A Metamodel independent approach for

aquahellishΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 4 χρόνια και 19 μέρες)

171 εμφανίσεις



SCHOOL OF INNOVATION,
DESIGN AND ENGINEERING,
Malardalan University,
Vasteras, Sweden



Master Thesis

A Metamodel independent approach for


Conflict Detecti
on to support distributed

development
in MDE


Mostafa Pordel


Supervisor:

Antonio Cicchetti


Exa
miner:

Ivica Crnkovic

Autumn 2009,

I.

Abstract

The need for change direction in software engineering has been suggested in several
resources. In recent years many organizations have begun to focus attention on Model Driven
Engineering (MDE) as an approach to

application design and implementation.

Model Driven
Architecture (MDA)
is introduced by Object Management Group (OMG)

in 2001

in support of
MDE
. The aim of it is
better
portability of software. This is done through separating of system
architectures from
platform architecture. Models are the basic elements in MDE. The focus on
MDE is on the concept of “Everything is a model” which have partly been already solved for
programming languages. In particular, models can be developed in a distributed environment,

thus once they
merge
together
,

conflicts and inconsistencies
should
be detected in a convenient
way
i
n order to let them be reconciled (regardless whether automatically or not). The project is
based on previous works which defined a difference and conflic
t metamodel of a source model.
It introduces the benefits of versioning systems in MDE framework. An architecture for detecting
conflicts is represented and a conflict metalmodel of any model which confirms KM3 (KM3 is a
domain specific language to define
metamodels and it is available under the eclipse platform) is
generated automatically. The concept of conflict metamodel is separated from the model so it
could be changed regardless of models and in the need of defining new metamodel of conflict
models.

II.

C
ontents

I.

Abstract

................................
................................
................................
..............................

2

II.

Contents

................................
................................
................................
.............................

2

1.

Preface

................................
................................
................................
...............................

4

2.

Introduction to MDE

................................
................................
................................
............

4

Standards and technologies used in MDE

................................
................................
..............

5

UML

................................
................................
................................
................................
....

6

MOF

................................
................................
................................
................................
....

6

XMI

................................
................................
................................
................................
.....

6

CWM

................................
................................
................................
................................
...

6

Models in MDE,

................................
................................
................................
......................

6

MDE open source tools

................................
................................
................................
..........

6

EMF

................................
................................
................................
................................
....

6

Kermeta

................................
................................
................................
..............................

7

MOFScript

................................
................................
................................
...........................

7

MTF

................................
................................
................................
................................
....

7

ATL

................................
................................
................................
................................
.....

7

ModFact

................................
................................
................................
..............................

7

KMF

................................
................................
................................
................................
....

7

OpenArchitectureWare

................................
................................
................................
........

7

GM
T

................................
................................
................................
................................
....

8

OpenMDX

................................
................................
................................
...........................

8

AndroMDA

................................
................................
................................
..........................

8

XDoclet

................................
................................
................................
...............................

8

Middlegen

................................
................................
................................
...........................

8

OOMEGA
................................
................................
................................
............................

8

3.

Version Management

................................
................................
................................
..........

9

1.1.

Difference Model

................................
................................
................................
........

9

1.2.

The need for Model Code Management

................................
................................
....
10

4.

Difference Metamodel

................................
................................
................................
........
11

5.

Conflict Metamodel

................................
................................
................................
............
13

6.

Conflict Detection Architecture

................................
................................
...........................
14

1.3.

The scenario

................................
................................
................................
..............
16

7.

Implementation

................................
................................
................................
..................
17

8.

Sample View

................................
................................
................................
......................
21

1.4.

Models

................................
................................
................................
.......................
21

1.5.

Difference Model

................................
................................
................................
.......
22

1.6.

Conflict Pattern

................................
................................
................................
..........
23

9.

Conclusion and futu
re works

................................
................................
..............................
24

10.

References

................................
................................
................................
....................
25


1.

Preface

M
odels
are the basic elements
in
Modeling Development Architecture (MDA). The focus on
models and the concept of “Everyth
ing is a model”

is the principle in MDE. This
ha
s

partly been
already solved for programming languages. In particular, models can be developed in a
distributed environment, thus once they have
merge
together
,

conflicts and inconsistencies
should
b
e detecte
d in a convenient way i
n order to let them be reconciled (regardless whether
automatically or not).

The emphasis here is to automatically generate the
Metamodel

of the conflict model of any
model that confirms
Kernel Meta
Metamodel

(
KM3). KM3 is a domain s
pecific language to
define metamodels and it is available under the eclipse platform.
Th
is

