19CSE204 Object Oriented Programming: OO Analysis With Use Case

19CSE204 Object oriented Programming
19CSE204 Object Oriented Programming

Lecture 4
OO Analysis with Use case
Nalinadevi Kadiresan
CSE Dept.
Amrita School of Engg.
19CSE204 Object oriented Programming 2
Object Oriented Development

• Phases
– Object-Oriented Analysis: understand the
domain
• Define an object-based model of it
– Object-Oriented Design: Define an
implementation
• Design the solution
– Object-Oriented Programming: Build it
June 2021 Nalinadevi Kadiresan

Object Oriented Analysis

• Object-oriented analysis is a method of
analysis that examines requirements from
the perspective of the classes and objects
found in the vocabulary of the problem
domain
• Steps in examining requirements are:
1. Use Case Document preparation
2. Object Model preparation

What is Use case?

• A use case is a narrative description of a goal-
oriented interaction between the system under
development and an external agent.
• A use case is sort of like a dialog script written for
two actors. Use cases capture requirements in the
form of interactions with an end user.
• When requirements are described in terms of
interactions with end users missing details
become obvious.

Identifying use case
• Functional requirements are

used to identify use cases.
• The tools to identify use cases
are:
– Goals of the Actor


History of Object Oriented

Software Engineering
• use cases was pioneered by Ivar
Jacobson in 1995
• The use cases are an important
component of Jacobson's Objectory
methodology and its simplified OOSE

Use Cases Do Not Require

Technical Knowledge

An example – Home security

system
Use Case
Deactivate Alarm
Title:
Actors: Home owner
Description: This use case begins when the home owner
enters the home and the alarm sounds. The
home owner enters a preassigned code on
the keypad to deactivate the alarm. If the
correct code is entered within 30 seconds
the alarm is deactivated, otherwise a
security alert is sent to the local police
station.
Main sections of Use case

document
• Use Case Name
• Description
• Actors
• Trigger
• Preconditions
• Flow – Basic Flow, Alternates and Exceptions
• Level
• Post condition
• Stakeholders

Create Unique and Explanatory

Names
• Use Case naming is usually done based on an
organization’s data standards.
• If your organization has already been using Use Cases,
ensure that you name your Use Case using the same
terminology as the other use cases.
• Use cases need to be searchable and they need to be
easily available when needed.
• Some companies simply assign numerical IDs to ensure
that use cases are easily indexed and maintained.

Actors
• The actors in the use case are the people or

elements who are involved in the process
• Primary Actor
– person who is responsible for the event for which
the Use Case exists
• Secondary Actor
– person or group of people that is needed to
complete the process successfully

Trigger
• A trigger simply defines the exact action which
results in the Use Case
• Types of Trigger:
– External events are those started by an actor, either a person
or another system requesting information, such as an airline
reservation system requesting flight information from an
airline system.
– Temporal events are those that are triggered or started by
time. Events occur at a specific time, such as sending an
email about special offers once a week on a Sunday evening

Precondition
• The preconditions are the conditions

that need to be met to ensure that the
use case can be fulfilled. If these
conditions are not met then the case
cannot run its course.

Flow
• You need to define the flow of the process
that starts when a use case is started.
• The flow needs to detail how the
communication will flow, who the
information will be displayed to, what they
need to do, and where the primary actor
will end up.

Flow - contd
• 3 things which you need to mention when writing the
flow.
– Basic Flow: best case scenario of what should
happen in the use case if all the conditions are met
– Alternates: Are there any alternate routes that the
action can be done?
– Exceptions: This dictates what happens when a
failure occurs in the flow.
• Exceptions are just as important to define as basic flow.

Flow - contd
Just one sentence writing style:
– a sentence in the present tense,
– with an active verb in the active voice,
– describing an actor successfully achieving a goal that
moves the process forward.
– Examples are,
• "Customer enters card and PIN."
• "System validates that customer is authorized and has sufficient funds."
• "PAF intercepts responses from the web site, and updates the user's
portfolio."
• "Clerk Finds a loss using search details for "loss"."

Level
• It is important to classify the use case with

a level in order to explain the urgency
which it needs to be dealt with.
• You need to ensure that whoever reads
the use case realizes its importance to
ensure that they give it the right amount of
time.

