บทที่ 6: การออกแบบซอฟต์แวร์

วัตถุประสงค์

• 6.1 เพื่อให้นักศึกษาเข้าใจบทบาทของกระบวนการออกแบบในวงจรชีวิตของการพัฒนาซอฟต์แวร์

• 6.2 เพื่อศึกษาหลักการพื้นฐานของการออกแบบซอฟต์แวร์

• 6.3 เพื่อให้นักศึกษาสามารถวิเคราะห์และออกแบบโครงสร้างระบบซอฟต์แวร์ได้

• 6.4 เพื่อทำความเข้าใจแนวคิดของการออกแบบเชิงวัตถุ (Object-Oriented Design)

6.1 กรอบการออกแบบสถาปัตยกรรมซอฟต์แวร์ 4+1 View Model

• 4+1 View Model เป็นกรอบการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ได้รับความนิยมมากที่สุด

• ถูกนำเสนอครั้งแรกโดย Philippe Kruchten จาก Rational Software (ปัจจุบันเป็นส่วนหนึ่งของ IBM)

• โมเดลนี้แบ่งการมองสถาปัตยกรรมออกเป็น 4 มุมมองหลัก พร้อมกับ 1 มุมมองเสริม เพื่อช่วยให้ครอบคลุมทุกแง่มุมของระบบ

6.1.1 วัตถุประสงค์ของ 4+1 View Model

• ช่วยให้นักพัฒนาและสถาปนิกซอฟต์แวร์ออกแบบและสื่อสารสถาปัตยกรรมได้ดีขึ้น

• รองรับการพัฒนาและบำรุงรักษาระบบในระยะยาว

• มุ่งเน้นไปที่ผู้มีส่วนเกี่ยวข้อง (Stakeholders) ที่แตกต่างกัน เช่น นักพัฒนา ผู้ใช้งาน และผู้ดูแลระบบ

ส่วนประกอบของ 4+1 View Model

1. Logical View (มุมมองเชิงตรรกะ)

   • แสดงโครงสร้างของซอฟต์แวร์ในแง่ของ Component, Class, และ Object

   • ใช้ UML Class Diagram และ Object Diagram เพื่อแสดงโครงสร้างเชิงตรรกะ

   • แสดงฟังก์ชันการทำงานหลักของระบบ มองจากมุมมองของผู้ใช้งานและนักพัฒนา

   • ตัวอย่าง: ระบบจัดการโรงพยาบาลมีโมดูลการลงทะเบียนผู้ป่วย การนัดหมายแพทย์ และการชำระเงิน

2. Development View (มุมมองการพัฒนา)

   • แสดงโครงสร้างระบบในแง่ของ Code Structure และ Module

   • เน้น Package Structure, Component Diagram

   • ช่วยให้เข้าใจการบำรุงรักษาและการปรับปรุงชุดคำสั่ง

   • ตัวอย่าง: แยกชุดคำสั่งเป็นแพ็คเกจ เช่น User Management, Payment Processing, และ Notification Service

3. Process View (มุมมองกระบวนการ)

   • แสดงว่าแต่ละโปรเซส (Process) ทำงานอย่างไร และการสื่อสารระหว่างโปรเซสเป็นอย่างไร

   • เน้นไปที่ Concurrency, Threading, และ Synchronization

   • ใช้ Sequence Diagram, Activity Diagram

   • ตัวอย่าง: ระบบสตรีมมิ่งวิดีโอเช่น Netflix มีการจัดการการสตรีมในโปรเซสหนึ่ง และจัดการการแนะนำเนื้อหาในอีกโปรเซสหนึ่ง

4. Physical View (มุมมองเชิงกายภาพ)

   • แสดงว่า ระบบถูกปรับใช้อย่างไรบนฮาร์ดแวร์และโครงสร้างเครือข่ายเป็นอย่างไร

   • ใช้ Deployment Diagram เพื่อแสดงการเชื่อมต่อระหว่างเซิร์ฟเวอร์ ฐานข้อมูล และคลาวด์

   • เน้น Network Configuration, Server Distribution

   • ตัวอย่าง: ระบบใช้ Load Balancer เพื่อกระจายโหลดไปยังหลายเซิร์ฟเวอร์ และใช้ฐานข้อมูล SQL สำหรับเก็บข้อมูล

