The MDA process, as described in section 1.2.1, shows the role that the various models, PIM, PSM, and code play within the MDA framework. A transformation tool takes a PIM and transforms it into a PSM. A second (or the same) transformation tool transforms the PSM to code. These transformations are essential in the MDA development process. In Figure 1-3 we have shown the transformation tool as a black box. It takes one model as input and produces a second model as its output.
When we open up the transformation tool and take a look inside, we can see what elements are involved in performing the transformation. Somewhere inside the tool there is a definition that describes how a model should be transformed. We call this definition the transformation definition . Figure 2-5 shows the structure of the opened up transformation tool.
Figure 2-5. Transformation definitions inside transformation tools
Note that there is a distinction between the transformation itself, which is the process of generating a new model from another model, and the transformation definition. The transformation tool uses the same transformation definition for each transformation of any input model.
In order for the transformation specification to be applied over and over again, independent of the source model it is applied to, the transformation specification relates constructs from the source language to constructs in the target language. We can, for example, define a transformation definition from UML to C#, which describes which C# should be generated for a (or any!) UML model. This situation is depicted in Figure 2-6.
Figure 2-6. Transformation definitions are defined between languages
In general, we can say that a transformation definition consists of a collection of transformation rules, which are unambiguous specifications of the way that (a part of) one model can be used to create (a part of) another model. Based on these observations, we can now define transformation, transformation rule, and transformation definition.
To be useful at all, a transformation must have specific characteristics. The most important characteristic is that a transformation should preserve meaning between the source and the target model. Of course, the meaning of a model can only be preserved insofar as it can be expressed in both the source and the target model. For example, specification of behavior may be part of a UML model, but not of an Entity-Relationship (ER) model. Even so, the UML model may be transformed into an ER model, preserving the structural characteristics of the system only.
2.3.1 Transformations between Identical Languages
The definition above does not put any limitations on the source and target languages. This means that the source and target model may be written in either the same or in a different language. We can define transformations from a UML model to a UML model or from Java to Java.
There are several situations where this may occur. The technique of refactoring a model or a piece of code (remember code is also a model) can be described by a transformation definition between models in the same language. Another well-known example of a transformation definition is the normalization of an ER model. There are well-defined normalization rules that may be applied over and over again on different ER models with a determined outcome. For instance, the normalization rule that produces a model in the second normal form is:
This rule may be applied to any ER model. It relates one entity and its attributes in the source model to two entities, their attributes, and a relationship in the target model, where both source and target model are written in the ER-modeling language.
In the case of transformations between UML models, we need to be very careful. Very often the purpose of the source and target models although both in UML, is completely different. In the examples in section 2.5, later in this chapter, we define a transformation from a PIM in UML to a PSM in UML. The trick is that the PSM is restricted to use only constructs from UML that can be mapped one-to-one onto constructs in the Java language. Conceptually, the target language is not plain UML, but a specific subset of UML, which we could call UML-for-Java. This kind of use of UML occurs often, and it is hard to recognize.
The UML-for-Java subset can be formalized by defining a UML profile for Java. Any UML profile in effect defines a completely new language which happens to be derived from the UML language. In Chapter 11 we elaborate on the role of UML profiles in MDA.