ソフトウェア保守のためのコードクローン情報検索ツー

ソフトウェア保守のための
コードクローン情報検索ツール
特別研究報告
井上研究室
泉田聡介
研究の背景(1/2)
コードクローン

ソースコード中に含まれる同一もしくは類似し
たコードのこと, いわゆる“重複したコード”
クローン
H15/02/26
平成14年度特別研究報告
2
研究の背景(2/2)
コードクローンはソフトウェア保守を困難にする


コードクローンにバグがあった場合、全てのコードクロー
ンについて修正を考慮しなければならない
機能追加の場合も同様
コードクローン検出ツールCCFinder




ソースコードをトークン単位で直接比較することによりク
ローンを検出
数百万行規模のシステムにも実用時間で解析可能
実用的に意味のないクローンを検出しない
様々な企業のソフトウェアにも適用している
H15/02/26
平成14年度特別研究報告
3
CCFinderの出力
対象ファイルのID
(file 0 in group 0)
クローンの位置
file 0.1:1615～1636行
file 1.0:
57～83行
がクローンである
#version: ccfinder 4.5h
#langspec: JAVA
#option: -b 30,1
#option: -k: #option: -r abcdfikmnprsv
#option: -c w-f-g
#begin{file description}
0.0 130 90
D:\test1.java
0.1 700 1980 D\GUI.java
0.2 380 560 D:\search.java
:
:
:
#end{file description}
#begin{syntax error}
#end{syntax error}
#begin{clone}
0.1 1615,12,2291 1636,34,2325
0.2 1646,15,2334 1665,12,2382
0.21 1878,12,2767 1909,12,2808
0.21 82,12,61
136,15,150
0.217 136,15,150
150,1,198
:
:
:
#end{clone}
検出結果はクローンの位置情報のみであり、 1.0
1.0
1.0
その結果を直感的に理解することは困難
1.0
57,12,19 83,34,53
34
94,15,60 120,12,108 48
57,12,19 94,15,60
41
57,12,19 120,12,108 89
1.0 94,15,60 120,12,108 48
ユーザの利用目的に応じた
ユーザインタフェースが求められている
平成14年度特別研究報告
H15/02/26
4
研究の目的
CCFinderを利用したコードクローン情報検
索ツールの試作

H15/02/26
ユーザが入力したコード片に対して，そのコー
ドクローンを含むファイルを検索し、提示する
平成14年度特別研究報告
5
利用状況の想定修正箇所の特定
機能を追加
デバッグへの適用
修正箇所に関するクローン
追加前のコード片のクローン
の検索
を検索
機能追加時の使用
発見したクローン全てに対し、
修正コードを適用
クローン全てについて機
能追加の是非を検討
H15/02/26
平成14年度特別研究報告
6
クローン情報検索ツール
入力：ユーザが指定するコード片
検索対象ファイル名のリスト
出力：ユーザが指定したコード片のクローンを含
むファイルのリスト
 特徴
 簡単な操作
 検索結果のソースコード上での確認


ハイライト表示等
Javaで実装．サイズは約3千行．
H15/02/26
平成14年度特別研究報告
7
ツールの使用例(1/2)
ファイルのリストを入力
検索したいコード片
を入力
解析対象言語の選択
解析開始ボタン
H15/02/26
平成14年度特別研究報告
8
ツールの使用例(2/2)
起動画面
検索項目
の入力
検索結果
ソースコード
の確認
H15/02/26
平成14年度特別研究報告
9
評価実験
擬似デバッグへの適用

SourceForge で開発されている日本語入力シ
ステム「かんな」の修正例へ適用
 修正の対象となるコード片を検出できるか
 実行にかかる時間はどれくらいか

適用環境
 CPU Pentium4 2GHz、メインメモリ 512MB
 OS WindowsXP HomeEdition SP1
 Java VM JDK1.4付属のもの
H15/02/26
平成14年度特別研究報告
10
「かんな」の修正例
「かんな」のver3.6とver3.6p1間の修正例


セキュリティー問題の修正において、バッファ
処理の前にオーバーフローを調べる処理を追
加する．
ほぼ同じ修正を行っている部分が21ヵ所あっ
た．
H15/02/26
平成14年度特別研究報告
11
評価方法
以下の2つの方法の比較を行う．

grepを用いた検索
 修正箇所で使用されている変数“Request.type”で検索

本ツールを用いた検索
 入力コード片として，典型的なバッファ処理を行っている2行
を与えて検索
検索対象：かんなver3.6の全ソースコード
（約21,000行）
H15/02/26
平成14年度特別研究報告
12
結果
grep
本ツール
検索結果
243行（58箇所）
17箇所
検索時間
約1秒
約8秒
本ツールでの検索では，4箇所が検出されず


2行が連続していなかった
検出された17箇所は正しい
grepでの検索結果のうち134行（20箇所）が
修正箇所に関連していた
H15/02/26
平成14年度特別研究報告
13
f値を用いた比較
完全性、効率性からf値を求め比較
完全性 - 必要な情報のうち実際に検索された情報の割合
効率性 - 実際に検索された情報のうち必要な情報の割合
2  完全性  効率性
f値＝
完全性  効率性
grep
本ツール
完全性
効率性
f値
95%
81%
34%
100%
0.50
0.90
本ツールでの検索の方が効率的である
H15/02/26
平成14年度特別研究報告
14
まとめと今後の課題
ユーザが入力したコード片のクローンを検
索するツールの試作を行った
「かんな」の修正へ適用した
今後の課題


H15/02/26
実用性の向上
出力する結果の表示方法の検討
平成14年度特別研究報告
15
H15/02/26
平成14年度特別研究報告
16
H15/02/26
平成14年度特別研究報告
17
性能の評価
JDK1.4.01 Gemini
FreeBSD
?file ??万行 ?file ??万行 ?file ??万行
10行
30token
20行
30token
20行
50token
100行
30token
H15/02/26
平成14年度特別研究報告
18
適用実験概要(1/2)
適用対象

ＳｏｕｒｃｅＦｏｒｇｅで開発されている日本語入力システム
「かんな」
 約21,000行

「かんな」のバグ修正を行うことを想定
 実際のバグ修正履歴を用いた擬似的なデバッグ
修正すべき(実際に修正された)コード片を本ツールでどの程
度見つけることができるか

実行環境
 Ｐｅｎｔｉｕｍ４ 2GHz メインメモリ512MB
 OS Windows XP HomeEdition SP1
 Java VM JDK1.4付属のもの
H15/02/26
平成14年度特別研究報告
19
適用実験概要(2/2)
ir_debug(Dmsg(10,”ProcWideReq3 start\n”) );
buf += 用いたバグ修正履歴
HEADER_SIZE; Request.type3.context = S2TOS(buf);
buf += SIZEOFINT;
Request.type3.buflen = S2TOS(buf);
 ver3.6からver3.6p1
start\n”) );
:ir_debug(Dmsg(10,”ProcWideReq3
 バッファオーバーフローが起こるバグの修正
:
 該当バッファを扱う処理コードへバッファサイズチェックコード
!= SIZEOFSHORT *2)
:if(Request.type3.datalen
の追加
return(-1);
 修正が行われたのは30ヵ所(3ファイル)
 うち21ヵ所は同じようなコード片に対し、同じような修正を行っ
buf +=
HEADER_SIZE; Request.type3.context = S2TOS(buf);
buf +=ていた結果の分析
SIZEOFINT; Request.type3.buflen = S2TOS(buf);
:
:
:
H15/02/26
平成14年度特別研究報告
20

Download Report