Jean-Marc Jézéquel

Modeling and Aspect Weaving

A model is a simplified representation of an aspect of the world for a specific purpose. Complex systems typically give rise to more than one model because many aspects are to be handled. For software systems, the design process can be characterized as a (partially automated) weaving of these aspects into a detailed design model. While validation is usually feasible on each single aspect when it is the only one to be woven, validation is seldom possible on the complete detailed design resulting from the weaving of all the aspects. Hence we need weaving processes that exhibit good composition properties to allow multiple aspect weavings. We present an example of such a weaving process for behavioral models represented as scenarios.

Introduction

It is seldom the case nowadays that we can deliver software systems with the assumption that one-size-fits-all [START_REF] Bosch | Software product families in Nokia[END_REF]. We have to handle many variants accounting not only for differences in product functionalities (range of products to be marketed at different prices), but also for differences in hardware (e.g.; graphic cards, display capacities, input devices), operating systems, localization, user preferences for GUI ("skins"). Obviously, we do not want to develop from scratch and independently all of the variants the marketing department wants. Furthermore, all of these variant may have many successive versions, leading to a two-dimensional vision of product-lines [START_REF] Ziadi | Families Research Book, chapter Product Line Engineering with the UML: Products Derivation[END_REF].

The traditional way scientists use to master complexity is to resort to modeling. Models can be used for instance to describe and analyse the commonalities and variation points within a software product-line. In the software community however, a lot of misunderstanding on Model Driven Engineering stems from a biased understanding of the nature of modeling.

In this paper, we explore the relationship between modeling and aspect weaving. In Section 2 we recall that a model is indeed a simplified representation of an aspect of the world for a specific purpose. Complex systems typically give rise to more than one model because many aspects are to be handled. For software systems, the design process can be characterized as a (partially automated) weaving of these aspects into a detailed design model. Section 3 then discusses the need for weaving processes that exhibit good composition properties to allow multiple aspect weavings, and goes on by presenting an example of such a weaving process for behavioral models represented as scenarios. Section 4 presents an implementation environment for building such model weavers, based on the kernel meta-modeling tool Kermeta. Some concluding remarks close the paper.

Modeling and Weaving

Models and Aspects

Modeling is not just about expressing a solution at a higher abstraction level than code. This limited view on modeling has been useful in the past (assembly languages abstracting away from machine code, 3GL abstracting over assembly languages, etc.) and it is still useful today to get e.g.; a holistic view on a large C++ program. But modeling goes well beyond that. Modeling is indeed one of the touchstone of any scientific activity (along with validating models with respect to experiments carried out in the real world). Note by the way that the specificity of engineering is that engineers build models of artefacts that usually do not exist yet (with the ultimate goal of building them, see Figure 1).

In engineering, one wants to break down a complex system into as many models as needed in order to address all the relevant concerns in such a way that they become understandable enough. These models may be expressed with a general purpose modeling language such as the UML, or with Domain Specific Languages when it is more appropriate (see Figure 2). Each of these models can be seen as the abstraction of an aspect of reality for handling a given concern. The provision of effective means for handling such concerns makes it possible to establish critical trade-offs early on in the software life cycle, and to effectively manage variation points in the case of product-lines.

Note that in the Aspect Oriented Programming community, the notion of aspect is defined in a slightly more restricted way as the modularization of a cross-cutting concern [START_REF] Filman | Aspect-oriented programming is quantification and obliviousness[END_REF]. If we indeed have an already existing "main" decomposition paradigm (such as object orientation), there are many classes of concerns for which clear allocation into modules is not possible (hence the name "crosscutting"). Examples include both allocating responsibility for providing certain kinds of functionality (such as loggin) in a cohesive, loosely coupled fashion, as well as handling many non-functional requirements that are inherently crosscutting e.g.; security, mobility, availability, distribution, resource management and real-time constraints. However now that aspects become also popular outside of the programming world [START_REF] Rashid | Modularisation and composition of aspectual requirements[END_REF], there is a growing acceptance for a wider definition where an aspect is a concern that can be modularized. The motivation of these efforts is the systematic identification, modularization, representation, and composition of these concerns, with the ultimate goal of improving our ability to reason about the problem domain and the corresponding solution, reducing the size of software model and application code, development costs and maintenance time.

Design and Aspect Weaving

So really modeling is the activity of separating concerns in the problem domain, an activity also called analysis. If solutions to these concerns can be described as aspects, the design process can then be characterized as a weaving of these aspects into a detailed design model (also called the solution space, see Figure 3). This is not new: this is actually what designers have been effectively doing forever. Most often however, the various aspects are not explicit, or when there are, it is in the form of informal descriptions. So the task of the designer is to do the weaving in her head more or less at once, and then produce the resulting detailed design as a big tangled program (even if one decomposition paradigm, such as functional or object-oriented, is used). While it works pretty well for small problems, it can become a major headache for bigger ones.

Note that the real challenge here is not on how to design the system to take a particular aspect into account: there is a huge design know-how in industry for that, often captured in the form of design patterns. Taking into account more than one aspect as the same time is a little bit more tricky, but many large scale successful projects in industry are there to show us that engineers do ultimately manage to sort it out (most of the time).

The real challenge in a product-line context is that the engineer wants to be able to change her mind on which version of which variant of any particular aspect she wants in the system. And she wants to do it cheaply, quickly and safely. For that, redoing by hand the tedious weaving of every aspect is not an option.

We do not propose to solve this problem up-front, but just to mechanize and reproduce the process experienced designers follow by hand. The idea is that when a new product has to be derived from the product-line, we can automatically replay most this design process, just changing a few things here and there [START_REF] Jackson | Toward a generic and extensible merge[END_REF].

