1.2 Model Driven Architecture

The Model Driven Architecture (MDA) is gradually becoming an important aspect of software development. Many tools are, or at least claim to be, MDA- compliant, but what exactly is MDA?

MDA is a framework being built under supervision of the Object Management Group (OMG). It defines how models defined in one language can be transformed into models in other languages. An example of a transformation is the generation of a database schema from a UML model, UML being the source language and SQL being the target language. Source code is also considered to be a model. Code generation from a UML model is therefore another form of transformation.

This section presents a brief introduction to MDA; it is by no means complete. You can find more information about MDA on the OMG Web site and in a number of books; for example, see MDA Explained, The Model Driven Architecture: Practice and Promise , by the same authors [Kleppe03].

1.2.1 PIMs and PSMs

Key to MDA is the importance of models in the software development process. Within MDA, the software development process is driven by the activity of modeling your software system. The MDA process is divided into three steps:

1. Build a model with a high level of abstraction, which is independent of any implementation technology. This is called a Platform Independent Model (PIM).

2. Transform the PIM into one or more models that are tailored to specify your system in terms of the implementation constructs that are available in one specific implementation technology; e.g., a database model or an EJB (Enterprise Java Beans) model. These models are called Platform Specific Models (PSMs).

3. Transform the PSMs to code.

Because a PSM fits its technology very closely, the last transformation is straightforward. The complex step is the one in which a PIM is transformed to a PSM. The relationships between PIM, PSM, source code, and the transformations between them, are depicted in Figure 1-1.

Figure 1-1. The relationship between PIM, PSM, and code

1.2.2 Automation of Transformations

Another key element of MDA is that the transformations are executed by tools. Many tools have been able to transform a platform-specific model to code; there is nothing new about that. What's new is that the transformation from PIM to PSM is automated as well. This is where the obvious benefits of MDA lie. Anyone who has been around a while in the business of software development knows how much time is spent on tasks that are more or less routine. For example, building a database model from an object-oriented design, or building a COM (Common Object Model) component model or an EJB component model from another high-level design. The MDA goal is to automate the cumbersome and laborious part of software development.

1.2.3 MDA Building Blocks

The MDA framework consists of a number of highly related parts. To understand the framework, you must understand both the individual parts and their mutual relationships. Therefore, let's take a closer look at each of the parts of the MDA framework: the models, the modeling languages, the transformation tools, and the transformation definitions, which are depicted in Figure 1-2.

Figure 1-2. The MDA Framework

Models

The first and foremost element of MDA is formed by modelshigh-level models (PIMs) and low-level models (PSMs). The whole idea of MDA is that a PIM can be transformed into more than one PSM, each suited for different target technologies. If the PIM were to reflect design decisions made with only one of the target technologies in mind, it could not be transformed into a PSM based on a different target technology; the PIMs must truly be independent of any implementation technology.

A PSM, conversely, must closely reflect the concepts and constructs used in the corresponding technology. In a PSM targeted at databases, for instance, the table, column, and foreign key concepts should be clearly recognizable. The close relationship between the PSM and its technology ensures that the transformation to code will be efficient and effective.

All models, both PSM and PIM, should be consistent and precise, and contain as much information as possible about the system. This is where OCL can be helpful, because UML diagrams alone do not typically provide enough information.

Modeling Languages

Modeling languages form another element of the MDA framework. Because both PIMs and PSMs are transformed automatically, they should be written in a standard, well-defined modeling language that can be processed by automated tools. Nevertheless, the PIMs are written by hand. Before a system is built, only humans know what it must do. Therefore, PIMs must be written to be understood and corrected by other humans . This places high demands on the modeling language used for PIMs. It must be understood by both humans and machines.

The PSMs, however, will be generated, and the PSM needs to be understood only by automated tools and by experts in that specific technology. The demands on the languages used for specifying PSMs are relatively lower than those on the language for PIMs. Currently, a number of so-called profiles for UML define UML-like languages for specific technologies, e.g., the EJB profile [EJB01].

Transformation Tools

