コードクローンの複雑度メトリクスを用いた開発者の特徴分析 東誠†　肥後芳樹†　早瀬康裕† 松下誠†　井上克郎† 「大阪大学」の東です． コードクローンのメトリクス「ち」と 開発者の「そーかん」の「ちょーさ」 について発表します． 別刷り †　大阪大学大学院情報科学研究科 2008/9/2 SES2008

コードクローン ソースコード中に存在する同一または類似したコード片 クローンの検出と除去に関する研究 以降単にクローンと呼ぶ 検出アルゴリズム 除去対象の発見 まず，コードクローンについて説明します． コードクローンとは，ソースコード中に存在する 同一または類似したコード片です． コードクローンを，図を用いて説明します． 図には2つのソースファイルがあります． そしてソースファイルの色がついているコード片は コードクローンであり， それぞれ類似しています． 以降，コードクローンを単にクローンと呼びます． このようなクローンに対し、 従来は検出と除去が研究されてきました． ソースファイルF1 ソースファイルF2 コードクローン コードクローン SES2008 2008/9/2

クローンが保守性に与える影響 ソフトウェア保守を困難にする場合がある 保守性を悪化させるとは限らない[1] バグ修正などコード変更をする際，全てのクローンに対して同じ変更を検討する必要がある 保守作業の手間が増大 保守性を悪化させるとは限らない[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 2008/9/2

クローンの管理の必要性 管理の一例：より保守性を悪化させる可能性の高いクローンを優先して除去する → 除去するクローンの判断材料が必要 例：複雑度の高いクローン 全てのクローンに同じ変更をする際，保守作業の手間がより増大する → 除去するクローンの判断材料が必要 例：複雑度の変化 → 今は簡単だが将来複雑になるクローンを除去 「このことから」、 クローンを適切に管理する必要があると考えられるようになりました． クローン管理の例としては， 全てのクローンを取り除くのではなく、 必要なクローンだけを除去する ことが挙げられます． 例えば， 保守性を悪化させるクローンは除去し， 明確な理由があって作成したクローンは 除去せずに様子を見ることが 管理の一例として挙げられます． 管理って何？　という質問が出てきそう． 「(基準によって)クローンを複数のグループに区別して， 各クローンのグループに対して適切な処理を行うこと」 SES2008 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 2008/9/2

本研究の目的 目的：クローンの新しい管理例を提案 手段：クローンの複雑度の変化を用いて，各開発者のクローンに対する編集傾向を調査 編集傾向 : 各開発者のソースコード編集時に，クローンの複雑度の変化に表れる，以下の特徴 開発者Aはクローンの複雑度の増加量が 他の開発者の平均よりも大きい傾向にある 他の開発者の平均よりも小さい傾向にある 他の開発者の平均と差があるとはいえない SES2008 2008/9/2

編集傾向の調査方法 1 ソースコードの スナップショット の取得 2 クローン 検出 3 クローン対応関係 の抽出 4 複雑度メトリクスの 版管理システム (ソフトウェアの 編集履歴を 格納するシステム) 2 クローン 検出 開発者 3 クローン対応関係 の抽出 メトリクス A B α 大 β 小 ＋ － 開発者A 開発者B α {+2, 0, …} {0, 0, …} β {0, -3, …} {+1, 0, …} 4 複雑度メトリクスの 値の変化の取得 5 編集傾向の決定 SES2008 2008/9/2

ステップ1 : スナップショットの取得 版管理システムを用いる 各開発者がソースコードを編集した直前・直後の時点のスナップショットを取得 ソフトウェアの編集履歴を格納するシステム 編集されたファイルの変更差分，編集した開発者，編集日時 各開発者がソースコードを編集した直前・直後の時点のスナップショットを取得 版管理システム 開発者Aが 編集 開発者Bが 編集 SES2008 2008/9/2

ステップ2 : クローンの検出 各スナップショット中のクローンを検出 同じスナップショット内で類似したコード片を検出 異なるスナップショット間で類似したコード片は検出しない 次に，各スナップショットごとに， その中のクローンを検出します． この検出方法を，図を用いて説明します． 図では，3つの時刻に取得したスナップショットがあります． スナップショットにはそれぞれソースファイルの集合があります． そして，それぞれのソースファイルの集合を対象として コードクローンを検出しています． 開発者Aが 編集 開発者Bが 編集 SES2008 2008/9/2

ステップ3 : クローン対応関係の抽出 複雑度の変化を取得するため，クローン対応関係を抽出する クローン対応関係 : 連続する2つのスナップショット中の同じ位置にあるクローン間の関係[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 2008/9/2

ステップ4 :複雑度メトリクスの値の変化の取得 クローンの様々な複雑度メトリクスの値を計算する 複雑度メトリクス：値が大きいほどクローンが複雑 クローン対応関係にある2つのクローン間のメトリクス値の差を計算する クローンが存在するスナップショットを編集した開発者ごとに，メトリクス値の変化を集める 次に，メトリクス値の変化を取得します． この取得方法を，図を用いて説明します． 図では3つのスナップショットがあり， それぞれのスナップショット中のクローンを検出しています． これらのクローンに対し， まずは，様々なメトリクス値を計算します． 図では，アルファとベータというメトリクスを計算しています． 次に，クローン対応関係にある2つのクローン間の メトリクス値の差を計算します． 例えば，図の左上のクローン対応関係にある2つのクローン間では， アルファ，ベータの差はそれぞれ２，０となっています． 最後に， クローンが存在するスナップショットを編集した開発者毎に， メトリクス値の変化を集めます． 図のメトリクス値の変化を集めると，このような表になります． 表では，横軸に開発者，縦軸にメトリクスが並んでいます． そして表の要素には， 開発者によるメトリクス値の変化のリストが 記録されています． 図では，左上のメトリクス値の変化は， 開発者Bが編集した際に起こっているので， 表では開発者Bの列に記録されています． 開発者A 開発者B メトリクスα {+2, 0} {0, 0} メトリクスβ {0, -3} {+1, -4} α : +2 β : 0 α : 0 β : +1 α : 0 β : -3 α : 0 β : -4 開発者Aが 編集 開発者Bが 編集 SES2008 2008/9/2

ステップ5 : 編集傾向の決定 メトリクス値の変化から開発者間の差を検定し，その結果から編集傾向を決定 編集傾向の決定手順 開発者間で差があるメトリクスを特定 他の開発者と差がある開発者を特定 メトリクス値の変化の傾向を分類 開発者ごとに編集傾向を決定 SES2008 2008/9/2

編集傾向の決定手順 1/4 開発者間で差があるメトリクスを特定するため，Kruskal-Wallis検定を使用 Kruskal-Wallis検定：k組のすべての標本に対し，平均値間に有意差があるかを検定 → 各メトリクス値の変化を，開発者ごとに集めた標本に対し，有意差の有無を検定 SES2008 2008/9/2

編集傾向の決定手順 2/4 差があると検定されたメトリクスについて，他の開発者と差がある開発者を特定するため， Mann-WhitneyのU検定を使用 Mann-WhitneyのU検定：2組の標本に対し，平均値間に有意差があるかを検定 → 差があると検定されたメトリクスについて，各開発者とその他の開発者全員で分けた標本に対し，有意差の有無を検定 SES2008 2008/9/2

編集傾向の決定手順 3/4 差があると検定された開発者の編集によるメトリクス値の変化の分布を調べ，変化の傾向を分類 メトリクス値の増加量は他の開発者の平均より 大きい傾向にある 小さい傾向にある SES2008 2008/9/2

編集傾向の決定手順 4/4 開発者ごとに，全ての複雑度メトリクスに対する変化の傾向を求め，編集傾向を決定 増加量が大きいメトリクスの方が多い → 複雑度の増加量が大きい 増加量が小さいメトリクスの方が多い → 複雑度の増加量が小さい 両者の個数が等しい → 他の開発者の平均と差があるとはいえない SES2008 2008/9/2

ケーススタディ 1/2 実際のソフトウェア編集履歴に対して調査 調査内容 調査方法の適用によって得られる情報を知る 調査対象 PostgreSQLの編集履歴 1997/01/01～1999/06/30を半年間ずつに分け，各期間中の編集履歴に対して調査 各期間は古い順に1から5まで通し番号をつける クローン検出：CCFinderX 提案した調査方法を用いて， 実際のソフトウェア編集履歴に対して調査したので， その調査内容と結果について説明します． 調査対象は，PosgtgreSQLの編集履歴です． これを調査する際には， 97年の1月から99年の6月を半年間ずつに分け， 各期間中の編集履歴に対して調査しました． なお，各期間は古い方から順に番号をつけました． また，クローン検出には 「シーシーファインダーエックス」を用いました． SES2008 2008/9/2

ケーススタディ 2/2 使用する複雑度メトリクス LEN : クローンの長さ(トークンの数) TKS : クローン中のトークンの種類数 LOOP : クローン中のループ文の数 COND : クローン中の条件分岐の数 McCabe : LOOP+COND SES2008 2008/9/2

調査対象期間中の開発者 1997/01/01～1999/06/30 に開発に参加した開発者は13名 クローンを編集した開発者は12名(A～L) 期間 開発に参加した 開発者数 クローンを編集した クローンを編集した開発者 1 6 5 C, F, H, I, J 2 4 C, F, H, I 3 7 C, F, G, H, I, K 8 A, C, D, F, G, H, I 10 A, B, C, D, E, F, G, H, I, L そのうち，クローンを編集した各開発者に対し， Aから順にアルファベットをつけたところ， そのような開発者は12名でした． SES2008 2008/9/2

検定結果 1/2 複雑度の増加量が大きい開発者 : A, B 複雑度の増加量が小さい開発者 : C, D, E 開発者 A B C D E 期間 4 5 1 2 3 メトリクス LEN 大 小 TKS LOOP COND McCabe 開発者の 編集傾向 ＋ － ＝ 複雑度の増加量が大きい開発者 : A, B 複雑度の増加量が小さい開発者 : C, D, E SES2008 2008/9/2

検定結果 2/2 期間によって傾向が変化する開発者 : F, G, H, I 明確な傾向が見つからなかった開発者 : J, K, L 開発者 1 2 3 4 5 メトリクス LEN 大 小 TKS LOOP COND McCabe 開発者の 編集傾向 ＋ ＝ － 期間によって傾向が変化する開発者 : F, G, H, I 明確な傾向が見つからなかった開発者 : J, K, L SES2008 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 2008/9/2

編集傾向を用いたクローンの管理 2/3 やや複雑なクローン付近を編集した開発者を発見 A B C D E 期間 4 5 1 2 3 開発者の編集傾向 ＋ － ＝ やや複雑なクローン付近を編集した開発者を発見 開発者A, Bが編集したクローンは，その後複雑になる可能性が高い → すぐにクローンを除去した方が良い 開発者C, D, Eが編集したクローンは，その後複雑になる可能性が低い → クローンの除去を急がなくて良い SES2008 2008/9/2

編集傾向を用いたクローンの管理 3/3 開発者F,G,H,Iは期間で傾向が変化している J K L 期間 1 2 3 4 5 開発者の編集傾向 ＋ ＝ － 開発者F,G,H,Iは期間で傾向が変化している 開発者A,B,C,D,Eの傾向が変化することもある 開発者J,K,Lに明確な傾向が見つかることもある →　調査を続け，傾向が変化すれば開発者への対処を変更する ただし，期間によって開発者の傾向が変化することもあるので， 調査を続けて傾向を確認する必要があります． また，差があるとはいえない開発者は調査を続け， 差が見られればクローン管理に利用することが考えられます． SES2008 2008/9/2

まとめと今後の課題 クローンの複雑度で各開発者の特徴を分析 今後の課題 開発者ごとに異なる特徴がある 各開発者の特徴によるクローンの管理例を提案 今後の課題 他のメトリクスによる開発者の特徴分析 開発者以外の要因(モジュール等)の影響の除外 クローンのメトリクス値の変化予測 本研究では，クローンのメトリクス値と 開発者の相関を調査しました． その結果，メトリクス値の変化は開発者毎に差があり， その開発者の中には 一定の傾向でメトリクス値を変化させ続ける開発者がいました． 今後の課題としては， 他のメトリクス値と開発者の相関の調査や， モジュール等の開発者以外の要因の影響の除外， クローンのメトリクス値の変化予測 が挙げられます． 以上で発表を終わります． SES2008 2008/9/2

SES2008 2008/9/2

4 : 複雑度メトリクスの値の変化の取得 クローンの様々なメトリクス値を計算する クローン対応関係にある2つのクローン間のメトリクス値の差を計算する クローンが存在するスナップショットを編集した開発者ごとに，メトリクス値の変化を集める 開発者によって編集されたクローン 複雑度メトリクスの値が変化したクローン 次に，メトリクス値の変化を取得します． この取得方法を，図を用いて説明します． 図では3つのスナップショットがあり， それぞれのスナップショット中のクローンを検出しています． これらのクローンに対し， まずは，様々なメトリクス値を計算します． 図では，アルファとベータというメトリクスを計算しています． 次に，クローン対応関係にある2つのクローン間の メトリクス値の差を計算します． 例えば，図の左上のクローン対応関係にある2つのクローン間では， アルファ，ベータの差はそれぞれ２，０となっています． 最後に， クローンが存在するスナップショットを編集した開発者毎に， メトリクス値の変化を集めます． 図のメトリクス値の変化を集めると，このような表になります． 表では，横軸に開発者，縦軸にメトリクスが並んでいます． そして表の要素には， 開発者によるメトリクス値の変化のリストが 記録されています． 図では，左上のメトリクス値の変化は， 開発者Bが編集した際に起こっているので， 表では開発者Bの列に記録されています． 開発者B 開発者C メトリクスα {+2} {0, 0} メトリクスβ {3} {+1, -4} α : +2　β : 0 編集なし α : 0 β : +1 編集あり α : 0 β : -3 編集なし α : 0 β : -4 編集あり 開発者Aが 編集 開発者Bが 編集 開発者Cが 編集 SES2008 2008/9/2

CKメトリクスの例 WMC (weighted methods per class)：あるクラスのメソッドの重さ(複雑さの総和) NOC (number of children)：あるクラスのサブクラスの数 値が大きいほど、サブクラスへの影響力が強い SES2008 2008/9/2

保守性を悪化させないクローンの例1/2 クローンを作成しない方法 クローンを作成する方法 プラットフォームA クローン作成 コード片変更 クローン変更 プラットフォームB クローン作成 コード片変更 プラットフォームC クローン変更 コード片が複雑に SES2008 2008/9/2

保守性を悪化させないクローンの例2/2 クローンを作成せず，様々なプラットフォームに対応できるコード片を書く方法 ソースコードが複雑になっていく 前のコード片のクローンを作成し，そのクローンを新しいプラットフォームに対応するように変更する方法 現在のプラットフォームの安定性が維持される 各プラットフォームの保守を独立して行える SES2008 2008/9/2