Use Cases
Classifier
Generalizable
Element
isRoot
Model
Element
Namespace
name
visibility
isSpecification
Constraint
Body
CS/SWE 421
Introduction to Software Engineering
Dan Fleck
(Slides adapted from Dr. Stephen Clyde with permission)
Coming up: Introduction
1
Introduction

Use Case: “... a typical interaction between
a user and a computer system”, Booch
– Here, “user” is anything that needs or invokes the
functionality of the system
– “Computer system” is the system being modeled



Use cases can capture and document the
user-visible functionality of a system
Use cases capture how the system will
benefit the user
Each use case achieves a discrete goal for
the user
2
Coming up: Example Use Case Diagram
Example Use Case Diagram
3
Coming up: Goals
Goals

Use cases help everyone come to a
common understanding of what the system
should do
– Developers
– End-users
– Domain Experts


Use-cases are a communication tool for the
design (not the implementation)
Use cases represent a functional
requirement of your system (as a whole)
4
Coming up: User Goals
User Goals


User Goals are statements that represent
what the users need to accomplish,
independent of specific software features
Examples of user goals 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
5
Coming up: System Interactions
System Interactions



Represent expected interacts between users and
the computer-based system
Suggest how the system fulfills a user goal
Examples:
– 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
– A process for an administrator to create a new
user
– A process for granting a user access rights
Coming up: User Goals vs. System Interactions
6
User Goals vs. System
Interactions


In some cases, system interactions and
user goals can be very similar
However, confusing system interactions
with user goals or neglecting to identify
user goals can
– fail to bring out and document the reasons why a
system should must certain features
– result in lost opportunities for creativity
7
Coming up: User Goals vs. System Interactions
User Goals vs. System
Interactions




User goals help answer “What” and “Why”
questions
System interactions help answer “How”
questions (from a user’s perspective)
We will model user goals with Uses Cases
Later, we will model system interactions
with interaction diagrams or activity
diagrams
8
Coming up: Use Case Diagrams
Use Case Diagrams


Use Case Diagrams provide a visual way to
document user goals and explore possible
functionality
Three primary modeling components:
– Actors
– Use Cases
– Relationships between
use cases
Record class grades
Review Transcripts
Teacher
Authorized
Staff Worker
Coming up: Actors
Student
9
Actors




Actors are things outside the system that
need to interact with the system
Actors carry out use cases
Actors are represented as stick figures
Although users are actors, not all actors
are users
– Actors can be external software systems
– External hardware (sensors, actuators, etc.)
– Actors can be people that need the functionality of
the system, but may not be the ones who actually
invoke the software commands
10
Coming up: Hints for Finding Actors
Hints for Finding Actors






Who or what will use the main functionality of the
system?
Who or what will provide input to 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 systems with which
this one needs to interact
Are there any hardware devices used or controlled
by this system?
11
Coming up: Hints for Modeling Actors
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
12
Coming up: Relationships Between Actors
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
Coming up: Use Cases
13
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
– <<extends>>
– <<includes>>
– Generalization or <<refines>> (“is a”)
14
Coming up: Use Cases
Use Cases
Includes
Extends
Generalization
After a while you realize extends and generalization are
not too different. Just know generalization and
includes… forget about extends
15
Coming up: Use-Case Relationships
Use-Case Relationships

Includes Dependency: Defines how one
use case can invoke behavior defined by
another use case
Alter Student Grade
<<includes>>
Teacher
Record Grades for a
Section
16
Coming up: Use-Case Relationships
Use-Case Relationships

Extends dependency: defines a use-case
that is a variation of another, usually for
handling an abnormal situation
Alter Student Grade
<<extends>>
Alter student grade for
a class taken more
than a year ago
Authorized
Staff Worker
17
Coming up: Use-Case Relations
Use-Case Relations

Generalization: Defines one use case as a
generalization of another.
Alter Student Grade
Teacher
Alter Student Grade for
a Graduate Course
18
Coming up: Hints for Finding 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 patient, allow the use cases to unfold
Don’t over do it – Use Case Diagram should be
broad-brush characterizations of user goals
19
Coming up: Hints for Modeling Use Cases
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
20
Coming up: Use-Case Relations
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
23
Coming up: A Well-structured Use Case Diagram
A Well-structured Use Case
Diagram





Describes the flow of events clearly enough for an
outsider to understand it
Factors in common behavior by pulling such behaviors
from other use cases it includes
Factors variants out by having other use cases
“extend” itself
Provides detail consistent with its level of abstraction
Is not so minimal that it misinform the reader about
important semantics
24
Coming up: Benefits of Use Cases
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
25
Coming up: Use cases for CS421
Use cases for CS421
Use extend,
include,
generalization/spe
cialization where
appropriate
Coming up: Use cases for CS421
Show system
boundary
(Warning:
skip this if not
supported by
the tool – like
Show Actors
Netbeans!
outside
boundary
Typically one
diagram for
26
your project
is sufficient
Use cases for CS421
Show system
boundary
(Warning: skip this
if not supported by
the tool – like
Netbeans!)
27
Coming up: Use cases for CS421
Use cases for CS421

For each use-case (oval) in your diagram
include the use-description text described in
the slide for Chapter 7, titled:
 Use
Case Description
–about slide #18
28
Coming up: Questions
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?
29
End of presentation