ドメイン固有言語

Poll without page-refresh

	del.icio.us
	Digg
	Furl
	Reddit
	Rojo
	Add to OnlyWire

ドメイン固有言語（Domain-Specific Language、DSL）とは、特定のタスク向けに設計されたプログラミング言語を意味する。ドメイン特化言語あるいはドメイン固有プログラミング言語とも。C言語やJavaのような汎用プログラミング言語やUMLのような汎用モデリング言語と対照的な用語である。DSLの例としては、表計算ソフトのマクロ、yaccのようなコンパイラ用構文解析、GEMSのようなドメイン固有モデリング用言語、音声ファイル作成用言語Csound、有向グラフ描画用言語GraphVizなどがある。

DSL はその領域によって様々な呼称で呼ばれている:

Little languages
マクロ（表計算ソフトやワープロソフトなどのマクロ機能を指す。プログラミング言語のマクロはDSLではなく、DSLの実装に使われることがある）
アプリケーション言語
超高級言語（いわゆる第4世代言語を指すこともある）

DSL は一種類のタスクをうまく実行することに集中したものである。例えば、GraphViz は様々な形式でグラフを描画するよう設計されているが、ネットワークアクセスとかユーザー入力を対話的に行うとか文字列を操作するといった基本的なタスクを行う機能がない。

利用パターン

DSL を利用するパターンには以下のような場合がある:

単独でDSLを利用する場合。また、（コマンドラインやMakefileから）ユーザー操作の直接的結果として呼び出される場合。例えば GraphViz など。
プログラミング言語のマクロ機能を利用して実装されたDSLは、コンパイル時か読み込み時に汎用プログラミング言語に展開/変換される。
C言語やPerlなどの汎用プログラミング言語で書かれたプログラムから（実行時に）呼び出され、特定の機能を実行して、その結果を主プログラミング言語に返して処理を続けるという形態で使われる DSL もある。この場合一般に、DSLのインタプリタや仮想機械が主アプリケーションに組み込まれている。
表計算ソフトのマクロ言語のように、ユーザーアプリケーションにDSLが組み込まれている場合、そのアプリケーションのユーザーが書いたDSLコードを実行するか、アプリケーション自体がDSLコードを動的に生成して実行する。

多くのDSLは必ずしも一種類の使い方しかできないわけではない。GraphViz はコマンド行で実行することもできるし、GraphViz 用データを出力する Perl モジュールもあり、GraphViz を視覚化コンポーネントとしてアプリケーションに組み込むこともできる。

ドメイン固有言語の定義

DSL は、ある特定の領域（ドメイン）の問題を解決するために作られ、それ以外の領域の問題を解くことは想定していない。一方、汎用プログラミング言語は様々な領域の問題を解くように作られている。汎用言語はチューリング完全である必要がある。

ドメインはビジネス領域にも対応することがある。例えば、次のようなDSLがある:

大手生命保険会社は、社内で利用する生命保険ポリシーDSLを開発している。
戦闘シミュレーションDSL
給与計算DSL
伝票DSL

DSL の位置づけは簡易プログラミング言語とスクリプト言語の中間あたりであり、ライブラリとの類似性がしばしば指摘される。これらの概念の境界は非常にあいまいであり、それはスクリプト言語と汎用プログラミング言語の境界があいまいであるのと似ている。

DSL は言語として（あるいは文法や構文として）非常に限定された目的で設計/実装される。DSL は視覚化された言語の場合もあるし（GEMSやGME）、プログラム的な抽象化の場合もあるし（EMF）、テキスト的な言語の場合もある。例えば、grepというコマンド行で使われるユーティリティはテキストとのパターンマッチを行うための正規表現が可能である。sedユーティリティは同様に正規表現を使ってテキストとパターンマッチングさせて、文字列の置換も行う。これらの簡易言語はシェルスクリプトで利用され、より複雑なタスクを実行する一部を構成する。

DSLとスクリプト言語の境界はあいまいだが、DSL にはファイルシステムへのアクセス機能やプロセス間制御といった機能を完備したプログラミング言語なら当然持っているべき機能が欠けていることが多い。多くのDSLはバイトコードや実行コードと言ったものにコンパイルされることはなく、他の様々な媒体向けに変換されることが多い。例えば、GraphViz は出力結果をPostScript/GIF/JPEGに変換するし、Csoundは音声ファイルを生成する。POV-Rayのようなレイトレーシング用DSLはグラフィックスファイルを生成する。SQLのような言語は、非常に面白い立場にあると言える。リレーショナルデータベースという特定の領域向けであるという意味では、SQL も DSL と見なすことができ、他のアプリケーションから呼び出されるという意味でもDSL的である。しかし、SQLの機能は通常のDSLよりも広範囲であり、独立した言語と見なされることも多い。

APIを公開しているDSLは、他のプログラミング言語から呼び出してライブラリのように使うことができ、このために境界があいまいとなっている。

機能を完備したプログラミングツールとなるべく拡張されるDSLもあり、そのために境界が更にあいまいとなっている。その例としてXSLTがある。これはXML文書を変換するための特殊な言語であったが、（特に2.0版で）拡張されてファイルシステム操作/文字列操作/日付操作/データ型付けなどが可能となっている。

