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

JCompaths: 実行経路の比較と可視化を行うコードレ
ビュー向けツール
神田 哲也

橋本 悠樹

嶋利 一真

肥後 芳樹

ソフトウェア開発においてプログラム理解は重要なタスクの一つである．プログラム理解が重要な場面としてコードレビューが挙げられる．特に変更に対するレビューでは，ソースコードの差分以外にも前後の挙動を理解してプログ
ラムを読み進める必要がある．しかし，プログラムを実行することで得られる動的な情報に着目したレビューの支援
技術は少ない．そこで本研究では．didiﬀﬀ という既存のツールを拡張し，ソースコードの変更前後におけるメソッ
ドの実行の変化を可視化するツール JCompaths を作成した．このツールは，プログラム実行時に変数トークンがとった値の系列（トレース）に着目する．メソッドの実行を 1 回ずつ順に比較し，その実行経路とともにトレースの差分を表示することで，ソースコードの差分が実行に与えた影響を可視化する，また，JCompaths の有用性を評価するために被験者実験を行った．結果として，タスクの所要時間と点数，およびユーザビリティの総合スコアのいずれにおいても，JCompaths と他のツールとの間で統計的に有意な差は見られなかった．しかしながら，自由記述からは，JCompaths 独自の機能がユーザにとって役立つことが確認できた．

る必要がある．このような状況では，ソースコードの1 まえがき差分のみから得られる情報は限られている．そこで，ソフトウェア開発におけるプログラム理解のタス

テストケースを実行するなどして変数の値や実行のクの占める比重は大きい．Minelli らの調査 [10] では，経路がどのように変化したかを実例で確認すること

開発者は約 70% の時間をプログラム理解に費やしてが，プログラムの理解の助けになると考えられる．しいることが明らかになっている．

かし，そのような動的な情報の差分を可視化することソフトウェア開発において既存のプログラムの内に着目した研究は少ない．

容を理解する場面のひとつとして，コードレビューがプログラムの変更前後における実行の変化を可視化

挙げられる．コードレビューは，ソースコードの可読するために，我々は以前 didiﬀﬀ [7] を開発しツールデ性，保守性の向上や教育的な効果をもたらす．そのたモを行った．これは，Java プログラム実行時に，あめ，オープンソースのシステムから商業的なシステム

る変数がとった値の系列に着目し，ソースコードのの開発に至るまで広く実施されている [13]．コードレ

変更前後における動的・静的双方の変化を同時に示

ビューにおいて，特にバグ修正のような変更を扱う場

すツールである．このツールでは，繰り返し呼び出合，変更された箇所がどう書かれているかだけでなされるメソッドやメソッド内部の繰り返しにおける差く，差分の前後も含めたソフトウェアの挙動を理解す

分の表示に改善の余地があった．そこで本論文では，

didiﬀﬀ を拡張し，ソースコードの変更前後におけるJCompaths: A code review tool for comparing andvisualizing execution paths
Tetsuya Kanda, ノートルダム清心女子大学, Notre Dame
Seishin University.
Yuki Hashimoto, Yoshiki Higo, 大 阪 大 学, Osaka
University.
Kazumasa Shimari, 奈良先端科学技術大学院大学, Nara
Institute of Science and Technology.

メソッドの実行の変化を特に繰り返しに着目してより詳しく可視化できるツール JCompaths を提案する．
本論文は，上述のツールデモ論文 [7] を拡張したものである．本論文では，ツールデモで示したコンセプ
トをもとに改良を加え，また被験者実験を行いツールを利用することによるプログラム理解のタスクでの効果を評価している．評価実験では，JCompaths を

2. 2 実行の可視化に関する先行研究使った場合のタスクの結果を，didiﬀﬀ を使った場合

デバッグの支援を目的にプログラムの実行中の状の結果，および可視化ツールを使わなかった場合の結態を可視化を行うツールとして，デバッガがあり，C果と比較し評価を行う．タスク後にはアンケートをとや C++では GDB [4]，Java では jdb [12] などが代表

り，SUS と自由記述により，ユーザビリティの側面的である．これらは，ソースコード中の興味のある位からも評価を行う．

置にあらかじめブレークポイントを設定し，プログラ

以降，2 章では研究背景について，3 章では作成しムを 1 ステップずつ実行する中で，ステップごとに変たツールの仕様について述べる．4 章では作成した数の値やスタックフレームなどを可視化する．また，ツールの評価方法について，5 章ではその評価結果にプログラミング初学者の支援を目的に可視化を行う

ついて述べる．6 章ではツールの問題点について整理ツールとしては，Jeliot 3 [11] がある．このツールは，

し，最後に 7 章で本研究のまとめを行う．

Java プログラムの 1 ステップごとの実行を，自動でなお，ツールは GitHub 上で公開している †1 ．

再生されるアニメーションにより可視化する．

2 背景

Debugging [8] がある．この手法は，プログラム実行

この章では，本研究の背景として，コードレビュー

時のメモリの状態を網羅的に記録しておくことで，任や，プログラムの実行の可視化，ソースコードの差分

意の時点におけるプログラムの状態をあとから再現とプログラム実行の変化の可視化に関する先行研究

する．Omniscient Debugging によって得られた情報について述べる．

を可視化するツールとして，NOD4J [15] のビューア

これらのツールとは別の概念として Omniscient

コンポーネントがある．このビューアはブラウザ上で

2. 1 コードレビュー

動作し，ソースコード上の各変数トークンに対し記録

コードレビューとは，ソフトウェア開発において，された値を表示することができる．

ソースコードを変更した開発者以外が，そのソース

一方で，複数回の実行を可視化するための研究もおコードをチェックする作業のことである．この作業はこなわれている．Celine らは，大規模なリファクタ

ソースコードの可読性や保守性を向上させるだけでリングプロセスにおける振る舞いの変化を実行ログ

なく，教育的な側面をもち，オープンソースのシステから抽出し，グラフをハイライト表示することで可視

ムから商業的なシステムの開発に至るまで広く普及化している [2]．また，あるメソッドの複数回の実行している [13]．

における実行経路を可視化し比較するツールとして，

コードレビューで指摘すべき項目は多岐に渡る．ス

REMViewer [16] がある．ここでの実行経路とは，プ

ペルミスやコーディング規約違反などは，ソースコー

ログラム実行時にソースコードのある文が実行されたドのごく一部を見るだけで容易に指摘できるが，プロという記録を要素とした系列である．メソッドの複数

グラムの動作を十分に理解しないと指摘できないよ

