Jose E. Rivera, Antonio Vallecillo Universidad de Málaga, Spain TOOLS Europe 2008, Zurich.

Representing and Operating with Model Differences

Jose E. Rivera, Antonio Vallecillo

Universidad de Málaga, Spain

TOOLS Europe 2008, Zurich

TOOLS Europe 2008(2) June 30, 2008

IntroductionIntroduction Model-Driven Software Development (MDSD)

● Models are the key artifacts● Most of the efforts are currently on the definition of

models, metamodels and transformations between them

● Other model operations (e.g., model subtyping, model difference) are required in MDSD practices

Model difference● An essential operation in several software

development processes: Version and change management Software evolution Model/data integration etc.


Model difference solutionsModel difference solutions Previous approaches:

●Edit scripts and coloring techniques: Do not produce models as results Do not fulfill other interesting properties

(composability…) ●Based on text, data structures or models

Usually restricted to a specific metamodel (UML) Our approach:

● Model-based: Differences are models, conforming to a metamodel

● Metamodel independent● Self-contained, compact, composable, applicable to

models conforming to different metamodel● Implementation available integrated in Eclipse

MAUDELINMAUDELINGG


Model comparisonModel comparison1) Matching

● Finding different objects from the two models that represent the same element

● The result is a model:

2) Differencing● Makes use of matching models to detect modified

elements● The result is a model:

Benefits:

Self-containedCompactIndependent of the metamodel of the source models


Matching ObjectsMatching Objects

Option 1: Using object persistent identifiers Matching process is simple and robust

But not always feasible!

Option 2: Using structural similarities Allows comparing models…

that do not use persistent object identifiers conforming to different metamodels that have evolved independently

Harder to define and implement You need an algorithm to identify the matches


The Matching AlgorithmThe Matching Algorithm

Compares objects independently of their depth in the containment tree●Implies more comparisons ●...but brings very interesting advantages:

Moved elements through different levels can be detected; Example of refactorization-> adding packages

Failing to identify a match does not condition other potential matches below in the tree hierarchy

Implemented in MaudeMAUDELINMAUDELIN

GG


The Matching AlgorithmThe Matching Algorithm Comparing two objects:

● Class rate:

● Name rate:


Matching Algorithm: Structural Matching Algorithm: Structural raterate Structural rate depends on the type of the feature

● Boolean attributes and enumerations match (with rate = 1.0) if they have the same value (otherwise rate = 0.0)

● String attribute values distances are calculated using the Levenshtein distance

● Numerical attribute values match rate is computed with a relative distance function (1-|n-m|/|n+m|) limited to [0..1]

● References are matched recursively, i.e., objects referenced are compared using the same match operation but without taking into account their own references (to avoid cycles)

If the upper cardinality is greater than 1 (i.e., if its value is a collection), the average rate is calculated

If a structural feature is defined only in one of the

objects, a penalty is applied to the final sfRate


Matching Algorithm: AnalysisMatching Algorithm: Analysis

If (Rate > Threshold) the two objects potentially match

Initially considered (although it is fully configurable): wc = 0.5; wsf = 0.25; wn = 0.0; Threshold = 0.66

nameRate is used in models in which the attribute name is considered as an identifier. ● If the name rate is omitted (wn=0.0), potential matches

are harder: features should be more strongly related

At the end of the process, only those objects that together obtain the biggest rate are kept


