D

MD

a

ARRAA

KASATUMA

1

diHadnRmastAsap

P

l

0d

The Journal of Systems and Software 85 (2012) 525– 545

Contents lists available at ScienceDirect

The Journal of Systems and Software

jo u rn al hom epage: www.elsev ier .com/ locate / j ss

eriving detailed design models from an aspect-oriented ADL using MDD�

ónica Pinto ∗, Lidia Fuentes, Luis Fernándezepartamento de Lenguajes y Ciencias de la Computación, University of Málaga, Spain1

r t i c l e i n f o

rticle history:eceived 13 May 2010eceived in revised form 17 May 2011ccepted 18 May 2011vailable online 12 June 2011

eywords:spect-oriented software developmentoftware architecturesO-ADLheme/UML

a b s t r a c t

Software architects can separate crosscutting concerns more appropriately by using an aspect-orientedADL, concretely AO-ADL. This paper illustrates how aspect-orientation and model-driven developmenttechnologies can be used to enhance the system design phase; by automatically deriving detaileddesigns that take into account the “aspects” identified at the architectural level. Specifically, we havedefined model-to-model transformation rules to automatically generate either aspect-oriented or object-oriented UML 2.0 models, closing the gap between ADLs and the notations used at the detailed designphase. By using AO-ADL it is possible to specify separately crosscutting concerns and base functionality.Another advantage of using AO-ADL is that it allows the specification of parameterizable architectures,promoting the definition of architectural templates. AO-ADL, then, enforces the specification of crosscut-ting concerns as separate architectural templates, which can be later instantiated and integrated with

ML 2.0odel-driven development

TL

the core functionality of the system being developed. The AO-ADL language and the transformation rulesfrom AO-ADL to UML 2.0 are available throughout the AO-ADL Tool Suite, which can be used to progres-sively refine and elaborate aspect-oriented software architectures. These refined architectures are thestarting point of the detailed design phase. This means that our approach provides support to automat-ically generate a skeleton of the detailed design that preserves the information about the crosscuttingand the non-crosscutting functionalities identified and modelled at the architecture level.

. Introduction

Architecture description languages (ADLs) deal with theescription, analysis and reuse of software architectures, provid-

ng an appropriate high-level view of complex software systems.owever, in spite of the importance of describing the softwarerchitecture of a system, ADLs are not extensively used. This is notue to the lack of ADLs, since there is a significant number of them,ot only those based on formalisms (ACME, Garlan et al., 1997;APIDE, Luckham et al., 1995; and C2, Medvidovic et al., 1996), butore modern ones based on XML (xADL, Dashofy et al., 2001). Some

spect-oriented (AO) ADLs have recently emerged, promoting thepecification of crosscutting concerns separately as aspects (Aspec-ualACME, Garcia et al., 2006; AspectLEDA, Navasa et al., 2009;O-ADL, Pinto et al., 2011), but neither are widely used. We con-

ider that the reasons are mainly related to the lack of appropriaterchitectural tool support and the lack of connection with the nexthases of the software development.

� Supported by Spanish Project TIN2008-01942 and the regional project FamWare09-TIC-5231.∗ Corresponding author. Tel.: +34 952132796; fax: +34 952131397.

E-mail addresses: pinto@lcc.uma.es (M. Pinto), lff@lcc.uma.es (L. Fuentes),fernandez@lcc.uma.es (L. Fernández).

1 http://caosd.lcc.uma.es.

164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved.oi:10.1016/j.jss.2011.05.026

© 2011 Elsevier Inc. All rights reserved.

On the one hand, there is a clear gap between ADLs and the nota-tions used in later phases of the software development – whilemost ADLs are based either on formalisms, XML or define newad hoc notations, the most widely used modelling language atdetailed design is UML. The consequence is that software engi-neers do not usually take advantage of the potential of ADLs. Whena high-level architecture is provided it is usually modelled usingthe UML component diagrams, which define a very restricted ver-sion of the connector concept present in most ADLs. On the otherhand, tool support is needed to specify, reuse and reason about soft-ware architectures. Moreover, a key issue is to provide tool supportalso to generate a skeleton of the detailed design from informa-tion available at the software architecture, without losing relevantinformation. It would be desirable that the skeletons were automat-ically generated. This happens with the traditional ADLs and alsowith recent approaches, specifically with aspect-oriented ADLs, thesubject of this paper. This means that the advantages of separatingcrosscutting concerns at the architectural level, using an aspect-oriented approach, are lost when the designer wants to refine thearchitecture until the detailed design (Chitchyan et al., 2007).

In this paper we show our experience using Model-DrivenDevelopment (MDD) (Beydeda et al., 2005) to enhance the archi-

tectural design phase by coping with the previously mentionedshortcomings. Firstly, at the architectural level we use the AO-ADL language, which is an aspect-oriented ADL that models both

5 tems and Software 85 (2012) 525– 545

cetctoc

riaroict

sag

dtUoantocd

2

2

eekiaabomt

iaMmef

aoc

rmrts

Target ModelSource Model

Target MetaModelSource MetaModel

Conforms ToConforms To

Aut

omat

ic M

odel

T

rans

form

atio

n

26 M. Pinto et al. / The Journal of Sys

rosscutting1 and non-crosscutting concerns as components, andxtends the semantic of classical ADLs connectors with an aspec-ual composition relationship, defining the so called aspectualonnectors. Moreover, AO-ADL defines (aspectual) architecturalemplates, which are mainly used to specify generic aspect-riented prefabricated solutions modelling recurrent crosscuttingoncerns.

Secondly, our approach defines model-to-model transformationules from AO-ADL to either UML 2.0 or to Theme/UML, whichs an aspect-oriented extension of UML 2.0. Following the MDDpproach, these transformations are defined in terms of a set ofules that map elements of the metamodel of AO-ADL to elementsf the metamodels of either UML 2.0 or Theme/UML. Thus, depend-ng on the target implementation platform, the designer is able tohoose to automatically generate an aspect-oriented design solu-ion, or an object-oriented one.

Finally, the AO-ADL Tool Suite is an Eclipse plug-in that providesupport to specify AO-ADL software architectures and to definend instantiate reusable architectural templates. Moreover, it inte-rates the MDD transformation rules that we propose in this paper.

After this introduction, related work on MDD and AOSD isescribed in Section 2. Then, the motivation for using AO-ADL athe architectural level instead of modelling the whole system usingML 2.0 is discussed in Section 3. Section 4 provides an overviewf the use of MDD to close the gap between software architecturend design, while the details are provided in Section 5 using a run-ing example. Section 6 describes the technical details, includinghe AO-ADL Tool Suite. The quantitative and qualitative evaluationf our approach, as well as the discussion of interesting issues con-erning MDD that were identified during its implementation areescribed in Section 7. Finally, Section 8 presents our conclusions.

. Related work

.1. Model-driven development

Model-Driven Development (MDD) (Beydeda et al., 2005; Stahlt al., 2006) is an approach to software development where mod-ls are used not only for illustrative purposes, but they also play aey role in software construction. Using MDD, a software systems created through the definition of different models at differentbstraction layers, where models of a certain abstraction layer areutomatically derived from models of the upper abstraction layery means of model transformations. This facilitates the separationf target model details from the input model, i.e., target models areore refined versions of source models. These refinements con-

inue until a complete implementation of the system is obtained.Fig. 1 shows the different elements required when perform-

ng a model transformation. The first elements that we need are source model (e.g., a component model described in UML, Objectanagement Group, 2005b) and a target model (e.g., a refined UMLodel that includes platform specific issues), which will be initially

mpty. Elements of the target model are automatically constructedrom the elements of the input model.

In order to make a model transformation feasible, both the input

nd the output models must have been precisely constructed inrder to allow computers to process them, i.e., both models mustonform to a metamodel, which specifies their precise abstract

1 Quality attributes (e.g. usability, security), normally classified as non-functionalequirements, are typical crosscutting concerns. There are also functional require-ents that have a crosscutting behaviour and are classified as extra-functional

equirements. For the sake of simplicity, in this paper we will refer to crosscut-ing concerns, non-functional requirements and extra-functional requirement asynonyms, although strictly speaking they are not.

Fig. 1. Scenario of a model transformation.

syntax (Kühne, 2006). These metamodels are constructed usinga metamodelling language (e.g., MOF, Object Management Group,2006). Additionally, these models need to be stored in a standardand interoperable format that the different model-driven tools canmanipulate (e.g., XMI, Object Management Group, 2005a). Finally,a model transformation specifies the rules for generating auto-matically the corresponding output model from an input model.These transformations are specified using a model transformationlanguage, such as QVT (Object Management Group, 2006).

Sometimes, such transformations may need some additionalinformation that is not contained in the input models. For instance,when several candidate transformations exist for the same inputelement, the transformation process may need to know which con-crete transformation has to be executed. This extra information isprovided by means of marks, defined as “lightweight, non-intrusiveextensions to models that capture information required for modeltransformation without polluting those models” (Mellor et al.,2004). In this case, as marking a model is a manual process, thetransformation process is said to be semiautomatic.

Currently, there are several specific approaches that follow theMDD paradigm. The Model-Driven Architecture (MDA) (Melloret al., 2004; Object Management Group, 2003) and Software Fac-tories (SF) (Greenfield et al., 2004) are worth a special mention.Readers interested in similarities and differences between MDA andSoftware Factories can refer to the work of Demir (2006). MDA andSF propose a set of languages, tools and technologies for specify-ing metamodels, model transformations and other issues related toMDD. They also define a methodology for adopting MDD practicesin the software development lifecycle. In this paper, we have optedfor using the set of standards proposed by MDA, as they are publiclyavailable, and they do not impose the use of any proprietary tool.

The specifications of the MDA technologies are proposed by theOMG (Object Management Group). They are then implemented,to a greater or a lesser extent, by different companies and orga-nizations that answer to the Request For Proposals (RFP) madeby the OMG. Among the most popular standards defined by theOMG we have: (1) the MOF (Meta-Object Facility) language todescribe metamodels. Since MOF is too large to be fully imple-mented, usually a subset of it called EMOF (Essential MOF) it isimplemented such as, for instance, the Ecore implementation ofMOF proposed by the Eclipse Foundation; (2) the UML (ObjectManagement Group, 2005b) modelling language of which there

are many implementations (MagicDraw UML, IBM Rational Rose,. . .) not all of them compatible with each other; (3) the XMI stan-dard format for exchanging models. XMI allows the serialisation of

tems a

mMtQAE

2

icacsowscwei

sBRpatahe2(tmac

eeaapDtwetgccanp

isitsl

M. Pinto et al. / The Journal of Sys

odels conforming to the MOF metamodel in an XML document.any UML modelling tools implement XMI serialisation but, again,

hey are not always fully compatible with each other, and (4) theVT (Query View Transformation) model transformation language.mong its implementations we highlight ATL, integrated with theclipse IDE and the Ecore metamodel.

.2. AO software architectures

Aspect-Oriented Software Development (AOSD)2 aims tomprove the separation and modular representation of crosscuttingoncerns by introducing a new decomposition dimension namedspect. These concerns would be otherwise tangled– several con-erns coexist in the same software artefact, and/or scattered– theame concern being part of more than one software artefact, withther concerns. New concepts introduced by AOSD are: (1) advice,hich are the aspectual behaviours that will be incorporated to the

ystem; (2) join points, which are well-defined points in the appli-ation, where aspect composition takes place, and (3) pointcuts,hich are means of referring to collections of join points (i.e. are

xpressions that specify every place where an aspectual behaviours injected).

Nowadays, AOSD is applied throughout all the phases of theoftware life cycle (Aspect-Oriented Software Development, 2010;richau et al., 2005; Chitchyan et al., 2005; Loughran et al., 2005;ashid et al., 2010; Sánchez et al., 2010; Tizzei et al., 2011). Inarticular, in recent years, AOSD has significantly been concernedbout the separation, representation and composition of crosscut-ing concerns at the software architecture level. As a result, severalspect-oriented (AO) architecture description languages (ADLs),ave been defined (Garcia et al., 2006; Navasa et al., 2005; Pintot al., 2003; Pessemier et al., 2006; Pérez et al., 2003; Pinto et al.,011), as well as more generic AO software architecture approachesAaltonen et al., 2006; Cuesta et al., 2006). These languages haveo deal with two main issues: (1) the architectural blocks used to

odel crosscutting concerns, and (2) the composition between therchitectural blocks modelling crosscutting and non-crosscuttingoncerns.

