1
推薦論文●第 9 回プログラミングおよびプログラミング言語ワークショップ (PPL2007)

プログラムスライシングを用いた機能的関心事の抽出
石尾 隆 † 仁井谷 竜介 † 井上 克郎 †ソフトウェアは数多くの機能的関心事，すなわち，特定の機能要求を実現するためのソースコードの集合から構成される．1 つの関心事に属するソースコードは，通常，複数のモジュールに分散しているため，開発者がある関心事を理解するには，その関心事に含まれるソースコードを探し，それらの間の制御フローやデータフロー情報を調べる必要がある．
本研究では，開発者が注目しているプログラム要素群に対し，それらのプログラム要素に依存関係を持つ他のプ
ログラム要素を探索し，要素間の関係を関心事グラフとして可視化する手法を提案する．具体的には，プログラム依
存グラフの探索に基づくプログラムスライシング手法に対して，プログラム構造やキーワードマッチに基づく経験的な指標を導入し，関心事に含まれない可能性が高い要素に対するグラフ探索を打ち切るよう拡張する． Java を対象とした解析ツールとして本手法を実装し，従来のプログラムスライシング手法に基づく手法との比較実験を行った結果，人間が作成したものにより近い関心事グラフを抽出していることを確認した．

A functional concern, code that helps fulﬁll a functional requirement, is typically implemented by collaborative software modules. When developers understand the implementation of a concern, they need to ﬁndcode fragments contributing to the concern and understand how the modules collaborate with one another.
In this paper, we propose an automatic approach to extract program elements closely related to developer’s interest and visualize the relationship among the elements as a concern graph. We extend program
slicing by introducing heuristics to calculate the degree of interest to a developer among program elements
for excluding unrelated elements from a program slice. We have implemented our approach as a slicing toolfor Java software and conducted an experiment. The result shows that our approach extracts a concern
graph more suitable to understand a concern than a traditional program slicing.

相互作用を行っているかを理解する必要がある [21]．

1 まえがきソフトウェアを保守していく過程では，1 つの関心事

ソフトウェアは数多くの機能的関心事から構成さに対して複数回の変更作業が発生するため，その都れる．ここでの機能的関心事とは，開発者がひとまと度，関心事に該当するメソッドの再発見と理解が必要

まりの単位でをあると考える，特定の機能要求を実になる [28]．このようなプログラム理解に関するコス現するためのソースコードの集合である．1 つの関心

トは，ソフトウェアのライフサイクル全体で半分以上事を構成するソースコードは，一般に複数のモジューを占めるといわれている [7]．

ルに分散しているため，ソフトウェア保守作業におい開発者が関心事を発見し理解する作業は，関心事て何らかの改修ないし拡張を行う際には，どのメソッの一部であるようなプログラム文やメソッド，フィードのどのコードが関心事に含まれており，どのようにルドなどのプログラム要素のいくつかを特定する作

Locating a Functional Concern Based on a Program
Slicing Technique.
Takashi Ishio† , Ryusuke Niitani† , Katsuro Inoue†† 大阪大学 大学院情報科学研究科, Graduate School ofInformation Science and Technology, Osaka University

業と，それらの要素に何らかの関係を持った周辺のコードを探索していく作業からなる．関心事に含まれるプログラム要素を探す代表的な方法はキーワー
ド検索であり，Feature Location [28] [37] や部品検索[11] といった手法も利用可能である．そして，発見さコンピュータソフトウェア

2れたプログラム要素と関連するほかのプログラム要

フに変換し可視化することで，開発者は入力として与素を，メソッド呼び出し関係やクラス階層などの情報

えたソースコード集合の関係を把握することができ，を参照しながら発見していき，また，それらがどのよ

関心事の理解を進めることができる．

うな制御フロー，データフローによって相互作用を行うかを調査することで，関心事の理解を行う．

提案手法をツールとして実装し，そのツール自身とjEdit†1 を題材に適用実験を行った結果，経験的な指本研究では，関心事の理解を支援するために，プロ標に基づくグラフ探索の打ち切りによって，小さなプ

グラムスライシング [35] を拡張した手法を提案する．

ログラムスライスを抽出できることを確認した．ま

提案手法は，開発者が関心事の手がかりとして発見した，抽出された関心事グラフについて，人間が手作業たソースコード行の集合と，関心事を表すキーワーで作成した関心事グラフとの比較を行い，従来のスラ

ド文字列を入力として受け取り，関心事に該当するク

イシング手法によって得られる結果よりも人間が作成

ラス，メソッド，フィールド間の関係を関心事グラフしたものに近い関心事グラフを抽出していることを[27] として出力する．

確認した．

プログラムスライシングは，制御依存関係やデータ

以降，2 章では，研究で用いているプログラムスラ

依存関係に基づいてプログラム依存グラフを構築し，イシングと関心事グラフについて解説する．3 章では入力として与えられた文に影響を与える，あるいは提案手法について，また 4 章では評価実験について，影響を受ける可能性のあるすべてのプログラム文をそれぞれ述べる．5 章で関連研究に対する位置づけをグラフ探索によって抽出する手法である．通常のプロ行い，最後に 6 章でまとめと今後の課題について述

グラムスライシングは，アプリケーションのエントリ

べる．

ポイントや一般的なデータ構造を表すユーティリティ
クラスなども含めて網羅的な探索を行っていくため，

2 背景

開発者が理解しようとしている関心事に特有のプロ

2. 1 プログラムスライシング

グラム要素のみを抽出することはできず，関心事の理プログラムスライシング（Program Slicing ，以降

解にそのまま適用することはできない．そこで，本研

スライシング）とは，プログラム中の文間の依存関

究では，プログラム中の各メソッドについて，開発者係に注目し，スライシング基準（Slicing Criterion ，の着目する関心事に該当するかどうかを評価するた< s, v > で表される文 s と変数 v の対）に依存関係

めの経験的な指標を導入する．関心事の一部ではないのある文の集合を抽出する技術である [35]．抽出されと推測されるプログラム要素に対するグラフ探索をた文の集合は，プログラムスライス，あるいは単にス

打ち切ることで，関心事に含まれることが期待されるライスと呼ばれる．

メソッド中の文だけをプログラムスライスとして出力

本研究では，スライシング技術として，プログラム

する．経験的な指標としては，プログラム依存グラフ

依存グラフ（Program Dependence Graph，PDG）の各頂点についての辺の入次数，探索したい関心事をに基づく手法を用いる [10]．プログラム依存グラフ

示したキーワードを含んだメソッドとの距離を用いは，頂点としてソースプログラムの各文に対応する頂

た．この指標における距離の計測には，プログラム依点およびメソッドの引数などを扱うための特殊頂点を存グラフの頂点をメソッド単位に集約したグラフを用持ち，それらの頂点間を制御依存関係（Control De-

いている．

pendence）やデータ依存関係（Data Dependence），

本手法の出力である関心事グラフは，クラス，メ

メソッド呼び出し，パラメータ渡しなどを表す辺に

ソッド，フィールドを頂点とし，クラスの継承関係やよって接続した有向グラフである．制御依存関係とメソッド呼び出し関係，フィールドの参照，更新など

は，文 s1 が制御文であり，s1 の結果によって文 s2

関心事の静的な構造の概要を記述するためのグラフである [27]．得られたプログラムスライスを関心事グラ†1 jEdit http://www.jedit.org/

Vol. 0 No. 0が実行されるかどうかが決定されるとき，文 s1 から

1983
表1

3
異なる関心事に対する従来のスライスの差分

s2 に対し成り立つ関係である．また，データ依存関
係とは，変数 v を定義している文 s1 から，v を参照

頂点数

メソッド数

クラス数

している文 s2 へ，v を再定義しない実行経路が少な

Autosave364,672

4,031

562

くとも 1 つ存在するとき，文 s1 から s2 に対し変数

Undo

364,752

4,038

562

v に関して成り立つ関係である．

差分

86

7

0

スライスは，スライシング基準に対応する PDG 上の頂点を基点として，グラフを逆方向または順方向

ば，アプリケーションのエントリポイントから，スラへ，メソッドの call-return 関係を維持しながら探索

イシング基準までの推移的な制御依存関係の列などすることによって得られる [24]．逆方向への探索は，は，デバッグなどの用途で有益な場合もあるが，途中基点となった変数に影響を与える文の集合を意味すで実行される他の様々な機能も，スライスへと含めてるバックワードスライス（Backward Slice）の抽出

しまう．その結果，異なる関心事を発見するために，となり，順方向への探索は，基点となった変数の影

異なるスライシング基準を与えたとしても，まったく響を受ける文の集合を意味するフォワードスライス

同一のスライスとなってしまうことがある．

（Forward Slice）の抽出となる．

表 1 は，jEdit に対して，ファイルの自動保存機

本研究では，ツールへの入力を簡単化するため，ス

能（Autosave）と，ファイルの変更を元に戻す機能

ライシング基準はプログラム文の集合によって与えら（Undo）に対応するスライスを計算し，その差分れるものとし，各プログラム文で定義または参照されを求めた結果である．スライシング基準としては，ているすべての変数をスライシング基準とみなした

jEdit のソースファイルのうち Autosave.java と Un-

スライシングの計算を行っている．

doManager.java に対して grep を適用し，キーワー
ド “autosave”，“undo” を持つ文の集合を与えた．ま2. 2 スライシングを関心事理解支援に用いるときの問題点

た，比較したスライスは，フォワードスライスとバッ
クワードスライスの和集合である．

スライシングは，スライシング基準に影響を与える，

Autosave, Undo ともに非常に多くの頂点が得られあるいは影響を受ける可能性のある文を全て抽出す

たにもかかわらず，その差分はきわめて小さい．こる手法であるため，多数の文が出力される．Binkleyの原因の 1 つは，Undo 機能によってファイルの変更

らによる実験では，C 言語のプログラムにおいて，任内容を破棄する処理が，Autosave の実行条件である意の文を基準としてスライスを実行した結果，平均で「ファイルが変更済みかどうか」を表現するフラグを

