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

◆モデル駆動型開発に必要な開発基盤技術

　これで、モデル駆動型開発では現在発展中の開発言語におけるEoDの大半をカバーできることが分かった。しかし、だからといってモデル駆動型開発で未来は決まりといえるほど単純ではない。依然としてソフトウェア開発はソース・コードによる開発が基本である。カスタマイズの自由度、変化への迅速な対応、開発者スキルの継承性などがソース・コードによる開発を続ける理由である。それ以外にも、モデル駆動型開発は開発言語の言語機能に対してだけではなく、次のような開発基盤技術に対する課題を解決しなければならない。

• フレームワークやコンポーネント技術への適合性
• 各種パターンやリファクタリングの適用
• テスト、ビルド環境の利用
• 開発プロセスの進め方や開発チームの役割
• モデルを含めた開発成果物の管理

　以下でこれらの解決すべき課題の内容についてより詳しく解説していこう。

●フレームワークやコンポーネント技術への適合性

　変化を前提とした開発が可能であることが重要である。既存のフレームワークやコンポーネントは変化に対して必ずしも柔軟とはいえず、要求変更に対する変更個所の特定も困難である。できれば要求モデルの単位と実現技術のコンポーネント単位が1対1であれば、単純に変更個所を特定でき、トレーサビリティの問題も容易に解決できる。しかし、例えば、要求モデルとしてのユースケースは、OOPによるドメインモデルのクラス構造に対して「散乱ともつれ合い」*4で横断的になるので、両者の関係は1対1にはならない。一方、モデル駆動型開発ではアスペクト指向のような関心の分離の原則に基づくモデルによるモジュール化と、要求変更を可変性としてとらえ、実現技術の可変性対応個所へのマップを行うことで、この問題を改善しようとする。

*4 散乱ともつれ合いについては、本連載の第4回を参照のこと。

●各種パターンやリファクタリングの適用

　最初から要求自体が不明確な場合の対応、開発中の仕様変更への対応、最適なアーキテクチャの構築では、1度で完全な成果物を開発するのは困難である。そのため、リファクタリングで徐々に成果物を洗練させていくこと、そして、適切なコンテキストで各種パターンを適用していくことが求められる。コードによる開発と同様にモデル駆動型開発でも類似の問題が存在し、モデルを使ってリファクタリングやモデル・ベースのパターンの適用を行っていかなければならない。これらはDSLの開発環境の支援機能として提供されるべきであるが、開発ツールの問題として軽く片付けてしまうのではなく、モデル駆動型開発の大きな問題として扱うべきである。

●テスト、ビルド環境の利用

　アジャイル開発でテストが仕様定義や進ちょく管理の意味を持つように、モデル駆動型開発であってもテストは同様に重要である。モデル・レベルの構文や意味の検証、視覚的なテスト、網羅性のチェックなどを考える必要がある。分離した関心ごとに、複数のDSLを使ってコード生成する場合、あるいは、既存のコードとの複合化やリンクをする場合は、既存のビルド環境が再利用できることも重要である。

●開発プロセスの進め方や開発チームの役割

　Software Factoriesでは、「プロダクトライン開発プロセスでアーキテクチャおよびDSLを構築するアーキテクト・チーム」と「提供されたアーキテクチャとDSLを使いプロダクト開発プロセスを行う開発チーム」に分離する方法に加えて、DSL、あるいは、ステークホルダーの視点であるビューポイントを単位としたプロダクト開発プロセスの細分化が可能である。典型的には、「コアのドメインモデル開発」と「アスペクト指向による関心のドメインのDSLモデル開発」を分離し、両者を並行開発する。本連載の第4回で紹介した「サブジェクト指向パラダイム」による開発で、サブジェクトをDSLモデルのモジュール化単位と見なすと、DSLを単位とした並行開発プロセスの一例となる。

●モデルを含めた開発成果物の管理

