The Use Case Model
UML has special representations for use cases and actors. A simple ellipse represents use cases; simple stick figures, actors. A use case diagram expresses the system's use cases in relation to the actors that invoke them. I prefer to construct these diagrams with an adornment that draws a boundary around the system, placing the use cases within the boundary and the actors outside (Figure 8-4). This notation is
Figure 8-4. Top-level use case diagram for an e-retail system
Relationships between actors and use cases
Relationships between use cases are also documented in the model and appear in a diagram as a stereotyped dependency relationship, or arrow-headed dashed line. The two major types of relationships between use cases are «includes» and «extends». Both indicate a dependency on one use case by the other; however, the subtle difference between the two has, in my experience, caused a significant degree of confusion.
In Figure 8-4, the use case Checkout extends the use case Browse Catalog. This means that the actor invoking the use case might decide to extend the dialogue with the system to include the activities described in the Checkout use case. The key word here is "might." Every invocation of the Browse Catalog use case does not
The use case model shows the structural relationships between use cases but does not show dynamic relationships, or workflows. Dynamic behaviors are
There's more to the use case model than this high-level diagram. I've recently begun to create a single activity diagram for each use case in the system. This activity diagram helps me
Figure 8-5, the activities for the Browse Catalog use case, shows a typical activity diagram for a use case that has some repetition. It is clear from this diagram that there is one main loop structure, labeled the Shop controller. Many of the branches are
Figure 8-5. Activity diagram of the Browse Catalog use case
As a notational convention, I add notes to the activity diagram at those points where the use case is extended or included. If the modeling tool you use supports the inclusion of
The activity diagram of a use case clarifies the nature of the «includes» or «extends» relationships. In the case of an «extended» relationship, it should be possible for the actor to get from the start activity to an end activity without invoking the extended use case. Figure 8-5
When the actor does decide to check out, the flow of activities shifts to the Checkout use case. In Figure 8-6, the activities of the Checkout use case clearly show how the included use cases are part of the basic flow. Even though one possible path through the use case does not invoke the Ship Order use case, it is still
Figure 8-6. Checkout use case activities
Another recommendation is to create a sequence diagram for each named use case scenario: basic and alternative flows. Document each with text taken directly from the use case specification, if practical. This serves two purposes. First, it provides the template later models will use when constructing use case realizations; second, it helps you identify and pull out the most important statements in use case text. If you have particularly wordy use cases, the exercise will force you to simplify the text to fit in the sequence diagram. Figure 8-7 shows a sequence diagram for the Browse Catalog use case basic flow scenario. This diagram is simple and for use case readers probably doesn't provide much additional value; however, as the rest of the systems models
Figure 8-7. Browse Catalog basic flow sequence diagram
Avoiding Functional Decomposition
An extremely common mistake many new and
Even the most seasoned use case modeler can get
The Create New Account use case scenario also is simple:
Figure 8-8 shows the use case model and an «includes» relationship between the Create New Account and Sign In use cases. This relationship was drawn because "logically," the Create New Account use case signs in the user when the account has been activated. The problem is, at no point during the invocation of the Create New Account use case has the user participated in the dialogue described by the Sign In use case. During account activation, the user does not need to enter a password, with the assumption that the activation code to validate the user is unique.
Figure 8-8. Use case model with functional decomposition
The point is, it may seem as though the Sign In use case is included when creating a new account; however, from the use case model point of view, the flow of events as described in the Sign In use case is never executed when creating a new account. Logically, the
Figure 8-9. Analysis model showing logical connection between Create New Account and Sign In
Figure 8-10. Use case model restructured to remove the functional decomposition
Use Case Model Structure
In the first iteration of the requirements-gathering phase, most of the attention is focused on the overall structure of the use case model. Even modest applications have a significant number of use cases: so many, in fact, that they need to be organized a little further. The idea of dividing a problem into smaller, more easily managed ones is not new. A use case model is often divided into packages. Each package owns a set of use cases or even other packages of use cases. A package is a UML mechanism for dividing a model into more manageable pieces. In a diagram, a package is rendered as a tabbed folder. Figure 8-11 shows a set of packages. The two top-level packages—Storefront and Warehouse—each contain additional packages that divide up the use cases inside of them across functional boundaries. In this diagram, some key dependencies are drawn between the packages, indicating that one or more use cases in the Shopping package have relationships with one or more use cases in the Inventory and Shipping packages.
Figure 8-11. Use case package diagram
As the use case definition activity progresses and a top-level use case diagram is completed, the project manager can assign separate packages and use cases to different requirements teams to complete. Careful coordination is necessary for those teams with packages and use cases that have relationships with those owned by other teams. In the initial iteration, this is usually accomplished by completing the goal statements of all the use cases involved and leaving the individual teams to fill in the use cases' details later. The goal statement becomes a temporary contract between the
In the early iterations, requirements teams usually own packages, not individual use cases; at this point, many of the system's use cases have not even been defined yet. Each team treats the package as its own isolated system. The system, of course, has relationships with other systems via package and use case dependencies, but the focus is on the set of goals and use cases owned by the package.
The first pass of the use case model usually is a milestone indicator for the end of an iteration. It doesn't mean that all the use cases are complete; in fact, for moderate- or large-scale applications, they are rarely complete this early in the project life cycle. It does indicate that the
The architecture team looks for use cases that possess a certain technical risk. Use cases that depend on new technologies or interfaces to external systems are