A MDE Approach for Heterogeneous Models Consistency

Mahmoud El Hamlaoui

, Saloua Bennani

1,2

, Mahmoud Nassar

, Sophie Ebersold

and Bernard Coulette

IMS Team, ADMIR Laboratory, ENSIAS, Rabat IT Center, Mohammed V University in Rabat, Morocco

SMART Team, IRIT Laboratory, University of Toulouse-Jean Jaur

es, France

Keywords:

Process, Metamodel, Heterogeneous Models, Matching, Consistency, Correspondences, Impacts.

Abstract:

To design a complex system, we often proceed via separation of viewpoints. Each viewpoint is described by

a model that represents a domain expertise. Those partial models are generally heterogeneous (i.e conform to

different metamodels) and thus performed by different designers. We proposed a matching process that links

partial models through a virtual global model in order to create a complete view of the system. As models

evolve, we should consider the impact of changing an element involved in a correspondence on other models

to keep the coherence of the global view. So, we have deﬁned a process that automatically identify changes,

classify them and treat their potential repercussions on elements of other partial models in order to maintain

the global model consistency.

1 INTRODUCTION

Complex systems design involve a varied set of mo-

deling experts from different business areas. These

designers can be located in distant geographical areas,

as it is the case in distributed collaborative deve-

lopment in big software companies. Several ap-

proaches have been developed to face complex sy-

stems’ modeling. The most used one is the multi-

modeling approach (Boronat et al., 2008). It consists

in elaborating separate partial models that correspond

to different business views on the system (Hilliard,

2001)(Boulanger et al., 2009). This approach helps

designers focus in isolation on different parts (partial

models) of the system. However, at some point, it is

mandatory to construct a global model to understand

and effectively exploit the whole system. Our appro-

ach sets a matching process as presented in (El Ham-

laoui et al., ). It allows the creation of a global view

of the system through a composition based on alig-

ning partial models. Our matching process ﬁrst iden-

tiﬁes correspondences between elements of metamo-

dels (meta-elements). We call those corresponden-

ces HLC - High Level Correspondences- then, the

process generates semi-automatically corresponden-

ces between models’ elements (LLC - Low Level Cor-

respondences). HLCs and LLCs are stored respecti-

vely in M2C (Model of correspondences between me-

tamodels) and M1C (Model of correspondences bet-

ween models). Thus, the global model is the network

of partial models elements, linked thanks to the esta-

blished model of correspondences.

Partial models may evolve during the system life

cycle. As their design was made separately by dif-

ferent designers, their evolution within a system may

occur in an uncoordinated manner. Changing one or

several elements, involved in a correspondence, may

cause the inconsistency of the global model. Our cur-

rent objective is to ensure the consistency of M1C by

re-evaluating LLCs after the evolution of each partial

model. One possible approach would be to relaunch

the matching process after each evolution. This solu-

tion is not optimal as it reproduces the model of cor-

respondence ”from scratch” ignoring the previously

created matches. Furthermore, no trace of the chan-

ges will be kept.

Our proposition takes part in the GEMOC ini-

tiative (GEMOC, 2017). In this paper, we present

an overview of the matching approach (detailed in

(El Hamlaoui et al., )) and present thereafter the con-

sistency management which is the added value and

the core of this current work. Its role is to automati-

cally detect changes from many heterogeneous mo-

dels and treat their impacts automatically (in some

cases semi-automatically) in order to ensure the co-

herence of the system. The process of maintaining

consistency is automatically activated when the mat-

ching process produces M1C. It takes as input all the

partial models of the application domain and the mo-

del of correspondence M1C as presented in Figure 1.

Our approach does not concern intramodel changes

(elements changes that impacts other elements of the

same partial model); it is up to the designers of partial

180

El Hamlaoui, M., Bennani, S., Nassar, M., Ebersold, S. and Coulette, B.

A MDE Approach for Heterogeneous Models Consistency.

DOI: 10.5220/0006774101800191

In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), pages 180-191

ISBN: 978-989-758-300-1

models to manage the internal repercussions of chan-

ges made on their models and to ensure their validity.

Thus, apart from the added elements, only changes

(modiﬁcation and deletion) that have an effect on the

elements of the M1C are treated.

The rest of this paper is organized as follows:

Section 2 introduces the Conference Management Sy-

stem that was chosen to apply our approach. Section

3 presents a general view of the matching approach

whereas section 4 describes in detail the consistency

management approach. Section 5 presents the related

work. We conclude this paper by some perspectives

and a conclusion in section 6.

Figure 1: Overall process of our approach.

2 RUNNING EXAMPLE: CMS

(CONFERENCE

MANAGEMENT SYSTEM)

Production and reviewing of documents are widely

used in various contexts such as project management,

software development, conference management, etc.

A Conference Management System (CMS) is a sy-

stem designed to automate the main functions nee-

ded for the management of a scientiﬁc conference,

namely: call for papers, papers submission, papers

assignment for evaluation, notiﬁcation of the ﬁnal de-

