社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

リファクタリングのための変更波及解析を利用したテスト支援ツールの提案
吉田昌友†

吉田則裕†

松下誠†

井上克郎†

† 大阪大学 大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1 番 5 号
E-mail: †{mstm-ysd,n-yosida,matusita,inoue}@ist.osaka-u.ac.jp
あらまし リファクタリングとは，外部的振る舞いを保ちつつ，ソースコードの保守性を改善する作業を指す．リファクタリングを行う開発者は，テストケースを使用してテストを行うことによって，外部的振る舞いが保たれていることを確認する．しかし，大規模ソフトウェアの開発では，膨大な数のテストケースを定義することが多く，その中から外部的振る舞いの検証に必要なもののみを選択し，使用することは困難である．本研究では，Java 言語で記述されたプログラムに対して変更波及解析を行い，実行結果が変化する可能性があるテストケースを編集内容を基に推測することで，リファクタリング支援を行うツールを提案する．
キーワード

リファクタリング，ソフトウェアテスト，変更波及解析，Eclipse プラグイン

A Change Impact Analysis Based Testing Tool for Refactoring
Masatomo YOSHIDA† , Norihiro YOSHIDA† , Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
1-5 Yamadaoka, Suita, Osaka, 565-0871 Japan
E-mail: †{mstm-ysd,n-yosida,matusita,inoue}@ist.osaka-u.ac.jp
Abstract Refactoring is the process that can improve the software maintainability without changing its externalbehavior. When developers perform refactoring, they preserve software’s external behavior by running test cases asregression test. In many cases of large scale software developments, developers create a large number of test cases.
However, it is diﬃcult to select and run only necessary test cases for preserving software’s external behavior. In thispaper, we propose a testing tool for Java program refactoring. This testing tool applies change impact analysis totwo programs before and after editing for the purpose of refactoring, and then infers test cases that have possibility
to change their results.
Key words Refactoring, Software Test, Change Impact Analysis, Eclipse Plug-in

1. は じ め にのリファクタリングを行うことを目的としてコード変換を適用したソースコードのプレビューが Eclipse 上に提示される．プ

リファクタリング [1] とは，外部的振る舞いを保ちつつ，ソーレビューが提示された時点ではソースコードは変換されていなスコードの保守性を改善する作業を指す [2]．Fowler はリファいため，そのコード変換を実際に行うか選択することができる．

クタリングを行うべきソースコードの状態に応じて，さまざまリファクタリングを行う開発者は，ソフトウェアの外部的振なリファクタリングパターンを提案している [2]．そして，いる舞いが保たれていることを確認するために，テストケースをくつかのリファクタリングパターンは，ソースコードを編集す使用してテストを行い，ソースコードを編集する前と編集したる作業に限り統合開発環境 Eclipse [3] のプラグイン JDT(Java後とでテストの実行結果が同じであることを確認する [2]．

development tools) [4] で支援されている（図 1(a)）．JDT とはしかし，大規模ソフトウェアの開発においては，膨大な数のJava 言語でソフトウェアを開発する際に利用できる Eclipse のテストケースを定義していることが多く，リファクタリングをプラグインである．JDT を使用する開発者が，リファクタリン行う度にすべてのテストケースを使用することは効率が悪い．

グを行う対象や行うリファクタリングの内容を設定すれば，そそこで，外部的振る舞いの検証に必要なテストケースのみを選—1—

Eclipse

ソース
コード１．編集内容を設定

リファクタリングを行う対象を選び，編集内容を設定する
コード変換後のソースコードを算出する
算出結果を参照し，実際にコード変換を適用するか決定する
コード変換を適用する

Eclipse JDT

２．実行すべきテスト
ケースを推測

編集された
ソース
コード

テストケース

テストケースを使用して，変換されたソースコードをテストする(a) 既存のリファクタリング支援

ソース
コード
Eclipse JDTテストケース入力入力

編集
された
ソース 入力 変更波及解析
コード出力
編集後に実行結果が２．実行すべきテスト 変化する可能性がある
テストケース
ケースを把握１．編集内容を設定(b) 提案手法

図1

既存のリファクタリング支援機能と提案手法

ソース
コード
編集する
編集
された
ソース
コード
テストする
テスト
ケース

図 2 Eclipse JDT のリファクタリング支援機能を使用する

2. 背景

