SWEN 5135 Configuration Management
«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. |
Topics
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:
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.
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.
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.
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).
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Artifacts >
Requirements Artifact Set >
Use-Case Model... >
Use-Case Model >
Guidelines >
