MDAをツールで体験する （前編）
-iUMLite：ソフトウェア開発の1つの方向性を示すツール-

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

2003/11/28

---

　「MDA（Model Driven Architecture）」というキーワードがふわふわとIT業界を漂うようになってしばらくたつ。しかしMDAとはいったい何なのか、どうもつかみどころがないと、だれもが思っているのではないだろうか。

　MDAはUMLの標準策定を進めてきたOMG（Open Management Group）が、「その次の一歩」を狙って標準策定を推進しているモデル駆動開発のための方法論の1つである。しかし、OMG自身にとっても、MDAの姿を漠然としか認識していないような気がする。MDAとは方法論なのか？ UMLのようなモデリングの標準言語なのか？ あるいは、単なるキーワードなのか（とすれば、何のキーワードなのか）？ 何をすればMDAといえるのか？ OMGからMDAに関するいくつかのホワイト・ペーパーが出ているものの、具体的な成果物はまだ一般にはほとんど公開されていないといってよい。

　今回は、MDAを提唱するツールをいくつか実際に使ってみたらどうなるか？ MDAツールを使うとどういう開発プロセスをたどることになるのかを体験してみよう、というのが記事の趣旨である。従って、開発ツールの評価が主な目的ではない。

　MDAと呼ばれている、あるいは自ら名乗っているツールや方法論も実はいろいろな種類があって、それぞれかなり違うものである。ただし、大きく2種類に分けられるかもしれない。1つはデータ・モデリングを中心としてJ2EEのようなフレームワークのスケルトン生成を目的としたのもの。もう1つはビヘイビア・モデリングを中心としてコードの自動生成を目的としたものである。

　前者は主にクラス図を利用してモデリングを行い、ビジネス系のシステム開発でよく用いられる。後者は主にステートチャート図を利用してモデリングを行い、組み込み／制御系のシステム開発でよく用いられている。また、前者はどちらかといえばラウンドトリップ・エンジニアリングの延長でアルゴリズムまで完全に生成するためのものではないのに対して、後者はMDAはおろかUML普及以前から行われている方法でアルゴリズムまで完全に生成させる。

　今回は前者の代表として日本コンピュウェアの「OptimalJ」を、後者の代表として英Kennedy-Carterが開発、販売している「iUML」のフリー版「iUMLite」を実際に使ってみる。これらのツールとは異なる性格のツールもある。例えば、Eclipseの「EMF」（Eclipse Modeling Framework）や「GMT」（Generative Model Transformation、UMLXとも呼ばれる）などだ。これらのツールはOptimalJやiUMLiteなどのような「フル・パッケージ」化されたツールとは違い、1つ1つは非常にコンパクトで汎用性の高いツールの集合である。なので、ツールの中身もよくみえるし、どんなモデルをどうやって扱っているかもよくみえる。

　逆にいうと、これらのツールはメタ・モデルやモデル変換ルールがよく理解できないと使いこなすのは難しいかもしれない。筆者はこれが1970〜1980年代のUNIXに相当する強力な開発ツールになるのではないか（なればいいな）と考えている。それはともかく、これらのツールについては今回は触れない。Eclipseはいまや飛ぶ鳥を落とす勢いだから、きっと誰かがどこかで記事を書いてくれるだろう。

---

◆iUMLiteを使ってみる

　（iUMLiteの商品版である）iUMLは英Kennedy-Carterが開発、販売しているMDAツールである。実際には、MDAというよりもxUML（eXecutable UML）ツールといった方がいいかもしれない。xUMLの前身はシュレーヤ=メラー法である。xUMLをベースとしたCASEツールにはKennedy-Carterの「iUML」のほかに、米Project Technolodyの「BridgePoint」、米Kabira Technologiesの「Infrastructure Switch」、米Pathfinder Solutionsの「PathMATE」がある。中でもProject Technology社はシュレーヤ=メラー法の提唱者である故Sally Shlaer氏とStephen J.Mellor氏が創立した会社である。

