Top Banner
Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of Computer Science, McGill University Montreal, Canada [email protected], [email protected] Jacques Klein Laboratory of Advanced Software Systems University of Luxembourg, Luxembourg [email protected] ABSTRACT Multi-view modeling allows a developer to describe a soft- ware system from multiple points of view, e.g. structural and behavioral, using different modeling notations. Aspect- oriented modeling techniques have been proposed to address the scalability problem within individual modeling nota- tions. This paper presents RAM, an aspect-oriented mod- eling approach that provides scalable multi-view modeling. RAM allows the modeler to define stand-alone reusable as- pect models using 3 modeling notations. The aspect models support the modeling of structure (using UML class dia- grams) and behavior (using UML state and sequence dia- grams). RAM supports aspect dependency chains, which al- lows an aspect providing complex functionality to reuse the functionality provided by other aspects. The RAM weaver can create woven views of the composed model for debug- ging, simulation or code generation purpose, as well as per- form consistency checks during the weaving and on the wo- ven model to detect inconsistencies of the composition. Categories and Subject Descriptors D.2.2 [Software: Design Tools and Techniques]: Keywords aspect-oriented modeling, class diagrams, sequence diagrams, state diagrams, aspect dependencies, instantiation, binding 1. INTRODUCTION Multi-view modeling allows a developer to describe a sys- tem under development from multiple points of view, e.g. structural and behavioral, using different modeling nota- tions. As a result, the developer can use the modeling nota- tion that is most appropriate to describe the individual rel- evant facets of the system under development. In practice, multi-view modeling faces two important challenges: scala- bility and consistency. Models of complex applications tend to grow in size, to a point where even individual views are not readily understood anymore. Keeping different views of Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00. a system consistent is also challenging for the developer, and even sophisticated tools face algorithmic challenges when at- tempting to analyze models of considerable size. Aspect-oriented techniques have been successfully used to identify and separate crosscutting concerns, which al- lows a developer to reason about each concern individually. Aspect-orientation also draws special attention to the com- position of concerns, which allows the developer to focus on the intricacies of concern interactions and conflicts. Aspect- orientation therefore has the potential to address the scala- bility and consistency issues in multi-view modeling. Existing aspect-oriented modeling (AOM) approaches have mostly focussed on separation and composition of models within the same modeling notation, e.g., within class di- agrams, sequence diagrams, state diagrams, SDL, live se- quence charts, etc. [1]. In the context of multi-view mod- eling, these existing techniques can be applied within indi- vidual views to achieve scalability. Unfortunately doing so makes guaranteeing consistency between views even harder, since each AOM approach defines its own way of model weaving or model composition. This paper presents Reusable Aspect Models (RAM), an aspect-oriented multi-view modeling approach that 1) inte- grates existing class diagram, sequence diagram and state diagram AOM techniques into one coherent approach; 2) packages aspect models for easy and flexible reuse; 3) sup- ports the creation of elaborate aspect dependency chains; 4) performs elaborate consistency checks to verify correct aspect composition and reuse; 5) defines a detailed weav- ing algorithm that resolves aspect dependencies to generate independent aspect models and ultimately the final applica- tion model 1 . The rest of the paper is structured as follows. Section 2 presents the AOM techniques that RAM is based on. Sec- tion 3 introduces the core concepts of RAM. Section 4 shows how we applied RAM to the AspectOptima case study. Sec- tion 5 presents related work and the last section draw some conclusions. 2. AOM BACKGROUND This section briefly introduces the class diagram, sequence diagram and state diagram weaving approaches that our reusable aspect model approach is based on. 2.1 Composition of Class Diagrams The symmetric model composition technique proposed by 1 An initial version of RAM addressing only class and se- quence diagrams has been introduced in [18].
12

Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

Aug 29, 2019

Download

Documents

duongdien
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

Aspect-Oriented Multi-View Modeling

Jörg Kienzle, Wisam Al AbedSchool of Computer Science, McGill University

Montreal, [email protected],

[email protected]

Jacques KleinLaboratory of Advanced Software Systems

University of Luxembourg, [email protected]

ABSTRACTMulti-view modeling allows a developer to describe a soft-ware system from multiple points of view, e.g. structuraland behavioral, using di!erent modeling notations. Aspect-oriented modeling techniques have been proposed to addressthe scalability problem within individual modeling nota-tions. This paper presents RAM, an aspect-oriented mod-eling approach that provides scalable multi-view modeling.RAM allows the modeler to define stand-alone reusable as-pect models using 3 modeling notations. The aspect modelssupport the modeling of structure (using UML class dia-grams) and behavior (using UML state and sequence dia-grams). RAM supports aspect dependency chains, which al-lows an aspect providing complex functionality to reuse thefunctionality provided by other aspects. The RAM weavercan create woven views of the composed model for debug-ging, simulation or code generation purpose, as well as per-form consistency checks during the weaving and on the wo-ven model to detect inconsistencies of the composition.

Categories and Subject DescriptorsD.2.2 [Software: Design Tools and Techniques]:

Keywordsaspect-oriented modeling, class diagrams, sequence diagrams,state diagrams, aspect dependencies, instantiation, binding

1. INTRODUCTIONMulti-view modeling allows a developer to describe a sys-

tem under development from multiple points of view, e.g.structural and behavioral, using di!erent modeling nota-tions. As a result, the developer can use the modeling nota-tion that is most appropriate to describe the individual rel-evant facets of the system under development. In practice,multi-view modeling faces two important challenges: scala-bility and consistency. Models of complex applications tendto grow in size, to a point where even individual views arenot readily understood anymore. Keeping di!erent views of

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.

a system consistent is also challenging for the developer, andeven sophisticated tools face algorithmic challenges when at-tempting to analyze models of considerable size.

Aspect-oriented techniques have been successfully usedto identify and separate crosscutting concerns, which al-lows a developer to reason about each concern individually.Aspect-orientation also draws special attention to the com-position of concerns, which allows the developer to focus onthe intricacies of concern interactions and conflicts. Aspect-orientation therefore has the potential to address the scala-bility and consistency issues in multi-view modeling.

Existing aspect-oriented modeling (AOM) approaches havemostly focussed on separation and composition of modelswithin the same modeling notation, e.g., within class di-agrams, sequence diagrams, state diagrams, SDL, live se-quence charts, etc. [1]. In the context of multi-view mod-eling, these existing techniques can be applied within indi-vidual views to achieve scalability. Unfortunately doing somakes guaranteeing consistency between views even harder,since each AOM approach defines its own way of modelweaving or model composition.

This paper presents Reusable Aspect Models (RAM), anaspect-oriented multi-view modeling approach that 1) inte-grates existing class diagram, sequence diagram and statediagram AOM techniques into one coherent approach; 2)packages aspect models for easy and flexible reuse; 3) sup-ports the creation of elaborate aspect dependency chains;4) performs elaborate consistency checks to verify correctaspect composition and reuse; 5) defines a detailed weav-ing algorithm that resolves aspect dependencies to generateindependent aspect models and ultimately the final applica-tion model1.

The rest of the paper is structured as follows. Section 2presents the AOM techniques that RAM is based on. Sec-tion 3 introduces the core concepts of RAM. Section 4 showshow we applied RAM to the AspectOptima case study. Sec-tion 5 presents related work and the last section draw someconclusions.

2. AOM BACKGROUNDThis section briefly introduces the class diagram, sequence

diagram and state diagram weaving approaches that ourreusable aspect model approach is based on.

2.1 Composition of Class DiagramsThe symmetric model composition technique proposed by

1An initial version of RAM addressing only class and se-quence diagrams has been introduced in [18].

Page 2: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

+ addToStream()!

FileStream

fstream

