SDSU CS 596 OODP
More Design

[To Lecture Notes Index]
San Diego State University -- This page last updated November 27, 1995
----------

Contents of More Design Lecture

  1. References
  2. Collaboration
    1. Finding Collaborations
    2. Common Collaboration Types
      1. The is-part-of relationship
      2. The has-knowledge-of relationship
      3. The depends-upon relationship
  3. Summary of the Exploratory Phase
    1. Booch's Process
    2. Rumbough's Process
  4. Analysis Phase
    1. Hierarchies
      1. Building Good Hierarchies
      2. Identifying Contracts
    2. Subsystems3
      1. Collaboration graphs
      2. Identifying Subsystems
    3. Protocols
      1. Refining Responsibilities
    4. Specifying the Design
  5. Review of Design Process

References


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

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

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)

Booch's Process


Identify classes and objects

Identify the semantics of classes and objects
Establish the meanings of classes and objects
Identify the relationships among classes and objects

Implement classes

Rumbough's Process


Write or obtain an initial description of the problem

Build an object model
Identify classes
Begin a data dictionary containing descriptions of classes and attributes
Add associations between classes
Add attributes for objects and links
Organize and simplify classes using inheritance
Test access paths using scenarios and iterate the above steps as necessary
Group classes into modules, based on close coupling and related function
Develop a dynamic model
Use scenarios to develop state diagrams for classes
Construct a functional model

Verify, iterate and refine the three models

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

Hierarchies

Hierarchy Graphs


Venn Diagrams

Building Good Hierarchies


Model a "kind-of" hierarchy



Multiple inheritance can be used in the design even if you use an implementation language with single inheritance.




Make sure that abstract classes do not inherit from concrete classes



Eliminate classes that do not add functionality

Factor common responsibilities as high as possible




Identifying Contracts


Contract[1]
Set of requests that a client can make of a server
Cohesive set of responsibilities that a client can depend on
Abstraction of a set of responsibilities of a class
Example: Account Class
Contract: Access and modify the account balance
Responsibilities:
Know the account balance
Accept deposits
Accept withdrawals
Identifying Contracts

Group responsibilities used by the same clients



Maximize the cohesiveness of classes
Contract of a class should make sense together

Minimize the number of contracts
Use inheritance
Set of classes all supporting a common contract should inherit the contract from a common superclass
Applying the Guidelines
Start defining contract at the top of the hierarchies
Name and number each contract
For each collaboration, determine which contract represents that collaboration

Contracts[2]
Another View

Precondition
The constraints under which a routine will function properly
"Push" may not be called if a stack is full
"Pop" may not be applied to an empty stack

Postcondition
Properties of the state resulting from a routine's execution
After a "push," the stack may not be empty, its top is the element just pushed, and its number of elements has been increased by one


Contract
A client must insure that the precondition holds before calling an operation
The server will guarantee that the postcondition holds

The contract forces a clear definition of whose responsibility it is to check every condition required for correct operation
Invariants and Correctness

Class invariant is a list of all properties of the instances of a class, which must be preserved by all operations


Example: Stack class invariants
0 <= number of elements in the stack <= max stack size


See [Gries, 1981] and [Meyer, 1990] for more details.

Subsystems[3]


Subsystems are groups of classes, or groups of classes and other subsystems, that collaborate among themselves to support a set of contracts

There is no conceptual difference between the responsibilities of a class and a subsystem of classes

The difference between a class and subsystem of classes is a matter of scale

A subsystem should be a good abstraction

There should be as little communication between different subsystems as possible

Top-Down, Bottom-Up
Large Systems


Most texts illustrate OO design "bottom-up"
Find objects
Determining responsibilities
Determine object collaboration
Find hierarchies
Determine subsystems

Large systems are designed "top-down"
Find top level subsystems
Determine subsystem responsibilities
Determine subsystem collaboration
Find hierarchies
Iterate above steps on each subsystem


Each level is built "bottom-up"

Levels are done "top-down"
Top-Down, Bottom-Up
Large Systems
Jacobson, 1991

"The subsystem division in small projects is normally made at the end of the analysis, when the architecture is clear. In larger projects, however, it often must be done earlier, in many cases even before the analysis model has been developed."

"In large systems it is often essential to develop the system in layers."

