mda技術の効果と課題rsa（rational software architect）, compuware社の optimalj,...

技術部

開発技術チーム

ITスペシャリスト

小松　清希

Seiki　Komatsu

※本論分は、2001年IBMソフトウェア協力企業SE論文で発表したものである。77

MDA技術の効果と課題－オープンソースのモデル・トランスフォーマ AndroMDA－

　UML（Unified Modeling Language）によるソフトウェア設計が普及してきた。UML はオブジェクト指向設計のモデリ

ング仕様である。UML は次のステップとしてUMLモデルからコードを自動生成するMDA（Model Driven Architecture）を目指しており、標準化と並行して徐々に実装が進展している。

　今回筆者のグループは数あるMDA の実装の中からAndroMDAを取り上げ、その機能・完成度と生産性を検証した。

その中でMDA の問題点とMDA ベースの開発業務展開に必要なアクションが見えてきた。

exa review　No.5（2005.12）

78

MDA技術の効果と課題　－オープンソースのモデル・トランスフォーマ AndroMDA－

り抽象的なので、さらに生産性の向上が期待できる。

　また、UMLモデルは図示されているので、コンピュー

タにまねができない人間のパターン認識を活用することに

より、素早い理解が可能になる。

2.2. アーキテクチャへの自動展開

　IT（Information Technology）が企業システムに広く

普及することで莫大なソフトウェアが作成されるようにな

った。ソフトウェア開発のシーンでは、常にスクラッチで

すべてを毎回コーディングするということはありえず、共

通のライブラリやフレームワークを中心に置き、業務ロジ

ックをプラグインする形式で品質と効率を高めている。そ

の結果、同じプログラミング言語であっても適用するミド

ルウェアやフレームワークが違うと異なるルールでの設計

・実装を求められるデメリットが顕在化してきた。MDA

を適用することで、アーキテクチャに依存しないUMLモ

デルから自動的にアーキテクチャに準拠したコードを得る

ことが可能となる。MDAはプログラミング言語だけでは

なく、実装アーキテクチャからも設計者の関心を開放する

ことができる。

2.3. その他の効果

　MDAによってUMLモデルからアプリケーションを自動

生成することで、プログラマの能力の差異から生ずる品質

のばらつきを解消する効果がある。

　また、設計書（UML）に実装が従属するため、設計書

が修正されず実装だけが変更されていくといった乖離を防

止でき、メンテナンス時の混乱を回避することができる。

2.4. MDA のプロダクトと動作環境

　MDAはアーキテクチャの仕様を定めたものであり、開

発業務への適用にはMDAを実装したプロダクトが必要と

なる。現在入手可能なMDAプロダクトとしてはIBM社の

RSA（Rational Software Architect）, COMPUWARE社の

OptimalJ, オープンソースで無償のAndroMDAなどがあ

る。したがって、MDAで開発を実施する際の開発環境は採

用したプロダクトが動作する実行環境となる。一方、MDA

で生成したアプリケーションの実行環境は、MDAプロダ

クトが出力するコードの種類による。例えばAndroMDA

1. はじめに

　UML（Unified Modeling Language）によるソフトウェ

ア成果物の仕様化、図式化が普及してきた。UML はオブ

ジェクト指向設計の統一モデリング仕様である。UML は

次のステップとしてUMLモデルからコードを自動生成す

るMDA（Model Driven Architecture）を目指しており、

標準化と並行して徐々に実装が進展している。

　今回筆者のグループは数あるMDAの実装の中からAndro

MDAを取り上げ、その機能・完成度を把握するとともに、

その生産性を定量的に検証した。

　その中でMDA の問題点とMDA ベースの開発業務展開

に必要なアクションが見えてきた。

2. MDAとは

　オブジェクト指向技術の開発と標準化を行う非営利団体

：Object Management　Group（OMG）1）は2001年に

Model Driven Architecture（MDA）の構想を制定した。

MDAはアプリケーションドメインのプラットフォーム非

依存を狙っている。

　現在Java/J2EE,C#/.Net, XML/SOAPなどプラット

フォームが乱立しており、この乱立状態が収束することは

なさそうである。アプリケーションドメインがプラット

フォーム非依存になれば、企業のシステムに大きなメリッ

トをもたらす。

2.1. 生産効率の改善

　「プラットフォームに依存して流行があるプログラム言

語で開発するのではなく、UMLモデルのみで開発したい。

即ちモデルを実行可能としたい。」という要求がある。

