Extend is a relationship between two use cases. Where A extends B, it means A describes some additional behavior that is executed conditionally (under exceptional circumstances) at some point during the normal behavior of B.
In some respects extend is like generalization. However the key difference is that the extended use case defines extension points (see Section 17.4, “ Extension Point ”), which are the only places where its behavior may be extended. The extending use case must define at which of these extension points it adds behavior.
This makes the use of extend more tightly controlled than general extension, and it is thus preferred wherever possible.
Examples for a travel agent sales system might be the use case for paying for a ticket, which has an extension point in the specification of the payment. Extending use cases may then extend at this point to pay by cash, credit card etc.
Within the UML metamodel, Extend is a
sub-class of Relationship.
An extend relationship is represented as a dotted link
with an open arrow head and a label
«extend». If a condition is defined, it is shown
under the «extend» label (see
Figure 17.1, “
Typical model elements on a use case diagram.
”).
The details tabs that are active for extend relationships are as follows.
![[Note]](images/note.png) | Note |
|---|---|
There is no source tab, since there is no source code that could be generated for an extend relationship. |
ToDoItemStandard tab.
PropertiesSee Section 17.9.2, “ Extend Property Toolbar ” and Section 17.9.3, “ Property Fields For Extend ” below.
DocumentationStandard tab. See Section 13.4, “ Documentation Tab ”.
PresentationStandard tab
Note The values in the "bounds" field of the extend are not editable, since they are determined by the properties of the endpoints of the line.
StereotypeStandard tab.
Tagged ValuesStandard tab. In the UML metamodel,
Extendhas the following standard tagged values defined.derived(from the superclass,ModelElement). Valuestrue, meaning the extend relationship is redundant -it can be formally derived from other elements, orfalsemeaning it cannot.Note Derived extend relationships could have their value in analysis to introduce useful names or concepts.
Go upNavigate up through the package structure of the model. For a extend this will be the package containing the extend.
New extension pointThis creates a new use case extension point within the namespace of the current extend relationship, with the current extend relationship as its first extending relationship.
![[Tip]](images/tip.png)
Tip While it is perfectly valid to create extension points from an extend relationship, the created extension point will have no associated use case (it can subsequently be set up).
It would be more usual to instead create the extension point within a use case and subsequently link to it from an extend relationship (see Section 17.9.3, “ Property Fields For Extend ” below).
New StereotypeThis creates a new Stereotype (see Section 16.6, “ Stereotype ”) for the selected extent relationship, navigating immediately to the properties tab for that stereotype.
DeleteThis deletes the selected extend relationship from the model.
![[Warning]](images/warning.png)
Warning This is a deletion from the model not just the diagram. To delete a extend from the diagram, but keep it within the model, use the main menu
Remove From Diagram(or press the Delete key).
NameText box. The name of the extend relationship.
Tip It is quite common to leave extends unnamed in use case analysis.
Note ArgoUML does not enforce any naming convention for extend relationships.
NamespaceText box. Records the namespace for the extend relationship. This is the package hierarchy.
Button 1 Double Click on the entry will navigate to the package defining this namespace (or the model for the top level namespace).
Base Use CaseText box. Shows the use case that is being extended by this extend relationship. Button 1 double click on this entry will navigate to the base use case.
ExtensionText box. Show the use case that is doing the extending through this extend relationship. Button 1 double click on this entry will navigate to the extension use case.
Extension PointsText box. Lists the extension points of the base use case where the extension will be applied if the condition holds.
Note If the condition is fulfilled, the sequence obeyed by the use-case instance is extended to include the sequence of the extending use case. The different parts of the extending use case are inserted at the locations defined by the sequence of extension points in the relationship -- one part at each referenced extension point. Note that the condition is only evaluated once: at the first referenced extension point, and if it is fulfilled all of the extending use case is inserted in the original sequence.
Hence, the sequence of the extension points is irrelevant, except for the position of the first one; since that one determines where the condition is evaluated.
Where an extension point has been created, button 1 double click will navigate to that relationship. Button 2 gives a pop up menu with the following entries.
Add. The “Ad/Remove ExtensionPoints” window opens. In this window it is possible to build a list of extension points.New. Add a new extension point in the list and navigate to it. The current extend relationship is added as the first in list of extending relationships of the new extension point.Move Up. Only available where there are two or more extension points listed, and the extension point selected is not at the top. It moves the extension point up one position.Move Down. Only available where there are two or more extension points listed, and the extension point selected is not at the bottom. It moves the extension point down one position.
ConditionText area. Multi-line textual description of any condition attached to the extend relationship.
The text entered here is shown on the diagram.