2012年10月31日水曜日

Scala Tips / ケースクラス設計原則

重厚な名前をつけてみましたが、内容はゆるふわです。

Scalaには色々な革新的な機能が導入されていますが、あえて日々のプログラミングで一番重要な機能は?と考えていくとケースクラスですよね。

ケースクラスは便利なので、なんにでも使いたくなってしまいますが、最近原則めいたことが分かってきたので、日々のプログラミング時の個人的な指針としています。

ケースクラスは直積

ケースクラスの利用方法を考える上で重要な指針となるのは、ケースクラスは「直積」という点です。Scalaでは直積はProductというトレイトで表現しますが、ケースクラスもこのProductが自動的にmixinされます。

また、直積に関連して代数的データ型という観点も重要です。このあたりの事情は「クラウド温泉3.0 (3) / 代数的データ型 on Scala」にも書きました。

原則

直積、代数的データ構造といった数学的な構成要素がケースクラスの土台になっているすると、ケースクラスではこの土台を揺るがすようなコーディングは慎むのが安全策です。

土台を揺るがす要因は以下の2点です。

  • 更新可能な変数を持っている
  • インヘリタンスで後付で振る舞いの変更が可能

これを避けるためには、ケースクラスは以下の使い方に留めるのが安全策となります。

  • ケースクラスは不変オブジェクトの実装に用いる。
  • インヘリタンスはsealedを用いて適用範囲を限定する。

つまり、ケースクラスは純粋関数型の範囲で使うということですね。

逆に、ケースクラス的な使い方をするクラスでも、不変オブジェクトではない場合はあえてケースクラスにしないというコーディングをします。こうすることによって、このコーディング方針を知っていれば、プログラムの意図が明確になりプログラムの可読性があがります。

以上、ゆるふわ指針でした。

2012年10月30日火曜日

Scala Tips / Option(18) - Boolean

昨日に引き続いてScalazの小ネタです。

OptionとBooleanの相互変換もよく出てくる処理です。普通に考えても簡単にできる処理ではありますが、より簡潔に書くことができればプログラミング効率も地味に上がってきます。

Option→Boolean

まず、OptionをBooleanに変換する処理です。OptionがSomeの場合はtrue、Noneの場合はfalseを得る処理になります。

この手の処理はmatch式が定番です。

o match {
  case Some(_) => true
  case None => false
}

しかし、Scalazを使うともう少し短くできそうです。

まずcataメソッド。

o.cata(x => true, false)

次はsomeメソッドとnoneメソッドのチェイン。

o.some(x => true).none(false)

少し短くすることができましたが、Someに格納されている値は無関係なのでもう少し短くしたいところです。

そこで登場するのが?メソッドと|メソッドのチェイン。

o ? true | false

これはかなり短くなりました。

と、ここでよく考えてみると、Scalazを使わないでもOptionにそのものズバリがありました。

o.isDefined

OptionからBooleanへの変換はOptionのisDefinedメソッドを使うのが結論です。

Boolean→Option

BooleanをOptionに変換するときには:

if (b) 1.some else none

とするのが普通ですが、Scalazを用いると以下のように書くこともできます。

b ? 1.some | none

いずれの場合も、「else none」や「| none」がちょっと悔しいですね。

Scalazだと以下のように書くことができます。

b option 1

optionメソッドはby-nameパラメタなので以下のように処理を記述することもできます。この使い方は結構使い出があります。

b option {
  ...何かの処理
}

諸元

  • Scala 2.10.0-RC1
  • Scalaz 2.10.0-M6

2012年10月29日月曜日

Scala Tips / Option(17) - orEmpty, orZero

Scalaプログラミングの要諦はOptionにあり、と常々感じるわけですが、Scalazを使うとさらにOptionが便利になります。

先日は以下の様なワンライナーが決まり、ガッツポーズがでました。(?)

target.orEmpty[List] ::: ~deps

targetはOption[T]型、depsはOption[List[T]]型です。

基本的には、targetの内容のTとdepsの内容のList[T]をconsで接続して一つのListにしたいわけですが、targetとdepsのそれぞれがOption型でどちらもNoneである可能性があるのが厄介です。

Java的なコーディングで普通に書くと、targetがSomeとNoneの2通り、depsがSomeとNoneの2通りの組合せで、4通りの組合せに対してifやmatchを用いた分岐を用いることになりそうです。

これは結構煩雑な処理になりますが、orEmptyメソッドとorZeroメソッド(またはunary_〜メソッド)を用いると上記のように完結に記述することができるわけです。

orEmptyメソッド

OptionのorEmptyメソッドは以下の処理を行います。

  • OptionがSomeの場合、Someの内容を型パラメタで指定したコンテナに格納して返す
  • OptionがNoneの場合、型Tの零元を型パラメタで指定したコンテナに格納して返す

ポイントになるのは以下の2点です。

  • 型パラメタで指定したコンテナを自動的に生成
  • Noneの場合は型Tの零元を自動的に生成

この2つの処理を型情報に従って自動的に行なってくれるので、プログラミングを大幅に省略できるわけです。

プログラムに登場する「target.orEmpty[List]」はtargetがSome[Int]ならSomeの中に入っている数値を入れたList[Int]を、NoneならList(0)を返します。

orZeroメソッド(unary_〜メソッド)

Optionのunary_〜メソッドはorZeroメソッドと同じものです。

OptionのorZeroメソッドは以下の処理を行います。

  • OptionがSomeの場合、Someの内容を返す
  • OptionがNoneの場合、型Tの零元返す

こちらも以下の点がポイントです。

  • Noneの場合は型Tの零元を自動的に生成

ノート

零元を自動生成するというのはわりと重要な機能で、Scalazの型クラスZeroによって実現しています。Monoidの便利さも零元(単位元)によるところが大きいことは言うまでもありません。

Scalazを用いると、こういった形で処理を完結に書けるのがよいですね。

ScalazはMonoidやTraverseのような大物もよいのですが、OptionWやBooleanWといった小粒の機能がなかなか便利なのもよいところです。

諸元

  • Scala 2.10.0-RC1
  • Scalaz 2.10.0-M6

2012年10月26日金曜日

SimpleModeler最新状況

SimpleModelerはメタモデルの拡張も含めて、色々と改造しているため、最新版がどうなっているのか分かりづらくなっています。

ちょうど今日のドメイン居酒屋用に図を作ったので、これを元にSimpleModelerの最新状況について説明します。




DSL

SimpleModelerの最新状況では以下のDSLの仕様を想定しています。

  • SmartDox DSL
  • CSV DSL
  • Mindmap DSL (XMind)
  • Excel DSL (予定)

基本となるDSLはSmartDox DSLです。

CSV DSL, Mindmap DSL, Excel DSLはモデルを部分的に記述するのに用います。

Scala DSL

SimpleModelerは元々Scala DSLをメインのDSLにしていたのですが、以下の理由によりSmartDox DSLに置き換えることにしました。

  • 日本語による仕様記述を書きにくい。
  • コンパイルが必要になるのは運用的にマイナス。

日本語による仕様記述はJavaに対してのScalaのアドバンテージでしたが、プレインテキスト文書であるSmartDoxをベースにしたSmartDox DSLの方がより簡単に書くことができます。

開発サイクル

現状では、SmartDox DSL生成、DSLマージ機能、Excel DSLが予定となっており、SmartDox DSL、CSV DSL、Mindmap DSLのいずれかからモデルを読み込んで成果物の生成を行います。

最終的には予定機能を実現後に以下の開発サイクルを想定しています。

  1. 基本モデルをSmartDox DSLで記述
  2. 追加部分をMindmap DSLなどで記述。ブレインストーミングで作成したモデルなど。
  3. SmartDox DSLとMindmap DSLなどをマージしたモデルをSmartDox DSLへ反映。
  4. Smartdox DSLを編集して最終モデルを作成。
  5. 各種成果物を生成。

SimpleModel

各種DSLで記述されたモデルはマージされて、SimpleModeler内部でSimpleModelというモデルとして表現されます。このSimpleModelから各種成果物を生成します。

コード生成

現在プログラム生成の基本プラットフォームと考えているのは以下の2つです。

  • Java EE
  • Play2 + Ext-JS
Java EE

Javaコードとしては、基本JavaにプラスしてJava EE Webプラットフォーム系の以下のアノテーションを付加したコードを生成します。

  • JPA
  • Dependency Injection
  • JAX-RS
Play2 + Ext-JS

Webアプリケーションとしては、個人的な好みもありPlay2とExt-JSの組み合わせによるRIAを基本ターゲットにしています。

クライアント側のExt-JSとサーバー側のScalaコードを生成します。

g3とg4

また、クラウドアプリケーションでのアプリケーション開発技法やフレームワーク技術を調査するために試作した2つのフレームワークg3(Cloud Serivce Framework)とg4(Android Framework)向けのコード生成も行います。

仕様書とクラス図

SimpleModelで記述したモデルから仕様書とクラス図を生成することができます。モデルに直接記述した情報だけでなく、誰が誰から参照されているといったバックリファレンス情報、直目しているクラスを中心にしたクラス図の生成なども行います。

