連載 次世代開発基盤技術“Software Factories”詳解 第6回 DSLによるモデル駆動型開発 マイクロソフト株式会社　萩原 正義 2005/09/03
Page1 Page2 Page3 Page4

◆Software FactoriesにおけるDSLの位置付け

　Software Factoriesでは、プロダクトライン・アーキテクチャのプロダクト生産で、DSLを利用して開発生産性を向上させると同時に、DSLモデルを資産として保守する。このDSLを提供するためには、Software Factoriesのプロダクトライン開発プロセスの一部として、DSLを定義し、開発する必要がある。

　それでは、DSLはどのように定義すべきだろうか？

●DSL設計におけるスコープの決定と理解容易性

　DSLを定義するうえで重要な点は、ターゲットしてのドメインの決定と可変性の分析にある。ドメインの決定では関心の分離を基本とし、ほかのドメインとの依存関係を単純化し、できる限り依存関係のない、独立したドメイン定義をする。そのためにビューポイント定義も考慮する。開発対象システムのスコープを決め、そこでの分離した関心を発見するには、経験が必要である。ドメインのスコープをあまり大きくしすぎず、複雑な場合は単純化することが必要である。

　企業システムの場合、アプリケーション・コードやデータの重複、冗長性は一説には80％に上るといわれる。重複は、アプリケーションやデータの複雑さを増し、変化への対応を阻害し、管理を困難にする。適切な関心の分離は、この冗長性への改善につながり、システム構造の単純化、変化への対応性、管理の容易化に結び付く。

　DSLは、通常の開発言語と異なり、汎用性を求めないので、特定のドメインで理解が容易で、表現力を豊かにすることが可能である。これらの利点を生かすには、できるだけDSLを単純化する必要がある。逆に、通常の開発言語と同等の機能を提供する、＜欲張りな＞DSLを定義するとDSLの利点は失われる。

　この単純化をどの程度にすればいいかの判断が、DSLを定義するうえで最も困難であり、最も有効性を左右する点である。例えば、業務系の計算処理に極めて有効なDSLとして、表形式のスプレッド・シートをモデルにする表計算ソフトは単純さ、有効性の点で非常に優れたDSLモデルの設計例である。

●DSL設計における複合化技術の選択

　さて、Software FactoriesでのDSL設計では、スコープの決定、理解のしやすさに加えて、可変性の表現力と複合化技術の選択、特にターゲットのフレームワークやコンポーネントの再利用を前提とした複合化が重要である。

　まず、DSLのスコープのドメインにおいて変化する部分と変化しない部分を発見するために、可変性分析、例えば、FODA（Feature Oriented Domain Analysis）を使ったフィーチャ・モデル*6で分析し、変化する部分に対しDSLモデルがどのようなカスタマイズ機能を提供すべきかを考える。次に、このDSLの可変性部分を含め、ほかのDSLやソース・コードとどのように統合し、実行可能なコードを生成するかを決定する。数ある複合化技術のうち、可変性の対応に必要な柔軟性、性能や保守などの観点で最適な複合化技術を選択する*7。同時に、実行可能コードが動作するターゲットのフレームワークやコンポーネントとの組み合わせ、その可変性部分の設定を決定する。

*6 フィーチャ・モデルについては、本連載の第3回を参照のこと。

*7 複合化技術については、本連載の第4回を参照のこと。

●Software FactoriesにおけるDSLの特徴

　Software FactoriesのDSLは、OMGのMDAと違って、MOF（Meta-Object Facility）とPIM（Platform Independent Model）*8を外すことで、単純化している点が特徴である。

*8 MOF（Meta-Object Facility）やPIM（Platform Independent Model）の詳細は、例えば、IT Architectフォーラムの「MDAのしくみ（1）　MDAのメリットを考える」や「MDAのしくみ（3）　MDAはどのように作動するか」を参照のこと。