回の実行をその実行経路の違いによって分類し，それうな項目も存在する．

ぞれの分類から 1 つの実行を可視化することで，実行

コードレビューでは，ソースコードの差分のみから経路と局所変数の状態を比較できる．我々の提案する得られる情報は限られている．そこで，コミットメッ

JCompaths はこの REMViewer による実行経路の可セージやプルリクエストの説明文など，ソースコード

視化機構を取り入れている．

を変更した開発者が静的な情報を補足することが一般的である．このような情報を自動的に生成する研究も行われている [5] [9]．

2. 3 ソースコードの差分と実行の変化を対応付けた可視化
我々は，ソースコードの変更前後におけるプログ†1 https://github.com/tetsuyakanda/jcompaths

ラムの実行を容易に比較するために，プログラムの実行の変化をソースコード上にマップして表示する

上にマップして表示するツールである．可視化におい

ツール didiﬀﬀ を提案した [7]．プログラムの実行の変て，Collector-Sahab のように差分が発生した点にの化は，プログラム実行時に変数トークンがとった値のみ注目するのではなく，全体の実行の情報を表示する

系列（トレース）について，ソースコードの変更前後

ことで，プログラム全体の動作を含めて差分の理解をでその内容を比較することで得られる．ここでの変数行えるようにすることを意図している．JCompaths

トークンとは，変数名を表すソースコード中の文字は，ソースコード変更前後のソースコードおよび実行列のことを指し，同じ変数でもソースコード中の出時情報を用いて，実行の変化の可視化を行う．具体的現場所が異なる場合，それらは異なる変数トークンには，プログラム実行時に変数トークンがとった値のとみなす．トレースの差分の有無はソースコード中の系列（トレース）に着目し，ソースコードの変更前後

変数トークンに色をつけてマッピングし，ソースコー

でその内容を比較する．ここでの変数トークンとは，ドの差分と合わせて表示することで，ソースコード

変数名を表すソースコード中の文字列のことを指し，の変更が各変数トークンに与える影響を可視化する．

同じ変数でもソースコード中の出現場所が異なる場

didiﬀﬀ は，ソースコードの差分と実行の差分を同一合，それらは異なる変数トークンとみなす．トレースのビューで可視化することで，開発者の理解を促進すの差分はソースコード中の変数トークンにマッピング

ることをコンセプトとしている．

し，ソースコードの差分と合わせてハイライトで表示

また，ソースコードの変更前後におけるプログラ

する．

ムの挙動の変化を検知するツールとして，Collector-

具体的なトレースの値は，ソースコード上の変数をSahab [3] が提案されている．このツールは，ソース

クリックすると横に用意された別のビューに表示されコードの変更前後におけるプログラムの実行を比較る．これにより，開発者はまず一般に用いられている

し，どちらか一方にしかない変数および返り値の状

ソースコードの差分表示を閲覧しながらソースコー

態を検出する．ここでの状態とは，＜行 , 変数, 値＞

ドの変更が各変数トークンに対する影響を大まかにの三つ組みである．また，Collector-Sahab は，オブ

理解し，その後ツール独自のビューを用いて具体的なジェクト内部の値について深さを指定してその範囲

変化の内容を探索できるように設計している．ソース

内でのプリミティブ型の値を取得している．このよ

コード上の変数をクリックすることによりトレースのうなデータの収集と計算により，差分の検出精度が値を表示する手法は NOD4J [15] のビューアコンポー

didiﬀﬀ よりも優れていることを示している．

ネントを参考にしており，本ツールではここに差分のCollector-Sahab の可視化は，上記の手順で得た変状態を示す色分けを加えている．

更前後どちらか一方にしかない状態を，ソースコード

JCompaths は既報の didiﬀﬀ のコンセプトをもとにの差分表示中に注釈の形で表示する．特異な状態に着改良を加えたものである．didiﬀﬀ がファイル単位での目してソースコードの差分に対する情報を補強する

差分計算結果を可視化していたのに対し，JCompathsという観点で設計されており，変更による影響箇所をはメソッド単位での差分計算をもとに可視化を行って効率的に検知することに重点を置いているといえる．

いる．これにより，複数回呼び出されるメソッドを呼一方我々の提案するツールは，実行トレース全体の可び出し単位で比較することが可能になっている．さら視化を行い，差分以外の部分についてもすべての変数に，REMViewer [16] の実行経路の可視化手法を，差トークンのステータスや値を可視化対象としている．

分の表現に対応させた上で取り入れることにより，あるメソッド実行内での繰り返しについても整理した

3 ツールの設計情報を提供することができる．この章では，ツール

JCompaths は，Java プログラムのソースコードの全体の設計としては didiﬀﬀ と重複する部分も記述し，変更前後におけるプログラムの実行を容易に比較す

JCompaths における拡張部分を JCompaths におるために，プログラムの実行の変化をソースコード

ける拡張として別段落で表記する．また，この拡張により見た目だけでなく提供する情報の品質が向上すは，実行前後の挙動の比較を行うにあたり着目すべきる例を 3. 4 節で説明する．

点を指し示すヒントとなる．ステータスは次の手順にツールは 3 つのコンポーネントから構成される．

従って決定する．

• 変更前後それぞれの実行時情報の取得および解析

1. ソースコード変更前，変更後ともにトレースの長• 変更前後間の差分計算• Web ビューアでの可視化
以下，それぞれについて詳しく説明する．

さが 0 である場合 no trace とする．

2. 変 数 ト ー ク ン が “delete” の 行 に 含 ま れ る 場
合 trace 1 only，“add” の行に含まれる場合

trace 2 only とする．
3. 1 変更前後それぞれの実行時情報の取得と解析

3. ソースコード変更前と変更後でトレースの長さ

Java プログラムの実行時に変数に関する情報を取が異なる場合（いずれか一方のトレースの長さが得し，解析を行う．実行時情報の取得には，NOD4J

0 の場合も含む）diff in length とする．

[15] と同様に SELogger を利用する．取得した実行時

4. （ソースコード変更前と変更後でトレースの長情報を，NOD4J の post processor を用いて，あるさが同じであり）変数トークンがプリミティブ型

変数トークンについて使用された際の値を記録する．

の変数でも String 型の変数でもない場合，same

プリミティブ型と String 型の変数トークンについて

length object とする．

はその値を，そうでなければ Object ID を記録する．

5. ソースコード変更前後のトレース内容を比較し，この結果得られる値の系列が変数トークンに対する一致する場合 no diff，そうでない場合 diff inトレースである．

