Modelling complex system often results in di erent but overlapping modelling artifacts which evolve independently. Thus, inconsistencies may arise which lead to unintended e ects on the modelled system. To mitigate this situation, model synchronization is seen as a recurring and crucial maintenance task which requires to restore consistency between multiple models using the most suitable changes. Currently, di erent languages and tools are used for inter-model consistency management than for intra-model consistency where UML/OCL is an accepted solution. Consequently, the result of synchronizing models solely based on inter-model constraints might result into inappropriately evolved models w.r.t. intra-model constraints. In this paper, we present a synchronization model formalized in UML/OCL which covers explicit consistency and change models including costs and which considers both, inter-model and intra-model constraints at the same time. Instances of this synchronization model represent successful synchronization scenarios. In particular, models can be synchronized, also taking into account their predecessor versions, by nding a constraint violation-free extension of a partial model including those instances which may be optimized for minimal cost. We prototypically implemented this approach using a model nder to automatically retrieve synchronized models and the change operations to compute them by completing the partial model. model consistency; model synchronization; model evolution
Modern systems are inherently much more complex to
design, develop, and maintain than classical systems due
to di erent properties such as size, heterogeneity,
distribution, and multi-disciplinarity. One way to cope with such
complexity is by resorting on model-driven engineering
approaches [
There are already several approaches to handle model
integration based on synchronization [
In this paper, we propose a new methodology for unifying
inter-model and intra-model constraints for model
synchronization using UML/OCL. We employ OCL in the classical
setting for de ning intra-model constraints and present a
method how to de ne inter-model constraints based on
dedicated UML/OCL models between two models in the spirit of
bi-directional model transformation languages such as QVT
Relations [
The remainder of this paper is structured as follows. In Section 2 we describe the architecture of our synchronization approach, the types of models we consider, and the running example of this paper. In Section 3 we formulate model changes as a UML/OCL model and how to select the synchronization strategy by associating changes with cost functions. Subsequently, in Section 4 we describe how inter-model constraints can be expressed using a consistency model based on UML/OCL. In Section 5 we discuss the prototypical implementation of our approach to automatically nd model synchronizations. Finally, in Section 6 we discuss related work and conclude with an outlook in Section 7.
In this section, we introduce our model synchronization architecture by-example. 2.1
A synchronization problem, as depicted in Figure 1(a) and (b), occurs when two models, which were potentially consistent in their current state, are subsequently changed independently leading to potential inconsistencies. To synchronize both models, the goal is to nd a suitable set of changes for both models to make them consistent again. As there may be a huge amount of di erent change sets to reestablish consistency, the question also arises which one is the most appropriate change set for a given situation. Before we go into details on this aspect, we discuss the general architecture of our approach, in particular, how we represent the model synchronization problem by utilizing change and consistency models.
Former MLeftFormer MConsFormer MRightFormer
XLII fourty-two sameValue
Given MChangeFormer remove last "I" no change
Current MLeftCurrent
MRightCurrent (a) generalpattern
XLI
Wanted MChange
Reconciled
MLeft MCons MRight
XLI sameValue no change "two" → "one" fourty-two
fourty-one (b) concreteexample Figure 1: Model synchronizing using change models and consistency models: (a) general pattern and (b) concrete example.
In the following, we will describe the general architecture of our synchronization model as depicted in Figure 1. Our approach synchronizes models by consistently completing a synchronization model containing the history of the models (MLeftFormer; MRightFormer; MLeftCurrent and MRightCurrent), the previous consistency relation MConsFormer, which might not be a valid consistency relation in the current state, the previous change set MChangeFormer, the wanted state of the models MLeft and MRight with a consistency relation MCons and changes MChange leading to a consistent state. In general, model nders like the USE ModelValidator1 search for instances of a metamodel. A model nder can synchronize models by consistently completing synchronization models consisting of former and current models with consistent change and wanted models by adding new objects, associations and attributes. Since a model nder may complete the model in many ways, including the application of delete changes, in the extreme case to delete the complete model, we also foresee to model change costs to guide the model nder in the right direction. In the concrete example shown in Figure 1, the model nder may nd and add two change objects (no change; \two" ! \one") and two consistent state objects (XLI; forty-one).
Summing up, in contrast to many other approaches, we do not use explicit consistency restoring transformation rules 1https://sourceforge.net/projects/useocl/files/ Plugins/ModelValidator/ for synchronization, but just the declarative consistency models. Among others, this has the advantage that this approach is, in principle, not limited to synchronize two models, but any number of models, with or without circular consistency dependencies between them. Since both model states are considered at the same time, the typical problem of making model A consistent with model B, thus requiring additional changes in model B which themselves require additional changes in model A etc. can never occur. Also, we do not use any model di ng algorithm, but again a fully declarative change model, i.e., the constraints which have to hold for a model explaining the di erence between two model versions. We copy left, right and consistency model two times to build former and current model while removing all constraints, including multiplicity constraints. This is done to ensure that (i) the change model actually describes changes between model versions and (ii) the model nder can nd a consistent model extension de ning only the wanted model.
For completeness reasons please note when integrating left models and right models into global models, name clashes may occur. This can be simply avoided by pre- or post xing names of classes and properties. Since this step is trivial but might clutter the overall architecture and descriptions, it is not further discussed throughout the paper. 2.2
As a running example2, let us consider two viewpoints for developing and maintaining computer networks as depicted in Figure 2: (a) the requirements viewpoint and (b) the implementation viewpoint. The metamodels realizing these two viewpoints are illustrated in Figure 3. When taking a closer look on Figure 2, we see that the left model stores the requirements of a computer network. There are named machines which provide a certain amount of communication speed and others which consume a certain expected amount of data. The right part of Figure 2 contains a model of the implemented system which does not only include servers providing data and computers consuming data, but also routers and cables needed to transfer the data from servers to computers. There are two types of cables, namely GlassFiberCables for high-speed connections and CopperCables for low-speed connections. There are constraints on the right model to ensure that (i) each server can serve the cables it is connected to, (ii) each computer gets enough bandwidth for its needs and (iii) each router does not produce any data and thus can ful ll the outgoing bandwidth with the incoming bandwidth and its own processing speed.
For the given example, the models' consistency relationship is de ned such that each provider needs a server with the same name and at least that speed and each consumer needs a computer with the same name and the same speed and vice versa.
In Figure 2, also the evolution scenario for our running example is shown. It is assumes that the models were changed independently from each other. In the requirements model, the provider p1 should be made ready for the future and gets a higher speed. Thus, its speed attribute was increased from 3 to 4. At the same time in the implementation model changes were performed. It was discovered that the computer w2 was never used and thus it was removed together 2A slightly simpli ed version of the example can be downloaded from http://cosimo.big.tuwien.ac.at/ findsync/ with its connected cable l4. Now there are two violations w.r.t. the aforementioned consistency relationship: The speed of server s1 is not su cient and the consumer c2 has no correspondence on the right side. Of course, one now may come up with some reconciliation actions for this small example. One obvious model synchronization would be to delete consumer c2 in the requirements model and to set the speed variable to 4 for server s1. For larger examples, of course automation support is needed in order to reason about appropriate synchronizations. How this is realized by our approach following the previously described architecture is the content of the following sections.
Our change model approach consists of an abstract part
which is the same for all modeling languages and a
languagespeci c part which is generated for each used metamodel
individually. In general, we follow the ideas presented in [
Figure 4 shows the abstract structure of our change model.
There are two types of changes, namely atomic changes and
composite changes [
A composite change builds higher level changes from lower
level changes [
0..1 RevisedObject revised
Figure 4: Abstract change classes.
FeatureChange featureChanges *
MoveChange * moves
ChangeModel AmtoomveicFCrohman1ge 1 m*oavtoemToicChanges
castFrom 0..1 *GecnaestrsalCast
type: {Create,Delete,Preserve} 1 changeFrom
1 pastChange 1changeTo castTo 0..1
(e.g., [
Currently, these are the only composite changes supported, but others might be added in the future. Also, it is currently not possible to let a feature change explain features of multiple objects.
Beside the change model itself, the metamodel is duplicated twice as well where class and feature names are changed to avoid name clashes. In particular, all model classes and associations of the previous version might be su xed with Prev while the metamodel to store current objects and feature values is su xed with Ori and names do not change for the synchronized model.
Two parallel class hierarchies resembling the class hierarchy of the original metamodel are created. In the Changehierarchy, all classes are replicated with a Change pre xed name inheriting from AtomicChange. For every structural feature in the original class X , two structural features of the same type T named as the original structural feature attr plus a su x of Add and Del are created in the Changeclass as shown in List. 1. They denote which values have been added or deleted by the change operation. The Add attribute is derived as values which exist in the revised model, but not the original model and the Del attribute is derived as values which exist in the original model, but not the revised model. Unique features generate a Set type, non-unique features generate a Bag type. The derived attributes attrAddCostly and attrDelCostly contain unexplained addition and deletion changes. Associations are derived in a similar fashion. To ensure that added and deleted classes can be derived via set di erence, the change objects have to be used instead of the original objects, i.e. revised.attr.futureChange/original.attr.pastChange is used instead of revised.attr/original.attr.
List. 1: Change calculation for unordered features. context ChangeX: attrAdd: [Set|Bag](T) derived = if revised = null then [Set|Bag]{} else revised.attr-> asBag() endif - if original = null then [Set |Bag]{} else original.attr->asBag() endif attrDel: [Set|Bag](T) derived = if original = null then [Set|Bag]{} else original.attr-> asBag() endif - if revised = null then [Set| Bag]{} else revised.attr->asBag() endif attrAddExpl: [Set|Bag](T) derived = featureChanges.attrAddExpl->union( castChanges.attrExpl)->union(movedFrom.
attrExpl) attrDelExpl: [Set|Bag](T) derived = featureChanges.attrDelExpl->union( castChanges.attrExpl)->union(movedTo.
attrExpl) attrAddCostly: [Set|Bag](T) derived = attrAdd attrAddExpl attrDelCostly: [Set|Bag](T) derived = attrDel attrDelExpl
For every ordered structural feature, three additional features named as the original structural feature plus AddEl,
DelEl and Same are created in the Change class as shown in List. 2. The feature *Same contains a base feature value which is extended by inserting the values in *AddEl to get the revised feature value and extended by inserting the values in *DelEl to get the original feature value. The feature *Same has the same type as the original feature, but *AddEl and *DelEl are sequences of pairs of (Integer,T). List. 2 shows the connection between all features.
List. 2: Additional change calculation for ordered features. context ChangeX: attrAddEl: Sequence(Tuple{i: Integer, v: \myvar {T}}) attrDelEl: Sequence(Tuple{i: Integer, v: \myvar {T}}) attrSame: Sequence(T) attrMoved: Bag(T) derived = attrAddEl.v attrAdd attrMovedExpl: Bag(T) derived = featureChanges. attrMovedExpl->union(castChanges.
attrMovedExpl) inv orderedSequence: Set{attrAddEl,attrAddEl}-> forAll(s | s->isUnique(i) and s->sortedBy(i ) = s) inv addToRevised: (revised = null) or (revised. attr = attrAdd->iterate(t, full = <@attrSame | full->insertAt(t.i, t.v))) inv delFromOriginal: (original = null) or ( original.attr = attrDel->iterate(t, full = <@attrSame | full->insertAt(t.i, t.v)))
The sequence *Same is an auxiliary sequence that represents a common sequence between both ordered features. The feature attrAddEl contains not only elements which have been added to the revised feature from the original feature, but also elements which are not in the common sequence because they have changed their position. Elements which are moved are those which are not in the common sequence but whose value has not been added to the common bag as well. The constraints guarantee a certain order of insert applications and ensure that the original and revised feature value actually can be built as previously described. Unlike the change object above, these feature values are not necessarily directly determined by original and revised objects. In fact, the sequence in the attrSame feature might be too short; then too many moves are determined. However, a larger number of moves yields higher costs and thus a solution with less super uous moves will be preferred.
Each Change object also has a original and revised association of the corresponding classes in the original and the revised model which rede nes the original and revised association in AtomicChange to ensure the correct type.
Consider Figure 5 as example for an excerpt of the change model for atomic changes of our running example. Since Device contains a name attribute, ChangeDevice contains two attributes to de ne which names have been added and deleted. Also, the incoming and outgoing associations are used to connect to added and deleted cables. The class ChangeRouter adds two attributes for the maxSpeed. It does not replicate the name attribute changes since they are available in the superclass.
Let us now consider another excerpt of an instance of the change model as depicted in Figure 6. There are two original objects, the original cable oc1 and the original router or1. The cable has been deleted, so the speed attribute is deleted as well as the incoming connection. The router 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 deletion of router. The speed has not been changed, so no additions or deletions are de ned there. The fact that all constraints, including multiplicity constraints, are removed from all but the target model is indicated by the set-valued name and speed attributes for the original objects.
In the Cast class hierarchy similarities between cast objects are stored. For every structural feature in the original class, a structural feature of the same type named as the original structural feature plus a su x of Expl is created in the Cast class. It denotes which values are the same in both objects and is de ned by the intersection of values between original and revised object and thus explains those ostensible changes. List. 3 demonstrates the structure of Cast objects. An invariant ensures that the cast object is connected to a single object which is deleted and an object which is added.
context CastX: attrExpl: [Set|Bag](T) derived = castFrom.
attrDel->intersection(castTo.attrAdd) inv changeTypes: changeFrom.type = ChangeType.
Delete and changeTo.type = ChangeType.Create Consider Figure 7 for an example of such a cast change for our running example. The model has only changed by retyping oo1 from CopperCable to GlassFiberCable. This is expressed as two changes, namely deleting the CopperCable and creating a GlassFiberCable with the same values. Since the speed has not changed, the same value was deleted for the CopperCable that was added to the GlassFiberCable. Thus, the cast explains this value change and it is not considered for costs.
Similarly, a Move change for a certain aggregation attribute connects two change objects where an association to a certain object X was deleted in one object, but created in another object. However, there is no requirement that any object must be deleted or created. oc1:CopperCableOri speed = {4} original
futureChange cc1:ChangeCopperCable type = Delete speedAdd = {} speedDel = {4} speedAddExpl = {4} speedDelExpl = {4} speedAddCostly = {} speedDelCostly = {} rc1:CastCable speedExpl = {4} castFrom castTo changeFrom nc1:GlassFiberCable speed = {4} revised
pastChange cc2:ChangeGlassFiberCable type = Create speedAdd = {4} changeTo speedDel = {} speedAddExpl = {4} speedDelExpl = {4} speedAddCostly = {} speedDelCostly = {}
In the example depicted in Figure 8, an incoming edge was moved from the Router or1 to or2. The two router change objects show that the edge was deleted (cr1) and added (cr2). The move object m1 connects both changes. The intersection of incomingAdd for cr2 and incomingDel of cr1 is cc1, so this is the attribute change explained by the move object. Thus, it is also explained in both cr1 and cr2 and no change of incoming is a costly change.
For every operation O in a class X , a corresponding FeatureX_O class is created which inherits from FeatureX. This class contains an attribute for each operation parameter and it has a bidirectional association to the change class of the class the operation is de ned in. The postcondition of the operation X is converted into an invariant of the generated class by changing the self context of each @pre expression to the original object of the associated change while other self contexts are transferred to the revised object of the associated change. For features changed in the referenced object, this class contains a T[Add|Del]Expl attribute for each attribute in the original class. Postconditions which have the pattern feature = feature@pre->including([expr]) or feature = feature@pre->excluding([expr]) are converted into the invariant T[Add|Del]Expl = Set{[expr]}. Additionally, invariants are generated to ensure all features not occurring in any such postcondition are empty. An invariant is generated to let the cost attribute of the class be equal the operation result.
context Router::disconnectServer(c: Cable) post disconnectedIncoming: incoming = (
incoming@pre)->excluding(c) post disconnectedOutgoing: outgoing = (
outgoing@pre)->excluding(c)
This example shows a simple operation which just disconnects a single cable from a router. The postconditions state that after this operation has been called, the disconnected cable is not connected to the server any more.
List. 6: Translation of the change operation of List. 5 into the synchronization model class FeatureRouter attributes
... end class FeatureRouter_disconnectServer <
FeatureRouter constraints inv disconnectedIncoming: incomingDelExpl = Set {c} inv disconnectedOutgoing: outgoingDelExpl = Set {c} inv noChange: incomingAddExpl = Set{} and ... end association assoc_FeatureRouter_disconnectServer_c between FeatureRouter_disconnectServer[*] role
FeatureRouter_disconnectServer_c
ChangeCable[
This example is translated as shown in List. 6. For each postcondition with the speci ed pattern, an invariant is generated which explains the according changes. The third invariant guarantees that all other attributes are not changed due to this operation call. The operation parameter is translated as association. Like for atomic changes, a parameter of type Cable is translated to a ChangeCable.
While the change model describes what has changed, for synchronization purposes, the severity of changes should be known. To describe this aspect as well, a cost function is added to each Change-class. The speci cation of the exact cost function depends on the synchronization strategy. In we following, we discuss how di erent synchronization strategies can be implemented with our approach.
The least change [
class ChangeObject attributes costObject: Integer derived = if type =
ChangeType.Create or type = ChangeType.
Delete then if castTo != null then 0 else 1 endif else 0 endif end end class ChangeCable attributes costCable: Integer derived = speedAddCostly-> size() + speedDelCostly->size() + sourceAddCostly->size() + sourceDelCostly-> size() + targetAddCostly->size() + targetDelCostly->size() class CostSummer attributes cost = ChangeObject.allInstances().costObject-> sum() + ChangeCable.allInstances().
costObject->sum() + ... end
List. 7 shows an excerpt of the implementation of the least cost strategy for the running example. The cost of deleting or adding objects is de ned as attribute of the ChangeObject class. If an object is casted to another object, the cost is not accounted. The ChangeCable class calculates the cost by summing up the costs of its direct attributes. The CostSummer calculates the total costs by summing over all cost attributes.
Models might be representations of the real world where changes induce real costs, e.g., working time for switching cables or the costs of a new server. Then, it is natural to use a cost function resembling real costs. These costs will typically occur as operation costs.
List. 8: Domain-speci c cost calculation. context Router::disconnectServer(c: Cable) body: if c.isKindOf(CopperCable) then 5 else 10 endif ==> class FeatureRouter_disconnectServer attributes cost: Integer derived = if (c.revised.isKindOf(
CopperCable)) then 5 else 10 endif ...
List. 8 shows a simple example of operation costs. It might be more di cult to disconnect glass ber cables than to disconnect copper cables, so the costs could be twice as high. Such costs are transformed into an invariant as explained in the previous section.
If model A is considered more important than another model B, changes in model A should be avoided. By assigning much higher costs to changes in the model A, changes in model A are avoided but enforced in model B. For instance, this strategy may be also of relevance for the running example of this paper.
Usually, a model was modi ed for a good reason. Thus, the synchronization step should not return to the previous model version. To achieve that, additional costs can be introduced if some attributes in the target re-appear: (i) if they were deleted before or vice versa using the sum of symmetric di erence sizes of attrAdd and attrDelete of future and past change objects in the current model, (ii) if objects are deleted when they were created before by counting create/delete pairs, and (iii) if objects are created when they were deleted by counting created objects in the target model which are similar to deleted objects in the former model.
List. 9 shows a simple example for avoiding undos. Each attribute which is reassigned to the same value as before will induce a cost of 10 because both the old value is added which should not be the case and the newly set value is deleted. If an attribute whose value was changed has its value changed again the cost would only be 5. If an object is deleted which was created before, the cost increases by 100. Likewise, if an object is recreated which has the same name as an object which was deleted, the cost is increased by 200.
List. 9: Costs for avoiding undos. class ChangeRouter attributes avoidRedoCosts: Integer derived = if original. pastChange.type = ChangeType.Create then 5* original.pastChange.speedDel->intersection( speedAdd)->union(original.pastChange. speedAdd->intersection(speedDel))->size() +... else if type = ChangeType.Delete then 100 else 0 endif endif + if type = ChangeType.Create and ChangeRouterOri.allInstances()->select (c | c.type = ChangeType.Delete).original-> select(r | r.name = revised.name) then 200 else 0 endif end
A consistency model might be just descriptive or prescriptive. In the former case, changes in the consistency model should have no cost, while in the latter case, consistency model changes, especially deletions, might have high costs if the associated objects were not deleted.
Please note that there are design decisions to take which synchronization properties to de ne as constraints and which via costs. For example, undos could not only be avoided using costs as described in List. 9, but also by just using a constraint like in List. 10. However, then no synchronization would be possible at all if con icting model changes would have been performed which could only be resolved by undoing a change. This also holds in the case of asymmetric changes. If a model should never change, this model can just be used as target models with additional constraints that all attributes and associations should remain equal.
class ChangeRouter constraints inv avoidRedo: if original.pastChange.type = ChangeType.Create then type <> ChangeType. Delete and if original.pastChange.type = ChangeType.Delete then type <> ChangeType.
Create endif end
In this section, we will show how inter-model consistency
concerns are modeled with UML/OCL. In general, we
follow the main idea of triple graph grammars (TGGs) [
As we now show in this section, by using UML/OCL it is possible to describe the interconnection between models by additional associations, constraints and possibly even additional other elements such as classes and attributes.
Since we aim for a non-intrusive addition of synchronization logic, we assume open models or some form of module import, at least for de ning new associations. In the following, @override denotes the extension of the specied class with attributes and associations contained by the consistency model. We now show several examples how to employ UML/OCL to de ne consistency models in terms of correspondences.
One-to-one correspondences are easily de ned in UML/OCL by adding an association between the corresponding classes having as lower and upper bounds 1 on both ends. Figure 9 shows an example where classes correspond based on name equality. Such constraints can either be added to a class (as shown in graphical syntax) or added to the association (as shown in textual syntax) as preferred.
1 1 @override leftcon rightcon Consumer name = rightcon.name Figure 9: One-to-one correspondence between consumer and computer in graphical and textual syntax.
One-to-many correspondences can also be expressed by associations. Figure 10 shows an example where a server in the requirements model might correspond to a whole cluster in the implementation model. In particular, the constraint inv1 speci es that a single cluster provider corresponds to many nodes if all servers have exactly one router and nothing else as target of their outgoing cables. Then, all servers connected to this router constitute the cluster, else a provider corresponds to a single cluster.
1..* @override node Server let router = cluster.node.outgoing.target in if router->one(true) and router->one(r | r.oclIsTypeOf(Router)) then cluster.node = router.incoming.source else cluster.node->one(true) endif inv1 Figure 10: One-to-many correspondences between provider and server in graphical and textual syntax. association LRCon between
Consumer[
Computer[
inv: leftcon.name = rightcon.name end association LRSrv between
Provider[
Server[1..*] role node constraints
inv: <inv1> end
Many-to-many can also be expressed either by using nary associations of UML or by introducing additional classes which connect more than one class on both sides by associations. Figure 11 shows a more complex correspondence between provider and server. Servers may be either part of a typical cluster where a service is provided by multiple servers or part of a virtual cluster, where services may be assigned to many servers and each server might handle multiple services.
@Porovveirdriedre 1s.e.*rvice cluste1r ClusterAssoc c1luster 1..* @override node Server
TypicalCluster service->one(true) inv1 VirtualCluster * backupprovision
1 backup
A full consistency model may also contain dependencies between correspondences modeled as associations. Figure 11 shows that each virtual cluster requires a second virtual cluster as backup which must provide the all services.
The presented synchronization approach has been prototypically implemented as an USE plugin and can be downloaded from http://cosimo.big.tuwien.ac.at/findsync. While the consistency model has to be hand-crafted, the USE plugin merges the di erent involved models automatically, generates the change model, and nds the minimum cost synchronized models. To give an idea about the complexity of the automatically produced models, consider the running example of this paper for which the generated model contains 79 classes, 124 associations, and 379 invariants.
The costs are currently xed to a constant for each primitive change operation. Due to limitations in the USE model validator, some constraints and structures had to be reformulated and only set-typed features are supported. The optimization process is run by iteratively nding a model completion with less cost than the previously found solution. If the model nder is not able to nd any better solution, the cost-optimal solution has been found. Bounds have to be given for the number of instances of each class, thus costoptimality is only guaranteed with regards to these bounds. 5.1
We ran our performance evaluation using a simpli ed synchronization scenario of the one shown in Figure 2 on a Intel i5-6500 3.2 GHz machine with 64 GB RAM, running Ubuntu Linux 16.04. For simplicity reasons, all costs were assumed to be one.
3Version '15, available at: http://fmv.jku.at/ lingeling/lingeling-bal-2293bef-151109.tar.gz 4Version 2.2.0, available at: http://minisat.se/ downloads/minisat-2.2.0.tar.gz
5Version 2.3.1, integrated in the ModelValidator jar, available at: http://forge.ow2.org/project/download. php?group_id=228&file_id=17186 Solver
Table 1 shows the average runtime of three runs to nd any solution and a cost-minimal solution with di erent solvers. The runtimes vary greatly with each run, but still some trends can be observed. The runtimes also indicate that with the current state of the USE model validator, the approach cannot be directly used to nd a good synchronized instances within a reasonable time frame for large models. Still, we see a huge di erence between solvers. While lingeling and plingeling are quite fast nding the rst solution which already provide a good quality, Sat4J requires a longer time to nd any solution, but this rst solution is nearly the optimal one. MiniSat had quite some problems for the studied scenario. It produced did not produce appropriate solutions and went out of memory without nding the best solution.
In addition to computing synchronizations, we see also an alternative usage scenario for the presented approach. It can be also used to validate whether an existing synchronization found by another tool is a valid synchronization by using the validation capabilities of OCL. Here, the full approach can be used since USE is able to check all constraints used in the approach.
In the evaluation, we have only shown the general feasibility of the approach, but not that it is fast enough for larger instances. We assume that faster, maybe heuristic model nding approaches may signi cantly improve the performance but we do not have any concrete evidence for this yet. Thus, we can not claim that the performance can be actually improved in order that the approach scales to the synchronization of larger real-world models in the matter of minutes.
While transformation models using UML/OCL have been
already introduced back in 2006 [
There are also some existing approaches using constraint
solving for model synchronization such as the Janus
Transformation Language (JTL) [
There have been many change models proposed in the
literature, e.g., [
In this paper, we have shown how to transform the problem of model synchronization into the problem of de ning a suitable consistency model and a change model with UML/OCL. This can be used to check whether a given synchronization strategy was performed successfully and to nd synchronization strategies by model completion. As the evaluation has shown, the approach can be used to build an incremental transformation which is used for our approach itself. The approach has also been prototypically implemented which shows that automation is feasible.
In the future, we need to further develop both the
conceptual approach and the implementation. Sometimes, you
explicitly require a change in a model if a speci c change
happened in another model [
The performance and scalability of the implementation
has to be assessed in order to increase its practical
usefulness. Including optimization strategies in the USE model
validator for this problem, which has been done in the past
for similar problems, may increase the performance by
orders of magnitude and make this approach usable in practice.
Also, we need to evaluate in which cases, if any, a suitable
cost de nition could let our approach nd least surprising
changes [
Acknowledgment: This work has been funded by the Vienna Business Agency (Austria) within the COSIMO project (grant number 967327) and by the Christian Doppler Forschungsgesellschaft, the Federal Ministry of Economy, Family and Youth and the National Foundation for Research, Technology and Development, Austria. 9.