トピック

サブシステムの使用方法 ページの先頭へ

サブシステムをさまざまな補助的手段として使用することによって、システムを次の単位にパーティション化できます。

  • 独立して注文、カスタマイズ、納入できる単位
  • インターフェースさえ変更しなければ、独立して開発できる単位
  • 分散コンピューティングのノード・セットに渡って、独立して導入できる単位
  • システムの他の部分を破壊せずに、独立して変更できる単位

したがって、サブシステムは、単独の設計クラスより大きく、コンポーネント・ベースの開発における交換可能な構成単位であるコンポーネントのモデリングに理想的です。

さらに、サブシステムは次のことができます。

  • システムを、制約条件付きのセキュリティーを主要なリソースに提供できる単位にパーティション化する
  • 既存の製品や、設計にある外部システムを表現する

サブシステムの識別 ページの先頭へ

複雑な分析クラスは、単独で機能する単一の設計クラスの責務とすることのできない振る舞いを具体化する場合は、設計サブシステムにマップされます。 複雑な設計クラスも、コラボレートする複数のクラスとして実装される場合は、サブシステムにすることができます。

また、サブシステムは、別のチームによって独立して開発されるシステムの部分を識別するためのよい手段でもあります。コラボレートする設計要素をコラボレーションと共に 1 つのパッケージ内に完全に収容できる場合は、単純なパッケージによって提供されるよりもずっと強力なカプセル化の形態がサブシステムによって提供されます。サブシステム内部のコンテンツとコラボレーションは 1 つ以上のインターフェースの背後に完全に隔離されるため、サブシステムのクライアントはそのインターフェースのみに依存することになります。したがって、サブシステムの設計者は外部依存性から完全に切り離されます。設計者 (または設計チーム) は、インターフェースを実現する方法を特定する必要はありますが、外部依存性に影響を与えることなく内部のサブシステム設計を自由に変更することができます。 独立性の高いチームを持つ大規模なシステムでは、この分離度の問題が、正式なインターフェースによって提供されるアーキテクチャーの実施と併せて、単純なパッケージとサブシステムのどちらを選択するかという大きな争点になります。

設計サブシステムは、このようなコラボレーションをカプセル化するために使用されます。サブシステムのクライアントは、サブシステムが提供するサービスを使う場合であっても、サブシステムの内部設計を知る必要はまったくありません。 コラボレーションに参加するクラス/サブシステムが、しっかりと定義された結果のセットを生成するために、それら同士だけで相互作用する場合は、コラボレーションおよびコラボレートする設計要素を、1 つのサブシステムにカプセル化する必要があります。

このルールは、コラボレーションのサブセットにも適応できます。コラボレーションの任意の部分または全体をカプセル化して単純化することができ、そうすることで設計はいっそう理解しやすくなります。

ヒント

ヒント

詳細

オプション度を求める 特定のコラボレーション (またはサブコラボレーション) がオプションの振る舞いを表現する場合は、それをサブシステムに含めます。削除、アップグレード、または代替案と置換できる機能は、独立しているものと見なす必要があります。
システムのユーザー・インターフェースを求める ユーザー・インターフェースが、システムのエンティティー・クラスから比較的独立している場合 (つまり、2 つが独立して変更可能であり、かつ変更される場合) は、水平方向に統合されたサブシステムを作成します。グループに関連するユーザー・インターフェース・バウンダリー・クラスを 1 つのサブシステムに、グループに関連するエンティティー・クラスをもう 1 つのサブシステムに統合します。
ユーザー・インターフェースとそれが表示するエンティティー・クラスが緊密に結合している場合 (つまり、片方における変更が、他方における変更を引き起こす場合) は、垂直方向に統合されたサブシステムを作成します。関連するバウンダリーとエンティティー・クラスを共通のサブシステムに含めます。
アクターを求める 2 つの異なるアクターに使用される機能を独立させます。各アクターが独立してシステムでの要求を変更する可能性があるためです。
外部のシステムまたはデバイスへのアクセスをカプセル化するサブシステムを作成します。
設計要素間の結合と固着を求める 高度に結合または固着したクラス/サブシステムは、サービスのセットを提供するためにコラボレートします。高度に結合した要素をサブシステムに編成し、結合が弱い線に沿って要素を分けます。よりまとまりの強い責務を持つ小さなクラスに分けることによって、またはサブシステムを適切に再分割することによって、弱い結合を完全に取り除くことが可能な場合もあります。
代用品を求める 特定の機能について指定された、サービスのレベルが複数ある場合は (例えば、高、中、低可用性など)、各サービス・レベルを別個のサブシステムとして表し、それぞれが同じインターフェースのセットを実現します。これによって、サブシステムが相互に代用可能になります。
分散を求める 特定のサブシステムの複合インスタンスが存在し、それぞれを異なるノードで実行できますが、多くのアーキテクチャーでは、コンポーネントを構成する 1 つのインスタンスを複数のノードにわたって分割することはできません。サブシステムの振る舞いがノードを超えて分散される必要がある場合は、機能的に制約のある小規模のサブシステムにサブシステムを分割することをお勧めします (そのそれぞれが単一コンポーネントを表します)。  各ノードに必須の機能を決定し、その機能を「所有する」新しいサブシステムを作成します。それに沿って、元のサブシステムの責務と関連要素を分散させます。  新しいサブシステムは、元のサブシステムにとって内部のものになります。