JCompaths における拡張

trace とする．
トレース間の比較においては，同一かどうかの判定

メソッド単位での比較を可能にするため，NOD4Jのみを行い UNIX diﬀ のような差分については計算の post processor にメソッドの区切りを認識する機しない．ソースコードの変更により，実行時の値の系

能を追加する．この結果得られるトレースは，ある変列は長さ，内容ともに大きく変化し，また偶然部分的数トークンについて使用された際の値およびメソッドに一致する可能性もある．そのため，2 つの系列の違区切りからなる系列となる．

いを値のみをヒントに正確に特定することは難しい．
利用者に混乱を与えないため，差分計算は行わず，対3. 2 変更前後間の差分計算

応関係についてはビューアでの表示をもとに利用者が3. 2. 1 ソースコードの比較

判断する形をとることとした．

プロジェクト中の各ソースファイルについて，変更

JCompaths における拡張

前後のソースコードを Unix diﬀ に基づいて比較し，上記の比較は didiﬀﬀ ではある変数トークンのト

行ごとに差分のステータスを割り当てる．変更によりレース全体に対して行っていたが，メソッドが複数回削除された行は “delete”，変更により追加された行実行された場合にその何回目の実行における変化であは “add”，変更前後で共通する行は “unchanged”

るかを識別できない状態であった．JCompaths では，とする．このうち，“unchanged” の行に含まれる各メソッドの 1 回の実行ごとに比較を行いそれぞれに差トークンについて，ソースコード変更前のファイルに分のステータスを割り当てることでこの問題に対処しおけるトークンと変更後のファイルにおけるトークン

た．メソッド中の変数トークンが，そのメソッドの iが対応しているものとして扱う．

回目の実行でとった値の系列を，その変数トークンの3. 2. 2 トレースの比較

i 回目のトレースとする．このとき，ソースコード変ソースコード中の各変数トークンに対して，ソース

更前の i 回目のトレースと，変更後の i 回目のトレー

コード変更前のトレースと変更後のトレースを比較

スを比較し，上記の手順に従って定めるステータス

し，差分のステータスを割り当てる．このステータス

を，その変数トークンの i 回目のステータスと呼ぶ．

表1

変数トークンのステータスと色の対応

ステータス

ハイライト色“no trace”（ハイライトなし）“trace 1 only”“trace 2 only”

灰“no diﬀ”“same length object”
図1

JCompaths のビューアの概観

3. 3 Web ビューアでの可視化“diﬀ in length”

薄い青紫“diﬀ in trace”

ビューアは Node.js の環境下で実行され，Web ブ
ラウザで動作する．ビューアの概観を図 1 に示す．

JCompaths における拡張

ビューアは大きく分けて 3 つの部分に分かれており，

メソッド全体の繰り返しについての拡張

左から順に，ファイルツリービュー，ソースコード

差分計算における繰り返し実行への拡張を可視化に

ビュー，トレースビューとなっている．

3. 3. 1 ファイルツリービュー

反映させるため，可視化対象のメソッドを選択したう
えで特定の回の実行をビューに表示するようにした．

ファイルツリービューでは，ソースコードビュー

ファイル選択直後のソースコードビューを図 2 に示に表示するファイルをファイルツリーから選択する．

す．このビューでは，選択中のファイルにおけるソー

ファイル名の先頭には，そのファイルにおける差分のスコードの差分が表示され，選択可能なメソッドが 1

有無を表す 2 つの円が表示される．1 つ目の円は，ソーつずつ枠で囲まれている．枠の色は，そのメソッドにスコードの差分の有無を表し，ファイルに “delete”

おけるトレースの差分の有無を表す．メソッドのあるまたは “add” の行が含まれる場合は緑色になる．2

回の実行において，ステータスが “diﬀ in length” ま

つ目の円は，トレースの差分の有無を表し，ファイル

たは “diﬀ in trace” の変数トークンを含む実行が存に “diﬀ in length” または “diﬀ in trace” の変数トー在する場合，その枠は紫色になる．これにより，注目クンが含まれる場合は紫色になる．また，ディレクト

すべきメソッドを容易に発見できる．これらの枠を選

リについても，そのディレクトリ中にこれらの円が表択することで，ファイル中のどのメソッドの実行を比示されるべきファイルが含まれている場合に同様の較するかを指定する．この段階では，メソッドの何回円を表示し，ディレクトリ内部の差分の有無を表す．

目の実行を表示するかを決めていないため変数トーこれにより，注目すべきファイルへ容易にたどり着け

クンのハイライトは行わない．

ることをねらっている．

メソッド選択後のソースコードビューを図 3 に示

3. 3. 2 ソースコードビュー

す．まず，右上にそのメソッドの何回目の実行を比

ソースコードビューでは，ファイルビューで選択し較するかを選択するための表示を追加している．表

たファイルにおけるソースコードとその差分が表示さ示は左右の切り替えボタンと「表示中の実行回/総実

れる．ソースコードは，“delete” の行の背景が赤色，

行回数」を示す数字からなり，表示中の実行回の文“add” の行の背景が緑色となる．各変数トークンは，

字色が，その実行回におけるトレースの差分の有無

そのステータスに応じて表 1 に示す色でハイライトさを表す．メソッドが，i 回目のステータスが “diﬀ in

れる．このハイライトにより，差分があって注目すべ

length” または “diﬀ in trace” の変数トークンを含む

き変数トークンを容易に発見できるようにしている．

場合，実行回 i は紫色になる．これにより，注目すべ

変数トークンをクリックすることで，トレースビュー

き実行を容易に発見できる．

に表示させたい変数を選択できる．

ソースコード上での変数トークンのハイライトは，

図4

REMViewer [16] による実行経路の表示例のように矩形が表示されている．矩形は各行の実行に応じて垂直方向下向きに描画され，繰り返しによりプ
図2

ファイル選択後のソースコードビュー

ログラムの実行がソースコードの上方向に向かうときに水平方向右側の列に移動する．図 4 左側の矩形
は，図右側の数字 1 から 8 の順に実行されることを示しており，3 から 4，6 から 7 において繰り返しにより X 方向の座標が変化している．

JCompaths ではメソッド選択後のソースコード
ビューにおいて，その実行経路を REMViewer の矩形を 3 色に拡張して可視化する．赤の矩形はソース
コード変更前にのみ存在する実行経路，緑の矩形はソースコード変更後にのみ存在する実行経路，青の矩
図3

メソッド選択後のソースコードビュー

