Software Design

vs
Design Engineering
 Software Design
การออกแบบซอฟต์แวร์ (software design) คือ
กระบวนการกาหนดสถาปตั ยกรรม (architecture) ส่วนประกอบ
(component) ส่วนประสาน (interface)และลักษณะด้านอื่น
ๆ ของระบบหรือส่วนประกอบของระบบ โดยการออกแบบซอฟต์แวร์ยงั มี
ความหมายรวมถึงสิง่ ทีไ่ ด้จากการออกแบบ ซึง่ ก็คอื “แบบจาลองของการ
ออกแบบ (design model)” อีกด้วย
กล่าวอีกนัย software design มีลกั ษณะการทางานแบบ
ซ้า ๆ เนื่องจากต้องนา user requirements ทีผ่ า่ นการวิเคราะห์
แล้ว ทัง้ ด้านข้อมูล ฟงั ก์ชนั งาน และส่วนประสาน มาแปลงเป็ นข้อกาหนดของ
การออกแบบ
 Design Engineering
• วิศวกรรมการออกแบบรวบรวมหลักการ แนวความคิด และวิธปี ฏิบตั ทิ น่ี าไปสูก่ ารพัฒนา
ระบบหรือซอฟต์แวร์ทม่ี คี ุณภาพสูง โดยมีเป้าหมายสาคัญ มีดงั นี้
o Firmness ซอฟต์แวร์ทไ่ี ด้จากการออกแบบจะต้องไม่มขี อ้ ผิดพลาด
o Commodity ซอฟต์แวร์ตอ้ งตรงกับวัตถุประสงค์การใช้งาน
o Delight ซอฟต์แวร์ตอ้ งทาให้ผใู้ ช้รสู้ กึ พอใจ
แบบจำลองของกำรออกแบบ (Design Model)
 Design Model
• Data/Class
Design
การออกแบบข้อมูลหรือคลาส
• Architectural
Design
• เป็ นการออกแบบข้อมูลทีจ่ าเป็ นต่อการพัฒนา
• User Interface ซอฟต์แวร์หรือจาเป็ นใช้ในซอฟต์แวร์ หรือการออกแบบ
Design
• Component- คลาส และความสัมพันธ์ระหว่างคลาส
level Design
 Design Model
• Data/Class
Design
การออกแบบเชิงสถาปตั ยกรรม
• Architectural • การแสดงให้ผใู้ ช้มองเห็นถึงส่วนประกอบ ความสัมพันธ์ระหว่าง
Design
• User Interface
ส่วนประกอบเชิงโครงสร้างของซอฟต์แวร์ และรูปแบบเชิง
Design สถาปตั ยกรรม เพือ่ ให้ประสบผลตามความต้องการของระบบ
• Component- โดยคานึงถึงข้อจากัดต่าง ๆ ในการพัฒนา
level Design
 Design Model
• Data/Class
Design
การออกแบบส่วนต่อประสาน
• Architectural • การออกแบบหน้าจอทีใ่ ช้ตดิ ต่อสือ่ สารกับผูใ้ ช้งานซอฟต์แวร์
Design
• User Interface ซึง่ ต้องคานึงถึงลาดับและขัน้ ตอนการทางานของซอฟต์แวร์
Design และระบบอื่นทีจ่ ะใช้บริการ โดยไม่จาเป็ นต้องทราบถึง
• Component-
level Design รายละเอียดการทางานภายในระบบย่อย
 Design Model
• Data/Class
Design
การออกแบบระดับส่วนประกอบ
• Architectural • การออกแบบโปรแกรมย่อย ฟงั ก์ชนั ย่อย หรือโมดูลย่อย
Design
• User Interface ต่างๆ ของซอฟต์แวร์ทป่ี ระกอบกันเป็ นระบบหรือซอฟต์แวร์
Design
• Component-
level Design
 Quality Attributes