With respect to the first issue, there is not a consensus betweenxisting AO architectural approaches (Chitchyan et al., 2005; Batistat al., 2006). While some of them add a new building block namedspect to model crosscutting concerns, others represent aspectss components with a different semantic, or as components thatrovide or require special ‘crosscutting’ interfaces. In this sense,AOP-ADL (Pinto et al., 2003; Fuentes et al., 2007) and Frac-

al (Pessemier et al., 2006, 2004) extend traditional componentsith new a kind of aspectual interfaces. Other approaches, how-

ver, such as AO-ADL (Pinto et al., 2011) (part of our approach inhis paper), AspectualACME (Garcia et al., 2006) and Navasa’s lan-uage (Navasa et al., 2005) use the same building block (e.g. theomponent) to represent both non-crosscutting and crosscuttingoncerns. Finally, in PRISMA (Pérez et al., 2003) aspects are a newbstraction used to define the internal structure of both compo-ents and connectors. For a more extensive comparison of theseroposals see Chitchyan et al. (2005) and Batista et al. (2006).

With respect to the second issue, though there are differencesn existing aspect-oriented ADLs, most of them agree that theemantics of the compositions have to be somehow extended to

ncorporate aspects to an ADL. For instance, in DAOP-ADL, connec-ions are defined outside either components and connectors, in apecific XML-based composition section. A similar approach is fol-owed by Fractal that defines an XML-based aspect binding section

2 http://www.aosd.net.

nd Software 85 (2012) 525– 545 527

in order to describe components and aspects compositions. A dif-ferent approach is followed by AO-ADL and AspectualACME, wherethe information about the composition between components andaspects is encapsulated inside connectors by extending their tra-ditional semantics. Finally, in Navasa et al. (2005) the semanticsof connectors is not modified since in addition to the componentsmodelling aspects, a new kind of component with the role of ‘coor-dinators’ has to be included in order to describe an aspect-orientedsoftware architecture. PRISMA (Pérez et al., 2003) also follows adifferent approach, since aspects are part of both the componentsand connectors specification, and therefore the composition spec-ification is specified inside both components and connectors. Onceagain, an interesting analysis and comparison of this issue has beenperformed in Chitchyan et al. (2005) and Batista et al. (2006).

2.3. MDD and AOSD

This section focuses on those proposals that combine the use ofAOSD and MDD.

AOSD and MDD can be considered complementary technolo-gies. As clearly stated in Aks it (2005); Amaya et al. (2005); Kulkarniet al. (2003), the main motivation for applying AOSD to MDD isto solve the problem that MDD presents regarding the lack of spe-cific mechanisms for the separation of crosscutting concerns withineach abstraction level. If all concerns can be modelled separately ata certain level, that level will become more manageable, extensi-ble and maintainable. In addition, each one of those models will besmaller, more concise, reusable and easier to modify (Amaya et al.,2005).

Most approaches combining MDD and AOSD follow thisapproach. For instance, in Amaya et al. (2005) their main goalis to obtain “separation of aspects” in each MDA level. Anothersimilar approach is presented in Atkinson et al. (2003), whereauthors propose a strategy for obtaining the advantages of AOSDin model-driven and component-based frameworks. Using archi-tecture stratification they identify and relate different architecturalviews to represent crosscutting concerns. These architectural viewsare the basis for their MDD approach.

An alternative approach, closer to ours, consists of applying theMDD philosophy to the development of aspect-oriented applica-tions, by proposing MDD generation processes to transform AOmodels at different phases of the software life cycle. An exam-ple of this approach is our work in Fuentes et al. (2003), in whichMDA helped us to identify that there were different models in ouraspect-component proposal (Pinto et al., 2005).

Another example is the AOMDF (Aspect-Oriented Model DrivenFramework) proposal (Simmonds et al., 2005). AOMDF combinesboth approaches, proposing an MDD framework that providesmechanisms supporting both vertical and horizontal separation ofconcerns. Vertical separation of concerns is supported by provid-ing techniques for transforming the models from one abstractionlevel to another. Horizontal separation of concerns is achieved bymodelling crosscutting concerns separately as aspects.

Other examples are Sánchez et al. (2006) and Navarro (2007)that use MDD to transform AO requirement specifications into AOsoftware architectures using a CAM profile and PRISMA, respec-tively. And the work in Clemente et al. (2011) that transforms anaspect-oriented software architecture specified using the Aspect-Component model into a UML 2.0 model. The proposal in Jacksonet al. (2008) transforms a Theme/UML AO detailed design into anAspectJ implementation. Our approach in this paper complementsthis approach in the sense that we use MDD to transform AO soft-

ware architectures into Theme/UML AO detailed design.

One important difference between these proposals and ourapproach is that many of them focus on models that provide adetailed specification of low level design of both the core func-

5 tems a

ttaoed

ereasipbawucdo

tdtbv

3

tUt

c2ttn

1

2

labeled (AO) and (OO)). The first transformation (box (AO).1) auto-matically generates an AO version of the detailed design usingTheme/UML, an AO extension of UML. In this case we would be

28 M. Pinto et al. / The Journal of Sys

ionality and the aspects (Simmonds et al., 2005). This means thathe definition and implementation of complex model compositionnd transformation mechanisms is required. Unlike this approach,ur proposal focuses mainly on the architecture level – i.e. mod-ls represent a high-level design of both components and aspects,efining more generic transformation processes.

Also, even when these approaches apply AOSD to particular lev-ls of MDD, the ultimate goal of many of them is to combine theesulting models horizontally into a composed model (Simmondst al., 2005), defining specific model composition operators (Kurtevnd Fabro, 2006). From an aspect-oriented perspective, the mainhortcoming of these approaches is that the separation of concernss lost in the latter levels of the MDD stack. In our approach, werovide both possibilities and the software architect can chooseetween: (1) maintaining the separation of concerns throughoutll the models of the development process – i.e. describing the soft-are architecture of applications that will finally be implementedsing an aspect-oriented language or middleware platform, or (2)omposing components and aspects into a plain UML 2.0 to finallyesign and implement the system using more traditional object-riented or component-oriented technologies.

Finally, many current MDD approaches still lack automaticransformation processes (Amaya et al., 2005). In this paper, weemonstrate how our approach has been implemented using MDDransformation tools and how we have integrated these MDD-ased tools into an existing tool-set that supports the specification,isualisation and validation of AO software architectures.

. Motivation

One question that may arise at this point concerns the reasonso use our approach – i.e. the AO-ADL language and the AO-ADL toML transformations, instead of using UML directly to specify both

he software architecture and the detailed design of the system.Concerning the use of the AO-ADL language, although the main

ontributions of AO-ADL have already been published (Pinto et al.,011), and thus a detailed description of the language is out ofhe scope of this paper, we highlight here two features of AO-ADLhat justify its use, instead of using, for instance, UML compo-ent&connector diagrams:

. AO-ADL is an aspect-oriented approach and thus it provides sup-port to model the architecturally-relevant crosscutting concernsof a system separately from the components modelling its corefunctionality. It also provides support to compose architecturalbuilding blocks in an aspect-oriented fashion. UML 2.0 does notprovide this capacity and thus aspect-oriented extensions ofUML would be needed in order to provide the expected benefitsof AOSD. The most used mechanism to extend UML is the UMLprofile. But when the approach we want to model (an aspect-oriented modelling language) differs notably from UML the bestoption is to define a new specific language.

. AO-ADL provides support to specify generic aspect-orientedprefabricated solutions by means of aspectual architectural tem-plates. These architectural templates are the natural way tomodel recurrent crosscutting concerns and their influences onthe core functionalities of the system. By specifying the depen-dencies between the architectural template and the base systemas parameters it is possible to specify generic architectural solu-tions. These generic solutions can be later reused by instantiatingthem in specific application domains. UML does not provide

a built-in notion of architectural styles constraints, so this isan important benefit of AO-ADL compared to UML. Regardingthe tool support, the architectural templates are available forreuse throughout a repository of AO-ADL architectural solutions,

nd Software 85 (2012) 525– 545

defined as part of the AO-ADL Tool Suite. This means that AO-ADLgives support to derive an aspect-oriented software architecturewithout necessarily assuming any previous knowledge aboutaspect-orientation. Instead, architectural templates modellingwell-known crosscutting concerns are ready to be reused bynon-experts in AOSD, by automatically instantiating them usingMDD technologies. An example of an AO-ADL architectural tem-plate will be shown in Section 5.

Regarding the motivations for defining the AO-ADL to UMLtransformations presented in this paper, we consider they couldhelp to smooth the adoption of AO-ADL by third parties. The gen-eration of UML diagrams facilitates the integration of AO-ADL indevelopment processes based only on UML. Also, software archi-tects are supposed to be more familiar with ADLs, or at least withthe concepts modelled by ADLs (the high level structure of thesystem), but programmers do not have to be familiar with ADLs,nor with the complete high level structure of the system. With theAO-ADL Tool Suite, the software architect can generate the archi-tecture in UML which is better understood by low level designersand programmers. Also, these designers and programmers do nothave to be experts in aspect-orientation, since the aspect-orientedconcepts are expressed in standard UML.

On the other hand, we also generate Theme/UML, one of theavailable aspect-oriented extensions of UML. While the genera-tion of UML is appropriate for non aspect-oriented developers,the Theme/UML will help designers who are expert in aspect-orientation to preserve the “aspects” identified at architecturallevel, in the detailed design. So, we fill the gap between aspect-oriented architecture and detailed design, one of the goals of theAO development methodology (AO DM, the main result of theAOSD-Europe project) in which AO-ADL is integrated.3 Regardingthe implementation level, several possibilities have been studied toautomatically generate code for AO languages such as AspectJ andCaesarJ (Jackson et al., 2008).

4. Our MDD process

In this section we provide an overview of the MDD process thatwe have defined to automatically transform a software architec-ture, described using the AO-ADL language, into a skeleton of itsdetailed design, using either plain UML 2.0 or an AO extensionof UML, concretely Theme/UML (Clarke et al., 2005). Fig. 2 showsthe main models and transformations of our process. Although thestarting point is always an AO version of the software architec-ture (box (ADL)), an important contribution of this process is thatin the lower levels it allows choosing between following an AOdevelopment methodology (left side of Fig. 2) or an OO develop-ment methodology (right side of Fig. 2). Following this approach,our main goal is the definition of an automatic process that can beuseful for both AO and OO designers and implementers.

