この記事はJohan den Haan氏の記事「DSL and MDE, necessary assets for Model-Driven approaches - by Johan Den Haan」を、氏の許可を得て翻訳したものです。（原文公開日：2008年8月11日）
私はこれまで、モデル駆動エンジニアリング（MDE）について、多くの記事を書いてきました。MDEはモデル駆動アーキテクチャ（MDA）よりも広い概念で、モデリングのさまざまな切り口とソフトウェアエンジニアリングプロセスの考え方を付け加えるものです。MDAが注力するのは技術的な可変性です。これは、プラットフォームから独立したモデルとそうでないモデルとを区別し、こうしたモデル間での相互変換を定義することで達成されます。一方、MDEが注力するのは、アプリケーションドメインの可変性です。これは、主題領域（"subject area"）に関するモデリングの切り口と、アーキテクチャ的アスペクトをつけ加えることで実現されます。
モデル駆動ソフトウエア開発の文脈において、ドメイン特化言語（DSL:Domain-Specific Language）という用語がしばしば言及されます。これは時としてMDAに対する代理品である場合もあります。私は以前、メタモデルを使ったDSLの実装に焦点を合わせた記事を書いており、そこでMDEとDSLの組み合わせという主題には多少触れました。この記事では、MDEとDSLが相補的であり、モデル駆動アプローチを成功させるには両方が必要であることを示したいと思います。
DSLと結びつけるためのフレームワークとしてのMDE
モデル駆動エンジニアリング（MDE）は、モデル駆動アーキテクチャ（MDA）において定義される、抽象／具象という切り口に加え、それ以外に複数の切り口を定義します。
Kent [1]はMDEにおいて追加で必要となる切り口のカテゴリを２つ定義しました。最初のカテゴリは関心事についてのさまざまな切り口を含むものです。これは異なる主題領域や、異なるシステムアスペクトのようなものです。２つめのカテゴリはシステムの技術的な側面にはあまり関連しません。かわりに、組織的な問題に関わります。例えば、作成者やバージョン（バージョンやコンフィグレーションコントロールに見られるようなもの）、位置（システム開発が複数の場所に分散している場合には）、ステークホルダ（ビジネスエキスパートやプログラマ）などが挙げられます。
ソフトウエア開発プロジェクトにおいては、そのプロジェクトにとっての重要な切り口が何かを決定する必要があります。ほとんどのプロジェクトにおいて、作成者やバージョン管理は重要になるでしょう。しかし他の切り口は興味のポイントを特定する必要があります。どの主題領域が影響を与え、システムのどのアスペクトが重要なのか、といったようにです。重要な決定はもう一つあります。それはプロセスにおいて用いられる抽象化のレベルです。ここにはステークホルダも関与します（だからこそ、理解可能なモデルを作らなければならないのですが）。ソフトウェア開発プロセスにおいてモデルを構築する際に、各モデルは各切り口が交わる場所におかれる可能性があります。
議論を具体的にするため、切り口の例と考えられる値について、表１に示します。
| 切り口 | 考えられる値 |
| 抽象／具象 |
CIM, PIM, PSM |
| 主題領域 |
受注、カスタマポータル、バックエンドの管理、など |
| アスペクト |
データ、プレゼンテーション、セキュリティ、業務ルール、ワークフロー、など |
| ステークホルダ |
対象読者：ドメインエキスパート、プログラマ |
表１に示された切り口に対するモデルの例は以下のようになります。
- ソフトウェアにおいて受注を受け持つ場所のワークフローに関する、処理から独立したモデル（CIM:Computation Independent Model）。ドメインエキスパート向け。
- ソフトウェアにおいてバックエンドで管理を行う場所のデータに関する、プラットフォームから独立したモデル（PIM:Platform Independent Model）。ドメインエキスパート向け。
- ソフトウェアにおいてカスタマポータルのセキュリティに関する、プラットフォームに特化したモデル（"PSM:Platform Specific Model"）。プログラマ向け。
交点における様々な切り口は、特定のモデルに対するモデリング言語を選択する上で重要な役割を果たします。例えば、モデリング言語は主題領域、ステークホルダ、抽象化のレベルによって影響を受けます。こうした言語は、主にドメイン特化言語（"DSL"）として提示されます。
しかし、モデリング言語のためのDSLだからと言って、視覚的であったり、グラフィカルであったりする必要はありません。モデルは現実の抽象的な表象にすぎず、テキスト形式のDSLを用いて表現することもできるのです。
要約すれば、MDEの方法論は諸々の切り口とその交点に関するフレームワークを定義し、それによって、あるソフトウェアアプリケーションを記述するために必要な、別々のモデルを定義しているのです。このことは、多少なりとも形式的な仕方で、求められるDSLについて議論する機会を与えてくれます。これは重要なことですが、MDEの方法論もまたソフトウェアエンジニアリングとメンテナンスのプロセスについて説明しています。それによって、モデルが生み出される順序、それぞれが（可能であれば）どう変換されるのか、モデルを使って既存のソフトウェアシステムをどう変更するのかを定義します。
ドメイン特化言語
DSLは次のように定義されます [2]
DSLとは、プログラミング言語ないし実行可能な仕様記述言語であり、適切な記法と抽象化によって、特定の問題ドメインに集中した（多くの場合は、同時にそこに限定された）表現力を提供するものです。
言語がドメインに対してどこまで特化しているかは、程度の問題です。どんな言語も、その適用可能性に関する何らかのスコープを持っています。しかし、他と比べて焦点がより絞られているものもあります。一般的に、あるDSLが対象とすることができるドメインは、２種類に分けることができます。
- ナレッジドメイン：その分野において実践する人が理解できる一連の概念と用語法によって特徴づけられる知識ないし活動の領域。
- システムファミリー：類似した機能を持つ、一連のソフトウェアシステム。このドメインはナレッジドメインの特殊な形と考えることができる。
原則として、ナレッジドメインはMDEが持つアスペクトの切り口と比較することができます。一方、システムファミリードメインは主題領域の切り口と比較することができます。MDEの方法論を設計する一方で、どういう種類のDSLが定義されるべきかを決定するのは重要なことです。表１に示した切り口の例を思い出せば、切り口の各交点のため（つまり、各モデルのため）にDSLを定義することで、90の異なるDSLが作られることになります（つまり、抽象／具象という切り口で３つ値があり、主題領域で×3、アスペクトで×5、ステークホルダで×2）が、これではあまりに多すぎます。以下に続く考察は、必要なDSLを減らす上で考慮に入れることができます。
- 特定のプラットフォーム上で直接実行できるようにDSLを実装する。別のプラットフォーム上で実行できるようにするには、ジェネレータないしインタプリタを書き換えなければならない。これによって、抽象／具象の切り口が取り去られる。
- 既存の汎用言語によって拡張可能なようにDSLを作成する。それによってプログラマは知っている言語を使って必要なものを追加することができる。これによってステークホルダという切り口が取り去られる。
- アスペクトの次元に集中する。つまりDSLを各アスペクトに対して定義する。主題領域がきわめて特殊な場合のみ（例えば、特定の金融システムの一部）、そのためのDSLを定義する。
こうした提言を例に当てはめれば、DSLの数を90から5に減らすことができます。DSLが必要なのは、アスペクト、すなわちデータ、プレゼンテーション、セキュリティ、業務ルール、ワークフローなどに対してのみなのです。確かに、多くのモデルは定義しなければなりませんが、これは巨大なソフトウェアシステムでは普通のことであり、言語としては5つ用いれば良いのです。
なぜドメイン特化言語を使わなければならないのか？
言語は、ファンクションポイントを実装するために必要なコードの量を基準として比較することができます。これにより、自然言語やマシン語、アセンブリ言語のような低級言語から、特定のドメインを対象とした高級言語へと至る表ができあがります（SPRプログラミング言語表を参照）。汎用言語とDSLの違いは程度の問題ですが、DSLとして考えるべきはより焦点が絞られた言語、例えばBNF、HTML、SQLなどだと思います。
DSLは汎用言語に対して、いくつか重要な利点があります。[3]
- ドメイン特化抽象化：DSLはアプリケーションドメインの概念を直接表象するための抽象化をあらかじめ定義する。結果として、ドメインエキスパート自身もDSLプログラムを理解し、検証し、時には開発することもできる [2]。
- ドメイン特化シンタックス：DSLは与えられたドメインに対する自然な記法を提供し、汎用言語を使った時にしばしば発生するような構文上の混乱が回避される。
- ドメイン特化エラーチェック：DSLにより静的アナライザを構築することができるようになる。それによって汎用言語に対する類似のアナライザよりも多くのエラーを見つけることができ、ドメインエキスパートにより親しみ深い言語でそのエラーを報告することができるようになる。
- ドメイン特化最適化：DSLにより、ドメインに特化した知識に関する最適化されたコードベースを生成する機会が生まれる。これは、通常汎用言語のコンパイラからは得られないものである。
- ドメイン特化ツールサポート：DSLによって開発環境におけるツール面を改善する機会が生まれる。ここでいうツールには、エディタ、デバッガ、バージョンコントロールなどが含まれまる。DSLによって明確に把握されるドメイン特化の知識は、開発者に向けてより高度なツールを提供するのに使うことができる。
Deursen氏らは[2] DSLがドメインの知識を具現化するもので、会話と知識の再利用を可能にすると付け加えています。Eric Evans氏 [4] もソフトウェア開発における複雑さに取り組むためには、言葉が開発者にとってもドメインエキスパートにとっても理解できるものでなければならないということを強調しています。
しかし、DSLは諸刃の剣でもあります。DSLの開発は困難で、ドメイン開発と言語開発の両方に対する知見を持たなければなりません。しかし、これを両方持つ人はわずかです。それに加え、ユーザコミュニティの規模に応じて、トレーニング素材の発達程度、言語サポート、標準化、メンテナンスなどが深刻で時間のかかる問題になります。
結論
MDAのアプローチもDSLのアプローチもソフトウェア開発における抽象化のレベルを引き上げることに焦点を合わせていますが、両者は異なるアプローチか、もしくは正反対のアプローチと考えられています。私自身はMDAが豊かになり、私がMDEと定義するものになるべきだと考えています。その場合、MDEとDSLのアプローチは、モデル駆動のアプローチを補完する、不可欠なものとなります。
MDEは、ソフトウェアアプリケーションを記述するのに必要な種類のモデルを定義する上で必要であり、またエンジニアリングとメンテナンスのプロセスを定義する上でも必要です。これはつまり、モデルを使ってどうソフトウェアを構築し、どう保守するのかを定義するということです。
DSLのアプローチはモデルを表現するための言語を定義するのに必要です。MDEのモデリングという切り口を使うことで、DSLのアプローチのスコープがより正確に定義されるのです。これはきわめて重要です。DSL設計における最も大きな落とし穴の一つに、要件の変化に伴ってスコープがどんどん拡大し、その結果ある種の汎用言語に帰結するというものがあるからです。
註：MDAとMDEはしばしばグラフィカルなモデルと関連づけられますが、これはOMGがUML標準に注力しているためです。思うに、あるモデルを表現するのに使用する言語は、できる限りそのモデルに適合したものであるべきなのです。これはセマンティックにおいてだけでなく、シンタックスにおいてもそうです。したがって、テキスト形式のDSLもMDEの一部になれなければならないのですなるべきなのです。
[1] S. Kent, "Model driven engineering," in IFM '02: Proceedings of the Third International Conference on Integrated Formal Methods. London, UK: Springer-Verlag, 2002, pp. 286-298.[2] A. v. Deursen, P. Klint, and J. Visser, "Domain-specific languages: An annotated bibliography." ACM SIGPLAN Notices, vol. 35, no. 6, pp. 26-36, Jun. 2000.
[3] K. Czarnecki, "Overview of generative software development," in UPP, 2004, pp. 326-341.
[4] E. Evans, Domain Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.
