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, hang-up
– 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
Analysis Phase
• Artifact
– Software Requirements Specification (SRS)
– Functional Specification: Use case Model
• 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
8
 UML
• UseCase Diagram
• Activity Diagram Business
Modeling

• Class Diagram • Sequence Diagram

• Communication Diagram
• Object Diagram
• Sate Diagram
• CRC Card

Behavioral Structural
Modeling Modeling
9
Use-Case Model

Actors

Use Case Diagram

...

Các đặc tả Use Case

(Use Case Specifications)
10
Voice Mail System Use Case Diagram

Caller Leave a Message

Login

Retrieve Messages
Owner

Change the Greeting

Change the Passcode 11

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

12
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

13
Design Phase
• Identify classes
• Identify behavior of classes
• Identify relationships among classes

14
Identifying Classes
• Rule of thumb: Look for nouns in problem
description
– Mailbox
– Message
– User
– Passcode
– Extension Number
– Menu
• Focus on concepts, not implementation
– MessageQueue stores messages
– Don't worry yet how the queue is implemented
15
Categories of Classes
• Tangible Things
• Agents
• Events and Transactions
• Users and Roles
• Systems
• System interfaces and devices
• Foundational Classes

16
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?
• A design tool: CRC Cards, Sequence Diagram
17
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

18
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 { public class Message {
void print() { String getText() {
System.out.println(text); // can print anywhere
} }
}
Replace}
with

• UML notation for dependency

MailBox MessageQueue

19
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

20
Aggregation
• A special form of association
• Represents the has-a or part-whole relationship.
• Simply a structural relationship
• Implemented through instance fields
– e.g. MessageQueue aggregates Messages
• e.g. Mailbox aggregates MessageQueue
• An example and UML notation for aggregation

MessageQueue Message

21
Composition
• A stronger form of aggregation
• The aggregate class exclusively owns the
component class.
• Contained objects don't exist outside container
• An example and UML notation for composition:
message queues permanently contained in mail box

MailBox MessageQueue

22
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 (one)
– e.g. Message doesn't know about message queue
containing it

MessageQueue 0..* Message

23
Multiplicities
• The number of instances one class relates to one
instance of another class.
– any number (0 or more): 0..*
– 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
24
Multiplicities
Implementation:
• 1, 0..1 relationship: MailBox MessageQueue
-...
-queue: MessageQueue
public class Mailbox {
...
private MessageQueue queue;
}

• *, 1..* relationship: Message

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

25
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

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

27
UML relationships

28
UML Diagram Softwares
• StarUML

• UML designer tool

• Visual Paradigm

29
UML Class Diagram for Voice Mail System

30
A design tool: 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

31
CRC Cards

Responsibilities Colaborators

32
CRC Cards
• Responsibilities should be high level without
concerning implementation details
• Between 1 - 3 responsibilities per card is ideal
• Collaborators are for the class, not for each
responsibility

33
How do you create CRC models
A CRC model is created iteratively performing the
following steps:
• Find classes
• One card per class
• Walk through scenario of use cases, to find
responsibilities, define collaborators to fill in cards

34
Walkthroughs
• 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
• Colaborator: Mailbox class

35
Walkthroughs

36
Other UML Diagrams
Many UML diagram types

We'll use three types:

• Class Diagrams
• Sequence Diagrams
• State Diagrams

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

38
Sequence Diagrams
Self call Object Construction

39
Sequence Diagram for Use Case:
Leave a message

40
Interpreting/EXPRESS a Sequence
Diagram
• Each key press results in separate call to dial, but only
one is shown
• Connection wants to get greeting to play
• Each mailbox knows its greeting
• Connection must find mailbox object:
Call findMailbox on MailSystem object
• Parameters are not displayed (e.g. mailbox number)
• Return values are not displayed (e.g. found mailbox)
• Note that connection holds on to that mailbox over
multiple call

41
State Diagram
• Use for classes whose objects have interesting states

42
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
43
Case Study: Voice Mail System

44
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

45
Use Case Diagram

Caller Leave Message

Login

Retrieve Messages
Owner

Change the Greeting

Change the Passcode 46

Use Case: Reach an Extension
1. User dials main number of 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

