Designing Heterogeneous Component Based

Systems: Evaluation of MARTE Standard andEnhancement Proposal

Ali Koudri1, Arnaud Cuccuru2, Sebastien Gerard2, and Francois Terrier2

1 Thales Research and Technology2 CEA

Abstract. Building complex real-time embedded systems requires as-sembly of heterogeneous components, possibly using various computationand communication models. A great challenge is to be able to design suchsystems using models where these heterogeneity characteristics are de-scribed precisely to assist the next step of the development including im-plementation or analysis. Although the new MARTE standard providesthe core concepts to model real-time components using various commu-nication paradigms, we state in this paper that MARTE extensions havestill to be made and we propose to extract common features from severalcomponent based approaches in order to support finer compositions ofheterogeneous sub-systems.

1 Introduction

Building real-time embedded systems through composition of well-defined andwell-documented components is a tricky issue. Composition provides means todeal with complexity applying the “divide to conquer” paradigm.

In the field of software engineering, composition issues are addressed by theComponent Based Development (CBD) domain. Historically, CBD comes fromdisciplines of mechanical and electrical engineering where components are intu-itively understood. In the field of real-time embedded systems (RTES), composi-tion is difficult to achieve as complexity is increased by sub-systems heterogeneity(analog / digital devices, Globally Asynchronous Locally Synchronous systems– GALS, etc.) and real-time or other QoS issues. Then, a solid alternative is toconsider UML models to handle such heterogeneity in a unified way. Unfortu-nately, current modeling languages lack means to specify rich interfacing andconnections between components in both software and hardware domains.

In this paper, we are interested in the “Interface Based Programming” appliedto Model Based Engineering (MBE). In particular, we study how assembly canbe achieved (interfacing conditions and constraints) and realized (allocation /implementation). We propose then to refine the notions of port, interface andconnector of the MARTE GCM (Generic Component Model) sub-profile in orderto achieve better composition and substitution capabilities in the context ofheterogeneous real-time embedded systems design and analysis.

J. Whittle, T. Clark, and T. Kuhne (Eds.): MODELS 2011, LNCS 6981, pp. 243–257, 2011.c© Springer-Verlag Berlin Heidelberg 2011

244 A. Koudri et al.

In the next section, we provide a short survey on component-based approachesfrom several communities in order to extract key features component modelsshould provide. Then, we list identified issues related to composition in UML,SysML and MARTE. In the third section, we propose a generic solution forcomposing heterogeneous system models. In conclusion, we provide insights onour future work.

2 Background

In software engineering, a component is defined as “a piece of self-contained, self-deployable computer code with well-defined functionality that can be assembledwith other components through its interface” [14]. More precisely, a componentmodel defines “rules for the specification of component properties and mech-anisms for component composition, including composition rules of componentproperties”. This definition distinguishes three important parts: the specificationof components internals, including functional and non-functional properties; thespecification of components interfaces, e.g. what they provide/require to/fromtheir environment; the specification of interactions. While the first and the sec-ond parts are usually well addressed by architectural patterns, the third part isusually not explicitly specified and is related to implicit communication patterns.

In order to provide a better understanding of composition, authors of [2]present a framework for software components that compares interfacing andinteraction styles. According to this survey, an interface is mainly characterizedby: its type, e.g. operation-based (service invocations) or port-based (data-flow);the distinction between its provided/required parts; the existence of distinctivefeatures (optional modes); its specification language; its contractualisation level(syntactic / semantic / behavioral). Besides, authors characterize interactions by:their interaction type (e.g. request/response, message passing or event-driven);their communication type (e.g. synchronous or asynchronous); their binding type(e.g. connection, hierarchy or both).

In hardware engineering, evolution of technologies has pushed the usage ofhardware components as well. Indeed, design of Integrated Circuits (IC) or VeryLarge Scale Integrated Circuits (VLSI) requires techniques to handle exponen-tial complexity due to Moore’s law. Then, hardware engineers can achieve abetter productivity assembling reusable and reliable blocks (Intellectual Prop-erties – IP): microprocessor, DSP, memory, bus, etc. Indeed, component-basedapproaches have been long used with success in hardware engineering and haveproven their relevancy to handle complexity and productivity.

