部品間の関係変化を分析するツールにおける後継部品の追跡に関する考察
2010SE112 草野福美 2010SE191 澤本美澄 2010SE239 田西恭平
指導教員：横森励士の差分の変化を示すこともできる．これらのツールでは，

1

はじめにソースコードの入手が可能な一方でリポジトリの情報が何
ソフトウェア開発では，様々な変化への対応や，品質のらかの理由で入手できない場面でも，分析可能とすること

向上，機能の向上を図るために長期にわたって保守活動がを想定し，入力を各バージョンのソースコードとしている．

行われているものが多数存在し，内部の構造はしだいに複雑化し把握しにくくなる．ソフトウェアを構成する部品間の関係がどのように複雑化するのかを視覚化するツールが提案されているが，単純にファイル名とパッケージ名が一致している部品間の前後のバージョンで関係を追いかけるだけでは，途切れる部品が多く，変化を追跡するのに不十分であった．
本研究では，ファイル名やパッケージ名が更新前後で変化した部品に着目し，その部品の名前がどう変化したか，
図 1 Use Relation Viewer の画面

それらが後のバージョンの部品と対応付け可能かを実際のオープンソースソフトウェアを対象に調査する．内容がどう変わったかを調査し，どのような方法を採用すれば視覚化ツールにおいて十分な効果を発揮できるか考察する．こ3

研究についてれらの分析から，後継となる部品とみなす条件を設定し， 3.1 既存ツールの問題点
それらの基準にもとづいてツール上で連続した部品として現状の部品間の関係を視覚化するツールでは，ファイル表示させる．これらの改良が視覚化ツールには必要不可欠名およびパッケージ名が完全一致した場合のみ，履歴中でであると考えられ，このような改良を行うことで，ツール同一の部品とみなしている．同一の機能を保有しているクを通じて開発者がソフトウェア開発における進捗情報をよラス同士であっても，ファイル名や存在するパッケージがり的確に共有することができると考えられ保守活動におけ一致しなければ別のクラスとみなされ，関係の変化を追跡る作業の支援につながると考えられる．
することができない．グラフとして表示した場合，例えば

2

背景技術

2.1

ソフトウェアの成長と視覚化ツールパッケージを移動した時点で追跡できなくなるので，図 1のようにグラフの線が途切れて表示されてしまう．

3.2

研究の目的

長期間にわたって開発されたアプリケーションは，不具合の対応，機能の追加などを通じて多くの修正が行わ

本研究では，実際のオープンソースソフトウェアの開発れている．それらの修正によって，時間と共にソフトウェ履歴を対象に，前のバージョンのクラス群と一致しなかっアの構成はより複雑化していく．私たちの研究室では，開たクラス群の分析を行う．分析では，その直後のバージョ発を通じてソフトウェアの部品間の関係がどのように変ンにおいてクラスで記述されていた内容がどのクラスに化していくかをグラフとして視覚化するツールを，Clone存在するかを調査し，それぞれのクラスの後継の部品とな

Tool[3] および Use Relation Viewer（URV）[4] として提案した．Clone Tool[3] は，ソフトウェアの複数のバージョン間のファイルを分析して，コードクローンの変化を視覚的に表示するツールである．CCFinder の分析結果とるべきクラスを推定する．分類ごとに内容の一致率を調査し，どのような形で後継となる部品を推定すれば十分な効果を発することができるかを考察する．

4

評価実験

して生成されるテキストファイルを読み込み，コードクローンの変化を表やグラフとして出力する．Use Relation

以下の項目を分析することを目的として，本研究の評価

Viewer[4] は，Java ソフトウェアのクラス間の利用関係を分析するツールである．Classycle の分析結果として生成される xml ファイルを読み込み，表やグラフとしてファイル間の利用関係を，図 1 のように視覚化する．ソフトウェ

実験で調査する．さらに，それぞれの項目について詳細なアの複数のバージョン間のファイルを分析して，利用関係分析を行うために，それぞれに小項目を追加する．

1. パッケージ名の変更されたクラスはどの程度存在するか．
（a）パッケージ名の変更はどのように行われている表 1 データの分類項目

か．
（b）パッケージ名の変更の場合，どれだけ更新前後で記号項目中身が一致しているのか．

ABCD

