ドメイン固有言語

出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動: 案内、 検索

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

DSL は一種類のタスクをうまく実行することに集中したものであり、古くから存在したが、ドメイン固有モデリングの発達と共にDSLという用語も広く知られるようになってきた。

例えば、HTML、ペン的な描画に特化したLOGO、ハードウェア記述言語であるVerilogやVHDL、MathematicaやMaximaなどの数式処理システム、表計算ソフトの式、関係データベースへの問い合わせ用のSQL、構文解析器構築用のyacc、字句解析器記述用の正規表現、図を作成する言語を構築する Generic Eclipse Modeling System（英語版）、音響や音楽の合成用のCsound、グラフ描画用のGraphvizなどがある。

対義語として

がある。

ドメイン固有言語が有効となるのは、既存の言語よりも特定領域の問題や解法をより明確に記述可能となる場合であり、かつその種の問題が比較的よく出現する場合である。言語指向プログラミング（英語版）は、問題を解く標準的過程の一部として問題を表現する特殊用途の言語を生成することを考慮する。

目次

概要 [編集]

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

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

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

DSLは簡易なプログラミング言語とスクリプト言語の中間に位置し、APIを公開しているDSLは、他のプログラミング言語から呼び出してライブラリのように使うことができる。それらの概念の境界はあいまいであり、機能を完備したプログラミングツールとなるべく拡張されるDSLもあり、そのために境界が更にあいまいとなっている。

設計と実装 [編集]

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

DSL にはファイルシステムへのアクセス機能やプロセス間制御といった機能を完備したプログラミング言語なら当然持っているべき機能が欠けていることが多い。多くのDSLはバイトコードや実行コードと言ったものにコンパイルされることはなく、他の様々な媒体向けに変換されることが多い。例えばGraphvizはPostScript、GIF、JPEGなどを出力し、Csoundは音声ファイルを出力し、POVのようなレイトレーシング用言語はグラフィックスのファイルを出力する。興味深い例としてSQLがある。SQLは関係データベースへのアクセスという特定領域向けのDSLであり、他のアプリケーションから呼び出されることが多いが、その機能は多くのスクリプト言語よりも豊富であり、データベースが広く使われていることもあいまって、SQLは独立した言語としての地位を確立している。

プログラミングツール [編集]

一部のDSLは徐々に機能が追加されて完全なプログラミングツールとなってきているため、ある言語がDSLかそうでないかという判断はさらに複雑化している。好例として関数型言語XSLTがある。当初XSLTはXMLで表現されたグラフを変換するために設計されたが、その後ファイルシステム操作、文字列操作、データ操作、データ型などが追加されていった。

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

簡易言語はナイフのようなもので、様々な用途がある。DSLは電動ドリルのようなもので、穴を空けることにかけては強力なツールである。汎用言語は工具箱のようなもので、様々なタスク向けのツール群が含まれている。プログラマがDSLを使うのは、自分の工具箱を見てもっとよいドリルが必要だと思ったときであり、その用途に最適なDSLが見つかったときである。

DSLに関する話題 [編集]

利用パターン [編集]

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

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

設計目標 [編集]

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

  • DSL は包括的である必要はない。
  • DSL はその領域（ドメイン）をより表現しやすくなければならない。
  • DSL は冗長性を最小限にすべきである。ここでいう冗長性とは、仕様変更を1つ行うのに記述をどれだけ修正しなければならないかを指す。修正が少なければ、仕様変更の実装時にバグを作りこむ危険性が減る。

例 [編集]

Unix シェルスクリプト [編集]

Unix シェルスクリプトはデータ編成用DSLのよい例である。ファイルやユーザー入力のデータを様々な形で操作できる。そのドメイン固有の抽象化と記法として、ストリームの考え方とその操作（リダイレクトやパイプ）がある。それら抽象化により、データのフローと編成に関する強力な言語を構成している。

その言語は、小さなタスクを行うプロセス群の実行と制御のための単純なインタフェース（スクリプト）で構成される。それらのタスクは、テーブル、グラフ、チャートなど必要な形にデータを編成するイディオムを表している。各タスクは単純な制御フローと文字列操作機構から成り、ファイル内の文字列の検索や置換、文字列の出現回数のカウントといった多数の一般的作業をカバーしている。

Unixのスクリプト言語はチューリング完全だったとしても、汎用言語とは異なる。実際にはスクリプト言語は、AWK、ls、sort、wcといった小さなUnixツール群と共に使われる。

ColdFusion Markup Language [編集]

データ駆動型ウェブサイトのためのDSLの例として、ColdFusionのスクリプト言語がある。ウェブサイト構築のために、Java、.NET、C++、SMS、電子メール、メールサーバ、HTTP、FTP、ディレクトリサービス、ファイルシステムなどと共に使われている。

ColdFusion Markup Language (CFML) には、ColdFusionのページでデータソースとのやりとりやデータ操作や表示出力に使用するタグ群が含まれている。CFMLのタグの構文はHTMLのそれによく似ている。

Erlang OTP [編集]

Erlang Open Telecom Platform は当初、エリクソンがDSLとして社内で使用するために設計した。有限オートマトン、汎用サーバ、イベントマネージャなどを素早く構築でき、特定分野ではCやC++といった汎用プログラミング言語を凌駕する生産性を示す。現在では公式にオープンソースとなっている。

FilterMeister [編集]

