Use Case Diagrams

In addition to introducing use cases as primary elements in software development, Jacobson (1994) also introduced a diagram for visualizing use cases. The use case diagram is also now part of the UML.

Many people find this kind of diagram useful. However, I must stress that you don't need to draw a diagram to use use cases. One of the most effective projects I know that used use cases involved keeping each one on an index card and sorting the cards into piles to show what needed building in each iteration.

Figure 3-2 shows some of the use cases for a financial trading system.

Figure 3-2. Use Case Diagram

Actors

An actor is a role that a user plays with respect to the system. There are four actors in Figure 3-2: Trading Manager, Trader , Salesperson, and Accounting System. (Yes, I know it would be better to use the word "role," but apparently, there was a mistranslation from the Swedish.)

There will probably be many traders in the given organization, but as far as the system is concerned , they all play the same role. A user may also play more than one role. For instance, one senior trader may play the Trading Manager role and also be a regular trader; a Trader may also be a Salesperson. When dealing with actors, it is important to think about roles rather than people or job titles.

Actors carry out use cases. A single actor may perform many use cases; conversely, a use case may have several actors performing it.

In practice, I find that actors are most useful when trying to come up with the use cases. Faced with a big system, it can often be difficult to come up with a list of use cases. It is easier in those situations to arrive at the list of actors first, and then try to work out the use cases for each actor.

Actors don't need to be human, even though actors are represented as stick figures within a use case diagram. An actor can also be an external system that needs some information from the current system. In Figure 3-2, we can see the need to update the accounts for the Accounting System.

There are several variations on what people show as actors. Some people show every external system or human actor on the use case diagram; others prefer to show the initiator of the use case. I prefer to show the actor that gets value from the use case, which some people refer to as the primary actor.

However, I don't take this too far. I'm happy to see the accounting system get value, without trying to figure out the human actor that gets value from the accounting system ”that would entail modeling the accounting system itself. That said, you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals.

When I'm working with actors and use cases, I don't worry too much about what the exact relationships are among them. Most of the time, what I'm really after is the use cases; the actors are just a way to get there. As long as I get all the use cases, I'm not worried about the details of the actors.

There are some situations in which it can be worth tracking the actors later.

The system may need configuring for various kinds of users. In this case, each kind of user is an actor, and the use cases show you what each actor needs to do.
Tracking who wants use cases can help you negotiate priorities among various actors.

Some use cases don't have clear links to specific actors. Consider a utility company. Clearly, one of its use cases is Send Out Bill. It's not so easy to identify an associated actor, however. No particular user role requests a bill. The bill is sent to the customer, but the customer wouldn't object if it didn't happen. The best guess at an actor here is the Billing Department, in that it gets value from the use case. But Billing is not usually involved in playing out the use case.

Be aware that some use cases will not pop out as a result of the process of thinking about the use cases for each actor. If that happens, don't worry too much. The important thing is understanding the use cases and the user goals they satisfy .

A good source for identifying use cases is external events. Think about all the events from the outside world to which you want to react. A given event may cause a system reaction that does not involve users, or it may cause a reaction primarily from the users. Identifying the events that you need to react to will help you identify the use cases.

Use Case Relationships

In addition to the links among actors and use cases, you can show several kinds of relationships between use cases.

The include relationship occurs when you have a chunk of behavior that is similar across more than one use case and you don't want to keep copying the description of that behavior. For instance, both Analyze Risk and Price Deal require you to value the deal. Describing deal valuation involves a fair chunk of writing, and I hate copy-and-paste . So I spun off a separate Value Deal use case for this situation and referred to it from the original use cases.

You use use case generalization when you have one use case that is similar to another use case but does a bit more. In effect, this gives us another way of capturing alternative scenarios.

In our example, the basic use case is Capture Deal. This is the case in which all goes smoothly. Things can upset the smooth capture of a deal, however. One is when a limit is exceeded ”for instance, the maximum amount the trading organization has established for a particular customer. Here we don't perform the usual behavior associated with the given use case; we carry out an alternative.

We could put this variation within the Capture Deal use case as an alternative, as with the Buy a Product use case I described earlier. However, we may feel that this alternative is sufficiently different to deserve a separate use case. We put the alternative path in a specialized use case that refers to the base use case. The specialized use case can override any part of the base use case, although it should still be about satisfying the same essential user goal.

A third relationship, which I haven't shown on Figure 3-2, is called extend . Essentially, this is similar to generalization but with more rules to it.

With this construct, the extending use case may add behavior to the base use case, but this time the base use case must declare certain "extension points," and the extending use case may add additional behavior only at those extension points. (See Figure 3-3.)

Figure 3-3. Extend Relationship

A use case may have many extension points, and an extending use case may extend one or more of these extension points. You indicate which ones on the line between the use cases on the diagram.

Both generalization and extend allow you to split up a use case. During elaboration, I often split any use case that's getting too complicated. I split during the construction stage of the project if I find that I can't build the whole use case in one iteration. When I split, I like to do the normal case first and the variations later.

Apply the following rules.

Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition.
Use generalization when you are describing a variation on normal behavior and you wish to describe it casually.
Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring your extension points in your base use case.