第3回記事の本格版モデル

補足

第3回の記事で「より本格的なモデルを筆者のブログに掲載します」なんて書いたことをすっかり忘れていた。今日になって急に思い出したのでセコセコと作ってみた。


まずは航空機の座席予約のモデルから。


だいたいこんな感じだと思う。座席レイアウトは便ごとに定義するのではなく、あらかじめ基本的なパターンが決まっているはずである。「機種」と「座席レイアウト」を分離したのは、1つの機種でも複数のレイアウトを持つはずだと考えたからである。

自分の中では、記事で、発着地となる「空港」を別エンティティに切り出さずに「便」の属性にしたのがずっと引っかかっていた。「全体−部分」関係の説明に注力するためにカットした枝葉だが、あまりにいい加減なモデルを活字にするのはちょっと気が引けたから。


次はハンバーガーショップのセット商品である。せっかくなのでマクドナルドのホームページを参照してみた。
http://www.mcdonalds.co.jp/sales/menu_h_f.html
結構厄介である。セット商品でもサイドメニューはポテト、サラダ、チキンマックナゲットから選択できるし、ドリンクはセット商品に含めるものとそうでないものがある。さらにセット商品でも追加料金を払うことで、ドリンクやポテトを上のサイズに変更できる。

まずはセット商品と単体商品の関係を表現するモデルを描いてみた。

多くの単体商品にはサイズがあるため、「サイズ別単体商品」というエンティティを定義してみた。販売商品の最小単位はこれになるはずである。サイズを持たない（1種類の）商品もあるが、これも"標準"サイズを持つことにした。
「セット商品」は「サイズ別単体商品」の組み合わせだが、単純な組み合わせではなく、複数商品の中から選択できる。このことを表現するために「セット商品構成要素」というエンティティを定義した。


さて、プラス30円でポテトをLサイズに、プラス20円でドリンクをLサイズに変更できる仕様も表現してみた。

セット商品の構成要素に対して、商品を別のサイズに変更した場合の追加料金を管理する「サイズ変更オプション」を設定可能としてみた。「セット商品構成要素」に「サイズ変更オプション」を設定するためには、”配下の「サイズ別単体商品」のサイズが同一であること”が前提になっているところが苦しい感じである。

この問題に本格的に対処するためには、同一の価格体系で運用する「単体商品」をまとめる「単体商品グループ」を導入すると良いのだろう。商品情報からは「コールドドリンク」や「ホットドリンク」などは価格体系が同一で、特に区別していないように見えるから。（海外のマクドナルドで、ドリンクバイキングで運用していたことを思い出した。）とはいえ、だいぶゴチャゴチャしてきたので、これ以上手を加えるのはやめておこうと思う。

これぐらいのモデルになるとクラス図だけで現場の共通理解を得るのは苦しい。ベン図（オブジェクト図）を書いたり、補足説明をきちんと書くなどする必要があるが、この記事自体も長くなってしまうので、ブログのエントリの方も今夜はここでおしまいである。