UMLモデリングカフェ第14回：百貨店のフロアをモデリングする

モデリング

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

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

1．前回の問題（ WBS ）

前回の問題をもう一度確認しておきましょう。

【お題13】WBS

とあるプロジェクトで、工数管理をする目的で以下の WBS を作成しました。この WBS をモデリングしてください。

タスク	状態	期日	担当者	予定工数	実績工数
A. 読者解答をレビューする	済	2007/8/24		20 h	15 h
A-1. 読者Ａの解答モデルをレビューする	済	2007/8/22	唐沢	5 h	3.5 h
A-2. 読者Ｂの解答モデルをレビューする	済	2007/8/22	吉井	5 h	3 h
A-3. 読者Ｃの解答モデルをレビューする	済	2007/8/22	青木	6 h	4.5 h
A-4. レビューを取りまとめる	済	2007/8/24	唐沢	4 h	4 h
B. お題を作成する	済	2007/8/28		6 h	5.5 h
B-1. 問題文を作成する	済	2007/8/27	吉井	4 h	3 h
B-2. 解答例を作成する	済	2007/8/28	唐沢	2 h	2.5 h
B-2-1. コンセプトを作成する	済	2007/8/28	唐沢	1 h	1 h
B-2-2. モデルを作成する	済	2007/8/28	唐沢	1 h	1.5 h
C. HTML を作成する	着手	2007/8/30		7 h
C-1. 本文の HTML を作成する	着手	2007/8/30	久本	4 h
C-2. 紹介できなかった解答モデルの HTML を作成する	未	2007/8/30	久本	3 h

お題（ WBS ）

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

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

ポイント解説

WBS とは作業を分解したもの（その図表）です。 WBS はさまざまな目的で作成されますが、おそらくどんな場合でも作業を分解したものという点は変わらないでしょう。本質としてまず押さえておきたい点です。

次に、お題の WBS の表を見てみましょう。先ほどの「WBS は作業を分解したもの」というのは、「タスク」列で表現されています。その他の列は何を表しているのでしょうか。

ここで一般論の話になりますが、表の行や列の形式にはいくつかあるかと思います。ここでは２つの形式を取り挙げます。

行や列が項目になっているもの
このお題のように、項目が並んでいるもの。
行や列に軸があるもの
ある軸に沿って区分けや分類がなされているもの。例えば、駅の時刻表の縦軸（時刻）の「6時」「7時」「8時」・・・。テレビ番組表の横軸（チャンネル）の「1ch」「3ch」「4ch」・・・。

さらに言えば、表にはいろいろな形式があるでしょう。

ここでは、上記の２つの形式に限って、また列の場合について考えます。モデリングという点から見ると、1. の場合は「項目」の 1 つ 1 つ（列の見出し）がクラスの候補となるでしょう。そして、セルにはそのクラスのインスタンスが入ることが多いです。 2. の場合は列の「軸」がクラスの候補となるでしょう。そして、1 つの列（列の見出し）がそのクラスのインスタンスとなることが多いです。

再び、お題に戻ります。お題の WBS の列は、上記の 1. になっています。まずは、「項目」の 1 つ 1 つ（列の見出し）をクラスの候補として捉えると良いでしょう。次に検討したい点は、各「項目」がクラスになるのか属性になるのか、です。この点は考え方によって変化するところですので、コンセプトでしっかりと押さえましょう。

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

読者解答1：ありゅ～様

コンセプト
- 1つのプロジェクトは複数のタスクから構成される。
- 1つのタスクは複数のサブタスクから構成される。
- サブタスクは階層構造をとることができる。
- タスクには担当者が一人設定される。ただし、最上位のタスクには担当者が設定されない。
- タスクには状態、予定工数、実績工数などが設定される。ただし、最上位タスクの属性は、下位タスクから導出される。
モデル
- クラス図
  
  図 1 ありゅ～様の解答モデル（クラス図）
- オブジェクト図
  
  図 2 ありゅ～様の解答モデル（オブジェクト図）
感想
- 難しかったところ
  コンセプトを決めるのが難しかった。
  - 最上位タスクだけではなく、子タスクを持った場合は担当者や予定工数を設定されない、としたほうが良かったのかも。
