トップQs
タイムライン
チャット
視点

アーキテクチャ記述言語

ウィキペディアから

Remove ads

アーキテクチャ記述言語（Architecture Description Language、ADL）とは、ソフトウェアアーキテクチャやシステムアーキテクチャを記述するためのコンピュータ言語または概念モデルである。ソフトウェア開発者がアーキテクチャについてやり取りする場合や、開発者と発注元との認識あわせに使う。またエンタープライズモデリングでも使われる[1]。

ソフトウェア工学分野では、Acme（CMUが開発）、AADL（SAEが標準化）、C2（UCIが開発）、Darwin（インペリアル・カレッジ・ロンドンが開発）、Wright（CMUが開発）などがある。

ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description)[2]では、アーキテクチャ記述言語を「アーキテクチャ記述で使用される任意の表現形式」と定義し、ADLに最低限要求されることを示している。

事業体モデリングの分野では企業レベルのアーキテクチャ記述言語が開発されている。例えば、ArchiMate（The Open Group）、DEMO、ABACUS（シドニー工科大学が開発）などがある。これらは必ずしもソフトウェアコンポーネントなどを記述しないが、アプリケーションのアーキテクチャをソフトウェア技術者に伝えるのに使われる。

以下では主にソフトウェア工学でのADLについて解説している。

Remove ads

概要

アーキテクチャを記述するための標準的記法(ADL)があれば、開発者間の対話、初期段階の決定の具体化などで作業がスムーズに進行する。また、ADLで書いたものを遠隔地とやり取りすることもできる。

従来、アーキテクチャと言えば、単に四角形を線で繋いだような図を指していた。そのような図で、コンポーネントの役割/特徴、コンポーネント間の関係、システム全体の振る舞いなどが定義されていた。ADL はアーキテクチャを形式的に表現する言語的手法であり、従来の手法の欠点を補う。また、洗練されたADLはアーキテクチャにおける設計上の決定の早期分析と実現可能性の評価を考慮している点も重要である。

歴史

ADLは大まかに3つに分類される。箱と線で描く図、形式的な言語、UMLベースの記法の3種類である。システムアーキテクチャの記述にはかつては「箱と線」が主に使われていた。これは非形式的であるため、アーキテクチャの説明としての有効性は限定的だった。そのため、より厳密なアーキテクチャの記述法が必要とされた[3]。仕様書は単に明確で正確な文書というだけでなく、自動的分析が可能で潜在する問題を検出できるものが求められていた[4]。

その後システムアーキテクチャ記述のための形式言語の研究が続けられてきた。様々な概念要素、文法、意味論を持つADLがいくつも提案されてきており、特定分野のみを得意とするものや特定の分析手法のみに対応したものなどもあった。ドメイン固有ADLの例としては、組み込みシステムやリアルタイムシステム向け（AADL[5]、EAST-ADL[6]、EADL[7]）、制御ループ向け（DiaSpec[8]）、製造ライン向け（Koala[9]）、動的システム向け（Π-ADL[9]）などがある。可用性、信頼性、セキュリティ、リソース消費、データ品質、リアルタイム性能分析（AADL、Fractal[10]）、信頼性分析（TADL[11]）などを考慮した分析指向のADLも提案されている。

しかし、これらの成果は産業界ではほとんど採用されていない。なぜADLが普及しないのかについて、Woods and Hilliard[12]、Pandey[13]、Clements[14] らが分析を行っている。形式的ADLはソフトウェア開発に滅多に採用されておらず、主要なツールでもサポートされていない。ADLは一般に解説書が少なく、特定分野に特化しており、新機能を追加する余地がない。

そういった既存のADLの限界を打破する代替手法としてUMLが有力となっている。UMLを使用または拡張してソフトウェアアーキテクチャをモデリングする方法が多数提案されている[15][16]。

実際最近の研究によると[17]、ソフトウェア開発者は使用するADLの設計面の機能については満足しているが、分析面の機能や機能以外の特性を定義する能力については不満を持っている。実際の場で使われているのは研究から生まれたものより実践の場で生まれたものが多い。

Remove ads

特徴

要約
視点