2. クラス名の変更はどの程度存在するか．
（a）クラス名の変更はどのように行われているか．
（b）クラス名の変更の場合，どれだけ更新前後で中身パッケージ・クラス名が両方変更
パッケージ名のみ変更
クラス名のみ変更
後継の部品なし

が一致しているのか．

3. ファイル名の変更以外の理由により追跡ができなくした理由についてもそれぞれ調査を行い，次のように調査なっているクラスはどの程度存在するか．
（a）ファイル名の変更以外の理由により追跡ができなくなっているクラスは，どのように変更されているか．

4.1

評価実験の方法

あるソフトウェアの開発履歴を対象として，以下の作業を行う．これにより，連続したバージョン間で追跡できなかったファイルを調査する．

1. いくつかの連続したバージョン群を選び，ソースコードを取得する．

した．それぞれの項目について，例も併せて示す．

• 所属パッケージが親になった
例：test.example.cname → test.cname• 所属パッケージが子になった
例：example.cname → test.example.cname• パッケージ名が途中で変わった
例：test.example.cname → package.example.cname• パッケージ名の最後の部分が変わった
例：test.example.cname → test.example.cnames

2. 連続する２つのバージョンを抽出し，ファイル名，パッ• パッケージ名の途中と最後の部分の両方が変わった
例：test.example.cname → package.example.cnames

ケージ名が次のバージョンに存在しなかったものを抽クラス名の変更にあたる項目 A，C については，変更内出する．

3. 抽出したファイルから，クラス名が一致するファイルが次のバージョンに存在するかを調査する．

4. クラス名が一致したファイルが存在しなかった場合，同一のパッケージ内から，類似したクラス名のものが存在するかどうかを調査する．

5. 類似したクラス名のものが存在しなかった場合，パッケージ名，クラス名の両方に着目し，名前が類似したファイルが存在するかどうかを調査する．

6. 上記３つの手順について，後継となる部品である可能性の高いファイルが発見できた場合，ソースコードを比較し，評価を行う．

7. 以上の手順を繰り返し，最終的に後継となる部品とみ容について調査を行い，次のように分類した．こちらもそれぞれの項目について，例も併せて示す．

• クラス名の単語が一部違うものに変化した
例： TestExample → PackageExample• クラス名に新しい単語が付け足された
例： Example → TestExample• クラス名が単純に変更された
例： Example → Examples後継となる部品がない場合は D として分類した上で，類似した機能を持つクラスがないか調査を行い，さらに以下のように分類した．

• 別のクラスに統合された• 完全に消滅した

なすことのできるファイルが存在しなかった場合，後4.3

評価実験の対象継となる部品はなしと判定する．の後継の部品と想定されるソースコード Q について，(QSourceForge で公開されている開発プロジェクトを対象として，評価実験の対象プロジェクトを選出した．Java を開発言語として，5 バージョン以上のソースコードが入手できるという条件のもとで，次の 6 プロジェクトを分析対に含まれる P の行数 +P に含まれる Q の行数)/（P の行象とした．

このように分類したクラス群について，後継となるクラスが存在するクラスについてそれぞれに diff を用いて類似度を計算する．なお，類似度とは，ソースコード P と P数＋ Q の行数）で定義したものである．内容がコピーされた部品ほど，高い値を示すと考えられる．

4.2• Freemind*1
マインドマップ作成ソフトウェア．

• Hodoku*2
評価実験における結果の分析方法
数独（ナンバープレイス）のためのソフトウェア．

後続のバージョンでパッケージ名，クラス名が一致する部品が確認できなかった部品について，表 1 で分類した．
パッケージ名の変更にあたる項目 A，B については，移動*1 http://sourceforge.net/projects/freemind/*2 http://sourceforge.net/projects/hodoku/• JgraphT*3
Java におけるグラフを構築するためのライブラリ．

（a）パッケージ名の変更はどのように行われているか．

• JavaGeom*4→プロジェクトごとにばらつきはあるが，パッジオメトリアプリケーション用の Java ライブラリ．

ケージの途中部分が変更したものが最も多く確認された．Freemind では，階層の変化を伴った• JXPlorer*5
JavaLDAP クライアント．

パッケージ名の変更はなかったが，そのほかのプロジェクトではパッケージの階層が変化してい• JIPT*6
Java の画像処理のツールキット．

