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


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.


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.



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.



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



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.



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



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);



(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.



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.



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.



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



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



<<CORBAInterface>>MoneyTransferService

moneyTransfer(acc1, acc2, amount)



-acc1, acc2:string-amount:double

<<CORBAInterface>>am1: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;



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.



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.



//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.



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.



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=’join’

p_ct:Type

p_c:Lifeline

me19:MessageEnd

m10:Message

+sendEvent

i_c:Interaction

name=pt.name

curt:Type

cur:Lifeline


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


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


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=’join’

p_ct:Type

p_c:Lifeline

me19:MessageEnd

m10:Message

+sendEvent

i_c:Interaction

name=pt.name

curt:Type

cur:Lifeline


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


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


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).



<<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)



-acc1, acc2:string-amount:double



am1=lookup(acc1)

am2=lookup(acc2)

sd Money transer

<<aspect>> Transaction(’twophaseCommit’)

Fig. 15. Primary model tagged with aspects.



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.



|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>>



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)


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,



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)


begin ()

cor:Coordinator


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]


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



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



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



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.



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).



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.



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/.

developing distributed services using an aspect oriented … · aspect oriented software...

Documents