　MDA は"モデル・コンパイラ"（UMLで作成したプラッ

トフォームに依存しないモデルから、指定したプラットフ

ォームに適合したコードを生成するツール）を実現し、上

記の要求に応えるソリューションである。

　モデルはプログラムより抽象度が高いため、開発・保守

の生産性が向上する。機械語やアセンブラから高級言語に

パラダイムシフトしたとき、生産性が著しく向上した歴史

がある。これはアプリケーションとしては関心がない実現

手段（スタック,レジスタ,アドレス）を高級言語が隠蔽し


図１　AndroMDAの入出力と構成要素

UML

(モデリングツール)

AndroMDA

AntNetBeans MDRSableCCDigesterVelocity

J2EE Web

MagicDraw Maven J2EE EAR

JSPJava設定ファイル

Struts,Hibernate(,Spring)‚に依存

入力変換出力

アクティビティ図

≪FrontEndView≫

アクティビティ図遷移（旧≪FrontEndView≫）

コントローラクラス（旧≪FrontEndView≫）

≪ValueObject≫クラス

≪Service≫クラス

クラス図≪Entity≫クラス

コントローラ

値オブジェクト

ファサード

ドメイン

AndroMDAモデル実装

JSP

Action Class

DAO

UML Java

DB

ドメイン層

Web層

図２　AndroMDAの出力するアプリケーションアーキテクチャ

79


Hibernateが利用され、マッピングファイルもUMLモデル

から自動生成される。したがって、データベースアクセス

の細かいコーディングをJDBC（Java DataBase

Connectivity）を用いて記述する必要はない（図2）。

　AndroMDA を用いた開発の手順は、以下の流れとなる。

　（1）AndroMDA 用の新規プロジェクトを作成

　（2）MagicDraw UML を用いてアプリケーションをモ

　　　デリング

　（3）AndroMDA に変換開始を指示

　（4）自動生成だけでは不足する細部の処理をハンドコー

　　　ディング

　（5）全てをビルドしてJ2EEのWARやEARアーカイブ

　　　ファイルを得る

　この手順では、（2）の比重が大きくなる。正しいモデル

を与えないと期待する結果を得ることができない。

　AndroMDA はUML モデルをファイルで受け取るが、

そのモデルを作成するツールは含んでないので、推奨ツー

ルとされているNo Magic社のMagicDraw UMLを別途用

意して利用する必要がある。MagicDraw UML によるモ

デリングの様子を図３, 図４に示す。

をMDAプロダクトとして採用した場合、開発環境は

J2SDK 1.4 が動作する環境であり、具体的にはWindows

や各種UNIX環境が広く該当する。AndroMDAを用いて

J2EE Web アプリケーションを作成した場合、特別なカ

スタマイズを行わない場合はJBoss社のオープンソース・

アプリケーションサーバであるJBoss用の設定ファイルを

出力するので、JBoss の稼動する各種UNIX, Windowsが

作成アプリケーションの動作環境となる。

3. AndroMDA とは

　AndroMDA3）はMatthias Bohlen 氏と The Andro

MDA Project による、MDA パラダイムにのっとったコー

ド生成フレームワークである。AndroMDA はUML モデ

リングツールMagicDraw UML4）を用いて出力したXMI

（XML Metamodel Interchange）形式ファイルを入力と

し、半完成のアプリケーションコンポーネントを出力する

（図1）。

　AndroMDA はカートリッジと呼ばれる変換モジュール

をプラグインすることで、さまざまなプラットフォームに

対応する多様なプログラミング言語のソースコードを自動

生成することができる。しかし、それは用途に適したカー

トリッジが存在し、入手できた場合のことである。

AndroMDA にバンドルされていてすぐに利用できるカー

トリッジでは、J2EE 向けのJava コードを生成すること

ができる。そのターゲット環境は、アプリケーションサー

バとしてJBoss を利用し、Struts やSpring をフレーム

ワークとして利用する。

コードだけではなく、Struts の設定ファイルやJ2EE の

DD（Deployment Descriptor）ファイルも生成される。

リレーショナルデータベースとのOR-Mapping には


図３　MagicDraw UMLによるクラス図作成の様子

図４　MagicDraw UMLによるアクティビティ図作成の様子


80exa review　No.5（2005.12）

顧客

商品をブラウズ

商品を購入

ユーザ登録

ログイン

管理者

注文承認

売上分析

サプライヤ

在庫確認在庫登録

