ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

修正履歴情報を利用した
コミット分割支援手法の提案
切貫 弘之†1,a)

堀田 圭佑†1,b)

肥後 芳樹†1,c)

楠本 真二†1,d)

概要：一般的に，版管理の 1 つのコミットでは複数のタスクを含む修正を行うべきではないといわれている．このような修正をもつれた修正と呼ぶ．もつれた修正を行うことは，開発者にとってデメリットが多い．例えば，複数のタスクを行うコミットが存在する場合，そのコミットに含まれるある単一のタスクのみをマージする，あるいは取り消すことができない．また，もつれた修正の存在はリポジトリマイニングの妨げとなる．なぜなら，リポジトリマイニングの手法の多くはもつれた修正がないことを前提としているからである．そこで，本研究では，過去のコミットの情報を利用することで，開発者がもつれた修正である可能性が高いコミットを行おうとした際にそれを開発者に知らせ，そのコミットを複数のコミットに分割する手法を提案する．コミットを分割する前に，まず分割候補を開発者に提示し，開発者はそのまま
コミットを行うか，提示された候補に従って分割されたコミットを適用するかを選択できる．このような支援を行うことによって，開発者がもつれた修正を行うことを防ぐことができる．
キーワード：バージョン管理システム, tangled changes, ソフトウェアリポジトリ

1. はじめにの [1], [3], [4], [10], [18], [20]，コードクローンに関するものなどがある [8], [17]．

近年，ソフトウェアリポジトリマイニング（以降，マイバージョン管理システムを利用した開発では，一度のニング）に関する研究が注目され，さかんに行われていコミットでは複数のタスクに関する修正を行わないことる [5], [10]. ソフトウェアリポジトリ（以降，リポジトリ）を求められている [12]. しかし，このことが広く受け入れにはソフトウェアの開発プロジェクトに関連する様々な情られているにも関わらず，開発者はしばしば複数のタス報が蓄積されている．マイニング技術を用いることで，リクに関する修正を一度にコミットすることがある．例え

ポジトリからソフトウェア開発に有益な情報を得ることがば，Murphy-Hill らは，リファクタリングを行った修正は可能である.[6], [11], [15], [19]．マイニングによって得られ他のタスクを行った修正と同時にコミットされることが多た情報は将来的なソフトウェアの保守や開発に活かすこといことを明らかにしている [16]．このような複数のタスクができる．

を伴った修正を本論文ではもつれた修正と呼ぶこととす

マイニングの対象となるリポジトリには様々なものがる [7]．

あるが，特にソースコードリポジトリを対象とする研究もつれた修正の存在は，ソフトウェア開発を効率よく進がさかんである．Subversion, CSV, Git に代表されるバー

める上での妨げとなる [5], [7]．そのような例を以下に示す．

ジョン管理システムを用いて開発を行う際に作成され• もつれた修正をマージする際に手動での操作を必要とたソースコードリポジトリはしばしばマイニングの対象する場合がある．修正をマージするということは，あとなる．ソースコードリポジトリを対象としたマイニン

るブランチで行われた修正を他のブランチに適用する

グの研究分野は多岐にわたっており，プログラム中の欠ことを意味する．ある修正をマージする際，マージ作

陥に関するもの [2], [6]，ソースコードの修正に関するも業の対象としているコミットで単一のタスクのみが行

†1
a)
b)
c)
d)

現在，大阪大学
Presently with Osaka University
h-kirink@ist.osaka-u.ac.jp
k-hotta@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

c 2014 Information Processing Society of Japan⃝

われているならば，バージョン管理システムのマージ機能を用いるだけで目的を達成できる．しかし，マージ作業の対象としているコミットで複数のタスクが行われている場合，その中の特定のタスクに関する修正

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

のみを適用することは難しい．そのような場合，下記る問題を避けるため，開発者がもつれた修正を行うことをのいずれかの方法をとらなければならない．

事前に防ぐ手法を提案する．コミットする前に，潜在的な– バージョン管理システムのマージ機能を用いず，手動でマージ操作を行う– バージョン管理システムのマージ機能を用いた後，手もつれた修正の存在を開発者に気づかせることができるという点で，著者らの手法は有用である．著者らの過去の研究では，過去に一度行われた修正を含むような修正はもつ動で一部の修正を取り消す

れた修正である可能性が高いという考えに基づき，コミッ

しかし，いずれの場合も手動による操作が必要となっトを分割する手法を提案している [13]．本研究では，これてしまう．

に経験則を追加することで，より適切な分割を行えるよう• もつれた修正では，そこで行われた特定のタスクのみにし，さらに手法の精度の定量的な評価を行っている．

を取り消すことができない．バージョン管理システム

本研究の貢献は以下のとおりである．

の取り消し機能を用いた場合，そのコミットで行われ• 開発者が行おうとした，もつれていると思われる修正た全ての修正が取り消されてしまう．

• もつれた修正が存在すると，差分情報を用いたコードを検知し，それらを複数の修正に分割する方法を提示する手法を提案した．

レビューが困難になる．なぜなら，それぞれのタスク• 提案手法の有効性を評価した結果，もつれた修正であに関する修正が，ソースコードの差分のどの部分に対る可能性が高いコミットに対して提示された分割候補応するのかが分かりづらくなるためである．

の中で，不適切でないと思われるものの割合は 75%か

これらに加えて，もつれた修正の存在は，マイニングの妨げにもなる．なぜなら，ほとんどのマイニング手法はもつれた修正がないことを前提としているからである．

ら 92%であった．

2. 研究の動機

