ユースケースモデルの作成

GOAL シナリオが与えられたとき、人に伝わるユースケースモデルが書けるようになる。

Objective ユースケースモデルを使う利点を説明できるようになる。 シナリオが与えられたとき、適切にユースケースを抽出できるようになる。 シナリオが与えられたとき、適切にアクタを抽出できるようになる。 「サービスを明らかにする」について議論することができるようになる。

人を幸せにするシステム ソフトウエアには、「人を幸せにするサービスを提供する」という使命がある。 ワープロであれば、文書を書いて、印刷するというサービスを提供します。 表計算システムでは、ある行の数字を全部足して、合計を出したり、並び替えを行ったりするサービスを提供します。

人を幸せにするサービス 「そんなの簡単ジャン！」 ケーススタディー 意外に難しい。 皆さんも、多かれ少なかれ、「使いにくいソフトウエア」に不満をもったことがあるでしょう。 ケーススタディー (HTS)HyperTransactionSystemの失敗

ケーススタディー(概要) ① 開発チームの作成したものは、××さん（クライアント）の想像していたものとは、異なっていた。 ① 開発チームの作成したものは、××さん（クライアント）の想像していたものとは、異なっていた。 ② どこが異なるかというと、××さん（クライアント）が思っていた「あってしかるべき機能がなかった」ことであった。 ③ しかし、開発チームは、４月時点での仕様書に書かれていない機能は実装しなかった。 ④ ソフトウエアができ、実際に使うときになって問題が発覚した。 ⑤ ××さん（クライアント）は、「性能が悪い」といって激怒した。 ⑥ 開発チームは、作り直しを求められたが、仕様書に書かれていないと反論した。 ⑦ １ヶ月間、水掛け論が続き、ユーザはその間使いづらいソフトウエアを使わされ、そのソフトウエアの評価が落ちた。

ケーススタディー(原因) ① 仕様書は、４月に作成されたが、開発チームが作ったものであり、実証実験チームは、その意味がわからなかった。 ① 仕様書は、４月に作成されたが、開発チームが作ったものであり、実証実験チームは、その意味がわからなかった。 ② 実証実験チームは、８月にソフトウエアができるまで、プロジェクトに参加しなかった。（実証実験だけやればいいと思っていた。） ③ 開発チームは、仕様書の機能を満たし、試験にパスすれば、良いソフトウエアができると信じていた。

失敗の本質 ソフトウエアを作り始める段階で、「これから作るものを明らかにする」ことをしなかった。 完成イメージが人それぞれ違っていた。 この問題は、人間が言葉を使って、暗黙の了解を続けている間は、避けられない問題です。 「時計」システムを作ってください。 「ワープロ」システムを作ってください。

「時計」システム あなたの考える「時計」システムを考えてください。 それは、腕時計ですか？置時計ですか？ それは、デジタルですか？アナログですか？ 24時間表示ですか？12時間表示ですか？ アラームはついてますか？ 現在時刻を再設定できますか？それは、どのように行いますか？

ユースケースモデル ユースケースモデルを書く目的は、 「作るシステムを明らかにする」ことです。 「明らか」とはどういう意味ですか？ 「明らか」になると、どのようないいことがありますか？ 発注者（クライアント）と開発者の思っていることの食い違いを防げる。 「作るものと、作らないもの」の意見の食い違いを防げる。 開発者の間での思っていることの食い違いを防げる。 自分で作るものがはっきりする。 作るものが、本当に必要かどうか、議論できる。

ユースケース 「ユーザ」がどのように使うのかを考える。 Ex)「自動販売機」システムの場合 システムの「機能」ではなく、ユーザが受ける「サービス」で考える。 システムの「機能」をユーザが何のために利用するのかを考える。 Ex)「自動販売機」システムの場合 機能 在庫管理機能 販売商品表示機能 サービス 商品を買う（在庫が適切に管理されているかは、関係ない） 商品を選ぶ（表示されているかは関係ないかもしれない。希望商品があるかどうか問い合わせる方法もある。） もちろん、関係ある場合は、 記述すべき。

アクタ サービスを受ける人のこと。 Ex）名簿システム システムに対する「役割」で考える 本名簿システムは、Aさん、Bさん、Cさん、が利用します。 3名とも、システムに対する役割は一緒なので、「ユーザ」アクタとして同じに取り扱う。 システムから見て、同じに役割に見える人は、同じアクタとして扱う。 しかし、管理する人がいる場合は、違う役割を持っているので、「管理者」アクタを追加する。 システムから見て、ユーザにはできないことができるから、役割が違う。 Aさんが、管理者を兼ねても良い

ケーススタディー

自動販売機システム

シナリオ 近くにある、ジュースの自動販売機を想像した。 山田くんは、まず500円玉を投入した。商品ディスプレイのサンプルを見て、値段が安かった100円のドクターペッパーを買うことに決め、ボタンを押した。自動販売機の下にある取り口から缶を取り出し、おつりである400円を受け取った。

まず、ユースケースを洗い出します。

だけど、ユーザから見れば、 結局は商品を買いたいんじゃ ないか！と思いました。

粒度の問題 しかし、「商品を買う」は、ほかのすべてを含ん でいるような気がします。 このようにレベルが違うユースケースが混じっ ていると、わかりにくくなってしまいます。 この問題は、モデルを考えているとしょっちゅう 出てきます。 これから、レベルのことを「粒度」と呼びます。

こう書くこともできますね。 ワークフロー ①利用者は、お金を投入する ②利用者は、商品の一覧を見る ③利用者は、希望する商品を選択する ④利用者は、希望した商品を受け取る

