Modeling single operations performed by the users as separate use cases, resulting in a use-case model consisting of a large number of very small use cases.
Keywords: Functional decomposition, large number of use cases, level of abstraction, order between use cases, simple operation, small use case.
A good indicator that this mistake has been made in a use-case model is the large number of use cases. Furthermore, studying the names of the use cases will reveal that the use cases model single operations. If not before, this will become obvious when the description documents for use cases are prepared and it becomes evident that the flows are very short. In other words, each document will contain extremely little substance, and no one will be interested in them individually but only in what sequences the use cases can be performed.
Therefore, an additional indication of this modeling mistake is that there will be a need to express the order in which this huge collection of use cases is to be performed. It may even be tempting to introduce communication between use cases to make the sequences explicit, which of course is a clear indicator that something is wrong (see also Chapter 39, “Mistake: Communicating Use Cases”).
When modeling a system, especially when it is an already existing system, it is sometimes tempting to focus on the different actions a user can perform and express these as use cases. The cause of this error is often focusing on how to interact with the system or on its user interface, instead of on what the user wants to do with the system.
An example of micro use cases is a model where each single menu alternative in the GUI is modeled by a separate use case. In such a case, the flow of each use case will consist of the user selecting one alternative from a menu, and the system's response to this selection.
In general, a single user-provided input together with the corresponding system response will seldom provide a business value to any stakeholder—no user will use the system just to provide this single input. For this reason, it is not a complete usage. Of course, such use cases do exist, but most use cases consist of several user actions in a sequence.
Obviously, we must consider how the users would like to use the system. We also have to define a use case for each set of micro use cases that are to be performed together, that is, the sequences that make up the complete usages.
Merging a set of small use cases into larger ones according to the sequence in which they are to be performed is done by first defining a new use case to capture the complete usage. Then the small use cases should be taken one by one, starting with the one that is performed first. The flow of this use case makes up the first part of the new use case's flow. The next part of the flow consists of the flow of the second micro use case, and so on. As soon as the flow of a micro use case is appended to the new use-case flow, it should be removed from the use-case model.
Note that the resulting, merged use cases will contain the actions of the micro use cases as part of their flows. However, it is important not to fall into the trap of composing the new, proper use cases by defining include relationships to the micro use cases! This would result in another ill-formed use-case model where the model would still contain use cases without business value (see Chapter 40, “Mistake: Functional Decomposition”).