2. 1 リファクタリング
リファクタリング [1] とは，外部的振る舞いを保ちつつ，ソースコードの保守性を改善する作業を指す [2]．ここで言うソフトウェアの外部的振る舞いとは，ソフトウェアの仕様と言い換えてもよい．内部の構造とは，ソースコードと同義である．ソフ
トウェアの外部的振る舞いを保つことで，ソフトウェアはソースコードを編集する前と同じ機能を提供することができ，ソフ
トウェアの利用者は，ソースコードが編集されたことに気が付かない [2]．

択し，使用することが推奨されている [2]．しかし，特にオブリファクタリングを行う上で，信頼できるテストケースがあジェクト指向プログラムでは，動的に動作が決まる部分があるることは必須条件である [2]．本研究では，信頼できるテストため，必要なテストケースを開発者が選択することは困難でケースとは，そのテストケースを使用したテストを行い，ソーある．

スコードの編集前後で実行結果が同じであれば，そのテスト

このような問題に対して，Ryder らが提案する変更波及解析

ケースで実行する範囲においては外部的振る舞いが保たれていと呼ばれる技術を用いると，ソースコードを編集した後に実行るとみなすことができるテストケースであるとする．信頼でき結果が変化する可能性があるテストケース，つまり外部的振るるテストケースが存在しない場合，外部的振る舞いが保たれて舞いの検証に必要なテストケースを，編集内容を基に推測するいるか確認できないため，リファクタリングを始める前に信頼ことができるため，リファクタリング支援になると言われていできるテストケースを用意する必要がある．

る [5]．しかし，リファクタリング支援に変更波及解析を利用しリファクタリングは次に示す手順で行う．

たツールや研究は，まだ確認されていない．
本研究では，変更波及解析を用いて，リファクタリングの（ 1 ） 開発者がソースコード中からリファクタリングを行った方がよい部分を特定する一環として行うテスト作業を支援するツールを提案する（図（ 2 ） リファクタリングを行う対象部分の設計を開発者が理1(b)）．具体的には，JDT のリファクタリング支援機能を拡張解する

し，外部的振る舞いの検証に必要なテストケースを推測した上（ 3 ） リファクタリングを行った後の設計を開発者が考えるでリファクタリングを行うことができるようにする．

（ 4 ） 開発者が考えた設計になるように，ソースコードを編提案するツールを使用してケーススタディを行い，その結果集するについて議論することで，リファクタリング支援に変更波及解（ 5 ） 開発者がソフトウェアの外部的振る舞いが保たれてい析を利用したツールの有効性を検証する．今回は，リファクタることを確認する

リングパターンの 1 つである Pull Up Method リファクタリン

（ 6 ） ( 4 )，( 5 ) の手順を繰り返し，最終的に開発者が考えグ [2] を行い，提案するツールを使用しない場合と使用した場た設計にする合とでどのような違いがあるかを検証する．

Fowler はリファクタリングを行うべきソースコードの状態に応じて，さまざまなリファクタリングパターンを提案している [2]．そして，いくつかのリファクタリングパターンは，ソースコードを編集する作業については統合開発環境 Eclipse のプ
ラグイン JDT [4] で支援されている（図 2）．JDT とは Java 言—2—

語でソフトウェアを開発する際に利用できる Eclipse のプラグイ

Price・・・
Price price= new RegularPrice();・・・
price.getCharge()・・・ンである．JDT を使用する開発者が，リファクタリングを行う対象や行うリファクタリングの内容を設定すれば，そのリファ呼出クタリングを行うことを目的としてコード変換を適用したソースコードのプレビューが Eclipse 上に提示される．プレビューが提示された時点ではソースコードは変換されていないので，getCharge

RegularPrice

そのコード変換を実際に行うか選択することができる．
(a) ソースコード編集前

ただし，ソフトウェアの外部的振る舞いが保たれていること

Priceを確認する作業は開発者が行わなければならない．リファクタ
・・・
Price price= new RegularPrice();・・・
price.getCharge()
・・・

リングを行う開発者は，ソフトウェアの外部的振る舞いが保たれていることを確認するために，テストケースを使用してテス呼出トを行い，ソースコードを編集する前と編集した後とでテストの実行結果が同じであることを確認する．このテスト作業は，ソースコードを編集してコンパイルをする度に行うことがリ

getCharge

RegularPrice
getCharge

ファクタリングの手順に定められている．そのため，リファク(b) ソースコード編集後タリングには自動的に実行できるテストケースが必要である

図 3 編集が波及する例と言われている [2]．文献 [2] では，自動的に実行できるテストケースを用意するために，JUnit テストフレームワーク [6] を使用している．Eclipse 上で JUnit テストフレームワークを使に加えて，ダイナミックディスパッチを利用して RegularPrice

