発表論文

• タイトル

「An Analysis of the Variability in Forty

Preprocessor-Based Software Product Lines」

（40のプリプロセッサベースのSPLの変動性解析）

• 著者– Jörg Liebig, Sven Apel , Christian Lengauer, Christian

Kästner, Michael Schulze

• 出典– 32rd International Conference

on Software Engineering

（ICSE 2010）0

year accept rate

2009 12%

2010 14%

2011 14%NII合同輪講

• ICSE（ソフトウェア工学系最強の学会）だから

→ 高級な学会の論文を調査することで、

自分も高級な着眼点で研究ができそう

• SPL系の論文だから

→ ソフトウェア工学の中で、

特にSPL（Software Product Line）を使った

既存システムの再利用に興味あり

選定理由

1NII合同輪講

概要

• 目的

→ CPP（C Preprocessor）を使って開発された

再利用資産が、SPL開発で実用可能かどうか

調査するため

• 手法

→ 40本のソフトウェア上にCPPによる可変フィーチャ

を実装し、実用化に必要な複数項目で調査

• 結論

→可変性の高い再利用資産の開発に関する

実用化に向けた調査結果を示した2NII合同輪講

背景：システム開発の現状

• 顧客が求めるシステムの

大規模化・高機能化、短期開発化、低コスト化

3

もっと高機能なシステムを

もっと早く

もっと安く

そ、そんな無茶な…

顧客

SE NII合同輪講

SPL（Software Product Line）による効率化

• 既存システムを再利用して、システム開発

4

再利用資産の開発

新システムの開発

いかに可変性の高い再利用資産を作れるか

重要

NII合同輪講

可変性の高い再利用資産の開発？

可変性の高い 再利用資産の開発

5

1. 「再利用資産の開発」とは？

2. 「可変性が高い」とは？

NII合同輪講

• システムはフィーチャ（機能）で構成されている

既存システムをフィーチャに分ける

例）時計システムのフィーチャ

6

再利用資産の開発1（全類似既存システムをフィーチャに分ける）

NII合同輪講

再利用資産の開発2（全類似既存システムのフィーチャを結合）

• 再利用資産：全フィーチャを備えた万能システム

7

…

再利用資産

1 2 3 4

+ + ++

NII合同輪講

可変性が高い1（必須フィーチャと任意フィーチャ）

• 似たようなシステム同士には、共通する機能がある

• 似たようなシステムでも、製品によって個性がある

類似既存システムのフィーチャを結合し、

共通機能と製品固有機能を明確化する

共通機能 → 必須フィーチャ

製品固有機能 → 任意フィーチャ8NII合同輪講

任意フィーチャの中で、顧客の要求を

満たすために必要なフィーチャを選ぶ

選ばれなかったフィーチャは取り外す

任意フィーチャは、

取り外し可能である必要がある

可変性が高い：任意フィーチャが取り外し可能

可変性が高い2（可変性が高いとは）

9NII合同輪講

CPP（C Preprocessor）の #define と #ifdef

• CPP：コードをコンパイルする前に、

前処理を施す

• #define CONST （#undef CONST）

→ CONST を定義 （CONST を未定義）

• #ifdef CONST ～ #endif

→ CONST が定義されていたら、

～の部分をコンパイル・実行

10NII合同輪講

• ＃define TXN と ＃undef TXNで、任意フィーチャを取ったり付けたりできる

11

CPPを使った可変性の実現

必須フィーチャ：スタック＋任意フィーチャ：ロック

NII合同輪講

関連研究（CPP的側面）

• An EmpiricalAnalysis of C Preprocessor

Use. （TSE’02）

CPPの包括的な分析（可変性の実装は未考慮）

• Can we Refactor Conditional Compilation

into Aspects? （AOSD’09）

#ifdefを使ったアスペクト指向拡張を提案12

NII合同輪講

関連研究（SPL的側面）

• Granularity in Software Product Lines.

