2.1 MODELS AND MODELLING¹

From a simplistic point of view (see [17]), a model is “a statement about a given subject under study (SUS), expressed in a given language”. This definition is similar to that given by [41] (“a set of statements about some system under study”) but it incorporates an explicit reference to the language in which the model is expressed. According to this definition, the sentence “today it is raining” is a model of our perceived real world, since it is a statement about a given subject (the perceived real world), expressed in a given language (English). Since today, as I look out of the window, it is raining, the statement expressed by the sentence can be evaluated as being true. Thus, the prospective model is valid. Of course, this is a trivial model of minimal utility. More complex models allow the representation of more complex real-world phenomena, thus permitting deeper insights. Indeed, we can say that the major reason for models is to be able to reason about the complexity of the SUS without having to deal with it directly (see also [26]). As a result, a suitable model would have to exhibit the appropriate structure for it to be useful. For this reason, we prefer to say that, for a statement about an SUS (expressed in a given language) to be a model, it needs to be homomorphic with the SUS that it represents. This means that the structure of the model and the structure of the SUS must coincide to some degree, and the operations that are possible on the SUS must also be possible on the model (Figure 2.1).

Figure 2.1: A model is homomorphic with its SUS: operations on the SUS are also possible on the model (after [17])

Source: Gonzalez-Perez and Henderson-Sellers, 2007, reproduced from Journal of Systems and Software, with permission from Elsevier.

This use of the word “homomorphic”, i.e. meaning “related via a structure-preserving mapping”, is not purely algebraic, and has been utilized in this sense before in software engineering [39] and other disciplines, such as linguistics [20]. For example, consider a car and the parts of which it is made. This is the subject under study (the SUS). By looking at it, we can (albeit with effort) enumerate all its parts and sub-parts recursively, in a tree-wise fashion. A model that represents a car and its parts should exhibit the same structure and allow for the same operation, i.e. enumerating its parts and sub-parts recursively (Figure 2.1). If a model were not homomorphic with its SUS, i.e. the structure of the SUS were not copied into the model, then the model could not be used as a surrogate for the SUS, thus violating a defining property of models.

We have established that models represent SUSs. This statement, however, raises two additional questions. First of all, what kind of entities are the model and the SUS? Secondly, what is the nature of this “representation”? In order to answer the first question, we need to take into account that the usual depiction of modelling activities in software engineering works suffers from a very peculiar problem: they show the model as being a representation of a fragment of reality and external to it. Although this may seem a simple matter of notation, it reveals the underlying assumption that a model is different to its SUS in a very particular way, namely, it does not belong to the same realm. However, even the most simplistic thought experiment would show that, if an SUS is part of reality, then a model of it is also part of reality, as vividly explained by [30, pp. 230–1]. Therefore, software engineering models are not external to reality but components of it, and, similarly, we (as modellers) are not outside reality, looking at it, but inside it [29, p. 261]. Precisely because of this, we can create models that represent other models, thus creating a model chain, as will be discussed further below.

Answering our first question (what kind of entities are the model and the SUS?), we can conclude that anything that can be observed can be an SUS, and that a model, once created, becomes part of reality and, therefore, is a potential SUS for further models. With regard to our second question (what is the nature of the connection between a model and its SUS?), two different scenarios are often found, as described by [41]. Sometimes a model is created to describe an existing SUS and enable reasoning about the SUS in its absence. For example, a training flight simulator is a model of a real aeroplane that is better suited for training pilots than the SUS it models. On other occasions, a model is created to specify an SUS that does not exist but can be somehow envisioned. For example, blueprints of a building are created to define what the building will look like and how it will be built. We will call the former backward-looking models since they look backward to the SUS they model and we will call the latter forward-looking models since they look forward into the future (Figure 2.2).

Figure 2.2: A backward-looking model representing an existing SUS (top) and a forward-looking model representing an SUS that does not yet exist (bottom); time flows from left to right (after [17])

Source: Gonzalez-Perez and Henderson-Sellers, 2007, reproduced from Journal of Systems and Software, with permission from Elsevier

For both types of model (backward-looking and forward-looking), homomorphism dictates that the structure of the model must match the structure of the SUS at some relevant level of detail; in other words, for each relevant entity in the SUS there must be an entity in the model that plays the same structural role. At the same time, every entity in the model must have at least one corresponding entity in the SUS; otherwise, the model entity would not represent anything. What is the nature of the connection between a relevant entity inside the SUS and its “surrogate”, homomorphic entity inside the model? This might be too general a question to have a single answer, but there is something that we can say: whatever the nature of the connection, any model must have access to the information necessary in order to find out which SUS entity is represented by a given model entity (please note that all model entities must be connected to SUS entities, but not all SUS entities need to be connected to a model entity). Without this information, interpretation of the model – as described by [41] – is not possible and, therefore, the model is meaningless. We have used the term “interpretive mappings” [17] to refer to the collection of information that allows the finding out of these connections when necessary (Figure 2.3).

