Specification of Adaptable Model Migrations
Paola Vallejo, Micka
¨
el Kerboeuf and Jean-Philippe Babau
University of Brest/Lab-STICC - MOCS Team, Brest, France
Keywords:
Metamodel and Model co-evolution, Migration Specification.
Abstract:
This paper puts the focus on adaptable model migrations. A dedicated formalism is introduced to combine
automatically-generated migrations with custom-made migrations. To illustrate this issue and the approach
we suggest to address it, a prototype engine is presented. Then, the prototype is applied on a case study. The
prototype processes the migration specifications that have been automatically generated and then customized.
The case study consists of the reuse of a mapping tool, in order to change highlighted places. During the reuse
process the migration specification is customized in order to produce different migrated models.
1 INTRODUCTION
Reusing legacy tools allows to reduce the cost of pro-
ducing the tooling for a Domain Specific Modeling
Language. A legacy tool is defined by its specific
metamodel (the tool metamodel): the tool metamodel
contains only the elements needed by the tool to exe-
cute its functionalities. A common issue when trying
to reuse a legacy tool is that the context in which the
tool should be used (the domain metamodel) is differ-
ent to the tool metamodel.
Even if these metamodels are different, we can
suppose that they share a common subset of close
concepts. Thus, the tool metamodel can be consid-
ered as an evolution of the domain metamodel. From
this point of view, the reuse of a legacy tool implies to
put existing models under the scope of the legacy tool
by means of migration techniques.
A well known and rather obvious way to achieve
this purpose relies on the principle of metamodel and
model co-evolution. It basically allows the meta-
model transformations to be automatically reflected
at the model level. Thus, model-level specifics
cannot be automatically taken into account by co-
evolution. In order to overcome this lack of model-
level customization, we present an approach to com-
bine both automatically-generated model migrations
with custom-made model migrations.
This paper is structured as follows. Section 2 in-
troduces a motivating example. Section 3 presents the
principles of the migration specification which under-
lies our approach. A case study is presented in sec-
tion 4 to show the relevance of this approach. Related
works are discussed in section 5. The paper is con-
cluded with an outlook on future work in Section 6.
2 MOTIVATION
This section introduces a case used as a running ex-
ample throughout the rest of the paper. MapView is
a legacy tool we aim at reusing. It displays a map
in which the location of specific buildings is marked.
The color and the label of the marker depend on the
place’s type. The tool has been implemented by us-
ing the Google Maps API
1
. An excerpt of the Ecore
metamodel of the input data that can be processed by
this tool is shown in figure 1. This metamodel intro-
duces the concepts of City, Neighborhood, Place and
Address. There are different types of places (e.g. Uni-
versity, Dormitory, HealthCareCenter). Each place is
located at a specific Address.
Figure 2 shows a variant of the metamodel on
which MapView has been designed. This metamodel
corresponds to an excerpt of a City Information Sys-
tem (CIS) which represents the population of a city.
It contains information about the citizens, their job,
theirs studies, their accommodation and theirs places
in the city. These data are typically expected to be
collected during a census.
This metamodel can be seen as a variant of the
MapView metamodel with additional elements (i.e.
Citizen class and all its features, citizens reference,
zipCode attribute and country attribute of the City
1
https://developers.google.com/maps/
32
Vallejo P., Kerboeuf M. and Babau J..
Specification of Adaptable Model Migrations.
DOI: 10.5220/0005231200320039
In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 32-39
ISBN: 978-989-758-083-3
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
Figure 1: Excerpt of MapView’s metamodel.
Figure 2: Excerpt of CIS metamodel.
class). The reuse of MapView in this context requires
the deletion of these extra-elements.
Figure 3: Simple CIS model.
Figure 3 presents a model conforming to the CIS
metamodel. To put it under the scope of MapView, we
apply typical co-evolution operators like Remove and
Rename (Herrmannsdoerfer et al., 2010) .
The modified metamodel fully matches with the
metamodel of MapView. Then, MapView can be ap-
Figure 4: Migrated model.
plied on the migrated model. The migrated model is
illustrated by figure 4, citizens Anne and Robert have
been removed. The outcome of the tool is depicted by
figure 5. The map marks one university (blue marker
labeled with U), one health care center (red marker
labeled with H) and three dormitories (brown marker
labeled with D).
Figure 5: MapView outcome.
In the context of reuse, the same tool can be used
according to different and specific needs. For in-
stance, MapView will be reused to provide a view of
specific places:
1. Only dormitories
2. The university and the dormitories near to it
3. The health care center and the closest dormitory
In case 1, model migration involves deletion of all
instances of university and health care center. In cases
2 and 3, some instances of dormitory have to be kept
and some others have to be removed. The way to se-
lect the dormitories to be kept depends on the notion
of nearness.
A way to remove the unnecessary instances is by
using co-evolution operators. In co-evolution of meta-
model and models, if a class is removed at the meta-
model level, all its instances are removed at the model
SpecificationofAdaptableModelMigrations
33
level. If a class is kept, thus all its instances are kept
too.
There are tools as Edapt
2
that allows to manually
specifying model migrations when they are so specific
to the model context. Edapt generates migration code
for instances affected by metamodel transformations.
As in cases 1, 2 and 3 there are not metamodel trans-
formations, migration code is not generated, so it is
not possible to specify specific model migrations.
In all cases, classes HealthCareCenter, University
and Dormitory have to persist at the metamodel level
for structural needs (modified metamodel must fully
matches with tool metamodel). Co-evolution opera-
tors are not useful in these cases because it is not pos-
sible to define a model migration for instances whose
corresponding class is not transformed.
Another way to handle cases 1, 2 and 3 is by using
classical transformation languages, for example ATL
3
. ATL allows to define specific model migrations.
The next code is an excerpt of the ATL code that
keep only dormitories.
-- @path City=/.../metamodel/cityis.ecore
-- @path Mapview=/.../metamodel/mapviewer.ecore
module city2mapview;
create OUT : Mapview from IN : City;
rule Dormitory2Dormitory {
from
c : City!Dormitory
to
m : Mapview!Dormitory (
name <- m.name
...)
}
rule deleteUniversity {
from
c : City!University
to
drop
}
The next code is an excerpt of the ATL code that
keep only dormitories located near to the university.
-- @path City=/.../metamodel/cityis.ecore
-- @path Mapview=/.../metamodel/mapviewer.ecore
module city2mapview;
create OUT : Mapview from IN : City;
rule Dormitory2Dormitory {
from
c : City!Dormitory(
c.address.reference.name = ’Lanredec’
2
http://www.eclipse.org/edapt/
3
http://www.eclipse.org/atl/
|| c.address.refrence.name = ’Archives’)
to
m : Mapview!Dormitory (
name <- m.name
...)
}
The next code is an excerpt of the ATL code that
keep the dormitory close to the health care center.
-- @path City=/.../metamodel/cityis.ecore
-- @path Mapview=/.../metamodel/mapviewer.ecore
module city2mapview;
create OUT : Mapview from IN : City;
rule Dormitory2Dormitory {
from
c : City!Dormitory(
c.address.reference.name = ’Lanredec’ )
to
m : Mapview!Dormitory (
name <- m.name
... )
}
The difference between the three pieces of code
is the constraint c.address.reference.name = . In the
first case, there is not constraint because all instances
of dormitory are kept. It is mandatory to specify the
migration code for each case, which makes this so-
lution model dependent, programming language ori-
ented and not generic.
More generally, three cases can be encountered:
1) A class and all its instances have to be removed.
For example, Citizen class. 2) A class is kept but some
of its instances have to be removed. For example, Dor-
mitory in cases 2 and 3. 3) A class is kept but all its
instances have to be removed. For example, Univer-
sity in case 1.
In those cases, there are two concerns, the first
one, related to the classes; the second one, related to
model instances and specific contexts. There is a lack
of a mechanism to ensure the separation those of con-
cerns.
Then, we propose to address the proposed cases
by an approach able to generate model migrations and
allowing customization of migrations without making
modifications directly in the migration’s code.
It consists in promoting the adaptation of auto-
matically generated model migration thanks to a for-
mal and generic migration specification. For a given
metamodel MM transformed into a new metamodel
MM’, and for a given model m conforming to MM: in-
stead of directly reflecting the metamodel evolution
at the model level by means of a generated migration
mig such that mig(m) provides a migrated model con-
forming to MM’, we suggest to generate a migration
specification
−→
m such that provided to a dedicated and
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
34
generic engine M, it produces the expected migration
mig (i.e. M(
−→
m ) = mig). As a consequence, the mi-
gration specification
−→
m is editable and processable.
Even if it is automatically generated, it can be modi-
fied before being processed by the generic engine M.
Then we can obtain an adapted migration mig.
The next section states the formal basis of this
approach. The following section illustrates this ap-
proach with the reuse of MapView.
3 FORMAL FRAMEWORK FOR
ADAPTABLE MODEL
MIGRATIONS
A migration specification relies on formal model de-
notations, which are oriented and labeled graphs.
These notions are detailed in the first part of this sec-
tion. They underlie the prototype presented in the sec-
ond part.
3.1 Migration Specification
Foundations
Model Graph. A model graph is a graph-based de-
notation of a model, i.e. a labeled graph composed
of vertices denoting instances and scalar values, and
edges denoting references and attributes. The names-
paces corresponding to instances, scalar values, at-
tributes and references are defined by the following
alphabets, (i.e. non-empty finite set of symbols):
I : instances, S : scalar values, A : attributes, R :
references.
We call model and note m a triplet composed of
a set of instances corresponding to vertices noted V ,
and two sets of edges noted E
a
and E
r
. The first set of
edges denotes attributes. It relates instances to scalar
values through attribute names. The second one de-
notes references. It relates instances to each other
through reference names:
m ,
V , E
a
, E
r
with
V ⊆ I
E
a
⊆ V × A × S
E
r
⊆ V × R ×V
We note m.V , m.E
a
and m.E
r
the V , E
a
and E
r
components of a given model m.
As an illustration, figure 6 depicts an excerpt of
the CIS model with this graph representation.
Migration Specification. For a given model m, we
call migration specification and note
−→
m a quadruplet
composed of m and of three sets noted D
i
, D
a
and
:Citizen
firstName = Anne
citizens
neighborhoods
:City
name = Brest
:Neighborhood
name = Bellevue
:University
name = UBO
studiesAt
birthday = 01011990
places
:Address
number = 20
address
:Avenue
reference
zipCode = 29200
country = France
UUID = Brest
UUID = Bellevue
lastName = MARTIN
maritalStatus = Single
job = Engineer
phoneNumber = 02980000
UUID = Anne
UUID = UBO
UUID = 20
name = Le Gorgeu
UUID = Le Gorgeu
Brest
Brest
29200
France
cy
Bellevue
Bellevue
n
Le Gorgeu
av
Le Gorgeu
a
20
20
UBO
u
UBO
places
name
name
UUID
UUID
number
UUID
address
name
UUID
reference
country
name zipCode
UUID
Anne
Martin
01011990
Single
Engineer
02980000
Anne
c
firstName
birthday
lastName
maritalStatus
job
phoneNumber
UUID
citizens
neighborhoods
studiesAt
Figure 6: Abstract syntax and semantics.
D
r
. These sets specify the instances, attributes and
references of m that are intended to be removed:
−→
m ,
m, D
i
, D
a
, D
r
where
D
i
⊆ m.V
D
a
⊆ m.V × A
D
r
⊆ m.V × R
We note
−→
m .D
i
,
−→
m .D
a
and
−→
m .D
r
the D
i
, D
a
and
D
r
components of a given migration specification
−→
m .
The migration specification is intended to be used to-
gether with the model to produce a migrated model.
This migration specification is computed from co-
evolution (i.e. Modif specification (Babau and Ker-
boeuf, 2011)). A specification makes it possible to
state the deletion of a class, an attribute or a reference
(corresponding to D
i
, D
a
and D
r
at the model level).
Migration Engine. We call migrator and note
M the tool aiming at producing a migrated model
from a migration specification. According to
the following algorithm, it commits the deletion
of instances and of features (attributes and refer-
ences) on the source model to produce a target model:
m
0
= M(
−→
m )
m
0
.V = m.V \
−→
m .D
i
m
0
.E
a
= m.E
a
\ {(i, a, s) ∈ I × A × S | i ∈
−→
m .D
i
∨ (i, a) ∈
−→
m .D
a
}
m
0
.E
r
= m.E
r
\ {(i, r, i
0
) ∈ I × R × I | i ∈
−→
m .D
i
∨ i
0
∈
−→
m .D
i
∨ (i, r) ∈
−→
m .D
r
}
As an illustration, we note m the model of figure
6 and
−→
m its migration specification aiming at produc-
ing a model conforming to the a metamodel of figure
1, i.e. a model in which all instances of Citizen have
SpecificationofAdaptableModelMigrations
35
been removed. This specification is formally and ex-
plicitly defined by its components:
−→
m .D
i
= {c}
−→
m .D
a
= {zipCode, country}
−→
m .D
r
= {studiesAt, citizens}
Once the migrator has been applied to
−→
m , we ob-
tain the migrated model m
m
illustrated by figure 7.
neighborhoods
:City
name = Brest
:Neighborhood
name = Bellevue
:University
name = UBO
places
:Address
number = 20
address
:Avenue
reference
UUID = Brest
UUID = Bellevue
UUID = UBO
UUID = 20
name = Le Gorgeu
UUID = Le Gorgeu
Brest
Brest
cy
Bellevue
Bellevue
n
Le Gorgeu
av
Le Gorgeu
a
20
20
UBO
u
UBO
places
name
name
UUID
UUID
number
UUID
address
name
UUID
reference
name
UUID
neighborhoods
Figure 7: Abstract syntax and semantics of a migrated
model without Citizen.
The migration is performed at the model level. It
does not require any metadata.
3.2 Migration Specification
Implementation
A migrator prototype based on Ecore and Modif
(Babau and Kerboeuf, 2011) has been developed ac-
cording to the formal principles of migration specifi-
cation. The refactoring, the migrator and the tool to
be reused form a toolchain depicted by figure 8 and
detailed as follows.
M
Re
MM
d
.ecore
MM
t
.ecore
m.mmd
m
m
.mmt
MMd2MMt.modif
mmd2mmt.migration
T
m
t
.mmt
Figure 8: Typical toolchain including the migrator.
Refactoring (Re). The first step is the application
of co-evolution operators at the metamodel level.
Consider a domain metamodel MMd.ecore in figure
8. On it, co-evolution operators are applied to ob-
tain an evolved metamodel that matches with the tool
metamodel (MMt.ecore). The prototype uses a Modif
Specification to indicate the operators to be applied,
but some other metamodel transformation tool or lan-
guage can be used as well (e.g. COPE, ATL, QVT).
Migration Specification Generation. The second
step is the automatic generation of a by default mi-
gration specification conforming to the metamodel of
figure 9. The by default migration specification is de-
rived from the co-evolution operators applied at the
Refactoring step. It contains URIs of source and tar-
get models and metamodels. The instances that must
be updated by the migration are identified by a unique
identifier (UUID). When a class is removed at the
metamodel level, deleteInstance is set to true for each
Instance of the removed class. Otherwise, it is set to
false and then, the modification is related to features.
Figure 9: Graphical view of Migration metamodel.
The migration specification is typically generated
from Modif, but it can be defined from other sources,
including a model editor generated from the meta-
model of figure 9.
Specification Edition. The third step is the edition
of the migration specification. In order to take into
account some model specifics in the generated migra-
tion specification. It is therefore possible to produce
migrated models according to specific needs without
having to generalize it at the metamodel level. And
without modifying any source code.
Migration Engine (M). In the fourth step, the Mi-
gration Engine is executed to obtain a migrated model
according to the modifications indicated in the mi-
gration specification. It takes an MMd input model
(m.mmd) and produces a migrated MMt output model
(mm.mmt). The Migration Engine is independent of
the input model. It means it can be reused for dif-
ferent input models. And it is not overloaded with
unnecessary metadata.
Use of a Legacy Tool (T). Before reusing the
legacy tool, the migrated model coming from the mi-
grator is validated. Finally, the legacy tool is applied
on the migrated validated model.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
36
4 EXPERIMENT
We present in this section the results of the application
of the prototype to the MapView case study introduced
in section 2.
An excerpt of the Modif Specification is illus-
trated by the next code:
root cityis to mapview
Prefix cityis to mapview
URI "file:/C:/Modif/cityisK.ecore"
to "file:/C:/Modif/mapview.ecore"
class {
City {
remove ref citizens
remove att zipCode
remove att country
} ;
remove Citizen {
remove att firstName
remove att birthday
remove att lastName
remove ref livesIn
remove att maritalStatus
remove att job
remove ref worksAt
remove ref studiesAt
remove att phoneNumber
remove att UUID
} ;
...
}
The features citizens, zipCode and country of the
class City are removed. The class Citizen and all its
features are removed too.
Figure 10: By default migration specification.
Figure 10 depicts the by default migration speci-
fication generated from the Modif Specification and
the model of figure 3. The left column contains the
instances and the features that have to be removed.
The right column contains the instances that have to
be kept.
Once the by default migration is generated, it can
be edited allowing the specification of customized
model migrations. Just by selecting one instance of
the Keep column and clicking on the To delete button,
it will be placed on the Delete column.
Figure 11: Customized migration specification 1.
Figure 11 presents the migration specification al-
lowing to keep only dormitories (case 1 of section 2).
Figure 12: Customized migration specification 2.
Figure 12 illustrates the migration specification
that allows to to keep only the university and the dor-
mitories near to it (case 2 of section 2).
Figure 13 illustrates the migration specification al-
lowing to to keep the health care center and the closest
dormitory (case 3 of section 2).
SpecificationofAdaptableModelMigrations
37
Figure 13: Customized migration specification 3.
From a model and the by default migration specifi-
cation, some customized migration specifications can
be produced. After customizing the migration speci-
fication, the Migration Engine is executed to produce
a model conforms to the legacy tool metamodel. Fi-
nally, MapView is applied. Figure 14 illustrates the
specific outcome when the migration specification is
that of figure 12.
Figure 14: D near to the U.
Our approach is able to generate model migrations
and allows customization of migrations. Thanks to
the migration editor, a same migration specification
can be used as a common basis to generate quickly
and efficiently various migrated models. Any knowl-
edge about transformation or programming languages
is required to customize model migrations.
5 CURRENT AND RELATED
WORKS
The necessity of providing automatic co-evolution of
metamodels and models was identified as an impor-
tant challenge in software evolution by Mens and al.
(Mens et al., 2005). With the growing importance of
model transformations, much work is intended to im-
prove the definition and the verification of such trans-
formations by providing adapting formalism and tool-
ing.
Wachsmuth (Wachsmuth, 2007) proposes a trans-
formational approach to assist metamodel evolution
by stepwise adaptation. Ciccheti et al. (Cicchetti
et al., 2009) present a classification of metamodel
and model changes. They propose an approach for
performing co-evolution automatically, based on de-
pendencies between different kinds of modifications.
In those works the migration of models is based on
reusable operators, automated and non adaptable. It
allows to reduce the effort associated with building
a model migration. As a complement, we allow to
define customize model migrations by means of a Mi-
gration Specification. It is possible to generate it from
the history of co-evolution operators applied to trans-
form a metamodel.
The authors of (Regg et al., ) and (Agrawal et al.,
2003) evoke the need of methods and tools to au-
tomate and speed up the process of migrating mod-
els. However, some metamodel changes require in-
formation during migration which is not available
in the model, these migration inherently cannot be
fully automated. They enable user interaction dur-
ing migration only when missing information has to
be provided. Epsilon Flock language (Rose et al.,
2010) uses a migration strategy that can be extended
by adding constraints. COPE (Herrmannsdoerfer
and Ratiu, 2009) provides a library of reusable co-
evolution operators which produces model migrations
automatically. Only in case no reusable operators are
available, the user defines custom operators by man-
ually encoding a model migration. When using those
approaches, additional effort is necessary to learn a
new language for model migrations. In general, the
definition of custom migrations is tedious and error-
prone. Unlike those approaches, our approach allows
user interaction even if migration is fully automated.
Definition of new operators is not needed and knowl-
edge about a particular language is not required.
MOLA (Kalnins et al., 2004) is a graphical model
transformation language whose main goal is to de-
scribe model transformations in a natural and easy
readable way. It focuses on easy readability and cus-
tomization of transformations. This approach is not
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
38
related to co-evolution, it means that they not include
the notion of co-evolution operators and it works only
at the model level.
6 CONCLUSION AND FUTURE
WORKS
The paper outlines an approach for supporting the co-
evolution of metamodels and models. The propo-
sition combines the automatic generation nature of
co-evolution approaches with user interactions. In
this way, part of the definition of model migrations
is achieved automatically, but it still possible update
them manually. We experimented the approach by
performing adaptable model migrations combining
automatically-generated migration with custom-made
migrations. Those model migrations allows to reuse
the MapView tool according to specific user needs.
Our perspective is to extend the approach to per-
form adaptable model migrations with others co-
evolution approaches. We are working on the defi-
nition of other co-evolution operators at model level
(change value) and on to define valid model migra-
tions.
REFERENCES
Agrawal, A., Karsai, G., and Shi, F. (2003). Graph transfor-
mations on domain-specific models.
Babau, J.-P. and Kerboeuf, M. (2011). Domain Spe-
cific Language Modeling Facilities. In 5th MoDELS
workshop on Models and Evolution, Wellington, New
Zealand.
Cicchetti, A., Ruscio, D. D., and Pierantonio, A. (2009).
Managing dependent changes in coupled evolution. In
Paige, R. F., editor, ICMT, volume 5563 of Lecture
Notes in Computer Science. Springer.
Herrmannsdoerfer, M. and Ratiu, D. (2009). Limitations
of automating model migration in response to meta-
model adaptation. In MoDELS Workshops.
Herrmannsdoerfer, M., Vermolen, S., and Wachsmuth, G.
(2010). An extensive catalog of operators for the cou-
pled evolution of metamodels and models. In SLE.
Kalnins, A., Barzdins, J., and Celms, E. (2004). Model
transformation language mola. In Proceedings of
MDAFA (Model-Driven Architecture: Foundations
and Applications.
Mens, T., Wermelinger, M., Ducasse, S., Demeyer, S.,
Hirschfeld, R., and Jazayeri, M. (2005). Challenges
in software evolution. In Proc. 8th IWPSE. IEEE.
Regg, U., Motika, C., and von Hanxleden, R. Interactive
transformations for visual models.
Rose, L. M., Kolovos, D. S., Paige, R. F., and Polack, F.
A. C. (2010). Model migration with epsilon flock. In
Tratt, L. and Gogolla, M., editors, ICMT, volume 6142
of Lecture Notes in Computer Science. Springer.
Wachsmuth, G. (2007). Metamodel adaptation and model
co-adaptation. In Proceedings of the 21st Euro-
pean Conference on Object-Oriented Programming
(ECOOP’07), Lecture Notes in Computer Science.
Springer-Verlag.
SpecificationofAdaptableModelMigrations
39
