SDSU CS 596 OODP
Classes and Responsibilities

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

Contents of Classes and Responsibilities Lecture

  1. References
  2. Overview of Design
  3. Exploratory Phase
    1. Classes
      1. Finding Classes
      2. Record Your Candidate Classes
      3. Finding Abstract Classes
      4. ATM Requirements Specification
    2. Responsibilities
      1. Identifying Responsibilities
      2. Scenarios5
      3. Assigning Responsibilities
      4. Examining Relationships Between Classes
      5. Recording Responsibilities

References


Designing Object-Oriented Software, Wirfs-Brock, chapters 1- 4
Computation as Simulation
Procedure programming consists of procedures acting on data



Object-oriented programming consists of objects interacting



Main() creates web of objects and starts them interacting



Object-Oriented Design Process


Exploratory Phase
Who is on the team? (Finding the objects - ch 3)
What are their tasks, responsibilities? (ch 4)
Who works with whom? (ch 5)

Analysis Phase
Who's related to whom? (ch 6)
Finding sub teams (ch 7)
Putting it all together (ch 8)
Object-Oriented Analysis

Understand the requirements for the product

Specify the functionality of the system

Identify the logical objects in the system


Object-Oriented Design
Fully specify the objects

Identify additional objects
Analysis versus Design

Analysis identifies objects and subsystems. This involves the basic behavior of objects and an understanding of how they interact. Design fully specifies the objects. Design involves the identifying behavior at a more detailed level than analysis. Objects are also discovered in design. Both analysis and design identify objects and specify behavior of the objects. Thus, the difference between the two is not always clear-cut. As Edward Berard states:

"The good news is that the chasm between analysis and design is very narrow."

"The bad news is it is more difficult to separate analysis concerns from design concerns. The thinking, tools, techniques, and guidelines have much more in common, than they have differences."

Overview of Design

Exploratory Phase

* Who is on the team?
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?
* Who works with whom?
With whom will each object collaborate in order to accomplish each of its responsibilities?
What is the nature of the objects' collaboration

These activities have an analysis flavor to them. Note the link between the goals of the system and its objects. The state and behavior of an object are derived, in theory, from the goals. ParcPlace has a design tool that tracks this relationship. Select a goal, and the tool will list all the objects required for that goal. Conversely, given any object, the tool will show you the goal(s) it helps accomplish.
Clients, Servers, Contracts

Object collaboration:
One object requests a service of another object
This is normally done by sending a message

Client
The object making the request
Server
The object receiving the request
Contract
Describes the ways in which a given client can interact with a given server
Overview of Design
Analysis Phase

* Who's related to whom?
Determine which classes are related via inheritance
Finding abstract classes
Determine class contracts

* Finding sub teams
Divide responsibilities into subsystems
Designing interfaces of subsystems and classes


* Putting it all together
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

Look at these phrases. Some will be obvious classes, some will be obvious nonsense, and some will fall between obvious and nonsense. Skip the nonsense, keep the rest. The goal is a list of candidate objects. Some items in the list will be eliminated, others will be added later. Finding good objects is a skill, like finding a good functional decomposition.


* Model physical objects
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
Finding Classes
* Be wary of the use of adjectives
Adjective-noun phrases may or may not indicate different objects
Is selection tool different than creation tool?
Is start point different from end point from point?



* Be wary of passive voice
A sentence is passive if the subject of the verb receives the action
Passive:
The music was enjoyed by us
Active:
We enjoyed the music


* Model categories of classes
Categories may become abstract classes
Keep them as individual classes at this point
Finding Classes

* Model known interfaces to outside world
User interfaces
Interfaces to other programs
Write a description of how people will use the system. This description is a source of interface objects.

* Model the values of attributes, not the attributes themselves
Height of a rectangle
Height is an attribute of rectangle

Value of height is a number

Rectangle can record its height
Finding Classes
Other Views
Coad and Yourdon

Structure
"Kind of" and "part of" relationships

Other systems
External systems with which the application interacts

Devices
Devices with which the application interacts

Events remembered
Historical event that must be recorded

Roles played
Different roles users play in interacting with application

Locations
Physical locations, offices and sites important to the application
Organizational units
Ross

People
Humans who carry out some function
Farmers

Places
Areas set aside for people or things
Fields on farm

Things
Physical objects or groups of objects
Plants
leaves roots

Organizations
Formally organized collections of people, resources, facilities
Union
farm crew

Concepts
Principles or ideas not tangible

Events
Things that happen
Shaler & Mellor[1]

Tangible things
Cars
telemetry data

Roles
Mother
teacher

Events
Landing
interrupt

Interactions
Loan
meeting

Booch[2]

"The tangible things in problem domain, the roles they play, and the events that may occur form the candidate classes and object of our design."
Jacobson[3]

"When a user uses the system they will perform a behaviorally related sequence of transactions in a dialogue with the system. This sequence is a use case. Objects are found by examining all the use cases for the system."
Abbot[4]

"In an English description of the problem, the nouns are candidates for objects; the verbs are candidates for operations."
Finding Classes
Categories of Classes

Data Managers
Principle responsibility is to maintain data
Examples: stack, collections, sets



Data Sinks or Data Sources
Generate data or accept data and process it further
Do not hold data for long
Examples: Random number generator, File IO classes

View or Observer classes
Example: GUI classes

Facilitator or Helper classes
Maintain little or no state information
Assist in execution of complex tasks

Record Your Candidate Classes


Class: Account .
. .
. .
. .
An Account represents a customer's account in the bank's database 
 An Account represents a customer's account in the bank's database


Record the class name on the front of an index card. One class per card. Write a brief description of the overall purpose of the class. The front of the card will be filled in with information as the design process continues. If you prefer to use some other medium (8 1/2" by 11" sheets of paper, computer program) do so. The goal is a tool that will enhance exploring the model. Once you are experienced with object-oriented design, you may find better tools. However, while learning, it is hard to find a cheaper tool than index cards. Even when you have a fancy case tool you might find yourself using these cards to help with designing parts of programs.

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
Class: Soil.
Superclass name.
Subclass 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 find a name, discard the group
Examples of Attributes


Physical vs. conceptual Mouse Network protocol


Active vs. passive Producer Product


Temporary vs. permanent Event Event queue


Generic vs. specific List Event list

Shared vs. unshared Print Queue Login Name

ATM Requirements Specification


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

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[5]


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.
Scenarios
Event Trace Diagram


Event Flow Diagram

Scenarios can be visualized in event trace diagrams. Placing events from all scenarios in an event flow diagram groups the responsibilities of entities in the system.

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
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
Assigning Responsibilities
State responsibilities as generally as possible

Assume that each kind of drawing element knows how to draw itself. It is better to say "drawing elements know how to draw themselves" than "a line knows how to draw itself, a rectangle knows how to draw itself, etc."




Keep behavior with related information

Abstraction implies we should do this




Keep information about one thing in one place

If two or more objects need the same information:
Create a new object to hold the information
Collapse the objects into a single object
Place information in the more natural object
Assigning Responsibilities
Share responsibilities

Who is responsible for updating screen when window moves?

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?
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?
Relations
or
The Data Base Problem


Mr. White works for the All-Smart Institute
 The All-Smart Institute employs Mr. White


Sally is John's sister
John is Sally's brother
Relations
or
The Data Base Problem

Model[6]


Implementation




Recording Responsibilities

Class: Soil.
..
..
List responsibilities here.
----------