+ addToStream()!

FileStream

bfstream

+ start()!

System

+ write()!

Buffer

buffer

+ writeLine()!

Writer

Base CDContext-SpecificBuffering Aspect

+ writeLine()!

Writer

+ addToStream()!

FileStream

+ start()!

System

bfstream

+ write()!

Buffer

buffer

Result

+ writeLine()!

Writer

fstream!!!!

Figure 1: Merging Class Diagrams with Kompose

France et al. [10, 20] supports composition of model el-ements that present di!erent views of the same concept.This composition technique has been implemented in a toolcalled Kompose [9, 2]. The model elements to be composedmust be of the same syntactic type, that is, they must beinstances of the same meta model class. An aspect viewmay also describe a concept that is not present in a targetmodel, and vice versa. In these cases, the model elementsare included in the composed model.

The process of identifying model elements to compose iscalled element matching. To support automated elementmatching, each element type (i.e., the element’s meta-modelclass) is associated with a signature type that determines theuniqueness of elements in the type space: two elements withequivalent signatures represent the same concept and thusare composed. Currently, Kompose focuses mainly on themerging of class diagrams.

Fig. 1 shows an example of class diagram composition(taken from [20]) using Kompose. In the example, a mod-eler creates a target model in which an output producer(an instance of Writer) sends outputs directly to the out-put device to which it is linked (instance of FileStream).The modeler then decides to incorporate a bu!ering featureinto the model by composing a bu!ering aspect model. Theaspect model describes how entities that produce outputs(represented by instantiations of Bu!er) are decoupled fromoutput devices through the use of bu!ers. The result of thecomposition is the class diagram entitled Composed Class di-agram where the model elements with the same name havebeen merged. Note that France et al. also propose a lan-guage of directives to modify the models before and after thecomposition step. This language is useful to adapt a genericaspect model to a specific target model or to improve thecomposed model.

2.2 Weaving of State and Sequence DiagramsIn RAM we use the state and sequence diagram weav-

ing technique provided by GeKo [19] (Generic weaving withKermeta), a generic model weaver that can easily be usedto weave any kind of models. In GeKo, an aspect is definedas a pair of models. For instance, if we want to weave anaspect state diagram into a target state diagram, the aspectstate diagram is composed of a pair of state diagrams: onestate diagram for the pointcut (specification of the behav-ior to detect), and the other state diagram for an advicerepresenting the expected behavior at the join point. Simi-

: User : Server

login()

Base SD

tryAgain()

login()

alt loggedIn()

rejected()

*

: User : Server

login()

Pointcut

: User : Server

login()

*

Advice

!

notify()

: Display

update()

: User : Server

login()

tryAgain()

Result SD

!

notify()

: Display

update()

login()

alt loggedIn()!

notify()

update()

rejected()!

notify()

update()

Figure 2: Sequence Diagram Weaving Examplelar to AspectJ, where an aspectual behavior can be inserted’around ’, ’before’ or ’after ’ a join point, an advice in theGeKo weaving approach may extend the matched behavior,replace it with a new behavior, or remove it entirely.

GeKo defines a two-phased process weaving: 1) a genericdetection where the pointcut is used to determine all thejoin points in the target model and 2) a generic compositionmechanism where the advice model is composed with thetarget model at the join points previously detected.

An example of the use of GeKo is illustrated on sequencediagrams in Fig. 2. The base/target sequence diagram showsa possible interaction sequence between a user and a server.The user first sends a login message to the server. Theserver answers with tryAgain and the user performs a newattempt. The sequence diagram then shows an alt compart-ment that describes what messages are sent next, dependingon whether the login succeeds or fails.

The aspect specified in Fig. 2 consists of a pointcut and anadvice. The pointcut states that any message exchange be-tween a user and a server starting with the message login isof interest. Note that in the specification of the pointcut, itis possible to use regular expressions on the message names:a message labeled with a * means that any message froma server to a user is of interest. The advice states that amessage notify and a message update on an object of typeDisplay are to be added after the return message from theserver. The result of the weaving is shown on the right handside of Fig. 2.3. REUSABLE ASPECT MODELS

This section describes the core concepts of RAM. Beforegoing into details, it is important to define what we call anaspect. In our approach, any concern or functionality that isreusable is modeled as an aspect. Even if an aspect is onlyused once in the same application, it is (or can be) reusedagain in other applications. Therefore, the structure andbehavior models of a reusable aspect cut across the modelsof the application(s) in which the aspect is reused.

3.1 Aspect Packaging - Grouping Structure,State and Message Behavior

In RAM, the model of a concern or functionality containsup to 3 di!erent kinds of views – a structural view, stateviews and message views – which are grouped together inan aspect model, a special UML package.Structural View. The structural view is the first compart-ment of the aspect model. It is expressed using a UML class

Page 3: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

aspect Copyable

+ |Copyable clone()- |Copyable create()+ replaceStateWith(|Copyable from)

!

|Copyable

|caller: |Caller |original: |Copyable

|copy: |Copyable

|copy := clone()

|copy := create()

replaceStateWith(|original)

structural view

message view clone

|caller: |Caller |original: |Copyable

|copy := clone()

Pointcut Advice|original, |copy|Caller, |caller

|Copyable

state view |Copyable Pointcut

|CloneAllowed

Advice

|ReplaceAllowed

replaceStateWith |CloneAllowed|ReplaceAllowed|ReplaceAllowed |CloneAllowed

clone

Figure 3: The Copyable Aspect Model

diagram, and therefore contains classes with attributes andmethods, and associations that relate the classes. Publicmethods, i.e. methods that can be used from outside theaspect package, should be annotated with the “+” charac-ter. The classes in the structural view do not necessarilyhave to be complete, i.e., they only need to specify the at-tributes, methods and associations that are relevant withinthe concern that is modeled. The classes may later be com-posed by the weaver with other classes when the aspect isinstantiated or bound to a base model (see subsection 3.2for details on instantiation and binding) to yield a completeclass. Incomplete classes, i.e. entities that are not directlyor indirectly bound to model elements of some other aspectmodel, and methods whose name and signature are yet tobe determined, are termed mandatory instantiation param-eters. Mandatory instantiation parameters are identified byprepending a “|” character to their name, and have to berendered prominent by depicting them as UML templateparameters on the right hand side of the structural viewcompartment.

Fig. 3 defines an aspect called Copyable that provides thefunctionality of making identical copies of objects, often alsocalled cloning. The structural view defines one incompleteclass named |Copyable with one public method called clonethat provides the cloning functionality. |Copyable is desig-nated as a mandatory instantiation parameter of the struc-tural view and hence shows up as a UML template param-eter.State View. In the aspect package, the structural compart-ment is followed by several state view compartments, onefor each class (complete or incomplete) defined in the struc-tural view. Using a UML state diagram, the state view ofan entity describes the internal states of that entity that arerelevant within the concern. A state is relevant if it a!ectsthe messages that the entity is capable of processing. InUML terms, the state view compartment describes the us-age protocol of the entity. To be complete, the state diagrammust contain each method defined in the structural view forthe entity at least once.

When a state view describes the protocol of a standardclass defined in the structural view, it takes the form of astandard state diagram. For incomplete classes, however, anaspect state diagram has to be defined. An aspect state di-agram consists of two parts: a pointcut and an advice. Thepointcut defines the states and transitions that have to ex-ist in the target state diagram, i.e. the state diagram with

which the aspect state diagram is composed. The advicepart defines the (refined) state diagram that replaces theoccurrence of the pointcut in the target state diagram. Justlike in the structural view, states that are not directly or in-directly bound to states defined in a standard state diagramare mandatory instantiation parameters of the state viewcompartment, highlighted by prepending a “|” character totheir name and emphasized as UML template parameterson the right hand side of the compartment.