proj
ect is based on
previous works done by A.Cicchetti [
Antonio
]

which defined a
difference and
conflict
metamodel
.
The aim of this thesis is to realize an Eclipse p
lug
-
in able to manage different EMF model
versions

detect conflicts and inconsistencies and reconcile them in an analogous way to lexical
concurrent version systems (e.g. CVS, SVN).


2.

Introduction to MD
E

The most popular software engineering methods in last

30 years were based on the basic
concept of “everything is an object”. That basic idea was so successful in driving software
engineering to simplicity and generality. It has provided a great integrity mechanism for software
development.

After introducing

of many extensions and concept the Object oriented concept, the need for
change direction in software engineering has been sug
gested in several

papers
. For example
we can refer to the following statements:

“The software industry remains reliant on the cra
ftsmanship of skilled individuals engaged in
labor intensive manual tasks. However, growing pressure to reduce cost and time to market and
to improve software quality may catalyze a transition to more automated methods. We look at
how the software industry

may be industrialized, and we describe technologies that might be
used to support this vision. We suggest that the current software development paradigm, based
on object orientation, may have reached the point of exhaustion, and we propose a mode
l for its

successor


[Patterns]
.

Recently

the idea of “Everything is a model” has started great interests among software
engineers and opened a realistic research agenda [Power of Models].

As a result,
many organizations have begun to focus attention on

Model Driv
en Architecture
(
MD
A) that supports MDE

as an approach to application design and implementation
. MDA
is
introduced by Object Management Group (OMG)

in 2001
.

The aim of
it
is more portability of
software. This is done through separating of system architectu
res from platform architecture.
MDE is shift from code
-
based to model based programming.

Figure
1

shows the basic concepts
of Object oriented technologies and

MDA
. As it is viewed, the basic component of MDA is a
Model while the
basic component of Object Oriented is an Object. In MDA, a model “confirms
to” another model.
On the other hand

each
object “
inherits

from” other objects.
In MDA
architecture we should avoid picking the concepts of
Object Oriented (
OO
) technology
. For
exa
mple there is no base model in MDA. If the concepts and relations

would be used

as
they
were
defined, the two software development architecture could be complimentary for each
other.

MDE

is a very positive development for several reasons.

It

encourages ef
ficient use of system
models in the software development process. The usage of models as the base elements of
development
has
encourage
d
software

developers to shift th
eir traditional solutions to MDE or
use it as a complimentary of their
programs
.

More s
pecifically,

P
latform Independent Model
(PIM)

is so called the base component of the MDA.

The reuse of models in different platforms
and frameworks was so successful in creating families of systems. As a result,
it
is a
solution

to
organize and manage ente
rprise architectures. MDA is supported by some automated tools and
services for both defining the models and facilitating transformations between different model
types

[Eclipse]
.


Figure
1
, MDA
and Objec
t technology basic concepts. A)
An

o
bject

inherits from another
object.
B) MD
A
Model
Confirms to

another Model
.



Standards and technologies used in MD
E

Several standards
have

been used in MDA concept while some new are needed for future
development.

Some o
f them are described bellow:

B)


A)

Object

Inherites from

System

Composed of

S
ystem

Model

Metamodel

Confirms to

Repreented by


UML

Unified Modeling Language (UML)

is a language for specifying and designing software systems.
It is useful by providing constructs for software
components
, object, activities, relations and etc.
Now UML 2.0 is
the current of
ficial version which is
widely used in different industries.

In the
case of
usage in
modeling and MDE, there are four different
parts

as follows:



UML 2.0 Infrastructure



UML 2.0 OCL



UML 2.0 Diagram Interchange



UML 2.0 Superstructure Specification

The only l
ast one (
UML 2.0 Superstructure Specification
) is completed and available for
download while the other three parts
has not yet finalized [MDA Spec].

UML 2.0 is helping
modeling currently is different domains including real
-
time systems and embedded systems
.


MOF

Meta Object Facility (MOF)

provides the standard modeling and constructs that are used in
MDA. The constructs are a subset of UML modeling constructs.

MOF help with defining the
transformations between models

[
MDATech
]
.


XMI


XML Metadata Interchang
e (XMI)

is an extension of XML and therefore very useful to hold
model’s information in structured text format [
MDATech
].


CWM

Common Warehouse Metamodel (CWM)

is a data warehouse standard which has been defined
by OMG.

It supports the management of the l
ife cycle

including designing, managing and
building data warehouse applications [MDATech].


Models in MD
E

There are several models used in MDE including
CIM
,
PIM
,
Platform

Model

and
PSM
.


MD
E

open source

tools

In order to get start with the implementation h
ere are some
open