Asakusa Framework

SimpleModelerでAsakusa FrameworkのDSLを生成することを計画中です。

SmartDox DSL用のデータフローの記述方式を思いついたので、この記述からAsakusa DSLを生成します。

現状の現状

現時点では、メタモデルを色々といじったこともあり、一時的に動かなくなっている機能があります。現在デバッグ中なので、近いうちに安定版をリリースしたいと思います。

2012年10月25日木曜日

Scala Tips / Scala 2.10味見(17) - NonFatal

Scala 2.10で導入される機能の中で、地味だけどちょっと注目しておきたいものとしてscala.util.control.NonFatalがあります。

Scalaプログラミングでも例外のハンドリングは引き続き重要項目です。scala.util.control.NonFatalは例外の分類に関するユーティリティ・オブジェクトです。

Javaの例外は大きく以下の4つに分類できます。

java.lang.Error
致命的なエラー
java.lang.RuntimeException
非検査例外
Runtime以外のException
検査例外
それ以外のThrowable
特殊用途

java.lang.Error(以下Error)とjava.lang.RuntimeException(以下RuntimeException)はどちらもthrows句で宣言しないでも発生する可能性がある例外です。その心は、システム側の致命的なエラー(Error)またはアプリケーションのバグ(RuntimeException)なので例外をキャッチしてもリカバリしようがないので、精密な例外ハンドリングが必要な場合以外は無視してよい、ということでしょう。

ご存知の通り、Scalaでは検査例外の機能がなくなってしまったので、java.lang.RuntimeExceptionとそれ以外のExeptionの違いがプログラミングに反映されなくなってしまう傾向は出てくるでしょう。

逆に、例外の使い方に対する制約もなくなったので、アプリケーションのニーズに従って例外を分類して使用するようにしておくと良いと思います。

例外に対する処理

例外に対する処理は概ね以下のものになります。

  1. エラー処理は放棄して上位に例外をそのまま上げる。
  2. 利用者にエラーを通知したりデフォルト値を返すなどして普通の処理に戻す。
  3. 例外を握りつぶす。(ログは取る事が多い)
  4. リトライする。

JavaではErrorとRuntimeExceptionは「1. エラー処理は放棄して上位に例外をそのまま上げる。」が基本操作となる例外と想定していると考えられます。

ここで問題となるのは、JavaではError扱いの例外であっても必ずしもシステム側の致命的な障害とは限らないということです。たとえば、StackOverFlowErrorは再帰呼び出しでスタックがあふれた時に発生するケースが多いですが、これは基本的にはプログラムのバグと考えてよいものです。

このため、このようなケースでは「1. エラー処理は放棄して上位に例外をそのまま上げる。」は適切ではなく、「2. 利用者にエラーを通知したりデフォルト値を返すなどして普通の処理に戻す。」や「3. 例外を握りつぶす。(ログは取る事が多い)」といった処理を選択する必要があります。

この切り分けの機能を提供しているのがNonFatalです。

NonFatalでは以下の例外を致命的なエラーと判定します。

  • VirtualMachineError(StackOverFlowError以外)
  • ThreadDeath
  • InterruptedException
  • LinkageError
  • ControlThrowable
  • NotImplementedError

これ以外の例外はErrorであっても、致命的例外とはみなさないということになります。

ControlThrowable

致命的エラーか否かという観点とは別に、制御フローの実装技術として例外を使うケースがあります。Scalaの基本ライブラリではscala.util.control.ControlThrowableがそれに当たります。この例外に対しては形の上で致命的エラーと判定します。こうすることで、アプリケーションがControlThrowableを誤ってキャッチしてしまうことを防ぎます。

使い方

NonFatalのScaladocでは、以下のような使い方を紹介しています。

try {
     // dangerous stuff
   } catch {
     case NonFatal(e) => log.error(e, "Something not that bad.")
    // or
     case e if NonFatal(e) => log.error(e, "Something not that bad.")
   }

つまり、NonFatalと判定される例外はキャッチしてしかるべきエラー処理をしますが、それ以外の例外はアプリケーションでのエラー処理は諦めるという使い方ですね。

Try

NonFatalが重要な理由の一つとして、scala.util.Tryがキャッチすべき例外の判定にNonFatalを使用していることがあります。

Tryが必ずしもすべての例外をキャッチしてモナドの文脈に乗せてくるわけではないという点は注意しておくべきです。致命的と判断された例外はそのまま例外のメカニズムに乗って上位に渡っていきます。

もう一点、TryがScala 2.10以降のエラー処理の重要なキーパーツになると思いますが、そのTryが致命的例外とそうでない例外の切り分けに使用しているロジックは、アプリケーション側でもできるだけ合わせておいたほうが得策です。そういう意味で、特別な考察が必要なケース以外はNonFatalを使うようにするという方針でプログラミングに臨むとよいでしょう。

諸元

  • Scala 2.10.0-RC1

2012年10月24日水曜日

トレイト・モデリング

先日行われたScala基礎勉強会はどの発表もとても刺激的でしたが、特に僕が触発されたのは:

  • Deprecating the Observer Pattern
  • JavaScript as an Embedded DSL

の2つです。

どちらも関数型言語のテクニックというより、トレイトの活用テクニックで、つまりオブジェクト指向プログラミングの最新技法ということができるでしょう。論文を見ていただければ分かりますが、その効果は驚異的です。

以前OFP(Object-Functional Programming)の三種の神器としてトレイトを取り上げましたが、恐らくScalaプログラミングという文脈では、その威力はモナドや型クラス以上でしょう。

つまり、Scalaをオブジェクトと関数のハイブリッドとしてのみの認識で見ているとScalaの実力を見誤ってしまいます。(これだけでもすごいのですが)

トレイトの導入によって、新次元のオブジェクト指向プログラミングができるという観点からの評価も必要でしょう。

モデリングにトレイトを導入

Scalaにおけるトレイトの威力は日々のScalaプログラミングで感じているわけですが、ちょっと思いついてSimpleModelerに組み込んでみたところ、モデリングの用途にもかなりいい感じになったということは「MindmapModelingと集合知(10) - トレイト」で説明しました。

この点をもう少し補足しておきましょう。



図の左上にあるのが、トレイトを用いたモデルです。A, B, Cがそれぞれトレイトで、クラスAがこの3つのトレイトをミックスインしています。

右上にあるのが、データベースのテーブルです。トレイトA, B, CとXの項目をすべて合体した表Xが定義されます。

下にあるのが、JavaやScalaといったプログラムです。データベースの表の各行は1つのオブジェクトとしてインスタンス化されます。

データベースの表の設計から開発を開始すると、表を構成する要素であるA, B, Cは他の表との共通部分であっても、共通部分ということはモデル上から陽には分かりません。設計者だけが知っている暗黙の情報ということになってしまいがちです。

このため表のメタデータから自動生成したJavaクラスではこういった共通情報をうまく抽出することはできません。このため、共通情報を操作するコンポーネントを用意するようなアプローチの適用が難しくなります。(逆に、動的言語だとこのあたりがスムーズにいきます。)

一方、モデルでトレイトを導入した場合は事情が異なります。上の例にあるようにデータベースの表ではひとつの大きな表になり、読み込んだオブジェクトもひとつの大きなオブジェクトになりますが、トレイトA, B, Cに対応する部分は、インタフェース(Javaの場合)やトレイト(Scalaの場合)としてプログラム化するので型安全にコンポーネントを適用することができます。

データベース中心設計への影響

現在は、データベースのER図と画面設計の二本立てで設計を進め、それぞれの実現であるデータベースとWeb UIを構築する開発方法が広く使われています。

このアプローチは余分なモデリングを必要としないのでプログラミング中心の開発とも相性がよくなっています。

従来のオブジェクト指向モデリングでは、オブジェクト・モデルとER図(あるいはRDBMSのデータベーススキーマ)のセマンティクス・ギャップは継承周りにとどまっています。これも大きなギャップではあるのですが、継承をできるだけ避けたり、Single Table Inheritance的なテクニックを使うことにより、オブジェクト指向モデリングをせず、直接ER図による設計から入っても十分に開発を行うことができたわけです。

別の言い方をすると、オブジェクト・モデルとER図がほとんど同じ形になるケースでは、オブジェクト指向モデリングした結果をデータベース・スキーマに変換する手間を掛けるより、直接ER図でモデリングしたほうが効率がよくなります。

そこでトレイトです。

モデリングにトレイトが入ってくると、単なる継承とは別次元のセマンティクス・ギャップが発生します。こうなってくると、直接ER図でモデリングするより、オブジェクト指向モデリングの結果をER図に変換するほうがより良い結果を得ることができるはずです。

もちろん、モデリングにトレイトを導入しても手作業でデータベース・スキーマに変換していたのでは効果は限定的です。しかし、SimpleModelerのようなモデルコンパイラによって、このあたりの変換処理が自動化されれば、トレイト導入の効果を十二分に享受することができます。

