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

信学技報
TECHNICAL REPORT OF IEICE.

更新履歴情報と静的情報を用いて同一機能を実装しているクラス群を抽出する手法の提案
檜皮 祐希†

誠†

松下井上 克郎†† 大阪大学 大学院情報科学研究科 〒 560-8531 大阪府豊中市待兼山町 1-3
E-mail: †{y-hikawa,matusita,inoue}@ist.osaka-u.ac.jp
あらましソフトウェアの保守において，ソフトウェア理解や再利用のために特定の機能が実装されている箇所を特定することが必要になることがある．その際に用いられる手法として Feature Location という研究がある．FeatureLocation の既存手法は，静的手法，動的手法，更新履歴情報を用いた手法の 3 つに分けることができるが，各々の手法にはそれぞれ異なる問題点があり，ソフトウェアの機能によっては適切に抽出できない場合がある．本研究では，既存手法で用いられている情報のうち，更新履歴情報と静的情報を組み合わせることによりあるクラスと同一の機能を実装しているクラス群を抽出する手法を提案する．具体的には，まず，更新履歴情報を用いて同一機能を実装しているクラス群の抽出を行い，その抽出結果に対して，静的情報を用いて更新履歴情報から誤って抽出したクラス群の除去，及び，更新履歴情報で抽出できなかったクラス群の補完を行う．また，オープンソースソフトウェアに対して手法の適用実験と評価を行い，手法の有用性を示した．
キーワード

ソフトウェア理解，ソフトウェア再利用，同一機能実装クラス群の抽出，更新履歴情報，静的情報

Feature location using static infomation and revision history
Yuki HIKAWA† , Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
1-3. Machikaneyama-cho, Toyonaka, Osaka, 560-8531, Japan
E-mail: †{y-hikawa,matusita,inoue}@ist.osaka-u.ac.jp
Abstract In the software maintenance or development, we have to ﬁnd the part which is implemented one feature
to the software comprehension or the software reuse, and Feature Location is the technique which ﬁnd the part ofthe source code which is implemented one feature. In this paper, we propose the feature location approach using
static infomation and revision history. We perform an experimental study for the open source software to evaluate
our approach. The result shows that our approach is useful.
Key words software comprehension, software reuse, feature location, revision history, static infomation

1. は じ め に
ソフトウェア保守プロセスは，ソフトウェア理解と実際の修連する部分を特定する必要がある．しかし，機能に関連する部分の特定にはソフトウェア全体の構成を知る必要があり，大規模かつ複雑なソフトウェアで行うのは困難である [8]．

正作業に分けることができる．修正作業には，発見されたバグ

一方，ソフトウェア開発においては，大規模かつ高品質なソの修正や要求の機能拡張が含まれるが，実際に修正を行う際にフトウェア製品を短期間で開発することが求められている．そは，ソフトウェアについて理解しておく必要がある．しかし，うした要求を実現する方法の 1 つとして，再利用がある [6]．再ソフトウェアの大規模化や複雑化により，ソフトウェア全体を利用は，過去に作られたソフトウェア部品を利用して開発を進理解するのには多大な時間やコストがかかるため困難な作業とめる方法で，再利用を行うことにより，高品質なソフトウェアなる．そこで，ソフトウェア全体を理解するのではなく，これを短期間で効率良く開発することができる．しかし，実際にあから修正する機能に関連する部分のみを理解することができれる機能を実装する際に過去に作った他のソフトウェアの一部をば，ソフトウェア理解にかかるコストを大きく削減することが再利用する際，再利用に必要なその機能を実装している部分をできる [4]．そこで，理解するべき修正に必要な特定の機能に関特定する必要があるが，ソフトウェア理解と同様に困難な作業

—1—

である．
このように，機能が実装されている部分を特定することが必

ウェアを何度も実行する必要があるため，大規模なソフトウェ
アに適用する場合，非常に時間がかかる．

要になるが，困難な作業である．そこで，ある機能が実装され更新履歴情報を用いた手法では，版管理システム等での開発ている部分を効率的に特定する手法として，Feature Location

履歴情報を用いて，同時更新の傾向を解析することにより特定と呼ばれる手法が研究されている [1]〜[3], [7], [9]．の機能を実装している箇所を抽出する [7]．しかし，更新履歴情

