2012年3月28日水曜日

EDAとオブジェクトと関数

3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。

今回はセッションで説明したモデルの改良案として、EDA(Event-Driven Architecture)の導入を行ってみます。

元のスライド

オブジェクトと関数型の繋ぎのところを具体的に考えるために2つスライドを作成しました。

「イベント→データフローの流れ」は、OOPレベルの細かい処理の流れを示しています。

「ユースケースと関数」は、OOADの観点からユースケース・モデルからOOPを経て、FPに至る流れを示しています。

OOADを軸としたアプローチが検討対象にしているので、いずれも(協調→)状態機械→アクションというオブジェクト・モデルとして素直な連携を軸に考えています。

実際に図にして考えてみると、(協調→)状態機械→アクションという流れのモデリングはあまり便利そうに見えません。協調→状態機械のモデリングは難しいですし、仮にモデルをきちんと作ったとしても、モデルと実装の乖離が大きいため、実装が進むにつれモデルが朽ちていきそうです。

理論的には正しくても、便利でないものは使われないので、もう少し実装に近いモデルで再検討してみます。

EDA

クラウド・アプリケーションのアプリケーション・アーキテクチャでは、EDA(Event Driven Arachitecture)やEIP(Enterprise Integration Patterns)といったSOA、エンタープライズ系のアーキテクチャの技術が有効ではないかと考えています。

そこで、OOAD的な(協調→)状態機械→アクションではなくて、EDA上での実現を考えてみました。

イベント→データフローの流れ

スライド「イベント→データフローの流れ」の改良案です。

OOAD的には、イベント発生が状態機械に状態遷移を発生させ、状態機械のアクションによってプログラムの処理がキックされるというモデルになりますが、「状態機械→アクション」の部分をEDAに取り替えてみたのが以下の図です。


図に登場するEDAの構成要素は以下の通りです。

イベント
システム内で発生する事象
イベントプロデューサ
イベントを生成するエージェント
イベントチャネル
イベントプロデューサとイベントコンシュマーを結び付けるチャネル
イベント処理エージェント
イベントのルーティングを行うエージェント
イベントコンシュマー
イベントを受信するエージェント

イベントプロデューサがイベントを発生させると、イベントチャネルからイベント処理エージェントを経由してイベントコンシュマーにイベントが通知されます。

イベントコンシュマーは、元のOOADの図におけるアクションに対応します。ここで、イベントに対するアプリケーション・ロジックを記述します。

イベントコンシュマーの実装では、データフローと関数型でアプリケーション・ロジックの中核部分を記述し(データフローの実装技術)、イベントコンシュマー本体でエンティティの更新を行うという役割分担(オブジェクトと関数の連携(2))を採ることになります。

EDAの構成を採ることで、イベント発生とアプリケーション・ロジックを疎結合にし、アプリケーション・ロジックの追加や拡張を容易にします。複数のユースケース・コンテキストがドメイン・モデル上に重なってくるようなアプリケーションでは、ユースケース・コンテキスト(あるいはユースケース)毎にイベント・コンシュマーを用意することで、システムのモジュール化を促進します。

また、イベントチャネルを介在させることで、MOMやESBを使用した非同期処理での実装も可能になります。

実装

論理モデルとして、この構成でモデリングしておいても、設計/実装の段階ではイベントプロデューサからイベントコンシュマーを直接同期型で呼んでしまうという実現方法を選択することも可能です。

実装時のイメージとしては、右のようなものを想定しています。基本的な処理はイベントチャネルを介さず、同期型でイベントコンシュマーにイベントを通知し、処理結果を持ち帰ります。一方、それ以外の処理はイベントチャネル経由で非同期にイベントコンシュマーにイベントを通知して処理を行います。

ユースケースと関数

スライド「ユースケースと関数」の改良案です。

OOAD的な視点では、ユースケースから関数までの流れが重要になります。

ユースケースは自然言語で記述した物語ですが、システム開発につなげるためには、もう少しシステムよりのモデルを用意してユースケースから使用するような形に持ってくる必要があります。ここでは、タスクとサービスというモデル要素を用意しました。

タスクは、ユースケース・フローにおけるシステムの使用方法を定義したものです。システムが提供するサービスの使い方(パラメタなど)を定めます。

サービスはイベントプロデューサを呼出して(サービス自身がイベントプロデューサも可)、EDAのメカニズムの上で処理を進めます。ここから先は前節で説明した流れで処理が進んでいきます。(イベント処理エージェントは宣言的な定義で記述する事が多いと思われるので図ではOOPから外していますが、OOPやFPあるいはDSLによる実現が可能です。)

DSLによるモデル記述と実装への展開

EDA上でオブジェクト・モデルと関数型を連携させていく方法についてやや実装よりに細かく考えてきました。

このあたりは、g3フレームワークやSimpleModelerで試行錯誤しながら色々と検討してきた点なのですが、ここでいっているような形では状態機械にはこだわらず、まずEDAベースでモデリングとフレームワークを構築するのがよさそうというのが最近の考えです。そのようなこともあり、今回ちょっと腰を据えて考えてみました。

今回考えたモデルをベースに、SimpleModelerとg3フレームワークでどのようにDSL化(モデルDSLとフレームワークDSL)していくのかというのが次の課題です。

諸元

当日使用したスライドは以下のものです。(PDF出力ツールの関係で、当日は非表示にしたスライドも表示されています)

このスライド作成の様子は以下の記事になります。

回顧は以下の記事になります。

投稿者 時刻:
ラベル: , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)