Use Case

Diagram

Object Oriented Design and Analysis

 Introductio
Use-cases are descriptionsnof the functionality of a
system from a user perspective.

Depict the behaviour of the system, as it appears to an
outside user.

Describe the functionality and users (actors) of the system.

Show the relationships between the actors that use the
system, the use cases (functionality) they use, the
and
relationship between different use cases.

Document the scope of the system.

Illustrate the developer’s understanding of the user’s
requirements.

Object Oriented Design and Analysis

 Use Case Diagram,
purposeClass Activity
diagrams diagrams

Requirements Sequence
document diagrams
(text in natural language)

Statechart
diagrams

• Use case models are developed at different levels of

abstraction
• –system, system component, or a class.
Use case modelling is an iterative and incremental process.
–If affected
user requirements change,the changes should
be documents.
made in all the

Object Oriented Design and Analysis

 Use Case diagrams, basic UML
 Use Case: A Usenotation
Case is a description of a
set of interactions between a user and the
system.
 Components of use case diagram:
 Actor
use case
 Use case name

 System boundary use case

name
 Relationship
use case
name

Object Oriented Design and Analysis

 Use cases: Information
•Actors captured
• Relationships with other use
cases
• Pre-conditions
• Details
• Post-conditions
• Exceptions
• Constraints
• Alternatives
Object Oriented Design and Analysis
 ACTO
 An actor is some one R
or something that must
interact with the system under development
 Actors can be human or automated systems.
 Actors are not part of the system.
 UML notation for actor is stickman, shown
below.

Student Faculty Employee

Object Oriented Design and Analysis
 ACTOR
(contd..)
• It is role a user plays with respect to
system.
• Actors carry out use cases and a single
actor may perform more than one use
cases.
• Actors are determined by observing the
direct uses of the system

Object Oriented Design and Analysis

 Primary and Secondary
• Primary Actor
Actors
–Acts on the system
–Initiates an interaction with the system
–Uses the system to fulfill his/her goal
–Events Something we don’t have control
• over
Secondary Actor
–Is acted on/invoked/used by the system
–Helps the system to fulfills its goal
–Something the system uses to get its job
done
Object Oriented Design and Analysis
 USE
What is USE case?
CASE
A use case is a pattern of behavior, the
system exhibits
The use cases are sequence of actions that
the user takes on a system to get particular
target
USE CASE is dialogue between an actor
and the system.
Add a
• Example course
s:
Object Oriented Design and Analysis
 Contd.
•
.
A use case typically represents a major piece of
functionality that is complete from beginning to
end.
• Most of the use cases are generated in initial
phase, but may add some more after
proceeding.
A use case may be small or large. It captures a
broad view of a primary functionality of the
system in a manner that can be easily grasped
by non technical user.

Object Oriented Design and Analysis

 System
 It Boundary
is shown as a rectangle.
 It helps to identify what is external versus internal, and
what the responsibilities of the system are.
 The external environment is represented only by actors.

Object Oriented Design and Analysis

 Relationshi
• p between use case and
Relationship is an association
• actor. There are several Use Case relationships:

 Association

 Extend

 Generalization

 Uses

 Include
Object Oriented Design and Analysis
 Extend
 The extended
Relationship
relationship is used
to indicate that
use case completely consists of the behavior of
another use case at one or specific point
 use cases that extend the behavior of other core
use cases. Enable to factor variants
 The base use case implicitly incorporates the
behavior of another use case at certain points
called extension points
 It is shown as a dotted line with an arrow point and
labeled <<extend>>
<<
extend>> Register
Logi
New User
n

Object Oriented Design and Analysis

 Generalizatio
n
 Generalization is a relationship between a
general use case and a more specific use
case that inherits and extends features to
it
 use cases that are specialized versions of
other use cases
 It is shown as a solid line with a hollow
arrow point

Object Oriented Design and Analysis

 Uses
Relationship
 When a use case uses another process, the
relationship can be shown with the uses
relationship
 This is shown as a solid line with a hollow
arrow point and the <<uses>> keyword

Object Oriented Design and Analysis

 Include
Relationship
 Include relationships insert additional behavior into
a base use case
 use cases that are included as parts of other use
cases.
Enable to factor common behavior.
 The base use case explicitly incorporates the
behavior of another use case at a location
specified in the base.
 They are shown as a dotted line with an open arrow
