情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

プログラム実行履歴を用いたオブジェクト生成関係の可視化
中野 佑紀1

伊達 浩典1

渡邊 結1

石尾 隆1,a)

井上 克郎1

受付日 2011年3月28日, 採録日 2011年12月16日

概要：オブジェクト指向プログラムは，1 つの処理を実行するために一時オブジェクトを多数生成する．
これらのオブジェクトがどのように生成されるかを知ることは，実行している処理の内容を理解するうえで有用である．本研究では，オブジェクト指向プログラムの実行履歴から，オブジェクト間の生成関係を抽出し，有向グラフとして可視化する手法を提案する．提案手法の有効性を評価するために，ケーススタ
ディとして，大学の演習科目で作成された Java プログラムの単体テストに必要なオブジェクトの生成を行
うコードを，可視化された生成関係に基づいて記述した．その結果，61 個のメソッドのうち，46 個のメ
ソッドのテストに必要なオブジェクトを生成するコードを記述することができ，可視化されたグラフからオブジェクトの生成関係を読み取れることを確認した．
キーワード：プログラム理解，動的解析，ソフトウェア可視化

Visualizing Relationship of Object Generation
Based on Execution Trace
Yuki Nakano1

Hironori Date1 Yui Watanabe1
Katsuro Inoue1

Takashi Ishio1,a)Received: March 28, 2011, Accepted: December 16, 2011

Abstract: Object-oriented programs generate many temporary objects to execute a functionality. Understanding how objects are generated is useful to understand the behavior of a program. In this research, we
propose a technique to identify relationship of object generation; for each object, we visualize a set of objects
which aﬀects the object construction. To evaluate our approach, we have conducted a case study on Java
programs written by undergraduate students. The visualized object generation relationship enabled us towrite code to generate objects for test cases for 46 of 61 methods in the programs.
Keywords: program comprehension, dynamic analysis, software visualization

1. まえがき
ソフトウェアのデバッグや保守作業では，その対象とクトとして管理されているため，オブジェクトの内容を調べることが，プログラム理解において重要であると考えられる．

なっているソフトウェアの構造や振舞いを正しく理解する

オブジェクト指向プログラムの実行中に，オブジェクトことが重要である．LaToza ら [1] は，保守作業に要する時がどのように生成されるかをソースコードのみから調べる

間の多くはプログラム理解に費やされていると述べており，ことは容易でない．なぜなら，オブジェクトの生成とは，また，開発者が頻繁に行う作業の 1 つとして，オブジェク

オブジェクト用のメモリ領域を初期化するだけでなく，そトの生成に関する処理の調査をあげている．オブジェクトのあとにオブジェクトに適切なデータを格納する一連の処

指向プログラムにおいて，重要なデータはすべてオブジェ理が続く場合があるためである．たとえば，GUI アプリ

1

ケーションにおけるウィンドウの生成方法を知りたい場a)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University, Suita, Osaka 565–0871, Japanishio@ist.osaka-u.ac.jp

c 2012 Information Processing Society of Japan合，コンストラクタを呼び出すことで空のウィンドウを作成するという処理だけでなく，そこに適切な部品を追加す

1166

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

る処理の完了までを調査する必要がある．また，動的束縛

本研究において，オブジェクト生成とは，オブジェクトを使用したオブジェクト指向プログラムの実行の流れは局のためのメモリ領域を確保し，適切なデータを格納するこ所的なソースコードの情報のみでは確定しないことがあるとで，外部から利用可能な特定の状態を持ったオブジェク

ため，単純にソースコードを追跡するだけでは，生成処理

トを生成することと定義する．オブジェクトは，生成後もの理解は困難である．

状態が変化することはあるが，最初に外部からデータの参

そこで本研究では，オブジェクト指向プログラムの実行照が行われるまでを，オブジェクトの生成と考える．そし履歴を解析することにより，実際のプログラム実行でオブて，オブジェクトの生成を調査するという作業は，その生ジェクトがどのように生成されたかを可視化する手法を提成処理を実行したオブジェクトと，その過程で参照された

案する．具体的には，あるオブジェクトについて，そのオ

オブジェクト群を特定する作業となる．たとえば，GUI ア

ブジェクトのコンストラクタを呼び出したオブジェクト

プリケーションにおけるウィンドウの生成に関係したオブや，オブジェクトに格納したデータを提供したオブジェク

ジェクトとは，ウィンドウのコンストラクタを呼び出したトを特定し，オブジェクトを頂点，制御とデータの流れをオブジェクトや，ウィンドウに追加された GUI 部品オブ辺としたオブジェクト生成関係グラフを抽出する．

ジェクトのことを指す．

本研究で提案する生成関係の有効性を評価するために，

オブジェクトの生成を調査する作業は，プログラムのあ

大学の演習科目で作成されたプログラムに対して提案手法

る時点から，過去にデータフローをさかのぼっていく作業を適用し，プログラムの単体テストに必要なオブジェクトとなる．このようなデータフローを調査する手法の 1 つとを生成するコードを記述するケーススタディを実施した．

して，プログラムスライシングが知られている [11]．しか第 1 著者が，テスト対象となっているクラスおよびテスト

し，プログラムスライシングは，次のような理由から，オが完了したクラス以外のコードの閲覧を禁止した状態で，ブジェクトの生成を調査する作業に適していない．

可視化された生成関係を閲覧しながらテストの作成作業を• オブジェクトの生成は，コンストラクタの実行だけで行ったところ，61 個のメソッドのうち，46 個のメソッド

なく，それ以降にデータ登録などの処理が実行されるのテストに必要なオブジェクトの生成手順を理解することことが多い．オブジェクトへの参照を格納した変数にが可能であった．この結果は生成関係という情報の有用性

関するデータフローだけをたどっていくと，その参照を示している．

変数の値を決定したコード位置（Java の場合は new の

本論文の貢献は，次の 2 点である．

結果を代入した位置）を追跡することは容易であるが，• オブジェクトの生成関係という概念を定義し，Java プ

単純に new の位置だけを特定しても，生成が完了してログラムの実行履歴から生成関係を自動抽出する動的解析手法を提案した．

いない状態のオブジェクトしか得られない．

• オブジェクトは，生成完了後，外部から様々なデータ• 提案手法の定義では，ライブラリなど，実行履歴を取要求を受け取り，外部にデータを提供するため，オブ得できない対象の取扱いを明示した．これは，Java プ

ジェクト間のデータ依存関係が複雑になる．オブジェ

ログラムの動的解析を試みる研究者にとって有用な情クトに格納されたデータの由来を直接調査しようとし報である．