evolutionary coupling を用いた手法はその良い例であソフトウェア開発のプロジェクトにおいて，もつれた修る [18]. ファイルやメソッド等のソフトウェアのモジュー正がしばしば行われ，そのことは様々な問題をはらんでいルが修正された時，それと同時に修正されるべきものを特ることを 1 章で説明した．コミットログが，行われた修正定するために evolutionary coupling が用いられる．多くの全てを説明しておらず，もつれた修正が行われているこの手法では，同じコミットで修正されたモジュールが evo-とがコミットログから判断できない場合も多い．

lutionary coupling を持つとみなされている．evolutionary

図 1 は，オープンソースソフトウェア JEdit で，もつれcoupling を用いる手法では，同時に修正されている複数のていると思われる修正が行われた例である．コミットログ

モジュールがある場合，その間に何らかの関係があると解では fix latex mode と書かれており，バグ修正と推測さ釈されるため，本来関係のないモジュールの修正が同時にコ

れるが，これは曖昧な表現である．実際にこのコミットでミットされることは想定していない．従って，evolutionary

行われている修正は次の 2 つである．

coupling を用いた手法は明らかにもつれた修正がないことを前提としている．
既存のマイニング手法では，多くのファイルや多くの行が修正されているコミット（以降，ラージコミット）を取り• メソッド closeBuﬀer() で変数 view の null チェックが追加された• メソッド newView() で非推奨 API が推奨 API に変更
された

除く前処理がしばしば行われている．なぜなら，ラージコ

もし，後者の修正が，バグ修正の一部として行われてミットでは，もつれた修正や，マイニングの際に考慮する

いないならば，これらの 2 つの修正は互いに関係がなく，必要のないコメントやフォーマットの修正などが行われる

別々のコミットに分けて行われるべきである．もし，このことが多いからである [9]. ラージコミットを除去すること

リポジトリに対し，メソッド間の evolutionary coupling をで，もつれた修正が分析結果に与える悪影響をある程度取特定するためのマイニングを行ったならば，本来は関係がり除くことができる．しかし，そのような前処理はもつれ無い closeBuﬀer() と newView() の間に何らかの関係があた修正を取り除くという意味では決して完全ではない [14]．

るとみなされてしまう．よって，このようなもつれた修正• ラージコミットの中にはもつれた修正を行っていないを未然に防ぐことは重要な意味を持つ．

ものも存在する．従って，全てのラージコミットを取本研究では，もつれていると思われる修正を開発者が行り除くことは意図せずそのようなコミットまで取り除おうとした時にそれを検知し，コミットの分割候補を提示いてしまうことになる．

する手法を提案する．

• 規模の小さなコミットの中にももつれた修正が存在す提案手法では，リポジトリ中の修正履歴情報を用いるこる．ラージコミットを対象とする前処理ではそのようとで，もつれた修正である可能性が高いコミットを検出すな場合に対応できない．

る．異なるコミットで類似した修正が繰り返し行われる場

そこで本論文では，もつれた修正によって引き起こされc 2014 Information Processing Society of Japan⃝

合があることを Higo らは確認している [21]．ある単一のソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

3.1 概要図 3 は手法のおおまかな流れを示している．手法は，大きく修正履歴情報の抽出とコミットの分割候補の提示に分けられる．修正履歴情報の抽出の手順を簡単に説明する．
リポジトリを入力とし，修正履歴情報が蓄えられたデータ
ベースを作成する．この時，修正履歴情報の抽出に用いた
リポジトリの中に，もつれた修正を行ったコミットが存在する可能性がある．コミットの分割候補を開発者に提示するために用いる修正履歴は，もつれた修正でないという前提があるため，データベース中の包含修正を解消すること
で，もつれた修正の数を減らす処理を行う．
提案手法では，修正履歴情報の抽出を事前に行っておき，開発者がリポジトリに修正をコミットする際に，コミットの分割候補の提示を行う．以下の手順に分けて，3.2，3.3
節で詳しく説明する．

( 1 ) 修正履歴情報の抽出
図 1 もつれていると思われる修正の例( 2 ) コミットの分割候補の提示

開発者が行おうとしているコミットは
nullチェックの追加を含む

開発者が行おうとしているコミット

開発者が行おうとしている
コミットに含まれるような
過去のコミットを見つける?

nullチェックの追加

定する．以降の説明では，既に n リビジョンがリポジトリ
nullチェックの追加?

nullチェックの追加のみが行われたコミット

図 2(2) で提示された分割候補に従うかどうかは開発者が決手法の軸となる考え方中に存在しており，開発者が新たなコミットを行う準備ができているものとする．

3.2 修正履歴情報の抽出
リビジョン r から r + 1(1 ≤ r ≤ n − 1) の間の修正を
ソースファイルごとに抽出し，全てデータベースに登録する．その後，データベース中の包含修正を解消する．リビ

タスクに関する修正 A が過去に行われ，コミットされていジョン間で行われた修正を構成する 1 つ以上の小さな修正たとする．このとき，修正 A と，そのタスクに含まれないのことを本論文では微小修正と呼ぶこととする．

他の修正を同時に行うコミットはもつれた修正を行っている可能性が高い．
図 2 は手法の軸となる考え方を示すものである．開発者

図 4 は連続する 2 つのリビジョン間から微小修正を抽出する過程を表したものである．図 4 の例では，連続する 2
つのリビジョン間から 3 つの微小修正が抽出されている．

がバグ修正として「null チェックの追加」を含むコミット

この手順は次の 5 つのステップで構成されている．

を行おうとしているとする．また，過去に「null チェック

STEP 1-1: リビジョン r から r + 1(1 ≤ r ≤ n − 1) の間の追加」という修正のみが行われたコミットが行われていで修正があったソースファイルを構文解析し，ソースたとする．もしそのコミットがもつれた修正を行っていな