source tool
s

currently available
for
download:


EMF

The Eclipse Modeling Framework (EMF), arguably the most popular project within the Eclipse
community, has largely adopted the MDA approach and implements most of MDA’s core
specifications
. These include the Meta Object Facility (MOF); Unified Modeling Language
(UML); Query, View, Transformation (QVT); Object Constraint Language (OCL); MOF to Text
(MOF2Text); and XML Metadata Interchange (XMI).


Kermeta

Kermeta has been

d
eveloped by the INRI
A Triskell
team.

T
he Kermeta workbench is an
Eclipse
-
based
Object Oriented (
OO
)

Meta

programming environment dedicated
for

metamodel
engineering activities, including specification of abstract syntax, static semantics (OCL) and
dynamic semantics with conne
ction to the concrete syntax, model and meta
-
model prototyping
and simulation, model transformation and aspect weaving. Kermeta is built as an extension to
Eclipse EMF.


MOFScript

MOFScript is a

model to text transformation tool, based on one of the OMG M
OF Model to Text
Transformation
.


MTF

IBM Model Transformation Framework (MTF) is an EMF based

model transformation
framework
. It is now available at alphaWorks and

provides a declarative means of specifying
metamodel relationships, similar to that of QVT r
elations.


ATL

ATL Engine is a QVT
-
like transformation language, developed by the INRIA Atlas team. ATL is
one of the core technologies in
the Eclipse

M2M project. It is developed as a set of Eclipse
plug
-
ins

and works as a development IDE for transformatio
ns
. ATL includes

execution and
debugging

in the current version

and it

is integrated
with EMF and MDR.


ModFact

ModFact
is a

MOF Repository and QVT
-
like engine from LIP6, Paris.

It is

b
ased on the TRL
language.


KMF

Kent Modelling Framework (KMF)

is

a too
l for generation of languages with support for dynamic
constraint checking.


OpenArchitectureWare

OpenArchitectureWare is a flexible, template
-
based generator framework
that has been
integrated with XMI.


GMT

Gen
erative Model Transformer (GMT) is

an eclipse
incubator project that provides research
-
oriented model transformation technology for
Eclipse platform.
Several tools are part of GMT

that some of them are mentioned bellow
:



AMW (Model Weaving)



Epsilon (Model Merging)



MoDisco (Model Discovery)



MOFScript (
Model 2 Text)



openArchitectureWare



U
MLX (Graphical Transformation)



VIATRA2 (Visual Automated Transformations).


OpenMDX

OpenMDX is an MDA environment
which integrates with several tools through
XMI. It
supports
code generation towards several target platfor
ms
like
J2EE

and

.Net.


AndroMDA

AndroMDA is
a
template
-
based tool for J2EE code generation from UML/XMI.
It u
ses VTL
(Velocity Template Engine) as scripting language and Netbeans MDR as a model API.


XDoclet

XDoclet is
an attribute based code generation too
l for J2EE.
It is not really model
-
based

but can
be combined with generation tools such as UMT to achieve good model
-
based value.


Middlegen

Middlegen is
a
database driven code generator
that is
based on JSBC, Velocity, Xdoclet and
Ant.


OOMEGA

OOMEGA is
an
integrated
modeling

and metamodeling tool for defining languages and code
generators.
It s
upports db4objects, Hibernate, Versant, OOMEGA's MemoryDB, XML and SDF
(a standard binary codec) for storing both

metamodels and models. Code generation templates
are

written in JSP where
developers
can inspect model information via a unified API.


3.

Version Management

For each language there is need for set of tools
to support
comparison, merging and
manipulation of the sources.
This is
especially

necessarily in
the
de
velopment and
implementation phase
s

of project while
different developers extend the same program.


For saving sources from problems in concurrent versions,
developers

are forced to update
their
programs
via some
Source Code Management (SCM)

tool
s

like CVS

or Subversion.
The basic

idea of these tools is compression of
the
server version and
changes ma
d
e by
developer
s.
The
output of such
a
tool is usually presented in a way that developers

can

see the changes and
decide the right decisions for replacing thei
r program
s

with
the

existing one.
Coloring technique
is used in several tools to show the result

[Coloring]
.


Figure
2
)

Overview of
updating

new models in
concurrent

MDE software development

[version]

3.1


Difference Model

Code manage
ment

system
s use version control
systems
in order to
store cha
nges track to the
final version.
There
is no such general purpose tool

for calculating the difference model for MDE
but there are some tools for specific models where they show differences betwe
en old version
and new version by highlighting different components

or elements
.
Rational Rose [
Rational] and
Konesa [konesa] have