As mentioned previously, the input of our approach is anAO-ADL software architecture (box (ADL)). During the specifica-tion of the software architecture, existing AO-ADL architecturaltemplates can be selected and instantiated to easily incorporatepre-fabricated aspect-oriented solutions (box (ADL).1). The nextstep in our MDD process is the automatic generation of a skeletonof its detailed design. Two alternative outputs are possible (boxes

following an AO development methodology, so the separation of

3 http://gateway.comp.lancs.ac.uk:8080/c/portal/layout?p l id=1.85.

M. Pinto et al. / The Journal of Systems a

ci(tdaagtfw

m(leacto

5

atfabfa

aspectual bindings. Then, aspectual bindings are defined in termsof these parameters, which will be instantiated for each particulardomain, promoting the reuse of the relationships between aspec-

Fig. 2. MDD process in the software development lifecycle using AO-ADL.

oncerns identified and modelled at the architectural level is explic-tly maintained at the design level. The second transformation (boxOO).1) generates a skeleton of the detailed design of that archi-ecture in plain UML 2.0. In this case, we would be using an OOevelopment methodology, so the crosscutting concerns identifiedt the architectural level are not explicitly separated and modelleds “aspects” at the design level, as in traditional OO designs. So, weenerate a UML model where the crosscutting and non crosscut-ing concerns are weaved. The aspectual information is translatedrom the AO-ADL connectors into dynamic sequence diagrams, ase will show later.

The design models generated will conform to the Theme/UMLetamodel (box (AO).2), and to the UML 2.0 metamodel (box

OO.2)), respectively. These designs need to be refined with lowevel details (e.g. platform specific details) using any existing UMLditor. Once the detailed design is completed, the last step is theutomatic generation of code (boxes (AO.3) and (OO.3)), either AOode (box (AO.4)) or OO code (box (OO).4). These are third-partyransformations (Jackson et al., 2008) that can be integrated intour MDD process, so they are not included in this paper.

. A step by step example

In this section our MDD process is followed step by step usingn auction system running example. Basically, in an auction sys-em “sellers initiate auctions offering items to be sold, and buyers bidor them. The sellers set the initial and minimum bid and initiate the

uction. Buyers join auctions, bid for items and increase their previousids”. Additionally to these functional requirements, several extra-unctional requirements, which have a crosscutting behaviour arelso identified: (1) Encryption: the communication between users

nd Software 85 (2012) 525– 545 529

and the auction system must be encrypted, (2) Consistency: min-imum bids, bid prices and bid increments must be valid, and (3)Synchronization: more than one buyer can simultaneously bid forthe same item.

5.1. AO-ADL specification

The main building blocks in AO-ADL4 are components and con-nectors. Components model both non-crosscutting and crosscuttingconcerns, and are described by their provided/required ports. Thecomposition (e.g. weaving in AO) between components modellingcrosscutting and non-crosscutting concerns is specified as part ofconnectors. Thus, the semantics of connectors is extended withthe definition of aspectual bindings. Also, aspectual roles are a newkind of role in AO-ADL. Components connected to aspectual rolesbehave as aspectual components, while those connected to provided/required roles behave as base components.

Fig. 3(a) shows five different components connected through aconnector. On the one hand, there is an interaction between theUser GUI and the Auction base components, which model the userand the auction non-crosscutting concerns. On the other hand,the Encryption, Consistency and Synchronization (aspectual) com-ponents model crosscutting concerns. The auction system shownin Fig. 3(a) is specified by a set of XML files. Fig. 3(b) shows theXML code that partially describes the Encryption component andthe BuyerConnector connector. The code labeled as (4) describesthe Encryption Service interface with two operations: encrypt anddecrypt. This interface is used in the description of the Encryptioncomponent (label (1)) that provides the Encryption Service interfaceby means of its port Encryption. The code labeled as (5) specifies theaspectual part of the BuyerConnector connector. On the one hand,the Encryption Service interface is associated with an aspectual roleof the connector, named Encryption. This means that a componentconnected to this role will behave as an aspect affecting the inter-action between base components, according to the informationspecified in the aspectual binding part of the connector (code (6)).Concretely, the pointcut specification (code (6.1)) describes that theencrypt method (code (6.2)) of the aspectual component connectedto the Encryption role (code (6.3)) will affect any operation of theprovided role Buyer. Moreover, the encrypt method will be injectedbefore (code (6.4)) any call intercepted by the pointcut.

Without having the facility of AO-ADL architectural templates,software architects would have to: (1) specify from scratch theaspectual roles and aspectual bindings of AO-ADL connectors (code(5)), for each crosscutting concern, and (2) repeat the same aspec-tual information for systems in different domains where the samecrosscutting concerns are identified. Thus, the primary aim in thedefinition of an architectural template is to allow reusing thespecification of aspectual roles and aspectual bindings. This impliesreusing the relationships between several aspectual componentsattached to a particular pointcut, the relationships between aspec-tual components and base components, the order of applicationof the aspectual advice in a particular join point, the advice oper-ator (before, after, around, concurrent-with) used to attach theaspectual behaviour to the base component interaction, and therelationship between the arguments of the intercepted join pointsand the arguments of the advice methods, information which isrecurrent in several application domains. Thus, all the informa-tion within an AO-ADL connector can be parameterised, except the

4 The AO-ADL metamodel (Pinto et al., 2011) is not shown here due to lack ofspace.

530 M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545

itectu

tt

cecmpiooa

cgltada

m

Fig. 3. (a–c) AO-ADL arch

ual components and the rest of the components participating inhe interaction.

In our example, templates for encryption, consistency and syn-hronization will be ready to be instantiated and reused. As anxample, in Fig. 3(c) we describe a template for the encryptiononcern. The other templates are defined in a similar way. Althoughodelling encryption is not too complicated and, thus, the template

resented here is quite simple, our purpose at this point is only tollustrate the benefits of having these templates available. The usef AO-ADL to model more intricate templates, specifying more thanne crosscutting concern and the relationships and dependenciesmong them, can be found in Pinto and Fuentes (2008).

In the encryption template shown in Fig. 3(c), notice that theonnector roles are parameters of the template (|source and |tar-et) (label (7)).5 Additionally, these parameterised roles specify a

ist of parameterised operations that will also have to be instan-iated (label (7)). It should also be noticed that these parameters

llow the specification of reusable pointcuts (code (9.1)), whichetermine the join points to which the Encryption component isttached, as well as the advices to be injected. Thus, in our approach

5 The use of | is syntactic sugar used here to describe the template. The imple-entation details are described in Section 6.1.

re of the auction system.

the aspectual binding shown in Fig. 3(b) would be automaticallygenerated by instantiating the template for the auction case study.In addition to the names of the provided and required roles and theinterface operations as described in this example, also the name ofthe connector, the name and operations of the aspectual roles andthe component bindings may be parameterised.

After defining the corresponding aspectual architectural tem-plate, the next step is to instantiate it in order to generate theconcrete solution that we want to use in our system. This trans-formation takes as inputs the parameterised architectural templateand the values of these parameters and automatically generates thespecific instance of the architecture. The process will be describedwith more details in Section 6.1. Moreover, as shown in Section6.3, our tool support provides a wizard that guides the softwarearchitect through the instantiation process.

5.2. Transformation to Theme/UML

Theme/UML is a UML profile that extends the UML metamodel todefine some new elements specifically created to aspect-oriented

design. The most relevant elements are the themes. A theme is aUML packet that contains all the UML elements that are neededto model a particular concern. It also defines two new relation-ships that can be established between themes: the merge and the

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 531

Table 1Theme/UML mapping rules.

AO-ADL element Theme/UML element Rationale ATL rules

Interface and operations Interface and operations.Optionally, a theme can begenerated from each of them.

Basically a 1:1 translation process. Atheme is generated for each of themdepending on the selected mappingoption.

Interface Transformation Rule. It creates a UML2.0 interface for each AO-ADL interface.

Component (base or aspectualcomponents, there is nodistinction in AO-ADL)

- A set of themes for AO-ADL basecomponents.

In AO-ADL the same component canplay a base or aspectual role dependingon how it is attached to connectors.

Base Component Transformation Rule. It createsa theme, and inside the theme a UMLcomponent with a port for each provided orrequired interface of the AO-ADL component.

- A set of parameterised themes forAO-ADL aspectual components.

Theme/UML differentiates betweentwo kinds of themes, distinguishing therepresentation of aspectual themes.

Aspectual Component Transformation Rule. Itcreates the same UML component as in thebase case representing the AO-ADL aspectualcomponent, plus ‘generic’ UML componentsrepresenting the base components affected bythe crosscutting behaviour. Moreover, itcreates a UML interaction representing thecrosscutting behaviour. All the aspectualinformation is obtained from the AO-ADLaspectual role and aspectual bindings of theconnector to which the component is attached.

- Both themes and parameterisedthemes composed by means of amerge operator.

Connector One single theme, containing a setof UML components.

This rule transforms a connector in thecontext of a particular architecturalconfiguration, considering the AO-ADLcomponents attached to the roles ofAO-ADL connectors.

Connector Transformation Rule. It creates atheme, and inside it, a set of UML components:one, stereotyped as « aoadlConnector»representing the connector; the rest of themare created from the components attached tothe connector in a particular configuration.Moreover, this rule creates a UML interactionfor each component binding defined inside theconnector. The aspectual binding informationis mapped executing the previous AspectualComponents Transformation Rule.

Configuration (a completearchitectural description)

A Theme/UML model. All the elements transformed byprevious rules are part of theTheme/UML model, creating a UML

sentatectur

Configuration Transformation Rule. It invokesthe previous rules for each interface,component and connector defined in an

bbb

dTT2m

tmslcmfaamccmoab

me

reprearchi

ind relationships. The merge relationship models the relationshipsetween concerns and the bind relationship models the aspectualindings of crosscutting concerns.

In order to implement this transformation, the first step is theefinition of the mapping between the metamodels of AO-ADL andheme/UML. This mapping was defined in collaboration with therinity College of Dublin (creators of Theme/UML) (Chitchyan et al.,006). A summary of this mapping is shown in Table 1. Its imple-entation is detailed in Section 6.Three different possibilities are offered in our approach to

ransform AO-ADL elements into Theme/UML elements. They areotivated by the fact that in Theme/UML a theme represents a

ingle concern. However, in AO-ADL, components of low granu-arity can be associated with a single concern, but more complexomponents and, in particular, composite components are usuallyodelling more than one concern. In order to cope with this dif-

erence, our MDD process includes a manual step, previous to theutomatic transformation, in which an expert in the domain of therchitecture to be transformed must choose the kind of transfor-ation to be performed: (1) An AO-ADL component models a single

oncern and is mapped to only one theme; (2) Each interface in theomponent models a different concern and thus each interface isapped to a different theme, or (3) Each operation in the interfaces

f the component models a different concern and thus each oper-tion is mapped to different themes. Notice that these options can

e combined so the designer can tune the design model.

Coming back to our example, Fig. 4 partly shows the Theme/UMLodel automatically generated from Fig. 3. In this particular case,

ach architectural component is modelling a single concern and

tion of an AO-ADL softwaree.

AO-ADL software architecture. Moreover, itcomposes the themes of the components andconnectors by using the bind operator.

thus we have chosen to transform each AO-ADL component intoa theme. Thus, according to Table 1, a theme is generated for eachcomponent in the software architecture. Moreover,an additionaltransformation is performed for those components that play therole of aspectual components in AO-ADL, consisting of the gener-ation of a parameterised theme for each operation in the interfaceof the aspectual component. Those additional themes model theaspect advice. In our example, the Encryption component is anaspectual component connected to an aspectual role of the Buy-erConnector connector with two advices: encrypt and decrypt. Thus,two new themes are created modelling the advice. According tothe Theme/UML metamodel, these new themes are related to theEncryption theme by means of merge relationships. The union ofthese three themes represents the whole behaviour of the Encryp-tion component. Notice that Fig. 4(a) is a simplification of the realtransformation since more themes should appear modelling theadvice of the rest of aspectual components in the software archi-tecture.

While, in AO-ADL, the aspectual information – i.e. pointcutsand aspectual bindings, is encapsulated as part of the connectors,in Theme/UML, pointcuts and aspectual bindings are specified bymeans of bind relationships between themes. In our example, theencrypt and decrypt themes interfere with the behaviour of Buy-erConnector by means of two bind relationships, which specify thepointcuts where the aspectual theme affects to the behaviour of the

base theme. In our example these points are the increase(), bid() andjoin() operations of the Buyer provided role shown in Fig. 3(a), as wecan see in the binding attribute of the bind relationship (binding=“<Buyer.increase(), bid(), join() >”).

532 M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545

e of th

twSstimtbpttr

ma

5

ttbdmbitfitl

itagadil

Fig. 4. (a, b, c1 and c2) Architectur

In addition to Fig. 4(a), Fig. 4(b) shows the internal design ofhe encrypt theme, in which an Encryption component is relatedith a generic component Component through the Encryption-

ervice interface. Moreover, the sequence diagram in Fig. 4(c.1)hows the precise way in which the encrypt advice behaves in rela-ion to the intercepted method. Concretely, the encrypt() advices executed when a method comes to Port before being trans-

itted to the Component. The diagram shown in Fig. 4(b) is aemplate to be instantiated with the binding information of theind relationship shown in Fig. 4(a). In our example, the Com-onent would be instantiated to the BuyerConnector connector,he Port to the provided role Buyer and the method() is instan-iated to the increase(), bid() and join() operations of the Buyerole.

Notice that by means of these diagrams the Theme/UML modelaintains all the aspectual information included in the AO-ADL

rchitecture.

.3. Transformation to UML 2.0

UML is the de facto standard language at the design stage. Inhis transformation the main goal is to generate a UML 2.0 designhat contains all the relevant information expressed in AO-ADL,ut without the requirement of learning a specific aspect-orientedesign approach to be able to continue the software develop-ent process. In order to do that we have defined a mapping

etween the AO-ADL and the UML 2.0 metamodels. We have onlyntroduced a new stereotype named crosscuts which allows uso make explicit that the source of the relationship was identi-ed as an aspectual component at the architectural level, and thearget was identified as a base component at the architecturalevel.

Notice however, that the use of this stereotyped relationships optional and can be omitted without changing the semantics ofhe model. This is possible because the information contained inn AO-ADL architecture is transformed into two kinds of UML dia-rams: static and dynamic. As indicated in Table 2, components in

n AO-ADL configuration are always mapped to a single UML staticiagram, a component diagram, where every AO-ADL component

s transformed into a UML component. The information encapsu-ated in AO-ADL connectors is represented partly in component

e auction system in Theme/UML.

diagrams and partly in sequence diagrams. Thus, even if the cross-cuts relationships are not specified in the component diagrams, theaspectual interactions between components encapsulated in theAO-ADL connectors are always transformed into a set of sequencediagrams. Notice that sequence diagrams have to be seen as theresult of applying the weaving process between AO-ADL base andaspectual components, according to the aspectual binding informa-tion specified in AO-ADL connectors.

Continuing with our example, the output model generated bythe transformation from AO-ADL to UML 2.0 is shown in Fig. 5. Fig.5(a) shows a component diagram (the static diagram) where wecan observe that the components originally joined by the Buyer-Connector at the architectural level are now directly connected bymeans of the BuyerService interface. Meanwhile, the componentsthat had an aspectual behaviour at the architecture level (Encryp-tion, Consistency and Synchronization) interfere with this relationby means of the crosscuts relationship. All the aspectual informa-tion that was contained in the BuyerConnector is transformed intodynamic diagrams like the sequence diagram we can see in Fig.5(b). This figure shows how the User GUI component invokes thejoin() method through its Buyer port and that before transmittingthe message to the corresponding port of the Auction componentthe encrypt() method is invoked, just as specified in the BuyerCon-nector.

5.4. Comparison

The output of the transformation to Theme/UML is an aspect-oriented design. This means that both the separation betweencrosscutting and non-crosscutting concerns and all the aspectualinformation identified at the architectural level is preserved in thedesign model. The design in Theme/UML enhances the aspectualvision of the architecture, since what you see in the design is agroup of themes (e.g. concerns) and the interactions among them.The aspectual information is also well contained in: (a) the themesthat represent aspectual behaviour, and (b) the bind relationships.Finally, the AO-ADL connectors are explicitly represented in the

design by using themes. On the other hand, the result of the trans-formation to UML 2.0 weaves the aspectual information into themodel, making easier to implement the model using a conventionalobject-oriented programming language. The configuration of the

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 533

Table 2UML 2.0 mapping rules.

AO-ADL element UML 2.0 element Rationale ATL rules

Interface and operations Interface and operations. Basically a 1:1 translation process(note that AO-ADL interfaces andoperations model the same concepts asin UML).

Interface Transformation Rule. It creates a UML2.0 interface for each AO-ADL interface.

Component A UML 2.0 component. Basically a 1:1 translation process(note that AO-ADL components are notdifferent from UML components.Moreover, AO-ADL components arealso used to model aspects).

Component Transformation Rule. It creates aUML 2.0 component for each AO-ADLcomponent.

Connector - Base components related with theconnector, connect themselvesdirectly through the interfaces.

This is not a 1:1 translation process andit is the most interesting part of theAO-ADL to UML 2.0 transformation. Allthe aspectual information contained inthe connector is translated to a set ofsequence diagrams where theaspectual interactions between thecomponents connected to theconnector are represented.

Connector to Crosscut RelationshipsTransformation Rule. It creates the crosscutsrelationships between aspectual and basecomponents.

- Aspectual components related withthe connector, connect through thenew crosscuts relationship.

Connector to Sequence Diagram TransformationRule. It creates the sequence diagrams tomodel the aspectual relationships betweenaspectual and base components.

- A sequence diagram is generatedfor each aspectual binding and eachjoin point captured by the pointcutspecifications specified inside theconnector.

Configuration (a completearchitectural description)

A UML 2.0 model. All the elements transformed byprevious rules are included in the newUML 2.0 model.

Configuration Transformation Rule. It invokesprevious rules to transform a particularconfiguration.

of the

aitdq2

6

t

site.7 In this section we will present the implementation details ofour approach.

Fig. 5. (a and b) Architecture

rchitecture (the components and their relationships) is clearly vis-ble in the static part of the design, but the aspectual information isranslated from the AO-ADL connectors into the dynamic sequenceiagrams, so the separation disappears from the design model. Auantitative comparison between AO-ADL, Theme/UML and UML.0 will be discussed in Section 7.

. Technical details

We have completely implemented our approach: (1) the instan-iation of AO-ADL architectural templates using JET, (2) the

auction system in UML 2.0.

model-to-model transformations using ATL, and (3) the AO-ADLTool Suite as an Eclipse plug-in. The AO-ADL Tool Suite and the ATLtransformations are available to be downloaded from the AO-ADLEclipse update site.6 Examples of AO-ADL architectural templatesand of the main ATL rules can also be consulted in the AO-ADL web

6 http://caosd.lcc.uma.es/AO-ADLUpdates.7 http://caosd.lcc.uma.es/aoadl.

534 M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545

plate

6

tihpaptvtcs

M2ppSiTeFiltt

Fig. 6. Architectural tem

.1. Instantiation of AO-ADL templates

MDD helped us to incorporate the concept of architecturalemplate into the AO-ADL language, whose XML schema was notnitially prepared to define them. Without using MDD, we wouldave needed: (1) to define a new mechanism to represent the tem-late parameters as part of the AO-ADL XML schema; (2) to define

new XML schema for describing the mapping between templatearameters and concrete values; (3) to write the code to implementhe mapping process between template parameters and concretealues, and (4) to implement the instantiation process that localiseshe parameters of a particular template one by one, to invoke theorresponding mapping code, and to generate an instantiated ver-ion of the template.

In our approach, the above tasks have been simplified usingDD, specifically using JET (Java Emitter Templates) (Project,

010). Among the several approaches available to implement tem-lates (Czarnecki et al., 2006), we decided to use JET because it isart of an Eclipse Project, and we are developing the AO-ADL Tooluite (see Section 6.3) as an Eclipse plug-in. Concretely, JET allowsntroducing java code in the definition of a template parameter.his java code is then executed in order to instantiate that param-ter. This simplifies the first and fourth tasks previously described.irstly, an AO-ADL configuration that includes JET code is automat-

cally considered by our tool as an architecture template (see Fig. 6,abel 1), and no additional mechanism is needed in order to definehe templates. Secondly, instead of implementing our own instan-iation process, we use the JET engine (see Fig. 6, label 2), which

instantiation process.

takes the architectural template with the JET code as input and: (1)automatically locates the JET code embedded in the definition ofthe architectural template, and (2) automatically makes the trans-formation of the parameters to their concrete values. With respectto the second and third tasks, they still need to be performed, evenwhen JET is used. Thus, we have defined an XML Schema to spec-ify the mapping between parameters and concrete values (an XMLdocument conforming to this schema is shown in Fig. 6, label 2.1).And we have implemented in Java the code that it has to be injectedinto the XML document in order to later instantiate each templateparameter (see Fig. 6, label 2.2).

Following with our example, the top section of Fig. 6 (label 1)shows part of the AO-ADL description of the encryption architec-tural template, graphically represented in Fig. 3(c). The text in boldis the JET code implementing the parameters of the template. Con-cretely, the name of the connector, and the name and interface ofthe provided role of the connector have been parameterised withthe ‘EncryptionConnectorTemplate’ and the ‘source’ parame-ters. All the operations defined in the ‘BuyerInterface’ are alsoconsidered as parameters of the template. The aspectual bindingshave been defined in terms of the parameters specified in otherparts of the connector (e.g. the ‘source’ and ‘secureOp’ parameters),and thus the relationships described by the aspectual bindings canbe reused in all the future instances of the connector.

Once the generic aspect-oriented architectural template hasbeen defined, the next step is to instantiate it for deriving partic-ular solutions (see label 2 in Fig. 6). As previously described, theinstantiation process is automatically performed by the JET engine.

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 535

L and

Apotptiti3tpiNoc

6

e2

TiA2AT

mAprraw

connector (connector, roles, component and aspectual bindings inthe left side of the figure), and in the Theme/UML representation of

Fig. 7. Excerpt of the AO-AD

s shown in Fig. 6, the JET engine receives the architectural tem-late, the XML document defining the values for each parameterf the connector (label 2.1) and the Java code (label 2.2). Whilehe XML document (label 2.1) is generated for each instantiationrocess using the information introduced by the software archi-ecture through our tool wizard (see Section 6.3), the java codes generic and can be reused to instantiate any AO-ADL architec-ural template (label 2.2). The output generated by the JET engines a particular instance of the architectural template. In Fig. 6 (label) we show the instantiated connector with name BuyerConnec-or, specifically generated for our example, where the ‘secureOp’arameter in the template has been instantiated with the bid andncrease operations of the BuyerInterface (see also Fig. 3(a)).otice that the aspectual bindings have been completely reused,nly the parameter names have been replaced by the values asso-iated to the components and interfaces in our example.

.2. AO-ADL 2 UML 2.0 transformations

This section describes the technical details of how AO-ADL mod-ls can be automatically transformed into Theme/UML or plain UML.0 models, using model-to-model transformations.

To carry out the transformation from an AO-ADL model into aheme/UML model or into a UML 2.0 model, the first thing to dos to define a mapping between the elements of the metamodel ofO-ADL and the elements of the metamodel of Theme/UML or UML.0. That mapping can be described as a set of rules, one for eachO-ADL element. Tables 1 and 2 depicted those mapping rules forheme/UML y UML 2.0, respectively.

Once the mappings have been defined, they have to be imple-ented using a model transformation language. We have usedTL, which has the advantage of being implemented as an Eclipselug-in. This allows us executing the ATL code inside of an Eclipse

untime environment, so it is the best choice to integrate the ATLules into the AO-ADL Tool Suite. Besides, the ATL plug-in provides

programming environment with numerous facilities: text editorith highlight syntax, compiler, debugger, etc.

Theme/UML metamodels.

Thus, the transformation from an AO-ADL model to anTheme/UML or an UML model is carried out by the application of aset of ATL rules (see last column in Tables 1 and 2) that describe howelements of the source model (one or several elements of AO-ADL)are transformed into elements of the target model (one or severalelements of Theme/UML).

6.2.1. Source and target metamodelsTo use a model transformation language we need the meta-

models of the source (AO-ADL) and target (Theme/UML, UML 2.0)models. In particular, when using ATL and EMF (Eclipse ModellingFramework), those metamodels have to be expressed in Ecore (themeta-metamodel).

Since AO-ADL is an XML language, the first step to define themetamodel of AO-ADL has been to automatically generate the Ecoremetamodel of AO-ADL using the facility ‘XML Schemas to Ecore’provided by the EMF Eclipse plug-in. For the target models, theTheme/UML metamodel is an extension of the Ecore metamodelof UML 2.0 (provided by the authors of Theme/UML), and the UML2.0 metamodel is the Ecore UML 2.0 metamodel provided with theUML2 Eclipse plug-in.

As said previously, Theme/UML (Clarke et al., 2005) is a spe-cific aspect-oriented extension of UML 2.0. A Theme/UML modelcan be represented in UML 2.0 using the Theme/UML Profile. Themain elements that we are going to use from Theme/UML areThemes, Merges and Binds. A Theme is represented by a UML pack-age stereotyped as «theme». Merges and Binds are representedby UML dependencies stereotyped as «merge» and «bind», respec-tively. Merges and Binds occur between Themes.

Fig. 7 shows part of both metamodels.8 Concretely, those partsof the metamodel that participate in the definition of the AO-ADL

AO-ADL connectors (UML packages representing the themes, UML

8 We consider that showing the metamodel of UML 2.0 is not necessary.

5 tems a

psiT

6

dmtmeT

tcfd

ttfabCbmtt

iwtCpaa

wdsttItt

dt

36 M. Pinto et al. / The Journal of Sys

orts, UML interactions in the right side of the figure).9 In the nextection we show part of the ATL rules than transform the elementsn the metamodel of AO-ADL to elements in the metamodels ofheme/UML or UML 2.0.

.2.2. ATL transformation rulesIn this section we show some of the ATL rules that have been

efined to implement the mapping from AO-ADL models to UMLodels, and the rationale behind the execution of those rules. Par-

icularly, the rules that we discuss here transform the AO-ADLodel of our running example to Theme/UML. The rules to gen-

rate plain UML 2.0 are not included due to the lack of space (seeable 2).

The transformation begins with the ATL rule Architec-ure to ThemeUMLDesign shown in Fig. 8 that converts an AO-ADLonfiguration into a Theme/UML model (rule Configuration Trans-ormation Rule in Table 1). It is a declarative rule structured in fourifferent parts:

from: it defines the element(s) of the source metamodel to betransformed.using: it declares and initialises auxiliary variables.to: it defines the element(s) of the target metamodel to be gener-ated.do: it defines additional actions to be executed after the elementsof the target metamodel have been generated.

Firstly, as defined in the using: clause, the information about allhe components, connectors and base and aspectual attachmentshat are part of an AO-ADL configuration (element to be trans-ormed as indicated in the from: clause) is obtained. Secondly,s defined in the to: clause, the Theme/UML model is generatedy applying a set of auxiliary rules (ComponentTypeToPackage,onnectorTypeToPackage, mergeComponentAndConnector andindAspectualComponentAndConnector) to the AO-ADL infor-ation previously selected with using:. Finally, the elements in

he target model are stereotyped with Theme/UML specific stereo-ypes as defined in the do: clause.

As we can see, the implementation of these rules is not a triv-al task and without the use of auxiliary rules the above code

ould be illegible. In fact, the auxiliary rules previously men-ioned already invoke other auxiliary rules (ComponentToPackage,omponentToThemes, ComponentToTemplatePackage, . . .) com-licating even more the resulting code. In ATL, these auxiliary rulesre called helper functions. Helper functions complement ATL rulesnd have the following structure:

helper context <contextElement> def:<functionName>(<parametersList>): <returnedEle-

ment>= <functionBody>;

here: contextElement is the context in which the function isefined; functionName is the name of the function; parameter-List is a list of parameters with their types; returnedElement ishe type of the element to be returned by the function, and func-ionBody is a single instruction with the behaviour of the function.

n order to improve the capability and versatility of helper functionshe let instruction can be used. This instruction allows the defini-ion and initialisation of a variable with the result obtained from

9 The inclusion of the complete specification of these metamodels is not possibleue to space limitations. The complete metamodel of AO-ADL can be consulted onhe AO-ADL web page.

nd Software 85 (2012) 525– 545

executing an ATL single instruction. This variable can then be usedin other parts of the helper function.

An example of a helper function (including an importantnumber of let instructions) is shown in Fig. 8. In Section 5 weexplained that the transformation of AO-ADL elements into themesis semi-automatic, because the software architect can choose thegranularity of themes (an operation is a theme, an interface is atheme or a component is a theme). Concretely, the helper functionComponentToTheme receives as parameters the name of a compo-nent (parameter componentName:String), one instance of thatcomponent (parameter instance: schema!ComponentType)and a sequence of concerns encapsulated on that component(parameter concerns: Sequence(parameter!ConcernType))and returns the sequence of UML packages (i.e. themes) mod-elling those concerns at the detailed design level (returned typeSequence(UML2!PackageableElement)).

These ATL rules have been integrated into the AO-ADL Tool Suite,which automatically invokes the ATL engine in charge of executingthe rules. The software architect has only to select the AO-ADL con-figuration to be transformed and push a button of our tool in orderto generate the Theme/UML or the UML 2.0 models.

6.3. AO-ADL Tool Suite

Our MDD process is supported by the AO-ADL Tool Suite.10 Thistoolkit has been implemented as an Eclipse plug-in that provides:(1) graphical support to describe and manipulate AO-ADL softwarearchitectures including the definition and instantiation of archi-tectural templates, covering the first step of our MDD process, and(2) integration of the architecture-to-design MDD transformationspreviously described, covering the second step of our MDD process.Finally, the designs generated with ATL do not contain graphicalinformation, basically because this information is specific to eachparticular UML editor. Thus, our tool prepares the output of ATLtransformations in order to automatically generate graphical infor-mation required to visualise the design in MagicDraw UML. Thismakes it easier to continue the design of the system using an exist-ing UML editor.

A snapshot of the AO-ADL Tool Suite, identifying the differentmodules that are part of it, is shown in Fig. 9. The most relevantcharacteristics of this tool are the following11:

1. It provides an architecture design module that allows thespecification of AO-ADL software architectures avoiding directmanipulation of XML files. Thys module is composed of a set ofeditors, one for each AO-ADL element (Architecture Design Toolin the right side of Fig. 9).

2. It provides a repository of components, connectors and configu-rations, including both architectural templates and instantiatedarchitectures. This module is integrated with the previous one,so the software architect can reuse existing architectural blocksby importing them directly from the repository (C&C Repositoryin the left side of Fig. 9).

3. Architectural templates can be defined exactly as any othersoftware architecture (e.g. configuration). Thus the softwarearchitect does not need to manage the JET code. Instead, dur-ing the definition of the template, he/she only needs to select

a ‘parameter’ check box to indicate that an element has to beparameterised. The JET code is automatically generated by ourtool.

10 Downloadable from our website (http://caosd.lcc.uma.es/aoadl/download.htm).11 Some of these characteristics have been already mentioned throughout the

paper, and are summarised in this section.

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 537

Fig. 8. ATL rules.

538 M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545

-ADL T

4

5

6

7

tbIqwdssrab

In this section we have measured the number of elements used

Fig. 9. AO

. A wizard guides the software architect through the process ofinstantiating an architectural template (Instantiation Wizard inFig. 9). Using the wizard the software architect indicates the con-crete values for each of the parameters of the template. Thosevalues can be selected from the repository accessing to previ-ously defined interfaces and components. The generation of theXML file with the mapping between parameters and concretevalues, the Java code invoked to make the instantiation, and theinvocation of the JET engine is hidden by our tool, simplifyingthe template instantiation process.

. The ATL rules have been integrated into the tool that automat-ically invokes the ATL engine in charge of executing the rules.The software architect only has to select the AO-ADL configura-tion to be transformed and push a button on our tool in order togenerate the Theme/UML or the UML 2.0 version of the softwarearchitecture (‘AO-ADL 2 UML Tool’ button in Fig. 9). This gen-erates a UML 2.0 model that can be directly loaded into a UMLdesign tool, for instance, Magic Draw.

. Finally, our tool is extensible with new transformations fromAO-ADL to other UML profiles, either aspect-oriented or non-aspect-oriented design models.

. Evaluation of our approach

In this paper we have shown how the use of MDD can be usedo enhance the specification of AO software architectures and toridge the gap between AO architecture and (AO) detailed design.

n this section we evaluate our approach both quantitatively andualitatively. We would like to highlight that the main goal of thisork is to connect AO-ADL with the lower phases of the softwareevelopment, and not to compare the complexity of architecturalpecification written in AO-ADL with their corresponding repre-

entation in Theme/UML or in UML 2.0. However, the quantitativeesults shown in this section demonstrate that in architectures with

high number of crosscutting concerns, their representation inoth Theme/UML and UML 2.0 is much more complicated than in

ool Suite.

AO-ADL. So, regarding the representation of aspectual information,the numbers shown in this section indicate that it would be recom-mendable to specify the software architecture in AO-ADL and thenautomatically generate the skeleton of the detailed design usingour approach.

Firstly, we show the quantitative results of applying ourapproach to three different case studies: an extended version ofthe auction system used throughout the paper and two more intri-cate scenarios: a health watcher case study and a toll case study.The new case studies are real systems developed in collaborationwith third-parties. The health watcher (Soares et al., 2002) is a websystem where citizens can complain about the health system andit is an industrial case study part of an AOSD testbed (Greenwoodet al., 2007) in which the authors are participating. The toll systemis a system for tolling the usage of roads and motorways and it isan industrial case study developed in collaboration with Siemensin the context of the AOSD-Europe network of excellence.12

Secondly, we present four different evolution scenarios todemonstrate that, in terms of the number of required changes, itis better to perform the changes in the AO-ADL language and thento propagate them to UML 2.0 and Theme/UML by applying ourMDD transformations, instead of performing the changes directlyin Theme/UML or UML 2.0.

Thirdly, we discuss the correction, reusability and scalabilityof our MDD transformations. We finish this section with our finalremarks about interesting issues with the implementation of ourapproach.

7.1. Practical experience and quantitative evaluation of ourapproach

in AO-ADL to specify the software architecture of the extended

12 http://www.aosd-europe.net.

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 539

Table 3Auction system: AO-ADL to Theme/UML and to UML 2.0.

AO-ADL Theme/UML UML 2.0

(granularity:component)

(granularity:interface)

(granularity:operation)

Components 8 Themes 15 18 22Components 22 25 29 Components 8Merge Rel. 7 10 14

Interfaces 9 Interfaces 28 36 54 Interfaces 9

Base bindings 2 Merge Rel. 5 5 5 Component attachments 2

Connectors 2 Themes 2 2 2 Crosscuts Rel. 9Components 7 7 7

+7

vtTUhoiaT

saroctoitotidt

7

s

TH

Aspectual bindings 9 Bind Rel. 9

EFFORT 30 +68.4%

ersion of the auction system, the health-watcher system and theoll system (we have used the metric suite provided by the AO-ADLool Suite). We have also measured the number of Theme/UML andML 2.0 elements automatically generated by our approach (weave extended the ATL rules to automatically calculate the numberf generated elements). The results of our experiments show that its easier and simpler (in terms of architectural elements) to specifyspect-oriented software architectures in AO-ADL than directly inheme/UML or UML.

The quantitative results for the auction system case study arehown in Table 3, for the health-watcher system shown in Table 4nd for the toll system shown in Table 5. In these tables the firstsows (i.e. components, interfaces and base bindings) refer to the listf components and bindings among them, and the last two rows (i.e.onnectors and aspectual bindings) show the elements involved inhe aspectual bindings. These tables demonstrate that the numberf elements in AO-ADL is always lower than the number of elementsn Theme/UML and UML 2.0. This means that the effort of specifyinghe software architecture in AO-ADL will be lower than the effortf specifying it directly in Theme/UML or in UML 2.0. Looking athe last row of Tables 3–5 we can observe that the additional efforts especially high in the case of Theme/UML. We first discuss theifferences between AO-ADL and Theme/UML and the reasons forhese differences. Then, we will do the same for UML 2.0.

.1.1. Comparison between AO-ADL and Theme/UMLAs we can see in Tables 3–5, the Theme/UML generation process

ometimes implies the generation of too many themes (see second

able 4ealth-Watcher system: AO-ADL to Theme/UML and to UML 2.0.

AO-ADL Theme/UML

(granularity:component)

(gin

Components 29 Themes 35 8Components 41 9Merge Rel. 6 5

Interfaces 77 Interfaces 120 40

Base bindings 23 Merge Rel. 44 4

Connectors a 5+8 Themes 13 1Components 38 3

Aspectual bindings 7 Bind Rel. 7

EFFORT 149 +51% +7

a 5 connectors with aspectual roles that are transformed to 13 crosscuts relationships i

9 9 Weaving representation(sequence diagrams)

25

3.2% +78.9% +43.4%

row of the tables). This problem is specific to the Theme/UML defini-tion, but affects the quality of the AO detailed design we generate.We have mitigated this problem by requiring user intervention,who will decide between: (1) generating a theme for each AO-ADLcomponent (the results are shown in the granularity: componentcolumn of the tables); (2) generating a theme for each interface inan AO-ADL component (the results are shown in the granularity:interface column of the tables); (3) generating one theme for eachAO-ADL component operation (the results are shown in the granu-larity: operation column of the tables), and (4) deciding componentby component, between the first three options. Although with thefirst and second options we may reduce the separation of concerns,we consider that the separation is preserved for aspectual com-ponents, which are modelled separately from base components.Moreover, option three suffers from scalability problems and it isnot suitable for large software architectures (with many operationsspecified as part of the interfaces of architectural components),where the large number of themes, components and interfacesgenerated make the design unmanageable. As an example, for thehealth-watcher system the number of interfaces is 100 when thegranularity is component and 700 when the granularity is operation.Also, our experience in applying these transformations indicatesthat it is not always possible to define the granularity of concerns atthe operation level – i.e. having only option three, initially defined

in the mapping from AO-ADL to Theme/UML. Thus, having the fouroptions discussed here and requiring the manual intervention ofan expert in the application domain being transformed is the mostappropriate solution.

UML 2.0

ranularity:terface)

(granularity:operation)

4 1460 152 Components 295 117

0 700 Interfaces 77

4 44 Component attachments 23

3 13 Crosscuts Rel. 138 38

7 7 Weaving representation(sequence diagrams)

33

9.6% +87.7% +14.9%

n UML 2.0. 8 connectors without aspectual roles.

540 M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545

Table 5Toll system: AO-ADL to Theme/UML and to UML 2.0.

AO-ADL Theme/UML UML 2.0

(granularity:component)

(granularity:interface)

(granularity:operation)

Components 34 Themes 46 92 137Components 58 103 148 Components 34Merge Rel. 12 58 93

Interfaces 48 Interfaces 141 264 351 Interfaces 48

Base bindings 20 Merge Rel. 52 52 52 Component attachments 20

Connectors 19 Themes 21 21 21 Crosscuts Rel. 28Components 72 72 72

Aspectual bindings 16 Bind Rel. 16 16 16 Weaving representation 30

+7

bacg

pc(coA

meawtcbtaTocid

Aii

Aabmctniibstusa(

EFFORT 137 +67.2%

Additionally, in Theme/UML the themes contain a variable num-er of components depending whether the theme is a base orn aspectual (or parameterisable) theme, and whether the con-ern is chosen at the component, the interface or the operationranularity.

Specifically, the MDD transformation of AO-ADL base com-onents will generate: Only one theme (with one internalomponent), if the component granularity is selected. One themewith one internal component) for each interface in the AO-ADLomponent, if the interface granularity is selected. One theme (withne internal component) for each operation of each interface of theO-ADL component, if the operation granularity is selected.

AO-ADL aspectual components will generate the same infor-ation as base components and, additionally, one extra theme for

ach advice of the AO-ADL aspectual component participating in anspectual binding. Those themes will be parameterised themes andill contain two different components: one component modelling

he aspectual behaviour and one component modelling the genericomponent (a parameter of the theme) affected by the aspectualehaviour. For instance, the results about the extended version ofhe auction system in Table 3 show that the 8 AO-ADL componentsre transformed to 15 themes when the granularity is component.wo of the 8 AO-ADL components are base components and eachne is transformed to only 1 theme. The rest of them are aspectualomponents and are transformed to two or more themes, depend-ng on the number of advices. This justify the generation of 15ifferent themes in Theme/UML from 8 components in AO-ADL.

The above justifies the big difference between the number ofO-ADL components and the number of themes and components

n Theme/UML. It also justifies the difference in the number ofnterfaces in both approaches.

Regarding the number of base bindings, the mapping from AO-DL to Theme/UML establishes that for each composition between

provided and a required role in a AO-ADL connector there wille two merge relationships in Theme/UML (relating the themeodelling the connector and the theme modelling the components

onnected to the provided and required roles). This means thathe number of merge relationships will be always greater than theumber of AO-ADL base bindings (at least double if the binding

s established between only two AO-ADL components and greaterf more than two components participate in an AO-ADL aspectualinding). Note that Theme/UML also uses the merge relationship topecify that two or more themes are related among them (–i.e. inhe transformation from AO-ADL to Theme/UML this relationship is

sed to indicate that two or more themes were generated from theame AO-ADL component). In Tables 3–5 these merge relationshipsre quantified as part of the transformation of AO-ADL componentssee second row in the tables).

(sequence diagrams)9.8% +84.6% +14.4%

Finally, the number of aspectual bindings in AO-ADL and thenumber of bind relationships in Theme/UML are exactly the samebecause they are both modelling the weaving between aspectualand non-aspectual entities. In conclusion, Theme/UML, an aspect-oriented design approach, shows worse results for architecturalelements modelling components and the composition betweenthem, but not very bad results for aspectual elements, in compari-son with AO-ADL.

7.1.2. Comparison between AO-ADL and UML 2.0Looking at the first two columns (AO-ADL elements) and the last

two columns (UML 2.0 elements) of Tables 3–5 we observe that thenumber of components and interfaces remain exactly the same inAO-ADL and UML 2.0. The reason is that the separation of concernsmade at the architectural level by AO-ADL is somehow preservedin the static part of the plain UML generated designs. The AO-ADL“base components” and “aspectual components” are transformedinto separated UML 2.0 components, with the same interfaces andbase bindings (connections between base components) that theyhad in AO-ADL. So, there is no crosscutting in the UML componentdiagrams, since the bindings between UML components modellingAO-ADL aspectual components are specified only in the sequencediagrams. So, the sequence diagrams contain the weaving betweenbase and aspectual classes, but no explicit relationships betweenboth kinds of classes is generated. This means that at the detaileddesign phase the developer will refine base and aspectual classeswith no regard for the dependencies between them, that is, howboth kinds of classes are composed. This is thanks to the fact thatthis composition was already defined at the architectural level, andit was automatically generated by our process.

Taking a look again at Tables 3–5 we can see that the main dif-ferences of UML 2.0 designs in comparison with AO-ADL are in thenumber of crosscuts relationships in comparison with the numberof connectors in AO-ADL (fifth row in Tables 3–5), and especiallyin the number of sequence diagrams in UML in comparison withthe number of aspectual bindings in AO-ADL (sixth row in Tables3–5) – e.g. 25 sequence diagrams are used in UML 2.0 to modelthe 9 aspectual bindings specified in AO-ADL for the auction sys-tem in Table 3). The difference between the number of connectorsand the number of crosscuts relationships is explained by the factthat for each base component affected by an aspectual component,more than one aspectual component can be attached to the sameconnector but only one crosscuts relationship can be generated in

the UML component diagram. Note that in Table 4 only 5 of the 13connectors contains aspectual roles modelling an aspectual inter-action between components. These 5 connectors are transformedto 13 crosscuts relationships in UML 2.0. This means that this differ-

tems and Software 85 (2012) 525– 545 541

ei

itainemBolsa

7

saotto

teniastco

tctAitaetfsa

oscetatdm

the

evol

uti

on

scen

ario

s

in

the

auct

ion

syst

em.

#

crea

tion

s

#

del

etio

ns

#

mod

ifica

tion

s

AO

-AD

L

UM

L

2.0

Them

e/U

ML

AO

-AD

L

UM

L

2.0

Them

e/U

ML

AO

-AD

L

UM

L

2.0

Them

e/U

ML

03

(seq

uen

ce

dia

gram

)0

03

(seq

uen

ce

dia

gram

)

0

1

(bin

din

g

oper

ator

)

0

1

(bin

d

rela

tion

ship

)0

1

(cro

sscu

ts)

0

0

1

(cro

sscu

ts)

0

1

(poi

ntc

ut

spec

ifica

tion

)

3

(seq

uen

ce

dia

gram

s)

1

(bin

d

rela

tion

ship

)1

(asp

ectu

al

bin

din

g)

4

(1

cros

scu

ts

+

3se

quen

ce

dia

gram

s)0

0 4

(1

cros

scu

ts

+

3se

quen

ce

dia

gram

s)0

1

(asp

ectu

al

bin

din

g)

0

1

(bin

d

rela

tion

ship

)

3

(1

com

pon

ent +

1as

pec

tual

role

+

1at

tach

men

t)

5

(1

com

pon

ent +

1cr

ossc

uts

+

3

sequ

ence

dia

gram

s)

≥5

(≥1

them

e

+

2co

mp

onen

ts

+

1se

quen

ce

dia

gram

s +

1bi

nd

rela

tion

ship

s)

0

3

sequ

ence

dia

gram

s

0

1

(asp

ectu

al

bin

din

g)

0

0

4

13

≥5

0

11

0

4

3

3

M. Pinto et al. / The Journal of Sys

nce will be incremented as the number of aspectual componentsncreases.

Regarding the difference between the number of aspectual bind-ngs in AO-ADL and the number of sequence diagrams in UML 2.0,his is motivated by the fact that the UML design will contain all thespectual information of the architecture, but explicitly expressednstead of using a more compacted high level aspectual-orientedotation. For instance, in AO-ADL a single pointcut can make refer-nce to multiple join points, for example in Fig. 3, the pointcut (6.1)akes reference to all the operations of the provided role Buyer.

ut the UML transformation generates a sequence diagram for eachperation selected by the pointcut. This is bad regarding the highevel number of sequence diagrams generated, but is good in theense that it is possible to reason about the interaction betweenspectual and non aspectual behavioral classes one by one.

.2. Evolution scenarios

One of the benefits of aspect-orientation is that the evolution ofoftware systems is enhanced thanks to the separation of concerns,nd the separate specification of the composition information. Inur approach, any change performed in the high-level structure ofhe system – i.e. that is, its software architecture, must be done inhe AO-ADL model and will then be propagated to the Theme/UMLr the UML 2.0 designs using our MDD transformations.

In this section we demonstrate that AO-ADL software architec-ures are more evolvable than UML 2.0 designs and almost equallyvolvable than Theme/UML. In order to do that we quantify theumber of modifications that need to be performed in AO-ADL and

n both Theme/UML and UML 2.0 when the software architecture of system evolves. In order to do that we present different evolutioncenarios using the simplified version of the auction system usedhroughout the paper. Note that we focus on changes that are spe-ific to aspect-oriented systems in order to highlight the advantagesf using AO-ADL.

The different evolution scenarios, typical of aspect-oriented sys-ems, considered in this section are summarized in Table 6. Wean observe that the lowest number of changes – i.e. the sum ofhe # creations, the # deletions and the # modifications, occurs inO-ADL (8 changes), followed by Theme/UML (≥8 changes depend-

ng on the number of aspectual behaviours (or advice) added tohe software architecture; almost the same effort than in AO-ADLlthough it could be a bit worse if the number of advice is consid-rably high) and finally by UML 2.0 (27 changes; 70.3% more efforthan in AO-ADL). Buy, it is also true that the changes are of dif-erent granularity. For instance, the cost of creating or modifying aequence diagrams will be greater that the cost of creating/deleting

