SDSU CS 535 Object-Oriented Programming
Fall Semester, 2003
OO Design Exploratory Phase
Previous    Lecture Notes Index    Next    
© 2003, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 13-Nov-03

Contents of Doc 16, OO Design Exploratory Phase



References


Wirfs-Brock, Designing Object-Oriented Software , chapters 1- 5



Doc 16, OO Design Exploratory Phase Slide # 2
Words of Wisdom

The best laid schemes o' mice and men often go astray
Robert Burns (1759-1796)

There is always something to upset the most careful of human calculations
Ihara Saikaku (1642-1693)



Doc 16, OO Design Exploratory Phase Slide # 3
Object-Oriented Design Process

Exploratory Phase

Who is on the team?
What are their tasks, responsibilities?
Who works with whom?

Analysis Phase

Who's related to whom?
Finding sub teams
Putting it all together


Doc 16, OO Design Exploratory Phase Slide # 4

Overview of Design

Exploratory Phase

What are the goals of the system?
What must the system accomplish?
What objects are required to model the system and accomplish the goals?

What does each object have to know in order to accomplish each goal it is involved with?
What steps toward accomplishing each goal is it responsible for?

With whom will each object collaborate in order to accomplish each of its responsibilities?
What is the nature of the objects' collaboration


Doc 16, OO Design Exploratory Phase Slide # 5
Overview of Design

Analysis Phase

Determine which classes are related via inheritance
Finding abstract classes
Determine class contracts

Divide responsibilities into subsystems
Designing interfaces of subsystems and classes

Construct protocols for each class
Produce a design specification for each class and subsystem
Write a design specification for each contract


Doc 16, OO Design Exploratory Phase Slide # 6

Exploratory Phase

Classes


Finding Classes


Noun phrases in requirements specification or system description




Disks
Printers Airplanes


Window
File Bank Account




Doc 16, OO Design Exploratory Phase Slide # 7

Record Your Candidate Classes




Doc 16, OO Design Exploratory Phase Slide # 8

Finding Abstract Classes


An abstract class springs from a set of classes that share a useful attribute. Look for common attributes in classes, as described by the requirement

Grouping related classes can identify candidates for abstract classes

Name the superclass that you feel each group represents

Record the superclass names


Doc 16, OO Design Exploratory Phase Slide # 9
If you can't name a group:
List the attributes shared by classes in the group and derive the name from those attributes
Divide groups into smaller, more clearly defined groups
If you still can't find a name, discard the group

Doc 16, OO Design Exploratory Phase Slide # 10

Responsibilities




General Guidelines

Consider public responsibilities, not private ones

Specify what gets done, not how it gets done

Keep responsibilities in general terms

Define responsibilities at an implementation-independent level

Keep all of a class's responsibilities at the same conceptual level

Doc 16, OO Design Exploratory Phase Slide # 11

Identifying Responsibilities


Requirements specification
Verbs indicate possible actions
Information indicates object responsibilities
The classes
What role does the class fill in the system?
Statement of purpose for class implies responsibilities

Walk-through the system
Imagine how the system will be used
What situations might occur?
Scenarios of using system


Doc 16, OO Design Exploratory Phase Slide # 12

Scenarios


Scenario
A sequence of events between the system and an outside agent, such as a user, a sensor, or another program
Outside agent is trying to perform some task

The collection of all possible scenarios specify all the existing ways to use the system

Normal case scenarios
Interactions without any unusual inputs or error conditions

Special case scenarios
Consider omitted input sequences, maximum and minimum values, and repeated values
Error case scenarios
Consider user error such as invalid data and failure to respond


Doc 16, OO Design Exploratory Phase Slide # 13
Scenarios

Identifying Scenarios

Read the requirement specification from user's perspective

Interview users of the system

