UML 2 For Dummies

Showing Your System’s Use Cases

Finding and categorizing the stakeholders and identifying the actors will certainly help you determine the sources of requirements for your system and help you get critical feedback early. However, to get full value from UML use-case diagrams you have to show how the actors use the system. Each distinct use of the system—or purpose for which the system can be put to use—is called a use case. Each use case must be initiated by some actor, whether human user, device, clock, or other system.

Defining use cases based on actors and goals

Put yourself in the place of each actor in turn. Consider the goals that each human actor has when using the system. Determine the job the actor performs while using the system you’re developing. You need to recognize and understand how your system helps the actor meet job goals or personal goals. If using the system returns some observable or measurable value to the actor that moves the actor toward the goal, then that use is a good candidate for a use case. For example, making a reservation returns a reservation to the actor; checking in returns a room assignment and a key; checking out returns an end-of-room assignment and a bill. For the non-human actors, consider the goals the actor’s stakeholders have when it initiated interaction with your system.

All actor-and-system interactions are part of some use case. For each set of interactions with the system, examine the goals or purposes of the initiating actor, sometimes called the primary actor. If more than one actor participates in the use case, then the actor who starts the behavior (or contacts the system) is the primary actor. The system contacts other actors as it attempts to meet the primary actor’s goals. You can call these other actors the secondary actors. Often an actor may be primary for one use case and secondary for another.

Illustrating use cases

UML has a simple way of indicating the relationships between actors and their use cases. You draw a line from each actor to each use case he or she (or it) participates in. (An example of a use-case diagram appears in Figure 8-4.)

Figure 8-4: This use-case diagram illustrates use cases and their associated actors.

Show the use case by drawing an oval, which is UML notation for a use case (and other such behaviors). The name of the use case is supposed to be placed inside the oval, but this is rarely seen. Some tool vendors find it difficult to redraw diagrams when the text is inside the oval, so they put the use-case name on the outside, near the bottom of the oval. UML accepts either location for the name. Our Figure 8-4 shows both ways of drawing use cases.

 Tip   If there are multiple actors participating in a use case, it’s sometimes convenient to show who is in charge and who is just along for the ride. We recommend that you indicate the actor who initiates a use case—the primary actor—by drawing an arrow from the actor to the use case. Other actors, who might just participate in the use case, you show as the targets of arrows that start at the use case. We demonstrate this convention in Figure 8-4.

 Tip   When you draw the use case yourself by hand, you’ll find it easy to put the name inside the use-case oval if you remember the simple rule for using your hand as a UML tool: Draw the words first, and then draw the container. If you draw the oval first, the name will rarely fit inside.

Showing multiplicity with actors and use cases

In many of your systems, the concurrency of each use case is useful to capture. The concurrency of a use case is the number of instances of the use case that the actor can communicate with at the same time. You can use the multiplicity value (see Chapter 4 for the complete details of how multiplicity is indicated) to show concurrency as well. If an actor can participate in more than one running of a particular use case—at the same time—then the multiplicity of the use case should be 0..*. In the normal situation (one-at-a-time participation), you can use 0..1 as the multiplicity, or just don’t bother to indicate it. In Figure 8-5, we show that the Credit Card Authorization System can work with many instances of the Make Room Reservation running at the same time, but a Potential Guest can only try one Make Room Reservation with our system at a time.

Figure 8-5: A use-case diagram with multiplicity.

 Tip   Don’t get too confused over arrowheads or multiplicity. The lines from the actors to the use cases can be adorned in many ways, all of which are optional. All you need is the basic core line to indicate that the actor participates in the use case. If a use case has only one actor, it’s obviously the initiating actor. If there is more than one actor, you can distinguish this primary actor by showing that it initiates the use case (do so by making the arrowhead point to the use case). You can also try the convention that places the primary actors on the left of the diagram and secondary (non-initiating) actors on the right. Of course, you can use both conventions on the same diagram.

Defining a good use case

A use case is an actor-initiated, complete, system behavior that brings value to the actor. Sometimes it may be difficult to identify the set of use cases that our system offers. The following list provides several helpful hints for defining a good use case:

• Choose a good name: A use case is a behavior, so you should name it with a verb phrase. To make it more precise, you should add a noun to the name to indicate the class of objects that the action effects. To help you choose the verb-noun phrase for the use case name, going back to the class diagrams that helped you find the actors (see Figure 8-1) may help identify the objects and the associations created by the use cases. Look at a possible good name for your use case, by examining the name of the relationships of the actor to the system’s objects.

• Illustrate a complete behavior: A use case must be a complete behavior that starts with the initiating event from the primary actor and ends with the actor normally reaching his/her goal. If a proposed use case is only a step along the way to the goal, don’t treat it as a use case unless you can consider it a goal in itself. For example, Specify the Bed Size (such as king, queen, or double) is an activity that you have to perform to reserve a room—but it’s only a part of the Make a Room Reservation use case because it never really stands alone and doesn’t (by itself) return a useful result. It’s not really a goal for the actor to use the system. However, you may consider Check Room Availability important enough to be a use case. It returns a value and could stand alone.

• Identify a completable behavior: To achieve a goal and produce value for an actor, the use case must complete. When you name the use case, choose a verb phrase form that implies completion or ending. For example, use Reserve a Room, rather than Reserving a Room, because the “ing” describes an ongoing behavior.

• Provide “inverse” use cases: Whenever you see a use case that accomplishes a goal that is to change a state in the system, you probably need a use case to un-accomplish that goal. For example, the use case Make a Room Reservation is undone with Cancel Room Reservation. Use cases that just obtain information don’t need an undo. (For example, you don’t need an undo for Check Room Availability.)

• Limit each use case to one behavior: Sometimes you might be tempted to have a use case achieve more than one goal or do more than one activity. To avoid confusion, keep the use case focused on only one thing. For example, the potential use case Check-in and Check-out is unfocused; it attempts to describe two different behaviors. If a proposed use-case name has an and or an or in the name, it’s probably too unfocused to be one activity.

• Represent the actor’s point of view: Write the use case from the actor’s point of view, using the terminology of the actor, not that of the system. Doing so allows the actors to review their use case properly without having to learn your system’s terminology. In addition, it helps keep you and your team learning—and using—your user’s terminology, making you more responsive to their needs. For example, you would allow a Guest to use the system to help Reserve a Room (using common Guest terminology), but you would not name that use case Schedule Room Assignment, because that’s a Hotel’s terminology and not the Guest’s.

 Tip   One hint that can help you find good names for your use cases is to put the name in the conversational words of a typical actor—for example, “System, please help me to <verb> <noun> <phrase>.” When you use this form, you automatically force the use-case name to adopt the actor’s point of view.