It may seem confusing to have two kinds of relationships between use cases that both imply adding a subflow into another flow. However, as described in the two previous chapters, their purposes are very different. The include relationship is intended for reusing behavior modeled by another use case, whereas the extend relationship is intended for adding parts to existing use cases as well as for modeling optional system services.
When modeling behavior common to several use cases, it may at times seem difficult to decide which of the two relationships to choose. The answer to the following question often clarifies whether an include relationship or an extend relationship is to be used: Which of the two use cases is to be dependent on the other, and which of them must not be dependent on the other (see Figure 9.1)?
Figure 9.1. The Withdraw Money use case is dependent on the Check PIN Code use case, but not the reverse. Moreover, the Withdraw Money use case is not dependent on the Log Transaction use case, whereas the latter is dependent on the Withdraw Money use case.
An include relationship is to be used when it must be possible to reuse the extracted behavior in different use cases—that is, when the extracted behavior has to be independent of where it is used. Moreover, the base use case is not complete without the extracted behavior; it is therefore dependent on the existence of the included use case.
The argument for the extend relationship is the opposite: The base use case is complete without the extension use case; it must therefore be defined independently of the existence of the extension use case. Moreover, the extension use case describes an addition to another use case; it is therefore dependent on that use case (the base use case).
The reason for extend being defined with a condition, and include without, is that most cases where include is used are not conditional, whereas most extend situations involve a condition. Therefore, they are defined in this way to support the most common situations.
To sum up the contrast:
Include is intended for common parts of use cases.
The base (including) use case is dependent on the inclusion use case, but not vice versa.
The base use case is not complete without the included use case.
whereas
Extend is intended for additional parts of use case flows.
The base (extended) use case is not dependent on the extension, but the extension use case is dependent on the base use case.
The base use case is—and must be—complete without the extension.
A few words of advice: Do not overuse the extend and the include relationships in your model, because they add to the complexity and to the size of the model. The extension and the inclusion use cases should make it easier to understand and maintain the model. Such a use case should either have an explicit value to the stakeholders, in the same way as ordinary use cases do, or be required by one of the stakeholders. Otherwise, its behavior should be merged into the base use case(s) and the extension/inclusion use case should be removed from the model. Overuse of relationships between use cases results in unnecessarily complex models that are hard to understand.
In the development of a use-case model, postpone all work with the relationships between the use cases until you have produced a first draft of the descriptions of the use cases and therefore can identify the true commonalities (and not imagined ones). Of course, if there are explicit requirements that two services must share a common part, or if you are positive you know what you are doing, add the relationships directly and just make sure to confirm them when you are producing the use-case descriptions. However, we have seen too many examples of projects introducing relationships between use cases just for the sake of it. Our advice is this: When in doubt, skip relationships between the use cases until you have identified and described all the concrete use cases and their actors (see also Chapter 26, “Use-Case Sequence”).