28 ％のプログラム文がスライスに含まれたことが報書き換えるためである．このように，複数の関心事は告されている [1]．この問題の原因の１つは，プログ相互に依存関係を持っていることから，特定の関心事

ラムの実行に影響を与えるアプリケーションのエンのみを通常のスライシングで抽出することは困難でトリポイント（Java における main メソッド）や各ある．

関心事で内部的に使われる一般的なデータ構造など，

実際に自動保存機能の仕組みを開発者が理解すどの関心事に対しても依存関係を持つプログラム要る場合には，定期的にファイルの自動保存処理を起素がスライスに含まれることである．しかし，実際動するタイマーを備えた Autosave クラスや，そのには，アプリケーションに固有でないユーティリティ

実際の処理を行う Buﬀer クラスの autosave メソッ

は，特定の関心事のみを理解しようとするとき，理解ド，BuﬀeredIORequest の autosave メソッド，またする必要がないことが多い [8]．

BuﬀeredIORequest クラスや FileVFS クラスに含また，多くのプログラムスライスは，他の関心事をまれるファイルへの書き込み処理，AutosaveBack-

経由した，長い依存関係の列を多く含んでいる．例え

upOptionPane と jEdit クラスに含まれるオプショ

コンピュータソフトウェア

4

ン設定値の編集処理などの情報が有用である．その一合を求めることに主眼を置いており，得られるスライ方で，Undo をはじめとする他のエディタの機能に関スは実行不可能である．我々の提案手法も同様に，抽わるクラスや，ログ記録用の Log クラス，編集中の出結果は実行不可能なスライスとなる．

文字列のデータ構造の実装クラスなどは，理解する必
要のない情報である．

2. 4 関心事グラフ
関心事グラフ（Concern Graph ）は Robillard ら

2. 3 スライシングに基づく理解支援手法

によって提案された，関心事を表現するためのグラ開発者が着目した特定のプログラム文についてのフである [27]．このグラフは，関心事に含まれるプロ

局所的な依存関係を抽出する手法として，Chopping

グラム要素とその関係を抽象化したグラフで，関心と Length-Limited Slicing が提案されている．

事に含まれるクラス，メソッド，フィールドを頂点とChopping は，ある文から src 別の文 dest への影
響を調べるための手法である [12]．これは，プログラし，メソッド呼び出し calls，フィールドの読み出し

reads など，各要素間の関係を辺とする．

ム依存グラフ上で，src に対応する頂点から，dest に関心事は，ソースコードとしては複数のファイルに対応する頂点へのすべての到達経路を探索すること分散して記述されているため，ツールの出力としてによって求められる．Chopping の計算では，始点おソースコードの断片や位置情報を直接出力しても全よび終点として選ばれた頂点をバリア（Barrier）と体像が把握しにくいという問題がある．そこで，本研して，スライシングの途中経路に登場することを禁止

究では関心事グラフを出力形式として採用し，関心事することで，始点から出発して再び始点に戻ってくるに含まれたプログラム要素の関係を開発者に提示すような循環経路を除去している [16]．

るものとした．

Chopping を使うには，どの文が始点であり，どの関心事グラフの構築に必要な情報とは，メソッド呼文が終点であるかを開発者が指定する必要がある．そび出しやフィールドの読み書きなどであり，プログラのため，調べている対象のソフトウェアの構造についムスライスから取得可能である．スライスから自動的ての知識が必要となる．しかし，開発者が関心事に対に関心事グラフの辺を生成するためのルールは既にして特に知識がなく，検索などで手掛かりとなる要素

亀田らによって提案されており，表 2 はその一部を抜を発見した状態で，ただちにこのような区別を行うこ粋したものである [13]．亀田らのルールは，本来ソフとは困難である．

トウェア中の横断的関心事を抽出するために提案されLength-Limited Slicing は，開発者が興味を持つたものであるが，それ自体は一般的なスライシングのプログラム文は依存関係上で局所的に存在するとい

結果に適用可能である．そのため，我々の手法で得らう仮定に基づいて，スライシング基準からグラフ探索

れたスライスを関心事グラフとして可視化する際にを行う距離を制限したスライシングである [17]．このもこの変換ルールを用いた．

手法は，頂点への訪問をスライシング基準から距離 k
離れた頂点で停止する．k の値を小さくすることで結3 提案手法果のプログラム文の集合を小さくすることはできる

開発者が注目している関心事についての情報を開が，小さな k の値を選んでも，関心事を理解するた

発者に簡潔に提示するため，プログラムスライシング

めに適切な情報が得られるとは限らない．

を用いて情報を抽出し，関心事グラフに変換する手法

プログラムスライシング手法 [10] [35] で抽出されを提案する．

るプログラムスライスは，それ自体実行可能なプログ本手法は，入力として，関心事の一部であると開ラムであり，たとえば手続きの抽出 [15] に利用され発者が判断したプログラム文の集合と，調べたい関ている．一方，Chopping や Length-Limited Slicing

心事を表すキーワードを受け取る．入力となるプロ

はプログラム理解に役立つ小さいプログラム文の集

グラム文の集合は，キーワード検索や様々な Feature

Vol. 0 No. 0
表2

スライスに基づく関心事グラフの辺の生成ルール

1983

5

ライシング基準として，バリア付きのスライシン
グを適用する．

種類

生成条件(calls m1 m2 )スライスがメソッド m1 からメソッド m2 への呼び出
し辺を含む(reads m f )スライスがフィールド f か

4. 得られたスライスの中から，ライブラリに属する頂点のフィルタリングを行う．

5. フィルタリングの結果を関心事グラフとして可視化する．
以降，各ステップの詳細について述べる．

らのデータフローを持つメ
ソッド m の頂点を含む(writes m f )スライスがフィールド f へのデータフローを持つメソッ
ド m の頂点を含む(creates m c)(declares c f |m)(superclass c1 c2 )3. 1 プログラム依存グラフの構築
本研究では，対象として Java を選択した．プログ
ラム依存グラフには，Zhao の JSDG （the software

dependence graph for Java） [36] の定義を用いた．

スライスがクラス c のインプログラム依存グラフの各頂点は，Java のソース

スタンスを生成するメソッ

コードではなく，バイトコードとの中間表現であり

ド m の頂点を含む

三番地コードの一種である Jimple [32] の各命令に対スライスがクラス c のフィー応させた．JSDG では，プログラム文に該当する頂

ルド f またはメソッド m を点以外に，いくつかの特殊頂点が使用される．また，含む

制御依存辺，データ依存辺のほかに，メソッド呼び出

関心事グラフがクラス c1 とし辺，パラメータ渡し辺，フィールド依存辺が使用さ親クラス c2 を含む

れる．

3. 1. 1 Jimple
Location 手法を用いて特定されたものを想定している．本手法の出力は，関心事グラフである．

Jimple は Java ソースコードとバイトコードの中間表現であり，三番地コードの一種である．図 1 に，本手法は，関心事に含まれるプログラム要素がプJava のソースコード（左）とそれに対応する Jimple

ログラムスライスに優先的に含まれるよう，グラフのコード（右）を示す．Jimple コードは，1 つの命令

構造に基づくヒューリスティクスと，開発者が与えでは高々1 つのメソッドしか呼び出さず，また高々たキーワードとメソッド名とのマッチングに基づく

1 つの変数しか値を更新しないことから，データフ

ヒューリスティクスとを用いて，プログラムスライシ

ロー解析が容易であるという特徴がある．制御構造

ングにおけるグラフ探索を打ち切る仕組みをプログ

は if/goto 命令として表現されるほか，ソースコー

ラムスライシングに導入する．

ド上では記述が省略されているデフォルトのコンスト

本手法は，次の 5 つのステップで構成される．

ラクタ（<init>）などのコードが補完される．また，

1. 対象ソフトウェアのプログラム依存グラフを構

通常のメソッド呼び出しには virtualinvoke が対応

築する．

2. プログラム依存グラフの各要素に対してヒュー
リスティクスの評価を行い，グラフ探索を打ち切るバリアとなる辺の集合を計算する．複数のヒューリスティクスが個別にバリアとなる辺を特定し，それらの辺の和集合を最終的に使用するバリアとする．

3. 入力として指定されたプログラム文の集合をスする．例えば，Java の 15 行目の notZero(i) には，

Jimple の 46 行目が対応し，戻り値は $z0 に格納される．

3. 1. 2 Jimple をもとに構築されるプログラム依存グラフ
本研究で用いたプログラム依存グラフは，次の頂点によって構成される．

Jimple 命令頂点 ラベルや宣言を除いた，Jimple

コンピュータソフトウェア

6

01 public class Foo
02 {03 public void nothing()
04 {
05 }
06
07 public boolean notZero(int i)
08 {09 return i != 0;
10 }11
12 public void ifStatement()
13 {14 int i = 10;
15 if (notZero(i)) {16
nothing();17 } else {18
nothing();
19 }
20 }
21 }

01 public class Foo extends java.lang.Object 19 public boolean notZero(int)
02 {
20 {
03 public void <init>()
21 Foo r0;
04 {22 int i0;05 Foo r0;
23 boolean $z0;
06
24
07 r0 := @this: Foo;25 r0 := @this: Foo;
08 specialinvoke r0.<java.lang.Object:
26 i0 := @parameter0: int;
void <init>()>();
27 if i0 == 0 goto label0;
09 return;28
10 }29 $z0 = 1;
11
30 goto label1;
12 public void nothing()
31
13 {32 label0:
14 Foo r0;
33 $z0 = 0;
1534
16 r0 := @this: Foo;
35 label1:
17 return;
36 return $z0;
18 }
37 }

図1

38 public void ifStatement()
39 {40 Foo r0;
41 int i0;
42 boolean $z0;
43
44 r0 := @this: Foo;45 i0 = 10;
46 $z0 = virtualinvoke r0.<Foo: boolean notZero(int)>(i0);47 if $z0 == 0 goto label0;48
49 virtualinvoke r0.<Foo: void nothing()>();
50 goto label1;
51
52 label0:53 virtualinvoke r0.<Foo: void nothing()>();
54
55 label1:
56 return;
57 }
58 }

