SimpleModeler 0.1.9

SimpleModeler 0.1.9を先日公開しました。

http://code.google.com/p/simplemodeler/downloads/list

Google App Engine Javaコード生成の精度を上げています。

関連の格納方法

オブジェクト間の関連の格納方法について考えている。

• 同じエンティティにまとめる範囲、エンティティ・グループにまとめる範囲
• 連鎖削除ありなし
• 同時ローディング、オンデマンド・ローディング
• 検索対象、対象外

• DataStoreデータ型で格納する。それ以外のデータ型はString、Textなどにエンコーディング。Javaプログラム上の表現とJDO格納表現がずれるで注意。

• オブジェクト間に関連については関連、集約、合成、部品で処理方法を調整

• 属性(attribute)
• document(またはvalue)をエンティティの属性とする
• エンティティのカラムに(必要に応じてテキスト、XMLエンコーディングして)格納
  


• 関連(association)
• エンティティ間で連鎖削除はしない
• エンティティは独立して管理
• エンティティをロードする時に、関連先エンティティはロードしない。使用時にオンデマンドでロードする。


• 集約(aggregation)
• 全体エンティティが削除されても部品エンティティは削除されない
• 全体エンティティと部品エンティティは独立して管理
• 全体エンティティをロードする時に、部品エンティティはロードしない。使用時にオンデマンドでロードする。


• 合成(composition)
• 全体エンティティが削除されると部品エンティティも削除される
• 全体エンティティをロードする時に、部品エンティティをロードする。
• 全体エンティティと部品エンティティでエンティティ・グループを構成する。


• 部品(part)
• 部品エンティティはエンティティIDを持たない
• エンティティのステレオタイプとしてpartを用意(DSLでは定義済み)
• partは、全体エンティティの部品として使用するオブジェクト
• 検索対象から外すことによって、全体エンティティのカラムにXMLエンコーディングして格納

SimpleModeler 0.1.8

SimpleModelerは、地道にバージョンアップしていて0.1.7と0.1.8をリリース。

http://code.google.com/p/simplemodeler/
http://code.google.com/p/simplemodeler/downloads/list

現在はGoogle App Engine/Java向けにデータ型まわりを実装中。

以下つぶやき。

Entityの部品をEntityの一部として扱いたい。

Entityの部品をJavaオブジェクトをシリアライズして格納すると持続性に問題がある。

Domain Model - Java - JDO(GAEJ)のギャップを地道に埋めていく。

JDOの基本データ型。これ以外のデータ型も使えないことはないが、できれば使わない方がよい。

• java.lang.String
• com.google.appengine.api.datastore.ShortBlob
• boolean
• java.lang.Boolean
• short
• java.lang.Short
• int
• java.lang.Integer
• long
• java.lang.Long
• float
• java.lang.Float
• double
• java.lang.Double
• java.util.Date
• com.google.appengine.api.users.User
• com.google.appengine.api.datastore.Text
• com.google.appengine.api.datastore.Blob
• com.google.appengine.api.datastore.Key

SimpleModeler 0.1.6

GWの連休ボケでSimpleModeler開発の日記が何となく滞っている。
ただ、SimpleModelerの開発は進んでいて、5月22日にSimpleModeler 0.1.6をリリースした。

[SimpleModeler 0.1.6]

http://code.google.com/p/simplemodeler/

http://code.google.com/p/simplemodeler/downloads/list

SimpleModeler 0.1.6は、AtomPubの自動生成機能を追加した。
-gaej.atomオプションで、AtomPubの参照系のプロトコルハンドラを自動生成する。更新系は折を見てサポートする予定。

serviceに対するGETはこんな感じ。

# curl http://localhost:8080/yorozu/atom/
<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>Entity Repository</atom:title>
<collection href="customer/">
<atom:title>Customer</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes"></categories>
</collection><collection href="goods/">
<atom:title>Goods</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes"></categories>
</collection><collection href="buy/">
<atom:title>Buy</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes"></categories>
</collection>
</workspace>
</service>


collectionに対するGETはこんな感じ。

# curl http://localhost:8080/yorozu/atom/customer/
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Entity Repository</title>
<updated>2009-05-30T22:02:48.010Z</updated>
<id>uuid</id>
<link href="http://localhost:8080/yorozu/atom/customer/" type="application/atom+xml" rel="self"></link>
<link href="http://localhost:8080/" type="text/html" rel="alternate"></link>
<generator uri="http://code.google.com/p/simplemodeler" version="0.1">SimpleModeler</generator>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>ABC(c001)</title>
<id>c001</id>
<updated>2009-05-30T22:02:48.030Z</updated>
<published>2009-05-30T22:02:48.010Z</published>
<link href="c001/" rel="edit"></link>
<content type="application/xml">
<customer xmlns="http://yorozu.com/"><customerId>c001</customerId><customerName>ABC</customerName><phone>045</phone></customer>
</content>
</entry>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>XYZ(c002)</title>
<id>c002</id>
<updated>2009-05-30T22:02:48.030Z</updated>
<published>2009-05-30T22:02:48.010Z</published>
<link href="c002/" rel="edit"></link>
<content type="application/xml">
<customer xmlns="http://yorozu.com/"><customerId>c002</customerId><customerName>XYZ</customerName><phone>06</phone></customer>
</content>
</entry>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>MNO(c003)</title>
<id>c003</id>
<updated>2009-05-30T22:02:48.030Z</updated>
<published>2009-05-30T22:02:48.010Z</published>
<link href="c003/" rel="edit"></link>
<content type="application/xml">
<customer xmlns="http://yorozu.com/"><customerId>c003</customerId><customerName>MNO</customerName><phone>06</phone></customer>
</content>
</entry>