設計をサブシステムに編成したら、ユース・ケースの実現をそれに従って更新します。

サブシステムのモデリング ページの先頭へ

設計サブシステムは、UML コンポーネントを使用してモデリングされます。これを構成すると、以下のモデリング機能が使用できます。

  • クラスをグループ化して、粒度の大きいシステムの部分を定義できる
  • 可視のインターフェースを内部の実装から分離できる
  • 実行時に実行するインスタンスを持つことができる

さらに以下の考慮事項があります。

  • 各設計サブシステムには、名前と短い説明を付ける必要があります。
  • 元の分析クラスの責務は、新しく作成したサブシステムに移す必要があります。責務を文書化するには、サブシステムの説明を使用します。

注: UML 2.0 では、<<subsystem>> という名前のコンポーネントのステレオタイプが定義されており、例えば、大規模な構造を表すために使用できます。 RUP 設計サブシステムは、大規模な構造であることも、そうでないこともあります。いずれも、RUP の観点から見れば設計サブシステムです。この問題 (例えば、コンポーネントを合成したコンポーネントに <<subsystem>> というラベルをつけるかどうか) は、ソフトウェア・アーキテクトが決定すべき問題です。

既存の製品を表すサブシステム ページの先頭へ

既存製品がインターフェースつまり操作 (およびおそらく受信) をエクスポートするけれども、実装のそれ以外の詳細はすべて隠している場合は、論理ビューのサブシステムとしてモデル化される可能性があります。 サブシステムによって表現できる可能性があり、システムによって使用される製品の例には次のものがあります。

  • 通信ソフトウェア (ミドルウェア)
  • データベース・アクセス・サポート (RDBMS マッピング・サポート)
  • アプリケーション固有の製品

タイプとデータ構造の集合 (例えばスタック、リスト、クエリー) などのような一部の既存製品は、パッケージとして表現した方がよい場合があります。これらは振る舞い以上のものを表しており、重要で役立つものは、単なるコンテナーであるパッケージ自体ではなく、パッケージの具体的な内容だからです。 

数値計算ライブラリーなどの共通ユーティリティーは、単にインターフェースをエクスポートするだけであれば、サブシステムとして表現できます。ただし、これが必要または有意義かどうかの判断は、モデル化する物の本質を設計者がどう判断するかによります。 サブシステムは、オブジェクト指向の構造です。(コンポーネントとしてモデリングされるため): サブシステムはインスタンスを持つことができます (設計者がそのように指定した場合)。グローバルな変数と手続きのグループを UML でモデル化するもう 1 つの方法としてユーティリティーがあります。ユーティリティーはクラスのステレオタイプで、インスタンスはありません。 

製品を表すためにサブシステムを定義する場合は、製品のインターフェースを表現するために 1 つ以上のインターフェースも定義します。

サブシステム依存関係に関する制限 ページの先頭へ

(UML コンポーネントとしてモデリングされた) 設計サブシステムは、セマンティクス上はパッケージとは異なります。サブシステムは、実現する 1 つ以上のインターフェースを介して振る舞いを提供します。パッケージは振る舞いを備えていません。パッケージは、振る舞いを提供するものの単なるコンテナーです。

パッケージの代わりにサブシステムを使用するのは、サブシステムは内容をカプセル化し、インターフェースを通じてのみ振る舞いを提供するためです。これによる利点は、パッケージと異なり、サブシステムのインターフェースが一貫している限り、サブシステムの内容と内部の振る舞いをまったく自由に変更できることです。サブシステムは、「置き換え可能な設計」要素も提供します。同じインターフェース (または <<specification>> コンポーネント) を実現する任意の 2 つの <<realization>> コンポーネントは、交換可能です。

