図1●MDAはプラットフォームの変更に強い
プラットフォームに依存しない形でシステムを作れる。プラットフォームに依存する部分はツールが自動的に作成してくれる。
図2●MDAによる開発の流れ
PIMとPSMという二つのモデルを経てソースコードに変換されるのが一般的。ロジックを記述する言語や,変換ルールの記述方法などはツールによって異なる。
画面●OptimalJ
英語版のもの。日本市場向けの製品は2003年11月に発売予定。
図3●拡張されたシーケンス図の表記法
繰り返し処理や条件分岐が書ける。他のシーケンス図を参照することもできるので,図の再利用性が高まる。
図4●複合構造図の例
「Car」クラスの中の四つの「Wheel」が,どのような関係にあるかを記述している。
 一般にシステムを開発するとき,システムに対する要求を分析し,その結果に基づいて設計する。分析/設計の結果は,UML(Unified Modeling Language)などを使って図で表現することが多い。システムの構造や振る舞いがソースコードよりも抽象的に表現されている。

 通常はこれに基づいてコーディング作業を始める。しかし作成した図からソースコードを自動的に生成できれば,かなりの労力削減につながる。このソフトウェア開発手法をMDA(Model Driven Architecture:モデル駆動型開発)と呼ぶ。2001年に米OMG(Object Management Group)がそのコンセプトを発表した。ようやくここにきてツールが整備されてきて,企業システムでの有効性検証が始まった。

組み込み系では目新しくない

 実のところMDA的な考え方は,組み込み用ソフトウェア開発では従来から使われてきた。

 MDAの利点は大きく二つある。一つは,プラットフォームの変更が容易なことだ。基本的なシステムの構造や振る舞いの情報は,実行環境が変わってもそのまま使い回せる(図1[拡大表示])。

 もう一つの利点は,モデルの段階でシステムの動作を検証できること。ソースコードを書かなくてもツール上でモデルの動作を確認できるため,早い段階でバグを見つけられる。

 組み込み系では,開発段階でシステムを別のプラットフォームに載せ替える手間が発生する。ハードウェアとソフトウェアの開発が並行して進められるからだ。まず評価用キットを使って開発を進め,ソフトを動かせる段階になってから機器に組み込む。このとき,MDAなら変換ルールを切り替えるだけでよい。しかもモデルで動作を検証できれば,ハードウェア開発が遅れてもソフトウェア開発の進行を妨げない。

変換ルールの作成が困難

 組み込み系で実績を積んでいたにもかかわらず,ここまで企業情報システムでは使われなかったのは理由がある。組み込みシステムは適用する領域(ドメイン)や規模が限られているため,ソースコードへの変換が比較的容易だからだ。

 MDAを実現する上でやっかいなのは,モデルとソースコードの対応付けだ。ドメインを限定しなければ対応関係を記述できない。例えば同じ「データの保存」でも,データベースを使うか独自のアクセス・メソッドを使うか,それともテキストで保存するのか。これはドメインやプラットフォームによる。

 MDAにおいて,ユーザーが作成するのは原則としてPIM(Platform Independent Model)だけだ(図2[拡大表示])。動作環境に左右されない,システムの基本的な構造や振る舞いしか記述しない。

 ツールはこれにプラットフォームの情報を足しこんだ情報に変換する。変換に適用するルールは,プラットフォームごとに用意する。さまざまなデータベースやミドルウェアの利用を想定し,あらゆる変換ルールを用意しておくのは不可能に近い。

 その点組み込み系なら,システムのドメインは機器の制御に限られている。規模もそれほど大きくない。変換ルールは比較的容易に揃えられる。

J2EEにドメインを限定

 だがここに来て,企業情報システムでもMDAが使えるという見方が出てきた。その最大の理由は,開発プラットフォームとしてJ2EE(Java2 Platform,Enterprise Edition)が確立されつつあるからだろう。フレームワークなどのソフトウェア部品も充実してきており,多くのシステムで採用されている。適用ドメインをJ2EEに限定すれば,変換ルールは作りやすい。

 実際に企業情報システム向けのMDAツールは,現在のところJ2EEに特化したものが主流だ。例えばシナジー研究所が2002年から発売中の「ArcStyler」や,日本コンピュウェアが2003年11月に発売を予定する「OptimalJ」である(画面[拡大表示])。どちらも,モデルからソースコードを自動生成してくれる。J2EEの範囲内とはいえ,異なるプラットフォームへの変更も容易だ。「J2EEと言っても,実装はアプリケーション・サーバーやデータベースに依存する。こうした違いをツールが吸収する」(日本コンピュウェア営業技術本部第二システム部主査システムエンジニアの山本忠担当次長)。

UMLもMDAに対応

 こうした動きをさらに加速させそうなのが,UMLの仕様変更だ。UMLは,業務系,組み込み系を問わずシステム開発の現場で広く使われている。次期バージョンであるUML 2.0に,MDAをにらんだ仕様が多く付け加えられることになった。

 例えばシーケンス図の表記法が拡張され,システムの振る舞いを詳細に書けるようになった(図3[拡大表示])。またコンポーネントなど複数の要素を組み合わせたシステムを表現するために,複合構造(Composite Structure)図が追加された(図4[拡大表示])。個々の要素の役割をこの図で定義しておけば,それに合わせた変換ルールを適用できる。

完全な自動生成は不可能

 ただしUML 2.0を使っても,MDAの現在の課題は解消されない。例えばロジックを生成するには,かなり詳細な情報をPIMで定義する。プログラムそのものではなくても,それに近いレベルまで詳細化しなければならない。

 幅広いアプリケーションに対応するのが難しいという課題も残されたままだ。それに合わせた変換ルールを作成しなければならないからだ。ある程度はツールが用意してくれるが,種類は限定される。例えばOptimalJが対象としているのは,データベースを使ったデータの取得/格納が発生するWebアプリケーションである。これ以外の処理は自分でJavaのコードを記述する必要がある。MDAを有効に使うには,「限界をきちんと知ることが大切」(日本コンピュウェアの山本氏)だ。

(八木 玲子)