トピック

説明ページの先頭へ

プログラミング環境では、実装は、ソース・コード・ファイル、バイナリー・ファイル、データ・ファイルなどの実装要素で構成され、これらのファイルはディレクトリーに編成されます。このような下位レベルの要素に加えて、通常は、上位レベルの管理単位である実装サブシステムを作成する必要があります。実装サブシステムは、実装要素と他の実装サブシステムをグループ化しています。

実装モデルは、主として実装サブシステムをモデル化し、依存関係や他の管理情報を含んでいます。また、配置可能なファイルやディレクトリー構造などの、実装サブシステムの重要な要素をモデル化することもできます。

付随するテキスト内で説明される図

実装モデルの表記法。矢印は可能な所有関係を示しています。

オプションとして、実装モデルの最上位レベル (ルート) のノードとして機能するパッケージがあります。パッケージは、<<implementation subsystem>> としてステレオタイプ化され、実装要素 (ファイルとディレクトリー) と他の実装サブシステムをグループ化します。

例:

銀行システムでは、実装サブシステムは、実装モデルの最上位レベル・ノード内のフラットな構造として編成されます。 実装モデルのサブシステムを表す方法としては、他にレイヤー構造があります (『ガイドライン: インポート依存関係』を参照)。

付随するテキスト内で説明される図

所有権の階層を示す銀行システムの実装モデル

実装モデルは、実装サブシステムの階層に関する実装の基本構造を定義するだけでなく、実装サブシステム間のインポート依存関係、実装要素関係のコンパイル関係、実装モデル要素と設計モデル要素の間の依存関係を示すダイアグラムも表します。

詳しくは、以下を参照してください。

使用 ページの先頭へ

実装モデルは、実装サブシステムと実装要素に関するソフトウェアの物理的編成に焦点を当てます。 オプションとして、物理的な実装と論理的な設計の両方を扱う単一のモデルを作成することもできます。これは、ソース・コード・ファイルと、実装モデルと設計モデルの組み合わせを同期化するラウンド・トリップ・エンジニアリング方法では一般的です。

実装サブシステムの編成は、2 つのモデル間のマップ方法により、設計モデルとの対応を強くしたり弱くしたりできます。 これは、プロジェクトに固有の設計ガイドラインで把握する必要のある、プロセスに関する決定事項です。マッピングが厳密である場合、つまり各実装サブシステムが設計サブシステムでもある場合は、1 つの設計サブシステムに焦点を当てたダイアグラムを作成し、その設計と設計要素の両方をまとめることができます。

実装モデルの構成方法および設計モデルと実装モデルの間のマップ方法について詳しくは、『概念: 設計のコードへのマッピング』、『作業: 実装モデルの構成』、『ガイドライン: 実装要素』を参照してください。



Rational Unified Process   2003.06.15