Loading article…
ソフトウェア アーキテクチャ記述は、ソフトウェア アーキテクチャを表現、伝達、分析するための一連のプラクティス(アーキテクチャ レンダリングとも呼ばれます) であり、ソフトウェア アーキテクチャを表現する作業成果物を通じてそのようなプラクティスを適用した結果です ( ISO/IEC/IEEE 42010 )。
アーキテクチャ記述（AD）は、アーキテクチャ表現、アーキテクチャ仕様[1] 、または ソフトウェアアーキテクチャドキュメントと呼ばれることもあります。
コンセプト
アーキテクチャ記述は、ソフトウェア アーキテクトがソフトウェア アーキテクチャを記録するために使用するプラクティス、テクニック、および表現の種類を定義します。アーキテクチャ記述は主にモデリング アクティビティです (ソフトウェア アーキテクチャ モデル)。アーキテクチャ モデルは、テキスト、非公式の描画、図、その他の形式 (モデリング言語) など、さまざまな形式を取ることができます。アーキテクチャ記述では、多くの場合、さまざまな対象者、利害関係者(エンド ユーザー、システム所有者、ソフトウェア開発者、システム エンジニア、プログラム マネージャーなど)、およびさまざまなアーキテクチャ上の懸念事項(機能性、安全性、配信、信頼性、スケーラビリティなど)に効果的に対処するため、複数の異なるモデル タイプが使用されます。
多くの場合、アーキテクチャ記述のモデルは、アーキテクチャの複数のビューに編成され、「各ビューは、システムのさまざまな利害関係者の関心事である特定の懸念事項に対応します」。 [2] アーキテクチャのビューポイントは、システムを見る方法です ( RM ODP )。アーキテクチャ記述の各ビューには、対応する懸念事項と利害関係者、および使用するモデルの種類、表記法、モデリング規則を文書化したビューポイントが必要です ( ISO/IEC/IEEE 42010 )。
複数のビューの使用は、多様な利害関係者とのコミュニケーションや多様な懸念事項の記録・分析には効果的ですが、潜在的な問題も生じます。ビューは通常独立していないため、重複する可能性があり、単一システムのビュー間に冗長性や不整合が生じる可能性があります。[3]さまざまなメカニズムを使用して、ビュー間の対応関係を定義および管理し、詳細を共有し、冗長性を減らし、一貫性を強化する ことができます。
アーキテクチャの説明に関するよくある誤解は、AD は「技術的な問題」のみを議論するものですが、AD は多くの利害関係者に関係する問題に対処する必要があります。一部の問題は技術的ですが、多くの問題はそうではありません。AD は、建築家、そのクライアント、その他の人々がコスト、スケジュール、およびプロセスを管理できるようにするために使用します。関連する誤解は、AD はシステムの構造的側面のみに対処するというものです。しかし、これでは利害関係者が満足することはめったにありません。利害関係者の懸念には、構造、動作、美観、およびその他の「機能外」の懸念が含まれることが多いからです。
歴史
最も初期のアーキテクチャ記述では、非公式な画像や図表、および関連するテキストが使用されていました。非公式な記述は、現在でも業界で最も広く使用されている表現です。[4]アーキテクチャ記述に影響を与えたのは、ソフトウェアエンジニアリングの分野（データ抽象化や大規模プログラミングなど）とシステム設計（SARA [5] など）です。
モジュール相互接続言語 (MIL) などの大規模プログラミングに関する研究は、ソフトウェアの大規模な特性の表現に重点を置きました。[6]モジュール (プログラム、ライブラリ、サブルーチン、サブシステムを含む) とモジュール関係 (モジュール間の依存関係と相互接続)。この研究は、プログラミング言語に関するアーキテクチャ的考え方 (Ada など)、設計およびアーキテクチャ表記法 (Buhr 図やユース ケース マップなど、UML のアーキテクチャ的特徴で体系化されたパッケージ、サブシステム、依存関係)、およびアーキテクチャ記述言語に関する研究の多くに影響を与えました。MIL に加えて、ソフトウェア エンジニアリング内の要件と設計の領域における成熟した研究の影響を受けて、さまざまな種類のモデルがソフトウェア エンジニアリングと設計から「持ち出され」、アーキテクチャの記述に適用されました。これには、構造化分析 ( SADT)の機能モデルとアクティビティ モデル、データ モデリング手法 (エンティティ関係)、およびオブジェクト指向手法が含まれます。
ペリーとウルフ[1]は、複数の視点の役割について建築の先例を引用しました。「建築建築家は、建物の特定の側面を強調したさまざまな視点を使用して顧客と協力します。」
ペリーとウルフは、アーキテクチャの表現には、 {要素、形式、根拠}が含まれるべきであり、3種類の要素（したがって3種類のビュー）を区別すると主張しました。
- 処理: データがどのように変換されるか。
- データ: 使用および変換される情報。
- 接続: 他の要素を一緒に保持する接着剤。
Perry 氏と Wolf 氏は、アーキテクチャ記述 (論文では「アーキテクチャ仕様」と呼ばれています) の 4 つの目的または用途を特定しました。
- 解決策を過剰に指定せずにアーキテクチャ上の制約を規定する
- 美学と工学を分離する
- 建築のさまざまな側面をそれぞれ適切な方法で表現する
- アーキテクチャ分析、特に依存性と一貫性の分析を実施する
Perry と Wolf の論文に続いて、ソフトウェア アーキテクチャの記述に関する 2 つの考え方が生まれました[引用が必要] :
- 多角的な視点の学校
- 構造主義学派
アーキテクチャ記述のメカニズム
アーキテクチャの記述には、いくつかの一般的なメカニズムが使用されます。これらのメカニズムにより、成功した記述スタイルの再利用が容易になり、多くのシステムに適用できるようになります。
- 建築の視点
- アーキテクチャ記述言語
- アーキテクチャフレームワーク
建築の視点
ソフトウェア アーキテクチャの記述は、一般的にビューにまとめられます。これは、建築物の建築で作成されるさまざまな種類の設計図に似ています。各ビューは、そのビューポイントの規則に従って、一連のシステムの問題に対処します。ビューポイントとは、特定の利害関係者の視点とその問題 ( ISO/IEC 42010 ) から問題のアーキテクチャを表現するためにビュー内で使用される表記法やモデリング手法を記述した仕様です。ビューポイントは、フレーム化された (つまり、対処される) 問題だけでなく、プレゼンテーション、使用されるモデルの種類、使用される規則、およびビューと他のビューの一貫性を保つための一貫性 (対応) ルールも指定します。
視点の例としては次のようなものがあります。
- 機能的観点
- 論理的視点
- 情報/データの観点
- モジュールの視点
- コンポーネントとコネクタの観点
- 要件の観点
- 開発者/実装の観点
- 並行性/プロセス/ランタイム/スレッド/実行の観点
- パフォーマンスの観点
- セキュリティの観点
- 物理/展開/インストールの観点
- ユーザーの行動/フィードバックの観点
ビュータイプという用語は、共通の要素と関係のセットを共有する類似のビューのカテゴリを指すために使用されます。[4]
アーキテクチャ記述言語
アーキテクチャ記述言語( ADL ) は、ソフトウェア アーキテクチャ ( ISO/IEC/IEEE 42010 ) を記述するために使用される表現手段です。1990 年代以降、AADL (SAE 標準)、Wright (カーネギー メロン大学が開発)、Acme (カーネギー メロン大学が開発)、xADL (UCI が開発)、Darwin (インペリアル カレッジ ロンドンが開発)、DAOP-ADL (マラガ大学が開発)、ByADL (イタリアのラクイラ大学) など、多くの専用 ADL が開発されました。初期の ADL では、コンポーネント、コネクタ、構成の観点からシステムをモデリングすることに重点が置かれていました。最近の ADL (ArchiMate や SysML など) は、コンポーネントとコネクタだけでなく、複数のサブ言語を通じてさまざまな懸念事項を表現できる「広範囲」の言語になる傾向があります。特殊用途の言語に加えて、UMLなどの既存の言語も、「ソフトウェア ベースのシステムの分析、設計、実装、およびビジネスや同様のプロセスのモデリング」のためのADL として使用できます。
アーキテクチャフレームワーク
アーキテクチャフレームワークは、「特定のアプリケーション ドメインおよび/または利害関係者のコミュニティ内で確立されたアーキテクチャの記述に関する規約、原則、および実践」( ISO/IEC/IEEE 42010 ) をキャプチャします。フレームワークは通常、1 つ以上のビューポイントまたは ADL の観点から実装されます。ソフトウェア アーキテクチャで重要なフレームワークには次のものがあります。
複数のビュー
1995年に発表されたクルヒテンの非常に影響力のある論文「4+1ビューモデル」に代表されるこのアプローチは、モデル化されるさまざまな利害関係者と懸念事項を強調しました。[2]
構造主義
第二に、CMUやその他の研究に反映されているように、アーキテクチャは実行時のシステムの高レベルな組織であり、アーキテクチャはコンポーネントとコネクタの観点から記述されるべきであるという考え方があります。「ソフトウェアシステムのアーキテクチャは、計算コンポーネントとそれらのコンポーネント間の相互作用の観点からそのシステムを定義します。」[7]
1990年代から2000年代にかけて、ADLに関する学術研究の多くは、コンポーネントとコネクタのパラダイム内で行われました。しかし、これらのADLは産業界にほとんど影響を与えませんでした。[8] 1990年代以降、アーキテクチャ記述へのアプローチは収束し、 2000年にはIEEE 1471でベストプラクティスが体系化されました。ADにおける複数の視点をサポートするが、必須ではないというものです。
決定によるアーキテクチャの説明
ペリーとウルフの元の公式の理論的側面を詳しく説明すると、ソフトウェアアーキテクチャを構想し表現するための重要な方法として、決定と決定の理由を文書化するという3番目の考え方が生まれました。[9] このアプローチでは、決定をアーキテクチャ記述の第一級要素として扱い、以前の表現では暗黙的であったものを明示的にします。
アーキテクチャ記述の用途
アーキテクチャ記述は、( ISO/IEC/IEEE 42010 ) など、さまざまな目的に使用されます。
- システム構築と保守をガイドする
- システムの計画、コスト計算、進化を支援する
- アーキテクチャの分析、評価、比較の媒体として機能する
- アーキテクチャとシステムに関するシステム関係者間のコミュニケーションを促進する
- 個々のプロジェクトの範囲を超えたアーキテクチャの知識（ソフトウェア製品ラインや製品ファミリ、リファレンスアーキテクチャなど）を文書化する
- 再利用可能な建築用語（建築様式やパターンなど）をキャプチャする
参考文献
- ^ ab Perry, DE; Wolf, AL (1992). 「ソフトウェアアーキテクチャの研究の基礎」 ACM SIGSOFT ソフトウェアエンジニアリングノート 17 (4): 40. doi:10.1145/141874.141884
- ^ ab PB Kruchten、「アーキテクチャの「4+1」ビューモデル」、IEEE Software、vol. 12、no. 6、pp. 42–50、1995年11月
- ^ A. Finkelstein、J. Kramer、B. Nuseibeh、L. Finkelstein、および M. Goedicke。Viewpoints: システム開発における複数の視点を統合するためのフレームワーク。International Journal of Software Engineering and Knowledge Engineering、2(1):31-58、1992 年。
- ^ ab PC Clements、F. Bachmann、L. Bass、D. Garlan、J. Ivers、R. Little、R. Nord、および J. Stafford、「Documenting Software Architectures: views and beyond」。Addison Wesley、2003 年。
- ^ G. Estrin、RS Fenchel、RR Razouk、MK Vernon、「システムAR建築家の見習い」、IEEE Transactions of Software Engineering、1986 年。
- ^ F. DeRemer および HH Kron、「大規模プログラミングと小規模プログラミング」、IEEE Transactions on Software Engineering、1976 年。
- ^ M. Shaw および D. Garlan、「ソフトウェアアーキテクチャ: 新興分野の展望」、Prentice Hall、1996 年。
- ^ E. Woods および R. Hilliard、「アーキテクチャ記述言語の実践」 http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
- ^ A. Jansen および J. Bosch、「一連のアーキテクチャ設計決定としてのソフトウェア アーキテクチャ」、第 5 回 IEEE/IFIP ソフトウェア アーキテクチャ カンファレンスの議事録、2005 年。