作業:
|
目的
|
|
手順 | |
入力とする成果物: | 結果となる成果物: |
頻度: オプションとして方向づけにおいて発生します。最初の推敲反復で発生しなければなりません。ソフトウェア アーキテクチャに対する大幅な変更または追加について調査が必要な場合は、後の反復で発生することがあります。 |
|
役割: ソフトウェア アーキテクト | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
アーキテクチャ分析では、候補アーキテクチャの定義と、システムで使用するアーキテクチャ技術を制限することに焦点を当てます。アーキテクチャの再発見のために無駄な努力をしないように、アーキテクチャに制限をつけて絞り込むには、類似のシステムまたは類似の問題領域で得られた経験を収集することが重要です。既にしっかりと定義されたアーキテクチャがあるシステムでは、アーキテクチャ分析を省略できる場合があります。アーキテクチャ分析は、主に前例のない新しいシステムを開発するときに役立ちます。
目的 | 高レベルなアーキテクチャ オプションを探求および評価して、システムの開発構想を容易にする
スポンサー、開発チームおよびそのほかの利害関係者に、想定システムの高レベルな構造の初期における考え方を伝達する |
アーキテクチャの概要は、プロジェクトのライフサイクルの初期に、方向づけフェーズと同じくらい早く作成します。この概要には、物理的アーキテクチャ、論理的アーキテクチャおよびシステムの機能外要求だけでなく、開発構想書を実装する上での初期決定や基礎的な仮定を反映させます。アーキテクチャの概要は、ソフトウェア アーキテクトが、多くの場合プロジェクトのスポンサーと共同で作成するものであり、形式は略式で、図が中心の絵コンテ的なもの、あるいはアイコンを使用したグラフなどになります。基本的にアーキテクチャの概要では、提案するソリューションの本質的な概念を示し、全体的な考えを伝え、主な構成要素を示します。アーキテクチャの概要の正式さのレベルは、プロジェクトによって異なります。たとえば、大規模で形式にこだわるプロジェクトでは、正式にレビューできるように、アーキテクチャの概要をソフトウェア アーキテクチャ説明書の適切な項に記載する必要があります。
この時点では、アーキテクチャの概要は暫定的なものにすぎません。実行可能なアーキテクチャ プロトタイプが設計、実装、導入の懸念事項を実証するまで、アーキテクチャ概要図に依存しないでください。
この概要書で示すアーキテクチャは、参照アーキテクチャ、他のアーキテクチャ パターン、または他のアーキテクチャ資産を基に検討します。
アーキテクチャ概要図をコミュニケーション手段として機能するように改良および保守するかどうかを検討します。
システムの開発および導入では、既存のハードウェアやソフトウェアの環境によって制約を受けることが多くあります。このような場合には、ソフトウェア アーキテクトが現状の環境に関する情報を集めます。
たとえば、e-ビジネスのシステム開発では、次のような情報を収集します。
こうした情報はテキストまたは配置モデルから得ることができます。
目的 |
プロジェクトに適切と思われる資産を識別する 資産とプロジェクトによる要求との一致点や相違を分析する システムの各部分を資産ベースで構成するかどうかを判断する プロジェクトで再利用可能な資産を調べてリストを作成する 必要なサポートを受けられることを確認するために、予備評価を行う |
資産を検討する環境の要件、およびシステムの範囲と必要な一般機能を理解する必要があります。また、組織の資産ベースや業界の文献を調べて、資産や類似するプロジェクトを明確にします。検討すべき資産としては、産業モデル、フレームワーク、クラス、経験などがありますが、これらに限定されるわけではありません。利用可能な資産が現在のプロジェクトの主な問題を解決するために貢献可能なものか、また、ほかの制限と矛盾するものではないかを評価する必要があります。
資産と顧客要求との合致の度合いについて、要求が交渉可能かどうか (資産を利用するため) を考慮して分析するとよいでしょう。
資産を修正または拡張して要求を満たせるかどうか、資産の採用により、コスト、リスク、機能性の点でどのようなトレードオフがあるかを評価しなければなりません。
最後に、1 つ以上の資産を使うかどうかをおおむね決定し、決定の論理的根拠を文書に残しておくとよいでしょう。
目的 | 設計モデルの初期構造を作成する |
方向づけ時のアーキテクチャ統合の実施に焦点が置かれている場合、この手順はこの作業から除外されます。
通常、設計モデルは、中規模システムから大規模システム向けの共通のアーキテクチャ パターンでは、レイヤ状に構成されます。レイヤ数は固定ではなく、状況ごとに異なります。
アーキテクチャの分析中は、通常上位 2 レイヤに焦点を当てます。つまり、アプリケーション レイヤとビジネス固有レイヤです。サブシステムの高レベルの編成とは、この 2 つのレイヤを指します。そのほかの低位レイヤは「作業: 既存の設計要素の組み込み」で考慮します。特定のアーキテクチャ パターンを使用する場合、サブシステムはそのパターンのアーキテクチャ テンプレートに基づいて定義されます。
レイヤリングの詳細については、「ガイドライン: レイヤリング」を参照してください。
目的 | システムで処理しなければならない中心となる抽象概念 (と要求作業で識別した概念の表現) を識別して、分析の準備を行う |
アーキテクチャ統合の実施に焦点が置かれている場合、この手順は、「成果物: アーキテクチャ上の概念の証明」を作成するために資産選択できるようにソフトウェア アーキテクトを援助し、代表的な使用法のシナリオをサポートするために必要な程度まで実行されます。
通常、要求との作業では、システムで処理しなければならない中心となる概念を明らかにします。これらの概念は、設計の中心となる抽象概念そのものを宣言するものです。識別の作業は既に完了しているため、「成果物: ユース ケース分析」の間に再度繰り返す必要はありません。
既に得た知識を活用するため、システムに関する一般的知識 (要求、用語集および特に領域モデル) をベースにして、これらの中心となる抽象概念を表す予備的なエンティティ分析クラスを識別します。
中心となる抽象概念を定義するとき、エンティティ クラス間のリレーションも定義します。1 つまたは複数のクラス図で中心となる抽象概念を表現し、それぞれを簡単に説明します。領域とシステムの新規性によっては、システムのモデル化に必要な、中心となる抽象概念の多くを表現できる分析パターンが既に存在する場合もあります。領域内で既に採用されているこのようなパターンを利用することで、表現する重要な概念を識別するという知的負担は大いに削減されます。[FOW97a] では、ビジネス システムのモデル化にすぐに役立つ分析パターンをいくつか提示していますが、これらのパターンは他の状況でも適用できます。もう 1 つの例としてはオブジェクト マネジメント グループ (OMG) があり、独自のドメイン技術委員会と関連する部会での作業を通じて、多くの領域におけるインターフェイスやプロトコルの定義を試みています。この作業は、必然的に領域の重要な抽象概念の識別につながるものです。
この時点で、明確な分析クラスは、プロジェクトが進行するにつれて、変化または進化していくでしょう。このステップの目的は、設計を通じて生き残るクラス セットを識別することではなく、システムが処理する必要のある、中心となる概念を識別することです。この初期段階では、エンティティ クラスを詳細に記述するために時間をかけることはありません。ユース ケースでは、実際に必要のないクラスやリレーションを識別してしまうリスクがあるからです。ユース ケースを検討する時点で、さらに多くのエンティティ クラスやリレーションが見つかることもあるということを覚えておいてください。
このステップは、方向づけの間に、「ワークフローの詳細: アーキテクチャ統合の実施」の一部としてアーキテクチャ分析 (本作業) を実行した場合にのみ含まれます。
このステップの目的は、システム内のかなりの種類の作業を特徴付ける、または表現する、システムの主要な抽象概念間の相互作用を識別することです。この相互作用は、ユース ケースの実現として把握されます。
目的 |
システム実装の実現性を評価するベースを提供する システムの地理的分散と運用の複雑性を理解する 初期における作業とコストの見積もりに対しベースを提供する |
ソフトウェアが導入されるしくみに関する高レベルの概要を作成します。たとえば、システムにリモートからアクセスする必要があるか、複数ノードにまたがった分散を暗示する要求があるか、といった内容を定めます。考慮するべき情報源には以下のようなものがあります。
大規模な分散システムが必要な場合、配置モデルを使用してノード間の関係を把握できます。これは、ノードに対するコンポーネントとデータの一時的な割り当てを含み、データにアクセスするコンポーネントに対するユーザー アクセスの方法を示さなければなりません。実現可能性の評価や見積りに必要な部分を除き、ノードと接続の詳細な仕様の検討は後に回します。利用可能な既存の資産が適切な資産である場合は、既存の資産を使用できます。これはプロジェクトで初めて、迅速かつ高レベルで作成する配置モデルですが、この時点で製品の選択や決定が必要な場合は、配置概要を作成することにより実際のハードウェア製品とソフトウェア製品が明確になる場合もあります。
配置モデルが、一般的なユース ケースを実行するユーザー (特に、必要な場合は遠隔地にいるユーザー) をサポートすると同時に、機能外要求と制約を満たすことを検証します。ノード間の接続が、異なるノード上のコンポーネント同士や、コンポーネントと格納データ間での相互作用をサポートするために十分であることを検証します。
目的 | 設計者がオブジェクトに「生命」を与えるために使用する分析メカニズムと分析サービスを定義する |
方向づけ時のアーキテクチャ統合の実施に焦点が置かれている場合、この手順はこの作業から除外されます。
分析メカニズムは、「トップダウン方式」(以前からの知識に基づく方式) と「ボトムアップ方式」(作業を進めていく中で発見していく方式) に分類できます。「トップダウン方式」では、ソフトウェア アーキテクトは自分の領域にある種の問題があること、およびある種のソリューションが必要になることを経験によって知ります。分析中にメカニズムとして表現される一般的なアーキテクチャの問題としては、永続性、トランザクション管理、障害管理、メッセージ処理、推論エンジンなどがあります。これらに共通な点は、システムの幅広いクラスの一般的な機能であることおよび基本的なアプリケーション機能との相互作用やサポート機能を提供することです。この分析メカニズムのサポート機能は、導入プラットフォームや実装言語とは関係なく、システムの基本的な機能要求で必要とされます。また分析メカニズムは、何種類かの異なる方法で設計および実装が可能です。一般的に、1 つの分析メカニズムに対して複数の対応する設計メカニズムがあり、さらに各設計メカニズムに対して、複数の実装方法が考えられます。
ボトムアップ方式は、分析メカニズムの生みの親といえます。この方式は、各種の問題に対する一連のソリューションから生ずる共通のテーマをソフトウェア アーキテクトの視点から、最初は大まかにとらえます。すなわち、異なるスレッドのクロックを同期させなければならないというニーズや、リソースを割り当てるために共通の方法が必要であるというニーズを考慮します。このようなパターンから、分析言語を単純化する分析メカニズムが生まれます。
分析メカニズムの識別は、共通で、かつ多くの場合、システムへの要求により暗黙に提示される二次的な問題の存在を明確にし、名前を付けることを意味します。最初に存在するのは名前だけかもしれません。たとえば、ソフトウェア アーキテクトがシステムにより、永続性のあるメカニズムが必要なことを認識した場合などです。最終的には、このメカニズムはクラスのソサエティのコラボレーションとして実装されますが ([BOO98] を参照)、これらの中にはアプリケーション機能を直接提供するのではなく、サポートするためだけに存在するものもあります。多くの場合、そのようなサポート クラスはレイヤ化されているアーキテクチャの中間または下位のレイヤに配置され、アプリケーション レベルの全クラスに共通のサポート サービスを提供する働きをします。
明確にした二次的な問題の共通度が高いものであれば、多くの場合パターンが存在し、既存のクラスをバインドして、パターンによって必要となる新しいクラスを実装することで、メカニズムをインスタンス化できます。そのようにして導出された分析クラスは抽象的なもののため、設計過程でさらに具体化した上で実装する必要があります。
詳細は、「概念: 分析メカニズム」を参照してください。
目的 | アーキテクチャ分析の結果が完全で一貫していることを確認する |
アーキテクチャ分析が結論に達したら、識別したアーキテクチャ メカニズム、サブシステム、パッケージ、クラスをレビューして、それらが完全で一貫していることを確認します。アーキテクチャ分析の結果は、まだ準備段階で比較的非公式なものなので、レビューも同じく非公式とするべきです。シナリオまたはユース ケースを使用して、ビジネス的観点や特定の相互作用など、さまざまなレベルにおいてアーキテクチャの選択を確認できます。
この作業結果の評価については、「チェックポイント: ソフトウェア アーキテクチャ説明書 - アーキテクチャ分析の考慮事項」を参照してください。
Rational Unified Process
|