Specifying aspect-oriented architectures in AO-ADL

Information and Software Technology 53 (2011) 1165–1182

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

Specifying aspect-oriented architectures in AO-ADL

Mónica Pinto ⇑, Lidia Fuentes, José María TroyaDpto. de Lenguajes y Ciencias de la Computación, University of Málaga, Campus de Teatinos, s/n, E29071 Málaga, Spain

a r t i c l e i n f o

Article history:Received 21 July 2010Received in revised form 17 March 2011Accepted 15 April 2011Available online 23 April 2011

Keywords:Software EngineeringSoftware ArchitecturesLanguagesAspect-Oriented Software DevelopmentMetrics

0950-5849/$ - see front matter � 2011 Elsevier B.V. Adoi:10.1016/j.infsof.2011.04.003

⇑ Corresponding author. Tel.: +34 952132796; fax:E-mail addresses: [email protected] (M. Pinto),

[email protected] (J.M. Troya).

a b s t r a c t

Context: Architecture description languages (ADLs) are a well-accepted approach to software architec-ture representation. The majority of well-known ADLs are defined by means of components and connec-tors. Architectural connectors are mainly used to model interactions among components, specifyingcomponent communication and coordination separately. However, there are other properties that cutacross several components and also affect component interactions (e.g. security).Objective: It seems reasonable therefore to model how such crosscutting properties affect componentinteractions as part of connectors.Method: Using an aspect-oriented approach, the AO-ADL architecture description language extends theclassical connector semantics with enough expressiveness to model the influences of such crosscuttingproperties on component interactions (defined as ‘aspectual compositions’ in connectors).Results: This paper describes the AO-ADL language putting special emphasis on the extended connectorsused to specify aspectual and non-aspectual compositions between concrete components. The contribu-tions of AO-ADL are validated using concern-oriented metrics available in the literature.Conclusion: The measured indicators show that using AO-ADL it is possible to specify more reusable andscalable software architectures.

� 2011 Elsevier B.V. All rights reserved.

1. Introduction

Software architecture can be considered quite a mature disci-pline, which focuses on a high-level representation of the softwaresystem structure. Software architecture helps developers to thinkabout a system’s complexity, in order to obtain the architecturalconfiguration that facilitates the best possible evolution and main-tenance management of the final system [1]. Because of this, recentapproaches in software engineering consider the description of thesoftware architecture as an important part of the software devel-opment life cycle. Architecture Description Languages (ADLs) wereproposed to represent the software architecture of a system, pro-viding precise descriptions of the constituent computational com-ponents and of their interactions [2]. A detailed discussion of thebenefits of using ADLs can be found in [3]. Due to the benefits ofdescribing the software architecture in the early stages of the soft-ware life cycle, a large number of ADLs have been proposed [3].These languages usually describe the software architecture of asystem in terms of components and connectors. Components encap-sulate computation and connectors represent patterns of commu-nication and interactions between components.

ll rights reserved.

+34 [email protected] (L. Fuentes),

This separation of concerns between computation and commu-nication helps to increase the reuse of software artifacts. However,some other concerns (e.g. security, persistence and synchroniza-tion) normally crosscut several components, also affecting compo-nent interactions. These crosscutting concerns cannot be easilylocated using traditional ADLs, either inside individual componentsor in connectors (none of the ADLs described in [3,4] provide expli-cit support to separate crosscutting concerns). For example, persis-tence is a crosscutting concern that deals with recording the stateof different software components in a database. Using traditionalADLs, the interaction between persistent components and thedatabase will be scattered among the different component inter-faces, and tangled with the components base functionality. Thisscattered and tangled behavior frequently results in poor architec-ture descriptions with highly coupled components, preventingreusability and evolution management of the affected components.Recently several empirical studies reveal that crosscutting con-cerns degrade system quality because they negatively impactinternal quality metrics such as coupling, separation of concerns,defects or reusability [5].

Coping with scattering and tangling of crosscutting concernproblems is the main goal of Aspect-Oriented Software Develop-ment (AOSD)1 modeling crosscutting concerns as ‘aspects’. AOSDpromotes the principle of separation of concerns throughout all

1 http://www.aosd.net.

http://dx.doi.org/10.1016/j.infsof.2011.04.003

mailto:[email protected]



http://www.aosd.net

http://dx.doi.org/10.1016/j.infsof.2011.04.003

http://www.sciencedirect.com/science/journal/09505849

http://www.elsevier.com/locate/infsof

1166 M. Pinto et al. / Information and Software Technology 53 (2011) 1165–1182

the phases of the software life cycle, including software architecturedesign (Aspect-Oriented Architectural Design, AOAD). In [6] a quan-titative comparison of aspect-oriented (AO) and traditional architec-tures is presented, revealing that an AO architecture normallyimproves separation of concerns and component cohesion, enhanc-ing the evolution management of the system. On the other hand,since crosscutting concerns are normally hard to find, understandand work with, separating and specifying them at the architecturallevel will provide a means of understanding how to make changesto system concerns (update/add/remove concerns) correctly andconsistently before moving to implementation. Despite the needfor and benefits from specifying and documenting crosscutting con-cerns, there is a notable lack of support for them in existing ADLs(none of the ADLs described in [3,4] provide explicit support to spec-ify and document crosscutting concerns).

In this paper we present AO-ADL, an aspect-oriented ADL (AOADL) based on XML. The goal of AO-ADL is to provide a languagesupport flexible enough to separate and inject crosscutting con-cerns in a non-intrusive way at the architectural level. Followinga symmetric approach, AO-ADL models crosscutting concerns (i.e.aspectual components in AOAD terminology) using the classicalcomponent. So, components model both crosscutting and non-crosscutting concerns (i.e. base components in AOAD terminology).As crosscutting concerns influence base component interactions, itseems reasonable to model their composition with base compo-nents as part of connectors. AO-ADL extends the classical connec-tor semantics with enough expressiveness to model the influenceof crosscutting concerns on component interactions by means ofaspectual compositions. Aspectual compositions in AOAD terminol-ogy is defined as the weaving between base and aspectual compo-nents at architectural level. In order to preserve the building blocksthat define the architectural structure in classical ADLs, connectorsin AO-ADL encapsulate any kind of component interaction, eitheraspectual or non-aspectual, in a homogenous way. This facilitatesthe understanding of how a set of aspectual components affect agiven interaction between base components.

So, with AO-ADL it is possible to retain base structural proper-ties of architectural models while at the same time being able toinsert ‘‘aspects’’ into the model simply by modifying or addingnew connectors. The resulting architectural description will bemore cohesive and less coupled, since base components do notcontain any reference to aspectual components, which only encap-sulate one concern. This means that the evolution and mainte-nance management is greatly improved since crosscuttingconcerns are localized in separate modules and their compositionis defined separately inside connectors. This will have a positiveimpact on several qualities of the software system as shown in thispaper (e.g. evolvability, traceability, composability and reusabil-ity2). Finally, describing AO-ADL architectural specifications is sup-ported by a toolkit that facilitates the work of software architects,being also part of an AO integrated development environment (IDE).3

The organization of the rest of the paper is as follows. The fol-lowing section presents the AOSD background, firstly describingAO architectural design concepts and, secondly, providing a de-tailed discussion about the shortcommings of current AO ADLs.Then, the case study used to illustrate AO-ADL concepts and themain features of the language are presented in Section 3. Sincethe main building blocks of AO-ADL are components and connec-tors we dedicate a section to each of them in Sections 4 and 5.Then, in Section 6 we describe the AO-ADL Tool Suite that supportsthe specification of AO-ADL descriptions, and outline how these

2 These properties are defined as qualities of an architectural configurationdescription in [3].

3 http://www.aosd-europe.net/ In Research ? Atelier ? IDE Framework ? Tools ?IDE Tools with Achieved Integration.

tools are integrated in a development methodology. As a proofosf concept, in Section 7 we validate our approach by presentinghow specifying software architectures in AO-ADL may have a posi-tive impact on several qualities, enhancing the system evolutionmanagement. Finally, in Section 8 we present our conclusionsand further work.

2. Related work on aspect-oriented architecture design

In this section we first describe common AOSD terminology,specific to the architectural-level. Secondly, we provide an over-view of existing aspect-oriented ADLs.

2.1. Aspect-oriented architectural design

AOSD aims to achieve separation of those concerns that arescattered among multiple software artifacts, which are known ascrosscutting concerns. The main motivation for using AOSD is theimpossibility of traditional software technologies, like object-ori-ented programming or component-based software development,to appropriately modularize crosscutting concerns. AOSD copeswith this limitation by introducing the concept of aspect.

Although AOSD covers all the phases of the software life cycle,the terminology used at architectural level is strongly influencedby the one introduced in Aspect-Oriented Programming (AOP)[7]. As defined in [8], an architectural aspect is a unit for modularis-ing an otherwise crosscutting concern. Non crosscutting concernsare considered base components. Inside an architectural aspect,the advice specifies the operations that will transform (augmentor diminish) the architecture at certain architectural join points.Architectural join points are well-defined points in the specifica-tion of the software architecture, where aspect composition takesplace. For each architectural style, a specialized set of join pointscan be defined, such as the invocation of services, publishing/sub-scribing of events, etc. [9]. Usually the aspect behavior (or architec-tural advice) can be inserted or woven before, after or around a joinpoint. Architectural pointcuts refer to collections of architecturaljoin points. An architectural pointcut is an expression that specifiesevery place where an aspect behavior is injected.

Nevertheless, defining a new artifact called aspect (or architec-tural aspect in AOAD) introduces some asymmetry into AO architec-tures, causing some problems to arise. Asymmetric architecturalmodels mean that concerns modeled as aspects cannot be (re) usedas standalone architectural components, reducing their reusabilitypossibilities. Also, this asymmetry prevents the same componentfrom playing an aspectual or non-aspectual role depending on therequirements of each system. In order to overcome these limitations,symmetric models do not distinguish between components and as-pects (as is defined in [10–12]), but between aspectual or non-aspec-tual compositions. An aspectual composition specifies the interactionbetween base components influenced by other components playingan aspectual role, according to an architectural pointcut definition.When a component plays an aspectual role it could also be namedat architectural level an aspectual component.

2.2. AOAD related works

A large number of AO approaches have emerged in recent yearsat each level of the software life cycle. A detailed comparison be-tween the most representative AOAD approaches can be found inthe survey [13]. The results of this survey illustrate that only afew AO proposals were defined at the architectural level, includingour previous work DAOP-ADL [14]. After this survey was pub-lished, some new AO ADLs have appeared. In this section we willcompare several AO ADLs and remark on some shortcomings that

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

M. Pinto et al. / Information and Software Technology 53 (2011) 1165–1182 1167

our AO-ADL seeks to resolve. Specifically, in order to compare AOADLs, there are some questions that need to be answered: (1) whatare the main architectural blocks of the language?; (2) how iscomposition between ‘base’ and ‘aspectual’ components repre-sented?; (3) what are the types of join points, and (4) is the lan-guage integrated as part of an IDE from AO requirements to AOimplementation? (see Table 1).

With respect to the first issue, there is no consensus amongexisting AO architectural approaches [13,15]. While some of themadd a new building block named aspect to model crosscutting con-cerns, others represent aspects as components with a differentsemantics, or as components that provide or require special ‘aspec-tual’ interfaces. In this paper, aspectual interfaces are new/specialinterfaces that AO architectural approaches add to the definitionof components in order to represent the aspectual behavior pro-vided by those components. As shown in Table 1 there is not a soledefinition and each approach models this aspectual information ina different way. In this sense, in DAOP-ADL [14,16] (our previouswork) aspects are first-order entities defining an evaluated inter-face. This interface specifies how aspects affect component inter-faces. Similarly, in FAC (Fractal Aspect Component) [17] a newkind of component named aspectual component is defined contain-ing a special aspect component interface that provides a set of meth-ods to introspect on a join point.

