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 Concept: 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
alarm.
-
To show that there might be a set of behavior segments of which one or several can 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 can access and modify attributes of the base use
case. The base use case, however, cannot see the extensions and cannot 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 must be complete in and of itself, meaning that it must be understandable and meaningful
without any references to the extensions. However, the base use case is not independent of the extensions, because
it cannot be executed without the possibility of following the extensions.
Example:
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: because 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.
The extension use case can consist of one or more insertion segments, each of which can 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 can extend into several base use cases, but this does not
imply any dependency between the base use cases. There can 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 might 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 Concept: 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 start the next insertion segment of the extension use
case. This is repeated until the last insertion segment has been executed. 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 can occur. It is the entire extension that is repeated (and limited by the multiplicity), not just one
insertion segment.
The base use case does not have dependencies to the extended use case(s), but the extended use case requires at least
one base use case. Without it, the extended use case is not a complete end-to-end scenario and would be out of context.
Documenting the Extend-Relationship
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.
Example:
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 can or cannot 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 can 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 enable 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 must consider, is to put the differences directly into Place Call. We could model these differences
using alternative flows of events, as described in Concept: 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:
Extension points:
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.
Basic Flow:
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: Defining Include Relationships).
|