The evolution of a metamodel may render its related terminal models invalid. This use case proposes a three-step solution that automatically adapts terminal models to their evolving metamodels. The main contribution is the precise detection of metamodel changes by using the AtlanMod Matching Language (AML), a DSL built on top of ATL and AMW. The running example is the Petrinet models.
|AML, AMW, and ATL 3.0 are required to execute this use case.|
Metamodel Evolution, Model Adaptation, Model Transformation, Petrinet.
This use case presents a solution to the model adaptation problem. This solution has been presented in . Figure 1 illustrates the problem: a metamodel MM1 evolves into a metamodel MM2 (see the dotted arrow). Our concern is to adapt any terminal model M1 conforming to MM1 to the new metamodel version MM2 (see the dashed arrow).
The use case proposes a three-step adaptation (see Figure 2). Firstly, an matching strategy computes the equivalences and changes between MM1 and MM2. Secondly, a HOT derives an ATL transformation from the discovered equivalences and changes. Finally, this transformation brings M1 into agreement with MM2, and persists the result in M2. We implement the prototype on the AMMA platform. More specifically, we use the AtlanMod Matching Language (AML) to specify the matching strategy, AMW to work with models of equivalences and changes, and ATL to implement the HOT. The HOT generates the adaptation transformation in ATL code too.
The bulk of this use case is devoted to the first step that discovers equivalences, as well as simple and complex changes. We explicitly distinguish two kinds of changes because complex changes need a more insightful adaptation that simple changes. Whereas a simple change describes the addition, deletion, or update of one metamodel concept, a complex change integrates a set of actions affecting multiple concepts. The reader interested on examples of simple and complex changes may consult .
The running example is based on the two versions of the Petri Net metamodel provided by . Figure 3 illustrates versions 0 (MM1) and 2 (MM2). MM1 represents simple Petri Nets. These nets may consist of any number of places and transitions. A transition has at least one input and one output place. MM2 represents more complex Petri Nets. The extraction of the reference dst illustrates a complex change named Extract class. This implies to add and remove a reference, add a class, and associate classes. In considering these actions as isolated simple changes, we may skip changes without migrating involved data from M1 to M2. In contrast, when we distinguish the complex change, we infer (for instance) that the added property (e.g., dst), contained in the new class PTArc, actually corresponds to the property dst removed from the class Place. Since we know the relationship between the properties we can migrate the data. We thus need to explicitly distinguish complex changes in order to properly derive adaptation transformations.
First step - Matching equivalences and changes
Model of equivalences and changesBefore describing the matching step, we explain how matching models represent equivalences and changes. Such models conforms to the Matching metamodel (which extends the AMW core metamodel) illustrated in Figure 4. The main concept is Equal which describes a mapping (or correspondence) between an element of MM1 (leftElement) and an element of MM2 (rightElement). Equal has a similarity value (between 0 and 1) that represents the plausibility of the correspondence. An equivalence with similarity value 1 represents that the MM2 element is an identical copy of the MM1 element. An equivalence with similarity value 0.7 describes that the MM2 element is a copy of the MM1 element including simple modifications. An equivalence with similarity value 0 link elements different to each other. Other basic concepts are Added and Deleted which mark a metamodel element as deleted/added from/into MM1.
Matching stepMatching models are computed by AML strategies, i.e., processes that incrementally execute a set of ATL transformations. Figure 5 shows an excerpt of the used AML strategy. This indicates how ATL transformations (generated by the AML compiler) interact each other to deliver the equivalences and changes.
The transformations above are generic enough to be applied to many use cases. It is ConceptualLink the one that figures out complex changes, and therefore leverages the solution to the model adaptation problem. For example, Figure 6 shows a rule that verifies if change Extract Class has happened. The helper 'isExtractClass' evaluates if: 1) there is a relation between the owner classes of the structural features referenced by EqualStructuralFeature 2) the right class is a new class. If the conditions are satisfied, the rule decorates a simple equivalence with the type ExtractClass.
Note that our approach may need the user to refine the results. The refinement can happen at high-abstraction level, i.e., over final matching models, or at low-abstraction level, i.e., over generated adaptation transformations.
Second step - Translation to adaptation transformationsIn this step, the equivalences and differences are translated into an ATL adaptation transformation via a HOT.
Figure 7 shows an ATL adaptation transformation which is generated by the HOT. This creates the transformation rule Place2Place (line 5) from the equivalence (Place, Place). The from part matches the elements conforming to Place (lines 7-9). The to part creates elements conforming to Place. The HOT moreover generates a complex binding (see lines 13-14) from the equivalence (out, dst). The binding calls a lazy rule (i.e., PTArc) to initialize dst and src of PTArc (lines 20-29) using the values Transition and Place.
Third step - Adaptation transformation executionThis step simply executes the generated adaptation transformation. The transformation takes any terminal model M1 and generates a terminal model M2.
|This use case introduces the fundamentals behind AML strategies.|
Metamodel Comparison and Model Migration
|An application of matching to model migration. The difference between the model migration use case and our use case is that the latter uses AML to automatically generate the ATL transformations.|
|||Garces, K., Jouault, F., Cointe, P., Bezivin, J.: Managing Model Adaptation by Precise Detection of Metamodel Changes. In: In Proc. of ECMDA 2009, Enschede, The Netherlands, Springer, 2009.|
|||Garces K., Jouault F., Cointe P., Bezivin J., Practical Adaptation of Models to Evolving Metamodels, Technical report, INRIA, 2008.|
|||Wachsmuth G., Metamodel Adaptation and Model Co-adaptation, in E. Ernst (ed.), ECOOP 2007, Berlin, Germany, Proceedings, vol. 4609 of Lecture Notes in Computer Science, Springer, 2007.|
|||Melnik S., Garcia-Molina H., Rahm E., Similarity Flooding: A Versatile Graph Matching Algorithm and ist Application to Schema Matching, Proc. 18th ICDE, San Jose, CA, 2002.|
|A psf file that points to the Adaptation AML project. Please download this file on your local disk, and then import the project in Eclipse using : File->Import->Team->Team Project Set. Besides the Adaptation project, you need the AMLLibrary project, find here the instructions to download it. Finally, the file 'Readme.txt' contains all the instructions to execute the AML strategy.|
|We encourage you to look at this demo which shows the main AML functionalities|
|This work has been partially funded by the FLFS ANR project (Families of Language for Families of Systems).|
Back to the top