System models

User requirements should be written in natural language because they have to be
understood by people who are not technical experts. However, more detailed system
requirements may be expressed in a more technical way. One widely used technique
is to document the system specification as a set of system models. These models
are graphical representations that describe business processes, the problem to be solved
and the system that is to be developed. Because of the graphical representations
used, models are often more understandable than detailed natural language descriptions
of the system requirements. They are also an important bridge between the
analysis and design processes.
You can use models in the analysis process to develop an understanding of the
existing system that is to be replaced or improved or to specify the new system that
is required. You may develop different models to represent the system from different
perspectives. For example:
1. An external perspective, where the context or environment of the system is
modelled
2. A behavioural perspective, where the behaviour of the system is modelled
3. A structural perspective, where the architecture of the system or the structure
of the data processed by the system is modelled
I cover these three perspectives in this chapter and also discuss object modelling,
which combines, to some extent, behavioural and structural modelling.
The most important aspect of a system model is that it leaves out detail. A system
model is an abstraction of the system being studied rather than an alternative
representation of that system. Ideally, a representation of a system should maintain
all the information about the entity being represented. An abstraction deliberately
simplifies and picks out the most salient characteristics. For example, in the very
unlikely event of this book being serialised in a newspaper, the presentation there
would be an abstraction of the book's key points. If it were translated from English
into Italian, this would be an alternative representation. The translator's intention
would be to maintain all the information as it is presented in English.
Different types of system models are based on different approaches to abstraction.
A data-flow model (for example) concentrates on the flow of data and the functional
transformations on that data. It leaves out details of the data structures. By
contrast, a model of data entities and their relationships documents the system data
structures rather than its functionality.
Examples of the types of system models that you might create during the analysis
process are:
1. A data- flow model Data-flow models show how data is processed at different
stages in the system.
2. A composition model A composition or aggregation model shows how entities
in the system are composed of other entities.
3. An architectural model Architectural models show the principal sub-systems
that make up a system.
4. A classification model Object class/inheritance diagrams show how entities have
common characteristics.
5. A stimulus-response model A stimulus-responsc~ model, or state transition diagram,
shows how the system reacts to internal and external events.
All th,ese types of models are covered in this chapter. Wherever possible, I use
notations from the Unified Modeling Language (UML), which has become a standard
modelling language for object-oriented modelling (Booch, et al., 1999;
Rumbaugh, et al., 1999a). Where UML does not include appropriate notations, I use
simple intuitive notations for model description. A new version of UML (UML 2.0)
is under development but was not available when I wrote this chapter. However, I
understarld that the UML notation that I have used here is likely to be compatible
with UML 2.0.