Feature Location の手法としてさまざまな手法が提案されて報を用いた手法は，開発履歴情報を蓄えてある必要があり，版おり，それらの手法は静的手法，動的手法，更新履歴情報を用管理システム等を使って開発履歴を管理していないソフトウェいた手法の 3 つにわけられるが，それぞれの手法ごとに異なるアには適用することができなく，管理のされ方によっても精度問題点が存在し，抽出する機能によって適切に抽出できない場が大きく変わってしまう．また，開発履歴のみを解析し，ソー合がある．

スコードには全く依存しないため，たまたま他の機能と同時にそこで本研究では，あるクラスと同一の機能が実装されている部分を特定する手法として，既存手法のうち，更新履歴情報を用いた手法に，静的手法を組み合わせて用いる手法を提案する．具体的には，まず，更新履歴情報を用いてあるクラスと同更新されたが，実際には機能とは関係のないモジュールが多く抽出されてしまう可能性がある．

3. 提 案 手 法

一の機能が実装されているクラス群を抽出する．そして，静的

本節では，更新履歴情報と静的情報を用いてある特定のクラ情報を用いて更新履歴情報から誤って抽出したクラス群の除去，スと同一の機能を実装しているクラス群を抽出する手法につい及び，更新履歴情報からは抽出できなかったクラス群の補完をて述べる．以下では，同一機能を抽出する際に最初に用いるあ行う．この手法により，それぞれの問題点を補い，機能抽出のる特定のクラスを開始クラスと呼ぶ．

精度を上げることを目指す．

更新履歴情報としてクラス間で同時に更新される割合を表し

以降，2. 節では Feature Location の関連研究を紹介する．3.

た更新傾向グラフを用いる．ソフトウェア開発において同じ機

節では提案手法について説明する．4. 節では 3. 節で説明した提能を実装しているクラスは同時に更新されることが多いと考え案手法に対して行った適用実験について述べ，5. 節で実験結果られるため，同時更新の傾向を解析することにより同一機能をの考察を述べる．最後に，6. 節でまとめと今後の課題を述べる．

実装しているクラスを特定できる．また，静的情報としてクラ2. 関 連 研 究ス間の呼び出し関係を表したコールグラフを用いる．呼び出し関係という直接的な関係を解析することにより同一機能を実装

効率的にソフトウェアの持つ特定の機能がソースコード中でしているクラスを特定できる．本手法では，まず，更新傾向グ

どの箇所に実装されているかを特定する手法として，Feature

ラフで開始クラスと同時更新傾向が強いクラス群を抽出し，そLocation についての研究がある [1]〜[3], [7], [9]．Feature Lo-の抽出結果に，コールグラフ上で特定の呼び出し関係のあるクcation を用いることで，保守作業や開発作業において，特定ラス群を抽出し補完することにより開始クラスと同一の機能をの機能を実装している箇所を特定するコストを削減する事がで実装しているクラス群を抽出する．

きる．
既存の Feature Location の手法は大きく静的手法，動的手法，更新履歴情報を用いた手法の 3 つに分けることができる．
静的手法では，対象とするソフトウェアのソースコードを静本手法は，以下の 4 つの手順から構成されている．
（ 1 ） 開始クラスの決定（ 2 ） 更新傾向グラフ，コールグラフの作成（ 3 ） 更新傾向グラフからの抽出的に解析し，モジュールのコールグラフを作成し，そのグラ（ 4 ） 抽出結果とコールグラフの比較

フを解析することで特定の機能を実装している箇所を抽出す

以下，これら 4 つについて詳しく説明する．

る [1], [9]．しかし，静的手法はいずれもソースコードの解析結

3. 1 開始クラスの決定

果を元にして特定の機能を実装している箇所を見つけ出すため，抽出したい機能のクラス群の中の 1 つのクラスを開始クラ実行経路が動的に決定されるオブジェクト指向プログラムにそスとして決定する．開始クラスの決定は，機能から連想されるのまま適用する事はできない．動的束縛は，オブジェクトが起キーワードを用いた検索などによって行う．

動するメソッドを変数の型ではなく実行時の実体をもとに決定

