Transcript 290355 Software Engineering

290355 Software Engineering
บทที่ 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
 เป็ นการกาหนดลักษณะโครงสร้างของระบบหรื อมุมมองด้านบน
Top-Level Design
ระดับของกระบวนการออกแบบ
ซอฟต์ แวร์

การออกแบบในรายละเอียด Detailed Design

เรี ยกว่า Implementation Design เป็ นการอธิ บายรายละเอียดของ
แต่ละส่ วนประกอบของซอฟต์แวร์ เพื่อเอื้ออานวยความสะดวกกับการ
เขียนโปรแกรมให้ได้มากที่สุด
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์


กลยุทธ์ในการออกแบบซอฟต์แวร์ เป็ นเพียงหลักและแนวทางในการ
ปฏิบตั ิงานแบบซอฟต์แวร์เท่านั้น ไม่ได้ระบุถึงวิธีทางานอย่างชัดเจน
แต่สาหรับระเบียบวิธี ในการออกแบบซอฟต์แวร์จะระบุถึงรายละเอียดของ
วิธีการทางานอย่างชัดเจน พร้อมกับเตรี ยมสัญลักษณ์ต่างๆ ของแบบจาลอง
เฉพาะระเบียบวิธีน้ นั ไว้ให้ใช้งานด้วย ทาให้ทีมวิศวกรซอฟต์แวร์ทางานได้
ง่ายขึ้น
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์





กลยุทธ์ทวไปในการออกแบบซอฟต์
ั่
แวร์ (General Strategy)
การออกแบบเชิงฟงั ก์ชนั (Function-Oriented Design)
การออกแบบเชิงวัตถุ (Object-oriented Dsign)
การออกแบบโดยใช้ขอ้ มูลเป็ นศูนย์กลาง (Data-structure Centered
Design)
การออกแบบคอมโพเน้นท์ (Component-base Design: CBD)
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์

กลยุทธ์ทวไปในการออกแบบซอฟต์
ั่
แวร์ (General Strategy)
 เป็ นกลยุทธ์ในการออกแบบซอฟต์แวร์ทวไป
ั ่ เช่น
 Top-Down and Bottom-up
 Divide-and Conquer
 Design Pattern
 Stepwise Refinement
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์

การออกแบบเชิงฟั งก์ชนั (Function oriented Design)
 คือ การออกแบบเชิงโครงสร้าง ซึง
่ เป็ นระเบียบวิธที ไ่ี ด้รบั ความนิยมมาตัง้ แต่
อดีตจนถึงปจั จุบนั
 เป็ นวิธก
ี ารพิจารณาถึงฟงั ก์ชนั ของซอฟต์แวร์เป็ นเกณฑ์ในการแบ่ง
ซอฟต์แวร์ออกเป็ นส่วนย่อย
 กาหนดรายละเอียดในแต่ละส่วนย่อย และปรับปรุงในลักษณะโครงสร้าง
ลาดับขัน้ จากบนลงล่าง
 ใช้ แผนภาพกระแสข้อมูล ประกอบ
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์

การออกแบบเชิงวัตถุ (Object Oriented Design)
 พิจารณาหาวัตถุในโดเมนทีส
่ นใจจากคาอธิบายความต้องการของผูใ้ ช้
 คานาม
 กริยา
 โครงสร้างการสืบทอด
 ใช้เครือ
่ งมือ ทางการออกแบบเชิงวัตถุเข้ามาช่วยประกอบกัน
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์

การออกแบบโดยใช้ข้อมูลเป็ นศูนย์กลาง (Data structure Centered
Design)



เป็ นวิธกี ารออกแบบโดยใช้ขอ้ มูลทีฟ่ งั ก์ชนั จะนามาประมวลผลเป็ นหลัก
เริม่ ต้นจากการแสดงโครงสร้างข้อมูล ทัง้ ทีเ่ ป็ นข้อมูลนาเข้าและผลลัพธ์ (Input and
Output Data) โดยสร้างเป็ นแผนภาพเพือ่ จาลองโครงสร้างของข้อมูลเหล่านัน้
ยกตัวอย่างแผนภาพเช่น Jackson Structure Diagram เป็ นต้น
จากนัน้ ทีมงานจะนาแผนภาพดังกล่าวไปออกแบบโครงสร้างควบคุมการทางานของ
โปรแกรมต่อไป
Jackson Structure Diagram