- 自己評価
  - 75点。
  - 少し工夫しよう、と思って継承を使ったが余計だったかも。
  - もう少し検討してもよかったが、目安時間の中ではこんなものかな、と。

マスター		コンセプトを見ると、タスクにとても注目されています。
唐沢さん		短時間でのモデリングにも関わらず、上位のタスクの工数や状態が下位のタスクの工数や状態から導出されているところに気付かれています。素晴らしいです。
吉井さん		なかなか気付きにくいところなのにね。
久本くん		そっか。今気付きました。サブタスクの予定工数の合計が、その上位のタスクの予定工数になってるんですね。
マスター		そうですね。状態や期日も同じようになっていますよ。
久本くん		こういうときって、派生属性で表現するんですよね？
唐沢さん		ええ。表記は属性の名前の前に"/"（スラッシュ）を付けます。
吉井さん		大切なことは、何が何から求まるのかちゃんと明らかにしておくことだね。ちゃんとコンセプトに書いてあって良いと思うよ。
マスター		下位のタスクがあるタスクは派生属性になりますね。ですので「サブタスク」クラスの属性も派生属性になる場合が出てきますが。
久本くん		ほんとですね。感想の「難しかったところ」に書いてありますね。。。本当に難しいです。
◇
吉井さん		ところで、どうして最上位のタスクだけ「タスク」クラスで表現したんだと思う？
久本くん		えーと、最上位のタスクだけ担当者が設定されないからでしょうか。
マスター		ええ、派生属性もありますし、最上位のタスクだけ他と違った特徴があるということだと思います。
吉井さん		うん。
唐沢さん		お題が WBS であるという点からも意味があるのではないでしょうか。つまり、タスクを細かくしていく方向に注目しているのであって、逆にタスクを組み上げて大きなタスクにする方向には注目していないということです。
吉井さん		そうかもしれないね。
唐沢さん		気になることがあります。「タスク」と「サブタスク」が汎化関係になっていますが、親クラスである「タスク」から子クラスである「サブタスク」へ関連があるのはどうでしょうか。
久本くん		「サブタスク」も「タスク」であるということですよね？
マスター		確かにそう表現しているのですが、より抽象的な親クラスがより具象の子クラスに依存することになっています。
吉井さん		異なる抽象度が混在しているね。モデルが分かりにくくなるし、もしシステム開発の場合だったら再利用や保守性という観点からも問題が生じてくるね。
唐沢さん		ええ。親クラスが子クラスへ依存する関係は注意が必要です。
マスター		自己評価でも余計だったかもということです。

読者解答2：岩沢正樹様

コンセプト
- 「タスク」は何を知らなければならないか？、について注目をしました。
  - 「タスク」の担当者は最大で１人。
- 「工数」については、タスクと担当が決まったときに、予定が決まって実績も決まると考えました。
- 「実績工数」と「状態」の関係は、独立していると考えました。
モデル
- クラス図
  
  図 3 岩沢正樹様の解答モデル（クラス図）
感想
- 難しかったところ
  「工数」は、
  - そもそも誰が知っているか？
  - どのクラスによって特徴付けられるか？
  を特定するところが難しかったです。
- 自己評価
  - バタバタと整理をしましたが、そこそこになったと思います。
  - １０点満点で６点ぐらいでしょうか？