Figure 2.3: Interpretive mappings between model entities and SUS entities, depicted by dotted-line arrows² (after [17])

Source: Gonzalez-Perez and Henderson-Sellers, 2007, reproduced from Journal of Systems and Software, with permission from Elsevier

Interpretive mappings are not always one-to-one relationships as shown in Figure 2.3. In fact, the “cardinality” of the mappings depends on the characteristics of the representation process employed to create the model. For example, an architectural scale model of a building usually contains a simplified, small-scale version of each room of the real building. In this case, each small room in the model is mapped to a real room in the real building; the cardinality is one to one. If the same model contains a figurine to exemplify how people interact with the building in the real world, this figurine does not correspond to any particular person in the SUS but rather to the prototypical idea of a person in the SUS interacting with the building. A number of people in the SUS can play the role that the figurine plays in the model and, therefore, the interpretive mapping between the figurine and the people it represents is one-to-many.

There is a second way in which an interpretive mapping can be one-to-many. A label attached to the architectural scale model may read “people walk through this way”. Rather than incorporating a prototype of SUS entities, this model entity declares which kind of entities in the SUS are suitable for interpretive mapping. Summarizing, we can identify three kinds of interpretive mapping:

• Isotypical mappings map one model entity to one SUS entity. The model entity straightforwardly represents the SUS entity.
• Prototypical mappings map one model entity to a set of SUS entities given by example, i.e. the model entity exemplifies the kind of SUS entities that can be mapped to it.
• Metatypical mappings map one model entity to a set of SUS entities given declaratively, i.e. the model entity is a description of the properties that SUS entities must comply with in order to be mapped to it.

Figure 2.4 shows examples of the three kinds. Notice that, in principle, there is nothing that prevents the three kinds coexisting within the same model.

Figure 2.4: Isotypical, prototypical and metatypical interpretive mappings: a circle shows an isotypical mapping; the shaded square on the model is an example (prototype) of any square in the SUS; “pentagon” in the model is metatypically mapped to all possible pentagons in the SUS (after [17])

Source: Gonzalez-Perez and Henderson-Sellers, 2007, reproduced from Journal of Systems and Software, with permission from Elsevier

We can find these three kinds of mappings in software development methodologies. Consider a Unified Modeling Language (UML) class diagram, for example. This diagram depicts a model and, as such, can be thought of as a model of that model. Each box in the class diagram that a UML-aware expert identifies as “a class” is really a representation of a class in the class model. The box on the paper is just a visual artefact that represents a conceptual (i.e. cognitive or mental) construct (the class). We must emphasize here that boxes on the paper are not classes but represent classes. Therefore, each box on the diagram is isotypically mapped to the corresponding class in the model. Because this is an isotypical mapping, the cardinality is one on the SUS side, i.e. there is exactly one SUS entity for any given model entity, and we often equate the box on the paper to the class in the model, thus confounding the model and its representation.³ This is convenient but does not mean that the box and the class are the same thing. Now, each class in the model is a declaration of the kinds of objects that can appear in the system being modelled; therefore, each class in the model is metatypically mapped to a number of potential objects in the running system. At the same time, we could argue that each class in the model is isotypically mapped to a class in the source code. Finally, let's consider what UML 1.5 [33] calls “object diagrams”, i.e. structural diagrams in which objects can appear. A box drawn on a piece of paper that is identified by an expert as “an object” is an ambiguous thing. Some people would interpret it as a representation of a particular object in the running system (an isotypical mapping) while others would interpret it as an example of an object that may occur in the running system (a prototypical mapping). Since the cardinalities of these two mappings, as well as their semantics, are different, we claim that UML 1.5 is ambiguous in relation to object diagrams. UML 2 [36] removes the concept of an Object as a model entity and introduces the concept of an InstanceSpecification. Indeed, the term “object” has driven some people to believe that the “objects” in UML 1.5 object diagrams are real objects (and associated confusion related to objects being in the same layer as their classes), when they are just a representation of objects. In this sense, the term “instance specification” is much better suited, since it clearly reflects that the model element is just a specification (i.e. an entity in a forward-looking model) of an instance in the SUS. However, the same ambiguity that we found in UML 1.5 remains, since the definition, description and semantics of an InstanceSpecification in UML 2 (see [36, pp. 62–4]) allow for both isotypical mappings (an instance specification may specify the existence of an entity in a modelled system) and prototypical mappings (an instance specification may provide an illustration or example of a possible entity in a modelled system). Whether this open definition enhances expressiveness or hinders interpretation is something that only time will tell.