これまでBizTalkやSoftware Factories、VSX Toolsでモデリングアーキテクチャに多大な投資をしてきたMicrosoftが、同社の次世代モデリングアーキテクチャ「Oslo」(参考記事・英語)のCTPリリースの準備の最中(リンク)、Object Management Group（OMG）へ加盟すると先日発表した。
サーバー&ツールビジネス担当のシニア バイスプレジデントBob Mugliaは、Osloプロジェクトで(リンク)Microsoftは、
システム動作そのものをモデル駆動にすべく、システム深部にモデルを組み入れることを目指している、と説明する。
OMGが管理しているのは、モデリングアーキテクチャの様々な要素、汎用モデリング言語のUML(参考記事・英語)、OMGのモデル駆動型アーキテクチャ・アプローチのMDA(リンク)、BPMN（Business Process Modeling Notation＝ビジネスプロセス・モデリング表記法(リンク)）、業界の独自モデルを定義する、多数の業界縦割りグループ（DTF＝Domain Task Force＝応用技術委員会に属する技術部会(リンク)）である。
最近Microsoftは、Visual Studio Team Systemの次期リリース「Rosario」(リンク)で、UML 2.1のダイアグラムを5つサポートする(リンク)と発表した。MicrosoftがUMLへの興味を新たにしたことで、UMLとDSLの関係に関する論争に火がついた。Cameron Skinner氏が説明する。
記事の中には、MicrosoftがDSLから離れ、UMLに向かっていると読者が受け取るように書かれたものも見られます。まったくの間違いです！ここで時間をとって事実を明確にしてから、より広い視野に立って対話を始めたいと思います。
Skinner氏が強調した点は以下のとおりである。
MicrosoftはDSL戦略に最大の努力を払っており、とりわけVS SDK(リンク)の一部として出荷されるDSLツールキット(リンク)には全力投球しています。実際、私たちのUMLデザイナーは、DSLツールキットの上に構築されているのです。
両方のモデリングアプローチをサポートすることにより、開発者もアーキテクトも「仕事に合ったツール」を選べます。実装の決定を伴わない標準記法を使ってアーキテクチャの分析・設計をしたい方々は、UMLダイアグラムをお使いください。UMLは、より高レベルの概念の記述や、さらに幅広いコミュニケーションの促進に必要な概念を記述するために利用可能な初期用語集の定義にうってつけです。実装の戦略を決定済みで、その選択した実装を記述する上で、UMLの大ざっぱな特質に煩わされたくない方々は、DSLをお使いください。
Skinner氏は次のように結論づけている。
2つのアプローチをすっきり区別しようと奮闘しているのですが、それと同時に、UMLからDSLへ、そしてDSLからUMLへ、いかにして情報を渡すかについての理解も継続させようとしているのです。
ですから「DSL対UML」の話ではないのです。「DSL＋UML」なのです。そしてもっと重要なことは、顧客の現在位置で顧客に相対し、顧客が行かなければならない所へ到達できるツールを提供することなのです。
Johan den Haan氏がこのトピックについて最近意見を述べている(リンク)。
聞き覚えがありませんか。MDAの概念(リンク)と比較してみてください！Skinner氏が言っているのは原則的に、UMLをプラットフォーム独立モデル（PIM＝Platform Independent Model）を定義する言語として使うべきで、DSLはプラットフォーム特化モデル（PSM＝Platform Specific Model）を定義する言語として使うべき、ということです。
den Haan氏はこうも言っている。
Steven Kelly氏はこのアプローチを好まず(リンク)、こう言っています。「ですから、DSLは問題ドメインに特定的であるべきなのに、問題ドメインではなく、ソリューションドメインに特定的です。DSLには、Microsoftの特定フレームワークあるいはライブラリの実装概念があるのです」。Kellyはつけ加えてこう断言しています。「このようにしてDSLの前にUMLを持ってくることは、馬の前に荷車を持ってくる以上のことを意味します。荷車の中に馬をぎゅうぎゅうに押し込んで、自分で引っ張り出すことを意味するのです」
しかし、den Haan氏は2つの理由からOMGのMDAには懐疑的である。
第一に、UMLを言語として使っていますが、言語は規模が大きく、複雑であり、そのため習得と使用が困難です。第二に、1つのモデリング次元(リンク)（抽象/具体）だけに焦点を合わせています。
den Haan氏の説明によると、問題ドメインとソリューションドメインに照準を定めるDSLには2つのタイプがある。それぞれをSubject-Area DSL（問題領域DSL）とFramework-Based DSL（フレームワークに基づいたDSL）と呼んでいる。しかしながら、den Haan氏は以下のように警告している。
Subject Area DSLの抽象度合いは実際高いので、設計と実装の費用効果が高いなら、使うべきでしょう。でも、次のことを覚えておいてください。ユーザーコミュニティの規模に応じて、トレーニング用資料の開発、言語サポート、標準化、維持管理が深刻かつ手間のかかる問題となる可能性があります。
den Haan氏は以下のようにまとめている。
Skinner氏が提示した方法でUMLとDSLを使うのは、非常にいい考えというわけではない、という点において、私は断然Kelly氏（前述の引用を参照のこと）に賛成です。
そして、こうつけ加えている。
ジェネリック/共通の標準を使えば、DSLを定義することや、DSLを実行可能にすること、さらにはDSLの（おそらくは）ポータブル化にさえ役立つと思います。DSLで利用されることになるジェネリック概念（すなわちオントロジー）の定義に、あらゆる種類のモデル変換を使うのではなく、普通のメタ−（メタ−）モデルを使うことによって役立つと思います。
InfoQはさらに、Microsoftのプラットフォーム アーキテクチャ チームの上級ディレクターを務めるJack Greenfield氏に話を聞いた。Greenfield氏はSoftware Factoriesに関する2冊目の本『Software Factories Applied』（Software Factoriesの適用）を準備中である。Greenfield氏の説明は以下のとおり。
ドメイン特化言語（DSL）は、特定の概念やタスク、プラットフォームに目標を定める言語です。汎用言語（GPL）は対照的に、多種多様な概念、タスク、プラットフォームの記述を意図しています。言語のタイプ毎に価値があるのです。
Greenfield氏はつけ加えて次のように述べている。
GPLは主に、決まった種類の問題に取り組む場合の初期段階で役に立ち、問題のドメインがまだはっきり理解されていないか、急速に変化しているような場合です。GPLの力は、多数の異なる問題ドメインを記述する能力を源としています。しかしながら、多種多様な問題ドメインに広く適用できることを狙ったものですから、一般にGPLでは多種多様な解釈が認められ、したがって、情報の明確性という点では精度が限定されたものになってしまいます。
DSLは主に、決まった種類の問題に取り組む場合の後期の段階で役に立ち、問題のドメインがはっきり理解されているか、変化が緩慢な場合です。特定の問題ドメインの記述において、最も有利な手段を提供することを狙っているため、DSLは一般に解釈の許容範囲が狭く、高い精度で情報をとらえます。実際、たいていのDSLには明確なセマンティクスが組み込まれているため、特定のプログラミングや仕様言語における有効コードの生成では、信頼して使用できます。しかし、この特定性が理由で、所定のDSLの適否は概して限定されています。
Greenfield氏は以下のように結論づけている。
実際は、GPLとDSLの区別は白と黒のように明確ではありません。換言すれば、汎用言語からドメイン特化言語への移行は必ずしも階段関数ではないのです。GPLでは拡張メカニズム（たとえばUMLのステレオタイプ）を使用して、通常はある程度カスタマイズでき、モデルが取り込む目標ドメインに関する情報の精度を改善できます。さらに、GPLツールを通常は拡張して、（たとえば、カスタムのコードジェネレータを書くことによって）言語拡張を活用できます。しかし、ある時点で、ビューポイントの表現要件とGPLの表現能力の分離が大きくなりすぎるのです。そうすると、必要とされる精度をGPLを使って実現することが難しくなります。その時点を越えると、言語拡張はユーザーの手に余る傾向にあり、またツール拡張は、GPLメタモデルと基礎をなしているツールアーキテクチャの制約の中で、好ましい振る舞いを提供するのが困難になってきます。そうなると、ビューポイントデザイナーはDSLを定義した方がうまくいくかもしれません。
UMLは言語ではなく表記になってきているのだろうか。モデル駆動型工学の概念を広く採用し始める時期にきているのだろうか。皆さんの見解は？
原文はこちらです：