オープンソースソフトウェアにおけるバグ混入コミットのトピック分析
椋代 凜

水野 修

京都工芸繊維大学 大学院工芸科学研究科 情報工学専攻

京都工芸繊維大学 大学院工芸科学研究科 情報工学部門

r-mukudai@se.is.kit.ac.jp

o-mizuno@kit.ac.jp

要旨

キスト分類手法を適用する研究が進んでいる [4, 8]．
自然言語テキストを分類する統計的手法としてトピッ

本研究では, バージョン管理システムにおいて開発者クモデルがある. これは文章をそれを構成する単語の集がバグを出したコミット（以下, バグ混入コミット）に合体と見なし, それらの単語は独立に出現するのではな

より変更されたソースコードに対してトピック分析をかく単語が潜在的に持つトピック（話題）に従って出現すけることにより, 特定の開発者のバグ傾向を分析する. 将るとするものである. トピック分析をすることで, 文章の来的には, 抽出されたバグ傾向を開発者本人に提示する

詳細を確認せずともその文章が持つ話題を知ることが可ことで, バグの改善に役立てることを目指す.

能になる.

一般的に, 開発者はプログラム理解のためにソースコー

本研究では, 自然言語テキストではなくプログラムのドの識別子にプログラムの内容や機能に関するキーワー

ソースコードを対象としてトピック分析を行い，開発者ドを埋め込むため, ソースコードから識別子を取り出しがバグを混入したコミットにおいて、どのようなトピッ

それらにトピック分析を適用すれば, プログラムに潜在クを扱っていたのか，そしてそれはバグを混入しなかっするトピックが推定可能である. 本研究では, これの対象た場合と比べて差異があるのかを分析する.

をバグ混入コミットで変更されたソースコードに限定すソースコード中で用いられる関数名や変数名といったる. 適用実験には, GitHub で公開されている Java ネット

識別子は, それらを構成する単語を理解することでそのワークアプリケーションフレームワーク「Apache MINA」

プログラムの意味や機能を知ることが可能であり, コメを用いる. 実験の結果, 開発者によって程度の差はあるもント文と同様にソースコードを理解する重要な情報源でのの, 特定のプログラムの機能に属するトピックをバグある. 一般的に, 開発者が識別子の命名に用いるキーワー混入コミットから抽出することが出来た. また，開発者

ドはそのプログラムの機能に関する単語であることから,個人のバグ混入コミットとバグ非混入コミットから抽出

同じ機能を持ったモジュールに用いられる識別子は一つされたトピックの違いを分析することで，その開発者がの文脈のように同じまとまりを持っていると考えられる.

バグを混入する状況の分析が可能となった．

本研究では, このまとまりを一つのトピックとして捉える. そして，特定の開発者が書いたコード群をいくつか

1 はじめにソフトウェア開発において，バグが混入する時点や状況を分析することは，以降のバグを未然に防ぐために有効な手段である．特に，ソフトウェア開発者が頻繁にバグを発生させてしまう状況を知ることは，開発者の啓発にもつながるため，開発者の行動に焦点を当てた研究が必要とされている．開発者の開発行動の成果としてはソースコードやコミットメッセージなどが利用でき，テのトピックに分類し, 特にその開発者が不具合を多く出すトピックを特定する.
まず, バージョン管理システムである Git を用いて, 適
当なオープンソースソフトウェアのリポジトリを取得し,バグ混入コミットによって変更されたファイルだけをそれらのコミットの Author 毎に取り出す. そして, それぞれのファイルから識別子を抽出し, それら識別子にトピッ
ク分析を適用する. 先行研究によって，ソースコードの情報からそのソフトウェアに関するトピック情報が抽出Git
Repository

Stopwords

Source code
A.javaA.ja
A.ja
vaA.ja
va
va

A.ja
A.ja
vaB.ja
va
va

BUG

FIXED

Extract
identifiers

Identifiers

Removestopwords

Identifier
Identifier
Identifier

Extract
topics

Topics
Topic
Topic
Topic

