Page 137 -

120 Chapter 5 System modeling

These perspectives have much in common with Krutchen’s 4 + 1 view of system
architecture (Kruchten, 1995), where he suggests that you should document a sys-
tem’s architecture and organization from different perspectives. I discuss this 4 + 1
approach in Chapter 6.
In this chapter, I use diagrams defined in UML (Booch et al., 2005; Rumbaugh
et al., 2004), which has become a standard modeling language for object-oriented
modeling. The UML has many diagram types and so supports the creation of many
different types of system model. However, a survey in 2007 (Erickson and Siau,
2007) showed that most users of the UML thought that five diagram types could
represent the essentials of a system:

1. Activity diagrams, which show the activities involved in a process or in data
processing.
2. Use case diagrams, which show the interactions between a system and its envi-
ronment.
3. Sequence diagrams, which show interactions between actors and the system and
between system components.
4. Class diagrams, which show the object classes in the system and the associa-
tions between these classes.
5. State diagrams, which show how the system reacts to internal and external events.

As I do not have space to discuss all of the UML diagram types here, I focus on
how these five key types of diagram are used in system modeling.
When developing system models, you can often be flexible in the way that the
graphical notation is used. You do not always need to stick rigidly to the details of a
notation. The detail and rigor of a model depends on how you intend to use it. There
are three ways in which graphical models are commonly used:

1. As a means of facilitating discussion about an existing or proposed system.
2. As a way of documenting an existing system.
3. As a detailed system description that can be used to generate a system
implementation.

In the first case, the purpose of the model is to stimulate the discussion
amongst the software engineers involved in developing the system. The models
may be incomplete (so long as they cover the key points of the discussion) and
they may use the modeling notation informally. This is how models are normally
used in so-called ‘agile modeling’ (Ambler and Jeffries, 2002). When models are
used as documentation, they do not have to be complete as you may only wish to
develop models for some parts of a system. However, these models have to be
correct—they should use the notation correctly and be an accurate description of
the system.