Generating CAM aspect-oriented architectures using Model-Driven Development

Available online at www.sciencedirect.com

Information and Software Technology 50 (2008) 1248–1265 www.elsevier.com/locate/infsof

Generating CAM aspect-oriented architectures using Model-Driven Development q Lidia Fuentes, Mo´nica Pinto *, Pablo Sa´nchez Dpto. Lenguajes y Ciencias de la Computacio´n, ETSI Informa´tica, Universidad de Ma´laga, Boulevard Louis Pasteur S/N, Campus de Teatinos, CP E29071, Ma´laga, Spain Received 5 December 2006; received in revised form 23 July 2007; accepted 15 October 2007 Available online 23 December 2007

Abstract Aspect-Oriented Software Development promotes the separation of those concerns that cut across several components and/or are tangled with the base functionality of a component, through all phases of the software lifecycle. The benefit of identifying these crosscutting concerns (aspects) at the architectural level in particular is to improve the architecture design and its subsequent evolution, before moving onto detailed design and implementation. However, software architects are not usually experts on using specific AO architecture notations. Therefore, the aim of this paper is to provide support to define and specify aspect-oriented (AO) architectures using non-AO ones as the source. We will use the Model-Driven Development approach to transform a component-based architecture model into an AO architecture model. The CAM (component and aspect model) model and the DAOP–ADL language are the proposals used for modelling and specifying AO architectures. We will show how we automated part of the process and the tool support. Ó 2008 Elsevier B.V. All rights reserved. Keywords: Aspect-orientation; Software architectures; Model-Driven Development; Component-based systems

1. Introduction Component-based software development (CBSD) promotes the building of large software systems by integrating previously existing software components, in order to reduce software development costs, time to market and maintenance efforts. A software component is defined as ‘‘a unit of composition with contractually specified interfaces and explicit context dependencies only” [1]. However, there are some concerns, named crosscutting concerns, that do not fit in well with component-based decompositions. Examples of crosscutting concerns are

q

This work has been supported by the Spanish MCYT Project TIN2005-09405-C02-01, the European Commission Grant IST-2-004349NOE AOSD-Europe and the European STREP Project AMPLE IST33710. * Corresponding author. Tel.: +34 952132796; fax: +34 952131397. E-mail addresses: lff@lcc.uma.es (L. Fuentes), [email protected] (M. Pinto), [email protected] (P. Sa´nchez). 0950-5849/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2007.10.020

persistence, authentication, encryption, etc. These concerns cannot be adequately modularised using component-based [1] decomposition techniques (or other traditional techniques, such as object-orientation [2]) and they appear scattered over several components, and tangled with the inherent functionality of a component, making system development, maintenance and evolution more complex. The main drawback of scattered and tangled code is the difficulty of locating the code related to a particular concern, and modifying it coherently, especially without breaking it. Aspect-Oriented Software Development (AOSD) [3] is an emerging technology which improves the separation of concerns, by encapsulating crosscutting concerns in special modules, called aspects. By extracting crosscutting concerns from components, AOSD helps to improve their independence, reusability, evolution and maintenance. Also, aspects in a component-based environment become reusable parts, which can be composed and then attached to the individual components [4] (weaving process in AOSD

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

terminology). Several studies that combine CBSD and AOSD technologies are now well known [4–6], their main contribution being that the weaving information is defined completely outside either components or aspects. Focusing on the architectural level, the definition of a component-based and aspect-oriented software architecture will include a phase for aspect identification as part of the development process. The benefits and motivation of identifying aspects at the architectural level (called early aspects) can be found in [7]. Then, using the information about the aspects identified, the software architect has to specify the component and aspect architecture using an AO architecture notation. Several AO architecture notations exist that incorporate AOSD concepts [8], but much more must be done in this direction since no common agreement on how to specify aspects at architectural level exists [9]. This means that the software architect needs to deal with aspect identification and the special characteristics of an AO architecture notation, before being able to define an AO architecture by him/herself. Regarding aspect identification, software architects are able to identify crosscutting and tangled functionality without having to be a specialist in aspect terminology. On the other hand, software architects are usually not experts in using an AO architecture notation. In consequence, a process that generates an AO architecture from a non-AO one would be a more desirable solution. The aim of our approach then is to provide support to the definition and specification of AO architectures derived from non-AO ones. This approach implies that the original component-based architecture has to be transformed into an AO one, which is not a trivial task. In particular, this paper shows a process to automatically generate AO architectures for the CAM/DAOP (Component-Aspect Model/ Dynamic Aspect-Oriented Platform) approach from nonAO architectural models, using Model-Driven Development (MDD) [10,11]. CAM/DAOP [4] is an aspect-oriented and component-based approach, that provides: (1) an AO component model, CAM; (2) an XML-based architecture description language (ADL) that promotes the separation of components and aspects (DAOP–ADL); and (3) a dynamic AO component platform (DAOP), which uses the information specified in DAOP–ADL to compose the components and the aspects at runtime. A UML 2.0 Architectural Model, describing only the non-crosscutting requirements of the system, is taken as input of the process. This model is marked (in an MDD sense) to indicate where and how crosscutting concerns have to be applied. This marking phase does not require any knowledge about aspects, so it can be performed even by non-AO software architects. We will show in detail how the marked model is transformed automatically into a CAM model. Then, the CAM model is automatically transformed into DAOP–ADL, where the system architecture is specified in terms of components, aspects and evaluation rules. An Auction System case study, taken from the

1249

literature [12], is used throughout the paper to validate this process. Specifically, the contributions of this paper are:  Using MDD, software architects can obtain AO software architectures automatically from non-AO architectures expressed in UML 2.0. This process can also be applied by non-AO experts.  Since we automated the step of transforming a UML model marked with aspects to a DAOP–ADL specification, the software architect only works at the UML 2.0 level. Therefore, there is no need to learn a new AO architecture language or approach.  Our primary aim is to define a transformation process supported by non-proprietary tools, so we will use standard notations and languages as much as possible. Thus, it will be possible for similar proposals to make use of this work.  Since DAOP–ADL specifications are XML files, they can be directly interpreted by DAOP, a middleware platform which bridges the gap between architecture and implementation [4].  Once the AO architecture is described in DAOP–ADL, other possibilities can be explored, such as aspects traceability from requirements [13] to detailed design [14] or the generation of code for implementation. After this introduction, the paper is structured as follows: Section 2 outlines some related work and technologies. Section 3 explains how our proposed process works. Section 4 describes the Auction System Case Study and the UML 2.0 Architectural Model. Section 5 shows how the previous model is marked and then automatically transformed into a CAM model. Section 6 illustrates how CAM models are transformed into a DAOP–ADL description. Section 7 comments on the tool support and the expected benefits and usage of our approach. Section 8 outlines some conclusions and future work. 2. Related work 2.1. Model-Driven Development Model-Driven Development (MDD) [10,11] is an approach to software development where models are used not only for illustrative purposes, but rather they play a key role in software construction. Using MDD, a software system is created through the definition of different models at different abstraction layers, where models of a certain abstraction layer are automatically derived from models of the upper abstraction layer by means of model transformations. This facilitates the separation of target model details from the input model, i.e., target models are more refined versions of source models. These refinements continue until a complete implementation of the system is obtained.

1250

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Conforms To

Target MetaModel

Automatic Model Transformation

Source MetaModel

Conforms To

and differences between MDA and Software Factories can refer to the work of Demir [23]. MDA and SF propose a set of languages, tools and technologies for specifying metamodels, model transformations and other issues related to MDD. They also define a methodology for adopting MDD practices in the software development lifecycle. In this paper, we have opted for using the set of standards proposed by MDA, as they are publicly available, and they do not impose the use of any proprietary tool. 2.2. AO software architectures

Source Model

Target Model

Fig. 1. Scenario of a model transformation.

