*Generalizations
•
BehavioredClassifier (from BasicBehaviors , Communications ) on page 451
Description
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.
Attributes
No additional attributes
Associations |
|||||
| • | 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’
• include : Include [*] References the Include relationships owned by this use case. (Subsets Namespace .ownedMember)
• extend : Extend[*] References the Extend relationships owned by this use case. (Subsets and Namespace .ownedMember)
• extensionPoint: ExtensionPoint [*] References the ExtensionPoint s owned by the use case. (Subsets Namespace .ownedMember)
Constraints
[1] A UseCase must have a name.
self.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 ()))
Semantics
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).
Notation
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.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.
: 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.
