目的
  • ユース・ケースの 1 つ以上のイベント・フローを、そこで開始するソフトウェア開発が可能になるほど十分な詳細さで記述する。
  • ユース・ケース仕様を、アクターの代表または顧客が理解および満足できるように記述する。
役割:  ユース・ケース定義者  
頻度:  反復ごとに 1 度。反復中に詳細化される各ユース・ケースまたは各ユース・ケース・フローについて。 
手順
More Information: 
入力とする成果物:     結果となる成果物:   
ツール・メンター:   

ワークフローの詳細:   

シナリオのレビューと詳細化 ページの先頭へ

初めに、開発サイクルの中で処理するシナリオのレビューと詳細化を行います。これらは既に「作業: ユース・ケースとアクターの獲得」で初期の識別がなされている場合があります。これらの列挙されたシナリオを、記述の必要があるフローの範囲を識別する際の開始点として利用します。

絵コンテは、ユース・ケース・フローの理解と詳細化に役立ちます。 ユーザー インターフェイス プロトタイプを既に開発済みの場合は、考慮すべきもう 1 つの入力になります。

イベント・フローの詳細化 ページの先頭へ

ここまでの作業で、ユース・ケースのイベント・フローに関する、簡単な、ステップごとの記述が作成されているはずです。この記述は、「作業: アクターとユース・ケースの獲得」で作成されています。このステップごとの概要を出発点にして、徐々に、より詳細にしていきます。

プロジェクトで決定した基準 に基づいて、ユース・ケースを記述します。すべてのユース・ケースが首尾一貫するように、記述をはじめる前に次の点を決定します。

  • ユース・ケースを開始する方法: ユース・ケースの始めには、ユース・ケースをアクティブにするシグナルを明確に記述します。たとえば、"…が起きたらユース・ケースを開始します"などのように記述します。
  • ユース・ケースを終了する方法: ユース・ケースを終了する、フロー内でのイベントを明確に記述します。たとえば、"…が起きたら、ユース・ケースを終了します"などのように記述します。
  • ユース・ケースがアクターと相互作用する方法: たとえば、何がシステム内にあり、何がシステムの外部にあるかなどの誤解が発生するリスクを最小にします。記述をいくつかの段落に構造化し、各段落でアクションを"アクターが…する時、システムは…する"の書式で記述します。また、ユース・ケースとアクター間のシグナルの送受信を記述して、相互作用を強調することもできます。たとえば、"オペレータから『開始』のシグナルを受けるとユース・ケースを開始します"などのようにします。
  • ユース・ケースがアクターとデータを交換する方法: 必要であればシグナル内の引数を参照することもできますが、たとえば"ユーザー名とパスワードを入力してシステムにログインするとユース・ケースが開始します"などのように記述することをお勧めします。
  • ユース・ケースで一部の振る舞いを繰り返す方法: これは、自然な言葉で表現するようにします。ただし、例外的な場合として、自然な言葉で表現するのが難しい場合、"WHILE-END WHILE"、"IF-THEN-ELSE"、および"LOOP-END LOOP"などのコードのような構文を使用することもできます。ただし一般的には、コードのような記述は読みにくく、維持も難しいため、ユース・ケースの記述では避けるようにします。
  • ユース・ケースのイベント・フローでの、オプション状況の有無: 場合によっては、アクターにいくつかのオプションがあります。 これは同じ方法で書かなければなりません。 たとえば:

    「アクターは次のうち 1 つを、1 回あるいは複数回選択します。」

    a) . . .

    b) . . .

    c) . . .

  • 顧客やユーザーが理解できるようにユース・ケースを記述する方法: ユース・ケースやシグナルなどの方法論の専門用語を使用すると、テキストが不必要に理解しにくくなることがあります。テキストを読みやすくするには、アクションを列挙するか、ほかの方策を採用します。採用する方策は、一般のユース・ケース モデリング ガイドラインに記述し、ユース・ケースの記述の作業全体において忘れずに使用するようにします。

