情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

情報検索に基づく Bug Localization への不吉な臭いの利用
高橋 碧1,a)セーリム ナッタウット1,b)

林 晋平1,c)

佐伯 元司1,d)

受付日 2015年3月4日, 採録日 2015年8月1日

概要：大規模なソフトウェア開発では，ある特定のバグを解決するために修正すべきソースコード箇所を見つける Bug Localization が必要である．情報検索に基づく Bug Localization 手法（IR 手法）は，バグに関して記述されたバグレポートとソースコード内のモジュールとのテキスト類似度を計算し，これに基づき修正すべきモジュールを特定する．しかし，この手法は各モジュールのバグ含有可能性を考慮していないため精度が低い．本論文では，ソースコード内のモジュールのバグ含有可能性として不吉な臭いを用い，これを既存の IR 手法と組み合わせた Bug Localization 手法を提案する．提案手法では，不吉な臭いの深刻度と，ベクトル空間モデルに基づくテキスト類似度を統合した新しい評価値を定義している．これは深刻度の高い不吉な臭いとバグレポートとの高いテキスト類似性の両方を持つモジュールを上位に位置
付け，バグを解決するために修正すべきモジュールを予測する．4 つの OSS プロジェクトの過去のバグレ
ポートを用いた評価では，いずれのプロジェクト，モジュール粒度においても提案手法の精度が既存の IR
手法を上回り，クラスレベルとメソッドレベルでそれぞれ平均 22%，137%の向上がみられた．また，不吉な臭いが Bug Localization に与える影響について調査を行った．
キーワード：Bug Localization，情報検索，不吉な臭い，バグ含有可能性

Using Code Smells to Improve
Information Retrieval-Based Bug Localization
Aoi Takahashi1,a)Natthawute Sae-Lim1,b)

Shinpei Hayashi1,c)Motoshi Saeki1,d)Received: March 4, 2015, Accepted: August 1, 2015

Abstract: Bug localization is a technique that has been proposed to support the process of identifying thelocations of bugs specified in a bug report. For example, information retrieval (IR)-based bug localization
approaches suggest potential locations of the bug based on the similarity between the bug description and thesource code. However, while many approaches have been proposed to improve the accuracy, the likelihood ofeach module having a bug is often overlooked or they are treated equally, whereas this may not be the case.
For example, modules having code smells have been found to be more prone to changes and bugs. Therefore,
in this paper, we propose a technique to leverage code smells to improve bug localization. By combining thecode smell severity with the textual similarity from IR-based bug localization, we can identify the modules
that are not only similar to the bug description but also have a higher likelihood of containing bugs. Our casestudy on four open source projects shows that our technique can improve the baseline IR-based approach by
22% and 137% on average for class and method levels, respectively. In addition, we conducted investigations
concerning the eﬀect of code smell on bug localization.
Keywords: bug localization, information retrieval, code smell, bug proneness

1

a)
b)
c)
d)

東京工業大学 情報理工学院
School of Computing, Tokyo Institute of Technology
takahashi-a-at@se.cs.titech.ac.jp
natthawute@se.cs.titech.ac.jp
hayashi@c.titech.ac.jp
saeki@c.titech.ac.jp

c 2016 Information Processing Society of Japan⃝

1. はじめに大規模なソフトウェア開発では，開発者は多くのバグを修正しなければならない．バグ報告に基づくバグレポート
が多数作成され，それらを手動で解決するためには多くの

1

情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

時間を要する．また，バグを修正するために最も時間がか

表 1 IR 手法の適用例

かる作業の 1 つは，バグレポートに書かれたバグの原因とTable 1 Application example of IR-based bug localization.

なるソースコード箇所の特定である．Thung ら [1] は，バ

順位

グの位置特定が困難であることをソフトウェアの分析から

1

ActionSaveProject

0.179

明らかにしている．

2

AbstractFilePersister

0.174

3

ZipFilePersister

0.150

4

XmiFilePersister

0.150

5

UmlFilePersister

0.142

6

ProjectFilePersister

0.128（Information Retrieval; IR）[2–4]，静的解析 [5]，動的解

7

FileConstants

0.123

析 [6, 7] などに基づく手法がある．また，これらを統合し

8

ActionSaveProjectAs

0.122

た手法 [8–10] も提案されている．

9

ActionOpenProject

0.121

10

ProjectBrowser

0.121

上記の課題に対処する手段の 1 つに，Bug Localizationがある．Bug Localization は，バグを解決するために修正すべきソースコード箇所を特定することを指し，情報検索

情報検索に基づく手法（IR 手法）では，報告されたバ

クラス名

テキスト類似度

グレポートとソースコードとのテキスト類似度を計算する
ことで，バグの修正箇所を特定する．このように，IR 手法は，対象とするバグレポートとソースコードのみを入力として用いる，適用するための制約が少ない手法である一2. 動機方，得られる精度に課題がある．その理由の一つに，IR 手

IR 手法の精度が高くない理由の一つに，IR 手法が主に法が主に入力のテキスト類似度に注目しており，結果とし入力のテキスト類似度に注目しており，結果として特定て特定されるモジュールにどの程度バグが含まれやすいのされるモジュールにどの程度バグが含まれやすいのかをかを考慮していないことがある（詳細は 2 章）．

考慮していないことがある． 表 1 は，オープンソースソ

本論文では，Bug Localization 手法の一つである IR 手

フトウェア（OSS）ArgoUML において，バグレポート*1

法に加えて，不吉な臭いの情報も組み合わせることで IR（ID：3790）の要約（“Exception when saving to a readonly

手法の精度を向上させる手法を提案する．以下に本論文のdirectory.”）とその説明を入力として，クラス粒度で IR 手

貢献を述べる．

法を適用した結果の抜粋である．ランキング上位のクラス• 既存の IR 手法の問題点を，オープンソースソフトウェ
アの実例を用いて示した．

は入力のバグレポートとのテキスト類似性が高く，例えば
クラス ActionSaveProject は save を含む多くの単語を共• IR 手法とソースコードに存在する不吉な臭いの情報有している．しかし，実際の正解にこのクラスは含まれず，を組み合わせる Bug Localization 手法を提案した．本

