Domain Specific Language(DSL)について

ご存知の方もおられると思いますが、Domain Specific Language (DSL) という言葉があります。Wikipediaで調べてみると、次のエントリが見つかります。本エントリではモデリングの観点からだけDSLを考えますが、例えばRuby on RailsのRailsはRuby言語に組み込まれたDSLと言われています。

  1. ドメイン固有言語
  2. Domain-specific language

ある限定された領域(ドメイン)において有効な言語ですが、モデリングの世界でUMLのようなどちらかと言うと汎用的モデリング言語より、その時々に応じて必要な概念だけを扱うDSLの方が有効という議論があります。

UMLのUはUniversalではなくUnifiedであり、良く利用されているモデリング言語を統合したという意味になります。そうすると、必ずしも良く利用されていないモデリング言語はその外側に置かれているということになります。通常UMLは汎用モデリング言語でありDSLと認識されていませんが、OMGのAndrew Watson氏はあるインタビューで、UMLの各ダイアグラムを個別に見れば各々がその領域に特化したもの(例えばステートチャート)なのだからUMLもDSLの一種と考えられる、というようなコメントをしていました。

DSLを支援するツールにはMetaEditやGMEなどが昔からあったのですが、数年前にMicrosoft社Visual StudioのDSLツールの発表で改めて脚光を浴びたと思います。eclipse GMFもこのカテゴリです。こう書くと、DSLツールとメタモデリングツールの差が分らないと思いますが、個人的にはこれらは同じでありどこを強調するかが違っているだけと考えています。さて、これらグラフィカルツールの良いところは、利用者がドメイン固有の概念をグラフィカルに規定すれば1)その概念に基づくグラフィカルなモデルエディタが使えるようになり、2)その結果を元にある程度のコード生成なりにつなげることが出来る、ということです。

UMLよりDSLの方が良さそうに思えるかもしれませんが、結局言語を設計することになるので、最初の定義部分を確実にする必要があり、どれだけやれば大丈夫かが難しいところかもしれません。また、類似のDSLが幾つも作成されると、まずはモデルの理解、そしてそれらに基づいたモデルの交換や統合などいろいろ現実的な問題が出てきそうです。標準化や調整のようなことが必要になってくるのでしょう。良い点は、うまく設計すれば必要最低限の概念でモデルを表現できるようになることでしょうか。

これに対し、DSLに対応するようなUMLの機能としてUMLの拡張メカニズムというものがあります。この機能を利用するとUMLをベースにして新しい(ある意味)モデル言語を作ることが出来ます。これはProfileと呼ばれるものです。例えば、UML Profile for EDOCという仕様では、EDOCに現れる概念はどのようなものであり、それがどのようにUMLの各要素にマッピングされるか(ステレオタイプやタグ値など)を規定しています。その結果できることは、UMLツールにこのProfileを組み込むと、例えばクラス図で通常のクラスとは違ったステレオタイプ付きのクラスを導入することができ、それを使ってEDOCモデルが作成できるようになることです。このアプローチの場合、出来上がったモデルは本来のUMLの備えるすべてのものを継承しているため、比較の問題ですがより大きな・複雑なモデル(データ)になってしまうことです。

いろいろ書きましたが、DSLは今後も利用が広がってゆくと思います。そのうち続編を書くことになりそうです。

Domain Specific Language(DSL)について

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中