ガイドライン: 拡張関係
トピック
拡張関係によって、拡張ユース ケースを基底ユース ケースに接続します。基底ユース ケースにある拡張ポイントを参照することによって、拡張を挿入する位置を定義します (「ガイドライン: ユース ケース」の拡張ポイントに関する解説を参照)。通常は、拡張ユース ケースは抽象ですが、必ずしも抽象である必要はありません。
拡張を使用する目的を次に示します。
- ユース ケースの一部が、オプションのシステムの振る舞い、またはオプションになる可能性のあるシステムの振る舞いであることを提示します。これにより、モデルのオプションの振る舞いを、必須の振る舞いから分離します。
- サブフローが、警報のトリガといった特定の (時には例外的な) 状況においてのみ実行されることを示します。
- 基底ユース ケースの拡張ポイントに挿入できる 1 つ以上の振る舞いセグメントを含む、振る舞いのセグメントのセットが存在する可能性があることを示します。挿入される振る舞いセグメント (および挿入される順序) は、基底ユース ケースの実行時におけるアクターとの相互作用によって決まります。
拡張は条件付きです。つまり、その実行は、基底ユース ケースの実行中に発生したことに依存します。基底ユース ケースは拡張を実行する条件を制御しません。条件は、拡張関係内に記述されています。拡張ユース ケースは、基底ユース ケースの属性にアクセスして変更できます。一方、基底ユース ケースからは拡張は見えず、属性にアクセスすることはできません。
基底ユース ケースは、拡張によって暗黙的に変更されます。基底ユース ケースは、拡張を追加できるモジュラー フレームワークを定義するとも言えます。ただし、基底ユース ケースには特定の拡張への可視性はありません。
基底ユース ケースは、それ自体で完結している必要があります。つまり、拡張を参照することなしに、理解可能で、有意義である必要があります。ただし、基底ユース ケースは、拡張から完全には独立してはいません。拡張に従う可能性なしには実行できないからです。
例:

ユース ケース「電話会議」と「発信者番号表示」は、どちらも「通話」という基底ユース ケースの拡張です。
電話システムでは、ユーザーに提供されている基本サービスは、ユース ケース「通話」で表されます。オプションのサービスの例を示します。
基底ユース ケースである「通話」への拡張ユース ケースとして、これらのオプション サービスに必要な振る舞いを表現できます。これが、拡張関係の正しい使用方法です。「通話」はそれ自体が意味を持っているので、基底ユース ケースの主要目的を理解するために拡張ユース ケースの記述を読む必要はなく、拡張ユース ケースはオプションの特性を備えています。
基底ユース ケースと「基底に拡張を加えた」ユース ケースを両方とも明示的にインスタンス化する必要がある場合、または基底ユース ケースの振る舞いを変更するために追加が必要な場合は、代わりにユース ケースの汎化を使用します (「ガイドライン: ユース ケースの汎化」を参照)。
拡張ユース ケースは 1 つ以上の挿入セグメントで構成できます。各セグメントの内部には、代替パスが組み込まれている場合があります。これらの挿入セグメントは、基底ユース ケースの振る舞いをインクリメンタルに変更します。拡張ユース ケースの各挿入セグメントは、基底ユース ケースの独立した位置に挿入できます。つまり、拡張関係には、拡張ポイントの参照リストがあり、この数は、拡張ユース ケースにある挿入セグメントの数と一致します。各拡張ポイントを、基底ユース ケースで定義する必要があります。
1 つの基底ユース ケースを、複数の拡張関係から構成することができます。つまり、ユース ケースのインスタンスが、その生涯において複数の拡張に従うことが可能です。1 つの拡張ユース ケースをいくつかの基底ユース ケースへと拡張できます。ただし これは、基底ユース ケース間に依存関係があるという意味ではありません。同じ拡張ユース ケースと基底ユース ケース間に、複数の拡張関係を作ることもできます。拡張を、基底の異なる位置に挿入すればよいのです。つまり、異なる拡張関係は、基底ユース ケースの異なる拡張ポイントを参照する必要があります。拡張、包含、汎化関係においては、拡張ユース ケース自体が基底になることもできます。たとえば、拡張ユース ケースがほかの拡張ユース ケースをネスト式に拡張できます。
ユース ケースのインスタンスが基底ユース ケースを実行して、基底ユース ケース内で拡張ポイントが定義された位置に達すると、対応する拡張関係の条件が評価されます。条件が真またはない場合は、ユース ケース インスタンスは拡張 (またはその拡張ポイントに対応する挿入セグメント) に従います。拡張関係の条件が偽の場合は、拡張は実行されません。
拡張ユース ケースは、ほかのユース ケースと同様、基本イベント フローと代替イベント フローを持つ場合があります (「ガイドライン: ユース ケース」のイベント フローの構造に関する説明を参照)。ユース ケースのインスタンスが拡張内でたどる正確なパスは、実行中それまでに発生したこと (ユース ケース インスタンスの状態) によって決定されます。また、拡張の実行中にアクターとの相互作用で発生したことによっても決定されます。ユース ケースのインスタンスが拡張を終了したら、ユース ケースのインスタンスは基底ユース ケースの実行を、中断された位置から再開します。

