7 Modelling users' routines
7.1 Activity diagrams
Each use case in a requirements model represents a unit of functionality or, more simply, a task initiated by an actor. Within each task there may be a number of identifiable actions that the software system should perform in order to complete that task successfully. In addition, it is necessary to identify what an actor does in unusual circumstances. To model these aspects of a system you can use activity diagrams.
In the UML, an activity diagram is used to model the coordination and sequencing of actions in order to achieve a given purpose; it shows which actor is responsible for which activity. Figure 11 shows an example of an activity diagram, which is used to show the separate responsibilities of the Receptionist and Guest actors for the main success scenario for the use case check in guest.
The aim of an activity diagram is to record the flow of control from one activity to another within the workflow of each actor and to show the interactions between actors. Time is an important concept in an activity diagram as the arrows indicate the order in which activities are carried out (unlike data flow diagrams). An activity diagram is divided horizontally by vertical lines, with each vertical strip, known as a swimlane, headed by the name of the actor. A swimlane contains the sequence of activities performed by an actor. Each activity is represented by a box with rounded corners containing a brief description of the activity. The transition from one activity to the next is identified by an open-headed arrow, which signifies that one activity has been completed and it is time to move on to the next one.
An activity for an actor begins at a solid black circle (there is one at the top of the Guest's swimlane) and finishes with a double circle with a black centre (there are two of these in the Guests swimlane). In Figure 11, the Receptionist is not shown with a start or a finish circle as theirs is a repetitive activity.
A diamond shape represents a decision and enables you to indicate that a flow can proceed in one of two directions depending on some condition. The condition under which a particular path is taken is written inside square brackets alongside the path. Such a condition is known as a guard – the path is taken only if the guard is true. In Figure 11, for example, a transition is made from the Receptionist requesting for a reservation number to the Guest stating the number only if the Guest has a reservation number. This diagram does not show the transition if the Guest does not have (or cannot remember) a reservation number (most likely we would need to draw a separate diagram to show what happens in this case).
The thick horizontal lines (there are two in the Receptionist's swimlane) are known as synchronisation bars. These indicate that the activities of the actors must be synchronised. That is, in the top-most bar, the Receptionist and the Guest must both be ready to continue their activities at the same time. For example, if the Receptionist is already dealing with a Guest, a new Guest must wait until the Receptionist reaches this synchronisation point in his check-in activity having completed his interaction with the first Guest. Likewise, if the Receptionist reaches the upper synchronisation bar and there is no Guest wishing to check in, the Receptionist pauses this activity and is able to do some other activity (such as check out a Guest or make a reservation). There are two flows entering this bar but only one flow out; it is technically known as a join synchronisation bar.
The lower synchronisation bar indicates that the two actors need no longer be synchronised and can go on their separate ways. There is one flow entering this bar and two flows coming out; it is technically known as a fork synchronisation bar.
Hence, by reading down a swimlane, you can see the order of activities that an actor performs. The horizontal lines (transitions) from one swimlane to another represents an exchange of data from one actor to another.
A final point about the UML activity diagram notation (not illustrated in Figure 11) is that it is permitted to show two (or more) transitions going into an activity, but there must be only one transition coming out of an activity.
Finally, we have annotated the Guest's final transition with a guard to show the postcondition for this part of the check in guest use case.