形はソースコード変更前後で共通する実行経路をそれぞれ表す．なお，矩形表示は，SELogger で記録さ選択されたメソッドの実行回における差分の状態を表れる全命令に対応する行番号にもとづいているため，している．“diﬀ in length” と “diﬀ in tarce” につい変数トークンが存在しない行についても表示される．

て，didiﬀﬀ では色を変えていたが，JCompaths では

矩形の表示例を図 5 の左側に示す．このソースコー

トレースの長さを別途 3. 3. 2 節で述べる矩形表示に

ドは，8 行目の for ループ内にある if 文の条件式が変より表現しているため同色で表示している．

更されたことで，9 行目の実行回数が変化している．

9 行目がソースコード変更前はループの 2，4，6 回目
メソッドの一部の繰り返しについての拡張

で，変更後はループの 3，6 回目で実行されたことがメソッドの一部の繰り返しについての拡張として，矩形から読み取れる．9 行目の濃くなっている青色の

REMViewer [16] の可視化技術を応用し，実行経路の矩形については次のトレースビューの項で説明する．

差分を表示する．これにより，トレースの各値がルー3. 3. 3 トレースビュー

プの何回目における値なのかを確認できるようにする．

最後に，トレースビューでは，選択中の変数トーク

まず，REMViewer による実行経路の可視化についンのステータスとトレースが表示される．トレースをて説明する．REMViewer では実行経路を可視化する

表示する列は左右 2 つあり，左側に並んでいる値がため，ソースコードの背景に矩形を表示する．表示ソースコード変更前のトレース，右側に並んでいる値

例を図 4 に示す．ここでは，for ループを含むソースが変更後のトレースである．変数トークンがプリミ

コードの実行を記録し，その結果各行に対して図左側

ティブ型，または String 型の変数の場合，その具体変数トークンとみなして具体的な値をトレースとして表示することができる．また，配列の長さを参照
するとき（array.length の形）にも，その具体的な値をトレースとして表示できるようにした．トレー
スビュー上では，図 5 右上のトグルボタンにより，配列のオブジェクト ID を表示するモード（Array ID）
図5

矩形とトレースの表示例と，具体的な値を表示するモード（Array Value）を切り替える．

的な値が表示されるが，それ以外の場合はクラス名とオブジェクト ID が表示される．

JCompaths における拡張

3. 4 JCompaths 拡張により可視化の品質が向上する例

トレースの長さが異なる場合など，どの値とどの値メソッドの繰り返しおよびメソッド内での繰り返を比べればよいかが不明瞭なことがある．そのようなしの差分に着目することにより可視化の品質が向上

状況での理解支援のため，ソースコードビューの矩形

する例を，Defects4J [6] に含まれる Math 82 を用いとトレースビューの値の対応関係を可視化する機能をて説明する．Defects4J は，OSS に生じた実際のバグ実装した．具体的には，ソースコードビューの矩形をからなるデータセットであり，デバッグ前後のソース

クリックにより選択可能とし，選択中の矩形に対応す

コードと，それを確認するためのテストケースが用意

るトレース中の値を，トレースビューにおいて赤字でされている．Math 82 のバグは，getPivotRow() メ表示するようにした．

ソッドの返り値が不正だったことに起因しており，同矩形の選択とトレースの例を図 5 を用いて示す．図では，トレースビューに 9 行目左辺の変数トークン

メソッドに含まれる条件式を書き換えることで，バグが修正されている．

sum を表示している．さらに，この図では 9 行目の青まず，didiﬀﬀ での可視化結果は図 6 のようになる．

の矩形が選択されており，ソースコード変更前後それ

図上側はソースコードビューで，利用者はソースコー

ぞれにおいて，この矩形に対応するトレース中の値がドの差分を頼りにこのファイルにたどり着き，ソー赤字になっている．それぞれの長さと矩形の数を比べ

スコードの差分をみて getPivotRow メソッドの近ることでも，左右のどの値を見比べればよいかを数え

辺を表示しているところである．図左下は，返り値ることは可能であるが，本拡張により対応関係を素早

minRatioPos のもととなる 86 行目の変数トークン i

く把握することができる．

を選択したときのトレースビューである．トレースよまた，didiﬀﬀ の場合，トレースビューには 1 つのり，i は 4 回目の参照までデバッグ前後で同じ値をと変数トークンに対するトレースしか表示されない．

り，5 回目から異なる値をとったことがわかる．一方，

JCompaths では複数の変数トークンを選択し，それソースコードより 86 行目の実行は 84 行目の条件式

らのトレースを同時に表示することができるようにで制御されている．そこで，84 行目の変数トークン

設計を見直した．上記の矩形は複数同時選択ができる

minRatio を選択したときのトレースビューが図右下ため，例えば for ループの特定回の矩形を選択するこである．変更によりトレースの長さが変化していることで，複数トークンにまたがって値の対応関係を把握とはわかるが，変数トークン i との対応が不明なたすることができる．

め，これ以上の考察は困難である．また，ソースコー

また，JCompaths は配列におけるトレースの表

ドビュー全体を眺めても，ほぼすべての変数トークン

示方法にも拡張を加えている．プリミティブ型の配が「記録されているトレースの長さが違う」を意味す

列について，配列中の特定の要素を参照するときる緑色の表示となっており，ソースコードの変更によ（array[index] の形）に，その要素の参照を 1 つのる影響が具体的にみてとれない．

図7
図6

JCompaths で可視化した Math 82 の実行

didiﬀﬀ で可視化した Math 82 の実行

同じ実行について，JCompaths で可視化するとクンの値の関係を確認することができている．また，

図 7 のようになる．図上側はソースコードビューで，ソースコードビュー全体を眺めても，この回のメソッ

利用者はソースコードの差分を頼りにこのファイル

ド実行において値が異なる部分が強調表示されておにたどり着き，同じくソースコードの差分をみてり，ソースコードの変更による影響が理解しやすい形

getPivotRow メソッドを選択している．このメソッになっている．

ドの 1 回目から 4 回目の実行においては，86 行目のこのように，JCompaths における拡張はメソッド

変数トークン i は灰色でハイライトされ，そのトレーの実行を 1 回ずつ順に比較し，矩形により実行経路

スに差分がなくメソッドの返り値に変化がないことがを表示することで，didiﬀﬀ に比べてトレースが整理わかったため，図に示す 5 回目の実行に切り替えていされ多くの情報を得ることができる．複数の変数トーる．図左下は，この 5 回目の実行において，86 行目

