ORGANIZING USE CASES

A small system may be expressed as a half- dozen use cases that involve two or three actors. As you tackle larger systems, however, you must define structuring and organizing principles. Otherwise, you can sink under a profusion of use cases, some of which have in common major parts of the flows of events. This profusion may make the requirements hard to understand and can make activities such as planning, prioritizing, and estimating very difficult.

The first structuring concept is that of a use-case package , in which you group related use cases into one container. You can also exploit relationships among use cases. To achieve this, you must look closely at the flow of events.

You can view a flow of events as several subflows ”one main flow and one or more alternate flows ”that, taken together, yield the total flow-of-events description. You can then reuse the description of a subflow in the flows of events of other use cases: subflows in the description of one use case's flow of events may be the same as those of other use cases. Further along, in design, this can assist you because you should have the same objects perform this same behavior in all the relevant use cases; that is, only one set of objects should perform this behavior no matter which use case is executing.

If the behavior is common to more than two use cases, or if it forms an independent part, the model might be clearer if you model the behavior as a use case of its own that can be reused by the original use cases. There are three ways to exploit commonality among use cases:

Inclusion
Extension
Generalization/specialization ^[3]

^[3] Starting with UML 1.3, the "uses" relationship between use cases has been broken down between "include" and generalization/specialization; the "uses" relationship has therefore been eliminated to prevent confusion.

Several use cases can include a common flow-of-event text organized as a use case. This technique is similar to the factoring you do in programming by means of subprograms. In the ATM example, both Withdraw Money and Check Balance include "User enters PIN." There is no need to express the flow of events associated with the entry of the PIN two or three times in the same model. Both use cases could include a use case "Authenticate the User." ^[4]

^[4] This very small example may be misleading. Do not fall into the trap of doing functional decomposition, in which you break down all use cases into a myriad of little, meaningless use cases that fail to be of value to any actor.

A use case can extend an existing one. For example, in a telephone switch, a basic person-to-person telephone call can be extended by call-forwarding or conference-call functionality. The extension occurs at specific points, called extension points , in the extended use case. The extension can be thought of as "injecting" additional descriptive text into the extended use case, at the extension point, under particular conditions. Extension is used primarily to simplify complex flows of events, to represent optional behavior, or to handle exceptions. The result of modeling with extensions is that it should make the basic flow of events of a use case easily understandable and should make the maintenance of the use-case model easier over time. Unlike the earlier "include" example, in which the basic flow of events is incomplete without the inclusion, when you use "extend," the basic flow of events should still be complete; it should not have to refer to the extending flow of events to be understandable.

A use case can specialize a more general one by adding to or refining the original flow of events. For example, in an air-traffic control system, the Entry of an ICAO Flight Plan follows the same basic principles and sequences of actions as the general Entry of a Flight Plan but has some refinements as well as specific steps, or attributes. Specialization in the use-case model provides a way to model the behavior of common application frameworks and makes it easy to specify and develop variants of the system.

A common mistake is to overuse these three relationships, a practice that leads to the creation of a use-case model that is difficult to understand and maintain. It also generates a lot of overhead costs.