and the key word <<include>>

Object Oriented Design and Analysis

 Extend vs
Include

Object Oriented Design and Analysis

 Exampl
e
place
place <<extend>>
conference
phone call
call
cellular
receive
receive <<extend>>
network additional
phone call
call

use
user scheduler
Cellular Telephone

18
Object Oriented Design and Analysis
 Use Case
Description
:Each use case may include all or part of the
 following
Title or Reference Name - meaningful name of the UC
 Author/Date - the author and creation date
 Modification/Date - last modification and its date
 Purpose - specifies the goal to be achieved
 Overview - short description of the
processes
 Cross References - requirements references
 Actors - agents participating
 Pre Conditions - must be true to allow execution
 Post Conditions - will be set when completes
normally
 Normal flow of events - regular flow of activities
 Alternative flow of events - other flow of activities
 Exceptional flow of events - unusual situations
 Implementation issues - foreseen implementation
problems
Object Oriented Design and Analysis
 Example- Money
• Use Case: Withdraw Money Author: PKD
• Date: 11-09-2013 Withdraw
• Purpose: To withdraw some cash from user’s bank account
• Overview: The use case starts when the customer inserts his card
• into the system. The system requests the user PIN. The system
validates the PIN. If the validation succeeded, the customer can
choose the withdraw operation else alternative 1 – validation
failure is executed. The customer enters the amount of cash to
withdraw. The system checks the amount of cash in the user
account, its credit limit. If the withdraw amount in the range
between the current amount + credit limit the system dispense
the cash and prints a withdraw receipt, else alternative 2 –
amount exceeded is executed.
Cross References: R1.1, R1.2, R7
•

Object Oriented Design and Analysis

• Actors: Customer
• Pre Condition:
– The ATM must be in a state ready to accept transactions
– The ATM must have at least some cash on hand that it can
dispense
– The ATM must have enough paper to print a receipt for at least
• one transaction
Post Condition:
– The current amount of cash in the user account is the amount
before the withdraw minus the withdraw amount
– A receipt was printed on the withdraw amount
– The withdraw transaction was audit in the System log file

Object Oriented Design and Analysis

 Typical course of
events

Object Oriented Design and Analysis

• Alternative flow of events:
– Step 3: Customer authorization failed. Display an
error message, cancel the transaction and eject the
card.
– Step 8: Customer has insufficient funds in its
account. Display an error message, and go to step
6.
• – Step 8: Customer exceeds its legal amount. Display
an error message, and go to step 6.
Exceptional flow of events:
– Power failure in the process of the transaction before
step 9, cancel the transaction and eject the card

Object Oriented Design and Analysis

 One method to identify use cases is actor-
based:
- Identify the actors related to a system or organization.
- For each actor, identify the processes they initiate or participate in.
 A second method to identify use cases is event-based:
- Identify the external events that a system must respond to.
- Relate the events to actors and use cases.
 The following questions may be used to help identify
the use cases for a system:
- What are tasks of each actor ?
- Will any actor create, store, change, remove, or read information in the
system ?
- What use cases will create, store, change, remove, or read this
information ?
- Will any actor need to inform the system about sudden, external
changes ?
- Does any actor need to be informed about certain occurrences in the
system ?
- Can all functional requirements be performed by the use cases ?
Object Oriented Design and Analysis
 Usecase diagram for Hospital Reception Module

•Describe major services (functionality) provided by a hospital's

reception.
•Hospital Reception subsystem or module supports some of the
many job duties of hospital receptionist. Receptionist schedules
patient's appointments and admission to the hospital, collects
information from patient upon patient's arrival and/or by phone. For
the patient that will stay in the hospital ("inpatient") she or he should
have a bed allotted in a ward. Receptionists might also receive
patient's payments, record them in a database and provide receipts,
file insurance claims and medical reports.
 Usecase diagram for ATM Management System

•An automated teller machine (ATM) or the automatic banking machine

(ABM) is a banking subsystem (subject) that provides bank customers
with access to financial transactions in a public space without the need for
a cashier, clerk, or bank teller.
•Customer (actor) uses bank ATM to Check Balances of his/her bank
accounts, Deposit Funds, Withdraw Cash and/or Transfer Funds (
use cases). ATM Technician provides Maintenance and Repairs. All these
use cases also involve Bank actor whether it is related to customer
transactions or to the ATM servicing.