Design by Contractは古くて新しい技術です。結構前から提唱されてる概念で、実践してみるとものすごく効果があるのになかなか世の中に広まっていかないのは、おそらく一つは厳密なContractを書くのがあまりにもめんどくさいということと、ツールが充実していないということがあると思います。
Eiffelの様に言語自体にDbCの機能が組み込まれている言語ならいざ知らず、JavaでDbCを実践しようとするのは大変です。JDK1.4からは一応assertキーワードが使えるようになってますが、単純に式がtrueかどうかをチェック出来るだけというのはあまりにもシンプルすぎる気がします。
JavaでDbCを実践できるツールとしてはJML
を試そうとした事がありますが、日本語がうまいこと通らない等の問題があって挫折しました。(2004/3月時点)
以前、 JavaDocに自然言語ベースでContractをがりがりと書いてDbC的なことをやったこともがあるのですが、その時はJUnitのテストケースのコーディング量が本体の3倍くらいになって、あやうく開発メンバーを殺すところでした。アサーションのコードをいちいち書くのがめちゃくちゃめんどくさいのです。やはりツールのサポートは不可欠のようです。

いろいろ考えた結果、最近ではAspectJを使ってAspectとしてContractを記述するのが良いのではと考えるようになっています。
JMLと比べて、AspectJが良いとおもった理由はいくつかあります。

1.柔軟性 - おそらくどのようなチェックでもかけられる。またContractと本体のコードは完全に切りはなせるし、必要に応じてアサーションをいれたり外したりも自由。
2.メジャー度 - JMLなどに比べて使ってる人が多くて安心。
3.開発環境-Eclipse AJDT等が使えて便利
4.明解さ:アスペクトとして定義されたContractがどのようにWeavingされるかが、明解に定義されている。Weavingのされ具合を視覚化するツールも充実している。JMLではどのようにアサーションコードを入れ込んでいるのか、謎。

とりあえず簡単なサンプルを作って動かすところまではできてるで、次回こそはそれを紹介したいと思います。

そもそもAspectJでDesign by ContractをやるためにMaven AspectJ Pluginを使おうとしたのですが、これがなかなか動いてくれなくて。。。結局はしょうもないことではまっていたのですが。というわけで、MavenでAspectJを使うためのメモです。
なお、Mavenのバージョンは1.0rc3を前提とします。

1. Maven AspectJ Pluginをバージョンアップする。
以下のコマンドを実行します。
maven plugin:download -DgroupId=maven -DartifactId=maven-aspectj-plugin -Dversion=3.1

なにしろドキュメントも全部バージョン3.1ベースですし、これをやらないと始まりません。

2. project.xmlの編集
dependencyにaspectjrt-1.2.jarを追加し、build要素の子要素としてaspectSourceDirectoryを追加します。
こんな感じになります。

3.maven.xmlの作成。
今回はテストケースに対してWeavingを行いたかったのですが、そのような場合はtest:compileのpreGoalとしてaspectj:test-compileを設定します。
本体のソースコードにWeavingをかけたい時はjava:compileのpreGoalとしてaspectj:compileを設定します。こんな感じになります。

これで、あとはチェック対象クラスのメソッド呼び出しの前後に事前条件/事後条件/不変表明のチェックを行うアスペクトを書いて、

maven test

を実行すると、JUnitのテストケースにWeavingされてうまいことチェックがかかります。本体でなくテストケースにWeavingするところがミソです。この方がテスト対象をいじくり倒すよりも安心ですし、特別なことをしなくてもmavenのjar goalで作成されるjarには当然チェック抜きのコードがはいりますから。
ただ、複雑な場合でもテスト対象をいじらないで済むかどうかは非常に疑問です。。。

明日は、実際にDbCをAspectJで実現したサンプルコードを紹介したいと思います。

