提案システム - Software Engineering Laboratory

関数クローン変更管理システム
の開発と評価
井上研究室
佐野 真夢
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
コードクローン
• 同一または類似した部分を持つコード片のこと
– ソースコードのコピーアンドペーストなどにより生じる
• ソフトウェアの保守コストを大きくする要因
あるコード片に
バグがあれば
他のコードクローンにも
バグがあるかもしれない
調査の手間
クローンセット
コードクローン
2
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
クローンの分類[1]
分類
タイプ1
タイプ2
タイプ3
タイプ4
定義
空白, コメント等のコーディングスタイルを除いて完全に
一致している
タイプ1 に加え, ユーザ定義名や型の違いを除いて構文上
一致している
タイプ2 に加え, 文が挿入・変更・削除されている
構文上は異なる実装だが, 類似処理を実行している
(while文とfor文など)
各タイプに応じたクローン検出ツールが存在している
[1] Roy et, al., Comparison and Evaluation of Code Clone Detection Techniques and Tools: A Qualitative Approach, Science of Computer
Programming, 2009
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
クローンの変更管理の必要性
• クローンを修正する場合, 他クローンの同時修
正を検討する必要がある
• 大規模なソフトウェアほど多くのクローンを含む
– 修正の度に, クローンを検出し, 手作業で修正され
たかどうか調査するのは非効率
コードクローン変更を自動管理するシステムが必要
4
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
CloneNotifier[2]
クローンの同時修正を支援するための変更管理システム
ソースコードの
コードクローンの検出
取得
※タイプ1, 2
版管理システム
クローン検出ツール
CCFinder
変更された
コードクローンを把握
コードクローンの
変更を調査
開発者
コードクローンの
変更情報の提示
[2] 山中ら, コードクローン変更管理システムの開発と実プロジェクトへの適用, 情報処理学会論文誌, 2013.
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
コードクローン
変更管理システム
5
問題点
• CloneNotifierはタイプ3, 4 のクローンを検出できない
– 文が挿入・変更・削除されたクローン
– 構文上の実装が異なるが, 処理は同じクローン
• 検出粒度が小さい分, 重要度の低い結果も多く検出
される
void AscendingSort(int list[])
{
比較対象のミス
void DescendingSort(int list[]) {
for(i = 0; i < n-1; i++) × j+1 → ○for(i
j-1 = 0; i < n-1; i++)
for(j = n-1; j > i; j--)
for(j = n-1; j > i; j--)
if(list[j+1] > list[j]) {
if(list[j+1] < list[j]) {
修正: if(list[j-1] > list[j]) {
修正: if(list[j-1] < list[j]) {
temp = list[j];
temp = list[j];
list[j] = list[j-1];
list[j] = list[j-1];
list[j-1] = temp;
list[j-1] = temp;
比較演算子が異なる
}
}
→
タイプ3
}
}
検出できない同時修正の例(タイプ3)
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
山中らのクローン検出ツール[3]
• テキストマイニング技術を利用したクローン検出ツール
• 関数単位でクローンを検出する
• タイプ1~4 の全てのクローンを高速に検出可能
Function A
ワード 回数
000
000
xxx
3
yyy
2
・・・
・・・
Function A
𝑎1 , 𝑎2 , 𝑎3 , …
類似度
0.95
0.70
Function B
ワード 回数
ソースコード
入力
Function A
Function B
xxx
2
yyy
4
・・・
・・・
ワード抽出
Function B
𝑏1 , 𝑏2 , 𝑏3 , …
特徴ベクトル
計算
Function C
Function D
Function E
クラスタリング
[3] 山中ら, 情報検索技術に基づく高速な関数クローン検出, 情報処理学会論文誌, 2014.
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
0.70
0.90
・・・
関数対 クローン
Function A

Function B
Function C
Function D
Function C
Function E
Function D

Function E
・・・
・・・
クローン検出
7
研究概要
• 山中らのクローン検出ツールを利用し, 新たな
関数クローン変更管理システムを開発
– CloneNotifier を改変する形で実装する
• 開発したシステムの評価
8
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
関数クローン変更管理システム
入出力仕様の
違いに対応
ソースコードの
取得
版管理システム
変更された
コードクローンを把握
コードクローンの検出
※全タイプ
山中らの
クローン検出ツール
出力仕様の違いによる.
変更されたかの判断に必要
コードクローンの
変更情報の提示
開発者
出力に関数名の
情報を追加
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
クローン位置情報
の特定
コードクローンの
変更を調査
関数クローン
変更管理システム
9
提案システムの出力の例
New Clone Set 新たに増えたクローン
クローンセットID:0
ID
分類
ファイル名
位置
メソッド名
0.0
ADDED
src\backend\parser\parse_expr.c
619.1-630.1
transformAExprAnd
0.1
ADDED
src\backend\parser\parse_expr.c
632.1-643.1
transfomrAExprOr
0.2
ADDED
src\backend\parser\parse_expr.c
682.1-706.1
transformAExprDistinct
Changed Clone Set 変更されたクローン
クローンセットID:1
ID
分類
ファイル名
位置
1.0
MODIFIED
src\backend\access\rtree\rtscan.c
157.1-203.1
rtmarkpos
1.1
MODIFIED
src\backend\access\rtree\rtscan.c
・
・
・
205.1-251.1
rtrestpos
Deleted Clone Set
メソッド名
消滅したクローン
クローンセットID:4
ID
分類
ファイル名
位置
メソッド名
4.0
DELETED
src\backend\access\gist\gistget.c
127.1-212.1
gistnext
4.1
DELETED
src\backend\access\rtree\rtget.c
125.1-210.1
rtnext
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
評価実験
• CloneNotifierと提案システムの比較評価
– 評価A. 提案システムのみが検出可能なクローンはどれく
らいあるかの調査
• CloneNotifierでほとんどの修正クローンが検出可能なら, 提案シ
ステムの有用性が示せない
– 評価B. クローン変更管理システムとしての性能の評価
• 評価対象
– PostgreSQL[4]
• OSS のデータベース管理システム(C言語)
• 2005/01/01 ~ 2005/06/30 の 6ヶ月間
• 1週間単位で区切り
[4] http://www.postgresql.org/
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
評価A. 概略
• 評価対象に提案システムを適用し, 検出結果
のタイプ3, 4クローン修正の数を調べる
タイプ3, 4
タイプ1, 2
合計
126
219
345
一貫した 非一貫した 他に適用
整形
合計
修正
修正
不能な修正 コメントのみ
73
16
32
5
126
CloneNotifier で検出できない 89件の
有用なクローン修正事例を検出できた
12
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価B. 手順
1. 各システムで, 評価対象(PostgreSQLの全26期
間の変更)における変更クローンセットの集合を
検出する
2. 各システム, 集合から50件ずつ結果をランダムに
選択する
– 手作業が入るため, 現実的に調査可能な数
– 母集団の数が4倍近く異なるため合わせる
3. 2つの評価尺度(後述)に基づき, 有用な修正
クローンセットの割合を求める
– 有用/不要の判断ができないものは分母から除外する
13
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価B. 評価尺度
• 尺度1. 一貫した修正が行われた, または,
必要な可能性のあるクローンセットか
cloneset.B
cloneset.A
clone1
clone2
同様の修正が行われた
有用
clone1
cloneset.D
cloneset.C
clone2
clone1
同様の修正を適用できる
可能性がある
clone2
同様の修正を適用不可
有用
有用でない
clone1
clone2
clone3
削除
追加
修正が無い
(クローンの構成が変わった)
除外
• 尺度2. 変更後も同じクローンセットとして追跡できているか
cloneset.A
clone1
cloneset.A
clone2
修正前
cloneset.B
clone1
clone2
clone1
not clone
clone2
clone1
cloneset.C
clone1
clone2
除外
追加コード
修正後
not clone
clone1
有用
cloneset.D
clone2
clone1
clone2
有用でない
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
not clone
削除コード
clone1
clone2
除外
14
評価B.結果(尺度1)
一貫した修正が行われた, または, 必要な可能性のある
クローンセットをどれくらい検出できているか
有用
有用でない
合計数 除外数
CloneNotifier 56.4 %(22) 43.6 %(17) 39
11
提案システム
15
71.4 %(25) 28.6 %(10) 35
• 提案システムの方が有用なクローンセットの割合が
高い
– 提案システムの方が精度は高い
– ただし, 母集団は排他的で, 完全に同じ修正箇所を検出し
ている事例は存在しなかった
15
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価B.結果(尺度2)
変更後も同じクローンセットとして追跡できているか
有用
有用でない
合計数 除外数
CloneNotifier 47.1 %(16) 52.9 %(18) 34
16
提案システム
8
71.4 %(30) 28.6 %(12) 42
• 提案システムの方が追跡を継続している割合が高い
– 提案システムの方が, クローンを継続して変更管理できる
– 一貫しない変更が起きても, タイプ3クローンとして追跡でき
たため
16
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
まとめと今後の課題
• 新たな関数クローン変更管理システムの開発
• 開発したシステムの有用性評価
– CloneNotifierでは検出できない多くの事例を検出した
– CloneNotifierと比較し, 精度は高かった
– ただし, 結果が排他的のため, 組み合わせて使う方が
望ましい
• 今後の課題
– より多くのプロジェクトに対する評価
– ユーザ調査, インタフェース等の改良
– 両システムを統合した場合の評価
17
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University