ても，生成関係以外のデータフロー情報が混在した状

本論文の構成は次のとおりである．まず，2 章で本研究

況で調査を行わなければならない．

の背景について述べ，3 章で提案手法について説明する．

本研究では，実行時情報を用いて，各オブジェクトに対4 章では実施したケーススタディについて説明する．5 章

して，そのオブジェクトの生成に関わったオブジェクトをでは関連研究を紹介する．最後に 6 章で本研究のまとめと特定する．プログラムスライシングは，開発者が興味ある

今後の課題について述べる．

特定のデータに関するすべての命令を取り出す手法となっ

2. 背景ているが，本研究では，命令の列ではなく，特定のオブジェ
クトの生成に関与したオブジェクトの集合を提示すること

プログラムのデバッグや保守作業において，開発者が知で，開発者に対して，オブジェクト生成に関する情報を簡りたい情報とは，振舞いを調査しようとしている処理の実潔に提示することを目指す．動的解析を用いた理由は，同行に必要なオブジェクトの状態である．デバッグ作業でじクラスのオブジェクトであっても，その状態の違いによは，ある時点で不正な状態のオブジェクトを発見した場合

り，プログラム内部でのオブジェクトの使用方法が異なるに，そのオブジェクトの生成に関与したオブジェクトを特場合があるためである [7]．そのようなオブジェクトの区別

定し，その不正な状態の原因を調査する必要がある．また，を，静的解析では正確に行うことができない [5] ため，本保守作業においても，処理に必要なデータを持つオブジェ研究では，実行時情報を使って，生成されたオブジェクト

クトがいつ，どのように生成されているかを調べる必要がをそれぞれ区別して取り扱う．

ある．

c 2012 Information Processing Society of Japan

1167

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

ドを記録する．

3. 提案手法• フィールドおよび配列に対する読み書きの直前と直後

本研究では，開発者が理解したいプログラムの実行を観に，処理を実行したオブジェクトとメソッド，読み書

測し，オブジェクトの生成関係を有向グラフとして可視化

き対象のオブジェクト，読み書きした値を記録する．

する手法を提案する．対象言語には Java を選択した．

すべての実行イベントは，スレッドに関係なく一意に順

2 つのオブジェクト A，B について，オブジェクト A が序を特定するタイムスタンプを付与しておく．コンストラ

オブジェクト B の生成に関与する方法を，次の 3 つの有向

クタ呼び出しは，戻り値が void 型のメソッド呼び出しとし辺で表現する．

て表現する．また，クラスメソッド（static メソッド）のT RIGGER

A −−−−−−−→ B ：オブジェクト A が，コンストラクタ呼

呼び出しやクラスフィールド（static フィールド）に対す

び出しか，それに類するメソッドの呼び出しを実行し，る読み書きは，それぞれのクラスに対してただ 1 つ存在す

オブジェクト B を構築した．

るクラスオブジェクトを対象とした操作であると見なす．

BASE−AA −−−−−−→ B ：オブジェクト A がオブジェクト B のフィールドに格納された．

引数および戻り値に登場する文字列オブジェクトに関して
は，生成関係を特定した後の分析を容易にするために，そBASE−U

A −−−−−−→ B ：オブジェクト A が，オブジェクト B に
何らかのデータを渡した．

の値を記録している．また，値がプリミティブ型であった
場合は，実行履歴のサイズを処理可能な範囲に抑えるとい

TRIGGER 辺はオブジェクトの生成に関する制御フロー

う実装の制約上，型のみを記録している．

を，BASE-A 辺と BASE-U 辺はオブジェクト間のデータ

このイベント履歴から，オブジェクト生成関係の特定にフローを表現している．TRIGGER 辺の順序は時系列を反必要な情報として，メソッド呼び出し call，フィールドお映しており，古いオブジェクトから，新しいオブジェクト

よび配列の読み書き access を次のように抽出する．

へと辺が引かれる．BASE-A 辺と BASE-U 辺については，

メソッド呼び出し call は，9 項組 tcall , tret , o1 , m1 , o2 , m2 ,多くの場合は，辺が時系列を表現するが，厳密な順序関係

P, s, r である．tcall は呼び出しが生じた時刻，tret は呼びは保証されない．たとえば，オブジェクト A がコンストラ

出しが終了した時刻である．o1 ，m1 はそれぞれ呼び出し

クタ内部で “this.f = new B();” という文を実行した場側のオブジェクト，メソッドであり，o2 ，m2 は呼び出し

合は，A −−−−−−−→ B ，B −−−−−−→ A という循環依存が先のオブジェクト，メソッドである．P = {p1 , . . . , pn } は，生じる．

呼び出しの引数に登場したオブジェクトのリストである．

T RIGGERBASE−A

このグラフを用いて，あるオブジェクトから矢印の向き

s = {return, exception} は，呼び出しが正しく終了したとを逆向きにたどっていくと，そのオブジェクトの生成に関き return，例外が発生したとき exception となる．r は，与したすべてのオブジェクトを得ることができる．本研究

メソッドの戻り値あるいは発生した例外のオブジェクトをでは，実行履歴を用いてグラフを作成するため，各辺に対格納し，戻り値がオブジェクト以外の場合は型名を保持す応する実行時のイベント情報を閲覧することで，開発者は，る．これらの情報は，通常，メソッドの呼び出し側と，そいつ，どのように，オブジェクトが生成されたかを知るこれに対応して発生したメソッド実行のイベントから抽出とができる．

する．
T RIGGER

以降の説明では，A −−−−−−−→ B となる A，B につい

本研究では，開発者が指定したライブラリのメソッドのて「A は B の TRIGGER である」
，A −−−−−−→ B あるい

実行内容は，実行履歴の取得対象外とする．ライブラリへ

は A −−−−−−→ B であれば「A は B の BASE である」とのメソッド呼び出しと，ライブラリから解析対象部分へのいう表現を用いる．

メソッド呼び出しだけを記録しておき，ライブラリの動BASE−ABASE−U作と見なす．たとえば，オブジェクト o1 のメソッド m1

3.1 実行履歴のモデル

が，java.util.HashSet クラスのオブジェクト o2 に対して

本研究では，Java プログラムの実行履歴を，メソッド呼add メソッドを呼び出し，引数としてオブジェクト o3 を

び出しと，フィールドおよび配列へのアクセスの列である

渡したとする．この add メソッドが，内部で o3 に対してと考えて解析を行う．観測するイベントは，以下のとおり

hashCode メソッドを呼び出したとすると，観測できるのである．

は o1 から o2 への呼び出しイベントと，o3 のメソッド実行• メソッド，コンストラクタの呼び出しの前後で，現在

