|
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
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)
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
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 are their tasks, responsibilities?
- 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
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
Exploratory
Phase
Classes
Finding
Classes
Noun
phrases in requirements specification or system description
- Disks
-
Printers
Airplanes
-
Model conceptual entities that form a cohesive abstraction
- Window
- File Bank
Account
-
If more than one word applies to a concept select the one that is most meaningful
Record
Your Candidate Classes
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
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
Responsibilities
- The
knowledge an object maintains
- The
actions an object can perform
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
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
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
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.
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
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
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?
Recording
Responsibilities
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
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?
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
Recording
Collaborations
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