久本くん		工数の考え方に特徴がありますね。
マスター		そうですね。タスクと担当から工数が決まるんですね。
唐沢さん		担当者の生産性を考慮すれば納得できます。
吉井さん		そうだね。「タスク」クラスに作業量、「担当者」クラスに生産性のような属性があれば、もっと良かったかな。
久本くん		作業量を生産性で割ったら工数になる、ってことですね。
吉井さん		そう。
唐沢さん		でもそれは別の難しさにぶつかりますね。単純な量で測れるならば良いですが、作業量をどうやって定義するか、作業の難しさをどう扱うかなどです。
久本くん		うっ。見積をするときによく悩みます。。。
◇
マスター		多重度が少しわからないのですが。
唐沢さん		ええ。いくつかどう解釈して良いかわからないものがありますね。
久本くん		「タスク」クラスの再帰関連になっていますが、→は逆のような気がします。この場合だと、下位のタスクから上位のタスクを見れるんですよね？
吉井さん		ロール名がないからはっきりとはしないけど、そうなるね。考え方次第とはいえ、WBS はタスクを分解していくものだから逆の方がわかりやすいね。
マスター		「工数」クラスと「タスク」クラスの関係はどうでしょうか。
唐沢さん		「タスク」からみて「工数」が 0..1 はわかります。
久本くん		その逆はというと・・・う～ん。
吉井さん		コンセプトに明記がないから、これもはっきりしないね。もしかしたらだけど、お題の WBS には"5h"が複数のタスクにあるよね。だから、0..* になっているのかもしれない。
マスター		デザインパターンの Flyweight パターンのようなものでしょうか。
吉井さん		うん。でも、まずは素直に捉えた方が良いかな。それから、ロール名を付けたりオブジェクト図を書いて確認することが大事だね。
◇
久本くん		デザインパターンで思ったのですが、「状態」クラスを出しているのって、State パターンみたいですね。
マスター		そうですね。状態には「済状態」「着手状態」「未状態」があることが明示されていて分かりやすいです。
唐沢さん		ええ、分かりやすいです。代替案としては、状態を属性にしておき、「タスク」クラスの状態遷移図で記述する方法もあります。

読者解答3：松田政博様

コンセプト
- 要求
  以下のような要求を満たすモデルとする。
  - 遅延しているタスクを知りたい。
  - 担当者毎のタスクを知りたい。
  - 未着手、着手、済の各状態にあるタスクを知りたい。
  - 期日ごとのタスクを知りたい。
- 構造
  - プロジェクトは、複数のタスクからなる。
  - タスクは、作業を詳細に分解した最小タスクやいくつかのタスクを集めた複合タスクからなる。
  → 要求を満たすために、遅延、担当者、期日、状態のそれぞれのクラスからタスクに関連を持たせた。
- 制限
  - 先行するタスク、後続するタスクは表現していない。
モデル
- クラス図
  
  図 4 松田政博様の解答モデル（クラス図）
- オブジェクト図
  
  図 5 松田政博様の解答モデル（オブジェクト図）
感想
- 難しかったところ
  - 「遅延しているタスクを知りたい。」という要求を表現するところ。
- 自己評価
  - 各タスクの状態、期日などをタスクの属性でもよかったかなあ？

唐沢さん		このモデルはちょっと変わった捉え方をされています。
吉井さん		面白い捉え方をされてるね。
マスター		といいますと？
唐沢さん		DB を意識したような捉え方をされているところです。
吉井さん		そうそう。コンセプトにあるように、状態や期日なんかから該当するタスクを引っ張ってくることを考えているよね。
久本くん		本当ですね。検索条件みたいです。
マスター		なるほど。オブジェクト図を見るとそれがよく表れてますね。「済状態」を持ち上げると、その状態のタスクが紐付いてくる感じです。
久本くん		"要求"としてまとめているのが面白いです。
吉井さん		管理のお仕事をされているのかもしれないね。具体的にシステムのイメージを持たれたのかな。
久本くん		なるほどー。「遅延しているタスク」に対して興味を持たれていますしね。
◇
マスター		構造で目を引くのが Composite になっている点ですね。
吉井さん		うん。「最小タスク」「複合タスク」という考え方は良さそうだね。
久本くん		うまく整理されていますね。
唐沢さん		でも、1 つ難しい問題も生じます。動的分類になってしまうという問題です。
マスター		動的分類になりますか？
吉井さん		「最小タスク」という言葉に込められた意味によっても変わるけどね。
久本くん		どうして動的分類になるんですか？
唐沢さん		「最小タスク」を更に分解した場合です。それまでは「最小タスク」だったのが「複合タスク」に変わります。
吉井さん		プロジェクト管理のツールで WBS を書くときとか、やるよね？
久本くん		そっか。確かにありますね。でも、"最小"なんだから、更に分解するっておかしくないですか？
唐沢さん		そうかもしれません。
マスター		ファイルシステムなどでは、「ディレクトリ」が、ある時「ファイル」に変わるということは通常考えませんが、この場合はあり得そうです。
久本くん		圧縮ファイルを「ディレクトリ」のように扱えたりしますが、その場合はどうなんでしょうか。
吉井さん		どうなんだろうね。「ファイル」でもあり「ディレクトリ」の"よう"でもあり。難しいね。
◇
唐沢さん		派生属性という点はどうでしょうか。惜しいと感じているのですが。
マスター		このモデルでは考えられていませんね。
吉井さん		確かにもう一歩工夫できそうだね。「状態」クラスなどが「タスク」クラスではなく「最小タスク」クラスと関連があれば良いのかな。
唐沢さん		そうです。「複合タスク」クラスの場合は、その下位の「最小タスク」から求められます。
久本くん		下位の「最小タスク」がぜんぶ「済」のとき、「複合タスク」が「済」になるということであってますか？
唐沢さん		ええ。
マスター		なるほど。スマートですね。