どちらがいいか？

こう書くこともできます。

3つのうち、どれにするか？ 答えは、ありません。（状況によります。） 3つの図の利点と欠点を考えてください。

ヒント 「ほしい商品があるか確認する」、「お金を入れる」、「商品を選択する」、「商品を受け取る」は、順番に行う必要があります。 すなわち、ワークフローだということです。ユースケースには、順番の指定はできないので、それを表せません。 イベントフローなら、あらわせます。 人間に分かりやすくするためにデザインされている、「取扱説明書」の粒度で考えるとわかりやすくなります。 取扱説明書には、どの粒度で書いてありますか？

ここで出す解答 これでよいというわけではありませんが ほしい商品があるか確認するのは、 商品を買う以前の問題なので、 商品を買うとは、別ものとした。 後は、ワークフローと考えた。

全体として、考えてみる 管理者もいます。

全体図

includeで書いた場合 こう書くこともできますが、 すべてにこのレベルがある場合は、 見づらくなってしまいます

その場合、図を何枚かに分けて書くと、わかりやすくなります。 本質的ユースケース図 詳細ユースケース図

考え方まとめ UC(UseCase)には、粒度がある。 粒度「レベル」を統一して書かないと、わかりにくくなってしまう。 粒度の異なる場合、さまざまな角度から考える。 includeを使うことができる。 ワークフロー、ビジネスロジックならば、一つに書ける。 ユースケース図だけですべてを表そうと考えるな！ 全体で考える。 図は、1枚でなくても良い。 とにかく、わかりやすさ重視。システムを「明らか」にする、という基準で。

名簿システム

グループのメンバー情報を管理するシステムを考えました。

名簿にはメンバーの個人情報が載っているので、次のようなユースケースが浮かびます。

アクタを追加する アクタは，一般的なユーザから考えました。 まず、名簿を利用する人がいますね。

名簿に載っている個人情報は、変更する必要があるかもしれません。 引越し 携帯電話換えましたとか

名簿はやっぱり見れなきゃ意味が無いですね。

個人情報を入力するって 変更などでも使わない？ 誤解を与える （書いた人は、新規作成の つもりだった）

名前を変更する 適切な名前に 変更します。

名簿に載っている情報は、 プライバシーに関わる情報なので、 誰でも見られるのはいやです。 だから、ログオンは必要でしょう。

ログオンを利用します。 単体では、深い目的が ありません

Includeを利用する

ログオンするということは、 アカウント・パスワードを持っている人と持っていない人がいるということ。 システムから見て違う役割！

アクタを追加する ＜未登録ユーザ＞ 定義： システムの利用者 まだシステムの利用権限は 与えられていない 目的： 未登録ユーザにシステム利用権限を与える

最終案

考え方まとめ 適切な名前を付けないと、誤解される。 適切にIncludeを利用するとわかりやすくなる。 役割が違うときは、アクタを別にする。 さらにユースケース文書で補う。 適切にIncludeを利用するとわかりやすくなる。 役割が違うときは、アクタを別にする。

目覚し時計システム

家にある、置時計を想像しました。

時計は、時間を知るために使うので、次のようなユースケースが浮かびます 目的： 現在の時刻を知るため イベントフロー： ①ユーザは、時計を見ます。 ②時計は、現在時刻を表示します。 ③ユーザは、表示されている時刻を見て、現在時刻を知ります。

アクタは、まず、一般的なユーザから考えました。 時計システムは、使うすべての人を区別しないので１種類でよい

目覚し時計なので、アラームを使うことを考えました。

「アラームが鳴る」イベントフローを考えましたが、うまくいきません。 サービスは、ポッと現れるはずがない。 押し売りになってしまう。 そもそも、勝手にアラームがなるはずがない。 起きる時間を知っているのか？ このサービスはそもそも、 「ユーザが指定した時刻にアラームを鳴らしてくれる」 というサービスだ 「アラームが鳴る」は、単品でサービスにならない。と思う。

「アラームを使う」にまとめたほうが、わかりやすいと判断しました。 目的： 指定の時刻を確実に知るため イベントフロー： ①ユーザは、知らせてもらう時刻を設定します。 ②時計は、知らせてもらう時刻を表示します。 ③ユーザは、アラームのスイッチを入れます。 ④時計は、アラームのスイッチが入っていることを表示します。 ⑤時計は、指定時刻になると、アラームを鳴らします。 ⑥ユーザは、アラームをとめます。

考え方まとめ ユースケースは、最終目的を持っている ユースケースは、アクタが起動する。 本当にサービスなのかを考える ユースケースは、アクタが起動する。 サービスは、勝手に行われるものではない。アクタの意思で、開始される。 ユースケースは、開始と終了を明確にした方が、明らかになる。 アクタの意思で開始され、目的が達成されたところで終了する。

テキストエディタシステム

簡単な「メモ帳」をイメージしました。

以下のユースケースを思いつきました。

文書を印刷するというのは、このシステムの仕事なのか？ 確かに、ユーザに印刷するというサービスを提供するのだが、 プリンタにジョブを送るだけでは？ プリンタは、このシステム外の話である。 システム外のことなのに、ユースケースに書いたら、 システムが提供することになってしまう。

プリンタをアクタ（外部システム）として、記述します。 「テキストを印刷する」ユースケースは、ユーザから起動され、 プリンタという外部システムを利用して、サービスを実現する ことになります。 こうすると、システムの内部と外部が明らかになります。

同じ理屈で、文書を開いたり、保存したりするには、ファイルシステムを使います。

考え方まとめ 外部システムもアクタとして記述する システム内部と外部をはっきりさせるため