Mini Language 1

Domain Specific Languages (以降 DSL(s)) は, 1950年代からその最初の原形があり (e.g. APT[1]The first computer-aided manufacturing (CAM) program.), 概念としては決して新しいものではない. 通常のプログラム言語やシェル言語に代表される General Purpose Languages (以降 GPL(s)) は, しばしばDSLと対比され, 多様な目的に適合する汎用性に富む. 一方で特定の domain[2]目的あるいは対象と訳して良い.に制限すれば, その表現力と使いやすさにおいてDSLに及ばない (そうでなくてはDSL足り得ない).

DSLと聞くと, MDE[3]Model-driven engineeringに則った, コード生成を主体とする先鋭的なメタ言語[4]この意味でのメタ言語の設計と, メタ言語で記述したモデルに基づくソースコードの生成を可能にしているパッケージとして, 例えばEclipse Modeling … Continue readingや, 30年以上前からANSI/ISOでクエリ記述言語の標準であり続けたSQL, あるいは誰もが知る Microsoft Excel を思い浮かべるかも知れない. そして一度でもプロジェクトにDSLを導入しようと試みたことがある人は, 技術的あるいはコスト的な障壁に阻まれたかも知れない.

実際:

the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage.[5]Marjan Mernik, Jan Heering, and Anthony Sloane. “When and How to Develop Domain-Specific Languages”. In: ACM Comput. Surv. 37 (Dec. 2005), pp. 316–. doi: 10.1145/1118890.1118892.

DSLの開発は, それが頭に過ったとしてもしばしば「いつかできたら」と先延ばしにされ, また世の殆どのDSLはアプリケーションライブラリの域を出ない.

という指摘にもある通り, 特に小~中規模プロジェクトにおけるDSLの開発・運用の方式は様々な点で発展途上のようだ. このことを取り上げて深堀りするつもりはないが, この理由として端的に言えば, IT製品開発に向けたDSL利用に際して, 開発コストとパフォーマンスが見合わないことが挙げられる.

プロジェクト規模と開発コストパフォーマンスの観点で見ると, プロジェクト規模が大きい方が特定のドメインに限定した notation[6]表現方法のこと. しばしばアプリケーションドメインに精通している専門家がより自然言語に近い形式で理解・表現できることが望まれる. … Continue reading と construction[7]構成のこと. 所定のドメイン固有の概念を表現する場合, GPLでは複数のブロックを組み合わせるようにするが, (しばしば技術的な理由により) … Continue reading の恩恵を受けやすいというのは感覚レベルで言えば正しいだろうし, DSLによる恩恵がどのようなもの (であるべき) かを正しく測るためにはソフトウェアに一定以上のサイズを必要としそうである:

It is often far from evident that a DSL might be useful or that developing a new one might be worthwhile. This may become clear only after a sizable investment in domain-specific software development using a GPL has been made.

DSLが役に立つ, または開発する価値があるかは, 最初は殆どの場合明らかではないし, 分かるとしてもGPLによる所定のドメインを扱うソフトウェア開発に十分な投資が成された後だろう.

In such cases, DSL development may be a key step in software reengineering or software evolution [Bennett and Rajlich 2000]

そのような場合, ソフトウェアの再開発やソフトウェアを進化させるにあたってDSL開発は鍵になるかも知れない.


このように書いてしまうと, ソフトウェアにDSLを採用する場合は規模がある程度大きくないとその効果が見えずらい, よって小規模開発への適用はまるで筋が悪いというように聞こえるかも知れないが, 私はそうは思わない.

小規模プロジェクトにおけるDSLの有効利用と実装の方法論を検証するだけの実践例は確かに少ないが, PoCは規模に依存せず数多く存在し, 現代は便利なツールが豊富に出ているので組み合わせ次第で適用可能であると考えている.

さて, このような背景をもとに, 以下の要件に適うDSLを Mini Language と呼ぶことにし, 以降数回に分けて Mini Language の実装論について検証を行っていく:

  1. 単一組織内での開発・利用を想定;
  2. 小~中規模の既存ソフトウェアシステム (ソフトウェアエンジニア総数20名以下) への適用を想定;
  3. DSLの適用スコープは未知または変動的;
  4. 開発リソースは限定的;

尚, 開発リソースが限定されたプロジェクトにおける必要十分かつ最小限のDSL実装には (多くの文献で示唆されているように) プロジェクト要件の分析及び分類が重要になるだろうから, 先に参照した論文[8]When and How to Develop Domain-Specific Languagesの用語を援用する. このsurveyは少し古いが, 私が調べた幾つかのsurvey研究に限ればDSL実装論に関連した主要なポイントは新旧共に類似していて, 表記法を統一しても一般性を失わない.

(2に続く)

Footnotes

Footnotes
1 The first computer-aided manufacturing (CAM) program.
2 目的あるいは対象と訳して良い.
3 Model-driven engineering
4 この意味でのメタ言語の設計と, メタ言語で記述したモデルに基づくソースコードの生成を可能にしているパッケージとして, 例えばEclipse Modeling Framework (EMF) 等がある.
5 Marjan Mernik, Jan Heering, and Anthony Sloane. “When and How to Develop Domain-Specific Languages”. In: ACM Comput. Surv. 37 (Dec. 2005), pp. 316–. doi: 10.1145/1118890.1118892.
6 表現方法のこと. しばしばアプリケーションドメインに精通している専門家がより自然言語に近い形式で理解・表現できることが望まれる. 固有の文法 (構文・意味論) を備える場合や, ダイアグラムで表現させる場合等様々である.
7 構成のこと. 所定のドメイン固有の概念を表現する場合, GPLでは複数のブロックを組み合わせるようにするが, (しばしば技術的な理由により) 概念を表すという意味で不自然であることが多い. 一方DSLでは, 一つのブロックに対し一つのドメイン概念を割り当てる構成が可能であり, 要件をシステムに取り込む際にビジネスモデルとずれにくく, 開発も最適化されやすい.
8 When and How to Develop Domain-Specific Languages