A transformation is the mechanism that takes a source set of elements and changes them into a new target set of elements. Like code-model synchronization in Rational® XDE®, the result of a transformation can be code generated from a model. However, transformations are customizable and more powerful than synchronization in what they can do.
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 (and patterns) bridge the gap between UML models and code, as well as between models at different levels of abstraction. Transformations can be, among others
Also, transformations can implement patterns to convert elements from one form to another. Transforms 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 PSM (platform specific model, such as a Java™ topic diagram) or code-level text.
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:
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.