Modeling an alternative flow of a use case as an extension of that use case.
Keywords: Addition to flow, alternative flow, extend relationship, extracting flow.
A use case has one flow, or sometimes multiple flows, considered to be the normal or basic flow of that use case. This flow will be performed when everything goes according to plan in the use case; this is the flow a reader of the model will associate with the use case.
However, a use case also includes variants of that flow to be used if a condition is not fulfilled, if something goes wrong, if the actor gives an unexpected input, and so forth. All of these are different paths through the use case, and from a user's perspective, all of them are important. Remove one of them and the system will not function properly—it might even crash. Similarly, adding one of these alternative flows to another flow or appending it to another flow will also result in strange and unwanted behavior of the system. Unfortunately, this is what often happens when an alternative flow is extracted from a use case into an extending use case.
The reason for this is to be found in the definition: The meaning of an extend relationship is that the extension may be added to the flow of the base use case (see Chapter 8, “Extend: Expanding Existing Use Cases”). This implies that behavior of the base use case cannot be replaced by behavior defined in the extension use case. Therefore, it is not possible to extract an alternative flow into an extension use case, because this extracted behavior will be performed only in addition to and not instead of what is described in the base use case.
To overcome this problem, we might erroneously believe we could use the condition of the extend relationship to be able to extract the alternative behavior. For example, we might consider describing the true-path in the base use case together with the statement that this path is only to be taken if the condition is evaluated to true, and extracting the false-path into an extension use case. The extend relationship will state that the addition is to be made at the location of the condition in the base use case, and the condition of the relationship will be the negation of the condition in the base use case. The problem with this scenario is that the base use case becomes dependent on the extension use case; the base use case is not complete without the extension use case as it is lacking what is to happen if the condition is not fulfilled.
Obviously, we must correct the ill-formed model by merging the base use case and the extension use case. The flow captured in the extension use case is moved into the base use case, where it will be an alternative flow, and then the extend relationship together with the extension use case is removed from the model. Note that it is not necessary to also remove the extension point from the (former) base use case, because having an extension point does not change the behavior of a use case in itself. In fact, it must not be removed without making absolutely certain that it is not used by another extension use case or planned to be used in a future version of the model.
If it is still desirable to model the alternative flow as a separate use case, you can do so by using an include relationship between the two use cases. This works because in an include relationship, there is no problem with the base use case being dependent on the inclusion use case (see Figure 37.1). However, before choosing this way out, it is important to make sure that the inclusion use case has a business value of its own. In this case, only the extension relationship and possibly the extension point is removed from the model, and an include relationship is added instead.
