Guidelines: Extend-Relationship

Artifacts > Requirements Artifact Set > Use-Case Model... > Use-Case Model > Guidelines > Extend-Relationship

«extend»

Extend-Relationship

An extend-relationship is a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension use case can be inserted into the behavior defined for the base use case. It is implicitly inserted in the sense that the extension is not shown in the base use case.

Explanation

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 Guidelines: 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 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.

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:

To be able to add a third party to a call (Place Conference Call).
To allow the receiving party to see the identity of the caller (Show Caller Identity).

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 Guidelines: 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.

Executing the Extension

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 Guidelines: 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 segment.

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 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.

Example of Use

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 Guidelines: 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 Guidelines: Include-Relationship).

Rational Unified Process