Classes identification

Outline
From Problem to Code Case Study: A Voice Mail System The Object and Class Concepts Identifying Classes Identifying Responsibilities CRC Cards Using javadoc for Design Documentation

CSE UOWD

CSCI 213: Classes Identification Spring 2013

From Problem to Code

(Partially) Three Phases:
Analysis Design Implementation

CSE UOWD

CSCI 213: Classes Identification Spring 2013

Analysis Phase
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

CSE UOWD

CSCI 213: Classes Identification Spring 2013

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 rich state
CSE UOWD

CSCI 213: Classes Identification Spring 2013

Implementation Phase
Implement and test classes Combine classes into program Avoid "big bang" integration Prototypes can be very useful

CSE UOWD

CSCI 213: Classes Identification Spring 2013

Object and Class Concept

Object: Three characteristic concepts
State Behavior Identity

Class: Container/Collection of similar objects

CSE UOWD

CSCI 213: Classes Identification Spring 2013

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 implemend
CSE UOWD

CSCI 213: Classes Identification Spring 2013

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

CSE UOWD

CSCI 213: Classes Identification Spring 2013

Responsibilities
OO Principle: Every operation is the responsibility of a single class
Responsibility-driven

Example: Add message to mailbox Who is responsible: Message or Mailbox?

CSE UOWD

CSCI 213: Classes Identification Spring 2013

10

Scenarios
Analysis technique Each scenario on a specific task/execution Scenario = 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
CSE UOWD

CSCI 213: Classes Identification Spring 2013

11

Use Case: Example

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
CSE UOWD

CSCI 213: Classes Identification Spring 2013

12

Variations
Variation #1
1.1 In step 3, user enters invalid extension number 1.2. Voice mail system speaks You have typed an invalid mailbox number. 1.3. Continue with step 2.

Variation #2
2.1. After step 4, caller hangs up instead of speaking message 2.3. Voice mail system discards empty message

CSE UOWD

CSCI 213: Classes Identification Spring 2013

13

Noun Extraction
Stage 1. Concise Problem Definition
Define product in single sentence

Stage 2. Informal Strategy

Incorporate constraints, express result in a single

paragraph

Stage 3. Formalize the Strategy

Identify nouns in informal strategy Use nouns as candidate classes

CSE UOWD

CSCI 213: Classes Identification Spring 2013

CRC Cards
CRC = Classes, Responsibilities, Collaborators Developed by Beck and Cunningham Used since 1989 Use an index card for each class
Class name on top of card Responsibilities on left Collaborators on right

CSE UOWD

CSCI 213: Classes Identification Spring 2013

15

CRC Cards (2)

Strength
When acted out by team members, powerful

tool for highlighting missing or incorrect items

Weakness
Domain expertise is needed

CSE UOWD

CSCI 213: Classes Identification Spring 2013

16

CRC Cards (2)

CSE UOWD

CSCI 213: Classes Identification Spring 2013

17

CRC Cards (3)

Responsibilities should be high level 1 - 3 responsibilities per card Collaborators are for the class, not for each responsibility

CSE UOWD

CSCI 213: Classes Identification Spring 2013

18

Walkthrough
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

CSE UOWD

CSCI 213: Classes Identification Spring 2013

19

Walkthrough (2)

CSE UOWD

CSCI 213: Classes Identification Spring 2013

20

OO Modeling: Three Steps

1. Use case modeling:
Specify the functionality of the product to be

constructed
Develop use case diagrams and associated scenarios Called functional modeling Mainly action oriented

2. Class modeling
Determine the classes and their attributes This information is presented using diagrams called

class diagrams
(similar to entity-relationship diagrams) Data-oriented
CSE UOWD

CSCI 213: Classes Identification Spring 2013

21

Three Steps (2)

3. Dynamic modeling
Determine the actions performed by or to

each class Use state diagrams (similar to finite state machines) Action-oriented

CSE UOWD

CSCI 213: Classes Identification Spring 2013

22

Class Diagram
Rectangle with class name Optional compartments
Attributes Methods

Include only key attributes and methods

CSE UOWD

CSCI 213: Classes Identification Spring 2013

23

Class Diagram (2)

CSE UOWD

CSCI 213: Classes Identification Spring 2013

24

Class Relationship (2)

Dependency ("uses") Aggregation ("has") Inheritance ("is")

CSE UOWD

CSCI 213: Classes Identification Spring 2013

25

Dependency
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

CSE UOWD

CSCI 213: Classes Identification Spring 2013

26

Aggregation
Object of a class contains objects of another class Examples:
MessageQueue aggregates Messages Mailbox aggregates MessageQueue

Implemented through instance fields

CSE UOWD

CSCI 213: Classes Identification Spring 2013

27

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

CSE UOWD

CSCI 213: Classes Identification Spring 2013

28

Inheritance
More general class = superclass More specialized class = subclass Subclass inherits from superclass Subclass supports all method interfaces of superclass (but implementations may differ) Subclass may have added method(s), added state(s) Examples
ForwardedMessage inherits from Message Greeting does not inherit from Message
CSE UOWD

CSCI 213: Classes Identification Spring 2013

29

State Diagrams
States can have activities represented as do / activity Transitions are labeled as Event [Guard] / Action Start states, final states

CSE UOWD

CSCI 213: Classes Identification Spring 2013

10

State Diagram (2)

Used for classes whose objects have interesting states

CSE UOWD

CSCI 213: Classes Identification Spring 2013

31

Design Documentation
Recommendation: Use Javadoc comments
Leave methods blank

/**

Adds a message to the end of the new messages.! @param aMessage a message! */! public void addMessage(Message aMessage)! {! }!

Don't compile file, just run javadoc

Makes a good starting point for code later

CSE UOWD

CSCI 213: Classes Identification Spring 2013

32

Challenges of the Design Phase

Design team should not do too much
Detailed design should not become code

Design team should not do too little

It is essential for the design team to produce

a complete detailed design

CSE UOWD

CSCI 213: Classes Identification Spring 2013

11

Key Points
The Object and Class Concepts Identifying Classes Identifying Responsibilities Use Cases CRC Cards OOD process Using javadoc for Design Documentation

CSE UOWD

CSCI 213: Classes Identification Spring 2013

34

12