注文受付処理

商品発送処理

注文完了処理

在庫引当

ペンディング解除

Java Prt Store

Admin

Storefront OPC

Supplier

図５　Java PetStore のユースケース


81

　J2EEを用いてアプリケーションを設計するガイドとし

て、サンマイクロシステムズはドキュメント『Java

BluePrints』6）を公開している。Java PetStoreは『Java

BluePrints』に付属するサンプルアプリケーションであ

る。

　パイロット開発を担当したのはJava, Web, UML のス

キルを有する若手のSE であり、事前に２ヶ月のAndro

MDAのトレーニングを済ませた後、開発に取り組んだ。

5.1. Java PetStore の概要

　Java PetStore はJ2EE の様々な技術を用いて構成され

たアプリケーションであり、その規模は全体で約108 FP

（Function Point）である。このアプリケーションはイ

ンターネットでペットを通信販売する電子取引システムを

実装している。

　顧客はWebブラウザで商品を選びオンラインで注文する。

注文は商品管理センターに転送され、そこで在庫を引き当

てる。ペットショップの管理者はリッチクライアントアプ

リケーションを用いて注文状況を確認し、大規模注文の承

認を行う。サプライヤは商品の在庫数を確認し、搬入した

商品の在庫数を更新する（図5）。

　Java PetStore は、次の4つのコンポーネントで構成さ

れている。

（1） Storefront

　AndroMDA はオープンソースのプロダクトであり、

BSDライセンスに基づいて無償で利用することができる。

開発は2002年にはじまり、2005年9月21日現在ではVer3.1

のリリース候補である、3.1-RC1 が公開されている。

4. AndroMDA入門ガイドの公開

　当社技術部としては、ソフトウェア開発はMDA にシフ

トし、上記の開発手順のように、コーディングとユニット

テストよりも業務ドメインの分析と記述に集中するべきだ

と考えている。しかしMDA は開発者に広く認知されてい

るとはいいがたい。

　ソフトウェア実装とはプログラミング言語でコードを書

くことであるという常識があまりにも長く続いてきたため、

ビジュアルにUMLモデルを作成することで実装作業を抽

象化するというスタイルの変更は大きな障壁になっている。

さらに、MDA を実践するためのツールがまだポピュラー

でないことがMDAの認知を妨げている。

　そこで我々は、MDAによる開発評価を自ら推進するべ

く、また上記のMDA普及を促進することを目的とし、

AndroMDAを開発ツールの具体例として取り上げ、2005

年4月時点での基本的な利用法を解説するガイド文書

（『AndroMDA入門ガイド』5））を作成して公開した。

　AndroMDA はオープンソースで入手性は優れているが、

体系立てて構成された丁寧な日本語ドキュメントが存在し

ない。

　『AndroMDA入門ガイド』はUMLやJ2EEに精通した

読者が参照し、AndroMDA の標準機能を用いて一般的な

J2EE Webアプリケーションを自由に作成できるようにな

ることを目標にしている。

AndroMDA の特徴やAndroMDA を用いた開発手順の詳

細については、この『AndroMDA入門ガイド』に詳しく

記述したので参照されたい。

5. パイロット開発

　AndroMDAの生産性を定量的に評価するため、パイロッ

ト開発を実施した。開発の題材にはJava PetStore を選定

した。


商品カテゴリリスト

商品リスト

Itemリスト

Item詳細

顧客登録情報表示

顧客登録情報編集

ショッピングカート内容表示

送付先等入力

注文完了

ログイン/新規ユーザ登録

ショピングビュー

商品カテゴリを選択

submit[前イベント=新規ユーザ登録]

submit[前画面=顧客登録情報表示]

Add to Cart[未ログイン]

Add to Cart[ログイン済]

ショッピングカート

ショッピングカートビュー

顧客登録情報ビュー

画面にはナビゲートヘッダがあり、全ての画面からショッピングカートビュー、顧客登録情報ビュー、

ログイン・ログアウトに遷移することが可能

ログアウト

（ログアウト後も商品を閲覧可能）

新規ユーザ登録

顧客情報変更

ログイン

入店

ブラウザ終了

Acount Next

Add to Cart[ログイン済]

Add to Cart[未ログイン]

Update

Checkout

Submit

図６　Storefront モジュールの画面遷移

Storefront

OPC

Admin

Supplier

合計

総行数

53,390

16,917

43,051

25,414

138,772

実効行数

35,027

13,496

30,027

