COURSE NAME

OBJECT ORIENTED CHAPTER 2

ANALYSIS AND
DESIGN USE CASE DIAGRAM
CSC 2210
SOFTWARE
(UNDERGRADUATE)
ENGINEERING
(UNDERGRADUATE
)
 Chapter 2: Use Case Diagram
S.2

USAGE OF USE CASE DIAGRAM?

 Use case diagrams are used to visualize, specify, construct, and document
the (intended) behavior of the system, during requirements capture and
analysis.
 Provide a way for developers, domain experts, and end-users to
Communicate.
 Serve as basis for testing.
 Use case diagrams contain use cases, actors, and their relationships.
 Chapter 2: Use Case Diagram
S.3

 Use cases specify desired behavior.

USE CASE
 A use case is a description of a set of sequences of actions, including
variants (alternatives),
a system performs to yield an observable result of value to an actor.
 The names of use cases are always written in the form of a verb followed
by an object.
 Each sequence represent an interaction of actors with the system.
 Describing the flow of events within the use case.
 Can be done in natural language, formal language or pseudo-code.
 Includes:
 How and when the use case starts and ends;
 When the use case interacts with actors and what objects are
exchanged;
 The basic flow and alternative flows of the behavior.
 Chapter 2: Use Case Diagram
S.4

ACTOR
 An actor represents a set of roles that users of use case play when
interacting
with these use cases.
 Actors can be human or automated systems.
 Actors are entities
 which require help from the system to perform their task, or
 are needed to execute the system’s functions.
 Actors are not part of the system.
 A system can be an Actor of other systems

Actor
 Chapter 2: Use Case Diagram
S.5

USE CASES AND ACTOR

 From the perspective of a given actor, a use case does something that is of
value to the actor, such as calculate a result or change the state of an object.
 The Actors define the environments in which the system lives
 Actors may be connected to use cases by associations, indicating that the actor
and the use case communicate with one another using messages.

updating
grades

faculty
Chapter 2: Use Case Diagram
S.6

EXAMPLE OF USE CASES DIAGRAM

University Management
System

Login

Registration of
Course
Faculty Student

Upload
Grade
 Chapter 2: Use Case Diagram
S.7
 IncludeRELATIONSHIPS BETWEEN
- use cases that are included USE
as parts of otherCASES
use. Enable to factor
common behavior
 The base use case explicitly incorporates the behavior of another use case at
a location
specified in the base.
 The included use case never stands alone. It only occurs as a part of some
larger base
that includes it. The original use case is not complete without the included
one

<<include>>
base included
 Chapter 2: Use Case Diagram
S.8

RELATIONSHIPS BETWEEN USE CASES

 Enables to avoid describing the same flow of events several times by
putting the common behavior in a use case of its own.

updating
grades
<<include>>
verifying
Id and password

<<include>>
registration
 Chapter 2: Use Case Diagram
S.9

RELATIONSHIPS BETWEEN USE CASES

 Extend – a part of a use case that is optional system behavior
 The base use case implicitly incorporates the behavior of another use case at
certain points called extension points.
 The base use case may stand alone, but under certain conditions its behavior
may be extended by
the behavior of another use case.
 Enables to model optional behavior or branching under conditions.

Vacatio
n

<<extend>>
base extending
 Chapter 2: Use Case Diagram S.
10

RELATIONSHIPS BETWEEN USE CASES

 Generalization - A generalization relationship means that a child use case
inherits the behavior and meaning of the parent use case. The child may add
or override the behavior of the parent.

Student
registration

under-graduate graduate
registration registration
 Chapter 2: Use Case Diagram S.
11

RELATIONSHIPS BETWEEN ACTORS

 Generalization - A generalization relationship means that a child actor
inherits the behavior and meaning of the parent actor. The child may add or
override the behavior of the parent.
Chapter 2: Use Case Diagram S.
12

USE CASES DESCRIPTION

 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
 Chapter 2: Use Case Diagram S.
13
 UseUSEcase CASES
Title: UC-1EXAMPLE – ATM MONEY WITHDRAW
 Use Case: Withdraw Money
 Author: Jack Lonagon
 Created Date: 1-OCT-2015
 Modification Date: 20-Apr-2017
 Purpose: To withdraw some cash from user’s bank account
 Overview: The use case starts when the customer inserts his credit 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.
 Chapter 2: Use Case Diagram S.
14

USE CASES EXAMPLE – ATM MONEY WITHDRAW

 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
 Chapter 2: Use Case Diagram S.
15

USE CASES EXAMPLE – ATM MONEY WITHDRAW

 Typical Course of events:

Actor Actions System Actions