3. 2 更新傾向グラフ，コールグラフの作成するため，実際に呼び出されるメソッドがソースコードを解析

更新履歴情報として用いる更新傾向グラフと静的情報としてしただけではわからないためである．
動的手法では，あらかじめテストケースを用意しておき，そ用いるコールグラフを作成する．

3. 2. 1 更新傾向グラフの作成のテストケースを入力として実行したときの呼び出されたモ

更新傾向グラフとは，クラス間で同時に更新される傾向を表

ジュールの履歴を解析することで特定の機能を実装している箇現するグラフである．ここでは，同じコミット作業により更新所を抽出する [2], [3]．しかし，動的手法は最初にテストケースされたとき，同時に更新されたと考える．グラフの頂点はクラを作る必要があり，また，テストケースの品質に抽出の精度がスを表現する．頂点間の辺は有向辺であり，辺の始点が頂点 c1 ，左右されてしまうため，慎重にテストケースを作成する必要が終点が頂点 c2 であるとき，同時に更新される傾向を表現するあり，テストケース作成のコストが膨大になる．また，ソフトメトリクスである conf idencec1 ,c2 という値を持っている．

—2—

表 1 conﬁdence 値の例

ABCD

A 1.00.75 0.50.25

B 1.01.0

C 0.50.25 1.00.33 0

D 0.33 01.0dceblf0.75

k1.0ga0.75

AB

1.00.33

Cstart0.25
0.50.5C

0.250.75

C10.33

1.0hjiC2D

図 2 更新傾向グラフからの抽出例
図1

更新傾向グラフの例

conﬁdence メトリクス [10] は，ある 2 つのクラス c1 ，c2 について，c1 が更新されたとき，c2 がどの程度の割合で更新されるか，ということを表現する．conﬁdence メトリクスを以下の式で定義する．ソフトウェア中の全クラス集合を C とし，任意のクラス c1 , c2 ∈ C について，c1 と c2 が同時に更新された回数
conf idencec1 ,c2 =c1 が更新された回数には同時に関係するクラスについて作業するため，同時に更新されたクラスは同一機能を実装していることが多いと考える．
そこで，同一機能を実装しているクラス群として，開始クラスと同時更新されることが多いクラス群，すなわち，conﬁdenceの値が大きいものを抽出する．
抽出方法は，あらかじめ閾値 Eth を決め，以下のような手順(1)

更新傾向グラフの作成では，まず，版管理システムのリポジトリに蓄積されている更新者，更新日時，更新時のコメントの情報を用いて同時に更新されたクラスを求める．そして，求めた同時更新情報を用いて，クラス間の conﬁdence 値を求め，グラフとして表現する．
更新傾向グラフの作成の具体例を挙げる．クラス A，B，C，D が次のような順に更新されたとする．
（ 1 ） A，B，C を同時に更新する（ 2 ） A，B を同時に更新する（ 3 ） C，D を同時に更新する（ 4 ） A，B を同時に更新する（ 5 ） A，C，D を同時に更新する（ 6 ） C，D を同時に更新する
このとき，各クラス間の conﬁdence の値は表 1 のようになる．
表 1 の各セルは conf idence行, 列 を表している．そして，図 1でこれを更新傾向グラフとして表現した．

3. 2. 2 コールグラフの作成
コールグラフとは，クラス間の呼び出し関係を表現したグラフである．グラフの頂点はクラスを表現する．頂点間の辺は有向辺であり，辺の始点が頂点 c1 ，終点が頂点 c2 であるとき，クラス c1 内のメソッド，あるいは変数はクラス c2 内のメソッド，変数を呼び出している．
ソースコードを静的に解析し，クラス間の呼び出し関係を抽出し，グラフとして表現する．

3. 3 更新傾向グラフからの抽出
3. 2. 1 節で作成した更新傾向グラフからクラス群の抽出を行う．

で行う．開始クラスを cstart とする．
（ 1 ） ∀ci ∀cj conf idenceci ,cj < Eth となる有向辺を削除する（ 2 ） cstart から到達可能な頂点集合 C1 を求める．
（ 3 ） cstart ，C1 の各頂点のいづれかに到達可能なクラス群

