オブジェクトの広場のモデリング連載

広場

オブジェクトの広場でモデリングの連載が始まった。“モデリングカフェ「Square」〜UMLでモデリングを愉しもう〜 ”というタイトルである。
http://www.ogis-ri.co.jp/otc/hiroba/others/ModelingCafe/
# なんだか自分の連載と微妙に企画がかぶっている気もするが、この際細かいことは気にしないでおこう(笑)。

羽生さんの「楽々ERDレッスン」を読んだときもそう思ったが、最近はモデリングに関する取っつきやすい記事が求められているのかもしれない。Javaや.netが普及したので、オブジェクト指向やUMLに対する抵抗がなくなったからだろうか？あるいはOOPに関係なく、永続化するデータ構造の定義を間違えると、システムがヒドいことになると気づいた人が増えたからだろうか？いずれにしても、こういう記事の登場は、とっても良いことだと思う。

その上で、この記事に関して、ちょいと揚げ足取りのイチャモンをつけておこうと思う。
# ちなみに著者は知り合いなので、悪気は全くありませんよー。

記事を読んで一番引っかかったのは、モデリングの目的を与えていないことである。お題の「打ち合わせ」で、

[参加者]2..* - 0..*[打ち合わせ]0..* - 1[会議室]

のクラス図が導かれるロジックにはまったく納得できなかった。だってクラス図は明らかに、会議室予約を記録する帳簿情報や、会議室予約システムで管理するデータ構造を表現しているのに、そんなことは一言も書かれてないから。

お題の文章には、長谷川さんが2つの会議に呼ばれた話が書かれている。しかし、それを素直に表現するなら、クラス図ではなくオブジェクト図だろう。また、自分が会議に呼ばれたときに「会議と参加者、会議室の三者の構造が重要な特徴」と考えるのは不自然だと思う。だって会議に呼ばれたときにまず確認するのは自分自身のスケジュールだし、次に考えるのはその会議の重要性や自分にとっての優先度のはずだから。

話の筋道をきちんと通すならば、結論がクラス図になる動機をきちんと与えるべきである。たとえば次のような感じで。

  • 「長谷川さんは以前から、同期入社で総務に配属された才色麗子さんに好意を持っていた。ある日彼女から“会議室の予約手続きで困っているので助けて欲しい”と頼まれたので、麗子さんと念願のデートをするためにAccessを使ったシステムを作ろうと決めた。そのシステムで管理する情報をクラス図に描いて麗子さんに見せたところ、“UMLってよくわからないけど、私のためにそんな難しい設計図を描いてくれてありがとう！”と感謝された。」

モデリングの目的がハッキリしてないのに“重要な性質が何か”を議論するなんて無意味である。

# 素晴らしい企画をスタートしたのに、変なイチャモンをつけてごめんなさいね、id:Akaponさん。

ところでこの企画では、Elapiz Basicのライセンスが当たるらしい。せっかくだから応募してみようかな。でもこんなこと書いたので、無視されるか、吊し上げられるかのどちらかになるのは間違いね、こりゃ(笑)。