モデリングカフェ 第1回：連絡網をモデリングする（読者解答モデル）

読者の皆様から、たくさんの解答モデルを頂きました。ありがとうございました。こちらのページでは、残念ながら本文で紹介することができなかった解答モデルを記載します。オブジェクトの広場 メーリングリスト等で意見交換していただければ幸いです。

• むらたおさむ 様の解答モデル
• ともちゃん 様の解答モデル
• 松田政博 様の解答モデル
• ひらさわ 様の解答モデル
• 徳永亮 様の解答モデル
• まるごん 様の解答モデル

読者解答1：むらたおさむ 様

コンセプト

みたままを描いてみました。

モデル

図 1 むらたおさむ 様の解答モデル

感想

• 難しかったところ

  連絡の内容が途中で変わることがない、という前提です。

• 自己評価

  連絡内容が複数あると困るなあ。

読者解答2：ともちゃん 様

コンセプト

• 連絡網には、メンバーID、連絡先名前、連絡先電話番号の情報がある
• 連絡網のメンバーは、連絡する事（連絡者）と連絡を受ける事（連絡先）が出来る
• メンバーは複数の連絡網のメンバーとなることが出来る

モデル

図 2 ともちゃん 様の解答モデル

感想

• 難しかったところ
  • モデルのコンセプトの抽出
  • 連絡網クラスの属性の決定
• 自己評価
  • 連絡網とメンバーの関係については、モデリングできているかと思うが、重要な特徴が漏れているのではないかと不安である。

読者解答3：松田政博 様

コンセプト

• 連絡網では、連絡する人（連絡元）と連絡される人（連絡先）がいる。
• 連絡元は複数の連絡先を担当する可能性がある。
• 連絡先の人には、次に連絡する必要がない人がいる。（連絡網終端）
• 連絡元である連絡網連絡担当は、連絡先の種類に関わらず連絡網として扱う。

モデル

• クラス図

  
  図 3.1 松田政博 様の解答モデル - クラス図

• オブジェクト図

  
  図 3.2 松田政博 様の解答モデル - オブジェクト図

感想

• 難しかったところ

  適切なクラス名が見つからず悩みました。 更に適切なクラス名と思いながらも、締め切り近づいてきたので、読み手が理解できればよいとしました。

• 自己評価

  連絡網を構成するメンバの役割が変わったとき、オブジェクトの再生成やリンクの張りなおしが必要なのが気になっています。 例えば、ゆみこは、連絡網終端であるが、連絡網連絡担当になった場合です。

読者解答4：ひらさわ 様

ひらさわ 様はblogに解答モデルを公開されています。

背景

モデリングの目的

最初に考えるべきことはモデリングの目的である。 モノのとらえ方なんて、関心によってまるで変わるから、目的を決めないと考えようがない。 ”見たまま感じたままをモデリングする”なんていう流儀もあるのかも知れないが、自分はそういう方面にはとんと興味がない。 と、まぁ言いたいことは相変わらずたくさんあるが、この件に関しては以前のエントリでだいぶツッコんだので今回はこれぐらいにしておく。

基本的に、概念モデリングは、集合論で複雑な物事や事象を客観的に整理することだから、コンピュータシステムの要件定義に適している。 コンピュータシステムの要件定義は、現実世界の複雑な仕事を「決まり切った仕事」に置き換えることだし、大容量のディスクを使った「覚える仕事」にするために、情報を決まった形に定義することだから。

とはいえ、集合論は複雑な物事を整理して理解する目的にも応用できる。 しかし実世界で暮らしていてそういう場面に出会うことは非常に少ない。 したがって、ここではモデリングの目的を連絡網登録ツールを作るためとしておく。 しかし、連絡網登録ツールなんてワープロで十分じゃないの？などと考え始めると、本題に入れなくなるので、このことについてこれ以上深入りしない。

お題の解釈

先ほども書いたように、お題の文章からはほとんど得る情報がない。 したがって、ここはシャーロック・ホームズ風に深読みしてみる。