In order to overcome the reusability limitations of asymmetricapproaches, recent approaches propose using the same buildingblock (e.g. a component) to represent both non-crosscutting andcrosscutting concerns. A proposal following this approach is PRIS-MA [18],4 which defines components and connectors that can im-port aspects modeling either crosscutting or non-crosscuttingconcerns. Their components and connectors cannot be consideredconventional therefore; the proposal is symmetric in the sense thatPRISMA architecture configurations are externally composed bycomponents and connectors, but asymmetric since aspects are firstorder entities of the language, modeled by an entity called aspect.Internally, both components and connectors are composed by as-pects. AspectualACME [20] is an AO extension of ACME where as-pects are modeled symmetrically as ACME components. Finally,the AspectLEDA is a symmetric extension of a pi-calculus basedADL [21] called LEDA. In these symmetric approaches, componentsborrow most of the concepts (interfaces, ports, roles) of traditionalADLs. Since PRISMA incorporates aspects as first-order entities ofthe ADL, it incorporates the concept of public services of an aspectin order to model what we have called in this paper aspectualinterfaces.

With respect to the aspectual composition issue, although thereare differences in existing AO ADLs, most of them agree that thesemantics of the compositions have to be somehow extended toincorporate aspectual mechanisms into an ADL. Once again, aninteresting analysis and comparison of this issue has been per-formed in [13,15]. In DAOP-ADL and in FAC, connections are de-fined outside components, in a specific composition section. InPRISMA, since aspects are part of both components and connectors,the composition specification is also specified inside both compo-nents and connectors. In AspectualACME, the composition modelis centered on the concept of aspectual connector, a new kind ofconnector used to add crosscutting concerns to base ones. Thensome interactions between base components must be specifiedusing a connector (non aspectual compositions) and others involv-ing ‘aspectual components’ must be modeled using an aspectualconnector (aspectual compositions), introducing an additionalcomplexity to the resulting specifications. In AspectLEDA the

4 There is also an extension of PRISMA specific for ambients in mobile aspect-oriented architectures [19], although in this paper we focus only on PRISMA.

semantic of LEDA connectors is not modified and a new kind ofcomponent with the role of ‘coordinators’ has to be included in or-der to describe compositions. So as in AspectualACME, AspectLEDAdefines the aspectual compositions outside the base connector ofthe language.

All these proposals define a set of join points that can be inter-cepted in aspectual compositions. The majority of them define asjoin points the sending and receiving of a message (or method calland execution) and the throwing and catching of events. However,there are other points in component interfaces that would be desir-able to be intercepted by AO ADLs, such as the creation ofcomponents.

Finally, we study for each proposal the phases of the softwarelifecycle that are encompassed by their tool support. Firstly, at earlystages of the development it would be very useful to define somekind of mapping between AO requirements models and AO architec-ture [22]. In most of the proposal studied this is not considered, andthe software architect has no help to identify crosscutting concernsat architectural level from the requirements specification. Excep-tions are AspectLEDA [21] and PRISMA [23], which have methodo-logical support to map requirements specifications into architectural specifications. Secondly, at later stages of the development,some of the studied proposals offer the possibility of generatingimplementation code (e.g. FAC, PRISMA, AspectLEDA), while othersallows the generation of UML designs (e.g. PRISMA). Few of them(PRISMA and AspectLEDA), however, are integrated into a completemethodology, so in the rest of the proposal studied it is not possibleto identify and model crosscutting concerns at requirements level,map them to architectural aspects, map again to AO design ap-proaches and finally generate an AO implementation. Although dis-cussing the mapping process from requirements to implementationis not the aim of this paper, we consider that the integration of as-pect-oriented ADLs into an AO development methodology is rele-vant for the adoption of these ADLs. Other language-specificlimitations of these AO ADLs will be presented throughout the restof the paper, where the AO-ADL solution is described.

3. Our approach

AO-ADL is an aspect-oriented ADL that was defined in the con-text of the AOSD-Europe research project.5 The goal of this projectwas to define a joint European proposal for developing AO applica-tions from requirements to implementation. At the architecturallevel, we extended and adapted our former ADL, called DAOP-ADL, to the new trends and requirements suggested by the otherproject partners, including industrial partners (Siemens and IBM).There are important differences between DAOP-ADL and AO-ADLthat justify the consideration of AO-ADL as a new ADL:

1. Asymmetric versus symmetric model. DAOP-ADL follows anasymmetric model. New building blocks were introduced inDAOP-ADL in order to model aspects and aspectual interfaces.Contrarily, AO-ADL is symmetric. The same building block(the component) is used to model both ‘‘base’’ and ‘‘aspectual’’components.

2. Implicit versus explicit connectors. DAOP-ADL did not explicitlyinclude the concept of connector. Instead, an architecture con-figuration was organized in three subsections: description ofcomponents, description of aspects and description of weavinginformation. AO-ADL explicitly defines the concept of connec-tor, encapsulating pointcut specifications and weaving informa-tion into it.

5 http://aosd-europe.net.

http://aosd-europe.net

Table 1Comparison of AO ADLs.

Architectural building blocks Aspectual compositions Join points types IDE or Tool support

Sym/asym

Aspectualcomponents

Aspectualinterfaces

Place Specification

DAOP-ADL

Asym Aspect Evaluatedinterface

Compositionsection

Aspect evaluationrules

MESSAGE, EVENT Specification and Repository tools

FAC Asym Aspectualcomponent

Aspectcomponentinterface

Compositedefinition

Aspect binding andweave tags

MESSAGE Deployment and monitoring tools

PRISMA Sym/asym

Aspect Publicservices ofaspects

PRISMAcomponents andconnectors

Weavings MESSAGE MDD tool based on DSL tools (modelingand code generation)

AspectualACME

Sym Components Ports Aspectualconnector

Crosscutting rolesand glue

MESSAGE, EVENT Mapping to UML 2.0

AspectLEDA

Sym Components Interfacesand roles

Component‘coordinator’

Compositions andattachments

MESSAGE, EVENT Specification, code generation andverification tools

AO-ADL Sym Components Ports(providedinterface)

Connectors Aspectual roles andaspectual bindings

MESSAGE, EVENT,ATTRIBUTE, FACTORY,EXCEPTION

MDD tools (specification, detailed designgeneration tool and code generation tool)


3. Quantified roles. DAOP-ADL did not include the concept of quan-tified roles, an important feature of AO-ADL.

4. CAM/DAOP specific ADL. DAOP-ADL was somehow linked to theCAM/DAOP approach, a middleware for the development ofaspect-oriented applications, where the weaving was drivenby the architectural information provided using DAOP-ADL.AO-ADL is a general-purpose aspect-oriented ADL.

3.1. Case study

Throughout the paper we will use the Health Watcher (HW)system [24] to illustrate the main contributions of our approach.The motivation for choosing this case study was twofold. Firstly,it is a relatively simple system with a considerable number ofcrosscutting concerns. Secondly, it is an industrial case study partof an AOSD testbed [25] in which the authors are participating.The following is a shortened version.

The purpose of the HW system is to collect and manage publichealth related complaints and notifications. The system is alsoused to notify people of important information regarding theHealth System. There are two kinds of users: citizens andemployees. Citizens interact with the system to specify a com-plaint or to query information about the health services or com-plaints. In the event of a complaint being made, it will beregistered on the system and addressed by a specific depart-ment. Employees have special permissions to manage the com-plaints, return a response and update the states of complaints.The system may be available via the Internet, and must be capa-ble of handling 20 simultaneous users. Data consistency mustbe ensured, otherwise changes in complaints must be rolled-back (. . .). Apart from the main functionality of the system,usability, availability, performance, security and distributionhave been identified as non-functional requirements.

Our primary aim is to show the advantages of modeling an AOversion of the HW system using AO-ADL. AO-ADL interfaces, com-ponents and connectors are graphically represented in Fig. 1. Forthe sake of simplicity, in this paper we will only model a subsetof the non-functional requirements that appear in the require-ments document. According to a 3-layer architecture the main‘base’ components are: the Citizen View and Employee View compo-nents model the point of access to the citizens and the employeessystems respectively (i.e. the view layer); the HealthWatcherModel

component models the business of the application (i.e. the modellayer), and the HealthWatcher Data Store models the data of the

application (i.e. the data layer). These are composite componentswith several internal components modeling the different function-alities of the system. Note, that following an AO approach the pro-vided and required interfaces of components do not include anyoperation regarding crosscutting concerns, such as security(authentication, encryption and access control), consistency, errorhandling, synchronization and feedback, which are modeled inFig. 1 as separate (aspectual) components (boxes in gray in Fig. 1).

3.2. An overview of AO-ADL

In this section we will summarize the main characteristics ofAO-ADL. This section is intended as a guide to make the paper eas-ier to read, by referencing the sections where each of these charac-teristics are detailed, and by giving a rough description of the casestudy specification depicted in Fig. 1.

– Symmetric decomposition. AO-ADL defines a symmetric modelwhere both non-crosscutting and crosscutting concerns aremodeled by base components (see Section 4).

– Extended connectors. Connectors (graphically represented by cir-cles) used in most ADLs are extended with AO compositionmechanisms, enhancing the specification of more reusable, scal-able, and evolvable software architectures.

– Aspectual and non-aspectual compositions. The AO-ADL connec-tor can model either base compositions (described in subSection5.2), and aspectual compositions (described in subSection 5.3).The Conn1 connector in Fig. 1 is an example of a classical con-nector, modeling the communication between the Citizen View

and the HealthWatcher Model components. The Conn2 connectoris an aspectual connector, meaning that, in addition to the baseinteraction between the Citizen View and the HealthWatcher

Model components, it models the aspectual interactions of theAccess Control, the Consistency and the Synchronization (aspectual)components. We define two connectors to separately illustrateclassical and aspectual interactions.

– Join points and advices. AO-ADL offers a set of join points anda kind of advices richer than that provided by current AOADLs (e.g. �EXCEPTION� in Conn5). They are more or lessequivalent to those defined by the AspectJ language, but onlythose which are architecturally relevant are considered (seeSection 5.3.1). This richer set of join points improves thesemantics of aspectual compositions. Concerning the advices,AO-ADL defines a new kind of advice (concurrent-with) in Sec-tion 5.3.3.

Fig. 1. Graphical representation of the HW System in AO-ADL.


– Quantified roles. The connector role definition is enriched withthe possibility of specifying a query restricting the component(s) that may be connected to that role. The Conn5 connectorillustrates the benefits of using quantified roles. In order to injectthe behavior of the Error Handling aspectual component ‘into allbase components’, we connect a provided role stereotyped as�EXCEPTION� with each component. This can be simplifiedby using quantified roles (described in subSection 5.1) as inthe Conn7 connector, simply adding a single required interfacewith wildcards (i.e. ‘⁄’, meaning ‘all’).

– Tool support. The AO-ADL Tool Suite6 gives support mainly for:(1) helping to instantiate the AO-ADL XML schema (i.e. writeAO-ADL specifications without directly manipulating XML); (2)storing components and connectors in a repository in order toencourage their reuse by simply importing them to the currentarchitectural specification; (3) generating UML and Theme/UMLdesigns; (4) generating AOP JBoss and AspectJ implementationcode.

