2
Objectives
Identify and write use cases.
Relate use cases to user goals and elementary
business processes.
Use the brief, casual, and fully dressed formats, in
an essential style.
Relate use case work to iterative development.
3
Use case = “Story”
Writing use cases—stories of using a system—is
an excellent technique to understand and
describe requirements.
4
What is use case?
Use Cases are to discover and record functional
requirements.
A use case captures a contract between the
stakeholders of a system about its behavior
ilftraesbdou .
The use case describes the system’s behavior
under various conditions as it responds to a
request from one of the stakeholders, called the
primary actor
p r i m ar y act o r
.
A Use Case is a collection of related success and
failure scenarios that describe actors using a
system to fulfill (or support) a goal.
A scenario is a specific sequence of actions and
interactions between actors and the system under
discussion.
5
Major Concepts in Use-Case Modeling
An actor represents anything that interacts with
the system.
A use case is a sequence of actions a system
performs that yields an observable result of
value to a particular actor.
Use Case
Actor
6
Use Case
The name of a Use Case should be the main goal
of the Use Case.
Use cases are fundamentally a text form
,
although they can be written using graphic form.
In UML use-case diagrams, a use case is
rendered as an ellipse.
Process Loan
7
Use Cases
Use cases document system behavior from point
of view of the user
A user
means anything that is
external to the system under development and
which interacts with the system
8
Use Cases and Functional Requirements
Use cases are requirements (not all requirements).
Primarily they are functional requirements that
indicate what the system will do. Use cases define
a promise or contract of how a system will behave.
Use cases provide a structured way to help with
requirements capture
Identify the actors
Find out what actors need from the system
Find out any other interactions the actors expect
to have with the system
9
Use Cases Basics
An actor
is something with behavior, such as a person
(identified by role
), computer system, or organization; for
example, a cashier
The actor
initiates an interaction with the system to accomplish
some goal. The system responds, protecting the interests of all
the stakeholders.
A scenario
is a specific sequence of actions and interactions
between actors and the system under discussion. It is one
particular story of using a system, or one path through the use
case;
A use case
is a collection of related success and failure
scenarios that describe actors using a system to support a goal
10
Example of UC
Example of POS Use Case – Handle Returns
Handle Returns
Main Success Scenario:
M a i n S u c e s S c e n a r i o :
A customer arrives at a checkout with
items to return. The cashier uses the POS system to record each
returned item ...
Alternate Scenarios:
A l t e r n a t e S c e n a r i o s :
If the credit authorization is reject, inform the customer and ask for an
alternate payment method.
If the item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is corrupted). If
the system detects failure to communicate with the external tax
calculator system, ...
11
Actors
An actor is anything with behavior, including the
system under discussion itself when it calls upon
the services of other systems.
Primary and supporting actors will appear in the
action steps of the use case text.
Actors are not only roles played by people, but
organizations, software, and machines.
12
Type of Actors
Primary actor
irayoPm has user goals fulfilled through
using services of the system.
For example, the cashier.
Supporting actor
itragnopuSct
provides a service (for example,
information) to the system. Often a computer
system, but could be an organization or person.
For example, the automated payment authorization
service
Offstage actor
fraesoO has an interest in the behavior of
the use case, but is not primary or supporting
For example, a government tax agency.
13
UC Names
Every use case must have a name that distinguishes it
from other use cases.
Rules of naming Use Case:
Verb + Noun
Place Order
leradPOc
Validate User
14
Goals and Brief Format Use Cases
Customers and end users have goals
(needs/requirements) and want
computer systems to help meet them. The goals are primarily the
starting point of finding out use case
Brief format Use cases are a mechanism to help keep it simple and
understandable for all stakeholders.
Informally, they are stories of using a system to meet goals.
Here is an example brief format use case:
Process Sale:
A customer arrives at a checkout with items to purchase.
The cashier uses the POS system to record each purchased item. The
system presents a running total and line-item details. The customer
enters payment information, which the system validates and records.
The system updates inventory. The customer receives a receipt from
the system and then leaves with the items.
15
Notation
Use cases are text documents, not diagrams
, and use-case modeling is
primarily an act of writing text, not drawing. However, the UML defines a use
case diagram to illustrate the names of use cases and actors, and their
relationships.
A Video Clerk who wants to rent a video to a customer
will communicate with the use case Rent A Video.
Rent A Video
Video Clerk
Actor:
human user
Actor:
external hardware, machine or system
Use Case
Association:
c ommunication between Actors and Use Cases
Association:
e xtends or u ses relationships between Use Cases
inheritance relationships between Actors.
Symbol Meaning / Usage
Use-case model: drawing system sequence
diagrams
2
Objectives
Identify system events.
Create system sequence diagrams for use cases.
3
Moving on to Iteration 1
What have we done?
Some light requirements work
was done in inception
to help
decide if the project was worth more serious investigation
.
Planning for the first iteration
has been completed
We have decided to tackle a simple cash-only success
scenario
of Process Sale
o f P r o c e s S a l e
(with no remote collaborations), with
the goal of starting a "wide and shallow" design and
implementation that touches on many major architectural
elements of the new system.
In the first iteration, many tasks related to establishing the
environment (tools, people, process, and setting) occur
Our focuses from now on are:
Understand what problems are (Analysis
), rather than how to
solve problems (Design
)
Analysis - use case and domain modeling analysis.
4
Introduction – System Sequence Diagram
A system sequence diagram
is a fast and easily
created artifact that illustrates input and output
events related to the systems under discussion
Before proceeding to a logical design of how a
software application will work, we should
investigate and define the system behavior as a
"black box
laxbock
“.
5
System Event and Response
Use cases describe how external actors interact
with the software system.
During this interaction an actor generates events
to a system, usually requesting some operation in
response.
For example, when a cashier enters an item's ID, the
cashier is requesting the POS system to record
that item's sale. That request event initiates an
operation upon the system.
6
System sequence diagram
A system sequence diagram
(SSD) is a picture
that shows, for a particular scenario of a use case,
the events that external actors generate, their
order, and inter-system events.
The emphasis of the diagram is events that cross the
system boundary from actors to systems.
An SSD should be done for the main success scenario
of the use case, and frequent or complex alternative
scenarios.
An SSD is generated from inspection of a use case
Suggestion:
One SSD – one Use Case
7
Case Study: How to do SSD in the POS Project
Simple cash-only
Process Sale
P r o c e s S a l e
scenario:
1. Customer arrives at a POS checkout with goods and/or
services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item
description, price, and running total.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
...
8
Step 1: Define System Events and the System Boundary
enterItem(itemID, quantity)
: Cashier
endSale()
makePayment(amount)
system boundary
:S yste m
makeNewSale()
the system boundary is usually chosen to be the software system itself;
in this context, a system event is an external event that directly
stimulates the software
9
Step 2: Naming System Events and Operations
enterItem(itemID, quantity)
scan(itemID, quantity)
: Cashier
worse name
better name
:S yste m
10
Step 3: show Use Case
Simple cash-only
Process Sale
P r o c e s S a l e
scenario:
1. Customer arrives at a POS checkout with goods and/or
services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item
description, price, and running total.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
...
11
Step 4: Do SSD
: Cashier :S yste m
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done.
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays and System handles
payment.
...
enterItem(itemID, quantity)
endSale()
makePayment(amount)
description, total
total with taxes
change due, receipt
* [more items]
makeNewSale()
12
SSD of UC - Process Sale
enterItem(itemID, quantity)
: Cashier :S yste m
endSale()
makePayment(amount)
box may enlose an
iteration area
the * [...] is an iteration
marker and clause
indicating the box is for
iteration
external actor to
s y s te m
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it
sim p le
the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
som e m echanism
description, total
total with taxes
change due, receipt
* [more items]
makeNewSale()
13
Relationships of SSDs to other artifacts