ユース・ケースで何が行われるかを記述することに集中し、システム内の特定の問題をどのように解決するかについては記述しないようにします。オブジェクト モデルで作業する場合、どのように機能するかの詳細を補足しなければならない場合があります。このため、この時点では記述をあまり詳細にしないようにします。将来的に安定すると考えられるものに絞って記述します。

ユース・ケースのイベント・フローが過度に包括的または複雑になった場合、あるいは 相互に依存する部分があるように思える場合は、ユース・ケースを 2 つ以上に分割します。

説明文を書く場合には、用語集を参照します。新しい概念によって新しい用語が生まれた場合は、それらの用語も用語集に入れます。適切なプロジェクト メンバーに通知することなしに用語の定義を変更することは避けます。

イベント・フローの記述の内容

イベント・フローの記述には、次のような点があります。

  • ユース・ケースが開始する方法とタイミングはどうしますか。
例:

「このユース・ケースは、ユーザーによって「オーダー管理」がアクティブにされた場合に開始できます。」

  • ユース・ケースがアクターと相互作用するタイミングはいつですか、またどのデータを交換しますか。
例:

「新規注文を作成するには、ユーザーが機能「新規作成」をアクティブにし、次に注文に関する必須データ (名前、ネットワーク要素 (少なくとも 1 つ) および測定機能のタイプ) を指定します。 また、コメント (文字による短い説明) などの注文に関するオプションのデータを指定することもできます。 次に、機能「OK」をアクティブにすると、新規注文がシステムに作成されます。」

メモ: アクターとユース・ケース間のデータの交換については、明示的に記述します。明示的に記述しないと、顧客やユーザーがユース・ケースの記述を理解できなくなります。

  • ユース・ケースがシステム内に格納したデータをいつ、どのように使用しますか。また、システム内にデータを、いつ、どのように格納しますか。
例:

「ユーザーが既存の注文を編集するために「編集」機能をアクティブにし、注文番号 (小さな整数) を指定します。 システムにより注文書が初期化され、注文名、ネットワーク要素、および測定機能のタイプが指定されます。 このデータは、補助格納デバイスから取得されます。」

  • ユース・ケースを終了する方法とタイミングはどうしますか。
例:

「ユース・ケースは、機能「終了」が発注者によってアクティブにされた場合に終了します。」

また、イベント・フローの例外などについても記述します。例外のフローとは、ユース・ケースのサブフローで、ユース・ケースの通常のまたは基本的なフローに従わないフローのことです。ユース・ケースの振る舞いを完全な記述にするには、このフローを記述することがやはり必要です。例外フローの典型的な例は、最初の例に見ることができます。ユース・ケースが予想外のデータを受信した場合 (アクターが特定のコンテキストで予想したものではなかった場合)、ユース・ケースは終了します。予想外のアクターによって、尚早に終了するのは、典型的なイベント・フローではありません。

ユース・ケースを記述する際のこのほかの「注意点」としては、次のようなものがあります。

  • ユース・ケースの機能や目的だけではなく、イベント・フローも記述します。
  • ユース・ケースに属するフローのみを記述し、ユース・ケースで同時に何が行われているかは記述しないようにします。
  • 対象のユース・ケースと通信しないアクターについては言及しないようにします。
  • ユース・ケースとアクターの相互作用を記述する際には、あまり詳細にならないようにします。
  • ユース・ケースで記述したサブフローの順番を修正する必要がない場合は、修正する必要があるかのように記述しないようにします。
  • 共通の用語集に記載されている用語を使用し、次のような文章を書くように心がけます。
  • 簡単な言葉を使用します。簡単な言葉で済む場合は、複雑な言葉は使用しないようにします。
  • 短い、簡潔な文を書きます。
  • 「とても」「もっと」「むしろ」などの、副詞を使用しないようにします。
  • 適切な句読点を使います。
  • 重文は避けます。

