Using Aspect-orientation Techniques to Improve Reuse of Metamodels

Using Aspect-orientation Techniques to Improve Reuse of Metamodels A. M. Reina Quintero J. Torres Valderrama Department of Languages and Computer Systems University of Seville Seville, Spain Abstract Metamodelling is an activity that attracts attention of the research community dealing with the ModelDriven Development (MDD). To be reusable in different MDD approaches a metamodel should be unaware of being extended by another metamodel. This property of metamodel is called obliviousness. This paper shows that current techniques implementing metamodels do not maintain obliviousness when some elements of the extended metamodel and the elements of the original model have association relations. Three different approaches to reuse of metamodels are analyzed. One of the approaches uses traditional object-oriented techniques. Two other approaches use aspect-oriented techniques. The paper shows that the third approach, which considers relationships as first-class citizens at the implementation level by using relationship aspects, guarantees obliviousness of metamodels. Keywords: Metamodelling, Aspect-Oriented Programming, Model-Driven Architecture. 1 Introduction Model Driven Development (MDD) is supported by two main approaches: Software Factories (SF) [11] promoted by Microsoft and Model Driven Architecture (MDA) [19] promoted by the Object Management Group (OMG) [16,5]. The Software Factories approach proposes the use of extensible and configurable tools to automate the development and maintenance of different software product families. The automation is obtained by means of the composition and configuration of different components. Thus, the Software Factories approach integrates multiple activities and techniques. One of these activities is the development of various modelling languages and domain specific tools. This work has been partially supported by the Spanish Ministery of Science and Technology and FEDER funds: TIC-2003-369. The Model Driven Architecture approach is based on the modelling standards proposed by the OMG: the Unified Modelling Language (UML) [22]andtheMeta Object Facility (MOF) [20]. MDA proposes a framework composed of different levels of modelling: Computation Independent Model (CIM), Platform Independent Model (PIM), and Platform Specific Model (PSM) and model transformations. Thus, the models and transformations have become the first-class citizens. Figure 1 shows a MOF diagram of the main elements of the MDA approach. Model Transformation CIM PIM PSM Code Metamodel 1..* 1 conformsTo source target 1..* 1..* Fig. 1. Metamodel of the MDA approach In addition to the CIM, PIM, PSM and transformation, Figure 1shows another important element of MDA: a metamodel. A metamodel is a special kind of model which describes an abstract syntax of another model. So, the metamodel have become the key elements for both MDD approaches. In this context it is very promising to define and implement metamodels that can be reused [2]. Catalysis method [7] introduces two mechanisms of metamodel reuse: the package extension and the package template mechanism [4]. In this paper we focus on the package extension mechanism. Metamodel MMA extends metamodel MMB if MMA specializes MMB. Thus, any of the elements of the MMA metamodel has a relationship with any of the elements of the MMB metamodel. This mechanism allows defining the MMA and MMB metamodels separately, and merging them together. In order to improve reuse of metamodels it is important to maintain the obliviousness, i.e. the unawareness of MMB about MMA. We have analyzed three different approaches to implementation of metamodels in order to understand if they maintain the obliviousness of metamodels. The first approach uses inheritance to make the original metamodel oblivious so that the problem is solved with traditional object-oriented techniques. The second and third approaches are based on aspect-oriented techniques [9,10]. The second approach introduces inter-type declarations, while the third one treats the relationships in metamodels as aspects [23]. In this paper we show that the third approach guarantees obliviousness of metamodels which facilitates metamodel reuse. This paper is structured as follows: section 2introduces the main metamodelling concepts. In section 3 the Eclipse Modelling Framework for implementing models and metamodels is presented. Section 4presents the problems that arise when metamodels are extended. Section 5analyses three different approaches to extension of metamodels. Section 6 draws conclusions from the analysis. 2 Metamodelling Accordingto[15] a metamodel is a precise definition of the constructs and rules needed for creating semantic models. Metamodelling is a way to organize related models. The OMG defines four different levels of modelling [14]. Figure 2shows a scheme of the relationships among the levels M0, M1, M2 and M3 defined by the OMG. The MOF is placed on the top of the hierarchy, and it is used to define itself; therefore, the level above MOF (M3) can be seen as the MOF itself. The UML is at level M2. The abstract syntax of the UML has been described using the MOF. An instance of the UML metamodel can be seen as a class diagram (level M1). An instantiation of a class diagram is an object diagram (Level M0). M1: System Model M2:(Meta-model) M0: System M3: (Meta-meta-model) +name MOF Class -name UML Class -name UML Attribute -title -name Customer -name -number Order title = "Dr" name = "John Doe" Objeto1 : Customer title = "Dr" name = "Frank Else" : Customer name = "Something" number = "12345678" : Order <<instance of>> <<instance of>> <<instance of>> <<instance of>> <<instance of>> <<instance of>> <<instance of>> <<instance of>> <<instance of>> Fig. 2. The four layer metamodel architecture proposed by the OMG The metamodel repositories can be classified in two main groups: •The MOF-based ones.TheMOF[20] is the metamodelling framework proposed by the Object Management Group (OMG) to define other modelling frameworks. The MOF specification is vendor and language independent. With the MOF specification, the OMG has standardized a set of mappings that specify how a specific technology represents and manages meta-data. For instance, XMI [21]is a XML representation for model interchange between tools, while JMI [25]isan abstract syntax definition for meta-data in Java applications. Some repositories that implement the JMI interface are: MDR from NetBeans [17]orNSMDF[18] from NovoSoft. The Coral Metamodelling Framework [24] has the hard coded MOF, although other different metamodels can be installed. Coral is not based on Java, but on Python. •The Ecore-based ones. Ecore is the metamodel included in the Eclipse Modelling Framework (EMF) [3]. It is different from MOF. EMF is a low-cost tool to obtain the benefits of formal modelling and Java code generation and it is language-dependent. The functionality of EMF is similar to MDR. 3 Eclipse Modelling Framework (EMF) The Eclipse Modelling Framework (EMF) [3] is a modelling framework for Eclipse. EMF is, on the one hand, a framework, and, on the other hand, a facility for defining a model in one of the following forms: Java interfaces, UML diagrams or XML Schemas. Ecore is the metamodel that uses EMF to represent models. Ecore is itself an Ecore model, and it is of the same OMG level (Figure 2)asMOF. Figure 3depicts different sources of a core model. Core Model Core Model UML Model XML Schema Other Java Code + Annotations Java Code + Annotations Fig. 3. Sources of a Core Model There are four basic metaclasses to represent an Ecore model: EClass,EAttribute,EReference and EDataType. •EClass models a class. It has an attribute called name to store the name of the modelled class. It has composition relationships with EAttribute and EReference. The cardinality of the composition means that an EClass can have zero or more attributes and zero or more references. •EAttribute models an attribute. It has an attribute (name) and an association with EDataType. The association represents that an attribute must have a type. •EReference models one of the two ends of an association between classes. It has two attributes: name and containment. The attribute containment is true if the association end represents a composition relation. Finally, EReference has an association with EClass. This relation models the target type, that is, the class which is at another end of the association. •EDataType models the type of an attribute. It can be a primitive type (int, float, ...) or an object type. We use Java interfaces to define the core model. For each class of the model an interface is defined. For each attribute and for each reference contained in the class, a standard get() method is declared in the interface. With this information the EMF generator will deduce the model attributes and references. The Java interfaces and the get() methods are annotated in order to help the EMF generator to deduce the model properties. With the interfaces and the annotations, EMF produces two files: a .ecore file and a .genmodel.The.ecore is an XML file that contains the core model. The .genmodel is a kind of wrapper of the core model with extra information. This information is needed for generating the implementation of the model. Once the implementation is generated, each Ecore class (that is, each EClass) corresponds to two things in Java: an interface and its corresponding implementation class. For example, class Book in our Ecore model will be modelled as an EClass in EMF, and it will be mapped onto a Java interface (public interface Book) and an implementation class (public class BookImpl ... implements Book). Figure 4depicts these relations. Book : EClass Book BookImpl library library.impl Fig. 4. Relationship between an Ecore class and the generated stuff If we define the Ecore model using annotated Java, we will just be in charge of writing the interfaces and the get() methods (if needed). Afterwards, the EMF generator will complete these interfaces with more annotations and set() methods. Furthermore, it will generate the implementation classes and all the extra code needed. 4 Problem Statement: Metamodel Extension If a metamodel is reused, it should be defined in such a way that it is completely unaware of being extended by another metamodel. To introduce the problem, we have classified the possible relations between the elements of two models (the original and the extended one) into two main groups: inheritance relationships and the rest of relationships. The following subsections introduce two different examples to illustrate the impact of these two kinds of relations on the definition and implementation of metamodels. 4.1 Example 1: Extensions by means of inheritance relationships This example has been obtained from [8]. It has been chosen because it is a very simple, introductory example. Figure 5shows a package named Library which holds a MOF metamodel of a library. This package contains three metaclasses (Library,Book and Writer) and one enumeration (BookCategory). For writing this metamodel with EMF, three interfaces (one for each metaclass) have to be defined. In each interface a number of get() methods should be written (one get¬ () method for each attribute and another one for each reference). Furthermore, a new class should be defined for the enumeration. +Mistery = 0 +Science-Fiction = 1 +Biography = 2 «enumeration» BookCategory -name : String Library -name : String Write -category : BookCategory -name : String -pages : int = 100 Book +library1 +writers* +library 1 +books * +author 1 +books * +Mistery = 0 +Science-Fiction = 1 +Biography = 2 «enumeration» BookCategory -name : String Library -name : String Write -category : BookCategory -name : String -pages : int = 100 Book +library1 +writers* +library 1 +books * +author 1 +books * Library -name : String Library::Library -category : BookCategory -name : String -pages : int = 100 Library::Book -location : String SchoolLibrary SchoolBook -value : float Asset SchoolLibrary Fig. 5. Exteding a metamodel by means of inheritance relationship Figure 6shows a part of the implementation of the Library metamodel with EMF: the Library metaclass and the BookCategory enumeration. package library; import java.util.List; /** *@model */ public interface Library { /** * @model */ String getName(); /** * @model type="Writer" containment="true" */ List getWriters(); /** * @model type="Book" containment="true" */ List getBooks(); } package library; /** * @model */ public class BookCategory { /** * @model name="Mystery" */ public static final int MYSTERY = 0; /** * @model name="ScienceFiction" */ public static final int SCIENCE_FICTION = 1; /** * @model name="Biography" */ public static final int BIOGRAPHY = 2; } Fig. 6. Part of the Library EMF metamodel with Java notation Figure 5shows the SchoolLibrary package which extends the Library package. From the MOF model point of view this extension implies that the SchoolLibrary package includes two classes (Book and Library) with the stereotype <<from Library>>. This stereotype means that those metaclasses belong to the Library package. In Figure 6, this is depicted with the name of the package placed just beforethenameoftheclass(Library::Book). Figure 7shows the extends clause in the SchoolLibrary and SchoolBook interfaces. These sentences express the inheritance relationship between the pair of classes SchoolLibrary-Library and SchoolBook-Book. The classes Book and Library should not be modified. Thus, as a conclusion, if we extend a metamodel by means of inheritance the obliviousness of the original metamodel is maintained. package schoollibrary; import library.Library; /** * @model */ public interface SchoolLibrary extends Library { /** * @model */ String getLocation(); } package schoollibrary; import library.Book; /** * @model */ public interface SchoolBook extends Book, Asset { } Fig. 7. Part of the extended SchoolLibrary package 4.2 Example 2: Extensions by means of associations Figure 8shows a relation between the two packages. The original package is called com.metamodels.java2, it has been obtained from [6], and it is a version of the UML metamodel which tailors the UML metaclasses to the Java2 Specification. The com.metamodels.aspectj package contains an AspectJ metamodel which extends the Java metamodel according to the AspectJ specification [1]. AspectJ is an extension for Java to develop aspect-oriented applications. The AspectJ metamodel has been obtained from [12]. AspectJ Java2 <<extends>> Fig. 8. Package relationship Figure 9shows the MOF Java 2 metamodel. Most of the metaclasses use the same name as the corresponding UML metaclasses. We focus on the metaclasses that are relevant to our example: Element,Generalization,Feature and Parameter. The Generalization class models the extend and implements relationships between classifiers (classes and/or interfaces). An instance of this class represents an inheritance relationship between a subtype and a supertype. It can also represent the relationship between a class and an interface. AFeature represents something that can be declared in a class or an interface (a field, a constructor or an ordinary method). The Parameter class abstracts the parameters in a method or constructor. This relationship is represented by a composition relation between Parameter and BehavioralFeature. A parameter is also related to a Type. That specification of this metamodel in annotated Java contains one interface for each metaclass and one final static class for each enumeration. Figure 10 shows -name[1] : String -modifiers[*] : FeatureModifier Feature +private +protected +public +static +abstract +final +native +synchronized +transient +volatile +strictfp «enumeración» FeatureModifier -initVal : String Field -name : String -modifiers : ClassModifier Classifier +public +protected +private +abstract +static +strictfp «enumeración» ClassModifier -owner 1 -member * -staticInit[0..1] : Block -instanceInit[*] : Block Class «tipo de datos» Block Type -typef 0..1 -feature * -kind : PrimitiveTag PrimitiveType +boolean +byte +short +int +long +float +double +char «enumeración» PrimitiveTag -body : Block BehavioralFeature Constructor Method Generalization Element -subtype 1 -supertipo * -supertype * -subtipo * Interface Fig. 9. AspectJ Metamodel the code needed for generating the metaclasses Feature and Class.Feature has two attributes name and modifiers which are transformed in the implementation into two get() methods, getName and getModifiers. Feature is also related to Type and Classifier. The first relation is an association while the second one is a composition relationship. From the point of view of Feature there is no difference between these two relationships: there are two get() methods (getOwner and getTypefeature) with an opposite annotation. This annotation refer to the name at the other end of the association. The difference between these two kinds of relationships is specified in the classes Type and Classifier, respectively. The Type interface will have a get() method named getFeatures while the Classifier interface will have a get() method (getMember) with an extra annotation (containment=true). This containment annotation has the composition semantics. The Java2 metamodel is extended by the metamodel depicted in Figure 11.As well as in the example introduced in the previous section, at the modelling level, there is no problem to reuse some metaclasses of the com.metamodel.java2 package. We only need to label the classes with the stereotype <<Java2>>.Figure11 shows the stereotyped classes Class,Generalization,Feature,Element and Parameter. The Element and com.metamodel.aspectj package have inheritance relationship. There are composition relationship between Class and Pointcut; between Parameter and Pointcut; and between Parameter and Advice.Generalization has association relationship with Aspect and Feature has an association with Aspect. If we want to implement these relationships we need to declare get() methods package com.metamodel.java2; import org.eclipse.emf.common.util.EList; /** * @model */ public interface Class extends Classifier{ /** * @model * dataType="com.metamodel.java2.Block" */ Block getStaticInit(); /** * @model * dataType="com.metamodel.java2.Block" */ Block getInstanceInit(); /** * @model *type="com.metamodel.java2.BehavioralFeature" * opposite="thrownExceptions" */ EList getBehavioralFeatures(); } package com.metamodel.java2; import org.eclipse.emf.common.util.EList; /** * @model */ public interface Feature extends Element{ /** * @model */ String getName(); /** * @model * type="com.metamodel.java2.FeatureModifier" */ EList getModifiers(); /** * @model opposite="member" */ Classifier getOwner(); /** * @model opposite="features" */ Type getTypefeature(); } Fig. 10. Java 2 Implementation in the interfaces. Figure 12 shows two of these interfaces, Pointcut and Aspect. The Pointcut interface contains an annotated method called getDeclarer that models one edge of the relationship between Pointcut and Class. But in order to model the other end of the association, a new annotated get() method with an annotation containment=true should be included in the Class interface. Therefore, at this point we need to modify the Class interface and, as a consequence, the com.metamodel.java2 package becomes aware of being extended with the com.¬ metamodel.aspectj package. The same problem arises when we try to implement the association between Aspect and Feature.ThegetIntroducedFeatures method implements one of the ends of the relationship, but in order to implement the other end we have to declare a new get method in the Feature interface. So, if we extend a metamodel using relationships different from inheritance, the obliviousness of the original metamodel is lost. 5 Using aspect technology to improve reuse of metamodels This section describes three different approaches for making the com.metamodel¬ .java2 unaware of being extended by another metamodel. The first one is based on the traditional object-oriented inheritance mechanism, while the second and the third ones are based on aspect-oriented solutions [13].