モデル駆動アプローチがうまく機能しない（しなくなる）8 つの理由

最近、モデル駆動ソフトウェア開発がますます高い関心を集めています。日々、MD（Model Driven: モデル駆動）で始まる頭字語が作り出されています。たとえば、MDA、MDE、MDD、MDSD、MDSE といった頭字語です。このようなことばの混乱は独創的な方法(リンク)で解決することができますが、私はどちらかというと MDE（Model-Driven Engineering: モデル駆動工学）ということばは好きです。MDE について最初に言及したのはケント [1] であり、MDA よりも MDE のほうが広い範囲を対象としています。MDA(リンク) では、単に PIM と PSM との対立やモデル間の自動変換というよりも、豊かなモデリングスペースのように物事を認識しますが、本当の工学手法を定義するということからは、依然としてかけ離れたものです。MDE は、複数のモデリング範囲という概念やソフトウェア工学の手法を MDA に付加するものです。

しかし、それでも MDA と MDE は高いレベルの構想なのですが、細かい部分では問題が解決されていません。モデル駆動方式でソフトウェアを構築したい場合は、ほかの方法の概念や実地経験に基づいた何らかの方法を考え出す必要があります。この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。もっと前向きな言い方をすれば、MDE を開始する際に注意すべき 8 つのポイントについて述べたいと思います。

1.     モデル駆動工学のすべての目的が対象とされていない

モデル駆動工学の根底にある動機は生産性の向上です。システムやプラットフォームが多様化している現在の複雑な企業環境において、既存のすべてのシステムや将来のすべてのシステムに、新しく構築したソフトウェアアプリケーションを適合させることは不可能です。MDE の目的は、企業がソフトウェア開発作業から得られる見返りを大きくすることです。それは、以下に示す 2 つの基本的な方法によって実現します [2]。

1. 開発担当者の短期的な生産性を向上する。つまり、ソフトウェアの最も重要なアーチファクトによってどの程度の機能が実現できるかという観点から、そのアーチファクトの価値を増大するということである。
2. 開発担当者の長期的な生産性を向上する。つまり、ソフトウェアの最も重要なアーチファクトが陳腐化する速度を低下させるということである。

ほとんどのツールメーカーが最も重視していることは、第一のメリットを実現することです。新しいソフトウェアアーチファクトを（一般的には技術的な）モデルから作成し、それによって開発担当者の生産性をサポートできます。しかし、最初の構築プロセスのあとは、ソフトウェアアーチファクトのライフサイクルの管理においてサポートは提供されません。生成されたソースコードまたはモデルのパーツを変更する必要があるため、往復の問題に発展します。

目まぐるしく変化している現在の企業環境において、2 番目のメリットはますます重要性が高くなります。ソフトウェアアーチファクトの価値が維持される期間が長くなればなるほど、アーチファクトを作り出すために行った最初の作業から得られる見返りは大きくなります。したがって、MDE の重要な側面によって、変更対象の最も重要なアーチファクトの反応性が低下します。アトキンソンとキューネ [2]は、特に重要性が高い、変化の基本的な形態として、主に以下の 4 つの項目を示しています。

