UMLモデリングカフェ第7回：カレーの作り方をモデリングする

モデリング

毎回、身近にあるモノや出来事など、簡単な【お題】を出題し、皆様にモデリングをして頂きます。次回の記事で、皆様の解答モデルの中から3つほど取り上げて、コメントを付けていくかたちで進めていきます。

前回の問題（登山ルート）
読者解答モデル　－　本文で紹介できなかった解答モデル
解答例
今月号の問題 (出題)
解答モデルの送付について
参考文献
Elapiz （いらぴす）当選者発表

1．前回の問題（登山ルート）

登山ルートをモデリングしてください。

奥岳山系の登山ルートは次のようになっています。

お題（登山ルート）

２つのルートが人気です。

表ルート（４時間２５分）
1. 白沢登山口から一の又（６０分）
2. 一の又から柳ヶ原山（５０分）
3. 柳ヶ原山から奥岳（４５分）
4. 奥岳から柳ヶ原山（４０分）
5. 柳ヶ原山から大下登山口（７０分）
裏ルート（５時間５０分）
1. 滝見道登山口から前屏風出合（１１０分）
2. 前屏風出合から屏風岳（７０分）
3. 屏風岳から奥岳（６０分）
4. 奥岳から柳ヶ原山（４０分）
5. 柳ヶ原山から大下登山口（７０分）

不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。

解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです(解答時間の目安は15分～30分です)。

今回は、読者の皆様からこれまでで最多の解答モデルを頂きました。ありがとうございます。これまでと同じように、3つの解答モデルをピックアップして、当カフェのマスターとヒトクセある！？常連たちと一緒に見ていきましょう。皆様、飲み物の準備はできましたか？　リラックスして、一緒にわいわいやる感じで考えてみてください。また、残念ながら紹介することができなかった解答モデルはこちらに掲載しますので、オブジェクトの広場メーリングリストなどで意見交換していただければ幸いです。

読者解答1：岩沢正樹様

コンセプト
１つの経路について、往復を、別々の経路と考えました。詳細については、深く考えずに、地点と経路情報との関係だけを明確にすることを考えました。
モデル
- クラス図
  
  図 1 岩沢正樹様の解答モデル（クラス図）
- オブジェクト図
  
  図 2 岩沢正樹様の解答モデル（オブジェクト図）
感想
- 難しかったところ
  幾つかの経路がある場合に、多重度をどう決めるかについて難しかったです。
- 自己評価
  今回は、３～４点です。

マスター		コンセプトにあるように、地点と経路情報の関係を明確にしたいということで、意図が明確なモデルになっています
唐沢さん		ええ。お題は一見複雑なのですが、「地点」とそれらを結ぶ「経路」という見方をすると同じことの繰り返しであることが分かります
久本くん		本質的な特徴を見つけ出しているってことですね
吉井さん		そして、シンプルにそこだけをモデリングしてあるね。良いモデルだと思うよ
マスター		オブジェクト図を見て感じたのですが、地図を素直にそのまま表現されています
吉井さん		そうだね。ノードとパスから作られるネットワークの形をしているものは、大抵、このような形になるね。地図もネットワークという側面があるから、そこに注目したということかな

久本くん		お題は登山ルートをモデリングせよってことだったんですが、このモデルでは登山ルートはどう考えたら良いのですか？
唐沢さん		モデルでは、ある「地点」から見た「経路情報」の多重度が 0..* になっています。ですので、特定の「ルート」の場合とは考えていないのではないでしょうか
マスター		ですが、オブジェクト図は、あるルート上に存在する「地点」と「経路情報」を描いています
吉井さん		クラス図で地図を表現して、オブジェクト図で「ルート」を表現しているのかもしれないね
久本くん		そうか。いろいろなルートの場合を考えていくと、最終的には正に地図になりますね