基底ユース ケースおよびその拡張に従うユース ケースのインスタンス
拡張ユース ケースは、複数の挿入セグメントを持つことができ、各セグメントは基底ユース ケースにあるそれぞれの拡張ポイントに関係します。この場合、ユース ケースのインスタンスは基底ユース ケースを再開し、拡張関係によって指定された次の拡張ポイントまで続行します。そのポイントで、拡張ユース ケースの次の挿入セグメントを実行します。最後の挿入セグメントの実行を終えるまで、これを繰り返します。拡張関係のための条件がチェックされるのは、最初の拡張ポイントだけであることに注意してください。条件が真のとき、ユース ケースのインスタンスは全挿入セグメントを実行する必要があります。

基底ユース ケースと拡張ユース ケース (挿入セグメントが 2 個所) に従うユース ケースのインスタンス
拡張関係の多重度に従って、拡張全体で発生する繰り返しの回数が制限されます。1 つの挿入セグメントだけではなく、拡張全体が繰り返される (および多重度によって制限される) ことに注意してください。
拡張の条件を、基底ユース ケースの属性という点から記述します。条件を省略することもできます。その場合、拡張は常に実行されます。
各拡張関係には、基底ユース ケースにある拡張ポイントの参照リストがあります。拡張ポイントは名前によって参照されます。拡張ユース ケースに複数の挿入セグメントがある場合、セグメントが対応する拡張ポイントを指定する必要があります。各挿入セグメントを構成する拡張ユース ケースのステップ、またはサブフローの指定も必要です。
例:
電話システムでは、ユース ケース「通話」を抽象ユース ケース「発信者番号表示」によって拡張できます。これは通常は「ナンバー ディスプレイ」と呼ばれている追加サービスであり、受信者が契約している場合もしていない場合もあります。「発信者番号表示」から「通話」への拡張関係の記述を次に示します。
条件: 呼び出し先が「発信者 ID」サービスを注文済みである。
拡張ポイント (複数可):「ID の表示」 - 者番号表示」ユース ケース全体を挿入。
拡張関係には多重度を指定できます。指定しないと、多重度は 1 つであると見なされます。
次に示す、単純な電話システムを考えてみましょう。

抽象ユース ケース「電話会議」は、ユース ケース「通話」に対する拡張です。
このモデルでは、家庭の電話システムを単純に表現しました。基本通話サービスは、ユース ケース「通話」に記述されています。イベントの基本フローまでのステップごとの概要例を次に示します。
- 呼び出し元が受話器を上げます。
- システムが発信音を流します。
- 呼び出し元が 1 桁の数字をダイヤルします。
- システムが発信音を止めます。
- 呼び出し元が残りの番号を入力します。
- システムは数字を分析し、呼び出し先のネットワーク アドレスを確定します。
- システムは数字を分析し、呼び出し先が存在するネットワーク上の位置を確定します。
- その後システムは呼び出し先に仮想回線を確立できるかを判断します。
- 仮想回線を確立できる場合は、システムが呼び出し先の電話を鳴らし、呼び出し元の電話に呼び出し音を流します。
- 呼び出し先が電話に出ると、システムは呼び出し元の電話の呼び出し音を停止し、呼び出し先の呼び出し音を止め、仮想回路を完成します。
- システムは、通話の開始時刻と終了点、呼び出し元の顧客情報を記録し、請求記録を開始します。
- しばらくの間、通話が続きます。呼び出し元または呼び出し先が電話を切ると、システムは通話の終了時刻を記録し、仮想回線のサポートに必要だった全リソースを解放します。ユース ケースはこの時点で終了します。
このシステムに、呼び出し元か呼び出し先が第三者を通話に接続できる機能 (しばしば「電話会議」と呼ばれる) を追加するには、イベントのフローに振る舞いを追加する必要があり ます。まず考慮すべき代替案は、「通話」に相違を直接挿入することです。このような相違は、代替イベント フローを使ってモデル化できます。「ガイドライン: ユース ケース」を参照してください。このソリューションはほとんどの単純な追加に有効であり、追加される機能によってユース ケースの元の意義が混乱したり不明瞭になったりすることはありません。もう 1 つの代替案は、基底ユース ケースを拡張する「発信者番号表示」という名前の抽象拡張ユース ケースに相違を分けることです。
「通話」ユース ケースには、以下の追加があります。
拡張ポイント: 「電話会議」はステップ 11 の後で発生します。
拡張ユース ケース「電話会議」は次のように記述されます。
「電話会議」ユース ケース 「通話」は、このユース ケースによって拡張され、拡張ポイント「電話会議」に挿入されます。 基本的なフロー: 1. 呼び出し元が、切断ボタン、リンク ボタン、またはフラッシュ ボタンを押します。 2. 確認のためにシステムから短いビープ音が 3 回鳴ります。
3 ~ 12. <これらのステップは、基底ユース ケースのステップ 3 ~ 12 と同じです。> 13. 呼び出し元は、「通話」ユース ケースから受信側に再接続します。
拡張ユース ケースのステップ 3 ~ 12 が基底ユース ケースステップ 3 ~ 12 と共通しているのは、好ましくありません。これを解決する 1 つの方法は、共通部分を包含ユース ケースとして処理することです (「ガイドライン: 包含関係」を参照)。
|