sadmanさん
清野です。
是非前向きな議論ができれば幸いです。
文才がないためか駄文長文で失礼します。
> 一言で言うと清野さんの思考方法は「オブジェクト指向」ではなく
> 業務指向やデータ指向であると言えるのではないでしょうか？
その通りだと思います。
私は普段からER図を使い業務分析しています。
クラス図で実務を行ったことはありません。
だからこそ、ER図とクラス図の違いは何か？、という疑問を解決したく
こちらのMLやモデリングコンテストに参加させていただきました。
ところで「業務指向」や「データ指向」と「オブジェクト指向」は
対立関係にあるのでしょうか？両立することはできないのでしょうか？
さらには、
UMLで概念クラス図をモデリングする
ということは、
オブジェクト指向でクラス図をモデリングする
ということなのでしょうか？
「業務指向」でモデリングする際にツールとしてクラス図を使う。
ということは忌避されているのでしょうか？
私は、それが業務を理解するために有効であるならば
「業務指向」や「データ指向」でクラス図を描くこと
に何の抵抗もありません。
仮にその概念クラス図が実装クラス図とかけ離れているならば、
業務を理解したうえでさらに実装クラス図を「オブジェクト指向」でモデリング
すればよいのではないでしょうか？
「概念クラス図を詳細化して実装クラス図とする」
というのも手段（の一つ）であって目的ではないと考えますので、
この原則から外れることにも抵抗はありません。
「概念クラス図」と「実装クラス図」が単純な誘導性を持っていなくても
意味的な誘導性を認知できればよいのではないでしょうか？
> OOPの説明に良く出てくるようにまず現実の物体そのものをオブジェクトと考え
> 次に物体ではないけれどもいろいろな概念をあたかも物体のように考えてモデル化
します
これは絶対不変の大原則なのでしょうか？
単純にこうするとクラスを探し出しやすいという、
手段の一つということだとも考えられないでしょうか？
我々は、ビジネスアプリケーションを対象としたときにも
大原則：「現実の物体そのものをオブジェクト」
が本当に正しいのかということを、もう一度検証してもよいのではないでしょうか？
私は、ビジネスアプリケーションにおいては
「現実の物体そのものをオブジェクト」
ではなくて
「業務上のイベントをオブジェクト」
という「業務指向」、「データ指向」でモデリングした方が
「オブジェクト指向」のモデル、つまり、クラス図が描きやすいと感じています。
＃もちろん、これが間違っている可能性もあると思います。
＃MLやコンテストを通じて検証していきたいと考えています。
「現実の物体そのものをオブジェクト」
「業務上のイベントをオブジェクト」
などはデータ（属性）を意味のまとまりに分類（クラス分け）する
ための基準のひとつでしかないように思うのです。
また「データ指向」なのか「オブジェクト指向」なのかで、
意味のまとまりであるクラスが異なることに、違和感を感じています。
この違和感の正体は何か？
というのが冒頭の
ER図とクラス図の違いは何か？
へとつながっています。
現時点では、ER図とクラス図の違いは「表記方法」と「活用範囲」と
考えています。
「表記方法」は識別子や関連の扱いなどです。モデル要素の違いであり
この違いは「業務を理解する」という上では些細なものと考えています。
「活用範囲」につてはER図がMVCのMに限定されるのに対し、
クラス図はMVCのすべてに適用できると考えています。（当たり前ですが）
クラス図のほうが広いということです。
＃これにはプラスの効果とマイナスの効果がありそうです。
概念クラス図に限定すればMを表現するということで、
ER図とクラス図のいずれでも目的は達成できると考えています。
> お題のインタビューにあるように「受け取って洗って返す」が基本ですから
> 業務の行動だけでなく、状態もシステムで管理するべきなのは自明です
> なぜなら、現実の業務が暗黙的に状態を把握しそれに依存して遷移するからです
「状態もシステムで管理するべきなのは自明」とありますが
クリーニング店システムの開発の目標に
「対費用効果の高いところをシステム化」
があげられています。
「クリーニング店の業務全体をシステム化」
ではありません。
・受け取る
・洗う
・返す
が基本であることは語られていますが、まだそれらすべてをシステム化することが
「対費用効果が高い」と結論付けされていないのではないでしょうか。
平澤さんがおっしゃるように「対費用効果が高い」範囲を明らかにするために
「洗う」「返す」もモデリングする必要があると思います。
ただし、これは
システム化するかどうかを判断するため
にモデリングするのであって、
システムで管理することが自明
だからモデリングするのではないと考えます。
＃その上でお題のタイミングで「洗う」「返す」もモデル化されているのは
＃不自然だな、もう少し後になるだろな、と先のメールでは記述したつもりでした。
もしかしたら、
「受け取り」だけをシステム化して、あとは受付記録を印刷し、
鉛筆なめなめ消しこんでいくほうがすべてをシステムでやるよりも
運用しやすい（対費用効果が高い）かもしれませんよね？
必ずしもパソコンのある環境で仕事をしているとも限りませんので。
あるいは、
「受け取り」と「返す」という店頭業務だけをシステムで行い、
「洗う」（洗ってあるかどうかを確認するを含めて）はシステム外で
行うことが「対費用効果が高い」かもしれません。
洗ってない預かり品を誤って返すということは運用上ありえない
ような気もしますので。
なぜならそこに「預かり品がない」＝「物理的に返せない」と想定できますし、
仮にあってもビニールがかかかってないとかいう物理的な状態で「洗ってない」
ことは「返す」前に気がつきそうです。
だとすると、
「洗ってない」のに「返す」＝キャンセルというのが逆に必要になりそうですが。
そういえば、キャンセルという状態もありますね。
私もこれを書いていて気がつきました。
−−
清野博之