UNIT III

Object Oriented Analysis

Identifying use cases
 Analysis Definition
It is the process of transforming a problem
definition from an unclear set of facts and legend
into a logical statement of system’s requirements
Four Major tools for analysis
 Examination of existing system documentation
 Interviews
 Questionnaires
 Observation
Analysis is concerned with
 User of the system
 Identifying the objects
 Think about the events that change the state of the
objects
Designer adds detail to this mode
 Designing screen
 User interaction
 Database access
Why analysis is difficult ?
 3 common sources of requirement difficulties are
 Fuzzy description
 Incomplete requirements
 Unnecessary features
Fuzzy description
 Fuzzy description leads to fast response time.
 Fast response time leads to user dissatisfaction if
user’s interpretation is different from analysis
interpretation
Incomplete requirements
Reasons:
 Users forgetting to identify them

 High cost

 Politics within business

 Oversight by system developer

Unnecessary features
 Additional features affect performance,
complexity, stability, maintenance and support
costs of application
 Ex: if primary task is to select a single object
extending to multiple objects will cause difficulty.
Business object analysis
 The business object analysis is a process that
understands user requirements and then identifies
the classes that make up the business (system).
During the identification of classes, their
relationships too are understand
Use cases
 Use cases are the scenarios that explain how the
user uses the system. For example, withdraw is
one of the major transaction that occur in a
BANK, so withdraw can be identified as a use
case while designing a BANK system
User
 User may be a person using the system. For example,
customer of a Bank is a user who withdraws money from
BANK
 Since the system focuses in the users, it is developed by
interacting with the real users of it. After proper
interaction with users, a prototype of the system is
prepared. In this period the developer decides on the
business of the systems and begins modeling in a unified
approach
Use case driven OOA
 The OOA phase of UA uses actors and use cases
to describe the system from users perspective.
while understanding the problem in users
perspective, 2 major things are identified
 Actors:- external factors that interact with the
system
 Usecases :-scenarios that describe how actors use
the system
The OOA procedure is as follows
 Identify the actors
 Find out the users of the system. Example, a person acting the role of
Bank customer is a user in a bank
 Build up a simple business process model using UML activity diagram
 Build up the use-case scenario to explain the activities of the system
 What the users do with the system?
 A meaningful documentation regarding the system
 Prepare interaction diagrams
-determine the sequence
-develop collaboration diagrams
Classification-develop a static UML class
diagram

 Identify classes
 Identify relationships

 Identify attributes

 Identify methods

Iterate and refine with the help of the above said

procedure
 Identify
Develop use Develop classes Refine
Identify Relationships
Cases, activity Interaction And
Actors Attributes
diagrams diagrams iterate
Methods

Build
prototype
Steps to identify actors
 Actors: The role a user plays with respect to the
system. A user may play more than one role.
Actors need not be human, it can be external
system too.
 Example
 A member of a public library, may play the role
of volunteers at the help desk in the library
Difference between users and actors
USER ACTOR USE CASE
Can
play performs
radha the member Borrow books
role of

rama employee Order books

ramya volunteer Check IDs

Railroad paradox
 Gause and Weinberg gave the Railroad paradox which
describes identification of actors and their interaction
with the system
 When railroad were asked to establish new stop on the
schedule, they studied the requirements by sending
someone to the station at the designated time to see if
anyone was waiting for a train. of course, nobody was
there because no stop was scheduled, so the railroad
turned down the request because there was no demand
The conclusions given are
 The product is not satisfying the user
 So potential users will not use it
 They ask for better product
 So the request is denied
The candidates for actors can be found if the
answers to the following questions are established
 Who are the users of the system?
 Who will make the flow of change in the
system?
 How the users use the system?
 Does the system give a solution to the
specified problem?
 What are the external hard wares that use
the system?
Jacobson two-three rule for
identifying actors
 He suggests to start identifying 2 or 3 people who could act as actors in
the system.
 Example, identifying actors for a company that specialize in marketing
jewelry.
 First actor is the final customer- Regular customers who buy the
product
 Next is jewelry buyers for exclusive stores; they look for quality
 Next type of customers are Boutique owners who know what design
are in fashion
Use case model
 According to Jacobson, an use case is a sequence of transaction in a
system whose task is to yield result of measurable value to an
individual actor of the system
 Steps for finding the use case
 Find the responsibilities and functions that the actor should be able to
perform or that the system needs the actor to perform
 Name the use cases

 Describe the use cases briefly by applying terms with which the user is
familiar
Every use case has one main actor to initiate them. If a use case is not
initiated by any of the actors then the use case is called as abstract use
case
Use case from library
 Actors
 A member
 A circulation clerk
 A supplier

 Use cases
 Borrow books
 Get an interlibrary loan
 Return books
 Check library card
 Do research
 Read books, newspaper
A member takes book from library to
read at home.
Register at checkout desk for keeping
track
Depending on the record, different
courses of event flow
 Get an interlibrary loan
 When book is not present in library it is located in
another library, then it is ordered thru interlibrary
loan
 Return Books
 A member brings borrowed books back to the
library
Check library card
A member submits his/her card to the
clerk who checks the borrower’s record

Do research
A member comes to library to do research
thru books, journals, CD, etc and finds
information on the research subjects
Read books and newspaper
 A member comes to a library, a quiet place
to read books, newspaper or a magazine
Purchase supplies
Thesupplier provides books, journals and
newspaper purchased by the library
Naming a use case
 Use case names should be a general
description of the use case function
 Should be descriptive
 Should express what happens when use
case is performed
 Borrow books uses
Check library
extends card
uses

Interlibrary loan

Return books
Circulati
member on clerk

Do research

Read books, paper

