【バグ管理の作法】
エンピリカルソフトウェア工学に触れる
第4回:法則を発見し、開発支援へつなげるアプローチの事例
著者:奈良先端科学技術大学院大学 松本 健一
公開日:2007/12/26(水)
バージョン間にまたがったコードクローン分析
2つ目の事例は、コードクローン分析である。エンピリカルアプローチとしての段階は「支援の実現」、粒度は「プロダクトライン」である。
コードクローンとは、プログラムコード(ソースコード)中に何度もあらわれる類似したコード片(重複コード)のことである。コードクローンの多くは安易なコピー&ペーストによって生まれるとされており、大規模ソフトウェアの保守において問題となっている。
すなわちプログラムコード中のある箇所にバグが発見され修正された場合、その箇所と類似している箇所(クローン関係にある箇所)についても同様の修正が必要であるかどうかの検討が必要となるためである。
しかし、多くの場合はそれらコードに若干の加筆修正が施されており、単純な文字列検索などでは、膨大なプログラムコードの中のどこにどれくらいそうした箇所が存在するのかを網羅的に把握することは困難だ。
開発支援への応用を考えた場合、ソフトウェアのあるバージョンを構成するプログラムコード(の集合)だけを対象にコードクローン分析を行うのではなく、バージョン間でのクローン関係、すなわちクローンの履歴や変遷を明らかにすることも重要になってくる。
例えばあるソフトウェアのバージョンF(t-1)において、クローン関係にあったコード片B-1〜B-5のうち、次のバージョンF(t)において、B-1とB-2はそのまま利用されたが、B-3、B-4、B-5は統廃合され、新たなコード片C-1〜C-3となったとする。こうした場合、バージョンF(t)だけを分析しても、「コード片B-1〜B-2」と「コード片C-1〜C-3」の間にクローン関係があると判断することは難しい。コード履歴・クローン履歴を考慮した分析が、より多様なコードクローンの検出を可能とする。
クローン履歴閲覧システム
(画像をクリックすると別ウィンドウに拡大図を表示します)
この図はクローン履歴閲覧システムの画面例である。Eclipse上で動作し、クローン行数の変遷グラフ、クローンヒストリーグラフ、各時点でのクローン内容(どの開発者が編集したか)、開発者ごとのクローン追加・編集・削除回数等のメトリクス値、などを表示することができる。
もちろん、すべてのコードクローンが悪者というわけではない。ソフトウェアを複数の開発者で開発すれば、定型処理においてコードの重複は当然発生し、デザインパターンを構成しているコードやある種のイディオムも存在する。またプログラミング言語に構造化例外処理や汎用型といった機能がないために、それらを1つのルーチンとしてまとめることができない場合もある。
実際、コードクローンが存在しないソフトウェアは非常に稀で、オープンソフトウェアの中ではコードの1割程度がクローンであるとか、20年以上保守が行われてきたあるソフトウェアではモジュールの半数にコードクローンが含まれていたという報告もある。大切なのはプログラムコード中のどこにどのようなクローンがどれくらい存在するのかを把握し、保守やデバッグ、リファクタリングなどに活用することである。
コードクローンに関する研究、クローン検出ツールなどについては、R2D2: Rapid and Runtime Duplication Detector、コードクローン関連ツール、CCFinderホームページなどを参照のこと。
また、今回はすべてを紹介できなかったが、エンピリカルデータに基づいて発見された法則を利用することで可能となる開発支援の例を一部紹介する。まず、プロジェクトの工数、日程、品質を高精度で見積もることができる(ワンクリック見積&データ品質診断ツールMagi)。また、進行中のプロジェクトをコントロールすることができる。さらに進行中のトラブルプロジェクトを再計画することも可能だ。
他にも、組織内の全プロジェクトに対して、リソース割り当ての全体計画を作成する場合にも利用できる。そして開発プロセスがどの程度改善されたかをモニターすることも可能である。これらについては、「初めて学ぶソフトウエアメトリクス 〜プロジェクト見積もりのためのデータの導き方〜」(L. H. Putnam, W. Myers著、山浦 恒央訳、2005年日経BP刊)が参考になるだろう。 次のページ