1. Designability 12. Memory
2. Efficiency 13. Timing Constraints
3. Human Engineering 14. Usability
4. Modifiability 15. Throughput
5. Portability 16. Robustness
6. Reliability 17. Availability
7. Testability 18. Fault Tolerant
8. Understandability 19. Security
9. Capacity 20. Extensibility
10. Degradation of Service 21. Readability
11. Maintainability 22. etc.
Quality Analysis and Evaluation
การวิเคราะห์และประเมินคุณภาพเป็ นกิจกรรมทีช่ ว่ ยให้มนใจได้
ั่ วา่ ซอฟต์แวร์ทถ่ี ูกออกแบบไว้จะต้อง
มีคุณภาพ โดยสามารถใช้เครือ่ งมือและเทคนิคต่าง ๆ แบ่งตามกิจกรรมดังนี้
1. การทบทวนงานออกแบบซอฟต์แวร์ (software design review) เทคนิคช่วยให้การ
ทบทวนงานออกแบบมีประสิทธิภาพ ได้แก่ group-based technique เป็ นเทคนิคใน
การตรวจสอบและปรับปรุงคุณภาพของงานออกแบบ เช่น การทบทวนสถาปตั ยกรรม
ซอฟต์แวร์ และการตรวจสอบอย่างละเอียด เป็ นต้น
2. วิเคราะห์งานออกแบบ (static analysis) ผลทีไ่ ด้จากการวิเคราะห์จะนาไปประเมิน
คุณภาพของงานออกแบบ เทคนิคทีช่ ว่ ยให้การวิเคราะห์มปี ระสิทธิภาพ เช่น fault-tree
analysis, auto-cross checking เป็ นต้น
3. การจาลองสถานการณ์และการสร้างต้นแบบ (simulation and prototyping)
เช่น การจาลองประสิทธิภาพของซอฟต์แวร์ และการสร้างต้นแบบเพือ่ ทดสอบความเป็ นไปได้
เป็ นต้น
 Quality Measurement
การวัดคุณภาพของซอฟต์แวร์ขน้ึ อยูก่ บั แนวทางในการออกแบบ แบ่งเป็ น 2 ประเภท ดังนี้
1. การวัดการออกแบบเชิงฟงั ก์ชนั (function-oriented design
measurement) ใช้กบั ซอฟต์แวร์ทอ่ี อกแบบด้วยแนวทางเชิงโครงสร้าง ทีม่ กี ารแบ่ง
ระบบใหญ่ออกเป็ นระบบย่อยตามหน้าที่ ทีเ่ รียกว่า Module และนาเสนอด้วยแผนภาพ
เชิงโครงสร้าง (structure chart) ดังนัน้ การวัดคุณภาพประเภทนี้จงึ วัดได้จาก
คุณลักษณะของ Module เช่น Coupling and Cohesion เป็ นต้น
2. การวัดการออกแบบเชิงวัตถุ (object-oriented design measurement)
ใช้กบั ซอฟต์แวร์ทอ่ี อกแบบด้วยแนวทางเชิงวัตถุ นาเสนอโครงกสร้างด้วย class
diagram ดังนัน้ การวัดคุณภาพประเภทนี้ วัดจากลักษณะภายใน class เช่น การวัด
ความสัมพันธ์ระหว่างคลาส การนับจานวนการโต้ตอยระหว่างเมธอดของคลาส เป็ นต้น
 หลักกำรออกแบบซอฟต์แวร์
1. ควรแสดงให้เห็นรูปแบบสถาปตั ยกรรมทีเ่ ลือกใช้อย่างชัดเจนและมีแบบแผน
2. ควรมีลกั ษณะเป็ น module
3. ควรเสนอด้านข้อมูล สถาปตั ยกรรม ส่วนประสาน และคอมโพเน้นท์ทช่ี ดั เจน
4. ควรออกแบบคอมโพเน้นท์ให้มอี สิ ระต่อกัน
5. ควรออกแบบส่วนประสานระหว่างคอมโพเน้นท์กบั สภาพแวดล้อมภายนอกให้มคี วามซับซ้อน
น้อยทีส่ ุด
6. ควรนาข้อมูลมาจากการวิเคราะห์ระบบ
7. ควรใช้สญ ั ลักษณ์ในการออกแบบทีเ่ ป็ นมาตรฐานและสือ่ ความหมายได้อย่างชัดเจน
8. ควรมีโครงสร้างทีด่ ี เพือ่ ง่ายต่อการแก้ไข
9. ควรออกแบบในลักษณะ functional independence หรือ loosely coupled
 กำรออกแบบข้อมูลหรือคลำส
• Data/Class Data - Function-oriented design
Design
o Structured flowchart/flowchart
• Architectural
Design o Data flow diagram
• User Interface o Pseudo-code
Design o ER diagram
• Component- o …
level Design
Class - Object-oriented design
o Class diagram
o Object diagram
o Component diagram
o Activity diagram
o Collaborative diagram
o Sequence diagram
o …
 กำรออกแบบเชิงสถำปัตยกรรม