relationship between two components or between two themes.Note that, since both AO-ADL and Theme/UML are aspect-

riented approaches, the results obtained from the evolutioncenarios is the expected one, in the sense that in both cases cross-utting concerns are well-modularized and then their evolution isasier than in non-aspect-oriented approaches. However, in Sec-ion 7.1 we demonstrated that the effort of specifying the softwarerchitecture directly in Theme/UML is considerable higher thanhe effort of specifying it in AO-ADL. Thus, the quantitative resultsemonstrate the adequacy of using AO-ADL and the MDD transfor-ations to Theme/UML described in this paper.

ES1. The type of advice (before, after, . . .) changes. In this evolu-tion scenario one or more aspects which were applied, for instance,“before” a join point will be now applied, for instance, “after” that

join point.ES2. The join point affected by one or more aspect changes. Inthis evolution scenario one or more aspects, which were appliedin a join point 1 will be now applied in a different join point 2. Ta

ble

6Ev

alu

atio

n

of

Evol

uti

onsc

enar

ios

SC1

SC2

SC3

SC4

TOTA

L

5 tems a

7

arco“a“

wASsaNtoonsts

tsTta

7

wtttdCp

osvn/p

cbbpbpr

we have tested our MDD transformations and the reusability andscalability of the ATL rules defined to implement our transforma-

