2004-03-24

しびれる．．．

Etc

日記を始めてから2週間．かつてNIFTYの会議室に入り浸っていた頃のように楽しみながらいろいろ書き込んできたのですが，ちょっとはしゃぎすぎたようです．前腕の内側全体がしびてれる感じなんですよね．特に左腕．どうやらキーボードを打ちすぎてしまったようです．職場ではKINESIS Ergo Elanを使っているのでまだいいとして，自宅で使っている普通の109キーボードを連日バリバリ叩きまくったのが原因に違いありません．
ということで，自宅にもKINESISが必要です．これから買うのならUSBタイプがいいのですが，今のところNon-USバージョンはないのですよね．USバージョンにしようかなぁ．その場合，職場と微妙にレイアウトが違うのはストレスになりそうなので，職場もUSバージョンにしたくなります．とはいえ，キーボードにしては高価なKINESIS，2つも購入するのは結構痛い．悩ましいです．
当面，自宅でキーを打つときはゆっくり入力するように気をつけよう．実は私，こう見えても(見えてないって！)タッチタイプの練習ソフトなんかだと200文字／分以上打てるんですよ．ローマ字入力だから打鍵数だと300／分くらい？でも，調子に乗りすぎると腕がしびれたり痛くなったり．．．腱鞘炎というやつなのかなぁ？そんなに深刻ではないので病院へ行ったりしたことはないのですが．将来，「体力の限界，キーボードも打てず，現役を引退することとなりました」なんてことにならなければいいのですが．
なーんて，そんなことをネタにしてまでキーボード叩いて日記を付けているのですから，心配するだけ無駄ですね．(^^;

2004-03-24

「MDA導入ガイド」4-7章

Book MDA

4. RosaのMDAアプリケーション
ここからは，「Rosa*1の朝食サービス」を題材として，MDAによる開発プロセスが解説されています．まず4章ではPIMを作成しています．
「Rosaの朝食サービス」は，WEBで注文された朝食を届けるというもので，クレジットカードで決済されます．しかし，そこはさすがに例題，決済の部分はPIMから完全に消え失せています．
結果，PIMはきわめてシンプルなものであるため，これなら分析モデルの成果物であっても無理はないと思います．でも現実的かはちょっと．．．
本章の「まとめ」には，「MDAの手法の威力を示すために，大規模なシステムを例に挙げました．」と書かれています．揚げ足を取りたいわけではありませんが，威力を示せる例題とは言い難いと感じました．
5. RosaのPIMからPSMへの3つの変換
本章では，4章で作成したPIMからPSMへの変換について説明しています．
「3つの変換」というのは，一つのPIMからリソース層(RDBMS)，エンタープライズ層(EJB)，プレゼンテーション層(JSP)に対応した3つのPSMへの変換です．元になるPIMは一つですから，それぞれのレイヤ間で矛盾が起こるはずはないというのが魅力的です．
とはいえ，例で示されているPSMはあまりにも単純かと思いました．
例えばリソース層(RDBMS)のPSMでは，全てのテーブルに○○Idという主キーが付け加えられています(元のPIMにはありません)．PIMに主キーとしてふさわしいと思われそうな項目があっても，無条件に○○Idです．それでいいの？文字列の長さは全て最大40文字にされています．それでいいの？
また，今回のPIM中のクラスは，全てのレイヤのPSMにクラスとして出現していますが，それが現実的とは考えにくいです．ドメインモデルのクラスの多くは，プレゼンテーション層では不要ではないかと思います．逆に，プレゼンテーション層にはドメインモデルにきわめて近いPIMには欠けている情報を相当補わなくてはならないと思うのですが，そのあたりの説明はほとんどありません．
ページ数からいっても，本書にそこまで詳細な解説を望んではいけないと思いますが，あまりにも単純な例だと疑念が強くなるだけではないか，という印象を持ってしまいました．
「6. RosaのPSMからコードへの変換」
前章で作成されたPSMからコードへの変換が解説されています．リソース層の例では，なんと文字列でCREATE TABLE文を組み立てるという，あまりに具体的な解説が出てきてちょっと笑ってしまいました．EJBへの変換ではそこまで低水準の解説ではなく，変換のためのいくつかのルールが紹介されています．
そういえばこの例題のモデル，操作は属性にアクセスしたり，関連をたどったりすることしかないのですね．動的な側面は省略されています．しょうがないですかね．
「7. 変換の詳細」
ここでは，PIM->PSM->コードという変換の際に考慮しなければならない事項を解説しています．
4ー6章を読んでいて感じる疑問のいくつかも取り上げられています．それは，PIMだけでは不足する情報をどのように補うか，ということです．「MDA モデル駆動アーキテクチャ(ISBN:4434038133)」でも取り上げられていたテーマですね(2004/03/17の日記を参照)．

入門書としての分かりやすさと，具体性・詳細さをどう両立するか，とても難しい問題ですね．本書は，かなり分かりやすさを優先しているようです．そのため，実際の開発をイメージしながら読もうとすると，疑問が残ることになりやすいように思いました．

*1:雑誌モデル界隈で話題の加藤ローサちゃんとは関係ありません，たぶん

2004-03-24

Spring Framework 入門記 Contextその1 ApplicationContext

Java Spring

今回は「3.9 Introduction to the ApplicationContext」です．長かったbeansパッケージをついに卒業して，ここからはcontextパッケージです．進歩するって気持ちいいですね〜．というわけで，improvement.jpなんていうマイドメインをメールアドレスに使っています．
さてcontextパッケージですが，これはbeansパッケージの上位に位置付けられて，BeanFactoryの機能をframework-styleなアプローチに与えてくれる．．．らしいです．英語むずいな*1．Springもframeworkだよね？って一瞬思いましたが，ここでいうフレームワークはプレゼンテーションフレームワークなどを意識しているようです．．．たぶん．それで，ContextLoaderというwebなパッケージに入っているクラスなどを使うと，これまで愛用してきたXmlBeanFactoryをプログラマチックに扱わなくてもいいとか．うーん，なんだかよく分かりません．
分からないときはソースを見れるのがオープンソースのいいところ．というわけでちょっとApplicationContextを見てみると，これはBeanFactoryをextendsしたインタフェースなんですね．なぁんだ，それなら怖くないぞ！
ではそのApplicationContext，BeanFactoryにどんな能力を付加してくれているのでしょうか？ドキュメントによると，

国際化対応のメッセージにアクセスできます．
URLやファイルなどのリソースにアクセスできます．
イベントを伝播してくれます．
複数のコンテキストをロードできます．

．．．悪くはないし，真っ当なアプリケーションでは必要なのでしょうが，ちょっと魅力に乏しい感じ．
まぁ，いいでしょう．一つずつやっていきましょう．
ApplicationContextはBeanFactoryでもあることが分かったので，まずはこれまで遊んできたサンプルをApplicationContext対応に変更してみることにします．
．．．むぅ．
このドキュメント，ApplicationContextを使ったコードがないなぁ．3章の中にはまったく出てこないぞ．自分で調べろってか？いいでしょう．そんなときはソースを見られるのがオープンソースのいいところ．おっ，FileSystemXmlApplicationContextなるクラスを発見！名前は物々しいけれど，要するにXMLの定義ファイルを読み込んでくれるらしい．
ということで，まずは実行用クラスの

            XmlBeanFactory factory = new XmlBeanFactory(new FileInputStream("beans.xml"));

を

            FileSystemXmlApplicationContext context = new FileSystemXmlApplicationContext("beans.xml");

に変更します．コンストラクタの引数は文字列なので，自分でInputStreamにしなくてもいいんですね．ちょっとだけラクチン？
そして変数factoryをcontextに置換します．
おやぁ？ BeanFactoryのカスタマイズのところで，postProcessBeanFactoryの呼び出しがエラーに？なるほど，postProcessBeanFactoryの引数は以前も書いたようにConfigurableListableBeanFactoryなのですが，ApplicationContextはListableBeanFactoryとHierarchicalBeanFactoryをextendsしているだけなんですね．じゃあカスタマイズはどうするんだろう？ようやくBigDecimalを使えるようになったのに，どうするんだろう？そんなときはソースを見れるのが(以下略)．
なるほどー，ApplicationContextは，初期化中に自分をカスタマイズしてくれるんですね．プログラマチックに扱わなくてもいいっていうのはそういうことかぁ．
ということで，カスタマイズ用(CustomEditorConfigurerやPropertyPlaceholderConfigurer)の定義も一緒にApplicationContextに与えてあげればいいようです．FileSystemXmlApplicationContextのコンストラクタには，文字列の配列を受け取るものもあるので，これを使ってBean定義のXMLとカスタマイズ用のXMLを一度に食べさせたあげましょう．

            FileSystemXmlApplicationContext context = 
                new FileSystemXmlApplicationContext(
                    new String[] {"factory.xml", "beans.xml"});

これでBeanFactoryカスタマイズ用のコードがなくなってすっきり．
おっと，BeanFactoryを後片付けするためのdestroySingletons()もエラーになってやがる．そんなときはソースを(以下略)．close()にすればいいようです．
ということで，全部まとめると次のようになりました．

package study;
import java.util.Iterator;
import java.util.Map;
import org.apache.commons.beanutils.BeanUtils;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class Main {
    public static void main(String args) {
        try {
            FileSystemXmlApplicationContext context =
                new FileSystemXmlApplicationContext(
                  new String { "factory.xml", "beans.xml" });

            String[] names = context.getBeanDefinitionNames();
            for (int i = 0; i < names.length; ++i) {
                Object bean = context.getBean(names[i]);
                System.out.println(names[i] + " : " + bean);
                Map props = BeanUtils.describe(bean);
                for (Iterator it = props.entrySet().iterator(); it.hasNext();) {
                    Map.Entry entry = (Map.Entry) it.next();
                    System.out.println("\t" + entry.getKey() + "=" + entry.getValue());
                }
            }

            context.close();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}

たいして変わってないんですけどね．そうかぁ，BeanFactoryのカスタマイズは自分でコードを書く必要がなかったのかぁ．それを先に教えてくれよー．でもまぁ，日記のネタとしてはこれでよかったかな．水面下で行われていることもちょっとは分かった気がしますから．
これでApplicationContextの付加機能を使う準備が出来ました．次回はその付加機能を使うべく，「3.10 Added functionality of the ApplicationContext」を学習します．

*1:コードより文章が多いと挫折しそうになります