Unit-3

ANALYSIS
 Problem Analysis
• “ The goal of object oriented analysis is to
understand the domain of the problem and
system responsibilities in order to meet the
user’s requirements.”
• The OOA process doesn’t begin with a
concern for objects. Rather, it begins with an
understanding of the manner in which the
system will be used-by the people, if the
system is human-interactive.
 Problem Domain Classes
• Object Oriented domain analysis is the
identification, analysis, and specification of
common requirements from a specific
application domain, typically for reuse on
multiple projects within that application
domain.
• Domain analysis is performed when an
organization wants to create a library of
reusable classes (components) that will be
broadly applicable to an entire category of
applications.
 Technical Literature
Existing applications
Source of Domain
Customer surveys Domain
Domain Analysis Analysis
Knowledge Expert advice
Model
Current/future
Requirements

The domain analysis model will serve as the basis for design
and construction of the domain objects. These domain
objects can be used to create a new application.
 Analysis Process
• Elicit customer requirements for the system
• Identify scenarios or use-cases
• Select classes and objects using basic
requirements as a guide
• Identify attributes and operations for each
system object
• Build an analysis model
• Review the OO analysis model against use-
cases or scenarios
 Problem Statement
• Analysis begins with a problem statement generated
by clients and the developers.
• The problem statement should state what is to be
done and not how it is to be done.
• The user should avoid describing system internals, as
this restricts implementation flexibility.
• The statement maybe incomplete or informal;
analysis makes it more precise and exposes
ambiguities and inconsistencies.
 Object Modeling
• The first step in analyzing the requirements is
to construct an object model. It shows the
static data structure of the real world system
and organizes it into workable pieces.
• Information for the object model comes from
the problem statement, expert knowledge of
the application domain, and general
knowledge of the real world.
• The following steps are performed in
constructing an object model:-
– Identify objects and classes:- from the detailed
statement of the problem, classes and objects can
be a visible thing, physical entities, concepts as
seating assignments, materials, events,
interaction, places, organization, devices etc.
Discard unnecessary and incorrect classes, if two
classes express the same information, the most
descriptive name should be kept. Names that
primarily describe individual objects should be
restated as attributes. The name of a class should
reflect its intrinsic nature and not a role that
plays in an association.
– Preparing a Data Dictionary:- From detail
statement of the problem
– (1) write a paragraph describing each object class
– (2) describe association, attributes and operations
in each class
– (3) describe the scope of the class within the
current problem, including any assumptions or
restrictions on its use.
• Identifying Associations:- Identify associations
between classes. Any dependency between two or
more classes is an association.
• If one of the classes in the association has been
eliminated, then the association must be eliminated
or restated in terms of other classes. Names should
define the association. Specify multiplicity but keep it
flexible as it often changes during analysis. Add any
missing associations that are discovered. Add role
names where appropriate.
– Identifying attributes:- Attributes are properties of
individual objects. An instance can have one value
for any attribute. Composite attribute should be
divided into smaller fields. Eliminate the
unnecessary and incorrect attributes. If the value
of an attribute depends on a particular context,
then consider restating the attribute as a qualifier.
If an attribute describes the internal state of an
object that is invisible outside the object, then
eliminate it from the analysis.
If a property depends on the presence of a link,
then the property is an attribute of the link and
not of a related object.
– Refining with Inheritance:- The next step is to
organize classes by using inheritance to share
common structure. Either the common aspects of
existing classes can be generalized into a super-
class, or existing classes can be refined into
specialized sub-classes. Avoid excessive refinement.
When the same association name appears more
than once with substantially the same meaning, try
to generalize the associated classes.
– Identify Operations to be included in a class:-
Behavior is how an object acts and reacts in terms
of its state changes and message passing.
 Operations that are included in a class can be:-
