モデリングカフェ第1回のお題
以前のエントリで取り上げたオブジェクトの広場の企画に応募してみた。
http://www.ogis-ri.co.jp/otc/hiroba/others/ModelingCafe/01.html
以下は、編集部に送った解答である。
改めてお題を読んでみたが、正直なところどうしようか悩んでしまった。お題の文章は次の通りである。
【お題01】連絡網
ゆうじ君たちは以下のように連絡をとることになっています。
この状況をモデリングしてください。
この文章にオブジェクト図っぽい絵が描かれているだけ、うーん..
漠然としたお題を与えて、自分で解釈しながらモデリングしてみればいろいろ発見がありますよ、という出題の意図なのだろうが、ちょっと手の出しようがない。
しかし、くじけずに次の順序で考えてみることにした。
- モデリングの目的をどうするか
- お題の文章をどう解釈するか
- クラス図でどう表現するか
1. モデリングの目的
最初に考えるべきことはモデリングの目的である。モノのとらえ方なんて、関心によってまるで変わるから、目的を決めないと考えようがない。“見たまま感じたままをモデリングする”なんていう流儀もあるのかも知れないが、自分はそういう方面にはとんと興味がない。と、まぁ言いたいことは相変わらずたくさんあるが、この件に関しては以前のエントリ(id:ahirasawa:20051211)でだいぶツッコんだので今回はこれぐらいにしておく。基本的に、概念モデリングは、集合論で複雑な物事や事象を客観的に整理することだから、コンピュータシステムの要件定義に適している。コンピュータシステムの要件定義は、現実世界の複雑な仕事を「決まり切った仕事」に置き換えることだし、大容量のディスクを使った「覚える仕事」にするために、情報を決まった形に定義することだから。
とはいえ、集合論は複雑な物事を整理して理解する目的にも応用できる。しかし実世界で暮らしていてそういう場面に出会うことは非常に少ない。したがって、ここではモデリングの目的を連絡網登録ツールを作るためとしておく。しかし、連絡網登録ツールなんてワープロで十分じゃないの？などと考え始めると、本題に入れなくなるので、このことについてこれ以上深入りしない。
2. お題の解釈
先ほども書いたように、お題の文章からはほとんど得る情報がない。したがって、ここはシャーロック・ホームズ風に深読みしてみる。すぐに気がつくのは、登場人物の名前がひらがなのファーストネームになっていることだ。これは連絡網の利用者の中に漢字を読めない人がいることを意味する。小学校でも高学年ぐらいになると、かなりの量の漢字を読めるようになるから、小学校低学年以下の子供を対象ユーザーにしていると推察できる。また保護者の名前が書いていないことから、子供自身を連絡者に想定していることもわかる。そうなると幼稚園児ではないだろう。したがって小学低学年、すなわち1年生か2年生を対象にした連絡網と考えるのが妥当だろう。とはいえ解せないのは子供の名前だ。「ゆうじ」「まゆみ」「ともよ」「ようすけ」は一般的な名前だが、今風の名前ではない。最近の小学生なら、男の子は「だいき」「かいと」「しょう」、女の子なら「みさき」「まい」「あやの」あたりが普通の名前だ。したがってお題の図は、今から20-30年前ぐらいのどこかの小学校で使われていた連絡網を転載したものと考えるのが妥当だろう。
さて、名前に関する能書きはこれぐらいにして(笑)、そろそろモデリングの話に入ろう。お題の絵を見る限り、連絡網は次のようになっている。
- ある人は次の連絡先を複数持つことがある。
- 複数の人から連絡される人はいない。
よくある連絡網として、重要な連絡が確実に伝わったかを確認するために、最後の人がとりまとめの人に連絡を入れるケースがある。しかしお題の絵を見る限りでは、このことについての配慮は要らないようだ。
またいったいどうやって連絡するのか、という疑問も沸く。お題には電話番号のことは一言も書かれていない。しかし、常識で考えろ、ということと判断して、普通に電話で連絡するものと解釈しておく。
3. モデルの表現
さて、前置きが長くなったが、ここからが本題のモデルの話である(笑)。
お題の絵では1対多の関係が複数階層に及ぶツリー構造になっているから、普通にツリー構造で表現すると次のようになる。
実際には再帰関連で多重度を書いただけでは、ツリー構造を指定したことにならないので、適当にノートアイコンで補足しておく。本来ならOCLを使うべきなのだろうが、現場で通用しづらい技術は使わないことにしているので、やめておく。（実際はふだん使ってないのでOCLの文法をよく知らない、というのがホントの理由）。
3.2 Compositeパターンによるツリー構造
ツリー構造と言えば、やはりGoFのCompositeパターンなので、一応書いてみる。
しかし連絡網で、末端の人と中間／先頭の人を区別するのはいかにも不自然なので、一応書いてはみたものの却下。
3.3 関連エンティティ別出し
次は、3.1のもう一つの変形として、関連エンティティを別出しにしたモデルである。
多重度が1:NならばRDBでも参照キーで実装できるため、わざわざ関連エンティティを別出しする必要はない。しかし、このモデルは意外と悪くない感じである。なぜならば、児童の個人情報と連絡網はそれぞれ独立した情報と考えても良さそうだからだ。児童の個人情報を管理するシステムが先にあって、それに影響を及ぼさずに連絡網のシステムを外付けで作りたいような場合には有効かも知れない。
3.4 実体とロールの分離
最後はちょっとトリッキーなモデルである。「連絡する人」と「連絡を受ける人」をロールとして切り出してみた。
このモデルにすると、関連の多重度を1対1..Nにできるが、それ以外のメリットはほとんどない。こんな場面で使えそう、という例も思いつかない。
ということで、モデルの表現については、オーソドックスな3.1がイチ押しで、次は3.3ということになる。しかし、何度も書いているように、目的やお題の解釈がちょっとでも変われば、モデルの表現なんてガラッと変わってしまう。
