7.2 Controlling and Tuning Transformations

A user of a transformation tool will most likely want to have some control over the transformation process. A response of an experienced software developer to the example in section 5.1 was: "But how do I tell the tool that I want the name of Comestible to be transformed to VARCHAR(20), and the transportForm to VARCHAR(50)?" This developer wants to influence some details of the transformation process, which, in our view, is a legitimate request.

There are several ways in which a user may control the transformation process. In the following sections we describe them all. When choosing your transformation tool, be aware that the options the tool offers to exercise control can be very different from tool to tool.

7.2.1 Manual Control

The most direct control a user can have over a transformation is to be able to manually define which model element is transformed by which transformation rule. This is by definition the most flexible solution, but it is error-prone and much work for the user. Imagine taking these decisions for even a small class model with ten classes, 40 attributes, 12 associations, and 100 operations. You'll be asked to make at least 162 choices. Most users will end up hitting the "OK" button blindly. For larger models, the situation becomes impossible to handle. Therefore, we need to take a look at solutions that scale up in practice.

7.2.2 Conditions on Transformations

Another way of giving the user the power of control is by attaching a condition to each transformation rule. This condition describes when the rule should be applied. A transformation rule will not simply look like: "Every class is transformed into ... ," but something like, "Every class with stereotype <<persistent>> is transformed into ..." In principle, all properties of the model elements in the source model can be used in this condition. Even very detailed rules like, "Every class with string 'THING' in its name is transformed into ... ," or "Every class associated with a class named 'XYZ' is transformed into ... " should be expressible.

Preferably we should make the conditions mutually exclusive. This allows full automation of the transformation process. This approach can be combined with the manual control for those cases where more than one condition holds.

7.2.3 Transformation Parameters

The transformation process can also be tuned by using parameters. Transformation definitions can be parameterized to make them conform to a certain style. For example, when transforming a public attribute to a private attribute with getter and setter operations the exact prefix strings (usually get and set ) can be defined as parameters of the transformation. When a transformation is performed, the user needs to set these parameters. Providing default values can help to avoid mandatory lengthy parameter lists. Other typical parameters can be the length of fixed-length data types, and so on.

In Rosa's example in section 5.1, the transformation definition from PIM to the Relational PSM transformed each "String" in the PIM into a VARCHAR(40) in the PSM. The choice of the length 40 is rather arbitrary and could better be defined as a parameter of the transformation. This allows the developer to influence selected details that are made during the transformation process.

7.2.4 Additional Information

Sometimes we want to formulate a condition, but find that the information we need is not among the properties of the elements in the source model. As a consequence of this, we cannot write the condition, need user intervention, and have to fall back to manual control.

In Rosa's example, the length of the transformed String in the Relational PSM was chosen to be 40. As we have seen in the previous section, this can better be defined as a parameter. However, it might be not desirable to transform each String in the PIM to the same length in the PSM. The developer might want to use different lenghts for different attributes. A "name" attribute could, for example, have a length of 40, while a typical "description" attribute might need to be much longer (say 256). Whether a String instance is a "name" or a "description" cannot be found in the PIM and needs to be added somewhere.



MDA Explained. The Model Driven Architecture(c) Practice and Promise 2003
Project Leadership (The Project Management Essential Library)
ISBN: N/A
EAN: 2147483647
Year: 2004
Pages: 118

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net