C SC 225 Lecture 2: Object-Oriented Design Process

[ previous | schedule | next ]

Major Development Activities

• Analysis
• Covered more completely in CSC 325
• fully describe what the software product is supposed to do
• includes other, non-functional, requirements such as required response times, that we will skip
• Design -- assuming functional, not OO, analysis
• identify classes, responsibilities, relationships
• notes below introduce a few major techniques
• My CSC 325 notes on Object Oriented Analysis are much more detailed
• See Object-Oriented Analysis: Objects and Associations
• See Object-Oriented Analysis: System Dynamics
• every object has identity, behavior and state
• produce a number of artifacts
• class diagrams showing relationships
• use cases and sequence diagrams showing usage scenarios
• possibly state diagrams
• possibly pseudo-code descriptions of algorithms
• textual descriptions of classes, responsibilities, relationships
• Implementation
• coding, testing, debugging, integrating
• text author includes prototyping, but I prefer to classify it as analysis/design activity

Use Cases for Analysis

• Included here because use case descriptions become useful sources for identifying objects, responsibilities and relationships
• Also included here because OO design textbook includes them
• Use case is step-by-step description of actor using the system to accomplish some goal. Actor is external to the system being modeled. Actor may be human or a different system.

Design Activity: Identifying Classes

• Either done during analysis for OOA, or at design time from functional specifications
• Nouns in problem description are candidate objects and classes
• Author says consider categories such as: tangible things, agents, events, users, roles
• Name the classes using singular nouns

Design Activity: Identifying Responsibilities

• Verbs in problem description are candidate responsibilities and behaviors
• Each responsibility assigned to one class
• Not always easy to assign responsibility correctly
• Text tip about keeping all responsibilities of class at same abstraction level

Design Activity: Identifying Relationships

• Inheritance is the specialization/generalization relationship, a.k.a. "is-a". This has its advantages and disadvantages, and one should not go to far out of one's way to see or exploit it.
• Aggregation and composition are the containment relationships, a.k.a. "has-a". An object that contains other objects. Also look for multiplicity, which is how many are contained (and, for the contained object, how many it is contained by).
• The term composition is sometimes used to indicate the contained object is dependent on the container and does not stand on its own, such as engine in a car.
• The term aggregation is sometimes used to indicate the contained object is independent of its container, such as a book in a shelf.
• More often, the distinction is not critical and the aggregation term is used to cover both cases.
• Dependency is the relationship indicating that one class uses another. This is a general and frequently occuring association.
• dependency cannot be avoided but is not discouraged because it tends to increase the "coupling" of one class to another.
• If class A depends on class B and class B later is modified, then A may also be affected. Not good.
• Association is the most general relationship. It is used to indicate a relationship exists but its nature is not (yet) known. It helps if a role can be identified. It may evolve into a more specific relationship as the design evolves through "iterate and increment".

Design Technique: CRC Cards

• Another technique for discovering classes, responsibilities, relationships
• developed in early 90s for Responsibility Driven Design (RDD)
• See www.wirfs-brock.com/
• Class-Responsibility-Collaboration cards
• Literally use 4x6 index cards
• class name at top
• left column is list of high-level responsibilities
• right column is list of collaborators
• if lists not fit, class needs to be broken down
• Horstmann: "Between one and three responsibilities per card is ideal."
• responsibility != method
• responsibilities should be "cohesive" (related)
• CRC cards not recommended for use in design documentation
• Process: fill out the cards while "walking through" use cases.
• Horstmann suggests group process with one person playing "protagonist" for each use case and arrange cards so that collaborators are physically close.
• I've used group process where each class is assigned one person who is responsible for its card and who plays the role of its class. A moderator reads through the use case and asks who will be responsible for each action. New classes are identified and assigned as appropriate.

UML Class Diagram

• You have all seen, used and drawn these
• You probably have not seen or used all the different notations
• Class diagrams, and design processes
• Early in design, diagram typically has few details
• As design evolves through "iterate and increment", details are added to diagram
• For more info on notation, see text or my CSC 325 notes on Objects and Associations (diagrams at bottom)
• There are many other online sources, do a search on: UML "class diagram"
• Particularly good: http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
• http://www.agilemodeling.com/artifacts/classDiagram.htm

UML Sequence Diagram

• Describes system dynamics and object/class interactions (class diagrams show static relationships)
• Drawn from the viewpoint of a client, the leftmost column
• See my CSC 325 notes on System Dynamics (bottom of page) for more details on notation
• Each column is an object/class
• Time flows from top to bottom
• Method calls modeled by right arrow
• Typical use is to model details of a single method or a use-case

UML State Diagram

• Sometimes called statechart
• A form of state transition diagram
• Indicates various states an object may have and what events trigger transition from one state to another
• See my CSC 325 notes on System Dynamics (top of page) for more details on notation

Javadoc for documentation of design

• Supplements the diagrams as design documentation
• Define method prototypes
• Temptation is to build implementation from this code. Is this good or bad?