スライド 1

コードクローンの複雑度メトリクス
を用いた開発者の特徴分析
東誠† 肥後芳樹† 早瀬康裕†
松下誠† 井上克郎†
†
2008/9/2
大阪大学大学院情報科学研究科
SES2008
1
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
コードクローン
• ソースコード中に存在する同一または類似し
たコード片
– 以降単にクローンと呼ぶ
• クローンの検出と除去に関する研究
– 検出アルゴリズム
– 除去対象の発見
ソースファイルF1
ソースファイルF2
コードクローン
コードクローン
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
2008/9/2
クローンが保守性に与える影響
ソフトウェア保守を困難にする場合がある
– バグ修正などコード変更をする際,全てのクローンに対し
て同じ変更を検討する必要がある
– 保守作業の手間が増大
保守性を悪化させるとは限らない[1]
例 : マルチプラットフォーム対応のソースコードを書く際に
作成するクローン
→ 保守性に対するデメリットだけではなくメリットもある
[1]C. Kapser and M. W. Godfrey: ““Cloning Considered Harmful” Considered
Harmful”, Proceedings of the 13th Working Conference on Reverse Engineering
(WCRE 2006), pp.19-28, 2006.
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
2008/9/2
クローンの管理の必要性
管理の一例:より保守性を悪化させる可能性
の高いクローンを優先して除去する
例:複雑度の高いクローン
全てのクローンに同じ変更をする際,保守作業の手間
がより増大する
→ 除去するクローンの判断材料が必要
例:複雑度の変化
→ 今は簡単だが将来複雑になるクローンを除去
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
2008/9/2
本研究の着目点
複雑度の変化の予測に,開発者を利用
開発者は特定のクローンを編集し続け,その複
雑度を一定の傾向で変化させ続ける
• 開発者は同じ箇所を連続して編集する[3]
• 開発者の役割や目的が編集内容に反映される
例:編集するコード片の長さ,条件分岐の数
[3]H. Siy, P. Chundi and M. Subramaniam: “Summarizing developer work history
using time series segmentation: challenge report ”, Mining Software
Repositories 2008(MSR 2008), pp.137-140.
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
2008/9/2
本研究の目的
• 目的:クローンの新しい管理例を提案
• 手段:クローンの複雑度の変化を用いて,各
開発者のクローンに対する編集傾向を調査
編集傾向 : 各開発者のソースコード編集時に,ク
ローンの複雑度の変化に表れる,以下の特徴
開発者Aはクローンの複雑度の増加量が
• 他の開発者の平均よりも大きい傾向にある
• 他の開発者の平均よりも小さい傾向にある
• 他の開発者の平均と差があるとはいえない
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
2008/9/2
編集傾向の調査方法
1 ソースコードの
版管理システム
(ソフトウェアの
編集履歴を
格納するシステム)
スナップショット
の取得
2 クローン
検出
3 クローン対応関係
の抽出
開発者
メ
開発者A
ト
リ α {+2, 0, …}
ク
ス β {0, -3, …}
A
B
開発者B
α 大
{0, 0, …}
β
{+1, 0, …}
4 複雑度メトリクスの
値の変化の取得
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
小
+ -
5 編集傾向の
決定
7
2008/9/2
ステップ1 : スナップショットの取得
• 版管理システムを用いる
ソフトウェアの編集履歴を格納するシステム
編集されたファイルの変更差分,編集した開発者,編集日時
• 各開発者がソースコードを編集した直前・直後の時
点のスナップショットを取得
版管理システム
開発者Aが
編集
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
開発者Bが
編集
8
2008/9/2
ステップ2 : クローンの検出
各スナップショット中のクローンを検出
– 同じスナップショット内で類似したコード片を検出
– 異なるスナップショット間で類似したコード片は検
出しない
開発者Aが
編集
開発者Bが
編集
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
2008/9/2
ステップ3 : クローン対応関係の抽出
複雑度の変化を取得するため,クローン対応
関係を抽出する
クローン対応関係 : 連続する2つのスナップショッ
ト中の同じ位置にあるクローン間の関係[2]
クローン
対応関係
クローン
対応関係
クローン
対応関係
開発者Aが
編集
クローン
対応関係
開発者Bが
編集
[2]M. Kim and D. Notkin : “Using a clone genealogy extractor for understanding and supporting evolution of code clones”, Proceedings of the
2nd International Workshop on Mining Software Repositories, pp.17-21, 2005.
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
2008/9/2
ステップ4 :複雑度メトリクスの値の変
化の取得
1. クローンの様々な複雑度メトリクスの値を計算する
複雑度メトリクス:値が大きいほどクローンが複雑
2. クローン対応関係にある2つのクローン間のメトリ
クス値の差を計算する
3. クローンが存在するスナップショットを編集した開
発者ごとに,メトリクス値の変化を集める
α : +2
β:0
α:0
β : +1
α:0
β : -3
開発者Aが
編集
α:0
β : -4
開発者Bが
編集
開発者A
開発者B
メトリクスα
{+2, 0}
{0, 0}
メトリクスβ
{0, -3}
{+1, -4}
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
2008/9/2
ステップ5 : 編集傾向の決定
•
•
メトリクス値の変化から開発者間の差を検
定し,その結果から編集傾向を決定
編集傾向の決定手順
1.
2.
3.
4.
開発者間で差があるメトリクスを特定
他の開発者と差がある開発者を特定
メトリクス値の変化の傾向を分類
開発者ごとに編集傾向を決定
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
2008/9/2
編集傾向の決定手順 1/4
1. 開発者間で差があるメトリクスを特定するた
め,Kruskal-Wallis検定を使用
Kruskal-Wallis検定:k組のすべての標本に対
し,平均値間に有意差があるかを検定
→ 各メトリクス値の変化を,開発者ごとに集め
た標本に対し,有意差の有無を検定
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
2008/9/2
編集傾向の決定手順 2/4
2. 差があると検定されたメトリクスについて,
他の開発者と差がある開発者を特定するた
め, Mann-WhitneyのU検定を使用
Mann-WhitneyのU検定:2組の標本に対し,平
均値間に有意差があるかを検定
→ 差があると検定されたメトリクスについて,各
開発者とその他の開発者全員で分けた標本に
対し,有意差の有無を検定
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
2008/9/2
編集傾向の決定手順 3/4
3. 差があると検定された開発者の編集による
メトリクス値の変化の分布を調べ,変化の
傾向を分類
メトリクス値の増加量は他の開発者の平均より
– 大きい傾向にある
– 小さい傾向にある
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
2008/9/2
編集傾向の決定手順 4/4
4. 開発者ごとに,全ての複雑度メトリクスに対
する変化の傾向を求め,編集傾向を決定
– 増加量が大きいメトリクスの方が多い
→ 複雑度の増加量が大きい
– 増加量が小さいメトリクスの方が多い
→ 複雑度の増加量が小さい
– 両者の個数が等しい
→ 他の開発者の平均と差があるとはいえない
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
2008/9/2
ケーススタディ 1/2
• 実際のソフトウェア編集履歴に対して調査
調査方法の適用によって得られる情報を知る
• 調査内容
– 調査対象
• PostgreSQLの編集履歴
• 1997/01/01~1999/06/30を半年間ずつに分け,各期
間中の編集履歴に対して調査
各期間は古い順に1から5まで通し番号をつける
– クローン検出:CCFinderX
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
2008/9/2
ケーススタディ 2/2
– 使用する複雑度メトリクス
•
•
•
•
•
LEN : クローンの長さ(トークンの数)
TKS : クローン中のトークンの種類数
LOOP : クローン中のループ文の数
COND : クローン中の条件分岐の数
McCabe : LOOP+COND
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
2008/9/2
調査対象期間中の開発者
1997/01/01~1999/06/30 に開発に参加
した開発者は13名
クローンを編集した開発者は12名(A~L)
期間 開発に参加した クローンを編集した クローンを編集した開発者
開発者数
開発者数
1
6
5 C, F, H, I, J
2
5
4 C, F, H, I
3
7
6 C, F, G, H, I, K
4
8
7 A, C, D, F, G, H, I
5
10
10 A, B, C, D, E, F, G, H, I, L
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
2008/9/2
検定結果 1/2
開発者
期間
LEN
メ
ト TKS
リ LOOP
ク COND
ス
McCabe
開発者の
編集傾向
A
4
B
5
5
大 小
C
1
2
小 大
3
D
4
5
4
大
E
5
5
小
大 大
小 小
大
小
大
小
大
小 小
小 小
小 小
小 小
+ + + - = = - - = - -
• 複雑度の増加量が大きい開発者 : A, B
• 複雑度の増加量が小さい開発者 : C, D, E
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
2008/9/2
検定結果 2/2
開発者
期間
LEN
F
H
I
J K L
1 2 3 4 5 3 4 5 1 2 3 4 5 1 2 3 4 5 1 3 5
メ
ト TKS
リ LOOP
ク COND
大
ス
McCabe 大
開発者の
編集傾向
G
大
小 大
小 大 小 小 小 小 小
大
大 小 小
大
小
大 小
小
大 大
大 大 小
大 小 小 大 小
大
大 大 小
小 小 大 小
大
+ = + - = + + - = = - - + - + - + - = = =
• 期間によって傾向が変化する開発者 : F, G, H, I
• 明確な傾向が見つからなかった開発者 : J, K, L
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
2008/9/2
編集傾向を用いたクローンの管理
1/3
開発者がある箇所を編集すると,次も同じ箇
所やその付近を編集する傾向がある[3]
複雑度の増加量が大きい傾向の開発者が,
やや複雑なクローン付近を編集すると,次に
そのクローンを編集する可能性が高い
→ 複雑なクローンになり,保守性を悪化
[3]H. Siy, P. Chundi and M. Subramaniam: “Summarizing developer work history
using time series segmentation: challenge report ”, Mining Software
Repositories 2008(MSR 2008), pp.137-140.
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
2008/9/2
編集傾向を用いたクローンの管理
2/3
開発者
期間
A
4
B
5
5
C
1
2
3
D
4
5
4
E
5
5
開発者の
+ + + - = = - - = - -
編集傾向
• やや複雑なクローン付近を編集した開発者を発見
• 開発者A, Bが編集したクローンは,その後複雑にな
る可能性が高い
→ すぐにクローンを除去した方が良い
• 開発者C, D, Eが編集したクローンは,その後複雑
になる可能性が低い
→ クローンの除去を急がなくて良い
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
2008/9/2
編集傾向を用いたクローンの管理
3/3
開発者
期間
F
G
H
1 2 3 4 5 3 4 5 1 2 3 4 5 1
I
J
K L
2 3 4 5 1 3
5
開発者の
+ = + - = + + - = = - - + - + - + - = = =
編集傾向
開発者F,G,H,Iは期間で傾向が変化している
– 開発者A,B,C,D,Eの傾向が変化することもある
– 開発者J,K,Lに明確な傾向が見つかることもある
→ 調査を続け,傾向が変化すれば開発者
への対処を変更する
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
2008/9/2
まとめと今後の課題
• クローンの複雑度で各開発者の特徴を分析
– 開発者ごとに異なる特徴がある
– 各開発者の特徴によるクローンの管理例を提案
• 今後の課題
– 他のメトリクスによる開発者の特徴分析
– 開発者以外の要因(モジュール等)の影響の除外
– クローンのメトリクス値の変化予測
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
2008/9/2
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
2008/9/2
4 : 複雑度メトリクスの値の変化の取
得
1. クローンの様々なメトリクス値を計算する
2. クローン対応関係にある2つのクローン間のメトリ
クス値の差を計算する
3. クローンが存在するスナップショットを編集した開
発者ごとに,メトリクス値の変化を集める
•
•
開発者によって編集されたクローン
複雑度メトリクスの値が変化したクローン
α : +2 β : 0
編集なし
α : 0 β : +1
編集あり
α : 0 β : -3
編集なし
α : 0 β : -4
編集あり
開発者Aが
編集
開発者Bが
編集
開発者B
開発者C
メトリクスα
{+2}
{0, 0}
メトリクスβ
{3}
{+1, -4}
開発者Cが
編集
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
2008/9/2
CKメトリクスの例
• WMC (weighted methods per class):あるク
ラスのメソッドの重さ(複雑さの総和)
• NOC (number of children):あるクラスのサ
ブクラスの数
値が大きいほど、サブクラスへの影響力が強い
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
2008/9/2
保守性を悪化させないクローンの例
1/2
クローンを作成
する方法
クローンを作成
しない方法
プラットフォームA
コード片変更
クローン作成
クローン
変更
プラットフォームB
クローン作成
コード片変更
プラットフォームC
コード片が
複雑に
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
クローン
変更
29
2008/9/2
保守性を悪化させないクローンの例
2/2
• クローンを作成せず,様々なプラットフォーム
に対応できるコード片を書く方法
ソースコードが複雑になっていく
• 前のコード片のクローンを作成し,そのクロー
ンを新しいプラットフォームに対応するように
変更する方法
– 現在のプラットフォームの安定性が維持される
– 各プラットフォームの保守を独立して行える
SES2008
Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
30
2008/9/2