というようなことを、SimpleModelerがトレイトを処理した結果のクラス図を眺めて感じたしだいです。こういった新しいモデリング手法が浸透するまでには長い時間が必要になるので、今すぐER図中心、データモデリング中心の開発アプローチが下火になることはないでしょうが、長い目で考えると大きく動いていくところではないかと思います。

2012年10月23日火曜日

Literate modeling

10月23日の昼にとあるプライベートな集まりで、夜に名古屋Geek BarでSimpleModelerを紹介する機会がありました。参加された皆さん、どうもありがとうございました。


今回は新機能であるSmartDox DSLを中心に紹介しました。

ユビキタス言語

SimpleModelerの主張点の一つは、ユビキタス言語を軸にビジネス・モデリングから分析、設計、そしてコード自動生成を束ねていく点にあります。

この目的に、より近づくために開発したのがSmartDox DSLです。

SmartDoxは、Emacs org-modeをベースにした文書処理システムです。これをオブジェクト指向モデルの記述言語に採用したものがSmartDox DSLです。

SmartDoxは普通の文章を記述するためのフォーマットですが、この中に、一定のコンベンションに沿った文章を書くことで、この文章の中からオブジェクト・モデルを抽出し、モデルの可視化やコード生成を行うものです。このようにして抽出されたオブジェクト・モデルは、自然言語によって記述された文書との整合性を持つはずです。この部分が日本語、モデル、プログラムの共通部分、すなわちユビキタス言語となります。

Literate modeling

ユビキタス言語を軸に説明する方針をとっていたのですが、説明をしながら思いついたのはLiterate modelingの観点をもう少し強調した方がよいかもという点です。

Literate modelingはLiterate programmingのモデリング版で『Enterprise Patterns and MDA』で提案されているものです。

UMLによるビジュアル・プログラミングだけでは情報不足という認識から、UMLと同時にビジネス文脈文書(Business context document)を作成し、この2つをあわせてモデリングの成果物とします。

『Enterprise Patterns and MDA』版Literate modelingでは、UMLが主でこれを自然言語文書で補完しますが、SmartDox DSLのLiterate modelingではこれを一歩進めて自然言語文書+コンベンションで実現します。

スライドにも柔らかいモデル、固いモデルという表現が出てきますが、これをもう少し精密化して、Literate modelingの文脈で説明していくのがよいのではないかと考えたわけです。

SmartDox DSLで書かれた自然言語文書(+コンベンション)の文書から抽出されるものは以下の3つに分類できます。

非モデル
モデル化できないマテリアル。自然言語、図など。
柔らかいモデル
プログラムに落とすことはできないが、モデルとしてデータ化することができる。
固いモデル
プログラムを自動生成できる。

SmartDox DSLでは非モデル、柔らかいモデル、固いモデルを一つの文書に束ねて記述します。このため、プログラムと直接対応を持たない非モデル、柔らかいモデルがプログラムと生き別れになってしまい散逸してしまうことを防ぐことができます。

柔らかいモデルは、要求仕様といったビジネス側の要件をオブジェクト指向モデルの枠組みにそって記述したものです。この柔らかいモデルが固いモデルを束ねる形になりますが、このメカニズムにより固いモデル経由で、仕様記述、ビジネス・モデリング記述とプログラムの関係を明示することができます。

また、非モデルも柔らかいモデルや固いモデルの説明として紐付けられ、モデルの中に束ねられます。

説明中に思いついたアイデアをより具体化してみました。Literate modelingはSimpleModelerの特徴をわかりやすく表現できるようです。SimpleModelerのモデル記述方法に関する説明は「ユビキタス言語」と「Literate modeling」の2つを軸に洗練させていきたいと思います。

2012年10月22日月曜日

MindmapModeling「オンライン・ツー・オフライン(O2O)は、これからどう近づくか?」

10月20日(土)に横浜モデリング勉強会(facebook group)を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。

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

ワークショップの流れ

モデリング勉強会はワークショップ形式で以下の作業を行います。

  • 雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する。

その上で、「要求仕様確認、実装可能性確認、開発のベースとなるプログラムを自動生成するモデルを目指」します。詳細は「ワークショップの進め方 第2版」になります。

テーマ

モデリングの対象は、アドタイ誌の記事「オンライン・ツー・オフライン(O2O)は、これからどう近づくか?」です。

この記事を中心に記事に登場するO2Oを活用している2つの会社「ニーマン・マーカス」、「ホールフーズマーケット」のO2Oのモデルを作成します。記事は短いので必要に応じて他のサイトの情報を参照します。

用語の収集と整理

まず用語の収集と整理します。

MindmapModelingに慣れてくると、用語がだいたいどこの枝に収まるのかわかるようになるので、用語を拾いながらラフなモデルを作っていきます。




今回の記事は、高級でデパート「ニーマン・マーカス」とスーパーマーケット「ホールフーズ・マーケット」のどちらかを選択するという趣旨だったのですが、「コミュニティを作る」という意味では共通部分が多いと感じたので、「ニーマン・マーカス」と「ホールフーズ・マーケット」を合体させたモデルを作成することにしました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。




まだ、個々のクラスはばらばらで組織化されていません。

物語

次の作業は「物語」です。

モデルは中心軸がないと単なる「用語」の集りなのでまとまりがでてきません。何らかの目的を実現するための構造を抽出したいわけですが、この「目的」と「目的を実現するための構造」を掬いとるためのツールとして有効なのが「物語」です。オブジェクト・モデリングの概念ではビジネス・ユースケースということになります。

「物語」を中心軸と定め、「物語」のスコープで用語を取捨選択、組織化し、足りない用語を補っていきます。

その手順は:

  1. 物語の名前をつける。目的(goal)が明確になる名前がよい。
  2. 物語の主人公、相手役、脇役などの登場人物を定める。
  3. 物語で使用する道具を定める。
  4. 出来事または脚本の列として脚本を記述する。

となります。2の登場人物と3の道具は最初から完全なものはできないので暫定的なものを定め、4の脚本の作業を通して洗練させていきます。


「物語」の作成を軸に、「出来事」の整理、「道具」の整理を進めました。

物語としては、ニーマン・マーカス由来の「顧客と専任スタッフの信頼関係を作る」、ホールフーズマーケット由来の「顧客とスタッフでコミュニティを作る」の2つの物語を軸にしています。どちらも、顧客と会社の間のコミュニティを醸成するという意味では共通しているのでこの観点でリソース(道具)の抽出、リソース間関係の整備などを行なっています。

今回はこの段階で時間切れになりました。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。




まだ、ビジネス・ユースケース→イベント→リソースの関係が作りこまれていないので、横に平べったくなっています。

モデリングを続けるとすると、そのあたりを伸ばしていく感じですね。

ノート

今回のモデリングでは以下の2つの機能拡張を試してみました。

  • トレイト
  • 物語の集約関係
トレイト

最近、モデル駆動を前提とした概念モデリングでもトレイトというモデル要素を導入するのが有効ではないかと考えています。

この目的でSimpleModelerにもトレイトを導入しました。

今回のモデルでは「共有したい物語」トレイトとして使用しています。

物語の集約関係

物語(business use case)は主役(primary actor)の視点で進めることが基本ですが、ある大きな物語とその内部のエピソードとなる物語で視点が異なることがあります。

今回のモデルでは「顧客と専任スタッフの信頼関係を作る」という物語は小売業企業の視点ですが、そのエピソードとなる「店舗で商品選択のアドバイスをもらう」は顧客(買物客)の視点になります。

この支店の異なる物語の入れ子関係を物語間に集約関係を導入するとモデルを的確に記述できそうということが分かってきました。この目的で勉強会の後にSimpleModelerを拡張しました。

前述の図は、改造後のSimpleModelerで生成したものです。

次回

次回は11月17日(土)です。

詳細情報はfacebookグループ「横浜モデリング勉強会」を参照してください。

今回と同じく「ワークショップの進め方 第2版」の手順で、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」を行う予定です。

2012年10月19日金曜日

SimpleModeler 0.4.0-RC3

モデルコンパイラSimpleModeler 0.4.0-RC3をリリースしました。

これは、明日(10/20)開催予定の横浜モデリング勉強会および10/22のセッション向けのリリースです。

SmartDox DSL機能をリリースしました。マインドマップ(XMind)とSmartDox DSLからクラス図を生成する機能が実用フェーズとなっています。

0.4.0正式版はバグフィックスおよび新機能の動作確認が取れた後リリース予定です。

機能

Simplemodeler 0.4.0-RC3では以下のオプションを提供しています。

オプション機能状況
projectプロジェクト生成α
importモデル移入α
convertモデル変換試験的
html仕様書生成α
javaJava生成α
androidAndroid生成α
diagramクラス図生成
buildプロジェクトビルド試験的
gaejGoogle App Engine Java生成試験的
gaeGoogle App Engine Python生成試験的
gaeoGoogle App Engine Oil生成削除予定
grailsGrails生成試験的
g3g3生成試験的
asakusaAsakusa生成試験的

基本的にはマインドマップ(XMind)、SmartDox DSLとCSVからクラス図を生成する処理が実用フェーズになっています。その他の機能はα版または試験的実装の状態です。

