MDAをツールで体験する （後編）
静的構造からのコード生成が特徴

有限会社メタボリックス
山田正樹

2003/12/13

---

　「OptimalJ」は日本コンピュウェアが販売しているオランダ製MDAツールである。UMLの標準化作業に積極的に携わっているKlasse Objectenのメンバーも開発に参加しているという。コンピュウェアのUSのサイトから30日間利用可能な評価版をダウンロードすることができる。

　前回（「MDAをツールで体験する 前編」）紹介した「iUMLite」が振る舞い（ステートチャート図）からのコード生成を中心にしているのに対して、OptimalJでは静的構造（クラス図）からのコード生成を中心にしており、同じMDAツールといっても使い方はまったく異なる点に注目してほしい。

　今回利用したのは「OptimalJ Architecture Edition 2.2」。日本語のドキュメント（チュートリアル、ユーザーズ・ガイドなど1000ページを超えるPDF）は付いているが、日本語化は行われていない。ベースになっているのは「NetBeans」（Sunでは「Sun ONE Studio」として商品化されている）なので、日本語が使える部分もあるがUMLモデル図中の日本語は文字化けして表示されない。フォントを変える方法は分からなかった。もっともモデル要素に付けられた名前はそのままコードに反映されるので、ノートなどを除けばあまり日本語を使う意味はない。

---

◆OptimalJを利用した開発プロセス

　OptimalJを利用した開発プロセスはおおむねこんな感じだ。

1. ドメイン・モデリングを行う（クラス図）
2. ドメイン・モデルからアプリケーション・モデルを生成する（クラス図）
3. アプリケーション・モデルからコード・モデルを生成する（クラス図）
4. 生成されたシステムを配備してテストする

　「ドメイン・モデリング」とは、問題領域にあるオブジェクトを抽出し、モデル化することを指す。MDAの用語でいえばPIM（Platform Independent Model＝プラットフォーム非依存モデル）である。すなわち、モデルをどう動かすかという視点はこのモデルには含まれず、開発対象となるシステムごとに作られる。大まかにいえばこのプロセスは分析のプロセスに当たる。
　
　「アプリケーション・モデル」とは、解決領域のモデルのことだ。ドメイン・モデルを「どういうプラットフォーム」の上で「どうやって動かすか」ということを指定するのである。MDAの用語でいえばPSM（Platform Specific Model＝プラットフォーム固有モデル）に当たる。要するに、このプロセスは設計のプロセスなのである。OptimalJではDBMS、EJB、Webの3つのアプリケーション・ドメインをサポートしている。図1のような3層アプリケーションをドメイン・モデルから生成できるわけだ。

図1 3層アプリケーションをドメイン・モデル

　「コード・モデル」というのは、アプリケーション・モデルから実際に生成されたコードを指す。Javaコード、JSPコード、SQL文などが含まれる。このプロセスは実装プロセスに該当する。生成されたコードをコンパイルして配備すれば、実際にドメイン・モデルを操作するWebアプリケーションを起動することができる。

◆実際にモデルを書いてみる

　まずは簡単なドメイン・モデルを書いてみる。ここでは通常のUMLツールでクラス図を描くのとほぼ同様だ。型名などはJavaのライブラリを意識することなく、ポップアップするものから選べばよい。また関連にはちゃんと名前を付けたり、多重度を指定する必要がある。モデルはXMIファイルで保存されているようだ。今回は非常に単純なモデルだが一応、「Modelメニュー」→「Check Mode」→「Check Class Model」を選択し、OptimalJが受け入れ可能なモデルかどうかをあらかじめチェックした。MDAでは、いままでは許されていたあいまいなモデリングが許されない場合があるからだ。

　OptimalJではドメイン・モデルの一部をドメイン・パターンとして登録しておくことができる。ドメイン・モデルの中でもよく使われるパターン、例えば顧客情報に関連するクラス群などをドメイン・パターンとして登録しておけば、多くのドメイン・モデルで再利用できるだろう。ドメイン・パターンが単なる登録ライブラリと違うのは、パターンを展開するとき、すでにモデリングされているクラスとパターンをマッチングできる点だ。

