This chapter describes what has been achieved within the MDA at the time of writing. Hopefully, by the time you read this, the technology will have advanced somewhat further. This chapter gives an overview of the various OMG standards that can be used within the MDA, the tool support that you can expect, and development processes that you can use.
The MDA is defined and trademarked by the OMG. We therefore first take a look at the OMG standards that play a role within the MDA framework.
The OMG defines a number of modeling languages that are suitable to write either PIMs or PSMs. The most well-known language is UML. This is the most widely used modeling language.
The Object Constraint Language (OCL) is a query and expression language for UML, which is an integral part of the UML standard. The term “Constraint” in the name is an unfortunate leftover from the time when OCL was used to specify only constraints to UML models. Currently, OCL is a full query language, comparable to SQL in its expressive power.
The Action Semantics (AS) for UML defines the semantics of behavioral models in UML. Unfortunately, it defines the behavior at a low-level foundation. Therefore, it is not directly suitable for writing PIMs. It lacks the higher level of abstraction that is necessary. The AS is not a language that can be used directly by a modeler, because it does not define a concrete syntax; you cannot write down anything at all in a standardized way.
UML includes a profile mechanism that enables us to define languages derived from the UML language. The language defined in the profile is a subset of UML with additional constraints and suitable for a specific use. It uses the UML diagrammatic notation and OCL textual queries, and looks like UML. Many such profiles are standardized by the OMG; others are not standardized, but publicly available. Official OMG profiles include the CORBA Profile, the Enterprise Distributed Object Computing (EDOC) Profile, the Enterprise Application Integration (EAI) Profile, and the Scheduling, Performance, and Time Profile. More profiles are being developed and will be standardized in the coming years. Profiles are usually suitable for writing PSMs.
The UML/EJB Mapping Specification (EJB01) is an example of a profile that is standardized through the Java Community Process. Several profiles for other programming languages, like Java, C#, and so on, are defined by individual organizations and tool vendors.
Another language that is defined by the OMG is the Common Warehouse Metamodel (CWM). This is a language specifically designed to model data mining and related systems.
Chapter 11 describes the various OMG languages and their role in MDA in more detail.
Languages used within the MDA need to have formal definitions so that tools will be able to automatically transform the models written in those languages. All of the languages standardized by the OMG have such a formal definition. The OMG has a special language called the Meta Object Facility (MOF), which is used to define all other languages. This ensures that tools are able to read and write all languages standardized by the OMG.
The transformation definitions used in the MDA framework are currently defined in a completely nonstandardized way. To allow standardization of these transformation definitions, the OMG is currently working on a standard language to write transformation definitions. This standard is called QVT, which stands for Query, Views, and Transformations. At the time of writing, the Request for Proposals (RfP) for QVT has been published. QVT is still being worked on by OMG members so we don't yet know exactly how the finished specification will look.
As seen in section 1.3.1 the level of completeness, consistency, and unambiguity of a PIM must be very high. Otherwise, it is not possible to generate a PSM from a PIM. Let's investigate to what extent UML is a good language for building PIMs.
The strongest point in UML is the modeling of the structural aspects of a system. This is mainly done through the use of class models, which enables us to generate a PSM with all structural features in place. The example in Chapter 4 shows how this is done.
UML has some weak points that stop us from generating a complete PSM from a PIM. The weak area in UML is in the behavioral or dynamic part. UML includes many different diagrams to model dynamics, but their definition is not formal and complete enough to enable the generation of a PSM. For example, what code (for any platform) would you generate from an interaction diagram, or from a use case?
Plain UML is suitable to build PIMs in which the structural aspects are important. When a PSM is generated, a lot of the work still remains to be done on the resulting model, to define the dynamic aspects of the system.
Executable UML (Mellor 2002) is defined as plain UML combined with the dynamic behavior of the Action Semantics (AS). The concrete syntax used in Executable UML has not been standardized.
The strength of plain UML, modeling the structural aspect, is present in Executable UML as well. Executable UML to some extent mends the weak point in plain UML, the modeling of behavior. In Executable UML the state machine becomes the anchor point for defining behavior. Each state is enhanced with a procedure written in the AS.
In principle, Executable UML is capable of specifying a PIM and generating a complete PSM, but there are a few problems:
Relying on state machines to specify complete behavior is only useful in specific domains, especially embedded software development. In other, more administrative, domains the use of state machines to define all behavior is too cumbersome to be used in practice.
The AS language is not a very high-level language. In fact, the concepts used are at the same abstraction level as a PSM. Therefore, using Executable UML has little advantage over writing the dynamics of the system in the PSM directly. You will have to write the same amount of code, at the same level of abstraction.
The AS language does not have a standardized concrete syntax or notation; therefore, you cannot write anything in a standard way.
Executable UML is suitable within specialized domains, but even there the benefits might be less than you would expect, because of the low abstraction level of the action language.
Using the combination of UML with OCL to build a PIM allows for PIMs that have a high quality; that is, they are consistent, full of information, and precise. The strong structural aspect of UML can be utilized and made fully complete and consistent. Query operations can be defined completely by writing the body of the operation as an OCL expression. Business rules can be specified using OCL, including dynamic triggers.
The dynamics of the system can be expressed by pre- and post-conditions on operations. For relatively simple operations the body of the corresponding operation might be generated from the post-condition, but most of the time the body of the operation must be written in the PSM. In that case, generating code for the pre- and post-condition ensures that the code written in the PSM conforms to the required specification in the PIM.
Although the dynamics of the systems still cannot be fully specified in the UML–OCL combination, the combination of UML class models with OCL allows for a much more complete generation of PSMs and code than does plain UML. The use of the combination of UML and OCL is at the moment of this writing probably the best way to develop a high quality and high level PIM, because this results in precise, unambiguous, and consistent models that contain much information about the system to be implemented.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
The MDA does not require a specific process to be used for software development. Processes are not standardized by the OMG, so you are free to choose your own. Of course, the central position of models and transformations in MDA should be reflected in such a process. We will take a short look at some of the more popular processes and show how they can be used for MDA development.
A current trend in the software development process is to minimize the amount of effort and time spent in building models that will only serve as documentation, even though they do capture some of the interesting aspects of the software to be built. The purpose is to ensure that software is delivered that works for the users. Since requirements continuously change, the software that is being developed must change accordingly. The ability for a software project to accommodate changes in a flexible and immediate way is the core aspect of Agile Software Development. According to Cockburn (2002), “Working software is valued over comprehensive documentation.” Well, we couldn't agree more. At the Web site http://agilemanifesto.org you can find the Agile Manifesto describing the agile principles. On this website you may post a quote why you like this approach. The quote from one of the authors of this book is:
As co-author of the UML standard, people usually think I love large and detailed models. The contrary is true, a model is only worth building if it directly helps to achieve the final goal: building a working system. With the emergence of MDA tools, it becomes possible to directly move from model to code. This “promotes” models from being merely documentation to becoming part of the delivered software, just like the source code.
Because changing a model means changing the software, the MDA approach helps support agile software development.
The XP approach is a very popular way of working, where the focus lies on writing code in small increments, such that you have a working system all the time. Each new requirement must be accompanied by an explicit test case, which is used to test the software. When adding new functionality, all previous tests are run in addition to the new tests, to ensure that existing functionality is not broken.
As we explained in section 1.1.1, the focus on code only is too limited. Code must be augmented with so-called “markers” that document the code at a higher level. In extreme programming this is often seen as overhead. When we realize that these markers may take the form of MDA models that directly transform into code, creating these markers is not overhead anymore. On the contrary, the high-level models help to develop the software faster.
This means that we can bring XP to a higher abstraction level, and we might want to talk about “Extreme Modeling.”
The RUP is a process that is much more elaborate, or much heavier, than the agile or extreme processes. Project managers often like these larger and more structured processes because they give a better feeling of control over the project. Especially for large projects, it is clear that a more elaborate process than extreme programming is needed. On the other hand, many people consider the RUP process as being too large and unwieldy, favoring bureaucratic development of large stacks of paper over “real” software development, i.e., writing code.
UML plays an important role within RUP. Many of the artifacts in RUP take the form of some UML model. If we are able to use these models in an MDA fashion, they can be used to generate PSMs and code. When we configure RUP for an MDA project, we need to make sure that the models that we produce fulfill the requirements that MDA puts on them.
When we do this, the models used in RUP are no longer bureaucratic overhead; they become “real” software development. The balance between writing paper documents and developing code moves more into the direction of developing code. At the same time, the artifacts that are produced will satisfy project managers in their quest for keeping control.
In this chapter we have seen that the MDA framework can be populated by a number of different OMG standards. At the same time standards like the MOF and UML profiles allow non-OMG organizations to develop their own standards that will fit seamlessly in the MDA framework.
Tools are of great importance to the success of MDA. A wide spectrum of functionality is needed in an MDA environment, including traditional tools. Each tool may provide some or more of the functionality needed, and there are standardized ways that tools can communicate with each other.
Note that MDA is an emerging technology that is still in its infancy. Neither the languages nor the tools are developed enough to achieve the hundred percent code generation that is promised by MDA. There is always a need for manual change within the generated code. However, tools can provide enough functionality to make a significant impact on your software development process.
MDA can be used in existing software development processes. What is needed is more focus on the models that are developed to ensure that they are complete and consistent enough to be used in MDA transformations.
In Chapter 12 we take a look at the promise that MDA brings us. When the languages and tools become more mature, MDA has the ability to become a major paradigm shift in the software development community.