5. Scenarios (Use Cases)

   • แสดงสถานการณ์การใช้งาน (Use Cases) เพื่อเชื่อมโยงมุมมองทั้ง 4 แบบ

   • อธิบาย Workflow ของผู้ใช้งานในแต่ละสถานการณ์

   • ใช้ Use Case Diagram เพื่อแสดงความสัมพันธ์ระหว่างผู้ใช้งานและฟังก์ชันต่างๆ ของระบบ

   • ตัวอย่าง: ผู้ใช้เข้าสู่ระบบ (Login), เลือกวิดีโอที่ต้องการสตรีม และทำการชำระเงิน

6.1.2 ความสัมพันธ์ของแต่ละมุมมองใน 4+1 View Model

• ช่วยให้เห็นภาพรวมของระบบในมุมมองต่างๆ

• รองรับการสื่อสารระหว่างทีมงานที่มีบทบาทต่างกัน

• เพิ่มความเข้าใจเกี่ยวกับโครงสร้างและการทำงานของระบบ

• รองรับการพัฒนาและบำรุงรักษาในระยะยาว

• ช่วยในการวิเคราะห์ความเสี่ยงและการแก้ไขปัญหา

6.1.3 ประโยชน์ของการใช้ 4+1 View Model

• เห็นภาพรวมของระบบในมุมมองต่างๆ

• รองรับการสื่อสารระหว่างทีมงานที่มีบทบาทต่างกัน

• เพิ่มความเข้าใจเกี่ยวกับโครงสร้างและการทำงานของระบบ

• รองรับการพัฒนาและบำรุงรักษาในระยะยาว

• ช่วยในการวิเคราะห์ความเสี่ยงและการแก้ไขปัญหา

6.1.4 ตัวอย่างการประยุกต์ใช้งาน 4+1 View Model ในโครงการ

• 
  

• สามารถแสดงตัวอย่างการประยุกต์ใช้ 4+1 View Model ในโครงการระบบการซื้อขายสินค้าออนไลน์และระบบสตรีมมิ่งได้

• 
  