　ここでの開発成果物とは、保守の対象となるソフトウェア資産全体をいう。ソース・コード、各種リソース、構成定義ファイル、スキーマ定義、画面、開発仕様書、そのほかのモデルである。開発成果物の識別、変更の一貫性、変更履歴などを管理する。モデル駆動型開発は、ソフトウェア開発生産性の向上を利点として取り上げられることが多いが、実はソフトウェアの保守管理の支援の方が重要である。モデルを使うことで、物理レベルの複雑な成果物の形式を隠ぺいし、設計の意図を分かりやすくする開発技術である。また、実装技術の変化に対して仕様の独立性を保つことに寄与する点も重要である。

◆DSLとは

　DSLとは何かを理解するには、Visual Studio 2005 Team Systemで提供されるDSLを使った開発の進め方を見るのが分かりやすい。次の画面は実際にそれを行っているところである。

図2 Visual Studio 2005 Team SystemにおけるWebサービスDSLモデル（左側）と論理サーバDSLモデル（右側）

Webサービスは一般的な設計手法ではUMLコンポーネント図として表現されるが、WebサービスのWSDLによるインターフェイス定義、Webサービスの実現に必要なそのほかの属性（例えば、セキュリティ・ポリシーやWebサービス関連のメタデータ）を表現するために、ここではWebサービスDSLモデルとして表現している。また論理サーバは、UML配置図として表現されるが、より多くの設定や運用管理の属性や制約を表現するために、ここでは論理サーバDSLモデルとして表現している。左側のWebサービスを右側の論理サーバに配置するために、両DSLモデル間でリンクを張る。これにより定義の無矛盾性を検証する。複数の分離された関心のDSLモデル間で、設定に矛盾があればエラーを修正し、修正結果で再度DSLモデルの妥当性を再検証していく。

　図2は、Visual Studio 2005 Team Systemが提供するWebサービスとその論理サーバへの配置の例を示している。Webサービスの契約は、WSDLのサービス・インターフェイスで定義する。WSDLは、サービス操作であるオペレーションとポート・タイプ、そのオペレーションに必要なメッセージとタイプ、オペレーションを提供するサービスとポートを定義する。また、サービス操作のプロトコル、エンコーディング、アドレスをバインディング定義として持つ。これらは特定の物理マシンに依存しない定義となっており、論理レベルで定義可能である。

　Webサービスを図形として定義するには、UMLのコンポーネント図を拡張しなければならない。コンポーネント図が持つインターフェイス定義は汎用的である。WebサービスのWSDLによるインターフェイス定義、あるいは、Webサービスの実現に必要なそのほかの属性（例えば、セキュリティ・ポリシーや、Webサービス関連のメタデータ）を表現できるほど、コンポーネント図は詳細ではない。

　そこで、「UMLのコンポーネントと同様の箱」と「箱から別の箱への関連のリンク」でWebサービスを表現する特殊化された箱を、Webサービス定義用のDSLモデルとする。このようにDSLは、特別な構造や外見（記法）を持つ場合*5ばかりではなく、多くの場合はUMLと類似の外見を持つ箱やリンクで表現されることが多い。

*5 DSLが特殊な構造や外見を持つ例として、例えば、交通管制システムや製鉄所の高炉制御のような業務アプリケーションの例がある。前者は交差点や交通信号をDSLのモデルとし、後者は圧力や温度センサー、高炉や待ち行列などをDSLモデルとする。

　論理サーバは、物理マシンを特定することなく、ソフトウェアの設定、運用管理の属性、制約を表現した抽象的なマシンである。表現に合うマシンであれば物理マシンは特定しない。例えば、nティア・モデル（＝n階層モデル）を運用するために、複数の論理サーバを配置し、それぞれのサーバで特定のドメインのフレームワーク、ミドルウェアや、アプリケーション・サーバ、業務アプリケーションを実行する。論理サーバは、UMLでは配置図として表現されるが、より多くの設定や運用管理の属性や制約を表現するためには、DSLを専用に作るのが有効である。

