連載 次世代開発基盤技術“Software Factories”詳解 第3回 長期的な要求を定義するフィーチャ・モデル マイクロソフト株式会社　萩原 正義 2005/05/28
Page1 Page2

◆フィーチャ・モデル

　フィーチャ・モデルの具体的な記法を説明しよう。次の図1はフィーチャ・モデルの記述例である。

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

問題領域のフィーチャ・モデルは、業務内容、その課題と要求を定義する。必須フィーチャは複数のプロダクト開発において共通性の高い要求であり、オプション・フィーチャはプロダクト開発ごとに選択される要求である。両者を明確に分離することで、変化（可変性）に対応可能なソフトウェア開発を行う。フィーチャ・モデルは変化と変化しない個所を識別するドメイン工学の一手法である。

　フィーチャ・モデルは、直感的にはエンドユーザーが選択可能な機能を示している。しかし、厳密には前述したように、エンドユーザーにとっての機能の選択性よりも、アーキテクチャが提供する長期的に再利用可能な機能（要求）の表現である。

　図1で、は必須のフィーチャ、は選択的なフィーチャ、は相互排他的なフィーチャを示す。ユースケースと同様に、フィーチャ・モデルの記述を読むこと自体は難しくはない。しかし、フィーチャの発見、粒度や境界の決定、体系化、実現法は、ユースケースと同様に困難で、アーキテクトの力量が試される。

●2段階で定義するフィーチャ・モデル

　Software Factoriesのソフトウェア・プロダクトライン開発プロセスでは、フィーチャ・モデルは次の2段階で定義する。

• 問題領域でのフィーチャ・モデル
• 解決領域でのフィーチャ・モデル

　問題領域でのフィーチャ・モデルは、業務内容、その課題と要求を定義する。

　一方、解決領域でのフィーチャ・モデルも、問題領域のフィーチャ・モデルをITシステム化の対象として見ているだけで、そのモデルは基本的に問題領域のフィーチャ・モデルとほぼ同じである。

　ただ異なるのは、問題領域のフィーチャ・モデルのうち、IT技術実現上の課題を検討したうえで、アーキテクチャ構築の面で見送るという結論に至ったものは削除される。

　逆に、現在は問題領域にないフィーチャであっても、長期的に必要なIT技術上のフィーチャならば解決領域でのフィーチャ・モデルに追加することもあり得る。例えば、「問題領域のフィーチャの実現は開発コストが高い」「技術的に困難でリスクが大きい」などの判断の結果、解決領域のフィーチャ・モデルが再定義されるのだ。

　具体的には、フィーチャ・モデルに対して、

• フィーチャの多重度を1…*（1以上）を1とする
• サブ・フィーチャを削除して可変性の選択肢を1つにする
• フィーチャの適切な型に値を割り当てる

などの決定を行う。

●非機能要求を含む、解決領域でのフィーチャ・モデル

　また、解決領域のフィーチャ・モデルでは、木構造のトップ・フィーチャは問題領域の分類に従うが、そのサブ・フィーチャはトップ・フィーチャを実現するうえでの非機能要求のフィーチャを明示することが多い。

　次の図2は非機能要求を含むフィーチャ・モデルの例である。

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

この解決領域でのフィーチャ・モデルは、図1の問題領域のフィーチャ・モデルに対して、IT技術実現上の課題、非機能要求を追加したものである。このモデル図では、「カタログ管理」は「スケーラビリティ」の点で、「同時ユーザー数」が1000を境にした2つのIT技術実現上の選択肢があることが示されている。ここで1000を境界とするのは、フィーチャ・モデルを定義するアーキテクトが経験的にこのアーキテクチャ実現上の課題に対して何らかの機構上の対応策を持っている根拠を示している。アーキテクトは非機能要求の確定しない段階で、ボトルネックを推定しアーキテクチャの検証を行っておく必要がある。

　解決領域のフィーチャ・モデルでは、図2の非機能要求のサブ・フィーチャ（例えば「カタログ管理」の配下にある「スケーラビリティ」などのサブ・フィーチャ）を見ると分かるように、アーキテクトによるアーキテクチャの制約／ボトルネックに関する知識（例えば、「スケーラビリティ」としての「同時ユーザー数」などの制約に関する知識）が、フィーチャとして含まれる。

　要するにこの例では、提供されるアーキテクチャの「同時アクセス数」（図中では「同時ユーザー数」）が1000を境に内部の機構を変えることで、「スケーラビリティ」の非機能要求に対応していることが暗黙に定義されている（このようなフィーチャの定義は、アーキテクトが経験的にその制約やボトルネックに対する対応策を持っていなければ、行うことはできない。フィーチャの定義・モデル化には、アーキテクトの力量が大きく反映されることになるわけだ）。

　フィーチャ・モデルで定義されるフィーチャを、具体的に実現していくための方法や技術については、次回で説明する。またその実現方法の中で、要求の変化（＝可変性）に対する実現技術の1つとして、先進的な開発手法である「サブジェクト指向パラダイム」を紹介する。

萩原 正義 Software Architect

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

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第3回 長期的な要求を定義するフィーチャ・モデル
	1．ユースケースとフィーチャの違い
	2．フィーチャ・モデル

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

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