DEVELOPING DISTRIBUTED SERVICES USING AN ASPECT ORIENTED … · Aspect Oriented Software...
Transcript of DEVELOPING DISTRIBUTED SERVICES USING AN ASPECT ORIENTED … · Aspect Oriented Software...
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
International Journal of Cooperative Information SystemsVol. 15, No. 4 (2006) 535–564c© World Scientific Publishing Company
DEVELOPING DISTRIBUTED SERVICES USING AN ASPECTORIENTED MODEL DRIVEN FRAMEWORK
ARNOR SOLBERG
ICT, SINTEF, Forskningsveien 1, Oslo, 0314, [email protected]
http://www.sintef.no
DEVON SIMMONDS∗, RAGHU REDDY†, ROBERT FRANCE‡and SUDIPTO GHOSH§
Department of Computer Science, Colorado State UniversityFort Collins, CO-80523, USA∗[email protected]
†[email protected]‡[email protected]§[email protected]://www.colostate.edu
JAN ØYVIND AAGEDAL
ICT, SINTEF, Forskningsveien 1, Oslo, 0314, [email protected]://www.sintef.no
To manage the development of cooperative information systems that support the dynam-ics and mobility of modern businesses, separation of concern mechanisms and abstrac-tions are needed. Model driven development (MDD) approaches utilize abstraction andtransformation to handle complexity. In MDD, specifying transformations between mod-els at various levels of abstraction can be a complex task. Specifying transformations forpervasive system services that are tangled with other system services is particularly dif-ficult because the elements to be transformed are distributed across a model. This paperpresents an aspect oriented model driven framework (AOMDF) that facilitates sepa-ration of pervasive services and supports their transformation across different levels ofabstraction. The framework facilitates composition of pervasive services with enterpriseservices at various levels of abstraction. The framework is illustrated using an examplein which a platform independent model of a banking service is transformed to a platformspecific model.
Keywords: Aspect-oriented software development; model driven development; dis-tributed services; separation of concerns; middleware; UML.
1. Introduction
Businesses are becoming more dependent on distributed computing systems.For example, they are used to enable collaboration and trading between busi-nesses and between businesses and customers. Recent advances in technology and
535
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
536 A. Solberg et al.
infrastructure provide ubiquitous access to enterprise services through differentkinds of devices. This increases demands for information system properties suchas flexibility, autonomy, security, reliability and availability. Business trading andcollaboration is dynamic. Long, medium and short term business collaboration andad hoc trading with customers and vendors are part of this dynamics. Support-ing the dynamics and providing the requested service with the requested quality,assembly of cooperative systems, for example, through composition, configurationand integration, is needed.
Service oriented technologies such as Service Oriented Architectures (SOA)14
and Web services7,28,48 are emerging technologies aiming to enable such kind of sys-tems. In distributed service oriented system construction, many concerns need to beconsidered, such as adaptability to enable service composition and re-composition,and extra functional concerns such as security and transaction control. To managedevelopment and evolution for these kinds of systems, there is a need for separationof concernsa and abstraction mechanisms. Furthermore, standardized mechanismsand techniques for service composition are needed. For example, to compose pri-mary business services (e.g. a booking service and a billing/payment service for anonline shopping service), and to compose pervasive services such as security andtransaction control services with primary business services.
Model driven development (MDD) aims to reduce complexity in software devel-opment through modularization and abstraction. Model-based system abstractionsare used for bridging the gap between enterprise services and IT services. Accom-plishing this entails developing support for modeling concepts at different levels ofabstraction and transforming abstract models to more concrete descriptions of soft-ware. For example, abstract enterprise services can be transformed into technology-specific IT services.
An MDD framework should provide mechanisms supporting both vertical andhorizontal separation of concerns. The OMG’s model driven architecture (MDATM)initiative34,44 proposes a vertical separation of concerns framework in which sys-tems are described at three different levels of abstraction: computation indepen-dent model (CIM) describes the system environment and the requirements for thesystem, platform independent model (PIM) provide descriptions of the parts ofa system that do not change from one platform to another; and platform spe-cific model (PSM) provide descriptions of systems that include detail that varyfrom one platform to another. The PIM and PSM are relative to the defined plat-form. For example, if middleware is defined as the platform, separation of platformindependent and platform specific concerns occurs when a middleware independentmodel (a PIM) and a corresponding middleware specific model (a PSM) are definedfor a particular application.
aThe IEEE recommended practice for architectural descriptions (IEEE1471) defines a concern as:Those interests which pertains to the system’s development, its operation or any other aspectsthat are critical or otherwise important to one ore more stakeholders.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 537
Horizontal separation of concerns is typically realized by modeling a systemusing views (e.g. the ISO RM-ODP framework21). A system view describes acertain facet of the system (e.g. structure, behavior or distribution). The use ofdiagram types (e.g. UML activity, class and state diagrams36) provided by a mod-eling language is normative for specifying view mechanisms. However, diagramtypes provide only separation of structure and behavior and do not inherently pro-vide separation of crosscutting features. To better manage complexity and separateconcerns, an MDD framework should provide support for separating crosscuttingfeatures.
Aspect Oriented Software Development (AOSD)1,25,26,37,38 supports horizon-tal separation of concerns by providing mechanisms for encapsulating crosscut-ting features using aspects. In service oriented system development, aspects canbe used to describe crosscutting services.9 In our aspect oriented modeling (AOM)approach,13,16 crosscutting services are modeled as aspects and composed withthe primary design model that describes the enterprise services, to form completeapplication models. Crosscutting services typically extend several primary servicesof the system, for example, to ensure provision of the required quality of the services(QoS). Examples of such crosscutting services are availability, transaction controland security.
In this paper, we present an aspect oriented model driven framework (AOMDF)that enables vertical and horizontal separation of concerns. The paper describes howthe AOMDF utilizes aspect-based techniques to facilitate the separation of concernsand ease the task of specifying transformations. It also describes how specification ofservices can be composed. Vertical separation of concerns is supported by providingtechniques for transforming the models from one abstraction level to another. Themodels are transformed using mappings that are defined separately for the primarymodel and each of the aspects. Horizontal separation of concerns is realized bytreating crosscutting services as aspects, i.e. these are modeled separately fromthe primary model. Composition of crosscutting services with the primary servicesspecified in the primary model can be performed at various levels of abstraction.The framework is illustrated using an example in which a platform independentmodel of a banking service is transformed to a platform specific model.
The AOMDF was initially presented in Simmonds.42 This paper extends thatwork by describing how AOMDF can be used to develop service-oriented systems.This paper also includes a discussion on composing sequence diagrams and onvalidating composition mechanisms.
Section 2 describes the framework. Section 3 illustrates the framework using ascenario from a bank application. Section 4 discusses related work. Section 5 drawssome conclusions and outlines planned work on the framework.
2. The Aspect Oriented Model Driven Framework
This section describes the aspect oriented model driven framework (AOMDF), itstechnological basis and validation concerns.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
538 A. Solberg et al.
2.1. Model transformation
A model transformation can be viewed as a transformation between two modelspaces defined by their respective metamodels. A source-model to target-modeltransformation specification describes how elements in the source-model spaceshould appear in the target-model space by relating metamodel elements in thesource and target metamodels. The relationships among transformation conceptsare illustrated in Fig. 1.
The source model instance conforms to the source metamodel (for instance theUML metamodel). The transformation implementation transforms a source modelinstance to the corresponding target model instance. The target model instanceconforms to the target metamodel (for instance the UML profile for CORBA32).The specific transformation implementation for a specific source and target modelis generated using the Source2Target Schema. This schema is the transformationspecification, which maps source metamodel concepts to target metamodel con-cepts. The Source2Target Schema must conform to a transformation metamodel(for instance the MOF 2.0 QVT35).
Before a transformation can be executed, the transformation must be specifiedas a mapping. Each mapping identifies the source model that is input to the map-ping and the target model that results when the mapping is executed. Many trans-formation approaches are based on specifying mappings from source metamodelconcepts to target metamodel concepts.8,15 However, it may not be desirable to
Source(e.g. UML metamodel)
<<metamodel>>
Source2TargetScheme
<<transformation>>
<<model instance>>Source
implementation
<<source>>
Target(e.g. EJB UML profile)
<<metamodel>>
<<target>>
<<source>> <<target>>
<<conforms_to>>
Transformation(e.g. MOF2.0 QVT)
<<metamodel>>
<<model instance>>Target
Transformation
<<conforms_to>> <<conforms_to>>
<<conforms_to>>
Fig. 1. Model transformation conceptual model.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 539
map all instances of a specific metamodel element at the source level in the sameway. For example, middleware platforms such as CORBA, J2EE, .Net and WebServices typically have specific protocols for pervasive middleware services such assecurity, persistence, and transactions. These protocols may differ from one mid-dleware to another, and different services may require different protocols even forthe same middleware. Thus, the mapping specifications of these aspects tend to berigid and proprietary. CORBA, for example, provides the CORBA security service,the CORBA transaction service and the CORBA persistent object service, each ofwhich require a specific protocol. Pervasive middleware services need to be treatedexplicitly in model transformation to obtain the correct target model. The AOMDFfacilitates source to target mappings in which provided platform specific protocolsare used. The AOMDF mapping specifications are based on the MOF 2.0 QueryView Transformation (QVT) standard.35 QVT is a language for specifying modelrelations and transformations that is currently undergoing OMG standardization.The language is based on currently available languages and tools for example, TataMastercraft47 and Atlas.4 Currently, there are a variety of model transformationapproaches and tools available. Many of the model transformation approaches aresurveyed in Czarnecki and Helsen.8 It is not clear to us how these approaches andtools will support the QVT standardization effort.
2.2. Aspect oriented modeling
There is an ongoing research on the usage of AOSD techniques at the modellevel.5,13,38,40,41 The AOMDF is based on our aspect oriented modeling approachin which a design is expressed in terms of the following artifacts:13,16
(i) A primary model that describes the business logic of the application.(ii) A set of generic aspect models, where each model is a generic description of a
crosscutting feature.(iii) A set of bindings that determine where in the primary model the aspect models
are to be composed.(iv) A set of composition directives that influence how aspect models are composed
with the primary model.
Before an aspect model can be composed with a primary model in an applicationdomain, the aspect model must be instantiated in the context of the applicationdomain. An instantiation is obtained by binding elements in the aspect model toelements in the application domain. The result is called a context-specific aspectmodel. Context-specific aspect models and the primary model are composed toobtain an integrated design view.13,45
2.3. The framework
Figure 2 shows the major activities and artifacts supported in the AOMDF. Theprimary focus of the framework is the transformation of aspect oriented models from
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
540 A. Solberg et al.
more abstract forms to more concrete forms. The major activities are partitionedinto four categories: source level, mappings, target level and model composition.
The source level includes activities for acquiring or developing abstract aspectand primary models. At this level, the aspect models are acquired from an aspectrepository if one is available or they are developed by the system architect. Theprimary model is developed by the system architect. The system architect decideswhich services will be included in the primary model and which will be treated asaspects. The decisions are based on the distinction of functional and extra func-tional requirements. Extra functional requirements, such as security and transactionmanagement, are often pervasive. AOSD techniques are used to separate servicesthat address these requirements from the primary business functionality.
The mapping category includes activities for developing or acquiring the corre-sponding target mappings for the aspect and primary models. The transformationsbetween the source and the target levels are defined by separate mappings foreach aspect and the primary model. The source and target levels have a recursivenature. Thus, the source level in one context may appear as the target level inanother context.
The target level includes activities for applying the mappings to the sourcelevel primary and aspect models. The target detailed design models are obtainedby applying the source to target transformations that are specified in the mappings.
The model composition part includes activities for instantiating and compos-ing the aspect and primary models using bindings and composition directives.13,46
Aspect models need to be instantiated before they can be composed. Instantia-tion is performed by binding the aspect model elements to the application specific
Acquiresource models
Sourceprimary model
Sourceaspect models
Acquire primarymodel mappings
Primary modelmappings
Acquire aspect mappings
Aspect mappingsDevelop
composition directives Compositiondirectives
Instantiate aspect models
Bindings Specify bindings
Context-specificaspect models Compose aspect
and primary models
Composed model
Apply aspect mappings
Targetaspect models
Apply primarymodel mappings
Targetprimary model
Model Composition
Target level
Mapping
Source level
PrimaryModelAspect models
Fig. 2. Aspect oriented model driven framework.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 541
Table 1. Potential framework instantiations.
Instantiation Types
1 2 3 4 5
Source level PIM PIM PIM PIM PSMTarget level PSM PSM PIM PSM PSMComposition level(s) PSM PIM PIM PIM and PSM PSM
model elements. Once the instantiation is done, model composition is performedusing the composition directives, basic name matching procedures13 and signaturematching.39
AOMDF has two major variation points that must be fixed before the frameworkcan be used. These are (1) the framework levels and (2) the level(s) at which com-position will be done. Using the MDA terminology, the PIM and PSM are definedrelative to the chosen platform (e.g. middleware platforms like J2EE, CORBA and.Net). One may still define a set of source and target levels within the PIM andPSM context. For instance, it may be desirable to perform transformations fromPIM architecture model to a PIM detailed design model, and likewise to have sev-eral abstractions within the PSM level, as illustrated in Table 1.
The following is a list of the perceived benefits of the proposed framework:
(i) The framework allows developers to conceptualize, describe, and communicatecrosscutting concerns as conceptual units at various levels of abstraction.
(ii) The horizontal separation of concerns as aspect models and a primary modelfacilitate separate specifications of mappings.
(iii) The specification of the transformation of an aspect or the primary model fromsource to target is less complex than the specification of the transformation ofan integrated source model to a target model, since the latter transformationis likely to have more kinds of relationships and dependencies.
(iv) Changes to a crosscutting concern can be made in one place, and effected bycomposing the changed aspect model with a primary model.
(v) The aspects are often application independent (e.g. security and transaction).The aspect model and its mappings can therefore be reused across multipleapplications and application domains once they are defined.
Automated or semi-automated model composition needs to be in place to gainfull benefit of points 3 and 4.
2.4. Consistency of the framework
The AOMDF provides separation of horizontal concerns by means of aspects andcomposition, and vertical separation of concerns by means of abstractions and trans-formations from source to target models. Thus, there are two paths for obtaining atarget level composed model. Either you compose models at the source level beforetransforming to a composed target model, or the primary and aspect models at
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
542 A. Solberg et al.
am1_src
amn_src…
pm_src
cm_src
Source Level
c_src
am1_trgt
amn_trgt…
pm_trgt
cm_trgt’
Target Level
c_trgt
mp
ma1
man
…rc
mc
cm_trgt
Abbreviationspm : primary modelam : aspect modelmp : mapping primary modelma1 : mapping aspect 1man : mapping aspect nrc : mapping model compositionmc : mapping composed modelc : compositionsrc : sourcetrgt : target
Fig. 3. Two paths to obtain composed model at the target level.
the source level are transformed to corresponding primary and aspect models atthe target level before a target level composition is performed. These paths haveto produce consistent results. We define consistency to imply property preservationthrough refinement similar to the definition in D’Souza and Wills.10 Furthermore,the framework also requires that analyzable properties at the source level (e.g.analysis of performance or reliability) are also analyzable at the target level tocheck for property preservation. In Fig. 3, cm src is a Composed Model at thesource level created by composing a source level primary model (pm src) and aset of source level aspect models (am src) using a composition specification (c src)that includes a set of composition directives (cd src). For consistency, we want toprove that for any transformation specification (mc), mapping cm src to a corre-sponding model at the target level (cm trgt), there exists an equivalent mappingconsisting of:
• Separate mappings (ma1 . . .man) for each of the aspects (am1 src. . . amn src)deriving a set of corresponding aspects (am1 trgt. . . amn trgt) at the target level;
• A mapping (mp) of the primary model pm src to a corresponding target levelprimary model (pm trgt); and
• A composition (c trgt) including a set of composition directives (cd trgt), thatproduce a composed model (cm trgt’), where cm trgt’ is consistent with cm trgt.
We identify the following three necessary conditions for these two paths to beconsistent:
(i) The composition at the target level (c trgt) is a refinement (rc) of the compo-sition at the source level (c src); thus, the composition directives at the targetlevel (cd trgt) is a refinement of the composition directives at the source level(cd src);
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 543
(ii) pm trgt is consistent with pm src, am1 trgt is consistent with am1 src, . . . ,and amn trgt is consistent with amn src; and
(iii) and cm trgt is consistent with cm src.
It can be derived that conditions 1–3 are sufficient to make the equivalenceof the two paths true. This follows since if condition 1, 2 and 3 holds cm trgt’ isconsistent with cm src.
3. An Illustrative Example
We illustrate the framework with a distributed banking application that offers elec-tronic money transfer using distributed transaction services. In the example, theframework is instantiated as follows:
• The source model is a PIM and the target model is a PSM. The platform isCORBA.
• Model composition is performed only at the PSM level.
Figure 4 shows the instantiated framework. Mappings are defined for a CORBAtransaction aspect and a money transfer scenario. They are applied on the PIMsto obtain the PSMs. The primary model is tagged to show where in the primarymodel the aspects are composed.
3.1. Acquire source models
We present a simple banking scenario and a transaction aspect as interaction dia-grams to illustrate the instantiated framework.
3.1.1. Primary model
The bank consists of a set of accounts managed by account managers. The busi-ness functionality includes operations to open and close accounts. Withdrawal anddeposit of specific amounts of money are provided for accomplishing money trans-fer. The transfer of money requires transaction control, which is modeled as anaspect. The money transfer scenario shown in Fig. 5 is the primary model used inthis illustrative example.
3.1.2. Transaction aspect
A transaction is a collection of operations between servers and clients that appearsatomic. An atomic operation is an operation that is free of interference from concur-rent operations performed by other threads in a system. Transactions are requiredto manifest the “ACID” properties.6 While different middleware may provide dif-ferent transaction models, a generic transaction model that captures the essence ofdistributed transactions can be specified at the PIM level. The generic model canthen be transformed to utilize the specific protocol of a particular middleware.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
544 A. Solberg et al.
Acquiresource models
Sourceprimary model
Sourceaspect models
Acquire primary modelCORBAmappings
Primary modelCORBAmappings
Acquire aspectCORBA mappings
CORBA Aspectmappings
Compositiondirectives
Instantiateaspect models
Bindings Specify aspect bindingsAnd composition directives
Context-specificaspects models Compose aspect
and primary modelsComposed model
Apply CORBA aspect mappingsCORBA
aspect models
Apply CORBA primarymodel mappings
CORBAprimary model
PSM Level
Mappings
PIM Level
Fig. 4. PIM to PSM framework instance.
Figure 6 shows a distributed transaction feature modeled as an aspect.The transaction aspect describes one-phase and two-phase commit distributedtransaction protocols. The one-phase and two-phase commit protocols are shownas alternatives in the figure. Templates are specified using the “|” notation.
The transaction aspect has three main roles:
(i) A Transaction Client initiates the transaction and performs a collection ofoperations for the specific transaction.
(ii) A Participant provides some service required by the Transaction Client.Figure 6 also shows a collection of Participants as a lifeline, representing theset of Participants involved in the transaction.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 545
MoneyTransferService
moneyTransfer(acc1, acc2, amount)
withdraw(acc1, amount]
deposit(acc2, amount)
sd Money transfer
-acc1, acc2:String-amount:Real am1:AccountManager am2:AccountManager
am1=lookup(acc1)
am2=lookup(acc2)
Fig. 5. Banking scenario primary model.
(iii) A Transaction Manager is responsible for coordinating and managingtransactions.
The Transaction Client initiates the transaction by sending the openTransac-tion message. When the Transaction Manager receives this message, it opens atransaction and returns a transaction id (Tid). This Tid is sent as a parameter inall subsequent operations. The Transaction Client then performs the collection ofoperations of the transaction. When a Participant receives an operation request itchecks whether it is already a member of the particular transaction. If not, it joinsthe transaction before it performs the requested operation.
Two-Phase Commit Protocol: When the transaction client requests to closethe transaction, the Transaction Manager starts the commit protocol according tothe chosen transaction protocol type. The diagram in Fig. 6 shows the detailsof the two-phase commit protocol. In the first phase (voting phase), the trans-action manager polls the participants to determine if they are ready to com-mit. In the second phase (completion phase), the Transaction Manager decidesto abort or commit the transaction. The decision is multicast to all participants.The completion phase can be initiated in one of three ways. The TransClientor a Participant can ask that the transaction be aborted, the TransClient canrequest that the transaction should be closed, or the TransactionManager cantimeout. When the TransactionManager receives an abortTransaction request, itmulticasts the doAbort message to all participants. If the TransactionManagertimes out or receives a closeTransaction request, it multicasts the canCom-mit message to all participants. If all participants can commit, the Transac-tionManager multicasts a doCommit message to all participants, otherwise adoAbort message is multicast. Participants must commit or rollback the transactionindividually.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
546 A. Solberg et al.
sd Transaction
:|TransClient :|Participant :TransactionManager
operation ()openTransaction (t:Ttype)
Tid
join(Tid,Pid)
|transoperation (Tid,|params )
do_|TransO peration (Tid,|params)
Loop [1,numberOfOperationsInTransaction ]
opt
+Tid, Pid:String+t:transProtocol+transactionAborted , timeOut , decisionAbort , decissionCommit :Boolean
[joined=false]
closeTransaction (Tid)
alt [t=2phaseCommit]
Loop [noVoteExist or yesFromAll]
<<multicast>> canCommit (Tid)
<<multireceive>> Yes/No
par
opt abortTransaction (Tid)
opt
break [transactionAborted or timeOut ]
[t=1phaseCommit]
ref OnePhaseCommit
alt [decisionCommit]decision(commit)
<<multicast>> doCommit (Tid)
[decisionAbort ]decision(abort )
<<multicast>> doAbort (Tid)
theParticipants :Participant [1..*]
addParticipant (Tid, Pid)
initiateVotingPhase(Tid)
initiateCompletionPhase (Tid)
timeOut(Tid)
initiateCompletionPhase (Tid)
processCommit (Tid)
processCommit (Tid)
processAbort (Tid)
processAbort (Tid)
Fig. 6. Transaction aspect.
3.2. Defining an interaction metamodel
QVT transformation specifications are metamodel based, and thus, to specify trans-formations, the source and target metamodels are needed. Both the source modelsin our example (the primary model and the transaction aspect) are specified using
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 547
NamedElement(from Kernel)
name:Stringvisibility :VisibilityKind
Lifeline Type
0..1*
Message
messageSort:MessageSort
0..1MessageEnd
+sendEvent
+receiveEvent
0..1
0..10..1
+/signature
Interaction
*
1 *InteractionFragment
*
*
0..1
CombinedFragment
interactionOperator:InteractionOperator
<<enumeration>>InteractionOperator
seqaltoptbreakparstrictloopcriticalnegassertignoreconsider
cover *
refersTo1
*
*
*
0..1
<<enumeration>>MessageSort
synchCallasynchCallasynchSignalreply
0..1
Parameter(from Kernel)
name:String
name:String
ValueSpecifcationFrom Kernel
*+argument
specifiedBy
1 *
0..1
name:String
Fig. 7. Simple interaction metamodel.
UML 2.0 interactions. The interactions metamodel is specified in the UML 2.0standard.36 However, the metamodel for interactions as specified in the UML 2is fragmented, and the fragments are tied together via several other metamodelpackages like the UML 2.0 kernel, the basic actions, and the basic behaviors. Themapping specifications would have been unnecessarily complex if we had used theUML 2.0 metamodel specifications directly.43 We have derived a simplified interac-tion metamodel including the basic concepts of interactions and their relationships.This model is shown in Fig. 7.
3.3. Acquire primary model mapping
One possible CORBA mapping for the primary model is to derive a PSM interactionmodel showing the CORBA object interactions. Stereotypes can be used to indicatethe CORBA objects. This is a straightforward mapping where CORBA stereotypesare added and primitive types are converted. The result is shown in Fig. 8.
Another possible mapping is to derive an IDL representation based on the spec-ified source interaction model. From this, stubs, skeletons and helper classes can
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
548 A. Solberg et al.
<<CORBAInterface>>MoneyTransferService
moneyTransfer(acc1, acc2, amount)
withdraw(acc1, amount]
deposit(acc2, amount)
-acc1, acc2:string-amount:double
<<CORBAInterface>>am1:AccountManager
<<CORBAInterface>>am2:AccountManager
am1=lookup(acc1)
am2=lookup(acc2)
sd Money transfer
Fig. 8. PSM sequence diagram.
be generated using an IDL compiler. A QVT specification for mapping interac-tion diagrams to CORBA IDL is shown in Fig. 9. The UML profile for CORBA32
contains the elements that are used as the target metamodel. This representationis compliant with an IDL representation and may serve as the source for an IDLcompiler.
Two mappings are defined in Fig. 9. Mapping (a) derives the CORBA interfaceswith operations, mapping (b) add directed associations. The left-hand side of themappings describes a pattern that should be matched in order for the mapping toexecute. The pattern is an instantiation of the interaction metamodel. The headerof the package specifies input and output (Lifeline and CORBAInterface, respec-tively). These are the anchors of the structures of the left-hand side and right-handside respectively. A Lifeline has a set of zero or more receive MessageEnds. Sets areindicated with the multiplicity star. According to the interaction metamodel, Life-line, Type, Message and MessageEnd have names. These are not explicitly shownin the source patterns, but are used to derive the target structures.
The mappings produce a CORBAInterface for each lifeline type having the samename as the lifeline type name. For every receive MessageEnd, a correspondingoperation is added. The parameter specifications remain the same in both sourceand target. This assumes that the primitive types of source and target are equal,else a type mapping would be needed. The different members of the patterns arereferred using their names. According to the QVT specification, the names are alsoused to decide whether to create new elements or edit existing ones. For example, ifthe CORBAInterface already exists, only new operations are added. An imperativepseudo code specification for this mapping is as follows:
create Transclient Interface;add moneyTransfer(..) to Transclient Interface;create AccountManager Interface;add withdraw(amount) to AccountManager Interface;
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 549
lt:T
ype
l:L
ifel
ine
ci:C
OR
BA
Inte
rfac
e
nam
e=
lt.n
ame
o:O
per
atio
nn
ame
=m
.nam
ety
pe
=m
t.n
ame
visi
bil
ity=
m.v
isib
ilit
yp
:Par
amet
er
p:P
aram
eter
me:
Mes
sag
eEn
d
m:M
essa
ge
mt:
Typ
el1
t:T
ype
l1:L
ifel
ine
as:A
sso
ciat
ion
rme
:Mes
sag
eEn
d
m:M
essa
ge
ci2
:CO
RB
AIn
terf
ace
nam
e=l
2t.n
ame
ci1:
CO
RB
AIn
terf
ace
nam
e=
l1t.
nam
e
l2t:
Typ
e
l2:L
ifel
ine
sme:
Mes
sag
eEn
d
Life
line
2C
orba
Inte
rfac
e_p
1(l1
,ci1
) an
d Li
felin
e2C
orba
Inte
rfac
e_p
1(l2
,ci2
)
ae2:
Pro
per
ty
ae1
:Pro
per
ty
{ae
2.is
Na
vig
ab
le
()=
tru
e}
* +re
ceiv
eEve
nt *
**C
E
*
*
+rec
eive
Eve
nt
+sen
dEve
nt
+as
soci
atio
nEnd+as
soci
atio
nEnd
{whe
n}
CE
Lif
elin
e2C
orb
aIn
terf
ace
_p
1(l:
Lif
elin
e, c
i:C
OR
BA
Inte
rfac
e
Lif
elin
e2
Co
rbaI
nte
rfac
e_p
2(m
:Mes
sag
e,
as:A
sso
cia
tio
n
Fig
.9.
QV
Tpri
mary
model
mappin
gsp
ecifi
cati
on.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
550 A. Solberg et al.
add deposit(amount) to AccountManager Interface;add directed association between Transclient and AccountManager
The resulting CORBA specification is shown in Fig. 14.
3.4. Acquire aspect mapping
When developing aspect mapping we want to utilize the transaction service providedby CORBA. The mappings to transform the PIM transaction aspect shown inFig. 6 must include all interactions that involve the TransactionManager and alltransactional interactions between Participants and Transclient. These are groupedinto six sets of mappings as follows:
(i) The openTransaction message from Transclient to TransactionManager.(ii) The join message from Participant to TransactionManager.(iii) The closeTransaction message from Transclient to TransactionManager.(iv) The abortTransaction message from Transclient to TransactionManager.(v) The canCommit message from TransactionManager to Participants.(vi) Other mappings involving decisionCommit(commit), decisionAbort(abort),
doCommit and doAbort.
We describe the aspect mappings first using an imperative style and we thengive examples of how they can be expresses using QVT:
//openTransaction pseudo code mapping specification:replace TransactionManager by {ORB; CurrentHelper; Current;}replace openTransaction message from Transclient to TransactionManager by {resolve initial references(“TransactionCurrent”) from Transclient to ORB;narrow(..) from Transclient to CurrentHelper;}add set timeout(time) message from Transclient to Current;add begin() message from Transclient to Current;
//join pseudo code mapping specification:replace TransactionManager by {Control; Coordinator;}replace join(Tid, Pid) message from Participant to TransactionManager by {
get control from Participant to Current;get coordinator from Participant to Control;register resource(Pid) from Participant to Coordinator;
}delete add participant message from TransactionManager to TransactionManager;
//closeTransaction pseudo code mapping specification:replace closeTransaction message from Transclient to TransactionManager by com-mit(TRUE) from transClient to Current.
//abortTransaction pseudo code mapping specification:replace abortTransaction message from Transclient to TransactionManager by roll-back() from Transclient to Current.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 551
//canCommit pseudo code mapping specification:replace canCommit message from TransactionManager to Participants by prepare()from Current to Participants.·// Other pseudo code mapping specification:delete decision(commit) message from TransactionManager to Transclient.delete decision(abort) message from TransactionManager to Transclient.replace doCommit message from TransactionManager to Participants by commit()from Current to Participants..replace doAbort message from TransactionManager to Participants by rollback()from Current to Participants.
The initiateVotingPhase and initiateCompletionPhase messages have noCORBA equivalents. They are retained in the model to provide logistical infor-mation to developers. However, no mappings are applied to them.
The derived target of the open transaction is shown in Fig. 10. Figure 11(a)shows the source part of the mapping for the open transaction. This pattern isbasically to recognize the openTransaction message between the Transclient andthe TransactionManager..
The mapping used to derive the CORBA target model is shown in Figs. 11(b),(c) and (d). The target model is obtained in three steps. The first two steps producethe operation/return message pairs; resolve initial references(txnString) and nar-row(tObj) (see Figs. 11(b) and (c)). The specification of the set timeout(time) andthe begin() operations are shown in Fig. 11(d).
The derived target of the join transaction is shown in Fig. 12. Figure 13(a) showsthe source part of the QVT mapping for the join message. This pattern essentiallyrecognizes the join message between the Participant and the TransactionManager.The corresponding mapping specification to derive the CORBA target Model isshown in Figs. 13(b), (c) and (d).
As the example illustrates the mapping specifications of both the open transac-tion and the join are complex. This is because these specific messages need to betreated explicitly in order to utilize the CORBA transaction service and follow therequired protocols.
sd Transaction
:Transclient
operation (…)
tObj
cur:Currentch:CurrentHelpero:ORB
narrow (tObj)
curset_timeout(time)
resolve_initial_references (txnString)
begin ()
Fig. 10. Open transaction CORBA counterpart.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
552 A. Solberg et al.
openTransaction2CorbaOpenTransaction(i,i_c:InteractionMM)
tct:Type
tc:Lifeline
me_s:MessageEnd
m:Message
+sendEvent
i:Interaction
name=’Transclient’
tmt:Type
tm:Lifeline
me_r:MessageEnd
1
+receiveEvent
name=’TransactionManager’
name=’openTransaction’
tc_ct:Type
tc_c:Lifeline
m1a:ValueS..
me1:MessageEnd
m1:Message
+sendEvent
m1at:Type
i_c:Interaction
name=tct.name
orbt:Type
orb:Lifeline
me2:MessageEnd+receiveEvent
name=’orb’
name=’resolve_intila_references’messageSort=’synchCall’me3:MessageEnd
m2:Message
+receiveEvent
me4:MessageEnd
+sendEvent
name=’tObj’messageSort=’reply’
m1t:TypeName=’CORBA.object’
tc_ct:Type
tc_c:Lifeline
m3a:ValueS..
me5:MessageEnd
m3:Message
+sendEvent
m3at:Type
i_c:Interaction
name=tct.name
cht:Type
ch:Lifeline
me6:MessageEnd
+receiveEvent
name=’CurrentHelper’
name=’narrow’messageSort=’synchCall’
me7:MessageEnd
m4:Message
+receiveEvent
me8:MessageEnd
+sendEvent
name=’cur’messageSort=’reply’
m3t:Type
Name=’Current’
name=’tObj’
tc_ct:Type
tc_c:Lifeline
me9:MessageEnd
m5:Message
+sendEvent
i_c:Interaction
name=tct.name
curt:Type
cur:Lifeline
me10:MessageEnd
+receiveEvent
name=’Current’
signature=’set_timeout(time)’messageSort=’synchCall’
me11:MessageEnd
m6:Message
+sendEventme12:MessageEnd
+receiveEvent
signature=’begin()’messageSort=’synchCall’
name=’txnStringname=’String’
name=’CORBA.object’
EC
Fig. 11. QVT mapping of the open transaction part of the aspect model.
sd Transaction:Participant
get_coordinator ()
opt [joined=false]
cur:Current cor:Coordinator
register_resource(Pid)
ctrl
ctrl:Control
cor
get_control()
Fig. 12. Join transaction CORBA counterpart.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 553
pt:Type
p:Lifeline
a:ValueSpecification
me_s:MessageEnd
m:Message
+sendEvent
pt:Type
i:Interaction
name=’Participant’
tmt:Type
tm:Lifeline
Me_r:MessageEnd
1
+receiveEvent
name=’TransactionManager’
name=’join’
p_ct:Type
p_c:Lifeline
me19:MessageEnd
m10:Message
+sendEvent
i_c:Interaction
name=pt.name
curt:Type
cur:Lifeline
me20:MessageEnd+receiveEvent
name=’Current’
name=’get_control’MessageSort=’synchCall’
me21:MessageEnd
m11:Message
+receiveEvent
me22:MessageEnd
+sendEvent
name=’ctrl’MessageSort=’reply’
m10t:TypeName=’Cont
rol’
p_ct:Type
p_c:Lifeline
me23:MessageEnd
m12:Message
+sendEvent
name=pt.name
ctrlt:Type
ctrl:Lifeline
me24:MessageEnd+receiveEvent
name=’Control’
name=’get_coordinator’MessageSort=’synchCall’
me25:MessageEnd
m13:Message+receiveEvent
me26:MessageEnd
+sendEvent
name=’cor’MessageSort=’reply’
m12t:TypeName=’Coordin
ator’
p_ct:Type
p_c:Lifeline
me27:MessageEnd
m14:Message
+sendEvent
i_c:Interaction
name=pt.name
cort:Type
cor:Lifeline
me28:MessageEnd+receiveEvent
name=’Coordinator’
name=’register_resource’MessageSort=’synchCall’
M1t:Type
name=’boolean’
name=’tid’name=String
m12a:ValueS..
+argument
name=’Pid’
m10t:Typename=’Parti
cipant’
join2CorbaJoin(i, i_c:InteractionMM)
pt:Type
p:Lifeline
a:ValueSpecification
me_s:MessageEnd
m:Message
+sendEvent
pt:Type
i:Interaction
name=’Participant’
tmt:Type
tm:Lifeline
Me_r:MessageEnd
1
+receiveEvent
name=’TransactionManager’
name=’join’
p_ct:Type
p_c:Lifeline
me19:MessageEnd
m10:Message
+sendEvent
i_c:Interaction
name=pt.name
curt:Type
cur:Lifeline
me20:MessageEnd+receiveEvent
name=’Current’
name=’get_control’MessageSort=’synchCall’
me21:MessageEnd
m11:Message
+receiveEvent
me22:MessageEnd
+sendEvent
name=’ctrl’MessageSort=’reply’
m10t:TypeName=’Cont
rol’
p_ct:Type
p_c:Lifeline
me23:MessageEnd
m12:Message
+sendEvent
i_c:Interaction
name=pt.name
ctrlt:Type
ctrl:Lifeline
me24:MessageEnd+receiveEvent
name=’Control’
name=’get_coordinator’MessageSort=’synchCall’
me25:MessageEnd
m13:Message+receiveEvent
me26:MessageEnd
+sendEvent
name=’cor’MessageSort=’reply’
m12t:TypeName=’Coordin
ator’
p_ct:Type
p_c:Lifeline
me27:MessageEnd
m14:Message
+sendEvent
i_c:Interaction
name=pt.name
cort:Type
cor:Lifeline
me28:MessageEnd+receiveEvent
name=’Coordinator’
name=’register_resource’MessageSort=’synchCall’
M1t:Type
name=’boolean’
name=’tid’name=String
m12a:ValueS..
+argument
name=’self’
m10t:Typename=’Parti
cipant’
EC
(d)
(b)
(c)
(a)
Fig. 13. QVT mapping for the join transaction part of the aspect model.
However, since transactions are application independent, the mappingspecification is highly reusable. In the example, we can recognize appearance ofa repeating pattern that is used in order to specify the derivation of the target.Thus, it may be possible to obtain more powerful mapping specifications throughparametrized patterns.
3.5. Apply mapping
Figure 14 shows the CORBA IDL interface generated by applying the PIM to PSMmappings specified in Fig. 9 to the primary model shown in Fig. 5. Applying themapping of the aspect model (partly specified in the previous section) will resultin an interaction model as shown in Fig. 17 (this model is further prepared forinteraction model composition).
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
554 A. Solberg et al.
<<CORBAInterface>>TransferClient <<CORBAInterface>>
AccountmoneyTransfer (acc1:string, acc2:string,amount:double)
withdraw ( amount:double)deposit(amount:double)
Fig. 14. Generated interfaces based on UML profile for CORBA.
3.6. Model composition
The composition of class models is done as described in our previous work.13,16,39,46
This subsection describes composition of interaction models.For composition of interaction models we have defined a set of tags to mark the
aspect model and primary model. We specify the tags as metamodel elements thatextend the UML metamodel using UML sterotypes. The particular tags define thetype of composition that needs to occur between the primary interaction model andaspect interaction models.
3.6.1. Tagging the primary model
The primary interaction model is tagged to identify the set of lifelines and messagesto which the aspect will be applied. This is similar to defining join points in AspectOriented Programming (AOP),25 but in our model tagging approach join pointsneed to be added to the primary model and not the aspect model. The notion oftags in the primary model interaction diagram plays a similar role as the notion ofsignatures in the class diagram composition described in Ref. 39. The interactiondiagram composition occurs under the assumption that the default message flow isspecified in the primary interaction model. When the primary model messages aretagged, the corresponding aspect model is composed.
Before composition, the primary model is tagged to define where in the pri-mary model the aspects are composed. Figure 15 shows the banking scenario and
<<CORBAInterface>>:MoneyTransferService
moneyTransfer(acc1, acc2,amount)
withdraw(acc1, amount]
deposit(acc2, amount)
-acc1, acc2:string-amount:double
<<CORBAInterface>>am1:AccountManager
<<CORBAInterface>>am2:AccountManager
am1=lookup(acc1)
am2=lookup(acc2)
sd Money transer
<<aspect>> Transaction(’twophaseCommit’)
Fig. 15. Primary model tagged with aspects.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 555
where the transaction aspect should be weaved into the model. The <<aspect >>
stereotype is used to model aspect tags. The transaction aspect in the primarymodel is a stereotyped combined fragment that encompasses the transactionalmethod calls. Combined fragments are constructs defined for interaction diagrams inUML 2.0.
The rationale for stereotyping concrete UML interaction modeling elementsis to enable this kind of aspect tagging using available UML tools. Theaspect tags include a message template as follows: <<aspect >> <aspectname>
(<paramlist >*)[(<bindspecification >*)].The aspectname refers to the aspect model that needs to be composed (e.g.
Transaction). The <paramlist > is a list of zero or more parameters used to con-figure the aspect. For example, one-phase or two-phase commit transaction pro-tocols can be assigned to an input parameter for a transaction aspect to specifythe transaction protocol to use. The binding specification part of the tag can beeither explicit or implicit. An explicit binding specification has the following form<lifelinePM>:<lifelineAM>, where lifelinePM is the lifeline of the primary modelthat should be bound to the particular lifeline template of the aspect interactionmodel (lifelineAM ). The binding specification is optional and is only required whenthere is ambiguity in the binding semantics. If the binding specification is not shownexplicitly, the tags provide implicit binding semantics. The implicit binding speci-fication is used in this example.
3.6.2. Aspect model tags
The aspect interaction model is tagged based on a defined schema. Aspect modelsare tagged to identify parts of an aspect model that perform different roles whencomposed with a primary model. The composition is executed based on the definedsemantics of the tags. The aspect model tags are presented in Fig. 16.
The aspect model tags are stereotypes of interaction fragments. The tags in theaspect model are defined with well defined semantics.
The <<begin >> tag defines the sequence of the aspect model that will appearin the beginning of the aspect tag. Thus, whenever there is an aspect tag in theprimary model that shall be composed with the aspect model, the begin sequenceappears exactly once for every aspect tag.
The <<body>> tag defines the sequence fragment that will refine each messageencompassed within the primary model aspect tag. For every message encompassedby the aspect tag in the primary model, the message is refined by the sequencefragment in the body part of the aspect model. The semantics of the messages inthe primary model should be maintained during the refinement.
The <<before>> tag defines the sequence fragment that will appear beforeeach message in an aspect tag in the primary model.
The <<after>> tag defines the sequence fragment that will appear after eachmessage in the aspect tagged primary model.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
556 A. Solberg et al.
|A |B
<<begin>>
<<before>>
<<after>>
<<end>>
<<body>>
Sequence appearing in the beginning of the composite aspect
Sequence embedding/replacingeach message in the composite aspect
Sequence appearing before each message in the composite aspect
Sequence appearing aftereach message in the composite aspect
Sequence appearing at the end of the composite aspect
AspectModelTags
Fig. 16. Composite aspect fragment tags.
The <<end>> tag defines the sequence fragment that will appear at the end ofthe aspect tag. Thus, whenever the composite tag in the primary model is composedwith the aspect model, the end sequence appears exactly once for every associatedaspect tag.
The tags listed above will appear in the aspect model and not in the primarymodel. Furthermore, one or more of the above tagged fragments are required tocompose the aspect model using a primary model aspect tag, but it is not necessarythat all fragments should exist in the aspect model.
Template notation as described in Refs. 13, 16 and 39 is used for merging andcomposition. Templates are specified using the “|” notation. It is defined defaultsemantics for the merging of each template message in the aspect model with thecorresponding message in the primary model.
3.6.3. Compose aspect and primary models
Once the primary model is tagged, the aspects and the primary model are composedusing the bindings and the composition directives associated with the tags, to obtainan integrated design view referred to as the composed model.
The tagged primary interaction model is shown in Fig. 15. The correspondingtagged transaction aspect model is shown in Fig. 17. The aspect model is structuredaccording to the defined fragment schema by means of the aspect model tags. Thetransaction aspect model is fragmented into a <<begin >> sequence, a <<body>>
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 557
sd Transaction(t:transProtocol)
:|TransClient :|Participant
tObj
get_coordinator ()
|transOperation (cur,|params )
do_|transOperation (Tid,|params )
[joined=false]
commit(TRUE)
alt
Loop [noVoteExist or yesFromAll]<<multicast>> prepare ()
<<multireceive >> VoteRollback/VoteCommit/VoteReadOnly
opt rollback()
OnePhaseCommit
alt<<multicast> commit()
:Participants ch:CurrentHelpero:ORB
narrow (tObj)
curset_timeout(time)
resolve_initial_references (txnString)
begin ()
cor:Coordinator
register_resource (self)
ctrl
ctrl:Control
cor
get_control()
cur:Current
[t=2phaseCommit ]
[t=1phaseCommit ]
[decisionCommit]
[decisionAbort ]
+Tid, Pid:string+<<CORBAEnum>> transProtocol{onePhaseCommit , twoPhaseCommit}+t:transProtocol+transactionAborted , timeOut, decisionAbort , decissionCommit :boolean
<<begin>>
<<body>>
opt
<<end>>
initiateCompletionPhase ()
opt timeOut
par
break [transactionAborted or timeOut ] initiateCompletionPhase ()
ref
processCommit
<<multicast> rollback()
processRollback
Fig. 17. Tagged aspect model.
sequence and an <<end>> sequence. It does not have any <<before>> and<<after>> fragments.
The composition of the transaction aspect interaction model with the primaryinteraction model is done using the implicit binding semantics of the compositetag. This binding semantics stipulates that the lifeline from which a primary modelmessage within the aspect tag originates will be bound to the corresponding lifelinetemplate in the aspect model, and the lifeline to which the message is received willbe bound to the corresponding template lifeline in the aspect model.
The result of composing the transaction aspect model with the primary modelis shown in Fig. 18. Using the implicit binding semantics, the |TransClient is boundto the MoneyTransferService and the |Participant to am1:AccountManager andam2:AccountManager respectively. The message in the aspect |transOperation(cur,
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
558 A. Solberg et al.
sd Transaction(t:transProtocol)
:MoneyTransferService am1:AccountManager
tObj
get_coordinator ()
withdraw(cur, acc1, amount )
do_withdraw(Tid, acc1, amount )
[joined=false]
am2:AccountManager
ch:CurrentHelpero:ORB
narrow (tObj)
curset_timeout (time)
resolve_initial_references (txnString)
begin ()
cor:Coordinator
register_resource (self)
ctrl
ctrl:Control
cor
get_control()
cur:Current
+Tid, Pid:string+<<CORBAEnum>> transProtocol{onePhaseCommit , twoPhaseCommit}+t:transProtocol+transactionAborted , timeOut, decisionAbort , decissionCommit :boolean
opt
<<end>>
get_coordinator ()
deposit (cur, acc2, amount )
[joined=false]
register_resource (self)
ctrl
cor
get_control()opt
do_deposit (Tid, acc2, amount)
Fig. 18. Composed interaction model.
|params) is sent by the |TransClient and received by the |Participant. Based on therules defined for aspect model tags, the <<begin >> fragment is the first sequenceto appear. A <<body>> sequence is applied to each message within the compos-ite fragment, hence, the <<body>> is applied to the withdraw and deposit mes-sages. The resultant behavior must exhibit the semantic properties of the withdrawand deposit messages defined in the primary model. The do |transOperation(Tid,|params) template message in the body fragment of the transaction aspect interac-tion model results in the do withdraw and do deposit message instantiations. Theinteraction diagram composition technique merges all the template messages ofthe transaction aspect interaction model defined within the tag fragments with themessages from the money transfer interaction model.
During the merge, the cur (cur includes reference to the transaction context) isinserted. The Tid represents the participant internal reference to the transaction.The <<end>> sequence appears in the composed model at the end of the sequenceof messages, similar to the <<begin >> sequence that appears at the start. The<<end>> sequence is the final sequence of interactions between primary modelelements and aspect model elements and appears only once. The end sequence isshown in Fig. 18 as a reference fragment, and is according to the sequence specifiedin Fig. 17. If the model is expanded and shown in full, the end sequence will be a
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 559
two-phase commit protocol sequence, since the input parameter in the compositetagged primary model specifies a two-phase commit protocol.
3.7. Discussion
The example presented in this section shows that the AOMDF is feasible for thepresented case. More case studies are needed to further investigate the feasibilityof AOMDF. We recently finished another case study using AOMDF to constructadaptable systems, using aspects for adding and configuring pervasive system ser-vices. In this case study we also generated implementation code, running on anadaptive middleware. The results of this case study are presented in a recently sub-mitted paper. We have also worked on a case study based on the banking exampleusing JINI as the middleware platform. The experiences with these case studiesare that AOMDF provides a feasible approach, but different platforms have theirparticularities that are not always easy to account for in the transformation speci-fications. This is both due to limitations in the transformation languages used, anddue to the semantic gap between generic PIM’s and properties provided by a partic-ular platform. For instance, the example in this paper presents a generic transactionmodel that captures the essence of distributed transactions at the PIM level. Thegeneric model is then assumed to be transformed to utilize the specific protocol ofa particular middleware. In principle this should be a straightforward transforma-tion, since transaction management theory is well defined (e.g. Ref. 6). In practice,it can be more troublesome since middleware vendors can provide proprietary solu-tions for transaction control and optimizations of transactions. In this CORBA casestudy, the transformation from the generic transaction model to CORBA specifictransactions appeared to be quite simple.
AOMDF is dependent on mature model transformation and model compositiontechnologies. Currently, model transformation technologies are still immature, andmodel composition is not very well investigated. One challenge is how to resolveconflicts that can occur if more than one aspect is composed with the primarymodel. Also, how to ensure consistency between different views (e.g. behavioralviews and structural views in UML interaction diagrams and class diagrams) whencomposing aspect models with the primary model, is a key concern that is not yetsolved.
4. Related Work
Atkinson and Kuhne3 describe an approach combining model driven and aspectoriented development. In this approach, aspect oriented techniques are used forrefining specific aspects of the model (vertical separation of concerns) using archi-tecture stratification. Typically new aspects like encryption for security will appearat a lower level stratum. This approach differs from our approach in that the aspectsare not composed, but represent refinements of a particular part of the model at
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
560 A. Solberg et al.
higher level stratums. Thus, each stratum represents the whole system. The notionof separating vertical and horizontal concerns and defining separate mappings forthese, are not part of this approach. In Atkinson and Kuhne,3 possible refinementsare defined as pattern-based aspects and applied through framework instantiations.In our approach, compositions and transformations are the mechanisms used.
Several researchers have done work on developing transformation languages andtools. ArcStyler,2 EXMOF,33 Objecteering,31 Atlas model weaver4 and Tarzan/XMorph11 are some of these. TopModl30 is an international open-source initiativelaunched to provide an extensible framework for model-driven experimentation.Most of the tools/languages are either imperative or declarative. The proposedframework shown in the paper uses both declarative and imperative languages fortransformations and hence can be used in a wider scope.
Jacobson22,23 describes the development of design aspects based on use cases,which are then composed to create different views of the system. The work mapsdirectly to program level aspects, using the composition techniques originally devel-oped for AspectJ.12 The work does not explicitly give details about transformationof models, rules of composition, structural relations, etc.
Reina, Toress and Toro40 propose the use of metamodels and UML profiles forthe separation of concerns at the PIM and PSM levels. The problem with thisapproach is that a different metamodel is required for every new concern.
In the aspect-oriented modeling approach proposed by Clarke et al.,5 a designcalled a subject is created for each system requirement. A comprehensive designis a composition of subjects. Subjects are expressed as UML model views, andcomposition merges the views provided by the subjects. The approach does notdeal with the vertical separation of concerns.
MDD is used by Kulkarni and Reddy27 for providing separation of concernbetween system concerns at both the model and code level using templates andcode weaving. This is similar to the AOM approach we employ, except that weuse parametrized UML to specify aspects and can perform model level compositionavoiding the need for code level weaving.
Ho et al.,19 Ho, Pennaneach and Plouzeau,20 and Jezequel et al.24 present anapproach where specialized stereotypes for each crosscutting concern are intro-duced. They have developed an UMLAUT tool that can be used as a framework forbuilding application-specific weavers to weave multi-dimensional high level UMLdesign models into detailed design models. This is similar to the binding procedurein AOM, where the generic models are instantiated in the context of the appli-cation. UMLAUT uses a form of roles but the treatment of properties is not asextensive.
In Gray et al.17 and Gray et al.,18 they use aspects in domain-specific mod-els that specifically target embedded systems. Requirements, architecture and theenvironment of a system are captured in the form of formal high-level models thatallow representation of concerns. Their research is part of Model-Integrated Com-puting (MIC) and extends the scope and usage of models such that they form the
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 561
backbone of a development process for building embedded software systems. Thework in our research can complement theirs by providing an UML-based approachfor representing aspects and is more generic.
Mellor29 discusses how model-driven architecture can support aspect-orientedmodeling. Their work talks about a framework that brings models and aspect ori-entation together. The research just brings out the issues related to aspects, UML,and MDA. Our approach provides a framework that can be used for developingsoftware using aspect oriented mechanisms.
5. Conclusion and Further Work
Modern systems are complex. Separation of concerns is recognized as a key principleto cope with complexity in software development. In this paper, we have reasonedthat both vertical and horizontal separation of concerns should be provided formanaging complexity in a model driven development.
Aspect-oriented technologies can be used to support horizontal separation ofcrosscutting concerns from other functionality. The AOM approach emphasizes theseparation and modularization of crosscutting concerns in design units (aspects).The AOMDF provides additional support for specifying transformations. TheAOMDF allows us to separate out the mapping specification for pervasive ser-vices from the mapping specification of the primary model. The aspect mappingspecification then becomes reusable and the mapping specification of the primarymodel becomes simpler.
The focus of our aspect oriented framework is to provide separate specificationof crosscutting services to enable better reusability, comprehensibility and evolv-ability of software models. In the web service world, crosscutting services such assecurity and availability can be seen as differentiating properties of web services. Aweb service provider can use our approach as a framework for providing the basicprimary service and let the user make a selection of additional crosscutting ser-vices such as security and availability. An associated differentiation of cost can beexpected due to additional resource requirements (e.g. replication to provide betteravailability).
This paper illustrates the transformation of a platform independent distributedtransaction aspect to a platform specific transaction aspect. We also describe theintegration of the transaction aspect in the context of a net banking application.The example illustrates that the mapping of pervasive services can be complex, forinstance, since we need to obtain specific mappings of specific operations. However,development of mappings is comparable to the development of compilers and is nota task that a regular system developer will do. We expect that when model drivendevelopment becomes more mature and more frequently used, the tools will provideready to use mapping specifications for a wide set of transformations. A systemarchitect will be responsible for configuring the provided mappings appropriatelyaccording to the system or system family at hand.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
562 A. Solberg et al.
Currently we are working on techniques to resolve conflicts that can occur ifmore than one aspect is composed with the primary model. Verifiable compositiontechniques that discharge proof obligations during composition are being developed.
We are also working with more case studies involving different middleware tofurther investigate the feasibility of the approach. Also, we plan to create a reposi-tory of the most common middleware concerns.
References
1. AOSD, Aspect oriented software development, AOSD Webpage (2005), URLhttp://aosd.net/.
2. ArcStyler, ArcStyler (2005), http://www.io-software.com/products/arcstyleroverview.jsp.
3. C. Atkinson and T. Kuhne, Aspect-oriented development with stratified frameworks,IEEE Software 20(1) (IEEE Computer Society, 2003) 81–89.
4. ATL, Atlas Transformatino Language (2005), www.tni-software.com/?p=mda.5. S. Clarke, W. Harrison, H. Ossher and P. Tarr, Separating concerns throughout the
development lifecycle, in Proc. 3rd ECOOP Aspect-Oriented Programming Workshop,Lisbon, Portugal (June 1999).
6. G. Coulouris, J. Dollimore and T. Kindberg, Distributed systems concepts and design(3rd ed.) International Computer Science Series (Addison-Wesley/Pearson Educa-tion, USA, 2001), p. 471.
7. F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi and S. Weerawarana, Unrav-eling the web services: An introduction to SOAP, WSDL, and UDDI, IEEE InternetComputing 6(2) (March/April 2002).
8. K. Czarnecki and S. Helsen, Classification of model transformation approaches, inProc. Workshop on Generative Techniques in the Context of Model-Driven Architec-ture, OOPSLA’03 (2003).
9. M. Deubler, M. Meisinger, S. Rittmann and I. Kruger, Modelling crosscutting serviceswith UML sequence diagrams, in Proc. 8th Int. Conference Models 2005 Conference,eds. L. Briand and C. Williams, ISBN: 3-540-29010-9.
10. D. D’Souza and A. C. Wills, Objects, Components, and Frameworks with UML: TheCatalysis Approach (Addison-Wesley Object Technology Series 1998, 1998) ISBN: 0-201-31012-0.
11. K. Duddy, A. Gerber, M. J. Lawley, K. Raymond and J. Steel, Model trans-formation: A declarative, reusable patterns approach, in Proc. 7th IEEE Inter-national Enterprise Distributed Object Computing Conference (EDOC 2003),pp. 174–185.
12. Eclipse AspectJ, AspectJ project (2005), http://eclipse.org/aspectj.13. R. B. France, I. Ray, G. Georg and S. Ghosh, An aspect-oriented approach to
design modeling, IEE Proceedings — Software, Special Issue on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design 151(4) (August, 2004).
14. N. Furmentol, J. Hau, W. Lee, S. Newhouse and J. Darlington, Implementations of aservice-oriented architecture on top of Jini, JXTA and OGSI, in Proc. of Second Euro-pean AcrossGrids Conference, AxGrids 2004, ed. M. D. Dikaiakos, Nicosia, Cyprus(January 28–30, 2004), ISBN: 3-540-22888-8.
15. T. Gardner, C. Griffin, J. Koehler and R. Hauser, A review of OMG MOF 2.0 Query/Views/Transformations Submissions and Recommendations towards the final Stan-dard MetaModelling for MDA Workshop (York, UK, November 2003).
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
An Aspect Oriented Model Driven Framework 563
16. G. Georg, R. Reddy and R. France, Specifying cross-cutting requirements concerns,in Proc. International Conference on the UML (Springer, October 2004).
17. J. Gray, T. Bapty, S. Neema, D. C. Schmidt, A. Gokhale and B. Natarajan, Anapproach for supporting aspect-oriented domain modeling, in Proc. 2nd Int. Confer-ence on Generative Programming and Component Engineering (GPCE’03), Erfurt,Germany (September 2003).
18. J. Gray, T. Bapty, S. Neema and J. Tuck, Handling crosscutting constraints indomain-specific modeling, Communications of the ACM 44(10) (October 2001)87–93.
19. W. Ho, F. Pennaneach, J. Jezequel and N. Plouzeau, Aspect-oriented design with theUML, in Proc. Multi-Dimensional Separation of Concerns Workshop, ICSE (2000),pp. 60–64.
20. W. Ho, F. Pennaneach and N. Plouzeau, UMLAUT: A framework for weavingUML-based aspect-oriented designs, in TOOLS ’00: Proc. of the Technology ofObject-Oriented Languages and Systems (TOOLS 33) (IEEE Computer Society, 2000),pp. 324–334.
21. ISO, ISO/IEC 10746: Basic reference model for open distributed processing, 1995.22. I. Jacobson, Case for aspects — Part I, Software Development Magazine (October
2003), pp. 32–37.23. I. Jacobson, Case for aspects — Part II, Software Development Magazine (November
2003), pp. 42–48.24. J. M. Jezequel, A. Guennec, F. Pennaneach, G. Sunye and K. Vinceller, The UMLAUT
Web Page (2005), URL http://www.irisa.fr/UMLAUT.25. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingier and J. Irwin,
Aspect oriented programming, in Proc. European Conference on Object-Oriented Pro-gramming (ECOOP), Lecture Notes in Computer Science, Vol. 1241 (Springer, 1997),pp. 220–242.
26. J. Kienzle and R. Guerraoui, AOP: Does it make sense? the case of concurrencyand failures, in Proc. 16th European Conference on Object-Oriented Programming(ECOOP) (Springer-Verlag, 2002), pp. 37–61.
27. V. Kulkarni and S. Reddy, Separation of concerns in model-driven development, IEEESoftware 20(5) (2003) 64–69.
28. F. Leyman, Web Services: Distributed applications without limits, in Proc. BTW’03,Lecture Notes in Informatics, Vol. P-26, Gesellschaft fuer Informatic (GI), Bonn,Germany (2003).
29. S. Mellor, A framework for aspect-oriented modeling, 4th AOM Workshop at UML’03,San Francisco, CA (October 2003).
30. P. A. Muller, P. Studer and J. M. Jezequel, Model-driven generative approach for con-crete syntax composition, in Workshop on Best Practices for MDSD (OOPSLA’2004)(October 2004).
31. Objecteering, Objecteering/Introduction User Guide. Version 5.3 — CODOBJ001/001 (2004), http://www.objecteering.com/downloads documentation.php.
32. OMG-CORBA, UMLTM Profile for CORBATM
version 1.0, formal/02-04-01, 2002.33. OMG-EXMOF, Queries, Views and Transformations on Models using MOF, OCL and
EXMOF, Joint 2nd r. submission, Compuware Corp., SUN Microsystems, ad/2004-10-03, 2003.
34. OMG-MDA, MDATM Guide v1.0.1, Object Management Group (2003), http://www.omg.org/docs/omg/03-06-01.pdf.
35. OMG-QVT, MOF QVT Final adopted specification OMG document ptc/05-11-01(2005), www.omg.org.
October 12, 2006 11:28 WSPC/111-IJCIS SPI-J073 00148
564 A. Solberg et al.
36. OMG-UML, Unified Modeling Language: Superstructure, Version 2.0, OMG, ptc/03-07-06, 2003.
37. H. Ossher and P. Tarr, Using multidimensional separation of concerns to (re)shapeevolving software, Communications of ACM 44(10) (2001) 43–50.
38. I. Ray, R. France, N. Li and G. Georg, An aspect-based approach to modelingaccess control concerns, J. Information and Software Technology 46(9) (July 2004),pp. 575–587.
39. R. Reddy, F. France, S. Ghosh, F. Fleurey and B. Baudry, Model composi-tion — A signature-based approach, The Aspect Oriented Modelling Workshop@ the MoDELS 2005 Conference, Montego Bay, Jamaica (2–7 October 2005),http://www.cs.colostate.edu/models05/workshops.html.
40. A. M. Reina, J. Toress and M. Toro, Towards developing generic solutions withaspects, in Proc. of the Workshop in Aspect Oriented Modeling held in conjunctionwith UML 2004 (October 2004).
41. R. Silaghi, F. Fondement and A. Strohmeier, Towards an MDA-oriented UML pro-file for distribution, in Proc. 8th IEEE Int. Enterprise Distributed Object ComputingConference, EDOC, Monterey, CA, USA (September 2004).
42. D. Simmonds, A. Solberg, R. Reddy, R. France and S. Ghosh, An aspect orientedmodel driven framework, in Proc. EDOC (Enterprise Distributed Object Computing)2005 Conference, Enschede, The Netherlands (19–23 September 2005).
43. A. Solberg, R. France and R. Raghu, Navigating the MetaMuddle, The 4th Int. Work-shop in Software Model Engineering, WiSME 2005, a satellite event of Models 2005,http://www.planetmde.org/wisme-2005/.
44. R. M. Soley, D. S. Frankel, J. Mukerji and E. H. Castain, Model driven architecture —The architecture of choice for a changing world (2001), http://www.omg.org/mda.
45. E. Song, R. Reddy, R. France, I. Ray, G. Georg and R. Alexander, Verifying accesscontrol properties using aspect oriented modeling, Accepted in 10th ACM Sympo-sium on Access Control Models and Technologies (SACMAT), Scandic Hasselbacken,Stockholm (June 1–3, 2005).
46. G. Straw, G. Georg, E. Song, S. Ghosh, R. France and J. Bieman, Model compositiondirectives, in Proc. 7th UML Conference, Lisbon, Portugal (10–15 October 2004).
47. Tata, Tata MasterCraft (2005), http://www.tata-mastercraft.com/index1.asp.48. W3C, Web Service Architecture Working Group (2002), http://www.w3.org/2002/
ws/arch/.