コード中の文を検出する．

いならば，「null チェックの追加」という修正は 1 つのタス

STEP 1-2: 修正前後の 2 つのソースファイルをそれぞクであると考えられる．ここで，行おうとしているコミッ

れ文の列とみなして比較し，最長共通部分列を特定しトが「null チェックの追加」とバグ修正ではないその他のた後，それを用いて微小修正を抽出する．

修正を行っているとする．この場合，「null チェックの追STEP 1-3: 変数名と定数リテラルを特殊文字に置換す

加」を含むコミットは「null チェックの追加」を行うコミッる．この際，同じ識別子は同じ特殊文字に置換し，異トと，それ以外の修正を行うコミットに分割すべきであるなる識別子は異なる特殊文字に置換する．クラス名やと思われる．したがって，過去の修正を含むようなコミッ

メソッド名などのその他のユーザ定義名は置換しない.

トはもつれた修正である可能性が高いと考えられる．この正規化を行うことで，修正を比較する際に変数名のみ

ような過去の修正を含むような修正を本論文では包含修正が異なる文を同じ文として扱うことができる．なお，と呼ぶこととする．

修正の比較は，修正された文の文字列を比較すること

3. 提案手法
この章では，提案手法の具体的な手順を説明する．

c 2014 Information Processing Society of Japan⃝

で行う．

STEP 1-4: ここまでの操作で得られたファイルごとの修正をデータベースに登録する．

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

入力：リポジトリ

𝑃1

𝑃2（1）修正履歴情報の抽出（2） コミットの
入力：コミット
分割候補の提示
コミットの分割候補の提示

𝑃𝑛

𝑃𝑛−1

修正の集合

もつれた変更を解消

出力：
もつれた変更が解消されたデータベース

データベース

出力：コミットの分割候補

図 3 提案手法の概要

int x = 10;
int y = 20;
if (x == 10) {y = x + y;}print(x);print(“end”);

int x = 10;
int y = 20;
int z = 30;
if (x == 10) {y = x - y;}print(x);STEP1-1

STEP1-1

int x = 10 ;int x = 10 ;int y = 20 ;int y = 20 ;if ( x == 10 )int z = 30 ;y = x + y ;if ( x == 10 )print ( x ) ;y = x - y ;print ( “end” ) ;print ( x ) ;データベース
修正前リビジョン番号, ファイルパス, 行われた修正
8, XXX.java, 修正P1+修正P2
13, YYY.java, 修正P3+修正P4
13, ZZZ.java, 修正P3+修正P5+修正P6
19, YYY.java, 修正P2

図 5 データベースのイメージ再登録する．STEP1-5 の詳細については，本章の最後で説明する．STEP1-1 から STEP1-5 までが行われた

STEP1-2

STEP1-2

後のデータベースのイメージを図 5 に示す．

3.2.1 最長共通部分列を用いた微小修正の抽出
STEP1-2 の最長共通部分列を用いた微小修正の抽出について説明する．最長共通部分列とは，2 つの系列の部分列のint x = 10 ;int x = 10 ;int y = 20 ;int y = 20 ;(B,F,C,E,G) という 2 つの系列の最長共通部分列は (B,C,E)

int z = 30 ;である．

if ( x == 10 )y = x + y ;print ( x ) ;print ( “end” ) ;if ( x == 10 )うちで最長のもののことである．例えば，(A,B,C,D,E) と提案手法では，修正前後のソースコードをそれぞれ文の列とみなして最長共通部分列をとっている．最長共通部分

y = x - y ;列の要素である文を修正されなかった文とみなし，要素でprint ( x ) ;ない文を修正された文とみなす．例えば，以下のような文の並び X,Y があるとする．

修正の集合

STEP1-3

STEP1-3

X = (A, B, C, D, E, F, G)
int $1 = 30 ;
$1 = $2 + $1 ;

Y = (A, P, C, Q, R, D, E, G)$1 = $2 - $1 ;もし，X が修正前，Y が修正後であるならば，下記の 3 つprint ( “end” ) ;の微小修正が抽出される．
3つの修正

図 4

2 つのリビジョン間の修正の抽出

STEP 1-5: データベース中の包含修正を検知し，そのような修正を複数の修正に分割した上でデータベースに

c 2014 Information Processing Society of Japan⃝• B からの P への変更
• Q と R の追加• F の削除
図 6 はその様子を表したものである．微小修正は，それぞれ変更・追加・削除のいずれかにあてはまる．

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

Algorithm 1 包含修正の解消

最長共通部分列

A C D E G

X A B C __ D E F G
追加

変更

削除

Y A P C Q R D E __ G
図 6

最長共通部分列を用いた修正の検出

3.2.2 データベース中の包含修正の解消
STEP1-5 のデータベース中の包含修正を解消する処理について説明する．包含修正を，複数の修正に分割するこ

Input: データベース
Output: 包含修正を解消したデータベース
LABEL: START
データベース中の修正を微小修正の数について昇順でソート
for i = 0 to n do
Q ← DB[i]for j = i + 1 to n do
P ← DB[j]if Q ⊂ P then
Algorithm2：同じ変数に関する修正を 1 つにまとめる (入力：P, Q，出力：Q′ )if P − Q′ ̸= ϕ then
データベースから P を取り除き，Q′ , P − Q′ を追加
する
end ifgoto START
end ifend forend forとで，包含修正を解消する．修正 P と Q がデータベース
中にあるとする．P と Q の要素数はそれぞれ a,b とする．

Algorithm 2 同じ変数に関する微小修正を 1 つにまと

mx ,ny を微小修正とすると，以下のように表せる．

める