10 位の ProjectBrowser が正解に該当する．ここで注目す手法は，ソースコード以外の追加的な入力なしに，IRべき点は，このクラスは他のクラスよりもテキスト類似性

手法の精度を向上できる．

に乏しいが，複数の不吉な臭い [12] を持っていることであ• 4 つの OSS に関して評価実験を行い，IR 手法に比べる．不吉な臭いとは，低品質な設計によりリファクタリン

て本手法では全てのプロジェクトで精度が向上するこグを必要とするソースコード箇所であり，その存在がソフとを示した．

トウェアの保守や理解に悪影響を与えることが示されてい• 不吉な臭いが Bug Localization の精度に影響を与えた
要因について複数の観点から調査した．

る [13, 14]．また，多くの種類が Fowler の文献 [12] の中で紹介されているが，それらの不吉な臭いに密度 [15] や深刻

本論文は，ICPC 2018 での我々の発表 [11] の内容を発展

度 [16] を割り当て，不吉な臭いに優先順位付けを行う手法

させたものである．既存の IR 手法の問題点を具体例を用もある．さらに，不吉な臭いを持つモジュールにはバグがいて示した点（2 章）と，不吉な臭いが Bug Localization

含まれやすいことも示されている [17,18]．ProjectBrowserの精度に影響を与えた要因について調査を行った点（5.5

クラスからは，行数の長さに起因する Blob Class と，責務節）が主要な拡張箇所である．

の過多による複雑性に起因する God Class の 2 つの不吉な本論文の以降の構成を以下に示す．2 章では，提案手臭いが検出されており，さらにそれらの深刻度はそれぞれ法を用いる動機を，例を用いて述べる．3 章では，Bug

3，5 と高い．こういった不吉な臭いの特徴，特に詳細な順

Localization に関する既存研究を紹介する．4 章では，Bug

位付けが可能だと考えられる不吉な臭いの深刻度を，テキ

Localization と不吉な臭いを組み合わせた手法について説

スト類似度に加えて考慮することで，このクラスを高順位明する．5 章では，提案手法の有効性を検証するための評に引き上げられる可能性がある．

価実験の内容とその結果の考察を行う．6 章では，本論文のまとめと今後の課題について記す．

c 2016 Information Processing Society of Japan⃝*1

http://argouml.tigris.org/issues/show_bug.cgi?id=
3790

2

情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

3. 関連研究3.1 IR に基づく Bug Localization 手法

バグレポート

IR手法

IR 手法は Bug Localization の分野で幅広く用いられて
おり，ソフトウェア開発の際に作成されたバグに関する記述であるバグレポートと，現在のソースコードの 2 つを入力として用いる．これまでに，Latent Dirichlet Allocation

1. 2. 3. モジュールごとのテキスト類似度

ソースコード不吉な臭いの検出（LDA）[2, 19]，Latent Semantic Indexing（LSI）[3, 20]，

Vector Space Model（VSM）[4] など，多くの IR 手法が提案されている．Rao ら [21] は，これらの代表的な手法の中でも VSM が最も効果的であると述べている．この

VSM に加えて，過去の類似したバグレポートを用いたûûû

提案メトリクスの計算

不吉な臭いの深刻度

1. 2. 3. -提案メトリクス

図 1 提案手法の概要

BugLocator [22] が Zhou らによって提案されている．

Fig. 1 Overview of proposed technique.

IR 手法では，バグレポートの質に強く依存するため，情報不足のバグレポートでは，良い結果が得られないことが問題となる．Kim ら [23] はバグレポートの質が十分かを判定し，十分な質であれば IR 手法を適用してバグの箇所を予測し，そうでなければ予測を行わない手法を提案している．Le ら [24] も IR 手法に基づくツールでの結果が効果的かを判定する手法を提案している．これらの手法を用いれば，開発者は IR 手法が誤って提案してしまったモジュー
ルに時間を取られずに済む．他にも Chaparro ら [25] は，
低品質なバグレポートを再構成する手法を提案している．

3.2 その他の Bug Localization 手法
静的解析手法は古くから用いられており，その典型的なものに静的プログラムスライシング [5] がある．静的プロ
グラムスライシングでは，ある関心事に対応するスライス
基準を与え，プログラム中の依存関係に注目して，関心事に関係のあるモジュール群を抽出する．この手法では，開発者がスライス基準を与えなければならない点，依存関係のあるモジュールが膨大となる点など，実践には多くの課題が残っている．Acharya ら [26] は，近年の大規模なソフ
トウェア開発に対するプログラムスライシング技術の問題
点とその改善案について言及している．
動的解析手法では，実際にプログラムを実行した際に得られる情報を用いて，Bug Localization を行う．Wong
ら [7] はスタックトレースを用いたツール BRTracer を提案した．スタックトレースには，テストに失敗するまでの間にどのような処理をどのような順番で呼び出したのかが表現されており，この情報を活用する．また，プログラムの実行トレースから，実行に成功したトレースと失敗した
トレースの間のスペクトル統計情報を分析したスペクト
ルベースの Bug Localization も提案されている [27]．Dao
ら [6] は，IR 手法に基づく Bug Localization に動的な実
行情報がどのように役立つかを調査している．この調査では，失敗したテストのカバレッジや，動的なスライス情報

c 2016 Information Processing Society of Japan⃝が IR 手法の検索範囲を効果的に減らすなど，改善が見られることが報告されている．動的解析手法の特徴として，高い精度を持つ代わりに，開発者が実際にプログラムを実行する必要があり，開発者に高い知識と時間的な手間を要求することとなる．
過去の変更履歴を効果的に用いる手法も提案されている．

Tantithamthavorn ら [28] は同時変更履歴を用いて，あるモジュールが変更された際に，同時に変更される可能性の高いモジュールを計算することで Bug Localization の精度を向上させている．
複数の手法を統合した手法も提案されている．Shi ら [29]は IR 手法に基づく Bug Localization に追加的な情報を付与し統合することが有益であると述べている．Saha ら [8]はソースコード構造に基づいた情報を用いて IR 手法を適用した上で，利用可能であれば過去の類似のバグレポートを用いるツール BLUiR を提案した．他にも，Wang ら [9]は，BugLocator [22] と BLUiR [8]，さらに Bug Prediction
ベースの変更履歴を統合したツール AmaLgam を提案している．さらに，Youm ら [10] はバグレポートやソースコー
ド構造情報，変更履歴，スタックトレースを用いた動的情報を統合したツール BLIA を提案している．これらの追加的な情報を含める手法は IR 手法に比べて大きく精度を向上させてきた．ただし，これらの追加的な情報は常に利用可能であるとは限らず，開発者の入力を必要とするものもある点に注意が必要である．