"For large projects there may be other criteria for subsystem division, for example:

Collaboration graphs



Subsystem Contracts

A subsystem contract consists of all class contracts that provide services to clients outside the system


Subsystem contracts can be extended

Subsystem Cards





Class Cards

Identifying Subsystems



All objects which have strong coupling should be placed in the same subsystem



There should be as little communication between different subsystems as possible



Does a set of classes make sense as an abstraction?



Can you name a group of classes?



Does a group of classes interact frequently?
Simplifying Interactions

Subsystems
Reduce complexity of a design
Provide coherent structure to the design



Minimize the number of collaborations a class has with other classes or subsystems
Reassign responsibilities or expand the knowledge of another class to create fewer collaborations
Create subsystem to reduce collaborations



Minimize the number of classes and subsystems to which a subsystem delegates



Minimize the number of different contracts supported by a class or a subsystem
Too many contracts in one subsystem can be a sign that the subsystem has too much intelligence


Protocols


Construct protocols for each class
Specify the signatures for the methods that each class will implement
Write a design specification for each class and subsystem

Write a design specification for each contract



Refining Responsibilities


Turn contracts into protocols

Account contract 1
Access and modify the account balance
Know the account balance
Accept deposits
Accept withdrawals
Protocols
balance() returns Fixed Point Number
deposit(Fixed Point Number)
withdraw(Fixed Point Number)


In general, private responsibilities represent designs notes to an implementor


Select operation names carefully
Don't use one name to mean two different things
Don't use two names for the same thing


Make protocols as generally useful as possible

Refining Responsibilities


Define reasonable defaults
First, define the most general message, one that allows clients to supply all possible required parameters
Next, provide default values for any parameter for which it is reasonable to do so
Finally, analyze how each client uses this general message. From that analysis, define a set of messages that allows clients to specify only some of the parameters, while relying on defaults for the others.

Refining Responsibilities

Define reasonable defaults


Example: Display of Drawing Elements
Parameters
Display device - printer or screen
Display region - clipping region
Drawing rule - how to combine new bits with old
Transformation - from element space to display space
Defaults
Display device - active window
Display region - entire medium
Drawing rule - over, completely replace old bits
Transformation - identity
Protocol
display()
display(Display Device)
display(Region)
display(Display Device, Region)
display(Display Device, Region, Drawing Rule)
display(Display Device, Region, Drawing Rule, Transformation)

Specifying the Design

Classes
Class: Drawing (Concrete)
Superclasses: Displayable Object
Subclasses: none
Hierarchy Graphs: page 5
Collaborations Graph: page 8
Description: This class represents the structure of ...
Contracts
1. Display itself
This contract is inherited from Displayable Object
2. Maintain the elements in a drawing
Know which elements are contained in the drawing
addElement (Drawing Element)
uses List
This method adds a drawing element ...
elementAt (Point) returns Drawing Element
uses List, Drawing Element (3)
This method returns the first drawing ...

Specifying the Design
Classes

behavioral constraints

implementation considerations

Specifying the Design
Subsystems

Subsystem: Drawing Subsystem
Classes: Control Point, Drawing, Drawing Element, Ellipse Element, Filled Element, Group Element, Line Element, Linear Element, Rectangle Element, Text Element
Collaborations Graphs: pages 6 and 8
Description: The Drawing subsystem is responsible for displaying, maintaining the contents of, a drawing. The Drawing Subsystem supports three contracts. Two are supported by ...
Contracts
1. Display itself
This contract is defined by Displayable Object, and supported by Drawing
Server: Drawing
2. Access and modify the contents of a drawing
Server: Drawing
3. Modify the attributes of a Drawing Element
Server: Control Point

Specifying the Design
Subsystems






Specifying the Design
Formalizing Contracts

Contract 3: Modify the attributes of a drawing element
Server: Control Point
Client: Selection Tool
Description: This contract allows modification of a drawing element through the manipulation of a control point associated with that element. The result of moving the control point is specified by the drawing element at the time the control point is created.





For each contract include:
Contract name and number
Server(s)
Clients
Description of the contract

Review of Design Process



Exploratory Phase
Finding the objects
Determining responsibilities
Finding collaborations

Analysis Phase
Finding hierarchies
Finding subsystems
Refining the design

Review of Design Process
Exploratory Phase

