第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」の感想

第56回　SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」に参加したので感想をメモ。
自分用メモをそのまま貼り付けたので、適当に書く。

【元ネタ】
3月29日 第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」

Xtext - Language Development Made Easy!

ベータパブリッシュ - テキスト型DSL開発フレームワーク Xtext 入門

最初は、細合さんのお話。

【1】DSLのメリット

　生産性の向上
　　コードの自動生成
　ドメイン分析
　　プログラムを第三者視点で表現して分析
　特定のモデルしか書けない
　　プログラミングの知識があまり必要ない
　　ドメインを明確にする
　プログラミングというプログラマの暗黙知を形式知にする

DSLを使いたい最大の理由は、暗黙知にあるドメイン知識を形式知にすること。
DSL文法を使うことによって、例えば業務ドメインの言葉を定義することで、どんな概念が必要で、どんな文法(つまり制約条件)が必要なのか、を明確にする。

DSLで書かれたモデルから、XtextはすぐにJavaソースへ自動生成できる。
昔のモデル駆動開発は、本来はXtextで書かれたモデルからソースを自動生成すべきではなかったのか。

【2】DSLの種類

Internal(言語内・内部)・External(外部)と、テキスト形式・グラフィカル形式で分類された4種類がある。

・Rake：Internal(言語内)＋テキスト形式

・Make、SQL、Ant：外部DSL＋テキスト形式
　→XTextもココに入る

・UML、SysML：外部(独自処理系)＋図形式

・VisualStudio：内部＋図形式

AntやSQLは外部DSL。
Rakeは内部DSL。

UMLやSysMLも、グラフィカルなDSLの1種ととらえる発想は面白い。
確かに、業務モデルや組み込み機器のモデルをUML文法やSysML文法に従って、図に書いているわけだ。

【3】DSL環境
　DSL定義→メタモデル→コード

DSLの作り方
　ドメイン知識が必要なので、新規開発に向かない
　既存資産からパターンを抽出し、ドメインモデルと変換規則を生成する

XText
　OSSのEclipseのDSL支援環境

昔に比べると、言語生成がすごく楽になった
　XTextなら、DSL定義とメタモデルさえ書けば、コードを自動生成してくれる
　　コードアシスト、シンタックスカラーリング、バリデーションなどの開発環境もある
　　Javaのライブラリを参照できる
　　Eclipse上で、テキスト形式とグラフィカル形式を連動できる

XText
　DSL定義

XTend2
　Javaを生成する軽量言語が内蔵されている
　XTextで作られたJavaを生成する軽量言語
　Javaの痒い所に手が届く便利な言語
　書いたそばから自動生成
　　コンパイルまで行なってくれるので、Javaとシームレスに利用可能
　　動的型付け
　　　但し、コンパイル時に型決定なので安心
　　ラムダ形式、拡張関数、拡張Switch(型に応じて条件分岐)
　　テンプレート記述
　　　Javaを自動生成するためのコードテンプレート
　　　　テンプレートにある変数にクラス名、変数名、メソッド名などが、メタモデルから設定されて、自動生成される

MWE2
　DSLからモデル、コード生成までのモデルワークフローエンジンが組み込まれている
　ワークフローエンジン
　　XTextで書かれている
　モデル駆動開発の主要な作業をワークフローの形で記述できる
　　状態遷移図みたいなもの
　　State、Transitionを定義する
　Xtextの言語生成を行う際もこのMWE2のスクリプトを起動して言語環境の生成を行う
　DIのような機能もある
　　ワークフローの途中にポイントがあり、動的にロジックを挿入できる？

Xtextの最大の利点は、DSLの文法を定義するプロセス、自動生成するソースのテンプレートをXtextだけで書けること。
つまり、Xtextさえ覚えれば、DSLを自前で定義できる。

使い道としては、フレームワーク開発を担当する上級SEや上級プログラマがXtextでDSLを定義する。
設計SEは、自前で定義されたDSLに基づき、業務のモデルをDSL文法に従って書く。
すると、即座にモデルに従ったJavaソースが自動生成される。
さらに、テストソースも自動生成されるので、設計SEが開発者の役割も兼ねて、自分でプログラムを書いてしまえばいい。

【3】Xtextを使ったDSLの使い道としては、下記のような業務システムの内部設計があるだろう。

【3－1】業務システムのCRUD表からJavaソースのスケルトンを作成
　機能とテーブルのCRUDマトリクスを、DSLに基づくモデルを書いて、ソースを自動生成する。
　画面やバッチが、どのテーブルからどんなデータを使って、どのテーブルへデータを更新しているのか
　機能をいじると、影響するテーブル、そのテーブルを使う機能に影響が出るのが分かるようにならないか？

【3－2】モデルからソースを自動生成
　モデルベース要件定義に相当する。
　例えば、オブジェクトの状態遷移図をDSL文法で書いて、ソースを自動生成する。

【3－3】既存システムのリバース・エンジニアリングは使えないか？
　既存システムの保守の過程で、パッチで継ぎ接ぎされて、ドキュメントが実際の仕様を反映していない
　誰も既存システムの仕様を知らない
　そんなときに、DSLを使ってソースを解析し、モデルを自動作成とかできないか？