Fig. 1 shows the different elements required when performing a model transformation. The first elements that we need are a source model (e.g., a component model described in UML [15]) and a target model (e.g., a refined UML model that includes platform specific issues), which will initially be empty. Elements of the target model are automatically constructed from the elements of the input model. In order to make a model transformation feasible, both the input and the output model must have been precisely constructed in order to allow computers to process them, i.e., both models must conform to a metamodel, which specifies their precise abstract syntax [16]. These metamodels are constructed using a metamodelling language (e.g., MOF [17]). Additionally, these models need to be stored in a standard and interoperable format that the different model-driven tools can manipulate. XMI [18] is an example of such a standard format. XMI allows the serialisation of models conforming to a MOF metamodel in an XML document. Finally, a model transformation specifies the rules for generating automatically the corresponding output model from an input model. These transformations are specified using a model transformation language, such as QVT [17] or ATL [19]. Sometimes, such transformations may need some additional information that is not contained in the input models. For instance, when several candidate transformations exist for the same input element, the transformation could require knowing which specific transformation should be executed. This extra information is provided by means of marks, defined as ‘‘lightweight, non-intrusive extensions to models that capture information required for model transformation without polluting those models” [20]. In this case, as marking a model is a manual process, the transformation process is said to be semiautomatic. Currently, there are several specific approaches that follow the MDD paradigm, where Model-Driven Architecture (MDA) [20,21] and Software Factories (SF) [22] are worth a special mention. Readers interested in similarities

Aspect-Oriented Software Development (AOSD) aims to improve the separation and modular representation of crosscutting concerns throughout all the phases of the software development [8,24–27]. In particular, during the last few years, AOSD has significantly been concerned about the separation, representation and composition of crosscutting concerns at the software architecture level, as well as more generic AO software architecture approaches [28,29]. As a result, several aspect-oriented (AO) architecture description languages (ADLs), have been defined [9,30–34]. These languages have to deal with two main issues: (1) the architectural blocks used to model crosscutting concerns, and (2) the composition between the architectural blocks modelling crosscutting and non-crosscutting concerns. With respect to the first issue, there is not a consensus between existing AO architectural approaches [8,35]. While some of them add a new building block named aspect to model crosscutting concerns, others represent aspects as components with a different semantics, or as components that provide or require special ‘‘crosscutting” interfaces. In this sense, DAOP–ADL [31,36] (part of CAM/DAOP) and Fractal [30,37] extend traditional components with a new kind of aspectual interfaces. However, other approaches such as AO-ADL [34], AspectualACME [9] and Navasa’s language [33] use the same building block (e.g., the component) to represent both non-crosscutting and crosscutting concerns. Finally, in PRISMA [32] aspects are a new abstraction used to define the internal structure of both components and connectors. For a more extensive comparison of these proposals see [8,35]. With respect to the second issue, though there are differences in existing aspect-oriented ADLs, most of them agree that the semantics of the composition has to be somehow extended to incorporate aspects to an ADL. For instance, in DAOP–ADL, connections are defined outside both components and connectors, in a specific XML-based composition section. A similar approach is followed by Fractal, an XML-based ADL which contains an aspect binding section to describe component and aspect compositions. A different approach is followed by AO-ADL and AspectualACME, where the information on the composition between components and aspects is encapsulated inside connectors by extending their traditional semantics. Finally, in [33] the semantic of connectors is not modified

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

since in addition to the components modelling aspects, a new kind of component with the role of ‘‘coordinators” has to be included in order to describe an aspect-oriented software architecture. PRISMA [32] also follows a different approach, since aspects are part of both the components and connectors specification, and therefore the composition specification is specified inside both components and connectors. Once again, an interesting analysis and comparison of this issue has been performed in [8,35]. 2.3. MDD and AOSD This section focuses on those proposals that combine the use of AOSD and MDD. AOSD and MDD can be considered complementary technologies. As clearly stated in [38–40], the main motivation for applying AOSD to MDD is to solve the problem that MDD presents regarding the lack of specific mechanisms for the separation of crosscutting concerns within each level of abstraction. If all concerns can be modelled separately at a certain level, that level will become more manageable, extensible and maintainable. In addition, each one of those models will be smaller, more concise, reusable and easier to modify [39]. Most approaches combining MDD and AOSD follow this approach. For instance, in [39] their main goal is to obtain ‘‘separation of aspects” in each MDA level. Another similar approach is presented in [41], where authors propose a strategy for obtaining the advantages of AOSD in model-driven and component-based frameworks. Using architecture stratification they identify and relate different architectural views to represent crosscutting concerns. These architectural views are the basis for their MDD approach. An alternative approach, closer to ours, consists of applying the MDD philosophy to the development of aspect-oriented applications, by proposing MDD generation processes to transform AO models at different phases of the software lifecycle. An example of this approach is our work in [42], in which MDA helped us to identify that there were different models in our aspect-component proposal [4]. Another example is the AOMDF (Aspect-Oriented Model-Driven Framework) proposal [43]. AOMDF combines both approaches, proposing an MDD framework that provides mechanisms supporting both vertical and horizontal separation of concerns. Vertical separation of concerns is supported by providing techniques for transforming the models from one abstraction level to another. Horizontal separation of concerns is achieved by modelling crosscutting concerns separately as aspects. One important difference of these proposals from our approach is that, in most of them, it is assumed that the developer has already defined an aspect-oriented model for the first level of the MDD stack [39,43], which is not a trivial task. Therefore, they do not provide support for the identification and separation of crosscutting concerns.

1251

Instead, they define horizontal compositions and/or vertical transformations of existing aspect-oriented models. Our approach, on the other hand, supports the software architect to derive an AO architecture from non-AO ones. Another difference is that many of these proposals focus on models that provide a detailed specification of low level design of both the core functionality and the aspects [43]. This means that the definition and implementation of complex model composition and transformation mechanisms is required. Unlike this approach, our proposal focuses mainly on the architectural level, i.e., models represent a high-level design of both components and aspects, defining more generic transformation processes. Also, even when these approaches apply AOSD to particular levels of MDD, the ultimate goal of many of them is to combine the resulting models horizontally into a composed model [43], defining specific model composition operators [44]. From an aspect-oriented perspective, the main shortcoming of these approaches is that the separation of concerns is lost in the latter levels of the MDD stack. In our approach, the goal is to maintain the separation of concerns throughout all the models of our development process, describing the software architecture of applications that will finally be implemented using an aspect-oriented language or middleware platform. Finally, many current MDD approaches still lack automatic transformation processes [39]. In this paper, we demonstrate how our approach has been implemented using MDD transformation tools and how we extend these MDD-based tools with a complete tool-set that supports the specification, visualisation and validation of AO software architectures. 3. MDD–AOSA generation process In this section, we will define a Model-Driven Development process for deriving an aspect-oriented software architecture (MDD–AOSA) particularised for CAM/ DAOP [4]. MDD–AOSA is an MDD generation process whose primary aim is to assist software developers in deriving AO software architectures (in CAM/DAOP–ADL) from more traditional component-based ones, expressed in UML 2.0. Aspect-Oriented Software Development [3] aims to solve the shortcomings regarding scattered and tangled representations of crosscutting concerns, as was commented in Section 1. Using aspect-orientation the crosscutting concern logic is encapsulated in an aspect. These aspects can be considered as functional units with welldefined interfaces, i.e., a special kind of component. The execution points at which aspects can be applied are called join points. Each approach defines its own set of join points (e.g., component instantiation, method invocation, etc.). The set of join points where an aspect will be executed is usually denoted by an expression called pointcut or in our approach, composition rules. Composition rules evaluate a certain set of join points along with some constraints.

1252

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

