複数のプロジェクトを対象としたクローンの系譜にもとづく ソースコード再利用分析手法の提案 大阪大学大学院情報科学研究科 コンピュータサイエンス専攻 ○ 森脇匠哉，堀田圭佑，井垣宏， 楠本真二，井上克郎

ソースコードの再利用[1] 既存のソースコードのコピーアンドペーストにより行われる メリット デメリット[2] コピー 同じソースコードを二度書かなくて済む ⇒ 生産性の向上 テスト済みのソースコードの再利用 ⇒ 信頼性の向上 デメリット[2] 不用意な再利用はライセンス違反やバグの伝搬に繋がる コピーアンドペースト後にコード修正が必要な場合もある 「ソースコードの再利用は既存のソースコードのコピーアンドペーストにより行われます」 「ソースコードのコピーアンドペーストはファイル内のみではなくファイル間でも行われなます」 アニメ 「テスト済みのコードの再利用によって信頼性が向上し，」 「同じコードを二度書かなくて済むことは生産性の向上につながります」 しかし，コードの再利用はそのコード内容の理解が必要であり，また，コピーアンドペースト後にコード修正が必要な場合もあるため一般に難しいと言われています． そのため，開発者には再利用しやすいソースコードを記述することが求められます． 開発者の再利用動向の分析について， 再利用しやすいソースコードや，開発者がどのようなときに再利用を行うか といった再利用動向の分析が重要である [1] Trivedi Prakriti and Kumar Rajeev. Software metrics to estimate software quality using software component 　reusability. IJCSI International Journal of Computer Science Issues, Vol. 9, pp. 144–149, 2012. [2] Will Tracz. Confessions of a used-program salesman: Lessons learned. In Proceedings of the 1995 Symposium on Software Reusability, SSR ’95, pp. 11–13, New York, NY, USA, 1995. ACM.

組織でのソフトウェア開発における再利用分析 再利用分析によりライセンス違反の特定，よく再利用されるソースコードについてのライブラリ化の提案，ソースコードの推薦などが可能となる[3] 再利用分析における課題 プロジェクト間での再利用の特定 開発者単位での再利用分析 組織 プロジェクトA プロジェクトB コピー 開発者B 開発者A 実装 コピー ほとんど行われていない →だから困る 「既存はプロジェクト内での分析」左の絵だけ．ちょい修正 「通常特定の組織は複数のプロジェクトを持ち，再利用はプロジェクトをまたがってくる」[参考文献] 「再利用動向の分析には複数プロジェクト間でやる必要有り」 --------------- またがった再利用の絵に修正 「そこで，」 「組織内での再利用を促進するためには，誰が再利用可能なコードを最初に作成したのか，また，誰が再利用を行ったのかという情報を明らかにすることが必要である」・・・ニュアン変える また後で細かく修正 開発者のモチベーションが異なる→(口頭)アンケートによると　再利用に関する 再利用傾向の分析は複数プロジェクト間で行う必要がある 開発者C (利用) (実装) 開発者B 開発者A (利用) [3] Naoki Fukuyasu, Sachio Saiki, Hiroshi Igaki, and Yuki Manabe, "Experimental Report of the Exercise Environment for Software Development PBL," In 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, pages 482-487, August 2012.

目的とアプローチ 目的 組織でのソフトウェア開発における 開発者ごとの再利用動向を分析すること アプローチ 複数プロジェクトをまたがるクローンの系譜を導出し，その系譜から再利用動向の情報を取得 口頭で「このように，アンケートによって定性的な調査が行われています，そして，この著者は定量的な・・・」 定性的：対象の状態を不連続な性質の変化に着目してとらえること。 定量的；対象の状態を連続する数値の変化に着目してとらえること。 http://news.mynavi.jp/column/system/002/index.html ・・・ついて，定性的な分析を行った研究があります． この研究では，686名のOSS開発者に対して，再利用に関するアンケートを実施しました． 結果として，再利用を積極的に行う開発者には以下の様な特徴があると述べられています． 1つめは，再利用のメリットである生産性・信頼性の向上について強く認識している開発者 2つめは，関わっているプロジェクト数や開発者数が多い開発者 3つめは，成熟していない，つまり，開発が始まってから日の浅いプロジェクトに携わっている開発者です そして，この研究の著者は，このような定性的な調査だけではなく，個人差に着目した再利用に関する定量的な分析も必要であると述べています．

