実装サブシステムは、実装要素の集合です。実装サブシステムは、統合とテストの単位として独立させることのできる小さな部分にモデルを分割することで、実装モデルを構造化します。 
そのほかの関係:  一部実装モデル
役割:  実装担当者 
オプション度 / 使用時期:  推奨。推敲フェーズ
テンプレートとレポート: 
 
例:   
UML の表現:  実装モデル内のパッケージ。モデルの最上層のパッケージ、または «implementation subsystem» としてステレオタイプ化されるパッケージのどちらか 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的ページの先頭へ

実装サブシステムを使用するのは次の人々です。

  • ソフトウェア アーキテクト。統合とテストの単位として独立させることのできる部分に実装モデルを構造化するために使用します。
  • システムの次のバージョンの設計者。実装モデルの構造を理解するために使用します。
  • システムのほかの部分の実装担当者。各部分の機能性の使用方法を理解するために使用します。
  • サブシステムのテスト担当者。テスト作業の計画立案に使用します。
  • プロジェクト管理者。実装作業の割り当てのための基礎として使用します。

実装サブシステムは、物理的な観点では設計パッケージと類似した概念です。実装モデルと実装サブシステムは最初は実装ビューに定義されるため、開発時に最も重要となります。

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

プロパティ名 

概要 

UML の表現 

Name  サブシステムの名前  モデル要素の「Name」属性 
Brief Description  サブシステムの役割と目的の簡単な説明  「short text」型のタグ付き値 
Implementation Elements  サブシステムに直接保有される実装要素。ファイルやディレクトリを含む  メタ集約「owns」を通して再帰的に所有される 
Relationships  サブシステムに直接保有される関係  - " - 
Diagrams  サブシステムに直接保有されるダイアグラム  - " - 
Implementation Subsystems  サブシステムに直接保有されるサブシステム  - " - 
Import Dependencies  サブシステムからほかのサブシステムへのインポート依存関係  メタ集約「owns」を通して、包含する側のサブシステムに所有される 

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

ソフトウェア アーキテクトは、推敲フェーズの間にサブシステムを定義し、個人またはチームに割り当てます。これはクラスの実装が開始される前に行われるため、サブシステムの並行開発が可能となります。

責務 ページの先頭へ

実装担当者は次の事柄を徹底し、サブシステムに責任を持ちます。

  • サブシステムが必要な要求を満たしていること
  • 将来の変更の影響を見積もることができるように、サブシステムを起点とするインポート依存性が記述されていること
  • ファイルやディレクトリを含むサブシステムの内容や、ネストされた実装サブシステム群が、独立して統合とテストを行うのにふさわしい、実装の中の 1 つの単位としての部分を形成していること
  • サブシステムが、それに対応する設計モデル内の部分との整合性を保っていること

実装サブシステムに責任を持つ実装担当者は、サブシステムの public (可視) 要素に対しても責任を持ちます。

実装サブシステムに責任を持つ実装担当者が、そのサブシステムに含まれるすべての要素についても責任を持つことが推奨されます。詳しくは、「成果物: 実装要素」を参照してください。

実装担当者のチームが実装サブシステムを開発する場合、チーム メンバーのうち 1 人がそのサブシステムに責任を持つようにします。

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

実装サブシステムを使用することが推奨されています。設計におけるパッケージを、実装におけるサブシステムとディレクトリにどのようにマッピングするかを決定する必要があります。必要なサブシステムのレベル数も決定しなければなりません。



Rational Unified Process   2003.06.15