ガイドライン:
|
|
詳細 |
---|---|
オプション度を求める | 特定のコラボレーション (またはサブコラボレーション) がオプションの振る舞いを表現する場合は、それをサブシステムに含めます。削除、アップグレード、または代替案と置換できる機能は、独立しているものと見なす必要があります。 |
システムのユーザー・インターフェースを求める | ユーザー・インターフェースが、システムのエンティティー・クラスから比較的独立している場合 (つまり、2 つが独立して変更可能であり、かつ変更される場合) は、水平方向に統合されたサブシステムを作成します。グループに関連するユーザー・インターフェース・バウンダリー・クラスを 1 つのサブシステムに、グループに関連するエンティティー・クラスをもう 1 つのサブシステムに統合します。 |
ユーザー・インターフェースとそれが表示するエンティティー・クラスが緊密に結合している場合 (つまり、片方における変更が、他方における変更を引き起こす場合) は、垂直方向に統合されたサブシステムを作成します。関連するバウンダリーとエンティティー・クラスを共通のサブシステムに含めます。 | |
アクターを求める | 2 つの異なるアクターに使用される機能を独立させます。各アクターが独立してシステムでの要求を変更する可能性があるためです。 |
外部のシステムまたはデバイスへのアクセスをカプセル化するサブシステムを作成します。 | |
設計要素間の結合と固着を求める | 高度に結合または固着したクラス/サブシステムは、サービスのセットを提供するためにコラボレートします。高度に結合した要素をサブシステムに編成し、結合が弱い線に沿って要素を分けます。よりまとまりの強い責務を持つ小さなクラスに分けることによって、またはサブシステムを適切に再分割することによって、弱い結合を完全に取り除くことが可能な場合もあります。 |
代用品を求める | 特定の機能について指定された、サービスのレベルが複数ある場合は (例えば、高、中、低可用性など)、各サービス・レベルを別個のサブシステムとして表し、それぞれが同じインターフェースのセットを実現します。これによって、サブシステムが相互に代用可能になります。 |
分散を求める | 特定のサブシステムの複合インスタンスが存在し、それぞれを異なるノードで実行できますが、多くのアーキテクチャーでは、コンポーネントを構成する 1 つのインスタンスを複数のノードにわたって分割することはできません。サブシステムの振る舞いがノードを超えて分散される必要がある場合は、機能的に制約のある小規模のサブシステムにサブシステムを分割することをお勧めします (そのそれぞれが単一コンポーネントを表します)。 各ノードに必須の機能を決定し、その機能を「所有する」新しいサブシステムを作成します。それに沿って、元のサブシステムの責務と関連要素を分散させます。 新しいサブシステムは、元のサブシステムにとって内部のものになります。 |
設計をサブシステムに編成したら、ユース・ケースの実現をそれに従って更新します。
設計サブシステムは、UML コンポーネントを使用してモデリングされます。これを構成すると、以下のモデリング機能が使用できます。
さらに以下の考慮事項があります。
注: UML 2.0 では、<<subsystem>> という名前のコンポーネントのステレオタイプが定義されており、例えば、大規模な構造を表すために使用できます。 RUP 設計サブシステムは、大規模な構造であることも、そうでないこともあります。いずれも、RUP の観点から見れば設計サブシステムです。この問題 (例えば、コンポーネントを合成したコンポーネントに <<subsystem>> というラベルをつけるかどうか) は、ソフトウェア・アーキテクトが決定すべき問題です。
既存製品がインターフェースつまり操作 (およびおそらく受信) をエクスポートするけれども、実装のそれ以外の詳細はすべて隠している場合は、論理ビューのサブシステムとしてモデル化される可能性があります。 サブシステムによって表現できる可能性があり、システムによって使用される製品の例には次のものがあります。
タイプとデータ構造の集合 (例えばスタック、リスト、クエリー) などのような一部の既存製品は、パッケージとして表現した方がよい場合があります。これらは振る舞い以上のものを表しており、重要で役立つものは、単なるコンテナーであるパッケージ自体ではなく、パッケージの具体的な内容だからです。
数値計算ライブラリーなどの共通ユーティリティーは、単にインターフェースをエクスポートするだけであれば、サブシステムとして表現できます。ただし、これが必要または有意義かどうかの判断は、モデル化する物の本質を設計者がどう判断するかによります。 サブシステムは、オブジェクト指向の構造です。(コンポーネントとしてモデリングされるため): サブシステムはインスタンスを持つことができます (設計者がそのように指定した場合)。グローバルな変数と手続きのグループを UML でモデル化するもう 1 つの方法としてユーティリティーがあります。ユーティリティーはクラスのステレオタイプで、インスタンスはありません。
製品を表すためにサブシステムを定義する場合は、製品のインターフェースを表現するために 1 つ以上のインターフェースも定義します。
(UML コンポーネントとしてモデリングされた) 設計サブシステムは、セマンティクス上はパッケージとは異なります。サブシステムは、実現する 1 つ以上のインターフェースを介して振る舞いを提供します。パッケージは振る舞いを備えていません。パッケージは、振る舞いを提供するものの単なるコンテナーです。
パッケージの代わりにサブシステムを使用するのは、サブシステムは内容をカプセル化し、インターフェースを通じてのみ振る舞いを提供するためです。これによる利点は、パッケージと異なり、サブシステムのインターフェースが一貫している限り、サブシステムの内容と内部の振る舞いをまったく自由に変更できることです。サブシステムは、「置き換え可能な設計」要素も提供します。同じインターフェース (または <<specification>> コンポーネント) を実現する任意の 2 つの <<realization>> コンポーネントは、交換可能です。
サブシステムがモデルの置換可能な要素であるためには、次に示すいくつかのルールに従う必要があります。
サブシステムとパッケージの依存関係の例を次に示します。
設計モデルにおけるサブシステムとパッケージの依存関係
UML ([UML04]) では、次のように定義されています。
コンポーネントに適用される複数の UML 標準のステレオタイプが存在します。例えば、<<specification>> および <<realization>> は仕様および実現を明確に定義してコンポーネントをモデリングします。1 つの仕様が複数の実現を持つ場合もあります。
<<specification>> でステレオタイプ化されるコンポーネントでは、オブジェクトのドメインを指定し、オブジェクトの物理的な実装は定義しません。 規定されるインターフェースおよび必要なインターフェースのみを持ち、実現する任意のクラスおよびサブコンポーネントを定義の一部として持つことは意図していません。
<<realization>> でステレオタイプ化されるコンポーネントでは、オブジェクトのドメインを指定し、オブジェクトの物理的な実装も定義します。 例えば、<<realization>> でステレオタイプ化されるコンポーネントでは、 独立した <<specification>> コンポーネントが指定する振る舞いを実装する、実現するクラスおよびサブコンポーネントのみを持ちます。
仕様と実現の分離は、本質的に、サブシステムの 2 つの異なる記述に対応します。仕様は、サブシステムを使用するためにクライアントが知る必要のあるすべてのことを定義する契約として機能します。実現は、実装担当者の手引きとなる詳細な内部設計です。 複数の実現をサポートする場合は、異なる「実現」サブシステムを作成し、各実現サブシステムから仕様サブシステムに実現を描画します。
サブシステムの内部状態と振る舞いが比較的単純である場合は、公開するインターフェース、振る舞いを記述するステートチャート図、および説明文でサブシステムを指定すれば十分な場合があります。
さらに複雑な内部状態と振る舞いの場合は、分析クラスを使用して、高レベルの抽象表現でサブシステムを指定できます。大きなシステムの場合は、サブシステムの仕様にもユース・ケースが含まれることがあります。『Rational Unified Process による大規模システムの開発』を参照してください。
以下のような場合は、実現とは別に詳細な仕様を用意するのが最も有効であることがよくあります。
ただし、サブシステムの実現と仕様を整合させておく必要があるため、独立した仕様を維持するには大きな労力が必要です。独立した仕様クラスと実現クラスおよびコラボレーションを、どのような場合に、どのような方法で作成するのかを示す条件を、成果物: プロジェクト固有ガイドラインで定義する必要があります。
仕様では、依存関係を定義する必要があります。依存関係は、他のサブシステムとパッケージから見える要素およびインターフェースであり、サブシステムのすべての準拠する実現で利用できなければなりません。
実現には、設計者または実装担当者によって導入された追加の依存関係がある場合があります。例えば、ユーティリティー・コンポーネントを使用して実装を簡単にできる場合がありますが、このようなユーティリティー・コンポーネントの使用は、クライアントに対して公開する必要のない細部です。このような追加依存関係は、実現の一部として、独立したダイアグラムで把握する必要があります。
細部まで完全に記述された仕様では、サブシステムを使用するためにクライアントが必要とするすべてのものが定義されています。これは、コードと 1 対 1 になるように、公開されるインターフェースおよび public 可視性の要素を調節することを意味します。サブシステムの振る舞いを指定するために導入された分析クラスは、サブシステムの実現からは独立していることが意図されているので、高レベルの抽象に留めておく必要があります。
サブシステムの実現要素は、コードと密接に関係付ける必要があります。
このトピックについて詳しくは、『概念: 設計のコードへのマッピング』を参照してください。
設計サブシステムは、UML 2.0 のコンポーネントまたは UML 1.5 のサブシステムとしてモデリングすることができます。 これらの構造では、モジュール性、カプセル化、実行時に実行可能なインスタンスといった、ほぼ同等のモデリングの機能を備えています。
これらのモデリングのオプションには、さらに以下の考慮事項があります。
ただし、全体として見れば、これらの表記は置き換えて使うことができます。「設計サブシステム」を UML 1.5 サブシステムと UML 2.0 コンポーネントのどちらで表現するかは、プロセス/プロジェクト用にカスタマイズしたプロジェクト固有のガイドラインの中で文書化する必要のある決定事項です。
ビジュアル・モデリング・ツールが UML 1.5 パッケージはサポートしていても UML 1.5 サブシステムはサポートしていない場合は、パッケージ・ステレオタイプ <<subsystem>> を使用してサブシステムを表記できます。
『サブシステム依存関係に関する制限』の依存関係の制限と記述は、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
|