MDAのしくみ（1）
MDAのメリットを考える

ボーランド
樫山友一

2004/2/11

---

◆はじめに

　MDAが実用段階に入りつつあります。筆者も昨年の夏、MDAを調べて解説を書いたことがありますが、あれから１年が経過してかなり実用が現実味を帯びてきています。おそらく来年にいくつかの実用的なツールがリリースされるでしょう。本記事では、MDAが実用段階に入った場合の開発スタイルとMDAのしくみを3回にわたって解説します。

◆MDAの概要

　MDAのしくみの詳細は後の回に譲るとしてここでは、MDAを理解するための簡単な解説をします。MDA＝Model Driven Architectureは、その名のとおりモデルを中心として開発を進めていく方法を提唱しています。中心となるモデルは、図1に示すとおり2階層から成り立ちます。

PIM（Platform Independent Model）
プラットフォームに依存しないモデルです。プラットフォームとは、CPUやOS、ミドルウェア、言語などを表します。

PSM（Platform Specific Model）
プラットフォームに依存したモデルとなります。よって、実際に開発対象となるプラットフォームの開発言語と1対1に対応します。また、J2EEや.NETなどにも依存します。

　PIMからPSMへは、ツールを使って自動的に変換することが可能となります。また、PSM間もブリッジツールによって、変換することが可能となります。

図1 MDAの概要

◆MDA登場の背景

　UMLが広く普及し、多くのソフトウェア開発に使われてきています。その一方で、UML自体の限界も認識されてきています。ここでいうUMLの限界とはなんでしょうか。まず、MDAを実現するためにUMLと開発言語のマッピングが行われていなければなりません。現在のUMLでは、開発言語とUMLの間のマッピングが完全ではないために、ラウンドロビン（モデルから言語、言語からモデル）の変換がうまくできない可能性があります。MDAの中でUMLと各開発言語がどのように関連付けられているのかは、第3回に解説します。

◆MDAのメリット

　さて、MDAの概要が分かったところで、MDAを導入するとどのようなメリットがあるかを解説します。前述の説明までで、多くの人はPIMのモデルを作っておけば、どのような言語の開発もスムーズに行えるということが分かったと思います。しかし、MDAのメリットは、もう少し別のところにあると筆者は考えます。では、まずそのメリットを解説する前にその背景について考えてみます。

　Javaによるサーバサイドの開発がされるようになって、3年以上が経過しています。現在、第1世代のJavaで開発したサーバの入れ替えプロジェクトなどが起こりつつあります。このプロジェクトでは、コードを単純に新しいJavaの仕様に合わせて修正していくという作業で、新しいハードウェアと新しいJavaの仕様で動作するように変更することができます。ここで、少し考えてみましょう。新しいハードウェアと新しいJavaの仕様で動作するようになったアプリケーションは、また3年後に新しいハードウェアと新しいJavaの仕様で動作するように変更しなければなりません。これを永遠に繰り返していくのでしょうか（図2）。

図2 J2EEアプリケーションサーバのマイグレーション

　システムを新規開発後、3年が経過すれば業務の変更などがあり、システムの仕様も変更されることになりますが、多くの企業では3年の単位では業務の変更は行われないでしょう。では、なぜ3年置きにマイグレーションを繰り返していかなければならないのでしょうか。

　これは、ハードウェアやミドルウェア製品のサポートされる期間が短くなってきていることに起因します。メインフレームで基幹システムが構築されている場合には、ハードウェアのサポート期間は、それほど問題にはなりませんでした。しかし、多くのアプリケーションがオープンシステムに移行してきています。オープンシステムでは、その性格上、ハードウェア、OS 、ミドルウェアの進化が早く、それを提供しているベンダは、次々に新しい製品をリリースしていかなければならないために、メインフレームなどに比べて製品のライフサイクルが短くなります。よって、製品のサポートが切れたものを使い続けるリスクがあり、オープンシステムを採用している場合には、メインフレームよりも短いサイクルでマイグレーションを繰り返していく必要があります。