The Copyable aspect in Fig. 3 only has one state viewsince the structural view only defines one entity. This entitybeing a mandatory instantiation parameter (and thereforean incomplete class), the state view takes the form of anaspect state diagram. The pointcut in the state view statesthat there are two relevant states within the Copyable as-pect. The advice states that the relevant states are the statesin which a call to clone or replaceStateWith are possible.The states |CloneAllowed and |ReplaceAllowed are desig-nated mandatory instantiation parameters of the state view,meaning that they have to eventually be mapped to statesin a standard state diagram using instantiation.Message View. After the state view compartments, the as-pect package contains message view compartments, at mostone for each public method defined in the structural view.Each message view describes, using a UML sequence dia-gram, the sequencing of message interchanges that occurbetween entities when providing the functionality o!ered bythe public method. Hence, if the functionality does not in-volve any message exchanges, but only computation internalto the entity, no message view compartment is shown forthat method.

A message view compartment contains an aspect sequencediagram, which again has two parts: a pointcut and anadvice. The pointcut defines the entities and message ex-changes that have to exist in the target sequence diagram,whereas the advice specifies the sequence diagram that re-places the occurrence of the pointcut in the target diagram.Typically, for standard methods, the pointcut shows a tem-plate caller that calls the method on a template instance ofthe entity that defines the method. The advice then showsthe details of the execution of that method. Nevertheless, inspecial cases, the pointcut can represent more complex be-haviors, e.g., sequences of messages between several objects.In these cases, the advice shows how additional messagesare added to the behavior specified in the pointcut or evenhow the matched messages are replaced.

Page 4: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

aspect Checkpointable depends on Copyable

+ establish()+ restore()+ discard()

!int level|Checkpointable

|caller: |Caller |target: |Checkpointable myStack: Stack

establish()

push(newCheckpoint)

structural view depends on Copyable

message view establish depends on Copyable

|caller: |Caller |target: |Checkpointable

establish()

Pointcut Advice

+ push(|Checkpointable e)+ |Checkpointable getLast()+ discardLast()

!

Stack

1

myStack

0..*

!

!!! newCheckpoint := clone()

Copyable.clone instantiation

clone.|original !|target

clone.|copy ! newCheckpoint

clone.|Caller !|Checkpointable

clone.|caller !|target

|target|Caller, |caller

|Checkpointable

Copyable instantiation

Copyable.|Copyable !|Checkpointable

(1)(2)(3)(4)

state view |Checkpointable depends on Copyable

Pointcut Advice

Any CheckpointingAllowed

Any Ready

establish/level++ establish/level++

restore/level--

Established

discard/level--

Copyable.|Copyable instantiation|Copyable.|CloneAllowed

! Established|Copyable.|RemoveAllowed

! Ready

|Any

restore[level>0]/level--

discard[level>0]/level--

restore and discard skipped for space reasons...

Figure 4: The Checkpointable Aspect Depends On Copyable

The Copyable aspect has two public methods, but only theclone method involves message exchanges between objects.This is the reason why Fig. 3 only contains one message view.Since the sequencing defined in the clone message view islikely to be reused many times, potentially with di!erenttarget objects, caller instances and classes, and return refer-ences, the message view defines 4 mandatory instantiationparameters.

3.2 Aspect Dependencies and Reuse - Bindingand Instantiation

One of the goals of our approach is to address the scala-bility problem of multi-view modeling. To keep our aspectmodels reasonably small, aspects providing complex func-tionality have to be able to reuse simpler functionality pro-vided by other aspects. If an aspect A reuses models pro-vided by an aspect B, then A depends on B. Dependencieshave to be listed in the heading of an aspect package.

Fig. 4 describes the aspect Checkpointable that providesobjects with the functionality to establish, restore and dis-card checkpoints of their state. To do that, it depends onthe clone and replaceStateWith functionality provided byCopyable. Therefore, the Checkpointable aspect has to de-clare the dependency on Copyable in the aspect packageheading.Instantiation. In the RAM approach, if A depends on B, Aexplicitly states that it reuses the functionality provided byB by instantiating B, one or several times, if needed. Withinthe structural view, A must provide at least one instantia-tion directive that maps at least all mandatory instantiationparameters from B’s structural view to entities in A’s struc-tural view. Classes in B that are not designated manda-tory instantiation parameters can be instantiated, but donot need to be. For each incomplete class Y (or |Y) of Bthat is merged with an entity X (or |X) of A, A must alsomap all mandatory template states from B’s state view ofY to states in A’s state view of X using an instantiation

directive in the state view X. Finally, all mandatory tem-plate parameters from B’s message views that are reusedwithin one of A’s message views have to be mapped to thecorresponding entities with one or multiple instantiation di-rectives in A’s message views2. The instantiation directivefor one template parameter is of the form:SourceAspect.IncompleteEntityName ! EntityName3

Fig. 4 illustrates how the Checkpointable aspect can reusethe functionality o!ered by Copyable. First, the structuralview of Copyable is instantiated into the structural view ofCheckpointable by mapping the |Copyable incomplete classto the |Checkpointable incomplete class. The semantics ofthis is the following: all instances of |Checkpointable, inaddition to providing the establish, restore and discardmethods also provide the methods, attributes and associa-tions defined by |Copyable. The |Checkpointable state viewspecifies that an instance of the incomplete |Checkpointableclass accepts any number of calls to establish followed by atmost the same number of calls to restore or discard. Theinstantiation that maps |CloneAllowed to Established en-sures that clone can only be called after a call to establish.Likewise, replaceStateWith can only be called after a callto restore or discard. Finally, the instantiation directivein the message view establish illustrates how the messag-ing specified in the message view clone can be reused. Bymapping both |caller and |original to |target, |Callerto |Checkpointable, and the |copy return parameter tonewCheckpoint, the weaver elegantly inserts the messagesequencing specified in the clone message view into the es-tablish message view at the point where the |target objectinvokes clone on itself. Note that since the message viewclone is an aspect sequence diagram, if the method clonewould have appeared several times in the establish mes-

2In case of multiple instantiations within the same state ormessage view, increasing numbers specify the order in whichthe instantiations shall be performed by the weaver.3Of the model where the instantiation is located.

Page 5: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

sage view on the |target object, then the message sequenc-ing specified in the clone message view would have beenwoven several times into the establish message view.

Binding. In the case where an aspect A depends on an as-pect B, it can happen that an incomplete class X (or |X)in the structural view of an aspect A needs to be composedwith a complete class Y defined in B (or in one of the as-pects that B depends on). In this case, the state view X inA might also need to refine the state view Y in order to takeinto account the functionality of A. Likewise, A might needto refine or override the message sequencing specified in amessage view of the aspect that defines Y to take into ac-count the functionality provided by A. In this case, A has todefine a binding directive that maps the incomplete entitiesof A’s structural view, state view or message view into thestructural view, state view or message view of the aspectdefining Y. The binding directive syntax for one templateparameter is as follows:IncompleteEntityName4 ! Target.EntityNameWhenever a view contains a binding directive, the bound

model elements cannot appear at the same time as manda-tory instantiation parameters of the view. This makes per-fect sense: since there are binding directives that tell theweaver how to map the incomplete model elements to com-plete model elements, instantiation directives that specifythe mapping are not mandatory anymore.

Instantiations and binding directives can be one-to-manyor many-to-one, if needed. In this case, wild cards can beused as a shortcut to instruct the weaver to perform patternmatching on model elements at weave time to determine theset of model elements that are to be used in the directive.

