Towards Multi-Paradigm Software Development

Valentino Vrani´c Department of Computer Science and Engineering, Faculty of Electrical Engineering and Information Technology Slovak University of Technology in Bratislava, Slovakia

Multi-paradigm software development is a possible an- multi-paradigm software development. swer to attempts of finding the best paradigm. It was The move towards multi-paradigm software present in software development at the level of intuition and practiced as the “implementation detail” without a development can be felt not only in new software real support in design. Recently it is making a twofold development paradigms—e.g. aspect-oriented breakthrough: several recent programming paradigms are programming, which is bound to other para- encouraging it, while explicit multi-paradigm approaches digms from the first principles—it is present al- aim at its full-scale support. In order to demonstrate this, ready in object-oriented programming. It is even a survey of selected recent software development (programming) paradigms (aspect-oriented approaches and more notable at the language level. It is hard to generative programming) and multi-paradigm approaches find a language that is pure in the sense of pro- (multi-paradigm programming in Leda, multi-paradigm hibiting any other than its proclaimed paradigm design in C++, and intentional programming) is pre- to be used in it. sented. The survey is preceded and underpinned by the anal- What has been described is the implicit form ysis of the concept of paradigm in computer science in of multi-paradigm software development. There the context of software development, since there is no a are several approaches which make this idea ex- common agreement about the meaning of this term, de- plicit by enabling a developer not only to com- spite its wide use. The analysis showed that there are two meanings of paradigm: large-scale and small-scale. bine multiple paradigms, but also to choose the most appropriate one for the given feature of a system or family of systems. Keywords: software development, programming, The rest of this article is organized as follows. large-scale, small-scale paradigm; commonality, variabil- Section 2 explores the concept of paradigm in ity analysis; multi-paradigm, aspect-oriented, generative, computer science in the context of software de- Leda, intentional programming; metaparadigm. velopment. Section 3 is an overview of selected recent post-object-oriented paradigms, namely 1 Introduction aspect-oriented programming approaches and generative programming. Section 4 proceeds The way software is developed is changing. En- with recent post-object-oriented approaches that forced by the need for mass production of qual- exhibit explicitly the multi-paradigm character. ity software and enabled by the grown experi- Section 5 closes the article with conclusions and ence of the field, software development is mov- proposals for further work. ing towards industrialization. The question is no longer which single tool is the best one, but how to select the right tools for each task to be 2 The Concept of Paradigm in accomplished. Software Development This article maps the state of the art in the field of post-object-oriented software devel- Paradigm is a very often used—and even more opment. Most notably, it is devoted to the often abused—word in computer science in the promising concepts of aspect-oriented program- context of software development. Its importance ming, generative programming and, particularly, arose significantly with appearance of so-called

1 2 Towards Multi-Paradigm Software Development multi-paradigm approaches. Before discussing 2.1 Large-Scale Paradigms them, the concept of paradigm in software development requires a deeper examination. We The notion of paradigm in the context of soft- must consider both the well-established meaning ware development is used at two levels of granu- of paradigm in science and the actual meaning larity. Let us first discuss the large-scale mean- of the word in order to find out when its use in ing of paradigm, which, as it has already been computer science is justified, and also to gain a mentioned, denotes the essence of a software de- better understanding of the concept of paradigm velopment process. Coplien used the term large- itself. scale paradigm to denote programming paradigms in, as he said, a “popular” sense [Cop99a]. The term paradigm in science is strongly re- Besides software development paradigm and lated to Thomas Kuhn and his essay [Kuh70], software engineering paradigm, at least two more where it has been used to denote a consistent terms are used to refer to large-scale paradigm collection of methods and techniques accepted by of software development: programming paradigm the relevant scientific community as a prevailing or, simply, programming. Although in common methodology of the specific field. use (for historical reasons), one must be car- ful with these terms because of possible misun- In computer science, the term paradigm de- derstanding: programming sometimes stands for notes the essence of a software development pro- implementation only, as other phases of a soft- cess (often referred to as programming, see Sec- ware development process can also be referred to tion 2.1). Unfortunately, this is not the only pur- explicitly (e.g., object-oriented analysis, object- pose this term is used for. Probably no science oriented design, etc.). has accepted this term with such an enthusiasm The name of a paradigm reveals its most sig- as computer science did; there are a lot of meth- nificant characteristic [Vra00]. Sometimes it is ods whose authors could not resist the tempta- derived from the central abstraction the para- tion to raise them to the level of paradigm (just digm deals with, as it is a function to functional try a keyword “paradigm” in some citing index paradigm, an object to object-oriented paradigm or digital library, e.g. [NEC]). Although not con- (according to [Mey97] it is not object but class tradictory to the original meaning of the word that is the central abstraction in object-oriented paradigm, such an overuse causes confusion. paradigm), etc. The basic meaning of paradigm is example, es- Lack of a general agreement on which name pecially a typical one, or pattern, which is in a di- denotes which paradigm is a potential source of rect connection to its etymology (Greek “to show confusion. For example, although the term func- side by side”) [Mer]. The meaning and etymol- tional paradigm is usually used to denote a kind ogy pose no restriction to the extent of the exam- of application paradigm, as opposed to proce- ple or pattern it refers to. This is reflected in the dural paradigm, in [Mey97] it is used to denote common use of the word paradigm today: on the exactly the procedural paradigm. It is hard to one hand, it has the meaning of a whole philo- blame the author for misuse of the term know- sophical and theoretical framework of scientific ing that the procedure is often being denoted as school (akin to Kuhn’s interpretation), while on function. the other hand, it is simply an example as in lin- It must be distinguished between the software guistics where it has the meaning of an example development paradigm itself and the means used of conjugation or declension showing a word in to support its realization. Unfortunately, this is all its inflectional forms [Mer]. another source of confusion. For example, any paradigm can be visualized by means of a visual Computer science, being a science whose great environment and thus it makes no sense to speak part is devoted to a special kind of languages about the visual paradigm (as in [Bud95]). Mak- intended for programming, hosts well both of ing a complete classification and comparison of these two interpretations of paradigm covered in the software development paradigms is beyond a more detail in the following text. the scope of this text; see [Náv96] for the com- Towards Multi-Paradigm Software Development 3 parison of selected programming paradigms re- the root in order to obtain different forms of the garding the concepts of abstraction and general- word. ization. Scope, commonality and variability (SCV) A software development paradigm is con- analysis [CHW98] can be used to describe these stantly changing, improving, or better to say language level paradigms. Here are the defini- refining. The basic principles it lays on must tions of the three cornerstone terms in SCV anal- be preserved; otherwise it would evolve into an- ysis (instead of entities the word objects was used other paradigm. Consider, for example, the sim- in [CHW98], but this could lead to a confusion plified view on the evolution of object-oriented with objects in the sense of object-oriented pa- paradigm. First, there were commands (impera- radigm): tive programming). Then named groups of commands appeared, known as procedures (proce- Scope (S): a set of entities; dural programming). Finally, procedures were Commonality (C): an assumption held uni- incorporated into the data it operated on yield- formly across a given set of entities S; ing objects/classes (object-oriented paradigm). However, according to Kuhn, paradigms do Variability (V ): an assumption true for only not evolve, although it could seem so; it is the some elements of S. scientific revolution that ends the old and starts SCV analysis of procedures paradigm illus- a new paradigm [Kuh70]. A paradigm is dom- trates the definition (based on an example inant by definition and thus there can be only from [CHW98]): one at a time in a given field of science unless the field is in an unstable state. According to S: a collection of similar code fragments, each this, simultaneous existence of several software to be replaced by a call to some new proce- development paradigms indicates that the field dure P ; of software development is either in an unstable state, or all these paradigms are parts of the one C: the code common to all fragments in S; not yet fully recognized nor explicitly named pa- V : the “uncommon” code in S; variabilities are radigm. That paradigm is beyond the commonly handled by parameters to P or custom code recognized paradigms and it is about the (right) before or after each call to P . use and combination of those paradigms. There- fore it can be denoted as metaparadigm. In the context of the small-scale paradigms, it is hard to find a single-paradigm program- 2.2 Small-Scale Paradigms ming language. The relationship between the small- and large-scale paradigms is similar to The notion of paradigm in computer science can that between the programming language features also be considered at the small-scale level based and programming languages; the large-scale pa- on the programming language perspective. This radigms consist of the small-scale ones. We can perception of paradigm is apparent in James O. revise here the source of the name of a large- Coplien’s multi-paradigm design [Cop99b] (cov- scale paradigm: the name of a large-scale pa- ered in more detail in Section 4.2). According radigm sometimes comes from the most signifi- to Coplien et al. [CHW98], we can factor out cant small-scale paradigm it contains. For exam- paradigms such as procedures, inheritance and ple, object-oriented (large-scale) paradigm con- class templates. We can identify the common sists of several (small-scale) paradigms: object and variable part which together constitute a pa- paradigm, procedure paradigm (methods), vir- radigm. A paradigm is then a configuration of tual functions, polymorphism, overloading, in- commonality and variability [Cop99b]. This is heritance, etc. Lack of a common agreement analogous to conjugation or declension in nat- what are the exact characteristics of object- ural languages, where the common is the root oriented paradigm makes it impossible to intro- of a word and variability is expressed through duce the exact list of the small-scale paradigms the suffixes or prefixes (or even infixes) added to that object-oriented paradigm consists of. 4 Towards Multi-Paradigm Software Development

