The MDA Framework

What Is a Model?
The name MDA stresses the fact that models are the focal point of MDA. The models we take into account are models that are relevant to developing software. Note that this includes more than just models of software. When a piece of software is meant to support a business, the business model is relevant as well.

But what exactly do we mean when we use the word model? To come up with a definition that is both general enough to fit many different types of models is difficult. The definition also needs to be specific enough to help us specify automatic transformation of one model into another. In the English dictionary we can find various meanings of model:

The type of an appliance or of a commodity

The example used by an artist

A person posing for an artist

A replica of an item built on a smaller scale, i.e., a miniature

An example of a method of performing work

An ideal used as an example

The form of a piece of clothing or of a hairdo, and so on

What all of the above definitions have in common is that:

A model is always an abstraction of something that exists in reality.

A model is different from the thing it models, e.g., details are left out or its size is different.

A model can be used as an example to produce something that exists in reality.

From these observations, it is apparent that we need a word to indicate "something that exists in reality.[1] " Because all of our models should be relevant in the context of software development, we use the word system. Most of the time the word system refers to a software system, but in the case of a business model, the business itself is the system.

[1] Models themselves are also "things that exist in reality;" therefore, there are models of models. For sake of simplicity, this possibility is not addressed in this chapter. For more on this subject, see Chapter 11, "OMG Standards and Additional Technologies."

Another observation we can make is that a model describes a system in such a way that it can be used to produce a similar system. The new system is not equal to the old one, because a model abstracts away from the details of the system; therefore, details in both old and new system might differ. Yet, because only the details are omitted in the model and the main characteristics remain, the newly produced system has the same main characteristics as the original, i.e., it is similar to it. The more detailed the model is, the more similar the systems it describes will be.

As we set out to find a definition to help us specify the automatic transformation of one model into another, it is clear that not all of the meanings in the dictionary are suitable for use within MDA. Obviously, we will not transform "a person posing for an artist" to another model.

A model is always written in a language. This might be UML, plain English, a programming language, or any other language we can think of. To enable automatic transformation of a model, we need to restrict the models suitable for MDA to models that are written in a well-defined language. A well-defined language has a well-defined form and meaning that can be interpreted automatically by a computer. We consider natural languages as not being well-defined, because they cannot be interpreted by computers. Therefore, they are not suitable for automatic transformations within the MDA framework. From this point onward we use the following definitions:

A model is a description of (part of) a system written in a well-defined language.

A well-defined language is a language with well-defined form (syntax), and meaning (semantics), which is suitable for automated interpretation by a computer.

Note that although many of the example models in this book are written in UML, MDA is certainly not restricted to UML. The only restriction is that the models must be written in a language that is well-defined.

Our definition of model is a very general one. Although most people have a mental picture of a model as being a set of diagrams (as in UML), we do not put any restrictions on the way a model looks (the syntax) as long as it is well-defined. Our definition intentionally includes source code as a model of the software. Source code is written in a well-formed language, the programming language can be understood by a compiler, and it describes a system. It is, of course, a highly platform-specific model, but a model nevertheless. Figure 2-1 shows the relationship between a model, the system it describes, and the language in which it is written. We use the symbols from Figure 2-1 in the remainder of this book to distinguish between models and languages.

Figure 2-1. Models and languages


2.1.1 Relationships between Models
For a given system there can be many different models, that vary in the details that are, or are not, described. It is obvious that two models of the same system have a certain relationship. There are many types of relationships between models. For instance, one model may describe only part of the complete system, while another model describes another, possibly overlapping, part. One model may describe the system with more detail than another. One model may describe the system from a completely different angle than another.

Note that MDA focuses on one specific type of relationship between models: automatic generation of one model from another. This does not mean that the other types of relationships are less important. It only says that these relationships cannot (yet) be automated. For instance, adding attributes to a class and deciding what should be the types of these attributes is not a task that can be automated. It needs human intelligence.
Types of Models
The definition of model given in section 2.1, What Is a Model?, is a very broad one that includes many different kind of models, so we will take a closer look at models. There are many ways to distinguish between types of models, each based on the answer to a question about the model:

In what part of the software development process is the model used? Is it an analysis or design model?

Does the model contain much detail? Is it abstract or detailed?

What is the system that the model describes? Is it a business model or software model?

What aspect of the system does the model describe? Is it a structural or dynamic model?

Is the model targeted at a specific technology? Is it platform independent or platform specific?

At which platform is the model targeted? Is it an EJB, ER, C++, XML, or other model?

What we need to establish is whether these distinctions are relevant in the context of model transformations. The answer to some of the above questions varies according to the circumstances. The distinction made is not a feature of the model itself. Whether a model is considered to be an analysis or design model depends not on the model itself, but on the interpretation of the analysis and design phases in a certain project. Whether a model is considered to be abstract or detailed depends on what is considered to be detail.

When the distinguishing feature is not a feature of the model itself, this feature is not a good indication for characterizing different types of models. So, answering the first two questions in the list above does not clearly distinguish different types of models. The answers to the other questions in the above list do indicate different types of models. We further investigate these distinctions in the following sections.

