日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

バグ情報を含むソフトウェアの視覚化
前田 竜馬

丸山 勝久

ソフトウェア理解において，ソフトウェアの構造や特性の視覚化は有益である．しかしながら，これらの情報とバグ情報を同時に視覚化するツールは実現されていない．本論文では，バグ情報として Google Bugspots によるバグの潜在度を視覚化できる CodeForest を提案する．

を備えたツールを，保守者が容易に利用できる環境は1 はじめに存在しない．

大規模化・複雑化したソフトウェア保守において，

本論文では，ソフトウェアの構成や特性といった従そのソフトウェアを理解する手間はますます増加し来の視覚化情報に，バグに関する情報を追加した視覚ている．このような理解作業におけるメンタルモデ化ツールを提案する．具体的な実装として CodeForest

ルの構築 [6] を支援するという観点から，ソフトウェを基盤とし，3 次元メタファーおよび視覚化パラメーア視覚化ツールが有効であるといわれている [2] [4]．
たとえば，CodeCity [7] [8] や CodeForest [5] [9]†1 は，タはそのまま利用する．保守者は，視覚化対象の情報ソフトウェアのソースコードに対して，さまざまなメスに加えて，Google Bugspots により提供されるバトリクスを適用することでその構造や特性を測定し，グ情報を指定することができる．

それらの測定値を直感的に理解しやすい 3 次元メタファーにより表現する．

として，すでに実装されているソフトウェアメトリク

このような視覚化ツールを提供することで，ソフトウェアに関する特定の構造や特性と，バグの潜在可能

一方，ソフトウェア保守にはバグ修正も含まれる．

性や修正頻度との相関を把握することが容易になる

一般的に，バグ修正などの情報は版管理システムや可能性がある．これにより，従来とは異なる観点でリバグトラッキングシステムに蓄積されている．また，ファクタリングの手がかりを見つけることを支援でGoogle Bugspots [3] では，過去に実施されたバグ修きる．たとえば，サイズの大きなモジュール（たとえ正から，現在バグが潜在している可能性があるソースば，Java プログラムのクラスやメソッド）を単純にファイルを推測する．このような状況において，保守リファクタリング対象とするのでなく，そのようなモ者がソフトウェアの構造や特性とバグやその修正情報

ジュールのバグ修正の頻度や時期に応じてリファクタを同時に見たいという要求を持つことは自然である．

リングの適用を先延ばしにするなどが考えられる．

しかしながら，筆者らの知る限り，このような視覚化

2 視覚化ツール
Presenting Bug Information in Software Visualization
Tatsuma Maeda, 立命館大学大学院情報理工学研究科,
Graduate School of Informamtion Science and Engineering, Ritsumeikan University.
Katsuhisa Maruyama, 立命館大学情報理工学部, Department of Computer Science, Ritsumeikan University.
†1 http://www.fse.cs.ritsumei.ac.jp/codeforest/

ここでは，まず CodeForest における視覚化手法を説明する．その後，新たに追加するバグ情報として利用する Google Bugpots を説明する．最後に，バグ情報を CodeForest に組み込む手法を提案し，その実装を述べる．

図1

CodeForest における視覚化の例

2. 1 CodeForestCodeForest は，Java プログラムのクラスを一つの木，森を木の集合体で表現するツールである．ビ

表 1 CodeForest が提供するクラスに関するメトリクスの一覧
略称概要

LOC

コードの行数
他のパッケージを利用しているクラスの数
他のパッケージから利用されているクラスの数
サブクラスの数
フィールドの数
メソッドの数(メソッド+フィールド) の数
公開メソッドの数
ステートメントの数
クラスの結合関係
クラス階層内での深さ
メソッド凝集の欠如
呼び出すメソッドの数
重み付きメソッドの数

ルディングなどのような立方体を用いた 3 次元メタファーでは，通常 3 つの軸と色で構成された 4 つのNOACL視覚化パラメータを提供している．それに対して，

NOECL

CodeForest では木を用いた 3 次元メタファーを用い

NOC
NOFD
NOMD
NOMF
NOPM
NOST
CBO
DIT
LCOM
RFC
WMC

ることで，同時に表現できる視覚化パラメータの数を増やしている．図 1 に，CodeForest による視覚化の様子を示す．

Forest view における木は，クラスに関する情報を提示する．木を取り囲む四角形はパッケージを表す．

Tree view における木は，クラスの詳細情報を提供する．この木の枝は，クラス内部に存在するメソッドに対応している．利用者は，Forest view 内の木を左クリックすることで，Tree view に表示される木を切り

Properties view は，これらのメトリクス値を提供す替えることができる．Source code view は，利用者がる．CodeForest が扱うソフトウェア（プロダクト）選択した木のクラスのソースコードを提供する．

メトリクスを表 1 に示す．ソフトウェアメトリクスとCodeForest は，Java プログラムのソースコードを読み込み，それを解析することで，プログラムはソフトウェアの品質を定量的に評価するための尺度のことである．に汎用的なメトリクスとオブジェクト指向プログラ

Setting view により，利用者は，Forest view に表示

ム向け CK メトリクス [1] の値をそれぞれ計算する．

される木に対する視覚化パラメータにメトリクス（の図2CodeForest の視覚化パラメータ値）を自由に設定することができる．6 つの視覚化パラメータを図 2 に示す．たとえば，図 1 では，木の図3

Google Bugspots における ti と Scorei の関係

幹の高さ (Trunk height) にクラス内部のコードの行（文献 [3] から引用）

数 (LOC) を割り当てている．このような視覚化では，大規模なクラスを見つけるためには，幹の長い木を探化した値を指す．ti の計算式を次に示す．