クン間における値の依存関係も明確になり，メソッドの変数トークン i を選択したときのトレースビューで全体の動きを捉えやすくなる．

ある．i のトレースより，i はソースコード変更前は

2，変更後は 5 をとったことがわかる．さらに，ソー4 ツールの評価方法

スコードビューの 86 行目の矩形により，これらの値

JCompaths の有用性を確認するための被験者実験はそれぞれ for ループの 2 回目，5 回目でとった値でを行った．この実験は以下の 2 点を確認することをあることがわかる．図右下は，84 行目の条件式内の目的としている．

変数トークン minRatio と ratio を選択したときの

1. ツールのコンセプトである，ソースコードの変更

トレースビューである．ソースコードビュー内で for

前後おいて，動的な情報を静的な差分にあわせてループの 2 回目の矩形を選択することで，図に示す

可視化することはその変化を理解する助けとなようにトレースビューの値も色が付けられ，ある行にるかおける変数トークンの値と別の行における変数トー

2. JCompaths における繰り返しを有するメソッド

に対する可視化の拡張は有効に働くか

表2

被験者ごとのタスク内容（使用するツール/対象のバ実験はタスクとその後のアンケートからなり，大阪

グ修正）

大学基礎工学部情報科学科の学生 4 名，大阪大学情

被験者

タスク 1

タスク 2

タスク 3

報科学研究科博士前期課程の学生 6 名の計 10 名を被A

G / バグ 1

D / バグ 2

J / バグ 3

験者とした．

B

G / バグ 3

J / バグ 1

D / バグ 2

C

G / バグ 2

D / バグ 3

J / バグ 1

4. 1 タスクによる評価

D

G / バグ 1

J / バグ 3

D / バグ 2

被験者には，デバッグによるメソッドの実行の変

E

D / バグ 1

J / バグ 2

G / バグ 3化について記述するタスクを，JCompaths を用いてF

D / バグ 3

G / バグ 1

J / バグ 2

行ってもらった．また，同じ実行時の差分を表示する

G

D / バグ 2

J / バグ 3

G / バグ 1

ツールとして didiﬀﬀ を，ソースコードの差分のみをH

J / バグ 1

G / バグ 2

D / バグ 3

表示するツールとして GitHub を用いて同様のタスI

J / バグ 3

D / バグ 1

G / バグ 2クを行ってもらい，タスクの所要時間，および点数をJ

J / バグ 2

G / バグ 3

D / バグ 1

JCompaths を用いたときのものと比較した．

A

G / バグ 1

D / バグ 2

J / バグ 3

4. 1. 1 バグ修正データの準備
バグ修正の内容や挙動の変化があまりにも単純な場
合，ツールの性能差が結果に表れない可能性がある．

ごとに変更した．表ではツール名を先頭 1 文字で略記している．

一方で，過度に複雑なバグ修正を扱ってしまうとツー

各タスクにおいて被験者には，修正されたバグのルの選択に関係なく理解が難しくなる恐れがある．

大まかな症状と被変更メソッドの大まかな仕様を記

そこで，メソッドの実行の変化について記述する対

載したドキュメントと，ツールにより表示されるソー象とするバグ修正は，Defects4J [6] から次の条件を全スコードの差分およびテストケースの実行の差分て満たすものを 3 つ選んだ．

（GitHub を除く）が与えられる．被験者にはこれら• バグ修正により書き換えられたメソッドがただを見たうえで，被変更メソッドの実行の変化について

1 つであり，かつそのメソッドが 20 行以上であ記述してもらった．記述対象として，メソッドの返りること．以下では，このメソッドを被変更メソッ

値や特定のフィールド変数など，バグにより不正な値

ドと呼ぶ．

をとっていた要素をあらかじめ指定した．デバッグの• 用意されたテストケースを実行したときに，ソー前後で同じテストケースを実行した際に，次の 3 つスコードに繰り返し実行される部分があること．

の項目について，被変更メソッドのみから読み取れる

選択した 3 つのバグ ID は，バグ 1：Chart5，バグ

2：Chart7，バグ 3：Chart11 である．

範囲内で記述するよう指示した．

1. 記述対象の値がデバッグの前後で異なるために，

4. 1. 2 タスクの手順

IN 要素が満たすべき必要十分条件．
（配点：2，部

被験者には，タスクを行う前に，各ツールの機能

分点あり）とタスクの内容を記したドキュメントを読んでもらった．ツールについては，サンプルのソースコードを対象として操作に慣れる時間を確保した．その後，3 つのタスクを，それぞれ異なるツールを用いて，それぞ2. 1. を満たすときの，記述対象のデバッグ前の値．
（配点：1）

3. 1. を満たすときの，記述対象のデバッグ後の値．
（配点：1）

れ異なるバグ修正を対象に行ってもらった．被験者間

ただし，IN 要素とは，被変更メソッドの外部で値がの能力差と，ツールの使用順序等による結果の偏りを決まる次の 3 つの要素を指す．

避けるため，使用するツールと対象のバグ修正の組み• 被変更メソッドの引数合わせ，およびその実施順序は表 2 のように被験者• 被変更メソッドの内部で読み出されるフィールド

変数• 被変更メソッドの内部で呼び出される別のメソッ
ドの返り値スコアを（回答）− 1 で定める．偶数番目は否定的な質問であり，各質問に対してそのスコアを 5 −（回答）で定める．こうして得られた各質問のスコアは，4 に各タスクは制限時間を 20 分とした上で所要時間を計近いほどユーザの満足度が高く，0 に近いほど低いこ

測し，記述の内容を 4 点満点で採点した．

とを表す．10 項目のスコアの総和を 2.5 倍し上限を

GitHub の差分表示は差分のあるソースファイルの100 としたものが SUS の総合スコアとなる．

みの表示であり，今回使用したデータは書き換えられ

自由記述では，各ツールに対し，タスクを行う上でたメソッドが 1 つのため注目すべきソースファイル便利だった点，不便だった点などについて記述してものみが表示されていることになる．この条件にあわらった．また，最後に実験全体についての感想を記述せて，被験者が JCompaths または didiﬀﬀ を使用すしてもらった．

る場合は，あらかじめ被変更メソッドをソースコード
ビューに表示させた状態でタスクを開始した．そのた

5 ツールの評価結果

め，ファイルやメソッドの選択に関連する機能につい4 章で説明した被験者実験の結果と考察を述べる．

ては，この実験での評価対象からは外れる．

5. 1 タスクの所要時間
4. 2 アンケートによる評価
タスクの実施後，被験者にアンケートをとり，タス