1. スタッフ: 開発に関する重要な知識は、開発担当者の頭の中だけに蓄積しておくべきではありません。スタッフの変動が多過ぎると、このような情報は失われてしまいます。したがって、このような情報は、ソフトウェアアーチファクトを最初に作り出した担当者以外のスタッフが簡単に利用できるようにしておく必要があります。できれば、顧客を含め、関与しているすべての利害関係者が理解できる形態をとるべきです。技術的な意味: 重要なソフトウェアアーチファクトは、簡潔でカスタマイズ可能な表現を使って表すことができます。
2. 要件: ソフトウェア工学において要件の変更は既知の問題ですが、この問題は以前よりも重大な問題になっています。現在の目まぐるしく変化する企業のビジネス環境においては、新しい機能の開発はこれまで以上に迅速に行う必要があります。また、保守やオンラインシステムの中断といった点で、既存のシステムに対するすべての変更の影響を少なくする必要があります。最も理想的な状況においては、システムを稼動しながら変更を行う必要があります。技術的な意味: 実行時の新しいタイプの動的な付加をサポートする必要性。
3. 開発プラットフォーム: 開発プラットフォームも絶えず進化しています。ソフトウェアアーチファクトの最初に作成した際に使った開発ツールからソフトウェアアーチファクトのライフタイムを分離するには、開発ツールから、アーチファクトまたはアーチファクトを表すモデルを分離する必要があります。技術的な意味: ツールは、ほかのツールが使えるフォーマットでアーチファクトを保存する必要があります。言い換えると、ツールは高いレベルの相互運用性をサポートしている必要があります。
4. 運用プラットフォーム: 最後の変化の形態は運用プラットフォームの進化です。新しいプラットフォーム、ミドルウェアソリューション、アプリケーションサーバーなどの発売は、ますます迅速化されています。ソフトウェアアーチファクトのライフタイムを長くするには、運用プラットフォームの変化に対してアーチファクトを保護する必要があります。この形態の変化が、OMG で示される MDA 手法の背後にある最も大きな原動力です [3]。技術的な意味: ユーザーが定義できるマッピングを利用することによって、プラットフォームに依存しないソフトウェアアーチファクトからプラットフォームに固有のソフトウェアアーチファクトを取得するプロセスを（できるだけ最大限に）自動化する必要があります。

MDA や MDE について議論する場合、ほとんどのケースでは、MDA や MDE といった用語に付随する唯一の目的は、PIM や PSM を利用してソフトウェアアーチファクトの運用プラットフォームの変化に対する反応性を低下させることです。ただし、言及されているその他の目的も重要性は同じであり、これらのニーズを満たす方法を使うことで、ソフトウェア運用プロセスやビジネス IT の調整における多くの問題を解決することができます。

ビジネス IT の調整という状況において、ジェームス・テイラーは言及されている MDE の目的(リンク)に関する注釈(リンク)を付加しました。同氏は、「開発担当者および開発担当者の生産性を重視することは、MDE に到達する上で十分なことではない。それはエンジニアリングの原動力となるべきモデルは技術モデルではなく、ビジネスモデルであるべきだからだ」と言っています。ジェームス・テイラーは、目的として以下の 2 つの項目を追加しています。

• 非技術ユーザーが、安全かつ効果的にソフトウェアに変更を加えて、変更に関するニーズやビジネスに対する理解を反映する能力を向上させる。
• 過去に収集したデータを効果的に活用して、将来についての有効な予想を行うことによって措置を講じるソフトウェアの能力を向上させる。

ジェームス・テイラーは、このような目的を可能にするビジネス規則管理システムの例を挙げています。MDE 手法ではこのような目的の達成に取り組むべきであるという点では、私はジェームス・テイラーに同意します。しかし、現在の慣習では（この慣習は変わらないと思います）、モデリング言語の形式的側面という観点から、常にビジネスの専門家と技術（または形式）のスペシャリストを組み合わせることによって、モデルや規則を策定する必要があります。また、システム視点ではなくユーザー視点のビジネスユーザーモデルも必要です（たとえば、BPMN と BPEL の相違を参照してください）。したがって、ほとんどのケースで、開発担当者にこのような観点をそれぞれ別の観点に置き換えてもらう必要があるでしょう。例外としては、システムのビジネス規則に関する部分が挙げられます。それらが理解可能な言語で表現され、十分な設備が利用できる場合は、非技術ユーザーが規則の定義を更新できる必要があります。

2.     1 つのモデリング範囲しか使われていない: PIM と PSM との対立