吉井さん		このお題では、「経路情報」のインスタンスが何を指すのかが１つのポイントかな
唐沢さん		そうですね。コンセプトにも示されています
久本くん		え～と・・・どういうことですか？
マスター		例えば「奥岳」と「屏風岳」の間の「道」はいくつありますか？
久本くん		「道」は１つです。あっ、コンセプトでは往復を別々の経路としてるんですね（図 3）
図 3 道と経路は異なる
唐沢さん		では、なぜ別々にしたのでしょうか？
吉井さん		うん、そこは考えておきたいところだね。何か見落としているかもしれないし、暗黙的な条件があるのかもしれない
マスター		お題を素直に見ると、向きによって所要時間が変わってきますね。ですから、往路と復路は別の実体として考えられたのでしょう。実際、登りの時と下りのときではしんどさがぜんぜん違うことがありますし
唐沢さん		そうですね。ですが「危険」や「注意」は向きに関係なく「道」の情報だと考える方が自然でしょう。今回はモデリングの対象範囲とされなかったようですが、これらを考えていくと問題になるかもしれません
吉井さん		往復を分けた方が良いかどうかは場合によるよね。だから大切なことは、どうしてそうしたのか、ということかな。モデルはこうなっています、だけではなく、こういう理由でこうなっています、というところをしっかり押さえておきたいね

読者解答2：吉本信弘様

コンセプト
- 地点は、特定の系（奥岳山系）に属する
- 地点は、少なくとも1つの登山道によって他の地点と関連付けられる
- 登山道は、同一系に属する地点から生成される
- 登山道は、同一始点、終点を参照するインスタンスを複数生成できる（力地蔵～奥岳）
- 登山ルートは、同一系に属する地点から生成された登山道を参照する
- 登山ルートは、同一登山道を複数参照できる（登山道のリストは複数あり）
- 難度は、系の異なる登山道ともリンクを生成できる
モデル
- クラス図
  
  図 4 吉本信弘様の解答モデル（クラス図）
- オブジェクト図
  
  図 5 吉本信弘様の解答モデル（オブジェクト図）
感想
- 難しかったところ
- 自己評価

唐沢さん		地図の情報とルートを区別しているのがとても素晴らしいです
吉井さん		地図は地図としてあって、じゃあ、どういうルートを選ぼうか、というのはまた別の興味ということだね
マスター		オブジェクト図を見るとそれがよくわかります。「登山道」を繋いでいくと「登山ルート」になります
久本くん		本当だ。「登山ルート」のインスタンスを隠して見ると地図になっていますね
唐沢さん		「人気ルート」というところが少し検討不足でしょうか
吉井さん		だね。「人気」って何？、というところで悩まれたのかな

マスター		OCL では何を伝えようとされているのでしょう
久本くん		常に、所要時間は正であること、始点と終点は異なる「地点」であること、始点と終点はどちらも同じ「系」に属していることでしょうか
吉井さん		うん、確かにそうなんだけど、それは本当に伝えたいことなのかな
マスター		所要時間が正であることは改めて言う必要はないかもしれませんね
唐沢さん		おそらくですが、同じ「地点」の間に所要時間が 0（言い換えれば、距離が 0）の「登山道」ができないようにしたかったのではないでしょうか。結果として、このような場合も許されなくなりましたが（図 6）
図 6 輪になった登山道

久本くん		{sequence} という制約を初めて見ました。{ordered} とは何が違うのですか？
唐沢さん		どちらも順序付きということですが、順序付きの "bag" か、順序付きの "set" かの違いですね
マスター		簡単に言いますと、同じインスタンスの重複を許すか、許さないか、です。{sequence} の場合は同じインスタンスが繰り返し出てきても良く、{ordered} の場合は同じインスタンスが出てきてはいけません
吉井さん		このモデルでは、ある「登山ルート」に同じ「登山道」が繰り返し出てきても良いということだね。こんな場合かな（図 7）
図 7 ある登山道が繰り返し出る例

読者解答3：ナカ様

コンセプト
- ルートは、終端地点2つ（出発、到着）と中間地点（複数）で構成
- 各区間に所要時間を持たせる
モデル
- クラス図
  
  図 8 ナカ様の解答モデル
感想
- 難しかったところ
  人気ルートは、クラス図にどう表せばよいか？表せないと思うので表記していない。
- 自己評価
  概ねできたと思う。

マスター		１つ特徴的な捉え方をされています
久本くん		「ルート」は「地点」が集まって出来ているんですね
吉井さん		そうだね。「ルート」は「区間」が集まっている、と考えることも、「ルート」は「地点」が集まっている、と考えることもできるね
唐沢さん		ええ。でも、「ルート」は「地点」が集まっていると考えるのには若干の違和感を感じます
久本くん		そうですね。「ルート」は 1 本の線だし、「区間」が繋がっている方が自然じゃないですか？
吉井さん		それはモデリングするときにどこに興味を持っているかで変わってくるよ。例えば、スタンプラリーの場合だったらどうかな？
久本くん		・・・「地点」が繋がっている方が自然ですね
吉井さん		だね。たぶん、違和感を感じたのは「ルート」の所要時間に興味があったからじゃないかな。所要時間は「地点」と「地点」の間にあるものだから

