清野です。
文章でのやり取りは難しいですね。
既にSadManさん、みつじさんと意見は一致していると思いますが、
私の考えでもあり、他の方の意見も聞いてみたいな、というは
次の点に尽きると思います。
ER図もクラス図もデータを分類して静的構造を表現するものだから
本質的には同じもの。
データの静的構造で業務を分析する作業において、いずれの図を
利用するかで「DOA対OOA」の構図を議論する必要はない。
なぜなら、どちらも同じことをしているのだから。
その他はSadManさんのおっしゃるように枝葉末節で、極論を言えば、
「分析者のやりやすい手法を実践すればよい」
ということだと思います。
その上で「自分ならどうするか」を書いたつもりでした。
> 私には清野さんがおっしゃるクラス図がどのようなものなのか、
> 具体的にイメージすることが出来ません。
>
> せっかくのモデリング道場ですから、実際に描いて見せていただくと
> 理解が進みやすいのではないかと思います。
その通りですね。
まずやりたいことは、クラス図という論理的な静的構造を作り上げることで
業務の論理的な構造を確認することです。
これにより業務を理解することができます。
ところで、クラス図に登場すべきクラスを特定しなければクラス図を
モデリングできません。
クラスを見つけるためには、クラスとは何か、の基準を持つ必要があります。
私の使用する基準です。（記述が長くなりそうなので単純に表現します。）
「クラスとは、ある業務を行ったときに、その業務の事実を記録するものである。」
＃多分、この基準がいろいろな議論の震源地なのではないかと思います。
「業務を行った事実を記録するものがクラス」とするならば、
「記録するべき事実」を伴う「業務」を見つける必要があります。
伴わない業務は、『この時点』では無視します。
そこで、「お題のクリーニング店」に戻ります。
>純白 四郎
>「預かって綺麗にして返す、これが基本だな。
>お客さんからクリーニング品をお預かりしたら、
>お名前と電話番号をうかがってから、
>整理番号をつけてチケットを渡すんだ。
>あとでそのチケットを持ってきてくれたら、
>綺麗にしたものをお返しする。
最終的に「対費用効果の高い部分」を特定するためには「預り」以外にも
分析対象を広げる必要が出て、次の範囲が必要だということがわかったとします。
＃お題のタイミングで開発太さんが作成したものではなく、もっと分析が進んだ
＃状態です。
業務1)預かる
業務2)綺麗にする
業務3)返す
この順序で業務が行われれば、無事クリーニング店は営業ができそうです。
また「対費用効果」の高い開発範囲を検討できそうだ、ということになったとしま
す。
いよいよ、クラス図をモデリングして、本当に営業できるかの確認です。
各々の業務の事実を記録するクラスを定義します。
業務1)預かる -> 「預り」クラス
業務2)綺麗にする -> 「クリーニング」クラス
業務3)返す -> 「返却」クラス
業務1)預かる については細かな業務ルールがいくつかわかっています。
>純白 四郎
>「預かって綺麗にして返す、これが基本だな。
>お客さんからクリーニング品をお預かりしたら、
>お名前と電話番号をうかがってから、
>整理番号をつけてチケットを渡すんだ。
>あとでそのチケットを持ってきてくれたら、
>綺麗にしたものをお返しする。
預かり時にお客さんの名前と電話番号を聞く。
預かりごとに整理番号をつける。
顧客管理はしていない。
>開
>「似たようなシャツとかはどうやって区別するんですか？」
>
>純
>「お預かりしたものに1枚ずつタグをつけておくんだよ。
>そこにも整理番号を書いておくから、わからなくなったりはしないな。
品物には整理番号記載のタグがついている。
>開
>「料金はどうやって決まるんですか」
>
>純
>「料金表があるよ。品名によってみんな料金は決まっているな。
>それから、防虫や防水の加工を承ることもある。
>このコートを防水加工してくださいとか、背広を防虫加工してくれとか、
>ワイシャツはそのままでいいとか、注文してもらうんだよ。
>防虫は品物に関係なく一点500円、
>防水は品名によってそれぞれ料金を決めているな。
>背広なら800円、コートなら660円とまあ、こんな具合だ。」
品物に対して、品名ががある。
品名とは、「コート」、「背広」、「ワイシャツ」など。
品物によって料金が決まっている。
品名のほかに、加工がある。
加工とは、「防水加工」、「防虫加工」など。
加工は、品名によって料金が変わるもの、変わらないもの、がある。
>開
>「なるほど。
>クリーニングだけしたり、クリーニングと防水加工だったり、
>防虫加工だけっていうこともあるんですね。
>「コートを2枚預かって、1枚はクリーニングのみ、
>1枚はクリーニングプラス防水加工のときはどうするんですか？」
>
>純
>「ああ、さっき言ったタグあるだろ、防水加工っていうタグもあるんだ。
>それを付けて、どれを防水加工するのかわかるようにしておくんだよ。」
同じ整理番号の預かり品がある。
つまり、一回の預かりで複数の品物を受け取ることがある。
業務2)綺麗にする については詳しい記述がありませんが、
ここでは品物単位にクリーニングされる、としました。
業務3)返す についても詳しい記述がありませんが、
預かりではなく、品物単位での返却がある、としました。
作成したクラス図はこちらです。
http://www.ops.dti.ne.jp/~hseino/class.png
業務1）預かり
「預り」クラス、「品物」クラスのインスタンスを生成します。
この時、「品名」クラス、「加工」クラスを参照します。
=>「品名」クラス、「加工」クラス、「加工料金」クラスは
別途違うタイミングで記録されている必要がありそうです。
業務1)預かり を見つけることで芋づる式に出てきたクラスです。
業務2) 綺麗にする
クリーニングした「品物」クラス（のインスタンス）を参照するような
「クリーニング」クラスのインスタンスを生成します。
業務3) 返す
「品物」クラスを参照するように「返却」クラスのインスタンスを生成します。
クリーニング完了したもののみ返却可能という制約はあるのか？
クリーニングされていないものも返却する必要はあるか？（キャンセル）
キャンセルしたとすると料金の扱いはどうするか？
料金の先払い、後払い、精算なども管理するか？
など確認したい項目が出てきました。
特に返却と料金について確認したいことが、たくさん出てきました。
業務1〜3)でデータの静的な構造を構築できましたので、
想定したクリーニング店業務は論理的（文法的）には正しいようです。
ただし、確認したい項目も多数出てきましたので、
先ほどのクラス図を持って確認に行くことにします。
というようなことをすることをイメージしています。
いかがでしょうか。
−−
清野博之