25.3. The extend Relationship

Suppose a use case's text should not be modified (at least not significantly) for some reason. Perhaps continually modifying the use case with myriad new extensions and conditional steps is a maintenance headache, or the use case has been baselined as a stable artifact, and can't be touched. How to append to the use case without modifying its original text?

The extend relationship provides an answer. The idea is to create an extending or addition use case, and within it, describe where and under what condition it extends the behavior of some base use case. For example:

This is an example of an extend relationship. Note the use of an extension point, and that the extending use case is triggered by some condition. Extension points are labels in the base use case which the extending use case references as the point of extension, so that the step numbering of the base use case can change without affecting the extending use case—indirection yet again.

Sometimes, the extension point is simply “At any point in use case X.” This is especially common in systems with many asynchronous events, such as a word processor (“do a spell check now,” “do a thesaurus lookup now”), or reactive control systems. Note however, as described in the prior include relationship section, that include can also be used to describe asynchronous event handling. The extend alternative is an option when the base use case is closed to modification.

Note that a signature quality of the extend relationship is that the base use case (Process Sale) has no reference to the extending use case (Handle Gift Certificate Payment), and therefore, does not define or control the conditions under which the extensions trigger. Process Sale is complete and whole by itself, without knowing about the extending use case.

Observe that this Handle Gift Certificate Payment addition use case could alternatively have been referenced within Process Sale with an include relationship, as with Handle Credit Payment. That is often suitable. But this example was motivated by the constraint that the Process Sale use case was not to be modified, which is the situation in which to use extend rather than include.

Further, note that this gift certificate scenario could simply have been recorded by adding it as an extension in the Extensions section of Process Sale. This approach avoids both the include and extend relationships, and the creation of a separate subfunction use case.

Some use case guidelines recommend using extending use cases and the extend relationship to model conditional or optional behavior inserted into the base use case. This is not inaccurate, but it misses the point that optional and conditional behavior can simply be recorded as text in the Extensions section of the base use case. The complication of using the extend relationship and more use cases is not motivated only by optional behavior.

What most practically motivates using the extend technique is when it is undesirable for some reason to modify the base use case.