• Data/Class o หมายถึง การกาหนดลักษณะโครงสร้างของซอฟต์แวร์ในมุมมองระดับบน
Design
เป็ นการแสดงให้เห็นส่วนประกอบต่าง ๆ ของซอฟต์แวร์ภายใต้โครงสร้าง
• Architectural
Design สถาปตั ยกรรมรูปแบบใดๆ กล่าวโดยสรุป คือ การเลือกรูปแบบ
• User Interface สถาปตั ยกรรมให้กบั ซอฟต์แวร์
Design
• Component-
• การออกแบบมี 2 ระดับ ดังนี้
level Design o การออกแบบเชิงสถาปตั ยกรรม (Architectural Design) หรือเรียกอีกอย่าง
หนึ่งว่า Top-level Design เป็ นการกาหนดลักษณะโครงสร้างของระบบในมุมมอง
ระดับบน กล่าวคือ เป็ นการแสดงให้เห็นส่วนประกอบต่าง ๆ ของระบบภายใต้โครงสร้าง
สถาปตั ยกรรมรูปแบบใดๆ
o การออกแบบในรายละเอียด (Detailed Design) หรือเรียกอีกอย่างหนึ่งว่า
Implementation Design เป็ นการอธิบายรายละเอียดของแต่ละส่วนประกอบ
องระบบเพือ่ เอือ้ อานวยต่อการเขียนโปรแกรมให้มากทีส่ ุด
 กำรออกแบบเชิงสถำปัตยกรรม
• Data/Class
Design
• Architectural
Design
• User Interface
Design
• Component-
level Design
Architectural
Design
Detailed Design
 รูปแบบเชิงสถำปัตยกรรม
• Data/Class การเลือกรูปแบบเชิงสถาปตั ยกรรม (Architectural Style) ให้กบั ซอฟต์แวร์ นับว่า
Design เป็ นสิง่ สาคัญของการออกแบบ ซึง่ ในปจั จุบนั มีรปู แบบหลากหลายรูปแบบ เช่น
• Architectural
1. Pipes and Filters
Design
• User Interface 2. Call and Return
Design 3. Client/Server
• Component- 4. Model View Controller
level Design 5. Layered Style
6. Database Centric Style
7. Three Tier
 Pipes and Filters
• Data/Class ข้อดี คือ เข้าใจง่าย และสามารถเพิม่ กระบวนการใหม่ได้งา่ ย เนื่องจากเป็ นการ
Design
เพิม่ ในลักษณะเรียงลาดับต่อเนื่องไปเรือ่ ยๆ
• Architectural
Design ข้อเสีย คือ ไม่เหมาะกับงานทีม่ กี ารประมวลผลแบบโต้ตอบทันที และข้อมูลที่
• User Interface ส่งไปตามท่อจะต้องมีรปู แบบเดียวกัน
Design
• Component-
level Design
 Call and Return
• Data/Class ข้อดี คือ ง่าย และเหมาะสาหรับภาษาโปรแกรมเชิงโครงสร้าง
Design
• Architectural ข้อเสีย คือ ทาให้การทางานของระบบช้า
Design
• User Interface
Design
• Component-
level Design
 Client/Server
• Data/Class ข้อดี คือ Client สามารถเข้าถึงข้อมูลได้โดยตรง
Design
• Architectural ข้อเสีย คือ หาก Server พังหรือเสียหายจะทาให้งานหยุดชะงัก และ
Design Client ไม่สามารถติดต่อมาที่ Server ได้ ปญั หานี้แก้ได้โดยการติดตัง้
• User Interface Server หลายตัว
Design
• Component-
level Design
 Client/Server
• Data/Class ข้อดี คือ Server อิสระต่อกัน ทางานแตกต่างกัน และสามารถกระจายการ
Design
ประมวลผล ทาให้การปรับปรุง Server ไม่กระทบต่อทัง้ ระบบ
• Architectural
Design ข้อเสีย คือ เกิดปญั หาความซ้าซ้อนของข้อมูลและค่าใช้จา่ ยสูง
• User Interface
Design
• Component-
level Design
 Model View Controller
• Data/Class ข้อดี คือ ทาให้มคี วามยืดหยุน่ ในการออกแบบระบบ พร้อมทัง้ รองรับการ
Design
ทางานแบบกระจาย และการประมวลผลทีม่ ปี ระสิทธิภาพ
• Architectural
Design
• User Interface
Design
• Component-
level Design
 Layered Style
