Modeling two use cases with an association between them, implying that the use cases communicate with each other.
Keywords: Dependency between use cases, combination of use cases, interacting use cases, messages between use cases, split a use case.
Each use case models a complete usage of the system. This means that an instance of the use case comprises the performance of the complete usage—that is, the execution of the actions inside the system as well as its interactions with specific persons and systems outside the system that is being modeled.
However, the use-case instance will never send messages to other use-case instances inside the same system. If it did, the use-case instance would not perform the complete usage, because it would request additional actions to be performed by another use-case instance. Clearly, if the actions executed by the other use-case instance must be performed for the usage to be complete, they must be included in the first use-case instance. Otherwise, the first use-case instance is incomplete.
Interacting use cases will occur when developers wrongly try to express the internal structure of the system in the use-case model by modeling the behavior of one part of the system in one use case and the behavior of another part in another use case. As you know, the use cases model the usages of the system as a whole and not usages of parts (see also Chapter 18, “Component Hierarchy”). Furthermore, the use-case model should not reveal anything about the internal structure of the system.
A model that is ill-formed because it contains use cases with associations between them can easily be corrected. The two use cases that seem to communicate should be merged and the original two use cases and their association be eliminated.
In practice this is best done by defining a new use case representing the whole flow expressed by the two use cases together. The flow of the new use case should consist of a merge of the two original flows, where all communication between them is eliminated.
Start by making sure where the combined flow starts (that is, which of the two use cases receives the initiating input from an actor). This actor will be the initiating actor of the new use case. Then, the first part of the new flow should be identical to the first part of that use case of the original two where the combined flow starts. When that original flow reaches a call to the other use case, this is ignored in the new flow, which instead should continue like the first part of the other use case's flow. The complete new flow is then constructed by interleaving parts of the original flows between internal calls like this.
When all parts of the original two flows have been captured in the new use case, the original two use cases and the association between them can safely be eliminated.
If it is still necessary to keep the two use cases separate, merging them is not appropriate. Instead, another kind of relationship has to be defined between them, the goal being that when performed, there should be just one use-case instance. This means that either an include or an extend relationship should be used between them:
If one of the use cases is complete without the other one, an extend relationship can be defined to that use case from the other one.
If one of them consists of a coherent subflow of the entire flow—that is, in the erroneous model it is called only once from the other use case—it can be an inclusion use case of the other one.
Most likely, neither of these two alternatives can be used immediately. Adjust the two use cases terms of moving subflows between them until either of the two conditions is met and an include or an extend relationship can be defined.