みつじです。
清野さん、SadManさん、私にも意見させてください。
>ところで「業務指向」や「データ指向」と「オブジェクト指向」は
>対立関係にあるのでしょうか？両立することはできないのでしょうか？
まず用語の確認ですが、
「業務指向」とは、処理の流れを重視した分析手法と考えてよい
でしょうか？具体的には、データ・フロー・ダイアグラムなどを用いて
大きな処理を小さな処理の集まりとして段階的に詳細化していくことで
業務を理解しようとするものです。
バッチ処理の記述などに適していると言われるあれですね。
「データ指向」とはデータの構造を重視した分析手法と考えて
よいでしょうか？具体的には、エンティティ関連図などを用いて
処理されるデータがどのように関連しあっているかを記述することで
業務を理解しようとするものです。
関係データベースを用いたオンライン・システムの記述など
に適しているというあれですね。
私は、この2つはオブジェクト指向と対立するのではなく、
オブジェクト指向に吸収されたものだと考えています。
（怒られちゃうかもしれないけどｗ）
[modeling-dojo:00370]の投稿とも関係してくるのですが、
ここでの用語を借りると、
・ドメイン分析（概念モデル）≒「データ指向」
・要求分析（要求モデル、ユースケース記述）≒「業務指向」
ということになると思います。
ドメイン分析レベルで使うクラス図は、操作を描かないのでE-R図に近いし、
ユースケース記述にアクティビティ図を使うとすると、それがDFDに対応する
ように思います。
違いは、クラス図にはE-R図にない汎化・特化という強力な機能が
備わっていること、アクティビティ図にはDFDのように処理を入れ子構造で
記述する手段がないことだと思います。
ただ、E-R図で表現できることは全てクラス図で表現できるし、
DFDで入れ子構造を用いて段階的に詳細化していく部分は、
もっと後の工程でオブジェクト間のメッセージのやり取りに
置き換えられるから、結局は同じことをやっているんだと思います。
分野によっては、「データ指向」や「業務指向」が有利なものも
残されていると思いますが、今日のシステム開発では、たいていの
場合、両方の利点を生かせるオブジェクト指向分析でOKだと思います。
>私は、ビジネスアプリケーションにおいては
> 「現実の物体そのものをオブジェクト」
>ではなくて
> 「業務上のイベントをオブジェクト」
>という「業務指向」、「データ指向」でモデリングした方が
>「オブジェクト指向」のモデル、つまり、クラス図が描きやすいと感じています。
>＃もちろん、これが間違っている可能性もあると思います。
>＃MLやコンテストを通じて検証していきたいと考えています。
私には清野さんがおっしゃるクラス図がどのようなものなのか、
具体的にイメージすることが出来ません。
せっかくのモデリング道場ですから、実際に描いて見せていただくと
理解が進みやすいのではないかと思います。