イベントとなる．このとき，o1 のメソッド m1 が o2 の add処理を実行中（呼び出し側）のオブジェクトとメソッを，o2 の add メソッドが o3 の hashCode メソッドをそれ

ド，呼び出しの引数となったオブジェクト，戻り値（あぞれ呼び出したと解釈し，2 つの call を抽出する．このとるいは発生した例外）オブジェクトを記録する．

き，o2 が内部で他のオブジェクトやメソッドを使っていた• メソッド，コンストラクタの実行開始と終了で，処理としても，その内容は無視する．この方式は，ライブラリを実行する（呼び出された側）オブジェクトとメソッに所属するオブジェクトを呼び出したとき，ライブラリ全

c 2012 Information Processing Society of Japan

1168

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

call(t1 , t5 , o1 , prepare , o2 , <init> , {}, return, void)call(t2 , t3 , o2 , <init> , o3 , <init>, {}, return, void)
access(t4 , write, f ield, o2 , <init> , o2 , o3 )call(t6 , t10 , o1 , prepare , o4 , <init> , {}, return, void)call(t7 , t8 , o4 , <init> , o5 , <init>, {}, return, void)
access(t9 , write, f ield, o4 , <init> , o4 , o5 )call(t11 , t14 , o1 , prepare , o2 , add , {o4 }, return, void)call(t12 , t13 , o2 , add , o3 , add, {o4 }, return, boolean)call(t15 , t17 , o1 , prepare , o6 , <init> , {o2 }, return, void)
access(t16 , write, f ield, o6 , <init> , o6 , o2 )図 2 実行履歴の例から抽出されるモデル

Fig. 2 The execution model for the example trace.
図 1 実行履歴の例

Fig. 1 An example of execution trace.

体の動作をその 1 オブジェクトが担当していると見なして動作を近似するものとなっており，他の動的解析手法 [4]で用いられているものと同様である．
フ ィ ー ル ド や 配 列 の デ ー タ へ の ア ク セ ス は ，7 項 組

taccess , op, d, o1 , m1 , o2 , v によって表現される．taccess は，フィールドあるいは配列への読み書きの直前に対応するイ
ベントの時刻である．op = {read, write} は，読み書きの種類を表す．d = {f ield, array} は，アクセスしたデータ

Obj(v) 値 v がオブジェクトであるとき真，それ以外のとき偽を返す．

K(t) 時刻 t よりも前のイベントに出現したすべてのオブジェクトの集合を意味する．
これらの関数を使って，値 v が時刻 t で新しいオブジェ
クトであれば真を返す関数 N ew，値 v が既知のオブジェ
クトまたは null，プリミティブ値であれば真を返す関数

Exist を次のように定義する．

がフィールドの場合 f ield，配列の場合は array という値

N ew(v, t) = Obj(v) ∧ v ∈/ K(t)

をとる．o1 はアクセスを行ったオブジェクト，m1 はそのExist(v, t) = ¬N ew(v, t) ∧ v = void

とき実行中だったメソッド，o2 はアクセスされたオブジェ
クトをそれぞれ表現する．v は，op = read のときは読み

上記の関数に加えて，以下の条件のいずれかに該当する

出された値，op = write のときは書き込んだ値であり，オメソッドの集合を，生成に関係するメソッド集合 CM とブジェクトあるいはプリミティブ型名を格納する．これらして定義する．

の属性値は，フィールドあるいは配列へのアクセスの前後( 1 ) コンストラクタ．

に記録された情報から抽出される．

( 2 ) オブジェクトの状態を変更することを目的とするメ

この抽出処理の例を示すため，実行履歴の例を図 1 にソッド．経験的な基準から，メソッド名の最初の単語示す．この図は，縦軸を時間軸，横軸をオブジェクトとしが set，add，put，push，oﬀer，append，insert，replace

たもので，オブジェクト間でのコンストラクタ（<init>）のいずれかであるメソッドを，このカテゴリに含める．

やメソッドの呼び出しと，メソッドからの戻りを水平方向( 3 ) コンストラクタや状態変更メソッドの実行中に生成処の矢印で示している．また，“o2.list=o3;” のような記述

理の一部として実行されるメソッド．具体的には，同は，その時点でフィールドへの代入が実行されたことを示

一クラスに定義されたコンストラクタや状態変更メ

している．左側に示された t1 , t2 , · · · という並びは，縦軸

ソッドの中からのみ呼び出されうるメソッドを，このでの各位置に該当する時刻を意味するラベルである．このカテゴリに含める．

実行履歴を call と access の列に変換したものが図 2 であまた，メソッド集合 CMlib を，CM のうち，ライブラリる．たとえば t12 に実行された o2 の add メソッドから o3に所属する，すなわち観測対象外となっているメソッド群の add メソッドへの呼び出しは，引数が o4 であり，戻りを意味する部分集合と定義する．

値として boolean 型の値を返し，t13 に終了したことを示している．

あるオブジェクトは，他のオブジェクトによってデータ参照などが行われた時点で，初期化が完了していると考えらえる．そのため，ある 1 つのオブジェクトについて，コ

3.2 オブジェクト生成関係の特定

ンストラクタの実行が完了した後，そのオブジェクトの実行履歴に記録されたイベントを実行された順に解析しCM に属さないメソッドが 1 回でも呼び出されると，そのていくことで，オブジェクト生成関係の特定を行う．オブ

時点でオブジェクトの生成が完了したと見なし，それ以降

ジェクト生成関係を形式化するにあたって，まず，次の 2の時刻におけるそのオブジェクトに関するメソッド呼び出つの関数を定義する．

しは，生成関係の特定処理から除外する．

c 2012 Information Processing Society of Japan

1169

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

3.2.1 TRIGGER の特定

出しの引数や戻り値に新しいオブジェクトが出現した場合

通常，オブジェクトが構築されるときには，コンストラに，T4 および T5 は新しいオブジェクト自身が何らかのクタが呼び出されるため，コンストラクタ呼び出しイベン

メソッドを実行するかフィールドのアクセスを行った場合トを調べることで TRIGGER を特定できる．しかし，ラに，T6 は新しいオブジェクトに対するフィールドアクセ

イブラリの中で作られるオブジェクトについては，コンススが生じた場合に，T7，T8 および T9 は新しいオブジェ

トラクタ呼び出しを観測できない．そこで本手法では，コ

クトへの参照がフィールドや配列の読み書きに登場した場

ンストラクタ呼び出しが観測できなかったオブジェクト

合に，それぞれ対応する．T8 は，フィールドの値が新しについては，イベントに初めて登場した時点で，オブジェ

