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

คำอธิบายสถาปัตยกรรม (ADs) บางครั้งเรียกว่าการแสดงสถาปัตยกรรมข้อกำหนดสถาปัตยกรรม [ ^{1 ] หรือ} เอกสาร สถาปัตยกรรมซอฟต์แวร์

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

บ่อยครั้งที่แบบจำลองของคำอธิบายสถาปัตยกรรมจะถูกจัดระเบียบเป็น มุมมอง สถาปัตยกรรมหลายมุมมอง โดยที่ “แต่ละมุมมองจะกล่าวถึงข้อกังวลเฉพาะที่น่าสนใจสำหรับผู้มีส่วนได้ส่วนเสียที่แตกต่างกันของระบบ” ^{[ 2 ]} มุมมองสถาปัตยกรรมคือวิธีการมองระบบ ( RM ODP ) แต่ละมุมมองในคำอธิบายสถาปัตยกรรมควรมีเอกสารประกอบมุมมองที่กล่าวถึงข้อกังวลและผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้อง รวมถึงประเภทของแบบจำลอง สัญลักษณ์ และข้อกำหนดการสร้างแบบจำลองที่ใช้ ( ISO/IEC/IEEE 42010 )

การใช้มุมมองหลายมุมมอง แม้ว่าจะมีประสิทธิภาพในการสื่อสารกับผู้มีส่วนได้ส่วนเสียที่หลากหลาย และการบันทึกและวิเคราะห์ข้อกังวลที่หลากหลาย ก็อาจก่อให้เกิดปัญหาได้เช่นกัน เนื่องจากมุมมองต่างๆ มักจะไม่เป็นอิสระต่อกัน ศักยภาพในการทับซ้อนกันอาจหมายถึงความซ้ำซ้อนหรือความไม่สอดคล้องกันระหว่างมุมมองของระบบเดียว^{[ 3 ]}สามารถใช้กลไกต่างๆ ในการกำหนดและจัดการความสัมพันธ์ระหว่างมุมมองต่างๆ เพื่อแบ่งปันรายละเอียด ลดความซ้ำซ้อน และบังคับใช้ความสอดคล้องกัน

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

คำอธิบายสถาปัตยกรรมในยุคแรกใช้รูปภาพและแผนภาพที่ไม่เป็นทางการและข้อความที่เกี่ยวข้อง คำอธิบายที่ไม่เป็นทางการยังคงเป็นการนำเสนอที่ใช้กันอย่างแพร่หลายที่สุดในอุตสาหกรรม^{[ 4 ]} อิทธิพลต่อคำอธิบายสถาปัตยกรรมมาจากสาขาวิศวกรรมซอฟต์แวร์ (เช่น การสรุปข้อมูลและการเขียนโปรแกรมขนาดใหญ่) และจากการออกแบบระบบ (เช่น SARA ^{[ 5 ]} )

งานเกี่ยวกับการเขียนโปรแกรมในขนาดใหญ่ เช่น ภาษาการเชื่อมต่อโมดูล (MILs) มุ่งเน้นไปที่การแสดงคุณสมบัติขนาดใหญ่ของซอฟต์แวร์: ^{[ 6 ]}โมดูล (รวมถึงโปรแกรม ไลบรารี รูทีนย่อย และระบบย่อย) และความสัมพันธ์ของโมดูล (การพึ่งพาและการเชื่อมต่อระหว่างโมดูล) งานนี้มีอิทธิพลต่อทั้งแนวคิดเชิงสถาปัตยกรรมเกี่ยวกับภาษาการเขียนโปรแกรม (เช่น Ada) และสัญกรณ์การออกแบบและสถาปัตยกรรม (เช่น แผนภาพ Buhr และแผนที่กรณีการใช้งาน และถูกกำหนดเป็นรหัสในคุณลักษณะทางสถาปัตยกรรมของ UML: แพ็กเกจ ระบบย่อย การพึ่งพา) และงานส่วนใหญ่เกี่ยวกับภาษาการอธิบายสถาปัตยกรรม นอกจาก MILs แล้ว ภายใต้อิทธิพลของงานที่พัฒนาแล้วในด้านข้อกำหนดและการออกแบบภายในวิศวกรรมซอฟต์แวร์ โมเดลประเภทต่างๆ ได้ถูก "ยก" มาจากวิศวกรรมซอฟต์แวร์และการออกแบบเพื่อนำไปใช้กับการอธิบายสถาปัตยกรรม ซึ่งรวมถึงโมเดลฟังก์ชันและกิจกรรมจาก Structured Analysis SADT เทคนิค การสร้างแบบจำลองข้อมูล ( เอนทิตี-ความสัมพันธ์) และเทคนิคเชิงวัตถุ

