ガイドライン: ユース・ケース
トピック
上の定義に使用されているキーワードを下に説明します。
- ユース ケース インスタンス: この定義においてシーケンスと呼ぶのは、実際にはシステムの中の特定のイベント フローまたはインスタンスです。イベント フローは多数あり、それらの中には類似したものが数多くあります。ユース ケース モデルを理解できるようにするには、類似したイベント フローを 1 つのユース ケースにグループ化する必要があります。ユース ケースを明確にして記述することは、実際には関連するイベント フローのグループを明確にして記述することになります。
- システムの遂行: これはシステムがユース ケースを提供することを意味します。アクターはシステムのユース ケースと情報を交換します。
- 結果として明確に認められる値:成功裏に遂行されたユース ケースには値を付与できます。ユース ケースでは、識別可能な値を持つタスクをアクターが遂行できるようにする必要があります。このことは、ユース ケースの適切なレベルまたは粒度を決定する上で、非常に重要です。適切なレベルとはあまり小さすぎないユース ケースを遂行することを指します。状況によっては、システム内のアクターである個人が含まれる組織における、計画単位としてユース ケースを使用できます。
- アクション: アクションは計算またはアルゴリズムのプロシージャです。アクションが起動されるのは、アクターがシステムにシグナルを与えたときか、またはシステムが時間イベントを入手したときです。アクションは呼び出し元のアクターまたはほかのアクターのどちらかにシグナルを送ることがあります。アクションは不可分です。つまり、アクションは完全に実行されるか、またはまったく実行されないかの、どちらかです。
- 特定のアクター: アクターは正しいユース・ケースを見つけ出すための鍵となります。特に、アクターは大きすぎるユース・ケースを避ける助けとなります。例として、ビジュアル・モデリング・ツールを考えてみましょう。このアプリケーションには実際には 2 人のアクターがいます。開発者はツールを利用して、システムを開発します。システム管理者はツールを管理します。これらの各アクターはシステムに対する独自の要求を保持しており、したがって独自の一連のユース・ケースを必要とします。
システムの機能は、種々のユース ケースによって定義されます。個々のユース ケースは特定のイベント フローを表します。ユース ケースの記述は、それを実行するとシステム内で何が発生するかを定義します。

