連載 次世代開発基盤技術“Software Factories”詳解 第7回 Software Factoriesによる可変性を管理したモデル駆動型開発の例 マイクロソフト株式会社　萩原 正義 2005/10/12

Page1 Page2 Page3 Page4

Back Issue

1 ソフトウェア工業化を目指して 2 開発手法「ソフトウェア・プロダクトライン」とは？ 3 長期的な要求を定義するフィーチャ・モデル 4 フィーチャの実現法とサブジェクト指向パラダイム 5 ビューポイントによる関心の分離と開発プロセスの実現 6 DSLによるモデル駆動型開発

　Software Factoriesは、以下を組み合わせた開発基盤技術である。

• プロダクトライン・アーキテクチャ
• ドメイン分析とフィーチャ・モデリング
• ビューポイントによる関心の分離
• DSL（Domain Specific Language）によるモデル駆動型開発

　これらに加えて、Software Factoriesでは以下の技術を組み合わせることが可能だ。

• サブジェクト／アスペクト指向パラダイムを組み合わせたモデル・ベースの複合化技術

• 開発ツールによるステークホルダーごとのビューポイント単位の開発プロセスの強制

　このようにSoftware Factoriesは、変化への対応と品質の確保を実現するための新しいソフトウェア工学技術群をうまく組み合わせて採用している。

　また、新しい工学的アプローチでソフトウェア開発全般の基盤を支える一方で、Software Factoriesには既存のスキルやソフトウェア資産を有効に活用するための以下のような工夫がある。

• 開発プロセス全体にはさまざまなプラクティスや方法論を適用可能

• 可変性に対してパターン指向のアーキテクチャ開発やコンポーネント・ベース開発の開発手法が適用可能

• 可変性に対して適切な開発ライフサイクルのフェイズで複合化技術、パラダイムを選択可能

• 可変性に対応するプラクティスとして、テストとパターン・ベースのリファクタリングの組み合わせをビューポイントのスコープで資産として定義可能

• モデル駆動型開発で利用されるDSLのメタモデルの独自定義が可能

　さて、今回はSoftware Factoriesによる開発の進め方を解説する。これまでの連載の中で断片的に扱ってきた技術要素を組み合わせてどのように開発が進められるかをまとめてみよう。詳しい開発手順は付録に記述したので、以下ではこの開発手順の中で特に難しいとされる、フィーチャ・モデルによる可変性管理、ビューポイントの設計、パターン指向のアーキテクチャ構築、DSLの設計例を順に取り上げていく。

◆フィーチャ・モデルによる可変性管理

　「第3回 長期的な要求を定義するフィーチャ・モデル」で扱ったフィーチャ・モデルは、記述法が容易にもかかわらず定義は困難である。フィーチャはユースケースと異なり、長期的な視点での要求を表現する。ユースケースがアクターの直接的な要求を表現するのに対して、フィーチャはソフトウェア資産の管理を考慮した要求を示す。

　これまでのソフトウェア開発では、「時間的変化が起こりやすい要求」と「保守性や再利用性の観点で長期間の安定性が求められるフレームワークやコンポーネント／モジュールなどのソフトウェア資産」との間のトレーサビリティ（追跡性）の問題を効果的に解決できていない。すなわち、ユースケースやストーリーで定義される要求から、開発ライフサイクルにおいて最終的にはモデルあるいはコードと、その付帯定義やリソースの形をしたソフトウェア資産の成果物を生成するが、「要求モデル」と「ソフトウェア資産モデル（コンポーネントとその接続コネクタ、パッケージなどで表現可能）」の開発ライフサイクルの中で時間的安定性の異なる2つのモデル間で行うモデル変換におけるインピーダンス・ミスマッチの本質的な問題は解決されていない。その解決のため、現状ではアスペクト指向パラダイムを概念や論理レベルに適用したり、ユースケース・モデルを拡張したり、DSLで表現される抽象モデルを導入したりするなど、さまざまな技術でトレーサビリティの問題を解決しようとしている。

　これらの技術は発展途上であるが、フィーチャ・モデルのフィーチャを「要求モデル」と「資産モデル」をつなぐ抽象モデルの一種と考えると、このインピーダンス・ミスマッチの問題に対する解決法の1選択肢となるのである。このあたりの工学的アプローチについては、次回で解説する。

●可変性管理を行うフィーチャの役割

　さて、フィーチャの役割をもう少し詳しく見ておこう。Software Factoriesがフィーチャを利用するのは、

• 大きなドメインをモデル化する
• ソフトウェア・プロダクトラインのプロダクトの可変性を管理する
• システム要求をカプセル化する
• プロダクトライン開発を駆動する
• マーケティング上の決定を支援する
• 将来計画に利用する
• ステークホルダー間のコミュニケーションで利用を可能とする

などの理由による。これらの理由を念頭に置いて、簡単な例でフィーチャの有効性と分析法を検討していこう。

　ここでは、有名な事例としてJava Pet Storeを考えてみよう*1。

*1 Java Pet Storeには複数のバージョンが存在する（詳しくはSunのコード提供サイトの「Enterprise: Java Pet Store Sample Application」の項目を参照のこと）。なお.NET版のPet Shopと呼ばれるサンプル・アプリケーションもある（詳しくは「MSDN:.NET を使って Sun Microsystems の Java Pet Store J2EE ブループリント アプリケーションを実装する」を参照のこと）。

