Approaches to Co-Evolution of Metamodels and Models: a Survey
Total Page:16
File Type:pdf, Size:1020Kb
This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TSE.2016.2610424 JOURNAL OF LATEX CLASS FILES, VOL. 13, NO. 9, SEPTEMBER 2014 1 Approaches to Co-Evolution of Metamodels and Models: A Survey Regina Hebig, Djamel Eddine Khelladi, and Reda Bendraou, Abstract—Modeling languages, just as all software artifacts, evolve. This poses the risk that legacy models of a company get lost, when they become incompatible with the new language version. To address this risk, a multitude of approaches for metamodel-model co-evolution were proposed in the last 10 years. However, the high number of solutions makes it difficult for practitioners to choose an appropriate approach. In this paper, we present a survey on 31 approaches to support metamodel-model co-evolution. We introduce a taxonomy of solution techniques and classify the existing approaches. To support researchers, we discuss the state of the art, in order to better identify open issues. Furthermore, we use the results to provide a decision support for practitioners, who aim to adopt solutions from research. Index Terms—Survey, software engineering, metamodels, models, design notations and documentation F 1 INTRODUCTION N the last decade, Model-Driven Engineering has proven any modification in the metamodel may impact all the I to be effective in the development and maintenance of other artifacts i.e. editors, code generators, transformation large scale and embedded systems [1], [2]. At the heart of rules, consistency constraints, etc. [8]. In [9] authors reported this vision is the notion of Metamodel, a formal definition how difficult it can be to update a GMF-based graphical of the language that will be used to represent models of editor after a metamodel evolution. Our industrial partner the application’s domain. Raising the level of abstraction KI5 reported that in the automotive domain, companies, from code to models combined with the promise of better such as Renault, use DSMLs for modeling their products. productivity and a shorter product development life-cycle, However, due to the competitive nature of this industrial have led to the emergence of an impressive number of field, metamodels have to be extended and evolved almost DSMLs (Domain Specific Modeling Languages). The use of every two years to include new concepts from the problem DSMLs would increase productivity between 200% (Adap- domain. This has an effect on the tedious task of not only tive Cruise Control) to 750% (Home automation, phone evolving the tooling chain but also model instances. Airbus6 switch features), according to [3]. Today, almost every busi- and Thales7, which were involved with us in the research ness and industrial domain has a dedicated DSML [4] projects MOVIDA8, ANR Galaxy9 and MeRGE10, mentioned and plenty of tools are provided to help you design your model instances with up to 500 000 model elements to be mi- own modeling language, e.g. EMF1, OBEO Designer2, or grated in some cases. Another example of artifacts that may Metaedit3. be impacted by metamodel evolution are OCL constraints. However, DSMLs do not come alone. Their productivity The UML metamodel11 comes with more than 700 OCL is mainly ensured by the ecosystem that surrounds them. constraints which may be impacted in case of an evolution. This includes code generators, text and graphical editors, However, the UML metamodel evolved quite often in the e.g. Xtext [5] or GMF4, rule and constraints consistency last decade12. BPMN evolved every three to four years since checker engines [6][7], and many other artifacts that con- it has been specified in 200413. Transformation rules are stitute the development chain, spanning from modeling the also highly related to metamodel elements. Especially if you problem domain to the code of the future system. While are dealing with exogenous model transformation (source this development chain is effective and efficient, its Achilles and target metamodels are different). Every modification of heel remains the metamodel. One can see it as the central either source or target metamodels will impact the trans- point of a dependency graph of artifacts and tools since formation rules, sometimes hundreds of them, and requires to manually or semi-automatically migrate them [10], [11], [12]. • R. Hebig is with the Chalmers j University of Gothenburg, Computer Science and Engineering G¨oteborg, V¨astra G¨otaland County, Sweden. 5. KnowledgeInside http://www.k-inside.com/web/fr D. Khelladi and R. Bendraou are with the Sorbonne Universit´es,UPMC 6. Airbus http://www.airbus.com/ Univ Paris 06, UMR 7606, LIP6, F-75005, Paris, France. 7. Thales https://www.thalesgroup.com E-mail: [email protected], [email protected], 8. Movida http://www.agence-nationale-recherche.fr/?Projet= [email protected] ANR-08-SEGI-0011 Manuscript received April 19, 2015; 9. ANR Galaxy http://www.galaxy.lip6.fr 1. Eclipse Modeling Framework http://www.eclipse.org/modeling/ 10. MeRGE http://www.merge-project.eu/ emf/ 11. UML standard http://www.omg.org/spec/UML/ 2. OBEO Designer http://www.obeodesigner.com/ 12. For an overview of different versions of the UML see http:// 3. Metaedit http://www.metacase.com/products.html www.omg.org/spec/UML/ 4. GMF http://eclipse.org/modeling/gmf 13. BPMN http://www.omg.org/spec/BPMN/ Copyright (c) 2016 IEEE. Personal use is permitted. For any other purposes, permission must be obtained from the IEEE by emailing [email protected]. This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TSE.2016.2610424 JOURNAL OF LATEX CLASS FILES, VOL. 13, NO. 9, SEPTEMBER 2014 2 The examples given above highlight the importance of 2 METHOD dealing with metamodels evolution especially with the wide spread of DSMLs. Some companies are already facing this In this section, we describe how we identified and analyzed problem. Through KI we know that Renault has invested the approaches considered within this survey. money and time to build DSMLs while underestimating the cost of co-evolving the related tools and model instances every time the metamodel is impacted. We believe that in 2.1 Exclusion Criteria for Supporting Approaches the near future, this problem, if not handled, can be an This survey includes approaches for co-evolution that either obstacle to the adoption and use of DSMLs. support the identification of metamodel changes as an input Metamodels co-evolution has already been identified as for model resolution or propose model resolutions in form a main issue in the literature [13], [14], [15]. The evolution of more generic strategies or model specific resolutions. between two versions of the same metamodel may consist of To make this survey feasible and keep the comparison hundreds of additions, deletions, and changes of elements. meaningful, we excluded supporting approaches that might For example, during the evolution of UML Class Diagrams be used to perform co-evolution manually or that are a from UML version 1.5 to 2.0 a total of 238 language elements standard inbuilt part of co-evolution approaches today. where added, deleted, or changed [16]. For the evolution There are approaches for conformance checking, such as from GMF version 1.0 to 2.0, 136 changes have been identi- discussed by Paige et al. [17] or the approach of Iovino fied by Herrmannsdoerfer et al. [13]. et al. [18]. Similarly, there are a multitude of approaches In the last decade, the literature introduced 31 ap- that allow to check for constraints on models, e.g. using proaches that focus exclusively on the co-evolution of mod- Answer Set Programming (ASP [19]) or the Epsilon Vali- els when the metamodel is evolved. These 31 approaches dation Language14. All of these approaches can help a user differ in the way they solve the involved tasks which are to identify what elements of a model are broken with regard a) the identification of metamodel changes and b) the co- to a new metamodel version. However, we do not include evolution of model instances. Thus, it is a challenge for these approaches in this survey, as they do not lead to an the users to identify which approach can best fit their automated resolution support. needs. Indeed, from the user’s perspective these approaches Naturally, all approaches that consume metamodel may differ significantly. The trade-off between correctness changes for the co-evolution rely on tools to identify these and automation could be one way to compare them. Fully changes. These can be tools used to retrieve model differ- automated approaches make it easier to handle huge sets ences, such as EMF compare15, or tools to record changes of models while it might not be possible to guarantee online, such as the seminal work of Alan and Porres [20] that the resulting models conform to the required outcome. or Praxis [6]. Thus, the identification of atomic changes, i.e. Approaches that provide more control for the user while the creation, deletion or modification of single metamodel performing the co-evolution might be preferable when some elements, can be considered as being well established and adaptation and customizations are required. Besides, some is included in most approaches today. In the remainder implicit prerequisites, such as required skills or language’s of this survey we therefore do not address these works ownership, need to be identified and considered before as standalone approaches.