用すれば，パッケージ，クラス，メソッドのいずれかの単位でクラスのオブジェクトに対して getCharge() メソッドを呼び出テストケースを指定し，実行結果を参照することができる．

すソースコードをテストするテストケースも使用して，外部的また，テストを頻繁に行うため，外部的振る舞いの検証に必要なテストケースのみを使用することが推奨されている [2]．外振る舞いが保たれていることを確認する必要があると考えられる．

部的振る舞いの検証に必要なテストケースを絞り込む作業は，Ryder らが提案する変更波及解析には，編集前のソースコーJDT でも支援されていないため，開発者がソースコードとテスドと編集後のソースコード，それらのソースコードをテストすトケースを理解して必要なテストケースを選択する必要がある．

るテストケースを入力する．編集前後のソースコードを比較し2. 2 変更波及解析て編集部分を算出するだけでなく，その編集部分が原因でダイ変更波及解析とは，ソースコードを編集した影響を特定する

ナミックディスパッチが変化する部分を推測し，ソースコード技術である [5]．この技術が研究される背景には，オブジェクトを編集した後に実行結果が変化する可能性があるテストケー

指向言語では継承やダイナミックディスパッチを使用しているスを推測することができる．また，実行結果が変化する可能性ために，ソースコードを編集した部分が原因で，編集していながある各テストケースについて，実行結果が変化する可能性をいソースコードの実行結果が変化することがあり，ソフトウェ引き起こした編集部分を推測することもできる．この変更波及アを保守することが困難になっているという問題がある [5]．

解析を利用することで，回帰テストを行うために必要なテスト

例えば，Java 言語で記述されたソースコード中にクラス Priceケースを選択する手間が省け，また，回帰テストの実行結果がを継承したクラス RegularPrice があるとする（図 3）．オブジェ

失敗であった場合に失敗の原因を特定することが容易になる．

クト指向言語では，継承元のクラス (親クラス) の型である変数

Ryder らが提案する変更波及解析では，メソッドの呼び出しに継承先のクラス（子クラス）のオブジェクトを代入すること関係を表現するコールグラフを使用している [5] [7]．コールグができるため，Price 型の変数に RegularPrice クラスのオブジェ

ラフを使用すると，あるメソッドがどのメソッドを呼び出してクトを代入して実行することができる．図 3(a) のように，親クいるか知ることができる．この変更波及解析で使用するコールラス Price でのみ getCharge() メソッドを定義している場合，子グラフは，入力として与えたテストケース（この場合，テストクラス RegularPrice に getCharge() メソッドが継承されるので，ケースとはテストメソッドに相当する）を始点とするグラフに

Price クラスに定義されている getCharge() メソッドが実行されなる．各ノードがメソッド定義に対応し，各エッジがメソッドる．ここで子クラス RegularPrice に，親クラス Price に定義さ呼び出しに対応していて，さらにエッジにはメソッドを呼び出れている getCharge() メソッドと同じシグネチャのメソッドをす際の形式についての情報が付加されている．例えば，図 3 で定義して，オーバーライドをするようにソースコードを編集しは，RegularPrice 型のオブジェクトが Price 型の変数に代入さたとする（図 3(b)）．この場合，getCharge() メソッドを呼び出れている状態で getCharge() メソッドを呼び出す，という情報

すソースコードは編集していないが，ダイナミックディスパッがコールグラフのエッジに付加される．コールグラフは，テスチが原因で，実行される getCharge() メソッドは，RegularPrice

トケースと編集前のソースコードを解析したコールグラフと，クラスに定義されている getCharge() メソッドになる．このよ

テストケースと編集後のソースコードを解析したコールグラフ

うな状況では，RegularPrice クラスをテストするテストケースとの 2 種類が生成される．

—3—

編集前のソースコードを使用したコールグラフとソースコードの編集部分の情報との対応をとると，編集されたメソッドにピーしたプロジェクトを削除しなければならない•

手順 (5) において，プロジェクト 2 つのうち一方を削除対応するノードがコールグラフ上にある場合，そのコールグラしなければならない．コピーをした際に名前を変更したプロ

フの始点であるテストケースはそのメソッドを呼び出している

ジェクトを残す場合は，プロジェクトの名前を元の名前に変更ので，ソースコードを編集する前と同じ実行結果を出力しないしなければならない可能性がある．また，ダイナミックディスパッチの変化に対応