4. 提案手法
4.1 概要提案手法の概要を図 1 に示す．提案手法では，バグレ
ポートとソースコードを入力として IR 手法を適用し，ソー
スコード内のモジュールごとにバグレポートとのテキスト類似度を計算する．また，ソースコードを入力として不吉な臭いを検出し，不吉な臭いの深刻度 [16] を得る．不吉

3

情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

表 2

ArgoUML に対する適用例

Table 2 Application example to ArgoUML.

(a) IR 手法（α = 0）
順位

クラス名

(b) 提案手法（α = 0.42）

nSim

nSev

BLI

順位

クラス名

nSim

nSev

BLI

1

ActionSaveProject

1

0

1

1

ProjectBrowser

0.679

0.667

0.674

2

AbstractFilePersister

0.971

0

0.971

2

ActionSaveProject

1.000

0

0.580

3

ZipFilePersister

0.842

0

0.842

3

AbstractFilePersister

0.971

0

0.563

4

XmiFilePersister

0.841

0

0.841

4

ZipFilePersister

0.843

0

0.489

5

UmlFilePersister

0.795

0

0.795

5

XmiFilePersister

0.842

0

0.488

6

ProjectFilePersister

0.715

0

0.715

6

Modeller

0.222

0.833

0.479

7

FileConstants

0.691

0

0.691

7

UmlFilePersister

0.794

0

0.461

8

ActionSaveProjectAs

0.683

0

0.683

8

Import

0.430

0.500

0.460

9

ActionOpenProject

0.679

0

0.679

9

ParserDisplay

0.051

1

0.449

10

ProjectBrowser

0.679

0.667

0.679

10

StylePanel

0.586

0.250

0.445

な臭いの深刻度とは，不吉な臭いの深刻さ・悪さを数値化

4.4 提案メトリクスの計算したものである．テキスト類似度と不吉な臭いの深刻度のモジュールごとに，nSim と nSev を用いて以下のように両方を組み合わせることで提案メトリクスが計算される．

提案メトリクスを表す Bug Likelihood Index （BLI ）を計

各モジュールを提案メトリクスの高い順に並び替えたリス

算する．

トを作成し，そのリストを参考に開発者はバグの修正を試

BLI (m) = (1 − α) × nSim(m) + α × nSev (m)みる．

ここで α (0 ≤ α ≤ 1) は用いている nSim と nSev の重要

4.2 IR 手法

度の分配を表すパラメータであり，利用者が経験的に与えIR 手法では，対象プロジェクトのバグの内容が記述されたり，適用したいプロジェクトの過去のデータや他のプロたバグレポートとソースコードを入力とする．これらの入ジェクトの値などから定める．α = 0 のとき，BLI が表力から，ソースコードのモジュールごとにバグレポートとすモジュール順位は IR 手法の結果と等しくなる．一方，のテキスト類似度が計算される．対象とするモジュール群

α = 1 のとき，順位には不吉な臭いの深刻度のみが反映さ

M のうち，特定のモジュール m とバグレポートとのテキれる．

スト類似度を Sim(m) として得る．この Sim(m) を，以下のように [0, 1] に線形正規化して用いる．

4.5 適用例
VSM に基づくテキスト類似度の計算に TraceLab [30]，nSim(m) =Sim(m)
maxm′ ∈M Sim(m′ )不吉な臭いの検出に inFusion*2 を用いて，提案手法を適用した例を示す．A.1 章には，inFusion により検出される，粒度がクラスレベルとメソッドレベルの不吉な臭いの

4.3 不吉な臭いの検出一覧が含まれている．表 2 は，表 1 で入力として用いた

対象プロジェクトのソースコードを入力として，不吉なバグレポートに対する適用結果の上位 10 を示しており，臭いを検出する．検出された不吉な臭いは，その種類，対IR 手法（α = 0) と提案手法（α = 0.42）の結果を比較し象モジュール，深刻度（Severity）などの情報を伴っていている．バグレポートに対して実際に変更された正解クる．提案手法では不吉な臭いの情報の定量化方法としてこラスは灰色で強調されている．IR 手法では正解のクラスの深刻度を用いる．これは，単に不吉な臭いを持つか否か

ProjectBrowser が 10 位に位置付けられているが，このクよりも細かく優先順位付けを行える分解能を与えるためでラスは不吉な臭いを持っており，nSev の値が高かったた

ある．

め，提案手法を用いた場合，1 位に位置付けられるように対象とするモジュール群 M のうち，特定のモジュール

なった．この例では，不吉な臭いの深刻度を用いることで，m で検出された全ての不吉な臭いの深刻度の合計 Sev (m)実際に変更されたクラスを IR 手法より高順位に位置付けを計算する．ただし，Bug Localization の対象モジュール

ることができている．

粒度と同じ粒度の不吉な臭いのみを用いる．この Sev (m)を，以下のように [0, 1] に線形正規化して用いる．

5. 評価実験
提案手法の評価のため，以下の 3 つの Research QuestionnSev (m) =Sev (m)maxm′ ∈M Sev (m′ )c 2016 Information Processing Society of Japan⃝*2

http://www.intooitus.com/products/infusion（販売は中止されており，現在はアクセスできない．）

4情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

表 3 プロジェクトの情報

Table 3 Projects used.
プロジェクトバージョン

バグレポート数

クラス数

メソッド数

クラスの臭い数

メソッドの臭い数

411

ArgoUML

0.20–0.24

74

1476

12131

61

JabRef

2.0–2.6

36

374

2947

37

60

jEdit

4.2–4.3

86

406

5276

51

185

muCommander

0.8.0–0.8.5

81

529

3916

41

44

（RQ）を定めた．

タセットから得られる正解セットとを比較し，順位付けリ

RQ 1：重要度のパラメータ α は手法の精度にどのようにストの精度の評価を行う．これには，順序付きランキング

