Previous UML Classes Table of Contents UML Packages Next

16.3.6 UseCase


   A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.


   • BehavioredClassifier (from BasicBehaviors , Communications ) on page 451


   A UseCase is a kind of behaviored classifier that represents a declaration of an offered behavior. Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure. These behaviors, involving interactions between the actor and the subject, may result in changes to the state of the subject and communications with its environment. A use case can include possible variations of its basic behavior, including exceptional behavior and error handling.

   The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. Each use case specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the use case can be initiated again or in an error state.

   Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

   The behavior of a use case can be described by a specification that is some kind of Behavior (through its ownedBehavior relationship), such as interactions, activities, and state machines, or by pre-conditions and post-conditions as well as by natural language text where appropriate. It may also be described indirectly through a Collaboration that uses the use case and its actors as the classifiers that type its parts. Which of these techniques to use depends on the nature of the use case behavior as well as on the intended reader. These descriptions can be combined. An example of a use case with an associated state machine description is shown in Figure 16.6.


   No additional attributes


subject : Classifier[*] References the subjects to which this use case applies. The subject or its parts realize all the use cases that apply to this subject. Use cases need not be attached to any specific subject, however. The subject may, but need not, own the use cases that apply to it.

Issue 9122 - remove subsetting of Classifier::feature for ‘include’ and ‘extend’


   [1] A UseCase must have a name. -> notEmpty ()

Issue 8468 - identify that the OCL is unavailable for the two constraints

   [2] UseCases can only be involved in binary Associations. (no OCL available)

   [3] UseCases cannot have Associations to UseCases specifying the same subject. (no OCL available)

   [4] A use case cannot include use cases that directly or indirectly include it.

   not self.allInclude dUseCases ()->includes(self)

   Additional Operations

   [1] The query allInclude dUseCases () returns the transitive closure of all use cases (directly or indirectly) included by this use case.

Issue 8468 - add missing closing parenthesis

   UseCase::allInclude dUseCases () : Set(UseCase)allInclude dUseCases = self.include->union(self.include->collect(in | in.allInclude dUseCases ()))


   An execution of a use case is an occurrence of emergent behavior.

   Every instance of a classifier realizing a use case must behave in the manner described by the use case.

   Use cases may have associated actors, which describes how an instance of the classifier realizing the use case and a user playing one of the roles of the actor interact. Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject. It is not possible to state anything about the internal behavior of the actor apart from its communications with the subject.

   When a use case has an association to an actor with a multiplicity that is greater than one at the actor end, it means that more than one actor instance is involved in initiating the use case. The manner in which multiple actors participate in the use case depends on the specific situation on hand and is not defined in this specification. For instance, a particular use case might require simultaneous (concurrent) action by two separate actors (e.g., in launching a nuclear missile) or it might require complementary and successive actions by the actors (e.g., one actor starting something and the other one stopping it).


   A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier . For example, the use cases shown in Figure 16.5 on page 622 apply to the ATMsystem classifier but are owned by various packages as shown in Figure 16.7.

Figure 16.5 - Example of the use cases and actors for an ATM system

   Figure 16.6 - Example of a use case with an associated state machine behavior

   Figure 16.7 - Example of use cases owned by various packages

   Extension points may be listed in a compartment of the use case with the heading extension points. The description of the locations of the extension point is given in a suitable form, usually as ordinary text, but can also be given in other forms, such as the name of a state in a state machine, an activity in an activity diagram, a precondition, or a postcondition.

   Use cases may have other associations and dependencies to other classifiers (e.g., to denote input/output, events, and behaviors).

   The detailed behavior defined by a use case is notated according to the chosen description technique, in a separate diagram or textual document. Operations and attributes are shown in a compartment within the use case.

    Use cases and actors may represent roles in collaborations as indicated in Figure 16.8.

Figure 16.8 - Example of a use case for withdrawal and transfer of funds

   : Bank

   Presentation Options

   A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper-righthand corner of the rectangle with optional separate list compartments for its features. This rendering is more suitable when there are a large number of extension points.

Figure 16.9 - Example of the classifier based notation for a use case


   See Figure 16.3 through Figure 16.9.


   The purpose of use cases is to identify the required functionality of a system.

   Changes from previous UML

   The relationship between a use case and its subject has been made explicit. Also, it is now possible for use cases to be owned by classifiers in general and not just packages.