アーキテクチャ記述言語

アーキテクチャ記述言語（ADL ）は、システムエンジニアリング、ソフトウェアエンジニアリング、エンタープライズモデリングおよびエンジニアリングなど、いくつかの分野で使用されています。

システムエンジニアリングコミュニティは、システムアーキテクチャを記述および表現するための言語および/または概念モデルとして、アーキテクチャ記述言語を使用します。

ソフトウェアエンジニアリングコミュニティでは、ソフトウェアアーキテクチャの記述を作成するためのコンピュータ言語として、アーキテクチャ記述言語（ADL）を使用します。いわゆる技術アーキテクチャの場合、そのアーキテクチャはソフトウェア開発者に伝えられる必要があります。機能アーキテクチャは、さまざまな利害関係者やユーザーに伝えられます。これまでに開発されたADLには、Acme （ CMUが開発）、AADL（SAEが標準化）、C2 （ UCIが開発）、SBC-ADL（国立中山大学が開発）、Darwin （インペリアル・カレッジ・ロンドンが開発）、Wright（CMUが開発）などがあります。

ISO /IEC/IEEE 42010 ^{[ 1 ]}文書「システムおよびソフトウェアエンジニアリング - アーキテクチャ記述」では、アーキテクチャ記述言語を「アーキテクチャ記述で使用するためのあらゆる形式の表現」と定義し、ADLの最小要件を規定しています。

エンタープライズモデリングおよびエンジニアリングコミュニティは、エンタープライズレベルに対応したアーキテクチャ記述言語も開発してきました。例としては、ArchiMate （現在はThe Open Groupの標準規格）、DEMO 、ABACUS（シドニー工科大学が開発）などがあります。これらの言語は必ずしもソフトウェアコンポーネントなどを指すわけではありません。しかし、そのほとんどは、ソフトウェアエンジニアに伝達されるアーキテクチャとしてアプリケーションアーキテクチャを参照しています。

以下の記述のほとんどは、主にソフトウェアエンジニアリングコミュニティの視点に基づいています。

アーキテクチャを表現するための標準表記法（ADL）は、相互コミュニケーションの促進、初期設計決定の具体化、およびシステムの転送可能な抽象化の作成に役立ちます。従来、アーキテクチャは主に、コンポーネントの性質、特性、接続の意味、システム全体の動作などの注釈が付けられたボックスと線で構成された図で表現されていました。ADLは、アーキテクチャの形式的表現に対する言語的アプローチから生まれたものであり、その欠点を克服しています。また、高度なADLを用いることで、アーキテクチャ設計の決定事項を早期に分析し、実現可能性を検証できることも重要です。

ADLは、大きく3つのカテゴリに分類されます。ボックスと線による非公式な図面、正式なアーキテクチャ記述言語、そしてUML（統一モデリング言語）に基づく表記法です。

長らく、ボックスとラインによる記述はソフトウェアアーキテクチャを記述する最も一般的な手段でした。有用なドキュメントを提供する一方で、その非公式性の高さがアーキテクチャ記述の有用性を制限していました。ソフトウェアアーキテクチャをより厳密に記述する方法が必要とされていました。アレンとガーラン（1997）^{[ 2 ]}は次のように述べています。「これらの[ボックスとラインによる]記述は有用なドキュメントを提供するかもしれませんが、現在の非公式性の高さがその有用性を制限しています。このようなアーキテクチャ記述が何を意味するのかは一般的に不明確であるため、アーキテクチャの一貫性を分析したり、その非自明な特性を決定したりすることは不可能かもしれません。さらに、システムの実装がそのアーキテクチャ設計に忠実であるかどうかを確認する方法はありません。」ペリーとウルフ（1992）^{[ 3 ]}も同様の結論を導き出しており、次のように述べています。「明確で正確なドキュメントを提供することに加えて、仕様の主な目的は、ドキュメントの自動分析を提供し、そうでなければ検出されないであろうさまざまな種類の問題を明らかにすることです。」

それ以来、ソフトウェアアーキテクチャ記述のための形式言語に関する研究が進められてきました。数十の形式的なADLが提案されており、それぞれ異なる概念的なアーキテクチャ要素、異なる構文や意味論、特定の運用ドメインへの焦点、または異なる分析手法にのみ適しているという特徴があります。たとえば、組み込みシステムやリアルタイムシステム（AADL ^{[ 4 ]} 、 EAST-ADL ^{[ 5 ]} 、 EADL ^{[ 6 ]}など）、制御ループアプリケーション（DiaSpec ^{[ 7 ]}）、プロダクトラインアーキテクチャ（Koala ^{[ 8 ]}）、動的システム（Π-ADL ^[ 9 ] ）を扱うためのドメイン固有のADLが提案されています。可用性、信頼性、セキュリティ、リソース消費、データ品質、リアルタイムパフォーマンス分析（AADL、振る舞い分析（Fractal ^{[ 10 ]}））、信頼性分析（TADL ^{[ 11 ]）を扱う}ための分析固有のADLが提案されています。

