Developing Aspect-Oriented Software Architectures: a Framework Definition

Transcription

1 2009 Fourth International Conference on Software Engineering Advances Developing Aspect-Oriented Software Architectures: a Framework Definition Amparo Navasa* Department of Computer Science University of Extremadura Spain amparonm@unex.es Miguel A. Perez-Toledano* Department of Computer Science University of Extremadura Spain toledano@unex.es Juan M. Murillo* Department of Computer Science University of Extremadura Spain juanmamu@unex.es Abstract. As the real world changes and evolves, software systems have to adapt in order to remain useful. For this reason, software engineers need techniques and tools which allow them to develop complex systems which are correct and easily adaptable. We here present a framework which provides the software engineer with a tool to design easily adaptable systems that evolve effortlessly. Changes are implemented from a structural point of view following the separation of concerns principle. We describe the characteristics of an aspect-oriented systems development model from an architectural viewpoint, a working methodology, and an aspect-oriented architecture description language. Keywords- AOSD, software architecture, AO Architecture, AO-ADL I. INTRODUCTION Managing complex software systems is one of the most important problems for software engineering to solve. Moreover, as the real world changes and evolves, software systems have to adapt in order to continue being useful. For this reason, software engineers need techniques and tools which allow them to develop complex systems which are both correct and easily adaptable. Several solutions have been considered. Some of them are based on the principles of Software Architecture (SA), Aspect-Oriented Software Development (AOSD), and Component Based Software Development (CBSD). Considering them jointly facilitates the development of complex systems. It is especially interesting to consider aspects 1 in software architecture. This is because AOSD is a technique that transparently and non-intrusively facilitates a system's evolution due to its application of the quantification and obliviousness principles [8]. This allows the architect to integrate software elements affecting several modules, without these needing to be prepared to make their composition possible. The suitability of the definition of an Aspect-Oriented (AO) architecture design appears when it is observed that crosscutting concerns traverse different architectural 1 In [7] an aspect is defined as a modular unit designed to implement a concern. * Quercus Software Engineering Group [17] This work is partially supported by the project TIN and GRU09137 (Junta de Extremadura). components, and the final design becomes complex. The present study provides proof of the usefulness of the combined use of these three disciplines. Aspect modeling at the architecture stage has captured the interest of the research community. That, and the treatment of crosscutting concerns at the architectural design level, formed the motivation for the present work. Two points of particular relevance in this area are: on the one hand, the development of models to facilitate the construction of complex systems that are better suited to frequent changes, so that systems become more modularized and maintainable; and on the other, the definition of AO Architecture Description Languages (ADL), because of the role they play in the formal representation of the design of complex systems. This definition allows for ensuring the correctness of the AO architecture that they describe, just as a conventional ADL provides appropriate support for reasoning about the properties of conventional architectures. The main goal of the present research was to provide the architect with a framework in which to develop complex software systems. This must integrate the definition and specification of the system as well as making its development process easy. This main goal was broken down into several specific targets: the definition of a model integrating the AOSD and CBSD approaches to the architectural design of software systems; the definition of an Aspect-Oriented ADL (AO-ADL) which will endow the architecture obtained with formal support after the proposed model has been applied; a methodological proposal to guide the software architect during the development process of AO systems; the definition of tools to aid the architect perform the tasks defined by this proposal; and the framework should be technology independent (here, technology is considered to be the relationship between hardware and the operating system). Since this study involved these three areas (SA, AOSD, and CBSD), a framework was defined to allow the insertion of aspects into the architectural definition of a system. It includes: (a) a model allowing one to specify AO software architectures (AOSA Model); (b) a methodological approach allowing one to extend the initial structure of a system by including new elements and connections. It covers several stages of the life cycle, and is applied iteratively. In addition, it guides the architect in the development process when the AOSA Model is used; (c) an AO-ADL, which was /09 $ IEEE DOI /ICSEA

