LastUpdate : 2008/12/08

特定非営利活動法人 UML モデリング推進協議会

UML モデリング技能認定試験
L3

サンプル問題モデリング問題-問題 1（ビジネス系）※本書の一部または全部を無断で複写、複製、転載、テープ化、ファイル化することを禁じます。
※UML、Unified Modeling Language は OMG（Object ManagementGroup）の商標です。

Copyright©2008 UMTP

LastUpdate : 2008/12/08

問題
漫画喫茶の A 社は、店舗に複数の棚を設置しており、多種の漫画や DVD を閲覧物品として収納しています。A 社では利用者に対して、それらの漫画の閲覧や DVD の鑑賞等の基本的なサービスに加え、インターネットを利用できるサービスも提供しています。
A 社は会員制を採用しており、サービスの利用者は事前に会員登録を行います。会員登録では会員の情報として、会員名と電話番号をシステムに登録し、システムが会員番号を一意に採番します。会員は、全国に数箇所あるどの店舗においても、同様のサービスを受けることができます。
会員はサービスを受ける場合、店舗の受付において、希望の座席と利用時間を指定して注文を行います（事前に予約することはできません）。なお、注文した時点での利用時間より延長することを希望する場合、まずは精算を行い、延長分は別注文とします。
A 社では店舗毎に、注文を受け付ける数名の担当者が配属されています。注文を受けた担当者は、その時点での座席の空き状況を確認して、空席であれば会員に座席を割り当てます。システ
ムでは座席の空き状況を確認するため、現在、どの会員がどの座席を注文（利用）しているのかの情報を保持しています。加えて、月ごとの売上げ推移を確認するために、会員の過去の注文についても、履歴として保持しています。
座席の種類には、個室とオープンがあります。両タイプの利用者ともに、漫画や DVD は自由に閲覧できます。PC（インターネット）の利用については、個室では各座席に必ず一つ設置されているため、いつでも利用可能です。しかしオープンの座席では、座席によって PC がある場合と無い場合があるため、利用できないケースもあります。また座席に割り当てていない予備の PC も何台かあります。
サービス料金は 1 時間毎に課金され、以下のように、座席の種類によって金額が異なります。
<<料金体系>>
オープン
個室
単価 （座席利用 1 時間の料金） \200\400
表 1 料金体系
また、店内ではフードやアメニティグッズを販売商品として販売しており、会員は随時、それらの販売商品を注文することができます。
座席（サービス料金）や販売商品の単価については、現時点では、以下を想定しています。
z 月の途中で単価を変更しない。
z 将来的には、座席毎に単価を設定できるようにしたい。

-2–
Copyright©2008 UMTP

LastUpdate : 2008/12/08

会員が精算を行った際の領収書は以下のようなものです。

領収証

領収証

漫画喫茶「Ａ社」：ＡＢＣＤ店

漫画喫茶「Ａ社」：ＡＢＣＤ店

精算日時：２００７/１０/１ １６：２３：３４

精算日時：２００７/１０/２ １３：４５：５１

会員番号：００００１２３４５ 様

会員番号：００００１３００５ 様

座席タイプ

： 個室

座席番号

： １５番

座席タイプ

： オープン

座席番号

： ３３番

利用開始日時 ：２００７/１０/１ １２：２３：３４

利用開始日時 ：２００７/１０/２ １２：４５：５１

利用時間

利用時間

： ４時間
座席小計金額 ： ￥１,６００： １時間
座席小計金額 ：￥２００

合計金額 ：

￥２００

販売商品名
タオル

１

￥３００

カップラーメン１￥１５０

チョコレート２￥２００

担当者名：鈴木 幸司

合計金額 ： ￥２,２５０
担当者名：鈴木 幸司

図 1 領収書
なお、会員は座席の PC から随時利用できる以下のサービスがあります。
z 閲覧物品として以下を検索する。
z 漫画の詳細情報（収納された棚番号、タイトル、出版社、著者、巻数）を表示する。
z DVD の詳細情報（収納された棚番号、タイトル、監督、上映時間）を表示する。
z 座席に設置された PC のスペック情報等を検索する。

-3–Copyright©2008 UMTP

LastUpdate : 2008/12/08

設問 1
上記の漫画喫茶を理解するために必要なクラスを洗い出した結果、以下のようなクラス図になりました。

1(a)

(b)
1..*

1
1*(c)

1

1*(d)
1

*

1
**(e)
*(x)

1

10..1(y)

*(f)

(g)
*

1

*

1(h)
巻数

1

1(j)

(k)

(i)

(l)

0..10..1

PC
PC番号
スペック

**

図 2 クラス図
図 2 の ( a ) ～ ( l ) に入るクラス名と、( x ) と ( y ) に入る関連端名を以下の選択肢から 1 つ選
んでください。
(1)

座席

(2)

会員

(3)

販売商品

(4)

担当者

(5)

閲覧物品

(6)

商品注文明細(7)漫画(8)

DVD(9)

現在(10) 注文(11) 棚(12) 座席利用明細(13) 過去(14) 店舗-4–Copyright©2008 UMTP

LastUpdate : 2008/12/08

