Journal of Computing and Information Technology - CIT 14, 2006, 2, 111–131 111 doi:10.2498/cit.2006.02.03 From Composition Filters to AspectJ: A Platform SpecificModel Transformation Djamel Meslati1, Mohamed T. Kimour1 and Sa¨ıd Ghoul2 1 Laboratory of Research on Computer Science (LRI), University of Annaba, Algeria 2 Computer Science Department, Philadelphia University, Amman, Jordan Both model-driven architecture MDA and aspect- model that has the salient characteristic that it oriented programming AOP are promising paradigms can be executed by a machine 7, 16, 17 . that are very attractive for the software engineering com- munity. While the former is an approach to application A metamodel is a special kind of model that design and implementation using models as first class entities, the latter advocates the separation of concerns specifies the abstract syntax of a modeling lan- as an approach to tackle most software development guage. In the MDA context, each model is an and maintenance problems. MDA and AOP can be instance of a metamodel that is described us- related in various ways and their combination seems ing the OMG MOF Object Management Group to be a promising issue. In this article, we focus on the transformation of two AOP approaches, composition Meta Objet Facility19 . A transformation is filters CF and ASPECTJ, considered as platform specific the process that converts one model to another metamodels within the MDA context. We propose a model of the same system according to some transformation of CF models into ASPECTJ models using a syntax-directed translation and a set of transformation description which, in turn, is a model and an templates. In addition to being easy to implement, instance of some metamodel 14, 18 . our transformation approach covers the most important concepts of CF. Broadly speaking, MDA is an approach where models are first class entities 8, 14 . A software Keywords: aspect-oriented programming,ASPECTJ, com- system can be seen as a collection of models of position filters, model-driven architecture, model trans- formation. various abstraction levels where each describes the system from some viewpoint and, conse- quently, most engineering tasks can be consid- ered as modeling and transforming models. 1. Introduction In order to promote interoperability and porta- bility, the MDA approach puts the emphasis on Model-driven architecture is an approach to sys- two kinds of models with respect to specific tem development that provides means for us- platforms: the platform independent models ing models to direct the course of systems un- PIM and the platform specific models PSM . derstanding, design, construction, deployment, Within each of these abstractions, there can be a operation, maintenance and modification 18 . number of refinements for example, many lev- The core concepts of MDA are models, meta- els of platform independent models14 .For models and transformations. A model is a rep- example, a program is a PSM obtained through- resentation of a part of the function, structure out a cascade of models and transformations. At and or behavior of a system. A model spec- the top, we find a use case PIM that highlights ification can be formal when it is based on a aspects of the system corresponding to the user language that has a well defined syntax, seman- view. Then, the use case PIM is transformed tics and possibly rules to analyze its constructs to extract objects and classes which form an- 17 . Under this definition, a source code is a other PIM. The last transformation might be a 112 From Composition Filters to AspectJ: A Platform Specific Model Transformation JAVA model which is specific to a JAVA platform sibility, simplifies component integration and i. e. the JAVA virtual machine . Notice that a decreases invasive changes 2, 12, 20 . “platform specific” is meaningful only relative Today, a large amount of literature is devoted to a particular point of view 8 . For example, to three SOC approaches: composition filters the JAVA program is a PSM when considering a CF 5 ,ASPECTJ 12 and hyperspace ap- specific JAVA platform, while it is a PIM when proach 20 . They aim at providing better con- considering the specific operating systems on cepts and mechanisms to appropriately sepa- which the JAVA virtual machine is implemented. rate the software concerns from the business In the MDA approach, transformations can be logic. Unfortunately, each approach has its own of various types such as merging or composing philosophy and concepts. An approach might models, but usually they convert models offer- be suitable from some point of view, but in- ing a particular view from one level of abstrac- appropriate from another. Consequently, pro- tion to a less abstract one e.g. PIM to PSM or viding an environment where multiple AOP ap- PIM to PIM , by adding more details supplied proaches can be used simultaneously is a worthy by the transformation rules 14 . Transforma- goal. This article is an attempt towards this goal tions between models are needed because: that focuses only on the transformation of CF models to ASPECTJ models. Our interest in CF Metamodels use various modeling concepts and ASPECTJ results from the fact that they are and notations to highlight one or more views both AOP approaches. within a model, depending on what is rele- The remainder of this article is composed of vant at any point in time 18 . six sections. Sections 2 and 3 describe, re- Metamodels influence the modeling task and spectively CF and ASPECTJ metamodels in an the perception we have of the real world. intuitive way. In section 4 we give the motiva- Thus it is beneficial to use various metamod- tions of the work and in section 5 we present els to capture the real world subtle situations CF to ASPECTJ transformation. Section 6 dis- during the engineering tasks 8 . cusses related work, and section 7 conclusion and future work. According to “divide and conquer” princi- ple, the engineering tasks can be simpli- fied if complex system models are com- posed or merged from less complex models 2. The Composition Filters Metamodel using transformations that supply necessary details. 2.1. Principle and Goals In this article, we focus on the transformation of two AOP approaches, CF and ASPECTJ, by CF considers a system as a set of objects that considering them as two platform specific meta- interact with each other to achieve a common models within the MDA context. This work is a task. Most interactions are done by sending and part of an ongoing one that aims to construct an receiving messages and CF intervenes during MDA environment where software developers these interactions 3, 6 . It provides an object can use multiple AOP metamodels, during the with an interface containing filters that inter- engineering tasks, and freely switch from one cept and manipulate messages in various forms, another, using automated tools that preserve the modifying their scope and expected behavior. concerns’ traceability. The former consists of delegating messages to other objects i. e. changing the target object AOP is a particular separation of concerns ap- to which the message is sent, whereas the lat- proach SOC , where a system can be seen as ter consists of substituting a message selector composed of business logic and concerns such with another i. e. replacing the name of the as synchronization, security, persistence, etc. It method to be called with the name of another is now commonly admitted that an appropri- one to be called instead. By controlling mes- ate separation of concerns have an influence on sages changing their targets and or selectors the development and maintenance processes. It and through a well-constructed interface, CF reduces the software complexity and code tan- provides suitable solutions to many problems gling, facilitates reuse, improves comprehen- see 2 ,suchas: From Composition Filters to AspectJ: A Platform Specific Model Transformation 113 Dynamic inheritance by enabling and dis- Input filters: A set of declarative specifica- abling inheritance relation between classes tions that handle the incoming messages. at runtime Output filters: A set of declarative specifi- Modeling of state dependent behaviors where cations that handle the outgoing messages. the behavior of an object changes according to its state Object without filters History sensitivity where the behavior of an Received messages Control Flow object depends on its previous behaviors Kernel object Method Reference Providing multiple views of the same object Method Instance see example in 2.3 Variable Method Behavior coordination and synchronization Instance Variable Tracing of programs during the development One of the CF strengths is the use of a uniform Sent messages filtration mechanism to resolve the above prob- CF object lems. From this point of view, CF is easy to Received messages Input Filter understand and work with as it only adds few Input Filter CF Interface concepts to the object metamodel. Input Filter Kernel object Method Instance Variable 2.2. Basic Concepts Instance Variable Instance Variable Method Instance messages Delegated Variable CF adds to an object a wrapping layer called Method Internal Instance Object External interface that traps incoming and outgoing Internal Object Condition Variable InternalIt Object messages. Figure 1 depicts the contents of an Object External interface added to a kernel object. We refer to Condition Object object or class with a CF interface by CF object Instance Variable Instance Variable External respectively CF class . Instance Variable Object A CF interface is composed of the following parts: Output Filter Output Filter Internal objects are objects whose methods Output Filter Sent messages are used to compose the behavior of the CF object. Messages received by a CF object can be delegated to internal objects instead Fig. 1. An object before and after adding a CF interface.