言語ワークベンチとモデル駆動アーキテクチャ

MDAの３つの陣営

これを議論する最初のステップは、MDAが実際には人によって明確に異なる、実際には互換性のない、多くのことを意味することを認識することです。Steve Cookは、そのバリエーションを互いに軽蔑し合う3つの陣営として説明しました。

• UML PIM：UMLを使用してプラットフォーム独立モデルを構築し、それをプラットフォーム固有モデルに変換（または詳細化）し、さらにコードに変換（または詳細化）します。
• MOF：UMLはまったく使用せず、OMGのメタオブジェクトファシリティ（MOF）を使用して言語と変換を定義します。
• 実行可能UML：UML（または拡張サブセット）のコンパイラを構築し、UMLをプログラミング言語として扱います。

これらの3つの陣営のうち、UML PIMとMOFの陣営は、ある程度、言語指向プログラミングに取り組んでいます。実行可能UML陣営は、実際には言語指向プログラミングに興味がありません。これは悪いことではありません。実際、実行可能UML陣営の一部は、さまざまなUML支持者の中で最も賢明に見えますが、ここでは議論とは関係ありません。

モデル駆動開発（MDD）陣営と呼ぶのが最適な別の陣営があります。彼らはOMG標準を真剣に受け止めていないため、実際にはMDAの一部ではありません。MDAはOMG標準です。混乱が生じるのは、人々がOMGのないMDDの取り組みを誤ってMDAと呼ぶことが多いためです。正しくは、MDAはOMG標準を使用したMDDであると言う方が適切です。（MDDについては後で説明します。）

これはすべて、言語ワークベンチにおけるMDAの役割を議論するためには、UML PIMとMOFの陣営を個別に検討する必要があることを意味します。なぜなら、彼らが言語指向プログラミングをどのように考えているかは大きく異なるからです。

UML PIM陣営

UML PIMスタイルのMDAは、UMLを「プラットフォーム独立モデル（PIM）」として使用してシステムを開発するというアイデアに基づいています。（ただし、実際にはプラットフォームに依存しています。）それが完了したら、（プラットフォーム固有モデル（PSM）を介して）コードに変換されます。このPIMはUMLであり、言語ワークベンチと同様に、情報の主要なソースはUMLメタモデルを使用して抽象表現に保存されます。編集（通常はCASEツールと呼ぶ勇気のないグラフィカルツールによって）は、UMLの図式標準を使用してレンダリングする投影エディターを介して行われます。

永続的な抽象表現と投影エディターを使用することは、確かに言語ワークベンチが行うことですが、言語ワークベンチとしての資格を得るには十分ではありません。言語ワークベンチであるためには、自分で新しい言語を定義し、それらを残りの部分に統合できる必要があります。UML PIMの方法は、UMLに組み込まれている言語拡張機能（ステレオタイプなど）を使用することです。

理論的には、UML PIMシステムが言語ワークベンチにならない理由は何もありません。問題は、UML PIMアプローチを使用することが言語ワークベンチを構築するための良い方法かどうかです。UMLを使用するアプローチは、UMLで定義された方法でUMLを拡張することであるため、UMLでDSLを使用することは、言語ワークベンチの統合された外部DSLではなく、内部DSLに似ています。この場合、言語ワークベンチトリオのスキーマ、エディター、ジェネレーターについて考える必要はありません。むしろ、ニーズを満たすのに十分なUMLの拡張がどれほど簡単かを検討します。

ここでの問題は、UMLが非常に複雑な言語であることです。拡張メカニズムも非常に複雑であり、実際にどのように機能するかは容易にわかりません。ツールがこれらの拡張機能をどの程度うまく操作できるかも明確ではありません。1つの特定のグレーゾーンは、生成のグレーゾーンです。UML図をコードとして解釈する方法を定義するための標準的な生成標準はありません。その結果、UMLには十分に正確なセマンティクスがありません。実際、UMLの支持者がUMLにはセマンティクスがないと誇らしげに言っているのを聞いたことがあります。

UMLメタモデルを使用してDSLスキーマを定義することもできますが、ここではUMLは多すぎても少なすぎても問題です。UMLには、スキーマの定義に不要な要素が多数含まれており、必要な構成要素が提供されているかどうかは明確ではありません。さらに、UMLはエディターまたはジェネレーターの定義に役立つものは何も提供していません。この目的のために、UMLメタモデルは、言語ワークベンチのコア要件をカバーしておらず、不要なものをたくさん追加する、大きく複雑な獣です。スピードボートとトラックの両方にハンドルが付いているからといって、トラックからスピードボートを作ろうと言うようなものです。

