Organizing Use Cases

The UML offers three constructs for factoring out common behavior and variant paths for use cases. The following subsections describe these constructs.

Include

Within an include relationship, one use case explicitly includes the behavior of another use case at a specified point within a course of action.

The included use case doesn't stand alone; it has to be connected with one or more base use cases. The include mechanism is very useful for factoring out behavior that would otherwise appear within multiple use cases.

Within Figure 4-5, the Add to Wish List and Check Out use cases include the behavior captured within the Log In use case, because a Customer must be logged in before he or she can add a book to a wish list or make a purchase.

Figure 4-5: Include

Extend

Within an extend relationship, a base use case implicitly includes the behavior of another use case at one or more specified points. These points are called extension points.

You generally use this construct to factor out behavior that's optional or that occurs only under certain conditions. One way to use extends is in creating a new use case in response to an alternate course of action having several steps associated with it.

Figure 4-6 shows that a Customer has the option of canceling an Order in conjunction with checking the status of that Order.

Figure 4-6: Extend

If it's desirable to show an explanation of when a use case extension comes into play, you can show this in a note, as illustrated in Figure 4-7.

Figure 4-7: Explaining a use case extension

Note ‚  

You have the option of using standard class notation to represent a use case, with the use case ellipse in the name compartment , and to add one or more compartments to the class box to hold relevant information ‚ for example, multiple extension points. See Figure 4-8.

Figure 4-8: Use cases (secondary notation)

Use Case Generalization

Generalization works the same way for use cases as it does for classes (see the section "Generalization" in Chapter 2): A parent use case defines behavior that its children can inherit, and the children can add to or override that behavior.

Figure 4-9 shows use cases that describe three different searches that a Customer can perform, all of which use the basic search technique defined by the Perform Search use case.

Figure 4-9: Use case generalization

Note ‚  

You can also use generalization with actors. For example, there might be a general Accounting Personnel actor, which has certain privileges, and then Accountant and Accounting Clerk actors that represent more specialized usage privileges than those actors have.