FilterMeister[3]はCをベースとするプログラミング言語のプログラミング環境で、Photoshop用画像処理フィルタ・プラグインの作成に特化している。FileMeister自体がPhotoshopのプラグインとして動作してスクリプトをロード・実行することもでき、コンパイルして独立したプラグインを生成することもできる。FilterMeisterの言語はC言語とそのライブラリの大部分を再現しているが、それはPhotoshopのプラグインで必要な部分に限られており、その領域でのみ有用な機能も追加している。

MediaWiki のテンプレート [編集]

MediaWikiのテンプレート機能は組み込み型DSLの一種であり、ページ内テンプレートの作成サポートとMediaWikiのページ間のトランスクルージョンを基本的目的としている。詳しくは、Help:テンプレートを参照。

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

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

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

比較的新しい分野として言語指向プログラミング（英語版）がある。これは、DSLの作成・最適化・利用を中心にすえた方法論である。

メタコンパイラ [編集]

言語指向プログラミングを含めあらゆる形態のDSLを補完するものとして、メタコンパイラ（英語版）と呼ばれるコンパイラ記述ツールがある。メタコンパイラはDSLの構文解析器とコード生成器を生成するのに便利というだけでなく、それ自体がコンパイラ記述に特化したDSLでもある。一般的なパーサジェネレータにはないメタコンパイラ特有の特徴として、メタコンパイラは独自の言語で書かれており、メタコンパイラ自体を実行形式に変換することができる。自分自身を定義し変換できるという点で「メタ」なステップを構成しており、メタコンパイラと呼ばれる。

DSLの構文解析だけでなく、メタコンパイラは様々なソフトウェア工学と分析のツールを生成するのにも有効である。メタコンパイラの方式は、汎用ツール群構築の際のブートストラップのためにプログラム変換システム（英語版）でよく使われている。

計算機科学史上重要なメタコンパイラとして、Meta-II[5] とその後継である TREE-META[6] がある。

Unreal Engine などのゲーム向け言語 [編集]

Unreal と Unreal Tournament は UnrealScript という言語を公開している。それによって競合するQuakeに比べて素早い修正が可能となっている。QuakeではC言語を使った Id Tech engine を採用しており、修正にはC言語の習得が必要だが、UnrealScriptは簡便さと効率を重視して設計されている。同様に最近のゲームでは独自の言語を導入することが多く、例えばスクリプト用にはLuaがよく使われている。

ポリシー自動化のためのルールエンジン [編集]

ポリシーや業務規約を自動化するための様々なビジネス・ルール・エンジン（英語版）が開発されてきた。ILOG、Oracle Policy Automation、DTRules、Droolsといった製品では、様々な分野をサポートするDSLを提供している。DTRulesでは、ルールセット内で複数のDSLを使用するためのインタフェースも定義している。

ビジネス・ルール・エンジンは、人間が読める形でビジネスロジックを定義することを目的としている。それにより、その業務の専門家と開発者がビジネスロジックについての理解を共有できるようにしている。多くのルール・エンジンは、ビジネスロジックの制御構造を単純化する技法とDSLを使ったプログラミングを組み合わせて提供している。

統計的モデリング言語 [編集]

統計的モデリング、特にベイズ確率を使った技法では、BugsやJagsといったDSLが作られてきた。これらのDSLはベイズ確率モデルを記述するためのもので、シミュレーションによってそのモデルを解く手段を生成する。

利点と欠点 [編集]

DSLには次のような利点がある[1][2]。

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

一方で、以下のような欠点もある。

  • DSLを習得するのにコストがかかるのに対して、その応用範囲が相対的に狭い。
  • DSL自体を設計/実装/保守するのにもコストがかかり、そのための開発環境が必要である。
  • 正しい適用範囲を探し、設定し、維持することが難しい。
  • ドメイン固有な部分と汎用プログラミング言語の構文とのバランス調整が難しい。
  • ハンドコーディングされたソフトウェアに比較して性能的に不利な可能性がある（実装しているアルゴリズムの効率の問題）。
  • 似たようなDSLが増殖する（同業各社がそれぞれDSLを開発する場合など）[8]。
  • 技術系でない（DSLの対象領域の）専門家は、DSLで書かれたプログラムであっても自らコードを書いたり修正したりできないことがある[7]。
  • ITシステムにDSLを組み込むことは、汎用言語に比べて困難である。
  • 1つのDSLに熟達した人材は相対的に少ないため、人件費が高くつく可能性がある。
  • 汎用プログラミング言語に比べてコード例を見つけにくい。

脚注 [編集]

  1. ^ a b 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
  2. ^ a b 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
  3. ^ “FilterMeister”. 2013年4月25日閲覧。
  4. ^ http://www.nrl.navy.mil/chacs/pubs/02-1221.1-1419.pdf
  5. ^ Shorre, D.V., META II a syntax-oriented compiler writing language, Proceedings of the 1964 19th ACM National Conference, pp. 41.301-41.3011, 1964
  6. ^ C. Stephen Carr, David A. Luther, Sherian Erdmann, 'The TREE-META Compiler-Compiler System: A Meta Compiler System for the Univac 1108 and General Electric 645', University of Utah Technical Report RADC-TR-69-83.
  7. ^ a b Freudenthal, Margus (1 January 2009). “Domain Specific Languages in a Customs Information System”. IEEE Software. doi:10.1109/MS.2009.152. 
  8. ^ Miotto, Eric, On the integration of domain-specific and scientific bodies of knowledge in Model Driven Engineering 

参考文献 [編集]

関連項目 [編集]

外部リンク [編集]

記事
「http://ja.wikipedia.org/w/index.php?title=ドメイン固有言語&oldid=47716217」から取得