影響するか? α は提案手法において不吉な臭いの情報と既を評価するために用いられる精度メトリクスである Mean

存の IR 手法の情報の結合割合であり，この値の影響を調Average Precision（MAP）を用いた．MAP は全てのバグ

べることは 2 つの情報のそれぞれの重要度を求めることにレポートの Average Precision（AP）の平均である．1 つ相応する．また，実際に手法を利用する際に α を定めるたのバグレポートの AP は以下のように計算される．

めにも，最適な α を求めておくことは重要である．

RQ 2：既存の IR 手法と比べ，提案手法は優れているか?

AP =実際に提案手法を用いることで既存の IR 手法よりも優れているかを調べることにより，不吉な臭いの情報を既存のIR 手法に組み合わせることが効果的であり，精度を向上させるかを検証する．α を定める際には，RQ 1 の結果を利用する．具体的には，複数の既存プロジェクトの α の最適値が既知である状況を想定し，特定のプロジェクトの α には，他の 3 プロジェクトの α の最適値の平均を用いる．

RQ 3 ：不吉な臭いの利用による精度変化の要因は何か?
提案手法による不吉な臭いの利用がどのような要因により精度の変化に影響を及ぼしたのかを，不吉な臭いのモ
ジュール分布およびバグレポート毎の精度の変化の 2 つの観点から分析する．また，これらの分析により，提案手法の特徴や今後の課題を明らかにする．

5.1 データ収集
本実験では，Dit らの変更影響分析のデータセット [31]を用いた．このデータセットには，4 つのオープンソースソ
フトウェアプロジェクトに対して，特定バージョンのソー
スコード，次期バージョンまでに解決されたイシュー，イシュー解決時に変更されたモジュール（正解セット）が含まれている．本実験では，バグカテゴリに属するイシュー
をバグレポートとして使用した．各プロジェクトの情報を
表 3 に示す．不吉な臭いは，データセットに含まれる変更
前バージョンのソースコードを inFusion に入力として与えて得た．各モジュール粒度で得られた不吉な臭いの検出数
も表 3 に示している．また変更前バージョンのソースコー
ドは，バグレポートとの VSM を用いたテキスト類似度の計算にも用いた．

5.2 評価メトリクス
提案手法では，提案メトリクス BLI に基づいて各モ
ジュールを順位付けしたリストが得られる．これと，デー

c 2016 Information Processing Society of Japan
⃝

N
∑
i=1

Pre(i) × pos(i)正解セットのモジュール数

ここで，i は順序付けされたモジュールの順位，N は順序付けしたモジュールの総数を表す．Pre(i) は i を含む i よ
りも順位の高いモジュールにおける正解セットのモジュールの割合を表す．pos(i) は i 番目にランク付けされたモジュールが正解セットに含まれていれば 1，さもなくば 0を返す．MAP は，与えられた全てのバグレポートでの APの平均値となる．

5.3 RQ 1：重要度のパラメータ α は手法の精度にどのように影響するか?

5.3.1 調査方法
RQ 1 に答えるために，α を横軸，MAP を縦軸とするグラフを描く．α を 0.01 刻みで 0 から 1 まで変化させ，それぞれの BLI を計算し各モジュールを順位付けた場合のMAP を計算する．このグラフをモジュール粒度がクラスレベルとメソッドレベルの両方で対象プロジェクトに関して作成する．これらにより得られたグラフの形状および

MAP が最大値となる α の値について議論する．
5.3.2 結果と考察
結果を図 2 に示す．また，それぞれのグラフの α の最適値，すなわち MAP が最大となる α の値を表 4 に示す．
最も重要な結果として，既存の IR 手法のみを用いたり（α = 0 ），不吉な臭いのみを用いたり（α = 1）するのではなく，それら 2 つを組み合わせた場合の方が効果的だった
ことがある．クラスレベルの結果では，α が 0.25–0.46 の値で MAP が最大となった．メソッドレベルの結果では，

α が 0.41–0.47 の値で MAP が最大となった．メソッドレ
ベルの結果では，クラスレベルの結果に比べて α の最適値が広範囲にわたっていない．一方で，クラスレベルでは，JabRef のみ他のプロジェクトに比べて α の値が明らかに小さい．その理由として，表 3 を見ると分かるように，

5情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

0.15

0.25
0.2
MAP

MAP

0.1
0.15
0.1

0.05
0.05
0

0

0.2

0.4

α

0.6

0.8

0

1

0

0.2

0.2

0.15

0.15

0.1
0.05
0

α

0.6

0.8

1

0.8

1

(b) JabRef.

0.2

MAP

MAP

(a) ArgoUML.

0.4

0.1
0.05

0

0.2

0.4

α

0.6

0.8

1

0

0

0.2

(c) jEdit.

0.4

α

0.6

(d) muCommander.
クラスレベル図 2

メソッドレベルα ごとの MAP の値

Fig. 2 MAP values for each α.
表 4α の最適値表 5 RQ 2 で用いた α の値

Table 5 α values used in answering RQ 2 .

Table 4 Most appropriate α values.
プロジェクトクラスレベル

メソッドレベル

ArgoUML

0.42

0.43

JabRef

0.25

0.44

jEdit

0.37

muCommander

0.46

クラスレベル

メソッドレベル

ArgoUML

0.36

0.44

JabRef

0.42

0.44

0.47

jEdit

0.38

0.43

0.41

muCommander

0.35

0.45

JabRef ではクラスレベルの不吉な臭いの検出数が全プロ

プロジェクト

5.4 RQ 2 ：既存の IR 手法と比べ，提案手法は優れてい

ジェクトの中で最も少なく，不吉な臭いの影響が大きくなるか?

らなかった可能性がある．しかし，muCommander との検5.4.1 調査方法

出数の差はわずか 4 であり，さらにクラス数に対する不吉

RQ 1 の結果を用いて α を実際に定め，提案手法を適用すな臭いの検出数の割合は ArgoUML が最も少ないため，原る．ここでは，あるプロジェクトを予測する際には，他の因の特定にはより詳細な分析が必要である．JabRef のク

3 プロジェクトの α の最適値の平均を用いた．例えば，対ラスレベルでの結果を除き，α の最適値は 0.40 付近に集中