6 Download the tool at http://caosd.lcc.uma.es/aoadl/download.htm. See videos ofour tool in action at http://caosd.lcc.uma.es/aoadl/userGuide.htm.

– Connection with other development phases. AO-ADL has beenintegrated with other approaches at different levels of the soft-ware lifecycle. Specifically, AO-ADL has been integrated withthe Requirements Definition Language (RDL) at the require-ments level [11], and with the Theme/UML model at the designlevel [26]. Regarding the implementation level, several possibil-ities have been studied to automatically generate code for AOlanguages such as AspectJ, CaesarJ [27] and AOP-JBoss.

4. The AO-ADL language: components

In this section we describe AO-ADL components (part of the AO-ADL metamodel describing components is shown in Fig. 2).

Similarly to other ADLs, AO-ADL components are the locus ofcomputation and state. Thus, the Component represents the archi-tectural element used to model both base and aspectual behavior.Components are identified by a required unique Name and aredescribed by means of their Ports (or interfaces), which can be Pro-

vided or Required. In Fig. 3 we can see that the Complaint componenthas three provided and two required ports. AO-ADL facilitates thereuse of component interface definitions, by encouraging theirspecification in separate description files (Uri, in Fig. 3). Thus, com-ponents providing and requiring the same interface (s) can reuse

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

http://caosd.lcc.uma.es/aoadl/userGuide.htm

Fig. 3. AO-ADL specification of the complaint component.

<<enumeration>>Type

ATTRIBUTE

EXCEPTION

MESSAGE

FACTORY

EVENT

ConstraintStateAttribute

ComponentState

InterfaceProvidedInterface

Connector

Operation

RequiredInterface

Composite Component Component

Semantics

Interface(port)

PortName

UriName Type

accessed by

1..*

1link_to

1

1

0..*

1is−a 0..1

1

0..1

1

has1

1

1..*1

1

1

identifies

has

1

1

plays1

1

has

identifies

1..*

1

Fig. 2. AO-ADL metamodel for components.

7 The concept of port in AO-ADL is the traditional one as in other ADLs; thedifference is that we classify them according to the different port types previouslymentioned.

8 http://caosd.lcc.uma.es/aoadl/videos/CreationComponent.htm.


their specification by specifying the Uri (s), but assigning a differentPort Name.

Additionally, in AO-ADL each port has a Type that determinesthe semantics of its operations. The Complaint component ofFig. 3 illustrates all these kinds of ports. Ports of type MESSAGE

are used to model synchronous interactions between components(port ComplaintMng including operations to update, remove and toresolve a complaint); ports of type EVENT model asynchronousinteractions between components (port ComplaintEvents includingthe events newComplaint and updatedComplaint that are thrownby the component when a new complaint is respectively createdor updated); ports of type ATTRIBUTE model the manipulationof the components state (port ComplaintState including operationsto manage the complaint state attributes); ports of type EXCEP-

TION model the exceptions thrown or handled by components(port ComplaintErrors including the erroneous situations that thecomponent can inform on); and finally, ports of type FACTORY

are used to model the creation of new component instances (portComplaintCreation including an operation to create a complaint).7

To complete the component interface specification, interfaces aredefined by a list of Operations and, optionally, may have Constraints

that can be pre- or post-conditions. A video showing how to specifycomponents using the AO-ADL ToolSuite is available.8

Note that we propose a classical component port definition and,like CCM (CORBA Component Model), AO-ADL ports are groupedby type, which gives more flexibility to the component connectionsspecification that can be performed also by port type. The differ-ence is that, in AO-ADL, we define offered and required ports notonly for messages and events, but also for attributes, exception

http://caosd.lcc.uma.es/aoadl/videos/CreationComponent.htm


and factory interfaces types. This approach extends the level ofinformation exposed by AO-ADL components, which is requiredin order to define a richer join point model (shown later in Section5.3.1). Thus, with this approach we try to achieve a compromisebetween the abstraction level required during the specification ofa software architecture, in which components should be seen asblack boxes, and the level of introspection required by AOapproaches, in which aspects may be required to intercept not onlythe communication between components, but also the statechanges or creation of the components among others.

Optionally, it is possible to specify the Semantics of a component.Normally only a high-level model of the component behavior isspecified, mainly the sequence of output and input messages (i.e.the interaction protocol [28]). Note that AO-ADL allows the embed-ding of formal languages to specify the semantics of a component,such as CSP [29] or COOL [30].

Finally, AO-ADL also allows us to define Composite Components,which can be used to encapsulate sub-architectures, or to definedifferent levels of abstractions of a component. Similarly to singlecomponents, AO-ADL composite components are defined by a setof provided and required interfaces.

5. The AO-ADL language: connectors

Similarly to traditional ADLs, the connector is the architecturalelement for modeling composition in AO-ADL. AO-ADL defines twokinds of compositions: (1) component bindings, which refer to clas-sical composition between components, and (2) aspectual bindings,which specify how ‘aspectual components’ are woven with basecomponents, one of the main novelties of AO-ADL connectors. Inthis section, the main elements of AO-ADL, shown in the metamod-el of Fig. 4, are described.

Comp

Prov

QuerySpecification

(Quantification)

Connector

Composite Component

Component

AspectualRole

RequiredRole

ProvidedRole

RoleCon Type

is defined by

1

is−a

0..*

1

1..*

1

is defined by

1..*1

1..*

1

has

Fig. 4. AO-ADL metamo

5.1. Provided, required, aspectual and quantified roles

AO-ADL distinguishes whether the component is acting as abase or aspectual component depending on the particular ‘role’the component is playing in a particular composition. In AO-ADL‘base’ components are those connected to either a Provided Role

or to a Required Role, as in traditional ADLs. For instance, the Conn2

connector in Fig. 1 models the interaction of the components con-nected to the NonSecureComplaint and the SecureComplaint providedroles (lines 2–4 in the AO-ADL specification of Conn2 shown be-low) with the components connected to the ComplaintRole requiredrole (line 6 in the code below). ‘Aspectual components’ are thoseconnected to an Aspectual Role. The Conn2 connector specifies threeaspectual roles modeling the AccessControl, the Consistency and theSynchronization crosscutting concerns (lines 8–12 of the codebelow).

1 <connector name="Conn2">2 <provided_role name="NonSecureComplaint"

type="MESSAGE"

role_specification="//interface[@name= ‘ComplaintSpecificationInt’]"/>

4 <provided_role name="SecureComplaint" type="MESSAGE

role_specification="//interface[@name=‘ComplaintUpdateInt’]" />

6 <required_role name="ComplaintRole’’ type="MESSAGE"

role_specification="//interface[@name=‘ComplaintInt’]"/>

8 <aspectual_role name="AccessControl’’ type="MESSAGE"

role_specification="//interface[@name=‘AccessControlInt’]"/>

(continued on next page)

onent Binding

<<enumeration>>Type

ATTRIBUTE

EXCEPTION

MESSAGE

FACTORY

EVENT

ided−RequiredBinding

Aspectual Binding

AttachmentConstraint

PointcutSpecification

Advice Specification

Semantics

Operator AdviceOrdering

Advice

Name

0..*

0..1

1

0..1

1

identifies

identifies

1

1

1

1

1..*

1

1..*1

1..*1

has 1..*1

1..*1

del for connectors.


10 <aspectual_role name="Consistency’’ type="MESSAGE"

role_specification="//interface[@name=‘ConsistencyInt’]"/>

12 <aspectual_role name="Synchronization"

type="MESSAGE’’role_specification="//interface

[@name=‘SynchronizationInt’]" />. . .

67 </connector>

Like component ports, connector roles (RoleCon in Fig. 4) havea Type and thus they can be affected by the same modifiers ascomponents’ interfaces (MESSAGE, ATTRIBUTE, etc.), limiting thekind of components (ports) that can be connected to a particularrole. We would like to highlight that an AO-ADL connector role isnot a mere syntactic identifier (i.e. an interface name) to be usedin the component bindings definition. Instead, in AO-ADL it ispossible to specify a query that is evaluated to determine thecomponent (s) that could be connected to these roles. Such que-ries (Query Specification (Quantification) in Fig. 4) are defined bymeans of quantifications, which are wildcards and binary opera-tors, applied over ‘any element’ of the component metamodel.For instance, the Conn6 and Conn7 connectors in Fig. 1 includeexamples of such queries (or quantifications). In Conn6, the Target

required role is a quantified role, which specifies that only a com-ponent with the name HealthWatcher Model, providing an interfaceof the type MESSAGE, whose name must start with Complaint, andalso containing at least one operation name starting with update

