リファクタリング支援のための コードクローンに含まれる識別子の変更内容分析 井上研究室 工藤 良介 1

発表概要 2  保守コストを抑えるためコードクローンを集約する ことが提案されている  全てのコードクローンが集約できるわけではない  集約しやすいクローン, 困難なクローンの割合を調査 する

コードクローンとは 3  ソースコード中の同一, または類似したコード片  クローンのひとつにバグが見つかった場合, その他のクローンについ ても修正を検討する必要がある  コードクローンの存在が保守コストを増大させる要因となっている クローンとなっている コード片

コードクローンに対するリファクタリング 4  共通した処理を，単一のコードに集約する  全てのクローンが集約できるとは限らない hoge(); 手続きとして独立させ る 手続き呼出し に変更 集約 hoge(){ }

研究目的・内容 5  コードクローンのリファクタリングがどの程度適用で きるのかを確認する  集約が容易なクローン，集約が困難なクローンの割合 を調べる  調査対象  Java で書かれたオープンソースソフトウェア 2142 個  apache.commons ， sourceforge.net から収集したもの

本研究で対象とするコードクローン 6  CCFinder が検出する “Parameterized” クローン … int y = getY(); System.out.println( “Freefall:”); int t =freefall(y) … int height = getY(); System.out.println( “Freefall:”); int time =freefall(height) … int y = getHeight(); System.out.println( “Freefall:”); int t =freefall(y) … 変数名が違う 手続き名が違 う

集約の容易なクローン, 困難なクローン 7  集約の容易なクローン  識別子名に変更のないクローン  変数名のみが変更されているクローン  手続きに引数を設定することで違いを吸収  集約の困難なクローン  型名が変更されているクローン  メソッド名が変更されているクローン  識別子の対応が 1 対 1 でないクローン

調査手法 8 1. ソースコード中のクローンを検出する 2. ソースコードに出現する識別子のリストを作成  出力する情報は { 識別子名, 出現位置, 種類 } 3. クローン中の識別子をリストから抽出し, 対応関係 を調査する  変更された識別子の種類  変更された識別子の対応関係 4. クローンを分類する

調査手法 9 1. ソースコード中のクローンを検出する 2. ソースコードに出現する識別子のリストを作成  出力する情報は { 識別子名, 出現位置, 種類 } 3. クローン中の識別子をリストから抽出し, 対応関係 を調査する  変更された識別子の種類  変更された識別子の対応関係 4. クローンを分類する

1 ．コードクローンの検出 10  コードクローン検出ツール CCFinder を利用 … int y = getY(); System.out.println( “Freefall:”); int t =freefall(y) … int height = getY(); System.out.println( “Freefall:”); int time =freefall(height) … int y = getHeight(); System.out.println( “Freefall:”); int t =freefall(y) … 変数名が違う 手続き名が違 う

調査手法 ソースコード中のクローンを検出する 2. ソースコードに出現する識別子のリストを作成  出力する情報は { 識別子名, 出現位置, 種類 } 3. クローン中の識別子をリストから抽出し, 対応関係 を調査する  変更された識別子の種類  変更された識別子の対応関係 4. クローンを分類する

2 ．識別子のリスト作成 12  出力する情報は { 識別子名, 出現位置, 種類 }  識別子の種類は { 変数, メソッド, 型, レシーバ, リテラル, そ の他 } とした

調査手法 ソースコード中のクローンを検出する 2. ソースコードに出現する識別子のリストを作成  出力する情報は { 識別子名, 出現位置, 種類 } 3. クローン中の識別子をリストから抽出し, 対応関係 を調査する  変更された識別子の種類  変更された識別子の対応関係 4. クローンを分類する

3 ．識別子名の対応関係の調査 14  識別子名の対応関係を以下のように定義する  変更なし  識別子名は変わっていない  変更あり  1 対 1 対応  クローン間で識別子名をお互いに 1 対 1 で置換できる  N 対 N 対応  1 対 1 対応ではない識別子名の対応がある

例）識別子の対応関係 15 A=1; B=B+A; D=1; E=E+D; H=1; Y=Z+H; コード片 1 コード片 2 コード片 3 コード片 1 コード片 2 コード片 3 種類 1 対 1 対応変更なし ADH 変数 ○ × 111 リテラル ○ BEYZYZ 変数 ××

調査手法 ソースコード中のクローンを検出する 2. ソースコードに出現する識別子のリストを作成  出力する情報は { 識別子名, 出現位置, 種類 } 3. クローン中の識別子をリストから抽出し, 対応関係 を調査する  変更された識別子の種類  変更された識別子の対応関係 4. クローンを分類する

4 ．クローンの分類 17 変数名 A ⇔ D ⇔ H ・・・・・・・・ 1 対 1 対応 変数名 B ⇔ E ⇔｛ Y,Z} ・・・・・・・・ N 対 N 対応 1 対 1 でない変更があると 集約が難しい コード片 1 コード片 2 コード片 3 種類 1 対 1 対応変更なし ADH 変数 ○ × 111 リテラル ○ BEYZYZ 変数 ×× このクローンは「変数のみが変更されていて」「 1 対 1 でない変更を含む」と分 類

調査する点 18  集約の容易なクローン  識別子名に変更のないクローン  変数名のみが変わっていてその変更が全て 1 対 1 対応であ るクローン  集約の困難なクローン  型名が変わっているクローン  メソッド名が変わっているクローン  識別子の対応が 1 対 1 でないクローン

