配置モデルでは、実行時の処理ノードの構成、ノード間の通信リンク、ノード上にあるコンポーネントのインスタンスとオブジェクトを示します。 
役割:  ソフトウェア アーキテクト 
オプション度 / 使用時期:  オプション
テンプレートとレポート: 
 
例:   
UML の表現:  モデル
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

配置モデルの目的は、システムにおける処理要素の構成と処理要素間の接続を把握することです。配置モデルは、1 つ以上のノード (最低 1 つのプロセッサ、メモリ、その他のデバイスを持つ処理要素)、デバイス (モデリング段階の抽象レベルでは処理能力を持たないステレオタイプ付きノード)、ノード間およびノードとデバイス間のコネクタから構成されます。配置モデルではプロセスをこれらの処理要素にマッピングすることも行い、表現されるノード間に振る舞いを分散させることができます。

配置モデルを使用するのは次の役割の人々です。

  • ソフトウェア アーキテクト。システムの物理的実行環境を把握および理解し、分散に関連する問題を理解するために使用します。
  • 設計者 (ソフトウェア設計者データベース設計者を含む)。システム内での処理とデータの分散を理解するために使用します。
  • システム管理者。システムが稼働する物理環境を理解するために使用します。
  • プロジェクト管理者。開発企画書のコスト見積もりと、調達、インストール、保守の計画立案に使用します。

プロパティ ページの先頭へ

プロパティ名 

概要 

UML の表現 

Introduction  モデルの簡単な紹介を記述したテキスト  「short text」型のタグ付き値 
Nodes  システム内の処理要素

ノードは次のプロパティを持つ場合があります。

  • 名前
  • プロセッサ、記憶容量、メモリ容量、またはその他のデバイスの性能に関する情報を提供する記述
  • プロセッサ上で実行するプロセスとスレッドの一覧。ここでは各プロセス内で実行するソフトウェア コンポーネントも列挙する
  • ノード上にインストールされる導入ユニットの一覧
 
ノード 
Devices  (モデリング段階の抽象レベルでは) 処理能力を持たず、プロセッサ ノードをサポートする物理デバイス

デバイスは次のプロパティを持つ場合があります。

  • 名前
  • デバイスの性能に関する情報を提供する記述 
 
ステレオタイプ付きのノード 
Connectors  ノード間、およびノードとデバイス間の接続

コネクタには、コネクタの容量または帯域幅に関する情報が関連づけられる場合があります。 

例として、さまざまな種類のコネクタをモデリングするための関連 (ステレオタイプが付く場合がある) 
Diagrams  パッケージに属するモデル内のダイアグラム   

表現 ページの先頭へ

配置モデルは通常、次に示すようなダイアグラムに描かれます。

タイミング ページの先頭へ

方向づけフェーズ

方向づけフェーズでは、導入環境がまだ存在しない場合は、アーキテクチャ統合の一環として概念レベルでモデルを作成します。このとき、ソフトウェア アーキテクトは要求、特に機能外要求を満たす実用的なアーキテクチャを、少なくとも 1 つ明確にしようと試みます。プロジェクト管理者はコストの見積もりに配置モデルを使用します。

ただし、システムが既存の環境に配置される場合は、その環境を文書化します。把握すべき重要な要素は次のとおりです。 

  • システム内のノードのタイプ (システム全体のトポロジーを文書化する必要はありません。特徴を捉えるだけで十分です)
    • ノードの容量と性能に関する情報
    • これらのノード上で既に稼働しているソフトウェアに関する情報
  • ノードを接続しているネットワークの構成
    • 接続の容量
    • 接続の信頼性

推敲フェーズ

推敲フェーズでは、配置モデルが仕様レベルにまで洗練され、ソフトウェア アーキテクトは自信を持って性能を予測できるようになります。この後でモデルを物理レベルにまで持っていきます。このレベルでは、使用する実際のハードウェアとモデルの数を仕様化するため、モデルはシステムの調達、インストール、保守のための計画書になります。

導入環境が既に存在している場合は、その環境を検証し、開発中のシステムの新しい機能に対応する能力があるかどうかを判断します。導入環境への変更が必要であれば、このフェーズで識別します。

導入環境がまだ存在していない場合、アーキテクチャを実現するために必要なノードの数、タイプ、構成、ノード間接続を定義します。次のものを含めて、配置に関するアーキテクチャの重要な側面を検証し、対処します。

  • 信頼性と可用性
  • 処理、容量、性能の分散
  • コスト
  • サポートと管理の容易さ

作成フェーズ

ノードへのコンポーネント (または導入ユニット) の割り当ては、コンポーネントが変更されると更新されます。

導入環境がまだ存在していない場合には、ソフトウェア開発作業と並行して、ハードウェアの調達とインストールの作業を実行するのが一般的です。ハードウェアの購入に関する最終決定には、できるだけ遅らせることが推奨されます。これは、性能リスクを軽減し (導入されたソフトウェアが満足できるだけの性能、応答時間、スループット特性を実証する)、技術の進歩と価格性能比の改善の恩恵を受けるためです。作成フェーズ中に性能上の問題が発生した場合、ソフトウェア アーキテクトがこの問題に対処するときに、ソフトウェアのアーキテクチャそのものだけでなく、配置モデルを自由に修正できるのが理想的です。

移行フェーズ

導入環境は、システムのインストール待ちとなっています。ソフトウェアが 1 回以上のベータテストを通過すると、1 回以上のテストまたは試行導入が行われます。ソフトウェアは段階的に、導入環境へと移行していきます。

責務 ページの先頭へ

ソフトウェア アーキテクトは配置モデルに責任を持ちます。

カスタマイズ ページの先頭へ

単一プロセッサシステムや、処理の分散がほとんどまたは全くない単純なシステムでは、配置モデルはオプションとなります。

ネットワークまたはプロセッサの構成が複雑なシステムでは、配置モデルが必須です。 



Rational Unified Process   2003.06.15