1. M.M. Pickard, PhD
A Primer on Use Cases (Reference: UML Superstructure Specification, v2.1.1)

2. Overview Use Case Diagrams: Key Concepts:
Used to specify required usages of a system.
Used to capture requirements.
Key Concepts:
Actors.
Use Cases.
Subject.

3. Key Concepts Subject: Actors: The system to which the use cases apply.
Users.
Any other systems that may interact with the subject.
Entities outside the subject system.

4. Key Concepts
Use Case:
Specification of required behavior of the subject.
A set of actions which yields an observable result that is usually valuable to actor(s) or stakeholder(s) of a system.
Strictly speaking, “use case” refers to a use case type.
An instance of a use case is an occurrence of the behavior shown in the use case type.

5. Actor
Specifies a role played by a user or any other external entity that interacts with the subject system.
The role may be played by humans, external hardware, and so on.
A single external entity may play multiple roles (shown as multiple actors).
Likewise, a given actor may represent multiple physical instances.

6. Actor in the UML Model Must have a name. Can have several forms:
“Stick man” icon (name above or below).
Class rectangle with keyword <<actor>>.
Other icons to denote non-human actors.
Example: A computer icon.

7. Use Case Modeling Shown as an elipse (oval).
May be extended to show additional behavior that could be added to the base use case.
May show included behavior as additional use case(s).

8. Use Case Modeling (extend relationship)
Use case may be extended.
The behavior of a use case may be extended by the behavior of another use case.
The extended use case is defined independently and is meaningful by itself.
However, the extending use case defines behavior that may not be independently meaningful.
Intended to show additional behavior that could be added to the base use case.

9. Use Case Modeling (extend relationship)
An extend relationship is shown by a dashed arrow with an open arrowhead from the extending use case.
The arrow is labeled with the keyword <<extend>>.
Option: The condition of the relationship may be shown in a note attached to it.

10. Use Case Modeling (include relationship)
Use case may include another use case.
The behavior of the included use case is inserted into the behavior of the original use case.
The including use case may only depend on the result of the included use case.
The included use case is not optional; it is always required in order for the including use case to execute correctly.
The include relationship is used when there is common behavior of two or more use cases.
The common part is extracted to a separate use case.

11. Use Case Modeling (include relationship)
An include relationship is shown by a dashed arrow with an open arrowhead from the base use case to the included use case.
The arrow is labeled with the keyword <<include>>.
The include relationship allows hierarchical composition of use cases, as well as reuse of use cases.

12. Use Case Summary
The subject of a use case could be a physical system or any other element that has behavior (e.g., component, subsystem, or class).
Each use case specifies a unit of useful functionality provided by the subject to its users.

13. Use Case Summary A use case can be used to specify both
external requirements of a subject;
and functionality offered by a subject.
Descriptions of use case behavior
Interactions
Activities
State machines
Pre- and post-conditions
Natural language text