</feed>


memberに対するGETはこんな感じ。

# curl http://localhost:8080/yorozu/atom/customer/c001
<entry xmlns="http://www.w3.org/2005/Atom">
<title>ABC(c001)</title>
<id>c001</id>
<updated>2009-05-30T22:02:34.350Z</updated>
<published>2009-05-30T22:02:34.340Z</published>
<link href="." rel="edit"></link>
<content type="application/xml">
<customer xmlns="http://yorozu.com/"><customerId>c001</customerId><customerName>ABC</customerName><phone>045</phone></customer>
</content>
</entry>


Google Web Toolkit動いた

昨晩、SimpleModelerのGoogle App Engine Java(GAEJ)のGoogle Web Toolkit(GWT)が動き出した。
通常のServlet/JSPのWeb MVC版はすでに動いているので、GAEJ生成器はWeb MVC版とGWT版の2種類の実装を生成することになる。
Web MVCとGWTの双方からGAEJのDataStoreを操作することができる。

GWTは今のところあまり人気がないという話もあるけれど、実際に使ってみるとなかなかよいではないですか。
とっかかりの設定ファイルがやや面倒なのだけれど、こういったところが自動生成でカバーできれば、アプリケーション本体の開発はWeb MVCよりもかなり簡単であるにもかかわらず、Ajaxを使った普通のGUIアプリケーションがWeb上に構築できるというかなり凄い結果を得られる。
普通のJavaオブジェクトを使ったAjaxの非同期通信用の専用RPCであるGWT-RPCも使い方は簡単で、サーバー側の処理を普通にJavaで書けるのもうれしい。
クライアント側とサーバー側の処理をすべてJavaで書いて、Eclipseでデバッグまでできる。
Widgetの部分はプログラマが書いて、Widgetを埋め込むHTMLはデザイナが作るといった分業もJSPとは比較にならないほどスムーズにできそう。
なぜ、流行っていないのか不思議である。

Webアプリケーション技術は新参者なので、事情はよく分からないのだけれど、Webを見てまわると昔は設定が難しいようだったからそういうのも影響があるのかも。でも、GAEJにバンドルされているGWTは特に設定いらずなので、少なくてもこの問題は解消される。

GWTはかなり気に入ってしまったので、SimpleModelerのGAE向け機能はGWTを中心に機能セットを整えていくことにした。

GWT単体でも便利だけれど、自動生成と組み合わせると、これは何ともいえないぐらい強力、というのがSimpleModelerが吐き出したGAEJ+GWTを触ってみた感想。
4月21日(火)のJJUG CCCで、デモしたいと思います。

http://www.java-users.jp/contents/events/ccc2009spring/

Google App Engine Java動いた

昨晩、SimpleModelerのGoogle App Engine Java(GAEJ)が動き出した。
GAEJのSDKでDataStoreの中身を見る方法が分からず、JDOを使うのも始めてなので、疎通が難航することを覚悟していたのだけれど、案外すんなりと動いた。
来週のJJUG CCCでは無事デモができそうである。

Google App Engine Java開発中

先週の水曜(4/8)にGoogle App Engine Javaが公開されたことを受けて、Google App Engine Python向けの機能拡張を保留して、Google App Engine Java向けの開発を開始した。
SimpleModelerではWeb MVCのMをEntity/Service/Documentの構成とするので、全体としてはESDVCとなる。この内、E(Entity)、D(Document)、V(View)は成果物のJavaやJSPがコンパイルできる所まできた。今はC(Controller)とS(Service)の実装中で、これができたら全体をつなげて疎通確認に入る予定。
来週火曜日4月21日のJJUG CCCでは、google App Engine Javaのデモも行いたい。

scala-toolsが落ちてる

今朝、急にmavenのscala-pluginが動かなくなる。

The server hosting scala-tools.org is experiencing a denial of service attack. We expect to have it back up and running really soon now(tm).

だそうです。
でも、-oオプションつけても動かないのは勘弁して欲しいなぁ。
mavenでscala-pluginのバージョン・チェックを回避すればよいかもしれないのだけど、回避方法が分からない。
しばし、待つとしよう。