P = {mx | 1 ≤ x ≤ a}
Q = {ny | 1 ≤ y ≤ b}
このとき，Q ⊂ P ならば P は包含修正であるとみなす．
微小修正の比較は STEP1-3 で正規化された後の文字列を比較することで行う．
データベース中の包含修正を解消するアルゴリズムを

Algorithm1 に示す．ここではデータベース中の修正の数を n としている．まず，P を修正 Q と P − Q に分割する．

Input: 修正 P, Q(Q ⊂ P )Output: 修正 Q′ (Q′ ⊂ P )Q′ ← QLABEL: STARTvQ′ ← Q′ 中の修正に関わる変数の集合
for all m ∈ P dovm ← 修正 m に関わる変数の集合
if vQ′ ∩ vm ̸= ϕ thenm を Q′ に追加する
goto START
end ifend for

次に，同じ変数が関わる文の修正が 1 つの集合にまとまるように P − Q から Q に微小修正を移動する．なぜなら，同れるような修正がデータベース中に存在しないかを探す．

じ変数が関わる文の修正は同じタスクである可能性が高い

そのような修正がなければ，開発者がもつれのない修正をと考えられるためである．また，同じ変数が関わる文の修しているとみなし，開発者はそのままコミットする．その正をまとめない場合，修正を適用する際コンパイルエラー

ような修正があれば，開発者がもつれた修正を行っているが発生する場合がある．例えば，Q で変数 x の宣言文が削可能性が高いとみなし，コミットの分割候補を提示する．

除される修正が行われており，P − Q で x の値を出力する

開発者はコミットの分割候補を見て，それに従うかどうか文が削除される修正が行われていたとする．このとき，もを決める．アルゴリズムを Algorithm3 に示す．

しも Q の修正を P − Q よりも先に適用した場合，コンパ
イルエラーが発生する．

この手順は下記の 3 つのステップで構成されている．開発者が包含修正をコミットした場合の手順の詳細を図 7 の同じ変数が関わる文の修正を 1 つにまとめるアルゴリズ

例を用いながら説明する．図 7 では説明のため，正規化を

ムを Algorithm2 に示している．Algorithm2 では，P が Q行う前の文を表示している．

と P − Q に分割された時に，同じ変数が関わる文の修正

STEP2-1: 開発者が行おうとしているコミットから抽出が 1 つにまとまるように微小修正を Q に追加している．こした，あるファイルの修正を P とする．ここで，デー

′

′

′

こで新たにできた Q を用いて，P を Q と P − Q に分割

タベース中に Q ⊂ P となるような修正 Q が存在する

する．

場合，P は包含修正である．図 7 の例では，Q で行われた微小修正が全て P でも行われているため，P は包3.3 コミットの分割候補の提示

含修正である．

3.2 節の STEP1-2，STEP1-3 と同様に開発者が行おうと

STEP2-2: 修正 P を Q と P − Q に分割する．次に，Al-しているコミットから修正を抽出し，抽出した修正に含ま

gorithm2 を用いて，同じ変数が関わる文の修正が 1 つ

c 2014 Information Processing Society of Japan⃝

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

Algorithm 3 コミットの分割候補の提示

STEP2-1
開発者が行おうとしている
コミットで行われた修正（集合P）x = x + 2; → x = x + 1;

修正履歴（集合Q）y = y + 1; → _______

y = y + 1; → _______

print(x);データベース_______ → print(y);→ ______________ → print(y);修正履歴_______ → y = z;

修正履歴

STEP2-2

P－Q

Q

x=x+2

→ x = x + 1;_______ → print(y);print(x);→ _______

y=y+1→ ______________ → y = z;

P － Q´Q´x=x+2→ x = x + 1;_______ → print(y);print(x);→ _______

y=y+1→ _______

Input: 修正 P
Output: コミットの分割候補
LABEL: START
for i = 0 to n do
Q ← DB[i]if Q ⊂ P then
Algorithm2：同じ変数に関する修正を 1 つにまとめる (入力：P, Q，出力：Q′ )最新リビジョンに修正 Q′ を適用したものを分割候補として
提示
if 開発者が分割候補に従う then
他のファイルで行われている修正がある場合，任意に Q′に追加する
最新リビジョンに Q′ を適用してコミット
P ← P − Q′goto START
end ifend ifend for_______ → y = z;

す項目について調査を行った．実験対象のソフトウェアの
STEP2-3Q´_______ → print(y);y=y+1→ _______

P － Q´順に適用

x=x+2→ x = x + 1;

print(x);→ ______________ → y = z;

図 7 包含修正を分割する手順の具体例

情報を表 1 に示す．
調査項目 1:

包含修正がもつれた修正である割合の調査.

調査項目 2:

データベースの規模と検出される包含修正の数および分割精度の変化の調査．
調査項目 3:

データベース作成に用いたソフトウェアと，包含修正を検出するソフトウェアが異なる場合の，検の集合にまとまるように P − Q から Q に微小修正を移動する．これにより微小修正が追加された Q を新たに Q′ とする．図 7 では，Q と P − Q 共に変数 y が出現する文の微小修正を要素に持っているので，変数 yが出現する文の微小修正を P − Q から Q に移動する．

Q に微小修正が追加されたものを Q′ とする．
STEP2-3: 最新リビジョンに Q′ を適用したものを分割候補として提示し，開発者はそれに従うかどうかを決定する．分割候補に従う場合，最新リビジョンに Q′ を適用したものをコミットする．次に P − Q′ を新たなP として，STEP2-1 から同様に処理を行う．P − Q′が包含修正でない場合は，Q′ を適用した後のリビジョ
ンに P − Q′ を適用して終了する．これを繰り返し行
うことで，開発者が行おうとしているコミットが複数のコミットに分割される．図 7 は，P − Q′ が包含修正でなかった場合の例である．
開発者が一度に複数のファイルに修正を行ってコミットする場合がある．複数のファイルが一度のコミットで修正されている場合は，個別に同様の処理を行い，ファイルごとの分割された修正を組み合わせてコミットを行えるよう
にする．