モデル駆動工学では、OCL、ATL などの各種DSLが使われる。ただし、UMLは DSL ではなく汎用モデリング言語に分類されるのが一般的である。

以上をまとめると、次のようなアナロジーが適切である。簡易言語はナイフのようなもので、食べ物を切ったり、木を削ったりといった様々な使い方ができる。DSL は電動ドリルのようなものである。非常に強力で様々な使い方があるものの、何かに穴を開ける（何かを混ぜる、ねじを回す）といった特定の状況でしか使えない。汎用プログラミング言語は完全な工具セットのようなもので、様々なタスクがこなせるようになっている。プログラマが自分の工具セットを見て「もっと良い電動ドリルが必要だ」と判断したときに DSL の出番となるのである。

要求仕様

設計目標

ソフトウェア工学の観点では、DSL の利用には危険性と可能性がある。よく設計された DSL はその二面性の間でうまくバランスをとっている。

DSL には汎用プログラミング言語にはない次のような重要な設計目標がある:

DSL は包括的である必要はない。
DSL はその領域（ドメイン）をより表現しやすくなければならない。

プログラミングの慣例

プログラミングにおいて、次のような慣例は通常の開発でプログラマが組み込む処理である:

ウィンドウが閉じられる前にデータがセーブされていることを確認する。
コストのかかるチェックを行う前に簡単なチェックを行って、コストのかかるチェックをしなければならないケースを減らす。
コマンド行パラメータが変更された場合、それに対応してコードも変更される。

汎用プログラミング言語はこのような慣習を直接サポートすることはほとんどなく、プログラマに任せられている。しかし、DSL は次のような慣習をサポートできる:

自動的にデータをセーブするスクリプト
賢いテストハーネスは良いテストとは何かを学習する。
コマンド行入力をパラメータ化するDSL

例

UNIXのシェルスクリプトは、データ編成用DSLの好例である。ファイルにあるデータを操作したり、ユーザー入力データを処理したりできる。この領域固有の抽象化としてストリームの概念が使われる（ファイル記述子、パイプ、リダイレクションなど）。このような抽象化によって、データの流れや構成に特化した言語を形成する。

この言語は、小さなタスクを実行するプロセス群を起動/制御する簡単なインターフェイスから構成される。タスク群はデータを所定の形式（テーブル、グラフ、チャートなど）に編成するための慣習（慣用句）と見なせる。それぞれのタスクは、非常に汎用的な文字列操作機構（検索、置換、数えるなど）と簡単な制御機構を持っている。

UNIXのスクリプト言語はチューリング完全であったとしても、いわゆる汎用言語とは異なる。例えば、線形リストや木構造のような複雑なデータ構造を生成する機構はない。また、オブジェクト指向設計をサポートする機構もない。実際には、スクリプト言語はUNIXの各種ツール（AWK、ls、sort、wcなど）を組み合わせて使われる。

特殊記号を多用することで知られるAPL言語だが、DSLの迅速な設計開発環境として利用可能である。APLを使って設計されたDSLは必ずしもAPLの特殊記号を入力する必要はない。

ウィキのマークアップは一種のDSLと言える。この言語の目的は、最小の指示でWebページを出力することである。

ソフトウェア工学での応用

ドメイン固有言語は、生産性と品質を向上させるものとして、ソフトウェア工学の分野で注目されてきた。DSL が効率的ソフトウェア工学のためのツールの土台となる可能性を秘めている。そのようなツールは一部のシステムの開発で使われ始めている。

SCR（Software Cost Reduction）ツールキットはその一例である[1]。このツールキットには、要求仕様を作成するためのエディタ、変数の依存関係を表示するブラウザ、仕様内の整論理式での不備をチェックする機構、仕様とアプリケーションを比較検証するモデル検査や自動定理証明機構、仕様から自動的に不変式（invariants）を構築する機構などが含まれる。

利点

DSL は問題領域に適した抽象レベルと慣用句でソリューションを表現する。そのため、その領域の専門家が DSL で書かれたプログラムを理解でき、検証でき、修正でき、さらには開発できる。
コード自体がドキュメントの役割を果たす。
DSL は、品質/生産性/信頼性/保守性/移植性/再利用性を高める。
DSL はその領域のレベルで検証可能である。言語構成要素が安全である限り、それを使って書かれたプログラムは安全とみなせる。

問題点

DSL を設計/実装/保守するコスト
正しい適用範囲を探すこと
ドメイン固有な部分と汎用プログラミング言語の構文とのバランス調整の難しさ
ハードコードされたソフトウェアに比較して性能的に不利な可能性がある

参考文献

Constance Heitmeyer. Using the SCR Toolset to Specify Software Requirements. Proceedings, Second IEEE Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, Oct. 19, 1998.
Diomidis Spinellis. Notable design patterns for domain specific languages. Journal of Systems and Software, 56(1):91–99, February 2001. doi:10.1016/S0164-1212(00)00089-3
Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Computing Surveys, 37(4):316–344, 2005. doi:10.1145/1118890.1118892