A Language-oriented Approach for the Maintenance of
Megamodel-based Complex Systems
El Hadji Bassirou Toure
1,2,3
, Ibrahima Fall
1,2,3
, Alassane Bah
1,2,3
, Mamadou S. Camara
1,2,3
,
Mandicou Ba
1,2,3
and Ahmad Fall
1,2
1
´
Ecole Sup
´
erieure Polytechnique, ESP, Dakar, Senegal
2
Universit
´
e Cheikh Anta Diop de Dakar, UCAD University, Dakar, Senegal
3
Institut de Recherche pour le D
´
eveloppement, IRD Institute, Dakar, Senegal
Keywords:
Software Configuration Management, MDE, Megamodeling, DSML, Design By Contract.
Abstract:
Model Driven Engineering (MDE) provides the concept of a runtime megamodel to represent the dynamic
structure of a given system, to which it is causally connected. A system changes at runtime therefore implies
frequent and dynamic changes of its related megamodel. In a previous work we have proposed to automate
change management through a runtime megamodel evolution management approach. In such an approach, a
megamodel manipulation, a kind of programming in-the-large activity, is considered as a mega-program which
is modified throughout Global Operation Models (GOMs). Then we proposed a safe execution of GOMs as
the solution for megamodel consistency preserving during evolution. In this work, we propose LAMEME, a
domain-specific language for the management and the evolution of megamodels, and its axiomatic semantics.
LAMEME gives the possibility to express an evolving megamodel as a mega-program and therefore defines a
framework that supports our previously proposed approach.
1 INTRODUCTION
Configuration management is the discipline of man-
aging change in large, complex systems. Its goal is to
manage and control the numerous maintenance activi-
ties (corrections, extensions, and adaptations) that are
applied to a system over its lifetime. Software con-
figuration management (SCM) is configuration man-
agement applied to software systems. In the early
80s SCM focused in programming-in-the-large (ver-
sioning, rebuilding, composition) (Estublier, 2000).
In a seminal paper entitled Programming-in-the-large
vs. Programming-in-the-small (DeRemer and Kron.,
1976), De Remer and Kron claimed that program-
ming languages are well suited to describing algo-
rithms and data structures, but not the structure of
complex versioned software products. According to
Favre, programming-in-the-large focuses on concepts
related to the management of large software systems,
taking into account four aspects: architecture, manu-
facture, evolution and variation (Favre, 1997).
A large software system is a system consisting of
a large number of components and many dependen-
cies, being dynamically developed (Murer and Bon-
ati., 2010). Such systems are inherently hard to man-
age largely because of their complexity. Indeed the
complexity of such systems has exploded from iso-
lated computers to global systems. It is for this reason
that such systems are also called ”complex systems”.
To address the problems related to complex sys-
tems, De Rosnay advocates the use of a macroscope
which can be considered as the symbol of a new
way of observing, understanding, controlling and act-
ing on complex systems (Rosnay, 1975). According
to Barbero, MDE (Schmidt, 2006), may now pro-
vide the right level of abstraction to move the macro-
scope from its status of a symbolic instrument to a
set of concrete and practical tools, ready to be used
by engineers when they collectively work on complex
computer-based systems (Barbero and al., 2008). The
idea promoted by MDE is to use models at different
levels of abstraction for developing systems, thereby
raising the level of abstraction in program specifica-
tion. An increase of automation in program develop-
ment is reached by using executable model transfor-
mations (operations). Higher-level models are trans-
formed into lower level models until the model can
be made executable using either code generation or
model interpretation.
Toure, E., Fall, I., Bah, A., Camara, M., Ba, M. and Fall, A.
A Language-oriented Approach for the Maintenance of Megamodel-based Complex Systems.
DOI: 10.5220/0007397503370344
In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 337-344
ISBN: 978-989-758-358-2
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
337
Such concrete and practical tools, to which Bar-
bero refers to, resulted in a kind of a special MDE
model called a megamodel which is intended to pro-
vide a macroscopic representation of a complex sys-
tem (Bezivin and al., 2004), (Bezivin and al., 2005b),
(Vignaga A., 2009).
Subsequently a megamodel has to hide fine-
grained details that obscure understanding and focus
on the big picture”, i.e. system structure, interactions
between models, assignment of models as parameters
or results for model transformations, etc. Indeed, the
notions of megamodeling (Bezivin and al., 2004) and
modeling-in-the-large (Bezivin and al., 2005b) are in-
troduced by analogy to respectively megaprogram-
ming (Boehm and Scherlis., 1992) and programming-
in-the-large (DeRemer and Kron., 1976) to address
the development of large-scale systems from a mod-
eling perspective called Global Model Management
(Vignaga A., 2009).
Thus the task of manipulating the megamodel
is considered as a programming-in-the-large one
(DeRemer and Kron., 1976), where the megamodel
acts as the mega-program which is manipulated
through mega-modules represented by GOMs (Toure
and al., 2018). Such megamodel manipulations co-
incide roughly with the needs of maintenance activi-
ties. Indeed nearly all systems particularly the com-
plex ones will need maintenance over their lifetime
because something in the system needs fixing (correc-
tive maintenance), or external changes force a change
to the system (adaptive maintenance), or something
can be improved (perfective maintenance). However,
whatever the type of maintenance involved, any meg-
amodel change is done through the execution of GOM
instances.
Such a situation leads mainly to two problems.
1. The problem of preserving megamodel consis-
tency after changes, amounts to ensuring safe ex-
ecutions of GOMs by defining a formal semantic
for each GOM instance. This problem has been
addressed in previous works (Toure and al., 2018).
2. Considering the megamodel as a mega-program
raises the issue of the language in which such a
mega-program is written. The goal of this pa-
per is to propose a domain-specific LAnguage for
the Management and the Evolution of MEgamod-
els (LAMEME) and its axiomatic semantics. The
design of LAMEME will enable us to check the
correctness of GOM instances and thus to main-
tain the megamodel quality and/or integrity after
changes.
The remainder of the paper is organized as fol-
lows. We first, in section II, present the megamodel
structure and behavior. In section III, we present the
syntax of LAMEME and describe its semantics (oper-
ational and axiomatic semantics). Section IV presents
some related works and section V concludes the pa-
per.
2 MEGAMODELLING
2.1 A Megamodel: A Kind of SCM
Typically SCM consist of two parts which collabo-
rate in a harmonious way (Estublier, 2000). The first
part is about the management of a repository of com-
ponents. Indeed there is a need for storing the dif-
ferent components of a software product and all their
versions safely. The second part of SCM concerns
the process control and support. In fact, traditionally,
change control is an integral part of an SCM product.
Otherwise, on the one hand, megamodels have of-
ten been used as a register for software architecture
components and their interconnections (Bezivin and
al., 2004), (Kling and al., 2011). On the other hand,
megamodels have also to take under consideration
the dynamic aspect of a system i.e the way a system
change (Seibel A., 2009), (Favre and NGuyen., 2005).
Thus in a MDE context, a megamodel plays the role
of a SCM. Therefore a megamodel results from a
Repository Model (RM) which represents its static
aspect and an Execution Environment Model (EE) to
represent the operations performed in the megamodel.
2.2 The Repository Model
The RM is the place wherein Component Models
(CMs) and their relations known as Global Links
(GLs), and GOMs are represented, stored and manip-
ulated. A component is any reusable software unit. It
can be as simple as a class diagram or as complex as
a whole system. We use models of such components
in order to manage all of them in a homogeneous way
without considering their nature and their internal de-
tails.
A GL between two CMs may be viewed as sum-
marizing a set of interactions between that two CMs
which are said to be dependent each other (Bezivin
and al., 2005b). Among others GLs we can distin-
guish the conformsTo relation between a CM and its
reference model, or the realizedBy relation between
a CM and its interface, etc. GLs are very usefull for
changes propagation management because if a CM is
modified then all CMs which depend on it are likely
to be targeted by this change.
A CM always represents a realization of another
CM which represents its interface. On the one hand a
MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development
338
CM can be realized throughout more than one CM,
each of them conforming to a specific metamodel.
Such realizations of a given component are called
variants of that component. On the other hand, each
time a CM is changed a new revision of that CM is
created. A variant (resp. revision) of a given CM is
called a logical (resp. historical) version of that CM.
At the same time, for a given CM, several variants
may exist but only one revision of that CM is stored in
the RM. Typically it is the last created. A variant may
be derived in several successive revisions. The exis-
tence of different variants can be independent from
the notion of time”. In the RM, variants correspond
to significant changes such as different metamodels,
whereas revisions result from addition of new func-
tionality, error corrections, refinements, etc.
2.3 Execution Environment
The Execution Environment controls the dynamic as-
pect of the megamodel by enabling GOMs to be
loaded from the RM and to be performed. Indeed a
GOM can only be applied to CMs already contained
in the RM, and its results are new CMs which are au-
tomatically added in or old CMs may be removed from
the RM. However the details of CMs are abstracted
away and the implementation details of GOMs con-
sidered not relevant. For example, we can use a GOM
such as merge to compose two CMs. In this case, we
are only interested in the impacts of that operation in
the megamodel and, potentially, to its effects in other
CMs but not on how such a merge GOM is defined.
So, focus is made in the product and not in the pro-
cess of GOMs in the megamodel.
The goal of a SCM is the control of the evolution
of complex systems. A megamodel being a SCM is
modified throughout the execution of GOM instances.
So we use a kind of a complex model, namely a con-
figuration model to describe an instance of a GOM,
the list of CMs as parameters and the CM as the re-
sult of such a GOM. The parameters of a configura-
tion model are called source CMs and the result is
called ”derived CM”.
A configuration model C is defined by the tuple :
C = < M
e
, Op, M
s
>, where :
M
e
is the list of source CMs C;
Op is an instance of a GOM (e.g : merge, match);
M
s
is the derived CM of C.
An instance of a given configuration model can be de-
fined and will take as input a revision of each CM in
the list M
e
, a specific instance of the GOM Op and
will give as output a new variant of the CMs in the list
M
s
. For example, a configuration model for a GOM
instance which have to merge two CMs representing
respectively the data model of two components s and
t, and a mapping between that two CMs. Such an op-
eration produces a CM representing a merge of s and
t. Such a configuration model is formally decribed
below :
< C = {ms
d
, map
d
, mt
d
}, merge
s
t
, merge
d
> where
ms
d
input(C) m revList(s model) : m == ms
d
.
mt
d
input(C) m revList(t model) : m == mt
d
.
map
d
input(C) m revList(map
s
t
) : m == map
s
t
.
merge
d
output (C).
map
d
is a mapping between ms
d
and mt
d
. Such a
mapping is a morphism that identifies combinations
of objects in the input models that are equal.
merge
s
t
is a generic instance (a function definition)
of the merge GOM. Thus an application of such a
function is done by defining specific instances of the
merge GOM.
3 A LANGUAGE-ORIENTED
MEGAMODEL MANAGEMENT
3.1 Overview
In this section, we present a textual domain-specific
modeling language (DSML), called LAMEME. It is
about a programming language or an executable spec-
ification language that offers, through appropriate no-
tations and abstractions, expressive power focused on,
and usually restricted to, the particular problems of
megamodel evolution and maintenance. LAMEME
can be considered as an interpreted functional lan-
guage because GOM instances (functions) and input
CMs (parameters) passing are the primary means of
accomplishing the megamodel changes.
Because of space constraints the abstract syntax
of LAMEME (the metamodel of the proposed meg-
amodel), representing its model is not presented in
this paper (Toure and al., 2017). Otherwise the
concrete syntax of LAMEME is highlighted through
some simple examples. So, this paper mainly focus
on the semantics of LAMEME which is more relevant
for the proposed approach.
Indeed to define the semantics of LAMEME, we
use Hoare’s axiomatic semantics or in its modern
form, the Design By Contract method (DBC) (Meyer,
1992). The principal idea behind such an approach is
that a GOM instance being executed and the EE have
a contract with each other. The EE must guaran-
tee certain conditions (preconditions) before calling
an operation defined by the specific GOM instance,
and in return the specific GOM intance guarantees
A Language-oriented Approach for the Maintenance of Megamodel-based Complex Systems
339
certain properties (postconditions) that will hold af-
ter the call. The use of DBC against Hoare-Logic is
that it makes these contracts executable.
In LAMEME, the contracts also called specifica-
tions are defined using annotations and are translated
into executable code by the interpreter. Thus, any vi-
olation of the specification that occurs while a GOM
instance is executed can be detected immediately. A
specification defines the oracle for a particular GOM
execution. An oracle is a mechanism for determining
behavioral correctness of GOM execution by exam-
ining its output. Indeed a GOM execution requires
an oracle to determine whether its output is correct or
not. Often such an oracle is a human, but the pro-
cess can be time-consuming, tedious and error-prone.
Whereas if the specification is mathematical (or log-
ical), such as in LAMEME through Hoare logic, it is
possible to derive a software oracle from it.
Such a software oracle is called a Runtime Asser-
tion Checker (RAC) (Cheon and Leavens., 2002), that
we have used in LAMEME in order to determine if a
given GOM execution is safe for the megamodel.
3.2 Syntax
3.2.1 Listings
1 context com.mega.test {
2 use metamodel com.mega.init.KM3
3 def metamodel Kermeta { ... }
4 def megamodel megaWork {
5 def interface IGeneral { ... }
6 def interface IKM3 { ... }
7 def component model KM3Model:KM3 implements IKM3 {
8 properties (
9 service data,
10 type descriptive ,
11 level terminal ,
12 )
13 }
Listing 1: CMs definition.
1 def component model KermetaModel:Kermeta implements
IGeneral{
2 properties (
3 service data,
4 type descriptive ” ,
5 level terminal ,
6 language ”KermetaLanguage”,
7 otherProperties ”An executable model”
8 )
9 }
10 def component model UMLModel : com.mega.init.UML2
implements IGeneral {
11 properties (
12 service data,
13 type descriptive ,
14 level terminal ,
15 language ”UML2.3”,
16 otherProperties ”An executable model”
17 )
18 }
Listing 2: CM definition: variant.
1 def component model KM3ExtModel:KM3 extends KM3Model
implements IKM3 {
2 properties (
3 author ”Max Payne”,
4 language ”KM3Language”
5 )
6 }
Listing 3: CM definition : revision
1 def configuration model matching KM3 Kermeta::Match {
2 ...
3 @input from: repository KM3Model
4 @input from: repository KermetaModel
5 @output KM3 Kermeta MatchModel
6 }
Listing 4: Configuration model definition.
1 megaprogram matchingModel {
2 let KM3 m1
3 let Kermeta m2
4 m2 = exec(model::query(with (name = ”KermetaModel”) and (
author = ”John Doe”) and Version > 0))
5 m1 = exec(model::queryLast(with (ReferenceModel = ”KM3”)
and (name=”KM3ExtendedModel”)))
6 let configuration matchGOM 23122018 = exec(configuration
::load(with name = ”matching KM3 Kermeta”))
7 let any m3 = call matchGOM 23122018(m1, m2)
8 m3 = exec(model::save(with name =”map model m3”))
9 }
10 matchingModel.execute()
Listing 5: Megaprogram definition.
3.2.2 Listing Descriptions
The Listing 1. starts with the definition of an execu-
tion context (Line 1) that can be simply considered as
a namespace. Then, the KM3 metamodel is imported
from the execution context com.mega.init (Line 2).
After the elaboration phase (imports and metamod-
els definition), the initialization phase starts with the
definition of a megamodel instance megaWork (Line
6). Before the definition of a CM you must first de-
termine the interface to be realized by that CM. This
is what has been done at Line 7 - 10. The Line 13
states that the KM3Model conforms to the metamodel
KM3 and realizes the IKM3 interface. The first step
in creating any composite system is to locate the CMs
that provide data or functionality that is to be placed
in the new system. For example, each CM should be
MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development
340
named, typed, and must specify what information it
represents (a data element, a process element, etc).
Such characteristics are represented through a set of
couples < attribute,value > in the properties section
(Line 8 - 11).
The Listing 2. shows the creation of two CMs
which are variants each other. Indeed the CMs Ker-
metaModel and UMLModel implement both the same
interface IGeneral but, the fact that the two CMs con-
form to two distinct metamodels results they are vari-
ants one another.
The Listing 3. shows the creation of a new revi-
sion (KM3ExtModel) for the CM KM3. By contrast
with variants definition, two revisions have to con-
form to the same metamodel.
The Listing 4. highlights the definition of a
configuration model (matching KM3 Kermeta) rep-
resenting a generic instance of the Match GOM.
Such a generic instance has as sources the
KM3Model and the KermetaModel and as derived the
KM3 Kermeta MatchModel. It is possible to instan-
tiate the generic instance matching KM3 Kermeta to
produce a specific instance of the Match GOM. Such
a specific instance will take as input a revision of the
KM3Model and a revision of the KermetaModel and
will produce as output a mapping between that two
CMs.
The Listing 5. starts the construction phase
by defining the matchingModel megaprogram which
starts with the declaration of two CMs m1 and m2
which conform respectively to KM3 and Kermeta
metamodels. To m2 is assigned the result of the
search of any revision of the KermetaModel (there
existst only one). The result of the search of the
last created revision (KM3ExtendedModel) of the
KM3Model is assigned to m1. A specific instance
matchGOM 23122018 of matching KM3 Kermeta is
created (line 6). A generic model m3 is created
to which is assigned the result of the application of
matchGOM 23122018 to m1 and m2 (line 7). Finally
m3 is saved in the RM as map model m3 which rep-
resents a mapping between KM3Model and Kermeta-
Model (line 8). Line 10 corresponds to the matching-
Model execution launch.
3.3 Semantics
Describing syntax is easier than describing semantics,
partly because a concise and universally accepted no-
tation is available for syntax description, but none has
yet been developed for semantics.
Operational semantics are easy to define and un-
derstand, similarly to implementing an interpreter
(Figure. 1). They require little formal training, scale
up well, and, being executable, can be tested. Thus,
operational semantics are typically used as trusted ref-
erence models for the defined languages.
Figure 1: LAMEME’s Operational Semantic.
Despite these advantages, they are rarely used directly
for program verification, because proofs tend to be
low-level, as they work directly with the correspond-
ing transition system. Moreover the real problem with
an operational semantics is the interpreter itself: it is
represented as an algorithm. If the algorithm is sim-
ple and written in an elegant notation, the interpreter
can give insight into the language.
Otherwise, Hoare or dynamic logics allow higher
level reasoning at the cost of (re)defining the lan-
guage as a set of abstract proof rules. Hoare logic,
often identified with axiomatic semantics, was pro-
posed more than forty years ago (Hoare, 1969) as a
rigorous means to reason about program correctness.
In order to define an axiomatic semantic for
LAMEME programs, GOMs in this case, we use
a framework similar to JML (Java Modeling Lan-
guage), (Leavens and al., 1998) which is a powerful
DBC tool for Java. As such, it allows one to spec-
ify both the syntactic interface of Java code and its
behavior.
GOMs specifications, as in JML, are written in
special annotation comments, which start with an at-
sign (@). We use a requires clause to specify the
GOM’s preconditions (a requires clause consists of
an assign clause to specify the GOM’s parameters,
an initially clause to specify the properties of pa-
rameters, etc.) and an ensures clause to specify the
GOM’s postcondition. A contract is typically writ-
ten by specifying a GOM’s pre and postconditions. A
GOM’s precondition says what must be true about in-
put and output CMs to call it. A GOM’s postcondition
says what must be true about input and output CMs
when it terminates. Unlike simple comments, formal
specifications in LAMEME are machine checkable,
and so can help with debugging. That is, checking the
specification can help isolate errors before they prop-
A Language-oriented Approach for the Maintenance of Megamodel-based Complex Systems
341
agate too far.
If an assertion in a GOM specification does not
hold when the execution control reaches it, one knows
that something is wrong with either the GOM defini-
tion (execution) or the GOM specification Figure. 2.
Generally, stating what one believes to be true about
a program as assertions and checking that program
using assertions at runtime is an effective means of
increasing the quality of programs.
Figure 2: Decision Procedures for Oracles.
For such purposes, a runtime assertion checker is used
as the decision procedure for oracles which are based
on the formal specifications. The way of implement-
ing oracles is to compare the execution output of an
instance of a GOM to some pre-calculated, presum-
ably correct, output defined using Hoare’s inference
rules. It’s about building expected outputs and com-
paring them to the execution outputs, the specified be-
havior of the GOM under execution is monitored to
decide whether an execution is safe or not. Execu-
tion oracles catch assertion violation exceptions from
the execution of an instance of a GOM to decide if
the GOM failed to meet its specifications, and hence
that its execution is unsafe for the megamodel. An
assertion violation will occur, and a specified excep-
tion will be thrown to indicate the detail information
when some checking failure of specifications is en-
countered. If an execution of an instance of a GOM
satisfies its formal specifications, no such exceptions
will be thrown, and that particular execution will be
considered as a safe one.
3.4 Illustrative Example
In this illustrative example we consider the LAMEME
program below defined in Listing 6. In this examle
we consider that s represents the complex system rep-
resented by the runtime megamodel to which will
be plugged a component t. Such an integration of
t into s will be done according to their data dimen-
sion. For that, we suppose that the data model of s is
represented by the CM s datamodel represented us-
ing the UML metamodel. We also consider that the
data model of t is represented by the CM t datamodel
which also conforms to the UML metamodel. The fu-
sion of s datamodel and t datamodel will produce
the s merge t CM which will be the new data model
of s and subsequently s merge t will represent the
data of the megamodel.
1 context com.mega.example {
2 ...
3 def configuration model Merge t s :: Merge {
4 / @ ASSIGN m1 as input IMPLIES m1 as s datamodel>
revision
5 @ ASSIGN m2 as input IMPLIES m2 as t datamodel>
revision
6 @ ASSIGN m as input IMPLIES m as s match t>revision
7 @ INITIALLY (service, level , language, otherProperties )
IN m1
8 @ INITIALLY (service, level , language, otherProperties )
IN m2
9 @ RESULTS m3 as output IMPLIES m3 as s merge t>
revision
10 @ REQUIRES (P, (m1.service EQUALS m2.service) AND
11 (m1.level EQUALS m2.level) AND (m1.language EQUALS
m2.language) AND
12 (m as mapping) AND (m EQUALS m1 MATCH m2))
13 @ ENSURES (Q, (m3.service EQUALS m1.service) AND
14 (m3.level EQUALS m1.level) AND (m3.language EQUALS
m1.language))/
15 @input from: repository t datamodel
16 @input from: repository s datamodel
17 @output s merge t
18 }
19 megaprogram exampleMerge{
20 let UML2 t m1 = null
21 let List <UML2> results = exec(interface :: query(
realisation , with name = ”IDataModel s”))
22 while( results != null ){
23 let any s m1 = exec(model::queryLast(with
ReferenceModel = ”UML2”
24 and RealizedInterface = ”IdataModel s) )
25 if (exec(model:: exists (with (name = ”s datamodel”) and
Version = 3.X” )) ){
26 t m1 = exec(model::new( realisation , with
ReferenceModel = ”UML2”
27 and RealizedInterface = ”IDataModel t” and Version
= ”1”) )
28 }
29 let configuration mergeInstance = exec( configuration ::
load(with name = ”Merge t s”))
30 let UML2 merge st = call mergeInstance(s m1, t m1)
31 merge st = exec(model::save(with name =”s merge t”))
32 }
33 }
34 exampleMerge.execute()
35 }
36 }
Listing 6: Illustrative example.
In Listing 6. we define a configuration model
Merge t s which is a generic GOM of type Merge that
MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development
342
takes as input a s datamodel and a t datamodel from
the RM and which gives as output the CM s merge t.
The megaprogram exampleMerge starts with the
declaration of a CM t m1 of type UML2. Then a list
of CMs which are realizations of the interface IData-
Model s is assigned to the variable results. A generic
CM s m1 is declared to which is assigned the result
of the search of the last revision of the realizations
of the IDataModel s and which is conform to UML2.
If a CM representing the s datamodel exists in the
RM and if such a CM represents the third alternative
without considering which revision it represents then
the t m1 CM will be assigned the only one revision
which represents the realization of the IDataModel t
and which conforms to the UML2 metamodel.
The execution of the exampleMerge megapro-
gram using the RAC shows that the Merge instance
Merge t s does not meet its specifications because
any generic instance of Merge GOM should have to
take three parameters : the two CMs to be merged
and a third CM which is a morphism representing the
links between the CMs to be merged. In the definition
of the specific Merge instance mergeInstance, there is
no CM representing the mapping of the two CMs to
be merged. The program throws an exception. We
say that the execution of the generic Merge instance
Merge t s is not a safe execution for the megamodel
because such an execution is likely to introduce in-
consistencies in the megamodel. The RAC causes the
program abort Figure. 3.
Figure 3: An unsafe execution of the generic Merge in-
stance : Merge t s.
To fix it, we have to redefine the configuration
model Merge t s by using a third parameter which
represents the mapping between the two input CMs.
Such a model mapping is similar to that defined in
Listing 4.
Indeed the third parameter of the generic instance
Merge t s was obtained as the result of the generic
Match instance. In other words, the third parameter
of the generic instance Merge t s should have to be a
specific instance of the generic instance Match t s.
Listing 7 gives the definition of the generic Merge
instance with three parameters.
1 def configuration model Merge t s :: Merge {
2 / ... /
3 @input from: repository t datamodel
4 @input from: repository s datamodel
5 @input from: repository s match t
6 @output s merge t
7 }
Listing 7: The generic Merge instance with the
mapping parameter.
In Listing 8, the exampleMerge megaprogram is
re-executed but using the generic instance Merge t s
with three parameters. Indeed the Merge t s is
redefined by adding a third parameter representing
a mapping of the two input models which uncovers
how the two source models correspond to each
other. The new Merge instance Merge t s does
not produce no longer any inconsistency in the
megamodel, so such an execution is safe for the
megamodel as illustrated in Figure. 4.
1 megaprogram exampleMerge{
2 ...
3 let configuration matchInstance = exec( configuration ::
load(with name = ”Match t s”) )
4 let any merge st = call matchInstance (s m1, t m1)
5 let configuration mergeInstance = exec( configuration ::
load(with name = ”Merge t s”))
6 let UML2 merge model ts = call mergeInstance(s m1, t m1
, merge st)
7 merge model ts = exec(model::save(with name =”s merge t
))
8 }
9 }
10 exampleMerge.execute()
11 }
Listing 8: The sound exampleMerge megaprogram.
Figure 4: A safe execution of the Merge instance Merge t s.
4 RELATED WORK
In this section we provide a short overview of the lit-
erature related to the tools and/or languages which are
developed in the field of Global Model Management
(GMM).
MoDisco (Bruneliere and al., 2014), offers a
generic and extensible model-driven reverse engi-
neering (MDRE) framework intended to facilitate the
A Language-oriented Approach for the Maintenance of Megamodel-based Complex Systems
343
elaboration of MDRE solutions actually deployable
within industrial scenarios. The provided description
includes its overall underlying approach, architecture,
available components and the detail of Model Discov-
ery and Model Understanding.
Neo4EMF (Benelallam and al., 2014), is a
tool that can improve the applicability of MDE
to large-scale scenarios, where on-demand loading,
high-performance access and enterprise-level data-
management features are needed.
MoScript (Kling and al., 2011), is a solution for
Global Model Management (GMM), based on the no-
tion of a Megamodel. The MoScript language is an
OCL-based scripting language for model-based task,
based on the metadata contained in a Megamodel and
allows for querying a Megamodel.
The AM3 tool (Bezivin and al., 2005a), is an envi-
ronment for dealing with models or metamodels, to-
gether with tools, services and other global entities,
when considered as a whole. For each platform, au-
thors suppose that there is an associated megamodel
defining the metadata associated to this platform.
5 CONCLUSION AND FUTURE
WORK
In this work, we propose LAMEME, a domain-
specific language for the management and the evo-
lution of megamodels, and its axiomatic semantics.
Our proposal seems at the moment staying at a too
high level of abstraction. A difficulty with metamod-
eling and even more with megamodeling approaches
resides in the high level of abstraction they involve.
Thus, as future works we are looking at using our
solution of complex system maintenance in a real
case study in order to fully validated the proposed ap-
proach.
ACKNOWLEDGEMENTS
The research in this paper is supported by the Centre
dExcellence Africain en Mathmatiques, Informatique
et TIC (CEA-MITIC).
REFERENCES
Barbero and al. (2008). Model driven management of com-
plex systems: Implementing the macroscope’s vision.
In Engineering of Computer Based Systems. IEEE.
Benelallam, A. and al. (2014). Neo4emf, a scalable persis-
tence layer for emf models. In European Conference
on Modelling Foundations and Applications. Springer.
Bezivin, J. and al. (2004). On the need for megamodels.
In 19th Conference on Object Oriented Programming,
Systems, Languages, and Applications. ACM.
Bezivin, J. and al. (2005a). An introduction to the at-
las model management architecture. In Rapport de
recherche 5.
Bezivin, J. and al. (2005b). Modeling in the large and mod-
eling in the small. In European MDA Workshops:
Foundations and Applications (MDAFA’05). Springer.
Boehm, B. W. and Scherlis., W. L. (1992). Megaprogram-
ming. In DARPA Software Technology Conference.
Bruneliere, H. and al. (2014). Modisco: A model driven
reverse engineering framework. In Information and
Software Technology.
Cheon, Y. and Leavens., G. T. (2002). A runtime assertion
checker for the java modeling language (jml).
DeRemer, F. and Kron., H. H. (1976). Programming-in-
the-large versus programming-in-the-small. In Trans-
actions on Software Engineering. IEEE.
Estublier, J. (2000). Software configuration management:
a roadmap. In Conference on the Future of Software
Engineering. ACM.
Favre, J.-M. (1997). Understanding-in-the-large. In In-
ternational Workshop on Program Comprehension.
IEEE.
Favre, J.-M. and NGuyen., T. (2005). Towards a megamodel
to model software evolution through transformations.
In Electronic Notes in Theoretical Computer Science.
Hoare, C. (1969). An axiomatic basis for computer pro-
gramming. In Communications of the ACM. ACM.
Kling, W. and al. (2011). Moscript: A dsl for query-
ing and manipulating model repositories. In Inter-
national Conference on Software Language Engineer-
ing. Springer.
Leavens, G. T. and al. (1998). Jml: a java modeling lan-
guage. In OOPSLA.
Meyer, B. (1992). Applying design by contract.
Murer, S. and Bonati., B. (2010). Managed evolution: a
strategy for very large information systems. In Science
and Business Media. Springer.
Rosnay, J. (1975). Le macroscope. vers une vision globale.
In Points Civilisation. Editions du Seuil.
Schmidt, D. C. (2006). Model-driven engineering. In Com-
puter IEEE Society. IEEE.
Seibel A., Neumann S., G. H. (2009). Dynamic hierarchical
mega models: Comprehensive traceability and its effi-
cient maintenance. In Software and System Modeling.
Toure, E. and al. (2017). Consistency preserving for evolv-
ing megamodels through axiomatic semantics. In In-
telligent Systems and Computer Vision. IEEE.
Toure, E. and al. (2018). Megamodel consistency man-
agement at runtime. In Conference Nationale sur
la Recherche en Informatique et ses Applications.
Springer.
Vignaga A., a. (2009). Typing in model management. In
Second International Conference on Model Transfor-
mation. Springer.
MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development
344