学術界や産業界で様々なADLが開発されている。その多くは単にADLであるだけでなく、アーキテクチャの表現や分析にも対応している。ADLはソリューション（解法）を記述するための言語であり、問題を記述するための要求仕様記述言語ではない。また、ADLは抽象化されたアーキテクチャを特定の解法に結び付けるものではないため、プログラミング言語ではない。ADLはコンポーネントを表現するものであり、全体の振る舞いを記述するモデリング言語とも異なる。ただし、ドメイン固有モデリング (DSM) の言語はコンポーネントを表現することに集中している。

ADLの最低限備えるべき特徴は以下の通りである:

  • あるシステムの関係者全員がそのアーキテクチャについてやり取りするのに適していること。
  • アーキテクチャ作成/修正/検証に必要な機能を備えていること。
  • その後の実装に必要な情報が提供できること。すなわち、設計段階でADLの記述に追記していき、最終的なシステム仕様が記述できる。
  • 一般的なアーキテクチャのスタイルを表現できること。
  • 分析的機能を備えるか、プロトタイプ実装を簡単に生成できること。

ADLは一般に形式的に定義された文法と意味を備えたグラフィカルな構文にテキストを埋め込むようになっている。また、分散システムをモデル化する機能を備え、設計情報を扱うことはほとんどないが、汎用の注釈を埋め込む機能を備えている。また詳細さの階層構造を表現できる。また、アーキテクチャレベルでデッドラインやタスクの優先度といったリアルタイム性に関する記述ができるものもある。また、オブジェクト指向設計的なスタイル（継承など）をサポートするものもある。1つのアーキテクチャ記述から製品ラインの定義に従って複数の実体化をサポートしたものもある。

長所と短所

長所

  • アーキテクチャを形式的に表現できる。
  • 人間もマシンも読むことができる。
  • 従来の手法よりも高い抽象レベルでシステムを記述できる。
  • アーキテクチャを分析できる（完全性、一貫性、あいまい性、性能）。
  • ソフトウェアの自動生成に対応できる。

短所

  • UMLのような汎用的なもの以外に国際的な標準規格がない。
  • 現状のADLの構文解析は複雑であり、商用ツールで対応していない。
  • 今のところ研究レベルに留まっており、商業的に広く使われるには至っていない。
  • 特定の分析に特化して最適化しているものがほとんどである。

ADL におけるアーキテクチャという概念

ADLにおいては、ソフトウェアアーキテクチャとはコンポーネント群とそれらの関連を指すのが一般的である。しかし、アーキテクチャには以下のような見方もある。

「オブジェクト連携アーキテクチャ」は、オブジェクト指向システムのインタフェースと連携から構成される。インタフェースとは、モジュール群が提供する機能を意味し、連携とはインタフェース間の呼び出し関係を指す。そこにさらにプログラミング言語への適合などが付随する。

「インタフェース連携アーキテクチャ」は、インタフェースと連携の役割を拡張したものである。インタフェースとしてはコンポーネントが必要とする（他コンポーネントの）インタフェースとそのコンポーネントが（他コンポーネントに）提供するインターフェイスを記述する。連携はその両方のインタフェースの間で成立する関係である。そこにさらに各種制限が付与される。

多くのADLは後者（インタフェース連携アーキテクチャ）を実装している。

アーキテクチャと設計

アーキテクチャと設計という用語の違いは何か？ アーキテクチャは、機能以外の決定と機能的要求仕様の区分に関わり、設計は機能要求仕様を具体化する作業全体を指す。アーキテクチャ上のヒューリスティックはもう一段階下のレベルで行う必要があるため、アーキテクトは区分を有効にするために概要レベルの設計にも関わらなければならない。

具体例

アーキテクチャ手法

  • 学術的手法
    • アーキテクチャモデルの解析評価が中心
    • 個別にモデル化
    • 厳密なモデル記述
    • 強力な解析技法
    • 幅よりも深さ優先
    • 問題毎の解法
  • 産業的手法
    • 開発上の各種問題の解決が中心
    • モデルのファミリ化
    • 厳密さよりも実用性
    • 開発する上での大雑把な図面としてのアーキテクチャ
    • 深さよりも幅優先
    • 汎用的解法

脚注

関連項目

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads