一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
社団法人 電子情報通信学会
INFORMATIONAND COMMUNICATION ENGINEERS

信学技報
IEICE Technical Report
信学技報
MSS2018-78,SS2018-49(2019-01)

THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERSTECHNICAL REPORT OF IEICE.

Java メソッドの高精度な追跡のための細粒度版管理システムの提案
肥後 芳樹†

楠本 真二†† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{higo,kusumoto}@ist.osaka-u.ac.jp
あらまし

関数やメソッド単位での変更履歴情報を容易に取得するための手法として，Historage が提案されている．

Historage では関数やメソッドが単一のファイルとして扱われているため，それらの単位での変更履歴を容易に取得できる．しかし，Historage ではサイズの小さいファイルを多く扱うことから，ファイルの追跡精度に課題を残している．本研究では，追跡精度の向上を目指して，関数やメソッドを表すファイルの各行に単一の字句のみを配置するファイルフォーマットを提案する．さらに，実験に基づいた 3 つの経験則を導入し，さらなる高精度でのファイルの追跡を目指す．
キーワード

版管理システム，ソースコード解析，ソフトウェアリポジトリマイニングを必要とする研究も多い．そのような研究では，版管理システ

1. は じ め にムからファイルを取得したあとに構文解析を行い，関数やメ（注 1）等の版管理システムをソッドを取得する必要がある．さらに，各関数や各メソッドに用いてソフトウェアプロダクトを管理することは必須である．

現代のソフトウェア開発では，Git変更が加えられたかどうかを調査するためには，版管理システ

版管理システムが提供する機能を用いることで，過去の任意のムから提供されるファイル単位での差分情報と，関数やメソッバージョンに戻る，バージョン間の差分を確認する，複数の開ドの開始位置および終了位置を突き合わせる必要があり，効率発者が書いたコードを統合する等が容易に行える．また，開発的に分析することが難しい．

者が，版管理システムに蓄えられた履歴情報をデバッグ，コーHata らは，容易に関数やメソッド単位の変更履歴情報を取ドの理解，変更の意図の確認等に利用することもある [1]．さ得するための細粒度版管理システム Historage を提案した [3]．

らに，GitHub（注 2）や Bitbucket（注 3）等の版管理システムのホス

Historage は既存の Git リポジトリを入力として受け取り，そティングサービスを利用することで，課題やレビューの管理をの中に含まれる Java ソースファイル内の各メソッドを単一のプロダクトと紐付けて行える．これにより，ソフトウェア開発ファイルとして切り出し，それらを管理するリポジトリを構築における開発者の活動が効果的に支援されると共にそれらが記する．Historage リポジトリでは，Java の各メソッドがファイ録として残る [2]．

ルになっているため，メソッド単位での変更情報を容易に取得

版管理システムやホスティングサービスに記録された情報かできる．構文解析や位置情報の突き合わせを行う必要はない．

ら有益な知見を見つけ，それを将来のソフトウェア開発に活か

図 1 は，Git リポジトリとそこから構築した Historage リポすための研究が活発に行われている．その研究の主要な対象のジトリの例である．Git リポジトリ（図 1(a)）では A.java が1 つとしてソフトウェアのソースコードが挙げられる．例えば，管理されている．コミット c100 と c101 では，A.java が変更

バグを含むモジュールを予測する研究や繰り返し行われる変更されている．ファイル単位での変更履歴は，“git-log” 等のコの内容を抽出する研究が数多く行われている．

マンドを利用することで容易に取得できる．どのメソッドが変版管理システムでは，ソースコードはファイル単位で管理さ更されたのかを調査する場合には，A.java の構文解析を行うれる．ファイル単位で管理されているため，どこのコミットでことによりメソッドの位置情報を特定し，メソッドの位置情報どのファイルに変更が行われたのか，各ファイルに何回変更がとファイル単位での変更の位置情報を突き合わせる必要があ加えられたのかといったファイル単位の情報が容易に取得でる．しかし，そのような分析を行うためにはツールの整備等のきる．分析がファイル単位で行われる場合は，版管理システム手間が必要である．それに対して，Historage リポジトリ（図で管理されているファイルをそのまま用いれば良い．しかし，1(b)）では，各メソッドがファイルとして管理されているため，ファイルよりも細かい粒度である関数やメソッド単位での分析“git-log” 等のコマンドを利用することで容易にメソッド単位での変更情報を得ることができる．図 1 の例では，Git のリポ（注 1）：https://git-scm.com/