C2 を求める．
（ 4 ） cstart ，C1，C2 の和集合を抽出クラス群とする．
閾値については，対象とするソフトウェアによって更新のされ方等が異なり閾値自体も異なってくるため，抽出を行う利用者によって抽出された数を見たり，抽出結果をコールグラフと比べることにより判断する．
更新傾向グラフからの抽出の具体例を図 2 を用いて示す．図2 は更新傾向グラフから閾値以下の有向辺を削除したグラフである．開始クラス a から到達可能な頂点は e, f, g でこの 3 つがC1 となる．次に，a, e, f, g のいづれかの頂点に到達可能な頂点は d, h, i, j でこの 4 つが C2 である．したがって，このグラフから抽出されるクラス群は {a, d, e, f, g, h, i, j} となる．

3. 4 抽出結果とコールグラフの比較
3. 2. 2 で作成したコールグラフを用いて 3. 3 節で更新傾向グ
ラフから抽出したクラスについて誤って抽出したクラスの除去，及び，抽出できなかったクラスの補完を行う．

3. 4. 1 誤って抽出したクラスの除去
ここでは，3. 3 節の更新傾向グラフからの抽出では抽出されたが，コールグラフ上では同一機能を実装していないとみなせるクラス群を除去する．除去にはコールグラフ上の開始クラスからの抽出クラス距離を用いて行う．クラス c1 と c2 間の抽出
クラス距離 dc1 ,c2 はコールグラフを無向辺と考えたときの c1と c2 のパスの間に抽出されていないクラスがいくつあるかの最小値を表すものと定義する．例えば，図 3 の d と f の抽出
クラス距離 dd,f は頂点 d と f の間に抽出されていないクラス

開発や保守の段階において，1 つの機能を実装，修正する際—3—aabdbcebfcije(A)gbhdcadecka

Start Classl(B)extracted Class

Extracted Class
図3

図 4 抽出できなかったクラスの補完例

誤って抽出したクラスの除去例

b が存在するので，dd,f = 1 となる．d と e の抽出クラス距離
dd,e は頂点 d と e の間は d → h → e というパスを通ればすべてのクラスが抽出されているので，dd,e = 0 となる．
この抽出クラス距離を用い，開始クラス cstart と c ∈ E （E(C)

これらの手順で最終的に抽出された結果を同一機能を実装しているクラス群とする．

4. 適 用 実 験は抽出クラス集合）について dcstart ,c >= 2 となる c を除去する．

本手法の妥当性を検討するために，Java を対象に本手法を

図 3 の例では，開始クラスは d，抽出クラス群 {e, f, h, j} で実装したツールを作成し，そのツールを用いてオープンソーあるので，開始クラス d と抽出クラス群の各クラスとの抽出ク

スソフトウェアの XBrowser [11] を対象に適用実験を行った．

ラス距離を求めると，dd,e = 0，dd,f = 1，dd,h = 0，dd,j = 2XBrowser は，Java によって記述されたウェブブラウザであり，となる．したがって，抽出クラス距離が 2 となった j を除去

規模は，クラス数 171 クラス，行数 28881 行，総更新回数 165

する．

回，総リビジョン数 1388 個である．

3. 4. 2 抽出できなかったクラスの補完
ここでは，3. 3 節の更新傾向グラフからの抽出で抽出されなかったクラス群をコールグラフを用いて補う．

実験では，XBrowser に実装されている機能のうちブックマーク機能とヒストリ機能の抽出を行った．ブックマーク機能は，何度も訪れる Web サイトの URL を記録しておく機能で，ユーまず，次の条件のいずれかを満たすクラスを抽出する．

ザが指定したページをブックマークとして保存することができ，•ユーザはブックマークとして保存したページをブックマークリ呼び出しているクラスのうち 3 つ以上のクラスが抽出されているクラス•呼ばれているクラスのうち 3 つ以上のクラスが抽出されているクラス•

呼び出しているクラスのいずれかが抽出されており，かつ，呼ばれているクラスのいずれかが抽出されているクラス

ストから選択することで，そのページに簡単にアクセスできるという機能である．ヒストリ機能は，ユーザが過去に閲覧したページの履歴を保持しておき，過去に開いたことのあるページへ戻ったり，その後，戻る前のページに戻ることを可能にする機能である．