• Data/Class ข้อดี คือ สามารถเตรียมได้หลาย platforms
Design
• Architectural ข้อเสีย คือ ประสิทธิภาพการทางานอาจลดลง เนื่องจากมีการส่งคาสังผ่
่ านส่วน
Design ต่อประสานหลายชัน้
• User Interface
Design
• Component-
level Design
 Database Centric Style
• Data/Class ข้อดี คือ ง่ายสาหรับการเข้าถึงข้อมูลใน database
Design
• Architectural ข้อเสีย คือ ข้อมูลไม่มกี ารบูรณภาพ เนื่องจากผูใ้ ช้แต่ละคนแก้ไขข้อมูลใน
Design database ได้โดยตรง และหาก database เสียหาย จะทาให้ระบบ
• User Interface หยุดชะงัก และไม่สามารถเข้าถึงข้อมูลได้
Design
• Component-
level Design
 Three Tier
• Data/Class ข้อดี คือ ระบบมีความยืดหยุน่ และข้อมูลมีความบูรณภาพ
Design
• Architectural
Design
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class การวิเคราะห์สว่ นประสานทีเ่ กีย่ วข้อง ได้
Design
• Architectural • การวิเคราะห์ผใู้ ช้
Design o ผูใ้ ช้หน้าใหม่
• User Interface o ผูใ้ ช้ทม่ี ปี ระสบการณ์และความรูร้ ะดับกลาง
Design o ผูใ้ ช้งานเป็ นประจาหรือผูเ้ ชีย่ วชาญ
• Component-
level Design
• การวิเคราะห์งาน
o ลักษณะงานของผูใ้ ช้ รวมถึงลาดับของงงานทัง้ หมด
• การวิเคราะห์เนื้อหา
o เอกสารทีเ่ กีย่ วข้อง รูปแบบการแสดงผลลัพธ์ เนื้อหา และวิธกี ารนาเสนอ
• การวิเคราะห์สภาพแวดล้อม
o สถาพแวดล้อมของระบบและข้อจากัดทางกายภาพทีอ่ าจเป็ นอุปสรรคในการใช้งาน
ระบบ เช่น เสียงดัง พืน้ ทีแ่ คบ
o วัฒนธรรมในการทางาน เช่น การอนุมตั งิ านเป็ นลาดับชัน้
 กำรออกแบบส่วนต่อประสำน
• Data/Class คือ การนาข้อมูลทีไ่ ด้จากขัน้ ตอนของการวิเคราะห์สว่ นต่อประสาน เพือ่
Design
ออกแบบส่วนต่อประสานหรือจัดทาต้นแบบให้กบั ผูใ้ ช้ แบ่งเป็ น 4 ขัน้ ตอน คือ
• Architectural
Design 1. กาหนดวัตถุและการดาเนินการของผูใ้ ช้
• User Interface 2. กาหนดเหตุการณ์ทเ่ี ป็ นการกระทาของผูใ้ ช้
Design
• Component- 3. แสดงหน้าจอของส่วนต่อประสานทีผ่ ใู้ ช้จะใช้งานระบบ
level Design 4. อธิบายความหมายของข้อมูลทีแ่ สดงในส่วนต่อประสานเพือ่ ให้ผใู้ ช้เข้าใจ
ระบบ
 กำรออกแบบส่วนต่อประสำน
• Data/Class ข้อคานึงในการออกแบบส่วนต่อประสานกับผูใ้ ช้ ได้แก่
Design
• Architectural 1. เวลาในการตอบสนอง
Design 2. การช่วยเหลือผูใ้ ช้งาน
• User Interface
Design 3. การจัดการความผิดพลาด
• Component- 4. การกาหนดรายการเลือกและชือ่ คาสัง่
level Design
5. การเข้าถึงระบบ
6. ความเป็ นสากลด้านภาษา
 กำรออกแบบส่วนต่อประสำน
