ITEC324 Principle of CS III Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee

Chapter Topics 1  From Problem to Code  Identifying Classes  Identifying Responsibilities  Relationships Between Classes  Use Cases

Chapter Topics 2  CRC Cards  UML Class Diagrams  Sequence Diagrams  State Diagrams  Using javadoc for Design Documentation  Case Study: A Voice Mail System

From Problem to Code  Three Phases:  Analysis  Design  Implementation  Case Study: Voice Mail System

From Problem to Code 1. Analysis Phase  Functional Specification  Completely defines tasks to be solved  Free from internal contradictions  Readable both by domain experts and software developers  Reviewable by diverse interested parties  Testable against reality

From Problem to Code 2. Design Phase  Goals  Identify classes  Identify behavior of classes  Identify relationships among classes  Artifacts  Textual description of classes and key methods  Diagrams of class relationships  Diagrams of important usage scenarios  State diagrams for objects with highly state-dependent

From Problem to Code 3. Implementation Phase  Implement and test classes  Combine classes into program  Avoid "big bang" integration  Prototypes can be very useful

Identifying Classes  Rule of thumb: Look for nouns in problem description  Mailbox  Message  User  Passcode  Extension  Menu  Focus on concepts, not implementation  MessageQueue stores messages  Don't worry yet how the queue is implemented

Identifying Classes Categories of Classes  Tangible Things  Agents  Events and Transactions  Users and Roles  Systems  System interfaces and devices  Foundational Classes

Identifying Responsibilities  Rule of thumb: Look for verbs in problem description Behavior of MessageQueue:  Add message to tail  Remove message from head  Test whether queue is empty

Identifying Responsibilities  OO Principle: A responsibility must belong to exactly one class  Example: Add message to mailbox Who is responsible: Message or Mailbox?

Class Relationships  Dependency  "uses"  Aggregation  "has"  Inheritance  "is"

Class Relationships Dependency Relationship 1  C depends on D: Method of C manipulates objects of D  Example: Mailbox depends on Message  If C doesn't use D, then C can be developed without knowing about D

Class Relationships Dependency Relationship 2  Minimize dependency: reduce coupling  Example: Replace public class Message { void print() {System.out.println(text);} } with public String getText()  Removes dependence on System, PrintStream

Class Relationships Aggregation  Object of a class contains objects of another class  Example: MessageQueue aggregates Messages  Example: Mailbox aggregates MessageQueue  Implemented through instance fields

Class Relationships Aggregation: Multiplicities  1 : 1 or 1 : relationship: public class Mailbox {... private Greeting myGreeting; }  1 : n relationship: public class MessageQueue {... private ArrayList elements; }

Class Relationships Inheritance  More general class = superclass  More specialized class = subclass  Subclass supports all method interfaces of superclass (but implementations may differ)  Subclass may have added methods, added state  Subclass inherits from superclass  Example: ForwardedMessage inherits from Message  Example: Greeting does not inherit from Message (Can't store greetings in mailbox)

Use Cases  Analysis technique  Each use case focuses on a specific scenario  Use case = sequence of actions  Action = interaction between actor and computer system  Each action yields a result  Each result has a value to one of the actors  Use variations for exceptional situations

Sample Use Case  Leave a Message 1.Caller dials main number of voice mail system 2.System speaks prompt Enter mailbox number followed by # 3.User types extension number 4.System speaks You have reached mailbox xxxx. Please leave a message now 5.Caller speaks message 6.Caller hangs up 7.System places message in mailbox

Sample Use Case -- Variations  Variation # In step 3, user enters invalid extension number 1.2. Voice mail system speaks You have typed an invalid mailbox number Continue with step 2.  Variation # After step 4, caller hangs up instead of speaking message 2.3. Voice mail system discards empty message

Recap of the Chapter Topics 1  From Problem to Code  The Object and Class Concepts  Identifying Classes  Identifying Responsibilities  Relationships Between Classes  Use Cases

Recap of the Chapter Topics 2  CRC Cards  UML Class Diagrams  Sequence Diagrams  State Diagrams  Using javadoc for Design Documentation  Case Study: A Voice Mail System

CRC Cards (1)  Design Technique  CRC = Classes, Responsibilities, Collaborators  Developed by Beck and Cunningham  Use an index card for each class  Class name on top of card  Responsibilities on left  Collaborators on right

CRC Cards (2)  Responsibilities should be high level  responsibilities per card  Collaborators are for the class, not for each responsibility

Walkthroughs (1)  Use case: "Leave a message"  Caller connects to voice mail system  Caller dials extension number  "Someone" must locate mailbox  Neither Mailbox nor Message can do this  New class: MailSystem Responsibility: manage mailboxes

Walkthroughs (2)

UML Diagrams  UML = Unified Modeling Language  Unifies notations developed by the "3 Amigos" Booch, Rumbaugh, Jacobson  Many diagram types  We'll use three types:  Class Diagrams  Sequence Diagrams  State Diagrams

Class Diagrams  Rectangle with class name  Optional compartments  Attributes  Methods  Include only key attributes and methods

Class Relationships

Multiplicities  any number (0 or more): *  one or more: 1..*  zero or one: 0..1  exactly one: 1

Composition  Special form of aggregation  Contained objects don't exist outside container  Example: message queues permanently contained in mail box

Association (1)  Some designers don't like aggregation  More general association relationship  Association can have roles

Association (2)  Some associations are bidirectional Can navigate from either class to the other  Example: Course has set of students, student has set of courses  Some associations are directed Navigation is unidirectional  Example: Message doesn't know about message queue containing it

Interface Types  Interface type describes a set of methods  No implementation, no state  Class implements interface if it implements its methods  In UML, use stereotype «interface»

Tips  Use UML to inform, not to impress  Don't draw a single monster diagram  Each diagram must have a specific purpose  Omit inessential details

Sequence Diagrams  Each diagram shows dynamics of scenario  Object diagram: class name underlined

Self call

Object Construction

State Diagram  Use for classes whose objects have interesting states

Design Documentation (1)  Recommendation: Use Javadoc comments  Leave methods blank /** Adds a message to the end of the new aMessage a message */ public void addMessage(Message aMessage) { }  Don't compile file, just run Javadoc  Makes a good starting point for code later

Design Documentation (2)  Please refer details on javadoc in page 6~9 of chapter 1 (Horstmann’s book)  Ch1/helloworld/Greeter.java (page 6) Ch1/helloworld/Greeter.java

Design Documentation (3)

Design Documentation (4)