Transcript ユースケース説明のパワーポイントファイル

ユースケースモデルの作成
GOAL
• シナリオが与えられたとき、人に伝わる
ユースケースモデルが書けるようになる。
Objective
• ユースケースモデルを使う利点を説明でき
るようになる。
• シナリオが与えられたとき、適切にユース
ケースを抽出できるようになる。
• シナリオが与えられたとき、適切にアクタを
抽出できるようになる。
• 「サービスを明らかにする」について議論
することができるようになる。
人を幸せにするシステム
• ソフトウエアには、「人を幸せにするサービ
スを提供する」という使命がある。
– ワープロであれば、文書を書いて、印刷すると
いうサービスを提供します。
– 表計算システムでは、ある行の数字を全部足
して、合計を出したり、並び替えを行ったりす
るサービスを提供します。
人を幸せにするサービス
• 「そんなの簡単ジャン！」
– 意外に難しい。
– 皆さんも、多かれ少なかれ、「使いにくいソフト
ウエア」に不満をもったことがあるでしょう。
• ケーススタディー
– (HTS)HyperTransactionSystemの失敗
ケーススタディー(概要)
• ① 開発チームの作成したものは、××さん（クライアント）の想像
していたものとは、異なっていた。
• ② どこが異なるかというと、××さん（クライアント）が思っていた
「あってしかるべき機能がなかった」ことであった。
• ③ しかし、開発チームは、４月時点での仕様書に書かれていない
機能は実装しなかった。
• ④ ソフトウエアができ、実際に使うときになって問題が発覚した。
• ⑤ ××さん（クライアント）は、「性能が悪い」といって激怒した。
• ⑥ 開発チームは、作り直しを求められたが、仕様書に書かれてい
ないと反論した。
• ⑦ １ヶ月間、水掛け論が続き、ユーザはその間使いづらいソフトウ
エアを使わされ、そのソフトウエアの評価が落ちた。
ケーススタディー(原因)
• ① 仕様書は、４月に作成されたが、開発チーム
が作ったものであり、実証実験チームは、その意
味がわからなかった。
• ② 実証実験チームは、８月にソフトウエアがで
きるまで、プロジェクトに参加しなかった。（実証
実験だけやればいいと思っていた。）
• ③ 開発チームは、仕様書の機能を満たし、試験
にパスすれば、良いソフトウエアができると信じ
ていた。
失敗の本質
• ソフトウエアを作り始める段階で、「これから作る
ものを明らかにする」ことをしなかった。
– 完成イメージが人それぞれ違っていた。
• この問題は、人間が言葉を使って、暗黙の了解
を続けている間は、避けられない問題です。
– 「時計」システムを作ってください。
– 「ワープロ」システムを作ってください。
「時計」システム
• あなたの考える「時計」システムを考えてく
ださい。
–
–
–
–
–
それは、腕時計ですか？置時計ですか？
それは、デジタルですか？アナログですか？
24時間表示ですか？12時間表示ですか？
アラームはついてますか？
現在時刻を再設定できますか？それは、どの
ように行いますか？
ユースケースモデル
• ユースケースモデルを書く目的は、
「作るシステムを明らかにする」ことです。
– 「明らか」とはどういう意味ですか？
– 「明らか」になると、どのようないいことがありますか？
• 発注者（クライアント）と開発者の思っていることの食い違い
を防げる。
– 「作るものと、作らないもの」の意見の食い違いを防げる。
• 開発者の間での思っていることの食い違いを防げる。
• 自分で作るものがはっきりする。
• 作るものが、本当に必要かどうか、議論できる。
ユースケース
• 「ユーザ」がどのように使うのかを考える。
– システムの「機能」ではなく、ユーザが受ける「サービ
ス」で考える。
– システムの「機能」をユーザが何のために利用するの
かを考える。
• Ex)「自動販売機」システムの場合
– 機能
• 在庫管理機能
• 販売商品表示機能
もちろん、関係ある場合は、
記述すべき。
– サービス
• 商品を買う（在庫が適切に管理されているかは、関係ない）
• 商品を選ぶ（表示されているかは関係ないかもしれない。希
望商品があるかどうか問い合わせる方法もある。）
アクタ
• サービスを受ける人のこと。
– システムに対する「役割」で考える
• Ex）名簿システム
– 本名簿システムは、Aさん、Bさん、Cさん、が利用しま
す。
– 3名とも、システムに対する役割は一緒なので、「ユー
ザ」アクタとして同じに取り扱う。
– システムから見て、同じに役割に見える人は、同じアクタとして
扱う。
– しかし、管理する人がいる場合は、違う役割を持って
いるので、「管理者」アクタを追加する。
– システムから見て、ユーザにはできないことができるから、役割
が違う。
– Aさんが、管理者を兼ねても良い
ケーススタディー
自動販売機システム
シナリオ
• 近くにある、ジュースの自動販売機を想像した。
• 山田くんは、まず500円玉を投入した。商品ディス
プレイのサンプルを見て、値段が安かった100円
のドクターペッパーを買うことに決め、ボタンを押
した。自動販売機の下にある取り口から缶を取り
出し、おつりである400円を受け取った。
• まず、ユースケースを洗い出します。
欲しい商品があるか確認する
お金を投入する
購入者
商品を選ぶ
商品を受け取る
欲しい商品があるか確認する
お金を投入する
購入者
商品を選ぶ
商品を受け取る
商品を買う
だけど、ユーザから見れば、
結局は商品を買いたいんじゃ
ないか！と思いました。
粒度の問題
欲しい商品があるか確認する
お金を投入する
購入者
商品を選ぶ
商品を受け取る
商品を買う
しかし、「商品を買う」は、ほかのすべてを含ん
でいるような気がします。
このようにレベルが違うユースケースが混じっ
ていると、わかりにくくなってしまいます。
この問題は、モデルを考えているとしょっちゅう
出てきます。
これから、レベルのことを「粒度」と呼びます。
• こう書くこともできますね。
購入者
商品を買う
ワークフロー
①利用者は、お金を投入する
②利用者は、商品の一覧を見る
③利用者は、希望する商品を選択する
④利用者は、希望した商品を受け取る
どちらがいいか？
欲しい商品があるか確認する
お金を投入する
購入者
購入者
商品を選ぶ
商品を受け取る
商品を買う
こう書くこともできます。
欲しい商品があるか確認する
<<include>>
<<include>>
お金を投入する
購入者
商品を買う
<<include>>
<<include>>
商品を選ぶ
商品を受け取る
3つのうち、どれにするか？
• 答えは、ありません。（状況によります。）
• 3つの図の利点と欠点を考えてください。
ヒント
• 「ほしい商品があるか確認する」、「お金を入れ
る」、「商品を選択する」、「商品を受け取る」は、
順番に行う必要があります。
– すなわち、ワークフローだということです。ユースケー
スには、順番の指定はできないので、それを表せませ
ん。
– イベントフローなら、あらわせます。
• 人間に分かりやすくするためにデザインされてい
る、「取扱説明書」の粒度で考えるとわかりやすく
なります。
– 取扱説明書には、どの粒度で書いてありますか？
ここで出す解答
• これでよいというわけではありませんが
欲しい商品があるか確認する
購入者
商品を買う
ほしい商品があるか確認するのは、
商品を買う以前の問題なので、
商品を買うとは、別ものとした。
後は、ワークフローと考えた。
全体として、考えてみる
• 管理者もいます。
売上を回収する
ジュースを補充する
管理者
おつりを補充する
商品を変更する
全体図
売上を回収する
商品を買う
ジュースを補充する
管理者
購入者
欲しい商品があるか確認する おつりを補充する
商品を変更する
includeで書いた場合
<<include>>
商品を選ぶ
<<include>>
商品を買う
<<include>>お金を投入する
購入者
欲しい商品があるか確認する
売上を回収する
ジュースを補充する
管理者
おつりを補充する
商品を変更する
商品を受け取る
こう書くこともできますが、
すべてにこのレベルがある場合は、
見づらくなってしまいます
• その場合、図を何枚かに分けて書くと、わ
かりやすくなります。
売上を回収する
<<include>>
商品を選ぶ
<<include>>
商品を買う
ジュースを補充する
管理者
商品を買う
購入者
<<include>>お金を投入する
購入者
欲しい商品があるか確認する おつりを補充する
欲しい商品があるか確認する
商品を受け取る
商品を変更する
本質的ユースケース図
詳細ユースケース図
考え方まとめ
• UC(UseCase)には、粒度がある。
• 粒度「レベル」を統一して書かないと、わかりにく
くなってしまう。
• 粒度の異なる場合、さまざまな角度から考える。
–
–
–
–
includeを使うことができる。
ワークフロー、ビジネスロジックならば、一つに書ける。
ユースケース図だけですべてを表そうと考えるな！
全体で考える。
• 図は、1枚でなくても良い。
– とにかく、わかりやすさ重視。システムを「明らか」にす
る、という基準で。
名簿システム
• グループのメンバー情報を管理するシステ
ムを考えました。
氏名
太田　○○
田中　△△
中村　●●
所属
環境情報
総合政策
政策・メディア
住所
東京都○○区
神奈川県△△市
千葉県●●市
電話番号
03-xxxx-xxxx
045-xxx-xxxx
090-xxxx-xxxx
• 名簿にはメンバーの個人情報が載ってい
るので、次のようなユースケースが浮かび
ます。
目的：
個人データを名簿に載せるため
個人情報を入力する
イベントフロー：
①ユーザは、個人情報入力画面で自分の個人
情報を入力します
②ユーザは、入力情報を確定します
③システムは、個人情報登録完了画面を表示
します
④ユーザは、個人情報登録完了を確認します
アクタを追加する
• アクタは，一般的なユーザから考えました。
– まず、名簿を利用する人がいますね。
ユーザ
個人情報を入力する
• 名簿に載っている個人情報は、変更する
必要があるかもしれません。
– 引越し
– 携帯電話換えましたとか
ユーザ
個人情報を入力する
個人情報を変更する
個人情報を削除する
• 名簿はやっぱり見れなきゃ意味が無いで
すね。
個人情報を入力する
ユーザ
個人情報を変更する
個人情報を削除する
名簿を閲覧する
個人情報を入力する
ユーザ
個人情報を入力するって
変更などでも使わない？
個人情報を変更する
個人情報を削除する
名簿を閲覧する
誤解を与える
（書いた人は、新規作成の
つもりだった）
名前を変更する
適切な名前に
変更します。
個人情報を新規作成する
ユーザ
個人情報を変更する
個人情報を削除する
名簿を閲覧する
個人情報を新規作成する
ユーザ
個人情報を変更する
個人情報を削除する
名簿を閲覧する
ログオンする
名簿に載っている情報は、
プライバシーに関わる情報なので、
誰でも見られるのはいやです。
だから、ログオンは必要でしょう。
個人情報を新規作成する
ユーザ
個人情報を変更する
ログオンを利用します。
個人情報を削除する
名簿を閲覧する
ログオンする
単体では、深い目的が
ありません
Includeを利用する
個人情報を新規作成する
個人情報を変更する
<<include>>
<<include>>
ユーザ
個人情報を削除する
名簿を閲覧する
<<include>>
ログオンする
• ログオンするということは、
– アカウント・パスワードを持っている人と持って
いない人がいるということ。
• システムから見て違う役割！
個人情報を新規作成する
個人情報を変更する
<<include>>
<<include>>
ユーザ
個人情報を削除する
名簿を閲覧する
<<include>>
ログオンする
アクタを追加する
＜未登録ユーザ＞
定義：
システムの利用者
まだシステムの利用権限は
与えられていない
未登録ユーザ
目的：
未登録ユーザに
システム利用権限
を与える
個人情報を新規作成する
個人情報を変更する
<<include>>
<<include>>
ユーザ
個人情報を削除する
<<include>>
名簿を閲覧する
ログオンする
最終案
未登録ユーザ
個人情報を新規作成する
個人情報を変更する
<<include>>
<<include>>
ユーザ
個人情報を削除する
<<include>>
名簿を閲覧する
ログオンする
考え方まとめ
• 適切な名前を付けないと、誤解される。
– さらにユースケース文書で補う。
• 適切にIncludeを利用するとわかりやすくな
る。
• 役割が違うときは、アクタを別にする。
目覚し時計システム
• 家にある、置時計を想像しました。
• 時計は、時間を知るために使うので、次の
ようなユースケースが浮かびます
現在時刻を見る
目的：
現在の時刻を知るため
イベントフロー：
①ユーザは、時計を見ます。
②時計は、現在時刻を表示します。
③ユーザは、表示されている時刻を見て、現在時刻を知ります。
• アクタは、まず、一般的なユーザから考え
ました。
– 時計システムは、使うすべての人を区別しな
いので１種類でよい
ユーザ
現在時刻を見る
• 目覚し時計なので、アラームを使うことを
考えました。
現在時刻を見る
ユーザ
アラームをセットする
アラームが鳴る
アラームをとめる
• 「アラームが鳴る」イベントフローを考えま
したが、うまくいきません。
現在時刻を見る
ユーザ
アラームをセットする
アラームが鳴る
サービスは、ポッと現れるはずがない。
押し売りになってしまう。
そもそも、勝手にアラームがなるはずがない。
起きる時間を知っているのか？
このサービスはそもそも、
「ユーザが指定した時刻にアラームを鳴らしてくれる」
というサービスだ
「アラームが鳴る」は、単品でサービスにならない。と思う。
アラームをとめる
• 「アラームを使う」にまとめたほうが、わかり
やすいと判断しました。
現在時刻を見る
目的：
指定の時刻を確実に知るため
ユーザ
アラームを使う
イベントフロー：
①ユーザは、知らせてもらう時刻を設定します。
②時計は、知らせてもらう時刻を表示します。
③ユーザは、アラームのスイッチを入れます。
④時計は、アラームのスイッチが入っていることを表示します。
⑤時計は、指定時刻になると、アラームを鳴らします。
⑥ユーザは、アラームをとめます。
考え方まとめ
• ユースケースは、最終目的を持っている
– 本当にサービスなのかを考える
• ユースケースは、アクタが起動する。
– サービスは、勝手に行われるものではない。アクタの
意思で、開始される。
• ユースケースは、開始と終了を明確にした方が、
明らかになる。
– アクタの意思で開始され、目的が達成されたところで
終了する。
テキストエディタシステム
• 簡単な「メモ帳」をイメージしました。
• 以下のユースケースを思いつきました。
テキストを印刷する
テキストを保存する
ユーザ
テキストを開く
テキストを新規作成する
テキストを編集する
テキストを印刷する
テキストを保存する
ユーザ
テキストを開く
テキストを新規作成する
テキストを編集する
文書を印刷するというのは、このシステムの仕事なのか？
確かに、ユーザに印刷するというサービスを提供するのだが、
プリンタにジョブを送るだけでは？
プリンタは、このシステム外の話である。
システム外のことなのに、ユースケースに書いたら、
システムが提供することになってしまう。
テキストを印刷する
テキストを保存する
ユーザ
テキストを開く
プリンタ
プリンタをアクタ（外部システム）として、記述します。
「テキストを印刷する」ユースケースは、ユーザから起動され、
プリンタという外部システムを利用して、サービスを実現する
ことになります。
こうすると、システムの内部と外部が明らかになります。
テキストを新規作成する
テキストを編集する
テキストを印刷する
プリンタ
テキストを保存する
ファイルシステム
ユーザ
テキストを開く
テキストを新規作成する
テキストを編集する
同じ理屈で、文書を開いたり、保存したりするには、ファイルシステムを使います。
考え方まとめ
• 外部システムもアクタとして記述する
– システム内部と外部をはっきりさせるため
テキストを印刷する
プリンタ
テキストを保存する
ファイルシステム
ユーザ
テキストを開く
テキストを新規作成する
テキストを編集する