Include is a relationship between two use cases. Where A includes B, it means B described behavior that is to be included in the description of the behavior of A at some point (defined internally by A).
Examples for a travel agent sales system might be the use case for booking travel, which includes use cases for booking flights and taking payment.
Within the UML metamodel, Include
is a
sub-class of Relationship
.
An include relationship is represented as a dotted link with an open
arrow head and a label «include»
(see
Figure 16.1, “Possible artifacts on a use case diagram.”).
The details tabs that are active for include relationships are as follows.
![]() | Note |
---|---|
There is no source tab, since there is no source code that could be generated for an include relationship. |
ToDoItem
Standard tab.
Properties
See Section 16.10.2, “Include Property Toolbar” and Section 16.10.3, “Property Fields For Include” below.
Documentation
Standard tab. See Section 12.5, “Documentation Tab”.
Style
Standard tab
![]() | Note |
---|---|
The values for the bounds of the include relationships appear to have no meaning. Changing them has no effect on the diagram. This is sensible behavior, given the include is tied to a particular pair of use cases. |
Constraints
Standard tab. ArgoUML only supports constraints on Classes and Features (Attributes, Operations, Receptions, and Methods), so this tab is grayed out.
Tagged Values
Standard tab. In the UML metamodel,
Include
has the following standard
tagged values defined.
derived
(from the
superclass, ModelElement
). Values
true
, meaning the include relationship is
redundant—it can be formally derived from other
elements, or false
meaning it
cannot.
![]() | Note |
---|---|
Derived include relationships could have their value in analysis to introduce useful names or concepts. |
Go
up
Navigate up through the package structure of the model. For a include this will be the package containing the include.
Delete
This deletes the selected include relationship from the model.
![]() | Warning |
---|---|
This is a deletion from the model
not just the diagram. To delete a
include from the diagram, but keep it within the model,
use the main menu |
Name
Text box. The name of the include relationship.
![]() | Tip |
---|---|
It is quite common to leave include relationships unnamed in use case analysis. |
![]() | Note |
---|---|
ArgoUML does not enforce any naming convention for include relationships. |
Stereotype
Drop down selector. ArgoUML does not provide any stereotypes for include relationships.
![]() | Tip |
---|---|
Stereotyping does not have great value on an include relationship. |
![]() | Note |
---|---|
There is no representation of the stereotype of an include relationship on the diagram. |
Navigate Stereotype
icon. If a
stereotype has been selected, this will navigate to the
stereotype property panel (see Section 15.4, “Stereotype”).
Namespace
Text box. Records the namespace for the include. This is the package hierarchy.
Button 1 click on the entry will navigate to the package defining this namespace (or the model for the top level namespace).
Base
Drop down selector. Records the use case that is doing the including in this include relationship. Button 1 click on this entry will give a drop down menu of all available use cases (and an empty entry) which may be selected by button 1 click.
![]() | Caution |
---|---|
In the current version of ArgoUML if you change the base use case on an include relationship that is already shown on a diagram, then it will NOT be redrawn. Currently the only way to effect a redraw is to remove the use cases at each end from the diagram and then add them back from the explorer. |
Included Use Case
Drop down selector. Records the use case that is being included by this include relationship. Button 1 click on this entry will give a drop down menu of all available use cases (and an empty entry) which may be selected by button 1 click.
![]() | Caution |
---|---|
In the current version of ArgoUML if you change the addition use case on an include relationship that is already shown on a diagram, then it will NOT be redrawn. Currently the only way to effect a redraw is to remove the use cases at each end from the diagram and then add them back from the explorer. |