Java ソースコード（左）に対応する Jimple コード（右）の実行可能な命令に対応する．1 頂点は，1 つのるメソッド呼び出しに対応する実引数頂点には，

数値演算，メソッド呼び出し，フィールド参照，

そのメソッド呼び出し命令の頂点からの制御依存

フィールド更新，分岐命令などに対応する．

辺を接続する．

Entry 頂点 メソッドの実行開始位置を表現した

データ依存辺 変数の定義と参照に対応する辺で，頂点で，各メソッドに必ず 1 つだけ存在する．メ

ある変数の値を定義する命令 vf rom と，その変ソッドの最初の命令文への制御フローを持つ．

数の値を参照する命令 vto があった場合，vto はExit 頂点 メソッドの実行終了を表現した頂点

vf rom に依存する．例えば，Jimple の 45 行目はで，各メソッドに必ず 1 つだけ存在し，すべてのi0 に関して，46 行目への依存辺を持つ．メソッ

return 文からの制御フローを持つ．制御依存関

ド呼び出しの実引数に関してはデータ依存のみ係を計算するために便宜的に用いられる．

扱いが異なり，メソッド呼び出し命令の頂点では仮引数頂点 メソッド宣言の引数および戻り値に対なく，対応する実引数頂点へとデータ依存辺を接応して生成される．メソッドの引数に対応する頂続する．戻り値を参照している場合も，対応する点は，データ依存解析において，各メソッドの先

実引数頂点からのデータ依存辺を接続する．

頭で，仮引数の値を定義した頂点として扱う．ま呼び出し辺 呼び出し辺はメソッド呼び出しに対応

た，戻り値に対応する頂点は，データ依存解析にする辺で，メソッド呼び出し文に対応する頂点かおいて，return 文が定義した戻り値を参照する

ら，呼び出されるメソッドの Entry 頂点へと接頂点として扱う．

続される．動的束縛によって複数のメソッドが呼

実引数頂点 メソッド呼び出し命令ごとに，かつ，動的束縛で実際に実行される可能性のあるメソッ
ドの候補ごとに，実引数および戻り値の受け渡しを表現するために生成される．

ばれる可能性がある場合は，可能性のあるすべてのメソッドへと辺を接続する．
パラメータ渡し辺 メソッド呼び出しによって渡される引数および戻り値のデータ依存に対応する辺各頂点は，以下の有向辺によって接続される．

である．メソッド呼び出し側の実引数頂点から，制御依存辺 ある分岐命令 vf rom から，実行され呼び出し先の対応する仮引数頂点へと接続されるかどうかが vf rom の結果によって直接決定さる．また，戻り値については，呼び出し先の仮引れる命令 vto があった場合，vto は vf rom に依数頂点から，呼び出し側の実引数頂点へと接続さ存する．例えば，Jimple の 47 行目の if 命令は，れる．

49, 50, 53 行目への制御依存辺を持つ．また，あフィールド依存辺 フィールドの値の更新および参Vol. 0 No. 0

1983

7

に基づいて，P DG に含まれる辺の集合 E からバリChild1 c1 = new Child1();
Child2 c2 = new Child2();
Parent p = (condition) ? c1 : c2;
p.something();
図2

エイリアシングの例

アとなる辺を特定する関数として表現できる．

P DG × options → 2E
複数のヒューリスティクスによって複数のバリア辺の集合 E1 , . . . , En を得られるので，それらの和集合

照によって起こりうるデータ依存に対応する辺を，次のステップで行われるスライシングへの入力パである．フィールドの値を更新する命令の頂点かラメータとする．

ら，そのフィールドの値を参照する命令の頂点へと接続される．

Java ではオブジェクトが参照として扱われるため，異なる変数が同じオブジェクトを指すエイリアシングが生じる可能性がある．これに対しては，Points-toSet 解析 [18] を適用することで，各変数について実際に参照しうるオブジェクトの集合を計算しておく．
その結果とクラスの継承関係から動的束縛の可能性を調べ，実行時に起こりうるすべてのメソッド呼び出しについて実引数頂点の生成，呼び出し辺とパラメータ渡し辺の接続を行う．フィールド依存辺については，フィールドの参照命令とフィールドの更新命令のペアに対して，同じオブジェクトを参照する可能性があればフィールド依存辺を接続する．
図 2 は ，Parent が Child1, Child2 の 親 ク ラ ス
で，変数 p が c1, c2 のどちらかを指している例
である．このとき p.something() の呼び出し辺は，Child1#something と Child2#something の両方に接続される．
本研究では，例外処理（Java における try-catch
文）によって発生する特別な制御フローには対応しておらず，例外による脱出頂点（Exceptional Exit）
は作成していない．catch 節については，catch 節の中の命令から，それ以降に続く命令への制御フロー，
データフローは解析しているが，try 節のどの命令から catch 節に移動しうるかは解析していない．

3. 2 ヒューリスティクスを用いたバリアの特定本手法で用いるヒューリスティクスは，適用対象となるプログラム依存グラフ P DG とヒューリスティク
ス用のパラメータ（キーワードおよび閾値） options

ヒューリスティクスが利用できる情報としては，プ
ログラム依存グラフの持つ構造に関する情報と，各頂点に対応した命令が持つ識別子や型などの意味的な情報がある．本手法では，構造の情報に基づくヒューリ
スティクスとして辺の入次数を用いたヒューリスティ
クス，意味的な情報に基づくヒューリスティクスとして識別子に対するキーワードマッチを用いたヒューリ
スティクスを提案する．

3. 2. 1 入次数の大きい頂点に入る辺
ソフトウェアの依存関係はべき乗則に従い，プロ
グラム中の特定のプログラム要素に対して依存関係が集中している [22] [33]．べき乗則では，ある頂点の依存辺の入次数が x である確率が P [X = x] ∼ x−aで表される．ここで分布を近似するための定数 a は，

a > 1 の実数であり，対象ソフトウェアによって多少異なるが，2 に近い値をとる†2 ．
多数のメソッド呼び出しが集中する（入次数が大きい）要素としては，Java における String クラス
や，java.util パッケージに含まれるコレクションクラ
ス，横断的関心事を実現するためのクラスなどがある[20]．このような場合は，呼び出し側のメソッドの機能と，呼び出し先のメソッドの機能との独立性が高いと考えられる．
そこで，PDG の依存辺の入次数 indegree が閾値th より大きな頂点 vto に入る辺をバリアとする．
isBarrier(vf rom , vto ) = indegree(vto ) > th閾値は手動で指定するか，あるいは自動で頂点数†2 被参照数が 1 であるような頂点の割合が大きいほど，a の値は大きくなる．約 38 ％のとき a=1.5，60 ％のとき a=2，83 ％のとき a=3，92 ％のとき a=4 となる．

コンピュータソフトウェア

8
N に対して√N を与える．依存辺の入次数が x より大きい頂点を持つ確率が P [X > x] ∼ x−(a−1) で表√√されることから，x = N のとき，オーダー O( N )個の頂点がバリアの対象の頂点となることが見積もられる．
このヒューリスティクスは，以降の図表中では I と略記する．また，入次数の対象となる辺を全ての辺としたものは Ia，PDG 上の呼び出し辺のみ（あるメ
ソッドを実行する可能性のある呼び出し文の数）を用いたものは Ic と表記する．

3. 2. 2 キーワードマッチと距離に基づく境界

図3

autosave + buﬀer に対するキーワードの評価値

多くの場合，関心事には対応するキーワードがあり，その関心事を実現するコードのメソッド名など，を含んだメソッド群 {m1 , . . . , mn } を抽出する．

重要な識別子に用いられている [28]．これらの関心事• ある評価対象のメソッド m に対する評価値 V (m)を実現するコード同士が直接何らかの依存関係を持っを，キーワードを含んだメソッド群 {m1 , . . . , mn }ているとは限らない [29] が，開発者が注目しているからの距離を用いて，次のように定義する．定要素と直接の依存関係を持つ要素は開発者の作業に数 α(= 0.8) は，評価値の距離に応じた減衰率で関係する要素であることが多い [25]．

ある．

そのため，キーワードを含むようなメソッド同士を接続する依存関係の経路を可視化することは，たと

V (m)

=

max αd(m,mk )k=1...navg αd(m,mk )+k=1...n

えばどのメソッドが他のメソッドを呼び出す役割を担
うのか，どのクラスが処理に必要なデータを提供す

図 3 は，あるプログラム依存グラフから得られた

るのか，といった情報を開発者が理解する際に有用でメソッド間の接続関係グラフの例である．グラフの各ある．

頂点はメソッドであり，上段のグラフでは，autosave

このヒューリスティクスは，開発者が指定したキーと getBuﬀers という２つのメソッドが黒色で示されワードを用いて，以下の手順で各メソッド m についている．下段のグラフは，上段のグラフに対して，ての評価値 V (m) を決定する．V (m) の値の計算式

autosave，buﬀer という 2 つのキーワードを与えたは，キーワードを名前の一部に持つメソッド自身や，ときの評価値 V (m) を表している．

またキーワードを名前の一部に持つ複数のメソッドとこのようにして得られるメソッドごとの評価値と，プログラム依存グラフ上で近い位置にある（依存関係閾値 th を用いて，isBarrier(vf rom , vto ) を次のよを接続するための経路上にある可能性が高い）メソッ

うに定義する．ただし vf rom , vto はそれぞれメソッ

ドが優先的にスライスに含まれるよう決定した．

ド mf rom , mto に所属する頂点であるとする．

• 通常のプログラム依存グラフから，メソッドを頂点とし，呼び出し辺，パラメータ渡し辺，フィールド辺を用いてメソッド間の接続関係グラフを作成する．このグラフ上で，頂点 mf rom
から mto までの最短パスの長さを頂点間の距離d(mf rom , mto ) とする．
• メソッド名の中に部分文字列としてキーワード