サブシステムがモデルの置換可能な要素であるためには、次に示すいくつかのルールに従う必要があります。

  • サブシステムは、内容の公開を最小限にしなければなりません。理想的には、サブシステムに含まれる要素は public の可視性を持ってはならず、したがってサブシステムの外部の要素はサブシステム内部の特定の要素の存在に依存しません。ただし、例外がいくつかあります。
    • 一部の技術については、サブシステムの外部を UML インターフェースとしてモデル化することはできません。例えば、Java インターフェースはステレオタイプ化されたクラスとしてモデル化します。
    • サブシステム設計では、UML インターフェースではなくクラスの公開が必要になる場合があります。 例えば、「委譲」クラスまたは「アクセス」クラスを使って、他のクラスの複雑なコラボレーションを隠すことができます。代わりに通常のパッケージを使用することもできますが、サブシステムを使えば、振る舞いをカプセル化して内部の詳細を隠す意図を強調することができます。

  • サブシステムの外部が UML インターフェースではない場合は、サブシステムの可視要素を示すダイアグラム (「外部ビュー」のような名前) を作成すると役に立つことがよくあります。
  • サブシステムでは、サブシステム・インターフェースでの依存関係を定義する必要があります (および、前記の例外ケースにおけるサブシステムの public 可視要素)。さらに、複数のサブシステムが、共通のインターフェース定義またはクラス定義のセットを共有できます。その場合、これらのサブシステムは、共通要素が含まれるパッケージの内容を「インポート」します。これは、アーキテクチャーの下層レイヤーのパッケージではいっそう一般的であり、サブシステム間で受け渡す必要のあるクラスの共通定義の一貫性を保証します。

サブシステムとパッケージの依存関係の例を次に示します。

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

設計モデルにおけるサブシステムとパッケージの依存関係

サブシステムの仕様と実現ページの先頭へ

定義 ページの先頭へ

UML ([UML04]) では、次のように定義されています。

コンポーネントに適用される複数の UML 標準のステレオタイプが存在します。例えば、<<specification>> および <<realization>> は仕様および実現を明確に定義してコンポーネントをモデリングします。1 つの仕様が複数の実現を持つ場合もあります。

<<specification>> でステレオタイプ化されるコンポーネントでは、オブジェクトのドメインを指定し、オブジェクトの物理的な実装は定義しません。 規定されるインターフェースおよび必要なインターフェースのみを持ち、実現する任意のクラスおよびサブコンポーネントを定義の一部として持つことは意図していません。

<<realization>> でステレオタイプ化されるコンポーネントでは、オブジェクトのドメインを指定し、オブジェクトの物理的な実装も定義します。 例えば、<<realization>> でステレオタイプ化されるコンポーネントでは、 独立した <<specification>> コンポーネントが指定する振る舞いを実装する、実現するクラスおよびサブコンポーネントのみを持ちます。

仕様と実現の分離は、本質的に、サブシステムの 2 つの異なる記述に対応します。仕様は、サブシステムを使用するためにクライアントが知る必要のあるすべてのことを定義する契約として機能します。実現は、実装担当者の手引きとなる詳細な内部設計です。 複数の実現をサポートする場合は、異なる「実現」サブシステムを作成し、各実現サブシステムから仕様サブシステムに実現を描画します。

使用する時と方法 ページの先頭へ

サブシステムの内部状態と振る舞いが比較的単純である場合は、公開するインターフェース、振る舞いを記述するステートチャート図、および説明文でサブシステムを指定すれば十分な場合があります。

さらに複雑な内部状態と振る舞いの場合は、分析クラスを使用して、高レベルの抽象表現でサブシステムを指定できます。大きなシステムの場合は、サブシステムの仕様にもユース・ケースが含まれることがあります。『Rational Unified Process による大規模システムの開発』を参照してください。

以下のような場合は、実現とは別に詳細な仕様を用意するのが最も有効であることがよくあります。

  • サブシステムの実現の内部状態と振る舞いが複雑であり、クライアントが有効に使用するためには、できる限り簡潔に仕様を表現する必要がある。
  • サブシステムが、複数のシステムに組み込むための再利用可能な「構成コンポーネント」である (『概念: コンポーネント』を参照)。
  • サブシステムの内部を、別の組織が開発すると予想される。
  • サブシステムの複数の実装を作成する必要がある。
  • 外部から見える振る舞いは同じで内部が大幅に変更される別バージョンによって、サブシステムが置き換えられることが予想される。

ただし、サブシステムの実現と仕様を整合させておく必要があるため、独立した仕様を維持するには大きな労力が必要です。独立した仕様クラスと実現クラスおよびコラボレーションを、どのような場合に、どのような方法で作成するのかを示す条件を、../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有ガイドラインで定義する必要があります。

