WebDSL：DSL作成から学んだ教訓

Eelco Visser氏(source)はオランダのDelft University of Technologyの准教授で、「プログラム変換と生成」(source)を教えている。

Visser氏は「WebDSL: A Case Study in Domain-Specific Language Engineering」（WebDSL：ドメイン固有言語エンジニアリングにおけるケーススタディ）という論文(PDF・英語)を書き終えたばかりだが、この論文ではWebDSLの設計ならびに実装を調べ直している。

この論文には「ドメイン固有言語エンジニアリング」プロセスに関する導入部分が2つと、WebエンジニアリングのソリューションとしてWebDSLを評価し、関連するDSLエンジニアリング・アプローチや言語エンジニアリングの研究課題を論じる考察部分が3つあります 。

WebDSL(source)は、リッチなデータモデルを使って動的Webアプリケーションを開発するためのドメイン固有言語である。根本的なターゲットアーキテクチャはJBossのSeamをベースにしている。Visser氏は2007年12月にWebDSL初のアルファリリースを発表した。

Visser氏はDSLを次のように定義している。

• DSLとは言語、すなわち、正式に定義されたシンタックスとセマンティクスを持つ、テキストもしくはビジュアルで表記された文の集まりである。
• DSLは、低レベルの実装の詳細や、ことによると実装プラットフォームの詳細事項からの抽出という意味において、高レベルである。
• DSLはソフトウェアの実装をサポートすべきものである。
• DSLのコンセプトと抽象概念は、特定のドメインに関連している。

Visser氏が見るところのDSLの目標は次のとおりである。

...低レベルのボイラプレートコードから抽出することにより、ソフトウェアエンジニアの生産性を向上させること。

メソッドとクラスのような、汎用プログラミング言語の従来の抽出メカニズムでは、もはや新規抽出レイヤの作成には不十分です。ライブラリとフレームワークは機能性のカプセル化に長けていますが、開発者がその機能性に到達するために使わなければならない言語、すなわちアプリケーション・プログラマーズ・インターフェース（API）は扱いにくいことがよくあります。

場合によっては、APIがより適した言語をサポートすることもありますが、そうすると言葉はライブラリ呼び出しに渡される文字列リテラルの形をとり（たとえばSQLクエリ）、セマンティクスは言うまでもなく、シンタックスも、ホスト言語がチェックすることはありません。

Visser氏は以下が必要と主張している。

...DSLの設計および実装の技術のみならず、その技術を使うための方法論。すなわち、言語設計および言語実装における一般的な問題にどのように取り組むかを開発者に示す、ガイドラインや設計パターン、再利用可能なDSLコンポーネントのコレクションです。

とは言いながらも、氏は次のように特に言及している。

Webアプリケーションのエンジニアリングはかなり成熟した分野であり…このドメインはDSL開発にぴったりの環境にあります。

• タスクの自動化：［JavaサーブレットおよびJSF］にもかかわらず、Webプログラミングには往々にして相当量のボイラプレートコードが必要です。;
• 表記法：現在のプラットフォームは様々な関心事を扱うしばしば冗長な言語の混合物を提供しており、この混合物は統合されていません。
• 検証：Webアプリケーション技術が統合されていない結果、実装が静的に検証されません。
• GUI構築：［JSP式のフレームワークには頻繁に］テンプレートが生成したHTMLコードの構造に関する知識が欠けているため、よい形式とは言えないドキュメントをいとも簡単に生成してしまいます。［JSF の場合でさえ］テンプレートは非常に冗長であり、低レベルの詳細を取り上げています。
• 分析と最適化：たとえば、データベースクエリをWiedermannおよびCook流に最適化［108］すれば、生成したクエリの調整を手動に頼ることなく、アプリケーションのパフォーマンスを改善する上で役立つかもしれません。.

Visser氏は3つのDSL設計パターンを確認している。

• プログラミングパターンの検出
• コア言語の設計
• コア言語に加えて構文抽象の構築

WebDSLについてVisser氏は、テキストのデータモデルDSLの定義から開始している。コードジェネレータは、JPAベースのJava コードでエンティティ定義を変換する。その後、View/Edit（ビュー／編集）DSLを展開させるが、このDSLからJSFページとSeamセッションBeanを生成する。この後は、カスタマイズ可能なView/Editページやコレクション、複雑な関連付けを導入することにより、WebDSLを拡張して「適用範囲を拡大」することができる。

Visser氏の報告によると、生成されたコード行をDSLの行で割った比率が100を超えていると、ジェネレータ改善の余地がある。

氏の論文は、言語エンジニアリング・パラダイムと言語エンジニアリングの課題、そしてとりわけ「モデルマイグレーション」に関する議論へと続く。

Visser氏は自身の経験に基づき、以下を推奨している。

• DSL［の開発を開始］…アプリケーションドメインを十分理解し、ドメイン内にシステム用のコードベースが相当規模で存在する場合。
• プログラムの比較的大きなチャンクをパターン候補として検討することから始めること。
• 技術を研究、理解し、一般的なパターンを見分けること。早い段階に基本的なジェネレータを準備してください。
• シンタックスを特殊化しすぎないこと。
• 始めからコア言語を識別しようとはしないでください。結果が目標の技術に接近しすぎることにもなりかねません。
• 簡潔な表現を可能にする構文抽象を用いてコア言語を拡張すること。
• コードベースの組織化向けのモジュールやDSL断片の上位に位置するパラメータ付き抽象など、ライブラリを構築する機能を入れるようにしてください。

原文はこちらです：http://www.infoq.com/news/2008/05/webdsl-case-study