2010年9月27日月曜日

インストール

g3バージョン0.1は以下の場所で公開している。


配布物は以下の2つ。いずれかをインストールする。

  • g3-0.1-bin.zip:配布バイナリ。unzipして使用。
  • g3-0.1-jar-with-dependencies.jar:java -jar g3-0.1-jar-with-dependencies.jarで直接使用。

g3-0.1-bin.zip

g3-0.1-bin.zipは、ファイル一式をzipで固めたもの。jarコマンドで解凍して、g3-0.1/bin/g3を実行可能にすればインストールは完了。

$ jar xvf g3-0.1-bin.zip

パスを通した後、以下のように実行できればOK。

$ g3-0.1/bin/g3
Copyright(c) 2010 ASAMI, Tomoharu. All rights reserved.
g3 Version 0.1 (20100926)

Usage: g3 [-options] [args...]
  for more information, use -help option

今の所、ドキュメントやサンプルプログラムが整備されていないけど、いずれかのバージョンで同梱されることになる予定。

g3-0.1-jar-with-dependencies.jar

g3-0.1-jar-with-dependencies.jarは、関連するライブラリもすべてリンクした実行可能jar形式。以下のように実行できればOK。

$ java -jar g3-0.1-jar-with-dependencies.jar 
Copyright(c) 2010 ASAMI, Tomoharu. All rights reserved.
g3 Version 0.1 (20100926)

Usage: g3 [-options] [args...]
  for more information, use -help option

簡単に試したい時や、ドキュメントやサンプルプログラムが不要の時はこちらが便利。

2010年9月26日日曜日

g3フレームワークをリリース

メッセージング・フレームワークg3のバージョン0.1を公開した。


  • g3-0.1-bin.zip:配布バイナリ。unzipして使用。
  • g3-0.1-jar-with-dependencies.jar:java -jar g3-0.1-jar-with-dependencies.jarで直接使用。

今の所、ファーストインプレッション的なレベルでドキュメントもないのだけど、色々とアイデアがあるので随時機能拡張していく予定である。ドキュメントはこのBlogで書きためていく。まずは、具体的な使い方、Hello Worldといったものが必要だけど、これは、また明日。

背景

2008年後半からScalaを導入し、フレームワークGoldenportとモデルコンパイラSimpleModelerを作ってきた。GoldenportはSimpleModelerとg3の土台として使用している。

Google AppEngineを素材にして、SimpleModelerによるクラウドアプリケーションの生成を試みていたのだけれど、Google AppEngine(のようなPaaS)は汎用性が高いことの裏返しで仮想機械としての抽象度が低いため、プログラムの直接の生成対象としては、あまり適していないことが分かった。このギャップを埋めるためには何らかのフレームワークの導入が必要である。

このフレームワークに関して、メッセージフローというアイデアを軸にScala DSLを活用した面白い実現方法を思いついたのが昨年の秋。今年に入ってから、少しずつ実装を進め、夏休みに集中的にプログラミングしてなんとか公開レベルまで到達することができた。これが今回公開したg3フレームワークである。

クラウド上で動作するアプリケーションでは、大規模データ・大規模計算の活用に加え、故障・遅延への対応が必須となるため、イベント、メッセージングといった技術を軸にしてアプリケーション・アーキテクチャが大転換することになるだろう。

この分野ではデータフロー、EDA(Event Driven Architecture)、リアクティブシステム、CEP(Complex Event Processing)、Streaming Programming Model、MOM(Message Oriented Middleware)、ESB(Enterprise Service Bus)といった概念や製品を思い浮かべることができる。

この流れの中に、メッセージフローがあるわけだけれど、それぞれの用語とどのような位置関係になるのか、ボク自身もまだ整理しきれていない。本で読むのと、自分でプログダクトを作って手を動かすのでは理解の深さが異なってくる。g3の実装をすすめることによって、これらの技術分野の中でのメッセージフローやg3フレームワークの立ち位置が徐々に明らかになると思われるので、楽しみにしている。

サンプル