Reuse. One of the main goals of RAM is to allow the mod-eler to design highly reusable aspect models. Reusability isat the very heart of aspect-oriented modeling: it should bepossible to reuse an aspect providing a simple functional-ity within a base model or an aspect model that providesa more complex functionality whenever and wherever thesimple functionality is needed, thus preventing scattering ofmodel elements providing related functionality, and tanglingof model elements providing di!erent functionalities.

To make reuse possible, it is important that instantiationsand bindings observe strict rules: if an aspect A providesa functionality whose design needs a simpler functionalityprovided by an aspect B, then A depends on B. In this case,and only then, A is allowed to instantiate views of B, or bindA’s model elements to model elements defined in B. Circulardependencies are forbidden.

If these simple rules are followed, individual reuse of as-pects is possible. In our example where A depends on B, itis possible to reuse B in isolation, or reuse A (which impliesthat indirectly B is also reused). Indirect dependencies ofaspects are hidden from the user of an aspect: when a de-veloper reuses A by instantiating it, the weaver takes careof all the indirect instantiations and bindings.

To fully exploit the benefits of reuse, aspect dependenciesshould be kept unresolved until the aspects are woven withthe final application model. Only then the full potential ofreuse is achieved: if A depends on B, then a change that ismade to B is automatically propagated to A.

4Of the model where the binding is located.

aspect Z

aspect A

aspect Bi

aspect Ci

aspect B!!!i-1 aspect B!!!i+1

aspect C!!!i-1 aspect C!!!i+1

... ...

... ...

Figure 5: Aspect Dependencies

3.3 Aspect WeavingBefore an aspect A that depends on other aspects can suc-

cessfully be woven with a base application model or reusedin another aspect, the weaver first has to create an indepen-dent model of A, i.e. an aspect model that contains all thestructural entities, states and message exchanges defined inthe aspects it depends on. In general, an aspect A can havecomplex dependencies in form of a directed acyclic graph(DAG). In oder to resolve these complex dependencies, ourweaving algorithm is recursive. It processes the DAG step bystep in depth-first order. A weaving step is always executedon a pair of aspects: if A depends on B, then B is wovenwith A in order to yield a model of A that is independentof B. The weaving directives are obtained by combining theinstantiation and binding directives.

In order to formally describe the weaving algorithm, weneed the following definitions:

• The higher aspect set of an aspect A is composed ofthe aspects that (directly or indirectly) depend on A.

• The dependency set of an aspect A is composed of allthe aspects that A directly or indirectly depends on.

• The direct dependency set of an aspect A is composedof all the aspects that A depends on directly.

• The indirect dependency set of an aspect A is com-posed of all the aspects that are in the dependency setof the aspects in the direct dependency set of A.

For example, in the context illustrated in Fig. 5, the higheraspect set of A includes Z, the dependency set of A includesall Bi and all Ci, the direct dependency set of A includes allBi (but not any Ci), and the indirect dependency set of Aincludes all Ci (but not any Bi).

When asking to create an independent aspect model ofA, Z provides as a parameter a set of binding directivesDhigher defined within Z (or the higher aspect set of Z) thatapply to aspects in the dependency set of A. To obtain anindependent aspect model of A conforming to these bindingdirectives, the weaving algorithm processes as follows:

Recursive Weaving AlgorithmInitialize the set of binding directives Dupdated to an empty

set. For each aspect Bi within the direct dependency set ofA perform the following 6 steps:

1. If there are binding directives defined in A that havethe same left hand side as a binding directive withinDhigher, perform a consistency check (as described insubsection 3.4), then discard the binding defined in A.

2. Assemble the set of binding directives Dlower to bepassed on to Bi. Dlower is composed of all bindingdirectives defined in A that bind into aspects withinthe dependency set of Bi and all binding directives inDhigher that apply to aspects within the dependencyset of Bi. For each binding directive in Dlower that

Page 6: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

on the left hand side of the binding refers to a modelelement X in A and for which A also defines an instan-tiation directive that maps a model element Y definedin Bi to X, apply the instantiation directive in the in-verse direction to the left hand side of the binding toobtain a binding directive that refers to Y. For exam-ple, assume that Dlower contains the directive A.X !C.Z, and A defines the instantiation B.Y ! X, thenapplying the instantion directive in the inverse direc-tion results in the new directive B.Y ! C.Z.

3. Create an independent aspect model of Bi (i.e. applythis algorithm recursively) using the binding directivesDlower. In addition to creating an independent aspectmodel of Bi, the recursive application of the algorithmproduces an updated list of bindings Dlower_updated,that now only contains bindings to model elements de-fined in Bi.

4. Assemble the set of binding directives Dweave. Dweave

is composed of A’s binding directives to Bi, if any, andany binding directives within Dlower_updated that bindfrom A to Bi. Remove the latter binding directivesfrom Dlower_updated.

5. Weave the views of the independent aspect model ofBi obtained in step 2 with the views of A as follows:

• For each view Y in Bi, apply A’s instantiationdirectives to the model elements of Y.

• For each view Y in Bi, apply the binding direc-tives Dweave to the model elements within Y.

• For each view X in A, weave the views Y in B thatX depends on with X using class diagram, statediagram or sequence diagram weaving techniques.

6. For each binding directives in Dlower_updated of step 4that on the right hand side binds to a model elementY in Bi and for which A also defines an instantiationdirective that maps Y to a model element X in A, applythe instantiation directive to the right hand side of thebinding to obtain a new binding that binds to X. Addthe obtained binding to Dupdated.

Now that the independent aspect model is created, addi-tional consistency checks are performed as described in sub-section 3.4. If no consistency violations are detected, returnthe aspect model and the set of binding directives Dupdated

to Z.Fig. 6 shows a simple example in which the above weaving

algorithm creates an independent aspect model of an aspectA that depends on B which in turn depends on C. First,an independent aspect model of B is created by weaving Cwith B according to the binding defined in B. Then, the in-dependent aspect model of A is created by weaving B with Aaccording to the instantiation and binding directives definedin A. For space reasons, only the structural view is shown.

3.4 Consistency ChecksIn multi-view modeling it is important to ensure that the

di!erent views are consistent with each other. In RAM con-sistency checks are performed at multiple levels.

The first level of consistency checks is performed withineach individual aspect model separately. Each class in thestructural view of an aspect model has to have a correspond-ing state view. The state view has to define the completeprotocol state diagram describing the acceptable sequencingof all the methods that the class declares in the structural

aspect B|Y1

+ my1()+ mz1()

!

|Y1+Z1

aspect A depends on B|X1

+ mx1()!

|X1

+ mx2()!

X2

B instantiation

B.|Y1 ! X3

B binding

X2 ! B.Y2

aspect B depends on C|Y1

+ my2()!

Y2

aspect A

aspect C

+ mx1()!

|X1

+ mx2()+ my2()

!

X2+Y2

+ mx3()+ my1()+ mz1()

!

X3+Y1+Z1

|X1

+ my2()!

Y2+ mx3()!

X3

+ my1()!

|Y1

C binding

|Y1 ! C.Z1

+ mz1()!

Z1

Figure 6: Structural Weaving Example

view. Any fields used in the state view diagram (e.g., levelin Fig. 4) have to be declared as attributes of the correspond-ing class in the structural view. For each public method ofa class in the structural view, the aspect model has to de-fine a corresponding message view. Finally, it is possible tocompare the behavior expressed in the message views andthe state views within each aspect model. For each objectlife line in a sequence diagram, the incoming messages tothat object are presented in sequence to the (partial) statediagram describing the protocol of the corresponding class.If the state diagram refuses a message, then the two viewsare inconsistent. This first level of check is not novel. Othermulti-view modeling approaches suggest similar checks.