4. 実験
提案手法の有用性を確認するため，本研究では以下に示

c 2014 Information Processing Society of Japan⃝

出される包含修正の数および分割候補の精度の調査．

4.1 調査の目的
各調査項目について，調査の目的を述べる．
調査項目 1:

提案手法では，検出された包含修正をもつれた修正の候補としている．どのような場合に包含修正がもつれた修正であるのかを調べる．
調査項目 2:

提案手法は，リポジトリに蓄積されている修正履歴情報の数が多ければ多いほど，包含修正の検出数が増加することが予想される．検出数の増加はどの程度であるのか，検出数が増加することによって分割精度がどう変わるのかについて調べることで，実用の際に必要なデータベースの規模を知る．
調査項目 3:

提案手法は，リポジトリにある程度データが蓄積されていることを前提としている．そのため，開発を開始して間もないプロジェクトでは手法を利用することができないという問題がある．そのような場合に，他のプロジェクトのリポジトリから作成したデー
タベースを代わりに利用できればそのような問題を軽
表 1

実験対象ソフトウェア
JEdit ArgoUML

コードの行数

299,530

164,851

リビジョン数

23,395

19,915

開発期間（月）204180

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)減できる．この時の検出数と分割候補の精度を調べる
ことで，他のプロジェクトのリポジトリから作成した
データベースで代用可能かどうかを判断する．

4.2 調査項目 1
調査項目 1 について，調査方法と結果について述べる．
調査対象にはオープンソースソフトウェアの ArgoUML を用いた．
まず，リポジトリのリビジョン 1 から 5,000 までを用
いてデータベースを作成した．次に，リビジョン r から

r + 1(5001 ≤ r < 6000) に対応するコミットに対し提案手法を用いたところ，41 のコミットで包含修正が行われているとみなされた．
提案手法では，開発者が行おうとしているコミットがある修正 A を含んでおり，その修正 A がデータベース中に存在する場合に，開発者が行おうとしているコミットを修正 A とその他の修正に分割したものを候補をとして提示する．それぞれについて提示された分割候補が適切であるかどうかを目視で評価した．分割候補を以下の 3 種類に分類

47……

public class UMLClassifierComboBoxModel extends UMLComboBoxModel

{

55 +
56 +
57
58
……

private static final Logger LOG =Logger.getLogger(UMLClassifierComboBoxModel.class);

115
116
117
118
119
120
121 +
+
+
122
123
124 +
+
+
……

while (iter.hasNext()) {before = currentStr;
currentEntry = afterEntry;
currentStr = after;
afterEntry = (UMLComboBoxEntry) iter.next();
after = afterEntry.getShortName();if (currentEntry != null)currentEntry.checkCollision(before,after);if (currentEntry != null) {currentEntry.checkCollision(before, after);}
フォーマットの変更
}

185
186 +
+
+
+
187
188
189
190 +
191
192
193 }

catch (InvocationTargetException ex) {cat.error(ex.getTargetException()+ " is IncovationTargetException in
UMLClassifierComboBoxModel“, ex);
LOG.error(ex.getTargetException()+ " is IncovationTargetException "+ "in UMLClassifierComboBoxModel", ex);
setSelectedItem(null);
LOGを使用する変更}
catch (Exception e) {cat.error("Exception in targetchanged", e);
Log.error("Exception in targetchanged", e);
setSelectedItem(null);}

定数LOGの宣言

if (afterEntry != null) afterEntry.checkCollision(currentStr, null);if (afterEntry != null) {afterEntry.checkCollision(currentStr, null);}

する．

True 修正 A が，その他の修正と関係のない単一のタス

図 8 もつれた修正であるとみなされた例

クである

False 単一のタスクであるものが分割されている
Unclear 上記の 2 つに当てはまるかどうかを判断できない
修正 A が単一のタスクであるかどうかは，コミットログや修正に関わっている変数・メソッドから判断した．分割
された修正の行数がわずかである場合は，修正の内容を理提案手法が適切に分割候補を提示できた例を図 8 に示す．図 8 では，以下の修正が行われている．

• 定数 LOG の宣言の追加• ロギングに LOG を使用するようにする変更• if 文のフォーマットの変更提案手法によってこのコミットは以下の 2 つに分割さ解しやすいため判断が容易であるが，そうでない場合は，れた．

単一のタスクであるかを判断できない場合が多かった．

( 1 ) 定数 LOG の宣言の追加と，ロギングに LOG を使用

分割候補の分類は，修正 A の種類ごとに排他的に行った．分類について，以下の様な基準で行った．

するようにする変更( 2 ) if 文のフォーマットの変更• ロギング・・・ロギング用のライブラリを用いてログをとる処理を行っている• メソッド宣言・呼び出し・・・メソッド宣言文，又は表 2 分割された修正の種類と分類
修正の種類
T
U
F

合計

メソッド名変更

3

0

1

4

メソッド宣言・呼び出し

0

1

3

4

ロギング

3

0

0

3

排他制御

• 排他制御・・・synchronized 修飾子が追加されている

1

0

0

1

引数の変更

6

2

0

8

• 継承・インターフェース・・・extends 又は implements

変数名の変更1001

変数・定数宣言

2

1

1

4

文字列リテラルの変更

3

0

0

3

クラス名の変更

0

0

1

1