isBarrier(vf rom , vto )=mf rom 6= mto∧(V (mf rom ) < th∨V (mto ) < th)

この手法は，キーワードを名前の一部に持つメソッドからの距離に基づいていることから，開発者が grepのようなキーワード検索によって本手法への入力を

Vol. 0 No. 0

1983

9

を定義しており，バリアの制約を破らないスライシン
グアルゴリズムが定義されている．本研究では，このアルゴリズムを，バリアが有向辺の場合に修正して適用している．

図4

バリア付きスライシングの実行

3. 4 ライブラリ頂点のフィルタリング
このステップでは，得られたスライスからライブラ

決定した場合，Length-Limited Slicing [17] の手法とリに属する頂点を取り除く．

近い結果が得られるように見える．しかし，本手法

ライブラリ（例えば java, javax パッケージ）に含は，複数の頂点に対する位置関係によって距離を決まれるような要素は，それ自体が使われていることは定している点，また，メソッド単位を頂点としたグ理解する必要があったとしても，その詳細は理解する

ラフ上で距離を計測している点で，Length-Limited必要がないことが多い．ライブラリに関する情報を除Slicing とは異なっている．図 3 の例では，キーワー

外ないし詳細を省略することで，スライシングの結果

ドにマッチしたメソッドからの距離は，頂点 A は 1，

を簡潔な形で開発者に提示する．

頂点 B は 2 と，頂点 A の方が近い．しかし，評価値

現時点では，Java の標準ライブラリに含まれる頂で見ると，2 つのマッチしたメソッドに挟まれてい点を単純にスライスから取り除いている．そのため，る頂点 B の方が高い値を示している．これによって，ライブラリを経由した依存関係は開発者に提示されLength-Limited Slicing でスライスを小さく絞り込

ない．ライブラリを経由した依存関係を明示するため

んだときに途切れてしまうような依存関係の経路を，には，頂点を取り除くことで消失する経路を，ライブ

本手法では取得可能である．

ラリを代替する辺で接続しておく等の工夫が必要だ

このヒューリスティクスは，以降の図表中では Kと考えられるが，それは今後の課題である．

と略記する．

3. 5 スライスの関心事グラフへの変換
3. 3 バリア付きスライシングの実行
このステップでは，入力として与えられたプログラ
ム文の集合（に含まれるすべての変数）をスライシン

このステップでは，フィルタリング適用後のスライスを，亀田らのルール [13] に基づいて関心事グラフに変換する．

グ基準とし，前のステップで得られたバリア集合を通スライスを関心事グラフとして可視化することで，過しない経路で到達可能な頂点の集合をスライスと開発者はプログラム要素間の関係を把握することがして抽出する．

できる．また，対応するソースコードにもスライスの

図 4 は，バリア付きスライシングの模式図である．

情報をマッピングすることで，関心事グラフと，そのスライシング基準は一般に複数の頂点に変換され，そ詳細としてのソースコードを併用して，関心事を理解れぞれの頂点から，順方向および逆方向のグラフ探索

していくことができる．

が行われる．スライシングはバリアで停止するため，得られるスライスは図 4 のようにバリアに囲まれた

4 実験

形になる．

本手法の有効性を示すため，Java を対象としたスラ

具体的なアルゴリズムとしては，Horwitz らの定

イシングツール（Slicing based COncern LOCation

義 [10] [24] に，バリア計算のアルゴリズム [16] を修正

tool，SCOLOC）を作成した．このツールは，プロしたものを組み合わせている． [16] では，スライシン

グラム依存グラフ構築部と，スライシング実行部からグの途中経路に登場してはならない（ただし，始点もなる．

しくは終端としては登場してよい）頂点としてバリア

まず，PDG 構築部は Java バイトコードを入力としコンピュータソフトウェア

10org.gjt.sp.jedit.Autosaveorg.gjt.sp.jedit.jEdit
getIntegerProperty(java.lang.String, int): int
propertiesChanged(): void

call

javax.swing.Timer timer

図5

表3

手作業で作成した関心事グラフとスライシング基準

actionPerformed(java.awt.event.ActionEvent): voidinit(): void
setInterval(int): void

のサイズ

関心事

関心事グラフスライシング基準

クラス

メソッド

クラス

メソッド

1

7

18

4

8

2

12

48
3

13

5

6

2

4

3

8

4

4

出力される関心事グラフの例

Autosaveて受け取り，PDG の構築を行う．この構築部は，Java
バイトコードを解析・変換するためのフレームワーク
Soot †3 に基づいており，フレームワークが提供する

Marker

1

8

30

2

12

33

制御フロー解析，データフロー解析，Points-to Set

Undo

1

3

6

2

12

21

1

20

32

2

7

14

Input

1

9

11

2

4

7

MethodID

1

5

13

2

7

9

解析および動的束縛の解析を用いて PDG を構築す
る．Soot は Points-to Set 解析の実装として Spark，

Batch

Paddle など複数の実装を提供しているが，本実装では Spark を使用した．また，PDG 構築部は，PDGの各頂点に対して，ソースコードの行番号との対応関係も保存する．
次に，スライシング実行部は，構築された PDG とスライシング基準となるプログラム文（ファイル名と行番号）の集合，ヒューリスティクス用の引数（キー定された場合はそのメソッドに含まれるすべての変数

ワードと閾値）を入力として受け取り，ヒューリスの出現を，スライシング基準として扱うようにしてティクスによるバリアの決定，スライスの計算，そしいる．

て関心事グラフへの変換を行う．
最終的な出力としては，エディタ上にマーキングを行うための行番号情報と，関心事グラフのテキスト記
述，そして関心事グラフを Graphviz †4 によって可視化したものの 3 種類をサポートした．

4. 1 実験対象ソフトウェア
実験対象には， jEdit 4.2 ﬁnal および我々の開発したツール SCOLOC を選択した．

jEdit は Java で書かれたテキストエディタで，プラAutosave 機能の簡単な関心事グラフを Graphviz

グインを除くクラス数は 777 クラス，行数は 140,316で可視化した出力例を図 5 に示す．Graphviz による行である．また，スライシングツールのサイズはク

可視化では，図の複雑化を避けるためクラスを 1 ノー

ラス数 183，行数 16,144 である．いずれの解析でも，

ドとして表現した．メソッドやフィールドはクラス

Sun JDK 1.4 に含まれるライブラリを含めた解析をノードの内部に含め，クラス間を接続する辺はそのま行っている．

ま表示し，クラス内部の辺を省略している．

本手法は，保守作業におけるプログラムの変更を

スライシング基準は，本来，各ソースコード行の変想定し，jEdit および SCOLOC についてそれぞれ 3

数を指定するものであるが，本研究では，キーワード

個，変更作業の説明という形で機能的関心事を記述

検索やその他の Feature Location ツールとの連携をした．

容易にするため，プログラム文の行番号が指定されれあるメソッドやフィールドが関心事に含まれるかど

ばその行中のすべての変数を，また，メソッド名が指うかは開発者によっても判断が分かれるため，被験者†3 Soot, a Java Optimization Framework
http://www.sable.mcgill.ca/soot/†4 Graphviz http://www.graphviz.org/

として，大学院生 2 名に関心事グラフの構築を依頼した．この 2 名は，いずれも Java プログラムの開発経験があり，また jEdit のコードを過去に読んだこと

Vol. 0 No. 0

1983

11

がある．スライシングに関する用語などの基礎知識はに必要なアルゴリズムに対応するオブジェクトを持っているが，本手法および SCOLOC ツールの開毎回作り直している．これらを適切に初期化し，発には関与していない．被験者 2 名は，与えられた再利用する処理を追加実装することを作業目的

変更作業の説明を元に，変更作業の事前計画としてとした．

関心事グラフを構築した．作成した関心事グラフのオブジェクトの生成に Factory パターンを用いサイズを表 3 に示す．著者らは，各関心事に対応するていたことから，キーワード “create” と，該当キーワードを用意し，主として grep によるキーワー

する Factory パターンのメソッド群をツールへ

ド検索の結果を用いてスライシング基準を作成した．

の入力とした．

以下，作成した計 6 個の関心事を示す．

Input (SCOLOC) SCOLOC は，スライシン

Autosave (jEdit) ユーザが編集中のバッファのグ基準を，コマンドライン引数や CSV ファイル

内容を，特別な名前のファイルに定期的に自動保によって，ファイル名と行番号，あるいはクラス

存する機能である．自動保存先のファイル名を変名とメソッド名のリストとして受け取っている．

更することを作業目的とした．

この形式として，クラス名やメソッド名にワイル

ツールへの入力には，キーワード “autosave” と，

ドカード文字列を許すよう機能を拡張すること同キーワードを引数として grep を実行した結果を作業目的とした．

得られたコード集合を用いた．

ツールへの入力には，スライシング基準のコード

Marker (jEdit) jEdit は，エディタ領域の左端上での表現であったキーワード “criterion” と，（ガター）部分を右クリックすることで，マー

同キーワードを引数として grep を実行した結果カーを設置できる．このマーカーを設置する際得られたコード集合を使用した．

に，マーカーの意味などの任意の文字列を追加でMethod ID (SCOLOC) SCOLOC は，解析記入，表示する機能を追加することを作業目的と対象プログラムの各メソッドに ID を割り当て，した．

そのリストをファイルに保存する．しかし，オブ

ツールへの入力であるキーワードには “marker”

ジェクト共有の取り扱いに誤りがあり，1 度の実を用いた．また，スライシング基準としては，

行でファイルが 2 回保存されていた．この誤り

jedit.Buﬀer クラス等にコメントとして “marker

を修正することを作業目的とした．

manipulation methods” と記載されていたメソッ

ツールへの入力には，キーワード “methodid”

ド群（のすべての行）を指定した．

と，同キーワードを引数として grep を実行した