Modifier:- alters the state of an object
Selector:- Accesses the state of an object but
does not alter the state.
Iterator:- Accessing parts of an object in some
well defined order.
Constructor:- creates an object and/or
initializes its state.
Destructor:- Frees the state of an object
Create, update, retrieve, delete include all the
operations for all the classes.
• Testing Access Paths:- Trace access path through the
object model diagram to see if they yield sensible
results. If something that seems simple in the real
world appears complex in the model, it indicates
error in the diagram.
• Iterating Object modeling:- An object model is rarely
correct after a single pass. The entire software
development process is one of continual iteration;
different parts of a model are often at different
stages of completion. Some refinements can only
come after the dynamic and functional models are
completed.
• Grouping Classes into modules:- The last step
of object modeling is to group classes into
sheets and models, diagrams may be divided
into sheets of uniform size for convenience in
drawing and viewing.
 Use-Case driven Object Oriented
Analysis
• A Use Case diagram is a diagram that help
system analyst to discover the requirements of
the target system from the user’s perspective.
• Use cases represent typical sets of scenarios
that help to structure, relate and understand
the essential requirements.
• It provides graphical description of the users of
a system and what kinds of interactions to
expect within that system.
 Elements of Use Case diagram
• Actors:- Actor is direct external user of system
• An actor portrays any entity (or entities) that
performs certain roles in a given system. An actor
in a use case diagram interacts with a use case.

• Actors are entities which require help from the

system to perform their task or are needed to
execute the system’s functions.
• Primary Actor:- main users or entities for which the
system is designed, deriving benefits from it directly
• Actor has a single well defined purpose
• Primary actors are completely outside the system
and derive the system requirements.
• Secondary actors:- users or entities that supervise,
operate or manage the system. They play a
supporting role to facilitate the primary actors to
achieve their goals.
• An actor may be : people, computer h/w and
devices, external systems
• Use Case: A Use Case is a visual
representation of a distinct business
functionality in a system. Each use case is a
sequence of transactions performed by the
system.
• It is interaction of actor with system
• It is a coherent piece of functionality that a
system can provide by interacting with actors
Use Case Name
• System Boundary:- It defines the scope of the
system. A system cannot have infinite
functionality. It defines the limits of the
system.
•
• Association:- This is used to show the
participation of actor in use case; how an
actor instance communicates with process
instance.
 Relationships in Use Cases
• A relationship between two use cases is basically a
dependency between the two use cases. This reuse
of an existing use case using different types of
relationships reduces the overall effort required in
defining use cases in a system.
(1)Include:- includes one use case within the behavior
sequence of another use case
(2) Include is used when two or more use cases share
some common portion in the flow of events. This
common portion is then grouped and extracted to
form a inclusion use case to be shared among two or
more use cases.
• The stereotype << include >> identifies the
relationship include. The arrowhead points toward
child use case (included use case) which is included
in parent use case (including use case).
• For ex- in Library management system, verify library
card is common use case for both Issue journal and
Issue book use case.
<<include>>
Issue Journal

Verify Library Card

Issue Book <<include>>

(2) Extend:-
In an extend relationship between two use cases, the
child use case adds to the existing functionality and
characteristics of the parent use case.

Withdraw money

<<extend>>

Excess money

Under normal scenario the money will be withdrawn

from the account and if the amount is more than the
existing balance the excess money use case will be
executed.
 Extend
• Adds incremental behavior to a use case
• It represents the frequent situation in which some initial
capability is defined.
• And later features are added modularly
• Extend is a directed relationship that specifies how and when
the behavior defined in usually supplementary (optional)
extending use case can be inserted into the behavior defined
in the extended use case.
• Extended use case is meaningful on its own, it is independent
of the extending use case. Extending use case typically defines
optional behavior that is not necessarily meaningful by itself.
The extend relationship is owned by the extending use case.
The same extending use case can extend more than one use
case, and extending use case may itself be extended.
• Extend relationship is shown as a dashed line with an open
arrowhead directed from the extending use case to the
extended (base) use case. The arrow is labeled with the keyword
«extend».
• In most cases extend relationship has codition attached.
• The condition of the extend relationship as well as the references
to the extension points are optionally shown in a comment
note attached to the corresponding extend relationship.
(3) Generalizations:- It is also a parent-child relationship
between use cases. The child use case in the generalization
relationship has the underlying business process meaning, but
is an enhancement of the parent use case.
Child use cases specialize the parent by inserting additional steps
or by refining steps