たとえば、ATM を使用して、顧客は口座から現金を払い戻したり、口座に現金を送金したり、口座の残高照会をします。これらの機能は流れを形成しており、それをユース ケースとして表すことができます。
各ユース ケースには遂行すべき独自のタスクがあります。ユース ケースを集めたものはシステムを使用するために可能なすべての方法を構成します。ユース ケースの名称を見るだけで、そのタスクを推測できます。
ユース ケースを明確にする際に役に立つ一連の質問を下に列挙します。
- 明確にした各アクターに、システム的などんなタスクがありますか。
- アクターはシステム内のある一定の出来事について知らされる必要がありますか。
- 突然外部的な変化が発生した場合、アクターはシステムに知らせる必要がありますか。
- システムはビジネスに正しい振る舞いを提供しますか。
- 明確にしたユース ケースによってすべての機能を遂行できますか。
- どのようなユース ケースによってシステムはサポートされメンテナンスされますか。
- システム内でどのような情報を作成または修正する必要がありますか。
よく見過ごされるユース ケースがありますが、その理由は、ユース ケースの中には、システムの主要な機能を表さないものがあるからです。そのようなユース ケースには下記の種類があります。
- システムの起動と停止
- システムのメンテナンス。たとえば、新規ユーザーの追加やユーザー プロフィールの設定。
- システム内に格納されているデータのメンテナンス。たとえば、システムが従来のシステムと並列的に動作する場合に、両システム間でデータの同期を取ること。
- システム内の振る舞いを修正するために必要な機能。たとえば、レポートの新規作成機能などがその例です。
推敲の初期の反復期間においては、(アーキテクチャ上重要であるとみなされる) 少数のユース ケースだけを概説を越えてある程度詳細に記述します。まず第一にユース ケースの概要を (ステップ バイ ステップのフォーマットで) 開発してから、詳細を調べるようにします。ステップバイステップで概要を把握することが、ユース ケースのイベント フローの構造 (「イベント フロー - 構造」を参照) を定義する最初の試みでなければなりません。必ず、ユース ケースの基本フローから着手するようにします。基本フローの概要についてある程度の合意が得られたら、基本フローに対する代替フローを追加できます。
推敲の終了までに、詳細に記述するよう計画したすべてのユース ケースを完成させます。
モデル内のユース ケースの中には、非常に単純であるためにイベント フローを詳細に記述する必要のないものがよくあります。そのようなユース ケースについては、ステップバイステップの概要で十分です。そのように判断する基準は、ユース ケースが意味することに関して読者ユーザーの間に意見の不一致が認められず、ステップ バイ ステップのフォーマットによって示される詳細さのレベルは、設計者とテスト担当者にとっても作業がしやすいことです。そのような例として、システムへの簡単なデータの入力またはシステムからの簡単なデータの検索を表すユース ケースが挙げられます。
ユーザーとシステム間の一連の相互作用または対話が 1 つのユース ケースであるのか、それともいくつかのユース ケースから構成されるのかの判定が困難なことがよくあります。リサイクル マシンを使用する例を考えてみましょう。顧客が空き缶や空き瓶、空き箱などのリサイクル アイテムをリサイクル マシンに投入します。すべての物を投入し終えたら、顧客はボタンを押します。すると、受領証が印刷されます。顧客はその受領証を換金できます。
リサイクル アイテムをリサイクル マシンに投入するのが 1 つのユース ケースであり、受領証を受け取るのは別のユース ケースでしょうか。それとも、両方で 1 つのユース ケースなのでしょうか。アクションは 2 つありますが、どちらか一方だけでは、顧客にとって価値はありません。むしろ、リサイクル アイテムをリサイクル マシンに投入して受領証を受け取ること全体で完全な対話となるのであり、それが顧客にとって価値 (および意味) のあることなのです。つまり、最初のリサイクル アイテムを投入することからボタンを押して受領証を受け取るまでが完全な使用例であり、ユース ケースとなります。
それに加えて、2 つのアクションを一緒にまとめておいた方がよいでしょう。それによって、両者を同時にレビューしたり、一緒に修正、テストしたり、また、同時にマニュアルに記載することで、一般に 1 つの単位として管理できます。大規模なシステムにおいては、このことが非常に重要になります。
ユース ケースは、アクターがシステムと対話しながらそれを実行したときに、システム内で何が起こるかを表します。ユース ケースは、コラボレーション オブジェクトの観点から、システムが内部的にタスクをどのように実行するかを定義するものではありません。それはユース ケースの実現に委ねられます。
例:
電話を例に取ると、ユース ケースによって示されることは、受話器が持ち上げられるとシステムが送信音を出すこと、その後システムはダイヤルされた番号を受け取り、通話先を見つけ出して通話先のベルを鳴らし、回線を接続し、通話を確立させる、というふうになります。
実行中のシステムにおいて、ユース ケースのインスタンスは実装モデル (たとえば、コード内のクラスのインスタンス) 内のある特定のオブジェクトには対応しません。逆に、ユース ケースのインスタンスは、アクターによって起動され一連のオブジェクト間のイベントのシーケンスとして実行される、特定のイベント フローに対応します。言い換えると、ユース ケースのインスタンスは、実装されたオブジェクトのコミュニケーション インスタンスに対応します。このことをユース ケースの実現と呼びます。同一のオブジェクトが複数のユース ケースの実現に参加することがよくあります。たとえば、銀行システムにおいて、「預金」と「払い戻し」の 2 つのユース ケース が、その実現において同じ口座オブジェクトを使用することがあります。このことは 2 つのユース ケースが通信し合うことを意味するわけではなく、単にそれらのユース ケースの実現において、同じオブジェクトが使用されるだけです。
イベント フローはいくつかのサブフローから構成されるものと見ることができます。それらのサブフローをまとめると、全体としてイベント フローとなります。ほかのユース ケースのイベント フロー中のサブフローの記述を再利用できます。あるユース ケースのイベント フローの記述内にあるサブフローがほかのユース ケースでも一般的に使用される可能性があります。設計において、関連するすべてのユース ケースに関して、この共通の振る舞いを同じオブジェクトに遂行させるようにすべきです。つまり、どのユース ケースで実行されようとも、一組のオブジェクトのみがこの振る舞いを遂行するようにすべきです。
例:
ATM システムにおいて、「払い戻し」と「残高照会」の 2 つのユース ケースのイベント フロー内の最初のサブフローは同じです。どちらのユース ケースのイベント フローも、キャッシュ カードを受け付けて身元を確認し暗証番号をチェックすることから始まります。
ユース ケース インスタンスが取り得るパスの数は事実上無限ですが、現実には列挙し得ます。それらのパスは、イベント フロー内に記述されているユース ケース インスタンスに関して取り得る選択肢を表します。実際にはイベントに応じてパスが選択されます。イベントには下記のタイプがあります。
- アクターからの入力: たとえば、アクターは、次に何を行うべきかをいくつかのオプションの中から指定できます。
例:
リサイクル マシン システムの「リサイクル アイテム」ユース ケースでは、顧客には常に 2 つのオプションがあります。さらに別のリサイクル アイテムを投入するか、投入したリサイクル アイテムの受領証を受け取るかです。
- 内部的なオブジェクトまたは属性の値またはタイプのチェック。たとえば、入力された値が任意の値よりも大きいか小さいかによって、イベント フローが変わる可能性があります。
例:
ATM システムの「払い戻し」ユース ケースにおいて、顧客が残高以上の額を要求した場合、イベント フローは通常とは違ってきます。したがって、ユース ケース インスタンスは別のパスを辿ることになります。
システムの状況が許せば、いくつかのユース・ケースのインスタンスと同一ユース・ケースのいくつかのインスタンスが並列的に動作可能です。ユース・ケース・モデリングにおいて、いくつかのユース・ケースのインスタンスが競合することなく並列的に動作すると想定できます。ユース・ケース・モデリングでは、動作の仕組みを記述しないため、この問題は設計モデルによって解決されることが期待できます。このことを見る 1 つの方法は、一時点では 1 つのユース・ケースのインスタンスだけがアクティブであり、そのインスタンスを実行することは不可分なアクションであると想定することです。ユース・ケース・モデリングにおいては、「解釈マシン」の速さは無限であるとみなされるので、ユース・ケースのインスタンスのシリアル化は問題になりません。
各ユース ケースには、アクターとの対話によって何が遂行されるかを示す名称を付けるべきです。理解を助けるために、名称の長さは数語に及ぶことがあります。複数のユース ケースに同じ名称を付けることはできません。
例:
リサイクル マシンの「リサイクル アイテム」ユース ケースを例にとった、名称の変形の例を下に示します。
- デポジット アイテムの受け入れ
- デポジット アイテムを受け入れる
- デポジット アイテムの返却
- デポジット アイテム
ユース ケースの概要にはその目的を反映させます。説明を記述するにつれて、そのユース ケースに参加するアクターや用語に言及し、必要があれば新しい概念を定義します。
例:
リサイクル マシン システムの「リサイクル アイテム」と「新しい瓶タイプの追加」の 2 つのユース ケースの概要の例を下に示します。
リサイクル アイテム: ユーザーはこのマシンを使用して、返却するすべてのリサイクル アイテム (瓶、缶、箱) の数を自動的に数えてもらい、受領証を受け取ります。受領証をキャッシャー (機械) で換金できます。
新しい瓶タイプの追加: 新しい瓶タイプをこのマシンに追加するためには、マシンを「学習モード」で起動し、普通どおりにサンプルを 5 つ投入します。これによって、マシンはサンプルを測定し、それらの識別方法を学習します。新しい瓶タイプへの返金額は管理者が指定します。
ユース ケースのイベント フローには、ユース ケース モデリング作業から導出された、最も重要な情報が含まれています。イベント フローには、部外者が容易に理解できるように、ユース ケースのイベント フローを十分明白に記述すべきです。イベント フローで表すべきことは、システムは何を行うかであって、必要な振る舞いを得るためのシステムの設計方法ではないことを忘れないようにしてください。
イベント フローの内容に関するガイドラインを下に示します。
- ユース ケースを開始、終了させる方法を記述します。
- アクターとユース ケースとの間でどのようなデータが交換されるかを記述します。
- ユーザー・インターフェースの詳細は記述しません。ただし、システムの振る舞いを理解するために必要な場合は例外です。たとえば、アプリケーションが Web をベースにしたものであることが事前にわかっている場合には、Web に固有の用語の一部を限定的に使用することは、多くの場合差し支えありません。そうでない場合、ユース・ケースの説明が抽象的であると受け取られる危険があります。使用してもよい用語は「移動」、「参照」、「ハイパーリンク」、「ページ」、「送信」、「ブラウザー」などです。「フレーム」や「Web ページ」という用語を、それらの違いが理解されているように想定して使用することは、勧められません。その適用を決めることは設計上の重要事項です。
- 機能だけではなく、イベント フローを記述します。それを確実に行うために、各アクションの書き出しを、"アクターが・・・した場合"というようにします。
- ユース ケースに属するイベントのみを記述するようにし、ほかのユース ケースまたはシステムの外部で発生することは記述しないようにします。
- 「たとえば」、「その他」、「情報」などの、あいまいな用語は使用しないようにします。
- イベント フローを詳細に記述し、"何を"という質問にすべて答えるようにします。テスト設計者はこの説明を見てテスト ケースを設定することを忘れないようにしてください。
ある用語を複数のユース ケースで使用する場合、正確に同じ用語を同じ意味で使用するようにします。一般的な用語を管理するために、それらを用語集に収録します。
イベント フローには、基本イベント フローと 代替イベント フローの、2 つの主要な部分があります。基本イベント フローでは、ユース ケースが実行されると、"通常"何が起こるかを取り上げます。代替イベント フローでは、通常の振る舞いではないオプションまたは例外的な振る舞いと通常の振る舞いの変形を取り上げます。代替イベント フローは基本イベント フローの"バイパス"と考えられます。その中には、基本イベント フローに戻るものもあれば、ユース ケースの実行を終わらせるものもあります。

