[論文レビュー] Type-Safe Feature-Oriented Product Lines

Sven Apel, Christian Kästner+2 more|arXiv (Cornell University)|Jan 20, 2010

Advanced Software Engineering Methodologies参考文献 82被引用数 10

ひとこと要約

この論文は、個々のプログラムバリアントを個別に生成せずに、すべての有効なプログラムバリアントにおいて型安全性を保証するための型システムを提示する。特徴の組み合わせを形式的計算式（FFJ PL）で直接モデル化することで、特徴モデルを用いてすべての可能な特徴の組み合わせを静的に検査し、有効な特徴選択から導かれるすべての整合的なプログラムが型安全であることを保証するとともに、型システムの完全性を裏付ける。

ABSTRACT

A feature-oriented product line is a family of programs that share a common set of features. A feature implements a stakeholder's requirement, represents a design decision and configuration option and, when added to a program, involves the introduction of new structures, such as classes and methods, and the refinement of existing ones, such as extending methods. With feature-oriented decomposition, programs can be generated, solely on the basis of a user's selection of features, by the composition of the corresponding feature code. A key challenge of feature-oriented product line engineering is how to guarantee the correctness of an entire feature-oriented product line, i.e., of all of the member programs generated from different combinations of features. As the number of valid feature combinations grows progressively with the number of features, it is not feasible to check all individual programs. The only feasible approach is to have a type system check the entire code base of the feature-oriented product line. We have developed such a type system on the basis of a formal model of a feature-oriented Java-like language. We demonstrate that the type system ensures that every valid program of a feature-oriented product line is well-typed and that the type system is complete.

研究の動機と目的

• 組み合わせ的爆発を伴う特徴指向の製品ラインにおける正しさの検証のスケーラビリティ課題に対処すること。
• 個々のプログラムバリアントごとに検査するのではなく、製品ライン全体のコードベースを一度に検査する型システムを開発すること。
• 特徴がクラスやメソッドを精査する場合を含め、有効な特徴選択から生成されるすべてのプログラムが型チェックに合格することを保証すること。
• 型システムが正しく（不正な型のバリアントを含まない）かつ完全（すべての型チェックに合格したプログラムがシステムによって捉えられる）であることを証明すること。
• ランタイムでの動的特徴組み合わせをサポートするために、特徴テーブルと特徴モデルをランタイムで動的に変更可能な構造としてモデル化すること。

提案手法

• 特徴モジュール、クラスおよびメソッドの精査、特徴の組み合わせをモデル化する直接的意味論を備えた、コアな特徴指向言語「Feature Featherweight Java（FFJ）」を形式化すること。
• 特徴モデルと制約を型システムに統合することで、すべての有効な特徴の組み合わせを同時に分析できるように、FFJをFFJ PLに拡張すること。
• 型チェック中に特徴モデルを参照する型ルールを設計することで、細かく分類されたエラーレポートを可能にし、コードフラットニングの必要性を回避すること。
• 形式的証明を用いて正しさを確立する：型チェックに合格した製品ラインから生成されるすべてのプログラムが、型チェックに合格すること。
• クラスと特徴テーブル、および特徴モデルをランタイムで変更可能にするようにすることで、動的組み合わせをサポートすること。
• Haskellを用いてシステムを実装し、特徴指向メカニズムの実験的検証のためのテストベッドを提供すること。

実験結果

リサーチクエスチョン

• RQ1 個々に各バリアントを生成せずに、特徴指向の製品ラインにおけるすべての有効なプログラムバリアントの正しさを型システムが検証できるか？
• RQ2 特徴モデルの制約を活用することで、すべての有効な特徴の組み合わせにおいて型安全性を保証する型システムはどのように設計できるか？
• RQ3 型システムを、正しく（不正な型のバリアントを含まない）かつ完全（すべての型チェックに合格したプログラムが検出可能）に設計することは可能か？
• RQ4 型システムは、静的組み合わせを必要とせず、ランタイムでの動的特徴組み合わせをサポートできるか？
• RQ5 コード生成を伴わない特徴指向の意味論の直接的モデル化は、型チェックの精度とエラーレポートの明確さをどのように向上させるか？

主な発見

• 提案された型システムは、有効な特徴選択から生成されるすべてのプログラムが型チェックに合格することを保証し、システムの正しさを裏付ける。
• 型システムは完全性を有する：製品ラインのすべてのプログラムが型チェックに合格している場合、製品ライン全体も型チェックに合格していると見なせる。
• 型チェック中に特徴モデルを参照することで、細かく分類されたエラーレポートが可能となり、型エラーの正確な特定が可能になる。
• コードフラットニングを回避し、特徉モジュール上で直接処理することで、ランタイムでの動的特徴組み合わせのモデル化が可能になる。
• Haskellでの実装により、本アプローチの実現可能性が示され、特徴指向メカニズムのさらなる実験的検証のためのテストベッドが提供される。
• 形式的モデル（FFJ PL）は、その前身よりもより簡潔で洗練されており、明確さと保守性が向上している。