象プロジェクトが ArgoUML の場合には，JabRef，jEdit，

しており，この値は経験的に他のプロジェクトにも利用で

muCommander の 3 つのプロジェクトの RQ 1 で求めた α

きる可能性があると考える．

の最適値の平均を α として定めて提案手法を適用した．こいずれの試行においても，テキスト類似度，不吉な臭いの両情報を適切に組み合わせた際（クラスレベルでは

α ∈ [0.25, 0.46]，メソッドレベルでは α ∈ [0.41, 0.47]）に MAP が最大となった．

c 2016 Information Processing Society of Japan⃝

れは，複数の既存プロジェクトの α の最適値が既知である
状況で対象プロジェクトの α を定める場合を想定している．実際に用いた α の値を表 5 に示す．このようにして

MAP を求め，提案手法が既存の IR 手法（α = 0）に比べて優れているかを検証する．

6

情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

0.06
0.2
0.04
MAP

MAP

0.15
0.1

0.02

(a) クラスレベル

muCommander

jEdit

JabRefArgoUML0

muCommander

jEdit

JabRef0

ArgoUML

0.05(b) メソッドレベル
IR 手法
図 3

提案手法

MAP の値の比較

Fig. 3 Comparison of MAP values.

5.4.2 結果と考察（正解セット）とそうでないモジュールが，どの程度不吉

結果を図 3 に示す．既存の IR 手法に対する提案手法のな臭いを持っていたかを調べた．具体的には，正解セット

MAP の上昇率は，クラスレベルで 39%，2%，32%，15%，に含まれるモジュール，及び，正解セットに含まれないモ

メソッドレベルで 269%，185%，56%，36%であった．いジュールの中で，不吉な臭いが検出されたものの割合∑

ずれのプロジェクト，モジュール粒度でも，既存手法に比べて提案手法の MAP が向上した．ただし，全体としてクSR =ラスレベルの方が，上昇率が低かった． この原因に，αr∈R |Or ∩ M∑

sr∈R |Or ||∑|M s \ Or |, SR = ∑r∈R
r∈R |M \ Or |∗の最適値の多様性の差がある．クラスレベルの JabRef かをそれぞれ求めた．ここで，R はバグレポート全体の集ら得た α の最適値は表 4 から 0.25 であるが，この値は他

合，M はモジュール全体の集合，M s は不吉な臭いを持つの 3 プロジェクトから得た α とは大きく離れている．メモジュールの集合，Or はバグレポート r の正解セットをソッドレベルでは，α の最適値は全プロジェクトで近い値指す．

を取っているため，この差が上昇率の差を生んでいる．また，図 2 からも分かるように，メソッドレベルよりクラス

結果を表 6 に示す．表の値から，いずれのプロジェクトにおいても，SR ∗ に比べて SR が自明に高いことが分かる．

レベルの方が MAP の絶対値が高いことも挙げられる．一

つまり，正解セットに含まれるモジュールはより高い割合方で，メソッドレベルではプロジェクト毎の α の最適値がで不吉な臭いを持っているということであり，これは Bug

近いため，MAP の上昇率が高くなったと考える．

Localization に不吉な臭いの情報を用いることが効果的であることを示唆している．

すべての試行において，提案手法の MAP が既存の IR

また，不吉な臭いの分布に関して，臭いの種類が提案手手法を上回った．クラスレベルでは平均 22%（最大では法に与える影響についてより詳細に分析するために，同様39%），メソッドレベルでは平均 137%（最大では 269%）の調査を，不吉な臭いの種類ごとにも行った．具体的には，の向上があった．

前述した，不吉な臭いが検出されたモジュールの割合 SR ，

5.5 RQ 3 ：不吉な臭いの利用による精度変化の要因はSR ∗ を，特定の臭いの種類に限定したもの∑∑
s|Mts \ Or |r∈R |Or ∩ Mt |∗∑SR t =, SR t = ∑r∈R
r∈R |Or |r∈R |M \ Or |何か?
前述した，提案手法による MAP の向上がどのような要因によって起こったのかを詳細に知るために，いくつかの分析を行った．

5.5.1 不吉な臭いの分布提案手法がなぜ効果的に機能したかを直感的に示すために，バグレポートに対して実際に変更されたモジュール

c 2016 Information Processing Society of Japan⃝を求めた．ここで，Mts は種類 t の不吉な臭いを持つモジュールの集合を指す．
結果を表 7 に示す．この表では，検出された不吉な臭いのみを表記している． 表の値より，クラスレベルでは

God Class，メソッドレベルでは Blob Operation が多く検出されていることが分かる．これらは主に規模に関する臭7

情報処理学会論文誌

表 61Vol.57 No.1 1–11 (Jan. 2016)1

不吉な臭いを含むモジュールの割合

Table 6 Ratios of modules having a code smell.
0.8

SR

SR ∗

ArgoUML

21.43%

JabRef36.07%

プロジェクト

メソッドレベル

SR

SR ∗

4.11%

7.10%

3.99%

9.03%

11.11%

2.77%

jEdit

51.14%

9.13%

15.57%

3.25%

muCommander

31.71%

6.59%

7.22%

1.35%

全プロジェクト32.63%

5.86%

9.52%

3.26%

0.6

ΔAP

クラスレベル

0.4

0.2

0

-0.2

表 7

不吉な臭いを含むモジュールの割合（種類ごと）

Table 7 Ratios of modules having a code smell per type.

メソッドレベル

クラスレベル

粒度

不吉な臭いの種類

SR t

図 4 ArgoUML でのバグレポートごとの AP の変化

Fig. 4 Delta of AP for each bug report of ArgoUML.

SR ∗t

God Class25.59%

3.09%

Blob Class

7.04%

0.72%

5.5.2 バグレポートごとの AP の調査

Schizophrenic Class

4.23%

0.96%

図 4 は，ArgoUML においてクラスレベルの Bug Local-

Refused Parent Bequest

0.70%

0.12%

ization を行った際に，既存の IR 手法（α = 0）に比べてTradition Breaker

0.23%

0.37%

提案手法（α = 0.42）がどの程度 AP を上昇させたかを示

Data Class

0.23%

1.31%