せばよい．この視覚化パラメータを公開メソッドの数

ti =(NOPM) に変更することで，木の形は変化する．このような視覚化パラメータの設定は，ユーティリティクラスを探す際に有効かもしれない．

d − didd はソースファイルを作成してから現在までの経過時間（d ̸= 0），di は i 番目のバグ修正から現在までの経過時間を指す．i 番目のバグ修正がファイル作成

2. 2 バグ情報に近いほど ti の値は 0 に近づき，バグ修正が最近で本研究で扱うバグ情報とは，修正されたことがリあるほど ti の値が 1 に近づく．

ポジトリに記録されているバグ（修正バグ）に関す

ti と Scorei の関係は図 3 のようになる．この図をる情報である．このような情報は，版管理システム見れば分かるように，バグ修正が最近であればある（Subversion や Git）とそれに付随するバグトラッキ

ほど，Scorei の値は指数的に増加する．ここで，HSングシステムから取得する．本研究では，CoreForestは個々のバグ修正に関する Scorei の総和となっていの提供する 14 種類のメトリクスに対して，Googleる．よって，HS の計算において，最近のバグ修正はBugspots から得られるバグ情報のメトリクスを追加支配的である．

する．

Google Bugspots では，「バク修正のために頻繁に2. 3 実装更新（コミット）されるファイルには，その修正が最本研究では，Google Bugspots におけるバグの潜近であるほど，バグが含まれる可能性が高い」という

在度 HS を視覚化パラメータとして指定できるよう前提のもとに，次の計算式を用いて，プログラムにに CodeForest を拡張した．HS の値を計算するアルゴリズムの実装は公開されている †2 ．

おける各ソースファイルのバグの潜在度 HS を計算する．

HS =この実装を用いることで，図 4 のような情報を含む
n∑i=0

Scorei =n∑
i=0

1
1 + e−12ti +12

Scorei は i 番目のバグ修正に関するスコア，n はバグ修正のコミット数，ti はバグ修正のための i 番目のコミットのタイムスタンプを 0 から 1 の範囲に正規テキストファイルが得られる．ここで，CodeForestの拡張において必要であるのは，各ソースファイルとその HS の値（図 4 における Hotspots の部分）である．そこで，もとの出力から正規表現を用いて，こ†2 https://github.com/igrigorik/bugspots

3 おわりに
本論文では，バグ情報として Google Bugspots の値を取り上げ，その情報を視覚化する CodeForest を提案した．このような拡張により，バグの潜在度とその他の特性との相関を調査したり，バグの潜在度に基づくファクタリング箇所の特定や優先度付けを支援できる可能性がある．今後の課題として，これらの利用シーンの具体化や評価実験を考えている．
謝辞 本研究に関してご討論頂きました，立命館大
学の紙名哲生氏に感謝いたします．本研究の一部は，立命館大学の 2015 年度研究推進プログラムの助成を
図4

Google Bugspots の出力（一部）の情報を抽出するモジュールを作成した．
ここで，CodeForest は，新たなメトリクスの視覚化を容易に追加できるように設計されている．追加するメトリクスを管理するクラスは，インタフェー
ス org.jtool.codeforest.metrics.IMetric を 実装する必要がある．実際には，このインタフェースを実装するデフォルトのクラス org.jtool.codeforest.

metrics.Metric が用意されているため，このクラスを継承すればよい．
本研究で追加するバグの潜在度は，ソースファイルに関係する値である．一方，CodeForest では，Javaクラスをひとつの木で表現する．そこで，あるクラスの HS の値は，そのクラスの記述を含むソースファイルの値と同一とすることにした．Java プログラムの場合，単一のクラスは単一のファイルに記述されることが多いので，このような方針で問題ないと考えた．
また，CodeForest では，表示する木のバランスを自動的に調整するため，HS の値だけでなく，その最大値と合計値を取得できるようにしておく必要がある．ここでは，クラスが属するパッケージを単位として，HS の最大値と合計値を計算した．

受けたものである．

参 考 文 献[1] Chidamber, S. R. and Kemerer, C. F.: A
Metrics Suite for Object Oriented Design, IEEETransactions on Software Engineering,, Vol. 20,No. 6(1994), pp. 476–493.
[2] Diehl, S.: Software Visualization: Visualizing theStructure, Behaviour, and Evolution of Software,Springer, 2007.
[3] Google Engineering Tools: Bug Prediction atGoogle. http://google-engtools.blogspot.jp/2011/12/
bug-prediction-at-google.html.
[4] Koschke, R.: Software Visualization in Software Maintenance, Reverse Engineering, and Reengineering: A Research Survey, Journal of Software Maintenance, Vol. 15, No. 2(2003), pp. 87–109.
[5] Maruyama, K., Omori, T., and Hayashi, S.: A
Visualization Tool Recording Historical Data ofProgram Comprehension Tasks, ICPC’14, 2014,pp. 207–211.
[6] Storey, M.-A.: Theories, tools and researchmethods in program comprehension: past, presentand future, Software Quality Journal, Vol. 14,
No. 3(2006), pp. 187–208.
[7] Wettel, R. and Lanza, M.: Visualizing Software
Systems as Cities, VISSOFT’07, 2007, pp. 92–99.
[8] Wettel, R., Lanza, M., and Robbes, R.: Software Systems As Cities: A Controlled Experiment,
ICSE’11, 2011, pp. 551–560.
[9] 轟大樹, 大森隆行, 丸山勝久: CodeForest: ソフト
ウェア構造・特性・依存の視覚化によるプログラム理解
支援, 2012.