Model Conversions

In addition to provisioning one model from another model via ModelPro (templates):

· Eclipse tools provide specific model-to-model conversions. These tools may be natively provided as ant tasks or UI actions. Many of the conversions which are natively accessible only via UI have been wrapped by ModelPro ant tasks.

· Eclipse tools include generic model-to-model transformations, such as ATL. When above tools for specific model-to-model conversions do not satisfy the transformation requirement, the Eclipse model-to-model tools should be reviewed for applicability.

· Some conversions may be more easily expressed using ModelPro XSLT. This is particularly effective when the source and target meta-models are the same or very similar, since the XLST templates need be defined only for the stepwise refinement required.

Eclipse model-to-model conversion tasks

Eclipse tool-based model conversions are enumerated in the following sections. These are all made available as ant tasks to facilitate use in automated multiple-stage provisioning processes. Where possible, original eclipse ant tasks are used for conversions. In other cases, underlying conversion capabilities available via eclipse UI have been wrapped as ant tasks.

emf.Ecore2Java

Converts an ecore model to:

· ?.genmodel (generation model) used for subsequent java code generation.

· (optional) Java code for the model, including both interfaces and ecore implementation.

· (optional) java code for “edit” implementation.

· (optional) java code for “editor” implementation.

· (optional) variant of above for SDO target.

General form of task command:

<emf.Ecore2Java

model="${basedir}/wsdl/Calculator.ecore"

genModel="${basedir}/wsdl/Calculator.genmodel"

reconcileGenModel="overwrite"

generateJavaCode="false"

generateModelProject="false"

generateEditProject="false"

generateEditorProject="false"

modelProject="org.modeldriven.modelpro.soapro.example"

modelProjectFragmentPath="src" modelPluginID="org.modeldriven.modelpro.soapro.example"

sdo="true">

</emf.Ecore2Java>

Where:

· model : the filepath to the source model.

· genModel : the filepath to the (target) genmodel.

· reconcileGenModel: how to reconcile an existing genmodel with new genmodel; may be:

o overwrite : overwrites existing genmodel with new genmodel

o keep :keeps existing genmodel

· generateJavaCode: whether or not to generate any java code

· generateModelProject: whether or not to generate java code for model project

· generateEditProject: whether or not to generate java code for edit project

· generateEditorProject: whether or not to generate java code for editor project

· modelProject: name of the model project

· modelProjectFragmentPath: relative location of the jave source directory within the model project

· modelPluginID: plugin id of the model project

· sdo: whether or not to generate code corresponding to SDO specification

The arg line is defined as:

{ <model.ecore> }+ [ <model.genmodel> [ -reload ] ] <OPTION>

Where:

<OPTION> ::= [ <PROJECT-OPTION> ] [ <PATHMAP> ]

{ <PACKAGE> }+ { <REF-PACKAGE> }* { <REF-GEN-MODEL> }*

[ <TEMPLATE-PATH> ] [ <MODEL-PLUGIN-ID> ] [ <COPYRIGHT> ]

[ <SDO> ] [ <QUIET> ]

<PROJECT-OPTION> ::= <MODEL-PROJECT> [ <EDIT-PROJECT> ] [ <EDITOR-PROJECT> ]

[ <TESTS-PROJECT> ]

<MODEL-PROJECT> ::= -modelProject <model-directory> <fragment-path>

<EDIT-PROJECT> ::= -editProject <edit-directory> <fragment-path>

<EDITOR-PROJECT> ::= -editorProject <editor-directory> <fragment-path>

<TESTS-PROJECT> ::= -testsProject <tests-directory> <fragment-path>

<PACKAGE> ::= -package <nsURI> [ <base> <prefix> ]

<REF-GEN-MODEL> ::= -refGenModel <model.genmodel> { <nsURI> }+

<TEMPLATE-PATH> ::= -templatePath <template-directory>

<MODEL-PLUGIN-ID> ::= -modelPluginID <plugin-ID>

<COPYRIGHT> ::= -copyright <copyright-string>

<JDK-LEVEL> ::= -jdkLevel <jdk level: 1.4 5.0 6.0>

<VALIDATE-MODEL> ::= -validateModel <true|false>

<SDO> ::= -sdo

<QUIET> ::= -quiet

org.modeldriven.ecore2xsd

Converts an ecore model to:

· ?.xsd (xml schema definition)

General form of task command:

<org.modeldriven.ecore2xsd model="${basedir}/wsdl/Calculator.ecore"

genModel="${basedir}/wsdl/Calculator.genmodel" />

