データフローDSL考 (2)

前回は、データフロー図の例として以下の図を挙げました。テキストDSLでデータフローを記述する場合、こういったモデルを記述できることが必要となります。

最後の手段

データフロー図はグラフ構造を取ります。つまり、テキストDSLで記述する際の最後の手段としてノード記述方式があります。

デーフローに登場する各ノードを個別に記述し、ノード間に存在するリンクを(1)リンクの集合として記述、あるいは(2)ノードの属性として記述、といった方式です。

このノード記述方式を採用すれば絶対に記述できるのは明らかです。グラフ処理のアルゴリズムは行列を使うものが多いですが、これも一種のノード記述方式といえます。

ノード記述方式による最後の手段は確立されているという前提の上で、さらによい記述方式があるのかどうかという点が論点となります。なければ、普通にノード記述方式を採用していけばよいわけです。

パイプライン

データフローをテキストDSLで記述する際の有力な候補がパイプラインです。UNIXのシェルや、このブログでもたびたび取り上げている関数型プログラミングのMonadicプログラミングもパイプラインの例です。パイプラインはセマンティクスの分かりやすさとテキスト記述との相性の良さから、テキストDSLの記述方式の有力な候補となります。

パイプラインの問題点は、木構造やグラフ構造をうまく記述できないことです。木構造については工夫でカバーできる点もありそうですが、グラフ構造については本質的に不可能です。

このため、応用がぴったりはまると非常に強力ですが、汎用的には利用できないという大きな弱点があります。

解決案

この問題を解決するために考えてみたのが、複数のパイプラインを組合わせてグラフ構造を記述する方法です。

たとえば以下のようなデータフロー図を考えてみます。

このデータフローは、上側のデータフローと下側のデータフローを2つ組合わせたものと考えることができます。

この観点で注釈をつけたものが以下の図になります。

上側のパイプラインと下側のパイプラインを分かりやすく枠で囲みました。

また、プロセスが複数入力する場合の多くが、メインの処理対象に補足情報を継ぎ足していきます。たとえば、仕訳伝票や製造指示書といったトランザクションデータに商品番号や部門といったマスターデータを結合するような処理です。こういった用途が限定された軽い枝は、特別な記法の導入で記述することができる可能性があります。これば可能であればパイプラインのセマンティクスを維持したまま、より広範囲のモデルの記述が可能になります。

そして、2つのパイプラインを結合する記述方式の問題が解決すれば、パイプラインを軸にデータフローを記述することが可能になります。

より複雑に

前述の例を少し拡張すると以下のデータフロー図になります。

拡張したポイントを追加した注釈は以下の図です。

この図は、一番最初のデータフロー図と全く同じものです。つまり、少し複雑に見えるデータフロー図でも、細かく見ていくと軸となるパイプラインを組み合わせたものであることが多々あるわけです。

実感的には、現実の応用はこのように軸となるパイプラインを決めることができて、これに小さな演算や小さなパイプラインを加えていく形に落ち着くことが多いのではないかと思います。

こういった性質を持つドメインのモデル化をする上では、パイプラインを軸にしたセマンティクスのテキストDSLが有効ではないかと思います。

具体例

データフロー図、データフローモデルをテキストDSL化する方式はDSL駆動開発の鍵となる重要な要素です。以前からパイプライン拡張方式が有力と考えており、色々と試行錯誤をしてきました。

その成果物としてメッセージングフレームワークg3と私家版Asakusa DSLがあります。次回は、データフローDSLという観点でこれらのDSLについてみていきます。