インストール

プログラムの配布は、Scala用のプログラム配布ツールconscriptを使っています。

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

$ cs asami/simplemodeler

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

sm
SimpleModelerコマンド
$ sm -version
Copyright(c) 2008-2012 ASAMI, Tomoharu. All rights reserved.
SimpleModeler Version 0.4.0-RC3 (20121019)
graphviz

-diagramオプションでクラス図を生成する場合は、graphvizのインストールが必要です。graphvizのインストール方法は以下を参照してください。

各プラットフォーム向けパッケージ管理ツールでもインストールできるようです。

Mac
http://www.macports.org/
Windows
http://sourceware.org/cygwinports/

使い方

マニュアルはまだありません。以前のバージョン用のものがありますが、機能が色々変わってしまったので一から見直す予定です。

リファレンスマニュアルとユーザーガイドの元ネタをこのブログで随時書いていきます。

CSV

Mind(マインドマップ)、SmartDox DSL、CSVからクラス図を生成することができます。

以下のCSVファイルをsample.csvとして用意します。

#actor,base
顧客
個人顧客,顧客
法人顧客,顧客
#resource,attrs,powers
商品,商品名;定価(long),商品区分(第1類;第2類;第3類)
#event,parts
購入する,顧客;商品

SimpleModelerを以下のように実行します。

$ sm -diagram sample.csv

以下のクラス図の画像が生成されます。



SmartDox

以下のSmartDoxファイルをsample.orgとして用意します。

#+title: Table

SmartDox DSLを使って記述したモデルの
サンプル文書です。

文書でサンプルモデルの定義をします。
本来は文書中の仕様記述の文書は
定義するモデルに対するものになります。

しかし、この文書ではSmartDox DSLの記述例として
SmartDox DSL文法の説明を記述することにします。

* サンプル文書の目的

このサンプル文書は表を中心にしてクラス定義するサンプルです。

登場人物、道具、出来事の各エンティティの種別の下に
顧客、商品、購入といった具象エンティティを節として
定義します。

そして、それらの節の下に属性一覧または特性一覧として
エンティティの属性や関連を記述していきます。

* 登場人物

** 顧客

IDの指定はありませんが、以下のルールで推測しています。

- 陽にID指定がない場合、先頭の属性の属性名が「id」(大文字可)で終わる場合はIDとみなす。

#+caption: 属性一覧
| 名前   | 型     | カラム  | SQL型        |
|--------+--------+---------+--------------|
| 顧客ID | token  | ID      | CHAR(16)     |
| 名前   | token  | NAME    | VARCHAR(64)  |
| 住所   | string | ADDRESS | VARCHAR(256) |

* 道具

** 商品

IDは、ID欄で指定しています。

#+caption: 属性一覧
| 名前   | 型    | ID | カラム | SQL型       |
|--------+-------+----+--------+-------------|
| 商品ID | token | ○ | ID     | CHAR(16)    |
| 名前   | token |    | NAME   | VARCHAR(32) |
| 定価   | money |    | PRICE  | LONG        |

* 出来事

** 購入

IDは、特性欄で指定しています。

#+caption: 特性一覧
| 特性 | 名前   | 型    | 多重度 | 派生        | カラム      | SQL型    |
|------+--------+-------+--------+-------------+-------------+----------|
| ID   | 購入ID | token |        |             | ID          | CHAR(16) |
| 属性 | 日付   | date  |        |             | DATE        | DATE     |
| 関連 | 顧客   | 顧客  |      1 |             | CUSTOMER_ID | CHAR(16) |
| 属性 | 顧客名 | token |        | 顧客.名前   |             |          |
| 関連 | 商品   | 商品  |      1 |             | GOOD_ID     | CHAR(16) |
| 属性 | 数量   | int   |        |             | AMOUNT      | INT      |
| 属性 | 商品名 | token |        | 商品.名前   |             |          |
| 属性 | 単価   | money |        | 商品.定価   |             |          |
| 属性 | 総額   | money |        | 数量 * 単価 |             |          |

SimpleModelerを以下のように実行します。

$ sm -diagram sample.org

以下のクラス図の画像が生成されます。




2012年10月18日木曜日

MindmapModelingと集合知(12) - オントロジー

今回のセッションは、社会科学を中心に、工学、理学の知見を集約してクラウド時代の「集合知」に対してアプローチしている集まり、でのものになります。

ソフトウェア開発でのモデリングは、日本語(自然言語)の情報から必要な情報を抽出、再構成してプログラムに落とし込むためのモデルを構築するものですから、この文脈の中で日本語(自然言語)をどう扱っていくのかという点は常に関心を持っていました。

その成果物として、ユビキタス言語をハブに「固いモデル」と「柔らかいモデル」を統合したSmartDox DSLをつくってみたわけです。

最近、読み返してみた『Enterprise Patterns and MDA』に「literate modeling」というコンセプトが載っていましたが、SmartDox DSLの目指すところはまさにこのliterate modelingということになると思います。

ボク自身は「集合知」といったものは全くの門外漢なので、直接その話題を取り上げることはありませんが、日本語とモデルとプログラムを結びつけるユビキタス言語としてのSmartDox DSLが何かのヒントにしていただけるかもしれないということで、この点を中心の話題にする予定です。

オントロジー

マインドマップモデリングは、wakhokでの教育用に考案したものですが、このメタモデルの設計にあたっては、日本語を扱う技術ということもあり、参考のためにオントロジーの文献もあたってみました。オントロジーの分野も門外漢なので、どの本が定番かよく分からないのですが、MDAや企業システムのモデル化という観点で以下の本を入手しました。

マインドマップモデリングは、最終的にOOPに落とし込むのが目的なので、できるだけOOPのセマンティクスの範囲でメタモデルを設計しています。そういう意味で、上記の本によるオントロジーは汎用的すぎて、目的には合わないと判断して初期の段階で参考資料からは落としました。

ただ、Mindmap DSLやSmartDox DSLといった形で、ユビキタス言語ベースのモデル記述DSLとそのメタモデルが形になってくると、このメタモデルのインスタンスであるモデル、このモデルのインスタンスであるデータは、ある意味ソフトウェア開発という文脈での意味のグラフと考えることができるかもしれないと感じています。そういう観点から、オントロジーの技術を導入して、なにか面白いことができるかもという期待もあります。

たとえば、「柔らかいモデル」の部分になる自然言語による記述に対してオントロジーな処理を施して意味を抽出し、「固いモデル」との整合性をチェック、は難しいかもしれませんが、レビューの元ネタぐらいはつくれないかな、とかそういう方向での応用です。

クラウド・プラットフォーム上での「集合知」の扱いがオントロジーと関係が出てくるのかそうでないのかも当日にならないと分かりませんが、そういった点も含めてこのあたりの技術動向についての知見を得ることができればと期待しています。

2012年10月17日水曜日

MindmapModelingと集合知(11) - SmartDox DSLによるユビキタス言語

ユビキタス言語で説明した通り、ユビキタス言語をハブにして日本語、モデル、プログラムを連携します。

元々、マインドマップモデリングをユビキタス言語として使用していましたが、マインドマップの記述力では本格的なシステム開発に耐えるモデルを記述するには無理があります。あくまでも、ブレインストーミングや教育の用途向けになります。



また本格的なシステム開発に耐えるモデルとしてはScalaをホスト言語とした内部DSLを使用していましたが、プログラミング寄りの記述方法なのでユビキタス言語としては難がありました。

この問題を解決するために開発したのがSmartDox DSLです。

SmartDox DSLは基本的にマインドマップと同じ文書構造になっており、システム側の語彙も共通しています。ただし、表組みなどを使ってより精密なモデルを記述できるようになっています。

SmartDox DSLでは、以下の2種類の語彙があります。

  • システム語彙
  • アプリケーション語彙

システム語彙

以下の用語にユビキタス言語の構造上の意味を持たせています。

語彙OO用語OO用語(英語)
登場人物アクターactor
道具リソースresource
出来事イベントevent
要約サマリsummary
役割ロールrole
物語ビジネス・ユースケースbusiness use case
規則ビジネス・ルールbusiness rule
特色トレイトtrait
区分パワータイプpowertype
種類汎化generalization
参照, 関連関連association
部品, 集約集約aggregation
部品, 合成合成composition
属性属性attribute
脚本(ユースケースの)フロー(use case) flow
主役プライマリ・アクターprimary actor
相手役セカンダリ・アクターsecondary actor
脇役サポーティング・アクターsupporting actor
状況の変化状態遷移state transition
状態状態state
状態機械状態機械state machine
サービスサービスservice
基底基底クラスbase class
多重度多重度multiplicity
目的目的goal
注記アノテーションannotation
性質プロパティproperty

アプリケーション語彙

システム言語の語彙と文章の構造を用いて、アプリケーション言語の語彙を定義します。

前回の例では以下のクラス図が示すモデルをSmartDox DSLで記述しました。



このモデルでは以下のアプリケーション語彙が定義されています。

