Colouring - Execution, debug and analysis of QVT-Relations based on Coloured Petri Nets

 
In this page you will find a set of prototype tools to: 

-          automate the generation of CPN (Coloured Petri Net) models from QVT-Relations specifications.

-          automate the generation of CPN markings from EMF models.

-          annotate the result of simulating the generated CPN models back as EMF models.

 

Overview

 

Step 1:

The transformation designer specifies the transformation using the textual format of QVT-Relations, and the source and target ecore meta-models. This can be done with common MDE tools.

 

Step 2:

The designer uses the qvt2cpn.jar generator to generate the CPN model for the chosen scenario (transformation, model matching or check-only).

The generated CPN models have the input format of CPNTools.

He can also use the parser.jar generator to parse the initial emf models for the chosen scenario (source model in the transformation scenario, and both source and target models in the other two scenarios).

 

Step 3:

The designer uses CPNTools to debug, execute and analyse the specification.

CPNTools can be downloaded here.

Also, take a look at this paper in order to know more about how to take advantage of CPNTools to debug and analyse your QVT-Relations specifications.

 

Step 4:

The designer can use the parser.jar generator to annotate back the results provided by the execution of the CPN model.

o        In transformation scenarios, the parser produces an emf model with the resulting target model.

o        In model matching scenarios, the parser produces an emf trace model, as well as a modelink file to visualize the traces in a three pane window. Modelink is an Eclipse-based project, and can be downloaded here.

o        In check-only scenarios, the parser produces an emf trace model with the occurrences of relations which are not satisfied, and a modelink file to visualize the traces.

 

toolchain.jpg

Download

 

qvt2cpn.jar : it generates a CPN model from a QVT-Relations specification for one of the following scenarios: transformation, model matching, check-only.

parser.jar : it parses emf models into CPN markings, and the other way round.

 

How to use it

 

The qvt2cpn.jar generator receives the following arguments:

1.      <specification.qvt>: file with the qvt specification

2.      <sourcemm.ecore>: ecore file with the source meta-model

3.      <targetmm.ecore>: ecore file with the target meta-model

4.      execution scenario, specified by one of the keywords: transformation, matching or checkonly (transformation is chosen if none is given).

We obtain a file with cpn extension, which can be loaded into CPNTools for its simulation and analysis.

 

> java -jar qvt2cpn.jar <specification.qvt> <sourcemm.ecore> <targetmm.ecore> [transformation | matching | checkonly]

 

The parser.jar generator, used to generate CPN markings from emf models, receives the following arguments:

1.      keyword gen_marking

2.      <metamodel.ecore>: ecore file with the meta-model of the model

3.      <model>: model to be parsed

We obtain a set of files, one for each class and association type in the meta-model, containing the model objects. These files are imported by the CPN models generated from the QVT specifications.

We also obtain a file called ids.txt, which will be used to parse-back the simulation results in the model matching and check-only scenarios. It assigns a unique identifier to each model object.

 

> java -jar parser.jar gen_marking <metamodel.ecore> <model> [<metamodel.ecore> <model>]*

 

The parser.jar generator, used to parse the CPNTool result for a transformation scenario, receives the following arguments:

1.      Keyword parse_marking

2.      <metamodel.ecore>: ecore file with the target meta-model

3.      <markingFolder>: folder containing the files generated by the execution of the CPN (usually, a folder output inside the folder that contains the net)

4.      <rootType>: type of the element acting as root in the parsed model

We obtain an emf file with the resulting target model.

 

> java -jar parser.jar parse_marking <metamodel.ecore> <markingFolder> <rootType>

 

The parser.jar generator, used to parse the CPNTool result for a model matching scenario, receives the following arguments:

1.      Keyword parse_matching

2.      <metamodel1.ecore>: ecore file with the meta-model of the first model

3.      <model1>: first model

4.      <metamodel2.ecore>: ecore file with the meta-model of the second model

5.      <model2>: second model

6.      <tracesFolder>: folder containing the files generated by the execution of the CPN (usually, a folder output inside the folder that contains the net)

7.      <ids.txt>: file previously generated by the parser when used in mode gen_marking

We obtain an emf file with the resulting trace model.

We also obtain a modelink file, which can be loaded in Eclipse to inspect the results in a three-pane window.

 

> java -jar parser.jar parse_matching <metamodel1.ecore> <model1> <metamodel2.ecore> <model2> <tracesFolder> <ids.txt>

 

The parser.jar generator, used to parse the CPNTool result for a check-only scenario, receives the following arguments:

1.      Keyword parse_checkonly

2.      <metamodel1.ecore>: ecore file with the meta-model of the first model

3.      <model1>: first model

4.      <metamodel2.ecore>: ecore file with the meta-model of the second model

5.      <model2>: second model

6.      <tracesFolder>: folder containing the files generated by the execution of the CPN (usually, a folder output inside the folder that contains the net)

7.      <ids.txt>: file previously generated by the parser when used in mode gen_marking

We obtain which relations are not satisfied.

We obtain an emf file with the resulting trace model, which identifies the enabled occurrences of relations which are not satisfied.

We also obtain a modelink file, which can be loaded in Eclipse to inspect the results in a three-pane window.

 

