290342
Software Development Process
บทที่ 5
การออกแบบซอฟต์ แวร์ (1)
อ.ธารารัตน์ พวงสุ วรรณ
คณะวิทยาศาสตร์ และศิลปศาสตร์
มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี
เนือ้ หา







ความหมายของการออกแบบซอฟต์แวร์และวิศวกรรมการออกแบบ
ระดับของกระบวนการออกแบบซอฟต์แวร์
กลยุทธ์และระเบียบวิธใี นการออกแบบซอฟต์แวร์
แบบจาลองการออกแบบ (Design Model)
หลักการออกแบบซอฟต์แวร์
หลักการพืน้ ฐานในการออกแบบซอฟต์แวร์
แบบจาลองทีใ่ ช้ในการออกแบบ
การออกแบบซอฟต์ แวร์
Quality
Customer’
requirement
product or
system
Translate by design
การออกแบบซอฟต์ แวร์
Maintenance
Maintenance
Test
Test
Implementation
Implementation
Design
With Design
Without Design
การออกแบบซอฟต แวร์


การออกแบบซอฟต แวร หมายถึง กระบวนการกาหนด สถาป ตยก
รรม ส วนประกอบ ส วนต่อประสาน และ ลักษณะด านอื่นๆ ของระบบ
สิง่ ทีไ่ ด จากการออกแบบก็คอื แบบจำลองกำรออกแบบ (Design
Model) นันเอง
่
การออกแบบซอฟต แวร์ เป นการนาข อกาหนดความต องการของ
ผู ใช มากาหนดรายละเอียดโครงสร างภายในของซอฟต แวร เพือ่
นาไปใช ในการเขียนและทดสอบโปรแกรมในระยะการสร างซอฟต์แวร์
วิศวกรรมการออกแบบ



วิศวกรรมการออกแบบเป็ นการรวบรวมหลักการ แนวความคิด และ
วิธปี ฏิบตั ทิ น่ี าไปสูก่ ารพัฒนาระบบคอมพิวเตอร์ทม่ี คี ุณภาพสูง
เป็ นกิจกรรมหลักอย่างหนึ่งของวิศวกรรมคอมพิวเตอร์
มีเป าหมาย คือ การสร างแบบร างของระบบ หรือมีการ
นาเสนอระบบในแต ละด้าน ให มีคุณสมบัติ
1. firmness
2. commodity
3. delight
***** ทุกข้อดังกล่าว คือ คุณภาพ ****
กระบวนการออกแบบซอฟต์ แวร์

จะมีลกั ษณะการทางานซ้ าๆเนื่องจากต้องนาความต้องการของระบบทีผ่ า่ น
การวิเคราะห์แล้วในแต่ละด้าน มาแปลงเป็ นข้อกาหนดของการออกแบบ
ได้แก่
 ข้อมูล
 ฟั งก์ชน
ั การทางาน
 ส่ วนประสาน
ระดับของกระบวนการออกแบบซอฟต์ แวร์


การออกแบบเชิงสถาปัตยกรรม Architectural Design
การออกแบบในรายละเอียด Detailed Design
กลยุทธ์ ในการออกแบบซอฟต์ แวร์

กลยุทธ์ทวไปในกำรออกแบบซอฟต์
ั่
แวร์ (General Strategy)
 เป็ นกลยุทธ์ในการออกแบบซอฟต์แวร์ทวไป
ั ่ เช่น
 Top-Down and Bottom-up
 Divide-and Conquer
 Design Pattern
 Stepwise Refinement
ระเบียบวิธีการออกแบบซอฟต์ แวร์




การออกแบบเชิงฟงั ก์ชนั (Function-Oriented Design)
การออกแบบเชิงวัตถุ (Object-oriented Dsign)
การออกแบบโดยใช้ขอ้ มูลเป็ นศูนย์กลาง (Data-structure Centered
Design)
การออกแบบคอมโพเน้นท์ (Component-base Design: CBD)
การออกแบบซอฟต์ แวร์

จากขัน้ ตอนการวิเคราะห์จะทาให้ได้ขอ้ มูล เพือ่ จะนาไปสร้างแบบจาลอง
ทัง้ 4 ประเภท ซึง่ จะนาไปใช้ต่อในขัน้ ตอนการออกแบบ




