Naouel Moha
email: moha@irisa.fr

Vincent Mahé

Olivier Barais
email: barais@irisa.fr

Jean-Marc Jézéquel
email: jezequel@irisa.fr

Generic Model Refactorings

Keywords: Adaptation, Aspect Weaving, Genericity, Model Typing, Refactoring

Many modeling languages share some common concepts and principles. For example, Java, MOF, and UML share some aspects of the concepts of classes, methods, attributes, and inheritance. However, model transformations such as refactorings specified for a given language cannot be readily reused for another language because their related metamodels may be structurally different. Our aim is to enable a flexible reuse of model transformations across various metamodels. Thus, in this paper, we present an approach allowing the specification of generic model transformations, in particular refactorings, so that they can be applied to different metamodels. Our approach relies on two mechanisms: (1) an adaptation based mainly on the weaving of aspects; (2) the notion of model typing, an extension of object typing in the model-oriented context. We validated our approach by performing some experiments that consisted of specifying three well known refactorings (Encapsulate Field, Move Method, and Pull Up Method) and applying each of them onto three different metamodels (Java, MOF, and UML).

Introduction

Software reuse has been largely investigated in the last two decades by the software engineering community [START_REF] Biggerstaff | Software Reusability Volume I: Concepts and Models[END_REF][START_REF] Mili | Reusing software: Issues and research directions[END_REF]. Basili et al. [START_REF] Basili | How reuse influences productivity in objectoriented systems[END_REF] have demonstrated the benefits of software reuse on the productivity and quality in object-oriented systems. In the domain of Model-Driven Engineering (MDE), which is often based on object-oriented metamodels, few works have been devoted to modeldriven reuse [START_REF] Blanc | Metamodel reuse with mof[END_REF]. For example, many modeling languages share some common concepts and principles: Java, MOF, and UML share some aspects of the concepts of classes, methods, attributes, and inheritance. However, a given model transformation such as the refactoring Pull Up Method specified for the UML metamodel might not be reused, for instance, for the Java metamodel because these metamodels are structurally different. Thus, the specification of model transformations are highly dependent on specific metamodels. Our aim is to enable a flexible reuse of such model transformations across various metamodels to enhance productivity and quality in the model-driven development.

In this paper, we present an approach to specify model transformations in a generic way, so that they can be applied to different metamodels. Our approach relies on two mechanisms: [START_REF] Amelunxen | Generic and reflective graph transformations for the checking and enforcement of modeling guidelines[END_REF] an adaptation based mainly on the weaving of aspects; [START_REF] Basili | How reuse influences productivity in objectoriented systems[END_REF] the notion of model typing [START_REF] Steel | On model typing[END_REF], an extension of object typing in the model-oriented context. We choose to illustrate and demonstrate our approach on well known model transformations, namely refactorings [START_REF] Fowler | Refactoring -Improving the Design of Existing Code, 1st edn[END_REF]. A refactoring is a particular transformation performed on the structure of software to make it easier to understand and cheaper to modify without changing its observable behavior [START_REF] Fowler | Refactoring -Improving the Design of Existing Code, 1st edn[END_REF]. For example, the refactoring Pull Up Method consists of moving methods to the superclass if these methods have same signatures and/or results on subclasses [START_REF] Fowler | Refactoring -Improving the Design of Existing Code, 1st edn[END_REF]. We validated our approach by performing some experiments that consisted of specifying three well known refactorings (Encapsulate Field, Move Method, and Pull Up Method) and applying each of them onto three different metamodels (Java, MOF, and UML). The specification of refactorings has been performed with Kermeta, a meta-language for defining the structure and behavior of models [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF].

This article is organized as follows. Section 2 provides an overview of our motivation. Section 3 introduces the executable metamodeling language, Kermeta, and highlights some of its new features including the notion of model typing. Section 4 presents our approach along with the Pull Up Method refactoring. Section 5 describes the experiments that we performed for the three refactorings (Encapsulate Field, Move Method, and Pull Up Method) on three different metamodels (Java, MOF, and UML). Section 6 surveys related work. Section 7 concludes and presents future work.

