作業:
|
目的
|
|
役割: ユース・ケース定義者 | |
頻度: 反復ごとに 1 度。反復中に詳細化される各ユース・ケースまたは各ユース・ケース・フローについて。 | |
手順
|
|
More Information: |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: |
ワークフローの詳細: |
初めに、開発サイクルの中で処理するシナリオのレビューと詳細化を行います。これらは既に「作業: ユース・ケースとアクターの獲得」で初期の識別がなされている場合があります。これらの列挙されたシナリオを、記述の必要があるフローの範囲を識別する際の開始点として利用します。
絵コンテは、ユース・ケース・フローの理解と詳細化に役立ちます。 ユーザー インターフェイス プロトタイプを既に開発済みの場合は、考慮すべきもう 1 つの入力になります。
ここまでの作業で、ユース・ケースのイベント・フローに関する、簡単な、ステップごとの記述が作成されているはずです。この記述は、「作業: アクターとユース・ケースの獲得」で作成されています。このステップごとの概要を出発点にして、徐々に、より詳細にしていきます。
プロジェクトで決定した基準 に基づいて、ユース・ケースを記述します。すべてのユース・ケースが首尾一貫するように、記述をはじめる前に次の点を決定します。
「アクターは次のうち 1 つを、1 回あるいは複数回選択します。」
a) . . .
b) . . .
c) . . .
ユース・ケースで何が行われるかを記述することに集中し、システム内の特定の問題をどのように解決するかについては記述しないようにします。オブジェクト モデルで作業する場合、どのように機能するかの詳細を補足しなければならない場合があります。このため、この時点では記述をあまり詳細にしないようにします。将来的に安定すると考えられるものに絞って記述します。
ユース・ケースのイベント・フローが過度に包括的または複雑になった場合、あるいは 相互に依存する部分があるように思える場合は、ユース・ケースを 2 つ以上に分割します。
説明文を書く場合には、用語集を参照します。新しい概念によって新しい用語が生まれた場合は、それらの用語も用語集に入れます。適切なプロジェクト メンバーに通知することなしに用語の定義を変更することは避けます。
イベント・フローの記述には、次のような点があります。
「このユース・ケースは、ユーザーによって「オーダー管理」がアクティブにされた場合に開始できます。」
「新規注文を作成するには、ユーザーが機能「新規作成」をアクティブにし、次に注文に関する必須データ (名前、ネットワーク要素 (少なくとも 1 つ) および測定機能のタイプ) を指定します。 また、コメント (文字による短い説明) などの注文に関するオプションのデータを指定することもできます。 次に、機能「OK」をアクティブにすると、新規注文がシステムに作成されます。」
メモ: アクターとユース・ケース間のデータの交換については、明示的に記述します。明示的に記述しないと、顧客やユーザーがユース・ケースの記述を理解できなくなります。
「ユーザーが既存の注文を編集するために「編集」機能をアクティブにし、注文番号 (小さな整数) を指定します。 システムにより注文書が初期化され、注文名、ネットワーク要素、および測定機能のタイプが指定されます。 このデータは、補助格納デバイスから取得されます。」
「ユース・ケースは、機能「終了」が発注者によってアクティブにされた場合に終了します。」
また、イベント・フローの例外などについても記述します。例外のフローとは、ユース・ケースのサブフローで、ユース・ケースの通常のまたは基本的なフローに従わないフローのことです。ユース・ケースの振る舞いを完全な記述にするには、このフローを記述することがやはり必要です。例外フローの典型的な例は、最初の例に見ることができます。ユース・ケースが予想外のデータを受信した場合 (アクターが特定のコンテキストで予想したものではなかった場合)、ユース・ケースは終了します。予想外のアクターによって、尚早に終了するのは、典型的なイベント・フローではありません。
ユース・ケースを記述する際のこのほかの「注意点」としては、次のようなものがあります。
詳細については、「ガイドライン: ユース・ケース」の、「イベント・フロー - 内容」および「イベント・フロー - スタイル」を参照してください。
イベントのユース・ケースのフローは、複数のサブフローに分割することができます。ユース・ケースがアクティブになっているときは、次の条件に合う場合には、サブフローをさまざまに組み合わせることができます。
ATM 機のユース・ケース「現金の引き出し」の部分として、次のような例が考えられます。「ユーザーが指定した金額を口座の残額と比較します。 指定した金額が残高を超える場合、ユーザーにその旨を示すメッセージが表示され、ユース・ケースは終了します。 残高が十分ある場合は、口座から現金を引き出します。」
これらのオプションのフローまたは代替フローは、すべて記述しなければなりません。各サブフローを、イベント・フローの項への独立した補足として記述することをお勧めします。次の場合には、記述することが必須です。
サブフローにかかわるのが、イベント・フロー全体のごく一部の場合は、テキストの本文に記述します。
このユース・ケースは、アクター「注文者」またはアクター「パフォーマンス管理者」のいずれかによって「オーダー管理」機能が呼び出されると、アクティブになります。 シグナルがこれらのアクター以外から送られた場合、ユース・ケースによる操作は中止され、ユーザーに対し適切なメッセージが表示されます。 ただしアクターが認識された場合は、ユース・ケースは続行され……。
イベント・フローの構造は、アクティビティ図で図解することができます。詳しくは「ガイドライン: ユース・ケース モデルにおけるアクティビティ図」を参照してください。
詳しくは「ガイドライン: ユース・ケースの「イベント・フロー - 構造」」を参照してください。
ユース・ケースと、アクターやほかのユース・ケースとの関係を示す、ユース・ケース図を作成します。このタイプのダイアグラムは、ユース・ケースの局所的なダイアグラムとして機能するものであり、関連がなければなりません。このような局所的ユース・ケース図は、ユース・ケースに説明の必要な拡張または内包の関係がある場合や、関連するアクターに並外れた複雑さがある場合以外には、概して小さな価値しかありません
詳しくは「ガイドライン: ユース・ケース図」を参照してください。
ユース・ケースに関係する要求で、ユース・ケースのイベント・フローで考慮されていないものは、ユース・ケースの「特殊な要求」に記述します。これらの要求は、多くの場合機能外要求です。
詳しくは「ガイドライン: ユース・ケースの「特殊な要求」」を参照してください。
別システムまたは外部ハードウェアである任意のアクターで使用される通信プロトコルを定義します。既存のプロトコル (特に認知されたプロトコルまたは標準とみなされるプロトコル) が使用される場合、ユース・ケースの記述は単にプロトコルの名前にしなければなりません。プロトコルが新規の場合は、オブジェクト モデル開発時に完全な説明が必要になるプロトコル定義が参照できる場所を特定しなければなりません。
ユース・ケースの事前条件では、ユース・ケースを開始することを可能にするために必要な、システムの状態を説明します。
ATM システムで現金を引き出すには、以下の事前条件を満たさなければなりません。
- ATM ネットワークにアクセスできること
- ATM 機がトランザクションを受け入れられる状態にあること
- ATM 機に、引き出しに使用できる現金がいくらかあること
- ATM 機に、少なくとも 1 つのトランザクション レコードを印刷するのに十分な紙があること
これらはすべて、ユース・ケース「現金の引き出し」に対して有効な事前条件です。
システムの状態を記述するにあたっては注意を払ってください。このユース・ケースに先立って起こったそのほかの偶発的なアクティビティを詳細に記述することは避けます。
事前条件は、ユース・ケースのシーケンス作成に使用するものではありません。 重要なイベント・フローを実現するために、まずあるユース・ケースを実行し、次に別のユース・ケースを実行しなければならないという状態にはなりません。 このような処理を行う必要があるのは、一般に、ユース・ケース・モデルが細かく分解されている場合です。 分解したユース・ケースを順番に 1 つのユース・ケースにまとめて、問題を解決してください。 これによって、出来上がったユース・ケースが複雑になった場合は、前述のユース・ケースのイベント・フローの構造化、または作業: ユース・ケース モデルの構成を参照してユース・ケースの構成を考えてください。
詳しくは「ガイドライン: ユース・ケースの「事前条件と事後条件」」を参照してください。
ユース・ケースの事後条件では、ユース・ケースの終了時点でシステムが取る可能性のある状態がリストされます。ユース・ケースの終了時には、システムはこれらの状態の 1 つになければなりません。また、ユース・ケース中に何が起こったかにかかわらず、ユース・ケースの最後でシステムによって実行されるアクションを記述するのにも使用します。
ATM 機で、ユース・ケースの終了時に常に「いらっしゃいませ」というメッセージを表示する場合、これはユース・ケースの事後条件に記述します。
同様に、発生したイベントにかかわらず、ATM 機でユース・ケースの最後に常に顧客のトランザクション (現金の引き出しなど) を閉じる場合、これをユース・ケースの事後条件に記述します。
事後条件は、ユース・ケースのイベント・フローを簡単、かつ読みやすくするために使用します。
どのような状況であっても、事後条件をユース・ケースのシーケンス作成に使ってはなりません。重要なイベント・フローを実現するために、まずあるユース・ケースを実行し、次に別のユース・ケースを実行しなければならないという状態にはなりません。このようなシーケンスが必要な場合は、依存するユース・ケースを 1 つのユース・ケースにまとめます。この結果、まとめたユース・ケースが複雑になりすぎる場合は、上記のガイドライン: ユース・ケースの「イベント・フロー - 構成」、または「作業: ユース・ケース モデルの構成」に説明されている、ユース・ケースの構成の技術を参考にしてください。
詳しくは「ガイドライン: ユース・ケースの「事前条件と事後条件」」を参照してください。
ユース・ケースを別のユース・ケースで拡張する場合 (ガイドライン: 拡張関係を参照)、拡張ポイントを記述する必要があります (ガイドライン: ユース・ケースの「拡張ポイント」を参照)。
ユース・ケースについて利害関係者とレビューおよび討論し、利害関係者がユース・ケースをはっきりと理解し、その記述に合意することを確認します。
ユース・ケースの記述は、ユース・ケースで実行および実装されるもの、あるいはユース・ケースを最初から最後まで実行するのに必要なものをすべて記述した時点で完了します。 作業を終了する前に、ユース・ケースが「優良な」ユース・ケースの特徴を備えていることを確認します。 作業: 要求のレビューのユース・ケースに関するチェックポイントを参照してください。
Rational Unified Process
|