Dojo Toolkit

Google App EngineのWebアプリケーションでDojo Toolkitを使うようにしてみた。
Dojo Toolkitはかなり大きいので配備の問題が悩ましいなぁと思っていたら、AJAX Libraries APIが使えることが判明。前にAJAX Libraries APIをみた時は今ひとつぴんと来なかったなのだけれど、こうやって実際にWebアプリケーションを作ってみるととても重要なAPIであることが分かった。

Dojo Toolkitはなかなかよい感じ。使い方も簡単で効果も抜群。こういったAjaxライブラリを使うのが、Webアプリケーションを作る際のいまどきの標準ということなのかな。

aggregation

クラウドでは、関連の深いデータをできるだけ近くに配備したいので、個々のデータのメタ情報にそいういった情報を格納する。たとえばGoogle App Engineの場合はデータの親データをKeyに入れているけれど、そういう目的ではないかと思う。
こういった情報の元ネタはモデリングの段階で収集するのが効率的であるけれど、その一つのアプローチがAggregateである。
ただ、「Aggregate Root」というステレオタイプを使うのはややクールでないかなぁ、と思いつつ常々扱いを気にしていたのだけれど、モデル内のaggregationを手繰ってAggregateを自動抽出すればよいことに思いついた。
現在の所SimpleModelerはassociationとcompositionをサポートしているもののaggregationはサポートしていない。というのは、aggregationはモデルの意味・意図が不明瞭であり、使い方が難しい、という評価があるモデルであり、モデル駆動を目指すSimpleModelerでは明確な使い方が見つかるまで、サポートを保留していたのである。
このaggregationを使うと、(ツールがモデルを解析する手間を惜しまなければ)Aggregateを明確に記述できる。Aggregateはクラウド時代にはとても重要なモデルの構成要素でありプラクティスとなるので、このAggregateを成立させるためのモデル要素としてaggregationをサポートする価値は非常に高い。
そのような判断でaggregationをサポートすることにした。
帰宅後、aggregationの実装。同時にcompositionを指定する文法も改良。
無事動作。

折を見て、Aggregateも実装したい。

NetBeans

NetBeansのScalaプラグインの出来がよいとの噂があったので、ダウンロードしてみた。
日本語の識別子には対応していないみたい。がっくし。
SimpleModelerのScala DSLは、IDEのサポートが受けられるとかなり使いやすくなるはずなので、期待してみたのだけれど、日本語の識別子が使えないと現時点では使えないなぁ。

XMLリテラル

Google App Engine用ドメイン・オブジェクトCRUD MVCでは、ScalaのXMLリテラルがとても役になった。

生成するHTMLをXMLリテラルでそのまま記述できる。その上で、「{」「}」で囲んだ所にScala関数を評価した結果が挿入される。そのままテンプレートエンジンである。


　　val html =
<html>
<head>
<title>Show {capitalizedTerm}</title>
</head>
<body>
<h1>Show {capitalizedTerm}</h1>

<table class="datasheet">
<tbody>
{
　for (attr <- entity.attributes.toList) yield {
　　<tr>
　　　<td>{attr.name}</td><td>{{{{doc.{attr.name} }}}}</td>
　　</tr>
　}
}
</tbody>
</table>

<table class="action">
<tr>
　<td><form action={getActionPath("edit")} method="get"><input type="hidden" name="key" value={getIdCode} /><input type="submit" value="Edit" /></form></td>
　<td><form action={getActionPath("destroy")} method="post"><input type="hidden" name="key" value={getIdCode} /><input type="submit" value="Delete" /></form></td>
</tr>
</table>
　　
<table class="menu">
<tr><td><a href={getActionPath("index")}>Index</a></td><td><a href={getActionPath("new")}>New</a></td></tr>
</table>

</body>
</html>


作成したXMLをテキストとして出力するのはこんな感じ。


XML.write(out, html, entityContext.textEncoding, false, null)


ScalaのXMLはこの他にも色々便利な機能がある。
Web系のプログラムだと何かとXMLやHTMLを使うことが多いので、言語ネイティブのXMLサポートは重要ですね。

Google App Engine CRUD MVC動いた

SimpleModelerドメイン・オブジェクトに対するGoogle App EngineのCRUD MVC&Serviceが動いた。ふぅー。
Model, Serviceに加えて、ViewとControllerも自動生成できるようになった。

Web MVCの自動生成器を作ってみて、Webアプリケーション開発が大変なことを実感。
ここが自動作成できたら、かなり便利なはずである。

今はCURDの範囲だけれど、もう少し自動生成の範囲を広げることができると考えている。
この実現のメカニズムとしてdocumentとstateMachineを作りこんできた。また、昨日書いたように画面遷移モデルをサポートすればさらに自動生成の範囲が広がる。
ここからは先が長そうなので、様子を見ながらぼちぼち取り掛かることにしたい。

Google App Engine MVC