依存関係ページの先頭へ

仕様では、依存関係を定義する必要があります。依存関係は、他のサブシステムとパッケージから見える要素およびインターフェースであり、サブシステムのすべての準拠する実現で利用できなければなりません。

実現には、設計者または実装担当者によって導入された追加の依存関係がある場合があります。例えば、ユーティリティー・コンポーネントを使用して実装を簡単にできる場合がありますが、このようなユーティリティー・コンポーネントの使用は、クライアントに対して公開する必要のない細部です。このような追加依存関係は、実現の一部として、独立したダイアグラムで把握する必要があります。

実装に対する関係ページの先頭へ

細部まで完全に記述された仕様では、サブシステムを使用するためにクライアントが必要とするすべてのものが定義されています。これは、コードと 1 対 1 になるように、公開されるインターフェースおよび public 可視性の要素を調節することを意味します。サブシステムの振る舞いを指定するために導入された分析クラスは、サブシステムの実現からは独立していることが意図されているので、高レベルの抽象に留めておく必要があります。

サブシステムの実現要素は、コードと密接に関係付ける必要があります。

このトピックについて詳しくは、『概念: 設計のコードへのマッピング』を参照してください。

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

モデリング

設計サブシステムは、UML 2.0 のコンポーネントまたは UML 1.5 のサブシステムとしてモデリングすることができます。 これらの構造では、モジュール性、カプセル化、実行時に実行可能なインスタンスといった、ほぼ同等のモデリングの機能を備えています。

これらのモデリングのオプションには、さらに以下の考慮事項があります。

  • UML 1.5 のサブシステムには、「仕様」および「実現」の表記法が明示的に含まれます (前述の『サブシステムの仕様と実現』で定義されています)。UML 2.0 コンポーネントは、仕様 (1 つ以上の規定されるまたは必要なインターフェースとして) および実現 (振る舞いを実現する 1 つ以上のクラスおよびサブコンポーネントから構成される内部実装) の表記法をサポートしています。
  • UML 1.5 のサブシステムは、パッケージでもありました。UML 2.0 のコンポーネントには、パッケージ化の機能があります。これは、大規模なモデル要素のセットを所有したりインポートしたりできるということを意味します。

ただし、全体として見れば、これらの表記は置き換えて使うことができます。「設計サブシステム」を UML 1.5 サブシステムと UML 2.0 コンポーネントのどちらで表現するかは、プロセス/プロジェクト用にカスタマイズした../artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト固有のガイドラインの中で文書化する必要のある決定事項です。

ビジュアル・モデリング・ツールが UML 1.5 パッケージはサポートしていても UML 1.5 サブシステムはサポートしていない場合は、パッケージ・ステレオタイプ <<subsystem>> を使用してサブシステムを表記できます。

サブシステム依存関係に関する制限

サブシステム依存関係に関する制限』の依存関係の制限と記述は、UML 1.5 のサブシステムとしてモデリングされる設計サブシステムにも適用されます。

UML 1.5 のサブシステムとパッケージの依存関係の例を次に示します。

 

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

設計モデルにおけるサブシステムとパッケージの依存関係

サブシステムの仕様と実現

UML 1.5 では、以下のように規定しています。

サブシステムの内容は、1) 仕様要素と 2) 実現要素という 2 つのサブセットに分かれる。
仕様要素は、サブシステムの操作と受信と共に、実現要素によって提供される振る舞いの
抽象仕様を示すために使用される。実装要素の集合は、物理システムの振る舞い単位の
内部をモデル化する。

仕様と実現の分離は、本質的に、サブシステムの 2 つの異なる記述に対応します。仕様は、サブシステムを使用するためにクライアントが知る必要のあるすべてのことを定義する契約として機能します。実現は、実装担当者の手引きとなる詳細な内部設計です。

仕様と実現のモデリングがモデリング環境で直接サポートされていない場合の 1 つのオプションは、各サブシステムの中に仕様と実現の 2 つのパッケージを設けることです。

仕様の 1 つの利点は、複数の実現をサポートしていることです。これは、UML 1.x では直接サポートされていません。UML 1.5 のサブシステムを使用して複数の実現をサポートする場合は、別個の「実現」サブシステムを作成し、各実現サブシステムから仕様サブシステムに実現を図示します。

基本的に、UML 2.0 に適用されるの同様の、仕様と実現についての考慮事項がここでも適用されます (詳しくは、『使用する時と方法』、『依存関係』、および 『実装に対する関係』を参照してください)。

追加情報

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

Rational Unified Process   2003.06.15