SadManです
＞清野さん
> ところで「業務指向」や「データ指向」と「オブジェクト指向」は
> 対立関係にあるのでしょうか？両立することはできないのでしょうか？
>
> さらには、
> UMLで概念クラス図をモデリングする
> ということは、
> オブジェクト指向でクラス図をモデリングする
> ということなのでしょうか？
>
> 「業務指向」でモデリングする際にツールとしてクラス図を使う。
> ということは忌避されているのでしょうか？
> 私は、それが業務を理解するために有効であるならば
> 「業務指向」や「データ指向」でクラス図を描くこと
> に何の抵抗もありません。
> 仮にその概念クラス図が実装クラス図とかけ離れているならば、
> 業務を理解したうえでさらに実装クラス図を「オブジェクト指向」でモデリング
> すればよいのではないでしょうか？
> これは絶対不変の大原則なのでしょうか？
> 単純にこうするとクラスを探し出しやすいという、
> 手段の一つということだとも考えられないでしょうか？
クラス自体およびモデリングさらにはモデルという考え方自体が
オブジェクト指向に基づいているので
モデリングをオブジェクト指向以外で行う事に自己矛盾を感じます
これはもう考え方の違いと言わざるを得ないと思いますが
不変の原則や忌避されているという事ではないと思います
つまり、物理的存在でないものを擬物かしてオブジェクトとして扱う事もできるわけです
クラス図が動的側面を表現しにくいという事はさんざん既出だと思いますが
UMLにはアクティビティやコラボレーションがあります
清野さんのスタイルではこちらの方が馴染みそうに思います
> 我々は、ビジネスアプリケーションを対象としたときにも
> 大原則：「現実の物体そのものをオブジェクト」
> が本当に正しいのかということを、もう一度検証してもよいのではないでしょうか？
> 私は、ビジネスアプリケーションにおいては
> 「現実の物体そのものをオブジェクト」
> ではなくて
> 「業務上のイベントをオブジェクト」
> という「業務指向」、「データ指向」でモデリングした方が
> 「オブジェクト指向」のモデル、つまり、クラス図が描きやすいと感じています。
> 「現実の物体そのものをオブジェクト」
> 「業務上のイベントをオブジェクト」
> などはデータ（属性）を意味のまとまりに分類（クラス分け）する
> ための基準のひとつでしかないように思うのです。
> また「データ指向」なのか「オブジェクト指向」なのかで、
> 意味のまとまりであるクラスが異なることに、違和感を感じています。
結果として同じ解釈にたどり着くならばアプローチの違いと言えますが
違う解釈にたどり着くならば単なるアプローチの違いとは言えなくなります
前回のポストで例にあげた電源スイッチの例などがそうです
スイッチの状態を履歴や部屋の照度計などのスイッチ以外から導くのは不自然です
逆の例で言いますと、自動車のナビで自動車がどこにいるかを把握する場合
逆に自動車クラス自体に位置情報を持つべきでなく、自動車以外のものから位置を割り出すのが妥当であるといえます
この違いはどうお考えでしょう？外部情報から導ける情報は須らく導くべしと思いますか？
わたしはデータの質によってどちらも有ると思います、この時の判断基準は
その物自体の性質であるかどうかであって、これは正にオブジェクト指向です
もう一点、ERについて、これは狭い意味でオブジェクト指向と言えます
MVCのMの部分を意味のあるデータの集まりにクラス化し
その間に関連をもたせているのですから
業務指向的に設計されたDBは経験上とてつもなく使いにくくなります
> 「状態もシステムで管理するべきなのは自明」とありますが
> クリーニング店システムの開発の目標に
> 「対費用効果の高いところをシステム化」
> があげられています。
> 「クリーニング店の業務全体をシステム化」
> ではありません。
>
> ・受け取る
> ・洗う
> ・返す
> が基本であることは語られていますが、まだそれらすべてをシステム化することが
> 「対費用効果が高い」と結論付けされていないのではないでしょうか。
> 平澤さんがおっしゃるように「対費用効果が高い」範囲を明らかにするために
> 「洗う」「返す」もモデリングする必要があると思います。
> ただし、これは
> システム化するかどうかを判断するため
> にモデリングするのであって、
> システムで管理することが自明
> だからモデリングするのではないと考えます。
自明なのは動機ではありません
が、動機の違いは問題にならないと思うのです
動機の違いによってモデルが変化したらおかしいからです
モデリングしなければ対費用効果を量れないからモデリングしてみるわけなのに
システム化が結論付けられていないのでモデリング対象としなくてもよい
矛盾していると思いませんか？
ゆえに、全体の業務をモデリングしてみなければならないのは自明なのです
まとめ：
オブジェクト指向至上主義なのではありませんが、これも経験から
java、UMLなどがOOPに基づいて出来ているのでそれに沿ったアプローチが自然です
それで賄えない部分は工夫して、イベントや実体の無いものをオブジェクトと置き換えてみたりしても良いと思います
しかしそれは一定の妥当性があっての事だと思います
オブジェクト指向が万能とは思わないので
目的の為にいろいろなアプローチをするのは良い事と思います
がシンプルにOOPでできるところを敢えてOOPを捨てて行う必要はないし
実のところそのメリットが今のわたしにはよく伝わりません
SadMan