• Data/Class การออกแบบส่วนต่อประสานกับผูใ้ ช้ มีหลักเกณฑ์ 2 ประการ ได้แก่
Design
• Architectural 1. การไหลของการปฏิสมั พันธ์ (flow of interaction)
Design o การเรียงลาดับข้อมูลได้อย่างเหมาะสม
• User Interface
Design 2. การมองเห็นและความรูส้ กึ (look and feel)
• Component- o การเลือกใช้ icon และสีทเ่ี หมาะสม
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 1. การปฏิสมั พันธ์ดว้ ยภาษาคาสัง่ (command language
Design interaction)
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 2. การปฏิสมั พันธ์ดว้ ยรายการเลือกแบบข้อความ (text menu
Design interaction)
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 3. การปฏิสมั พันธ์ดว้ ยรายการเลือก (menu interaction)
Design
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 4. การปฏิสมั พันธ์ดว้ ยแบบฟอร์ม (form interaction)
Design
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 5. การปฏิสมั พันธ์เชิงวัตถุ (object-based interaction)
Design
• User Interface
Design
• Component-
level Design
 กำรออกแบบส่วนต่อประสำน
• Data/Class รูปแบบของการต่อประสานกับผูใ้ ช้ แบ่งเป็ น 6 ประเภท ได้แก่
Design
• Architectural 6. การปฏิสมั พันธ์ดว้ ยภาษาธรรมชาติ (natural language
Design interaction)
• User Interface
คือการปฏิสมั พันธ์ดว้ ยเสียงพูดของผูใ้ ช้ รวมทัง้ การนาข้อมูลเข้าและ
Design
• Component-
ออกจากระบบ ซึง่ ภาษาทีใ่ ช้ คือ ภาษาอังกฤษ
level Design ข้อเสีย คือ ยากและค่าใช้จา่ ยสูง
 กำรออกแบบส่วนต่อประสำน
• Data/Class การสร้างส่วนต่อประสาน ควรคานึงถึงการออกแบบเครือ่ งมือนาทาง ข้อมูล
Design
นาเข้า และข้อมูลส่งออก
• Architectural
Design ออกแบบเครื่องมือนำทำง (navigation design)
• User Interface
Design
• Address bar
• Component- • Navigation bar
level Design
• Hyperlink
• Outline view
 กำรออกแบบส่วนต่อประสำน
• Data/Class การสร้างส่วนต่อประสาน ควรคานึงถึงการออกแบบเครือ่ งมือนาทาง ข้อมูล
Design
นาเข้า และข้อมูลส่งออก
• Architectural
Design กำรออกแบบข้อมูลนำเข้ำ (input design)
• User Interface
• ข้อมูลนาเข้าแบ่งเป็ น 2 ประเภท คือ batch input และ
Design
• Component- online input
level Design • การตรวจสอบความถูกต้องของข้อมูลนาเข้า เช่น
o sequence check
o data type check
o format check
o range check
o mission data check
o reasonableness check
o validity check
o batch control
 กำรออกแบบส่วนต่อประสำน
• Data/Class การสร้างส่วนต่อประสาน ควรคานึงถึงการออกแบบเครือ่ งมือนาทาง ข้อมูล
Design
นาเข้า และข้อมูลส่งออก
• Architectural
Design กำรออกแบบข้อมูลส่งออก (output design)
• User Interface • คือการแสดงผลลัพธ์ออกทางจอภาพ วีดทิ ศั น์ รายงาน เสียง
Design
• Component-
ภาพเคลื่อนไหว กราฟ ตาราง รูป และอื่นๆ เพือ่ ตอบสนองความต้องการ
level Design ของผูใ้ ช้งาน
 กำรออกแบบระดับส่วนประกอบ
• Data/Class • การออกแบบโปรแกรมย่อย ฟงั ก์ชนั ย่อย หรือโมดูลย่อยต่าง ๆ ของ
Design
ซอฟต์แวร์ทป่ี ระกอบกันเป็ นระบบหรือซอฟต์แวร์
• Architectural
Design
• User Interface
Design
• Component-
level Design
Software Reuse
 ประเภทของกำร Reuse
