Structure a use case comprising a large number of actions. There are two “dimensions” along which a use case may be large: It may either be “long”—consist of a very long sequence of actions—or it may be “fat”—include many different flows.
Characteristics: Moderately common. Basic solution.
Keywords: Alternative flow, large use-case description, long use case, multiple paths, structuring use-case descriptions.
The first Large Use Case pattern contains a use case consisting of a very long sequence of actions that is always to be performed as one unit.
This pattern must be chosen when splitting the large use case would result in two use cases where one of them is always to be performed immediately after the other; hence, at least one of them will not model a complete usage of the system. The inevitable drawback is that the description of the use case becomes very long, calling for clever text structuring.
An alternative pattern models the large usage with multiple use cases, each of them modeling one alternative of the usage of the system.
This pattern is applicable when the usage to be modeled consists of multiple alternative flows. In this case, each of the longer flows can be modeled as a separate use case. This will keep the description of each use case shorter and more manageable instead of merging them all into one huge description.
A surprisingly common question is “How large is a use case?” Unfortunately, there is no simple answer, like “a description of a use case is two to three pages,” “a use case comprises four to seven stimulus-response transactions,” or “in a use case there are at most 10 actions per input stimulus.” These numbers can vary a lot and still be reasonable. In some systems, the use cases are very short and simple. For example, one use case may receive an input stimulus carrying some information that is only checked for completeness and then stored in the system, or it may receive a request from an actor and as a response retrieve some information stored in the system and present it to the actor. In other systems, the use cases will receive very few stimuli but perform hundreds of actions as the response to each of these stimuli. Hence, the proper answer to the question is this: A use case and its description are as large as they must be.
Many use-case modelers have been told that a use-case description should be kept rather short and that one should watch out for descriptions being more than three pages long. This is good advice, because a long use-case description can be a warning sign that too much is covered by that use case (see Chapter 43, “Mistake: Multiple Business Values”) or the use case is described at too low level of detail (see Chapter 42, “Mistake: Mix of Abstraction Levels”). However, sometimes a use-case description has to be long, simply because the use case will perform many actions or it will have multiple alternative flows. In neither of these cases should the description be condensed so that it will fit into, say, three pages, because this would reduce the number of necessary details so the description will not be understandable or it will cease to be useful for the designers of the system. Therefore, a use case that is perceived as large is not necessarily an incorrect use case.
When the flow of a use case is long, as in the Large Use Case: Long Sequence pattern, its textual description must be structured wisely. Apart from describing the alternative flows in separate subsections, a few other structuring techniques may be applied. The first one is to organize a description of a flow that is long by introducing headings, just like in ordinary text. In general, however, we do not recommend using more than two levels of headings within the description of the flow, because this would make the structure of the text overly complicated and fragmented.
The description of the basic flow of a use case ordering flight tickets can be structured as follows:
A second option is to extract descriptions of coherent subflows into subsections of their own, to be referenced from the main description (see the Example section, below). Together with a reference to the separate subsection, a short summary of the extracted text should be provided in the main description to give the reader an indication of its contents. In this way, the reader will get an overview of the complete flow and can study the detailed descriptions when needed. This proves particularly useful if the use-case description includes technical details of little or no interest to some categories of readers (see also Chapter 25, “Orthogonal Views”).
Of course, these two techniques can be combined. However, remember to keep the overall goal in mind: Use-case descriptions should be easy to understand and to review by all relevant stakeholders. Therefore, the level of abstraction in the description should not be modified just to make the description short. Instead, to make them effective, the same level of detail should be used in all descriptions for the same use-case model (see Chapter 13, “Describing Use Cases,” Chapter 30, “Legacy System,” and Chapter 42, “Mistake: Mix of Abstraction Levels”).
When two or more equally important variants of a use case can be distinguished, it is possible to split the use case and promote the variants into use cases of their own, according to the Large Use Case: Multiple Paths pattern. If the variants have different business values, they should be modeled as separate use cases; even if they have the same business value, the variants may be split into separate use cases just to make the descriptions easier to handle and understand. Of course, it is never a good idea to make a separate use case of a small alternative flow or of an exceptional flow, because this would make the descriptions of the use cases as well as the use-case model as a whole more difficult to understand.
If the same short alternative flow is to be used in several of the use cases, it can be extracted into a separate inclusion use case (see Chapter 17, “Commonality”). Similarly, if the same statements, rules, and regulations about the business are valid for several of the use cases, these facts should be expressed as business rules and be referenced from the descriptions of the use cases (see Chapter 16, “Business Rules”).
In this example, there is only one use case, named Register Insurance Tender (see Figure 21.1). In this use case, the Insurance Agent, most likely sitting together with the policyholder to be, will register all the information about the policyholder, the beneficiaries, and so on. When all information is entered, the use case will check whether the tender can be sent for immediate approval or whether a more thorough evaluation of the tender must be done (if the policyholder practices sky diving, for example).
This is an example of the Large Use Case: Long Sequence pattern. The basic flow gives an overview of how the use case is usually performed. The description includes references to other subsections of the use-case description that contain the detailed descriptions of the flow.
Other useful patterns in this example are the Business Rules, the CRUD, and the Multiple Actors patterns.
There is no analysis model for this chapter because the size of the use-case description does not affect the structure of the analysis model. However, if the system as a whole is large, it might be good to organize it in subsystems (see also Chapter 18, “Component Hierarchy”).