2 defined to formalize and analyze software architectures; and (d) a toolkit to assist the architect and facilitate obtaining an AO-architecture, as well as executing the automatically generated prototype. The paper is structured as follows. In Section 2, the research is set in its context. Section 3 describes the framework and the constitutive elements. Section 4 briefly describes related work, and Section 5 presents some conclusions and some lines of future work. II. CONTEXT This research focuses on the architectural design and the following objectives must be achieved: - To provide an asymmetric AO model, in which architectural components of the system and aspects are considered as first class citizens but having different characteristics. - To formalize the design, using a conventional ADL which will be extended to enable it to support aspects. - To generates a validatable architectural specification, to enable verification when the appropriate tools are used. - To facilitate the evolution of existing systems. This will allow systems to be adapted to new situations or unanticipated changes by considering the new requirements as aspects. - To consider these aspects as components. This is a simple way of considering aspects at the architecture stage as well as allowing their use in different contexts. - New interactions will be external to the elements of the initial system. Thus, there is improved re-use of aspects. - To provide tools to help the software architect use the model. - To execute the automatically generated prototype (at early stages, the architectural design level). This allows one to check whether the system behaves as expected. To achieve the above goals, it was necessary to carry out an exhaustive study of software architecture as a discipline, and of the AOSD and CBSD approaches, as well as to use a coordination model. The application of coordination concepts represents the principal contribution of this research. After studying these issues, we obtained the needed knowledge to carry out the proposed work. In this section the characteristics of each are described briefly: 1) Software Architecture is the part of software engineering in which the system's structure is defined. It allows the system's complexity to be managed by considering it as a set of components and connectors. There is no denying the current interest in SA and its importance in the development of systems software. Several mechanisms have been proposed to describe architectures formally. One is the definition of an ADL. Which choose to express the architecture of a system will depend on the appropriateness of the characteristics of the language. Among the ADLs studied by our research group, LEDA [5] was selected as the most appropriate basis on which to define an AO-ADL. LEDA has a strong formal basis (picalculus), dynamic characteristics, and is translated into Java. This has the advantage of allowing the execution of a prototype from the architectural specification of a system, even if the components are not completely defined. From a study of this discipline, one can conclude that, it does not adequately address the problem of modeling the non-modularizable crosscutting properties (the crosscutting concerns), which are present in many systems. In [7], a crosscutting concern is defined as a property whose implementation is scattered over the system. The work done during the course of this research provided a solution to the issue of crosscutting concerns, considered from an architectural point of view. To address this task with some guarantee of success, it was necessary to make an in-depth study of the AOSD approach. 2) The AOSD approach examines how to deal with the non-modularizable crosscutting properties that are present in many software systems and during their process of development. Aspect-Orientation is a discipline that has attracted considerable interest from the research community. It covers all phases of the life cycle, facilitates the development of complex systems, and creates systems that are well-designed and easy to maintain. It is based on the principle of the separation of concerns, and provides techniques for the identification and extraction of aspects, as well as their subsequent composition. One can mention several advantages in the use of AOSD [2]: (a) improving the modularization of systems, allowing aspects to be encapsulated into independent modules and obtaining less tangled code; (b) promoting re-use; and (c) facilitating the adaptation of systems to unanticipated changes. Several models have already been developed following this philosophy: CAD/DAOP, AOSD/UC, Theme, Prisma, FAC, PCS, TranSAT Method, etc. (Most of them are described and analysed in [6]). Each has its own perspective, but generally does not provide enough support to cover all stages of development. Moreover, within the AOSD approach, it would seem logical to use an architectural description language to formalize the characteristics of software architectures. However, regular ADLs are poorly suited to expressing the characteristics of the crosscutting properties at the architectural level. Several works ([3] and [15] among others) have set out which features and requirements these kinds of language should have. In this sense, several AO-ADLs with different characteristics have been proposed: DAOP/ADL, Prisma ADL, FAC ADL, AspectualAcme, AO-Rapide, AO-PiLAR. They are compared and contrasted in [13]. 3) The third area underlying the present research is CBSD. Its objective is to address the development of large systems using techniques of software re-use, so that a system is defined as a set of interconnected components which are developed explicitly with a view to their composition, and which communicate via interfaces. To make their composition possible, the components must have been constructed following the same component model. 332