MDE の目的を達成するためのアプローチにおいては、OMG のモデル駆動アーキテクチャで示されるただ 1 つのモデリング範囲だけでは不十分です。つまり、プラットフォームに固有な、またはプラットフォームに依存しない範囲が必要であり、この範囲は原則として、もっと汎用性の高い抽象的なサイズまたは具体的な範囲の例となるものです。このような範囲においては、モデルがほかのモデルに対して抽象的（プラットフォームに依存しない）か否かという観点でしか議論できません。これは、モデルがプラットフォームに依存しないのか、それともプラットフォームに固有のものであるのか（抽象的かそれとも具体的か）という観点に依存していますが、モデルがプラットフォームに固有のものであれば、実装に必要なすべての詳細が必ずモデルに装備されている必要があるということになります。

ケント [1]は、MDE に必要な範囲の分類を さらに 2 つ定義しています。1 つ目の分類には、対象となるさまざまな範囲があります。対象となる 1 つ目の範囲は、モデルが属する主題領域に基づいたモデルの区別から生じるものです。システムのユーザーが異なればシステムの見方が変わるため、システムの機能のサブセットを重視する場合があります。たとえば、システムの顧客に対処する部分や注文の処理に関係する部分などです。対象となる 2 つ目の範囲には、システムのさまざまな側面があります。たとえば、情報・データ、プレゼンテーション、並行処理制御、セキュリティ、配信、エラー処理などです。

範囲の 2 つ目の分類は、システムの技術的な側面というよりも、組織的な側面と関連性が高いものです。この分類の範囲には、出所、（バージョン・構成制御の）バージョン、場所（システム開発がさまざまな場所で分散的に行われる場合）、利害関係者（ビジネスの専門家やプログラマーなど）などがあります [1]。

ソフトウェアの開発プロジェクトでは、特定のプロジェクトの重要範囲を決定する必要があります。ほとんどのプロジェクトで、出所やバージョニングが重要になりますが、どの主題領域が重要な役割を果たすのか、システムのどの側面が重要なのかなど、ほかの範囲の重要ポイントも明確にする必要があります。これ以外の重要な決定項目は、プロセスで使う抽象化のレベルと関与している（理解可能なモデルを作成する必要がある）利害関係者です。ソフトウェア開発プロセスにおいてモデルを構築する際、それぞれのモデルを範囲の交点に設置することができます。交点におけるさまざまな範囲は、その特定のモデルに対するモデリング言語を選択する際に重要な役割を果たします。たとえば、モデリング言語は、主題領域、利害関係者、抽象化のレベルの影響を受けます。この場合は、特定の主題領域や特定の利害関係者に合わせた、適切なレベルの抽象化を備えたドメイン固有言語（DSL）を設計することができます。

したがって、MDE アプローチでは、複数の DSL を定め、それらを組み合わせて企業アプリケーションを記述する必要があります。これらの DSL を使ってモデルを定義すると、さまざまな言語で定義された複数の結合モデルが作成されます。変換プロセスを使って、このモデルを組み合わせ、実行可能にする必要があります。Mendix(リンク) では、たとえば対象となる主題範囲を使って、ソリューションをさまざまなモジュール（CRM、HRM、受注、顧客ポータルなど）に分割しています。それぞれのモジュールは、対象となる側面の範囲に応じて、さまざまなモデルに分割されます。私たちは以下の DSL を使って、モデルを記述しています。:

• ビジネスオブジェクト DSL
• リッチインターネットフォーム DSL
• マイクフロー DSL
• ビジネス規則 DSL
• サービス DSL
• セキュリティ DSL

マイクロフローとはどのようなフローなのかと疑問に思われた方は、Architecture requirements for Service-Oriented Business Applications（サービス指向のビジネスアプリケーションのアーキテクチャ要件）(リンク)を参照してください。この記事には、サービスを実装するのに必要なさまざまなフローを含め、SOBA に必要なプログラミングモデルについて書かれています。

モデルの数によっては、モデルを作成、構成、変換する順番を記述する変換プロセスは非常に複雑になる場合があります。さまざまなシナリオがあり(リンク)、それらを組み合わせてエンジニアリングプロセスを構築することができます。