しかし、これらの取り組みは産業界で期待されたほど採用されていません。産業界で採用されない理由については、WoodsとHilliard ^{[ 12 ]} 、 Pandey ^{[ 13 ]}、Clements ^{[ 14 ]}などが分析しています。形式的なADLはソフトウェアライフサイクルにほとんど統合されておらず、成熟したツールでサポートされることもほとんどなく、ドキュメントもほとんどなく、非常に特定のニーズに焦点を当てており、新しい機能を追加できる拡張の余地がありません。

これらの制約の一部を克服する方法として、UMLは既存のADLの後継として考えられています。ソフトウェアアーキテクチャをより適切にモデル化するためにUMLを使用または拡張するための多くの提案が提示されています。^{[ 15 ] [ 16 ] [ 17 ]}

2013年の研究^{[ 18 ]}では、実務者は使用しているADLSの設計機能に概ね満足しているものの、いくつかの大きな懸念事項があることがわかった。分析機能や機能外特性を定義する機能が不足していること、実務で使用されているものは学術研究ではなく産業開発に由来するものが多いこと、より形式的で使いやすいものである必要があることなどである。

学術機関や産業界によって開発されたADL（アーキテクチャ記述言語）には、非常に多様な種類があります。多くの言語は当初ADLとして開発されたものではありませんでしたが、結果としてアーキテクチャの表現や分析に適していることが判明しました。原則として、ADLは要求言語とは異なります。なぜなら、ADLはソリューション空間に根ざしているのに対し、要求言語は問題空間を記述するからです。また、ADLはアーキテクチャの抽象化を特定のポイントソリューションに結び付けないため、プログラミング言語とも異なります。モデリング言語は振る舞いを表現するのに対し、ADLはコンポーネントの表現に重点を置いています。ただし、コンポーネントの表現に特化したドメイン固有モデリング言語（DSML）も存在します。

最低限の要件

言語は以下の条件を満たす必要があります。

• 関係者全員にアーキテクチャを伝えるのに適していること
• アーキテクチャの作成、改良、検証のタスクをサポートする
• さらなる実装の基礎を提供するため、ADL仕様に情報を追加して、最終的なシステム仕様をADLから導出できるようにする必要があります。
• 一般的な建築様式のほとんどを表現できる機能を提供する
• 分析機能のサポート、または迅速なプロトタイプ実装の提供

日常生活動作（ADL）には以下の共通点があります。

• 多くの場合テキスト形式であり、形式的に定義された構文と意味論を持つグラフィカル構文
• 分散システムをモデル化するための機能
• 汎用的な注釈メカニズムを除けば、設計情報を取得するためのサポートはほとんどない。
• テンプレートをインスタンス化することによるサブストラクチャの作成など、階層的な詳細レベルを表現する機能

ADL（日常生活動作）は、以下の点で異なります。

• 締め切りやタスクの優先順位など、リアルタイムの構造をアーキテクチャレベルで処理する
• さまざまなアーキテクチャスタイルの仕様をサポートする。オブジェクト指向のクラス継承や動的アーキテクチャを扱うものは少ない。
• アーキテクチャの分析をサポートする
• 製品ラインアーキテクチャに関連して、同一アーキテクチャの異なるインスタンスを処理する

ADLコミュニティは一般的に、ソフトウェアアーキテクチャはコンポーネントの集合とそれらの間の接続であることに同意しています。しかし、次のようなさまざまな種類のアーキテクチャが存在します。

ソフトウェアシステムの文脈におけるアーキテクチャは、大まかにソフトウェアアーキテクチャ、ネットワークアーキテクチャ、システムアーキテクチャの3つのカテゴリに分けられます。これらのカテゴリそれぞれにおいて、アーキテクチャとデザインの間には、明確ではあるものの曖昧な区別が存在します。この区別をできる限り普遍的かつ明確にするためには、デザインを動詞ではなく名詞として捉え、2つの名詞を比較するのが最善です。