3 With CBSD, the final systems are given a more flexible structure. The present study maintains internally the principles of CBSD. However, the model's components do not have to be defined by any specific component model. The work which is described in the following sections is based on the three aforementioned cornerstones, and proposes the definition of an AO model, a methodological approach, and an AO-ADL which satisfy the criteria given above. Indeed, one of the reasons for carrying out the work was that we found no existing proposal satisfying those criteria. III. DESCRIPTION OF THE FRAMEWORK In this section, we shall describe the framework that was developed for the description of AO-systems from an architectural point of view. It comprises a model, a methodological approach, and an AO-ADL. Firstly, we shall present an overview of the structure of the architecture we propose, then the methodological aspects, the model and the AO-ADL that was defined. The framework defines the architectural structure of an AO-system in two levels (Figure 1): First of all, the base-level or component-level made up of the system components and their interactions. They define the initial system, into which the aspects will be inserted. For the sake of clarity, the bottom part of the figure shows only the two components (of the initial system) involved in the extension. Secondly, the meta-level or aspect-level contains the components to be inserted, as well as the necessary elements to establish the new interaction. The complex interaction between the initial system, in the base-level, and the aspects, in the meta-level, is represented schematically in the figure as a connector (the complex connector). Before defining in detail this complex interaction, first we shall describe the methodological stages leading to the definition of the AO system, then the characteristics of the model and its elements. Aspect-Level Aspect2 ClientComp Aspect1 Complex Connector Base-Level ServerComp AOSA Model. Schematic architectural representation. A. Methodological considerations This subsection describes the stages of the proposed method. 1 st Stage: Initial system specification The first stage methodologically is to consider the systems in terms of their requirements specification. This is done without taking the crosscutting aspects into account. The initial system is described by means of a use-case diagram (UML notation). Each use case is described so as to maintain the system properly documented. 2 nd Stage: Creating a design model for the initial system Once the initial system has been specified, the next task is to specify a design model for it and to describe its software architecture, expressed by an ADL. The task of creating the architectural description of a system can be divided into the following steps: S.2.1. In order to explain each use case in the diagram, the corresponding sequence diagrams are created. S.2.2. The design components appearing in each sequence diagram and the interactions between the components of the initial system are considered. S.2.3. The architecture is described formally by means of an ADL. As was mentioned above, we selected the LEDA ADL [5] as the most appropriate due to its allowing the execution of a prototype of the system. With these three steps, one has obtained the architectural description of the initial system. However, aspects (representing the new requirements to be inserted) have yet to be considered. 3 th Stage: Including a new requirement as an aspect After having described the architecture of the initial system, and as part of the incremental and iterative process which is proposed, we now need to redefine the system specification to be able to include new requirements (aspects) and thus obtain the new system. We propose redefining the architecture of the initial system in three steps: S.3.1. First, the aspects need to be defined, described, and specified considering the new requirements. Then they are added to the use case diagram (of the initial system) maintaining the obliviousness principle [8]. At the specification phase, aspects can be modeled as use cases extending the behaviour of the initial system: these are termed use case extensions [10]. Thus, the initial use case diagram is extended with use case extensions, each defined in association with one aspect. - The points where each aspect interacts with a use case are identified: these are the extension points. - How and when each aspect interacts with the system as well as the application conditions need to be described. I.e., for each extension point, one must determine: events triggering the execution of an aspect, execution conditions that must be satisfied, and when each aspect should be executed. 333