図 1: トピック分析の流れできることが知られている [2, 8]. 本研究では, 対象のソフトウェア全体が持つトピックも抽出し, それらと各開発者の持つトピックとの関係についても考察する. ト
ピック分析は統計計算ソフト R のパッケージに含まれる LDA(Latent Dirichlet allocation) を用いて行う. 一般的に, トピック分析は自然言語テキストを対象とするため,ソースコードを対象とする場合は通常とは異なるストップワードを用いる必要がある. また LDA はトピックの推定は行えるが, 予めトピック数をユーザ側で入力する必要があるため, その推定も別途行った．
オープンソースプロジェクトを利用した適用実験の結果，トピック分析によってバグ混入時と非混入時において，トピックに違いがあること，また各開発者に限定して調べた場合でも，同様に違いがあることを確認した．
本論文の以降の構成を述べる．2 節では，研究に当たって設定した質問を挙げ，問題を明確にする．3 節では，トピック分析の手法について概要を述べる．4 節ではトピック分析を Apache MINA プロジェクトに適用した実験について述べる．5 節ではまとめと今後の課題を述べる．

2 研究設問本研究では以下の 3 つの研究設問を設定し，これらについて調べる．

RQ1: プロジェクトにおけるバグ混入コミットとバグ非混入コミットの間でトピックの種類に差はあるか．

間でトピックの種類に差はあるか．

RQ1 はプロジェクトにおけるコミット作業のうち，バグが混入したものとそうでないものとの間で，トピック情報が異なるかを調べるものである．差があるとすれば，トピック分析によってバグの混入しやすいソースコード特定が可能になる．

RQ2 は開発者個人毎にトピックを抽出し，その傾向の違いを特定することで，個人が得意とする分野を分析する．

RQ3 は開発者個人毎のバグ混入コミットの傾向を分析し，バグが混入したものとそうでないものとの間で，トピック情報が異なるかを調べるものである．ここで差を発見できれば，個人がバグを作り込みやすい場面を特定し，バグの発生を未然に防止することに役立つ．

3 トピック分析
本研究で行うトピック分析の流れを図 1 に示す．以降の節ではこの手順を順を追って説明する．

3.1

コミットに関連するファイルの抽出

バグ混入コミットを抽出して，バグに関わった開発者がどのようなトピックの下で作業をしていたのかを明らかにする．バグ混入コミットの抽出方法は 4.2 節で述べる．
あるコミットが指定されるとそれに関連するファイル

RQ2: 開発者毎にトピックの傾向は違うか．
RQ3: 個人のバグ混入コミットとバグ非混入コミットのは git リポジトリの差分表示によって特定される．そこ
で，バグ混入コミットに関連づけられるソースコードから識別子を抽出した後，その識別子をさらに単語に分解名称し，その単語を単位とするトピックモデルを作成する．

ユニーク開発者数

20

バグ混入開発者数

123.2

識別子の抽出

全コミット数る手法について述べる. どの識別子がどのファイルから

表 1: 対象としたプロジェクト出現したか（即ち, 識別子の出現の頻度）はトピック抽係は壊さないように抽出する. 本研究では以下のツールを用いて抽出を行った．

2014
688

(内) バグ混入コミット数

次に，ソースコードファイルから識別子だけを抽出す

出の結果に影響するので, ファイルと識別子との対応関

Apache MINA

3.3.1

Term-score

自然言語処理の分野では, 文書内の単語の重要度の尺語として tf-idf がよく用いられる. tf-idf における文書をト識別子の抽出ツール: lscp

3.2.1

ソースコードからの識別子の抽出には, GitHub で公開ピックに置き換えたものが term-score である. term-score
はあるトピック内のでのある単語の特徴量として, 次のように表される.

されている「lscp」という Perl プログラムを利用した [7].

lscp はソースコードの文章を識別子やコメント, 文字列などに区別し抽出することが出来る. また, オプション

term-scorek,v=によって抽出する対象を変更することも出来る. 今回はコメント文や文字列は除き, 識別子だけを抽出するよう機能も有するため，この機能により識別子を単語に分解した．

3.2.2

(1)

