システムの一部であるこの成果物は、振る舞いをカプセル化し、インターフェースの集合を公開し、他のモデル要素をパッケージ化します。

外部から見て、サブシステムは他のモデル要素と協調してその責務を果たす単独の設計モデル要素です。外部に公開されたインターフェースとそれらの振る舞いのことをサブシステム仕様と呼びます。

内部的には、サブシステムはモデル要素 (設計クラスと他のサブシステム) の集合体であり、サブシステム仕様のインターフェースと振る舞いを実現します。これはサブシステムの実現と呼ばれます。

Other Relationships:  一部設計モデル
役割:  設計者 
オプション度/使用時期:  クラスとパッケージだけで構成される単純なシステムに関してはオプション。 
テンプレートおよびレポート: 
     
例: 
     
UML の表現:  設計サブシステムは、UML 2.0 コンポーネントとしてモデリングされます。UML では、<<subsystem>> という名前のコンポーネントのステレオタイプが定義されており、例えば、大規模な構造を表すために使用できます。表現については、『ガイドライン: 設計サブシステム』を参照してください。 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

設計サブシステムは、明示的インターフェースと仮インターフェースを提供することで振る舞いをカプセル化し、通常はその内部の構造を公開しません。設計サブシステムを使用すると、多数のクラスやサブシステムの相互作用を完全にカプセル化できるようになります。設計サブシステムの「カプセル化」能力は、インターフェースを実現しない成果物: 設計パッケージの同じ能力とは対照的です。パッケージは主に、構成管理とモデルの組織化に使用され、その場合サブシステムが振る舞いの補助的なセマンティクスを提供します。

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

主要な機能は開発の単位として扱うことのできる「塊」に分割されるので、設計サブシステムは推敲フェーズで作成されます。

責務 ページの先頭へ

設計者は次の事柄を徹底し、設計サブシステムの整合性に責任を持ちます。

  • サブシステムがその内容をカプセル化し、内部の振る舞いはそのサブシステムが実現するインターフェースのみを通して公開すること
  • サブシステムが実現するインターフェースの操作が、サブシステムに保有されるクラスまたはサブシステム間に分散されること
  • サブシステムがそのインターフェースを正しく実装すること

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

設計サブシステムは、大規模なシステムを複数の部分に分解して理解しやすくする重要な手段です。設計サブシステムは特に、コンポーネント・ベースの開発で、独立して開発、再利用、再配置されるものと予測されるコンポーネント (『概念: コンポーネント』を参照) を仕様化するために役立ちます。

設計サブシステムに関係するカスタマイズ上の重要な決定事項には、次のものがあります。

このカスタマイズ上の決定事項は、ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有のガイドラインで把握するべきものです。

UML 1.x の表現ページの先頭へ

設計サブシステムを UML 2.0 コンポーネントとしてモデリングするか、UML 1.5 サブシステムとしてモデリングするかは、重要なカスタマイズ上の決定事項です (『 ガイドライン: 設計サブシステム』を参照)。

詳しくは、『UML 1.x と UML 2.0 の相違点 』を参照してください。

Rational Unified Process   2003.06.15