Java EE勉強会

DSL / Architecture of DSL Processing

DSL

Architecture of DSL Processing （DSL言語処理アーキテクチャ） †

一言要約 †

  • DSL言語処理は、DSLから意味論モデルを生成して、それを実行するというアーキテクチャになる。実行方法は、意味論モデルを直接実行する方法がオススメ。

要約 †

  • DSL処理系のアーキテクチャ＝「DSL実装がどう動くかについての大まかな構造」
  • 意味論モデル（Semantic Model）（＝ドメインモデル）をDSL処理の中心に据えたアーキテクチャ
    • 最初の秘密ドアの例では、状態（State）、イベント（Event）、命令（Command）のクラスをもった状態機械モデルが意味論モデル
  • 意味論モデルはたいていシステムのドメインモデルの一部になる
    • 通常のモデルと同じに扱えばよい
    • 非OOのモデルでも構わない
    • 意味論モデル自体はDSLとは独立している
  • 意味論モデルをDSLと分けて扱うことにはいくつかのメリットがある
    1. DSL構文／パーサの複雑さから切り離して、ドメインの意味を検討できる
      • DSLを使いたいということは、それだけその表現が複雑だということ
      • 意味論モデルだけ別個にテストできる
    2. 1つの意味論モデルに対して複数のDSLをサポートできる
      • 最初は簡単な内部DSLを提供し、後でもっと洗練された外部DSLも提供する、ということができる
      • 内部DSLと外部DSLの両方をサポートし続けることもできる
    3. モデルと言語を別々に進化させることができる
      • 先にモデルだけに変更を加えて、後からそれをサポートするDSL要素を追加すればよい
      • モデルを変えず、DSLに新しい構文だけを導入することもできる
  • 意味論モデルとDSLの関係は、エンタープライズソフトウェアの世界のドメインモデルとプレゼンテーションの関係のようなものである
    • DSLはUIの一種なんじゃないの、と思うこともある
    • 意味論モデルとDSLは繋がっていることも意味する
      • 一方を変更したら他方も変更しないといけないことが多いということ
      • しかし、分割によって意味論と構文解析を別々に検討できることが重要
  • 内部DSLと外部DSLの違いは構文解析のステップにある
    • どちらもDSLから意味論モデルを生成するのは一緒
    • 外部DSLの場合：
      • DSL、パーサ、意味論モデルが明確に区別されている
    • 内部DSLの場合：
      • 物事がごっちゃになっている
      • Expression Builderを使って言語層を明確にするのがオススメ
      • DSLを構文解析するのは、ホスト言語のパーサとExpression Builderのコンビ
  • 出来上がった意味論モデルの実行方法
    1. 意味論モデルを直接実行する方法（オススメ）
    2. コード生成をする方法
      • DSLとなると必ずコード生成の話をする奴がいる
      • でも、DSL作るのにコード生成は全然必要じゃないからね！
      • コード生成がどうしても必要なのは、実行環境がDSLを解析する環境と異なる場合（ex. 組込ハードウェア、RDB）
      • あるいは、実行環境に開発時のライブラリ依存を含めたくない場合（ex. 言語ワークベンチなどの複雑なDSLツール）
  • コード生成の場合でも、意味論モデルを持つのは有用
    • コード生成せずに、意味論モデルだけで動作確認ができる
    • また、コードジェネレータとパーサを完全に分離できる
  • 何度も言うが、DSLの世界ではコード生成はあくまでオプション！
    • 冬の山を歩くときは雪靴が必要だが、夏でもそれを履く奴はいないでしょ？

ファウラーへのフィードバック †

担当者のつぶやき †

  • 思ったより同じ事を繰り返し言っているような印象です。この節は、以前の箇所で既に読んだことがあるような気が。
  • Fowlerがコード生成を強烈に否定しているところが面白い。トランザクションスクリプトに次ぐ新たな弾圧の対象でしょうか？　過去に何か嫌な経験でもあったのかな？

みんなの突っ込み †


Menu