The Eclipse support for OCL, QVTc and QVTr adds an import statement to define the location of the metamodels.
import SimpleUML : 'SimpleUml.ecore'::umlMM;
This specifies that the SimpleUml.ecore metamodel is loaded. The metamodel root prefixes a navigation to select an imported element. In the example above the umlMM package is selected and made available with a SimpleUML alias. If alias-name and colon separator are omitted, the imported element is accessible by its own name.
The quoted name may be importing-file-relative file name as above, or a an absolute path such as platform:/resource/org.eclipse.emf.examples.library/model/extlibrary.ecore or a registered namespace URI such as http://www.eclipse.org/emf/2002/Ecore.
The Eclipse support for QVTc and QVTr supports declaration of transformations within a package hierarchy. A Transformation therefore extends just a Class, not a Class and a Package as specified by OMG. The Transformation is declared nested within one of more Packages by qualifying the transformation name with one of more package names. For compatibility, if no Package is declared, the Transformation is contained by a Package with a blank name.
The package hierarchy declared for the Transformation is re-used to define the Java package hierarchy when Java code is generated from the Transformation.
transformation org::eclipse::qvtd::xtext::qvtrelation::tests::hstm2fstm::HierarchicalStateMachine2FlatStateMachine(hier:hierMM, flat:flatMM)
{
...
}
Alternatively a package declaration may be used. This may also optionally define the package URI and/or namespace prefix.
package org::eclipse::qvtd::xtext::qvtrelation::tests::hstm2fstm : nsPrefix = 'nsURI'
{
transformation HierarchicalStateMachine2FlatStateMachine(hier:hierMM, flat:flatMM)
{
...
}
}
A package declaration may contain nested packages, classes or transformations. Within class declarations operations and properties may be declared analoguously to QVTo’s contextual operatuions and properties, or to additional declarations from an imported Complete OCL document. The syntax is the same as OCLinECore which emulates typical OMG specification source text.
package MyPackage
{
class MyClass
{
operation op(p : String[1]) : String[1]
{
body: p.toUpper();
}
property name : String[1];
}
transformation MyTx(...)
{
...
}
}
The QVTc part of the specification is unclear as to how the middle metamodel is defined.
Eclipse QVTc imports the middle metamodel in the same way as any other metamodel. This is then used as a used-package of an unnamed domain.
import SimpleUML : 'SimpleUml.ecore'::umlMM;
import SimpleUMLtoRDBMS : 'SimpleUMLtoRDBMS.ecore'::uml2rdbms;
import SimpleRDBMS : 'SimpleRdbms.ecore'::rdbmsMM;
transformation umlRdbms {
uml imports SimpleUML;
rdbms imports SimpleRDBMS;
imports SimpleUMLtoRDBMS;
}
The QVTr part of the specification appears to specify how the middle metamodel is synthesized. The specification however ignores details such as Models, Packages and Collections. There is also a lack of clarity as to whether the trace is the minimum required to support non-re-invocation of mappings or whether it should contain everything necessary for minimal incremental re-execution. The Eclipse QVTd implementation is work-in-progress.
The QVTr part of the specification omits almost all detail of the semantics of Collections and in particular Collection Templates. The implementation in Eclipse QVTd is therefore language design work-in-progress rather than implementation work-in-progress.
The QVT specification provides layered metamodels for QVTrelation, QVTtemplate, QVTcore and QVTbase layered on top of EssentialOCL and EMOF. The EssentialOCL and EMOF metamodels are very strongly influenced by OCL and MOF specifications, but are ot formally compliant.
Eclipse QVTd provides layered metamodels for QVTrelation, QVTtemplate, QVTcore and QVTbase layered on top of Pivot which is derived from the UML 2.5 metamodel and work towards a future OCL specification. (QVTimperative shares some QVTcore functionality through a QVTcoreBase abstraction.)
A consequence of extending the Eclipse OCL Pivot is that Eclipse QVTd has preliminary support for templated types, extensible libraries and safe navigation.
QVTo defines this as a reserved variable for the instance of the executing transformation.
Eclipse QVTd provides this for QVTc and QVTr and thereby solves an OCL compatibility problem with respect to the source of an operation call of a query. In Eclipse QVTd, queries, using the Function class, are operations of the Transformation class and are invoked with an implicit this. An explicit this can be used, and is used when viewing the equivalent source text for the Abstract Syntax model.