た．特に，JgraphT と JavaGeom では，パッケージが親や子になる変更の方が多くなっていた．
（b）パッケージ名の変更の場合，どれだけ更新前後で表 2 追跡できなかったクラスの個数中身が一致しているのか．
プロジェクト名

次のバージョンで追跡できなかったクラス数

A

B

CD

6157
15511322
1600
6000314312078
0060
400024142535
2216

Freemind
HodokuJgraphT
JavaGeom
JXPlorer
JIPT→ Freemind，JgraphT では平均でも半分以上一致する場合が多く，クラスによっては完全に一致したものも存在した．その一方で，Hodoku とJavaGeom では一致率が低く，平均で 1 ％未満となり，プロジェクトによって差が大きく開いた．
どのプロジェクトでも類似度が最も高くなるのはパッケージ名の変更の場合であった．

2. クラス名の変更はどの程度存在するか．
4.4

評価実験の結果

前節で選んだ 6 つのプロジェクトに対して，後継となる部品の推定を行った．結果を表 2 に示す．パッケージ名の→クラス名の変更はパッケージの移動より少ない頻度で見られた．
（a）クラス名の変更はどのように行われているか．
→プロジェクトごとにばらつきがあること，色々み変わるケースが特に多く見られた一方で，クラス名の変更は多くないとわかった．また，どのプロジェクトでもある一定の部品は後継となる部品を確認できなかった．
次に，さらに細かく分類した結果と，追跡可能部分について分類ごとに平均類似度を測定した結果を表 3 に示なパターンが混在していることがあった．Free-mind では 3 つのパターンがそれぞれ同じ頻度で見られ，JgraphT では，名前の単語の付け足しが最も多く，名前の単語の一部の変化が最も少ないというばらつきが見られた．

す．プロジェクトごとに平均類似度が大きく異なることが見受けられる．Freemind では，パッケージ名の変更に（b）クラス名の変更の場合，どれだけ更新前後で中身よるものが高い類似度を示している．しかし，Hodoku，が一致しているのか．

JavaGeom では類似度は極端に低い数値を示している．対→名前の一部の単語が変化した場合が最も高い類似度を示した．全体的にパッケージ名の変化の象のプロジェクトを通じて，パッケージの最後の部分が変更されたケースは高い類似度を示している．クラス名の変場合と比較して一致度は低い．JgraphT では名更によるものでは，各プロジェクトそれぞれ平均類似度が前の変化で一致度が 0 という極端な結果が見られた．

パッケージ名の変更によるものと比べて低い数値を示している．クラス名の変更によるものの中では，名前の単語が3. ファイル名の変更以外の理由により追跡ができなく変化したものが最も高い数値を示した．また，後継となるなっているクラスはどの程度存在するか．

部品が存在しなかったものもいくつか存在が確認されて→どのプロジェクトでも存在が確認された．後継部品いる．

が存在しないもののみのプロジェクトもあった．

5（a）ファイル名の変更以外の理由により追跡ができな

考察
くなっているクラスは，どのように変更されてい評価実験の結果から，以下の結果を得ることができた．
るか．

1. パッケージ名の変更されたクラスはどの程度存在する→ほとんどが完全に消滅していたが，ほかのクラか．
スに統合されたクラスの存在も確認された．
→対象のプロジェクトでの追跡できなかったクラス
評価実験を行った結果，追跡できなかったクラスはパッは，ほとんどがパッケージ名の変更が原因であった．
ケージ名の変更が原因となっているものが大多数であった．実際に追跡できなかったクラスを次のバージョンのク*3 http://jgrapht.org/*4 http://geom-java.sourceforge.net/

ラスと比較したところ，関連したファイルがまとめて違う*5 http://jxplorer.org/

パッケージに移動されたことで大量のクラスが追跡でき*6 http://sourceforge.net/projects/jipt/表 3 それぞれのクラスの分類結果
Freemind

HodokuJgraphT

JavaGeom

JXPlorer

項目数

平均類似度

数

平均類似度

数

平均類似度

数

平均類似度

数

平均類似度

数

平均類似度

パッケージ名の変更によるもの (A，B)

3100
3
12
16
6222
24
6
18

0.592
0.466
0.276
0.674
0.268
0.491
00.313