Mavenは大変素晴らしいツールだと思います。勝手に依存ライブラリをダウンロードしてくれるのはやっぱり便利ですし、Mavenを使ってビルドしている限りはハードディスクがjarまみれになって、xerces.jarが5個ぐらいあるという事態からは逃れられます。antよりCheckStyleやJ Coverageなど外部のいろいろなツールを使うのも楽です。antだと、jarをダウンロードして、クラスパス設定して、taskdefして、ドキュメントを見ながらtaskを書いて、といった作業が必要ですが、mavenだとそういうantビルドスクリプトを簡単に再利用できます。
ですが、人間の欲というものには際限がないもので、最近mavenにいろいろと不満を感じるようになってきました。どんな不満かはおいておいて、maven2/mavenNGと呼ばれる(っぽい)次期mavenがどうなっているのかとても気になっています。ですが、Web上ではまだ情報はすくなく、ソースコードも見付かりません。もしかしたらまだ全然構想段階なのかもしれません。以下に、このサイトとこのサイトにのっていたmaven2情報を断片的ですが書いておきます。

・dependencyのdependencyを自動的に解決してくれる
・DIコンテナにPlexusを使った、コンポーネント指向のモデルになる
・だから、コマンドラインだけでなくIDE統合も用意になる。
・Pluginは基本的にPOJO、Jellyもサポート?
・Pluginは設定オプションに関する十分なメタデータを提供する。これもIDE統合を容易にする。
・クライアント/サーバモデルになる?
・POMの一部がURI指定で読み込めるようになる。

実現すれば非常に素晴らしいものになりそうですが。。
有力な情報があったら是非おしえて欲しいです。

このBlogで調べて来たいくつかのソフトウェアの新しいバージョンがリリースされていました。

WebWork2.1
UIタグ関連にこまごまとした改善が施されているようです。
Viewまわりはあまり調べきれてないので、良く分からないですが。。
これを機に調べてみたいですね。
特にインパクトが大きいそうなのはStrutsのような入力チェックJavaScriptコードの生成がサポートされたことでしょうか。

XWork1.0.1
ObjectFactoryというクラスが導入され、SpringやPicoとの連携がより簡単になったそうです。また、ErrorMessageだけでなく、StrutsのようにActionMessageが使えるようになったみたいです。Ognlまわりのパフォーマンスも改善されたということです。
WebWork2.1はこの新しいXWorkに依存しています。
WebWorkもそうなのですが、全体的にドキュメントが充実してきた感じです。

SnipSnap0.5.2a
日本語Snip名が...通るっ...!!!素晴らしいです。
あとインデックスのソートがおかしかったバグが直ってました。
あいかわらず一度つくったSnipの消しかたはわかりません。。。

WEBrickを使って動的なページを生成するには、AbstractServletや手続きオブジェクトをHTTPServerに登録する他に、erbを使う方法があります。erbというのはJavaでいうところのJSPの様なもので、テキスト文書の中に <%～%>で括ってRubyスクリプトを埋め込みます。JSPと同じように<%=～%>で括られた式が返す文字列は文書に埋め込まれます。HTTPServerはデフォルトで拡張子rhtmlのファイルをerbスクリプトとして扱うようになっています。

例えば、ドキュメントルートにhello.rhtmlという名前で以下の内容のファイルが置いてあるとします。

Hello, <%= query["name"] %> 

HTTPServerがポート2000で起動しているとき、ブラウザで
http://localhost:2000/hello.rhtml?name=Nose
を開くと、
パラメータの部分がテキストに埋め込まれて、
Hello, Nose
ときちんと表示されるはずです。他にもWEBrickから呼ばれるerbスクリプトの中では、servlet_request, servlet_responseという変数名でそれぞれHTTPRequest, HTTPResponseオブジェクトが使用できます。WEBrickのソースコードは短いので、APIの詳細を調べるにはソースを追ってしまった方が早いと思います。
機能的にはいたってシンプルで、JavaServletのようにリクエストのディスパッチや、セッションのような仕掛けはどうも見当たりませんでした。この辺をサポートするフレームワーク的なものがあるといいなぁと思っていたら、
DIVなどというものがあることが発覚。dRubyとerbを使ったちょっとしたWebアプリケーションフレームワークだということです。作者はerbを作った人らしいです。そういえばこのDIVというフレームワーク、昔なにかの雑誌の記事で見掛けたような気がする。。。