β̂k,v : トピック k での語 v の出現確率
K : トピックの総数に設定した. また，識別子は通常複数の単語の組み合わせから構成されている．lscp はこうした単語を分割するβ̂k,vβ̂k,v log ∏K1 ( j=1 β̂ j,v ) K

右辺の前半部が tf 値に対応し, 対数部分が idf 値に対応することで, 全てのトピックで頻繁に現れる単語の term-score は低くなる. トピック内の特徴語とその単語の term形態素解析ツール: TreeTagger

抽出した識別子には, 英単語の進行形や過去形といっscore を各次元として対応付けたベクトルを作り, それら同士のコサイン類似度を測定し, 内容の似通ったトピックを結合することでトピック数を推定する.

た活用形が混じっている. それを形態素解析システム「TreeTagger」を使用することで基本形へと戻す語幹処cos( x⃗1 , x⃗2 ) =理を行った [5]. この操作と同時に, ストップワードを利x⃗1・x⃗2| x⃗1 || x⃗2 |(2)用してトピックとして不要な語を取り除く. なお，ストップワードとしては，トピック抽出ツール mallet [3] が有

3.4

トピック数の推定するストップワードリストを利用した．
次のステップに基づき, 対象のトピック数を推定する.

3.3

トピック抽出

語幹処理を施した識別子群をテキストとして, LDA に入力する. LDA はトピック数を入力する必要があるが,事前に対象に潜在するトピック数を知っている状況は少ない. 事前にトピック数を推定する手法は perplexity やHDP-LDA を利用するなど様々な方法が考案されているが, 先行研究である [9] を参考にし，今回は term-score [1]を用いた方法を使用する.

STEP 1. 意図的に多めにトピック数を設定し, LDA を用いてトピックを抽出する.
STEP 2. 抽出されたトピック間のコサイン類似度をそれぞれ測定する. どのトピックとも類似度が閾値を上回らない（類似度が低い）トピックを「単独トピック」とし, どれか一つでも閾値を上回るトピックが存在するトピックを「類似トピック」とする.

proportion

1.00

0.75

0.25

0.50

session322

session1

buffer

proportion(a) 全コミット

topic
4

1

1.00

1.0

address

0.75

1.0

30.50

1.5

0.00

1.00

2.0

ssl

0.25

buffer

2

1.5

40.00

2.5

topic

topic
3.0

2.5

10.75

0.25

0.00

topic
3.0

2.0

decode

10.50

topic

address

2

event

3

topic

session3

proportion(b) バグ混入コミット(c) バグ非混入コミット

図 2: プロジェクト MINA におけるトピックの傾向

STEP 3. 類似トピックだけを取り出し, それらをノードとして類似度が閾値を上回ったトピックの組にリンクを張ったグラフを考える. その時に完全グラフを構成するノードを一つにまとめる. これを「結合トピック」とし, さらに複数の結合トピックに含まれるトピックを「重複トピック」とする.
表 2: 各開発者のバグ混入コミット
開発者

D1 : Alan Cabrera
D2 : Alex Karasulu
D3 : Ashish Paliwal
D4 : Edouard De Oliveira
D5 : Emmanuel Lecharny
D6 : Ersin Er
D7 : Garrett RooneyD8 : Guillaume Nodet
D9 : Jeﬀ Genender
D10 : Jim Jagielski
D11 : John E. Conlon
D12 : Julien Vermillard
D13 : Maarten Bosteels
D14 : Mark Webb
D15 : Mike Heath
D16 : Niklas Gustavsson
D17 : Niklas Therning
D18 : Peter A Royal Jr
D19 : Sangjin Lee
D20 : Trustin Lee

全コミット

349770386
121113316744623510593811062

バグ混入
コミット 1050144500001035153317235220464

バグ関連
ファイル 1–271–
78531––––
1–
420
5289
43614954–
742

STEP 4. 重複トピックは重要性が低いものとして, 各結合トピックから削除する. こうして残った「結合トピック」数と「単独トピック」数の合計を, トピック数とする.

STEP 5. STEP 4 で出したトピック数で，再び STEP 1 から操作を行う. これを繰り返し行い, 平均してこれ以上トピック数が減らなくなった時点のトピック数を, 最終的なトピック数とする.