supplier
Purchase supplies
Uses and extends
 User association
 Some of the sub flows occur in common
 Instead of describing these sub flows more
number of times, extract the common sub flow
and make it a use case of its own
 This new use case us used by other use cases
 This avoid redundancy
example
 Checking library card is common among borrow
books, return books and inter library loan
 To share common sequences in several, use cases
utilizes “uses” association
extends
 When one use case is similar to another use case
but does a bit more or specialized we use
“extends” association. It is like a sub class
 Ex: checking out of a book
 In the normal flow, it goes smoothly
 But if book is already checked out or the library
doesn’t have the requested book, we have to create
other use cases to handle the situation
 To solve this problem we use extends association
 Normal behavior is put in one use case and unusual
in another
 We utilize “extends association” to expand the
common behavior to fit special circumstances
 Borrow books Do research Purchase groups

uses
Borrow books Check library
extends card
uses

Interlibrary loan

Return books
Circulati
member on clerk

Do research

Read books, paper

supplier
Purchase supplies
Developing effective documentation
 A document serves as a communication
vehicle among the projects team members

 So it is an important factor in making a

decision about committing resources
documentation
 In analysis phase determines what the system
must do
 In design phase decides how the system works
 Some important points for documentation are:
 How document is going to be used?
 What is the objective of the document?
 What is the management view of the document?
 Who are the readers of the document?
Organization conventions for documentation
 Documentation depends on the organization rules
and regulations
 Documentation should be clear and elaborate as
little documentation generates disaster
Guidelines for developing effective
documentation(Bell & Evans)
 Common cover
 All the documents should have a common cover
sheet for identifying the document, the current
version and individual responsible for the content
 80-20 rule
 80% of work can be done with 20% of documentation
 The 20% is easily accessible but the rest is available to
those who need to know
 Familiar vocabulary
 The vocabulary of the document must be easily
understood by the readers.
 Make the document as short as possible
 The document must look like a manual

(Document Name)
For
(product)
(version number)
Responsible Individual
Name
Title
CASE STUDY Analyzing the vianet Bank ATM
 Background
 The description of Bank ATM systems requirements
1. The client must be able to deposit and withdraw
amount using touch screen at the ATM
The date, time, transaction type, amount, account
balance must be recorded for each transaction of
the client
2. Two types of account are present
a. Checking account/current account

b. Savings account
3. We can access the Bank account using a PIN code
consisting of 4 integer digits between 0 and 9
4. One PIN code allows access to all accounts held by
bank client
5. Negative balance is not allowed for both savings
and current a/c
If the withdrawal amount is more than the balance in
the checking a/c the system automatically
withdraws from saving account
If the balance on the saving a/c is less than the with
drawal amount, the transaction will stop and the
client will be notified
Identifying Actors and use cases for Bank ATM system
 The following use cases are created by system requirements,
examination of existing system, documentation, interviews,
questionnaire, observation etc
 1. Bank ATM transaction-steps
 Insert ATM card

 Perform approval process

 Ask type of transaction

 Enter type of transaction

 Perform type of transaction

 Eject card

 Request take card

 Take card
 Insert ATM
Activity Diagram card
Password not
Enter password
accepted

Password
accepted

Select type
of transaction

More
Perform the transactions
transactions

No more
transactions

Take the card

Approval process
 The client enters a PIN code consisting of 4 digits.
If it is valid, client’s account become available
 The steps are
 Request password
 Enter password
 Verify password
 3. Invalid PIN
 If the PIN is not valid, an appropriate message is displayed to client.
This extends approval process.
 4. Deposit Amount
 After approval process, the client requests to deposit money to an
account
 The client selects the account for depositing the money and enters the
amount
 The system creates the records of transaction

 The steps are

 Request account type

 Request deposit amount

 Enter deposit amount

 Put the cheque or cash in envelope and insert into ATM

 Deposit savings
 The client selects the saving a/c for which a
deposit is made
 Deposit checking
 Withdraw amount
 The steps are
 Request a/c type
 Request withdrawal amount
 Enter withdrawal amount
 Verify sufficient funds
 Eject cash
Transaction use cases
Bank ATM <<uses>>
Approval
transactions process

<<extends>> <<extends>>
<<extends>>

Checking transaction Invalid pin

History

<<extends>>
<<extends>>

Saving transaction Deposit Withdraw

history amount amount
 5. Deposit savings
 The client selects the saving account for which a
deposit is made. All the other steps are similar to
previous
 System creates a record of transaction. This use case
extends the deposit amount use case
 Deposit checking
 The client selects the checking account for which a
deposit is made. All the other steps are similar to
deposit amount. The system also creates a record of
transaction. This use case extends deposit amount use
case
Checking amount use cases
Deposit
Amount
Withdraw
amount
<<extends>>

<<extends>>
Deposit
savings
Withdraw
savings

<<extends>>

withdraw
Savings
denied
 7. Withdraw amount
 After approval process the client interacts with the system to withdraw
money from account
 It extends the BANK ATM transaction use case
 The steps are
 Request account type

 Request withdrawal amount

 Enter withdrawal amount

 Verify sufficient funds

 Eject cash


 Withdraw checking
 The client tries to withdraw amount from his
checking amount.
 When the amount is less than or equal to the
balance the transaction is performed
 The system creates a record of transaction
 Withdraw saving denied
 During withdrawal if the amount is more than the
balance the transaction us halted, and a message
is displayed
 Checking transaction history
 The client request a history of transactions for a
checking account. The system displays the
transaction history
 Saving transaction history
 The client request a history of transaction for a
saving account
The Bank ATM System Packages
It is better to breakdown the use cases into
packages
The various scenarios in the bank system
are
Checking account
Savings account
General bank transactions