ภาษาสำหรับการอธิบายสถาปัตยกรรม ( ADLs ) ถูกนำไปใช้ในหลายสาขา ได้แก่วิศวกรรมระบบวิศวกรรมซอฟต์แวร์และ การสร้างแบบจำลอง และวิศวกรรม องค์กร

ชุมชนวิศวกรรมระบบใช้ภาษาอธิบายสถาปัตยกรรม (Architecture Description Language ) เป็นภาษาและ/หรือแบบจำลองเชิงแนวคิดเพื่ออธิบายและแสดงสถาปัตยกรรมของระบบ

ชุมชนวิศวกรรมซอฟต์แวร์ใช้ภาษาอธิบายสถาปัตยกรรม (Architecture Description Language หรือ ADL) เป็นภาษาคอมพิวเตอร์เพื่อสร้างคำอธิบายของสถาปัตยกรรมซอฟต์แวร์ในกรณีของสถาปัตยกรรม ทางเทคนิค สถาปัตยกรรมนั้นจะต้องสื่อสารไปยังนักพัฒนาซอฟต์แวร์ ในขณะที่สถาปัตยกรรมเชิงฟังก์ชันจะสื่อสารไปยังผู้มีส่วนได้ส่วนเสียและผู้ใช้ต่างๆ ตัวอย่างของ ADL ที่ได้รับการพัฒนาแล้ว ได้แก่Acme (พัฒนาโดยCMU ), AADL (ได้รับการกำหนดมาตรฐานโดยSAE ), C2 (พัฒนาโดยUCI ), SBC-ADL (พัฒนาโดยมหาวิทยาลัยแห่งชาติซุนยัตเซน ), Darwin (พัฒนาโดยImperial College London ) และWright (พัฒนาโดยCMU )

เอกสารISO /IEC/IEEE 42010 ^{[ 1 ]}ระบบและวิศวกรรมซอฟต์แวร์—คำอธิบายสถาปัตยกรรมกำหนดภาษาคำอธิบายสถาปัตยกรรมว่าเป็น "รูปแบบการแสดงออกใดๆ สำหรับใช้ในการอธิบายสถาปัตยกรรม" และระบุข้อกำหนดขั้นต่ำเกี่ยวกับ ADL

ชุมชนด้านการสร้างแบบจำลองและการออกแบบระบบระดับองค์กรได้พัฒนาภาษาสำหรับการอธิบายสถาปัตยกรรมที่เหมาะสมกับระดับองค์กร ตัวอย่างเช่นArchiMate (ปัจจุบันเป็นมาตรฐานของThe Open Group ), DEMO , ABACUS (พัฒนาโดยมหาวิทยาลัยเทคโนโลยีซิดนีย์ ) ภาษาเหล่านี้ไม่จำเป็นต้องอ้างอิงถึงส่วนประกอบซอฟต์แวร์ ฯลฯ แต่ส่วนใหญ่จะอ้างอิงถึงสถาปัตยกรรมแอปพลิเคชัน ซึ่งเป็นสถาปัตยกรรมที่สื่อสารไปยังวิศวกรซอฟต์แวร์

เนื้อหาส่วนใหญ่ด้านล่างนี้กล่าวถึงมุมมองของชุมชนวิศวกรรมซอฟต์แวร์เป็นหลัก

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

ADL (Architectural Description Language) ถูกจำแนกออกเป็นสามประเภทใหญ่ๆ ได้แก่ ภาพวาดแบบไม่เป็นทางการด้วยกรอบและเส้น ภาษาอธิบายสถาปัตยกรรมที่เป็นทางการ และสัญกรณ์ที่อิงตาม UML ( Unified Modeling Language )

รูปแบบกล่องและเส้นเป็นวิธีการอธิบายสถาปัตยกรรมซอฟต์แวร์ที่แพร่หลายที่สุดมาเป็นเวลานาน แม้ว่าจะให้เอกสารที่มีประโยชน์ แต่ระดับความไม่เป็นทางการนั้นจำกัดประโยชน์ของการอธิบายสถาปัตยกรรม จึงจำเป็นต้องมีวิธีการที่เข้มงวดมากขึ้นในการอธิบายสถาปัตยกรรมซอฟต์แวร์ อ้างอิงจาก Allen และ Garlan (1997) ^{[ 2 ]} "แม้ว่าคำอธิบาย [กล่องและเส้น] เหล่านี้อาจให้เอกสารที่มีประโยชน์ แต่ระดับความไม่เป็นทางการในปัจจุบันจำกัดประโยชน์ของมัน เนื่องจากโดยทั่วไปแล้วความหมายของคำอธิบายสถาปัตยกรรมดังกล่าวไม่แม่นยำ จึงอาจเป็นไปไม่ได้ที่จะวิเคราะห์สถาปัตยกรรมเพื่อความสอดคล้องหรือกำหนดคุณสมบัติที่ไม่ธรรมดา ยิ่งไปกว่านั้น ไม่มีวิธีใดที่จะตรวจสอบได้ว่าการใช้งานระบบนั้นสอดคล้องกับการออกแบบสถาปัตยกรรมหรือไม่" ข้อสรุปที่คล้ายกันนี้ได้มาจาก Perry และ Wolf (1992) ^{[ 3 ]}ซึ่งรายงานว่า "นอกเหนือจากการให้เอกสารที่ชัดเจนและแม่นยำแล้ว จุดประสงค์หลักของข้อกำหนดคือการวิเคราะห์เอกสารโดยอัตโนมัติและเปิดเผยปัญหาประเภทต่างๆ ที่อาจตรวจไม่พบ"