Unfortunately, the aforementioned approaches are mainly focused on imple-mentation issues and higher level approaches are required to favor analysis activ-ities. To this end, several Architecture Description Languages (ADL) have beenproposed in both software and hardware domains. According to [9], the purposeof an ADL is to shift from lines-of-code to coarser-grained architectural elements(components and connectors). Then, authors define an Architecture DescriptionLanguage as “a language that provides features for modeling a software system’s

Designing Heterogeneous Component Based Systems 245

conceptual architecture distinguished from the system’s implementation.” Still,there is no consensus on what aspects of architecture should be modeled and in-terchanged. For instance, among all existing ADLs, some of them are just usedto provide a better understanding of the system (global behavior and commu-nications) while other provide full featured language along with analysis tools,checkers, compilers, synthesis tools, etc.

Whatever, an ADL should provide at least a simple and understandable syn-tax, possibly graphical, to improve the system analysis. This syntax must rely ona clear semantics avoiding ambiguities. In [13], authors elaborate six classes ofproperties all ADLs should provide: composition, abstraction, reusability, con-figuration, heterogeneity and analysis. In particular, they argue the need to con-sider the connector as a first-class entity to support heterogeneity. In [9], authorsprovide a comparison framework for ADLs. In this framework, both componentand connector are characterized by their: Interfaces, defining a set of interactionpoints providing/requiring services (messages, operations, variables) to/from ex-ternal world – Services are related to computations in the case of componentsand to communications in the case of connectors; Types, defining a configurableabstraction allowing re-usability, and extensibility – Modeling connectors as typemakes sense because interactions are often characterized by complex protocols;Semantics, representing a high level behavioral model which is required to per-form analysis or to ensure consistent mappings from one level of abstractionto another; Constraints, defining assertions whose violation would render thesystem unacceptable; Non-functional properties, e.g. properties that cannot bederived directly from the specification of behaviors (safety, security, performance,etc.). Such properties are required early in the design process to perform relevantanalysis or to foster replaceability in context.

3 Motivations

The specification of UML 2.0 [10] introduces several important concepts forsupporting composition: Collaboration, Port, Connector, etc. Unfortunately, thesemantics of those elements is generally not well defined. The main reason of thislack is because such semantics depends on target domains. Indeed, it is suggestedin p.147 of the specification that “profiles based around components will bedeveloped for specific component technologies”. In SysML [11], components havebeen introduced under the notion of “Block” which is defined as “a modular unitof system description” providing general purpose capabilities to model large andheterogeneous systems. SysML refines the UML components in different ways:reusable constraints, multi-level nesting of connector ends, etc. In MARTE [12],the Generic Component Model (GCM) sub-profile provides the core concepts tomodel real-time and embedded system components. Those concepts representa common denominator among various component models (lightweight-CCM,AADL, EAST-ADL2, etc.) except that no specific execution semantics has beentied. For instance, a structured component is defined as “a self-contained entityof a system which may encapsulate structured data and behaviors”.

246 A. Koudri et al.

Regarding UML components, several issues have been raised by the OMG andshow inconsistencies in both syntax and semantics:

– Handling of requests by ports (behavioral or not) is not clear (issue 10597),– Typing a port by a class, behavioral or not, has not a clear semantics (issue

15290),– Connectors do not provide means for specifying an interaction pattern be-

tween involved roles played at connector ends (issue 10474).

Even if SysML proposes refinements of ports, interfaces and connectors, thereare still several lacks and semantics issues that have been raised:

– In some situations, it would be useful to be able to attach a protocol statemachine to ports (issue 10047),

– Handling of complex ports, mixing services and data-flows, is not well ad-dressed (issues 10059 and 12269),

– Nothing is said about the semantics of binding connector ends with differentmultiplicities (issue 11333), and particularly in the context of continuousflows (issue 15298),

– Binding connectors should be typed in order to support decomposition (issue15079),

– There are limitations to represent certain kinds of interfaces (mechanical,electrical, etc.) and ports. For instance, issues 12156 and 15076, proposeto introduce the notions of “Junction Port” and “Non-flow property Port”.Issue 13179 adds that, in this context, an integration of Modelica conceptsshould be discussed,

– Issue 13178 suggests that a flow specification should not be a refinement ofan interface because port decomposition in that case would not be possible.

