Transformations

This content applies to version 7.5.2 or later. A transformation is a mechanism that takes a set of source elements and changes them into a new set of target elements.

A transformation is a set of transforms that you can configure, specify as public in the plug-in manifest file, and run using a transformation configuration.

The relationship between the source and target elements is defined by a set of rules that is contained in a transformation. The application of these rules is based on extractors that specify how to traverse the source set of elements. The transformation might depend on a profile to apply more information to its rules.

Transformations enable you to convert UML models to code, convert code to UML models, and convert models to models at a different level of abstraction. There are four categories of transformations:

Also, transformations can implement patterns to convert elements from one form to another.

The most common starting point for a transformation is a platform-independent model (PIM), such as a class model. A class model contains design elements with no reference to implementation specifics. You can create, modify, and annotate class models, and then use transformations to generate a platform-specific model (PSM), such as a Java topic diagram or code-level text.

Note: For more information on PIMs, which are a key part of the Object Management Group's (OMG) defined process for model-driven architecture (MDA) and model-driven development (MDD), visit the Object Management Group Web site.

As a part of their packaging, patterns can also define and provide transformation extensions that define additional rules to be applied when they cross specific levels of abstraction or specific metamodels. A common implementation of this concept is a design pattern that provides transformation rules to generate specific code. These rules would extend a code transformation, for example, a Java or C++ transformation, to provide pattern-specific code to the generated output.

You need the following four pieces of information to apply a particular transformation:
Transformation
A reference to the particular transformation being applied
Transformation context
Contains the values for all of the parameters of the transformation
Source
The initial object, or set of objects, passed into the transformation operation
Target container
A reference to the locations where any generated artifacts are located

A very basic process of model transformation includes the following steps, which you can perform iteratively:

  1. Apply a profile to the model that defines additional stereotypes that can be used.
  2. Apply these stereotypes to the existing model elements.
  3. Add the information, through stereotype properties, that these stereotypes provide, as well as any information from the base model that the transformation requires.
  4. Select a transformation from the workbench and initiate the transformation operation.

The result of a completed transformation is the target model, or text, and a record of the transformation for traceability purposes. In model-to-text transformations, the output could be Java or C++ code, Data Definition Language (DDL) files for database creation and population, unit tests, or visualization diagrams that match corresponding modeling diagrams. The record of transformation includes a map from the element in the source model to the corresponding elements of the target, and shows which parts of the mapping were used for each part of the transformation.

You can create new transformations by using the transformation API. To create a transformation that you can configure by using a transformation configuration, you must add the com.ibm.xtools.transform.core.transformationProviders extension to the plugin.xml file in the plug-in that contains the transformation. The transformation provider defines extensions of type Transformation for each transformation that it provides. Adding these extensions automatically registers the transformation, or transformations, with the transformation service. The transformation service is generic and has no assumptions about the source model, the target model, or the implementation of the transformation itself. Although the transformation service contains a default transformation engine, a transformation author could use an engine that is completely different. However, by building transformations on the default engine, transformation authors can take advantage of the logical debugging environment, the extensibility mechanism, and any future improvements to that architecture.

Transformation configurations

A transformation configuration is an instance of a transformation that includes information that all transformations use, such as a unique name, the source, and the target of the transformation; it can also include properties that are specific to a given transformation. A transformation configuration has .tc as a file name extension. When you run a transformation, it uses the information that you provide in the transformation configuration.

Before you can run a transformation, you must create a transformation configuration. When you apply a transformation configuration, an instance of the transformation is created and runs with the properties that you define in that configuration, generating the output that you expect.

You can share properties in a transformation configuration with other transformation configurations by establishing hierarchical relationships programmatically. This feature allows transformation configurations to inherit their property values from the properties in a default transformation configuration. A transformation configuration can have multiple parents, and the order in which you specify the relationships by using the public API determines the priority of a configuration when multiple configurations specify the same properties. Therefore, if a default property set is changed, all the transformation configurations in the system that use that property set inherit the changes.


Feedback