g3フレームワークでは、Scala DSLで、プログラムを記述する。現時点で動作する機能のデモ的なサンプルとして以下のものが参考になると思う。

  • AtomDb.scala: TwitterからAtomフィードを受信してRDBMS(Derby)に格納するWebアプリケーション。
  • ReadingLog.scala:読書ログの格納と参照をRDBMS(Derby)に対して行うWebアプリケーション。

この2つのサンプルプログラムについてはブログで追々解説していく。

AtomDb.scala
class AtomDb extends G3Application with UseRecord {
  val kind = 'feed
  val schema = Schema(AutoIdField,
                      'twitterid,
                      'title,
                      ('date, XDate),
                      ('content, XString))
  val url = "http://twitter.com/statuses/public_timeline.atom"

  datastore('db, uri="jdbc:derby:target/g3/derbyDB;create=true",
            driver="org.apache.derby.jdbc.EmbeddedDriver",
            username="user1", password="user1")
  service('feed, url)

  html('viewtop, "Atom to Database") {
<body>
<h1>Atom to Database</h1>

<ul>
  <li><a href="/init">Initialize Database</a></li>
  <li><a href="/list">List Feeds</a></li>
  <li><a href="/update">Collect Feeds</a></li>
</ul>

</body>
  }

  channel('viewinitrun) invoke("init") agent {
    case _ => Html("Initialize Result", 
<body>
<h1>Initialize Result</h1>

Success!

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>
    )
  }

  channel('viewlist) invoke("list") agent {
    case rs: RecordSet => Html("Feed List",
<body>
<h1>Feed List</h1>

<g.list/>

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>, schema
    ) += rs
  }

  channel('viewupdaterun) invoke("update") agent {
    case _ => Html("Collect done",
<body>
<h1>Entry</h1>

Atom feeds are updated.

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>, schema
    )
  }

  agents('init)(MsgSeq(Drop(kind), Create(kind, schema))) invoke("db")

  agents('list)(Query(RecordQuery(AllFieldSlot(kind)))) invoke("db")

  channel('update) invoke("feed") agent {
    case AtomFeed(feed) => {
      Post(kind,
           feed.toRecordSet(entry => {
             Record('twitterid -> entry.id,
                    'title -> entry.title,
                    'date -> entry.updated,
                    'content -> entry.contentText)
           }))
    }
  } invoke("db")

  port("/") invoke("viewtop")
  port("/init") invoke("viewinitrun")
  port("/list") invoke("viewlist")
  port("/update") invoke("viewupdaterun")
  port("/service/init") invoke("init")
  port("/service/list") invoke("list")
  port("/service/update") invoke("update")
}
ReadingLog.scala
class ReadingLog extends G3Application with UseRecord {
  val kind = 'book
  val schema = Schema(IdField,
                      'name,
                      ('date, XDate),
                      ('comment, XString))

  datastore('db, uri="jdbc:derby:target/g3/derbyDB;create=true",
            driver="org.apache.derby.jdbc.EmbeddedDriver",
            username="user1", password="user1")

  html('viewtop, "Reading Log") {
<body>
<h1>Reading Log Menu</h1>

<ul>
  <li><a href="/init">Initialize Reading Log</a></li>
  <li><a href="/list">List Readling Log</a></li>
  <li><a href="/entry">Write Readling Log</a></li>
</ul>

</body>
  }

  html('viewinit, "Initialize") {
<body>
<h1>Initialize Reading Log</h1>

<ul>
  <li><a href="/init/run">OK?</a></li>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>
  }

  channel('viewinitrun) invoke("init") agent {
    case _ => Html("Initialize Result", 
<body>
<h1>Initialize Result</h1>

Success!

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>
    )
  }

  channel('viewlist) invoke("list") agent {
    case rs: RecordSet => Html("Reading List",
<body>
<h1>Reading List</h1>

<g.list/>

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>, schema
    ) += rs
  }

  html('viewentry, "Entry", schema = schema) {
<body>
<h1>Entry</h1>

Please enter book information.

<g.input action="/entry/confirm" label="SUBMIT"/>

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>
  }

  html('viewentryconfirm, "Confirm Entry", schema = schema) {
<body>
<h1>Confirm Entry</h1>

Are you ok?

<g.confirm action="/entry/run" label="SUBMIT"/>

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>
  }

  channel('viewentryrun) invoke("entry") agent {
    case _ => Html("Entry done",
<body>
<h1>Entry</h1>

Reading log is written.

<g.detail/>

<ul>
  <li><a href="/">Return Menu</a></li>
</ul>

</body>, schema
    )
  }

  agents('init)(MsgSeq(Drop(kind), Create(kind, schema))) invoke("db")

  agents('list)(Query(RecordQuery(AllFieldSlot(kind)))) invoke("db")

  agentc('entry) {ctx: G3AgentContext => {
    case post: Post => post.transform(kind, schema, ctx.context)
  }} invoke("db")

  port("/") invoke("viewtop")
  port("/init") invoke("viewinit")
  port("/init/run") invoke("viewinitrun")
  port("/list") invoke("viewlist")
  port("/entry") invoke("viewentry")
  port("/entry/confirm") invoke("viewentryconfirm")
  port("/entry/run") invoke("viewentryrun")
  port("/service/init") invoke("init")
  port("/service/list") invoke("list")
  port("/service/entry") invoke("entry")
}

2010年8月31日火曜日

現在の活動

8月も今日で終わり。今年も2/3に、今年度も半分に近づきつつあり、おおむね半分が過ぎたというところで活動の内容をまとめておくことにした。
現在行っている活動は大きくまとめると以下の3つである。

  • SimpleModeling - クラウドアプリケーション向けのメタモデル
  • SimpleModeler - SimpleModeling用のScala DSLモデルコンパイラ
  • g3フレームワーク - メッセージフローフレームワーク



元々SimpleModelingは、wakhok時代に教育用に整備したオブジェクトモデリング手法で、『上流工程UMLモデリング』や『マインドマップではじめるモデリング講座』という形で本にまとめることができた。従来型のオブジェクトモデリングをベースにwakhokで得られた知見などをもとに拡張している。

SimpleModelingのもう一つの大きな目的はモデル駆動開発で使用できるオブジェクトモデルのプロファイルである。DSLで記述することができ、かつプログラムに落としこむことができることを念頭にメタモデルを定めている。

このSimpleModeling用のモデルコンパイラとして開発したのがSimpleModelerである。
SimpleModelerはScalaをDSLのホスト言語として使用しており、SimpleModeler自身もScalaで開発している。
SimpleModelerでは、Scala DSLから仕様書とプログラムを生成する。仕様書はクラス図や状態機械図、状態遷移表を埋め込んだHTMLを生成することができる。

SimpleModelingとSimpleModelerが一通り目処がついたところで、クラウドがそろそろ来そうという感触を得たのが一昨年の秋。SimpleModelerでGoogle App Engine/Python用のコード生成が動き始めた頃、Google App Engine/Javaが公開された。
それ以降はGoogle App Engine/Java向けのコード生成を中心にSimpleModelerの開発を進めている。

Google App Engineを一通り経験した後、SimpleModelingをクラウド向けに拡張する本格的に開始したのが昨年の夏、秋。11月にはMicrosoftのPDCに参加させてもらってAzureの技術に刺激を受けた。

クラウド向けの拡張項目についてはいずれブログでも説明する予定だけど、今の所(1)ドメインモデルの拡張(2)メッセージフローの導入の2点。

アプリケーションの振舞いモデルを主にメッセージフローで記述してみようというアプローチなんだけど、このアプローチを取るためには現在利用できるクラウド・プラットフォームとは距離がありすぎる。

そこで、この距離を埋めるために開発を始めたのがメッセージフローフレームワークであるg3フレームワークである。g3フレームワークの開発は今年に入ってから。
g3フレームワークはScala DSLで記述したメッセージフローを実行する。

最近は、このg3フレームワーク上でメッセージフローモデルとドメインモデルを連携させるための仕組みづくりの開発を行っている。

以上の3つの活動はそれぞれ面白い論点があるので、ブログで順にまとめていきたいと思っている。

2010年7月12日月曜日

マインドマップ・モデリング

先週の木金に函館で久々にマインドマップ・モデリングの講習を行った。

組み込みエンジニアなど実装周りを担当されているエンジニアの再教育事業でのモデリング教育。
UMLの文法を講義して終わり、ということにはしたくなかったので、wakhok時代に開発したモデリング教育の技法であるマインドマップ・モデリングを行うことにした。


一日目にマインドマップ・モデリングの文法や簡単な演習を行った後、二日目に実際の雑誌記事を用いて演習を行った。この二日目の演習が本番である。日本語の文章とモデルのマッピングの勘所をつかんでもらうという狙いがある。

今回は旬の話題ということで週刊 東洋経済 2010年 7/3号の特集『激烈!メディア覇権戦争』から『電子書籍は「本」を救うのか』をテーマに選んでみた。

以下はボクがサンプルで作ってみたマインドマップ・モデル。
モデル作成の過程を三段階で示している。

まず最初に記事中から単語を抜き出してマインドマップ・モデリングが定義しているBOIの下に配置する。
それぞれの枝は通常のマインドマップの技法を用いて自由に情報を整理する。


次の段階ではマインドマップ・モデリングの文法に従って用語の整理を行う。
用語の名寄せ・統合と用語間の関係を整理して、基本的な構造を抽出するのが目的である。


そして、以下が最終型。時間の関係があって完成というところまではいけなかったけど、大体の構造まで持ってくることができた。
全段階で得られた基本構造をベースにして、モデルのリファインを行う。
ここで重要なのが物語(ユースケース=利用事例)と出来事(イベント)によって記事の意図をモデルに注入する点である。
物語と出来事によって、モデルに動的な側面が加わる。そして、モデルを動作させるのに必要な静的構造の文脈が確定する。


こういったモデリングをUMLでももちろん行うことができるけど、仕掛けが大掛かりになりすぎて、演習という限られた時間では実現が困難というのが経験則。
この問題を解決するために開発した技法がマインドマップ・モデリングというわけである。

マインドマップ・モデリングのモデルは一般的なOOをベースにしている(正確にはボクが開発したSimpleModelingというプロファイルをメタモデルにしている)ので、このまま半機械的にクラス図やユースケース図に変換することが可能である。

今回もUMLによるモデリングはほとんど経験のないという受講者の方が多数おられたが、適切なマインドマップ・モデルを作成されていた。
いずれUMLを使うようになり、UMLによるモデリングを行う必要が出てくれば、今回の講習の成果を活かしていただけると思う。

久々にマインドマップ・モデリングをやってみてモデリングは楽しいなぁ、と再認識。
プログラミングと直結する設計モデルの作成はどちらかというと無駄な作業だと思うけど(Scalaを使って直接コーディングするかDSL化するのがよい)、ふわふわとした状況を具体的な形にしていく概念モデリングという作業はクラウド時代になっても引き続き重要な技術であり続けるだろう。

現在は新しく登場したプラットフォームであるクラウドの基盤技術に業界の関心が集中しているけど、いずれモデリングの方にも関心が移ってくることになるはずである。
そういったことも意識しつつ、今はマインドマップ・モデリングをどのように改修すればクラウドに対応できるのかといったことを切り口にしてクラウド時代のモデリングについてつらつらと考えている。

2010年6月24日木曜日

ボクらのScala

明日6月25日に拙著のScala入門書『ボクらのScala』が出版されます。


副題は「次世代Java徹底入門」となっています。
題と副題は編集のYさんがつけたものですが、なかなかよい感触です。
少し冒険的な副題ですが、二年ほどScalaをいろいろと触ってみてのボクの実感とも一致しています。
内容をみてYさんもそのように感じられたのだと思います。

Scalaは色々な言語のよいところを絶妙のバランスで配合しており、プログラミング効率も高く、高い実用性を備えています。その上で、DSL、マルチコア、クラウドといったこれからの応用を実現するために必要な機能が整備されているのが美点です。
今すぐ便利であるのはもちろん、これからの10年を乗り切るための基盤ともなる言語といえるでしょう。

ただ、言語仕様やライブラリの使い方を一度にすべて把握しようとすると初学者には敷居が高いので、普通のプログラミングをする上で普通に必要な言語仕様やライブラリを、学習段階に合わせて説明していくというアプローチを取りました。

400ページに収めるために、大幅に原稿を削りました。
原稿を書く側からすると辛いところですが、逆に読者の側からは内容がコンパクトになって読みやすくなったのではないかと思います。
割愛した原稿は、このブログで随時アップしていこうと思っています。

2010年5月4日火曜日

Scala DSL

クラウド時代に向けて:

  1. SimpleModel:オブジェクト・メタモデル。クラウド・アプリケーション向けの拡張中。
  2. SimpleModeler:SimpleModelのモデルコンパイラ。
  3. g3:メッセージフロー・フレームワーク。

の開発を行っているわけだけれど、これらの技術のキーテクノロジとなるのがDSL(Domain Specific Language)である。

SimpleModelはメタモデルだけれど、Scala DSLで簡潔に記述できることが要件の一つになっている。そして、SimpleModelのモデルコンパイラがSimpleModeler。SimpleModelerはSimpleModelを記述したScala DSLの集まりをソフトウェアリポジトリとして使用する。

またg3は、Scala DSLで記述したメッセージフロー・モデルに基づいて動作する。

このように、このところはScala DSLを中心に活動しているのだけれど、ここにいたるまで色々と紆余曲折があった。

1998年に登場したXMLがJavaと分散環境のミッシングリンクを埋めるキーテクノロジーであると感じ、Java&XMLを中心に活動していた時期がある。

分散環境では、分散ノード間でのオブジェクトの共有や移送は理論的には不可能ではないにしても相当ハードルが高く、当面は実運用的には不可能と考えてよい、というのが分散OSや分散オブジェクトの教訓。

このため、分散アプリケーションが取るべき現実解は、異機種間での疎結合のサービスを構造化された値の送受信で連携させるということになるのではないか。そしてこの「異機種間で送受信する構造化された値」を記述する技術が当時のJavaには欠けており、ここにXMLはすっぽりとはまるのではないか。

そういったブレークスルーの予感もあって、XMLアプリケーションであるSmartDoc(1998)とRelaxer(2000)を開発したのだけれど、これらのアプリケーションを通して、いわゆる「one source multi use」の有効性を体感することができた。

当時はまだ、DSL(Domain Specific Language)という用語はなかったか、あるいは一般的ではなかったのだけれど、用途ごとの専用言語をXML上に構築して「one source multi use」の運用を行うこと、つまり今の言い方ではDSLが今後の技術の主流になると思えた。

ただ、XMLをDSLのホスト言語として使用することを試行錯誤する中で、XMLは文書をマークアップするにはとても良いのだけれど、定義ファイルやプログラムといった用途に使用するのには向いていないことが分かってきた。

そこで、プログラミング言語をホスト言語にすることを考えたのが次の段階。最初に候補となったのはGroovy。これは2004年頃。Javaベースであり、メタな操作も可能なのでDSLのホスト言語としてうってつけであると思ったわけである。

しかし、いくつか問題があってGroovyを採用するのは断念した。

当時のGroovyは、非常に遅かったのが一点。ただ、こういった問題は時間が解決するので、DSLの用途ではそれほど大きな問題ではない。

木構造を扱う抽象構文的な拡張の柔軟性が低い、という問題もあった。これは、他に良いところがあれば我慢できる範囲。(なにぶん古い話なので今は違った状況になっていると思う。)

しかし、これは大きな問題だと思ったのは、動的言語であるためにDSLの構文にコンパイラ相当のエラーチェックをかけることができない、ということ。これはDSLを使ってモデルを作成していく際の効率を著しく低下させる。

たとえば、フレームワークの設定ファイルに識別子のミススペルがあることが原因で、フレームワークが意味不明のエラーで落ちる、というような事が起きる。

DSL処理系の開発も難しくなる。DSL処理系をクイックハックで作る分には楽でよいのだけれど、本格的なものにしようとするとコンパイラ相当のエラーチェックを自分で実装しなければならなくなる。

そんな中で、アノテーション技術が登場したこともあり、JavaをDSLのホスト言語とすることに決めて開発を進めていた。

しかし、JavaをDSLのホスト言語として使用した場合、メタな情報はjava.lang.reflectionとアノテーションで部分的に取り出すことができるだけなので用途が限られるという問題がある。Javaの文法を構文木として取得するのが非常に難しい。EclipseのASTを使うという案もあったのだけれど、Eclipseに依存してしまうので断念した。

以上のようなこともあり、Javaでは木構造のデータ構造を簡潔に記述するための文法を定義するのが難しい。Javaで書いたロジックをそのまま取り出すことも難しい。

もちろん、GWTのような荒業もあるけれど、これはハードルが高すぎて一般的な技術には成り得ない。

また、Javaではテキスト情報をDSLの一部として記述するのが一苦労。コメントに記述したものを、自作パーサで読み込むといったようなことをやったりしていた。

そして最後に行きついたのがScalaということになる。これが、2008年の7月。

Scalaは、高階関数と字句上の様々なトリックを併用することで、簡潔で強力なDSLを簡単に構築することができる。また、生文字リテラルやXMLリテラルがあるのでテキスト情報の記述も簡単。ケースクラスや抽出子によるリテラル追加機能もよい。しかも、型推論のついた静的型付け言語。

まさに、DSLのために生まれてきた言語である。

たとえば、以前にご紹介したg3フレームワークが使用する以下のScala DSL。Enterprise Integration PatternsのSplitパターンとAggregateパターンを使用したメッセージフローを記述している。これをXMLやJavaで記述しようとすると、大変な事になりそうだ。実装もややこしくなる。

Split.scala
class Split extends G3Application {
  start(List(1, 2, 3, 4, 5)) split() agent {
    case x: Int => x + 100
  } aggregate()
}

しかし、Scalaだととてもすんなりいくのである。実装も、簡単というわけではないけれど、XMLやJavaをDSLにした時のことを考えるとはるかに容易になる。

いずれにしても、こういったDSLの構築技術が、クラウドに限らずこれからのソフトウェア開発のキーテクノロジーになると思っている。よほどの本格的な用途でない限り、ホスト言語の上に構築する内部DSLを使うことになるので、内部DSLが最重要技術ということである。

内部DSLのホスト言語としては、現在のところRuby、Groovy、Scalaが有力だと思われるけれど、やっぱりDSLは静的型付けがよいかな、ということでボクの選択はScalaということになる。もちろん、これは各自の好みで決めてよいところ。DSL処理系の開発効率も重要なので、プログラミングに慣れている言語を選択するのがよいでしょう。

Scala DSLアプリケーションであるSimpleModelerやg3の開発を通して、二年近くScala DSLプログラミングしてきて、多少ノウハウも蓄積されてきた。そのようなこともあり、Scala DSLに関するノウハウを5月18日に行われるJJUG CCCで『Scala DSLの作り方』というセッションで発表させていただけることになった。

興味のある方はぜひどうぞ。

2010年5月3日月曜日

クラウド・モデリング

5月14日に行われる『Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会』という座談会に参加させていただくことになった。

よい機会なので、クラウドをターゲットにして取り組んできたモデリング手法、ツール、フレームワークなどをつらつらと整理しているところ。

オブジェクト指向モデリングは、本来、振舞いモデルを記述する能力が高い所が特徴であり強みでもあるはずだけれど、今のところ有効活用されているとは言い難い。

伝統的な基幹システムも、新興のWebシステムも基本的には画面とデータベース間の転記が基本アプリケーション・アーキテクチャとなっていることが多く、この場合には従来型のデータモデリングで十分だったということかもしれない。

三段(3 tier)構成のシステムアーキテクチャといった設計レベルでのモデリングもあるけれど、アーキテクチャレベルの鳥瞰図があれば、あとは直接プログラミングした方が話が早い。

しかし、クラウドでは故障、遅延、規模といった問題が従前より重要な課題となって浮上するため、今までのようにはいかなくなるだろう。

故障、遅延、規模の問題をデータベースシステムを中心としたミドルウェア層で吸収することはもはやできなくなるわけで、性能と一貫性のバランスを取るために、アプリケーションの用途に応じて、アプリケーション側で調整を行う必要が出てくる。いずれこういった問題を吸収するクラウド・ミドルウェアが出てくることになるとは思うけど、これは10年スパンで考えていくことである。

利用者側への見せ方、エクスペリエンスにも影響が出てくる。たとえば、今までだったらフォームの完了ボタンが完了したらデータベースには確実に書かれているはずだったけど、クラウドでは後で書いときます、という約束が行われるだけとなることが多くなる。そうなると、利用者側のアクションとして、書かれたことの確認や、実は書き損なっていたのでリカバリを利用者自身にお願いするというようなユースケースが普通に出てくる。

こういった問題を取り扱うには並列、分散、非同期といった要因を上位のモデリング段階で扱わなくてはならなくなるはず。そのモデリングのためのメカニズムとしてオブジェクト指向が再評価されることになるだろう、というのが最初のアイデア。そして、システム構築という観点から見るとMQ的なキューを中心としたシステムアーキテクチャ、アプリケーションアーキテクチャになるだろう、というのが二つ目のアイデア。

当時考えていたこれらのアイデアを昨年の1月にクラウド研究会でお話をさせていただいた流れから、UNIXマガジン誌に寄稿した記事を『クラウドの技術』の一編として再録していただいた。

この2つのアイデアを、従来から考えているモデリング手法に取り込む方針で作業を進めている。

従来システムに対するオブジェクト指向のモデリング手法はSimpleModeling、MindmapModelingという形でまとめ、一昨年の夏に出版させていただいた。

SimpleModelingとMindmapModelingは、内部的には共通のメタモデルSimpleModelを使用しており、相互運用可能である。MindmapModelingでラフなドメインモデルやユースケースモデルを抽出し、SimpleModelingで本格的なモデリングに入っていくという流れを想定している。

SimpleModelでは、イベントを軸に静的モデルと動的モデルを相互連携させる点がポイントとなっている。SVOがモデリングの基本になる。Vがイベント。イベントがアクター(S)とResource(O)の状態遷移を束ねる。ユースケースも物語をイベントの列として記述することで、静的モデルと動的モデルの両方にシームレスに連結できる。

クラウド・アプリケーションの場合でも、この枠組は引き続き有効ではないか、というのが今のところの考え。とはいえ、静的モデル、動的モデルの双方に相応の拡張が必要になる。

静的モデルでは、いわゆるBASEトランザクションに対応したデータモデリングが必要になってくる。ここでSVOの枠組みを自然に拡張していくことで対応できるのではないか、と考えている。具体的には、関連の各種プロパティの解釈の精度を上げることと、イベント・エンティティにBASE向けの属性を取り入れるといったことである。

動的モデルでは、新しくメッセージ・フローという概念の導入がミッシングリンクを埋める鍵になるのではないかと考えている。オブジェクト指向に限らず、コントロール・フローやデーター・フローをモデル化する図は色々と用意されているのだけれど、コントロール・フローとデータ・フローを包含して記述するための図というのが案外ない。しかし、クラウド・アプリケーションのモデリングでは、コントロール・フローとデータ・フローを同じ文脈上で記述することが、有効なのではないか仮説を立てているところである。

この仮説に基づいて、メッセージフロー図の文法、メッセージフローのDSL、そしてメッセージフローの実行系としてのフレームワークを開発しているのが現在のステータス。メッセージフローのDSLとフレームワークが一段落したら、一昨年から昨年にかけて開発したScala DSLコンパイラSimpleModelerを、メッセージフロー対応する構想となっている。

先は長そうだけど、ぼちぼちやっていくつもり。