View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Criteria for Good OOA/D

See also, the Design Road Map.

What makes for good OOA/OOD/OOP?

The following are the criteria that I've collected from class discussions as defining good object-oriented analysis and object-oriented design (and some good object-oriented programming).

Advice From the TA's:

Object-Oriented Analysis

Object-Oriented Design

TAs in the past have reported that some students just repeated the OOA in the OOD. For example, one might have defined a class named TempSensor that has a part-of relationship with a Refrigerator and has an attribute named DesiredTemp. In the OOD, we're seeing the script "I am a TempSensor. I know my DesiredTemp. I am part of a Refrigerator." Period. That's not the idea. The OOD is where you ALSO spell out what the TempSensor does and HOW it does it. Below is an example, with my notes in parentheses about what you should be thinking about when you're writing these out:
"I am a TempSensor. I know how to alert the Refrigerator when to turn on. (Which implies that I'd better have an instance variable for my Refrigerator.) When I get a tick message (Which implies that something is going to send the Tick message. Who? How do they track those of us who care about ticks?), I compare the current temperature (maybe there's a message which reads the device?) to the DesiredTemp, and if it's out of range (where is the acceptable range stored?), I send a message to the Refrigerator. (What message? Refrigerators better know how to respond to that message.)"

The idea is that the OOD is where you patch the pieces together, where you make sure that messages are caught, important information is known at the right places, that all the important services are accounted for.

Object-Oriented Programming

Links to this Page