Level
• Different levels of use-case:
1. High Level Summary(white/cloud) -Enterprise level
2. Summary of goals (Kite) - business unit or department
level
3. User Goal (Blue/ Sea level) - usually written for a
business activity and each person should be able to do one
blue level activity in anywhere from 2 to 20 minutes.
4. Sub-Function (Indigo/ fish) - shows lots of detail
5. Low Level (Black/calm) - most detailed use cases

Level - Example

Postcondition
• It is the state of the system after the

use case has finished, including
output people have received,
transmissions to other systems, and
data that have been created or
updated.

Stakeholders
• Who are the people that are going to be affected
by the use case?
• There’s no way to write a good process if you do
now know who will be affected because only when
you know all the people involved will you be able
to ensure that your design does everything that it
needs to do.

Example-1 Coin Flip

Use Case Name: Coin Flip
Description: A player at random offers a prediction of

coin flip. The other play gets the other option. The coin is
flipped. The correct guess wins
Actors:
1.A player who makes the prediction
2.A player who gets the other option
3.Coin
4.Coin game

Example-1 Coin Flip

Trigger: A player at random offers a prediction.
Preconditions:
1. 2 players are available
2. A coin available
Basic Flow ("Sunny Day Scenario"):
1. A player at random is picked to predict the coin flip.
2. A player picked offers the prediction for the coin flip.
3. The coin is flipped and the result is provided.
4. A winner and loser is picked.
5. Offer to try it again.

Example-1 Coin Flip
Alternates: no
Exceptions: no failure condition.
Post conditions: one player wins and other
loses
Stakeholders: Nil

Example-2: Car Rental Application

Use Case Name: Release a Vehicle (to a Customer)
Description:
A customer arrives to acquire the vehicle and depart
for desired destination. The vehicle reservation
contract is signed and the vehicle is released to the
customer.
Actors: Front-Desk Clerk, Customer

Preconditions: Vehicle has been assigned to the
customer
Basic Flow ("Sunny Day Scenario"):
1. A customer comes to the office to acquire a vehicle.

