=Paper= {{Paper |id=None |storemode=property |title=On using inplace transformations for model co-evolution |pdfUrl=https://ceur-ws.org/Vol-711/paper8.pdf |volume=Vol-711 }} ==On using inplace transformations for model co-evolution== https://ceur-ws.org/Vol-711/paper8.pdf

On using Inplace Transformations for
Model Co-evolution∗

M. Wimmer1 , A. Kusel2 , J. Schoenboeck1 ,
W. Retschitzegger2 , W. Schwinger2 , and G. Kappel1
1
Vienna University of Technology, Austria
{lastname}@big.tuwien.ac.at
2
Johannes Kepler University Linz, Austria
{firstname.lastname}@jku.at

Abstract. 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 co-
evolution 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 lan-
guages has been proposed demanding for the specification of rules for
copying unchanged elements.
In this paper, we propose to tackle the co-evolution problem from a
different 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 com-
puted by merging the initial and the revised metamodel. This ensures
that the initial as well as the revised model conform to the merged meta-
model, enabling the employment of inplace transformations for initializ-
ing new metamodel elements. Finally, a check-out transformation is used
for eliminating model elements which are no longer covered by the re-
vised metamodel. We demonstrate this idea by using ATL for merging the
metamodels and realizing the check-out transformation. Furthermore, we
discuss the ATL refinement mode for co-evolving the models.

Key words: Model Co-evolution, Metamodel Merging, Inplace Trans-
formations

1 Introduction
Metamodel evolution and model co-evolution are considered to be essential in-
gredients for the successful adoption of Model-Driven Engineering in practice.
Especially, when domain-specific modeling languages are employed, the neces-
sity of language adaptations arise to reflect changes in the modeling domain
∗
This work has been funded by the Austrian Science Fund (FWF) under grant
P21374-N13.

65
as well as in technologies without losing existing models. Thus, (i) dedicated
co-evolution languages (e.g., COPE [10]) and (ii) the usage of model-to-model
(M2M) transformation languages (cf. [6] for an overview) have been proposed to
migrate models conforming to an initial metamodel M M to models conforming
to a revised metamodel M M 0 . However, this requires to learn a new language
in the first case and to copy the entire model—also the elements which are not
affected by metamodel changes—in the second case.
In this paper, we tackle the co-evolution problem from a different 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 transforma-
tion rules which add or update elements according to the revised metamodel,
the co-evolution process is completed by a fully automated check-out transfor-
mation 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
refinement mode for co-evolving the models. Please note that the focus of this
paper is how to support breaking and (non-)resolvable metamodel changes [9]
by inplace transformations for reflecting these changes on existing models and
not on discussing the possible impacts of 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 pa-
per. 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 finally, the paper is concluded with an outlook
on future work in Section 5.

2 Motivating Example

To elaborate on our co-evolution approach, we introduce in this section an evolu-
tion scenario, namely the evolution of a small domain specific modeling language
which is inspired by the UML class diagram language. Fig. 1 illustrates the sce-
nario 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 meta-
model 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 ab-
stract (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).

66
NamedElement
name : String
opposite
1..1
0..* 0..*
Reference Class attributes Attribute
references
upperMult: Int isAbstract: Boolean type : String
lowerMult: Int
1..1 0..1
type extends ID_Attribute Desc_Attribute
MM
MM
MM‘ NamedElement
name : String

0..*
Reference Class attributes Attribute
type isAbstract: Boolean
upperMult: Int type : String
lowerMult: Int 1..1 id: Boolean
refEnds 2..3 0..1
Association superClass

Fig. 1. Running Example - Class Diagram: Initial Metamodel (M M ) and Revised
Metamodel (M M 0 ).
Change Request 1: Modeling of ternary Associations
Change Request 2: Change Attribute Type dynamically
Changethat
Imagine Request
after3:using
Inheritance Feature for
the language should be named
several superClass
projects, to be more
the modelers re-
platform independent
quested several changes of the language due to their experiences and needs:

– Change Request 1: Modeling of ternary associations. The modelers
request that they need, in addition to bi-directional associations, the possi-
bility to describe ternary associations.
– Change Request 2: Change attribute kind dynamically. The mod-
elers 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-specific. Some
modelers complaint that the inheritance feature of the modeling language
should be named superClass instead of extend to be more platform inde-
pendent.

The lower part of Fig. 1 illustrates the revised metamodel M M 0 incorporating
the requested changes. For reflecting 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 reflected 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

67
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 difference 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 exist-
ing extends reference in MM.

3 Co-evolution as Inplace Transformation Problem
In this section, we elaborate on how to apply inplace transformations for co-
evolution 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 different metamodels3 , inplace transformations are currently not used for
this task. This is quite different 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 unification of
both metamodel versions (cf. Step 1 in Fig. 2). The unification is done in a way
that the existing models M, which conform to the initial metamodel MM, also
conform to the unified 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 unified 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 differences between the metamodels are minimal in most cases,
technically we are concerned with two metamodels.

68
1
MM merge MM‘

MM  MM‘

M initialize M  M‘ reject M‘
2 3

Conceputal Architecture
Fig. 2. Conceptual Architecture of the Co-evolution Approach

the inplace transformation
MM MM‘ is the initial
MM model
MM‘which is extended
MM with
MM‘ instances of
the new metamodel elements created by the rules of the inplace transformation.
initialize reject
The rejection of old elements (cf. Step 3 in Fig. 2), i.e., elements which are
only covered by MM,M is done by a M2M M  transformation
M‘ which
M‘is automatically
computed by matching the unified metamodel with the revised metamodel and
by generating a transformation rule for each match.
In the following weCo‐evoluation
describe thetreated Set‐theoretically
approach in more detail. First, we elabo-
rate 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 meta-
model 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.

3.1 Prerequisite: Metamodel Merging

The prerequisite for employing inplace transformations is that we have a unified
metamodel which is capable of representing the commonalities of both meta-
model versions as well as their differences. In Fig. 3, the co-evolution of models
is illustrated by using set theory. We start with a model which consists of ele-
ments 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 transforma-
tion which produces a model which only consists of elements covered by MM’.
In order to support this process, the unified 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 at-
tributes have the same name and the same type, but a different 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 different cardinalities. Therefore, they
have to be both incorporated in the unified metamodel by independent elements.

69
MM  MM‘

M initialize M  M‘ reject M‘
2 3

Conceputal Architecture

MM MM‘ MM MM‘ MM MM‘

initialize reject

M M  M‘ M‘

Fig. 3. Model Co-evolution from a set-theoretic point of view.
Co‐evoluation treated Set‐theoretically

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 defined 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 offer, e.g., a different 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 shows the unified metamodel for our running example. Please note that
due to readability, elements which are only contained by the initial metamodel
are shown in red (for indicating a deletion), elements which are only contained
by the revised metamodel are shown in green (for indicating an addition), and
elements which are contained by both metamodels are shown in black.

MM U MM‘ NamedElement
name : String
1..1
opposite

0..* 0..*
Reference references Class attributes
Attribute
upperMulti: Int type isAbstract: Boolean type : String
lowerMulti: Int 1..1 id: Boolean
refEnds 2..3 0..1 0..1
Association extends superClass
ID_Attribute Desc_Attribute

Fig. 4. Merged metamodel for the metamodels of Fig. 1
Adaptation Rules:

(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
// l for
f Desc_Attribute
D ib
(4) foreach c Class {
c.superClass = c.extends
}
70
Input: initialMM, revisedMM
Output: mergedMM
// create empty mergedMM
1 mergedMM = new MM()
// Add classes to mergedMM
2 for originalClass ∈ Class.allInstancesFrom ( initialMM) do
3 Class revisedClass = findEquivalentClass (revisedMM, originalClass)
4 if revisedClass <> OclUndefined 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)
10 mergedMM.add(modif iedClass.Annotate (’both’))
11 end
12 else
13 mergedMM.add(originalClass.Annotate (’old’))
14 end
15 end
16 for revisedClass ∈ Class.allInstancesFrom ( revisedMM) do
17 Class originalClass = findEquivalentClass (initialMM, revisedClass)
18 if originalClass = OclUndefined then
19 mergedMM.add(revisedClass.Annotate (’new’))
20 end
21 end

// Add features to mergedMM
22 for originalF eature ∈ Feature.allInstancesFrom ( initialMM) do
23 Feature revisedF eature = findEquivalentFeature (revisedMM,
originalF eature)
24 if revisedF eature <> OclUndefined then
25 getContainer (originalF eature).add(originalF eature.Annotate
(’both’))
26 end
27 else
28 getContainer (originalF eature).add(originalF eature.Annotate
(’old’))
29 end
30 end
31 for revisedF eature ∈ Feature.allInstancesFrom ( revisedMM) do
32 Feature originalF eature = findEquivalentFeature (initialMM,
revisedF eature)
33 if originalF eature = OclUndefined then
34 getContainer (revisedF eature).add(revisedF eature.Annotate (’new’))
35 end
36 end
Algorithm 1: Merge Algorithm

71
We have implemented the merge algorithm as an ATL model-to-model trans-
formation 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 unified 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 meta-
model 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 meta-
model constraints. However, these violations are only requiring additional ele-
ments 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 unified 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 transfor-
mation syntax [15]. Please note that Rule 3 is not shown, because it is analogous
to Rule 2. As can be seen in this figure, the inplace transformation rules are very
concise and naturally to develop with existing inplace transformation language
constructs. In the following we shortly discuss the functionality of each rule.
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 defining 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 Refinement Mode. We have implemented the rules
shown in Fig. 5 in ATL using the refinement mode. The resulting transforma-
tion definition 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

72
NAC LHS RHS
assoc2
2 : Association
A i ti 3 : refEnds
ref1 : Reference ref1 : Reference

Rule 1
name = x
6 : refEnds 5 : refEnds assoc1: Association
2 : opposite 1 : opposite 2 : opposite 1 : opposite
name = x + “2“ + y
ref2: Reference
ref2 : Reference ref2 : Reference
ref1 : Reference name = y
4 : refEnds

LHS RHS LHS RHS
cl1 : Class cl1 : Class
s
superCl : Class superCl : Class
Rule 2

Rule 4
1 : attributes 2 : attributes 2 : superClass
1 : extends 1 : extends
att1: ID_Attribute
att tt bute att2 : Attribute
subCl: Class subCl: Class
name = x name = x
type = t type = t
id = true

Fig. 5. Co-evolution rules expressed as graph transformation

semantics of the ATL refinement 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 modified the to block for dealing with the existing
id attributes by the first 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 refining mode.

3.3 Getting rid of out-dated model elements
After initializing the newly introduced metamodel elements of the revised meta-
model, it is now time to modify the extended model in order to conform solely

73
to the revised metamodel (cf. reject arrow in Fig. 2 and 3). This step is automat-
ically achieved in our approach by comparing the unified metamodel with the
revised metamodel by using a matching transformation inspired by [7]. Because
the merge described in Subsection 3.1 is based on one-to-one correspondences,
it is now again possible to use exact one-to-one correspondences as matches be-
tween the unified and the revised metamodel. Thus, we only have to compare
both metamodels with a state-based comparison and generate for each class
match (defined by equal class names) a declarative ATL rule and for each fea-
ture match (defined by equal qualified feature names) an assignment statement.
The resulting M2M transformation is so to say a projection transformation, i.e.,
only a subset of the extended model is transformed to the new model. The
matching transformation can be found again on our project web site.

Listing 1.1. Co-evolution rules expressed in ATL
1 module C o E v o l u t i o n ;
2 create OUT : MM r e f i n i n g IN : MM;
3
4 −−Rule 1
5 rule G e n e r a t e A s s o c i a t i o n s {
6
7 from r e f 1 : MM! R e f e r e n c e ,
8 r e f 2 : MM! R e f e r e n c e ( r e f 1 . o p p o s i t e = r e f 2 ) −− m i s s i n g NAC
9
10 to dummy : MM! R e f e r e n c e ,
11 a s s o c : MM! A s s o c i a t i o n ( r e f E n d s <− S e t { r e f 1 , r e f 2 } )
12 }
13
14 −−Rule 2
15 r u l e G e n e r a t e A t t r i b u t e s {
16
17 from i d a t t : MM! I D A t t r i b u t e
18
19 to dummy : MM! I D A t t r i b u t e ,
20 a t t : MM! A t t r i b u t e (
21 name <− i d a t t . name ,
22 t y p e <− i d a t t . type ,
23 i d <− t r u e ,
24 c l a s s <− i d a t t . c l a s s
25 )
26 }
27
28 −−Rule 3 i s a n a l o g o u s t o Rule 2
29
30 −−Rule 4
31 rule s e t S u p e r C l a s s R e f s {
32
33 from c1 : MM! C l a s s
34
35 to c2 : MM! C l a s s (
36 s u p e r C l a s s <− c1 . extends
37 )
38 }

4 Related Work

Co-evolution has been subject for research since the introduction of the first
object-oriented database systems [2], consequently a huge amount of approaches

74
for dealing with this issue have been proposed (cf. [14] for a survey). In this sec-
tion we therefore focus on most closely related approaches, only, i.e., approaches
dedicated to reflecting changes of metamodels on the model layer in the field of
model-driven engineering.
Garces et al. [8] propose a set of heuristics to automatically compute equiv-
alences and differences between two metamodel versions in order to adopt mod-
els to their evolving metamodels and thus follow a matching approach to co-
evolution. The computed equivalences and differences are stored in a so-called
matching model, acting as input for a higher-order transformation [16], produc-
ing an executable adaptation transformation.
Cicchetti et al. [5] present a similar approach to Garces et al., i.e., the ap-
proach is again based on a metamodel difference representation, which acts as
input for a higher-order transformation. Moreover, the computed differences are
classified into (i) non-breaking changes, (ii) breaking and resolvable changes,
and (iii) breaking and unresolvable changes, further structuring the higher-order
transformation.
Wachsmuth [17] proposes to combine ideas from object-oriented refactoring
and grammar adaptation to provide the basis for automatic metamodel evolu-
tion. In this respect, metamodel relations are defined, building the basis for the
definition of semantics preservation and instance preservation. Moreover, a set
of transformations based on QVT Relations [12] are proposed, which are accord-
ingly classified into refactoring, construction, and destruction transformations.
In [1, 11] a co-evolution approach for models using the Model Change Lan-
guage (MCL) is presented. MCL is declarative and graphical language supporting
a set of co-evolution idioms. The evolver defines relationships between elements
of the metamodel versions. There are different kind of relationships starting from
simple one-to-one mappings between classes to more complex mappings for typ-
ing objects to new subclasses or for changing the containment hierarchy. More
complex co-evolution rules have to be defined in the context of the defined map-
pings as constraints and actions in terms of C++ code. For unchanged parts of
the metamodel no mappings have to be defined due to the usage of name equiv-
alences. It has to be mentioned that the provided idioms only cover syntactical
co-evolution concerns but not semantical concerns and that the co-evolution is
achieved again by a model-to-model transformation.
Herrmannsdoerfer et al. propose in [10] COPE, an integrated approach to
specify the coupled evolution of metamodels and models in order to reduce the
migration effort. In this respect, the co-evolution of metamodels and correspond-
ing models is realized by a set of so-called coupled transactions, composing a
whole co-evolution problem of modular transformations. The coupled transac-
tions are further divided into custom coupled transactions and reusable coupled
transactions, whereby as the name reveals reusable coupled transactions are pre-
defined and have not to be specified by the user, thereby reducing the migration
effort. Moreover, the authors argue to provide the needed expressivity by custom
coupled transactions expressed by primitives embedded into the Turing-complete
language Groovy.

75
Summarizing, our approach is different to the mentioned approaches, because
we tackle co-evolution of models with existing inplace transformation languages
instead of using domain-specific 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 el-
ements which are no longer covered by the revised metamodel, which in contrast
has to be manually developed with COPE. The first 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 defined 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 defining the co-evolution rules by using our unified metamodel in
combination with inplace transformations. For computing the check-out trans-
formation for generating the finally co-evolved models, we are using a similar
approach as Graces et al. [8] for producing the adaptation transformation, but
with the difference that we do not have to rely on heuristics. This is due to
the fact that we only have one-to-one correspondences which are unambiguously
derivable. Finally, currently we do not support the automatic generation of co-
evolution rules for breaking and resolvable changes as is supported by the first
two mentioned approaches. We see this support as an orthogonal concern and
as subject to future work.

5 Conclusion and Future Work

In this paper we have reported on our first experiments using inplace transfor-
mations for model co-evolution. Our experiences indicates that co-evolution of
models may be easily described with current inplace transformation languages.
However, the ATL refinement mode currently has some limitations compared to
the M2M mode which complicate the definition of co-evolution rules. An im-
provement for defining co-evolution rules would be to allow for imperative parts
in the ATL refinement 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 unified 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 ab-

76
stract classes should no longer be supported, meaning that only concrete classes
are migrated. This kind of elimination is a selection and not a projection auto-
matically achieved by the check-out transformation. Thus, selections have to be
defined 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 im-
prove our proposed approach. First, by tracking and analyzing the metamodel
edit operations, we aim at generating skeleton transformations for the needed co-
evolution rules similar to the migration framework supported by Ruby on Rails5 .
In this respect, we plan to consider move and rename operations in our meta-
model merge for automatically generating co-evolution rules. For this we plan to
employ dedicated model comparison approaches such as [3, 13]. Furthermore, we
have to apply our approach to more complex metamodel evolution scenarios to
validate if we are able to support all possible metamodel changes [4]. Finally, we
plan some student user studies, because in our model engineering course students
always struggle with metamodeling examples due to unloadable example mod-
els which are important to verify the developed metamodels. However, to allow
for a prototypical, incremental, and iterative metamodel development process,
co-evolution of models must be easily accomplished.

References
1. D. Balasubramanian, C. vanBuskirk, G. Karsai, A. Narayanan, S. Neema, B. Ness,
and F. Shi. Evolving paradigms and models in multi-paradigm modeling. Technical
Report ISIS-08-91, Institute for Software Integrated Systems, Nashville, 11/2008
2008.
2. J. Banerjee, W. Kim, H.-J. Kim, and H. F. Korth. Semantics and implementation
of schema evolution in object-oriented databases. SIGMOD Record, 16(3):311–322,
1987.
3. C. Brun and A. Pierantonio. Model Differences in the Eclipse Modeling Framework.
UPGRADE, The European Journal for the Informatics Professional, 2008.
4. E. Burger and B. Gruschko. A Change Metamodel for the Evolution of MOF-Based
Metamodels. In Proceedings of Modellierung 2010, volume 161 of LNI, pages 285–
300. GI, 2010.
5. A. Cicchetti, D. D. Ruscio, R. Eramo, and A. Pierantonio. Automating Co-
evolution in Model-Driven Engineering. In Proceedings of the 12th International
IEEE Enterprise Distributed Object Computing Conference (EDOC’08), pages
222–231. IEEE Computer Society, 2008.
6. K. Czarnecki and S. Helsen. Feature-based Survey of Model Transformation Ap-
proaches. IBM Systems Journal, 45(3):621–645, 2006.
7. M. D. D. Fabro and P. Valduriez. Towards the efficient development of model
transformations using model weaving and matching transformations. Software and
System Modeling, 8(3):305–324, 2009.
8. K. Garcés, F. Jouault, P. Cointe, and J. Bézivin. Managing Model Adaptation
by Precise Detection of Metamodel Changes. In Proceedings of the 5th Euro-
pean Conference on Model Driven Architecture - Foundations and Applications
(ECMDA-FA’09), pages 34–49. Springer-Verlag, 2009.
5
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

77
9. B. Gruschko, D. Kolovos, and R. Paige. Towards synchronizing models with evolv-
ing metamodels. In Proceedings of the International Workshop on Model-Driven
Software Evolution @ ECSMR, 2007.
10. M. Herrmannsdoerfer, S. Benz, and E. Juergens. COPE - Automating Coupled
Evolution of Metamodels and Models. In Proceedings of the 23rd European Confer-
ence on Object-Oriented Programming (ECOOP’09), pages 52–76. Springer-Verlag,
2009.
11. A. Narayanan, T. Levendovszky, D. Balasubramanian, and G. Karsai. Automatic
domain model migration to manage metamodel evolution. In Proceedings of the
12th International Conference on Model Driven Engineering Languages and Sys-
tems (MoDELS’09), volume 5795 of LNCS, pages 706–711. Springer, 2009.
12. Object Management Group. Meta Object Facility (MOF) 2.0 Query/View/-
Transformation Specification. www.omg.org/docs/ptc/07-07-07.pdf, 2007.
13. D. Ohst, M. Welle, and U. Kelter. Differences between versions of UML diagrams.
SIGSOFT Softw. Eng. Notes, 28(5):227–236, 2003.
14. J. F. Roddick. Schema evolution in database systems - an annotated bibliography.
SIGMOD Record, 21(4):35–40, 1992.
15. G. Taentzer. AGG: A Graph Transformation Environment for Modeling and Vali-
dation of Software. In Proceedings of the 2nd International Workshop on Applica-
tions of Graph Transformations with Industrial Relevance (AGTIVE’03), volume
3062 of LNCS, pages 446–453. Springer, 2003.
16. M. Tisi, F. Jouault, P. Fraternali, S. Ceri, and J. Bézivin. On the Use of Higher-
Order Model Transformations. In Proceedings of 5th European Conference on
Model Driven Architecture - Foundations and Applications (ECMDA-FA’09), pages
18–33. Springer-Verlag, 2009.
17. G. Wachsmuth. Metamodel adaptation and model co-adaptation. In Proceedings
of the 21rd European Conference on Object-Oriented Programming (ECOOP’07),
pages 600–624. Springer-Verlag, 2007.