継承・インターフェース

0

1

0

1

メソッド呼び出し文が追加・削除されている• 引数の変更・・・引数の変数名や引数の個数が変更されている

修飾子が追加されている調査の結果は表 2 のようになった．表 2 から，包含修正の約半数がもつれた修正であることと，修正の種類によって，適切に分割しやすいものとそうでないものがあること

break 文の追加・削除

0

0

2

2

が分かる．適切に分割されやすいものは，ロギング，引数

try 文の追加・削除

0

3

0

3

の変更，文字列リテラルの変更などであった．また，適切

分類不可

0

4

0

4

に分割されにくいものは，メソッド宣言・呼び出しの変更，

合計

19

13

8

41

break 文の追加・削除などであった．

c 2014 Information Processing Society of Japan⃝T : True, U : Unclear, F : False

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

80

160

60

120

40

80

20

40

0

0
0

2000

4000

6000

JEditからDBを作成

図 9

8000

10000

0

ArgoUMLからDBを作成

調査項目 3：データベースの規模と検出数 (JEdit)

2000

4000

ArgoUMLからDBを作成
図 10

6000

8000

10000

JEditからDBを作成

調査項目 3：データベースの規模と検出数 (ArgoUML)

この 2 つの修正は互いに関係がなく，別々にコミットさ( 1 ) 調査対象となる 2 つのソフトウェアについて，リビれるべきであると考えられる．また，定数 LOG の宣言の

ジョン 1 から n (n=500, 1000, 2000, 4000, 6000, 8000,

追加とロギングに LOG を使用するようにする変更は別々

10000) までを用いてデータベースをそれぞれ作成する．

にコミットするべきではないと思われる．なぜなら，定数( 2 ) 作成したそれぞれのデータベースを用いて，JEdit のの宣言とその定数の使用は単一のタスクであると考えられ，リビジョン r から r + 1 (10001 ≤ r < 11000) に対応

また，コミットを行う順番によってはコンパイルエラーがするコミットに対して提案手法を用いる．

発生するためである．

( 3 ) 包含修正が行われているとみなされたコミットの数を数える．

4.3 調査項目 2

その結果をグラフにしたものが図 9 である．

調査項目 2 について，調査方法と結果について述べる．

同じく，ArgoUML のリビジョン r から r + 1 (10001 ≤調査対象にはオープンソースソフトウェアの ArgoUML を

r < 11000) に対応するコミットに対し提案手法を用い，そ用いた．この調査の手順を以下に示す．

の結果包含修正であるとみなされたコミットの数をグラフ( 1 ) リビジョン 1 から n (n=500, 1000, 2500, 5000) までにしたものが図 10 である．

を用いてデータベースをそれぞれ作成する．

図 9,10 について，縦軸は包含修正の数，横軸はデータベー( 2 ) 作成したそれぞれのデータベースを用いて，リビジョ

ス作成に用いたリビジョン数である．JEdit と ArgoUML

ン r から r + 1 (5001 ≤ r < 6000) に対応するコミッ

双方 4,000 リビジョン以下の規模のデータベースではも包トで包含修正を検出する．

含修正の数の差が小さいが，それより上の規模では，特に( 3 ) 提示された分割候補を，4.2 章で定義した True ,ArgoUML で差がでていることが分かった．
次に，データベースの元となるソフトウェアと包含修正

Unclear に分類する．

False ,

その結果を表にしたものが表 3 である．データベースの規模に関わらず，True，Unclear，False の順で多かった．

を検出するソフトウェアが異なる場合の分割候補の精度について調べた．

1,000 リビジョン以上の規模で分割候補が True であった

JEdit のリビジョン 1 から 5,000 を用いてデータベース

ものの割合は，37.5%–53.8%の間であった．また，True とを作成し，ArgoUML のリビジョン r から r + 1 (5001 ≤Unclear を合わせた割合は，75.0%–92.3%の間であった．

r < 6000) に対応するコミットが，包含修正である時に提4.4 調査項目 3

したところ，それぞれの割合は 58%, 21%, 21%であった．

示された分割候補を True , Unclear , False に分類
調査項目 3 について，調査方法と結果について述べ

また，JEdit のリビジョン 1 から 5,000 を用いてデーる．調査対象にはオープンソースソフトウェアの JEdit とタベースを作成し，ArgoUML のリビジョン r から r + 1

ArgoUML を用いた．

(5, 001 ≤ r < 6, 000) に対応するコミットが，包含修正と

まず，包含修正が行われているとみなされたコミットのみなされた時に提示された時の分割候補を True , Un-

clear , False に分類したところ，それぞれの割合は 50%,

数について調べた．その手順を以下に示す．

44%, 6%であった．

5. 議論

表 3 調査項目 2：データベースの規模とコミットの分割候補の精度
リビジョン

True

Unclear

False

合計

1–500

6(75.0%)1(12.5%)1(12.5%)8

1–1,000

7(53.8%)5(38.5%)1(7.7%)

13

1–2,500

9(37.5%)9(37.5%)6(25.0%)24

1–5,000

19(41.3%)

18(39.1%)

9(19.6%)26

c 2014 Information Processing Society of Japan
⃝

各調査項目の結果に対する考察を述べる．

5.1 調査項目 1 の結果に対する考察
適切に分割されやすい修正の 1 つとして，ロギング処理

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)の追加があった．ロギング処理は専用のライブラリやクラ5.3 調査項目 3 の結果に対する考察

スを用いて行うため，決まった命令が用いられることが多

図 9,10 共に，4,000 リビジョン以下の規模のデータベー

い．従って，データベース中にロギング処理の追加を行っ