42 M. Pinto et al. / The Journal of Sys

Our assumption is that the change applies simultaneously to allthe aspects in the changed join point.ES3. The join point affected by one or more aspect changes (butonly for one of the aspects). This evolution scenario is similar tothe previous one but now only one of the aspects being applied in aparticular join points is affected by the change. The rest of aspectsremains the same.ES4. A new aspect (aspectual component) is added to a connec-tor. In this evolution scenario a new aspect is added to an existingconnector. Our assumption is that there are already other aspectsbeing applied in the pointcut affected by the new aspect.

.2.1. First evolution scenarioComing back to our running example in Fig. 3(a), let us suppose

Log aspect that is applied “before” the “increase” operation iseceived by the Auction component. The evolution scenario wouldonsist of making the aspect to be applied “after” the “increase”peration is received by the Auction component, instead ofbefore”. In AO-ADL it would only be required to change the oper-tor attribute of the binding element from a “before” value to anafter” value (see 6.4 in Fig. 3(b)).

In UML 2.0, however we need to change the sequence diagramshere the Log component participates (remember that the AO-DL aspectual bindings are transformed to sequence diagrams).ince we may need complex modifications to adapt the existingequence diagrams, we have represented this evolution in Table 6s we delete the old sequence diagram(s) and create the new one(s).ote that depending on the complexity of the pointcut specifica-