Undo (jEdit) Undo 機能では，バッファに対する編集を取り消すことができるが，連続した変更を元に戻すための作業ヒストリ長に 0 を設定してしまうと，テキストの編集を行うごとに，配列の不正アクセス（ArrayIndexOutOfBoundsEx-

ception）が発生してしまう．この問題を修正することを作業目的とした．
ツールへの入力であるキーワードには，“undo”
を使用した．また，スライシング基準には，送出された例外のスタックトレース情報（クラス名と行番号のペアの列）を使用した．

Batch (SCOLOC) 複数のスライシングを連続して実行するバッチ処理機能では，スライシング

結果得られたコード集合を使用した．
厳密に時間計測を行ったわけではないが，手作業での関心事グラフの構築には，1 つのグラフにつき 1 時間から 1 時間 30 分の時間が必要であった．
ツールの実行環境には Windows Vista 64 ビット
版，Intel Core 2 Duo 6300 (1.86GHz)，64 ビット版

Sun JVM 1.6 を用いており，4GB のメモリを JVMに割り当てた．PDG 構築には，jEdit，SCOLOC のいずれの場合でも約 20 分の時間を要した．この構築
時間のうち約 10 分は Points-to Set 解析とコールグ
ラフの構築に費やされており，残り 10 分がメソッド
単位での解析とファイルへの出力である．スライシ

コンピュータソフトウェア

12
表4Autosave に対するスライスのサイズ

基準
通常スライス
Length 10
Length 9
Length 8
Length 7
Length 6
Length 5
Length 4
Length 3
Length 2
Length 1
K 0.80K 0.90
K 1.00
K 1.10K 1.20K 1.30K 1.40K 1.50K 1.60Ia auto
Ia 8
Ia 4
Ia 2
Ia 1
Ic auto
Ic 8
Ic 4
Ic 2
Ic 1

頂点数
290
492,300
459,132
418,546
360,242
278,430
154,320
76,79830,278
8,572
3,489
672
483,568
479,578
270,838
233,582
56,007
11,002
3,873
389
363
397,306
284,346
109,727
1,751
845
399,570
326,504
247,767
97,25940,472

メソッド数
8
5,442
5,295
5,178
4,871
4,351
3,552
2,399
1,324
698
171
63
4,946
4,829
1,853
1,580
296
54
24
9
8
4,652
4,157
2,179
75
20
4,688
4,418
3,817
2,160
1,153

クラス数
4
724
721
720
717
688
647
588
429
295
71
19
724
724
580
548
135
20
9
4
4
654
644
485
31
6
657
653
626
503
378

を著しく悪化させ，また，たとえば Graphviz による可視化手法では対応できないといった問題を生じる．
表 4 に，関心事 Autosave を発見するために用意したスライシング基準を用いて，従来のプログラム
スライシング手法（バリアなし），Length-Limited

Slicing，そして提案手法で得られたスライスのサイズを示す．本手法では，スライシングの結果を関心事
グラフへ変換して開発者に提示するため，スライスに含まれるメソッド数が，最終的に出力される関心事グ
ラフのサイズへと影響する．
表 4 における「通常スライス」は，Horwitz らのアルゴリズムの適用結果である．Length k とあるのは，スライシング基準である頂点から依存辺を高々 k
回たどってたどり着ける頂点だけを抽出したスライスである．k = 0 の場合，出力はスライシング基準と等しい．Length-Limited Slicing では，k = 1 の場合にのみ小さいスライスを抽出することに成功しているが，k = 2 以上になると，多数のメソッドをスライスとして抽出している．

K 1.00 は，キーワードを用いたヒューリスティク
スによるスライシングで，閾値として 1.00 を与えたことを表している．提案手法では，抽出されるスライスのサイズが，閾値によって従来のスライスとほぼ同等のものから，スライシング基準周辺のみの最小限のものにまで変化する．

ングには，実行の前準備に約 5 分程度，1 回のスライ
シングとそれに伴う関心事グラフの生成に 10 秒から

入次数のヒューリスティクスでは，手動で設定した√いくつかの閾値と，自動設定（auto）の閾値 b N c

1 分程度の時間を要した．2 つの対象ソフトウェアでを用いた．自動設定の値における N は，プログラム

時間に差がなかったのは，同時に解析した Sun JDK

依存グラフの頂点数である．

1.4 のクラスが占める割合が大きいためであると思わ閾値が小さな値の範囲では，閾値が 1 変化するだ

れる．また，スライシングに要する時間にはかなりのけでスライスのサイズが大きく変化する．これは，入幅があるが，グラフ探索が早く打ち切られ，結果が次数がべき乗則に従っており，入次数の小さい頂点の

小さなスライスとなったときほど，計算時間は短く数が非常に多いためである．また，過剰に依存関係がなった．

集中したプログラム要素を除外する目的から考えても，あまり小さな閾値は有効ではないと考えられる．

4. 2 スライスのサイズ

したがって，入次数によるヒューリスティクスは単独

本実験では 6 つのタスクに対して関心事グラフをで使うのではなく，他のヒューリスティクスと併せて作成したが，これらは，高々 48 のメソッドしか含んでいない．このサイズを大きく超えたスライスの抽出は，出力の品質（次節で行う適合率による評価結果）使うべきだと考えられる．

Vol. 0 No. 0

1983

4. 3 ヒューリスティクスの効果

0.7

提案手法と Length-Limited Slicing [17] で得られ

0.6

13
w/o I
Ia 2
Ia 4
Ia 8
Ic 2
Ic 4
Ic 8

る関心事グラフを，被験者が手作業によって作成した
0.5

この評価基準には，適合率 (Precision)，再現率 (Re-call)，そしてそれらのトレードオフを示す F 値を用いた．これらの数値は，プログラムスライスに含まれるメソッドの集合 Mslice ，人間が作成した関心事グ
ラフに含まれるメソッドの集合 Mconcern に対して，

f-measure

関心事グラフと比較した．
0.4

0.3

0.2

0.1

0
0.8

以下の式で計算される．

|Mslice ∩ Mconcern ||Mslice ||Mslice ∩ Mconcern |Recall =|Mconcern |2P recision × RecallF =P recision + Recall

P recision =

図6

0.9

1

1.1

1.2
K threshold

1.3

1.4

1.5

1.6

Autosave (被験者 1) でのヒューリスティクスの組み合わせによる F 値の変化

ヒューリスティクスと組み合わせて適用した場合の F値である．w/o I の値は，キーワードマッチ単独の

この定義では，メソッド集合 M の要素数を |M |場合の値である．この結果から，ヒューリスティクスと表記している．|Mconcern | の具体的な値は，表 3の組み合わせによって F 値が向上しており，Ia 2 のの「関心事グラフ」列に示しているメソッド数とな値が最も良かった．この図は 1 人の被験者が作った

る．結果の F 値が高いほど，抽出されたメソッド集

Autosave に関するメソッド集合に対しての F 値を表

合 Mslice は人間が選択したメソッド集合 Mconcern

しているが，他のデータに対しても確認した結果，こに近い．

の Ia 2 の設定を以降の実験に用いることにした．

このように定義した F 値を用いて，我々が提案しIa は，Ic と異なり，メソッド呼び出し辺だけでなた入次数およびキーワードマッチのヒューリスティク

く，多数のメソッドから代入される，グローバル変数

ス，Length-Limited Slicing を以下のように組み合に近いフィールドによるデータ依存関係もバリアとしわせたスライシング計算を行い，得られた関心事グラて検出する．Ic との差の原因については今後も調査

フの比較を行った．

が必要であるが，ある 1 つの機能の内部ではデータ

1. Length-Limited Slicing のみの多くを引数によって伝達しており，異なる機能間で2. キーワードマッチのみ

はフィールドに一度データを保存してデータを受け渡3. Length-Limited Slicing + 入次数

す形式が多かったという可能性がある．

4. キーワードマッチ + 入次数

続いて，従来手法である Length-Limited Slicing

このうち，1 が従来手法であり，4 が提案手法を完全を用いて，たどる依存辺の数 k を 1 から 10 まで変に適用したものである．キーワードマッチと Length-

化させて得られた関心事グラフの F 値を図 7 に示す．

Limited Slicing は，いずれも距離を用いていること

スライシング基準となる頂点はキーワード検索で選択から，同時には適用していない．

しているため，k = 1 または 2 のとき，良い結果を

まず，入次数のヒューリスティクスについて，他の出すことができる．一方で，4. 2 節で示したように，２つの手法との組み合わせに適した閾値の設定を検k が増加するとスライスサイズに含まれるメソッド数討した．具体的には，入次数のヒューリスティクスのが大きく増加し，関心事グラフのサイズを大幅に上回

閾値を変化させて F 値の計算を行い，使用しない場

るため，適合率と F 値を悪化させる．

合と比較した．図 6 は，関心事 Autosave に対して，

キーワードマッチによるヒューリスティクスのみを異なる入次数の閾値を用いて，キーワードマッチの適用した結果を図 8 に示す．サイズが最も小さなスラコンピュータソフトウェア

14
0.8

0.7

0.6

0.4

autosave(1)autosave(2)marker(1)marker(2)undo(1)
undo(2)batch(1)batch(2)input(1)input(2)methodid(1)methodid(2)

0.7

0.6

0.5
f-measure

0.5
f-measure

0.8

autosave(1)autosave(2)marker(1)marker(2)undo(1)
undo(2)batch(1)batch(2)input(1)input(2)methodid(1)methodid(2)

0.4

0.3

0.3

0.2

0.2

0.1

0.1

0

0
10

9

図7

8

7

6
5
Length threshold

4

3

2

1

10

Length-Limited Slicing の結果

図9

9

8

7

6
5
Length threshold

4

3

2

1

Length-Limited Slicing に入次数 (Ia 2) を組み合わせた結果

0.7

autosave(1)autosave(2)marker(1)marker(2)undo(1)
undo(2)batch(1)batch(2)input(1)input(2)methodid(1)methodid(2)0.6

autosave(1)autosave(2)marker(1)marker(2)undo(1)
undo(2)batch(1)batch(2)input(1)input(2)methodid(1)methodid(2)