where:

· model (source ecore model)

· genModel (target xsd model)

emf.XSD2Java

Essentially the same as emf.Ecore2Java, except the source model is an xsd model. The syntax of the <PACKAGE> construct within the arg line is altered to become:

<PACKAGE> ::= -packages [<nsURI>]+

org.modeldriven.ecore2uml

Converts an ecore model to:

· ?.uml (uml model)

Converts a combination of an ecore model, gmf graph model, and gmf tool model to:

· ?.gmfmap (a gmf map model)

General form of task command:

<org.modeldriven.ecore2gmfmap

model="${basedir}/wsdl5/Calculator.ecore"

domainMetaElement="CalculationTask"

graphModel="${basedir}/wsdl5/Calculator.gmfgraph"

toolModel="${basedir}/wsdl5/Calculator.gmftool"

targetModel="${basedir}/wsdl5/Calculator.gmfmap"/>

where:

· model (source ecore model)

· targetModel (target gmf map model)

· graphModel (source gmf graph model)

· toolModel (source gmf tool model)

· domainMetaElement (Name of the EClass which represents top node in a containment hierarchy)

org.modeldriven.gmfmap2gmfgen

Converts a gmf map model and its corresponding genmodel to:

· ?.gmfgen (a gmf generation model)

General form of task command:

<org.modeldriven.gmfmap2gmfgen model="${basedir}/wsdl5/Calculator.gmfmap"

genModel="${basedir}/wsdl5/Calculator.genmodel"

targetModel="${basedir}/wsdl5/Calculator.gmfgen"/>

where:

· model (source gmf map model)

· targetModel (target gmf gen model)

· genModel (source emf gen model for the original emf model)

ATL is a hybrid declarative/imperative language leveraging the OMG OCL (Object Constraint Language).

Artifacts associated with the use of ATL include:

· *.atl. The transformation specification itself.

· *.asm An artifact produced by ATL tooling as a “compiled” representation of the original atl. An asm is constructed from an atl during project build cycle by an “Atl builder”.

· .project The “.project” file includes a specification of the “ATL nature” and the use of the “Atl builder” to be executed during the project build cycle.

· *.launch. A launch configuration which includes binding an *.atl specification to specific source and target models.

· Source models and meta-models. A specific configuration of a fixed number of source models and their associated meta-models.

· Target models and meta-models. A specific configuration of a fixed number of target models and their associated meta-models.

Within a ModelPro provisioning cycle, ATL may be utilized as a means for producing EMF model artifacts which are subsequently processed by additional ModelPro provisioning steps, or by other tools, to produce required target technology artifacts. For example, the information model portion of a UML model may be transformed via ATL into an ecore model, and then further processed to produce SDO java implementation artifacts and an XSD Schema using standard eclipse tools.

Since ATL (and other QVT transformers) are bound to specific configurations of source and target models, there is a requirement to provide a “launch” binding for each permutation of source/target model configuration. ModelPro may be used to generate multiple launch configurations, projects, and downstream bindings of target models to tools. ModelPro templates would typically generate:

· *.atl. (See note below).

· .project The “.project” file combines “ATL nature” and “Atl builder” descriptions with other target technology descriptions.

· *.launch. A launch configuration for each required permutation of source/target model configuration. Source models, source meta-models, and target meta-models may be resident in the workspace, plugins, network locations, or simply one of the original resources being processed by the ModelPro provisioning launch. Target models should normally be within the currently targeted project folder.

· * Artifacts for down-stream tool invocation, such as ant build scripts and/or launches.

Note:ATL files generally do not need the parametric variable substitution facilities provided by templates, but may require model-dependent target artifact locations. Furthermore, construction and debug of atl specifications are facilitated by a model-aware atl editor. One convenient way to achieve both model-dependent target artifact location specification and atl editing is to utilize the VTL #include directive within a template of the form:

Text Box: #**
description of the template purpose
@projectPath /some/path/to/myTransform.atl
@artifactContext singleton
*##include("myTransform.atl")

For each meta-model specification within an ATL launch, there is a “model handler”. ATL includes model handlers named EMF and UML. ModelPro provides an additional model handler named “ModelPro” which includes some additional capabilities and/or corrections to the native ATL model handlers. Additional capabilities include handling of arbitrary ecore EDataTypes, all resources in a ResourceSet, applied stereotypes.

Some project examples are provided with modelPro which incorporate ATL, see Eclipse menu File/NewàExample…àmodelPro.

Examples

