*Generalizations
•
DirectedRelationship (from Kernel ) on page 62
Issue 8465 - add NamedElement as parent
•
NamedElement (from Kernel , Dependencies ) on page 99
Description
This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary)
use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however,
that the extended use case is defined independently of the extending use case and is meaningful independently of the extending
use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself.
Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use
case under specific conditions.
Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be
extended.
It is a kind of DirectedRelationship , such that the source is the extending use case and the destination is the extended use
case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The extend relationship
itself is owned by the extending use case.
Attributes
No additional attributes
Associations
• extendedCase : UseCase [1] References the use case that is being extended. (Subsets DirectedRelationship .target)
• extension : UseCase [1] References the use case that represents the extension and owns the extend relationship. (Subsets DirectedRelationship .source)
• condition : Constraint [0..1] References the condition that must hold when the first extension point is reached for the extension
to take place. If no constraint is associated with the extend relationship, the extension is unconditional. (Subsets Element.ownedElement)
• extensionLocation: ExtensionPoint [1..*] An ordered list of extension points belonging to the extended use case, specifying
where the respective behavioral fragments of the extending use case are to be inserted. The first fragment in the extending
use case is associated with the first extension point in the list, the second fragment with the second point, and so on. (Note
that, in most practical cases, the extending use case has just a single behavior fragment, so that the list of extension points
is trivial.)
Constraints
[1] The extension points referenced by the extend relationship must belong to the use case that is being extended.
extensionLocation->forAll (xp | extendedCase.extensionPoint->includes(xp))
Semantics
The concept of an extension location is intentionally left underspecified because use cases are typically specified in various
idiosyncratic formats such as natural language, tables, trees, etc. Therefore, it is not easy to capture its structure accurately
or generally by a formal model. The intuition behind the notion of extension location is best explained through the example
of a textually described use case: Usually, a use case with extension points consists of a set of finer-grained behavioral
fragment descriptions, which are most often executed in sequence. This segmented structuring of the use case text allows the
original behavioral description to be extended by merging in supplementary behavioral fragment descriptions at the appropriate
insertion points between the original fragments (extension points). Thus, an extending use case typically consists of one
or more behavior fragment descriptions that are to be inserted into the appropriate spots of the extended use case. An extension
location, therefore, is a specification of all the various (extension) points in a use case where supplementary behavioral
increments can be merged.
If the condition of the extension is true at the time the first extension point is reached during the execution of the extended
use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the condition
is false, the extension does not occur. The individual fragments are executed as the corresponding extension points of the
extending use case are reached. Once a given fragment is completed, execution continues with the behavior of the extended
use case following the extension point. Note that even though there are multiple use cases involved, there is just a single
behavior execution.
Notation
An extend relationship between use cases is shown by a dashed arrow with an open arrowhead from the use case providing the
extension to the base use case. The arrow is labeled with the keyword «extend». The condition of the relationship as well
as the references to the extension points are optionally shown in a Note attached to the corresponding
extend relationship.(See Figure 16.3.)
*Examples
Perform ATM Transaction On-Line Help
Figure 16.3 - Example of an extend relationship between use cases
In the use case diagram above, the use case Perform ATM Transaction has an extension point Selection. This use case is extended
via that extension point by the use case On-Line Help whenever execution of the Perform ATM Transaction use case occurrence
is at the location referenced by the Selection extension point and the customer selects the HELP key. Note that the Perform
ATM Transaction use case is defined independently of the On-Line Help use case.
Rationale
This relationship is intended to be used when there is some additional behavior that should be added, possibly conditionally,
to the behavior defined in another use case (which is meaningful independently of the extending use case).
Changes from previous UML
The notation for conditions has been changed such that the condition and the referenced extension points may now be included
in a Note attached to the extend relationship, instead of merely being a textual comment that is located in the vicinity of
the relationship.