次の組合せでGoogle App EngineのMVC&Serviceが動いた。ふぅー。

Model: 自動生成
Service: 自動生成
View: 金型
Controller: 金型

すっかりPythonプログラマである。
次は、金型をSimpleModelerに取り込んで自動生成する処理の開発。
4月21日のJJUG CCCでデモできそう。

Webフレームワーク

Google App EngineのWebフレームワークとGoogle App Engine Oil（GAEO)を調査している。
GAEOでURLとMVCの実装を:controller/:actionのコンベンションに結び付けている部分が面白い。一種のリンカですね。
本家のRuby on Railsは:controller/:action/:id.:formatというコンベンションのようだけれど、こういったURLと実装の動的リンク機能(何か名前がついているんだろうなー、以下ではURLルーティングと呼ぶことにする)がRuby on Railsの柱の一つであり、これをGoogle App Engine(GAE)で実現しようとしているのがGAEOということである。
GAEOのCRUD VC自動生成はまだまだ発展途上だと思われるけれど、このURLルーティング機能は現時点でもかなり使える。

と、ここでSimpleModelerのGAE生成器だけれど、GAEOに全面依存するのもリスクがあるので、gaeサービスではGAEのみを使うようにしようと思う。URLルーティングも簡単なものを自前で実装することにする。
これとは別にgaeoサービスでは、GAEOのURLルーティングを活用したプログラムを自動生成することにしたい。

調べてみるとWebのこのあたりの技術はなかなか面白い。こういった処理を実装する場合、メタ・プログラミングを使ってコンベンションによる動的リンクが非常に有効なのでPythonやRubyのような動的言語が大人気なのもよく分かる。
ただ、こういったWeb MVCの実装は、自動生成の格好の対象であることも感じた。
単純な繰り返しのプログラミングは、コンベンションと動的リンクで解決することも可能であるけれど、プログラムの自動生成で解決することも可能である。
プログラムの自動生成をするのであれば、ターゲットのプログラミング言語は静的型付のものでよい。つまり、自動生成を前提にするとテーゲット言語はJavaのみでも、Ruby on RailsやPython Djangoと同等のWebアプリケーションの開発効率が得られると思われる。
開発言語がJava指定の案件でも、Ruby on RailsやPython Djangoと同等の開発効率が得られれば魅了的である。

そうはいっても、RubyやPythonを主力言語として開発している人がわざわざJavaをやるというのも考えにくいので、結局の所、色々な言語の色々なWebフレームワークが並存することになるだろう。顧客が指定するWebアプリケーションの言語やフレームワークも多極化することになるだろうから、どのような組合せであっても対応できるのが開発者側のスタンスとしては望ましい。
こういったニーズに対してSimpleModelerのようなモデル・コンパイラは有力なソリューションである。

今回、Webフレームワークを調べてみて、SimpleModelerでかなりの部分を自動生成できるように感じた。ただし、ユースケースやドメイン・モデルから自動生成できるという意味ではなくて、システム・モデルとして画面遷移モデルなどの専用PIMモデルを定義すればである。
Webのフロントは開発工数も大きい上にバグの出やすいところでもあるし、要件定義から実装までの各段階で試行錯誤が必須の部分なので、PIMモデルからの自動生成ができれば、その効果は計り知れないだろう。
SimpleModeler的には、Scala DSLで定義した専用画面遷移モデルから、画面遷移図と各種Webフレームワーク向け実装の自動生成の機能ということになる。画面遷移モデルとドメイン・モデル、ユースケース・モデルとの連携は確保すれば、上流モデルからWebフレームワーク向け実装まで一気通貫で開発することができる。
GAEが一段落したら、SimpleModelerをそちらの方向に延ばしてみようかな。

GAEOのMVC遷移

メモ。

GuestbookController
==create
====r.put()
====/guestbook

==destroy
====Guestbook.get()
====r.delete()
====/guestbook

==edit
====Guestbook.get()
====template/guestbook/edit.hml
======/guestbook/update

==index
====Guestbook.all()
====template/guestbook/index.hml
======/guestbook/new
======/guestbook/show?key

==new
====template/guestbook/new.hml
======/guestbook/create

==search
====?

==show
====Guestbook.get()
====template/guestbook/show.hml
======/guestbook/edit?key
======/guestbook/destroy?key

==update
====Guestbook.get()
====r.put()
====/guestbook

コントロール、サービス、ドキュメント

週末にPythonと格闘してGoogle App Engineの金型をつくったので、これをベースにSimpleModelerのGoogle App Engine生成器のリファインを開始。

