OBJECT ORIENTED

ANALYSIS
Object - Oriented Analysis..
 In analysis , we model the world by discovering the
classes and objects that form the vocabulary of the
problem domain.

 In design, we discover the abstractions and

mechanisms that provide the behavior that this
model require.
Approaches
 Classical Approaches
 Behavior Analysis
 Domain Analysis
 Use-case Analysis
 CRC cards
 Informal English Description
 Structured Analysis
Classical Approaches
 Shlaer and Mellor suggestion
 The candidate classes and objects comes from the
following.
 Tangible things – Cars, pressure sensors etc..
 Roles- Mother,Teacher,etc..
 Events-Landing, Request, etc..
 Interactions- Loan, meeting, etc..
Classical Approaches (cont’d)
 From the perspective of the database modeling,
Ross offers :
 People- Humans who carry out some function.
 Places- Areas set aside for people or things
 Things- Physical objects/group of objects that are tangible
 Organizations- Formally organized collection of people,
resources, facilities and capabilities having a defined
mission.
Classical Approaches (cont’d)
Coad and Yourdon suggest some sources of potential objects as :
 Structure – “Is-a” and “part of” relationships

 Other systems – External systems with which the application

interacts.
 Devices – Devices with which the application interacts.

 Events remembered – As historical event that must be recorded

 Roles Played – The different roles users play in interacting with

the application
 Locations – Physical locations , offices and sites important to
the applications.
 Organizational units – Groups to which users belong.
Behavior Analysis
 Focuses upon the dynamic behavior as the primary
source of classes and objects
 Classes can be formed based upon the groups of
objects that exhibit similar behavior
 Rubin and Goldberg approach:
 Classes and objects can be identify from system functions
 First understand what takes place in the system (system behavior).
 Next assign these behaviors to parts of the system
 Try to understand who initiates and who participates in these
behaviors.
Domain Analysis
 “An attempt to identify the objects, operations and
relationships that domain experts perceive to be important
about the domain”
 Seeks to identify the classes and objects that are common to
all applications within a given domain
 Eg patient record tracking, bond tracking, compilers etc..
 Moore’s and Bailin’s suggestion:
 Construct a generic model of the domain by consulting with domain
experts
 Examine existing systems within the domain and represent this
understanding in a common format
 Identify similarities and differences between the systems by consulting
with domain experts
 Refine the generic model to accommodate existing system.
 May be applied across similar applications (vertical)
and also to related parts of the same application
(horizontal)
 Eg. When starting to design a new patient monitoring
system, it is reasonable to survey the architecture of existing
systems to understand what key abstractions and
mechanisms were previously employed and to evaluate
which were useful and which were not.
 Also an accounting system must provide many
different kinds of reports.
 By considering these reports within the same
application as single domain, a domain analysis

 can lead the developer to an understanding of the key

abstractions and mechanisms that serve all the different
kinds of reports
Use-Case Analysis
 First formalized by Jacobson
 Jacobson defines a use-case as “a particular form or
pattern of usage, a scenario that begins with some user of
the system initiating some transaction or sequence of
interrelated events”
 Developing a Use Case
 What are the main tasks or functions that are performed by the
actor?
 What system information will the actor
acquire, produce or change?
 Will the actor have to inform the system about changes in the
external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
CRC Cards
 First proposed by Beck and Cunningham as tool for
teaching OOP
 It is 3x5 index card upon which the analyst writes
classname, responsibilities and collaborators
Why uses CRC cards?
 They are portable... No computers are
required so they can be used anywhere.
 They allow the (group) participants to
experience first hand how the system will work.
 They are a useful tool for teaching the object-
oriented paradigm.
 They can be used as a methodology them
selves or as a front end to a more formal
methodology such as Booch, Jacobson, etc
The CRC cards

ClassName

Responsibilities Collaborators
Informal English Description
 The first step in modeling a system in the object-
oriented paradigm is to identify the class in the
problem domain.

 The nouns are a good key to what class are in the

system, and the verbs show what there
responsibilities are going to be.
Structured analysis
 We start with an essential model of the system as
described by data flow diagrams.
 Can identify the classes and objects by analyzing
the individual data flow diagram.
 Ward Mellor suggest
 From a given data flow diagram candidate objects may be
derived from the following
 External entities
 Data stores
 Control stores