機能モデル

ソフトウェア開発において、機能モデルとは、ソフトウェア製品ライン(SPL)のすべての製品を「機能」という観点から簡潔に表現したものです。機能モデルは、機能図によって視覚的に表現されます。機能モデルは、製品ラインの開発プロセス全体で広く使用されており、ドキュメント、アーキテクチャ定義、コードなどの他の資産を生成するための入力としてよく使用されます。^{[引用が必要]}

SPL は、関連するプログラムのファミリーです。プログラム構築の単位が機能 (プログラムの機能または開発の増分) である場合、SPL 内のすべてのプログラムは、機能の一意かつ正当な組み合わせによって識別され、その逆も同様です。

フィーチャモデルは、1990年にKangによってフィーチャ指向ドメイン分析（FODA）手法で初めて導入されました。^[1]それ以来、フィーチャモデリングはソフトウェア製品ラインコミュニティで広く採用され、多くの拡張が提案されてきました。

「機能」とは、「ソフトウェア システムまたはシステムの、ユーザーから見える顕著な、または特徴的な側面、品質、または特性」と定義されます。^[1] SPL 開発の焦点は、類似のプログラムを体系的かつ効率的に作成することにあります。FODA は、特定の SPL でカバーされるドメイン内の機能の識別に特化した分析です。^[1]

フィーチャモデルは、フィーチャとその依存関係を定義するモデルであり、通常はフィーチャ図 + 残りの制約 (クロスツリーとも呼ばれる) の形式をとります。ただし、可能な組み合わせのテーブルとして表される場合もあります。^{[引用が必要]}

フィーチャー ダイアグラムは、フィーチャー モデルの視覚的な表記法であり、基本的には AND-OR ツリーです。その他の拡張機能として、カーディナリティ、フィーチャーのクローン作成、フィーチャーの属性などがあります。これらについては以下で説明します。

機能構成は、SPL のメンバーを記述する機能のセットです。メンバーには、その構成に機能が含まれている場合にのみ、機能が含まれます。機能構成は、モデルによって課される制約に違反しない場合にのみ、機能モデルによって許可されます...

機能ツリー（機能モデルまたは機能図とも呼ばれる）は、ソリューションの機能を詳細レベルのグループごとに視覚的に表す階層図です。機能ツリーは、ソリューションに含まれる機能とそれらの関連性を視覚的にわかりやすくまとめるのに最適です。 ^[2]

現在の機能モデリング表記法は、次の 3 つの主要なグループに分けられます。

• 基本機能モデル
• カーディナリティベースの特徴モデル
• 拡張機能モデル

親機能とその子機能 (またはサブ機能) の関係は、次のように分類されます。

• 必須 – 子フィーチャを選択する必要があります。
• オプション - 子フィーチャを選択することも、選択しないこともできます。
• または、サブ機能の少なくとも 1 つを選択する必要があります。
• 代替 (xor) - サブ機能の 1 つだけを選択する必要があります。

機能間の親子関係に加えて、クロスツリー制約も許可されます。最も一般的なものは次のとおりです。

• A には B が必要 – 製品で A を選択すると、B も選択されることになります。
• A は B を除外します – A と B は同じ製品の一部になることはできません。

例として、右の図は、機能モデルを使用して構成可能なオンライン ショッピング システムを指定および構築する方法を示しています。各アプリケーションのソフトウェアは、それが提供する機能によって決まります。ルート機能 (つまり、E ショップ) は SPL を識別します。すべてのショッピング システムは、カタログ、支払いモジュール、セキュリティ ポリシー、およびオプションで検索ツールを実装します。E ショップは、高セキュリティ ポリシーまたは標準セキュリティ ポリシー (いずれかを選択) を実装する必要があり、銀行振込、クレジットカード、またはその両方のさまざまな支払いモジュールを提供できます。さらに、クロスツリー制約により、クレジットカード支払いモジュールを含むショッピング システムは、高セキュリティ ポリシーを実装する必要があります。

一部の著者は、 UMLのような多重度[n,m] （ nは下限、mは上限）で基本フィーチャモデルを拡張することを提案しています。これらは、親が選択されるたびに製品の一部となるサブフィーチャの数を制限するために使用されます。^[3]

上限が*の場合、機能は必要な回数だけ複製できます (他の制約が尊重されている限り)。この表記法は、任意の数のコンポーネントで拡張可能な製品に役立ちます。

他には、「属性」を使用して機能に追加の機能情報を追加することを提案する人もいます。これらは主に名前、ドメイン、値で構成されます。^[4]

フィーチャモデルのセマンティクスは、フィーチャモデルが許可するフィーチャ構成の集合です。最も一般的なアプローチは、数学的ロジックを使用してフィーチャダイアグラムのセマンティクスをキャプチャすることです。^{[5]各フィーチャは}ブール変数に対応し、セマンティクスは命題式としてキャプチャされます。この式の満足値は、フィーチャダイアグラムで許可されるフィーチャ構成に対応します。たとえば、が の必須のサブフィーチャである場合、式には制約 が含まれます。^[6]${\displaystyle f_{1}}$${\displaystyle f_{2}}$${\displaystyle f_{1}\Leftrightarrow f_{2}}$

次の表は、基本的なプリミティブの変換を示しています。図は、ルートを持つルート付きツリーであると想定しています。図全体のセマンティクスは、図に含まれる要素の変換の連言です。したがって、すべての要素が連言標準形(CNF)で記述されている場合、項は論理 AND で簡単に組み合わせることができ、論理式全体が CNF のままになります。 ${\displaystyle r}$

SPL の製品は、ユーザーの好みに応じて機能を選択または選択解除することによって宣言的に指定されます。このような決定は、機能モデルによって課される制約を尊重する必要があります。「コンフィギュレータ」は、構成プロセス中にユーザーを支援するツールです。たとえば、構成を正常に完了するために選択する必要がある機能と選択してはならない機能を自動的に選択または選択解除します。現在のアプローチでは、ユニット プロパゲーション^[7] とCSP ソルバー^[4]が使用されています。

フィーチャーモデルの分析は、マーケティング戦略や技術的な決定に重要なモデルの特定の特性をターゲットとします。文献では、多くの分析が特定されています。^{[8] [9]}典型的な分析では、フィーチャーモデルが無効（製品を表さない）かどうか、デッドフィーチャー（どの製品にも含まれないフィーチャー）が含まれているかどうか、またはモデルによって表されるソフトウェア製品ラインの製品の数を判断します。他の分析では、複数のフィーチャーモデルの比較に焦点を当てています（たとえば、モデルが別のモデルの特殊化、リファクタリング、または一般化であるかどうかを確認するなど）。^[10]

• ドメイン分析
• ドメインエンジニアリング
• 機能指向プログラミング- ソフトウェア製品ライン合成のパラダイム
• 製品ファミリーエンジニアリング
• ソフトウェア製品ライン

• 機能モデルリポジトリ Wiki
• 機能モデルを使用したソフトウェア製品ラインエンジニアリング