There is a growing market of transformation tools. These tools implement the central part of the MDA approach, thus automating a substantial portion of the software development process. Many tools implement the PSM-to-code transformation. Currently, only a few implement the execution of the transformation definitions from PIM to PSM. Most of the PIM-to-PSM tools are combined with a PSM-to-code component. These tools should offer users the flexibility to tune the transformation to their specific needs.

Transformation Definitions

Another vital part of the MDA framework is formed by the definitions of how a PIM is to be transformed to a specific PSM, and how a PSM is to be transformed into code. Transformation definitions are separated from the tools that will execute them, in order to re-use them, even with different tools. It is not worthwhile to build a transformation definition for onetime use. It is far more effective when a transformation can be executed repeatedly on any PIM or PSM written in a specific language.

Some of the transformation definitions will be user -defined, that is, written by the developers that work according to the MDA process. Preferably, transformation definitions would be in the public domain, perhaps even standardized, and tuneable to the individual needs of its users. Some tool vendors have developed their own transformation definitions, which unfortunately usually cannot be adapted by users because their use is not transparent, but hidden in the functionality of the tools.

1.2.4 MDA Benefits

This section describes some of the advantages of MDA:

1. Portability , increasing application re-use and reducing the cost and complexity of application development and management, now and in the future. MDA brings us portability and platform independency because the PIM is indeed platform independent and can be used to generate several PSMs for different platforms.

2. Productivity , by enabling developers, designers, and system administrators to use languages and concepts they are comfortable with, while still supporting seamless communication and integration across the teams . A productivity gain can be achieved by using tools that fully automate the generation of code from a PSM, and even more when the generation of a PSM from a PIM is automated as well.

3. Cross-platform interoperability , using rigorous methods to guarantee that standards based on multiple implementation technologies all implement identical business functions. The promise of cross-platform interoperability can be fulfilled by tools that not only generate PSMs, but also the bridges between them, and possibly to other platforms as well.

4. Easier maintenance and documentation , as MDA implies that much of the information about the application must be incorporated in the PIM. It also implies that building a PIM takes less effort than writing code.

1.2.5 The Silver Bullet?

When explaining the MDA to software developers, we often get a skeptical response: "This can never work. You cannot generate a complete working program from a model. You will always need to adjust the code." Is MDA just promising another silver bullet?

We believe that MDA may change the future of software development radically . One argument for this is that although MDA is still in its infancy, you can today achieve great gains in productivity, portability, interoperability, and maintenance efforts by applying MDA using a good transformation tool. Therefore, MDA is, and will continue to be, used. A second argument comes from the history of computing.

In the early 1960s, our industry was in the middle of a revolution. The use of existing assembly languages was replaced with the use of procedural languages. There was a lot of skepticism in those days too, and not without reason. The first compilers were not very good. The Algol programming language, for instance, offered the potential to the programmer to give hints to the compiler about how to translate a piece of code. Many programmers were concerned that the generated assembler code would be far less efficient than handwriting the assembler code themselves . Many could not believe that compilers would become proficient enough to stop worrying about this.

To a certain extent the skeptics were right. You lost efficiency and speed, and you could not program all the assembler tricks in a procedural language. However, the advantages of procedural languages became increasingly obvious. Using higher level languages, you can write more complex software much faster, and the resulting code is much easier to maintain. At the same time, better compiler technology diminished the disadvantages. The generated assembler code became more efficient. Today, we accept the fact that we should not program our systems in assembler. Indeed, anyone planning to write a new customer relationship management system in assembler today would be declared insane.

What MDA brings us is another revolution of the same kind. Eventually, PIMs can be compiled (read: transformed) into PSMs, which are compiled into procedural language code (which itself is compiled into assembly or raw machine code). The PIM-to-PSM compilers (read: transformation tools) will not be very efficient for some years to come. Their users will need to provide hints about how to transform parts of a model. Eventually however, the advantage of working on a higher level of abstraction will become clear to everyone in the business.

Concluding, we can say that although MDA is still in its infancy, it shows the potential to radically change the way we develop software. We are likely witnessing the birth of a paradigm shift; and in the near future, software development will shift its focus from code to models.