← กลับไปยังบทความทั้งหมด

การอธิบายสถาปัตยกรรมซอฟต์แวร์

สรุปใจความสำคัญ

  • การอธิบายสถาปัตยกรรมซอฟต์แวร์เป็นไปตามมาตรฐาน ISO/IEC/IEEE 42010
  • ใช้ 'มุมมอง' (Views) และ 'จุดมอง' (Viewpoints) เพื่อสื่อสารกับผู้มีส่วนได้ส่วนเสียที่แตกต่างกัน
  • ครอบคลุมทั้งประเด็นทางเทคนิคและประเด็นที่ไม่ใช่ทางเทคนิค เช่น ต้นทุน ระยะเวลา และกระบวนการทำงาน
  • มีวิวัฒนาการจากการใช้ภาพวาดอย่างไม่เป็นทางการไปสู่การใช้ภาษาการอธิบายสถาปัตยกรรม (ADL) และกรอบการทำงาน (Frameworks)

การอธิบายสถาปัตยกรรมซอฟต์แวร์ (Software Architecture Description หรือ SAD) คือชุดของแนวทางปฏิบัติในการแสดงออก การสื่อสาร และการวิเคราะห์สถาปัตยกรรมซอฟต์แวร์ ซึ่งผลลัพธ์ที่ได้จากการนำแนวทางเหล่านี้ไปใช้จะปรากฏในรูปแบบของชิ้นงาน (Work Product) ที่อธิบายโครงสร้างและคุณลักษณะของซอฟต์แวร์ ตามมาตรฐาน ISO/IEC/IEEE 42010

ในบางครั้ง การอธิบายสถาปัตยกรรมอาจถูกเรียกว่า การนำเสนอสถาปัตยกรรม (Architecture Representations), ข้อกำหนดสถาปัตยกรรม (Architecture Specifications) หรือ เอกสารประกอบสถาปัตยกรรมซอฟต์แวร์ (Software Architecture Documentation)

แนวคิดหลักในการอธิบายสถาปัตยกรรม

การอธิบายสถาปัตยกรรมเป็นกิจกรรมการสร้างแบบจำลอง (Modeling Activity) โดยสถาปนิกซอฟต์แวร์จะใช้เทคนิคและรูปแบบการนำเสนอที่หลากหลายเพื่อบันทึกรายละเอียดของระบบ แบบจำลองเหล่านี้สามารถอยู่ในรูปแบบของข้อความ, ภาพวาดอย่างไม่เป็นทางการ, แผนภาพ (Diagrams) หรือภาษาการสร้างแบบจำลองที่เป็นทางการ (Modeling Language)

การใช้มุมมอง (Views) และจุดมอง (Viewpoints)

เนื่องจากระบบซอฟต์แวร์มีความซับซ้อน สถาปนิกจึงมักจัดระเบียบแบบจำลองออกเป็น มุมมอง (Views) เพื่อให้สามารถตอบโจทย์ความต้องการของผู้มีส่วนได้ส่วนเสีย (Stakeholders) ที่แตกต่างกัน เช่น ผู้ใช้งานปลายทาง, เจ้าของระบบ, นักพัฒนาซอฟต์แวร์ และผู้จัดการโครงการ

  • จุดมอง (Viewpoint): คือข้อกำหนดหรือวิธีการมองระบบ ซึ่งจะระบุว่ามุมมองนั้นๆ จะตอบสนองต่อความกังวล (Concerns) ของผู้มีส่วนได้ส่วนเสียกลุ่มใด และใช้สัญลักษณ์หรือข้อกำหนดในการสร้างแบบจำลองอย่างไร
  • มุมมอง (View): คือผลลัพธ์ที่ได้จากการนำจุดมองไปใช้กับระบบจริง เพื่อแสดงรายละเอียดในด้านที่สนใจ เช่น ด้านการทำงาน (Functionality), ความปลอดภัย (Safety), ความน่าเชื่อถือ (Reliability) หรือการขยายตัวของระบบ (Scalability)

อย่างไรก็ตาม การใช้หลายมุมมองอาจนำไปสู่ปัญหาความซ้ำซ้อนหรือความไม่สอดคล้องกันของข้อมูล ดังนั้นจึงต้องมีกลไกในการจัดการความสัมพันธ์ระหว่างมุมมองเพื่อให้ข้อมูลมีความถูกต้องและเป็นหนึ่งเดียวกัน

