« 「CONCEPTWARE/受注生産」の実装版が完成 | トップページ | 「フィールドの更新不可制約」の必要性 »

2015.04.02

ドメインの階層化とDSP

 開発課題を「上位ドメインと下位ドメインの階層」とみなすことで、開発効率は劇的に改善される。上位ドメインに対する配慮を専用の開発基盤に委譲することで、下位ドメインの定義が様式化・最小化されるからだ。

 何度か例として挙げた「コンピュータに"イパネマの娘"を演奏させる」の課題で説明しよう。この課題を引き受けたミュージシャンは、「初音ミク」のような専用ツールを使って、"イパネマの娘"の演奏定義ファイルをアジャイルに「編集」する。JavaやRuby等のプログラミング言語を使って大掛りな「"イパネマの娘"演奏システム」をアジャイル開発するわけではない。

 ミュージシャンがやっていることは、「上位ドメインの特性」と「下位ドメインの特性」の分離である。すなわち、「コンピュータに"イパネマの娘"を演奏させる」の課題を、「コンピュータに楽曲xを演奏させる」という上位ドメインと、「="イパネマの娘"」という下位ドメインに階層化する(次図)。

▼開発課題を2つのドメインに階層化する
150402a

 階層化の戦略を取り入れることで、課題への対処方法は大きく変わる。すなわち、上位ドメインに特化した開発基盤を事前に用意できるようになる。上の例では「初音ミク」がその種の開発基盤に相当する。その上で記述される個々の下位ドメインは、変数xに対する実際値として矮小化される。

 そのような開発基盤を「ドメイン固有プラットフォーム(DSP,Domain Specific Platform)」と呼びたい。一般にDSPには「ドメイン固有言語(DSL,Domain Specific Language)」が組み込まれていて、これにもとづく「エディタ」と「ドライバ」が搭載される。エディタを用いて課題をDSLで記述し、その結果をドライバに渡すことで、課題が完遂される。

 「初音ミク」であれば、ピアノロールや五線譜のUIを持つエディタを搭載している(次図)。ユーザがこれを用いてDSLにもとづく"イパネマの娘"の演奏定義ファイルを編集し、それをドライバ(演奏用エンジン)に渡す。すると、演奏定義ファイルにもとづいて、ドライバが瞬時に「"イパネマの娘"演奏システム」に変形して動き出す。

▼ピアノロール形式の演奏シーケンスエディタの例
Vocaloid

 DSPそのものを開発することは簡単でないとはいえ、このやり方によってさまざまな効果がもたらされる。まず、開発課題の記述が容易になる。利用者は「クラス」や「メソッド」といったプログラミング上の概念を知らないまま、下位ドメイン固有の問題を「個別案件」として記述できる。また、定義体のサイズが極端に小さいので、開発・保守が楽になる。

 「楽になる」と簡単に言うがこれは、その分野で活動するために求められる本来の専門性は何かという問題でもある。「初音ミク」のエディタがどんなに気が利いているとしても、利用者に作曲や編曲といったスキルや音楽性が欠けていたら使いこなせるものではない。つまりDSPは、「その適用分野で稼ぐために必要な専門性や適性がどういうものか」をあぶりだすための仕掛けでもある。

 さて、ようやく本題。DSPの話は、業務システム開発の世界に棲んでいる技術者にとっても他人事ではない。拙作のOSS基盤XEAD Driverは、「コンピュータ上で業務システムx を動かす」という上位ドメイン向けのDSPである。この世界でもすでにこういう基盤がいろいろと出回り始めている。経済的訴求力の大きなソフトウエア領域では、DSPは必然的に生み出され、普及するものだ。

 技術者は本能的にDSPを侮ったり忌避したりしがちだが、いずれかのDSPを自家薬籠中のものにしておくことはキャリア上有意義なことだ。というのも、たいていのDSPが、技術者が業務システム開発のエキスパートとして成長するための教育的リソースを提供しているからだ。

 じっさい今回、XEAD Driver上で定義された3つ目の事例「受注生産型組立加工管理システム(CONCEPTWARE/受注生産)」を公開した。たいへんシンプルなので、生産管理システムとして理解しやすいものに仕上がっている。これをダウンロードして解凍すると、全体で6メガ程度だが、その内訳は以下のとおりだ。

・データベース(dbフォルダ)...4Mバイト
・基本設計情報(MfgOrder.xead)...1Mバイト
・システム定義(MfgOrder.xeaf)...1Mバイト

 かさばっているのはデータベースであって、基本設計情報もシステム定義も1メガしかない(いずれもXMLデータ)。特に後者は、60個のテーブルと200個の機能を含むシステムの実体としては信じがたいようなサイズだが、これもDSPがもたらす効果(切り出された定義体として個々の開発案件が極小化される)のひとつである。クラスもメソッドも含まない小さな定義ファイルをドライバに渡せば、ドライバ自身が複雑精妙な「受注生産型組立加工管理システム」に瞬時に変形して動き出すのである。

 とはいえ、定義ファイルのサイズなどは大した話ではない。エディタでシステム定義を編集したり、ドライバに読ませたりすることで、実際に動作する業務システムを楽しく理解できる。それは、"イパネマの娘"の演奏定義ファイルを調べたり実行したりすることで、楽曲のコード進行やリズムを楽しく分析できるのと同じ話だ。実システムを、ポータビリティの高い教材としてライブラリ化しやすくなる――これこそが、DSPがもたらす最大の社会的効用だと私は考えている。

|

« 「CONCEPTWARE/受注生産」の実装版が完成 | トップページ | 「フィールドの更新不可制約」の必要性 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: ドメインの階層化とDSP:

« 「CONCEPTWARE/受注生産」の実装版が完成 | トップページ | 「フィールドの更新不可制約」の必要性 »