スでは検出数自体が少ないため，4,000 リビジョンより大た修正履歴があれば，その後同様の処理を行った時に検出きな規模のデータベースを用いた場合の結果について議論されやすい．

を行う．JEdit のリポジトリでの包含修正の検出数につい

次に，適切に分割できなかった修正について説明する．

て，同じソフトウェアからデータベースを作成した場合の適切に分割されない原因の 1 つとして，import 文の存在

検出数に対して，ArgoUML からデータベースを作成したがある．import 文を追加することによって使用可能にな場合の検出数は平均 31.2%減少している．

るメソッドがあるが，import 文の追加と対応するメソッ

一方，ArgoUML のリポジトリでの包含修正の検出数にド呼び出しの追加が別のコミットに分かれる案を提示してついて，同じソフトウェアからデータベースを作成した場しまうことがあった．import 文の追加と，対応するメソッ合の検出数に対して，JEdit からデータベースを作成した

ドの呼び出しの追加は同じコミットで行うべきである．同場合の検出数は平均 80.0%減少している．

様に，継承・インターフェースの修正についても，それにこの結果から，使用するソフトウェアによって，検出数

よって使用可能なメソッドが変わる場合があり，継承・イが大きく減る場合とそうでない場合があることが分かっ

ンターフェースの修正と対応するメソッド呼び出しが別のた．手法の性質上，あるソフトウェア A 中の包含修正を，コミットに分かれてしまうことがあった．

他のソフトウェア B から作成したデータベースを用いて検この問題を解決する方法として，クラスやインターフェー

出する場合，ソフトウェア A 特有の修正は検出することがスとそれらが持っているメソッドの対応関係を用いることできない．ArgoUML は JEdit と比べて，そのソフトウェが考えられる．例えば，import 文の追加によって新たに使ア特有の修正が多かったため，結果に差が出たと考えられ用可能になるメソッドを記憶しておくことで，そのようなる．その他の原因として，ArgoUML で多くのソースファ

メソッドの呼び出しが同時に追加されている時，import 文

イルに対して同様の包含修正が行われた事が考えられる．

の追加とメソッド呼び出しの追加が別々のコミットに分か同様の包含修正が複数ある場合，それらの修正が検出されれないようにすることができる．

るかどうかで検出数に大きく差が出てしまうため，このよ

適切に分割されない他の原因として，break 文の追加のうな結果になったと考えられる．

みが行われるなどの，粒度の小さすぎる修正の存在があっ

また，データベースの元となるソフトウェアと包含修正た．このようなコミットがあると，break 文の追加を含むを検出するソフトウェアが異なる場合，検出数は減少する

ようなコミットが全て包含修正となってしまう．しかし，が，分割候補の精度は変わらないことが分かった．従って，

実際は break 文の追加を含むコミットがもつれた修正でな

開発プロジェクトが始まって間もない時期に十分な規模のい場合も多く，そのような場合に誤検出が発生する．

データベースが作成できない場合，検出数は減るものの，この問題を解決する方法として，break 文の追加など，
単一のタスクとしては粒度が小さすぎる修正については個別に除外するという経験則を用いる方法が考えられる．

他のソフトウェアから作成したデータベースで代用することが可能であると考えられる．
また，他のソフトウェアからデータベースを作成する際，包含修正を検出するソフトウェアとより近いソフトウェア

5.2 調査項目 2 の結果に対する考察を用いたほうがより多くの包含修正を検出しやすいと考え

1,000 リビジョン以上の規模でデータベースを作成した

られる．従って，同じ機能を持っていたり，同じライブラ

場合，検出数が増加しても分割候補の精度が大きく変化すリを使用しているソフトウェアからデータベースを作成す

ることはなかった．データベースの規模が大きければ大きべきである．

いほど，検出数が増加するため，より検出漏れを減らすことができる．分割候補の精度はデータベースの規模によらないため，実用の際はなるべく大きな規模のデータベースを用いるべきである．

6. 妥当性への脅威
本研究の実験では，対象としたオープンソースソフト
ウェアは 2 つで，さらに限られたリビジョンに対し手法

10,000 リビジョンの規模のデータベースを用いた場合でを適用した．よって，他のリビジョンまたは，他のソフトも，包含修正を検出するのにかかる時間は 1 コミットあた

ウェアを実験対象とすることで包含修正の検出数や分割候

り 0.2 秒程度であった．検出時間はデータベース中の修正

補の精度が変わる恐れがある．さらに多くのソフトウェア

履歴の数を n とし，O(n) であるので，規模の大きなデーに対し実験を行うことで，より一般的な結果を得られるとタベースを用いた時の実行時間についての問題はないと考考えられる．

えられる．

また，実験では，提案手法によって提示された分割候補が適切かどうかの分類は著者らが目視で行っている．分割

c 2014 Information Processing Society of Japan⃝

ソフトウェアエンジニアリングシンポジウム 2014
IPSJ/SIGSE Software Engineering Symposium (SES2014)

候補の分類は判断基準を設定して行ったが，主観による部[6]分を完全に取り除くことはできないため，人によって評価結果が変わる恐れがある．従って，複数の被験者を用意したり，実際にコミットした開発者に実験を行ってもらうこ[7]とでより客観的に判定できると思われる．

7. おわりに[8]

本論文では，開発者がもつれた修正を行うことを防ぐ手段として，包含修正がコミットされた場合にそれを検知す[9]る手法を提案した．この手法は，包含修正がもつれた修正である可能性が高いという考えに基づいている．提案手法
を用いることで，開発者はもつれた修正をコミットする前にそのことに気づくことができる上，提示された分割候補[10]に従ってコミットすることでもつれた修正を減らすことが
できる．

[11]