種別アプリケーション語彙
アクター顧客
リソース商品
イベント購入
トレイトMaster, Transaction, LogicalDeletable, Tagable, ImageHolder

「固いモデル」と「柔らかいモデル」の整合性

アウトラインや表組みの中の所定の場所にシステム語彙やアプリケーション語彙を記述することで、プログラム生成に必要な精度のモデルを記述します。この部分はツールと人間が共通に認識します。ここの部分を「固いモデル」と呼んでいます。

それと同時に、日本語の文章で各モデル要素の仕様を記述します。この部分はツールはモデルとしては扱わず、人間が仕様を理解するための情報になります。ここの部分を「柔らかいモデル」と呼んでいます。

柔らかいモデルの意図は、要求仕様といった人間側の情報をまとめ固いモデルへ紐付ける点にあります。要求仕様と固いモデルの整合性は、人間が「柔らかいモデルの文章」を読んでアナログに判断していきます。

従来のプログラミング言語よりの固いモデルと人間よりの柔らかいモデルが別々に存在しており、2つのモデル間の連携が不十分でした。

固いモデルと柔らかいモデルを統合したユビキタス言語を用いることで、アプリケーション開発のライフサイクルを通して持続的にこの2つのモデルの整合性を保っていく事が可能になるのではないかと考えています。

2012年10月16日火曜日

MindmapModelingと集合知(10) - トレイト

前回はマインドマップではなく、通常の仕様書ライクな文書によるSimpleModeler DSLであるSmartDox DSLを紹介しました。

SmartDox DSLを用いることで、マインドマップモデルでは難しかった本格的なシステム開発をターゲットにしたコード生成を行うことができます。

さて、SmartDox DSLでモデリングを始めてみると、あるモデル要素が無性に使いたくなってきました。そのモデル要素とは「トレイト」です。

ここで言うトレイトはScalaが提供しているミックスイン用のクラス断片で、通常のクラス継承の機能を緩めることで、多重継承的なモデリングを可能にします。scalaプログラミングではトレイトを用いたCakeパターンが非常に便利ですが、これをオブジェクト・モデリングの段階でも使いたいと考えたわけです。

そこで、ここ数日SimpleModelerにトレイトを追加する拡張を行なっていたのですが、何とか動くようになりました。

以下の文書がトレイトを用いたSmartDox DSLです。

#+title: Table

SmartDox DSLを使って記述したモデルの
サンプル文書です。

文書でサンプルモデルの定義をします。
本来は文書中の仕様記述の文書は
定義するモデルに対するものになります。

しかし、この文書ではSmartDox DSLの記述例として
SmartDox DSL文法の説明を記述することにします。

* サンプル文書の目的

このサンプル文書は表を中心にしてクラス定義するサンプルです。

表を中心にトレイトを使ったモデリングのサンプルです。

* 特色

** Master

** Transaction

** LogicalDeletable

** ImageHolder

** Tagable

* 登場人物

** 顧客

#+caption: 性質一覧
| 項目 | 値                                          |
|------+---------------------------------------------|
| 特色 | Master,LogicalDeletable,ImageHolder,Tagable |

#+caption: 属性一覧
| 名前   | 型     | カラム  | SQL型        |
|--------+--------+---------+--------------|
| 顧客ID | token  | ID      | CHAR(16)     |
| 名前   | token  | NAME    | VARCHAR(64)  |
| 住所   | string | ADDRESS | VARCHAR(256) |

* 道具

** 商品

#+caption: 性質一覧
| 項目 | 値                                          |
|------+---------------------------------------------|
| 特色 | Master,LogicalDeletable,ImageHolder,Tagable |

#+caption: 属性一覧
| 名前   | 型    | ID | カラム | SQL型       |
|--------+-------+----+--------+-------------|
| 商品ID | token | ○ | ID     | CHAR(16)    |
| 名前   | token |    | NAME   | VARCHAR(32) |
| 定価   | money |    | PRICE  | LONG        |

* 出来事

** 購入

#+caption: 性質一覧
| 項目 | 値                           |
|------+------------------------------|
| 特色 | Transaction,LogicalDeletable |

#+caption: 特性一覧
| 特性 | 名前   | 型    | 多重度 | 派生        | カラム      | SQL型    |
|------+--------+-------+--------+-------------+-------------+----------|
| ID   | 購入ID | token |        |             | ID          | CHAR(16) |
| 属性 | 日付   | date  |        |             | DATE        | DATE     |
| 関連 | 顧客   | 顧客  |      1 |             | CUSTOMER_ID | CHAR(16) |
| 属性 | 顧客名 | token |        | 顧客.名前   |             |          |
| 関連 | 商品   | 商品  |      1 |             | GOOD_ID     | CHAR(16) |
| 属性 | 数量   | int   |        |             | AMOUNT      | INT      |
| 属性 | 商品名 | token |        | 商品.名前   |             |          |
| 属性 | 単価   | money |        | 商品.定価   |             |          |
| 属性 | 総額   | money |        | 数量 * 単価 |             |          |

以下の5つのトレイトを定義しています。例題なので中身は定義していませんが、以下のような用途を想定しています。

Master
マスターテーブル
Transaction
トランザクションテーブル
LogicalDeletable
論理削除
ImageHolder
イメージと関連付け
Tagable
タグと関連付け

ポイントとなるのは、顧客はMaster, LogicalDeletable, ImageHolder, Tagable、商品はMaster, LogicalDeletable, ImageHolder, Tagable、購入はTransaction, LogicalDeletableといったように必要な特色(トレイト)を自由にミックスインすることができる点です。

クラス図

上記のDSLからSimpleModelerを使って以下のクラス図を生成することができます。




実装

モデリング時にトレイトを使う場合、Scalaでは特に問題なくそのまま実現できるのは明らかです。それでは、JavaやRDBMSの場合はどうなるでしょうか。

Java

Javaの場合は、複数のトレイトを合体させた実装をクラスとして生成し、トレイトに対応するインタフェースとimplementsしておけばよいでしょう。手動でトレイト相当を実装すると大変ですが、コード生成であれば特に難しかったり煩雑だったりするところはありません。

RDBMS

RDBMSのテーブルは、単純に元のテーブル定義にトレイトを合体させたテーブルを生成すればよいでしょう。これもコード生成であれば難しいところはありません。

以上のようにトレイトはモデリング上も有効な上に、コード生成を前提にすればJavaやRDBMSといった既存のプラットフォームでも問題なく展開することができます。

UML時代には存在していなかったトレイトですが、SimpleModelerを使ったモデル駆動開発では非常に有効に使えそうです。

2012年10月15日月曜日

MindmapModelingと集合知(9) - SmartDox DSL

今月の22日にとある名古屋の学際的な集まりで、マインドマップモデリングやモデル駆動開発についてお話させていただくことになりました。タイトルは「文書をプログラムにする技術」となりました。このセッションのネタ整理を「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」といった感じで、ブログの上で行なっていっています。

ここまで以下の順にマインドマップモデリングの基盤技術について説明してきました。

日本語とモデルとプログラムをつなぐハブとしてユビキタス言語が極めて重要になります。

ここで問題となるのはマインドマップを使ったモデルの表現力、記述力です。マインドマップはブレインストーミングや教育目的では極めて有効なのですが、ある程度の大きさと精密さを持ったモデルの記述力には難があります。

当初は精密なモデルの記述には(SimpleModeler専用の)Scala DSLを用いていたのですが、こちらは日本語情報による「柔らかいモデル」の記述に難があることが分かってきました。

そこで新たなDSLとして開発中なのが、浅海が開発している文書処理システムSmartDoxを使用したSmartDox DSLです。

SmartDox DSL

SmartDoxはEmacsのorg-modeをベースにした文書処理システムです。(1月10日の記事参照)

本ブログも今年に入ってからSmartDoxを使って書いていますが、非常に便利に使えています。

SmartDoxの美点の一つはorg-modeをベースにしているので、Emacsのorg-modeで編集できることです。org-modeはアウトラインプロセッサであると同時に、極めて強力な表組み記述機能を持っています。

ここで、ユビキタス言語を記述するための言語について改めて考えてみると:

  • 日本語を自然に記述することができる
  • アウトラインで全体構造を表現できる
  • 表で詳細情報を表現できる

という要因が重要になりますが、SmartDox(org-mode)は以上のすべての要因を満たしています。

そこで、このSmartDoxを使ったSimpleModeler用のDSLを開発してみたものがSmartDox DSLです。

SmartDox DSLの例

SmartDox DSLの例を以下に示します。

#+title: Table

SmartDox DSLを使って記述したモデルの
サンプル文書です。

文書でサンプルモデルの定義をします。
本来は文書中の仕様記述の文書は
定義するモデルに対するものになります。

しかし、この文書ではSmartDox DSLの記述例として
SmartDox DSL文法の説明を記述することにします。

* サンプル文書の目的

このサンプル文書は表を中心にしてクラス定義するサンプルです。

登場人物、道具、出来事の各エンティティの種別の下に
顧客、商品、購入といった具象エンティティを節として
定義します。

そして、それらの節の下に属性一覧または特性一覧として
エンティティの属性や関連を記述していきます。