Scenerio-based elements
Class-based elememts
Flow-oriented elements
Behavioral elements
องค์ประกอบเชิงฉากบรรยาย: use-case diagram
องค์ประกอบเชิงคลาส : class diagram
องค์ประกอบเชิงกระแส : Data flow diagram
องค์ประกอบเชิงพฤติกรรม : State diagram,
Sequence diagram
การแปลงจาลองการวิเคราะห์ เป็ นแบบจาลองการออกแบบ
sc e na r i o- ba se d
e l e me nt s
Co m p o n e n t L e v e l D e sig n
f l ow- or i e nt e d
e l e me nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e rf a c e D e sig n
Analysis Model
c l a ss- ba se d
e l e me nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e me nt s
A rc h it e c t u ra l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
แบบจาลองการออกแบบ




Data/Class Design
Architecture Design
Interface Design
Component-level Design
(Design Model)
หลักการออกแบบซอฟต์ แวร์

การออกแบบควรแสดงให้เห็นถึงรู ปแบบสถาปั ตยกรรมที่เลือกใช้อย่างชัดเจนและ
มีแบบแผน

การออกแบบควรมิลกั ษณะเป็ นโมดูล

การออกแบบควรนาเสนอด้านข้อมูล สถาปั ตยกรรม ส่ วนประสาน และคอมโพ
เน้นท์ที่ชดั เจน

ควรออกแบบคอมโพเน้นท์ให้มีอิสระต่อกัน

ควรออกแบบให้ส่วนประสานระหว่างคอมโพเน้นท์กบั สภาพแวดล้อมภายนอกมี
ความซับซ้อนน้อยที่สุด
หลักการออกแบบซอฟต์ แวร์

การออกแบบควรนาข้อมูลมาจากการวิเคราะห์ระบบ และใช้ระเบียบวิธีปฏิบตั ิ
เดียวกัน

สัญลักษณ์ที่ใช้ในการออกแบบควรสื่ อความหมายได้ชดั เจน และเป็ นมาตรฐาน

งานออกแบบควรมีโครงสร้างที่ดี เพื่อการแก้ไขที่ง่ายและใช้ตน้ ทุนน้อย

การออกแบบในระดับคอมโพเน้นท์มีลกั ษณะแบบ Functional Independence คือ
ฟังก์ชนั งานมีความเป็ นอิสระต่อกัน ไม่ข้ ึนต่อกัน

คอมโพเน้นท์ของซอฟต์แวร์ จะต้องมีลกั ษณะการขึ้นต่อกันน้อยที่สุด (Loosely
Coupled)
หลักการพืน้ ฐานในการออกแบบซอฟต์ แวร์
Abstraction
 Refinement
 Architecture
 Patterns
 Modularity
 Information Hiding
 Refactoring
 Functional independence

Abstraction
การกาหนดสาระสาคัญ โดยสามารถกาหนดสาระสาคัญได้หลาย
ระดับ
 เป็ นแนวคิดพืน
้ ฐานในการออกแบบ

 Procedural Abstraction
 Data Abstraction
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
Procedural Abstraction

“Open”
1. เดินไปทีป่ ระตู
2. ยืน่ มือไปทีล่ ูกบิด
3. หมุนลูกบิด
4. ดึงประตู
5. เดินเข้ าประตู
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
Refinement


การลงรายละเอียดเพิ่มเติมรายละเอียดกระบวนการทางาน
จากประโยคที่ระบุหน้าที่ไปทีละขั้นตอน จนกว่าจะได้ประโยคภาษา
โปรแกรม
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
Architecture

สถาปัตยกรรมซอฟต์แวร์ (Software Architecture) หมายถึง การแสดง
ความสัมพันธ์ระหว่างระบบย่อยและส่ วนประกอบ (คอมโพเน้นท์) เพื่อ
กาหนดโครงสร้างหรื อระบบภายในซอฟต์แวร์

เป้ าหมายของการออกแบบสถาปัตยกรรมคือ ให้เป็ นกรอบในการ
ออกแบบส่ วนประกอบของระบบให้เป็ นในทิศทางเดียวกันและอยูบ่ น
สถาปัตยกรรมเดียวกัน
Patterns



การใช้โครงสร้างตัวแบบมาช่วยแก้ปัญหาการออกแบบ
โดยนาหลักและวิธีการแก้ปัญหาชนิดหนึ่งชนิดใดจากตัวแบบ จะ
สามารถนาไปใช้กบั ปัญหาชนิดเดียวกันที่เกิดขึ้นซ้ าได้
การใช้ pattern จะช่วยให้งานผลิตซอฟต์แวร์ดาเนินไปได้อย่างรวดเร็ ว
ประหยัดเวลาในการออกแบบ
Modularity
 การแบ่งระบบหรื อซอฟต์แวร์ แยกออกเป็ นส่ วนๆ แต่ละส่ วน