2. The clerk locates the vehicle reservation contract by
means of the reservation number and/or customer name.
[Exception: Required vehicle type is not available due to late
arrivals.]
3. The customer signs the contract and the clerk gives the
keys to the vehicle.
4. The clerk then marks the contract active by entering the
vehicle release date (today's date) onto the vehicle reservation
contract. The use case terminates at this point.


•Exceptions ("Rainy Day Scenario"):

–Required vehicle type is not available due to late arrivals:
–Raised when the reserved vehicle is not available due to
late returns. The customer is informed of the situation and
told about the other vehicle types that are available. The
customer is offered an incentive to accept another vehicle
type. If the customer is not satisfied, the reservation is
cancelled without penalty charges. The customer either
accepts another vehicle type or cancels the reservation.

•Postconditions: The customer departs with the vehicle and the
reservation contract is marked active, or the reservation is
cancelled.
•Stakeholder: Reservation department

Example-3: Online Support Request
• Use Case Name : Support Request

• Description: Suppose a person generates a support
request on a website for electronic products.
• Actors
– Person who generates support request by clicking
button
– Customer Support Representative

• Preconditions:
– The person who generates the request needs to have an
active internet connection
– The website needs to be accessible by the customer
– The support agent needs to have an active internet
connection
• Basic Flow
1. The customer visits the support website
2. The customer clicks the “generate support ticket button”
3. The customer is taken to a page where they are told that
support will be present shortly.

4. The ticket is sent to the support department

5. A customer support representative takes hold of the
ticket
6. The customer support representative is sent to the
same page as the user where there is a chat box
7. The customer support representative provides the help
and support to the customer
8. The customer closes the chat window
9. The customer support representative closes the
support ticket and enters information about the
session.
10. The use case ends

• Alternates:
– The customer asks to be contacted over the phone
– The customer might request someone come to their
home to help them with the product
• Exception:
– The customer loses their internet connection between
the chat. They are then shown an error message.
– The customer service representative accidentally
closes the chat window, ending the support session.
The customer is informed that another representative
will be with them shortly.

• Level:
– Customer complaints
– General Feedback
• Trigger : customer clicks the button on the website to
generate a support ticket
• Stakeholders:
– The Customer Support Department – The whole
department’s purpose is to ensure customer satisfaction.
– The Sales Department – If the customer is unable to get
their problem fixed they might want to return the product,
which will be a loss for the sales department.

Example 4 - Buy something

User story
•The Requestor initiates a request and sends it to her or his Approver.
• The Approver checks that there is money in the budget, check the price of the
goods, completes the request for submission, and sends it to the Buyer.
•The Buyer checks the contents of storage, finding best vendor for goods.
•Authorizer: validate approver's signature . Buyer: complete request for
ordering, initiate PO with Vendor. Vendor: deliver goods to Receiving, get
receipt for delivery (out of scope of system under design). Receiver: register
delivery, send goods to Requestor. Requestor: mark request delivered.
• At any time prior to receiving goods, Requestor can change or cancel the
request. Canceling it removes it from any active processing. (delete from
system?) Reducing the price leaves it intact in process. Raising the price sends
it back to Approver.



Try it yourself !!!

• 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

Try it yourself !!!

• FAST CASH.
• Mary, taking her two daughters to the day care on the way to work, drives
up to the ATM, runs her card across the card reader, enters her PIN code,
selects FAST CASH, and enters $35 as the amount.
• The ATM issues a $20 and three $5 bills, plus a receipt showing her
account balance after the $35 is debited. The ATM resets its screens after
each transaction with FAST CASH, so that Mary can drive away and not
worry that the next driver will have access to her account.
• Mary likes FAST CASH because it avoids the many questions that slow
down the interaction. She comes to this particular ATM because it issues
$5 bills, which she uses to pay the day care, and she doesn't have to get
out of her car to use it.

Try it yourself !!!

Use case: Login.
•Upon presenting themselves, the user is asked to enter a
username and password. The system verifies that a submitter
exists for that username, and that the password corresponds to
that submitter. The user is then given access to all the other
submitter commands. If the username corresponds to a
submitter which is marked as an administrator then the user is
given access to all the submitter and administrator commands.
If the username does not exist, or if the password does not
match the username, then the user is rejected.

Things to remember
Reminder 1. A use case is a prose essay
Reminder 2. Make the use case easy to read (active
voice).
Reminder 3. Just one sentence form
Reminder 4. Include sub use cases
Reminder 5. Keep the GUI out
Reminder 6. Mandatory two endings

Reference book
• Alistair Cockburn, Writing Effective

Use Cases, Addison-Wesley, 2001.

Next Session will be

Object Oriented Analysis with
Domain Model

19CSE204 Object Oriented Programming: OO Analysis With Use Case

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

19CSE204 Object Oriented Programming: OO Analysis With Use Case

Uploaded by

Copyright:

Available Formats

19CSE204 Object oriented Programming

19CSE204 Object Oriented Programming

OO Analysis with Use case

Object Oriented Development

June 2021 Nalinadevi Kadiresan

Object Oriented Analysis

June 2021 Nalinadevi Kadiresan

What is Use case?

June 2021 Nalinadevi Kadiresan

Identifying use case

• Functional requirements are

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

History of Object Oriented

June 2021 Nalinadevi Kadiresan

Use Cases Do Not Require

June 2021 Nalinadevi Kadiresan

An example – Home security

Main sections of Use case

June 2021 Nalinadevi Kadiresan

Create Unique and Explanatory

June 2021 Nalinadevi Kadiresan

• The actors in the use case are the people or

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

• The preconditions are the conditions

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

• It is important to classify the use case with

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

• It is the state of the system after the

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

Example-1 Coin Flip

Description: A player at random offers a prediction of

June 2021 Nalinadevi Kadiresan

Example-1 Coin Flip

June 2021 Nalinadevi Kadiresan

Example-1 Coin Flip

June 2021 Nalinadevi Kadiresan

Example-2: Car Rental Application

Actors: Front-Desk Clerk, Customer

Basic Flow ("Sunny Day Scenario"):

1. A customer comes to the office to acquire a vehicle.

June 2021 Nalinadevi Kadiresan

•Exceptions ("Rainy Day Scenario"):

June 2021 Nalinadevi Kadiresan

Example-3: Online Support Request

• Use Case Name : Support Request

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

4. The ticket is sent to the support department

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan

Example 4 - Buy something

June 2021 Nalinadevi Kadiresan

June 2021 Nalinadevi Kadiresan