改訂履歴
日付 |
バージョン |
説明 |
作成者 |
|
|
|
|
|
|
|
|
2.3 <<Include>> と <<Extend>> 関係の使用
3.1.1 個々の具体的なユースケースは必ず 1 つ以上のアクターと関係する
3.6.1 システムがアクション選択肢を提示する責任がある箇所を定義する
3.10 未定義の詳細のプレースホルダー (TBD) の使用
ユースケース・モデリング・ガイドライン
この一連のガイドラインの目的は、ユースケース・モデルの一貫性を保証することにあります。 このガイドラインでは、 ユースケースを文書化する方法と、要求定義者とシステム分析者にとってよく問題となる関連項目に関して一般的なヘルプとなる事柄を示します。
ここで示すガイドラインはほとんどのプロジェクトでそのまま使用でき、 プロジェクトのニーズに合わせてカスタマイズすることもできます。
「Rational Unified Process 用語集」を参照してください。
なし
この一連のガイドラインは 2 つのセクションから編成されています。 前半のセクションでは、ユースケースの望ましいモデリング 方法を説明します。 後半のセクションでは、ユースケース・モデルの内容 とモデル内部の要素の命名 に関するガイドラインについて説明します。
ユースケースは Rational Unified Process が提供するテンプレートを使用して記述します。 文書化に関してプロジェクトで適用する標準があれば、それに合わせて特定のスタイルやレイアウトを修正します。
アクターとユースケースの間の関連はコミュニケーション関係と呼ばれます。 これは一方向関連にすることが推奨されます。 このモデリング戦略に従うことで、次のものが識別されます。
アクティブ (能動的) アクター
アクターがユースケースの実行を開始 (トリガー) するとき、
アクターとユースケースのペアにおいてアクターは能動的であるとみなされます。 コミュニケーション関係の矢印はユースケースの方向を指します。
パッシブ (受動的) アクター
ユースケースがコミュニケーションを開始するとき、アクターとユースケースのペアにおいてアクターは受動的であるとみなされます。パッシブ・アクターになるのは通常、
システムがコミュニケーションする必要のある外部のシステムまたは装置です。コミュニケーション関係の矢印はアクターの方向を指します。
このことを推奨するのは、 アクティブ・アクターとパッシブ・アクターの概念がユースケース・モデルを読む人々に付加価値をもたらすからです。
最初は、これらの関係を使用しないことが推奨されます。 このことを推奨するのは、 これらの関係の使用法を誤ると、ユースケース・モデルの簡素化に役立つより先にモデルが乱雑になり、混乱する可能性が高いからです。 ベスト・プラクティスとしては、最初はこの種の分解を避け、プロセスの比較的後期の段階でこれらの関係の使用を検討します。これらの関係は以下の目的で使用できます。
1. 2 つ以上のユースケースに共通する振る舞いを除外します。
2. ユースケースの主な目的を理解するためには必要なく、 結果のみが重要である振る舞いを、基底ユースケースから除外します。
3. 基底ユースケースの 1 箇所の拡張点に、 1 つまたはいくつかが挿入された可能性がある、振る舞いのセグメントの集合が存在する可能性を提示します。
ただし、これらの関係は、 ユースケース・モデルの簡素化と管理に寄与することによって付加価値をもたらす場合に限って使用すべきです。
包含関係は、 基底ユースケースを実行するユースケースのインスタンスに挿入される振る舞いのセグメントを記述します。 これはサブルーチンに似た性質のメカニズムであり、 共通の振る舞いを分析する目的で最も頻繁に使用されます。
詳しくは、 Rational Unified Process の「ガイドライン: 包含関係」を参照してください。
拡張関係は比較的その利用が難しい関係ですが、 それは主に、拡張ユースケースが基底ユースケースから見て未知のものである、という理由によるものです。 一般的見解として、 大半のビジネス・システムでは、この関係が役立つ場合はほとんどありません。ただし、ルールには常に例外があるということと、 特定の状況下ではこのメカニズムが役に立つ可能性もあるということを覚えておいてください。
詳しくは、 Rational Unified Process の「ガイドライン: 拡張関係」を参照してください。
アクターの汎化は一般に、 開発対象のシステムのユーザーが演じるさまざまなロールをより正確に定義するために使用できます。 これは、エンド・ユーザーの「カテゴリー」が多様であるアプリケーションで役立ちます。 この方法で、関連する機能だけを各カテゴリーのユーザーに提示し、このグループ化に基づいてアクセス権を制御することができます。
経験則: 各ユースケースが 1 つのアクターだけによって開始されるようにします。 ユースケースの説明で決定を正当化しなければならない場合には、 この「ルール」に従わなくてもかまいません。
「大学のビジネス・ドメイン: 図書館員と教授」
からの例は、
大学ドメイン内の既存の 2 つのロール (アクター) の例です。
これらのロールにはいくつかの共通のタスクと、
ビジネスにおける各自のロールに固有のタスクがいくつかあります。これをモデリングする望ましい方法を次に示します。
詳しくは、 Rational Unified Process の「ガイドライン: アクターの汎化」を参照してください。
テキストによるイベント・フローの記述に加えて、 ユースケースの「高レベルの」イベント・フローを表現する相互作用図を含めると効果的な場合があります。 この目的のためのシーケンス図は Rational Rose で描画することを推奨します。ダイアグラムにはアクターとバウンダリー・オブジェクトの間のコミュニケーション (入力メッセージと出力メッセージの両方をカバーする) だけを盛り込み、 システムはブラック・ボックスとして扱います。ユースケースのイベント・フローに定義された論理名を持つバウンダリー・オブジェクトを使用しますが、 この時点ではそれらのオブジェクトをクラスに割り当てることはしません。
対応する相互作用図がすべてのユースケースに必要なわけではありません。 これはオプションのワーク・プロダクトです。
ユースケースのイベント・フローを定義し、明確化し、 完成する作業の補助手段としてアクティビティー図が効果的な場合、 それらのイベントを Rational Rose でモデリングすることを推奨します。 経験則上、(複数の代替フローや例外フローを含む) 複雑なユースケースについてはアクティビティー図の使用を検討すると有効です。アクティビティー図は、ユースケース内のフローの決定木を示します。
対応するアクティビティー図がすべてのユースケースに必要なわけではありません。 これはオプションのワーク・プロダクトです。
全般的な情報と補足の「ユースケースのガイドライン」については、 Rational Unified Process を参照してください。
全般的な情報と補足の「アクターのガイドライン」については、 Rational Unified Process を参照してください。
具体的な各ユースケースに、少なくとも 1 つのアクターが関与しているか。 関与していない場合は、 アクターと相互作用しないユースケースが余分であるなど、どこかに問題があるので、 このユースケースを削除するか、そのユースケースに対応するアクターを識別します。
ユースケースの相互作用の中で、複数のアクターが 1 つのロールを演じる場合があります。 1 つのユースケース内で複数のアクターを使用する場合、 必ずそのことの正当性をチェックしてください (「アクターの汎化」を参照)。
アクターの名前が直感的にわかり、かつ説明的でしょうか。 ユーザーと顧客の両方がその名前を理解できるでしょうか。アクター名とアクターのロールが一致していることが重要です。一致していない場合は名前を変更します。
ユースケース内のすべてのアクターについて、 正しいアクター名を使用しているかどうかを、ユースケース・モデルを参照して確認します。
ユースケース仕様は、一貫したアクター名を使用して記述します。 常に、明確で、あいまいさのない名前をアクターに付けるように注意を払います。
「アクター」のような総称的な名前ではなく、 アクターを一意に識別または定義するために使われる実際の名前を使用します。 アクター名は、システムの一連の相互作用の中で演じられるロールと考えることができます。
ユースケース名は一意で、直感的で、説明的なものにし、 その名前によって、それと認められる価値のある結果がユースケースから得られるよう明確に定義するようにします。
ユースケース名が適切かどうかをチェックするよい方法は、 顧客、ビジネスの代表者、分析者、開発者のすべてがユースケースの名前と説明を理解できるかどうかを調査することです。 ユースケースの命名では、 アクターの観点からそれと認められる価値のある結果を定義しているのだ、ということを覚えておいてください。
個々のユースケース名では、そのユースケースで扱う振る舞いを記述します。 実行されるアクションと、 「アクションの対象である」重要な要素の両方を組み合わせた名前を付けます。ほとんどの場合、 これは単純な動詞と名詞の組み合わせです。ユースケースには、そのユースケースを開始するアクターの観点からの名前を付けます。例えば、 「コースを登録する」や「教授するコースを選択する」のような名前です。
ユースケースには簡潔な説明を付けます。 この説明の長さは 1 ~ 3 段落にします。 記述にはユースケースの主な目的、提示する価値、概念の説明を含めます。
それを行う価値がある箇所では、より詳細な状況の描写に役立つ、 短い「ストーリー」を例として説明に添付することができます。 この例は通常は基本フローに従い、有効な場合にはデータ値を組み込みます。
ユースケース内部のシステム要件は断定形を使用して記述します。 要求の記述の一貫性を保つために、 「~する (Shall)」や「~しなければならない (Must)」に類する表現として「~する (Will)」という用語を選択します。「~すべき (should)」、「おそらく (possibly)」、「~など (etc)」、「~かもしれない (might)」、「~の場合がある (may)」など、 要求がオプションまたは未定義であることを暗示する受動的な用語は使用しないようにします。
ユースケース内で使用されるすべてのビジネス用語をプロジェクトの用語集に定義します。 用語集に定義されていないビジネス用語がユースケース内に存在する場合、 その用語は次のどちらかの方法で取り扱う必要があります。
1. 簡潔な説明 (長くても 1 段落) を付けて用語集に追加する。
2. 用語集に定義されている正しいビジネス用語に合わせて、ユースケース内の用語を変更する。
ユースケースでは、 アクターの選択肢としてのアクションをシステムが提示しなければならない箇所を明示的に述べます。 ほとんどの場合、 有効な選択肢は基本フローの一部として提示され、対応する代替フローの最初の文でエントリー・ポイントとして参照されます。
「新規作成」、「修正」、「キャンセル」、「削除」、「OK」、「印刷」などの用語の使用に関して、 ユースケース全体を通じて一貫性を保ちます。複数の異なる用語が同じ論理アクションを指さないようにします。 特に、代替フロー内で使用するアクション用語が、 基本フロー内で使用されている用語と確実に一致するように注意を払います。
アクターとシステムの間の相互作用が (アクターとシステムの間で) フォーカスを切り替えるたびに、 振る舞いの次のセグメントの記述を新しい段落から開始します。 まずアクター側の記述から始め、次にシステム側を記述します。
記述する文は「<アクター名> は~する」または「システムは~する」のような形式で開始しなければなりません。 頭字語は使用せず、アクター名は常に正確かつ省略せずに記述します。
個々の代替フローとサブフローでは、フローへの入状点として考えられるものすべてを明示的かつ明確に定義し、 フローの退状点として考えられるものすべてを記述して結びます。
代替フローでは、退状点とアクターの次の進路 (アクターが基本フロー内の特定のステップに戻るのか、 それとも終了するのか) も明示的に述べます。
振る舞いが複雑なためにイベント・フローが混雑する箇所、 または、1 つのフローが長く、印刷して 1 ページに収まらないような箇所では、 サブフローを使用することによってフローをより分かりやすくし、複雑さを緩和することができます。 サブフローの記述は、 自己完結した、詳細な振る舞いの論理グループをサブフローに移動し、 イベント・フローの内部ではその振る舞いを要約形式で参照することによって行います。
ユースケース仕様には一連の条件 (仮定とも呼ぶ) が含まれます。 条件には、ユースケースの開始前に満たされることが期待される条件 (事前条件) と、 ユースケースの終了後に満たされることが期待される条件 (事後条件) の 2 種類があります。 ユースケースの終了形態は複数に分かれる場合があり、 形態ごとに個別に「事後条件」を記述すべきである、という点に注意してください。
情報が未定義または未決定の問題または要素がある場合、 ユースケースにはその問題または要素への参照と、プレースホルダー「TBD」を含めます。
イベント・フローの中で自然に記述できない補足的な要求がある場合、 それらの要求を補足要求として定義します。 特定のユースケースに固有である要求については、 ユースケース仕様書の「特殊要件」セクションで定義します。
システム全体に適用可能な要求、特に機能外的な性質の要求については、 1 つまたは複数の独立した補足仕様書で定義します。
以下にその例を挙げます。
信頼性: - システムは 1 日 24 時間、週 7 日の稼働を保証しなければならない。
- システムは 48 時間の MTBF (平均故障間隔) の間は停止してはならない。
性能: - 想定される通常の負荷状況下で、システムは 5 秒以内にオンライン応答しなければならない。
UI プロトタイプ/設計に照らしてユースケースの内容をクロスチェックし、 ユースケースまたは UI プロトタイプ/設計から欠落しているシステム要件がないことを保証します。 ユースケースへの変更が必要な場合、 変更はアクションとして定義されます。UI プロトタイプへの変更は、将来のアクションに関しての検討事項として注釈化されます。
例外フローの発見を支援するための、以下のガイドラインが提供されています。
ユースケースの各ステップについて、発生の可能性がある想定外の事態を検討します。 内容的に重複しない個々の例外は例外フローと捉えることができます。「タイムアウト」のような、1 つの例外フローを ユースケース全体で共通して使用する場合もあります。把握すべき重要な情報は、 例外が発生したときのビジネス要求 (例えば、アクターがとるべき対処など) です。