Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA2/Ecore2Genmodel"
(→Transformation) |
(→Interesting points of the transformation) |
||
| Line 57: | Line 57: | ||
Note: Export works only with the last imported model (due to a reqiured reference to the original Ecore resource) | Note: Export works only with the last imported model (due to a reqiured reference to the original Ecore resource) | ||
| − | === Interesting points of the | + | === Interesting points of the solution === |
==== Metamodels ==== | ==== Metamodels ==== | ||
| Line 92: | Line 92: | ||
During the transformation, this mapping function is used for creating the correctly typed GenModel elements for the Ecore elements. | During the transformation, this mapping function is used for creating the correctly typed GenModel elements for the Ecore elements. | ||
| − | ===== | + | ===== Metametamodel patterns ===== |
| + | The transformation uses complex graph patterns for creating GenModel elements, attributes, relations and cross-model references. In these patterns, the Ecore metametamodel is used instead of creating explicit patterns for every element and relation type of the GenModel metamodel. | ||
| + | For example, in order to create a relation between a GenClass and its contained GenFeature, the ''genFeatures'' relation has to be retrieved from the metamodel. The metametamodel used here states that we are looking for an EReference (in nemf) typed relation, which can be instantiated between elements that are instances of EClass (in nemf) typed elements. Although these constructs may sound too complex, their use provide a generic solution. | ||
===== Annotations ===== | ===== Annotations ===== | ||
| + | Annotations defined in the Ecore models using the "emf.gen" source are inspected in the transformation and their corresponding attributes are set in the target GenModel. It is important, that these attributes may be simple data types (EString, EBoolean, EInteger), but they might point to existing model elements as well. Furthermore, some attributes can be instantiated multiple times in the same element. Finally, there are attributes that have to be set (with defualt values) even if no annotation is defined for them, in order to create a well-formed GenModel. | ||
| + | |||
| + | In the transformation first the attribute relation and value type is retrieved from the metamodel using the key of the annotation entry, then the multiplicity of the relation is checked. If it is "many", the annotation value is split to multiple values and the attribute is created for every value. Furthermore, the attribute relation is created between the parent and attribute elements. If the attribute is an existing element (EEnumLiteral), only the relation is created to the appropriate element. | ||
===== Type-checking ===== | ===== Type-checking ===== | ||
| + | |||
| + | The annotation entry values in the Ecore model are all character strings, however, many attributes in GenModel models are types with restricted value sets. For example a boolean must be "true" or "false", while enumerations define a given set of values. In the transformation, the key of the annotation entry is used through a metametamodel pattern to find the corresponding attribute definition and required data type. Then the value of the entry is checked against the possible values of the data type. | ||
Latest revision as of 11:14, 13 July 2010
This page is dedicated to the TTC 2010 Ecore2GenModel case study solution implemented in VIATRA2.
Contents
Description
The built-in EMF GenModel generator transformation is able to propagate changes of the source Ecore model to the generated GenModel, whoever in some cases (when the source model changes are too many) this consolidation fails and all previous data existing only in the GenModel are lost as a new GenModel is created. In the case study, EMF annotations are used in the source Ecore model for storing specific GenModel information and a new transformation is required that is able to generate a GenModel using the annotations from the Ecore model.
EMF annotations have a source and a details part, where the source is a character string describing the group of entries which are included in the details part. The details part contains an arbitrary number of entries (key-value pairs). In this case, annotations with "emf.gen" source are identified as GenModel information, while the key of an entry is equal to the name of the attribute in the GenModel metamodel (e.g. basePackage for GenModel).
For more details on the problem and solution, check the case study description and our short paper
Try it in SHARE
SHARE is a hosted demonstration platform where tools prepared in dedicated virtual machines can be accessed through remote desktop connection.
To try our solution in SHARE, go here.
Installation
The solution can be easily installed into an Eclipse (3.5+) using our dedicated update site. After selecting all the features, the plugin dependencies are automatically resolved, as long as you have the default Eclipse update site (Galileo/Helios) and have the "Contact all update sites..." enabled.
Execution
Select an arbitrary Ecore model (.ecore file) in the Navigator view, right-click to bring up the local menu and click on "Generate GenModel". The resulting .genmodel file is created and can be opened with the inbuilt EMF editors.
Manual execution
Execute transformation step-by-step using the source files found under the models directory in the hu.bme.mit.viatra2.genmodelexport plugin (included in the update site as well):
0. Switch to VIATRA2 Perspective
1. Open nemf-meta.vpml
2. Drag and drop ecore2genmodel_cropped.vtcl file on the model space in the VIATRA2 Model spaces view (lower left corner)
3. Right-click on the model space in the same view and select "Native importers" and "Ecore Instance importer"
4. Select the desired Ecore file to import. The created model appears under nemf.resources in the model space.
5. Right-click ecore2genmodel below Program Models (VIATRA2 Model spaces view) and select "Run..."
6. Select the Ecore package to transform below nemf.resources and click "Select Model Element"
7. Enter additional properties (Model name and pluginID) then click OK. Use space or semicolon to separate parameters.
8. The GenModel model is created under nemf.resources using the model name and "_genmodel".
9. Right-click on the model space again, select "Contributions" and "Export GenModel"
10. Select the folder and name for the .genmodel file
11. Input the name of the created GenModel model and click OK.
Note: Export works only with the last imported model (due to a reqiured reference to the original Ecore resource)
Interesting points of the solution
Metamodels
The solution uses 3 modeling levels which are:
- Ecore metametamodel for defining the possible types and relations in Ecore metamodels (nemf).
- Ecore/GenModel metamodel for describing Ecore and GenModel models (in packages).
- Ecore and GenModel model instances which are the inputs and outputs of the transformation (in resources).
Note that the metamodel of Ecore is Ecore as well, thus the metametamodel and the Ecore metamodel are identical apart from the fact that elements in the first have VPM types while in the second they are instances of the first.
The nemf-meta.vpml model space file contains the two metamodel levels and instance models (.ecore files) can be imported as well.
Import/Export
Ecore models are instances of the Ecore metamodel and are imported into the model space using the generic EMF importer available from the extras update site. Export is done by a GenModel exporter plugin, though a generic EMF exporter is planned later.
Transformation
There are several interesting points in the transformation itself which may be reused in other scenarios as well.
Mapping
In EMF, the GenModel type corresponding to any given Ecore type is precisely defined. For example, an EClass element is transformed to a GenClass element. However, in some cases the Ecore element can not be transformed directly by its type, but one of its supertypes can (e.g EReference type has EStructuralFeature as a supertype and that is transformed into Genfeature type).
The ASM function feature of VIATRA2 is used to declare the type pairs on which the transformation is possible.
asmfunction mapping /1 {
(nemf.packages.ecore.EPackage) = nemf.packages.genmodel.GenPackage ;
(nemf.packages.ecore.EClass) = nemf.packages.genmodel.GenClass ;
(nemf.packages.ecore.EStructuralFeature) = nemf.packages.genmodel.GenFeature ;
[...]
}
During the transformation, this mapping function is used for creating the correctly typed GenModel elements for the Ecore elements.
Metametamodel patterns
The transformation uses complex graph patterns for creating GenModel elements, attributes, relations and cross-model references. In these patterns, the Ecore metametamodel is used instead of creating explicit patterns for every element and relation type of the GenModel metamodel.
For example, in order to create a relation between a GenClass and its contained GenFeature, the genFeatures relation has to be retrieved from the metamodel. The metametamodel used here states that we are looking for an EReference (in nemf) typed relation, which can be instantiated between elements that are instances of EClass (in nemf) typed elements. Although these constructs may sound too complex, their use provide a generic solution.
Annotations
Annotations defined in the Ecore models using the "emf.gen" source are inspected in the transformation and their corresponding attributes are set in the target GenModel. It is important, that these attributes may be simple data types (EString, EBoolean, EInteger), but they might point to existing model elements as well. Furthermore, some attributes can be instantiated multiple times in the same element. Finally, there are attributes that have to be set (with defualt values) even if no annotation is defined for them, in order to create a well-formed GenModel.
In the transformation first the attribute relation and value type is retrieved from the metamodel using the key of the annotation entry, then the multiplicity of the relation is checked. If it is "many", the annotation value is split to multiple values and the attribute is created for every value. Furthermore, the attribute relation is created between the parent and attribute elements. If the attribute is an existing element (EEnumLiteral), only the relation is created to the appropriate element.
Type-checking
The annotation entry values in the Ecore model are all character strings, however, many attributes in GenModel models are types with restricted value sets. For example a boolean must be "true" or "false", while enumerations define a given set of values. In the transformation, the key of the annotation entry is used through a metametamodel pattern to find the corresponding attribute definition and required data type. Then the value of the entry is checked against the possible values of the data type.