Motivation

Our motivation is to enable the specification of generic refactorings, so that they can be applied to different metamodels. In this section, we clearly state this motivation using the concrete example of the Pull Up Method refactoring on three different metamodels (Java, MOF, and UML).

The Pull Up Method Refactoring

The Pull Up Method refactoring consists of moving methods to the superclass when methods with identical signatures and/or results are located in sibling subclasses [START_REF] Fowler | Refactoring -Improving the Design of Existing Code, 1st edn[END_REF]. This refactoring aims to eliminate duplicate methods by centralizing common behavior in the superclass. A set of preconditions must be checked before applying the refactoring. For example, one of the preconditions to be checked consists of verifying that the method to be pulled up is not a constructor. Another precondition checks that the method does not override a method of the superclass with the same signature. A third precondition consists of verifying that methods in sibling subclasses have the same signatures and/or results.

The example of the Pull Up Method refactoring presented in [START_REF] Mens | A taxonomy of model transformation[END_REF] of a Local Area Network (LAN) application [START_REF] Janssens | Case study: Simulation of a lan[END_REF] and adapted in Figure 1 shows that the method bill located in the classes PrintServer and Workstation is pulled up to their superclass Node.

Three Different Metamodels

We consider three different metamodels (Java, MOF, and UML), which support the definition of object-oriented structures (classes, methods, attributes, and inheritance). The Java metamodel described in [START_REF] Hoffman | A case study for program refactoring[END_REF] represents Java programs with some restrictions over the Java code. For example, inner classes, anonymous classes, and generic types are not modeled. As MOF metamodel, we consider the metamodel of Kermeta [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF], which is an extension of MOF [START_REF] Omg | Mof 2.0 core specification[END_REF] with an imperative action language for specifying constraints and operational semantics of metamodels. The UML metamodel studied in this paper corresponds to the version 2.1.2 of the UML specification [START_REF] Omg | The uml 2.1.2 infrastructure specification[END_REF]. This Java metamodel is one possible representation of Java programs; there is no standard for such metamodel in contrast to UML and MOF metamodels.

We provide an excerpt of each of these metamodels in Figures 2,3, and 4. These metamodels share some commonalities, such as the concepts of classes, methods, attributes, parameters, and inheritance (highlighted in grey in the figures). These concepts are necessary for the specification of refactorings, and in particular for the Pull Up Method refactoring. However, they are represented differently from one metamodel to another as detailed in the next paragraph.

Problems

We list here some of the problems encountered when trying to specify one common Pull Up Method refactoring for all three metamodels:

-The metamodel elements (such as classes, methods, attributes, and references) may have different names.

For example, the concept of attribute is named Property in the MOF and UML metamodels whereas in the Java metamodel, it is named Variable. For example, in the UML metamodel, the attribute visibility of Operation is an enumeration of type VisibilityKind whereas the same attribute in the Java metamodel is of type String. -There may be additional or missing elements in a given metamodel compared to another. For example, Class in the UML metamodel and ClassDefinition in the MOF metamodel have several superclasses whereas Class in the Java -Opposites may be missing in relationships.

For example, the opposite of the reference related to the notion of inheritance (namely, superClass in the MOF and UML metamodels, and extends in the Java metamodel) is missing in the three metamodels.

-The way metamodel classes are linked together may be different from one metamodel to another. For example, the classes Operation and Variable in the Java metamodel are not directly accessible from Class as opposed to the corresponding classes in the MOF and UML metamodels.

Because of these differences among these three metamodels, we are not able to directly reuse a Pull Up Method refactoring accross all three metamodels. Thus, we are forced to write three refactorings, one for each of the three metamodels. In Section 4, we present an approach that allows the specification of one common refactoring for these different metamodels.

Kermeta and Model Typing