　図2では、左側がWebサービスのサービス間連携を示すDSLであり、右側が論理サーバの配置を示すDSLである。それぞれのDSLで、まず対象ドメインのモデルを定義する。DSLは実システムをドメインごとに別々の関心で見た表現であるので、これらの関心の分離されたDSLモデル間で矛盾がなく、一貫性を持つ表現であることが求められる。例えば、Webサービスで実現する特定のアプリケーションが必要とするセキュリティ・ポリシーが、そのWebサービスが配置され実行される論理マシンのセキュリティ・ポリシー設定と矛盾していないことを検証する必要がある。

　図2では、左側のWebサービスを右側の論理サーバに配置するために、両DSLモデル間でリンクを張ることで、このセキュリティ・ポリシーを含めた定義の無矛盾性を検証する。例えばWebサービスでは、X.509による認証サービスが必要であるのに、配置先の論理サーバは認証サービスを提供しない設定となっている場合は、現実的にそのサービスを運用できない。このようして、分離された複数の関心のDSLモデル間で、設定に矛盾があれば、そのエラーを修正し、修正結果で再度DSLモデルの妥当性を検証していく。

　ここに、DSLモデル間のトレーサビリティによる変更の自動波及があれば、より開発は容易となる。例えば、概念レベルのビジネス・エンティティのDSLモデルで、エンティティのデータ項目名が変更されると、それに応じて、物理レベルのデータベース・スキーマのDSLモデルのカラム名が変更されるという自動波及の仕組みがある場合である。このトレーサビリティは、本連載の第5回の「ビューポイントによる関心の分離と開発プロセスの実現」で述べた、ビューポイント単位で管理される開発成果物（DSLモデルを含む）間の依存関係で管理される。トレーサビリティは「Factoryスキーマ定義」を用いてモデル間の制約関係を対応ツールが解釈して実現する。

●Webサービスと論理サーバを含むDSL間の関係

　図3は、「WebサービスDSL」と「論理サーバDSL」を含むDSL間の関係を、ビューポイント単位で示した例である。この2つのDSLに加えて、「ビジネス・エンティティDSL」、「ビジネス・プロセスDSL」、「エンティティ・クラス」、「Webサービス・クラス」などのDSLとの関係も示している。これらのDSLの関係は、開発プロセスにおける開発順序、モデル間の依存関係を表現している。

図3 ビューポイントを単位としたDSL間の関係の例

ビジネス・エンティティDSL、ビジネス・プロセスDSL、WebサービスDSL、論理サーバDSL、エンティティ・クラス、Webサービス・クラス、ネットワーク・トポロジーDSLのDSL間の関係をビューポイント単位で示している。これらのDSLの関係は、開発プロセスにおける開発順序、モデル間の依存関係を表現している。開発プロセスでの開発順序では、トップダウン・アプローチ、ボトムアップ・アプローチなどの自由度にはほとんど制約を与えない。

　トップダウン・アプローチの開発順序では、概念レベルのビジネス・エンティティとビジネス・プロセスを分析し、次にビジネス・プロセスのうちどの部分をWebサービスで実現するかを抽出し、その部分のWebサービスのインターフェイス定義を決定する。一方では、既存の物理サーバ配置を考慮し、Webサービス運用に必要なサーバ設定を論理サーバで定義し、Webサービスをこの論理サーバに配置する。最後に、ビジネス・エンティティを実現する物理レベルのエンティティ・クラス、Webサービスを実現するWebサービス・クラス、論理サーバを割り当てる物理マシンを決定する。

　ボトムアップ・アプローチの開発順序では、既存の運用アプリケーションをWebサービスの観点で適切に分割してWebサービス定義として外部公開する。そして、その実現のためのラッパ・クラスとして、Webサービス・クラスを提供する。一方、Webサービスの提供に必要なメッセージ形式をエンティティ・クラスとして定義し、そのメッセージを利用したビジネス・プロセスをWebサービス利用の観点で再構築していく。

　このようにDSLは特定ドメインでの関心を表現し、ビューポイントはステークホルダーの視点から必要とする複数のDSLモデルをグループ化した単位を提供する。DSLとビューポイント定義は、開発プロセスでの開発順序の自由度にはほとんど制約を与えない。（次のページへ続く）

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

　

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

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