この問題点となる作業は，機械的に実行することができるた

するエッジがコールグラフ上にある場合も同様である．そのよめ，ツールとして実装すれば解決できると考えられる．しかし

うなテストケースが，ソースコードを編集した後に実行結果が今のところ，リファクタリング支援に変更波及解析を利用した変化する可能性があるテストケースと判定される．

ツールは確認されていない．

また，編集後のソースコードを使用したコールグラフとソースコードの編集部分の情報との対応をとると，テストケースの3. 提案するツール

実行結果はそのテストケースを始点とするコールグラフ上の

この節では，2. 3 節で述べた問題点を解決するために本研究ノードに対応するメソッドの実行結果であるから，コールグラで提案するツールについて説明する．なお本研究では，リファフ上のノードに対応するメソッドに対する編集が，テストケークタリングパターンの 1 種である Pull Up Method リファクタ

スの実行結果に波及していることが分かる．コールグラフ上のリング [2] を支援する．

エッジに対応するダイナミックディスパッチの変化についても同様である．

提案するツールを使用した際の手順を次に示す（図 4）．
手順 A（対象のメソッドと引き上げ先のクラスを指定）

Ryder らが提案する変更波及解析は Chianti [7] という Eclipse

Pull Up Method リファクタリングにおいて引き上げる対象ののプラグインとして実装されている．Chianti は Java 言語を対メソッドと，そのメソッドを引き上げる先のクラスを指定する．

象とし，Eclipse でソフトウェア開発を行う際の単位であるプロ

手順 B（コード変換後のソースコードを確認）

ジェクト 2 つを入力とする．この 2 つのプロジェクトをそれぞ

JDT が提示したコード変換後のソースコードを参照して，問題れ，編集前のソースコード，編集後のソースコードを含むプロがないことを確認する．

ジェクトとして扱う．さらにユーザが編集前のソースコードを手順 C（Chianti を実行）含むプロジェクトから変更波及解析に使用するテストケースをChianti に入力するテストケースを指定し，Chianti を実行する．

選択することで，実行結果が変化する可能性があるテストケー

手順 D（Chianti が提示したテストケースを用いてテストを実行）

スと，実行結果が変化する可能性を引き起こした編集部分につChianti が実行結果として提示したテストケースを使用してテいての情報を出力する．

ストを行い，外部的振る舞いを検証する．

2. 3 リファクタリングを行う際に Chianti を使用した場合の問題点

Ryder らは，変更波及解析がリファクタリング支援にも利用

手順 E（対象ソースコードにコード変換を適用）
リファクタリング対象であるソースコードに手順 B で参照した内容のコード変換を適用する．

できることを述べている [5]．JDT のリファクタリング支援機

以降，手順 A，B，C，D，E についてそれぞれ詳述する．

能と Chianti を単純に併用した場合，次のような手順で開発者

3. 1 手順 A（対象のメソッドと引き上げ先のクラスを指定）はリファクタリングを行うと考えられる．

Pull Up Method リファクタリングにおいて引き上げる対象（ 1 ） Chianti は編集前後のソースコードを入力とするため，とするメソッドとそのメソッドを引き上げる先のクラスを開発

プロジェクトをコピーし，2 つ用意する者が指定する．JDT のリファクタリング支援機能は，開発者が（ 2 ） プロジェクト 2 つのうち一方に含まれるソースコー指定した情報を元にリファクタリングを目的としたコード変換

ドを，JDT のリファクタリング支援機能を利用して変換するを行った後のソースコードを算出する．

（JDT のリファクタリング支援機能で問題が見つかった場合は，3. 2 手順 B（コード変換後のソースコードを確認）リファクタリングを中止する）

JDT が提示したコード変換後のソースコードを参照し，開（ 3 ） 編集前後のソースコードを用意できたので，Chianti を発者は自分が意図した通りのコード変換が行われるか確認す実行する

る．また，このときエラーや警告が表示される場合があるので，（ 4 ） Chianti で出力されたテストケースを使用して，外部コード変換に問題がないかどうかも確認する．

的振る舞いを確認する

3. 3 手順 C（Chianti を実行）

（ 5 ） テストの実行結果を確認し，リファクタリング成功だ

Chianti を実行するために必要なテストケースを開発者が指と判断したならば，編集前のソースコードを含むプロジェクト定する．提案するツールは，リファクタリング対象であるソーを削除する．リファクタリング中止と判断したならば，編集後スコードをコピーし，手順 A で算出したコード変換をそのコのソースコードを含むプロジェクトを削除する