詳細については、「ガイドライン: ユース・ケース」の、「イベント・フロー - 内容」および「イベント・フロー - スタイル」を参照してください。

イベント・フローの構造化 ページの先頭へ

イベントのユース・ケースのフローは、複数のサブフローに分割することができます。ユース・ケースがアクティブになっているときは、次の条件に合う場合には、サブフローをさまざまに組み合わせることができます。

  • ユース・ケースは、与えられたビジネス アクターからの入力、または属性もしくはオブジェクトの値に依存して、可能な複数のパスのうちの 1 つからたどることができます。たとえば、アクターがいくつかのオプションから次に何をするかを決定したり、値が一定の値より大きいか小さいかによってイベント・フローが異なる場合などがあります。
例:

ATM 機のユース・ケース「現金の引き出し」の部分として、次のような例が考えられます。「ユーザーが指定した金額を口座の残額と比較します。 指定した金額が残高を超える場合、ユーザーにその旨を示すメッセージが表示され、ユース・ケースは終了します。 残高が十分ある場合は、口座から現金を引き出します。」

  • ユース・ケースでは、いくつかのサブフローをオプションのシーケンスで実行できます。
  • ユース・ケースでは、複数のサブフローを同時に実行できます。

これらのオプションのフローまたは代替フローは、すべて記述しなければなりません。各サブフローを、イベント・フローの項への独立した補足として記述することをお勧めします。次の場合には、記述することが必須です。

  • 与えられたイベント・フローの大部分をサブフローが占める場合
  • 例外イベント・フロー: これにより、ユース・ケースの基本的なイベント・フローがはっきりとわかるようになります。
  • 同じイベント・フロー内で、さまざまな待ち時間で実行できるサブフロー

サブフローにかかわるのが、イベント・フロー全体のごく一部の場合は、テキストの本文に記述します。

例:

このユース・ケースは、アクター「注文者」またはアクター「パフォーマンス管理者」のいずれかによって「オーダー管理」機能が呼び出されると、アクティブになります。 シグナルがこれらのアクター以外から送られた場合、ユース・ケースによる操作は中止され、ユーザーに対し適切なメッセージが表示されます。 ただしアクターが認識された場合は、ユース・ケースは続行され……。

イベント・フローの構造は、アクティビティ図で図解することができます。詳しくは「ガイドライン: ユース・ケース モデルにおけるアクティビティ図」を参照してください。

詳しくは「ガイドライン: ユース・ケースの「イベント・フロー - 構造」」を参照してください。

アクターとほかのユース・ケースの関係の図解 ページの先頭へ

ユース・ケースと、アクターやほかのユース・ケースとの関係を示す、ユース・ケース図を作成します。このタイプのダイアグラムは、ユース・ケースの局所的なダイアグラムとして機能するものであり、関連がなければなりません。このような局所的ユース・ケース図は、ユース・ケースに説明の必要な拡張または内包の関係がある場合や、関連するアクターに並外れた複雑さがある場合以外には、概して小さな価値しかありません

詳しくは「ガイドライン: ユース・ケース図」を参照してください。

すべての特殊な要件の記述 ページの先頭へ

ユース・ケースに関係する要求で、ユース・ケースのイベント・フローで考慮されていないものは、ユース・ケースの「特殊な要求」に記述します。これらの要求は、多くの場合機能外要求です。

詳しくは「ガイドライン: ユース・ケースの「特殊な要求」」を参照してください。

通信プロトコルの定義 ページの先頭へ

別システムまたは外部ハードウェアである任意のアクターで使用される通信プロトコルを定義します。既存のプロトコル (特に認知されたプロトコルまたは標準とみなされるプロトコル) が使用される場合、ユース・ケースの記述は単にプロトコルの名前にしなければなりません。プロトコルが新規の場合は、オブジェクト モデル開発時に完全な説明が必要になるプロトコル定義が参照できる場所を特定しなければなりません。

事前条件の記述 ページの先頭へ