（ICSE’08）

• A Model of Refactoring Physically and

Virtually Separated Features.

（GPCE’09）

再利用資産の可変性の実現に関して議論

可変性の実用性に関して議論していない13

NII合同輪講

実用性へ向けた調査1（調査テーマ）

• プログラムサイズと可変性に関係はあるか？

–可変性を管理できる規模に影響

• 可変コード数が多いほど、フィーチャの散らばりと

縺れは深刻になるのか？

–保守性（解析性・変更性）に影響

• フィーチャの拡張はどのレベルの粒度まで及ぶか？

– フィーチャのモジュール化に影響

• 同種の拡張と異種の拡張の比率はどのぐらいか？

– Cのアスペクト指向言語拡張の容易性に影響14NII合同輪講

実用性へ向けた調査2（40ソフトウェア）

• 40ソフトウェア上にCPPを使った可変性を実現

15

※全部C言語

規模もドメインも様々 NII合同輪講

16

• 全コード行数（LOC）

→ ソフトウェア全体の規模を計測

• 全フィーチャ定数の数（NOFC）

• フィーチャに関連するコードの行数（LOF）

→ 可変性のあるコードの規模を計測

• 同じフィーチャ定数の発生頻度（SD）

→ フィーチャの散らばり度合を計測

調査項目とそれが意味するもの1

NII合同輪講

• コードに関連するフィーチャ定数の数（TD）

• ネストの深さ（AND）

→ フィーチャの縺れ度合を計測

• 粒度のレベル（GRAN）

→ フィーチャの粒度をレベルごとの出現頻度で

計測

• 拡張タイプ（TYPE）

→ 同種の拡張と異種の拡張の出現頻度を計測

17

調査項目とそれが意味するもの2

NII合同輪講

調査結果1

• プログラムサイズと可変性に関係はあるか？

– コード行数が増えると、フィーチャの数も増える（a）

– フィーチャの数が増えると、可変コード数も増える（c）

– プログラム中の可変コード数が占める割合は、

プログラムサイズとは無関係（b）

18NII合同輪講

調査結果2• 可変コード数が多いほど、フィーチャの散らばりと

縺れは深刻になるのか？

– 可変コード数とフィーチャの散らばりは無関係（a）

– 可変コード数とフィーチャの縺れは無関係（b）

– 可変コード数と入れ子の深さは無関係（c）19NII合同輪講

• フィーチャの拡張はどのレベルの粒度まで

及ぶか？

– GL（プログラムレベル）：46±12%

– FL （関数レベル） ： 33±9%

– BL （ブロックレベル）： 19±7%

– SL （行レベル） ：

– EL （式レベル） ： ほとんどない

– ML （変数レベル） ：

フィーチャのモジュール化は有効

粗い

調査結果3

20

粒度

細かい

NII合同輪講

調査結果4

• 同種の拡張と異種の拡張の比率はどのぐらいか？

–同種の拡張（アスペクト指向に向いている）： 5±5%

→ コードの複数の場所に同じフィーチャがある

–異種の拡張（アスペクト指向に向いていない） ： 89±6%

→ コードの複数の場所に異なるフィーチャがある

–混合の拡張: 4±2%

アスペクト指向言語拡張は不必要

21NII合同輪講

調査結果のまとめ

• システムの規模が大きくなるほど、可変性の管理は大変

• システムの規模が大きくなっても、可変コードの散らばり・縺れは深刻にならない

• フィーチャの拡張は粗い粒度の場合が大部分なので、フィーチャのモジュール化に与える悪影響は少ない

• 大部分が異種の拡張なので、

アスペクト指向開発の恩恵は受けられない22

NII合同輪講

研究の今後の展望

• この研究で洗い出された大量のデータは、

サポートツールのさらなる研究などに役立つ

–他のドメインのソフトウェアも調査し、今回の調査結果と比較する

–より多くのソフトウェアに対応できるようにツールを改良する

