2012年5月29日火曜日

Object-Functional Analysis and Designふたたび

5月28日(月)にJJUG CCC 2012 Springで、『Object-Functional Analysis and Design』のセッションを行いました。予定していたセッションがキャンセルになったので、その代わりにお話させていただいた次第です。

スライド: http://www.slideshare.net/asami224/ofad

内容は基本的に3月19日(月)に要求開発アライアンスで行なった『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』の再演です。3月19日版のまとめは「Object-Functional Analysis and Designまとめのまとめ」になります。

要求開発アライアンスとJJUGではオーディエンスが違うので、事実上新規内容に近い形で見ていただけるのではないかということで、このテーマを選択しました。

前回の経験とオーディエンスの違いを勘案して再構成したのに加えて、いくつか内容の修正を行いました。ここでは、その点について記録しておきます。

再構成

要求開発アライアンスの参加者はモデリングが興味の中心と思われるので、OFADという趣旨からもモデリングの所を厚くしていましたが、今回はJavaプログラマが中心と想定されるので関数型言語のあたりを厚くしてみました。モデリングの所のスライドを減らしているのと、関数型言語のスライド数は増やしたわけではないですが、しゃべる時間を長めにしてみました。

とはいえ、JJUG CCCに参加するエンジニアはエンタープライズ系でモデリングにも興味を持っている方が多いと思われるのと、さらにこのセッションに参加される方はその傾向が大きいと思うので、モデリングに関してポイントとなるスライド(オブジェクトの世界と関数の世界, ユースケースと関数)(参考「オブジェクトの世界と関数の世界」)は残しています。さらに詳しくは「メタモデル」、「Domain-Driven Design (DDD)」あたりが面白いのですが、このあたりは省略しました。

クラウドまわりの応用でCQRSEDAと、OFADの関係もやりたかったのですが、これはセッション時間の兼ね合いで断念しました。DCI (Data Context Interaction)はトレイトや型クラスの素材という面で面白いのですが、アーキテクチャパターンとしてはちょっと採用しづらいというのが現時点の判断なので削除しました。

新しい現実

前回: 新しい現実

今回: 新しい現実

セッションの問題設定の文脈を提示したスライドを修正しました。前回は「クラウド・プラットフォーム」、「メニーコア」、「メモリDB」でしたが、今回は「クラウド・プラットフォーム」、「メニーコア」、「DSL」にしています。

前回のスライドを作っていた時は:

  • メモリDB→I/Oボトルネックが解消→アルゴリズム勝負←メニーコア

から、関数型へのニーズが高まるというような文脈を考えていたのですが、これよりもDSLの方がはるかに影響が大きいと思うので、今回はDSLにしてみました。

関数型言語の系譜

前回: 関数型言語の系譜

今回: 関数型言語の系譜

内容に変更はないですが、図の見方についての注釈を入れました。

ボク自身は、関数型言語は大昔にLispを触って以来20年ほど空白があるので、客観的な意味での関数型言語の発展史はまったく分かりません。この図はあくまでも、Javaプログラマが2008年に関数型言語に再遭遇した時の心象風景における関数型言語の見え方です。

セッションではその旨を口頭でお話しするわけですが、スライドでの流通もあるので注釈で補足しました。

ボクと同じ世代でLispや人工知能などをかじった後、エンタープライズ系の開発を主業にされている方は、恐らくその時点での関数型言語のイメージのフィルターを通して最近の関数型言語の興隆を理解しようとすると思うのですが、モナド、型クラスという新しい言語機能が入っている現代の関数型言語は、全く別物なのでそのあたりの注意を喚起したいというのが、このスライドの趣旨です。

関数型言語の正しい発展史はボクも興味があるので、URLや書籍をお知らせ頂けると助かります。

ユースケースと関数

前回: ユースケースと関数

今回: ユースケースと関数

ユースケースと関数の関係を定義するメタモデルを前回と今回で修正しました。修正点は以下のものです。

  • OOPから関数へのリンクの元を状態遷移からサービスにした。

EDAとオブジェクトと関数」で説明したように、EDAアーキテクチャをとりつつ状態遷移モデルは深く考えないのが、現実解ではないかというのが最近のボクの考えです。

この点を加味して、サービスから関数を直結し、状態遷移はサービスの専有下にしてみました。このアーキテクチャは、「オブジェクトと関数の連携(2)」にも沿っています。

このスライドの図を、EDAベースで実現すると「EDAとオブジェクトと関数」の最後の図になります。

CQRS/EDAとOFADを合わせてだいたいこんな感じが落としどころかなというのがボクの現時点での結論です。この図を使ってもよかったのですが、EDAの説明などが時間的に難しいので、モデリング段階の抽象的な枠組みのみにしました。

並列プログラミング

今回: 並列プログラミング

関数型言語というと並列プログラミングなので情報を追加しました。

基本的には:

  • shared mutability
  • isolated mutability
  • immutable

の三段階があって、一番下のimmutableが上策ということです。このimmutableを関数プログラミング方式で実現します。

さらにisolated mutabilityをアクター、shared mutabilityをSTMでハンドリングし、どうしてもダメな場合の最後の手段として伝統的な排他制御の技法(Javaのクラスライブラリが充実した機能セットを提供)用いるのが関数プログラミング流ということになります。

参考情報

要求開発アライアンス版に関する参考情報です。

スライド

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

まとめ

セッション後のまとめは以下の記事になります。

まとめのまとめ

最終のまとめは以下の記事になります。

0 件のコメント:

コメントを投稿