コードクローンとクローンの系譜 A B C コードクローンがいつ生成され，どのような修正がなされたかを示す コードクローン: 同一または類似したコード片を持つもの コードクローンを用いた既存の再利用分析研究 再利用の規模や性質を分析[4] コードクローン利用者 コード クローン コピー A B C コードクローン作成者 コードクローンであるコード片の内，実装日時が最も古いコード片を実装した開発者 コードクローン 利用者 既存のコード片を再利用した開発者 クローンの系譜[5] rev. i rev. i+1 rev. i+2 rev. i+3 コードクローンがいつ生成され，どのような修正がなされたかを示す 誰が再利用可能なコードを最初に作成したのか，また，誰が再利用を行ったのかという情報？ ↓ コードクローン作成者とコードクローン利用者を導出する 再利用傾向の分析を開発者ごとに行う必要がある モチベの詳細 [4]Lars Heinemann, Florian Deissenboeck, Mario Gleirscher, Benjamin Hummel, and Maximilian Irlbeck. On the Extent and Nature of Software Reuse in Open Source Java Projects. In Proceedings of the 12th International Conference on Top Productivity Through Software Reuse, ICSR’11, pp. 207–222, Berlin, Heidelberg, 2011. [5] Miryung Kim, Vibha Sazawal, and David Notkin. An empirical study of code clone genealogies. In 13th ACM SIGSOFT international symposium on Foundations of software engineering, 2005.

再利用分析の概要 STEP1： 合成リポジトリの作成 rev. i+1 rev. i rev. i+2 rev. i+3 STEP2： クローン の系譜の導出 ・・・ ・・・ ・・・ ・・・ リポジトリ 合成リポジトリ rev. i+1 rev. i+2 rev. i+3 「STEP1では，複数プロジェクト間のリビジョン情報を得るために合成リポジトリの作成を行います」 Our reuse analysis method consists of three steps. In Step1, multiple repositories are concatenated into one virtual composite repository. In Step2, Code clone genealogies are derived from the composite repository. In Step3, Individual reuse behaviors are extracted for each genealogy. That is, who reused the existing code, and who originally implemented the code. rev. i rev. i+1 rev. i+2 rev. i+3 STEP3： コードクローン作成者 と利用者の特定

STEP1: 合成リポジトリの作成 t1 t3 リポジトリA t2 t4 リポジトリB time 合成 リポジトリ t1 t2 t3 t4 Rev. A1 a1.java Rev. A2 a1’.java t1 t3 リポジトリA t2 t4 Rev. B1 b1.java Rev. B2 b2.java リポジトリB 全リビジョンを 時系列順にマージ time 合成 リポジトリ Rev. 1 t1 Rev. 2 t2 Rev. 3 t3 Rev. 4 t4 In Step1, commits of multiple repositories are concatenated. Please suppose that there exist these two different repositories A and B. In this example, revision B1,A2 and B2 are merged sequentially to revision A1. Based on the concatenated repository, we can check-out files from multiple repositories. In the following steps, our method uses this composite repository. a1.java a1.java a1’.java a1’.java b1.java b1.java b1.java 複数リポジトリの ファイル情報を持つリポジトリ b2.java

STEP2: クローンの系譜の導出 本研究では，クローンの系譜特定ツールECTEC [6]を利用 再利用の検出 再利用の検出 クローンの系譜 コードクローンがいつ発生し，どのような変更がなされてきたかが分かる 再利用の検出 再利用の検出 クローンの系譜 rev. i rev. i+1 rev. i+2 rev. i+3 In Step2, our method derives every clone genealogy from a composite repository. As you know, the genealogy of code clones describes how clone sets change over multiple versions of a program. Here, we use only three patterns in the genealogy research; “Same”, “Add”, and “Subtract”. In this example, “Same”, “Add”, and “Subtract” are detected like this. By detecting the evolution pattern “Add”, our method identified reuse behavior. Currently, we target only type-2 clone to derive clone genealogies. //つなぎ In the next step, our method clarifies who reused the existing code, and who originally created it. コードクローン の発生 新たなコード片 が追加 コードクローンである コード片が削除 変更なし [6]Yoshiki Higo, Keisuke Hotta, and Shinji Kusumoto. Enhancement of crd-based clone tracking. In Proceedings of the 13th International Workshop on Principles of Software Evolution (IWPSE2013), pp. 28{37, 8 2013.