ion in AO-ADL (i.e. of the use of quantifications in the specificationf pointcuts) the number of sequence diagrams will be greater thanne. In our example, since we apply the Log aspectual compo-ent to three different operations (join, bid and increase) (and eachequence diagram models a valid interaction between the user andhe auction) we need to modify or to create/delete three differentequence diagrams.

Finally, in Theme/UML the number of modifications is identicalo AO-ADL because only the specification of the bind relation-hip between the base and aspectual themes needs to be modified.his makes sense because both are aspect-oriented approaches andhus the representation of the type of advice is similar in bothpproaches.

.2.2. Second evolution scenarioIn the auction system, an example of this evolution scenario

ould be changing the join point in which the Consistency aspec-ual component is applied (see Fig. 3(a)). Let us suppose that initiallyhe consistency of the data was checked in the user side and thathe evolution scenario supposes that now the consistency of theata will be checked in the auction side. Let us also suppose thatonsistency is the sole aspectual component being applied in thatarticular join point.

If we take a look at the Buyer Connector in Fig. 3(a) wenly need to perform one modification. In the aspectual bindingpecified inside the connector, the original pointcut was (//pro-ided role[@name=‘Buyer’] and //operation[@name=‘*’]) and noweeds to be changed to (//required role[@name=‘Auction’] and/operation[@name=‘*’]). This means that we have changed the joinoint from the Buyer provided role to the Auction required role.

In UML 2.0, however, this evolution scenario would involvehanges on both the static and the dynamic diagrams generatedy our MDD transformations. Firstly, the crosscuts relationshipetween the Consistency component and the UserGUI com-

onent needs to be deleted and a new crosscuts relationshipetween the Consistency component and the Auction com-onent needs to be created. Secondly, the sequence diagramsepresenting the weaving between base and aspectual compo-

nd Software 85 (2012) 525– 545

nents need to be modified. In this case we would only need tochange the UserGUI component for the Auction component andwe decided to quantify this change as a modification instead of athe deletion/creation of sequence diagrams. We will need to modifya sequence diagram for each operation intercepted by the pointcutas in the previous evolution scenario.

Finally, as it occurred in the first scenario the number of mod-ifications in Theme/UML is identical to AO-ADL because only thespecification of the bind relationship would need to be modifiedto reflect the change in the pointcut specification.

7.2.3. Third evolution scenarioLet us now suppose that in the same join points there is

more than one aspect to be injected (e.g. the Consistency andthe Encryption aspectual components). However, the evolutionscenario only contemplates the join point changes for the Con-sistency aspectual component. For the Encryption aspectualcomponent, the join point remains the same. In this scenario theAO-ADL software architecture requires more changes than in pre-vious ones. Concretely, the old aspectual binding section in theconnector needs to be modified to delete the binding entry for Con-sistency. Moreover, a new aspectual binding section needs to beadded to the connector in order to specify how consistency is nowapplied to a different join point. Likewise, the number of changesalso increases in UML 2.0 and even in Theme/UML (in addition tothe bind relationships, the merge relationship between the encryp-tion and the consistency themes needs to be deleted because theyare no longer applied in the same join point). This means that theevolution in AO-ADL is still better supported than the evolution inTheme/UML and UML 2.0, requiring less effort.

7.2.4. Fourth evolution scenarioThe last evolution scenario consists of adding a new aspectual

behavior to the software architecture. In AO-ADL, assuming thatthe connector already exists and that there are other aspects beingapplied to the pointcut affected by this new aspect, this evolutionscenario implies creating a new aspectual component, creating anew aspectual role in the connector and creating the attachmentbetween the new aspectual component and the new aspectualrole. Moreover, the aspectual binding in the connector needs to bemodified in order to add the information about the new aspectualbehaviour being applied to the pointcut.

In UML 2.0 a new component also needs to be created, as wellas a new crosscuts relationship. Moreover, assuming that theaspectual behaviour will be applied to the same pointcut discussedin previous scenarios (which captures three different operations),three sequence diagrams (one for each operation) need to bedeleted and created to incorporate the new aspectual behaviour.

Finally, in Theme/UML the new aspectual behaviour is modelledby 1 or more new themes (depending on the selected granularity),with two internal components and a new sequence diagram. More-over, 1 bind relationships needs to be created for this new aspectualtheme.

7.3. Implementation of the MDD transformations

We have implemented the approach presented in this papercompletely, and the example with the transformation rules is avail-able from the AO-ADL web site.13 In this subsection we discuss how

tions.

13 http://caosd.lcc.uma.es/aoadl/download.htm.

M. Pinto et al. / The Journal of Systems and Software 85 (2012) 525– 545 543

Table 7Reusability of ATL rules.

# ATL rules # Total helpers # Common helpers % Reuse of helpers

Theme/UML 34 266 204 76.7%

7

trftt

ps(cTtr

prta(eTfaaptmt

tMsttcmmotapAhWttsrAaw

sAet

UML 2.0 39 246

.3.1. Test suite for the MDD transformationsWhile much research has been conducted on transforma-

ion languages and tool support for conducting transformations,elatively little attention has focused on testing the model trans-ormations (McQuillan and Power, 2009). The consequence is thathe field currently lacks adequate techniques to support modelransformations testing (Fiorentini et al., 2010).

Basically, since a transformation language is similar to any otherrogramming language, their correctness can be verified either viaome kind of formal method or via the definition of a test suiteFiorentini et al., 2010). The application of both approaches in theontext of model transformations is under investigation presently.hus, the available techniques are not mature enough as to be sys-ematically used in the evaluation of the correctness of our ATLules.

On the one hand, the ATL Eclipse plug-in does not yet incor-orate any kind of support to evaluate the correctness of the ATLules programmed with it. On the other hand, we did not find anyool that would allow us to formally validate our ATL rules (Trattnd Gogolla, 2010). Some works investigate the use of formalismse.g. Maude, a formal language based on rewriting logic), whichnables the simulation and formal analysis of the ATL specifications.hese approaches provide a representation of ATL constructs in aormal language. Even though this can be a useful approach, therere two disadvantages that prevented us from using this kind ofpproach: 1) none approach provides tool support to automaticallyerform this formal analysis, and (2) some of them implement theransformations between the ATL and the formal language meta-