いオブジェクトのとき，所有者がオブジェクトを生成したクトが構築されたと見なす．main メソッドなど，処理をと解釈する．T9 は，配列オブジェクト自身が要素を生成

呼び出す側のコードが観測対象外である場合，TRIGGERすることはありえないため，配列を生成したオブジェクトを特定することが不可能な場合がある．このような場合にが要素も生成したと解釈する．どのルールが適用された場

は，UNKNOWN オブジェクトという形式上のオブジェク

合であっても，本研究では，観測している実行履歴に最初トが，そのオブジェクトを構築したと出力する．

に出現した時刻に，コンストラクタ呼び出しに相当する処

静的オブジェクトはクラスを利用する際に Java の仮想マシンによって自動的に初期化されるため，TRIGGER と理が実行されたと見なす．

3.2.2 BASE の特定

なるオブジェクトは存在しない．その他の実行履歴に登場

各イベントで利用されたオブジェクトが生成に利用されしたオブジェクトには，必ず 1 つ，メモリ上に作られたたかを判断することで BASE-A，BASE-U の特定を行う．

他のオブジェクトあるいは UNKNOWN オブジェクトが，2 つのオブジェクト o1 と o2 の間に以下の関係があるとき，

TRIGGER として存在することになる．

オブジェクトは生成に利用されたと考える．

メソッド呼び出しイベントから TRIGGER を抽出する• o1 への参照が o2 のフィールドに代入された．

ルールを表 1 に，データアクセスイベントから TRIGGER• o1 のメソッドが o2 に対して，名前が add や set などを抽出するルールを表 2 にそれぞれ示す．全部で 9 個のの単語で始まるメソッドを呼び，引数としてデータをルールがあるが，すべてのコンストラクタ呼び出しが記録渡した．

された実行履歴が与えられた場合，必要なルールは T1 だけである．残るルールは内部の観測が不可能なライブラリへの対応となっており，T2 および T3 は他のメソッド呼び• o1 のメソッドを o2 が呼び出し，何らかの値を o2 が取り出した．

• o1 のフィールドを o2 が読み出した．
このような考え方に基づいて，7 つのルールを作成した．

表 1

メソッド呼び出しイベント call(tcall , tret , o1 , m1 , o2 , m2 , P,

メソッド呼び出しイベントから BASE を抽出するルールs, r) からの TRIGGER の抽出ルール

を表 3，データアクセスイベントから BASE を抽出する

Table 1 The rules to extract TRIGGER from a method call
events call(o1 , m1 , o2 , m2 , P, t, r).

を呼び出して新しいオブジェクトが返ってくれば，呼び出

番号

条件生成される辺T1

N ew(o2 , tcall )o1 −−−−−−−→ o2

T2

N ew(pi , tcall )o1 −−−−−−−→ pi

T3

N ew(r, tret )o1 −−−−−−−→ r

T4

N ew(o1 , tcall )U N KN OW N −−−−−−−→ o1

T RIGGERT RIGGERT RIGGERT RIGGER

ただし P = {p1 , . . . , pn } である．

表 2

ルールを表 4 にそれぞれ示す．B1 は，何らかのメソッド
し対象のオブジェクトと引数が，新しいオブジェクトに関係したと考える．また，B2 では，ライブラリに所属する

add などのメソッド呼び出しで，オブジェクトを生成しないものは，オブジェクトの初期化に関するものであると考える．B3 と B4 は，生成に関連したメソッドから，ライブ

データアクセスイベント access(taccess , op, d, o1 , m1 , o2 , v) からの TRIGGER の抽出
ルール

Table 2 The rules to extract TRIGGER from access(taccess , op, d, o1 , m1 , o2 , v).
番号条件生成される辺T5

N ew(o1 , taccess )U N KN OW N −−−−−−−→ o1

T6

N ew(o2 , taccess )o1 −−−−−−−→ o2

T7

op = write ∧ N ew(v, taccess )o1 −−−−−−−→ v

T8

op = read ∧ d = f ield ∧ N ew(v, taccess )o2 −−−−−−−→ v

T9op = read ∧ d = array ∧ N ew(v, taccess )o2 −−−−−−−→ v

T RIGGERT RIGGERT RIGGERT RIGGERT RIGGERT RIGGER

ただし o2 は o2 −−−−−−−→ o2 を満たす
オブジェクト．

c 2012 Information Processing Society of Japan


1170

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

表 3 メソッド呼び出しイベント call(tcall , tret , o1 , m1 , o2 , m2 , P, s, r) からの BASE の抽出
ルール

Table 3 The rules to extract BASE from call(tcall , tret , o1 , m1 , o2 , m2 , P, s, r).
番号条件生成される辺B1

s = return ∧ N ew(r, tret )o2 −−−−−−→ r, pi −−−−−−→ r

BASE−U

BASE−U

BASE−AB2

s = return ∧ Exist(r, tret ) ∧ m2 ∈ CMlib

pi −−−−−−→ o2

B3

s = return ∧ Exist(r, tret ) ∧ m1 ∈ CM

o2 −−−−−−→ o1 , pi −−−−−−→ o1

BASE−U

BASE−U

∧m2 ∈
/ CM
B4

s = return ∧ m1 ∈ CMlib ∧ m2 ∈/ CM ∧ Obj(r)BASE−Ar−−−−−−→ o1

ただし P = {p1 , . . . , pn } である．
表4

データアクセスイベント access(taccess , op, d, o1 , m1 , o2 , v) からの BASE の抽出ルール

Table 4 The rules to extract BASE from access(taccess , op, d, o1 , m1 , o2 , v).
番号条件生成される辺

B5

op = write ∧ Obj(v)v −−−−−−→ o2

B6

op = read ∧ m1 ∈ CM

o2 −−−−−−→ o1

B7

op = read ∧ d = array ∧ N ew(v, taccess )oi −−−−−−→ v, v −−−−−−→ o2

BASE−ABASE−U

BASE−U

BASE−ABASE−U
ただし oi は oi −−−−−−→ o2 を満たす

オブジェクト．

3.3 オブジェクト生成関係の可視化
オブジェクトの生成関係は有向グラフであり，頂点はオブジェクトの情報として，パッケージ名，クラス名，オブジェクト ID の情報を保持する．また，辺は，TRIGGER
および BASE の区別と，生成に関係したイベントの時刻を保持する．ここでのイベントの時刻とは，辺の生成条件に出現する，tcall ，tret ，taccess のいずれかの値である．
図 3

本手法では，開発者が注目するオブジェクトを基点とし
図 2 のモデルから得られるオブジェクト生成関係の例