The hypothesis of the MDD–AOSA process is that software architects do not really need to manage aspect terminology to deal properly with crosscutting concerns. He/she can produce an architectural model, which considers only non-crosscutting concerns, in a traditional notation, such as UML 2.0. Then, this model is annotated in order to indicate where and how crosscutting concerns must be addressed. These annotations, marks in model-driven terminology, do not contain any reference to aspect-oriented terminology, rather they are based on terms of the domain of the crosscutting concern they represent, which should be familiar to the software architect. Using model transformations, this annotated model can be transformed into an aspect-oriented model. The transformation introduces into the architecture: (1) the logic of crosscutting concerns by means of aspectual components with well-defined interfaces (the result is the same for all applications of the transformation); (2) the composition rules that link the aspects with the base architecture. They are created specifically for the application using the information provided by the annotations. This idea is independent of the non-AO architectural notation and the AO architectural notation selected as source and target models, respectively. However, in this paper, it is particularised for UML 2.0 as source model and CAM/DAOP–ADL as an AO target model. Following the MDD principles, MDD–AOSA consists of a collection of models and transformations, which, as shown in Fig. 2, are based on standard technologies, such as UML 2.0 [15], XMI [18] or QVT [45]. Using widely accepted and used standards, more tool support can be obtained (especially free open source tools) and it is not necessary to learn new languages and notations. The mod-

Base Architectural Model

RE processes

(UML 2.0)

Marking Marking Process Process

Marks

Marked Base Architectural Model (UML 2.0) XMI export

Prebuilt catalogues Domain experts Knowledge

...