STEP 3 で用いた閾値は，類似度の乖離に基づいて設定する．

4 適用実験
4.1

対象プロジェクト

本実験で対象としたのは Apache プロジェクトで開発されているソフトウェア「MINA」の開発データである．

Apache MINA はネットワークアプリケーションの開発フ
レームワークであり，ユーザが簡単に高度なネットワークアプリケーションを作成できるようにするための補助ツールである．

(c) D5

1encodeproportion(e) D12(f) D13

1.00

0.75

0.50

0.25

2subnet

topic

topic
3.0
2.5
2.0
1.5

1

1.0

1.00

0.75

0.25

0.50

inet

1

proportion

2.5

proportion(g) D15(h) D16

2.5

state
1.75
1.50

session

1.0

decode2address

topic
2.00

topic

topic
2.00

1.5

3

session

2.0

1.75
1.5

1.50

1.25

1.25

1.00

1.00

topic
3.0

topic

2.0event

1

proportion

proportion

proportion(i) D17(j) D18(k) D20

1.00

0.75

0.25

0.00

1.00

0.75

0.50

0.25

0.00

1.00

0.75

0.50

0.25

0.5
0.00

0.5

2.0

1.0

assert

1.0

2.5

1.5

0.50

topic

connect

1.00

0.25

0.00

1.00

0.75

0.50

proportion

date

0.75

filter

1

3

2
2

0.50

1.0

0.00

filter

1.5

1

1

topic
4
3

1.00

1

2.0

2

address

3(d) D10

address3

2.5

address

20.75

address

3

14

proportion

topic

4

0.50

2

topic
3.0

0.25

topic
5

encodetopic
5

2session

4

image

3

2

1.00

0.75

(b) D4decode0.25

0.50(a) D2

idle

0.00

0.25

0.25

0.00

1.00

0.75

proportion

bufferstream1

buffer

1

proportion

4

session

3

2

proxy

2

1

session

1

4
topic
4
3

proportion

5

3

address

2

proxy

2

1

topic

topic

0.50

session
0.25

10.00

message

3

zlib

0.00

3

3

2

2

topic
4

topic

entry

0.00

address

3

5

0.00

4

session

topic

topic
5

4

1.00

event

3

buffer

0.75

4

4

0.50

buffer

topic

topic

5

図 3: 開発者毎の全コミットにおけるトピックの傾向
具体的には，ソースコードの git リポジトリとバグデー
タベース JIRA から抽出したバグが混入した時点などの情報を用いる．

MINA の全開発人数は 20 人で，全コミット数は 2014個である．そのうちの 688 個がバグ混入コミットである．
表 1 に本プロジェクトの特性を挙げる．

4.2

バグ混入コミットの抽出

バグ混入コミットの抽出には文献 [6] に示されている

SZZ アルゴリズムを用いる．SZZ アルゴリズムの概要は以下の通りである．

いと仮定する．

3. 不具合は発見される前に作り込まれているはずなので，CLFaultFixed のうち，不具合が初めて報告された時点 D fi から fi が修正されるまでの間，1 度も変更されなかったクラスを CLFaulty とする．このCLFaulty を作った時点のコミットをバグ混入コミッ
ト CMBugIn ject とする．
4. 全ての不具合に対し，1 から 3 の作業を繰り返す．
この結果, バグ混入コミットの集合 CMBugIn ject が得られる 1 ．

1. ある不具合 fi に対し，バージョン管理記録のコメン
ト部分から fi が修正されたコミットを特定する．
2. fi の修正の際に実際に変更されたクラス CLFaultFixedを特定し，それ以前の状態は不具合が含まれていな

1 バグ混入コミットに関して，ファイル “pom.xml” に関する不具合は不具合として数えていない．

filter5

socket3

assert4

4

1

socket

1.5

1

1.0

http

0.25

0.00

1.00

0.75

0.50

0.25

10.00

2.0

2

proportion

1.00

buffer2.5

session

20.75

2

3

0.50

address

3

topic
3.0

topic

