The Use Case Model

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 convenient when multiple systems are being jointly developed, and it can be clearly seen which use cases are part of which system. The complete collection of use cases, actors, and diagrams forms a use case model, which, like individual use cases, is just one part of the system's requirements specification.

Relationships between actors and use cases indicate that the actor can invoke a particular use case. Figure 8-4 shows that the actor can browse the catalog or check on the order status. This diagram also identifies two other actors: the Merchant Account System and the Shipping Department. These actors are in fact not individuals but rather external systems, or more accurately the APIs of those external systems. When the Process Payment use case is invoked, it initiates the dialogue between the Merchant Account System and this system; similarly, the Ship Order use case contacts the Shipping Department's system when invoked.

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 necessarily include checking out. The relationships between the Checkout use case and the Process Payment and Ship Order use cases, however, are expected with every invocation of the Checkout use case. The «includes» relationship indicates that each invocation of the Checkout use case will invoke the included use cases at least once. This type of a relationship can be thought of as calling a subroutine.

The use case model shows the structural relationships between use cases but does not show dynamic relationships, or workflows. Dynamic behaviors are expressed with interaction diagrams: sequence, collaboration, and activity. It is important to keep that in mind when drawing use case diagrams. It's easy to start constructing use case diagrams as if they were workflow diagrams, since use case names often reflect major activities of the business workflow. Most associations between use cases in a diagram simply imply that one invokes the other, nothing more.

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 sort out all the alternative flows in a use case and ensure that I haven't forgotten how any of them rejoins the basic flow. In the past, I helped draft a few use cases in which later iterations added alternative flows that seemed reasonable and addressed the issue at the time, but when it came to implementing them, it wasn't clear in what state those alternative flows would leave the system and at what point the normal flow of the use case scenario should resume. Properly created activity diagrams for a use case clearly identify all alternative paths as branches and even allow us to see the effects of repetition, or loops , in the flow that would otherwise be mentioned only in the text of the use case specification.

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 guarded with conditions—text between the brackets—and indicate the availability of an option that the actor can invoke.

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 hyperlinks to other diagrams, I highly recommend hyperlinking these notes to the relevant activity diagram to make it easier for the reader to follow the flow through all the related use cases.

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 demonstrates that it is possible for the actor to follow a path from start to finish without hitting the Request Checkout activity and thus invoking the Checkout use case.

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 considered an included use case because it is part of the "happy-path" scenario, or basic flow. It is the exceptional case, when the payment is not received, that causes the activities to bypass the commitment of the order.

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 evolve , this scenario will be referenced and elaborated on in each model's use case realizations. A use case realization is in part an explanation of how a use case is implemented with the elements of the specific model it is in. For example, in the design model, this sequence diagram would have a number of design-level objects instead of the System object and messages to and from the design objects that correspond to methods defined in their classes.

Avoiding Functional Decomposition

An extremely common mistake many new and experienced use case modelers make is to start thinking of use cases as primarily bundles of functionality, not dialogues of interactions between the actors and the system. Functional decomposition is the term for a use case model that describes bundles of system functionality independent of the user . Systems with many small use cases, such as Enter Payment Information, are examples of models that have degenerated into functional decomposition.

Even the most seasoned use case modeler can get confused at times. Ironically, while writing this chapter, I was also engaged in a discussion of how to model a certain set of use cases for a medium- size Web application. The two relevant use cases are Sign In and Create New Account. The Sign In use case is a classic log-on use case, which simply states that the actor enters a valid user name and password to change his or her state with the system: ^[5]

^[5] Yes, I know that many people consider a Sign In use case insufficiently large to warrant a use case by itself, but that argument has been going on in the industry for some time, and I am not about to get sucked into it myself .

1. A user requests to sign in.

2. The system prompts for a valid user name and password.

3. The user supplies the valid user name and password.

4. The system validates the user name and password and sets the user's state to "signed in."

The Create New Account use case scenario also is simple:

1. A user requests a new account with the system.

2. The system prompts for desired user name, password, demographic, payment, and e-mail information.

3. The system notifies the user that the account name and activation code have been e-mailed to the user.

4. The user reads the e-mail, with own e-mail client.

5. The user navigates back to the system and authorizes the system by entering the user name and activation code.

6. The system validates the code, activates the account, and signs in the user.

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.

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 sign-in functionality is included when creating a new account but not the use case flow of events for Sign In. Figure 8-9 shows an early analysis model for these use cases. The analysis model, discussed further in Chapter 10, is a logical model, and it is here that we see how the Create New Account controller can invoke the functionality of the Sign-In controller through an association between the two. Figure 8-10 shows the correct use case model for these two use cases.

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.

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 teams . Of course, during reviews, every use case owner will look carefully at all the available details of those use cases they depend on.

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 next phase of development can continue on some of the architecturally significant use case packages. The determination of these architecturally significant use cases is made by the architecture team and project management.

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 targeted for early development. The architecture team also looks for use cases that exhibit "standard" functionality and that can be used as a future exemplar. Project management looks for use cases that will be easy to complete and for those that demonstrate some of the system's core behavior. It is important for the team to be successful in its first iteration of use case development, and it is also important for real progress to be demonstrated to the stakeholders. Together, the architect and the project manager pick use cases and packages of use cases to be developed first in the next phase of development.