Transf . Transf QVT)) (QVT XMI import

AO Architectural Model (CAM Profile for UML 2.0) XMI export

Transf. Transf ((MOFScript)) Text generation

ADL description (DAOP- ADL)

Fig. 2. The MDD–AOSA generation process.

els and transformations of the MDD–AOSA process are described below. 3.1. Base Architectural Model The software architect produces a first version of the system architecture, without considering the crosscutting requirements of the system, which are usually system quality attributes or extra-functional properties. It defines the main entities of the system, and their interactions, from an architectural point of view. This architectural model is expressed using UML 2.0 class, component and communication/sequence diagrams. Therefore, this initial model conforms to the UML 2.0 metamodel. 3.2. Marking process This is a manual process, which makes the global generation process semiautomatic. The software architect must annotate the Base Architectural Model in order to indicate where and how crosscutting requirements have to be applied (e.g., where and how security is demanded). The identification of the crosscutting concerns at requirements level is still an open issue, but most of the work being done relies on the use of pre-built catalogues for non-functional requirements [46,47]. For example, in distributed systems, the crosscutting concerns are normally recurrent, and can be identified and catalogued, as in [46,47]. Thus, a set of marks for each catalogued crosscutting concern can be provided. Note that the decision as to how to identify crosscutting concerns and as to how they can be adequately managed as aspects is outside the scope of our work. Some other possibilities are to use third-party AO requirement engineering approaches [7], existing meta-concerns spaces [48], and lessons learned from personal practical experience. 3.3. Marked Base Architectural Model This model extends the Base Architectural Model with a set of marks, which represents crosscutting concerns. The marked model contains all the information required to generate a complete AO architectural model, but without containing any AO terminology. Marks are modelled as UML stereotypes with attached tagged values. Consequently, the marked model also conforms to the UML 2.0 metamodel. 3.4. UML 2.0 to CAM transformation The Marked Base Architectural Model is transformed into a CAM model. This transformation is specified using two techniques: (1) The elements belonging to Base Architectural Model are transformed based on a transformation between the elements of the UML 2.0 metamodel and the CAM metamodel; (2) Each mark is transformed using a template transformation. For each mark found in the

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Marked Base Architectural Model, a specific pattern, which introduces an aspect into the architecture, is created in the target model. This transformation is specified in QVT, the OMG standard for model transformation. 3.5. AO architectural model As a result of the previous transformation, an AO software architecture is obtained. This architecture is expressed as a CAM model. Since CAM models are constructed using a UML 2.0 profile, they conform to the UML 2.0 metamodel. 3.6. CAM to DAOP–ADL transformation Using MDD, the DAOP–ADL description of a software architecture can be automatically derived from its corresponding CAM model by means of a model to text transformation. Currently, there is no existing standard for model to text transformation. MOFScript is a stable language with enough tool support1 and is one of the proposals leading the OMG standard development, so can therefore be considered particularly appropriate for implementing the CAM to DAOP– ADL transformation. 3.7. Architecture description using an ADL Finally, an architecture description based on an AOADL is obtained, which is expressed with DAOP–ADL. Using DAOP–ADL, the software architecture of a system is textually described in XML, according to the DAOP– ADL XML Schema. Notice that our approach provides two models to describe the AO software architecture of the application. The reason for this is that DAOP–ADL can be seen as a textual notation of CAM models. This duality allows us to provide: (1) a UML 2.0 visual notation for describing AO architectures, which is normally preferred by architects to negotiate with the different stakeholders; (2) a textual notation which, although more inconvenient for humans, is machine-readable and can be used by different kinds of tools, such as for instance, a middleware platform, like DAOP [4], which interprets this information in order to do the composition of components and aspects at runtime. 4. Base Architectural Model construction This section shows the first step in the MDD–AOSA process: the construction of a Base Architecture Model which meets exclusively the non-crosscutting concerns of the system. First, our case study is presented and then, its Base Architecture Model is produced.

1

http://www.eclipse.org/gmt/mofscript/.

1253

4.1. Case study: an Auction System An online Auction System, taken from [12], will be used as a case study to illustrate the process throughout this paper. In this section, we will present an informal description of this system. A complete description of the Auction System Case Study can be found in [49]. The Online Auction System allows subscribed users to negotiate over the buying and selling of goods in the form of English-style auctions.2 Additionally, the system has to guarantee that bids placed are solvent, this means that the system has to check that users have enough funds in their accounts to support a bid. In order to check user solvency, each time a user places a bid, the corresponding bid amount is blocked in the user’s account. Once a customer has joined an auction, he/she may make a bid and all the other users who have joined the auction are notified of the placing of a new bid. Once an auction closes, the system decides the winner, and it deposits the highest bid price minus the commission taken for the auction service into the seller’s virtual account. An important requirement is that the system must be fault-tolerant. All fund transfers must be transactional: either they finish successfully or they leave the accounts involved untouched. As we already commented, different techniques, such as Aspect-Oriented Requirements Engineering [7], existing meta-concerns spaces [48], pre-built catalogues [46] and lessons learned, can be used to identify crosscutting requirements. Some of the crosscutting requirements identified that are part of this paper are Notification, which encapsulates the logic for notifying all users about the placing of new bids and other events and Transaction Management, for managing fund transfers. Justifications about why these requirements are crosscutting and how they can be encapsulated into aspects can be found in [50,51] for Notification (a particular kind of Awareness) and in [47,52,53] for Transactions Management. 4.2. UML 2.0 Auction System architecture The first step in the MDD–AOSA process is the construction of an initial architecture from the requirements specification for the system under consideration. This initial architecture addresses exclusively the non-crosscutting concerns, explicitly avoiding considering crosscutting requirements and/or crosscutting quality attributes. This base architecture might be shared by different systems requiring the same functionality, but with different crosscutting quality attributes (e.g., different security mechanisms). The architecture can be derived from requirements following any classic (non-AO) process (a survey explaining these processes can be found in [8]), and it is modelled in UML 2.0.

2

http://en.wikipedia.org/wiki/Auction.

1254

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Fig. 3 shows the structural view of one alternative architecture expressed in UML 2.0, for the Auction System Case Study. An architecture expressed in UML 2.0 is comprised of a set of components. These components can own ports. A port can be associated with a set of provided/required interfaces, indicating those services a component provides to its environment as well as the services that a component expects from its environment. A port in UML 2.0 is an interaction point able to redirect, filter, modify, etc., messages. The UML ports proposal enables components to send output messages directly to ports, rather than identifying an external target object/component by a reference. Messages are also received on ports, which redirect them appropriately to component internals. The Auction System architecture is comprised of five main components: (1) AuctionSystem, which registers users, creates auctions, etc.; (2) Auction, which manages the auction of a single item; (3) VirtualBank, which handles the virtual credit accounts of auction participants; (4) CreditCard, is an external service used in order to transfer credit from/to user virtual accounts to/from real accounts; and (5) User, which is responsible for the interaction with the user. Each component has several ports, each one responsible for managing a set of related interfaces. Together with the structural view of Fig. 3, a behavioural description is created using sequence/communication diagrams in order to represent the interaction between components. Fig. 4 depicts a sequence diagram that shows the transfer between accounts after an auction closes. In this diagram, components send messages to their ports, which redirect them appropriately. First, the final price is withdrawn from the winner’s virtual account. This price, minus a charge for the Auction System, is deposited in the auctioneer’s virtual account. Finally, the charge for carrying out the operation is deposited into the system’s virtual account. This architecture was constructed without considering crosscutting requirements specified in the Auction System requirements specification, as transaction support. The next section shows how to mark and transform this model in order to semiautomatically generate an AO architecture that also satisfies the aspectual requirements, such as the transactions and notification in our example.

<> User

IAuctionManagement

5. From marked UML 2.0 architectures to CAM Once the initial base architecture has been constructed, it is marked to indicate how and where the crosscutting concerns are applied. Then, the Marked Base Architectural Model is transformed into a CAM model. 5.1. Marked Base Architectural Model According to the MDD–AOSA process, where and how aspectual requirements have to be addressed is indicated using a set of marks. As commented in Section 3, our approach is particularly well suited for recurring aspectual requirements. For example, in distributed systems, there is a set of crosscutting concerns previously identified, which are normally provided by component platforms by means of predefined common services (e.g., transaction or security). Therefore, these well-known crosscutting concerns can be catalogued as good candidates to be modelled with aspects. For each catalogued aspect, a set of marks is provided. The architect must insert these marks in the Base Architectural Model, specifying how and where the crosscutting requirements must be considered. To illustrate how the marking process works, the Notification and Transaction Management crosscutting concerns of the case study are used. Notification and Transaction Management are denoted as aspectual requirements as a result of previous experience that has shown they can be managed more easily if they are modelled as aspects [47,51,52]. The addition of the Transaction Management concern as an aspect requires two elements: (1) The specification of the transaction logic, i.e., mechanisms to ensure the ACID (Atomicity, Consistency, Isolation and Durability) properties [54] of the transaction. As commented in Section 3, the transaction logic is encapsulated inside an aspect. This part is independent, to a certain degree, of the application, as most of the transaction logic can be reused. Only the implementation of a few methods are application dependent, such as compensation actions for rolling back a transaction if ATMS (Advanced Transaction Mechanisms) [55–58] are used. Aspectual interfaces

<> AuctionSystem

<> CreditCard

UserAuctionPort IManagement IAuction IUSerNotification AuctionPort

ICreditCard

<> Auction FundsPort

<> VirtualBank VirtualBankPort IVirtualBank

Fig. 3. Initial Auction System Architecture in UML 2.0 – structural view.

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

: Auction

1255

: VirtualBankPort

: FundsPort

closeAuction withdrawal(finalPrice, winnerAcc)

deposit(finalPrice,winnerAcc)

deposit(finalPriceMinusTax, sellerAcc)

withdrawal(finalPriceMinusTax,sellerAcc)

deposit(tax, systemAcc)

deposit(tax,systemAcc)

Fig. 4. Initial Auction System Architecture in UML 2.0 – behavioural view for the Close Auction use case.

however, the relevant part at architectural level, do not change for different applications, and can therefore be reused in many application architectures. The model transformation does not require any extra information to inject this aspect into the architecture. It needs only to know that Transaction Management is required. The logic of a Transaction Management aspect is described in depth in [52,59]. (2) The composition rules, or pointcut definition in most aspect languages, specify where and when the Transaction Management aspect has to be executed. These composition rules depend on each application. For this purpose, a set of marks is then created to specify transactional needs of each operation. The Transaction Management imposes that a certain sequence of messages has to be executed as an atomic unit. Four marks are provided to the software architect to indicate how the Transaction Management must work: (1) begin_ transaction signals the beginning of a set of operations that are considered part of a transaction; (2) join indicates that an operation participates in a transaction; (3) end_transaction indicates the end of the transaction (commit is performed) and; (4) transaction_failed indicates the transaction has failed (rollback is required).

: Auction

These marks are stereotypes that can only be applied to messages. It is the responsibility of the software architect to ensure the correct behaviour of the transaction support. For instance, the architect has to check that each open transaction will either commit or rollback. Fig. 5 shows the scenario for transferring funds between accounts once an auction is closed. All these movements of funds have to be executed transactionally, so a begin_transaction mark is placed on the first message of fund movements and an end_transaction mark on the end of the last one. The operations that require transactional support are marked with join. As this is a successful transaction scenario, the transaction_failed mark is not required. Scenarios reflecting exceptional cases should be created to show when transactions have to rollback. Regarding Notification, the solution is to apply the aspect-oriented version of the subject-observer pattern [50] at architectural level. Two marks are defined: one for registering observers, register_observer; and the other one, send_notification, for notifying them. Both marks are placed on messages. Subscription list is used in order to support that different observers can be added to the same subject, but each one

: VirtualBankPort

: FundsPort

closeAuction <> <> withdrawal(finalPrice, winnerAcc)

<> deposit(finalPriceMinusTax,sellerAcc)

<> deposit(tax,systemAcc)

deposit(finalPrice,winnerAcc)

withdrawal(finalPriceMinusTax,sellerAcc)

deposit(tax,systemAcc)

<>

Fig. 5. Marked model for transaction management.

1256

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

: UserAuctionPort

: UserAuctionPort

: AuctionPort

: Auction

join(johnId ) <> join(userId) 1

<> observerList = buyers

placeBid (bid, userId) <> placeBid (bid, userId)

2

<< send_notification >> observerList = buyers method = updateBid (bid)

Fig. 6. Marked model for notification.

requiring different kinds of notifications. register_observer indicates that, the receiver of a message where it is placed, (see Fig. 6, label 1) must register the caller as an observer, in the list indicated in the tagged value associated to the stereotype. send_notification indicates that a certain list of observers must be notified after receiving the message it marks (see Fig. 6, label 2). Additionally, this mark must specify, by means of a tagged value, the subscribers’ method that should be called to send the notification. Fig. 6 illustrates a scenario where users join and bid on the same auction. It is marked to indicate where and how notifications are demanded. After joining an Auction, the User should subscribe to the buyers list. Additionally, after a new bid is placed, a message UpdateBid with the new bid as argument has to be sent to the observers subscribed to the buyers list. The most important contribution of this marking process is that the software architect specifies the behaviour and relationships of the aspectual requirements without any knowledge of aspects. Using marks only requires knowledge about the domain of the aspectual requirement, but not about its aspectual solution. For example, the software architect needs to know how transactions work, but nothing about how transactions are specified using aspects. Finally, we would like to point out that marking a model requires placing a mark in every place a crosscutting concern is required. Therefore, the effort required to mark a model is directly proportional to the number of architectural points where crosscutting concerns must be applied. This is not worse than in the traditional case, where the crosscutting concern itself is added in each one of these places, instead of just a mark. In addition, using our approach, an aspect-oriented software architecture is obtained, achieving benefits regarding maintenance and evolution. Readers familiar with aspect-oriented techniques might claim than a quantification mechanism, such as that used in pointcuts of aspect-oriented languages, could be applied here in order to facilitate the addition of marks. This idea was discarded because: (1) it implies the software architect has to learn how to use this quantification mechanism, i.e., he or she would need to learn some aspect-oriented related issues, which is what we are trying to avoid; (2) the useful-

ness of these quantification mechanism relies mainly on syntactic tricks, such as following conventions for naming methods, which are difficult to apply at the architectural level and reduce the freedom of the software architects when designing the Base Architectural Model. 5.2. Marked UML to CAM transformations Once the Base Architecture Model has been marked, the model obtained is ready to be automatically transformed into an AO architectural model, expressed in CAM. 5.2.1. CAM As previously described, CAM [4] is a component and aspect model that defines components and aspects as the basic building blocks. Both, components and aspects (aspectual components in CAM), can act as units of composition with contractually specified interfaces and explicit context dependencies.3 Components interact with other components in the environment by sending and/or receiving messages and by throwing events. CAM defines three kinds of interfaces: provided, required and evaluated. Provided and required interfaces have the same meaning as in UML 2.0. Evaluated interfaces are the interfaces provided by aspects, and CAM imposes a specific syntax for the signature of their operations. Operations of an evaluated interface differ from operations of a provided interface in that they are never invoked explicitly, they are only executed as a result of the evaluation of an aspect.4 CAM considers that aspects are applied to black-box components. Therefore, CAM intentionally avoids the definition of join points that intercept the internal behaviour of a component, so components can only be accessed through their public interfaces. CAM aspects can be applied before and after (incoming and outgoing) messages and events, and also before and after the creation and destruction of component instances (this is the list of CAM join points). A CAM model can be represented in UML 2.0 using the CAM Profile. CAM components and aspects are repre3

According to the definition of component by C. Syperski [1]. By aspect evaluation we mean the execution of the aspect advice, according to AspectJ [60] terminology. 4

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

sented as UML 2.0 components, and provided/required interfaces as UML 2.0 interfaces. Evaluated interfaces are also represented as UML 2.0 interfaces. OCL constraints are used to ensure the interfaces are compliant with CAM constraints on evaluated interfaces. In the CAM Profile, direct communication between components is explicitly avoided, so all communication has to be performed through ports. Aspect advice execution is triggered when a message sent from a port to an aspect arrives. As components communicate with ports, they are not aware of which aspects are being triggered at the port when the messages are routed. Fig. 7 shows how a synchronous message sending, and the possible advice execution, are modelled according to the CAM Profile. In this case, a component A sends a synchronous message to a component B through its port PortA. This message is received by component B through its port PortB. The execution of an aspect is signalled by placing a message stereotyped as aspectual from a port to an aspect. In the case of a synchronous message, an aspect can be executed BEFORE_SEND (Fig. 7, label 1), BEFORE_RECEIVE (Fig. 7, label 2), AFTER_RECEIVE (Fig. 7, label 3) or AFTER_SEND (Fig. 7, label 4), the message. 5.2.2. Transformation process Let us consider how the Marked UML 2.0 Architectural Model can be automatically transformed into a CAM model of the Auction System using MDD mechanisms. This transformation consist of three substeps, which are described textually:

Component transformation rule. UML 2.0 components are copied with no changes, and stereotyped as CAM component, preserving the same ports and associations with interfaces. Some minor auto-

ComponentA

PortA

Aspect

matic model transformations can be required in order to adapt the UML 2.0 Architecture Model to CAM. For instance, the CAM Profile avoids direct component communication, which is allowed in UML 2.0. Therefore, direct communication would be automatically transformed into communication through ports. Scenario transformation rule. UML 2.0 sequence diagrams are copied with no changes. As in the last step, some minor automatic transformations may also be required. Aspect Injection Rule. Each mark adds, when transformed, one or more aspects to the architecture. Aspects encapsulate crosscutting concerns, so each mark is transformed into the execution of one or more aspect advices. A specific transformation rule is required by each mark. As previously commented, several transformations can exist for the same mark corresponding to different solutions that satisfy the aspectual requirement. The mark contains all the information required to model the aspectual requirements as a CAM aspect in the architecture. Thus, the main contribution of using model transformation techniques is that all this knowledge can be encapsulated in a ‘‘transformation rule”, which would be applied automatically over all those models where it is required. For instance, applying the Aspect Injection Rule to the begin_transaction mark, this implies firstly adding (if it has not already been done by a previous transformation) a new aspectual component TransactionMng to the architecture, which encapsulates the transaction logic. This aspectual component crosscuts the VirtualBank and Auction components. Then, the second step is to introduce the aspectual message begin_transaction in order to

ComponentB

PortB

foo «aspectual» aspect 1 BEFORE_ SEND

foo «aspectual» aspect 2

BEFORE_ RECEIVE

foo fooReply «aspectual» aspect 3

fooReply

1257

AFTER_ RECEIVE

AFTER_ SEND «aspectual» aspect 4 fooReply

Fig. 7. Modelling aspect triggering using the CAM Profile.

1258

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

what we have to search in the source model. The bottom pattern indicates which elements have to be created (if they have still not been created by the application of a previous QVT-relation). The top pattern of Fig. 9 indicates that whenever a message stereotyped as begin_transaction in a sequence diagram (interaction) arrives at a port, the bottom pattern has to appear in the target model. The satisfaction of the bottom pattern requires: (1) the copying of the original message (left side of the pattern); (2) the creation of a new instance representing the TransactionMng aspect (in2, c1, p2, s3 elements); (3) the introduction of the beginTransaction message, stereotyped as aspectual from the port to the aspect (m2, p3, s2, me4, me5 elements); (4) the rearrangement of the message ordering (elements with a gray background) to accommodate the new message (g1, g2, g3 elements). The transformations of the other marks, and also the minor transformations that could be required to adapt the Base Architectural Model before transforming it into a CAM model, are similar to this.

indicate that the begin_transaction advice must be executed before the first message in the transactional sequence is sent (Fig. 8, label 1). The same technique is applied to the join and end_transaction marks, generating the composition rules for executing the join and commit advices (Fig. 8, labels 2–5). All these transformations are specified in QVT, the OMG standard model transformation language. It allows us to specify transformations between models that conform to a MOF metamodel. As UML 2.0 models conform to a MOF metamodel (i.e., the metamodel of UML 2.0 is constructed using MOF), QVT can be used to specify the transformations from the marked UML 2.0 Architectural Model to CAM. QVT allows us to manipulate elements of models as instances of their associated metaclasses. The QVT standard specifies several equivalent sub-languages to specify the transformations, each one with a certain abstraction level and style (imperative or declarative). Specifically, we use the QVT-relations language (and its graphical notation in particular) to specify the transformations. In this language, a QVT transformation is composed of several QVT-relations. A QVT-relation is a relationship between two patterns, one of the source model and one of the target model. Which pattern is the source and which is the target is indicated by the direction of the execution of the transformation (right to left or left to right). The meaning of a QVT-relation is that whenever the specified pattern is found in the source, the target has to contain this pattern. In order to satisfy QVT-relations, elements can be created, updated or removed from the target model. Fig. 9 shows one of the relations for transforming the begin_transaction mark. A QVT-relation can be interpreted as a graph transformation. This QVT-relation is executed from top to bottom. The top pattern indicates : Auction closeAuction

: FundsPort

withdrawal (...)

6. From CAM to DAOP–ADL This section explains how CAM models can be automatically transformed into DAOP–ADL descriptions. DAOP– ADL allows us to describe the architecture of the system in a textual way, by means of XML documents [31], which can be more easily processed by tools. Although UML 2.0 models, such as CAM, can be serialised in XML using the XMI standard, these XMI serialisations produce huge XML documents, containing a lot of information which, although it is required to serialise the UML models, is not required at all for the description of the software architecture. In addition, the XMI syntax is not user-friendly (it is

: VirtualBankPort

: TransactionMng

: VirtualBank

1 «aspectual» beginTransaction withdrawal (finalPrice ,winnerAcc ) 2

«aspectual» join withdrawal (finalPrice , winnerAcc )

deposit (..)

deposit (finalPriceMinusTax ,sellerAcc )

3

«aspectual» join

deposit (finalPriceMinusTax ,sellerAcc )

Injected into the architecture by the transformation .

deposit (..) deposit (tax,systemAcc )

«aspectual» join deposit (tax ,systemAcc )

«aspectual» commit

5

Fig. 8. Result of transaction marks transformation.

4

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

1259

beginTransaction i1 : Interaction

receiveEvent me1 : MessageEnd

before g1 : GeneralOrdering

ownedMember l1 : Lifeline s1 :Stereotype

m1 : Message

after

covered

name = “begin_transaction ”

me2 : MessageEnd

in1 :Instance represents

p1 : Property

po1 :Port s1

s2

C

E

s2 :Stereotype i1 : Interaction

name = “aspectual ” ownedMember s :Message

ownedMember m1 : Message

represents

receiveEvent me1 : MessageEnd before covered

p2 : Property

name = “beginTransaction ”

sendEvent me4 : MessageEnd

receiveEvent before

after

me5 : MessageEnd

before

c1 : Component name = “TransactionMng ”

after

l1 : Lifeline g2 : GeneralOrdering

in2 : Instance

g3 : GeneralOrdering

p2 : Property

represents in1 :Instance

me3 : MessageEnd

after

g1 : GeneralOrdering

s3 :Stereotype name = “aspect ”

po1 :Port

Fig. 9. One of the QVT-relations for the begin_transaction mark.

based on metamodel element names and relationships, as used by QVT patterns), therefore XMI files are not easy to parse. DAOP–ADL, on the other hand, produces more compact and manageable documents, which are written in a syntax familiar to software architects. For example, the Auction component is represented in DAOP–ADL by means of a tag, whereas in XMI, it is represented using the tag , which, in our opinion, is more confusing. Therefore, the transformation from CAM to DAOP– ADL is a model to text transformation which has to fill the three main parts of a DAOP–ADL description: (1) component description; (2) aspect description; and (3) composition constraints description (i.e., pointcut definition). This transformation is implemented in the MOFScript language. This language allows us to navigate through models which conform to a MOF metamodel, such as UML 2.0 models; also to access model element attributes; and to write text in output. Fig. 10 shows the initial steps of the CAM to DAOP– ADL transformation implemented in MOFScript: Line 1 declares the transformation name and input model, which conforms to a certain metamodel, in this case ‘‘UML2”.

Line 2 declares the main entry point to the transformation; Line 3 declares the output file and in Lines 4–5 the DAOP– ADL root tag is written on the output. Then, components, aspects and composition constraints are generated. For instance, Lines 6–10 show how CAM components are searched as UML 2.0 components stereotyped as CAM component, and for each one found, a call to a method to generate the information for this single component is performed. Lines 24–31 show the method implementation. The tag is appropriately filled, calling other methods to fill the subtags. A similar process is applied for aspects. In order to generate the composition constraints, the interactions (sequence diagrams) are processed to search messages stereotyped as aspect, and when found, the corresponding aspect evaluation rule is generated. Finally, Fig. 11 shows an excerpt of the DAOP–ADL architectural description generated. It contains the description of the components (Lines 3–6), the aspects (Lines 9– 12) and the composition constraints (Lines 13–33). In DAOP–ADL, when aspects are triggered over component public interfaces it is indicated by means of . An indicates the kind of behaviour intercepted (a message creation/destruction, the sending/receiving of a message, etc.) and additional

1260

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Fig. 11. Excerpt of generated DAOP–ADL architecture description. Fig. 10. Excerpt of the CAM to DAOP–ADL transformation.

information for executing the aspect. The execution of the beginning of the transaction, as shown in Fig. 8, is transformed into the rule of Lines 15–30. This indicates that, before the withdrawal message is sent from the Auction component to the VirtualAccount component, the TransactionMng aspect has to be evaluated. As already commented in Section 1, once the DAOP– ADL architectural specification is obtained automatically from the CAM metamodel several options that go from architecture to detailed design and implementation can be explored. First of all, the software architect can reason about the resulting architecture. For instance, in our example, the software architect can see at first glance that the Auction and the VirtualAccount components are not dependent on each other, so they can be implemented and (re)used separately. All the information about crosscutting concerns is placed under the tag, so all the component interactions affected by an aspect are listed in one place. This facilitates the task of the software architect identifying aspectual compositions. On the other hand, this DAOP–ADL specification can be used by different kinds of tools, such as a middleware platform like DAOP [4]. Finally, the generation of code for implementation is also possible.

7. Tool support In this section, we describe the tool support for the MDD–AOSA process. In the first sub-section, we present the MDD tools used to construct the initial models and to perform the model transformations. Then, we describe how these tools have been integrated with an IDE previously built to support the development of CAM/DAOP applications [36]. 7.1. Model construction and transformation implementation By using widely used and accepted standards we have obtained a good degree of external tool support for our approach. The construction of the initial component model of our approach requires the use of a UML 2.0 tool with capacity to export UML diagrams to XMI documents. Currently, there are a sufficient number of modelling tools supporting this feature,5 so development teams can choose the one they prefer.

5

http://www.uml.org/#Links-UML2Tools.

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Model transformations are specified according to the QVT standard, which is publicly available. However, there is a lack of stable tool support for the QVT standard. We have specified QVT-transformations for two reasons: (1) when stable tools are released, QVT-relations will be able to be implemented directly on them; (2) in the meanwhile, QVT-relations serve as a useful guide specifying how to implement transformations in other languages. Nevertheless, since models conforming to MOF metamodels can be serialised in XML using the XMI standard and this functionality is widely supported by current modelling tools, the problem of implementing a model transformation (QVT-relation) can be reduced to the problem of creating an XML document from another XML document according to a model transformation specification. Therefore, we have adopted XSLT for implementing QVT-relations, because it offers a standard, vendor-independent and high-level solution for transforming one XML document into another XML document. Other solutions for parsing and creating XML documents, such as SAXP6 or DOM,7 could also be used. However, as model transformations become more and more complex, implementing them by dealing with XMI representations of the models becomes more difficult and tedious to maintain. Thus, when the transformations are more complex, the use of non-standard model transformation languages, such as ATL8 or MTF9 should be considered. The main benefit is that these languages hide the complexity of dealing with the XMI representations, providing high-level constructs to manipulate models. However, if the complexity of the transformations is manageable, the effort of learning a non-standard language, which will probably disappear in the next few years, would not be justified. Finally, model to text transformations are implemented using the MOFScript language, which is the most mature and important proposal leading the final OMG standard development. We have integrated the MDD transformations presented in this paper as part of the development process of the CAM/DAOP platform [36]. Applications running on top of the CAM/DAOP platform must be implemented using the CAM/DAOP development framework and the application architecture must be specified in DAOP– ADL. With the results presented in this paper, developers can specify the application architecture in UML 2.0, without needing to learn a new middleware framework for developing component- and aspect-based applications (i.e., CAM/DAOP).

6 7 8 9

JSR 173 – http://www.jcp.org/en/jsr/detail?id=173. http://www.w3.org/DOM/. http://www.sciences.univ-nantes.fr/lina/atl/. http://www.alphaworks.ibm.com/tech/mtf.

1261

7.2. Integrating MDD–AOSA with the CAM/DAOP tools The MDD transformations described throughout the paper have been integrated as part of the IDE developed for CAM/DAOP [36] (see Figs. 12 and 13). This IDE has been implemented as a set of Eclipse plug-ins.10 With this IDE a cohesive method and tool-set supporting the use of CAM/DAOP technologies throughout the lifecycle is provided. First, by using MDA standards and automatic transformations, the CAM model and the DAOP–ADL model of the application are (semi)automatically generated. This information can be loaded into an Architecture Description and Validation tool (Fig. 12), by which software architects can easily consult and share the description of the software architecture with the different stakeholders. Optionally, this tool can serialise this architectural information to make it available to the DAOP platform [4], which uses the architectural information at runtime to perform latebinding between components and aspects. Moreover, in order to facilitate the reuse of components and aspects, the CAM/DAOP IDE also contains a Component and Aspect Directory tool (Fig. 13), which provides access to a web-based repository of components and aspects. These tools allow the development of highly flexible systems, where the system architecture can be modified by removing, replacing and reconfiguring components (and aspects in our approach) without disturbing other parts of the application [61].

8. Conclusions In this paper, we have presented our experience combining MDD and AOSD, specifically to produce AO architectures from non-AO ones, using the AO architectural model and the AO ADL provided by the CAM/DAOP approach. The important contribution of this approach is that specific expertise about the technical details of aspect-orientation and its terminology is not required to carry out the marking process. This process allows designers to focus only on the identification of the aspectual requirements as well as the entities affected by them. Consequently, with this approach we attract the attention of designers to the aspectual requirements identified at the architectural level, encouraging them to study how they may affect the design and implementation phases. We have illustrated our approach by managing the transaction and notification concerns as aspects for an Auction System. Although it is not always possible to encapsulate transaction or notification related concerns as aspects, this does not affect the hypothesis of this paper. The main goal of our approach is to provide a good solution to manage crosscutting concerns whenever 10 It can be downloaded from http://caosd.lcc.uma.es/CAM-DAOP/ tools.

1262

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

Fig. 12. CAM/DAOP IDE – architecture repository.

Fig. 13. CAM/DAOP IDE – component and aspect repository.

it is possible to encapsulate them as aspects. This paper demonstrates that MDD-based approaches make the transformation of a non-aspect oriented architecture into an aspect oriented one easier. The architecture generated

includes a general schema for modelling and composing crosscutting concerns for a given set of marks. This architecture could be extended if the developer were to consider that more details must be added. Nevertheless,

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

with our approach this task will not be accomplished from scratch. The automatic model transformations (and the set of marks they use) shown in this paper encapsulate the know-how about modelling crosscutting concerns as architectural aspects. The steps for adding these crosscutting concerns are practically the same across different applications, this being a repetitive, tedious and errorprone task. Thus, it is possible to automate these steps, enabling them to be performed faster and without (or with fewer) errors. However, the first time software architects need to deal with a crosscutting concern, this knowhow is not yet available, so it is not possible to use automatic model transformations as described in this paper. In this case, software architects need first to investigate how this crosscutting concern can be encapsulated and composed at the architectural level as an aspect. When the steps for incorporating this crosscutting concern into an aspect are well known, it is possible to encapsulate it into an automatic model transformation and a set of marks that assist the model transformation. After this process, the automatic model transformation and the set of marks will be added to the transformations and marks repository. For instance, AccessControl is a well-known crosscutting concern inside the Aspect-Oriented Community [47]. If this crosscutting concern and its associated set of marks was not in the repository, the first task will be to analyse how it can be encapsulated into an aspect. Then, software architects would examine the steps for adding this aspect to different software architectures. Once this know-how has been acquired, the process can be automated by encapsulating it in an automatic model-transformation. This process will require some additional information, such as which operations need to have their access controlled. For this purpose, and using the acquired know-how, a set of marks are defined. Finally, the automatic model transformation and the set of marks are added to the repository, thus, non-AO software architects can use them, without requiring any knowledge of aspect-orientation. It should be noticed that most of crosscutting concerns, such as Persistence, Authentication or Awareness, recur throughout different applications, so the construction of a transformations and marks repository for crosscutting concerns which requires being extended with new crosscutting concerns in only a few exceptional cases, is a reasonable idea, in our opinion. The most important challenge of MDD today is the provision of tool support for the automatic model transformations. We have described in this paper a first step toward this end, defining automatic model transformation processes based on the use of XMI, QVT for model-to-model transformation and MOFScript for model-to-text transformations. As future work, we are currently working on the provision of a wide repository of marks, which will allow archi-

1263

tects to make extensive use of this work. We are also investigating different strategies to specify and implement model transformations in order to facilitate the specification of new rules on top of existing ones. To this end, we are investigating the mixing of XML APIs, such as DOM, with XSLT, or how to effectively translate QVT specifications into languages like ATL. References [1] C. Szyperski, Component Software, second ed., Addison-Wesley, Reading, MA, 2002. [2] B. Meyer, Object-Oriented Software Construction, second ed., Prentice-Hall, Eaglewood Cliffs, NJ, 2001. [3] R.E. Filman, T. Elrad, S. Clarke, M. Aksßit, Aspect-Oriented Software Development, Addison-Wesley, Reading, MA, 2005. [4] M. Pinto, L. Fuentes, J.M. Troya, A dynamic component and aspectoriented platform, The Computer Journal 48 (4) (2005) 401–420. [5] D. Suve´e, W. Vanderperren, V. Jonckers, JAsCo: an aspect-oriented approach tailored for component based software development, in: Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (AOSD), Boston, Massachusetts, USA, 2003, pp. 21–29. [6] E. Truyen, B. Vanhaute, B.N. Jørgensen, W. Joosen, P. Verbaeton, Dynamic and selective combination of extensions in componentbased applications, in: Proceedings of the 23rd International Conference on Software Engineering (ICSE), Toronto, Ontario, Canada, 2001, pp. 233–242. [7] E. Baniassad, P.C. Clements, J. Araujo, A. Moreira, A. Rashid, B. Tekinerdogan, Discovering early aspects, IEEE Software 23 (1) (2006) 61–70. [8] R. Chitchyan, et al., Report synthesizing state-of-the-art in aspectoriented requirements engineering, architectures and design, Tech. Rep. AOSD-Europe Deliverable D11, AOSD-Europe-ULANC-9, Lancaster University, 2005. [9] A. Garcia, C. Chavez, T. Batista, C. Sant’anna, U. Kulesza, A. Rashid, C. Lucena, On the modular representation of architectural aspects, in: V. Gruhn, F. Oquendo (Eds.), Proceedings of the 3rd European Workshop on Software Architecture (EWSA), LNCS, vol. 4344, Nantes, France, 2006, pp. 82–97. [10] T. Stahl, M. Vo¨lter, Model-Driven Development: Technology, Engineering, Management, Wiley, London, 2006. [11] S. Beydeda, M. Book, V. Gruhn, Model-Driven Development, Springer, Berlin, 2005. [12] S. Sendall, A. Strohmeier, Specifying concurrent system behavior and timing constraints using OCL and UML, in: M. Gogolla, C. Kobryn (Eds.), Proceedings of the 4th International Conference on the Unified Modeling Language (UML), LNCS, vol. 2185, Toronto, Ontario, Canada, 2001, pp. 391–405. [13] R. Chitchyan, M. Pinto, A. Rashid, L. Fuentes, COMPASS: composition-centric mapping of aspectual requirements to architecture, in: A. Rashid, M. Aksßit (Eds.), LNCS Transactions on AspectOriented Software Development IV (TAOSD), Special Issue on Early Aspects, 2007, LNCS, vol. 4640, pp. 3–53. [14] P. Sa´nchez, L. Fuentes, A. Jackson, S. Clarke, Aspects at the right time, in: A. Rashid, M. Aksßit (Eds.), LNCS Transactions on AspectOriented Software Development IV (TAOSD), Special Issue on Early Aspects, 2007, LNCS, vol. 4640, pp. 54–113. [15] Object Management Group (OMG), Unified Modeling Language: Superstructure v2.0 (formal/05-07-04), 2005. [16] T. Ku¨hne, Matters of (meta-)modeling, Software and Systems Modeling (SoSyM) 5 (4) (2006) 369–385. [17] Object Management Group (OMG), Meta Object Facility (MOF) Core Specification, Version 2.0 (formal/06-01-01), January 2006. [18] O.M.G. (OMG), MOF 2.0/XMI Mapping Specification, v2.1 (formal/05-09-01), 2005.

1264

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265

[19] F. Jouault, I. Kurtev, Transforming models with ATL, in: J.-M. Bruel (Ed.), Satellite Events at the MoDELS Conference, LNCS, vol. 3844, Montego Bay, Jamaica, 2005, pp. 128–138. [20] S.J. Mellor, K. Scott, A. Uhl, D. Weise, MDA Distilled, AddisonWesley, Reading, MA, 2004. [21] Object Management Group (OMG), MDA Guide, Version 1.0.1 (omg/2003-06-01), 2003. [22] J. Greenfield, K. Short, S. Cook, S. Kent, Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tool, Wiley, London, 2004. [23] A. Demir, Comparison of model-driven architecture and software factories in the context of model-driven development, in: Proceedings of the 4th Workshop on Model-Based Development of ComputerBased Systems and the 3rd International Workshop on Model-Based Methodologies for Pervasive and Embedded Software (MBD-MOMPES), Postdam, Germany, 2006, pp. 75–83. [24] A. Rashid, A. Moreira, J. Arau´jo, P. Clements, E. Baniassad, B. Tekinerdogan, Early aspects: aspect-oriented requirements engineering and architecture design, Available from: . [25] Aspect-Oriented Software Development web site, Available from: . [26] J. Brichau, M. Haupt (Eds.), Report describing survey of aspect languages and models, Tech. Rep. AOSD-Europe Deliverable D12, AOSD-Europe-VUB-01, Vrije Universiteit Brussel, 2005. [27] N. Loughran, et al., Survey of aspect-oriented middleware research, Tech. Rep. AOSD-Europe Deliverable D8, AOSD-Europe-ULANC10, Lancaster University, 2005. [28] C.E. Cuesta, M. del Pilar Romay, P. de la Fuente, M. BarrioSolo´rzano, Temporal superimposition of aspects for dynamic software architecture, in: R. Gorrieri, H. Wehrheim (Eds.), Proceedings of 8th International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS), LNCS, vol. 4037, Bologna, Italy, 2006, pp. 93–107. [29] T. Aaltonen, M. Katara, R. Kurki-Suonio, T. Mikkonen, On horizontal specification architectures and their aspect-oriented implementations, in: A. Rashid, M. Aksßit (Eds.), Transactions on AspectOriented Software Development (TAOSD), LNCS, vol. 4242, 2006, pp. 1–29. [30] N. Pessemier, L. Seinturier, T. Coupaye, L. Duchien, A model for developing component-based and aspect-oriented systems, in: W. Lo¨we, M. Su¨dholt (Eds.), Proceedings of the 5th International Symposium on Software Composition (SC), LNCS, vol. 4089, Vienna, Austria, 2006, pp. 259–274. [31] M. Pinto, L. Fuentes, J.M. Troya, DAOP–ADL: an architecture description language for dynamic component and aspect-based development, in: F. Pfenning, Y. Smaragdakis (Eds.), Proceedings of the 2nd International Conference on Generative Programming and Component Engineering (GPCE), LNCS, vol. 2830, Erfurt, Germany, 2003, pp. 118–137. [32] J. Pe´rez, I. Ramos, J. Jae´n, P. Letelier, E. Navarro, PRISMA: towards quality, aspect-oriented and dynamic software architectures, in: Proceedings of the 3rd International Conference on Quality Software (QSIC), Dallas, Texas, USA, 2003, pp. 59–66. [33] A. Navasa, M.A. Pe´rez, J.M. Murillo, Aspect modelling at architecture design, in: R. Morrison, F. Oquendo (Eds.), Proceedings of the 2nd European Workshop on Software Architecture (EWSA), LNCS, vol. 3527, 2005, pp. 41–58. [34] M. Pinto, L. Fuentes, AO-ADL: an ADL for describing aspectoriented architectures, in: Proceedings of the 10th International Workshop on Early Aspect (EA), 6th International Conference on Aspect-Oriented Software Development (AOSD), LNCS, vol. 4765, 2007. [35] 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 9th International Workshop on Early Aspect (EA), 28th International Conference on Software Engineering (ICSE), Shanghai, China, 2006, pp. 3–10.