–データの収集を続けることでソフトウェアの適応と進化の手掛かりとなる

–粒度や同種・異種の拡張に基づいてフィーチャを自動で判別し、自動で#ifdefをつけるツールを

作成する 23NII合同輪講

まとめ

SPLでは可変性の高い再利用資産開発が重要

CPPを使うと可変性の高い再利用資産を実現可能

40ソフトウェア上に、CPPを使った可変性を実現し

実用性の観点から調査

可変性の高い再利用資産に関する

実用化に向けた調査結果を示した24NII合同輪講

私見

• 長所

– 可変性の高い再利用資産開発を、実装レベルで分析している

– フィーチャのモジュール化・アスペクト指向拡張など、

流行りの技術に対する有効性についても考察している

• 短所

– 可変コードの散らばり・縺れ度合いは開発者の能力に

依存するのでは？

– CPPの#ifdefだらけの文は解析性・変更性に悪影響

→ #ifdefを消して、かつ可変部分がわかるような表示方法を

適用したツールが必要

25NII合同輪講

附録

ここからは、発表に関連する項目を記載

26NII合同輪講

コード中のフィーチャを判別する1

（フィーチャ判別の問題）

• コード中からフィーチャを判別するには、

深いドメイン知識が必要

27

typedef struct T_node {

int item;

struct T_node *next;

struct T_node *prev;

} node;

node *first = NULL;

node *last = NULL;

void insert(node *elem) {

node *a = NULL;

node *b = NULL;

node *c = NULL;

node *e = NULL;

node *tmp = NULL;

if (NULL == first) {

first = elem;

}

}

黒:T_node

赤:DLinked

青:Sortalgotypedef struct T_node {

int item;

struct T_node *next;

struct T_node *prev;

} node;

node *first = NULL;

node *last = NULL;

void insert(node *elem) {

node *a = NULL;

node *b = NULL;

node *c = NULL;

node *e = NULL;

node *tmp = NULL;

if (NULL == first) {

first = elem;

}

}

NII合同輪講

• コードをAST（Abstruct syntax tree）に自動変換

→ プログラムの構造がわかりやすくなる

28

コード中のフィーチャを判別する2

（srcmlによるAST変換）

関連付けられる

AST

NII合同輪講

コード中のフィーチャを判別する3

（CIDEによるフィーチャの視覚化）

• 関連付けられたフィーチャが色でわかる

29NII合同輪講

コード中のフィーチャを判別する4

（CIDEの機能説明）

• Feature Code

– フィーチャの要素と、それに対応する部分の

コードの色が変わる

• Overlapping Features

– コードに対応するフィーチャが複数ある場合、

色が混ざる

• Hidden Code

–不必要だと判断したフィーチャは、

隠すことができる30NII合同輪講

• ASTでも判別できなそうなら…

プログラムの仕様書を見る

プログラムを動作させてみる フィーチャモデルを作成する

ゴールモデルを書いてみる

31

コード中のフィーチャを判別する5

（フィーチャモデルの作成）

構造的に対応

AST

フィーチャモデル

NII合同輪講

ツールを使って自動化している部分と、手作業でやってる部分

• 自動化

– srcml：ソースコードからASTへの変換

（http://www.sdml.info/projects/srcml/）

– CIDE：フィーチャの視覚化

（http://wwwiti.cs.unimagdeburg.de/iti_db/research/cide/）

– cppstats：各メトリクスの計測

（http://fosd.de/cppstats/）

• 手作業

– フィーチャの判別

– #ifdefの付加

– コードの記述方法の統一32

NII合同輪講

同種・異種の拡張とアスペクト指向

アスペクト指向は、横断的機能（複数のクラスに出現する機能）のカプセル化を目指す

同じ処理を何回も記述する必要がなくなり、

プログラムが簡素化する

• 同種の拡張が多い場合、横断的機能が多い

• 異種の拡張が多い場合、横断的機能が少ない

33NII合同輪講