Fig. 3 A resultant graph for the trace model of Fig. 2.

て，以下の基準で辺を逆向きにたどり，生成に関係するオ
ブジェクトを抽出する．

ラリから外部へのコールバックを取り扱っている．B5 とB6 は，それぞれ，o1 のフィールドに格納されたオブジェ• 基点から，BASE-A のみをたどって到達可能な範囲を探索する．

クトと，o1 の生成途中で参照されるフィールドを持ってい• BASE-U，BASE-A 辺を，直前にたどった辺の時刻よたオブジェクトからの関係を抽出する．最後に，B7 は，配りも前の時刻のイベントから生成されたもののみ探索

列から未知のオブジェクト v が読み出されたとき，v が配する．

列の初期化に使われたことを BASE-A として抽出する．vの生成に関係するオブジェクト oi が後から見つかれば，それらのオブジェクトから v への関係を接続する．
なお，ルールに従って BASE を特定すると，任意のオブ
BASE• 上記の手順で到達した全オブジェクトから，TRIGGER
辺を 1 回だけたどる．

BASE-A は，オブジェクトに格納されたオブジェクトとなっているので，生成順序にかかわらず，すべてのオブジェクト A に対して，A −−−−→ A という関係を特定する

ジェクトが生成に関係したものと見なす．一方，BASE-U

場合があるが，このような同一オブジェクトでの BASE はは，オブジェクトの生成に一時的に関係したものとなって無視する．

いるので，その時点でオブジェクトから参照可能であった

図 2 に示した実行履歴のモデルから生成関係を抽出してものだけを探索する．探索によって発見された BASE オブ

得られるオブジェクト間の関係を図 3 に示す．この図でジェクトに加え，各オブジェクトに対する TRIGGER オ

は，オブジェクトを頂点とし，辺のラベルに適用したルー

ブジェクトを残した状態が，そのオブジェクトの生成に関ルを示している．オブジェクト o6 からルール B2，B5 に係した範囲となる．

よる BASE 関係をたどると，o4 や o5 が o6 の生成に関係

本研究では，提案手法のルールに基づいてグラフの可視していることが読み取れる．この情報は，図 1 の呼び出し化を行うツールを作成した．一般にオブジェクトは多数生

関係のみからでは読み取ることができない情報である．

成されるため，オブジェクト生成関係を閲覧する専用の

c 2012 Information Processing Society of Japan


1171

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

図 4 プログラム L3 の実行履歴から取得したオブジェクト生成関係の例

Fig. 4 A resultant graph extracted from an execution trace of a program L3.

ツールとし，頂点の集約機能を実装した．この集約機能は，

サイズは，空行やコメントも含めたとき，L1 は 9 クラス

1 つのクラスのオブジェクト群が，ある 1 つのオブジェク

594 行，L2 は 8 クラス 1,486 行，L3 は 52 クラス 2,780 行

トに対して同一ラベルの辺を持つとき，オブジェクト群をである．ここで，L2 は L1 に比べて非常に大きく見えるが，

1 つの頂点として表示する．また，オブジェクトを迅速にL2 では独自拡張として，ライフゲームにおける著名な盤

グラフ中から特定するために，クラス名，オブジェクト ID

面のパターンを表示する機能を組み込んでおり，パターンを用いた検索を可能とした．また，辺の表示では，基本情に対応した盤面のデータを約 500 行にわたってハードコー

報として TRIGGER，BASE のラベルを表示し，開発者がディングしているため，実際の機能量に比べて大幅にサイ選択した辺について，その辺に対応するイベント情報を閲

ズが大きくなっていた．また，複数行にわたるコメントお覧できるようにした．

よび空行をレイアウトに数多く使っていたため，実際の有4. ケーススタディ
提案手法を実装したツールを用いて，プログラム理解のケーススタディと，ツールの性能評価を実施した．

効なコードの量は，L1 とほぼ同程度である．L3 は L2 と比べてもサイズが大きいが，L3 の作者は 1 クラスを 1 機能とする形でクラス分割を行った結果，たとえばファイルを読み込むクラスや，それを継承した設定ファイルを読み込

ケーススタディの対象としたのは，大阪大学基礎工学部

むクラス，ライフゲームの盤面を読み込むクラス，といっ情報科学科の 2 年生が演習で作成した「コンウェイのライたようにクラスの定義を行っており，多くのコードをクラフゲーム」プログラムである．このプログラムは GUI をス宣言に費やしている．

持ち，起動するとウィンドウに碁盤目状の「盤面」を表示
する．利用者はマウスを使って，各区画「セル」の状態を

4.1 実行シナリオの分析編集したり，ライフゲームのルールを適用してセルの状態

まず，クラス数が多く特殊な構造を持つとみられる L3を更新したりできる．その他の機能として，盤面を過去のについて，提案手法を用いて，盤面データをファイルから状態に巻き戻す機能や，盤面の状態をファイルに保存する読み込み機能の実行を分析した．調査方法であるが，まず，機能を持つ．

L3 を起動し，盤面の状態を保存しているファイルを開いてプログラム理解に関するケーススタディでは，当該課題

から，L3 を終了するというシナリオを実行し，実行履歴をの内容を知らない第 1 著者が，課題の文書に書かれた外部取得した．この実行履歴に対して，第 1 著者が提案手法を

仕様を読解したのち，3 名の学生が作成したプログラム L1，

適用し，オブジェクトの生成処理を可視化したグラフを取L2，L3 を分析し，グラフに可視化されているオブジェク

得した．図 4 は実行履歴を解析し，盤面の状態を管理する

トの生成方法の有用性を評価した．

オブジェクト CellCaretaker の生成処理の一部を可視化し対象となっている 3 つのプログラムは，同一の要求に基たものである．プログラム L3 のファイルの読み込み機能

づいて作成されているが，作成者ごとに独自の機能が追加の実行では，まず，CellIO オブジェクトがファイルの内容されている．すべての作成者は，設計の例として，基本機を格納した String オブジェクトを生成する．次に，CellIO能に関するクラス分割および各クラスが持つべきメソッド

は，文字列の内容を読み込み，盤面の各セルの状態を表す

名の情報を与えられており，L1 と L2 は，この設計例にCell オブジェクトの集合を生成する．CellCaretaker オブ

従ったプログラム構造を持った学生のプログラムから，ラジェクトは，Cell オブジェクトの集合から，盤面の状態をンダムに選択したものとなっている．一方，L3 は，設計例表現する CellMemento オブジェクトと，盤面の履歴を表に従っていないもののうち，最も複雑であることを期待し現する LinkedList オブジェクトを生成し，盤面の状態が 1て，一番ファイル数が多いものを選択した．プログラムのつだけ登録された状態となる．

