7.6 Implications on Transformations

What are the implications of the desired features on the transformations? In short, there are two things we require of a transformation:

• It should have parameters with which you can tune it.

• It should maintain a persistent source-target relationship.

7.6.1 Transformation Parameters

In order to achieve the first requirement, we add parameters to the transformation rules in the transformation definition. For each parameter we can set a default value. For instance, the rule from section 5.1 for transforming Strings to VARCHARs becomes:

• A UML string is mapped onto a SQL VARCHAR (parameter i: Integer [default=20] )

Every application of this rule in the transformation process needs to have its own value for parameter i . In most cases the default value will be used, but for the tool to be able to support the requested user control, variation of the default must be possible. The tool might, for instance, produce a list of UML Strings in the source model that are transformed according to the rule above. The user will indicate for which of the UML Strings a different parameter value should be used. In Rosa's example the following table could be shown, in which the user has already changed the value of the parameter for Comestible.transportForm .

Table 7-1. Using Transformation Parameters for the Length of a VARCHAR

Name of source element	Transformed to	Parameter value
Comestible.name	VARCHAR	20
Comestible.transportForm	VARCHAR	40
StandardBreakfast.name	VARCHAR	20

Of course, the values indicated by the user should persist when the target needs to be regenerated. No user wants to enter those data over and over again. To realize this, there are three options:

1. Add this information to the source model

2. Add it to the target model

3. Create an intermediate transformation object that holds this information

The first option is a popular one; many tools choose to implement transformation parameters this way. The source model, usually the PIM, is augmented with tags that hold this type of information. In our view, this additional information clutters the source model. The additional information does not really belong to the source model, it belongs to the transformation. For example, the stereotype <<persistent>> does not really belong in a platform independent model and is just pollution from the business point of view. Using the types ShortString and LongString in the PIM to solve the VARCHAR length in the Relational PSM also pollutes the PIM. In the case where one PIM is being transformed into a number of PSMs, the PIM becomes overloaded with information that is only relevant to the transformation process.

The second option is popular in lower level tools. For instance, the NetBeans development platform uses this schema to keep information on code that is generated for a visually built user interface. It has some problems though, because a transformation always starts with a source model. Until the first generation has been performed, there is no way to store the needed information. In this option too, the PSM becomes cluttered with information that does not really belong there. Perhaps the best option is option 3. It is much cleaner to store this information as part of the transformation itself, instead of adding it to either PIM or PSM.

7.6.2 Persistent Source-Target Relationship

If we want to ensure that we can keep the source and target models consistent, we have to make sure that no information about the relationship between the source and target model is lost. One way of achieving this is to keep track of the relationships between the elements in the source model and the transformed elements in the target model.

We take a look at how to do this based on the example in section 2.5.2. In this section, the association between Customer and Order is transformed into two attributes in the classes Customer and Order in the design model. More precisely, the association-end orders is transformed into the attribute orders : Set in Customer and the association-end customer is transformed into the attribute customer : Customer in Order . Additionally, getter and setter operations are defined on these attributes.

To keep the information about what has been transformed into what, we can store a link between association-end orders in the source model and attribute orders in the target model, and likewise for customer . This allows us to use the link whenever a change is made in either the source or the target model. The links in the target model allow for a transformation back to the source model, while the links in the source model allow for a renewed forward transformation. If we change the attribute name customer into client in the design model, we could have the reverse transformation to the conceptual model change the role-name customer to client . Or, if we do not want that change in our conceptual model, every renewed (incremental) generation of the design model could use the name client for the attribute instead of customer . Without the additional information about the original transformation, this would be impossible .

Keeping these links in the source and target models clutters these models with details that are not really part of the models. Figure 7-2 shows all the additional links that need to be included in the two models. The situation gets even more complicated when there are multiple transformations to multiple target models from one single source model. In the example for Rosa's Breakfast Service in Chapter 4, the PIM is transformed to three different models: the database model, the EJB model, and the Web model. If we follow the approach described above, we need to store all information about all these transformations inside the PIM. It is clear that this leads to large scale pollution in the PIM. The PIM also includes many additional fields to hold the references to the platform specific models. With each new target, new links need to be added to the source model. We need a strict separation of concerns to manage this transformation information in a maintainable way.

Figure 7-2. Keeping transformation information in the models

7.6.3 Transformation Rules as Objects

The relationship between the source and target model is not a property of either model, but it is really a property of the transformation itself. Using the principle of separation of concerns, this leads us to introduce the transformation as an object in its own right. By promoting the transformation into an object with internal state and structure, we are able to store the required information in the transformation itself without cluttering the source and target models.

For each transformation rule that is performed, a separate instance of a transformation object is created. This transformation instance keeps track of all additional information for the specific transformation rule. Figure 7-3 shows this transformation instance for the Order/Customer example. All links are directed from the transformation instance to the models involved. As we can see in the figure, the models themselves do not contain any transformation specific information. This information is owned by the transformation instance. Also note that a transformation instance consists of multiple objects, each holding a piece of the transformation information.

Figure 7-3. Transformation as a separate object

From the point of view of the transformation objects, the direction of the transformation is irrelevant. Transformation objects contain the information that is the result of the transformation process. Usually there is one transformation object for each application of a transformation rule. In Figure 7-2 and Figure 7-3 the rule Association-end-attribute is applied twice, resulting in two transformation objects.