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