STEP3: コードクローン作成者と利用者の特定 ソースコードの実装日時からコードクローンの作成者と利用者を検出 開発者A 開発者B コードクローン利用者: 再利用を行った開発者 コードクローン作成者: 再利用元のソースコードを記述した開発者 コピー rev. i rev. i+1 rev. i+2 rev. i+3 コピー A:2015/1/1 A:2015/1/1 A:2015/1/1 A:2015/1/1 B:2015/2/2 B:2015/2/2 B:2015/2/2 B:2015/2/2 開発者C コードクローン利用者: 再利用を行った開発者 C:2015/3/3 Version Control System such as subversion and git, usually has blame command which specify who implemented source code, and when. //rev. i+2のdeveloper name, dateを表示　⇒ 全revの表示 //Authorの吹き出し表示 Next, we detect clone set authors and users based on these development date. Here, the clone set author means a developer who implemented code snippet which was developed first in a clone genealogy. The clone set user means a developer who reuses code snippet in the genealogy. In this example, the clone set author of this clone set is Developer A, the clone set users of the clone set are Developer B and C. //selfでcopyの説明(省略してもいいです) In our method, if a developer reused his own code, the developer is identified as both of the author and the user of the clone set. 作成者と利用者の特定を行うことで，頻繁にソースコードが再利用される開発者の分析や，再利用を積極的に行う開発者についての分析などが可能となる

仮想マシンを用いた並列処理 ・・・ ・・・ ・・・ ・・・ 複数の仮想マシン(VM)を用意し，STEP2及びSTEP3を並列化 データベースサーバ用VM(DBserver) プログラム実行用VM(worker) STEP2:リビジョン(r)単位で並列化 STEP3:クローンの系譜(ID)単位で並列化 workers ・・・ workers ・・・ r1~2000 ID1~50 DBserver r2001~3000 ID51~100 r3001~3500 ID101~150 ・・・ fabricによって30台のworkerにプログラム起動命令を投げる 各workerはプログラムを起動しdbserverと接続される ・・・ r9901~10000 ID951 ~ 1000 後半のリビジョンほど処理時間が掛かることを考慮

ケーススタディ benten 版管理システムSubversionで管理されているJavaプロジェクトを対象に実施 実験概要 プロジェクト名 リビジョン数 開発者数 開発開始日時 benten 3258 3 2009/4/17 mergedoc 908 1 2007/11/8 itext 6738 28 2000/11/29 mailmarket 1158 7 2012/2/19 davmail 2332 2006/12/13 benten及びmergedoc に所属する開発者1名 itext及びmailmarket に所属する開発者2名 実験概要 AWS(Amazon Web Service)を用いて仮想マシンを用意 データベースサーバとしてm3.2xlargeインスタンスのVMを1台 プログラム実行用にc3.xlargeインスタンスのVMを30台 benten インスタンス名 OS CPU メモリ[GB] m3.2xlarge centOS 6.5 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz 30 c3.xlarge Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz 7.5

ケーススタディ分析項目 O1：開発者ごとの再利用傾向がどの程度異なるか O2:再利用されやすいソースコードを記述する開発者の特徴 コミット数の多い開発者はコードクローンの作成数と利用数も多いか O2:再利用されやすいソースコードを記述する開発者の特徴 再利用される回数の多い開発者はどのような特徴を持つか コミット数，所属しているプロジェクト数など O3:多くの開発者に再利用されるソースコードの特徴 再利用される回数の多いソースコードに特徴があるか O4：再利用を積極的に行う開発者の特徴 再利用回数の多い開発者にどのような特徴があるか O5: プロジェクト間での再利用の特徴 関わっている開発者や，ソースコードに特徴があるか 文章短く，端的に，一般性，文字大きく，ユニーク使う 「ユニークな利用者数とは，クローンセットのコードクローン利用者である開発者が何人であるかを表しています」