3. 解答例

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

コンセプトの導出

Work Breakdown Structure の名前が表す通り、作業を分解する構造を表現します。この構造は、（粒度が異なる）タスク同士の関係として考えます。

次に、タスクの状態や期日、担当者、予定工数、実績工数の情報を付加します。ここでは、担当者や予定工数、実績工数は、工数管理をする上で付加された情報と考え、タスクとは異なる概念として捉えます。状態や期日はタスク自身の性質を表しているとして、タスクの属性として考えます。この時、1 つの指針として「タスクという概念のライフサイクル（ライフタイム）」を意識します。あるタスクが生まれたときに一緒に出来てそのタスクが無くなるときに一緒に消える情報は属性ではないかと考えます。

解答例

コンセプト
作業を分解する構造をモデリングする。
- 上位のタスクを分解したものが下位のタスクである。
- ある上位のタスクは、複数の下位のタスクに分解される。
- 上位、下位の関係は階層構造（hierarchy）である。最上位の上位はなく、また最下位の下位はない。
- お題には無いが、最上位のタスク「モデリングカフェの記事を作成する」があるとする。
- タスク間の時間的な順序性（A の次に B をやる）は考慮しない。
タスクについてモデリングする。
- タスクは状態を持ち、「済」「着手」「未」のいずれかの状態である。状態の間に複雑な関係はないため、クラス図上には表現しない。
- タスクには期日がある。
担当者がアサインされることをモデリングする。
- 担当者はプロジェクトメンバー（略してメンバー）であるとする。
- アサインされることを、タスクと担当者が関係付けされることで表現する。
- 1 つのタスクには 1 人のメンバーがアサインされる。ただし、最上位のタスクと 1 階層目のタスク（図の灰色の部分）にはアサインされないとする。
- あるメンバーは、複数のタスクにアサインされることもある。
予定工数と実績工数をモデリングする。
- 予定工数も実績工数もどちらも工数であり、同じ概念とする。
- 個別のタスクに対して予定としての工数と実績としての工数があるとする。
- 担当者の生産性は考慮しない。
- 実績は、タスクが済になってから記入される。それまでは空欄なので、実績はないとする。
モデル
- オブジェクト図
  
  図 6 解答例のオブジェクト図
- クラス図
  
  図 7 解答例のクラス図

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

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

【お題14】百貨店のフロア

百貨店「角井」のフロアガイドは以下のようになっています。

□｜□｜
11F	レストラン	和食　中華料理
10F	レストラン	フレンチ　イタリアン
9F	催事場	各種催し物
8F	スポーツ	スポーツ　レジャー
7F	紳士服	スーツ　フォーマル
6F	紳士服	ヤング　ミドル
5F	婦人服	キャリア　フォーマル
4F	婦人服	ミセス　コンテンポラリー
3F	婦人服	ヤング　カジュアル
2F	婦人雑貨	シューズ　バッグ　帽子
1F	ファッション	ジュエリー　アクセサリー　化粧品
B1F	食品	生鮮食料品　惣菜　ベーカリー　和・洋菓子