被験者がタスクを行うのにかかった時間について，
箱ひげ図によるツールごとの分布を図 8 に示す．平

クの内容を踏まえた上で，ユーザビリティの観点か

均値は，JCompaths が 14 分 31 秒，didiﬀﬀ が 16 分

ら JCompaths の性能を評価した．アンケートは，各35 秒，GitHub が 15 分 49 秒であった．JCompaths

ツールに対する SUS (System Usability Scale) [1] のと他のツールとの間で，平均値の差が統計的に有意質問と，自由記述からなる．

かを確かめるために，JCompaths の結果を対照群，

SUS は，ツールやシステムのユーザビリティ評価

didiﬀﬀ と GitHub の結果を処理群とみなし，Steel のするためののアンケート手法である．SUS は次の 10方法を用いて有意水準 5%の両側検定を行った．結項目の各質問に対し，1（全く思わない）から 5（強く果，didiﬀﬀ との比較では，統計検定量を td1 とする

思う）の 5 段階のリッカート尺度を用いて回答する．

と，|td1 | = 1.04 < d(3, ∞, 0.5; 0.05) = 2.21 より平Q1 このツールを頻繁に使用したいと思う．

均値に有意差は見られなかった．GitHub との比較

Q2 このツールは不必要に複雑だった．

では，検定統計量を tG1 とすると，|tG1 | = 0.66 <Q3 このツールが使いやすいと感じた．

d(3, ∞, 0.5; 0.05) = 2.21 より，こちらも平均値に有Q4 このツールを利用するには，技術者のサポートが意差は見られなかった．

必要だと思う．

Q5 このツールの様々な機能は上手くまとまっていると思う．

5. 2 タスクの点数
被験者のタスクの点数について，箱ひげ図によるツー

Q6 このツールは矛盾がとても多いと感じた．

ルごとの分布を図 9 に示す．平均値は，JCompaths

Q7 ほとんどの人がすぐ使いこなせるようになるツーが 1.4 点，didiﬀﬀ が 1.4 点，GitHub が 2 点であった．

ルだと思う．

JCompaths と他のツールとの間で，平均値の差が統Q8 このツールを使うのがとても面倒だと感じる．

計的に有意かを確かめるために，JCompaths の結果を

Q9 自信を持ってこのツールを操作できた．

対照群，didiﬀﬀ と GitHub の結果を処理群とみなし，

Q10 このツールを使いこなすには事前に多くの知識

Steel の方法を用いて有意水準 5%の両側検定を行っが必要だと思う．
奇数番目は肯定的な質問であり，各質問に対してそのた．結果，GitHub との比較では，検定統計量を tG2とすると，|tG2 | = 1.50 < d(3, ∞, 0.5; 0.05) = 2.21

1200

800

SUSスコア

所要時間（秒）

1000

600
400
200
0

JCompaths

図8

didiﬀﬀ

GitHub

タスクの所要時間の分布

JCompaths

図 10

didiﬀﬀ

GitHubSUS の総合スコアの分布

3 人が JCompaths，1 人が didiﬀﬀ，7 人が GitHub

4を最も高く評価しており，GitHub が優勢ではあるが3.5

個人差があった．

3

さらに，SUS の 10 個の質問それぞれについて，

2.5
得点

100
90
80
70
60
50
40
30
20
10
0

2

JCompaths と他のツールとの間でスコアの平均値の1.5

差が統計的に有意かを確かめるため，同様に有意水準

15%で Bonferroni 法による多重比較を行った．その結

0.5

果，3 つの質問に対して平均値の差が有意となるツー

0

JCompaths

didiﬀﬀ

GitHubルの組が存在することがわかった．これらの質問について，スコアの分布を図 11 に示す．

図9

タスクの点数の分布「Q1. このツールを頻繁に利用したいと思う」に対するスコアは，JCompaths の平均値が 2.9，didiﬀﬀ

より平均値に有意差は見られなかった．

の平均値が 2.1 であった．これらを比較したところ，

t(9) = 2.75, p = 0.022 < 0.025 より，平均値の差が5. 3 SUS のスコア有意であることがわかった．

被験者へのアンケートから得られた SUS の総合ス

「Q4. このツールを利用するには，技術者のサポーコアについて，箱ひげ図によるツールごとの分布を図トが必要だと思う」に対するスコアは，JCompaths の

10 に示す．平均値は，JCompaths が 63.25，didiﬀﬀ

平均値が 1.6，GitHub の平均値が 3.2 であった．これが 60.5，GitHub が 72 であった．JCompaths と他のらを比較したところ，t(9) = 3.36, p = 0.008 < 0.025

ツールとの間で，平均値の差が統計的に有意かを確か

より，平均値の差が有意であることがわかった．

めるために，有意水準 5%で Bonferroni 法による多重「Q10. このツールを使いこなすには事前に多くの知比較を行った．ただし，2 群間の比較は対応のある t

識が必要だと思う」に対するスコアは，JCompaths の検定（両側検定）により行った．結果，JCompaths と平均値が 1.9．GitHub の平均値が 3.3 であった．これ

didiﬀﬀ の比較では，t(9) = 0.67, p = 0.52 > 0.025 よらを比較したところ，t(9) = 4.12, p = 0.003 < 0.025

り平均値に有意差は見られなかった．JCompaths とより，平均値の差が有意であることがわかった．

GitHub の比較では，t(9) = 0.95, p = 0.37 > 0.025
より，こちらも平均値に有意差は見られなかった．また，各被験者が最も高く評価したツールに着目すると，

4
3.5
3
2.5
2
1.5
1

4
3.5
3
2.5
2
1.5
1

4
3.5
3
2.5
2
1.5
1

0.5
0

0.5
0

0.5
0

Q1. このツールを頻繁に使⽤したいと思う

Jcompaths

didiﬀﬀ

Q4. このツールを利⽤するには，技術者のサポートが必要だと思う

Jcompaths

GitHub示するなどの機能がないことに不便さを覚えたという意見もあった．

GitHub＋) 普段から見慣れている
Q10. このツールを使いこなすには事前に多くの知識が必要だと思う

Jcompaths

GitHub＋) シンタックスハイライトがある＋) 差分箇所を変更された文字列単位でハイライト
してくれるのは見やすくてよい

図 11

Q1,Q4,Q10 のスコアの分布−) コードの変化から動作の変化を考える必要があるので，バグが直っているかを判断するのは大変