different graphic view for models.

Antotnio
and others [
Conflicts
]
have
explained a model driven
approach

which
shows
how
a

d
ifference model is created in MDA.


Figure
3
) Difference Model that is created confirms to Difference Metamodel

[
Conflicts
]

A
metamodel
for that d
i
fference model i
s described in details in

section
4
.

3.2


The need for Model Code Management

SCMs are
general purpose tools for code management. They are
applicable
and used
for
documents, source codes,

programs and other information.

T
hese tools are not efficient for
being used as model repositories
and users sh
ould decide for the problems that are shown
usually
in text format and
with coloring techniques.


As i
n MDE,

text
sources
are not any more concerned and
s
ince we use models including some
elements like classes and relations, we should manage changes on

the

form of
models
, not in
text format.

If we use
SCM, there is a need to first convert models into texts and then use the SCM and
again
convert result
s

to
the

form
of model
s

to be shown to developer
s
.

Some to
ols that use

such techniques are currently availa
ble for some
model
domains like Argo

UML [
Argo]. Argo
transform
s

a diagram into
a

XML document [
Version
], and after the
transformation
, developers

can
use text based
version control tool
s

such as RCS

and CVS
for
the transformed XML document.
In some cases
these
kinds

of tools
such as

Eclipse UML,
Jude
and

Poseidon

have interfaces
which
enable
them
to

use
CVS

or other SCMs

[EclipseUML]
.

This
solution
is not logical in MDE
and it
does not follow
the
i
dea of

“Everything is model”
.
Also
limited result that rec
eived by text based comparison is not
a good achievement.

In a scene

that
integration with models
is

not stressed,
there is a need
for Modeling Code Management (M
C
M
)
.
MCM

is then a platform
which
should be
created for
models

management
.

In such a platform
difference models are
stored to help version controls.
In this thesis we propose a structure for
detecting conflicts that could

also

be used in
MCM
s

later
.
Therefore
benefits of
MCM
s
is
not
just
only on behalf of the model based versioning system but also
on
helping developers with
introducing conflicts in a form of a model. The

possibility to define conflicts in
MCM
s

will

help
developers with the simplicity of problem detection and preventing traditional conflict problems
usually occurs because of parallel

developing.

4.

Difference
Metam
odel


In order to compare two models in
MCM
,

we need to generate the difference of two input
model
s
. The concept of “Everything is model”, suggests us to present
that
difference as a model

itself
. The
difference model should co
nfirm a metamodel which we call Difference
Metamodel

(DMM)
.

Some
requirements for model difference are discussed in [Antonio] and a metamodel
is
suggested
to cover them
. That idea is based on three events that could be happ
ened for a
model. A model element

could be deleted, changed or added in new
er

version
s
. If these three
events are considered in new difference model, the DMM is more likely an extension of the
metamodel of the input model with three extended elements for each existing element in input
met
amodel.

To demon
strate the difference metamodel, consider the simple model named NET that can hold
a network nodes
and
edges.

The following
NET
metamodel
is defined
in
KM
3 format:

package NET

{

class Node



{





attribute name : String;



reference edges

: Edge;


}


class Edge



{





attribute name : String;



reference nodes : Node;


}

}


package PrimitiveTypes {



datatype

String;

}

Code
1
) NET metamodel defined KM
3 format

Figure
4

shows
NET
metamodel
d
i
agram
. Each NET
model can
have different Nodes and
Edges and each new version of an existing model
can differ on added, deleted
or chang
ed
node
as discussed.



Figure
4
) NET metamodel of NET model

D
ifference metamodel of input
NE
T metamodel
is simply an extension of
it as

described in
Figure
5
.


Figure
5
) Difference

Metamodel of NET
meta
model
; e
ach element of NET metamodel is extended
to three other elements that
confirm

Deleted,

Added, Changed

The following
code
is
d
ifference metamodel in KM3

format
:

package NETDiff {



abstract class Added {




}



abstract class Deleted {


}


abstract class Changed {


}



class Node {


attribute name : String;


reference edge
s : Edge;


}



class Edge {


attribute name : String;


reference nodes : Node;


}



class AddedNode extends Node, Added {


}



class DeletedNode extends Node, Deleted {


}



class ChangedNode extends Node, Changed {


reference upDatedEl
ement : Node;


}



class AddedEdge extends Edge, Added {




}



class DeletedEdge extends Edge, Deleted {




}



class ChangedEdge extends Edge, Changed {


reference upDatedElement : Edge;


}

}


package PrimitiveTypes {



datatype

String;

}

Code
2
)
NET d
ifference
m
etamodel
in KM3 format