したものである．横軸はそれぞれのバグレポート，縦軸はBlob Operation

7.00%

1.06%

Intensive Coupling

2.51%

0.64%

Internal Duplication

0.36%

0.84%

Sibling Duplication

0.36%

0.37%

グラフから，それぞれのバグレポートがバランスよく AP

Feature Envy

0.36%

0.10%

を向上させたわけではなく，偏りがあることがわかる．まData Clumps

0.00%

0.44%

た，中央付近には変化がほとんど見られないバグレポート

External Duplication

0.00%

0.32%

があり，右端の AP 減少量は左端の AP 上昇量に比べて小Shotgun Surgery

0.00%

0.01%

さい．0.01 以下の微小な変化を無視したとして，∆AP が

AP の上昇量（∆AP = AP α=0.42 − AP α=0 ）を表しており，∆AP が高い順に左からバグレポートを並べている．

0.01 より大きい（増加）バグレポートは 20，−0.01 より小いであり，正解セットに特に多く含まれるこれらの不吉なさい（減少）バグレポートは 17 あり，減少したものよりも臭いが結果に寄与していることは，規模の大きいモジュー増加したものが多かった．また，AP の定義により，∆AP

ルから多くのバグが検出されているとみることもでき，この値には上位の正解モジュールの順位変動が強く影響し，れは驚くべき結果ではない．しかし，Schizophrenic Class

下位の正解モジュールの順位変動の影響が小さい．これら

や Instensive Coupling など，必ずしも規模のみに関連すのことから，提案手法の導入が，ランキング上位の正解モるわけではない不吉な臭いも，正解セットから大きな割合

ジュールをより高い順位に引き上げる効果を与えたものとで検出されている．また，その他にも，多くの種類の不吉考える．

な臭いが正解セットに含まれている．このことは，必ずしも規模の観点に留まらない不吉な臭いが Bug Localization

提案手法では，精度低下を起こしたバグレポートよりも，の精度向上に貢献している可能性を示唆している．

精度向上を起こしたバグレポートが多数だった．また，

一方で，クラスレベルにおける Data Class などは，正解セットに含まれていないクラスで多く検出された．これ

精度向上例においては，ランキング上位の正解モジュー
ルをより高順位に引き上げていた．

は，Data Class が振る舞いよりもデータの管理に特化したモジュールに対する不吉な臭いであり，バグ修正の際の変5.6 妥当性の脅威

更対象とはなりづらいことに起因するかもしれない．この

内的妥当性．本実験では 4 つのプロジェクトを用いたような種類の不吉な臭いは，提案手法における検出対象かが，プロジェクトのバグレポートやソースコードの質が脅ら除くことで，さらなる精度の向上が可能かもしれない．

威となる．バグレポートの質が悪ければ悪いほど，既存の正解セットに含まれるモジュールは多くの種類の不吉な臭いを持っており，それらのうち不吉な臭いを持つものの割合は，正解セットに含まれないモジュールのうち臭いを持つものの割合よりも大きかった．

c 2016 Information Processing Society of Japan⃝IR 手法の重要度が下がる．また，ソースコードの質が悪け
れば悪いほど，不吉な臭いが多く検出される可能性が高い
ため，不吉な臭いの重要度が上がる．しかし，データセッ
トとして整備されているプロジェクトのバグレポートやソースコードを用いたため，この脅威は小さいと考える．

8

情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

さらに，不吉な臭いはいくつかのソフトウェアメトリクスがある．IR 手法に実行情報や過去の変更履歴などの追加を元に検出されるため，不吉な臭いの情報ではなく，ソフ的な情報を組み合わせた手法に対しても，不吉な臭いの深

トウェアメトリクスが Bug Localization に効果的であった

刻度を組み合わせた際に精度が向上するかを検証すること可能性がある．そのため，ソフトウェアメトリクスについが望ましい．

ても同様の検証を行う必要がある．

ソフトウェアメトリクスを用いた検証． 不吉な臭いは外的妥当性．本実験ではソースコードが Java 言語で書ソフトウェアメトリクス，特にプロダクトメトリクスを元かれているプロジェクトに関して検証したが，他のプログに検出されている．プロダクトメトリクスとはソースコー

ラミング言語でも同じように手法を用いて MAP が上がる

ド上のモジュールの特性を定量化した尺度であり，例えばとは限らない．また，4 つのプロジェクトに対してしか検行数を示す Lines of Code（LOC）やメソッドの数を示す証できていないため，どのようなプロジェクトでも MAP

Number of Methods（NOM）などがある．こういったメが向上するとは言えない．そのため，他のプログラミング

トリクスの組み合わせに基づき，不吉な臭いが定義されて言語や他の多くのプロジェクトで検証する必要がある．

いる [32]． 不吉な臭いそのものではなく，ソフトウェア

6. おわりに
本論文では，Bug Localization 手法の中でも基盤となる

IR 手法に対して，不吉な臭いの情報を組み合わせた新しい

メトリクスが Bug Localization を改良した可能性もあるた
め，ソフトウェアメトリクスを用いた，同様の検証を行い分析することで，Bug Localization を改良した要因を明らかにすることができる．

メトリクス及びそれを用いたモジュールの推薦手法を提案

提案手法の改良．現在利用している不吉な臭いは，Bug

した．4 つのプロジェクト，クラスレベルとメソッドレベ

Localization の対象モジュール粒度と同じ粒度の不吉な臭ルの 2 粒度に関して，既存の IR 手法と提案手法を比較しいのみである．しかし，対象モジュール粒度に限らない粒たところ，既存の IR 手法に比べて MAP の向上が見られ，度の不吉な臭いを用いることで，精度を改善できる可能性

それぞれの粒度に関して，平均 22%，137%の向上がみらがある．

れた．また，どのプロジェクトに関しても MAP の向上が謝辞みられた．本手法で用いた不吉な臭いはソースコードのみ

本研究の一部は，日本学術振興会科学研究費補助金を入力とするため，IR 手法を適用できる状況では適用が可（JP15K15970，JP15H02683，JP15H02685，JP18K11238）

能である．すなわち，これまでに IR 手法をベースの手法の助成を受けた．

とした発展的な Bug Localization 手法においても，ベースとする IR 手法として本論文の提案手法を用いることが可能である．
本論文の今後の課題を以下に挙げる．