Since MARTE reuse definitions of SysML blocks, interfaces and connectors, is-sues presented above are also applicable in this language. To give insights tothose questions, we use the study from section 2 to abstract common denomi-nators so we can propose a flexible way to specify components and compositionthat takes into account systems heterogeneity. This work is required in order tofoster the use of models for design, analysis and implementation of RTES.

4 Contribution

Ideally, the MBE combined with CBD provides a powerful approach as it fa-cilitates design and analysis activities though a clear separation of concerns.In practice, this is another story; and before such approach comes to reality,we have to make efforts to finely characterize components, their interfaces andconnectors. To this purpose, we propose to extend the component model of theMARTE GCM sub-profile to tackle issues presented in section 3. This workaims to improve analysis as it contributes to handle emergent behaviors relatedto implicit choices.

Designing Heterogeneous Component Based Systems 247

4.1 Core Principles

Today, design methodologies and environments integrating semantically distinctmodels are in high demand [4]. From study of section 2, we can state that, atsome level, hardware and software developments are quite similar: engineers haveto think in terms of data, computation, communication and architecture. Then,a system should be conceived as an understandable architecture of cooperatingagents which characteristics and interactions should be well understood undera certain Model of Computation (MoC). For instance, the rugby conceptualmodel [7] states that from specification to implementation, the complexity ofa system can be managed through several representations mainly characterizedby four axes: Computation represents relationship between the inputs and theoutput of the system: it can be captured for example by an Ordinary DifferentialEquation at high level or a Netlist at low level; Communication represents meansfor structural elements to exchange data: it can be a functional call at high levelor a complex bus at low level; Data represents information produced or consumedby structural elements: it can be abstract data types at high level or bit vectorsat low level; Time represents the causality of the system: it can be causal athigh level (succession of events) or clocked at low-level.

Modeling and analysis of complex systems, composing heterogeneous parts,requires taking into account each of those properties. In particular, we needto understand in what circumstances interactions between such heterogeneousparts can occur. According to [6], modeling explicitly MoCs characteristics hasseveral advantages: Faster specification development through usage of appropri-ate primitives and rules; Optimum simulation speed using a unified simulationengine instead of using multiple languages / frameworks; Useful properties : de-terminism, protection against deadlocks, introduction of non-determinism onlywhen needed; Feasible implementation flow through usage of a syntax which issemantically identifiable by compilation / synthesis tools.

Besides, in [5], authors identify two kinds of specification / integration ofMoCs. The first one, called horizontal heterogeneity, refers to the ability to in-tegrate a component among others on the same level of abstraction. The secondone, called vertical heterogeneity, is mainly related to refinements of componentsbetween several levels of abstraction and requires transformations.

The next section presents the main concept of our extension to address mod-eling of heterogeneity for RTES design and analysis.

4.2 Main Concepts

Complex ports. In order to tackle issues related to ports presented in theprevious section, we introduce the notion of “complex port” in the GCM MARTEsub-profile. This notion refines the UML port in order to support structuraldecomposition as well as behavioral specification. A complex port conforms to a“port specification” which defines its structural and behavioral features (figure1). Its usage serves several purposes.

248 A. Koudri et al.

Fig. 1. Refinement of MARTE GCM Port Definition

Fig. 2. Ports Group definition

First of all, building large hierarchical systems often requires gathering portsinto groups to favor readability and reusability. For instance, figure 2 shows asimple concrete example of complex port usage extracted from OCP/IP specifi-cation [1]. We can see in this figure how a complex port can be used to gather aset of ports into a reusable element. We can also notice that such representationimproves the readability of the models. Regarding the issues presented above,this first example shows how our proposition contributes to tackle issue 13178.

Another benefit of this proposition is to be able to explicit the way requests/ flows must be handled. Indeed, a port specification can contain definition ofspecific data structures and behaviors required to implement a protocol (usingprotocol state machines for example) in case of client / server ports, or to spec-ify how received data are transformed in case of flow ports. Then, the property“isLightweight” indicates whether the port has to perform some computation onreceived data / requests. Setting this property to “false” implies for the port: thespecification of discrete or continuous behavior; the specification of both external/ internal interfaces, e.g. what is provided / required to / from respectively thecontext and the nested elements of the component. External and internal inter-faces of a port represent two subsets of its nested ports. The first one (externalinterface) contains ports that are externally visible features (isService=true),while the second one are only internally visible features (isService=false).