図 4(A) のクラス a のように呼び出しているクラスのうち 3それぞれの機能に対して，静的情報，更新履歴情報単独でのつ以上が抽出されているクラスは，その機能を統括しているよ

抽出と提案手法を比較するために次の 3 種類の抽出を行った．

うなクラスと考えられる．図 4(B) のクラス a のように呼ばれているクラスのうち 3 つ以上が抽出されているクラスは，その機能に必要なライブラリ的な機能を実装していると考えられる．

•

更新履歴情報のみを用いて，グラフ作成後，3. 3 節の更新傾向グラフからの抽出のみを行った．

•

静的情報のみを用いて，グラフ作成後，3. 4 節のコール

図 4(C) のクラス a のように呼び出しているクラスのいずれかグラフからの抽出のみを行った．ただし，提案手法では抽出クが抽出されており，かつ，呼ばれているクラスのいずれかが抽ラスが 1 つのとき静的情報からの補完を行っても，ほとんど抽出されているクラスは，実際にその機能の一部を実装している出できないため，抽出できなかったクラスの補完で，「呼び出しと考えられる．これらの更新傾向グラフからは抽出できなかっているクラスのうち 3 つ以上のクラスが抽出されているクラ

たが，実際にはその機能の一部を実装していると考えられる 3ス」を「呼び出しているクラス」，「呼ばれているクラスのうち種類のクラス群を抽出クラス群に加える．

3 つ以上のクラスが抽出されているクラス」を「呼ばれている最後に，さらに呼び出してるクラスと呼ばれているクラスのクラス」と変更し，抽出した上で，「呼び出しているクラスのいすべてが抽出されてるクラスは，その機能に何らかの関係があずれかが抽出されており，かつ，呼ばれているクラスのいずれると考えられるので抽出する．

かが抽出されているクラス」を抽出するという手順に変更した．

—4—

表2

ブックマーク機能の抽出結果
正解クラス 抽出クラス 該当クラス

適合率 再現率

更新履歴情報のみを用いての抽出34

10101.000.29

静的情報のみを用いての抽出3432160.500.47

提案手法3429250.860.74

10101.00——

更新傾向グラフから抽出
誤って抽出したクラスの除去

000.00——

抽出できなかったクラスの補完

19150.79——

表 3 ヒストリ機能の抽出結果
正解クラス 抽出クラス 該当クラス•

適合率 再現率

更新履歴情報のみを用いての抽出301560.400.20

静的情報のみを用いての抽出30

31130.420.43

提案手法

30

27

140.520.47

更新傾向グラフから抽出

1560.40——

誤って抽出したクラスの除去

200.00——

抽出できなかったクラスの補完

1480.57——

次に各機能についての考察を述べる．

提案手法の手順をすべて行った．

今回の実験では，開始クラスをブックマーク機能は，“Book-5. 1 ブックマーク機能

mark” と い う キ ー ワ ー ド に 一 致 し た xbrowser.bookmark.

更新履歴情報のみで抽出した場合は，適合率は 1.0 となり完

BookmarkFinder クラス，ヒストリ機能は，“History” とい全なものの再現率は低くなっている．これは，同一機能を実装

うキーワードに一致した xbrowser.history.HistoryFinder クラしているクラスが必ずしも全体で同時に更新されるわけではなスとした．また，更新傾向グラフからの抽出で用いる閾値は，いため，同時に更新されることが少なかったクラスを取りこぼ

ブックマーク機能，ヒストリ機能共に，Eth = 0.95 とした．

してしまった．また，1 つのブックマーク機能でも更にいくつ実験に対する評価は，クラスごとにブックマック，ヒストリかの細かな機能に細分化され細かな機能の単位で更新が行われの各機能を実装しているかをソースコードから判定し，その上たため，細かな機能の単位で抽出されたためだと考えられる．

で，適合率，再現率を用いて評価を行った．手法によって抽出

静的情報のみで抽出した場合は，多くのクラスを抽出するこされたクラスの数を抽出クラス数，ソースコードから実際に機とができ，再現率は更新履歴情報のみより高いものの，ブック能を実装していると判断したクラスの数を正解クラス数，手法マーク機能とは関係のないクラスも多くとってしまい適合率がによって抽出されたクラスのうち実際に機能を実装していると低くなってしまった．これは，今回の手法では，そのクラスを判断したクラスの数を該当クラス数とすると，適合率，再現率