OptimalJではドメイン・モデルの一部をドメイン・パターンとして登録しておくことができる（クリックすると拡大）

　次に、このドメイン・モデルに対して、「Modelメニュー」→「Generate Model」→「Generate DBMS from Domain…」を選択してDBMSアプリケーション・モデルを生成する。この程度のモデルならばほんの数秒しかかからない。DBMSアプリケーション・モデルは、ドメイン・モデルをデータベースのエンティティ／リレーション関係やSQLのデータ型などに合わせて変換したものになっている。

DBMSアプリケーション・モデルを生成する（クリックすると拡大）

　同じようにこのドメイン・モデルからEJBアプリケーション・モデルとWebアプリケーション・モデルを生成する。

EJBアプリケーション・モデルを生成する（クリックすると拡大）

Webアプリケーション・モデルを生成するる（クリックすると拡大）

◆コード・モデルを生成する

　以上、このプラットフォームに関するアプリケーション・モデル（PSM）がそろったので、ここからコード・モデルを生成しよう。コード・モデルの生成は「Modelメニュー」→「Generate All Code」を選択するだけだ。

　ところで、プラットフォーム（Java、EJB、RDBMSなど）に関するコードをいっさい記述していないことに注意してほしい。Webアプリケーション開発ではさまざまな局面で、フレームワークによって強制される数多くの呪文的コードを書かなければならないが、それはすべてツールに任せてしまえるということになる。ここまでの時点ではビジネス・ロジックも記述していない。しかし、ドメイン・モデルに定義したデータを操作（生成、変更、検索、削除）するためのコードはツールが生成してくれている。

　生成したコードの種類はスキーマ定義用のSQL文、EJBで使われるEnterprise Beanのインターフェイスとクラス、サーバへの配備情報ファイル、JSPファイル、Java（Struts）コードなどである。
　
　次に生成したコードをコンパイルする。これも簡単で「Buildメニュー」→「Compile All」を選択するだけだ。ここまでくれば、ドメイン・モデルをWebアプリケーションとして動かしてみることができる。

　そのためにはまず、RDBMSを起動してこのドメイン・モデルに対応するスキーマを定義しなければならない。OptimalJでは使用するRDBMSをあらかじめ設定しておけば、SQL Workbenchというツールからスキーマ定義などが簡単に行えるようになっている。OptimalJにはSolidというRDBMSが同梱されていて、テストにはこれを使うことができる。

　次にEJBサーバの設定を行う。これも「Testメニュー」→「Start EJB Server」を選択するだけだ。OptimalJでは同梱されているJBossを使うようになっている。最後にWebブラウザを立ち上げて指定したページにアクセスすればよい。これもツールの中から実行できる。OptimalJではServletコンテナとして同梱されているTomcatを使うようになっている。

OptimalJにはSolidというRDBMSが同梱されていて、テストにはこれを使うことができる（クリックすると拡大）

OptimalJではServletコンテナとして同梱されているTomcatを使うようになっている（クリックすると拡大）

◆UMLツールとはどこが違うのか？

　ここまで行ってきたOptimalJによる開発のプロセスを振り返り、簡単にまとめてみると図2のようになる。

図2 OptimalJによる開発のプロセス

　ドメイン・モデルが変化した場合にも、このプロセスを繰り返すだけだ。ドメイン・モデルを変更してからそのモデルをWebアプリケーションとしてテストするまでのターン・アラウンド時間は規模や複雑さにもよるが、おそらく、数分から数十分だろう。もちろん、通常はこれだけで製品とすることはできない。製品の見栄え（ビュー）はWebアプリケーション・モデルから生成されたコード・モデルを変更したり追加したりすることによって洗練させていくことができる。もう1つのポイントはビジネス・ルールの追加である。

　ビジネス・ルールとはビジネス（ドメイン）上の制約やルールを表現するものである。例えば「異なる顧客が同じ電子メールアドレスを持つことはない」というのは構造に関する制約を表したビジネス・ルールだ。一方、「ゴールド会員には1万円以上の購入に対して3％の割引がある」というのは動作に関するルールを表したビジネス・ルールだ。実際に製品を作る場合にはモデルにこれらの情報を付加していく必要がある。

