=Paper=
{{Paper
|id=Vol-1706/paper1
|storemode=property
|title=DSL/Model Co-Evolution in Industrial EMF-Based MDSE Ecosystems
|pdfUrl=https://ceur-ws.org/Vol-1706/paper1.pdf
|volume=Vol-1706
|authors=Josh Mengerink,Ramon R. H. Schiffelers,Alexander Serebrenik,Mark van den Brand
|dblpUrl=https://dblp.org/rec/conf/models/MengerinkSSB16
}}
==DSL/Model Co-Evolution in Industrial EMF-Based MDSE Ecosystems==
https://ceur-ws.org/Vol-1706/paper1.pdf
DSL/Model Co-Evolution in Industrial EMF-Based MDSE
Ecosystems
J.G.M. Mengerink R.R.H. Schiffelers A. Serebrenik
Eindhoven University of ASML & Eindhoven Univerisity Eindhoven University of
Technology of Technology Technology
The Netherlands The Netherlands The Netherlands
j.g.m.mengerink@tue.nl r.r.h.schiffelers@tue.nl a.serebrenik@tue.nl
ramon.schiffelers@asml.com
M.G.J. van den Brand
Eindhoven University of
Technology
The Netherlands
m.g.j.v.d.brand@tue.nl
ABSTRACT Similarly to traditional software systems and languages [11],
Model Driven Engineering and Domain Specific Languages DSLs evolve over time [12, 13]. This leads to challenges
(DSLs) are being used in industry to increase productivity, with respect to backwards compatibility: artifacts (models,
and enable novel techniques like virtual prototyping. Using parsers etc.) from the old version of the DSL may no longer
DSLs, engineers can model a systems in terms of their do- be valid in the new version of the DSL. To this extent, these
main, rather than encoding it in general purpose concepts, artifacts have to co-evolve to reflect the changes in the DSL.
like those o↵ered by UML. However, DSLs evolve over time, This is known as the co-evolution problem.
often in a non-backwards-compatible way with respect to Manual co-evolution of these artifacts is tedious, error-
their models. When this happens, models need to be co- prone, and costly. To mitigate this, we wish to automate the
evolved to remain usable. Because the number of models co-evolution of artifacts in DSL ecosystems to the highest
in an industrial setting grows so large, manual co-evolution extent possible. In the literature, various approaches have
is becoming unfeasible calling for an automated approach. been presented towards automating this co-evolution, each
Many approaches for automated co-evolution of models with with their own strong and weak points [14, 15, 16, 17]. For
respect to their DSLs exist in literature, each operating in a our industrial case we aim at completeness and formality,
highly specialized context. In this paper, we present a high- rather than approximation of the various artifacts.
level architecture that tries to capture the general process In this paper, we present a high-level architecture that
needed for automated co-evolution of models in response to captures the various steps and components required for co-
DSL evolution, and assess which challenges are still open. evolution of models. Subsequently, we examine the state-of-
the-art in co-evolution research to ascertain to what extent
the state-of-the-art is able to e↵ectuate the proposed archi-
Keywords tecture. Lastly, we summarize the open challenges towards
Model driven engineering, evolution, domain specific lan- implementing the architecture, and are thus future work for
guage, model, maintenance, co-evolution automating DSL/model co-evolution.
In the remainder of this paper we discuss DSL ecosys-
tems (Section 2),and present our architecture and its com-
1. INTRODUCTION ponents (Section 3), position existing work with respect to
Model driven (system) engineering MD(S)E is being used the architecture and determine which components are not
both in industry [1, 2], and open source [3] for developing yet supported (Section 4). Next we discuss the theoreti-
software and systems. Systems design using MDE allows for cal limitations of the automation (Section 5) and sketch the
analysis and feedback early in the design process. A main directions for future work (Section 6).
driver for doing so is designing domain specific languages
(DSLs), e.g., using the Eclipse Modeling Framework (EMF)
[4]. In EMF, DSLs consist of meta-models [5] eventually
augmented by OCL constraints [6]. DSLs allow one to model 2. ECOSYSTEMS
systems in terms of their domain, rather then using general In model-driven engineering, the meta-model is the cen-
purpose concepts o↵ered by, e.g., UML or SysML [7]. tral artifact that dictates the concepts and structure of other
We have observed that in an industrial setting, DSLs of- artifacts. Several related DSLs and their corresponding arti-
ten occur in an ecosystem (cf. [8, 9, 10]), i.e., collection facts constitute an MDSE ecosystem. When evolving a DSL
of DSLs with dependencies between them introduced,e.g., in an MDSE ecosystem, artifacts such as models [14, 15,
by language reuse or model-to-model transformations. Ad- 18, 19], model-to-model transformations [20, 21], text and
ditionally, infrastructural artifacts such as parsers, textual graphical editors [22] may have to be co-evolved. Di Ruscio,
editors, and graphical editors also reside in this ecosystem. Iovino and Pierantonio define three categories of co-evolving
2
number of modified models (Logarithmic scale)
256
500
Frequency
400
7
6
#Model elements
32
5
300
4
3
200
2
4 1
100
2000 4000 6000 8000
0
Revision
0 503 1446 2658 3958 5127 7116 9000
Revision
Figure 3: A binplot (aggregating several data-points into
hexagonal bins) of the number of revised PGWB models per
Figure 1: Evolution of the number of meta-model elements
revision. Each hexagon represents a bin of a range of re-
in PGWB. Largest groups represent references (blue), enumer-
visions and a range of “number of models modified”, where
ation literals (indigo), attributes (yellow), classes (green).
the colors represent the number of data points in that bin.
Numerous changes to the meta-model are visible.
transformations. Assume a transformation T transforms a
60
concept A in meta-model X to a concept B in Y . If A is
20 30 40 50
evolved to include additional information, one might have to
#Model elements
co-evolve T to incorporate this new information. Addition-
ally, Y might not be expressive enough to encode the new
information, and B itself has to be co-evolved too.
Lastly, not all relations between artifacts in MDSE ecosys-
10
tems are modeled (or specified) explicitly. There can also be
implicit relations, such as the classic software co-change as
0
0 744 1538 2682 4098 5137 8643
Revision described by Zimmerman et al. [27]. Similar relations exist
for MDSE and similar solutions can be presented [28].
To illustrate the ripple e↵ect issue in CARM consider
Figure 2: Evolution of the number of meta-model ele- DSLs PGWB and Basics. PGWB reuses concepts from Basics.
ments in Basics. Largest groups represent references (blue), Evolution of PGWB and Basics is shown in Figures 1 and
enumeration literals (indigo), attributes (yellow), classes 2, respectively. Around revision 4100 we see an increase in
(green). Numerous changes to the meta-model are visible, the number of classes, enumeration literals and references
in addition to a gradual increase in size. in Basics language. The corresponding change in PGWB is
barely visible. However, Figure 3 shows that there is a large
number of PGWB models that are being co-evolved around
artifacts [23]: DSL1 /Model co-evolution, DSL/Transformation revision 4100, in response to the evolution in Basics.
co-evolution, and DSL/Editor co-evolution. This example illustrates that presence of inter-DSL de-
The driving cases behind our research are several MDSE pendencies in an MDSE ecosystem causes a ripple e↵ect and
ecosystems at ASML, provider of lithography equipment for increases costs of manual maintenance. Hence, an automatic
the semiconductor industry. The largest ecosystem we con- approach is required to facilitate co-evolution of artifacts in
sider is CARM [2] consisting of 22 EMF-based DSLs, 95 MDSE ecosystems.
QVT model transformations, and 5500 unit-test models sup-
porting development of these transformations [24].
In the CARM ecosystem, models make up the majority 3. A HIGH-LEVEL ARCHITECTURE FOR
of artifacts. Thus, in this work we focus on DSL/model co- CO-EVOLVING MODELS
evolution. The model co-evolution e↵ort required by a DSL As described in Section 2, several types of artifacts must
evolution can be expected to become bigger when carried co-evolve in response to DSL evolution. In this section we
out in the context of an MDSE ecosystem as opposed to a present a high-level architecture for co-evolving models in
single DSL and its models. The reasons are threefold: reuse response to DSL evolution. However, a similar architecture
of concepts from other DSLs, model transformations and may be used for other artifacts. We focus on models (rather
implicit relations between DSLs. than model transformations or editors) since models make
Indeed, meta-models may reuse concepts from other meta- up the majority of CARM artifacts. Moreover, we focus on
models. However, let meta-model X reuse a concept A from co-evolving a single (arbitrary) model in response to the evo-
meta-model Y . If A in Y evolves, models of meta-model X lution of a single DSL. In the case where there are multiple
reusing A (from Y ) might need to co-evolve. Hence, evo- DSLs, we can treat them as a single DSL by resolving all in-
lution of a single DSL, can cause co-evolution of models in clusions and dependencies. When more models are involved,
other DSLs. the proposed process can simply be repeated for each model
Similar ripple e↵ects [25, 26] might be caused by model individually, as we have no assumptions on the model, other
1
We consider a DSL to consist of a meta-model enriched than that it is a valid model for the first version of the DSL.
with OCL constraints. The original work of Di Ruscio, Figure 4 presents a high-level architecture for model co-
Iovino and Pierantonio considered meta-models only. evolution. The process starts when a DSL (1) evolves (2) to
3
(1) (2) (3) Once C4 and C5 are available, one needs to determine
DSL DSL
version Evolve version whether all models would be correctly co-evolved by the
1 2
co-evolution specification, with respect to the evolution of
(12) (14)
Co-evolution
DSLs. As most DSLs only formally define syntax, and not
Evolution DSL
DSL semantics, this is not a question that can be answered. Hence,
we merely require presence of a component, C6, capable
(8)
(5)
(9) (10) (13) of determining whether every (syntactically) valid artifact
Obtain
Evolution
Specification
Derive
Co-evolution
Specification
for DSL version 1 can be co-evolved with respect to a co-
(11) evolution specification to a (syntactically) valid artifact for
DSL version 2. Finally, co-evolution specification depends
Model Model
version Co-evolve version on the evolution specification, i.e., we need the component,
1 2
(6)
C7, presenting a way to do we derive (11) a co-evolution
(4) (7)
specification (13) from an evolution specification (10).
Legend DSL Model Information Injection
Action
4. EXISTING WORK
Specification Input/output Conformance
In the literature, several approaches exist that implement
Figure 4: The framework for positioning research(questions)
(part) of the architecture presented in Figure 4. As men-
with respect to DSL/model co-evolution.
tioned above, although approaches exist for co-evolving trans-
formations [21, 29, 20] and editors [22], we focus on DSL/model
Table 1: A summary of the components of the high-level co-evolution, as models constitute the vast majority of ar-
architecture that have to be implemented. tifacts in the ASML ecosystems. In the remainder of this
section, we discuss previous approaches to DSL/model co-
Comp. Description Fig. 4 evolution and map them onto our architecture. In this way
C1 A way to model meta-model evolution 12 we assess the state-of-the-art and identify directions for fur-
C2 A way to model OCL-constraint evo- 12 ther research. Our discussion of the previous work is in-
lution debted to earlier surveys [30, 13].
C3 A way to obtain an evolution specifi- 9,10 The approaches we survey (primarily) target EMF-based
cation DSLs. Additional ways to construct DSLs exist [31], with
C4 A way to describe when a model is 1,3,4,5, the corresponding ways of dealing with co-evolution.
valid for a given DSL 7,8
C5 A way to describe model co-evolution 13,14 Specifying Evolution: (10,12).
C6 A way to determine if a given co- 6 To allow for the specification of meta-model evolution
evolution specification is total (10), a formalism is required to capture the evolutionary
C7 A way to derive a co-evolution specifi- 10,11, steps of a meta-model from its original to its evolved ver-
cation from an evolution specification 13 sion. To this extent we have computed a complete library of
atomic evolutionary steps based on the meta-meta-model [32].
Using this library, every sequence of evolutionary steps can
a new version (3). Consequently, models (4) conforming (5) be described allowing the implementation of C1.
to that DSL (1) should co-evolve (6) into models (7) con- Alternatively, a generic model-to-model transformation
forming (8) to the new version of the DSL (3). Since manual language such as QVT [33, 34], or a meta-model indepen-
co-evolution of models is too costly, we aim to (partially) au- dent di↵erence DSL such as EMFCompare [35] can be used.
tomate the co-evolution by providing a specification (13) of However, to the best of our knowledge, for OCL (C2) a
how models should co-evolve (6) in a dedicated formalism dedicated formalism is still needed.
(14). To ease the creation of a co-evolution specification
(13), we wish to use a DSL evolution specification (10) to Obtaining an Evolution Specification: (9,10).
derive (11) a partial co-evolution specification (13). There are several ways of obtaining an evolution specifi-
We stress that one can neither expect the automation nor cation, which can be divided into two categories: automatic
the co-evolution specification to be complete. Theoretical evolution specification approximation and manual evolution
limitations of the approach are discussed in Section 5. specification specification.
To support the architecture in Figure 4, one has to imple- Automatic evolution specification approximation is also
ment components listed in Table 1. First of all, a formalism known as di↵erencing. Such approaches such as EMFMi-
is required to model DSL evolution. This formalism can grate [29] and EMFCompare [35] compare the original and
be further decomposed into two components: C1, a way to evolved meta-model to extract a specification of the dif-
model meta-model evolution (12), and C2, a way to model ference. A known shortcoming of these approaches is the
OCL-constraint evolution (12). Furthermore, once the for- inability to choose between several evolution specifications
malism has been chosen a separate component C3 should that can lead from the original meta-model to the evolved
focus on obtaining an evolution specification (9,10), e.g., by one. For instance, when renaming a class, an identical result
inspecting previous changes [29]. may be achieved by deleting the old class and creating a new
In order to co-evolve models in response to DSL evolution, class. Rose et al. [30] argue that no di↵erencing approach
one needs C4, a mechanism deciding whether model (4,7) is can always choose the correct evolution specification.
well-formed (5,8) for a given DSL (1,3), as well as C5 a way Manual Evolution Specification Specification can be achieved
to describe model co-evolution (13,14). by means of a predefined collection of operators, or by record-
4
ing changes. Operator-based methods [14] specify evolu-
Language Workbench Developer M3
tion by means of operators, that each encode a (frequently-
occurring) pattern of co-evolution. The applicability of this
approach relies heavily on the available operators. The state- DSL Developer M2 M2 M2
of-the-art operator-based tool is Edapt2 [36], which we have
evaluated [37], and improved [38]. Change recording ap- DSL User M1 M1 M1 M1 M1 M1
proaches record the actions performed on the meta-model
by the user in order to obtain an evolution specification.
This mitigates the problem presented by the di↵erencing ap- Figure 5: The three levels of meta-modelling, and their avail-
proach, but only is the user works in the correct way. That able information.
is, if a user deletes and adds a class, did they indeed intend
a delete and add, or did they really intend a rename?
Summarizing, various approaches can be found in the lit- starts with the user implementing a co-evolution for a cou-
erature to implement C3. ple of models. From these sample co-evolution specifica-
tions, they derive a generic co-evolution specification that
DSL/Model Conformance: (5,8). should be applicable to all models, dropping the need for an
When a DSL evolves, we can wonder which models are evolution specification all together.
valid before the evolution, and which models are valid after However, regardless of the technique chosen, derived co-
the evolution. evolution specification should be total. Otherwise, a co-
Schoenboeck et al. have formalized conformance into a evolution specification derived might turn out to be useless.
number of OCL constraints [39]. However, this work does Since no implementation of C6 is available to the best of
not cover all constraints used by modern meta-modeling our knowledge, we consider implementation of component
frameworks such as EMF [4]. González et al. have created C7 to be an open question. Additionally, with respect to
a transformation from EMF (including OCL constraints) to this derivation, there are other limitations to consider, which
a constraint solving language CSP [40]. This CSP speci- we will discuss in Section 5.
fication then precisely describes all valid model instances.
Lastly, Anastasakis et al. have created a similar transfor- Conclusion.
mation that formalizes a UML diagram [41] into Alloy [42]. Having summarized the state-of-the-art for DSL/model
Summarizing, the existing formalisms allow one to de- co-evolution, we conclude that the following questions should
scribe the set of all valid models for a given meta-model, be answered, before the DSL/model co-evolution architec-
implementing component C4. ture can be completely implemented:
1. C2: How do we specify OCL evolution?
Specify Co-Evolution: (13,14).
For the specification of co-evolution, several mature lan- 2. C6: Is a given co-evolution specification total?
guages/tools exist, the most generic being QVT [33, 34]. 3. C7: How do we derive a total co-evolution specifica-
Specifically for the co-evolution of models, a tool called Flock tion from an evolution specification?
[43] exists. We thus consider C5 to be adequately addressed
by these existing tools.
5. THEORETICAL LIMITATIONS TO AU-
Valid Co-Evolution Specification: (4,6,7,13). TOMATION
Intuitively, a co-evolution specification takes a model in In the previous sections, we have defined a number of com-
the original language as input and yields a semantically ponents that have to be implemented in order to automate
equivalent model in the evolved language as output. How- the co-evolution of models with respect to DSL evolution.
ever, DSLs defined by a meta-model and OCL constraints Herrmannsdörfer et al. have already argued that, in gen-
merely define syntax of the models. Hence, addressing valid- eral, no co-evolution specification can fully automate model
ity either calls for analysis of semantics specified elsewhere, co-evolution [44]. In the same work, the authors present a
or for redefinition of validity in terms of syntax. solution based on user interaction. However, there are addi-
Unfortunately semantics are often not formally specified, tional limitations not related to user interaction, but related
but embedded in code generators and interpreters. Hence, to the information available.
we relax the notion of validity and require the co-evolution Deriving co-evolution specifications from evolution specifi-
specification to be total, i.e., every valid model for the orig- cations is hindered by presence of OCL constraints in DSLs.
inal DSL is mapped to a valid model in the evolved DSL. The OCL constraints are not known by the developer of
Summarizing, we observe that to the best of our knowl- (co-)evolution tooling, as they reside at the level of actual
edge, no implementation for C6 is available. meta-models. We structure the information available to de-
veloper of co-evolution tooling by explain the three di↵erent
Deriving a Co-Evolution Specification: (10,11,13). levels of information (illustrated in Figure 5).
Many of the existing solutions for DSL/model co-evolution, At level 1 reside the Language Workbench Developers.
derive a co-evolution specification from the corresponding They have knowledge of a specific meta-meta-model (e.g.,
evolution specification [36, 29]. Ecore [45]), but have no knowledge of specific meta-models
Additionally, Kappel et al. [16] have defined a method (e.g., as the workbench they develop may be used outside
called “Model Transformation By-Example”. The method their own company). The challenge they face is that any
tools, or techniques developed must be generic and applica-
2
Previously known as COPE ble to any meta-model conforming to the meta-meta-model.
5
This means that a researcher wanting to create a complete swered before co-evolution specifications can be derived from
and reusable piece of evolution tooling must account for ev- evolution specifications.
ery possible meta-model, and every combination of possible As future work, we consider formal modeling of co-evolution
OCL constraints on that meta-model. With respect to co- specifications and checking whether their validity. Addition-
evolutions for these evolutions, every valid instance of that ally, we are considering specification of OCL evolution as
DSL (i.e., any possible meta-model with any valid combina- future work.
tion of OCL constraints) should be accounted for. We deem
that creating reusable pieces of tooling at this level is, there-
fore, unfeasible. What remains is to assist the developers at
7. REFERENCES
the next level in creating good co-evolution specifications. [1] M. Herrmannsdörfer, S. Benz, and E. Juergens,
At level 2 reside the DSL Developers. DSL developers “Automatability of coupled evolution of metamodels
have knowledge of their own specific meta-model including and models in practice,” in MoDELS, ser. LNCS.
the OCL constraints present. Additionally the DSL devel- Springer, 2008, vol. 5301, pp. 645–659.
oper has access to the evolution specification of that meta- [2] R. R. H. Schi↵elers, W. Alberts, and J. P. M. Voeten,
model and its OCL constraints. However, the DSL developer “Model-based specification, analysis and synthesis of
may still have no knowledge of which instances (models) of servo controllers for lithoscanners,” in 6th
their DSL actually exist (e.g., because the models are made International Workshop on Multi-Paradigm Modeling.
at external companies), and must thus (in their work) ac- ACM, 2012, pp. 55–60.
count for all possible models. However, tooling exists to [3] M. Herrmannsdörfer, D. Ratiu, and G. Wachsmuth,
give a formal definition of what a valid model is (e.g., us- “Language evolution in practice: The history of GMF,”
ing EMFtoCSP [40]). In this sense, we could help the DSL ser. LNCS, vol. 5969. Springer, 2009, pp. 3–22.
developers gain insight into the models that could exist [4] D. Steinberg, F. Budinsky, M. Paternostro, and
At the lowest level, level 3, reside the DSL users. These E. Merks, EMF: Eclipse Modeling Framework 2.0,
users actually create models. At this level there is knowledge 2nd ed. Addison-Wesley, 2009.
of all levels (models, meta-models and meta-meta-models) [5] T. Kühne, “Matters of (meta-) modeling,” Software &
and the evolution of meta-models. However, creating tooling Systems Modeling, vol. 5, no. 4, pp. 369–385, 2006.
here is not feasible, as it would have to be re-created for
[6] J. Warmer and A. Kleppe, The Object Constraint
every individual version of every individual DSL.
Language: Getting Your Models Ready for MDA,
As, at level 1 there is not enough information to create
2nd ed. Addison-Wesley, 2003.
static reusable pieces of (co-evolution) knowledge. One can
never give a fixed mapping from an evolution specification [7] “OMG SysML,” http://www.omgsysml.org/, accessed:
to a co-evolution specification that works for every meta- 2016-07-05.
model, because for every such mapping there is a possible [8] M. Lungu, “Towards reverse engineering software
OCL constraint that can contradict the mapping. ecosystems,” in ICSM, 2008, pp. 428–431.
A solution would be to create a function that, given a DSL [9] A. Serebrenik and T. Mens, “Challenges in software
(meta-model + OCL) and an evolution specification, yields ecosystems research,” in ECSA Workshops,
a co-evolution specification. Such a function would have to I. Crnkovic, Ed. ACM, 2015, pp. 40:1–40:6.
account for every possible meta-model, and every possible [10] T. Mens, M. Claes, P. Grosjean, and A. Serebrenik,
combination of OCL constraints on that meta-model. At “Studying evolving software ecosystems based on
present, we do not see how to approach this problem. ecological models,” in Evolving Software Systems,
We thus believe that creation of the evolution-to-co-evolution T. Mens, A. Serebrenik, and A. Cleve, Eds. Springer,
mapping should be carried out at level 2 (DSL developer), 2014, pp. 297–326.
as the DSL developers do have knowledge of which OCL [11] J. Businge, A. Serebrenik, and M. G. J. van den
constraints should be accounted for. The next obvious goal Brand, “An empirical study of the evolution of eclipse
should thus be to support the DSL developer in creating a third-party plug-ins,” in IWPSE-EVOL, A. Capiluppi,
valid mapping (e.g., by creating counter examples of models A. Cleve, and N. Moha, Eds. ACM, 2010, pp. 63–72.
that are not validly co-evolved for a given mapping). [12] J.-M. Favre, “Languages evolve too! changing the
software time scale,” in Principles of Software
6. CONCLUSION AND FUTURE WORK Evolution, 2005, pp. 33–42.
In this paper, we have presented a high-level architecture [13] M. Herrmannsdörfer and G. Wachsmuth, “Coupled
for implementing a tool that automates model co-evolution evolution of software metamodels and models,” in
with respect to DSL evolution to the highest degree possible. Evolving Software Systems. Springer, 2014, pp.
Based on this architecture, we have presented a number of 33–63.
questions that have to be answered before the architecture [14] G. Wachsmuth, “Metamodel adaptation and model
can be fully implemented. co-adaptation,” in ECOOP, ser. LNCS. Springer,
Furthermore, we have looked at the state of the art in 2007, vol. 4609, pp. 600–624.
DSL/model co-evolution to assess to what extent the posed [15] A. Cicchetti, D. Di Ruscio, R. Eramo, and
questions have already been answered. We concluded that A. Pierantonio, “Automating co-evolution in
specification of both meta-model evolution, and model co- model-driven engineering,” in IEEE Enterprise
evolution are supported by existing formalisms, but the spec- Distributed Object Computing Conference, 2008, pp.
ification of OCL evolution is not. Furthermore, we observe 222–231.
that there is no formal check whether a given co-evolution [16] G. Kappel, P. Langer, W. Retschitzegger,
specification is valid, and that this question has to be an- W. Schwinger, and M. Wimmer, “Model
6
transformation by-example: A survey of the first [29] J. Di Rocco, L. Iovino, and A. Pierantonio, “Bridging
wave,” in Conceptual Modelling and Its Theoretical state-based di↵erencing and co-evolution,” in
Foundations, ser. LNCS. Springer, 2012, vol. 7260, Workshop on Models and Evolution. ACM, 2012, pp.
pp. 197–215. 15–20.
[17] L. M. Rose, A. Etien, D. Mendez, D. S. Kolovos, [30] L. M. Rose, R. F. Paige, D. S. Kolovos, and F. A. C.
F. A. C. Polack, and R. F. Paige, “Comparing Polack, “An analysis of approaches to model
Model-Metamodel and Transformation-Metamodel migration,” in MoDSE-MCCM Workshop, 2009, pp.
Co-evolution,” in Model and Evolution Workshop, 6–15.
2010. [31] S. Erdweg, T. van der Storm, M. Völter, M. Boersma,
[18] B. Gruschko, D. Kolovos, and R. Paige, “Towards R. Bosman, W. R. Cook, A. Gerritsen, A. Hulshout,
synchronizing models with evolving metamodels,” in S. Kelly, A. Loh, G. D. P. Konat, P. J. Molina,
Workshop on Model-Driven Software Evolution, 2007. M. Palatnik, R. Pohjonen, E. Schindler, K. Schindler,
[19] A. Narayanan, T. Levendovszky, D. Balasubramanian, R. Solmi, V. A. Vergu, E. Visser, K. van der Vlist,
and G. Karsai, “Automatic domain model migration G. H. Wachsmuth, and J. van der Woning, The State
to manage metamodel evolution,” in MoDELS, ser. of the Art in Language Workbenches. Springer, 2013,
LNCS. Springer, 2009, vol. 5795, pp. 706–711. pp. 197–217.
[20] J. Garcı́a, O. Diaz, and M. Azanza, “Model [32] J. G. M. Mengerink, A. Serebrenik, R. R. H.
transformation co-evolution: A semi-automatic Schi↵elers, and M. G. J. van den Brand, “A complete
approach,” in SLE, ser. LNCS. Springer, 2013, vol. operator library for DSL evolution specification,” in
7745, pp. 144–163. ICSME, 2016.
[21] T. Levendovszky, D. Balasubramanian, A. Narayanan, [33] “QVT,” http://www.omg.org/spec/QVT/, accessed:
and G. Karsai, “A novel approach to semi-automated 2015-04-07.
evolution of dsml model transformation,” in SLE, ser. [34] “QVTo,” http://www.eclipse.org/mmt/?project=qvto,
LNCS. Springer, 2010, vol. 5969, pp. 23–41. accessed: 2015-04-07.
[22] D. Di Ruscio, R. Lämmel, and A. Pierantonio, [35] “EMF Compare,”
“Automated co-evolution of GMF editor models,” in https://www.eclipse.org/emf/compare/, accessed:
SLE, ser. LNCS. Springer, 2011, vol. 6563, pp. 2015-04-07.
143–162. [36] “Edapt,” https://www.eclipse.org/edapt/, accessed:
[23] D. Di Ruscio, L. Iovino, and A. Pierantonio, 2015-04-07.
“Evolutionary togetherness: How to manage coupled [37] Y. Vissers, J. G. M. Mengerink, R. R. H. Schi↵elers,
evolution in metamodeling ecosystems,” in Graph A. Serebrenik, and M. Reniers, “Maintenance of
Transformations, ser. LNCS. Springer, 2012, vol. specification models in industry using Edapt,” in FDL,
7562, pp. 20–37. 2016.
[24] J.G.M. Mengerink, R.R.H. Schi↵elers, A. Serebrenik, [38] J. G. M. Mengerink, A. Serebrenik, R. R. H.
and M.G.J. van den Brand, “Evolution specification Schi↵elers, and M. G. J. van den Brand, “Udapt:
evaluation in industrial mdse ecosystems,” Eindhoven Edapt extensions for industrial application,” in
University of Technology, Tech. Rep. CSR-15-04, 2015. IT.SLE, ser. CEUR-WS, 2016.
[Online]. Available: https: [39] E. Burger and A. Toshovski, “Di↵erence-based
//pure.tue.nl/ws/files/3757969/390954927658277.pdf Conformance Checking for Ecore Metamodels,” in
[25] F. M. Haney, “Module connection analysis: A tool for Proceedings of Modellierung 2014, ser. GI-LNI, vol.
scheduling software debugging activities,” in 225, 2014.
Proceedings of the December 5-7, 1972, Fall Joint [40] C. A. González, F. Büttner, R. Clarisó, and J. Cabot,
Computer Conference, Part I, ser. AFIPS ’72 (Fall, “Emftocsp: A tool for the lightweight verification of
part I). ACM, 1972, pp. 173–179. emf models,” in Formal Methods in Software
[26] S. S. Yau, J. S. Collofello, and T. MacGregor, “Ripple Engineering: Rigorous and Agile Approaches, ser.
e↵ect analysis of software maintenance,” in Computer FormSERA ’12. IEEE, 2012, pp. 44–50.
Software and Applications Conference, 1978. [41] “UML,” http://www.uml.org/, accessed: 2016-06-28.
COMPSAC ’78. The IEEE Computer Society’s Second [42] D. Jackson, Software Abstractions: logic, language,
International, 1978, pp. 60–65. and analysis. MIT press, 2012.
[27] T. Zimmermann, V. Dallmeier, K. Halachev, and [43] L. M. Rose, D. S. Kolovos, R. F. Paige, and F. A.
A. Zeller, “erose: guiding programmers in eclipse,” in Polack, “Model migration with Epsilon Flock,” in
Companion to the 20th annual ACM SIGPLAN Theory and Practice of Model Transformations, ser.
conference on Object-oriented programming, systems, LNCS. Springer, 2010, vol. 6142, pp. 184–198.
languages, and applications. ACM, 2005, pp. 186–187. [44] M. Herrmannsdörfer and D. Ratiu, “Limitations of
[28] R. Jongeling, “Change Impact Analysis in Model automating model migration in response to
Driven Software Engineering Ecosystems,” Master’s metamodel adaptation,” in MSE, Workshops and
thesis, Eindhoven University of Technology, the Symposia at MODELS, ser. LNCS, vol. 6002.
Netherlands, 2016. [Online]. Available: Springer, 2009, pp. 205–219.
http://alexandria.tue.nl/extra1/afstversl/wsk-i/ [45] “Ecore,” lhttp://www.eclipse.org/modeling/emf/,
Jongeling 2016.pdf accessed: 2016-7-20.
7