Ecore transformation tools

Ecore transformation tools is a set of plugins and APIs that permit transformation of EMF meta-models (Ecore/Xcore files) into MPS language structures, and transformation of models from EMF into MPS and vice versa.

User- Perspective

From the user-perspective, the Ecore transformation tools are available as a pop-up menu within the respective contexts.

1. Upon right-clicking the "Structure" aspect of a new Language, the "Import Ecore meta-model into MPS" is available as an option. The user simply chooses the corresponding meta-model file which will be imported as concepts(class, interface, and enums) inside the language.

2. Upon right-clicking a "Model", it is possible to either import an existing emf model instance or export the model as an XML file. The difference lies in the file choosers that follow.

• For the model exporter, the user begins with an existing model instance of a known meta-model (mps language), right clicks on the model instance and chooses the meta-model in EMF. The exported model instance is stored as an xml file in the file system (same location as the emf meta-model file).

• For the model importer, the user begins with an empty model where he intends to import the instance(in MPS), chooses the xml model instance and the corresponding EMF meta-model. He also needs to choose the meta-model in MPS (language structure) that corresponds to the EMF meta-model. This import is a step that needs to take place after the meta-model importer has been used. The imported model instance is available as nodes in the picked model.

Developer perspective

From the developer perspective, the Ecore transformation tools are all in the mbeddr.mpsutil languages within the ecore virtual folder. There are two virtual sub-folders impl and tests. The impl contains the plugins and runtime API and the tests contain the tests. The plugin code is available inside the solution suffixed with .ui. The rest of the folder comprises of runtime solutions and languages used internally by the model transformer and testing framework. These languages will be explained in the Design decision section.

Design decisions

Meta-model importer

The meta-model importer gets as input an Ecore/Xcore file representing an EMF meta-model. Both Ecore and Xcore files have the capability to represent the same EMF meta-model in different fashions. The ecore file uses an XML representation, whereas an XCORE file uses a java-interface like representation. Thanks to the EMF API and resource loaders, our importer is able to process both types of files without issues. The meta-model performs the following (on a high level):

• Import all non-abstract classes as concepts.

• Import all abstract classes as interface concepts.

• Import all enums as enumeration concepts. EMF permits enums with non-unique representations which is not permitted in MPS. To handle this issue, our importer simply generates unique values starting from 0 with increments of 1 for enums which donot have unique values.

• Import all properties of classes as attributes. The properties of type int, char and string are imported as is with the corresponding EMF primitive types. The properties of enum types are also mapped accordingly. The properties of any EMF type that is not one of the previously explained types is mapped to a string type with an annotation EMFDatatype. The value of this annotation is set to a concept from the ecore language which contains a concept for each EMF data type permissible. We acquired this list of data types from the EMF api.

  

• Import all sub-class -> super-class/interface relationship as is, except for cases of multiple inheritance. Whenever there is a case of multiple inheritance, our importer creates interfaces that correspond to the superclasses and map the sub-class to the corresponding generated super-class. This is a popular method of mapping multiple inheritance to single inheritance systems.

  

In addition to the above mentioned steps, the meta-model importer also creates a copy of the imported Ecore/Xcore file into the folder of the imported language and creates a new node called EcoreFileInfo which points to the copied file.

The meta-model importer uses a lazy-resolving approach to efficiently resolve reference relationships. For every concept that has a reference relationship, the meta model importer creates a lazy reference to the desired concept. At the end of the importing phase 1,

The Model Importer/Exporter

Both the model importer and exporter work in similar fashion. The model exporter exports the model instance of MPS meta-models as xml and the model importer uses the xml file to generate model instances. Both the model importer and exporter use the SModel API (MPS) and EMF API(EMF) to create nodes, parse the xml files and so on. The implementation is pretty straight forward.

• The model importer parses the xml file, and for every node in the xml it searches for corresponding class in the meta-model and creates an instance of the corresponding concept in MPS. The mapping between the class in EMF and the concept in MPS is performed using simple class name search and this assumes that the imported meta-model in EMF and MPS share the same class names. This is currently ensured by the meta-model importer.
• The model exporter parses the nodes in the root of the chosen MPS model, gets the concept of each of these nodes, and uses the EMF api to create nodes in the output xml file.

Both the importer and exporter use multiple-phase approach to handle resolving of children and references.

The Testing framework

The testing framework includes a runtime and two language extensions.

1. The first language extension allows testers to specify the meta-model file in EMF(ecore/xcore file) and the expected meta-model. These are then used by the testing runtime to invoke the meta-model importer and assert if the imported meta-model and the expected meta-model are equal. This internally uses the MPS Node Comparator framework.

2. The second language extension allows testers to simultaneously test the model-importer and model-exporter. The tester simply needs to specify the two meta-models (MPS language and EMF ecore file) and the model instance to be tested. The testing framework internally uses the model-exporter to export this model as an xml file, store it in a temporary location, then use the model-importer to import this xml file as a temporary model and finally assert if the imported model and the original model are equal using the MPS Node Comparator.

Future directions:

The following tasks/features could be developed in the future:

1. Use the stored ecore file in the imported language (from meta-model importer) in order to simplify the model export/import process. This feature would make sure the user does not have to choose both the meta-models (EMF and MPS) when importing model instances

2. Use annotations to to compare the classes in MPS and EMF (for model import/export). This will make sure the model importer/exporter function independent of the implementation choices taken by the meta-model importer.

3. Support versioning for the meta-model importer. The details of this feature are beyond the scope of this document. But a typical versioning system would be able to import only 'updated' parts of a previously imported meta-model and maintain links accordingly so that model import/exports remain unbroken after a meta-model upgrade.