4.2 Working with Use Cases

Often candidate use cases include items that require an actor's intervention to complete the activity. This intervention is itself a separate activity that could become its own use case. Consider, for example, a use case Order Books. When the customer completes an order, the system sends a message to the credit card company to approve the charge. It is unclearwhether the response from the credit card company is a separate use case or not. In addition, this informal description introduces vocabulary ("message") that does not belong in the Bookstore domain.

This section provides guidance on working with use cases that span several domains and when a use case should be decomposed into other, smaller use cases.

4.2.1 Single-Domain Use Cases

As noted in Section 3.2: Domains and Requirements, for our purposes in organizing modeling, we want to work with a vocabulary consistent with the domain. It is therefore critical that the description of each use case employ the vocabulary of the domain under study. The flow description shown in Figure 4.5 describes requirements on domains other than the Bookstore domain. These "extra-curricular" requirements are shown in italics.

Figure 4.5. Typical Flow Description for an Order Books Use Case

The flow description should be rewritten to use only the single vocabulary of the domain under study. Figure 4.6 shows a revised the flow description using only the vocabulary of the Bookstore domain.

Figure 4.6. Revised Flow Description for an Order Books Use Case

4.2.2 Levels of Use Cases

So, what is the right level of detail for use cases? Cockburn [2] identifies several different levels of use cases. Those at the "sky" level involve a broad system goal, such as Order Books. These use cases are useful for getting a grip on the problem as a whole, without being overwhelmed by too much detail.

The next level of use cases, those at the "kite" level, are the more detailed steps a user takes to achieve a goal. For the bookstore customer, these would include Start New Order, Add Item to Order, and Check Out Order. Constantine and Lockwood [3] conceive of use cases primarily at this level, at the level of user goals. These use cases tend to be written in the language of the user, so they naturally apply to a single domain.

"Sea level" use cases are single system interactions: The actor requests a service, and the system is capable of making a complete response, with no additional interaction with any actor. For example, the kite-level use case Check Out Order needs other actors to carry out the checkout process: The credit card company approves the charge, a shipping clerk packs the order, and a delivery company picks up and delivers the order. Each of these actors initiates system interactions that involve no other intermediate intervention while contributing to the overall kite-level goal of check ing out an order. Figure 4.7 shows a use case diagram with a set of single-interaction use cases.

Figure 4.7. Order Books Identified as Single-Interaction Use Cases

"Mud-level" use cases are even lower than single system interactions and generally describe the mechanics of how the system will implement functionality. These often mix in the vocabulary of the mechanics of a particular user interface, middleware, or messaging technology.

Note that some "kite-level" use cases such as Start New Order also appear as single-interaction "sea-level" use cases, because they are both at the level of a user goal, and they happen not to involve other actors. Because use cases can be expressed at a number of different levels, it is quite tempting to decompose use cases and to form a neat hierarchy all the way down into the mud. However, our objective is not to analyze the system with use cases (the dreaded "abuse by decomposition" [4]), but rather to understand enough about the domain to build executable models.

4.2.3 Applying Use Cases

We recommend using use cases in two ways: to provide a foundation for modeling and as fodder for test cases.

Use cases and modeling.

Use cases are helpful in learning the vocabulary of the domain from a user perspective.As the problem becomes better understood,it is your job as developer to abstract the requirements expressed in the use cases into a set of classes and their behaviors,as described in subsequent chapters. This abstraction frequently increases the semantic gap between the models and use cases,and that 's a good thing.

Generally, sky-level use cases are useful to get you started, but are too high-level to provide enough detail (by themselves) for modeling. Sea-level use cases, in particular those developed before any modeling is started, can easily overwhelm you with too much detail, though it is occasionally useful to drill down some especially difficult use cases to that level. Mud-level use cases that incorporate other domains, particularly the user interface, are worse than useless.

Kite-level use cases provide the level of use cases needed for modeling.

Use cases and test cases.

The second application of use cases is as fodder for test cases. A good use case, with a definition for the required behavior, describes the behavior that needs to be tested well. For this, sea-level use cases are best, assembled into larger kite use cases as required. Chapter 15: Domain Verification covers in detail the process of testing models.