3.     新しいアーチファクトの作成を重視している

理由その 1 で、変化は MDE の重要な（そして一般的には、ないがしろにされている）側面であることを確認しました。一般的に、ソフトウェアシステムは使っているうちに変化します。これをソフトウェアシステムの進化と呼びます。文献では、これはメンテナンスとも呼ばれ、以下の 3 つの理由が伴います [4]。

• 補正メンテナンスは、処理、パフォーマンス、実行のエラーを解決するために加えられたシステム内の変更を指す。
• 適応メンテナンスは、ビジネス環境や技術環境の変化によって引き起こされたソフトウェアシステムの変化である。
• 完了メンテナンスを使って、システムの質（処理の非効率性、パフォーマンスの強化など）と保守性を向上させる。

原則的には、付加進化、システムコンポーネントの取り替え、減法進化といった 3 つの進化シナリオがあります [5]。この 3 つのシナリオは、システムコンポーネントのライフタイムを表しています。追加したシステムコンポーネントは、取り除かれるまでは途中で変化する可能性があるということです。

付加進化のシナリオでは、既存のソフトウェアシステムに新しいシステムコンポーネントが付加されます。モデル駆動工学を利用する際に考えられるシナリオを図 1 に示します。t1 の時点に、初期システムを示します。t2 の時点で、ソースモデル S1 が付加され、それがモデル S とともに 1 つのソースモデル S’ になったあと、新しいターゲットモデル T’ に変換されます。t3 の時点では、既存のシステム T’ にターゲットモデル T1 が付加され、新しいシステム T’’ ができあがります。

図 1: 新しいモデルを付加することによる変換パターンにおける付加による変化の実行: t1 の時点は初期状態、t2 の時点はソースモデル S1 の付加、t3 の時点は対象モデル T1 の付加を示す [5]。

図 1 には、構成別に付加のみを図示しました。もちろん、構成や変換を利用したソースモデル、ターゲットモデル、変換モデルの付加に基づいたシナリオをもっと多く定義することも可能です。

補正メンテナンスや完了メンテナンスの場合、ほとんどのケースで、システムコンポーネントをそのコンポーネントの別バージョンに取り替えるという結果になります。コンポーネントの変更は、ソースモデルを適合させることによって実現できますが、変換の定義を変更したり、対象モデルを直接変更したりすることでも実現できます。ソースモデルを変更することでコンポーネントを変更する場合は、最初の実行後に最初から変換を再実行することに対応した、処理状態を把握しない変換の場合とは異なり、いわゆる変更伝達変換が必要になることがあります。変更伝達変換では、ソースモデルから既存のターゲットモデルへの、非破壊的な変更伝達に対応しています [6]。変更伝達変換を利用することによって、実行時または実行時データの保存によってコンポーネントを取り替えることが可能になります。このような変換の例によって、データを失うことなくオブジェクトモデルを基盤としたデータベース（対象モデル）の構造が更新されています。これは、もちろん、すべての変更に対して可能というわけではありません。

また、変化伝達言語を利用して、さまざまなモデル間の同期をとることも可能です。すでに述べたように、ソフトウェアアーチファクトはさまざまなモデルを使ってモデリングする必要があります。これらのモデルや DSL では、しっかり定義されたインターフェイスを通じてお互いの要素を使います（たとえば、マイクロフローでは、ビジネスオブジェクトモデルの要素を使います）。モデルの 1 つに変更がある場合（要素が変えられる、または削除される場合）、参照するモデルに変更内容を伝える必要があります。アラネンとポレス [7]は、伝達可能な変更の分類のいくつかについて説明しています。

図 2: 変更伝達を図示化したもの [8]

問題領域をもう少しわかりやすくするために、図 2 の例を見てみましょう。変更伝達モデル変換の以下に示す部分を図示化しています。

a)      初期モデルが作成される

b)      モデルを対象に検索が行われ、変換の対象となる適切な要素を明確にする

