Skip to main content
Jump to: navigation, search

Papyrus/designer/transformations

< Papyrus
Revision as of 07:46, 3 July 2021 by Ansgar.radermacher.cea.fr (Talk | contribs) (Created page with "= Use a transformation = Papyrus SW designer can execute a set of model to model transformation prior to code generation. This can be done in two different ways: * Apply the...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Use a transformation

Papyrus SW designer can execute a set of model to model transformation prior to code generation. This can be done in two different ways:

  • Apply the stereotype ExecuteTrafoChain. Use this, if you want to apply a transformation, but without specifying the instances of your system.
  • Apply the stereotype DeploymentPlan (a specialization of ExecuteTrafoChain). This stereotype enables the definition of component or class instances along with an allocation to a node of a distributed system. SW Designer will include a transformation that creates code for each deployment node and a bootloader that starts the software on this node.

As the focus of this section is the use of transformations, we only present the ExecuteTrafoChain stereotype which is the base stereotype for the DeploymentPlan. The stereotype that can be applied to a package has the following attributes

  • chain: M2MTrafoChain - the principal transformation chain that should be executed. A Chain is a set of M2M transformations. This attribute is optional. If left empty, one of the two default transformation chains (see below) is chosen.
  • additionalTrafos: M2MTrafo[0..*] - a set of additional transformations that are added to the principal chain
  • additionalChains: M2MTrafoChain[0..*] - a set of additional transformation chains that are added to the principal transformation chain.

Write a new transformation chain

A transformation chain is represented by the stereotype M2MTrafoChain. Instead of using attributes of the stereotype, the different steps within the chain are representation by the attributes of a class that applies the stereotype M2MTrafoChain.

Depending of whether a deployment plan is used or a simple transformation, one of the following chains us used by default. The chains are defined in the model "trafos", in plugin oep.designer.transformation.library/models/library.

  • The standard transformation chain in case of a deployment plan.
    • normalization - normalize model in the sense??
    • m2MFromStereotype - manual transformation
    • statemachine - state machine transformation (depending on programming language)
    • applyIConI - instance configuration on intermediate model
    • writeTmpModels - write temporary models (tmpModel folder in project containing the source model)
    • deployToNodes - split models into a model for each node
    • createAndConfigure - create and configure a target project (for CDT or JDT)
    • applyICOnT - apply instance configuratioin on target model
    • bootloaderCreation - create a bootloader, i.e. create Java or C/C++ instances for each instance specification in the deployment plan
    • generateCode - generate code
    • writeModels - write the target models (models folder in target project)
  • The standard transformation chain in case of ExecuteTrafoChain
    • normalization - normalize model in the sense??
    • m2MFromStereotype - manual transformation
    • statemachine - state machine transformation (depending on programming language)
    • writeTmpModels - write temporary models (tmpModel folder in project containing the source model)
    • copyRequired - copy required elements into target model
    • createAndConfigure - create and configure a target project (for CDT or JDT)
    • generateCode - generate code
    • writeModels - write the target models (models folder in target project)


Write a new Transformation

A model-to-model transformation consists of the following parts:

1. The model based representation. This includes the definition of class applying the stereotype M2MTrafo. The stereotype has two attributes, "before" and "after". Both reference a list of other M2M transformations. In this way, a (half) order of transformation execution can be specified. An example is a transformation that creates additional instance specifications should be executed before bootloader generation.

2. The implementation. The implementation is a Java class that implements one of the following interfaces (all in oep.designer.transformation.core.m2minterfaces package, in the oep.transformation.core plugin, oep = org.eclipse.papyrus)

a. IM2MTrafoCDP - Use this interface for a transformation that needs information in the deployment plan, i.e. either the root package of the model (with the ExecuteTrafoChain stereotype) or a deployment plan. For historical reasons, only the name deploymentPlan appears here. The interface contains a method

 public void applyTrafo(M2MTrafo trafo, Package deploymentPlan) throws TransformationException;

This method is called once during the transformation. The first parameter is a reference to the model element representing the transformation, the second the deployment plan or root package. Transformation typically navigate from the deployment plan to the elements that should be modified.

b. IM2MTrafoElement - Use this information for a transformation that is (potentially) executed for each element. Implementations must overload the method

 public void transformElement(M2MTrafo trafo, Element element) throws TransformationException;

A transformation based on this interface typically checks with an instanceof test whether the passed UML element is an element that is relevant. For instance, a transformation adding getters or setters could check if the passed element is a Property and then add a getter/setter operation (as well as corresponding opaque behaviors for the given language).

c. IM2MTrafoModelSplit - A transformation that could split a model into several new models. For each, a transformation context is created.

 public List<TransformationContext> splitModel(M2MTrafo trafo, Package deploymentPlan) throws TransformationException;

3. The link between the modeled transformation and its implementation is realized via the extension point oep.designer.transformation.m2mTrafo in the plugin.xml file, as shown in the following example. The transformationID corresponds to the qualified name of the transformation in the UML model.

 <extension point="org.eclipse.papyrus.designer.transformation.extensions.m2mTrafo">
   <transformation
     transformationID="trafos::m2mtransformations::BootLoaderGen"
     class="org.eclipse.papyrus.designer.transformation.library.transformations.BootLoaderGen">
   </transformation>
 </extension>

All transformations can have access to context information that is useful for implementing the transformation. The class TransformationContext has a static attribute "current" that references the instance information of the ongoing transformation. The attributes include information about the deployment plan, the model root, the code generator and also a copier. The copier has been used to create the current model (from the original user model that remains unmodified or from an intermediate model). The copier should be used, if additional elements should be copied into the current model.

Back to the top