ガイドライン: ユース・ケースの汎化
トピック
親ユース ケースは、親をより限定された形で表す子ユース ケースによって特化されます。親ユース ケースも子ユース ケースも必ずしも抽象的ではありませんが、親ユース ケースはほとんどの場合、抽象的です。子ユース ケースは親ユース ケースの構造、振る舞い、関係をすべて継承します。同じ親を持つ子ユース ケースはすべて、親ユース ケースを特化したものです。これは、ユース ケースに適用できる汎化です (「ガイドライン: 汎化」も参照してください)。
汎化は、振る舞い、構造、目的に共通点のある 2 つの異常なユース ケースがある場合に行われます。この場合、共通部分を新しい、またしばしば抽象的なユース ケースで説明でき、子ユース ケースによって特化されます。
例:

ユース ケース「電話注文」と「インターネット注文」は抽象ユース ケース「注文」の特化されたものです。
「注文管理」システムでは、ユース ケース「電話注文」と「インターネット注文」の間に多くの構造と振る舞いの共通点があります。一般的なユース ケース「電話注文」は、構造と基本的な振る舞いが定義されるときに定義されます。抽象的なユース ケース「注文」は単独で完成されている必要はありませんが、一般的な振る舞いのフレームワークが提供され、子ユース ケースによって完成されるようにします。
親ユース ケースは、常に抽象的であるとは限りません。
例:
前出の例の「注文管理」システムを検討します。顧客に代わってシステムに注文を入力する「注文登録係」アクターを追加するとします。このアクターによって一般的なユース ケース「注文」が開始されます。この時点では、ユース ケースにはこれを表す完全なイベントのフローが備わっています。子ユース ケースでは、親から継承した構造に振る舞いを追加でき、また親の振る舞いを変更できます。

アクター「注文登録係」により、一般的なユース ケース「注文」を具体化できます。「注文」はまた、ユース ケース「電話注文」と「インターネット注文」によって特化されます。
子ユース・ケースは、親ユース・ケースの構造に依存しています (「ガイドライン: ユース・ケース」のイベント・フローの構造に関する説明を参照)。子ユース・ケースで、継承した振る舞いに振る舞いのセグメントを挿入したり、包含関係や拡張関係を宣言したりすることで、親ユース・ケースの振る舞いを追加できます。また、子ユース・ケースでは、継承した振る舞いのセグメントを変更できます。この場合、親ユース・ケースの目的を変えてしまわないように注意する必要があります。親ユース・ケースの構造は、子ユース・ケースによって保たれます。つまり、親ユース・ケースのイベントのフローのステップまたはサブフローで表された振る舞いのセグメントはすべて保たれる一方で、その内容は子ユース・ケースによって変更される場合があるということです。
親ユース ケースが抽象的なものである場合、その振る舞いのセグメントは不完全なものである可能性があります。この場合、不完全な振る舞いのセグメントは子ユース ケースによって埋め合わされ、アクターにとって意味のあるものとなるようにしなければなりません。
親ユース ケースが抽象的なユース ケースである場合、アクターと関係を持つ必要はありません。
2 つの子ユース ケースによって同一の親ユース ケース (あるいは基底ユース ケース) が特化されている場合、この特化は互いに独立しており、異なるユース ケースのインスタンス単位で実行されます。この点は、同じ基底ユース ケースを実行する 1 つのユース ケースのインスタンスが、複数の追加によって暗示的、明示的に変更される包含関係や拡張関係とは異なります。
ユース ケースの汎化と包含は共に、モデルのユース ケースにおける振る舞いの再利用に使用できます。この 2 つは、ユース ケースの汎化においては子ユース ケースの実行は親の構造や振る舞い (再利用部分) に依存し、包含関係では基底ユース ケースの実行は包含ユース ケース (再利用部分) によって実行される機能の結果にのみ依存するという点で異なります。また、ユース ケースの汎化では子ユース ケースが類似の目的と構造を備えているのに対し、包含関係では同一の包含を再利用する基底ユース ケースがまったく異なる目的を備えている場合があります (この場合、同一の機能を備えている必要があります)。
子ユース ケースを実行するユース ケースのインスタンスにより、または親ユース ケースに対して定義されたイベントのフローに従い、子ユース ケースに対して定義されたイベントのフローのとおりに追加の振る舞いが挿入され、また振る舞いが変更されます。

ユース ケースのインスタンスにより、親ユース ケースに従って子ユース ケースで説明されているとおりに振る舞いが挿入されたり、振る舞いが変更されます。
一般に、汎化関係自体を記述することはありません。その代わりに、子ユース ケースのイベントのフローにおいて、継承された振る舞いへの新しい手順の挿入方法を定義し、また継承された振る舞いの変更方法を指定します。
子ユース ケースによって複数の親が特化されている場合 (複数継承)、子ユース ケースにおいて、親の振る舞いのシーケンスが子にインターリーブされる方法を明示的に定義する必要があります。
次のような、簡単な電話システムのユース ケースの段階的な概要を検討します。
ローカルの呼び出し
- 発信者が受話器をとる。
- システムが発信音を出す。
- 発信者が電話番号の 1 つ目を押す。
- システムが発信音を停止する。
- 発信者が電話番号の残りをすべて押す。
- システムによって電話番号が分析される。
- システムによって通話先が特定される。
- システムによって通話者同士が接続される。
- 通話者が電話を切る。
長距離の呼び出し
- 発信者が受話器をとる。
- システムが発信音を出す。
- 発信者が電話番号の 1 つ目を押す。
- システムが発信音を停止する。
- 発信者が電話番号の残りをすべて押す。
- システムによって電話番号が分析される。
- システムによって別のシステムに電話番号が送信される。
- システムによって通話者同士が接続される。
- 通話者が電話を切る。
青で示した記述部分は、2 つのユース・ケースの類似部分を表します。2 つのユース・ケースが非常に類似している場合、代替サブフローで市内通話と長距離通話の相違が示される部分までを 1 つに統合することを考慮すべきです。
相違がある程度大きな物であり、ユース ケース モデルに市内通話と長距離通話の関係を明確に示す値がある場合、共通する振る舞いを分離して「電話をかける」という新しい一般的なユース ケースを作成できます。
ユース ケース図において、作成された汎化関係は次のように表されます。

ユース ケース「市内電話をかける」と「長距離電話をかける」により、抽象的なユース ケース「電話をかける」が継承されます。
|