専門家に聞くモデル駆動開発のメカニズム：The Rational Edge（1/2 ページ）

WebSphereコンサルタントがモデル駆動開発（MDD）や、実行イメージパターン、Java Emitter Templates（JET）、そしてDesign Pattern Toolkit（DPTK）のオーサリングおよびその使用によるアプリケーションのソース生成に関する質問に答える。

[Chris Gerken，＠IT]

The Rational Edgeより：WebSphereコンサルタントのChris Gerken氏がモデル駆動開発（MDD）や、実行イメージパターン、Java Emitter Templates（JET）、そしてDesign Pattern Toolkit（DPTK）のオーサリングおよびその使用によるアプリケーションのソース生成に関する質問に答える。

　MDD変換は、現在は実行イメージパターンとして利用されている。これらは、慣例、最優良事例、およびガイドラインの整合的な適用を自動化する。 EclipseやRSA（Rational Software Architect）の重要な新機能により、これらのパターンのオーサリングによるアプリケーションのソース（Java、COBOL、JSP、XML、プロパティファイルなど）生成が簡単になった。

質問　UMLのアクティビティモデルがあった場合、モデル間変換（UML2からDSL Ecore）を実行し、モデルの中の情報を使い、Java Emitter Templates（JET）でコードを生成しながらも、これをシームレスかつプログラム的に行うプラグインはどうすれば作成できるのか。

回答　一般には、MITM（meet-in-the-middle）アプローチを使いたい。まずはJET変換を作成する（まだRational Software Architect V6.xを使っている場合は、alphaWorks のDesign Pattern Toolkitを使用）。このインプットモデルは、テンプレート内のモデルアクセスがかなりシンプルになるよう最適化されている。

　 M2T（モデルからテキスト）変換を書き上げたら、UMLモデルのナビゲーションと、JET変換が要求するインプットモデルのような内部モデルの構築を行うRational Software Architect（RSA）変換が書ける。RSA変換の最後は、構築した内部モデルをJET変換が簡単に活用できるフォーマット（XML文字列もしくは EMFインメモリモデル）に変換し、プログラムでJET（もしくはDPTK）を呼び出す作業になる。

質問　「エグザンプラー（exemplar）」とは何か。また、M2T変換を構築する際どのように役立つのか。

回答　エグザンプラーは、M2T変換で生成するものの代表例。RSAのエグザンプラーオーサリングツールが利用し、インプットモデルスキーマとM2Tテンプレートを素早く抽出するために使用される。エグザンプラーのオーサリング中は、該当するすべての最優良事例、ガイドライン、慣例などに合わせてエグザンプラーが書かれているものと仮定される。これは、変換がサポートするすべての可変点を示す。最初は感じないかもしれないが、エグザンプラーを構築して認証し、これを変換オーサリングプロセスの入力に使うと相当な時間の節約になる。

質問　M2T変換を書くときに、JETではなくDPTKを使うのはどのような場合か。

回答　Eclipse 3.2、Rational Application Developer（RAD）V7、あるいはRational Software Architect V7上で変換を行うつもりであればJETを使う。これ以前のバージョンのRSA、RAD、あるいはEclipseであればDPTKを使う。

質問　JET変換のインプットモデルとして配備記述子（web.xml）を使いたいが、この配備記述子に分類できない新しいデータも幾つか必要だ。この場合はどうすればよいのか。

回答　2番目のXMLファイルに追加情報を入れることができる。変換では、2つのうちの1つのファイルを主入力とし、コンテンツタグを使って2番目のファイルのリード、パーシング、メモリへの読み込みを行う。2つのファイルからの両モデルの読み込みが終了すれば、ファイル生成に必要なテンプレート処理が何でも可能になる。

質問　パターンはM2T変換とどのような関係があるのか？

回答　グラディ・ブーチ氏はかつて、パターンとは所定の状況において繰り返し発生する問題に対するソリューションである、と定義した。この定義は、最優良事例、ガイドライン、命名慣例がいずれもパターンであることを示唆している。M2T変換は最優良事例、ガイドライン、そして命名慣例の適用を自動化できるため、M2T 変換（およびモデル間変換）はパターンの適用も自動化できる。わたしは、「変換」と「パターン」の両方の用語を併用することが多くなっている。

質問　唯一苦労するのがエグザンプラーとパターンの適用範囲だ。M2T変換を活用できるよう十分広い範囲を確保したいが、最初の変換で閉口するほどの広範囲を望まない場合はどうするか。

回答　エグザンプラーの範囲を決定するには幾つか方法がある。

　最初は、「パターンとは所定の状況において繰り返し発生する問題に対するソリューションである」という点だ。ソリューションは最優良事例、慣例、ガイドライン、設計書などの形態になる。オブジェクト（「doc」や「j-unit」テストファイルなど）を存続させる方法など、特定の問題を解決できる一連のファイルを探していただきたい。もちろん、この問題は、アプリケーションスイート全体で解決されるケースが多ければ多いほどよい。

　わたしは、それぞれのファイルの生成に必要なモデルデータの2つの集合が重複することを2つのファイルが「MDD関係にある」（わたし独自の用語）といっている。例としては、別のファイルのために、あるファイルのクラスもしくはファイルの名前がソース中で呼ばれる場合や、同じプロパティ名（もしくは「getter」や「setter」の名前といったその変種）がこれら2つのファイルのソース中にある場合がある。また、MDD関係は強い（インタフェースおよびインプリメントクラス）もしくは弱い（Javaプロジェクトのjar名や参照するadminスクリプト）と呼び分けることができる。強いMDD 関連ファイル（数学の閉包を思い出していただきたい）のグループを探したい。

　これらのアプローチは、いずれも最終的には同じファイルグループを特定する。入門に適したエグザンプラーとしては、約20のファイルで構成されるようなファイルグループを探すといいだろう。わたしが見たところ、1つのパターン中およそ80％のテンプレートは平凡なもので、15％は分かりやすくて完成もさせやすく5％はやや扱いづらい。

　もしパターンのオーサリングに関する経験がもっと豊かならば、ファイルを見て、幾つか質問しただけで、テンプレートの数や複雑性、そしてモデルのサイズや形もだいたい分かるようになる。わたしなら、そのテーマの専門家や、パターンのテーマの専門家がほかのテーマの専門領域に不慣れであるなど、まだ目に見えない複雑性のリスク要因も計算に入れるだろう。

　大胆に簡略化するため、わたしなら最初の 変換用に5〜10種類のテンプレートを作成する。これより多いとなかなかすぐには満足感を得られないし、これより少ないとM2T変換の力を実感できなくなる。