นับตั้งแต่นั้นมา ได้มีการดำเนินการวิจัยเกี่ยวกับภาษาทางการสำหรับการอธิบายสถาปัตยกรรมซอฟต์แวร์อย่างต่อเนื่อง มีการเสนอ ADL ทางการหลายสิบรายการ โดยแต่ละรายการมีลักษณะเฉพาะด้วยองค์ประกอบทางสถาปัตยกรรมเชิงแนวคิดที่แตกต่างกัน ไวยากรณ์หรือความหมายที่แตกต่างกัน โดยมุ่งเน้นไปที่โดเมนการดำเนินงานเฉพาะ หรือเหมาะสมเฉพาะกับเทคนิคการวิเคราะห์ที่แตกต่างกันเท่านั้น ตัวอย่างเช่น มีการนำเสนอ ADL เฉพาะโดเมนเพื่อจัดการกับระบบฝังตัวและระบบเรียลไทม์ (เช่น AADL [ ^{4 ] EAST} -ADL ^{[ 5 ]}และ EADL ^{[ 6 ]} ) แอปพลิเคชันวงจรควบคุม (DiaSpec ^{[ 7 ]} ) สถาปัตยกรรมสายผลิตภัณฑ์ (Koala ^{[ 8 ]} ) และระบบไดนามิก (Π-ADL ^{[ 9 ]} )) มีการเสนอ ADL เฉพาะการวิเคราะห์เพื่อจัดการกับความพร้อมใช้งาน ความน่าเชื่อถือ ความปลอดภัย การใช้ทรัพยากร คุณภาพข้อมูล และการวิเคราะห์ประสิทธิภาพแบบเรียลไทม์ (AADL การวิเคราะห์เชิงพฤติกรรม (Fractal ^{[ 10 ]} )) และการวิเคราะห์ความน่าเชื่อถือ (TADL ^{[ 11 ]} )

อย่างไรก็ตาม ความพยายามเหล่านี้ยังไม่ได้รับการนำไปใช้ในทางปฏิบัติทางอุตสาหกรรมอย่างที่ต้องการ สาเหตุบางประการของการขาดการนำไปใช้ในอุตสาหกรรมนี้ได้รับการวิเคราะห์โดย Woods และ Hilliard ^{[ 12 ]} Pandey ^{[ 13 ]} Clements ^{[ 14 ]}และอื่นๆ ได้แก่ ADL อย่างเป็นทางการไม่ค่อยได้รับการบูรณาการในวงจรชีวิตของซอฟต์แวร์ ไม่ค่อยได้รับการสนับสนุนจากเครื่องมือที่พัฒนาแล้ว มีเอกสารน้อยมาก มุ่งเน้นไปที่ความต้องการเฉพาะเจาะจงมาก และไม่มีพื้นที่สำหรับส่วนขยายที่ช่วยให้สามารถเพิ่มคุณสมบัติใหม่ได้

เพื่อเอาชนะข้อจำกัดบางประการเหล่านั้นUMLจึงถูกระบุว่าเป็นตัวสืบทอดที่เป็นไปได้ของ ADL ที่มีอยู่เดิม มีข้อเสนอมากมายที่นำเสนอเพื่อใช้หรือขยาย UML เพื่อจำลองสถาปัตยกรรมซอฟต์แวร์ได้อย่างเหมาะสมยิ่งขึ้น^{[ 15 ] [ 16 ] [ 17 ]}

การศึกษาในปี 2013 ^{[ 18 ]}พบว่าโดยทั่วไปแล้วผู้ปฏิบัติงานพึงพอใจกับความสามารถในการออกแบบของ ADLS ที่พวกเขาใช้ แต่มีข้อกังวลหลักหลายประการ ได้แก่ ขาดคุณสมบัติการวิเคราะห์และความสามารถในการกำหนดคุณสมบัตินอกฟังก์ชันการทำงาน ADLS ที่ใช้ในทางปฏิบัติส่วนใหญ่มีต้นกำเนิดมาจากการพัฒนาอุตสาหกรรมมากกว่าการวิจัยทางวิชาการ และจำเป็นต้องมีรูปแบบที่เป็นทางการมากขึ้นและใช้งานได้ดีขึ้น

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