ジトリからは A.java に対して二度のバグ修正が行われたこと（注 2）：https://github.com/がわかる．それに対して，Historage リポジトリを利用するこ（注 3）：https://bitbucket.org/とで，メソッド method01() とメソッド method02() に，一度- 133 —1—
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©2019 by IEICEA.java

ソースファイル内の各メソッドが単一ファイルとして抽出されている

method01()
method02()

method01()

method02()

bugfix (issue #10)
commit c100

bugfix (issue #10)
commit c100
bugfix (issue #20)

bugfix (issue #20)
commit c101

commit c101(a) Git リポジトリ(b) Historage リポジトリ

図 1 Git と Historage の違いずつバグ修正が行われたことが容易にわかる．

•

しかし，Historage には課題もある．図 2 は，Person.java

ファイル名の命名規則というファイルに対して名前変更リファクタリングが行われ，

本研究では，Java メソッドを表すファイルはその名前に以下その内部のフィールド名も同時に変更された様子を表している．変更前ファイルにおいて赤で強調された行と変更後ファイの情報を含むとする．

ルにおいて緑で強調された行は，変更された行を表している．
図 2(a) に示すようにファイル名が変更された場合であっても変更されていない行の割合が大きければ，Git のリネーム検出機能でファイルを追跡できる．しかし，Historage リポジトリの場合は，図 2(b) のように，ファイル全体に対する変更行のが小さくなってしまうために，ファイル名が変更された場合の•そのメソッドを含むクラスの名前•

そのメソッドのアクセス修飾子•

そのメソッドの返値の型•

そのメソッドの名前•

そのメソッドの引数の型

これらの情報をファイル名に含めることにより，対象とする割合が大きくなってしまうため，追跡できなくなってしまう．

Historage リポジトリでは，Git リポジトリに比べてファイルJava メソッドを切り出したファイルの行フォーマット

メソッドの周辺におけるさまざまな変更は以下のようにメソッドのファイルに反映される．
ケース 1 対象メソッドを含むクラス名が変更された場合は，追跡能力が落ちてしまうことが課題である．

Hata らは対応策として，変更されていない行の割合が低くても追跡を行えるように，しきい値を変更することが有効であると主張している [3]．しかし，しきい値を下げることにより，まったく関係のないファイルを誤って同じファイルと見なしてしまう危険性が強くなってしまう．例えば，
図 2(b) の 場 合 は ，追 跡 に 必 要 な し き い 値 を デ フ ォ ル ト 値の 0.6 から Hata らが有効だと主張している 0.3 に下げることにより，“Person/getLength” から “Engineer/getHeight”
へ と 追 跡 可 能 に な る が ，“Person/getLength” か ら 誤 っ て“Engineer/setHeight” を追跡してしまう可能性もある．
本研究では，追跡精度の向上を目的として，メソッドを切り対象メソッドのファイルの名前は変わるが内容は変更されない．
ケース 2 対象メソッドを含むクラスの別のメソッドが変更された場合は，対象メソッドのファイル名も内容も変更されない．
ケース 3 対象メソッドのシグネチャが変更された場合は，対象メソッドのファイル名は変わるが内容は変更されない．
ケース 4 対象メソッドの内容が変更された場合は，対象メソッドのファイル名は変わらないが，内容が変更される．
上記いずれのケースであっても Git のメカニズムを利用することで追跡可能である．提案手法が追跡できないのは，メソッドのシグネチャやそのメソッドを含むクラスの名前が変更され，かつメソッドの内容が大幅に変更された場合である．

Historage でも Java メソッドを表す各ファイルには，その出したファイルの各行に単一の字句のみを配置することを提案する．また，実験に基づいた 3 つの経験則を導入することにより，さらなる精度向上を試みる．

メソッドのシグネチャ情報が含まれている．Historage と提案手法の違いは，Historage が Java の各クラスを表すディレクトリを作成しそれ以下に Java メソッドを表すファイルを配置

2. 提 案 手 法するのに対して，提案手法では Java メソッドを表す各ファイ

本研究では，Git のメカニズムを用いて Java メソッドの高精度な追跡を行う手法を提案する．提案手法は大きく以下の 2つの項目からなる．

•Java メソッドを切り出したファイル名の命名規則

ルは元の Java ファイルと同一ディレクトリに配置される．提案手法で各クラスからディレクトリを作成するのを避けた理由
は，Historage は大規模なリポジトリに対しては処理時間が長くなってしまう傾向にあること，およびその原因の 1 つが各ク

- 134 -—2—

Person.java
public class Person {…
private int length;…
public int getLength(){return length;}…
public void setLength(int length){this.length = length;}…
}

publicintgetLength(){
returnlength;}

ファイル全体に対する変更行が少ないため，Gitの名前変更検出機能で追跡できる
Engineer.java

publicvoidsetLength(intlength){
this.
length=length;}

ファイル全体に対する変更行が少ないため，Gitの名前変更検出機能で追跡できる

public class Engineer {…
private int height;…
public int getHeight(){return height;}…
public void setHeight(int height){
this.height = height;}…
}

publicint
getHeight(){
returnheight;}(a) Git

Person/gentLength
public int getLength(){return length;}

publicvoid
setHeight(intheight){
this.
height=height;}

図 3 Git と Historage の違いの字句のみを配置することを提案する．各行が単一の字句のみ

ファイル全体に対する変更行が多いため，Gitの名前変更検出機能で追跡できない
Engineer/gentHeightを持つため，各ハッシュ値は単一の字句から生成される．
図 2(b) では，getLength および setLength メソッドにおいpublic int getHeight(){
return height;}てメソッド名と変数名が変更されているのみである．しかし，それらを含む行全体が変更されたとみなされてしまうため，ファイル全体に対するされなかった行の割合が 1/3 になってしま

Person/setLength

い，デフォルトのしきい値である 0.6 より小さくなるため，追public void setLength(int length){this.length = length;}

跡できない．
図 2(b) の変更を，提案手法を用いて表すと図 3 のようになファイル全体に対する変更行が多いため，Gitの名前変更検出機能で追跡できない
Engineer/setHeight

る．提案手法を利用すると，getLength メソッドの変更されなかった行の割合は 8/10(=0.80)，setLength の変更されなかっpublic void setHeight(int height){
this.height = height;}

た行の割合は 11/15(=0.73) となり，どちらも 0.6 を上回るため追跡できる．

(b) Historage

提案手法にはもう 1 つ利点がある．各行が単一字句であるの

図 2 Git と Historage の違い

ですでに字句解析が完了した状態であり，そのあとの分析作業に用いやすい．Historage の場合は，例えばメソッドの字句数ラスからディレクトリを作成することによるリポジトリのさらを計測する場合には，字句解析器を用いる必要があるが，提案なる大規模化であるからである．提案手法を用いた場合でも管手法ではファイルの行数を数えるだけでよい．メソッド内で利理するファイル数は元の Git リポジトリよりも多くなってしま

用されているユーザ定義名も容易に取得できる．

うが，Historage のようにディレクトリ数まで増えてしまうこ

2. 1 予 備 実 験とはない．

提案手法の追跡能力を確認するために予備実験を行った．こ
こでは，追跡の精度を手作業で確認するために，小規模なオーファイルの行フォーマット

Git はハッシュ値を用いてファイルの比較を行う．ハッシュ値は各行から算出されるが，一行が 64 バイトを超える場合には，64 バイト毎にハッシュ値が生成される．このため，行内における変更が小さい場合でも，その行全体やその 64 バイト全体が変わったとみなされる．よって，本研究では，各行に単一プンソースソフトウェアである paho.mqtt.android（注 4）を対象とした．対象ソフトウェアのリポジトリは 2018 年 9 月 13 日に取得した．取得時点でのコミット数は 195，最新コミットにおけるメソッド数も 195 である．この 195 のメソッドに対して，（注 4）：https://github.com/eclipse/paho.mqtt.android- 135 -—3—

Historage と提案手法それぞれを利用した場合の追跡の違いをは，そのメソッドのファイルと同名のファイルが存在しない調査した．なお，どちらの手法もしきい値として 0.3 と 0.6 の場合である．メソッドのファイル名が変更されるのは，そのメ2 つを用いた．

ソッドのシグネチャが変更された場合に加えて，そのメソッド予備実験では，しきい値 0.6 を用いた場合の Historage を基を含むクラスのクラス名が変更された場合や，そのメソッドが準として，その他の 3 つの手法がより長い期間追跡したメソッ他のクラスに移動した場合である．調査の結果，メソッド内がドおよびより短い期間追跡したメソッドを特定した．そして，大きく変更されており，かつメソッドのファイル名が変わってそれらのメソッドについて，その「より長い期間の追跡」もししまっていても，そのメソッドのシグネチャやメソッド名は保

くは「より短い期間の追跡」が正しいかどうかを手作業により持されていることが多かった．また，類似度が 0.3∼0.6 の間で調査した．

誤って追跡してしまったメソッドはその多くでシグネチャやメ

表 1 は，予備実験の結果を表している．「差異メソッド数」は追跡期間が異なったメソッドの数を表しており，「差異の正誤」ソッド名が異なるという結果であった．このことから，追跡のしきい値を以下の戦略で用いる経験則 1 を導入する．

は手作業による調査結果を表している．Historage(0.3) および提案手法 (0.6) では，基準と比べて 4 つのメソッド（全メソッ•ドの約 4%）のみの追跡結果が異なっていた．一方，提案手法(0.3) では，30 のファイル（全メソッドの 15%）について基準と••であり，残りの 1 つが誤った追跡となってしまったメソッドでであった．

経験則 2

提案手法でしきい値 0.6 を用いた場合には，Historage のしきい値 0.3 を用いた場合は追跡の能力はほどんど変わらない．

•Java のソースコードには括弧やセミコロンが多数出現する．
それらはさまざまなプログラム要素の一部として用いられている．例えば，中括弧（“{” と “}”）は，if ブロックや for ブ

予備実験の結果をまとめると次のようになる．

•メソッドのシグネチャもメソッド名も異なる場合にはGit デフォルトのしきい値（0.6）で追跡する．

あった．一方，提案手法 (0.3) では，正しく追跡できていたメ
ソッドは 6 つのみであり，残りの 24 のメソッドは誤った追跡

メソッドのシグネチャは異なるがメソッド名は同じ場合にはしきい値をやや高くして（例えば 0.45）追跡する．

異なる結果であった．Historage(0.3) および提案手法 (0.6) は，4 つの異なる追跡結果のうち 3 つが正しく追跡できたメソッド

メソッドのシグネチャが同じ場合には低いしきい値（例えば 0.3）で追跡する．

提案手法でしきい値 0.3 を用いた場合には，より長い期間追跡できるメソッドは増えるが，誤検出も増えてしまう．
次節では，より長い期間追跡できたメソッドの数をできるだけ減らさずに，誤検出のみを減らすための経験則について述べる．

ロック等の範囲を表現する以外に，配列の初期化にも用いられる．そのため，各行に単一字句を配置する提案手法では，異なる役割を持つ括弧やセミコロンが偶然一致してしまい，類似度が不適切に高くなってしまう場合がある．そこで，経験則 2 として，字句の役割を表す文字列を各行に追記することを提案する．これにより，異なった役割を持つ括弧やセミコロンが偶然一致してしまうことを避けることができる．

2. 2 経験則の導入

図 4 は経験則 2 の有無による類似度の違いを表す例である．

メソッドが誤って追跡されてしまうのは，あるコミットにおいて削除されたメソッドと追加されたメソッドの類似度が偶然しきい値以上になってしまうためである．よって，経験則は，そのような異なるメソッドについて，しきい値を超えないような工夫となる．本研究では，以下の 3 つの経験則を導入する．
経験則 1 メソッドのシグネチャが一致している場合やメソッド名が一致している場合のみ，低いしきい値を用いる．
経験則 2 括弧やセミコロン等の字句について，その種類を詳細に分ける．
経験則 3 メソッドに必ず含まれる字句を類似度の計測対象から外す．

図 4(a) は，Historage の出力した Java メソッドのファイルを表している．対象コミットで削除されたメソッドには null チェッ
クをするための if ブロックが含まれており，同じコミットで追加されたメソッドには変数 b の値を変数 total に加える whileブロックが含まれている．この if ブロックと while ブロックを含むメソッドは異なるため，追跡すべきではない．Historageの場合は，これらのブロックの最終行が偶然一致してしまい，ブロック部分の類似度は 1/3(=0.33) となる．提案手法を用いた場合（図 4(b)）は，if 文と while 文の丸括弧と中括弧，および return 文のセミコロンと式文のセミコロンが一致してしまうため，類似度は 5/12(=0.42) になる．一方，経験則を導入以降，各経験則について詳細に述べる．

することで（図 4(c)）これらの丸括弧，中括弧，セミコロンは一致しなくなるため，類似度は 0/12(=0.00) となる．

経験則 1
類似度を利用してメソッドを追跡するかどうかを判断するの

経験則 3Java のメソッドには構文規則上，引数を囲むための丸括弧と表 1 予備実験の結果
手法

Historage

提案手法

提案手法

メソッド本体を囲むための中括弧が存在する．つまり，メソッ（しきい値）

(0.3)

(0.6)

(0.3)

ドの類似度を計測した場合，これら 4 つの字句は必ず一致する

差異メソッド数 長 2 短 2 長 3 短 1 長 28
差異の正誤

正3 誤1 正3 誤1

正6

短2
誤 24

（注 4）：シグネチャが一致する場合のしきい値は 30，メソッド名が一致する場合のしきい値は 45，それ以外の場合のしきい値は 60．

- 136 -—4—

削除されたメソッド削除されたメソッド

削除されたメソッド…

publicint
getLength(){
returnlength;}

publicint
getLength(){
returnlength;}if(null == a){return true;}…
異なる種類のブロックの右括弧が一致してしまう
追加されたメソッド…

メソッドの丸括弧と中括弧が一致してしまう

while(b < 10){total += b;}…
(a) Historage
削除されたメソッド

削除されたメソッド…
if(null==a){returntrue;}…

…
if(null==a){returntrue;}…

括弧，セミコロンが一致してしまうIF
IFLEFTPAREN
NULL
EQUAL
VARIABLEIFRIGHTPAREN
IFLEFTBRACKETRETURNTRUE
RETURNSEMICOLONIFZRIGHTBRACKET

追加されたメソッド

追加されたメソッド…
while(b<10){
total+=b;}
…

…
while
(b<10){total+=b;}…

PUBLICINTMETHODNAMEMETHODLEFTPAREN
METHODRIGHTPAREN
METHODLEFTBRACKETRETURN
VARIABLE
RETURNSEMICOLONMETHODRIGHTBRACKET

メソッドの丸括弧と中括弧は計測対象外追加されたメソッド

追加されたメソッド

publicvoid
setHeight(intheight){this.
height=height;}

publicvoid
setHeight(intheight){this.
height=height;}

PUBLICVOIDMETHODNAMEMETHODLLEFTPARENINT
VARIABLEETHODRIGHTPAREN
METHODLEFTBRACKET
THIS
DOT
VARIABLEASSIGN
VARIABLE
EXPRESSIONSEMICOLONMETHODRIGHTBRACKET(a) 提案手法（経験則 3 無し）

PUBLICVOIDMETHODNAMEMETHODLLEFTPARENINT
VARIABLEETHODRIGHTPAREN
METHODLEFTBRACKET
THIS
DOT
VARIABLEASSIGN
VARIABLE
EXPRESSIONSEMICOLONMETHODRIGHTBRACKET(b) 提案手法（経験則 3 有り）

図 5 経験則 3 の例

3. 実

まったく一致しない(b) 提案手法（経験則 2 無PUBLICINTMETHODNAMEMETHODLEFTPAREN
METHODRIGHTPAREN
METHODLEFTBRACKETRETURN
VARIABLE
RETURNSEMICOLONMETHODRIGHTBRACKET

装

2. 節で述べた 3 つの経験則を含む提案手法をオープンソース
ソフトウェア FinerGit（注 5）として実装した．FinerGit の入力

WHILE
WHILELEFTPAREN
VARIABLELESSNUMBERLITERALWHILERIGHTPAREN
WHILELEFTBRACKETVARIABLE
PLUSEQUALVARIABLE
WHILEBRACKET
WHILERIGHTBRACKETは Java のソースコードが管理されている Git リポジトリであり，出力は各 Java メソッドがファイルに切り出された Git リポジトリである．
出力された Git リポジトリにおいて，各 Java メソッドは.mjava という拡張子を持つファイルである．これらのファイルに対して，“git-log” 等のコマンドを利用することにより，他の種類のファイルと同様に，そのファイルの変更履歴を取得できる．また，FinerGit では “git-sv” という新しいコマンドが用意されており，経験則 1 を利用したメソッドのシグネチャ(c) 提案手法（経験則 2 有り）し）やメソッド名の同一性に基づいたファイルの追跡を行うことが
図 4 経験則 2 の例

できる．

.mjava ファイルはファイル名にクラス名とメソッドシグネため，類似度を不適切に高めてしまう．メソッドが多数の字句チャの情報を含むため，ファイル名が非常に長くなってしまうを含む場合は，4 つの字句が一致してもその影響は少ないが，場合がある．これは，標準的に用いられている OS とは相性がオブジェクト指向で多用されるセッターやゲッター等の小さなよくない．例えば，Windows10 の場合では，ファイルの絶対メソッドの場合は，4 つの字句の一致は影響が大きい．そこでパスの文字数が 260 を超えるとファイルマネージャーからア

本研究では，経験則 3 としてこれら 4 つの字句を類似度の計測クセスできない等の問題が発生する．Linux や MacOS の場合対象から外す．これにより，メソッドの類似度が不適切に高くはファイル名が 255 文字を超えることはできない．そのため，なってしまうことを抑制できる．

FinerGit では生成したファイル名が長くなる場合にはファイル

図 5 は，経験則 3 の有無の違いを表す例である．この例は，

表 2 メソッド追跡の設定

図 2 における変更前の getLength と変更後の setHeight 間の類似度を計測する例である．これらは別のメソッドであるた

設定名行フォーマット

閾値

経験則 1 経験則 2 経験則 3

FG

単一字句

0.6

有（注 6）

有有め，類似度は低い方が望ましい．経験則 3 を用いない場合（図HIS30 元ファイルと同じ

0.3無無無5(a)）は，メソッドの丸括弧と中括弧が一致してしまうため，

HIS60 元ファイルと同じ0.6

無無無類似度は 5/10(=0.5) となってしまう．それに対して，経験則

3 を導入するとこれらが計測対象から外れるため，類似度は1/6(=0.17) に下がる．

（注 5）：https://github.com/kusumotolab/FinerGit（注 6）：シグネチャが同一の場合はしきい値 30，メソッド名のみが同一の場合はしきい値 45 とした．

- 137 -

—5—

名の後部を削除し，その代わりにファイル名全体から生成した

かった．

ハッシュ値を付与することにより，ファイル名が長くなりすぎるのを防ぐ．

4. 評

また，追跡の精度についても評価を行った．精度については，比較的メソッド数の少ない paho.mqtt.java に対して，FG がHIS60 よりも長く追跡できた 40 のメソッドと，HIS30 が HIS60

価よりも長く追跡できた 29 のメソッドについて，その追跡が正FinerGit を用いて提案手法の評価を行った．メソッド単位でしいのかどうかを手作業により確認した．その結果，FG がよファイルを切り出すシステムとしては Historage [3] が存在する

り長く追跡した 40 のメソッドのうち 38 は正しい追跡であった

ため，Historage との比較により，FinerGit を評価した．このこと，および HIS30 がより長く追跡できた 29 のメソッドのう実験では，FinerGit と Historage の細部の実装差が計測に与えち 27 は正しい追跡であったことがわかった．その結果，より長る影響を憂慮し，FinerGit に Historage と同様の機能を実装しく追跡できたメソッドの精度は FG において 0.95（=38/40），て，提案手法と比較した．表 2 は，この実験における FinerGit

HIS30 において 0.93（=27/29）であった．よって，Historageと Historage の設定を表している．

でしきい値として 0.3 を用いた場合と，FinerGit でしきい値

HIS30 と HIS60 は Historage を模した追跡であり，ファイルの各行は元ファイルと同じである．3 つの経験則は追跡に用

0.6 を用いた場合に，追跡の精度は同じであるが，提案手法がより長く追跡できたメソッドの方が多かった．

いられない．

5. お わ り に評価の対象として，GitHub に公開されている Eclipse プロジェクトのスター数が上位 10 件の Java プロジェクト（注 7）を選

本稿では，Java メソッドの開発履歴を高精度で追跡するためんだ．表 3 は，対象プロジェクト名，コミット数，最新コミッの手法を提案した．提案手法は，FinerGit というツールとしてトにおけるメソッド数に加えて，3 つのうちの 2 つの追跡を実装され，現在すでに GitHub で公開されている．FinerGit と比べた結果も表している．例えば，「FG 対 HIS60」は，この既存手法の Historage を比較したところ，FinerGit の方が追跡2 つの設定におけるメソッドの追跡結果を比べた結果であり，能力が優れていることが確認できた．今後は，FinerGit を利用「FG」の列は FG の方がより長く追跡できたメソッドの数を表して，ソフトウエアリポジトリマイニングの研究のレプリケーし，「HIS60」は HIS60 の方が長く追跡できたメソッドの数をションを行い，精度の高いメソッドの追跡により，既存研究の表している．この表の結果をまとめると以下のようになる．

実験結果が変わることがないかを調査する予定である．
謝辞• 「FG 対 HIS60」の列から，FinerGit を利用することに本研究は，日本学術振興会科学研究費補助金基盤研究より，より長く追跡できたメソッドが多数存在していることが（B）（課題番号：17H01725）の助成を得て行われた．

わかる．しかし，その一方で，Historage の方がより長く追跡文できたメソッドも存在していた．

•献[1] M. Codoban, S.S. Ragavan, D. Dig, and B. Bailey, “Software History Under the Lens: A Study on Why and How
Developers Examine It,” Proceedings of the 2015 IEEE International Conference on Software Maintenance and Evolution, pp.1–10, 2015.
[2] L. Dabbish, C. Stuart, J. Tsay, and J. Herbsleb, “SocialCoding in GitHub: Transparency and Collaboration in an
Open Software Repository,” Proceedings of the ACM 2012
Conference on Computer Supported Cooperative Work,
pp.1277–1286, 2012.
[3] H. Hata, O. Mizuno, and T. Kikuno, “Historage: Finegrained Version Control System for Java,” Proceedings ofthe 12th International Workshop on Principles of Software
Evolution and the 7th Annual ERCIM Workshop on Software Evolution, pp.96–100, 2011.

「HIS30 対 HIS60」の列から，Historage のしきい値を0.6 から 0.3 に変更することで，より長く追跡できるメソッドが増えることがわかる．しかしながら，しきい値が 0.6 の場合の方が長く追跡できたメソッドも存在していた．

• 「FG 対 HIS30」の列から，FinerGit を利用することにより，Historage のしきい値として 0.3 を用いた場合よりも多くのメソッドをより長く追跡できた．しかし，eclipse-collectionsについては，Historage の方が長く追跡できたメソッドが多（注 7）：2018 年 9 月 13 日時点のランキング

表 3 評価対象 Java プロジェクト
プロジェクト

コミット数

メソッド数

（GitHub のプロジェクトフォルダ名）（2018/9/13 時点）（2018/9/13 時点）

FG 対 HIS60

HIS30 対 HIS60

FG HIS60 HIS30

eclipse-vertx/vert.x

3,652

5,520

950

53570

eclipse/che

6,658

36,142 2,224

16

eclipse/jetty.project16,063

12,236 1,783

eclipse/openj9

3,494

18,81237

eclipse/paho.mqtt.android

195

195

eclipse/eclipse-collections

875

eclipse/smarthome
eclipse/paho.mqtt.java
eclipse/jgit
eclipse/egit-github

HIS60
35

FG 対 HIS30
FG HIS30
502

76

1,415

8 1,010

128

33

1,093

31

895

107

1

18

1

20

188

8

1

2

9

15,959

325

8147

5

196

21

4,800

13,613

899

153

675

151

328

89509

1,523

40

0

290

17

4

6,198

8,391

506

10

310

12248

32

857

1,910

127

13

122

13

44

35

- 138 -—6—