ずっとJavaの話ばかり書いてますが、僕は実はRubyも大好きです。
Windows上でシェルスクリプトがわりに良く使うのですが、
Rubyでプログラムを書くたびに、その出来の良さに感激しています。作者のまつもとさんは凄い人です。
他の言語のようなプログラミング特有の辛さがなく、自然な思考の流れを妨げられずに楽しくプログラミングができるのです。

いつも、Rubyをもっといろいろな分野で使えないかと思案していて、例えばRubyでServletみたいなことができたら、Webアプリケーションのプロトタイプ開発などに威力を発揮するのじゃないかと思っていました。

で、そんなライブラリを探してみたら、ruby1.8からWebrickというrubyでServletのようなことを実現できるライブラリが標準の添付ライブラリになっていることに気が付きました。Webサイトにのっていたサンプルを見る限りはでは、JavaServletに似たインターフェースで簡単に使えそうです。
Javaと違って、web.xmlのようなややこしい設定ファイルが無いのは手軽でいいと思います。あと、クロージャをServletのように使えるのは結構熱いですね。
eRubyとかと組み合わせるとJavaServlet+JSPのようなことも簡単にできそうです。
おもしろそうなので、これに関してはもう少し突っ込んで調べてみたいと思います。
なお、僕が普段家で使っているDebian sarge でaptを使ってRubyをインストールした場合、webrickはruby本体とは別のパッケージで配布されてるみたいなので、注意が必要です。

apt-get install libwebrick-ruby

でインストールできます。

BeanShell2.0では、スクリプト内でクラスが定義出来るようになったついでに、クラスパス上の.javaファイルを必要に応じて勝手に読み込んでクラスを生成するという荒技が可能になりました。
使いどころがいまいち思い付かないのですが、とにかく凄い。

こちらは、もっとすぐ使えて便利そうなのが、オブジェクトインスタンスのインポート機能。たとえば以下のようなコードが可能になります。

