みつじです。
SadManさん、
> データ指向がMVCのMにおいてオブジェクト指向に似ている事は清野さんも述べていますね
そうですね。そして設計モデルの段階で (M)odel として詳細化される部分を、
より高い抽象度で記述するのがドメイン分析であり概念モデルであると思います。
> 業務指向については
> 局所的に業務指向と似たような活動が現れる事はあると思いますが
> 根本的なアプローチが全く異なりませんか？
>
> 業務指向的な分析や開発だと、業務自体の流れを隈なく精査しながら
> その中から必要な処理や共通点を抽出し実装に落としていくという感じに思います
> つまり頂点が業務でありトップダウン的に実装が生まれてくる
要求分析において、個々のユースケースの分析で業務指向的な活動が
繰り返し行われるということだと思います。
ユースケース記述は下記のように詳細化されていきます。
（前にも述べましたが、OOD全般では一般的でないかもしれません）
ビジネス・ユースケース → システム・ユースケース → （設計モデルの）クラスの操作
ビジネス・ユースケースはシステム・ユースケースを用いて実現され、
システム・ユースケースは（設計モデルの）クラスの操作を用いて実現されるので、
各段階で共通点の抽出も行われます。
> オブジェクト指向では、業務の中からクラスや関連を抽出していき一度モデル(静的でも動的でも)を作り上げる
> すると業務は各オブジェクトの自律機能の組合せによって表現される事になりますから
> 業務自体は従という位置付けになり、ボトムアップ的なアプローチになります
業務を静的な側面から分析するときは、個々のデータ（エンティティ）から始める
ボトムアップ的なアプローチが適していて、動的な側面から分析するときは、
個々の機能（ユースケース）から始めるトップダウン的なアプローチが適しているのだ
と思います。
そして、設計モデルの段階で属性と操作の両方が定義されたクラス図と、
操作の内容を定義したシーケンス図に結実する。
ほかにも色々な図がありますが、実際のコードに落とすために必要になるのは
この2つの図で、ほかの図はこれらの導出をサポートするものと考えてもよいと思います。
> メリットがあると思うのはやはりECでしょうか？
> モデルが適切であれば業務の変更に対して比較的柔軟な実装が得られると思います
>
> なぜならオブジェクトはそのクラス(対象となる概念)の普遍的な原質を持たせることができるから
ボトムアップにもトップダウンにも偏らず、両方のアプローチから分析するからこそ、
設計モデルのクラスに変更への柔軟性や再利用性が約束されるのではないでしょうか。