> java -jar parser.jar parse_checkonly <metamodel1.ecore> <model1> <metamodel2.ecore> <model2> <tracesFolder> <ids.txt>

 

In the future, we plan to provide an Eclipse plug-in for our generators, so that they can be integrated easily in the Eclipse environment.

 

Example 1: transformation scenario

 

An example QVT specification, together with the source and target meta-models, and a source model to be transformed, can be downloaded here.

This is a simplified version of the classical uml-to-relational transformation. Unzip the file in the folder where you downloaded the jars.

 

First, we generate the CPN model for the QVT specification (transformation scenario):

 

> java -jar qvt2cpn.jar uml2rdbms.qvt TinyUML.ecore TinyRDBMS.ecore transformation

 

The generated CPN file can be downloaded here.

 

Next, we generate the marking for the uml model we want to transform:

 

> java -jar parser.jar gen_marking TinyUML.ecore uml.model

 

In the folder we will see that 6 files have been generated, one for each class and association in the meta-model. You can download these files with the initial marking for the net here.

 

Now we can load the generated cpn file in CPNTools, and simulate and validate the transformation by using the tool.

In order to load the initial marking in the net, we should execute the transition appearing in page LoadTinyUML of the generated net first.

Then, we run the complete simulation.

Once the simulation of the net is complete, CPNTools will create a folder called output containing the final marking of the net (download here).

 

Now we can parse the final marking of the net into an emf model, which corresponds to the resulting RDBMS target model:

 

> java -jar parser.jar parse_marking TinyRDBMS.ecore output Schema

 

The parsed emf model, named output.model, can be downloaded here.

 

Example 2: model matching scenario

 

We are using the same uml-to-rdbms example as before, but for a model matching scenario.

The QVT specification, together with the source and target meta-models, and source and target models to be matched, can be downloaded here.

Again, unzip the file in the folder where you downloaded the jars.

 

First, we generate the CPN model for the QVT specification (check-only scenario):

 

> java -jar qvt2cpn.jar uml2rdbms.qvt TinyUML.ecore TinyRDBMS.ecore matching

 

The generated CPN file can be downloaded here.

 

Next, we generate the marking for the uml and rdbms models we want to match:

 

> java -jar parser.jar gen_marking TinyUML.ecore uml.model TinyRDBMS.ecore rdbms.model

 

Now we can load the generated cpn file in CPNTools, and simulate and validate the transformation by using the tool.

In order to load the initial marking in the net, we should execute the transitions appearing in pages LoadTinyUML and LoadTinyRDBMS of the generated net first.

Then, we run the complete simulation.

Once the simulation of the net is complete, CPNTools will create a folder called output containing the final marking of the net (download here).

 

We can parse the final marking of the net, and obtain an emf model containing the generated traces:

 

> java -jar parser.jar parse_matching TinyUML.ecore uml.model TinyRDBMS.ecore rdbms.model output ids.txt

 

We obtain a trace model (download here) and a file with extension modelink (download here).

 

We can inspect the matched models, together with their traces, by loading the obtained modelink file into Eclipse.

For this, first we will need to: (i) register the traces meta-model in our Eclipse workspace (download meta-model here), and (ii) install Modelink in our Eclipse installation (download plug-in here).

 

This is how our obtained modelink file will be visualized.

 

toolmatching.jpg

 

Additional examples

 

Below you can find several example QVT-R transformations. Each zip contains a file with the transformation, the ecore meta-models, some example models, and the generated coloured Petri net. Indeed, the zip files contain two cpn files: one that reads from local files the initial marking of the net (file *_transformation.cpn), and another one with the initial marking that corresponds to the example models (file *_transformation_initialized.cpn). The zip also includes the result of executing the net and parsing back the results (folder output).
  • fruits2pears_when: this example illustrates the use of abstract objects in check-only domains

  • fruits2pears_where: this example illustrates the use of abstract objects in check-only domain

  • mma2mma: a simple transformation illustrating meta-models with inheritance

  • people2families_v1: A more complex example

  • people2families_v2: A more complex example

  • uml2rdbms: the classical transformation from UML to RDBMS. It includes the generated nets for all scenarios (transformation, check-only and model_matching) as well as the result in each one of them for the provided example models. 

 

Non-supported features

 

This is an on-going research work, therefore there are features that our generators do not support yet:
  • Associative classes in meta-models

  • Complex OCL constructs

  • More than two domains

  • ...

Any contribution is welcome!

  

Publications

 

Formal support for QVT-relations with coloured Petri nets. 2009. Juan de Lara and Esther Guerra. Lecture Notes in Computer Science 5795, Springer. pp.: 256-270. Presented at MODELS'09: ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems.

Colouring: Execution, debug and analysis of QVT-Relations transformations through coloured Petri nets. 2014. Esther Guerra and Juan de Lara. Software and Systems Modeling (Springer), Volume 13, Issue 4. pp.: 1447-1472.

 

Contacts

 

If you have some problem or question, please feel free to contact us:

-          Esther Guerra: Esther.Guerra <at> uam.es

-          Juan de Lara: Juan.deLara <at> uam.es

 

Last update: November 2010