ข้อกำหนดขั้นต่ำ

ภาษาที่ใช้ต้อง:

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

กิจกรรมในชีวิตประจำวัน (ADLs) มีลักษณะร่วมกันดังนี้:

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

กิจกรรมในชีวิตประจำวัน (ADLs) มีความแตกต่างกันในด้านความสามารถดังต่อไปนี้:

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

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

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

โดยทั่วไปแล้ว ชุมชน ADL เห็นพ้องกันว่า สถาปัตยกรรมซอฟต์แวร์คือชุดของส่วนประกอบและการเชื่อมต่อระหว่างส่วนประกอบเหล่านั้น แต่ก็มีสถาปัตยกรรมประเภทต่างๆ เช่น:

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

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

ADL ส่วนใหญ่ใช้สถาปัตยกรรมการเชื่อมต่ออินเทอร์เฟซ

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

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

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

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

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

• อาร์คิเมท
• ภาษาการวิเคราะห์และออกแบบสถาปัตยกรรม
• รุ่น C4 (ซอฟต์แวร์)
• ซี4อินเตอร์โฟลว์
• ดาร์วิน (ADL)
• อีสต์-เอดีแอล
• ไรท์ (ADL)
• ซิสเอดีแอล

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

• เอดีแอล
• ดาร์วิน
• ภาษาสคริปต์
• ซิสเอดีแอล
• ภาษาอธิบายฮาร์ดแวร์

วิกิมีเดียคอมมอนส์มีสื่อที่เกี่ยวข้องกับภาษาอธิบายสถาปัตยกรรม (Architecture description language )

• Medvidovic, N.; Taylor, RN (มกราคม 2000). "กรอบการจำแนกและเปรียบเทียบสำหรับภาษาการอธิบายสถาปัตยกรรมซอฟต์แวร์" IEEE Transactions on Software Engineering . 26 (1): 70– 93. Bibcode : 2000ITSEn..26...70M . doi : 10.1109/32.825767 .
• Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "สิ่งที่อุตสาหกรรมต้องการจากภาษาสถาปัตยกรรม: การสำรวจ" IEEE Transactions on Software Engineering . 39 (6): 869– 891. Bibcode : 2013ITSEn..39..869M . doi : 10.1109/TSE.2012.74 . S2CID  6383726 .
• ภาษาที่ใช้ในการอธิบายสถาปัตยกรรม // มหาวิทยาลัย Mälardalen
• Clements, PC (1996). "การสำรวจภาษาการอธิบายสถาปัตยกรรม" (PDF) . รายงานการประชุมเชิงปฏิบัติการนานาชาติครั้งที่ 8 ว่าด้วยการกำหนดคุณสมบัติและการออกแบบซอฟต์แวร์ . หน้า  16–25 . doi : 10.1109/IWSSD.1996.501143 . ISBN 0-8186-7361-3S2CID 7307554 เก็บถาวรจากต้นฉบับ(PDF) เมื่อ วันที่ 24 ธันวาคม 2013
• ลูกคิด
• เอซีเอ็ม
• เอดีเอ็มแอล
• อีสป
• AO-ADL
• ArchiMateตัวอย่างของ ADL สำหรับสถาปัตยกรรมระดับองค์กร
• ByADL (Build Your ADL) - มหาวิทยาลัยลากวิลา
• ซี2 เอสดีแอล
• DAOP-ADL
• ตัวอย่างสาธิต:สถาปัตยกรรมองค์กร ADL อีกตัวอย่างหนึ่ง
• DiaSpec คือแนวทางและเครื่องมือในการสร้างเฟรมเวิร์กแบบกระจายจากสถาปัตยกรรมซอฟต์แวร์
• Malavolta, I.; Muccini, H.; Pelliccione, P.; Tamburri, D. (มกราคม–กุมภาพันธ์ 2010). "การจัดให้มีความสามารถในการทำงานร่วมกันของภาษาสถาปัตยกรรมและเครื่องมือผ่านเทคโนโลยีการแปลงแบบจำลอง" IEEE Transactions on Software Engineering . 36 (1): 119– 140. Bibcode : 2010ITSEn..36..119M . doi : 10.1109/TSE.2009.51 . S2CID  6825192 .ดับเบิลลี่
• เร็ว
• เอสเอสอีพี
• ยูนิคอน
• ไรท์