Finding the objects and classes

Review of Design Process
Exploratory Phase

Read and understand the specification.

Throughout the process use scenarios to explore possibilities. Record results on design cards.

Finding the objects and classes
Extract noun phrases from the specification and build list of nouns.

Look for nouns that may be hidden and add them to the list.

Identify candidate classes from the noun phrases by applying the following guidelines:
Model physical objectsModel categories of objects
Model conceptual entities Model external interfaces
Use a single term for each conceptModel the values of an object's attributes
Be wary of the use of adjectives
Identify candidates for abstract superclasses by grouping classes that share common attributes.

Use categories to look for classes that may be missing.

Write a short statement of the purpose of the class.
Review of Design Process
Exploratory Phase

Responsibilities

Find responsibilities using the following guidelines:
Recall the purpose of each class, as implied by its name and specified in the statement of purpose.
Extract responsibilities from the specification by looking for actions and information.
Identify responsibilities implied by the relationships between classes.

Assign responsibilities to classes using the following guidelines:
Evenly distribute system intelligence.
State responsibilities as generally as possible.
Keep behavior with related information.
Keep information about one thing in one place.
Share responsibilities among related classes.

Find responsibilities by looking for relationships between classes.
Use "is-kind-of" relationships to find inheritance relationships.
Use "is-analagous-to" relationships to find missing superclasses.
Use "is-part-of" relationships to find other missing classes.

Review of Design Process
Exploratory Phase

Collaborations

Find and list collaborations by examining the responsibilities associated with classes. Ask:
With whom does this class need to collaborate to fulfill its responsibilities?
Who needs to make use of the responsibilities defined for this class?

Identify additional collaborations by looking for these relationships between classes:
is-part-of
has-knowledge-of depends-upon

Discard classes if no classes collaborate with them, and they collaborate with no other classes.

Review of Design Process
Analysis Phase

Hierarchies

Account
ContractClients
1. Access and modify the account balanceBalance Inquiry,
Deposit Transaction,
Funds Transfer,
Withdrawal Transaction
2. Commit the results to the databaseTransaction

Review of Design Process
Analysis Phase

Hierarchies

Build hierarchy graphs that illustrate the inheritance relationships between classes.

Identify which classes are abstract and which are concrete.

Draw Venn diagrams representing the responsibilities shared between classes.

Construct class hierarchies using the following guidelines:
Model a "kind-of" hierarchy.
Factor common responsibilities as high as possible.
Make sure that abstract classes do not inherit from concrete classes.
Eliminate classes that do not add functionality.
Construct the contracts defined by each class using the following guidelines:
Group responsibilities that are used by the same clients.
Maximize the cohesiveness of classes.
Minimize the number of contracts per class.

Review of Design Process
Analysis Phase

Subsystems



Review of Design Process
Analysis Phase

Subsystems
Draw a complete collaborations graph of your system.

Identify possible subsystems within your design. Look for frequent and complex collaborations.
Classes in a subsystem should collaborate to support a small and strongly cohesive set of responsibilities.
Classes within a subsystem should be strongly interdependent.

Simplify the collaborations between and within subsystems.
Minimize the number of collaborations a class has with other classes or subsystems.
Minimize the number of classes and subsystems to which a subsystem delegates.
Minimize the number of different contracts supported by a class or a subsystem.

Review of Design Process
Analysis Phase

Protocols

Class: Drawing (Concrete)
Superclasses: Displayable Object
Subclasses: none
Hierarchy Graphs: page 5
Collaborations Graph: page 8
Description: This class represents the structure of ...
Contracts
1. Display itself
This contract is inherited from Displayable Object
2. Maintain the elements in a drawing
Know which elements are contained in the drawing
addElement (Drawing Element)
uses List
This method adds a drawing element ...

Review of Design Process
Analysis Phase

Protocols

Construct the protocols for each class. Refine the responsibilities into sets of signatures that maximize the usefulness of classes.
Use a single name for each conceptual operation, wherever it is found in the system.
Associate a single conceptual operation with each method name.
If classes fulfill the same specific responsibility, make this explicit in the inheritance hierarchy.
Make signatures generally useful.
Provide default values for as many parameters as reasonable.

Write a design specification for each class and subsystem.

Write a design specification for each contract.

----------