2 Models

2.1 What is modelling?

Modelling is about building representations of things in the ‘real world’ and allowing ideas to be investigated; it is central to all activities in the process for building or creating an artefact of some form or other. In effect, a model is a way of expressing a particular view of an identifiable system of some kind. Models are:

• a means of understanding the problems involved in building something;

• an aid to communication between those involved in the project, especially between the requirements analyst (a development role) and the user, as part of some deliverable;

• a component of the methods used in development activities such as the analysis of the requirements for an artefact and the design of the artefact.

A model is an abstraction, which allows people to concentrate on the essentials of a (complex) problem by keeping out non-essential details. Since there is a limit to how much a person can understand at any one time, we build models to help in activities such as the development of large software systems. For example, developers build different models throughout the development process in order to verify that the eventual software system will meet the requirements.

Models are, in one respect, idealisations in the sense that they are less complicated than reality; they are simplifications of reality. The benefit arises from the fact that only the properties of the world relevant to the job in hand are represented. For example, a road map is a model of a particular part of the earth's surface. We do not show things like vegetation or birds' nests as they are not relevant to the map's purpose. We use a road map to plan our journeys from one place to another and so the map should only contain those aspects of the real world that serve the purpose of planning journeys.

A model and the real world are alike in some ways, but different in others. For example, road maps are helpful because they represent the distance between, and relative positions of, a set of places and the routes between them. They use the relevant properties of the real thing with just a change in scale; one centimetre on the road map, for instance, may be equivalent to one kilometre on the ground. A map may be unhelpful if it shows only major roads.

Quite often, a property of the real world may be represented by a different kind of property in a model. In the case of the road map, different colours are normally used to represent different classes or types of road. Such a road map should have a key or legend so that those who read the map can understand what the different coloured lines are intended to represent. In effect, an analogy is being used to exploit the similarity between two different properties: one in the real world and one in the model.

Models of a problem situation are only an approximate representation of that situation. The real world situation will have a complexity that tends to reduce your chances of achieving an exact representation. So, you need to find some way of achieving an acceptable balance between accuracy and manageability. As a project unfolds, there will be a number of practical considerations that result in some compromise. It is for this reason that several different models are built, each one representing different aspects (views) of the real world.

If a model is so complex that its author (or other team members) cannot use it, then that model is of little or no value. However, simplification is only of value if all simplifying assumptions, and their consequences, are made explicit. At some point in a project, any of these assumptions may need to be justified.

Models are subject to change. At the very least they require some form of testing so that a model can maintain its correspondence with reality. As towns and cities expand and contract, a road map must be changed to reflect the new situation. In the worst case, a change in scope necessitates a whole new model. For example, if there was a need to reflect the current status of roads and the traffic on them, a simple road map is inadequate since we would want to show, amongst other things, the changes in traffic density over time.

Unfortunately, not all models of a particular type share the same notation, often because they originate from different sources. For example, different publishers will have different ways of constructing and presenting road maps.

When developing a product, a variety of models are likely to be constructed. It is unrealistic to expect to put everything into just one model. Too much detail in a model can only be a distraction. It would be hard to use such a model as an aid to communication.

Each model is used to illustrate a different point of view. For example, there are two different kinds of views that modellers often distinguish:

• static models, which describe a set of elements and any relationships that exist between them;

• dynamic models, which describe the behaviour of one or more elements over time.

There is a useful discussion in Michael Jackson's Software Requirements and Specifications (1995, p. 120) where he defines what he means by a model by distinguishing between a model and reality in relation to developing software. To Jackson, a model refers to the machine (what the software does when it executes on a computer), which embodies a simulation of the real thing; it is a description of a domain (that part of reality that you are interested in). A model and the domain are different so he draws attention to the difference between a description that is true in both the machine and the domain, a description that is true only of the domain, and another description that is true only of the machine. It is important to be clear whether you are talking about reality, the machine, or both.

Further reading: Michael Jackson, Software Requirements and Specification, Addison-Wesley, 1995, ISBN 0-201-87712-0