アーキテクチャ記述言語（Architecture Description Language、ADL）とは、ソフトウェアアーキテクチャやシステムアーキテクチャを記述するためのコンピュータ言語または概念モデルである。ソフトウェア開発者がアーキテクチャについてやり取りする場合や、開発者と発注元との認識あわせに使う。また事業体モデリングでも使われる。ソフトウェア工学分野では、Acme（CMUが開発）、（SAEが標準化）、C2（UCIが開発）、（インペリアル・カレッジ・ロンドンが開発）、（CMUが開発）などがある。事業体モデリングの分野では企業レベルのアーキテクチャ記述言語が開発されている。例えば、（The Open Group）、DEMO、ABACUS（シドニー工科大学が開発）などがある。これらは必ずしもソフトウェアコンポーネントなどを記述しないが、アプリケーションのアーキテクチャをソフトウェア技術者に伝えるのに使われる。以下では主にソフトウェア工学でのADLについて解説している。アーキテクチャを記述するための標準的記法(ADL)があれば、開発者間の対話、初期段階の決定の具体化などで作業がスムーズに進行する。また、ADLで書いたものを遠隔地とやり取りすることもできる。従来、アーキテクチャと言えば、単に四角形を線で繋いだような図を指していた。そのような図で、コンポーネントの役割/特徴、コンポーネント間の関係、システム全体の振る舞いなどが定義されていた。ADL はアーキテクチャを形式的に表現する言語的手法であり、従来の手法の欠点を補う。また、洗練されたADLはアーキテクチャにおける設計上の決定の早期分析と実現可能性の評価を考慮している点も重要である。ADLは大まかに3つに分類される。箱と線で描く図、形式的な言語、UMLベースの記法の3種類である。システムアーキテクチャの記述にはかつては「箱と線」が主に使われていた。これは非形式的であるため、アーキテクチャの説明としての有効性は限定的だった。そのため、より厳密なアーキテクチャの記述法が必要とされた。仕様書は単に明確で正確な文書というだけでなく、自動的分析が可能で潜在する問題を検出できるものが求められていた。その後システムアーキテクチャ記述のための形式言語の研究が続けられてきた。様々な概念要素、文法、意味論を持つADLがいくつも提案されてきており、特定分野のみを得意とするものや特定の分析手法のみに対応したものなどもあった。ドメイン固有ADLの例としては、組み込みシステムやリアルタイムシステム向け（AADL、EAST-ADL、EADL）、制御ループ向け（DiaSpec）、製造ライン向け（Koala）、動的システム向け（Π-ADL）などがある。可用性、信頼性、セキュリティ、リソース消費、データ品質、リアルタイム性能分析（AADL、Fractal）、信頼性分析（TADL）などを考慮した分析指向のADLも提案されている。しかし、これらの成果は産業界ではほとんど採用されていない。なぜADLが普及しないのかについて、Woods and Hilliard、Pandey、Clements らが分析を行っている。形式的ADLはソフトウェア開発に滅多に採用されておらず、主要なツールでもサポートされていない。ADLは一般に解説書が少なく、特定分野に特化しており、新機能を追加する余地がない。そういった既存のADLの限界を打破する代替手法としてUMLが有力となっている。UMLを使用または拡張してソフトウェアアーキテクチャをモデリングする方法が多数提案されている。実際最近の研究によると、ソフトウェア開発者は使用するADLの設計面の機能については満足しているが、分析面の機能や機能以外の特性を定義する能力については不満を持っている。実際の場で使われているのは研究から生まれたものより実践の場で生まれたものが多い。学術界や産業界で様々なADLが開発されている。その多くは単にADLであるだけでなく、アーキテクチャの表現や分析にも対応している。ADLはソリューション（解法）を記述するための言語であり、問題を記述するための要求仕様記述言語ではない。また、ADLは抽象化されたアーキテクチャを特定の解法に結び付けるものではないため、プログラミング言語ではない。ADLはコンポーネントを表現するものであり、全体の振る舞いを記述するモデリング言語とも異なる。ただし、ドメイン固有モデリング (DSM) の言語はコンポーネントを表現することに集中している。ADLの最低限備えるべき特徴は以下の通りである:ADLは一般に形式的に定義された文法と意味を備えたグラフィカルな構文にテキストを埋め込むようになっている。また、分散システムをモデル化する機能を備え、設計情報を扱うことはほとんどないが、汎用の注釈を埋め込む機能を備えている。また詳細さの階層構造を表現できる。また、アーキテクチャレベルでデッドラインやタスクの優先度といったリアルタイム性に関する記述ができるものもある。また、オブジェクト指向設計的なスタイル（継承など）をサポートするものもある。1つのアーキテクチャ記述から製品ラインの定義に従って複数の実体化をサポートしたものもある。長所短所ADLにおいては、ソフトウェアアーキテクチャとはコンポーネント群とそれらの関連を指すのが一般的である。しかし、アーキテクチャには以下のような見方もある。「オブジェクト連携アーキテクチャ」は、オブジェクト指向システムのインタフェースと連携から構成される。インタフェースとは、モジュール群が提供する機能を意味し、連携とはインタフェース間の呼び出し関係を指す。そこにさらにプログラミング言語への適合などが付随する。「インタフェース連携アーキテクチャ」は、インタフェースと連携の役割を拡張したものである。インタフェースとしてはコンポーネントが必要とする（他コンポーネントの）インタフェースとそのコンポーネントが（他コンポーネントに）提供するインターフェイスを記述する。連携はその両方のインタフェースの間で成立する関係である。そこにさらに各種制限が付与される。多くのADLは後者（インタフェース連携アーキテクチャ）を実装している。アーキテクチャと設計という用語の違いは何か？ アーキテクチャは、機能以外の決定と機能的要求仕様の区分に関わり、設計は機能要求仕様を具体化する作業全体を指す。アーキテクチャ上のヒューリスティックはもう一段階下のレベルで行う必要があるため、アーキテクトは区分を有効にするために概要レベルの設計にも関わらなければならない。

出典:wikipedia