16,969

95,519

コメント行

10,980

2,371

6,979

5,132

25,462

空白行

7,361

1,050

6,045

3,313

17,769

ハンドコーディング行

3,123

2,160

1,148

1,455

7,886

自動化率(%)

91.1

84.0

96.2

91.4

91.7

表１　パイロット開発における自動生成率


82

Web 画面はAndroMDAの自動生成するJSPではなく、商

品として出せる品質の画面をハンドコーディングで作成し

ている。

　Admin モジュールのクライアントは本来はリッチクラ

イアントであるがAndroMDAの制約よりJSPでWebクラ

イアントとして実装した。

　画面系はすべてハンドコーディングしたが、全体で見る

とコメントや空白行を除いた9万5000行中でハンドコーデ

ィングを要したのはわずか7900行ほど、91.7%のコードや

設定が自動生成されており、保有する機能の範囲は良好で

あることがわかる。

6. AndroMDA の問題点

　『AndroMDA入門ガイド』を執筆し、パイロット開発

を実施する中で現在AndroMDAが持つ問題点が明らかと

なった。

（2） OPC（Order Processing Center）

（3） Supplier

（4） Admin

　Storefront は顧客が利用するWeb フロントエンドであ

る。顧客はStorefront を使用してペットを注文する。

Storefront は規模の大きいWebシステムである。その画

面遷移を図6に示す。

　OPC は３種類のタイミング、すなわちa.注文受け付け、

b.注文商品の個別配送、c.全注文商品配送完了の各時点で

必要な処理を行う。

　Supplier は注文を在庫から充当し、OPC に納品書を送

付する。また、在庫の状況確認と在庫補充を入力するWeb

フロントエンドを提供する。

　Admin は、JFC/Swing フロントエンドの管理者イン

タフェースである。管理者はAdminを使用して保留になっ

ている注文を調査し、それを承認または否認することがで

きる。また、商品販売実績の統計情報をグラフで確認する

ことができる。

5.2. パイロット開発結果

　AndroMDAを用いたJava PetStoreの開発ではコードの

自動生成率は表1のような結果となった。



83

えたMDAツールを採用することが望ましい。

（1）実行時ランタイムが不要なこと

（2）ピュアジェネレータであること

（3）カスタマイズが可能であること

　（1）はMDAで生成したアプリケーションがMDAツー

ル固有のランタイムライブラリに依存せず実行可能である

ことを意味する。実行時にMDA固有のランタイムが必要

であると、その部分が手を加えられないリスクになってし

まう。

　（2）はUMLモデリングツール等を含んだ統合開発環

境の形式では開発者の数だけMDAツールが必要になって

しまうし、こなれたモデリングツールやEclipse のような

整備された環境を活用する機会が奪われてしまう。MDA

はXMI 標準形式でUMLモデルを受け取り、プログラムや

設定ファイルといったコードモデルを出力する純粋なジェ

ネレータであって欲しい。

　最後に（3）は生成するコードが準拠するフレームワー

クを独自に追加・カスタマイズできる必要があることをあ

らわす。大規模な開発ではStruts などのフレームワークを

そのまま用いるのではなく、非機能要件に応じたカスタマ

イズを施すケースが多い。カスタマイズではなくフレーム

ワーク自体を新規に作成することもあるだろう。こういっ

た独自のフレームワークに適合したアプリケーションコー

ドをMDAで自動生成できないと、大規模プロジェクトに

MDA を適用することができない。従ってMDAツールのコ

ード生成カートリッジはカスタマイズ可能であることが重

要な要件となる。

　AndroMDA はこれら3点の本質的な条件を全て満たし

ている。

　筆者がいた推進グループでは、筆者の後任者を中心に、

AndroMDA のカートリッジを実際にカスタマイズする技

術の蓄積に取り組んでいるところである。

8. おわりに

　ソフトウェア開発において、工数を多く要するフェーズ

に実装・単体テストがある。これまではこのフェーズに大

　AndroMDA は概念レベルのUMLモデルから出発するの

ではなく、J2EE でStruts利用という暗黙の前提を意識し

たUMLモデルを入力としている。そのためAndroMDA用

に作成した業務モデルが将来プログラム言語やアーキテク

チャの変化にどれだけ安定していられるかは疑問がある。

例えばAndroMDAで作成するアプリケーションの画面遷

移をアクティビティ図で作成するが、これはStruts のア

クションクラスやJSP画面に対応がとられており、設計者

