1. Projects
  2. MTB

MTB

Overview

On this website it is provided the implementation, as well as full examples, of the MatchingTablesBuilder approach presented in [1]. It allows to identify, in a static way, guilty rules in ATL model transformations according to a set of OCL constraints. This is, in case a constraint is not satisfied, this approach helps identifying the rule most likely responsible for this. Furthermore, it allows answering the following research questions:

  • Which transformation rule(s) implement(s) which constraint(s)?
  • Are al constraints covered by transformation rules?
  • Are all transformation rules covered by constraints?

In the following, examples where the approach has been applied are shown, and the program is available for download. We also show the similarity matrixes for many ATL transformations taken from the ATL zoo. It is a table that basically gives us the fitness of a model transformation for applying our approach on it. Also, we describe the process we use for extracting the types appearing in ATL trasnformations.

MatchingTablesBuilder

Downloadable

Please access this dedicated webpage to find the latest version of our MatchingTablesBuilder. In such website you can also find a user manual explaining the easy steps to obtain your matching tables.

At the time of development, we used the Eclipse Luna (Eclipse Modeling Tools version) and ATL 3.5.0.

Examples

The MatchingTablesBuilder has been applied in the following examples, for which we also show the transformation and OCL constraints, as well as the similarity matrix.

Similarity Matrixes

Please access this dedicated webpage with information regarding similarity matrixes. A very important aspect of them is the types extraction in ATL transformations, which has been described in a technical report [2] and also in the section below in this website.

Types Extraction

from the constraints

In the constraints, due to the nature of OCL, nesting is necessary to implement correct restrictions. For example, let us imagine we have the source and target metamodels for the UML2ER case study are used later on to illustrate our approach. In the source metamodel, there is a class named Package composed of several elements of type Class through the ownedElements relationship. Similarly, the target metamodel has a class ERModel composed of elements of type EntityType through the entities relationship. If we have a one-to-one transformation that transforms objects of type Package to objects of type ERModel and objects of Class to objects of class EntityType, and we want to check that the Packages have been properly transformed to ERModels, the OCL restriction would be written as follows:

Package.allInstances->forAll(p|ERModel.allInstances
		->exists(em|p.name=em.name))

But if we want to check about Class and EntityType too (i.e., their internal members), then the OCL restriction should be similar to:

Package.allInstances->forAll(p|ERModel.allInstances
		->exists(em|p.name=em.name and p.ownedElements
		->forAll(c|em.entities->exists(e|c.name=e.name))))

As we can see, for building a correct OCL restriction, it is necessary to introduce types Package and ERModel. However, these are implementation details and not relevant for the semantics of the constraint - which only involves Class and EntityType.

Alternatively, we can take into account only the types inside the body of the deepest (in the sense of nesting) iterators (the forAll and exists iterators are the most employed). In this work, we opt for this latter approach because it introduces less noise, i.e., it does not extract types which are not representative for the constraint (since they are used for navigation purposes, and not for model element transformation), what in turn contributes to the modularization and independence of the types extracted in the constraints.

Furthermore, when there is a navigation through different types, the ones extracted are those in the last part of the expression, since the other types are not considered to be relevant. Since metamodels are graphs, starting from a specific class several navigation paths can lead to the same target class, which is what we really need, whereas all other classes in the navigation can be considered as mere implementation details. For instance, to extract the types from Package.ownedElements.ownedProperty - for simplicity, let us consider now that all relationships have cardinality 1..1, so that we do not need to add the OCL collect operator -, we only consider Class.ownedProperty, so we extract its types. In this case, we obtain types Class, Class.ownedProperty and Property.

There are two possibilities for the type extraction of OCL constraints. We can weight the types according to their number of occurrences in the constraints, giving less importance (a lower value) to those that appear less often. Alternatively, we can take into account only the types inside the body of the deepest (in the sense of nesting) iterators (the forAll and exists iterators are the most employed). In this work, we opt for this latter approach because it introduces less noise, i.e., it does not extract types which are not representative for the constraint (since they are used for navigation purposes, and not for model element transformation), what in turn contributes to the modularization and independence of the types extracted in the constraints.

Finally, we also ignore primitive types and constants as they do not normally introduce interesting information. Values like Integer, Boolean, true or false, can appear frequently, but this does not mean that each appearance has a relation with the others. For example, one case where they clearly spoil the results is when a constraint requires a feature to be between two integers (e.g. feature>2 and feature<10). These two numbers (2 and 10) are not helpful at all given the meaning of the constraint.

from the ATL rules

For obtaining both matching tables and similarity matrixes, we need to extract the types of tracts and ATL transformations. Tracts [3][4] are expressed in OCL (Object Constraint Language). For this reason, the API of USE (UML based Specification Environment) tool [5] can be used in the types extraction, what eases the process. Contrarily, ATL does not offer any support nor API to do the extraction, what makes it quite complicated.

In this dedicated webpage we explain how we achieve the extraction of the types in ATL transformations.

References

[1] Loli Burgueño, Javier Troya, Manuel Wimmer, Antonio Vallecillo. Static Fault Localization in Model Transformations. IEEE Transactions on Software Engineering. Accepted for publication. 2014
[2] Javier Troya, Loli Burgueño, Manuel Wimmer, Antonio Vallecillo. Footprints Extraction in ATL Transformations. Technical Report. 2013
[3] Antonio Vallecillo, Martin Gogolla. Typing model transformations using Tracts. Theory and Practice of Model Transformations, LNCS 7307, pp. 56-71. 2012
[4] Manuel Wimmer, Loli Burgueño: Testing M2T/T2M transformations. Proc. of the 16th International Conference on Model-Driven Engineering Languages and Systems (MODELS), LNCS 8107, pp. 203-219. 2013
[5] Mark Richters, Martin Gogolla. OCL: Syntax, semantics, and tools. Object Modeling with the OCL. 2012