odel precisely in ATL. Thus the question that arises here is howhe correctness of these new ATL rules can be validated.

Thus, by know, the best available alternative is to use tradi-ional test suites in the context of MDD. In this sense, the work in

cQuillan and Power (2009) defines rules, instructions and deci-ion coverage criteria in the definition of test suites for modelransformations. We have followed a similar approach in order toest our ATL rules by defining a test suit that allowed us to: (1)heck the coverage of the elements in the source metamodel. Thiseans that we checked that for all the elements in the source meta-odel there is at least one ATL rule that transforms it to elements

f the target metamodel; (2) test each individual ATL rule to checkhat it correctly generates the elements of the target metamodel,nd the relationships between them, according to the mappingreviously specified from AO-ADL to Theme/UML and from AO-DL to UML 2.0, and (3) check the coverage of the ATL rules andelpers by checking that all the rules are invoked at least once.e designed our test cases making sure that all the elements in

he metamodel of AO-ADL are considered in at least some of theests. Moreover, we have generated several versions of the auctionystem, the health-watcher system and the toll system with goodesults, since the designs in UML and Theme/UML generated by theO-ADL Tool Suite are the same than the ones generated manu-lly, which is a good indicator that the automatic transformationsork well.

Note that we have used ATL because it provides us with the

upport we need to automate the MDD transformations from ourO-ADL architectural language to detailed design languages. How-ver, it is out of the scope of our research the specification of formalechniques to evaluate model transformations. This is the main

204 83%

reason for choosing the test suite approach – i.e. it is right nowas far as we know the only available mechanism to systematicallytest a model transformation implemented with the ATL language.However, as soon as tools to formally evaluate ATL transformationare available we will use them to improve the evaluation of thecorrectness of our ATL rules.

7.3.2. Reusability and scalability of ATL rulesIn this paper we have presented two different transformations:

from AO-ADL to Theme/UML and from AO-ADL to UML. The imple-mentation of the transformations was not very trivial. As shownin Table 7, we have defined 34 ATL rules and 266 helpers to gen-erate Theme/UML and 39 ATL rules and 246 helpers for the UMLtransformation. A large number of the helpers defined (204) aregeneric, being reused in both transformations with a high reuserate – 76.7% of reuse in Theme/UML and 83% of reuse in UML 2.0.So, we have made the effort to modularise and generalise the ATLtransformation rules, in order to simplify future transformationsfor new design models (e.g. JBoss metamodel) that will thereforebe defined with little effort.

Moreover, as shown in Section 7.1, the implemented ATL rulesare scalable, able to be applied not only to the simplified case studyshown throughout the paper illustrating our proposal but also toreal case-studies of greater complexity.

7.4. Final remarks and future works

In this subsection we discuss some issues that we consider rel-evant about the implementation of our approach and that has notyet been discussed in previous subsections.

Regarding the implementation of the ATL rules, the helperfunctions were implemented especially to solve the one-to-manytransformation between AO-ADL components and themes definedfor the Theme/UML. This kind of one-to-many transformationmakes it difficult to apply the declarative pattern usually followedby the ATL rules. To solve this problem we have used some imper-ative constructions provided by ATL and overall a large number ofhelper functions to simplify the transformation rules. Additionally,AO-ADL composite components also complicate the generation ofTheme/UML, since they could generate a large number of themes.This occurs because the number of themes can grow exponentiallywhen the elements defined inside composite components are alsocomposite components and all the generated themes are associatedto the same package (i.e. theme) in the design model. In order tosolve this problem the design elements generated from the trans-formation of the architectural elements that are part of a compositecomponent are stored in a new design model. Thus, the transfor-mation of an AO-ADL configuration will generate as many outputmodels as there are composite components in the architecture plusone, representing the entire architecture.

Regarding the transformation from AO-ADL to UML 2.0, one cur-rent limitation of our approach is that pointcuts in UML do notcapture all the expressiveness of AO-ADL pointcuts. In order to pre-

serve the expressiveness of AO-ADL pointcuts at design, as part ofour future work we will define new transformations to the JoinPoint Designation Diagrams (JPDDs). The JPDDs allows the specifi-cation of contextual static and dynamic join point selection criteria.

5 tems a

eigbsaiioMmitdttimawcmGio

plmctTptmtemeCtAmdAnoind

8

bdtSaiattfp

44 M. Pinto et al. / The Journal of Sys

There is also an important drawback of using UML. Basically,very tool that supports UML has its own way of storing the graph-cal information of the model. Some of those tools can generate theraphical information for an UML model lacking this information,ut the problem is that they do not generate all kinds of graphics,pecifically they do not create the sequence diagrams and thesere a very important part of our designs. As previously mentionedn Section 6, our solution to this shortcoming has been to includen the AO-ADL Tool Suite a module that creates the graphics thatther tools do not. We have implemented the module also usingDD to automatically generate the code to visualize the generatedodels. This part is not standard since the information generated

s for a specific UML editor. We have chosen MagicDraw UML ashe tool for continuing the process of development in the detailesign phase. So our module for generation of the graphic informa-ion of sequence diagrams uses a MagicDraw project with part ofhe graphics already generated and completes it with the graphicst lacks. For the particular case of the Eclipse technologies, at this

oment the GMF framework (Graphical Modelling Framework)llows the integration of EMF and GEF (Graphical Editing Frame-ork) to generate more powerful graphical editors than those

onsisting on a tree-based representation of the elements of theodel. However, at the moment of implementing our approach,EF was not mature enough as to use it. Now, as part of our ongo-

ng work we are using GEF to generate graphical editors to visualizeur models; both the AO-ADL models and the UML 2.0 models.

Finally, regarding the evolution of software architectures, asrevious said, in our approach, any change performed in the high-

evel structure of the system – i.e. that is, its software architecture,ust be done in the AO-ADL model. So, if the designer decides to

hange the architecture of the system in the UML generated model,hese changes will not be propagated to the AO-ADL specification.he reason is that the high-level structure of the system must bereserved at the detailed design level, and not viceversa. In ordero being able to apply the AO-ADL to UML transformations incre-

entally, and to preserve the additional details incorporated intohe model at the design level, we use a special notation to mark thelements of the Theme/UML or the UML 2.0 models that are auto-atically generated from our tool and to protect the new design

lements incorporated by the designer from being overwritten.urrently, these new design elements are directly translated fromhe old Theme/UML or UML 2.0 models to the new generated ones.s part of our ongoing work we plan to enhance our model-to-odel transformation rules to inform about those elements of the

etailed design that may be inconsistent after a modification in theO-ADL software architecture – e.g. when an interface of a compo-ent is changed at the architectural level, for instance by deletingne of its operations, a class diagram that was added to model thenternal behaviour of the component may be inconsistent with theew software architecture and will need to be adapted in order toelete the disappeared operations.

. Conclusions

In this paper we have shown how the use of MDD can be used toridge the gap between between AO architecture and (AO) detailedesign. We have completely implemented the model-to-modelransformations using ATL, integrating them into the AO-ADL Tooluite. The complete mapping information and the main ATL rulesre available in the AO-ADL web site. They have not been includedn the paper due to the lack of space. Current limitations of ourpproach, as well as our ongoing work to cope with these limita-

ions have also been discussed. Interested readers can downloadhe running example used in the paper, as well as other examples,rom our web page, in order to use our tool to reproduce the MDDrocess presented in the paper.