5. 4 自由記述
被験者へのアンケートで得られた各ツールおよび実験全体に対する自由記述をいくつか記載する．
「便
利だった点，良かった点」を「＋」，「不便だった点．
悪かった点」を「−」で表示している．

JCompaths＋) 実行ごとのトレースがすぐ理解できたのが便利だと感じた＋) 実行経路の違いを可視化することで頭でやるよ
りも考えることが少くて良い＋) didiﬀﬀ と違い複数の変数実行結果を同時に見れるのが便利だった−) できることが多いため，何をとっかかりにすれば良いか分からなかった−) ツールに慣れる時間がもう少し必要であると感じただと思いました−) 変更による実行の影響範囲がわからないためタ
スクに時間がかかった−) ループの実行ごとの変数の値を追うのが大変で不便だった
機能の単純さに使いやすさを覚えたという意見が多く，各種ハイライト機能を高く評価する意見も見られた．一方で，タスクの内容に対して実行時の情報が無いことに不便さを覚えたという意見もあった．
実験全体＋) コードレビューの時に実行経路が可視化されているのは本当に助かる気がする−) タスク自体を理解するのがやや困難だった−) タスクごとの難易度に差があるように感じたトレースや実行経路の有用性に対する感想や，タスクの難易度について指摘する感想が見られた．

メソッドの実行ごとの比較や実行経路の表示など，

JCompaths 独自の機能を高く評価する意見も見られた．一方で，情報量の多さなどに使いにくさを覚えたという意見もあった．

didiﬀﬀ

5. 5 考察
ここではまず，実験の目的として設定した 2 つの項目について考察を行い，改善に向けた課題を挙げる．

1. ツールのコンセプトである，ソースコードの変＋) 実行時の値が表示されることで，コードの動きを

更前後おいて，動的な情報を静的な差分にあわせて頭の中で想像するのが楽になって便利でした

可視化することはその変化を理解する助けとなるか＋) トレース情報の変化がひと目でわかったのでよかった−) 複数の変数の差分を同時に表示できない点が不便だった−) 実行回数ごとに表示できないのが不便でした

タスクの点数の分布からは，明確に理解の助けになるとは言えない結果となった．一方，動的な情報の差分というこれまであまり扱われていなかった情報を提示したにも関わらず，慣れ親しんだツールと同等のタ
スクの点数及び SUS のスコアを得られており，自由トレースが見れることを便利に感じたという意見記述からも JCompaths による動的な差分そのものにが多く，ひと目で変化に気づけることを高く評価する

対する不満は見られなかったことから，このような情意見も見られた．一方で，複数のトレースを同時に表報の利活用については開発者に一定の理解を得られるものであるととらえている．

2. JCompaths における繰り返しを有するメソッとが伺える記述が複数見られた．
具体的な値を得られる変数トークンが限られていドに対する可視化の拡張は有効に働くかた． 実行時の具体的な値をトレースとして参照でき

本実験は繰り返しを有するメソッド実行を対象にしるのは，プリミティブ型と String 型の変数トークンており，JCompaths の機能を生かすことで理解が進のみであり，どの被変更メソッドにも中身がわからなむと予想した．しかしながら，タスクの所要時間と点

いオブジェクトが複数存在した．ツールとしては，具数の両方において，JCompaths と他のツールとの間体的な値が得られないとしてもその変数トークンにで統計的に有意な差は見られなかった．

アクセスがあったことを知らせるためにハイライト

SUS の総合スコアについては，個人差が大きく出を行い，またその回数を表示するためにオブジェクト

る結果となり統計的に有意な差は見られなかったが，ID の列としてトレースビューへの表示も可能にして質問ごとのスコアではいくつかの特徴がみてとれた，

いるが，今回のタスクではこの機能が被験者を混乱さQ1 から，JCompaths が didiﬀﬀ よりも頻繁に利用しせてしまった可能性がある．

たいと思われるツールであることがわかり，動的な差分の表示においては可視化の拡張が被験者に好意

6 ツールの制限的にとらえられていた．自由記述でも，JCompaths

被験者実験の結果も踏まえて，JCompaths をコー

独自の機能がタスクに役立ったことが伺える記述や，

ドレビューに用いる上での制限について整理する．

didiﬀﬀ や GitHub で提供される情報に不足を感じたという記述が多かった．

メソッド間の情報の欠如

一方，Q4 と Q10 からは，JCompaths が GitHub

JCompaths は 1 つのメソッド内の差分を見ることの差分表示に比べ，技術者のサポートが必要で，多くに特化しており，メソッド間における情報は取得しの事前知識が必要だと思われるツールであることがていない．そのため，例えば，メソッド A の実行をわかった．GitHub や didiﬀﬀ の差分表示よりも表示

詳しく見る中でメソッド B が呼び出されていた場合，する情報や操作する項目が増加する分，インターフェ

そのままメソッド B の実行を追う機能はない．実行

イスの工夫がより重要になると考えられる．

トレース自体はもともとが時系列データであるため，改善に向けた考察

これを活用してメソッド呼び出しの順を追うこと自体

JCompaths を用いた場合のタスクの結果が，他のは現実的に可能であると考える．しかしながら，今回ツールを用いた場合より優れたものにならなかった理作成したビューのような形の場合，画面遷移が煩雑に由として，次の 3 点が考えられる．

なることも予想される．JCompaths は現状単体テス

ツールに慣れるための時間が不足していた． タストでカバーできる範囲の修正に対するレビューを想定

クを行う前に，ツールを操作してもらう時間は確保ししており，この拡張に取り組む場合はまずは単体テスていたが，そのときに表示していたサンプルのソース

トの範囲でどの程度メソッド間の動きを追跡できればコードが単純だったこともあり，ツールを使いこなす

良いのかを検討する必要があると考えられる．

のに十分な事前知識を得られなかった可能性がある．
自由記述でも，JCompaths を使いこなせなかったこ

オブジェクト内部の可視化の限界とが伺える記述が複数見られた．

具体的な値を表示する対象はプリミティブ型とタスクの指示が理解しづらく，ツールの性能差が現String 型に限っているため，それら以外の変数トーれにくい状況だった． 「バグ修正の内容」にとどまクンについてはその内容は可視化されない．また，配らない「実行の変化に対する理解の度合い」を測るた

列についても配列中の要素を 1 つの変数トークンとめの設計により，タスク自体が複雑なものになってしして扱って可視化しており，配列全体の値を可視化す

まった．自由記述でも，タスクの理解が困難だったこるような仕組みは現状備えていない．

