連載 次世代開発基盤技術“Software Factories”詳解 第4回 フィーチャの実現法とサブジェクト指向パラダイム ―― ソフトウェア・プロダクトラインの分析、設計、実装法（後編） ―― マイクロソフト株式会社　萩原 正義 2005/07/02

Page1 Page2 Page3

Back Issue

1 ソフトウェア工業化を目指して 2 開発手法「ソフトウェア・プロダクトライン」とは？ 3 長期的な要求を定義するフィーチャ・モデル

　前回の「長期的な要求を定義するフィーチャ・モデル」では、ユースケースとフィーチャの違いを説明し、問題領域と解決領域におけるフィーチャ・モデルの考え方について解説した。これに引き続き今回は、フィーチャ・モデルにおいて定義されるフィーチャの実現方法について説明する。またその実現方法の中でも、要求の変化（＝可変性）に対応する技術の1つとして、先進的な開発手法である「サブジェクト指向パラダイム」を紹介する。

◆フィーチャの実現法

　問題領域は、一般的にはビジネス・プロセス、ビジネス・エンティティなどのモデルで詳細化される。OO（オブジェクト指向）パラダイムを利用する場合は、クラスの識別、オブジェクト間のシーケンス図を経由して、その問題領域に対する論理レベルのドメインクラスが定義されることになる。

●ドメインクラスの設計方法とフィーチャ・モデルの導入

　ドメインクラスには、前回の表1「書籍購入サイトのユースケースとフィーチャの関係」（以下に再掲）の縦軸のユースケースで決まる機能要求の操作（例えば、「カタログ検索」「カタログ保守」など）が、ドメインクラスを動作させるアーキテクチャ*1を前提に割り当てられる。

*1 アーキテクチャ・パターンなどを利用して別に確立する。

　

ユースケース（アクターに対する機能）	フィーチャ（アーキテクチャの要求と再利用可能な機能）
	ユースケース優先度	カタログ管理	注文処理	課金処理	認証	メタデータ	データ分析	……
カタログ検索	1	○
カタログ保守	1	○
カタログ分類	3	○				○
カタログ在庫	2	○					○
注文	1		○
注文状況	2		○				○
決済	1			○	○
： ： ：
表1　書籍購入サイトにおけるユースケースとフィーチャの関係（再掲）

　操作の割り当ては、ドメインクラスのインスタンスであるオブジェクト間での連携の単純性、クラスの拡張性、再利用性などを基準にして決定する。これが従来のOOパラダイムを利用したドメインクラスの設計法である。

　しかし、ビジネス・プロセス、ビジネス・エンティティによる既存のモデル化では、問題領域の共通性と可変性（Commonality and Variability）*2を明確に識別できない。そこでSoftware Factoriesでは、可変性を定義するために、フィーチャ・モデルが導入された。つまり、変化する部分を明確に定義するために、専用のモデル表現が用意されているのである。

*2 共通性と可変性については本連載第2回を参照のこと。

●フィーチャを用いたアーキテクチャの構築手順

　フィーチャを使うアーキテクチャ構築の開発手順は、表1の縦軸のユースケースを考慮し、横軸のフィーチャを選択して進める。一般に、フィーチャの選択には、フィーチャの説明のために便宜上利用した表1のような表形式ではなく、前回の図1や図2（以下に再掲）のようなフィーチャ・モデルの木構造を用いる。選択したフィーチャの（バインディング・タイム*3などの）可変性の要求に応じて、適切なアーキテクチャを前提に、可変性の実現技術としての複合化技術*4を選択し、結果的にドメインクラスが構築される。

*3 変化する部分を開発プロセスのいつの段階までに決定しておくべきかの要求。コンパイル時までに決めるべきか、実行時までに決めるべきかなどは要求によって異なる。複合化技術はバインディング・タイムによって選択肢が異なる。例えば、複合化技術の1つである「継承」は論理レベル、すなわち設計段階でソース・コードとして書いておく必要があるが、もう1つの複合化技術である「Webサービスの呼び出し」（＝委譲）は実行時まで利用できない。 *4 複合化技術については本連載第2回を参考のこと。

　

図1 問題領域のフィーチャ・モデルの記述例（書籍購入サイトの機能要求）（再掲）

　

図2 解決領域でのフィーチャ・モデルの例（書籍購入サイトの非機能要求）（再掲）

　アーキテクトは、必須フィーチャの実現においてはドメインクラスに可変性は必要ないので、ドメインクラスに固定的に操作を割り当てる従来の実現方法を選択する。

　オプション・フィーチャ（選択的なフィーチャ）の実現では、複合化技術の選択肢の中から可変性の要求に応じて、疎結合パターンで別クラスのオブジェクトと連携して一部操作の実行を委譲する実現技術や、アスペクトをウィービングする実現技術などを意思決定して選択する。複合化技術の選択は、バインディング・タイム、拡張性、アーキテクチャの資産管理方針から決定される、ソフトウェア・プロダクトライン開発プロセスにおいて、極めて重要なアーキテクトが行う意思決定の1つである。

　可変性の範囲が予見できない場合には、プロダクト開発（＝プロダクト生産）プロセスでカスタマイズすることを選択する。プロダクト開発プロセスでのカスタマイズは、プロダクト・アーキテクチャ確立、プロダクト開発プラン策定、プロダクト製造、プロダクト配布あるいは初期化、プロダクト実行の、いずれかの段階で可能である。

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第4回 フィーチャの実現法とサブジェクト指向パラダイム
	1．フィーチャ・モデルによるアーキテクチャの構築
	2．フィーチャ・モデルによる可変性の実現
	3．可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」

　

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

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