|  | レベル: 初級 Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM
2000年 10月 05日 Scott Ambler が、エッセンス・ユース・ケースとシステム・ユース・ケースの相違について説明し、双方を文書化する上での提案をします (後者に重点を置きます)。本稿は、The Object Primer 2nd Edition の第 3 章に修正を加えたものです。
ユース・ケースは、コンポーネント・ベースのシステムの動作要件を文書化するのに適用されている技法のうち、最も一般的なものの 1 つです。デベロッパーがしばしば質問するのは、「ユース・ケースを文書化するときに含めるべき情報は何か」ということです。ここに提案するセクションの中にはオプションのものも含まれていますが、わたしの考えでは、それらも含めた方が良い結果が得られます。エッセンス・ユース・ケースを文書化するとき (「エッセンス・ユース・ケースのモデリング (Modelling essential use cases)」と題する以前のヒントを参照)、わたしはオプションのセクションを省略する傾向があります (これは、エッセンス・ユース・ケースがどのように という問いにではなく、何 という問いに重きを置いているゆえ、システム・ユース・ケースほど複雑にする必要がないためです)。システム・ユース・ケースを文書化する場合、通常わたしはすべてのセクションを含めます。ここで、エッセンス・ユース・ケースとシステム・ユース・ケースの主な相違を思い出してみましょう。それは、システム・ユース・ケースには高レベルのインプリメンテーション上の決定が含められるのに対し、エッセンス・ユース・ケースはユーザーの意図を、テクノロジーやインプリメンテーションから独立した方法で捕らえることにあります。
セクションのうちの 2 つ (アクターと組み込みユース・ケース) は、実際のところ、単にユース・ケースのダイアグラムを見れば分かります。しかし、わたしの経験から言えば、ユース・ケースを自立できるようにするのは良いことです。言い換えれば、ユース・ケースとその文脈を理解するのに欠かせない情報は、すべてユース・ケースに含めるということです。そうすれば、その論題のエキスパート (SME: subject matter expert) たちが、ユース・ケースを個々に肉付けできます。(午前中は集まってグループで作業し、午後は各自にユース・ケースを割り当てて、自分でできるところまでユース・ケースを発展させるようにするなら、チームの生産性は向上するでしょう。)
ユース・ケースのセクション
-
名前。名前は、ユース・ケースに対するユーザーの意図や目的を暗黙的に示すものであるべきです。たとえば「セミナー登録」などです。
-
ID [オプション]。他のプロジェクトの作業結果 (クラス・モデルなど) でそのユース・ケースを参照するために使用できる、固有 ID ("UC1701" など)。
-
説明。ユース・ケースを要約する幾つかの文。
-
アクター [オプション]。ユース・ケースに関連したアクターのリスト。この情報はユース・ケース自体に含まれているものの、ダイアグラムが使用できない場合にユース・ケースが分かりやすくなります。
-
状況 [オプション]。ユース・ケースの状況を示す標識。通常は、処理中、検討準備完了、検討合格、検討不合格のいずれかになります。
-
頻度。このユース・ケースがアクターによって呼び出される 頻度。これはしばしばフリー・フォームの回答になります。たとえば、ユーザー・ログインごとに 1 回、あるいは 1 か月に 1 回などです。
-
事前条件。ユース・ケースを呼び出す前に満たさなければならない条件のリスト (もしあれば)。
-
事後条件。ユース・ケースが正常に終了した後にあてはまることになる条件 (もしあれば)。
-
拡張ユース・ケース [オプション]。このユース・ケースが拡張するユース・ケース (もしあれば)。拡張された関係とは、ユース・ケースを拡張することによって基底ユース・ケースの動作が継続するという、汎用化の関係です。これは、ユース・ケースを拡張した結果、付加的なアクションのシーケンスが基底ユース・ケースのシーケンスに挿入されることによって、可能になります。これは、<<extend>> ステレオタイプによるユース・ケース関連を使用してモデリングします。
-
組み込みユース・ケース [オプション]。このユース・ケースが組み込むユース・ケースのリスト。組み込みの関係は、別のユース・ケースの中にあるユース・ケースによって表される動作を含めるよう指示する、汎用化の関係です。これは、<<include>> ステレオタイプによるユース・ケース関連を使用してモデリングします。uses 関係、またはhas-a 関係とも呼ばれます。
-
前提事項 [オプション]。作成してきたドメインに関する、このユース・ケースを作成するにあたっての重要な前提事項。ある時点でこれらの前提事項を検査し、決定 (以下を参照)、あるいは単にアクションの基本コースまたは代替コースに発展させる必要があります。
-
アクションの基本コース。アクターがユース・ケースの中でたどって行く、論理のメインパス。これは、ハッピー・パス またはメインパス と呼ばれることもあります。なぜなら、すべてが期待どおりに機能するときに、ユース・ケースどのように機能するかを記述したものだからです。
-
アクションの代替コース。ユース・ケースの中でまれに使用される、論理のパス。これは、代替手段、例外、またはエラー状態の結果として生じるパスです。
-
変更ヒストリー [オプション]。いつ、誰が、なぜ、ユース・ケースに変更を加えたかに関する詳細。
-
問題 [オプション]。このユース・ケースの開発に関係する問題またはアクション項目のリスト (もしあれば)。
-
決定。通常 SME が下す、ユース・ケースの内容に関係する重要な決定のリスト。これらの決定を記録しておくことは、グループの記憶 を維持する上で重要です。
参考文献
ユース・ケースの詳細については、以下を参照してください。
著者について
記事の評価
| |
|