設問 2
以下の属性が割り当てられるべき適切なクラスを図 2 から 1 つ選び、( a ) ～ ( l ) の記号で答えてください。
(1)

座席番号

(2)

担当者名

(3)

合計金額

(4)

タイトル

(5)

監督

(6)

上映時間

(7)

会員番号

(8)

利用時間

(9)

販売商品単価(10) 販売商品個数(11) 座席小計金額(12) 棚番号(13) 店名-5–
Copyright©2008 UMTP

LastUpdate : 2008/12/08

設問 3
現モデルにおいて、月ごとの売上げの管理では座席タイプ毎の単価については変更されないことを前提として、座席クラスに座席単価の属性を持たせていました。しかし月の途中でも座席単価を変更することになったため、会員がサービスを利用した時点の座席単価と、現在の座席単価とを区別できるように、現モデルの変更方針を検討しました。
案1

現在の座席単価は座席クラスの属性としてそのまま保持し、会員がサービスを利用した時点の座席単価は座席利用明細クラスの属性として保持する。
座席利用明細
…
座席単価

案2

座席
*

1

…
座席単価

座席クラスから座席単価の属性を削除し、座席単価とその座席単価を適用する期間とを属性として持つ料金クラスを新規に追加して、座席クラスから以下のように関連でつなぐ。
座席現在料金1…

適用期間
過去 座席単価*

案3

座席クラスに、その座席単価を適用する期間の属性を追加して、座席単価が変更されたときに、対応する座席クラスのインスタンスを新たに生成する。
座席…
座席単価
適用期間

表 2 モデルの変更案
以下の選択肢より、表 2 モデルの変更案の説明として正しいものを全て選んでください。（複数選択可）(1)

案 1 では、座席利用明細クラスがサービスを利用した時点の座席単価を表現し、座席クラスが現在の座席単価を表現していることがモデルのみを見て分かるため、同じ属性が 2つのクラスに分散していることについてモデルを見る人に説明する必要はありません。

(2)

案 2 では、会員がサービスを利用した時点の座席単価は過去の料金を参照することで分かりますし、座席単価を適用した期間ごとに売上げの推移を確認することもできます。

(3)

案 3 では、座席単価が変更されるたびに該当するオブジェクトを生成するので、店舗にある実際の座席 1 つに対して座席クラスのインスタンスが複数生成されることになります。このため、他の案と比べて、現在の座席の空き状況を確認しにくいモデルといえます。

-6–
Copyright©2008 UMTP

LastUpdate : 2008/12/08

設問 4
当初のモデルでは「商品注文明細」と「座席利用明細」を別のクラスとして考えていましたが、将来的にアミューズメント（ビリヤードやカラオケ）の利用などのサービスを追加して、明細の種類を増やすことを検討しています。そこで、明細に関する部分について、適切な構造や振る舞いを検討するために、以下の 2 つの案を考えました。

案1

現状のままの方針で、明細毎に対応するクラスを作る

商品注文明細

座席利用明細ビリヤード明細

小計金額を計算する( )小計金額を計算する( )小計金額を計算する( )

・・・

案2

スーパークラスに共通の属性や操作を持たせた「注文明細」クラスを切り出し、サブクラスに「商品注文明細」、「座席利用明細」クラスと、個々の明細クラスを特化させる
注文明細
注文

1

小計金額
数量

1..*

小計金額を計算する( )商品注文明細

座席利用明細ビリヤード明細

小計金額を計算する( )小計金額を計算する( )小計金額を計算する( )販売商品

座席ビリヤード

表 3 明細に関する拡張案-7–
Copyright©2008 UMTP

・・・

LastUpdate : 2008/12/08

以下の選択肢より、表 3 明細に関する拡張案の説明として記述している内容が正しいものを全て選んでください。（複数選択可）(1)

注文の合計金額を求めるとき、「商品注文明細」や「座席利用明細」以外にも新たな明細が増える場合、案 1 では案 2 に比べて「注文」クラスの実装が複雑になり、保守性が低下しやすい。

(2)

小計計算をするとき「座席利用明細」だけ割引を適用する場合がある。そのため、案 2 のケースにおいて「座席利用明細」クラスに操作「割引を適用する（ ）」を持たせた。それにより、「注文」クラスが合計金額を計算するときに「座席利用明細」を特定して操作「割引を適用する（ ）」を直接呼び出すという実装が可能になった。この方法は、利用する側に柔軟な利用方法を提供する好例であり、できる限り採用したほうが良い。

(3)

両案ともに、明細毎に計算方法が異なるため、小計金額についての計算は、明細のクラス毎に個別に実装したほうが良く、合計金額についての計算は、「注文」クラスで実装したほうが良い。

(4)

注文の合計金額を求めるとき、「商品注文明細」と「座席利用明細」以外に新たな明細が増えたり減ったりしても、案 2 では「注文」クラスで、どのような明細があるのかを意識せず実装できるため、将来的に明細の種類が頻繁に変更されるケースに対応しやすい。

(5)

案 1 の場合、明細の種類が増えたとしても、全ての明細における共通ロジックを、個々の明細で重複して持つ必要が無いため、共通ロジックを変更したときの全体的な影響は少ないといえる。

-8–
Copyright©2008 UMTP