The second level of consistency check is performed betweenaspect models by checking the adherence to the instantia-tion and binding rules. The weaver makes sure that when Ainstantiates B, all mandatory instantiation parameters aresupplied. Furthermore, the weaver ensures that the bind-ings in A conform to eventual bindings declared in B. Thischeck is performed during step 1 of the weaving algorithmsdescribed in section 3.3. For structural model elements, ifthe instantiation directive in A maps an entity Y in B to Xin A, then the binding in A has to map X to the same en-tity as the binding in B maps Y to. For states, the bindingin A must be a sub-binding of the binding in B. A bindingX ! S (or X ! "Si) is a sub-binding of a binding X ! T(or X ! "T ) if either S = T or S is a substate of T (or#Si$Ti(Si = Ti or Si is a substate of Ti)). This level of con-sistency check is novel. For message views, the binding in Amust map to the same or a subset of the objects used in thebinding defined in B. These conformance rules make surethat A reuses B correctly, i.e. that the expected operationconditions of the reused aspect B are preserved within A.

The last level of consistency checks is performed within theindependent aspect model and within the final base model,where the sequencing of message exchanges expressed in thefinal sequence diagram is checked against the final protocolstate machines in the same way in which it was done foreach individual aspect. For each object life line in the se-quence diagram, the incoming messages to that object arepresented in sequence to the state diagram describing theprotocol of the corresponding class. If the state diagram re-

Page 7: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

0..1

myContext

aspect Context

structural view

+ Context getContext()* setContext(Context)+ createAndEnterContext()+ leaveContext()

!

|ContextParticipant

0..1 participant

caller: Caller target:|ContextParticipant

newContext:Context

createAndEnterContext()newContext := create()

addParticipant(|target)

message view createAndEnterContext

caller: Caller target:|ContextParticipant

createAndEnterContext()

Pointcut

Advice

!

!!! setContext(newContext)

|ContextParticipant

|Idle |Working

createAndEnterContext

leaveContext

Pointcuts Advice

Any

getContext

|Idle |Working

createAndEnterContext

leaveContext

EnteringsetContext

LeavingsetContext

Idle Active

create

contextCompleted!!!!!!!!

addParticipant

removeParticipant

destroyCompleted

state view Context

+ Context create()+ destroy()+ addParticipant(|ContextParticipant p)+ removeParticipant(|ContextParticipant p)* contextCompleted()

!

Context

state view |ContextParticipant

Any

Binding

Any ! *

leaveContext skipped for space reasons...

Binding

caller ! *

Caller ! *

target ! *

|Idle, |Working

Figure 7: The Context Aspect Models

fuses a message, consistency is violated. This signals to thedeveloper that the instantiations and bindings (or the order-ing of the instantiations and bindings) of the state and mes-sage views contradict each other and have to be revisited.To our knowledge, no AOM approach has so far proposedsuch a powerful consistency check.

4. CASE STUDY: ASPECTOPTIMAAspectOptima [15, 14] is an aspect-oriented framework

providing customizable transaction support to applications.The current AspectJ implementation of AspectOptima [6]consists of 29 aspects that modularize and implement criticaltransaction system features in a reusable way. The aspectscan be combined in di!erent ways to create di!erent imple-mentations of transaction models, concurrency control andrecovery strategies.

To demonstrate the e!ectiveness of RAM, we applied ourapproach to model the design of parts of the AspectOptimaframework. The feature diagram model that specifies thepossible ways to build a transaction is shown in Fig. 8. Eachof the features has been modeled as one RAM aspect model.For space reasons we can not present all the aspect mod-els in this paper. We therefore concentrate on a subset ofthe aspects, in particular on Recovering. Recovering imple-ments the atomicity property of transactions, which statesthat either all the changes performed in a transaction arereflected in the application state, or none is, i.e., the appli-cation state is identical to the state that was valid beforethe transaction started. Recovery can be implemented intwo ways: based on a technique called in-place update andcheckpointing, or using deferred update. We will concen-trate on the checkpointing alternative. Recovering thereforedepends (directly or indirectly) on OutcomeAware, Check-pointing, Tracing, Checkpointable, Copyable, Traceable, Ac-cessClassified and Context. In the following subsections wepresent parts of these aspects, and then demonstrate how abase model can be woven with the Recovering aspect.

Optimistic Validation

Transaction

RecoveringNested

Deferring

2-Phase-Locking

CopyableContext

Traceable

AccessClassified LockableSemanticClassified

Shared

OutcomeAware

Checkpointing

TracingCheckpointable Deferrable

Legend

Mandatory

Optional

!

Alternative

Figure 8: Feature Diagram of AspectOptima

4.1 AspectOPTIMA AspectsContext. The Context aspect is one of the base aspects ofAspectOptima. A context are best described as an area ofcomputation. Contexts structure the execution of an appli-cation. They give identity to the set of operations executedby threads on objects over a given period of time in thepursuit of a goal. A transaction is an example of a contextthat exhibits additional properties, i.e., the Atomicity, Con-sistency, Isolation and Durability (ACID) properties [11].

The structural view of our RAM context model presentedin Fig. 7 defines a Context class, together with a permanentassociation to a (to be determined) |ContextParticipantclass. The createAndEnter message view describes the func-tionality that allows a context participant to instantiate acontext and add itself as a participant. The |ContextPartic-ipant state view shows that any class that wants to par-ticipate in a context must eventually follow each call tocreateAndEnter with a call to leaveContext. The Con-text state view describes the usage protocol of the Contextclass: it specifies, for instance, that in order to completethere must be no active participants.OutcomeAware. OutcomeAware shown in Fig. 9 extendsthe functionality o!ered by Context. According to the struc-

Page 8: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

|Working

aspect OutcomeAware depends on Context

structural view

+ Outcome getOutcome()+ setOutcome(Outcome o)

Outcome myOutcomeContextWithOutcome

|OutcomeControllingParticipant

message view createAndEnterContext is Context.createAndEnterContext

Context instantiation

Context.|ContextParticipant !|OutcomeControllingParticipant

+ createAndEnterContext()+ voteAndLeaveContext(Outcome vote)

!

|OutcomeControllingParticipant

caller: Caller target:|OutcomeControlling

ParticipantmyContext:

ContextWithOutcome

voteAndLeaveContext(o)

setOutcome(o)

caller: Caller target:|OutcomeControlling

Participant

voteAndLeaveContext(o)

Pointcut

!

myContext :=

getContext()

leaveContext()

Advice

Context.leaveContext instantiation

leaveContext.target ! target

leaveContext.Caller ! Caller

leaveContext.caller ! caller

Undecided

setOutcome

Any

getOutcomeContext binding

Undecided ! Context.Active

Decided ! Context.Active

Any ! Context.*

Pointcut Advice

Undecided

|Idle |Working

createAndEnterContext

voteAndLeaveContext

Pointcut

Advice

|Idle Busy

createAndEnterContext

!!!!!!!!!!!!!!!voteAndLeaveContext

VotingleaveContext

|Idle, |Working

Context.|ContextParticipant instantiation

|ContextParticipant.|Idle ! |Idle

|ContextParticipant.|Working ! |Working

DecidedDecided

Context binding

ContextWithOutcome !Context.Context

message view voteAndLeaveContext depends on Context

Any

state view ContextWithOutcome depends on Context

state view |OutcomeControllingPartcipant depends on Context

Binding

caller ! *

Caller ! *

target ! *

Figure 9: The OutcomeAware Aspect Model

opt [myContext != null]

aspect Checkpointing depends on Tracing, Checkpointable

caller:|Checkpointing

Participant

callee: |Checkpointed

structural view

caller:|Checkpointing

Participant

callee:|Checkpointed

m(..)

Pointcut Advice

+ * m(..)!

|Checkpointed

+ restoreCheckpoints()- contextCompleted

!

CheckpointingContext

!

!!! myContext := getContext()

myContext:CheckpointingContext

secondTime := wasModified(callee)

m(..)

opt [not secondTime]

establish()

Checkpointable.establish instantiation

establish.target ! callee

establish.Caller ! Caller

establish.caller ! caller

Tracing.traceMethod instantiation

traceMethod.caller ! caller

traceMethod.callee ! callee

traceMethod.m ! mTracing.wasModified instantiation

wasModified.target ! myContext

wasModified.Caller ! Caller

wasModified.caller ! caller

wasModified.result ! secondTime

message view checkpointMethod depends on Tracing, Checkpointable

|CheckpointingParticipant|Checkpointed

+ createAndEnterContext()+ leaveContext()

!

|CheckpointingParticipant

Checkpointable instantiation

Checkpointable.|Checkpointable !|Checkpointed

Tracing instantiation

Tracing.TracingContext !CheckpointingContext

Tracing.|TracingParticipant !|CheckpointingParticipant

Tracing.|Traced ! |Checkpointed

CheckpointingContext, |CheckpointingParticipant, |Checkpointed, enterAndCreateContext, leaveContext,contextCompleted, restoreCheckpoints skipped for space reasons...

Checkpointable binding

caller ! *

m !Checkpointable.+ * *(..)

Figure 10: The Checkpointing Aspect Model

Page 9: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

aspect Recovering depends OutcomeAware, Checkpointing

structural view

+ createAndEnterContext()+ voteAndLeaveContext()

!

|RecoveringParticipant|RecoveringParticipant

|Recoverable

OutcomeAware instantiation

OutcomeAware.ContextWithOutcome !RecoveringContext

OutcomeAware.|OutcomeControllingParticipant !|RecoveringParticipant

- contextCompleted()!

RecoveringContext

Checkpointing instantiation

Checkpointing.CheckpointingContext ! RecoveringContext

Checkpointing.|CheckpointingParticipant !|RecoveringParticipant

Checkpointing.|Checkpointed ! |Recoverable

+ * m(..)!

|Recoverable

message view prepareRecovery is Checkpointing.checkpointMethod

ActiveIdle

Pointcut

|Idle

|ActiveAdvice

BeforeVote AfterVote

Checkpointing.CheckpointingContext instantiation

CheckpointingContext.Active ! BeforeVote

CheckpointingContext.Idle ! Idle

CheckpointingContext.Completed ! Completed

CheckpointingContext.RestoreAllowed !Completed

Context binding

Active ! Context.Active

Idle ! Context.Idle

Completed ! Context.Completed

removeParticipantremoveParticipant

Completed

contextCompleted

|Completed

contextCompleted

OutcomeAware.ContextWithOutcome instantiation

ContextWithOutcome.Undecided ! BeforeVote

ContextWithOutcome.Decided ! AfterVote

state view RecoveringContext depends on CheckpointingContext, ContextWithOutcome

|RecoveringParticipant, |Recoverable, voteAndLeaveContext, contextCompleted skipped for space reasons...

Figure 11: The Recovering Aspect Model

tural view, a ContextWithOutcome has an outcome (positiveor negative), and o!ers operations to query or set the out-come. The state view shows that a context is first in anUndecided state, and then moves to a Decided state whenthe outcome of the context is set. An |OutcomeControlling-Participant must decide on the outcome of the contextwhen leaving by invoking the voteAndLeaveContext method.After setting the outcome, the voteAndLeaveContext mes-sage view reuses the leaveContext functionality providedby Context.

AccessClassified, Traceable and Tracing are not shown forspace reasons. Checkpointable and Copyable have alreadybeen presented in section 3.Checkpointing. Checkpointing shown in Fig. 10 makes surethat whenever a modifying operation is invoked on a Check-pointable object for the first time within the current con-text, a checkpoint is established. To do this, Checkpointingdepends on Tracing to keep track of the operations thatare invoked, and on Checkpointable to establish the actualsnapshot of the state of the Checkpointable object. How thishappens is modeled in the message view checkpointMethod.Whenever an operation m is invoked by a checkpointing par-ticipant on a checkpointed object, the current checkpointingcontext, which is also a tracing context, is asked if the targetobject has already been modified from within the context.If not, the establish method of the checkpointable objectis called before proceeding with the call to m. Note that thebinding directive m ! Checkpointable.+ * *(..) makessure that all calls to public methods of checkpointable ob-jects are taken care of.Recovering. Recovering shown in Fig. 11 finally dependson Checkpointing and OutcomeAware. The structural viewinstantiates the RecoveringContext to also be a Checkpoin-tingContext as well as a ContextWithOutcome. The Recov-eringContext state view integrates the two dependent stateviews into its own state view. The message view prepar-

+ Thread create()+ destroy()!

!

Thread

+ Account create()+ destroy()+withdraw(int amount)+deposit(int amount)

int balanceAccount

Base Class Diagram Base Sequence Diagram

t: Thread a: Account

withdraw(100)

b: Account

deposit(100)

!

!!!!!!!!!!!!!createAndEnterContext()

!

!!!!!! voteAndLeaveContext(o)

Ouside Inside

createcreateAndEnterContext

voteAndLeaveContextdestroy

sd Thread

Base State Diagram of Thread

Figure 12: A Simple Base ModeleRecovery makes sure that all method calls to recoverableobjects are checkpointed.

4.2 Applying Recovering to a Base ModelFig. 12 depicts a simple base model of a banking appli-

cation where a thread object t transfers some money fromaccount a to account b. By instantiating the Recovering as-pect into this base model, the transfer can be made atomic.The instantiation directives are as follows:

Recovering.|RecoveringParticipant ! ThreadRecovering.|Recoverable ! Account|RecoveringParticipant.|Idle ! Outside|RecoveringParticipant.|Working ! InsideIf the modeler does not want to add the instantiation di-

rectives directly to the base model, it is also possible to com-pletely separate the base model from the Recovering aspectand vice versa. This can be done by modeling a Recovery-Introduction aspect that instantiates Recovering and bindsit into the base model.

The resulting application structural view, 2 of the inter-esting application state views and the beginning of the appli-cation sequence diagram that are obtained after the weaving

Page 10: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

of these instantiation instructions are shown in Fig. 13. Inall three views it is (graphically) obvious that the di!erentconcerns (context, tracing, checkpointing, recovery) are tan-gled. Looking, for example, at the structure diagram it isnot obvious to say which entities and methods are involvedin, for example, establishing checkpoints. The annotationson the left hand side of the sequence diagram also show that,for example, functionality provided by Tracing is scatteredthroughout the diagram. Finally, the generated models areconsiderably bigger than the individual aspect models. Thecomplete final sequence diagram, for example, is 4 timeslonger, but had to be truncated to fit on to the page.

It is also interesting to note here that during our model-ing e!ort, we were able to detect subtle errors in our modelsthanks to the consistency checks between the final sequencediagram and the state views. In our sequence diagrams, Re-covering specified that the restoration of checkpoints was tobe performed after the context completes. We had forgottenthat Checkpointing specified that all checkpoints should bediscarded when the context completes. We discovered thatmistake because the state view of |Checkpointable refused toaccept a restore message after a discard had already beenprocessed (see Fig. 4).

5. RELATED WORKOur RAM approach is based on the class diagram com-

position approach [10] (called Kompose) and the generic as-pect model weaving approach (called GeKo) [19] to weaveboth state and sequence diagrams as presented in section 2.However, we believe that the RAM approach could be easilyadapted to run on other model weavers that support modelcomposition and model weaving. The major related aspect-oriented modeling tools and approaches are briefly describedin this subsection.

Clarke and Baniassad [7] define the Theme/UML approach.It introduces a theme module that can be used to representa concern at the modeling level. Themes are declarativelycomplete units of modularization, in which any of the dia-grams available in the UML can be used to model one view ofthe structure and behavior the concern requires to execute.In Theme/UML, class diagrams and sequence diagrams aretypically used to describe the structure and behavior of theconcern being modeled. Just like in our approach, the bind-ing to a base model is done by template parameter instan-tiation. In contrast to our approach, Theme/UML does notsupport model weaving, and hence does not allow the weaverto perform consistency checks between di!erent views.

Similarly to our approach, Whittle and Araujo [22] repre-sent behavioral aspects with scenarios. Aspectual scenariosare modeled as interaction pattern specifications and arecomposed with specification scenarios. The weaving processis performed in two steps. First state machines are gener-ated from the aspects and from the specification. The weav-ing is then performed by composing the obtained state ma-chines. Their approach di!ers from ours since it focusses onsequence diagrams only. We propose in [17, 16] a semantics-based weaver for sequence diagrams. This weaver allows thedetection of join points which cannot be detected if only thesyntax of the model is used.

The Motorola WEAVR approach [8] and tool have beendeveloped in an industrial setting. Behavior is modeled withSDL, a formalism related to state diagrams and activity di-agrams. In order to be able to reuse aspects, mappings have

to be defined (equivalent to our instantiations) that link areusable aspect to the application-specific context in whichit is to be deployed. The WEAVR approach di!ers from ourapproach since it exclusively focusses on SDL.

Whittle and Jayaraman [23] have recently proposed an in-teresting aspect-oriented modeling tool called MATA. Thistool uses graph transformations to specify and weave aspectsat the modeling level. MATA can be applied to any model-ing language with a well-defined meta model, and some casestudies have been proposed using mainly class, sequence,and state diagrams. With MATA, both pointcut and adviceare specified on the same model, whereas with our approachboth pointcut and advice are separately specified. At firstglance, the composition and weaving mechanisms o!ered byMATA seems powerful enough to implement the RAM ap-proach. Similarly, Groher and Voelter [12] have proposeda weaver based on the Eclipse Modeling Framework (EMF)Ecore meta meta model [4]. This means that the approachcan weave models that are instances of Ecore (meta mod-els). XWeave weaves crosscutting concerns encapsulated asaspect models into (non-AO) base models. This is a form ofasymmetric model weaving (similary to GeKo), where thereis a designated base model into which a number of aspectmodels are woven (as opposed to symmetric weaving, wherethere is no designated base model). Weaving is done basedon matching names of elements in the aspect and the basemodel. Additionally, pointcuts based on the openArchitec-tureWare (oAW) expression language [3] can be defined toselect sets of model elements as join points. XWeave cannotremove, change, or override existing base model elementsusing aspects. XWeave thus currently supports essentiallyonly additive weaving, where additional elements are addedto the base model.

In [21], Stein et al. introduce a way to express variousconceptual models of pointcuts (called JPDDs for Join PointDesignation Diagrams) in aspect-oriented design. Structuraland behavioral modeling is achieved by employing for in-stance class diagrams, state charts, and sequence diagrams.In contrast to our approach, their objective is not to performthe weaving at the modeling level, but rather to generatecode for aspect-oriented programs from an aspect-orienteddesign as shown in [13]. Again, it would be possible tochange the notation used in our approach and express point-cuts using JPDDs, if modelers find them more intuitive.

6. CONCLUSION AND FUTURE WORKThis paper presented Reusable Aspect Models (RAM), an

aspect-oriented multi-view modeling approach. The maincontributions of RAM are:

• RAM is the first AOM approach that integrates classdiagram, sequence diagram and state diagram AOMtechniques. As a result, RAM aspect models can de-scribe the structure and the behavior of a concern un-der study.

• Reuse of aspect models in RAM is simple and flexible.Flexibility is achieved by allowing any model elementto optionally be composed or extended through bind-ings. Correct reuse is enforced by the weaver, whichmakes sure that compatible model elements are pro-vided for all mandatory instantiation parameters whenan aspect is instantiated, and eventual bindings de-fined in a higher aspect are compatible with the bind-ings in the reused aspect.

Page 11: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

• RAM supports the creation of elaborate aspect depen-dency chains. This makes it possible to model aspectsthat provide complex functionality by decomposingthem into aspects that provide simpler functionality.Vice versa, aspects providing simpler functionality canbe reused in several aspects of complex functionality.As a result, scattering and tangling of models can beprevented at all complexity levels.

• The RAM weaver performs extensive consistency checksduring the weaving and on the final woven model toensure that the composition directives of the state andmessage views are consistent.

• RAM defines a detailed weaving algorithm that re-solves aspect dependencies recursively to generate in-dependent aspect models and ultimately generate thefinal application model. Dependencies are resolved atweave-time only in order to maximize the benefits ofreuse.

We have shown that the RAM approach can handle the mod-eling of complex aspect frameworks by applying it to modelAspectOptima, an aspect-oriented framework for the gener-ation of transaction middleware. Even though we only mod-eled the part of AspectOptima that deals with providing theatomicity property of transactions, the obtained RAM mod-els of the individual aspects were a magnitude smaller thanthe woven final models.

The case study leads us to believe that RAM providesscalable and consistent multi-view modeling. Support foraspect-orientation and for dependencies among aspects al-lows the developer to modularize concerns at multiple lev-els. Enforcement of correct aspect reuse, and model check-ing performed on the views of the final woven model ensureglobal view consistency. In order to make a conclusive state-ment, however, further experiments are necessary.

We already have implemented tool support for RAM inEclipse based on Kompose [2] and GeKo [9]. It can bedownloaded from [5]. So far, however, only class and se-quence diagrams are supported. In this restricted contextwe have also developed a technique that allows the RAMweaver to automatically handle aspect conflicts for users ofaspect models, if the developer of the aspect model has pre-viously identified and resolved the conflict by providing anaspect conflict resolution model. We are currently workingon extending the approach to also include state diagrams.

Finally, we believe that in order to be complete, RAMaspect models should be extended by adding yet anotherkind of view that describes the detailed execution paths forindividual methods. Detailed method algorithms could beexpressed, for instance, with UML activity diagrams or SDL.With this additional view, RAM would be capable of gener-ating final application models that are fully executable.

7. REFERENCES[1] Aspect-Oriented Modeling Workshop Series.

http://www.aspect-modeling.org/.[2] Kompose. http://www.kermeta.org/mdk/kompose/.[3] openArchitectureWare.

http://www.eclipse.org/gmt/oaw/.[4] The Eclipse Modeling Framework.

http://www.eclipse.org/emf/.[5] AspectOPTIMA Webpage:

http://aspectoptima.cs.mcgill.ca/, 2007.

[6] Bölükba!i, G. Aspectual Decomposition ofTransactions. Master’s thesis, School of ComputerScience, McGill University, Montreal, Canada, 2007.

[7] Clarke, S., and Baniassad, E. Aspect-OrientedAnalysis and Design: The Theme Approach. AddisonWesley, 2005.

[8] Cottenier, T., v.d. Berg, A., and Elrad, T.Stateful aspects: the case for aspect-orientedmodeling. In 10th Aspect-Oriented Modeling Workshop(2007), ACM Press.

[9] Fleurey, F., Baudry, B., France, R., andGhosh, S. A generic approach for automatic modelcomposition. In 11th Aspect-Oriented ModelingWorkshop (2007).

[10] France, R., Ray, I., Georg, G., and Ghosh, S.Aspect-oriented approach to early design modelling.IEE Proceedings Software (August 2004), 173–185.

[11] Gray, J., and Reuter, A. Transaction Processing:Concepts and Techniques. Morgan Kaufmann, 1993.

[12] Groher, I., and Voelter, M. Xweave: Models andaspects in concert. In 10th Aspect-Oriented ModelingWorkshop (2007).

[13] Hanenberg, S., Stein, D., and Unland, R. Fromaspect-oriented design to aspect-oriented programs:tool-supported translation of JPDDs into code. InAOSD (2007), pp. 49–62.

[14] Kienzle, J., Duala-Ekoko, E., and Gélineau, S.AspectOPTIMA: A Case Study on AspectDependencies and Interactions. TAOSD (to bepublished).

[15] Kienzle, J., and Gélineau, S. AO Challenge:Implementing the ACID Properties for TransactionalObjects. In AOSD (2006), ACM Press, pp. 202 – 213.

[16] Klein, J., Fleurey, F., and Jézéquel, J. M.Weaving multiple aspects in sequence diagrams.TAOSD LNCS 4620 (2007), 167–199.

[17] Klein, J., Hélouet, L., and Jézéquel, J.-M.Semantic-based weaving of scenarios. In AOSD(2006), ACM Press, pp. 27–38.

[18] Klein, J., and Kienzle, J. Reusable AspectModels. In 11th Aspect-Oriented Modeling Workshop(September 2007).

[19] Morin, B., Klein, J., Barais, O., and Jezequel,J.-M. A generic weaver for supporting product lines.In Early Aspects Workshop at ICSE (2008).

[20] Reddy, R., Ghosh, S., France, R. B., Straw,G., Bieman, J. M., Song, E., and Georg, G.Directives for composing aspect-oriented design classmodels. TAOSD LNCS 3880 (2006), 75–105.

[21] Stein, D., Hanenberg, S., and Unland, R.Expressing di!erent conceptual models of join pointselections in aspect-oriented design. In AOSD (2006),ACM Press, pp. 15–26.

[22] Whittle, J., and Araújo, J. Scenario modellingwith aspects. IEE Proceedings - Software 151, 4(2004), 157–172.

[23] Whittle, J., and Jayaraman, P. Mata: A tool foraspect-oriented modeling based on graphtransformation. In 11th Aspect-Oriented ModelingWorkshop (2007).

Page 12: Aspect-Oriented Multi-View Modeling - Uniorbilu.uni.lu/bitstream/10993/3910/1/Kienzle_RAM_aosd2009.pdf · Aspect-Oriented Multi-View Modeling Jörg Kienzle, Wisam Al Abed School of

+ A

ccount cre

ate

()+

destr

oy()

+ w

ithdra

w(int am

ount)

+ d

eposit(int am

ount)

- K

ind g

etA

ccessK

ind(M

eth

od m

)-

Account clo

ne()

- copyS

tate

(Account fr

om

)-

Tra

ce c

reate

Tra

ce(M

eth

od m

)-

esta

blis

h()

- re

sto

re()

- dis

card

()

!

Acco

un

t

1

m

yT

race

+ C

onte

xt cre

ate

()+

destr

oy

- addP

art

icip

ant(

Thre

ad t)

- re

moveP

art

icip

ant(

Thre

ad t)

- O

utc

om

e g

etO

utc

om

e()

- setO

utc

om

e(O

utc

om

e o

)-

boole

an w

asM

odifi

ed(A

ccount obj)

- A

ccount[] getM

odifi

ed()

- addT

race(T

race t)

- addT

races(T

race t[])

- T

race[] g

etT

races()

- re

moveT

race(T

race t[])

- re

sto

reC

heckpoin

ts()

!

Co

nte

xt

+ insert

(Tra

ce t)

+ T

race[] fi

ndT

races(A

ccount o)

+ T

race[] g

etT

races()

!

Tra

ceL

ist

+ c

reate

(Meth

od m

, K

ind k

, A

ccount t)

+ b

oole

an w

asA

pplie

dTo(A

ccount t)

+ b

oole

an isM

odify()

!

Tra

ce

0..

*

ele

me

nts

1 ob

j+

push(A

ccount e)

+ A

ccount getL

ast(

)+

dis

card

Last(

)

!

Sta

ck

myS

tack

1

0..

*

myC

on

text

1

0..

1

pa

rtic

ipa

nt

+ T

hre

ad c

reate

()+

destr

oy()

+ R

ecoveringC

onte

xt getC

onte

xt(

)+

cre

ate

AndE

nte

rConte

xt(

)+

vote

AndLeaveC

onte

xt(

)-

setC

onte

xt(

RecoveringC

onte

xt c)

- le

aveC

onte

xt(

)

!

Th

read

Insta

nti

ate

d

sd

Th

rea

d

Insid

e

Ou

tsid

eW

ork

ing

cre

ate

And

Ente

rConte

xt

!!!!!!!!!!!!!!!!!!!!!v

ote

AndLeave

!!!!!!!!!!!!!!!!!!!!C

onte

xt

Vo

tin

gsetC

onte

xtcre

ate

destr

oy

An

y

getC

onte

xt

En

teri

ng

Leavin

gle

ave

Conte

xt

setC

onte

xt

Insta

nti

ate

d

Acti

ve

conte

xt

Com

ple

ted

addP

art

icip

ant

sd

Co

nte

xt

Acti

ve

Befo

reV

ote

Aft

erV

ote

rem

ove

Part

icip

ant

setO

utc

om

e

cre

ate

An

y

getM

odifi

ed

getT

races

wasM

odifi

ed

addT

race

addT

races

Idle

Co

mp

lete

d

destr

oy

!!!!!!!!!!re

sto

reC

heckpoin

ts

!

!!!

acce

ssK

ind :

= g

etA

cce

ssK

ind(m

)

!

!!!

!!!!!!!!!!!c

rea

teA

nd

En

terC

on

text(

)

t: T

hre

ad

a:

Acco

un

t

!

!!!

m

yC

on

text

:= g

etC

onte

xt(

)new

Co

nte

xt:

R

eco

veri

ng

Co

nte

xt

se

co

nd

Tim

e :

= w

asM

odifi

ed

(a)

with

dra

w(1

00

)

op

t [n

ot

se

co

nd

Tim

e]

esta

blis

h()

myS

tack:

Sta

ck

pu

sh(n

ew

Che

ckp

oin

t)

!

!!!

new

Ch

eckp

oin

t :=

clo

ne

()

new

Ch

eckp

oin

t: A

cco

un

tn

ew

Ch

eckpo

int

:= c

rea

te()

co

pyS

tate

(a)

in

clu

de

:=

wa

sA

pp

liedTo(o

)

ops :

= fi

nd

Tra

ce

s(o

)

t: T

race

loo

p [t

with

in e

lem

en

ts]

loo

p [

i w

ithin

ops,

foun

d "

tru

e]

i: T

race

foun

d :=

isM

od

ify()

!

!!!

myC

on

text

:= g

etC

on

text(

)

tra

ce

dO

p :

= c

rea

teT

race(|

m)

ad

dT

race

(tra

ce

dO

p)

insert

(tra

ce

dO

p)

traced

Op

: T

race

tra

ce

dO

p :

= c

rea

te(m

, acce

ssK

ind,

|ta

rge

t)

ne

wC

on

text

:= c

rea

te()

ad

dP

art

icip

an

t(t)

!

!!!

s

etC

on

text(

new

Co

nte

xt)

myT

race:

Tra

ceL

ist

Context Checkpointing

TracingTracing

Traceable

Checkpointable

Copyable

AC

---

deposit a

nd v

ote

AndLeaveC

onte

xt skip

ped for

space r

easons -

--

Figure 13: Woven Application Model