c)       ソースモデルがターゲットモデルに変換される

d)      追跡情報を記録して、変換によってターゲットモデルのどの要素がソースモデルの要素に関連付けられるのかを明確にする

e)      ソースモデルを変更する

f)       変換に関わっているソースモデルの要素の更新を検出し、関連する操作を実行してターゲットモデルの対応する要素を（非破壊的に）変更する

この単純な例は、変更伝達変換の基本概念を示していますが、どのような特定の手法においても考慮すべき多くの決定や課題については示していません。それらの中で、最も重要なものを以下に示します [6]。

• 伝達のチェックまたは更新。最低でも、ターゲットモデルに変更を加えて整合性を持たせる必要がある場合は、ユーザーに伝える手法を使う必要があります。また、これとは正反対に、どのような変更を行うかをユーザーに伝えずにターゲットモデルを強制的に更新する手法を使う場合もあります。
• 手動または自動の変更操作。変更を手動でターゲットモデルに適用できる手法、または手動のヘルプなしで任意の変更を伝達できる手法。
• 一括伝達または即時伝達。変更の一括伝達では、ユーザーが明示的に要求した場合のみ、ソースモデルの変更を確認してターゲットモデルに伝達します。変更の即時伝達では、ソースモデルに変更が加えられたら即座にターゲットモデルに変更を加えます。
• ソースモデルとターゲットモデルの関連付け。どのような変更伝達手法でも、特定の規則で作成したソースモデルとターゲットモデルを関連付けるメカニズムが必要です。
• 削除する要素の検出。ソースモデルの要素を削除すると、ターゲットモデルの該当要素も削除されるようにする必要があります（ただし、削除しても、手動の変更の非破壊性の性質が維持される必要があります）。
• 伝達の正確性のチェックと競合の解消。ソースモデルに行った変更の一部が、ターゲットモデルに手動で加えた変更と矛盾する場合があります。このような矛盾を処理する方法は、アプローチによって異なる場合があります。

Mendix(リンク) では、変更伝達変換を 2 種類の方法で使用しています。1 つ目のケースは、データを失うことなく、ビジネスオブジェクト DSL（ソースモデル）に基づいてデータベース（ターゲットモデル）の構造を更新する方法です。私たちは、追跡を利用してソース要素とターゲット要素を関連付け、変更をトラッキングします。また、ビジネスオブジェクト DSL における要素の作成と削除を記録して、このような変更に対してもデータベースの構造を更新できるようにしています。

2つ目のケースでは、変更伝達変換を利用して、異なるモデルの同期をとります。Mendix Business Modeler(リンク) では、要素に変更が加えられると、自動的にモデルの同期がとられます。ほかの DSL の要素や参照に影響を与える変更も自動的に伝達されます。手動で変更したために変更が伝達できない場合は、モデリング環境が整合性エラーを報告し、手動で変更を行う必要がある箇所に直接ユーザーを導きます。

一般的には、MDE ソリューションでは変更の伝達に注意が払われることがないため、上述したように複雑な問題が発生し、モデル駆動工学のすべての目的を達成することができないと言えます。

4.     汎用言語が使われている

MDE の分野で現在行われている取り組みの多くでは、UML のような GPL が利用されています。しかし、これには、（モデリング）言語を使う人がその GPL で利用できるすべての概念を覚えなければならないというマイナスポイントがあります。したがって、MDE の目的を達成して、人員の変化に対するソフトウェアアーチファクトの反応性を低くすることができません（理由その 1 を参照）。以下の理由で、MDE では DSL を使うべきだと私は考えます。

• 使用目的に合わせて、（モデリング）言語を完全にカスタマイズすることができる。
• ユーザーは自分が知っている概念で作業を行う。DSL は、縦方向（特定のビジネス領域に合わせる）にも横方向（技術的な分野に合わせる）にも適用できる。
• ユーザーは必要なものだけを手に入れる。ユーザーは作業対象の領域に関連する限られた概念だけを覚えればよい。
• さらにユーザーがモデルを簡単な方法で定義できるようにする特定の DSL の使用に合わせてツールをカスタマイズできる。

