オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです
毎回、身近にあるモノや出来事など、簡単な【お題】を出題し、皆様にモデリングをして頂きます。次回の記事で、皆様の解答モデルの中から3つほど取り上げて、コメントを付けていくかたちで進めていきます。お知らせです。この連載は全6回（出題5回）の予定でしたが、連載を延長することとなりました。今月号より隔月にて連載を続けていきますので、今後ともよろしくお願い致します。
前回の問題をもう一度確認しておきましょう。
すごろくをモデリングしてください。
不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。
お題（すごろく）
解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです (解答時間の目安は15分～30分です)。
今回は、読者の皆様からこれまでで最多の解答モデルを頂きました。ありがとうございます。 これまでと同じように、3つの解答モデルをピックアップして、当カフェのマスターとヒトクセある！？常連たちと一緒に見ていきましょう。 皆様、飲み物の準備はできましたか？ リラックスして、一緒にわいわいやる感じで考えてみてください。 また、残念ながら紹介することができなかった解答モデルはこちらに掲載しますので、 オブジェクトの広場 メーリングリストなどで意見交換していただければ幸いです。
１）マスをつなげただけにするか、２）マスがすごろく盤の上にあるか、が判断しにくかった。 すごろく盤があった方が、より具体的にわかりやすいとおもい、「すごろく盤」を出した。
すごろくをシンプルに表現できていると思う。
| 久本くん | ぱっと見て、クラス図が縦に長いところが目を引きますね |
|
| 吉井さん | そうだね。みんなはクラス図のレイアウトで、どんなことに気を付けてる？ |
|
| 唐沢さん | 私の場合、抽象度が高いものや、より大きな概念のものを左か上の方へ配置します |
|
| 久本くん | 関連線が交差しないようにと、あと直角になるようにしてます |
|
| マスター | モノ－コト－モノの関係が見やすいように気を付けていますね |
|
| 吉井さん | あと、モデルの一番重要なところ、中心的な概念のところを中央付近に配置するといいね |
|
| 久本くん | レイアウトを変えただけでモデルが分かりやすくなったりして、面白いですよね |
|
| |
||
| マスター | 「すごろく盤」と「マス」の関係のところで悩まれたとのことです |
|
| 唐沢さん | 「マス」が１本道であることは「マス」の再帰関連で表現できています。「すごろく盤」と「マス」の関係も描くと冗長になりませんか？ |
|
| 久本くん | オブジェクト図を描くとリンクの数がすごく多くなりますね。冗長なんでしょうか |
|
| 吉井さん | その１点だけで見たらそうかもしれない。だけど「すごろく盤」を出すことでメリットもあるんじゃない？ |
|
| マスター | 考察されているように"わかりやすい"のではないでしょうか |
|
| 吉井さん | 「ふりだし」と「あがり」をどう表現するかかな。このモデルのようにすると「ふりだし」と「あがり」があることが自明になるね |
|
| |
||
| マスター | 「指示」が「マス」の属性になっていますね |
|
| 久本くん | 市販のすごろくゲームとか見ると、それぞれの「マス」に「指示」が書いてありますよね。直感的で分かりやすいです |
|
| 吉井さん | うん。素直に考えられているね |
|
| 唐沢さん | ですが、すごろくには指示がない「マス」もあります。その場合、属性には何が入るのでしょう |
|
| 久本くん | 空の文字列とか『指示なし』とかかな。ちょっと不自然かも |
|
| マスター | 属性はそのクラスのインスタンスを特徴付けるものですから、インスタンスによってあったりなかったりするのはどうでしょうか |
|
| 吉井さん | うん。そうやって考えてみると、「マス」と「指示」は別の概念として分けた方が良いのかもしれないね |
|
| |
||
| マスター | 少し文法を確認したいところがあります。「ふりだし」や「あがり」は関連名ではなくて、「マス」のロール名になるのではないでしょうか |
|
 図 2 「ふりだし」や「あがり」はロール名 |