5.

Conflict
Metamodel

Antonio and others

[Conflicts]

suggested a metamodel for conflict detection that is based on
difference metamodel.
It contains left and right patterns
definition
for

two input models. Each
pattern includes

one or more difference element. Pattern
s are described in OCL language
.



Figure
6
) NET Conflict Metamodel; t
he idea is based on left and right patterns of elements of two
input models.

In
next chapter a “
conflict detection scenario
” is presented and a conflict metamodel is used
there.


6.

Conflict Detection Architecture

Based on
d
ifference
and conflict metamodels
which
has been already presented,
we can
generate the conflict metamodel of any i
nput metamodel. The conflict metamodel enables us to
develop an eclipse plug
-
in

for developing conflict models
in
the language of conflict metamodel.
A
ll the gener
ated conflict models made by preferably an
expert
are

then
used in a
c
onflict
d
etector tools
to detect the conflicts of the parallel developed versions of the
same model.

Figur
e
7

demonstrates a scenario for detecting conflicts for two input models which are
extended from the same model.


Figur
e
7
) Conflict

Detection scenario: for different versions of input Model A, the conflict patterns
are used to detect conflicts.

The model

contains several

actions and packages
as follows:



Actions are:

1.

Merge

This part receives a conf
lict metamodel definition and a conflict metamodel of a model and
merges them in to another model. It is written in

ATL file.

2.

Generate
Eclipse Plug
-
in

Conflict
Metamodel
definition

Metamodel
of Model A

Merge

Conflict
Metamodel
of A

Generate
Eclips plug
-
in

Conflict
patterns

Eclipse
Plug
-
in

Define
Conflicts

DVersion 1
of Model A

DVers
ion 2
of Model A

Detect
Conflicts

Conflicts

Automated by
ATL engine

Done by an
expert

This is done
with Java. It
receives conflict metamodel as an input and generates an
Eclipse

plug
-
in for d
efining conflicts.

This plug
-
in enables developers to drag and drop elements of
conflict language and define a set of conflicts.

3.

Define Conflicts

Developers
can define

new conflicts with the help of the eclipse plug
-
in generated from conflict
metamodel.

4.

De
tect Conflicts

It is done by comparing the patte
rns of left and right model
s

with set of conflicts

already defined
.
If both side
s

are matched a conflict is detected.



Packages are

1.

Conflict Met
amodel
d
efinition

This could be a conflict metamodel discussed ea
rlier

[Conflicts]

or any other conflict metamodel
that is based on difference metamodel.

2.

Input metamodel

Any metamodel that confirms KM3 could be considered as input metamodel.

3.

Conflict Metamodel of the input


The result of Merge
process
is a Conflict met
amodel of the input metamodel.

4.

Eclipse Plug
-
in

In the process of

“Generate Eclipse Plug
-
in”, conflict m
etamodel

is transferred into an eclipse
plug
-
in in order to enable developers to define new conflict patterns.

5.

Conflict Patterns

Each side of left and ri
ght
models
includes
patterns in a case of a conflict.

6.

Version 1 of Model A

The right model input of Model A

7.

Version 2 of Model A

The left model input of Model A

1.1.

The scenario

The process here is to generate the conflict metamodel and then create conflict

patterns. These
conflict patterns could benefits developers specially if embedded in
MCM
s. That is done when
developers check in their models
with

server and the conflict patterns here are compared to the
models. If any match will be occurred, then simply

the
conflicts

could be shown again in a form
of model
s
. The basic idea of
“Everything is model”

is used in all parts of this scenario including
input models, difference models, conflict metamodel definitions, conflict pattern definitions and
conflict resu
lt. Comparing to the
general purpose SCM
text based

servers
;

this methodology is
very advanced
and based on models
.

O
n the other hand
it is
useful and simple for usage
among
MDE
developers

because

it
provides

them,

conflict resolution
automatically
.

7.

Imple
mentation

All the implementation has been done with ATLAS Transformation Language (ATL) languages.

In the field of MDE, ATL does the transformation between models. ATL is a Model to Model
(M2M) component inside the Eclipse Modeling Project (EMP)
.

Figure
8

shows the project folders and a view of eclipse source codes.


Figure
8
)

Eclipse project

One part of implementation is the

metamodel
Difference To

metamodel conflict
” transformation
.
Code
3

and
Code
4

show two rule
s

of this

transformation
.



M
odule

metamodelDifference2metamodelConflict;
--

Module Template

create

OUT : KM3
from

anyMetamodel
:KM3 ;


rule