Having an expressive programming language not an essential property of OOP, or it is being that supports multiple paradigms introduces an- denoted as a minor feature [Bud95]). Perhaps other issue: a method is needed for selecting the the Bertrand Meyer’s viewpoint that “‘object- right paradigms for the features that are to be oriented’ is not a boolean condition” [Mey97] is implemented. Such a method is a metaparadigm the best characterization of this issue. with respect to the small-scale paradigms. The OOP is not always the best choice among all small-scale paradigms metaparadigm is therefore the paradigms. This is recognized even in the a less elusive concept than the large-scale pa- OOP literature. Thus Booch points out that radigms metaparadigm. One such small-scale there is no single paradigm best for all kinds metaparadigm, multi-paradigm design for C++, of applications. But, according to Booch, OOP is described in Section 4.2. has another important feature: it can serve as One can understand small-scale paradigms as “the architectural framework in which other pa- a programming language issue exclusively, while radigms are employed” [Boo94]. Although this large-scale programming paradigms seem to have statement is probably overestimated in its appli- a broader meaning as they are affecting all the cability to all the paradigms, the truth is that phases of software development. Actually, small- some multi-paradigm languages (like Leda, see scale paradigms have an impact to all the phases Section 4.1) are designed in this fashion. This of software development as well; either with or reveals that OOP is multi-paradigmatic in its without an explicit support in analysis and de- very nature and leaves not much space for the sign. object-oriented purism. The object-oriented purism comes from the 3 Recent Software Develop- dogma that everything should be modeled by objects. But not everything is an object; neither ment Paradigms in the real world, nor in programming. Con- sider synchronization as a well-known example Among the recent software development para- of a non-object concept; in natural language, we digms there is a significant group of those that would probably refer to it as aspect. The as- appeared as a reaction to the issues tackled but pects crosscut the structure of objects (or func- not satisfactorily solved by object-oriented para- tional components, in general) making the code digm. Many of these paradigms actually build tangled. The pieces of code are either repeated upon object-oriented paradigm. Despite some throughout different objects or unnatural inher- of them are claimed not to be bound to object- itance must be involved. Among other inconve- oriented paradigm (and indeed, they are more niences, this “code scattering” has a bad impact generally applicable), they are still widely ap- on reuse. plied in connection with it. There are also other problems with OOP, in- 3.1 Beyond Object-Oriented Pro- cluding those it was supposed to solve, which are mainly in the areas of reuse (discussed gramming in [SN97]), adaptability, management of com- Human perception of the world is to the great plexity and performance [CE00]. In the sense extent based on objects. Object-oriented pro- of the means for solution that are at the de- gramming, well-known under the acronym OOP, veloper’s disposal—that can be denoted as solu- is based precisely on this perception of the world tion universe—OOP is not a universal paradigm. natural to humans. But what is OOP exactly? For example, OOP is not a universal paradigm This question seems to be an answered one. Ac- in C++ because it is not capable of making a tually, there is a plenty of answers to this ques- full use of all of its features, and C++ which tion, but the trouble is that they are all different. is just a part of the solution universe of soft- OOP has passed a very long way of changes to ware development. OOP encompasses only a few reach the form in which it is known today. Yet, interesting kinds of commonality and variabil- there is no general agreement about what are its ity [Cop99a]. Other kinds are needed as well, essential properties (to some even inheritance is so the non-object-oriented features of program- Towards Multi-Paradigm Software Development 5 ming languages are often used even though the problem. Note that the original code remains analysis and design were object-oriented. unchanged. The solution with aspects is undoubtedly more elegant than the tangled one would be. However, 3.2 Aspect-Oriented Programming the information where an aspect is to be woven and Related Approaches (i.e., join points) is included in the aspect itself. According to one of those who stood upon This complicates the aspect reuse. AspectJ ad- the birth of the aspect-oriented programming, dresses this problem with abstract aspects and Gregor Kiczales, aspect-oriented programming named sets of join points, so-called pointcuts. (AOP) is a new programming paradigm that enables the modularization of crosscutting con- Adaptive Programming cerns [KLM+97]. We’ll take a closer look at four main AOP approaches. Adaptive programming (AP), proposed by Demeter group [Dem] at Northeastern Univer- sity in Boston, deals mainly with the traversal Xerox PARC Aspect-Oriented Program- strategies of class diagrams. Demeter group has ming used the ideas of AOP several years before the Most of the AOP terminology (as well as its name aspect-oriented programming was coined. name) later adopted by others was coined by Xe- After the collaboration with the Xerox PARC rox PARC AOP group. Their research effort is AOP group had begun, Demeter group redefined being concentrated mainly on AspectJ [Xera], a AP as “the special case of AOP where some of general purpose AOP extension to Java [LK98]. the building blocks are expressible in terms of graphs and where the other building blocks refer AOP appeared as a reaction to the prob- to the graphs using traversal strategies” (build- lem known from the generalized procedure lan- ing block stands for aspect or component) [Lie]. guages [KLM+97], i.e. languages that use The traversal strategies are partial graph speci- the concept of procedure to capture function- fications through mentioning a few isolated cor- ality (besides procedural languages, this in- nerstone nodes and edges, and thus they crosscut cludes functional and object-oriented languages the graphs they are intended for. as well). In such languages some program code fragments that implement a clearly separable as- An example of AP is presented in Fig. 2. The pect of a system (such as synchronization) are left part of the figure presents a UML class di- scattered and repeated throughout the program agram of a system. Assume we would like to code that becomes tangled. AOP aims at factor- count on the people waiting at the bus stations ing out such aspects into separate units. Aspects along the bus route. In ordinary OOP this crosscut the base code in join points. These must would require either the implementation of small be specified so aspects could be woven into the methods in all of the affected classes (depicted base code by a weaver. shaded) or rough breaking of the encapsulation by exposing some of the classes’ private data. A simple example written in AspectJ v1.0.0 If we use a traversal strategy, as it is proposed (similar to the example in [LK98]) in Fig. 1 illus- in AP, there is no need for a change in the exist- trates the idea. Two classes are presented there, ing classes. In this case, the traversal strategy: Point and Line, whose methods are of the three kinds: creating, writing and reading (the imple- from BusRoute through BusStop to Person mentation of the methods is omitted). Suppose we want to be informed what kind of access to solves the problem of getting to objects of the these classes has been performed. In ordinary class Person along the bus route, which is suf- Java we would have to modify each method of ficient to count them. The right part of Fig. 2 both Point and Line. Moreover, this would re- demonstrates the robustness of this technique: sult in a tangled code. In AspectJ both problems the traversal strategy mentioned above applies can be avoided using aspects. In our example in this case as well although the class diagram it it is the aspect ShowAccesses that solves the was constructed for has changed. 6 Towards Multi-Paradigm Software Development

class Point { class Line { int x,y; int x1,y1,x2,y2; Point(int x, int y){...} Line(int x1, int y1, int x2, int y2){...} void set(int x, int y){...} void set(int x1, int y1, int x2, int y2){...} void setX(int x){...} int getX1(){...} void setY(int y){...} int getY1(){...} int getX(){...} int getX2(){...} int getY(){...} int getY2(){...} }}

aspect ShowAccesses { before(): execution(* (Point || Line).set*(..)) {System.out.println("Write");} before(): execution(* Point.get*(..)) {System.out.println("Read");} before(): execution((Point || Line).new(..)) {System.out.println("Create");} } Figure 1: Tracking access in AspectJ.

busStops BusRoute BusStopList BusRoute villages BusStopList

buses busStops 0..* buses VillageList busStops 0..* 0..* BusList BusStop BusList BusStop Village 0..* waiting 0..* waiting passsengers passsengers Bus PersonList Bus PersonList

0..* 0..* Person Person

Figure 2: Traversal strategies (from [Lie97], °c 1997 Northeastern University).

Composition Filters language [Koo95], which directly adopts the CF model [AT98, AWB+93]) are shown. These Composition filters (CF) is an aspect-oriented filters are attached to the Point and Line programming approach in which different as- classes from Fig. 1. The existence of the class pects are expressed as declarative and orthogo- ShowAccess is presumed. ShowAccess provides nal message transformation specifications called three methods—WriteAccess, ReadAccess and filters [AT98]. CreateAccess)—that simply write out the type A message sent to an object is evaluated and of the access. They are called by the three cor- manipulated by the filters of that object, which responding Dispatch filters, in case the message are defined in an ordered set, until it is dis- was accepted. Afterwards, the method of the carded or dispatched (i.e., activated or delegated inner object, which has actually been called, is to another object). A filter behavior is sim- executed (inner.*). ple: each filter can either accept or reject the received message, but the semantics of the op- erations depends on the filter type. For example, if an Error filter accepts the received message, it is forwarded to the next filter, but if it From the perspective of AOP, the class was a Dispatch filter, the message would be exe- ShowAccess implements the aspect, while the cuted. A detailed description of CF can be found filters represent the join points. Thus, the join in [AWB+93, Koo95]. points in this case are separated from the aspect, In Fig. 3 two sets of filters (written in Sina which is better regarding the aspect reuse. Towards Multi-Paradigm Software Development 7

Point acc: ShowAccess; inputfilters WriteAccess: Dispatch = {set, acc.WriteAccess, inner.*}; ReadAccess: Dispatch = {getX, getY, acc.ReadAccess, inner.*}; CreateAccess: Dispatch = {Point, acc.CreateAccess, inner.*}; Execute: Dispatch = {true => inner.*};

Line acc: ShowAccess; inputfilters WriteAccess: Dispatch = {set, acc.WriteAccess, inner.*}; ReadAccess: Dispatch = {getX, getY, getX1, getY1, acc.ReadAccess, inner.*}; CreateAccess: Dispatch = {Line, acc.CreateAccess, inner.*}; Execute: Dispatch = {true => inner.*}; Figure 3: Tracking access example implemented using composition ﬁlters approach.

Subject-Oriented Programming sented by composition rules, are separated from the aspect and represented by a separate class A concept can be defined by naming its proper- (as in CF approach). The composition rules for ties. This is sufficient to precisely define and the methods getY, getX1, getY1 and getX2 are identify mathematical concepts, but the same omitted in Fig. 4 (indicated by ellipsis) since they does not apply to natural concepts. Their def- are analogous to the rules for getX or getY2. initions are subjective and thus never complete This is not a characteristic case of the appli- (more details about conceptual modeling can be cation of SOP (such can be found in [OHBS94, found in [CE00]). KOHK96, IBM]); it is presented here in order Subject-oriented programming (SOP), devel- to show how a well-known AOP example can be oped at IBM as an extension to OOP [IBM], is easily transformed into its SOP version. Never- based on subjective views, so-called subjects.A theless, there is no general agreement whether subject is a collection of classes or class frag- SOP is AOP. In [CE00] SOP is viewed as a spe- ments whose hierarchy models its domain in its cial case of AOP where the aspects according to own, subjective way. A complete software sys- which the system is being decomposed are chosen tem is then composed out of subjects by writ- in such a manner that they represent different, ing the composition rules, which specify the cor- subjective views of the system. On the other respondence of the subjects (i.e., namespaces), hand, Kiczales et al. reject the very idea that classes and members to be composed and how SOP (which they call subjective programming) to combine them. could be AOP, arguing that the methods from As a result of the research effort in SOP, different subjects, which are being automatically the Watson Subject Compiler was devel- composed in SOP, are components in the AOP oped [KOHK96], which allows partial (subjec- sense since they can be well localized in a gener- + tive) definitions of C++ program elements and alized procedure (routine) [KLM 97]. But this automates the composition required to produce a seem to be a more general issue, since it applies running program. There are also other platforms to AspectJ, too, where it has been identified as SOP support was built for, such as IBM Visu- aspectual paradox by Liebrherr et al. [LLM99]: alAge for C++ Version 4, HyperJ and Smalltalk. An aspect described in AspectJ, the The example from Fig. 1 reimplemented in Xerox PARC’s AOP language, which Watson Subject Compiler-like syntax (the actual has a construct for specifying aspects, syntax could by slightly different) is presented in is by definition no longer an aspect, as Fig. 4. We assume that the class ShowAccess is it has just been captured in a (new kind implemented in Access namespace and that the of) generalized routine. classes Point and Line are implemented in the Graphics namespace. The join-points, repre- As observed in [Cza98], SOP is close to Gen- 8 Towards Multi-Paradigm Software Development

namespace GraphicsWithAccess{ class Point; class Line;}

GraphicsWithAccess.Point.Point := Merge[Graphics.Point.Point, Access.ShowAccess.CreateAccess]; GraphicsWithAccess.Line.Line := Merge[Graphics.Point.Line, Access.ShowAccess.CreateAccess];

GraphicsWithAccess.Point.set := Merge[Graphics.Point.set, Access.ShowAccess.WriteAccess]; GraphicsWithAccess.Line.set := Merge[Graphics.Line.set, Access.ShowAccess.WriteAccess];

GraphicsWithAccess.Point.getX := Merge[Graphics.Point.getX, Access.ShowAccess.ReadAccess]; ... GraphicsWithAccess.Line.getY2 := Merge[Graphics.Line.getY2, Access.ShowAccess.ReadAccess]; Figure 4: Tracking access example implemented using subject-oriented approach.

Voca [BG97], a successful approach to software • aspect-oriented programming, used to reuse. In GenVoca, systems are composed out of achieve the separation of concerns. layers according to design rules: GenVoca layers can be easily simulated by subjects. GP first has to be tailored to a particular domain in order to be used. This process will yield 3.3 Generative Programming a methodology for the families of systems to be developed, which can be viewed as a paradigm in Krysztof Czarnecki and Ulrich Eisenecker pro- its own right. This gives a certain metaparadigm pose a comprehensive software development pa- flavor to GP. radigm which brings together the object-oriented In the solution domain, GP requires metapro- analysis and design methods with domain en- gramming for weaving and automatic configu- gineering methods that enable development of ration. To support domain-specific notations, the families of systems: generative program- syntactic extensions are needed. Active libraries ming [CE00]: are proposed in [CE00], which can be viewed as knowledgeable agents interacting with each other Generative programming (GP) is a to produce concrete components, as appropriate software engineering paradigm based to cover this requirement. on modeling software systems families such that, given a particular re- quirements specification, a highly cus- 4 Multi-Paradigm Approaches tomized and optimized intermediate or end-product can be automatically man- In the survey of recent post-object-oriented soft- ufactured on demand from elementary, ware development paradigms presented in the reusable implementation components previous section a spontaneous move towards the by means of configuration knowledge. integration of paradigms became apparent. This section proceeds with explicit multi-paradigm GP is a unifying paradigm—it is closely re- approaches. lated to four other paradigms (see Figure 5):

• object-oriented programming, providing ef- 4.1 Multi-Paradigm Programming in fective system modeling techniques, Leda

• generic programming, enabling reuse The question how to support multi-paradigm through parameterization, programming at the language level can be answered simply: create a multi-paradigm lan- • domain-speciﬁc languages, increasing the guage. Timothy Budd took this route by cre- abstraction level for a particular domain, ating a multi-paradigm programming language and called Leda. Towards Multi-Paradigm Software Development 9

Object-Oriented Q Q Programming Q Q QQs Xerox PARC Aspect- Generic - Generative S 3 Oriented Programming S Programming 7 Programming S S Composition Q Domain-Speciﬁc Q S Filters Q S Languages Q S QQsSw Demeter/Adaptive - Aspect-Oriented 3 Programming Programming Subject-Oriented Programming

Figure 5: Generative programming and related paradigms. The arrows represent “is incorporated into” relationship.

According to Budd, Leda supports four pro- functional paradigm is achieved by using func- gramming paradigms [Bud95]: imperative (pro- tions in the recursive fashion while refraining cedural, to be more precise) logic, functional, from assignments. and object-oriented. The term paradigm, as In addition to the basic mechanisms of object- used by Budd, denotes a large-scale paradigm oriented paradigm, such as classes, inheritance, (with respect to the classification of paradigms encapsulation etc., Leda also supports parame- introduced in Section 2). This means that Leda terized types (considered by some authors a part actually supports more than four small-scale pa- of object-oriented paradigm [Mey97]). radigms. This is clear having in mind that, for Despite Leda is not widely used, it is worth example, object-oriented paradigm breaks down consideration because it demonstrates the com- into six or more small-scale paradigms, as has bination of paradigms. For example, the infer- been shown in Section 4.2. Nevertheless, in order ence mechanism of logic programming can be not to digress from the intent of this approach, used inside of a procedure. just the mechanisms by which each of the four Of course, creating a language that supports proclaimed paradigms is supported in the lan- multiple paradigms and expecting it would be guage will be discussed. the best language to program in is similar to a Leda has a Pascal-like (i.e., Algol-like) syn- search for the best programming paradigm. No tax and, moreover, the mechanism upon which matter how many paradigms are supported in a all the four supported paradigms realization is programming language, the number is finite and, based on in Leda are functions (procedures that obviously, it does not embrace the future para- return values). This makes a good background digms. One can argue that it is possible to ex- for procedural paradigm, denoted as imperative tend the language with new programming mech- by Budd. anisms in order to support new paradigms. This Logic paradigm is supported by a special type is not only possible, but often practiced. Un- of function that returns relation data type and fortunately, programming languages cannot be by a special assignment operator <-. These indi- extended indefinitely due to limitations set by cate when the inference mechanism, inherent to parsing methods. logic programming, is to be activated. Leda is an example of a language created (from Functional paradigm requires no special mech- scratch) in order to support multiple paradigms. anism than those provided by functions because We can consider interconnecting existing lan- Leda permits a function to be an argument of an- guages that support different paradigms through other function and to return a function. Thus, an interface instead of making a completely new 10 Towards Multi-Paradigm Software Development language (a sort of language reuse). There is hand, neither SCV, nor SCVR analysis is men- also a possibility of implementing one language tioned in [Cop99b]; the term commonality and on top of the other, but this leads to a certain variability analysis is used instead to denote the degradation of performance. An example of in- same thing. Commonality analysis concentrates terconnecting object-oriented and logic program- on common attributes while the aim of variabil- ming (Loops and Xerox Quintus Prolog) can be ity analysis is to parameterize the variation. found in [KE88]. The major steps in MPD are: commonality There are a lot of approaches that fall into this and variability analysis of the application do- category. Yet another approach and an overview main, commonality and variability analysis of of similar approaches together with the discus- the solution domain, transformational analysis sion of the paradigms integration problems can and translation from the transformational anal- be found in [VS95]. Such approaches are popular ysis to the code. These steps need not to be per- especially in the field of artificial intelligence be- formed sequentially. They can be performed in cause of the need to combine the two paradigms parallel (to some extent) and revisited as needed. traditionally used in this field, logic and func- Before starting the actual MPD, it is recom- tional programming, both with each other and mended to evaluate the possibility to reuse an together with OOP. existing (similar) design. If the commonalities Different paradigms are expressed using dif- and variabilities of the application domain do not ferent syntax. BETA language [Mad00] is sup- fit any existing solution domain structures, cre- posed to overcome this inconvenience through a ation of a new application-oriented (i.e., domain- unified syntax achieved by introducing so-called specific) language should be considered. pattern as an abstraction of all other programming language constructs appearing in the pa- Application domain analysis. Commonal- radigms it supports. The approach is therefore ity analysis of the application domain (usually denoted as unified paradigm, but it is not funda- denoted as problem domain) starts with finding mentally different from the other “created to be commonality domains and creating domain dic- multi-paradigm” languages. tionary. It then proceeds in parallel with variability analysis, whose results —the parameters of variation of a given commonality domain and 4.2 Multi-Paradigm Design for C++ their characteristics— are being summarized in Multi-paradigm design for C++ (MPD), as pro- variability tables (one per each commonality do- posed by Coplien [Cop99b, Cop00], has its roots main), as depicted in the upper part of Fig. 6. in the multi-paradigm features of C++. De- As already mentioned, variability dependency spite these multi-paradigm features, C++ is of- graphs (denoted also as domain dependency ten considered to be just an object-oriented lan- graphs or diagrams) are used to capture the re- guage. As such, C++ is used to implement the lationship between domains and their parame- systems designed according to object-oriented ters of variation, which are also domains. Vari- paradigm. However, non-object-oriented fea- ability dependency graphs are directed graphs tures of C++ are widely used, but without a whose nodes represent domains and edges rep- support in the (object-oriented) design. resent “depends on” relationship (in the direc- MPD is a metaparadigm intended for develop- tion indicated by an arrow) between domains ing families of systems, therefore akin to domain and their parameters of variation. Despite the engineering approaches. It deals with choosing simple notation, variability dependency graphs the appropriate paradigm for a feature being de- are quite useful in identifying overlapping do- signed and implemented. MPD is based on SCV mains (such domains can be merged) and code- analysis (discussed in Section 2.2) or, to be more pendent domains, i.e. the domains with circular precise, SCVR analysis, where R stands for re- dependencies (which must be resolved). lationship between domains [Cop00], which are covered by variability dependency graphs (ex- Solution domain analysis. The same com- plained further in this section). On the other monality and variability analysis as applied to Towards Multi-Paradigm Software Development 11 the application domain is applied to the solu- justified in the ongoing research on reuse with tion domain, i.e. the programming language. design patterns [SN00]. First, a description of the identified small-scale Indeed, MPD and design patterns seem to paradigms, manifested through the language fea- be complementary; design patterns capture de- tures, structured according to commonality, vari- signers’ experience by documenting the recom- ability, binding, and example is provided. The mended solutions for the common problems in analysis proceeds with exploring the negative software development, while MPD relies on this variability, a variability that violates the rule of experience. However, to make a full use of design variation by attacking the underlying common- patterns in MPD, and in software development ality. A positive variability, as opposed to the in general, a better way of their representation negative one, can be parameterized. The neg- is needed [SNB98]. ative variability has to be kept small. If it be- Although the design patterns from [GHJV95] comes larger than the commonality, the design are inspired by Alexandrian patterns [Ale79], not should be refactored to reverse the commonality all of them are the patterns in Alexandrian sense: and variability. some of them can be formalized as configurations The results of the solution domain commonal- of commonality and variability (unlike Alexan- ity and variability analysis are summarized in the drian patterns). As such they can be incorpo- family table, as shown in the lower part of Fig. 6, rated directly into MPD (by adding them to the and in the table used to express features for neg- family table), as anything else that can be for- ative variability, where for each combination of malized as a configuration of commonality and the kind of commonality and kind of variability variability (i.e., other paradigms and solution do- the language feature for positive variability and main tools that are not supported by the main the one for the corresponding negative variabil- programming language, like databases or parser ity is introduced. generators) [Cop99b]. One of the problems with MPD is the un- Transformational analysis. The tables ob- suitability of the notation used: only a few tained in the preceding analyses are used in types of tables and variability diagrams with a transformational analysis, which is, roughly lot of the relevant details expressed as informal speaking, a matching of application domain text. With a better notation, like feature model- structures, described in variability tables, with ing [Vra01], transformational analysis could be- solution domain structures, i.e. paradigms, de- come more transparent. A better notation could scribed in family tables. Figure 6 shows how is also ease the transition to the actual program this matching performed. Prior to the matching, code (the program skeleton). the commonality domain has to be generalized (e.g., Text Editing Buffers: behavior, struc- 4.3 Intentional Programming ture), and the parameters of variation also (e.g., output medium: structure, algorithm). Programming languages with fixed syntax are MPD emphasizes solution domain analysis, limiting otherwise unlimited number of pro- underestimated in contemporary software devel- gramming abstractions. Intentional program- opment methodologies resulting into a gap be- ming group at Microsoft Research offered a so- tween design and implementation. lution to this problem as a new software de- To a certain extent, MPD enforces the reuse velopment paradigm called intentional program- of design: both application and solution domain ming (IP) [Sim99, Sim96] (the project is on hold analysis can be reused independently; however, from Spring 2001 [Roe]). The idea behind IP transformational analysis is not reusable. This is that programming abstractions, which are in brings MPD close to design patterns, as dis- IP denoted as intentions, could live better with- cussed in [Cop99b]. On the very cover of the de- out their hosts, (fixed-syntax) programming lan- sign patterns cornerstone book [GHJV95] Steve guages, because of their limits in the accepted Vinoski points out that a reusable design is “the notations (due to underlying grammars). real key to software reuse”. This claim is being A program in IP is represented by a so-called 12 Towards Multi-Paradigm Software Development

9DULDELOLW\WDEOHV IURPDSSOLFDWLRQGRPDLQ6&95DQDO\VLV 7H[W(GLWRU9DULDELOLW\$QDO\VLVIRU&RPPRQDOLW\GRPDLQ 7(;7(',7,1*%8))(56 &RPPRQDOLW\%HKDYLRUDQG6WUXFWXUH 3DUDPHWHUVRIYDULDWLRQ 0HDQLQJ 'RPDLQ %LQGLQJ 'HIDXOW 2XWSXWPHGLXP « 'DWDEDVH5&6ILOH 5XQWLPH 81,;ILOH 6WUXFWXUH$OJRULWKP 77<81,;ILOH

)DPLO\WDEOH IURPVROXWLRQGRPDLQ6&95DQDO\VLV &RPPRQDOLW\ 9DULDELOLW\ %LQGLQJ ,QVWDQWLDWLRQ /DQJXDJH0HFKDQLVP 5HODWHG RSHUDWLRQVDQG $OJRULWKP &RPSLOH 2SWLRQDO ,QKHULWDQFH VRPHVWUXFWXUH HVSHFLDOO\PXOWLSOH WLPH SRVLWLYH DVZHOODV RSWLRQDO YDULDELOLW\ GDWDVWUXFWXUHDQG VWDWH $OJRULWKPDVZHOODV 5XQWLPH 2SWLRQDO 9LUWXDOIXQFWLRQV RSWLRQDO GDWD VWUXFWXUHDQGVWDWH Figure 6: Transformational analysis in MPD (according to an example from [Cop99b]). intentional tree, whose nodes represent intention same name (even if they reside the same scope). instances. Each intention instance points to the This is possible because the intentional tree does corresponding intention declaration node that not rely on the names to identify intentions; the provides a method which speciﬁes the process names are provided only for developers’ conve- of transforming the subtree headed by the in- nience. tention instance. The executable program is ob- Although it can seem so, IP is not intended tained in a process called reduction in which the to push out the existing programming languages intentional tree is traversed and transformed ac- from the scene. It can import any program in cording to the rules indicated by intention decla- any programming language if a parser for that rations until it consists only of executable nodes. language—in the form of a library—is added to Such a reduced tree is represented in an interme- IP environment. diate language. The executable code is generated from this representation. 4.4 Multi-Paradigm Approaches It would be inconvenient for a human to di- Compared rectly maintain the intentional tree. This is being performed in a programming environment The three multi-paradigm approaches presented with a special graphic editor instead of the usual in this section are compared in Table 1 according text editor. This enables each intention to have to the selected criteria: the concept of paradigm its own graphic representation. Of course, enter- the approach enforces, a programming language ing a program in such an environment is quite the approach is bound to, and whether the ap- diﬀerent from entering it in a classic text editor. proach supports the language extension. A program text, as we are used to it, is a com- It is important to note that these three ap- plete and an unambiguous representation of the proaches are not antagonistic; they are comple- program. In IP environment this is not so. What mentary. Multi-paradigm design arms us with is presented in IP editor is only a view of the ac- techniques for dealing with multiple paradigms tual program. To illustrate this, consider one when a multi-paradigm environment is available. peculiarity: two distinct variables can have the Intentional programming enables such an envi- Towards Multi-Paradigm Software Development 13

Paradigm Language Language extension MP in Leda large-scale Leda no MPD small-scale any not applicable IP small-scale none yes

Table 1: The three multi-paradigm approaches compared. ronment to be created and maintained easier programming language by applying commonality than it is the case with the classical program- and variability analysis to it. It would be par- ming languages. Finally, multi-paradigm pro- ticularly interesting to establish multi-paradigm gramming in Leda demonstrates how four spe- design for AspectJ (see Section 3.2) since it cific programming paradigms can be combined. could help to understand better the relationship between multi-paradigm design and aspect- oriented programming (although, of course, As- 5 Conclusions and Further pectJ is not the same as aspect-oriented pro- Work gramming in general), which Coplien denoted as “the most fully general implementation of multi- The concept of paradigm in computer science in paradigm design possible” [Cop00]. An initial the context of software development has been work towards establishing multi-paradigm de- analyzed in this article. Two distinct meanings sign for AspectJ has been reported in [Vra01]. of paradigm in software development have been The notation used in multi-paradigm design, identified and discussed: large-scale and small- which besides informal description embraces scale. only two types of tables and a kind of sim- A survey of selected post-object-oriented pa- ple graphs, is not appropriate. This is appar- radigms, namely aspect-oriented approaches and ent especially during transformational analysis. generative programming, has been presented. Similarly to commonality and variability anal- A growing multi-paradigm tendency has been ysis of multi-paradigm design, feature modeling identified in these approaches. This tendency also expresses commonalities and variabilities ex- has materialized into explicit multi-paradigm ap- plicitly, but using a more sophisticated notation proaches. Three such approaches have been dis- (see [CE00] for more details on feature modeling cussed and compared: multi-paradigm program- and feature diagrams). Both solution and ap- ming in Leda, multi-paradigm design for C++, plication domains can be represented as feature and intentional programming. models, as has been demonstrated in [Vra01]. Multi-paradigm approach to software develop- This eases transformational analysis and brings ment makes the question which paradigm is the multi-paradigm design and generative program- best (and therefore should replace all other pa- ming closer to each other. radigms) a meaningless one. It has a potential of incorporating all the paradigms at disposal of Acknowledgments the solution domain. It is a paradigm of paradigms: a metaparadigm. This work was partially supported by Slovak Sci- However, multi-paradigm software develop- ence Grant Agency, grant No. G1/7611/20. I ment must be further improved and refined if it would like to thank Pavol Návratfor his valu- is to be used in its full strength. Among the able suggestions. multi-paradigm approaches considered, multi- paradigm design (for C++), described in Sec- tion 4.2, seems to be the most appropriate as References the basis for the future form of multi-paradigm [Ale79] C. Alexander. The Timeless Way of software development. Building. Oxford University Press, 1979. Multi-paradigm design can be tailored to any Cited in [Cop99b]. 14 Towards Multi-Paradigm Software Development

[AT98] M. Aksit and B. Tekinerdogan. Solving [Cza98] K. Czarnecki. Generative Programming: the modeling problems of object-oriented Principles and Techniques of Software languages by composing multiple aspects Engineering Based on Automated Config- using composition filters. In Proc. of the uration and Fragment-Based Component Aspect-Oriented Programming Workshop Models. PhD thesis, Technical Univer- at ECOOP’98, 1998. Available at [Twe]. sity of Ilmenau, Germany, 1998. Partially available at [Cza]. [AWB+93] M. Aksit, K. Wakita, J. Bosch, L. Bergmans, and A. Yonezawa. [Dem] Demeter group. Home page. http:// Abstracting object-interactions us- www.ccs.neu.edu/research/demeter. ing composition-filters. In Proc. of Accessed on October 30, 2001. 7thEuropean Conference on Object- [GHJV95] E. Gamma, R. Helm, R. Johnson, and Oriented Programming (ECOPP’93) J. Vlissides. Design Patterns: Ele- Workshop, LNCS 791, pages 152–184, ments of Reusable Object-Oriented Soft- Kaiserslautern, Germany, 1993. Springer. ware. Addison-Wesley, 1995. Available at [Twe]. [IBM] IBM Research. Subject-Oriented Pro- [BG97] D. Batory and B. J. Geraci. Composition gramming home page. http://www. validation and subjectivity in GenVoca research.ibm.com/sop. Accessed on generators. IEEE Transactions on Soft- August 15, 2000. ware Engineering (special issue on Soft- ware Reuse), pages 67–82, February 1997. [KE88] T. Koschmann and M. W. Evens. Bridg- Available at [Pro]. ing the gap between object-oriented and logic programming. IEEE Software, [Boo94] G. Booch. Object-Oriented Analysis 60:36–42, July 1988. and Design with Applications. Addison- Wesley Publishing Company, second edi- [KLM+97] G. Kiczales, J. Lamping, A. Mendhekar, tion, 1994. C. Maeda, C. V. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented program- [Bud95] T. A. Budd. Multiparadigm Programming ming. In M. Aksit and S. Matsuoka, in Leda. Addison-Wesley, 1995. editors, Proc. of 11th European Con- [CE00] K. Czarnecki and U. Eisenecker. Genera- ference on Object-Oriented Programming tive Programing: Principles, Techniques, (ECOOP’97), LNCS 1241, Jyväskylä, and Tools. Addison-Wesley, 2000. Finland, June 1997. Springer. Available at [Xerb]. [CHW98] J. Coplien, D. Hoffman, and D. Weiss. Commonality and variability in soft- [KOHK96] M. Kaplan, H. Ossher, W. Harrison, ware engineering. IEEE Software, 15(6), and V. Kruskal. Subject-oriented de- November 1998. Available at [Cop]. sign and the watson subject compiler. In 11th Annual ACM Conference on Object- [Cop] J. O. Coplien. Home page. http://www. Oriented Programming Systems, Lan- bell-labs.com/people/cope. Accessed guages and Applications (OOPSLA’96), on November 15, 2001. 1996. Available at [IBM]. [Cop99a] J. O. Coplien. Multi-paradigm design [Koo95] P. S. Koopmans. On the definition and and implementation in C++. Slides and implementation of the Sina/st language. notes of the tutorial given at 1st Inter- Master’s thesis, Dept. of Computer Sci- national Conference on Generative and ence, University of Twente, The Nether- Component-Based Software Engineering lands, August 1995. Available at [Twe]. (GCSE’99), Erfurt, Germany, September 1999. Available at [Cop]. [Kuh70] T. S. Kuhn. The Structure of Scientific Revolutions. University of Chicago Press, [Cop99b] J. O. Coplien. Multi-Paradigm Design for Chicago, 1970. Czech translation, OIKY- C++. Addison-Wesley, 1999. MENH, 1997. [Cop00] J. O. Coplien. Multi-Paradigm Design. [Lie] K. J. Lieberherr. Connections be- PhD thesis, Vrije Universiteit Brussel, tween Demeter/adaptive programming Belgium, 2000. Available at [Cop]. and aspect-oriented programming. Web [Cza] K. Czarnecki. Home page. http://www. document, College of Computer Science, prakinf.tu-ilmenau.de/~czarn. Ac- Northeastern University, Boston, USA. cessed on November 15, 2001. Available at [Dem]. Towards Multi-Paradigm Software Development 15

[Lie97] K. J. Lieberherr. Demeter and aspect- [Roe] L. Roeder. Home page. http://www. oriented programming: Why are pro- aisto.com/roeder. Accessed on Novem- grams hard to evolve? Presenta- ber 21, 2001. tion slides, 3rd Conference Smalltalk [Sim96] C. Simonyi. Intentional programming— und Java in Industrie und Ausbildung innovation in the legacy age, June 1996. (STJA 97), Erfurt, Germany, 1997. Presented at IFIP WG 2.1 meeting, avail- Available at [Dem]. able at [Roe]. [LK98] C. V. Lopes and G. Kiczales. Recent de- [Sim99] C. Simonyi. The future is intentional. velopments in AspectJ. In Proc. of 12th IEEE Computer, 32(5):56–57, May 1999. European Conference on Object-Oriented Programming (ECOPP’98) Workshops, [SN97] M. Smolárováand P. Návrat. Software Demos, and Posters, LNCS 1543, Brus- reuse: Principles, patterns, prospects. sels, Belgium, July 1998. Springer. Avail- Journal of Computing and Information able at [Xerb]. Technology, 5(1):33–48, 1997. [LLM99] K. J. Lieberherr, D. Lorenz, and [SN00] M. Smolárová and P. Návrat. Reuse M. Mezini. Programming with aspec- with design patterns: Towards pattern- tual components. Technical Report NU- based design. In Y. Feng, D. Notkin, and CCS-99-01, College of Computer Science, M. Gaudel, editors, Proc. Software: The- Northeastern University, Boston, MA, ory and Practice, pages 232–235, Beijing, March 1999. Available at [Dem]. China, 2000. PHEI - Publishing House of Electronics Industry. [Mad00] O. L. Madsen. Towards a unified pro- [SNB98] M. Smolárová, P. Návrat, and M. Be- gramming language. In J. L. Knud- liková.Abstracting and generalising with sen, editor, Proc. of 14th European design patterns. In A. G. U. Güdükbay, Conference on Object-Oriented Program- T Dayar and E. Gelenbe, editors, Proc. of ming(ECOOP 2000), Sophia Antipolis 13th International Symposium on Com- and Cannes, France, June 2000. Springer puter and Information Sciences (IS- LNCS 1850. CIS’98), pages 551–558, Belek-Antalya, [Mer] Merriam-Webster OnLine. Merriam- Turkey, 1998. IOS Press. Webster’s Collegiate Dictionary. http: [Twe] Twente Research and Education on Soft- //www.m-w.com. Accessed on Novem- ware Engineering (TRESE) group. Home ber 15, 2001. page. http://trese.cs.utwente.nl. [Mey97] B. Meyer. Object-Oriented Analysis Soft- Accessed on November 15, 2001. ware Construction. Prentice Hall, second [Vra00] V. Vranić. Multiple software devel- edition, 1997. opment paradigms and multi-paradigm [NEC] NEC Research Institute. ResearchIndex: software development. In J. Zendulka, The NECI Scientific Digital Research Li- editor, Proc. of 3rd International Confer- brary. http://citeseer.nj.nec.com. ence on Information Systems Modelling Accessed on November 15, 2001. (ISM 2000), pages 191–196, Roˇznov pod Radhoˇstˇem,Czech Republic, May 2000. [Náv96] P. Návrat. A closer look at program- MARQ. ming expertise: Critical survey of some methodological issues. Information and [Vra01] V. Vranić. AspectJ paradigm model: A Software Technology, 38(1):37–46, 1996. basis for multi-paradigm design for As- pectJ. In J. Bosch, editor, Proc. of [OHBS94] H. Ossher, W. Harrison, F. Budinsky, 3rd International Conference on Gen- and I. Simmonds. Subject-oriented pro- erative and Component-Based Software gramming: Supporting decentralized de- Engineering (GCSE 2001), LNCS 2186, velopment of objects. In Proc. of 7th IBM pages 48–57, Erfurt, Germany, Septem- Conference on Object-Oriented Technol- ber 2001. Springer. ogy, July 1994. Available at [IBM]. [VS95] S. Vraneˇsand M. Stanojević. Integrat- [Pro] Product-Line Architecture Research ing multiple paradigms within the black- group. Home page. http://www.cs. board framework. IEEE Transactions utexas.edu/users/schwartz. Accessed on Software Engineering, 21(3):244–262, on November 15, 2001. 1995. 16 Towards Multi-Paradigm Software Development

[Xera] Xerox PARC. AspectJ home page. http: //aspectj.org. Accessed on Novem- ber 15, 2001. [Xerb] Xerox PARC. Software Design Area home page. http://www.parc.xerox. com/sda. Accessed on November 15, 2001.