Designing Heterogeneous Component Based Systems 249

Fig. 3. Specifying junction ports

The figure 3 shows a simple concrete example from a “Software Defined Radio”application where there is a need to specify that incoming signals are mixedbefore being processed by the signal processing chain. The ports specification ofthis figure defines actually a junction port where signals mixing occur.

In software domain, one could use for example port specification to storearrival requests (possibly with a timeout) until they are consumed by nestedbehavior(s). We can see that, in this case, our proposition contributes to givean answer to issues 10597, 15290, 10047, 12156, 13179 and 15076. Additionally,complex ports decomposition allows mixing both services and data-flows ports inan explicit way, which contributes to give an answer to issues 10059 and 12269.

Finally, our proposition addresses also the routing issue, e.g. how a request /flow is propagated to /from the component in case of multiple choices? UML isnot clear on that point. We think that such decision is domain dependant andshould be explicitly captured in the model. The Routing Policy defined by theport tells whether to propagate the request to the first connector (routing=first),to any of those connector (routing=any) or to all connectors (routing=all). For afiner routing decision, one can use a complex connector defining a path betweeninternal and external interfaces.

Complex connectors. Introducing complex ports requires dedicated mecha-nisms to take into account hierarchy of complex ports. To this purpose, and toclarify inter-connections in UML, we introduce the notion of complex connector.

The figure 4 shows the abstract syntax of complex connector which extendsthe UML connector in order to reinforce its semantic and to provide syntacticfacilities to express multi-level nested connections.

In order to better explain introduced concepts, we distinguish three cases inthe following paragraphs: the first one clarifies connections in UML; the secondone deals with inter-connections of complex ports; the last one discusses usageof typed complex connectors.

250 A. Koudri et al.

Fig. 4. Refinement of MARTE GCM Connector Definition

To illustrate the first item, we will use an image processing application as ex-ample. We consider a piece of the Lucas-Kanade algorithm dedicated to tracking[8] presented in figure 5.

Fig. 5. Tracking System Data-Flow

In this figure, we can see that the algorithm takes as input a set of elevenimages which are distributed among 5 Gaussian Smoothing blocks. The resultingimages are then passed to 3 different blocks that perform spatial and temporalgradients to produce new images.

Designing Heterogeneous Component Based Systems 251

Fig. 6. Tracking System Model

To model this algorithm using UML composite structure and flow ports, wewould produce the diagram presented in figure 6. This diagram makes benefitsof syntactic facilities of UML to produce a concise model. Unfortunately, be-cause interpretation of cardinalities of both parts and ports between connectedelements is not clear in UML, it is quite impossible to infer the architecturepresented in figure 5 from the model of the figure 6.

Fig. 7. On richer connection specification

252 A. Koudri et al.

The figure 7 illustrates how our proposition addresses this problem. In theleft side of the figure, we can see how the delegation connector set betweenthe input port of the tracking system and the “gs” part should be interpreted.Such interpretation could be achieved in UML at the price of big efforts usingOCL constraints. In the right side of the figure, we can see the correspondingrepository view. A connector owns several connector ends which store relevantinformation on richer connection specification. More precisely, a connector ownsseveral connector ends that precise finely how related elements are connected.In this example, we can see that each connector end selects specific parts androles from respectively their partWithPort and role properties using value spec-ification. In this case, we have just used an index to select which parts and rolesare involved into the connection, but it could be any other discriminating factor(the best QoS for example). This simple example can also be applied to assemblyconnector as well as connectors related to service ports. This example shows howour proposition contributes to give an answer to issues 11333 and 15298.

To illustrate the second item, e.g. connection between complex ports, we usethe example of the figure 8 which shows a connection between an abstraction ofan ARM9 processor and an OCP-IP bus, both complying with OCP-IP standardspecification [1].

In this example, we aim to express connections between nested ports definedby ports specification. Using UML, we can connect only the first level of the porthierarchy. Thanks to our extension, it is possible to precise which “sub-ports”

Fig. 8. Connecting Complex Ports

Designing Heterogeneous Component Based Systems 253

