Use Cases
OOP
Software Engineering Major
Universidad de las Fuerzas Armadas-ESPE
Computer Science Department
Jorge Edison Lascano
Based on the Slides of Dr. Stephen Clyde
Actors
Actors are “things” outside of the system being build
that needs to interact with the system, e.g.
Users
Other software systems
Hardware (sensors, actuators, etc.)
Actors have goals with respect to the system
Actors are classified into sets, characterized by their
common properties
A set of actors is given a name, in singular form, that
communicates the set’s characteristic properties
A set of actors is typically represented by stick figures
Although all users are actors, not all actors are users
Use Cases
Use Cases are ideas that represent what the users need to
accomplish, independent of specific software features
They capture and document the user-visible functionality
of a system
Each use case communicates a discrete goal for the user
The name of a use case should communicate the goal in terms
that are free of design choices
Use cases are actually classifiers (sets)
The instance of a use case (the things in the set) are specific
scenarios that represent the realization of that goal
Use Cases
Good examples of use cases for a Student
Records Management System
Ensure that a student’s records reflects
courses taken and grades received in those
courses
Allow only authorized faculty and staff to
update student records
Ensure that students can obtain copies of their
own (and only their) records in a timely manner
System Interactions
Uses are not system interactions, which describe
how users (or actors) interact the system
System Interactions suggest how the system fulfills a
user goal
Example:
A teacher alters a course grade for a student by
selecting a semester
selecting a course
selecting a student
reviewing the previous grade
entering a new grade
confirming the change
Use Cases vs. System
Interactions
Use case and system interactions differ in terms of the perspective and
abstraction
Use cases help answer “What” and “Why” questions
System interactions help answer “How” questions (from a user’s
perspective)
Confusing system interactions with use cases or neglecting to identify use
cases
Can lead to failure to understanding why a system should must
certain features
result in lost opportunities for creativity
Later, we will model system interactions with Interaction Diagrams
Eventually, we will describe put all of the pieces together with
Collaborations
Use Case Diagrams
Use Case Diagrams provide a visual way to document user
goals and explore possible functionality
Four primary modeling components:
Actors Relationships
Use Cases Subjects
Record class grades Review Transcripts
Advise students
Teacher Authorized Student
Staff Worker
Relationships Between Actors
Actors are Classifiers, meaning they are sets of instances
Therefore, an actor (a set of instances) can be a subset of
another actor (another set of instances)
Generalization / Specialization
Student
Graduate
Student
Use Cases
Each use case represents something the
user needs to do with the system – a goal
A use cases is given a short name and
textual description (optional)
Use cases can be large or small, from a
conceptual perspective
Use cases can relate to each other via
dependencies, such as
<<extend>>
<<include>>
Generalization
Use-Case Relationships
Extends dependency: defines a use-case that is a
variation of another
The extended use case can stand on its own
The extending use case depends on the other, varying
the goal with respect to a specific extension point.
Alter Student Grade
Extension Points
Authorized
Elapsed time Staff Worker
<<extend>> Condition: {class was taken more than 1 year ago}
Extension point: Elapse Time
Alter student grade
for an old class
Use-Case Relationships
Includes Dependency: Defines a how one use case can
require the goal defined by another use case
Alter Student Grade
<<include>>
Record Grades for a
Teacher
Section
Use-Case Relations
Generalization: Defines one use case to be subset of another.
Alter Student Grade
Alter Student Grade for
Teacher
a Graduate Course
Extends vs. Includes vs.
Generalization
Extends, includes, and generalization may appear similar, but differ in
intent
Extend dependencies model variations or augmentations
Specializations are refinements of a general use cases – the scenarios
represented by the specialization are a subset of the scenarios
represented by the generalization
“Included” uses case (or sub-use cases), unlike specializations, can
represent different goals or processes
Include dependencies are a form of aggregation
The actors for a general use case are also actors for the use cases
that specialize it
Often there are no actors for “included” use cases
Use Case Diagrams
A use case diagram consists of actors, use
cases, and relations among use cases
A use case diagram can also include
notes
constraints
subjects (like the system) to show ownership of
the use cases
packages to group elements into larger
conceptual chunks
instances of use cases or actor, to show
specific examples
A Well-structured Use Case
Diagram
Focuses on communicating one aspect of
the system’s functionality
Contains only those use cases and actors
that are essential to understanding that
functionality
Provides detail consistent with its level of
abstraction
Is not so minimal that it fails to inform the
readers about important semantics
Hints for Finding Actors
IoT: Internet of Things
Who or what will use the main functionality of the
system?
Who or what will provide input from this system?
Who or what will use output from this system?
Who will need support from the system to do their work?
Are there any other software system with which this one
needs to interact
Are there any hardware devices used or controlled by
this system?
Hints for Modeling Actors
An actor can be a role that a user plays with respect
to the system
A single person may play different roles
A single actor may perform many use cases
A use case may be performed by many actors
Show external systems as actors only when they are
the ones who need a use case
Don’t worry too much about the details of an actor
or the relationship between actors and use cases
Hints for Finding Use Cases
Try listing actors first and then look at the activities
each needs to perform and then try to express the
goal that represent these activities
although this will uncover many valuable use cases, it
will not find them all
Try listing external events and then look at what the
system needs to do in response to each one.
This technique will find some additional use cases, but
not all
Be patience, allow the use cases to unfold
Don’t over do it – Use Case Diagram should be broad-
brush characterizations of user goals
Hints for Modeling Use Cases
Establish the context of a user goal by
identifying the actors
For each actor, consider the behavior that it
expects or requires the system to provide
Name these common behaviors as use cases
Factor common behavior into new use cases
Relate the use cases using the extend,
includes, and refines dependencies
Adorn uses cases with notes
More Hints
When drawing a use case diagram:
give the diagram a name that communicates its
purpose
lay out its elements to minimize crossing lines
organize its elements spatially so behaviors and
roles that are conceptually close are laid out close
together on the diagram
use notes and color as visual clues
Benefits of Use Cases
Use cases diagrams capture user-visible functions
Identifying actors help capture who needs the system
functionality
Relationships between use cases document
opportunities for reuse
Use cases provide a basis planning and scheduling
incremental development
Use cases can provide a basis for system testing
Questions
Who might be interested in reviewing or using use case
diagrams?
When in the development life cycle should we employ use
cases?
What do use cases have to do with object-orientation?
What level of use-case granularity is best?
How many use cases are enough?
Can other modeling activities help in discovering use
cases?
When in the development life cycle do we stop referring
to or refining the use cases?
What should the text description of use case contain?
WHAT IS NEXT…
Class Diagrams