Metamodel2Metamodel {


from



s: KM3!Metamodel




t
o



t: KM3!Metamodel(




contents <
-

s.contents



)

}


Code
3

) Modules for transformation models in ATL languages


ATL is not an imperative language. The elements of input models are compared to the types of
each rule. In a case tha
t a match occurs, that rule will be executed. Only one rule should be
matched for each set of entries.

The above module is the
main module developed in for

thesis. The aim here is to add a
conflict

definition

that is
actually a metamodel independent to the

existing difference metamodel. The
difference metamodel of a metamodel has been created automatically in the same solution from
the input metamodel. All metamodels confirm KM3 format
. KM3 is available in the eclipse
platform. Ecore is
an
other format the m
etamodels are usually defined with

and in that case one
transformation from
Ecore to KM3 is needed in order to give them as inputs for the
mentioned
transformation files.

I
nput of the module
is a difference

m
etamodel of any model and the output is the conf
lict
metamodel of that model.
The
first

solution is to hardcode the definition

of the conflict

in
the
ATL
file in a way that this definition will be added to the input difference metamodel and generates
the related conflict
metamodel
. This solution then is

not ind
ependent from conflict language
.

The
other solution is to
get two models as the input for the ATL file. One
input model
for the
difference metamodel and the other for the
conflict definition
. With the recent solution, the
conflict languages could b
e changed any time and there is no need to change the
transformation file.

The first solution is successfully implemented but the second one is done with an error of
referring

to the right model and still needs more efforts to be finished.

R
ule

Package2Pa
ckageDiff

{


from



s: KM3!Package



(




not

(s.name=

PrimitiveTypes

)



)


to



t: KM3!Package(




name <
-

s.name+

_AfterTransfer

,




contents <
-

Sequence





{





ConflictBlock,PatternBox,BooleanRestriction, DifferenceElement,
ConflictRelation, Con
flictEndLink, MetaData, IntegerProperty, StringProperty, BooleanProperty,





ReconcilationStrategy, Rule,


OCLExpression,OCLCriteriaExpression,
OCLRuleExpression,





s.contents





},




metamodel<
-

s.metamodel



)

Code
4
) Rules a
re activated
if
input
models are matched
with “from” part


The code above shows the rule where new elements have been added to the target model. All
the new elements like “Conflict Block” are then defined after that rule like the one bellow that we
used fo
r “
composedRules
”.

composedRules: KM3!Reference



(




name<
-

composedRules

,




package<
-
s.package,




isContainer<
-
false
,




owner<
-
OCLCriteriaExpression,




lower <
-

0,




upper<
-

1,




isOrdered <
-
false
,




isUnique <
-
false
,




type <
-
Rule



)

Code
5
)
Declaration of
composedRules

model in ATL;
composedRules

is Reference type in KM3

The other type of files used in the thesis is “Ant” files. For running and building an ATL solution
there is a need for a configuration that is usuall
y saved in the eclipse executable folders. In a
case that we do not want to set the configuration file again when we change the eclipse
workspace and for better visualizing the configuration setting, the “Ant” files are
used
.
Code
6

shows the ant file used in the project to run the “difference metamodel to conflict metamodel”
transformation.
S
ource model

and

target model are defined in this file. Also there are some
commands that can print some messages for “Console” window of the

eclipse which
has been

used.

<project

name=

BuildMetamodel


default=

transformAll

>


<target

name=

transformAll


depends=

loadModels

>





<antcall

target=

MetamodelDifference2MetamodelConflict


inheritall=

true


inheritrefs=

true

>




<param

name=

source


value=

/ModelDifference/Metamodels/NETDiff.km3

/>




<param

name=

target


value=

/ModelDifference/Metamodels/NET_Conflict.km3

/>




<param

name=

atl


value=

/ModelDifference/Transformations/test.atl

/>



</antcall>




</target>






<!

parameters: (sampl
e : String)



<target

name=

MetamodelDifference2MetamodelConflict

>



<echo

message=

Transforming ${source}

/>






<!

Load source models




<am3.loadModel

modelHandler=

EMF


name=

SimpleUMLModel


metamodel=

KM3


path=

${source}

>




<injector

name=

ebnf

>





<param

name=

name


value=

KM3

/>




</injector>





</am3.loadModel>






<!

Transform KM3 model into KM3Conflict model




<am3.atl

path=

${atl}

>




<inModel

name=

simpleUML


model=

SimpleUMLModel

/>




<inModel

name=

KM3


model=

KM3

/>




<outMod
el

name=

OUT


model=

KM3ConflictModel


metamodel=

KM3

/>



</am3.atl>




<!

Save target model




<echo

message=