Pay Bill

By Post By Internet
Difference between generalization and
Extend
• When we establish a generalization
relationship between use cases, this implies
that the parent use case can be replaced by the
child use case without breaking the business
flow.
• An Extend relationship between use cases
implies that the parent use case cannot be
replaced by the child use case. It represent the
exceptional cases.
 Guidelines for use case models
• Use case identify the functionality of the system and organize it
according to the perspective of users.
• Guidelines for constructing use cases:
• First determine the system boundary
• Ensure that actors are focused
– Each actor should have single coherent purpose
– If real world object embodies multiple purposes, capture them with
separate actors
– Example: owner of PC can install software, set up database, send email
– These functions differ greatly in their impact on computer system and
potential for system damage
– So, they can be broken into 3 actors as
• System administrator
• Database administrator
• Computer user
• Identify actors by following questions:
– Who will use the main functionality of the system?
– Who will need to maintain, administrate, and keep
the system working?
– Who will need support from the system to do their
daily tasks?
– What other systems does the system need to
interact?
– Who has an interest in the results produced?
• Each use case must provide value to users

– Use case should represent a complete transaction that

provides value to users and should not be defined too
narrowly
– Example: ‘Dial a telephone number’ is not a good use case
for telephone system
– It is a part of a use case ‘make telephone call’
– ‘make telephone call’ includes placing a call, talking and
terminating a call
• Identify Use Cases by following questions:-
– Which functions does the actor requires from the
system?
– What does the actor need to do?
– What input/output does the system need?
– Where does this input/output come from or go to?

Specify the system boundary that limits the system

functioning.
• Relate use cases with actors:
– Every use case should have at least one actor
– Every actor should participate in at least one use case
• Use cases are informal
• Use cases can be structured
– For large systems use cases can be built out of smaller
fragment using relationships
• A well structured use case also describes the pre
condition, post condition, exceptions. And these
extra elements are used to make test cases when
performing the testing.
• Use Case diagram for library management
system Library Management System

Issue Book
Librarian

Return Book
Student
 Use case Diagram for a vending machine
Vending machine

Buy beverage

Customer
Perform
scheduled
maintenances
Repair technician
Make repairs

Load items
Stock Clerk
• System Startup Use Case
• The system is started up when the operator turns the
operator switch to the "on" position. The operator will be
asked to enter the amount of money currently in the cash
dispenser, and a connection to the bank will be established.
Then the servicing of customers can begin.
• System Shutdown Use Case
• The system is shut down when the operator makes sure that
no customer is using the machine, and then turns the
operator switch to the "off" position. The connection to the
bank will be shut down. Then the operator is free to remove
deposited envelopes, replenish cash and paper, etc.
• Session Use Case

• A session is started when a customer inserts an ATM card into

the card reader slot of the machine.
• The ATM pulls the card into the machine and reads it.
• If the reader cannot read the card due to improper insertion
or a damaged stripe, the card is ejected, an error screen is
displayed, and the session is aborted.
• The customer is asked to enter his/her PIN, and is then
allowed to perform one or more transactions, choosing from
a menu of possible types of transaction in each case.
• After each transaction, the customer is asked whether he/she
would like to perform another.
• When the customer is through performing transactions, the
card is ejected from the machine and the session ends.
• If a transaction is aborted due to too many invalid PIN
entries, the session is also aborted, with the card being
retained in the machine.
• The customer may abort the session by pressing the Cancel
key when entering a PIN or choosing a transaction type.
• Transaction Use Case
• Note: Transaction is an abstract generalization. Each specific
concrete type of transaction implements certain operations in the
appropriate way. The flow of events given here describes the
behavior common to all types of transaction. The flows of events for
the individual types of transaction (withdrawal, deposit, transfer,
inquiry) give the features that are specific to that type of
transaction.
• A transaction use case is started within a session when the
customer chooses a transaction type from a menu of options. The
customer will be asked to furnish appropriate details (e.g.
account(s) involved, amount). The transaction will then be sent to
the bank, along with information from the customer's card and the
PIN the customer entered.
• If the bank approves the transaction, any steps needed to complete
the transaction (e.g. dispensing cash or accepting an envelope) will
be performed, and then a receipt will be printed. Then the customer
will be asked whether he/she wishes to do another transaction.