Perry และ Wolf ^{[ 1 ]}อ้างถึงแบบอย่างของสถาปัตยกรรมอาคารสำหรับบทบาทของมุมมองที่หลากหลาย: "สถาปนิกอาคารทำงานร่วมกับลูกค้าโดยใช้มุมมองที่แตกต่างกันหลายมุมมองซึ่งเน้นแง่มุมเฉพาะของอาคาร"

เพอร์รีและวูล์ฟเสนอว่า การนำเสนอสถาปัตยกรรมควรประกอบด้วย {องค์ประกอบ รูปทรง และเหตุผล}โดยแยกแยะองค์ประกอบออกเป็นสามประเภท (และด้วยเหตุนี้จึงมีมุมมองสามประเภท):

• การประมวลผล: วิธีการแปลงข้อมูล;
• ข้อมูล: สารสนเทศที่ถูกนำมาใช้และแปลงสภาพ;
• การเชื่อมต่อ: กาวที่ยึดองค์ประกอบอื่นๆ เข้าด้วยกัน;

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

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

หลังจากบทความของ Perry และ Wolf เผยแพร่ออกไป ก็ได้เกิดแนวคิดสองสำนักเกี่ยวกับการอธิบายสถาปัตยกรรมซอฟต์แวร์ขึ้นมา:

• โรงเรียนที่มีมุมมองหลากหลาย
• สำนักโครงสร้างนิยม

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

• มุมมองทางสถาปัตยกรรม
• ภาษาอธิบายสถาปัตยกรรม
• กรอบสถาปัตยกรรม

โดยทั่วไปแล้ว คำอธิบายสถาปัตยกรรมซอฟต์แวร์จะถูกจัดระเบียบเป็นมุมมอง (views ) ซึ่งคล้ายคลึงกับแบบแปลน ประเภทต่างๆ ที่ใช้ในงานสถาปัตยกรรม อาคาร แต่ละมุมมองจะกล่าวถึงชุดของข้อกังวลของระบบ โดยปฏิบัติตามข้อกำหนดของมุมมอง นั้น ๆ ซึ่งมุมมองคือข้อกำหนดที่อธิบายถึงสัญลักษณ์และเทคนิคการสร้างแบบจำลองที่จะใช้ในมุมมองนั้นๆ เพื่อแสดงสถาปัตยกรรมที่เกี่ยวข้องจากมุมมองของกลุ่มผู้มีส่วนได้ส่วนเสียและข้อกังวลของพวกเขา ( ISO/IEC 42010 ) มุมมองจะระบุไม่เพียงแต่ข้อกังวลที่กำหนดไว้ (เช่น สิ่งที่จะต้องกล่าวถึง) แต่ยังรวมถึงการนำเสนอ ประเภทของแบบจำลองที่ใช้ ข้อกำหนดที่ใช้ และกฎความสอดคล้อง (การตรงกัน) ใดๆ เพื่อให้มุมมองนั้นสอดคล้องกับมุมมองอื่นๆ ด้วย

ตัวอย่างของมุมมองต่างๆ ได้แก่:

• มุมมองเชิงฟังก์ชัน
• มุมมองเชิงตรรกะ
• มุมมองด้านข้อมูล/สารสนเทศ
• มุมมองของโมดูล
• มุมมองของส่วนประกอบและตัวเชื่อมต่อ
• มุมมองด้านข้อกำหนด
• มุมมองของนักพัฒนา/ผู้ใช้งาน
• มุมมองการทำงานพร้อมกัน/กระบวนการ/รันไทม์/เธรด/การดำเนินการ
• มุมมองด้านประสิทธิภาพ
• มุมมองด้านความปลอดภัย
• มุมมองด้านกายภาพ/การใช้งาน/การติดตั้ง
• มุมมองการกระทำ/ข้อเสนอแนะของผู้ใช้

คำว่าviewtypeใช้เพื่ออ้างถึงหมวดหมู่ของมุมมองที่คล้ายกันซึ่งมีชุดองค์ประกอบและความสัมพันธ์ร่วมกัน^{[ 4 ]}

ภาษาอธิบายสถาปัตยกรรม ( ADL ) คือวิธีการแสดงออกใดๆ ที่ใช้ในการอธิบายสถาปัตยกรรมซอฟต์แวร์ ( ISO/IEC/IEEE 42010 ) มีการพัฒนา ADL เฉพาะทางมากมายตั้งแต่ทศวรรษ 1990 รวมถึงAADL (มาตรฐาน SAE), Wright (พัฒนาโดย Carnegie Mellon), Acme (พัฒนาโดย Carnegie Mellon), xADL (พัฒนาโดย UCI), Darwin (พัฒนาโดยImperial College London ), DAOP-ADL (พัฒนาโดยมหาวิทยาลัยมาลากา) และByADL (มหาวิทยาลัยลากวีลา ประเทศอิตาลี) ADL ในยุคแรกๆ เน้นการสร้างแบบจำลองระบบในแง่ของส่วนประกอบ ตัวเชื่อมต่อ และการกำหนดค่า ADL ในยุคหลังๆ (เช่น ArchiMate และ SysML) มีแนวโน้มที่จะเป็นภาษา "ครอบคลุมกว้าง" ที่สามารถแสดงออกได้ไม่เพียงแค่ส่วนประกอบและตัวเชื่อมต่อเท่านั้น แต่ยังรวมถึงประเด็นต่างๆ มากมายผ่านภาษาย่อยหลายภาษาด้วย นอกจากภาษาเฉพาะทางแล้ว ภาษาที่มีอยู่แล้ว เช่นUMLยังสามารถใช้เป็น ADL ได้"สำหรับการวิเคราะห์ การออกแบบ และการนำระบบซอฟต์แวร์ไปใช้งาน ตลอดจนการสร้างแบบจำลองทางธุรกิจและกระบวนการที่คล้ายคลึงกัน"