ピーしたソースコードに適用する．コピー元のソースコードとこの手順において，次のような問題点が考えられる．

コピーしてコード変換を適用したソースコード，開発者が指定•

プロジェクトを手動でコピーしなければならない

したテストケースを入力として，Chianti を実行し，外部的振•手順 (2) においてリファクタリングを中止した場合，コる舞いの検証に必要なテストケースを提示する．

—4—

対象のメソッドと引き上げ先のクラスを指定(A-1)

コード変換後のソースコードを確認(C-1)Chiantiに入力するテストケースを指定(D-1) Chiantiが提示したテストケースを指定(B-1)

対象ソースコードにコード変換を適用

(E-1)

提案ツール

Eclipse

コード変換後のソースコードを算出(B-2)コード変換後のソースコードを提示(A-2)

ソースコードをコピー(C-3)コピーしたソースコードにコード変換を適用(C-4)Chiantiを実行して実行すべきテストケースを提示(C-2)

テストを実行(E-2)対象ソースコードにコード変換を適用(D-2)

コピーしたソースコードを削除(E-3)

図 4 提案するツールを使用したリファクタリング

3. 4 手順 D（Chianti が提示したテストケースを用いてテ

this.base = base;this.height = height;

ストを実行）

Chianti が提示したテストケースを使用して，コピーしてコー}}ド変換を適用したソースコードに対するテストを行う．開発者
はテストの実行結果を参照し，外部的振る舞いが保たれていることを確認する．

3. 5 手順 E（対象ソースコードにコード変換を適用）

package drawtool.figure;public class DiamondShape extends Parallelogram {public DiamondShape(int base, int height) {リファクタリングを行う対象であるソースコードに対して，

super(base, height);}

コード変換を適用する．Chianti を実行するためにコピーしてpublic int calculateArea() {コード変換を適用したソースコードは削除する．

return this.base * this.height;

この提案するツールを使用して Pull Up Method リファクタ
リングを行うと，外部的振る舞いを検証するために必要なテス}}

トケースを選択する手間が省け，外部的振る舞いが検証できないコード変換を知ることができる．よって，より安全に Pull

package drawtool.figure;Up Method リファクタリングを行うことができるようになる

public class Rectangle extends Parallelogram {public Rectangle(int base, int height) {と考えられる．

super(base, height);

4. ケーススタディ}
public int calculateArea() {4. 1 適 用 例

return this.base * this.height;}

提案するツールを使用して，次のソースコードに対して Pull

Up Method リファクタリングを行った場合について説明する．
DiamondShape クラスと Rectangle クラスに定義されている
calculateArea() メソッドを親クラス Parallelogram クラスに引き上げる．

}

このソースコードに対して，次のテストケースを用意する．
package drawtool.figure;import junit.framework.TestCase;public class DiamondShapeTest extends TestCase {package drawtool.figure;public void testCalculateArea() {public interface Figure {Figure figure = new DiamondShape(3, 4);

abstract public int calculateArea();assertEquals(12, figure.calculateArea());}}}

package drawtool.figure;4. 2 適 用 結 果

