モデリングカフェ 第4回:タイムテーブルをモデリングする
モデリングカフェ「Square」~UMLでモデリングを愉しもう~
(株)オージス総研 組み込みソリューション部
田中恒, 赤坂英彦
2006年3月9日
目次
- 前回の問題(部品の構成)
- 読者解答モデル
- 解答例
- 今月号の問題 (出題)
- 解答モデルの送付について
- 参考文献
- Elapiz (いらぴす)当選者発表
前回の問題をもう一度確認しておきましょう。
【お題03】部品の構成
型番 D0101 の机の部品構成は以下のとおりです。
- 机 (D0101) は天板 (T0212) 1つ、脚 (F0132) 4つ、引き出し (H0303) 1つで構成されます
- 引き出し (H0303) は、箱 (B0505) 2つ、棚 (TA0635) 1つで構成されます
- 天板 (T0212) や引き出し (H0303) などは他の製品でも利用されます
※ ( ) 内は型番
この例を参考に部品の構成をモデリングして下さい。
不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。
解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです (解答時間の目安は15分~30分です)。
今月も、読者の皆様からたくさんの解答モデルを頂きました。ありがとうございました。
これまでと同じように、3つの解答モデルをピックアップして、当カフェのマスターとヒトクセある!?常連たちと一緒に見ていきましょう。
コーヒーなどを飲みながら、皆様も一緒にわいわいやる感じで考えてみてください。
また、残念ながら紹介することができなかった解答モデルはこちらに掲載しますので、
オブジェクトの広場 メーリングリストなどで意見交換していただければ幸いです。
コンセプト
- 製品(机)は複数の部品から構成されている
- 一部の部品は複数の部品から構成されている
- 部品と部品を組み合わせていろいろな製品を構成できる
モデル
図 1 こしお 様の解答モデル
感想
- 難しかったところ
- 一部の部品は複数の部品から構成されているというのをモデル化する時に、ロール名の付け方や多重度で悩みました。
- 自己評価
コメント
マスター |
|
コンセプトが問題を素直に表現しています。 |
久本くん |
|
ですよね。問題を適度に一般化してあるので、とってもわかりやすいです。 |
吉井さん |
|
曲解したり誤解したりしないためにも、モデリングの対象を素直に解釈するのは大切なことだね。 |
唐沢さん |
|
ええ。それに、対象の特徴を素直に捉えることで、自分が何に興味あるのか、何を表現したいのかが見えるようになります。 |
吉井さん |
|
そうだね。最初から深く検討するよりも、ある程度の当たりを付けてから深く検討すると良いね。 |
マスター |
|
モデルも、コンセプトに従って素直に記述されています。 |
吉井さん |
|
それも大切だね。コンセプトとモデルに齟齬があると、何のためのコンセプトかわからない。 |
久本くん |
|
コンセプトが、モデリングの対象とモデルを繋いでいるっていうのがよくわかります。 |
|
マスター |
|
ロール名や多重度で悩まれたということですが。 |
唐沢さん |
|
悩むということは良いことです。というのも、悩むということは、明らかにされていないこと、整理されていないことがあるということを示唆しているからです。 |
吉井さん |
|
うん。なんとなくわかったつもりで、実はわかってなかったということも良くあるんだけど、モデリングをすることでそれが見えてくるね。 |
久本くん |
|
「無知の知」ですね。 |
吉井さん |
|
おっ、かっこいいね。その通りで、おやっ、と思う嗅覚を大切にしたいね。 |
|
唐沢さん |
|
とても素直に描かれていてわかりやすいという点では優れているのですが、素直さ故にこの問題の罠というか、落とし穴にはまっています。 |
久本くん |
|
えっ、どこですか? |
マスター |
|
「部品」クラスではないでしょうか。 |
久本くん |
|
不自然な属性はないと思うんだけど。 |
吉井さん |
|
じゃあ、こんな場合を考えてみて(図 2 )。 |
図 2 複数の「製品」の「部品」になる場合 |
久本くん |
|
あっ! 個数が属性だとうまく表現できません。 |
マスター |
|
そうですね。 |
唐沢さん |
|
個数というのは、「部品」という概念の特徴なのか、考えなければいけません。例えば、ねじが1つあるとして、この"1つ"というのはねじ自体の性質や特徴を表しているんでしょうか。 |
吉井さん |
|
そこを踏み込んで考えることで、この問題の難しいところを素直にわかりやすく伝えられる良いモデルになるんじゃないかな。 |
コンセプト
- 品物は複数の部品から構成される
- 品物もまた、別の品物の部品になる
- 他の品物の部品にならない単品の品物もある
- 同じ品番の部品で、製品に対する構成箇所が異なる場合も管理したい
モデル
クラス図
図 3 かささぎ 様の解答モデル(クラス図)
オブジェクト図
図 4 かささぎ 様の解答モデル(オブジェクト図)
感想
- 難しかったところ
- 製品-部品の関係が巡回しないような制約の記述にてこずった
- 時間(30分以内)を守れなかった
- 自己評価
- 最初は構成クラスを部品-部品の再帰構造の関連クラスにしていましたが、コンセプトの追加で制約を緩めてみました。
コメント
唐沢さん |
|
シンプルに、この問題の大切なところを押さえています。 |
マスター |
|
数ですね。 |
吉井さん |
|
いろんな種類の部品で構成されることと、ある部品が複数個あることが切り分けられているね。 |
久本くん |
|
オブジェクト図を見ると面白いことに気付きました。現実世界の机を見ると、脚は 4 本ありますよね。だから、単純にインスタンスを考えると脚インスタンスが 4 つあるのを思い描きますが、このオブジェクト図では脚インスタンスは 1 つなんですね。 |
唐沢さん |
|
ええ。「構成」としてうまく抽象化しています。 |
吉井さん |
|
「構成」という概念を導いたのはうまいね。 |
唐沢さん |
|
「使用箇所」という属性も面白いです。この考え方には気付きませんでした。 |
久本くん |
|
えーと、どういうことですか? |
吉井さん |
|
例えば、普通に机の下に引出が付いている場合だと「引出:構成」は1つだよね。さらに、卓上用の引出も付け加えたい場合を考えてみてごらん。 |
久本くん |
|
「引出:構成」が 2 つになりますね。 |
吉井さん |
|
そうそう。すると 2 つの「引出」の違いはどこにあるんだと思う? |
マスター |
|
そこで「使用箇所」の出番なわけですね。 |
吉井さん |
|
うん。そうだね。 |
唐沢さん |
|
少し話しが逸れますが、「構成」クラスを関連クラスとしなかったのも、このことを表現したかったからでしょうね。 |
|
唐沢さん |
|
「品物」という概念をどうやって出したのか興味があります。 |
吉井さん |
|
確かに、問題には「品物」という概念は出ていないからね。これらを抽象化した概念だね。 |
マスター |
|
「製品」や「部品」はクラスではなくロールとして表現されています。これらをクラスにすると何か不都合があるのでしょうか。 |
久本くん |
|
「品物」として捉えないといけないことかぁ。なんだろう。 |
吉井さん |
|
これは宿題。考えてみて。 |
唐沢さん |
|
欲を言えば、どうやって「品物」を導いたのか、「品物」は何を意味しているのか、をコンセプトに記述しておきたいところです。 |
|
久本くん |
|
この制約はどういうことを言っているのですか? |
吉井さん |
|
あまり難しく考えなくてもいいんじゃないかな。例えば『机は机で構成される』というのを避けるということだと思うよ。 |
久本くん |
|
なるほど。そういうことですね。 |
コンセプト
- 部品と製品の関係
- 製品は、一つ以上の部品を持つ
- 部品は、一つ以上の製品の一部として利用される
- 部品は、製品の一部として利用される場合もあり、製品として利用される場合もある
- 部品と型番リストの関係
- 部品は、型番リストにより管理されている
- 部品は、一つの型番リスト内で型番によってユニークである
- 部品は、一つ以上の型番リストで管理することが可能である
モデル
クラス図
図 5 ともちゃん 様の解答モデル
感想
コメント
久本くん |
|
うっ、限定子だ。 |
吉井さん |
|
どうしたの久本くん。顔色が良くないよ。 |
久本くん |
|
限定子よくわからないんです。 |
マスター |
|
身近な例で考えるとわかりやすいですよ。例えば銀行の口座などです(図 6 )。 |
図 6 限定子を使った例 |
唐沢さん |
|
「銀行」と「口座」の組で「口座主」が決まるということです。 |
久本くん |
|
なるほど。これだとわかりやすいですね。 |
吉井さん |
|
じゃあ、この解答モデルを、限定子を使わない形にしたらどうなる? |
久本くん |
|
え~と・・・。こうでしょうか(図 7 )。 |
図 7 限定子を使わない形に描きなおしたモデル |
吉井さん |
|
そうだね。 |
唐沢さん |
|
限定子は、ときに"わかりにくさ"を生んでしまうので、使うときには注意が必要です。 |
吉井さん |
|
うん。でも、データベースをやっている人にはわかりやすいかもしれないね。 |
マスター |
|
このモデルの場合も、データベースの考え方が伺えますね。「型番リスト」という名前からも感じます。 |
吉井さん |
|
そうだね。きっと、部品表などをイメージして捉えたんだろうね。コンセプトにもどうやって管理しているのかに興味があると書いてある。 |
唐沢さん |
|
概念モデルの場合、どう実現するかといった設計的な視点はできるだけ避けたほうがよいと思うのですが。 |
吉井さん |
|
確かにそうだね。でも部品表などの概念があるのであれば、描いておいたほうが良いんじゃないかな。 |
|
久本くん |
|
「型番リスト」というのが何を表しているのかわからなかったんですが、さっきの部品表だと考えるとわかりました。 |
マスター |
|
例えば「机:型番リスト」や「引出:型番リスト」というように製品毎に「型番リスト」があるんですね。
|
吉井さん |
|
そうだろうね。コンセプトにも『一つ以上の型番リストで管理することが可能である』とある。 |
唐沢さん |
|
ある「部品」が複数の「製品」の部品となることが表現できていますね。 |
|
マスター |
|
「製品」と「部品」の多重度に苦労されたようです。 |
久本くん |
|
多重度が(1..*)になってるというのはミスでしょうか。再帰構造の最初と最後がありません。 |
吉井さん |
|
多重度を考えるときは、"0"と"1"には注意が必要だね。特に再帰構造の場合は最初と最後に注目しないといけないね。オブジェクト図を描いて確認すると良いよ。 |
唐沢さん |
|
ところで、「部品」という概念は、一つ一つのモノとしての「部品」を指すのか、それらの型を指すのかどちらだと思いますか? |
マスター |
|
このモデルの場合、型を指していると思いますが。 |
吉井さん |
|
うん。「製品」の多重度が(1..*)になっていることからもそうだと思うよ。もし、「部品」クラスが一つ一つのモノを指していたら、同時に複数の「製品」の部品になることはできないからね。 |
唐沢さん |
|
つまり、仕様の世界をモデリングしているんですね。 |
久本くん |
|
仕様って何ですか? |
吉井さん |
|
ちょっと難しくなるから詳しくは話さないけど、一つ一つの実体のあるモノをインスタンスとして考えるのではなく、それらを形作る性質的なところだけを抜き出したものが仕様なんだ。このモデルで、「製品」の多重度が(1..*)であることに注目して、考えてごらん。 |
解答例としまして、当カフェのマスターのモデルを紹介致します。
コンセプト次第でモデルは変わりうるものですから、正解としてではなく、1つの考え方としてご覧ください。
コンセプト
- 図解する
図 8 部品の構成の図解
- 製品を構成する部品とその個数(点数)を表現する
- 部品が製品になることもありうると考え、「品目」として捉える
- 「品目」は以下に分類される
- それ以上分解できない「単品目」
- いくつかの「品目」が構成されて成り立つ「ユニット」
- 「ユニット」の特徴を整理する
- 複数の「品目」で構成される
- 構成する「品目」ごとに個数の情報が必要
「品目」ごとに「構成」を持たせて個数を保持させる
モデル
オブジェクト図
図 9 解答例のオブジェクト図
クラス図
図 10 解答例のクラス図
総括
この問題のポイントを整理しておきましょう。
多重度は何を意味しているの?
図 8 を見てください。
この関係を次のように捉えたとしましょう。
図 11 多重度のあいまいさを含んだクラス図
このとき、多重度(0..*)は何を表しているのでしょうか?
実は、この多重度にはあいまいさが含まれていて、2 つの意味での解釈が可能になってしまいます。
その 2 つは次の通りです。
- 要素の種類が複数あることを表している
- ある種類の要素が複数あることを表している
オブジェクト図を考えるとこの不自然さがよりわかりやすくなりますので、描いてみてください。
この 2 つの意味はまったく異なることを意味していますので、明確に切り分けましょう。
また、この問題のように多重度の解釈にあいまいさが含まれてしまうことはよくあります。
オブジェクト図で確認する習慣を付けておきましょう。
「製品」と「部品」の違いは何?
今回の問題では、「製品」と「部品」を区別している解答がいくつか見られました。
ところが、この 2 つの違いが感じられないものが多かったように思います。
図 12 を見てください。
図 12 製品と部品の違いは?
違いが感じられない点は、次の 2 点です。
- 属性が同じ
- 部品との関連の意味が同じ(ロール名が同じ)
このように、同じことを書いているな、と思われるときは抽象化するチャンスです。
それぞれのクラス(概念)の定義を明確にして、同じことなのか違うことなのか考えましょう。
また、表面に出ている特長(名前など)にとらわれずに、いろいろなケースを考えて揺さぶってみましょう。
実は、違う概念だと思っていたものは、違う役割なのかもしれません。
別の観点が含まれているのかもしれません。
例えば、『「引出」の評判がよく、「引出」単体でも製品として販売するとき』はどうなるでしょう。
「引出」は製品でもあり部品でもあるということになりませんか?
構成に関する視点と、販売する単位という視点が混ざっているのかもしれませんね。
今月の問題です。モデリングの進め方については、第 1 回のモデリングの進め方を参照してください。
【お題04】タイムテーブル
2006 年 4 月 7 日(金)にダイエットセミナーが開催されます。
プログラムは次の通りです。
時間 |
「運動」トラック ( A 会場) |
「食事」トラック ( B 会場) |
「医療」トラック ( C 会場) |
10:00 |
【A-1】脂肪を燃焼させる効果的な運動方法
奥下 博則 氏 |
【B-1】油の摂取量の上手なコントロール
高平 智恵子 氏 |
【C-1】体脂肪率と糖尿病の相関
東神 博 氏 |
12:00 |
-昼食- |
-昼食- |
-昼食- |
13:00 |
【A-2】運動を継続する~生活の中の自然な運動
野岡 太郎 氏 |
【B-2】満腹感から満足感へ~食事の量を抑えるコツ
巻 栄二 氏 |
【C-2】摂食障害と心の病気
羽田 隆子 氏 |
15:00 |
【A-3】体脂肪率の変化と体重の増減
尾河 厚一郎 氏 |
【B-3】食事リハビリテーション
多上 恵子 氏 |
【C-3】生活習慣病のセルフチェック
出本 貞幸 氏 |
※全てフィクションです。実在の人物、研究、発表、その他とは一切関係ありません。
この例を参考に、セミナーのタイムテーブルをモデリングしてください。
不足する情報は適宜補っていただいて結構です。補った情報は、コンセプトに記述してください。
解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです (解答時間の目安は15分~30分です)。
解答モデルの送付についてをご覧ください。
なお、今月号は第 4 回です。
締め切りは 2006 年 3 月 30 日 (木) です。
先月号に引き続き、UML モデリングツールをお持ちでない方向けの読者プレゼントを実施しています。
弊社の UML モデリングツールである Elapiz スタンダードエディション の Elapiz Basic の正規ライセンス(\9,975 相当)を、
解答モデルをご送付いただいた方の中から、抽選で 3 名の方にプレゼントいたします。
解答モデルの送付についてをご覧いただき、是非ご応募ください。
現在、応募していただいた方の当選確率は、89 % と高確率 です!
本連載では、文献[1]をベースに、より気軽にモデリングを愉しんでいただけるテイストにしております。モデリングに関するしっかりした解説が欲しい場合には、以下の書籍をご覧になると良いと思います。
- 「思考系UMLモデリング即効エクササイズ モデ力を鍛える13の自主トレメニュー」、渡辺博之他、翔泳社
- 「UMLによるオブジェクト指向モデリングセルフレビューノート」、荒井玲子著、ディーアート
- 「UMLモデリングの本質」、児玉公信著、日経BP社
先月号の Elapiz Basic の正規ライセンス(\9,975 相当) の当選者の方々を発表いたします。おめでとうございます!!
なお、当選者の方々には、後日改めてメールにてご連絡いたします。お楽しみに!!
改訂履歴
- サイトテンプレート変更に伴う変更(2018年3月)