c 2012 Information Processing Society of Japan

1172

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

作業を行った第 1 著者は，提案手法によって可視化されの情報から，他のクラスは GUI の実装に対応していたた

たグラフから，図 4 に相当する部分を見つけ，CellIO がめ，テスト対象から除外した．BoardMode クラスは他のCell の生成を，CellCaretaker が CellMemento の生成を実クラスに依存しておらず，BoardHistory は BoardModel

行していること，Cell のデータが CellMemento に格納さクラスに，GameController クラスは BoardHistory クラス

れていることを推測した．その後，推測が正しいことを，に依存していることから，BoardModel，BoardHistory，

CellCaretaker，CellIO，Cell，CellMemento の 4 つのクラ

GameController の順でテストを作成するものとした．なスのソースコードを読解することで達成した．一方で，提お，これらのクラスには，授業の指導書に記載のない，学案手法を使わない調査方法の代表として，デバッガによ

生がそれぞれ追加したメソッドも含まれている．

るステップ実行で，ファイル読み込み機能の実行開始（メグラフからソースコードを作成する作業は，第 1 著者がニューの actionPerformed メソッド）から，ファイル読実施した．第 1 著者の能力が結果に影響するのを避けるた

み込みを追跡した．この方法では，ファイル読み込みの開め，プログラムの実行履歴は，授業での動作確認手順を記始点となった OpenListener クラスから，盤面情報を読み載した手順書に従って，プログラムを起動し，実装が必須

込む CellIO クラスの処理に至るまでに，ファイルを開くとされていた機能をひととおり実行することで記録した．

クラス，ファイルのヘッダを読み込むクラスなど，合計 7

また，グラフに含まれた情報の有効性を評価するため，テつのクラスのコードを通過した．これは，L3 では共通処ストを作成する手順では，オブジェクトの生成としてソー理をできるだけ継承によって親クラスにまとめるようにスコードに記述してよいメソッド呼び出しを，グラフ上でコードが記述されており，読み込んだデータが画面に反映

各クラスのオブジェクトの生成からたどれる範囲に表現さされるまでに，全部で 25 個のクラスのコードが実行されれている呼び出し関係に限定し，引数として使用できるプ

た．提案手法は，ファイルからの盤面の読み込みに無関係

リミティブ型の値は，現在テスト対象となっているクラス

な GUI，ファイル IO などのコードを提示しないため，単のソースコードに定義されている値，そのクラスのコンス

純なデバッガによる処理の追跡などに比べると，簡潔な情

トラクタ呼び出しにハードコーディングされている値に限報を提示できたといえる．

定した．
本実験の結果をまとめたものを表 5 に示す．表 5 にお

4.2 メソッドのテスト用データの作成
オブジェクトの生成に関して十分な情報が可視化されていて，メソッド数とは，テスト対象となった public メソッ
ドの数である．平均 LOC とは，テスト用メソッドにおけいるかを確認するために，ライフゲームの実装 L1 と L2 にる，空行，コメント，テスト用 assert 文を除いたコード

対して，可視化されたグラフの情報から，メソッドの単体

行数の平均である．テスト対象メソッドを実行するためにテストに必要な状態のオブジェクトを生成するコードを記必要な事前準備や，テストすべき値を取り出す処理が長い

述する作業を実施した．L3 は，すでに 4.1 節で分析してほど，この値が大きい．テスト成功メソッド数とは，ホワいるので，対象から除外している．

イトボックステストとしてテスト用コードを評価したと

デバッガや保守におけるプログラム理解に役立つオブ

き，各テスト用コード単独で条件分岐を網羅できるように

ジェクト生成関係とは，ある処理を実行するために必要なオブジェクトを準備できたメソッドの数である．対象としオブジェクトの情報，すなわち，メソッドを実行するオブ

た 61 メソッド中 46 メソッドのテストについて，可視化さジェクトや，その時点で引数やフィールドを介して参照可れたグラフの情報と，対象クラスのソースコード情報を組

能なオブジェクトの状態に関する情報である．グラフがそみ合わせるだけで，必要なオブジェクトの生成コードを記のような情報を含んでいるのであれば，グラフに記述され述することができた．また，Cobertura *1 を用いてすべてた情報をもとに，任意のメソッドについて，そのメソッドのテストをまとめて実行し，行カバレッジおよび分岐カバの単体テストを実施可能な状態のオブジェクトを生成する

レッジを計算したところ，L1 に関しては行カバレッジおソースコード記述が可能であると考えた．単体テストを実よび分岐カバレッジは 100%，L2 に関しては行カバレッジ

施するためには，実行時エラーを起こさず，かつ，十分な

99%，分岐カバレッジ 87.5%となっていた．L1 に関してはカバレッジを達成できるようにオブジェクトを生成しなく

テストメソッドの作成成功の判断に比べ数値が向上していてはならない．テスト対象メソッドごとに，ホワイトボッ

るが，これは，BoardModel の単独のテストでは実行でき

クステストの観点から，条件分岐がすべて網羅できれば，なかった処理が，GameController などのテストにおいてそのメソッドのテストが成功していると判定する．

実行されたためである．L2 については，GameController

テスト対象にしたクラスは，1 枚の盤面の状態を表現する

内部に，GUI でのアニメーション機能に関する条件分岐がBoardModel クラス，盤面の履歴を管理する BoardHistoryあり，その範囲についてはテスト不可能であったため，カクラス，ライフゲームの進行を管理する GameController
クラスの 3 つである．授業の指導書に記載されたクラス

c 2012 Information Processing Society of Japan*1

Cobertura. http://cobertura.sourceforge.net/

1173

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

表 5

メソッドのテスト用オブジェクトの生成結果

Table 5 Result of generating essential objects for method tests.
対象

クラス

メソッド数

7

平均 LOC

テスト成功メソッド数

割合（%）

3

42.86

L1

BoardModel

8.57

L1

BoardHistory

7

3.71

7

100.00

L1

GameController

12

5.50

12

100.00

L2

BoardModel

10

9.50

4

40.00

L2

BoardHistory

8

3.75

7

87.50

L2

GameController

17

26.88

13

76.47

バレッジは 100%に到達しなかったが，GUI に関係ない部
分はすべて実行されていた．結果をまとめると，単体テス
トとして，各テスト用メソッドでテスト対象メソッドの条
件分岐を網羅できたものは 61 メソッド中 46 メソッドであり，テストケース集合全体としては，GUI と無関係に単体テスト可能なコードについては，網羅することに成功していた．