43
50
38
0
0
0
000
14
0
14

0.001
00.001
-130
1238
71
7
3
122
6
4
4
7
16

0.476
0.205
0.290
0.591
0.869
0.333
0.130
0.471
0.103
078
069
8
10000035
035

0.093
0.086
0.047
0.989
-000000000022022-000000000016016-

パッケージが親になったパッケージが子になったパッケージの途中部分が変更されたパッケージの最後部分が変更されたパッケージの途中部分，最後部分が両方変更された
クラス名の変更によるもの (A，C)
名前の単語の一部が変化した
名前に単語が付け足された
名前が変化した後継となる部品が存在しなかったもの (D)他のクラスに統合された
完全に消滅していた

JIPTなくなっている例が多く存在した．新しい所属パッケージ

Configuration Management) システムを提案した．本研が親パッケージになったものや，子パッケージになった例

究では，各バージョンのソースコードのみが得られることもいくつか存在した．クラス名については，１つの変更のも分析の前提としているが，リポジトリの情報も入手可能

影響は，名前が変更されたファイル自身にのみ起こるが， な場合，これらの手法をもとに，より正確な追跡が行えるパッケージ名の変更は，１つの変更が起こると，そのパッことが予想できる．

ケージに属する全てのファイルに影響を起こしてしまうの

6

まとめで，クラス名よりも，パッケージ名の変更により追跡でき
本研究では，ファイル名かパッケージ名が更新前後で変なくなったクラスが多く発生したと考えられる．
類似度を調査するとプロジェクトごとに大きく異なり， 化した部品について，それらの部品がどう変化したかを調
全体的に４割以上の比較的高い数値を割り出すプロジェク 査した．結果として，パッケージ名の変更の場合は，更新前後で中身が比較的変化しないこと，プロジェクトごとにトもあれば，１割以下の低い数値がほとんどを占めるプロジェクトも存在した．しかし，同じプロジェクト内では， 傾向が異なることなどを確認した．今後，後継となる部品類似度が全体的に高いか，全体的に低いかのどちらかにな とみなす条件を設定し，ツールに反映させることで，ツールが示す情報がより有益になり，情報の共有が効果的に行る傾向があったので，名前による追跡が有効なプロジェクえるようになることを通じて保守作業を支援することがで
トとそうでないプロジェクトで追跡の有無を選択することきることと考えられる．
ができれば有効であると考えられる．

5.1

参考文献
関連研究

[1] M.Kim,D.Notkin: ”Program Element Matching forMulti Version Program Analyses,” in processing of
品群（クラス群）がどのように対応をしているかを分析すthe 2006 international workshop on mining software
るための研究は数多く存在している．文献 [1] によると，
repositories, P.58-64,2006.
ソフトウェアの更新前後において，更新前，更新後の部それらのマッチングに関する研究のサーベイを行っており，手法を大きく分けて 7 つに分類している．文献 [1] によると，一番単純な，ソフトウェア部品の中に存在する固有名詞，動詞などの名前を用いてマッチングを行う方法である Entity NameMatching で，多くのバージョン間でのマッチングに対して，一番基本的であるが十分な性能を示していると述べている．本研究の分析結果でも，後継となる部品の存在したクラスのうち，パッケージ名のみの変化が全体の多くを占めており，部品間の関係変化を追跡するツールにおいても，パッケージ名を吸収することが後継となる部品の追跡に対して有効であると考えられる．

Danny らの研究 [2] では，リファクタリングを通じてソフトウェア内部構造が変化することに対応することも目的として，それぞれの構成要素やリファクタリング操作を考慮して，更新のヒストリーが保たれるような SCM(Software[2] D.Dig,K.Manzoor,T.Ngayen,R.Johnson:”Refactoring-aware Configuration Management
for Object-Oriented Programs,” Proceeding of
the 29th International in Conference on Software
Engineering, P.427-436,2007.
[3] 松坂太智，岡田直希，坂下智紀：”バージョン間のコードクローン関係の変化を提示するシステムの試作，”南山大学情報理工学部 2012 年度卒業論文要旨集，2012．
[4] 亀井雄佑，木下裕太郎，前原一機：”バージョン間の利用関係の変化を提示するシステムの試作，”南山大学情報理工学部 2012 年度卒業論文要旨集，2012．