การนากลับมาใช้ใหม่ สามารถแยกประเภทตามขนาดของงานได้ 3 ประเภท
• Application System Reuse
o เป็ นการนาระบบเก่าทีพ่ ฒ ั นาไปแล้วนากลับมาใช้งานใหม่ทงั ้ ระบบ โดยอาจไม่มกี ารเปลีย่ นแปลง
แต่เปลีย่ นกลุม่ ผูใ้ ช้เดิมเป็ นกลุม่ ผูใ้ ช้ใหม่ ซึง่ เป็ นกลุม่ ผูใ้ ช้ทต่ี อ้ งการระบบทีม่ คี วามคล้ายคลึงกับ
ระบบเก่า
• Component Reuse
o เป็ นวิธที น่ี าเอา component จากระบบเก่ามาใช้กบั ระบบใหม่ทอ่ี าจมีการทางานคล้ายกัน
ในบางส่วน โดยนามาพัฒนาร่วมกับระบบใหม่ สาหรับการพัฒนระบบทีเ่ น้น component-
based software engineering
• Object and Function Reuse
o เป็ นการนา object and function ในส่วนประกอบของระบบย่อย จากระบบเก่ามาใช้
ในการพัฒนาระบบใหม่ หรืออาจทาการเชือ่ มโยงกับระบบอืน่ ทีม่ กี ารใช้ object and
function เหมือนกับทีร่ ะบบใหม่ตอ้ งการ
 กำรวำงแผนกำรนำกลับมำใช้ใหม่
วิธกี ารนากลับมาใช้ใหม่นนั ้ ต้องมีการวางแผนและพิจารณาองค์ประกอบของระบบ ความเสีย่ ง เวลา
และงบประมาณอย่างรอบคอบ โดยสามารถใช้ software reuse ได้ตอ้ งคานึงหลักเกณฑ์
ดังนี้
• ระยะเวลาการพัฒนาซอฟต์แวร์มนี ้อย
• ซอฟต์แวร์มอี ายุการใช้งานยาว ซึง่ อาจมีการเปลีย่ นแปลงระบบส่วนต่าง ๆ ในอนาคต
• ผูพ้ ฒ ั นามีความสามารถและประสบการณ์สงู
• ขอบเขตการทางานของซอฟต์แวร์ทส่ี ามารถปรับแต่งได้ในแต่ละสถานการณ์
• ระบบใหม่ถูกออกแบบให้ใช้บนระบบปฏิบตั กิ ารเดิม

อย่างไรก็ตาม ความต้องการของลูกค้าเป็นสิง่ ทีค่ วบคุมได้ยาก บางกลุ่มมีนโยบายเคร่งครัดหรือ

ต้องการระบบทีม่ คี ุณภาพสูง ทาให้ software reuse อาจไม่ใช่ทางเลือกทีด่ ี ดังนัน้ ให้
คานึงถึง user requirements เป็นสาคัญ
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern
• Generator-
เป็ นวิธสี าหรับแก้ปญั หาแต่ละด้าน สามารถนาไปใช้งาน
based Reuse ได้หลายกรณีตามทีอ่ อกแบบไว้ กล่าวคือ เมือ่ มีปญั หา
• Application
Frameworks หนึ่งทีเ่ คยเกิดขึน้ และมีการแก้ไขเรียบร้อยแล้ว มีวธิ กี าร
มีผลลัพธ์ แสดงให้เห็ฯไว้อย่างชัดเจน จึงรวบรวมมาเส
ร้างเป็ นแบบแผน หากเกิดปญั หาเดิมขึน้ อีกส็ ามารถนา
แบบแผนทีส่ ร้างไว้มาใช้ได้ทนั ที สาหรับมุมมองด้าน
ออกแบบ object-oriented การใช้แบบแผน
ทาให้ผพู้ ฒ ั นาเข้าใจกันได้ตรงกันว่าต้องทาสิง่ ใดและมี
ส่วนประกอบอะไรบ้าง
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern ส่วนประกอบของแบบแผน
• Generator-
based Reuse • Pattern name
• Application
Frameworks • Description
• Problem description
• Solution description
• Consequence
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern หลักการออกแบบแบบแผน
• Generator-
based Reuse • ต้องตัง้ ชื่อทีม่ คี วามหมายทีส่ อ่ื ถึงหน้าทีข่ องแบบแผนนัน้
• Application
Frameworks • แบบแผนต้องผ่านการใช้แก้ปญั หานัน้ มาแล้ว ก่อนนามาสร้าง
• คาอธิบายวิธกี ารแก้ไขควรสอดคล้องกับหน้าทีข่ องแบบแผนนัน้
• คาอธิบายวิธกี ารแก้ไข จะต้องไม่กล่าวถึงวิธนี าไปใช้งาน แต่ตอ้ ง
กล่าวถึงการออกแบบวิธกี ารแก้ไข เพือ่ นาไปออกแบบและแก้ไข
ด้วยตนเอง ทาให้ได้วธิ กี ารแก้ไขหลายแบบ
• ผลลัพธ์ตอ้ งแสดงให้เห็นว่าแบบแผนนัน้ ใช้ได้ผลดีกบั
สถานการณ์ใด
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern
• Generator-
based Reuse
• Application
Frameworks
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern The Observer pattern
• Generator-
based Reuse • Pattern name
• Application o Observer
Frameworks • Description
o Separates the display of object state from the object itself