設計とは、実装済みまたは実装予定の機能のパターンと構成要素を抽象化し、仕様化することです。アーキテクチャは、抽象度が高く、粒度が粗いという点で、設計よりも優れています。結果として、アーキテクチャは、主要なコンポーネントがどこで出会い、どのように相互に関係するかを指定する点で、設計（具体的な詳細と実装）よりもトポロジー的（つまり、全体構造とコンポーネント間の関係）な性質を持っています。アーキテクチャは、主要な機能領域を高レベルのコンポーネントに分割すること、それらが物理的または仮想的にどこに配置されるか、どのような既製コンポーネントを効果的に使用できるか、一般的に各コンポーネントがどのようなインターフェースを公開するか、コンポーネント間でどのようなプロトコルが使用されるか、拡張性、保守性、信頼性、耐久性、スケーラビリティ、およびその他の非機能的な目的を最もよく満たすことができるプラクティスと高レベルのパターンに焦点を当てています。設計は、これらの選択を詳細化し、機能の一部をより粒度の細かいコンポーネントに委任することによって機能要件がどのように満たされるか、そしてこれらの小さなコンポーネントがより大きなコンポーネント内でどのように構成されるかをより具体的に明確化することです。

多くの場合、アーキテクチャの一部はアプリケーション、システム、またはネットワークの構想段階で作成され、要件定義書の非機能要件セクションに記載されることがあります。一般的に、設計は要件定義書に明記されるのではなく、要件定義書に基づいて進められます。

アーキテクチャを定義するプロセスには、アーキテクトまたはアーキテクチャチームがその領域での経験を通じて獲得したヒューリスティックが含まれる場合があります。設計と同様に、アーキテクチャも多くの場合、一連の反復を経て進化します。高レベル設計の妥当性が低レベル設計と実装の段階で検証されるのと同様に、アーキテクチャの妥当性は高レベル設計の仕様策定中に検証されます。どちらの場合も、詳細設計の段階で仕様の妥当性が疑問視された場合は、状況に応じてアーキテクチャまたは設計のいずれかを再度反復する必要が生じる可能性があります。

要約すると、建築とデザインの主な違いは、粒度と抽象度、そして（結果として）時間的な順序にある​​。（一般的に建築はデザインに先行するが、両者の重複や循環的な反復はよくあることである。）

• アーキメイト
• アーキテクチャ分析と設計言語
• C4モデル（ソフトウェア）
• C4インターフロー
• ダーウィン（ADL）
• イースト・アデレード
• ライト（ADL）
• SysADL

• 学術的なアプローチ
  • 建築モデルの分析的評価に焦点を当てる
  • 個々のモデル
  • 厳密なモデリング表記法
  • 強力な分析手法
  • 幅広さよりも深さ
  • 特殊用途ソリューション
• 産業的アプローチ
  • 幅広い開発問題に焦点を当てる
  • モデルのファミリー
  • 厳密さよりも実用性を重視
  • 開発における全体像としての建築
  • 深さよりも幅広さ
  • 汎用ソリューション

• AADL
• ダーウィン
• スクリプト言語
• SysADL
• ハードウェア記述言語

• Medvidovic, N.; Taylor, RN (2000年1月)「ソフトウェアアーキテクチャ記述言語の分類および比較フレームワーク」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 . 
• 建築記述言語// メーラダーレン大学
• Clements, PC (1996). 「アーキテクチャ記述言語の概観」（PDF） .第8回ソフトウェア仕様および設計に関する国際ワークショップ議事録. pp. 16–25 . doi : 10.1109/IWSSD.1996.501143 . ISBN  0-8186-7361-3S2CID 7307554。2013年12月24日にオリジナル（PDF）からアーカイブされました。 
• そろばん
• アクメ
• ADML
• イソップ
• AO-ADL
• ArchiMateエンタープライズアーキテクチャのためのADLの例
• ByADL（Build Your ADL） - ラクイラ大学
• C2 SADL
• DAOP-ADL
• デモエンタープライズアーキテクチャADLの別の例
• DiaSpecは、ソフトウェアアーキテクチャから分散フレームワークを生成するためのアプローチとツールです。
• Malavolta, I.; Muccini, H.; Pelliccione, P.; Tamburri, D. (2010年1月～2月)「モデル変換技術によるアーキテクチャ言語とツールの相互運用性の提供」IEEE Transactions on Software Engineering . 36 (1): 119–140 . Bibcode : 2010ITSEn..36..119M . doi : 10.1109/TSE.2009.51 . S2CID 6825192 . デュアリー
• ラピード
• SSEP
• ユニコン
• ライト