[36] L. Fuentes, M. Pinto, J. Troya, Supporting the development of CAM/ DAOP applications: an integrated development process, Software Practice and Experience 37 (1) (2007) 21–64. [37] N. Pessemier, L. Seinturier, L. Duchien, Components, ADL and AOP: towards a Common Approach, in: Proceedings of the International Workshop on Reflection, AOP and Metadata for Software Evolution (RAMSE), 18th European Conference on Object-Oriented Programming (ECOOP), 2004. [38] M. Aksßit, Systematic analysis of crosscutting concerns in the modeldriven architecture design approach, in: Symposium on How Adapatable is MDA? Twente, Enschede, The Netherlands, 2005. [39] P.A. Amaya, C.F. Gonza´lez, J.M. Murillo, MDA and separation of aspects: an approach based on multiple views and subject oriented design, in: Proceedings of the 6th International Workshop on Aspect-Oriented Modelling, 4th International Conference on Aspect-Oriented Software Development (AOSD), Chicago, Illinois, USA, 2005. [40] V. Kulkarni, S. Reddy, Separation of concerns in model-driven development, IEEE software 20 (5) (2003) 64–69. [41] C. Atkinson, T. Ku¨hne, Aspect-oriented development with stratified frameworks, IEEE Software 20 (1) (2003) 81–89. [42] L. Fuentes, M. Pinto, A. Vallecillo, How MDA can help designing component- and aspect-based applications, in: Proceedings of the 7th International Enterprise Distributed Object Computing Conference (EDOC), Brisbane, Australia, 2003, pp. 124–135. [43] D. Simmonds, R. Reddy, R. France, S. Ghosh, A. Solberg, An aspect oriented model driven framework, in: Proceedings of the 9th International Enterprise Distributed Object Computing Conference (EDOC), Twente, Enschede, The Netherlands, 2005, pp. 119–130. [44] I. Kurtev, M.D.D. Fabro, A DSL for definition of model composition operators, in: Proceedings of the 2nd Workshop on Models and Aspects – Handling Crosscutting Concerns in MDSD, 20th European Conference on Object-Oriented Programming (ECOOP), Nantes, France, 2006. [45] Object Management Group (OMG), MOF QVT Final Adopted Specification (ptc/05-11-01), 2005. [46] L.E. Chung, B. Nixon, E. Yu, J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, Dordrecht, 1999. [47] N. Loughran, et al., A domain analysis of key concerns – known and new candidates, Tech. Rep. AOSD-Europe Deliverable D43, AOSDEurope-KUL-6, Katholieke Universiteit Leuven, 2006. [48] A. Moreira, J. Arau´jo, A. Rashid, Multi-dimensional separation of concerns in requirements engineering, in: Proceedings of the 13th International Conference on Requirements Engineering (RE), Paris, France, 2005, pp. 285–296. [49] R. Chitchyan, A. Sampaio, A. Rashid, P. Sawyer, S. Khan, Initial version of aspect-oriented requirements engineering model, Tech. Rep. AOSD-Europe Deliverable D36, AOSD-Europe-ULANC-17, Lancaster University, 2006. [50] J. Hannemann, G. Kiczales, Design pattern implementation in Java and AspectJ, in: Proceedings of the 17th International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Seattle, Washington, USA, 2002, pp. 161–173. [51] J.M. Conejero, K. van den Berg, J. Herna´ndez, Disentangling crosscutting in AOSD: formalization based on a crosscutting pattern, in: XI Jornadas Ibe´ricas de Ingenierı´a del Software y Bases de Datos (JISBD), Sitges, Spain, 2006, pp. 325–334. [52] R. Laddad, AspectJ in Action: Practical Aspect-Oriented Programming, Manning Publications, 2003. [53] J. Fabry, T. Cleenewerck, Aspect-oriented domain specific languages for advanced transaction management, in: C.-S. Chen, J. Filipe, I. Seruca, J. Cordeiro (Eds.), Proceedings of the 7th International Conference in Enterprise Information Systems (ICEIS), vol. 1, Miami, Florida, USA, 2005, pp. 428–432. [54] J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufman, 1993.