0.7

0.6

0.4
0.5
f-measuref-measure

0.5

0.8

0.3

0.4

0.2
0.3

0.1

0.2

0.1

0
0.8

0.9

1

1.1

1.2
K threshold

1.3

1.4

1.5

1.6
0
0.8

図8

0.9

1

1.1

1.2
K threshold

1.3

1.4

1.5

1.6

キーワードマッチのヒューリスティクスのみの適用
結果

図 10

キーワードマッチと入次数 (Ia 2) を組み合わせた結果

イスは，スライシング基準として選ばれたコードを含んだクラスのみの関係を示す非常に簡潔な関心事グ定した場合（たとえば 1.4 などを選んだ場合）は，F

ラフとなり，再現率が低いため，F 値としては高くな

値では Length-Limited Slicing とほぼ同じ値を取るらない．閾値の低下に伴ってスライスサイズが増加すが，Length-Limited Slicing では k ≥ 2 でなければると，再現率および F 値が上昇するが，スライスの登場しないようなメソッドをスライスに含めることがサイズがある程度以上大きくなると，適合率の減少にできる．これに該当するメソッドの例としては，関心

よって F 値も減少に転じる．

事 Autosave において，変更された設定を Autosave

k = 1 で適用した Length-Limited Slicing は，キークラスに伝える経路である jEdit.propertiesChanged

ワードマッチによるヒューリスティクスの結果を上回

メソッドが挙げられる．このような差は，我々の用る良好な結果を出すことがある．しかし，k = 1 といたヒューリスティクスが，キーワードにマッチしたは，スライシング基準として選んだプログラム文か（スライシング基準としても用いている）メソッド間らただ 1 度依存辺を辿っただけであり，メソッド呼びを接続するような頂点を優先的に抽出しているため出し関係やフィールドによる直接的な依存関係を持であると考えられる．

つメソッドだけを抽出したものとなっている．キー

図 9 は Length-Limited Slicing に対して，また図

ワードマッチのヒューリスティクスで閾値を高く設

10 はキーワードマッチのヒューリスティクスに対し

Vol. 0 No. 0

1983

15

て，それぞれ入次数のヒューリスティクス（Ia 2）をファイル名を変更しようとしたところ，図中に太枠組み合わせたときの結果である．入次数のヒューリス

で示す 9 個のクラス群が実際に重要であると判明しティクスの導入によって，いずれの結果も，導入前にた．この関心事グラフでは，従来のスライシングでは比べ，閾値の変化に対して F 値の悪化が抑制されて含まれてしまっていた UndoManager クラスや，オいるが，Length-Limited Slicing が k の値から受けプション設定値を管理するデータ構造の実装であるる影響などには変化がなかった．

PropertyManager クラスなどが除去されている．ま図 7 で示した従来の Length-Limited Slicing 手法

た，jEdit クラスは 90 のメソッドを持つ約 3800 行のを用いた場合に比べ，提案手法である入次数とキー巨大クラスであり，Buﬀer クラスも約 4300 行，120

ワードマッチのヒューリスティクスは，人間が作成し以上の GUI 処理のメソッドを持っているが，これらた関心事グラフに近い結果を抽出することに成功しのメソッド群のほとんどをスライスから除外することている．我々の提案手法の一部である入次数のヒューに成功している．

リスティクスだけを Length-Limited Slicing に組み関心事 Autosave では，ユーザが自動保存の間隔な合わせた状態でも，提案手法とほぼ同程度の F 値とどを設定するための設定ダイアログである Autosave-

なることがある．ただし，提案手法は，複数のキー

BackupOptionPane に関する処理と，実際に保存処

ワードにマッチしたメソッド間を接続するような経路

理を定期的に実行する Autosave.actionPerformed メを優先的に発見しており，たとえば Length-Limited

ソッドとの間には，直接のメソッド呼び出し関係が存

Slicing よりサイズが小さいとき（例：表 4 における在しない．フィールドに保存された値を経由したデー

K=1.3 以上）でも，距離 k = 2, 3 となるようなメ

タ依存関係を用いてクラス間の関係を探索できる点

ソッドをスライスに含めている．距離が遠いメソッド

が，プログラムスライシングを用いた手法の利点でほど数が多いため，そのようなメソッドを自動で特定ある．

できる点で，提案手法は有効である．

従来手法である Length-Limited Slicing によって最終的な関心事グラフの要素数が大きくなってき得られる最も F 値の高かったグラフは，k = 1 の場

たときは，提案手法のほうが F 値が高いグラフを提合に得られる 19 個のクラスであった．サイズは提案示できるが，やはり本研究で用いているような関心手法で得られたものとほぼ同じであったが，頂点同士事グラフの直接の可視化は困難となる．しかし，関心を接続するような経路が発見されておらず，関心事グ

事を文書化する手法 [19] やコードを読解する順序のラフが 8 つの部分グラフに分割された（ある部分グ

構築 [23] のように，他のプログラム理解手法を適用

ラフからは他の部分グラフに到達することができなするための情報として利用可能となる可能性があり，い）状態となっていた．提案手法で得られた関心事グ

Length-Limited Slicing を用いた場合よりも適用可

ラフは，頂点が連結されており，従来手法で得られた能な場面が多いと考えられる．

ものと比べて，メソッド間の関連を知ることができるという点で有用なものとなっていた．

4. 4 議論

4. 4. 2 手作業で作成した関心事グラフとの違い

4. 4. 1 関心事グラフの出力例

被験者 2 名に対して，提案手法で抽出された関心提案手法を完全に適用した（キーワードマッチと事グラフおよび被験者らが作成した関心事グラフと入次数の両方を用いた）スライシングによって得らの差分を提示し，提案手法の有用性についてインタれた F 値の高い（手作業で作成した関心事グラフとビューを行った．

近い）関心事グラフの例として，図 11 を示す．図 11

その結果，まず，提案手法によって抽出された関心は Autosave についての関心事グラフで，含まれてい事グラフは，被験者らが発見したにも関わらず関心事たクラスは 17 個あった．著者らが実際に jEdit におグラフに入れ忘れたメソッドを発見していたことが判

ける Autosave 機能を改変し，自動保存で作成される

明した．また，動的束縛の解析によって実際には呼ばコンピュータソフトウェア

16org.gjt.sp.jedit.options.AutosaveBackupOptionPane_init(): void
_save(): voidinit(): voidorg.gjt.sp.jedit.PluginJAR
call

activatePlugin(): void

javax.swing.JCheckBox backupEverySave
javax.swing.JTextField autosave
javax.swing.JTextField backupDirectory
javax.swing.JTextField backupPrefix
javax.swing.JTextField backupSuffix
javax.swing.JTextField backups

boolean activatedjava.lang.Class class$org$gjt$sp$jedit$EditPluginorg.gjt.sp.jedit.EditPlugin plugin

call

call

call

bsh.CollectionManager

bsh.ClassGenerator

bsh.ReflectManager

getCollectionManager(): bsh.CollectionManager

getClassGenerator(): bsh.ClassGenerator

getReflectManager(): bsh.ReflectManager

bsh.CollectionManager manager

bsh.ClassGenerator cg

bsh.ReflectManager rfm

callorg.gjt.sp.jedit.jEdit
exit(org.gjt.sp.jedit.View, boolean): void
getBuffers(): org.gjt.sp.jedit.Buffer[]
getProperty(java.lang.String): java.lang.String
getProperty(java.lang.String, java.lang.Object[]): java.lang.String
propertiesChanged(): void

callboolean backgroundint bufferCountjava.lang.Object bufferListLockorg.gjt.sp.jedit.Buffer buffersFirst
org.gjt.sp.jedit.PropertyManager propMgr

call

call

call

call

call

call

call

org.gjt.sp.jedit.PerspectiveManagerorg.gjt.sp.jedit.GUIUtilities
call

savePerspective(boolean): void

call

call

confirm(java.awt.Component, java.lang.String, java.lang.Object[], int, int): int

readjava.lang.Class class$org$gjt$sp$jedit$PerspectiveManager

call

call

call

org.gjt.sp.jedit.Buffer
autosave(): void
close(): voidfinishSaving(org.gjt.sp.jedit.View, java.lang.String, java.lang.String, java.lang.String, boolean, boolean): void
getAutosaveFile(): java.io.Fileload(org.gjt.sp.jedit.View, boolean): boolean
recoverAutosave(org.gjt.sp.jedit.View): boolean
setDirty(boolean): void
setPath(java.lang.String): voidorg.gjt.sp.jedit.Autosave
actionPerformed(java.awt.event.ActionEvent): voidinit(): void
setInterval(int): voidstop(): void

calljava.io.File autosaveFile
java.io.File filejava.lang.String namejava.lang.String pathorg.gjt.sp.jedit.Buffer nextorg.gjt.sp.jedit.buffer.UndoManager undoMgrjavax.swing.Timer timer

call

call

call callorg.xml.sax.helpers.NewInstancebsh.BshClassManager
createClassManager(bsh.Interpreter): bsh.BshClassManagerorg.gjt.sp.jedit.io.VFSManager
call

newInstance(java.lang.String): java.lang.Object

getFileVFS(): org.gjt.sp.jedit.io.VFS

java.lang.Class class$org$xml$sax$helpers$NewInstanceorg.gjt.sp.jedit.io.VFS fileVFS

org.gjt.sp.jedit.buffer.BufferIORequest
autosave(): voidinit(int, org.gjt.sp.jedit.View, org.gjt.sp.jedit.Buffer, java.lang.Object, org.gjt.sp.jedit.io.VFS, java.lang.String): void
insert(): voidload(): voidrun(): voidsave(): void
toString(): java.lang.String
write(org.gjt.sp.jedit.Buffer, java.io.OutputStream): void

call

int type
java.lang.Object session
java.lang.String markersPathjava.lang.String pathorg.gjt.sp.jedit.Buffer bufferorg.gjt.sp.jedit.View vieworg.gjt.sp.jedit.io.VFS vfs