are connected to each other. The upper part of this figure shows the connectionbetween two complex ports of the two parts of the hardware design. Using UMLconnectors cannot fit the need to specify how the connector is refined throughport decomposition. Then, the middle part of the figure shows in more detailshow a complex connector can be used to achieve such refinement. For instance,we show in this figure that the connector contains two initial ends connectingthe first level of the ports hierarchy. The connector owns other connector endsthat define a path from initial ends. In this example, we can see that each initialend posses a reference (next end) to another connector end. Connector endsthat are leaf reference one or several opposite ends from which we can infer therefinement of the connector as shown in the lower part of the figure.

Fig. 9. Repository view

The model repository view presented in figure 9 shows that our propositionclarifies the specification of interconnections between nested ports. This figurefocuses on interconnections between sub-ports “sres” of the figure 8. Comparedto the RSM sub-profile of MARTE which allows only specification of regular pat-terns [3] in complex connections, our proposition is complementary as it allowsspecification of irregular patterns as well. We see through this small examplehow our proposition contributes to give a partial answer to issues 10474 and15079.

Regarding the last case, connectors must provide more detailed informationto precise finely how messages are conveyed between ports. According to theUML specification, a connector can be realized by a simple pointer as well asa complex network. In the latter case, a connector can be seen as a black boxinto which several kinds of operation can occur: dispatching, filtering, data cor-ruption, data transformation, etc. Then, in order to achieve realistic analysis,we must be able to specify such features for any complex connector. A UMLconnector can only be typed by an association, which represents a great limi-tation to model any behavioral feature required to model and analyze complex

254 A. Koudri et al.

communications. That is why we have introduced the notion of connector spec-ification to type connectors. A connector specification gathers a set of commonfeatures a family of connectors share. For example, the connector between the“Smoothing3” block and the three “Gradient” blocks of the figure 5 illustratessuch complex connector. In this example, each image produced by the “Smooth-ing” block is sent to “X-Gradient” and “Y-Gradient” blocks. Produced imagesare then queued because the “T-Gradient” block requires 5 images to perform acomputation. This kind of model corresponds actually to the Synchronous DataFlow MoC where production and consumption rates are well-known. As we can-not specify such connector using an UML association, the figure 10 shows howour proposition handles this issue.

Fig. 10. On richer connection specification

In this example, the specification of the connector is given by the “CS” classwhich defines one fifo to store incoming images and two behaviors triggered whennew images are ready to be processed. The first behavior copies the incomingimage into the fifo and the second one sends a block of five images to the “T-Gradient” block when the fifo is full.

Interface realization and usage. We have seen in section 3 that InterfaceBased Programming is the support of the replaceability in context. An inter-face defines common features a set of components should provide to be usedindifferently. This suggests that there exists somehow a matching between thefeatures an interface exposes and the visible features of the implementing com-ponent. In current approaches, such matching is implicit and consists usuallyin name matching. We have seen in section 2 that, among existing CBD ap-proaches, there are several level of conformance between an interface and itsimplementations (syntactic, structural or behavioral). In this paper, we distin-guish between three incremental levels of conformity: Structural conformity: a

Designing Heterogeneous Component Based Systems 255

component is replaceable if it has compatible properties; Behavioral conformity:a component is replaceable if it has compatible properties and behaviors (exam-ple: protocol); Non-functional conformity: a component is replaceable if it hascompatible properties and behaviors, and it provides the same non-functionalproperties (example: latency).

Using UML, one can specify that a classifier realizes an interface using the In-terface Realization direct relationship. This relationship references the contractand the implementing classifier. Thus, the metamodel assumes only a syntacticconformance since no additional information is given about the level of confor-mance and the way the implementing classifier implements / uses effectively acontract. In RTES, this situation is not acceptable as RTES requires more thana syntactic conformity to allow replacement of a component by one another. Wepropose then to refine both interface realization and usage.

Fig. 11. Refinement of MARTE GCM Interface Definition

Figure 11 presents the abstract syntax of our proposition which is illustratedthrough the example of the figure 12 taken from the Lucas-Kanade algorithmmentioned above. The left side of the figure 12 tells that the “IMultiplier” blockconforms to the “IMultIface” interface, although the signatures of its propertiesare not the same either in name or in cardinality. In this case, syntactic con-formance does not work. Then, we need additional information in the interfacerealization link to specify how the implementing block actually realizes its inter-face. We need to express a fine mapping between the properties of the interfaces

256 A. Koudri et al.

