メトリクス値の変化に基づく コードクローンの編集傾向分析 井上研究室　 東　誠 　井上研究室の東です． 　メトリクス「ち」の変化に基づく コードクローンの編集「けーこー」分析について 発表させていただきます． 2008/2/22 特別研究発表会

コードクローン ソースコード中に存在する同一，もしくは類似したコード片を同一システム中に持つコード片 クローンの検出と除去が研究されてきた 以降単にクローンと呼ぶ クローンの検出と除去が研究されてきた ソースファイルF1 ソースファイルF2 まず，コードクローンについて説明します． コードクローンとは，ソースコード中に存在する 同一または類似した コード片です． 下の図では、クローンが、 左のファイルに2個、 右のファイルに1個存在しています． また，クローンを2つ選んで作られる組を クローンペアといいます． このようなクローンに対し、 従来は検出や除去が研究されてきました． クローンペア コードクローン コードクローン クローンペア クローンペア 特別研究発表会 2008/2/22

クローンが保守性に与える影響 クローンはソフトウェア保守を困難にする場合がある クローンが保守性を悪化させるとは限らない[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. 特別研究発表会 2008/2/22

クローン管理の必要性 全てのクローンを取り除くのではなく，必要なクローンだけ除去する 保守性を悪化させるクローンは除去する 開発者が意図的に作成したクローンは除去しない …例2はデザインパターンとか言いたいんだが， コピペとも取れるよなあ． 後、→という因果関係をどう示しか． そのため、全てのクローンを取り除くのではなく、 必要なクローンだけを除去する必要があります． 「このことから」、 クローンを適切に管理する必要があると考えられるようになりました． 管理って何？　という質問はかなりの高確率で出てくる． 「(基準によって)クローンを複数のグループに区別して， 各クローンのグループに対して適切な処理を行うこと」 特別研究発表会 2008/2/22

本研究の着目点 クローンを編集した開発者 開発者によってクローンの編集内容に特徴が表れるのではないか 異なる役割や目的を持つ 経験に差がある 開発者によってクローンの編集内容に特徴が表れるのではないか 例 : 経験の浅い開発者によって編集されたクローンは保守性を悪化させる 特徴によってクローンを区別し，管理することができるのではないか 本件旧では，クローンを管理する基準として， クローンを編集した開発者が考えられる． 例が突っ込まれるかもしれんが、思いつかなかったと答えるしかない。 …後，例のニュアンスを履き違えているかも．編集傾向との違いは？　 「～な開発者は」～なクローンを編集するってことなんだが． 特別研究発表会 2008/2/22

本研究の目的 各開発者のクローンに対する編集傾向を調査 編集傾向を知るためにメトリクス値の変化を調べる 編集傾向 ： クローンを編集する時に表れる特徴 例 : 開発者Ａはクローンを長くすることが多い 編集傾向を知るためにメトリクス値の変化を調べる そこで本研究では，各開発者のクローンに対する(この表現おかしい？) 編集傾向を調査しました 「編集傾向とは開発者が～特徴であり， 例としては、ある開発者がクローンを長くすることが多いことなどがあげられます」 そして、編集傾向を知る 「クローンの性質を表す」メトリクス「ち」 調べました． 特別研究発表会 2008/2/22

調査方法の概略 1 ソースコードの スナップショット の取得 2 クローン検出 3 クローン対応関係 (同じ位置にあるクローンの関係) 版管理システム (ソフトウェアの 編集履歴を 格納するシステム) 2 クローン検出 3 クローン対応関係 (同じ位置にあるクローンの関係) の抽出 次に、 まず，ソフトウェアの～格納している版管理システムから， ソースコード 次煮、各スナップショット内の そして、同じ位置にあるクローンの関係である さらに、クローン対応関係を用いて 最後に、 4 メトリクス値の 変化の取得 5 開発者間の差の検定 メトリクスα メトリクスβ A {+2, 0, …} {0, 0, …} B {0, -3, …} {+1, 0, …} α A ＋ B － 開発者 特別研究発表会 2008/2/22

1 スナップショットの取得 版管理システムを用いる 各開発者がソースコードを編集した直後のスナップショットを取得 ソフトウェアの編集履歴を格納するシステム 本研究において用いる情報 編集されたファイルの変更差分 編集した開発者 編集した日時 各開発者がソースコードを編集した直後のスナップショットを取得 特別研究発表会 2008/2/22

2 クローンの検出 各スナップショット中のクローンを検出 特別研究発表会 2008/2/22

3 クローン対応関係の抽出 メトリクス値の変化を取得するために，連続するスナップショット間のクローン対応関係を抽出する クローン対応関係 : 2つのスナップショット中の同じファイルの同じ位置にあるクローン間の関係[2] クローン対応関係 クローン対応関係 [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. 特別研究発表会 2008/2/22

4 メトリクス値の変化の取得 クローンの様々なメトリクス値を計算する クローン対応関係にある2つのクローン間のメトリクス値の差を計算する クローンが存在するスナップショットを編集した開発者毎に，メトリクス値の変化を集める 開発者A 開発者B メトリクスα {+2, 0, +1, …} {0, 0, +4…} メトリクスβ {0, -3, -5…} {+1, 0, +2…} 特別研究発表会 2008/2/22

5 開発者間の差の検定 メトリクス値の変化の分布と検定結果から，各開発者によるメトリクス値の変化を以下の3種類に分類する 他の開発者に比べてメトリクス値を大きくする傾向がある 他の開発者に比べてメトリクス値を小さくする傾向がある 他の開発者と差があるとはいえない タイトルと内容が微妙に… 「各開発者が他の開発者と比べて」 が、相対的な話に進んでしまうと帰って怪しいような． 開発者が有意にメトリクス「ち」を変化させているかどうかを、 (他の開発者との比較によって)検定する． 特別研究発表会 2008/2/22

調査内容 1/2 実際のソフトウェア開発履歴に対して調査 調査対象 PostgreSQLの編集履歴 1997/07/01～1998/12/31を半年間ずつの3つの期間に分け，それぞれの期間に行われた各編集直後のソースコードのスナップショットを取得 期間1 : 1997/07/01～1997/12/31 期間2 : 1998/01/01～1998/06/30 期間3 : 1998/07/01～1998/12/31 特別研究発表会 2008/2/22

調査内容 2/2 クローン検出：CCFinderX 使用したメトリクス 複雑度メトリクス : 値が大きいほど複雑なクローンであることを表す LEN : クローンの長さ(トークンの数) TKS : クローン中のトークンの種類数 COND : クローン中の条件分岐の数 LOOP : クローン中のループ文の数 McCabe : LOOP+COND 特別研究発表会 2008/2/22

検定結果 開発者 A B C D E F G H 期間 1 2 3 LEN + － TKS LOOP COND McCabe 次に，検定結果(…調査結果、ではなく？　後で質問) について質問します． 3つの調査期間は時期の早いものから順に1,2,3と番号を振っています． そして各開発者が開発に参加した期間のみ，メトリクス値の変化の差を検定しています． 例えば開発者Hは期間が3の列しかありませんが， それはHが最後の調査期間にしか開発に参加していなかったからです． また，表の要素は， メトリクス「ち」を増加させている場合はプラス、 現象させている場合はマイナス、 メトリクスの変化に差があるとはいえない場合は空欄としています． この検定結果から， メトリクス「ち」を増加させる開発者、 減少させる開発者、 増減が混在する開発者がいることがわかりました． (いまさらだが、言いたいことに合わせて 図を見やすくすべきではなかったか？) クローンを複雑にする開発者 : F クローンを簡単にする開発者 : B, C 期間によって傾向が異なる開発者 : A, D 特別研究発表会 2008/2/22

開発者によるクローン管理方法 開発者は目的を達成するために，前に編集した箇所やその付近を連続して編集する傾向がある 開発者Fが編集したクローンは，今後複雑になる可能性が高い →　今の複雑度が低くても，除去した方が良い 開発者Bや開発者Cが編集したクローンは，今後簡単になる可能性が高い →　今の複雑度が高くても，除去を急ぐ必要はない 間違いなく突っ込まれるのは 「混在した開発者はどうした」 定期的に調査を行い， その開発者のメトリクス「ち」の変化の傾向が特定できれば クローン管理の基準として用います． 特別研究発表会 2008/2/22

まとめと今後の課題 メトリクス値の変化を用いてクローンの編集傾向を調査 今後の課題 メトリクス値の変化は開発者ごとに差があった 各開発者に編集傾向があることが分かった 今後の課題 他のメトリクス値を用いた編集傾向の調査 開発者以外の要因(モジュール等)の影響の除外 　本研究では，メトリクス値の変化によって クローンの 寧ろ管理手法が考えられたことを強調すべき？　 が、編集傾向の分析が目的だからなあ． 特別研究発表会 2008/2/22