แบบจำลองสถาปัตยกรรม

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

สถาปัตยกรรมซอฟต์แวร์ต้องอธิบายถึงกลุ่มของส่วนประกอบการเชื่อมต่อการโต้ตอบระหว่างส่วนประกอบเหล่านั้นและการกำหนดค่าการปรับใช้ของส่วนประกอบทั้งหมด

สถาปัตยกรรมซอฟต์แวร์สามารถกำหนดได้หลายวิธี -

• UML (Unified Modeling Language) - UML เป็นหนึ่งในโซลูชันเชิงวัตถุที่ใช้ในการสร้างแบบจำลองและการออกแบบซอฟต์แวร์

• Architecture View Model (4+1 view model) - แบบจำลองมุมมองสถาปัตยกรรมแสดงถึงข้อกำหนดด้านการทำงานและไม่ใช้งานได้ของซอฟต์แวร์แอปพลิเคชัน

• ADL (Architecture Description Language) - ADL กำหนดสถาปัตยกรรมซอฟต์แวร์อย่างเป็นทางการและตามความหมาย

UML

UML ย่อมาจาก Unified Modeling Language เป็นภาษาภาพที่ใช้ในการสร้างพิมพ์เขียวซอฟต์แวร์ UML ถูกสร้างโดย Object Management Group (OMG) ร่างข้อกำหนด UML 1.0 ได้รับการเสนอต่อ OMG ในเดือนมกราคม 1997 ซึ่งทำหน้าที่เป็นมาตรฐานสำหรับการวิเคราะห์ความต้องการซอฟต์แวร์และเอกสารการออกแบบซึ่งเป็นพื้นฐานสำหรับการพัฒนาซอฟต์แวร์

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

องค์ประกอบเป็นเหมือนส่วนประกอบที่สามารถเชื่อมโยงในรูปแบบต่างๆเพื่อสร้างภาพ UML ที่สมบูรณ์ซึ่งเรียกว่าไฟล์ diagram. ดังนั้นจึงเป็นสิ่งสำคัญมากที่จะต้องเข้าใจแผนภาพต่างๆเพื่อนำความรู้ไปใช้ในระบบชีวิตจริง เรามีแผนภาพสองประเภทกว้าง ๆ และยังแบ่งออกเป็นหมวดหมู่ย่อยอีก ได้แก่Structural Diagrams และ Behavioral Diagrams.

แผนภาพโครงสร้าง

แผนภาพโครงสร้างแสดงลักษณะคงที่ของระบบ ลักษณะคงที่เหล่านี้แสดงถึงส่วนต่างๆของแผนภาพซึ่งเป็นโครงสร้างหลักดังนั้นจึงมีเสถียรภาพ

ชิ้นส่วนคงที่เหล่านี้แสดงโดยคลาสอินเทอร์เฟซอ็อบเจ็กต์ส่วนประกอบและโหนด แผนภาพโครงสร้างแบ่งย่อยได้ดังนี้ -

• แผนภาพคลาส
• แผนภาพวัตถุ
• แผนภาพส่วนประกอบ
• แผนภาพการปรับใช้
• แผนภาพแพ็คเกจ
• โครงสร้างคอมโพสิต

ตารางต่อไปนี้ให้คำอธิบายสั้น ๆ ของไดอะแกรมเหล่านี้ -

ซีเนียร์	แผนภาพและคำอธิบาย
1	Class แสดงถึงการวางแนววัตถุของระบบ แสดงให้เห็นว่าคลาสมีความสัมพันธ์กันอย่างไร
2	Object แสดงถึงชุดของอ็อบเจ็กต์และความสัมพันธ์ที่รันไทม์และยังแสดงถึงมุมมองแบบคงที่ของระบบ
3	Component อธิบายส่วนประกอบทั้งหมดความสัมพันธ์ระหว่างกันปฏิสัมพันธ์และส่วนต่อประสานของระบบ
4	Composite structure อธิบายโครงสร้างภายในของส่วนประกอบรวมถึงคลาสทั้งหมดส่วนต่อประสานของส่วนประกอบ ฯลฯ
5	Package อธิบายโครงสร้างแพ็คเกจและองค์กร ครอบคลุมคลาสในแพ็คเกจและแพ็คเกจภายในแพ็คเกจอื่น
6	Deployment แผนภาพการทำให้ใช้งานได้คือชุดของโหนดและความสัมพันธ์ โหนดเหล่านี้เป็นเอนทิตีทางกายภาพที่มีการปรับใช้คอมโพเนนต์

แผนภาพพฤติกรรม

แผนภาพพฤติกรรมโดยพื้นฐานแล้วจะจับภาพลักษณะไดนามิกของระบบ แง่มุมแบบไดนามิกเป็นส่วนที่เปลี่ยนแปลง / เคลื่อนไหวของระบบ UML มีแผนภาพพฤติกรรมประเภทต่อไปนี้ -