• If the bank reports that the customer's PIN is invalid, the Invalid PIN
extension will be performed and then an attempt will be made to
continue the transaction. If the customer's card is retained due to
too many invalid PINs, the transaction will be aborted, and the
customer will not be offered the option of doing another.
• If a transaction is cancelled by the customer, or fails for any reason
other than repeated entries of an invalid PIN, a screen will be
displayed informing the customer of the reason for the failure of the
transaction, and then the customer will be offered the opportunity
to do another.
• The customer may cancel a transaction by
pressing the Cancel key as described for each
individual type of transaction below.
• All messages to the bank and responses back
are recorded in the ATM's log.
• Withdrawal Transaction Use Case
• A withdrawal transaction asks the customer to choose a type of
account to withdraw from (e.g. checking) from a menu of possible
accounts, and to choose a dollar amount from a menu of possible
amounts. The system verifies that it has sufficient money on hand
to satisfy the request before sending the transaction to the bank. (If
not, the customer is informed and asked to enter a different
amount.) If the transaction is approved by the bank, the
appropriate amount of cash is dispensed by the machine before it
issues a receipt. (The dispensing of cash is also recorded in the
ATM's log.)
• A withdrawal transaction can be cancelled by the customer pressing
the Cancel key any time prior to choosing the dollar amount.
• Deposit Transaction Use Case

• A deposit transaction asks the customer to choose a type of

account to deposit to (e.g. checking) from a menu of possible
accounts, and to type in a dollar amount on the keyboard.
• The transaction is initially sent to the bank to verify that the ATM
can accept a deposit from this customer to this account. If the
transaction is approved, the machine accepts an envelope from the
customer containing cash and/or checks before it issues a receipt.
• Once the envelope has been received, a second message is sent to
the bank, to confirm that the bank can credit the customer's
account - contingent on manual verification of the deposit envelope
contents by an operator later. (The receipt of an envelope is also
recorded in the ATM's log.)
• A deposit transaction can be cancelled by the customer
pressing the Cancel key any time prior to inserting the
envelope containing the deposit. The transaction is
automatically cancelled if the customer fails to insert the
envelope containing the deposit within a reasonable period of
time after being asked to do so
• Transfer Transaction Use Case
• A transfer transaction asks the customer to choose a type of
account to transfer from (e.g. checking) from a menu of
possible accounts, to choose a different account to transfer
to, and to type in a dollar amount on the keyboard. No
further action is required once the transaction is approved by
the bank before printing the receipt.
• A transfer transaction can be cancelled by the customer
pressing the Cancel key any time prior to entering a dollar
amount
• Inquiry Transaction Use Case
• An inquiry transaction asks the customer to choose a type of
account to inquire about from a menu of possible accounts.
No further action is required once the transaction is approved
by the bank before printing the receipt.
• An inquiry transaction can be cancelled by the customer
pressing the Cancel key any time prior to choosing the
account to inquire about.
• Invalid PIN Extension
• An invalid PIN extension is started from within a transaction when
the bank reports that the customer's transaction is disapproved due
to an invalid PIN. The customer is required to re-enter the PIN and
the original request is sent to the bank again. If the bank now
approves the transaction, or disapproves it for some other reason,
the original use case is continued; otherwise the process of re-
entering the PIN is repeated. Once the PIN is successfully re-
entered, it is used for both the current transaction and all
subsequent transactions in the session.
• If the customer fails three times to enter the
correct PIN, the card is permanently retained, a
screen is displayed informing the customer of
this and suggesting he/she contact the bank,
and the entire customer session is aborted.
• If the customer presses Cancel instead of re-
entering a PIN, the original transaction is
cancelled.
Use case for ATM
Bank ATM Transactions and Customer Authentication Use Cases
Example.
Bank ATM Maintenance, Repair, Diagnostics Use
Cases Example.
 Documenting Use Case
• Use Case name: name of use case
• Use Case Id: Unique identifier of the use case
• Super use case: name of parent use case
• Actor: name of actor participating in use case
• Preconditions: constraints to be satisfied
before use case is invoked
• Post conditions: condition will be established
after the use case
• Flow of events: step by step description of the
interaction between actor and the system
• Exceptions: exceptions that may occur
• Non-behavioral requirements: hardware and
software requirements
• Assumptions: assumptions made about the
use case
• Source: references and materials used in
developing use case.
 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

55
 Example- Money Withdraw
• Use Case: Withdraw Money
• Author: ZB
• Date: 1-OCT-2004
• 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.
• Cross References: R1.1, R1.2, R7

56
 Example- Money Withdraw (cont.)
• 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

57
 Example- Money Withdraw (cont.)

 Typical Course of events:

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

58
 Example- Money Withdraw (cont.)
• Alternative flow of events:
– Step 3: Customer authorization failed. Display an error
message, cancel the transaction and eject the card/ re-
enter the pin.
– 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 cancel the transaction.

• Exceptional flow of events:
– Power failure in the process of the transaction before step
9, cancel the transaction and eject the card

59
 Example- Money Withdraw (cont.)
 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 ?

60
 Creating Class diagram by using Use Case
Analysis method
• Use Case diagram contains different
functionalities of the system from user’s point of
view. These functionalities can be directly
converted to class diagram.
• The entities or the actors that are participating in
a use case are modeled as classes.
• Relationship between different use cases and
actors represents the association among classes.
• It involves the following steps:-
– Determine the goal of use case: Identify the functions
– Identify Entities or Actors
– Specify Entities as Classes and their features as
Attributes of the Classes in object modeling
– Specify reference between entities as relationships
between Classes
– Identify Collaboration between Use cases and Entities:
classes that will be performing specific functions,
specified in use case
– Specify collaboration as Operation of Classes
– Test Use Case Entity diagram and the Class diagram
 Class-Responsibility-Collaborator Modeling

• A CRC model is a collection of standard index

cards that represent classes. A CRC Card:-
Class Name:
Class Type: ( device, role, event)
Class Characteristics:
Responsibilities: Collaborations:
(Attributes and operations (Classes required to provide
relevant for the class) a class with the information
needed to complete a
responsibility)
• Reviewing the CRC model:-
– Review team are given the CRC model index cards
– All Use case scenarios and corresponding use case
diagrams should be organized into categories.
– The review leader reads the use case. When an object
is encountered, a token is passed to the person
holding the corresponding class index card.
– The holder of the card describes the responsibilities
noted on the card. The team determines whether one
(or more) of the responsibilities satisfies the use-case
requirement.
– Modifications are made to the cards if required
– This cycle continues until the use-case is finished.
When all use-cases have been reviewed, OOA
continues.
 Online Shopping system
• System Requirements
• Allow customers to view products from their home
• Allow customers to make purchases and receive products from their
home
• Customers are able to make payments from credit card
• Product descriptions must be easily maintained and updated by
store employees
• Fast distribution of product descriptions so that customers have
accurate portrayal
• Inexpensive distribution of product descriptions
• Fast customer ordering system that is as simple as possible
• Information Requirements
• Information needed to created order form
• Product selections
• Customer information
• Billing information (credit card)
• Shipping information (if different from
customer)