Transforming ${target}

/>



<am3.saveModel

model=

KM3ConflictModel


path=

${target}

>






<extractor

name=

ebnf

>







<param

name=

format


v
alue=

KM3.tcs

/>






</extractor>



</am3.saveModel>







</target>





<target

name=

loadModels

>



<!

Load ATL metamodel






<am3.loadModel

modelHandler=

EMF


name=

ATL


metamodel=

MOF


path=

/ModelDifference/AMMATools/ATLT.ecore


/>




<!

Load KM3 m
etamodel




<am3.loadModel

modelHandler=

EMF


name=

KM3


metamodel=

MOF


nsUri=

http://www.eclipse.org/gmt/2005/KM3


/>









<!

Load TCS metamodel




<am3.loadModel

modelHandler=

EMF


name=

TCS


metamodel=

MOF


path=

/ModelDifference/AMMATools/TCS.eco
re


/>






<!

Load KM3
-
TCS model




<am3.loadModel

modelHandler=

EMF


name=

KM3.tcs


metamodel=

TCS


path=

/ModelDifference/AMMATools/KM3.tcs

>




<injector

name=

ebnf

>





<param

name=

name"

value=
"TCS"
/>




</injector>



</am3.loadModel>




</target>





</project>


Code
6
) Ant files are used to configure and build a solution or project in eclipse platform.

8.

Sample View

In this chapter a demonstration of the process that ends with simple conflicts is shown.

8.1
Models


The NET meta
model discussed already is a metamodel of a computer network.

To demonstrate
the ideas of the thesis we present the conflict detection scenario for a simple conflict of
concurrent versions of a model that confirms NET metamodel.

Figure
9

shows “Model A” that is changed by two developers.



Figure
9
)
Two

new version
s

of a model
, Version 1 has no more the Server Node, Version 2 has
added “Edge 2”
. There is

a conflict between two co
ncurrent versions of the same model.

Version 2

Version 1

Model A

Router

Switch

Edge 1

Router

Switch

Edge 1

Server

V1

V2

Router

Switch

Edge 1

Server

Edge 2

T
wo versions demonstrated in
Figure
9

are
both correct in a sense that there is no language
error in both cases
. Model A shows a network with three nodes and one edge. In version 1, the
“Server
” node has been
removed
and as there is no error (
compiler error or here language
error)

and

it
can

be uploaded to
the MCM server. On the other hand,
another developer
has
add
ed

a new edge to the existing model A. The V2 model shows the added edge.


The pr
oblem with these two versions is that a developer
has
added a new edge to the model
that depends on an existing node while another developer
has
deleted that node.

In this case a
conflict has been occurred.

To

detect conflicts we first make a difference m
odel of the two versions.

Then we define the
conflict pattern in the language of the conflict metamodel of the NET model. And finally we
should compare the two input difference model to the conflict patterns and detect the conflicts.

1.2.

Difference Model

The c
onflict metamodel has been already generated automatically with “MetaModelDiff to
MetaModelConflict” transformation
.

It
receives NETDiff metamodel and
the general
conflict
metamodel
as inputs
and generate
s

the NETConflict metamodel as described in previo
us
chapters. Similarly the NETDiff has been generated automatically from NET metamodel

with
“Metamodel to metamodelDiff” transformation
.


Figure
10
) Changes made for V1: Server Node is deleted

Figure
10

demonstrates the changes mage for making V1 out of Model A. As it is shown, a node
which is named “Server” has been deleted.

It confirms both “Node” and “Deleted”.
As discussed
already, version control programs only keep the changes. Similarly for V2

in
Figure
11
, there is
“ChangedNode” that confirms Changed and “AddedEdge” that confirms added. The
“ChangedNode” also has a reference to the new updated node which here is the “server” node.
The reference “edges” of the “server” node

holding “Edge2” as new member.



Figure
11
) Changes made for V2: Edge2 added and Server is updated


1.3.

Conflict Pattern

To be able to detect the conflict mentioned above, we should define the right and left patterns of
the two input

models in the language of NETConflict.


Several solutions are possible for defining
such a conflict. One simple solution is described

in
Figure
12
.


Figure
12
) Conflict Patterns in the language of metamo
del NET Conflict;
there

could be many
debates and research
possible
on the conflict language

and the reconciliation strategy
. The
current
conflict detecting
solution is independent from conflict languages and also

from

the
metamodel of the input model.

The

conflict patterns are not very well defined and there are better solutions to define them. The
conflict languages which are based on the left and right patterns are connected with a conflict
relation. In order to describe complicated conflicts, there is a

