システムユースケースの概要
by Scott
W. Ambler, Copyright 2003
ユースケースとは、アクターに重要な価値を提供するアクションのシーケンスです。実世界のアクターがシステムとどう相互作用するかを表すものだということもできます。システムユースケースには、高いレベルの実装上の決定事項を含めます。システムユースケースは、略式と正式のどちらの方法で書くこともできます。ユースケースを識別する方法やユースケースを書くときにアジャイルであり続ける方法についても説明します。
まず、プロジェクトのサイクル0において、初期の要求収集作業の一環としてどのような種類のユースケースを記述するかを考えてみましょう。この場合のユースケースは、本質ユースケースまたは「略式」のシステムユースケースになります。略式のシステムユースケースの例を図I-1に示します。これを見ると、各ステップは非常に短く箇条書きで書かれています。何とか考えを理解させられるだけの情報しか含んでいません。また、技術的な問題も考慮されています。たとえば「学生は名前と学生番号を入力する」という文からは、何らかの情報システムを使うことが読み取れます。「システム」ということばが使われていることも同じ意味を持ちます。
図I-1. 「ゼミに登録する」の略式のシステムユースケース(システム化されたもの)
|
名前: ゼミに登録する
識別番号: UC17
アクションの基本コース:
-
学生は名前と学生番号を入力する。
-
システムは学生がゼミに登録する資格を持っていることを確認する。資格がない場合には学生にその旨を知らせ、ユースケースは終了する。
-
システムは取ることのできるゼミの一覧を表示する。
-
学生はゼミを選択する、あるいはまったく登録しないことにする。
-
システムは学生が選択したゼミに登録する資格を持っていることを確認する。資格がない場合には別のゼミを選択するよう告げる。
-
システムは学生のスケジュールにそのゼミを組み込むことができるかどうかを確認する。
-
システムは授業料を計算して表示する。
-
学生は授業料を確認し、登録したいかどうかを知らせる。
-
システムは学生をゼミに登録し、授業料を請求する。
-
システムは授業料の領収証を印刷する。
|
もう1つの図I-2は、自動化されたシステムではなく、学籍係(人)が登場する手動のプロセスです。ソフトウェアを使ったプロセスではなく人手を介したプロセスを使うという判断も、技術アーキテクチャのうちです。つまりこの場合は、ローテクのアーキテクチャを選んだということです。この2つのユースケースの違いによって、システムユースケースが分析の成果物やおそらくは設計の成果物でさえないこと、要求の成果物でもないことが表れています。
図I-2. 「ゼミに登録する」の略式のシステムユースケース(人手を介したもの)
|
名前: ゼミに登録する
識別番号: UC17
アクションの基本コース:
-
学生は名前と学生番号を入力する。
-
学籍係は学生がゼミに登録する資格を持っていることを確認する。資格がない場合には学生にその旨を知らせ、ユースケースは終了する。
-
学籍係は学生にどのゼミに登録したいかを尋ねる。ゼミが分からない場合、学籍係は要望があれば学生にコースカタログを渡す。
-
学生はゼミを選択する、あるいはまったく登録しないことにする。
-
学籍係は学生レコード（履修記録）を見て、学生が前提条件のコースをこれまでに終了しているかどうかを確認する。資格がない場合には別のゼミを選択するよう告げる。
-
システムは学生のスケジュールにそのゼミを組み込むことができるかどうかをを確認する。
-
学籍係は授業料を計算する。
-
学生は授業料を確認し、登録したいかどうかを知らせる。
-
学籍係は学生をゼミに登録し、授業料を請求する。
-
学籍係は授業料の領収証を書く。
|
正式なシステムユースケース
図1は図I-1を正式な形に書き直したものです。こちらの方が略式のユースケースよりずっと詳細で、文書を重視する環境でよく書かれているタイプのユースケースです。正直なところ、ほとんどのプロジェクトではユースケースをここまで詳細にすると書きすぎなのですが、この形式で(あるいは同様の形式で)書くことを要求されているプロジェクトチームは数多くあります。というのも、このレベルの文書が必要だと上級管理職が信じて疑わないからです。モデルはできるだけシンプルにし、ここまで徹底的に文書化するのは実際に価値がある場合だけにとどめることを推奨します。
正式なシステムユースケースは、画面やHTMLページやレポートといった、具体的なユーザインターフェースのコンポーネントにも言及しています。これは、本質/ビジネスユースケースでは触れないことです。分析時には、何を構築するか(ユースケースに反映する情報)と、おそらくはどう構築するか(事実上の設計)を決定します。ユースケースではユーザインターフェースコンポーネントに言及しており、ユーザインターフェースは設計時に考慮することなので、必然的に設計に関する事柄がユースケースに入り込むことになります。たとえば、設計上の考慮点として、ユーザインターフェースをHTMLページなどのブラウザベースの技術で実装するのか、WindowsなどのGUI技術で実装するのかという問題があります。ユーザインターフェースの動きは実装技術によって異なるため、ユーザインターフェースのフローを反映したシステムユースケースのロジックも影響を受けることになります。
図1. 「ゼミに登録する」の正式なシステムユースケース
|
名前: ゼミに登録する
識別番号: UC17
概要:
既存の学生を登録資格のあるゼミに登録する。
事前条件:
学生は大学に登録されている。
事後条件:
登録資格があり、席が空いていれば、学生は望む授業に登録される。
アクションの基本コース:
1.
学生がゼミに登録しようとすると、ユースケースは始まる。
2.
学生は「UI23 セキュリティログイン画面」から名前と学生番号をシステムに入力する。
3.
システムは、ビジネスルール「BR129 登録資格を判断する」に従って、学生が大学のゼミに登録する資格を持っていることを確認する。[代替コースA]
4.
システムは「UI32 ゼミ選択画面」を表示して、取ることのできるゼミの一覧を示す。
5.
学生は登録したいゼミを指定する。[代替コースB: 学生は登録しないことにする]
6.
システムは、ビジネスルール「BR130 学生のゼミへの登録資格を判断する」に従って、学生がそのゼミに登録する資格を持っていることを確認する。[代替コースC]
7.
システムは、ビジネスルール「BR143 学生の受講スケジュールを確認する」に従って、学生の現在のスケジュールにそのゼミを組み込むことができるかどうかを確認する。
8.
システムは、講義カタログで公表されている料金と、必要な諸経費および税金を適用して、ゼミの授業料を計算する。ビジネスルール「BR180 諸経費を計算する」および「BR45 ゼミの税金を計算する」を適用する。
9.
システムは「UI33 ゼミ授業料表示画面」に授業料を表示する。
10.
システムは学生にそれでもゼミに登録したいかどうかを尋ねる。
11.
学生はゼミに登録したいことを示す。
12.
システムは学生をゼミに登録する。
13.
システムは「UI88 ゼミ登録概要画面」で学生に登録が成功したことを知らせる。
14.
システムは、ビジネスルール「BR100 学生にゼミの授業料を請求する」に従って、学生にゼミの授業料を請求する。
15.
システムは学生に登録内容を印刷したいかどうかを尋ねる。
16.
学生は登録内容を印刷したいことを示す。
17.
システムは登録内容について「UI89 登録概略レポート」を印刷する。
18.
学生が印刷された登録内容を手にすると、ユースケースは終了する。
代替コースA: 学生がゼミに登録する資格がない
A.3. 学籍係は学生がゼミに登録する資格がないと判断する。
A.4. 学籍係は学生に登録資格がないことを知らせる。
A.5. ユースケースは終了する。
代替コースB: 学生は取ることのできるゼミに登録しないことにする
B.5. 学生はゼミの一覧を見るが、登録したいゼミが見つからない。
B.6. ユースケースは終了する。
代替コースC: 学生が前提条件を満たしていない
C.6. 学籍係は学生が選択したゼミに登録する資格がないと判断する。
C.7. 学籍係は学生に前提条件を満たしていないことを知らせる。
C.8. 学籍係は学生に必要な前提条件を知らせる。
C.9. ユースケースはアクションの基本コースのステップ4に続く。
|
図2. 「大学に登録する」の正式なシステムユースケース
|
名前: 大学に登録する
識別番号: UC19
概要:
誰かを大学に登録する。
事前条件:
事後条件:
アクションの基本コース:
1.
申込者は大学に登録しようとする。
2.
申込者は記入した「UI13 入学申請用紙」を学籍係に手渡す。[代替コースA: 申込用紙の記入が済んでいない]
3.
学籍係は申込用紙を目でチェックする。
4.
学籍係は申込用紙が正しく記入されていると判断する。[代替コースB: 申込用紙の記入に不備がある]
5.
学籍係は「学生を作成する」アイコンをクリックする。
6.
システムは「UI89 学生作成画面」を表示する
7.
学籍係は申込者の名前、住所、電話番号を入力する。[拡張点: 「UC34 セキュリティチェックを行う」 ステップ17に適用]
8.
システムは「BR37 新規学生に該当する候補者の抽出条件」に従って、システム中にその申込者がまだ存在しないことを確認する。[代替コースF: 学生がシステム中に存在する]
9.
システムは申込者が登録資格のある申込者のリストに載っていることを確認する。[代替コースG: その人に登録資格がない]
10.
システムは申込者をレコードに追加する。これで申込者は学生とみなされる。
11.
学籍係は学生がユースケース「UC17 ゼミに登録する」によってゼミに登録するのを手伝う。
12.
システムは「BR16 登録料を計算する」に従って、必要な入学金を計算する。
13.
システムは「UI15 授業料要約画面」を表示する。
14.
学籍係は「BR19 授業料支払いオプション」に従って入学金を支払うかを学生に尋ねる。
15.
学生は入学金を支払う。[代替コースD: 学生はその場で支払うことができない]
16.
システムは領収証を印刷する
17.
学籍係は学生に領収証を手渡す。
18.
ユースケースは終了する。
代替コースA: 申込用紙の記入が済んでいない
A.2. 申込者は申込用紙をくれるよう頼む。
A.3. 申込者は申込用紙を正しく記入する。
A.4. ユースケースはアクションの基本コースのステップ2に続く。
代替コースB: ……
|
図2は大学に登録するための正式なシステムユースケースです(従来型ユースケースあるいは具象ユースケースと呼ばれることもあります)。このユースケースで興味深いのは以下の点です。
-
このシステムユースケースには実装上の詳細が数多く含まれています。たとえば「システム」ということばが使われていますが、ここから、登録に関する決まりきった作業をシステム化するという決定が下されていることが分かります。システムユースケースを書くときに、問題に対応するための要求を分析し、記述しながら、ユーザインターフェースをどのようなものにするかを暗黙的に決定して書き込んでいます。
-
このシステムユースケースでは画面やレポートに言及しています。たとえば「UI23 セキュリティログイン画面」や「UI89 登録概略レポート」などです。ここでも実装の詳細が反映されています。システムを(HTMLページではなく)画面や印刷されたレポートとして実装すると誰かが決定したわけです。
-
このユースケースでは、「BR37 新規学生に該当する候補者の抽出条件」といったビジネスルール定義に言及しています。これは、ビジネスルールがシステム化対象領域の本質的な特徴を表しているためです。複雑なビジネスルールを多く持たない単純なシステムの場合、私はシンプルにするためにビジネスルールをユースケース内に記述してしまいます。状況によって必要なアプローチは異なるため、AMの「実状に合わせよう」の原則が重要になってきます。
-
ユースケースの各ステップには、1つの作業だけを記述します。この方法にはいくつかの長所があります。それぞれの文が理解しやすく妥当性を確認しやすいため、ユースケースのテストが容易になります。1つの文が1つのことだけを行っているため、分岐しやすくなり、代替コースを書くのが容易になります。
-
ユースケースのステップが能動態で書かれています。たとえば「学籍係は学生に授業料を知らせる」というのは能動態で、「学生は学籍係から授業料を知らされる」というのは受動態です。能動態で書くことで、文が簡潔になります。
-
私はユースケースのアクションの基本コースの最後に、締めくくりの文を書くことにしています。たいていは「ユースケースは終了する」や「〜すると、ユースケースは終了する」といった文を使います。これによってアクションのコースのロジック定義が完了したと示すことができます。
-
アクションの代替コースとは、ユースケースのロジックのうち、あまり使われない経路のことです。代替コースを書くのは、異なる仕事のやり方がある場合や、例外的なやり方、対処しなければならないエラーが発生する場合などです。ユースケースの本文では複数の代替コースを参照します。これはユースケース式のif/thenロジックであり、そのロジックの1つがユースケースの一番下に記述されているだけだと考えるとよいでしょう。
ユースケースになりそうなものを識別するにはどうすればよいでしょうか。Constantine とLockwood(1999)は、本質ユースケース(あるいは単にユースケース)を識別する方法として、利害関係者にアクターの視点から以下の質問に答えてもらい、サービスになりそうなものを見つけ出すという方法を提案しています。
- この役割のユーザは何を行いたいと思っているのか
- この役割を果たすには、ユーザは何ができなければならないか
- この役割のユーザにとって、主なタスクは何か
- この役割のユーザはどのような情報をチェック、作成、変更しなければならないか
- この役割のユーザはシステムからどのような情報を得る必要があるか
- この役割のユーザはシステムにどのような情報を知らせる必要があるか
たとえば「学生」アクターの視点から見ると、学生について以下のことが分かります。
- ゼミに登録する、出席する、ゼミから脱退する、不合格あるいは合格になる。
- 空席のあるゼミの一覧が必要である。
- 概要や前提条件など、ゼミに関する基本情報を知る必要がある。
- 成績証明書、講義スケジュール、授業料の写しを入手する。
- 授業料を支払う、延滞金を支払う、脱退したあるいはキャンセルされたコースの授業料の返還を受ける、補助金を受ける、学生貸付を受ける。
- 学校を卒業する、あるいは中退する。
- 教室の変更、時間の変更、休講など、ゼミに関する変更情報を得る必要がある。
ユースケースモデリングはすぐにアジャイルでなくなってしまいます。アジャイルであり続けるには、そこそこ役に立つだけの成果物を作成することに集中する必要があります。成果物は完璧である必要はありません。要求を完璧に書き表さなければならないと考えたばかりにプロジェクトが誤った方向に進んでしまった例を、私はいくつも見てきました。開発者はマグナカルタを書いているのではないのです。たとえば図2には、不完全な部分がいくつかあります。代替コースのラベルは順番になっていませんし(FやGの後にDがきています)、CやEは使われていません(以前にはあったのが消されてしまったのでしょう)。ユースケースは完璧ではありませんが、それで世界が終わってしまったわけではありません。時間をかけてこれらの問題を修正することはできますが、それにどんな価値があるでしょうか。AMの「利害関係者の投資を最大限に生かそう」の原則を常に心に留め、価値のあることだけを行いましょう。私について繰り返してください。ユースケースは役に立ちさえすればよいのです。ユースケースは役に立ちさえすればよいのです。ユースケースは役に立ちさえすればよいのです。なぜこれでうまく行くのでしょうか。アジャイルな環境ではこれらの要求にもとづいて早々にコードの作成を開始するため、要求されていることを完全に理解していなくてもすぐそれに気付きますし、そのために利害関係者の近くで作業をしています。そして、利害関係者の実際のニーズに合ったものを構築できるわけです。開発するのはソフトウェアであって、文書ではありません。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。
 |
効果的なユースケースの書き方を学ぶにはもっとも適した本です。 |
 |
利害関係者と一緒に作業をする技法を説明した非常に優れた本です。ユースケースモデリングが含まれています。 |
|
その他の成果物概要
|
ユースケース図および本質ユースケース |
| その他のユースケースに関する文献 |
|
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
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 June 8, 2004.
|