呼び出しているクラスとそのクラスに呼び出されいてるクラスの計算は次の式で行う．

をすべて抽出してしまうが，実際には別の機能を呼び出したり

適合率 =該当クラス数
抽出クラス数

再現率 =該当クラス数
正解クラス数(2)

ブックマーク機能の実験結果を表 2 に，ヒストリ機能の実験結果を表 3 に示す．

5. 考

察

別の機能に呼ばれるすことも多いので機能とは関係のないクラスも抽出してしまったからだと思われる．
提案手法全体を行った場合は，更新履歴情報のみ，静的情報のみに比べ，適合率，再現率ともに高い値になった．
手順の各段階での抽出結果を見てみると，提案手法の更新履歴情報を用いる部分まででは，すべて実際に機能を実装してい3. 1 節の開始クラスの決定方法として，今回は機能名を用いるクラスを抽出できているものの，実際に機能を実装しているてクラス名のキーワード検索を行った．今回の方法以外に用いクラスのうちの一部分しか抽出することができなかった．しかることが可能な方法としては，ソースコード部品の検索システし，静的情報を用いることにより更新履歴情報から抽出できなムなどを用いるということが考えられる．ソフトウェア部品検かったクラスの補完を行うことで，同時更新傾向が低く抽出で索システムとは，ソフトウェア部品特有の性質を利用した検索きなかったクラス群の多くを抽出することができ，再現率を飛システムで，クラス名を用いたキーワード検索より機能の特徴躍的に上げることができた．

を反映した開始クラスを選ぶことができる．

3. 4. 2 節で，3 つ以上の抽出クラスから呼ばれている，ある今回の適用実験では，ある程度の同一機能を実装しているクいは呼んでいるとした．これは，その機能を実装している複数ラス群を抽出できた．しかし，提案手法は 2 つの情報を用いてのクラスと接続している場合，同じ機能を実装していると考えおり，両方の情報が必要になる．例えば，更新回数が著しく少られるためだが，2 つとした場合はそのクラスの他の機能と関ないソフトウェアに対しては，更新履歴情報からの抽出ができ係している場合も考えうるということからクラス数を 3 とした．

ず，静的手法からの抽出はできるものの精度が下がってしまう．

このように設定した結果，誤って抽出することなく，同一機能—5—を実装しているクラスを抽出できた．しかし，どのソフトウェ定の機能を実装している箇所を特定できることを確認した．

アでも 3 という値を用いることができるかは今後検証していく

今後の課題として以下のことがあげられる．

必要があると考える．

•

更新傾向グラフからの抽出で，誤って他の機能を実装しまた，提案手法を行った結果，単独で手法を適用するより再ているクラスも抽出してしまい，補完を効果的に行うことがで現率は高くなったものの，まだ機能を実装しているクラスを完きなかった．更新傾向グラフからの抽出手法について改良して全に抽出することはできていない．そのため，適合率をあまりいき，精度を上げていきたい．

下げることなく再現率を上げるためにコールグラフを用いて抽•誤って抽出されたクラスの除去の精度が悪く，更新履歴出できなかったクラスを補完していく方法を改良していく必要

情報からの抽出で誤ってクラスを抽出してしまった場合，適合があると考える．

率と再現率を大きく下げることになった．そこで，抽出クラス

5. 2 ヒストリ機能

距離以外のメトリクスを用いることでより効果的に除去を行え

ヒストリ機能の抽出も，ブックマーク機能同様，提案手法のるように考えていきたい．

適合率，再現率が最大となった．

•

提案手法では，適合率は高かったものの，再現率はあましかし，ブックマーク機能に比べ，適合率，再現率ともに低り高くなかった．そこで，抽出できなかったクラスの補完の方く，特に再現率は 50%以下となってしまった．この原因として法として，現在の 3 つの条件以外に適当な条件がないかを検討考えられるのは，更新履歴情報からの抽出がうまくいかず，さしていきたい．

