ガイドライン: ソフトウェア・アーキテクチャー説明書
トピック
参照の項では、システムのアーキテクチャーを理解するために重要な背景情報を提供してくれる、外部の文書を示します。大量の参照資料がある場合は、下記のように項目を分けます。
- 外部文書
- 内部文書
- 官公庁文書
- 非官公庁文書
- その他
下記の事項を考慮して、アーキテクチャーを構成します。
- ユース・ケース・モデルにおいて把握された機能要求
- 補足仕様書において把握された機能外要求
ただし、アーキテクチャーの構成には、他の影響要素もあります。ソフトウェア動作環境による制約、既存資産の再利用のための制約、各種標準による制約、既存のシステムとの互換性のための制約などです。
また、既存のアーキテクチャーの原則と方針があって、それに従って開発を進めながらも、プロジェクトのためにそれを検討し改善する必要もあるでしょう。 ソフトウェア・アーキテクチャー説明書のこの項に、それらの目標と制約、そこから派生するが他に収録する適切な場所のないその他のアーキテクチャーに関する決定事項を記述します。
この文書を作成する際に重要な情報は、実装環境の仕様です。定義されなければならないものの例としては、対象となるプラットフォーム (ハードウェア、オペレーティング・システム)、ウィンドウ・システム、画面、開発ツール (言語、GUI ビルダー)、データベース管理システム、コンポーネント・ライブラリーなどがあります。 使用する、または使用しないインターフェース ・テクノロジーを指定することも重要です。 多くのシステムでは、アプリケーションを使用できるクライアント・システムを制限しないよう、またはアプリケーション開発をしやすくするため、特定の表現テクノロジー (JavaScript、アプレット、フレーム、XML、など) を使用しない方法を選んでいます。 ここでの決定事項は、ソフトウェア・アーキテクチャー説明書
それらの決定事項を実施することは、反復評価の一部として使用される一連のアーキテクチャーの評価基準の枠組みを設定することによって達成されます。
評価基準は変更ケースからも得られます。その中に下記のような将来発生する可能性のある変更が記述されています。
- システムの能力とプロパティー
- システムの使用方法
- システムの運用とサポート環境
変更ケースは抽象的な表現で記述されたシステムのプロパティーを明確にするものです。そのような抽象的な表現の例として、「拡張しやすい」、「移植しやすい」、「保守しやすい」、「変更に対して堅牢」、「迅速に開発可能」などが挙げられます。変更ケースでは、単に何が可能かということではなく、何が重要で発生しそうかということに焦点を当てます。
変更ケースでは、将来の変更を予測しようとします。しかし、予測が完全に当たることはほとんどありません。
システムのプロパティーは多くの関係者によって決められます。具体的には、ユーザー、予算承認者、供給業者、開発者、その他の利害関係者がいます。変更が提起される原因はいろいろあります。その例を下に示します。
- ビジネスの動因: 新規または改訂されたビジネス・プロセスと目標
- 技術的動因: 新しいプラットフォームへのシステムの追加、新しいコンポーネントとの統合
- 平均的なユーザーのプロファイルの変化
- 他のシステムとの統合のニーズの変化
- 外部システムからの機能の移行に起因する範囲の変化
この項では、成果物: ユース・ケース・モデルのサブセットとして、アーキテクチャー的に重要なシステムのユース・ケースを提示します。このビューには、重要な中心的な機能を表すシナリオやユース・ケースのセットが示されます。また、(多くのアーキテクチャー要素を含む) 十分なアーキテクチャー範囲を扱うシナリオやユース・ケース、またはアーキテクチャー上の特定の細かい点を強調または表現するシナリオやユース・ケースも示されます。
モデルが大規模な場合、通常はパッケージに編成されています。理解しやすくするために、ユース・ケース・ビューも同様にパッケージごとに編成します。重要な各ユース・ケースに、下記の情報を盛り込んだ項を設けます。
- ユース・ケースの名前
- ユース・ケースの概要説明
- ユース・ケースのイベント・フローの重要な説明。これはイベント・フロー全体の説明であることも、ユース・ケースの重要なフローまたはシナリオを部分的に記述したものでもあり得ます。
- ユース・ケースにかかわる関係の重要な説明。例えば、包含関係、拡張関係、コミュニケーション関連などが挙げられます。
- ユース・ケースに関連する重要なユース・ケース図のリスト
- ユース・ケースの特殊な要求についての重要な説明。それは特殊な要求全体であることも、重要な要求を記述した部分の場合もあります。
- ユース・ケースを明白に示すユーザー・インターフェースの画像
- それらのユース・ケースの実現は論理ビューに記載します。
論理ビューはアーキテクチャー的に重要な設計要素を提示する成果物: 設計モデルのサブセットです。この項では、最も重要なクラス、パッケージとサブシステムにおけるそれらのクラスの構成、それらのパッケージとサブシステムのレイヤーの構成を記述します。
また、アーキテクチャーの動的な様相のような、最も重要なユース・ケースの実現についても、ここに記述します。
複雑なシステムの場合、論理ビューを記述するために、下記のような項を必要とすることがあります。
- 概要
ここでは、パッケージの階層とレイヤーの観点から、設計モデルの全体的な構成を記述します。パッケージが何層か重なったシステムの場合、トップレベルの重要なパッケージについて記述します。トップレベルの重要なパッケージを示すダイアグラムを含めると共に、それらの相互依存関係とレイヤーも含めます。次に、そのパッケージに含まれる重要なパッケージについて、同様に記述します。そのようにして、階層の最下位レベルのパッケージまでカバーします。
- アーキテクチャー上重要な設計パッケージ
重要な各パッケージについて、それぞれ下記の項を設けて、説明を加えます。
- 名前
- 簡単な説明
- パッケージ内の重要なクラスとパッケージをすべて含めたダイアグラム。理解を助けるために、必要があれば、このダイアグラムに他のパッケージのクラスを一部引用してもかまいません。
- パッケージ内の重要な各クラスの名前と簡単な説明を記します。また、各クラスの主要な責任、操作、属性について、説明することがあれば記述します。さらに、ダイアグラムを理解するために、必要があればクラス間の重要な関係を記述します。
- ユース・ケースの実現
ここでは、ソフトウェアの仕組みを説明します。そのために、ユース・ケース (またはシナリオ) をいくつか選択して、その機能にさまざまな設計モデル要素がどのように貢献するかを説明します。ここに示すユース・ケースの実現は、最終的なシステムの中枢的かつ重要な機能を果たすものを選択します。あるいは、広く多くのアーキテクチャー要素をカバーするもの、アーキテクチャーの特定の微妙な点を強調または説明するものを選択します。それらのユース・ケースの実現に対応するユース・ケースとシナリオは、ユース・ケース・ビューに示されているはずです。
各ユース・ケースの実現について、それぞれ下記の項を設けて、説明を加えます。
- 実現されたユース・ケースの名前
- 実現されたユース・ケースの簡単な説明
- ユース・ケースの実現のイベント・フロー - 設計の重要な説明。イベント・フロー - 設計の全体を説明するものでもかまいませんし、ユース・ケースの重要なフローまたはシナリオの実現を部分的に説明するものでもかまいません。
- ユース・ケースの実現に関連する重要な対話図またはクラス図の列挙
- ユース・ケースの実現の派生要件についての重要な説明。それは派生要件全体であることも、重要な要求を記述した部分の場合もあります。
アーキテクチャー上重要な設計要素
アーキテクチャー的に何が重要であるかの決定に役立つように、要素とその特性を評価する例をいくつか示します。
- 問題領域の主要な抽象化をカプセル化するモデル要素
- 航空管制システムの飛行計画
- 給与計算システムにおける従業員
- 電話システムの加入者
これらのサブタイプを、必ずしも含める必要はありません。例えば、国際便の飛行計画と国内便の飛行計画を区別することは重要ではありません。それらは共に飛行計画であり、相当量の属性と操作を共有します。
電話をかけるときの処理がだいたい同じであるならば、データ回線の加入者と音声回線の加入者を区別することは重要ではありません。
- 他の多くのモデル要素によって使用されるモデル要素
- システムの主要な仕組み (サービス) をカプセル化するモデル要素
- 設計の仕組み
- 永続性の仕組み (リポジトリー、データベース、記憶管理)
- 通信の仕組み (RPC、ブロードキャスト、ブローカー・サービス)
- エラー処理または復旧の仕組み
- 表示の仕組みとその他の共通のインターフェース (ウィンドウの表示、データ収集、シグナルの条件付けなど)
- パラメーター化の仕組み
一般に、多くの異なるパッケージで使用される可能性が高く (完全に 1 つのパッケージ内で使用されるのではない)、システム全体を通じて 1 つだけを共通のものとして実装するか、または少なくともいくつかの代替方法の実装を隠すインターフェースを 1 つだけ設定するのが賢明です。
- システム内で下記の事項との主要なインターフェースにかかわるモデル要素
- オペレーティング・システム
- 出来合いの製品 (ウィンドウ・システム、RDBMS、地理情報システム)
- アーキテクチャー・パターンを実装またはサポートするクラス (例えば、モデル要素同士を分離するためのパターンである、モデル・ビュー・コントローラー・パターンやブローカー・パターンなど)
- localized の可視性を持ち、システム全体の性能に大きな影響を与える可能性のある、下記のようなモデル要素
- 非常に高い頻度でセンサーを走査するポーリング・メカニズム
- トラブルシューティングのための追跡メカニズム
- 高可用性システムのためのチェックポイント・メカニズム (チェックポイントとリスタート)
- 起動シーケンス
- コードのオンライン更新
- 奇抜で技術的にリスクのあるアルゴリズム、または安全性やセキュリティーが最重要課題であるアルゴリズムをカプセル化するクラス。その例として、照射レベルの計算、混雑した空域における航空機の衝突回避基準、パスワードの暗号化が挙げられます。
アーキテクチャー的に何が重要かという基準は、プロジェクトの初期の反復期間中に、技術的な困難に遭遇し、システムについての理解が深まるにつれて、固まって行きます。しかし、1 つのルールとして、モデル要素の少なくとも 10% に「アーキテクチャー的に重要」であるとの印を付けるべきです。そうしないと、アーキテクチャーの概念が希薄になり、「すべてがアーキテクチャーである」ということになってしまいます。
アーキテクチャー的に重要なモデル要素を定義して論理ビューに含めるときに、下記の様相についても考慮に入れるべきです。
- 潜在的な共通性と再利用可能性を把握すること。どのクラスが共通クラスのサブクラスまたはパラメーター化されている同じクラスのインスタンスになり得るか。
- パラメーター化できる潜在的な可能性を把握すること。設計のどの部分について、静的パラメーターまたは実行時パラメーターを使用して (テーブルによって起動される振る舞いや起動時にロードされるリソース・データなど)、再利用性または柔軟性を高められるか。
- 市販の製品を使用する潜在的な可能性を把握すること。
この項では、システムのプロセスの構成を記述します。プロセスの構成はアーキテクチャーに大きく影響するので、すべてのプロセスを提示すべきです。プロセス内で提示する必要のあるスレッドは、アーキテクチャー的に重要な軽量のものだけです。プロセス・ビューには、システムの実行にかかわるタスク (プロセスとスレッド)、それらの相互作用と構成の設定、タスクへのオブジェクトとクラスの割り当てを記述します。
プロセスの各ネットワークについて、それぞれ下記の項を設けて、説明を加えます。
- 名前
- 関係するプロセス
- オブジェクトがそれ独自の制御スレッドを取り巻く実際のプロセスとして示されている、コミュニケーション図の形での、プロセス間の相互作用。各プロセスについて、その振る舞い、寿命、通信に関する特性を記述します。
この項では、ソフトウェアが配置されて実行される、1 つ以上の物理的なネットワーク (ハードウェア) の構成について記述します。また、プロセス・ビューからのタスクの物理ノードへの割り当てについても、ここに記述します。各物理ネットワーク構成について、それぞれ下記の項を設けて、説明を加えます。
- 名前
- 構成を示す配置図と各プロセッサーへのプロセスの対応
- 物理構成に多くの可能性がある場合、代表的なものだけを記述して、それから他のものを定義する際に従うべき一般的な対応ルールを説明します。また、ほとんどの場合、ソフトウェアのテストとシミュレーションを行うための、ネットワーク構成についてもここに記述すべきです。
このビューは、成果物: 配置モデルから生成されます。
この項では、実装モデル内でソフトウェアがいくつかのレイヤーと実装サブシステムに分解される様相を記述します。また、(論理ビューから) 実装への設計要素の割り当てについても記述します。ここには下記の 2 つの行も含めます。
- 概要
ここでは、いくつかの事項に名前を付けて定義します。具体的には、種々のレイヤーとその内容、所定のレイヤーに何を含めるかを規定するルール、レイヤー間の境界を取り上げます。レイヤー間の関係を示すコンポーネント図もここで説明します。
- レイヤー
各レイヤーについて、それぞれ下記の項を設けて、説明を加えます。
- 名前
- 実装サブシステムとそのインポート依存関係を示したコンポーネント図
- 該当する場合、論理ビューまたはプロセス・ビューにおけるレイヤーから要素への関係を示します。
- レイヤー内の実装サブシステムの一覧。
それぞれの実装サブシステムにつき、次をあげます。
- 名前、略称または愛称、概略、存在の理由
- 該当する場合、論理ビューまたはプロセス・ビューにおける実装サブシステムから要素への関係を示します。多くの場合、実装サブシステムでは、論理ビューから 1 つ以上の設計サブシステムを実装します。
- 実装サブシステムが、アーキテクチャー上重要な実装サブシステムやディレクトリーを含む場合、
これをサブセクション階層に反映するよう考慮してください。
- 実装サブシステムと実装ディレクトリーが 1 対 1 のマッピングをしない場合、実装ディレクトリーやファイルに関して実装サブシステムがどのように定義されているか説明を加えてください。
この項では、データ・モデル内のアーキテクチャー的に重要な永続的な要素を記述します。データ・ビューでは、システムに永続性を持たせるために使用されるテーブル、ビュー、索引、トリガー、ストアード・プロシージャーの観点から、データ・モデルとその構成の概要を説明します。また、データベースのデータ構造に対する (論理ビューからの) 永続的なクラスの対応づけも、ここに記述します。
通常は下記の事項を含めます。
- 永続的な主要な設計クラスからの、特に重要なものの対応づけ
- データベース内にストアード・プロシージャーとトリガーの形で実装されている、アーキテクチャーに重要なシステムの部分
- データの扱いに影響を与える、他のビューにおける重要な決定事項。トランザクション戦略、分散、並行性、フォールト・トレランスに関する選択がそれに該当します。
例えば、データベースに基づくトランザクション管理を行う (トランザクションの確定と異常終了の処理をデータベースにゆだねる) という選択をすると、そのアーキテクチャー内で使用するエラー処理の仕組みにリカバリー戦略を組み込む必要があります。つまり、アプリケーション内のメモリー中にキャッシュ化されている永続的なオブジェクトの状態をリフレッシュすることによって、エラーを起こしたトランザクションを復旧できるような仕組みが必要となります。
アーキテクチャー的に重要なデータ・モデル要素を提示し、それらの責任を説明し、(トリガーやストアード・プロシージャーなどの) 非常に重要な関係と振る舞いをいくつか提示すべきです。
この項では、アーキテクチャーの定義にかかわる、システムの計測と応答に関する特性を記述します。下記の事項を含みます。
- システムで処理する必要のある主要な要素の数 (航空管制システムにおける同時に発着する便の数、電話交換機における同時にかかってくる電話の数、座席予約システムにおける同時にオンラインでアクセスするユーザーの数など)
- システムの主要な性能値 (主要なイベントの平均応答時間、スループットの平均値、最大値、最小値など)
- 実行可能ファイルの容量 (ディスクとメモリーの観点から) - きわめて限定的な制約のもとで稼働する組み込みシステムの場合に特に重要です。
ここにそれらを掲げた理由は、それらはアーキテクチャーに重要な影響を与えるので、特に焦点を当てる必要があるからです。各要求について、アーキテクチャーでどのようにサポートするかを検討します。
この項では、アーキテクチャーを構成するシステムの主要な品質特性を列挙します。下記の事項を含みます。
- 運用上の性能要求。例えば平均故障待ち時間 (MTBF)。
- 品質目標。例えば「予定外のダウンタイムなし」。
- 拡張性の目標。例えば「システムが稼働中にソフトウェアのアップグレードが可能」。
- 移植性の目標。ハードウェア・プラットフォーム、オペレーティング・システム、言語について。
各特性について、アーキテクチャーでどのようにサポートするかを検討します。
この項を種々のビュー (論理ビュー、実装ビューなど) または品質の観点から構成できます。例えば、安全性、セキュリティー、あるいはプライバシーのような特定の特性がシステムにおいて重要である場合、それらをアーキテクチャー的にどうサポートするかを、この項で詳細に記述します。アーキテクトは、セキュリティー設計アプローチの概要によって生成された情報を把握するために、この項を使用できます。
|