SimpleModeler開発日記

SimpleModeler 0.1.9

2009-07-29T18:15:00.002+09:00

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

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

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

SimpleModeler 0.1.8

2009-06-25T10:15:00.003+09:00

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

2009-05-31T06:56:00.002+09:00

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動いた

2009-04-18T06:00:00.003+09:00

昨晩、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動いた

2009-04-15T10:48:00.003+09:00

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

Google App Engine Java開発中

2009-04-13T18:34:00.002+09:00

先週の水曜(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が落ちてる

2009-04-07T08:41:00.002+09:00

今朝、急に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

2009-04-06T11:06:00.002+09:00

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

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

aggregation

2009-04-03T10:09:00.004+09:00

クラウドでは、関連の深いデータをできるだけ近くに配備したいので、個々のデータのメタ情報にそいういった情報を格納する。たとえば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

2009-03-31T09:06:00.002+09:00

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

XMLリテラル

2009-03-27T10:16:00.003+09:00

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動いた

2009-03-26T11:02:00.003+09:00

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

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

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

Google App Engine MVC

2009-03-25T16:40:00.002+09:00

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

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

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

Webフレームワーク

2009-03-25T06:59:00.003+09:00

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遷移

2009-03-24T23:19:00.003+09:00

メモ。

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

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

2009-03-24T07:36:00.002+09:00

週末に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

2009-03-20T09:02:00.002+09:00

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

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

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

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

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

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

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

合成状態の状態遷移表

2009-03-19T12:56:00.003+09:00

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

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

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

合成状態

2009-03-19T04:45:00.004+09:00

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

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

composite state

2009-03-18T17:58:00.007+09:00

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

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

JavaDSL

2009-03-18T13:14:00.002+09:00

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など

2009-03-18T09:43:00.002+09:00

昨日は、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

2009-03-17T18:40:00.002+09:00

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

さて、どうするか…

状態機械と文書

2009-03-17T11:41:00.003+09:00

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ではまる

2009-03-05T15:01:00.002+09:00

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

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

状態機械

2009-03-03T07:47:00.004+09:00

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

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

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

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

SimpleModeler 0.1.3b (20090301)

2009-03-01T15:19:00.002+09:00

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

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

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

SimpleModeler 0.1.2リリース

2009-02-22T10:59:00.005+09:00

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

ユーザーガイド作成中

2009-02-21T09:17:00.003+09:00

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

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

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

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

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

ユーザーガイド

2009-02-18T17:51:00.002+09:00

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

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

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

Annotated CSV

2009-02-10T04:49:00.003+09:00

日曜日に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への変換

2009-02-07T17:44:00.002+09:00

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

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

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

つまり:

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

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

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

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

2009-02-02T16:23:00.002+09:00

先週から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

2009-01-30T07:52:00.003+09:00

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

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

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

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

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

SimpleModeler 0.1.1

2009-01-29T17:22:00.002+09:00

昨日SimpleModeler 0.1.1をリリース。

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

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

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

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

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

状態機械

2008-12-24T02:40:00.000+09:00

パワータイプと状態機械をScala DSLで記述する方法について試行錯誤しつつ実装。

ユースケースによって発生するドメイン・イベントとドメイン・リソースの状態機械を有機的に結びつけることができそうな感触を得た。このあたりは汎用性を目指すUMLでは、利用者に任されているところなのだけれど、使い方をよほど真剣に考えないと実運用に適用できるレベルで具体化できないので、結局使われないままになってしまうという結果になっていると思われる。この点をモデリング手法で定型化することで、一般で利用可能にすることが SimpleModelingの狙いの一つである。

実装を続けながら、アプリケーション開発では状態機械の置き場所が一つの論点であることに気付く。
ドメインオブジェクトの状態機械で色々なアクションを行うようにすると、ドメイン・モデルとアプリケーション・モデルが好ましくない方向で密結合になってしまう。アプリケーション・モデルはドメイン・モデルに依存するけれども、ドメイン・モデルはアプリケーション・モデルから独立させたい。
ドメイン・モデルの状態機械で色々なことを始めると、最終的に業務プロセスの作業手順をドメイン・モデルが抱え込むことになってしまう。
この問題を解決するためには、ドメイン・オブジェクトの状態機械にアプリケーション・モデルの状態機械をかぶせるような実現方法が必要になってくるかもしれない。そういったプログラムを自動生成するには...などとつらつら考える。

業務ユースケースのextend

2008-12-16T11:31:00.001+09:00

このところ業務ユースケースのextendの実装を続けている。今朝、なんとか疎通した。ちょっとした勘違いで数日デバッグに費やす。プログラミングはどれだけデバッグに耐えられるかという耐性によるところが大きい。

ユースケースを扱うツールを書いてみるとよく分かるけれど、ユースケースを準形式的に書くために意識しなければならない点は多い。こういった点まで網羅した参考書は見かけたことがなく、今の専らの参考書は『The Unified Modeling Language Reference Manual 2nd』である。ここに定義しているUMLのメタ・モデルをどのようにDSLで表現するのか、という作業を続けているともいえる。

業務ユースケースフロー

2008-12-11T21:45:00.000+09:00

SimpleModelerは業務ユースケースのフローを扱う処理を開発中。既存の手法だと、フローは自然文で書いて後は目視のみなので、実運用上開発に必要な情報量を記述することが困難。実際にユースケースのフローを扱う処理を書いているとかなりややっこしいことが分かる。こういうややっこしいことを手作業で開発者に強いるのは、まず機能しない。やはり、定型フォーマットに会わせて書いた物をツールで検証しかない。

業務ユースケース

2008-12-07T03:43:00.002+09:00

現在は業務ユースケースの実装を行っている。その中で特にScala DSLでフローを記述する手法を試行錯誤中。

task("商品を購入する") {
step_client_worker_system(DS顧客購入().operation("顧客購入")) {
event_issue(DEE顧客購入()) {
resource_update(DER商品())
}
} mark_is "buy3"
}

という定義から:

というフローを生成できる所まできた。
次の課題は、(1)ユースケース間の関係と(2)エンティティの状態遷移の2つをどのように取り込むのかである。

TODO

2008-12-05T15:27:00.002+09:00

この間の日曜日(11/30)にBeProudさんのモデル駆動勉強会でSimpleModeling/SimpleModelerの紹介をしてきました。とてもよいフィードバックを得られて感謝です。

以下、その中ででたコメントから、SimpleModelerでサポートするとよいと思われる機能をメモしておきます。

既存のデータベースからのリバース
UML図の自動生成

また、懸念事項として、モデルと生成したソースコードのずれの問題が挙がりました。これは、11/14のUMTPでのセッションでも挙げられた問題で、モデルコンパイラのお話しをすると必ずされる質問です。

これについてはプログラマ日記にSimpleModelerの方針を書きました。

実現したい機能

2008-11-07T17:21:00.002+09:00

SimpleModelerを実現するための基礎工事が一定の地点まで到達し、基本機能の疎通もできたので0.1としてリリースしました。

現在できるのはSimpleModelのドメイン・モデルからJavaクラスとWeb仕様書の生成です。

ただ、JavaクラスはPOJOレベルの単純なものなので、Factory機能や永続化などの機能の自動生成まで行うことを予定しています。『Domain Driven Design』の技術はかなりパターン化されているので、これを自動生成するのが目標です。

Web仕様書は、DSL(Domain Specific Language)で記述したことをYUI(Yahoo UI)を使ってきれいに表示できるようにしたレベルです。ただし、オブジェクトが誰にどのように利用されているのかという情報を「参加」という項目で記述しています。

単に、DSLに記述したことを字句上で変換するだけではなくて、モデルの内容を解析したうえで、プログラマが関心をもつ色々な切り口の情報を記述していくのが目標です。たとえば、ユースケースを実行するとイベントの発生やリソースの状態遷移が起こりますが、逆にイベントやリソースの立場では、どのユースケースに参加する時に自分が生成されたり、状態が変えられたりするのかという点を知りたくなります。こういった情報をツールで抽出することがSimpleModelerに持たせたい機能の一つです。

SimpleModeler 0.1

2008-11-05T07:24:00.004+09:00

SimpleModelerは、ScalaベースのDSLで記述したSimpleModelingのモデル体系であるSimpleModelからJavaプログラムや仕様書を生成するためのモデル・コンパイラです。

開発も端緒についたばかりで、実用に利用するにはまだまだ機能不足ですが、最初の第一歩ということで公開します。

SimpleModelerのホームページは以下のURLです。

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

SimpleModeler 0.1は以下のページからダウンロードできます。ソースコードはSubversionからチェックアウトすることができます。

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

[セットアップ方法]

上記のURLからsimplemodeler-0.1-setup.jarをダウンロードします。

このインストールプログラムを以下のように起動します。

$ java -jar simplemodeler-0.1-setup.jar

インストールディレクトリを聞いてきますので入力します。デフォルト値で良い場合にはそのままリターンを押下します。

Install directory [default: C:\usr\local\lib\simplemodeler]:

コマンドスクリプトのインストールディレクトリを聞いてきますので入力します。デフォルト値で良い場合にはそのままリターンを押下します。このディレクトリには実行パスが通っている必要があります。(インストール後に設定しても可)

Command directory [default: C:\usr\local\bin]:

以下のように設定の確認をしてくるので良ければ"yes"を入力します。

[Configuration] Install directory = c:\usr\local\lib\simplemodeler Command directory = c:\usr\local\bin  Type yes to install, no to re-enter, exit to exit Type yes:

以下のようにインストールが実行されます。

この例はWindows上での実行例でCommand.com用のBATファイルとCygwin用のシェルスクリプトが生成されています。

Extract archives... Generate script...   script = c:\usr\local\bin\simplemodeler.bat   script = c:\usr\local\bin\simplemodeler Done.

UNIXの場合には、生成されたスクリプトに実行権がついている必要があります。 chmodコマンドを使って実行権を付加してください。

これでインストールは終了です。スクリプトのインストールディレクトリにパスが通っていればすぐにでも実行を行なうことができます。

以下のように実行できればインストール完了です。

$ simplemodeler -version Copyright(c) 2008 ASAMI, Tomoharu. All rights reserved. SimpleModeler Version 0.1 (20081105)

examples/com.yorozuにサンプルがあるので参照してください。

SimpleModeler開発日記

SimpleModeler 0.1.9

関連の格納方法

SimpleModeler 0.1.8

SimpleModeler 0.1.6

Google Web Toolkit動いた

Google App Engine Java動いた

Google App Engine Java開発中

scala-toolsが落ちてる

Dojo Toolkit

aggregation

NetBeans

XMLリテラル

Google App Engine CRUD MVC動いた

Google App Engine MVC

Webフレームワーク

GAEOのMVC遷移

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

python

合成状態の状態遷移表

合成状態

composite state

JavaDSL

document、subgraph、gae、grailsなど

grailsとgaeoのcontroller

状態機械と文書

mavenではまる

状態機械

SimpleModeler 0.1.3b (20090301)

SimpleModeler 0.1.2リリース

ユーザーガイド作成中

ユーザーガイド

Annotated CSV

CSVからMindmapへの変換

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

scaffold

SimpleModeler 0.1.1

状態機械

業務ユースケースのextend

業務ユースケースフロー

業務ユースケース

TODO

実現したい機能

SimpleModeler 0.1