Examples in which the concepts outlined in this chapter are employed include:

· UML to Diagram

· SoaML to BPMN

· SoaML to SCA/SDO

· SMOF

· WSDL to UML

Most of these examples may be executed as actions upon a selected model:

· From a navigation pane, right click on a model

· Select the pull-down menu item for the appropriate action as exemplified below:

Examples as projects (i.e., source specifications) may be obtained via the Examples.. User Assist capability.

UML to Diagram

The UML to diagram action simply generates a set of GMF diagram model instance shells for a selected UML model. The diagram models are all produced using trivial templates. When opened, the underlying diagram implementation will auto-align the appropriate model elements and allow for graphical editing of the targeted model elements.

Result of executing the action will be a set of diagram models in a sibling directory named “diagram”. Double-click a diagram model to open a diagram editor:

SoaML to BPMN

The SoaML (UML) to BPMN action generates the following types of artifacts:

· BPMN models. The provisioning is based on the ATL Model-to-Model transformation engine.

· Ancillary technology artifacts required to define an eclipse project and its associated launch definitions required for ATL execution. These artifacts are provisioned from templates.

The result of invoking the provisioning action will be a project focused on the BPMN model, having a small number of artifacts, and exemplified in following:

Utilizing eclipse BPMN tools, a graphical BPMN diagram can be created and used to edit the model, as illustrated below:

SoaML to SCA/SDO

The SoaML (UML) to SCA/SDO action generates several projects:

· An ecore model plug-in project representing the SDOs. This will include, in addition to java implementation of the SDO/EMF the following models:

o The sdo ecore model and genmodel.

o Schemas (*.xsd) corresponding to the ecore model

o An ecore instance diagram.

o Various GMF graph, map, tool models.

· An edit plug-in project corresponding to the SDO ecore model.

· A graphical diagram plug-in project corresponding to the SDO ecore model and edit plug-in.

· An SCA project for SCA component definitions and java implementations.

The SDO ECORE model is produced via an ATL based model-to-model transform.

· Supporting build artifacts are provisioned via Templates.

· The build artifacts are used to drive the secondary provisioning processes such as java code generation, schema generations, GMF models, etc.

· The secondary level provisioning process uses available eclipse tools, including those described in “model-to-model conversion tasks”. .

The SCA component definitions and associated java implementations are all provisioned from templates.

A sample of the plug-in and other projects provisioned from an example SoaML model (projects with “.sca” suffix are sca projects; project with “.sdo” suffix are ado projects):

In conjunction with eclipse+Apache SCA/SDO support, resulting artifacts are intended to be realized in a SOA environment. The SCA run-time environment handles the infrastructural requirements, such as dynamic generation of WSDL and technology bindings, (presumably) leaving the focus of additional effort to the implementation of business logic.

SMOF

An example of dedicated provisioning task: transform an OMG UML Specification of “SMOF” into an EMF/Ecore implementation. The result of provisioning are the following types of artifacts:

· An ecore model plug-in project which implements the SMOF. This includes, in addition to java implementation of the SMOF, the following models:

o The SMOF ecore model and genmodel.

o An ecore instance diagram.

o Various GMF graph, map, tool models.

· An edit plug-in project corresponding to the SMOF ecore model.

· An editor plug-in project corresponding to the SMOF ecore model.

The SMOF ECORE model is produced via an ATL based model-to-model transform.

· Supporting build artifacts are provisioned via Templates.

· The build artifacts are used to drive the secondary provisioning processes such as java code generation, edit and editor plug-in creation, GMF models, etc.

· The secondary level provisioning process uses available eclipse tools, including those described in “model-to-model conversion tasks”. .

A sample of the primary SMOF plug-in provisioned from the UML SMOF model:

Resulting artifacts are intended to serve as an augmentation of the Ecore implementation layer and enable the semantic concepts defined by SMOF to be applied to any Ecore-based model. The focus of additional effort related to SMOF includes (manual) implementation of business logic not formally expressed in the UML model.

WSDL to UML

The WSDL to SoaML (UML) action generates the following types of artifacts:

· UML model. The provisioning is based on the ATL Model-to-Model transformation engine, in this case transforming WSDL + XSD (as models) into UML.

· Ancillary technology artifacts required to define and execute the ATL transformation, plus requisite SoaML profile models. These artifacts are provisioned from templates (primarily as “included” copies of original definitions).

The result of invoking the provisioning action will be a sibling folder (named “model”) to the source WSDL model, having a small number of artifacts, and exemplified in following:

[i]