CHAPTER 2:

USE CASE DIAGRAM

LEARNING OBJECTIVES

✔Understand the object-oriented modeling processes by studying use case

diagram.
✔Draw data use case diagram following specific rules and guidelines that
lead to accurate and well-structured process models.
✔ Detail the use case diagram using the Use Case relationship.
✔Simplify the use case diagram by learning how to write the use case
description.
✔Use Use case diagrams as a tool to support the analysis of information
systems.
UML DIAGRAM – USE CASE DIAGRAM
INTRODUCTION
Use Cases are descriptions of the functionality of a system from a
user perspective.
 Depict the behavior of the system, as it appears to an outsite user.
 Describe the functionality and user (actors) of the system.
 Show the relationships between the actors that use the system, the use
cases (functionality) the use, and the relationship between different use
cases
 Document the scope of the system
 Illustrate the developer’s understanding of the user’s requirements.
WHY USE CASE DIAGRAM IN OO ANALYSIS
 Answers the main question about system:
- Who the system’s for?
- What must it do?
- Why build it in the first place?
 System users: Actor
 System normal situations: Use-case
 Stay Focus on client’s goals
 A good use case must represent the point of view of
people who will use the system and how the system
interact with them
 Complete set of use case will represent the system
requirements.
 USE-CASE DIAGRAM
 A use-case model is a diagram or set of diagrams that together with
some additional documentation show what the proposed software
system is designed to do A use-case diagram consist of three main
components:
- Actor
- Use Cases, and their communications
- Some additional documentation such as use –case descriptions
for elaborating use-case and problem statements that are initially
used for identifying use
USE-CASE DIAGRAM :ACTORS

 Usually represented with a stick figure

 An actor may be:
- People
- Hardware and device (IOT)
- External system
USE-CASE DIAGRAM : ACTOR
 An actor represents a role that a system user can play,
 But actor is NOT a specific user
 Primary actors (active) are those who use the system’s main functions, deriving
benefits from it directly.
 Secondary actors (passive) play a supporting role to facilitate the primary actor
to achieve their goals.
 Secondary actor often appear to be more inside the system than outside
 Secondarry actors are usually not derived directly from the statement of
requirements. Hence, the designer can have more freedom in specifying the roles of
these actors
 Usually found on the right of the system (primary on the left)
USE-CASE DIAGRAMS : ACTORS

Actors treated like classes and it

can be generalized (Inherited)
USE-CASE DIAGRAMS : ACTORS AND GOALS

 Start by identifying the actors of the system

 See if the actors can be generalized or not
 Define the goals of the system and how they can
be achieved with system actor
 Demonstrate these goals and actors' actions using
use-case diagram.
USE CASE DEFINITION
 Use cases specify desired behavior.
 A use case is a description of a set of sequences of actions
 Each sequence represent an interaction of actors with the
system.
 Naming convention = verb +noun
 - e.g. Make Appointment Make
Appointment
 Represented by an oval
USE OF THE USE CASE

 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.
USE CASE MAIN COMPONENT
 The use case has three components.
 The use case task referred to as the use case that represents a
feature needed in a software system.
 The actor(s) who trigger the use case to activate.
 The communication line to show how the actors
communicate with the use case.
USE CASE AND ACTOR RELATIONSHIP

 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
SYSTEM BOUNDARY

 It is Shown a rectangle ATM System

 Boundary help to identify what is

external versus internal, and what the
responsibilities of the system are
 The external environments is only
represent by actors.
USE CASE EXAMPLE
System name

Actor Use-case

Association System boundary

17
RELATIONSHIPS BETWEEN USE CASES

1. Include - use cases that are included as parts of other use

cases. Enable to factor common behavior.
2. Extend - use cases that extend the behavior of other core use
cases. Enable to factor variants.
INCLUDE

 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.
<<include>>
base included
EXTENDS

 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.
<<extend>>
base extending
EXAMPLE 1
EXAMPLE 2
EXERCISE

 Develop a use case diagram that capture a customer

who want to open a new account in Bank and also to
handle the deposit fund process.
SOLUTION
EXERCISE

 Modify the previous use case diagram to allow customer to

withdraw fund and how the system handle the withdrawal
process. Plus model add a calculate bonus function into current
fund. Please use extend and include in your Use case.
Solution
USE CASE DESCRIPTION
USE CASE DESCRIPTION TEMPLATE
Use Case Name meaningful name of the UC

Brief Description short description of the processes

