Modegramming Style

Scala Tips / Either (4) - getOrElse, flatMap

2012-02-16T08:00:00.000+09:00

Eitherから値を取り出すイディオムです。

Eitherから値を取り出す処理として以下の2つのコーディングパターンを挙げました。

Either[A, B]からEither[A, C]に変換
Eigher[A, B]からCに変換

前回は、後者のEither[A, B]からCへの変換について、基本的なイディオムを紹介しました。

条件	結果	演算
Either[A, B]がRight[A, B]	C	BからCを計算
Either[A, B]がLeft[A, B]	C	デフォルト値

今回は、Either[A, B]がLeft[A, B]の場合だけでなく、Right[A, B]の値が条件を満たさない場合も、デフォルト値を返すようにします。

条件	結果	演算
Either[A, B]がRight[A, B]で有効な値が入っている	C	BからCを計算
Either[A, B]がRight[A, B]で無効な値が入っている	C	デフォルト値
Either[A, B]がLeft[A, B]	C	デフォルト値

以下では、Either[Exception, Int]からStringへの変換を例に考えてみます。ただし、Intは0以上のものが有効という条件を追加します。Right[Int]に入っているIntが0以上の場合、Stringが処理結果となります。一方、0未満の場合は無効となり空文字列「""」が処理結果となります。またEither[A, B]がLeft[A, B]の場合も空文字列「""」が処理結果となります。

(分類の基準)

Java風

if式でEither#isRightを使って右側の値の有無を判定します。デフォルト値の「""」はelse句で指定します。isRightメソッドが一回、getメソッドが二回、泣き別れになってしまいます。

def f(a: Either[Exception, Int]): String = {
  if (a.isRight && a.right.get.toString >= 0) {
    a.right.get.toString
  } else ""
}

Scala風

match式を使うと以下のようになります。こちらの方が綺麗です。

def f(a: Either[Exception, Int]): String = {
  a match {
    case Right(b) if b >= 0 => b.toString
    case _ => ""
  }
}

Scala

EitherでMonadic演算をしたい場合にはright(またはleft)メソッドでRightProjection(またはLeftProjection)を取得し、これに対してmapメソッドやflatMapメソッドを適用します。EitherとRightProjection/LeftProjectionの組合せでモナド的な動作をします。

前回は計算文脈の切り替えは行わなかったのでmapメソッドを使いましたが、今回は計算文脈の切り替えを行うのでflatMapメソッドを使います。

以下ではEitherからrightメソッドでRightProjectionを取り出しflatMapメソッド内で、Right[Exception, Int]の値が0未満である場合はLeft(new IllegalArgumentException("bad"))を返すことで失敗の計算文脈に切り替える処理を行っています。

def f(a: Either[Exception, Int]): String = {
  a.right.flatMap { b =>
    if (b >= 0) Right(b.toString)
    else Left(new IllegalArgumentException("bad"))
  }.right getOrElse ""
}

Optionに変換

最終的に値を取り出す場合、左側に保持しているエラー情報は捨てることになります。この場合には、エラー情報(Exception)を最初の段階で捨ててしまい、エラーか否かという情報のみを伝搬しても得られる結果は同じです。

前述の例では、new IllegalArgumentException("bad")で生成したExceptionを次の処理ですぐに捨てています。もったいないですね。

以下ではRightProjectionのtoOptionメソッドでEitherをOptionに変換してしまいます。Optionに変換後、withFilterメソッド、mapメソッドとgetOrElseメソッドの合わせ技で値を取得しています。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.withFilter(_ >= 0).map(_.toString) getOrElse ""
}

Scalaz

ScalazではEitherが右側を成功文脈とする成功/失敗の計算文脈としても動作するので、Either#rightメソッドでRightProjectionを取得しなくてもEitherに対して直接flatMapメソッドを適用することができます。ただし、ScalazでもEither#getOrElseメソッドはないので、rightメソッドでRightProjectionを取得する必要があります。このためScala版と比べてそれほど違いは出てきません。

def f(a: Either[Exception, Int]): String = {
  a.flatMap { b =>
    if (b >= 0) b.toString.right
    else new IllegalArgumentException("bad").left
  }.right getOrElse ""
}

また、Booleanのeitherメソッドを使う方法もあります。

def f(a: Either[Exception, Int]): String = {
  a.flatMap { b =>
    !(b >= 0) either {
      new IllegalArgumentException("bad")
    } or b.toString
  }.right getOrElse ""
}

SclazではflatMapを「>>=」の記号で記述することができます。上の例はそれぞれ以下のようになります。

def f(a: Either[Exception, Int]): String = {
  (a >>= { b =>
    if (b >= 0) b.toString.right
    else new IllegalArgumentException("bad").left
  }).right getOrElse ""
}

def f(a: Either[Exception, Int]): String = {
  (a >>= { b =>
    !(b >= 0) either {
      new IllegalArgumentException("bad")
    } or b.toString
  }).right getOrElse ""
}

Optionに変換

ScalazでもEitherにtoOptionメソッドは追加されないのでrightメソッドで得られるRightProjectionのtoOptionメソッドを用いてOptionに変換します。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.withFilter(_ >= 0).map(_.toString) | ""
}

Scalazでは、Optionに対して色々な機能拡張を行っているので、Optionに変換すればいろいろな技を使うことが可能になります。ここでは「|」メソッドで値を取り出しています。

また、以下のようにデフォルト値がモノイドの単位元と同じ場合にはorZeroメソッドを使うこともできます。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.withFilter(_ >= 0).map(_.toString) orZero
}

ノート

前回のmapメソッドと同様に、flatMapメソッドを使う場合も、計算文脈をEitherからOptionに切り替えるテクニックが有力です。

Eitherを使う場合は、計算文脈を成功文脈から失敗文脈に切り替える時にflatMapメソッドを使うしか選択肢はありませんが、Optionにすることで、withFilterメソッドやcollectメソッドなども使えるようになります。

また、ScalazはOptionに対して色々な機能拡張をしているので、さらにプログラミングの選択肢が広がります。今回の例では「|」メソッドやorZeroメソッドで値を取り出しています。

Monadicプログラミングでは、計算文脈の中で文脈を切り替えていく(Eitherの中でLeftとRightを切り替え)のに加え、計算文脈毎、応用に適したものに切り替えていく(EitherをOptionに切り替え)のも重要なテクニックになります。

モナドで実現された階層化複合化された計算文脈を適材適所で切り替えながら処理を進めていくのがMonadicプログラミングの醍醐味と言えるかもしれません。

flatMapと「>>=」と「∗」

Scalazは型クラスをベースにしたMonadicプログラミングを指向したクラスライブラリですが、Scala言語本体にもモナドが実装されています。このため、モナドの基本操作の部分ではScala本体とScalazの機能がバッティングします。

ボク個人のプログラミング方針としては、Scala本体とScalazがバッティングしていて機能がほとんど変わらない場合はScala本体を選ぶようにしています。というのは、Scalazは余分なオブジェクトを相当数生成しながら動作するのでかなり重たいからです。

ただ、これは簡潔に記述できることとのトレードオフでもありますし、Scalazを選んだ以上多少のことは目をつぶって簡潔さに賭けるというのが潔く、現在のハードウェア性能では多くの場合許容範囲と考えられます。

さらに本記事のようなScalazイディオムという意味では、よりScalazらしい書き方を主にした方が趣旨に合います。

そういうこともあって、ボクの書き癖でflatMapを使ってきましたが、Scalazらしく機能がバッティングする場合も「>>=」といったScalaz側のメソッドを主にしていくことにしました。

また、flatMapは「∗」、mapは「∘」という記号(Unicode)で記述する方法もあり、flatMap、「>>=」、「∗」のどれを選ぶのか悩ましいところです。「∗」は「∘」と紛らわしいので、flatMap、「>>=」、「∗」の選択では「>>=」を使うことにします。(Haskellの流儀に則っていて、モナドや型クラス周りの知識のある人には読みやすいというのもあります。)

なお、Eitherに関していうと、Scala標準ではEitherにはflatMapメソッドはないので、Scalazを使っていることを明示する目的で「>>=」を使うという考え方もあります。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Either (3) - getOrElse

2012-02-15T08:00:00.000+09:00

Eitherから値を取り出すイディオムです。

EitherをOption的な成功/失敗文脈で使う方法について考えています。右側が成功文脈、左側が失敗文脈としています。

Eitherの場合も、Optionと同様に値を取り出す処理として以下の2つのコーディングパターンがあります。

Either[A, B]からEither[A, C]に変換
Eigher[A, B]からCに変換

ここまではEither[A, B]からEither[A, C]への変換についてみてきました。今回はEither[A, B]からCへの変換について考えます。

条件	結果	演算
Either[A, B]がRight[A, B]	C	BからCを計算
Either[A, B]がLeft[A, B]	C	デフォルト値

Either[A, B]がRight[A, B]の場合は、この値からCを計算しますが、Left[A, B]の場合はあらかじめ用意しているデフォルト値を返します。

以下では、Either[Exception, Int]からStringへの変換を例に考えてみます。Either[Exception, Int]がLeft[Exception]の場合はデフォルト値として空文字列「""」を返すことにします。

(分類の基準)

Java風

if式でEither#isRightを使って右側の値の有無を判定します。デフォルト値の「""」はelse句で指定します。isRightメソッドとgetメソッドが泣き別れになっているのがあまりよい感触ではありません。

def f(a: Either[Exception, Int]): String = {
  if (a.isRight) a.right.get.toString
  else ""
}

Scala風

match式を使うと以下のようになります。こちらの方が綺麗です。

def f(a: Either[Exception, Int]): String = {
  a match {
    case Right(b) => b.toString
    case Left(_) => ""
  }
}

Scala

以下ではEitherからrightメソッドでRightProjectionを取り出しmap適用、mapの結果のEitherからrightメソッドでRightProjectionを取り出しgetOrElseで値を取り出す、という形でEither→right→RightProjectionの連鎖で処理を進めています。

最後に、flatMapの結果のEitherからrightメソッドでRightProjectionを取り出しgetOrElseで値を取り出します。

def f(a: Either[Exception, Int]): String = {
  a.right.map(_.toString).right getOrElse ""
}

Optionに変換

そこで、最初の段階でRightProjectionのtoOptionメソッドでOptionに変換し、Optionに対してMonadic演算を行うようにします。

以下ではOptionに変換後、mapメソッドとgetOrElseメソッドの合わせ技で値を取得しています。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.map(_.toString) getOrElse ""
}

Scalaz

ScalazではEitherが右側を成功文脈とする成功/失敗の文脈としても動作するので、Either#rightメソッドでRightProjectionを取得しなくてもEitherに対して直接mapメソッドを適用することができます。ただし、ScalazでもEitherにgetOrElseメソッドはないので、rightメソッドでRightProjectionを取得する必要があります。このためScala版と比べてそれほど違いは出てきません。

def f(a: Either[Exception, Int]): String = {
  a.map(_.toString).right getOrElse ""
}

Optionに変換

ScalazでもEitherにtoOptionメソッドは追加されないのでrightメソッドで得られるRightProjectionのtoOptionメソッドを用いてOptionに変換します。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.map(_.toString) | ""
}

また、以下のようにデフォルト値がモノイドの単位元と同じ場合にはorZeroメソッドを使うこともできます。

def f(a: Either[Exception, Int]): String = {
  a.right.toOption.map(_.toString) orZero
}

ノート

Eitherは、Optionに比べるとかなり扱いにくいオブジェクトです。Scala標準クラスライブラリでは、あくまでも直和、選択を表現するためのオブジェクトであり、典型的な使い方である成功/失敗文脈を扱うのに便利な機能(右側を特別扱いする関数など)が用意されていません。またEitherそのものはOptionのようなモナドでもありませんし、今の所利用頻度がそれほど多くないためか、その他Eitherを取り回す時に便利なユーティリティ機能が少ないので、Optionのような使いやすさにはなりません。

Scalazでも、多少状況は緩和されますが扱いにくいオブジェクトであることは変わりません。

Eitherの文脈を維持する必要がある場合は仕方ありませんが、今回のようにエラー情報そのものは捨ててもよい場合には、最初の段階で計算文脈をEither(エラー情報を保持する成功/失敗文脈)からOption(エラー情報を保持しない成功/失敗文脈)に切り替えるのが有力なテクニックです。

計算文脈の複雑度が低くなるのでプログラミングが扱うべき事項も小さくなります。また、OptionはScalaでもScalazでも、Eitherに比べると機能が豊富でいろいろな技が使えるので、プログラミングの選択肢が広がります。

エラー情報を保持しつつ、成功/失敗の計算文脈でプログラミングを行う場合は、ScalazのValidationが有力な選択肢になります。ValidationはEitherに続けて取り上げる予定です。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Either (2) - flatMap

2012-02-14T08:00:00.000+09:00

Eitherを成功/失敗の文脈で使用する方法のイディオムです。

前回はEitherをOptionと同じ成功/失敗の文脈で使用する方法について見てきました。

これは以下の演算になりますが、ちょうど、Optionでいうと「 Option (3) - map 」に相当する処理です。

条件	結果
Either[A, B]がRight[A, B]	Right[A, C]
Either[A, B]がLeft[A, B]	Left[A, C]

今回は以下の処理、アプリケーションの意図で成功の文脈を失敗の文脈に切り替えるためのMonadic演算についてみていきます。Optionでいうと「Option (6) - flatMap 」に相当する処理になります。

条件	結果
Either[A, B]のRight[A, B]に有効な値が入っている	Right[A, C]
Either[A, B]のRight[A, B]に無効な値が入っている	Left[A, C]
Either[A, B]がLeft[A, B]	Left[A, C]

大枠ではB→Cの演算を行いたいわけですが、これをEither[A, B→C]の文脈の上で行います。この時、Either[A, B]がRight[A, B]であっても「B」が無効な値である場合には、Left[A, C]にすることで、成功の文脈から失敗の文脈へ切り替えます。

以下では、Either[Exception, Int]からEither[Exception, String]への変換を例に考えてみます。ただし、Intは0以上のものが有効という条件を追加します。Either(Right)に入っているIntが0以上の場合、Right[Exception, String]が処理結果となります。一方、0未満の場合は無効となりLeft[Exception, String]が処理結果となります。

Java風

if式でEither#isRightメソッドを使ってLeftとRightの判定をして、処理を切り分ける事ができます。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  if (a.isRight) {
    if (a.right.get >= 0) {
      Right(a.right.get.toString)
    } else {
      Left(new IllegalArgumentException("less than 0"))
    }
  } else {
    a.asInstanceOf[Either[Exception, String]]
  }
}

Scala風

match式を使うとLeftとRightのパターンマッチングで綺麗に書くことができます。ただし、Scala的にはLeft(b)の場合はLeft(b)というロジックを書くのが悔しい。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a match {
    case Right(b) if (b >= 0) => Right(b.toString)
    case Right(_) => Left(new IllegalArgumentException("less than 0"))
    case Left(b) => Left(b)
  }
}

Scala

Eitherのrightメソッドで得られるRightProjectionがモナドっぽい動きをするので、flatMapメソッドを使ってMonadicプログラミングします。flatMapメソッドでは、Int値が0以上である場合は有効な値なのでStringに変換する演算を行い結果をRightオブジェクトに詰めて返します。一方、Int値が0未満の場合は、無効な値なので成功の文脈から失敗の文脈への切り替えとして、LeftオブジェクトにIllegalArgumentExceptionを詰めて返します。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a.right.flatMap { b =>
    if (b >= 0) Right(b.toString)
    else Left(new IllegalArgumentException("less than 0"))
  }
}

Scalaz

Scalazを使うと、Eitherが右側を成功の文脈として動作するモナドに拡張されるので、これを利用したプログラミングが可能です。やはりflatMapメソッドを使います。また、LeftとRightの生成をleftメソッド、rightメソッドで簡潔に記述できるようになります。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a.flatMap { b =>
    if (b >= 0) b.toString.right
    else new IllegalArgumentException("less than 0").left
  }
}

ノート

前回は、Eitherのrightメソッドで返ってくるRightProjectionを使えばMonadic演算が可能なことを説明しました。

RightProjectionを使って、Optionで使用したwithFilter, collect, flatMap, for式といった技が駆使できると嬉しいのですが、残念ながらそうはなっていません。以下の理由により、この中で使える/使って便利なのはflatMapのみとなります。

collectメソッドはRightProjectionにそもそも機能がありません。

withFilterメソッドやfilterメソッドはEither[A, B]ではなくOption[Either[A, B]]を返すので、Optionのハンドリングが余分に必要になります。これは、それなりのコードになってしまうので、それよりflatMapメソッドを使ったほうが簡潔です。

for式は内部的にwithFilterメソッドを使っているので、やはり使えません。

以上の理由で、Eitherに対しては他の機能のことは考えずに、文脈の切り替えはflatMapメソッド一本で考えていくのが得策です。

Scalazの場合も事情は同じで(Left/RightProjectionではなく)EitherのflatMapメソッドを使って処理を記述することになります。

追記 (2012-02-14)

ひなたねこさんのツイートでよりScalazらしい書き方が判明したので補足します。

以下はEither[Exception, Int]の生成にBooleanのeitherメソッドを使ったバージョンです。Right(…)、….rightやLeft(…)、….leftが出てこないので、より簡潔でScalazらしいですね。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a.flatMap { b =>
    !(b >= 0) either {
      new IllegalArgumentException("less than 0")
    } or b.toString
  }
}

またScala版の記述をleftメソッド、rightメソッドを使うものに更新しました。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Either

2012-02-13T08:00:00.000+09:00

Eitherは直和(disjoint union)を表現するオブジェクトです。数学的な意味はこちらを参照してください。

直和は、プログラミング的な観点でざっくりというと二つの種類の値のどちらかを選択する(choice)という意味です。

Eitherでは、2つの種類の値のことをそれぞれleftとrightと呼んでいます。以下ではleftの値を「左側」、rightの値を「右側」と表現することにします。

Eitherの典型的な使い方は、関数の成功と失敗を、成功時の返却値、失敗時の返却値と合わせて通知するというものです。EitherのサブクラスはRightとLeftの2つで、成功の場合はRight、失敗の場合はLeftを使う慣習になっています。右側のRightを成功の用途に使うという慣習は、いうまでもなく「Right=正しい」という英語の意味にかけています。

Eitherを使ってOptionと同様の成功/失敗の計算文脈上でのMonadicプログラミングをすることが可能です。

今回はOption(3)の課題のEither版を考えてみます。

条件	結果
Either[A, B]がRight[A, B]	Right[A, C]
Either[A, B]がLeft[A, B]	Left[A, C]

大枠ではB→Cの演算を行いたいわけですが、これをEither[A, B→C]の文脈の上で行うわけです。

以下で左側(失敗側)にException、右側(成功側)にIntを持つをEither、つまりEither[Exception, Int]をEither[Exception, String]に変換するプログラムを考えます。

(分類の基準)

Java風

if式でEither#isRightメソッドを使ってLeftとRightの判定をして、処理を切り分ける事ができます。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  if (a.isRight) {
    Right(a.right.get.toString)
  } else {
    a.asInstanceOf[Either[Exception, String]]
  }
}

Scala風

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a match {
    case Right(b) => Right(b.toString)
    case Left(b) => Left(b)
  }
}

Scala

Eitherのrightメソッドで得られるRightProjectionがモナドっぽい動きをするので、これを使ってMonadicプログラミングします。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a.right.map(_.toString)
}

RightProjectionそのものはモナドではなく、EitherとRightProjectionを合わせて一つのモナド、というような動きになります。たとえば、mapメソッドを繋げる場合は以下のようになります。

a.right.map(_.toString).right.map(_.toInt)

Scalaz

Scalazを使うと、Eitherが右画はを成功の文脈として動作するモナドに拡張されるので、これを利用したプログラミングが可能です。

def f(a: Either[Exception, Int]): Either[Exception, String] = {
  a.map(_.toString)
}

ScalazではEitherが、エラー情報付きのOption的な機能を持つオブジェクト/モナドになるわけです。

ノート

ScalaのEitherはモナドではないので、Monadicな演算、つまり計算文脈上で値を操作する演算をするためにはちょっとコツが要ります。

Eitherのleftメソッド、rightメソッドで得られるLeftProjection、RightProjectionがモナド的な動きをします。EitherとLeftProjection、RightProjectionを合わせて一つのモナドという使い方になります。

Eitherでは左側と右側を公平に扱っています。左側を主にMonadic演算をする場合は右側は自動的に引き継がれる、逆に右側を主にMonadic演算をする場合は左側は自動的に生き継がれる、という動きになります。左側が主の場合は、leftメソッドで得られるLeftProjection、右側が主の場合は、rightメソッドで得られるRightProjectionを使うわけです。直和を表現するという趣旨からは妥当な仕様です。

しかし、Eitherの典型的な使い方である成功/失敗の文脈の用途では、右側を成功の文脈とするのが慣習となっているため、Either自身が右側を成功の文脈とするモナドである方が使い勝手が良くなります。

Scalazを使うと、まさにこのEitherの右側を成功の文脈とするモナドの機能が付加されます。

日々のプログラミングでは、Option的な成功/失敗の文脈が、Eitherの主たる用途になるのでScalazの拡張を利用するとよいでしょう。

Scala基本クラスの提供する左側と右側が平等に扱われるMonadic演算も、応用にハマれば面白い使い方ができそうです。

追記 (2012-02-13)

よい表現を思いついたので更新しました。

二つの種類の値のどちらかを取る→二つの種類の値どちらかを選択する(choice)

諸元

Scala 2.9.1
Scalaz 6.0.3

SmartDox 0.2.2

2012-02-12T09:00:00.000+09:00

SmartDox 0.2.2をリリースしました。

本バージョンはorg-modeの解析方法を改良しました。

機能

SmartDox 0.2.2では以下のオプションを提供しています。

オプション	機能
-html5	HTML5生成(試験的)
-html4	HTML4生成
-html3	HTML3生成
-plain	プレインテキスト生成
-pdf	PDF生成
-latex	LaTeX生成
-blogger	Blogger用のHTML生成

基本的にSmartDox 0.2.1と同じです。org-modeの解析方法を改良しました。

インストール

プログラムの配布は、Scalaで最近注目されているconscriptを使っています。conscriptのインストール方法は以下のページに詳しいです。

conscript - Scala で作られたソフトウェアをインストールするためのツール

Linux, Macであれば、以下のようにすればインストール完了です。

$ curl https://raw.github.com/n8han/conscript/master/setup.sh | sh

conscriptをインストールした後、以下のようにしてSmartDoxをインストールします。

$ cs asami/dox

以下の2つのコマンドがインストールされます。

dox: SmartDoxコマンド
sdoc: SmartDocコマンド(互換用)

依存プロダクト

SmartDoxでは、以下のプロダクトに依存しています。

プロダクト	使用する機能
LaTeX	PDF生成
Graphviz	画像生成
Ditaa	画像生成

プロダクトに依存する機能を使わない場合は必要ありません。

LaTeX

platexコマンドとdvipdfmxコマンドが実行可能になっていれば基本的にはOKです。

Mac OS上でmacportsを使ってインストールしたLaTeXで動作確認しています。他の環境の場合、スタイルファイルなどがない可能性があります。

Graphviz

dotコマンドが実行可能になっていればOKです。

Mac OS上でmacportsを使ってインストールしたGraphvizで動作確認しています。

Ditaa

ditaaコマンドが実行可能になっているか、optlocalsharejavaditaa09.jarのJarファイルが存在していればOKです。

Mac OS上でmacportsを使ってDitaaをインストールすると、optlocalsharejavaditaa09.jarに配置されます。このditaa09.jarを決め打ちで使用しています。(いずれパラメタで指定可能にする予定です。)

それ以外の環境では、シェルスクリプトなどでditaaコマンド(インストールされているJarファイルを呼び出す)を作成してください。

使い方

まだマニュアルがないので、文書フォーマットは org-modeを参考にしてください。あまり難しい文法を使わなければ大体大丈夫だと思います。

org-mode形式で作成した文書から以下のようにしてHTMLやPDF、プレインテキストに変換してください。

$ dox -html4 mydoc.dox
$ dox -pdf mydoc.dox
$ dox -plain mydoc.dox

サンプル

SmartDoxでは以下のようなorg-mode文書が扱えます。

#+title: SmartDoxサンプル
#+author: 浅海
#+date: 2012年2月12日

* 文章

これは *SmartDox* の文章です。

- SmartDoxのコンセプトは(org-mode＋html5)／2
- HTMLに加えてPDFやプレインテキストを生成することができます。
- GraphvizやDitaaの画像を生成して埋め込むことができます。

* 表

| オプション | 機能                 |
|------------+----------------------|
| -html5     | HTML5生成(試験的)    |
| -html4     | HTML4生成            |
| -html3     | HTML3生成            |
| -plain     | プレインテキスト生成 |
| -pdf       | PDF生成              |
| -latex     | LaTeX生成            |
| -blogger   | Blogger用のHTML生成  |

* 画像

** graphviz