กรอบสถาปัตยกรรมรวบรวม "ข้อตกลง หลักการ และแนวปฏิบัติสำหรับการอธิบายสถาปัตยกรรมที่กำหนดขึ้นภายในโดเมนการใช้งานเฉพาะและ/หรือชุมชนของผู้มีส่วนได้ส่วนเสีย" ( ISO/IEC/IEEE 42010 ) โดยปกติแล้วกรอบงานจะถูกนำไปใช้ในแง่ของมุมมองหรือ ADL หนึ่งมุมมองขึ้นไป กรอบงานที่น่าสนใจในสถาปัตยกรรมซอฟต์แวร์ ได้แก่:

• อาร์ค42
• รุ่น C4
• 4+1
• RM-ODP (แบบจำลองอ้างอิงของการประมวลผลแบบกระจายเปิด)
• โทกาฟ

แนวทางนี้ ซึ่งนำเสนอในบทความที่มีอิทธิพลอย่างมากของ Kruchten ในปี 1995 เกี่ยวกับ"แบบจำลองมุมมอง 4+1"เน้นย้ำถึงผู้มีส่วนได้ส่วนเสียและความกังวลที่หลากหลายที่จะต้องนำมาสร้างแบบจำลอง^{[ 2 ]}

ประการที่สอง สะท้อนให้เห็นในงานของ CMU และที่อื่นๆ แนวคิดที่ว่าสถาปัตยกรรมคือการจัดระเบียบระดับสูงของระบบในระหว่างการทำงาน และสถาปัตยกรรมควรได้รับการอธิบายในแง่ของส่วนประกอบและตัวเชื่อมต่อ: "สถาปัตยกรรมของระบบซอฟต์แวร์กำหนดระบบนั้นในแง่ของส่วนประกอบการคำนวณและการโต้ตอบระหว่างส่วนประกอบเหล่านั้น" ^{[ 7 ]}

ในช่วงทศวรรษ 1990-2000 งานวิจัยเชิงวิชาการส่วนใหญ่เกี่ยวกับ ADL เกิดขึ้นภายใต้กรอบแนวคิดของส่วนประกอบและตัวเชื่อมต่อ อย่างไรก็ตาม ADL เหล่านี้มีผลกระทบต่ออุตสาหกรรมน้อยมาก^{[ 8 ]} ตั้งแต่ทศวรรษ 1990 เป็นต้นมา มีแนวทางที่สอดคล้องกันมากขึ้นในการอธิบายสถาปัตยกรรม โดยIEEE 1471ในปี 2000 ได้กำหนดแนวปฏิบัติที่ดีที่สุดไว้ คือ สนับสนุน แต่ไม่บังคับให้มีมุมมองหลายมุมมองใน AD

การขยายความในด้านเหตุผลของสูตรดั้งเดิมของ Perry และ Wolf ทำให้เกิดแนวคิดที่สามขึ้นมา โดยบันทึกการตัดสินใจและเหตุผลในการตัดสินใจเป็นวิธีสำคัญในการคิดและแสดงออกถึงสถาปัตยกรรมซอฟต์แวร์^{[ 9 ]} แนวทางนี้ถือว่าการตัดสินใจเป็นองค์ประกอบชั้นหนึ่งของคำอธิบายสถาปัตยกรรม ทำให้สิ่งที่มักจะแฝงอยู่ในการนำเสนอแบบก่อนหน้านี้มีความชัดเจนมากขึ้น

คำอธิบายด้านสถาปัตยกรรมมีวัตถุประสงค์หลากหลายประการ รวมถึง ( มาตรฐาน ISO/IEC/IEEE 42010 ):

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

• ภาษาอธิบายสถาปัตยกรรม
• กรอบสถาปัตยกรรม
• การแยกส่วนความรับผิดชอบ ( ความรับผิดชอบหลักและความรับผิดชอบ (วิทยาศาสตร์คอมพิวเตอร์) )
• แบบจำลองสถาปัตยกรรมซอฟต์แวร์
• เอกสารสถาปัตยกรรมซอฟต์แวร์
• แบบจำลองวิว