• ตารางที่ 6.2 ตัวอย่างการใช้งานจริงในโครงการ
  

  โครงการ	Logical View	Development View	Process View	Physical View	Scenarios
  ระบบ E- Commerce	โมดูลผู้ใช้	แพ็กเกจ UserService	กระบวนการชำระเงิน	ติดตั้งบน AWS EC2	การสั่งซื้อสินค้า
  ระบบสตรีมมิ่ง	โมดูลการค้นหา, โมดูลสตรีม	แพ็กเกจ SearchService	กระบวนการสตรีมวิดีโอ	ใช้ CDN และ Load Balancer	การเล่นวิดีโอ
  6.2 การออกแบบระบบโดยใช้ UML (Unified Modeling Language)

  • UML (Unified Modeling Language) คือการรวบรวมสัญลักษณ์ที่ใช้ในการสร้างโมเดลซอฟต์แวร์

  • แนวคิดนี้ริเริ่มขึ้นประมาณปี ค.ศ. 1997 โดยศาสตราจารย์ 3 ท่าน ได้แก่ James Rumbaugh, Grady Booch และ Ivar Jacobson

  • ปัจจุบัน UML ได้รับการยอมรับเป็นมาตรฐานสากลของ ISO

  • UML แบ่งออกเป็น 2 ประเภทใหญ่ ๆ คือ Static Diagram และ Dynamic Diagram

  Static Diagram

  • ใช้สำหรับออกแบบโครงสร้างของระบบ เช่น Class diagram, Object diagram, Component diagram, Deployment diagram

  Dynamic Diagram

  • ใช้สำหรับออกแบบและอธิบายการทำงานขององค์ประกอบต่าง ๆ ในระบบ

  • ภายใต้เน้นไปที่การแสดงพฤติกรรม (Behavior)

  6.2.1 Use case Diagram

  • ใช้เพื่อแสดงภาพรวมของสถานการณ์ต่าง ๆ ที่ผู้ใช้ (Actor) สามารถใช้งานระบบได้

  • แต่ละสถานการณ์ที่ระบบสามารถตอบสนองความต้องการของผู้ใช้ จนสำเร็จเรียกว่า Use case

  ความสัมพันธ์ระหว่าง Use case

  • Actor: ตัวแทนของผู้ใช้หรือระบบภายนอกที่โต้ตอบกับระบบ

  • Relationship: ความสัมพันธ์ระหว่าง Actor กับ Use case เช่น Include หรือ Extend

  ตัวอย่างการออกแบบ Use case Diagram

  • ตารางที่ 6.3 สัญลักษณ์ใน Use case Diagram

  ชื่อสัญลักษณ์	รูปสัญลักษณ์	คำอธิบายอย่างย่อ
  Use case	วงรี	แทนฟังก์ชันหรือบริการ
  Actor	รูปร่างคน	แทนผู้ใช้งานระบบ
  Includes	สัญลักษณ์	ใช้ระบุว่าใช้ Use case
  Extends	สัญลักษณ์	ใช้แสดงว่ายืดพฤติกรรม

  6.2.2 Class Diagram

  • ใช้บรรยายโครงสร้างของคลาสที่ประกอบกันอยู่ในระบบ

  ความสำคัญในการออกแบบ Class Diagram

  1. Dependency: ความสัมพันธ์ระหว่างสองสิ่ง

  2. Association: ชุดความสัมพันธ์ที่เชื่อมต่อองค์ประกอบของโมเดล

  3. Generalization: กำหนดความสัมพันธ์ที่เชื่อมต่อองค์ประกอบพิเศษกับองค์ประกอบทั่วไป

  4. Realization: กำหนดความสัมพันธ์ที่องค์ประกอบทั้งสองเชื่อมต่อกัน

  • Class Diagram ถือเป็นพื้นฐานในการมองเห็นมุมมองแบบโครงสร้างของระบบ

  6.2.3 Sequence Diagram

  • ใช้เพื่อแสดงลำดับของการสั่งงานวัตถุให้ทำงานไปจนเสร็จภารกิจหนึ่ง

  • แสดงว่าผู้ใช้จะใช้งานตาม Use case จะทำให้ระบบต้องไปสั่งงานวัตถุตัวไหนบ้าง

  สัญลักษณ์ใน Sequence Diagram

  1. Message: การส่งเป็นการสั่งงานระหว่างวัตถุ

  2. Synchronous Message: ต้องการการตอบสนองทันที

  3. Asynchronous Message: ไม่ต้องรอการตอบสนอง

  4. Object Life Line: เส้นประที่บอกว่าวัตถุยังมีชีวิตอยู่

  5. Activation Bar: แสดงการรอคอยของวัตถุว่าใช้งานอยู่

  6. Guard: การใส่เงื่อนไขในการส่งเมสเสจ

  6.2.4 Statechart Diagram

  • แสดงการเปลี่ยนแปลงสถานะของวัตถุในคลาส

  • แสดงสถานะ (State) ของวัตถุ และเหตุการณ์ที่ทำให้วัตถุเปลี่ยนจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง

  6.2.5 Activity Diagram

  • แสดงกิจกรรมย่อย ๆ ที่ต้องทำให้เสร็จในหนึ่งงาน

  6.2.6 Component Diagram

  • ส่วนประกอบของซอฟต์แวร์ที่มีจุดเชื่อมต่อ (Interface) กำหนดไว้แน่นอน

  6.2.7 Deployment Diagram

  • ใช้สำหรับจัดวางระบบงาน และวางตำแหน่งของส่วนประกอบในเครื่องเซิร์ฟเวอร์หรือเครื่องไคลเอ็นต์ที่เหมาะสม

  6.2.8 Package Diagram

  • ใช้สำหรับการจัดระเบียบคลาสต่างๆ ที่เกี่ยวข้องกันในกลุ่มเดียวกัน เพื่อให้การค้นหาคลาสง่ายขึ้น

  6.3 บุคคลากรที่เกี่ยวข้องในไดอะแกรมแต่ละประเภท

  • นักวิเคราะห์ระบบ, นักออกแบบระบบ, นักพัฒนา, และนักทดสอบระบบจะมีบทบาทในการพัฒนาไดอะแกรมในแต่ละประเภท

  6.4 ตัวอย่างกรณีศึกษาการออกแบบสถาปัตยกรรมซอฟต์แวร์ 4+1 View Model

  • กรณีศึกษา: แพลตฟอร์มซื้อ-ขายปลาสวยงามไทย

  • เช่น การลงทะเบียนและจัดการบัญชีผู้ใช้, การลงข้อมูลสินค้า, การค้นหาข้อมูล, การแสดงข้อมูล, การซื้อขายสินค้า เป็นต้น

  • ข้อก าหนดที่ไม่ใช่ฟังก์ชันเช่น ความสามารถในการขยายระบบ, ความสเถียรภาพ, ความปลอดภัย