Usually in science, a model has a different nature that the thing it models (think of a bridge drawing vs. a concrete bridge). Only in software and in linguistics a model has the same nature as the thing it models. In software at least, this opens the possibility to automatically derive software from its model, that is to automate this weaving process. This requires that models are no longer informal, and that the weaving process is itself described as a program (which is as a matter of facts an executable meta-model) manipulating these models to produce a detailed design that can ultimately be transformed to code or at least test suites (see section 4 An advice , which is a new behavior meant to replace (or complement) the matched ones.

Many complex aspects involve dynamic behavior. This is usually a problem for AspectJ kinds of languages [START_REF] Kiczales | The fun has just begun[END_REF] which are limited by their join point models and pointcut expression mechanisms based on concrete syntax [START_REF] Cazzola | Semantic join point models: Motivations, notions and requirements[END_REF][START_REF] Klein | Problems of the semantic-based weaving of scenarios[END_REF]. With models however, interrelations among model elements (not just classes and objects, but also methods call and other events) can be immediately available and identifiable through e.g.; dynamic diagrams. Class and object diagrams describe clientship and inheritance among the program elements. Whereas use cases, statecharts, activity and sequence diagrams describe how and when the clientship takes place. Therefore, through a static analysis of the models we can get a much more direct outline of the system execution. Weaving a single aspect is then just detecting the join points matching the aspect pointcut (still sometimes limited by decidability issues [START_REF] Klein | Semantic-based weaving of scenarios[END_REF]), and then replacing them with the aspect advice.

However, when a second aspect has to be woven, the join point might not any longer exist because it could have been modified by the first aspect advice. If we want to allow the validation of aspect weaving on a pair-wise basis, we must then define the join point matching mechanism in a way that takes into account these composability issues. However, with this new way of specifying join points, the composition of the advice with the detected part cannot any longer be just a replacement of the detected part by the advice: we also have to define relevant compositions operators. The rest of the paper investigates these issues by narrowing down the problem to the simple modeling language of scenarios available in UML2.0 under the form of Sequence Diagrams.

Weaving Aspects in Sequence Diagrams

Sequence Diagrams are either basic Sequence Diagrams (bSDs), describing a finite number of interactions between objects of the system, or combined sequence diagrams (cSD), that are higher level of specifications that allow the composition of bSDs with operators such as sequence, alternative and loop. Formally, Sequence Diagrams in UML2 are partially ordered sets of event instances. Figure 5 shows several bSDs which describe some interactions between the two objects customer and server. The vertical lines represent life-lines for the given objects. Interactions between objects are shown as arrows called messages like log in and try again. Each message is defined by two events: message emission and message reception which induces an ordering between emission and reception. These bSDs can be composed with operators such as sequence, alternative and loop to produce a more complex Sequence Diagram (also called UML 2.0 Interaction Overview Diagram). Figure 5 shows two equivalent views of the same cSD called log in (one view is more compact). This cSD log in represents the specification of a customer log on a server. If the customer makes two bad attempts, then he is rejected. Else, he is accepted. We can see that the cSD allows an alternative between the bSDs Accept and Retry, and between the bSDs Accept and Rejected.

In this context, we define a behavioral aspect as a pair A = (P, Ad) of bSDs. P is a pointcut, i.e. a bSD interpreted as a predicate over the semantics of a base model satisfied by all join points. Ad is an advice, i.e. the new behavior that should replace the base behavior when it is matched by P . When we define aspects with sequence diagrams, we keep some advantages related to sequence diagrams. In particular, it is easy to express a pointcut as a sequence of messages. Figure 6 shows three behavioral aspects. The first allows the persistence of exchanges between the customer and the server. In the definition of the pointcut, we use regular expressions to easily express three kinds of exchanges that we want to save (the message log in followed by either the message ok, the message try again, or the message no). The second aspect allows the identification of a log in which fails. The third aspect allows the addition of a display and its update.

In Figure 5, the cSD log in represents a customer log in on a server. The customer tries to log in and either he succeeds, or he fails. In this last case, the customer can try again to log in, and either he succeeds, or the server answers "no". The expected weaving of the three aspects depicted in Figure 6 into the cSD log in is represented by the cSD in Figure 7.

Weaving More Than One Aspect: the Detection Problem

Weaving several aspects at the same join point can be difficult if a join point is simply defined as a strict sequence of messages, because aspects previously woven might have inserted messages in between. In this case, the only way to support multiple static weaving is to define each aspect in function of the other aspects, which is clearly not acceptable.

The weaving of the three aspects depicted in Figure 6 allows us to better explain the problem. If the join points are defined as the strict sequence of messages corresponding to those specified in the pointcut, the weaving of these three aspects is impossible. Indeed, when the aspect security is woven, a message save bad attempt is added between the two messages log in and try again. Since the pointcut only detects a strict sequence of messages, after the weaving of the aspect security, the aspect display cannot be woven anymore. We obtain the same problem if we weave the aspect display first and the aspect security afterwards.

To solve this problem of multiple weaving, we need definitions of join points which allow the detection of join points where some events can occur between the events specified in the pointcut. In this way, when the aspect security is woven, the pointcut of the aspect display will allow the detection of the join point formed by the messages log in and try again, even if the message save bad attempt has been added.

In our approach, the definition of join point will rely on a notion of part of a bSD, which is a subset of a bSD where any kind of messages can occur between the messages of the pointcut. A join point will then be defined as a part of the base bSD such that this part corresponds to the pointcut.

The notion of correspondence between a part and a pointcut is defined as an isomorphism between bSD, made of a set of 3 isomorphisms between the base SD and the pointcut SD: f 0 is an isomorphism for matching objects; f 1 is an isomorphism for matching events; f 2 is an isomorphism for matching message names (taking into account wildcards).

As an example, figure 8 shows a bSD morphism f =< f 0 , f 1 , f 2 >: pointcut → M 2 where only the morphism f 1 associating the events is represented (for instance, the event ep 1 which represents the sending of the message m1 is associated with the event em 2 ).

Weaving More Than One Aspect: the Composition Problem

Detecting a join point in a bSD then boils down to construct such an isomorphism between a pointcut and a base bSD. Once such a join point has been detected, it remains to compose the bSD Advice with the join points. Since some messages can be present between the messages forming the join point, it is not possible to simply replace a join point by an advice because we would lose the "in-between" messages. Therefore, we have to define a new operator of composition which takes into account the common parts between a join point and an advice to produce a new bSD which does not contain copies of similar elements of the two operands. We use an operator of composition for bSDs called left amalgamated sum, inspired by the amalgamated sum proposed in [START_REF] Klein | Merging scenarios[END_REF]. We add the term lef t because our operator is not commutative, as it imposes a different role on each operand. Figure 9 shows an example of left amalgamated sum where the two bSDs base and advice are amalgamated. For that, we use a third bSD which is the pointcut and two bSD morphisms f : pointcut → base and g : pointcut → advice which allow the specification of the common parts of the two bSDs base and advice.

f is the isomorphism from the pointcut to M that has automatically been obtained with the process of detection described into the previous section.

The morphism g, which indicates the elements shared by the advice and the pointcut, has to be specified when the aspect is defined. In this way, g allows the specification of abstract or generic advices which are "instantiated" by the morphism. For instance, it is not mandatory that the advice contains objects having the same names as those present in the pointcut. In the three aspects in Figure 6, the morphism g is not specified but it is trivial: for each aspect, we associate the objects and the actions having the same names, and the events corresponding to the actions having the same name. The advice of the aspect Display in Figure 6 could be replaced by the "generic" Advice in Figure 9. It is the morphism g which indicates that the object customer plays the role of the object subject and that the object server plays the role of the object A.

In Figure 9, the elements of the bSDs base and advice having the same antecedent by f and g will be considered as identical in the bSD result, but they will keep the names specified in the bSD base. For instance, the objects subject and A in the bSD advice are replaced by the objects customer and server. All the elements of the bSD base having an antecedent γ by f such that γ has not an image by g in the bSD advice are deleted. This case does not appear in the example proposed, but in this way we can delete messages of the bSD base. For instance, in an amalgamated sum, if the right operand (the bSD advice in the example) is an empty bSD then the part of the left operand which is isomorphic to the pointcut (that is to say the join point), is deleted. Finally, all the elements of the bSDs base and advice having no antecedent by f and g are kept in the bSD result, but the events of the bSD advice will always form a "block" around which the events of the bSD base will be added. For instance, in Figure 9, in the bSD base, if there were an event e on the object customer just after the message try again, then this event e would be localized just after the sending of the message update (event ea 7 ) in the woven SD.

Building Aspect Weavers with Kermeta

What we are trying to achieve is to reify the design process into a weaver program that makes it possible to re-build as often as it is need the target software from its models. The goal is to have only small modifications to make when requirements do change. Actually we need a family of weavers, that for a given product-line are just variants of one's another.

There is thus a need for tools to build these weavers efficiently. These tools are often called meta-tools, or more properly metamodeling tools, that is tools to build tools to build software from models. Several of these metamodeling tools have mature over the last decade, the most well known being Metacase [START_REF] Pohjonen | Automated Production of Family Members: Lessons Learned[END_REF], Xactium [START_REF] Clark | Applied Metamodelling: A Foundation for Language Driven Development[END_REF], GME [START_REF] Ledeczi | The Generic Modeling Environment[END_REF], and Kermeta [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF]. All these metamodeling tools have in common that they are based on an executable metamodeling language specifically designed to support the design of tools dedicated to user defined metamodels. In the rest of this section, we outline one of these tools, Kermeta, as well as how it can be used to build our Sequence Diagram weaver.

Kermeta is a metamodeling language which allows describing both the structure and the behavior of metamodels. It has been designed to be compliant with the OMG metamodeling language EMOF (part of the MOF 2.0 specification) and Ecore (from Eclipse). It provides an action language for specifying the behavior of models. Kermeta is intended to be used as the core language of a model oriented platform. It can be seen as a common basis to implement Metadata languages, action languages, constraint languages or transformation language. Kermeta is statically typed, with generics as well as function types to allow OCL style forall/exist/iterate style of closures. It also directly supports A MOF meta-model is a valid Kermeta program that just declares packages and classes and does nothing (see Figure 10). Then familiar OO techniques such as design patterns may be applied to model transformations.

As illustrated in Figure 11, the weaving process consists of two steps. Firstly, the detection step uses the pointcut model and the base model to compute a set of join points. Each join point is characterized by a morphism from the pointcut to a corresponding elements in the base model. Secondly, using these morphisms, the advice is composed with each join point in the base model.

The first step processes models to extract join points and the second is a model transformation. Figure 12 gives an other view of the overall process, concentrating on the input and output models of these two steps (each ellipse is a model and the black rectangle on the top left-hand corner indicates its metamodel). Except for morphisms (which are defined with their own meta-models), all models are SDs.

Conclusion

From an engineering point of view, modeling and weaving aspects are symmetric activities: weaving aspects is the process by which analysis models are transformed into a design model. Model Driven Engineering makes it possible to automate this process: i.e. to have software build software instead of building it by hand. In this paper we have described the overall vision of a design process require kermeta require "../models/bigSd.kmt" require "../detectionAlgorithm/Detection.kmt" require "../amalgamatedSum/LeftSum.kmt" using kermeta::standard using bigSd based on these ideas. We have illustrated this overall process on a toy example where simple aspects, described as Sequence Diagram pairs (representing the aspect pointcut and advice), have been woven into a base Sequence Diagram. We have highlighted that when more than one aspect has to be woven, potentially difficult join point detection and composition problems arise. We proposed to solved them using powerful techniques based on executable meta-modeling as available in the Kermeta environment.

While our example was simple, we firmly believe that this overall approach can be applied to more realistic examples. We are currently in the process of evaluating it through various collaborative projects with industrial partners.

Figure 1 .

 1 Figure 1. Modeling the world

Figure 2 .

 2 Figure 2. Modeling several aspects

Figure 4 .

 4 Figure 4. Principle of Aspect Weaving

Figure 5 .

 5 Figure 5. Examples of bSDs and combined SD

Figure 6 .

 6 Figure 6. Three behavioral aspects

Figure 7 .

 7 Figure 7. Result of the weaving

Figure 8 .

 8 Figure 8. Example of a morphism between bSD

Figure 9 .Figure 10 .

 910 Figure 9. An example of left amalgamated sum

Figure 11 .

 11 Figure 11. Weaving Aspects in Kermeta

Figure 12 .

 12 Figure 12. Transformation of Models

Acknowledgments

We are grateful to Jacques Klein and Franck Fleurey for the development of the weaving example used all along this paper, and beyond that, for many interesting discussions around aspect weaving.

Ideally, all aspects are equally important, and should play a symmetrical role. In practice however, a base model is useful to provide a backbone on which other aspects are woven (see Figure 4). An aspect is then made of:

A pointcut , which is a predicate over a model that is used to select relevant model elements called join points.


Franck Fleurey
email: ffleurey@irisa.fr

Erwan Breton
email: ebreton@sodifrance.fr

Benoit Baudry
email: bbaudry@irisa.fr

Alain Nicolas
email: anicolas@sodifrance.fr

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

Model-Driven Engineering for Software Migration in a Large Industrial Context

As development techniques, paradigms and platforms evolve far more quickly than domain applications, software modernization and migration, is a constant challenge to software engineers. For more than ten years now, the Sodifrance company has been intensively using Model-Driven Engineering (MDE) for both development and migration projects.

In this paper we report on the use of MDE as an efficient, flexible and reliable approach for a migration process (reverse-engineering, transformation and code generation). Moreover, we discuss how MDE is economically profitable and is cost-effective over the migration through out-sourced manual re-development. The paper is illustrated with the migration of a large-scale banking system from Mainframe to J2EE.

Introduction

Positioned from the mid 80's on IT servicies dedicated to Banks and Insurance Companies, Sodifrance has developed a strong legacy modernization expertise based on software solutions to industrialize transformation projects. Since 1994, Sodifrance has adopted and promoted model-driven engineering (MDE) approaches for modernization projects. It has industrialized model-driven techniques for reverse-engineering, code analysis and transformation and for representing and manipulating information systems. These solutions allow the company to propose efficient and profitable solutions for migration and modernization of software legacy systems.

In this paper we first present an original model-driven process, developed at Sodifrance, for software migration. This process includes automatic analysis of the existing code, reverse engineering of abstract high-level models, model transformation to target platform models and code generation. We detail the different meta-models and transformations that are produced for the automation of these steps. We also discuss what artefacts can be directly reused and which ones need to be adapted from one project to another. Sodifrance has developed a tool suite for model manipulation called Model-In-Action (MIA) that is used as a basis for automating the migration.

A second contribution of this paper is an industrial feedback on the benefits and issues of MDE for migration. First, we present data for a migration project of a large-scale banking system from Mainframe to J2EE. These data are used to discuss the improvements with respect to efficiency, flexibility and reliability that are introduced with a model-driven solution migration. Moreover, we compare MDE and complete manual re-development, and discuss how MDE is economically profitable and is cost-effective.

Model-Driven Migration Process

The constant evolution of software technology leads to continuous migrations of software components. These projects may be motivated by different reasons such as the obsolescence of a technology, the pressure of users, or the need to build a single coherant information system when merging companies. Most of the time software migration is achieved through the full re-developement of the legacy application. Model-driven software developement offers an oportunity for increasing the automation in software migration.

The full automation of migration is difficult to achieve not only because of the distance between the legacy platform and the new platform but also in order to ensure the quality of the new application. Most of the time, the objective of migration is not to simply "compile" the legacy application to a new platform but to create a new version of the application using state of the art development techniques. This is necessary to ensure the maintainability of the new application and to leverage the latest technologies in terms of graphical user interfaces, distribution and mobility.

In the following, section 2.1 first presents the general process developed by Sodifrance for model-driven migration, section 2.2 discusses the automation of the process and section 2.3 details how this process is adapted in practice along the phases of a migration project.

Migration General Process

Figure 1 presents the general process developed by Sodifrance for model-driven migration. This process is mainly divided in four steps.

The first step is the parsing of the code of the legacy application, to build a complete model of the code of the application. This step can be divided into two stages: first a parser builds an abstract syntax tree from the code and, then this syntax tree is processed by a transformation to build an actual model that conforms to the meta-model of the legacy language. During the second stage, all the symbols such as types, variables or function calls are resolved and properly bound to the appropriate model elements. This is a necessary step to allow for a efficient analysis of the legacy system. The meta-model denoted L on figure 1 corresponds to the meta-model of the legacy application implementation language.

The second step is a reverse-engineering from the code model to a platform independent model. The role of this step is to abstract high-level views from the The navigation is the most high level view of the ANT meta-model. Figure 2 shows an excerpt of this meta-model. It connects dialog elements which correspond to GUI forms, transitions between forms and their GUI events with operations in the class model.

All ANT views have to be created through model transformations from the model of the code of the legacy application. In order to be able to create highlevel views, such as a model of the graphical user interface of the legacy application, the model transformations have to rely on a knowledge of the libraries of the legacy platform and on coding conventions (or code patterns introduced by tools) that were used during the development of the legacy application. This is the reason why, even if the legacy platforms for several migration projects are similar, the legacy code must be carefully studied in order to properly adapt the migration tools to every single project.

The third step is the transformation of the ANT model into a platform specific model of the application. This step is implemented using model transformations from the ANT meta-model to the UML meta-model. These transformations are design transformations which refine the platform independant views of the pivot model to fit the target platform. Again at this stage, it is important to adapt the transformation to meet the requirements of every customer. This issue is discussed with more details and illustrated on a specific project in section 4.

Fig. 2. Excerpt of the ANT navigation meta-model

The last step is the generation of the code of the new application from the platform specific model. To implement this step, Sodifrance uses template-based text generation tools in order to be able to easily customize code generation acording to the customers requirements. The specific tools used by Sodifrance for the implementation of model-transformations and code generation are presented section 3.

Automation in the Migration Process

To reduce the cost of migration the goal is to achieve an optimum automation in the migration process. However, this should not impact the quality in terms of design, performances or maintainability of the resulting application. Since the legacy application is fully-executable and the target platform is usually powerful enough, one could argue that the migration should be completely automated. It is theoretically possible: it would be the equivalent of writing a compiler for the legacy language that targets the new platform.

However, as stated in the previous section, migration, and especially in the context of modernization, is more than just creating an executable version of the application on top of the new platform. The goal is to design the application for the new platform in order to make it more efficient, more reliable, easier to maintain or easier to extend than the legacy application. In practice this means that the new code should respect the coding standards and best practices of the target platform languages, it should take into account the specific requirements related to the software development process used by the customer company, there should be models for the new application, etc.

In the migration process implemented by Sodifrance the first two steps (as presented on figure 1) are usually completely automated, i.e. all the information from the legacy system is represented in the pivot model. This is to concentrate the manual effort on the transformation from the pivot model to the new Fig. 3. Model-driven migration project phases application and avoid having to deal manually with the legacy code as a whole. If some elements of the legacy code cannot fit properly in the pivot model, these elements are captured as notes or tags and presented to the developer when the corresponding parts of the application are transformed or generated.

To maximize the efficiency of the migration process, the tasks that are left to the developer have to be clearly identified and the developer should be provided with all the information he or she needs. This is taken into account in the design of the transformations and code generators. For example in the case of a Java code generator, T ODO directives can be generated for every piece of code that requires manual inspection, re-factoring or completion. This T ODO directive can contain the kind of work that has to be done and references to the model elements that are relevant to it. The T ODO directives are summarized into a task list which gives the developer a clear view of what has to be done.

Migration Project Phases

Prior to the actual migration and implementation of the new application, the design, the implementation and the validation of a project specific migration process must be completed. This includes the parsing of legacy languages, reverse engineering transformations, high-level design of the new application and mappings between the structures of the legacy application and the concepts of the target platform. All these tasks require some effort due to their complexity and their overall influence on the migration project. In the project structure used by Sodifrance, as represented on figure 3, there are three project phases before the actual migration can start.

The first phase represented on figure 3 is a technical analysis. Its objective is to study the legacy platform, define the target platform and specify the tools that are needed by the migration process. This phase is crucial for the migration project. It is used to estimate the effort that would be required for the development of the tools and the total effort that would be required for the migration. At the end of the technical study a total contractual price is proposed to the customer. During the technical study a small component of the legacy application is usually migrated using generic tools and manually completed to match the code that would be produced using the final tools. This serves as a test for the tool specifications and as a demonstration of the resulting code the customer can expect. If both the price proposed by Sodifrance and the quality of the migrated code are satisfactory to the customer, the project can carry on.

The second phase represented on figure 3 is a tool development phase. The objective is to develop all the tools that have been specified for the migration process. Most of the time the tools do not have to be developed from scratch but are rather re-used or adapted from previous projects. However, most of the time even if the language is the same, the language version and the coding style might be different and require some adaptation.

The third phase represented on figure 3 is a pilot project. The objective of the pilot project is to validate and fine tune the migration process and the tools it uses. It also serves as a demonstration of the viability of the process and allows measuring its efficiency precisely. During this phase, a component of the legacy application is used as a benchmark for the migration process. This component has to be chosen to be as representative as possible of the components of legacy application. In practice the development of the pilot project is truly a testing and debugging phase for the migration tools. For this reason it is usually a lot longer than the migration of a comparable component once the migration process is fully-functional. At the end of the pilot project, the customer is provided with a final price for the project and has a sample of how the new application would look like.

Projects seldom have to stop after the pilot project: the actual migration usually starts shortly afterwards. The preparation of a model-driven migration process can be quite long (the three phases described previously usually require around 6 months to complete but can last up to a year on specific projects such as the one described in section 4), but once the process is up and running, the migration rate can be far more rapid than with any competing techniques. This is discussed in section 5, but before that, the next section presents the modeldriven engineering tools used by Sodifrance to practically implement modeldriven migration.

Model-In-Action (MIA) Tool Suite

Implementing the migration process presented in the previous section requires advanced, scalable and reliable tools for model transformation and code generation. For both the needs of migration project and development projects, Sodifrance has developed Model-In-Action (MIA) [START_REF]Sodifrance: Model-in-action tool-suite[END_REF], a suite of model-driven engineering tools. This section gives a quick overview of these tools.

Figure 4 presents a simplified architecture diagram for the MIA tools. One of the essential requirement for a company like Sodifrance is to be able to adapt to any specific modeling technology used by their clients. In the design of MIA this has been taken into account by creating a generic modeling platform that can connect through various drivers to existing repositories and modelers. On -User environments for model transformation and code generators (MIA developer environments). There are not only standalone versions of these tools but also plug-in versions that integrate directly in the IDEs and modelers of the software developers.

MIA-Transformation is a rule-based model-to-model transformation engine. A model transformation is defined by a set of rules defined between some input meta-models and some output meta-models. Each rule is composed of three elements:

-A context: it corresponds to the set of declared variables and parameters.

-A query: it is an expression that calculates the set of model elements to be processed by the rule. -An action: it can be a creation, a modification or a deletion of model elements and is performed for each model element returned by the query.

When using MIA-Transformation, alternative languages may be used for expressing transformation rules. MIA-Transformation includes both a fully declarative language (close to the declarative form of QVT) and an imperative language.

The two languages can even be mixed in a single transformation rule: the query can be written using the declarative language and the action implemented imperatively. In addition, as rule based transformation has some limitations, it is possible to define transformation services in Java and use them in transformation rules. MIA-Generation is a template based model-to-text transformation engine. The idea of MIA-Generation is to attach text generation scripts directly in metamodels in order to define how each model element should be generated. There are two kinds of scripts:

-Templates that textually describe the piece of code to be generated. -Macros that allow more complex operations such as string handling or model navigation.

The macros are defined directly in Java and can be called from the template. The fact that the generation scripts are directly attached to the meta-model makes MIA text generators easy to understand, adapt and maintain. In addition, the generation engine can keep track of the execution of each generation script and the text it has produced. This provides the developer with all the information required to tune or fix a code generator.

Migration of a Large-Scale Banking Application

This section reports on how the migration process described in section 2 is applied in the context of a large-scale banking application. The migration of this application is part of the modernization of the information systems of a French bank 1 . The objective of the project was to migrate a mainframe system made of around a million lines of code to J2EE in order to ease the maintenance and future evolutions of the system. The overall system is composed of:

-42 applications (for a total of 800 forms and 7500 events) -99 prints and exports using Cristal Report -990 server services -20 batch processes Sodifrance (and their model-driven migration approach) was chosen by the bank for the migration of this system not only because of the quality assurance provided by the use of automation but also for pricing reasons. After an initial study of the project by Sodifrance and several competing companies, the price proposed by Sodifrance was significantly lower than the price of any brute-force redevelopment strategy (out-sourced or not). In the following, section 4.1 presents the customer's requirements and the migration process that has been developed, section 4.2 details the project schedule and section 4.3 discusses the problem of the validation of the migrated application.

Specific Requirements and Migration Process

For the modernization of its information system both the servers and the client applications of the bank had to be migrated. The whole legacy application had been developed using the COOLGEN IDE. COOLGEN provides an intermediate programming language and produces executable application by compiling this language to a combination of C code and COBOL code. For the modernization of the system, the servers had to be migrated to plain COBOL because the code generated by COOLGEN was difficult to maintain and had some performances issues. The 42 client applications had to be migrated from COOLGEN to J2EE web applications. The applications and the servers would communicate through a COBOL/Java middleware. The following focuses on the migration of the 42 client applications from COOLGEN to J2EE. An important requirement of the customer for this project was the strict respect of its internal development standards. All the new applications developed by this bank are generated from Rational Rose UML models. All the models conform to a UML profile developed by the bank itself and specific code generators are used. As a result of the migration process the bank expected to be able to round-trip between models and code using its usual profiles, tools and code generators. The model-driven migration process had to be adapted to take this specific requirement into account.

Figure 5 presents the migration process that is applied to each of the 42 applications of the legacy system. Steps 1 and 2, which correspond to the parsing and reverse-engineering of the application, are similar to the two first phases of the general process presented in section 2. These two phases produce an ANT model of the legacy application which includes all the information contained in the code of the applications (windows, widgets, statements, expressions). Step 3 (also quite similar to the third step of the general process) does the mapping between the source architectural concepts and the target ones to produce a complete platform specific model of the target application.

Steps 4, 5, and 6 of the process presented figure 5 are specific to the banking system migration and designed to produce customer-specific synchronized UML models and source code for the target application. Firstly, step 4 is a model transformation that extracts a UML-profiled model from the ANT application model. The elements of the target application, such as statements, that do not fit in the UML-profiled model are ignored. Then, step 5 consists in using the regular code generator used in all the development projects of the bank to produce code skeletons from the UML model. In regular projects these skeletons have to be filled manually but here the role of step 6 is to automatically generate the final application code in the code skeletons. The manual phase of the migration can then be carried out: the model transformations and the code generators have left notes in the UML model and comments in the code wherever a manual migration task has to be accomplished.

Project Time Schedule and Cost Breakdown

This section details the organization and cost breakdown for the banking system migration. The overall project required a total of 9315 days of work including 7815 for the migration of the 42 client applications. As discussed in section 2 any model-driven migration project has several mandatory initialization phases to design a specific migration process and adapt or develop the required tools. Figure 6 presents the scheduling and the cost (in terms of days of work) for each phase of the banking system migration project.

The first preliminary phase of the project is the technical study. In the case of the banking system it took 3 months and required a total of 209 days of work (which represents about 2.5% of the project effort). Then, the tool development phase and the pilot project took 7 months to complete and required an approximate effort of 800 days of work (around 10% of the project effort). For the pilot project, a representative client application has been chosen among the 42 application that had to be migrated. The delivery of the pilot project occurred 10 months after the beginning of the project and after about 12% of the project effort has been spent.

The important investment and delay before the first delivery is specific to model-driven migration. Moreover, because the preliminary tasks are difficult to parallelize and because the developers need to have a global view of the project to accomplish these tasks, using a large team of developers cannot really help reducing the duration of preliminary work. The developer team for these tasks have to be small (3 to 8 developers for most Sodifrance projects) and should include experts of the source platform, experts of the target platform and model transformation experts.

On the banking application the industrial migration of the 41 remaining application started 3 months after the end of the pilot project. This phase required a total of 19 months to complete. During this industrial phase of the project the migration is performed in parallel by three independent teams of around 15 developers each. Sodifrance migrates three applications at a time, and, during the 19 month period of the industrial migration an average of 2 deliveries are made per month. Contrary to the project preliminary phases that require a small developer team, the industrial migration duration can easily be shortened by increasing the number of developers.

Validation and Quality Assurance

Even with the use of automation, since there is still a significant part of the work done by hand, the migrated application has to be carefully validated in order to check its correctness, performance and integration in its new environment. In practice this is achieved thanks to a strict non-regression testing process. This test process is costly for the customers because they have to provide test cases together with the legacy applications and they have to perform acceptance testing2 . It is also costly for Sodifrance who perform unit testing for the new application and uses the test cases provided with the legacy application to do regression testing. In the case of the banking application the total testing cost is around 3500 days of work (around 1000 days for unit testing and 2500 for regression testing). This represents 45% of the total project cost.

Discussion

This section compares model-driven migration with brute-force re-development migration strategies. The most significant difference between the two approches is the significative preliminary tasks required by model-driven techniques. This section especially discusses the influence of these preliminary tasks on the schedule and cost breakdown of migration projects and shows that for projects over a critical size, the model-driven approach is more profitable than re-development.

Complete re-development has some advantages over automated migration. Firstly the development process is similar to the development of any application except that it has a fixed and non-ambiguous specification. This allows using efficient software engineering techniques which is reassuring and unsurprising to the customer. Secondly, the target application can easily be re-designed, refactored and adapted to the new platform. Thirdly, evolutions to the legacy application can be taken into account in the design of the new application. All these advantages, most of the time combined with out-sourcing to cut workforce cost, allow full re-development to be a common option for modernization.

In this context, thanks to model-driven migration, Sodifrance has managed to provide a comparable quality of service at lower prices to its customers on a number of modernization projects.

Migration Time Schedule

Figure 7 compares re-developpment and model-driven migration with respect to the percentage of code migrated over time. For re-development the model we use is linear: the components of the legacy application are re-developed one by one. For model-driven migration the process is a little different: during the first stage of the project (1) the objective is to develop the tools that will be used to partially automate the migration. During this first stage no code of the new application is produced at all but once the tools are fully functional they typically allow generating about 70 percent of the final application code [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF]. The actual migration can then begin (3), each component of the legacy application is manually completed and delivered to the customer.

The most important difference between the two approaches is the first phase of the model-based process which is an investment in specific tools that will make the migration faster. One of the drawback of model-driven migration is that for an initial period of time, no final code is produced and thus nothing can be delivered to the customer. In the example of figure 7 the legacy application has been divided in 8 components. Using a re-development strategy, the first component can be delivered to the customer just after the beginning of the project. On one the hand the first component is delivered after quite a long period of time: using model-driven migration, when the first component is delivered, 3 components have already been finished with re-development. But on the other hand, using model-driven migration, once the production of the new application has started, the delivery rate can be faster than for re-development. Eventually, the delivery of components developed using the model-driven approach can catch up with the delivery of re-developed components (this is the case for components 7 and 8 on the figure).

In the case of the banking application described previously, the preliminary tasks of the migration project required 10 months which represents about a third of the total project duration. From an economical point of view, more than 10% of the total migration cost was spent on these preliminary tasks. The next subsection discusses the profitability of this investment.

Migration Cost Repartition

To be profitable, the model-driven migration process must be applied on legacy applications that have a sufficient size. Indeed, the effort that has to be invested for developing migration tools mostly depends on the complexity of the input and output platforms but not on the volume of code that has to be migrated. Figure 8 presents an estimation of the cost of a migration project using both model-driven migration and re-development.

In the case of re-development the cost is directly proportional to the size of the legacy application. In the case of model-base migration, there is a fixed initial cost related to the development of tools which is complemented by a linear cost corresponding to manual migration efforts. The gradient of the function corresponding to model-driven migration is lower than the gradient for re-development because using migration tools reduces the manual effort that has to be provided.

A general profitability threshold for model-driven migration cannot be estimated accuratly because it really depends on the ratio of tools that have to be developed for each project. In practice, the experience of Sodifrance on modeldriven migration shows that the profitability threshold for MDE in the context of migration is quite low. Even for projects that require about 1000 days of work, the initial overhead of developing tools pays off. On the migration of the large banking application described previously, Sodifrance estimated that the cost of re-development whould have been around twice the price of model-driven migration.

Benefits and Limitation of Model-Driven Migration

The primary advantage of model-driven migration is to partly automate the migration process. As discussed in the previous sections this allows Sodifrance to significantly lower the prices and duration of migration projects. This is the reason why Sodifrance is often chosen over competing companies that propose full re-development.

The second advantage is to allow for reuse between migration project. This is another element that allows cutting the cost of migration. All the transformations and tools that have been developed for a migration projects can be adapted to future project that have similar input or output platforms.

The first limitation of model-driven migration is a commercial limitation related to the cost and time consumed by preliminary tasks. In the project presented in section 4 the first delivery of migrated code occured after 10 months. This is a commercial issue because after the begining of the project the customer has to wait for a long time without seeing the progression of the project. To mitigate this issue, possible solution is to works in close collaboration with the IT department of the customer and, if possible, to include members of the customer company in the development team.

The second limitation is related to the cost of testing. This is not specific to model-driven migration but is a general problem in software migration. For the banking application discussed previously, testing represents 45% of the total migration cost. This cost does not include the cost of the production of regression tests and acceptance testing which are the responsability of the customer3 . One of the reasons of the important cost of testing tasks is that, for most migration project, they are mostly handled manually. In the same way model-based techniques has been applied to smartly automate repetitives migration tasks, Sodifrance is now studying model-based regression testing using meta-modeling languages such as Kermeta [START_REF] Muller | Weaving executability into objectoriented meta-languages[END_REF] to reduce the cost of testing.

Related Works

Software modernizaton has been identified by the OMG as an important application field for model-driven architecture. The Architecture-Driven Modernization (ADM) is an OMG task force dedicated to this topic [START_REF]OMG: Architecture-driven modernization[END_REF] that aims at building standard metamodels and tools for software modernization. Reus et al. in [START_REF] Reus | Harvesting software systems for mda-based reengineering[END_REF] propose a MDA process for software migration that is quite similar to ours. They parse the text of the original system and build a model of the abstract syntax tree. This model is then tranformed into a pivot language that can be translated into UML. A prototype automates parts of this process using Arc-Styler [5]. Bordbar et al. [START_REF] Bordbar | Integrated model-based software development, data access, and data migration[END_REF] propose a model-based approach for maintenance of data-centric systems. Their MDA approach improves the evolution and maintenance of databases in applications developed with java and modelled with UML. In [START_REF] Zou | Migration to object oriented platforms: a state transformation approach[END_REF], Zou transforms legacy code towards object-oriented languages. Parts of this process are implemented with automatic program transformations.

Another type of works related to the study presented in this paper concerns feedbacks from industrial projects that have applied model-driven approaches. In the last two editions of the MoDELS conference, two studies gave such feedback. In [START_REF] Baker | Model-driven engineering in a large industrial context -motorola case study[END_REF], Baker et al report on the significant improvements in productivity and reliability gained with MDE techniques and also present the remaining issues to profit more from those approaches. In [START_REF] Staron | Adopting model driven software development in industry -a case study at two companies[END_REF], Staron presents a study on the requirements for the adoption of MDE in software industries. The paper reports on the observations of two companies that tried to MDE in their development process. In [START_REF]M1 Global Solutions: Model driven software development and offshore outsourcing[END_REF] M1 Global solution compares MDE and off-shore development. They conclude that MDE tool increased developer productivity by over 50 percent and advocate a combination of MDE for automatic production of a large part of the system and off-shore development for the parts that need to be manually developed.

Conclusion

This paper has precisely presented a model-driven migration and modernization process developed by the Sodifrance company. We have detailed the process and the tools that automate this process. The paper has also dicussed the benefits introduced by MDE in terms of reuse and automation, and also the issues that are introduced to fully benefit from reusable transformations and generators. Finally we have showed that, even if the process is not fully automated and requires manual adaptation from one project to the other as well as manual implementation of some parts of the final application, it is still viable compared to manual re-development.

Even if model-driven engineering is already economically profitable for migration, there are still some important challenges that need to be tackled. A major issue in terms of human effort is testing. Today, regression test is used to validate the migration. However, the production of efficient regression test cases is manual, ad-hoc and difficult to evaluate. Future work consists in adding, in the reverse-engineering phase, a step to reverse a model for high-level control flow in the application in order to eveluate test coverage at use-case level. Moreover, unit and integration test for the migrated code is also very expensive. A possible solution here could consist in generating test objectives when generating the code.

Fig. 1 .-

 1 Fig. 1. Model-driven migration priciple

Fig. 4 .

 4 Fig. 4. Model-In-Action tool suite architecture

Fig. 5 .

 5 Fig. 5. Banking application migration process

Fig. 6 .

 6 Fig. 6. Banking application migration time schedule and cost breakdown

Fig. 7 .

 7 Fig. 7. Migrated code percentage in function of time

Fig. 8 .

 8 Fig. 8. Project cost in function of it size

G. Engels et al. (Eds.): MoDELS 2007, LNCS 4735, pp. 482-497, 2007. c Springer-Verlag Berlin Heidelberg 2007

For confidentiality reasons, and for the protection of Sodifrance customers, this paper does not provide specific details on the migrated application.

The numbers provided in this section do not include this cost. Only the cost for Sodifrance is taken into account.

The production of the tests is a cost that has to be taken into account by the client. However, this cost is usually far lower than the cost of providing the complete specifications required for full re-development.


Franck Fleurey
email: ffleurey@irisa.fr

Benoit Baudry
email: bbaudry@irisa.fr

Robert France
email: france@cs.colostate.edu

Sudipto Ghosh
email: ghosh@cs.colostate.edu

A Generic Approach For Automatic Model Composition

Analyzing and modelling a software system with separate views is a good practice to deal with complexity and maintainability. When adopting such a modular approach for modelling, it is necessary to have the ability to automatically compose models to build a global view of the system. In this paper we propose a generic framework for composition that is independent from a modelling language. We define a process for adapting this framework to particular modelling language (defined with a metamodel) and illustrate how the generic composition has been specialized for class diagrams.

Introduction

When using aspect-oriented modelling to build the model for a large system, the modellers identify different views. They model each view and reason about these separate models. They can also perform validation tasks on each model, for example using model checking techniques. Once all these models have been correctly built in isolation, it is necessary to compose these different models. The composed model can be used to

• check the global consistency of the system's model,

• better understand the interactions across the composed views • analyze interactions to identify conflicts and undesirable emergent behaviours When the models are small enough and developed by a single or a couple of designers, they can be composed manually. However, in most cases, the models are too large to be composed manually and it is necessary to develop an automatic composition operator to ensure that all the elements in the model are handled. Moreover, an automatic composition operator allows the designer to try different solutions for composition that correspond to different decision (e.g., try different orders for composition, or different solutions for one view…).

There exist several solutions to automatically compose models in different languages (class diagrams [START_REF] Baniassad | Theme: An Approach for Aspect-Oriented Analysis and Design[END_REF][START_REF] Reddy | Directives for Composing Aspect-Oriented Design Class Models[END_REF], statecharts [START_REF] Nejati | Matching and Merging of Statecharts Specifications[END_REF], sequence diagrams [START_REF] Klein | Semantic-based Weaving of Scenarios[END_REF]…). If there is no composition operator for one modelling language, it is necessary to build a completely new operator for this language. In the future, there might be more and more domain-specific modelling language developed for model-driven development.

In that case, we do not want to generate a new algorithm and a new environment for each language. It becomes necessary to reuse algorithmic and design knowledge from composition operators in other languages.

In this paper we propose a generic framework for automatic model composition. There are two main steps for composition: matching and merging. The matching step is specific to a modelling language. It specifies which element in the language can match and how they can match. The merge step can be defined independently from any language. The framework we propose implements a generic merge operator. It defines, how two model elements that match are merged, as well as a mechanism for conflict detection. The framework also implements a language to specify composition directives as they are defined by Reddy et al. [START_REF] Reddy | Directives for Composing Aspect-Oriented Design Class Models[END_REF] and specifies a clear interface to specify a match operator. This framework can then be specialized for a particular metamodel in order to add composition capabilities to a particular language.

In section 2 we discuss the generic framework for model composition. In section 3 we explain how this framework can be specialized to add composition capabilities to a particular metamodel and in section 4 we illustrate this specialization on an example.

A generic framework for model composition

This section describes the generic composition algorithm that is implemented in the generic composition framework. The composition mechanism implemented in this framework is structured in two major steps:

1 Matching: identifies model elements that describe the same concepts in the different models that have to be composed. 2

Merging: matched model elements are merged to create new model elements that represent an integrated view of the concepts. The merging operator builds a new model from two models. It merges elements that match according to the matching operator and creates new elements in the target composed model. This operator is independent of a specific domain. It consists in going through the set of elements that match in both input models and if they can be merged the operator creates a new model element in the output model. If the elements can not be merged, a conflict is detected that has to be solved. This happens when elements that match based on a subset of their properties (e.g., when merging two class diagrams, classes with same names match) can not be merged because of other properties that do not match (e.g., if there is one concrete class and one abstract class). The whole process of conflict detection and model elements creation is generic.

The semantics of matching is domain specific. The knowledge for detecting model elements that describe the same concept is based on information dependent on the meaning of the model. Thus, the matching operation has to be specialized for each modelling language. However, in order to interact correctly with the merging operator, the matching operator has to have a clear interface.

The generic framework described in this section implements the behaviour of the merging operator and offers a precise interface for the definition of the matching operator. The framework can then be specialized by providing specific matching operators through this interface.

2.1

Generic framework for composition

Figure 1 describes the class diagram of the generic composition framework. It defines the interface of a matching operator for a specific metamodel and it implements the merging operator that is independent of any metamodel.

The abstract operation getSignature in MERGEABLE has to be specialized to define the algorithm for matching elements. The getSignature operation defines the signature of the model elements. This signature is compared with the signature of other model elements to check if these elements have to be merged. A default comparison is implemented in the equals operation of STRINGSIGNATURE. This operation can be specialized in other subclasses of SIGNATURE in order to compare signatures which are more complex than simple strings.

For example, two methods in a class diagram can match because they have the same name or because they have the same name and the same parameters. In the first case, the getSignature operation will return the name of the methods and the default equals is sufficient. In the second case getSignature will return the name and the list of parameters and it is necessary to redefine the equals operation.

The merge operation in class MERGEABLE implements the generic algorithm for merging two model elements. The complete algorithm is defined in [START_REF] Reddy | Model composition -a signature-based approach[END_REF]. If two model elements match according to their signature, this operation tries to merge them into a new model elements. The algorithm compares the values of each property of the elements to merge to detect possible conflict. If no conflict is detected the new model element is created, otherwise the conflict must be solved using composition directives.

The class CompositionContext contains the data structures and utility methods that are used by the merge operation in order to create the merged elements and keep a traceability information between the input models and the composed model.

The composition directives

Modellers can specify composition directives that are used during composition to force matches, disallow merges, and to override default merge rules. Two types of composition directives are currently supported in the composition metamodel:

• Pre-Merge Directives: These directives specify simple model modifications that are to be made before the models are merged. These changes will force or disallow element matches. These directives can specify renaming model elements, removing or adding elements. • Post-Merge Directives: These directives specify simple modifications to the merged model. For example, it may be the case that a security view requires the removal of associations that are present in other views. This restriction can be specified as post-merge directives that remove these associations from the merged model. The language for model directives is domain independent and is part of the generic composition framework. The metamodel for this language is shown Figure 2. There are two main types of directives: CREATE and CHANGE directives. CREATE directives are used to create new model elements. CHANGE directives are used to modify model elements. These directives can be used to remove an element from a namespace, set a property value associated with an element, and add an element to a namespace. A CHANGE directive is associated with a reference to the model element it modifies.

A SET directive is associated with two instances of ELEMENTREF one is the target property and the other is the new value for the property. Elements can be reference by (1) a name that is an instance of NAMEREF, (2) their literal value, or (3) a unique identifier that is an instance of IDREF.

Figure 2 -The composition directives language 3 Specializing the framework for a particular metamodel

This section summarizes how to specialize the generic framework to add composition capabilities to a metamodel. The framework has been defined in such a way that it can be specialized for any metamodel that conforms to EMOF. The specialization process is described in Figure 3.

Generic

+

Specific for M meta-model

Figure 3 -Adding composition capabilities in a metamodel

To specialize the generic composition framework, for a metamodel M, it is necessary to define a composition strategy. This strategy specifies which elements of the metamodel can be merged. This consists in selecting the classes in the metamodel that will have composition capabilities, i.e., the classes which instances will be composable in models that conform to M. The strategy defines the equality between elements, and the signature of these elements.

The composition strategy is a model with major parts: the classes of the metamodel M that are mergeable and how the signatures are computed and the classes that define comparison between signatures. The classes of M that are mergeable inherit from MERGEABLE in the strategy and they implement the getSignature operation. The other classes of the strategy specialize the SIGNATURE class of the generic framework. These subclasses specialize the equals operation that defines the equality between two model elements. We can notice that the generic framework defines a default behaviour for the equals operation. Thus, it is not mandatory to specialize the SIGNATURE class.

Once the strategy is modelled it can be composed with the metamodel M. As a result of the composition, the metamodel M is augmented with the classes and methods that are necessary to provide composition capabilities. Moreover, the resulting metamodel M' inherits form all the operations implemented in the generic framework through inheritance relationships with the MERGEABLE and SIGNATURE classes.

M' is obtained using the composition mechanism of Kermeta1 [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF]. This composition only allows adding operations and classes in a metamodel and ensures that every model that conforms to the original metamodel can be viewed as an instance of the composed metamodel. Thus the models that conform to M also conform to M' and can be composed thanks to the capabilities added in M'.

An example for composing Ecore models

In this section we illustrate the specialization of the framework to compose models that conform to the Ecore metamodel. Figure 4 shows the Ecore metamodel that is very close to the metamodel for class diagrams. The metamodel defines packages that are composed of classifiers. There are two types of classifiers: classes or data types. The enumeration is the only data type present here. Classes are composed of structural features which can be attributes or references to other classes. Classes also contain operations which have attributes. This metamodel can be seen as a simplified metamodel for class diagrams.

For the composition of two models that conform to the Ecore metamodel, it is necessary to define a specific matching operator. The merging operator is reused from the generic framework. Figure 5 shows the model of the composition strategy for Ecore models. This model specializes the generic framework to define a specific matching operator for Ecore models.

Figure 4 -The Ecore metamodel

According to the model in Figure 5, EMODELELEMENT (of the Ecore metamodel) inherits from MERGEABLE (from the generic framework). This means that all model elements from Ecore have to implement the getSignature operation. However, the operation only has to be implemented three times in the case of the Ecore metamodel. A default signature corresponding to their name is associated with all ENAMEDELEMENT. This signature is used to match classes, data types, attributes and references. For operations and parameters specific signatures have to be defined. Two operations will match only if they have the same names, parameters that match and the same return type. Two parameters will match only if they have both the same name and the same type.

Figure 5 -The composition strategy model for Ecore

Both the generic framework presented in the previous section and its specialization for adding composition capabilities to the Ecore meta-model have been implemented in an open-source tool called Kompose [START_REF] Fleurey | Kompose : a generic model composition tool[END_REF]. Kompose was built using the Kermeta language and integrated in the Eclipse IDE as a plug-in. A complete demo of the tool can be found in [START_REF] Fleurey | Kompose : a generic model composition tool[END_REF]. Figure 6

Conclusion

In this paper we detailed a reusable framework for model composition. This framework implements a generic model composition operator that can be specialized for any specific meta-model. This operator is based on signatures associated with model elements for matching objects and uses a generic algorithm for merging objects. We have defined a generic composition directive language for the resolution of potential composition conflicts. It allows both to adapt input models and to fix the composed model. The proposed technique has been implemented as an open-source tool using the Kermeta language.

The main advantage of the proposed approach is to allow easily defining composition operators for new modelling languages. This is especially interesting in a context where domain specific modelling languages are more and more popular. The generic framework is specialized by decorating the meta-model of the language with signatures. These signatures allow capturing semantic elements of the modelling language in order to produce a meaningful composition operator.

The principal limitation of the proposed approach is that to be reusable the framework only relies on the structure of the models to compose. The signatures are the only elements which can be used to take into account some semantics of models to compose. Our current experiments show that it is not an issue when working with structural models such as class diagrams, database schemas or components model but it becomes a clear limitation when working with modelling languages such as sequence diagrams.

To produce a meaningful composition operator for sequence diagrams, the order in which events and messages have to be composed is based on the semantics of sequence diagrams [START_REF] Klein | Weaving multiple aspects in sequence diagrams[END_REF]. Using the current version of our composition framework, the only way to implement such a composition operator is to redefine the generic merge operation for the classes of the sequence diagram meta-model which contain properties that have to be semantically composed. For these classes there is no clear benefit from extending the generic framework as the merging algorithm has to be fully redefined.

As a future work to what is presented in this paper we are currently investigating a finer-grained redefinition mechanism that allows redefining independently the composition strategy for each property of the modelling language meta-model. This allows focusing on properties that require special semantic composition and benefit from the generic implementation for the others.

Figure 1 -

 1 Figure 1 -Generic framework for Composition

Figure 6 -

 6 Figure 6 -The composition strategy model for Ecore

It can be noticed that the composition operation in Kermeta is a specialization of the generic framework presented here..