The extend-relationship connects an extension use case to a base use case. You define where in the base to insert the
extension by referring to extension points in the base use case (see Guideline: Use Case, the discussion on extension points). The extension use case is often abstract, but does not have to be.
You can use the extensions for several purposes:
To show that a part of a use case is optional, or potentially optional, system behavior. In this way, you separate
optional behavior from mandatory behavior in your model.
To show that a subflow is executed only under certain (sometimes exceptional) conditions, such as triggering an
To show that there may be a set of behavior segments of which one or several may be inserted at an extension point
in a base use case. The behavior segments that are inserted (and the order in which they are inserted) will depend
on the interaction with the actors during the execution of the base use case.
The extension is conditional, which means its execution is dependent on what has happened while executing the base use
case. The base use case does not control the conditions for the execution of the extension - the conditions are
described within the extend-relationship. The extension use case may access and modify attributes of the base use case.
The base use case, however, cannot see the extensions and may not access their attributes.
The base use case is implicitly modified by the extensions. You can also say that the base use case defines a modular
framework into which extensions can be added, but the base does not have any visibility of the specific extensions.
The base use case should be complete in and of itself, meaning that it should be understandable and meaningful without
any references to the extensions. However, the base use case is not independent of the extensions, since it cannot be
executed without the possibility of following the extensions.
The use cases Place Conference Call and Show Caller Identity are both extensions to the base use case Place Call.
In a phone system, the primary service provided to the users is represented by the use case Place Call. Examples of
optional services are:
We can represent the behaviors needed for these optional services as extension use cases to the base use case Place
Call. This is a correct use of the extend-relationship: since Place Call is meaningful in itself, you do not need to
read the descriptions of the extension use cases to understand the primary purpose of the base use case, and the
extensions use cases have optional character.
If both the base use case and the "base plus extension" use case must be explicitly instantiable, or if you want the
addition to modify behavior in the base use case, you should use use-case-generalization instead (see Work Product Guideline: Use-Case-Generalization).
The extension use case can consist of one or more insertion segments, each of which may have alternative paths built
into it. These insertion segments incrementally modify the behavior of the base use case. Each insertion segment in an
extension use case can be inserted at a separate location in the base use case. This means that the extend-relationship
has a list of references to extension points, equal in number to the number of insertion segments in the extension use
case. Each extension point must be defined in the base use case.
One base use case consist of several extend-relationships, which means a use case instance can follow more than one
extension during its lifetime. One extension use case may extend into several base use cases, but this does not imply
any dependency between the base use cases. There may even be multiple extend-relationships between the same extension
use case and base use case, provided the extension is inserted at different locations in the base. This means the
different extend-relationships need to refer to different extension points in the base use case. An extension use case
may itself be the base in an extend-, include-, or generalization-relationship. For example, this means extension use
cases can extend other extension use cases in a nested manner.
When a use-case instance performing the base use case reaches a location in the base use case where an extension point
has been defined, the condition on the corresponding extend-relationship is evaluated. If the condition is true or if
it is absent, the use-case instance will follow the extension (or the insertion segment within it that corresponds to
the extension point). If the condition of the extend-relationship is false, the extension is not executed.
The extension use case may, just like any use case, have a basic flow of events and alternative flows of events (see Guideline: Use Case, the discussion on structure of flow of events). Which exact
path the use-case instance will take through the extension depends on what has happened before in the execution (the
state of the use-case instance) and also what happens in interaction with actors as the extension is executed. Once the
use-case instance has performed the extension, the use-case instance resumes executing the base use case at the point
where it left off.
A use-case instance following a base use case and its extension.
An extension use case can have more than one insertion segment, each related to its own extension point in the base use
case. If this is the case, the use-case instance will resume the base use case and continue to the next extension point
specified in the extend-relationship. At that point it will execute the next insertion segment of the extension use
case. This is repeated until the last insertion segment has been executed. Note that the condition for the
extend-relationship is checked at the first extension point only - if the condition is true, the use-case instance must
perform all insertion segments.
A use-case instance following a base use case and an extension use case, the latter with two insertion segments.
The multiplicity of the extend-relationship will constrain the number of repetitions of the entire extension that may
occur. Note that it is the entire extension that is repeated (and limited by the multiplicity), not just one insertion
Describe the condition of the extension in terms of attributes of the base use case. You can also choose to omit the
condition, in which case the extension will always be executed.
Each extend-relationship has a list of references to extension points (one or more) in the base use case. The extension
points are referenced by name. If the extension use case has multiple insertion segments, you need to specify which
segment corresponds to which extension point. You also need to specify which steps or subflows of the extension use
case constitute each insertion segment.
In a phone system, the use case Place Call can be extended by the abstract use case Show Caller Identity. This is an
optional service, often referred to as "Caller ID", that may or may not have been requested by the receiving party. A
description of the extend-relationship from Show Caller Identity to Place Call could look as follows:
Condition: Receiving party must have ordered the service "Caller ID".
Extension Point(s): Show Identity - insert the whole Show Caller Identity use case.
You may give the extend-relationship a multiplicity, if it is omitted the multiplicity is assumed to be one.
Consider the following simple phone system:
The abstract use case Place Conference Call is an extension to the use case Place Call.
In this model, a simple representation of our familiar phone system, basic call service is described in the use case
Place Call. A step-by-step outline to the basic flow of events would look like this:
The Caller lifts receiver.
The system presents dial-tone.
The Caller dials a digit.
The System turns off the dial-tone.
The Caller enters the remainder of the number.
The system analyzes digits, determines network address of the Receiving Party.
The system analyzes the digits, determining the location in the network where the Receiving Party exists.
The system then determines whether a virtual circuit can be established to the Receiving Party.
If a virtual circuit can be established, the System rings the Receiving Party's phone and presents the ringing tone
on the Caller's phone.
When the Receiving Party answers the phone, the system disables the ringing tone on the Caller's phone, stops
ringing the Receiving Party's phone and completes the virtual circuit.
The system starts a billing record, recording the start time for the call, the end points of the call, and the
Caller's customer information.
The call continues for some length of time. When either the Caller or the Receiving Party disconnects from the
call, the system records the end time for the call, and frees all resources required to support the virtual
circuit. The use case then ends.
To add functionality to this system that would allow the caller or receiving party to connect a third party to the call
(often called "conference call"), we need to add behavior to the flow of events. One alternative, and the first one we
should consider, is to put the differences directly into Place Call. We could model these differences using alternative
flows of events, as described in Guideline: Use Case. This solution works for most simple additions, where the added functionality will not confuse or obscure the
original meaning of the use case. The other alternative is to separate the differences into an abstract extension use
case called Place Conference Call which extends the base use case.
The Place Call use case would have the following addition:
Conference Call occurs after step 11.
The extension use case, Place Conference Call, could then be described as:
Place Conference Call Use Case
This use case extends Place Call. It is inserted at extension point Conference Call.
1. Caller depresses the hang-up, link, or flash button.
2. The system generates 3 short beeps to acknowledge.
3..12.<these steps are identical to steps 3..12 from the base use case>
13. Caller is reconnected to the receiving party from the Place Call use case.
The commonality of steps 3..12 with the base use case is undesirable. One way to solve this is to factor out the
common part as an inclusion use case (see Guideline: Include-Relationship).