マルチパラダイムモデルを想定した分析設計

ソフトウェア開発の対象となる要求、より根源的には価値、の表現には、振る舞いと情報の2つの側面が隠されています。
ある意味でこの2つの側面を抽象化し、名前を付けたのが価値や要求とも言えます。

ソフトウェア開発では、振る舞いと情報を一体として持つ価値や要求はそれぞれ別のモデルで表現されることが多いです。
アクティビティ、概念モデル、あるいは、DFD、ERDなどを使い分けて、ソフトウェア開発の対象領域を表現します。
このように振る舞いと情報を分ける表現は、それらを一体とした表現に比べて、それぞれの特徴や構造を表現するのに適していて、特に複雑になりがちな大規模システムでは有効となります。ドメイン毎の関心を表現するDSLの一種とみてもいいです。

しかし、この2つを分離する理由は、これだけではありません。

現在の開発の主流である、オブジェクト指向パラダイムは、振る舞いと情報（データ、状態）を一体化したモデルによる分割と構造化でシステムを表現する方法です。この定義に従えば、最初から、振る舞いと情報が一体となっている価値や要求をそのままオブジェクトで表現した方がわかりやすいと言えます。POJOなどビジネスロジックをそのままクラスで表現するのは、この考え方に基づいた、開発を容易とする手法の一種です。
しかし、常に価値や要求がクラスと1対１となるのならば、これほど簡単なことはありません。
問題は、共通性の高い振る舞いや情報、変化するスピードの違う振る舞い（ロジック）や情報、の扱いを考える必要がある点です。あるいは、企業システムでは、ERPやマスタデータなど既存の資産も膨大にあるので、それらを考慮すると簡単ではありません。

OOをサブシステムのアーキテクチャの実現技術のパラダイムに採用する場合であっても、データを中心に考え、そこにデータに必要な操作をつける場合と、振る舞いを中心に考え、そこに必要な状態データをつける場合が存在します。結果としては、出来上がる振る舞いとデータの一体化はともにオブジェクト（クラス）となります。が、分析する手法は異なり、前者はデータ中心アプローチ、後者にはアクティビティやワークフロー、状態遷移図を使った分析が有効です。前者はデータアーキテクチャの中心となるマスタデータなどのCRUD操作を対象とし、後者は、データ操作よりも処理を中心とする中間層のオブジェクトが対象となります。

振る舞いと情報を一体とする実現技術はOOパラダイムだけが有効であるとは言えません。OOではメソッドがロジックを記述する最小単位となります。が、このメソッドという括りに依存せず、プログラムのコードの任意の領域をカバーする抽象的なアルゴリズムを考えることができます。この抽象化のモデルに振る舞いとデータを一体として持たせることで、OOパラダイムに限定されない、振る舞いとデータを持つモデルを作ることができます。たとえば、関数型パラダイムのクロージャがこのモデルに相当します。

こうした複数のパラダイムが持つモデル要素を実現技術として持つ場合、制約条件に応じて実現技術を柔軟に選択できます。時として、特定パラダイムの実現技術の決定後も、実装に関する評価を遅延させることもできます。この柔軟性を持つためには、パラダイムに依存しない概念モデルとして、振る舞いとデータを分離した表現を持ち、実現の選択肢を考慮しながら、論理モデルで、それらを分割や統合していく方法が有効となります。こうしてできた論理モデルは、並列、非同期などの処理の単位となり、識別、参照、生成、呼び出し、保存の対象となります。