ASPECT GENERATOR. Audit Trail WEAVER. Aspect Editor. Weaving Strategies Editor. Model Editor. Mapping. Instructions. Original Model (XMI)

Transcription

1 Tool Support for Aspect-Oriented Design Francois Mekerke 1, Geri Georg 2, Robert France 3, and Roger Alexander 3 1 Ecole Nationale Superieure des Etudes et Techniques d'armement, Brest, France mekerkfr@ensieta.fr 2 Agilent Technologies, Fort Collins, USA geri georg@agilent.com 3 Colorado State University, Fort Collins, USA ffrance,rtag@cs.colostate.edu Abstract. In this paper, we describe the tool we plan to build in order to show the feasibility of aspect-oriented design, and demonstrate the advantages that it implies. This technique allows one to independently specify cross-cutting concerns and functionnal features of a system. The tool would then allow the weaving of the aspects on the model one after the other, creating a design model that would comply to all specications, with additionally a high-quality architecture. Introduction Aspect-oriented design (AOD) localizes cross-cutting concerns to better manage design evolution and to enable reuse of these aspects (e.g. security or fault tolerance aspects) in multiple systems. A comprehensive system model can be obtained byweaving the model of essential functionality with aspect models. Design aspects allow one to understand and communicate cross-cutting concerns in their essential forms, rather than in terms of a specic system's behavior. Design aspect are also potentially reusable across dierent systems since they are not tied to any particular system. Policies and procedures intended to be applied across multiple systems can be expressed using aspect designs. Changes to any particular concern are made in one place (the aspect design), and eected by weaving the changed aspect into the models of essential functionality. This eases the management of design changes. Anumber of authors have tackled the problem of dening and weaving aspects at the design level (e.g. [1], [2], [6]), but many of these approaches essentially result in wrapping additional functionality around an existing model by taking advantage of regular expression matching between aspect model elements and primary model elements. Therefore, the proper model factoring must already exist in order to apply the aspect in these cases. By contrast, our method of dening aspects using role models and weaving them into essential functionality through template as well as extension mechanisms is more exible and therefore fewer constraints need to be placed on the models they are woven into.

2 1 Background 1.1 Role Models We use the concept of Role Models (see [5], [4]) to dene aspects in an application-independent manner. Aspect properties are dened in terms of roles that can be played by model elements representing application-specic concepts. A model element conforms to a role if it possesses the properties dened in the role. Weaving an aspect dened by Role Models is essentially a model transformation process in which a non-conforming model is transformed to a conforming model (i.e., a model that incorporates the aspect). One can view a Role Model as a characterization of model element structures that incorporate the aspect. The UML is used as the design modeling notation in our work, thus the Role Models we developed are property-oriented characterizations of conforming UML models [5], [4]. A UML model element (e.g., a class or an association) that has the properties specied in a role can play the role, that is, it conforms to (or realizes) the role. A UML model is said to conform to (or realize) a Role Model (i.e., is a realization) if it consists of model elements that conform to the roles in the Role Model. A design aspect (e.g., a security concern) can be modeled from a variety of perspectives. In our initial automated tool work, we focus on one aspect view (static) although we generally dene an aspect using two views (static and interaction views). An aspect's static view (a Static Role Model, or SRM), focuses on the structure of the aspect. The interaction view (the Interaction Role Model, or IRM), focuses on the interactions that take place within the aspect. To facilitate weaving, Role Models are constructed in a manner that allows one to generate conforming structures from them. Weaving a Role Model into a UML model M, can involve (1) merging roles with model elements M, that is, modifying model elements in M so that they conform to the roles and (2) generating new model elements from roles and inserting them into M. 1.2 An Overview of SRMs An SRM consists of classier and relationship roles. Each role has a base that restricts the type of UML construct that can play the role. In general, association roles havemultiplicity constraints expressed as templates of the form [[n]], where n is constrained to be a range or a specic value. Multiplicities in a realization of a SRM containing these template forms can be obtained by substituting values for n that satisfy the constraints. Each role denes properties that conforming constructs must possess. Two types of properties can be specied in a SRM role: Metamodel-level constraints are well-formedness rules that constrain the form of UML constructs that can realize the role, and Feature roles characterize properties that must be expressed in the conforming model elements. Metamodel-level constraints are constraints over the UML metamodel expressed in the Object Constraint Language (OCL) [7], [8]). For example, a metamodel-level constraint in a class role can constrain