【3－4】ワークフローエンジンを作る
　例えば、ユーザ企業の経費申請、工場の製造・出荷の作業フローなど。
　DSLで状態遷移図の文法を定義し、モデルにワークフローを書き、ソースを自動生成する。

　Xtextでは、トランジション(条件分岐)にDI(Dependency Injection)が使えるらしいので、BRMS(ビジネスルール管理システム)を理論上実装できるはず。
　例えば、出張申請のワークフローをXtextのモデルで書いておき、「出張旅費5万円以上なら、処理Bを実行する」のような業務ロジックをトランジションに挿入して呼び出しできるようにすればいい。

【4】次は、細谷さんの事例の話。

【4－1】Xtext導入の経緯
　SNSで聞いていた
　アジャイル開発で、通信プロトコルの解析処理の実装が電文解析しながら、単純作業になっている
　電子仕様を形式化して、コード生成手段とマッチング
　Xtextは15分でやれると聞いて試した
　チュートリアルの試行
　独自のコードジェネレータを実装

Xtext以前のコード生成
　Excelマクロでコード生成
　　Excelで設計書を作る
　Rubyによるコード生成

より良い手段としてXtext導入を検討

Xtextの適用
　バイナリファイルのパーサー

　製品に対抗する装置のシミュレータ
　　100種類の信号に対応する電文
　　製品とシミュレータがTCP/IP通信
　様々な装置に対抗する装置のシミュレータ
　コード生成のツールとして利用
　既に規定されている構造を処理するコードを生成する
　通信プロトコルを定義するための文法を設計、実装し、未来のプロジェクトで利用可能なDSLを定義する

Xtextの気づき
　ドメイン知識の形式化
　　文法を定義する過程で、ドメイン知識が形式知になる
　　定義された文法を読めば、非常に少ない情報量で、モデル化の範囲や内容を理解することができる

　　70％をカバーする製品に適用した
　　　マニアックな製品仕様は除く
　　　コストが割に合わない

　モデルの改善
　　一つの言語要素から1つの対応するクラスを生成する
　　　ジェネレータの実装が簡単になる
　　自動生成範囲が派生クラス、共通部分が基底クラスとなり、実装の重複がなくなる

効果的な導入ポイント
　最初から全てのモデル化は困難
　容易に効果が出るポイントに着目する
　　コストや時間のトレードオフ
　分析して言語を決めるのは、初心者ならXtextは時間がかかる
　　最初は単一プロジェクトから
　行数の多い表に注目する
　　Xtextに適用すると効果的
　　表は一つの型
　一つのデータ定義が複数の箇所で実装される部分に注目する
　　例：機器の監視項目
　　　　　監視項目は電文の仕様に近い
　　　　　　電文の定義をDSLでモデルとして表現する
　　　　　監視項目は画面で表示して、担当者がチェックする
　同じ概念を複数のソフトウェアで共有している部分に注目する
　　例：複数の機器の間の通信
　　　　　通信されている機器のI/Fは共通の電文仕様を持っている

【4－2】細谷さんの話を聞くと、Xtextを組み込み機器の通信プロトコルに使われる電文や制御処理の自動生成に使われていたらしい。
DSLで通信プロトコルの制御仕様を書くことで、100種類以上の電文の仕様(ドメイン)が明確になり、そのドメインを他の開発者も共有できる。

興味深かったのは、DSLが万能といっても、すべての電文をDSLの対象はならないこと。
複雑な仕様の電文は、コストや納期などの都合上割にあわないので、効果が出る部分のみにXtextを導入した、とのこと。

【5】Xtextの実演習では、Eclipseを使って、サンプルソースを書きながら動かしてみた。
初心者なので、開発環境Eclipseの使い方にはまる。

慣れると、Eclipse上でDSLのコード補完、バリデーション、Import文の自動追加、コードハイライトなどがあるので、すごく書きやすい。
フレームワークを開発、保守するプログラマなら、Xtextを覚えれば、かなり生産性が上がるのではないだろうか？

また、細谷さんから聞いた所によると、XtextのDSL文法はEclipseのプラグインにできるらしい。
すると、ある特定の実装モデルを記述するDSLをXtextで書いてEclipseプラグインにしておき、開発工程でプログラマにプラグインを読み込ませて、実装モデルの設計をDSLというプログラミングで書いてもらえばいい。

すなわち、上級プログラマがDSL文法を定義して、それをEclipseプラグインにして設計SEに配布しておけば、設計SEはDSL文法に基づくモデルを書くと、ソースないしスケルトンを自動生成できる。
つまり、上級プログラマが、システムの方式設計と、システムの設計内容を記述するモデル言語としてDSLの文法を作っておけばいい。

他に、DSLに基づくモデルとして、UMLのクラス図やシーケンス図、状態遷移図があるだろう。
設計SEは、業務をそれらUMLのダイアグラムを絵で書くのではなく、DSLの文法に従ってテキストで書けばいい。
設計書はモデルを表すテキストなので、Gitの配下でバージョン管理でき、その変更履歴をいくらでも追跡できる。
また、モデルをグラフィカルに表現するようなツール(例えばPlantUML)に食わせれば、顧客などのエンドユーザも理解できるはずだから、要件定義や仕様変更で議論しやすくなる。

色々試してみる。