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