Ruby on Rails、Grails、Google App Engine、Google App Engine Oilを一通り調べて、これらのWebフレームワークが共通して持っている問題だと思うのは、MVCのコントローラからPSM(Physical Data Model)をダイレクトにマップしたモデルを直接触る構造になっているということである。もちろん、アプリケーションが意識すればそういう構造にしないことも可能だけれど、自動生成されるCRUDのコントローラはPSMモデルを直接操作する構造になっているし、色々なクックガイドのサンプルもそういう形になっている。
この方式が問題なのは、UIのコードがデータベースのデータ構造を直接意識してしまうことと、アプリケーション・ロジックがUIコードに断片としてばら撒かれてしまう点にある。また、UIデザイナとアプリケーション・プログラマの仕事が分離しづらいという問題もある。
この問題はかつてのCS(Client/Server)で既知のものであり、CSシステムの保守や拡張を大変にしている。
作っているプログラマは楽だけれど、その後、高コストになるアーキテクチャなのである。

もちろん、作り捨てで拙速を重要視するタイプのシステムはこの戦略が合っているわけだけれど、"持続性"が大事な企業アプリケーションではそういうわけにはいかない。

この問題を解決するためには、アプリケーション・ロジックをコントローラから分離し、サービスとして独立したジュールとして作成。コントローラからはサービスを呼び出すという構造にするのがよい。
この時、コントローラからサービスを呼び出す際には"構造を持った値"によってパラメータの受け渡しをすることになる。この目的でSimpleModelingが用意しているモデル要素がdocumentである。

以上のような理由によって、SimpleModelerでは、MVCのコントローラとアプリケーション・ロジックを分離して、アプリケーション・ロジックをサービスとして部品化する構造のアプリケーションを自動生成を指向している。このアプリケーション・アーキテクチャでは、ドメイン・モデルの操作もできるだけサービスとしてカプセル化する。

昨日の作業で、この方針に沿ったそれなりのコードが出てくるようになった。
今朝から、Google App Engine SDK上で生成されたコードのデバッグとチューニング。かすかに動き始めたようである。

python

entityとdocumentのマッピング、状態機械モデルからステートマシーン図と状態遷移表の生成ができるようになって、動的モデルを含むドメイン・モデルを扱うプログラムの生成の土台ができた。

エンティティ・オブジェクトの実装はgaeオプションやgaeoオプションですでに実現済みだけれど、状態機械による振舞いの記述やドメイン・オブジェクトを束ねるドメイン・コンポーネントといったものも生成できるようにすることを考えている。

Google App Engine用のプログラム生成器を本格的に取り掛かるわけだけれど、その前にPythonをちゃんとマスターしないといけませんねー。

ということでPythonに取り掛かる。チョー久々にEclipse Ganymedeを動かしてPyDevを入れてみた。
Eclipse使うの久しぶり。
試しにScalaのプラグインも更新してみたけど、あんまり進展はないみたい。

Pythonは、インデントを文法の論理要素に取り込んだ文法が特色だけれど、それを除いてみるとLispの上に外付けにオブジェクト機能をつけた言語という印象。オブジェクト指向言語としては美しくないような気もするけれど、メタなプログラミングをしたいフレームワーク系の人には逆に分かりやすくてよいかもしれない。
フレームワークが充実すれば、結果としてアプリケーション・プログラマにも恩恵があるので、文法が多少不思議系でもトータルとしてはメリットの方が大きい、ということかな。
その文法もとても簡潔で使いやすいので、不思議系の部分はおまじないと考えれば気にならない。

Djangoとの組合せはとてもバランスがよくて、Webアプリケーションのプレゼンテーションはこういった軽量言語が合っているということを実感。これは、ちょっと前に調べたGrailsでも感じたこと。

プレゼンテーション=>軽量言語、アプリケーション・ロジック=>Java、フレームワーク・DSLコンパイラ=>Scalaで3極化というのをこの間のセミナーのスライドで書いたけれど、そういうことなんだろうと思う。

合成状態の状態遷移表

合成状態(composite state)の入った状態遷移表が無事生成できるようになった。
横軸はイベントとガードの組、縦軸は状態の表である。合成状態は合成状態を構成するサブ状態と合成状態の擬似状態2つ(初期状態、終了状態)、そして合成状態全体を示す状態のそれぞれを軸として使用する。
この2つの軸のマトリクスによってエンティティの状態遷移を記述することができる。
また、プログラムの自動生成もこの状態遷移表の振舞いをプログラムコード化したものになる。

ネットワーク系のアプリケーションでは、仕様の概要を見るには状態遷移図がよいけれど、プログラムとして実装するためには、状態遷移表の形でより具体的、網羅的な情報が必要である。この状態遷移表で「N/A」となっている部分が仕様としてありえない組合せだけれど、実システムでは往々にしてこのような状態に陥ることがあり、そうなった時の予防的なロジックを仕込んでおく必要がある。このような抜けを網羅的につぶしていくためには状態遷移表を用いるのが有効である。

そんなこんなで、合成状態をサポートした状態機械のステートマシーン図と状態遷移表ができるようになった。
次はアクションのサポートである。

合成状態

