ユースケース図を教える

「誰が何をする」。ユースケース図を教えるということは、「システムとは何ぞや」を教えることと同じこと。描き方ではなく使い方が大事です。

ユースケース図を教えるのは、楽なものです。

これだけ。

ここで生徒たちは、油断したもよう。

 なんすか、その絵は?絵にする必要あるんすか?
 スティックマンってぇ・・・棒人間! ゲラゲラ~ ヘラヘラ~

おめーらー、要件定義をなめんじゃねー(怒
・・・というわけで、今日の授業開始です。

「描き方」じゃなくて「使い方」

お客さんの要求というのは、いろんな表現があります。

  日々の仕事で楽がしたい
  面白いサービスを提供したい
  コミュニケーションを円滑にしたい
  アイツが悪い アタマにくる
  体調が悪い 酒の飲みすぎ
      :

こういうお客さんの要望をぜんぶ余すことなく、誰が、何をするに翻訳する。つまりは、要求への「視点」と「結果」を過不足なく洗い出すこと。それがユースケース図というわけです。

漠然として複雑怪奇な(アナログな)会話から、この研ぎ澄まされたモデルを見つけるのは、かなりアタマを使う、そして、骨の折れる作業。逆に言えば、複雑怪奇なものを、いかに単純化するか。
ここがエンジニアの腕であり、UMLはそのための道具なのです。

試しにブログのユースケース

ブログシステムのユースケースを描いてみることにしました。あーだこーだと話合いながら、作ってみたのは、こんな感じ。


作っていく中で、間違えるであろうところを、案の定、間違えてくれました(だから大好きだよ、おまえたち)。

間違い例を2つ紹介します。

ユースケースは、画面遷移ではありません。「確認する」はユースケースから削除しました。次、

会員が製本するわけではありません。誰が製本するの?と考えれば、次のようになるはずです。


もちろん、このユースケースひとつひとつにイベントフロー(ユースケースシナリオ)があります。基本フローと代替フローも書き出して、ちゃんと動くか検証しなければなりません。

ブログという、既に仕様が決まっているシステムのユースケースを描くだけでも、かなり難しい作業。

  全く新しいシステムを作ることを考えてみろ。
  コンピューターを知らないおじさんが語る夢を、ユースケースにしてみろ。

・・・生徒たちはグウの音も出なくなりました。

わかったか、おまえたち。道は長いんだぞ。


コメント
さらしなこ
2006/11/09
理論的に物事を考えること、
私は苦手なんですが、
とても大切なことなんですね。
どんな仕事においても・・・。
武田ソフト
2006/11/10
さらしなこさん、コメントありがとうございます。
動くものを作るときには理論は大切だと思いますが、世の中の全ての仕事が理詰めだとは思いません・・。私は仕事柄、熱中すると、ゼロかイチか!みたいな考え方になりがちで、まわりから注意されることが多いです ^^;
koba
2006/11/10
どうも。こちらのブログは初コメントかもしれません。

ユースケース、べ・・・勉強になったっす!
正直、お仕事でこれをちゃんと活用したことないんです。
我々に仕事が落ちてくる頃には、シーケンス図とクラス図がメインになってしまいまして・・・。
これからも講師がんばってください。
武田ソフト
2006/11/11
kobaさん、コメントありがとうございます。
専門家の方にツッコみいただくと、ホントにこれで良いのか
不安になります。・・・いや、勉強になりますw
これからもよろしくお願いします。
monya
2006/11/13
そうですよね〜、実際は「なんだかこんなことコンピュータでちゃちゃっとできんでねぇの?ボタンぽちっと押せばばーっと表示してぱぱっと計算して」みたいな会話から始まったりしますよね。
私も勉強になります。今後もこのシリーズ楽しみです。
武田ソフト
2006/11/13
monyaさん、こんにちわ。
私自身も、バーとやってドーンとできんだろー!
と、擬態語が多い方です。
考えてることが言葉にならない時、こんな風になります。
これを言葉にするのが、「仕事」なんでしょうね。

コメントしてください

closed.