17.3. Use Case

A use case represents a complete meaningful “chunk” of activity by the system in relation to its external users (actors), human or machine. It represents the primary route through which requirements are captured for the system under construction

Within the UML metamodel, use case is a sub-class of classifier.

The use case icon is an oval (see Figure 17.1, “Possible artifacts on a use case diagram.”). It may be split in two, with the lower compartment showing extension points


By default ArgoUML does not show the extension point compartment. It may be revealed by the context sensitive Show menu (using button??2 click), or from the Presentation tab.

17.3.1. Use Case Details Tabs

The details tabs that are active for use cases are as follows.


Standard tab.


See Section 17.3.2, “Use Case Property Toolbar” and Section 17.3.3, “Property Fields For Use Case” below.


Standard tab. See Section 13.4, “Documentation Tab”.


Standard tab. The Fill color is used for the use case oval.

The Display: Extension Points check box is used to control whether an extension point compartment is displayed.


Standard tab. It would not be usual to provide any code for a use case, since it is primarily a vehicle for capturing requirements about the system under construction, not creating the solution.

Tagged Values

Standard tab. In the UML metamodel, UseCase has the following standard tagged values defined.

  • persistence (from the superclass, Classifier). Values transitory, indicating state is destroyed when an instance is destroyed or persistent, marking state is preserved when an instance is destroyed.


    In general the instantiation of use cases is not a major aspect of any design method (they are mostly concerned with requirements capture. For most OOA&D methodologies, this tag can safely be ignored.

  • semantics (from the superclass, Classifier). The value is a specification of the semantics of the use case.

  • derived (from the superclass, ModelElement). Values true, meaning the use case is redundant???it can be formally derived from other elements, or false meaning it cannot.


    Derived use cases still have their value in analysis to introduce useful names or concepts.


Standard tab for a Classifier.

17.3.2. Use Case Property Toolbar

Go up

Navigate up through the package structure of the model.

New use case

This creates a new use case within the model, (but not within the diagram), and shows immediately the properties tab for that use case.


This method of creating a new use case can be confusing. It is much better to create a new use case on the diagram of your choice.

New extension point

This creates a new use extension point within the namespace of the current use case, with the current use case as its associated use case, navigating immediately to the properties tab for that extension point.


This deletes the selected use case from the model.


This is a deletion from the model not just the diagram. To delete a use case from the diagram, but keep it within the model, use the main menu Remove From Diagram (or press the Delete key).

17.3.3. Property Fields For Use Case


Text box. The name of the use case. Since a use case is a classifier, it would be conventional to Capitalize the first letter (and initial letters of any component words), e.g. RemoteSensor. The name is shown inside the oval representation of the use case on the diagram.


ArgoUML does not enforce any naming convention for use cases


Drop down selector. Use case is provided by default with the UML standard stereotypes ( metaclass, powertype, process, thread, utility) for classifiers. Stereotyping can be useful when creating use cases in the problem domain (requirements capture) and solution domain (analysis), but none of the predefined stereotypes are well suited to this.

Navigate Stereotype

icon. If a stereotype has been selected, this will navigate to the stereotype property panel (see Section 16.5, “Stereotype”).


Text box. Records the namespace for the use case. This is the package hierarchy.


Check box, with entries Abstract Leaf and Root.

  • Abstract is used to declare that this actor cannot be instantiated, but must always be specialized. .

  • Leaf indicates that this use case can have no further children, while Root indicates it is a top level use case with no parent.

Extension Points

Text box. If this use case is, or can be extended, this field lists the extension points for the use case.


Extension points are listed by their location point rather than their name.

Where an extension point has been created (see below), button??1 Double Click will navigate to that relationship. Button??2 gives a pop up menu with one entry.

  • New. Add a new extension point and navigate to it, making this use case the owning use case of the extension point.


Text area. Lists use cases which are generalizations of this one. Will be set whenever a generalization is created on the from this Use Case. Button??1 Double Click on a generalization will navigate to that generalization.


Text box. Lists any specialized use case (i.e. for which this use case is a generalization.

Button??1 double click navigates to the generalization and opens its property tab.


Text box. Lists any class that is extended by this use case.

Where an extends relationship has been created, button??1 double click will navigate to that relationship.


Text box. Lists any use case that this use case includes.

Where an include relationship has been created, button??1 Double Click will navigate to that relationship.

Association Ends

Text box. Lists any association ends (see Section 18.11, “Association”) of associations connected to this use case.

Button??1 double click navigates to the selected entry.