L. Fuentes et al. / Information and Software Technology 50 (2008) 1248–1265 [55] E.B. Moss, Nested transactions: An approach to Reliable Distributed Computing, MIT Press, Cambridge, MA, 1985. [56] H. Garcia-Molina, K. Salem, Sagas, in: U. Dayal, I.L. Traiger (Eds.), Proceedings of the Annual Conference on Management of Data, ACM Press, San Francisco, California, USA, 1987, pp. 249–259. ¨ zsu, Using semantic knowledge of transactions [57] A.A. Farrag, M.T. O to increase concurrency, ACM Transactions on Database Systems (TODS) 14 (4) (1989) 503–525. [58] P.K. Chrysanthis, K. Ramamritham, A formalism for extended transaction model, in: G.M. Lohman, A. Sernadas, R. Camps (Eds.), Proceedings of the 17th International Conference on Very Large Data

1265

Bases (VLDB), Morgan Kaufmann, Barcelona, Spain, 1991, pp. 103– 112. [59] Rod Johnson, et al., The spring framework – reference documentation 2.0. [60] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W.G. Griswold, An overview of AspectJ, in: J.L. Knudsen (Ed.), Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP), LNCS, vol. 2072, Budapest, Hungary, 2001, pp. 327– 353. [61] O. Nierstrasz, T.D. Meijler, Research directions in software composition, ACM Computing Surveys 27 (2) (1995) 262–264.