2.1 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.