Adapting Difference Models to the Eclipse Platform

In Maude, objects may have references to non-accessible elements. For instance, modified, added and deleted elements of difference models (contained by the element and oldElement references) may refer to other objects that are not contained in the difference model but in one of the operand (subtrahend or minuend) models. If we remove, for example, the minuend model, and keep the subtrahend and difference models, the references from difference elements to objects of the minuend model will be kept. Then, whenever we apply the dooperation to the subtrahend and difference models, we will recover the minuend model and the dangling references will become valid references again.

However, EMF editors do not work like that: they do not allow editing models with dan-gling references. If we, e.g., delete one of the difference operand models, the difference model may become invalid, and therefore we need to maintain minuend and subtrahend models in order to have a valid difference model.

Thus, we have defined a mechanism to adapt our difference approach to the Eclipse plat-form taking into account these considerations. We have created a new Difference metamodel where difference elements will not contain the modified, added, and deleted elements anymore but they will have just an (intermodel) reference to them (note that in Eclipse we will have to maintain the difference operand models, so it makes no sense for the difference model to contain these elements too). In fact, the only difference with respect to the Difference meta-model shown in Figure 5.1 is that theelementandoldElementreferences are not containments.

Then, to transform models conforming to the previous Difference metamodel (specified in the Maude platform) to this new one (specified in the Eclipse platform), we have specified an ATL model transformation from Maude to EMF that adapt difference models to this new

represen-tation. This transformation has been defined making use of the Ecore2ATL transformation: we selected the previous Difference metamodel as input, and we adapted the resulting transforma-tion to set these new intermodel references properly:

module DifferenceRepresentation; -- Module Template

c r e a t e OUT : Difference from IN : Maude , SUB : Ecore1 , MIN : Ecore2 ;

u s e s Maude2ModelLib; . . .

r u l e ”Difference : : ModifiedElement” { from

rt : Maude ! RecTerm

( rt . op = thisModule . object and rt. isTypeOf (’@Object’) and rt. belongsTo (’ModifiedElement@Difference’) ) u s i n g{

oid_element : S t r i n g = rt . listVariable (’element’)−>first ( ) . originalOid ( ) ; oid_oldElement : S t r i n g = rt . listVariable (’oldElement’)−>first ( ) . originalOid ( ) ; }

t o

cl : Difference ! ModifiedElement ( ) do{

cl. refSetValue (’element’, Ecore2 ! EObject . getInstanceById (’MIN’, oid_element ) ) ; cl. refSetValue (’oldElement’, Ecore1 ! EObject . getInstanceById (’SUB’, oid_oldElement ) ) ; }

}

r u l e ”Difference : : DeletedElement” { from

rt : Maude ! RecTerm

( rt . op = thisModule . object and rt . isTypeOf (’@Object’) and rt. belongsTo (’DeletedElement@Difference’) ) u s i n g{

oid_element : S t r i n g = rt . listVariable (’element’)−>first ( ) . originalOid ( ) ; }

t o

cl : Difference ! DeletedElement ( ) do{

cl. refSetValue (’element’, Ecore1 ! EObject . getInstanceById (’SUB’, oid_element ) ) ; } and rt. belongsTo (’AddedElement@Difference’) ) u s i n g{

oid_element : S t r i n g = rt . listVariable (’element’)−>first ( ) . originalOid ( ) ; }

t o

cl : Difference ! AddedElement ( ) do{

cl. refSetValue (’element’, Ecore2 ! EObject . getInstanceById (’MIN’, oid_element ) ) ; }

}

Note that we have added two additional input models:MINandSUB, that represent the min-uend and subtrahend models, respectively. They are needed to get their corresponding added, deleted or modified objects. These objects will be obtained by means of the getInstanceById ATL operation, which looks for them by their identifiers. Once we get these objects, we can set the value of theelementreference of the created difference elements (and the value of the odlElementreference in case ofModifiedElements) properly by making use of therefSetValue ATL operation.

5.5 Related Work

There is quite a large number of contributions on the importance of model management, the operations required to deal with models and metamodels, and algorithms to implement such operations. For instance, there is the work by X. Blanc on the Model Bus [23], or the work by Bernstein on Model Management [20] on how model operations can help addressing classical meta-data management problems such as schema integration, schema evolution, and round-trip engineering. Many people have mentioned the importance of counting on model management operations such as model subtyping, match, merge, diff, compose, or apply, and some other people have developed algorithms for implementing some of these operations. Most of these implementations have been independently developed, although some of them have tried to deal with them on a unified and general way (e.g., [13, 65]), but mostly at a high level, using category theory and institutions. What we are presenting here is an integrated environment to both formally specify these operations, and to provide efficient implementations for them, which has been integrated into an Eclipse model engineering environment.

