作業:
|
目的
|
|
役割: 設計者 | |
頻度: サブシステムの設計ごとに 1 回。 | |
手順 | |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: | |
More Information: | |
ワークフローの詳細: |
目的 | サブシステムの内部的な振る舞いを指定する。 サブシステムの振る舞いに関する要求を満たすのに必要な、新しい設計クラスまたは設計サブシステムを識別する。 |
サブシステムの振る舞いがどのように実現されるかを示すシーケンス図を使用して、サブシステム内のモデル要素のコラボレーションを文書化する必要があります。サブシステムが実現するインターフェースに対する各操作には、1 つ以上の文書によるシーケンス図がなければなりません。このダイアグラムはサブシステムによって所有され、サブシステムの内部的な振る舞いを設計するために使用されます。
サブシステムの振る舞いが状態に強く依存し、1 つ以上の制御スレッドを表す場合は、通常、サブシステムの振る舞いの説明には状態マシンのほうが便利です。このコンテキストでの状態マシンは通常、アクティブ クラスと共に使用され、システム (この場合はサブシステム) の制御スレッドの分解を表し、ステートチャート図で説明されます。「ガイドライン: ステートチャート図」を参照してください。
サブシステム内には、独立した実行スレッドがある場合があります。これはアクティブ クラスによって表現されます。
例:
システムの必要な振る舞いを実行するためのサブシステムのコラボレーションは、次のように、シーケンス図を使用して表現できます。
このダイアグラムは、シナリオを実行するために、サブシステムのインターフェースがどのように使用されるかを示しています。特に、ネットワーク処理サブシステムについては、サブシステムがサポートしなければならない特定のインターフェース (この場合は ICoordinator) と操作があります。また、ネットワーク処理サブシステムが、IBHandler インターフェースと IAHandler インターフェースに依存していることもわかります。
次のサブシステムの中を見ると、ICoordinator インターフェースがどのように実現されているかがわかります。
Coordinator クラスは、ICoordinator インターフェースの「プロキシー」として機能し、インターフェースの操作の処理とインターフェースの振る舞いの調整を行います。
この「内部」シーケンス図は、どのクラスがそのインターフェースを提供しているか、サブシステムの機能を提供するには内部的に何が発生する必要があるか、どのクラスがサブシステムからメッセージを送信しているかを、正確に示しています。 このダイアグラムは、内部設計を明確にするもので、複雑な内部設計を持つサブシステムには不可欠です。 また、このダイアグラムによって、サブシステムの振る舞いがわかりやすくなり、複数のコンテキスト間で再利用できる可能性があります。
これらの「インターフェース実現」図を作成する場合、必要な振る舞いを実行する新しいクラスやサブシステムを作成することが必要になる場合があります。 このプロセスは、ユース・ケース分析で定義されるプロセスに類似していますが、ここでは、ユース・ケースの代わりに、インターフェースの操作を取り扱います。 各インターフェースの操作について、現在のサブシステム内のクラス (必要な振る舞いが複雑な場合は包含されるサブシステム) を識別します。これらのクラスは、操作を実行するために必要です。 既存のクラス/サブシステムが必要な振る舞いを提供できない場合は、新しいクラス/サブシステムを作成します (ただし、まず再利用を試みます)。
新しい設計要素を作成するときは、サブシステムの内容と境界を再検討する必要があります。2 つの異なるサブシステム内に、実質的に同じクラスが存在しないように注意します。このようなクラスの存在は、サブシステムの境界がうまく区切られていない可能性があることを意味します。サブシステムの責務のバランスを取り直すために、作業: 設計要素の識別を定期的に再確認してください。
サブシステムの 2 つの異なる内部モデルを作成すると便利な場合があります。つまり、サブシステムのクライアントを対象にした仕様と、実装担当者を対象にした実現です。 仕様では、「理想的な」クラスとコラボレーションを含め、理想的なクラスとコラボレーションの観点から、サブシステムの振る舞いを説明する場合があります。 一方、実現は、より実装に近い部分に対応し、最終的に実装に進化する場合があります。 設計サブシステムの仕様と実現について詳しくは、 ガイドライン: 設計サブシステムのサブシステムの仕様と実現を参照してください。
目的 | サブシステムの内部構造を文書化する。 |
サブシステムの内部構造を文書化するため、サブシステムによって包含される要素や、要素間の互いの関連を示すクラス図を 1 つ以上作成します。1 つのクラス図で十分なはずですが、より単純化し、読みやすくするために、複数のダイアグラムを使用することもできます。
次にクラス図の例を示します。
注文入力システムのクラス図の例
コンポーネントとしてモデリングすると、サブシステムの内部構造は、コンポーネント図内で四角形の中に表すこともできます。このように表すことによって、このサブシステムとシステムの他の部分との相互作用ポイントを記せるようにもなります。これは、インターフェースを介して行われます。
以下は、コンポーネント図の一例です。この図では、注文サブシステムとその内部の構造、および提供される必須インターフェースが示されています。
注文サブシステムのコンポーネント図の例
コンポーネントは構造化クラスであるため、 構造化クラスの外部からのコミュニケーションが宣言済みのインターフェースに従ってポートを通過するように強制することにより、カプセル化を促進できます。これにより、そのコンポーネントの指定の精度が向上し、相互接続が実現されます。 このように表すことで、コンポーネントの実装の中で特定の役割を果たすように、 コネクターを経由して各部分のインスタンスを「繋げる」ことができます (詳しくは、概念: 構造化クラスを参照してください)。
以下は、インターフェースとポートを使用した注文サブシステムの複合構造図の一例です。
注文サブシステムの複合構造図の例
また、サブシステムの潜在的な状態を文書化するために、ステートチャート図が必要な場合があります。「ガイドライン: ステートチャート図」を参照してください。サブシステム自体に包含されるクラスの説明は、作業: クラス設計にあります。
目的 | サブシステムが依存するインターフェースを文書化する。 |
あるサブシステムによって包含される要素が、別のサブシステムによって包含される要素の振る舞いを使用する場合、それらの要素を包含しているサブシステムの間に依存関係が作成されます。再利用を推進し保守の依存関係を減らすために、ここでは、サブシステム自体やサブシステムに含まれる要素への依存関係ではなく、サブシステムの特定のインターフェースへの依存関係として、これを表現します。
これには次の 2 つの理由があります。
依存関係の作成では、あるサブシステムに含まれるモデル要素と別のサブシステムに含まれるモデル要素の間に、直接の依存関係やその他の関連がないようにします。また、サブシステムとインターフェースの間に、循環依存関係もないようにします。サブシステムは、1 つのインターフェースの実現とそれへの依存の両方を行うことはできません。
サブシステム間の依存関係と、サブシステムとパッケージの間の依存関係は、次に示すように直接結ぶことができます。このように表現される場合、この依存関係は、1 つのサブシステム (請求管理など) が別のサブシステム (支払スケジュール管理) に直接依存していることを示しています。
直接の依存関係を使用したサブシステム レイヤリングの例
あるサブシステムと別のサブシステム (どちらも同じインターフェースを持つ場合) を入れ替える可能性がある場合、その依存関係は、サブシステム自体にではなく、そのサブシステムによって実現されるインターフェースに結ぶことができます。 これにより、同じインターフェースを実現するほかのモデル要素 (サブシステムやクラス) を使用することができます。 インターフェースの依存関係を使用すると、置き換えが可能な設計要素を使用して、柔軟なフレームワークを設計できます。
インターフェースの依存関係を使用したサブシステム レイヤリングの例
直接の依存関係を使用したサブシステム レイヤリングの例
インターフェースの依存関係を使用したサブシステム レイヤリングの例
詳しくは、UML 1.x と UML 2.0 の相違を参照してください。
Rational Unified Process
|