このアプローチに対する私の明らかな軽蔑にもかかわらず、UML PIMに基づいて言語ワークベンチの作業を行っている人々がいます。この作業に対するUMLの適合性についての私の評価に同意しない場合は、確かにこれらの人々をさらに調査する必要があります。

MOF陣営

メタオブジェクトファシリティは、UMLとは異なるOMG内のコミュニティから出てきており、MOFとUMLの陣営間の関係はしばしば冷淡でした。MOFの取り組みはOMGのCORBA作業とより密接に関連しており、MOFの推進力の多くはCORBAでの作業から得られました。

MOF標準は、メタモデルのメタモデルの標準です。そのため、UMLメタモデルを定義するための言語としてMOFを使用する場合があります。実際、UMLメタモデルのMOF互換性は、UML作業における長期にわたる問題でした。言語ワークベンチの観点から、MOFはDSLスキーマを定義するためのDSLに対応しています。MPS構造言語と同様です。MOFのドキュメントを見ると、MPS構造エディターで見たものと同様の機能が多数あることに気付くでしょう。そのため、本質的にMOFは（さらに別の）データモデリングメタモデルです。オブジェクトの履歴にも操作が提供されますが、（UMLとは異なり）動作モデリングメカニズムはありません。

MOFはUMLよりもはるかに小さく、本質的にUMLのクラス図部分のサブセットです。これはDSLスキーマに必要な種類のものです。MOFはこのタスクにUMLよりもはるかに適しています。実際、一部の人々は、MOFが抽象表現、または少なくとも言語ワークベンチのストレージ表現の優れたスキーマになるだろうと提案しています。

ただし、MOFは依然として完全には適合していません。操作定義はリモートオブジェクトの相互運用性（CORBA）のコンテキストでは理にかなっていますが、DSLスキーマの場合よりも理にかなっていません。そのため、DSLスキーマにMOFを使用することについての議論の多くは、それが実際にどれほど適切に適合しているかという問題に帰着します。MOFは不要な荷物を持っているのか、それとも重要な要素が欠けているのか？私はこれについて強い意見を持っていないので、私にとってこれは未解決の質問です。

むしろ重要なのは、MOFにはエディターまたはジェネレーターの定義について言及することが何もないことです。これらは言語ワークベンチの2つの重要な要素であるため、言語ワークベンチの観点からはMOFの大きな欠点です。OMGは、これを解決するためのQVT（クエリ、ビュー、変換）と呼ばれる標準を準備しています。原則として、QVTはジェネレーターのギャップを埋める可能性がありますが、まだ開発の初期段階です。

MOFが役立つ可能性があるのは、DSLスキーマの言語ワークベンチ間の交換メカニズムとしてです。そのため、そのコンテキストでは役立つ可能性がありますが、エディターとジェネレーターの部分が不足しているため、DSLを完全に交換するには不十分です。それでも、肥大化したUMLよりも言語ワークベンチにとってMDA標準の世界でより有用な部分であるように私には思えます。

MDAと標準化

言語ワークベンチをめぐる小さな論争の1つは、Microsoftがソフトウェアファクトリの取り組みでMDAを無視していることに対する批判でした。多くの人々は、これを悪のMicrosoftが独自ソリューションのためにコミュニティ標準を無視しているという、さらに別のケースと見なしました。

Intentional SoftwareとMPSもMDAを無視していることに気付くでしょう。どちらも、さまざまなMDA標準は実際に行っていることには実際には役に立たないと考えています。MicrosoftのMDAの知識はほとんどの人よりも優れており、ソフトウェアファクトリチームの多くのメンバーはUMLコミュニティのベテランメンバーです。彼らは同じ決定に達しました。MDA標準は、彼らがやりたいことには適していません。

この態度には非常に正当な理由があると私は思います。MDAのUML PIMとMOFの両方の陣営は、DSLスキーマの標準化のサポートを主張することしかできません。同様に重要なエディターとジェネレーターの要素は完全に無視されます。さらに、すべてが逆さまです。私の見解では、動作するテクノロジーの共通要素を理解したら、標準を定義します。言語ワークベンチはまだ未成熟すぎて標準化の準備ができていません。DSLスキーマの標準はMOFに基づいて構築できる、または少なくともMOFのように見えるのではないかと思います。これは、これらのスキーマがデータモデルであり、MOFのほとんどがデータモデリング標準であるためです。しかし、言語ワークベンチツールはまだ必要なものを理解しようとしているため、今すぐ標準をまとめようとすると、時期尚早な標準化のリスクがあります。