ステートマシーン図の合成状態(composite state)完成。
合成状態そのものに対する遷移を、開始/終了擬似ステートではなくて合成状態のシンボルそのものにするようにした。このあたりはGraphvizと格闘した所。
UMLの合成状態のフルスペックというわけではないけれど、実用的には十分でしょう。後はニーズ駆動で作り足ししていく。

Graphvizのdotコマンド呼び出しでハングアップする件は、標準エラー出力のバッファあふれみたい。dotコマンド起動時にWarning出力を抑止して解決。
外部コマンドを起動して標準入出力で連携する処理を汎用的に書く場合には、標準入出力および標準エラー出力の3つの入出力に対してそれぞれ別スレッドで対応しなければならない。単一スレッドで対応する場合にはselectシステムコールを使ったポーリングのメカニズムとなる。いずれにしても単純ではない。
起動するコマンドの振舞いによっては、標準入力に一括書き込み(コマンド側は読み込み)、標準出力から一括読み込み(コマンド側は書き込み)という逐次処理で連携できることがある、という特殊な連携パターンであるということを念頭においておかなければならない。
今回の場合は、dotコマンドが一括入力、一括出力のバッチ処理であることと、コマンド引数で標準エラー出力を抑止、という工夫を併用することで、特殊な連携パターンが可能になったということである。

composite state

ステートマシーン図のcomposite stateを作成して、何とか図が出力されるようになった。ただ、謎のハングアップをするのでデバッグ継続中。

関連して2つ目の図は昨日作成したentityとdocumentの関係を記述したクラス図。

JavaDSL

SimpleModelerはScalaをDSLのホスト言語として採用しているのだけれど、以前はJavaをDSLのホスト言語として使用するモデルコンパイラを作っていた。
Javaだと記述能力上の問題もあり、Scalaがよさそうということで去年JavaからScalaに乗り換えたという経緯がある。

この間のedge2.ccでJavaのDSLを評価する声があった。理由はEclipse。Eclipseを使うとJavaのコード補完がものすごいからである。
以前JavaDSLを作っていた時も、この理由でJavaを採用したのであった。

Scalaは、DSLのホスト言語としてとても優れているので、Scalaをメインにすえるのは問題ないのだけれど、あまり複雑でないオブジェクトの定義についてはJavaをホスト言語にしても十分に記述可能なので、SimpleModelerでJavaをDSLとしてサポートする価値は高いかもしれないと思い始めている。すべてをJavaで記述しようとしなければ十分に実現可能である。
状態遷移表をExcelで書きたいというニーズもあるようなので、どこかのタイミングでこういったScala以外のDSLもサポートしていくこともしたいところである。

document、subgraph、gae、grailsなど

昨日は、entityとdocumentのrelationshipの定義機能の追加と、entityとdocumentのマッピング機能のリファイン。これらの関係を表現するクラス図の生成ができるようになった。

今日から状態機械のネストに取り掛かる。
Graphvizのsubgraphに格闘。subgraph名は先頭が"cluster"となっていないといけないらしい。バグじゃないかなぁ。ドキュメントにはそんなこと書いてないぞ。

ふと、思いついたこと。
クラウド・アプリケーションは、ACIDのRDBMS、BASEのクラウドDBを併用するアプリケーション・アーキテクチャを取る。
さて、そこで、Google App Engine。Google App Engineは当然ながらBigTableをラップしたと思われるクラウドDBしか使用することができない。このため、RDBMSを使用するためには外部のサーバーを利用する必要がある。
このようなアーキテクチャを取る場合、Google App EngineとGrails on EC2という組合せはどうだろう。
Google App Engineの範囲でできること、Googlen App EngineでなければできないことはGoogle App Engineで行い、RDBMS、SpringやJava EEといった所を使いたい場合にはGrails on EC2を併用するわけである。
Google App EngineからGrailsの呼び出しはRESTやSOAPを使えばよい。
もちろん、Messagingも使えればよいのだけれど、現時点ではGoogle App Engineでサポートしていない。そういう意味では、Java EEのJMSを利用するためにGoogle App EngineからGrails on EC2を使いにいくのもありえる。
SimpleModelerではGoogle App EngineとGrailsの両方をサポートしているので、この併用アーキテクチャもサポートできたら面白そうである。

grailsとgaeoのcontroller

GrailsとGoogle App Engine Oilのcontrollerを比較。

Grails:

• index
  
• list
  
• show
  
• delete
  
• edit
  
• update
  
• create
  
• save
  

Google App Engine Oil:

• create
  
• destroy
  
• edit
  
• index
  
• new
  
• search
  
• show
  
• update
  

さて、どうするか…

状態機械と文書

3/7のSapporo Java Days 2009 Winter、3/13のatWorksも無事終了し、これらのセミナーをターゲットに開発してきたGrails、Google App Engineも一応動作するようになった。
また、状態機械もかなりよいところまで実現できた。

これらの成果はSimpleModeler 0.1.4として公開している。