• ใช้แผนภาพกรณี
• แผนภาพลำดับ
• แผนภาพการสื่อสาร
• แผนภาพแผนภูมิสถานะ
• แผนภาพกิจกรรม
• ภาพรวมการโต้ตอบ
• แผนภาพลำดับเวลา

ตารางต่อไปนี้ให้คำอธิบายสั้น ๆ ของแผนภาพเหล่านี้ -

ซีเนียร์	แผนภาพและคำอธิบาย
1	Use case อธิบายความสัมพันธ์ระหว่างฟังก์ชันการทำงานและตัวควบคุมภายใน / ภายนอก ตัวควบคุมเหล่านี้เรียกได้ว่าเป็นนักแสดง
2	Activity อธิบายขั้นตอนการควบคุมในระบบ ประกอบด้วยกิจกรรมและการเชื่อมโยง โฟลว์อาจเป็นแบบลำดับพร้อมกันหรือแยกกลุ่มก็ได้
3	State Machine/state chart แสดงถึงการเปลี่ยนแปลงสถานะของระบบที่ขับเคลื่อนด้วยเหตุการณ์ โดยพื้นฐานแล้วจะอธิบายถึงการเปลี่ยนแปลงสถานะของคลาสอินเทอร์เฟซ ฯลฯ ใช้เพื่อให้เห็นภาพปฏิกิริยาของระบบโดยปัจจัยภายใน / ภายนอก
4	Sequence แสดงภาพลำดับของการโทรในระบบเพื่อดำเนินการฟังก์ชันเฉพาะ
5	Interaction Overview รวมแผนภาพกิจกรรมและลำดับเพื่อให้ภาพรวมขั้นตอนการควบคุมของระบบและกระบวนการทางธุรกิจ
6	Communication เช่นเดียวกับแผนภาพลำดับยกเว้นว่าจะเน้นที่บทบาทของวัตถุ การสื่อสารแต่ละครั้งจะเชื่อมโยงกับลำดับลำดับหมายเลขและข้อความในอดีต
7	Time Sequenced อธิบายการเปลี่ยนแปลงตามข้อความในสถานะเงื่อนไขและเหตุการณ์

แบบจำลองมุมมองสถาปัตยกรรม

โมเดลคือคำอธิบายที่สมบูรณ์พื้นฐานและเรียบง่ายของสถาปัตยกรรมซอฟต์แวร์ซึ่งประกอบด้วยหลายมุมมองจากมุมมองหรือมุมมองเฉพาะ

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

4 + 1 ดูโมเดล

แบบจำลองมุมมอง 4 + 1 ได้รับการออกแบบโดย Philippe Kruchten เพื่ออธิบายสถาปัตยกรรมของระบบที่เน้นซอฟต์แวร์โดยอาศัยการใช้มุมมองที่หลากหลายและพร้อมกัน มันคือmultiple viewแบบจำลองที่เน้นคุณสมบัติและข้อกังวลต่างๆของระบบ เป็นมาตรฐานของเอกสารการออกแบบซอฟต์แวร์และทำให้ผู้มีส่วนได้ส่วนเสียทั้งหมดเข้าใจการออกแบบได้ง่าย

เป็นวิธีการตรวจสอบสถาปัตยกรรมสำหรับการศึกษาและจัดทำเอกสารการออกแบบสถาปัตยกรรมซอฟต์แวร์และครอบคลุมทุกแง่มุมของสถาปัตยกรรมซอฟต์แวร์สำหรับผู้มีส่วนได้ส่วนเสียทั้งหมด มีมุมมองที่สำคัญสี่ประการ -

• The logical view or conceptual view - อธิบายรูปแบบวัตถุของการออกแบบ

• The process view - อธิบายกิจกรรมของระบบจับภาพการทำงานพร้อมกันและการซิงโครไนซ์ของการออกแบบ

• The physical view - อธิบายถึงการทำแผนที่ซอฟต์แวร์กับฮาร์ดแวร์และสะท้อนถึงแง่มุมที่กระจายออกไป

• The development view - อธิบายองค์กรแบบคงที่หรือโครงสร้างของซอฟต์แวร์ในการพัฒนาสภาพแวดล้อม

โมเดลมุมมองนี้สามารถขยายได้โดยเพิ่มอีกหนึ่งมุมมองที่เรียกว่า scenario view หรือ use case viewสำหรับผู้ใช้ปลายทางหรือลูกค้าของระบบซอฟต์แวร์ มีความสอดคล้องกับมุมมองอื่น ๆ อีกสี่มุมมองและใช้เพื่อแสดงสถาปัตยกรรมที่ทำหน้าที่เป็นมุมมอง "บวกหนึ่ง" แบบจำลองมุมมอง (4 + 1) รูปต่อไปนี้อธิบายสถาปัตยกรรมซอฟต์แวร์โดยใช้โมเดลมุมมองพร้อมกันห้ามุมมอง (4 + 1)