hello() {
    importObject(new HashMap());
    void sayHello() {
        print("hello, world ");
    }
    return this;
}
h = hello();
h.put("key", value");

importObjectの引数で渡されたオブジェクトのインスタンスメソッドは実行時のスコープにインポートされます。ここではHashMapのメソッドがhello()というScriptingObjectにMix-Inされているのが分かります。
これは素のJavaクラスとBeanShellスクリプトとの連携に新たな可能性を開く、非常に面白い機能だと思います。

あと、細かいですが、JDK1.5のstatic importが使えるようになりました。

static import java.lang.Math.*;
 sqrt(4.0);

このコードがJDK1.4でも1.3でも動く、というところがミソです。

最近、Groovyを試したりしてたのですが、いろいろあってまたすっかりBeanShell派に戻ってしまいました。機能の豊富さ、易しさ、柔軟性は他のJavaで実装されたスクリプト言語に比べても抜群にいいと思います。アイディア次第でいろいろな用途に使える、非常にパワフルなツールです。
今日は、そんなBeanShellの最新版、2.0b1の新機能について調べてみました。
目玉はスクリプトの中でクラスを定義できる様になったことです。
しかも、クラス定義には普通のJavaのコードだけでなくBeanShellのルーズな文法も使えます。さらに、クラスのメソッドの中で使用されるコマンドや変数は、実行時のコンテキストで評価されます。
例えば、以下のようなスクリプトが可能です。

class HelloWorld {
    void sayHello() {
        print("hello " + name);
    }

    void doCommand() {
        sampleCommand();
    }
}

sayHelloメソッドの中の変数nameや、doCommandメソッドの中のコマンドsampleCommandがクラス定義の中に含まれていないことに注意してください。このスクリプトを"classTest.bsh"という名前で保存したとして、bshプロンプト上から以下のようなコマンドを実行することができます。

bsh % source("classTest.bsh");
bsh % hw = new HelloWorld();
bsh % hw.sayHello();
hello void
bsh % name = "nose";
bsh % hw.sayHello();
hello nose

変数nameを後付けできていますね。
同様に、つづけて以下のコードも可能です。

bsh % sampleCommand(){print("execute!");}
bsh % hw.doCommand();
execute!

普通のBeanShellスクリプトは構文木をあらわすJavaオブジェクトとして表現されているのですが、この場合だけは動的にクラスを生成しているようです。バイトコードの生成にはASMが使われていたりします。普通のJavaクラスなので、同じ名前のクラスを2回定義しようとすると怒られます。そういうことがやりたい時はおとなしくScriptingObjectを使え、ということなのでしょう。
いろいろきわどいことも試してみたのですが、GroovyのようにImcompatibleClassChangeErrorとかは発生しませんでした。
大体のコードは想定通り動きそうです。
良く考えてみると、クラス以外のBeanShellスクリプトはJavaオブジェクトの世界で表現されているので、普通のやり方ではバイトコードの世界にはたどり着けそうにないから、当然と言えば当然です。

多分Groovyの気難しさは全てのスクリプトを一旦バイトコードに変換しているところから来ているような気がしてるんですね。バイトコードはどうしても動的な性質が制限されますから。
Rubyのような動的な言語を期待していた僕としては、その辺がいまいちしっくり来なかったというのも、BeanShell派にもどった理由の一つですね。まぁ、Groovyに関しては今後の発展に期待というところでしょうか。

以前書いた、ASMの続編です。

ASMがなぜBCELとかより速いのか、という説明はASMのドキュメントに書いてありました。その内容を僕なりに理解した所を述べたいと思います。

ASMとBCELが、クラスファイルを読み込んでバイトコードを変換する方式の違いは、平たくいうとXMLにおけるDOMとSAXの違いと似たようなものだと思います。
ASMはSAXで、BCELはDOMです。DOMがXMLファイルを読み込んで、XML文書を表現するオブジェクトモデルを構築するのと同様に、BCELはクラスファイルを表現するオブジェクトモデルを構築します。SAXがXMLファイルを読み込みながらContentHandlerにstartElementとか、charactersとかのイベントを通知するように、ASMではClassReaderというクラスがクラスファイルを読み込み、ClassVisiterというインターフェースを実装したクラスに「メソッド宣言のはじまりだよ(visitMethod)」とか「内部クラスのはじまりだよ(visitInnerClass)」といったイベント?を通知します。
だから、ASMが速い理由は、SAXがDOMより速いのと同じ風に説明できると思います。
ところで、SAXがあるからといってDOMがいらないというわけではないのと同様に、ASMの方式は万能ではありません。
複雑な変換の操作が難しいのです。そういった時にはやはりクラスファイルのオブジェクトモデルを構築した方が便利です。
ASMのディストリビューションには、そんな時のために、asm-tree.jarという名前で、ちゃっかり「クラスファイルのオブジェクトモデルを構築するClassVisiterの実装」が含まれていたりします。
また、ASMのコアにはClassVisiterのデフォルトの実装として、ClassAdapterというのが用意されています。これはChain Of Responsibilityっぽく、ClassVisiterを鎖状に連結する機能をデフォルトで持った、便利クラスです。ClassReaderでクラスファイルを読み込んで来て、複数のClassAdapterで変換処理を行い、最後にClassWriterで変換後のバイト配列を取得するという流れが基本パターンのようです。
まるで、 CocoonのXML Pipelineみたいだなとおもいました。

書名：チェンジ・ザ・ルール! なぜ、出せるはずの利益が出ないのか
著者：エリヤフ・ゴールドラット
訳：三木本 亮
ダイヤモンド社 ISBN4-478-42044-0 1,600円

「ザ・ゴール」「ザ・ゴール2」の続編です。内容は引続きTOC(Theory of Constraints)に関するものですが、今回は焦点をコンピュータシステムにあてています。ERPを開発しているあるソフトウェア開発企業が、他社の追随を許さない絶対的な競争優位を築くまでを描いたお話しです。
話の結論としては、単にコンピュータシステムを導入するだけでは、企業にとって大した利益にはならず、コンピューターのパワーが何を可能にするのかを認識して業務のルール自体を変えなければならない、ということです。

単に顧客のリクエストにて答えているだけでは顧客もソフト開発企業も幸せにならない。顧客のリクエストというのは大抵既存のルールにシステムを対応させようとするもので、かつその既存のルールはコンピュータ導入以前の物理的な限界に縛られたものである。そのようなルールに対応しても徒にシステムが複雑化するだけで、コンピュータのパワーをフルに活かすことは出来ない。単に顧客のリクエストに答えるだけでなく、業務コンサルのような部分まで踏み込まないと、本当にWin-Winの関係にはなれない。

という主旨のことが小説仕立てで描かれています。特に、ここでいう「既存のルール」というのは、主にTOC以前の部分最適化の努力のことを指しており、コンピュータ導入によって、従来の限界を越えてTOCを加速させることが出来るということがいいたいのだと思います。

小説としてはちょっと話がうまく行きすぎで、正直どうかと思うのですが、上述の話の主旨には考えさせられるものがあります。
TOC云々の話とは離れてしまうのですが、既存のルールに縛られるとコンピュータのパワーを活かしきれないというのは共感できます。僕も、もしかしてコンピュータより人間の方が頭が硬いのではと思うことがよくあります。コンピュータは人間とちがって、今までの習慣とかに縛られることがありません。だから、テクノロジーの進化に応じて黙々と仕事をこなすことができます。それに対して人間は一度身に付いた習慣をなかなか変えたがらないものです。

テクノロジーの進化の方が人間の習慣の変化より速い例を自分の身に引き付けて考えると、例えば、
ソースコードと同じ詳細レベルのプログラム設計書を意地になって書きたがることなどがあげられます。

現在のテクノロジーの状況を考えれば、ソースコードと同じ詳細レベルの設計書を書く必要性は全くありません。

第一に、同じ情報を２回書くのは基本的に無駄です。
第二に、設計書のほうがソースコードより見やすいということは決してありません。紙の設計書よりIDEの助けを借りてソースを追う方がずっと楽です。
第三に、設計書はテストできません。テストしないで動作するソースコードなどありえないのに、どうして設計書を正しく書けるとおもうのでしょうか?それに対して今はマシンが速いので、ソースコードはすぐにテストすることができます。
第四に、ソースコードの変更と設計書の同期を手動でとるのは、ほとんど不可能です。できたとしても、多大なるコストがかかります。

冷静に考えてみればわかることなのに、それでも気違いじみたプログラム設計書を書かせたがるのは、プログラマーの時間よりCPUの時間の方が高価だったころの習慣からぬけだせないからだと思います。そりゃテストするのにマシンを予約しなければならないような環境では机上デバッグも大事だろうさ。ホントにソースコード全部特大フォントで印刷してプログラム設計書とかゆって渡してやろうかと思うことがあります。

単に習慣の問題に加え、前例の無いことをやって自分が責任をとりたくないとかいう、もうなんといっていいか、バカか、というような悪い意味で極めて日本的な思考回路が状況を悪化させています。こんなことが日本を代表するSIerと呼ばれる企業でも結構まかり通ってしまっているところに日本のソフトウェア産業の限界を見て、いつも暗い気分になってしまうのであります。だからITゼネコンとかいわれるんだよ、全く。

そういう意味で、この本を読ませたい人はたくさんいますね。