目的
  • サブシステムのインターフェースで指定される振る舞いを、包含される設計要素と外部のサブシステム / インターフェースの観点から定義する。
  • サブシステムの内部構造を文書化する。
  • サブシステムのインターフェースと、包含されるクラスの間の実現を定義する。
  • ほかのサブシステムへの依存関係を判別する。
役割:  設計者 
頻度: サブシステムの設計ごとに 1 回。  
手順
入力とする成果物:     結果となる成果物:   
ツール・メンター:   
More Information: 

ワークフローの詳細:   

サブシステム要素へのサブシステムの振る舞いの分散 ページの先頭へ

目的 サブシステムの内部的な振る舞いを指定する。
サブシステムの振る舞いに関する要求を満たすのに必要な、新しい設計クラスまたは設計サブシステムを識別する。  

サブシステムの外部的な振る舞いは、主にサブシステムが実現するインターフェースによって定義されます。サブシステムはインターフェースを実現するとき、そのインターフェースによって定義される、すべての操作のサポートを確約します。各操作は、サブシステムによって包含される設計要素 (設計クラス設計サブシステム) に対する操作によって実現される場合があります。つまり、各操作はその他の設計要素とのコラボレーションが必要になる場合があります。

サブシステムの振る舞いがどのように実現されるかを示すシーケンス図を使用して、サブシステム内のモデル要素のコラボレーションを文書化する必要があります。サブシステムが実現するインターフェースに対する各操作には、1 つ以上の文書によるシーケンス図がなければなりません。このダイアグラムはサブシステムによって所有され、サブシステムの内部的な振る舞いを設計するために使用されます。

サブシステムの振る舞いが状態に強く依存し、1 つ以上の制御スレッドを表す場合は、通常、サブシステムの振る舞いの説明には状態マシンのほうが便利です。このコンテキストでの状態マシンは通常、アクティブ クラスと共に使用され、システム (この場合はサブシステム) の制御スレッドの分解を表し、ステートチャート図で説明されます。「ガイドライン: ステートチャート図」を参照してください。

サブシステム内には、独立した実行スレッドがある場合があります。これはアクティブ クラスによって表現されます。

例:

システムの必要な振る舞いを実行するためのサブシステムのコラボレーションは、次のように、シーケンス図を使用して表現できます。

付随するテキストで説明されているダイアグラム。

このダイアグラムは、シナリオを実行するために、サブシステムのインターフェースがどのように使用されるかを示しています。特に、ネットワーク処理サブシステムについては、サブシステムがサポートしなければならない特定のインターフェース (この場合は ICoordinator) と操作があります。また、ネットワーク処理サブシステムが、IBHandler インターフェースと IAHandler インターフェースに依存していることもわかります。

次のサブシステムの中を見ると、ICoordinator インターフェースがどのように実現されているかがわかります。

付随するテキストで説明されているダイアグラム。

Coordinator クラスは、ICoordinator インターフェースの「プロキシー」として機能し、インターフェースの操作の処理とインターフェースの振る舞いの調整を行います。

この「内部」シーケンス図は、どのクラスがそのインターフェースを提供しているか、サブシステムの機能を提供するには内部的に何が発生する必要があるか、どのクラスがサブシステムからメッセージを送信しているかを、正確に示しています。 このダイアグラムは、内部設計を明確にするもので、複雑な内部設計を持つサブシステムには不可欠です。 また、このダイアグラムによって、サブシステムの振る舞いがわかりやすくなり、複数のコンテキスト間で再利用できる可能性があります。

これらの「インターフェース実現」図を作成する場合、必要な振る舞いを実行する新しいクラスやサブシステムを作成することが必要になる場合があります。 このプロセスは、ユース・ケース分析で定義されるプロセスに類似していますが、ここでは、ユース・ケースの代わりに、インターフェースの操作を取り扱います。 各インターフェースの操作について、現在のサブシステム内のクラス (必要な振る舞いが複雑な場合は包含されるサブシステム) を識別します。これらのクラスは、操作を実行するために必要です。 既存のクラス/サブシステムが必要な振る舞いを提供できない場合は、新しいクラス/サブシステムを作成します (ただし、まず再利用を試みます)。

新しい設計要素を作成するときは、サブシステムの内容と境界を再検討する必要があります。2 つの異なるサブシステム内に、実質的に同じクラスが存在しないように注意します。このようなクラスの存在は、サブシステムの境界がうまく区切られていない可能性があることを意味します。サブシステムの責務のバランスを取り直すために、作業: 設計要素の識別を定期的に再確認してください。

サブシステムの 2 つの異なる内部モデルを作成すると便利な場合があります。つまり、サブシステムのクライアントを対象にした仕様と、実装担当者を対象にした実現です。 仕様では、「理想的な」クラスとコラボレーションを含め、理想的なクラスとコラボレーションの観点から、サブシステムの振る舞いを説明する場合があります。 一方、実現は、より実装に近い部分に対応し、最終的に実装に進化する場合があります。  設計サブシステムの仕様と実現について詳しくは、 ガイドライン: 設計サブシステムのサブシステムの仕様と実現を参照してください。