need for better conflict language.
Also the OCL expression is considered to express details. For solving the detecting problem a
reconciliation strategy is added to the model.


9.

Conclusion

and future works

Inspired by the concept of “Everything is model”,

we
have
proposed a conflict detection scenario
which could be applied in

MCM
s.


Some parts of the Conflict Detection scenarios
have

been

completed

but
there is a need to
develop other parts. Also
for developing MCM

for MDE, there is need for design
ing

an
architecture

based on Models.



Conflict
Metamodel
definition

Metamodel
of Model A

Merge

Conflict
Metamodel
of A

Generate
Eclips plug
-
in

Conflict
patterns

Eclipse
Plug
-
in

Define
Conflic
ts

DVersion 1
of Model A

DVersion 2
of Model A

Detect
Conflicts

Conflicts

Automated by
ATL engine

Done by an
expert

Figure
13
) Conflict detection scenario; the green parts are done in this thesis, the blue parts have
been
partially implemented and the red part should be done in future works.


Figure
13

shows the
status of the thesis
i
dea. Apart from the partial implemented parts and not
implemented parts of the “Conflict Detecting scenario”, there
are other

possible improvements

as follows:

1
-

Optimization in Conflict Languages used. For the “DeletedReferenced” conflict
that was discussed in previous chapter, there
are

other possible changes in the
model that result in the same conflicts. The language should en
able developers
to define a general template for those simple conflicts for all the languages.

2
-

Special Language for specifying the patterns and the reconciliation strategy.
There are some limitations with the usage of OCL as mentioned in [Graphic]. A
lan
guage that could be expressed in a form of models could fill the current
problems of using OCL.

3
-

Framework for MCM. There should be a framework for MCM
in a

way different
plug
-
ins like the conflict plug
-
in we
proposed
can be
integrated with

them
.

4
-

Extending
the idea of
automatically reconciliation strategy after conflict detection

is another field to be studied in future plans.



10.

References

[Antonio] Antonio Cicchetti, PHD Thesis, University of L’Aquila, Italy, “Difference Representation
and Conflict Manageme
nt in Model
-
Driven Engineering”

[Conflicts]
A. Cicchetti, D. Di Ruscio, and A. Pierantonio
; “
Managing model conflicts in
distributed development
”; IT department,
L’Aquila, Italy

[
Lifecycle
] Mohsen Asad and others, “
An MDA
-
based System Development Lifecycl
e
”, IEEE,
Modeling & Simulation, 2008. AICMS 08. Second Asia International Conference

[Power of Models]
Jean B´ezivin

“On the unification power of models”, 10 may 2005, published
on Springer

[
Patterns
]
Greenfield J, Short K (2003) Software factories Assemb
ling

Applications with
Patterns, Models, Frameworks and Tools.

In: OOPSLA’03, Anaheim, CA, Companion Volume,
pp 16

27

[MDA Spec] OMG, “MDA Specification”, available at
http://www.omg.org/mda/specs.htm

[
MDATech
]
ATHENA Consortium, “
Standards and technologie
s

, available

at

http://www.modelbased.net/mdi/mda/technologies.pdf

[
Version
]
“Meta
-
Modeling Based Version Control System for Software Diagrams”,
IEICE
TRANS. INF. & SYST., VOL.E89

D, NO.4 APRIL
2006,

available at
http://ietisy.oxfordjournals.org/cgi/repri
nt/E89
-
D/4/1390.pdf

[Argo] ArgoUML,
http://argouml.tigris.org/

[EclipseUML]
EclipseUML, http://www.omondo.com/

[Rational]
Rational Rose,http://www
-
6.ibm.com/jp/software/rational/

[
Konesa
]
Konesa,
http://www.canyonblue.com/

[Toward]
M. Saeki, “Toward automa
ted method engineering: Supporting

method assembly in
CAME,” in Engineering Methods to

Support Information Systems Evolution

EMSISE’03,
OOIS’03,http://cui.unige.ch/db
-
research/EMSISE03/2003

[Unified]
I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Soft
ware Development

Process,
Addison
-
Wesley, 1999.

[Graphic]
Dominik Stein, Stefan Hanenberg, and Rainer Unland
; “
A Graphical Notation to
Specify Model Queries

for MDA Transformations on UML Models
”,
University of Duisburg
-
Essen, Essen, Germany

[Eclipse]
ATL
homepage in eclipse,
http://www.eclipse.org/m2m/atl/

[Coloring]
OHST, D., WELLE, M., AND KELTER, U. Differences between versions of UML

diagrams. In ESEC/FSE
-
11: Proc. ESEC/FSE (2003), ACM Press, pp. 227

236.