目的
  • 実装の存在場所になる構造を確立する。
  • 実装サブシステムとその内容についての責務を割り当てる。
 
ステップ  
入力とする成果物:    結果となる成果物:   
頻度: 反復ごとに最低 1 回。新しい実装要素が発見されたとき。 
役割:  ソフトウェア アーキテクト 
ツール メンター:   
More Information: 

ワークフローの詳細:   

実装モデル構造の確立 ページの先頭へ

目的 実装モデルの構造を確立する。 

「設計空間」から「実装空間」への移動に際し、設計モデルの構造を実装モデルに反映させることから開始します。

設計パッケージは対応する実装サブシステムを持ち、このサブシステムには、対応する設計要素を実装するために必要な 1 つ以上のディレクトリとファイル (成果物: 実装要素) が含まれます。各実装サブシステムは、アーキテクチャ内の特定レイヤに割り当てられるので、設計モデルから実装モデルへのマッピングは変化することがあります。

実装モデル構造を表すダイアグラムを作成します (「ガイドライン: 実装図」を参照)。

実装サブシステムの調整 ページの先頭へ

目的 チーム編成または実装言語の制約を反映するよう、モデル構造を調整する。 

実装環境に関連する細かい戦術的問題を検討して、サブシステムの構成に変更が必要かどうかを決定します。このような戦術的問題の例を以下に示します。実装サブシステムの構成を変更することを決定したら、前に戻って設計モデルを更新するか、設計モデルを実装モデルとは異なるままにしておくかを決定する必要があります。

  • 開発チームの編成: サブシステム構造では、複数の実装担当者または実装担当者のチームが作業を重複したり、混乱したりすることなく、並行作業できるようにする必要があります。各実装サブシステムは、1 チームだけの担当にすることをお勧めします。これは、(サブシステムが大きい場合は) サブシステムを 2 つに分割し、この 2 つの実装部分を 2 人の実装担当者または 2 チームの実装担当者で実装するということです。この 2 人 (またはチーム) のビルド サイクル / リリース サイクルが違う場合は特に注意を払ってください。
  • 型の宣言: 実装段階になると、サブシステムはほかのサブシステムから成果物をインポートする必要が生じる場合があります。該当のサブシステムでは、型が宣言されているからです。これは通常、C++、Java、Ada のような型付きのプログラミング言語を使用した場合に生じます。この場合、通常は型宣言を別のサブシステムへ抽出するとよいでしょう。

サブシステム D からいくつかの型宣言を抽出して、新しいサブシステムの型、サブシステム A を作成します。これは、サブシステム D のパブリック (可視) 成果物への変更には依存しません。

型宣言はサブシステム D から抽出します。

  • 既存のレガシー コードとコンポーネント システム: レガシー コード、再利用可能コンポーネントのライブラリ、市販 (COTS) 商品を組み込む必要が生じる場合があります。これらが設計でモデル化されていない場合は、実装サブシステムを追加する必要があります。
  • 依存関係の調整: サブシステム A とサブシステム B には相互にインポート依存関係があると仮定します。ただし、B は A の変更に依存しないようにすると仮定します。B がインポートする A の成果物を抽出して、新しい実装サブシステム A1 の下位レイヤに入れます。

サブシステム A から成果物を抽出して、新しいサブシステム A1 内に配置します。

既に実装サブシステムは設計モデル内のパッケージ / サブシステムに 1 対 1 でマッピングされないため、対応する変更を設計モデル内で行うか (設計モデルを実装モデルに密接に対応させることを決定した場合)、実装モデルと設計モデル間のマッピングを追跡します (追跡可能性や実現の依存関係を通じて)。そのようなマッピングがいつ、どのように行われるかは、プロセスの決定であり、../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有のガイドラインで把握される必要があります。

実装サブシステムごとのインポートの定義 ページの先頭へ

目的 サブシステム間の依存関係を定義する。 

各サブシステムについて、ほかのどのサブシステムをインポートするのかを定義します。これはサブシステムのすべてのセットについて実行でき、あるレイヤのすべてのサブシステムが下位レイヤのすべてのサブシステムをインポートできるようにします。一般に、実装モデルでの依存関係は、実装モデルの構造が調整された場合を除いて、設計モデルの依存関係を反映しています (「実装サブシステムの調整」を参照)。

サブシステムのレイヤ構造をコンポーネント図に示します。

実行可能ファイル (とその他の派生オブジェクト) の扱い方の決定 ページの先頭へ

実行可能ファイル (とその他の派生オブジェクト) は、実装サブシステム (またはサブシステム) またはその一部にビルド プロセスを適用した結果できあがるもので、論理的には実装サブシステムに属します。ただし、ソフトウェア アーキテクトは構成管理者と共に、実装モデルに適用する構成項目の構造を決定する必要があります。 

特に配置について選択と参照を簡単にするための基本的な推奨事項は、別個の構成項目を定義して、配置可能な実行可能ファイルのセットを含めることです (どのノードにどの実行可能ファイルを配置するかは、配置モデルで把握される)。したがって、単純なケースでは、各実装サブシステムについて、配置可能な実行可能ファイルの構成項目と、それらを生成するソース コードなどを含む構成項目があります。実装サブシステムは、これらの構成項目 (およびテスト資産などのその他の項目) を含む、複合構成項目で表されると考えることができます。

モデリングの観点から見ると、ビルド プロセスで生成される実行可能ファイルの集合は、成果物: ビルド (パッケージ) で表すことができ、関連する実装サブシステム (それ自体がパッケージ) に含まれます。

テスト資産の扱い方の決定 ページの先頭へ

目的 テスト成果物を実装モデルに追加する。 

一般に、Rational Unified Process のテスト成果物とテスト サブシステムの扱いは、ほかの開発ソフトウェアとほとんど変わりません。ただし、テスト成果物とテスト サブシステムは通常、導入システムの一部とならず、顧客への納品可能物にもなりません。したがって、基本的な推奨事項は、テスト資産をテスト対象 (単体テストの実装要素、統合テストの実装サブシステム、システム テストのシステム) と一緒に構成することですが、プロジェクト リポジトリがディレクトリのセットまたは階層として構成されている場合は、テスト資産を別個のテスト ディレクトリなどに格納します。個別のテスト サブシステム (単体テスト レベル以上のテストを意図) は、ほかの実装サブシステムと同じく、個別の構成項目として扱う必要があります。

モデリングの場合、テスト成果物の集合は、成果物 : 実装サブシステム (パッケージ) として表すことができます。単体テストの場合、このようなテスト サブシステムは通常、関連する (テスト済みの) 実装サブシステムに含まれます。ソフトウェア アーキテクトは構成管理者と相談して、このレベルのテスト成果物を、テストする実装要素と一緒に構成するか、別個の構成項目として構成するかを決定します。統合テストとシステム テストについては、テスト サブシステムはテスト対象の実装サブシステムと同等のものである場合があります。

実装ビューの更新 ページの先頭へ

目的 ソフトウェア アーキテクチャ説明書の実装ビューを更新する。 

実装ビューは、ソフトウェア アーキテクチャ説明書の「実装ビュー」で説明されています。この項には、サブシステム間のインポート依存関係だけでなく、レイヤと、実装サブシステムのレイヤへの割り当てを示すコンポーネント図が記載されています。

実装モデルの評価 ページの先頭へ

チェックポイント: 実装モデル」を参照してください。

 

Rational Unified Process   2003.06.15