nd Software 85 (2012) 525– 545

References

Aaltonen, T., Katara, M., Kurki-Suonio, R., Mikkonen, T., 2006. On horizontal spec-ification architectures and their aspect-oriented implementations. In: Rashid,A., Aks it, M. (Eds.), Transactions on Aspect-Oriented Software Development(TAOSD), vol. 4242 of LNCS. , pp. 1–29.

Aks it, M., 2005. Systematic analysis of crosscutting concerns in the model-drivenarchitecture design approach. In: Symposium on How Adapatable is MDA?

Amaya, P., et al., 2005. MDA and separation of aspects: an approach based on multipleviews and subject oriented design. In: AOM Workshop.

Aspect-oriented Software Development, 2010. Aspect-oriented Software Develop-ment website, http://www.aosd.net/.

Atkinson, C., et al., 2003. Aspect-oriented development with stratified frameworks.IEEE Software 20 (1), 81–89.

Batista, T., et al., 2006. Reflections on architectural connection: seven issues onaspects and ADLS. In: Workshop on Early Aspect (EA), ICSE 2006 , pp. 3–10.

Beydeda, S., et al., May 2005. Model-driven Development. Springer.Brichau, J., et al., 2005. Report describing survey of aspect languages and models.

Tech. Rep. AOSD-Europe Deliverable D12, AOSD-Europe-VUB-01, Vrije Univer-siteit Brussel.

Chitchyan, R., et al., 2005. Report synthesizing state-of-the-art in aspect-orientedrequirements engineering, architectures and design. Tech. Rep. AOSD-EuropeDeliverable D11, AOSD-Europe-ULANC-9, Lancaster University.

Chitchyan, R., Pinto, M., Rashid, A., Fuentes, L., 2007. COMPASS: Composition-centricmapping of aspectual requirements to architecture. In: Rashid, A., Aks it, M.(Eds.), Transactions on Aspect-oriented Software Development (TAOSD), SpecialIssue on Early Aspects. LNCS.

Chitchyan, R., et al., October 2006. Mapping and refinement of requirements levelaspects. Tech. Rep. AOSD-Europe Deliverable D63.

Clarke, S., et al., 2005. Aspect Oriented Analysis and Design. The Theme Approach.AW Professional.

Clemente, P.J., Hernández, J., Conejero, J.M., Ortiz, G., 2011. Managing crosscuttingconcerns in component based systems using a model driven developmentapproach. Journal of Systems and Software, 84(6)1032–1053, http://www.sciencedirect.com/science/article/B6V0N-524N98F-2/2/bdbbe8221581eb82454905579afcc739, doi:10.1016/j.jss.2011.01.053.

Cuesta, C.E., del Pilar Romay, M., de la Fuente, P., Barrio-Solórzano, M., June 2006.Temporal superimposition of aspects for dynamic software architecture. In:Gorrieri, R., Wehrheim, H. (Eds.), Proceedings of 8th International Conferenceon Formal Methods for Open Object-based Distributed Systems (FMOODS), vol.4037 of LNCS. Bologna, Italy, pp. 93–107.

Czarnecki, K., et al., 2006. Feature-based survey of model transformation approaches.IBM Systems Journal 45 (3), 621–645.

Dashofy, E.M., et al., August 2001. A highly-extensible, xml-based architecturedescription language. In: Proceedings of WICSA , Amsterdam, The Netherlands,pp. 103–112.

Demir, A., 2006. Comparison of model-driven architecture and software factoriesin the context of model-driven development. In: Workshop on Model-basedDevelopment of Computer-based Systems, MBD-MOMPES 2006 , pp. 75–83.

Fiorentini, C., Momigliano, A., Ornaghi, M., Poernomo, I., 2010. A constructiveapproach to testing model transformations. In: Proceedings of the Third Inter-national Conference on Theory and Practice of Model Transformations, ICMT’10,. Springer-Verlag, Berlin/Heidelberg, pp. 77–92.

Fuentes, L., et al., 2007. Supporting the development of CAM/DAOP applications:an integrated development process. Software Practice and Experience 37 (1),21–64.

Fuentes, L., et al., 2003. How MDA can help designing component- and aspect-basedapplications. In: Proceedings of EDOC , pp. 124–135.

Garcia, A., et al., 2006. On the modular representation of architectural aspects. In:EWSA 2006, vol. 4344 of LNCS , pp. 82–97.

Garlan, D., et al., November 1997. ACME: an architecture description interchangelanguage. In: Johnson, J.H. (Ed.), Proceedings of CASCON. IBM Press, Toronto,Ontario, pp. 169–183.

Greenfield, J., et al., 2004. Software Factories: Assembling Applications with Patterns,Frameworks, Models & Tool. Wiley.

Greenwood, P., et al., 2007. On the contributions of an End-to-End AOSD testbed. In:Proceedings of the Early Aspects at ICSE: Workshops in Aspect-oriented Require-ments Engineering and Architecture Design, EarlyAspects’07 ,. IEEE ComputerSociety, Washington, DC, USA, p. 8.

Jackson, A., et al., March 2008. Mapping design to implementation. Tech. Rep. AOSD-Europe Deliverable D111.

JET Project, 2010. JET Project website, http://www.eclipse.org/modeling/m2t/?project=jet.

Kühne, T., December 2006. Matters of (meta-)modeling. Software and Systems Mod-eling (SoSyM) 5 (4), 369–385.

Kulkarni, V., et al., 2003. Separation of concerns in model-driven development. IEEEsoftware 20 (5), 64–69.

Kurtev, I., Fabro, M.D.D., July 2006. A DSL for definition of model composition oper-ators. In: Proceedings of the 2nd Workshop on Models and Aspects – HandlingCrosscutting Concerns in MDSD, 20th European Conference on Object-orientedProgramming (ECOOP) , Nantes, France.

Loughran, N., et al., March 2005. Survey of aspect-oriented middleware research.Tech. Rep. AOSD-Europe Deliverable D8, AOSD-Europe-ULANC-10, LancasterUniversity.

Luckham, D.C., et al., April 1995. Specification and analysis of system architectureusing Rapide. IEEE Transactions on Software Engineering 21 (4), 336–355.

tems a

M

M

MN

N

N

O

O

O

O

P

P

P

P

P

P

P

R

S

S

M. Pinto et al. / The Journal of Sys

cQuillan, J.A., Power, J.F., July 2009. White-Box coverage criteria for model trans-formations. In: 1st International Workshop on Model Transformation with ATL.

edvidovic, N., et al., October 1996. Using object-oriented typing to support archi-tectural design in the C2 style. In: Proceedings of ACM FSE’96 , San Francisco,USA, pp. 24–32.

ellor, S.J., et al., 2004. MDA Distilled. Addison-Wesley.avarro, E., 2007. ATRIUM: Architecture traced from requirements applying a uni-

fied methodology, PhD Thesis.avasa, A., et al., 2005. Aspect modelling at architecture design. In: EWSA 2005, vol.

3527 of LNCS , pp. 41–58.avasa, A., Pérez-Toledano, M., Murillo, J.M., 2009. An ADL dealing with aspects

at software architecture stage. Information and Software Technology 51 (2),306–324.

bject Management Group (OMG), 2003. MDA Guide, Version 1.0.1 (omg/2003-06-01).

bject Management Group (OMG), 2005a. MOF 2.0/XMI Mapping Specification, v2.1(formal/05-09-01).

bject Management Group (OMG), 2005b. Unified Modeling Language: Superstruc-ture v2.0 (formal/05-07-04).

bject Management Group (OMG), January 2006. Meta Object Facility (MOF) CoreSpecification, Version 2.0 (formal/06-01-01).

érez, J., et al., 2003. PRISMA: towards quality, aspect-oriented and dynamic soft-ware architectures. In: QSIC 2003 , pp. 59–66.

essemier, N., et al., 2004. Components, ADL and AOP: towards a common approach.In: Workshop on Reflection, AOP and Metadata for Software Evolution (RAMSE),ECOOP 2004 , pp. 61–69.

essemier, N., et al., 2006. A model for developing component-based and aspect-oriented systems. In: Symposium on Software Composition (SC), vol. 4089 ofLNCS , pp. 259–274.

into, M., et al., 2003. DAOP-ADL: an architecture description language for dynamiccomponent and aspect-based development. In: GPCE 2003, vol. 2830 of LNCS ,pp. 118–137.

into, M., et al., 2005. A dynamic component and aspect-oriented platform. TheComputer Journal 48 (4), 401–420.

into, M., Fuentes, L., 2008. Aspect-oriented modeling of quality attributes. In:Meersman, R., Tari, Z., Herrero, P. (Eds.), Proceedings of IWSAA 2008, vol. 5333of LNCS. Springer-Verlag, pp. 334–343.

into, M., Fuentes, L., Troya, J.M., 2011. Specifying aspect-oriented archi-tectures in AO-ADL. Information and Software Technology, in press,http://www.sciencedirect.com/science/article/B6V0B-52P6KY8–2/2/b39a05a046e1e649359c085ad4f8798a, doi:10.1016/j.infsof.2011.04.003.

ashid, A., et al., 2010. Early aspects: aspect-oriented requirements engineering and

architecture design, http://www.early-aspects.net/.

ánchez, P., et al., 2006. Towards MDD transformations from AO requirements intoAO architecture. In: EWSA 2006, vol. 4344 of LNCS , pp. 159–174.

ánchez, P., Moreira, A., Fuentes, L., Araújo, J., Magno, J., 2010. Model-driven devel-opment for early aspects. Information and Software Technology 52 (3), 249–273.

nd Software 85 (2012) 525– 545 545

Simmonds, D., et al., 2005. An aspect oriented model driven framework. In: EDOC2005 , pp. 119–130.

Soares, S., Laureano, E., Borba, P., 2002. Implementing distribution and persistenceaspects with AspectJ. In: Proceedings of the 17th ACM SIGPLAN Conferenceon Object-oriented Programming, Systems, Languages, and Applications, OOP-SLA’02 ,. ACM, New York, NY, USA, pp. 174–190.

Stahl, T., et al., 2006. Model-driven Development: Technology, Engineering, Man-agement. Wiley.

Tizzei, L.P., Dias, M., Rubira, C.M., Garcia, A., Lee, J., 2011. Components meet aspects:assessing design stability of a software product line. Information and SoftwareTechnology 53 (2), 121–136.

Tratt, L., Gogolla, M. (Eds.), July 2010. Theory and Practice of Model Transformations,vol. 6142 of Lecture Notes in Computer Science. Springer, Berlin/Heidelberg.

Mónica Pinto is an associate professor in the Languages and Computer ScienceDepartment at the University of Málaga (Spain). She received the MSc. degree inComputer Science in 1998 from the University of Málaga, and her Ph.D in 2004 fromthe same University. Her main research areas are component-based software engi-neering, aspect-oriented software development, architecture description languages,model-driven development, and context-aware mobile middleware. In the last yearsshe has co-organised the Early Aspects workshop at ICSE, and has been member ofthe programme committee of several workshops and conferences on AOSD and soft-ware composition. She has been publicity co-chair at AOSD 2011 and AOSD 2012. Sheis involved in the AOSD European Network of Excellence and currently participatesin several national and international projects on AOSD.

Lidia Fuentes received her MSc degree in Computer Science from the University ofMálaga (Spain) in 1992 and the Doctorate degree in 1998 from the same Univer-sity. She has been an Associate Professor at the Department of Computer Science ofthe University of Málaga since 1993, and currently she is Full Professor from 2011.Her research interest deals with Model-Driven Development, Aspect-Oriented Soft-ware Development, Software Product Lines (SPL) and its application to pervasivesystems. Her scientific production is very prolific, with more than one hundred sci-entific publications in international forums. Her most significant publications canbe found in international journals, such as IEEE Internet Computing, IEEE Trans. onSoftware Engineering, ACM Computing Surveys or Information and Software Tech-nology journal. Her work has currently around one thousand citations. She leadsthe Analysis and Design lab in the post-EC phase of the NOE AOSD-Europe. She hasserved on the programme committee of multiple conferences such as AOSD, OOPSLAor GPCE. She is actively participating in several European research projects aboutAOSD, MDD and SPLs (e.g. AOSD-Europe, AMPLE, etc.). She is currently head of theCAOSD research group.

Luis Fernández is a PhD Student in the Languages and Computer Science Depart-ment at the University of Málaga (Spain). He received the MSc. degree in ComputerScience in 2011 from the University of Málaga. His main research areas are aspect-oriented software development and model-driven development.