クローンの系譜と出力結果 パフォーマンス 処理時間 クローンの系譜について 開発者について(全開発者数は37名) STEP1: 1分55秒 STEP2: 12時間44分42秒(全VMの合計時間延べ93時間57分12秒) STEP3: 3分20秒(全VMの合計時間延べ81分44秒) クローンの系譜について 開発者について(全開発者数は37名) クローンの系譜の数 再利用回数 リポジトリ間の再利用 5396 5812 10 パフォーマンス 再利用された開発者 (セルフコピー含む) 再利用した開発者 (セルフコピー含む) 再利用された開発者 (セルフコピー含まず) 再利用した開発者 (セルフコピー含まず) 22 15

O1:開発者ごとの再利用傾向がどの程度異なるか コミット数と再利用回数の関係(コミット数5以上のみ表示) コミット数が多いと再利用回数も多いとは限らないことから，開発者ごとに再利用の傾向が異なることが分かる 他プロジェクトのコード片を頻繁に利用して開発を行っていた ため再利用回数が増えた 開発者Dはbentenとmergedocにに所属している 開発者OとWはitextとmailmarketに所属している

O2:再利用されやすいソースコードを記述する開発者の特徴 開発者Aはコミット数，再利用される回数，再利用回数のすべてが最も多い Sourceforgeのプロジェクト11個に所属 (そのほとんどがitext関連のプロジェクト) つまり，似ている機能のある他プロジェクトから再利用を行った可能性あり itextにおけるRoleはAdmin(16人中Admin5人) 開発者E(コミット数に対しての再利用される回数，再利用回数が多い) Sourceforgeのプロジェクト8つに所属 開発者H(コミット数に対しての再利用される回数，再利用回数が多い) Sourceforgeのプロジェクト3つに所属 ⇒ 『O4:再利用を積極的に行う開発者の特徴』についても同じであった

O3:多くの開発者に再利用されるソースコードの特徴[1/2] クローンの系譜ごとの再利用回数(再利用された回数が2以上のみ表示) 全クローンの系譜5396個の内，2回以上の再利用が行われたのは321個であった パフォーマンス

O3:多くの開発者に再利用されるソースコードの特徴[2/2] 再利用された回数が7回のコード片 createPDF(String filename)というPDFを作成するメソッドが7つのファイルに定義されていた ⇒ ライブラリ化の提案に繋がる可能性あり 再利用される回数の多いコード片について，クラスやメソッド単位での再利用といった，規模の大きい再利用が多いことが分かった private static void createPdf(String filename) { // we create a document with multiple pages and bookmarks Document document = new Document(); ・・・省略 document.close(); } パフォーマンス

O5: プロジェクト間での再利用の特徴 プロジェクトmergedocからbentenへの再利用が9回 翻訳プログラムにおいて，文字列分割機能を実装したファイルをプロジェクトをまたがってコピーすることで発生 あるプロジェクトで使用している一般的な機能を他のプロジェクトにうまく再利用できていたと考えられる プロジェクトmergedocからitextへの再利用が1回 getter及びsetterが一致したものであった public String trim() { if (body != null) { return body; } // 前後空白除去 trimSpace(original); ・・・省略 } return body; 文章短く，端的に，一般性，文字大きく，ユニーク使う 「ユニークな利用者数とは，クローンセットのコードクローン利用者である開発者が何人であるかを表しています」

まとめ 複数プロジェクトにおける開発者ごと再利用動向の分析手法の提案および調査を行った 今後の課題 コミット数が多いと再利用回数も多いとは言えず，開発者によって再利用動向が異なることを示した 再利用された回数の多いソースコードやプロジェクト間での再利用について特定及び分析ができることを示した 今後の課題 より大規模なプロジェクトを対象に実験 扱える版管理システムやプログラミング言語の増加 分析プロジェクト数の増加 より利用者の多いソースコードについての分析を実施 再利用支援ソフトウェアの構築 ライセンス違反の特定，ライブラリ化の提案やソースコード推薦といった再利用の支援を行う それなりのコミット(Topのコミッターの1/5以上)