* 登場人物

** 顧客

IDの指定はありませんが、以下のルールで推測しています。

- 陽にID指定がない場合、先頭の属性の属性名が「id」(大文字可)で終わる場合はIDとみなす。

#+caption: 属性一覧
| 名前   | 型     | カラム  | SQL型        |
|--------+--------+---------+--------------|
| 顧客ID | token  | ID      | CHAR(16)     |
| 名前   | token  | NAME    | VARCHAR(64)  |
| 住所   | string | ADDRESS | VARCHAR(256) |

* 道具

** 商品

IDは、ID欄で指定しています。

#+caption: 属性一覧
| 名前   | 型    | ID | カラム | SQL型       |
|--------+-------+----+--------+-------------|
| 商品ID | token | ○ | ID     | CHAR(16)    |
| 名前   | token |    | NAME   | VARCHAR(32) |
| 定価   | money |    | PRICE  | LONG        |

* 出来事

** 購入

IDは、特性欄で指定しています。

#+caption: 特性一覧
| 特性 | 名前   | 型    | 多重度 | 派生        | カラム      | SQL型    |
|------+--------+-------+--------+-------------+-------------+----------|
| ID   | 購入ID | token |        |             | ID          | CHAR(16) |
| 属性 | 日付   | date  |        |             | DATE        | DATE     |
| 関連 | 顧客   | 顧客  |      1 |             | CUSTOMER_ID | CHAR(16) |
| 属性 | 顧客名 | token |        | 顧客.名前   |             |          |
| 関連 | 商品   | 商品  |      1 |             | GOOD_ID     | CHAR(16) |
| 属性 | 数量   | int   |        |             | AMOUNT      | INT      |
| 属性 | 商品名 | token |        | 商品.名前   |             |          |
| 属性 | 単価   | money |        | 商品.定価   |             |          |
| 属性 | 総額   | money |        | 数量 * 単価 |             |          |

ポイントとなるのは、仕様書のアウトラインや文章、表の中からモデルとして記述された部分を抽出し、このモデルから各種成果物を生成する点です。

マインドマップモデルよりモデルの記述力ははるかに高くなります。

また、Scala DSLと比較しても、モデルの記述力は同等ととしても、日本語の文章の記述力はるかに高くになります。

特に日本語による文章については、リストや表、プログラム例、画像といったものを自由に記述することができるので、汎用の仕様書としての役割を十分に果たすことができます。

クラス図

上記のDSLからSimpleModelerを使って以下のクラス図を生成することができます。




開発中なのでまだ試せていませんが、各種プログラムの自動生成もできる予定です。

2012年10月12日金曜日

MindmapModelingと集合知(8) - マインドマップモデリングの例

ここまで以下の順にマインドマップモデリングの基盤技術について説明してきました。

ユビキタス言語をハブとして、日本語とモデルとプログラムをつなぐわけですが、その実現技術としてマインドマップを用いるのがマインドマップモデリングというわけです。

マインドマップモデリングのメリット

通常、マインドマップは非定形の情報を記述しますが、ここまで説明してきたようにマインドマップモデリングではオブジェクト指向技術と連携できるメタモデルを持っており、このメタモデルの枠組みの上でモデルを構築していきます。

一見、同様のことはUMLでもできそうですが、以下の理由によりマインドマップを用いたほうがはるかに便利というのが経験則です。

  • UMLの文法を覚えるのが大変。UMLは文法を覚えないと何も描けない。さらにUMLのモデルとして基本文法に加えてアプリケーション用のプロファイルも覚える必要がある。マインドマップモデリングでは、文法をうろ覚えでもとりあえずそれなりのものを描くことができる。
  • マインドマップモデリングではモデル全体の一覧性が高い。
  • エディタ(XMind)がUMLエディタよりも簡単に使える。UMLエディタではプロパティシートの呼出しなど煩雑な処理が必要になる。

以上のメリットがあるので、モデリング初学者向けの教育や、顧客との文脈共有のためのブレインストーミングに有効です。

マインドマップモデリングの例

マインドマップモデリングの例として横浜モデリング勉強会で行ったMindmapModeling「LCCがもたらしたのは、価格破壊だけではない」のマインドマップモデルが以下です。横浜モデリング勉強会では、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」という趣旨で雑誌記事からマインドマップを作成するワークショップ形式の勉強会です。(ワークショップの進め方 (2012-06-16版))



このモデルは、日本語の情報としても本文の内容をうまく整理できていると思いますが、ユビキタス言語としてオブジェクト指向モデルと連続性がある点がさらに重要です。

これは、SimpleModelerを用いてクラス図を生成することで確認することができます。

上記のマインドマップモデルから生成したクラス図は以下になります。




SimpleModelerでは、クラス図だけでなくJavaクラスやAndroidアプリケーション、Ext-JS&Playアプリケーションの生成も行うことができます。つまり、ユビキタス言語からプログラムの自動生成する、モデル駆動開発を行うことができるわけです。

2012年10月11日木曜日

MindmapModelingと集合知(7) - クラウド拡張

前回は、マインドマップモデリングの土台となるSimpleModelingのメタモデルを紹介しました。

このSimpleModelingメタモデルは、wakhok時代から積み上げてきたものでwakhok時代の成果物は『上流工程UMLモデリング 業務・要求分析からプログラミングへのモデル化技法』になります。

wakhokの段階では、伝統的な業務アプリをターゲットにしていましたが、2008年以降は、新しく勃興してくる「クラウド・アプリケーション」を新しいターゲットに設定して、メタ・モデルの拡張を進めています。

「クラウド・アプリケーション=クラウド・サービス+スマート・デバイス」とした上でキーポイントは以下になります。

  • ビジネス・モデリングとの連続性を確保
  • クラウド・サービスによる大規模データ/大規模演算
  • スマート・デバイスを用いたUX/UI
  • モデルからプログラムの自動生成

そこで昨日のメタモデルの図になるわけですが、このブログを書きながら少し情報を追加したので、その改版版を以下に示します。




最近UXの取り込みのイメージができてきたので、その情報を追加しました。また、ビジネス・プロセスのところで省略していたビジネス・フローを念の為に入れています。

以下ではこのメタモデルのインスタンスとして構築したモデルをSimpleModelingモデル、略してSMモデルと呼ぶことにします。

ビジネス・モデリング

SMモデルでは、プログラムに直接落とし込める部分を「固いモデル」、落とし込めない部分を「柔らかいモデル」と呼んでいます。基本的に要求仕様に近くなるほど「柔らかいモデル」、ドメインモデルに近くなるほど「固いモデル」になります。

ポイントとなるのは、固いモデルが、柔らかいモデルで記述したモデルを効率的に実現するための土台になっているのかという点を検証可能にしたいということです。このために、ビジネス・プロセスやユースケースといった柔らかいモデルを記述し、ドメインモデルとの関係をモデル上で維持し、可視化やモデルの検証などを行う基盤としていく予定です。

SMモデルでは、ビジネス・ユースケース(マインドマップモデリングの「物語」)をビジネス・モデリングの軸としています。ビジネス・プロセスはビジネス・ユースケースの集まりとしてモデル化していきます。ビジネス・ユースケースの具体的なステップはビジネス・タスクとして抽出し、ユースケースと紐付けます。

またビジネス・プロセスやビジネス・ユースケースは、イベント、アクター、イベントといったエンティティを使用します。この部分で直接プログラムとの関係が出てきます。

ビジネス・プロセスやその実行過程としてのビジネス・ユースケースにおいて、どのようなエンティティがどのように使われるのかという点を可視化し、検証可能にしていくのがSMモデルのおけるビジネス・モデリングの目標です。

クラウド・サービス

クラウド・サービスでは、大規模データ、大規模演算をどのようにモデル化して全体アーキテクチャに位置付けていくのかについて検討を重ねてきました。

MindmapModelingと集合知」でも少し触れましたが、「データフローの導入」、「メッセージフローの導入」がクラウド・サービス向けの拡張点です。

大規模データ、大規模演算への対応が「データフローの導入」、非同期事象・遅延への対応が「メッセージフローの導入」です。プログラミングモデルに例えると前者が並列プログラミング、後者が並行プログラミング的なアプローチになります。

少し情報が古いですが想定しているアーキテクチャは以下のものです。

このようなアーキテクチャに対して「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」で取り組んだObject-Functionalの切り口で分析、設計、プログラミングを行うためのメタモデルとDSLの実現を目指しています。

スマート・デバイス&UX/UI

スマート・デバイスを用いたUX/UIもクラウド・アプリケーションの重要なテーマです。

Android

スマートデバイスについてはAndoirdを素材に検討を重ねてきました。成果物は以下のとおりです。

スマートデバイスとスマートサービスの組合せによるアーキテクチャの動作イメージやモデリングとの接点は大体つかめたと思います。基本的にはiOSへの技術転用は可能だと考えているので、いずれそちらの方面にも展開できればと思います。

UX/UI

UXについては、色々と調査を進めていたのですが、最近イメージが明確になってきたのでSMモデルの枠組みの中に取り込んでいきたいと考えているところです。

