-MDE projects contain different kinds of artifacts targets the web-based modeling platform MDEFORGE [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 foofrmarattifioanctsorancdontfhoermraelnecvea.nItnrethlaistiopnaspheirp,swine caapmtuergeamthoedetlyipnegs- 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 MDEFORGE. 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 semitency recovery; Megamodeling; Modeling platforms formal account on consistency recovery. Sec. V discusses the integration of the approach into the web-based modeling platI. INTRODUCTION form MDEFORGE. Sec. VI discusses related work. Sec. VII concludes the paper.
Research context: This research is concerned with model
management [
Research objective: We want to exercise an effective, declarative (model-based), and transparent (understandable) approach to organizing the artifacts in an MDE project (in a model repository or not) and the relationships between the artifacts. That is, a model-managed project has an associated megamodel so that a user (a developer within the project) can understand the structure of the project in megamodeling terms. Further, the project’s consistency with the megamodel is continuously monitored in the background of the interactive modeling platform so that any changes can be mapped to corrective, automated actions to be proposed to and confirmed by the user.
Research contribution: We address the research objective
by an emerging language design, definition, implementation,
and integration into a modeling platform. The language and its
implementation are referred to as MegaL/Forge because the
language is inspired by our previous work on linguistic
architecture, as a form of megamodeling, as realized by the MegaL
family of languages [
For brevity and focus on the key idea, we commit to a very basic running example here: there are two models m1 and m2 that conform to the same metamodel mm with the difference being referred to as delta and model management operations in place to express conformance of m1 and m2 to mm, comparison so that delta represents the difference between m1 and m2, and patching so that m2 is the result of patching m1 according to delta. This simple example involves enough semantical issues so that it suffices for an initial language design discussion. In our ongoing research, we also model more involved scenarios.
The running example operates within the EMF technological space. We need these types of artifacts; we use the concrete syntax of MegaL/Forge for expressing the type definitions: EmfModel // EMF based models (XMI representation) EmfMetamodel < EmfModel // Ecore models EmfCompareModel < EmfModel // Delta models
That is, we declare types EmfModel, EmfMetamodel, and EmfCompareModel; we organize these types in a hierarchy (‘<’). In the running example, we also need certain modelmanagement operations on the types just declared; again, we use the concrete syntax of MegaL/Forge for expressing signatures of relations and functions: conformsTo : EmfModel compare : EmfModel patch : EmfModel
EmfMetaModel
That is, we have access to conformance checking (conformsTo—a relation), model comparison (compare—a function), and delta application (patch—another function).
The following megamodel declares artifact ids for models m1 and m2, the shared metamodel mm to which both models are assumed to conform to, and the delta (difference) between the models. Conformance, comparison, and patch application are expressed by appropriate applications of relation conformsTo and functions compare and path. Thus: m1, m2 : EmfModel mm : EmfMetaModel conformsTo(m1, mm) conformsTo(m2, mm) delta : EmfCompareModel compare(m1, m2) 7! delta patch(m1, delta) 7! m2
Let us apply the MegaL/Forge megamodel to an actual project. That is, artifact identifiers in the megamodel are linked to actual filenames in the underlying model repository (in fact, a project). We may assume links as follows: m1 = ”Family1.xmi” m2 = ”Family2.xmi” mm = ”FamilyMM.ecore” delta = ”Delta.xmi”
These links assume relative file names (relative to a base URI for the project). We are concerned with two versions of a model for describing ‘families’ (family members, i.e., persons with names and some relationships or attributes), subject to a suitable metamodel, and a delta (a difference) between the two models at hand.
The modeling artefacts are subject to evolution [
1) Modify delta: We propagate this change by applying the patch function, thereby deriving a new version of m2 that is ‘in sync’ with m1 and delta. Thus, the following function application facilitates consistency recovery: patch(m1, delta) 7! m2
We should note that we do not want to apply the
compare function (beforehand or afterwards) because we consider
changed artifacts (such as delta here) as ‘authoritative’ [
An interactive user may disfavor this option on the grounds of domain knowledge such that (the older version of) delta readily captures aspects of m1 (and m2) and thus, it may not work well for a new version of m1.
3) Modify m2: We could consider applying the patch function, thereby deriving a new version of m2 that is ‘in sync’ with m1 and delta. This is clearly not a useful strategy, as it would overwrite the changes just made to m2. Instead, we need to compare m1 and m2 to compute a new delta. Thus, the following function application facilitates consistency recovery: compare(m1, m2) 7! delta
In fact, now that we changed delta, we may want to check that an application of the patch function would derive a model that is equal to the existing model m2. In that case, we would have recovered consistency in the project. Of course, this is exactly the semantics of comparison: it provides a delta for two models so that the second model can be derived from the first one by applying the delta as a patch.
We provide a language definition of MegaL/Forge. In particular, we define the concrete syntax by means of a grammar and the abstract syntax by means of a metamodel. We also briefly discuss the static semantics for well-formed megamodels. Finally, we define what may account for a dynamic semantics by means of a consistency notion—an MDE project (its artifacts) to be consistent with a megamodel.
The following grammar (in ANTLR notation) defines the concrete syntax of the MegaL/Forge constructs exercised in the present paper (Sec. II). megamodel : declaration+; declaration : type // Root entity type j subtype // Entity type as subtype j artifact // Entity j relation // Relation signature j function // Function signature j relatesTo // Relationship j mapsTo // Function application j link ; // Artifact binding 2.a) First compare, then patch: We apply the compare function to the (changed) model m1 and the (unchanged) model m2 to compute a new version of delta to be applied by type : ID ; // Base type subtype : ID ’<’ ID ; // Subtype < supertype artifact : ID (’,’ ID) ’:’ ID ; // Artifacts of a given type relation : ID ’:’ ID (’#’ ID) ; // Signature function : ID ’:’ ID (’#’ ID) ’ >’ ID; // Signature relatesTo : ID ’(’ ID (’,’ ID) ’)’ ; // Relationship mapsTo : ID ’(’ ID (’,’ ID) ’)’ ’j >’ ID; // Apply function link : ID ’=’ ’”’ LINK ’”’ ; // Bind artifact symbol to filename
The type and subtype forms of declaration facilitate the definition of a nominal classification hierarchy for artifacts. Actual artifacts are introduced by their name (an id); see declaration form artifact. The declaration forms relation and function facilitate signatures including names for arguments and results (the latter for functions only). There is a declaration form relatesTo for expressing relationships on artifacts. There is a declaration form mapsTo for expressing the specific relationship of function application. Finally, there is a special declaration form link for binding artifact symbols to files. Making the links part of the megamodel rather than designating a separate model for links can be compared to the use of annotations in OO programming rather than using XMLbased configuration.
MegaL/Forge is a very simple member in the MegaL
language family [
The metamodel defining the abstract syntax of the language is shown in Fig. 1. In particular, a megamodel specification consists of a set of Artifacts of different Types. Each function (relation) is defined by means of a Function (Relation) declaration and the corresponding MapsTo (RelatesTo) definition. Artifacts are arguments of Functions and Relations as shown by the constructors of the MapsTo and RelatesTo elements. The former consists of input and output elements, whereas the latter consists of the set of artifacts for which the specified relation holds. All the elements in the figure specialize a NamedElement class (not shown in the figure for brevity) consisting of the name attribute of type String.
C. Static Semantics = Well-formedness
A static semantics for well-formedness of
MegaL/Forgelike megamodels was defined as a definite clause program
in previous work [
a) Types, artifacts, relations, and function are declared before they are used. b) Each name can be declared once only (‘no overloading’ here of any kind). c) The arguments of relationships and function applications and results of function applications must be of the types as prescribed by the signatures of the corresponding relations and functions. d) Each artifact symbol is linked to some filename. (We do not consider incompletely bound megamodels here.) D. Dynamic Semantics = Consistency
Megamodels may have various dynamic semantics [
We take consistency to mean that all relationships on artifacts in the project, as expressed by the megamodel, i.e., applications of relations and functions, must hold, subject to suitable interpretations of the applied relations or functions. Details follow below.
interpretations of symbols used in megamodels systematically, we assume an environment E which is, in fact, a triple hEA; ER; EF i as follows:
EA maps artifact symbols, as they are used in the megamodel, to actual artifact representations in the sense of text, JSON, etc. In the MegaL/Forge notation (see Section II-B), we assume a mapping from artifact symbols to files. In the semi-formal model at hand, we assume a universe U for representations of artifacts. We use the type U in setting up interpretations for relation and function symbols; see below.
ER maps relation symbols to their interpretations; these are predicates of type U + ! Boolean. We use here U + for each predicate’s argument because, in this manner, a simple generic type suffices for all possible relations. The idea is, of course, that a suitable interpretation enforces a certain length (a certain number of parameters) and appropriate representation types (subtypes of U ) for the different parameters.
EF maps function symbols to their interpretations; these are functions of type U + ! U .
As an environment effectively represents what we think of as a ‘project’, we may also speak of consistency of a megamodel with an environment.
2) Consistency = Relational + Functional Consistency: We speak of relational consistency when the interpretation of all relation applications (‘relationships) in a given megamodel m for a given environment E returns true. We speak of functional consistency when the interpretation of all function applications in the megamodel m with the environment E returns true. Details of the assumed notion of interpretation follow.
A relation application r(a1; : : : ; an) with the relation symbol r and artifact symbols a1, . . . , an as arguments is interpreted by applying the interpretation of r to the interpretations of a1, . . . , an, as defined by the environment. Thus:
ER(r)(hEA(a1); : : : ; EA(an)i)
A function application f (a1; : : : ; an) 7! an+1 with the function symbol f , artifact symbols a1, . . . , an as arguments, and an artifact symbol an+1 for the result is interpreted by applying the interpretation of f to the interpretations of a1, . . . , an, as defined by the environment, and comparing the result with the interpretation of an 1 for equality. Thus:
EF (f )(hEA(a1); : : : ; EA(an)i) = EA(an+1)
For consistency to hold, the formulae as described above should evaluate to true for all relation and function applications.
IV. CONSISTENCY RECOVERY
In response to a change in a project, we perform a recovery analysis on the megamodel to determine the function applications (a recovery sequence) for recovering consistency, when applied to the artifacts in the project.
When consistency does not hold, then we may try to ‘overwrite’ artifacts according to function applications so that consistency is recovered. The major assumption is here that function applications, as they are part of the megamodel at hand, suffice for consistency recovery and a suitable order can be determined. In more detail, given a sequence of function applications fa1, . . . , fan from a given megamodel m, we call it a recovery sequence for a given environment E, if E is not consistent with m.
Apply fa1, . . . , fan in the given order to overwrite the artifact symbols for the results in the environment E. The updated environment E is now consistent with m.
see the two scenarios for changing m1 in Sec. II-C2. We may either delegate such nondeterminism to the interactive component or enhance megamodels and the analysis thereof to resolve nondeterminism automatically.
Let us now sketch a first attempt at the desired analysis; we defer proper treatment of nondeterminism to future work. We need helper functions as follows: in(m; a) returns all the function applications in the megamodel m with the artifact symbol a as an argument. out(fa) returns the artifact symbol for the result of the function application fa.
The main function for recovery analysis, ra, takes as arguments the megamodel m, an artifact symbol ac indicating the change, a sequence S of function applications, and it returns a sequence of function applications that may be a recovery sequence. We begin with an empty S and extend it into the result sequence, step by step.
It remains to define an analysis for megamodels to map changes to recovery sequences. For simplicity, we start from the assumption that changes are atomic in the sense that single artifacts are changed on a discrete timeline and consistency is to be recovered after each change. Thus, the analysis is essentially a mapping from a megamodel m and an artifact (‘++’ is list append.) The conditions control that we select symbol ac identifying the actual change to a sequence of function applications that can be applied to ac and results of function applications. previous applications without though any overwriting. The for
Let us discuss expected properties of the analysis. We do mulation is nondeterministic, as different function applications not want to map a change to a sequence that would change an could be picked in a step. artifact that was changed previously, as such ‘overwriting’ may For instance, for the megamodel of Sec. II and ac = m1, be semantically debatable and it may also lead to divergence. starting from S = ;, the analysis returns a sequence starting As a special case, we do not want to apply any function with a comparison, followed by a patch as follows: application twice. For instance, this could happen, in the compare(m1, m2) 7! delta running example, if we were responding to model changes patch(m1, delta) 7! m2 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 nondeterminchanges for which different recovery sequences are possible; ism is deferred to future work. ra(m; ac; S) = 8 ra(m; ac; S++hfai); with fa drawn from m such that >>>> fa 62 S; and >>< fa 2 in(m; ac) [ Sfa02S in(m; out(fa0)); and > out(fa) 6= ac; and >>>> out(fa) 6= out(fa0) for all fa0 2 S: :> S; otherwise (if there is no such fa)
This section presents the implementation of the presented
consistency recovery approach, which has been integrated in
the MDEFORGE platform [
The consistency recovery mechanism presented in the previous section has been integrated in MDEFORGE by essentially extending the existing project management facilities. In particular, the Java packages ProjectMonitoring and ConsistencyManagement shown in Fig. 2 contain the new classes and interfaces that have been added in the MDEFORGE implementation. The existing package CoreService has been extended to work with such new packages.
The ProjectMonitoring package implements listeners that execute the consistency recovery manager when artifacts or projects are changed. In such cases, ApplicationEvents are created as shown in the listing below and used by ArtifactChangedListener and ProjectChangedListener to interact with the ConsistencyRecoveryManager. public void update(T artifact) f ... eventPublisher.publishEvent(new ArtifactChangedEvent(artifact, ”
UPDATE”)); artifactRepository.save(artifact);
The ConsistencyManagement package implements the presented consistency recovery concepts. For each symbolic function or relation name a corresponding IOperationApplier implementation is available. For instance, the functions compare and patch discussed in Sec. II-B have the corresponding 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 apply method of the class ComparisonApplier executes the comparison mechanism already available in MDEFORGE (that in turn is based on EMFCompare1) as shown in the following listing showing a fragment of the apply method of the class
public Object apply(Object[] inputs) f if (inputs.length != 2)
throw new Exception();
Artifact left = inputs[0];
Artifact right = inputs[
The links between symbolic operation names and the corresponding appliers are specified in the operationMapper HashMap of the ConsistencyRecoveryManager class. The consistency check between a project and the corresponding
megamodel is performed by the method checkConsistency shown below: public boolean checkConsistency(Project project, Megamodel megamodel) f for (Artifact relatesTo : m.models) f
List <ArtifactChangedEvent> changes= checkChanges(project); if (changes.size()==0) return true; g for (RelatesTo relatesTo : m.relatesTos) f
IOperationApplier opApplier = operationMapper.get(relatesTo.
getType()); boolean result = (boolean) opApplier.apply(relatesTo.arguments); if (!result) return false; g return true; g g g
The method consistencyRecovery implements the recovery mechanism by exploiting the getFunctionsToRecoverConsistency method shown in the listing below. It is responsible of identifying the functions to be applied and their execution order for recovering the consistency between the changed project and the corresponding megamodel. public List<MapsTo> getFunctionsToRecoverConsistency(Project project,
List<MapsTo> result = new ArrayList<MapsTo>(); List <ArtifactChangedEvent> changes=checkChanges(project); for (MapsTo function : m.functions) f
if (function.inputs.contains(changes)) result.add(function); g return result; A fragment of the consistencyRecovery method is as follows: public void consistencyRecovery(Project project, Megamodel megamodel) f checkConsistency(project, megamodel); List<MapsTo> toApply = getFunctionsToRecoverConsistency(project, megamodel); for (MapsTo function : toApply) f
IOperationApplier opApplier = operationMapper.get(function.
getType()); opApplier.apply(m.inputs);
Consistency recovery can generate new artifacts that might overwrite existing ones. In such cases, the user will be notified and will be asked for confirmation, as illustrated with the popup in Fig. 3. The user will also be notified when consistency recovery fails. We are also working on presenting options to the user.
In general, a few model management platforms exist, such
as MMINT [
In requirements engineering, the consistency between
requirement artifacts needs to be maintained. In [
In [
Bidirectional transformations pose a need for consistency
checking and change propagation. Demuth et al. [
VII. CONCLUDING REMARKS
In this paper, we have described an approach towards
consistency recovery in MDE projects such that megamodels are
facilitated for expressing consistency and providing guidance
for recovery thereof in an interactive setup. We are working on
the following improvements. Firstly, we look at more complex
scenarios with richer dependencies between the involved
artifacts so that the issue of nondeterminism (Sec. IV-B) is (needs
to be) properly addressed. For instance, we study examples of
co-evolution [