ทำไมถึงเรียกว่า 4 + 1 แทนที่จะเป็น 5?

use case viewมีความสำคัญเป็นพิเศษเนื่องจากมีรายละเอียดความต้องการระดับสูงของระบบในขณะที่มุมมองอื่น ๆ ให้รายละเอียดว่าข้อกำหนดเหล่านั้นรับรู้ได้อย่างไร เมื่อมุมมองอื่น ๆ ทั้งสี่มุมมองเสร็จสมบูรณ์มันซ้ำซ้อนอย่างมีประสิทธิภาพ อย่างไรก็ตามมุมมองอื่น ๆ ทั้งหมดจะเป็นไปไม่ได้หากไม่มี ภาพและตารางต่อไปนี้แสดงมุมมอง 4 + 1 โดยละเอียด -

	ตรรกะ	กระบวนการ	การพัฒนา	ทางกายภาพ	สถานการณ์
คำอธิบาย	แสดงส่วนประกอบ (Object) ของระบบตลอดจนปฏิสัมพันธ์	แสดงกระบวนการ / กฎเวิร์กโฟลว์ของระบบและวิธีการสื่อสารของกระบวนการโดยเน้นที่มุมมองแบบไดนามิกของระบบ	ให้มุมมอง Building Block ของระบบและอธิบายการจัดระเบียบแบบคงที่ของโมดูลระบบ	แสดงการติดตั้งการกำหนดค่าและการปรับใช้แอปพลิเคชันซอฟต์แวร์	แสดงให้เห็นว่าการออกแบบเสร็จสมบูรณ์โดยดำเนินการตรวจสอบความถูกต้องและภาพประกอบ
ผู้ดู / ผู้ถือหุ้น	ผู้ใช้ปลายทางนักวิเคราะห์และนักออกแบบ	ผู้ประกอบและนักพัฒนา	โปรแกรมเมอร์และผู้จัดการโครงการซอฟต์แวร์	วิศวกรระบบผู้ปฏิบัติงานผู้ดูแลระบบและผู้ติดตั้งระบบ	มุมมองทั้งหมดของมุมมองและผู้ประเมินของพวกเขา
พิจารณา	ความต้องการการทำงาน	ข้อกำหนดที่ไม่ใช่หน้าที่	องค์กรโมดูลซอฟต์แวร์ (การใช้การจัดการซอฟต์แวร์ซ้ำข้อ จำกัด ของเครื่องมือ)	ข้อกำหนดที่ไม่สามารถใช้งานได้เกี่ยวกับฮาร์ดแวร์พื้นฐาน	ความสอดคล้องและความถูกต้องของระบบ
UML - แผนภาพ	คลาสสถานะวัตถุลำดับแผนภาพการสื่อสาร	แผนภาพกิจกรรม	ส่วนประกอบแผนภาพแพ็คเกจ	แผนภาพการปรับใช้	ใช้แผนภาพกรณี

ภาษาคำอธิบายสถาปัตยกรรม (ADL)

ADL เป็นภาษาที่จัดเตรียมไวยากรณ์และความหมายสำหรับการกำหนดสถาปัตยกรรมซอฟต์แวร์ เป็นข้อกำหนดสัญกรณ์ที่มีคุณลักษณะสำหรับการสร้างแบบจำลองสถาปัตยกรรมแนวคิดของระบบซอฟต์แวร์ซึ่งแตกต่างจากการนำไปใช้งานของระบบ

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

ภาษาคำอธิบายสถาปัตยกรรมเป็นภาษาข้อกำหนดที่เป็นทางการซึ่งอธิบายคุณลักษณะของซอฟต์แวร์เช่นกระบวนการเธรดข้อมูลและโปรแกรมย่อยตลอดจนส่วนประกอบฮาร์ดแวร์เช่นโปรเซสเซอร์อุปกรณ์บัสและหน่วยความจำ

ยากที่จะจำแนกหรือแยกความแตกต่างของ ADL และภาษาโปรแกรมหรือภาษาโมเดล อย่างไรก็ตามมีข้อกำหนดต่อไปนี้สำหรับภาษาที่จะจัดประเภทเป็น ADL -

• มันควรจะเหมาะสมสำหรับการสื่อสารสถาปัตยกรรมไปยังทุกฝ่ายที่เกี่ยวข้อง

• ควรเหมาะสำหรับงานสร้างสถาปัตยกรรมการปรับแต่งและการตรวจสอบความถูกต้อง

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

• ควรมีความสามารถในการแสดงรูปแบบสถาปัตยกรรมทั่วไปส่วนใหญ่

• ควรสนับสนุนความสามารถในการวิเคราะห์หรือจัดเตรียมการใช้งานต้นแบบอย่างรวดเร็ว