เรี ยกว่า “โมดูล” (Module) ซึ่งจะประกอบกันได้เพื่อทางานตาม
ความต้องการ
Modularity
module development cost
cost of
software
module
integration
cost
optimal number
of modules
number of modules
Information Hiding

โมดูลจะต้องซ่อนรายละเอียดการทางานไว้ ไม่วา่ จะเป็ นอัลกอริทมึ หรือ
ข้อมูลของโมดูล เพือ่ ป้องกันการเข้าถึงข้อมูลภายในโมดูลโดยไม่จาเป็ น
Information Hiding
module
controlled
interface
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision
Refactoring


เป็ นเทคนิคในการปรับโครงสร้างการออกแบบ
เป็ นการจัดระเบียบใหม่ เพื่อให้งานออกแบบองค์ประกอบย่อย หรื อตัวโค้ดมี
ลักษณะที่ง่ายขึ้น โดยไม่ไปเปลี่ยนแปลงพฤติกรรมของการทางาน
ตัวอย่ าง Refactoring

Collapse Hierarchy
A superclass and subclass are not very different.

Merge them together.
ตัวอย่ าง Refactoring


Inline Method
A method's body is just as clear as its name.
Put the method's body into the body of its callers and remove
the method.
int getRating() {
return (moreThanFiveLateDeliveries()) ? 2 : 1;
}
boolean moreThanFiveLateDeliveries() {
return _numberOfLateDeliveries > 5;
}
int getRating() {
return (_numberOfLateDeliveries > 5) ? 2 : 1;
}
Functional independence
การออกแบบให้โมดูลมีความเป็ นอิสระต่อกัน
 โมดูลที่เป็ นอิสระต่อกันจะง่ายต่อการบารุ งรักษา
 การประเมินระดับของความเป็ นอิสระของโมดูล ประเมินได้จาก
 ความแข็งแกร่ งของโมดูล (Cohesion)
 ความสัมพันธ์ระหว่างโมดูล (Coupling)

Functional independence
ความเป็ นอิสระ
โมดูล
Modular Design
Cohesion
Functional Cohesion
 Sequence Cohesion
 Communicational Cohesion
 Procedural Cohesion
 Temporal Cohesion
 Logical Cohesion
 Coincidental Cohesion

Good
Bad
Functional Cohesion
M1
Compute price
M2
Select Seat
M3
Verify Customer
Sequence Cohesion
M1
Function A
Function B
Function C
Communicational Cohesion
book
M1
Find Title of Book
Find Price of Book
Find Publisher of Book
Find Author of Book
Procedural Cohesion
M1
Function A
Function B
Function C
Temporal Cohesion
M1
Time to initial
Time to + x
Time to + 2x
Logical Cohesion
M1
Go by Car
Go by Train
Go by Boat
Go by Plane
Coincidental Cohesion
M1
Function A
Function B
Function C
Function E
Function F
Coupling
Data Coupling
 Stamp Coupling
 Control Coupling
 Common Coupling
 Content Coupling

Good
Bad
Data Coupling
Edit student
record
Student name
Student ID
Student address
course
Student record
EOF
Retrieve student
record
X Data Coupling
Edit student
record
Student ID
Student record
EOF
Retrieve student
record
 Data Coupling
Stamp Coupling
Edit student
record
Student name
Student ID
Student address
course
Student
Student record
EOF
Retrieve student
record
Control Coupling
Edit student
record
Student ID
flag
Done (True or false)
Retrieve student
record
Student record
EOF
Common Coupling
Module M1
----Change A1 to Zero
Module M13
----Increment A3
Global:
A1
A2
A3
Variables:
V1
V2
Module M21
----sum = V2+A2
Content Coupling
M1
Module 12
----Goto D1
M12
M13
M21
----D1
Target of Module Design
High Cohesion
 Low Coupling

low cohesion
high cohesion
High coupling
Low coupling
แบบจาลองทีใ่ ช้ ในการออกแบบ


กลุ่ม Structural Description (Static View)
กลุม่ Behavioral Description (Dynamic View)
แบบจาลองทีใ่ ช้ ในการออกแบบ

กลุม่ Structural Description (Static View) เช่น
 Architecture Description Language ADU
 Class And Object Diagram
 Component Diagram
 Deployment Diagram
 Entity Relationship Diagram ERD
 Interface Description Language IDL
 Jackson Structure Diagram
 Structure Chart
แบบจาลองทีใ่ ช้ ในการออกแบบ

กลุม่ Behavioral Description (Dynamic View) ได้แก่
 Activity Diagram
 Collaborative Diagram
 Data Flow Diagram
 Decision Table
 Flowchart and Structure Flowchart
 Sequence Diagram
 Pseudo-code and Program Design Language PDL