Skip to content
Skip to main content

About this free course

Download this course

Share this free course

Approaches to software development
Approaches to software development

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

3.1 Importance of modelling

Modelling is a way of thinking about things and ideas in the ‘real world’. A model is an abstract representation of a situation in reality, or of a system from a particular point of view. In effect a model is a way of expressing a particular view of an identifiable system of some kind.

In terms of the development of software systems, models are:

  • a way of understanding the problems involved
  • an aid to communication among those involved, especially between the developer and the user, as part of some deliverable
  • a component of the processes used in development activities such as analysis and design.

A good model is an abstraction, which allows those involved to concentrate on the essentials of a (complex) problem by keeping out non-essential details. Previously, you saw that there is a limit to how much a person can understand at any one time. So we build models to help us in activities such as the development of software systems. For example, developers build different models at different stages during the development process in order to confirm that the eventual software system will meet the users’ requirements.

Models contain a representation of the significant states, objects and events in a real-world situation or within a software system. In one respect models are an idealisation, because they are less complicated than reality, and so they are easier to use for software development. The benefit arises from the fact that only the relevant properties of the outside world 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 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 contain only those aspects of the real world that serve the purpose of planning journeys.

When we model, we are trying to show or reveal what something is like. Models can do more than this because they can help us explain the past and the present (the problem), and they can help us predict and control the future (the solution – a software system). However remember that the model and the real world are alike in some ways, but different in others. For example, road maps are helpful because they represent distances between (and relative positions of) places, as well as 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. They may however be unhelpful if they show only major roads.

We can also use one property in a model to represent another in the real world. In the case of the road map, we can use different colours 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. On a road map, a blue line might represent a motorway, and a yellow line a narrow track.

Models of a problem situation are only an approximate representation of that situation. The real-world situation is normally complex – so much so that an exact representation is likely to be impossible to achieve. The problem therefore confronting a developer is to find some way of achieving an acceptable balance between completeness and manageability. In a software development project, there will be a number of practical considerations that result in some compromise in completeness.

If the constructed model is so complex that the developer (or other team members) cannot use it, it is of little or no value. So the model must simplify the reality a good deal. However the developer should make explicit all simplifying assumptions for a given model, as well as their consequences. At some point in a development project, any of these assumptions may need to be justified.

Models are subject to change. At the very least, they require some form of periodic 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 were a need to reflect the current status of roads and the traffic density on them, a simple road map would be inadequate.