and the ones of the block. The right side of the figure shows the model repositoryview focusing on the feature mapping between property “img1” of the interfaceand the port “itxy[0]” of the block.

Fig. 12. Example of interface realization

Besides, finer mappings can be expressed using a mapping expression in thefeature mapping. For instance, one could split a single property into two distinctproperties. For example, we could imagine an unsigned integer property codedinto 32 bits (uint < 32 >) mapped into two unsigned integer ports coded into 16bits (uint < 16 >) for both Most Significant Bits (MSB) and Least SignificantBits (LSB) parts of the property.

We see through this simple example that our proposition contributes to clarifyinterfaces usage and realization. Moreover, such specification can be used toautomate generation of wrappers or complex connectors facilitating COTS IPintegration.

5 Conclusion

Component Oriented Modeling offers several advantages: It is an interface-basedapproach providing loosely-coupled specifications and favoring better reuse; Itprovides high level services for NFP (Non-Functional Properties) support; Itprovides a better support of allocation. Actually, those assumptions are trueonly if the semantics of components and composition of heterogeneous systemsare clearly and unambiguously defined.

In this paper, we have presented a small survey on component based ap-proaches from several domains. From this survey, we have extracted commondenominators in order to propose a generic approach that encompasses designand analysis of heterogeneous real-time systems. This proposition aims to givea practical answer to issues raised by the OMG and contributes to reinforce thesemantics of real-time components and composition in the UML for MARTEprofile.

Designing Heterogeneous Component Based Systems 257

Beyond UML for MARTE, this work can be generalized to the componentmodel of UML. This work contributes also to explicit the various models ofcomputation and communication of real-time embedded systems. It allows theestablishment of libraries of reusable and configurable ports and connectors.Future works will have to take into account system validation through verticalrefinements of components as well as support of behavioral and non-functionalconformity in order to enable component replaceability in context. This work ispartially founded by the VERDE project (http://www.itea-verde.org/).

References

1. Open core protocol specification2. Crnkovic, I., Chaudron, M., Sentilles, S., Vulgarakis, A.: A classification frame-

work for component models. In: Proceedings of the 7th Conference on SoftwareEngineering and Practice in Sweden (October 2007)

3. Cuccuru, A., Dekeyser, J.-L., Marquet, P., Boulet, P.: Towards UML 2 extensionsfor compact modeling of regular complex topologies. In: Briand, L.C., Williams, C.(eds.) MoDELS 2005. LNCS, vol. 3713, pp. 445–459. Springer, Heidelberg (2005)

4. Eker, J., Janneck, J., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Sachs, S., Xiong,Y.: Taming heterogeneity - the ptolemy approach. Proceedings of the IEEE 91(1),127–144 (2003), http://chess.eecs.berkeley.edu/pubs/488.html

5. Herrera, F., Villar, E.: A framework for heterogeneous specification and designof electronic embedded systems in systemc. ACM Trans. Des. Autom. Electron.Syst. 12(3), 1–31 (2007)

6. Jantsch, A.: Modeling Embedded Systems and SoCs. Morgan Kaufmann, San Fran-cisco (2004)

7. Jantsch, A., Kumar, S., Hemani, A.: A metamodel for studying concepts in elec-tronic system design. IEEE Des. Test 17(3), 78–85 (2000)

8. Mahalingam, V., Bhattacharya, K., Ranganathan, N., Chakravarthula, H., Mur-phy, R.R., Pratt, K.S.: A vlsi architecture and algorithm for lucas-kanade-basedoptical flow computation. IEEE Trans. Very Large Scale Integr. Syst. 18(1), 29–38(2010)

9. Medvidovic, N., Taylor, R.N.: A classification and comparison framework for soft-ware architecture description languages. IEEE Trans. Softw. Eng. 26(1), 70–93(2000)

10. OMG: Omg unified modeling languagetm (omg uml) superstructure (v2.3). Tech.rep., OMG (2010)

11. OMG: Sysml 1.1. Tech. rep., OMG (2010)12. OMG: Uml for marte 1.0. Tech. rep., OMG (2010)13. Shaw, M., Garlan, D.: Characteristics of higher-level languages for software archi-

tecture. Tech. rep., Carnegie Mellon Univ. (1994)14. Wang, A.J.A., Qian, K.: Component-Oriented Programming. Wiley, Chichester

(2005)