2.2.1 Business and Software Models
The system described by a business model is a business or a company (or part thereof). Languages that are used for business modeling contain a vocabulary that allows the modeler to specify business processes, stakeholders, departments, dependencies between processes, and so on.

A business model does not necessarily say anything about the software systems used within a company; therefore, it is also called a Computational Independent Model (CIM). Whenever a part of the business is supported by a software system, a specific software model for that system is written. This software model is a description of the software system. Business and software systems describe quite different categories of systems in the real world.

Still, the requirements of the software system are derived from the (part of the) business model that the software needs to support. For most business models there are multiple software systems with different software models. Each software system is used to support a different piece of one business model. So there is a relationship between a business model and the software models that describe the software supporting the business, as shown in Figure 2-2.

Figure 2-2. Business and software models


We have seen that the type of the system described by a model is relevant for model transformations. A CIM is a software independent model used to describe a business system. Certain parts of a CIM may be supported by software systems, but the CIM itself remains software independent. Automatic derivation of PIMs from a CIM is not possible, because the choices of what pieces of a CIM are to be supported by a software system are always human. For each system supporting part of a CIM, a PIM needs to be developed first.

2.2.2 Structural and Dynamic Models
Many people talk about structural models versus dynamic models. In UML, for example, the class diagram is called a structural model and the state diagram a dynamic model, while in reality the class diagram and state diagram are so dependent on each other that they must be regarded as part of the same model.

The fact that we start software modeling by drawing classes in a class diagram doesn't mean we are developing a class model. We are developing a software model by defining static aspects through a static view. If we start our development by drawing a dynamic diagram, like the state or sequence diagram, we are developing a software model by defining dynamic aspects through a dynamic view. Later, when we add a state diagram to our class diagram, or a class diagram to our state diagram, we are merely adding dynamic aspects through a dynamic view to the same model, or vice versa. Therefore, the common terminology is a bit sloppy. The class and state diagrams could better be called structural and dynamic views. Figure 2-3 shows how different diagrams in UML are all views on the same model. They are all written in the same language: UML.

Figure 2-3. Different views of one system in one model


In UML the relationship between dynamic and static views is direct, because they show different visualizations of the same thing in the same model. For example, a class in a UML model is shown as a rectangle with the class name in a class view, while it is shown as the type of an instance in a sequence diagram. The same class can be the anchoring point for a complete state diagram. All the diagrams are views on the same class.

If a system has both structural and dynamic aspects and the language used is able to express both structural and dynamic aspects, the model of the system contains both aspects. Therefore, a UML model of a system includes both the structural and the dynamic aspects, shown in different diagrams.

If structural and dynamic aspects cannot be described in one model because the language used is not able to express certain aspects, there are indeed two models. Note that both models are related; they describe the same system. The type of the model is in such a case more clearly described by naming the language in which it is written than by the use of the connotation "structural" or "dynamic," e.g., an ER-model or Petrinet-model. Figure 2-4 shows a situation where two different models describing the same system are written in two different languages.

Figure 2-4. Different models of one system written in different languages


We can conclude with the observation that the aspect that is described in a diagram or model (i.e., structural, dynamic) is not relevant for the type of a model. The essential characteristic of a model is the language in which the model is written. Some languages are more expressive than others and more suitable for representing certain aspects of a system.

2.2.3 Platform Independent and Platform Specific Models
The MDA standard defines the terms PIM and PSM. The OMG documentation describes this distinction as if this is a clear black-and-white issue. A model is always either a PIM or a PSM. In reality it is difficult to draw the line between platform independent and platform specific. Is a model written in UML specific for the Java platform because one of the class diagrams defines one or more interfaces? Is a model that describes the interactions of components specific for a certain platform only because some of the components are "legacy" components, which may be written in, let's say, COBOL? It is hard to tell.

The only thing one can say about different models is that one model is more (or less) platform specific than another. Within an MDA transformation, we transform a more platform independent model to a model that is more platform specific. Thus, the terms PIM and PSM are relative terms.

2.2.4 The Target Platforms of a Model
The last issue we need to analyze is whether the target platform is a relevant distinction between models in the context of model transformations. Is a design model in UML targeted at Smalltalk distinctively different from a design model in UML targeted at EJB? Yes, most people would say it is. But why? What is the difference?

The difference lies in the use of constructs (in UML) that can be easily mapped to one specific platform, but not to another. A model targeted at EJB has a different structure than a model targeted at Smalltalk. To generate these models from the same PIM we need different transformation rules.

Furthermore, the extent to which a model is platform specific is very important. Using UML profiles (see section 11.8, UML Profiles) a UML model can be made very specific for a certain platform. Such a model should be used as a PSM, not as a PIM. The transformation rules that take such a model as source are quite different from the rules that take a general UML/PIM model as the source.

We conclude that it is very important to know the target platform of a model and the degree to which the model is platform specific. For instance, a relational model targeted at SQL might be specific for a certain database vendor.