• Problem description
o Used when multiple displays of state are needed

• Solution description
o See UML description

• Consequence
o Optimizations to enhance display performance are
impractical
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern
• Generator-
based Reuse
• Application
Frameworks
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern เป็ นวิธที ต่ี อ้ งอาศัยเครือ่ งมือช่วยสร้างโปรแกรม (program
• Generator-
based Reuse
generator) ซึง่ เกีย่ วข้องกับการนาแบบแผนมาตรฐาน
• Application (standard pattern) และ algorithm กลับมาใช้ใหม่
Frameworks โดยฝงั ตัวอยูใ่ นเครือ่ งมือ่น้ี เมือ่ ผูพ้ ฒ
ั นาป้อนข้อมูล หรือตัวแปทีเ่ กีย่ วข้อง
หรือโมเดลใหม่ เครือ่ งมือจะสร้าง program code ต่าง ๆ ให้
อัตโนมัติ ซึง่ เป็ นการอานวยความสะดวกให้กบั programmers ได้
เป็ นอย่างดี

ตัวอย่าง program generator เช่น

• Parser Generator : compiler, interpreter
• Code generator
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern Framework เป็ นกรอบการทางาน ทาหน้าทีป่ ระสานการทางาน
• Generator- ระหว่างตัวโปรแกรมกับระบบ โดยสามารถติดต่อได้ 2 ทาง คือ โปรแกรม
based Reuse
• Application
เรียกใช้ framework หรือ framework จะเรียกใช้โปรแกรมก็ได้
Frameworks

ส่วน Application Framework เป็ นการกาหนดกรอบการ

ทางานในการพัฒนา application ให้มมี าตรฐานเดียวกันตาม
application framework ทีส่ ร้างไว้ เพือ่ ให้
programmers ในทีมสามารถทางานไปในทิศทางเดียวกัน การแก้ไข
user requirements ก็สามารถทาได้งา่ ย โดยแก้ท่ี
application framework เพียงทีเ่ ดียว
 เทคนิคในกำรนำกลับมำใช้ใหม่
• Design Pattern Framework แบ่งออกเป็ น 3 ระดับ คือ
• Generator- • System Infrastructure Framework สนับสนุนการพัฒนาโครงสร้าง
based Reuse พืน้ ฐานของระบบ GUI และ Complier
• Application
Frameworks o MVC (Model View Controller), Struts
Framework
• Middleware Integration Framework ประกอบด้วยกลุม่ ของ
objects and classes สนับสนุนการทางานของ components ใน
การติดต่อสือ่ สารและแลกเปลีย่ นข้อมูล
o Web Service, .NET, Enterprise Java Bean
• Enterprise Application Framework เป็ นกรอบการพัฒนาระบบ
ขนาดใหญ่และซับซ้อน
o SAP Enterprise Portal - Development
Framework
ข้อดีและข้อเสียของ Software Reuse
ข้อดี
• เพิม่ ความน่าเชือ่ ถือ เนื่องจากระบบเก่า
ผ่านการทดสอบและใช้งานแล้ว
• ลดความเสีย่ งของข้อผิดพลาดในการ
พัฒนา
• เพิม่ ทักษะให้กบั ผูพ้ ฒ
ั นา
• ผูใ้ ช้งานเดิมเกิดความคุน้ เคยและยอมรับ
การใช้งานซอฟต์แวร์ได้งา่ ยกว่า
• ลดเวลาในการพัฒนาซอฟต์แวร์ ทาให้
สามารถส่งมอบงานได้รวดเร็วขึน้
ข้อเสีย
• เพิม่ ค่าใช้จา่ ยในการบารุงรักษา หาก
software reuse นัน้ ไม่สามารถ
ใช้ประโยชน์ได้
• ผูพ้ ฒั นาต้องมีความเข้าใจและสามารถใช้
งาน components ในระบบเก่า
ได้เป็ นอย่างดี
• ขาดเครือ่ งมือในการสนับสนุน
• ไม่มคี วามท้าทายในการพัฒนา