||
| 吉井さん | そうだね。あと、「こま」と「マス」のところなど、多重度が間違っているかもしれないところとか、どういう関係なのか分かりにくいところがあるね。インスタンスを考えること、できればオブジェクト図を描くことと、関連にはロール名を出来る限り明記することを心掛けるといいね |
|
「こま」クラスはプレーヤーの分身となり，さいころを振ったり，すごろくのマス上を移動します．
「マス」クラスはすごろくのマップを表現するクラスです． となりのマスへのリンクを持っています． スタートマスとゴールマスは，「マス」が特殊化したものと考えました． マスに止まった場合の出来事（進む，戻る，休む）の実施を，イベントクラスに委譲します．
「イベント」クラスはマス上で起こる出来事を実施する責務を持っています． 複数のマスとリンクが貼られることもあります．
「進む」マスや「休む」マスも，マスの一種であり，「マス」クラスから特化させるという案も挙がりました．
このモデルには「イベント」と「コマ」の間に関連が無いため，「イベント」クラスにおいて休む()メソッドが発動された場合に，「コマ」クラスにメッセージを送ることができない． そもそも静的な関連はあるのか無いのか迷いました．
静的側面からは，すごろくを表現できていると考えています． しかし，動的な面を考えると，動作しないため，６０点位です．
| 久本くん | 先ほどのモデルとは違って、「スタートマス」「ゴールマス」を汎化関係を使って表現していますね |
|
| マスター | ええ、こういう表現方法もありますね |
|
| 吉井さん | 「普通のマス」というクラスは必要だと思う？ |
|
| 唐沢さん | あるべきなのではないでしょうか。でないと、「マス」のインスタンスは「スタートマス」と「ゴールマス」のいずれかになるという誤解を与えてしまいます |
|
| マスター | 「マス」は抽象クラスではないのでインスタンスを持てますね。でも確かに誤解してしまうかもしれません |
|
| 吉井さん | そうだね。「普通のマス」クラスを出しておいたほうが分かりやすいね |
|
| 久本くん | でも、この分け方だったら「スタートマス」と「ゴールマス」は「普通じゃないマス」のサブクラスにしないと分類の大きさが合わないんじゃないですか？ |
|
 図 4 普通じゃないマス？ |
||
| 吉井さん | 確かにそうだね。でも、分かりにくくならない？ |
|
| |
||
| 唐沢さん | 「スタートマス」や「ゴールマス」にはイベントはありません。だから、「マス」と「イベント」の関連は「普通のマス」と「イベント」の関連になるんじゃないでしょうか |
|
 図 5 「普通のマス」と「イベント」の関連 |