call

call

superclass callorg.gjt.sp.util.WorkRequestorg.gjt.sp.jedit.io.UrlVFS
call_createOutputStream(java.lang.Object, java.lang.String, java.awt.Component): java.io.OutputStream

call

call call

setStatus(java.lang.String): voidcallsuperclassorg.gjt.sp.jedit.io.VFS
getFileName(java.lang.String): java.lang.String

図 11

関心事理解に適した関心事グラフ (Autosave)

れないようなメソッドが除去されている点，フィール

Listener として登録されること）などは関心事グラドを経由した推移的なデータフロー関係の追跡が容フ上に提示されないとの指摘もあった．これに対して易である点が有用であるとの回答を得た．

は，たとえば実行履歴の可視化手法 [31] と組み合わ提案手法は grep によるキーワード検索の結果など

せ，構造と振る舞いの要約を同時に開発者が閲覧できをそのまま関心事グラフに変換できるため，得られたるようにするといったツールの拡張が考えられる．

グラフを手作業での洗練していくか，あるいは適切に

4. 4. 3 入次数によるユーティリティクラスの判定

スライシング基準を追加していくといった対話的なイ

入次数のヒューリスティクスは，ソースコードの多ンタフェースがあれば，より有用であろうとの意見が数の場所に出現するメソッド呼び出しを，探索の範囲

得られた．

から除去する効果がある．一方で，わずかな回数しか一方で，オブジェクトの振る舞いに関する情報（た参照されないクラスは，たとえライブラリであってもとえば Autosave クラスが Timer に対する Event

結果に含まれる．本手法では，出力を簡略化するたVol. 0 No. 0

1983

17

め，Java 標準のクラスについては，パッケージ名にクは，Java 標準のクラスに付属する native メソッド

よる出力のフィルタリングを行っている．

に関する「事前に準備された」依存関係を提供してお本実験では，ユーティリティと判断されたが，入次数が少なく，かつ関心事の理解に役立つクラスとしり，ユーザが追加した native メソッド以外のすべてのメソッドが解析対象となっている．

て，たとえば Autosave を実装するために使われてい本実験で，このようなライブラリ内部の依存関係の影

た Timer や，Input を実装するために使われていた

響を受けていたのは，関心事 Autosave に用いられた

CSVReader というクラスが発見された．

Timer オブジェクトから Autosave.actionPerformed

これらのクラスは，それぞれの機能の実装でのみ利用されているので，入次数が少ない．また，実装

メソッドへのコールバックなど，イベントハンドラに関する呼び出しであった．

の方法を端的に示しているため，関心事の理解としライブラリを除外した安全な解析を実現できればて有用であると判断された．Timer は Java 標準ク

提案手法の実行性能の改善が見込めるが，そのためラスであったのでフィルタリングの対象であったが，には，ライブラリ内部のデータ依存関係を近似する

CSVReader は SCOLOC のプログラムの一部として方法の考案が必要である．また，コールグラフの頂

ソースコードごと再利用されていたため，呼び出し関

点数などが変化することから，得られるスライスや係などが関心事グラフ中に示された．

関心事グラフへの影響も評価していく必要があるが，入次数の少ないもののうち，実際に不要であると判

これらは今後の課題である．

明したものは手動でフィルタリングを追加設定するこ4. 4. 5 閾値の設定方法とができる．また，逆に適用済みのフィルタを解除す

実際の運用においては，開発者らは事前に定義さることも可能である．フィルタリングは，スライシン

れた正解集合を持たないため，F 値を用いて閾値の値

グ結果に対して適用するため，プログラムスライスさを決定することはできない．本実験において被験者え保存しておけば，関心事グラフをただちに更新するが作成したグラフのサイズが表 3 に示した最大のもことができる．

ので 48 個のメソッドであったこと，また，Robillard

その一方で，ライブラリやフレームワークの中からが行った実験においても jEdit に対する関心事グラ

重要クラスだけを的確に取りだす手法は，今後の課題

フが 35 個のコード片から構築されていたこと [26] なである．動的解析では，あるユーザの操作に対応する

どから，開発者が作成する関心事グラフの情報を集め実行履歴の中から，その操作に固有の重要なメソッドていけば，出力として適切だと思われる関心事グラフ

だけを抽出する方法が提案されており [3]，このようのサイズを自動推定できる可能性がある．

な「機能に対して固有である」性質を入次数よりも適しかし，一般的な関心事グラフのサイズというのは切に反映するメトリクスがあれば，それをヒューリス

知られていないため，現段階での利用方法としては，

ティクスとして本手法の枠組みに導入することが可能

関心事グラフの段階的な提示を考えている．これは，である．

まず閾値を自動で最も厳しい値に設定することでスラ

4. 4. 4 ライブラリの解析

イシング基準となったメソッド群を含んだ簡潔な関心

本論文で用いた実装では，ライブラリを解析対象

事グラフを提示しておき，閾値を段階的に変化させ，に含めている．Java のライブラリは，イベントハン

より詳細な情報を含んだ関心事グラフへと理解を進ドラやオブジェクトを比較するためのメソッド（Ob-めていくという方法である．この方針は，Storey ら

ject.equals）を内部で使用することが多く，これらのの提案する「ソフトウェア理解支援ツールが満たすべ

呼び出し関係がヒューリスティクスに影響を及ぼす可き項目」の 1 つ「E5: システム（本研究の場合，関能性がある．

心事の実装）の構造を表すオーバービューが抽象度を本実験では，すべてのメソッドを解析した状態での変化させながら使えること」とも合致する [30]．また，実験を行っている．実装に用いた Soot フレームワー

バリアを用いたスライシングのアルゴリズム [16] は，

18コンピュータソフトウェア

バリアを通過しない経路を網羅的に探索していく反しているような関心事の抽出が行える．しかし，出力

復アルゴリズムとして定義されており，バリアが除去の可視化については，抽出されたメソッド間の直接のされた経路だけを追加で探索することが可能である．

呼び出し関係と継承関係以外はサポートしていない．

そのため，最も厳しい閾値から順に複数の関心事グラ

この手法によって得られたメソッド群を我々の提案手フを抽出する方法は，ツールの性能面での問題も少な

法の入力とすれば，より有効な情報を開発者に提示でいと考えている．

きると推測される．
我々の提案手法によって得られるグラフの可視化に

5 関連研究

おいて，コードが多数のメソッドに分散すると，グラ

ソフトウェア中の特定の機能や関心事に属するソーフが巨大化し，可読性を損なう可能性がある．このよスコードを発見，調査するための手法は，広く研究さ

うにコードが著しく分散する例としては，エラー処理

れている．

やロギングなどの横断的関心事があり，100 以上のメSNIAFL は，メソッド群から，そのメソッドに関

ソッドに分散する事例などが報告されている [2]．こ係する機能への対応関係を抽出する情報検索手法でのような横断的関心事に対しては，複数の類似したある [37]．この手法は，各機能の実行の様子を表現す

コード断片を簡潔な 1 つのコードとして提示，保守る擬似実行トレースを出力としている．我々の手法を行う Fluid AOP [9] のアプローチが有効であるとは，このような手法によって得られた機能の静的な構考えられる．また，Seesoft [5] のように，1 つのファ造を調査するのに有益である．

イルを 1 つのファイルの長さに比例した長方形で表我々の手法に近いものとして，Chen らの依存グラ示し，関心事に対応する行に相当する部分を着色してフを用いたアプローチがある [4]．Chen らの手法は，表示することでプログラム全体におけるコード分布

スライシング基準からの依存グラフを作成した上で，を表示する手法なども利用可能である．

ユーザが調査したい頂点の選択と，検索用の依存グ

ソースコードだけでなく実行履歴情報を用いたアラフの更新を繰り返す対話的な環境を提案している．

プローチとして，Walkinshaw らの手法がある [34]．

我々の手法は，スライシング基準の選択以降の作業

この手法は，特定のユースケースやシナリオでプロをヒューリスティクスによって自動化している点で異グラムを動作させ，その実行履歴情報から構築したなっている．

コールグラフのうち，重要だと思われる部分グラフ

Krinke は，スライシング基準からの距離を制限しを抽出する．入力として，開発者が調べたいメソッド

た Length-Limited Slicing を提案している [17]．これ群（landmark methods）を指定させ，その間のパス

は，我々の手法におけるヒューリスティクスの代わりを含むコールグラフを抽出する．また，実行履歴情に，プログラム依存グラフ上の距離を用いたものだ

報を用いるもう 1 つの手法として，Eisenbarth らにと考えることができる．我々の手法は，グラフ上の距よる Formal Concept Analysis を用いた手法がある

離ではなく，キーワードを含む複数のメソッドからの[6]．この手法は，実行履歴ごとにどの機能を実行した

距離や，入次数を用いた基準によって訪問を停止するかというキーワードを設定することで，特定のキー

ヒューリスティクスを用いることで，関心事に該当す

ワードに対応する手続きの発見を行う．これらの動的るコードを抽出している．

解析手法は，機能に対応するコードを特定するために

Shepherd らは，ソースコードに対する自然言語解
析に基づいた関心事の抽出を提案している [28]．この

多数の入力と実行履歴の観測が必要であることから，
我々は静的解析のアプローチを採用した．

手法は，あるメソッドが所属する関心事を，識別子やKersten らが開発している開発支援ツール Mylar

コメント中に登場する単語から取り出せる動詞とそ

は，統合開発環境において開発者が頻繁に参照しての目的語になる名詞のペアであると定義している．こいるプログラム要素群を関心事とみなす DOI モデルの手法により開発者は，実装がソースコード上で分散を用いている [14]．Mylar の DOI モデルは，開発者

Vol. 0 No. 0

1983

19

の作業内容に従って開発環境上での表示状態（強調，究（スタートアップ）（課題番号:19800021）の助成を非表示）を変更することで，開発者の効率的な作業を得た．