すぐに気がつくのは、登場人物の名前がひらがなのファーストネームになっていることだ。 これは連絡網の利用者の中に漢字を読めない人がいることを意味する。 小学校でも高学年ぐらいになると、かなりの量の漢字を読めるようになるから、小学校低学年以下の子供を対象ユーザーにしていると推察できる。 また保護者の名前が書いていないことから、子供自身を連絡者に想定していることもわかる。 そうなると幼稚園児ではないだろう。 したがって小学低学年、すなわち1年生か2年生を対象にした連絡網と考えるのが妥当だろう。 とはいえ解せないのは子供の名前だ。 「ゆうじ」「まゆみ」「ともよ」「ようすけ」は一般的な名前だが、今風の名前ではない。 最近の小学生なら、男の子は「だいき」「かいと」「しょう」、女の子なら「みさき」「まい」「あやの」あたりが普通の名前だ。 お題の図は、今から20-30年前ぐらいのどこかの小学校で使われていた連絡網を転載したものと考えるのが妥当だろう。

さて、名前に関する能書きはこれぐらいにして(笑)、そろそろモデリングの話に入ろう。 お題の絵を見る限り、連絡網は次のようになっている。

• ある人は次の連絡先を複数持つことがある。
• 複数の人から連絡される人はいない。

よくある連絡網として、重要な連絡が確実に伝わったかを確認するために、最後の人が最初の人に連絡を入れるケースがある。 しかしお題の絵を見る限りでは、このことについての配慮は要らないようだ。

またいったいどうやって連絡するのか、という疑問も沸く。 お題には電話番号のことは一言も書かれていない。 しかし、常識で考えろ、ということと判断して、普通に電話で連絡するものと解釈しておく。

モデルとコメント

再帰関連による木構造

お題の絵では1対多の関係が複数階層に及ぶツリー構造になっているから、普通にツリー構造で表現すると次のようになる。

図 4.1 ひらさわ 様の解答モデル1 - 再帰関連による木構造

実際には再帰関連で多重度を書いただけでは、ツリー構造を指定したことにならないので、適当にノートアイコンで補足しておく。 本来ならOCLを使うべきなのだろうが、現場で通用しづらい技術は使わないことにしているので、やめておく。（実際はふだん使ってないのでOCLの文法をよく知らない、というのがホントの理由）。

Compositeパターンによるツリー構造

ツリー構造と言えば、やはりGoFのCompositeパターンなので、一応書いてみる。

図 4.2 ひらさわ 様の解答モデル2 - Compositeパターンによるツリー構造

しかし連絡網で、末端の人と中間／先頭の人を区別するのはいかにも不自然である。 ということでこれは一応書いてはみたものの却下。

関連エンティティ別出し

次は、1のもう一つの変形として、関連エンティティを別出しにしたモデルである。

図 4.3 ひらさわ 様の解答モデル3 - 関連エンティティ別出し

多重度が1:NならばRDBでも参照キーで実装できるため、わざわざ関連エンティティを別出しする必要はない。 しかし、このモデルは意外と悪くない感じである。 なぜならば、児童の個人情報と連絡網を独立した情報と考えても良さそうだからだ。 児童の個人情報を管理するシステムが先にあって、それに影響を及ぼさずに連絡網のシステムを外付けで作りたいような場合には有効かも知れない。

実体とロールの分離

最後はちょっとトリッキーなモデルである。 「連絡する人」と「連絡を受ける人」をロールとして切り出したモデルである。

図 4.4 ひらさわ 様の解答モデル4 - 実体とロールの分離

このモデルにすると、関連の多重度を1対1..Nにできるが、それ以外のメリットはほとんどない。 こんな場面で使えそう、という例も思いつかない。

結論

ということで、モデルの表現については、オーソドックスな 1 がイチ押しで、次は 3 ということになる。 しかし、何度も書いているように、モデリングの目的やお題の解釈がちょっとでも変われば、モデルの表現なんてガラッと変わってしまう。

読者解答5：徳永亮 様

コンセプト

とにかくシンプルに。

モデル

図 5 徳永亮 様の解答モデル

感想

• 難しかったところ

  連絡網のツリーの根と葉を意識した多重度

• 自己評価

  連絡オブジェクトと人オブジェクトのリンクが動的に増えるという設計よりも良いものがありそうなので６０点。

読者解答6：まるごん 様

コンセプト

メンバー全員に各1回伝達されること、リーダーは、最終伝達者から確認の連絡を受けること。

モデル

図 6 まるごん 様の解答モデル

感想

• 難しかったところ

  サークルのメンバーを3種類に汎化したところ。 伝達内容をクラスとすることも考えたが、伝達が正確に行われた場合には、オブジェクトとしての存在価値はないので、サークル員クラスだけの構成とした。

• 自己評価

  12月から独学でＵＭＬを始めました。その割には上出来かな？と思っております。