The object oriented design process (THIẾT kế đối TƯỢNG SLIDE)

The Object-Oriented
Design Process

1


Topics
•
•
•
•
•
•
•
•
•
•

From Problem to Code
Identifying Classes
Identifying Responsibilities
Relationships Between Classes
Use Cases
CRC Cards
UML Class Diagrams
Sequence Diagrams
State Diagrams
Case Study: A Voice Mail System
2

From Problem to Code
• Three Phases:
– Analysis
– Design
– Implementation

3


Analysis Phase
• Establish the functions, services, and constraints of
the software to be developed.
– The developers and the software users work together to
produce a requirements specification, which will be the
input to the design phase.

• Functional Specification is a part of requirements
specification. It has the following characteristics:
– 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

4


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

5


Implementation Phase
• Implementation is the realization of the software
design in a specific programming language.
• Each unit (a single class) is implemented separately.
• Unit testing is done to ensure that each unit
functions properly with respect to its specification
before the units are integrated.
• The individual units are integrated and tested as a
whole to ensure that the entire software system
works properly conforming to its specification.

6

Case Study: Voice Mail System
• Program that simulates a telephone voice mail
system
• The system has a collection of mailboxes, each of
which may be accessed by an extension number
• Use text for voice, phone keys, hangup
• 1 2 ... 0 # on a single line means key
• H on a single line means "hang up"
• All other inputs mean voice
• In GUI program, will use buttons for keys
7


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
8


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

9


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

• OO Principle: Every operation is the responsibility of
a single class
– Example: Add message to mailbox

– Who is responsible: Message or Mailbox?
10


Identifying Class Relationships
• The following relationships can exist among classes:
– Dependency ("uses")
– Association, including aggregation and composition
– Generalization, including inheritance and implementation

• Among them, inheritance ("is-a"), aggregation
("has"), and dependency ("use") are the most basic
relationships

11


Dependency Relationship
• Class A depends on class B:
– A method of A manipulates objects of B in the parameters, local
variables, or return types

• Minimize dependency: reduce coupling
– Example: Removes dependence on System and Message
public class Message {
void print() {

public class Message {
String getText() {
// can print

System.out.println(text);
anywhere
Replace with
}
}
}
}

• UML notation for dependency
MailBox

MessageQueue

12


Association
• Association represents general binary relationships
between classes
• Association can have roles
• Implemented through instance fields
• An example and UML notation for association
relationship
Course

register for

has a participant

Student

13


Aggregation
• A special form of association
– Represents the has-a or part-whole relationship.
– Simply a structural relationship that distinguishes the
whole, that is, the aggregate class, from the parts, that is,
the component class.
– Implemented through instance fields
• e.g. MessageQueue aggregates Messages
• e.g. Mailbox aggregates MessageQueue

• An example and UML notation for aggregation
MessageQueue

Message

14


Composition
• A stronger form of aggregation
– The aggregate class exclusively owns the component
class.
– The lifetime of the components is entirely included in the
lifetime of the aggregate.
– Contained objects don't exist outside container

• An example and UML notation for composition:
message queues permanently contained in mail box
MailBox

MessageQueue

15


Association Direction
• Some associations are bidirectional
– Can navigate from either class to the other
– e.g. Course has set of students, student has set of courses

• Some associations are directed
– Navigation is unidirectional
– e.g. Message doesn't know about message queue
containing it
MessageQueue

0..*

Message

16


Multiplicities
• The number of instances one class relates to one
instance of another class.

–
–
–
–

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

• For example:
– For each instance of Professor, many Course Offerings
may be taught.
– For each instance of Course Offering, there may be either
one or zero Professor as the instructor.
Professor

0..1

*

CourseOffering

instructor
17


Multiplicities
Implementation:
• 1, 0..1 relationship:

public class Mailbox {
...
private MessageQueue
queue;
}

MailBox
-...
-queue: MessageQueue

MessageQueue

•

MessageQueue

*

Message

-messages: List<Message>
public class MessageQueue {
*, 1..*
...relationship:
private List<Message>
messages;
}
18

Generalization - Inheritance relationship
• Inheritance relationship is formed when a class (or
an interface) extends another class (or interface).
• UML notation for generalization
SuperClass

<<interface>>
SuperInterface

SubClass

<<interface>>
SubInterface

19


Generalization - implementation relation
• The implementation relation between a class and an
interface
• Interface type describes a set of methods.
No implementation, no state
<<interface>>
Comparable
• Class implements interface
if it implements its methods
• UML notation for
implementation relation
Message

20


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

21


Use-Case Model

Actors
Các Use Case

...
Các đặc tả Use Case
(Use Case Specifications)
22


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
23


Sample Use Case -- 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

24

CRC Cards
• CRC = Classes, Responsibilities, Collaborators
– a very effective design tool in identifying classes, their
responsibilities, and relationships to other classes

• Developed by Beck and Cunningham
• Use an index card for each class
• Class name on top of card
• Responsibilities on left
• Collaborators on right

25