コードの生存期間を考慮したコードクローンと欠陥修正の関係調査 大阪大学 大学院情報科学研究科 ○齋藤 晃，吉田 則裕， 　 松下 誠，井上 克郎 理ファクタリングはKiｍがやってる クローンとバグの関係はまだ探していない だ

概要 コードクローンと欠陥修正の関係には様々な報告が存在 既存研究においてコードクローンと欠陥修正の関連は小さいと報告 しかし既存研究ではコードクローンの生存期間を考慮していない コードクローンの生存期間を考慮してクローンと欠陥修正の関係を再調査 調査の結果，生存期間の短いクローンのほうが 欠陥修正に含まれる割合が多い 概要にもっていく

背景：コードクローンとは ソースコード中に存在する一致または類似 したコード片 コードクローンに修正漏れがあると欠陥の 要因となる ソースコード中に存在する一致または類似 したコード片 コピーアンドペーストなどの理由により生成 コードクローンに修正漏れがあると欠陥の 要因となる リファクタリング等を用いて除去する必要がある 修正を検討する必要がある，ぐらいに言っておく バグの原因になりやすい理由を言う クローンペア：２つの要素からなるクローンの対 クローンセット：推移関係が成り立つクローンの集合 欠陥 C4 C1 C2 C5 C3

背景：欠陥管理システム 欠陥に関する内容・発見日時・修正履歴などの情報を一元管理 多くの欠陥管理システムはWebサーバ上で 動作 オープンソースソフトウェアの有名な欠陥管理システムとしてBugZillaが代表的 このスライドいらない？

背景：コードクローンと欠陥の関係 コードクローンと欠陥との関係には様々な 報告がある コードクローンと欠陥との関係には様々な 報告がある 重複したコードは不吉な匂い(Bad Smell) [Fowler1999] コードクローンは保守性を低下させるので積極的に除去すべき[Jiang2007] コードクローンと欠陥修正の関連は小さい[Rahman2010] ちょうふく [Fowler1999]M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts,“Refactoring: Improving the Design of Existing Code”, 1st ed.Addison-Wesley Professional, July 1999. [Jiang2007] L. Jiang, Z. Su, and E. Chiu, “Context-based detection of clone-related bugs” ESEC-FSE 2007 [Rahman2010] F. Rahman, C. Bird, P. Devanbu, "Clones:What is that Smell?“, MSR2010

既存研究 コードクローンと欠陥修正の関連を調査[Rahman2010] 手順１．過去のソースコードのスナップショットを取得 手順２．コードクローン検出 手順３．欠陥修正と対応するコミットの取得 手順４．欠陥修正に含まれるコードクローンの割合を算出 [Rahman2010] F. Rahman, C. Bird, P. Devanbu, “Clones:What is that Smell?“, MSR2010

１．過去のソースコードのスナップショットを取得 1ケ月おきにリポジトリからスナップショットを取得 ソフトウェア リポジトリ(SVN, Git等) チェックアウト ・・・ 2008/03/01 2008/04/03 2009/02/02 その月の中で最も早い日にコミットされたファイル群を取得

２．コードクローン検出 コードクローン検出ツールDECKARDを使用[Jiang2007] コードクローンは位置を特定する情報を保有 s1 抽象構文木(AST)を構築し，それらの等価性を比較することによりクローンを検出 コードクローンは位置を特定する情報を保有 クローンが含まれるスナップショット(sn), ファイル名(fn) クローンの開始行(lbegin), 終了行(lend) s1 s2 s3 f1…fn f1…fn f1…fn クローン lbegin lend ・・・・・ 2008/03/01 2008/04/03 2009/02/02 [Jiang2007] L.Jiang, Z.Su, G.Misherghi, S.Glondu,  “DECKARD:scalable and accurate tree-based detection of code clones“, ICSE2007 各コードクローンは含まれるスナップショット，ファイル名，開始行，終了行の情報を持つ

３．欠陥修正と対応するコミットの取得 欠陥を含むコードの位置を特定することは困難 修正済みのバグレポートを取得し，欠陥が修正されたコード全てを欠陥コード(Buggy Code)とする Buggy Codeを取得するために，リポジトリから欠陥が修正されたコミットとバグレポートを対応付けを実行 リポジトリのコミットログ 欠陥管理システム ------------------------------------------------------------------------ r201 　| authorName | 2009-01-01 add feature: ・・・・ r202　 | authorName | 2009-02-01 bug fixed: #10002 欠陥管理システムには修正済みの欠陥情報の一覧が取得できます これらの欠陥情報には，それぞれ一意の欠陥IDを持っています． またリポジトリのコミットログには欠陥が修正された場合，修正者が修正を行った欠陥IDを記述している場合が 多くあります． また修正に関する”fixed”などの文言もあり，それらの情報を基にコミットログを解析して欠陥情報と対応付けを行います． 欠陥ID 状態 詳細 10001 RESOLVED ・・・ 10002 リビジョン番号 欠陥IDがコミットログに記述 コミットログを解析して対応付け

４．欠陥修正に含まれるクローンの割合を算出 欠陥修正が行われたリビジョンと最も近い　スナップショットを取得 スナップショットと間に変更が生じている可能性があるので，diffコマンドによって調整 Buggy Code内に含まれるコードクローンの重複率dを算出 多くのコードクローンは欠陥修正に含まれていないという結果を報告

既存手法の問題点 (1/2) 生存期間に着目することでより欠陥に起因するコードクローンを特定できる のではないか？ 既存手法の問題点 (1/2) 既存研究の調査はクローンの生存期間を考慮していない 既に修正が頻繁に生じているコード片は今後も変更が生じやすい たとえコードクローンであってもよく知られたプログラミングロジックであれば欠陥修正との関連は小さくなりやすい C1 C’1 C’’1 修正 されやすい 修正 修正 C2 C’2 C’’2 C3 C3 C3 重要なとこを強調 修正 されにくい C4 C4 C4 生存期間に着目することでより欠陥に起因するコードクローンを特定できる　　　のではないか？