We introduce here new features of the Kermeta language and the notion of model typing to ease the comprehension of our approach presented in Section 4.

New Features of Kermeta

In the current version of Kermeta, its action language provides new features for weaving aspects, adding derived properties, and specifying constraints such as invariants and pre-/post-conditions. Indeed, the first new feature of Kermeta is its ability to extend an existing metamodel with new structural elements (classes, operations, and properties) by weaving aspects (similar to inter-type declarations in AspectJ or open-classes [START_REF] Clifton | Multijava: Modular open classes and symmetric multiple dispatch for java[END_REF]). This feature offers more flexibility to developers by enabling them to easily manipulate and reuse existing metamodels while separating concerns. The second new key feature is the possibility to add derived properties. A derived property is a property that is derived or computed through getter and setter accessors for simple types and add and remove methods for collection types. The derived property thus contains a body, as operations do, and can be accessed in read/write mode. Thanks to this feature, it is possible to figure out the value of a property based on the values of other properties belonging to the same class. The last new feature is the specification of preand post-conditions on operations and invariants on classes. These assertions can be directly expressed in Kermeta or imported from OCL (Object Constraint Language) files [START_REF] Omg | The Object Constraint Language Specification 2.0[END_REF].

Model Typing

The last version of the Kermeta language integrates the notion of model typing [START_REF] Steel | On model typing[END_REF], which corresponds to a simple extension to object-oriented typing in a model-oriented context. Model typing can be related to structural typing found in languages such as Scala. Indeed, a model typing is a strategy for typing models as collections of interconnected objects while preserving type conformance, used as a criterion of substitutability.