||
| 久本くん | 本当ですね |
|
| 吉井さん | でも、小さなことだから良いんじゃないかな。あまり細かいところに入り込まずに、大きく『マスにはイベントがある場合がある』と捉えることも大事なことだと思うよ |
|
| |
||
| マスター | 「イベント」と「コマ」の間に関連があるかどうかで悩まれたそうですが、関連がないと確かにメッセージが送れないのではないでしょうか |
|
| 久本くん | 問題の特徴を捉えるだけではなくて、動きの側面も考えられたんですね |
|
| 唐沢さん | 私は「イベント」と「コマ」には関連はなくて良いと思います。その関係というのはイベントの処理を実行する間しかない関係ですから |
|
| 吉井さん | そうだね。メッセージを送るための関連というのは考えない方がいいね。気を付けないと呼び出し依存グラフみたいになってしまって、機能分解に陥ってしまう |
|
| マスター | なるほど。では、メッセージが送れないという問題はどうすれば良いのでしょうか |
|
| 唐沢さん | どうしてもということであれば依存関係で表せます |
|
| 吉井さん | うん。関連はなくて良いんじゃないかな |
|
凝らないモデル。わかりやすいモデル。
すころくのルールに関して意識していない（無視している）モデルだがいいんだろうか？
とりあえず５０点。
| マスター | たつみ様のご希望がありましたので、私なりにレビューを致しました。今回は、レビュー内容についてご意見を頂けませんか |
|
| 久本くん | レビューをするってどんな感じでした？ |
|
| マスター | やはり、モデルでどういうことを伝えたいのか、を読み解くところが難しいように思いますね |
|
| 唐沢さん | インスタンスを考えることと、どれだけモデルを揺さぶれるかでしょう |
|
| 吉井さん | インスタンスを考えることは大事だね。あと、レビューではモデルを導いた過程に注目したいところ。つまり、どう考えたかだね |
|
| |
||
| マスター | まず、モデルの大枠のところを掴もうとしました。大きく（１）「マス」の構造 （２）「マス」と「プレイヤー」の関係 （３）「プレイヤー」の順番、の３点を表現していることが読めました。すごろくで大事な点として、これらに注目したのは良いのではないでしょうか |
|
| 吉井さん | うん。良いんじゃないかな |
|
| マスター | そして、「プレイヤー」「マス」「イベント」という概念ですごろくの骨子を表現できていると感じました。問題なく描けているのではないでしょうか？ ただ、今回はコンセプトがありませんでしたので、伝えたいことが描けているかが確認できませんでしたが |
|
| 吉井さん | 確かに。コンセプトがないので真意がわからないところがあるね |
|
| 唐沢さん | 細かいところですが、１点気になります |
|
| 久本くん | 「イベント」クラスが抽象クラスになってる。のは理解できるし・・・どこですか？ |
|
| 唐沢さん | 「プレイヤー」と「マス」の関係です |
|
| 吉井さん | インスタンスを考えてみよう |
|
| マスター | なるほど、「マス」の多重度が「0..1」なので、どの「マス」にも止まっていない「プレイヤー」がいますね。あがりのプレイヤーは「マス」の上から除かれるのでしょうか |
|
| 吉井さん | かもしれないね |
|
| |
||
| マスター | 次に「イベント」の分類について見ました。インスタンスを考えることで、１つ面白い捉え方をされていることに気付きました |
|
| 久本くん | 「ジャンプ」クラスですよね？ |
|
| マスター | ええ。最初は、進むや戻るがないことが気になったんです |
|
| 唐沢さん | それはクラスを記述し忘れたのではありませんか？ |
|
| マスター | そうかもしれません。しかし、進むも戻るも、見方を変えればマス指定の「ジャンプ」だと言えるということです。例えば、２つ進む場合は２つ先のマスへのジャンプだということです |
|
| 吉井さん | その考え方は面白いね。でも、それが成り立つためには１つの前提条件がないとだめかな |
|
| 久本くん | うーん。条件ですか |
|
| 唐沢さん | 分岐があるときうまくいかないかもしれません。ジャンプ先の候補が複数になり、一意の「マス」が特定できなくなる可能性があります |
|
 図 7 分岐があるとき |
||
| 久本くん | それも「ジャンプ」の考え方で変わりますよね。どう考えられたのか知りたいな |
|
解答例としまして、当カフェのマスターのモデルを紹介致します。 コンセプト次第でモデルは変わりうるものですから、 正解としてではなく、１つの考え方としてご覧ください。
マスの構造と、マスとコマの関係に注目する。
今月の問題です。モデリングの進め方については、第 1 回のモデリングの進め方を参照してください。
登山ルートをモデリングしてください。
奥岳山系の登山ルートは次のようになっています。
２つのルートが人気です。
不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。
解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです(解答時間の目安は15分～30分です)。
解答モデルの送付についてをご覧ください。
なお、今月号は第 6 回です。
締め切りは 2006 年 7 月 13 日 (木) です。
解答例掲載は 8 月号 ( 8月上旬 ) を予定しております。
先月号に引き続き、UML モデリングツールをお持ちでない方向けの読者プレゼントを実施しています。
弊社の UML モデリングツールである Elapiz スタンダードエディション の
Elapiz Basic の正規ライセンス(\15,750 相当)を、 解答モデルをご送付いただいた方の中から、抽選で 3 名の方にプレゼントいたします。
解答モデルの送付についてをご覧いただき、是非ご応募ください。
現在、応募していただいた方の当選確率は、85 % 以上です！
本連載では、文献[1]をベースに、より気軽にモデリングを愉しんでいただけるテイストにしております。モデリングに関するしっかりした解説が欲しい場合には、以下の書籍をご覧になると良いと思います。
先月号の Elapiz Basic の正規ライセンスの当選者を発表いたします。おめでとうございます！！
残念ながら外れてしまった方、次回のご応募お待ちしております。
なお、当選者の方には、後日改めてメールにてご連絡いたします。お楽しみに！！
改訂履歴