4 Instructions Component Extnddsyst { Component Instruction Contains the whole extended system. Composition Section Describes the elements comprising the extended system. Attachments Section Needed bindings are described (between aspect operations and the intercepted operations of components of initial Priority Section To assign the right priority of execution when more than one aspect is applied to an IP Instance Declaration To define the instance of the class representing the ext. syst. composition basesystem: System; pathfile_base_s ; counterroom: Aspect; pathfile_aspect1 ; countertable: Aspect; pathfile_aspect1 ; findroom:aspect: pathfile_aspect2 ; waitinglistroom:aspect; pathfile_aspect3 ; waitinglisttable:aspect; pathfile_aspect3 ; attachments basesystem.roomhandler.retrieveop(resroomhandler) <<RMS,NoAvail=True,after>> counterroom.countertop(); basesystem. Restauranthandler.Retrieveop(customerapp) <<RMS,NoAvail=True,after>> countertable.countertop(); basesystem.roomhandler.retrieveop(resroomhandler) <<RMS,NoAvail=True,after>> findromm.findroomop(); basesystem.roomhandler.request(resroomhandler) <<RMS,Full=True,after>> waitinglistroom.waitinlistop(); basesystem.restauranthandler.query(customerapp) <<RMS,Full=True,after>> waitinglisttable.waitinglistop(); priority counterroom>findroom; } instance extsys: Extnddsyst; Architectural description in AspectLEDA. S.3.2. For each use case extended with an aspect, it is necessary to describe how the integration will be done. For this, the associated sequence diagram is redefined. The new diagram contains components associated with the initial use case to be extended as well as the aspect or aspects to be injected. To manage the integration of aspects, we propose the inclusion of a new element: the Aspect-Manager component. It contains the aspectual components and manages their interaction with the initial system, i.e., it coordinates the interaction between the added aspect and the rest of the components involved in that scenario. The definition of the Aspect-Manager component has the advantage of allowing the transparent insertion of new requirements (considered as aspects) into the design components of the initial system. The inclusion of several aspects at different points implies the definition of several Aspect-Manager elements. 4 th Stage: Architectural specification of the extended system The next goal has to be to find a way to formally describe the extended system. A convenient tool is to use an ADL. The following are the steps we propose to achieve a description of the extended system in a suitable ADL: S.4.1. Describe the aspects crosscutting the system as architectural components. S.4.2. The extended system is described in an AO-ADL. In order to obtain an AO-ADL allowing the architect to formally express AOSD concepts (at the architecture level), we use an extension of LEDA ADL. This AO- ADL is denominated AspectLEDA [14]. Figure 2 shows the elements of the architectural description of a system in AspectLEDA. Four sections can be distinguished. 5 th Stage: Expressing the extended system in a regular ADL The architectural description of a system expressed in AspectLEDA needs to be translated into LEDA to make it possible to execute a prototype. A tool AOSA Tool/LEDA [11] has been developed to facilitate the translation tasks (Figure 3). 6 th Stage: Generating a prototype After the extended system has been expressed in LEDA, the formal properties of that language allow the architectural description to be translated into Java. Our research group has developed a graphical environment EVADeS [9] to facilitate the tasks of automatically generating Java code. This code can also be executed, so that one can obtain at design time a simulation of the AO system's behaviour. The formal basis of LEDA also makes it possible to demonstrate the properties of the extended system architecture, as well as verify its correctness. B. Separation of Concerns: A coordination problem After describing the stages of the method and the process of obtaining an AO architecture, we can now go on to describe our architectural model (the AOSA Model). It is based on a very simple idea: To consider the separation of aspects as a coordination problem. The reason behind it is that: 334

5 AOSA Tool/LEDA. On the one hand, the coordination concept proposes separating the interaction between elements. They also provide mechanisms for the reorganization and composition of these elements so that the system behaves as if nothing had been separated, and On the other, the separation of aspects concept proposes separating and extracting a certain code. It also provides mechanisms that enable the system to behave as if the extracted code had not been separated. A relationship can be established between the two concepts, and thus we can say that the separation of aspects, at the architectural level, has some similarities with coordination problems which are solved by applying coordination models. This relationship is evident when one considers that the specification of the aspects identified in the system crosscuts the specification of components, so that the interaction between these elements must be addressed in a different way. To establish the new interaction involves firstly, for each component, identifying the points where the aspects have been extracted or will be inserted: specification of the join points 2, and secondly specifying the connections between aspects and join points. In addition, these connectors need to describe the conditions for executing each aspect (when and how to apply them), and indeed will be responsible for managing the execution of the system extended with aspects. Therefore, we can deal with problems of separation of aspects as a matter of coordination. Coordination models 2 Join Points in [7] are defined as well-defined places in the structure flow of a program where additional behaviour can be attached. [1], in particular exogenous coordination models, can be used to manage the interaction between functional components and aspects. Specifically, the Coordinated Roles model [12] is an exogenous coordination model in which a coordinating entity is aware of the events that occur in the objects which it coordinates. And coordination is oblivious to coordinated objects. For this reason, and after studying coordination models in general and Coordinated Roles in particular, we would say that the characteristics of the separation of aspects, during the architectural design, can be managed as a coordination problem. This was applied in the definition of the AOSA Model, and is one of the distinguishing features of the model, and one of the main contributions of the present work. C. The AOSA Model Having shown the process of describing and creating a system extended with aspects, and how it is done by using a coordination model, in this section we shall present the characteristics of the proposed model. The AOSA Model [13] is a model for describing software architectures of complex systems, whether during the specification and design stages or during maintenance and evolution, when the AOSD approach is followed. Aspects are regarded as first-class entities, identified at early stages of development, during the maintenance or evolution of the system. AOSA model promotes re-use of aspects in different contexts, because they are defined independently of the system components into which they will be inserted. Aspects are regarded as architectural components, without the need to define new abstractions for their integration. Their interaction with the components of the system is transparent to the latter. * Structural elements of the system are components. One must distinguish: - Functional components of the initial system, regarded as black boxes which contain the semantics of the system and encapsulating their behaviour. - Aspectual components define the structure and behaviour of some concern, crosscutting several architectural components, and encapsulating their operability. Point cuts 3 have to be located in the public interface of these architectural components. * Interaction between the elements of the architecture that defines the model is represented in two ways: - Connectors which are defined between the components (their interfaces) of the initial system. These connections remain the same when the system is extended with aspects, except for those connectors associated with the points where insertions will be made. These are broken and it is necessary to define new ones. - New connections that must be established to link the components of the initial system with the aspectual components. The relationship between the two kinds of 3 Pointcut in [7] is defined as a set of join points. 335

6 component leads us to define a composition relationship (weaving process), and includes several elements (components and connectors). * The process of weaving 4 in the AOSA Model is based on the definition of join points, point cuts, and the corresponding advices 5. Moreover, conditions of weaving are specified outside of components and aspects, to thereby preserve context independence. This specification determines when the detection of an event on a component should trigger the execution of an aspect. A single event can trigger the execution of more than one aspect. * The semantics of weaving for each aspect is defined by a coordinator component, proposed by the model. The invocation of a service is intercepted by this component, and at run-time it determines whether the conditions for the execution of the aspect (to which is associated) are satisfied. In this case, the coordinator synchronizes the execution of the components that it communicates. As a result, aspects are context independent and reusable. On the contrary, coordinators are dependent on the system context where aspects are inserted. * Composition is done dynamically at run time, depending on the rules defining the aspectual behaviour in the context, but external to it. Components and aspects remain ever separate. The coordinator manages the composition when, at run time, it knows the value of conditions determining the aspects' execution. Composing more than one aspect on the same pointcut makes relationships more complex. It is then necessary to prioritize the aspects' execution. After this description of the model's characteristics and the interaction it proposes, the next step is to present in detail the architectural structure indicated at the beginning of this section, i.e., the elements constituting the aspect- or meta-level. Meta-level structure Figure 4 shows the elements of the meta-level structure. Now the interaction, represented in Figure 1 as a connector, is explicit in the representation of the components which manage that communication. The structural definition of a system extended with aspects comprises the following elements: - The initial system which consists of all of its components plus the connections between them. The AOSA Model assumes it to be specified before extending it with aspects. This is termed the base-level. - The aspect-level is superimposed on the base-level. It consists of: a set of aspectual components, which will be inserted into the initial system; several coordinators, which manage the interaction between components of initial system and the aspectual components; and a component (Blackboard) which provides the services of reading and 4 Weaving is the process of composing core functionality modules with aspects. 5 Advice is the behaviour to execute at a join point. writing on a structure defined as a "blackboard" to which the coordinators have access. BB : BlckBrd Intercept Cl : Client MC : Metacoordinator Provide Initial System Coordinators Coordinator Aspects Serv : Server The AOSA Model, architectural structure. A2 : Aspect A1 : Aspect Aspect-Level Base-Level Besides the connections between components of the initial system, new connections between these components and the aspect-level need to be established. Thus, the metalevel (aspect-level) acts on the base-level to modify the initial system's behaviour. Detailed description of the meta-level This subsection describes the meta-level elements. - Set of aspects. Aspects to be injected in the system are described as design components. To later include them effectively, it is necessary to store all the information associated with them and their execution. - Insertion Point (IP). This concept allows a relationship to be defined between, on the one hand, the design component that executes the operation represented by an extension point 6 and, on the other, the aspect that intercepts the service. Each IP is defined by the following properties: one extension point (associated with one or more aspects); the name of one aspectual component, which executes an advice and extends the system's behaviour; and the name of a design component whose execution will be intercepted at the service associated with the extension point. The insertion point concept is close to that of the join point, but at a higher level. - Common Items Structure (CI). This is a structure defined to store the information needed to know how to generate the specification and design of the system extended with aspects. This information is deduced during the process of constructing the new system. It reflects the associations between components of the initial system and aspectual components, as well as their conditions of application. - Set of rules. This describes the characteristics of the interaction between system components and aspectual components. The rules define the actions to be executed to apply these aspects according to the conditions that must be satisfied. They are deduced from the information stored in the CI structure. - Control Process (CP). This manages the coordinated execution of the extended system, taking into account the information in the rules. Specifically, CP coordinates the 6 Extension Point: point in a use case extending its behaviour. 336

7 execution of the components affected by the events that are triggered and each aspect associated with them. A coordination model manages this coordinated execution. Because the extended system can be complex when there are many aspects to be included, CP comprises several coordinators, one for each design component having an Insertion Point. A coordinator can manage several aspects associated with the same IP. The behaviour of a coordinator is defined by the rules that are checked by another component: the MetaCoordinador. The behaviour of a coordinator is established from the information in the CI structure and the set of rules. The MetaCoordinador (MC) is defined as an architectural component, the only one that is system-wide. It really is a coordinator of coordinators. It has been defined as a necessary entity that monitors the global state of the system and is able to check the conditions in full. Furthermore, in complex systems, information associated with several events which have been triggered and written on the Blackboard component by different coordinators remains in this structure until MC has finished dealing with the events which had been written previously. - Blackboard is a component which manages, at runtime, the storage of the information associated with the events that have been triggered and that have not yet been addressed. Removing aspects Finally, after a system has been specified and designed, it might be necessary to eliminate or change some of its requirements. The AOSA Model allows this: To remove a requirement added previously as an aspect when following the AOSA Model, the corresponding elements must be withdrawn from the aspect-level as well as their associated information, and the connections which had been intercepted must be restructured. D. AspectLEDA This subsection briefly describes the AO-ADL AspectLEDA. As described in [14] and [11], it is an ADL that allows the integration of aspects transparently into a system described in a conventional ADL such as LEDA. The integration is done following the AOSA Model and according to the characteristics of the aspects to be injected. Its definition endows the definition of AO-architectures with formal support. It was designed as the extension of an ADL, preserving its formal characteristics. After describing the architecture of an AO system in AspectLEDA, the architectural specifications written in it are recognized and validated by a parser. Since the architecture of the initial system to be extended is described in LEDA, a LEDA analyzer is used to recognize the elements making up the extended system. After translating the architectural specification in AspectLEDA into LEDA, the formal basis of this ADL (picalculus) make it possible to demonstrate the architectural properties of the extended system. One can thus obtain a formal specification of the system which can be used as input for tools that allow the validation of the generated architecture. The process of generating a prototype of the architecture of an AO system can be done using tools we developed: AOSATool/LEDA and EVADeS: a) AOSATool/LEDA [11] facilitates the tasks of translating an architecture expressed in AspectLEDA into an equivalent architecture in LEDA. The resulting architectural description can be modified, refined, or corrected using this tool. Throughout this process, there is the appropriate detection of errors in the code of the architectural description (AspectLEDA and LEDA). The consistency between the data of the two descriptions is also checked. b) The EVADeS tool [9] facilitates the translation of LEDA code into Java when executing the LEDA interpreter. To this end, elements describing the LEDA architecture are converted into Java classes. The generated code can also be modified, refined, and completed using this tool. Finally, a prototype of the system can be obtained when the Java interpreter is invoked. After execution of the architecture (the generated prototype), it is possible to evaluate whether the system behaves as expected or not. This allows one to detect errors that otherwise would only be found at later stages. In this sense, it is particularly interesting to detect errors in the architectural description when several aspects are injected at the same insertion point, and thus establish the appropriate priority in their execution. Validating the architecture Throughout this work, the initial system specification has been assumed correct, and the system architecture was built on its basis. Nevertheless, this assertion should be checked by carrying out a validation process of the system's specification, expressed in UML. Validation ensures that the system behaves as the designer expected it to do. Our research group has carried out several studies on validating specifications [16], whose results can be used in this framework. Therefore, at different times throughout the process described in the present article, several validation tasks were performed. IV. RELATED WORK This section briefly reviews some other work in the area of software architecture and AOSD, and its relationship with the framework that has been presented here. Our study of the literature in the area of SA showed the interest in this discipline for software development, in particular in the use of ADLs for the formal description of systems. We have studied several of them (Darwin, Unicon, ArchJAva, Wright, LEDA, C2SADL, Rapide, PiLar, ADML, among others). We concluded that each of them is interesting for application in certain domains, and that they all have their advantages and disadvantages. However, none of them allow the architect to model the (non-modularized) crosscutting concerns present in certain systems. It was necessary therefore to study other models and ADLs which do take this kind of property into account. 337