　この中で今回iUMLiteを選んだのは、高価なxUMLツールの中で、iUMLのフリー版としてiUMLiteが提供されていたからである。iUMLiteはユーザー登録をすればKennedy-CarterのWebサイトから手に入れることができる。
　
　一般的な動作環境は、Windows NT 4とWindows 2000上となっている。Windows XPではモデルからシミュレータを動作させるためのコードを生成できなかった（実は筆者のWindows 2000 Serverでも症状は違うが、やはりできなかった）。製品版のiUMLとの大きな違いはモデルの要素数が限られていること、シングル・ユーザー向けであること、モデル・コンパイラをカスタマイズできないことなどである。また日本語は使えない。

　xUMLの開発プロセスはおおむねこんな感じだ。

1	システム全体をドメインに分割する （ユースケース図、ドメイン・チャート図）
2	各ドメインごとに
	2.1	静的モデルを作る （クラス図）
	2.2	動的モデルを作る （クラス・コラボレーション図、ステートチャート図）
	2.3	アクションを指定する
	2.4	（ドメインとドメインを結合する）ブリッジを作る
3	デザイン・パターンを適用する
4	コードを自動生成する

　だいたい2までが分析のプロセスで、それ以降が設計のプロセスと考えればいいだろう。2.3まで進めばモデルをシミュレーション実行できる。これがxUML、モデル駆動開発の大きな利点である。iUMLiteにはコード生成ツールは含まれていないので、今回の記事の範囲もこの辺りまでになる。

　さて、まずはModeller Liteというアプリケーションを立ち上げる。これ単独ではほとんど従来のUMLツールと変わらない。このツールはファイルではなくデータベースを利用するので、まずはレポジトリを作る。製品版では複数のユーザー、複数のバージョンをサポートしているはずだ。何か作業をするときもその対象のロックを獲得してからということになるが、これ自身はMDAとは直接の関係はない。また、モデル要素を作ると番号やらキーワードを入力するフィールドがあったりするが、これはシュレーヤ=メラー法の名残といってよい。

　まずはユースケース図から描き始めた。この辺はシュレーヤ=メラー法としては本来はなかったプロセスだが、いまや通常のUMLモデリング・プロセスと同じだ。

まずはユースケース図から描き始めた（クリックすると拡大）

　次にはドメイン･チャート図というものを描く。形式的にはUMLのパッケージ図と変わらないが、シュレーヤ=メラー法由来のxUMLでは非常に重要な部分である。ドメインとは解決すべき個々の課題を表したものだ。ドメインごとに使命があり、自律的で（つまりほかのドメインに依存しない）機能や実装に応じてドメインを入れ替えることができる。ドメインにはよく使われるいくつかの種類がある。例えば、

アプリケーション：ユーザーに何らかの価値を与えるドメイン

サービス：ほかのドメインに汎用的なサービスを提供するドメイン

アーキテクチャ：システムの基本設計方針を実現するドメイン

実装：既存のコンポーネント（ハードウェア、プログラミング言語やオペレーティング・システムなど）を抽象化したドメイン

などだ。xUMLではいかにうまくドメインを切り分けるかがシステム開発の成功を左右する。ドメインはパッケージで表し、「ほかのドメインのサービスを利用する」という依存関係を描く。

ドメインはパッケージで表し、「ほかのドメインのサービスを利用する」という依存関係を描く（クリックすると拡大）

　次にはそれぞれのユースケースに対してシーケンス図を使ってシナリオを考える。これは典型的なUMLモデリング・プロセスと同じだが、このシナリオに参加するのはドメインであるというところが少し違う。

それぞれのユースケースに対してシーケンス図を使ってシナリオを考える（クリックすると拡大）

　ここで左側に<Boundary>という名前の生命線があったり（通常はアクタがいる）、一番左にはシナリオをテキストとして書く部分があるのはいい工夫かもしれない。この部分には「If Else」なども書ける（ツールが解釈してくれるわけではないが）。

　次にドメインごとに静的な構造を記述する。つまりクラス図を描くわけだ。どうやってクラスを抽出し、属性、関連、操作などを追加すればよいかについては、これまたシュレーヤ=メラー法以来の独自の方法がある。シュレーヤ=メラー法はオブジェクト指向分析設計方法論の中では非常に厳格なモデリング手法で、特に静的構造の分析はERモデリングの影響を受けている。例えば、各クラスにはプライマリ・キーに相当するフィールドを指定したり、関連には番号を付けたりする。これは実は後で述べるアクション言語の記述に関連してくる。

