Consistency Recovery in Interactive Modeling Juri Di Rocco1 , Davide Di Ruscio1 , Marcel Heinz2 , Ludovico Iovino3 , Ralf Lämmel1,2 , Alfonso Pierantonio1 1 DISIM, University of l’Aquila, Italy 2 Faculty of Computer Science, University of Koblenz-Landau Germany 3 Gran Sasso Science Institute, L’Aquila, Italy Abstract—MDE projects contain different kinds of artifacts targets the web-based modeling platform MDEF ORGE [5]. An such as models, metamodels, model transformations, and deltas. original aspect of MegaL/Forge is that its semantic model These artifacts are related in terms of relationships such as trans- addresses consistency recovery; the approach is inspired by formation or conformance. In this paper, we capture the types of artifacts and the relevant relationships in a megamodeling- our previous work on relationship maintenance in software based manner for the purpose of monitoring and recovering a language repositories [11]. In this paper, we focus on defining MDE project’s consistency in response to changes that users may the consistency-recovering response to a repository change apply to the project within an interactive modeling platform. The while taking interaction with the user of a modeling platform approach supports users in experimenting with MDE projects into account. and receiving feedback upon changes on the grounds of a specific execution semantics for megamodels. The approach is validated Roadmap of the paper: Sec. II develops the running within the web-based modeling platform MDEF ORGE. example of the paper. Sec. III defines syntax and semantics of Index Terms—Model management; Model repository; Consis- the required megamodeling language. Sec. IV provides a semi- tency recovery; Megamodeling; Modeling platforms formal account on consistency recovery. Sec. V discusses the integration of the approach into the web-based modeling plat- I. I NTRODUCTION form MDEF ORGE. Sec. VI discusses related work. Sec. VII Research context: This research is concerned with model concludes the paper. management [1], [2] on top of model repositories [3], [4] which users can access through a modeling platform [5], II. T HE RUNNING E XAMPLE [6]. Model repositories are a promising form of aggregating For brevity and focus on the key idea, we commit to a reusable MDE artifacts such as models, metamodels, and very basic running example here: there are two models m1 model transformations. Model management is the model-based and m2 that conform to the same metamodel mm with the (model-driven) approach to the automated management of difference being referred to as delta and model management collections of MDE artifacts instead of using ad-hoc tools or operations in place to express conformance of m1 and m2 lacking good automation. Modeling platforms such as Eclipse, to mm, comparison so that delta represents the difference MDEF ORGE, or MMINT are essential tools for users of model between m1 and m2, and patching so that m2 is the result of repositories—users may either explore MDE artifacts in a patching m1 according to delta. This simple example involves repository or they may be developers in some scope of the enough semantical issues so that it suffices for an initial repository. language design discussion. In our ongoing research, we also Research objective: We want to exercise an effective, model more involved scenarios. declarative (model-based), and transparent (understandable) approach to organizing the artifacts in an MDE project (in A. An EMF-related Prelude a model repository or not) and the relationships between the artifacts. That is, a model-managed project has an associated The running example operates within the EMF technologi- megamodel so that a user (a developer within the project) cal space. We need these types of artifacts; we use the concrete can understand the structure of the project in megamodeling syntax of MegaL/Forge for expressing the type definitions: terms. Further, the project’s consistency with the megamodel EmfModel // EMF−based models (XMI representation) is continuously monitored in the background of the interactive EmfMetamodel < EmfModel // Ecore models modeling platform so that any changes can be mapped to EmfCompareModel < EmfModel // Delta models corrective, automated actions to be proposed to and confirmed That is, we declare types EmfModel, EmfMetamodel, and by the user. EmfCompareModel; we organize these types in a hierarchy Research contribution: We address the research objective (‘<’). In the running example, we also need certain model- by an emerging language design, definition, implementation, management operations on the types just declared; again, and integration into a modeling platform. The language and its we use the concrete syntax of MegaL/Forge for expressing implementation are referred to as MegaL/Forge because the signatures of relations and functions: language is inspired by our previous work on linguistic archi- conformsTo : EmfModel × EmfMetaModel tecture, as a form of megamodeling, as realized by the MegaL compare : EmfModel × EmfModel → EmfCompareModel family of languages [7], [8], [9], [10] and the integration patch : EmfModel × EmfCompareModel → EmfModel That is, we have access to conformance checking (conform- means of the patch function, thereby deriving a new version sTo—a relation), model comparison (compare—a function), of m2 that is ‘in sync’ with m1 and delta. (Adding domain and delta application (patch—another function). knowledge (‘algebraic reasoning’), we know that the new version of m2 equals the original one.) Thus, the following B. An MDE Project’s Megamodel list of function applications facilitates consistency recovery: The following megamodel declares artifact ids for models compare(m1, m2) 7→ delta m1 and m2, the shared metamodel mm to which both models patch(m1, delta) 7→ m2 are assumed to conform to, and the delta (difference) between the models. Conformance, comparison, and patch application 2.b) First patch, then compare: Thus: are expressed by appropriate applications of relation conform- patch(m1, delta) 7→ m2 sTo and functions compare and path. Thus: compare(m1, m2) 7→ delta m1, m2 : EmfModel An interactive user may disfavor this option on the grounds mm : EmfMetaModel conformsTo(m1, mm) of domain knowledge such that (the older version of) delta conformsTo(m2, mm) readily captures aspects of m1 (and m2) and thus, it may not delta : EmfCompareModel work well for a new version of m1. compare(m1, m2) 7→ delta patch(m1, delta) 7→ m2 3) Modify m2: We could consider applying the patch Let us apply the MegaL/Forge megamodel to an actual function, thereby deriving a new version of m2 that is ‘in project. That is, artifact identifiers in the megamodel are linked sync’ with m1 and delta. This is clearly not a useful strategy, to actual filenames in the underlying model repository (in fact, as it would overwrite the changes just made to m2. Instead, we a project). We may assume links as follows: need to compare m1 and m2 to compute a new delta. Thus, the following function application facilitates consistency recovery: m1 = ”Family1.xmi” m2 = ”Family2.xmi” compare(m1, m2) 7→ delta mm = ”FamilyMM.ecore” delta = ”Delta.xmi” In fact, now that we changed delta, we may want to check that an application of the patch function would derive a model These links assume relative file names (relative to a base that is equal to the existing model m2. In that case, we would URI for the project). We are concerned with two versions of a have recovered consistency in the project. Of course, this is model for describing ‘families’ (family members, i.e., persons exactly the semantics of comparison: it provides a delta for with names and some relationships or attributes), subject to two models so that the second model can be derived from the a suitable metamodel, and a delta (a difference) between the first one by applying the delta as a patch. two models at hand. III. L ANGUAGE D EFINITION C. Change scenarios We provide a language definition of MegaL/Forge. In The modeling artefacts are subject to evolution [12]: models particular, we define the concrete syntax by means of a are modified and updated during the engineering process and grammar and the abstract syntax by means of a metamodel. the metamodels evolve over time to address changes to the We also briefly discuss the static semantics for well-formed requirements. Let us just imagine changes to artifacts of megamodels. Finally, we define what may account for a the project at hand. We should also explain how we expect dynamic semantics by means of a consistency notion—an to respond to these changes, thereby characterizing change MDE project (its artifacts) to be consistent with a megamodel. scenarios. The key idea is that function applications in the megamodel may need to be used to recover consistency. A. Concrete Syntax 1) Modify delta: We propagate this change by applying The following grammar (in ANTLR notation) defines the the patch function, thereby deriving a new version of m2 that concrete syntax of the MegaL/Forge constructs exercised in is ‘in sync’ with m1 and delta. Thus, the following function the present paper (Sec. II). application facilitates consistency recovery: megamodel : declaration+; declaration patch(m1, delta) 7→ m2 : type // Root entity type We should note that we do not want to apply the com- | subtype // Entity type as subtype | artifact // Entity pare function (beforehand or afterwards) because we consider | relation // Relation signature changed artifacts (such as delta here) as ‘authoritative’ [13] | function // Function signature which we do not want to overwrite along consistency recovery. | relatesTo // Relationship | mapsTo // Function application 2) Modify m1: There are two options: | link ; // Artifact binding 2.a) First compare, then patch: We apply the compare type : ID ; // Base type subtype : ID ’<’ ID ; // Subtype < supertype function to the (changed) model m1 and the (unchanged) artifact : ID (’,’ ID)∗ ’:’ ID ; // Artifacts of a given type model m2 to compute a new version of delta to be applied by relation : ID ’:’ ID (’#’ ID)∗ ; // Signature function : ID ’:’ ID (’#’ ID)∗ ’−>’ ID; // Signature We take consistency to mean that all relationships on relatesTo : ID ’(’ ID (’,’ ID)∗ ’)’ ; // Relationship artifacts in the project, as expressed by the megamodel, i.e., mapsTo : ID ’(’ ID (’,’ ID)∗ ’)’ ’|−>’ ID; // Apply function link : ID ’=’ ’”’ LINK ’”’ ; // Bind artifact symbol to filename applications of relations and functions, must hold, subject to suitable interpretations of the applied relations or functions. The type and subtype forms of declaration facilitate the Details follow below. definition of a nominal classification hierarchy for artifacts. 1) Environments for Interpretation: In an effort to set up Actual artifacts are introduced by their name (an id); see interpretations of symbols used in megamodels systematically, declaration form artifact. The declaration forms relation and we assume an environment E which is, in fact, a triple function facilitate signatures including names for arguments hEA , ER , EF i as follows: and results (the latter for functions only). There is a declaration • EA maps artifact symbols, as they are used in the form relatesTo for expressing relationships on artifacts. There megamodel, to actual artifact representations in the sense is a declaration form mapsTo for expressing the specific of text, JSON, etc. In the MegaL/Forge notation (see relationship of function application. Finally, there is a special Section II-B), we assume a mapping from artifact sym- declaration form link for binding artifact symbols to files. bols to files. In the semi-formal model at hand, we assume Making the links part of the megamodel rather than desig- a universe U for representations of artifacts. We use nating a separate model for links can be compared to the use the type U in setting up interpretations for relation and of annotations in OO programming rather than using XML- function symbols; see below. based configuration. • ER maps relation symbols to their interpretations; these MegaL/Forge is a very simple member in the MegaL are predicates of type U + → Boolean. We use here U + language family [7], [8], [9]. In particular, there is only one for each predicate’s argument because, in this manner, a kind of types—as opposed to languages versus artifacts versus simple generic type suffices for all possible relations. The concepts in other MegaL languages. idea is, of course, that a suitable interpretation enforces B. Abstract Syntax a certain length (a certain number of parameters) and The metamodel defining the abstract syntax of the language appropriate representation types (subtypes of U ) for the is shown in Fig. 1. In particular, a megamodel specification different parameters. consists of a set of Artifacts of different Types. Each function • EF maps function symbols to their interpretations; these (relation) is defined by means of a Function (Relation) dec- are functions of type U + → U . laration and the corresponding MapsTo (RelatesTo) definition. As an environment effectively represents what we think Artifacts are arguments of Functions and Relations as shown of as a ‘project’, we may also speak of consistency of a by the constructors of the MapsTo and RelatesTo elements. megamodel with an environment. The former consists of input and output elements, whereas the 2) Consistency = Relational + Functional Consistency: latter consists of the set of artifacts for which the specified We speak of relational consistency when the interpretation of relation holds. All the elements in the figure specialize a all relation applications (‘relationships) in a given megamodel NamedElement class (not shown in the figure for brevity) m for a given environment E returns true. We speak of consisting of the name attribute of type String. functional consistency when the interpretation of all function applications in the megamodel m with the environment E C. Static Semantics = Well-formedness returns true. Details of the assumed notion of interpretation A static semantics for well-formedness of MegaL/Forge- follow. like megamodels was defined as a definite clause program A relation application r(a1 , . . . , an ) with the relation sym- in previous work [8]. We summarize the relevant constraints bol r and artifact symbols a1 , . . . , an as arguments is inter- informally to make this text more self-contained. preted by applying the interpretation of r to the interpretations a) Types, artifacts, relations, and function are declared of a1 , . . . , an , as defined by the environment. Thus: before they are used. b) Each name can be declared once only (‘no overloading’ here of any kind). c) The arguments of ER (r)(hEA (a1 ), . . . , EA (an )i) relationships and function applications and results of function A function application f (a1 , . . . , an ) 7→ an+1 with the applications must be of the types as prescribed by the sig- function symbol f , artifact symbols a1 , . . . , an as arguments, natures of the corresponding relations and functions. d) Each and an artifact symbol an+1 for the result is interpreted by artifact symbol is linked to some filename. (We do not consider applying the interpretation of f to the interpretations of a1 , incompletely bound megamodels here.) . . . , an , as defined by the environment, and comparing the D. Dynamic Semantics = Consistency result with the interpretation of an−1 for equality. Thus: Megamodels may have various dynamic semantics [8], [11]; EF (f )(hEA (a1 ), . . . , EA (an )i) = EA (an+1 ) we are interested here specifically in a semantics that captures consistency of an MDE project with regard to a megamodel. For consistency to hold, the formulae as described above We provide a simple semantics of this kind from the ground should evaluate to true for all relation and function applica- up here. tions. Fig. 1. The MegaL/Forge metamodel. IV. C ONSISTENCY RECOVERY see the two scenarios for changing m1 in Sec. II-C2. We In response to a change in a project, we perform a recovery may either delegate such nondeterminism to the interactive analysis on the megamodel to determine the function applica- component or enhance megamodels and the analysis thereof tions (a recovery sequence) for recovering consistency, when to resolve nondeterminism automatically. applied to the artifacts in the project. Let us now sketch a first attempt at the desired analysis; we defer proper treatment of nondeterminism to future work. We A. Recovery Sequence need helper functions as follows: When consistency does not hold, then we may try to • in(m, a) returns all the function applications in the meg- ‘overwrite’ artifacts according to function applications so that amodel m with the artifact symbol a as an argument. consistency is recovered. The major assumption is here that • out(fa) returns the artifact symbol for the result of the function applications, as they are part of the megamodel at function application fa. hand, suffice for consistency recovery and a suitable order can The main function for recovery analysis, ra, takes as be determined. In more detail, given a sequence of function arguments the megamodel m, an artifact symbol ac indicating applications fa1 , . . . , fan from a given megamodel m, we call the change, a sequence S of function applications, and it it a recovery sequence for a given environment E, if returns a sequence of function applications that may be a • E is not consistent with m. recovery sequence. We begin with an empty S and extend • Apply fa1 , . . . , fan in the given order to overwrite the it into the result sequence, step by step. artifact symbols for the results in the environment E. • The updated environment E is now consistent with m.  ac , S) = ra(m,  ra(m, ac , S+ +hfai), with fa drawn from m such that B. Recovery Analysis     − fa ∈ 6 S, and  − fa ∈ in(m, a ) ∪ S 0 in(m, out(fa0 )), and  It remains to define an analysis for megamodels to map c fa ∈S changes to recovery sequences. For simplicity, we start from   − out(fa) 6 = ac , and 0 0 the assumption that changes are atomic in the sense that single  − out(fa) 6= out(fa ) for all fa ∈ S.    artifacts are changed on a discrete timeline and consistency S, otherwise (if there is no such fa)  is to be recovered after each change. Thus, the analysis is (‘++’ is list append.) The conditions control that we select essentially a mapping from a megamodel m and an artifact function applications that can be applied to ac and results of symbol ac identifying the actual change to a sequence of previous applications without though any overwriting. The for- function applications. mulation is nondeterministic, as different function applications Let us discuss expected properties of the analysis. We do could be picked in a step. not want to map a change to a sequence that would change an For instance, for the megamodel of Sec. II and ac = m1, artifact that was changed previously, as such ‘overwriting’ may starting from S = ∅, the analysis returns a sequence starting be semantically debatable and it may also lead to divergence. with a comparison, followed by a patch as follows: As a special case, we do not want to apply any function application twice. For instance, this could happen, in the compare(m1, m2) 7→ delta patch(m1, delta) 7→ m2 running example, if we were responding to model changes with comparison and patching in a cyclic manner. Here we assume that the analysis respects the megamodel- We also need to address ‘nondeterminism’ in the context of defined order of function applications. (Also, ‘∪’ operates on consistency recovery. That is, there may exist megamodels and sequences rather than sets.) Proper treatment of nondetermin- changes for which different recovery sequences are possible; ism is deferred to future work. V. I NTEGRATION INTO MDEF ORGE megamodel is performed by the method checkConsistency This section presents the implementation of the presented shown below: consistency recovery approach, which has been integrated in public boolean checkConsistency(Project project, Megamodel megamodel) { the MDEF ORGE platform [5]. MDEF ORGE was proposed as for (Artifact relatesTo : m.models) { List changes= checkChanges(project); an extensible platform enabling the adoption of model man- if (changes.size()==0) return true; agement tools as SaaS (software as a service). By resembling } facilities of desktop IDEs, like Eclipse, MDEF ORGE users for (RelatesTo relatesTo : m.relatesTos) { IOperationApplier opApplier = operationMapper.get(relatesTo. have the possibility to create modeling artifacts and organize getType()); them in projects that are, in turn, contained in workspaces. boolean result = (boolean) opApplier.apply(relatesTo.arguments); The consistency recovery mechanism presented in the pre- if (!result) return false; } vious section has been integrated in MDEF ORGE by essen- return true; tially extending the existing project management facilities. In } particular, the Java packages ProjectMonitoring and Consis- The method consistencyRecovery implements the recovery tencyManagement shown in Fig. 2 contain the new classes mechanism by exploiting the getFunctionsToRecoverConsis- and interfaces that have been added in the MDEF ORGE tency method shown in the listing below. It is responsible of implementation. The existing package CoreService has been identifying the functions to be applied and their execution extended to work with such new packages. order for recovering the consistency between the changed The ProjectMonitoring package implements listeners that project and the corresponding megamodel. execute the consistency recovery manager when artifacts or projects are changed. In such cases, ApplicationEvents are public List getFunctionsToRecoverConsistency(Project project, Megamodel megamodel){ created as shown in the listing below and used by Arti- List result = new ArrayList(); factChangedListener and ProjectChangedListener to interact List changes=checkChanges(project); with the ConsistencyRecoveryManager. for (MapsTo function : m.functions) { if (function.inputs.contains(changes)) result.add(function); public void update(T artifact) { } ... return result; eventPublisher.publishEvent(new ArtifactChangedEvent(artifact, ” } UPDATE”)); artifactRepository.save(artifact); A fragment of the consistencyRecovery method is as follows: } public void consistencyRecovery(Project project, Megamodel megamodel) { The ConsistencyManagement package implements the pre- checkConsistency(project, megamodel); List toApply = getFunctionsToRecoverConsistency(project, sented consistency recovery concepts. For each symbolic megamodel); function or relation name a corresponding IOperationApplier for (MapsTo function : toApply) { implementation is available. For instance, the functions com- IOperationApplier opApplier = operationMapper.get(function. getType()); pare and patch discussed in Sec. II-B have the correspond- opApplier.apply(m.inputs); ing implementation consisting of the ComparisonApplier and } PatchApplier classes, respectively. Such classes implement ... } the method apply that executes the real behaviour of the corresponding function. For instance, the execution of the Consistency recovery can generate new artifacts that might apply method of the class ComparisonApplier executes the overwrite existing ones. In such cases, the user will be notified comparison mechanism already available in MDEF ORGE (that and will be asked for confirmation, as illustrated with the pop- in turn is based on EMFCompare1 ) as shown in the following up in Fig. 3. The user will also be notified when consistency listing showing a fragment of the apply method of the class recovery fails. We are also working on presenting options to ComparisonApplier: the user. public Object apply(Object[] inputs) { VI. R ELATED W ORK if (inputs.length != 2) throw new Exception(); In general, a few model management platforms exist, such Artifact left = inputs[0]; as MMINT [6] and Mondo [14] that try to support any Artifact right = inputs[1]; kind of operation needed in model driven engineering with a ModelsServiceImpl modelService=new ModelService(); return modelService.compare(left, right); focus on models. The problem of well-formed metamodelling } is directly addressed by the model management platform The links between symbolic operation names and the ‘Modelverse’ [15]. It is a platform emphasizing a consistently corresponding appliers are specified in the operationMap- specified form of metamodelling based on the work by Kühne per HashMap of the ConsistencyRecoveryManager class. The et al. [16]. Tools may not properly check conformance to consistency check between a project and the corresponding metamodels as the static semantics is left unattended [17]. SERGe generates all possible metamodel consistency preserv- 1 https://www.eclipse.org/emf/compare/ ing transformations to be reused by other tools. Fig. 2. Event based architecture of MDEForge. In requirements engineering, the consistency between re- [21] a systematic literature review is presented on consistency quirement artifacts needs to be maintained. In [18] authors checking of business process models that pose further related propose to use the Snapmind Framework and a UML-based approaches in the domain. specification environment for user stories and domain mod- els. The relation between elements in a mind map-based In [22] authors approach consistency checking for evolving user story and domain models are checked. In [19] authors models and consistency recovery using state space exploration explicitly define correspondence relationships in architecture based on postulates defining consistent states. Sunye [23] descriptions for all kinds of digital artifacts. Kowal et al. [20] addresses collaborative modelling processes, where multiple explicitly aim at delta-aware consistency checking for models editors write on the same model. An addressed challenge that are part of difference perspectives by using rules that lies in reproducing the same order of operations for every describe a consistent UML-based architecture description. In accessing node. In [24] authors describe a system using SAT solvers to propagate all possible changes for source models [5] F. Basciani, J. D. Rocco, D. D. Ruscio, A. D. Salle, L. Iovino, and A. Pierantonio, “MDEForge: an Extensible Web-Based Modeling Platform,” in Proc. CloudMDE@MoDELS 2014, vol. 1242, 2014, pp. 66–75. [6] A. D. Sandro, R. Salay, M. Famelis, S. Kokaly, and M. Chechik, “MMINT: A Graphical Tool for Interactive Model Management,” in Proc. MoDELS 2015 Demo and Poster Session, ser. CEUR Workshop Procs, vol. 1554, 2016, pp. 16–19. [7] J. Favre, R. Lämmel, and A. Varanovich, “Modeling the Linguistic Architecture of Software Products,” in Proc. MODELS 2012, ser. LNCS, vol. 7590. Springer, 2012, pp. 151–167. [8] R. Lämmel and A. Varanovich, “Interpretation of Linguistic Architec- ture,” in Proc. ECMFA 2014, ser. LNCS, vol. 8569. Springer, 2014, pp. 67–82. [9] J. Härtel, L. Härtel, M. Heinz, R. Lämmel, and A. Varanovich, “Inter- connected Linguistic Architecture,” The Art, Science, and Engineering Fig. 3. Pop-up asking the user regarding overwriting. of Programming Journal, vol. 1, 2017, 27 pages. [10] M. Heinz, R. Lämmel, and A. Varanovich, “Axioms of linguistic architecture,” in Proc. MODELSWARD 2017. SCITEPRESS, 2017, such that the transformation to view models remains traceable. pp. 478–486. [11] R. Lämmel, “Relationship maintenance in software language reposito- Bidirectional transformations pose a need for consistency ries,” The Art, Science, and Engineering of Programming Journal, vol. 1, checking and change propagation. Demuth et al. [25] discuss 2017, 27 pages. failure detecting for co-evolving metamodels and domain [12] R. F. Paige, N. Matragkas, and L. M. Rose, “Evolving models in model- driven engineering: State-of-the-art and future challenges,” Journal of models. When a consistency check fails, repair measure Systems and Software, vol. 111, pp. 272 – 280, 2016. [Online]. Available: suggestions are automatically generated. Kusel et al. [26] http://www.sciencedirect.com/science/article/pii/S0164121215001909 explicitly state the properties that need to be verified after [13] P. Stevens, “Bidirectional Transformations in the Large,” in MoDELS. ACM, 2017, to appear. a coupled model transformation. Diskin et al. [27] classify the [14] D. S. Kolovos, A. Garcı́a-Domı́nguez, R. F. Paige, E. Guerra, J. S. various kinds of model synchronizations that may have to be Cuadrado, J. de Lara, I. Ráth, D. Varró, G. Sunyé, and M. Tisi, considered. Other kinds of bidirectional transformations and “MONDO: scalable modelling and model management on the cloud,” in STAF, 2016, pp. 55–64. their specific needs are discussed in [28]. [15] S. V. Mierlo, B. Barroca, H. Vangheluwe, E. Syriani, and T. Kühne, “Multi-level modelling in the modelverse,” in MoDELS, 2014, pp. 83– VII. C ONCLUDING R EMARKS 92. In this paper, we have described an approach towards con- [16] T. Kühne, “Matters of (meta-)modeling,” Software and System Modeling, vol. 5, no. 4, pp. 369–385, 2006. sistency recovery in MDE projects such that megamodels are [17] M. Rindt, T. Kehrer, and U. Kelter, “Automatic generation of facilitated for expressing consistency and providing guidance consistency-preserving edit operations for MDE tools,” in MoDELS, for recovery thereof in an interactive setup. We are working on 2014. [18] F. Wanderley, A. Silva, J. Araújo, and D. S. da Silveira, “Snapmind: the following improvements. Firstly, we look at more complex A framework to support consistency and validation of model-based scenarios with richer dependencies between the involved arti- requirements in agile development,” in MoDRE, 2014, pp. 47–56. facts so that the issue of nondeterminism (Sec. IV-B) is (needs [19] A. Chichignoud, F. Noyrit, L. Maillet-Contoz, and F. Terrier, “Use of architecture description to maintain consistency in agile processes,” in to be) properly addressed. For instance, we study examples of MODELSWARD, 2017, pp. 459–466. co-evolution [29]. Secondly, we look at making megamodels [20] M. Kowal and I. Schaefer, “Incremental consistency checking in delta- and the underlying MDE projects explicitly version-aware so oriented uml-models for automation systems,” in Procs. 7th Intl. FM- SPLE@ETAPS Workshop 2016, 2016, pp. 32–45. that consistency recovery can be modeled atop versioning. [21] A. Awadid and S. Nurcan, “A systematic literature review of consistency Thirdly, we look at techniques for automatically creating (at among business process models,” in CAiSE, 2016, pp. 175–195. least initial fragments of) megamodels out of existing MDE [22] H. K. Dam and A. Ghose, “Towards rational and minimal change propagation in model evolution,” CoRR, vol. abs/1402.6046, 2014. projects. Finally, we look at the incorporation of ‘algebraic [23] G. Sunyé, “Model consistency for distributed collaborative modeling,” reasoning’, possibly also subject to capturing more domain in Proc. of ECMFA, 2017, pp. 197–212. knowledge in the megamodel, for the benefit of omitting [24] O. Semeráth, C. Debreceni, Á. Horváth, and D. Varró, “Incremental backward change propagation of view models by logic solvers,” in unnecessary recovery steps (e.g., patch after commit in the MoDELS, 2016, pp. 306–316. running example) or addressing nondeterminism. [25] A. Demuth, M. Riedl-Ehrenleitner, R. E. Lopez-Herrejon, and A. Egyed, “Co-evolution of metamodels and models through consistent change R EFERENCES propagation,” JSS Journal, vol. 111, pp. 281–297, 2016. [1] M. Barbero, F. Jouault, and J. Bézivin, “Model Driven Management [26] A. Kusel, J. Etzlstorfer, E. Kapsammer, W. Retschitzegger, of Complex Systems: Implementing the Macroscope’s Vision,” in Proc. W. Schwinger, and J. Schönböck, “Consistent co-evolution of ECBS 2008. IEEE, 2008, pp. 277–286. models and transformations,” in MoDELS, 2015, pp. 116–125. [2] W. Kling, F. Jouault, D. Wagelaar, M. Brambilla, and J. Cabot, “Mo- [27] Z. Diskin, H. Gholizadeh, A. Wider, and K. Czarnecki, “A three- Script: A DSL for Querying and Manipulating Model Repositories,” in dimensional taxonomy for bidirectional model synchronization,” JSS Proc. SLE 2011, ser. LNCS, vol. 6940. Springer, 2012, pp. 180–200. Journal, vol. 111, pp. 298–322, 2016. [3] F. Basciani, J. D. Rocco, D. D. Ruscio, L. Iovino, and A. Pierantonio, [28] K. Czarnecki, J. N. Foster, Z. Hu, R. Lämmel, A. Schürr, and J. F. Ter- “Model Repositories: Will They Become Reality?” in Proc. Cloud- williger, “Bidirectional transformations: A cross-discipline perspective,” MDE@MoDELS 2015, ser. CEUR Workshop Procs, vol. 1563, 2016, in Proc. of ICMT, 2009, pp. 260–283. pp. 37–42. [29] D. D. Ruscio, L. Iovino, and A. Pierantonio, “Coupled evolution in [4] J. D. Rocco, D. D. Ruscio, L. Iovino, and A. Pierantonio, “Collaborative model-driven engineering,” IEEE Software, vol. 29, no. 6, pp. 78–84, Repositories in Model-Driven Engineering,” IEEE Software, vol. 32, 2012. no. 3, pp. 28–34, 2015.