3 conforming classes to be concrete with a class multiplicity that cannot exceed a value m. For examples of their use see [4]. Feature roles are associated only with classier roles. There are two types of feature roles: Structural roles specify state-related properties that are realized by attributes or value-returning operations in a SRM role realization, and behavioral roles specify behaviors that can be realized by a single operation or method, or by a composition of operations. A feature role consists of a name, and an optional property specication expressed as a constraint template (omitted in the examples given in this paper). Realizations of a feature role have properties that imply the property generated by appropriately instantiating the feature role's constraint template. For example, each behavioral role is associated with pre- and post- constraint templates that, when instantiated, produce pre- and post-conditions that must be implied by the pre- and post-conditions of realizing operations. (See [3] for examples of aspect models with behavioral roles.) In summary, a model element conforms to a role if: (1) it satises the metamodel-level constraint and (2) the constraints associated with its features imply the constraints obtained by appropriately instantiating the role's constraint templates. 1.3 Weaving Aspects into a Design Model Weaving an aspect into a model involves identifying existing elements in the models of essential functionality that can play aspect roles. Weaving rules can add new elements, extend, or change existing elements so that all required roles in the aspects are present in the woven model. Weaving an aspect into a model involves: 1. Identify existing model elements that can play the aspect roles or can be modied to play aspect roles. This activity is carried outby the developer. 2. If no existing model element can play an aspect role, then a new model element is generated from the Role Model and added to the model of essential functionality. This is accomplishedin the following manner: { Create an instance of the role base that satises the metamodel-level constraints. { For each structural role, generate an attribute and associated constraints by substituting a name for the role name, and substituting conforming values for the template parameters of the constraint templates. { For each behavioral role, generate an operation and associated constraints by substituting a name for the role name, and by substituting conforming values for the template parameters for the pre- and postcondition constraint templates. 3. Modication of existing model elements may be necessary if they are to play the roles. Modication can involve adding new features (attributes or operations) to classes, changing association multiplicities, or moving features out of one construct and placing it in another. The required changes can be identied by matching the model elements with an appropriately instantiated form of the SRM.

4 2 Tool Design 2.1 Objectives Our nal objective is to provide tool support for aspect-oriented design, in order to allow developers to model their system with more ease. The advantages of using aspect-oriented design are the following: { Simplied and systematic specication phase, through support for the separation of concerns principle: Architects can specify each cross-cutting concern independently of essential functionality. { Potential automation of the integration of multiple concerns (weaving): A comprehensive architecture can be obtained by automatically weaving the aspects, one after the other, into the core functionality. { High-quality architecture, through use of aspect patterns based on highquality experience: Aspects can be used to create recognisable architecture, which are easier to understand. 2.2 Description of the tool The architecture of the tool is illustrated in Fig. 1. In the diagram, ovals represent data, rectangular boxes represent subsystems, and grayed boxes/bubbles represent elements that are out of the scope of our present eort. Model Editor Weaving Strategies Editor Aspect Editor Original Model (XMI) Weaving Strategies Aspects Library Mapping Instructions ASPECT GENERATOR Mapping Rules Audit Trail Use Cases WEAVER Woven Model EVALUATOR Evaluation Results Fig. 1. General Architecture

5 The user must dene the following inputs: { An Original Model into which aspects will be woven (XMI format, created by anmodel Editor) { An Aspect (created by anaspect Editor 4 ), stored in an Aspect Library { Weaving Strategies (created by a Weaving Strategy Editor), which describe what aspects to weave into the model in particular conditions { Mapping Instructions, which dene a correspondance between the roles of the aspect and the elements of the Original Model that are intended to play the roles. These inputs are processed in two subsystems: { An Aspect Generator creates a le dening the Mapping Rules that determine how the weaver will incorporate an aspect into a primary model { A Weaver, which modies the primary model, using the aspect. The result is a Woven Model whose properties are tested in a Model Evaluator. 2.3 Aspect Generator The Aspect Generator is certainly the part of the tool that is the most dicult to conceive, since it has to collect data concerning the aspect and process them to produce a le containing mapping rules. The elements needed as inputs for the aspect generator are: { Analyzable forms of Role Models { Mapping instructions that describes which classes of the model play the roles dened in the aspect { Weaving Strategies used to select and compose aspects. 2.4 Weaver The Weaver takes the Original Model and the Mapping Rules le generated by the Aspect Generator as inputs. It then processes those two les in order to provide the Woven Model and an Audit Trail. During this operation, the Weaver must preserve all the features of the original model, and add the features required by the aspect, which include new attributes and operations, but also new objects, thus new architecture. 4 The Aspect Editor can be the same tool as the Model Editor as long as XMI descriptions of aspects can be dened

6 In order to fulll its missions, the Weaver must support the following operations: { Create/delete an object or an attribute in a given context { Migrate attributes or operations from one class to another { Link a new object to the existing architecture. For this, it will need to be able to compare the structures of both the Aspect le and the Original Model, to evaluate if the features of the model elements conform to the aspect, to add missing features and modify existing elements that do not conform to the aspect roles. In order to have traces of what has been implemented (and then have the possibility to undo some operations), the Audit Trail records every operation performed by the Weaver and the Aspect Generator. 2.5 Evaluator Once the Woven Model has been created by the Weaver, the Evaluator tests it, in order to : { check itsinternal consistency { detect potential emergent properties { identify aspects conicts. The evaluation is performed by applying scenarios (described in Use Cases) to the Woven Model. These scenarios are system-specic, and should be chosen in such a way that all features of the system are tested in realistic situations. The Evaluation Results may be analysed to determine whether or not the system really meets the expectations of its architects. Conclusion As some of the concepts that we intend to integrate in the tool are not yet clearly dened, we have chosen to develop it incrementally and iteratively. We have thus begun with the building of a Weaver, which compares a hand-made Mapping Rules le and a Model, and modies the structure of the Model so that it complies to the Mapping Rules specications. The Aspect Generator and the Evaluator, which are the next steps of the development of the tool, are currently in the study phase, and should enter soon in the building phase.

7 References 1. S. Clarke, W. Harrison, H. Ossher, and P. Tarr. Separating concerns throughout the development lifecycle. In Proceedings of the third ECOOP Aspect-Oriented Programming Workshop, S. Clarke and J. Murphy. Developing a tool to support the application of aspectoriented programming principles to the design phase. In Proceedings of the International Conference on Software Engineering (ICSE), R. France and G. Georg. Modeling fault tolerant concerns using aspects. submitted to ISSRE02, R. B. France, D. K. Kim, and E. Song. Patterns as precise characterizations of designs. Technical Report , Computer Science Department, Colorado State University, R. B. France, D. K. Kim, E. Song, and S. Ghosh. Using roles to characterize model families. In Proceedings of the Tenth OOPSLA Workshop on Behavioral Semantics: Back to the Basics, J. Suzuki and Y. Yamamoto. Extending UML with aspects: Aspect support in the design phase. In Proceedings of the third ECOOP Aspect-Oriented Programming Workshop, The Object Management Group (OMG). Unied Modeling Language. Version 1.4, OMG, September J. Warmer and A. Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, 1999.