ドメイン固有言語

出典: フリー百科事典『ウィキペディア（Wikipedia）』

移動：案内, 検索

ドメイン固有言語（ドメインこゆうげんご、英: domain-specific language、DSL）とは、特定のタスク向けに設計されたコンピュータ言語を意味する。ドメイン特化言語あるいは単にドメイン言語とも呼ばれるが、学術的にはドメイン特化言語と呼ばれることが多い。C言語やJavaのような汎用プログラミング言語やUMLのような汎用モデリング言語と対照的な用語である。

DSL は一種類のタスクをうまく実行することに集中したものである。

[編集] 利用パターン

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

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

[編集] ドメイン固有言語の定義

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

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

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

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

DSL にはファイルシステムへのアクセス機能やプロセス間制御といった機能を完備したプログラミング言語なら当然持っているべき機能が欠けていることが多い。多くのDSLはバイトコードや実行コードと言ったものにコンパイルされることはなく、他の様々な媒体向けに変換されることが多い。

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

機能を完備したプログラミングツールとなるべく拡張されるDSLもあり、そのために境界が更にあいまいとなっている。

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

[編集] 要求仕様

[編集] 設計目標

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

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

[編集] 例

yacc: コンパイラ用構文解析
SQL: データベース言語
Csound: 音声ファイル作成
GraphViz: 有向グラフ描画
ウィキのマークアップ: ウェブページの作成

[編集] ソフトウェア工学での応用

ドメイン固有言語は、生産性と品質を向上させるものとして、ソフトウェア工学の分野で注目されてきた。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

[編集] 関連項目

[編集] 外部リンク