Object Oriented Analysis

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Object Oriented Analysis (OOA)
 First Technical activity performed as part of
OO Software Engineering.
 Involves the answering the following
questions when a new Product is developed:
• How is the proposed system amenable to OOSE?
• What are the relevant objects?
• How do the objects behave in context of the
system?
• How do we specify or model a problem in order
to implement an effective design?
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Principles to Develop OOA
model
 Model Information domain
 Describe model function
 Represent model behavior
 Partition models to expose greater detail

Thus, Early models represent essence of problem

while later models provide implementation details.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 OOA Model Development Steps
 Obtain basic user requirements; problem
statement
 Identify classes, define attributes, methods
 Specify class hierarchy
 Represent Object - Object relationships
 Model Object behavior

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 OOA Approaches
Booch Method - Micro & Macro Development.
 Identify classes and objects:
• Propose candidate objects,
• Conduct behavior analysis,
• Identify relevant scenarios,
• Define attributes and operations for each class
 Identify class and object semantics :
• Select scenarios and analyze,
• Assign responsibility
• Partition responsibilities to balance behavior,
• Enumerate object roles and responsibilities,
• Define operations to achieve responsibilities,
• Look for “collaborations” among objects.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Booch method - contd,
 Identify relationships among classes and
objects:
• Define dependencies between objects,
• describe role of each object,
• validate by “walking thru” scenarios.
 Conduct series of refinements:
• Produce appropriate diagrams for representation,
• Define class hierarchies,
• Perform clustering based on class commonality
 Implement classes and objects (i.e., complete
OO Analysis model).
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 OOA Approaches
Rumbaugh Method: Object Modeling
Technique (OMT) for Analysis, System
design and Object-level design.
 Analysis : creates 3 models
• Object model - Representation of classes,
objects, hierarchies, and relationships
• Functional model - A high-level DFD-like
information flow representation.
• Dynamic model - Representation of Object and
system behavior
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Outline of Rumbaugh Method
 Develop a statement of scope for problem.
 Build an Object model
• Identify classes,
• Define attributes and associations,
• Define object links,
• Organize classes using inheritance.
 Develop dynamic model
• Prepare scenarios,
• Define events and trace them,
• Draw event flow,
• State diagrams,
• Review behavior.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Outline of Rumbaugh Method
 Construct functional model for system
• Identify inputs and outputs
• Use data flow diagrams to represent flow,
• Develop Process Specifications for each
function,
• Specify constraints and optimization criteria.

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 9

 Domain Analysis Process
 A series of activities that begin with identification
of domain to be investigated and end with a
specification of the objects and classes that
characterize the domain(Domain Analysis model)
 Domains can range from avionics to banking, to
multimedia video games to medical applications.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Domain Analysis Procedure

 Goal: create software within the domain with

a high percentage of reusable components .
• Define the domain, then extract objects.
• Categorize the items extracted in a hierarchy.
• Collect sample of applications in the domain.
• Analyze each application in the sample.
• Develop an analysis model for the objects.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 OOA Process
 Define a set of system usage scenarios
• Identified from meeting with the customer.
• Identify the different roles that interact with the
system or product. These are called actors.
– Anything that communicates with system and is
external to it.
• Actors are different from user: user may play
part of several actors. e.g.:
– programmer, tester, monitor or troubleshooter .
• Define Use Cases: unambiguous narrative of
interaction between actor and system.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Generating Use Cases
 Begin with identifying actors and
determining how they interact with the
system.
• What are the main tasks performed by actors?
• What system info will actor use or produce?
• Will actor inform system about external changes?
• What info will actor delete from system?
• Is actor informed about unexpected changes?

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Use Case Example - Safe Home

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 17

 Use Case Example - Safe Home
 Owner looks at control panel - Is system
ready?
• If not ready, physically close windows & doors so
the ready indicator is present.
 Owner enters password;
• Password compared with valid password.
• If not correct, beep and reset.
• If correct, await further commands.
 Owner activates system.
• Mode AtHome or
• Mode Away
 System alarm light comes on.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 Identifying Object Classes

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Identifying Object Classes

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 20

 Subjects
and Sub-
systems

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 OOA model
with
Subject
references

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Safe Home Level 1 DFD

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 23

 OOA Process
 Class-Responsibility-Collaborator Modeling:
• A means of identifying and organizing classes
relevant to the system.
 Responsibilities:
• The attributes and operations that are relevant
for the class - anything a class knows or does.
 Collaborators:
• Those classes that are required to provide a class
with information needed to complete a
responsibility.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 CRC model index card:

 CRC model “tested” by conducting a

review driven by use cases.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 25
 Collaboration Example
 Responsibility: (As part of activation
procedure)
• Safe home Control Panel must determine if
any sensors are open - responsibility determine-
sensor-status.
 Collaborator:
• Sensor info is obtained from Sensor Object.
• For determine-sensor-status to be fulfilled,
Control Panel has to work in collaboration
with Sensor.

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 26

 Associations
 Collaborators suggest associations

Control Panel Sensor

Determine
sensor
status

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 27

 Associations & Operations
 Collaborations suggest operations

Control Panel Sensor

Determine
sensor
status
GetState ()

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 28

 OOA Process
 Guidelines for organizing classes and
assigning them responsibilities:
• System intelligence should be evenly
distributed.
• State responsibility as generally as possible.
• Share responsibilities among related classes.
– Will lead to inheritance.
• Information and related behavior should reside
in same class
• Information about one thing should be localized
in a single class.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 29
 The Object relationship model

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

 Object behavior model
 Evaluate use cases to determine interactions.
• Look at the states of each object
• Look at states of system as observed from outside
 Identify events that drive the interactions.
• Events are Boolean.
• Typically represent the completion of some
action.
 Create an event trace.
 Build a state-transition diagram.
 Review the object-behavior model to verify
accuracy and consistency.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 31
 Use Case Example - Safe Home
 Owner looks at control panel - Is system
ready?
• If not ready, physically close windows & doors so
the ready indicator is present.
 Owner enters password;
• Password compared with valid password.
• If not correct, beep and reset.
• If correct, await further commands.
 Owner activates system.
• Mode AtHome or
• Mode Away
 System alarm light comes on.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
 State Transition model

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 33

 Event Trace

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 34

 Partial Event Flow Diagram

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 35

 Summary
 OOA begins with use cases.
 Create object, functional and dynamic models
 Object Analysis
• model as objects, attributes and operations.
• Develop relationships among objects.
 Common characteristics
• Representation of classes and class hierarchies,
• Creation of object-relationship models, and
• Derivation of object-behavior models.

February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 36