イベント フローの典型的な構造。直線は基本イベント フローを表し、曲線は通常のフローに対する代替イベント フローを表します。代替イベント フロー中には、基本イベント フローに戻るものもあれば、ユース ケースの終わりに至るものもあります。
基本イベント・フローと代替イベント・フローの両方をさらにステップまたはサブフローに分解します。こうすることによって、説明文が読みやすくなります (「イベント・フロー - スタイル」の項も参照)。経験則として、サブフローはユース・ケースの振る舞いのうち、目的が明白な 1 セグメントであって「不可分な」ものとします。ここで、不可分とは、記述されているアクションのすべてが実行されるか、何も実行されないかの、どちらかであるということです。サブフローを何レベルかに分ける必要がある場合でも、説明文の複雑さと理解しにくさが増大するので、可能な限り、それは避けるべきです。イベント・フローの構造は、アクティビティー図で図解することができます。詳細は、「ガイドライン: ユース・ケースのアクティビティー図」を参照してください。
項目を順々に記述する構造を取るこの種の説明では、読者は自然とサブフローの間に順序があるものと暗黙的に受け取るでしょう。誤解を避けるために、サブフローの順序が固定的であるか否かを、必ず指摘するようにした方がよいでしょう。この種の考慮は下記の事項と関連していることがよくあります。
- ビジネス ルール: たとえば、ユーザーは認証を受けてからでないと、システムのデータを利用できません。
- ユーザー インターフェイスの設計: たとえば、一部の人には直観的にわかるがほかの人にはわからないような、一連の振る舞いを強制してはなりません。
代替イベント フローがイベント フロー構造のどこに当てはまるかを明らかにするために、基本イベント フローの各"バイパス"に下記の説明を加える必要があります。
- 基本イベント フローのどこに代替イベント フローを挿入できるか。
- 代替イベント フローを開始するために満たされる必要がある条件。
- 基本イベント フローがどこからどのようにして再開されるか、またはユース ケース をどのように終了させるか。
例:
これは、リサイクル マシン システムの「リサイクル アイテムの返却」ユース ケースにおける代替サブフローです。
2.1. 瓶が詰まった場合
1.5 項「リサイクル アイテムの挿入」において瓶が投入口に詰まった場合、投入口と測定部に設置されているセンサーによってこの問題が検知されます。すると、コンベヤ ベルトが停止し、オペレータを呼ぶ警報が発せられます。マシンは問題が解決されたことをオペレータから知らされるのを待ちます。その後、マシンは基本フローの 1.9 項から稼働を再開します。
上の例において、基本イベント フロー中の指定された位置に代替イベント フローが挿入されます。代替イベント フローの中には、複数の位置に挿入可能なものもあれば、基本イベント フローの任意の位置に挿入可能なものもあります。
例:
これは、リサイクル マシン システムの「リサイクル アイテムの返却」ユース ケースにおける代替サブフローです。
2.2. フロント パネルが外れた場合
誰かがリサイクル マシンのフロント パネルを外した場合、缶の圧縮が停止されます。フロント パネルが外れた状態で、缶の圧縮を開始することはできません。また、フロント パネルが外されると、オペレータへの警報も発せられます。フロント パネルが閉じられると、基本イベント フローが停止された位置から、マシンの運転が再開されます。
代替イベント フローが非常に単純な場合、それを基本イベント フローの記述の中に含めて (なんらかの "If-Then-Else" 構造を使用して) 記述したいという誘惑に駆られるでしょう。しかしそれは避けるべきです。代替イベント フローが多くなりすぎると、通常の振る舞いが見えにくくなります。また、基本イベント フローの中に代替イベント フローをいれると、説明が"擬似コード的"になり読みにくくなります。
一般に、イベント フローの一部を抽出して別立てで記述すると、基本イベント フローが読みやすくなり、ユース ケースとユース ケースモデルの構造が改善されます。抽出した部分を下記のようにモデル化できます。
- 基本イベント フローの単純な変形、オプション、または例外である場合、基底ユース ケース内の代替イベント フローとして。
- ほかのユース ケースで再利用できるようにカプセル化したい場合、基底ユース ケースへ明示的に包含するものとして (「ガイドライン: 包含関係」を参照)。
- 基底ユース ケースの基底イベント フローが完了している場合、つまり開始と終了が定義されている場合、基底ユース ケースへの暗黙的に包含するものとして (「ガイドライン: 拡張関係」を参照)。拡張するフローの性質は、複雑にならないように基底ユース ケースの記述の中に隠した方がよい、というようなものであるべきである。
- 上記のどれも当てはまらない場合、おそらく別のオプションとしての、基本イベント フロー内のサブフローが考えられる。たとえば、「社員情報のメンテナンス」ユース ケースには、社員情報を追加、修正、削除するための別々のサブフローがある可能性がある。
ユース ケースを記述するスタイルはたくさんあります。例として、「オーダーの管理」ユース ケースの基本イベント フローを 3 とおりのスタイルで記述したものを示します。それらの主な違いは形式的なところにあります。理解しやすく、物事が発生する順序が明白であるため、下の例 1 に示した最初のスタイルを奨励します。説明は項に分けられ、各項には番号と見出しが付けられています。番号が付けられているのは、参照先を見つけやすくするためです。項目に見出しが付いているので、読者は全体を通して見出しだけを拾い読みすることにより、イベント フローの概要を素早く知ることができます。
下の例 2 のイベント フローの記述には物事が発生する順序が明白に示されていません。このようなスタイルで記述すると、読者はシステムに関わる重要な事項を見落とす可能性があります。
下の例 3 はさらに別のスタイルを示しています。イベントの順序を明白に表現することが難しい場合に、このスタイルが役に立ちます。この擬似コード的なスタイルはより正確なものの、情報技術に詳しくない読者にとっては読みにくく理解しにくいもので、特にイベント フローを素早く明確したい場合に不向きです。
1.1. ユース・ケースの開始
アクター「オペレータ」がシステムに測定オーダーを作成する指示を出したときに、このユース ケースは開始されます。すると、システムはその「オペレータ」が利用可能なすべての「ネットワーク要素」アクター、その測定オブジェクト、対応する測定機能を検索します。利用可能なネットワーク要素とは、稼働していてそのオペレータがアクセス権限を保持しているものを指します。測定機能を使えるかどうかは、特定のタイプの測定オブジェクトに何が設定されているかによります。
1.2. 測定オーダーの設定
システムは、アクター「オペレータ」がどのネットワーク要素を測定するかを選択できるようにし、次いで選択されたネットワーク要素に関して利用可能な測定オブジェクトを示します。システムは、オペレータが測定オブジェクトを選択し、各測定オブジェクトに設定する測定機能を選択できるようにします。
システムは、オペレータが測定オーダーに注釈文を入力できるようにします。
オペレータは測定オーダーを完了するようにシステムに指示します。システムはそれに応答して、測定オーダーの固有名を生成し、測定の開始時期、頻度、期間に関するデフォルト値を設定します。デフォルト値はオペレータごとに固有です。システムはオペレータが自分のデフォルト値を編集できるようにします。
1.3. オーダーの初期化
オペレータは測定オーダーを初期化するようにシステムに指示します。システムはそれに応答して、測定オーダーの作成者のオペレータの身元、作成日、測定オーダーの"スケジュール済み"状態を記録します。
1.4. ユース ケースの終了
システムは測定オーダーが初期化されたことをオペレータに通知し、ほかのアクターがその測定オーダーを参照できるようにします。
|
ユース ケースの記述。このスタイルでは、説明は読みやすく、イベント フローも追いやすくなっています。このスタイルで記述するようにします。
オーダー作成者はネットワーク要素から測定データを収集するためのオーダーを作成できます。
システムはオーダーに固有の名称、測定の時間と長さと反復頻度を示すデフォルト値を割り当てます。オーダー作成者はそれらの値を編集できます。
オーダー作成者はさらに、使用する測定機能、対象とするネットワーク要素と測 定オブジェクトを指定する必要があります。オーダー作成者はオーダーに個人的な注釈を付けることもできます。
必要な情報が定義されたとき、新しいオーダーが作成されて、定義されている属性、作成者名、作成日を用いて初期化されます。オーダーの状態は"スケジュール済み"に設定されます。(具体的な状態には、スケジュール済み、実行中、完了済み、取消済み、エラーがあります。
新しいオーダーが作成されたこと、それを表示させるための参照情報が、ユー ザー インターフェイスに表示されます。
|
ユース ケースの記述。このスタイルは理解可能ですが、イベント フローが明確ではありません。
'Administrate order' (User identity)
REPEAT
<='Show administer order menu'
IF (=> 'Creating an Order' (Measurement function,
network element, measurement object)) THEN
The system finds a unique name, default values for when and
how long the measurement should be executed.
<= 'Show order' (Default attributes)
REPEAT
=> 'Edit order' (Attribute to change, New value of attribute)
<= 'Update screen' (New attributes)
UNTIL (All attributes are defined)
REPEAT
IF (=> 'Edit order' (Attribute to change, New value of attribute))
THEN <= 'Update screen' (New attributes)
ELSIF (=> 'Save order' (Order identity, Attributes)) THEN
The order is created and initialized in the system with
the defined attributes, the name of the creator,
date of creation and the status 'scheduled'.
<= 'New order created' (The order)
ENDIF
UNTIL (=> 'Quit')
ENDIF
UNTIL 'Quit administer order'
|
ユース ケースの記述。ここでは、ユース ケースの記述者は擬似コードを使用した形式スタイルを選択しました。このスタイルでは、プロセスのステップを素早く把握することは困難です。
ユース ケース「測定オーダーの管理」のイベント フローの完全な記述例を、代替フローも含めて、以下に示します。
1. 基本イベント フロー
1.1. ユース・ケースの開始
アクター「オペレータ」がシステムに測定オーダーを作成する指示を出したときに、このユース ケースは開始されます。すると、システムはその「オペレータ」が利用可能なすべての「ネットワーク要素」アクター、その測定オブジェクト、対応する測定機能を検索します。利用可能なネットワーク要素とは、稼働していてそのオペレータがアクセス権限を保持しているものを指します。測定機能を使えるかどうかは、特定のタイプの測定オブジェクトに何が設定されているかによります。
1.2. 測定オーダーの設定
システムは、アクター「オペレータ」がどのネットワーク要素を測定するかを選択できるようにし、次いで選択されたネットワーク要素に関して利用可能な測定オブジェクトを示します。システムは、オペレータが測定オブジェクトを選択し、各測定オブジェクトに設定する測定機能を選択できるようにします。
システムは、オペレータが測定オーダーに注釈文を入力できるようにします。
オペレータは測定オーダーを完了するようにシステムに指示します。システムはそれに応答して、測定オーダーの固有名を生成し、測定の開始時期、頻度、期間に関するデフォルト値を設定します。デフォルト値はオペレータごとに固有です。システムはオペレータが自分のデフォルト値を編集できるようにします。
1.3. オーダーの初期化
オペレータは測定オーダーを初期化するようにシステムに指示します。システムはそれに応答して、測定オーダーの作成者のオペレータの身元、作成日、測定オーダーの"スケジュール済み"状態を記録します。
1.4. ユース ケースの終了
システムは測定オーダーが初期化されたことをオペレータに通知し、ほかのアクターがその測定オーダーを参照できるようにします。
2. 代替イベント フロー
2.1. ネットワーク要素が利用可能でない場合
1.1「ユース ケースの開始」において、該当オペレータが測定に使用できるネットワーク要素がないと判明した場合、システムはそのことをオペレータに通知します。ユース ケースはこの時点で終了します。
2.2. 測定機能が利用できない場合
1.2「測定オーダーの設定」において、選択されたネットワーク要素に使用できる測定機能が存在しないと判明した場合、システムはそのことをオペレータに通知し、ほかのネットワーク要素を選択できるようにします。
2.3. 測定オーダーの取消
ユース ケースを実行中の任意の時点で、システムはオペレータがすべてのアクションを取り消せるようにします。その後、システムはユース ケースを起動する前の状態に復帰し、ユース ケースを終了します。
ユース ケースの特殊な要求には、イベント フローによってカバーされなかったユース ケースに関するすべての要求を記述します。それらは設計モデルに影響を与える機能外要求です。「ガイドライン: ユース ケース モデル」中の機能外要求に関する説明も参照してください。それらの要求を「使いやすさ」、「信頼性」、「性能」、「代替性」というように分類して編成することも可能ですが、通常、特殊な要求は非常に少ないので、そのように分類することによって特に付加価値が高まることはありません。
例:
リサイクル マシン システムの例において、「リサイクル アイテムの返却」ユース ケースに下記のような特殊な要求を付する場合があります。
マシンは 95% よりも高い信頼性でリサイクル品を認識できる必要があります。
事前条件と事後条件という概念を適用すると、イベント フローの開始と終了を明白にするのに役立つことがあります。ただし、ユース ケースの使用者によって付加価値があると認められる場合にのみ、この概念を利用するようにします。

事前条件とは、ユース ケースを開始する際に事前に必要となるシステムとその環境の状態であり、事後条件とはユース ケース終了後のシステムの状態です。
次の例を考慮します。
- 事前条件または事後条件に記述される状態は、ユーザーが観察できるものである必要があります。そのような例として、"ユーザーがシステムにログインを済ませている"、"ユーザーが該当の文書を開き終わっている"ことが挙げられます。
- 事前条件は、ユース ケースをいつ開始できるかに関する制約です。事前条件はユース ケースを開始させるイベントではありません。
- ユース ケースの事前条件はただ 1 つのサブフローの事前条件ではありません。ただし、サブフローのレベルで事前、事後条件を定義できます。
- ユース ケースの事後条件は、どの代替フローが実行されたかにかかわりなく、真となる必要があります。つまり、基本フロー以外のフローについても、ユース ケースの事後条件が真にならなければなりません。何か異常が起こり得る場合、それを事後条件でカバーします。たとえば、単に"アクションは完了しました"と言う代わりに、"アクションが完了しました、または何らかの異常があった場合、アクションは行われませんでした"と言うことができます。
- 事後条件と拡張関係を併用する場合、ユース ケースを拡張することが、基底ユース ケース内の事後条件に反するサブフローを組み込むことにならないように注意する必要があります。
- 事後条件は、ユース・ケースを記述するための強力なツールとなり得ます。最初にユース・ケースで達成しようとしていること、つまり事後条件を定義します。次に、その条件に達する方法 (必要なイベント・フロー) を記述できます。
例:
ATM マシンの「払い戻し」ユース ケースの事前条件: 顧客はカード リーダーで読みとれる自分のキャッシュ カードを持ち、暗証番号を割り当てられており、銀行システムに登録されていること。
ATM マシンの「払い戻し」ユース ケースの事後条件: ユース ケースの終了時点で、口座と取引ログのつじつまが合い、銀行システムとの通信が再初期化され、顧客にカードが戻されていること。
拡張点を使用すると、ユース ケースを拡張できる可能性が開けます。拡張点には名前が付けられ、ユース ケースのイベント フロー内の 1 か所以上の参照先が列挙されます。拡張点からユース ケース内の 2 つの振る舞いステップの間の 1 か所を参照できます。また、一連の個別の箇所を参照することもできます。
名前付きの拡張点を使用すると、拡張先のユース ケースの振る舞いの仕様を基底ユース ケースの内部的な詳細から分離するのに役立ちます。基底ユース ケースを修正または調整しても、拡張点の名前が同じである限り、拡張先のユース ケースは影響を受けません。同時に、基底ユース ケースのどこに振る舞いを拡張するかという詳細情報と共に、基底ユース ケースのイベント フローを記述しているテキストをダウンロードすることはありません。「ガイドライン: 拡張関係」も参照してください。
例:
電話システムにおいて、ユース ケース「送信」を抽象的なユース ケース「送信者番号を表示」で拡張できます。これは通常は"ナンバー ディスプレイ"と呼ばれている追加サービスであり、受信者が契約している場合もしていない場合もあります。ユース ケース「送信」内の拡張点の記述は下記のようになるでしょう。
名前: 送信者番号を表示
位置: 1.9「受信者の電話機のベルを鳴らす」の後
ユース・ケース図は、あるユース・ケースがアクターとほかのユース・ケースとどのように関係するかを図で示したものです (まれには複数のダイアグラムにわたることがあります)。ユース・ケースに多くのアクターが参加している場合、またはユース・ケースがほかの多くのユース・ケースと関係している場合に、このダイアグラムは役に立ちます。この種のダイアグラムは、1 つのユース・ケースの観点のみからユース・ケース・モデルを示しているだけであり、ユース・ケースモデル全体について全般的に説明するものではないため、"局所的"なものと言えます。詳しいガイダンスについては、「ガイドライン: ユース・ケース図」も参照してください。
|