久しぶりのモデリング道場。 - わたしの髪が長いのは

http://www.mamezou.com/tec/mamenight/history/014_ModelingDOJO04/ModelingDOJO04.html
これは前回の様子ですが。ちなみに前回も行きましたけど。
今回は皆川さんと長谷川さんが担当。
まずはモデリング道場訓からでしたが略。。

モデリングって、曖昧な定義になりがちだから、
前提条件って必要だと思うんですよね。
「これは分析レベルですよー」とか。
「今回はシステムについても考えましょうねー」とか。
モデリング道場の道場訓みたいな感じで、
トークする前に確認することって重要だと思うんですよ。
よくよく考えればあたりまえのことなんですけどね。これは。
会議の目的をはっきりさせること。。
Agendaの無いミーティングをしないようにすること。。
ああ、どこかでそれが出来ていない会社があった気がするよ…。

その後、ユースケースとは何か。
ユースケース図とユースケースドキュメントの役割ですね。
あとアクターとアクター間の関係。汎化ですけど。
ユースケースとユースケース間の関係について。includeとかextendとか。

extendってあんま必要ないですよねー。
ユースケースの穴埋めに使うって言ってたけど、
そんならもともとそのユースケースに記述しちゃえばいいわけだし。
kdmsnrタンがextendはつかわねー。って言う案に同意。
どうしても使わなきゃいけないときは、
ユースケースががっちりまとまったあとに、
仕様追加としての記述に使う。
元々無かったものを足しましたよーー。というときのみ。
そんなオレなりの結論。

で、さくっと白帯稽古に。
白帯稽古は与えられた美容院というものをシステムとしてとらえたときの微妙なユースケース図について変だと思うところをあげろ。と。
図がないと説明しにくいなぁ。。
とりあえず参考になったのが粒度の話。
「予約する」「予約を変更する」「キャンセルする」
っていうユースケースがあったんだが、
これを「予約する」にまとめちゃって良いんでないか？という人がいた。
それに対する答えは、
「ビジネス的なユースケースとしてならまとめちゃってよいが、
システム的にとらえると分けた方がいいんでないかい？」
とのこと。アクターが「予約する」ときと「キャンセルする」ときは別のタイミングでしょ？と。
まぁ、その図の前提条件が語られてなかったから揉めるのはあたりまえだったんですがね。
あとは「料金を支払う」ってユースケースがあったんですが、
料金支払いにだけ美容院行く人いないよね？じゃあ、ほかのユースケースのincludeで。と。なる。
そんで、休憩はさんで黒帯稽古。幹事さん支援システム『鍋奉行』ですって。
分析レベルをかけって言ってるのに、みんな言うことが細かいこと細かいこと。
まぁ、機能概要が詳細に書かれていたのに流された感もありますが。
分析レベルは書かなくて良いんですよー。
アクターに「メールサーバー」とかは出てきません！
まぁ、詳細なレベルになると出てくるんでしょうが。自動実行するアクター「Timer」とか。

引っかけのために分析レベルであることをアピールしなかったんでしょうけど、
そのトラップのために、本質的に重要なことを言う時間が減っちゃった気がします。
いい話は聞けたと思うんですが、後味が微妙な２時間でしたとさ。