マスター		人気ルートをどう表せば良いか悩まれたそうです
吉井さん		皆だったらどう表現する？
久本くん		「人気」っていうクラスを出して「ルート」と関連付けるかなぁ
図 9 人気クラスを出す場合
マスター		「ルート」には人気ルートと不人気ルートがある、というように分類できるので汎化関係でしょうか。ちょっと不自然ですね
唐沢さん		私は「ルート」クラスに「人気度」のような属性を付けますね
図 10 人気を属性にする場合
吉井さん		もし、"初心者向けルート"・"健脚者向けルート"・"熟練者向けルート"といったランクのようなものと同じように「人気」を捉えたら、久本くんの案でいいかもしれないね。人気にいくつか分類があるときとか。でも、このお題では人気についてあまり触れられていないから、唐沢さんの案のように属性にしておいてもいいと思うよ

3. 解答例

解答例としまして、当カフェのマスターのモデルを紹介致します。コンセプト次第でモデルは変わりうるものですから、正解としてではなく、１つの考え方としてご覧ください。

コンセプト
地図の情報とどこを通るか（登山ルート）をモデリングする
- 地図の情報
  - 地点と地点を結ぶ区間がある
    - 同じ地点を結ぶ複数の区間がある場合がある（力地蔵－奥岳など）
  - 区間には往路・復路という順路がある
    - 往路・復路それぞれに所要時間がある
  - 区間には注意事項が付くことがある（注意、危険など）
- 登山ルート
  - 登山ルートは連続する１つ以上の順路からなる
    - 一度通った順路は二度と通らないとする
モデル
- オブジェクト図
  
  図 11 解答例のオブジェクト図
  　
- クラス図
  
  図 12 解答例のクラス図

4. 今月号の問題 (出題)

今月の問題です。モデリングの進め方については、第 1 回のモデリングの進め方を参照してください。

【お題07】カレーの作り方

カレーの作り方をモデリングしてください。

不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。

お題（カレーの作り方）

解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです (解答時間の目安は15分～30分です)。

5. 解答モデルの送付について

解答モデルの送付についてをご覧ください。
なお、今月号は第 7 回です。締め切りは 2006 年 9 月 7 日 (木) です。

解答例掲載は 10 月号 ( 10月上旬 ) を予定しています。

読者プレゼント～Elapiz （いらぴす) 要ります？キャンペーン～

先月号に引き続き、UML モデリングツールをお持ちでない方向けの読者プレゼントを実施しています。
弊社の UML モデリングツールである Elapiz スタンダードエディションの Elapiz Basic の正規ライセンス(\15,750 相当)を、解答モデルをご送付いただいた方の中から、抽選で 3 名の方にプレゼントいたします。

解答モデルの送付についてをご覧いただき、是非ご応募ください。

現在、応募していただいた方の当選確率は、85 %以上です！

6.参考文献

本連載では、文献[1]をベースに、より気軽にモデリングを愉しんでいただけるテイストにしております。モデリングに関するしっかりした解説が欲しい場合には、以下の書籍をご覧になると良いと思います。

「思考系UMLモデリング即効エクササイズ　モデ力を鍛える13の自主トレメニュー」、渡辺博之他、翔泳社
「UMLによるオブジェクト指向モデリングセルフレビューノート」、荒井玲子著、ディーアート
「UMLモデリングの本質」、児玉公信著、日経BP社

7. Elapiz（いらぴす）当選者発表

先月号の Elapiz Basic の正規ライセンスの当選者を発表いたします。おめでとうございます！！

８８４様
じゃま様
喫茶「模型作り」様

なお、当選者の方には、後日改めてメールにてご連絡いたします。お楽しみに！！

改訂履歴

サイトテンプレート変更に伴う変更（2021年7月）

モデリングカフェ 第7回：カレーの作り方をモデリングする

【お題07】カレーの作り方

モデリングカフェ第7回：カレーの作り方をモデリングする