1

What is OO Design? OO Design is a process of invention, where

developers create the abstractions necessary to meet the system’s requirements

OO Design is independent of the programming language used to implement the design. However, using OO Language helps

Objects are independent and encapsulate state and representation information

System functionality is expressed in terms of object services

Shared data areas are eliminated. Objects communicate via message passing

2

Why OOD? OOD does not reduce development

time. In fact it may increase it! However, there is empirical

evidence that OOD facilitates the following activities: Reuse Maintenance Verification

3

What is Object Oriented Design? OOD is a set of principles and methods for

designing systems based on combining data and function into entities called objects

OOD Principles include Encapsulation Decomposition Design Patterns Hierarchical Relationships Defined decision making

4

OO Design OO systems are designed using a three

phase iterative process- Analysis- Design - Implementation

Successful software systems evolve over time, leading to iterative process, by evolving and refining each time through the process.

5

OO Analysis Definition ( Booch ):

OOA is a method of analysis that examines the requirements of the system from the perspective of classes and objects that are found in the vocabulary of the problem domain

Transform programming problem into a precise description of the tasks to be performed. Prior to analysis problem is usually vaguely understood.

OOA focuses on What needs to be done, not

How it needs to be done.

6

OO Analysis OOA is the input to Object Oriented Design (OOD) Quality of OOD is based on quality of OOA When defining OOA need to work with problem

domain expert. OOA provides a description of the problem The description must be complete, consistent,

readable, reviewable by diverse parties, and testable against the reality.

You should not pursue issues of class design or representation in the analysis phase

7

OO Analysis Identify functional and non-functional points of

the system Identify classes and objects( their roles and

responsibilities) from the vocabulary of problem domain

Functional points are observable and testable behaviors of a system

End use perspective: function points represent the activity of the system in response to an event

Analyst perspective: function points represent a behavior. The more function points, the greater system’s complexity

8

When OO Analysis is finished? When you have formal requirements analysis

document describing behavioral requirements Described non-functional requirements:

reliability, security, portability, and performance

Capture descriptions of behavior by using scenarios

Risk assessment: Identify known risks that may impact the design process. Better to document risks early than discover them latter.

9

Domain Analysis Identify objects that are common

to a particular system Study similar existing systems

(REUSE), benefiting from other projects that had to make similar design decisions. Do not reinvent the wheels!

10

OO Analysis: Scenario Planning Identify the function points of the

system and cluster them by the related behaviors.

If an object life cycle is essential to a scenario document using a finite state machine

Look for patterns in among developed scenarios

11

OO Analysis: Approaches Primary goal of OOA is to discover the

objects in the system specification How do we discover objects and classes

that form the vocabulary of system domain? Classical Behavior Analysis Domain Analysis Use case Analysis CRC cards Informal English description

12

Classical Analysis Derive classes from the requirements of

problem domain Derive candidate classes and objects from

the following sources: Tangible things Roles Events Interactions Structure Devices/Locations Organizational Units / Grouping

13

Behavioral Analysis Focus on dynamic behavior as the

primary source of classes and objects Emphasize responsibilities:

Actions object can perform Group things that have common

responsibilities Create hierarchies that embody general

responsibilities and subclasses that specialize their behavior

14

Domain Analysis Focuses on single specific application Seeks to identify the classes and

objects that are common to all applications within a specific domain

Examples: Patient record tracking, stock and bond trading, Compilers and etc.

Addresses the fact that there are very few unique kinds of software systems

15

Use Case Analysis Goal: Derive process of analysis in

a meaningful way Develop series of important

scenarios and identify objects, their responsibilities and how objects collaborate with other objects

16

CRC Cards Help to analyze scenarios CRC cards are 3x5 cards capturing:

Name of the class Class responsibilities Collaboration with other classes Software team walks through

scenarios and and assigns new responsibilities, updates existing, discovers new classes and etc

17

English description Radical alternative analysis method developed by

Abbott Process: Write a detailed English description of the

problem Underline nouns and verbs in the detailed English

description Nouns become candidate objects Verbs represent candidate operations upon the objects Benefits: Simple and forces analysis to work in the

vocabulary of problem space Problem: Does not scale well to handle large problems

18

OO Design A lot of gray areas between analysis phase and

design OOD emphasizes the proper and effective

structuring of a complex system: the system architecture.

Design process begins as soon as we have developed a reasonably complete model of the behavior of the system

Don’t design before analysis reaches closure Don’t delay the design trying to achieve perfect

analysis. When working in gray areas, both activities are done in parallel

19

OO products Tactical Policies

Error detection Memory management Exception Handling Data store managment

System Architecture Class and object structure Clustering of classes into class

categories

20

Object oriented programming Method of implementation in which

programs are organized as cooperative collections of objects, each of which represents an instance of some class.

Uses objects, not algorithms as its fundamental blocks

Each object is an instance of some class

Classes are related to each other