GameController クラス，BoardHistory クラスは，盤面の状態を管理するクラスとなっていることから，少なく
とも 1 つ，ライフゲーム開始時の盤面（BoardModel オブ
ジェクト）の登録が必要であり，そのメソッドを呼び忘れ
ると，いくつかのメソッドは正しく動作しない．また，テ
スト対象の 3 つのクラスにおいて，L1 は 6 個，L2 は 15個のメソッドを独自に実装しており，これらの中には，複数の盤面の状態が履歴として蓄えられたときに初めて実行

図 5

オブジェクト数に対する生成関係特定時間の関係

Fig. 5 Time to identify relationship of object generation.

可能となる（盤面がたかだか 1 つしかない状態で呼び出すとクラッシュする）メソッドが存在していた．これらのメ

した）ものを除外し，56 の実行履歴に対して調査を行った．

ソッドの実行に必要なオブジェクトの生成方法を，外部仕実行履歴に出現したイベント数は最大で 2,500 万，オブ様なしでもグラフから抽出できたことから，オブジェクト

ジェクト数は 30 万であった．実行時オーバヘッドは，主の生成に関する十分な情報をグラフが表現していたと考えとして実行履歴をディスクに保存するために要する時間でられる．

あるが，最も大きいもので 2 分であった．

なお，テストが成功しなかったメソッドについては，実

イベント数とオブジェクト数が，それぞれ生成関係の特行履歴から作成したグラフと，テスト対象クラスのソース定に必要な時間に影響する度合いを調べた結果，イベント

コードのみでは，プリミティブ型の引数の値などに適切な数と計算特定時間の相関係数が 0.45，オブジェクト数と特ものを用意できず，作成することができなかった．たとえ定時間の相関係数が 0.93 となった．このことから，オブば，盤面のある座標にあたるセルが生存しているか，してジェクトの数が生成関係の特定に要する時間と強く関係しいないかを判定するメソッドをテストするには，セルの座ている．解析対象となるオブジェクトの数は，解析の範囲

標の値が必要であるが，テスト対象コードの範囲では，そをたとえば 1 つのメソッドの実行開始から終了までというの値が提供されていなかった．この点は本研究の実装上のように区切れば，容易に制御することができる．

制約に由来しており，プリミティブ値を記録するように実装を拡張すれば対応可能である．

本手法では，1 度にオブジェクト生成関係を特定するオ
ブジェクト数は数万程度を想定している．オブジェクト数
が 5 万以下の実行履歴において，オブジェクト生成関係の4.3 実行性能の調査

特定に必要な実行時間を調査した結果を図 5 に示す．こツールの実行性能を，Intel Xeon(R) E5507 2.27 GHz のの図から，半分以上の実行履歴で 1 分以下，ほとんどの実

ワークステーション上で計測した．解析対象は，Ant と行履歴において 2 分以下でオブジェクト生成関係を特定し

ANTLR の既存のテストケースの実行と，Java の実行ベンており，実行時オーバヘッドまで含めても 5 分程度となっ

チマーク集 DaCapo の各ベンチマークである．実行履歴のたことから，現実的な時間で利用可能なツールであるとい

記録の際に正常に動作しなかった（テストそのものに失敗

える．

c 2012 Information Processing Society of Japan


1174

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

4.4 議論

クト間のメソッド呼び出しを時系列で示すことに主眼を置

ケーススタディでは，第 1 著者が提案手法を用いて，プいているため，図 1 に示した例のように，オブジェクトがログラム理解および単体テストの作成を行った．対象プロ引数に含まれていた場合には，オブジェクト間の関係を読

グラムは第 1 著者は初めて見るプログラムであり，実行履

み取れない場合がある．

歴は授業課題の動作確認用に事前に定義された操作手順を

Rayside ら [8] は，動的解析によって，実行中にどのオ用いている．また，ファイルとして開いてよいソースコー

ブジェクトがどのオブジェクトを保持していたか，所有関ドを，テスト対象クラスおよびテストが完了したクラスに係を特定し可視化する．この手法は，所有関係を可視化す

制限し，テスト記述に使用してよい情報をグラフに示されるが，オブジェクトの構築段階において，一時的にデータた情報に限定することで，グラフの情報をソースコードにを参照する関係については可視化できず，どのようにオブ

手作業で変換するという形式をとり，第 1 著者の推測なジェクトが生成されたかを知りたい場合には使用すること

どが結果に影響しないように実施した．そして，結果の評ができない．

価は，単体テストにおいて，メソッドを呼び出すために必Lienhard ら [2] はオブジェクトがどのオブジェクトを経

要なオブジェクト生成を行うことができたこと，ホワイト

由して移動し，どのオブジェクトで保持されているかを可

ボックステストとしての妥当性，行カバレッジと分岐カバ視化している．また，Lienhard ら [3] は，この手法を利用

レッジによって評価した．L1 と L2 に関する結果から，グして，メソッドの実行中に利用する参照関係とそのメソッ

ラフを閲覧することでオブジェクトの生成に関する情報をド実行によって変化する参照関係を可視化する手法も提案得ることができることを示している．また，L3 に関するしている．これらの手法は，オブジェクトがどのオブジェ

結果から，デバッガによるステップ実行に比べて，データ

クトにアクセスですることが可能であったかを提示し，メフローに関与する少数のクラスだけを迅速に特定できる場

ソッドの実行によって生じた状態変化を知ることができ合があることを示した．

る．本研究では，時系列によって，その時点で実際に利用

この有効性の評価方法は，オブジェクトの関係を可視化する関連研究 [2], [3], [8] と同様に，著者によるケーススタされたオブジェクトだけを提示しており，開発者に提示する情報を減らしているといえる．

ディによる有効性の提示という方式を採用している．プロ

オブジェクトの生成方法を理解するという観点で，2 つグラム可視化手法がプログラム理解に与える影響を直接評の静的解析手法が提案されている．Mandelin ら [6] は，利価することは難しいため [12]，ケーススタディでは，オブ用者が指定した条件を満たすメソッド呼び出し列を生成

ジェクトの使用方法をグラフから読み取ることが可能であ

し，提示する手法を提案している．また，Thummalapenta

る，という情報の含有を評価の基準としている．この可視ら [10] は，ソースコード検索エンジンを用いて集めたコー化が，異なる作業目的ごとのソースコード読解作業の時間

ドサンプルを利用し，利用者が指定したクエリを満たすメをどれだけ効率化するか，という時間面での定量的な評価

ソッド列の候補を提示する手法を提案している．これらのは今後の課題とする．

手法は静的に行われているため，取得するオブジェクトの

なお，提案手法は，プログラムの実行履歴全体を可視化

