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

これだけ。

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

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

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

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

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

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


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

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

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

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


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

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

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

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