著者らは，JEdit と ArgoUML という２種類のオープン
ソースソフトウェアに対し，提案手法の有用性を評価する実験を行った．実験の結果，修正の種類によって適切に分割しやすいものとそうでないものがあることが分かった．

[12]

また，包含修正を検知するソフトウェアとは別のソフト
ウェアから作成したデータベースを用いた場合も，提案手[13]法を利用できることが分かった．今後，今回適切に分割できなかった種類の修正について適切に分割できるような経験則を導入し，手法を改善する予定である．

[14]

また，本研究では提案手法を実装したプロトタイプを用いて実験を行ったが，提案手法を Eclipse のプラグインとして実装し，実用可能なツールを作成する予定である．
謝辞

[15]

本論文は，日本学術振興会科学研究費補助金基盤

研究 (S)(課題番号：25220003)，挑戦的萌芽研究 (課題番号：24650011)，及び文部科学省科学研究費補助金若手研究 (A)(課題番号：24680002) の支援を受けて行われた．

[16]

参考文献
[1]

[2]

[3]

[4]

[5]

Askari, M. and Holt, R.: Information Theoretic Evaluation of Change Prediction Models for Large-scale Software, Proceedings of the 2006 International Workshop
on Mining Software Repositories, pp. 126–132 (2006).
Boogerd, C. and Moonen, L.: Evaluating the relation
between coding standard violations and faultswithin andacross software versions, Mining Software Repositories,
2009. MSR ’09. 6th IEEE International Working Conference on, pp. 41–50 (2009).
Canfora, G., Cerulo, L. and Penta, M. D.: Identifying
Changed Source Code Lines from Version Repositories,
Proceedings of the Fourth International Workshop on
Mining Software Repositories, pp. 14– (2007).
Giger, E., Pinzger, M. and Gall, H.: Can we predicttypes of code changes? An empirical analysis, Mining
Software Repositories (MSR), 2012 9th IEEE Working
Conference on, pp. 217–226 (2012).
Hassan, A.: The road ahead for Mining Software Repositories, Frontiers of Software Maintenance, 2008. FoSM
2008., pp. 48–57 (2008).

c 2014 Information Processing Society of Japan
⃝

[17]

[18]

[19]

[20]

[21]

Hata, H., Mizuno, O. and Kikuno, T.: Bug Prediction
Based on Fine-grained Module Histories, Proceedings ofthe 34th International Conference on Software Engineering, pp. 200–210 (2012).
Herzig, K. and Zeller, A.: The Impact of Tangled CodeChanges, Proc. of the 10th International Workshop on
Mining Software Repositories, pp. 121–130 (2013).
Higo, Y., Hotta, K. and Kusumoto, S.: Enhancementof CRD-based Clone Tracking, Proceedings of the 2013
International Workshop on Principles of Software Evolution, pp. 28–37 (2013).
Hindle, A., German, D. M. and Holt, R.: What Do Large
Commits Tell Us?: A Taxonomical Study of Large Commits, Proceedings of the 2008 International Working
Conference on Mining Software Repositories, pp. 99–
108 (2008).
H.Kagdi, H., Maletic, J. I. and Sharif, B.: Mining
Software Repositories for Traceability Links, Proc. of
ICPC2007, pp. 145–154 (2007).
Kamei, Y., Matsumoto, S., Monden, A., Matsumoto,K.-i., Adams, B. and Hassan, A. E.: Revisiting Common Bug Prediction Findings Using Eﬀort-aware Models, Proceedings of the 2010 IEEE International Conference on Software Maintenance, pp. 1–10 (2010).
KDE TechBase: Commit Policy, (online), available from⟨https://techbase.kde.org/Policies/Commit Policy⟩ (accessed 2014-07-23).
Kirinuki, H., Higo, Y., Hotta, K. and Kusumoto, S.:
Hey! Are You Committing Tangled Changes?, Proceedings of the 22Nd International Conference on Program
Comprehension, pp. 262–265 (2014).
Kusunoki, N., Hotta, K., Higo, Y. and Kusumoto,S.: How Much Do Code Repositories Include Peripheral Modifications?, Proceedings of the 2013 20th AsiaPacific Software Engineering Conference (APSEC), pp.
19–24 (2013).
Moser, R., Pedrycz, W. and Succi, G.: A Comparative
Analysis of the Eﬃciency of Change Metrics and Static
Code Attributes for Defect Prediction, Proceedings ofthe 30th International Conference on Software Engineering, pp. 181–190 (2008).
Murphy-Hill, E., Parnin, C. and Black, A. P.: How We
Refactor, and How We Know It, Proceedings of the 31st
International Conference on Software Engineering, pp.
287–297 (2009).
Rahman, F., Bird, C. and Devanbu, P.: Clones: What is
That Smell?, Empirical Softw. Engg., Vol. 17, No. 4-5,
pp. 503–530 (2012).
Ying, A. T. T., Murphy, G. C., Ng, R. and ChuCarroll, M. C.: Predicting Source Code Changes by Mining Change History, IEEE Trans. Softw. Eng., Vol. 30,
No. 9, pp. 574–586 (2004).
Zhang, H.: An investigation of the relationships betweenlines of code and defects, Software Maintenance, 2009.
ICSM 2009. IEEE International Conference on, pp.
274–283 (2009).
Zimmermann, T., Weisgerber, P., Diehl, S. and Zeller,
A.: Mining Version Histories to Guide Software Changes,
Proceedings of the 26th International Conference on
Software Engineering, pp. 563–572 (2004).
肥後芳樹，楠本真二：コード修正履歴情報を用いた修正漏れの自動検出，情報処理学会論文誌，Vol. 54, No. 5, pp.
1686–1696 (2013).