topic

topic
5

proportion(a) バグ混入コミット(b) バグ非混入コミット

図 4: 開発者 D20 のコミットにおけるトピックの傾向

charset char get set read write
open org net com file size length

4.4

index type output input put array
list flag integer min max www src

4.4.1

utf impl val prev util
図 6: MINA におけるトピック抽出のストップワード

実験結果
プロジェクト全体に対する分析

図 2 は Apache MINA プロジェクトの全体，バグ混入，バグ非混入それぞれのコミットから抽出したトピックの最も重要な語を表したものである．図 2a にプロジェクト全体から抽出したトピックを挙げる．ここで挙げられた “session”, “address”, “decode” の 3 語が，MINA では

4.3

バグ混入コミットの取り出し支配的であることを示している．以降のトピックを示す
グラフの横軸は正規化したトピックの出現頻度を示して対象となるプロジェクト Apache MINA のバグ混入コおり，縦軸はトピックの種類を表す．また，グラフに重ミットで変更されたファイルの総数は 2436 個であり, そねてトピックに含まれる単語を示している．図 2 中のトれに携わった開発者は 12 人である. 表 2 に各開発者にピックに含まれる単語はネットワークアプリケーション

ついての全コミット数，バグ混入コミット数，バグ混入の開発フレームワークという特性を反映し，session やに関連したファイル数を示す．表 2 からは，開発者のコaddress といった語が多く出現する．

ミット数には大きなばらつきがあり，D20 が主要な役割を果たしていることが分かる．

図 2b にプロジェクト MINA におけるバグコミットから抽出した頻出トピックを挙げる．図 2b からは “event”,Apache MINA からトピックを抽出するにあたって，図“buﬀer”, “session” というトピックが出現し，中でも6 に示す語は追加のストップワードとして扱った．これ
らの語はあまりにも頻繁に出現し，さらにプログラミン“event” に関するバグ混入コミットが多いことが分かる．
一方，図 2c にプロジェクト MINA におけるバグ非混入

グ言語中に一般的に存在する語であることから除外した．

コミットから抽出したトピックを示す．このグラフでは，“ssl” が最頻出であり， “address”, “session”, “buﬀer” とimage

button

ssl

topic
7
65
43
2
1

requestbufferentry

logger4queuefilter2

proportion

0.50

0.25

0.00

1.00

buffer

0.75

0.50

0.25

0.00

address

1.00

2

topic
7
65
4
3
2
1

session

0.75

topic

service

4

bean

6

topic

6

proportion(a) バグ混入コミット(b) バグ非混入コミット

図 5: 開発者 D13 のコミットにおけるトピックの傾向
続く．

少ないファイルでの特徴が抽出されたものとなっている．

このことから，バグが混入するコミットでは “event”

このように，開発者のトピックを分析することでそのに関するトピックが多く，逆に “ssl” に関連するトピッ

開発者が従事している開発をある程度特定できる．さらクが存在したコミットではバグが混入しないことが多いに抽出したトピックを利用すればより詳細な情報を得ると分かる．

ことも期待できる．

以上より，RQ1 での設問「プロジェクトにおけるバグ混入コミットとバグ非混入コミットの間でトピックの種

以上のことから，RQ2 での設問「開発者毎にトピックの傾向は違うか」は「違う」と結論づけられる．

類に差はあるか．
」は「差を発見できる」と結論づける．

4.4.3
4.4.2

開発者全体の特徴分析

開発者のバグ傾向分析

上で挙げた 2 人の開発者 D20 と D13 について，それぞ

ここでは，各開発者の全コミットに対するトピックをれのバグ混入コミットとバグ非混入コミットを区別した抽出し，その結果を図 3 に示す．なお，表 2 に挙げた開上でトピックを抽出したものを図 4，図 5 に挙げる．

発者のうち，バグ混入コミットを作成していない開発者は以降の分析で除外している．

図 4a と図 4b は最も多くのコミットを行った開発者

D20 のバグ混入時と，バグ非混入時のトピックをそれぞ