What is a Transformation?
The MDA process, as described in section 1.2.1, shows the role that the various models, PIM, PSM, and code play within the MDA framework. A transformation tool takes a PIM and transforms it into a PSM. A second (or the same) transformation tool transforms the PSM to code. These transformations are essential in the MDA development process. In Figure 1-3 we have shown the transformation tool as a black box. It takes one model as input and produces a second model as its output.

When we open up the transformation tool and take a look inside, we can see what elements are involved in performing the transformation. Somewhere inside the tool there is a definition that describes how a model should be transformed. We call this definition the transformation definition. Figure 2-5 shows the structure of the opened up transformation tool.

Figure 2-5. Transformation definitions inside transformation tools


Note that there is a distinction between the transformation itself, which is the process of generating a new model from another model, and the transformation definition. The transformation tool uses the same transformation definition for each transformation of any input model.

In order for the transformation specification to be applied over and over again, independent of the source model it is applied to, the transformation specification relates constructs from the source language to constructs in the target language. We can, for example, define a transformation definition from UML to C#, which describes which C# should be generated for a (or any!) UML model. This situation is depicted in Figure 2-6.

Figure 2-6. Transformation definitions are defined between languages


In general, we can say that a transformation definition consists of a collection of transformation rules, which are unambiguous specifications of the way that (a part of) one model can be used to create (a part of) another model. Based on these observations, we can now define transformation, transformation rule, and transformation definition.

A transformation is the automatic generation of a target model from a source model, according to a transformation definition.

A transformation definition is a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language.

A transformation rule is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language.

To be useful at all, a transformation must have specific characteristics. The most important characteristic is that a transformation should preserve meaning between the source and the target model. Of course, the meaning of a model can only be preserved insofar as it can be expressed in both the source and the target model. For example, specification of behavior may be part of a UML model, but not of an Entity-Relationship (ER) model. Even so, the UML model may be transformed into an ER model, preserving the structural characteristics of the system only.

2.3.1 Transformations between Identical Languages
The definition above does not put any limitations on the source and target languages. This means that the source and target model may be written in either the same or in a different language. We can define transformations from a UML model to a UML model or from Java to Java.

There are several situations where this may occur. The technique of refactoring a model or a piece of code (remember code is also a model) can be described by a transformation definition between models in the same language. Another well-known example of a transformation definition is the normalization of an ER model. There are well-defined normalization rules that may be applied over and over again on different ER models with a determined outcome. For instance, the normalization rule that produces a model in the second normal form is:

Shift all attributes in an entity that are not dependent on the complete key of that entity to a separate entity, holding a relationship between the original entity and the newly created one.

This rule may be applied to any ER model. It relates one entity and its attributes in the source model to two entities, their attributes, and a relationship in the target model, where both source and target model are written in the ER-modeling language.

In the case of transformations between UML models, we need to be very careful. Very often the purpose of the source and target models although both in UML, is completely different. In the examples in section 2.5, later in this chapter, we define a transformation from a PIM in UML to a PSM in UML. The trick is that the PSM is restricted to use only constructs from UML that can be mapped one-to-one onto constructs in the Java language. Conceptually, the target language is not plain UML, but a specific subset of UML, which we could call UML-for-Java. This kind of use of UML occurs often, and it is hard to recognize.

The UML-for-Java subset can be formalized by defining a UML profile for Java. Any UML profile in effect defines a completely new language which happens to be derived from the UML language. In Chapter 11 we elaborate on the role of UML profiles in MDA.

The Basic MDA Framework
In the previous sections, we have seen the major elements that participate in the MDA framework: models, PIMs, PSMs, languages, transformations, transformation definitions, and tools that perform transformations. All of these elements fit together in the basic MDA framework, as depicted in Figure 2-7. Although most of the terms have been defined in the previous sections, we summarize of the elements and their role below:

A model is a description of a system.

A PIM is a Platform Independent Model, which describes a system without any knowledge of the final implementation platform.

A PSM is a Platform Specific Model, which describes a system with full knowledge of the final implementation platform.

A model is written in a well-defined language.

A transformation definition describes how a model in a source language can be transformed into a model in a target language.

A transformation tool performs a transformation for a specific source model according to a transformation definition.

Figure 2-7. Overview of the basic MDA framework


From the developer's point of view, the PSM and PIM are the most important elements. A developer puts his focus on developing a PIM, describing the software system at a high level of abstraction. In the next stage, he chooses one or more tools that are able to perform the transformation on the PIM that has been developed according to a certain transformation definition. This results in a PSM, which can then be transformed into code.

Note that the figure only shows one PSM, but that from one PIM often multiple PSMs and potential bridges between them are generated. The figure only shows one transformation between a PIM and a PSM, but another transformation to code is also necessary.

In sections 8.3.1 and 9.4 we complete the basic MDA framework with additional elements at the metalevel. These metalevels are explained in Chapter 8 and Chapter 9. Until Chapter 7, the framework as described in Figure 2-7 is sufficient.