2012年3月21日水曜日

Object-Functional Analysis and Designまとめ

3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いました。要求開発アライアンスの皆さん、多数お集まりいただきどうもありがとうございました。

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

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

要求開発アライアンス向けのセッションなので、OOADとOFPの関係というテーマ設定を行って考えて来たわけですが、現段階の材料ではびしっと決まらない…ですね。

Scala DSLを用いてデータフローを記述し、HadoopやESB上で動作させる技術が登場してきており、この技術を軸にOOADと関数型を組み合わせていくというのが当面の現実解として有効と考えられるので、セッションではこれにフォーカスした内容にしました。

OOAD的には一番普通のアプローチである協調(collaboration)を状態遷移経由でデータフローに結び付ける方法を中心に考えましたが、できあがったものを見るとあまり便利には見えないので、もう一段ブレークスルーが必要と思います。協調をイベント＋データフローの集り+αで記述する方がエンタープライズ向けにはフィットしそうです。

プロセス計算

協調を記述する形式的な計算モデルの候補としてはプロセス計算が最右翼です。いわゆる形式手法のアプローチということになりますが、最終的にはこの方向とは思うもののエンタープライズ向けには現時点では研究段階というのがボクの認識なので、セッションではその点を軽く触れるにとどめました。

SOAの中核技術であるBPMN(のサブセット)が形式的だったと記憶しているのですが、Webを検索した感触だと、BPMNの説明で形式手法を全面に出している感じではなく、事実上はそういう使われ方はされていないのかなという印象です。

たとえば、InfoQでBPMを検索するとトップ記事が2010年の以下のものになります。

(サブセットが)形式手法であるというような記述も特に見られません。形式手法という観点では他の記事も大体似たような感じです。

BPMN&formalで検索すると以下のような記事(2008年)がヒットします。だいたい少し前の研究論文が頭に並んでくるのでSOA時代に一定の研究が進められていたのかな、という印象です。

データフローにフォーカスしたかったので、このあたりは省略したのですが、懇親会での材料投入にもなったと思われるので、入れておいたほうがよかったのかも、という気もします。

今考えてみると、BPMをSOAスケールで使うのではなく、局所的なデータフローの実現技術として使う方法もあるかもしれません。

関数型プログラミング

関数型プログラミングの最大の効用は、開発効率が高いことと思いますが、これだけだと実装技術として優れているということなので、OOAD的な開発手法との接点が出てきません。OOADで設計図を書いて、実装でScalaを使えば、という話になります。

そこで、セッションでは関数型プログラミングがシステム分析、設計に本質的に与える影響とは、という観点でまとめています。関数型プログラミングの最大の効用を省略しているので、念のためここに記しておきます。

そういう意味での、最大の効用は計算機科学、数学の成果物が、ちょっとした工夫でプログラミングの部品として活用できる道筋ができたことだと思います。直近では、並行プログラミングでそういった成果が活用できるようになるでしょう。

とはいえ、これは長期的スパンで漢方薬のようにじわじわ効いてくる効用なので、直近の実利としては説明しづらいのが難点です。

DSL

関数型言語の用途の一つにDSLがあります。関数型言語の自己拡張性というか言語を自然に拡張していける能力が内部DSLの実現に有効です。また、パーサコンビネーターといったメカニズムで外部DSLの実現も容易です。さらに、Scalaでは、さまざまな文法糖衣メカニズムによって、内部DSLの実現がより用意になっています。(こういった言語機能のScalabilityがScalaという名前の意図ですね。)

セッションでは、Spark、Scalding、Apache Camel Scala DSLの3つのデータフローDSLを紹介しました。それぞれHadoopやESBを利用するためのDSLとなっています。

モデリングとの接点で関数型言語によって実現されている実用技術を探すとこのあたりがアンテナに引っかかってきたわけです。

ここでは、モデリングとの接点なのでデータフローになりましたが、丸山先生の「エンタープライズ・クラウドの現在」で取り上げられていたPlay 2.0を始めScala DSLにはこの他にも様々な応用例が出てきています。

アプリケーションを構成する要素技術、ドメインごとにモデルをDSLで記述し、DSLの成果物を組合わせてアプリケーションを構築する...。以下の図はRelaxerの時代から使っているものですが、結局はこれかなという結論です。

この図を書いた当時はコンポーネントを生成して、これをスクリプトで結び付けるというアプローチを考えていたのですが、コンポーネント結合のDSLを使う手法が有力だと分かってきたことと、DI、AOPに加えてトレイト、型クラスといった新しい言語機能が加わってきたこともあって、実用化のハードルが低くなってきたと思います。

OFADより、DSL駆動というアプローチのほうが、当面の技術革新の方向にあっていると改めて感じました。

今後の方向性

懇親会で、萩原さんに最新の(クラウドスケールの)データベースの技術動向のお話を伺って非常に参考になりました。

一日寝かせて今朝思いついたのが以下のようなアイデア。(twitterより採録)

  • クラウドスケールの次世代DBの技術革新が、アプリ側に影響を与える一つはキー設計のところかな。GAEやAzureで議論になったキー設計はクラウド的に本質的。データフローを考えると、タプルの任意の冪集合をその段のキーとして使うようになるので、そのあたりも含めて。
  • SQLだと演算子が事前に決まっているけど、データフローは演算子を任意に追加できる。データフローを流れるデータと演算子の組について結合、可換をアプリレベルでどう記述していくのか、データベースやデータフローエンジンにどう情報を渡していくのかも論点。
  • ドメインモデル作成時に必要なこと(1)キー設計。ユースケースでドメインモデルのアクセスパターンを絞り込み、データ操作の局所性を抽出。同じ演算が適用されるデータが同じノード上に配置されやすいキーまたは複合インデックスを設計に織り込んでいく
  • ドメインモデル作成時に必要なこと(2)演算子設計。ドメインモデルでエンティティに加えて、データーフローに必要な代数的データ型(←エンティティをマップした物＋中間データ)と演算子を定義。このために、ユースケースでデーターフローと演算子の抽出を行う。
  • エンティティに対する代数的データ型＋演算子の組は、エンティティ操作に基本的に必要なものはドメイン・モデル、応用に特化したものはアプリケーション・モデル側で定義しておいて、後者はDCI的なメカニズムで後付けて編み込めるようにしておく。実装時には型クラスを使う感じ。

モデリングという方向では、ドメイン・モデル、ユースケース・モデル段階でこういった切り口でのモデリングを行うことが有効そうです。このあたりを今後の課題として考えていきたいと思っています。

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

0 件のコメント:

コメントを投稿

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