Colouring: execution, debug and analysis of QVT-relations transformations through coloured Petri nets

Abstract

QVT is the standard language sponsored by the OMG to specify model-to-model transformations. It includes three different languages, being QVT-relations (QVT-R) the one with higher-level of abstraction. Unfortunately, there is scarce tool support for it nowadays, with incompatibilities and disagreements between the few tools implementing it, and lacking support for the analysis and verification of transformations. Part of this situation is due to the fact that the standard provides only a semi-formal semantics for QVT-R. In order to alleviate this situation, this paper provides a semantics for QVT-R through its compilation into coloured Petri nets. The theory of coloured Petri nets provides useful techniques to analyse transformations (e.g. detecting relation conflicts, or checking whether certain structures are generated or not in the target model) as well as to determine their confluence and termination given a starting model. Our semantics is flexible enough to permit the use of QVT-R specifications not only for transformation and check-only scenarios, but also for model matching and model comparison, not covered in the original standard. As a proof of concept, we report on the use of CPNTools for the execution, debugging, verification and validation of transformations, and on a tool chain (named Colouring) to transform QVT-R specifications and their input models into the input format of CPNTools, as well as to export and visualize the transformation results back as models.

Appendix

1.1 A.1 Compilation of meta-models into colour sets

Listing 4 shows the procedure to compile meta-models with and without inheritance into colour sets. We assume that we can access the name of meta-models, classes and associations through the dot notation “.$\langle$name$\rangle$”, the name of the variable associated to the meta-model $M$ in a QVT-R specification $S$ through “M.$\langle$id$\rangle$”, the ancestors of a class through the dot notation “.$\langle$anc$\rangle$”, and assume binary associations with named roles at both ends. If a role is missing, we take as role the name of the class in the association end. We assume that the two roles of an association have different names.

In the compilation, step 1 creates a page for the meta-model, step 2 creates a record and a place of the record sort for each class, and step 3 does the same for each association. Records associated to classes include an object identifier and one field for each attribute in the class or its ancestors. Records derived from associations store the identifier of the objects in each association end. The name of the records for the associations is given by the concatenation of names of the source and target types and roles.

1.2 A.2 Compilation of relations: graphical pattern

The compilation of the relations in a QVT-R specification consists of two steps: the creation of colour sets and places to store the execution traces, and the generation of transitions modelling the relations. Listing 5 shows the pseudocode for the first step assuming relations without when and where clauses, which are handled in Appendix A.3. We assume that we can access the variable name of an object in a relation by using the dot notation “o.$\langle$id$\rangle$”, and all objects in both domains of a relation $r$ through “r.$\langle$domains$\rangle$”. According to the standard, the traces store the identifier of all objects involved in a relation.

Listing 6 shows the translation of each relation into a CPN transition. The handling of identifiers for the created objects is managed through the use of a global counter called $ID$, which gets incremented each time the transitions fire (step 8). In particular, firing a transition increments the counter as many units as objects the relation creates. Then, if a relation creates several objects $\text{ o}_i$, their identifier is assigned the value $ID-i$.

1.3 A.3 Compilation of relations: when and where

In order to handle the when and where sections of a relation, we have to perform the following modifications to Listing 6:

• For each relation $r$ invoked in the where clause, we create an additional place and colour set called “Param”+r. $\langle$name$\rangle$ to store the identifier of the objects used in the invocation. The calling relation is connected to the place with a write arc. The called relation $r$ is connected to the place with a self-loop arc.

• For each relation $r$ inspected in the when clause, we add a self-loop arc from the place “Trace”+r.$\langle$name$\rangle$ of the inspected relation to the transition of the actual relation.

• If a relation is invoked from a where clause from which it receives certain parameter objects, then the arcs that write tokens to the places for these objects are not created (i.e. step 3.1.5 in Listing 6 is not performed for the received objects).

• If a relation checks certain object in the when clause, then the arc that writes tokens to the place for this object is not generated (i.e. step 3.1.5 in Listing 6 is not performed for the checked objects).

In our current compilation, we restrict to when and where sections that contain sequences of calls to other relations, but not arbitrary formulae involving relations.

1.4 A.4 Model matching scenario

The procedure for generating transitions in the model matching scenario is similar to Listing 6, but both domains are check-only, and hence places of both domains are connected to the transition with self-loop arcs. Moreover, we do not make use of the global counter $ID$, so that transitions are not added any action (i.e. step 8 is not performed) and arcs always use the variables used in the relation (i.e. in steps 3.1.5 and 6, the object identifiers are read from the corresponding variable).