ประวัติและการพัฒนา

ในยุคแรก การอธิบายสถาปัตยกรรมซอฟต์แวร์ใช้เพียงภาพวาดและข้อความอธิบายอย่างไม่เป็นทางการ ซึ่งยังคงเป็นวิธีที่นิยมใช้มากที่สุดในอุตสาหกรรมปัจจุบัน การพัฒนาต่อมาได้รับอิทธิพลจากวิศวกรรมซอฟต์แวร์ (เช่น การแยกส่วนข้อมูล หรือ Data Abstraction) และการออกแบบระบบ (เช่น SARA)

แนวคิดเรื่อง Programming in the Large นำไปสู่การสร้างภาษาการเชื่อมต่อโมดูล (Module Interconnection Languages - MILs) ซึ่งมุ่งเน้นการแสดงคุณสมบัติขนาดใหญ่ของซอฟต์แวร์ เช่น โมดูล ความสัมพันธ์ และการพึ่งพากัน ซึ่งส่งผลต่อการพัฒนาภาษาโปรแกรมอย่าง Ada และมาตรฐานการสร้างแบบจำลองอย่าง UML (Unified Modeling Language) ในส่วนของ Package และ Subsystem

แนวคิดของ Perry และ Wolf

Perry และ Wolf ได้นำแนวคิดจากสถาปัตยกรรมอาคารมาประยุกต์ใช้ โดยเสนอว่าการนำเสนอสถาปัตยกรรมควรประกอบด้วย องค์ประกอบ (Elements), รูปแบบ (Form) และเหตุผล (Rationale) โดยแบ่งองค์ประกอบออกเป็น 3 ประเภท ได้แก่:

  1. การประมวลผล (Processing): วิธีการที่ข้อมูลถูกเปลี่ยนแปลง
  2. ข้อมูล (Data): ข้อมูลที่ถูกนำมาใช้และประมวลผล
  3. การเชื่อมต่อ (Connecting): ส่วนที่ยึดองค์ประกอบอื่นๆ เข้าด้วยกัน

กลไกในการอธิบายสถาปัตยกรรม

เพื่อให้สามารถนำรูปแบบการอธิบายที่ประสบความสำเร็จกลับมาใช้ซ้ำได้ จึงมีการพัฒนากลไกต่างๆ ดังนี้:

  • จุดมองสถาปัตยกรรม (Architecture Viewpoints): การกำหนดมาตรฐานในการมองระบบเพื่อตอบโจทย์ผู้มีส่วนได้ส่วนเสีย
  • ภาษาการอธิบายสถาปัตยกรรม (Architecture Description Languages - ADLs): ภาษาที่เป็นทางการสำหรับระบุโครงสร้างและพฤติกรรมของระบบ
  • กรอบการทำงานสถาปัตยกรรม (Architecture Frameworks): โครงสร้างระดับสูงที่ช่วยให้การออกแบบและสื่อสารสถาปัตยกรรมเป็นระบบมากขึ้น

คำถามที่พบบ่อย

Software Architecture Description (SAD) คืออะไร?

คือชุดของแนวทางปฏิบัติและผลลัพธ์ (เอกสารหรือแบบจำลอง) ที่ใช้ในการแสดงออก สื่อสาร และวิเคราะห์โครงสร้างของสถาปัตยกรรมซอฟต์แวร์ เพื่อให้ผู้มีส่วนได้ส่วนเสียเข้าใจระบบตรงกัน

ความแตกต่างระหว่าง View และ Viewpoint คืออะไร?

Viewpoint คือ 'แม่แบบ' หรือข้อกำหนดที่บอกว่าควรจะมองระบบในมุมไหนและใช้สัญลักษณ์อะไร ส่วน View คือ 'ผลลัพธ์' ที่เกิดจากการนำ Viewpoint นั้นมาใช้กับระบบจริงเพื่อแสดงรายละเอียดเฉพาะด้าน

การอธิบายสถาปัตยกรรมเน้นเฉพาะเรื่องทางเทคนิคเท่านั้นหรือไม่?

ไม่ใช่ การอธิบายสถาปัตยกรรมต้องครอบคลุมถึงประเด็นที่ผู้มีส่วนได้ส่วนเสียสนใจ ซึ่งรวมถึงเรื่องที่ไม่ใช่ทางเทคนิค เช่น การบริหารจัดการต้นทุน กำหนดการ และกระบวนการพัฒนา