付録

A.1 検出される不吉な臭い

パラメータ α のより厳密な設定．提案手法を実際に用い表 A·1 には，inFusion により検出される，オブジェク

るためには，パラメータ α の値を定める必要がある．例え

ト指向言語を対象とした，粒度がクラスレベルとメソッド

ば，対象プロジェクトの過去のバグレポートとその際に変レベルの不吉な臭いとそれらの説明が含まれている．

更されたモジュールの情報を用いて，RQ 1 での調査と同様に α の最適値を計算しておくことにより，プロジェクト特参考文献

有の α を得られると考える．こういった試みを含めた，パ[1]

ラメータ調整のための枠組みが必要である．
より多くの評価実験の実施．本論文での評価では 4 つの[2]

プロジェクトのみを対象としており，またそれらのいずれも Java 言語を用いたものである．そのため，本手法がどのようなプロジェクトに対しても効果的な手法であることを十分には示せていない．より多くのプロジェクトに関し[3]て提案手法を検証し，効果的であることを示す必要がある．
また，Zhou ら [22] が Bug Localization 手法の評価をする
ためのデータセットを提案しており，提案手法もこういっ[4]たデータセットを用いて評価したい．さらに，本論文ではIR 手法のみに不吉な臭いの深刻度を組み合わせた手法が精度向上に繋がることを示したものの，IR 手法よりも高精度の手法に対しても同様に精度が向上することを示す必要

c 2016 Information Processing Society of Japan⃝[5]

Lucia, Thung, F., Lo, D. and Jiang, L.: Are faults localizable?, Proc. 9th Working Conference on Mining Software Repositories, pp. 74–77 (2012).
Nguyen, A. T., Nguyen, T. T., Al-Kofahi, J., Nguyen,
H. V. and Nguyen, T. N.: A topic-based approach fornarrowing the search space of buggy files from a bug
report, Proc. 26th International Conference on Automated Software Engineering, pp. 263–272 (2011).
Marcus, A., Sergeyev, A., Rajlich, V. and Maletic, J. I.:
An information retrieval approach to concept location insource code, Proc. 11th Working Conference on Reverse
Engineering, pp. 214–223 (2004).
Gay, G., Haiduc, S., Marcus, A. and Menzies, T.: On
the use of relevance feedback in IR-based concept location, Proc. 25th International Conference on Software
Maintenance, pp. 351–360 (2009).
Weiser, M.: Programmers use slices when debugging,
Communications of the ACM, Vol. 25, No. 7, pp. 446–

9情報処理学会論文誌

Vol.57 No.1 1–11 (Jan. 2016)

表 A·1

inFusion により検出される不吉な臭い

Table A·1 Code smells detected by inFusion.

メソッドレベル

クラスレベル

粒度

[6]

[7]

[8]

[9]

[10]

[11]

[12]
[13]

[14]

[15]

種類

説明

Blob Class [12, 32, 33]

非常に大きく複雑なクラス

Data Class [12, 32, 34]

機能を持たずデータばかりを持ち，他クラスから頻繁に参照されるクラス

Distorted Hierarchy [34]継承階層が非常に狭く深いクラス

God Class [12, 32, 34]

他クラスが持つデータを処理するクラス

Refused Parent Bequest [32, 34, 35]

基底クラスから継承するメンバをほとんど使わないクラス

Schizophrenic Class [34, 35]

複数の概念を表現しているクラス

Tradition Breakers [32, 34]

基底クラスが定める規約に違反するクラス

Blob Operation [12, 32, 33]

大きく複雑なメソッド

Data Clumps [12]数個のデータがグループとして現れているメソッド

External Duplication [12, 33, 36]

関係性の無いクラスとの間に重複したコードを含むメソッド

Feature Envy [12, 32, 34]

自クラスのデータより他クラスのデータとの関連性が高いメソッド

Intensive Coupling [12, 32, 34]

他の多くのメソッドに対して，結合性が高いメソッド

Internal Duplication [12, 33, 36]

同一クラス内に重複したコードを含むメソッド

Message Chains [12, 32, 33]

連鎖的に多くのメソッド呼び出しが起こるメソッド

Shotgun Surgery [12, 32]

変更をする際に，多くの他のメソッドに変更が伝播するメソッド

Sibling Duplication [12, 33, 36]

兄弟クラス間に重複したコードを含むメソッド

452 (1982).
Dao, T., Zhang, L. and Meng, N.: How does execution
information help with information-retrieval based bug
localization?, Proc. 25th International Conference on
Program Comprehension, pp. 241–250 (2017).
Wong, C.-P., Xiong, Y., Zhang, H., Hao, D., Zhang,
L. and Mei, H.: Boosting bug-report-oriented fault localization with segmentation and stack-trace analysis,
Proc. 30th International Conference on Software Maintenance and Evolution, pp. 181–190 (2014).
Saha, R. K., Lease, M., Khurshid, S. and Perry, D. E.:
Improving bug localization using structured information
retrieval, Proc. 28th International Conference on Automated Software Engineering, pp. 345–355 (2013).
Wang, S. and Lo, D.: Version history, similar report, andstructure: Putting them together for improved bug localization, Proc. 22nd International Conference on Program Comprehension, pp. 53–63 (2014).
Youm, K. C., Ahn, J. and Lee, E.: Improved bug localization based on code change histories and bug reports,
Information and Software Technology, Vol. 82, pp. 177–
192 (2017).
Takahashi, A., Sae-Lim, N., Hayashi, S. and Saeki, M.:
A preliminary study on using code smells to improve
bug localization, Proc. 26th International Conference
on Program Comprehension, pp. 324–327 (2018).
Fowler, M.: Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional (1999).
Yamashita, A. and Moonen, L.: Do code smells reflect
important maintainability aspects?, Proc. 28th International Conference on Software Maintenance, pp. 306–
315 (2012).
Yamashita, A. and Moonen, L.: Exploring the impact
of inter-smell relations on software maintainability: An
empirical study, Proc. 35th International Conference on
Software Engineering, pp. 682–691 (2013).
Fontana, F. A., Ferme, V., Zanoni, M. and Roveda, R.:
Towards a prioritization of code debt: A code smell
intensity index, Proc. 7th International Workshop on
Managing Technical Debt, pp. 16–24 (2015).

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