Actor agents participating

Pre-Conditions must be true to allow execution

Basic Flow regular flow of activities

Alternative Flow other flow of activities

Exception Flow unusual situations

Post-Conditions will be set when completes normally

Constraints need to full fill

 Example- Money Withdraw

Actor Actions System Actions

1. Begins when a Customer arrives at ATM

2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status

5. Customer chooses “Withdraw” operation 4. System asks for an operation type

7. Customer enters the cash amount 6. System asks for the withdraw amount
8. System checks if withdraw amount is legal

9. System dispenses the cash

10. System deduces the withdraw amount from account

11. System prints a receipt

13. Customer takes the cash and the receipt 12. System ejects the cash card
 Use case description Example
Use case name Withdraw Money

Brief description This use case is to withdraw some cash from user’s
bank account
Actor Customer
Pre condition • The ATM must be in a ready state 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
Basic Flow 1. The use case starts when the customer inserts his
ATM card into the system.
2. The system requests the user PIN.
3. The system validates the PIN [E1: Validation failure
is executed ]
4. The customer choose withdraw operation.
5. The customer enters the amount of cash to
withdraw.
6. The system checks the amount of cash in the user
account [E2 - Amount exceeded is executed] [C1 -
Constraint 1]
7. The use case end.
Alternative Flow None
Exception Flow E1: Validation failure is executed.
1.Customer authorization failed.
2.Display an error message,
3.Cancel the transaction and eject the card.
4.Continue with step 1 or 7 from basic flow.

E2 : Amount exceeded is executed

1. Customer has insufficient funds in its account.
2. Display an error message.
3. Continue with step number 5 from basic flow.

OR

1. Customer exceeds its legal amount.

2. Display an error message,
3. Continue with step number 5 from basic flow .
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

Constraints C1 : Amount to withdraw per day

The amount allowed to withdraw per day is

RM3000 only
EXAMPLE 2 – USE CASES DIAGRAM & USE CASE
DESCRIPTION
MANAGE BOOKING USE CASE
Brief Description This use case is initiates by customer and clerk. It provides the customer the
(1m)
capability to booking wedding package by choosen date, place and type of
package. Customer also can edit and delete the booking. (0.5m)
The cleark can view all the booking by the customer.(0.5m)

Actor (1m) Even driven by the customer and clerk (1m)

Pre-Conditions The customer and clerk already login to the system. (1m)
(1m)
BASIC FLOW

Basic Flow 1. The use begins when the customer go to booking package menu.
(3m)
2. The customer is able to:
a. Add new booking for wedding package [A1:Add booking]
b. Delete booking for wedding package [A2: Delete booking]
c. Edit booking for wedding package [A3: Edit booking]
3. The customer click <<CONFIRM>> button.
4. The clerk is able to VIEW booking by the customer. The clerk click
<<VIEW>> button. The system list all the customer booking
information data.
5. The use case ends.
Alternative Flow A1: Add Booking
(2m) 1. The customer choose date, place and type of wedding package.
2. If the date is available [E1: Date Not Available], place [E2: place not available] and type of wedding
package is chosen, the customer need to click the <<ADD BOOKING> button
3. The use case continues to step number 3 in basic flow.
A2: Delete Booking
1. The customer choose the booking that he/she already done it before this.
2. The customer click <<DELETE>> button.
3. The use case continues to step number 3 in basic flow.
A3: Edit Booking
1. The customer choose the booking that he/she already done it before this.
2. The customer click <<EDIT>> button.
3. The customer edit the information that he/she key-in before this.
4. The customer click <<SAVE>> button.
5. The use case continues to step number 3 in basic flow.
Exception Flow E1: Date Not Available
(1m) 1. The customer choose a new date for booking.
2. The system check the availability of that date.
3. The use case continues to step 2 in alternative flow A1.

E2: Place Not Available

1. The customer choose a new place for booking.
2. The system check the availability of that place.
3. The use case continues step 2 in alternative flow A1.

Post Condition The list of booking is success and updated.(1m)

(1m)
SUMMARY
1. User Case is Conceptual line that separates the system that you want
to build, and it scope, and the stakeholder involve.
2. Use case relationship allow analyst to expand the function and tight and
loose relationship that we as analyst can expand the requirement to
make it more clear.
3. Use Case description identify the critical, information, data and rules
that we need to consider and identify for the particular use case
4. Use case description also detail out the requirement by using simple
technical written language to elicit the use case.