はStrutsを意識しながらモデルを作成する必要がある。

UMLには概念レベル、実装モデルといった、視点によっ

て異なるレベルがある。MDAは入力にUMLを利用すると

定めているが、レベルやUML中のステレオタイプ等も標

準化することによって同一のUMLモデルを異なるMDAプ

ロダクトで再利用することが可能となるはずである。

　オブジェクト制約記述言語OCL（Object Constraint

Language）のサポートがファインダメソッドの検索条件

のみに限定される、という問題がある。例えば「サービス

料は宿泊料の10%」という簡単なビジネスルールをOCL

で表現できるが、AndroMDAはこれを扱えない。

　また、AndroMDAでは簡単なWeb 画面JSP を自動生成

するが、ビジュアルな画面エディタが付属せず、外部ツー

ルとの連携機能も有していない問題がある。この原因は、

UML がアプリケーション画面をスコープに入れていない

ことに起因する。ソフトウェア開発の進化の観点からは画

面の柔軟なカスタマイズについても何らかの支援が欲しい

ところである。

　その他にも、AndroMDA はビジネスとしてのサポート

がない海外のオープンソースプロダクトであることから、

次のような制約がある

・日本語を扱うアプリケーションを作成する場合、修正が

　必要

・少ない情報（あっても英語）、少ない実績

・利用方法や障害に対してサポート供給がない

7. MDAベースの開発業務のために

　AndroMDA を用いてMDA を検証してきた中で、MDA

ツールに求める条件が見えてきた。事業としてソフトウェ

ア開発をMDA ベースですすめていく場合、次の条件を備



84

-----------------------------------------------------

Object Management Group, OMG, Model Driven

Architecture, Unified Modeling Language はObject

Management Group, Inc. の登録商標である

MDA,UML,OCL はObject Management Group, Inc. の

商標である

UNIX はX/Open Company Limited の登録商標である

JBoss はJBoss Inc. の登録商標である

OptimalJ はCOMPUWARE CORPORATION の登録商標

である

MagicDraw はNo Magic, Inc.の登録商標である

Windows および .NET は米国Microsoft Corporationの

商標、もしくは登録商標である

JavaおよびすべてのJava関連の商標は米国Sun Micro-

systems, Inc. の商標または登録商標である

その他の会社名ならびに製品名は、各社の商標、もしくは

登録商標である

------------------------------------------------------------------

量のSEを投入し、人海戦術で乗り越えてきた。この最も

コストのかかる工程を、MDAは大幅に効率化しようとし

ている。MDAが成功すると、プロジェクトは少人数化さ

れ、期間は短縮される。その中で自動化できない工程の占

める割合は従来より大きくなる。

　自動化できない工程は属人的であり、高いスキルが求め

られる部分である。その結果プロジェクトのリスクは大き

くなり、少人数で短いプロジェクト期間の中では失敗のリ

カバーも容易ではなくなるはずである。

　MDA実現が全ての問題を解決すると錯覚してはならな

い。MDA の後、モデリングスキルの向上はもちろん、よ

り上流工程に位置する要求開発の研究に取り組む必要があ

る。

　最後に『AndroMDA入門ガイド』の執筆とAndroMDA

を用いたパイロット開発においては（株）ブリッジの明井

賢一殿の貢献が大きかったことを申し添えておきたい。

参考文献

1） OMG, "OMG Model Driven Architecture",

　　　http://www.omg.org/mda/

2） ANNEKE KLEPPE, JOS WARMER, WIM BAST, "MDA

　　　導入ガイド", インプレス, ISBN4-8443-1869-1

3） AndroMDA Model Driven Architecture Framework,

　　　http://www.andromda.org/

4） No Magic Inc, "UML diagramming, OO software

　　　modeling, Source code engineering Tool MagicDraw

　　　UML", http://www.magicdraw.com/

5）（株）エクサ技術部, "AndroMDA入門ガイド",

　　　http://www.exa-corp.co.jp/techinfo/ti050902.shtml

6） Inderjeet Singh. et al, "Designing Enterprise

　　　Applications with the J2EE Platform, Second Edition",

　　　http://java.sun.com/blueprints/guidelines/

　　　designing_enterprise_applications_2e/

＜問い合わせ先＞

　技術部

　開発技術チーム

　　Tel 044-540-2149　小松清希

　　E-mail: [email protected]


mda技術の効果と課題rsa（rational software architect）, compuware社の optimalj,...

Documents