c 2016 Information Processing Society of Japan⃝

Marinescu, R.: Assessing technical debt by identifying
design flaws in software systems, IBM Journal of Research and Development, Vol. 56, No. 5, pp. 9–1 (2012).
Khomh, F., Di Penta, M., Guéhéneuc, Y.-G. and Antoniol, G.: An exploratory study of the impact of antipatterns on class change-and fault-proneness, Empirical Software Engineering, Vol. 17, No. 3, pp. 243–275(2012).
Palomba, F., Bavota, G., Di Penta, M., Fasano, F.,
Oliveto, R. and De Lucia, A.: On the diﬀuseness andthe impact on maintainability of code smells: A large
scale empirical investigation, Empirical Software Engineering, Vol. 23, No. 3, pp. 1188–1221 (2018).
Lukins, S. K., Kraft, N. A. and Etzkorn, L. H.: Bug localization using latent dirichlet allocation, Informationand Software Technology, Vol. 52, No. 9, pp. 972–990(2010).
Poshyvanyk, D., Marcus, A., Rajlich, V., Gueheneuc,
Y.-G. and Antoniol, G.: Combining probabilistic ranking and latent semantic indexing for feature identification, Proc. 14th International Conference on Program
Comprehension, pp. 137–148 (2006).
Rao, S. and Kak, A.: Retrieval from software libraries
for bug localization: A comparative study of generic andcomposite text models, Proc. 8th Working Conferenceon Mining Software Repositories, pp. 43–52 (2011).
Zhou, J., Zhang, H. and Lo, D.: Where should the bugs
be fixed? More accurate information retrieval-based bug
localization based on bug reports, Proc. 34th International Conference on Software Engineering, pp. 14–24(2012).
Kim, D., Tao, Y., Kim, S. and Zeller, A.: Where should
we fix this bug? A two-phase recommendation model,
IEEE Transactions on Software Engineering, Vol. 39,
No. 11, pp. 1597–1610 (2013).
Le, T.-D. B., Thung, F. and Lo, D.: Will this localization tool be eﬀective for this bug? Mitigating the impactof unreliability of information retrieval based bug localization tools, Empirical Software Engineering, Vol. 22,
No. 4, pp. 2237–2279 (2017).
Chaparro, O., Florez, J. M. and Marcus, A.: Using10

情報処理学会論文誌

[26]

[27]

[28]

[29]

[30]

[31]

[32]
[33]

[34]
[35]
[36]

Vol.57 No.1 1–11 (Jan. 2016)

Observed Behavior to Reformulate Queries during Text
Retrieval-based Bug Localization, Proc. 33rd International Conference on Software Maintenance and Evolution, pp. 376–387 (2017).
Acharya, M. and Robinson, B.: Practical change impact
analysis based on static program slicing for industrial
software systems, Proc. 33rd International Conference
on Software Engineering, pp. 746–755 (2011).
Naish, L., Lee, H. J. and Ramamohanarao, K.: A model
for spectra-based software diagnosis, ACM Transactions
on Software Engineering and Methodology, Vol. 20,
No. 3, pp. 11:1–11:32 (2011).
Tantithamthavorn, C., Ihara, A. and Matsumoto, K.:
Using co-change histories to improve bug localization
performance, Proc. 14th International Conference on
Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, pp. 543–548(2013).
Shi, Z., Keung, J., Bennin, K. E. and Zhang, X.: Comparing learning to rank techniques in hybrid bug localization, Applied Soft Computing, Vol. 62, pp. 636–648(2018).
Dit, B., Moritz, E. and Poshyvanyk, D.: A TraceLabbased solution for creating, conducting, and sharing
feature location experiments, Proc. 20th International
Conference on Program Comprehension, pp. 203–208(2012).
Dit, B., Revelle, M., Gethers, M. and Poshyvanyk, D.:
Feature location in source code: A taxonomy and survey,
Journal of Software: Evolution and Process, Vol. 25,
No. 1, pp. 53–95 (2013).
Lanza, M. and Marinescu, R.: Object-Oriented Metrics
in Practice, Springer Science & Business Media (2007).
Brown, W. H., Malveau, R. C., McCormick, H. W. andMowbray, T. J.: AntiPatterns: Refactoring Software,Architectures, and Projects in Crisis, John Wiley &Sons, Inc. (1998).
Riel, A. J.:
Object-Oriented Design Heuristics,
Addison-Wesley (1996).
Martin, R. C.: Agile Software Development: Principles,
Patterns, and Practices, Prentice Hall (2007).
Hunt, A. and Thomas, D.: The Pragmatic Programmer:
From Journeyman to Master, Addison-Wesley (2000).

セーリム ナッタウット
2012 年キングモンクット工科大学ラカバン校工学部コンピュータ工学科
卒業．2016 年東京工業大学大学院情報理工学研究科計算工学専攻修士課程修了．現在，同大学情報理工学院情報工学系博士後期課程在学中．修士（工学）．ソースコードの不吉な臭いに関する研究に従事．

林 晋平 （正会員）
2008 年東京工業大学大学院情報理工学研究科計算工学専攻博士後期課程修了．2009 年同専攻助教．2018 年同大学情報理工学院准教授．博士（工学）．
ソフトウェア変更やソフトウェア開発環境の研究に従事．電子情報通信学会，日本ソフトウェア科学会，IEEE-CS，ACM 各会員．

佐伯 元司 （正会員）
1983 年東京工業大学大学院工学研究科情報工学専攻博士後期課程修了．同
大学助手，助教授を経て，2000 年同大学大学院情報理工学研究科計算工学専攻教授．現在，同大学情報理工学院教授．工学博士．要求工学やソフトウェ
ア開発技法等の研究に従事．電子情報通信学会，人工知能学会，日本ソフトウェア科学会，IEEE，ACM 各会員．

高橋 碧 （学生会員）
2018 年東京工業大学工学部情報工学科卒業．現在，同大学情報理工学院
情報工学系修士課程在学中．学士（工学）．Bug Localization に関する研究に従事．IEEE 会員．

c 2016 Information Processing Society of Japan⃝

11