3/13のatWareに続いて、3/14のedge2.cc、3/15のMindmapModeling勉強会(SimpleModeling勉強会)での反応をみると、Google App Engineは当然として、状態機械の評判がよい。
状態機械は必要な技術であることは認識しているものの、うまく使いこなせない、ツールが整備されていないといった微妙な立場の技術といえる。
そういった意味で、状態機械はモデル駆動開発を成功させる鍵となる技術であると考えていたのだけれど、その点を確認できてよかった。

ということで粛々と状態機械の実装を続けている。

また、状態機械をプログラムとして実装する上で、SimpleModelingでdocumentとしてモデル化する文書オブジェクトの存在が重要であると考えている。
ということで、今日からdocumentを整備して状態機械に接続する処理の開発に入った。

mavenではまる

あさってのSapporo Java Daysで行う予定のデモの確認をしようとしたら、突如動かなくなっていた。
調査の結果、mavenのscala pluginのバージョンが3月2日に2.10に上がったことの影響のようである。
2.10でpomのエラーチェックを強化したようなのだけれど、SimpleModelが取っているマルチ・プロジェクト方式のプロジェクトのpom.xmlをうまく認識できずエラーとしてはじくことが原因のように見える。正確に調査したわけではないので絶対にそうかどうかは不明だけど。
とりあえずはprojectサービスで生成するpomでscala pluginのバージョンを2.9に指定して回避することができた。
美しい本格的な対処方法はちょっと大変なので、当面はこの方法で回避しておくかなぁ。

あさってのデモでちゃんと動くことを願うばかりである。

状態機械

SimpleModeler 0.1.3b (20090301)でステートマシーン図描画のバグを修正して以下のようなステートマシーン図を表示できるようになった。

ステートマシーン図と同時に状態遷移表も作成する。

複雑な振舞いをするオブジェクトのモデリングでは状態遷移図(ステートマシーン図)と状態遷移表の両方が必要なので両方を同時に生成するSimpleModelerのアプローチは有効だと思う。

また、現在開発中の版では以下のように状態機械の存在をクラス図に記述するようにしてみた。オブジェクトの持つ状態と状態遷移を引き起こすイベントの関係を明確に表現できる。

SimpleModeler 0.1.3b (20090301)

SimpleModeler 0.1.3b (20090301)を公開しました。

0.1.3の内部リリース版です。バグ修正が主ですが、CSVやXMindからの移入機能を強化しています。

http://code.google.com/p/simplemodeler/downloads/list 

SimpleModeler 0.1.2リリース

SimpleModeler 0.1.2をリリースしました。

以下プログラマ日記より

===

Scala DSLを用いたモデルコンパイラSimpleModeler 0.1.2をリリースしました。 

今回の目玉機能は： 

- CSVの移入 

- マインドマップ・モデルの移入(XMind形式) 

- CSVからマインドマップ・モデルへの変換です。 

その他、SimpleModelerの機能は以下の通りです。 

-javaオプション：Javaソースコード生成 

-htmlオプション：Web仕様書生成 

-grailsオプション：Grails POGO(Plain Old Grails Object)生成 

ダウンロードは以下の場所から。 

http://code.google.com/p/simplemodeler/downloads/list 

日々の開発の様子は以下の日記にて。 

http://simplemodeler.blogspot.com/ 

インストール方法はこちらを参照してください。

 http://groups.google.co.jp/group/simplemodelingsemi/web/simplemodeler

ユーザーガイド作成中

ただいまユーザーガイド作成中。現在35ページ。

例題を作りながらCSVからの移入がなかなか便利なのを実感。Excelからの移入も便利そうなので作ろうと思う。

GrailsはMavenと統合したらしい。

SimpleModelerのリポジトリはMavenプロジェクトなので、この統合は都合がよい。

近いうちにSimpleModelerのgrailsサービス(grails生成器)を、Grails on Mavenに対応させたい。

ユーザーガイド

クラウド関係の原稿を書いていたので開発は小休止というところ。

いずれSimpleModelerにもクラウド向けの機能を入れたい。

原稿が一段落したので、ユーザーガイドの作成を開始。

Annotated CSV

日曜日にSimpleModeler 0.1.2bを公開。

http://code.google.com/p/simplemodeler/downloads/list

日曜日のSimpleModeling勉強会のデモで使用した版である。

昨日(月曜)にブログでも公開。

SimpleModelerが取り込めるCSVは、ボクがこの目的で作ったAnnotated CSVという形式のCSVを入力ファイルとする。

たとえばSimpleModelerに用語を移入するための最小のCSVは以下のように用語を並べたものである。(なお、上記の版ではバグで動かない。(汗))

---

customer

clerk

goods

buy

---

Annotated CSV（以下ACSV)では、先頭に#をつけた行で注記(annotation)を入れていく。注記は、新たな注記があるまで有効となる。

上記のCSVに注記を入れてみる。

---

#actor

customer

clerk

#resource

