アーキテクチャ モデル （ ソフトウェア ）には、設計対象のソフトウェアの静的特性または動的（動作）特性を表す複数の図が含まれています。 [1] [2] [3] これらの図は、適切な分析範囲におけるシステムのさまざまな 視点 を表します。これらの図は、利用可能な標準規格に基づいて作成され、その主な目的は、システムまたはエコシステムの構造と設計に固有の特定のトレードオフを示すことです。 ソフトウェアアーキテクトは 、コミュニケーションを促進し、同僚からのフィードバックを得るためにアーキテクチャモデルを活用します。
ソフトウェア アーキテクチャ モデルの主要な要素は次のとおりです。
リッチ ：問題となっている視点については、その地域を詳細に説明できるだけの十分な情報が必要です。情報が不足していたり、曖昧であったりしてはいけません。誤解を最小限に抑えることが目的であり、誤解を永続させることが目的ではありません。「主な懸念事項」については、下記の注記を参照してください。 厳密性 ：建築家は特定の方法論を用いてこの特定のモデルを作成し、その結果得られたモデルは特定の「外観」を呈します。厳密性のテストでは、異なる都市に住む2人の建築家が同じものを表現した場合、結果として得られる図面は（視覚的なレイアウトをある程度例外として）ほぼ同一になるであろうと述べられます。 ダイアグラム ：一般的に、モデルとは、特定の観点に対応するために何かを単純化した抽象化を指します。この定義では、「アーキテクチャモデル」を、ダイアグラムとして表現されるモデル記述のサブセットに具体的に分類し ます 。 標準 ：標準は、誰もがそれを知り、誰もがそれを使用することで機能します。これにより、各図が互いに大きく異なる場合には実現できないレベルのコミュニケーションが可能になります。 統一モデリング言語 （UML）は、最も頻繁に引用される標準です。 主な懸念事項 ：単一の図面に多くの異なるニーズを盛り込むと、詳細になりすぎてしまうことがよくあります。これは避けるべきです。非常に詳細な「メガダイアグラム」を描くよりも、視点ごとに1つずつ、複数の図面を描く方が適切です。覚えておいてください。家を建てる際、建築家は多くの異なる図面を提出します。それぞれは異なる用途で使用されます。最終的な設計図には、間取り図に加えて、骨組み図、電気図、暖房図、配管図などの図面が何度も含まれていることがよくあります。これらの図面は、必要な情報のみを提供することを保証します。例えば、配管工事の 下請け業者は 、電気技師が知っておく必要があるような詳細情報を必要としません。 図解 ：モデル作成の目的は、コミュニケーションを取り、貴重なフィードバックを得ることです。図解の目的は、特定の質問に答え、その答えを他の人と共有することです。
彼らが同意するかどうか確認する 彼らの仕事を指導します。 経験則: 何を言いたいのか、そしてそれによって誰の作品に影響を与えたいのかを分かってください。 具体的なトレードオフのセット ： アーキテクチャトレードオフ分析法（ATAM）は、 ソフトウェアアーキテクチャの適切性を ピアレビューする プロセス を表します 。ATAMは、「あらゆる状況に適した設計など存在しない」という基本的な概念から始まります。汎用的な設計を作成することはできますが、ビジネス要件に基づいて特定の状況に合わせて変更する必要があります。つまり、人はトレードオフを行っているのです。ダイアグラムは、これらの具体的なトレードオフを可視化する必要があります。したがって、アーキテクトはダイアグラムを作成する前に、このモデルでどのようなトレードオフを示そうとしているのかを言葉で説明できるように準備しておく必要があります。 構造と設計に内在するトレードオフ ：コンポーネント自体がトレードオフであるわけではありません。トレードオフが図表上のイメージとして表現されることはほとんどありません。トレードオフは設計モデルを生み出す基本原則です。アーキテクトが特定のトレードオフを説明したり、その立場を擁護したりしたい場合、図表はその立場を擁護するために使用できます。 システムまたはエコシステム ：モデリングは一般的に、様々な抽象化レベルで行うことができます。特定のアプリケーションのアーキテクチャを、コンポーネントとインタラクションを含めてモデル化することは有用です。また、完全なビジネスプロセス（受注から入金までなど）を提供するために必要なアプリケーションのシステムをモデル化することも合理的です。しかし、単一のコンポーネントとそのクラスのモデルをソフトウェアアーキテクチャと見なすことは、一般的に有用ではありません。このレベルでは、モデルはそれ自体に価値がありますが、アーキテクチャよりも設計をより明確に示します。
参照
参考文献
^ Hasselbring, Wilhelm (2018)、 「ソフトウェアアーキテクチャ：過去、現在、未来」 、 The Essence of Software Engineering 、Cham: Springer International Publishing、pp. 169– 184、 doi :10.1007/978-3-319-73897-0_10、 ISBN 978-3-319-73896-3 、 2025年2月10日取得 ^ 「統一モデリング言語仕様バージョン2.5.1について」 www.omg.org . 2025年2月10日 閲覧 。 ^ Hilliard, Rich; Malavolta, Ivano; Muccini, Henry; Pelliccione, Patrizio (2012年8月). 「アーキテクチャフレームワークを横断するビューポイントの構成と再利用について」. 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture . IEEE. pp. 131– 140. doi :10.1109/wicsa-ecsa.212.21. ISBN 978-1-4673-2809-8 。
外部リンク SEI が発行した「ソフトウェア アーキテクチャ定義」には、古典および現代の著者が使用するアーキテクチャの定義のリストが含まれています。 アーキテクチャ モデルには、オタワ大学のオブジェクト指向ソフトウェア エンジニアリング データベースからのアーキテクチャ モデルの定義が含まれています。 アーキテクチャトレードオフ分析法 (ATAM) は、アーキテクチャの適合性と要件への適合性を評価する方法です。 