Jackson Structure Diagram (JSD)
เพื่ออธิบายโครงสร้างของโปรแกรมเช่นเดียวกับ Structure Chart
ลักษณะ JSD เหมือนแผนภูมิตน้ ไม้ (tree) ซึ่ งแต่ละโหนด (node)
แทนโมดูล โดยที่โหนดที่อยูร่ ะดับบนสุ ดเป็ นโมดูลควบคุมหรื อ
ขั้นตอนหลัก
 การทางานแบบเป็ นลาดับ (Sequence)
 การเลือก (selection)
 การทาซ้ า (iteration)
Jackson Structure Diagram
 ไดอะแกรมนี้แสดงความสัมพันธ์ของข้อมูล (Entity) และกิจกรรม
(Action) ว่าแต่ละตารางมีกจิ กรรมอะไรบ้าง
 การทางานเป็ นแบบลาดับ (sequence)
 มีสญ
ั ลักษณ์วงกลมเล็กมุมบนขวาแสดงกิจกรรมเลือก (selection)
 สัญลักษณ์ asterisk แสดงการทาซ้า
 ส่วนโครงสร้างไดอะแกรมคล้ายกับ Organization Chart จากบนลงล่าง
ข้อมูลจาก http://www.smartdraw.com/tutorials/software/jsd/tutorial_01.htm
Jackson Structure Diagram
ข้อมูลจาก http://www.smartdraw.com/tutorials/software/jsd/tutorial_01.htm
Jackson Structure Diagram (JSD)
Make tea
Warm teapot
Add boling
water to pot
Put tea in pot
Spoon tea
from caddy
Use chinese tea
*
Use indian tea
แสดงตัวอย่างการอธิบายวิธีชงชาด้วย JSD
Pour tea
into cups
กลยุทธ์ และระเบียบวิธีการออกแบบ
ซอฟต์ แวร์

การออกแบบคอมโพเน้ นท์ (Component-base Design: CBD)
 เป็ นวิธก
ี ารออกแบบซอฟต์แวร์ดว้ ยการแบ่งเป็ นส่วนประกอบย่อยที่เรียกว่า
คอมโพเน้นท์
 แต่ละคอมโพเน้นท์ จะทางานเป็ นอิสระต่อกัน ทางานได้ดว
้ ยตนเอง และ
สามารถประกอบเข้ากันได้เมือ่ ทางานเสร็จ
 สามารถประกอบกับคอมโพเน้นท์อ่น
ื เพือ่ เติมเต็มการทางานให้กบั
ซอฟต์แวร์ได้
 ดังนัน
้ จึงต้องมีการสือ่ สารระหว่างคอมโพเน้นท์ผา่ นทาง Interface
 ถูกพัฒนาขึน
้ เพือ่ ตอบสนองความต้องการผลิตซอฟต์แวร์ทส่ี ามารถนา
กลับมาใช้ ใหม่ได้
การออกแบบซอฟต์ แวร์

จากขัน้ ตอนการวิเคราะห์จะทาให้ได้ขอ้ มูล เพือ่ จะนาไปสร้างแบบจาลอง
ทัง้ 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
แบบจาลองการออกแบบ(Design Model)




Data/Class Design
Architecture Design
Interface Design
Component-level Design
แบบจาลองการออกแบบ(Design Model)


Data/Class Design
เป็ นการออกแบบข้อมูล เนื้อหาทีจ่ ะใช้ในระบบ : แอตทริบวิ ส์ คลาส
Architecture Design
การออกแบบสถาปตั ยกรรม -- ความสัมพันธ์ระหว่างส่วนประกอบเชิง
โครงสร้างหลักๆ ของซอฟต์แวร์ สไตล์ และรูปแบบสถาปตั ยกรรม เอามา
จากข้อกาหนดระบบ แบบจาลองการวิเคราะห์
แบบจาลองการออกแบบ(Design Model)


Interface Design
การออกแบบส่วนติดต่อกับผูใ้ ช้ เพือ่ การนาเสนอ และใช้งานซอฟต์แวร์
ต้องคานึงถึงลาดับและขัน้ ตอนการทางานของระบบ
Component-level Design
การออกแบบระดับรายละเอียด เป็ นการออกแบบโปรแกรมย่อยหรือ
ฟงั ก์ชนย่
ั ่ อยต่างๆ ของระบบ ทีจ่ ะประกอบเป็ นระบบ
หลักการออกแบบซอฟต์แวร์



การออกแบบควรแสดงให้เห็นถึงรูปแบบสถาปตั ยกรรมทีเ่ ลือกใช้อย่าง
ชัดเจนและมีแบบแผน
การออกแบบควรมิลกั ษณะเป็ นโมดูล
การออกแบบควรนาเสนอด้านข้อมูล สถาปตั ยกรรม ส่วนประสาน และ
คอมโพเน้นท์ทช่ี ดั เจน

ควรออกแบบคอมโพเน้นท์ให้มอี สิ ระต่อกัน

ควรออกแบบให้สว่ นประสานระหว่างคอมโพเน้นท์กบั สภาพแวดล้อม
ภายนอกมีความซับซ้อนน้อยทีส่ ุด
หลักการออกแบบซอฟต์แวร์

การออกแบบควรนาข้อมูลมาจากการวิเคราะห์ระบบ และใช้ระเบียบวิธี
ปฏิบตั เิ ดียวกัน

สัญลักษณ์ทใ่ี ช้ในการออกแบบควรสือ่ ความหมายได้ชดั เจน และเป็น
มาตรฐาน

งานออกแบบควรมีโครงสร้างทีด่ ี เพือ่ การแก้ไขทีง่ า่ ยและใช้ตน้ ทุนน้อย

การออกแบบในระดับคอมโพเน้นท์มลี กั ษณะแบบ Functional
Independence คือ ฟงั ก์ชนั งานมีความเป็ นอิสระต่อกัน ไม่ขน้ึ ต่อกัน

คอมโพเน้นท์ของซอฟต์แวร์จะต้องมีลกั ษณะการขึน้ ต่อกันน้อยทีส่ ุด
(Loosely Coupled)
หลักการพืน้ ฐานในการออกแบบซอฟต์แวร์
 Abstraction
 Refinement
 Architecture
 Patterns
 Modularity
 Information Hiding
 Refactoring
 Functional independence
Abstraction

การกาหนดสาระสาคัญ เป็ นพืน้ ฐานทางความคิดในการออกแบบ
เราสามารถกาหนดสาระสาคัญได้หลายระดับ ระดับบนสุดนัน้ จะ
อธิบายในภาพรวมของปญั หาและสถาพแวดล้อมภายนอก ในระดับ
ถัดมาจะอธิบายถึงวิธกี ารแก้ปญั หาค่อนข้างละเอียด
 Procedural Abstraction
-- เชิงกระบวนการทางาน : ลาดับ
ของคาสังที
่ ท่ าหน้าทีเ่ ฉพาะเจาะจงอย่างหนึ่ง
 Data Abstraction -- เชิงข้อมูล : เป็ นชือ
่ ของข้อมูลทีอ่ ยูใ่ น
Procedural 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) ซึง่ จะประกอบกันได้เพือ่ ทางานตามความต้องการ
 easier to build, easier to change, easier to fix
 การแบ่งระบบเป็ นโมดูลจะช่วยให้การออกแบบงานในแต่ละส่วนง่าย
ขึน้ นอกจากนี้ยงั ช่วยให้การวางแผนพัฒนา การแก้ไขหรือ
เปลีย่ นแปลง ตลอดจนการทดสอบและซ่อมบารุงเป็ นเรือ่ งง่าย

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


การแยกส่วนประกอบใหม่ เป็ นเทคนิคในการปรับโครงสร้างการออกแบบ เป็ น
การจัดระเบียบใหม่ เพือ่ ให้งานออกแบบองค์ประกอบย่อย หรือตัวโค้ด ที่
ลักษณะทีง่ า่ ยขึน้ โดยไม่ไปเปลีย่ นแปลงพฤติกรรมของการทางาน
When software is refactored, the existing design
is examined for:
 สิ่ งเกินความจาเป็ น
 ไม่ได้ใช้ส่วนออกแบบ
 วิธีคิดไร้ประสิ ทธิ ภาพหรื อไม่จาเป็ น
 โครงสร้างข้อมูลไม่เหมาะสม
 หรื อการออกแบบใดๆ ที่ลม
้ เหลว ที่สามารถแก้ไขได้ดีกว่า
ตัวอย่าง 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



การออกแบบให้โมดูลมีความเป็ นอิสระต่อกัน โมดูลควรทาหน้าทีเ่ ดียว
หลีกเลีย่ งการมีปฏิสมั พันธ์กบั โมดูลอื่นๆ
โมดูลทีเ่ ป็ นอิสระต่อกันจะง่ายต่อการบารุงรักษา เพราะผลกระทบจากการ
เปลีย่ นแปลงมีอยูจ่ ากัด ลดการแพร่กระจายความผิดพลาด และมีความเป็ นไป
ได้ทจ่ี ะนากลับมาใช้ใหม่
การประเมินระดับของความเป็ นอิสระของโมดูล ประเมินได้จาก
 ความสัมพันธ์ระหว่างโมดูล (Coupling)
 ความแข็งแกร่งของโมดูล (Cohesion)
Functional independence


Coupling เป็ นการวัดความสัมพันธ์ระหว่างโมดูล 2 โมดูลว่ามีความ
ซับซ้อนหรือมีระดับการขึน้ ต่อกันของโมดูลมากน้อยเพียงใด โครงสร้าง
ของโมดูลทีด่ จี ะต้องมีระดับการขึน้ ต่อกันของโมดูลน้อย (Loosely
Coupled)
Cohesion
เป็ นการวัดระดับการยึดเกาะกันของหน้าทีห่ รือกิจกรรม
ในโมดูล เพือ่ ประมวลผลข้อมูลให้ได้เป็ นผลลัพธ์ทต่ี อ้ งการ ลักษณะของ
โมดูลทีด่ จี ะต้องมีระดับการยึดเกาะกันของหน้าทีใ่ นโมดูลสูง (High
Cohesion) โดยทีม่ กี ารปฏิสมั พันธ์กบั โมดูลอื่น กิจกรรมอื่นในโมดูล หรือ
ระบบอื่นน้อยทีส่ ุด
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

เป็ นโมดูลหรือฟงั ก์ชนั ทีไ่ ม่มคี วามสัมพันธ์กนั แต่หน้าทีห่ รือฟงั ก์ชนั
ทีโ่ มดูลนัน้ รับผิดชอบอยูก่ ลับต้องไปทางานต่อเนื่องในกระบวนการ
เดียวกัน เช่น โมดูลทีเ่ กิดจากคาสัง่ IF, while เป็ นต้น
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

ทัง้ สองโมดูลมีความสัมพันธ์กนั โดยการส่งข้อมูลระหว่างกัน แต่เป็ นข้อมูล
ควบคุมหรือ flag
Edit student
record
Student ID
flag
Done (True or false)
Retrieve student
record
Student record
EOF
Common Coupling

โมดูลมีการใช้ Global Variable ร่วมกัน
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
 Collaboration Responsibility Card CRC
 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 and Diagram
 Flowchart and Structure Flowchart
 Sequence Diagram
 Formal Specification Language
 Pseudo-code and Program Design Language PDL
Assignment

ให้นิสิตค้นคว้าหาข้อมูลเกี่ยวกับรู ปแบบของสถาปัตยกรรมซอฟต์แวร์
ต่อไปนี้





Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures