オブジェクトと関数の連携(3)

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

• 関数型言語の技術マップ
• オブジェクト・モデリングのボトルネック
• 代数的構造デザインパターン
• 圏論デザインパターン
• オブジェクトと関数の連携(1)
• オブジェクトと関数の連携(2)

今回は背景説明第7弾として、「オブジェクトと関数の連携(3)」として用意した以下の図を説明します。

アプリケーション・アーキテクチャ

アプリケーション・アーキテクチャを考える場合、システムのレイヤ構造の視点が重要です。ここでは、システム、サブシステム、モジュール、コンポーネント、オブジェクトの5階層を考えます。具体的な実装を持っているのはオブジェクトで、オブジェクトをソフトウェア部品の単位で束ねたものがコンポーネント、コンポーネントを物理的な配備の単位で束ねたものをモジュールと呼ぶことにします。システムをドメインごとに分割した物がサブシステムで、サブシステムは複数のモジュールから構成されます。

システム、サブシステム、モジュール、コンポーネント、オブジェクトは、メタ・モデル的には同じ構造を持っており、オブジェクト・モデル上での運用で使い方を決めています。システム、サブシステム、モジュール、コンポーネント、オブジェクトを総称する場合は、分類子と呼ぶことにします。

モデル記述

図ではシステムの振舞いを記述するモデルの候補として以下の2つを挙げました。

• プロセス計算
• データーフロー

プロセス計算

ボクの理解では、プロセス計算はオートマトンがベースで、モデルの記述方式として制御フロー的なアプローチと、状態機械的なアプローチがあり、理論的には相互に変換可能です。

制御フロー的なアプローチの代表が、有名なCSP(Communicating Sequential Processes)です。状態機械的なアプローチとしては、FSP(Finite State Processes)などがあります。

HoareのCSPが最初に発表されたのが1978年ですから、プロセス計算自体は相当昔からある理論です。しかし、今の所、エンタープライズ分野では普及しているとは言えません。普及していない理由は色々あると思いますが、実務での展開を考えた場合、特に以下の2つの問題が重要です。

• オープンソースで無料で使える実装が見当たらない(知られていない)
• 理論(使い方)が難解

プロセス計算系の技術を実現したものは色々とあるようですが、一般的な意味(たとえばApacheのトッププロジェクト級)で有名なものはないと思います。

また、研究者向けの文献は多数あるものの、プログラマ向け、(この分野の)初心者向けの平易な解説書がなく、一般のエンジニアが実務に適用することはかなり困難です。

個人的には、ひとつの目安はパーサーコンビネータによる構文解析だと考えています。Scalaのパーサーコンビネータは使い方も比較的簡単で機能も強力ですが、少なくてもこれと同程度の使いやすさのものが入門用の文書と込みでオープンソースで提供されてこないと、エンタープライズでの一般の開発に使うのは難しいと思います。

データーフロー

プロセス計算もいずれ実用化されてくると思いますが、短期的な観点でより実現の可能性が高いのがデーターフローです。(ここでは、データフローをデータフロー図的なモデルの意味で使います。)

データフローは、OOADが登場する前に支配的な開発方法論だったSA/SDで広く使われていた技術です。OOADでも、初期(1991年)に一世を風靡したOMTの機能モデル(function model)として採用されています。しかし、OOADはOOSE系のユースケース駆動が主流になったため、データフローはUMLでは(アクティビティ図の一部としてかすかに残っていますが)主軸のモデルからは外れており、事実上ロスト・テクノロジとなっています。(2004年のOMT第2版では、OMTもユースケース駆動になりデータフローはなくなっています。)

データフローは、ある意味でデータの計算過程を示しているので、関数型言語との相性がよいと思われます。そういう意味で、関数型言語が実用化されると、実績のある技術であるデータフローも再発見されることになるのではないかと思います。

オブジェクトと関数

システム、サブシステム、モジュール、コンポーネントは、考え方によっては実装技術にニュートラルな分類子です。オブジェクト・モデルの場合は、コンポーネントの実装技術にオブジェクトを用います。たとえば、コンポーネントの機能はファサード的なオブジェクトが代表として実現し、具体的な処理をプログラムとして実行します。

このため、システム、サブシステム、モジュール、コンポーネントでは実装独立の抽象度の高いモデルであるプロセス代数やデーターフローで、モデルを記述することになります。

一方、オブジェクトの場合はモデルを記述してもよいですが、その具体的な実現を関数で実装することも可能です。

ビジネスフローと状態機械

システム、サブシステム、モジュール、コンポーネントはビジネスフローを持つことができますが、これをプロセス代数で記述するアプローチができます。この場合は、制御フロー的な記述方式を用いることになります。

システム、サブシステム、モジュール、コンポーネント、オブジェクトは状態機械を持つことができますが、これをプロセス代数で記述するというアプローチも可能です。この場合は、状態機械的な記述方式を用いることになります。

どちらも有力なアプローチですが、プロセス計算自体のエンタープライズ・アプリケーションへの展開は、もう少し先の事になりそうなので、ここでは可能性を指摘するにとどめておきます。

メソッドとアクション

システム、サブシステム、モジュール、コンポーネント、オブジェクトのメソッドやアクションは、通常は手続き的に処理を記述しますが、ここにデーターフローを記述することが有益です。

つまり、状態遷移時のアクションや操作を呼び出されたときのメソッドの動作が、データの状態遷移を引き起こす場合、データは事前条件から事後条件へデータの更新が行われます。この更新データの計算にデータフローを使用することができます。

この処理が単純な場合には、もちろん関数でそのまま記述すればよいのですが、以下の場合にはデータフローのモデルで記述して、フレームワークなりモデルコンパイラなりに処理を委譲するのが有力な選択肢になります。

• データフローの内容が複雑
• 処理データ量が膨大

次のスライドでは、この辺について考えます。