3.3 Tools

Ever since MDA became a popular buzzword , vendors have claimed that their tools support MDA. Tools that were on the market for many years , even before the name MDA was invented, make these claims. Most of these claims are true, in the sense that they support some aspect of MDA. We will use the MDA framework as shown in Figure 2-7 to analyze what level of support a tool really offers.

3.3.1 Support for Transformations

Support for MDA comes in many different varieties. Simple code generation from a model has been done for more than a decade , and lies well within the boundaries of MDA. The demands that MDA places on models and transformations of models in the ideal situation, however, are very high. In this section we will focus on the support for transformations that tools can offer.

PIM to PSM Transformation Tools

This type of tool transforms a high level PIM into one or more PSMs. This type of tool is barely available at the time of writing, although some tools offer minimal functionality in this area.

PSM to Code Transformation Tools

The most well-known support for MDA is given by tools that act as black-box PSM to code transformation tools. They have a built-in transformation definition and take one predefined type of model as source and produce another predefined type as target. The source model is a PSM, while the target is the code model. In fact, code generation from traditional CASE tools follows this pattern.

Several tools persist the relationship between the PSM and code, and enable you to see changes in either of the models reflected in the other model immediately after the change. This is possible because of the fact that the PSM and code are relatively close to each other, and have almost the same level of abstraction.

PIM to Code Transformation Tools

Another type of tool supports both the PIM to PSM and the PSM to code transformation. Sometimes the user will only see a direct PIM to code transformation and the PSM is left implicit. With this type of tool, the source and target language and the transformation definition are built into the tool that acts as a black box.

UML is usually used as the PIM language. Dynamic functionality that cannot be expressed in UML needs to be added manually in the generated code.

Tunable Transformation Tools

Tools should allow for some tuning or parameterization of a transformation. Access to the transformation definition to adjust it to your own requirements is usually not available. The best one can get today is a transformation definition written in an internal tool-specific scripting language. It is a time-consuming task to make changes to such a script. Because there is no standard language to write transformation definitions yet (see QVT in section 3.1.2), transformation definitions are by definition tool-specific.

Most tools only work for a predefined PIM language, which is often required to be a restricted variant of UML. Although UML diagrams are used to model a PIM, internally the tools do not use the UML language definition, but their own tool-specific definition of UML. Because this does not always follow the UML language definition, even UML experts will have to learn the tool-specific UML definition first and will have difficulty writing transformation definitions.

Transformation Definition Tools

Transformation definition tools support the creation and modification of transformation definitions. This type of tool is needed when you cannot use a transformation definition off the shelf and need to create your own transformation definitions. The only type of transformation definition tool that we have encountered are the tool-specific scripting languages described in the previous paragraph. The heavy dependency of MDA on complex transformation definitions drives a need for a transformation definition language (QVT) and tools that are better suited to this task. More flexible tools should allow a new language definition to be plugged in and used in a transformation. Such tools are not on the market yet.

Because the tools that we have at our disposal today are not ideal, you might conclude that you cannot use MDA successfully today. The situation is far better than that. Although the full potential of MDA might not yet be achievable, the tools we have today can give us enough of the MDA benefits to be useful.

3.3.2 Categorizing Tools

Although transformation tools are at the very heart of an MDA development environment, they are not the only tools that are needed. Next to the functionality that transformation tools bring, other functionality is relevant. For instance, one needs a tool in which models can be made and changed. In Figure 3-1 the functionality that we need in the complete environment is shown. We will explain each item in more detail.

• Code Editor (IDE) : The common functions that are provided by an Interactive Development Environment (IDE), for example, debugging, compilation, and code editing, cannot be missed.

• Code Files : Although we can consider code to be a model, it is usually kept in the form of text-based files. Text-based files are not the format that other "tools" are able to understand. Therefore, we need the following two items:

  • Code File Parser : A parser that reads a text-based code file and stores the code in the model repository in a model-based form that other tools can use.

  • Code File Generator : A generator that reads the code in the model repository and produces a text-based code file.

• Model Repository : The "database" for models, where models are stored and can be queried using XMI, JMI, or IDL (see section 11.2.1).

• Model Editor (CASE tool) : An editor for models, in which models can be constructed and modified.

• Model Validator : Models used for generation of other models must be extremely well-defined . Validators can check models against a set of (predefined or user-defined) rules to ensure that the model is suitable for use in a transformation.

• Transformation Definition Editor : An editor for transformation definitions, in which transformation definitions can be constructed and modified.

• Transformation Definition Repository : The storage for transformation definitions.

Figure 3-1. Functionality in an MDA development environment

Most of today's tools combine a number of functions in a more or less open fashion. The traditional CASE tools provide a model editor and a model repository. A code generator based on a scripting language and plugged into a CASE tool provides the transformation tool and transformation definition editor. In that case, the transformation repository is simply text files.

All functions may come in two forms: language specific or generic. A language-specific tool may, for example, provide a model editor for UML and a code generator from UML to C# only. A generic model editor would enable the user to edit any model, as long as a language definition is available.

Selecting Tools

If you are selecting tools to set up your MDA development environment, the above features can help to find your way among the myriad of tools available. First of all you need to find out your own requirements. Are you happy to be language specific, do you want to be able to combine different tools using standardized interfaces, or are you happy with one monolithic tool that incorporates all the functionality you need?

From the tool perspective, you can investigate what functions are supported by a tool and how language specific they are. You should also check whether the functions, the complete tool, or both, can work on models that are interchanged using standard mechanisms (XMI, JMI, IDL). When you go through all of the potential functions, you are able to get a good characterization of the tool in question. There are no tools that provide all functionality in a fully generic way; therefore, you should be prepared to choose several tools that need to be combined.

Although transformations are at the core of MDA, many tools that claim to support MDA do not perform transformations. Instead, they provide some of the other functionality that is required in an MDA development environment. For instance, a tool may only implement the model repository functionality. This is perfectly all right, because you will need to combine multiple tools anyway. The main issue is to find out what features a specific tool supports.

We have not included a tool comparison in this book because the tool market around MDA is still in flux. As the MDA further evolves, tools will start to support pieces of the MDA process. Any characterization of existing tools will be outdated by the time you are reading this. You are much better off applying the above categorization to tools that you encounter yourself. References to tools that claim MDA support can be found at the OMG website: http://www.omg.org/mda.