アジャイルモデリング(AM)
公式サイト
モデリング成果物>本質ユースケース

本質ユースケースの概要

by Scott W. Ambler, Copyright 2003

 

本質ユースケース (essetial use case) (Constantine and Lockwood 1999)は、ビジネスユースケースとも呼ばれる、簡潔で、抽象化、一般化されたユースケースであり、ユーザの意図を技術や実装に依存しないように表現したものです。完全に文書化された本質ユースケースは、話を構造化したものであり、対象とする分野やユーザのことばで表現します。1つのタスクや相互作用を、簡潔、抽象的で、技術にとらわれない、実装に依存しない方法で記述します。本質ユースケースは、システムに対して何らかの役割を持つユーザの視点から見て、完結し、意味があり、効果的に設計されたもので、相互作用の背後に存在する目的や意図を具体的に表現します。

本質ユースケースが RUP(ラショナル統一プロセス)で言うところのビジネスユースケースであるというのは、あまり正確ではありません(非常に似てはいますが)。ビジネスユースケースの方は、たいていはよりビジネスプロセスに特化しており、既存技術に関する事柄も頻繁に持ち込まれます。ビジネスユースケースは、本質ユースケースとシステムユースケースとの間にあるものと考えるとよいでしょう(どちらかというと本質ユースケース寄りですが)。

図1は、詳細に記述した本質ユースケースの例です。言い回しが非常に短くて適切であることに注目してください。基本的な考えを伝えればよいだけなので、詳細はあまり書かれていません。

 

図1. 本質ユースケース

ゼミに登録する

ID: UC 17

事前条件:

  • 学生は大学に登録されている。

事後条件:

  • なし

アクター

応答

学生は自分が誰であるかを示す

 

 

 

ゼミを選択する

 

 

 

 

 

 

登録を確認する

「BR129 登録資格を判断する」に従って、登録資格を確認する

登録可能なゼミを示す

 

「BR130 学生のゼミへの登録資格を判断する」に従って、選択内容を確認する

「BR143 学生の受講スケジュールを確認する」に従って、スケジュールに問題がないことを確認する

「BR180 諸経費を計算する」および「BR45 ゼミの税金を計算する」に従って、授業料を計算する

授業料を要約する

確認を求める

 

学生をゼミに登録する

学生への請求に授業料を追加する

登録したという確認を行う

 

一般的に、本質ユースケースは2列の書式で記述します。左側の列にはアクターが何をするかを、右側の列にはそのアクターがしたこと(アクション)に対する応答を記述します。アクターは何かを行い、そのアクションに対する応答を受け取ります。この図を見ると、アクションと応答の行間のあき具合からユースケースの流れ(フロー)は明白ですが、より分かりやすくするためにステップに番号を振ってもかまいません。

このユースケースではビジネスルールを参照していますが、ルール自体をユースケースに埋め込んではおらず、「適切な成果物を使おう」というAMのプラクティスを反映しています。これは書き方の問題ではありますが、このおかげで私は何年にもわたって、情報を1ヶ所だけに記録して身軽な旅をすることができています(他の成果物でも同様にビジネスルールを参照する必要があるでしょう)。

ConstantineとLockwood(1999)は、これらの列のタイトルに「ユーザアクション」および「システム応答」ということばを使っていますが、私はご覧のように「アクター」および「応答」ということばを使っています。「アクター」ということばは一般的なユースケースの用語と同じですが、「応答」ということばは「システムの応答」だけではなく、「人間による応答」も含んでいます。すなわち、「応答」はその応答を実現する技術に特定するものではありません。「アクター」に対する「応答」はすべて自動化しなければならないと考えてしまう人がいるかもしれませんが、実際はそう考えるのは適切ではないということは明らかです。そのような短絡的な発想を防ぐために、ここでは「応答」という言葉を使っています。例によって、自分にとってもっともうまく行く形式を見つけてください。

私がユースケースに一意の識別番号 (ID) を付け、事前条件および事後条件を示していることに注意してください。これら3つの情報は記述しなくてもよいのですが、非常に便利です。他の場所で成果物を参照する必要があるときには、私は必ず識別番号を付けています。たとえば、このユースケース自体からいくつかのビジネスルールを参照していますが、そのそれぞれに一意の識別番号が付いています。事前条件には、このユースケースを実行する前に真でなければならない事柄があれば、それを示します。事後条件には、ユースケースが成功で終わったときに真になっている事柄があれば、それを示します。

本質ユースケースの大きな利点は、少し離れて「実際に何が行なわれているのだろう」「本当にしなければならないのは何だろう」といった基本的な問題を、実装上の決定に邪魔されずに考えられることです。これらの問題を考えることで重大な事柄を認識できることがよくあり、結果として全体的なビジネスプロセスを考え直す(好みであればリエンジニアリングということばを使ってもかまいません)ことができます。

本質ユースケースモデリングを行なっているとき、技術に依存しないことはできても、完全に「システムに依存しない」ことは不可能です。自分の作業の範囲だけでなく、プロジェクトの構想や目的にも常に縛られます。その結果、人間系のシステムであれ、自動化されたシステムであれ、その両者の組み合わせであれ、開発中のシステムをどう理解しているかはユースケースの書き方に必ず影響することになります。

なぜ本質ユースケースを使うのでしょうか。従来型/システムユースケースには一般的に、背後に存在する技術的な実装やこれから設計するユーザインターフェースに関して、想定した事柄が多く含まれすぎています(多くは隠されていたり暗黙的な了解です)。これは分析や設計の作業には役立ちますが、要求の作業ではあまりよいことではありません。それに対して本質ユースケースは、ユーザの目的や意図にもとづいて作成されるものであり、目的や意図を達成する具体的なステップやメカニズムに基づいて作成されるのではありません。

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。


推奨文献

ユースケース実践ガイド

 

効果的なユースケースの書き方を学ぶにはもっとも適した本です。
Software For Use

 

利害関係者と一緒に作業をする技法を説明した非常に優れた本です。ユースケースモデリングが含まれています。
 

その他の成果物の概要

 

ユースケース図およびシステムユースケース
その他のユースケースに関する文献

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help (以下、北米での話ですのでご注意ください)

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since November 17, 2003.