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

Ecole Sup

erieure Polytechnique, ESP, Dakar, Senegal

Universit

e Cheikh Anta Diop de Dakar, UCAD University, Dakar, Senegal

Institut de Recherche pour le D

eveloppement, IRD Institute, Dakar, Senegal

Keywords:

Software Conﬁguration 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 modiﬁed 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-speciﬁc 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 deﬁnes a

framework that supports our previously proposed approach.

1 INTRODUCTION

Conﬁguration 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-

ﬁguration management (SCM) is conﬁguration 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 speciﬁca-

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

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 ﬁne-

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 ﬁxing (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 deﬁning 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-speciﬁc 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 ﬁrst, 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 ﬁrst

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

modiﬁed 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 speciﬁc 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 signiﬁcant changes such as different metamodels,

whereas revisions result from addition of new func-

tionality, error corrections, reﬁnements, 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 deﬁned.

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

modiﬁed throughout the execution of GOM instances.

So we use a kind of a complex model, namely a con-

ﬁguration 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 conﬁgura-

tion model are called ”source CMs” and the result is

called ”derived CM”.

A conﬁguration model C is deﬁned by the tuple :

C = < M

, Op, M

>, where :

• M

is the list of source CMs C;

• Op is an instance of a GOM (e.g : merge, match);

• M

is the derived CM of C.

An instance of a given conﬁguration model can be de-

ﬁned and will take as input a revision of each CM in

the list M

, a speciﬁc instance of the GOM Op and

will give as output a new variant of the CMs in the list

. For example, a conﬁguration 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 conﬁguration model is formally decribed

below :

< C = {ms

, map

, mt

}, merge

, merge

> where

∈input(C) ⇒ ∃m ∈revList(s model) : m == ms

∈input(C) ⇒ ∃m ∈revList(t model) : m == mt

map

∈input(C) ⇒ ∃m ∈revList(map

) : m == map

merge

∈ output (C).

map

is a mapping between ms

and mt

. Such a

mapping is a morphism that identiﬁes combinations

of objects in the input models that are equal.

merge

is a generic instance (a function deﬁnition)

of the merge GOM. Thus an application of such a

function is done by deﬁning speciﬁc instances of the

merge GOM.

3 A LANGUAGE-ORIENTED

MEGAMODEL MANAGEMENT

3.1 Overview

In this section, we present a textual domain-speciﬁc

modeling language (DSML), called LAMEME. It is

about a programming language or an executable spec-

iﬁcation 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 deﬁne 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 deﬁned by the speciﬁc GOM instance,

and in return the speciﬁc 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 speciﬁca-

tions are deﬁned using annotations and are translated

into executable code by the interpreter. Thus, any vi-

olation of the speciﬁcation that occurs while a GOM

instance is executed can be detected immediately. A

speciﬁcation deﬁnes 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 speciﬁcation 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 deﬁnition.

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 deﬁnition: 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 deﬁnition : revision

1 def conﬁguration model matching KM3 Kermeta::Match {

2 ...

3 @input from: repository KM3Model

4 @input from: repository KermetaModel

5 @output KM3 Kermeta MatchModel

6 }

Listing 4: Conﬁguration model deﬁnition.

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 conﬁguration matchGOM 23122018 = exec(conﬁguration

::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 deﬁnition.

3.2.2 Listing Descriptions

The Listing 1. starts with the deﬁnition 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 deﬁnition), the initialization phase starts with the

deﬁnition of a megamodel instance megaWork (Line

6). Before the deﬁnition of a CM you must ﬁrst 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 ﬁrst 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 deﬁnition, two revisions have to con-

form to the same metamodel.

The Listing 4. highlights the deﬁnition of a

conﬁguration 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 speciﬁc instance of the Match GOM. Such

a speciﬁc 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 deﬁning 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 speciﬁc 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 deﬁne 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 deﬁned languages.

Figure 1: LAMEME’s Operational Semantic.

Despite these advantages, they are rarely used directly

for program veriﬁcation, 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)deﬁning the lan-

guage as a set of abstract proof rules. Hoare logic,

often identiﬁed 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 deﬁne 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 speciﬁcations, 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

speciﬁcations in LAMEME are machine checkable,

and so can help with debugging. That is, checking the

speciﬁcation 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 speciﬁcation does not

hold when the execution control reaches it, one knows

that something is wrong with either the GOM deﬁni-

tion (execution) or the GOM speciﬁcation 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 speciﬁcations. 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 deﬁned using Hoare’s inference

rules. It’s about building expected outputs and com-

paring them to the execution outputs, the speciﬁed 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 speciﬁcations, and hence

that its execution is unsafe for the megamodel. An

assertion violation will occur, and a speciﬁed excep-

tion will be thrown to indicate the detail information

when some checking failure of speciﬁcations is en-

countered. If an execution of an instance of a GOM

satisﬁes its formal speciﬁcations, 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 deﬁned 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 conﬁguration 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 conﬁguration mergeInstance = exec( conﬁguration ::

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 deﬁne a conﬁguration 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 speciﬁcations 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 deﬁnition

of the speciﬁc 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 ﬁx it, we have to redeﬁne the conﬁguration

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 deﬁned 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

speciﬁc instance of the generic instance Match t s.

Listing 7 gives the deﬁnition of the generic Merge

instance with three parameters.

1 def conﬁguration 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

redeﬁned 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 conﬁguration matchInstance = exec( conﬁguration ::

load(with name = ”Match t s”) )

4 let any merge st = call matchInstance (s m1, t m1)

5 let conﬁguration mergeInstance = exec( conﬁguration ::

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 ﬁeld 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

deﬁning the metadata associated to this platform.

5 CONCLUSION AND FUTURE

WORK

In this work, we propose LAMEME, a domain-

speciﬁc 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 difﬁculty 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 conﬁguration 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 efﬁ-

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