public abstract class Parallelogram implements Figure {このリファクタリングを提案するツールを使用して行うと，protected int base;protected int height;
public Parallelogram(int base, int height) {Chianti で推測した結果が図 5 のように表示される．図 5 から読み取ることができる情報は，次の通りである．

—5—

度防ぐことができると考えられる．しかし，ソフトウェアが大規模になるほど大量のテストケースが定義されているため，テストを実行するために時間がかかる．提案するツールを使用すれば，必要最小限のテストケースを使用してテストを行うことができるため，有効だと考えられる．
図 5 提案するツールの出力

なお，現状のツールでは，実行結果が変化する可能性があるテストケースをツールで提示しているが，テストを行う際には•DiamondShapeTest クラスの testCalculateArea() メソッ

開発者がツールで提示されたテストケースを選択して Eclipse

ドが，ソースコード編集後に実行結果が変化する可能性がある上で行うようになっている．テストケースを選択する作業もテストケースであるツールで支援することが可能だと考えられる．

•Figure 型の変数に DiamondShape クラスのオブジェクトを代入して calculateArea() メソッドを呼び出した場合の外部的振る舞いがテストされている•

抽 象 ク ラ ス Parallelogram に 引 き 上 げ ら れ た calcu-lateArea() メソッドがテストされている

5. ま と め本研究では，リファクタリング作業の一環であるテスト作業を，Ryder らが提案する変更波及解析という技術を利用して支援するツールを提案した．提案するツールは，JDT のリファク逆に，Figure 型の変数に Rectangle クラスのオブジェクトをタリング支援機能を拡張し，Pull Up Method リファクタリン

代入して calculateArea() メソッドを呼び出した場合の外部的振グを目的としてコード変換を行う前に，コード変換の内容を基る舞いはテストされていないことが分かる．リファクタリングに実行結果が変化する可能性があるテストケースを変更波及解を行うには信頼できるテストケースが必須であるため，この場析で推測して，ソフトウェアの外部的振る舞いが保たれている

合は Figure 型の変数に Rectangle クラスのオブジェクトを代入ことを確認するためのテスト作業で使用するテストケースを提して calculateArea() メソッドを呼び出した場合の外部的振る舞示するツールである．この提案するツールを使用することで，いをテストするテストケースを追加する必要がある．よって，より安全に Pull Up Method リファクタリングを行うことがでこのリファクタリングは中止と判断できる．

きると考えられる．

4. 3 議論

今後の課題は，他のリファクタリングパターンもツールで支

4. 1 節の例は，信頼できるテストケースが十分に用意されて援することが挙げられる．また，開発者に提示する情報をリいないために，リファクタリングを中止する例であった．この例

ファクタリングにより適した形式で提示することも挙げられ

では，3 つの点で提案するツールが有効であったと考えられる．

る．提案するツールの実行時間については，規模が大きいソフ

1 つめは，開発者の労力である．提案するツールを使わなかっトウェアを対象として実験を行うことで実用的な時間で収まる

た場合，外部的振る舞いの検証に必要なテストケースを開発者か検証する必要がある．

が事前に把握した上でリファクタリングを行わなければならな

謝辞 変更波及解析ツール Chianti を提供していただいた

い．4. 1 節の例は小規模のソースコードとテストケースである

バージニア工科大学 Barbara G. Ryder 教授に深く感謝する．

ため，開発者が理解をするために時間はほとんどかからないが，本研究は一部，日本学術振興会科学研究費補助金基盤研究（A）

ソフトウェアが大規模になるほど理解に時間がかかると考えら（課題番号:21240002），文部科学省科学研究費補助金若手研究れる．提案するツールを使用することで，必要なテストケース（B）（課題番号:20700024），日本学術振興会特別研究員奨励費を短時間で推測することができ，また，テストケースでテスト（課題番号:20・1964）の助成を得た．

されていないコード変換を推測することもできる．

2 つめは，開発者が必要なテストケースを推測する際には誤りが入り込む点である．継承やダイナミックディスパッチが原因でオブジェクト指向言語で記述されたソースコードは理解が難しいため，開発者が外部的振る舞いの検証に必要なテストケースの推測を誤ることがあると考えられる．結果として，外部的振る舞いを変化させてしまったのに，外部的振る舞いを検証するためのテストに使用するテストケースの選択を誤って，外部的振る舞いの変化に気が付かない可能性がある．提案するツールを使用することで，外部的振る舞いの検証に必要なテストケースを確実に推測できると考えられる．

3 つめは，テストの実行時間である．外部的振る舞いの検証に必要なテストケースを使用しなかったために，外部的振る舞いの変化を見落とすという事態は，コード変換を適用する度にすべてのテストケースを使用してテストを行うことで，ある程文

献[1] W. F. Opdyke: “Refactoring object-oriented frameworks”,
PhD thesis, University of Illinois at Urbana-Champaign(1992).
[2] M. Fowler: “Refactoring: improving the design of existingcode”, Addison Wesley (1999).
[3] Eclipse: “http://www.eclipse.org”.
[4] Eclipse JDT: “http://www.eclipse.org/jdt/”.
[5] B. G. Ryder and F. Tip: “Change impact analysis
for object-oriented programs”, the 3rd ACM SIGPLANSIGSOFT Workshop on Program Analysis For SoftwareTools and Engineering (PASTE 2001), Snowbird, UT, USA,
pp. 46–53 (2001).
[6] JUnit: “http://www.junit.org”.
[7] X. Ren, F. Shah, F. Tip, B. G. Ryder and O. Chesley: “Chianti: A tool for change impact analysis of Java programs”,
the 19th Annual ACM SIGPLAN Conference on ObjectOriented Programming, Systems, Languages, and Applications (OOPSLA 2004), Vancouver, BC, Canada, pp. 432–448 (2004).

—6—