ユース・ケースの事前条件では、ユース・ケースを開始することを可能にするために必要な、システムの状態を説明します。

例:

ATM システムで現金を引き出すには、以下の事前条件を満たさなければなりません。

  • ATM ネットワークにアクセスできること
  • ATM 機がトランザクションを受け入れられる状態にあること
  • ATM 機に、引き出しに使用できる現金がいくらかあること
  • ATM 機に、少なくとも 1 つのトランザクション レコードを印刷するのに十分な紙があること

これらはすべて、ユース・ケース「現金の引き出し」に対して有効な事前条件です。

システムの状態を記述するにあたっては注意を払ってください。このユース・ケースに先立って起こったそのほかの偶発的なアクティビティを詳細に記述することは避けます。

事前条件は、ユース・ケースのシーケンス作成に使用するものではありません。 重要なイベント・フローを実現するために、まずあるユース・ケースを実行し、次に別のユース・ケースを実行しなければならないという状態にはなりません。 このような処理を行う必要があるのは、一般に、ユース・ケース・モデルが細かく分解されている場合です。 分解したユース・ケースを順番に 1 つのユース・ケースにまとめて、問題を解決してください。 これによって、出来上がったユース・ケースが複雑になった場合は、前述のユース・ケースのイベント・フローの構造化、または作業: ユース・ケース モデルの構成を参照してユース・ケースの構成を考えてください。 

詳しくは「ガイドライン: ユース・ケースの「事前条件と事後条件」」を参照してください。

事後条件の記述 ページの先頭へ

ユース・ケースの事後条件では、ユース・ケースの終了時点でシステムが取る可能性のある状態がリストされます。ユース・ケースの終了時には、システムはこれらの状態の 1 つになければなりません。また、ユース・ケース中に何が起こったかにかかわらず、ユース・ケースの最後でシステムによって実行されるアクションを記述するのにも使用します。

:

ATM 機で、ユース・ケースの終了時に常に「いらっしゃいませ」というメッセージを表示する場合、これはユース・ケースの事後条件に記述します。

同様に、発生したイベントにかかわらず、ATM 機でユース・ケースの最後に常に顧客のトランザクション (現金の引き出しなど) を閉じる場合、これをユース・ケースの事後条件に記述します。

事後条件は、ユース・ケースのイベント・フローを簡単、かつ読みやすくするために使用します。

どのような状況であっても、事後条件をユース・ケースのシーケンス作成に使ってはなりません。重要なイベント・フローを実現するために、まずあるユース・ケースを実行し、次に別のユース・ケースを実行しなければならないという状態にはなりません。このようなシーケンスが必要な場合は、依存するユース・ケースを 1 つのユース・ケースにまとめます。この結果、まとめたユース・ケースが複雑になりすぎる場合は、上記のガイドライン: ユース・ケースの「イベント・フロー - 構成」、または「作業: ユース・ケース モデルの構成」に説明されている、ユース・ケースの構成の技術を参考にしてください。

詳しくは「ガイドライン: ユース・ケースの「事前条件と事後条件」」を参照してください。

拡張ポイントの記述 ページの先頭へ

ユース・ケースを別のユース・ケースで拡張する場合 (ガイドライン: 拡張関係を参照)、拡張ポイントを記述する必要があります (ガイドライン: ユース・ケースの「拡張ポイント」を参照)。

結果の評価 ページの先頭へ

ユース・ケースについて利害関係者とレビューおよび討論し、利害関係者がユース・ケースをはっきりと理解し、その記述に合意することを確認します。

ユース・ケースの記述は、ユース・ケースで実行および実装されるもの、あるいはユース・ケースを最初から最後まで実行するのに必要なものをすべて記述した時点で完了します。 作業を終了する前に、ユース・ケースが「優良な」ユース・ケースの特徴を備えていることを確認します。 作業: 要求のレビューのユース・ケースに関するチェックポイントを参照してください。



Rational Unified Process   2003.06.15