Page 138 -

5.1 Context models 121

The Unified Modeling Language

The Unified Modeling Language is a set of 13 different diagram types that may be used to model software
systems. It emerged from work in the 1990s on object-oriented modeling where similar object-oriented
notations were integrated to create the UML. A major revision (UML 2) was finalized in 2004. The UML is
universally accepted as the standard approach for developing models of software systems. Variants have been
proposed for more general system modeling.
http://www.SoftwareEngineering-9.com/Web/UML/

In the third case, where models are used as part of a model-based development
process, the system models have to be both complete and correct. The reason for this
is that they are used as a basis for generating the source code of the system.
Therefore, you have to be very careful not to confuse similar symbols, such as stick
and block arrowheads, that have different meanings.

5.1 Context models

At an early stage in the specification of a system, you should decide on the system
boundaries. This involves working with system stakeholders to decide what func-
tionality should be included in the system and what is provided by the system’s envi-
ronment. You may decide that automated support for some business processes
should be implemented but others should be manual processes or supported by dif-
ferent systems. You should look at possible overlaps in functionality with existing
systems and decide where new functionality should be implemented. These deci-
sions should be made early in the process to limit the system costs and the time
needed for understanding the system requirements and design.
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
computerized 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 patient information
system for mental healthcare. This system is intended to manage information about
patients attending mental health clinics and the treatments that have been prescribed.
In developing the specification for this system, you have to decide whether the sys-
tem should focus exclusively on collecting information about consultations (using
other systems to collect personal information about patients) or whether it should
also collect personal patient information. The advantage of relying on other systems
for patient information is that you avoid duplicating data. The major disadvantage,
however, is that using other systems may make it slower to access information. If
these systems are unavailable, then the MHC-PMS cannot be used.