1. Begins when a Customer arrives at
ATM
2. Customer inserts a Credit card into 3. System verifies the customer ID and PIN
ATM & PIN
5. Customer chooses “Withdraw” 4. System asks for an operation type
operation
7. Customer enters the cash amount 6. System asks for the withdraw amount
8. System checks if withdraw amount is legal
(50k per day)
9. System dispenses the cash
10. System deduces the withdraw amount from
account
balance and set new balance
11. System prints a receipt
 Chapter 2: Use Case Diagram S.
16

USE CASES EXAMPLE – ATM MONEY WITHDRAW

 Alternative flow of events:
– Step 3: Customer authorization failed. Display an error message,
cancel the transaction and eject the card. Some other thing may
happen for example go to step 2 try login again for maximum 3 times
and after that the failed login attempt will seize and inform related
authority of any suspicious activity in the ATM machine.
– 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 4.

 Exceptional flow of events:

– Power failure in the process of the transaction before step 9, cancel
the transaction and eject the card
 Chapter 2: Use Case Diagram S.
17

IDENTIFY USE CASES

 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 (cash withdraw) to actors (customer) and use cases (ATM
system).

 The following questions may be used to help identify the use cases for
a system:
- What are the 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 ?
 Chapter 2: Use Case Diagram S.
18

CASE STUDIES: USE CASE DIAGRAM

 Case 1:
In a hotel management system, a guest can rent rooms. Hotel
receptionist uses the system to assist in the renting. A guest can also
book a room for future renting with the help of the receptionist, but
he has to check if the room has prior booking or not. A Guest pays for
the rooms at the time they check out. He can pay by cash, cheque or
credit card. Receptionists has to logon to the system before they can
use it, but to logon he has go through username/password
verification.
CASE 1 SOLUTION:

 In a hotel management system:

A guest can rent rooms. Hotel receptionist uses the
system to assist in the renting. A guest can also book
a room for future renting with the help of the
receptionist, but he has to check if the room has prior
booking or not. A Guest pays for the rooms at the
time they check out. He can pay by cash, check or
credit card. Receptionists has to logon to the system
before they can use it, but to logon he has go through
username/password verification.

19
 Chapter 2: Use Case Diagram S.
20

CASE STUDIES: USE CASE DIAGRAM

 Case 2:
Music Today is an audio recording company. There are several
recordists in the company. Clients record their music with the help of
the recordists. The recording is done in a session. A session is usually
created by the office clerk. A session needs to be booked by the
client beforehand and before booking the time needs to be verified
by the booking clerk for availability. The company maintains a list of
preferred clients who book sessions like regular clients but also can
create sessions according to their needs. Clerks have to log in to use
the system. Clients can pay in cash or card. The accountant deals
with the payment. The payment is only cleared when the accountant
receives clearance from the booking clerk.
 Chapter 2: Use Case Diagram S.
21
 Case 3:
CASE STUDIES: USE CASE DIAGRAM
In a hospital management system, a patient's medical history is
created by a doctor. A patient may be referred by a doctor to be
admitted in the hospital. A patient can rent hospital facilities. An
administrative officer deals with the renting. The system
automatically checks whether the patient is referred by a doctor
before he can rent any hospital facility. The types of facilities are
rooms, beds or ICUs. Admitted patients are regularly visited by
doctors and a nurse updates patient medical history after each visit.
A doctor writes the discharge note of the patient when he leaves
which is also included in the patient's medical history. An account
clerk prepares the bill. The bill is calculated from the elements
written in the medical history, i.e. number of doctor's visit, prescribed
medication, tests. When the nurse updates the medical history she
writes either the date-time of doctor's visit or prescribed medication
or test. The patient may pay by cash or card when the bill is
prepared.
 Chapter 2: Use Case Diagram S.
22
 Case 4:
CASE STUDIES: USE CASE DIAGRAM
ABCD Records is a mail order company that distributes CDs and tapes
at discount prices to record club members. A member fills up an
order form and sends it to the order processing clerk. When the order
processing clerk receives an order form, she verifies that the sender
is a club member by checking the member file. She also checks the
status of the member whether he is a royal class member or regular
class member. If the sender is not a member, the clerk returns the
order along with a membership application form. If the customer is a
member, the clerk verifies the order item data by checking the item
file. Then the clerk enters the order data and saves it to the daily
records file. At the same time the clerk also prints an invoice and
shipping list for each order, which are forwarded to the collection
department clerk for processing there. If the items are not available
they are ordered if the member is a royal class member. Royal class
members also get discounts. The members can pay by cash, check or
bank draft.
 Chapter 2: Use Case Diagram S.
23

REFERENCES

 Booch, G., Rumbaugh, J. & Jacobson, I. (2005). The unified modeling language
user guide. Pearson Education India.