目的
  • 実装環境の制限に基づいて、分析メカニズムを設計メカニズムへと洗練する。
手順
入力とする成果物: 結果となる成果物:
頻度: 反復ごとに 1 回
役割: ソフトウェア アーキテクト
ツール メンター:
More Information: 

ワークフローの詳細:

分析メカニズムのクライアントの分類ページの先頭へ

分析メカニズムでは、分析クラスで使用される概念的なサービスのセットが提供されます。これらは、最終的には考慮しなければならないが分析の作業では範囲外になる、かなり複雑な振る舞いに対するショートハンドとなります。主な目的は、まだ設計されていないシステムのサービスに対する要求を、サービス プロバイダ自体の考慮をせずに把握することにあります。

ここで、分析メカニズムで収集した情報の見直しを開始します。次のステップに従います。

各分析メカニズムのクライアントの識別: 与えられた分析メカニズムのすべてのクライアントに目を通し、そのメカニズムに必要な特性を確認します。たとえば、多くの分析クラスで永続性メカニズムを使用する場合でも、それぞれの要求は異なることがあります。1000 の永続インスタンスを持つクラスと、400 万の永続インスタンスを持つクラスでは、永続性の要求が大幅に異なるからです。同様に、インスタンス データに 1000 分の 1 秒で応答しなければならないインスタンスを持つクラスと、特定のクエリーやバッチ レポート アプリケーションを通してのみアクセスされるインスタンス データを持つクラスでは、永続性に対して異なるアプローチが必要です。

各分析メカニズムに対する特性プロファイルの識別: 性能、フットプリント、セキュリティ、経済的コストの程度によって、非常に幅の広い特性プロファイルが存在する場合があります。各分析メカニズムはそれぞれ異なり、異なる特性が適用されます。多くのメカニズムでは、管理するインスタンス数およびインスタンスの予想されるサイズ (予想されるバイト数) の見積もりが必要となります。大量のデータを転送する場合は、どのようなシステムでもかなりの性能的な問題を解決しなければなりません。

クライアントの特性プロファイルによるグループ分け: 同様の特性プロファイルの分析メカニズムを必要とするクライアントで、グループを形成します。これらのニーズに基づいて設計メカニズムを識別します。これらのグループ分けによって設計メカニズムを始めることができます。たとえば、分析メカニズム「プロセス間通信」を、設計メカニズム「オブジェクト リクエスト ブローカー」にマップできます。異なる特性プロファイルにより、同じ分析メカニズムから異なる設計メカニズムが生まれます。分析時にはシンプルな永続メカニズムが、設計時には メモリ内の永続性、ファイル ベース、データベース ベース、分散型などの多くの永続メカニズムへと発展していきます。設計メカニズムは、異なる特性プロファイルに基づいて分析メカニズムを見直したものです。

実装メカニズムのリストの作成ページの先頭へ

一番下層から始め、自由に使用できる実装メカニズムのリストを作成します (「概念: 設計メカニズムと実装メカニズム」を参照してください)。

  • ミドルウェア製品またはコンポーネント フレームワークにより提供されるメカニズム
  • オペレーティング システムにより提供されるメカニズム
  • コンポーネントにより提供されるメカニズム
  • クラス ライブラリにより提供されるメカニズム
  • 従来のコード (「作業: 既存の設計要素の組み込み」も参照)
  • 特殊目的のパッケージ: GUI ビルダ、地理情報システム、DBMS など

既存の実装メカニズムを使用できるかおよびどの部分で新しい実装メカニズムをビルドしなければならないかを決定します。

設計メカニズムの実装メカニズムへのマップページの先頭へ

設計メカニズムでは、実装メカニズムの抽象が提供され、分析メカニズムと実装メカニズム間のギャップを埋めます。設計に抽象的なアーキテクチャ メカニズムを使用すると、特定のメカニズムの詳細によって現在直面している問題から焦点をはずしてしまうことなく、アーキテクチャ メカニズムをどのように提供するかを検討できます。また、設計に悪影響を与えることなく、特定の実装メカニズムを他の実装メカニズムに置き換えることもできます。

特性の範囲の決定: 設計メカニズムに対して識別された特性を使用して、実装メカニズムの候補に対して妥当、経済的または可能な設計メカニズム特性の値の範囲を決定します。

購入するコンポーネントのコストの検討: 実装メカニズムの候補に対し、純粋な技術的基準に加え、購入やライセンスのコスト、製品の成熟度、ベンダーとの関係、サポートなどを検討します。

適切なコンポーネントの調査またはコンポーネントの作成: 一部の設計メカニズムでは、明らかに適切な実装メカニズムが見つからない場合が多くあります。このような場合は、適切な製品を探すか、社内で開発する必要があるかを決定します。また、一部の実装メカニズムがまったく使用されていないこともあります。

実装メカニズムの選択は、技術的特性との適合だけでなく、コストなどの非技術的な特性にも依存します。選択の一部は一時的な場合もあり、すべての場合にいくらかのリスクが伴います。性能、耐久性およびスケーラビリティは、ほとんどすべての場合に問題となり、評価、説明的なプロトタイプまたはアーキテクチャ プロトタイプによって検証する必要があります。

アーキテクチャ メカニズムの文書化ページの先頭へ

このアクティビティにおけるソフトウェア アーキテクトの役割は、これらのメカニズムをビルドまたは統合して決定および検証し、適切に機能することを確認し、システム設計のほかの部分に継続して適用することにあります。ソフトウェア アーキテクトの役割はプロセス エンジニアの役割と連携し、メカニズムと使用に関する詳細をプロジェクト固有の設計ガイドラインに文書化します。分析メカニズム、設計メカニズム、および実装メカニズム間の関係 (またはマッピング) と、これらの選択に関連する根拠をソフトウェア アーキテクチャ説明書に記述しなければなりません。メカニズム自体は、各設計活動の一部として「成果物: 設計モデル」に詳細化される設計モデル要素 (設計パッケージ、設計クラス、設計サブシステム) です。



Rational Unified Process   2003.06.15