47
Use Case: Leave a Message
1. Caller carries out Reach an Extension
2. Caller speaks message
3. Caller hangs up
4. System places message in mailbox

48
Use Case: Retrieve Messages
1. Mailbox owner carries out Log in
2. Mailbox owner selects "retrieve messages" menu option
3. System plays message menu:
Press 1 to listen to the current message
Press 2 to delete the current message
Press 3 to save the current message
Press 4 to return to the mailbox menu
4. Mailbox owner selects "listen to current message"
5. System plays current new message, or, if no more new
System plays message menu
6. User selects "delete current message".
Message is removed.
7. Continue with step 3.

49
Use Case: Retrieve Messages
Variation #1
1.1. Start at Step 6
1.2. User selects "save current message".
• Message is removed from new queue and
appended to old queue
1.3. Continue with step 3.

50
Use Case: Change the Greeting
1. Mailbox owner carries out Log in
2. Mailbox owner selects "change greeting" menu
option
3. Mailbox owner speaks new greeting
4. Mailbox owner presses #
5. System sets new greeting
Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.
1.3. System keeps old greeting.
51
Use Case: Change the Passcode
1. Mailbox owner carries out Log in
2. Mailbox owner selects "change passcode" menu
option
3. Mailbox owner dials new passcode
4. Mailbox owner presses #
5. System sets new passcode
Variation #1: Hang up before confirmation
1.1. Start at step 3.
1.2. Mailbox owner hangs up.
1.3. System keeps old passcode.
52
CRC Cards for Voice Mail System
Some obvious classes
• Mailbox
• Message
• MailSystem
• MessageQueue

53
Initial CRC Cards

54
Telephone
• Who interacts with user?
• Telephone takes button presses, voice input
• Telephone speaks output to user

55
Connection
• With whom does Telephone communicate
• With MailSystem?
• What if there are multiple telephones?
• Each connection needs to keep track of the current state
(dialing, recording, retrieving messages,...)
• Should mail system keep track of all connection states?
• Better to give this responsibility to a new class

56
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

57
Analyze Use Case: Leave a message
1. User dials extension. Telephone sends number to Connection
– Add collaborator Connection to Telephone
2. Connection asks MailSystem to find matching Mailbox
3. Connection asks Mailbox for greeting
– Add responsibility "manage greeting" to Mailbox, add collaborator
Mailbox to Connection
4. Connection asks Telephone to play greeting
5. User speaks message. Telephone asks Connection to record it
– Add responsibility "record voice input" to Connection
6. User hangs up. Telephone notifies Connection.
7. Connection constructs Message
– Add card for Message class, add collaborator Message to Connection
8. Connection adds Message to Mailbox
58
Result of Use Case Analysis

59
Result of Use Case Analysis

60
Analyse Use Case: Retrieve messages
1. User types in passcode.
Telephone notifies Connection
2. Connection asks Mailbox to check passcode.
– Add responsibility "manage passcode" to Mailbox
3. Connection sets current mailbox and asks Telephone
to speak menu
4. User selects "retrieve messages".
Telephone passes key to Connection
5. Connection asks Telephone to speak menu
6. User selects "listen to current message".
Telephone passes key to Connection
61
Analyse Use Case: Retrieve messages
7. Connection gets first message from current mailbox.
– Add "retrieve messages" to responsibility of Mailbox.
– Connection asks Telephone to speak message
8. Connection asks Telephone to speak menu
9. User selects "save current message".
Telephone passes key to Connection
10.Connection tells Mailbox to save message
– Modify responsibility of Mailbox to "retrieve, save, delete
messages"
11.Connection asks Telephone to speak menu

62
Result of Use Case Analysis

63
CRC Summary
• One card per class
• Responsibilities at high level
• Use scenario walkthroughs to fill in cards
• Usually, the first design isn't perfect.

64
UML Class Diagram for Mail System
• CRC collaborators yield dependencies
– Mailbox depends on MessageQueue
– Message doesn't depends on Mailbox
– Connection depends on Telephone,
MailSystem, Message, Mailbox
– Telephone depends on Connection

65
Dependency Relationships

