USE CASE MODELLING
Dr.C.P.INDUMATHI
ASSISTANT PROFESSOR
Dept of CSE/IT,BIT CAMPUS
Tiruchirappalli
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 1
CAMPUS
OUTLINE
Introduction
USE CASE
TERMS USED IN USE CASE
USE CASE FORMATS
WRITING USE CASE
CASE STUDY
HOW TO FIND USE CASE
USE CASE DIAGRAM NOTATION
RELATIONSHIPS BETWEEN ACTOR AND
USECASE
CASE STUDY
* Dr.C.P.INDUMATHI / Dept of CSE/ BIT CAMPUS 2
Use-Case Model
Unified Process defines the Use-Case Model within the
Requirements discipline
set of all use cases
it is a model of the system's functionality and environment
model shows how different types of users interact with the
system to solve a problem
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 3
CAMPUS
Introduction to Use Case
Text stories used to record requirements
Excellent technique to understand and describe functional
requirements.
Plays a significant role in the distinct phases of the Software
Development Life Cycle
Use cases are text documents, not diagrams
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
Eg: In Bank ATM system
Use Case 1: withdraw amount
Use Case 2: Deposit amount
Use Case 3: Check Balance
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 4
CAMPUS
Uses of the Use case Documents
Developers use the use case documents for implementing the
code and designing it.
Testers use them for creating the test cases.
Business stakeholders use the document for understanding
the software requirements.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 5
CAMPUS
Definitions/ Terms in Use Cases
Brief description
A brief description explaining the use case.
Actor
Users that are involved in Use Cases Actions
Actors are always outside the system and interact
directly with it by initiating a use case
provide input to it, and/or receive outputs from it
A person, an organization, or an outside system that
interacts with your application or system
Eg
• a timer that triggers sending of an e-mail reminder
• Cashier in POS system
• Student in online exam
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 6
CAMPUS
Definitions/ Terms in Use Cases
contd..
Primary Actors
Primary Actors are actor(s) using the system to achieve a goal
Eg Cashier in POS system, Student in student information
system
Supporting actors
provide services to the system under design.
Secondary Actors are actors that the system needs assistance from to
achieve the primary actor’s goal.
Eg calculator – to find total
Payment Authorization System – to validate pay
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 7
CAMPUS
Definitions/ Terms in Use Cases
Scenario contd..
Specific sequence of actions and interactions between actors
and usecase (also called a use-case instance)
Successfully purchasing items with cash
scenario of failing to purchase items because of a credit
card transaction denial
Use Case is a collection of related success and failure scenarios
that describe an actor using a system to support a goal
stakeholders
The stakeholders are people who have a reason to want this
system.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 8
CAMPUS
Definitions/ Terms in Use Cases
contd..
Preconditions:
Conditions to be Satisfied before the use case begins
Eg: In POS system, Cashier is identified and authenticated.
Success Guarantee (Postconditions):
The conditions that need to be checked after the case is
completed.
Eg
Sale is saved. Tax is correctly calculated.
Accounting and Inventory are updated. Commissions
recorded. Receipt is generated.
Payment authorization approvals are recorded.
.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 9
CAMPUS
Example 1
Use Case Name Verify User
Use case Description A user login to System to access
the functionality of the system.
Actors Parents, Students, Teacher,
Admin
Pre-Condition System must be connected to
the network.
Post -Condition After a successful login a
notification mail is sent to the
User mail id
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 10
CAMPUS
Definitions/ Terms in Use Cases
contd..
Basic Flow:
‘Basic Flow’ or ‘Main Scenario’ is the normal workflow in the
system.
It is the flow of transactions done by the Actors on accomplishing
their goals.
When the actors interact with the system, as it’s the normal
workflow, there won’t be any error and the Actors will get the
expected output.
Alternate flow:
Apart from the normal workflow, a system can also have an
‘Alternate workflow’.
Failure
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 11
CAMPUS
Main Scenarios Serial No Steps
Actors/Users 1 Enter username
Enter Password
2 Validate Username and
Password
3 Allow access to System
Extensions 1a Invalid Username
System shows an error
message
2b Invalid Password
System shows an error
message
3c Invalid Password for 4
times
Application closed
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 12
CAMPUS
Three Formats
Brief
Concise
one-paragraph summary
usually the main success scenario
Create during early requirements phase.
Casual
Informal paragraph format
Can cover various scenarios in multiple paragraphs.
Fully-dressed
All steps and variations written in detail.
Has supporting sections, success guarantees, main
scenario, alternate scenarios, etc.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 13
CAMPUS
brief format use case
Use case: Buy Items
Actors: Cashier
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 leaves with the items.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 14
CAMPUS
Casual Format
Handlereturn
Main Success Scenario: A customer arrives at a checkout
with items to return. The cashier uses the POS system to
record each returned item ...
Alternate Scenarios:
•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
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 15
CAMPUS
Fully Dressed Format
1. Customer arrives at 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.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done
System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the
external Accounting system (for accounting and commissions) and Inventory
system (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 16
CAMPUS
CASE STUDY: THE NEXTGEN point-of-sale (POS) system
A POS system is a computerized application used (in part) to record sales and
handle payments; it is typically used in a retail store.
It includes hardware components such as a computer and bar code scanner, and
software to run the system.
It interfaces to various service applications, such as a third-party tax calculator
and inventory control.
These systems must be relatively fault-tolerant;
that is, even if remote services are temporarily unavailable (such as the
inventory system), they must still be capable of capturing sales and handling at
least cash payments (so that the business is not crippled).
A POS system increasingly must support multiple and varied client-side terminals
and interfaces.
These include a thin-client Web browser terminal, a regular personal computer
with something like a Java Swing graphical user interface, touch screen input,
wireless PDAs, and so forth.
creating a commercial POS system that we will sell to different clients with
disparate needs in terms of business rule processing.
Each client will desire a unique set of logic to execute at certain predictable
points in scenarios of using the system, such as when a new sale is initiated or
when a new line item is added.
Therefore, we will need a mechanism to provide this flexibility and
*
customization. Dr.C.P.INDUMATHI / Dept of CSE/ BIT
17
CAMPUS
Fully Dressed Example: Process Sale
Use Case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer
shortages are deducted from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort. Wants proof of
purchase to support returns.
- Company: Wants to accurately record transactions and satisfy customer interests.
Wants to ensure that Payment Authorization Service payment receivables are
recorded. Wants some fault tolerance to allow sales capture even if server
components (e.g., remote credit validation) are unavailable. Wants automatic and fast
update of accounting and inventory.
- Government Tax Agencies: Want to collect tax from every sale. May be multiple
agencies, such as national, state, and county.
- Payment Authorization Service: Wants to receive digital authorization requests in the
correct format and protocol.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 18
CAMPUS
Main Success Scenario (or Basic Flow):
1. Customer arrives at 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.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done
System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment
information to the external Accounting system (for accounting and
commissions) and Inventory system (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 19
CAMPUS
Extensions (or Alternative Flows):
*a. At any time, System fails:
To support recovery and correct accounting, ensure all
transaction sensitive state and events can be recovered from
any step of the scenario.
1. Cashier restarts System, logs in, and requests
recovery of prior state.
2. System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records the
error, and enters a clean state.
2. Cashier starts a new sale.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 20
CAMPUS
3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and tracking unique item identity not
important (e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters item identifier for removal from sale.
2. System displays updated running total.
3-6b. Customer tells Cashier to cancel sale:
1. Cashier cancels sale on System.
4a.The system generated item price is not wanted (e.g., Customer complained
about something and is offered a lower price):
1. Cashier enters override price.
2. System presents new price
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 21
CAMPUS
5a. System detects failure to communicate with external tax calculation system
service:
1. System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Cashier may manually calculate and enter the tax, or cancel the
sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred
customer):
1. Cashier signals discount request.
2. Cashier enters Customer identification.
3. System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1. Cashier signals credit request.
2. Cashier enters Customer identification.
3. Systems applies credit up to price=0, and reduces remaining credit.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 22
CAMPUS
6a. Customer says they intended to pay by cash but don’t have
enough cash:
1a. Customer uses an alternate payment method.
1b. Customer tells Cashier to cancel sale. Cashier cancels
sale on system
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the
cash drawer.
3. Cashier deposits cash tendered and returns balance
in cash to Customer.
4. System records the cash payment.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 23
CAMPUS
7b. Paying by credit:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment
Authorization Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. System receives payment approval and signals approval to Cashier.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 24
CAMPUS
7c. Paying by cheque...
7d. Paying by debit...
7e. Customer presents coupons:
1. Before handling payment, Cashier records each coupon and System
reduces price as appropriate. System records the used coupons for
accounting reasons.
1a. Coupon entered is not for any purchased item:
1. System signals error to Cashier.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 25
CAMPUS
Special Requirements
• If a non-functional requirement, quality attribute, or constraint
relates specifically to a use case, record it with the use case.
• These include qualities such as performance, reliability, and
usability, and design constraints (often in I/O devices)
Special Requirements
• Touch screen Ul on a large flat panel monitor. Text must be
visible from 1 meter.
• Credit authorization response within 30 seconds
• Robust recovery when access to remote services such the
inventory system is failing.
• Language internationalization on the text displayed.
• Pluggable business rules to be insertable at steps 3 and 7.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 26
CAMPUS
Technology and Data Variations List
• Technical constraint imposed by a stakeholder regarding input
or output technologies
• For example, a stakeholder might say, "The POS system must
support credit account input using a card reader and the
keyboard
Technology and Data Variations List
• Item identifier entered by bar code laser scanner (if bar code
is present) or keyboard.
• 3b. Item identifier may be any UPC (universal product code),
EAN (European Article Number), or SKU (stock keeping
unit)coding scheme.
• 7a. Credit account information entered by card reader or
keyboard.
• 7b. Credit payment signature captured on paper receipt. But
within two years, we predict many customers will want digital
signature capture. Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 27
CAMPUS
Two-Column Variation
9. Logs the completed sale and sends
information to the external accounting
(for all accounting and commissions)
and inventory systems (to
update inventory). System presents
receipt.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 28
CAMPUS
Finding Use Cases
1. Choose the system boundary
2. Identify the primary actors
3. Identify the goals for each primary actor
4. Define use cases that satisfy these goals
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 29
CAMPUS
Choose the system boundary
Indicates the scope of your system
Encloses the Use Case
For POS case study
the POS system itself is the system under design
everything outside of it is outside the system boundary
including the cashier, payment authorization service, and so
on.
If the definition of the boundary of the system under design is not
clear
it can be clarified by further definition of what is outside
the external primary and supporting actors.
Once the external actors are identified, the boundary becomes clearer
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 30
CAMPUS
Questions to Find Actors and Goals
• Who starts and stops the system?
• Who does user and security management?
• Who does system administration?
• Is “time” an actor because the system does something in
response to a time event?
• How are software updates handled?
• Who gets notified of problems?
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 31
CAMPUS
Actor-Goal List
Actor Goal
Cashier Process Sales
Process rentals
Handle returns
Cash in
Cash out
Manager Start up
Shut down
System administrator Add/Modify/Delete users
Manage security
Manage System tables
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 32
CAMPUS
Define Use Cases
• Define one use case for each user goal.
• Name the use case similar to the user goal.
• for example, Goal: process a sale; Use Case: ProcessSale
• name use cases starting with a verb
• A common exception to one use case per goal is to collapse
CRUD (create,retrieve, update, delete) separate goals into
one CRUD use case, idiomatically called Manage <X>.
– For example, the goals "edit user," "delete user," and so
forth are all satisfied by the Manage Users use case.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 33
CAMPUS
Applying UML: Use Case Diagrams
• The UML provides use case diagram notation to illustrate the
names of use cases and actors, and the relationships
between them
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 34
CAMPUS
Actor
• Actor in a use case
diagram is any entity that
performs a role in one given
system
Custom icons that convey the kind of
actor may also be used to denote an actor,
such as using a separate icon(s) for
non-human actors.
An actor may also be shown as
a class rectangle with the
keyword «actor», having usual notation for
class compartments, if needed.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 35
CAMPUS
Use Case
• A use case represents a function or an action within the
system.
• Use cases are used to represent high-level functionalities
• It’s drawn as an oval and named with the function.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 36
CAMPUS
System
• The system is used to define the scope of the use case and
drawn as a rectangle.
• This an optional element but useful when you’re visualizing
large systems.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 37
CAMPUS
Bank ATM System
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 38
CAMPUS
POS System
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 39
CAMPUS
RELATING USE CASES & INCLUDE,
EXTEND AND GENERALIZATION
There can be 5 relationship types in a use case diagram.
Association between actor and use case
Generalization of an actor
Generalization of a use case
Extend between two use cases
Include between two use cases
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 40
CAMPUS
Association Between Actor and Use Case
An actor must be associated with at least one use case.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 41
CAMPUS
Generalization of an Actor
Generalization of an actor means that one actor can inherit the role of an
other actor.
The descendant inherits all the use cases of the ancestor.
The descendant have one or more use cases that are specific to that role.
Generalization between actors is rendered as a solid directed line with a
large arrowhead
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 42
CAMPUS
Generalization of a Use Case
This is similar to the generalization of an actor.
The behavior of the ancestor is inherited by the
descendant.
This is used when there are common behavior
between two use cases and also specialized
behavior specific to each use case.
For example in the previous banking example
there might be an use case called “Pay Bills”.
This can be generalized to “Pay by Credit
Card”, “Pay by Bank Balance” etc.
It is rendered as a solid directed line with a large
arrowhead, the same as
for generalization between classifiers
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 43
CAMPUS
Extend Relationship Between Two Use Cases
As the name implies it extends the base use case and adds
more functionality to the system
The extending use case is dependent on the extended (base)
use case.
“Calculate Bonus” use case doesn’t make much sense without
the “Deposit Funds” use case.
The extending use case is usually optional and can be
triggered conditionally.
Extending use case is triggered only for deposits over 10,000
or when the age is over 55.
The extended (base) use case must be meaningful on its own.
This means it should be independent and must not rely on
the behavior of the extending use case
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 44
CAMPUS
Extend relationship between use cases is shown by a dashed arrow with
an open arrowhead from the extending use case to the extended (base)
use case.
The arrow is labeled with the keyword «extend».
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 45
CAMPUS
Registration use case is complete and meaningful on its
own. It could be extended with optional Get Help On
Registration use case
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 46
CAMPUS
UC1: Process Sale (the base use case)
Extension Points: VIP Customer, Payment, step 7. Main Success
Scenario:
1 . Customer arrives at a POS checkout with goods and/or services to
purchase.
…
7. Customer pays and System handles payment.
…
UC15: Handle Gift Certificate Payment (the extending use case)
…
Trigger: Customer wants to pay with gift certificate.
Extension Points: Payment in Process Sale.
Level: Subfunction Main Success Scenario:
1 . Customer gives gift certificate to Cashier.
2. Cashier enters gift certificate ID.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 47
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 48
CAMPUS
Include Relationship Between Two Use Cases
Include relationship show that the behavior of the included use case
is part of the including (base) use case.
Reuse the common actions across multiple use cases.
Simplify complex behaviors.
The base use case is incomplete without the included use case.
The included use case is mandatory and not optional
An include relationship between use cases 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».
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 49
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 50
CAMPUS
When two or more use cases have some common behavior, this common
part could be extracted into a separate use case to be included back by the
use cases with the UML include relationship
Use case C is extracted
from use cases A and B to
be reused by both use
cases using UML include
relationship
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 51
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 52
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 53
CAMPUS
For example: UC1: Process Sale
Main Success Scenario:
1 . Customer arrives at a POS checkout with goods
and/or services to purchase.
7. Customer pays and System handles payment.
Extensions:
7b. Paying by credit: Include Handle Credit Payment.
7c. Paying by check: Include Handle Check Pavment.
UC7: Process Rental
Extensions:
6b. Paying by credit: Include Handle Credit Payment.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 54
CAMPUS
UC12: Handle Credit Payment
Level: Subfunction Main Success Scenario:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external
Payment Authorization Service System, and requests payment
approval.
3. System receives payment approval and signals approval to
Cashier.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 55
CAMPUS
Generalization Extend Include
Base use case could Base use case is complete Base use case is
be abstract use (concrete) by itself, defined incomplete (abstract use
case (incomplete) or independently. case).
concrete (complete).
Specialized use case Extending use case is Included use case required,
is required, not optional, supplementary. not optional.
optional, if base use
case is abstract.
No explicit condition Could have optional No explicit inclusion
to use specialization. extension condition. condition.
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 56
CAMPUS
POS System
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 57
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 58
CAMPUS
summary
1. List main system functions (use cases)
2. Draw ovals around the function labels
3. Draw system boundary
4. Draw actors and connect them with use cases
5. Specify include and extend relationships between use cases
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 59
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 60
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 61
CAMPUS
Loan System
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 62
CAMPUS
Bank ATM
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 63
CAMPUS
Dr.C.P.INDUMATHI / Dept of CSE/ BIT
* 64
CAMPUS