状態までは完全には再現されないことがある．これらの手するため，本ケーススタディのように，特定のタスクの実法は，複数のプログラムを同時に解析できる点で有意義で施に必要な情報を含んでいることは示すことが可能であるあるが，本研究のように，ある特定のクラスの生成を理解

が，正確さに関しては，他の情報をすべて余計な情報と解するという用途とは目的が異なっている．

釈すると，正確さは実行履歴のサイズによって定まってしまうため，本研究では議論していない．また，ライブラリ

6. まとめや Java 仮想マシンの内部で生じるイベントを含めた完全本研究では，オブジェクトがどのように生成されたかをな生成関係は観測することができないため，それに対するオブジェクト生成関係として特定し，有向グラフとして可正確さも本研究では議論の対象外とした．

視化する手法を提案した．ケーススタディでは，プログラ

5. 関連研究
本研究は，オブジェクトの生成関係を動的解析によってムの特定の機能を分析する際の実例を示し，また，メソッ
ドの単体テストに使用できるようなオブジェクトの生成方法を，グラフから読み取ることができることを示した．

抽出する手法を提案した．動的解析の分野では，オブジェ

今後の課題としては，プログラム理解への有効性を確認

クトの呼び出し関係，所有関係，参照関係を可視化する手する対照実験があげられる．また，実行履歴の取得範囲が法が複数提案されている．まず，オブジェクト間のメッ制限されている環境下での動的解析手法について，本研究

セージのやり取りを UML のシーケンス図として可視化すで使用したルールの一般化を試みる予定である．

る手法が提案されている [9]．この手法は，プログラムがど

謝辞のように動作しているかを知ることができるが，オブジェである．

c 2012 Information Processing Society of Japan

本研究は科研費（23680001）の助成を受けたもの

1175

情報処理学会論文誌

Vol.53 No.3 1166–1176 (Mar. 2012)

参考文献
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

伊達 浩典 （学生会員）

LaToza, T.D. and Myers, B.A.: Developers Ask Reachability Questions, Proc. 32nd ACM/IEEE International Conference on Software Engineering, pp.185–194(2010).
Lienhard, A., Ducasse, S. and Girba, T.: Taking an
object-centric view on dynamic information with object
ﬂow analysis, Computer Languages, Systems & Structures, Vol.35, pp.63–79 (2009).
Lienhard, A., Girba, T., Greevy, O. and Nierstrasz, O.:
Test Blueprints – Exposing Side Eﬀects in Execution
Traces to Support Writing Unit Tests, Proc. 12th European Conference on Software Maintenance and Reengineering, pp.83–92 (2008).
Lo, D. and Maoz, S.: Scenario-based and valuebased speciﬁcation mining: Better together, Proc. 25th
IEEE/ACM International Conference on AutomatedSoftware Engineering, pp.387–396 (2010).
前田直人：コンテキストを考慮したポインタ解析結果を用いたメソッド呼出しパターン検査，コンピュータソフ
トウェア，Vol.26, No.2, pp.157–169 (2009).
Mandelin, D., Xu, L., Bodik, R. and Kimelman, D.:
Jungloid Mining: Helping to Navigate the API Jungle,
Proc. ACM SIGPLAN 2005 Conference on Programming Language Design and Implementation, pp.48–61(2005).
宗像 聡，石尾 隆，井上克郎：類似する振舞いのオブ
ジェクトのグループ化によるクラス動作シナリオの可視化，情報処理学会研究報告，第 163 回ソフトウェア工学
研究発表会，Vol.31, pp.225–232 (2009).
Rayside, D., Mendel, L. and Jackson, D.: A Dynamic
Analysis for Revealing Object Ownership and Sharing,
Proc. 2006 International Workshop on Dynamic Analysis, pp.17–23 (2006).
谷口考治，石尾 隆，神谷年洋，楠本真二，井上克郎：プログラムの実行履歴からの簡潔なシーケンス図の生成手
法，コンピュータソフトウェア，Vol.24, No.3, pp.153–169(2007).
Thummalapenta, S. and Xie, T.: PARSEWeb: A Programmer Assistant for Reusing Open Source Code on
the Web, Proc. 22nd IEEE/ACM International Conference on Automated Software Engineering, pp.204–213(2007).
Weiser, M.: Program slicing, Proc. 5th International Conference on Software Engineering, pp.439–449(1981).
Wettel, R., Lanza, M. and Robbes, R.: Software Systems
as Cities: A Controlled Experiment, Proc. 33rd International Conference on Software Engineering, pp.551–560(2011).

平成 19 年関西大学総合情報学部総合情報学科卒業．平成 21 年大阪大学大学院情報科学研究科博士前期課程修了．現在，大阪大学大学院情報科学研
究科博士後期課程在学中．ソフトウェ
アに対するパターンマイニングの研究に従事．

渡邊 結 （正会員）
平成 20 年大阪大学大学院情報科学研
究科博士前期課程修了．平成 23 年同研究科博士後期単位取得退学．同年日立製作所研究開発本部横浜研究所．在学時，プログラムの動的解析の研究に従事．

石尾 隆 （正会員）
平成 15 年大阪大学大学院基礎工学研
究科博士前期課程修了．平成 18 年同
大学院情報科学研究科博士後期課程修了．同年日本学術振興会特別研究員（PD）．同年ブリティッシュコロンビ
ア大学ポストドクトラルフェロー．平成 19 年大阪大学大学院情報科学研究科コンピュータサイ
エンス専攻助教．博士（情報科学）．データフロー解析，ア
スペクト指向プログラミングに関する研究に従事．日本ソフトウェア科学会，ACM，IEEE 各会員．

井上 克郎 （フェロー）
昭和 54 年大阪大学基礎工学部情報工学科卒業．昭和 59 年同大学大学院博士課程修了．同年同大学基礎工学部情報工学科助手．昭和 59〜61 年ハワイ大学マノア校情報工学科助教授．平成中野 佑紀
平成 23 年大阪大学大学院情報科学研
究科博士前期課程修了．同年株式会社
ニッセイコム．在学時，プログラムの動的解析の研究に従事．

元年大阪大学基礎工学部情報工学科講師．平成 3 年同学科助教授．平成 7 年同学科教授．平成 14年大阪大学大学院情報科学研究科コンピュータサイエンス
専攻教授．平成 20 年国立情報学研究所客員教授．同年情報処理学会フェロー．同年電子情報通信学会フェロー．工学博士．ソフトウェア工学の研究に従事．日本ソフトウェ
ア科学会，電子情報通信学会，IEEE，ACM 各会員．

c 2012 Information Processing Society of Japan

1176