[[http://www.graphviz.org/][Graphviz]] の図を直接書くことができます。

#+begin_dot images/dot_example.png -Tpng
digraph G {
  Hello->World
}
#+end_dot

** ditaa

[[http://ditaa.sourceforge.net/][Ditaa]] の図を直接書くことができます。

#+begin_ditaa images/ditaa_example.png
+--------+   +-------+    +-------+
|        | --+ ditaa +--> |       |
|  Text  |   +-------+    |diagram|
|Document|   |!magic!|    |       |
|     {d}|   |       |    |       |
+---+----+   +-------+    +-------+
    :                         ^
    |       Lots of work      |
    +-------------------------+
#+end_ditaa

** SimpleModeler

SimpleModelerを使ってCSVでクラス図を
書くことができます。

#+begin_sm_csv images/sm_csv_simplemodel.png
#actor
顧客
個人顧客,,,,,顧客
法人顧客,,,,,顧客
#resource
商品,商品名,,商品区分(第1類;第2類;第3類)
#event
購入する,,顧客;商品
#+end_sm_csv

PDF

PDFの生成は以下のようにして行います。PDFの生成時に画像の生成も自動的に行いPDF内に埋め込まれます。

$ dox -plain sample.dox

3ページのPDFが生成されます。2ページ目は以下のように表や図が記述されています。

1ページ目はタイトル、3ページ目はditaaとSimpleModeleの図です。

プレインテキスト

ブラウザでは崩れて見えますが、等幅フォントを使えば表やタイトル下の下線も正しくレイアウトされます。

SmartDoxサンプル
                           ━━━━━━━━

                            2012年2月12日
                                 浅海


目次
──

  1 文章
  2 表
  3 画像
    3.1 graphviz
    3.2 ditaa
    3.3 SimpleModeler


1 文章
───

  これは SmartDox の文章です。

    - SmartDoxのコンセプトは(org-mode＋html5)／2
    - HTMLに加えてPDFやプレインテキストを生成することができます。
    - GraphvizやDitaaの画像を生成して埋め込むことができます。


2 表
──

┏━━━━━┯━━━━━━━━━━┓
┃オプション│        機能        ┃
┣━━━━━┿━━━━━━━━━━┫
┃-html5    │HTML5生成(試験的)   ┃
┠─────┼──────────┨
┃-html4    │HTML4生成           ┃
┠─────┼──────────┨
┃-html3    │HTML3生成           ┃
┠─────┼──────────┨
┃-plain    │プレインテキスト生成┃
┠─────┼──────────┨
┃-pdf      │PDF生成             ┃
┠─────┼──────────┨
┃-latex    │LaTeX生成           ┃
┠─────┼──────────┨
┃-blogger  │Blogger用のHTML生成 ┃
┗━━━━━┷━━━━━━━━━━┛


3 画像
───


3.1 graphviz
──────

  Graphviz<http://www.graphviz.org/> の図を直接書くことができます。
  <images/dot_example.png>


3.2 ditaa
─────

  Ditaa<http://ditaa.sourceforge.net/> の図を直接書くことができます。
  <images/ditaa_example.png>


3.3 SimpleModeler
─────────

  SimpleModelerを使ってCSVでクラス図を書くことができます。
  <images/sm_csv_simplemodel.png>

Scala Tips / Option - Index

2012-02-10T08:00:00.000+09:00

Optionが一段落したので記事の一覧表をまとめておきます。

項目	内容
Option	値の取得
Option (2)	nullをOptionに持ち上げる方法
Option (3)	map
Option (4)	withFilter
Option (5)	collect
Option (6)	flatMap
Option (7)	for式
Option (8)	getOrElse
Option (9)	withFilter, map, getOrElse
Option (10) - Exception	flatMap, Exceptionハンドリング
Option (11) - Some／None	SomeとNoneの記述方法
null	nullを値に持ち上げる方法

Optionをnullの問題を回避するためのコンテナとみるとちょっとした便利機能のように思ってしまいますが、成功/失敗の計算文脈を実現するモナドとしてみると、関数型プログラミングの広大な世界が垣間見えてきます。

Optionについては以下の記事も参考になると思います。

Scala Tips / Option (11) - Some/None

2012-02-09T08:00:00.000+09:00

OptionのサブクラスであるSomeとNoneを生成するイディオムです。

Scala

Some[Int]とNoneは以下のようにして生成します。(Noneは実際にはシングルトンです。)

val a = Some(10)
val a = None

通常はこの生成方法で良いのですが、一つ問題があります。Some(10)の型はOption[Int]ではなくSome[Int]に、Noneの型もOption[Int]ではなくNone[Nothing]になってしまいます。

scala> val a = Some(10)
a: Some[Int] = Some(10)

scala> val a = None
a: None.type = None

このため、型をOption[Int]にするためには以下のように変数定義に記述するか:

val a: Option[Int] = Some(10)
val a: Option[Int] = None

オブジェクト側に型注釈を付ける必要があります。

val a = Some(10): Option[Int]
val a = None: Option[Int]

いずれもちょっと冗長ですね。

Scalaz

Scalazでは、以下の記述方法でSomeとNoneを生成することが可能です。

val a = 10.some
val a = none[Int]

「10.some」のように任意のオブジェクトのsomeメソッド(Scalazが追加)によってOption[Int]型のインスタンスとしてSome[Int]を生成することができます。また、「none[Int]」のように型名を指定することでOption[Int]型のインスタンスとしてNoneを生成することができます。

scala> 1.some
res53: Option[Int] = Some(1)

scala> none[Int]
res54: Option[Int] = None

BooleanをOptionに変換

Scalazでは、Optionを生成する方法としてBooleanのoptinメソッドを使用する方法があります。(Option(6))

def f(cond: Boolean, value: Int): Option[Int] = {
  cond.option(value)
}

条件が真だった場合は指定した値でSomeを、偽だった場合はNoneを作成します。BooleanをOptionに変換する機能ということができます。

ノート

Some(10) と 10.some の違いは、一つは見た目として関数型プログラミング的に 10.some の方が見やすいというのがあると思います。この問題はテーマとしていずれ取り上げたいと思います。これは、あくまで主観的なものなので、見た目の問題だけならどちらの記法を採るのかというのは好みの問題となります。

ということで、もっと実利的な意味で 10.some が有益なケースというのを知りたいところです。

Scalazの 10.some という記法が具体的に役に立つのは、関数の引数で型情報まで記述する場合です。

典型的な例がfoldLeftメソッドです。foldLeftメソッドはで畳込みの結果を積算する値の型は、引数に指定する値に付帯する形で指定しなければなりません。

List#foldLeftメソッドを使ってList[Int]の内容を積算するプログラムを例に考えます。Int値がすべて0以上の場合は積算を行いますが、一つでも0未満のものが合った場合はエラーとします。積算が成功した場合はSome[Int]を、失敗した場合はNoneを返します。

まず、初期値として普通にSome(0)を指定してみます。

以下の指定はコンパイルエラーになります。初期値として Some(0) とするとSome[Int]型になってしまうので、Option[Int]として演算ができなくなってしまうわけです。

def f(l: List[Int]): Option[Int] = {
  l.foldLeft(Some(0)) { (a, e) =>
    if (e >= 0) a.map(_ + e) else None
  }
}

これは、以下のように型を明記すれば解決しますが、ちょっと冗長ですね。

def f(l: List[Int]): Option[Int] = {
  l.foldLeft(Some(0): Option[Int]) { (a, e) =>
    if (e >= 0) a.map(_ + e) else None
  }
}

Scalazの 0.some は型がOption[Int]になるので、この問題が発生しません。

def f(l: List[Int]): Option[Int] = {
  l.foldLeft(0.some) { (a, e) =>
    if (e >= 0) a.map(_ + e) else none
  }
}

Optionに対するfoldLeftでの畳込み

ついでなのでOption操作の復習も兼ねて、foldLeftでOptionに対する畳込みをいくつか書いてみました。

def f1(l: List[Int]): Option[Int] = {
  l.foldLeft(0.some) { (a, e) =>
    if (e >= 0) a.map(_ + e) else none
  }
}

def f2(l: List[Int]): Option[Int] = {
  l.foldLeft(0.some) { (a, e) =>
    (e >= 0).fold(a.map(_ + e), none)
  }
}

def f3(l: List[Int]): Option[Int] = {
  l.foldLeft(0.some) { (a, e) =>
    for (x <- a if e >= 0) yield x + e
  }
}

def f4(l: List[Int]): Option[Int] = {
  l.foldLeft(0.some) { (a, e) =>
    a.withFilter(_ => e >= 0).map(_ + e)
  }
}

同じ処理でも色々な書き方ができます。もう少し複雑な処理だと、それぞれの書き方との相性が出てくるので、色々ストックしておいて適材適所で選んでいくようにしたいですね。

関数	説明	参考
f1	if式を使った普通の手法	Option(4)
f2	Booleanのfoldを使った手法	Option(8)
f3	for式を使った手法	Option(7)
f4	withFilterとmapを使った手法	Option(4)

追記 (2012-02-12)

xuwei_kさんのご指摘で抜けがあることが分かったので補足です。

Some(10) と 10.some の比較をして、後者の方がOption[Int]という型になるので、使いやすいという話をしました。この点について補足です。

Scalaの標準ライブラリでは Some(10) とは別に Option(10) というOptionの生成方法を用意していて、この場合はOption[Int]型の Some(10) を生成します。本記事の用途では、Someに関しては Option(10) の方法でも実現可能です。Scalazを使わない場合は、こちらを使うとよいでしょう。

ただし、Noneに関しては、ちょっとややこしくなります。

Option(null) で生成できるものの型がOption[NULL]になってしまいます。

格納するオブジェクトがAnyRefである場合には、Option[String](null)やOption(null: String) という記法が可能です。(関連「null」)

scala> Option[String](null)
res32: Option[String] = None

scala> Option(null: String)
res29: Option[String] = None

ただし、Anyの場合は使えません。

scala> Option[Int](null)
<console>:8: error: type mismatch;
 found   : Null(null)
 required: Int
Note that implicit conversions are not applicable because they are ambiguous:
 both method Integer2intNullConflict in class LowPriorityImplicits of type (x: Null)Int
 and method Integer2int in object Predef of type (x: java.lang.Integer)Int
 are possible conversion functions from Null(null) to Int
              Option[Int](null)
                          ^

scala> Option(null: Int)
<console>:8: error: type mismatch;
 found   : Null(null)
 required: Int
Note that implicit conversions are not applicable because they are ambiguous:
 both method Integer2intNullConflict in class LowPriorityImplicits of type (x: Null)Int
 and method Integer2int in object Predef of type (x: java.lang.Integer)Int
 are possible conversion functions from Null(null) to Int
              Option(null: Int)
                     ^

以上のようにNoneの場合は、色々と考えないといけないことがあります。この辺の事情を覚えておいてプログラミング中に使い分けても、特にメリットがあるところではないので、Noneを生成する場合は変数や関数シグネチャの型定義またはオブジェクトに対する型注釈で型を補うという方針にしておくのがよいと思います。

scala> None: Option[Int]
res31: Option[Int] = None

Scalazを使っている場合は、本文中にあったように、10.some , none[Int] の記法を使うようにするのが分かりやすくてよいでしょう。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (10) - Exception

2012-02-08T08:00:00.000+09:00

Optionから値を取り出すイディオムです。

Optionから値を取り出す際に、以下の表の演算を行う方法についてみてきました。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

今回は「Option[A]に無効な値が入っている」の判定で例外を使用するケースです。例外を使うと、プログラミングにも少なからぬ影響が出てきます。

以下では、Option[String]からOption[Int]への変換を例に考えてみます。Optionに入っているStringがIntに変換できる場合は有効となり、Some[Int]が処理結果となります。一方、変換できない場合は無効となりNoneが処理結果となります。

ここで、StringからIntへの変換ができない事の判定に例外を使用します。

(分類の基準)

Java風

if式でOption#isDefinedを使って値の有無を判定します。

文字列が整数値に合致しなかった場合String#toIntメソッドがNumberFormatExceptionをスローするので、これをtry/catch文でキャッチしています。

引数がNoneの場合とNumberFormatExceptionをキャッチした時がNone、toIntで整数値が得られた場合はSome[Int]が演算結果となります。

def f(a: Option[String]): Option[Int] = {
  if (a.isDefined) {
    try {
      Some(a.get.toInt)
    } catch {
      case e: NumberFormatException => None
    }
  } else None
}

Scala風

match式を使うと以下のようになります。try/catch文が入るとプログラムの見通しはJava風とそれほど変わらなくなりますね。

def f(a: Option[String]): Option[Int] = {
  a match {
    case Some(b) => {
      try {
        Some(a.get.toInt)
      } catch {
        case e: NumberFormatException => None
      }
    }
    case None => None
  }
}

Scala

Optionの処理にmapメソッドを使うのがScala的なコーディングです。ただし、今回のケースでは例外をキャッチする処理を行う必要があります。

def f(a: Option[String]): Option[Int] = {
  try {
    a.map(_.toInt)
  } catch {
    case e: NumberFormatException => None
  }
}

mapメソッドの外側でtry/catchを使って例外をキャッチするのは、ちょっと美しくありません。例外に依存するロジックは部品化の妨げになるので、できるだけ局所化して隠蔽したいところです。

このためには、mapメソッドの中で例外をキャッチしたいわけですが、この場合は例外をキャッチしたときに、成功の文脈から失敗の文脈への切り替えを行う必要があるので、Option(6)で取り上げたOption#flatMapメソッドを使用します。

def f(a: Option[String]): Option[Int] = {
  a.flatMap { b =>
    try {
      Some(b.toInt)
    } catch {
      case e: NumberFormatException => None
    }
  }
}

例外をキャッチしてOptionに変換するのはScalaでは頻出の処理なので、専用の関数がオブジェクトscala.util.control.Exceptionに用意されています。よく使うのがcatching関数とallCatch関数です。

catching関数は、キャッチする例外を列挙して指定することができます。catching関数から返されるCatchオブジェクトのoptメソッドで例外の発生の有無をOptionに変換することができます。

import scala.util.control.Exception._    

def f(a: Option[String]): Option[Int] = {
  a.flatMap { b =>
    catching(classOf[NumberFormatException]).opt(b.toInt)
  }
}

多くの場合はNumberFormatException以外の例外が発生しても関数のエラーとして返して大丈夫だと思われるので、すべての例外をキャッチするallCatching関数を使う方法も有力です。

import scala.util.control.Exception._    

def f(a: Option[String]): Option[Int] = {
  a.flatMap { b =>
    allCatch.opt(b.toInt)
  }
}

Scalaz

Scalaz流のエレガントな書き方はないと思います。

汎用的な方法ではありませんが、今回の例題である文字列を数値に変換する処理に関しては、ScalazのparseIntメソッド(parseFloatその他もあります)が利用できます。

def f(a: Option[String]): Option[Int] = {
  a.flatMap(_.parseInt.toOption)
}

parseIntメソッドは数値への変換の成否をValidationオブジェクトとして通知します。ValidationのtoOptionメソッドでOptionに変換します。

ノート

例外を関数型プログラミングの中でどう扱っていくのかというのは、ちょっと悩むところですが、Java由来のOOPとのハイブリッドであるScalaでは避けて通ることはできません。

例外処理の考え方はいずれイディオムとしてまとめる予定ですが、今の所、できるだけ早い段階でOption, Either, Validationにして関数合成を軸としたMonadic演算のラインに乗せる方向が、よいのではないかと考えています。

そういう意味で、Scala 2.8から入ってきたscala.util.control.Exceptionは重要な機能ということができます。

現段階では、Optionまでしか取り上げていないので、Either, Validationが終わったたところで改めて考えることにします。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (9)

2012-02-07T08:00:00.001+09:00

Optionから値を取り出すイディオムです。

Optionから値を取り出す処理として以下の2つのコーディングパターンを挙げました。

Option[A]からOption[B]に変換
Option[A]からBに変換

前回は、後者のOption[A]からBへの変換について、基本的なイディオムを紹介しました。

条件	結果	演算
Option[A]がSome[A]	B	AからBを計算
Option[A]がNone	B	デフォルト値

今回は、Option[A]がNoneの場合だけでなく、Some[A]の値が条件を満たさない場合も、デフォルト値を返すようにします。

条件	結果	演算
Option[A]に有効な値が入っている	B	AからBを計算
Option[A]に無効な値が入っている	B	デフォルト値
Option[A]がNone	B	デフォルト値

以下では、Option[Int]からStringへの変換を例に考えてみます。ただし、Intは0以上のものが有効という条件を追加します。Optionに入っているIntが0以上の場合、Stringが処理結果となります。一方、0未満の場合は無効となり空文字列「""」が処理結果となります。またOption[A]がNoneの場合も空文字列「""」が処理結果となります。

Java風

if式でOption#isDefinedを使って値の有無を判定します。isDefinedAtメソッドが一回、getメソッドが二回が泣き別れになってしまいます。

def f(a: Option[Int]): String = {
  if (a.isDefined && a.get >= 0) a.get.toString
  else ""
}

Scala風

match式を使うと以下のようになります。こちらの方が綺麗ですね。

def f(a: Option[Int]): String = {
  a match {
    case Some(b) if (b >= 0) => b.toString
    case _ => ""
  }
}

Scala

Option(4)のwithFilterメソッド、mapメソッドとOption のgetOrElseメソッドの合わせ技で実現できます。

def f(a: Option[Int]): String = {
  a.withFilter(_ >= 0).map(b.toString) getOrElse ""
}

Scalaz

Scalazの場合はOption(7)の技法にOption(4)のwithFilterメソッドまたはfilterメソッドを組合わせて、実現できます。

注意点としては、cataメソッドとfoldメソッドの場合はwithFilterではなくてfilterを使う必要があります。cataメソッドとfoldメソッドはScalazが拡張したメソッドで、ScalaのWithFilterオブジェクトは扱えないからです。

def f(a: Option[Int]): String = {
  a.withFilter(_ >= 0).map(_.toString) | ""
}

def f(a: Option[Int]): String = {
  a.filter(_ >= 0).cata(_.toString, "")
}

def f(a: Option[Int]): String = {
  a.filter(_ >= 0).fold(_.toString, "")
}

def f(a: Option[Int]): String = {
  a.withFilter(_ >= 0).map(_.toString) orZero
}

def f(a: Option[Int]): String = {
  ~a.withFilter(_ >= 0).map(_.toString)
}

ノート

今回はOption(4)のwithFilterメソッドを組み合わせてみましたが、Option(5)のcollectメソッド、Option(6)のflatMapメソッドでも同じように実現できます。

要するに、Option上で(つまり成功失敗の計算文脈上で)計算を続け、最後にcataメソッドなどでOptionから値を取り出すというメカニズムです。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (8)

2012-02-06T08:00:00.001+09:00

Optionから値を取り出すイディオムです。

Optionから値を取り出す処理として以下の2つのコーディングパターンを挙げました。

Option[A]からOption[B]に変換
Option[A]からBに変換

ここまではOption[A]からOption[B]への変換についてみてきました。今回はOption[A]からBへの変換について考えます。

条件	結果	演算
Option[A]がSome[A]	B	AからBを計算
Option[A]がNone	B	デフォルト値

Option[A]に有効な値が入っている場合は、この値からBを計算しますが、それ以外の場合はあらかじめ用意しているデフォルト値を返します。

以下では、Option[Int]からStringへの変換を例に考えてみます。Option[A]がNoneの場合はデフォルト値として空文字列「""」を返すことにします。

Java風

if式でOption#isDefinedを使って値の有無を判定します。デフォルト値の「""」はelse句で指定します。

def f(a: Option[Int]): String = {
  if (a.isDefined) a.get.toString
  else ""
}

Scala風

match式を使うと以下のようになります。こちらの方が綺麗ですね。

def f(a: Option[Int]): String = {
  a match {
    case Some(b) => b.toString
    case None => ""
  }
}

Scala

Option(3)のmapメソッドとOption のgetOrElseメソッドの合わせ技で実現できます。

def f(a: Option[Int]): String = {
  a.map(_.toString) getOrElse ""
}

Scalaz

Scalazも、Option(3)のmapメソッドとOption の「|」メソッドの合わせ技で実現できます。

def f(a: Option[Int]): String = {
  a.map(_.toString) | ""
}

Scalazでは、今回の用途にぴったりのメソッドOption#cataとOption#foldが用意されています。以下のように使用します。

def f(a: Option[Int]): String = {
  a.cata(_.toString, "")
}

def f(a: Option[Int]): String = {
  a.fold(_.toString, "")
}

foldメソッドはcataメソッド(cataはcatamorphismの略)に分かりやすい名前をつけたもので、全く同じ動作をします。好きな方を使用すればよいでしょう。

以上が汎用的な方法ですが、条件が合えば以下のようにorZeroメソッドや「~」メソッドを使う方法も適用できます。

def f(a: Option[Int]): String = {
  a.map(_.toString) orZero
}

def f(a: Option[Int]): String = {
  ~a.map(_.toString)
}

StringやIntといった型では、Scalazが初期値を持っています。この初期値を単位元と呼びます。デフォルト値がScalazが持っている初期値、すなわち単位元でよい場合は、これを利用するとデフォルト値の指定を省略することができます。今回使用している問題は、デフォルト値が「""」ですが、これはStringの単位元と同じなので、この条件に当てはまります。

このため、OptionがNoneだった場合にデフォルト値として単位元を使うorZeroメソッドと単項演算子の「~」メソッドを使用することができるわけです。

orZeroメソッドと「~」メソッドは好みの方を使えばよいでしょう。orZeroメソッドを使うとちょっとごっつい感じですが、「~」メソッドは簡潔に記述できます。ただ、「~」は単項演算子で、見落としてしまいがちなのと、普通の単項演算子とはちょっと違う感触の使い方なので、プログラムの可読性が必ずしも高くないかもしれません。

ノート

Scalazはモノイドという性質を扱うための型クラスMonoidを用意しています。モノイドの数学的な定義はこちら(Wikipedia)をご覧ください。

数学のモノイドはとても難しそうですが、Scalazの型クラスMonoidが適用されるオブジェクトはざっくりと以下の性質を持つと理解しておけばよいでしょう。

結合的な二項演算を持っている。多くの場合は加算。
単位元(identity element) を持っている。

単位元はざっくりいうと a+e や e+a の二項演算を行った時に、 a+e=a 、 e+a=a となるeの事です。具体的には、 1+0=1 、 0+1=1 における0、 "Hello"+""="Hello" 、""+"Hello" における「""」です。つまりIntの単位元は0、Stringの単位元は「""」となります。

前述のorZeroメソッドや「~」メソッドは、モノイドの性質である単位元を使用しています。関数fは演算結果がStringでデフォルト値が「""」となる演算を定義しているわけですが、このデフォルト値「""」が、たまたまStringの単位元と同じなので、モノイドの性質を利用しているorZeroメソッドや「~」メソッドを使うことができるわけです。

Scalazでの代表的なMonoidのオブジェクトは、Int、String、Listといったものです。加算的な演算を持っているオブジェクトはだいたいMonoidとして操作できるようになっています。

Int、String、Listといったオブジェクトの共通の性質としてMonoidを定義することで、Monoidを対象にしたロジックを組めば、Int、String、Listといったオブジェクト指向的には全く異なったオブジェクトに同じロジックを適用できるようになります。たとえば、ScalazのValidationはこのモノイドをうまく利用しています。

今回のイディオムでは、Monoidの性質のごく一部を使っているだけでしたが、MonoidはScalazプログラミングでは頻出の極めて重要な型クラスなので少し詳しく説明してみました。

最後に、Monoidの動作をREPLで試してみたものを以下に示します。

単位元はmzero関数で取得できます。

scala> mzero[Int]
res4: Int = 0

scala> mzero[String]
res5: String = ""

scala> mzero[List[Int]]
res7: List[Int] = List()

Monoidの二項演算は|+|メソッドまたは⊹メソッドです。(後者はUnicodeの数学記号になっています。)

scala> 1 |+| 1
res8: Int = 2

scala> 1 |+| mzero[Int]
res9: Int = 1

scala> mzero[Int] |+| 1
res10: Int = 1

scala> "Hello" |+| "World"
res15: java.lang.String = HelloWorld

scala> "Hello" |+| mzero[String]
res16: java.lang.String = Hello

scala> mzero[String] |+| "World"
res17: String = World

scala> List(1, 2, 3) |+| List(4, 5, 6)
res11: List[Int] = List(1, 2, 3, 4, 5, 6)

scala> List(1, 2, 3) |+| mzero[List[Int]]
res13: List[Int] = List(1, 2, 3)

scala> mzero[List[Int]] |+| List(1, 2, 3)
res14: List[Int] = List(1, 2, 3)

諸元

Scala 2.9.1
Scalaz 6.0.3

追加

一部、次回の記事が混入していたので、2月6日8時45分頃に内容を更新しました。

Scala Tips / Option (7)

2012-02-03T08:00:00.000+09:00

Optionから値を取り出すイディオムです。

ここまで以下の演算と:

条件	結果
Option［A］がSome［A］	Some［B］
Option［A］がNone	None

以下の演算についてみてきました。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

前者は、成功の文脈と失敗の文脈の切り替えが発生しない演算、後者は、成功の文脈と失敗の文脈の切り替えが発生する演算です。

今回はこの2つの演算をfor式を使って書いてみます。

Some[A]→Some[B]

Option(3)で取り上げた成功の文脈と失敗の文脈の切り替えが発生しない演算です。以下の表に示す演算になります。

条件	結果
Option［A］がSome［A］	Some［B］
Option［A］がNone	None

Option[Int]からOption[String]へ変換は以下のようになります。

def f(a: Option[Int]): Option[String] = {
  for (b <- a) yield b.toString
}

Option(3)で使用したmapメソッドと同様に、Option[A]がNoneだった場合の処理を書く必要がありません。

Some[A]→None

次はOption(4)で取り上げた成功の文脈と失敗の文脈の切り替えが発生する演算です。以下の表に示す演算になります。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

Intは0以上のものが有効という条件付きのOption[Int]からOption[String]へ変換は以下のようになります。

def f(a: Option[Int]): Option[String] = {
  for (b <- a if b >= 0) yield b.toString
}

for式内のif句で、Some[A]をNoneに切り替える条件を指定することができます。

ノート

Javaのfor文は構造化プログラミングにおける繰り返しを記述するための文でしたが、Scalaのfor式はモナドによる演算の文法糖衣となっています。

たとえば、以下のプログラムは、一見普通のfor文に見えますが、実際は0オブジェクト(Int型)のuntilメソッドが返すRangeオブジェクトがモナドで、このRangeオブジェクトに対するモナドの演算を行っています。

for (i <- 0 until 10) {
  println(i)
}

モナドに対する演算を伝統的なfor文に見せているのがScalaの芸の細かいところで、Java言語などから移行する場合の敷居を低くしています。普通にプログラミングしていても自然にMonadicプログラミングをしているということになるわけで、使い方に慣れたところで徐々にMonadicプログラミング的な作法を取り入れていけばよいようになっています。

for式には、上記の(yield句なしの)for式と本文中で用いているyield句ありのfor式の2種類があります。

yield句ありのfor式の場合は、内部的に今までOption操作で使ってきた、mapメソッド、flatMapメソッド、withFilterメソッドを使って処理を行っています。つまり、完全な文法糖衣ということです。(yield句なしのfor式ではforeachメソッドを使います。)

今回取り上げているOptionから値を取り出すといった小さな処理では、mapメソッドなどを直接使ってもfor式を使っても効果はそれほど変わりません。好みの方を使うとよいでしょう。

ただし、Option(6)のようにflatMapメソッドを使って細かい操作をしたい場合や、Option(5)のようにcollectメソッドのようなfor式がカバーしていないメソッドを使いたい場合は、for式は諦めることになります。

逆に本格的なMonadicプログラミングを行う場合、for式を使うと見通しがよくなるケースがあるので、こういう場合はfor式を積極的に使っていきたいところです。

このあたりの選択のポイントについてもテーマとして考えていきたいと思います。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (6)

2012-02-02T08:00:00.000+09:00

Optionから値を取り出すイディオムです。

以下の表が示す演算について考えています。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

withFilterバージョン、collectバージョンに続いて、flatMapバージョンです。

引き続きIntは0以上のものが有効という条件付きのOption[Int]からOption[String]へ変換を例に考えてみます。

(分類の基準)

Java風

Option(4)と同じです。

Scala風

Option(4)と同じです。

Scala

Option[Int]のflatMapメソッドは、Option[Int]の格納する値であるIntを引数に取り、この場合はOption[String]を返す関数を実行します。Option(3)で取り上げた、mapメソッドの場合はIntを引数に取りStringを返す関数を実行し、その結果をmapメソッド側でOptionに詰めなおしますが、flatMapの場合は、StringをOptionに詰め直す作業もアプリケーション側の関数で行います。

def f(a: Option[Int]): Option[String] = {
  a.flatMap { b =>
    if (b >= 0) Some(b.toString)
    else None
  }
}

Scalaz

Scalazの場合もflatMapメソッドを使いますが、flatMapの中のロジックをより簡潔に記述することができます。

def f(a: Option[Int]): Option[String] = {
  a.flatMap(b => (b >= 0).option(b.toString))
}

Scalazでは、Booleanにoptionメソッドを拡張しています。optionメソッドでは、Booleanが真の場合、指定した関数が実行され、その結果をSomeに詰めたものが返されます。一方、偽の場合はNoneが返されます。

(b >= 0).option(b.toString)は、bの値が0以上の場合にbをStringにしたものをSome[String]に詰めて返し、そうでない場合はNoneを返します。

Scalazでは、このように式を簡潔に記述できる便利なメソッドが多数追加されています。

ノート

今回の用途では、Optionのfilter/withFilterメソッドやcollectメソッドで十分に要件を満たせるので、イディオムとしてはこの2つだけもよかったのですが、プリケーションの意志で成功の文脈を失敗の文脈に切り替えるということを、もっと直接的な形で行う手法をマスターしておかないと応用が効かないので、flatMapメソッドも取り上げました。

以下の表の演算において:

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

「Option[A]に無効な値が入っている」部分が、アプリケーションの意志で成功の文脈を失敗の文脈に切り替えるところになります。

filter/withFilterメソッドやcollectメソッドは自動的にこの切り替えを行ってくれるわけですが、それぞれのメソッドの機能ははっきり決まっていて、提供された機能以外の用途に使うのは得策ではありません。

そういった汎用目的で成功の文脈を失敗の文脈に切り替える処理を行うのがflatMapメソッドです。

mapメソッドを使うと、成功の文脈における演算を記述することができましたが、成功の文脈を失敗の文脈に切り替えることはできませんでした。flatMapメソッドは、この切り替えを記述するためのメソッドというわけです。

モナドは計算文脈をカプセル化して扱う技術と考えることができます。(モナドの一種であるOptionは成功/失敗の文脈をカプセル化していました。)この計算文脈の操作に色々な手法が存在するわけですが、その中軸となるのがflatMapメソッドです。

flatMapメソッドを使いこなせるようになるとScalaプログラミングの幅がぐんと広がります。

filter, collect, flatMapの使い分け

前回はfilterメソッドとcollectメソッドの使い分けについて説明しましたが、これにflatMapが加わりました。

filterメソッドやcollectメソッドは、使い方の形が決まっているので、これにぴったりハマるケースはfilterメソッドやcollectメソッドを使えばよいでしょう。

あまりぴったりはまらないケース、判定ロジックと生成ロジックが入り乱れているような場合に、flatMapメソッドを使うことになります。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (5)

2012-02-01T08:00:00.000+09:00

Optionから値を取り出すイディオムです。

以下の表が示す演算について考えています。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

withFilterバージョンに続いて、collectバージョンです。

前回はwithFilterメソッドとmapメソッドを組合せてこの表の演算を実現しましたが、これを一発で行うメソッドがあります。これがcollectメソッドです。

引き続きIntは0以上のものが有効という条件付きのOption[Int]からOption[String]へ変換を例に考えてみます。

(分類の基準)

Java風

Option(4)と同じです。

Scala風

Option(4)と同じです。

Scala

Option#collectメソッドにケースシーケンスを用いて部分関数(PartialFunction)を指定します。

指定した部分関数は、「指定されたInt値が0以上の場合には値をStringに変換する」というものです。指定されたInt値が0以上でない場合には、この部分関数は適用されません。

以下のプログラムでは、Option[Int]がSome[Int]の場合、部分関数が適用可能か(つまりInt値が0以上か)を検査し、適用可能の場合に部分関数を評価することでInt値をStringに変換します。collectメソッドはさらにStringをSome[String]に詰めなおして返します。また、Option[Int]がNoneの場合、あるいはSome[Int]だけど部分関数が適用可能でなかった場合はNoneを返します。

def f(a: Option[Int]): Option[String] = {
  a collect {
    case b if b >= 0 => b.toString
  }
}

Scalaz

Scalaz流のエレガントな書き方はないと思います。

ノート

以下の表が示す演算について考えています。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

withFilterメソッドとmapメソッドを組合せて実現していた処理をcollectメソッド一発で実現できました。

collectメソッドは非常に強力ですが、その力の源となっているのがPartialFunctionという関数オブジェクトです。部分関数と呼ぶこともできます。collectメソッドはPartialFunctionを引数に取ります。

関数の引数に指定された型の一部の値のみを評価できる関数が部分関数です。評価できない値に対しては関数は未定義となります。

ケースシーケンスや部分関数、PartialFunctionという用語は見慣れないかもしれませんが、プログラムをみれば、やろうとしていることは一目瞭然だと思います。まずは、match式の後ろ半分case句の集りがケースシーケンスで、ケースシーケンスはPartialFunctionという関数オブジェクトに落とし込まれる、と覚えておいてください。(使い方に慣れてきたら文法書を確認して正確な定義を理解しておくとよいでしょう。)

PartialFunctionをScalaプログラムのリテラルとして記述する方法がケースシーケンスです。ケースシーケンスはmatch式からキーワードmatchを除いた後ろ半分の形です。今回のプログラムの以下の部分ですね。(アスタリスクは無視)

******** {
    case b if b >= 0 => b.toString
  }

処理の意味はmatch式のcase句と同様です。指定されたInt値を変数bにバインドし、このbの値が0以上の場合は、Int値をStringに変換します。0以上の値でない場合は、この部分関数は未定義となります。部分関数が未定義の場合、Option#collectメソッドはNoneを返します。

PartialFunctionの主要なメソッドは以下の2つです。

メソッド	機能
isDefinedAt	指定された値が関数の引数として有効化を判定
apply	関数の評価

通常の関数オブジェクト(Function1など)はapplyメソッドは持っていますが、isDefinedAtは持っていません。

isDefinedAtメソッドは指定された値が関数に取って有効かどうかを判定するメソッドです。collectメソッドは、このisDefinedAtメソッドを使用して、現在扱っている値に対して部分関数が未定義がどうかを判定しているわけです。

前述のケースシーケンスの場合、case句中の「if b >= 0」がisDefinedAtメソッドの実装に、「b.toString」がapplyメソッドの実装になるわけです。ケースシーケンスは、こういったPartialFunctionオブジェクト定義の文法糖衣というわけですね。

PartialFunctionはScalaプログラミングの様々な場所に現れ、非常に重要な役割を担います。これからも色々なイディオムに登場すると思います。

filter, collectの使い分け

今回の用途では、filterメソッドとcollectメソッドはどちらも似たような効果を得ることができます。好みの方を使うとよいでしょう。

filterメソッドの方が機能が絞り込まれている分、プログラムがやりたいことの意図ははっきりすると思います。

ボク自身のプログラミングでは、多分collectメソッドの方を使うと思います。ちょっとだけ性能が速そうなので。

filterメソッドとcollectメソッドで明らかにcollectメソッドが有用なケースもあるのですが、これは別の機会に取り上げたいと思います。

諸元

Scala 2.9.1
Scalaz 6.0.3

Scala Tips / Option (4)

2012-01-31T08:00:00.000+09:00

Optionから値を取り出すイディオムです。
前回は、Optionに値が格納されているケースといないケースの両方に対応するイディオムでした。今回は、これを拡張してOptionに格納されている値が行おうとしている処理に対して無効だったケースを追加します。
前回の演算は以下の表の示す演算でしたが、これを拡張して:

条件	結果
Option[A]がSome[A]	Some[B]
Option[A]がNone	None

以下の表が示す演算にします。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

「Option[A]に無効な値が入っている」のケースが加わっています。
以下では、引き続きOption[Int]からOption[String]への変換を例に考えてみます。ただし、Intは0以上のものが有効という条件を追加します。
Optionに入っているIntが0以上の場合、Some[String]が処理結果となります。一方、0未満の場合は無効となりNoneが処理結果となります。
(分類の基準)

Java風

if式でOption#isDefinedを使ってOptionが有効であることを確認後、さらにif式で値が0以上であることを判定します。このプログラムにあるように a.get を二度行なうか、a.get の値を変数に覚えておかなくてはいけません。

def f(a: Option[Int]): Option[String] = {
  if (a.isDefined) {
    if (a.get >= 0) Some(a.get.toString)
    else None
  } else {
    None
  }
}

Scala風

match式を使うと以下のようになります。a.get の二回判定(または a.get の値を変数に記憶)が必要なくなるのでその点はすっきりしています。とはいえ「Noneの場合はNone」の処理を記述するのはScala的には悔しい感じ。

def f(a: Option[Int]): Option[String] = {
  a match {
    case Some(b) => if (b >= 0) Some(b.toString) else None
    case None => None
  }
}

Scala

Scala的なコーディングでは、withFilterメソッドを使って、「0以上」という条件に合わない値の場合に、Some[A]からNoneへの切替えを行います。

def f(a: Option[Int]): Option[String] = {
  a.withFilter(_ >= 0).map(_.toString)
}

Scalaz

Scalaz流のエレガントな書き方はないと思います。

ノート

前回は以下の表の演算を行いましたが、今回はこれを拡張して:

条件	結果
Option[A]がSome	Some[B]
Option[A]がNone	None

以下の表の演算を行いました。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

「Option[A]に無効な値が入っている」のケースが加わっていますが、この追加が何を意味しているのかというと、成功の文脈だったものをアプリケーションの意思で失敗の文脈に変えることができるということです。
mapメソッドを使うと、成功の文脈における演算を記述することができましたが、成功の文脈を失敗の文脈に切り替えることはできませんでした。
withFilterメソッドは、指定した条件が真の場合はSome[A]を返し、偽の場合はNoneを返します。また、Noneを受け取った場合はそのままNoneを返します。つまりwithFilterメソッドを使うことで、成功の文脈を失敗の文脈に切り替えることができるわけです。
withFilterメソッドは以下の表の演算を行います。

条件	結果
Option[A]に有効な値が入っている	Some[A]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

また、mapメソッドは以下の表の演算を行います。

条件	結果
Option[A]がSome[A]	Some[B]
Option[A]がNone	None

この2つの表を連結すると以下の表になります。

条件	結果
Option[A]に有効な値が入っている	Some[B]
Option[A]に無効な値が入っている	None
Option[A]がNone	None

以上のようにwithFilterメソッドとmapメソッド連結することで、全体として期待した結果が得られます。

withFilterとfilter

withFilterメソッドとほぼ同じ機能を持つfilterメソッドを使っても同じ結果が得られます。
filterメソッドとwithFilterメソッドは、指定された条件でOptionの値をフィルタリングして、条件に合わない場合は成功の文脈(Some[A])から失敗の文脈(None)に切り替える点は同じです。
異なるのは、filterメソッドはOption[A]を返すのに対して、withFilterメソッドはWithFilterというオブジェクトを返す点です。WithFilterオブジェクトは、mapメソッドなどつないでいく場合に利用するオブジェクトです。
filterメソッドはメソッドチェインの最後に位置する場合に用いるのに対して、withFilterメソッドはメソッドチェインの内部にあり後続に別のメソッドがつながれる場合に使用します。メソッドチェインの最後に位置する場合は、Option[A]のオブジェクトを生成してこれを返すことになりますが、その後にすぐにmapメソッドなどがつながれる場合は、このOption[A]の生成が無駄になります。このような無駄を省くために用意されているのがwithFilterメソッドです。
filterメソッドとwithFilterメソッドの使い分けがよく分からない場合は、filterメソッドを使っておくと安全です。ただし、若干ですが性能的に不利になります。
filterメソッドとwithFilterメソッドには以上のような機能差があるため、Optionの値をフィルタした後にmapメソッドなどをつないでいく場合は、filterメソッドより高速に動作するwithFilterメソッドを使用するのがテクニックになっています。このためイディオムではwithFilterメソッドを採用しました。

collectメソッドとflatMapメソッド

Optionでは、filter/withFilterと同じような使い方ができるメソッドとしてcollect、filterNotが提供されています。
filterNotメソッドはfilterメソッドと条件式が反対に作用するものです。
collectメソッドは部分関数を用いて、Optionの値を変換しながら、成功の文脈と失敗の文脈の切り替えもできるという優れもののメソッドです。
また、今回のイディオムはより汎用性の高いメソッドであるflatMapを用いて実現することもできます。
collectメソッドとflatMapメソッドを使ったイディオムについて、続けて取り上げていきます。

諸元

Scala 2.9.1
Scalaz 6.0.3

SmartDox 0.2.1 / クラス図の生成埋込み

2012-01-30T08:00:00.000+09:00

SmartDox 0.2.1をリリースしました。
SimpleModelerを使って、CSVからクラス図の画像生成と埋込みができるようになりました。

機能

SmartDox 0.2.1では以下のオプションを提供しています。

オプション	機能
-html5	HTML5生成(試験的)
-html4	HTML4生成
-html3	HTML3生成
-plain	プレインテキスト生成
-pdf	PDF生成
-latex	LaTeX生成
-blogger	Blogger用のHTML生成

基本的にSmartDox 0.2と同じです。
CSVで記述した情報からクラス図の画像を生成して、文書内に埋め込む機能をサポートしました。

サンプル

SmartDox 0.2.1では以下のようなorg-mode文書が扱えます。

#+TITLE: simplemodeler

* SimpleModelerによるクラス図記述

SimpleModelerを使ってCSVでクラス図を
書くことができます。

#+begin_sm_csv images/sm_csv_simplemodel.png
#actor
顧客
個人顧客,,,,,顧客
法人顧客,,,,,顧客
#resource
商品,商品名,,商品区分(第1類;第2類;第3類)
#event
購入する,,顧客;商品
#+end_sm_csv

#+begin_sm_csv images/sm_csv_simplemodel.png で始まるところがCSV言語で記述したクラス図情報です。この記述から自動的にクラス図の画像(png)を生成して文書に埋め込みます。
この文章中にあるCSVからSmartDoxが(SimpleModeler経由で)生成するクラス図画像は以下のものです。

クラス図情報を記述するCSVの文法は次回に説明します。

PDF

クラス図画像の生成はHTMLやプレインテキストの生成時にも行いますが、ここではPDFを例にして生成されたクラス図画像がどのように文書中に埋め込まれるのかをみてみましょう。
PDFの生成は以下のようにして行います。

$ dox -plain sample.dox

2ページのPDFが生成されます。1ページ目はタイトルと目次ですが、2ページ目に以下のように生成されたクラス図が本文に埋め込まれています。

インストール

プログラムの配布は、Scalaで最近注目されているconscriptを使っています。conscriptのインストール方法は以下のページに詳しいです。

conscript - Scala で作られたソフトウェアをインストールするためのツール

Linux, Macであれば、以下のようにすればインストール完了です。

$ curl https://raw.github.com/n8han/conscript/master/setup.sh | sh

conscriptをインストールした後、以下のようにしてSmartDoxをインストールします。

$ cs asami/dox

以下の2つのコマンドがインストールされます。

dox: SmartDoxコマンド
sdoc: SmartDocコマンド(互換用)

依存プロダクト

SmartDoxでは、以下のプロダクトに依存しています。

プロダクト	使用する機能
LaTeX	PDF生成
Graphviz	画像生成
Ditaa	画像生成

プロダクトに依存する機能を使わない場合は必要ありません。

LaTeX

platexコマンドとdvipdfmxコマンドが実行可能になっていれば基本的にはOKです。
Mac OS上でmacportsを使ってインストールしたLaTeXで動作確認しています。他の環境の場合、スタイルファイルなどがない可能性があります。

Graphviz

dotコマンドが実行可能になっていればOKです。
Mac OS上でmacportsを使ってインストールしたGraphvizで動作確認しています。

Ditaa

ditaaコマンドが実行可能になっているか、optlocalsharejavaditaa09.jarのJarファイルが存在していればOKです。
Mac OS上でmacportsを使ってDitaaをインストールすると、optlocalsharejavaditaa09.jarに配置されます。このditaa09.jarを決め打ちで使用しています。(いずれパラメタで指定可能にする予定です。)
それ以外の環境では、シェルスクリプトなどでditaaコマンド(インストールされているJarファイルを呼び出す)を作成してください。

使い方

まだマニュアルがないので、文書フォーマットは org-modeを参考にしてください。あまり難しい文法を使わなければ大体大丈夫だと思います。
org-mode形式で作成した文書から以下のようにしてHTMLやPDFに変換してください。

$ dox -html4 mydoc.dox
$ dox -pdf mydoc.dox

Scala Tips / Option (3)

2012-01-27T08:00:00.000+09:00

Optionから値を取り出すイディオムです。

Optionの値を取り出すのは、Option#getメソッドを使うかパターンマッチングでSome(x)とするのが普通ですが、イディオムとして整理する場合は、適材適所という切り口が重要になるので、もう少し大きな粒度のシーケンスでまとめておきたいところです。

Optionから値を取り出す処理は以下の2つのコーディングパターンのいずれかの構成要素として使われることが多いでしょう。それぞれのケースについて考えていきます。

Option［A］からOption［B］に変換
Option［A］からBに変換

まず、「Option［A］からOption［B］に変換」のイディオムです。Option［A］からOption［B］に変換するケースで注意が必要なのは、Option［A］がSome［A］ではなくNoneだったケースです。この場合は、AからBへの変換処理は行わずNoneにしなければなりません。これを表にまとめると以下のものになります。

条件	結果
Option［A］がSome［A］	Some［B］
Option［A］がNone	None

Optionから値を取るイディオムでは、Noneのケースも包含した形にしておく必要があるというわけです。

以下では、Option［Int］からOption［String］への変換を例に考えてみます。

(分類の基準)

Java風

if式でOption#isDefinedを使って値の有無を判定します。Option#isDefinedとOption#getが泣き別れになるので、あまりよい感触ではありません。

def f(a: Option[Int]): Option[String] = {
  if (a.isDefined) Some(a.get.toString)
  else None
}

Scala風

match式を使うと以下のようになります。こちらの方が綺麗ですね。

def f(a: Option[Int]): Option[String] = {
  a match {
    case Some(b) => Some(b.toString)
    case None => None
  }
}

Scala

Optionの処理にmapメソッドを使うのがScala的なコーディング。mapメソッド内に処理を記述します。(処理を行う関数を引数に指定します。)Noneの場合にはNoneになる、という処理はmapメソッド内で自動的に行ってくれるのがミソです。

def f(a: Option[Int]): Option[String] = {
  a.map(_.toString)
}

Scalaz

Scalaz流のエレガントな書き方はないと思います。

ノート

Optionの心は「成功/失敗の計算文脈」にあります。成功または失敗の状況を文脈として持ちまわるモナドという意味です。ボクが現時点で理解しているOptionの意味ですが、この言葉にピンと来ない場合もあまり気にする必要はありません。

実用的には、この抽象的な概念が具体的にどう役に立つのかという点が重要です。具体的に役に立つコーディングパターン、すなわちイディオムを洗いだしてマスターしておけばよいでしょう。

「成功/失敗の計算文脈」が具体的に何を指すのかという点について、前述した以下のmapメソッドを例に考えてみましょう。

def f(a: Option[Int]): Option[String] = {
  a.map(_.toString)
}

Option#mapメソッドは関数を引数に取りますが、成功の文脈(すなわちSome［Int］の場合)では関数を実行した結果(String)を再度Someに詰め直したもの(Some［String］)を返却値とします。Someに詰め直すということは値を更新しつつ、成功の文脈を引き継ぐということです。

一方、失敗の文脈(すなわちNoneの場合)は何もせず自動的にNoneを返却値とします。つまり、失敗の文脈の処理についてはプログラマは直接指定する必要はなく、Option側で自動的に行ってくれるということです。失敗の文脈が自動的に引き継がれる点は、Java風(if式を使う場合)やScala風(match式を使う場合)と比べてみると違いが明確です。

プログラマの関心が低い方の文脈である失敗の文脈が、Optionが内包しているロジックにより自動的に引き継がれるのがOptionの旨みで、Optionの実現技術であるモナドの威力です。

「ソーシャルメディアマーケティングの基本戦略」のマインドマップとクラス図

2012-01-26T08:00:00.000+09:00

1月21日(土)に横浜モデリング勉強会を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。懇親会では、勉強会でモデル駆動開発のハンズオンみたいなこともどうか、という意見もありました。そちらの方向への展開も考えてみたいと思います。
この勉強会で、浅海が作成したモデルを紹介します。モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)
モデリングの対象は、IT media エンタープライズビジネスイノベーション誌に掲載された小川浩氏の記事「ソーシャルメディアマーケティングの基本戦略」です。前回、前々回は経済ネタだったのですが、今回はITエンジニアにも親和性の高いソーシャルメディアのマーケッティングをテーマにしてみました。

単語を抜き出す

まず、最初の作業で記事中から単語を抜き出します。単語を抜き出しながら、登場人物、道具、出来事を中心にMindmapModelingの定めた分類に従って仕分けしていきます。
この結果、できた最初のマインドマップが以下のものです。(以下、図をクリックすると拡大します。)

記事の内容がソーシャルメディアマーケッティングの構造についてなので、そのあたりに単語が集中しています。

関係の洗練

次の段階では、抽出した、登場人物、道具、出来事の洗練を行います。用語の名寄せ、用語の種類(generalization)や部品構成(aggregation)を整理していきます。また、この段階で区分(powertype)の抽出を開始します。
以上の作業を行った結果のマインドマップは以下のものです。

SimpleModelerのサービスを使用して作成したクラス図は以下のものになります。

今回は、ソーシャルメディアマーケッティングについての区分を整理を中心に作業しました。自然言語の文章としては意味が通っても、モデルの用語としては曖昧なところが出てくるのでそういった点を補ったり、MECE(Mutually Exclusive and Collectivily Exhausitive、もれなくだぶりなく)を念頭に区分の中身を整理しました。

出来事と物語

SimpleModelerのサービスを使用して作成したクラス図は以下のものになります。

今回は、よい物語が思い浮かばなかったので、出来事と規則を中心に洗練を進めました。
また、ソーシャルメディアマーケッティングの手法として、記事中で明示的に列挙してあった(1)ペイパーポスト、(2)クチコミを分析、(3)情報発信だけでなく、記事中の他の場所にばらばらに書いてあった(4)コールセンター、(5)対面販売、(6)イベント応募も加えています。
このように著者が形式知として明示したものにも案外抜けがあるものです。これを記事中から拾い集めてきて形式知化し、情報の再構成を行うのがMindmapModelingの目的です。
以上が勉強会での作業です。

仕上げ

最後にドメインモデルの形に仕上げることにしましょう。SimpleModelerを使用して作成したクラス図を見ながら調整していきます。
ついでなのでSimpleModelerの機能を拡張して、より適切なクラス図が表示されるようにしてみました。来週ぐらいにSimpleModelerのサービスを新しいバージョンのSimpleModelerにアップグレードしたいと思います。
以上の作業で作成したマインドマップとクラス図は以下のものになります。

かなりドメインモデルとして整理されました。ドメインモデルがこのレベルの情報を持つようになると、クラス図ベースでモデルの推敲をはじめても大丈夫です。
生成されたクラス図をみてみると、たとえば「市場シェアが二番手、三番手の企業が大域的な市場シェアを奪うためにソーシャルマーケティングを行う」という物語(Business UseCase)を作成し、この物語を軸にモデルの精度をあげると面白いのではないか、とか色々とイメージが湧いてきますね。
初見のモデリングでは、推敲のベースとなる初期モデルを作るのがなかなか大変なので、MindmapModeling→クラス図のアプローチはなかなか有力ではないかと思います。

Scala Tips / null

2012-01-25T08:00:00.000+09:00

null値の可能性がある値をnull値ではない普通の値に持ち上げるイディオムです。

(分類の基準)

Java風

if式で変数がnullかどうかを判定します。

def f(a: String, b: String): String = {
  if (a == null) b
  else a
}

実際に使う時は以下のような感じになります。

val c = if (a == null) b else a

Scala風

match式を使う時は以下のようになります。この場合は、Java風の方が簡潔ですね。

def f(a: String, b: String): String = {
  a match {
    case null => b
    case _ => a
  }
}

Scala

OptionとOption#getOrElseを使うと簡潔に記述できます。

def f(a: String, b: String): String = {
  Option(a) getOrElse b
}

Scalaz

Scalazを使うと、さらに簡潔に記述することができます。

def f(a: String, b: String): String = {
  a ?? b
}

以下のような形でメソッドの引数に書きたい場合は、"??"を使った簡潔な記述方法は重宝します。

val a = SomeJavaObject.getStringValue()
println("Value is " + a ?? "unknown")

ノート

プログラムの実行速度という観点では、「Java風」が一番速く、「Scala」はオブジェクト生成とメソッド呼出しが余分に発生するためかなり遅くなります。「Scalaz」は、さらに一段余分にオブジェクト生成とメソッド呼出しが発生するため、さらに低速です。

つまり、Javaの実行速度とScalaの記述力のトレードオフが発生するわけです。実行速度を採るのであればJavaで書けばよいので、Scalaで書く以上、簡潔に記述できることを重視するのがよいでしょう。

まずScalaで書いてみて、プロファイルでホットスポットと判明した処理については、Java風に書き直したり、Java(場合によってはC++)で書いて呼び出すというアプローチになります。

Scala Tips / Option (2)

2012-01-24T08:00:00.000+09:00

null値の可能性がある値をOptionに持ち上げるイディオムです。

Scalaでは、できるだけnull値を使わないようにするのが、プログラミングのコツになっています。そのため、既存のJavaプログラムから戻ってきた値などを速やかにOptionに持ち上げる、といった処理がよく出てきます。この処理を簡潔に書けるイディオムを覚えておくとプログラミングがスムーズになります。

(分類の基準)

Java風

if式で変数がnullかどうかを判定します。

def f(a: String): Option[String] = {
  if (a == null) None
  else Some(a)
}

実際に使う時は以下のような感じになります。

val b = if (a == null) None else Some(a)

Scala風

match式を使うこ以下のようになります。この場合は、Java風の方が簡潔ですね。

def f(a: String): Option[String] = {
  a match {
    case null => None
    case _ => Some(a)
  }
}

Scala

Optionオブジェクトに目的にぴったりあうメソッドapplyがあるので、これを使うのがイディオム。Option(a)は、Optionオブジェクトのapplyメソッドを呼び出す簡略記法です。

def f(a: String): Option[String] = {
  Option(a)
}

Optionの持つ基本機能なのでイディオムというのも大げさですが、ボクも長年この使い方を知らずに損なコーディングをしていたので、イディオムとしてまとめておきました。(Scala 2.8でサポートされた機能のようです。)

パッと見は Option(null) とすると Some(null) が返ってきそうですが、None が返って来てくれるということですね。Some(null) が欲しい場合には、文字通り Some(null) とします。

Scalaz

Scalaz流のエレガントな書き方はないと思います。

利用シーン

Scalaでnullを使いたいユースケースとして、メソッドのデフォルト値があります。(いずれイディオムとして取り上げたいと思います。)

case class Person(name: String, address: Option[String])

object Person {
  def apply(name: String, address: String = null) = {
    new Person(name, Option(address))
  }
}

ここを以下のようにしたくないということですね。

new Person(name, if (address == null) None else Some(address))

SmartDox 0.2

2012-01-23T08:00:00.000+09:00

SmartDox 0.2をリリースしました。
PDF、プレインテキスト、HTML4の生成をサポートしました。また、GraphvizやDitaaを使った画像の生成と埋込みもできるようになりました。
エラー処理などがまだ柔らかいですが、ある程度使えるレベルのものになってきたと思います。

機能

SmartDox 0.2では以下のオプションを提供しました。

オプション	機能
-html5	HTML5生成(試験的)
-html4	HTML4生成
-html3	HTML3生成
-plain	プレインテキスト生成
-pdf	PDF生成
-latex	LaTeX生成
-blogger	Blogger用のHTML生成

html4, html3, plain, pdf, latexはSmartDocのエンジンを使用しています。
html5とbloggerはSmartDoxで新規に開発を進めたものです。
html5は試験的な簡単な実装の段階です。
bloggerは、このブログでも使用しているBloggerでブログを書くときに使用するHTMLを生成します。生成したHTMLをBloggerのHTMLエディタに手動で貼り付けて使用します。前回のエントリから、このbloggerオプションを使用しています。
また、Dot言語(Graphviz)とDitaa言語で記述した画像を生成して、文書内に埋め込む機能をサポートしました。

インストール

プログラムの配布は、Scalaで最近注目されているconscriptを使っています。conscriptのインストール方法は以下のページに詳しいです。

conscript - Scala で作られたソフトウェアをインストールするためのツール

Linux, Macであれば、以下のようにすればインストール完了です。

$ curl https://raw.github.com/n8han/conscript/master/setup.sh | sh

conscriptをインストールした後、以下のようにしてSmartDoxをインストールします。

$ cs asami/dox

以下の2つのコマンドがインストールされます。

dox: SmartDoxコマンド
sdoc: SmartDocコマンド(互換用)

依存プロダクト

SmartDoxでは、以下のプロダクトに依存しています。

プロダクト	使用する機能
LaTeX	PDF生成
Graphviz	Dot言語画像生成
Ditaa	Ditaa言語画像生成

プロダクトに依存する機能を使わない場合は必要ありません。

LaTeX

Graphviz

dotコマンドが実行可能になっていればOKです。
Mac OS上でmacportsを使ってインストールしたGraphvizで動作確認しています。

Ditaa

ditaaコマンドが実行可能になっているか、/opt/local/share/java/ditaa0_9.jarのJarファイルが存在していればOKです。
Mac OS上でmacportsを使ってDitaaをインストールすると、/opt/local/share/java/ditaa0_9.jarに配置されます。このditaa0_9.jarを決め打ちで使用しています。(いずれパラメタで指定可能にする予定です。)
それ以外の環境では、シェルスクリプトなどでditaaコマンド(インストールされているJarファイルを呼び出す)を作成してください。

使い方

$ dox -html4 mydoc.dox
$ dox -pdf mydoc.dox

サンプル

SmartDox 0.2では以下のようなorg-mode文書が扱えます。

#+title: SmartDoxサンプル
#+author: 浅海
#+date: 2012年1月22日

* 文章

これは *SmartDox* の文章です。

- SmartDoxのコンセプトは(org-mode＋html5)／2
- HTMLに加えてPDFやプレインテキストを生成することができます。
- GraphvizやDitaaの画像を生成して埋め込むことができます。

* 表

| オプション | 機能                 |
|------------+----------------------|
| -html5     | HTML5生成(試験的)    |
| -html4     | HTML4生成            |
| -html3     | HTML3生成            |
| -plain     | プレインテキスト生成 |
| -pdf       | PDF生成              |
| -latex     | LaTeX生成            |
| -blogger   | Blogger用のHTML生成  |

* 画像

** graphviz

[[http://www.graphviz.org/][Graphviz]] の図を直接書くことができます。

#+begin_dot images/dot_example.png -Tpng
digraph G {
  Hello->World
}
#+end_dot

** ditaa

[[http://ditaa.sourceforge.net/][Ditaa]] の図を直接書くことができます。

#+begin_ditaa images/ditaa_example.png
+--------+   +-------+    +-------+
|        | --+ ditaa +--> |       |
|  Text  |   +-------+    |diagram|
|Document|   |!magic!|    |       |
|     {d}|   |       |    |       |
+---+----+   +-------+    +-------+
    :                         ^
    |       Lots of work      |
    +-------------------------+
#+end_ditaa

「#+begin_dot images/dot_example.png -Tpng」で始まるところがGraphviz言語で記述した画像、「#+begin_ditaa images/ditaa_example.png」で始まるところがDitaa言語で記述した画像です。この記述から自動的に画像(png)を生成して文書に埋め込みます。

PDF

PDFの生成は以下のようにして行います。

$ dox -plain sample.dox

以下の3つのページから構成されるPDFが生成されます。

プレインテキスト　

プレインテキストの生成は以下のようにして行います。

$ dox -plain sample.dox

以下のプレインテキストが生成されます。

Scala Tips/Option

2012-01-20T22:59:00.000+09:00

プログラミング言語の習得で重要なことの一つは、局面ごとに使うイディオムを体で覚えて無意識に出てくるようにすることです。

Scalaでのイディオムも少し見えてきたので、少しずつ整理していきたいと思います。

基本文法を覚えたての知識でのコーディングからScalazまでを併置するようにしました。以下のような分類にしています。

Java風: Javaプログラミングの感覚でコーディングしたもの
Scala風: Scalaらしい文法を使っているが、少し泥臭い感じ
Scala: Scalaでのイディオム
Scalaz: Scalazでのイディオム

Java風、Scala風は問題を明確にするための参考情報で、ScalaまたはScalazが推奨の方法です。

今回は、Optionから値を取り出す時に、Noneの場合デフォルト値を使用する方法です。

Java風

if式でOptionのisDefinedメソッドを判定します。安全確実ですが、if式、Option#isDefined、Option#getが出てきたら、Scala的にはちょっと負けっぽい。

Option#isDefinedとOption#getが何かの拍子で泣き別れになるとバグの元になるので、この組合せはできるだけ避けたいわけです。

def f(a: Option[Int]): Int = {
  if (a.isDefined) a.get
  else 0
}

Scala風

match式を使うことで、if式、Option#isDefined、Option#getが見えなくなりました。ただ、やろうとしていることに対して記述がやや冗長な感触です。

def f(a: Option[Int]): Int = {
  a match {
    case Some(b) => b
    case None => 0
  }
}

Scala

Optionに目的にぴったりあうメソッドgetOrElseがあるので、これを使うのがイディオム。事前に用意されているメソッドを使うだけなのでイディオムと呼ぶのはやや大げさですが、ユースケースに対する解を、考えて分かるのではなく、無意識に出てくるのが大事なので、イディオムとして取り上げています。

def f(a: Option[Int]): Int = {
  a getOrElse 0
}

Scalaz

Scalazの場合は"|"でデフォルト値をより簡潔に記述することができます。

def f(a: Option[Int]): Int = {
  a | 0
}

SmartDoxの実装技術

2012-01-11T10:47:00.002+09:00

昨日はSmartDoxの紹介をしましたが、今日はSmartDoxの実装技術について説明します。
既存のプログラムの改良では、今まで積み上げてきたアーキテクチャや使っているフレームワークの関係があって、思い切ったコーディング方針の変更はなかなかできません。
SmartDoxは新規開発なので、練習も兼ねてボクが認識している今風のScalaプログラミングを取り入れてみました。

Scala
sbt
conscript
GitHub
関数型プログラミング
代数データ構造
Scalaz
パーサーコンビネータ

Scala, sbt

実装言語Scala、ビルドツールsbtは現在の既定路線です。
sbtは、後発だけあって何かと使いやすいのと、Scalaプログラミング特有の色々な事情をハンドリングしてくれるので、Scalaプログラミングでは必須です。
たとえば、Scalaは、コンパイルしたScalaバージョンの異なるライブラリのバイナリ互換が鬼門で、JavaだとJARファイルがlibname-1.0.jarとなるところを、Scalaだとlibname₂.9.1-0.1.jarといった具合に使用するScalaライブラリのバージョン(2.9.1)をファイル名に埋め込むのが、基本的な運用になっていますが、sbtはこのあたりをうまくハンドリングしてくれます。
編集、デバッグにはEclipseを使っていますが、sbtのEclipseプラグインで「.classpath」を生成して、ライブラリの依存性を取り込む運用にしています。
ただし、sbtだけでは力不足のところもあります。以下の処理はsbtでやり方を見つけられなかったのでmavenとantを併用しています。

JavaのみのプロジェクトのJar作成(2.9.1を付けないJar名)
FTPによるmavenリポジトリへのアップロード(sftpならできるのですが、昔ながらのftpはダメみたい)

conscript

SmartDoxのインストールにはconscriptを使いました。
conscriptはGitHubに格納したアプリケーションの構成情報を使用して、アプリケーションの依存関係を解決した上でローカル環境にインストールしてくれるインストーラです。
プログラムの提供側、利用者側のどちらもかなり便利なので、これから広く使われるようになるのではないかと思います。

GitHub

ソースコードの管理はGitHubを使っています。GitHubはUIが使いやすいので、このところ新規プログラムはGitHub上で開発していますが、SmartDoxの場合は、conscriptを使うというためという理由もあります。
GitHubは、ソースコードのバージョン管理という枠組みを超えて、conscriptのような形でソフトウェアリポジトリ的な使われ方もしてきています。こういう新しい応用が出てくるので、使っていて刺激的ですね。

関数型プログラミング

関数型プログラミングは、ボクがLispをかじっていた頃(25年ぐらい前)はラムダ計算をベースに、List、クロージャといった部品を使ってプログラミングしていくものでしたが(さらにいうと綺麗につくると性能がでないので、手続き型的なプログラミングにしたり、nreverseといった破壊的な関数を使うのがバッドノウハウ)、現在は状況が一変しています。
まずハードウェア性能の向上で、関数型言語の宿命だった動作性能は事実上あまり問題にならなくなっています。Javaを使って大丈夫な用途であればScalaでも基本的には大丈夫と考えてよいでしょう。RubyやPythonで大丈夫な用途であれば、Scalaだと逆に高速に動作しそうです。
技術的には、モナド、型クラスという新しい技術が登場し、これが新しい関数型プログラミングの基盤になっています。
ボクも2008年にScalaを始める前は、昔の関数型プログラミングのイメージで関数型言語を捉えていたのですが(List処理が便利で開発効率がアップとか)、現在では全く別物と考えています。モナド、型クラスはそれだけのインパクトのある技術ということが分かりました。いつの間にか、こんなことになっていたのか、という感じです。
さらに、Scalaでは関数型プログラミング(FP)とオブジェクト指向プログラミング(OOP)の融合したObject-Functional Programming(OFP)という概念が提唱しています。
歴史的な蓄積やOOADからの連続性を考えると、OOPは今後も軸の一つで在り続けることになると予想されます。ここにFPの記述力をどのように融合させていくのかということが、実務の世界では非常に重要になるのは明らかで、OFPはこれは今後大発展する分野と考えています。
このあたりを意識しつつSmartDoxの開発では、今風のFP的な技術をできるだけ使うことにしました。

代数的データ型

まずデータ構造として、代数的データ型(Algebraic data type)を使用します。Scalaでは、代数的データ型は直接サポートされていませんが、case classがこの目的での利用を想定して提供されています。たとえばA Scala Tutorial for Java programmersにも以下の記述があります。このあたりの背景は、Object-Oriented Pattern Matchingに詳しいようです。

In Java, such a tree would be represented using an abstract super-class for the trees,
and one concrete sub-class per node or leaf. In a functional programming language,
one would use an algebraic data-type for the same purpose. Scala provides the concept of case classes which is somewhat in between the two

今までは、内部データ構造はオブジェクト指向的な作り方にしていたわけですが、SmartDoxではcase classを使ってimmutableな構造をにしてみました。
オブジェクト指向的な作りの場合、可変オブジェクトを複数のコンポーネントで共有して少しづつ変更を加えていくプログラミングモデルになりますが、代数的データ型(case class&immutable)にすると、コンポーネントで全複写しながら変換するプログラミングモデルになります。immutableにすると、なにか不測の事態があったときの回避方法が限られるためOOP派的には非常に怖い選択ですが、FPでは避けて通れない道です。
SmartDoxでは、このプログラミングモデルにチャレンジしてみたわけです。今の所、特に問題もなく、このプログラミングモデルでもやっていけそうな感触を得ています。
また、代数的データ構造を取っても、いざという時には型クラスの技法を使って色々細工ができそうという読みもありました。なにか問題が出てきたら試してみようと思っています。

Scalaz

Scalazは、型クラスと純粋関数型データ構造を提供するScalaライブラリです。Scalaの暗黙型変換、暗黙パラメータの機能を利用してHaskell的な型クラスを提供しています。
Scalaプログラミングを足掛け4年程やってきて分かってきたのは、FPは関数の合成でプログラミングしていくのがコツということです。Scalaでも提供されているMonadという仕組みは、この関数合成のメカニズムの一種で普通の関数合成(composeやandThen, orElseなど)よりもより強力な関数合成を可能にします。このMonadを活用したプログラミングスタイルをMonadicプログラミングと呼ぶようです。
Scalaの基本機能にもMonadはあるので、ScalaだけでもMonadicプログラミングはできるのですが、Scalazの強力な型クラス群を使用すると、さらに強力なMonadicプログラミングを行うことができるようになります。
Scalazが用意している型クラスはたとえば、Monoid, Functor, Applicative Functor, Monadといったもので、MonadをKleisli圏で合成するようなこともできるようになっています。このあたりの型クラスを手足のように使えるようになるのが現在目標としていることで、そのためにSmartDoxではできるだけScalazを使ってプログラミングする方針にしています。
Scalazを使うもう一つの効用は、Scalaで型クラスを使うためのよいお手本になるということ。Scalaでは、型クラスの機能は直接サポートされておらず、暗黙パラメタ、暗黙変換の機能を駆使して実装する必要があります。この実装技術をScalazで学ぶことができます。
型クラスは、フレームワークと実装クラスを疎結合に保ちつつ(静的な)多態性を可能にする非常に強力な言語機能と理解しています。Scalazの技法を使えば、Scalaでも型クラスを使ったプログラミングが可能になるわけで、いずれ自分のプログラミング技法に取り入れたいと考えています。

パーサーコンビネータ

SmartDoxでは、SmartDox文書のパースにパーサーコンビネータを使ってみましたが、驚くほど簡単にパーサーを書くことができることが分かりました。
パーサーの記述はBNF的なDSLになっていますが、基本的な動きとしてはMonadicでかつApplicativeという感じです。Parser[T]を返す関数がMonadic的な動き、その中で「^^」メソッドに渡すクロージャがApplicative的な動きと思います。
簡単なパーサーであれば、BNF的DSLという理解の範囲で使えますが、細かいことをしようとするとMonadicかつApplicativeな動きを理解していないと辛そうです。パーサーコンビネータをある程度使いこなせるようになったのも、Scalazを使ってMonadicプログラミングに慣れてきた効用かなと思います。
パーサーコンビネータを使っていて分かったのは、パーサーコンビネータは文字列以外にも使えるということ。DOMなどのXML木やマイ代数的データ型からパターンマッチングで構造を抽出してドメインモデルを構築するという用途には簡単に適用できそうです。翻って考えてみればこのあたりがMonadicプログラミングの威力ですね。

以上、SmartDoxを素材にScala+Scalazを中心としたFP技術を概観してきました。15年前はC→Javaによって、OOPがメインストリームのプログラミングパラダイムになりプログラミングの生産性が大きく向上しました。それと同等の大きなムーブメントがFPの本格導入により起こりそうです。もちろん前述したように、OOPは今後も軸の一つとなり続けるでしょうから、OOPとFPを融合した新しいプログラミングパラダイムという形になるでしょう。
最後にどのプログラミング言語が残るのかは分かりませんが、現時点ではScala+Scalazで技を磨いておくのが有力な選択肢だと思います。

SmartDox

2012-01-10T12:29:00.000+09:00

年末年始はまとまった時間が取れたこともあって、以前から構想していた文書処理アプリケーションのSmartDoxを作ってみました。まだ、実用レベルではないですが一応ミニマムな実装が動いたところです。

SmartDoxは、1998年から作り続けているSmartDocの後継バージョンです。SmartDoc2という名前でもよかったのですが、smartdox.orgというドメイン名が取れたのでSmartDoxにしてみました。SmartDocの場合、ドメイン名にxmlsmartdoc.orgを使っているのですが、SmartDoxでは「XML」が必須でなくなるので「XML」の文言のないドメイン名を新しく使うことにしました。

動機

1998年にSmartDocを作る時も、プレインテキストベース(当時だとsetext、今だとSphinxあたりが候補)にするかXMLベースにするかという選択があったのですが、プレインテキストベースだとパーサーを書くのが大変だったのと、当時のプレインテキストベースのマークアップ言語だと表組みや画像をマークアップする方法がなかったこともあって、XMLを選択しました。Emacsのsdoc-mode(sgml-modeを拡張)を使えば、XMLといっても入力、編集は問題ないので、SmartDocは現在まで使い続けています。

ではなぜSmartDocの新バージョンを作ることにしたのかというと以下の理由があります。

org-modeが構造化プレインテキストワープロであることが分かった
SimpleModelerで、モデルの仕様記述
自作アプリケーションで文章を扱うときの受け皿
Evernoteでの文書編集
iPad, iPhoneからの文書編集

org-mode

org-modeは、Emacs上で動作するアウトラインプロセッサです。アウトラインプロセッサはMindmapModelingとの親和性も高そうなので、以前からOmni Outlinerやorg-modeを調べていたのですが、年末にorg-modeを触っていて、実は大変すごいことになっていることが判明しました。org-modeは、アウトラインプロセッシング機能を持った構造化プレインテキストワープロと呼んでも差し支えないEmacsアプリケーションだったのです。

特に驚愕したのは以下の機能。

Emacsをメインに使いながら今まで気づかなかったのは不覚でした。

org-modeの威力を目の当たりにし、今まで懸案にしていた色々なミッシングリンクが繋がってきました。そこで得たインスピレーションをベースにSmartDox開発を開始することにしたわけです。

SimpleModelerで、モデルの仕様記述

SimpleModelerは、テキストDSLでモデルを記述し、このモデルからAppEngineやAndroidのアプリケーション(ドメインモデル+α)を生成するモデルコンパイラです。SimpleModelerでは、クラス図や状態遷移図/表を含んだ仕様書生成も行いますが、この仕様書で使用する自然言語による仕様記述の記述方法が懸案事項になっていました。SmartDocをベースにした記述方式を仮実装していたのですが、これをオーバーホールし、新規に本格的な文書処理系で実現するのがSmartDoxの目的の一つです。

自作アプリケーションで文章を扱うときの受け皿

SimpleModelerに限らず、自作アプリケーションで文章を扱いたいというニーズは色々あります。たとえば、ヘルプとして構造を持った長めの文章を表示したいとか、そういう細々した用途です。

この目的で、org-mode文書を操作するScalaコンポーネントを用意しておきたいというのが、SmartDoxの目的の一つです。ボクが開発するアプリケーションはgoldenportというアプリケーションフレームワーク上に構築していますが、SmartDoxのコアはgoldenportからも切り離して、より汎用的な部品として使用できるようなアーキテクチャにしています。もちろんgoldenportでもSmartDoxに対応してSmartDoxをアプリケーションに容易に組み込む枠組みを提供する予定です。

Evernoteでの文書編集

ノートやアイデアの管理にEvernoteを使っていますが、Evernoteのエディタが今ひとつ使いづらいのと、Evernoteで記録した情報の再利用という目的で、Evernoteのエディタでも使用できる構造化プレインテキストの導入を考えていました。この目的にSmartDox文書を使用します。

また、Evernote APIを使ってSmartDox文書を格納したEvernoteノートの操作など、色々と面白い応用がありそうです。

iPad, iPhoneからの文書編集

最近はiPadやiPhoneからTextforceを用いてDropbox上のテキスト文書を編集する運用を行っています。

PCからはEmacsを使うのでXML系のテキスト文書でも問題はないのですが、Textforce(のようなプレインなテキストエディタ)でXML文書を編集するのはかなり辛いので、構造化プレインテキストの導入を考えていました。Evernoteの場合と同様に、ここもSmartDox文章がぴったりはまりそうです。

コンセプト

SmartDoxのコンセプトは、「(HTML5 + org-mode) / 2」です。(SmartDocのコンセプトは、「(HTML + LaTeX) / 2」で、これをXML上に構築していました。)

SmartDoxは、HTML5とorg-modeをごちゃまぜにした記述方式にしました。HTML5のサブセットとorg-modeのサブセットを合体させた文法にしています。(という予定です。現在はorg-mode上に一部HTML5を取り込んでいます。)

普通の範囲のHTML5文書をHTMLエディタで編集したテキスト、普通の範囲のorg-mode文書をEmacs上のorg-modeで編集したテキストの両方からHTML、プレインテキスト、LaTeX、PDFを生成します。(という予定です。)また、同一文章にHTML5とorg-modeを混在させ、さらにSmartDox専用の記述方式で技術文書向けの便利な指定も可能にします。

具体的には、以下のような記述になります。

* SmartDox文書

これは<b>SmartDox</b>文書です。

<!DOCTYPE html>
<html>
<head><title>SmartDox文書</title></head>
<body>
<section><h2>SmartDox文書</h2>
<p>これは*SmartDox*文書です。</p>
</section>
</body>
</html>

org-modeを主体にして、細かい指定が必要なところはHTML5やSmartDox専用記述方式を併用するという運用イメージです。

インストール

プログラムの配布方法は、Scalaで最近注目されているconscriptにしました。conscriptのインストール方法は以下のページに詳しいです。

conscript - Scala で作られたソフトウェアをインストールするためのツール

Linux/Macであれば、以下のようにすればインストール完了です。

$ curl https://raw.github.com/n8han/conscript/master/setup.sh | sh

conscriptをインストールした後、以下のようにしてSmartDoxをインストールします。

$ cs asami/dox

以下の2つのコマンドがインストールされます。

dox: SmartDoxコマンド
sdoc: SmartDocコマンド(互換用)

確認

SmartDoxの文章として以下のものをsample.orgという名前で用意します。

* 最初の章

最初の章の文章。

** 最初の節

最初の節の文章。

*** 最初の小節

最初の小節の文章。

| 名前 | 住所 |
|------+------|
| 太郎 | 横浜 |
| 花子 | 東京 |

以下のようにSmartDoxのdoxコマンドを起動し、HTML5文書らしきものがsample.htmlで生成されればインストール成功です。(デバッグ用のスナップショットが出力されますが、ご愛嬌ということで)

$ dox -html5 sample.org

SmartDoxは、まだPoC(Proof of Concept)の段階ですが、ボクが日々の作業の中で色々と作り足していく予定なので、いずれそれなりに機能が充実してくると思います。その時になったらぜひ試してみてください。

ScalazでBean Validation

2011-12-23T15:02:00.000+09:00

このエントリはScala Advent Calender 2011の第23日目です。

Java業界で今年最大のニュースといえば、Oracle Open Worldで発表されたOracleのクラウド参入を上げる人も多いでしょう。OracleのPaaSが成功するのかどうかは未知数ですが、Java EEがPaaSのプラットフォームとして強力に推進されることは確実で、Java VM系での標準コンテナ仕様になるとみて間違いないと思います。

現状では、WebアプリケーションをJavaで作る場合TomcatやJettyなどの生ServletにSpringなどのフレームワークを載せて使うのが一般的で、Java EEのEJBはあまり使われていません。Java EEからEJBを引くと生Servletになるのであれば、Java EE仕様はあまり関係なくて、今まで通りTomcatやJettyベースでよいことになります。

しかし、実はJava EEのプラットフォームも地味に進歩してきていて、Java EEからEJB(のフルスペックやその他管理系の機能)を引いた部分の機能がかなり大きくなってきており、生Servletとの乖離が大きくなっています。この部分は、Java EEのWeb Profileとして仕様化もされています。Java EEのフルスペックは大変ですが、Web Profileなら使用頻度とのバランス的にリーズナブルな大きさであり、このWeb ProfileがJava VM系のPaaS標準仕様になると予想されるわけです。

ScalaもJava VM上で動作させることが普通なので、Javaプラットフォームの進化とは切っても切れない関係です。そういうわけでScalaでクラウドアプリケーションを書く場合も、Java EEのWeb Profileを念頭に置いておきたいところです。

Web Profileではいくつか重要な機能が追加されていますが、その一つがBean Validationです。Bean Validationは、Java Beansのプロパティを検証する機能です。プロパティ(属性やメソッド)に対するアノテーションで指定された値の値域と実際に格納されている値がマッチしているか検証してくれます。この機能は、普通のJava SEベースのプログラムでも利用したいぐらいの便利な機能で、たまたまJava EEの枠組みで仕様化されていますが、事実上Javaの標準機能といえます。(Jarを追加すればJava SE上でも簡単に使えます。) そういう意味でもScalaプログラミングにも積極的に取り入れたいところです。

さて、ScalaでValidationといえばScalaz Validationですね(笑)。

Scalaz Validationは、applicative functorとして実現されたValidationクラスを中心とした機能で、いわゆるapplicative styleというプログラミングスタイルで、正常系処理と異常系処理を綺麗に取り扱うメカニズムを提供します。

Scalaでクラウドアプリケーションを作る場合、Beans ValidationとScalaz Validationを併用するのが望ましいことはいうまでもありません。そこで、この2つのValidationシステムを統一的に扱うためのプログラミング方法を試行することにしました。

Person

まず、検証対象となるクラスをPersonを定義します。通常のScalaクラスですが、属性に@NotNullや@Size(min=1)といったアノテーションがつけられている点がBean Validationのための追加点です。

class Person(nm: String, ag: Int, ad: Option[String]) {
  @NotNull @Size(min=1)
  val name: String = nm
  @Min(0) @Max(150)
  val age: Int = ag;
  @NotNull // Option内の判定はできない
  val address: Option[String] = ad
}

本来は、case classを使いたいところですが、コンストラクタの引数につけたアノテーションをBean Validationは認識してくれないみたいなので、泣く泣くこの実装にしています。これは、ScalaからBean Validationを使うときの要注意項目ですね。

また、Optionの中身はBean Validationの基本機能では扱えないので、より本格的に作り込む場合は、カスタムのバリデーターを作る必要があります。

Personのコンパニオンオブジェクト

次に、Personクラスを操作するための関数を集めたコンパニオンオブジェクトPersonを定義します。ここで、Bean ValidationとScalaz Validationを接続する処理を実現します。

以下では、プログラムに直接コメントしていきます。

object Person {
  // Scalaでは、型名が長くなることが多いので、よく使うものはtypeで定義しておくとよい。
  type ViolationNelA[A] = NonEmptyList[ConstraintViolation[A]]
  type ViolationNel = ViolationNelA[Person]
  type ValidationB[B] = Validation[ViolationNel, B]

  // javax.validationパッケージからBeanValidationのValidatorを取得。
  val validator = {
    // Validationがscalaz.Validationと重なるので、BeanValidationという名前で取り込む。
    import javax.validation.{Validation => BeanValidation}
    val vf = BeanValidation.buildDefaultValidatorFactory()
    vf.getValidator()
  }

  def isValid(p: Person) = validate(p).isEmpty

  // Bean Validatorを使って、Personオブジェクトの検証を行う。
  // asScala.toListでScalaのListに格納する。
  // ConstraintViolationはBean Validatorが検出した異常情報。
  def validate(p: Person): List[ConstraintViolation[Person]] = {
    validator.validate(p).asScala.toList
  }

  // 指定された値からPersonオブジェクトを生成する。成功した場合はscalaz.SuccessにPersonオブジェクトを、失敗した場合はscalaz.FailureにConstraintViolationのリストを格納する。
  // scalaz.Successとscalaz.FailureはScalaz.Validationのサブクラスでそれぞれ検証の成功と失敗を示す。
  // この関数でBean Validationの結果をScalaz Validation化している。
  def createV(name: String, age: Int, address: Option[String]): ValidationB[Person] = {
    val p = new Person(name, age, address)
    validate(p) match {
      case vs if vs.isEmpty => p.success
      // vs.toNel.get.failといったものがScalaz的な書き方。コンパクトに記述できる。
      case vs => vs.toNel.get.fail
    }
  }

  // Bean Validationは、Java Beanに値を設定した後にしか使えない。
  // Webアプリなどで、生文字列からJava Beansを生成する場合、文字列が適切な値に変換できないため、そもそもJava Beansを生成できないケースもある。そのケースを取り扱うため、文字列からの値変換に失敗した場合はその時点でエラー、Java Beansを生成後はBean Validatorで検証し、いずれの場合も結果はscalaz.Validationで通知する。
  def createVFromStrings(name: String, age: String, address: String): Validation[NonEmptyList[String], Person] = {
    // 型名が長くなりがちなので、内部関数やvalで吸収する。
    // 名前はコメントをつける気持ちでつけるとよい。
    def parseint(s: String, name: String) = s.parseInt match {
      case Success(a) => a.success[NonEmptyList[String]]
      case Failure(e) => violationmsg(name, s, e.getMessage).fail.liftFailNel
    }
    def parsestring(a: String, name: String) = a.success[String].liftFailNel
    def parseoption[T](a: Option[T], name: String) = a.success[String].liftFailNel
    def constraintviolation2string(cv: ConstraintViolation[Person]) = {
      violationmsg(cv.getPropertyPath.toString, cv.getInvalidValue.toString, cv.getMessage)
    }
    def violationmsg(path: String, value: String, msg: String) = {
      "%s = %s: %s".format(path, value, msg)
    }
    // ロジックの中心は内部関数を使ってコンパクトに書く
    (parsestring(name, "name") |@| parseint(age, "age") |@| parseoption(Option(address), "address"))(createV(_, _, _)) match {
      case Success(Success(a)) => a.success[String].liftFailNel
      case Success(Failure(e)) => e.map(constraintviolation2string(_)).fail
      case Failure(e) => e.fail[Person]
    }
  }

  // List[ValidationB[Person]]をValidationB[List[Person]]に変換。型クラスTraverseと似たような動き。
  // TraverseでValidationをうまく扱うことができなかったので、foldrで実装してみた。
  // 「(s <**> p)(_ :: _)」の所がapplicative styleのプログラミング。ValidationがSuccessの場合に走るロジック(正常処理)を記述する。ValidationがFailureの場合(異常処理)は、applicative functorであるValidationのコンテナ側が実装している裏ロジック(?)が走って、monoidとして実現されているエラー情報を蓄積していく。
// applicative functorのメカニズムを用いることでプログラマが記述する正常系ロジックとValidationが自動的に実行する異常系ロジックを綺麗に分離できる。
  def sequenceV(persons: List[ValidationB[Person]]): ValidationB[List[Person]] = {
    persons.foldr(mzero[List[Person]].success[ViolationNel])((s, p) => (s <**> p)(_ :: _))
  }
}

applicative functorはfunctorとmonadの中間に位置する型クラスです。それぞれ計算の文脈(コンテナ)の扱いに違いが出てきます。functorはピュアなアプリケーションロジック実行後ピュアな文脈(コンテナ)を生成、monadはアプリケーションロジックが文脈(コンテナ)を操作するのに対して、applicative functorはピュアなアプリケーションロジックの裏で暗黙的に文脈(コンテナ)が引き継がれていきます。このapplicative functorの有名な応用がValidationで、実際に触ってみるとピュアなアプリケーションロジックをベースに文脈(コンテナ)依存の処理を進められるapplicative styleのプログラミングがなかなか便利なことが分かります。

ValidationMatchers

Bean ValidationをScalaプログラムで扱うときは、ScalaTestのボキャブラリとなるカスタムマッチャーを作っておくと便利です。Bean ValidationとScalaz Validationを併用するので、両方の機能を包含したValidationMatchersを定義することにします。

package advent2011

import org.scalatest.matchers._
import javax.validation.ConstraintViolation
import scalaz._
import Scalaz._

// アプリケーションロジックのためのボキャブラリの追加はtraitの典型的な使い方の一つ。
trait ValidationMatchers {
  // Bean Validation用のボキャブラリ
  def containViolations(violations: List[(String, String)]) = {
    ContainViolationsMatcher(violations)
  }

  // Scalaz Validation用のボキャブラリ
  object success extends ValidationSuccessMatcher
  def fail(messages: List[String]) = {
    ValidationFailMatcher(messages)
  }
}

// Bean Validation用のマッチャー。
// BeMatcherやMatcherをextendsして、applyメソッドを定義するだけなので非常に簡単。
// テスト用のボキャブラリを簡単に追加できる。
case class ContainViolationsMatcher(violations: List[(String, String)]) extends BeMatcher[List[ConstraintViolation[_]]] {
  def apply(value: List[ConstraintViolation[_]]) = {
    def iscontain(nm: (String, String)) = {
      val (name, message) = nm
      value.any(v => v.getPropertyPath.toString == name && v.getMessage == message)
    }
    // allはscalazの型クラスFoldableの関数。関数名に∀の記号を使うこともできる。
    val result = violations.all(iscontain)
    MatchResult(result, "does not contains expected violation", "contains expected violation")
  }
}

// Scalaz Validation用のマッチャー。Successの判定をする。
case class ValidationSuccessMatcher() extends Matcher[Validation[NonEmptyList[String], _]] {
  def apply(value: Validation[NonEmptyList[String], _]) = {
    val result = value.isSuccess
    MatchResult(result, "failure", "success")
  }
}

// Scalaz Validation用のマッチャー。Failureの判定をする。
case class ValidationFailMatcher(messages: List[String]) extends Matcher[Validation[NonEmptyList[String], _]] {
  def apply(value: Validation[NonEmptyList[String], _]) = {
    value match {
      case Success(a) => MatchResult(false, "incorrect success", "")
      case Failure(e) => if (e.all(messages.contains)) {
        MatchResult(true, "", "correct failure")
      } else {
        MatchResult(false, "incorrect failure", "")
      }
    }
  }
}

PersonSpec

最後に、Personの使い方をScalatestのWordSpecで書いてみました。WordSpecはBDD(Behavior Driven Development)スタイルのSpecを記述するためのクラスです。Scalatest標準のShouldMatchersに加えて、先ほど作成したValidationMatchersのボキャブラリを追加しています。
ScalatestのBDDは、テスト用のアプリケーションロジックと結果判定がコーディングスタイル上明確に分離できるので、プログラムの視認性が高くなります。また、カスタムマッチャーを作り足すことで、より英文っぽい記述が可能になるので、そのあたりの遊び的な要素がプログラミングを進める上で良い感じです。

class PersonSpec extends WordSpec with ShouldMatchers with ValidationMatchers {
  "A Person" should {
    "provide isValid and validate operation" that {
      "against valid Person" in {
        val p = new Person("taro", 30, "Yokohama".some)
        Person.isValid(p) should be (true)
        Person.validate(p) should be === Nil
      }
      "against invalid Person" in {
        val p = new Person("", -150, null)
        val expected = List("address" -> "may not be null",
                            "name" -> "size must be between 1 and 2147483647",
                            "age" -> "must be greater than or equal to 0")
        Person.isValid(p) should be (false)
        Person.validate(p) should have length (expected.size)
        // 追加したボキャブラリを使用
        Person.validate(p) should be (containViolations(expected))
      }
    }
    "provide createV to create Person with Validation." that {
      // アプリケーションロジックを普通のScalaプログラム的に書いた場合。
      "Plain usage." in {
        val taro = Person.createV("taro", 30, Some("Yokohama"))
        val hanako = Person.createV("hanako", 25, Some("Kamakura"))
        if (taro.isSuccess && hanako.isSuccess) {
          val tage = taro match {
            case Success(p) => p.age
          }
          val hage = hanako match {
            case Success(p) => p.age
          }
          val avg = (tage + hage) / 2.0
          avg should be (27.5)
        } else {
          sys.error("invalid")
        }
      }
      // アプリケーションロジックをScalazのapplicative styleで書いた場合。
      // よりコンパクトで分かりやすく記述できる。
      "Scalaz usage, applicative style." in {
        val taro = Person.createV("taro", 30, Some("Yokohama"))
        val hanako = Person.createV("hanako", 25, Some("Kamakura"))
        val avgv = (taro <**> hanako)((x, y) => (x.age + y.age) / 2.0)
        // この段階までValidationの文脈(コンテナ)の上で計算が進んでいる。
        // 以下のmatch式で、アプリケーションロジックが正常に動作した場合と、エラーがある場合を分離して、それぞれのロジックを記述している。
        avgv match {
          case Success(avg) => avg should be (27.5)
          case Failure(e) => sys.error("invalid")
        }
      }
    }
    "provide createV and sequenceV for applicative style." that {
     // ValidationのListを扱う場合2例。いずれもapplicative style。
      "Use sequenceV to convert List[Validation[Person]] to Validation[List[Person]] " in {
        val taro = Person.createV("taro", 30, Some("Yokohama"))
        val hanako = Person.createV("hanako", 25, Some("Kamakura"))
        val jiro = Person.createV("jiro", 35, Some("Tokyo"))
        val persons = List(taro, hanako, jiro)
        val personsv = Person.sequenceV(persons)
        val avgv = personsv.map(x => x.map(_.age).sum.toFloat / x.length)
        avgv match {
          case Success(avg) => avg should be (30.0)
          case Failure(errors) => sys.error("invalid")
        }
      }
      "Use foldl to sum of age" in {
        val taro = Person.createV("taro", 30, Some("Yokohama"))
        val hanako = Person.createV("hanako", 25, Some("Kamakura"))
        val jiro = Person.createV("jiro", 35, Some("Tokyo"))
        val persons = List(taro, hanako, jiro)
        val sumv = persons.foldl(0.success[Person.ViolationNel])((s, p) => (s <**> p)(_ + _.age))
        val avgv = sumv.map(_.toFloat / persons.length)
        avgv match {
          case Success(avg) => avg should be (30.0)
          case Failure(errors) => sys.error("invalid")
        }
      }
    }
    "provide createVFromStrings to create Person from plain strings." that {
      "Valid parameters." in {
        val person = Person.createVFromStrings("taro", "30", "Yokohama")
        // 追加したボキャブラリを使用
        person should success
      }
      "Invalid parameters of type mismatch." in {
        val person = Person.createVFromStrings("", "a", "Yokohama")
        val expected = List("""age = a: For input string: "a"""")
        // 追加したボキャブラリを使用
        person should fail(expected)
      }
      "Invalid parameters of invalid value." in {
        val person = Person.createVFromStrings("", "30", "Yokohama")
        val expected = List("""name = : size must be between 1 and 2147483647""")
        // 追加したボキャブラリを使用
        person should fail(expected)
      }
    }
  }
}

実行結果は以下のようになります。トップレベル, that, inの三層でテストを整理できるのがなかなか便利です。

[info] PersonSpec:
[info] A Person 
[info]   should provide isValid and validate operation that 
[info]   - against valid Person
[info]   - against invalid Person
[info]   should provide createV to create Person with Validation. that 
[info]   - Plain usage.
[info]   - Scalaz usage, applicative style.
[info]   should provide createV and sequenceV for applicative style. that 
[info]   - Use sequenceV to convert List[Validation[Person]] to Validation[List[Person]] 
[info]   - Use foldl to sum of age
[info]   should provide createVFromStrings to create Person from plain strings. that 
[info]   - Valid parameters.
[info]   - Invalid parameters of type mismatch.
[info]   - Invalid parameters of invalid value.
[info] Passed: : Total 9, Failed 0, Errors 0, Passed 9, Skipped 0
[success] Total time: 2 s, completed 2011/12/23 11:54:09

まとめ

Bean ValidationとScalaz Validationを併用する方法について試行してみました。
Bean Validation用のアノテーションとScalaの相性に若干問題があるようですが、プログラミング的には特に問題なくシームレスに繋げることが確認できました。

また、Scalaz Validationの実現技術であるapplicative functorによるapplicative styleによるプログラミング、ScalatestによるBDDという技術も合わせて使ってみました。いずれもJavaでは実用化が難しい技術で、Scalaを使うメリットですね。

今回使用した技術は以下のものになります。合わせてプログラミングしてみてJava EE web profile技術、Scalaz、ScalaTestによるTDD/BDDといったところがScalaプログラミングのベースになりそう、という感を強くしました。

Bean Validation
Scalaz Validation
Scalaz applicative functor (applicative style)
Scalatest BDD
Scalatest カスタムマッチャー

ImmutableとBuilder

2011-12-14T19:00:00.000+09:00

このエントリはJava Advent Calender 2011の第14日目です。

OOPで最も重要なテクニックは何でしょうか。色々な考え方があるでしょうが、ボクはImmutable Objectがまず最初に浮かびます。
かなり前にJava World誌に書いていたJavaデザインノートという連載でも、第1回のテーマはImmutable Objectでした。

Immutable Object(不変オブジェクト)は、生成時に属性を設定した後、属性値を変更することができないオブジェクトです。Javaの場合、StringやDateなどの情報を保持する基本クラスの多くがImmutable Objectになっており、Javaプログラミングを下支えしています。

Immutable Objectの長所は、とにかく属性値が変更されないこと。一度生成したオブジェクトは何の心配もなく、メソッドの引数で渡すことができます。その先で、どのような共有のされかたをしても、知らないところで勝手に内容が変更されるということがありません。マルチスレッドプログラミングでは、この性質はさらに重要になります。

一方、Immutable Objectは以下の短所があります。

値を変更するためには、オブジェクトをまるごと複写する必要がある。
すべての値の設定をオブジェクト生成時に行う必要があり、プログラミングがちょっと煩雑。

前者の問題は、最近のハードウェア性能の向上で、普通のWebアプリ、業務アプリではまず問題にはならないでしょう。まるごと複写といってもshallow copyとなるので、まるまるデッドコピーとはなるわけではありません。また、多少の性能劣化があっても、プログラム品質、開発効率の向上の方がより重要というケースは多いはずです。よほど性能要件の高い場合でも適材適所で使い分ければよいわけです。

そういう意味で、Value Objectは当然として、DTOといった情報量の多いオブジェクトもできるだけImmutable Object化していきたいところです。

となると、現在問題となるのは後者。まずオブジェクト生成時のコンストラクタで全情報を引数で渡さなければなりません。さらに、オブジェクトの変更(つまりデータを変更して複写)では、オブジェクトのほとんどの情報と変更したいデータを用意して、コンストラクタに渡すという手間が必要になります。 StringやDateのようなValue Objectでは、オブジェクトが管理する情報が1つやせいぜい2つなので全く問題ありませんが、DTO等の場合は管理する情報が数十個になるケースも考えられ、かなり煩雑になります。数十個と言わずとも5個ぐらいでも十分嫌になります。実際のプログラミングではこの手間が嫌で、Immutableの方がよいと分かっていても普通のMutable Objectを選択することになりがちです。これを何とかしたいですね。

この問題を解決するのがBuilderです。

プログラムはこんな感じ。

Immutable Object「Person」と、そのBuilderである「Person.Builder」を定義しています。Personは、Immutable Objectであることを活用して属性をpublicにして外から扱いやすくしています。Person.Builderの方は、普通のMutableオブジェクトで、値を設定しやすくするための工夫を好きなだけ行うことができます。ここではwithXXXメソッドでメソッドチェインを実現してみました。

package advent2011;

import java.util.List;
import java.util.ArrayList;
import static java.util.Collections.unmodifiableList;

public class Person {
    public final String name;
    public final int age;
    public final String address;
    public final List<String> phones;

    public Person(String name, int age, String address,
                  List<String> phones) {
        this.name = name;
        this.age = age;
        this.address = address;
        this.phones = unmodifiableList(new ArrayList<String>(phones));
    }

    public static class Builder {
        public String name;
        public int age;
        public String address;
        public ArrayList<String> phones = new ArrayList<String>();

        public Builder() {
        }

        public Person build() {
            return new Person(name, age, address, phones);
        }

        public Builder withName(String name) {
            this.name = name;
            return this;
        }

        public Builder withAge(int age) {
            this.age = age;
            return this;
        }

        public Builder withAddress(String address) {
            this.address = address;
            return this;
        }

        public Builder withPhone(String phone) {
            this.phones.add(phone);
            return this;
        }
    }
}

こんな感じで使います。

package advent2011;

import org.junit.Test;
import static org.hamcrest.core.Is.is;
import static org.junit.Assert.*;

public class PersonTest {
    @Test
    public void buildPerson() {
        Person.Builder builder = new Person.Builder();
        builder.withName("Taro")
            .withAge(30)
            .withAddress("Yokohama")
            .withPhone("045-123-4567");
        Person person = builder.build();
        assertThat(person.name, is("Taro"));
        assertThat(person.age, is(30));
        assertThat(person.address, is("Yokohama"));
        assertThat(person.phones.get(0), is("045-123-4567"));
        System.out.println(person);
    }
}

Personオブジェクトを生成す時の手間は、普通のMutableオブジェクトの時と同じ。 buildメソッドで返ってくるPersonオブジェクトはImmutableオブジェクトなので、安全に使うことができます。どちらの目的も叶える解ですね！

新たな問題

さて、Builderを使うとImmutableオブジェクトが使いやすくなるのは分かったのですが、新たに別の問題が発生します。

このBuilderを用意する手間がなかなか大変なんです。コーディング量も多いですし、コーディング内容が単純作業のためが短調で面白くない、という問題もあります。この手間があるので、このままでは結局使わないテクニックになってしまいそうです。

単調なコーディングあるところ、自動生成あり。ここで登場するのが自動生成です。クラスの形が分かっていれば、その情報からJavaプログラムのソースコードを生成すればよることが可能です。

SimpleModelerService

現在開発中のSimpleModelerServiceでは、この問題に対応するためにDSLからJavaプログラムを自動生成する機能を提供する予定です。DSLにはScala DSLに加えて、CSV、マインドマップ(XMind)、Excelなどが利用できるようになる予定です。今回は、CSVを使って試してみましょう。

以下の内容のCSVファイルを用意します。

person,name;age(int);address?;phone+

CSVの第1カラムにクラス名、第2カラムに属性のリストを定義しています。「(int)」はint型、「?」「+」は多重度(?は0または1、+は1以上)を意味しています。

これを以下のフォームに設定して「生成」すると、色々なコードが生成されたものをzipで固めたものが返ってきます。

この中にある、DDPerson.javaに今回のテーマであるImmutableオブジェクトとBuilderが記述されています。ぜひ覗いてみてください。

ImmutableオブジェクトとそのBuilderの作成は、手間がかかるのでつい手抜きをしたくなりますが、プログラムの自動生成を活用すれば楽々クリアできますね。
SimpleModelerのJava生成機能は、近々公開したいと思いますので、ぜひご利用ください。

SimpleModelerServiceのアーキテクチャ

2011-12-07T09:13:00.000+09:00

昨日公開したXMind→クラス図変換サービスは、g3上に構築したSimpleModelerServiceというRESTサービスです。
このRESTサービスはScalaでプログラミングし、WAR形式にパッケージングしたものをGlassFish上で動作させています。
Java系のPaaS標準コンテナは、WAR形式をJavaEEのWebプロファイル＋αを動作させるものになると予想されるので、この環境をScala＆自作フレームワークで試してみるというという目的もありました。

SimpleModelerServiceは以下の4つのモジュールから構成されています。

Goldenport: アプリケーションフレームワーク
g3: クラウドアプリケーションフレームワーク
SimpleModeler: モデルコンパイラ
SimpleModelerService: SimpleModelerサービス

SimpleModelerServiceが最上位にあるクラウドアプリケーションの本体で、g3上に構築されています。SimpleModelerServiceはgoldenport上に構築されたスタンドアロンアプリケーションであるSimpleModelerをRESTサービス化します。

SimpleModelerServiceの開発規模は以下の表になります。Scalaが約121.6Ks、Javaが約10.8Ksです。Scalaのコーディング量が100Kステップを超えてきておりちょっと感慨深いものがあります。

開発規模
モジュール	Scala(Ks)	Java(Ks)
Goldenport	16.8	9.1
g3	22.6	1.7
SimpleModeler	82.1	N/A
SimpleModelerService	0.1	N/A

SimpleModelerService on g3

SimpleModelerServiceでは、クラウドアプリケーション用フレームワークとして開発してきたg3を実応用に初めて適用することができました。

g3はScala DSLでアプリケーションを記述しますが、SimpleModelerServiceは以下のものになります。

class SimpleModelerService extends G3Application {
  title = "SimpleModeler"
  summary = SimpleModeler service produces various artifacts from a SimpleModeling model.
port("/diagram",
      Description(
          "Diagram", "SimpleModeler Diagram Service",
          SimpleModeler diagram service produces a class diagram from a mindmap modeled by MindmapModeling.
,
          Schema(
              (Symbol("source.package"), XString, MZeroOne),
              ('_1, XBase64Binary)))
  ) agentpf {
    case p: Post => Post("diagram", p)
  } invoke('sm)

  goldenport('sm, SimpleModelerDescriptor)
}

port("/diagram")はHTTPリクエストを受け取るポートを指定しています。
URIの断片"/diagram"にマッチしたHTTPリクエストがこのポートで受信され、パイプラインで以下の処理が実行されていきます。

agentpfでPostリクエストを加工するPartialFunctionを実行。
invokeでチャネルsmを呼出し。

その下にあるgoldenport('sm, SimpleModelerDescriptor)は、チャネルsmをGoldenportアプリケーションSimpleModelerに割り当てる設定です。SimpleModelerのGoldenport DSLであるSimpleModelerDescriptorを指定しています。

port("/diagram")からinvokeでこのsmチャネル経由でSimpleModelerが実行され、その実行結果がport("/diagram")の実行結果としてクライアントに返されます。

HTTPのプロトコル処理、FormやJSON、AtomPub, MIMEといったデータ入出力、ファイルのアップロード処理はg3フレームワークが行います。アプリケーションは、GetやPostといったメッセージに対する関数型的な転換処理の連鎖として、アプリケーションロジックを記述することができます。また、Goldenport上に構築したスタンドアロンアプリケーションは、シームレスに接続できるようになっており、ほぼそのままRESTサービス化することができます。

SimpleModeler on Goldenport

モデルコンパイラはアプリケーションフレームワークGoldenport上に構築しています。そのアーキテクチャを定義するDSLが以下のSimpleModelerDescriptorです。

class SimpleModelerDescriptor extends GApplicationDescriptor {
  name = "SimpleModeler"
  version = "0.3.0"
  version_build = "20111206"
  copyright_years = "2008-2011"
  copyright_owner = "ASAMI, Tomoharu"
  command_name = "sm"
  //
  classpath("target/classes")
  importers(ScalaDslImporter)
  entities(CsvEntity, XMindEntity, OpmlEntity, ExcelTableEntity, 
      OrgmodeEntity, YamlEntity)
  services(ProjectRealmGeneratorService,
    ImportService,
    ConvertService,
    HtmlRealmGeneratorService,
//    JavaRealmGeneratorService,
    GrailsRealmGeneratorService,
    GaeRealmGeneratorService,
    GaeoRealmGeneratorService,
    GaeJavaRealmGeneratorService,
    AndroidGeneratorService,
    G3GeneratorService,
    AsakusaGeneratorService,
    DiagramGeneratorService)
}

SimpleModelerDescriptorでは概ね以下のような定義を行っています。

importersで外部データの移入器としてScalaDslImporterを指定。
entitiesでCsvEntityやXMindEntityなどを指定。サフィックスがcsvやxmlになっているファイルを入力すると、自動的にCSVEntityやXMindEntityに変換される。
servicesでDiagramGeneratorServiceやAndroidGeneratorServiceなどを指定。パラメタにより自動的に適合するサービスが起動される。

Goldenportが外部入出力のもろもろをハンドリングしてくれるので、アプリケーションロジックの記述に専念することができます。g3を併用することでRESTサービスまでシームレスに接続できるようになりました。

ScalaとDSL

DSLの用途は大きく(1)モデルなどの静的な情報を記述、(2)フレームワークのAPIを記述、の2つに分けられます。

SimpleModelerがモデル記述に使っているScala DSLは前者の例です。

一方、本記事で取り上げたSimpleModelerService(g3)、SimpleModeler(Goldenport)は後者の例です。SimplModeler(Goldenport)のDSLは、Javaでも何とか実現できそうですが、SimpleModelerServiceのDSLはJavaではこのような記述は難しく、DSLを得意とするScalaの美点がよく出ています。

Scalaは元々、JavaでのDSL実現に限界を感じていたため、DSL用の言語として採用したのですが、十分満足できる結果を得られました。Scalaで100K超のコーディングを行った事になりますが、Javaと比べてプログラミングが圧倒的に楽ということも体感できました。

Goldenportやg3のようなDSLベースのAPIを持つフレームワークやコンポーネントがこれからどんどん出てくることが予想されるので、Scalaプログラミングの生産性はますます向上してくることになるでしょう。また、メニーコア時代の並行プログラミングは関数型言語を中心に広がっていきそうです。今回確認できたようにGlassFishのようなJava用のクラウドコンテナ(の候補)にもまったくシームレスに載せることができるのは、Javaとの互換性を軸に据えているScalaならではです。色々考えていくとScalaはかなり便利な言語で、クラウドアプリケーション向けプログラミング言語の最右翼かなと実感しています。

XMindをクラス図に変換するクラウドサービス

2011-12-06T11:17:00.001+09:00

XMind形式のマインドマップモデルからクラス図(PNG)を生成するクラウドサービスを作成しました。

http://www.mindmapmodeling.org/service

次回の横浜モデリング勉強会(1月21日(土)予定)で使用する予定です。作成中のマインドマップをクラス図に変換して確認することによって、マインドマップモデルとオブジェクトモデルの関係をより深く理解できるようになると思います。

ツールをインストールするのは何かと大変なので、開発中のツールはこういったクラウドサービスで提供していく予定です。

このツールは、CURLコマンドまたはWeb上に置いたガジェット(HTML断片)を使って使用することができます。

Bloggerで、このガジェットが動くのか試すために以下で配置してみました。もしかしたらここから動かすことができるかもしれません。

クラウドサービスの配備には、さくらインターネットとGlassFishを使ってみました。
この組合せは、かなり簡単にScalaアプリケーションが動きますね。
どちらのUIもこなれていて作業のハードルが低いので、気軽に色々試してみたいと思います。

追記：Bloggerからもガジェット動きました。サービスはまだまだ柔らかいので、変なことをすると落ちるかもしれません。お手柔らかに。

要約エンティティ

2011-12-02T16:08:00.000+09:00

きのう「Deep Hadoop Night～誰がHadoopを殺したか？～」を聞いてきました。タイトルからも分かるように刺激的な内容でしたがオフレコが趣旨とのことで内容への感想は差し控えますが、それはともかく、座談会のお話に色々なヒントが満載で、クラウドアプリケーションのモデリングを考える上でとても刺激になりました。

Hadoop的なサービスが普通のインフラとして整備された世界での、クラウドアプリケーションのモデリング手法について考察が進みました。今まで考えていたアイデアが少しまとまってきたので、つらつら、まとめておきたいと思います。

データモデル

以下の図は、ここ数年、クラウドアプリケーションのメタモデルの素案として使用しているものを今回のアイデアに基づき改良したものです。

基本的にはクラウド以前に使っていたメタモデルを自然に拡張したものになっています。概念モデルや分析モデルのあたりは、要するに利用者などのステークホルダー観点でのモデルを構築することになるので、クラウドプラットフォームだからといって、特別な手法を取り込むということにはならないと考えています。

もちろん、クラウドによって今まであったシステム構築上の制約が外れてくるので、そのあたりで新たに考慮に入れる必要がある要因は増えてきます。

このメタモデルは、2008年頃からクラウド向けに徐々に改良してきたもので、クラウド向けのモデル要素として以下のものを追加してきました。

アプリケーション利用モデルのUX(User Experience)
アプリケーション実現モデルのメッセージフロー

UX(User Experience)は、UCD(User Centered Design)によるUIモデリング技術の発展とGUI技術の向上を取り込む意図です。UXをシステムに落し込む時の技術としてユースケースを組み合わせることを考えています。ユースケースのカバー範囲が少し小さくなるとともに、ユースケースをシステム設計側のモデリング技術として再構築することを想定しています。
メッセージフローは、さまざまなシステム間でのメッセージ交換によって協調動作するクラウドアプリケーションのアーキテクチャを、制御フローとデータフローを統合した形で記述する目的のものです。ただし、システム設計レベルの詳細な記述力は持たないので、プログラムの自動生成といった用途には使用できません。
ここまでは、以前からあちこちでお話ししている内容なのですが、これに加えて、今回新たなモデル要素として「要約エンティティ」を追加することにしました。この「要約エンティティ」がクラウドアプリケーションのモデリングの要になるのでは、と思いついたわけです。

ドメインモデル

分析モデル、設計モデルの軸となるのがドメインモデルです。(以下、正確には振舞いを含んだオブジェクトモデルですが、イメージしづらいのでデータモデルとして考えていきます。)
ポイントとなるのは、一つのドメインモデルでUIから永続データまで直接カバーするのではなく、ドメインモデルの枠組みの中で、目的毎のデータモデルを構築して、これらのデータモデルを連携させて、全体として機能させていく必要があるのではないかという仮定です。
その目的のために、仮にドメインモデルを以下のような要素に分解して実現することを考えます。

メンタルデータモデル
アプリケーションデータモデル
永続データモデル
集約データモデル

UXの実現は、利用者の目的を達成するためという軸から導きだされるものなので、永続データモデルに引きづられすぎては本末転倒です。UX専用のメンタルデータモデルを構築します。
クラウドアプリケーションでは、複数のデータソースから得られた情報を取捨選択射影して、アプリケーション独自のデータモデルを構築します。アプリケーションの意図に沿っていること、色々なデータソースを融合させるための十分な記述力を持っていること、メンタルデータモデルへの写像が行えること、といった要件を満たす必要があります。

要約エンティティ

利用者側からは利用者中心のメンタルモデル、クラウドプラットフォームからは外部データを集約データモデル、さらにアプリケーションがやりたい事を実現するためのアプリケーションデータモデル。このようないくつかのモデルを連携させて仕事をさせるには、ハブとなるモデル要素を軸に据えるのが常道です。
このモデル要素として、以前からアイデアとして温めていた要約エンティティ(ステレオタイプはsummery)がぴったりハマるのではないかというのが、今回の気付きになります。
要約エンティティは、アプリケーションが必要なさまざまな情報を集計、集約したエンティティです。つまり、元ネタとなるファクトモデルのエンティティではなく、そこから二次的に派生したエンティティとなります。
ある意味では、データベースのビューと同じ目的のものですが、問合せをカプセル化したものではなく、アプリケーションの意志で情報を集積、計算、追加していく点が異なります。

事前計算

クラウドアプリケーションでは、利用者数、データ規模の双方に対するスケーラビリティが問題となるアプリケーションが当然増えてきます。
スマートデバイスからのアクセスでは、より高速なレスポンスが要求されます。
クラウドアプリケーションの場合は、アプリケーションの外部にあるさまざまなデータを取り込んで利用するユースケースも考えられます。この場合は、外部のアプリケーションへの通信が発生するため、相応の遅延が発生することになります。複数の外部アプリケーションと連携する場合はさらに大変なことになります。
いずれにしても、問合せを受けた契機で、アプリケーションロジックとして問合せ処理を行うのでは、実用的な性能がでない可能性が高いでしょう。
この問題へ対応するには、予測される問合せ処理を事前にバックグラウンドで行っておく必要があります。この事前計算の結果を格納する受け皿として要約エンティティが使用できます。
以下の図ではドメインイベントを契機に、ドメインデータの値と合わせて、何らかの要約処理を行い要約エンティティに格納しています。このように、利用者が問合せしたタイミングではなく、イベントが発生したタイミングで要約データを計算しておくことで、利用者からの問合せに対して高速にレスポンスを返すことができるようになります

要約エンティティを導入すると、各種データのスムーズな連携が可能になるのに加えて、問合せ結果を事前計算しておくことによって、問合せのレスポンス時間を向上させるという、クラウドアプリケーションで頻出するユースケースを自然に実現できるようになります。
要約データを用いて問合せの性能を上げる手法は以前からあるわけですが、クラウドアプリケーションの場合はより重要な手法になります。
要約データは、ある意味ではデータモデルの論理的な一貫性を弱くしてしまうデータを導入することになります。このため、今までは、要約データはできるだけ用いずトランザクションの枠組みの中でSQLによって一括に結合して取得するアプローチが好まれていました。
しかし、クラウドアプリケーションのスケーラビリティ要件では、このような強い一貫性を用いるとレスポンス時間に大きな犠牲が出てくるため、逆に一貫性を弱め、いかに適切な事前計算をしておくことによって、実用的なレスポンス時間を確保するのかという点が、重要なアプローチになるわけです。

イベント駆動

一般的には、アクターは端末を操作するエンドユーザーであることが多いわけですが、クラウドアプリケーションでは、事情が変わってきます。
クラウドアプリケーションでは、今まで以上に他システムとの連携が重要になります。他システムが提供するサービスをRESTなどのプロトコルで使用し、コアコンピタンスの処理のみをアプリケーションで実装することになるでしょう。
この他システムもアクターとしてモデル化します。
外部センサーやスマートデバイスもクラウドアプリケーションと連携するアクターです。
また、アクターに外部センサーやスマートデバイスを加えて、ここから上がってくるイベントのコラボレーションをモデルに加えていけばよいでしょう。
アクターが利用者の場合には、基本的には利用者からの問合せや申請に対応するというアプリケーションアーキテクチャになります。
しかし、クラウドアプリケーションでは、利用者からの問合せや申請に加えて、他システムからプッシュされてくるさまざまなイベントを蓄積、集計して刻一刻とアプリケーションデータを更新していくことになります。
また、上で説明したように利用者からの問合せを予測して事前計算しておくことで、より高速に問合せに対するレスポンスを行うというニーズもあります。
このような要件に対応するために、上がってきたイベントをイベントエンティティといったファクトモデルとして記録すると同時に、アプリケーションのユースケースに合わせた要約エンティティにも集計を行い、事前計算をしておくことが有効になると考えられます。
また、最近注目されているストリーミングなども、イベント駆動の粒度が小さくなったものと考えることができます。この場合も要約エンティティが有効に機能するはずです。

まとめ

要約データ(summary)自体は、新しいアイデアではなくて、大きめのシステムでは広く用いられているものと思いますが、データモデルの正規化という観点からは、あまり望ましいものではなく、どちらかというと日陰者的な扱いではないかと思います。これを一級市民として扱って、UXとイベント駆動を結びつけるハブとして使うと、ぴったり収まるのではないか、というのが今回のアイデアです。
設計段階の回避策ではなく、分析段階から積極的に使っていこうということですね。そうすることによって、クラウドにまつわる遅延や障害、スケーラビリティというさまざまな問題をうまく扱えるのではないかということです。こうやって文章にしてみると、地味な改良案ですが、メタモデラー的には面白い気付きになりました。

「崖っぷちの欧州、ローマの炎上を許すな」のマインドマップとクラス図

2011-11-21T08:36:00.000+09:00

11月19日(土)に横浜モデリング勉強会を行いました。
参加者６名で、懇親会も盛り上がりました。
また、会場には(株)アットウェア様の会議室をお借りしました。
参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。
モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

モデリングの対象は、JB PRESS誌に掲載されたMartin Wolf氏の記事(FT誌の翻訳)「崖っぷちの欧州、ローマの炎上を許すな」です。前回と同様に、時事ネタなのと、いろいろな情報が交錯していて、一見焦点が絞れないところが、モデリングの練習によい感じです。
この記事における現実世界の構造をオブジェクトモデルとして抽出します。

まず、最初の作業で記事中から単語を抜き出します。
単語を抜き出しながら、登場人物、道具、出来事を中心にMindmapModelingの定めた分類に従って仕分けしていきます。
この結果、できた最初のマインドマップが以下のものです。(図をクリックすると拡大します。)

次の段階では、抽出した、登場人物、道具、出来事の洗練を行います。
用語の名寄せ、用語の種類(generalization)や部品構成(aggregation)を整理していきます。
また、この段階で区分(powertype)の抽出を開始します。
以上の作業を行った結果のマインドマップは以下のものです。

このマインドマップをSimpleModelerでクラス図に変換すると以下のものになります。「国」を中心に、ある程度構造化ができていますが、まだまだ中に浮いたクラスがあることが分かります。

次の段階では、対象となる世界の動的な側面を捉える出来事や物語を整理していきます。
出来事や物語を洗練していくことによって、出来事や物語における登場人物や道具の役割が明確化され、より登場人物や道具の構造をさらに洗練させることができます。
出来事や物語で抽出した役割は、役割(role)としてモデル化して「役割」構造枝に配置し、役割の持つ構造を洗練していきます。

今回は、EUの「中心にいる国々」(事実上、ドイツですが)が主役の物語「欧州連合を救う」と、ギリシャやイタリアなど「支援を受ける側」が主役の物語「経済破綻を回避する」の2つの物語を軸にモデルを整理していきました。

今回のモデルでもう一点ポイントになるのがドメイン・ルール(Domain Rule)、制約条件です。
記事からは「緊縮財政政策 ⇒ 内需が弱くなる」、
「景気が回復しない ⇒ 投資家の信頼感を取り戻す可能性は低い」、
「構造改革 ⇒ 労働市場に影響を及ぼす」、
「労働市場に悪影響 ⇒ 社会的・政治的な混乱」、
「社会的・政治的な混乱 ⇒ 投資家の信頼感は揺らぐ」、
「競争力が回復する ⇒ 人員解雇と名目賃金下落をもたらす」、
「人員解雇と名目賃金下落 ⇒ 失業と社会不安、債権者の不安感」といったルールが抽出できます。

救う側であるEUの「中心にいる国々」も、「支援を受ける側」もこれらの制約条項の上で、金融政策、財政政策、労働政策などを立案、遂行していく必要があります。この記事の場合、こういった制約群で合成される非常に厳しい全体制約が物語の遂行をほぼ実現不可能にしているという絶望感が記事の重要なテーマと考えられます。
逆に、針の穴を通すほどの小さいストライクゾーンとなる、実現可能な組合せは何かというのが、テーマとしてあぶり出されてくるわけですね。
この「実現可能な制約条件の組合せ」の抽出は、システムを実現する上での重要なモデル要素なので、MindmapModelingでもモデルを記述することができるようになっています。これが、BOI構造枝「規則」(Domain Rule)というわけです。

MindmapModelingではBOI構造枝「規則」に記述するDomain Ruleの命名法や構造などは特に定めていません。現状では、OCLのような非常に限定した形でしか、制約を記述して実装に落し込む手法が一般的になっていないからです。
(ルールエンジンなどの商用ミドルウェアやJSR 94 Java Rule Engine APIなどは存在していて一部では活用されていると思いますが)

ただ、最近は関数型言語が実装言語として視野に入ってきたので、このあたりとの接続を念頭において、「規則」の記述方法について文法の拡張を行うことを考えています。
今回は、論理結合子「⇒」(ならば, conditional, material implication)を使ってみました。最終的には、実装の自動生成時に関数型言語が扱える論理式を自動生成するのが目標です。

とはいえ、「緊縮財政政策 ⇒ 内需が弱くなる」という論理式は「緊縮財政政策」ならば必ず「内需が弱くなる」ということですが、現実には100%ということはないので、現実世界のモデリングには使いづらい面があります。参考情報に留めるのか、様相論理の可能性演算子(◇, possibility operator)といったものを導入するか、色々と考えてみたいところです。

以上の作業の結果、作成したマインドマップが以下のものです。

このマインドマップをSimpleModelerでクラス図に変換したものが以下の図です。

以上のマインドマップとクラス図が勉強会で作成したものです。

クラス図にしてみると、名寄の甘いところや、モデル要素のステレオタイプの選択などで問題があることが分かります。
そこで、SimpleModelerでのクラス図生成を繰り返しながら洗練したマインドマップと、このマインドマップからSimpleModelerを使って生成したクラス図は以下のものです。

記事における現実世界の構造がそれなりに上手くとらえられていると思います。

このように記事を詳細にモデル化すると、記事の内容がより深く理解できますね。

「支援を受ける側」が取り得る方法は、制約条件の組合せからほぼ:

緊縮財政、構造改革する。
緊縮財政、構造改革による内需の縮小は、外需の取り込みでカバーする。
緊縮財政、構造改革による社会の不安定化により、投資家が投資を引き上げないために不安感を払拭する対策を行う。

しかないことが分かります。

EU圏外の国から外需の取り込みを行うことも、社会の不安定化を払拭する施策も、相当難しそうですが、このあたりが今後のEUの動向を見定めるポイントかもしれません。

緊縮財政、構造改革を行う国が唯一取れる成長戦略が外需の取り込みである以上、自国通貨の切り下げ、相手国関税、非関税障壁の撤廃が最重要戦略となるわけで、(EUは入れてもらえませんが)最近TPPが政治的なイシューになっている背景がなんとなく見えてきますね。(記事の内容からの推論なので、感想の妥当性は無保証ですw)

横浜モデリング勉強会 (第2回)

2011-11-19T12:34:00.000+09:00

今日(11/19)のモデリング勉強会の情報です。

http://atnd.org/events/21756

今回モデリングするのは以下のWeb記事です。

テーマ: 崖っぷちの欧州、ローマの炎上を許すな

http://jbpress.ismedia.jp/articles/-/29621

モデリングは記事の問題領域であるドメインモデルを作成を目標にします。

問題領域の構造を、エンジニアでない人が理解できるで構築している。
プログラムに落し込むことができる。

モデリングは各自のお好きなモデリング手法で行います。

一時間に一度程度、作成途中のモデルを見ながら議論します。

初学者の方は、MindmapModelingをお勧めします。

MindmapModelingチュートリアル

「TPP議論の本質はこれだ！」のマインドマップとクラス図

2011-10-31T22:34:00.002+09:00

10月29日(土)に横浜モデリング勉強会を行いました。
札幌サテライトから2名参加があり合計6名の参加でした。
参加された皆さん、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。
モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

モデリングの対象は、田原総一朗氏のブログ記事「ＴＰＰ議論の本質はこれだ！」です。時事ネタなのと、いろいろな情報が交錯していて、掴みどころがないのが、モデリングの練習によい感じです。
この記事における現実世界の構造をオブジェクトモデルとして抽出するという趣旨です。

まず、最初の作業で記事中から単語を抜き出します。
単語を抜き出しながら、登場人物、道具、出来事を中心にMindmapModelingの定めた分類に従って仕分けしていきます。
この結果、できた最初のマインドマップが以下のものです。(図をクリックすると拡大します。)

次の段階では、抽出した、登場人物、道具、出来事の洗練を行います。
用語の名寄せ、用語の種類(generalization)や部品構成(aggregation)を整理していきます。
また、この段階で区分(powertype)の抽出を開始します。
以上の作業を行った結果のマインドマップは以下のものです。

モデリング勉強会での作業はここまででした。

その後、このマインドマップをSimpleModelerでクラス図に変換したものが以下のクラス図です。(クリックすると拡大します。)

クラス図にしてみると、まだまだ抜けているところがあることがよく分かります。

モデルとして欠陥があるわけではなさそうですが、名寄せが甘いところや、時間切れでモデルに記述しきれなかったところが明確になりました。

そこで、SimpleModelerでのクラス図生成を繰り返しながら洗練したマインドマップが以下のものです。

このマインドマップをSimpleModelerを使ってクラス図に変換したものが以下のクラス図です。(クリックすると拡大します。)

記事における現実世界の構造がそれなりに上手くとらえられていると思います。

短い記事ですが、丹念にモデル化していると存外大きな構造が背景にあることが分かります。

物語は記事中で一番重要視していると思われる「アメリカのアジア戦略」を抽出しましたが、時間があれば「アメリカの輸出増加戦略」や「日本のTPP外交戦略」というような物語を加えるとより内容が充実してくると思います。

モデリング勉強会

2011-10-29T09:37:00.000+09:00

今日(10/29)のモデリング勉強会の情報です。

http://atnd.org/events/20884

今回モデリングするのは以下のブログ記事です。

テーマ: TPP議論の本質はこれだ!

http://news.livedoor.com/article/detail/5962027/

モデリングは各自のお好きなモデリング手法で行います。

一時間に一度程度、作成途中のモデルを見ながら議論します。

初学者の方は、MindmapModelingをお勧めします。

MindmapModelingチュートリアル

クラウド時代のデータアーキテクチャとモデリング

2011-10-29T09:23:00.000+09:00

クラウド時代のデータアーキテクチャとモデリングについてちょっと思いついたことがあるのでメモ。

クラウドアプリケーションが従来のアプリケーションと異なる点の一つは、クラウド上に遍在する様々なデータをマッシュアップして使用することになるという点です。
自前で管理するデータだけでなく外部データを編みこんだドメインモデルに対して、アプリケーションが操作を行うことになります。
また、スケーラビリティを確保するため、CQRSのように参照系と更新系をアーキテクチャレベルで分割していく形が基本になるでしょう。
これは、自前データのサイズが巨大になる場合への対応にも有効ですが、外部データとの連携では必須のアーキテクチャです。自前データが巨大にならない普通のアプリケーションでも、外部データとの連携を行うのであれば、このアーキテクチャを採るのが得策です。

ドメインモデル

このアーキテクチャの上でドメインモデルは、以下の3つの種類に分類するのがよいのではないかというのがアイデア。

Application Domain
Actor Domain
Fact Domain

Application Domainは、アプリケーションが操作するドメイン。自前データと外部データをマッシュアップして見せます。

従来のドメインモデルとの違いは、外部データをマッシュアップすること。マッシュアップを行う場合、更新系を含めると実現方法が大変になってくるので、参照系を中心にするとよいでしょう。都合のよいことに参照系と更新系を分離するアーキテクチャにもマッチしています。

従来技術でもRDBMSのViewなどでこういった事が可能ですが、これをもっとアーキテクチャレベルで大掛かりにやるイメージです。(そういう意味ではデータベースの3層スキーマが近しいかも。)

外部データは、Actor Domainとしてモデル化します。Actor Objectは、アプリケーション外にあるオブジェクト(の代理オブジェクト)という意味ですが、このドメインモデル版という意図でActor Domainという名前にしてみました。

Actor Objectの場合、自前のオブジェクトでないので、決められた範囲でお願いはできるけど自由に操作できないという処理上の制約が出てきます。

Actor Domainもそういった制約を持ったドメインモデルをイメージしています。

そして、Actor Domainの外側にFact Domainを持ってきました。

Fact Domainは、クラウド上で発生する無数のイベントの生データをイメージしています。たとえばアプリケーションのログや、データベースのジャーナルなどです。

Actor Domainはアプリケーションの外部で、Fact Domainのデータを集約し、意味を付加したモデルとしてモデルインスタンスが公開されています。

Application Domainは、このAcotr Domainのインスタンスを、自前データとマッシュアップして、アプリケーションに取って意味のあるモデルのインスタンスとして、アプリケーションに提供します。

更新系

更新系には、Application Commandというモジュールを用意しました。(Commandというのは仮です。他によい名前があったら取り替えると思います。)
Application Commandは自前のデータの更新を中心に、Application Domainへの更新依頼、Fact Domainの情報提供を行います。
Application Domainへの更新依頼はあまり多くないという仮定で点線にしてみました。

モデリング技術

こういったデータアーキテクチャを採る場合のモデリング技術として、どうも文書モデリング(SGML, XML系)が有効でないかというのが、データアーキテクチャと同時に思いついたアイデア。
従来アプリケーションでは、データモデル/オブジェクトモデルがモデリングの中心でしたが、ここまで説明してきたようなマッシュアップが基本となるデータアーキテクチャでは、異なったセマンティクスのモデルをマッシュアップする基盤として文書モデリングが重要になってくるのではないかということです。
2000年頃にも、こういう話題がよく出たと思いますが、クラウド時代になって改めて、この技術を適用する形が見えてきた感触です。
ただし、今回はXMLという文脈でなく、関数型という文脈ではないかというのが、今回のアイデアの軸。関数型プログラミングと文書モデリングの相性は相当よさそうです。
XMLはデータ表現形式としてはよいのですが、データ操作体系としてはまだまだ不十分でした。ここを関数型言語ですっきりと記述することが可能になってきたのは一つミッシングリンクが埋まってきた感じです。

オブジェクトモデル、データモデル、文書モデル、関数モデル。
Application Domainのメタモデルとして、4つのモデルをどのように配合していくとよいのか。まだまだノーアイデアですが、未開拓の領域だけに色々と面白そうです。
クラウドも現時点では、プラットフォーム技術やフレームワーク、プログラミング言語といった実装よりの技術に焦点があっていますが、次の段階ではこういったモデリング技術の所に焦点が移ってくるのではないかと考えています。

RESTのFeedを一覧表示するActivityの生成

2011-09-19T21:00:00.000+09:00

8月27,28日に開催されたクラウド温泉@小樽のセッション、「クラウドアプリケーション(App Engine＆Android)自動生成 - SimpleModeler/g3/g4デモ」でのSimpleModelerからAndroidアプリの自動生成のデモの話の続きです。

SimpleModelerでは、アプリケーション開発のベースとなるドメインモデルの実装を「自動コーディング」します。この部分はドメインモデルが決まれば、プラットフォーム上での実装はほぼ決まるので自動生成の格好のターゲットです。逆に、この部分を手組みでコーディングしていると相当の工数が必要となります。プログラム開発の生産性を上げるためには、この部分の生産性向上が重要になってきます。

ただし、エンティティに対するCRUD処理については自動生成である程度のモノを生成可能です。アプリケーション部分のサンプルという意味もこめて、データに対するCRUD処理を行なうActivityを生成する予定で、一部実現しています。

現在SimpleModelerが自動生成しているのは、サーバー上に格納されているエンティティCustomerをREST経由でアクセスして一覧表示を行うプログラムが以下のCustomerRestViewActivityです。

package com.demo;

import android.content.Context;
import android.os.Bundle;
import java.math.*;
import java.util.*;
import org.goldenport.android.*;
import org.goldenport.android.traits.ListViewTrait;

public class CustomerRestViewActivity extends GActivity<DemoController> {
    
    // @LayoutView(R.id.header)
    // TextView mHeader;
    // @ResourceString(R.string.header)
    // String mHeaderLabel;
    // @ResourceColor(R.color.header)
    // Color mHeaderColor;
    // @IntentExtra("message")
    // String mMessage;
    
    public CustomerRestViewActivity() {
        addTrait(new ListViewTrait());
    }
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }
    
    @Override
    protected int get_Layout_id() {
        return R.layout.customer_rest_view;
    }
    
    @Override
    protected void onStart() {
        super.onStart();
    //    if (mMessage != null) {
    //        mHeader.setText(mMessage);
    //    } else {
    //        mHeader.setText(mHeaderLabel);
    //    }
        set_list_adapter(gcontroller.getCustomerRestFeedAdapter());
    }
}

GActivity

CustomerRestViewActivityは、サーバー上に格納されているエンティティCustomerをRESTでアクセスしてListViewの一覧として表示するActivityです。基底クラスはGActivityで、型パラメータとしてDemoアプリケーションのコントローラであるDemoControllerを指定しています。

org.goldenport.android.GActivityが、g4におけるActivityの基底クラスです。主に以下の機能を提供しています。

DI
コントローラクラスの自動バインド
トレイトによる機能拡張
非同期更新処理

DI(Dependency Injection)

g4では、Google Guice (without AOP)を用いたDIコンテナ機能を提供しています。XMLで定義された各種ViewやリソースをActivityのインスタンス変数に自動インジェクトすることができます。
自動生成されたCustomerRestViewActivityを、自前で拡張するためのヒントとして以下のコメントが入っています。
この機能は次回の記事で説明することにします。

// @LayoutView(R.id.header)
    // TextView mHeader;
    // @ResourceString(R.string.header)
    // String mHeaderLabel;
    // @ResourceColor(R.color.header)
    // Color mHeaderColor;
    // @IntentExtra("message")
    // String mMessage;

コントローラクラスの自動バインド

g4では、画面表示を行うクラスであるGActivity(Activityのサブクラス)から、アプリケーション・ロジックを分離してコントローラとして実装します。コントローラはGControllerのサブクラスになります。
Activityからアプリケーションロジックを分離して、コントローラ側で実現することにより、以下の効果を期待しています。

アプリケーション全体のロジックをコントローラに集中させることで、アプリケーションの見通しを良くし、拡張性、保守性を高める。
GUIを経由しないで、アプリケーションロジックのユニットを可能にする。
アプリケーションロジックを複数のActivityから共用できる。

GActivityでは、コントローラクラスを自動的にインジェクトするので、GActivityの実装では、特に初期化処理なしでコントローラを参照して使うことができます。　
生成されたonStartメソッドにはヒントのコメントがあります。この不要なコメントを削除したonStartメソッドは以下のものになります。

@Override
    protected void onStart() {
        super.onStart();
        set_list_adapter(gcontroller.getCustomerRestFeedAdapter());
    }

「super.onStart()」はお約束。
set_list_adapterメソッドで、コントローラから返されるListAdapterを設定しています。
GActivityで定義しているインスタンス変数gcontrollerから参照しているコントローラ(DemoController)から、ドメインエンティティCustomerをRESTのフィードとしてアクセスするListAdapterを取得しています。
このListAdapterは、バックエンドにページング付きのREST通信と通信結果のキャッシュ機能を持っています。この機能を実現するために、SimpldeModelerが生成するAndroidコードで説明したとおり、ActivityからRESTドライバにいたるまで相当数のコードが自動生成されています。また、g4ベースでサーバサイドのコードも自動生成していることは、SimpleModeler (クラウド温泉@小樽)で触れました。このあたりのメカニズムはいずれ紹介したいと思います。

トレイトによる機能拡張

ActivityにListViewやGralleryなどを操作するロジックをハードコーディングしてしまうと、ロジックを他の目的に再利用させることができません。
これらの機能を持つ基底クラスを作るのが次善策ですが、拡張性や保守性に問題があります。
この問題を解決するために、g4ではScalaのトレイトライクなメカニズムを導入しました。
ListViewTraitは、ListViewを操作する機能を持つトレイトです。GActivityのaddTraitメソッドによりListViewTraitを追加することによりGActivityにListViewを操作する機能が追加されます。
以下のようにコンストラクタでトレイトListViweTraitを追加しています。

public CustomerRestViewActivity() {
        addTrait(new ListViewTrait());
    }

非同期更新処理

ListViewTraitが内部で自動的にハンドリングしているので、CustomerRestViewActivityには直接みえていません。
ListViewTraitが、一覧データのローディング時にプログレスバーを画面上に表示し、ローディングが完了した時点で表示を終了する処理を行っています。

SimpldeModelerが生成するAndroidコード

2011-09-01T19:19:00.000+09:00

8月27,28日に開催されたクラウド温泉@小樽では、「クラウドアプリケーション(App Engine＆Android)自動生成?SimpleModeler/g3/g4デモ」のセッションで、SimpleModelerからAndroidアプリの自動生成のデモを行いました。

クラウド温泉＠小樽に向けてブログに書いてきたものを実演しました。

デモに使ったモデルは以下のCSV、demo.csvをコンバートして生成したDEACustomer.java、DEEBuy.java、DERGoods.javaの3つのScala DSLで記述したものです。

demo.csv

#actor,parts,attrs

customer,,phone

#resource

goods,,note

#event

buy,customer;goods

そのうちの一つ、DEACustomer.javaのソースコードは以下のものです。DEEBuy.javaとDERGoods.javaもだいたい同じコードになります。

DEACustomer.java

package com.demo



import org.simplemodeling.dsl._

import org.simplemodeling.dsl.datatype._

import org.simplemodeling.dsl.domain._

import org.simplemodeling.dsl.domain.values._



case class DEACustomer extends DomainActor {

  term = "customer"

  caption = "customer"

  brief = <t></t>

  description = <text></text>



  id("customerId", DVICustomerId())

  attribute("name", DVNCustomerName())

  attribute("summary", XString)

  attribute("phone", XString)

}



case class DVICustomerId extends DomainValueId {

  term = "customerId"

  caption = "customerId"

  brief = <t></t>

  description = <text></text>



  attribute("value", XString)

}



case class DVNCustomerName extends DomainValueName {

  term = "customerName"

  caption = "customerName"

  brief = <t></t>

  description = <text></text>



  attribute("value", XString)

}

デモでは、このモデルからg4上で動作するJavaソースコードを生成し、Androidアプリケーションとして動作させました。Javaソースコードの生成は、一部デモに間に合わなかったものもあったので、その後、少し改良しました。その改良版では、以下のソースコード(33ファイル、4.7Kステップ)を生成します。

BuyRestFeedAdapter.java
BuyRestFeedRepository.java
BuyRestViewActivity.java
CustomerRestFeedAdapter.java
CustomerRestFeedRepository.java
CustomerRestViewActivity.java
DDBuy.java
DDCustomer.java
DDGoods.java
DEACustomer.java
DEEBuy.java
DERGoods.java
DVIBuyId.java
DVICustomerId.java
DVIGoodsId.java
DVNCustomerName.java
DVNGoodsName.java
DemoAgent.java
DemoApplication.java
DemoContext.java
DemoContract.java
DemoController.java
DemoErrorModel.java
DemoFactory.java
DemoG3Driver.java
DemoModel.java
DemoModule.java
DemoProvider.java
DemoRepository.java
GoodsRestFeedAdapter.java
GoodsRestFeedRepository.java
GoodsRestViewActivity.java
IDemoRestDriver.java

このJavaプログラムをクラス図にすると以下のようになります。

BuyRestViewActivity, CustomerRestViewActivity, GoodsRestViewActivityがAndroidの画面クラスであるActivity(Androidの画面クラス)です。これらのActivityがサーバー上に格納されているデータを画面に表示します。
これらのActivityからDemoControllerを経由して、ドメインモデルを管理するクラスDemoModelにアクセスします。データの管理は、サーバーから取得したフィードデータをメモリ上に保持するクラスBuyRestFeedRepository, CustomerRestFeedRepository, GoodsRestFeedRepositoryで行い、これらのクラスをAndroidのウィジェットであるListView用のアダプタBuyRestFeedAdapter, CustomerRestFeedAdapter, GoodsRestFeedAdapterが使用します。
また、サーバーとの通信はDemoG3Driverが行います。今回のデモではサーバー側はg3なので、g3と通信するためのドライバを使用していますが、ドライバはインタフェースIDemoRestDriverを実装していれば取り替え可能な構造になっています。
クラス図の下に、Documentオブジェクト(DTO)であるDDCustomer, DDBuy, DDGoodsがありますが、これらのオブジェクトでデータのやりとりを行います。
クラス図のざっくりとした説明は以上の通りです。追々詳細な情報を書いていく予定です。
ここで強調したいのは、(トイプログラムではなくて)ある程度本格的なアプリケーションを作成する場合、ごく小さなドメインモデルからでも、これらのクラス群を作成しなければならないということです。一般的なJavaプログラムでも必要なものもありますし、Android特有のクラスもありますが、いずれにしても相当量のコーディングが必要になります。しかも、これらのクラス群はドメインモデルが決まれば、Android上でどう実装するのかというのも、ほとんど決まってしまうので、人力でコーディングするのは、かなりもったいない作業です。こういった定型部分を自動コーディングしてしまうことがSimpleModelerの目的です。

F#考 - クラウド温泉2.0@小樽

2011-08-31T09:00:00.002+09:00

8月27,28日にクラウド温泉@小樽が開催されました。今回のクラウド温泉も盛りだくさんの内容で、ボクとしてはF#について詳しいお話を聞けたのが収穫でした。発表者の@bleisさん、MSの荒井さん、参加者の皆様、どうもありがとうございました。

F#はScalaと同じオブジェクト指向と関数型のハイブリッド言語で、ざっくりとはだいたい同じことができると捉えてみてよさそうです。ただし、言語の狙いは異なるので、利用シーンは違ってきます。

以下、F#の知識は当日の聞きかじりを元にしているので、不正確なところが多いと思いますが、ボクの現時点での認識のメモということでご了承ください。

F#の言語のセマンティクスは関数型が主でオブジェクト指向は従のようです。

関数型の世界で扱うデータはレコード/タプルで、構造体的な言語要素となっています。そして、このレコードとは別にクラス/オブジェクトが用意されています。(変数に関数をバインドしてメソッド的に使えるかもしれませんが、この点は未確認。)
つまりデータを記述する言語要素が二系統あって、そのうちの一系統を使うと関数型言語らしいプログラミングが堪能できるということですね。

一方、クラス/オブジェクトは、当日確認しなかったのですが、恐らく.NETのクラス/オブジェクトだろうと思います。クラス/オブジェクトを通じて.NETのクラス/オブジェクトをC#やVBと相互に連携できるのではないかと推測します。

データを記述する言語要素が二系統あるのは、関数型言語としての純粋性を保ちたかったということもあるでしょうし、.NETのクラス/オブジェクトを関数型言語向けに拡張するのが難しかった、という制約に起因するところもありそうです。

また、データは基本的にイミュータブルで、mutableというキーワードを付けるとミュータブルにもできるというアプローチになっています。この点からも関数型の方に軸足があることが分かります。このため、状態の存在を前提としたプログラミングには、あまり向いておらず、つまるところオブジェクト指向プログラミング言語としてはあまり快適ではなさそうです。

F#では、型パラメータの省略ができて簡潔な記述が可能になっていますが、関数をオブジェクトのメソッドとしてポリモーフィックに動かすことをやめることにより(クラス/オブジェクトではなくレコード/タプルを使う効果)、共変/反変まわりの指定を考えなくてもよいので、そのあたりが寄与しているのかなと感じました。これも、関数型側に軸足を持っている効果です。

以上のようにF#は関数型側に大きく機能を倒して、オブジェクト指向的にはほどほどにして、関数型言語の美点を伸ばしていくアプローチのようです。

このアプローチの延長線上で、コンピューテーション式、seq/yieldといったところが、関数型言語の高度な応用で、マニア的に面白いところですね。どちらもDSLの記述力を高めることに大きく寄与する機能です。

F#は関数型言語として素晴らしい言語であるのは確かですが、関数型側に機能を倒しているため、オブジェクト指向言語としては快適というわけではなく、実務へ適用する汎用言語としては考えにくいのかなという印象を持ちました。F#一本ですべての応用を記述する、ということにはならないかなと。

そこで、F#を取り囲む文脈を考えてみましょう。F#は.NET上で動作することを前提とした言語であり、C#やC++といった.NETの他の言語と共存することが前提です。

C#の場合は、VBなどを置き換えていって、.NETの中心言語にしていくという意図もあったかと思いますが、F#の場合は、C#を置き換えるといったことは意図しておらず、C#を補完する立場になるでしょう。そうすると、C#ができることを全部カバーした上で、新たに関数型の機能を追加するといったことをする必要はなく、オブジェクト指向的な文法は.NETのクラス/オブジェクトと連携できるものがあれば十分と割り切ることができます。その上で、C#ではできない関数型のプログラミングモデルを使いやすいものにする方向に力をそそいでいるわけですね。

そういう意味で、F#は.NETワールドを構成するパーツの一つとして、並列プログラミングやDSLといった関数型に適した分野をカバーする専用言語という戦略上の意図を持った言語であると推測されます。
今後の技術の発展の方向は並列プログラミングとDSLが二大潮流になることは確実なので、この2つの分野に強い関数型言語を並行プログラミングとDSL向けを意識してチューニングし、.NETワールド内でのポジションを明確にした上で提供してきているのにはMicrosoftの底力を感じました。

F#は、monoと組合わせてMacやLinuxでも普通に動くみたいなので、DSLにフォーカスした応用ではプラットフォームを問わず実用的に使用できそうです。そういう意味でも面白い存在です。

SimpleModeler (クラウド温泉@小樽)

2011-07-19T09:00:00.001+09:00

クラウド温泉＠小樽では、モデルコンパイラSimpleModelerからg3フレームワーク上で動作するクラウドサービス、g4フレームワーク上で動作するAndroidクライアントを自動生成し、Androidクライアントとクラウドサービスが連携動作するデモを行う予定です。

まずScala DSLでモデルを記述します。(デモではより効果を狙ってCSVでモデル記述するかもしれません。)
このScala DSLからSimpleModelerを使って、Android用クライアントとGoogle App Engine/Tomcat(Glassfish)の両方で動作するRESTサービスを生成します。
生成された、AndroidクライアントとRESTサービスは連携して、データに対するCRUD処理を行うことができます。

Android用クライアントはg4フレームワーク上で動作します。g4フレームワークはGoogle GuiceによるDIをベースにしたAndroidアプリケーションフレームワークです。

サーバープログラムはg3フレームワーク上で動作します。g3フレームワークはGoogle App Engineと、TomcatやGlassfishなどの通常のServletコンテナ上で動作します。ServletコンテナはEC2を始め、一般的なクラウドプラットフォーム上で動作します。このため、g3フレームワークを用いることでクラウドプラットフォーム上で可搬性のあるアプリケーションを作成することができます。

デモの目的

デモでは、見栄えや分りやすさの点からプログラミングレスで自動生成したアプリケーションがそのまま動作することを主眼とします。
しかし、このデモはモデル駆動開発でアプリケーションプログラムが自動生成されるということを主張するのが趣旨ではありません。現在の所、CRUDのような特定の定形処理以外はアプリケーションの自動生成は、まだまだ実用化には程遠いからです。

それでは、SimpleModelerによるプログラムの自動生成は何をコンセプトとしているのでしょう。
それは、ひとことで言うと「ドメインライブラリの自動コーディング」です。

ドメインモデル

オブジェクトモデリングでは大きく分析モデル(またはPIM, Platform Indenpendent Model)と設計モデル(またはPSM, Platform Specific Model)の2つのモデルを作成します。これはモデルの抽象度が分類の軸になっています。
分析モデルに対して、動作ターゲットのプラットフォームと非機能要求を加えて、実際に動作するプログラムの設計図となる設計モデルとなります。

モデルの分類の軸は他にも色々ありますが、筆者が有効と考えているものにアプリケーションモデルとドメインモデルの軸があります。
ドメインモデルは、アプリケーションの問題領域の構造をモデル化したものです。主に静的モデルにフォーカスしたモデルで、静的構造中心、モデルのライフサイクルが長い、自動生成の対象になりやすいという特性があります。
一方、アプリケーションモデルはドメインモデルを使用して、アプリケーション利用者の目的を達成するための仕組みをモデル化したものです。主に動的モデルにフォーカスしたモデルで、アプリケーションモデルは、振舞い中心、モデルのライフサイクルが短い、自動生成の対象になりにくいという特性があります。

ドメインモデルは、静的構造(クラス図)中心となりますが、動的モデルとして状態機械、ルールモデル、アクション言語を併用します。(アプリケーションモデルでは、ユースケース、インタラクション、コラボレーションなどを使用します。)

静的構造図が中心のモデルの場合、オブジェクト指向言語を使うと設計モデルとプログラムのセマンティクスギャップが非常に少ないので、設計モデルを飛ばして直接プログラミングすることも可能です。短期開発では、その方が効率もよく、プログラムの品質もよくなるでしょう。また、持続性を重視する製品開発でも、静的構造のみでよければER図などのデータモデリングで十分です。
一方、状態機械やルールモデルなど、プログラミング言語とのセマンティクスギャップが大きいモデルを使用する場合は短期開発であっても引き続き設計モデルが有効です。

ドメインライブラリ

現状では、ドメインモデルを作成しても手作業でプログラミングすることが多く、モデルを作成しても作業量は減りません。プログラミング側での改修がモデルに反映されなくなり、長期的にはモデルが死んでしまうという問題もあります。

ドメインモデルからRDBMSのDDLや、O/Rマッパーのコード生成などを行うツールはあるので、データモデリングの範囲では自動生成を取り込んだ運用を行うことは可能です。
しかし、動的モデルを包含したオブジェクトモデル全体のスコープでは、ドメインモデルに限定しても、プログラムの自動生成はまだまだ発展途上といえるでしょう。
しかし、ドメインモデルを実用的に記述できる範囲でドメインモデルのプロファイルを定めておくことは可能です。筆者はこの目的でドメインモデル(とアプリケーションモデル)のプロファイルをまとめています。詳しくはこちらをどうぞ。(『上流工程UMLモデリング』、『マインドマップではじめるモデリング講座』)

ドメインモデルの重要な特性の一つは、自動生成に適しているということです。決められたパーツを使ってドメインモデルを記述するという運用にすれば、分析モデルから、設計モデルをバイパスしてほぼ完全に実装を自動生成することができます。また設計モデルも仕様書という形で生成可能です。もちろん、100%完全は難しいでしょうが、適切な拡張ポイントを生成することで、部分的なプログラミングで補完可能にできるでしょう。

SimpleModelerは、この実現を目指しています。

ドメインライブラリとアプリケーションフレームワーク

ドメインライブラリを単体で生成するのも十分に有効ですが、適切なアプリケーションフレームワークがあれば、この枠組みの中に組み込んでしまえば、アプリケーション開発をより効率的に行うことができます。
アプリケーションフレームワークの上にドメインライブラリをビルトインしたものを土台にしてアプリケーション開発を進めることができます。

クラウドアプリケーション向けにg3フレームワーク、Androidアプリケーション向けにg4フレームワークを開発したので、これらのフレームワーク上にビルトインできるドメインライブラリを生成します。

自動コーディング

モデル駆動開発について以下のような疑問をしばしば耳にします。

モデルからプログラム全体を生成するのは無理ではないか。
モデルから自動生成したプログラムを直接修正した時に、モデルに反映できないと、以降の開発にモデルを使うことができない。
モデルレベルでデバッグできないとバグ修正ができない。

つまりモデル駆動に対してプログラミング言語のコンパイラ的な運用を期待しているわけです。これは一つの理想ではあるのですが、現段階の技術レベルでは難しく、ここに判断基準を置いてしまうと、自動生成は時期尚早という判断になってしまいます。
しかし、ドメインモデルに範囲を限定すれば、相当量のコードの自動生成が可能なので、これをまったく無視するのはあまりにももったいない。
そこで、コンパイラモデルに代わって、プログラムの自動生成をソフトウェア開発の枠組に取り込む切り口として考えているのが『クラスライブラリの「自動コーディング」』というコンセプトです。

言うまでもなくソフトウェア開発では、多数のクラスライブラリを併用して開発を進めるのが普通です。多くのクラスライブラリはオープンソースであり、APIリファレンスとソースコードの両方を参照して利用できます。
基本的にはAPI仕様をみて使いますが、詳細仕様を知りたい時にはソースコードも参照します。デバッグ時にはクラスライブラリのソースも取り込んでブレークポイントを張ったり、変数の値を確認したりします。
クラスライブラリのバグ修正は追加は、短期対応と長期対応の2つのフェーズで行われます。まず、短期対応として、必要に応じてパッチを当てたりして修正します。
その後、バグの修正や機能追加は所定の手続きをへてクラスライブラリに反映されます。長期対応として、この修正が取り込まれた新しいバージョンのクラスライブラリを、改めてアプリケーションに取り込みます。

ここで、発想を少し変えてみましょう。
事前に誰かが用意したクラスライブラリでも、プログラムが自動生成したクラスライブラリでも、利用者からは全く同じです。
つまり、クラスライブラリとしてとして運用するのであれば、プログラムの自動生成を用いても、今までの開発と何ら変わるところはないはずです。

次は、ニーズの面から考えてみましょう。
プログラミングをするときに、特定のドメイン向けのクラスライブラリが整備されているととても効率的です。
しかし、特定のドメイン向けのドメインクラスライブラリは、よほど共通して使用される大きなドメインでないと事前に誰かが用意しているということはありません。
このため、ソフトウェア開発の初期段階では、ドメインモデルをコードとして実装する作業を黙々と続けることになります。あるいは、画面とデータベースをつなぐ処理として、画面のイベントハンドラーの中にドメイン処理が重複して繰り返し生産されることになります。
前者では、ドメインモデルのコーディングが開発全体のボトルネックになりますし、後者では、アプリケーションの保守性、拡張性に問題が出てきます。
この問題を、ドメインクラスライブラリの自動コーディングが解決することができます。前述したようにドメインモデルはほぼ完全な自動生成が可能なので、ドメインライブラリを自動生成するのは実用範囲です。そこで、ドメインモデルをドメインクラスライブラリとして"自動コーディング"してしまおう、というわけです。
出来合いの標準品ではなく、自分向けのクラスライブラリですから、アプリケーションのニーズにもぴったり合います。使い方は、ソースコードが提供されている通常のクラスライブラリと全く同じです。

クラウド温泉＠小樽

SimpleModelerのコンセプトが「ドメインライブラリの自動コーディング」であることを説明しました。クラウド温泉＠小樽では、SimpleModelerのデモをネタに、ドメインライブラリの自動コーディングというコンセプト、実現性、応用について議論できればと思っています。
また、クラウドアプリケーション、スマートデバイスによって、ドメインモデリングの技術にも色々な影響があることが予想されます。このあたりも面白い議論ができそうです。

g4 (クラウド温泉＠小樽)

2011-07-11T07:30:00.002+09:00

クラウド温泉@小樽では、Androidアプリケーションの自動生成のデモをしますが、その基盤となるAndroidアプリケーションフレームワークであるg4について説明します。

g4はSImpleModelerによるAndroidアプリケーション自動生成の基盤として新規作成したアプリケーションフレームワークです。

g4の基本構成は以下の通りです。

ボクのAndroid開発経験から、Androidのアプリケーションアーキテクチャとして、この図に示したものがよいのではないかという仮説のものと、このアーキテクチャの基盤となるクラス群を提供してます。

アーキテクチャの基盤となるクラスは以下の3つに分類できます。

Android基本ライブラリを拡張
Google Guideを拡張
g4独自クラス

Android基本ライブラリ

Android基本ライブラリが提供するクラスです。これらのクラスをさらに拡張した基底クラスを用意しています。

Application: アプリケーション
Activity: Android画面
Fragment: Android画面の断片(Android 3.0以降)
View: Android画面の部品
Service: アプリケーション本体を補完するサービス
Intent: Activity/Service間で流通する情報
ContentProvider: 情報提供

Activity, Fragment, ViewはCRUDなど特定のユースケース向けのソースコード自動生成が行われるので、それに対応した拡張を行っています。
Service, Intent, ContentProviderは、ソースコードの自動生成の直接の対象です。特にドメインモデルからIntentとContentProviderはほぼ完全な形で自動生成できる見込みです。
Serviceは、ファサード部分を自動生成して、実現部分をコーディングする形になりますが、これに対応した拡張を行う予定です。

Google Guiceを拡張

g4は、DI(Dependency Injection)を用いたアプリケーション組立てをサポートします。DI機能にはGoogle Guice(without AOP)を用いています。
Guiceを使ったDIで、アプリケーションを構築する各オブジェクトの結合度を低くし、オブジェクトの再利用性、拡張性、保守性、テスタビリティを高めます。
このGuiceのモジュールを定義するクラスがModuleです。g4ではGuiceのMiduleをg4用に拡張した基底クラスを提供しています。

Module: Google Guiceのモジュール定義クラス

g4クラス

g4では以下のAndroidが提供する基本クラスに、以下のクラスを追加してAndroidアプリケーションのアプリケーションアーキテクチャを構築しています。

Controller: 画面が実行する責務を提供
Agent: モデルの更新を伴う責務を実装
Model: ドメインモデル
ErrorModel: エラーモデル
Driver: 外部リソースにアクセスするドライバ
Factory: オブジェクトの生成とインジェクション
Repository: エンティティオブジェクトの管理

Androidでは、画面のインタラクションをActivityが遂行しますが、シンプルな造りの場合、すべての責務をActivity内に実装することになります。
この方法は初期実装は楽ですが、プログラムがある程度大きくなってくると、再利用性、拡張性、保守性、テスタビリティが損なわれることになります。
そこで、持続的に機能拡張を続ける本格的なアプリケーションの場合はきちんとしたアプリケーションアーキテクチャの構成を取るのが得策です。アプリケーションアーキテクチャでは、分散対象となる部品の構成、分散配置の戦略を定めます。そしてユースケースを構成する各種責務を色々なオブジェクトに分散配置していくことになります。
g4では、以下の方針で責務の分散配置を行います。

利用者視点でドメインモデルを操作する責務はControllerに配置
ドメインモデル視点でモデルの更新処理を行う責務はAgentに配置
ドメインモデルはModelに配置
エラー処理の責務はErrorModelに集約
外部リソースへのアクセスはDriverに集約

また、ドメインモデル操作の基本機能であるFactoryとRepositoryも用意しています。
Androidの基本ライブラリのみだと、ここで述べたアプリケーションアーキテクチャを実装することが難しいので、必要なオブジェクトをg4独自クラスとして追加しているわけです。

g3 (クラウド温泉@小樽)

2011-07-09T17:02:00.001+09:00

8月27日(土)/28日(日)に開催されるクラウド温泉@小樽に向けて、現時点でのg3/g4/SimpleModelerの技術について整理しておこうと思います。

Scala DSLベースのモデルコンパイラSimpleModelerでは、当初Glassfish(Java EE)、Spring、Google App Engineといったクラウドプラットフォームあるいはその上で利用するフレームワークのAPI上に直接プログラムを生成することを目指していました。

実際に、Google App Engineでのプログラム生成を実装したところ、生成するプログラム側で相当な作り込みが必要となり、ある意味フレームワークそのものを生成するような形になってしまうことが分かりました。結局、共通部品として必要なものは、自動生成ではなくフレームワークとして独立して提供するのが筋ということですね。

クラウドアプリケーション向けのフレームワークとしては、既存のフレームワークを流用するのが有力な選択肢です。Java EEやSpringといったエンタープライズ向けのWebフレームワーク、あるいはMule ESBやCamelといったESBについても比較検討したのですが、ボクが必要としている機能とはまだま距離があるということで、新規に開発することにしました。

こうして開発したのがg3フレームワークです。

目標

g3を一言で表現すると『Scala DSLベースREST指向粗粒度非同期コンポーネントフレームワーク』です。

フレームワークのアプリケーションインタフェースにはScala DSLを用いる。
粗粒度のコンポーネントを非同期で連携してアプリケーションを構築する。
コンポーネント間の連携にはRESTを用いる。

開発時に念頭においていたのはEIP(Enterprise Integration Patterns)です。EIPによって非同期コンポーネントをAtomPubのフィードメッセージで連携するアーキテクチャがクラウドアプリケーションの一つの形ではないかというのが基本アイデアになっています。

プログラミングモデルとDSL

クラウドアプリケーションのアプリケーションアーキテクチャとしてどのようなものが適切かというのはまだまだ未知の領域ですが、ボクが仮説として考えているのが並行動作する粗粒度コンポーネントをメッセージングで接続する、コンポーネントベースのアーキテクチャです。粗粒度コンポーネント間の連携プロトコルとしてRESTセマンティクスを用いることで、プログラミングモデル上、インターネット空間とシームレスに接続することができます。

Scala DSL

このアーキテクチャを取るときの論点の一つが、コンポーネントの組立てをいかに簡単に記述するのかという点です。このようなコンポーネントの組立てにXMLを用いるのが従来の手法ですが、以下の問題があります。まず、XMLによる定義は記述が煩雑になってしまうこと。また、プログラミング言語とのシームレスな連携ができないので、プログラミング言語とXMLの二本立ての管理になってしまうという問題もあります。関連して、定義ファイルにプログラミング的な技法、たとえばマクロを導入して定義の共通部をまとめることにできるようにする、いったことを実現することも困難です。この問題を解決するために採用したのが、Scalaをホスト言語にしたDSLです。専用言語であるDSLを用いることで、メッセージングによるコンポーネントの連携を簡潔に記述することができます。また、Scalaを通してScalaだけでなくJavaやその他JavaVM上で動作するプログラミング言語で記述されたプログラムと連携することができます。

REST指向

REST指向は、Webプロトコルとのシームレスな連携、フレーム内リソース識別のURI化、コンポーネント連携に用いるメッセージをAtomフィードベースにしていることにより実現しています。

イベント駆動

クラウドアプリケーションは非同期に発生するイベントを受けて動作するイベント駆動で処理する構造がアプリケーションの基本アーキテクチャになるというのがボクの仮説の一つです。比喩的には、割り込みハンドラーとシステムアクティビティでアプリケーションを構築する組込み機器のような構造をイメージしています。イベント駆動はまだ実現できていませんが、その前提となるメッセージの到着を起点に処理を駆動するメカニズムは実現しています。エンティティとして永続管理するビジネスイベントと、揮発性のシステムイベントをどのように再構成して、フレームワークのアーキテクチャ上に位置付けていくのか考慮中です。

状態機械

イベントの発生を受けて、発生したイベントとリソースの状態の組に対して、適合するアクションを実行するというのが、オブジェクト指向の動的モデルの基本的な考えです。イベント駆動型のアプリケーションでは、この状態機械による動的モデルの記述と実行が重要な意味を持ってくることになります。残念ながら現状のオブジェクト指向言語では、状態機械のサポートを行っていないのでプログラムで直接記述することができません。このメカニズムをフレームワークで実現したいというのもg3の目的の一つです。プログラミング言語でサポートされていない必須機能をフレームワークで実現するわけですが、Scala DSLによるアプリケーションインタフェースを用いるので、ある意味新しい専用言語を導入するのと同じインパクトがあります。状態機械の記述方式と上流モデルとの連携方法について、前述のイベント駆動のメカニズム、記述方法と合わせて検討中です。

スケーラビリティ

クラウドアプリケーションでは、スケーラビリティも重要な要件です。すべてのアプリケーションがフルにスケーラビリティを追求する必要はありませんが、必要に応じてスケーラビリティを確保する手段をモデリング、アプリケーションアーキテクチャ、フレームワークといった様々な層の技術の中に事前に織り込んでおく必要があります。 g3はスケーラビリティ確保の手段として非同期メッセージング、KVSのサポートを行っています。非同期メッセージングとして前述したようにREST指向のメッセージを粗粒度コンポーネント間でパイプライン的に流通させるモデルをとっています。現在はまだ実現できていませんが、CPS(Continuous Passing Style;継続渡しスタイル)的な処理の記述や、メッセージキューを媒介にした非同期処理などを取り込める構造になっています。また、データストアのスケーラビリティについてはKVSを包含したデータアクセス基盤を用意しました。 KVSも、Redisのように本当のKey/Value対のデータストアもありますしGoogle App Engine DataStoreのようにISAM的なデータ構造を持っているものもあります。以上の点から、KVSといってもISAMデータ構造、要するに単純な表形式のデータ構造を扱うようにしています。クラウドアプリケーションでは、一貫性重視の用途にはRDBMS、スケーラビリティ重視の用途にはKVSを使い分けることになります。その場合、RDBMSとKVS間でデータを持ちまわる処理も普通に行われるのでKVSとRDBMSに対する統一アクセス法が欲しくなります。また、このアクセス法はREST指向アーキテクチャ上で使用することになるので、RESTとのシームレースに連携できることが必要です。 g3では上記の要件を満たす統一アクセス法をサポートしました。REST指向アーキテクチャに沿って普通に処理を記述するだけで、特に意識することなくKVSを使用することができます。(もちろん、KVSをスケールさせるためにはキーの選定など特別な考慮が必要になりますが、疎通レベルでは簡単に使えるというのも重要です。) なお、SQLを直接使用したアクセスも可能ですし、Javaを直接使ってJDBCを使用することもできるので、必要に応じて使い分けすることもできます。

各種機能

実用上有用な機能として以下の機能を実装しました。

Web Socket
Ext-JS対応
各種クラウドサービス用ドライバ(Twitter, Google Calendar, Dropbox, Evernote)

こういった、各種Web技術、クラウドサービスの取り込みは、必要に応じて順次行っていく予定です。

スコープ外の機能

g3の提供する機能という切り口とは別に、g3がスコープ外としている機能、後回しにしている機能が分かれば、g3の目的・意図が明確になると思います。以下の機能はフレームワークの直接のスコープ外としています。

Web MVCフレームワーク
テンプレートエンジン

Web MVCフレームワークやテンプレートエンジンは、まだまだ改良すべき点はあるでしょうが、基本的には枯れた技術であり、再発明する必要性が薄いことが一つ。それより重要なのが、HTML5/CSS3によるAjaxやiOS/Androidといったスマートデバイスの興隆によって、技術の重要性が低くなりそうということです。レガシー技術はそのまま再利用することとして、イベント駆動や非同期コンポーネントフレームワークといった既存の技術ではカバーしていない技術の実現を中心に開発を進めています。通常のWebアプリケーションを開発する場合にg3を用いる場合には、既存のWebフレームワークと併用することになります。

次の段階で取り組むもの

以下の機能は、次の段階で取り組む予定にしています。

DI(Dependency Injection)
OSGi
JMX
Android
TDD/BDD

実用化フェーズでは必要なのは分かっているものの、基本機能が定まっていない段階で取り組むのは時期尚早ということで、将来の拡張を意識しつつも当面の開発項目からは落としています。

クラウド温泉＠小樽

2011-06-29T08:30:00.002+09:00

正式の広報はまだですが、8月27日(土)/28日(日)にクラウド温泉@小樽が開催される予定です。温泉に浸かりながら、クラウドを肴に語り合いましょう、という企画です。

ここ数年取り組んでいた、ScalaによるDSL駆動開発について、開発していたツールが形になってきたので、クラウド温泉でお披露目する予定です。

DSL駆動開発の軸となるのがScala DSLコンパイラSimpleModelerです。当初は、SimpleModelerでモデルからクラウドプラットフォームのAPI上に対して直接クラウドアプリケーションの生成を試行していたわけですが、適切なアプリケーションフレームワークがないと自動生成もままならない、ということが分かりクラウドプラットフォーム向けにRESTメッセージングフレームワークであるg3を開発しました。

g3はAtomPubメッセージによるRESTを軸としてコンポーネントの連携動作を行うイベント駆動フレームワークです。

g3はデータストアアクセスを含めてTomcatなどのWebサーバとGoogle App Engineの両方で動作します。できるだけ同じプログラムを色々なクラウド・プラットフォームで動作させることがg3の目的の一つです。

また、クラウド時代にはUIが、伝統的なWeb UIからAjaxベースのGUIやスマートデバイスに移行することになります。このところ仕事でAndroidに取り組んでいたこともあり、Android向けのプログラム生成の基盤となるフレームワークg4を作ってみました。

Androidのアプリケーションアーキテクチャは、以前「Androidのアーキテクチャ」で考えてみましたが、これをさらに発展させプログラムの自動生成に対応したものを実装しました。

クラウド温泉のセッションでは、SimpleModelerからg3を使ったGoogle App Engineアプリケーションと、g4を使ったAndroidアプリケーションの自動生成のデモを行う予定です。自動生成したAndroidアプリケーションとGoogle App Engineはもちろん連携動作します。

といいつつ、g3アプリケーション(App Engine)とg4アプリケーション(Android)の自動生成はこれから作るので(汗)、実際にデモまで辿りつけるかは分かりませんが、クラウド温泉を励みにして取り組んでいく予定です。

データストアのアクセス特性

2011-05-31T18:15:00.001+09:00

4月の中頃に書いていた記事の続きなんですが、ずいぶん間が空いてしまいました。そこでは、すこしモデリングの話題に寄り道しましたが、ドメインモデルとデータストアのマッピングの話題に戻りたいと思います。

ドメインモデルとデータストアのマッピングを考える上で重要なのがデータストアの分類です。データストアの分類軸として、色々なものが考えられますがその一つとして、データアクセス特性があります。

クラウドプラウドプラットフォームにおけるデータストアの性能特性と、アプリケーションのニーズの対応関係を整理し、アプリケーションの用途に合わせた性能特性を持つデータストアを選択することが重要になります。

RDBMS登場後は、データストアの選択もRDBMS一本でよかったのですが、クラウドプラットフォーム、NoSQLといった新しい技術の登場で、データストアの選択、あるいは使い分けがアーキテクチャ選択上、重要な要因になってきました。

そこで、データストア選択のための評価軸を整理しておくことにしました。現時点で思いつくのがアクセスパターン、アクセス方式、アクセスサイズです。他によいものあれば随時追加していきたいと思います。

アクセスパターン

データストアに対するアクセスパターンとして以下の分類を使用します。

read-only: 参照のみ。
read-write: 参照と更新。
read-mostly: ほとんど参照、まれに更新。
write-only: 書き込みのみ。

read-writeが一番汎用的ですが、スケーラビリティの達成が困難になります。

その他の3つのアクセスパターンは、read-writeよりもアクセスの自由度が限定される分、スケーラビリティを高くする事ができます。

read-onlyは文字通り参照のみのアクセスで、更新処理はありません。このパターンでは、データの複製を必要な数だけ用意することができるので、スケーラビリティを高めることができます。

read-mostlyは分散技術でよく用いられる呼び方で、ほとんど参照のみで、たまに更新があるという特性です。この特性と、データの一貫性は厳密に制御しないという方式を組み合わせるとキャッシュを広範囲にわたって配布、共有できるのでスケーラビリティを大幅に向上させることができます。

write-onlyはアプリケーションからは書込みのみを行うパターンです。ログなどが典型例ですが、CQRSといったアーキテクチャではデータ投入にこのアクセスパターンを用います。

read-writeでは、データの一貫性を保つための制御に大きなオーバヘッドあり、write-onlyとすることでこのオーバヘッドを避けることができます。

アクセス方式

アクセス方式として以下の分類を使用します。

sequential: シーケンシャルアクセス
random: ランダムアクセス

sequentialは、データを先頭から最後尾まで連続でアクセスするアクセスパターンです。先頭から最後尾までの連続アクセスも、さらに索引順と格納順に分けることができますが、現在は索引を持つのが普通(あるいはカラムナDB)なので考えないことにします。

randomは、データを一部をランダムにアクセスするアクセスパターンです。

OLTPはランダムアクセスが中心ですが、バッチ処理やOLAP/BIはシーケンシャルアクセスのニーズが高くなります。

データストアを選択する上で重要なのは、ランダムアクセス性能とシーケンシャルアクセス性能は、多くの場合相反する性質ということです。このため、アプリケーションの特性に応じてデータストア製品を選択するが必要となります。あるいは、RDBMSにおけるインデックスのチューニングといった作業で同じデータベースシステムをシーケンシャルアクセス向けやランダムアクセス向けにチューニング仕分けることも可能です。いずれかの手段で、適切なデータストアを確保することになります。

アクセスサイズ

アクセスサイズとして以下の分類を使用します。

record: データをレコード単位でアクセス
portion: データの一定範囲をアクセス
bulk: データの一定範囲/全体を一括してアクセス

recordはレコード単位でのデータアクセスです。1レコードから数レコードの範囲を想定しています。

portionは一定範囲でのデータアクセスです。データの選択を行った後、一回の転送で取得できる範囲(1000件程度)を想定しています。

bulkはデータの一定範囲あるいは全体を一括アクセスします。データ全体スキャンあるいは選択条件に合致する多量のレコードを一括してアクセスすることを想定しています。

ユースケース

2011-04-15T07:15:00.001+09:00

コラボレーションタスク監視起票は、Twitterでの注目発言の発生を監視し、注目発言が発生したときに、この発言に対応するためのタスクを起票するコラボレーションです。

アプリケーション開発におけるモデリング作業の中でこのコラボレーションをどのように抽出してくるのかというのが論点の一つになります。これは、利用者の要求とコラボレーションの結びつけるモデル要素が必要なことを意味しています。

いうまでもなく、このモデル要素とはユースケース(use case)です。ユースケースは、システムの振舞いモデルであると同時に利用者の目的と、目的を達成するための物語を記述したモデル要素です。

ユースケースは、アクターの目的をアクターとシステム間のインタラクションの列として記述します。通常は、自然言語によるシナリオとしてこのインタラクションを記述します。

UMLでは、ユースケースを具象化したものがコラボレーション、コラボレーションを抽象化したものがユースケースという関係になります。

以下の図はコラボレーションイベント監視タスク起票を利用者の要求と結びつけるユースケースであるユースケースイベントを監視して対応するタスクを起票するを追加したものです。ユースケースイベントを監視して対応するタスクを起票するは、利用者視点での利用者とシステムのインタラクションをシナリオとして記述します。

そして、コラボレーションイベント監視タスク起票はこのユースケースイベントを監視して対応するタスクを起票するを実現(realize)する、という関係(relationship)になるわけです。(UMLでは、ユースケースをコラボレーションが実現するという関係を、実現シンボル(典型的にはインタフェースをクラスが実現の用途で使用)で記述できるのですがJudeではサポートしていないようなので、依存(dependency)で記述しています。)

開発の手順としては、問題領域のドメインモデルをざっくりと作りつつ、利用者の要求をユースケースとしてモデル化。ユースケースを実現するためにドメインモデルを調整、という流れになります。

ここで、ユースケースとドメインモデルをつなぐモデル要素としてコラボレーションが登場することになります。このコラボレーションをコードの自動生成の枠組みに結びつけることができれば、自動生成のターゲットが大きく広がります。

SimpleModelerでは、ユースケース、コラボレーションをScala DSLで記述して、(同じくScala DSLで記述した)ドメインモデルと結びつけるような方向でユースケースからコラボレーションを経てドメインモデルに至るトータルなモデリングプラットフォームを提供したいと考えています。

ユースケース周りは、ロバストネス分析など色々とおもしろい話題があるので、SimpleModelingでの扱い、SimpleModelerでのサポート方針といった切り口でブログでも取り上げていきたいと思います。

コラボレーションと拡張点

2011-04-14T18:00:00.002+09:00

コラボレーションイベント監視タスク起票は、Twitterでの注目発言の発生を監視し、注目発言が発生したときに、この発言に対応するためのタスクを起票するコラボレーションです。

話のそれついでにコラボレーションに関連するモデリング上の話題を続けます。
コラボレーションの導入はコードの自動生成が重要な目的です。
コード生成を行うためには、模型的な意味で図形が配置されているだけでは情報量は不十分で、より詳細な情報を記述しなければなりません。
このような情報の一つに前回の記事で説明した「ドメインルールはTemplateMethodの骨組みのスロットに差し込む拡張部。アプリケーションの構成定義画面でパラメタの変更が可能」といったものがあります。
つまり、ドメインルールのところで、カスタマイズが可能なわけですが、コラボレーション側でもカスタマイズが必要な場合があります。
この目的に、UML標準部品である拡張点(extension point)を用いることができます。拡張点は(通常はユースケースに使うのですが)コラボレーションのインタラクションの一部を拡張するためのスロット的なポイントです。拡張点名を記述し、それに対する具体的な拡張のコラボレーションを拡張(extend)関係で記述します。
拡張点を用いて、コラボレーションイベント監視タスク起票のより詳細な情報を記述した図が以下のものです。

コラボレーションイベント監視タスク起票は、拡張点イベント監視を持っており、ここに拡張を実現するコラボレーションとしてコラボレーション注目発言拡張を指定しているので、注目発言を監視するコラボレーションとして動作する、というわけです。(補足ですが、この図の趣旨からは、注目発言ピックアップの対象がTwetterとなっているのは、DoainRule注目発言ピックアップの設定、ということになります。
この他にもコラボレーションをカスタマイズするメカニズムとしてステレオタイプ、タグ付き値を使用することができます。
UMLでカスタマイズを記述するとこの図のような形になるわけですが、これでは情報が不足ではないか、と思われるかもしれません。
実際のところ、その通りで、本当にコードの自動生成を行うということであれば、相当量の情報をタグ付き値などを使って設定しなければなりません。
つまるところ、UMLでモデルを記述する場合でも、結局のところ情報の過半数はテキスト情報として入力しなければならないわけです。そうであれば、始めからテキスト形式の言語で記述したほうがよい、というのがSimpleModelerのアプローチです。
テキスト情報から、上記の図レベルのものはプログラムで生成することが可能です。どのコラボレーションにどのような拡張点があるのか、といった情報をざっくり見るにはツールが生成した図を見れば十分であり、わざわざモデリング時に手で入力する必要はないわけです。
SimpleModelerでは、コラボレーションとドメインルールによって、アプリケーションの振舞いのプレースホルダーを記述し、ここから実行フレームワーク上で動作するコード(フレームワークの設定情報になるかもしれない)を生成するという方向で、アプリケーションの振舞いをコードに落とすことを考えています。

コラボレーション

2011-04-13T08:36:00.000+09:00

ドメインモデルにおけるロジックの抽出、記述方式について検討しています。
前々回にドメインモデルの例として以下の図を作成しました。これは、ServiceEvent、ServiceResourceの導入がクラウド向けの工夫ですが、基本的には従来からあるドメインモデルの静的構造側面を記述しています。

前回は、ドメインオブジェクトとしてDomainRuleを導入することで、ドメインロジックをドメインモデルとして記述できるようにしました。それが以下の図です。

ドメインルールはあくまでもルールを記述するオブジェクトなので、記述するロジックも受動的なものになります。何かの処理の中で、ドメインが内包しているルール(たとえば消費税の計算)を使用するというのが、ドメインルールの基本的な使い方になります。
つまり、受動的なロジックであるルールを駆動する能動的なロジックが必要になるわけです。この能動的なロジックの記述はドメインモデルではなく、アプリケーションモデルとしてモデル化するのがSimpleModelingのアプローチです。アプリケーションモデルは、アプリケーションの利用者が目的を達成するための構造、振る舞いを記述するモデルです。アプリケーションモデルは、アプリケーションの文脈(プロダクトライン、ユースケースファミリなど)として定義されているドメインモデルを操作して、利用者の目標(目的を具体化した物)を達成していきます。SimpleModelingのモデリングアーキテクチャにおけるドメインモデルとアプリケーションモデルの位置付け、関係についてはいずれ説明したいと思います。
ここでは、アプリケーションを構成する能動的なロジックは基本的にアプリケーションモデルで定義するのが基本的な考え方として検討を進めます。
アプリケーションロジックの網羅的な抽出や詳細化はアプリケーションモデルを作成する段階で行うとしても、ドメインモデルの段階でもある程度の抽出は可能です。また、ドメインモデルの構造もアプリケーションモデルから利用可能な形に調整する必要があるので、ドメインモデルを作成する段階で代表的なアプリケーションロジックを記述しておくのは有用です。
アプリケーションロジックの抽出をこの段階で行うのはやや早い感もありますが、代表的な物を明確にしておくことは、モデルの目的を明確化することになるので、分かっている範囲で行っておくのがよさそうです。
アプリケーションロジックについては、ユースケース分析の中で網羅的に抽出し、ドメインモデルに反映していくことになります。
この目的で導入するモデル要素がコラボレーション(collaboration,協調)です。コラボレーションは、UMLの標準モデル要素でオブジェクト間のメッセージの送受信であるインタラクション(interaction)を(目標を達成する単位で)束ねたものです。(UML1とUML2でコラボレーションの定義が変わってしまったのですが、ここではUML1的な意味で使っています。)
コラボレーションイベント監視タスク起票を追加したドメインモデルは以下の図となります。ボクの使っているJudeではコラボレーションシンボルが使えないみたいなのでユースケースシンボルにステレオタイプcollaborationを記述して代用しています。(UMLのコラボレーションシンボルは破線の楕円です。)

コラボレーションタスク監視起票は、Twitterでの注目発言の発生を監視し、注目発言が発生したときに、この発言に対応するためのタスクを起票するコラボレーションです。このコラボレーションがアプリケーションロジックに落とし込まれていくことになります。
この段階でコラボレーションを記述する目的の一つは、ドメインモデルの精度を高めるという目的に加えて、自動生成の対象を抽出という目的もあります。このあたりは、ドメインルールを導入するのと同じ目的です。
つまり、コードの自動生成のプレースホルダーとしての役割、さらにフレームワークと連動できるコラボレーションは、実行可能レベルのコード生成が可能になるでしょう。
以上のようにドメインモデルを振る舞いの視点でみるとコラボレーション、ドメインルール、ドメインエンティティの3階層で構成されます。この階層をモデル要素の関係を実装レベルで考えてみると以下のようなイメージになります。

コラボレーションはTemplateMethodパターン的な処理部。
ドメインルールはTemplateMethodの骨組みのスロットに差し込む拡張部。アプリケーションの構成定義画面でパラメタの変更が可能。
ドメインエンティティはデータベースに格納されるデータまたはサービスとやり取りするデータ。

ドメインルール

2011-04-12T06:46:00.001+09:00

前回はエンティティ間の静的な関係(relationship)を定義する以下のドメインモデルを作成しました。モデル駆動開発によるコードの自動生成でも、この範囲の自動生成はすでに実用化または実用化の射程距離内です。

ドメインモデルの重要な軸は(このモデルが典型的な例ですが)問題領域の静的な構造の記述です。従来のアプローチは、データベースに格納するデータとデータ間の構造が中心でしたが、ServiceEventやServiceResourceの導入によって、クラウド上のイベントやリソースもスコープ内に取り込もうというのがここまでの試みです。
クラウドアプリケーションのニーズに対応した形で自動生成の対象範囲が広がりますが、データの範囲をスコープにしているという意味では従来路線を踏襲した漸進的なアプローチともいえます。もう一段、コードの生成範囲を広げられないでしょうか。
モデル駆動開発の問題点の一つは、オブジェクトモデルとしてロジックを宣言的、形式的に記述する方法が確立されていない点です。UMLできちんと記述できるのは状態機械図まで。シーケンス図/コミュニケーション図(旧コラボレーション図)は一応演繹的にも記述できることになっていますが、実用上はインタラクションのインスタンスを具体例として記述するものと考えた方がよさそうです。OCL(Object Constraint Language)は有用ですが、文字通り制約を記述するための言語なので適用範囲が限られます。MDA(Model Driven Architecture)の基盤となるxUML(Executable UML)はこの部分をAction Language (MDA的にはAction Semanticsとその実現言語)で補完していますが、Action Languageは状態機械との連動がオブジェクト指向的には進化であるとはいえ(大多数のオブジェクト指向型言語がそうであるように)手続き型折衷オブジェクト指向プログラミング言語みたいなものであり、現時点の技術では手続き型プログラミング言語を導入しないとロジック記述の問題は解決しないと考えてよさそうです。(いずれこの部分を関数型言語や論理型言語が埋めていくことになるでしょうが、まだまだ先の話です。)
どちみちプログラミング言語的な記述が必要なのであれば、ActionLanguageを使うより、使い慣れているScalaやJava(その他お好みの言語)でロジックは書きたいところです。
そこで、コードの自動生成の対象範囲を広げるための仕掛けとしてSimpleModelingが用意しているドメインモデルのモデル要素がドメインルール(ステレオタイプDomainRule)です。ドメインルールは、ドメインに存在するロジック、責務の中でルールとして扱うと適切なものをオブジェクト化したものです。ドメインルールは以前から導入済みですが、クラウド時代でも引き続き有効なドメインオブジェクトです。
ドメインモデルの中でロジックを記述する方法としては、エンティティオブジェクトのオペレーションとして定義する方法もあります。ドメインルールとはケースバイケースで使い分けることになります。
オペレーションとドメインルールの選択は以下の項目を目安にするとよいでしょう。

アプリケーションのカスタマイズ項目になりそうなものはドメインルール。
複数のドメインオブジェクトを横断的に操作するものはドメインルール。

ドメインルールを追加したドメインモデルは以下の通りです。

以下の3つのドメインルールを追加しています。

注目発言ピックアップ: Twitterからツイートを検出するルール
タスク生成: タスクを生成するルール
対応選択: Twitterのツイートから対応を選択するルール

DomainRule対応選択は、DomainRuleタスク生成と合成(composition aggregation)の関係になっており、タスク生成の一部として動作します。
この例では、ドメインルールからドメインイベントやドメインリソースに対する使用(use dependency)を行っていますが、逆にドメインイベントやドメインリソースからドメインルールへの使用(use dependency)もありえます。例えば、消費税計算ルールを請求書発行イベントから使用するといったケースです。
ドメインルールは、ドメインモデルの中でルールを特定するプレースホルダーの役割を担います。前述したようにUMLではロジックを記述できないので、ドメインモデルでできることはここまでという割り切りです。
ただし、ステレオタイプやタグ付き値、関連端(association end)といった修飾パラメタによって生成するコードを特定することができる可能性があります。
たとえば、DomainRuleタスク生成はfactoryというステレオタイプが付いていますが、適切なパラメタを与えればファクトリオブジェクトの実装に落とし込むことは技術的に可能でしょう。
実行プラットフォーム上で動作するフレームワークによって、相当な種類のドメインルールに対応する機能の受け口を実現できるはずです。このようにプラットフォームで対応済みのルールをドメインモデル上で使用することで、ドメインモデルからコード生成できる範囲が格段に広がるでしょう。
また、自動生成には至らなかった場合でも、ロジックのプレースフォルダーとしての存在意義は十分にあります。少なくても、アプリケーションに組み込むためのSPI(Service Provider Interface)といったものの自動生成は可能で、これだけでもずいぶん違うはずです。
ボクが開発しているDSLコンパイラSimpleModelerとマッシュアップフレームワークg3では、このような連携ができることを目指しています。

ドメインモデルを具体的に考えてみる

2011-04-11T08:10:00.000+09:00

ドメインモデルとデータストアのマッピングについて検討を始めたところで、話がだいぶそれてきましたが、もう少しそれてみたいと思います。
DomainResourceとServiceResourceを導入したので、試しにDomainResourceとServiceResourceが混在するドメインモデルについて具体的に考えてみました。
以下の図はTwitterのタイムラインを監視して、何らかの基準に沿ったツイートを検出し、何かの対応をすることを管理するタスクを起票するアプリケーションのドメインモデルです。タスクはNozbeのタスクとBacklogの課題として2つのサービスに同時に作成します。

こういったNozbeのタスクやBacklogの課題といった「概念」上は抽象の中に隠蔽されるオブジェクトをPIM段階のドメインモデルでどう扱うのか、というのが論点の一つ、というのがここまでの話でした。DomainResourceとServiceResourceを導入したメタモデルでは、抽象「概念」として隠蔽したいケース、具象「概念」として明示したいケースの両方に対応できるというのがミソです。
この図は具象概念として明示したいケースになります。
ドメインモデルでタスクとして扱うものは、実際には主にNozbeとBacklog上で利用者からの操作を行うことを想定しています。しかし、NozbeとBacklog間の同期やアプリケーション側での操作の目的で、自前のデータベースで管理するオブジェクトも必要になります。このオブジェクトがDomainResourceタスクです。そして、タスクからNozbeTaskとBacklog課題を集約(aggregation)します。
一方、アプリケーションが扱うイベントとしてDomainEventタスク起票とServiceEventTweet発生を定義しています。よりモデルの汎用化を進めるならServiceEventTweet発生に対応するDomainEventTweet発生を定義して抽象化しておくというアプローチも考えられます。
ドメインモデルの記述対象のスコープにも色々な切り口がありますが、一般的なのはデータベースに格納するデータの範囲です。この図の場合、DomainEventタスク起票, DomainResourceタスクがこれに当たります。
モデル駆動開発によるコードの自動生成でも、データベースに格納するオブジェクトの範囲の自動生成はすでに実用化されており、安定状態にある技術です。つまり、DomainEventタスク起票, DomainResourceタスクは自動生成のスコープ内に入ってきます。
しかし、ドメインモデルの記述がこの範囲であれば、自動生成の対象範囲もここまでということになります。
ServiceResourceやServiceEventといった外部サービスが提供するドメインオブジェクトを導入する目的は、もちろんドメインモデルの精度を上げることもありますが、実利的にはサービスが生成するイベントやリソースに対応するコードの自動生成を行える可能性が出てくることが大きいでしょう。
ServiceResourceやServiceEventをドメインモデル上で扱うことによって、twitterのストリームを監視したり、RESTで各種サービスのリソースに対してアクセスをしたりといったコードを生成することは技術的には十分射程範囲です。こういった、アプリケーションの部品として何回も何回も繰り返し作り続けられている処理を定型化して、自動生成の対象にできることが、モデリングという要求と実装の中間に位置する作業を行う具体的な価値であり、大きな動機です。このスコープを広げるために、ドメインモデルのメタモデルの拡張と、メタモデルと実装とのマッピングを進めていくことが重要となってきます。

メタモデルとステレオタイプ

2011-04-08T08:01:00.000+09:00

PIM段階のドメインモデルで、自前管理のオブジェクトと他サービス管理のオブジェクトの区別をするのか、その区別はPSM段階まで留保しておくのか。
一意的に決めてしまうのは難しい問題で、ケースバイケースで選択したいところです。短手番でサービスをマッシュアップしてアプリケーションを構築する用途では前者のニーズが高そうですし、長期間にわたって持続的にシステム構築を続けていく、基幹システムでは後者のニーズが高いでしょう。
SimpleModelingは、どちらかというと前者の用途をターゲットにしているので、前者向けに特化したメタモデルを整備しても良いのですが、場合によっては後者の応用にも対応できるのに越したことはありません。
そういったことをつらつらと考えている中で、思いついたのは以下の図のメタモデルです。

以下のメタオブジェクトが定義されています。

Entity: アプリケーションが永続的に使用するオブジェクト
DomainResource: Resourceタイプのドメインオブジェクト
ManagedEntity: アプリケーションの管理下にあるEntity
ServiceEntity: 他サービスの管理下にあるEntity
ManagedDomainResource: アプリケーションの管理下にあるDomainResource
ServiceDomainResource: 他サービスの管理下にあるDomainResource
ServiceResource: ServiceDomainResourceの別名

EntityとDomainResourceが元々あったメタオブジェクト。SimpleModelingのメタオブジェクト全体でアプリケーションが永続的に使用するオブジェクトがEntity。Entityの一種でドメインモデルのリソースオブジェクトがDomainResourceとなります。
ManagedEntityとServiceEntityは、EntityにミックスインしてEntityの所属を記述するために追加したメタオブジェクトです。
そして、DomainResourceかつManagedEntityなドメインオブジェクトがManagedDomainResource、DomainResourceかつServiceEntityなドメインオブジェクトがServiceDomainResourceです。
さらに、ServiceDomainResourceの別名としてServiceResourceを用意します。
このメタモデルをステレオタイプで表現したクラス図表現は以下のようになります。

このステレオタイプの使用方法は以下の2パターンを念頭においています。

DomainResourceはManagedDomainResourceの省略形として用い、ServiceResourceと組合せて使うことで、PIM段階で自前エンティティと他サービスエンティティを区別しながらモデリングを行う。
PIM段階ではDomainResourceとしておき、PSM段階でManagedEntityやServiceEntityを追加し定義して、自前エンティティと他サービスエンティティを区別する。

具体例でみていきましょう。
(1)ServiceResourceを使う場合は以下のようになります。DomainResourceと同様に拡張を行ったDomainEventも使用しています。Tweet発生にはタグ付き値にservice=twitterを定義して、TwitterによるTweet発生であることを記述しています。(ボクが使っているJudeではタグ付き値がクラスシンボルに表示されないようなので、コメントで定義しています。)

次は、(2)ManagedEntity/ServiceEntityを使う場合です。
まず、PIM段階では以下のようにDomainResourceやDomainEventを使用していきます。具体的な実現方法はここでは記述しません。

これをPSM段階で具体的なサービスの活用を加えたものが以下のものです。Tweet発生にServiceEntityを加え、タスク起票とタスクにManagedEntityを加えています。また、Tweet発生にはタグ付き値にservice=twitterを定義して、TwitterによるTweet発生であることを記述しています。

この例はTwitterのツイートの取り込みを念頭においているものなので、「(1)ServiceResourceを使う」のが適している感じです。
もちろん、アプリケーションの構想段階でドメインオブジェクトのどの部分を外部サービスのものを借りてくるか未定の場合には「(2)ManagedEntity/ServiceEntityを使う」記述方法が適しているでしょう。

ドメインモデルとクラウドリソース

2011-04-07T07:15:00.000+09:00

前回「ドメインオブジェクトとデータストアのマッピング」の検討は、SimpleModelingが元々定義しているドメインオブジェクトを検討対象にしています。つまり、クラウド登場前のドメインオブジェクトですね。伝統的なドメインモデルを、クラウドアプリケーションが扱わないといけない多種多様なデータストアにどのように格納管理するのかというのがテーマです。

それとは別の次元で、クラウド時代に入ってドメインモデルのスコープやドメインオブジェクトのモデル化対象をオーバーホールして見直す必要があると感じています。

クラウド時代以前のドメインモデルは基本的に自前でデータベースで管理するオブジェクトが中心で、システム外のオブジェクトはアクターという形で特別扱いして凌ぐ形になっています。

一方、クラウドアプリケーションの場合、複数のサービスをマッシュアップして構築するのが主流となるため、利用者のメンタルモデルに登場するオブジェクト、すなわちアプリケーションが扱うオブジェクトは、必ずしも自前のデータベースで管理するオブジェクトとは限りません。場合によっては、ほとんどが外部オブジェクトということになるでしょう。そのようなケースでこれらをアクターとしてモデル化するのは明らかに不適切です。

この問題に対応するには以下の2案が考えられます。

ドメインモデル(PIM段階)を概念モデル的な抽象度の高いモデルと位置づけ、設計時(PSM段階)に自前データベースか他サービス上のリソースかをモデル化する。
ドメインモデルの初期作成段階(PIM段階)からサービス上のリソースを専用のオブジェクトで表現する。

(PIM=Platform Independent Model=プラットフォーム独立モデル、PSM=Platform Specific Model=プラットフォーム固有モデル)

つまり、ドメインモデルを構成するオブジェクトとしてクラウド上のリソースを一級市民として扱うのか否かという問題ですね。

メタモデルとしての汎用性、拡張性という意味では前者(クラウドリソースをドメインモデルの一級市民として扱わない/PSM段階で導入)が美しいと思います。

しかし、クラウド時代にはクラウドサービスの活用がアプリケーションの中心的な関心事の一つであり、利用者自身も使用しているリソースとリソースを提供しているサービスの関係を意識するケースも多くなるため、PIM段階で自前データとクラウドリソースを明確に区別しておいたほうがなにかと得るものが多そうです。

また、設計実装との連続性という意味では、自前とサービス活用ではアプリケーションの構築のアプローチが異なってきます。PIMレベルのドメインモデルを構築した段階で、ざっくりとした工数見積もりができることも重要で、そういう意味でも自前オブジェクトとクラウドリソースをPIM段階で分離しておくのが実用的なアプローチであると考えています。

また、前者の美しいアプローチで起きそうな問題点として、自前リソースとクラウドリソースのアクセススピードの問題もあります。これは、複数のサービスの共通部分を抽出、汎化して、適切な抽象度のインタフェース経由で提供することができても、性能差がありすぎると事実上同じようには使えないという問題です。

たとえば、WebDavをExplore(Windows)やFinder(Mac)の配下に置いてExcelファイルなどをクリックで開いて使う使い方はとても便利ですが、UNIX shellの上からfindしたりとかそういう細かい使い方をしようとすると速度が遅すぎて心が折れてしまいます。後者のような使い方の場合、サービスに処理プログラム(クロージャ的な物)を投げてサービス側で処理を実行するエージェント的なアプローチ(レトロな言い方ではRJE(Remote Job Entry)かな)の方がより適切です。(WebDavは残念ながらこういう使い方はできませんが、これからのクラウドサービスではこういった利用方法への対応も重要な課題になると思います。)

また、細かいところでは故障頻度にも相当大きな差が出てきます。故障発生確率の大小で利用者への見せ方が変わってきます。加えて、障害発生時の可用性の問題も重要です。マッシュアップしている多数の外部サービスの一つが落ちただけで、自サービスがまるごと動かなくなるのは、アプリケーション的にはかなり恥ずかしいので、自サービスの根幹部と周縁部を切り分け適切に責務分割を行うことが必要です。

こういった要件の実現はアプリケーションアーキテクチャの根幹に関わってくるので、PSM段階から意識を始めるのはやや遅い感じで、PIM段階で意識の上に上げて起きたいところです。

今の所、以上のようなことを考えながら、机上で試行錯誤している状況です。たとえばドメインオブジェクトの種別DomainResourceを自前リソースと位置づけ、クラウド側のカウンターパートにCloudResourceやServiceResourceといったオブジェクトを新規に導入するのか、というようなことを検討しています。

ドメインオブジェクトとデータストアのマッピング

2011-04-06T09:18:00.000+09:00

SimpleModelingと呼んでいるモデリング手法をクラウド向けに拡張する作業を行っています。
その一つの柱がドメインモデルの拡張です。ドメインモデルの拡張の一つのアプローチは、オブジェクト種別ごとの実現方法の確立です。モデルから設計/実装へ落し込むときの指針が一つも目標ですが、最終的にはDSLコンパイラによる自動コーディングをターゲットにしています。
SimpleModelingではドメインモデルを構成するオブジェクトに対して用途に応じた分類行い、プロファイルとして定義しています。代表的なオブジェクトは以下のものです。

Actor: システム外に存在する(リアル)オブジェクトの代理オブジェクト。(例：利用者)
Event: システムで発生する出来事。
Resource: システムが管理するリソース。
Powertype: ドメインオブジェクトのパワータイプ。(実装時には区分コードなどで実現される)
Rule: ドメインで使用される規則。

これらのオブジェクトの種別は、今までのソフトウェア開発でも有効ですが、クラウドアプリケーションではその価値がさらに高まります。というのは、クラウドアプリケーションではデータストアの選択が一つの大きな関心事になるからです。今までの企業システム、Webシステムでは大規模あるいは特殊要件がない限りはデータベースとしてRDBMSを一つだけ用いるということが普通です。このため、ドメインモデルとしてどのようなものを作るにしても、どうRDBMSに落し込むのかという設計へのマッピングが重要でした。しかし、クラウドアプリケーションでは複数のデータストアを用途に応じて使い分ける必要があります。一番大きいのがトランザクションやデータモデルの柔軟性というRDBMSの持つ特性が、スケーラビリティと相反する関係になる点です。この他にも半構造データの取り扱いや、分析処理向け性能特性など、必要に応じてデータストアを使い分けていく必要があります。このため、クラウドアプリケーションではRDBMS一刀流では用途が限定されてしまいます。用途に応じてデータストアを使い分けていく必要があります。

データストアの種類

SimpleModelingのドメインモデル拡張での一つのアイデアは、ドメインモデルのオブジェクト種別ごとにデータストアとのマッピングの相性を定義することが有効ではないかということです。設計の指針にもなりますし、DSLコンパイラでのコード生成でも活用できます。
データストアの種類として以下のものを想定しています。

RDBMS: 汎用的なデータストア。トランザクション。SQLによる高度な問合せ。複雑なデータ構造。スケーラビリティは低い。
分散ディレクトリ: システムデータ管理向け。利用者情報などシステム管理データにアプリケーションが相乗りする使用方法。ほとんど参照でまれに更新されるデータに使用。トランザクション、SQL的な高度な問合せ、複雑なデータ構造はない。スケーラビリティは高い。
分散キャッシュ: キャッシュデータの格納向け。ほとんど参照でまれに更新されるデータに使用。永続性はない。トランザクション、SQL的な高度な問合せ、複雑なデータ構造はない。スケーラビリティは高い。
KVS: 汎用的なデータストア。トランザクション、SQLによる高度な問合せ、複雑なデータ構造はない。スケーラビリティは高い。
カラムナDB: 分析処理向け。全件走査に強い。スケーラビリティは高い。トランザクション、SQLによる高度な問合せ、複雑なデータ構造については要調査。
文書DB: 半構造データの格納。その他の特性は要調査。
プログラム埋込み: データをプログラムに埋込んで配備。高速動作。エラー要因、配備の複雑度を低減。データとアプリケーションのライフサイクルが一致する場合、特に有効。

「プログラム埋込み」もデータストアの一種として考えています。データをプログラムに埋め込んで配備する手法は、従来のアプリケーション開発では邪道ですが、クラウド上では案外侮れない手法です。
クラウドプラットフォームでは、プログラムがシステム上に多数存在する物理マシンに配備されるわけですが、この配備のメカニズムに乗って同時にデータも配備できるというメリットがあります。また、DSLコンパイラを使うと、プログラム開発とデータ定義を別々に行い、配備の段階で集約するといったことも可能になるので、データをプログラム内に埋め込むことのデメリットを緩和することができます。
この他のデータストアとしてはCDN(Content Dlivery Network)が考えられますが、HTMLページなどの静的な成果物の配備が主な用途なので考慮の対象外にしています。(場合によっては対象に加えるかもしれません。)

マッピング

ドメインオブジェクトとデータストアのマッピングは以下の図のものを考えています。用途を問わずすべてのデータをRDBMSを入れるというアプローチも当然あるわけですが、ここでは用途別により適したデータベースという視点で分類しています。

詳細は後日。

クラウドアプリケーションのモデリング考

2011-04-04T08:22:00.001+09:00

オブジェクトモデリングは、元々の源流がシミュレーション向けプログラミング言語SIMULAにあることからも分かる通り、人間が認知する世界観を基本構成要素とするモデリング手法です。
ビジネスモデリング、要求分析、システム分析、システム設計、実装(プログラミング)の各作業フェーズで同じモデル(オブジェクトとオブジェクト間の関係)を持ちまわることによってフェーズ間のインピーダンスミスマッチを低減することができ、要求モデルと実装の乖離を防ぎ、反復型の開発を可能にします。

ただ、オブジェクトモデリングでモデリングの要件を全て満たせるのかというと、まだまだ力不足です。
1つは、人間の認知モデルをベースにしているため、形式的な処理が難しいということです。オブジェクト間の関係は宣言的に記述することができますが、これらのオブジェクトによって構築される協調関係を宣言的に記述したり、形式的に取り扱って検証や合成、最適化といったことはできません。
1つは、ビジネスモデリングから実装までモデルを持ちまわる事ができるのが問題領域の静的構造に限られること。動的モデルについては状態機械の範囲で部分的に持ちまわることができるだけです。これは、前述の「オブジェクトによって構築される協調関係を宣言的に記述できない」という問題に起因しています。

このため、オブジェクトモデリングというと「問題領域の静的構造」に焦点が絞られることになりがちで、たとえば、これをどう実装するのかという切り口のドメイン駆動設計のような方向に技術が伸びていきます。
それ自身は適切なアプローチですが、オブジェクトモデリング全体としてはシステムの振舞いをオブジェクト間の協調としてモデル化していく方向への拡張をしていかないと、汎用的なモデリング手法として適用範囲を広げることは難しいでしょう。

振舞いモデルについては、(単なるお絵描きではない)データして活用可能なモデルを作成することができないとなると、モデリング作業そのものが無駄な作業といえなくもありません。
「問題領域の静的構造」だけモデリングするのであれば、DOAのアプローチで十分ですし、軽量開発の場合ER図だけ用意すれば十分でしょう。
そして、振舞いモデルをモデリングできないのであれば、ER図をかいた後、いきなりプログラミングが効率のよい開発手法となります。

オブジェクトモデリングの柱の一つはユースケースです。ユースケースは「物語」によって利用者要求の暗黙知を抽出し、シナリオ分析技術によってオブジェクトの静的構造と協調を構築する技術とボクは理解しています。
振舞いモデルを宣言的、形式的に扱えない弱点を持つオブジェクトモデリングですが、このユースケースがあることによって「問題領域の静的構造」だけのモデリング手法ではなく、総合的なモデリング手法として汎用的に使用できる技術体系となっているといえます。
ただし、このユースケースはかなり難しい技術で、うまく使いこなせないのであれば背伸びしてオブジェクトモデリングをするより、ER図＋プログラミングの方が効率よく精度の高いシステム構築ができるでしょう。

オブジェクトモデリングの現状分析はこんな感じですが、これをクラウドアプリケーションに対して、どう適用していくのかというのが、ここ数年考えてきたことです。
まだまだ、試行錯誤の段階ですがいくつか切り口があります。

1つは、手堅いモデリング技術であるドメインモデルをクラウドアプリケーション向けにチューンするアプローチ。
ソーシャルグラフをどのようにモデル化するのかというアナリシスパターン的な切り口、モデル構造の雛形を定めるメタモデルやプロファイルの切り口、クラウド的なトランザクションやBigDataといったプラットフォームに落し込む手法の整備が必要です。

また、ユースケースをクラウドアプリケーションに適用する手法についても整備が必要です。
従来型のユースケースは、利用者とシステムのショートトランザクション粒度のインタラクションがターゲットでしたが、クラウド環境では非同期処理、並行処理、ロングトランザクションといった要因が重要になってくるので、そのままの形では適用が難しいでしょう。
また、UX(User Experience)技術の興隆によって、ユースケースの適用範囲も変わってきます。
従来のユースケースの運用では、ドメインモデルとの接続箇所が曖昧で、方法論としての整備も遅れていたので、この点の充実も併せて必要でしょう。

加えて、システムの振舞いモデル(オブジェクト間の協調モデル)に対してのアプローチを考える必要があります。
ここは元々従来もうまくいっていないところなので、クラウドアプリケーションでいきなり解決することは考えられません。
とはいえ、非同期、並列、分散がより重要なパーツとなってくるクラウドアプリケーションなので、何らかの対応策は考えたいところです。

アプリケーションの振舞いのアーキテクチャの側面では、要求駆動からイベント駆動への移行も重要です。
要求駆動は、たとえば画面にフォームを入力しエンターキーを押すとその延長で同期型でリクエストが発行されSQLが実行され結果が返されるといったアーキテクチャです。
それに対して、イベント駆動はクラウド上で発生する様々なイベントをアプリケーションがイベントハンドラで受けとり、都度小さな処理を自身のリソースに対して行ったり、協調動作する相方にメッセージを投げたりして処理を進めていくアーキテクチャです。
前者はシェルからCLIで動作させる単発のコマンド的な振舞い、後者は各種イベントを割り込みハンドラで拾いながら動作する制御システム的な振舞いです。
アプリケーションの振舞いが相当複雑化することが容易に推測できます。

大規模データへの対応では、DFD(データフロー図)的なアプローチが再び表舞台に出てきそうです。
エンタープライズ系の開発ではDFDは今でもよく利用されていると思いますが、実装時に手組みプログラミングになるのでその効果は限定的です。
クラウドアプリケーションで事情が変わってくるのは、大規模データの扱いにおいて手組みのプログラミングではなく、DFD的なモデルからHadoopのような大規模データ処理向けのコードを自動生成するアプローチが実用化されるかもしれないという点によります。
ここは、単なる転記を超えたプログラムが必要となるところで、手組みのプログラミングでは、Hadoopのようなフレームワーク向けに合わせる接合部のコーディングが煩雑、最適化やデバッグが難しいという問題があり、これは自動生成のコストをかけても十分に実用化できそうです。
この方面では、SQL的、関係演算的な切り口の言語で大規模データを扱うというアプローチもあり、動向が注目されます。

つらつらと書いてきましたが、現在は、こういった論点についてScala DSLモデルコンパイラSimpleModelerとサービスマッシュアップフレームワークg3を開発しながら試行錯誤を続けています。
ちょうど立ち止まっておさらいするのによいタイミングだと思うので、途中結果をブログにまとめよう思います。

Asakusa Scala DSL

2011-03-31T08:29:00.001+09:00

基幹バッチをターゲットにしたHadoopフレームワークAsakusaのScala DSLにトライしています。

DSLの素案が固まってきたので、SimpleModelerに組み込んでみました。

DSLを検証するために使用したモデルは、Asakusaのホワイトペーパーにある以下の図7です。
比較的シンプルですが、基幹バッチのデーターフローをモデルとして記述しています。

Asakusaでは、このようなデータフローをJava DSLで記述するわけですが、ここにScala DSLを用いるとより簡潔に記述できるのではないかと考えているわけです。

このデーターフローをScala DSLで記述したものが以下の会計処理バッチ.scalaです。
具体的な説明は追々していこうと思いますが、ここではぱっと見た感じ、簡潔に明快な形で記述できているような印象を持って頂けるとうれしいと思います。

このScala DSLの設計のポイントはScalaの型パラメータを使って、型安全にモデルを記述している点です。
少しの記述ミスでもコンパイラがエラーで教えてくれる点が、Scalaのような静的型付け言語をDSLのホスト言語として使用するメリットですが、型パラメータを使用することでこの長所を最大限に活かすことができます。

package sample

import org.simplemodeling.dsl.domain._
import org.simplemodeling.dsl.flow._

class 仕入明細データ extends DomainResource
class 仕入返品データ extends DomainResource
class 費用振替データ extends DomainResource
class 売価変更データ extends DomainResource

class 修正在庫振替TRN extends DataSet
class 修正未収収益TRN extends DataSet
class 修正在庫移動TRN extends DataSet
class 未払計上TRN extends DataSet

class 仕入TRN extends DataSet
class 在庫振替TRN extends DataSet
class 在庫移動TRN extends DataSet
class 未収収益TRN extends DataSet

class 計上済仕入TRN extends DataSet
class 計上済未収収益TRN extends DataSet
class 計上済未払費用TRN extends DataSet
class 更新済買掛残高TRN extends DataSet

class 請求エラーTRN extends DataSet
class 支払不可消込TRN extends DataSet
class 支払可消込TRN extends DataSet
class 照合済支払費用TRN extends DataSet
class 照合済未収収益TRN extends DataSet
class 照合済仕入TRN extends DataSet
class 照合済請求TRN extends DataSet

class 仕入データ extends DataSource4[仕入明細データ, 仕入返品データ,
                                     費用振替データ, 売価変更データ]
class 修正データ extends DataSource4[修正在庫振替TRN, 修正未収収益TRN,
                                     修正在庫移動TRN, 未払計上TRN]
class 売価変更在庫変更TRN extends DataSet
class 仕入データTRN extends DataSource4[仕入TRN, 在庫振替TRN,
                                        在庫移動TRN, 未収収益TRN]
class 残高更新TRN extends DataSource4[計上済仕入TRN, 計上済未収収益TRN,
                                      計上済未払費用TRN, 更新済買掛残高TRN]
class 請求TRN extends DataSet
class 会計データTRN extends DataSource7[請求エラーTRN, 支払不可消込TRN, 支払可消込TRN,
                                        照合済支払費用TRN, 照合済未収収益TRN,
                                        照合済仕入TRN, 照合済請求TRN]

case class 仕入データ取り込み(cout: Port[売価変更在庫変更TRN]) extends Operator12[仕入データ, 仕入データTRN, 売価変更在庫変更TRN](cout)
case class 残高更新(cin: Port[修正データ]) extends Operator21[仕入データTRN, 修正データ, 残高更新TRN](cin)
case class 照合処理(cin: Port[請求TRN]) extends Operator21[残高更新TRN, 請求TRN, 会計データTRN](cin)

// 図7 改善された会計処理バッチの処理フロー
case class 会計処理バッチ extends Flow32[仕入データ, 修正データ, 請求TRN,
                                    会計データTRN, 売価変更在庫変更TRN] {
  start op12(仕入データ取り込み(out2)) op21(残高更新(in2)) op21(照合処理(in3)) end
}

このScala DSLからSimpleModelerで生成したフロー図が以下のものです。
データフローの概要をつかむのに十分な図が得られていると思います。

このような図が生成できるということは、SimpleModelerの内部でデータフローのグラフ構造が適切に構築できたことを示しています。
このグラフ構造を使って、モデル検証を行ったり、モデルのクロスリファレンスを作成したり、さらにAsakusa Java DSLの自動生成を行うことが可能のはずです。

Asakusaでは、各種DSL向けにAsakusa Hadoopコンパイラの内部モデル(Asakusa IR?)が提供されるとのことなので、それを待ってAsakusa Hadoopコンパイラの連携部を作成していく予定です。

Access-Control-Allow-Origin

2011-02-28T06:01:00.001+09:00

WebブラウザからRESTをアクセスするプログラムを開発するときに、困るのがクロスオリジンの問題。
Webページ上で動作するJavaScriptプログラムは、Webページをダウンロードしたサイトにしかアクセスができない、というアレです。

プログラム開発中では、作ったプログラムをわざわざサーバーに上げるといったような作業が必要となるため、とても不便です。
また、運用時でもREST APIを一般に公開する場合には、大きな制約になります。

この問題は従来JSONPで回避してきましたが、最近はAccess-Control-Allow-Originという手法があるのを知り、g3に実装してみました。

Cross-Origin Resource Sharing

Access-Control-Allow-Originはブラウザ側でのクロスオリジンの選択をするために必要な情報を、HTTPのヘッダにクロスオリジン情報を付加するものです。
ブラウザは、従来はクロスオリジンであればすべて拒否していたのを、ヘッダに許可情報がある場合はクロスオリジンを許可するという動きになります。

具体的には、GET, POST, PUT, DELETEではリプライのヘッダにAccess-Control-Allow-Originヘッダを設定します。

Servletの該当箇所は以下のようになります。(g3の実装なのでScalaです。)

resp.setHeader("Access-Control-Allow-Origin", "*")

GET, POST, PUT, DELETEにAccess-Control-Allow-Originをつけるだけでよいと勘違いしていて、ちょっとはまったのですが、実はOPTIONSでリソースアクセスに対するクロスオリジン定義を返さないといけないのですね。
以下の情報をヘッダに設定します。

Access-Control-Allow-Origin: クロスオリジンを許すURL。すべて許す場合は「*」。
Access-Control-Allow-Methods: Access-Control-Request-Methodに指定されたメソッドを返すのが丁寧っぽいですが、公開してるメソッドをすべてを毎回返すようにしても大丈夫のようです。
Access-Control-Allow-Header: Access-Control-Request-Headersで指定されている文字列を返します。ブラウザがチェック用に使っているみたいです。
Access-Control-Max-Age: このOPTIONSの設定の有効時間。この時間が過ぎると再度OPTIONSでクロスオリジン定義を取りにきます。

Servlet該当箇所は以下のようになります。

resp.setHeader("Access-Control-Allow-Origin", origin)
      resp.setHeader("Access-Control-Allow-Methods", "POST, PUT, GET, DELETE, OPTIONS")
      resp.setHeader("Access-Control-Allow-Headers", req.getHeader("Access-Control-Request-Headers"))
      resp.setHeader("Access-Control-Max-Age", accessControlMaxAge.toString)

Web Socketなど

2011-01-31T08:53:00.000+09:00

とある事情があって、g3にHTML5のWeb SocketやServer-Sent Event機能を追加してみました。
Web SocketはJettyの機能を利用しています。

今回使ったWeb SocketとServer-Sent Eventを使ったg3アプリケーションは以下のものです。

class Html5Service extends G3Application {
  port("/") html(<p>OK</p>)

  port("/sse") agent {
    case _ => {
      EventStream(System.currentTimeMillis.toString, 1000)
    }
  }

  port("/ws/chat") agent {
    case msg: Post => {
      new Post("/chat", msg.content)
    }
  } invoke("wschat")

  websocket('wschat, "/chat")
  websocket('wstimer, "/timer")

  timer("") agent {
    case msg: Post => {
      Post("/timer", "Time: " + System.currentTimeMillis)(
    }
  } invoke("wstimer")
}

動作概念図はこんな感じ。

「/」(e.g. http://example.com/demo/)にアクセスが来ると「OK」が表示されます。これは動作確認のため。

「/sse」(e.g. http://example.com/demo/sse)にアクセスが来ると、以下のようなServer-Sent Eventを返します。MIMEタイプはtext/event-streamです。

retry: 1000

data: 1292615603413

実現方式は簡単で、新たにtext/event-streamなメッセージEventStreamを追加しました。Server-Sent Eventの仕様はシンプルなので、サーバー側の仕組みもいたってシンプルです。
ただ、残念なことに現在の所、ブラウザが想定しているフォーマットと少しずれているのか、Safariではうまく動きませんでした。仕組みは簡単なので、原因が分かれば修正も簡単にできるでしょう。

「/ws/chat」は、チャットの入力となるHttpのURIです。g3のWebSocketチャネル「wschat」を経由して、WebSocketのポート「/ws/chat」にデータを出力しています。

WebSocketのポートとして、「/ws/chat」と「/ws/timer」が公開されています。「/ws/chat」は前述のように、HTMLのURIの「/ws/chat」からループバックして接続されています。このループバックによってチャット機能を実現しています。

「/ws/timer」は、タイマーからg3のWebSocketチャネル「wstimer」を経由して、タイマーからの入力を受取り、WebSocketに送信しています。

g3は、RESTのセマンティクスを軸にコンポーネントを疎結合して、非同期メッセージング、イベント駆動で動作させるフレームワークですが、WebSocketやServer-Sent Eventもシームレスに統合できることが確認できました。
上記のプログラムは、チャネル間を配線しただけの簡単なものですが、アプリケーションロジックをチャネルのエージェントとして配備することでより複雑な処理ができるようになります。
たとえば、一定時間ごとにEvernoteにアクセスして、取得した結果をWeb SocketやServer-Sent Eventでプッシュ配信する、というようなアプリケーションを簡単に作れるでしょう。

Androidのアーキテクチャ

2010-12-15T18:21:00.001+09:00

このところAndroidに集中して取り組んでいるのですが、その作業の中で、Androidアプリのアーキテクチャとして使えそうなものが見えてきたのでメモしておきます。

図で赤くなっているオブジェクトは、Androidの基本クラスでAndroid OS上で特別な機能を担うものです。これらのオブジェクトをベースとして、どのようなオブジェクト群を追加し、どのような責務配分をして全体をバランスさせるのかという点が論点となります。

このアーキテクチャでは、ControllerとModelという2つのクラスを導入して、上記の配線でActivity、Handler、Thread、Serviceを結びつけています。
ここで注意が必要なのは、ControllerとModelという名前。他に良い名前がないのでControllerとModelという名前を付けていますが、気持ちとしては(MVCではなく)PACアーキテクチャパターンのControlとAbstractionを意図しています。
UIデバイス周りの低レベルイベントはActivity(PACのPresentation)で処理し、Controller(PACのC)はUX領域のセマンティックイベントの処理を行います。
一方Serviceの方は、利用者以外のアクター、すなわち外部サービスや時間といった外部事象からのイベント処理を行います。
Modelは、アプリケーションロジックを記述します。データベースやファイルそしてDriver経由で外部サービスの呼出しを行います。
外部との連携はDriverとReceiverの2つのオブジェクトを用います。Driverは従来的なPull型の連携を行うドライバです。Receiverはクラウド的なプッシュ型連携を受け取るドライバです。

Androidは、ちょっと本格的なアプリケーションになると内部的には非同期メッセージを駆使したプログラミングモデルになってくるので、そのあたりをどうさばくのかというがアーキテクチャを考える上での軸の一つとなります。
Real-Time UML的にはタスク設計的なことも必要になります。

この図では直接見えてきませんが、このアーキテクチャは、Androidのスレッド構造にも配慮しています。肝になるのが、GUI用スレッドがGUIリソースを専有している点。Handlerが鍵となるオブジェクトです。

また、クラウドとスマートデバイスを統合したトータルでのアプリケーションアーキテクチャとの中でも機能するアーキテクチャである点も重要です。
この点は、非同期メッセージをプログラミングモデルの基盤に据えることで要件を満たせると考えており、その点をアーキテクチャに盛り込んでいます。