　興味のある読者は『Executable UML - A Foundation for Model-Driven Architecture』（Stephen J. Mellor、Marc J. Balcer、2002、Addison-Wesley）をご覧いただきたい。邦訳の話も聞くのだが。どうなっているのだろうか（編注：近日翔泳社から翻訳刊行予定）。

ドメインごとに静的な構造を記述する。つまりクラス図を描くわけだ（クリックすると拡大）

◆動的な振る舞いをモデリングする

　さてここから動的な振る舞いをモデリングしていく。

　まずはクラス・コラボレーション図を使って先ほどクラス図に描いたドメインに参加しているクラス間のコラボレーションを記述する。クラス・コラボレーション図というのは（ドメインではなく）クラスのコラボレーション図という意味で、図の形式としてはUMLのコラボレーション図と同じだ。ただし、この図の目的は明確で、オブジェクト間でどのような同期／非同期メッセージが交換され、どのオブジェクトが状態を持つかなどを分析することである。

　ドメイン・コラボレーション図の描き方にも作法がある。例えば、

メッセージの出入りの多いオブジェクトは大きく描く

図の左に「高レベルの」オブジェクトを、右に「低レベルの」オブジェクトを描く（Project Technologyのガイドラインでは上から下へ。微妙な違いが面白い）

メッセージはできるだけ水平に描く

などだ。

　もっともツール自体はかなり素朴なので、図をきれいに描くのには結構労力を要するが、このようなガイドラインに従って描かれた図が分かりやすいのは確かだ。

　また、通常のUMLとは異なり、ここでTerminatorというものを考える。Terminatorとはドメインの外側にあってこのドメインのオブジェクトと関係のあるオブジェクトのことだ。ロバストネス分析に使われるBoundaryに似ているけれど、プロセスにおける使われ方の意味合いはかなり異なる。例えば、ドメインへの入出力を表すオブジェクト、ほかのドメインにあるオブジェクトとの関連などがTerminatorとしてここで現れる。

まずはクラス・コラボレーション図を使って先ほどクラス図に描いたドメインに参加しているクラス間のコラボレーションを記述する（クリックすると拡大）

　こうしてクラス・コラボレーション図の中で「制御」役をしているようなオブジェクト、状態に依存した働きをしているオブジェクトに対してそれぞれステートチャート図を描く。ステートチャート図も基本的には通常のUMLのステートチャート図を描く場合と同じだ。ただし、iUMLiteではUMLで使われているHarelの状態図のサブセットになっている。例えば、アクションは状態の入状アクションしか書けない。歴史的にそうなっていることもあるだろうし、コード生成の都合上このくらいで十分、ということかもしれない。

　iUMLiteの特徴の1つは状態遷移を表すのに状態遷移表で書くこともでき、常にステートチャート図と同期していることだ。状態遷移表もステートチャート図も表している内容は基本的に同じだが、ステートチャート図では状態の遷移を一目で追いかけることができるのに対して、状態遷移表では状態が受け取るシグナルに対するアクションのモレ・ヌケがないかどうかを一目でみることができる。

ステートチャート図も基本的には通常のUMLのステートチャート図を描く場合と同じだ（クリックすると拡大）

◆実際に動かしてみよう

　さて、ステートチャート図が描ければ動かすことができるはずだ。iUMLiteでは状態や操作にアクションを書くことができる。通常のUMLツールではアクションは何でもモデラの好きに書ける代わりに、ツールがアクションを実行してくれるということはない。しかし、iUMLiteではこのアクションを実行してくれるのである。実は、UML 1.5ではアクション・セマンティクスというものが含まれている。これはどんな種類のアクションがあってそれを実行すると何が起こるかを決めたものであるが、残念なことにシンタックスまでは決められていない。iUMLiteでは、独自のASL（Action Specification Language）を決めている。