DSL を利用したソフトウェア開発プロジェクトの重要なポイントは、適切な人員が適切な状況で適切な DSL を使用することです。

5.     ユーザー定義のドメイン固有言語が使われている

DSL を使うことにはデメリットもありますが、その日の趣きに基づいた DSL を作るだけで、DSL が一般化します。DSL の一般化を完全に避けることはできませんが、メタモデルを使って DSL を GPL の特定のインスタンス化として定義することによって、一般化の問題を小さくすることができると思います。これは、本当のメタモデルではありませんが、UML で固定観念を使うことは、GPL に基づいた特定の目的に合わせてモデル言語を定義する手法の好例です。

メタモデリングの概念は一般的に、言語定義の手段として使われます。アトキンソンとキューネは、この概念を言語メタモデリングと呼んでいます [2]。しかし、彼らによると、メタモデリングに関するこの「従来の」考え方は、2 つの重要な範囲のうちの 1 つしかカバーしていないということです。言語のインスタンス化以外にも、生徒はエンティティのインスタンスであるように、生徒は人のインスタンスでもあると定義する存在論的インスタンス化関係も存在します [9]。言語メタモデリングでは、生徒と人は同じ層にありますが、存在論的な考え方では、人はメタ層にあることになります。アトキンソンとキューネは、これを存在論的メタモデリングと呼んでいます。

GPL に基づいた DSL の定義を行うには、言語メタモデリングと存在論的メタモデリングの両方が必要です。両方のメタモデリングを組み合わせてメタモデリング階層を構築し、実際のモデル層のメタモデルを定義する必要があります。

図 3: 考えられるメタモデル階層

メタモデル階層の例を図 3 に、このような階層の考えられる要素を図 4 に示します。

図 4: メタモデル階層の要素例

言語メタモデルと存在論的メタモデルやドメインに固有のプロセスモデリング言語の定義例などの詳細については、Combining GPL’s and DSL’s for MDE（GPL と DSL を組み合わせて MDE に対応する）(リンク)を参照してください。

結論: DSL の一般化を完全に回避することはできないが、GPL に基づいて DSL を定義することによって相互運用が可能になり、同じ方法で実行可能にすることも可能だと思います。

6.     完全実行可能ではないモデル変換が使われている

ソフトウェアをモデル駆動方式で開発するのはよいことですが、私たちは高度なデザインを作り上げることによってソフトウェア開発の初期からモデル駆動方式によるソフトウェア開発を行っています。基本的な変化は、モデルは単なるプログラマー用のマニュアルとして使われなくなる代わりに、ソフトウェアの開発の原動力として直接使えるようになるということです。MDE のもう 1 つの価値は、高レベルのモデルから低レベルの（実装）モデルへの自動的な変換に起因したものでなければなりません。

センダールとコザクジンスキー [10]に従って、モデル駆動ソフトウェア開発に対応したモデル変換言語には、以下の要件を満たしたものが推奨されます。

1. 実行可能である。
2. 効率的な方法で実装できる。
3. 既存のモデルを修正したり、まったく新しいモデルを作成したりするような変換に対して、完全な表現力を有しながら一義的である。
4. 正確、簡潔、明確な記述で、開発担当者の生産性を向上できる。
   1. ソースモデルの選択規則と対象モデルの生成規則の記述を明確に区別できるような言語
   2. 文字よりも図表を使って表現したほうが概念を簡潔で直感的に理解できる場合は、図表構造を提供できる言語
   3. 状況から直感的に説明できる概念やメカニズムを暗黙的にすることによって、記述可能にできる言語
5. 変換を組み合わせて複合的な変換を形成する手段を提供し、少なくとも、変換の順序付け、条件付選択、繰り返しのための演算子を提供できる。
6. 変換が実行可能になる条件を定義する手段を提供できる。

