オブジェクト・モデリングのボトルネック

要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』で使用するスライドの背景説明第2弾です。

「オブジェクトモデリング」として用意した以下の図を説明します。

オブジェクト・モデルの構成

オブジェクト指向分析/設計ではシステムを色々な観点のモデルを組み合わせて記述します。

ここでは、静的構造モデル、状態機械モデル、協調モデルの3種類のモデルによる軸について考えます。(これとは別の軸で、ドメイン・モデル／アプリケーション・モデルの軸、論理モデル／物理モデルの軸、もあります。)

静的構造モデルは、モデルの静的構造をクラス図やコンポーネント図などを用いて記述します。ドメイン・モデルや配備モデルの中核モデルとして用いられます。

状態機械モデルは、オブジェクトの状態遷移モデルを状態機械図や状態遷移表で記述します。オブジェクトモデリングの動的モデルの基盤となります。

協調モデルは、システムを構成するオブジェクト群の協調動作をメッセージパッシングによるオブジェクト間の相互作用として記述します。相互作用は、相互作用図(interaction diagram) であるシーケンス図(sequence diagram)とコミュニケーション図(commnunication diagram) (旧コラボレーション図, collaboration diagram)で記述します。

また、協調モデルの中で抽象的な位置付けのモデルとしてユースケースモデルがあります。ユースケースを現実化(realization)するとコラボレーション、コラボレーションを抽象化するとユースケースになるという関係です。ユースケースはUML的にはユースケース図で記述しますが、これはユースケース・モデルの目次みたいなもので、ユースケース記述、シナリオがユースケースの肝となる情報です。

ユースケースは、要求モデルの中軸モデルです。ユースケースによって記述された要求モデルを、ユースケースをコラボレーションに落とし込むことで、システムの静的構造モデル、状態機械モデルに反映させていくことになります。

オブジェクトモデリングの問題点

静的構造モデルと状態機械モデルは、プログラムに落とし込めるレベルのものを宣言的に記述することが可能です。

しかし、協調モデルについては、静的構造モデルや状態機械モデルとはモデルの練度が異なっていて、直接プログラムに落とし込むレベルのものは記述することができません。インスタンス(実例)ベース、帰納的に記述したモデルを、手動でプログラムに落とし込むことになります。

オブジェクトモデリングの問題点は、協調モデルが不完全なためにモデル駆動開発で使えるレベルのプラットフォーム独立な動的モデルを記述できない点にあります。さらに、協調モデルは要求モデルとシステムをつなぐ重要な役割も担っているので、このモデルが機能不全を起こしていることの影響は深刻です。

また、協調モデルが取り持つことになっている静的構造モデルと状態機械モデルの連携も不完全になり、結果として静的構造モデルのみの運用になってしまいます。静的構造モデルのメインの用途はドメイン・モデルの構造記述ですから、事実上、クラス図を使ってデータモデリングをしているのと変わらないことになってしまいがちです。

Object-Functional Analysis and Design (OFAD)での論点

OOADに関数型を編み込んでOFADに昇華させるための論点として、色々あると思いますが、今の所、以下のものを中心に考えています。

• 状態機械と関数の関係
• 要求モデルの記述方法と関数型との関係
• 協調モデルの問題点を関数型で緩和できるのか
• データフローモデルの使いどころ

特に、オブジェクトモデリングの欠点を埋める「協調モデルの問題点を関数型で緩和できるのか」という論点が重要ではないかと考えています。他の項目は、OOADに対してFPで何を足すのかということですが、この項目は、OOADのボトルネックをFPが緩和(理想的には解消)できるのかという切り口なので、うまく適用できれば、OOADからOFADに移行する大きな誘因になるからです。