netail.net

_ [論文] "Feature-Oriented" リファクタリング ▲

Jia Liu, Don Batory and Christian Lengauer: Feature Oriented Refactoring of Legacy Applications.

Proceedings of ICSE 2006, pp.112-121, Shanghai, China, May 2006.

Feature-Oriented Refactoring (FOR) は，色々なfeatureを持ったソフトウェアを，featureごとにモジュール分割する作業のことを指す．この作業を補助する手法を提案している論文．

各featureは，それぞれ固有のメンバー定義（AspectJでいうインタータイプ宣言）である基本のモジュール(base)と，基本モジュールに対する変更操作（アドバイス）である派生モジュール(derivative)によって構成される．派生モジュールの中には，依存する他の派生モジュールを改変するもの（他の特定のfeatureの存在を仮定した処理）が含まれる．この定式化が論文の前半を占めている．

プログラムをfeatureごとに分割する作業では，最初に，開発者が「featureがどう合成されているか」をモデルとして（マニュアルやソースから割り出して）定義する．たとえばロギング機能とバックアップ機能が付いたバッファクラスなら [LOGGING] [BACKUP] BUFFER といった具合．ケーススタディでは GenVoca という文法をこのモデル記述のために使っていて，もしあるfeatureが他のfeatureに依存しているなら「LOGGING implies BACKUP」のように制約を記述できるようにしている．

モデルができたら，元のプログラムの各メンバーがどのfeatureに属するかをラベル付けし，base 部分と derivative 部分を先に切り離してから（先の例なら BUFFER だけを先に取り出してから），派生モジュールのほうをさらに細かく分割していく．

featureごとのモジュールさえできたら（形式的にはAspectJのアスペクトやAHEADのrefineクラスで），あとは組み合わせたいfeatureの組み合わせ（モデルの文法で生成可能な文）を選ぶだけで，プログラムを自動的に再合成することができる．

feature間の相互作用がすべて派生モジュールとして登場するので，featureの数 n に対して，組み合わせ数である2のn乗の派生モジュールが生じてしまうが，実際には相互作用というのはほとんどないので，実際には 3*n 個くらいのモジュール数に収まるようだ，とケーススタディに基づいて述べられている．

この論文の偉いところは，feature間の相互作用を必ず考えろと定式化段階で言ってるところかもしれない．また，featureのモデルを作るのが，必須の機能と付加的な機能を列挙して，その間の依存関係を定義するだけなので，開発者にとっての負荷もそれほど高くなさそうなところもいいかもしれない（コードをそのモデルに基づいて分割するのはけっこうなコストだとは思うけど）．