cision, registration, etc. Although, this system is not

very complex, we had chosen it for two reasons; ﬁr-

stly, it is well known by almost every researcher; se-

condly and most importantly, it involves different de-

signers, working with different points of view.

We represent this system by three models: a soft-

ware design model, a business process model and a

persistence model. Due to space limit, we refer to

(Author, 2017) where we provide and present in de-

tail the three models and their respective metamodels.

3 MATCHING APPROACH

Our matching approach consists in analyzing input

models (and their respective metamodels) in order to

identify correspondences that exist among them. Cor-

respondences are stored into a model of correspon-

dences (M1C) conforming to a metamodel of corre-

spondences (MMC). As mentioned earlier, we only

consider intermodels correspondences. So, corre-

spondences between elements of the same partial mo-

del are out of the scope of our research study. We

present below the elaboration of M1C as well as the

proposed iterative matching process.

3.1 Metamodel of Correspondences

MMC represented in Figure 2 identiﬁes the diffe-

rent concepts through which M1C is created. Corre-

spondenceModel contains correspondences establis-

hed between at least two (meta)-elements (RefEle-

ment) from different (meta)models through their re-

ferences. We store references as String value to en-

capsulate information about both their source model

and source metamodel. The Correspondence meta-

class has two attributes that works for the consistency

management process : the mandatory attribute spe-

ciﬁes whether a correspondence is obligatory to the

studied system or not. The weight attribute repre-

sents the weighting coefﬁcient associated to each cor-

respondence. These two attributes will be explained

in section 4.

The correspondence meta-class is composed of

at least two referenced elements and the Relations-

hip that connects them. The bidirectional attribute

speciﬁes whether the relationship is bidirectional or

not. If the relationship is bidirectional, the concerned

(meta-)elements are all source ones and there is no

(meta-)element of type target, as speciﬁed by the OCL

rule :self.bidirectional implies self.target → isEmpty

(). The priority attribute, which is also used in the

consistency management process, granted a priority

value to each type of relationship.

Relationship is an abstract generalization of DIR

(Domain Independent Relationship) and DSR (Dom-

ain Speciﬁc Relationship) meta-classes. The speci-

alization of the ﬁrst one allows representing generic

relationships that are generic and independent from

the domain of application. However, these relations-

hips may be insufﬁcient for a given domain. In this

case, it is possible to add speciﬁc relationships by a

specialization of the DSR meta-class. For the CMS,

we had to add the following three DSRs to describe

the whole system: Play, Requirement and Contribu-

tion. The ﬁrst one highlights the role played by the

participants of a conference in the business process.

The second allows us to know the required input for

a task. The third identiﬁes the operations that contri-

bute to the success of a task.

The abstract meta-class Level is associated to a re-

lationship to describe whether it represents a High Le-

vel Relationship (HLR) or a Low Level Relationship

(LLR) or both. HLR allows representing relationships

A MDE Approach for Heterogeneous Models Consistency

181

Figure 2: MMC with semantic expressions.

Figure 3: Matching sub-process.

that are used in correspondences at metamodel level,

whereas LLR represents relationships that are used

in correspondences at model level. The OCL rule:

self.reﬁned → forAll (r — r.adaptedTo → forAll (lv —

lv.oclIsTypeOf (LLR) implies self.abstract.adaptedTo

→ forAll (lv — lv.oclIsTypeOf (HLR))) speciﬁes that

any type of relationship usable at the HLR level is

also usable at the LLR level. The opposite is not

true. Other annotations are associated to relations-

hips. They are created during the mathing process

and they contain their semantics expressions which

will be used during the selection operation (section

3.4). For example for the Similarity relationship, the

semantic explains that this relationship is used in a

correspondence involving two elements (recovered by

the importSourceElts() operation) with indifferent ty-

pes (Any, Any). It is described by an expression in

Java. The condition explicitly states, using the sa-

meAs function, that the related elements are similar.

3.2 Matching Process

The model of correspondences cannot be constructed

in a monolithic manner. It follows a process that we

call matching process. Figure 3 shows one iteration

of the proposed process. The process involves two

stakeholders, namely, an integrator expert who is the

supervisor of the application domain, and a tool that

assists the supervisor and enacts the automatic parts

of the process.

Firstly, the process takes as input the various meta-

models and the kernel of the metamodel of correspon-

dences. Subsequently, the supervisor veriﬁes if the

MMC contains all needed relationships to set up cor-

respondences between partial (meta)models. If he/she

assumes that the proposed relationships are not sufﬁ-

cient to describe the given domain of application, the

DSR meta-class of MMC is specialized. In the case of

CMS, we added three types of relationships: Play, Re-

quirement and Contribution. The third activity of this

process enriches the MMC with a Semantic Expres-

sion (SE) for each relationship. For this purpose, we

proposed a Semantic Expression DSL (El Hamlaoui

et al., 2015) that is woven with the MMC as annota-

tions. The advantage of using this DSL is primarily

to have a structured common deﬁnition of each rela-

tionship. Secondly, it helps build M2C in an assisted

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

182

way using information on the connected elements ty-

pes. Thirdly, it helps ﬁlter out the correspondences in

the selection step in order to keep only corresponden-

ces that match the semantics of their relationship.

Once the MMC is specialized, the matching ope-

ration begins, the supervisor identiﬁes corresponden-

ces between meta-elements in order to produce the

model of correspondences called M2C. M2C (Model

of correspondences between metamodels) stores High

Level Correspondences that contain meta-elements

linked by High Level Relationships. Figure 4 sum-

marizes the thirteen HLCs deﬁned for CMS. We cite

two examples: A Contribution correspondence links

the meta-element Task from the Business Process me-

tamodel to the meta-element Operation from the Soft-

ware Design metamodel, since an operation can po-

tentially contribute to the achievement of a task. A

Similarity correspondence is established between the

meta-elements Table and Entity in one side and bet-

ween the meta-elements Property and Column on the

other side.

HLCs are then reﬁned in order to produce

LLCs. Our developed tool produces them semi-

automatically by performing a reproduction operation

on the M2C followed by an operation of selection.

3.3 Reproduction

This operation is a homomorphism (structural preser-

vation from one algebraic structure to another one)

between correspondences in M2C and M1C. It dupli-

cates all correspondences deﬁned at the metamodel

level into the model level. So, there will be as many

potential LLCs for a given HLC as Cartesian product

of instances of meta-elements involved in the HLC.

This operation limits the generation of corresponden-

ces to elements whose type participates in a HLC.

Even if the contextual information helps avoiding

the creation of correspondences between elements of

types that do not match (e.g., an Operation and a

Field) it does not guarantee that all generated corre-

spondences are semantically correct.

3.4 Selection

This operation consists in ﬁltering out corresponden-

ces produced by the reproduction operation in order

to keep only those who are valid, with respect to the

semantic expression associated to their relationship,

and ﬁlter out the incorrect ones. For relationships

with informal expression (in natural language), the

supervisor decides whether or not to keep the corre-

spondences depending on the expression associated

to their relationships. Considering the relationships

with a formal expression, their expressions (represen-

ted as a note in Figure 2) have to be executed. Exe-

cution of body’s expressions requires an interpreter

of the language in which the expression is written (a

Java Virtual Machine in our case). Figure 5, illustra-

tes the M1C model of CMS obtained when the expert

manually does the selection phase. In parallel, the

expert has performed the matching process through

the tool and compared the M1C that he has produ-

ced manually to the one generated by the tool. This

comparison concerns only three relationships (i.e. si-

milarity, aggregation and contribution) as they are

the only ones implemented on the tool. For exam-

ple, executing the following sameAs method: ”Aut-

hor”.sameAs(”AuthorTable”) returns true. Thus, the

tool keeps the correspondence involving the two ele-

ments. Similarly, the execution of these two code

snippets: ”ﬁrstName”.isPartOf(”fullName”) and ”las-

tName”.isPartOf(”fullName”) return true. This leads

to keeping the correspondence with the aggregation

relationship between the two source elements (ﬁrst-

Name, lastName) and the target element (fullName).

One the tool generates the M1C, the expert evalua-

tes the accuracy of produced LLCs. Figure 6 shows

the results of comparison between the M1C obtai-

ned manually and the one generated through the tool.

On the line axis, we present for each type of relati-

onships, LLCs considered valid according to the tool

(true) and those considered false. Then each bar is

split to distinguish LLCs truly validated by the expert

(true expert) from invalid ones (false expert). Con-

sidering precision and recall about these results, we

have obtained a precision of 86% for the similarity

relationship, 50% for the aggregation and 70% for the

contribution. While the value of recall is respectively

75%, 75% and 100% for the similarity, aggregation

and contribution relationships. The following section

will discuss the consistency management based on the

manually produced model of correspondences presen-

ted in Figure 5. The seventeen LLCs produced were

numerated to facilitate their exploitation on the next

section.

4 CONSISTENCY

MANAGEMENT APPROACH

Since models evolution is generally not coordinated

between partial models designers, each model may

evolve independently. So, it is very tedious to rerun

the matching process after each change due to the hu-

man effort required in the matching activity and the

lack of changes tracking.

Our approach provides a consistency management

A MDE Approach for Heterogeneous Models Consistency

183

Figure 4: Example of M2C Model for the CMS system.

Figure 5: M1C Model for the CMS system.

Figure 6: Comparison between the M1C produced manu-

ally and the one generated via the tool.

process. This process is automatically activated using

the Observer pattern (Vlissides et al., 1995) at the end

of the matching process. It takes as input the system’s

partial models and the model of correspondences be-

tween them (M1C) and it follows six steps as shown

in Figure 7 (change detection, change analysis, cy-

cle management, change scheduling strategy, change

prioritization and change processing). The ﬁrst step

requires continuous monitoring while the others are

triggered successively on the expert’s demand. This

process is carried out by a developed tool and im-

ply the supervisor’s intervention in phases that require

a human expertise or conﬁguration. Throughout this

section, we are going to detail these six steps.

4.1 Changes Detection

Changes are detected when they occur through

the Observer pattern model instead of differencing

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

184

Figure 7: Consistency management sub-process.

techniques as done in EMFCompare (Brun and Pie-

rantonio, 2008) that provides a generic algorithm for

calculating differences between two versions of a mo-

del. The problem with these techniques is threefold.

Firstly, the whole model must be parsed in order to

check if an element has changed between two versi-

ons of a model, based on distance computing techni-

ques. Secondly, there is a restriction on the number

of models because comparison can be done with only

two models of a given business domain. Thirdly, there

is a waste of memory since they require keeping in

memory the previous version of the input model as

well as the current one.

Changes detected by the implementation Obser-

ver pattern are subsequently added to M1C using the

MMC meta-classes History, DiffElt, AddedElt, Dele-

tedElt, ModiﬁedElt (part 1 of Figure 8). History is

used to keep track of applied changes. DiffElt allows

to record the trace of evolved elements. It has two

attributes. The ﬁrst attribute contains the change clas-

siﬁcation type. The second attribute contains the re-

ference of the element constructed from the element’s

name, its meta-element and the model’s name. Dele-

tedElt represents an element that no longer exists in

the original model but that is maintained for tracing

purpose. AddedElt and ModiﬁedElt respectively re-

present newly added element and model element that

has undergone a modiﬁcation. The extended MMC

deﬁnes moreover a concept that represents the core of

the observer pattern (part 2 of Figure 8). The Obser-

ver meta-class speciﬁes the model’s element to be ob-

served. It is a generalization of the subject meta-class

which has three methods. Two of them (attach and

detach) allow to ﬁx or detach an observer object from

a model element. The third method (notify) makes

it possible to notify the M1C of the changes that have

taken place. The update method of the meta-class Ob-

server is used during the phase of changes processing

in order to maintain the consistency of domain’s mo-

dels. The third part of Figure 8 (i.e. the impact meta-

class) deﬁnes the impact kind of each change and the

solution for each change. A change on an element

may affect directly or indirectly elements that are lin-

ked to this element by a correspondence as we will

see in section 4.2.

The column change detection of Table 1 sum-

marizes the evolutions perfomed on the CMS mo-

dels. These changes are automatically detected via the

tool (with a continuous monitoring) and added to the

M1C. For the CMS, we consider that the process ar-

chitect has added the two roles ”chairman” and ”aut-

hor” to the business process model and that the soft-

ware architect and the process architect have remo-

ved the following elements: Property:phoneNumber,

Entity:Comment and Task:outsource paper. We

also consider that the software architect has rena-

med the operation createCom() and replaced the En-

tity:Review element with Entity:Note element.

4.2 Changes Analysis

This analysis includes deﬁning the type of change

and the M1C elements that may be affected by this

change. This is possible thanks to the extension of

the MMC, which makes it possible to ﬁnd for a mo-

diﬁed element the correspondence(s) to which it be-

longs and thus to ﬁnd the element(s) that may be af-

fected. Directly impacted elements are elements di-

rectly related to a modiﬁed element, whereas indi-

rectly impacted elements are elements that may be af-

fected via a cascading effect.

Suppose we have two correspondences (Figure 9),

the ﬁrst linking an element A to an element B by the

relationship Rx and the second one relating the ele-

ment B to an element C by the relationship Ry. If

element A is modiﬁed, element B can be inﬂuenced

directly by this change, whereas element C may be

affected indirectly via the cascading effect.

In this phase, we also classify changes in two ca-

tegories: the automatic mode for added and deleted

elements and the monitored mode for the modiﬁed

elements. In this latter when an element has chan-

ged, the correspondence must be assessed in terms of

the semantics of its type of relationship. According to

(Cicchetti and Ciccozzi, 2013), when the relationship

type semantics comes into play, version management

problems become more complex and can not be pro-

cessed automatically. In other words, the automation

support is reduced and the changes likely involve hu-

man assistance to decide the impact of the change.

A MDE Approach for Heterogeneous Models Consistency

185

Figure 8: Extension of the Correspondence Metamodel MMC to handle consistency management.

Table 1: Steps of the Consistency Management Process on the CMS system.

Model’s Element

Change

De-

tection

Change Analysis Change Priorization

Change Processing

Type Classiﬁcation Inﬂuenced Elts.

Weight

Order

Pool:Chairman Add Automatic - 0 4 Matching process

Pool:Author Add Automatic - 0 3 Matching process

Task:Outsource

paper

Del Automatic

Operation:

reviewPaper()(DirectImpact)

8 1

Restoring the deleted

element

Task:Edit review(IndirectImpact)

Property:

phoneNumber

Del Automatic - - - -

Entity:Comment Del Automatic

DataObject:

Comment(DirectImpact)

1 2

Deleting the

correspondence

Old Operation:

createCom()

Mod Monitored

Task: Enter

comment(DirectImpact)

4 6

Maintaining the

correspondence

New Operation:

createComments()

Old Entity:Review Mod Monitored

DataObject:

Review(DirectImpact),

DataObject:

Review(IndirectImpact)

6 5

Modifying the

correspondence’s end

element (C9)

New Entity:Note

Column: reviews(DirectImpact),

Property: details(IndirectImpact)

deleting the

correspondence (C16)

Figure 9: Example of cascading effect.

Column change analysis of Table 1 shows the in-

formation that are automatically added to the M1C

during this phase. The added elements are classiﬁed

in the automatic mode since adding them does not af-

fect the consistency of the M1C. Deleted items are

also classiﬁed in the automatic mode.

Deleting the Property:phoneNumber element has

no effect on M1C since it does not participate in any

correspondence. Deleting the Entity:Comment ele-

ment has a direct impact on the DataObject:comment

(linked via correspondence C14 as shown in Figure

5) while deleting the Task:Outsource paper element

has a direct inﬂuence on the Operation:reviewPaper()

element (correspondence C12) and an indirect in-

ﬂuence on the Task:Edit review element (correspon-

dence C11).

Modiﬁed elements are classiﬁed in guided mode.

The modiﬁcation of Operation:CreateCom() element

has a direct inﬂuence on the Task:Enter comment ele-

ment (via correspondence C13), whereas the change

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

186

on the Entity:Review has a direct inﬂuence on the

DataObject:review (correspondence C9) and Co-

lumn:reviews (correspondence C16) and an indirect

inﬂuence on the DataObject:review (correspondence

C17) and Property:details (correspondence C7).

4.3 Cycle Management

Once changes and their direct or indirect impacts are

detected, the tool catches automatically the cycles of

cascading effects. Then the expert chooses to delete

one of the correspondences in order to break the cy-

cle. Let’s take the example presented in Figure 10, we

have three correspondences. The ﬁrst one relates an

element A to an element B, the second one connects

element B to an element C and the third one relates

C to A. If the element A is modiﬁed, the element B

can be directly inﬂuenced by this change, which in-

directly inﬂuences the element C. In the case where

the element C is the one that causes the modiﬁcation

of the Element A, we will have a cascading cyclical

effect. The various cascading cyclical effects are re-

ported to the experts to decide to delete one of these

correspondences in order to break the cycle.

Figure 10: An example of the cascading cyclical effect.

4.4 Change Scheduling Strategy

This step aims at producing an ordered list of chan-

ges. We propose two strategies for changes orde-

ring: classiﬁcation-based strategy and impact-based

strategy.

The classiﬁcation-based strategy consists of cre-

ating a list of changes that contains, in order, chan-

ges that are classiﬁed in automatic mode followed by

those in monitored mode. For example, by choo-

sing this strategy, the list of changes produced in

the CMS is as follows: Pool:Chairman, Pool:Author,

Task:Outsource paper, Property:phoneNumber, En-

tity:Comment; Operation:createComments() and En-

tity:Note. The second strategy that we propose cre-

ates an ordered list depending on the type of impact

of each change. For example, the expert may start

by processing the changes that have both direct and

indirect impacts on other elements and leave chan-

ges that have only direct impacts on other elements to

the end. For example, by choosing this strategy, the

list of produced changes is as follows: Entity:Note,

Task:Outsource paper, Pool:Chairman, Pool:Author,

Property:phoneNumber, Entity:Comment, Opera-

tion:createComments().

These two scheduling strategies work for changes

that have different modes of change or different types

of impact. In the next section, we will see how to

classify changes that have the same type of impact or

the same mode of classiﬁcation.

4.5 Change Prioritization

Changes processing order has an impact on the sy-

stem and its consistency. That’s why we attribute a

weighting coefﬁcient to each correspondence so we

can determinate a prioritized processing order. Taking

the example of Figure 10, assuming that elements A

and C have been modiﬁed, the question to be raised

is which change to treat ﬁrst, knowing that both have

an inﬂuence on the same element B? and will the two

changes be treated?. Prioritization allows to answer

these two questions. We ﬁrst deal with the change

that has the highest weighting coefﬁcient, next change

must then take into account the impact of the previous

changes. In other words, if the change of the element

A requires the modiﬁcation of the element B, the ele-

ment C can modify the element B only if the corre-

spondence linking the element A and B has not been

changed semantically. The order of processing is de-

ﬁned by calculating the weighting coefﬁcient of the

correspondence. This coefﬁcient is calculated by the

following formula:

weight =

∑

k=0

(DirectlyA f f ectedElement

∗ priority)

∑

k=0

(IndirectlyA f f ectedElement

∗ priority)

Where the term priority is the level of priority given

to each type of relationship. We consider that the su-

pervisor gives level 1 to the relationship Similarity,

level 2 to the Aggregation, level 3 to the Play relati-

onship, level 4 to the Contribution and level 5 to the

relationship of requirement.

Sub column order of column change prioritiza-

tion of Table 1 illustrates the result of the change pri-

oritization phase according to the strategy chosen in

the previous step (in our case, automatic mode ﬁrst)

and to the calculated coefﬁcients.

When several changes have the same weighting

coefﬁcient, it is up to the expert to decide on the pro-

cessing order, except for the addition type changes for

which there is no order preference given that all added

elements are processed at the end of the change pro-

cessing by using the matching process. Let’s detail

the weighing coefﬁcient calculation for the highest

A MDE Approach for Heterogeneous Models Consistency

187

change (deletion of Task: OutsourcePaper) : This ele-

ment is directly linked to Operation: ReviewPaper()

via a Contribution link (priority 4) and indirectly lin-

ked to Task:Edit Review via a Contribution link also.

The weighting coefﬁcient is thus 4*1+4*1=8.

4.6 Change Processing

In this step, M1C and the partial models may be mo-

diﬁed to take account of the changes that have been

detected. Figure 11 presents the change processing

process. Changes categorized in automatic mode are

processed automatically.

In case where an element has been added, the ma-

tching process is restarted at the end of the change

process to handle the added elements all at once. In

case an element has been deleted, all corresponden-

ces involving this element become orphaned. An or-

phaned correspondence is a correspondence for which

one of its ends - a model element - is missing. When a

correspondence becomes orphaned, the expert checks

if it is mandatory for the system concerned (true in

the mandatory attribute). In positive case, the dele-

ted item is restored, otherwise the correspondence is

deleted from the model of correspondences.

Concerning the second type of changes, namely

changes occurring in a monitored mode, they are

managed semi-automatically. The correspondence is

maintained if, after the change of one of its ends, it re-

mains correct regarding the semantic associated to its

type of relationship. Otherwise, when an element is

modiﬁed, it is necessary to modify each of the ele-

ments tied to it since this modiﬁcation is possible.

When it is impossible to modify an element, the cor-

respondence is deleted if it is not mandatory (man-

datory = false). Otherwise, a group decision making,

involving the expert with partial model designers, ta-

kes place to decide whether to modify the concerned

element or the element at the other end of the corre-

spondence.

For the CMS example, we proceed following the

column order of Table 1, the ﬁrst removed element is

restored because it is used in the correspondence C12

(see Figure 5) and it is a compulsory correspondence

(mandatory = true). Correspondence C14 involving

the second element is deleted, since it is an orphan

correspondence and it is not mandatory to the system

consistency. The matching is invoked at the end of

the process to search for possible correspondences for

the third and the fourth element. Two corresponden-

ces using the play relationship are thus created (C17

and C18). The ﬁfth element is involved in two corre-

spondences C9 and C16. The ﬁrst one links it to the

DataObject:review element and the second to the Co-

lumn:reviews element. The element of the opposite

end of the ﬁrst correspondence is modiﬁed since the

correspondence is no longer correct. Concerning the

second correspondence, since the opposite element

cannot be modiﬁed (because of the choice to prohi-

bit the modiﬁcation or the deletion of any element of

the persistence model) and the correspondence is not

obligatory, it is then deleted.

Table 2 summarizes the change processing on the

CMS. Lines in bold indicate changes that have been

made to M1C of Figure 5. The underline lines (cor-

respondences: C17 and C18) are the added elements,

those in dotted lines (correspondences: C12 and C13)

are the changed elements. Deleted elements are bar-

red (C14 and C16).

5 RELATED WORK

A number of approaches described in the litera-

ture deal with view-based complex systems’ design

through models matching. As this paper mainly ad-

dresses the consistency management due to an evo-

lution, in this section, we put the focus on the sub-

set of these approaches that support one or several

aspects of model evolution issue. To do that, we

have studied a set of representative approaches, na-

mely Edapt(Williams et al., 2012), previously called

COPE(Herrmannsdoerfer et al., 2008), EMFMigrate

(Di Ruscio et al., 2011), Model federation (Guychard

et al., 2013) and the one developed by Cicchetti and

al. (Cicchetti et al., 2008). To lead this study we have

deﬁned and used the following criteria that we con-

sider relevant in a multi-modeling environment: he-

terogeneity, number of input artifacts and their types,

mechanism of change detection, adopted support of

changes’ classiﬁcation, and migration rules. These

criteria are deﬁned as follows:

• H

eterogeneity: expresses if the considered ap-

proach takes into account heterogeneous artifacts.

We consider that two artifacts are heterogeneous

if their modeling languages are themselves diffe-

rent,

• Number of input Artifacts: indicates the maxi-

mum number of input artifacts allowed by the ap-

proach,

• Types of Artifacts: identiﬁes the shape of repre-

senting artifacts. The latters are not necessarily

models, they might be rules of transformation or

other types of artifacts,

• Change Detection: assesses how an approach pro-

ceeds to detect the elements of artifacts that have

undergone an alteration,

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

188

Figure 11: Change processing steps.

Table 2: CMS system’s M1C model after models evolution and Consistency Management Process conduct.

Correspondence Relationship’s Type Partial Models’ Elements

Name

Man-

datory

Name

Prio-

rity

Software Design Model Business Process Model Persistence Model

C1 False

Similarity

StereotypedEntity:Author Table:AuthorTable

C2 False

Similarity

Entity:Paper Table:ArticleTable

C3 True

Similarity

Property:organization Column:organization

C4 True

Similarity

Property:address Column:address

C5 False

Similarity

Entity:Reviewer Table:ReviewerTable

C6 False

Aggregation

Property:ﬁrstName Column:FullName

Property:lastName

C7 False

Aggregation

Property:details Column:reviews

Column:decision

C8 True

Similarity

Property:submissionDate Column:admissionDate

C9 False

Similarity

Entity:Note DataObject:notice

C10 True

Requirement

Task:logIn Columns:password, e-mail

C11 True

Contribution

Operation:reviewPaper() Task:Edit review

C12 True

Contribution

Operation:reviewPaper() Task:Outsource paper

C13 True

Contribution

Operation:createComments() Task:Enter comment

C14 False

Similarity

Entity:Comment DataObject:comment

C15 False

Play

StereotypedEntity:Reviewer Pool:Reviewer

C16 False

Similarity

DataObject:review Column:reviews

C17 False

Play

StereotypedEntity:Author Pool:Author

C18 False

Play

StereotypedEntity:Chairman Pool:Chairman

A MDE Approach for Heterogeneous Models Consistency

189

• Classiﬁcation Support: indicates whether the ap-

proach supports a classiﬁcation of changes in or-

der to assign to each kind of change a particular

action. It is interesting to take this criterion into

account, because the classiﬁcation of changes al-

lows the automation of the whole evolution mana-

gement process or at least a part of it,

• Migration Rules: describes the language in which

the migration rules are implemented. It is with

this language that the treatment of evolution is re-

alized.

Table 3 presents a synopsis of the studied approa-

ches, based on the established criteria. By analyzing

it, we can deduce that the consistency management

process has not reached a sufﬁcient maturity yet. Fir-

stly, the studied approaches do not deﬁne any classiﬁ-

cation support, a factor that we consider mandatory

to automatically manage changes and their impacts

on models, through predeﬁned actions. Secondly, for

a complex change which affects several elements at

the same time, multiple rules are likely to be produ-

ced. Choosing the appropriate adjustment to run re-

quires rules’ customization and also some technical

background knowledge. Thirdly, most of the appro-

aches discussed above, except Model Federation and

Cicchetti and al., focus on model evolution as a re-

sult of adaptation of their corresponding metamodels

(co-evolution) to preserve the conformity relations-

hip. That is to say that these approaches emphasize

the vertical level (co-evolution) without considering

horizontal evolution (between models). It is within

the scope of this latter that models synchronization is

based. Fourthly, EMFMigrate and Cicchetti and al.

require a speciﬁc difference metamodel and it is up

to the stakeholder to detect the changes and represent

them in a difference model. Fifthly, the model fede-

ration approach responds to our problem by exploi-

ting correspondences established for the consistency

management. However, it does not propose a mecha-

nism for managing traceability of changes. Moreo-

ver, the approach is based essentially on the modiﬁ-

cation change of type. Therefore, it does not manage

impacts due to the addition or deletion of model ele-

ments. For the modiﬁcation, the synchronization can-

not be applied without deﬁning a master and a slave

model.

To sum up, the approaches presented above do not

consider or respect all of the criteria described above

and thus do not fully address some important aspects

of model evolution. This is because they do not ex-

ploit previously established correspondences to pro-

vide a mechanism that ensures the consistency of the

overall model.

6 CONCLUSION AND

PERSPECTIVES

Our general research work addresses view-based

complex information systems design. During the mo-

deling cycle, the description of models evolves fre-

quently due to the emergence of new requirements

and constraints. In a multi-modeling environment, se-

veral changes can occur on different models of the

system. To manage the consistency between these

models, we propose to exploit the correspondences

model to treat the changes that are identiﬁed auto-

matically on partial models in order to maintain the

consistency of the interconnected models. Once the

changes are identiﬁed, the consistency management

process proceeds to their classiﬁcation and the po-

tential impacts are identiﬁed automatically as well as

the possible presence of cycles. These latters are ma-

naged by the expert. Change prioritization is impor-

tant because without coordination the evolutions tre-

atment could become unmanageable. For this, accor-

ding to the chosen strategy, a list of changes is gene-

rated according to the calculation of weighting coef-

ﬁcients. Finally changes proceed automatically based

on a change processing sub-process.

As a proof of concept of our approach we are de-

veloping a support tool called HMCS (Heterogeneous

Matching and Consistency management Suite). Its

role is to provide assistance to expert in the creation

of the model of correspondences and the management

of the consistency between heterogeneous partial mo-

dels when they evolve. HMCS is operational but only

supports the matching sub-process. This tool, once

completed, will allow us to validate our approach and

to conduct experiments to verify thereafter its scala-

bility.

We propose two perspectives to our work. The

ﬁrst one concerns the consistency management pro-

cess. In this process we considered the directly af-

fected elements at the same level as the indirectly af-

fected ones for calculating the weighting coefﬁcients.

To strengthen the algorithm, we intend to implement

the random walk theory (Fouss et al., 2007) in order

to evaluate the probability that an element in the cor-

respondences model (M1C) is impacted by a change

either it is directly related or not. So far, our propo-

sal is based on a relatively centralized process, giving

a large responsibility to the expert. Big industrial in-

formation systems involve several designers working

collaboratively. So, the second perspective consists

in deﬁning a collaborative process to support the ma-

tching and consistency management activities. In-

deed, in real complex systems, designers should clo-

sely work together to efﬁciently produce the corre-

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

190

Table 3: Comparison of model evolution approaches.

Approaches/Criteria H NA TA CD CS MR

Edapt (Cope ) No 2 M

No Java (Groovy)

EMFMigrate No 2 M/T

Manual No Speciﬁc DSL

Cichetti and al. No 2 M Manual No ATL

Model federation Yes 2..n M Not deﬁned No ATL

Our approach Yes 2..n M Automatic Yes M1C+Process

Model

Transformation rules

Semi-automatic

Adaptation

ATLAS Transformation Language

spondence model and they also should be collabora-

tively involved in the management of models’ change

impacts. We have initiated this work by presenting in

(El Hamlaoui et al., ) the design of a complex system

via a collaborative process by modeling the Emer-

gency Department (ED) of a hospital.

REFERENCES

Author, A. (2017). Conference management system exam-

ple.

Boronat, A., Knapp, A., Meseguer, J., and Wirsing, M.

(2008). What is a multi-modeling language? In Inter-

national Workshop on Algebraic Development Techni-

ques, pages 71–87. Springer.

Boulanger, F., Jacquet, C., Hardebolle, C., and Rouis, E.

(2009). Modeling heterogeneous points of view with

modhelx. In International Conference on Model Dri-

ven Engineering Languages and Systems, pages 310–

324. Springer.

Brun, C. and Pierantonio, A. (2008). Model differences

in the eclipse modeling framework. UPGRADE, The

European Journal for the Informatics Professional,

9(2):29–34.

Cicchetti, A. and Ciccozzi, F. (2013). Towards a novel

model versioning approach based on the separation

between linguistic and ontological aspects. In ME

2013–Models and Evolution Workshop Proceedings,

page 60. CEUR-WS.

Cicchetti, A., Di Ruscio, D., Eramo, R., and Pierantonio,

A. (2008). Automating co-evolution in model-driven

engineering. In Enterprise Distributed Object Compu-

ting Conference, 2008. EDOC’08. 12th International

IEEE, pages 222–231. IEEE.

Di Ruscio, D., Iovino, L., and Pierantonio, A. (2011). What

is needed for managing co-evolution in mde? In Pro-

ceedings of the 2nd International Workshop on Model

Comparison in Practice, pages 30–38. ACM.

El Hamlaoui, M., Coulette, B., Ebersold, S., Bennani, S.,

Nassar, M., Anwar, A., Beugnard, A., Bach, J., Ja-

moussi, Y., and Tran, H. Alignment of viewpoint he-

terogeneous design models: Emergency department

case study. In International Workshop On the Globa-

lization of Modeling Languages (GEMOC) co-located

with MODELS 2016. CEUR Workshop Proceedings.

El Hamlaoui, M., Ebersold, S., Coulette, B., Anwar, A.,

and Nassar, M. (2015). Maintien de la coh

erence

de mod

eles de conception h

erog

enes. Technique et

Science Informatiques, 34(6):667–702.

Fouss, F., Pirotte, A., Renders, J., and Saerens, M. (2007).

Random-walk computation of similarities between

nodes of a graph with application to collaborative re-

commendation. IEEE Transactions on knowledge and

data engineering, 19(3).

GEMOC (2017). Initiative on the globalization of modeling

languages.

Guychard, C., Guerin, S., Koudri, A., Beugnard, A.,

and Dagnat, F. (2013). Conceptual interoperability

through models federation. In Semantic Information

Federation Community Workshop.

Herrmannsdoerfer, M., Benz, S., and Juergens, E. (2008).

Cope: A language for the coupled evolution of me-

tamodels and models. In International Workshop on

Model Co-Evolution and Consistency Management.

Hilliard, R. (2001). Viewpoint modeling. In Proceedings of

1st ICSE Workshop on Describing Software Architec-

ture with UML, volume 7.

Larman, C. (2002). Applying UML and patterns: an intro-

duction to object-oriented analysis and design and the

uniﬁed process. Prentice Hall.

Vlissides, J., Helm, R., Johnson, R., and Gamma, E. (1995).

Design patterns: Elements of reusable object-oriented

software. Reading: Addison-Wesley.

Williams, J., Paige, R., and Polack, F. (2012). Searching

for model migration strategies. In Proceedings of the

6th International Workshop on Models and Evolution,

pages 39–44. ACM.

A MDE Approach for Heterogeneous Models Consistency

191