In this sense, MOMENT [24, 5, 25] is a generic model management framework integrated in Eclipse which provides a reflective, algebraic, and executable framework for metamodeling, with support for MOF and OCL, and partial support for the QVT Relations language. It also uses Maude modules to automatically serialize software artifacts, but the kind of operations they provide are different. These operations rely on the definition of the Equal operation for matching two elements. The semantics of this operation coincides with the syntactical equiva-lence, although this generic semantics can be enriched by means of OCL expressions that take

into account the structure and semantics of a specific metamodel. They do not provide model subtyping. The latest internal encoding of models and metamodels in MOMENT was presented in [26], and shares many similarities with our previous representation [114] (see Section 4.3 for a comparison between the two representations). The tool does not follow a full MDE process to define the semantic mappings: they directly serialize EMF models into Maude instead of defining a Maude metamodel and model transformation between both platforms.

Model Subtyping. One of the most relevant works in model subtyping was presented by Steel and J´ez´equel in [121]. They introduced a model type definition as an extension of object type, i.e., as the set of objects types for all the objects contained in a model (basically a meta-model without its packages structure). The reason not to consider the metameta-model as the meta-model type is attributed to the increasing abundance of models that refer to other models, that causes that we can no longer guarantee that the classes of all objects within a model will be contained by a single package. However, we think that the problem lies on the metamodel definition they adopt, assuming a metamodel as a single MOF package and not considering the different package relationships (such as importation) that may exist. Our flattened subtyping covers the subtyping relationship they propose.

There are other approaches that propose to check type conformance from a set of restric-tions. For instance, in [58], a type system for object models is described that supports subtypes and allows overloading of relation names. The work is focused on type conformance, which is checked using the Alloy language. Model operations defined over the object models are not considered.

Finally, in [130], metamodel evolution is also handled, but they focus on the adaption of the models that conforms to the metamodels instead of on their operations.

Model Difference. There are several proposals that address the problems of comparing mod-els and calculating their difference. Firstly, we have the works that describe how to compute the difference of models that conform to one specific metamodel, usually UML [14, 90, 131].

Their specificity and strong dependence on the elements and structure of the given metamodel hinders their generalization as metamodel-independent approaches that can be used with mod-els that conform to arbitrary metamodmod-els.

Secondly, there are several techniques that allow to compute the difference between models using edit scripts, which are based on representing the modifications as sequences of atomic actions specifying how the initial model is procedurally modified. These approaches are more

general and powerful, and have been traditionally used for calculating and representing differ-ences in several contexts. However, edit scripts are intrinsically not declarative, lengthy and very fine-grained, suitable for internal representations but quite ineffective to be adopted for documenting changes in MDE environments, and difficult to compose. Furthermore, the re-sults of their calculations are not expressed as a model conforming to a specific metamodel, and therefore they cannot be processed by standard modeling platforms [41].

Other works, such as [41], [80] and [123], are closer to ours. In [41], a metamodel-independent approach to difference representation is presented, but with the particularity that the Difference Metamodel is not fixed, but created in each case as an extension of the operands’

metamodel. This approach is agnostic of the calculation method, so it does not introduce any model difference operation, and also requires a complex model transformation process to create the specific Difference Metamodel and to calculate the differences. Matching is based on name comparison: the proposal assumes that a specific attribute called name always exists. This may hinder its application in some contexts, such as for instance those in which metamodels are defined in languages different to English.

The work described in [80] introduces an algorithm for calculating and representing model differences in a metamodel-independent manner, but the result is not compact (it contains more information than required) and it is more oriented towards graphically representing and visual-izing the differences.

Thirdly, EMFCompare [123] is an interesting approach that uses complex and sophisti-cated algorithms to compute the structural matching between model elements. However, this proposal makes heavy use of the hierarchical tree for matching the elements, restricting the comparisons to elements in the same level. As discussed in Section 5.2.2, this restriction may not be effective in some cases, including those in which the changes affect the tree structure (something common in several model refactoring operations). Furthermore, difference models are not self-contained in EMFCompare, and therefore the minuend and subtrahend models are required in order to operate with the differences.

Finally, none of these approaches currently provide good support for composing the deltas and implementing further operations on them.