Transformations

A transformation is the mechanism that takes a source set of elements and changes them into a new target set of elements. Like round-trip engineering (RTE) in Rational Rose®, the result of a transformation can be code generated from a model. However, transformations are customizable and vastly more powerful than RTE in what they can do.

Note: Capabilities such as visual editing and language transformations are not offered in Software Modeler.

The relationship between the source and target elements is defined by a set of rules contained within a transformation. The execution of these rules is based on rule sets that understand how to traverse the source set of elements. The transformation may depend on a profile to apply more information to its rules.

Transformation services (and patterns) bridge the gap between UML models and code, as well as between models at different levels of abstraction. Transformations can be, amongst others:

Also, transformations can implement patterns to convert elements from one form to another. Transformations installed with the product are available through commands in Software Architect and Systems Developer.

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), refer to www.omg.org.

As a part of their packaging, patterns can also define and provide transformation extensions that define additional rules to be executed when crossing specific levels of abstraction or specific meta-models. 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 in order to apply a particular transformation:

A very basic process of model transformation includes the following steps:

  1. If required by the transformation selected, apply a profile to the model that defines additional stereotypes that can be used.
  2. Apply these stereotypes to the existing model elements, as required.
  3. Fill in the new information (through stereotype properties) provided by these stereotypes, as well as any information from the base model required for the transformation.
  4. Select a transformation from the IDE and initiate the transformation operation.
Note: You can perform these steps iteratively.

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

You can create new transformations by using the transformation API. 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.

Related concepts
Model-driven development
UML modeling and visual editing
Multiple model approach versus Rose subunits
Rose top-level model views
Model property sets and UML 2.0 profiles
Feedback
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.