8 Thus, in the area of AOSD, we studied several models that address the characteristics of crosscutting concerns. Each has its own specific characteristics and emphasis on certain stages of development. We would mention: MDSoC and AOSD Use Cases, which are oriented to requirement specification; and Theme, PCS, CAD/DAOP, PRISMA Model, and TranSAT Method, which lay especial stress on architectural characteristics. Within the AOSD approach, it would seem natural to use ADLs to formalize the characteristics of the software architecture of AO systems. But conventional ADLs are poorly suited to expressing crosscutting concerns at an architectural level. For this reason, several AO-ADLs have been proposed, each with its own characteristics. However, there was lacking an architectural model that met all of the following criteria: asymmetry (greater ease of use), considering aspects as components, defining the interaction externally to the system components, supported by a formal LDA, having tools available to facilitate its application, allowing a validatable architecture to be generated, and generating an executable prototype. This, in sum, was the motivation for the present work. V. CONCLUSIONS AND FUTURE WORK The complexity of current software systems and the constant demand for changes to be made to them are challenges that software engineers need appropriate tools, techniques, and models to face. SA, AOSD, and CBSD both facilitate the development of complex systems and simplify their maintenance and evolution. In this work, we have shown how useful it can be to combine these three disciplines, presenting a practical framework consisting of an AO architectural model, the methodology for using the model, an AO-ADL (which expresses formally the system's architecture), and a toolkit. The application of the concepts of SA, AOSD, and CBSD, together with the use of a coordination model (Coordinated Roles) constitute the main contribution of this research: to reduce the problem of the separation of aspects at design time to one of coordination. The appropriate use of the framework needs to bear in mind certain prerequisites. For example, throughout the entire process point cuts are taken to be located at the interface of components (which are defined as black boxes). In addition, aspects to be inserted into the initial system are assumed to be mutually independent. We are currently finishing the development of a new AO-ADL, AAJ, which extends ArchJava. The new language has similar characteristics to AspectLEDA. Preliminary conclusions concerning AAJ have been presented in [4]. A tool, AOSATool/AAJ facilitates the software architect's tasks in describing the architectures of AO systems. Another study nearing conclusion is a comparison of the Java code generated by the two AO-ADLs we developed. The results so far show that the Java code generated by LEDA is better and more efficient than that generated by ArchJava. The next step will be to compare the results of applying our framework versus those obtained from applying other proposals. We are also considering a possible extension of AOSATool/LEDA so that it will be possible to automatically translate a LEDA specification into pi-calculus. This would include the development of a working environment to facilitate the validation and testing of the architecture generated. REFERENCES [1] Arbab,F., What Do You Mean Coordination? Bulletin of the Dutch Association'96. LNCS Springer-Verlag. Cesena. April [2] Aspect Oriented Software Development homepage [3] Batista, T., Chavez, C., García, A., Kulesza, U., Sant Anna, C., Lucena, Aspectual Connectors: Supporting the Seamless Integration of Aspects and ADLs. Proceedings of the ACM Sigsoft. XX Brazilian Symposium on Software Engineering (SBES 06) Florianópolis, Brazil. October, 2006 [4] Botón, M., Navasa, A. AAJ: Un Lenguaje de Descripción Arquitectónica Orientado a Aspectos. XIII Jornadas de Ingeniería del Software y Bases de Datos 08. Gijón, Spain. October, [5] Canal, C, Pimentel, E., Troya, M. Compatibility and Inheritance in Software Architecture. Review Scene and Computing Programming. vol 41 no. 2, pp [6] Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Pinto, M., Bakker, J., Tekinerdogan, B., Clarke, S., Jackson, A. Report synthesizing state-of-the-art in aspect-oriented requirements engineering, architectures and design. Lancaster University, Lancaster, AOSD-Europe Deliverable D11, AOSD-Europe-ULANC-9. May, [7] Filman, R. et al. Aspect Oriented Software Development. Addison Wesley [8] Filman,R.E., Friedman,D.P. Aspect-Oriented Programming is Quantification and Obliviousness Workshop on Advanced Separation of Concerns. OOPSLA 2000, USA. [9] Garcia, C., Navasa, A. EVADeS: Un Entorno Visual de Asistencia al Desarrollo de Sistemas en LEDA. TR-30/2008 University of Extremadura [10] Jacobson, I., Ng Pan-Wei. Aspect-Oriented Software Development with Use Cases. ISBN: Addison Wesley [11] Merín, I, Navasa, A. AspectLEDA: Un Lenguaje de Descripción Arquitectónica Orientado a Aspectos. TR 31/2008. University of Extremadura [12] Murillo,J.M., Hernandez,J., Sánchez,F., Alverez,L. Coordinated Roles: Promoting Re-Usability of Coordinated Active Objects Using Event Notification Protocol. Coordination Proceeding, pp53-68, [13] Navasa, A. Pérez-Toledano, M. A., Murillo, J. M. An ADL dealing with aspects at software architecture stage. Information and Software Technology, 51 (2009) pp [14] Navasa, A., Perez, M. A., Murillo, J. M. Aspect Modelling at Architecture Design. EWSA LNCS 3527, pp , Ed. R. Morrison and F. Oquendo. Springer Verlag. Berlin Heidelberg. ISBN: X [15] Navasa, A., Pérez, M. A., Murillo, J. M., Hernández, J. Aspect Oriented Software Architecture: A structural Perspective. WS on Early Aspect. AOSD Conf Enschede Holland. utwente.nl/aosdearlyaspectsws/works hop_papers.htm. [16] Pérez-Toledano M. A., Navasa, A., Murillo, J. M., Canal, C. A Safe Dynamic Adaptation Framework for Aspect-Oriented Software Development. Journal of Universal Computer Science. Special Issue on Practical Approaches to Software Adaptation. September, [17] Quercus Software Engineering Group ercusproy/ 338