Page 141 -

124 Chapter 5 System modeling

dangerous and not dangerous to society. Patients who are dangerous to society must
be detained in a secure facility. However, patients who are suicidal and so are a
danger to themselves may be detained in an appropriate ward in a hospital.

5.2 Interaction models

All systems involve interaction of some kind. This can be user interaction, which
involves user inputs and outputs, interaction between the system being developed
and other systems or interaction between the components of the system. Modeling
user interaction is important as it helps to identify user requirements. Modeling sys-
tem to system interaction highlights the communication problems that may arise.
Modeling component interaction helps us understand if a proposed system structure
is likely to deliver the required system performance and dependability.
In this section, I cover two related approaches to interaction modeling:

1. Use case modeling, which is mostly used to model interactions between a
system and external actors (users or other systems).
2. Sequence diagrams, which are used to model interactions between system
components, although external agents may also be included.

Use case models and sequence diagrams present interaction at different levels of
detail and so may be used together. The details of the interactions involved in a high-
level use case may be documented in a sequence diagram. The UML also includes
communication diagrams that can be used to model interactions. I don’t discuss
these here as they are an alternative representation of sequence charts. In fact, some
tools can generate a communication diagram from a sequence diagram.

5.2.1 Use case modeling

Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s
and was incorporated into the first release of the UML (Rumbaugh et al., 1999). As
I have discussed in Chapter 4, use case modeling is widely used to support require-
ments elicitation. A use case can be taken as a simple scenario that describes what a
user expects from a system.
Each use case represents a discrete task that involves external interaction with a
system. In its simplest form, a use case is shown as an ellipse with the actors
involved in the use case represented as stick figures. Figure 5.3 shows a use case
from the MHC-PMS that represents the task of uploading data from the MHC-PMS
to a more general patient record system. This more general system maintains sum-
mary data about a patient rather than the data about each consultation, which is
recorded in the MHC-PMS.