Maude (Maude (http://maude.cs.uiuc.edu/)http://maude.cs.uiuc.edu/)

Formal notation and system● High-level language and a high-performance

interpreter and compiler of the OBJ algebraic specification family

● Supports membership equational and rewriting logic specification and programming

● Maude specifications are executable

Supported by a toolkit● Executing the specifications, model-checking, theorem

proving, termination and confluence, etc.

Highly efficient and integrated with Eclipse


Representing Representing ModelsModels in Maude in Maude Maude supports OO specifications and computations

● Classes: class C | a1 : S1, …., an : Sn● Objects: < O : C | a1 : v1, …., an : vn >● Messages: msg m : S1 … Sn -> Msg .● A configuration is a multiset of objects and messages that

evolves by rewriting rules

Models are represented as configuration of objects

Nodes

Nodes’ attributes

Nodes’ Edges

Objects

Objects’ attributes

MultigraphMaude Configuration of

objects


Representing Representing MetamodelsMetamodels in in MaudeMaude Object-oriented modules (i.e., specifications)

● They contain the classes to which the Maude objects belong

● Models conform to metamodels by construction● Used to instantiate models, to add behavior…

Metamodels are models too!● They can be represented as Configuration of objects

The classes of such objects will be the ones that specify the meta-metamodels (for example Ecore)

Used to operate and reason about them


(omod SimpleStateMachines is pr STRING . class State | name : String, stateMachine : Oid, incoming : Set{Oid}, outgoing : Set{Oid} . class StateMachine | initialState : Maybe{Oid}, containedState : Set{Oid} . class Transition | name : String, target : Oid, src : Oid .endom)

Models and Metamodels in Models and Metamodels in MaudeMaude Simple State Machine example

membership axioms

< ’SM : StateMachine | initialState : ’ST1, containedStates : (’ST1, ’ST2) >< ’ST1 : State | name : "St1", stateMachine : ’SM, outgoing : ’TR, incoming : empty >< ’ST2 : State | name : "St2", stateMachine : ’SM, incoming : ’TR, outgoing : empty >< ’TR : Transition | name : "Tr", src : ’ST1, target : ’ST2 >

Conforms to

+


Calculation of Differences op modelDiff : Configuration Configuration -> DiffModel .

Possible situations :●The element appears in both models and has not

been modified

●The element appears in both models but has been modified;

ceq modelDiff(< O1 : C | ATTS > CONF1> < O2 : C | ATTS > CONF2, MATCHM) = modelDiff(CONF1, CONF2, MATCHM) if match(O1, O2, MATCHM) .

ceq modelDiff( < O1 : C1 | ATTS1 > CONF1, < O2 : C2 | ATTS2 > CONF2, MATCHM)= < newModId(O1) : ModifiedElement | element : newId(O1), oldElement : oldId(O2) > < newId(O1) : C1 | attsDiff(ATTS1,ATTS2) > < oldId(O2) : C2 | attsDiff(ATTS2,ATTS1) > modelDiff(CONF1,CONF2,MATCHM)if match(O1, O2, MATCHM) /\ (not(ATTS1 == ATTS2) or not(C1 == C2)) .


Calculation of Differences●The element only appears in the minuend model;

●The element only appears in the subtrahend model.

●Both the minuend and subtrahend models are empty:

eq modelDiff( < O1 : C1 | ATTS1 > CONF1, CONF2, MATCHM )= < newAddId(O1) : AddedElement | element : newId(O1) > < newId(O1) : C1 | ATTS1 > modelDiff(CONF1, CONF2, MATCHM) [owise] .

eq modelDiff( CONF1, < O2 : C2 | ATTS2 > CONF2, MATCHM )= < newDelId(O2) : DeletedElement | element : oldId(O2) > < oldId(O2) : C2 | ATTS2 > modelDiff(CONF1, CONF2, MATCHM) [owise] .

eq modelDiff( none, none, MATCHMODEL ) = none .


An ExampleAn Example

< ’SM : StateMachine | initialState : ’ST1, containedStates : (’ST1, ’ST2) >< ’ST1 : State | name : "St1", stateMachine : ’SM, outgoing : ’TR, incoming : empty >< ’ST2 : State | name : "St2", stateMachine : ’SM, outgoing : empty, incoming : ’TR >< ’TR : Transition | name : "Tr", src : ’ST1, target : ’ST2 >

< ’SM : StateMachine | initialState : ’ST1, containedState : (’ST1, ’ST2) >< ’ST1 : State | name : "St1", stateMachine : ’SM, outgoing : ’TR, incoming : ‘TR2 >< ’ST2 : State | name : "St2", stateMachine : ’SM, outgoing : ’TR2, incoming : TR >< ’TR : Transition | name : "Tr", src : ’ST1 , target : ’ST2 >< ’TR2 : Transition | name : "Tr2", src : ’ST2 , target : ’ST1 >

(Minuend Model)

(Subtrahend Model)

Tr2

< 'ST1@MOD : ModifiedElement | element : 'ST1@NEW, oldElement : 'ST1@OLD> < 'ST1@NEW : State | incoming : 'TR2 > < 'ST1@OLD : State | incoming : empty >< 'ST2@MOD : ModifiedElement | element : 'ST2@NEW, oldElement : 'ST2@OLD > < 'ST2@NEW : State | outgoing : 'TR2 > < 'ST2@OLD : State | outgoing : empty >< 'TR2@ADD : AddedElement | element : 'TR2@NEW > < 'TR2@NEW : Transition | name : "Tr2", src : 'ST2, target : 'ST1 >

(Difference Model)


Further OperationsFurther Operations Operation do

● do ( Ms , Md ) = Mm .● Applies to a model all the changes specified in a

difference model

Operation undo● undo ( Mm , Md ) = Ms .● Reverts all the changes specified in a difference model

Sequential composition of differences● Very useful to, e.g., optimize the process of applying

successive modifications to the same model

undo(do(Ms, Md), Md) = Ms . do(undo(Mm, Md), Md) = Mm.


““do” operation specificationdo” operation specificationop do : Configuration DiffModel -> Configuration .

eq do ( MODEL, < O : AddedElement | element : NEWO >< NEWO : NEWC | NEWATTS > CONF )

= < originalId(NEWO) : NEWC | NEWATTS > do ( MODEL, CONF ) .

ceq do (< O : C | ATTS > MODEL, < O2 : DeletedElement | element : OLDO >< OLDO : OLDC | OLDATTS > CONF )

= do ( MODEL, CONF ) if O = originalId(OLDO) .

ceq do (< O : C | ATTS > MODEL,< O2 : ModifiedElement | element : NEWO, oldElement : OLDO >< NEWO : NEWC | NEWATTS > < OLDO : OLDC | OLDATTS >

CONF ) = < originalId(NEWO) : NEWC | (excludingAll(ATTS,OLDATTS), NEWATTS)) > do(MODEL, CONF)

if O = originalId(OLDO) .

eq do ( MODEL, none ) = MODEL .


ConclusionsConclusions Model difference definition

● Independent of the metamodel of the source models● Can be fully integrated into other MDSD processes ● Self-contained and compact● Applicable to models conforming to different metamodel● Suitable for composing deltas and implementing further

operations on them● Results are very encouraging

Tool support:● All the difference operations implemented in Maude● Integrated in Eclipse

MAUDELINMAUDELINGG


Future WorkFuture Work Make Maude completely transparent to the user

Conflict detection and resolution of concurrent modifications

Improving the matching algorithm● More complex heuristics ● More customizable parameters

Make model operations available via Web services

Date post:	14-Dec-2015
Category:	Documents
Upload:	lyric-way
View:	213 times
Download:	0 times

Jose E. Rivera, Antonio Vallecillo Universidad de Málaga, Spain TOOLS Europe 2008, Zurich.

Documents