Active actors initiate interaction with the system. This can be shown by placing an arrow on the association from the actor pointing toward the use case. In the ATM example, the customer is an active actor.

Interaction with passive actors is initiated by the system. This can be shown by placing an arrow on the association from the use case pointing toward the actor. In the ATM example, the central computer is a passive actor.

This is a good example where the arrow helps, since it allows us to distinguish an event driven system (the ATM initiates interaction with the central computer) from a polling system (the central computer interrogates the ATM from time to time).

Where an actor may be either active or passive, depending on circumstances, the arrow may be omitted. In the ATM example the bank engineer fits into this category. Normally he is active, turning up on a regular cycle to service the machine. However if the ATM detects a fault, it may summon the engineer to fix it.

The use of arrows on associations is referred to as the navigation of the association. We shall see this used elsewhere in UML later on. The choice, by the OMG, of zero vice two arrowheads to show a bidirectional association is unfortunate. Under this convention you cannot distinguish between an association whose navigation has yet to be determined and one that is bidirectional.

Figure 4.2, “ Use case diagram for an ATM system showing navigation. ” shows the ATM use case diagram with navigation displayed.

Figure 4.2.  Use case diagram for an ATM system showing navigation.

It can be useful to show the multiplicity of associations between actors and use cases. By this we mean how many instances of an actor interact with how many instances of the use case.

By default we assume one instance of an actor interacts with one instance of a use case. In other cases we can label the multiplicity of one end of the association, either with a number to indicate how many instances are involved, or with a range separated by two periods (..). An asterisk ( *) is used to indicate an arbitrary number.

In the ATM example, there is only one central computer, but it may be auditing any number of ATM uses. So we place the label 0..* at the use case end. There is no need for a label at the other end, since the default is one.

A local bank will have up to three officials authorized to unload and load ATM machines. So at the actor end of the relationship with the use case Maintain ATM, we place the label 1..3. They may be dealing with any number of ATM machines, so at the other end we place the label 0..*.

There may be any number of customers and there may be any number of ATM systems they could use. So at each end of the association we place the label 0..*.

Figure 4.3, “ Use case diagram for an ATM system showing multiplicity. ” shows the ATM use case diagram with multiplicity displayed.

Figure 4.3.  Use case diagram for an ATM system showing multiplicity.

Multiplicity can clutter a diagram, and is often not shown, except where it is critical to understanding. In the ATM example we would only choose to show 1..3 against the local bank official, since all others are obvious from the context.

In our ATM example so far we have just three use cases to describe all the behavior of the system. While use cases should always describe a significant chunk of system behavior, if they are too general they can be difficult to describe.

We could for example define the behavior of the use case “Use ATM” in terms of the behavior of three simpler use cases, “Deposit Cash”, “Withdraw Cash” and “Query Account”. The main use case could be specified by including the behavior of the subsidiary use cases where needed.

Similarly the “Maintain ATM” use case could be defined in terms of two use cases “Maintain Equipment” and “Reload ATM”. In this case the two actors involved in the main use case are really only involved in one or other of the two subsidiary use cases and this can be shown on the diagram.

The decomposition of a use case into simpler sub-use cases is shown in UML by using an include relationship, a dotted arrow from the main use case to the subsidiary, with the label «include».

Figure 4.4.  Use case diagram for an ATM system showing include relationships.

Include relationships are fine for breaking down the use case behaviors in to hierarchies. However we may also want to show a use case that is an extension to an existing use case to cater for a particular circumstance.

In the ATM example we have a use case covering routine maintenance of the ATM, “Maintain Equipment”. We also want to cover the special case of an unscheduled repair caused by the ATM detecting an internal fault.

This is shown in UML by the extend relationship. In the main use case, we specify a name for a location in the description, where an extension to the behavior could be attached. The name and location are shown in a separate compartment within the use case oval. The representation extend relationship is the same as the include relationship, but with the label «extend». Alongside the extend relationship, we specify the condition under which that behavior will be attached.

Figure 4.5, “ Use case diagram for an ATM system showing an extend relationship. ” shows the ATM use case diagram with an extend relationship to a use case for unscheduled repairs. The diagram is now getting rather complex, and so we have split it into two, one for the maintenance side of things, the other for customer usage and audit.

The “Maintain Equipment” use case defines a name “Unsched”, at the start of its description. The extending use case “Unscheduled Repair” is attached there when the ATM detects an internal error.

Figure 4.5.  Use case diagram for an ATM system showing an extend relationship.

Use cases may be linked together in one other way. One use case may be a generalization of a subsidiary use case (or alternatively the subsidiary is a specialization of the main use case). This is very like the extends relationship, but without the constraint of specific extension points at which the main use case may be extended, and with no condition on when the subsidiary use case may be used.

Generalization is shown on a use case diagram by an arrow with solid line and solid white head from the subsidiary to the main use case. This may be useful when a subsidiary use case specializes the behavior of the main use case at a large number of positions and under a wide range of circumstances. However the lack of any restriction makes generalization very hard to specify precisely. In general use an extend relationship instead.

All flows in a use case specification are linear—that is there is no conditional branching. Any choices in flows are handled by specifying another alternate flow that takes over at the choice point. It is important to remember we are specifying behavior here, not programming it.

A flow is specified as a series of numbered steps. Each step must involve some interaction with an actor, or at least generate a change that is observable externally by an actor. Requirements capture should not be specifying hidden internal behavior of a system.

For example we might give the following sequence of steps for the basic flow of the use case "Withdraw Cash" in our ATM example.

Remember this is a sub-use case included in the main “Use ATM” use case, which will presumably handle checking of cards and PINs before invoking this included use case.

	Note
	The first step is not a condition. We take as our basic flow the case where the customer does want a receipt. The case where the customer does not want a receipt will be an alternative flow.

This captures the alternative scenarios, as linear flows, by reference to the basic flow. Initially we just build a list of the alternate flows.

Subsequently we flesh out each alternate flow, by reference to the basic flow. For example the first alternate flow might look like.

The convention is to number the various alternate flows as A.1, A.2, A.3, etc. The steps within an alternate flow are then numbered from this. So the steps of the first alternate flow would be A.1.1, A.1.2, A.1.3, etc.

Iterative development will prioritize the use cases, and the first iterations will address the most important.

Early iterations will capture the basic flows of the most important use cases with only essential detail and list the headings of the main alternate flows.

Later iterations will address the remaining use cases, flesh out the steps on individual alternate flows and possibly provide more detail on individual steps.