One large use case with include relationships to a set of inclusion use cases, each modeling a subfunction of the large use case.

Keywords: Large use case, level of abstraction, levels of use cases, long use case, split a use case.

Traditional techniques for decomposing a function into smaller subfunctions are sometimes mistakenly used for extracting subflows of a use case into separate, inclusion use cases. The base use case can then be seen as an assembly of, or a composition of, the included use cases. Consider, for example, the functional decomposition of a compiler into the subfunctions Parse Stream, Perform Semantic Check, Perform Type Check, and Generate Output. Defining separate use cases for each of these functions and an aggregate use case called Compile Stream with include relationships to them results in a typical example of this mistake. Basically, the Compile Stream use case will contain no additional actions except what is included from the other use cases.

Use cases model usages of a system. Each such usage provides a value to a stakeholder of the system; that is, there is someone, usually a user of the system, who has an interest in that use case. To make the use-case model easier to maintain, it is possible to extract subflows into separate, abstract use cases that are to be included by or to extend the original base use case. This should be done, for example, when we want to model commonalities between use cases (a subflow is to appear in multiple use cases), when there are to be different system configurations (a subflow should appear only in some configurations), when the subflows are defined in different layers, or when a stakeholder requires that a subflow be explicitly stated in the use-case model.

However, extracting subflows into separate use cases just to make them explicit to the developers is not an acceptable reason! The size of the model will increase, there will be more documents to maintain, no other stakeholder will be interested in and defend the existence of those use cases, and, perhaps most importantly from a modeling perspective, the overview of the complete usage of the system will be lost.

To sum up, a use case should not be functionally decomposed as the overview of the complete usage will be lost and the cost for maintaining the model will be increased.

The way out from the decomposition trap is to take a few steps back: We must return to basics; that is, first we have to verify that all the base use cases really represent complete usages of the system initiated by actors. Then we must eliminate all inclusion use cases with no clear value to a stakeholder other than the developers and merge them with their base use cases.

Doing this merge is quite straightforward: In each place where the use-case description of the base use case says that another use case is to be included, determine whether that use case is among those that should remain in the model, or whether it is to be merged with the base use case. In the latter case, replace the statement to include the other use case with the flow of the inclusion use case. Then the include relationship and the inclusion use case can be eliminated from the use-case model.

When we are tempted to make use of functional decomposition, it is often an indication that we are dealing with a system that is so large and complex that it is hard to create an overview of it and at the same time provide enough details. Such situations should be handled using a Component Hierarchy pattern (see Chapter 18, “Component Hierarchy”) or a Large Use Case blueprint (see Chapter 21, “Large Use Case”).