上の図で示した通りユースケース→タスクのラインからサービスを、UXのラインからUIを構築するような形を考えています。

プログラムの自動生成

以上に示した各種モデルをDSLで記述し、プログラムの自動生成を行うためのツールとしてSimpleModelerを開発中です。

セッションではマインドマップモデリングとSimpleModelerでプログラムの自動生成のデモも行う予定です。

2012年10月10日水曜日

MindmapModelingと集合知(6) - メタモデル

前々回、前回でマインドマップモデリングでのモデリング方法についてざっくりと説明しました。業務アプリケーションを記述する場合、どのような枠組みを補助線にしていけばよいのかというプラクティスを、オブジェクト・モデルのプロファイルとして形式知化したものと考えるとよいでしょう。

こういったモデリングのプロファイルを考えるためには、モデルのメタモデルを構築する必要があります。

マインドマップモデリングでは、ボクが整備しているSimpleModelingというモデリング手法のメタモデルをベースにしています。SimpleModelingのメタモデルの中で、概要をざっくりつかむのに必要なモデル要素を厳選して、この範囲でモデルを記述します。

SimpleModelingのメタモデルの最新状況は以下のようになっています。




このメタモデルの中で、マインドマップモデリングでは以下のものを使用しています。

MindmapModelingSimpleModeling
登場人物アクター
道具リソース
出来事イベント
役割ロール(図では省略)
規則ルール
物語ビジネス・ユースケース

エンティティを中心にメタモデルの一部を切り取っています。

マインドマップモデリングの範囲では、イベント(出来事)を中心に、エンティティとビジネス・ユースケースを結びつけるのが眼目になります。モデリングの中で、ビジネスの目標に沿った形で、エンティティとイベントを抽出し、お互いの関係を整理します。

2012年10月9日火曜日

MindmapModelingと集合知(5) - SVOで考える

今月の22日にとある名古屋の学際的な集まりで、マインドマップモデリングやモデル駆動開発についてお話させていただくことになりました。タイトルは「文書をプログラムにする技術」となりました。このセッションのネタ整理を「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」といった感じで、ブログの上で行なっていっています。

前回はオブジェクト・モデルにおける関係(relationship)がマインドマップモデリングでどのように扱われているのかについて説明しました。

関係(relationship)の中で汎化(generalization)と集約(aggregation)を特別扱いするのがオブジェクト指向の基本的な考え方です。

関係(relationship)の一種に関連(association)があり、関連(association)の一種に集約(aggregation)、集約(aggregation)の一種に合成(composition)があるという関係になっています。

マインドマップモデリングでは、汎化を種類枝、集約を部品枝で記述していきます。

さて、伝統的なオブジェクト指向モデルでは、基本的にはこの部品建てなのですが、実際に業務アプリケーションをモデリングするとなるとこれだけでは道具不足です。UMLの基本部品をベースに、用途向けのプロファイルを整備していく必要があります。

動詞

業務アプリケーション向けのプロファイルは色々な論点がありますが、その一つとしてシステムの振舞いとの接点をどのように持たせるのかという点があります。

マインドマップモデリングで重要視している概念がSVOです。英文法に出てくるSubject-Verb-Objectですね。

日本語の文書にある「動詞」からシステムの振舞いを抽出するのが第一ステップです。


SVO

抽出した「動詞」を静的構造の中に位置付けるための手法としてSVOを使用します。


SVOを用いて、振舞いをモデル化した「動詞」と振舞いの起点となる「名詞」、振舞いの対象となる「名詞」を結びつけます。さらに、振舞いの結果発生する「名詞」の状態遷移を記述するための土台ともなります。

出来事

オブジェクト指向モデルの基本的な考え方では、動的モデルの振舞いは静的構造モデルの関連(association)に結びつきますが、関連そのものは揮発的な情報になってしまうので、動的モデルとの連携のヒントといったレベルのものになってしまいます。

また、業務アプリケーションのおけるイベントは、「伝票の発行」など記録を残していくことが基本なので、動的モデルといえども静的構造モデルとしての側面を持っています。

その上、アプリケーション上の最重要情報でもあるので、"連携のヒント"レベルの扱いではもったいなさすぎます。

以上の点からマインドマップモデリングではビジネス・イベントをエンティティとして扱い「動詞」やSVOのVと結びつけています。

具体的なモデリングの手法としてはスライドにもあるように、SVOを用いて動詞を「出来事」の枝に追加していきます。


SVOでモデリングした「動詞」を「出来事」として可視化し、「名詞」から抽出した「登場人物」や「道具」と結びつけていくのがマインドマップモデリングの重要な作業になるわけです。

2012年10月5日金曜日

MindmapModelingと集合知(4) - 関係

ここまでの議論では日本語、モデル、プログラムの共通部分をユビキタス言語で記述し、このユビキタス言語をハブにして、日本語、モデル、プログラムの独自部分をンクしていくというアプローチを紹介しました。

その実現手法の一つがマインドマップモデリングです。マインドマップモデリングに則ったマインドマップが日本語とモデルをつなぐユビキタス言語というわけです。

マインドマップモデリングの手法は「マインドマップではじめるモデリング講座」という書籍にまとめましたが、横浜モデリング勉強会で本書の購入を前提にしたくなかったのと、リファレンス的な資料も必要だったので、簡単なチュートリアルを作りました。

それが「MindmapModelingチュートリアル」です。



マインドマップモデリングの概要はこのチュートリアルをみていただければ簡単に把握することができると思います。

名詞の構造を考える

日本語をユビキタス言語化する際にまず考えないといけないのは文書中の名詞をオブジェクトのクラス化することです。

チュートリアルでは以下の節がこの作業に相当します。



このようにして抽出した名詞から構成される構造を記述するのがオブジェクト指向モデルのハイライトです。名詞間の関係をオブジェクト指向モデルの文脈で抽出するという点が重要になります。

チュートリアルでは以下の節がこの作業に相当します。



オブジェクト指向モデルの静的構造モデルは基本的にクラスとクラス間の関係(relationship)で構成されます。関係(relationship)の一種に関連(association)があり、関連のインスタンスがリンク(link)で、クラスのインスタンスであるオブジェクトは関連のインスタンスであるリンクで接続されます。関連はクラスの結合の強度によって集約(aggregation)、合成(composition)となっていきます。

オブジェクト指向モデルでは、関係(relationship)が基本モデル要素ですが、各種の関係の中でis-a(is-kind-of)関係、has-a(is-composed-of)関係を特別扱いしている点がポイントで、この2つの関係を軸に構造を記述していきます。

is-a関係は、UMLでは汎化(generalization)になります。通称的には継承(inheritance)でもよいでしょう。

has-a関係は、UMLでは集約(aggregation)、合成(composition)になります。

データベースに格納するデータ構造としての静的構造を構築するだけであれば、UMLが定めるオブジェクト指向モデルの基本モデル要素のみでも十分にモデルを記述することができます。

2012年10月4日木曜日

MindmapModelingと集合知(3) - 日本語とモデルとプログラム

MindmapModelingと集合知」では、日本語(自然言語)、モデル、プログラムの関係として以下の図を導入しました。



理想的には、日本語の世界とモデルとプログラムが完全に一致することで、日本語の仕様書を書けばそのままプログラムとして動作するというものです。もちろん、これはSFの世界になってしまい現実的ではありません。そこで、日本語、モデル、プログラムのそれぞれが部分的に重なり図のようになるわけです。

これらの重なりに対してマインドマップモデリングやSimpleModelingで、それぞれの重なりに対してどのように対処しようとしているのか説明します。

日本語の世界とモデル

日本語の世界とモデルとの共通部をつくり、これを大きくしていくことが最初の段階になります。

もちろん、自由奔放に書いた日本語の文章がモデルに変換できるわけではありません。モデルを一定の規則に則って日本語で記述するアプローチを取ります。

このために導入したのが、「MindmapModelingと集合知(2) - ユビキタス言語」で説明したマインドマップモデリングの「登場人物 (actor)」、「道具 (resource)」、「出来事 (event)」といったモデル上の役割です。マインドマップモデリングでは演劇のメタファで、こういったモデル上の役割を規定しており、これらのメタファ上でマインドマップを記述していくことで、自然にオブジェクト・モデルと相互運用できるモデルを記述できるようにしています。

マインドマップモデリングは、文書とモデルの折衷案という切り口でもありますが、この手法を洗練させ文書よりに持ってくることで、日本語の世界とモデルの共通部分をより大きくすることができるかもしれません。

モデルとプログラム

プログラムとモデルを一致させることができれば、プログラムを書くこととモデルを作ることはイコールになります。

もちろん、現時点で完全にプログラムとクラスをマッピングさせることはできませんが、静的構造に関してはほぼ100%マッピングすることが可能なので、静的構造を軸にモデルとプログラムの一元化を考えていくことになります。

モデルとして静的構造のみを扱うのであれば、Javaクラスにアノテーションやコメントでモデル上の情報や日本語による仕様を記述していくというアプローチでも十分に機能するでしょう。

