Metamodel evolution and model co-evolution are considered to be essential ingredients for the successful adoption of model-driven engineering in practice. In this respect, on the one hand, dedicated coevolution languages have been proposed for migrating models conforming to an initial metamodel to models conforming to a revised metamodel with the drawback of requiring to learn a new language. On the other hand, the employment of dedicated model-to-model transformation languages has been proposed demanding for the speci cation of rules for copying unchanged elements. In this paper, we propose to tackle the co-evolution problem from a di erent viewpoint. Instead of describing the co-evolution of models as a transformation between two metamodels, we employ existing inplace transformation languages. For this, the prerequisite is to represent both language versions within one metamodel which is automatically computed by merging the initial and the revised metamodel. This ensures that the initial as well as the revised model conform to the merged metamodel, enabling the employment of inplace transformations for initializing new metamodel elements. Finally, a check-out transformation is used for eliminating model elements which are no longer covered by the revised metamodel. We demonstrate this idea by using ATL for merging the metamodels and realizing the check-out transformation. Furthermore, we discuss the ATL re nement mode for co-evolving the models.
Metamodel evolution and model co-evolution are considered to be essential
ingredients for the successful adoption of Model-Driven Engineering in practice.
Especially, when domain-speci c modeling languages are employed, the
necessity of language adaptations arise to re ect changes in the modeling domain
as well as in technologies without losing existing models. Thus, (i) dedicated
co-evolution languages (e.g., COPE [
In this paper, we tackle the co-evolution problem from a di erent viewpoint.
Instead of describing the co-evolution of models as transformation between two
metamodels, we employ existing inplace transformation languages for this task.
For being able to employ inplace transformations, the prerequisite is to represent
both language versions within one metamodel which is automatically computed
by merging the initial and the revised metamodel. Thereby, it is ensured that the
original model as well as the to be evolved model always conform to the merged
metamodel. After performing the co-evolution by specifying inplace
transformation rules which add or update elements according to the revised metamodel,
the co-evolution process is completed by a fully automated check-out
transformation eliminating model elements which are no longer covered by the revised
metamodel. We demonstrate this idea by using ATL for merging the metamodels
as well as for the check-out transformation. Furthermore, we discuss the ATL
re nement mode for co-evolving the models. Please note that the focus of this
paper is how to support breaking and (non-)resolvable metamodel changes [
The remainder of this paper is structured as follows. Section 2 introduces a co-evolution scenario which is used as running example throughout the paper. Section 3 presents (i) the conceptual architecture of our approach, (ii) the metamodel merging algorithm, (iii) the co-evolution rules expressed as inplace transformations, and (iv) how the check-out transformation is derived. Related work is discussed in Section 4, and nally, the paper is concluded with an outlook on future work in Section 5. 2
To elaborate on our co-evolution approach, we introduce in this section an evolution scenario, namely the evolution of a small domain speci c modeling language which is inspired by the UML class diagram language. Fig. 1 illustrates the scenario which serves as a running example throughout the rest of the paper. In the upper part of Fig. 1, the initial metamodel MM is illustrated. The metamodel comprises four modeling concepts being Class, Reference, ID Attribute (identifying attributes), and Desc Attribute (descriptive attributes). A Class may extend another Class (reference extends) and may be marked as being abstract (attribute isAbstract). A Reference has an opposite reference, actually representing a bi-directional association, and comprises an upper multiplicity (attribute upperMult) as well as a lower multiplicity (attribute lowerMult). opposite 1..1
upperMult: Int lowerMult: Int 0..* references MM MM‘
isAbstract: Boolean 1..1 type { Change Request 1: Modeling of ternary associations. The modelers request that they need, in addition to bi-directional associations, the possibility to describe ternary associations. { Change Request 2: Change attribute kind dynamically. The modelers have explored that during establishing models it is often necessary to change the attribute kind from identifying to descriptive and vice versa. This is currently only possible by deleting the attribute and by creating a new one. { Change Request 3: Extends reference is too Java-speci c. Some modelers complaint that the inheritance feature of the modeling language should be named superClass instead of extend to be more platform independent.
The lower part of Fig. 1 illustrates the revised metamodel M M 0 incorporating the requested changes. For re ecting change request 1, a new class Association is introduced which may contain two or three references. The subclasses of the class Attribute are deleted and the class Attribute is changed to a concrete class. For distinguishing between identifying and descriptive attributes, the class Attribute now holds an additional attribute named id of type Boolean.
For migrating existing models to the revised metamodel M M 0, the changes have also to be re ected on the model level. Therefore, four co-evolution rules (please note that change request 2 results in rule 2 and in rule 3) are needed to transform the existing models conforming to M M to models conforming to M M 0.
{ Rule 1: Create associations for reference pairs. For each reference pair, i.e., two references which link each other as opposite references, an association has to be created which contains both references. { Rule 2: Convert identifying attributes. For each identifying attribute, i.e., instance of ID Attribute, an instance of class Attribute has to be created whereby the id attribute has to be set to true. { Rule 3: Convert descriptive attributes. For each descriptive attribute, i.e., instance of Desc Attribute, also an instance of class Attribute has to be created but with the di erence that the id attribute has to be set to false. { Rule 4: Set Class.superClass reference. Finally, for each class, the new reference superClass in M M 0 has to be set according to the existing extends reference in MM. 3
In this section, we elaborate on how to apply inplace transformations for coevolution of models if changes to the metamodel have been made. As we have seen in the previous section, some metamodel elements remained unchanged, some have been deleted, and some have been introduced. Thus, if we want to migrate a model conforming to the initial metamodel to a model conforming to the revised metamodel, we have to copy some model elements, we have to delete some, and some new elements have to be created. However, this viewpoint is inspired from existing approaches which tackle co-evolution by creating completely new models which conform to the revised metamodel from existing ones.
In our opinion, inplace transformations would be a natural choice when the evolution of a model has to be described. However, due to the fact that we have two di erent metamodels3, inplace transformations are currently not used for this task. This is quite di erent to other model evolution scenarios where only one metamodel is used such as describing the simulation/execution of models.
For employing inplace transformations also for co-evolution scenarios, we propose the following process which is shown on a conceptual level in Fig. 2. First, in order to use inplace transformations, we need a special kind of uni cation of both metamodel versions (cf. Step 1 in Fig. 2). The uni cation is done in a way that the existing models M, which conform to the initial metamodel MM, also conform to the uni ed metamodel M M [ M M 0. By this, we do not have to cope with any copy operations for the constant parts of the model (i.e., instances of the unchanged metamodel elements). The uni ed metamodel is now the key to employ inplace transformations for initializing the newly introduced metamodel elements of MM' in the initialization phase (cf. Step 2 in Fig. 2). The output of 3 Even though, the di erences between the metamodels are minimal in most cases, technically we are concerned with two metamodels. initialize 2
1 merge the inplace tranMsMformatMioMn‘ is the initMiMal modMeMl‘which is exMteMnded wMMit‘h instances of the new metamodel elements created by the rules of the inplace transformation. The rejection of old elemeinnittisali(zecf. Step 3 in Firgej.ec2t), i.e., elements which are only covered by MMM, is done by a M2MM tMr‘ansformation whichM‘is automatically computed by matching the uni ed metamodel with the revised metamodel and by generating a transformation rule for each match.
In the following weCod‐eesvcorilubaetitohnetraepapterdoaSceht‐tihnemoroertiecadlleytail. First, we elaborate on how the two metamodels are merged into one metamodel unifying both language versions. Second, we present how to use inplace transformations for instantiating new model elements which are derived from the existing context. Third, we discuss how to match the merged metamodel with the revised metamodel to derive all necessary transformation rules to check-out a model which solely conforms to the revised metamodel, i.e., all elements which are no longer covered by the metamodel are rejected. The prerequisite for employing inplace transformations is that we have a uni ed metamodel which is capable of representing the commonalities of both metamodel versions as well as their di erences. In Fig. 3, the co-evolution of models is illustrated by using set theory. We start with a model which consists of elements which are all covered by the initial metamodel MM as well as partly by the revised metamodel MM'. From this set, additional elements are computed which are only covered by MM', however, the model still contains elements covered only by MM. Finally, these elements are rejected by the check-out transformation which produces a model which only consists of elements covered by MM'.
In order to support this process, the uni ed metamodel must be created as explained in the following. First, only corresponding elements, i.e., classes, attributes, and references, are merged into one element. For example, if two attributes have the same name and the same type, but a di erent cardinality, they cannot be merged into one element. The reason for this is that if they are merged into one element, we cannot represent the di erent cardinalities. Therefore, they have to be both incorporated in the uni ed metamodel by independent elements.
In the following we explain the merge algorithm which is shown as pseudo code in Algorithm 1. Please note that we only consider classes and their features, i.e., attributes and references, in the pseudo code whereas other elements of MOF such as packages are not discussed in the paper.
First of all classes are merged together if they have the same name, since we assume that the class name being unique. If two classes are found with the same name, the merge of these two classes is achieved by introducing a new class which gets the union of the features and superclasses of both classes. Furthermore, the class is only de ned as abstract class if both classes are abstract. If no name match is found, the class is directly added to the merged metamodel.
In contrast to classes which have only to correspond concerning their names, features have to correspond totally. This means that they have to be equivalent in all their meta-features such as name, type, multiplicity, unique constraints and so on. Note that if an equally named attribute occurs in the original and in the revised version but they o er, e.g., a di erent type, both attributes have to be considered in the merged metamodel. If no total match is found, the feature is simply added to the merged metamodel.
Fig. 4. Merged metamodel for the metamodels of Fig. 1 (1) create a Association foreach r1:Reference, r2:Reference (r1.opposite = r2) { a.name = r1.name + “2“ +r2.name, a.refEnds = {r1,r2} } (2) create a Attribute foreach a1:ID_Attribute {
a.id = true, a.name = a1.name } (3) //analog for Desc_Attribute (4) foreach c Class {
c.superClass = c.extends } Input: initialMM, revisedMM Output: mergedMM // create empty mergedMM 1 mergedMM = new MM()
// Add classes to mergedMM 2 for originalClass 2 Class.allInstancesFrom ( initialMM) do 3 Class revisedClass = findEquivalentClass (revisedMM, originalClass) 4 if revisedClass <> OclUnde ned then 5 Class modif iedClass = new Class () 6 modif iedClass.name = originalClass.name 7 modif iedClass.abstract = originalClass.abstract and
revisedClass.abstract 8 modif iedClass.features =
originalClass.features.union(revisedClass.features) 9 modif iedClass.superClasses = originalClass.superClasses.union(revisedClass.superClasses) mergedMM.add(modif iedClass.Annotate ('both')) 10 11 end 12 else 13 mergedMM.add(originalClass.Annotate ('old')) 14 end 15 end 16 for revisedClass 2 Class.allInstancesFrom ( revisedMM) do 17 Class originalClass = findEquivalentClass (initialMM, revisedClass) 18 if originalClass = OclUnde ned then 19 mergedMM.add(revisedClass.Annotate ('new')) 20 end 21 end
// Add features to mergedMM 22 for originalF eature 2 Feature.allInstancesFrom ( initialMM) do 23 Feature revisedF eature = findEquivalentFeature (revisedMM, originalF eature) 24 if revisedF eature <> OclUnde ned then 25 getContainer (originalF eature).add(originalF eature.Annotate ('both')) 33 34 35 36 end end getContainer (originalF eature).add(originalF eature.Annotate ('old')) 29 end 30 end 31 for revisedF eature 2 Feature.allInstancesFrom ( revisedMM) do 32 Feature originalF eature = findEquivalentFeature (initialMM, revisedF eature) if originalF eature = OclUnde ned then getContainer (revisedF eature).add(revisedF eature.Annotate ('new')) Algorithm 1: Merge Algorithm
We have implemented the merge algorithm as an ATL model-to-model transformation by using only declarative rules. The transformation takes two input models, i.e., the initial metamodel and the revised metamodel, and one output model, i.e., the uni ed model. The complete ATL code and the example models for testing the code can be found on our project page4.
Instantiation conformance. Because we copy each element of the initial metamodel into the revised metamodel, the existing models conform to the merged metamodel. However, there are some exceptions, namely required features which are coming from the revised metamodel. For example, please imagine that the superClass reference in Fig. 4 is mandatory. Of course, the existing models would not contain such links, thus, we would have a violation of the metamodel constraints. However, these violations are only requiring additional elements which are currently not present. All present elements are conforming to a subset of the merged metamodel, i.e., the initial metamodel. What we have explored is that current modeling tools as well as transformation engines ignore violations which require further elements in the model. These issues are only reported by executing additional validation checks, but fortunately the models are loadable and usable in current modeling tools and transformation engines. 3.2
Instantiating new Metamodel Elements with Inplace
Transformations
After generating a uni ed metamodel as discussed in the previous subsection, we
are now able to instantiate the introduced metamodel elements from the context
of the initial model with the help of inplace transformations. Fig. 5 shows the
necessary transformation rules on a conceptual level in the AGG graph
transformation syntax [
Rule 1 is used for instantiating the new class Association. As can be seen in the LHS of the rule, we match for all reference pairs which are connected via an opposite link. For each match, an association is introduced in the model which is connected to matched references (cf. RHS of Rule 1) if no association already exists which links the matched references. This is ensured by the negative application condition (NAC). The second rule is used for creating an instance of Attribute for each instance of ID Attribute. This is done by de ning such a new instance on the RHS and connecting this instance to the class which also contains the id attribute. Finally, Rule 4 simple generates for each extends link between two classes an additional superClass link.
Implementation with ATL Re nement Mode. We have implemented the rules shown in Fig. 5 in ATL using the re nement mode. The resulting transformation de nition for the co-evolution rules is presented in Listing 1.1. Whereas Rule 4 can be implemented by the provided language constructs and execution 4 www.modeltransformation.net
NAC assoc2 : Association 1 leu 6 : refEnds 5 : refEnds R ref2: Reference ref1 : Reference
LHS cl1 : Class 2 leu 1 : attributes R att1: ID_Attribute name = x type = t ref1 : Reference name = x 2 : opposite 1 : opposite ref2 : Reference name = y
RHS cl1 : Class
2 : attributes att2 : Attribute name = x type = t id = true
RHS 3 : refEnds ref1 : Reference 4 e l u R naasmseoc=1x:+A“s2s“o+cyiation 2 : opposite 1 : opposite
ref2 : Reference 4 : refEnds LHS
RHS superCl : Class
superCl : Class 1 : extends subCl: Class 1 : extends 2 : superClass subCl: Class semantics of the ATL re nement mode, the Rules 1-3 can not as detailed in the following.
No Type Changes. For Rule 2 and 3, we explored that it is not possible to write the ATL rules as concise as it is shown in Fig. 5. For example, for creating an Attribute for each ID Attribute, we started with a declarative rule consisting of a from block for matching the ID Attributes and a to block for generating the Attributes. However, when executing the described rule, we ended up again with ID Attributes in the output model, only. It was neither possible to upcast the existing instances nor was it possible to generate new attribute instances. Thus, we modi ed the to block for dealing with the existing id attributes by the rst target pattern (cf. line 19) and an additional target pattern for creating new attributes (cf. line 20).
No Queryable Execution State. Another issue we encountered was the unsupported query of the transformation state which is in particular necessary for implementing the NAC of Rule 1. As we have mentioned before, we have to check when generating an association, if an association has been already created for a reference pair (each pair is matched twice because of binding a particular reference to variable ref1 in one match and to variable ref2 in another). This check was not possible for us to implement as additional guard clause due to the fact that only the initial input model can be matched.
No Imperative Code. For overcoming the restriction mentioned above, we
tried to solve this issue by storing the already matched References in a global
helper. Nevertheless, it was not possible to add new elements to the global helper
during transformation, since no imperative language constructs, i.e., calls in the
do block, are supported in the re ning mode.
After initializing the newly introduced metamodel elements of the revised
metamodel, it is now time to modify the extended model in order to conform solely
to the revised metamodel (cf. reject arrow in Fig. 2 and 3). This step is
automatically achieved in our approach by comparing the uni ed metamodel with the
revised metamodel by using a matching transformation inspired by [
Listing 1.1. Co-evolution rules expressed in ATL to dummy : MM! Re f er e nc e , a s s o c : MM! A s s o c i a t i o n ( r e f E n d s <
Set f r e f 1 , r e f 2 g) 4
Co-evolution has been subject for research since the introduction of the rst
object-oriented database systems [
Garces et al. [
Cicchetti et al. [
Wachsmuth [
In [
Herrmannsdoerfer et al. propose in [
Summarizing, our approach is di erent to the mentioned approaches, because
we tackle co-evolution of models with existing inplace transformation languages
instead of using domain-speci c languages or M2M transformation languages.
By using our specialized metamodel merging algorithm, we do not have to copy
elements which are resistant to the metamodel changes as is also supported by
COPE. However, our approach allows the automatic elimination of old model
elements which are no longer covered by the revised metamodel, which in contrast
has to be manually developed with COPE. The rst four approaches use M2M
transformation languages which are partly supported by automatic derivation
of transformations. However, the non-automatically derived parts have to be
manually de ned which seems to be more challenging for the user in comparison
to using inplace transformations, because s/he has to reason on how elements
look like in the source model, how elements are represented in the target model,
and how they are transformed by analyzing the trace information enforcing the
user to work with three models. In contrast, in our approach, only one model is
necessary for de ning the co-evolution rules by using our uni ed metamodel in
combination with inplace transformations. For computing the check-out
transformation for generating the nally co-evolved models, we are using a similar
approach as Graces et al. [
In this paper we have reported on our rst experiments using inplace transformations for model co-evolution. Our experiences indicates that co-evolution of models may be easily described with current inplace transformation languages. However, the ATL re nement mode currently has some limitations compared to the M2M mode which complicate the de nition of co-evolution rules. An improvement for de ning co-evolution rules would be to allow for imperative parts in the ATL re nement mode which are possible in M2M ATL transformations and to match also on intermediate transformation results.
For applying inplace transformations, we provide an automatic merge of two metamodel versions into a uni ed metamodel and by matching transformations we are able to generate check-out transformations, so the user can focus on describing the co-evolution rules in her/his inplace transformation language of choice. In particular, the user only has to instantiate new metamodel elements and modify existing elements if needed, but s/he is not concerned with copying constant elements or deleting no longer supported elements. One co-evolution scenario has not been mentioned, namely the elimination of instances which are in principle covered by the revised metamodel. Consider the example that abstract classes should no longer be supported, meaning that only concrete classes are migrated. This kind of elimination is a selection and not a projection automatically achieved by the check-out transformation. Thus, selections have to be de ned by the user again by employing inplace transformation rules in step 2 of our approach. We are currently investigating such scenarios in ongoing work.
For future work we see many possible directions to further validate and
improve our proposed approach. First, by tracking and analyzing the metamodel
edit operations, we aim at generating skeleton transformations for the needed
coevolution rules similar to the migration framework supported by Ruby on Rails5.
In this respect, we plan to consider move and rename operations in our
metamodel merge for automatically generating co-evolution rules. For this we plan to
employ dedicated model comparison approaches such as [