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