The notion of model type conformance (or substitutability) has been adapted and extended to model types based on Bruce's notion of type group matching [START_REF] Bruce | Semantics-driven language design: Statically typesafe virtual types in object-oriented languages[END_REF]. The matching relation, denoted <#, between two metamodels defines a function of the set of classes they contain according to the following definition: Metamodel M' matches another metamodel M (denoted M' <# M ) iff for each class C in M, there is one and only one corresponding class or subclass C' in M' such that every property p and operation op in M.C matches in M'.C' respectively with a property p' and an operation op' with parameters of the same type as in M.C. This definition is adapted from [START_REF] Steel | On model typing[END_REF] and improved here by relaxing two strong constraints. First, the constraint related to the name-dependent conformance on properties and operations was relaxing by enabling their renaming. The second constraint related to the strict structural conformance was relaxing by extending the matching to subclasses.

Let's illustrate model typing with two metamodels M and M' given in Figures 5 and6. These two metamodels have model elements that have different names and the metamodel M' has additional elements compared to the metamodel M. Thus, matching between classes may depend on the matching of their related dependent classes. As a consequence, the dependencies involved when evaluating model type matching are heavily cyclical [START_REF] Steel | Typage de modèles[END_REF]. The interested reader can find in [START_REF] Steel | Typage de modèles[END_REF] the details of matching rules used for model types.

However, the model typing with the mechanisms of renaming and inheritance is not sufficient for matching metamodels that are structurally different. We show in the next section with our approach how we overcome this limitation of the model typing using aspect weaving.

Approach: Specification of Generic Refactorings

In this section, we present our approach for generic model refactoring. The four steps of the approach are illustrated in Figure 7. The first step consists of specifying a generic metamodel GenericMT1 , which corresponds to a metamodel that only contains elements required for applying refactorings. The second step consists of specifying refactorings based on the source metamodel GenericMT using a model transformation language such as Kermeta. The third step aims to adapt the target metamodels (Java, MOF, and UML) to the metamodel GenericMT. In the last step, refactorings are directly applied to models of all target metamodels. We detail in the following each of these steps using the Pull Up Method refactoring as a running example.

Specification of Generic

Step 1: Specification of Generic Metamodel. Our approach consists first of specifying a lightweight metamodel that contains the minimum required classes, methods, and attributes for specifying refactorings. The generic metamodel, called GenericMT and given in Figure 8, has been designed to specify refactorings. GenericMT contains concepts common to most of object-oriented metamodels such as classes, methods, attributes, and parameters.

Step 2: Specification of Generic Refactorings. In the second step, refactorings are specified based on the generic metamodel GenericMT. Listing 1 gives Fig. 8. Generic Metamodel GenericMT a Kermeta code 2 excerpt of the class Refactor, which contains the operation pullUpMethod. This operation aims to pull up the method meth from the source class source to the target class target. This operation contains a precondition that checks if the sibling subclasses have methods with the same signatures. In the body of the operation, the method meth is added to the methods of the target class and removed from the methods of the source class. Step 3: Adaptation of Target Metamodels. The third step aims to adapt the target metamodels to the generic metamodel GenericMT using the new Kermeta features for weaving aspects and adding derived properties. The adaptation consists of weaving, in the target metamodels, derived properties that match with those of the generic metamodel. This step of adaptation is necessary because the model typing is too restrictive for allowing a matching between metamodels that are structurally too different. Thus, this adaptation virtually modifies the structure of the target metamodel with additional elements, and uses the model typing to match the metamodels.

The adaptation requires also the weaving of opposites. The opposites are identified in Kermeta by a sharp and are computed during the loading of the model. The opposites make easier the writing of adapters by adding required navigation links.

Listings 2, 4, and 3 present the adaptations of the derived properties superClasses and subClasses of Class respectively for the Java, MOF, and UML target metamodels given respectively in Figures 2, 3, and4. Because of lack of space, we provide only the getter accessors of the derived properties; the setter accessors are symmetric.

Adaptation for the Java metamodel. The derived property superClasses corresponds to a simple access to the property extends that is then wrapped in a Java 2 The interested reader can refer to the Kermeta syntax in [16].

Experiments and Discussion

We specified three well known refactorings (Encapsulate Field, Move Method, and Pull Up Method [START_REF] Fowler | Refactoring -Improving the Design of Existing Code, 1st edn[END_REF]) on models of the LAN application [START_REF] Janssens | Case study: Simulation of a lan[END_REF] conforming to three different metamodels (Java, MOF, and UML). We were able to successfully apply our approach on these metamodels although they were structurally different. We experimented also a fourth metamodel, which a subset is given in Figure 9. In this metamodel, the two classes (corresponding to Class and Parameter in the generic metamodel) are unified in a same class (Type). This case introduced an ambiguous matching with the generic metamodel since these classes are distinct in the latter. This special case illustrates a limitation of our approach that needs to be overcome and will be investigated in future work. Thus, the only prerequisite of our approach is that each element in the generic metamodel should correspond to a distinct element in the target metamodel. The approach is thus not very restrictive since the mechanism of adaptation enables to raise the inherent limitations of metamodels.

Our approach theoretically relies on the model typing and is feasible in practice thanks to the mechanism of adaptation. Writing adaptations can be more or less difficult depending on the developers' knowledge of the target metamodels. However, once the adaptation is done, the developers can reuse all model refactorings written for the generic metamodel. Conversely, if a developer specifies a new refactoring on the generic metamodel, it can readily be applied on all target metamodels if adaptations are provided.

Although we use a specific kind of model transformations, namely refactorings, for demonstrating the feasibility of our approach, this one can be applied to any other endogenous model transformation. In addition, our approach also fits well in the context of metamodel evolution. Indeed, all model transformations written for an old version of a given metamodel (for example, UML 1.2) can be reused for a new version (for example, UML 2.0) once the adaptation is done. Moreover, the models do not need to be migrated from the old version to the new one. Finally, our approach (with the model typing, the mechanism of adaptation, and the generic metamodel) can be seen as a framework for specifying arbitrary model transformations for arbitrary metamodels.

Related Work

Genericity and reuse in MDE have not been sufficiently investigated as in objectoriented (OO) programming. However, we observe some efforts in the MDE community that are directly inherited from type-safe code reuse in OO programming and, in particular, from generic programming.

Generic programming is about making programs more adaptable by making them more general [START_REF]Generic Programming[END_REF]. This style of programming allows writing programs that differ in their parameters, which may be either other programs, types and type constructors, class hierarchies, or even programming paradigms [START_REF]Generic Programming[END_REF]. Aspects [START_REF] Kiczales | Aspect-oriented programming[END_REF] and open-classes [START_REF] Clifton | Multijava: Modular open classes and symmetric multiple dispatch for java[END_REF] are powerful generic programming techniques for adapting programs by augmenting their behavior in existing classes [START_REF] Hannemann | Design pattern implementation in java and aspectj[END_REF][START_REF] Kiczales | Aspect-oriented programming and modular reasoning[END_REF]. Similarly, in our approach, we use aspects to align target metamodels with the generic metamodel. Other languages that provide support for generic programming are Haskell and Scala [START_REF] Oliveira | Scala for generic programmers[END_REF]. The use of Haskell has been investigated [START_REF] Lämmel | Towards Generic Refactoring[END_REF] to specify refactorings based on high level graph algorithms that could be generic accross a variety of languages (XML, Pascal, Java), but its applicability does not seem to go beyond a proof of concept. Scala's implicit conversions [START_REF] Odersky | An overview of the scala programming language[END_REF] simulate the open-class mechanism in order to extend the behavior of existing libraries without actually changing them. Although Scala is not a model-oriented language, developers can build type-safe reusable model transformations on top of EMF thanks to its good integration with Java. However, it would require to write a significant amount of code and manage relationships among generic types.

In the MDE community, Blanc et al. proposed an architecture, called Model Bus, that allows the interoperability of a wide range of modeling services [START_REF] Blanc | Model bus: Towards the interoperability of modelling tools[END_REF]. The term 'modeling service' defines an operation having models as inputs and outputs such as model edition, model transformation, and code generation. Their architecture is based on a metamodel that ensures type compatibility checking by describing services as software components having precise input and output definitions. However, the type compatibility defined in this metamodel relies on a simple notion of model types as sets of metaclasses, but without any notion of model type substitutability. Other work [START_REF] Amelunxen | Generic and reflective graph transformations for the checking and enforcement of modeling guidelines[END_REF][START_REF] Münch | Generic Modelling with Graph Rewriting Systems[END_REF] study the problem of generic model transformations using a mechanism of parameterization. However, these transformations do not apply to different metamodels but to a set of related models.

Modularity in graph transformation systems was also explored [START_REF] Heckel | Classification and comparison of module concepts for graph transformation systems[END_REF]. In this area, an interesting work was done by Engels et al. who presented a framework for classifying and defining relations between typed graph transformation systems [START_REF] Engels | Flexible interconnection of graph transformation modules[END_REF]. This framework integrates a novel notion of substitution morphism that allows to define the semantic relation between the required and provided interfaces of modules in a flexible way.

From another perspective, our approach also relates to the Aspect Oriented Modeling (AOM) field [START_REF] Kienzle | Aspect-oriented multi-view modeling[END_REF], or more precisely to AO metamodeling. From the AOM perspective, our notion of model type can indeed be interpreted as a pointcut defining a (model) pattern to be matched in a specific metamodel (e.g. UML or Java). The definition of our generic refactorings then would play the role of advices to be woven into these metamodels through some kind of adaptation as available in SmartAdapters [START_REF] Lahire | Introducing variability into aspect-oriented modeling approaches[END_REF]. Thus from this perspective our paper could have been title "Weaving refactoring aspects into metamodels".

Conclusion

In this paper, we have presented an approach for generic model refactorings, that is refactorings that can be reused on structurally different metamodels. This approach relies on the model typing and a mechanism of adaptation based mainly on the weaving of aspects. We illustrated our approach on the Pull Up Method refactoring and validated it on three different refactorings (Encapsulate Field, Move Method, and Pull Up Method) for three different metamodels (Java, MOF, and UML) in a concrete application. We demonstrated that our approach ensures a flexible reuse of model transformations, in particular refactorings. This approach seems to be generalisable to other endogenous model transformations such as the computation of metrics, detection of patterns and inconsistencies. As future work, we plan to increase the repository of refactorings on other metamodels and experiment with other model transformations.

Fig. 1 .

 1 Fig. 1. Class Diagrams of the LAN Application Before and After the Pull Up Method Refactoring of the Method bill

Fig. 2 .

 2 Fig. 2. Subset of the Java Metamodel

Fig. 3 .

 3 Fig. 3. Subset of the MOF Metamodel

Fig. 4 .

 4 Fig. 4. Subset of the UML Metamodel

Fig. 5 . 6 .

 56 Fig. 5. Metamodel M Fig. 6. Metamodel M'

Fig. 7 .

 7 Fig. 7. Approach for the Specification of Generic Refactorings

Listing 1 .

 1 package r e f a c t o r ; c l a s s R e f a c t o r <MT : GenericMT> { operation pullUpMethod ( s o u r c e : MT: : C l a s s , t a r g e t : MT: : C l a s s , meth : MT: : Method ) : Void // P r e c o n d i t i o n s pre s a m e S i g n a t u r e I n O t h e r S u b c l a s s e s i s do t a r g e t . s u b C l a s s e s . f o r A l l { sub | sub . methods . e x i s t s { op | haveSameSignature ( meth , op ) } } end // O p e r a t i o n body i s do t a r g e t . methods . add ( meth ) s o u r c e . methods . remove ( meth ) end } Kermeta Code for the Pull Up Method Refactoring

Listing 5 .

 5 package r e f a c t o r ; require " h ttp : / /www. e c l i p s e . org /uml2 / 2 . 1 . 2 /UML" c l a s s Main { operation main ( ) : Void i s do var r e p : EMFRepository i n i t EMFRepository . new var model : uml : : Model model ?= r e p . g e t Re so u r c e ( " l a n a p p l i c a t i o n . uml" ) . one var s o u r c e : uml : : C l a s s i n i t g e t C l a s s ( " P r i n t S e r v e r" ) var t a r g e t : uml : : C l a s s i n i t g e t C l a s s ( "Node" ) var meth : uml : : O p e r a t i o n i n i t g e t O p e r a t i o n ( " b i l l " ) var r e f a c t o r : r e f a c t o r : : Re f ac tor <uml : : UmlMM > i n i t r e f a c t o r : : Re f ac tor <uml : : UmlMM>.new r e f a c t o r . pullUpMethod ( s o u r c e , t a r g e t , meth ) end } Kermeta Code for Applying the Pull Up Method Refactoring on the UML metamodel

Fig. 9 .

 9 Fig. 9. Subset of the Fourth Metamodel

MT refers to Model Type.

This work was realized in the context of the MOVIDA project, funded by the ANR (French National Research Agency) CONVENTION N 2008 SEGI 011.

Class. However, for the derived property subClasses, the opposite inv extends of the property extends was weaved by aspect on the class Classifier and used to get the set of subclasses. Adaptation for the UML metamodel. In UML, the inheritance links are reified through the class Generalization. Thus, the derived property superClasses is computed by accessing to the class Generalization and the reference property general. As in Java and MOF, an opposite inv general is specified to get the set of subclasses. Step 4: Application of Refactoring. The last step of our approach consists of applying the refactoring on the target metamodels as illustrated in Listing 5 for the UML metamodel. We reuse the example of the method bill in the LAN application. We can notice that the class Refactor takes as argument the UML metamodel, which thanks to the adaptation of Listing 3 is now a subtype of the expected supertype GenericMT as specified in Listing 1. The model typing guarantees the type conformance between the UML metamodel and the generic metamodel.