　MOFのような統一的メタモデルを定義しないで、AST、ASGという開発言語のコンパイラの処理系が利用する抽象データ構造だけを定義し、意味モデルの詳細を規定しない。また、PIMを強制しないで、物理レベルのモデルの利用や、コード・ジェネレータのテンプレートなどを特定のプラットフォームや開発言語に特定して開発することが可能である。

　もちろん、相互運用性の観点でMDAのような標準仕様が重要であるのは明白である。しかしSoftware FactoriesのDSLは、あえてそれをしないことで、標準化に伴う遅延、政治的な調整や仕様の中立性保証の課題を回避し、ソフトウェア開発の課題の解決に最も重要な部分だけを取り上げている。特定ドメインにおけるメタモデルの標準仕様、ツール間のモデル連携は、必要とされる段階で、当事者間で決定することを推奨する。MDAのような統一的メタモデルとPIM、その拡張機能で、予見不可能な将来の新技術への対応を解決しようとすると、どうしても複雑さを招く可能性があるが、Software FactoriesのDSLにはこれを回避する狙いもある。

◆まとめ

　モデル駆動型開発が発展したとしても、ソース・コード・ベースの開発は依然として残るだろう。アジャイル開発でテストにより仕様化し、コードを資産として位置付け、パターンを適用し、リファクタリングで改善し、できるだけ単純化して変化に対応し、変更を容易としておくことは、十分に有効なアプローチである。一方、モデル駆動型開発で、モデルにより仕様化し、モデルを資産として位置付け、モデルを使ったパターンを適用し、リファクタリングを実行し、可変性をモデルに加えることで変化に対応し、必要に応じてコードのカスタマイズを併用する方法も、現在よりもずっと有効なアプローチとなる。

　両者の開発アプローチは対立するものではなく、開発規模、開発メンバーの役割やスキル、短期と長期のプロジェクトなどに依存して選択される。しかし、ソフトウェア開発の工業化の観点でいえば、現在よりもモデル駆動型開発の適用場面は増えるだろう。なぜなら、一昔前に比べて、ウィザードなどコード・ジェネレータの技術は確実に浸透し、開発生産性を向上してきたからである。

　ソース・コード・ベースの開発に対して、OOPを初めとして開発言語自体は今後も発展する。アスペクト指向などのオブジェクト指向に対するマルチパラダイムの対応、高度な抽象化概念とそれに対応する開発言語機能の開発と追加は進むであろう。

　しかし、一般には開発言語の発展は技術要求の変化よりもかなり遅く、また、普及にはさらに時間がかかる。その結果、要求の変化に合わせて高度な抽象化概念を開発言語機能が追加することはあまり期待できない。一方、コード書き換え技術や高度なリフレクション機能をフレームワーク・レベルで提供する傾向もある。

　これらの動向を押さえながら、利用できる技術は利用し、要求の変化に追随可能な高度な抽象化概念を、DSLやパラダイム、そのパラダイムを利用した開発プロセス、分析設計手法で補完して利用していくことになるだろう。Software Factoriesは開発基盤技術として必要な技術を取り込み、今後数年をかけて進歩していくことになる。

　次回はSoftware Factoriesによる開発プロジェクトの実際について説明する予定である。

萩原 正義 Software Architect

1993年マイクロソフト入社。北海道大学、早稲田大学非常勤講師。.NET開発、アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向、フレームワーク実装技術、開発方法論、データ中心アプローチとオブジェクト指向分析／設計との融合、モデル駆動型アーキテクチャ、サービス指向アーキテクチャなどが現在の興味対象。趣味は、IT業界の著名人との雑談とウインター・スポーツ。ソフトウェア技術の発展に貢献することが夢。

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第6回 DSLによるモデル駆動型開発
	1．モデル駆動型開発によるEoD
	2．DSLとは
	3．DSLの構造
	4．Software FactoriesにおけるDSLの位置付け

　

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）