　OptimalJではモデルのさまざまな場所にビジネス・ルールを追加できる。

　例えば、ドメイン・モデルの各属性には、

• 固有制約（インスタンスの一意性を示すキー）
  
• 範囲制約（値の取り得る範囲）
  
• 正規表現（値の取り得るパターン）
  
• 任意のJavaブール式
  
• 初期値の指定

などを付けることができる。

　ドメイン・モデルの各操作にはJavaの本体コードを定義することができる。この操作は最終的にはWebブラウザからユーザーによってハイパーリンクを通して呼び出される。共有されるビジネス・ルールは個々のクラスではなくドメイン自体に付けておくこともできる。iUMLiteではこれらはアクション言語によって記述されていたが、OptimalJではJava（SQLなどが使える場所もあるが）というプラットフォーム言語を直接利用していることに注意してほしい。

　これだけではなく、生成されたコード・モデルを直接変更したり、外部で定義されたJava
クラスをインポートすることによってアプリケーションの微調整を行ったり、機能を追加していく場合もある。生成されたコード・モデルには「フリー・ブロック」と呼ばれる部分が明確に切り出されている（OptimalJのエディタ上では背景の色が変わっていて編集可能になっている）。フリー・ブロック部分はドメイン・モデルを変更して、アプリケーション・モデルやコード・モデルを再生成させても保護されることになっている。

　こうやってみてくると当然、MDAツールと従来のラウンドトリップ・エンジニアリング可能なUMLツールとはどこが違うのか、という疑問が湧いてくる。実際、OptimalJをツールのユーザーの目からみると、よくできたラウンドトリップ・エンジニアリング・ツールのようだ。しかし、もう少し高い視点からみてみると、従来のラウンドトリップ・エンジニアリング・ツールのアーキテクチャがアド・ホックであったのに対して、MDAツールのアーキテクチャはきれいにできている、ということがいえるだろう。ツール・ユーザーからみればそのことはツールの分かりやすさとしてとらえられる。

　OptimalJではモデリングとモデル変換のプロセスが「パターンの適用」として図3のようにまとめられている。

図3 パターンの適用

　このうちツールのユーザーが定義できるのは前述したドメイン・パターンとこれから述べる実装パターンだけだが、その基礎にあるのはMDA、さらにMDAを可能にしているMOF（Meta Object Facility）だ。MOFとはメタ・モデリングのための言語である。UMLがモデリングのための言語であるのに対して、MOFはモデリングのための言語をモデリングするのに使われるというわけだ。実際、OptimalJのExplorerの「Meta Model」タブを開いてみれば、メタ・モデルの一部を垣間見ることができる。これらは実装パターンをユーザーが定義するためにみえるようになっているのだ。

　実装パターンはアプリケーション・モデルからコード・モデル、つまり実装コードを生成するために使われる。変換先はJavaに限らず、SQL、HTMLなど任意のテキストである。ツール・ユーザーが実装パターンを書く場合にはTPL（Template Pattern Language）を使う。TPLはアスペクト指向のマクロ・プロセッサとでもいえばいいだろうか。MDAツールでは最終的にどこかの段階でマクロ・プロセッサが使われることになるが、その中でもTPLは興味深い言語だ。TPLで書かれた実装パターンはJavaコードに変換される。

◆MDAの進化とともに

　OptimalJはユーザーの立場からみれば、従来のラウンドトリップ・エンジニアリングをサポートしたUMLツールに近い。しかし、MDAというアーキテクチャを採用していることによって、モデル変換へのアクセス性が高まっている。今後もMDAの進化に伴ってOptimalJも進化していくことだろう。もっとも、実装パターンを本格的にやるためにはツール・ユーザーにとってもUMLメタ・モデルの知識が必要になってくる。

　また、Webアプリケーションというプラットフォームを固定して考えれば、非常に効率のよい開発を可能にしてくれるツールと考えることもできる。実際、従来必要だった大量のコーディングはツールが肩代わりしてくれる。その代わりにわれわれは今度は「正しい」モデリングをし、モデルの変換結果をチューニングできる能力を身に付けることが必要になってくるのである。

IT Architect 連載記事一覧