一方，Collector-sahab にならってオブジェクトのルを使い行ってもらった．その後，SUS の質問と自内部変数の状態を取得した場合，その差分の可視化を由記述からなるアンケートをとった．結果として，タどのような表現にするかは検討が必要な課題である．

スクの所要時間と点数，および SUS の総合スコアのCollector-sahab の可視化は異なる状態の初めての出

いずれにおいても，JCompaths と他のツールとの間

現を注釈として表示するものであり，オブジェクトので統計的に有意な差は見られなかった．しかしなが複雑さには関係なく，その内部のある変数 1 つの状態

ら，自由記述からは，メソッドの実行ごとの比較や実が変化したことを示すメッセージがピンポイントで出

行経路の表示など，JCompaths 独自の機能がユーザ現する形になる．本手法のように差分のない部分も含にとって役立つことが確認できた．

めた一連の系列を提示して比較を行う場合は，オブ

今後の課題として，可視化による効果を高めるた

ジェクトの内部までを表示しようとするとソースコー

め，6 章で述べたツールの制限にどこまで対処すべき

ド上での 1 トークンに付随する情報量が非常に多くなかを実証的に調査し，拡張を行うことが考えられる．

るため，その可視化にはさらなる工夫が必要である．

また，被験者実験についてもタスクの内容を見直し，実行時の情報がコードレビューにもたらす効果をうま

大量の繰り返しへの対処
メソッドの実行回数が非常に多い場合，トレースにく測定できるよう改善していきたいと考えている．
謝 辞 本 研 究 は ，JSPS 科 研 費 JP21H04877，

差分のある実行を見つけるために大量の実行を切り

JP21K02862，JP21K18302，JP22K11985，

替える必要がある．また，ループによる繰り返し回

JP23K16862，JP23K24823，JP23K28065，

数が非常に多い場合，1 回のメソッド実行におけるトJP24H00692，JP24K14895 の 助 成 を 受 け た も のレースが非常に長くなり，表示される矩形も長大になです．

るため，視認性が悪化する．

Shimari らによれば [14]，実行のすべてを記録するのではなく，大量に繰り返されるような変数トークン
についてはその値の新しい数十から数百件を保持するだけでも，デバッグに必要な情報が一定程度欠損せず残っていることが明らかになっている．このような機構と組み合わせた可視化も対処法の候補である．

7 まとめ
本研究では，コードレビューの支援を目的とし，Java プログラムのソースコードの変更前後におけるメソッドの実行の変化を可視化するツール JCom-paths を作成した．JCompaths は，メソッドの実行
を 1 回ずつ順に比較し，変数トークンのトレースに加えて実行経路の差分を表示することで，複数の変数
トークン間における値の依存関係を明らかにする.
また，このツールの有用性を評価するために，JCom-paths 拡張前の試作ツール didiﬀﬀ とあわせて被験者実験を行った．被験者には，デバッグによるメソッドの実行の変化について記述するタスクを，JCompaths，

didiﬀﬀ，GitHub（実行の可視化なし）の 3 つのツー

参 考 文 献[ 1 ] Brooke, J.: SUS: A “quick and dirty” usability
scale, Usability Evaluation In Industry, Taylor &Francis, 1996, pp. 189–194.
[ 2 ] Deknop, C., Mens, K., Bergel, A., Fabry, J., andZaytsev, V.: A scalable log diﬀerencing visualisation applied to COBOL refactoring, Proceedings of
the 9th Working Conference on Software Visualization, 2021, pp. 1–11.
[ 3 ] Etemadi, K., Sharma, A., Madeiral, F., andMonperrus, M.: Augmenting diﬀs with runtime information, IEEE Transactions on Software Engineering, Vol. 49, No. 11(2023), pp. 4988–5007.
[ 4 ] Free Software Foundation: GDB: The GNU
Project Debugger, https://www.sourceware.org/
gdb/. 2024 年 7 月 11 日閲覧.
[ 5 ] Jiang, S., Armaly, A., and McMillan, C.: Automatically generating commit messages from diﬀsusing neural machine translation, Proceedings of the
32nd IEEE/ACM International Conference on Automated Software Engineering, 2017, pp. 135–146.
[ 6 ] Just, R., Jalali, D., and Ernst, M. D.: Defects4J:
a database of existing faults to enable controlled
testing studies for Java programs, Proceedings of the2014 International Symposium on Software Testingand Analysis, 2014, pp. 437–440.
[ 7 ] Kanda, T., Shimari, K., and Inoue, K.: didiﬀﬀ: A viewer for comparing changes in bothcode and execution traces, Proceedings of the 30th
IEEE/ACM International Conference on Program
Comprehension, 2022, pp. 528–532.
[ 8 ] Lewis, B.: Debugging Backwards in Time,
CoRR, Vol. cs.SE/0310016(2003).
[ 9 ] Liu, Z., Xia, X., Treude, C., Lo, D., and Li,
S.: Automatic generation of pull request descriptions, Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering, 2019, pp. 176–188.
[10] Minelli, R., Mocci, A., and Lanza, M.: I knowwhat you did last summer-an investigation of how
developers spend their time, Proceedings of the 23rd
international conference on program comprehension, 2015, pp. 25–35.
[11] Moreno, A., Myller, N., Sutinen, E., and BenAri, M.: Visualizing programs with Jeliot 3, Proceedings of the working conference on Advanced visual interfaces, 2004, pp. 373–376.
[12] Oracle: jdb - The Java Debugger, https://
docs.oracle.com/en/java/javase/21/docs/specs/

man/jdb.html. 2024 年 7 月 11 日閲覧.
[13] Sadowski, C., Söderberg, E., Church, L., Sipko,
M., and Bacchelli, A.: Modern code review: A casestudy at Google, Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, 2018, pp. 181–190.
[14] Shimari, K., Ishio, T., Kanda, T., and Inoue,K.: Evaluating the eﬀectiveness of size-limited execution trace with near-omniscient debugging, Science of Computer Programming, Vol. 236(2024),
pp. 103117.
[15] Shimari, K., Ishio, T., Kanda, T., Ishida, N.,
and Inoue, K.: NOD4J: Near-omniscient debugging tool for Java using size-limited execution trace,
Science of Computer Programming, Vol. 206(2021),
pp. 102630.
[16] 松村俊徳, 石尾隆, 鹿島悠, 井上克郎: REMViewer:
複数回実行された Java メソッドの実行経路可視化ツー
ル, コンピュータソフトウェア, Vol. 29, No. 1(2012),
pp. 78–84.