ModelJoin/Xbase Integration

Aus SDQ-Wiki
Zur Navigation springen Zur Suche springen


This page should clarify the migration of the MetaModelJoiner from Java to Xtend and the Xbase Integration.
In order to download and run the ModelJoin application, no further steps are required than the one described in the sections before.

Migration of the MetaModelJoiner

The MetaModelJoiner under /edu.kit.ipd.sdq.mdsd.mj.metamodel.generator/src/edu/kit/ipd/sdq/mdsd/mj/metamodel/generator/ was migrated from Java to Xtend. The new class can be found under /edu.kit.ipd.sdq.mdsd.mj.metamodel.generator/src/edu/kit/ipd/sdq/mdsd/mj/metamodel/generator/MetamodelJoinerXtend.xtend and the corresponding java class can be found under /edu.kit.ipd.sdq.mdsd.mj.metamodel.generator/xtend-gen/edu/kit/ipd/sdq/mdsd/mj/metamodel/generator/

Xbase Integration

Why did we decide to use Xbase?

A ThetaJoin query contains a where-condition in order to specify the join.

For example:

import "platform:/resource/edu.kit.ipd.sdq.mdsd.mj.test/models/imdb.ecore"
import "platform:/resource/edu.kit.ipd.sdq.mdsd.mj.test/models/extlibrary_dominik.ecore"

target ""

theta join library.Book with imdb.Film where "library.Book.title=imdb.Film.title" as jointarget.Book {
keep attributes library.Item.publicationDate

With the old Xtext grammar we were able to write any string into the where-condition, which made it possible to create a transformation file, even if the condition was not correct at all. In order to be able to validate the where-condition while editing a ThetaJoin query we decided to integrate Xbase.

How to use Xbase?

Adding "with org.eclipse.xtext.xbase.Xbase" to the grammar, which is defined in the edu.kit.ipd.sdq.mdsd.mj.xtext package gives us the possibility to use Xbase Expressions in the grammar. Instead of being defined as string, the where-condition now is defined as XExpression. Running the mwe2 workflow under edu.kit.ipd.sdq.mdsd.mj.xtext/src/GenerateModelJoinXtextEditor.mwe2 creates the ModelJoin-Metamodel (defined by the grammar as before, which is now able to use Xbase Expressions as well) and also creates the JvmModelInferrer under /edu.kit.ipd.sdq.mdsd.mj.xtext/src/edu/kit/ipd/sdq/mdsd/jvmmodel/ModelJoinJvmModelInferrer.xtend

Why we use the JvmModelInferrer?

The JvmModelInferrer gives us the possibilty to validate the where-condition of a ThetaJoin query when the query is edited. The JvmModelInferrer automatically generates a class, with methods and parameters in the runtime application. The class that we want to be generated, is defined in the ModelJoinJvmModelInferrer. The advantage of using the JvmModelInferrer is, that it makes it possible to interpret the Xbase Expressions, as well as refer the in the grammar defined variables to any Java element.

Open Problems

Open problem ModelJoinJvmModelInferrer

Right now, the JvmModelInferrer is already implemented. Editing a ThetaJoin query leads to the error message: "Could not find a GenModel for EPackage", because the JvmModelInferrer is not able to read the properties of the EClasses, defined in the ThetaJoin query. In order to solve that issue, the GenModel files for the EClasses, used in the ThetaJoin query, needs to be registered in the mwe2 workflow.

Open problem Transformation Execution

Previously the where-condition of a ThetaJoined was saved as an EAnnotation in the target class, hence the transformation execution knew the condition of the join. This was done by the MetaModelJoiner (now MetaModelJoinerXtend). This part of the code is commented by:

// TODO: Transformation needs to know the theta join condition

Now that the where-condition of a ThetaJoin isn't a string any longer, the where-condition needs to be casted from XExpression to string.


First part of the presentation explains the migration from Java to Xtend in the MetaModelJoinerXtend class.
Second part of the presentation describes the Xbase integration.