　ステートチャート図を動かすことによって、ドメイン分析の妥当性確認をしたい場合には、まず状態にアクションを加える必要がある。さらに、初期化（Initialization Segment）と状態機械起動（Test Method）のためのアクションを書く。その名前のとおり、ステートチャート図をシミュレーションするのは分析モデルの正しさを「テスト」するためのものだ。初期化アクションは例えばこんな具合になる。

# initialization code four_star_fuel_grade = create FUEL_GRADE with \         Grade_Name = "Four Star" & \         Unit_Price = 62.9 tank_1001 = create TANK with \         Tank_Number = 1001 & \         Tank_Empty_Flag = TRUE & \         Tank_Level = 0.0 & \         Tank_Capacity = 100000.0 & \         Empty_Threshold = 4.0 & \         Current_State = 'Waiting_For_Tanker_Delivery' link four_star_fuel_grade R2 tank_1001 pump_1 = create PUMP with \         Pump_Number = 1 & \         Current_State = 'Waiting_For_Customer' link pump_1 R1 tank_1001

　FUEL_GRADEのインスタンスfour_star_fuel_gradeとTANKのインスタンスtank_1001を生成して初期化している。次に、この2つを関連R2でつないでいる。ここでは単純な文しかないが、もちろん「if 〜 else, while」などの制御文を書くこともできる。非常に高レベルでモデルの操作に適合したプログラミング言語の断片と思えばよい。

# test code pump = find-one PUMP where Pump_Number = 2 generate PMP1:Gun_Removed() to pump

　こちらはTest Methodの例。インスタンス変数の値が2であるようなPUMPのインスタンスを探して、それにGun_Removed()イベントを送っている（この記事の例はKennedy-Carterが配布している“iUMLite Tutorial”から取っている）。

　ステートチャート図の状態にアクション（いわばプログラムの一部）が記述されるので、どうしてもステートチャート図の見栄えはこんなふうになってしまう。

ステートチャート図の状態にアクションが記述されるので、どうしてもステートチャート図の見栄えはこんなふうになってしまう（クリックすると拡大）

　これを実行するためには、モデルの中のアクションをファイルに書き出して、ビルドする。iUMLiteでは最終的にCコードに落ちるようだ。もちろんこの辺はメニューから選択すればツールがやってくれる。残念ながら筆者の環境では最後の実行可能ファイルを作ることができなかったが。

　うまくいけば簡単なデバッガ風の環境でステートチャート図を実行させることができるはずだ。主な機能としては、

ステップ実行

オブジェクト一覧

ブレークポイント

実行トレース表示

シグナル・キュー表示

などが挙げられている。

　モデルのシミュレーションによって各ドメインの分析の妥当性が確認されたら、これを基に設計を行っていく。設計の目的は製品として出荷可能なコードを自動生成させることである。アクションを追加したり、コード生成のヒントになるタグを追加したり、ドメインとドメインをつなぐブリッジを記述したりする。タグはクラス、遷移、操作などに付けることができ、ユーザーが定義することもできる。モデルは最終的にモデル・コンパイラによって出荷可能コードに落ちる。

　モデル・コンパイラはKennedy-Carterによって複数提供されている。また、iCCGというツールを使えば自分でルールを定義してモデル・コンパイラを用意することもできるようだ。いずれにしろ、これらの機能はiUMLiteの範囲を超えている。

　iUMLiteはツールとしてはそのほかにも、要求管理（アクセス権の設定と管理、追跡、要求ライフサイクルの管理など）、レポート作成など多彩な機能を持っているが、これらはMDAとは直接関係ないのでここでは述べない。

◆ソフトウェア開発の1つの方向性として

　iUMLiteやiUMLiteのベースとなっているxUMLはすでに長い間進化しながら利用されてきたし、モデルから直接出荷可能なコードを生成できるのは非常に魅力的だ. しかしシュレーヤ=メラー法にはかなり独特の部分があったり、xUMLに基づくモデリングもまだまだ誰にでもできるというわけではない。特に、どうやってドメインを切り出してくるかは難しく、システム全体に大きな影響を与える。クラスの状態遷移の切り出しも同様だ。とはいうものの、iUMLiteのようなツールがこれからのソフトウェア開発の将来の方向性の1つを見せているのは間違いないだろう。

（後編に続く）

IT Architect 連載記事一覧