らに，コールグラフを用いての誤って抽出したクラスの除去もあまり効果的にできなかったためである．更新履歴情報からの抽出がうまくいかなかった原因は，ヒストリ機能は，開いたページの履歴を取得する際，他の多くの機能と直接関係しており，開発や保守においてヒストリ機能を実装，修正する際，同時に他の機能を実装しているクラスも更新することが多く，ヒストリ機能を実装していないクラスとの間の conﬁdence も高くなったため抽出されてしまったためと考えられる．さらに，コールグラフから誤って抽出したクラスの除去では，除去することができた 2 つともヒストリ機能を実装しておらず正確に除去できたものの，9 個ある誤って抽出したクラスのうち 2 個しか除去することができなかった．これは，更新履歴情報から誤って抽出されたクラスと開始クラスの抽出クラス距離が近いものが多かったため本手法での除去では効果的に除去することができなかったためと考えられる．
また，十分に誤って抽出したクラスを除去できなかったため，補完する際，誤って抽出したクラスがノイズとなり，そのクラスの周辺の別の機能を実装しているクラスを抽出してしまったため，適合率も下げてしまうことになった．
今後，更新傾向グラフから誤って抽出することが少なく，機能実装クラスを多く抽出できるように工夫し，また，抽出クラス距離以外のメトリクスも用いることによりさらに多くの誤って抽出したクラスの除去を行えるようにしたい．

6. ま と め
本研究では，あるクラスと同一の機能が実装されている部分を特定する手法として，更新履歴情報を用いた手法に静的手法を組み合わせて用いる手法を提案した．具体的には，更新履歴情報として，クラス間の同時更新の傾向を表現する更新傾向グ•

現在はクラス単位での抽出のみしか実装していないため，メソッド単位やパッケージ単位での抽出も実装していきたい．
文

献[1] K. Chen and V. Rajlich: “Case Study of Feature Location
Using Dependence Graph”, In Proceedings of the International Workshop on Program Comprehension (IWPC’00),
pp.241–249, 2000.
[2] T. Eisenbarth, R. Koschke, and D. Simon: “LocatingFeatures in Source Code”, IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING (Vol. 29, No. 3), pp.210–224, 2003.
[3] A. D. Eisenberg and K. D. Volder: “Dynamic Feature
Traces: Finding Features in Unfamiliar code”, In Proceedings of the International Conference on Software Maintenance (ICSM’05), pp.337–346, 2005.
[4] K. Erdos and H. M. Sneed: “Partial comprehension of complex programs(enough to perform maintenance)”, In Proceedings of the International Workshop on Program Comprehension(IWPC’98), pp.98–105, 1998.
[5] A. E. Hassan and R. C. Holt: “Using Development History Sticky Notes to Understand Software Architecture”,
In Proceedings of the International Workshop on Program
Comprehension (IWPC’04), pp.183–192, 2004.
[6] I. Jacobson, M. Griss, and P. Jonsson: “Software Reuse”,
Addison-Wesley Pub, 1997.
[7] 楠田: “メソッドの同時更新履歴を用いたクラスの機能別分類法”，大阪大学 大学院情報科学研究科 修士学位論文，2006.
[8] J. J. Marciniak: “Encyclopedia of Software Engineering”,
John Wiley & Sons, 1994.
[9] W. Zhao, L. Zhang, Y. Liu, J. Sun, and F. Yang: “SNIAFL:
Towards a Static Non-Interactive Approach to Feature Location”, In Proceedings of the International Conference on
Software Engineering (ICSE’04), pp.293–303, 2004.
[10] T. Zimmermann, S. Diehl, and A. Zeller: “How history justiﬁes system architecture (or not)”, In Proceedings of theInternational Workshop on Principles of Software Evolution (IWPSE 2003), pp.73–83, 2003.
[11] “XBrowser”. http://xbrowser.sourceforge.net/

ラフを用い，同時に更新されるものが多いクラスを抽出した．
さらに，静的情報として，クラス間の呼び出し関係を表現するコールグラフを用い，誤って抽出したクラスの除去と抽出できなかったクラスの補完を行った．また，提案手法について適用実験を行い，静的手法と更新履歴を用いた手法を組み合わせた結果，手法を単独で実行するときより高い適合率，再現率で特—6—