and one operation name starting with remove can be connectedto this connector. Only the ComplaintInt interface (see the specifi-cation of this interface in Fig. 3) of the HealthWatcher Model com-ponent fulfills this query (the line connecting this interface withthe connector role was omitted in Fig. 1). Similarly, the providedand required roles of the Conn7 connector in Fig. 1 specify thatthe Encryption aspectual component is attached to all the interac-tions between any source and target components in the systemarchitecture (note the use of the ‘⁄’ wildcard (//inter-face[name=‘⁄’]) to specify the provided and required roles of theconnector). If interactions between the HealthWatcher Model in-ner components do not need to be encrypted, then we must add//component[name=’’HealthWatcherModel’’] to the query of thetarget role.

This is a very powerful characteristic of the language, as it ispossible to define which components could be attached to a con-nector, by specifying the interface type and/or the interface nameand/or a list of operations, and so on. So if an aspectual compo-nent is present in more than one component interaction, by usingquantified roles it is possible to specify a complex query that cov-ers all the components of the system affected by such aspectualcomponent, both for the required and provided interfaces. Thisremoves from the connectors the crosscutting that is present inother AO ADLs, thereby making them more evolvable. For in-stance, aspectual connectors in AspectualACME include a glue sec-tion where the weaving information between crosscuting roles andbase roles is specified, so if an aspectual component is present inmore than one aspectual connector, a reference to its roles is scat-tered among all aspectual connectors affected by this aspectualcomponent.

5.2. Component bindings

In AO-ADL, component bindings specify classical interactions be-tween ‘base components’. The code below shows the specificationof the component bindings again of the Conn2 connector.

1 <connector name="Conn2">. . .

14 <componentBindings>15 <binding name="NonSecureBinding">

<source>//provided_role[@name=‘NonSecureComplaint’]

</source><target>//required_role[@name=‘ComplaintRole’]

</target></binding >

19 <binding name="SecureBinding"><source>//provided_role[@name=‘SecureComplaint’]

</source><target>//required_role[@name=‘ComplaintRole’]

</target></binding>

23 </componentBindings>. . .

67 </connector>

The first binding is named NonSecureBinding since the com-plaints made by citizens do not have special security requirements(line 15). The second binding named SecureBinding specifies thatemployees can update complaints, but the requirements specifica-tion requires that their access must be granted first by the system(line 19). This means that the access control functionality crosscutsthe SecureBinding composition, so following an AO approach accesscontrol should be incorporated to the architecture by an ‘aspectualcomponent’. Later we will add this crosscutting behavior as part ofan aspectual binding. Note that thanks to the definition of differentbindings, we will be able to apply aspectual behaviors to specificbase compositions, and not to the whole connector. Nevertheless,aspectual roles and aspectual bindings are optional in AO-ADL, itbeing possible to define traditional ADL connectors as in Fig. 1,the Conn1 connector.

5.3. Aspectual bindings

Along with the description of the AO-ADL aspectual bindings weneed to have previously described the AO-ADL join point model, theAO-ADL pointcuts, the AO-ADL advice model, and the AO-ADL advicespecification. All these elements are needed in order to specify theweaving between aspectual and base components.

5.3.1. AO-ADL join point modelFirstly, the architectural join point model of AO-ADL is defined in

the scope of connectors – i.e. architectural pointcuts would only cap-ture those join points exposed by base components attached to aconnector. Although this may sound like a limitation it is not; in factit has two main advantages: (1) it is in line with the idea of the con-nector as the only first-class element encapsulating compositions atthe architecture level, and (2) it alleviates the pointcut fragility prob-lem, where the use of quantifications in the specification of a point-cut may result in capturing join points not intended by thedeveloper, especially as the system architecture evolves or is refac-tored [31]. In AO-ADL this problem is reduced because since point-cuts are specified in the scope of a connector, only changes incomponents attached to a connector may affect pointcut definitionsof this connector. This means that a new component added to thesystem architecture would never be affected by a pointcutdefinition with the wildcard ‘‘any component’’, unless it is explicitlyconnected to the connector containing this pointcut definition – i.e.

Fig. 5. AO-ADL join points.


in AO-ADL the interpretation of the wildcard ‘�’ in pointcuts wouldbe ‘‘any component connected to this particular connector’’.Likewise, removing or making changes to components (e.g. renam-ing a component operation) that are not explicitly attached to aconnector will not affect the pointcut definitions of this connector.Consequently, checking the pointcut definitions of connectors aftersome kind of modifications of attached components can be done eas-ily, since these definitions are localized in individual connectors.

Secondly, our aim was to define a set of join points relevant atthe architectural level – i.e. those that should be explicitly exposedat this high-level of detail. At the architectural level all the ele-ments that are visible in the specification of components are can-didate join points (operations of component interfaces, stateattributes, events, component factory or exceptions). In order tofacilitate the description of AO-ADL join points, we have graphi-cally represented them in Fig. 5. Join points intercept a certainbehavior that takes place sometime during base components inter-actions. So, we distinguish between behavior that occurs: (1) at theprovided role of a connector, jp1:provided, (e.g. an operation callmade by a component connected to the connector provided role);(2) at the required role of a connector, jp2:required, (e.g. the recep-tion of an operation call in a component connected to the connec-tor required role); and (3) at the interaction between twocomponents previously defined as a component binding inside aconnector, jp3:composition, (e.g. in the figure, composition betweenC1 and C3 components, and C2 and C3 components). Note that joinpoints of type jp3 allow the application of different aspectualbehaviors to the particular component interactions.

For instance, in the context of the connector Conn2, examples ofjoin points of type jp1:provided would be NonSecureComplaint or Sec-

ureComplaint provided roles (lines 2 and 4 respectively). An exam-ple of a jp2:required join point would be the ComplaintRole

required role (line 6). Finally, examples of join points of typejp3:composition are the two composition bindings NonSecureBinding

and SecureBinding defined in the connector (lines 15 and 19respectively).

The combination of these join points with the different modifi-ers applied to the provided/required roles of the connector9 (MES-SAGE, EVENT, ATTRIBUTE, FACTORY or EXCEPTION) allows thedefinition of a richer set of join points than existing aspect-orientedADLs. In order to demonstrate this, the equivalence between the AO-ADL join points and the join points of AOP languages AspectJ andJBoss AOP is shown in Table 2. Note that the AO-ADL join point mod-el is richer than the AOP JBoss, and is similar to the AspectJ one, dis-carding those join points not architecturally relevant.

5.3.2. AO-ADL pointcut specificationArchitectural pointcuts, defined as collections of architectural

join points, are specified by means of the join points of Table 2.Note, that they are not specified jointly with the aspectual

9 These modifiers, as well as the justification for using them to define a richer set ofjoin points, are defined in Section 4.

behavior they are intending to inject. Instead, they are specifiedseparately from components and inside the connectors,increasing the components reuse possibilities in different con-texts. AO-ADL also uses queries and wildcards to specify thepointcuts.

Coming back to connector Conn2, the pointcut specifications(line 25 and 45 respectively in the below code) capture ‘the recep-tion of any message, starting with the ‘read’ string, by the compo-nent attached to the ComplaintRole required role’, but only whenthe message is sent in the context of the NonSecureBinding compo-nent binding and reads similarly for line 45. This means that for thesame join point (reception of a message in the ComplaintRole re-quired role) AO-ADL allows defining different advices affecting dif-ferent component interactions.


24 <aspectual_binding name="CitizenBinding">25 <pointcut_specification>

(//componentBindings/binding

[@name=‘NonSecureBinding’])

and (//required_role[@name=‘ComplaintRole’])

and (//operation[@name=‘read⁄’])</pointcut_specification>. . .

44 <aspectual_binding name="EmployeeBinding">45 <pointcut_specification>

(//componentBindings/binding

[@name=‘SecureBinding’])

and ((//required_role[@name=‘ComplaintRole’])

and (//operation[@name=‘update⁄’]))</pointcut_specification>. . .

67 </connector>

5.3.3. AO-ADL advice modelAs part of the advice definition, the place where an aspectual

component behavior will be inserted must be defined. The AO-ADL language supports four kinds of advices: before the join point,after the join point, around, or ‘instead of’ a join point, and concur-rent with or ‘in parallel with’ a join point. The latter is an importantcontribution of AO-ADL since it is not considered in other aspect-oriented ADLs.

Comparing the AO-ADL advice model with that of AspectJ, be-fore and after advices have the same meaning in both. The only dif-ference is that AspectJ distinguishes for instance, between afterreturning and after throwing advices and in AO-ADL this distinctionis not needed because it is already done at the join point definitionlevel, using the Required.MESSAGE and Required.EXCEPTION AO-ADL join points.

With respect to the around advice, the meaning is not the samein AO-ADL as in AspectJ. Basically, while in AspectJ the meaning of‘around’ depends on where the proceed method (the code execu-tion of the intercepted join point) is placed. In AO-ADL ‘around’ al-ways means executing some code in place of the code of theintercepted join point. Basically, this difference is motivated by:(1) in a symmetric approach it does not make sense that the com-ponent specifications include AOP mechanisms like proceed, whichforce them to play exclusively an aspectual role; (2) the use of aproceed statement inside a black-box component would drasticallyreduce the understandability of the software architecture, and (3)the ‘around’ advice, as is defined in AspectJ, can be easily modeled

Table 2Comparing the Join Point Models of AO-ADL and AOP languages.

AO-ADL AspectJ JBoss AOP

Provided.MESSAGE Method call Method call.EVENT – –.ATTRIBUTE Field reference/assignment combined with ‘this’ –.EXCEPTION It is not a join point, though it can be implemented with ‘after

throwing’ adviceException being thrown

.FACTORY Constructor call Call (constructor)/construction(constructor)

Required.MESSAGE Method execution Method execution.EVENT Method execution Method execution.ATTRIBUTE Field reference/assignment combined with ‘target’ Field set/get.EXCEPTION Handler execution –.FACTORY Constructor execution Execution (constructor)/construction

(constructor)

Composition.Provided.� Each join point in previous rows (Provided.�) combined with‘this’ and ‘target’

–

.Required.� Each join point in previous rows (Required.�) combined with‘this’ and ‘target’

–

Not needed. AO-ADL does not distinguish between aspectsand components.

Advice execution –

Not defined. Implementation-specific join points Static initializer execution, object pre-initialization, objectinitialization

–


as a combination of a before and an after advice over the same joinpoint.

Finally, we have investigated the possibility of representingother kinds of advices relevant at architectural level. Specifically,AO approaches at the requirements level would normally providea richer advice model, since they are not restricted to the interac-tions between components or classes as in lower stages of the soft-ware development. Normally, some temporal relationshipsbetween requirements are specified, as in the RDL [32] language.Basically, the idea is that not all the behaviors injected by an aspec-tual component have to occur before/after/around a join point.Sometimes, the advice just needs to be injected as a consequenceof the occurrence of an event (e.g. sending/reception of a message)in the system, but concurrently with such event. The several vari-ants that RDL offers to express concurrency are all grouped underthe same concurrent-with operator in our AO-ADL. In [11] we pre-sented the mapping between typical temporal operators (start,meet, overlaps, during, etc.) included as part of the RDL languageand the AO-ADL concurrent-with operator. But, to capture the par-ticular semantics of each RDL operator at the architectural level(e.g. during), we should add a synchronization aspectual compo-nent, encapsulating the synchronization between operations ofthe involved components.

5.3.4. AO-ADL Advice specificationA complete advice specification consists of defining the kind of

advice (when), the join points affected by the advice (where), thebehavior of the ‘aspectual’ components that are attached to theintercepted join points (what), and the advices relative ordering,when more than one affect the same join point (in which order).In the code below, we complete the specification of the Conn2 con-nector with the advice specification. Concretely, we specify howthe AccessControl, the Consistency and the Synchronization aspectualroles affect the join points captured by the pointcuts previouslyspecified. Inside the aspectual binding section, several pointcutsdefinitions can be specified. Each pointcut definition has associatedwith it one or more advice specifications, meaning that a join pointcan be affected by more than one aspectual behavior. In the codebelow we can observe that the kind of advice is specified in theoperator tag.


24 <aspectual_binding name="CitizenBinding’’ >25 <pointcut_specification> . . . </pointcut_specification>

30 <advice_specification operator="before"><aspectual_component

aspectual_role_name="Consistency"><advice label="isConsistent"/>

</aspectual_component><aspectual_component

aspectual_role_name="Synchronization">

<advice label="beforeRead"/></aspectual_component>

</advice_specification>38 <advice_specification operator="after">

<aspectual_componentaspectual_role_

name="Synchronization"><advice label="afterRead"/>

</aspectual_component></advice_specification>

43 </aspectual_binding>44 <aspectual_binding name="EmployeeBinding">45 <pointcut_specification > . . . </pointcut_specification>

50 <advice_specification operator="before">51 <aspectual_component

aspectual_role_name="AccessControl"post-cond="return (isAllowed) ==

true"><advice label="isAllowed"/>


aspectual_role_name="Consistency"><advice label="isConsistent"/>


aspectual_role_


name="Synchronization"><advice label="beforeWrite"/>

</aspectual_component></advice_specification>

61 <advice_specification operator="after’’ ><aspectual_component

aspectual_role_name="Synchronization">

<advice label="afterWrite"/></aspectual_component>

</advice_specification>66 </aspectual_binding>67 </connector>

It can be interpreted that the particular aspectual behavior willbe injected before (line 30) and after (line 38) the first specifiedpointcut (line 25), and before (line 50) and after (line 61) the secondone (line 45). The aspectual components that will be woven atthese pointcuts are specified by means of one of the aspectual rolespreviously defined in the connector. The name of the aspectualcomponent operation that will be executed when the join pointis reached is also specified. In the example, the advices in the firstadvice specification (lines 30–38) are the isConsistent () operationof the Consistency aspectual role and the beforeRead () operation ofthe Synchronization aspectual role. This means that these operationsare inserted before ‘the reception of any operation beginning withread in the component attached to the ComplaintRole required portof the connector, but only in the context of the NonSecureBinding

composition’ (the pointcut definition of line 25). Since the synchro-nization protocols establish that synchronization needs to be in-jected before and after reading a critical resource, there is asecond advice specification (lines 38–42) for this pointcut specifi-cation which establishes that ‘the afterRead () operation of the Syn-

chronization aspectual role needs to injected after the reception ofany operation beginning with read’. When two or more aspectsneed to be applied on the same join point at the same moment (be-fore, after, around), the order is determined by the order in whichaspects are listed in a particular advice_specification. For instance,in the advice specification specified between lines 50–60, the orderin which aspects are injected would be: first, AccessControl; second,Consistency and, third Synchronization.

The advice specification for the other pointcuts can be describedsimilarly (lines 44–66). The main difference is that now the Access-

Control aspectual behavior is injected, in addition to consistencyand synchronization. For this aspectual component we have in-cluded an example of a constraint restricting the injection of as-pects under certain circumstances. In this case a post-conditionhas been defined (line 51, isAllowed advice), which means that theother aspectual behaviors in the chain will not be applied andthe message will not reach its target if the user is not allowed todo that action (isAllowed returns false). A pre-condition may alsobe specified. These constraints can be defined in terms of thecontext exposed by the intercepted join points or in terms of infor-mation generated by aspectual components previously applied atthe same join point.

Finally, several advices being composed at the same join pointneed to be appropriately ordered. By default, advices are evaluatedin the order in which the aspectual components are specified. Inthe example ‘before’, consistency is evaluated before synchroniza-tion. If a different order is required, the operators before, after andconcurrent-with described previously can also be used to indicatethe order of advices execution.

Summarising, looking at AO-ADL connectors, the softwarearchitect can straightforwardly deduce that there is communica-tion between the components attached to the provided and

required roles. Furthermore, a primary aim in AO-ADL is also toprovide precise information about the crosscutting concerns affect-ing that particular interaction. Specifically, the AO information pro-vided by the AO-ADL connector Conn2 used as an example in thissection may be read as: ‘‘Access Control, Consistency and Synchro-nization are a crosscutting behavior constraining the interactionsbetween the components connected to the provided and the re-quired role of the connector’’. Note that this aspectual informationis more difficult to deduce in other aspect-oriented ADLs in whichthe component bindings and the aspectual bindings are specifiedin separate first-class entities [14,17] (see the related work section)and not inside the connectors as in AO-ADL. Compared to Aspec-tualACME, the main difference is in the definition of pointcuts.While in AspectualACME pointcuts are defined as part of ACMEattachments, in AO-ADL pointcuts are defined inside connectors.This means for instance that AspectualACME suffers the pointcutfragility problem commented on above. Another difference is that,though both languages allow the use of quantifications in the spec-ification of pointcuts, in AO-ADL the roles of connectors can also bespecified using quantifications removing the crosscutting of aspec-tual compositions also in connectors. As is discussed in Section 7,this feature of AO-ADL improves the evolvability, scalability andreusability of connectors.

6. AO-ADL Tool Suite: specification and generation tools

One of the main values of AO-ADL is that we offer a completetool suite that aids the developer to: (1) specify an AO softwarearchitecture enforcing the (re) use of components and connectorsstored in a repository; (2) connect the software architecture withthe design and implementation phases since the AO-ADL Tool Suiteincludes model-driven transformations to automatically generateeither a detailed design or aspect-oriented code.

AO-ADL Tool Suite [33] is implemented as an Eclipse plug-in totake advantage of all the features available from this renownedIDE. The tool is an Eclipse perspective, that is, a set of related win-dows that works together in the development process. The AO-ADLTool Suite includes the following set of tools:

� C&C Repository tool. Components, connectors and even completesub-architectures can be stored in a repository for future (re)use. This repository offers the typical functionality: create,delete, search, store, etc. folders and architectural elementsinside these folders.� Specification tool. Through the different editors, the software

architect will be able to specify a complete architecture, defin-ing the interfaces, components and connectors, without manip-ulating XML code. AO-ADL enforces the specification ofarchitectures by the (re) use of pre-developed architectural ele-ments, so this tool offers the possibility to import the specifica-tion of components and connectors from the AO-ADL C& CRepository. The tool also validates that a given architecture iscomposed by AO-ADL well-formed elements. Also it reportson whether the resulting architecture is complete or not, allow-ing the definition of partially specified architectures. Finally,this tool offers the possibility to see the list of components par-ticipating in a connector (connector view), but also the list ofconnectors and bindings where one component participates(component view).� 2 Design. In order to bridge the classical gap between architec-

ture and design, this tool allows the generation of the corre-sponding detailed design by just clicking a button. Thegenerated design can be considered as the starting point, whichdesigners may refine by adding new (crosscutting) concernsthat may appear at the detailed design phase, and by specifying


more details of previously identified components and composi-tions. Using our tool, it is possible to generate either an AOdesign (in Theme/UML) or a non-AO design (in UML). Firstly,the mapping processes to relate AO-ADL software architectureswith AO detailed designs modeled with Theme/UML [26,34]and UML 2.0 [33] were defined. Secondly, the skeleton of aTheme/UML design or a UML 2.0 design is automatically gener-ated from an AO-ADL specification. In Theme/UML we use theaspect-oriented mechanisms provided by Theme/UML to modelAO-ADL aspectual information. In plain UML 2.0, componentdiagrams are used to model AO-ADL components and their sta-tic relationships, while sequence diagrams are used to specifybase and aspectual AO-ADL compositions, including the depen-dencies between several (aspectual) components affecting thesame join point.10 The transformations from AO-ADL toTheme/UML and UML were defined using the ATL language.Since the graphical information is specific of each particularUML editor, this tool manipulates the output of ATL transforma-tions to automatically generate the graphical informationrequired to visualize the design, concretely in MagicDrawUML. The main benefit of this module is that the AO architec-tural conceptual model is the input to the detailed design and,therefore, all the aspects identified in early stages of the devel-opment will be part of the detailed design from the beginning.The technical details about how this module was developedcan be found in [33].� 2 Code. Two different approaches can be followed at the imple-

mentation level. On the one hand, it is possible to generateAspectJ and CaesarJ code from the Theme/UML design that wehave previously generated using the AO-ADL Tool Suite (usingexisting third-party transformations). This means that architec-turally relevant concerns may be preserved both in the designand in the implementation of the application. On the otherhand, it is also possible to automatically generate code for reus-able aspects directly from the information contained in AO-ADLcomponents and connectors. An example is the generation ofaspects in AspectJ or JBoss AOP from AO-ADL components. Con-cretely, the specification of the XML-based weaving informationin JBoss AOP can be easily generated from AO-ADL connectors.For instance, the mapping to JBoss AOP of part of the Conn2 con-nector used throughout the paper is shown in Fig. 6. We canobserve that elements of AO-ADL connectors have their coun-terpart in JBoss AOP (arrows labeled 2, 3 and 4). Although notshown in the figure due to a lack of space, AO-ADL componentsand interfaces are mapped to Java classes and interfaces respec-tively, embedding the JBoss AOP specific code for aspects. Thus,the Software Architect can chose between going from the archi-tecture to design or directly to implementation.

7. Evaluation of our approach

Since aspect-oriented ADLs are fairly new, there is no consensusabout the specific criteria that AO ADLs should satisfy. We base ourevaluation on a set of desirable characteristics derived from exist-ing best practices in software engineering in general, and particu-larly in traditional ADLs [3,4] and in aspect-orientation [13]. Wewill assess how the AO-ADL language improves the evolutionand maintenance management of software architectures by ana-lyzing eight qualities: reusability, scalability, refinement and trace-ability, heterogeneity, evolvability, non-functional properties,composability and tool support. We dedicate separate subsectionsto reusability and scalability to show the results of our quantitative

10 Visit our web site to download the how-to guides to perform these transforma-tions (http://caosd.lcc.uma.es/aoadl/download.htm).

evaluations. The last six qualities are then grouped in one subsec-tion, for which a qualitative evaluation discussing the impact ofour approach on those qualities have been carried out. Table 3shows a summary of the main contributions of AO-ADL and theirimpact on the qualities that we will evaluate, highlighting whichones are not supported by other AO ADLs. This table will be refer-enced throughout this section and also complete the related workshown in Section 2.

7.1. Reusability assessment of AO-ADL specifications

Our initial hypothesis is that ‘‘by separating crosscutting con-cerns in aspectual components, the resulting system componentsare more reusable than in a non-aspect-oriented version, sincewe removed the scattering from both base and aspectual compo-nent interfaces’’. Furthermore, ‘‘by using AO-ADL, not only base/aspectual components will be more reusable, but also the aspec-tual connectors’’. This will be evaluated by experimental studiesand some metrics. Firstly, we will analyze the results obtainedfor our experience with the case studies of Table 7, and, secondly,we will analyze some predictors of reusability, specifically metricsmeasuring coupling, cohesion and concern difussion. We will com-pare the results of these metrics both for AO and non-AO versions.

Experimental results on the reuse rate of crosscutting concerns.Firstly, we will analyze the reuse rate of aspectual components indifferent case studies. Some of these aspectual components encap-sulate crosscutting concerns modeling non-functional properties(e.g. persistence, concurrency, security). Since these NF propertiesare well known at the early stages of the development, they arenormally the first candidates to be modeled as (aspectual) compo-nents. In our experience, these NF properties have many reuse pos-sibilities, appearing in most case studies as shown in the secondcolumn of Table 7. This is because the interface specification ofaspectual components modeling a NF property is always the same,since by definition it does not depend on base component inter-faces. Other aspectual components model application-specificcrosscutting behaviors, so these aspectual components have lesspossibilities of reutilization. Considering this, we calculated the re-use rate of the crosscutting concerns (CC) modeled in these casestudies and the results show that (see last row of Table 7): a highpercentage of aspectual concerns (28.9%) appear only once (nor-mally the application specific concerns), and the rest of them havedifferent reuse rates, concurrency (with 57.1%) and persistence(with 71.4%) being the most reused concerns. Secondly, we shouldalso analyze the reusability of (aspectual) connectors modeling theaspectual bindings between aspectual and base components. Sincebase components’ interfaces are part of aspectual bindings (specif-ically of pointcuts), normally it is not possible to reuse such con-nectors. The solution basically would be to defineparameterizable connectors. AO-ADL has defined what we call con-nector templates that allow parameterizable aspectual bindingsthat will increase the reusability possibilities of AO-ADL connec-tors. Describing connector templates is beyond the scope of thispaper (see [35]).

Quantitative results of some reuse predictors. In [5] it is demon-strated that coupling and cohesion metrics are the main predictorsof reusability. In [36] a set of coupling and cohesion metrics is pro-posed to compare AO and non-AO versions of the same architec-ture. Since aspect-orientation improves the separation ofconcerns (SoC), some SoC metrics are also part of this metric suite.These metrics are rigorously defined and validated by several stud-ies [37–39], providing empirical evidence of how aspect-orienta-tion improves modularity, and then reusability of softwarearchitectures.

The metric suite defined in [36] is not specific to AO-ADL,as the authors focus on aspectual components, present in any

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

Fig. 6. An example of mapping from AO-ADL to JBoss AOP.

Table 3Summary of main contributions of AO-ADL and its impact on qualities.

AO-ADL novelty Impact on qualities In other AO ADLs Limitations in other AO ADLs

Concurrent-withadvice

Traceability Not supported Not possible to express many temporal operators (e.g. during)

New join points Composability Only MESSAGE Must introduce new methods to intercept attributes, factory, etc.Aspects into

jp3:composi–tions

Reduce pointcut fragility problem;composability

Not supported Difficult or not possible to express ‘‘if component1 is connected tocomponent2, then add component3 aspectual behavior’’

Quantified roles Connector reusability; evolvability;scalability

Not supported Crosscutting of aspectual bindings through aspectual connectors

AO-ADL Tool Suite Heterogeneity; scalability; refinementand traceability; composability

Similar Limited functionality and applied to a small set of simple examples

IDE Refinement and traceability;heterogeneity

Not cover all phases ofsoftware lifecycle

Not possible to map and transform ‘‘aspects’’ at requirements toarchitecture, design and implementation


aspect-oriented proposal. Since aspectual connectors are one ofthe main contributions of AO-ADL, we extended this metricssuite to measure the concerns diffusion over AO-ADL connectors.Specifically, in this paper, we will apply an extended version ofthe metric suite [36] to the HW case study.

Firstly, we will assess how reusable base components are afterthe separation of concerns in terms of the coupling Fan-in andFan-out metrics, and in terms of the cohesion LCC (Lack of Con-cern-based Cohesion) metric. To compare the results we havemodularized the non-AO and AO version similarly, encapsulatingin both versions crosscutting concerns in separate components.We focus on seven crosscutting concerns, those depicted inFig. 1. Coupling is evaluated by counting the number of compo-nents, which require services from the assessed component (Fan-in metric) and the number of components from which the assessedcomponent requires services (Fan-out metric). Table 4 shows theresults of applying these metrics for base components. As can beseen, for the Fan-in metric, there is no improvement in the AO ver-sion, but this must be interpreted as a good result for AO-ADL,since in other AO approaches, in which pointcuts are specified in-side the same software entity in which the aspect behavior is mod-eled, this normally produces worse results. The reason is that theFan-in metric also counts the number of aspectual components(or aspects) that affect the assessed component, considering thatthe aspectual component explicitly includes information aboutthe accessed component as part of the pointcut specification. InAO-ADL this does not happen as pointcus are not included in

aspectual components. The same may be said for other AO ADLsthat also separate the pointcut specification from the specificationof the aspectual behavior.

In AO architectures, the Fan-out for base components is consid-erably lower than in non-AO architectures (33.3%), basically be-cause the component does not directly require a service fromthose components modeling crosscutting concerns (aspectual com-ponents). For instance, in a non-AO architecture, the Citizen View

component in Fig. 1 would have three additional required interfacesto interact with: the Consistency, the Error Handling and the Encryption

components. Due to the ‘dependency inversion’ promoted by AOarchitectures, in Fig. 1 these additional interfaces are not requiredand instead a dependency between the aspectual components andthe Citizen View component is specified throughout the aspectualroles of the Conn2 connector. Thus, the use of aspect-orientationchanges from dependencies with base components to dependencieswith aspectual components. Note that dependencies with aspectualcomponents is a less expensive option as these dependencies arecompletely transparent from the point of view of the base compo-nents. Moreover, in AO-ADL they are transparent also for aspectualcomponents, since the place to specify them is the connector. Thisincreases the possibilities of reusing not only base componentsbut also aspectual ones.

Therefore, as we have removed references to crosscutting con-cerns from the interfaces, base components are less coupled inAO versions, so our first hypothesis is demonstrated. Next we haveto calculate the Fan-in and Fan-out for aspectual components. The

Table 4Coupling and cohesion metrics.

Base components Fan-in Fan-out LCC

Non-AO AO Non-AO AO Non-AO AO

Citizen view 2 2 5 3 6 4Employee view 2 2 7 4 6 4Health Watcher controller 5 5 9 5 10 5Health Watcher data 4 4 6 6 5 5Average (%) 0 +33.3 +32.35


result of the Fan-in metric for aspectual components is not shownhere, since for the non-AO version the result will obviously be farworse. The reason is that in non-AO versions, aspectual compo-nents are required explicitly by base components, and in AO ver-sion they are not. Finally, the cohesion of base components isstudied by means of the LCC metric that counts the number of con-cerns addressed by the assessed component. The higher this num-ber is, the lower the cohesion is. The AO version is on average 32.35% better than its counterpart. The reason is that in the non-AO ver-sion, base components have to deal with part of the crosscuttingconcerns, which contributes to an increase in the average LCC,showing a lower cohesion than its AO counterpart, where basecomponents do not have to deal with crosscutting concerns. Inour example the cohesion of the Citizen View component is higherthan in a non-AO architecture because in our approach this compo-nent does not have to deal with consistency, error handling andencryption. Because of the lower cohesion of non-AO architectures,components are less reusable since, for instance, the componentCitizen View cannot be reused in environments where the consis-tency or the encryption crosscutting concerns are not required.

The separation of architectural concerns (SoC) metrics calculatethe degree to which a single concern maps to the architecturalcomponents. SoC is computed in terms of the Concern Diffusionover Architectural Components (CDAC), Interfaces (CDAI) andOperations (CDAO), which, given a particular concern, count thenumber of components/interfaces/operations where that concernis present. A lower diffusion means a better modularization (see

Table 5Concern diffusion metrics on components.

Concerns #Components (CDAC) #

AO Non-AO A

Authentication 2 5 3Access control 2 5 3Consistency 1 6 1Encryption 1 10 1Error handling 19 19 1Feedback 3 3 3Synchronization 1 4 1Average (%) +44.2

Table 6Concern diffusion metrics on connectors.

Concerns #Components /#attachments (CDACn) #poin

Non AO AO-noQR AO-QR Non A

Authentication 2/6 4/8 1/1 –Access control 2/6 4/8 1/1 –Consistency 1/6 5/10 1/1 –Encryption 2/12 5/15 1/1 –Error handling 1/19 1/19 1/1 –Feedback 1/2 1/2 1/1 –Synchronization 1/4 3/6 1/1 –

Table 5). The results of the SoC metrics are obtained for each con-cern of interest in the system (in our case, crosscutting concerns ofthe HW system). Considering that we are mainly talking about themodularization of crosscutting concerns, CDAC has a value of: 1 ifthe component modeling the crosscutting concern does not requireany service from other components, and 1 plus the number of aux-iliary components in the other case. In a non-AO architecture theprevious values have to be increased with the number of compo-nents that are affected by the crosscutting concern. Accordingly,the data collected for both the non-AO and AO versions showsfavorable results for the AO version (average values are: CDAC44.2%; CDAI 42.67%; CDAO 47.75% in Table 5). For instance, CDAC(consistency) is 1, while CDAC (authentication) and CDAC (access con-trol) are 2 because the Authentication and the Access Control compo-nents use the Health Watcher DataStore to do their task. In a non-AOarchitecture, each component with data that needs to be consistentwill contribute to CDAC (consistency) by increasing their values by1 (six simple components/interfaces/operations in our example).As an exception, there is no improvement in the AO version forthe Error Handling and the Feedback aspectual components. This isbecause, AO-ADL defines interfaces of type exception (used bythe Error Handling) and of type event (used by the Feedback), sowe have counted all the interfaces of these types specified in thebase component interfaces.

Then in AO software architectures all the tangled and scatteredbehavior has been eliminated from the interfaces of base compo-nents and is moved to the interfaces of aspectual componentsand to the specification of the aspectual compositions. So, to makethe results comparable, we should also consider the concern diffu-sion in the aspectual compositions. How to count this will dependon how the aspect-oriented ADL specifies the composition ofaspectual components. So, we extended these metrics by alsocounting the number of connectors/attachments/pointcuts/aspec-tual bindings affected by a given crosscutting concern, after its sep-aration as an aspectual component (see Table 6). In the non-AOversion we specify one connector per crosscutting concern, andcount the number of components attached to each connector. Inthe AO version the use of quantified roles (QR) is very relevant

interfaces (CDAI) #operations (CDAO)

O Non-AO AO Non-AO

6 3 66 3 66 1 610 2 11

9 19 19 193 3 34 4 16

+42.67 +47.75

tcuts #aspectual_bindings

O AO-noQR AO-QR Non AO AO-noQR AO-QR

3 1 – 3 13 1 – 3 15 1 – 5 110 1 – 10 21 1 – 1 11 1 – 1 16 2 – 12 4

Table 7Case studies specified in AO-ADL.

System Crosscutting concerns Size %AC

Virtual office Security (access control, authentication), configuration, awareness, coordination, persistence, broadcasting (18C + 22AC) = 40CC,43AspC

55

Pictionarygame

Security (authentication), persistence, coordination, awareness, configuration, sound, time analysis (9C + 8AC) = 17CC,26AspC

47

Collab. games Security enrollment, authentication, persistence, coordination, awareness, sound (8C + 10AC) = 18CC,25AspC

55

Auction system Security (authentication, access control), enrollment, concurrency, validation, scheduling, monitoring, transaction,response time

(8C + 9AC) = 17CC,14AspC, 6Cn

52

ATM Security (authentication, authorization, encryption), concurrency, replication, adaptability, availability, transaction,heterogeneity

(6C + 9AC) = 15CC,20AspC, 8Cn

60

Toll gate system Security (authentication, encryption), enrollment, concurrency, persistence, error handling, distribution, timeanalysis, asynchronous notification, adapter, display update, charge calculation, charge displayer

(20C + 11AC) = 31CC,25AspC, 14Cn

35

Health Watchersystem

Security (authentication, access control, encryption), enrollment, concurrency, replication, persistence, distribution,consistency, data formatting, error handling, feedback, usability (history log, contextual help, alert, undo, cancel)

(20C + 14AC) = 34CC,30AspC, 10Cn

41

Average Rr 24 CC Rr = 14.3%; 7 CC Rr = 26.6%; 4 CC Rr = 42.8%; 1 CC (concurrency) Rr = 57.1%; 1 CC (persistency) Rr = 71.4%

Legend: CC – concerns, C – base component, AC – aspectual component, AspC – aspectual compositions, Cn – connector, Rr – reuse rate.


since it strongly influences the results of the concern diffusion overconnectors. Likewise in other aspect-oriented ADLs in the versionwithout QR, the number of connectors/attachments is higher thanin the non-AO version. Let us consider the authentication concern.This concern is required by the three base components (complaint,table and employee) and requires the data store component, so inthe worst case it participates in four different connectors and twocomponents are attached in each connector (i.e. eight attach-ments). By using QRs it is possible to specify the addition ofauthentication in a separate single connector, with only oneattachment/pointcut/aspectual binding. So, AO-ADL not only re-moves crosscutting from components, but from connectors, whichother ADLs fail to achieve.

According to these metrics, AO architectures compute bettervalues than non-AO architectures when the software architect isable to encapsulate each crosscutting concern in a single compo-nent, and it is possible to remove most interaction dependenciesbetween either base or aspectual components. In general, aspect-orientation is not a panacea however. While it does provide goodresults for those concerns that can be easily separated and mod-eled inside a single and independent (aspectual) component, com-plex concerns can normally not be easily encapsulated in a singlecomponent, and it is almost impossible to avoid certain dependen-cies with other concerns in the architecture [40].

7.2. Scalability assessment of AO-ADL specifications

Scalability is a desirable characteristic of ADLs because it shouldbe possible to model both small and large-scale systems equallywell. In the first place, the scalability can be evaluated by consider-ing the facility of adding new architectural artifacts to the architec-ture. In AO-ADL, quantified roles strongly contribute to scalabilityas they make it possible to add new aspectual components to manycomponent interactions by simply adding a single connector (forexample Conn7 in Fig. 1). In this way, it is not necessary to modifythe specification of all the components and/or connectors affectedby the new aspectual property (see Table 3, fourth row). In the casethat many new artifacts need to be added to the architecture, theAO-ADL Tool Suite offers different facilities, such as: (1) definitionof interfaces in separate files, which can be referenced by any com-ponent (the uri), reducing repetitive specifications; (2) (re) use ofcomponents and connectors specifications stored in the repository;(3) addition of new artifacts by contextual menus, with defaultfields, . . . that help to specify artifacts quickly. Also, AO-ADL ex-presses architectural configurations explicitly, as it is possible to

vary the number of component types attached to a given composi-tion by simply modifying the configuration file using the menus ofthe AO-ADL Tool Suite.

Secondly, scalability is also proven by empirical evidence fromseveral case studies, both academic and industrial ones (see Table7). The virtual office application is a large case study that we devel-oped for a national project funded by a telecommunications com-pany [41]. Another collaborative service we developed in thatproject was the Pictionary game, used also as one of the case studiesof the AOSD-Europe project [42]. Additionally, different versions ofcollaborative games were developed by MSc students, providing uswith interesting feedback that helped us to improve the tool sup-port in particular. The auction system was used as the common casestudy in the AOSD-Europe project to illustrate the different propos-als [34]. The ATM system is a typical example used extensively toillustrate ADL characteristics (see [43]). Finally, the Toll GateSystem is the industrial demonstrator [44] of the AOSD-Europeproject, whose goal was to illustrate the joint use of the differenttools developed by the project partners. For each of these casestudies, Table 7 shows the list of crosscutting concerns, and thesize of the case study in terms of the number of base and aspectualcomponents, aspectual compositions and connectors. These casestudies address from 15 (small case study) to 40 (large case study)concerns, the average being 24 concerns (medium sized case stud-ies). Also the number of connectors is shown for each case study,14 connectors being the maximum and 6 connectors the mini-mum. But the number of connectors is not really a conclusive da-tum regarding scalability. This is because the number ofconnectors specified for each case study strongly depends on thecriteria used by the Software Architect. For example, in Fig. 1, theaspectual roles and binding information of Conn2 and Conn5 couldbe specified inside the same connector. The criteria used in thiscase was to separate the management of the error handling aspec-tual component, since its application does not depend on the restof Conn2’s aspectual components (i.e. authentication, consistencyand synchronization), so it is clearer and more manageable to havethe Conn5 connector encapsulating only the error handlingbindings.

7.3. Quality assessment of AO-ADL specifications

The quality of AO-ADL specifications is analyzed in this sectionin terms of the last six qualities previously mentioned.

Refinement and traceability. ADLs must enable correct andconsistent refinement of architectures into executable systems.


Firstly, AO-ADL facilitates the refinement of software architecturesdue to its explicit support to achieve separation of concerns. Spe-cifically, it enforces that the main functional concerns (e.g. HWModel, Citizen View and Employee View) must be specified first,specifying in a second step other properties that crosscut the mainfunctional components (e.g. authentication, error handling, etc.)and that will be easily added or deleted according to the final sys-tem requirements. This can be an iterative process until all the(crosscutting) properties of the system are addressed by the archi-tecture. Secondly, regarding the traceability from requirementsand to design/implementation, AO-ADL proposes several improve-ments. Although not shown in this paper due to the lack of space,there is a mapping from AO requirements to AO-ADL described in[11], where the novel concurrent-with advice makes it possible toexpress a richer set of temporal operators defined in the require-ments, enhancing the traceability of ‘‘aspects’’ defined in require-ments to architecture (see Table 3, first row). Finally, AO-ADLallows the refinement of each architectural artifact by means ofits mapping and transformation into design elements specified inTheme/UML and UML 2.0 [33], or directly into executable classesin AOP JBoss. So, AO-ADL is integrated with other aspect-orientedapproaches and thus, although the step from requirements toarchitecture is not completely automated yet, it would be possibleto trace aspects from requirements to implementation, preservingthe advantages of identifying aspects in the early stages of the soft-ware development cycle (i.e. improved modularization, increasedreusability, etc.). It is then possible to trace if an ‘‘aspect’’ identifiedat the requirements level, is also an aspect at the architecture level,or if new ‘‘aspects’’ appear at the architectural level, or how anarchitectural aspect is mapped to design or implementation (seeTable 3, tow last rows).

Heterogeneity. One of the goals of ADLs is to facilitate thespecification of large scale architectures by using preexisting com-ponents and connectors of varying granularity. The AO-ADL ToolSuite offers a repository that fulfills this quality, offering compo-nents and connectors with different granularity (i.e. compositecomponents, simple components and connectors with many orfew bindings). Also, the AO-ADL Tool Suite generates code forAOP JBoss. Moreover, using the automatic generation from AO-ADL to Theme/UML, it is also possible to generate AspectJ and Cae-sarJ implementations. Then, three different implementation lan-guages are supported, although the support to generate two ofthem is provided by third parties (see Table 3, two last rows).

Evolvability. This is the ability to accommodate new architec-tural artifacts or to modify existing ones, without excessive effortfrom the developer. This criterion is important because change isan ever present factor in development, and if not supported, thestructure of the artifacts may degrade, making them difficult touse and to maintain. First of all, if the behavior added is crosscut-ting then an aspect-oriented ADL avoids the modification of theinterfaces of components affected by the new behavior. Specifi-cally, in AO-ADL, adding a new crosscutting functionality meansadding a new component modeling the new functionality and alsoadding new aspectual bindings to connect this aspectual compo-nent to the system. In AO-ADL there are two possibilities to addnew aspectual bindings: (1) to modify connector specificationsby adding the new binding; (2) to add a new connector with thenew binding. In the first case, connectors with too many bindingswill be difficult to understand (the worst case would be an archi-tecture with a single connector, as in DAOP-ADL). With the secondapproach, the architecture will have many connectors, but eachconnector will be simpler and easier to understand. AO-ADL helpsin this decision for aspectual components. In this case since aspec-tual components model properties that crosscut several compo-nent interactions, which may be specified in different connectors,the recommendation is to add a new connector using quantified

roles. As we stated above, using quantified roles prevents the prob-lem of ‘‘crosscutting roles’’ in connectors (present in other ADLs)making connectors more evolvable (see Table 3, fourth row). Forexample, Conn7 in Fig. 1 ensures that all the communications be-tween base components will be accomplished in a secure way,even for those components that have not yet been added to thearchitecture. It should be noted however that in this case the archi-tecture would suffer a similar problem to that of pointcut fragilityproblem stated above, typical of quantifications in AO languages(reduced in AO-ADL by connectors and the jp3:compositions, see Ta-ble 3, third row). So in AO-ADL using too general universal quanti-fiers in the source and target roles of connectors may lead to therole fragility problem. In particular, if new components are con-nected to the system architecture, then they would be automati-cally linked to connectors with source/target quantified roles ashappens with Conn7. So the software architect must find a com-promise between specifying highly evolvable connectors and min-imizing the possible emergence of the role fragility problem.Nevertheless, in the query of the AO-ADL quantified roles it ispossible to put very specific restrictions on the components inter-faces. Therefore, we recommend that the roles be as specific aspossible and also that the use of quantifiers such as ‘‘for allcomponents’’ should be avoided unless specifically specified bythe requirements.

Non functional properties. These properties are particularly wellsupported by AO-ADL. The list of properties documented as non-functional (NF) is very large. However, only a subset of this listhas strong functional implications and so can be easily modeledby components (like security, awareness, error handling, etc.). Inthe literature there is enough evidence showing that these kindsof NF properties are normally crosscutting, and are good candi-dates to be modeled with aspects. So, in AO-ADL these kinds ofNF properties can be mapped to (aspectual) components andadded to the architecture by means of aspectual bindings [33].Other non-functional properties like efficiency, price, portability,etc., could be mapped to architectural or implementation deci-sions, and not directly to (aspectual) components. Coming backto Table 7, the last column shows the percentage of concerns mod-eled as aspectual components. Given that the first five case studieswere not chosen on purpose to have a large number of crosscuttingconcerns and that the last two ones were proposed by the aspect-oriented community, an average result of 49% reveals that a largenumber of concerns are crosscutting in real case studies. So, thisresult strongly supports the use of aspect-oriented ADLs, like AO-ADL, in order to improve the modularisation of the architecture.

Composability. Composability is the ability to compose artifactsand consequently to view and understand the complete set of arti-facts and their interrelationships, as well as to perceive the systemas a whole from the associated artifacts. AO-ADL defines compositecomponents that can contain both components and connectors,defining a partial architecture. So, a complete system may be com-posed of a set of coarse-grained composite components by meansof connectors. This means that it is possible to understand thewhole architecture by exploring different levels of detail, zoominginto composite components at different levels of granularity. Also,AO-ADL gives the option of composing aspectual components notonly with a given component, but also with a given compositionbetween components, enriching composability at the architecturallevel where interactions between components are so important(see Table 3, third row). Also, since AO-ADL connectors containinformation about the bindings between components, the naturalway of studying architecture composition is to analyze each con-nector binding, both aspectual and non-aspectual ones. In contrast,it is not easy to see how a given component is connected to (or af-fects) the rest of the system components, especially when connec-tors use quantified roles. Quantified roles, then, are not so good if


the Software Architect wants to know, by observing a connectorcontaining quantified roles, the list of aspectual components thatare affecting a given component or a given component interaction.To mitigate this shortcoming, the AO-ADL Tool Suite defines some-thing similar to a ‘‘weaving process’’ at the architectural level. Thisprocess propagates the aspectual bindings defined by quantifiedroles to the corresponding connectors in which the affected com-ponents are defined. Afterwards, it is possible to generate a UMLdescription for such connectors to visualize all the kinds of bind-ings for a specific set of components. In the case studies of Table7, the average number of bindings per aspectual connector is 2.4,revealing that in practice, connectors are simple, with not toomany bindings/compositions.

Tool support. AO-ADL provides tools to aid the tedious specifica-tion task of the architecture using a new language, and also forboth design and/or implementation derivation, it being possibleto obtain an initial version of the executable system, by simplypressing one button. This issue was already addressed in a previoussection.

8. Conclusions and future work

In this paper we have presented the main features of the AO-ADL language, illustrating them through the specification of theAO software architecture of the Health Watcher case study. Wehave demonstrated that AO-ADL distinctive features have a posi-tive impact on eight qualities, including reusability. By empiricaland quantitative studies we showed that AO-ADL architecturaldescriptions are more cohesive, less coupled and with an improvedseparation of concerns in both components and connectors. Thismeans that the evolution and maintenance are greatly improvedas we promised in the introduction.

However, we are aware of the reluctance of some developers tofirst specify the architecture and then derive the detailed designand implementation. If we add the complexity of learning AO con-cepts, we could put off software architects from using our ap-proach. In order to cope with this shortcoming, we offer the toolsthat may facilitate the specification process. In addition, by offeringthe possibility of generating a UML model, we facilitate the adop-tion by industry, as it is easier to integrate AO-ADL as a previousphase of the detailed design definition in UML. However, someknowledge about aspectual bindings is still required by the soft-ware architect. For experts in AO, the AO-ADL Tool suite has beenwell appreciated as in [45] where AO-ADL was used to specify thearchitecture of a digital publishing application, and authors say‘‘AO-ADL delivers an architecture in which the various discovered as-pects are easily traceable throughout the later stages of design andimplementation. Productivity is also increased because the AO-ADLnotation is formal enough to generate the design and implementationof AO connectors automatically’’.

As part of our ongoing work, we are extending AO-ADL to sup-port variability. This feature will allow the use of AO-ADL to specifysoftware product lines. This will be achieved by combining AO-ADLwith tools for software product lines that are already available inour research group. This new feature will particularly improvethe instantiation of AO-ADL templates, which will be driven bythe variability information provided by the software product linetools. We are also planning to report on a study that we are carry-ing out on the use of the AO-ADL tools by users who are not expertsin AO (mainly MSc and PhD students).

Acknowledgment

This research was funded by the Spanish Project TIN2008-01942 and by the regional project FamWare P09-TIC-5231.

References

[1] G. Booch, On creating a handbook of software architecture, in: Companion tothe 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming,Systems, Languages, and Applications, OOPSLA ’05, ACM, New York, NY, USA,2005. pp. 8–8.

[2] D. Garlan, Software architecture, in: J. Marciniak (Ed.), Encyclopedia ofSoftware Engineering, John Wiley & Sons, 2001.

[3] N. Medvidovic, R.N. Taylor, A classification and comparison framework forsoftware architecture description languages, IEEE Transactions on SoftwareEngineering 26 (2000) 70–93.

[4] N. Medvidovic, E.M. Dashofy, R.N. Taylor, Moving architectural descriptionfrom under the technology lamppost, Information and Software Technology 49(2007) 12–31.

[5] G. Gui, P. Scott, Measuring software component reusability by coupling andcohesion metrics, Journal of Computers 4 (2009) 797–805.

[6] A. Molesini, A. Garcia, C. von Flach, G. Chavez, T. Batista, On the quantitativeanalysis of architecture stability in aspectual decompositions, in: IEEEComputer Society (Ed.), Working IEEE/IFIP Conference on SoftwareArchitecture (WICSA), 2008. pp. 29–38.

[7] G. Kiczales et al., Aspect-oriented programming, in: Proceedings of the Euro-pean Conference on Object-Oriented Programming (ECOOP’97), Lecture Notesin Computer Science, vol. 1241, Springer-Verlag, Finland, 1997, pp. 220–242.

[8] B. Tekinerdogan, A. Moreira, J. Araujo, P. Clements (Eds.), Early Aspects:Aspect-Oriented Requirements Engineering and Architecture Design, 2004.<Http://trese.cs.utwente.nl/workshops/early-aspects-2004/>.

[9] C. Chavez, A. Garcia, T. Batista, M. Oliveira, C. Sant’Anna, A. Rashid, Composingarchitectural aspects based on style semantics, in: AOSD ’09: Proceedings ofthe 8th ACM International Conference on Aspect-Oriented SoftwareDevelopment, ACM, New York, NY, USA, 2009, pp. 111–122.

[10] D. SuvTe, B. De Fraine, W. Vanderperren, A symmetric and unified approachtowards combining aspect-oriented and component-based softwaredevelopment, in: I. Gorton, G. Heineman, I. Crnkovic, H. Schmidt, J. Stafford,C. Szyperski, K. Wallnau (Eds.), Component-Based Software Engineering ofseries Lecture Notes in Computer Science, vol. 4063, Springer, Berlin/Heidelberg, 2006, pp. 114–122.

[11] R. Chitchyan, M. Pinto, A. Rashid, L. Fuentes, Compass: composition-centricmapping of aspectual requirements to architecture, in: A. Rashid, M. Aksit(Eds.), Transactions on Aspect-Oriented Software Development IV of seriesLecture Notes in Computer Science, vol. 4640, Springer, Berlin/Heidelberg,2007, pp. 3–53.

[12] W. Harrison, H. Ossher, P. Tarr, Asymmetrically vs. symmetrically organizedparadigms for software composition, Technical Report, IBM Research Division,Thomas J. Watson Research Center, 2002.

[13] R. Chitchyan et al., Report synthesizing state-of-the-art in aspect-orientedrequirements engineering, architectures and design, Technical Report AOSD-Europe Deliverable D11, AOSD-Europe-ULANC-9, 2005.

[14] M. Pinto, L. Fuentes, J.M. Troya, DAOP-ADL: an architecture descriptionlanguage for dynamic component and aspect-based development, in:Proceedings of the 2nd International Conference on Generative Programmingand Component Engineering, GPCE ’03, Springer-Verlag New York, Inc., NewYork, NY, USA, 2003, pp. 118–137.

[15] T. Batista, C. Chavez, A. Garcia, A. Rashid, C. Sant’Anna, U. Kulesza, F.C. Filho,Reflections on architectural connection: seven issues on aspects and ADLs, in:Proceedings of the 2006 International Workshop on Early Aspects at ICSE, EA’06, ACM, New York, NY, USA, 2006, pp. 3–10.

[16] L. Fuentes, M. Pinto, J.M. Troya, Supporting the development of CAM-DAOPapplications: an integrated development process, Software Practice &Experience 37 (2007) 21–64.

[17] N. Pessemier, L. Seinturier, T. Coupaye, L. Duchien, A model for developingcomponent-based and aspect-oriented systems, in: W. Lwe, M. Sndholt (Eds.),Software Composition of Lecture Notes in Computer Science, vol. 4089,Springer, Berlin/Heidelberg, 2006, pp. 259–274.

[18] J. Pérez, N. Ali, J.A. Carsı, I. Ramos, B. Álvarez, P. Sanchez, J.A. Pastor, Integratingaspects in software architectures: PRISMA applied to robotic tele-operatedsystems, Information and Software Technology 50 (2008) 969–990.

[19] N. Ali, I. Ramos, C. Solís, Ambient-PRISMA: Ambients in mobile aspect-orientedsoftware architecture, Journal of Systems and Software 83 (2010) 937–958.

[20] A. Garcia, C. Chavez, T. Batista, C. Santanna, U. Kulesza, A. Rashid, C. Lucena, Onthe modular representation of architectural aspects, in: V. Gruhn, F. Oquendo(Eds.), Software Architecture of Lecture Notes in Computer Science, vol. 4344,Springer, Berlin/Heidelberg, 2006, pp. 82–97.

[21] A. Navasa, M.A. Pérez-Toledano, J.M. Murillo, An ADL dealing with aspects atsoftware architecture stage, Information and Software Technology 51 (2009)306–324.

[22] P. Sánchez, A. Moreira, L. Fuentes, J. Arajo, J. Magno, Model-drivendevelopment for early aspects, Information and Software Technology 52(2010) 249–273.

[23] F. Montoro, E. Navarro, ATRIUM: software architecture driven byrequirements, in: IEEE International Conference on Engineering of ComplexComputer Systems, 2009, pp. 230–239.

[24] S. Soares, E. Laureano, P. Borba, Implementing distribution and persistenceaspects with AspectJ, Proceedings of the 17th ACM SIGPLAN Conference onObject-Oriented Programming, Systems, Languages, and Applications, OOPSLA’02, ACM, New York, NY, USA, 2002, pp. 174–190.

http://Http://trese.cs.utwente.nl/workshops/early-aspects-2004/


[25] P. Greenwood et al., On the contributions of an end-to-end AOSD testbed, in:Proceedings of the Early Aspects at ICSE: Workshops in Aspect-OrientedRequirements Engineering and Architecture Design, EarlyAspects’07, IEEEComputer Society, Washington, DC, USA, 2007, p. 8.

[26] P. Sánchez, L. Fuentes, A. Jackson, S. Clarke, Aspects at the right time, in: A.Rashid, M. Aksit (Eds.), Transactions on Aspect-Oriented SoftwareDevelopment IV of Lecture Notes in Computer Science, vol. 4640, Springer,Berlin/Heidelberg, 2007, pp. 54–113.

[27] A. Jackson, N. Casey, S. Clarke, Mapping Design to Implementation,Technical Report AOSD-Europe Deliverable D111, AOSD-Europe-TCD-D111,2008.

[28] C. Canal, L. Fuentes, E. Pimentel, J.M. Troya, Adding roles to corba objects, IEEETransactions on Software Engineering 29 (2003) 242–260.

[29] C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall, 1984.[30] C.V. Lopes, D: a language framework for distributed programming, PhD,

1997.[31] C. Koppen, M. Stoerzer, PCDIFF: attacking the fragile pointcut problem,

in: First European Interactive Workshop on aspects in software (EIWAS),pp. 1–8.

[32] N. Weston, R. Chitchyan, A. Rashid, A formal approach to semanticcomposition of aspect-oriented requirements, in: RE ’08: Proceedings of the2008 16th IEEE International Requirements Engineering Conference, IEEEComputer Society, 2008, pp. 173–182.

[33] M. Pinto, L. Fuentes, L. Fernández, J.A. Valenzuela, Using AOSD and MDD toenhance the architectural design phase, in: International Workshop onSystem/Software Architecture (IWSSA09), LNCS, vol. 5872, Springer-Verlag,2009, pp. 360–369.

[34] R. Chitchyan, A. Rashid, A. Garcia, M. Pinto, P. Sanchez, L. Fuentes, A. Jackson,Mapping and refinement of requirements level aspects, AOSD-Europe NoEPublic Documents (AOSD-Europe-ULANC-24) (2006).

[35] L. Fuentes, N. Gámez, M. Pinto, J. Valenzuela, Using connectors to modelcrosscutting influences in software architectures, in: F. Oquendo (Ed.),Software Architecture of Lecture Notes in Computer Science, vol. 4758,Springer, Berlin/Heidelberg, 2007, pp. 292–295.

[36] C. SantAnna, E. Figueiredo, A. Garcia, C. Lucena, On the modularity of softwarearchitectures: a concern-driven measurement framework, in: F. Oquendo(Ed.), Software Architecture of Lecture Notes in Computer Science, vol. 4758,Springer, Berlin/Heidelberg, 2007, pp. 207–224.

[37] E. Figueiredo et al., On the maintainability of aspect-oriented software: aconcern-oriented measurement framework, in: Proceedings of the 2008 12thEuropean Conference on Software Maintenance and Reengineering, IEEEComputer Society, Washington, DC, USA, 2008, pp. 183–192.

[38] P. Greenwood et al., On the impact of aspectual decompositions on designstability: an empirical study, in: E. Ernst (Ed.), ECOOP 2007 Object-OrientedProgramming of Lecture Notes in Computer Science, vol. 4609, Springer,Berlin/Heidelberg, 2007, pp. 176–200.

[39] C. Lopes, S. Bajracharya, Assessing aspect modularizations using designstructure matrix and net option value, in: A. Rashid, M. Aksit (Eds.),Transactions on Aspect-Oriented Software Development I of Lecture Notes inComputer Science, vol. 3880, Springer, Berlin/Heidelberg, 2006, pp. 1–35.

[40] J. Kienzle, S. Gélineau, AO challenge – implementing the ACID properties fortransactional objects, in: Proceedings of the 5th International Conference onAspect-Oriented Software Development, AOSD ’06, ACM, New York, NY, USA,2006, pp. 202–213.

[41] M. Pinto, M. Amor, L. Fuentes, J. Troya, Collaborative virtual environmentdevelopment: an aspect-oriented approach, in: International Conference onDistributed Computing Systems Workshops, 2001, pp. 97–102.

[42] C. Sant’Anna et al., General architecture evaluation process/metrics, TechnicalReport AOSD-Europe Deliverable D85, AOSD-Europe-UT-D85, 2008.

[43] M. Pinto, L. Fuentes, AO-ADL: an ADL for describing aspect-orientedarchitectures, in: A. Moreira, J. Grundy (Eds.), Early Aspects: CurrentChallenges and Future Directions of Lecture Notes in Computer Science, vol.4765, Springer, Berlin/Heidelberg, 2007, pp. 94–114.

[44] M. Pinto et al., Report on case study results, Technical Report AOSD-EuropeDeliverable D118, AOSD-Europe-Siemens-11, 2008.

[45] D.V. Landuyt et al., Building a next-generation digital publishing platformusing AOSD, 2008. <Http://gateway.comp.lancs.ac.uk/computing/aosd-europe//DigitalPublishing/Application/whitepaper.pdf>.

http://Http://gateway.comp.lancs.ac.uk/computing/aosd-europe//DigitalPublishing/Application/whitepaper.pdf

http://Http://gateway.comp.lancs.ac.uk/computing/aosd-europe//DigitalPublishing/Application/whitepaper.pdf