調査結果 19  調査対象  Java で書かれたオープンソースソフトウェア 2142 個  apache.commons ， sourceforge.net から収集したもの  総クローン数  調査結果  集約の容易なクローン 26.0%  集約の困難なクローン 52.4%

調査結果 20 分類クローン 数 総クローン 数に対する 割合 全ての識別子が 1 対 1 対応 変更なし %100% 変数のみ変更 %91.2% 集約の期待できるクローン・・・ 26.0% 集約の難しいクローン ・・・ 52.4% 分類クローン 数 総クローン 数に対する 割合 全ての識別子が 1 対 1 対応 型が変更 %78.3% メソッドが変更 %74.0% 型またはメソッドが変 更 %75.5% 総クローン数

考察 21  集約が容易なクローンが全体の 4 分の 1 であった  これらのクローンを集約することで保守コストを下げる ことができる  また, 集約が困難なクローンも, その 4 分の 3 は識別子が 1 対 1 対応のクローンであった  違いを吸収する手法を確立できれば, 多くのクローンをリ ファクタリングすることができる

まとめ 22  コードクローンのリファクタリングがどの程度適用 できるのかを確認するために, 集約が容易なクローン， 集約が困難なクローンの割合を調べた  クローンになっているコード片の間で識別子を比較 し，識別子名の変更状況を調査した  実験の結果, 約 4 分の 1 のクローンで集約が容易なこと がわかった

識別子の分類 23  今回識別子を以下のように分類した。  変数  メソッド  型  レシーバ  リテラル  その他

調査結果 24 分類クローン数全体に対する割合 全体 変更なし % 変数のみ変更 % 型が変更 % メソッドが変更 % 型またはメソッドが変 更 % 分類全ての識別子が 1 対 1 対応 N 対 N 対応を含む 変数のみ変更 91.2%8.8% 集約の期待できるクローン・・・ 26.0% 集約の難しいクローン ・・・ 52.4%

実験結果 25  識別子名の変更なしのクローンが全体の 22.4% 、変数 名のみ変更されているクローンが 全体の 4% でその うち 86% が 1 対 1 対応の変更であった  集約の期待されるクローン  型またはメソッド名の変更されたクローンは全体の 52.3% であった  集約の難しいクローン

考察 26  全クローンのうち約 4 分の 1 で集約が期待できること がわかった。  提案されているコードクローンのリファクタリング 手法は十分有用であると言える。  しかし、集約可能でも実際には行うべきでないケー スも存在することに留意しなければならない。

例）識別子の対応関係 27 a=1; b=b+1; … a=c; a=1; b=b+1; … a=c; a=1; b=b+1; … a=c; 変更なし 1 対 1 対応 a=1; b=b+1; … a=c; d=1; e=e+1; … d=f; g=1; h=h+1; … g=i; a ⇔ d ⇔ g b ⇔ e ⇔ ｈ と 対応 c ⇔ f ⇔ i N 対 N 対応 a=1; b=b+1; … a=c; d=1; f=g+1; … i=c; k=1; f=g+1; … a=l; a ⇔ d,i ⇔ k,a ….. とバラバラ

調査結果 28 分類クローン数全体に対する割合 全体 変更なし % 変数のみ変更 % リテラルのみ変更 % 型が変更 % メソッドが変更 % 型またはメソッドが変 更 % 分類全ての識別子が 1 対 1 対応 N 対 N 対応を含む 変数のみ変更 85.5%14.5%

おわり 29

30

コードクローンとは (2) 31  コードクローンは 3 つのタイプに分けられる。  タイプ 1 ：空白、改行などを除き同一のもの  タイプ 2 ：変数名や型名など識別子名が変わったもの  タイプ 3 ：一部に文の挿入や削除が行われたもの  本研究ではタイプ 1 およびタイプ 2 のコードクローン を扱う。

コードクローンのリファクタリング (1) 32  コードクローンの存在は保守コストを増大させるの で好ましくない。  コードクローンを除去するためのリファクタリング 手法が提案されている。  リファクタリング：外部からみた動作を変えずに、内部構造を整理する こと

背景 ( 非表示 ) 33  Yii Yong Lee の研究で、クローンペア間での識別子名の 変更によるバグの生成についての調査が行われた。  今回は一般化し、バグ検出という視点ではなく、どの ように識別子名の変更が行われているかを調査したい。

調査対象 34  Java で書かれたソースファイルを対象とする  研究対象として、以下のドメインから集めたオープ ンソースソフトウェアのデータセットを利用する  apache.commons  sourceforge.net  sourceforge.net.DB  ツールの実行対象はプロジェクト単位  全 2142 プロジェクト

実験準備 35  実験を行うためにクローン間の識別子の変更内容を 割り出すツールを作成  今回は Java ファイルのみを対象とする

実験用ツール概略図 36 Java ファイル CCFinder リスト作成 コードクローン情報識別子リスト 比較 識別子情報

実験用ツール 37  クローン検出には既存のツール CCFinder を使用  タイプ 1 および 2 のクローンを検出  クローンとして検出するのは 30 トークン以上のコード片  Java ファイルから識別子を抜き出しリストを作成する プログラムを用意  CCFinder の出力結果と識別子リストの比較により識 別子の変更情報を得る

38