　多くの基幹業務システムがオープンシステムに移行してきていますが、このマイグレーションサイクルの問題で、メインフレームを利用していた場合よりもコスト高になる可能性があります。マイグレーションのための費用が思ったよりも高くなることがその理由です。

　オープンシステムを利用している場合は、定期的なマイグレーションは避けられないものだと思っていいでしょう。では、そのマイグレーションのためのコストをどのように抑えるかが問題となります。そのために有効なものがMDAとなります。

　マイグレーションを繰り返さなければならないのは、テクノロジの進化のスピードと業務の変化のスピードにギャップがあるからです。このギャップが存在することを前提に開発を考えてみると、解決策が分かります。

　UMLとオブジェクト指向技術の進歩により、業務をモデルとして記述することが可能になっています。記述されたモデルは、その業務が変更されない限り有効となります。現在も、業務をUMLでモデル化して、プラットフォームからの依存度を低くし、実装モデルを業務モデルから作成して、実装を行うといった開発スタイルを実現しているプロジェクトがいくつか見られます。

図3 業務モデルとテクノロジ

　図3のようにJ2EEを継続して利用するケースもMDAのメリットが受けられますが、図4のようにほかのプラットフォームに移行するような場合もメリットを受けられます。テクノロジの変化は早いので、J2EEに代わるサーバサイドのプラットフォームが登場する可能性もあります。この場合でも、MDAがテクノロジに依存した部分を吸収します。PIMを作成しておけば、テクノロジの変化に依存せずに動作するモデルを持てるということになります。

図4 .NETとJ2EEのインターオペラビリティ

　このような開発スタイルをもう一歩推し進めたのがMDAを用いたアプローチです。MDAを用いたアプローチもいくつか考えられますが、例を図5に示します。

図5 MDAを用いたプロセス概略

　一見、プロセスとしては１段仕事が増えるように思えますが、PIMからPSMへの変換はツールが自動で行うので、以前に設計モデルを作成していたアクティビティがPIMの作成に変わったと考えられます。

◆コンポーネント化と再利用性向上の可能性

　コンポーネントを用いた再利用がJ2EEのEJB （Enterprise Java Beans）などの登場により加速されてきています。また、Strutsなどのオープンソースのフレームワークなどが利用され始め、各社からも多くのフレームワーク製品が販売されています。

　コンポーネントは、フレームワーク上で動作するため、あるコンポーネントを継続的に利用するためには、同じフレームワークを利用し続ける必要があります。例えば、Strutsで開発したコンポーネントは、JSF（Java Server Faces）では、作り直す必要があります。ここで再度、技術の進歩のスピードの問題に直面します。確かに、フレームワークを採用すれば、コンポーネント化を進め、再利用性を向上させて効率を高めることができます。しかし、そのフレームワークが陳腐化した時点で、蓄積したコンポーネントはすべて手直しすることになります。

図6 フレームワークとコンポーネント

　図6に示す移行作業は、作成したコンポーネントが多ければ多いほど、作業量が多くなります。そのため、コンポーネントのメンテナンスのためのコストが増大して、逆にコストが高くなってしまうという状況が発生してしまうかもしれません。

　MDAは、この問題を解決する機能を持ちます。PIM上で、フレームワークを構築して、そのフレームワーク上にコンポーネントを構築していくことで、コンポーネントをフレームワークに依存しないものにします（図7）。

図7 PIM内のフレームワーク

◆まとめ

　今回は、MDAが最終的に実用化に入った場合にはどのようなメリットがあるかに注目して解説をしました。このような開発がすぐに可能になるわけではありませんが、MDA対応のツールも2004年には、数多く登場するでしょう。ただ、現在も多くのオープン化プロジェクトや新規システム開発プロジェクトが行われています。MDAの登場を待たずに、オブジェクト指向の分析設計を導入して、スムーズにMDAの世界に移行できるような開発作業が重要であると考えます。

　次回は、MDAを採用すると開発の流れがどのように変わるか、また、どのような開発の流れを採用すればよりMDAのメリットを享受できるかを解説します。

Development Style 連載記事一覧