CS 596 OODP: More Design

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

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

Finding Inheritance

Determine which classes are related via inheritance

Finding abstract classes

Determine class contracts

Finding Object Interaction

Divide responsibilities into subsystems

Designing interfaces of subsystems and classes

Refining the Design

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

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:

Different specialties in different development groups

If an existing product is to be used in the system, it may be regarded as a subsystem

In a distributed environment, a subsystem may be wanted at each logical node"

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

Write class name and state whether the class is abstract or concrete
List its immediate superclasses and subclasses

Provide class's position in the hierarchy and collaboration graphs

Describe the purpose of the class and its intended use

List each contract for which the class is a server

For each contract, list the responsibilities of the class that support it. Under each responsibility, write the signatures of the methods that implement the responsibility. Include a brief description and note the collaborations required. Don't neglect error conditions; specify the behavior of the method for all given inputs.

List the private responsibilities that have been defined

Include other relevant information:

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

Write the subsystem name at the top of the page

List all encapsulated classes and subsystems

Provide subsystems position in the hierarchy and collaboration graphs

Describe the purpose of the subsystem

List the contracts for which this subsystem is a server

For each contract, identify the class or subsystem to which the contract is delegated

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 objects	Model categories of objects
Model conceptual entities	Model external interfaces
Use a single term for each concept	Model 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

Contract	Clients
1. Access and modify the account balance	Balance Inquiry,
	Deposit Transaction,
	Funds Transfer,
	Withdrawal Transaction

2. Commit the results to the database	Transaction

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.