Normal ATM Scenario
The ATM asks the user to insert a card; the user inserts a card.
The ATM accepts the card and reads its serial number.
The ATM requests the password; the user enters "1234."
The ATM verifies the serial number and password with the ATM consortium; the consortium checks it with the user's bank and notifies the ATM of acceptance.
The ATM asks the user to select the kind of transaction; the user selects "withdrawal."
The ATM asks the user for the amount of cash; the user enters "$100."
The ATM verifies that the amount is within predefined policy limits and asks the consortium to process the transaction; the consortium passes the request to the bank, which confirms the transaction and returns the new account balance.
The ATM dispenses cash and asks the user to take it; the user takes the cash.
The ATM asks whether the user wants to continue; the user indicates no.
The ATM prints a receipt, ejects the card and asks the user to take them; the user takes the receipt and the card.
The ATM asks a user to insert a card.

Special Case ATM Scenario

The ATM asks the user to insert a card; the user inserts a card.
The ATM accepts the card and reads its serial number.
The ATM requests the password; the user enters "9999."
The ATM verifies the serial number and password with the ATM consortium; the consortium checks it with the user's bank and notifies the ATM of rejection.
The ATM indicates a bad password and asks the user to reenter it; the user hits "cancel."
The ATM ejects the card and asks the user to take it; the user takes the card.
The ATM asks a user to insert a card.

Doc 16, OO Design Exploratory Phase Slide # 14

Assigning Responsibilities


Assign each responsibility to the class(es) it logically belongs to

Evenly Distribute System Intelligence

Intelligence:
What the system knows
Actions that can be performed
Impact on other parts of the system and users
Example: Personnel Record
Dumb version
A data structure holding name, age, salary, etc.
Smart version
An object that:
Matches security clearance with current project
Salary is in proper range
Health benefits change when person gets married


Doc 16, OO Design Exploratory Phase Slide # 15
Assigning Responsibilities

Evenly Distribute System Intelligence

The extremes:
A dictator with slaves
Dumb data structure with all intelligence in main program and few procedures
Class with no methods
Class with no fields
Object utopia
All objects have the same level of intelligence


Reality
Closer to utopia than to dictator with slaves

Reality check
Class with long list of responsibilities might indicate budding dictator


Doc 16, OO Design Exploratory Phase Slide # 16
Common Difficulties

Missing classes
A set of unassigned responsibilities may indicate a need for another class
Group related unassigned responsibilities into a new class

Arbitrary assignment
Sometimes a responsibility may seem to fit into two or more classes
Perform a walk-through the system with each choice
Ask others
Explore ramifications of each choice
If the requirements change then which choice seems better?


Doc 16, OO Design Exploratory Phase Slide # 17

Recording Responsibilities




Doc 16, OO Design Exploratory Phase Slide # 18

Collaboration


Represents requests from a client to a server in fulfillment of a client responsibility

Interaction between objects

Finding Collaborations


Examine class responsibilities for dependencies

For each responsibility:
Is class capable of fulfilling this responsibility?
If not, what does it need?
From what other class can it acquire what it needs?
For each class:
What does this class do or know?
What other classes need the result or information?
If class has no interactions, discard it


Doc 16, OO Design Exploratory Phase Slide # 19

Examining Relationships Between Classes


is-kind-of or is-a
Implies inheritance
Place common responsibilities in superclass

is-analogous-to
If class X is-analogous-to class Y then look for superclass
is-part-of or has-a
If class A is-part-of class B then there is no inheritance
Some negotiation between A and B for responsibilities may be needed
Example:
Assume A contains a list that B uses
Who sorts the list? A or B?


Doc 16, OO Design Exploratory Phase Slide # 20
Finding Collaborations

Examine scenarios
Interactions in the scenarios indicate collaboration


Common Collaboration Types

The is-part-of relationship


X is composed of Y's
Composite classes
Drawing is composed of drawing elements
Some distribution of responsibilities required
Container classes
Arrays, lists, sets, hash tables, etc.
Some have no interaction with elements

The has-knowledge-of relationship



The depends-upon relationship



Doc 16, OO Design Exploratory Phase Slide # 21
Recording Collaborations



Doc 16, OO Design Exploratory Phase Slide # 22

Summary of the Exploratory Phase


Find classes

Determine responsibilities (state and operations)

Determine collaborations (interactions)

Copyright ©, All rights reserved.
2003 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 13-Nov-03    Next