=Paper=
{{Paper
|id=Vol-2019/exe_6
|storemode=property
|title=Consistency Recovery in Interactive Modeling
|pdfUrl=https://ceur-ws.org/Vol-2019/exe_6.pdf
|volume=Vol-2019
|authors=Juri Di Rocco,Davide Di Ruscio,Marcel Heinz,Ludovico Iovino,Ralf Lämmel,Alfonso Pierantonio
|dblpUrl=https://dblp.org/rec/conf/models/RoccoRHILP17
}}
==Consistency Recovery in Interactive Modeling==
https://ceur-ws.org/Vol-2019/exe_6.pdf
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.