Object Oriented Analysis

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Object Oriented Analysis (OOA)
Technical activity performed as part of OO Software Engineering.  Involves the answering the following questions when a new Product is developed: 
First

‡ 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
Information domain  Describe model function  Represent model behavior  Partition models to expose greater detail 
Model

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 classes, define attributes, methods class hierarchy Object - Object relationships 

Identify  Specify 

Represent  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.
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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).
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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.
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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 
Domain

Analysis

‡ Emphasize creating & using library of reusable classes. ‡ Identification, analysis and specification of common requirements from application domain, for reuse on multiple projects within that domain. 
Levels

of Abstraction for System Analysis:

‡ Enterprise - Entire business ‡ Business level - Workings of a particular activity ‡ Application level - Specific customer requirements.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

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

Generic OOA Model Components 
Static

components - Structural in nature, indicate characteristics that hold throughout the operational lifetime of the application.
‡ ‡ ‡ ‡ Static view of Semantic classes Static view of attributes Static view of relationships Static view of behaviors 

Dynamic

components: Focus on control and are sensitive to timing and event processing.
‡ Dynamic view of Communication, ‡ Dynamic view of Control and Time.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Generic OOA Model Components

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 14

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? enters password;

‡ If not ready, physically close windows & doors so the ready indicator is present. 
Owner

‡ Password compared with valid password. ‡ If not correct, beep and reset. ‡ If correct, await further commands. 
Owner

activates system. alarm light comes on.
Chapter 20 -- Assistance -- Senthil K Veluswamy

‡ Mode AtHome or ‡ Mode Away 
System

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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 Subsystems

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.
Chapter 20 -- Assistance -- Senthil K Veluswamy 25

February 21, 1999 -- R. A. Volz

Collaboration Example 
Responsibility:

(As part of activation

procedure)
‡ Safe home Control Panel must determine if any sensors are open - responsibility determinesensor-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
Sensor
Determine sensor status

Control Panel

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 27

Associations & Operations 
Collaborations

suggest operations
Sensor
Determine sensor status

Control Panel

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? enters password;

‡ If not ready, physically close windows & doors so the ready indicator is present. 
Owner

‡ Password compared with valid password. ‡ If not correct, beep and reset. ‡ If correct, await further commands. 
Owner

activates system. alarm light comes on.
Chapter 20 -- Assistance -- Senthil K Veluswamy

‡ Mode AtHome or ‡ Mode Away 
System

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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