しかし、振舞いをスコープに入れるとこの前提が崩れてきます。

オブジェクト・モデリングのボトルネック」で取り上げた通り、オブジェクトモデリングでは静的構造モデルと状態機械モデルの実装技術は確立していますが、協調モデルの実装技術が未完成のため、ここは手作業でやらざるを得なくなっているからです。

関数型言語、論理型言語の導入でこの垣根は徐々に下がっていく事になるでしょうが、現時点ではうまく連携できないという前提で考えておくのが無難です。

しかし、協調モデルはユースケース技術による「物語」を使ったシナリオ分析によって、要求モデル、振舞いの外部仕様、静的構造モデルを結びつける技術が確立してます。この「物語」の部分はまさに「日本語」を使ったモデルなので、日本語による記述との親和性が高くなっています。

以上の点を踏まえて、マインドマップモデリングでは「物語」を「脚本」を通して「登場人物」や「道具」といった静的構造に結びつけるメカニズムを提供しています。モデルとプログラムの重なりで欠落する振舞いの部分、つまり協調モデルは「日本語の世界とモデル」の技術を適用することで、緩和できるわけです。

そういう意味でも、日本語の世界、モデル、プログラムを統合的に扱うアプローチは有効ではないかと考えています。

日本語の世界とモデルとプログラム

ソフトウェア開発での論点の一つは、プログラムに落とし込めない日本語で書いた仕様をいかにプログラムとリンクした形で維持していくのかという点にあります。

その解決策としてオブジェクトモデリングの王道であるユビキタス言語をハブとして、モデル化できないゆるい日本語の情報をモデルに結びつけるという手法が考えられます。さらに、ユビキタス言語からモデルやプログラムの重ならない部分もリンクしていくということもできるでしょう。

ユビキタス言語は、日本語の文書かつモデルでプログラムの自動生成付き、という形になるでしょう。マインドマップモデリングを入り口に、こういった技術へのアプローチを考えています。

2012年10月3日水曜日

MindmapModelingと集合知(2) - ユビキタス言語

前回は「マインドマップとDSL駆動開発」としてボクが作っているマインドマップモデリング、SimpleModeling、SimpleModelerと日本語、モデル、プログラムの関係を図で示しました。



ここで問題になるのが日本語の世界、モデル、プログラムという異なった枠組み間をどのようにつないでいくのかという点です。

ここで登場するのがオブジェクト指向技術です。

オブジェクト指向は、再上流の概念モデルから実装を意識した分析モデル、設計モデル、そしてオブジェクト指向プログラミングまで、同じコンセプトで一気通貫しているのが最大の主張点ですから、これを利用しない手はありません。

このコンセプトに適切な名前をつけてパターン化したものが、DDD(Domain-Driven Design)のユビキタス言語(Ubiquitous Language)です。

図にユビキタス言語を追加したものが以下になります。



日本語、モデル、プログラムの共通部分をユビキタス言語としてモデル化して、連携の土台とします。

ユビキタス言語の実現

ユビキタス言語の実現を行うためには、日本語、モデル、プログラムで共通化するモデルの部品を明確にしなければなりません。これはオブジェクト指向技術として大枠は決まっているのでそれを使用します。

  • 名前
  • 属性
  • 名前間の関係
    • 汎化 (is-kind-of)
    • 構成 (is-composed-of)

また、一般的な業務アプリケーションではオブジェクトのモデル上の役割によって実現方法が異なってくるので、そういった点をユビキタス言語に取り入れておくと共通モデル化の精度が上がってきます。

マインドマップモデリングはこの方針に則って以下のモデル上の役割(stereotype)を定義しています。

  • 登場人物 (actor)
  • 道具 (resource)
  • 出来事 (event)
  • 役割 (role)
  • 物語 (business use case)
  • 規則 (business rule)

モデル上の役割の名前からも分かるように、マインドマップモデリングは演劇のメタファを採用しています。このことによって、構築するモデルの動作イメージを簡単に伝えられるようにしています。またソフトウェア開発の経験がない人にも比較的簡単に理解してもらえるのではないかと思います。顧客とのブレインストーミングやモデリング初学者への教育といった用途にも利用することができます。

集合知とユビキタス言語

今回の「クラウド時代の集合知」のセッションでは、オブジェクト指向の重要なコンセプト(をDDDで形式知化したもの)であるユビキタス言語が、集合知の実現技術に何らかのヒントにならないかといったところが論点になればよいなと考えています。

集合知の実現方法としてはオントロジーを使った汎用的な知識モデルをベースにするのが王道と思いますが、実装とリンクした知識の表現方法としてユビキタス言語を評価してみると、何か面白いアプローチが見えてくるかもしれません。

2012年10月2日火曜日

MindmapModelingと集合知

今月の22日にとある名古屋の学際的な集まりで、マインドマップモデリングやモデル駆動開発についてお話させていただくことになりました。このセッションのネタ整理を「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」といった感じで、ブログの上で行なっていきたいと思います。

このブログのタイトル「Modegramming Style」は、モデリングとプログラミングを融合させたソフトウェア開発のスタイルを提案することを意図しています。そのキーテクノロジとなるのがDSLによるモデル駆動開発です。これを実現するための言語として「用途に応じてScalableに言語を拡張できるDSL指向言語」であるScalaを採用しています。

名古屋の集まりは社会科学を中心に、工学、理学の知見を集約してクラウド時代の「集合知」についてアプローチしていくもののようです。

そういった研究に、どの程度参考にしていただけるか分かりませんが、現場発の技術とツールであるマインドマップモデリングとSimpleModelerの説明を行います。

マインドマップモデリングとDSL駆動開発

DSLによる駆動開発をテーマに活動しているわけですが、活動は大きく以下の3つになります。

  • マインドマップモデリング
  • SimpleModeling
  • SimpleModeler


活動の柱が日本語の世界とプログラムを結びつけるメタモデルであるSimpleModelingの開発です。 

マインドマップモデリングは、日本語の世界とSimpleModelingの橋渡しを行うための手法です。

SimpleModelerはSimpleModelingのモデルインスタンスをプログラムに変換するツールです。

メタモデル

その中でこのところの活動の中心としてきたのは、「Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標」や「クラウド温泉3.0@小樽」で考察したクラウド・アプリケーション向けのメタモデルです。この方向で2009年の「クラウド・アプリケーションの作り方 edge2.ccの挑戦」以降色々と手探りで考えてきましたが、現在のところの結論は以下のようになっています。

  • 基本はオブジェクト・モデリング
  • データの種別のモデリングを明確にする
  • データフローの導入
  • メッセージフローの導入

基本は既存のオブジェクト・モデリング+αということで、平凡な結論ですが現場展開を考えると妥当な落とし所かなと思います。

プログラミング的には関数型を取り込んだOFP(Object-Functional Programming)でこれらのモデルをどう捌いていくのかということが焦点になりますが、Scalaだと無理なく実現できると考えています。

日本語の世界

もう一つの大きなテーマは、日本語の世界をどうやってソフトウェア開発につなげていくのかという方法論です。

持続的なシステム開発を行う上では、単に超上流工程で日本語の世界をオブジェクト・モデル一回写像して終わりというわけではなく、ソフトウェア開発のライフサイクルを通じて、持続的に日本語の世界とプログラムの関係を維持していかなくてはなりません。

ここは要件定義の最重要課題でしょう。

また、このライフライクルを構築するには、プログラマが自ら日本語を扱いモデルとの関係を紐付けていくスキルも求めらるでしょう。ツールのサポートも必須です。

この問題に対するアプローチとしてマインドマップモデリングの試行を続けてきました。稚内北星学園大学時代に始めた試みですが、横浜モデリング勉強会として現在も続けています。



セッション

今回の「集合知」というテーマでは、ソフトウェア開発における「日本語」情報のセミフォーマルな取り扱いというのも重要な切り口ではないかと思います。そういう観点で、マインドマップモデリングの成果物を紹介し、クラウド上での「集合知」の収集とモデル化という切り口でディスカッションできればと思っています。

2012年10月1日月曜日

Scalaプログラミングのコツ

今週とある所でScalaソースコード・リーディングを行うのですが、ソースコードを漫然と読んでいるだけでは、ポイントがわかりづらいので、ボクがScalaプログラミングをしながらいつも考えていることをマインドマップに書き出してみました。



ソースコードを読みながら、このマインドマップの項目に即して内容の説明を行う形を取ろうと思っています。

ポイントとなる場所では:

  • なぜこうなっているのか
  • 他の選択肢の存在と得失の比較検討
  • 全体アーキテクチャとポイントでの選択の関係

といったことをマインドマップの情報を補助線に取り上げていくことを考えています。その上で判断の是非、選択肢以外の可能性といったものが議論できればと思います。

このマインドマップは、とりあえず書き出したものでまだまだ抜けがありそうです。今後もScalaプログラミングしながら、色々と書き足して熟成させていく予定です。

本ブログでも、個々の項目はScala Tipsとして取り上げたものもありますが、Scalaプログラミングのコツ、指針といった観点でもまとめていきたいと思います。