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.

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.

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.