　Java Pet Storeの主なユースケースは、ユーザーの作成、ユーザーのログイン、ユーザーのログオフ、在庫の一覧、バスケットへのアイテム追加、バスケット内容のチェックアウト、ローカライゼーション設定の変更などである。これらのユースケースは3ティア・モデルのWebアプリケーションとして実現される。

　さてここで、これらのユースケースに加えて、以下のユースケースによる要求変更があったとしよう。

1. 新しいローカライゼーション設定要求として韓国語を追加する
2. セッションにまたがってバスケットの内容を保存、復元する
3. 新しい支払い方法を追加する
4. 検索機能を追加する
5. 現在の登録ユーザーに対してメール通知機能を追加する

　これらの要求変更に対して、既存のアーキテクチャに必要となる可変性を、フィーチャの観点で考えてみる。

●可変性分析の原則

　可変性分析では、ソフトウェアを変化する部分と変化しない部分に分離する。両者を確実に分離することは一般的には困難であるが、以下で紹介するような、分析に有効なプラクティス（可変性分析の原則）は存在する*2。

*2 このプラクティスはアスペクト指向分析から生じた成果の一部である。

　ここでは可変性分析の原則を理解するための例え話として、旅行先で財布を失くした場合を考えてみよう。

　財布には、現金のほかに、運転免許証、銀行のキャッシュ・カード、クレジット・カードが入っている。経験したことがある人なら、その後の対応の煩雑さをよくご存じだろう。

　通常、キャッシュ・カードを発行する銀行に連絡し、失くしたカードを無効化して新しいカードの再発行の手続きを依頼する。また、クレジット・カードを発行するカード会社にも同様な対応を行うだろう。運転免許証は所轄の警察署ないし運転免許試験場で再発行の手続きを取ることになる。

　ところで、なぜこのような煩雑な手続きが必要なのであろうか。それは社会の仕組みがその役割に応じた機能を提供し、それぞれが独立した管理を行っているからである。

　これは自律・分散・協調の原則を持つサービス指向の考え方と同じである。つまり、社会は複数の構成要素からできていて、それらの機能を組み合わせたサービスで人々は利便な生活を行っている。これと同様に、ソフトウェアもビルディング・ブロックと呼ばれる独立性の高いWebサービス・プロバイダやコンポーネント、クラスから構成され、それらの機能や責務を組み合わせて動作する。

　本連載の「第4回 フィーチャの実現法とサブジェクト指向パラダイム」では、OO（オブジェクト指向）パラダイムの弱点として、ユースケースが複数のドメインクラスに散乱し、もつれ合う関係にあることを説明した。これは、OOパラダイムに特化した、ビルディング・ブロックであるドメインクラスと、その責務の組み合わせによるユースケースの実現の例を示している。

　このシステム構造としてのビルディング・ブロックと、ビルディング・ブロックの機能を組み合わせたサービスにより実現する要求モデル（ユースケース）の関係を図1で示す。

図1 縦（ビルディング・ブロック）と横（サービス）の関係

ソフトウェアのビルディング・ブロックは安定的で変化しにくい縦のシステム構造であり、それらの機能を組み合わせて動作するサービスは時間変化が起こりやすい横の要求モデルの構造となる。現在のOOパラダイムの主流技術は、この縦の構造に対してドメインクラス構造を適用し、横の構造にはサブジェクト／アスペクト指向パラダイム、依存性注入の技術などを適用する。この関係から、縦の資産モデルのビルディング・ブロックと横の要求モデルの役割が明確になり、将来の要求変更に対する可変性の考慮に有効なプラクティスを導ける。

　日本の縦割り行政はシステム構造の1例であり、横の構造である行政サービスにおけるワンストップ・サービスやサービス追加変更の柔軟性への障害となっている。

　この縦（ビルディング・ブロック）と横（サービス）の関係は、安定的で変化しにくい縦と時間変化が起こりやすい横の関係ともいえる。その原則を知っていれば、ビルディング・ブロックとしてのOOパラダイムのドメインクラス構造やアーキテクチャと、その上で要求変化に対応するためのサブジェクト／アスペクト指向パラダイム、依存性注入などの技術の位置付けが理解できるはずである。

●可変性分析におけるビルディング・ブロックとサービスの考慮

　可変性分析では、この原則を理解したうえで、要求の変更が縦と横のいずれに属するかを考慮して分析を行う。上記のJava Pet Storeの要求変更の例では、ユースケース1、2、3は縦の変更で、4、5は縦と横の同時変更であることが分かる。

　すなわち、縦はビルディング・ブロックに閉じた変更であり比較的複雑度の低い変更である。一方、横は複数のビルディング・ブロックにまたがる変更となるので、適切な関心の分離をしてモジュール化していなければ、変更の波及範囲は大きくなりシステム変更は複雑となる。

　これから起こる可能性のある変更要求に対して、縦と横の関係を適切に分担させ、起こり得る変化に対してはモジュール化を行うことが必要である。そのために変更要求を長期的視野のフィーチャで分析し、可変性の生じる部分のフィーチャをモジュール化の対象として考慮することが重要となる。

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第7回 Software Factoriesによる可変性を管理したモデル駆動型開発の例
	1．フィーチャ・モデルによる可変性管理
	2．ビューポイントの設計
	3．パターン指向のアーキテクチャ構築
	4．付録：Software Factoriesの開発手順

　

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

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