ひとことで言うと、モデル変換が実行可能であり、簡単に定義できることが非常に重要であると言えます。

7.     モデルがテストされていない

MDE 手法の最大の落とし穴の 1 つは、テストへの厄介な対応とモデルレベルでのソフトウェアアーチファクトのデバッグです。ただし、以下に示す理由で、MDE は質の高いエンジニアリングに向いています。

• モデルは重要なソフトウェアアーチファクトであるため、モデルの質によって、そのモデルから作成されるアーチファクトの質が決まる。
• ツールによって、整合性のチェック、モデルのチェックやシミュレーションなど、モデルのさまざまな特性を分析したり監視したりできる。
• モデルを使って、モデルをベースにしたテストの入力として使える。モデルをベースとしたテストには、テストの作成、実行、モデルを使った評価が伴う。

ただし、モデルの質には特に注意を払う必要があります。MDE で使うモデルの主要な 2 つの品質基準は、変換性と保守性です [11]。ソルハイムとネプルは、これらの基準をいくつかのほかの基準に分けています。変換性に対する品質基準を表 1 に、保守性に対する品質基準を表 2 に示します。

表 1: モデルの変換性の品質基準

表 2: モデルの保守性の品質基準

表 1 で説明したように、品質の一部はモデルをメタモデルと照合することによって確保できます。それ以外にも、モデルや結果として生じたソフトウェアアーチファクトの品質を確保するための手法としてモデルの検証、モデルのチェック、モデルをベースにしたテスト(リンク)を利用することもできます。

8.     設備が不十分である

MDE 手法がうまく機能しない（しなくなる）最後の理由は、ツールの作成に対する対応が不十分であるということです。モデルを持つことのメリットを最大化したり、そのメリットを維持するために必要な作業を最小化したりするためには、ツールの作成は欠かすことができないものです [1]。現在のプログラミング言語はすべて、統合開発環境（IDE）でサポートされているため、コードの記述や保守の厄介さが低減しています。開発ツールの作成をサポートしていない MDE 手法では、私たちが必要としているメリットが実現しません。

モデルを定義するための開発環境は、使われているドメイン固有言語に合わせて完全にカスタマイズするべきです。ツールの作成には以下のものを組み入れる必要があります。

• モデルに対する適格性の制約をチェックしたり実現したりするためのツール。つまり、タイプ・静的な意味論のチェック。
• モデルのインスタンス処理のサポート。モデルに対するインスタンスの妥当性の確認、モデルからのインスタンスの生成、ユーザーインターフェイスの有無、インスタンスからのモデルの（部分的な）生成など。
• モデル間のマッピングをサポートするツール。対象モデルからのソースモデルの生成とモデル間の変更同期の両方が適切なツーリングにサポートされている必要がある。
• 言語の動的な拡張とそのコード生成モジュールの概念。

これらの要素以外に、ツールの作成では複数の DSL をサポートして、これらを組み合わせてシステム全体を記述する必要があります。これらの DSL は結合されており、お互いの要素を使える必要があります。自動完了、構文カラーリング、リファクタリングオプション（名前の変更、要素の移動など）など、開発担当者が使い慣れているその他の機能も、ソフトウェア工学ツールに必要な要素です。

理由その 7 で述べたように、テストは MDE 手法の重要な側面です。MDE ツールは、コンパイラーのような動作にエラーメッセージを付与することによって、少なくともこれをサポートする必要があります。これらのエラーメッセージによってモデル内の問題を明確にする必要がありますが、これは生成されたソースコード内に限定したものではありません。

最近の調査「ユーザーの選択 IDE - 2008」(リンク)で、1,200 人以上の開発担当者が、デバッガーが IDE の最も重要な属性であると結論付けています。デバッガーの最も基本的な機能は、アプリケーションと一緒に実行し、プログラムがクラッシュすると問題のある行で停止し、開発担当者が問題を簡単に特定、修正できるようにすることです。MDE の場合は、デバッガーで問題を引き起こしたモデル要素を特定する必要があります。また、デバッガーは、それぞれのモデル要素や活動を利用した単一ステップ、各モデルのブレークポイントの設定や条件付ブレークポイントの設定といった機能もサポートしている必要があります。

