Transcript Object-Oriented Software Development

Chapter 10 : Software Design
Juthawut Chantharamalee
Curriculum of Computer Science
Faculty of Science and Technology, Suan Dusit University
Email: [email protected]
URL: http://dusithost.dusit.ac.th/~juthawut_cha/home.htm
Outline
1
ความหมายของการออกแบบซอฟต์ แวร์
2
กระบวนการออกแบบซอฟต์ แวร์
3
สถาปัตยกรรมและโครงสร้ างสถาปัตยกรรม
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์ แวร์
4
5
แนวคิดในการออกแบบซอฟต์ แวร์
6
กลยุทธ์ และระเบียบวิธีของการออกแบบซอฟต์ แวร์
7
แบบจาลองทีใ่ ช้ ในการออกแบบ
2
ความหมายของการออกแบบซอฟต์แวร์
การออกแบบระบบ (System Design)
- เป็ นการนาความต้องการของผูใ้ ช้มาแปลงให้อยู่ในรู ปของแบบ
(เปรี ยบได้กบั พิมพ์เขียว) ก่อนนาไปสร้างเป็ นผลิตภัณฑ์
- สิ่ งที่ได้จากการออกแบบ คือ ข้อกาหนดเฉพาะของการออกแบบ
(Specification Document)
- สิ่ งจาเป็ นที่สุดที่จะนามาใช้ในการออกแบบ คือ ข้อกาหนดความ
ต้องการของผูใ้ ช้และแบบจาลองที่ได้จากการวิเคราะห์ เพื่อ นามาสร้าง
เป็ นแบบจาลองของการออกแบบที่มีรายละเอียดทางเทคนิ คมากพอที่ จะ
เป็ นประโยชน์ในการเขียนโปรแกรม
3
ภาพจาลองความสาคัญของข้อกาหนดความต้องการ
What
How
Function & Analysis
Models
Design
Models
นักออกแบบระบบ
ลูกค้ า/ผู้ใช้
แสดงการนา Analysis Model มาใช้ ในการออกแบบ
โปรแกรมเมอร์
4
ความหมายของการออกแบบซอฟต์แวร์
• ด้ านวิศวกรรมซอฟต์ แวร์
– มุ่งเน้นการผลิตซอฟต์แวร์เป็ นหลัก
– งานออกแบบซอฟต์แวร์เป็ นหัวใจของกระบวนการผลิต
5
ความหมายของการออกแบบซอฟต์แวร์
• การออกแบบซอฟต์แวร์ (Software Design) คือกระบวนการ
กาหนดสถาปัตยกรรม ส่ วนประกอบ ส่ วนประสาน และ
ลักษณะด้านอื่นๆ ของระบบหรื อส่ วนประกอบของระบบ
• โดยการออกแบบซอฟต์แวร์ยงั มีความหมายรวมถึงสิ่ งที่ได้จาก
การออกแบบ ซึ่ งก็คือ แบบจาลองของการออกแบบ (Design
Model) (IEEE610-12, 1990)
6
ความหมายของการออกแบบซอฟต์แวร์
• ในทางวิศวกรรมซอฟต์แวร์ แล้วการนาความรู้ดา้ นวิศวกรรม
ซอฟต์แวร์ มาประยุกต์ใช้กบั การออกแบบ ก็คือ วิศวกรรมการ
ออกแบบ ซึ่ งมีเป้ าหมายคือ การสร้างแบบร่ างของระบบ หรื อ
การน าเสนอระบบในแต่ ล ะด้า น ให้มี คุ ณ สมบัติ ที่ ดี ได้แ ก่
Firmness
(โปรแกรมที่ ได้รับการออกแบบจะต้องไม่ มี
ข้อผิดพลาด) Commodity (จะต้องตรงกับวัตถุประสงค์การใช้
งาน) และ Delight (ต้องทาให้ผูใ้ ช้รู้สึกพอใจ) ทั้งหมดคือ
คุณภาพ
•
7
7
ปัจจัยที่ส่งผลให้การออกแบบมีคุณภาพ
•
•
•
•
•
•
ประสบการณ์ของบุคลากร
หลักการ
แนวทาง
เครื่ องมือ
ระเบียบวิธีที่จะนามาใช้
การกาหนดเงื่อนไขเพื่อวัดคุณภาพของงาน
8
กระบวนการออกแบบซอฟต์แวร์
• กระบวนการออกแบบซอฟต์แวร์ (Software Design Process) จะมี
ลักษณะการทางานแบบซ้ าๆ เนื่ องจากต้องนาความต้องการของ
ระบบที่ผ่านมาวิเคราะห์แล้วในแต่ละด้าน ทั้งด้านข้อมูล ฟั งก์ชัน
และส่ วนประกอบ มาแปลงเป็ นข้อกาหนดของการออกแบบ
• ดังนั้น ข้อกาหนดการออกแบบจึ งสอดคล้องกับข้อกาหนดความ
ต้องการและสามารถใช้สื่อสารกับโปรแกรมเมอร์ ได้ กระบวนการ
ออกแบบนั้นจะประกอบไปด้วยการออกแบบใน 2 ระดับ ได้แก่
การออกแบบเชิ งสถาปั ตยกรรม และการออกแบบในรายละเอียด
9
กระบวนการออกแบบซอฟต์แวร์
• การออกแบบเชิงสถาปัตยกรรม (Architectural Design) เรี ยกอีก
อย่างหนึ่งว่า Top-Level Design เป็ นการกาหนดลักษณะโครงสร้าง
ของระบบหรื อซอฟต์แวร์ในมุมมองระดับบน กล่าวคือ เป็ นการ
แสดงให้เห็นส่ วนประกอบต่างๆ ของซอฟต์แวร์ภายใต้โครงสร้าง
สถาปัตยกรรมรู ปแบบใดๆ
• การออกแบบในรายละเอียด (Detail Design) เรี ยกอีกอย่างหนึ่งว่า
Implementation Design เป็ นการอธิบายรายละเอียดของแต่ละ
ส่ วนประกอบของซอฟต์แวร์ เพื่อเอื้ออานวยต่อการเขียนโปรแกรม
ให้มากที่สุด
10
สถาปัตยกรรมและโครงสร้างสถาปัตยกรรมซอฟต์แวร์
• สิ่ งส าคั ญ ที่ ค วรทราบส าหรั บ การออกแบบซอฟต์ แ วร์ คื อ
สถาปั ต ยกรรม และโครงสร้ า งสถาปั ต ยกรรมซอฟต์ แ วร์
(Software Architecture and Architecture Structure)
• สถาปั ตยกรรมซอฟต์แวร์ (Software Architecture) หมายถึง การ
แสดงความสาพันธ์ระหว่างระบบย่อยและส่ วนประกอบ (คอม
โพเน้นท์) เพื่อกาหนดโครงสร้างหรื อระบบภายในซอฟต์แวร์
11
โครงสร้างสถาปัตยกรรมและมุมมอง
• โครงสร้างสถาปัตยกรรมนั้น เกิดขึ้นจากมุมมองและแนวคิดในการออกแบบ
ที่มีความหลากหลายในปั จจุบนั เนื่ องจากการออกแบบซอฟต์แวร์ ก็คือการ
กาหนดรายละเอียดในแต่ละมุมมองของซอฟต์แวร์ แล้วนามาประกอบกัน
เป็ นซอฟต์แวร์ ลักษณะของโครงสร้างเมื่อรวมส่ วนประกอบย่อยต่างๆ ของ
ซอฟต์แวร์ เข้าด้วยกันแล้ว ก็คือ สถาปั ตยกรรมซอฟต์แวร์ ชนิดต่างๆ ที่มีการ
ทางานแตกต่างกันออกไป แต่ละชนิดมีวตั ถุประสงค์เพื่อให้ซอฟต์แวร์ ที่งาน
ในลัก ษณะเฉพาะที่ แ ตกต่ า งกัน บางชนิ ด มี ล ัก ษณะโครงสร้ า งของการ
ประกอบรวมซอฟต์ แ วร์ เ หมื อ นกั น แต่ ท างานได้ ต่ า งกั น โครงสร้ า ง
สถาปั ต ยกรรมซอฟต์แ วร์ จึ ง ถู ก ก าหนดขึ้ น เพื่ อ ควบคุ ม สถาปั ต ยกรรม
ซอฟต์แวร์ที่หลากหลายดังกล่าวนัน่ เอง
•
12
โครงสร้างสถาปัตยกรรมและมุมมอง
รู ปแบบสถาปั ตยกรรม หมายถึง ข้อบังคับหรื อกฎเกณฑ์ทางด้านสถาปั ตยกรรม ที่จดั ตั้ง
ขึ้ น มา เพื่ อ จ าแนกกลุ่ ม หรื อ หมวดหมู่ ข องสถาปั ต ยกรรมซอฟต์แ วร์ ปั จ จุ บัน มี ก าร
กาหนดรู ปแบบสถาปั ตยกรรมขึ้นมาหลากหลาย สามารถแบ่งออกเป็ น 5 กลุ่ม ดังนี้
1. กลุ่มสถาปั ตยกรรมแบบโครงสร้างทัว่ ไป (General Structure) เช่น สถาปั ตยกรรม
แบบ Layer, Pipe and Filter และ Blackboard เป็ นต้น
2. กลุ่มสถาปั ตยกรรมแบบกระจาย (Distributed System) เช่น สถาปั ตยกรรมแบบ
Client/Server, Three Tiers และ Broker เป็ นต้น
3. กลุ่มสถาปั ตยกรรมระบบแบบโต้ตอบ (Interactive System) เช่น สถาปั ตยกรรมแบบ
Model-View-Controller และ Presentation-Abstraction-Control เป็ นต้น
13
โครงสร้างสถาปัตยกรรมและมุมมอง
4. กลุ่มสถาปั ตยกรรมระบบที่สามารถดัดแปลงได้ (Adaptable System) เช่น
สถาปัตยกรรมแบบ Micro-Kernel และ Reflection เป็ นต้น
5. กลุ่ ม สถาปั ต ยกรรมระบบแบบอื่ น ๆ เช่ น สถาปั ต ยกรรมแบบ Batch,
Interpreter, Process Control และ Rule based เป็ นต้น
14
แบบแผนการออกแบบ
• แบบแผน (Patten) หมายถึง วิธีแก้ปัญหาที่มีรูปแบบเป็ นกลาง
เพื่ อ ใช้กับ ปั ญ หาทั่ว ไปตามลัก ษณะของปั ญ หาที่ ร ะบุ ใ นวิ ธี
แก้ปัญหาแบบแผนการออกแบบในระดับจุลภาค ถูกกาหนดขึ้น
เนื่ องจากรู ปแบบสถาปั ตยกรรมแสดงถึงโครงสร้างในระดับ บน
ของสถาปั ต ยกรรมเท่ านั้น ไม่ ส ามารถแสดงให้เ ห็ น ถึ ง ระดับ
รายละเอียดปลี กย่อยอื่นๆ ที่ประกอบอยู่ภายในสถาปั ตยกรรม
รู ปแบบนั้นได้
15
แบบแผนการออกแบบ
โดย Design Pattern ในระดับจุลภาคถูกแบ่งออกเป็ น 3 กลุ่ม ดังนี้
1. แบบแผนในกลุ่มการสร้ าง (Creational Pattern) เช่ น Builder,
Factory, Prototype และ Singleton เป็ นต้น
2. แบบแผนในกลุ่มโครงสร้ าง (Structural Pattern) เช่น Adapter,
Bridge, Composite, Decorator, Facade, Flyweight และ Proxy เป็ นต้น
3. แบบแผนในกลุ่มพฤติกรรม (Behavioral Pattern) เช่น Command,
Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy,
Template, และ Visitor เป็ นต้น
16
กลุ่มของซอฟต์แวร์และ Framework
• วิธีการอย่างหนึ่ งที่ ช่วยสนับสนุ นการออกแบบซอฟต์แวร์ และ
คอมโพเน้นของซอฟต์แวร์ ให้สามารถนากลับมาใช้ใหม่ได้ก็คือ
การกาหนดเป็ นกลุ่มของซอฟต์แวร์ (Families of Software) ขึ้น
ซึ่งรู้จกั กันในชื่อ Software Product Line
17
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
เกณฑ์คุณภาพ (Quality Attribute)
1. การทางานของโปรแกรม (Functionality) จะประเมินจากลักษณะ (Feature Set) และ
ความสามารถ (Capability) ของโปรแกรม นอกจากนี้ ยังประเมินจากหน้าที่ทวั่ ไปของ
โปรแกรม และความปลอดภัยเมื่อต้องทางานรวมเป็ นระบบ
2. ความสามารถในการใช้งาน (Usability) พิจารณาจากผลตอบกลับจากการใช้งานของ
ผูใ้ ช้ ไม่วา่ จะเป็ นการใช้งานง่าย และเรี ยนรู ้ง่าย
3. ความน่ าเชื่ อถือ (Reliability) วัดจากความถี่และความรุ นแรงของความผิดพลาดที่
เกิ ดขึ้ น ความถูกต้องของผลลัพธ์ที่ได้ เวลาเฉลี่ ยของความล้มเหลว (Mean-Time-ToFailure:MTTF) ความสามารถในการกูค้ ืนระบบ และความสามารถในการคาดการณ์ได้
ของโปรแกรม
18
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
เกณฑ์คุณภาพ (Quality Attribute)
4. ประสิ ทธิ ภาพ (Performance) วัดจากความเร็ วของการประมวลผล
ระยะเวลาตอบสนอง ทรัพยากรที่ใช้ ปริ มาณที่ทาได้ในช่วงเวลาหนึ่ ง และ
ประสิ ทธิผลในการทางาน
5. ความสามารถในการสนับสนุ น การใช้ง าน (Supportability)
และ
ความสามารถในการบ ารุ ง รั ก ษา (Maintainability)
พิ จ ารณาจาก
ความสามารถในการเพิ่มเติมส่ วนกรทางาน ความสามารถในการแปลงการ
ทางาน และการบริ การ ยังพิจารณาจากความสามารถในการทดสอบ การ
ทางานข้ามระบบได้ และการจัดสภาพแวดล้อมของระบบด้วย
19
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
การวิเคราะห์และประเมินคุณภาพ (Quality Analysis and Evaluation)
การวิเคราะห์และการประเมินคุณภาพเป็ นกิจกรรมที่ช่วยให้มนั่ ใจว่าซอฟต์แวร์ ที่
ถูกออกแบบไว้จะต้อ งมี คุณภาพโดยที มงานสามารถใช้เครื่ องมื อและเทคนิ ค
ต่างๆ ในการวิเคราะห์และประเมิน ซึ่งแบ่งตามกิจกรรมได้ดงั นี้
1. ทบทวนงานออกแบบซอฟต์แวร์ (Software Design Review) เทคนิคที่ช่วยให้
การทบทวนงานออกแบบมีประสิ ทธิ ภาพ ได้แก่ Group-Based Technique เป็ น
เทคนิ ค ในการตรวจสอบและปรั บ ปรุ ง คุ ณ ภาพของงานออกแบบ เช่ น การ
ทบทวนสถาปั ต ยกรรมซอฟต์แ วร์ และการตรวจสอบอย่า งละเอี ย ด เป็ นต้น
20
20
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
การวิเคราะห์ และประเมินคุณภาพ (Quality Analysis and Evaluation)
2. วิเคราะห์งานออกแบบ (Static Analysis) ผลที่ได้จากการวิเคราะห์จะนาไป
ประเมิ น คุ ณ ภาพของงานออกแบบ เทคนิ ค ที่ ช่ ว ยใช้ ก ารวิ เ คราะห์ มี
ประสิ ทธิภาพ เช่น Fault-tree Analysis, Auto-cross Checking เป็ นต้น
3. การจาลองสถานการณ์และการสร้างต้นแบบ (Simulation and Prototyping)
เช่น การจาลองเหตุการณ์ประสิ ทธิภาพของซอฟต์แวร์ และการสร้างต้นแบบ
ซ อ ฟ ต์ แ ว ร์ เ พื่ อ ท ด ส อ บ ค ว า ม เ ป็ น ไ ป ไ ด้ เ ป็ น ต้ น
21
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
การวัด (Measure)
การวัดสามารถใช้กบั การประเมินหรื อการประมาณการคุณลักษณะบางอย่าง
เช่น ขนาด โครงสร้าง หรื อคุณภาพ ของซอฟต์แวร์ ได้ แต่การวัดคุณภาพของ
การออกแบบซอฟต์แวร์จะแบ่งออกเป็ น 2 ประเภท ดังนี้
1. การวัดการออกแบบเชิงฟังก์ชนั (Function-Oriented Measure)
ใช้กบั ซอฟต์แวร์ ที่ออกแบบด้วย แนวคิดเชิ งโครงสร้ าง ที่มีการแบ่งระบบ
ใหญ่ออกเป็ นระบบย่อยตามหน้าที่ เรี ยกว่า โมดูล และนาเสนอด้วยแผนภาพ
เชิงโครงสร้าง การวัดคุณภาพประเภทนี้ จึงสามารถวัดได้จากคุณลักษณะของ
โมดูล เช่น Coupling Cohesion
22
คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
การวัด (Measure)
2. การวัดการออกแบบเชิงวัตถุ (Object-Oriented Design Measure)
ใช้กบั ซอฟต์แวร์ ที่ถูกออกแบบด้วยแนวทางเชิงวัตถุ ที่มีการจัดให้ทุก
สิ่ งของระบบเป็ นวัตถุ และนาเสนอโครงสร้ างของซอฟต์แวร์ ด้วย
Class Diagram การวัดคุณภาพประเภทนี้ จึงสามารถวัดได้จาก
ลักษณะภายในคลาส เช่น การวัดความสัมพันธ์ระหว่าคลาส การนับ
จานวนการโต้ตอบกันระหว่างเมธอดของคลาส
23
หลักการออกแบบซอฟต์แวร์
เนื่ องจากการออกแบบซอฟต์แวร์ ตอ้ งคานึ งถึงคุณภาพของซอฟต์แวร์ ที่จะผลิต
ด้วย ดังนั้น ทีมงานจึงควรใช้แนวทางการออกแบบบางประการ เพื่อนาไปสู่ การ
ออกแบบที่ดี ดังนี้
1. การออกแบบควรแสดงให้เห็นถึงรู ปแบบสถาปั ตยกรรมที่เลือกใช้อย่างชัดเจน
และมีแบบแผน
2. การออกแบบควรมิลกั ษณะเป็ นโมดูล
3. การออกแบบควรนาเสนอด้านข้อมูล สถาปั ตยกรรม ส่ วนประสาน และคอม
โพเน้นท์ที่ชดั เจน
4. ควรออกแบบคอมโพเน้นท์ให้มีอิสระต่อกัน
5. ควรออกแบบให้ ส่ ว นประสานระหว่ า งคอมโพเน้น ท์กับ สภาพแวดล้อ ม
ภายนอกมีความซับซ้อนน้อยที่สุด
24
หลักการออกแบบซอฟต์แวร์
6. การออกแบบควรนาข้อมูลมาจากการวิเคราะห์ระบบ และใช้ระเบียบวิธี
ปฏิบตั ิเดียวกัน
7. สัญลักษณ์ที่ใช้ในการออกแบบควรสื่ อความหมายได้ชดั เจน และเป็ น
มาตรฐาน
8. งานออกแบบควรมีโครงสร้างที่ดี เพื่อการแก้ไขที่ง่ายและใช้ตน้ ทุนน้อย
9. การออกแบบในระดั บ คอมโพเน้ น ท์ มี ล ั ก ษณะแบบ Functional
Independence คือ ฟั งก์ชันงานมีความเป็ นอิ สระต่อกัน ไม่ข้ ึนต่อกัน
10 คอมโพเน้นท์ของซอฟต์แวร์ จะต้องมีลกั ษณะการขึ้นต่อกันน้อยที่สุด
(Loosely Coupled)
25
แนวคิดในการออกแบบซอฟต์แวร์
การคิดแบบนามธรรม (Abstraction)
เป็ นพื้นฐานทางความคิดในการออกแบบอย่างหนึ่ ง ที่ช่วยลด
ความซับซ้อนของระบบลงได้ เมื่อมีการพิจารณาถึงแนวทางแก้ไข
ของแต่ละปั ญหา จะเกิ ดการคิดแบบเป็ นนามธรรมขึ้นเป็ นระดับ
ได้แก่ Procedural Abstraction เป็ นการสร้างลาดับขั้นตอนของ
ชุ ด ค าสั่ ง ของฟั ง ก์ ชัน ใดฟั ง ก์ ชัน หนึ่ งขึ้ น มา โดยจะไม่ ร ะบุ ถึ ง
รายละเอียดภายในฟังก์ชนั่ และ Data Abstraction คือชื่ออ็อบเจ็กต์
ข้อมูลที่อยูใ่ น Procedural Abstraction
26
แนวคิดในการออกแบบซอฟต์แวร์
สถาปัตยกรรม (Architecture)
เป้ าหมายของการออกแบบสถาปั ตยกรรม ก็เพื่อเป็ นกรอบ
ให้กบั การออกแบบส่ วนประกอบที่เหลือของระบบ ให้เป็ นไปใน
ทิ ศ ทางเดี ย วกัน และอยู่บ นสถาปั ต ยกรรมเดี ย วกัน นั่น เอง การ
ออกแบบโครงสร้างหรื อสถาปั ตยกรรมสามารถนาเสนอออกมาใน
รู ปแบบจาลอง 4 ชนิ ด ได้แก่ Structural Model, Framework
Model, Dynamic Model, Process Model, และ Functional Model
27
แนวคิดในการออกแบบซอฟต์แวร์
แบบแผน (Pattern)
คือหลักและวิธีแก้ไขปั ญหาชนิ ดใดชนิ ดหนึ่ งที่สามารถ
นาไปใช้กับ ปั ญ หาชนิ ดเดี ย วกันที่ เกิ ด ซ้ าได้ โดยจะต้องอธิ บาย
โครงสร้ างการออกแบบซอฟต์แวร์ ไว้อย่างละเอียด ไม่ว่าจะเป็ น
ชื่อแบบแผน วิธีแก้ปัญหา และผลที่ตามมา การใช้ Pattern จะช่วย
ให้งานผลิตซอฟต์แวร์จะดาเนินไปได้รวดเร็ ว
28
แนวคิดในการออกแบบซอฟต์แวร์
การแบ่ งระบบ (Modularity)
เป็ นการแบ่งระบบหรื อซอฟต์แวร์ ออกเป็ นส่ วนย่อยๆ แต่ละ
ส่ วน ในระบบงานใดๆ ย่อมประกอบไปด้วยการทางานหลายส่ วน
หากแบ่งออกแต่ละส่ วนจะสามารถทางานได้ง่ายขึ้น ลดความซัก
ซ้อน
29
แนวคิดในการออกแบบซอฟต์แวร์
การซ่ อนรายละเอียด (Information Hiding)
เนื่องจากการแบ่งระบบออกเป็ นโมดูลย่อย นักออกแบบระบบ
ได้เล็งเห็ นปั ญหาที่อาจเกิ ดขึ้นเมื่อมีการนามาประสานเพื่อทาให้
ทางานร่ วมกัน จึ งเกิ ดความยุ่งยากในการใช้งานร่ วมกัน จึงซ่ อน
รายละเอียดไว้เพื่อป้ องกันการเข้าถึง ซึ่ งอาจส่ งผลให้ผิดพลาดได้
30
แนวคิดในการออกแบบซอฟต์แวร์
ความเป็ นอิสระต่ อกันในการทางาน (Functional Independence)
Coupling เป็ นการวัดความสัมพันธ์ระหว่างโมดูล 2 โมดูลว่ามี
ความซั บ ซ้ อ นหรื อมี ร ะดับ การขึ้ นต่ อ กัน ของโมดู ล มากน้ อ ย
เพียงใด
Cohesion เป็ นการวัดระดับการยึดเกาะกันของหน้าที่หรื อ
กิ จ กรรมในโมดู ล เพื่ อ ประมวลข้อ มู ล เป็ นผลลัพ ธ์ ที่ ต้อ งการ
ลักษณะโครงสร้ างที่ดีจะต้องมีระดับการยึดเกะกันของหน้าที่ใน
โมดูลสูง
31
แนวคิดในการออกแบบซอฟต์แวร์
การกลัน่ กรอง (Refinement)
การกลัน่ กรองเป็ นการบรรยายรายละเอียดของแต่ละฟังก์ชนั เป็ น
ลาดับขั้น เริ่ มต้นจากชื่อฟังก์ชนั ที่จะถูกกาหนดขึ้นในระดับบนสุ ด
ของการคิ ด แบบนามธรรม ซึ่ งเป็ นเพี ย งการก าหนดชื่ อ ฟั ง ก์ชัน
เท่านั้น ยังไม่มีรายละเอียดการทางานภายในข้อมูล การกลัน่ กรอง
เป็ นการนาชื่ อฟั งก์ชนั เหล่านั้น มาเพิ่มเติมรายละเอียดการทางาน
ภายในให้ ชั ด เจนยิ่ ง ขึ้ นในแต่ ล ะระดั บ ของการกลั่ น กรอง
32
แนวคิดในการออกแบบซอฟต์แวร์
การปรับโครงสร้ างการออกแบบ (Refactoring)
เป็ นเทคนิ คในการปรับโครงสร้างการออกแบบภายในของคอม
โพเน้นท์ โดยไม่ตอ้ งเปลี่ ยนฟั งก์ชันหรื อพฤติ กรรมของคอมโพ
เน้นท์ โดยเมื่อซอฟต์แวร์ ถูกปรับโครงสร้าง จะเริ่ มต้นจากการนา
งานออกแบบเดิ ม มาพิ จ ารณาถึ ง ความซ้ า ซ้อ น ส่ ว นประกอบที่
ไม่ ไ ด้ถู ก ใช้ง าน อัล กอริ ธึ ม ที่ ไ ม่ มี ป ระสิ ท ธิ ภ าพหรื อ ไม่ จ าเป็ น
ตลอดจนโครงสร้างข้อมูลที่ไม่เหมาะสม หรื อข้อผิดพลาดจากการ
ออแบบอื่นๆ แล้วนามาแก้ไขให้มีประสิ ทธิภาพและถูกต้องมากขึ้น
33
แนวคิดในการออกแบบซอฟต์แวร์
Design Class
สาหรับการวิเคราะห์ระบบด้วยแนวทางเชิ งวัตถุ เมื่อจบ
ขั้นตอนการวิเคราะห์ระบบแล้ว สิ่ งที่ ได้คือ แบบจาลองคลาส ที่
แสดงเพียงมุมมองของระบบในระดับบนเท่านั้น เมื่อมาถึงขั้นตอน
การออกแบบ วิ ศ วกรซอฟต์ แ วร์ จ ะต้อ งน าแบบจ าลองคลาส
เหล่านั้น มากลัน่ กรองเพื่อกาหนดรายละเอี ยดเชิ งลึ ก ของแต่ ล ะ
คลาสอีกครั้ง เพื่อให้เขียนโค้ดได้ง่ายขึ้น และต้องสร้างแบบจาลอง
คลาสที่แสดงให้เห็นถึงโครงสร้างภายในที่สนับสนุนกระบวนการ
ทางธุรกิจด้วย
34
แนวคิดในการออกแบบซอฟต์แวร์
Design Class
สิ่ งที่ได้คือ Design Class ซึ่งประกอบไปด้วย Design Class 5
ชนิด แบ่งตาม Layer ของสถาปัตยกรรมระบบ ได้แก่
1. User Interface Class
2. Business Domain Class
3. Process Class
4. Persistent Class
5. System Class
35
กลยุทธ์และระเบียบวิธีของการออกแบบซอฟต์แวร์
กลยุทธ์ในการอกแบบซอฟต์แวร์
เป็ นเพียงหลักและ
แนวทางในการปฏิบตั ิงานแบบซอฟต์แวร์ เท่านั้น ไม่ได้ระบุถึง
วิธีทางานอย่างชัดเจน แต่สาหรับระเบียบวิธี ในการออกแบบ
ซอฟต์แวร์ จะระบุถึงรายละเอียดของวิธีการทางานอย่างชัดเจน
พร้อมกับเตรี ยมสัญลักษณ์ต่างๆ ของแบบจาลองเฉพาะระเบียบ
วิธีน้ นั ไว้ให้ใช้งานด้วย ทาให้ทีมวิศวกรซอฟต์แวร์ ทางานได้ง่าย
ขึ้น
ปัจจุบนั
กลยุทธ์และระเบียบวิธีในการออกแบบ
ซอฟต์แวร์มีหลายวิธี สรุ ปได้ดงั นี้
36
กลยุทธ์และระเบียบวิธีของการออกแบบซอฟต์แวร์
กลยุทธ์ ทวั่ ไปในการออกแบบซอฟต์ แวร์ (General Strategy)
กลยุทธ์ทวั่ ไปในการออกแบบซอฟต์แวร์ ได้แก่ Divide-and
Conquer, Stepwise Refinement, Top-down and Bottom-up
Strategy, Data Abstraction and Information Hiding, Heuristic และ
Design Pattern เป็ นต้น
37
กลยุทธ์และระเบียบวิธีของกาสรออกแบบซอฟต์แวร์
การออกแบบเชิงฟังก์ ชัน (Function-Oriented Design)
การออกแบบเชิงโครงสร้าง ซึ่งเป็ นระเบียบวิธีที่ได้รับความนิยมมา
ตั้งแต่อดี ตจนถึงปั จจุบนั เป็ นวิธีในการพิจารณาถึงฟั งก์ชนั ของซอฟต์แวร์
เป็ นเกณฑ์ในการแบ่งส่ วนซอฟต์แวร์ ออกเป็ นส่ วนย่อย จากนั้นจะกาหนด
รายละเอี ย ดในแต่ ล ะส่ ว นย่อ ยของซอฟต์แ วร์ แ ละปรั บ ปรุ ง ในลัก ษณะ
โครงสร้างลาดับขั้นจากบนลงล่าง
สิ่ งที่ใช้ประกอบการออกแบบเชิงโครงสร้าง คือ แผนภาพกระแสข้อมูล
(Data Flow Diagram :DFD) และรายละเอียดของกระบวนการ (Process
Description)
38
กลยุทธ์และระเบียบวิธีของกาสรออกแบบซอฟต์แวร์
การออกแบบเชิงวัตถุ (Object-oriented Design)
ระเบียบวิธีเชิงวัตถุในปั จจุบนั มีหลากหลายวิธี ในยุคแรกของ
ระเบี ยบวิธีการออกแบบเชิ งวัตถุ จะพิจารณาหาวัตถุในโดเมนที่
สนใจจากค าอธิ บ ายความต้อ งการของลู ก ค้า และจัด โครงสร้ า ง
ของอ็อบเจ็กต์แบบ Inheritance และ Polymorphism ต่อมา ได้มี
ร ะ เ บี ย บ วิ ธี ก า ร อ อ ก แ บ บ ซ อ ฟ ต์ แ ว ร์ แ บ บ ค อ ม โ พ เ น้ น ท์
(Component-base Design) ขึ้นมา เพื่อช่วยให้การผลิตซอฟต์แวร์
รวดเร็ วขึ้น
39
กลยุทธ์และระเบียบวิธีของกาสรออกแบบซอฟต์แวร์
การออกแบบโดยใช้ ข้อมูลเป็ นศูนย์ กลาง
(Data-structure Centered Design)
เป็ นวิธีการออกแบบโดยใช้ขอ้ มูลที่ฟังก์ชนั จะนามาประมวลผล
เป็ นหลัก เริ่ มต้นจากการแสดงโครงสร้ างข้อมูล ทั้งที่ เป็ นข้อมูล
นาเข้าและผลลัพธ์ (Input and Output Data) โดยสร้างเป็ นแผนภาพ
เพื่อจาลองโครงสร้ างของข้อมูลเหล่านั้น ยกตัวอย่างแผนภาพเช่น
Jackson Diagram เป็ นต้น จากนั้น ทีมงานจะนาแผนภาพดังกล่าว
ไปออกแบบโครงสร้างควบคุมการทางานของโปรแกรมต่อไป
40
กลยุทธ์และระเบียบวิธีของกาสรออกแบบซอฟต์แวร์
การออกแบบคอมโพเน้ นท์ (Component-base Design: CBD)
เป็ นวิธีการออกแบบซอฟต์แวร์ ดว้ ยการแบ่งเป็ นส่ วนประกอบ
ย่อยที่เรี ยกว่า คอมโพเน้นท์ จะทางานเป็ นอิสระต่อกัน ทางานได้
ด้วยตนเอง และสามารถประกอบกับคอมโพเน้นท์อื่นเพื่อเติมเต็ม
การทางานให้กบั ซอฟต์แวร์ ได้ ดังนั้น จึงต้องมีการสื่อสารระหว่าง
คอมโพเน้นท์ผ่านทาง Interface ได้ถูกพัฒนาขึ้นพื่อตอบสนอง
ความต้อ งการผลิ ต ซอฟต์ แ วร์ ที่ ส ามารถน ากลับ มาใช้ ใ หม่ไ ด้
41
แบบจาลองที่ใช้ในการออกแบบ
จาแนกได้ เป็ น 2 กลุ่ม ดังนี้
1. กลุ่ม Structural Description (Static View)
2. กลุ่ม Behavioral Description (Dynamic View)
42
แบบจาลองที่ใช้ในการออกแบบ
1. กลุ่ม Structural Description (Static View)
เป็ นแบบจาลองที่ ใช้อธิ บายมุมมองด้านโครงสร้ างของ
ซอฟต์แวร์ โดยแสดงให้เห็นรายละเอียดของแต่ละคอมโพเน้นท์
และความสัมพันธ์ระหว่างคอมโพเน้นท์ดว้ ย
43
แบบจาลองที่ใช้ในการออกแบบ
กลุ่ม Structural Description (Static View)
แบบจาลองในกลุ่มนี้ อาจอธิบายโครงสร้างด้วยแผนภาพหรื อข้อความ ได้แก่
Architecture Description Language ADU ใช้อธิ บายสถาปั ตยกรรม
ซ อ ฟ ต์ แ ว ร์ แ บ บ ค อ ม โ พ เ น้ น ท์ แ ล ะ ก า ร เ ชื่ อ ม ต่ อ ค อ ม โ พ เ น้ น ท์
Class And Object Diagram แผนภาพแสดงโครงสร้างของคลาส (อ็อบ
เจ็กต์) และความสัมพันธ์ระหว่างคลาส
Component Diagram แผนภาพแสดงคอมโพเน้นท์ที่เป็ นส่ วนประกอบ
ของระบบ และแสดงความสัมพันธ์ระหว่างคอมโพเน้นท์ นอกจากนี้ ยงั แสดง
ให้เห็น Interface ของคอมโพเน้นท์ดว้ ย
44
แบบจาลองที่ใช้ในการออกแบบ
กลุ่ม Structural Description (Static View)
Collaboration Responsibility Card CRC ใช้บนั ทึกชื่อคอมโพเน้นท์
(คลาส) พร้อมกับคอมโพเน้นท์ที่มีความสัมพันธ์กนั และหน้าที่ของคอมโพ
เน้นท์ดว้ ย
Deployment Diagram แผนภาพแสดงโครงสร้างทางด้านฮาร์ ดแวร์
(โหนด) ของระบบและความสั ม พั น ธ์ ร ะหว่ า งโหนดชนิ ดต่ า งๆ
Entity Relationship Diagram ERD แผนภาพแสดงความสัมพันธ์
ระหว่าง Entity ใช้แสดงโครงร่ างของฐานข้อมูล
45
แบบจาลองที่ใช้ในการออกแบบ
กลุ่ม Structural Description (Static View)
Interface Description Language IDL มีลกั ษณะคล้ายกับการเขียน
คาสั่ งในโปรแกรม ใช้ กาหนดรายละเอียดของ Interface
Jackson Structure Diagram แผนภาพแสดงโครงสร้ างควบคุมการ
ประมวลผลข้ อมูลแบบเรียงลาดับแบบเลือกทา
Structure Chart แผนภาพแสดงโครงสร้ างของโปรแกรม แสดงให้ เห็น
การเรียกใช้ โมดูล
46
46
แบบจาลองที่ใช้ในการออกแบบ
2. กลุ่ม Behavioral Description (Dynamic View)
เป็ นแบบจาลองที่ใช้อธิบายมุมมองด้านพฤติกรรมการทางานของ
ซอฟต์ แ วร์ แ ละคอมโพเน้ น ท์ แ สดงให้ เ ห็ น พฤติ ก รรม การท างานที่
เปลี่ยนแปลงไปเมื่อเกิดเหตุการณ์ใดเหตุการณ์หนึ่ง
Activity Diagram แผนภาพแสดงลาดับการดาเนินกิจกรรมของระบบ
ที่เกิดจากการทางานของอ็อบเจ็กต์
Collaborative Diagram แผนภาพแสดงให้เห็นถึงการปฏิสัมพันธ์
ระหว่างอ็อบเจ็กต์ (เมื่อไม่เป็ นไปตามลาดับเวลา)
Data Flow Diagram แผนภาพแสดงการไหลของข้อมูล จาก
47
กระบวนการหนึ่งไปอีกกระบวนการหนึ่ง
แบบจาลองที่ใช้ในการออกแบบ
2. กลุ่ม Behavioral Description (Dynamic View)
Decision Table and Diagram ตารางการตัดสิ นใจใช้แสดงให้
เห็ น การตัด สิ น ใจด าเนิ น กิ จ กรรมอย่า งใดอย่า งหนึ่ งของระบบ
ภายใต้เงื่อนไขที่ซบั ซ้อน
Flowchart and Structure Flowchart แผนภาพแสดงลาดับการ
ดาเนินกิจกรรม
Sequence Diagram แผนภาพแสดงปฏิสัมพันธ์ระหว่างอ็อบ
เจ็กต์โดยแสดงถึ งสถานะและการเปลี่ ยนแปลงสถานะของอ็อบ
เจ็กต์ที่มีต่อเหตุการณ์ใดเหตุการณ์หนึ่ง
48
แบบจาลองที่ใช้ ในการออกแบบ
2. กลุ่ม Behavioral Description (Dynamic View)
Formal Specification Language ใช้กาหนดรายละเอียดของ
Interface และพฤติกรรมของคอมโพเน้นท์
Pseudo-code and Program Design Language PDL มีลกั ษณะ
คล้ายกับการเขียนคาสั่งในโปรแกรม เรี ยกว่า รหัสเทียม จาลองการ
ทางานของฟังก์ชนั โพรซีเดอร์ หรื อเมธอด
49
สรุป
• การออกแบบซอฟต์แวร์ หมายถึง กระบวนการกาหนดสถาปั ตยกรรม
ส่ วนประกอบ ส่ วนประสาน และลักษณะด้านอื่ น ๆ ของระบบหรื อ
ส่ วนประกอบของระบบ
• การออกแบบซอฟต์แวร์ ยังรวมถึ งสิ่ งที่ ได้จากการออกแบบ ซึ่ งก็คือ
แบบจาลองของการออกแบบ (Design Model)
• กระบวนการออกแบบซอฟต์แวร์แบ่งออกเป็ น 2 ระดับ ได้แก่
– การออกแบบเชิงสถาปัตยกรรม (Architectural Design)
– การออกแบบในรายละเอียด (Detailed Design)
50
สรุป
• การออกแบบเชิงสถาปั ตยกรรม เป็ นการแสดงโครงสร้างของระบบหรื อซอฟต์แวร์
ในระดับบน เพื่อแสดงให้เห็นส่ วนประกอบต่าง ๆ ของซอฟต์แวร์
• การออกแบบในรายละเอียด เป็ นการอธิ บายรายละเอียดของแต่ละส่ วนประกอบ
ของซอฟต์แวร์ เพื่อเอื้ออานวยต่อการเขียนโปรแกรม
• สถาปั ตยกรรมซอฟต์แวร์ (Software Architecture) หมายถึง การแสดงให้เห็นถึง
ระบบย่อยและส่ วนประกอบของซอฟต์แวร์ รวมถึงความสัมพันธ์ระหว่างระบบ
ย่อยและส่ วนประกอบเหล่านั้น
• สถาปั ต ยกรรมซอฟต์ แ วร์ เ ป็ นส่ ว นที่ พ ยายามก าหนดโครงสร้ า งภายในของ
ซอฟต์แวร์
51
สรุป
• เมื่อเลือกรู ปแบบของสถาปัตยกรรมแล้ว การออกแบบในรายละเอียดจะต้อง
คานึงถึงสถาปัตยกรรมที่เลือกใช้
• แนวคิดการออกแบบ
– การคิดแบบนามธรรม (Abstraction)
– การแบ่งระบบ (Modularity)
– การซ่อนรายละเอียด (Information Hiding)
– ความเป็ นอิสระต่อกันในการทางาน (Functional Independent)
– การกลัน่ กรอง (Refinement)
– การปรับโครงสร้าง (Refactoring)
52
สรุป
• แนวคิดถูกพัฒนาขึ้น เพื่องานวิศวกรรมซอฟต์แวร์
– ช่วยให้ระบบการผลิตซอฟต์แวร์รวดเร็ ว
– มีประสิ ทธิภาพ
– เพื่อคุณภาพที่ดีของซอฟต์แวร์ (สิ่ งที่สาคัญที่สุด)
• ในระยะการออกแบบต้องมีการจัดการด้านคุณภาพ
– การวิเคราะห์และประเมินคุณภาพ
– การวัดคุณภาพ
– การปรับปรุ งการออกแบบให้มีคุณภาพอย่างต่อเนื่อง
53
แบบทดสอบที่ 10
1. จงอธิบาย การออกแบบซอฟต์แวร์ (Software Design) หมายถึงอะไร
2. ระบบที่ดีตอ้ งมีคุณสมบัติอย่างไร
3. จงอธิ บ ายความแตกต่ า งระหว่า งการออกแบบเชิ งสถาปั ตยกรรม (Architectural
Design) และการออกแบบในรายละเอียด (Detail Design)
4. จงอธิยายความหมายของสถาปัตยกรรมซอฟต์แวร์ (Software Architecture)
5. จงอธิยายความหมายของรู ปแบบสถาปั ตยกรรม
6. รู ปแบบสถาปั ตยกรรม แบ่งได้เป็ นกี่ประเภทอะไรบ้าง จงอธิ บาย
7. จงอธิยายความหมายของแบบแผน (Patten)
54
แบบทดสอบที่ 10
8. Design Pattern แบ่ งได้ เป็ นกีก่ ลุ่ม และแต่ ละกลุ่มประกอบด้ วย Pattern อะไรบ้ าง
9. จงอธิบายเกณฑ์ คุณภาพ (Quality Attribute) ที่ใช้ เป็ นเป้ าหมายในการออกแบบ
ซอฟต์ แวร์ มีอะไรบ้ าง
10. การวิเคราะห์ และประเมินคุณภาพประกอบด้ วยกิจกรรมอะไรบ้ าง
11. การวัดคุณภาพของการออกแบบซอฟต์ แวร์ จะแบ่ งออกเป็ นกี่ประเภท อะไรบ้ าง
จงอธิบาย
12. จงอธิบายแนวทางสาหรับการออกแบบซอฟต์ แวร์ เพือ่ นาไปสู่ การออกแบบทีด่ ี
55
แบบทดสอบที่ 10
13. จงอธิบายแนวคิดในการออกแบบซอฟต์แวร์มีอะไรบ้าง
14. จงอธิ บายข้อแตกต่างระหว่างกลยุทธ์และระเบียบวิธีของการออกแบบซอฟต์แวร์
56
Chapter 10: The End (Any Question?)