Generalization is a relationship between two use cases or two actors. Where A is a generalization of B, it means A describes more general behavior and B a more specific version of that behavior.
Examples for a travel agent sales system might be the use case for making a booking as a generalization of the use case for making a flight booking and a salesman actor being a generalization of a supervisor actor (since supervisors can also act as salesmen, but not vice versa).
Generalization is analogous to class inheritance within OO programming.
![]() | Note |
---|---|
It is easy to confuse extends relationships between use cases with generalization. However extends is about augmenting a use case's behavior at a specific point. Generalization is about specializing the behavior throughout the use case. |
Within the UML metamodel, Generalization
is a
sub-class of Relationship
.
Generalization is represented as an arrow with white filled head from the specialized use case or actor to the generalized use case or actor (see Figure 16.1, “Possible artifacts on a use case diagram.”).
The details tabs that are active for associations are as follows.
ToDoItem
Standard tab.
Properties
See Section 16.8.2, “Generalization Property Toolbar” and Section 16.8.3, “Property Fields For Generalization” below.
Documentation
Standard tab. See Section 12.5, “Documentation Tab”.
Style
Standard tab
![]() | Note |
---|---|
The values for the bounds of the generalization appear to have no meaning. Changing them has no effect on the diagram. This is sensible behavior, given the generalization is tied to a particular actor and use case. |
Source
Standard tab. You would not expect to generate any code for an association end so this is empty.
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,
Generalization
has the following standard
tagged values defined.
derived
(from the
superclass, ModelElement
). Values
true
, meaning the generalization is
redundant—it can be formally derived from other
elements, or false
meaning it
cannot.
![]() | Note |
---|---|
Derived generalizations still have their value in analysis to introduce useful names or concepts, and in design to avoid re-computation. |
Go
up
Navigate up through the package structure of the model. For a generalization this will be the package containing the generalization.
Delete
This deletes the selected generalization from the model.
![]() | Warning |
---|---|
This is a deletion from the model
not just the diagram. To delete a
generalization from the diagram, but keep it within the model,
use the main menu |
Name
Text box. The name of the generalization.
![]() | Tip |
---|---|
It is quite common to leave generalizations unnamed in use case analysis. |
![]() | Note |
---|---|
ArgoUML does not enforce any naming convention for associations. |
![]() | Note |
---|---|
There is no representation of the name of a generalization on the diagram. |
Stereotype
Drop down selector.
Generalization is provided by
default with the UML standard stereotype
implementation
.
The stereotype is shown between
« and » above or across the generalization.
![]() | Tip |
---|---|
Stereotyping generalization does not have great value on a use case diagram. The standard stereotype is about implementation, and suited to the use of generalization on class diagrams. |
Navigate Stereotype
icon. If a
stereotype has been selected, this will navigate to the
stereotype property panel (see Section 15.4, “Stereotype”).
Discriminator
Text box. The name of a discriminator for the specialization. UML 1.3 allows grouping of specializations into a number of sets, on the basis of this value.
![]() | Tip |
---|---|
The empty string “” is a valid entry (and the default) for this field. The discriminator is only of practical use in cases of multiple inheritance. A (class diagram) example is shown in Figure 16.2, “Example use of a discriminator with generalization”. Here each type of user should inherit from two sorts of user. One distinguishing between local or remote user (which can be identified by one discriminator) and one indicating their function as a user (identified by a different discriminator). There is little point in using this within a use case diagram. |
Namespace
Text box. Records the namespace for the generalization. This is the package hierarchy.
Parent
Text box.
Shows the use case or actor that is the
parent in this relationship,
i.e. the more general end of the relationship.
Button 1 Double Click
on this entry will navigate to that use case or
actor. Button 2 click will give a pop up menu, with a single
entry, Open
which will also navigate to that
use case or actor.
Child
Text box.
Shows the use case or actor that is the
child in this relationship,
i.e. the more specific end of the relationship.
Button 1 Double Click
on this entry will navigate to that use case or
actor. Button 2 click will give a pop up menu, with a single
entry, Open
which will also navigate to that
use case or actor.
Powertype
Drop down selector providing access to all standard UML types provided by ArgoUML and all new classes created within the current model.
This is the type of the child entity of the generalization.
![]() | Tip |
---|---|
This can be ignored for use case analysis. The only sensible value to put in would be the child use case type (as a classifier, this appears in the drop down list. |