ツールは、たとえば、どのようなモデルをいつ作成するべきかに関して、開発担当者に指示を与えるといった方法で、ソフトウェア開発プロセスを管理できるものである必要があります。手法に従って難しい手順を案内するウィザードや、言語の特定要素の定義を案内するウィザードも提供できるようなツールが必要です。このように、MDE 手法に、その手法に従ってユーザーに最大限の指示を与えることができるサポートツールを組み合わせると、簡単に覚えたり、使ったりすることができます。

大事なことを 1 つ言い忘れていました。それは、MDE 手法のツール作成では大規模なソフトウェアプロジェクトの開発の共同作業をサポートする必要があるということです。したがって、バージョン管理や分散作業のサポートが重要です。

結論

これまで、モデル駆動手法で期待どおりの結果を実現できない 8 つの理由について考えてきました。モデル駆動ソフトウェア開発に取り組むことを断念させることが私の目的ではありません。単に、モデル駆動ソフトウェア開発の複雑さを示し、考えを分かち合うことによって、皆さんが MDE の複雑さを克服できる手助けができればと考えただけです。1 つの記事の範囲内ですべてのポイントを詳細に掘り下げることはできませんが、基本的な部分を理解する上で、重要なポイントは十分にわかりやすく説明できたと思います。

皆さんのコメントとモデル駆動手法に関する実体験を是非お聞かせください！

参考文献

[1] S. Kent 著『Model Driven Engineering』（IFM2002、LNCS 2335、2002 の会報、286 ～ 298 ページ）

[2] C. Atkinson と T. K?hne の共著『Model-Driven Development: A Metamodeking Foundation』（IEEE Softw. 第 20 巻、No. 5、36 ～ 41 ページ、2002）

[3] OMG（2003 年 6 月）オブジェクトマネージメントグループ [オンライン]. http://www.omg.org/mda

[4] E. B. Swanson 著『The dimensions of maintenance』（1976 年サンフランシスコに於けるソフトウェアエンジニアリングに関する第 2 回国際会議の議事録、492 ～ 497 ページ）

[5] I. Kurtev 著『Adaptability of Model Transformations』（Twente, Enschede 大学、博士号論文、2005）

[6] L. Tratt 著『A change propagating model transformation language』（Journal of Object Technology第 7 巻、No. 3、107 ～ 126 ページ、2008 年 3 月）

[7] M. Alanen と I. Porres 共著『Change Propagation in a Model-Driven Development Tool』（UML 2004 の WiSME のパート、2004 年）

[8] L. Tratt 著『Model transformations and tool integration』（Journal of Software and Systems Modelling 第 4 巻、No. 2、112 ～ 122 ページ、2005 年）

[9] D. Karagiannis と P. H?fferer との共著『Metamodels in action: an overview』（Filipe, J.、Shishkov, B.、Helfert, M. eds.、ICSOFT 2006 ? 2006 年、セトゥーバルにおけるソフトウェアとデータテクノロジに関する第 1 回国際会議）

[10] S. Sendall とW. Kozaczynski との共著『Model Transformation - the Heart and Soul of Model-Driven Software Development』（IEEE Software 第 20 巻、No. 5、42 ～ 45 ページ、2003 年）

[11] I. Solheim と T. Neple との共著『Model Quality in the Context of Model-Driven Development』（2006 年、キプロスのパポスにおけるモデル駆動の企業情報システムに関する第 2 回国際ワークショップ（MEEIS 2006）の議事録、27 ～ 35 ページ）

原文はこちらです：http://www.infoq.com/articles/8-reasons-why-MDE-fails
（このArticleは2008年7月28日に原文が掲載されました）