=Paper=
{{Paper
|id=Vol-1706/paper4
|storemode=property
|title=On Leveraging UML/OCL for Model Synchronization
|pdfUrl=https://ceur-ws.org/Vol-1706/paper4.pdf
|volume=Vol-1706
|authors=Robert Bill,Martin Gogolla,Manuel Wimmer
|dblpUrl=https://dblp.org/rec/conf/models/BillGW16
}}
==On Leveraging UML/OCL for Model Synchronization==
https://ceur-ws.org/Vol-1706/paper4.pdf
On Leveraging UML/OCL for Model Synchronization
Robert Bill Martin Gogolla Manuel Wimmer
TU Wien, Institute for Software Universität Bremen, TU Wien, Institute for Software
Technology and Interactive Department for Mathematics Technology and Interactive
Systems and Computer Science Systems
Favoritenstraße 9-11 PO Box 330440 Favoritenstraße 9-11
A-1110 Wien D-28334 Bremen A-1110 Wien
bill@big.tuwien.ac.at gogolla@tzi.de wimmer@big.tuwien.ac.at
ABSTRACT model synchronization has become an indispensable duty
Modelling complex system often results in different but over- where inconsistencies between different models need to be
lapping modelling artifacts which evolve independently. Thus, resolved in an efficient and correct way.
inconsistencies may arise which lead to unintended effects on There are already several approaches to handle model in-
the modelled system. To mitigate this situation, model syn- tegration based on synchronization [23]. However, there is a
chronization is seen as a recurring and crucial maintenance recurring pattern in most of these approaches: a dedicated
task which requires to restore consistency between multiple language is used to define a mix of synchronization steps
models using the most suitable changes. Currently, differ- and inter-model consistency relationships. There are two
ent languages and tools are used for inter-model consistency potential challenges using such approaches: (i) for consis-
management than for intra-model consistency where UM- tency relationship formulation, the intermingling of consis-
L/OCL is an accepted solution. Consequently, the result tency relationships and synchronization might make it diffi-
of synchronizing models solely based on inter-model con- cult to specify how to realize context-dependent resolutions
straints might result into inappropriately evolved models of inconsistencies in heavily constrained models, and (ii) the
w.r.t. intra-model constraints. increased mental load for modelers who need to learn a new
In this paper, we present a synchronization model for- synchronization language.
malized in UML/OCL which covers explicit consistency and In this paper, we propose a new methodology for unifying
change models including costs and which considers both, inter-model and intra-model constraints for model synchro-
inter-model and intra-model constraints at the same time. nization using UML/OCL. We employ OCL in the classical
Instances of this synchronization model represent success- setting for defining intra-model constraints and present a
ful synchronization scenarios. In particular, models can be method how to define inter-model constraints based on dedi-
synchronized, also taking into account their predecessor ver- cated UML/OCL models between two models in the spirit of
sions, by finding a constraint violation-free extension of a bi-directional model transformation languages such as QVT
partial model including those instances which may be op- Relations [25] or TGGs [30]. In order to define general-
timized for minimal cost. We prototypically implemented purpose and domain-specific synchronization properties, we
this approach using a model finder to automatically retrieve introduce a formalized change model that is the basis for ex-
synchronized models and the change operations to compute plicitly modeling such properties based on our UML/OCL
them by completing the partial model. approach. For instance, the use of different cost functions for
changes allows the definition and usage of different synchro-
nization strategies such as least-change and beyond. Hav-
Keywords ing these ingredients, UML/OCL based model finders can
model consistency; model synchronization; model evolution be employed to compute the model synchronizations taking
into account both inter-model and intra-model constraints
and the stated properties which should be fulfilled by the
1. INTRODUCTION synchronization. We show this by applying a model finder
Modern systems are inherently much more complex to for UML/OCL, which has already proven to be usable for
design, develop, and maintain than classical systems due transformations models [16].
to different properties such as size, heterogeneity, distribu- The remainder of this paper is structured as follows. In
tion, and multi-disciplinarity. One way to cope with such Section 2 we describe the architecture of our synchroniza-
complexity is by resorting on model-driven engineering ap- tion approach, the types of models we consider, and the
proaches [4,5] and dividing the engineering activities accord- running example of this paper. In Section 3 we formulate
ing to several areas of concerns or viewpoints, each one focus- model changes as a UML/OCL model and how to select
ing on a specific aspect of the system and allowing different the synchronization strategy by associating changes with
stakeholders to observe the system from different perspec- cost functions. Subsequently, in Section 4 we describe how
tives [26, 27]. There are more and more approaches which inter-model constraints can be expressed using a consistency
allow to define different views of a system resulting in par- model based on UML/OCL. In Section 5 we discuss the pro-
tially overlapping models. Unfortunately, this separation of totypical implementation of our approach to automatically
concerns by using different viewpoints, potentially expressed find model synchronizations. Finally, in Section 6 we discuss
in different domain-specific modeling languages, comes with related work and conclude with an outlook in Section 7.
the price of keeping those viewpoints consistent [13]. Thus,
20
2. MODEL SYNCHRONIZATION ARCHI- for synchronization, but just the declarative consistency mod-
TECTURE AND RUNNING EXAMPLE els. Among others, this has the advantage that this approach
is, in principle, not limited to synchronize two models, but
In this section, we introduce our model synchronization
any number of models, with or without circular consistency
architecture by-example.
dependencies between them. Since both model states are
considered at the same time, the typical problem of mak-
2.1 Model Synchronization Architecture ing model A consistent with model B, thus requiring addi-
A synchronization problem, as depicted in Figure 1(a) tional changes in model B which themselves require addi-
and (b), occurs when two models, which were potentially tional changes in model A etc. can never occur. Also, we do
consistent in their current state, are subsequently changed not use any model diffing algorithm, but again a fully declar-
independently leading to potential inconsistencies. To syn- ative change model, i.e., the constraints which have to hold
chronize both models, the goal is to find a suitable set of for a model explaining the difference between two model ver-
changes for both models to make them consistent again. As sions. We copy left, right and consistency model two times
there may be a huge amount of different change sets to re- to build former and current model while removing all con-
establish consistency, the question also arises which one is straints, including multiplicity constraints. This is done to
the most appropriate change set for a given situation. Be- ensure that (i) the change model actually describes changes
fore we go into details on this aspect, we discuss the general between model versions and (ii) the model finder can find a
architecture of our approach, in particular, how we repre- consistent model extension defining only the wanted model.
sent the model synchronization problem by utilizing change For completeness reasons please note when integrating left
and consistency models. models and right models into global models, name clashes
may occur. This can be simply avoided by pre- or postfixing
Given Wanted
Former Current Reconciled names of classes and properties. Since this step is trivial but
MLeftFormer MChangeFormer MLeftCurrent MChange MLeft might clutter the overall architecture and descriptions, it is
MConsFormer MCons not further discussed throughout the paper.
MRightFormer MRightCurrent MRight
2.2 Running Example
(a) general pattern
As a running example2 , let us consider two viewpoints for
XLII XLI XLI
remove no developing and maintaining computer networks as depicted
last "I" change in Figure 2: (a) the requirements viewpoint and (b) the im-
sameValue sameValue
no "two" →
plementation viewpoint. The metamodels realizing these
change "one" two viewpoints are illustrated in Figure 3. When taking a
fourty-two fourty-two fourty-one
closer look on Figure 2, we see that the left model stores
(b) concrete example the requirements of a computer network. There are named
Figure 1: Model synchronizing using change models and consis- machines which provide a certain amount of communica-
tency models: (a) general pattern and (b) concrete example.
tion speed and others which consume a certain expected
amount of data. The right part of Figure 2 contains a
In the following, we will describe the general architecture model of the implemented system which does not only in-
of our synchronization model as depicted in Figure 1. Our clude servers providing data and computers consuming data,
approach synchronizes models by consistently completing a but also routers and cables needed to transfer the data from
synchronization model containing the history of the models servers to computers. There are two types of cables, namely
(MLeftFormer , MRightFormer , MLeftCurrent and MRightCurrent ), the GlassFiberCables for high-speed connections and Copper-
previous consistency relation MConsFormer , which might not Cables for low-speed connections. There are constraints on
be a valid consistency relation in the current state, the pre- the right model to ensure that (i) each server can serve the
vious change set MChangeFormer , the wanted state of the cables it is connected to, (ii) each computer gets enough
models MLeft and MRight with a consistency relation MCons bandwidth for its needs and (iii) each router does not pro-
and changes MChange leading to a consistent state. In gen- duce any data and thus can fulfill the outgoing bandwidth
eral, model finders like the USE ModelValidator1 search with the incoming bandwidth and its own processing speed.
for instances of a metamodel. A model finder can syn- For the given example, the models’ consistency relation-
chronize models by consistently completing synchronization ship is defined such that each provider needs a server with
models consisting of former and current models with con- the same name and at least that speed and each consumer
sistent change and wanted models by adding new objects, needs a computer with the same name and the same speed
associations and attributes. Since a model finder may com- and vice versa.
plete the model in many ways, including the application of In Figure 2, also the evolution scenario for our running ex-
delete changes, in the extreme case to delete the complete ample is shown. It is assumes that the models were changed
model, we also foresee to model change costs to guide the independently from each other. In the requirements model,
model finder in the right direction. In the concrete example the provider p1 should be made ready for the future and
shown in Figure 1, the model finder may find and add two gets a higher speed. Thus, its speed attribute was increased
change objects (no change; “two” → “one”) and two consis- from 3 to 4. At the same time in the implementation model
tent state objects (XLI; forty-one). changes were performed. It was discovered that the com-
Summing up, in contrast to many other approaches, we puter w2 was never used and thus it was removed together
do not use explicit consistency restoring transformation rules
2
A slightly simplified version of the example can
1
https://sourceforge.net/projects/useocl/files/ be downloaded from http://cosimo.big.tuwien.ac.at/
Plugins/ModelValidator/ findsync/
21
p1:Provider p2:Provider s1:Server s2:Server
speed = 3 → 4 speed = 3 speed = 3 speed = 4
name = "s1" name = "s2" name = "s1" name = "s2"
source source
outgoing outgoing
h1:GlassFiberCable h2:GlassFiberCable
bandwidth = 4 bandwidth = 4
incoming incoming
target target
r1:Router r2:Router
speed = 4 speed = 4
name = "r1" name = "r2"
source source source
outgoing X outgoing
l1:CopperCable X l4:CopperCable l2:CopperCable
bandwidth = 2 bandwidth = 2 bandwidth = 2
incoming Xincoming incoming
target target target
c1:Consumer c2:Consumer c3:Consumer w1:Computer X w2:Computer w3:Computer
speed = 2 speed = 2 speed = 2 speed = 2 speed = 2 speed = 2
name = "pc1" name = "pc2" name = "pc3" name = "pc1" name = "pc2" name = "pc3"
(a) Requirements model (b) Implementation model
Figure 2: Example synchronization scenario: a requirements model, its corresponding implementation model, and their uncoordinated
evolution.
source outgoing
Agent
Device 1 * Cable ated, there is no original object. If an object is preserved,
speed: integer
fixed: boolean
name: string 1
*
bandwidth: integer there are both original and revised objects. In the change
speed: integer target incoming
model, every original object must specify what happens in
the future and every revised object must specify what hap-
Server Computer CopperCable
Provider Consumer pened to it in the past. For set-valued features, the set of
Router GlassFiberCable
future values must be equal to the set of past values with the
(a) Requirements model (b) Implementation model deleted values removed and the created features added. For
Figure 3: Metamodels of the running example: (a) requirements bag features, the number of occurrences of a future feature
metamodel and (b) implementation metamodel. must be equal to the occurrence count of this feature in the
past object plus the sum of all added feature counts minus
the sum of all deleted feature counts. For ordered features,
with its connected cable l4. Now there are two violations
the sequence resulting from the deletion of all deleted ele-
w.r.t. the aforementioned consistency relationship: The
ments from the past object feature must be the same as the
speed of server s1 is not sufficient and the consumer c2 has
sequence resulting from deleting all created elements from
no correspondence on the right side. Of course, one now
the future object feature which is expressed by inserting val-
may come up with some reconciliation actions for this small
ues at specific list indexes, sorted from bottom to top, to the
example. One obvious model synchronization would be to
common base sequence.
delete consumer c2 in the requirements model and to set
A composite change builds higher level changes from lower
the speed variable to 4 for server s1. For larger examples,
level changes [21]. For example, type changes cannot be di-
of course automation support is needed in order to reason
rectly represented with atomic changes. A general cast com-
about appropriate synchronizations. How this is realized by
bines an atomic delete change and an atomic create change
our approach following the previously described architecture
to express that semantically, the object has not been deleted
is the content of the following sections.
and another created, but the object is still the same. Sim-
ilarly, a general move combines an atomic feature delete
3. CHANGE MODEL change and an atomic feature create change for the same
Our change model approach consists of an abstract part feature and the same value to specify that the feature has
which is the same for all modeling languages and a language- moved and was not deleted and re-added. A feature change
specific part which is generated for each used metamodel in- is a composite change defined by an OCL operation which
dividually. In general, we follow the ideas presented in [9] takes several parameters and has a postcondition defining
to generate language specific change models to represent which changes are done to the object. The last change
changes between two models. However, we also go beyond type resembles composite changes as proposed in literature
the ideas presented in [9], by providing also the conditions
for finding a valid change model. Thus, we do not only ex-
CompositeChange
plicitly model the abstract syntax of change models but also
explicate their semantics in terms of OCL constraints.
FeatureChange MoveChange ChangeModel
3.1 Abstract Change Types featureChanges * * moves
1 moveTo
Figure 4 shows the abstract structure of our change model. original futureChange moveFrom 1
OriginalObject 0..1 1 AtomicChange * atomicChanges
There are two types of changes, namely atomic changes and type: {Create,Delete,Preserve} castFrom 0..1 * casts
1 changeFrom GeneralCast
composite changes [21]. An atomic change connects the 0..1
1 pastChange 1
changeTo castTo 0..1
RevisedObject revised
original object to the revised object. If an object has been
deleted, there is no revised object. If an object has been cre- Figure 4: Abstract change classes.
22
(e.g., [19]) while the others could also be semantically re- DelEl and Same are created in the Change class as shown
garded as atomic changes, but are regarded as composite in List. 2. The feature *Same contains a base feature value
changes from an implementation point of view. In principle, which is extended by inserting the values in *AddEl to get
such explained changes could be derived (semi-)automatically the revised feature value and extended by inserting the val-
for various postconditions [24]. If such technologies are used, ues in *DelEl to get the original feature value. The feature
only the cost remains to be specified. *Same has the same type as the original feature, but *AddEl
Currently, these are the only composite changes supported, and *DelEl are sequences of pairs of (Integer,T). List. 2
but others might be added in the future. Also, it is currently shows the connection between all features.
not possible to let a feature change explain features of mul-
List. 2: Additional change calculation for ordered features.
tiple objects.
context ChangeX:
3.2 Language-specific Change Language attrAddEl: Sequence(Tuple{i: Integer, v: \myvar
{T}})
Beside the change model itself, the metamodel is dupli- attrDelEl: Sequence(Tuple{i: Integer, v: \myvar
cated twice as well where class and feature names are changed {T}})
to avoid name clashes. In particular, all model classes and attrSame: Sequence(T)
associations of the previous version might be suffixed with attrMoved: Bag(T) derived = attrAddEl.v -
Prev while the metamodel to store current objects and fea- attrAdd
ture values is suffixed with Ori and names do not change for attrMovedExpl: Bag(T) derived = featureChanges.
attrMovedExpl->union(castChanges.
the synchronized model. attrMovedExpl)
Two parallel class hierarchies resembling the class hierar-
chy of the original metamodel are created. In the Change- inv orderedSequence: Set{attrAddEl,attrAddEl}->
hierarchy, all classes are replicated with a Change prefixed forAll(s | s->isUnique(i) and s->sortedBy(i
name inheriting from AtomicChange. For every structural ) = s)
feature in the original class X , two structural features of inv addToRevised: (revised = null) or (revised.
attr = attrAdd->iterate(t, full =
the same type T named as the original structural feature <@attrSame | full->insertAt(t.i, t.v)))
attr plus a suffix of Add and Del are created in the Change- inv delFromOriginal: (original = null) or (
class as shown in List. 1. They denote which values have original.attr = attrDel->iterate(t, full =
been added or deleted by the change operation. The Add <@attrSame | full->insertAt(t.i, t.v)))
attribute is derived as values which exist in the revised The sequence *Same is an auxiliary sequence that repre-
model, but not the original model and the Del attribute sents a common sequence between both ordered features.
is derived as values which exist in the original model, but The feature attrAddEl contains not only elements which
not the revised model. Unique features generate a Set type, have been added to the revised feature from the original
non-unique features generate a Bag type. The derived at- feature, but also elements which are not in the common se-
tributes attrAddCostly and attrDelCostly contain unex- quence because they have changed their position. Elements
plained addition and deletion changes. Associations are de- which are moved are those which are not in the common se-
rived in a similar fashion. To ensure that added and deleted quence but whose value has not been added to the common
classes can be derived via set difference, the change ob- bag as well. The constraints guarantee a certain order of
jects have to be used instead of the original objects, i.e. insert applications and ensure that the original and revised
revised.attr.futureChange/original.attr.pastChange feature value actually can be built as previously described.
is used instead of revised.attr /original.attr . Unlike the change object above, these feature values are not
necessarily directly determined by original and revised ob-
List. 1: Change calculation for unordered features. jects. In fact, the sequence in the attrSame feature might
context ChangeX: be too short; then too many moves are determined. How-
attrAdd: [Set|Bag](T) derived = if revised = ever, a larger number of moves yields higher costs and thus
null then [Set|Bag]{} else revised.attr-> a solution with less superfluous moves will be preferred.
asBag() endif - if original = null then [Set
|Bag]{} else original.attr->asBag() endif Each Change object also has a original and revised as-
attrDel: [Set|Bag](T) derived = if original = sociation of the corresponding classes in the original and the
null then [Set|Bag]{} else original.attr-> revised model which redefines the original and revised as-
asBag() endif - if revised = null then [Set| sociation in AtomicChange to ensure the correct type.
Bag]{} else revised.attr->asBag() endif Consider Figure 5 as example for an excerpt of the change
attrAddExpl: [Set|Bag](T) derived = model for atomic changes of our running example. Since
featureChanges.attrAddExpl->union(
castChanges.attrExpl)->union(movedFrom. Device contains a name attribute, ChangeDevice contains
attrExpl) two attributes to define which names have been added and
attrDelExpl: [Set|Bag](T) derived = deleted. Also, the incoming and outgoing associations are
featureChanges.attrDelExpl->union( used to connect to added and deleted cables. The class
castChanges.attrExpl)->union(movedTo. ChangeRouter adds two attributes for the maxSpeed. It does
attrExpl) not replicate the name attribute changes since they are avail-
attrAddCostly: [Set|Bag](T) derived = attrAdd -
attrAddExpl able in the superclass.
attrDelCostly: [Set|Bag](T) derived = attrDel - Let us now consider another excerpt of an instance of the
attrDelExpl change model as depicted in Figure 6. There are two orig-
inal objects, the original cable oc1 and the original router
For every ordered structural feature, three additional fea- or1. The cable has been deleted, so the speed attribute
tures named as the original structural feature plus AddEl, is deleted as well as the incoming connection. The router
23
original futureChange AtomicChange pastChange revised
Original Revised
0..1 1 1 1 Object
Object
incomingDel ChangeDevice_incomingDel ChangeDevice_incomingAdd incomingAdd
«redefines» «redefines»
CableOri * * ChangeDevice * * Cable
DeviceOri nameAdd: Set(string) Device
nameDel: Set(string)
* * * *
outgoingDel ChangeDevice_outgoingDel ChangeDevice_outgoingAdd outgoingAdd
«redefines» «redefines»
ChangeRouter
original futureChange maxSpeedAdd: Set(integer) pastChange revised
RouterOri Router
0..1 1 maxSpeedDel: Set(integer) 1 1
Figure 5: Change model excerpt 1 of the running example.
cc1:ChangeCable oc1:CopperCableOri nc1:GlassFiberCable
oc1:CopperCableOri original futureChange type = Delete speed = {4} speed = {4}
speed = {4} speedAdd = {} incomingDel rc1:CastCable
speedDel = {4} original revised
incoming speedExpl = {4}
ChangeDevice_incomingDel futureChange pastChange
cc1:ChangeCopperCable castFrom castTo cc2:ChangeGlassFiberCable
or1:RouterOri cr1:ChangeRouter rr1:Router
futureChange pastChange revised
name = {"router"} type = Preserve name = "routerOld" type = Delete type = Create
maxSpeed = {4}
original nameAdd = {"routerOld"} revised maxSpeed = 4 speedAdd = {} speedAdd = {4}
nameDel = {"router"} speedDel = {4} changeFrom changeTo speedDel = {}
maxSpeedAdd = {} speedAddExpl = {4} speedAddExpl = {4}
maxSpeedDel = {}
speedDelExpl = {4} speedDelExpl = {4}
speedAddCostly = {} speedAddCostly = {}
Figure 6: Change model excerpt 2 of the running example. speedDelCostly = {} speedDelCostly = {}
Figure 7: Cast change excerpt for the running example.
just has been taken out of usage, so its name was changed
to routerOld from router. In terms of attribute changes,
this equals the addition of routerOld to the name and the List. 4: Change calculation for moves
deletion of router. The speed has not been changed, so no context MoveX:
additions or deletions are defined there. The fact that all attrExpl: [Set|Bag](T) derived = moveFrom.
constraints, including multiplicity constraints, are removed attrDel->intersection(moveTo.attrAdd)
from all but the target model is indicated by the set-valued
name and speed attributes for the original objects. In the example depicted in Figure 8, an incoming edge
was moved from the Router or1 to or2. The two router
Composite changes. change objects show that the edge was deleted (cr1) and
In the Cast class hierarchy similarities between cast ob- added (cr2). The move object m1 connects both changes.
jects are stored. For every structural feature in the original The intersection of incomingAdd for cr2 and incomingDel
class, a structural feature of the same type named as the of cr1 is cc1, so this is the attribute change explained by
original structural feature plus a suffix of Expl is created the move object. Thus, it is also explained in both cr1 and
in the Cast class. It denotes which values are the same in cr2 and no change of incoming is a costly change.
both objects and is defined by the intersection of values be- For every operation O in a class X , a corresponding Fea-
tween original and revised object and thus explains those tureX_O class is created which inherits from FeatureX . This
ostensible changes. List. 3 demonstrates the structure of class contains an attribute for each operation parameter and
Cast objects. An invariant ensures that the cast object is it has a bidirectional association to the change class of the
connected to a single object which is deleted and an object class the operation is defined in. The postcondition of the
which is added. operation X is converted into an invariant of the generated
class by changing the self context of each @pre expression
List. 3: Change calculation for casts to the original object of the associated change while other
context CastX: self contexts are transferred to the revised object of the
attrExpl: [Set|Bag](T) derived = castFrom. associated change. For features changed in the referenced
attrDel->intersection(castTo.attrAdd) object, this class contains a T[Add|Del]Expl attribute for
inv changeTypes: changeFrom.type = ChangeType. each attribute in the original class. Postconditions which
Delete and changeTo.type = ChangeType.Create
have the pattern feature = feature@pre->including([expr])
Consider Figure 7 for an example of such a cast change or feature = feature@pre->excluding([expr]) are con-
for our running example. The model has only changed by verted into the invariant T[Add|Del]Expl = Set{[expr]}.
retyping oo1 from CopperCable to GlassFiberCable. This
is expressed as two changes, namely deleting the Copper- incomingAddExpl, incomingAdd
Cable and creating a GlassFiberCable with the same values. cc1:ChangeCopperCable
oc1:CopperCableOri
original type = Preserve
revised nc1:CopperCable
Since the speed has not changed, the same value was deleted incoming
futureChange
incomingDel,
pastChange
incomingExpl
for the CopperCable that was added to the GlassFiberCa- incomingDelExpl
ble. Thus, the cast explains this value change and it is not or1:RouterOri
original cr1:ChangeRouter revised nr1:Router
futureChange type = Preserve pastChange
considered for costs.
moveFrom movedTo
Similarly, a Move change for a certain aggregation at- m1:MoveRouter
type = Update
tribute connects two change objects where an association moveTo
movedFrom
incoming
to a certain object X was deleted in one object, but created or2:RouterOri
original cr2:ChangeRouter revised nr2:Router
in another object. However, there is no requirement that futureChange type = Preserve pastChange
any object must be deleted or created. Figure 8: Move change excerpt for the running example.
24
Additionally, invariants are generated to ensure all features a higher value instead of 1 to Delete or Create changes.
not occurring in any such postcondition are empty. An in- Positive costs ensure hippocraticness [32], i.e., that the syn-
variant is generated to let the cost attribute of the class be chronization does nothing for consistent models, because ev-
equal the operation result. ery change would have positive cost while consistent models
would require no change which has no and thus less cost.
List. 5: Simple change operation defined in UML/OCL.
context Router::disconnectServer(c: Cable) List. 7: Least change cost calculation.
post disconnectedIncoming: incoming = ( class ChangeObject
incoming@pre)->excluding(c) attributes
post disconnectedOutgoing: outgoing = ( costObject: Integer derived = if type =
outgoing@pre)->excluding(c) ChangeType.Create or type = ChangeType.
Delete then if castTo != null then 0 else 1
This example shows a simple operation which just discon- endif else 0 endif
nects a single cable from a router. The postconditions state end
that after this operation has been called, the disconnected
class ChangeCable
cable is not connected to the server any more. attributes
costCable: Integer derived = speedAddCostly->
List. 6: Translation of the change operation of List. 5 into the size() + speedDelCostly->size() +
synchronization model sourceAddCostly->size() + sourceDelCostly->
class FeatureRouter size() + targetAddCostly->size() +
attributes targetDelCostly->size()
... end
end
class CostSummer
class FeatureRouter_disconnectServer < attributes
FeatureRouter cost = ChangeObject.allInstances().costObject->
sum() + ChangeCable.allInstances().
constraints costObject->sum() + ...
inv disconnectedIncoming: incomingDelExpl = Set end
{c}
inv disconnectedOutgoing: outgoingDelExpl = Set List. 7 shows an excerpt of the implementation of the
{c} least cost strategy for the running example. The cost of
inv noChange: incomingAddExpl = Set{} and ... deleting or adding objects is defined as attribute of the
end
ChangeObject class. If an object is casted to another object,
association the cost is not accounted. The ChangeCable class calculates
assoc_FeatureRouter_disconnectServer_c the cost by summing up the costs of its direct attributes.
between The CostSummer calculates the total costs by summing over
FeatureRouter_disconnectServer[*] role all cost attributes.
FeatureRouter_disconnectServer_c
ChangeCable[1] role c
end Real costs.
Models might be representations of the real world where
This example is translated as shown in List. 6. For each changes induce real costs, e.g., working time for switching
postcondition with the specified pattern, an invariant is gen- cables or the costs of a new server. Then, it is natural to
erated which explains the according changes. The third in- use a cost function resembling real costs. These costs will
variant guarantees that all other attributes are not changed typically occur as operation costs.
due to this operation call. The operation parameter is trans-
lated as association. Like for atomic changes, a parameter List. 8: Domain-specific cost calculation.
of type Cable is translated to a ChangeCable. context Router::disconnectServer(c: Cable)
body: if c.isKindOf(CopperCable) then 5 else 10
3.3 Change Costs endif
While the change model describes what has changed, for ==>
class FeatureRouter_disconnectServer
synchronization purposes, the severity of changes should be attributes
known. To describe this aspect as well, a cost function is cost: Integer derived = if (c.revised.isKindOf(
added to each Change-class. The specification of the ex- CopperCable)) then 5 else 10 endif ...
act cost function depends on the synchronization strategy.
In we following, we discuss how different synchronization List. 8 shows a simple example of operation costs. It
strategies can be implemented with our approach. might be more difficult to disconnect glass fiber cables than
to disconnect copper cables, so the costs could be twice as
Least change. high. Such costs are transformed into an invariant as ex-
The least change [22] strategy cost function sums up the plained in the previous section.
size of all unexplained add and deletion collections in the
Change objects and adds 1 if the change type is Delete or Organizational asymmetry.
Create. If objects have been casted, one change should not If model A is considered more important than another
be counted. This function can be easily changed to sup- model B, changes in model A should be avoided. By assign-
port a least creation or least deletion strategy by adding ing much higher costs to changes in the model A, changes in
25
model A are avoided but enforced in model B. For instance, inv avoidRedo: if original.pastChange.type =
this strategy may be also of relevance for the running exam- ChangeType.Create then type <> ChangeType.
ple of this paper. Delete and if original.pastChange.type =
ChangeType.Delete then type <> ChangeType.
Create endif
Avoiding undos. end
Usually, a model was modified for a good reason. Thus,
the synchronization step should not return to the previous
model version. To achieve that, additional costs can be in-
troduced if some attributes in the target re-appear: (i) if 4. CONSISTENCY MODEL
they were deleted before or vice versa using the sum of sym- In this section, we will show how inter-model consistency
metric difference sizes of attrAdd and attrDelete of future concerns are modeled with UML/OCL. In general, we fol-
and past change objects in the current model, (ii) if objects low the main idea of triple graph grammars (TGGs) [30] and
are deleted when they were created before by counting cre- triple patterns [10] to build an explicitly modeled structure
ate/delete pairs, and (iii) if objects are created when they between two models. If the models are defined with UM-
were deleted by counting created objects in the target model L/OCL we end up with an unified representation for intra-
which are similar to deleted objects in the former model. and inter-model concerns.
List. 9 shows a simple example for avoiding undos. Each As we now show in this section, by using UML/OCL it is
attribute which is reassigned to the same value as before will possible to describe the interconnection between models by
induce a cost of 10 because both the old value is added which additional associations, constraints and possibly even addi-
should not be the case and the newly set value is deleted. If tional other elements such as classes and attributes.
an attribute whose value was changed has its value changed Since we aim for a non-intrusive addition of synchroniza-
again the cost would only be 5. If an object is deleted which tion logic, we assume open models or some form of mod-
was created before, the cost increases by 100. Likewise, if ule import, at least for defining new associations. In the
an object is recreated which has the same name as an object following, @override denotes the extension of the speci-
which was deleted, the cost is increased by 200. fied class with attributes and associations contained by the
consistency model. We now show several examples how to
List. 9: Costs for avoiding undos. employ UML/OCL to define consistency models in terms of
class ChangeRouter
correspondences.
attributes
avoidRedoCosts: Integer derived = if original. One-to-one correspondences.
pastChange.type = ChangeType.Create then 5* One-to-one correspondences are easily defined in UML/OCL
original.pastChange.speedDel->intersection( by adding an association between the corresponding classes
speedAdd)->union(original.pastChange.
speedAdd->intersection(speedDel))->size()
having as lower and upper bounds 1 on both ends. Figure 9
+... shows an example where classes correspond based on name
else if type = ChangeType.Delete then 100 else equality. Such constraints can either be added to a class (as
0 endif endif + if type = ChangeType.Create shown in graphical syntax) or added to the association (as
and ChangeRouterOri.allInstances()->select shown in textual syntax) as preferred.
(c | c.type = ChangeType.Delete).original->
select(r | r.name = revised.name) then 200 1 1 association LRCon between
else 0 endif @override leftcon rightcon @override Consumer[1] role leftcon
Consumer Computer Computer[1] role rightcon
end constraints
inv: leftcon.name = rightcon.name
end
name = rightcon.name
Retaining existing traces. Figure 9: One-to-one correspondence between consumer and com-
puter in graphical and textual syntax.
A consistency model might be just descriptive or prescrip-
tive. In the former case, changes in the consistency model One-to-many correspondences.
should have no cost, while in the latter case, consistency One-to-many correspondences can also be expressed by
model changes, especially deletions, might have high costs if associations. Figure 10 shows an example where a server in
the associated objects were not deleted. the requirements model might correspond to a whole cluster
Please note that there are design decisions to take which in the implementation model. In particular, the constraint
synchronization properties to define as constraints and which inv1 specifies that a single cluster provider corresponds to
via costs. For example, undos could not only be avoided us- many nodes if all servers have exactly one router and nothing
ing costs as described in List. 9, but also by just using a else as target of their outgoing cables. Then, all servers con-
constraint like in List. 10. However, then no synchroniza- nected to this router constitute the cluster, else a provider
tion would be possible at all if conflicting model changes corresponds to a single cluster.
would have been performed which could only be resolved by
undoing a change. This also holds in the case of asymmetric @override 1 @override association LRSrv between
1..*
changes. If a model should never change, this model can just Provider cluster node Server Provider[1] role cluster
Server[1..*] role node
be used as target models with additional constraints that all constraints
attributes and associations should remain equal. inv:
let router = cluster.node.outgoing.target in end
if router->one(true) and router->one(r |
r.oclIsTypeOf(Router)) then
List. 10: Constraints for avoiding undos. cluster.node = router.incoming.source else
cluster.node->one(true) endif inv1
class ChangeRouter Figure 10: One-to-many correspondences between provider and
constraints server in graphical and textual syntax.
26
Many-to-many correspondences. Solver Time (FS) Costs (FS) Time (OS)
Many-to-many can also be expressed either by using n-
lingeling3 4 min 52 sec 21 38 min
ary associations of UML or by introducing additional classes
plingeling3 6 min 26 sec 17 77 min
which connect more than one class on both sides by asso-
ciations. Figure 11 shows a more complex correspondence MiniSat4 8 min 49 sec 46 OOM
between provider and server. Servers may be either part Sat4J5 65 min 3 85 min
of a typical cluster where a service is provided by multi- Table 1: Execution times and costs for the running example (FS:
first solution, OS: optimal solution, the cost for producing the
ple servers or part of a virtual cluster, where services may
optimal solution is 2, OOM: out of memory).
be assigned to many servers and each server might handle
multiple services.
Table 1 shows the average runtime of three runs to find any
@override 1..* 1 ClusterAssoc 1 1..* @override
node
solution and a cost-minimal solution with different solvers.
Provider service cluster cluster Server
The runtimes vary greatly with each run, but still some
* backupprovision trends can be observed. The runtimes also indicate that
TypicalCluster VirtualCluster
service->one(true) inv1 1 backup
with the current state of the USE model validator, the ap-
proach cannot be directly used to find a good synchronized
backup != self and backup.service->
includesAll(service)
instances within a reasonable time frame for large models.
inv2
Figure 11: Many-to-many correspondences between provider and Still, we see a huge difference between solvers. While lin-
server in graphical syntax. geling and plingeling are quite fast finding the first solution
which already provide a good quality, Sat4J requires a longer
Correspondence dependencies. time to find any solution, but this first solution is nearly
A full consistency model may also contain dependencies the optimal one. MiniSat had quite some problems for the
between correspondences modeled as associations. Figure 11 studied scenario. It produced did not produce appropriate
shows that each virtual cluster requires a second virtual clus- solutions and went out of memory without finding the best
ter as backup which must provide the all services. solution.
In addition to computing synchronizations, we see also an
5. TOOL SUPPORT BASED ON THE USE alternative usage scenario for the presented approach. It can
be also used to validate whether an existing synchronization
MODEL VALIDATOR found by another tool is a valid synchronization by using
The presented synchronization approach has been proto- the validation capabilities of OCL. Here, the full approach
typically implemented as an USE plugin and can be down- can be used since USE is able to check all constraints used
loaded from http://cosimo.big.tuwien.ac.at/findsync. in the approach.
While the consistency model has to be hand-crafted, the
USE plugin merges the different involved models automat- 5.2 Threats to Validity
ically, generates the change model, and finds the minimum In the evaluation, we have only shown the general fea-
cost synchronized models. To give an idea about the com- sibility of the approach, but not that it is fast enough for
plexity of the automatically produced models, consider the larger instances. We assume that faster, maybe heuristic
running example of this paper for which the generated model model finding approaches may significantly improve the per-
contains 79 classes, 124 associations, and 379 invariants. formance but we do not have any concrete evidence for this
The costs are currently fixed to a constant for each primi- yet. Thus, we can not claim that the performance can be
tive change operation. Due to limitations in the USE model actually improved in order that the approach scales to the
validator, some constraints and structures had to be refor- synchronization of larger real-world models in the matter of
mulated and only set-typed features are supported. The minutes.
optimization process is run by iteratively finding a model
completion with less cost than the previously found solution.
If the model finder is not able to find any better solution, 6. RELATED WORK
the cost-optimal solution has been found. Bounds have to While transformation models using UML/OCL have been
be given for the number of instances of each class, thus cost- already introduced back in 2006 [3], to the best to our knowl-
optimality is only guaranteed with regards to these bounds. edge, the model synchronization aspect has not been consid-
ered in such type of models. However, since model synchro-
5.1 Evaluation nization is an important topic in model-driven engineering,
We ran our performance evaluation using a simplified syn- there is already a great variety of approaches to support
chronization scenario of the one shown in Figure 2 on a Intel different synchronization scenarios. For example, there is
i5-6500 3.2 GHz machine with 64 GB RAM, running Ubuntu specific work on model synchronization by specifying how
Linux 16.04. For simplicity reasons, all costs were assumed to deal with inconsistencies [2, 11, 14] and by using bidirec-
to be one. tional transformation languages. For instance, triple graph
3 grammars [20, 30] are often employed for model synchro-
Version ’15, available at: http://fmv.jku.at/
nization scenarios such as reported in [1,15,17]. In a similar
lingeling/lingeling-bal-2293bef-151109.tar.gz
4 fashion, QVT Relational [33] allows synchronization, also
Version 2.2.0, available at: http://minisat.se/
downloads/minisat-2.2.0.tar.gz in conjunction with unidirectional transformation languages
5
Version 2.3.1, integrated in the ModelValidator jar, such as ATL [22]. Furthermore, there are other, mostly
available at: http://forge.ow2.org/project/download. rule-based, approaches available (cf. [18] for a survey). One
php?group_id=228&file_id=17186 benefit of our approach when comparing it to existing work
27
is that we make use of an explicit change model which allows ness. Including optimization strategies in the USE model
to adjust the synchronization strategy in a domain-specific validator for this problem, which has been done in the past
way. for similar problems, may increase the performance by or-
There are also some existing approaches using constraint ders of magnitude and make this approach usable in practice.
solving for model synchronization such as the Janus Trans- Also, we need to evaluate in which cases, if any, a suitable
formation Language (JTL) [8], also with compressed state cost definition could let our approach find least surprising
space [12], and the CARE approach [29]. JTL [8] is using changes [7].
answer set programming (ASP) to find a synchronized re-
sult. In contrast to JTL, we do not map a relation-based
language into ASP, but we aim to describe everything with
8. ACKNOWLEDGMENTS
UML/OCL. In addition, we also provide a method to pre- Acknowledgment: This work has been funded by the Vi-
fer certain change results over others by having cost models enna Business Agency (Austria) within the COSIMO project
attached to change models. In previous work, we have pre- (grant number 967327) and by the Christian Doppler Forsch-
sented CARE [29], an approach using a constraint solver ungsgesellschaft, the Federal Ministry of Economy, Family
(ASP) to re-synchronize models with their evolving meta- and Youth and the National Foundation for Research, Tech-
models. However, CARE is a specific approach for the nology and Development, Austria.
metamodel/model co-evolution problem. The approach pre-
sented in this paper may be also employed in the future 9. REFERENCES
to reproduce the results of the CARE approach. An alter-
native approach for metamodel/model co-evolution is pre- [1] A. Anjorin, S. Rose, F. Deckwerth, and A. Schürr.
sented in [28] where the variability of different model mi- Efficient Model Synchronization with View Triple
gration solutions is formalized as a feature model. We see Graph Grammars. In Proceedings of the European
this research direction as an interesting line for future work Conference on Modelling Foundations and
as this would allow to concisely report equally good model Applications (ECMFA), volume 8569 of LNCS, pages
synchronization solutions, i.e., having the same cost, to the 1–17. Springer, 2014.
user. [2] G. Bergmann, I. Ráth, G. Varró, and D. Varró.
There have been many change models proposed in the Change-driven model transformations - change (in) the
literature, e.g., [6, 9, 31, 34]. However, to the best of our rule to rule the change. SoSyM, 11(3):431–461, 2012.
knowledge, we do not know any constraint-based approach [3] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault,
to define change models. I. Kurtev, and A. Lindow. Model transformations?
transformation models! In Proceedings of the
7. CONCLUSION AND FUTURE WORK International Conference on Model Driven
Engineering Languages and Systems (MODELS),
In this paper, we have shown how to transform the prob- volume 4199 of LNCS, pages 440–453. Springer, 2006.
lem of model synchronization into the problem of defining
[4] J. Bézivin, R. F. Paige, U. Aßmann, B. Rumpe, and
a suitable consistency model and a change model with UM-
D. C. Schmidt. Manifesto - model engineering for
L/OCL. This can be used to check whether a given synchro-
complex systems. CoRR, abs/1409.6591, 2014.
nization strategy was performed successfully and to find syn-
[5] M. Brambilla, J. Cabot, and M. Wimmer.
chronization strategies by model completion. As the evalu-
Model-Driven Software Engineering in Practice.
ation has shown, the approach can be used to build an in-
Morgan & Claypool, 2012.
cremental transformation which is used for our approach it-
self. The approach has also been prototypically implemented [6] E. J. Burger. Flexible views for view-based
which shows that automation is feasible. model-driven development. In Proceedings of the 18th
In the future, we need to further develop both the con- International Doctoral Symposium on Components
ceptual approach and the implementation. Sometimes, you and Architecture, pages 25–30. ACM, 2013.
explicitly require a change in a model if a specific change [7] J. Cheney, J. Gibbons, J. McKinna, and P. Stevens.
happened in another model [35]. Within this approach, Towards a principle of least surprise for bidirectional
this would correspond to a consistency model constraining transformations. In Proceedings of the 4th
change objects. A sensible consistency model or an alterna- International Workshop on Bidirectional
tive representation translated into a consistency model for Transformations co-located with Software Technologies:
that has to be found. The approach could be adapted to sup- Applications and Foundations, STAF 2015, L’Aquila,
port metamodel/model co-evolution by (i) translating the Italy, July 24, 2015., pages 66–80, 2015.
metamodel to a model a consistency relation between this [8] A. Cicchetti, D. Di Ruscio, R. Eramo, and
generated model and the model to co-evolve or (ii) allowing A. Pierantonio. JTL: A Bidirectional and Change
the target metamodel to differ from the source metamodel. Propagating Transformation Language. In Proceedings
The first approach would be more general since it would not of the International Conference on Software Language
only cover model evolutions based on metamodel changes Engineering (SLE), volume 6563 of LNCS, pages
but may also cover metamodel evolutions based on model 183–202. Springer, 2011.
changes, but at the same time more challenging since OCL [9] A. Cicchetti, D. Di Ruscio, and A. Pierantonio. A
constraints would have to be translated into a model and metamodel independent approach to difference
interpreted using OCL. Thus, we are currently evaluating representation. Journal of Object Technology,
the latter approach. 6(9):165–185, 2007.
The performance and scalability of the implementation [10] J. de Lara, E. Guerra, and P. Bottoni. Triple patterns:
has to be assessed in order to increase its practical useful- Compact specifications for the generation of
28
operational triple graph grammar rules. ECEASST, 6, classification of model repair approaches. CoRR,
2007. abs/1504.03947, 2015.
[11] R. Eramo, A. Pierantonio, J. R. Romero, and [24] P. Niemann, F. Hilken, M. Gogolla, and R. Wille.
A. Vallecillo. Change management in multi-viewpoint Assisted generation of frame conditions for formal
system using ASP. In Workshops Proceedings of the models. In Proceedings of the Design, Automation &
International IEEE Enterprise Distributed Object Test in Europe Conference & Exhibition (DATE),
Computing Conference (EDOCW), pages 433–440. pages 309–312, 2015.
IEEE, 2008. [25] Object Management Group. Meta Object Facility
[12] R. Eramo, A. Pierantonio, and G. Rosa. Managing (MOF) 2.0 Query/View/Transformation Specification.
uncertainty in bidirectional model transformations. In http://www.omg.org/spec/QVT/1.0/.
Proceedings of the ACM SIGPLAN International [26] J. E. Rivera, J. R. Romero, and A. Vallecillo.
Conference on Software Language Engineering (SLE), Behavior, time and viewpoint consistency: Three
pages 49–58, 2015. challenges for MDE. In Models in Software
[13] A. Finkelstein, D. M. Gabbay, A. Hunter, J. Kramer, Engineering, Reports and Revised Selected Papers of
and B. Nuseibeh. Inconsistency handling in Workshops and Symposia at MODELS 2008, pages
multi-perspective specifications. In Proceedings of the 60–65, 2008.
4th European Software Engineering Conference [27] J. R. Romero and A. Vallecillo. Well-formed rules for
(ESEC), volume 717 of LNCS, pages 84–99. Springer, viewpoint correspondences specification. In Workshops
1993. Proceedings of the 12th International IEEE Enterprise
[14] A. Finkelstein, D. M. Gabbay, A. Hunter, J. Kramer, Distributed Object Computing Conference (ECOCW),
and B. Nuseibeh. Inconsistency handling in pages 441–443, 2008.
multi-perspective specifications. IEEE Trans. Software [28] D. D. Ruscio, J. Etzlstorfer, L. Iovino, A. Pierantonio,
Eng., 20(8):569–578, 1994. and W. Schwinger. Supporting variability exploration
[15] H. Giese and R. Wagner. From model transformation and resolution during model migration. In Proceedings
to incremental bidirectional model synchronization. of the 12th European Conference on Modelling
SoSyM, 8(1):21–43, 2009. Foundations and Applications (ECMFA), volume 9764
[16] M. Gogolla, L. Hamann, and F. Hilken. On static and of LNCS, pages 231–246. Springer, 2016.
dynamic analysis of UML and OCL transformation [29] J. Schoenboeck, A. Kusel, J. Etzlstorfer,
models. In Proceedings of the Workshop on Analysis of E. Kapsammer, W. Schwinger, M. Wimmer, and
Model Transformations co-located with ACM/IEEE M. Wischenbart. CARE: A Constraint-based
17th International Conference on Model Driven Approach for Re-Establishing Conformance
Engineering Languages & Systems (MoDELS 2014), Relationships. In Proceedings of the 10th Asia-Pacific
pages 24–33, 2014. Conference on Conceptual Modelling (APCCM), pages
[17] F. Hermann, H. Ehrig, C. Ermel, and F. Orejas. 19–28. Australian Computer Society, 2014.
Concurrent Model Synchronization with Conflict [30] A. Schürr. Specification of graph translators with
Resolution Based on Triple Graph Grammars. In triple graph grammars. In Proceedings of the 20th
Proceedings of the International Conference on International Workshop on Graph-Theoretic Concepts
Fundamental Approaches to Software Engineering in Computer Science (WG), pages 151–163, 1994.
(FASE), volume 7212 of LNCS, pages 178–193. [31] C. Seidl, I. Schaefer, and U. Aßmann. Deltaecore - A
Springer, 2012. model-based delta language generation framework. In
[18] S. Hidaka, M. Tisi, J. Cabot, and Z. Hu. Feature-based Proceedings of Modellierung, pages 81–96, 2014.
classification of bidirectional transformation [32] P. Stevens. Towards an algebraic theory of
approaches. SoSyM, 15(3):907–928, 2016. bidirectional transformations. In Proceedings of the 4th
[19] M. Javed, Y. M. Abgaz, and C. Paul. Composite International Conference on Graph Transformations
ontology change operators and their customizable (ICGT), pages 1–17, 2008.
evolution strategies. In Proceedings of the 2nd Joint [33] P. Stevens. Bidirectional model transformations in
Workshop on Knowledge Evolution and Ontology QVT: semantic issues and open questions. SoSyM,
Dynamics (EvoDyn), pages 1–12. CEUR-WS.org, 9(1):7–20, 2009.
2012. [34] G. Taentzer, C. Ermel, P. Langer, and M. Wimmer. A
[20] E. Kindler and R. Wagner. Triple graph grammars: fundamental approach to model versioning based on
Concepts, extensions, implementations, and graph modifications: from theory to implementation.
application scenarios. Technical report, tr-ri-07-284, SoSyM, 13(1):239–272, 2014.
University of Paderborn, 2007. [35] M. Wimmer, N. Moreno, and A. Vallecillo. Viewpoint
[21] P. Langer, M. Wimmer, P. Brosch, co-evolution through coarse-grained changes and
M. Herrmannsdörfer, M. Seidl, K. Wieland, and coupled transformations. In Proceedings of the
G. Kappel. A posteriori operation detection in International Conference on Objects, Models,
evolving software models. Journal of Systems and Components, Patterns (TOOLS), volume 7304 of
Software, 86(2):551–566, 2013. LNCS, pages 336–352. Springer, 2012.
[22] N. Macedo and A. Cunha. Least-change bidirectional
model transformation with QVT-R and ATL. SoSyM,
pages 1–28, 2014.
[23] N. Macedo, J. Tiago, and A. Cunha. A feature-based
29