サブシステム要素の文書 ページの先頭へ

目的 サブシステムの内部構造を文書化する。  

サブシステムの内部構造を文書化するため、サブシステムによって包含される要素や、要素間の互いの関連を示すクラス図を 1 つ以上作成します。1 つのクラス図で十分なはずですが、より単純化し、読みやすくするために、複数のダイアグラムを使用することもできます。

次にクラス図の例を示します。

付随するテキストで説明されているダイアグラム。

注文入力システムのクラス図の例

コンポーネントとしてモデリングすると、サブシステムの内部構造は、コンポーネント図内で四角形の中に表すこともできます。このように表すことによって、このサブシステムとシステムの他の部分との相互作用ポイントを記せるようにもなります。これは、インターフェースを介して行われます。

以下は、コンポーネント図の一例です。この図では、注文サブシステムとその内部の構造、および提供される必須インターフェースが示されています。

付随するテキストで説明されているダイアグラム。

注文サブシステムのコンポーネント図の例

コンポーネントは構造化クラスであるため、 構造化クラスの外部からのコミュニケーションが宣言済みのインターフェースに従ってポートを通過するように強制することにより、カプセル化を促進できます。これにより、そのコンポーネントの指定の精度が向上し、相互接続が実現されます。 このように表すことで、コンポーネントの実装の中で特定の役割を果たすように、 コネクターを経由して各部分のインスタンスを「繋げる」ことができます (詳しくは、概念: 構造化クラスを参照してください)。

以下は、インターフェースとポートを使用した注文サブシステムの複合構造図の一例です。

付随するテキストで説明されているダイアグラム。

注文サブシステムの複合構造図の例

また、サブシステムの潜在的な状態を文書化するために、ステートチャート図が必要な場合があります。「ガイドライン: ステートチャート図」を参照してください。

サブシステム自体に包含されるクラスの説明は、作業: クラス設計にあります。

サブシステム依存関係の文書化 ページの先頭へ

目的 サブシステムが依存するインターフェースを文書化する。  

あるサブシステムによって包含される要素が、別のサブシステムによって包含される要素の振る舞いを使用する場合、それらの要素を包含しているサブシステムの間に依存関係が作成されます。再利用を推進し保守の依存関係を減らすために、ここでは、サブシステム自体やサブシステムに含まれる要素への依存関係ではなく、サブシステムの特定のインターフェースへの依存関係として、これを表現します。

これには次の 2 つの理由があります。

  • 2 つのモデル要素 (サブシステムを含む) が同じ振る舞いを提供する限り、1 つをもう 1 つと置き換えることができるようにする必要があります。インターフェースに関して必要な振る舞いを指定するので、あるモデル要素からほかのモデル要素に対する振る舞いに関するあらゆる要求は、インターフェースによって表現されることになります。
  • 正しい外部的な振る舞いを提供する限り、サブシステムの内部的な振る舞いの設計において、設計者に完全な自由を与える必要があります。あるサブシステム内のモデル要素が別のサブシステム内のモデル要素を参照する場合、設計者には、そのモデル要素を削除したり、そのモデル要素の振る舞いをほかの要素へ再分配する自由がなくなります。結果的にシステムが脆弱になります。

依存関係の作成では、あるサブシステムに含まれるモデル要素と別のサブシステムに含まれるモデル要素の間に、直接の依存関係やその他の関連がないようにします。また、サブシステムとインターフェースの間に、循環依存関係もないようにします。サブシステムは、1 つのインターフェースの実現とそれへの依存の両方を行うことはできません。

サブシステム間の依存関係と、サブシステムとパッケージの間の依存関係は、次に示すように直接結ぶことができます。このように表現される場合、この依存関係は、1 つのサブシステム (請求管理など) が別のサブシステム (支払スケジュール管理) に直接依存していることを示しています。


付随するテキストで説明されているダイアグラム。

直接の依存関係を使用したサブシステム レイヤリングの例

あるサブシステムと別のサブシステム (どちらも同じインターフェースを持つ場合) を入れ替える可能性がある場合、その依存関係は、サブシステム自体にではなく、そのサブシステムによって実現されるインターフェースに結ぶことができます。 これにより、同じインターフェースを実現するほかのモデル要素 (サブシステムやクラス) を使用することができます。 インターフェースの依存関係を使用すると、置き換えが可能な設計要素を使用して、柔軟なフレームワークを設計できます。


付随するテキストで説明されているダイアグラム。

インターフェースの依存関係を使用したサブシステム レイヤリングの例

 

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

UML 1.5 表記法を使用している場合は、サブシステム依存関係と同じ考慮事項が適用されます。


付随するテキストで説明されているダイアグラム。

直接の依存関係を使用したサブシステム レイヤリングの例

 

付随するテキストで説明されているダイアグラム。

インターフェースの依存関係を使用したサブシステム レイヤリングの例

 

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

Rational Unified Process   2003.06.15