Objectives
The objective of this chapter is to introduce a number of system models that may be developed during the requirements engineering process.
When you have read the chapter, you will:
• understand why it is important to establish the boundaries of a system and model its context;
• understand the concepts of behavioUiral modelling, data modelling and object modelling;
• have been introduced to some of the notations defined in the Unified Modeling Language (UML) and how these notations may be used to develop system models.
Contents
8.1 Context models 8.2 Behavioural models 8.3 Data models 8.4 Object models 8.5 Structured methods
System models
User requirements should be written in natural language because they have tobe understood by people who are not technical experts. However, more detailed sys-tem requirements may be expressed in a more technical way. One widely used tech-nique 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 descrip-tions 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 dif-ferent 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 sys-tem model is an abstraction of the syssys-tem being studied rather than an alternative representation of that system. Ideally, arepresentationof a system should maintain all the information about the entity being represented. An abstractiondeliberately 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 abstrac-tion. A data-flow model (for example) concentrates on the flow of data and the func-tional transformations on that data. Itleaves 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 anal-ysis process are:
1. A data- flow modelData-flow models show how data is processed at different stages in the system.
2. A composition modelA composition oraggregationmodel shows how entities in the system are composed of other entities.
8.1 • Context models 171
3. An architectural model Architectural models show the principal sub-systems that make up a system.
4. A classification modelObject class/inheritance diagrams show how entities have common characteristics.
5. A stimulus-response modelAstimulus-responsc~model, orstate transition dia-gram,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 stan-dard 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.
8.1 Context models
At an early stage in the requirements elicitation and analysis process you should decide011the boundaries of the system. This involves working with system stake-holders to distinguish what is the system and what is the system's environment.
You should make these decisions early in the proce:ss to limit the system costs and the time needed for analysis.
In some cases, the boundary between a system and its environment is relatively clear. For example, where an automated system is replacing an existing manual or computerised system, the environment of the new system is usually the same as the existing system's environment.
In
other cases, there is more flexibility, and you decide what constitutes the boundary between the system and its environment during the requirements engineering process.For example, say you are developing the specification for the library system LIB-SYS. Recall that this system is intended to deliver electronic versions of copyrighted material to users computers. The users may then print personal copies of the mate-rial. In developing the specification for this system, you have to decide whether other library database systems such as library catalogues are within the system bound-ary.Ifthey are, then you may have to allow access to the system through the cat-alogue user interface; if they are not, then users may be inconvenienced by having to move from one system to another.
The definition of a system boundary is not a value-free judgement. Social and organisational concerns may mean that the position of a system boundary may be determined by non-technical factors. For example, a system boundary may be
posi-System models