既存手法の問題点 (2/2) 欠陥修正を行ったリビジョンとスナップショットとの期間が増えると誤差が大きくなる 既存手法の問題点 (2/2) 欠陥修正を行ったリビジョンとスナップショットとの期間が増えると誤差が大きくなる 欠陥修正時ではコードクローンであってもスナップショットではクローンでない可能性がある クローンでない 修正 取得したスナップショット 重要なとこを強調 コードを修正 欠陥修正を行ったリビジョン

研究内容 既存手法の手順に以下の手順を追加 Buggy Codeに含まれているコードクローンに包含されるコード片の生存期間を取得 RQ: 生存期間の長いクローンは欠陥が少なく、生存期間が短いクローンは欠陥を多く含む スナップショットを欠陥修正と対応付けした リビジョン全てにコードクローン検出を実行 取得したスナップショットとの誤差を小さくする 重要なとこを強調

クローンの生存期間の取得方法 手順１－４．Buggy Code内に含まれるクローンの抽出と重複率の算出 以下の手順A, Bを追加 既存手法と同様 以下の手順A, Bを追加 A．コード片の変更の有無を過去のリビジョンと比較 B．コード片の生存期間を算出 重要なとこを強調

コード片の変更の判定・生存期間の算出 1ケ月おきに過去のリビジョンから該当するコード片に変更があるかどうかを判定 差異はdiffが存在するかどうか 変更が生じたリビジョンとBuggy Codeが検出されたリビジョンとの日付の差が生存期間 BuggyCode C1 重要なとこを強調 C2 C2 C2 過去にコード片が存在しない 過去にコード片が存在 C3 C4 約1ケ月 r2 r1 r0 rs 2009-03-02 2009-04-04 2009-05-01 2009-06-01

変更の有無の判定 変更の有無はdiffコマンドを使用 過去にリビジョンに対して，下記の１～４の場所に差分が存在すれば変更が生じたと判定 変更が生じた周りの行は取得しないよう設定 過去にリビジョンに対して，下記の１～４の場所に差分が存在すれば変更が生じたと判定 diffの開始行 4. 1. コード片の開始行 3. コード片 コード片の終了行 2. diffの終了行 欠陥修正が行われた リビジョン 過去のリビジョン

適用実験 下記のオープンソースソフトウェアを調査 リポジトリはGitを使用 BugZillaから修正完了したバグレポートを取得 gimp・・・画像処理ソフトウェア evolution・・・Gnome環境に付属するメールクライアント これらは既存研究でも調査対象 リポジトリはGitを使用 BugZillaから修正完了したバグレポートを取得 Statusが“RESOLVED”, “VERIFIED”, “CLOSED”のいずれかに設定 Resolutionが“FIXED”に設定

実験結果：生存期間の抽出 抽出したコードクローンの数と生存期間 生存期間中央値よりも長いコードクローン プロジェクト名 Gimp Evolution コードクローンの数 1093 1114 生存期間最大(日) 3460 3812 生存期間最小(日) 32 41 生存期間中央値(日) 574 1791 全体でクローンはいくつあった？？ 生存期間中央値よりも長いコードクローン (Clong)と短いコードクローン(Cshort)に分割

実験結果：欠陥修正に含まれるクローンの分布 ClongとCshortに対して欠陥修正にクローンが含まれる　割合を算出 （a）Gimp （ｂ）Evolution 累積 カバレッジ Clong Cshort 重複率4割以下はClongでは8割をしめるのにCshortは6割程度しかない これはCshortのほうがそれ以上に重複率が高いものを多く含むことを表している よって生存期間が短いクローンの方が欠陥修正に多く含まれる 欠陥修正に含まれるクローンの重複率 累積カバレッジ(縦軸)は欠陥修正に含まれるクローンがｘ％以下のものが全体の何割を占めるかを表す 生存期間が短いクローンの方が欠陥修正に多く含まれる

実験結果：欠陥修正に含まれるクローンの分布 ClongとCshortに対して欠陥修正にクローンが含まれる　割合を算出 （a）Gimp （ｂ）Evolution Clong Cshort 全体に対する割合 重複率4割以下はClongでは8割をしめるのにCshortは6割程度しかない これはCshortのほうがそれ以上に重複率が高いものを多く含むことを表している よって生存期間が短いクローンの方が欠陥修正に多く含まれる 欠陥修正に含まれるクローンの重複率 生存期間が短いクローンの方が欠陥修正に多く含まれる

考察 (1/2) 生存期間の短いコードクローンはより欠陥に 含まれる コードクローンのリファクタリングによる除去 本調査から得られた知見 考察 (1/2) 本調査から得られた知見 生存期間の短いコードクローンはより欠陥に　含まれる 有効な場面 コードクローンのリファクタリングによる除去 全てのコードクローンのリファクタリングは現実的でなく，優先的に対象を選ぶ必要がある

考察 (2/2) 提案手法で取得した生存期間の定義の検討が必要 過去のバージョンにおいてクローン検出を行い対応付ける必要がある 考察 (2/2) 提案手法で取得した生存期間の定義の検討が必要 提案手法で取得した生存期間 コード片そのものが存在する期間 コード片が存在 しない クローン コード片が存在 過去のバージョンにおいてクローン検出を行い対応付ける必要がある

まとめ 生存期間を考慮して欠陥修正に含まれるコードクローンの割合を調査 生存期間が短いコードクローンのほうが欠陥修正に含まれる割合が大きい 今後は生存期間の取得方法を再検討