66
Aggregation Relationships
• A mail system has mailboxes
• A mailbox has two message queues
• A message queue has some number of messages
• A connection has a current mailbox.
• A connection has references to a mail system and a
telephone

67
UML Class Diagram for Voice Mail System

68
Sequence Diagram for Use Case:
Leave a message

69
Sequence Diagram: Retrieve messages

70
Connection State Diagram

71
Final Class Diagram for Voice Mail System

72
 Xây dựng sơ đồ Use case cho một hệ
thống thương mại điện tử (ECommerce)
• Để mở rộng hoạt động kinh doanh của mình, công
ty mong muốn xây dựng một hệ thống thương mại
điện tử nhằm mở rộng phạm vi kinh doanh trên
mạng Internet.
• Hệ thống mới phải đảm bảo cho khách hàng viếng
thăm Website dễ dàng lựa chọn các sản phẩm, xem
các khuyến mãi cũng như mua hàng
• Khách hàng đăng nhập vào hệ thống để đặt hàng
và có thể thực hiện việc thanh toán qua mạng hoặc
thanh toán trực tiếp tại cửa hàng.

73
 Xây dựng sơ đồ Use case cho một hệ
thống thương mại điện tử (ECommerce)
• Khách hàng có thể nhận hàng tại cửa hàng hoặc sử
dụng dịch vụ chuyển hàng có phí của công ty.
• Người bán hàng (Hệ thống) có thể quản lý đơn
hàng như thu tiền, theo dõi chuyển hàng.
• Yêu cầu:
– Xây dựng mô hình Use Case cho hệ thống trên (xác định
actor, usecase, ….)
– Xây dưng mô hình hoá hiện thực cho một chức năng cụ
thể trong hệ thống với một chức năng tuỳ ý.

74
Bài tập Quản lý Học viên
• Một trung tâm tin học muốn quản lý các giáo viên, học
viên của mình. Thông tin của mỗi giáo viên bao gồm: tên
giáo viên, ngày tháng năm sinh, học vị (cử nhân, thạc sĩ,
tiến sĩ). Thông tin của mỗi học viên bao gồm: tên học
viên, ngày tháng năm sinh, giáo viên chủ nghiệm. Mỗi
học viên sẽ đăng ký học một số môn học và phải thi cuối
khóa. Thông tin của một môn học bao gồm: tên môn
học, số tín chỉ, giáo viên giảng dạy. Sau khi kết thúc
khóa học nhà trường sẽ đánh giá loại tốt nghiệp của học
viên dựa trên điểm trung bình các điểm thi các môn học
của học viên.
75
Bài tập Quản lý Học viên
• Yêu cầu 1: Cho Use case: In bảng điểm cho sinh viên
1. Hệ thống hiển thị thông báo:
Nhap ten hoc vien:
2. Người dùng nhập mã học viên muốn in bảng điểm
3. Hệ thống tính điểm trung bình cho học viên dựa vào kết quả điểm
số các môn học của học viên như sau:
• Điểm TB = S (Điểm môn i * Số tín chỉ môn i) / Tổng số tín chỉ các
môn học
4. Hệ thống xếp loại tốt nghiệp cho học viên dựa vào điểm trung bình
như sau:
• Điểm TB ≥ 9 xếp loại xuất sắc.
• 9 > Điểm TB ≥ 8 xếp loại là giỏi.
• 8 > Điểm TB ≥ 7 xếp loại là khá.
• 7 > Điểm TB ≥ 6 xếp loại là trung bình khá.
• 6 > Điểm TB ≥ 5 xếp loại là trung bình.
• Điểm TB < 5 không được tốt nghiệp.
76
Bài tập Quản lý Học viên
5. Hệ thống in bảng điểm cho học viên theo mẫu sau:
• Họ tên:
• Ngày sinh:
• STT Môn Điểm
• …
• Điểm TB:
• Xếp loại:
Yêu cầu: Hãy hiện thực use case trên:
• Nhận diện, thiết kế và cài đặt các lớp cho use case
• Thiết kế các ứng xử trong use case và gán cho các lớp
a. Tính điểm trung bình cho học viên.
b. Xếp loại tốt nghiệp cho học viên
c. In bảng điểm cho học viên.

77