goods

#event

buy

---

このACSVは、customerとclerkがactor(登場人物)、goodsがresource(道具)、buyがevent(出来事)であることを定義している。(このACSVと次のACSVは上記の版のSimpleModelerで動作する。)

ACSVでは、複数カラムに対する注記も行うことができる。

---

#actor,term_ja,caption,brief,description,parts,base,tableName

customer,顧客,customer's caption,customer's brief,customer's description,,,CUSTOMER

clerk,店員,clerk's caption,clerk's brief,customer's description,,,CLERK

#resource

goods,商品,goods's caption,goods's brief,customer's description,,,GOODS

#event

transaction,取引,buy's caption,buy's brief,customer's description,customer;clerk,,,TRANSACTION

buy,購入,buy's caption,buy's brief,customer's description,goods,transaction,BUY

---

このACSVでは、先頭行の注記によって、第1カラム：アクター名、第2カラム：日本語用語、第3カラム：見出し、第4カラム：摘要、第5カラム：記述、第6カラム：部品、第7カラム：基底クラス、第8カラム：テーブル名であることを定義している。

2行目と3行目はこの定義が適用されるので、それぞれ以下の意味となる。

[2行目]

アクター名：customer

日本語用語：顧客

見出し：customer's caption

摘要：customer's brief

記述：customer's description

部品:N/A

基底クラス：N/A

テーブル名：CUSTOMER

[3行目]

アクター名：clerk

日本語用語：店員

見出し：clerk's caption

摘要：clerk's brief

記述：clerk's description

部品:N/A

基底クラス：N/A

テーブル名：CLERK

ACSVでは、注記を追加することができる。

4行目では「#resource」という注記行であるが、これは第1カラムのみ「resource」とし、第2カラム以降は以前の設定を引き継ぐ、という定義となる。

このため、第5行目は以下の意味を持つことになる。

[3行目]

リソース名：goods

日本語用語：商品

見出し：goods's caption

摘要：goods's brief

記述：goods's description

部品:N/A

基底クラス：N/A

テーブル名：GOODS

以上のようにACSVを用いれば、構造を持ったデータを必要な情報のみを記述して定義することができる。

SimpleModelerでは、このACSVを用いてデータの移入を行うことができるので、初期データの構築などを効率よく行うことができると考えている。

CSVからMindmapへの変換

開発中だったCSVとMindmap(XMind)の移入機能が一応動作。

CSVからMindmap(XMind)への変換も動作するようになった。

ここまでの作業で、CSV→Mindmap(XMind)→Scala DSL→Grailsのパスが通った。

つまり:

1. CSV形式で用語集などを用意
2. Mindmap(XMind)に変換
3. Mindmap(XMind)で大枠のモデルを作成
4. SimpleModelプロジェクトの足場を生成
5. Scala DSLに移入
6. Scala DSLでモデルを編集
7. Web仕様書を生成し仕様を確認
8. Grailsの足場を生成
9. Grailsのドメイン・モデルを生成
10. Grailsで開発

といった手順で開発の一連の手順が繋がったわけである。

またまだデモレベルだけれど、この土台の上で機能を充実させていく予定である。

CSV、マインドマップの移入

先週からCSVとマインドマップの移入機能を開発中。

CSVからScala DSL、XMindからScala DSLへの基本的な移入を行えるようになった。

CSVで用語の一覧表、XMindでマインドマップモデルを作成し、ここからScala DSLに移入。

Scala DSLを編集してモデリング。最後にGrailsのプログラムを生成。

といった開発ができるようになる。

XMindは、XMLや画像ファイルをZipで固めたファイルフォーマットになっているので、マインドマップ情報を操作するのにXMLプログラミングが必要となる。

Relaxerを使ってもよかったのだけれど、今回はScalaのXML機能を試してみた。

これが、なかなか良くできて便利。Scalaは基本機能として木構造を扱うのにとても便利な言語だけれど、XML用文法を最初から持っているため、両機能の相乗効果でXMLの操作がとても楽にできるのである。

Scalaは使っていて日々便利さを実感している。ただ、文法が難しいのでJavaのように一般的になるような感じでもなさそう。SimpleModelerのようなモデル・コンパイラ作成といった分野向け言語ということになるかも。

scaffold

UMLステートチャート図の作成が一段落したので、scaffoldの作成に入った。

プロジェクト作成の基本的なところは動作。

外部データの移入機能を作成開始。まずはCSVから。

Scalaコンパイラのバグらしきものに遭遇。

ScalaのRegex便利。extracterが使いやすい。

SimpleModeler 0.1.1

昨日SimpleModeler 0.1.1をリリース。

ダウンロードは以下の場所から。

http://code.google.com/p/simplemodeler/downloads/list

使用方法や技術的な考察などは、以下の日記に書いていく予定。

http://d.hatena.ne.jp/goldenport/

この日記では、日々の開発ログを書いていく予定にしている。