支援する．我々の提案手法の出力で得られた関心事グ
ラフに対応するファイル集合と，Mylar によって得参 考 文 献られたファイル集合とを比較することで，開発者が存[ 1 ] Binkley, D., Gold, N., and Harman, M.: An Empirical Study of Static Program Slice Size, ACM
Transactions on Software Engineering Methodology, Vol. 16,No. 2(2007), pp. 8.
[ 2 ] Bruntink, M., van Deursen, A., van Engelen, R., and Tourwé, T.: On the Use of Clone
Detection for Identifying Crosscutting Concern
Code, IEEE Transactions on Software Engineering,Vol. 31,No. 10(2005), pp. 804–818.
[ 3 ] Chan, K., Liang, Z. C. L., and Michail, A.: Design Recovery of Interactive Graphical Applications,
Proceedings of the 25th International Conference on
Software Engineering, 2003, pp. 114–124.
[ 4 ] Chen, K. and Rajlich, V.: Case Study of Feature
Location Using Dependence Graph, Proceedings of
the 8th International Workshop on Program Comprehension, 2000, pp. 241–247.
[ 5 ] Eick, S. G., Steﬀen, J. L., and Jr., E. E. S.:
Seesoft-A Tool for Visualizing Line Oriented Software Statistics., IEEE Transactions on Software
Engineering, Vol. 18,No. 11(1992), pp. 957–968.
[ 6 ] Eisenbarth, T., Koschke, R., and Simon, D.:
Locating Features in Source Code, IEEE Transactions on Software Engineering, Vol. 29,No. 3(2003),
pp. 210–224.
[ 7 ] Fjeldstad, R. K. and Hamlen, W. T.: Application Program Maintenance Study: Report to Our
Respondents, Proceedings of GUIDE 48, April 1983.
[ 8 ] Hamou-Lhadj, A. and Lethbridge, T. C.: Reasoning about the Concept of Utilities, Proceedingsof the Workshop on Practical Problems of Programming in the Large, 2004.
[ 9 ] Hon, T. and Kiczales, G.: Fluid AOP Join Point
Models, Proceedings of the 2nd Asian Workshop
on Aspect-Oriented Software Development, 2006,
pp. 14–17.
[10] Horwitz, S., Reps, T., and Binkley, D.: Interprocedural Slicing Using Dependence Graphs, ACM
Transactions on Programming Languages and Systems, Vol. 12,No. 1(1990), pp. 26–60.
[11] Inoue, K., Yokomori, R., Yamamoto, T., Matsushita, M., and Kusumoto, S.: Ranking Signiﬁcance of Software Components Based on Use Relations, IEEE Transactions on Software Engineering,Vol. 31,No. 3(2005), pp. 213–225.
[12] Jackson, D. and Rollins, E. J.: A New Modelof Program Dependences for Reverse Engineering,
Proceedings of the 2nd ACM SIGSOFT Symposium
on Foundations of Software Engineering, 1994,
pp. 2–10.
[13] 亀田大輔, 滝本宗宏: プログラムスライシングに基づく関心事グラフ構築, 情報処理学会論文誌: プログラミン
グ, Vol. 46,No. SIG 11 (PRO 26)(2005), pp. 45–56.

在に気づいていないファイルの再発見や，提案手法の出力には含まれていたが実際には不要な要素の除去などを行うことができる．

6 まとめ
機能的関心事を実現するプログラム要素を発見し，それらの間の相互作用を理解することは，ソフトウェ
アの保守作業において非常に大きな割合を占めている．
我々は，開発者が着目した関心事について，手がかりとなるプログラム文の集合とキーワードをもとに関心事グラフを抽出する手法を提案した．本手法は，プログラムスライシングに基づいているが，プログラ
ム依存グラフ上での辺の入次数，キーワードを含んだメソッドからの距離を用いたヒューリスティクスによって，関心事に含まれると推測されるプログラム文
だけをスライスとして出力している．
提案手法に基づくスライシングツールを実装し，

jEdit および提案手法を実装したツールを対象とした適用実験を行った．その結果，従来のプログラムスライシング手法に基づく手法と比べ，人間が作成したものにより近い関心事グラフを抽出していることを確認した．
今後の課題としては，対話的に興味あるメソッドや
フィールドを追加していくことで関心事グラフを構築していく環境の実現が挙げられる．また，メソッド単位で頂点を作成した依存グラフを用いたプログラム
スライスの近似解計算 [1] や，コールグラフだけを用いた計算など，スライシング計算を簡略化した場合での実行時性能および出力結果のトレードオフを評価する予定である．
謝辞 有益なご助言をいただきました University of

British Columbia, Gail Murphy 教授および匿名のPPL2007 査読者に心より深く感謝いたします．
本研究は，日本学術振興会科学研究費補助金若手研20コンピュータソフトウェア[14] Kersten, M. and Murphy, G. C.: Mylar: a
Degree-of-Interest Model for IDEs, Proceedingsof the 4th International Conference on AspectOriented Software Development, 2005, pp. 159–168.
[15] Komondoor, R. and Horwitz, S.: Eﬀective, Automatic Procedure Extraction, Proceedings of the
11th International Workshop on Program Comprehension, 2003, pp. 33–42.
[16] Krinke, J.: Slicing, Chopping, and Path Conditions with Barriers, Software Quality Journal,
Vol. 12,No. 4(2004), pp. 339–360.
[17] Krinke, J.: Visualization of Program Dependence and Slices, Proceedings of the 20th IEEE International Conference on Software Maintenance,
2004, pp. 168–177.
[18] Lhotak, O. and Hendren, L.: Context-Sensitive
Points-to Analysis: Is It Worth It?, Proceedingsof the 15th International Conference on Compiler
Construction, 2006, pp. 47–64.
[19] Marin, M., Moonen, L., and van Deursen, A.:
SoQueT: Query-Based Documentation of Crosscutting Concerns, Proceedings of the 29th International Conference on Software Engineering, 2007,
pp. 758–761.
[20] Marin, M., van Deursen, A., and Moonen, L.:
Identifying Aspects using Fan-in Analysis, Proceedings of the 11th Working Conference on Reverse
Engineering, 2004, pp. 132–141.
[21] Murphy, G. C., Kersten, M., Robillard, M. P.,
and Cubranic, D.: The Emergent Structure of Development Tasks, Proceedings of the 19th European Conference on Object-Oriented Programming,
LNCS, Vol. 3586, 2005, pp. 33–48.
[22] Myers, C. R.: Software Systems as Complex
Networks: Structure, Function, and Evolvability ofSoftware Collaboration Graphs, Physical Review E,
Vol. 68,No. 4(2003), pp. 046116.
[23] Oezbek, C. and Prechelt, L.: JTourBus: Simplifying Program Understanding by Documentationthat Provides Tours Through the Source Code, Proceedings of the 23rd International Conference on
Software Maintenance, 2007, pp. 64–73.
[24] Reps, T., Horwitz, S., Sagiv, M., and Rosay, G.:
Speeding up Slicing, Proceedings of the 2nd ACM
SIGSOFT Symposium on Foundations of Software
Engineering, 1994, pp. 11–20.
[25] Robillard, M. P.: Automatic Generation of Suggestions for Program Investigation, Proceedings ofthe 13th Symposium on Foundations of Software
Engineering, 2005, pp. 11–20.
[26] Robillard, M. P.: Tracking Concerns in Evolving Source Code: An Empirical Study, Proceedingsof the 22nd International Conference on Software

Maintenance, 2006, pp. 479–482.
[27] Robillard, M. P. and Murphy, G. C.: Concern
Graphs: Finding and Describing Concerns Using
Structural Program Dependencies, Proceedings ofthe 24th International Conference on Software Engineering, 2002, pp. 406–416.
[28] Shepherd, D., Fry, Z. P., Gibson, E., Pollock,L., and Vijay-Shanker, K.: Using Natural Language Program Analysis to Locate and UnderstandAction-Oriented Concerns, Proceedings of the 6thInternational Conference on Aspect Oriented Software Development, 2007, pp. 212–224.
[29] Shepherd, D., Pollock, L., and Tourwé, T.: Using Language Clues to Discover Crosscutting Concerns, Proceedings of the Workshop on Modelingand Analysis of Concerns in Software, 2005, pp. 1–6.
[30] Storey, M.-A. D., Fracchia, F. D., and Müller,
H. A.: Cognitive Design Elements to Support theConstruction of a Mental Model During Software
Exploration, The Journal of Systems and Software,Vol. 44,No. 3(1999), pp. 171–185.
[31] 谷口考治, 石尾隆, 神谷年洋, 楠本真二, 井上克郎:
プログラム実行履歴からの簡潔なシーケンス図の生成手法, コンピュータソフトウェア, Vol. 24,No. 3(2007),
pp. 153–169.
[32] Vallee-Rai, R. and Hendren, L. J.: Jimple: Simplifying Java Bytecode for Analyses and Transformations, Technical report, Sable Technical Report
1998-4, Sable Research Group, McGill University,
1998.
[33] Valverde, S., Ferrer-Cancho, R., and Solé, R. V.:
Scale-free Networks from Optimal Design, Europhysics Letters, Vol. 60,No. 4(2002), pp. 512–517.
[34] Walkinshaw, N., Roper, M., and Wood, M.: Understanding Object-Oriented Source Code from the
Behavioural Perspective, Proceedings of the 13th International Workshop on Program Comprehension,
2005, pp. 215–224.
[35] Weiser, M. D.: Program slicing, Proceedingsof the 5th International Conference on Software
Engineering, IEEE Computer Society Press, 1981,
pp. 439–449.
[36] Zhao, J.: Applying Program Dependence Analysis to Java Software, Proceedings of the Workshop on Software Engineering and Database Systems, December 1998, pp. 162–169.
[37] Zhao, W., Zhang, L., Liu, Y., Sun, J., and Yang,
F.: SNIAFL: Towards a Static Non-Interactive Approach to Feature Location, Proceedings of the 26th
International Conference on Software Engineering,
2004, pp. 293–303.