言語ワークベンチと見なされる可能性のあるMDAの何らかの形式のバナーの下でツールを構築している人々がいます。私はこれらを詳細に調べたことがありません。そのようなツールは、有用である可能性がありますが、UMLまたはMOFはそのようなツールの機能の一部にのみ役立ち、UMLは複雑さのために実際に有害になる可能性があるようです。

UML表記法が言語ワークベンチにとって役に立たないと言っているわけではありません。実際、ソフトウェアファクトリーに対する批判には、グラフィカル標準がUMLにより近い方が良いという点で妥当性があると思います。特定の種類の図では、UMLのような表記法は非常に理にかなっています。UML（少なくともスケッチモードでは）は、ある程度よく知られるようになりました。ツールは、UML標準に完全に準拠していなくても、UMLメタモデルを抽象表現として使用していなくても、理にかなっている場合はUMLのような図を使用すると思います。

モデル駆動開発

上記で述べたように、（主に）グラフィカルモデルを使用してソフトウェア開発を推進するというアイデアの多くは気に入っているが、OMG標準スタックにはそれほど熱心ではない人々がいます。このコミュニティは、モデル駆動開発（MDD）コミュニティと呼ばれるのが最適です。

彼らはMDAコミュニティと多くの共通点を共有しています。彼らの多くは、80年代と90年代のCASEツールへの取り組みから来ています。彼らはテキストモデルよりもグラフィカルモデルを好む傾向があります。プロジェクションエディターを通じて抽象表現を編集するというアイデアが好きです。彼らの多くは、人々が独自のグラフィカル言語を定義できるようにするというアイデアを支持しています。

これらの意味で、MDDと言語ワークベンチの間には多くの哲学的な合意があります。実際、言語ワークベンチへの関心は、プログラミング言語の人々とモデリングの人々の2つの背景から来ていると言えるでしょう。ソフトウェアファクトリーチームは、よりモデリングのバックグラウンドを持っています。

すべてのMDDフォロワーが、人々が独自の言語を簡単に定義して統合できることが重要であると考えているわけではありません。MDDの世界の多くの人々にとって重要なことは、一連のモデルに関してシステムを定義することです。複数のDSLを定義および統合する方法を考え出すことには、それほど優先順位がありません。ほとんどは重点の違いですが、それでもMDDと多くの言語指向プログラミングの取り組みとの間の重要な違いです。

MDDコミュニティの取り組みが言語ワークベンチを生み出すことができない特別な理由はありません。実際、（私にとって無関係な）グラフィカル言語とテキスト言語の議論を除けば、MDDと言語指向プログラミングはほとんどのものを共有しています。しかし、私が気づいた1つの傾向は、MDDの人々はしばしばジェネレーターに真剣に注意を払わないことです。モデラーの間には、コードの生成は些細な実装の問題であり、モデリングが完了すれば、すべての大変な作業が完了したという態度がよく見られます。しかし、ジェネレーターを整理することは、言語指向プログラミングを機能させるための鍵となります。なぜなら、ジェネレーターはDSLのセマンティクスを効果的に定義するからです。ジェネレーターを軽視する傾向は、多くのプログラマーがモデラーを真剣に受け止めない主な理由です。UMLと一般的なターゲット言語との間のマッピングを、手書き以外の形式で提供することにUMLコミュニティが無関心であることは、このギャップの良い例です。

まとめ

私はMDAに対してかなり懐疑的な見方をしていることで知られるようになりました。この否定性のほとんどはUML PIM陣営に向けられています。UMLは複雑すぎて、将来の作業の基礎として機能するには意味的に一貫性がないと考えています。しかし、この記事の質問は、MDAが言語ワークベンチでどのような役割を果たすべきかということです。

私の答えは「それほど多くない」です。確かに、言語ワークベンチ間で効果的な交換表現を定義する必要があります。それがなければ、多くのユーザーを阻止し、言語ワークベンチの使用を妨げる可能性のあるベンダーロックインのリスクがあります。しかし、OMG標準がその答えであるとは確信していません。主に、それらが異なる目的のために設計されたためです。私は、最初に何かを行う方法を理解してから、何をどのように標準化するかを理解する必要があるという見解を取っています。OMG標準は、全体像の一部に適用できる場合があります（スキーマのMOFが思い浮かびます）。しかし、言語ワークベンチのライフサイクルでは時期尚早です。