図 3 を調べると多くの開発者は図 2a で挙げるトピッれ示したものである．この図からは，D20 がバグを混入クを含む開発をしていることが分かる．開発者間の傾向するコミットは “filter”, “assert”, “address” などのトピッは類似したものが多いが，D13 は唯一 “image” というトクがあるときに多いことが分かる．一方でバグ非混入トピックが見られる．これは，D13 が GUI 関連のコードをピックのトピックは “socket”, “session” などであり，こ多く書いていることに起因している．

うしたトピックについてはあまりバグを混入しなかった開発者 D10 も “zlib” という語がトピックで出現している．ただし，この D10 は 3 コミットしかしていないため，ことが分かる．

同様に別の開発者 D13 のバグ混入コミットとバグ非混参考文献

入コミットのトピックを図 5 に示す．
図 5a と図 5b を比較する．図 5a のバグ混入コミットのトピックには “image”, “ssl”, “service” が存在する．これは，先に図 3f で示されたように，GUI 関連の語である “image” の出現頻度が最も高いことを示している．一方で図 5b のバグ非混入コミットにおけるトピックでは“button”, “bean”, “session” となっており，こちらも GUI関連のトピック “button” が含まれている．すなわち，バグを混入した場面で最も多かったのは GUI の image に関わるものの変更であり，それはバグ非混入のものとは傾向が違うことが分かる．

[1] D. Blei and J. Laﬀerty. TOPIC MODELS. Taylor andFrancis, 2009.
[2] G. Maskeri, S. Sarkar, and K. Heafield. Mining business topics in source code using latent dirichlet allocation. In Proceedings of the 1st India Software Engineering Conference, ISEC ’08, pp. 113–120, New York, NY,USA, 2008. ACM.
[3] A. K. McCallum. Mallet: A machine learning for language toolkit. http://mallet.cs.umass.edu, 2002.

以上の結果より，RQ3「個人のバグ混入コミットとバグ非混入コミットの間にトピックの種類に差はあるか．
」[4] O. Mizuno and T. Kikuno. Prediction of fault-proneについては「差がある」と結論づける．

software modules using a generic text discriminator. IEICE Trans. on Information and Systems, E91-

5 まとめと今後の課題

D(4):888–896, 2008.

本報告では，ソフトウェアのソースコードからトピッ[5] H. Schmid. Treetagger - a language independent
part-of-speech tagger, Nov. 2013. http://www.cis.

クを抽出する技法を利用し，開発者がバグを混入するコ

uni-muenchen.de/˜schmid/tools/TreeTagger/.

ミットでの特徴を抽出することを試みた．適用実験として，Apache MINA プロジェクトからトピックを抽出し，[6] J. Śliwerski, T. Zimmermann, and A. Zeller. When do

開発者毎の分析を実施した．分析の結果を以下にまとchanges induce fixes? In Proceedings of the 2005 International Workshop on Mining Software Repositories,
MSR ’05, pp. 1–5, New York, NY, USA, 2005. ACM.

める．

• プロジェクトにおけるバグ混入コミットとバグ非混入コミットの間でトピックの種類に差は存在する．

[7] S. Thomas. lscp, Nov. 2013. https://github.com/
doofuslarge/lscp/.

• 開発者毎にトピックの傾向は明らかに異なる．
• 個人のバグ混入コミットとバグ非混入コミットの間でのトピックの種類に差が見られる．
この結果から，トピックの分析は開発者個人が混入するバグの分析に有効であろうと考えられる．
今後の課題としては以下のものが挙げられる．

• 多くのプロジェクト，多くの開発者に対する適用• 複数のプロジェクトに関わる開発者についてのトピック抽出• 得られたトピック情報をソースコードに還元して注意喚起を促すシステムの開発[8] S. W. Thomas, B. Adams, A. E. Hassan, andD. Blostein. Modeling the evolution of topics in sourcecode histories. In Proceedings of the 8th working conference on mining software repositories, pp. 173–182.
ACM, 2011.
[9] 芹澤, 小林. 文書内のトピック数を考慮したトピッ
ク追跡の試み. 言語処理学会年次大会発表論文集,
No. 18, pp. 3–32, 2012.