ソフトウェア部品分類手法へのコンポーネントランク法の応用
中塚 剛 ††

松下 誠 †

井上 克郎 †

大阪大学 大学院情報科学研究科〒 560-8531 大阪府豊中市待兼山町 1-3

ソフトウェア部品を分類することによって，巨大なシステムを複数のサブシステムに分解するソフトウェア
クラスタリング手法は，大規模なソフトウェアを理解するために有用である．しかし，システム内には，特定のサブシステムに属すべきでないライブラリのような部品も存在する．そのような部品を事前に特定することにより，クラスタリング結果の質が向上することが期待できる．本稿では，ソフトウェア部品の重要度を測定するコンポーネントランク法を用いることにより，特定のサブシステムに属すべきではない部品を特定する手法の提案を行う．提案する手法を用いたクラスタリングツールを用いて実験を行い，得られた結果に対する考察を行った．その結果，従来手法よりも優れたクラスタリング結果を得られることがわかった．

An Application of Component Rank Modelto Software Clustering Algorithm
Gou Nakatsuka††

Makoto Matsushita†

Katsuro Inoue†

Graduate School of Information Science and Technology, Osaka University
1-3 Machikaneyama-cho, Toyonaka, Osaka 560-8531, Japan

Decomposing a large software system into some subsystems by grouping software modules helps us understand its
structure and functions. In the system, however, there are special modules such as libraries that should not belong
to a certain subsystem, and pre-detecting such modules can make the clustering results better. This paper proposesa new method of detecting such modules by Component Rank Model, that is used to measure mutual signiﬁcanceof software modules. We performed experiments with a new clustering tool combined with our detecting method
and investigated the clustring results. As a result, our method turned out better than an existent method.

1

まえがき

様々なソフトウェア部品（例えば Java の場合，クソフトウェア開発現場において，保守やソフト

ラスやインターフェース）を何らかの方針に従っ

ウェア部品再利用を行う際，あるソフトウェアシて分類して，システムを複数のサブシステムへ分

ステム（以降，システム）の構造や機能を理解する

解する手法であり，これまでに様々な手法が提案必要がある [10]．しかし，仕様書等の不備や，ソされている [3, 9]．以下，ソフトウェアクラスタリ

フトウェアの巨大化，複雑化等の原因によりソフングにおいて，システムに含まれる分類の対象とトウェア理解が非常に困難な場合が多い．

なる部品の単位を「モジュール」と呼ぶ．

このような場合に，ソフトウェア理解を助ける

ソフトウェアクラスタリングの方針の一つとし手法の一つとしてソフトウェアクラスタリングとて，各サブシステムが強凝集・低結合になるよういう手法が研究されている．ソフトウェアクラス

に分類を行う方法がある [5, 7]．これにより，密にタリングとは，ソフトウェアシステムを構成する

依存しあっているモジュールをクラスタとするこ-1-

とによってサブシステムを構成し，サブシステム

良することを示す．

間の依存関係をできるだけ少なくするというもの

以降，2 節で研究の背景であるソフトウェアクラである．

スタリングについて説明した上で，3 節にて本研究

しかし，ソフトウェアクラスタリングの結果，シに関連する 2 つの手法について説明する．4 節で，ステム内の全てのモジュールをいずれか一つのサ

コンポーネントランク法を用いた遍在モジュール

ブシステムに属させないほうが良い場合がある．一

特定手法を決定するための実験と結果について説

般的にライブラリと呼ばれるようなモジュール，例

明し，5 節でまとめと今後の課題について述べる．

えば文字列を操作するようなモジュールは様々な

2 ソフトウェアクラスタリング

モジュールから利用されており，特定のサブシス

2.1 概要テムに含めることは適切ではない．また，例えば

ソフトウェアクラスタリングは，システムを構

java.awt パッケージ内の java.awt.Component
クラスのように，様々なクラスから参照もしくは成する多くのモジュールを，ある特定の基準に基づいて分類し，システムを複数のサブシステムに継承されるような抽象データクラスも，特定のサ分解することによって，ソフトウェア理解を助ける

ブシステムに属するべきではない．このようなモための手法である．多くのクラスタリングアルゴ

ジュールは遍在モジュール（omnipresent module）

リズムは，システムの構造に基づいて分類を行う．

と呼ばれている [6]．遍在モジュールはソフトウェ

システムは，複数のモジュールがお互いに依存

アクラスタリングを行う前に特定し，事前にクラしあって成立しており，その様子は図 1 の左図のスタリング対象から除去する必要がある．

ように，モジュールを頂点，依存関係を有向辺と従来のソフトウェアクラスタリング手法では，あした有向グラフ（以下，依存関係グラフ）を用いるモジュールが依存関係を持つモジュールの数が，て表される．ここで，モジュールとは，C 言語なある閾値以上のモジュールを遍在モジュールとす

どの手続き型言語の場合ファイルを指し，Java なるという単純な手法で特定している [5,6]．つまり，どのオブジェクト指向言語の場合クラスあるいは

従来手法では直接的な依存関係のみを考慮しておインターフェースを指す．また依存関係とは，関り，間接的な依存関係を考慮していない．特にオ数呼び出し，変数参照，継承，インターフェース

ブジェクト指向言語の場合，継承やインターフェー

実装を指し，場合によっては依存の程度を表す辺

ス実装といった依存関係も考慮するため，間接的に重みをつけることもある．

な依存関係がより重要になると考えられる．しか   し，これまでに遍在モジュールに関して詳細な考察を行っている例は少ない．
一 方 ，Java ソ フ ト ウェア 部 品 検 索 シ ス テ ム

SPARS-J [1] では，システムに含まれるモジュールの重要度を計算するためにコンポーネントラン
ク法と呼ばれる手法が用いられている．この手法

図 1: クラスタリングの例

は，あるシステム内のソフトウェア部品の直接的，間接的な相互利用関係を解析することによって，各

このような依存関係グラフを分割する方針の一

ソフトウェア部品の重要度を計算する．このコンつとして，高凝集・低結合の原則に基づいて分割す

ポーネントランク法によって上位にランク付けさるというものがある [5, 7]．具体的には，図 1 の左れたクラスは，ソフトウェア中の多くから利用され図で示されるような依存関係グラフで表されるシる重要な部品であることがわかっており [12]，これステムを，右図のように依存関係が密な部分をク

は，遍在モジュールの満たすべき性質と似ている．

ラスタとしてまとめる方法である．この結果，クラそこで本稿では，コンポーネントランク法を利

スタ内の辺が多く，クラスタ間の辺が少なくなる

用して遍在モジュールを特定する手法を，実験にような分割となる．このようにして作られたクラよって評価，決定する．その結果，本手法が従来

スタは，に着目することによってその動作を理解のソフトウェアクラスタリングアルゴリズムを改-2-

することが容易となり，ソフトウェアを理解するた

行えるシステムが，Mancoridis，Mitchell らによっめの有用な方針として広く研究されている [5,7,8]．

て開発された Bunch [5] である．Bunch では，ソフ

2.2

トウェアクラスタリングを探索問題として定義す

遍在モジュール

しかしながら，全てのモジュールを，高凝集・ることにより解を求める．つまり，分割結果を評

低結合となるようなサブシステムへ分類すること価するための目的関数を定義して，考えられる分が適切ではないことがある．その要因として，遍割全てに目的関数を適用して評価値が最も高いも在モジュール（omnipresent module）と呼ばれるモのを解とする．しかし，頂点数 n のグラフに対す

ジュールの存在が知られている．遍在モジュール

るクラスタリング結果の総数は O(n!) となり，このは，一般的にユーティリティやライブラリと呼ば中から最適なものを探す問題は NP 困難である [8]．

れるようなシステム内の多くのモジュールと依存

そこで，局所探索法である山登り法（hill climbing）

関係のあるモジュールを表している．このようなによって近似解を求めている．

Bunch では，分割を評価するための目的関数とモジュールは，特定のサブシステムに属すべきでして，MQ（Modularization Quality）を定義していはない（図 2）．

る．これはサブシステムの凝集度と結合度のトレードオフを関数化したもので，以下のように与えられる．なお，評価する分割中のクラスタ数を k と    する．
まず，クラスタ i (1 ≤ i ≤ k) 内に含まれる辺（クラスタ i 内の 2 頂点間にある辺）の数を µi とする．
また，クラスタ i からクラスタ j への辺（クラス

図 2: 遍在モジュールの例

タ i 内の頂点からクラスタ j 内の頂点への辺）の数を εi, j とする．

そのため，ソフトウェアクラスタリングを行う

次に，各クラスタ i に対して関数 CFi （Cluster
Factor）を次のように定義する．
0(µi = 0)




2µi
(µ
CFi = i > 0)k 2µi + ∑ (εi, j +ε j,i )

前に，遍在モジュールを特定し，遍在モジュールとそれに関連する辺を除去したグラフに対して，ク
ラスタリングを行うアルゴリズムが知られている．
従来の遍在モジュール特定手法は，ある閾値を決めて，次数が閾値以上のモジュールを遍在モジュー

j=1, j,i

ルとしている．このとき，閾値の決め方はクラス

これは，各クラスタに関連する辺のうち，クラタリングアルゴリズムよって異なり（例えば，頂スタ内部にある辺の割合を表している．また，全点数の平方根を取ったもの [2] や，平均次数の 3てのクラスタの CF の合計を MQ とする．

倍 [5] など），どのような条件が遍在モジュールをMQ =特定するために有効であるかという詳細な考察はほとんど行われていない．次数のみで決定する手

Bunch では，遍在モジュールとして，次の 4 種類を定め，次のような特定条件を与えている．

ても，多くのモジュールに直接的あるいは間接的• supplier：入次数が平均次数の 3 倍以上• client：出次数が平均次数の 3 倍以上に依存されているモジュールは遍在モジュールとするべきである．

• central：supplier かつ client• library：出次数が 0
Bunch の遍在モジュール特定手法の問題点とし関連研究
この節では，本研究に関連する 2 つの研究について紹介する．

3.1

CFi

i=1

法は，単純すぎるといえ，次数が閾値以下であっ3k∑て，2.2 節で述べたように，次数のみによる単純なBunch評価であるという点に加えて，遍在モジュールの数

高凝集・低結合の原則に基づくクラスタリングをが多過ぎることがあげられる．特に，出次数 0 のモ行うシステムとして，現実的な実行時間で計算をジュールは多く，4 節で示す実験結果においては，-3-

全モジュールの 10∼30%が library として抽出され一般的に CRV の分布は，一部の部品が非常にてしまう．この結果，全モジュールの 30∼50%が高い CRV を持ち，ほとんどの部品の CRV は低く

遍在モジュールとして除去される．遍在モジューなることがわかっている．この性質を利用して，

ルはクラスタに属さず，個々に理解する必要があるため，遍在モジュールが多過ぎるとクラスタリ

CRV が非常に高い部品に着目することによりソフ
トウェアの理解を容易にするための研究も行われング結果は見にくくなる．

ている [12]．

指定した遍在モジュールによって，出力される

本稿では，「CRV の高い部品は，多くの部品に直クラスタリング結果は当然変化するが，本稿では，

接的あるいは間接的に使用されている部品であり，適切な遍在モジュールを特定することによって，遍在モジュールの候補ではないか」，という点にBunch の出力する解を改善することを目的とする．

注目して，CRV を用いた遍在モジュール特定手法

3.2を提案する．

コンポーネントランク法

Java ソフトウェア部品の再利用を助けるための，

4 CRV を用いた遍在モジュール特定手法

部品検索システムとして SPARS-J が開発されてい本節では，本稿で提案する，CRV を用いた遍在る [1]．このシステムは，Java で書かれたソース

モジュール特定手法について述べる．

コードを解析し，クラスやインターフェースをソフトウェア部品の単位としてデータベースに情報

Bunch で定義されている 4 種類の遍在モジュー
ルを CRV，次数によって特定することを考える．

を記録し，与えられた検索単語に対して関連する

その際，どのような閾値条件を用いれば，解を改ソフトウェア部品を提示する．その際，ソフトウェ良できるか検証するための実験を行った．

ア部品を提示する順番を決定する手法として，ソ

まず，考えられる特定条件として 40 の条件を定

フトウェア部品の重要度を数値化するコンポーネ

義し，その 40 の条件を比較するために，2 種類のントランク法（Component Rank 法，以下 CR 法）

実験を行い，実験結果より最適な条件を決定する．

が用いられる．

以下にその詳細を述べる．

CR 法では，依存関係グラフ上の各頂点に総和が1 となるように，それぞれ均等に重みを与え，各4.1 実験対象となる特定条件
本実験では，表 1 に示すように，C1∼C40 の遍在

頂点がその頂点を始点とする有向辺に重みを均等モジュール特定条件を実験対象として定めた．こに分配することによって，その辺の終点の新たなこで in，out，CRV の列はそれぞれ入次数，出次重みが決定する．これを各頂点の重みが収束する

数，CRV の条件を表し，数字は平均値からの倍率まで繰り返し，収束した値をコンポーネントランを表している．数字が正の場合，例えば 3 の場合

ク値（Component Rank Value，以下 CRV）とする．

は，平均値の 3 倍以上ならば該当とするが，数字CRV の計算の例を図 3 に示す．

が 0 の場合は，値が 0 でないと該当しない．

CRV=0.4aC1 は Bunch でデフォルトで用いられている特定条件であり，これよりも良い条件を探すことを目的とする．C2 は，遍在モジュールを全く考慮し

0.2
0.2

0.4

c CRV=0.2
0.2

bない条件であり，C3∼C5 は C1 の倍率を変更した

CRV=0.4

ものである．C6 は，遍在モジュールの数を増やし過ぎる原因であると思われる library を考慮しない

図 3: CRV 計算の例

条件である．

2 つの部品から使用されている b の CRV は高く

C7 以降は，supplier，central，library の条件になっており，また CRV の高い b から使用されている a の CRV も高くなっている．このように，たくCRV を使用している．この際，CRV が平均を超えるモジュールは全体の約 20%と少ないため，CRVさんの部品から使用されている部品の CRV は高くの条件としては平均以上のみを考慮する．supplier

なり，また，CRV の高い部品から使用されているの特定条件として，CRV 平均以上を固定して，入部品の CRV も高くなる．

次数条件を変化させたものでまとめてある．client-4-表 1: 遍在モジュール特定条件（実験対象，数字は場合，クラスタリングされたモジュールは理解し平均からの倍率）

やすいといえるが，多く特定された遍在モジュー

No.
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
C15
C16
C17
C18
C19
C20
C21
C22
C23
C24
C25
C26
C27
C28
C29
C30
C31
C32
C33
C34
C35
C36
C37
C38
C39
C40

supplierin CVR3

clientout
3centralin out CVR
3
3

2
2.5
3.5
3

2
2.5
3.5
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3

2
2.5
3.5
3

1
1
1
1
1
1
1.5
1.5
1.5
1.5
1.5
1.5
2
2
2
2
2
2
2.5
2.5
2.5
2.5
2.5
2.5
3
3
3
3
3

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

3
1
1
1
1
3
1.5
1.5
1.5
1.5
3
2
2
2
2
3
2.5
2.5
2.5
2.5
3
3
3
3
3

2
2.5
3.5
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3

library
in out CVR
0

ルは個別に理解する必要があるため，全体として理解にかかるコストが増加してしまう場合がある．

0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

よって，クラスタリング対象モジュール数（遍在モジュールではないモジュール）の数と，平均 CF

0
1
1

0
0
0
0

1
1
1

1
1
1

0
0
0
0
0

1
1
1
1

1
1
1

0
0
0
0
0

1
1
1
1

1
1
1

0
0
0
0
0

1
1
1
1

1
1
1

0
0
0
0
0

1
1
1
1

1
1

0
0
0

1
1
1

値のバランスを考えて，両方ともある程度高い結果がが優れた条件であることとする．
方針

15 種類の Java で書かれたオープンソース
システムに対して 40 の特定条件を適用し，クラス
タリング対象モジュール数と平均 CF 値が共に高い条件を求める．
結果と考察

15 システムに適用した結果の平均値を図 4 に示す．横軸は 40 の条件を表し，縦軸は，クラスタリング対象モジュール数の全モジュール数に対する割合と，平均 CF 値を示している．また，2 つの評価値の調和平均値も共に示してある．
左端の，C1 の結果が，Bunch オリジナル条件での結果であり，C2 と比べると，平均 CF 値が約 2倍に増加しているが，遍在モジュール数が多過ぎることがわかる．

特定条件には，CRV は使用しにくいため，出次数

C3∼C5 の結果は，閾値が増えるにつれ，クラス

平均 3 倍以上で固定している．central に関しては，

タリング対象モジュール数は増えており，逆に平supplier と client の両方の性質を持つものという意味から，2 つの条件を足したような条件とした．
library に関しては，出次数 0 だけでは条件が緩す関係となっていることがわかる．

均 CF 値は下がっていて，両者がトレードオフのぎるため，CRV 平均以上や，入次数平均以上といC6 の結果は，平均 CF 値が下がり，クラスタリ
ング対象モジュール数が約 40%の増加になっていう条件を加えている．

る．これは，出次数 0 という条件によって library

4.2

実験 1：結果の理解しやすさによる評価が多く選ばれていることを示している．

Bunch では，クラスタの凝集度と結合度のオー

C7 以降の結果は，C1 に比べて，2 つの評価値がバーヘッドを CF ， MQ という 2 つの関数で表す．

共に増加している条件が多数存在している．図中にこのとき，その値が高いほどクラスタ間に辺が少示した縦の破線で示したブロックごとに，supplierなくなり，クラスタリング結果が理解しやすいもに対する条件が厳しくなるが，結果は，クラスタのとなる． MQ は，値域が正規化されていないた

リング対象モジュール数は増加し，逆に平均 CF 値

め，モジュール数が多いシステムほどその値は高が減少している．つまり，トレードオフとなってくなる傾向があるが，CF は，0∼1 の値を取る．そいるが，調和平均値が改善していることがわかる．

こで，本実験では，平均 CF 値（全クラスタの CF

では，このクラスタリング対象モジュール数と平値の平均値）に注目した．

均 CF 値のどちらを優先すべきかという点を考え

ところが，平均 CF 値が高いほどクラスタリング

ると，遍在モジュールはあくまでも特殊なモジュー結果として良いというわけではない．遍在モジュールであって，たくさんのモジュールを遍在モジュー

ルを多く特定するほど，多くの辺が無視されるこルとして特定して別扱いするよりも，少し見づらとになり，平均 CF 値が高くなりやすいが，このくなってもクラスタに入れた方が，理解しやすい

-5-







 

                               !"#%$'&!(*) +,.- /'0!12 3 45./'03
図 4: 実験 1 の結果といえる．そこで，クラスタリング対象モジュー一つである GNUJpdf に対してベンチマークを作成

ル数を重視することにすると，C27∼C29 の条件がした．このシステムは，PDF ファイルを生成，印優れていることがわかる．C27∼C29 は，library の刷するための package で，25 モジュールから成る．

条件に CRV と入次数を加えたもので，C1 に比べ作成したベンチマークを図 5 に示す．

て，library の数を程良く減らしている．

4.3

方針

GNUJpdf のベンチマークと，40 条件におけるクラスタリング結果の類似度を EdgeSim，MeCl

実験 2：ベンチマークによる評価

実験 1 では，クラスタリング結果に付随する表面を用いて測定する．また目視による比較を行う．

的な評価値によって条件の比較を行った．次に，実際のクラスタリング結果を評価することを考える．

結果と考察

クラスタリングアルゴリズムを評価するために

実験 2 の結果を図 6 に示す．横軸は，40 の条件を表しているが，一部，下線を引いているものがある．これは，遍在モジュールの選び方によって，Bunch API の出力する解から一部のモ

よく用いられる手法として，ベンチマークを作成
してクラスタリング結果と比較するという手法がある [4, 11]．

ジュールが削除されているというバグが存在し，そベンチマークと解を比較するために両者の距離のため，Bunch API の解を一部書き換えて測定しを計る手法がいくつか提案されているが，ここではたことを表している．縦軸は，EdgeSim，MeCl を

EdgeSim と MeCl という 2 つのメトリクス [4] を用いた．EdgeSim（Edge Similarity）は，分解されたグラフ中で辺がクラスタ内に閉じているか，ある表している．両メトリクスの相関係数は 0.88 と非常に高い．
この結果から，CRV を用いることによって，Ed-

いはクラスタ間にまたがっているかという点に注

geSim，MeCl 共に値が改善している条件が多数目して，辺の類似度を測定するメトリクスである．

存在することがわかる．実験 1 で結果の良かった

一方 MeCl （Merge Clusters）は，片方のグラフを

C27∼C29 は，実験 2 でも非常に良い結果を示している．ただし，C29 は，前述の Bunch API のバグ

分割した後マージすることで，もう片方のグラフと一致させるために必要なコストを測定するメトのため，正しい解を出力できていない．

リクスである．これらのメトリクスは共に，パー

表 7 に C1 でのクラスタリング結果を，表 8 にセント尺度で，値が高いほど 2 つのグラフが類似

C27，C28 でのクラスタリング結果（この 2 条件は同じ結果）を示す．C1 では，ベンチマークに比べてlibrary が非常に多く，またクラスタ間の辺も多い

していることを意味する．ただし，この 2 つのメ
トリクスは，遍在モジュールを考慮しないため，遍在モジュールを含む結果に関して，正しい評価がことがわかるが，C27，C28 では，ベンチマークと行えない場合があるそのため，目視評価によって，異なるのは，PDFPage というモジュールが supplier

その点を補う必要がある．

か central かという違いのみで，ほとんど同じ結果

本実験では，実験 1 で用いたシステムのうちの-6-

libraries

suppliers

PDFStringHelper

PDFPage$procset

PDFTest

PDFOutput
PDFTestcentrals
PDFObject

PDFDocument

PDFOutput

BoundingBox
PDFPage

TestPanel

HelpFrame

TestMenuBar

PDFJobBoundingBox

PDFCatalog

PDFJob

PDFCatalog

PDFXref

PDFAnnotStringTooLongException

PDFJob$graphic

PDFInfo

PDFAnnot

PDFOutline

PDFPageList

PDFGraphics
PDFGraphics

PDFBorder

PDFImage
PDFFont

PDFImage

PDFStream

図 5: GNUJpdf のベンチマーク

 !"                                           
図 6: 実験 2 の結果となっている．

4.4の拡張がまず挙げられる．現状では行っていない，
遍在モジュールを考慮した上での評価を行えるよ

実験のまとめGNUJpdf では，C27，C28 で同じ結果を示してうに改良する必要がある．その上で，より大規模いるが，他システムでは結果は異なる．それらをなシステムでのベンチマーク実験を行い，提案手調査したところ，Bunch API では，central の条件法のさらなる評価を行いたい．

として，supplier かつ client としていない場合に正参考文献

しくない結果を出力し得ることがわかった．C28[1] Inoue, K., Yokomori, R., Yamamoto, T., Mat-は，central の条件が supplier かつ client となってめの最も良い条件であることがわかった．その条

sushita, M. and Kusumoto, S.: Ranking Significance of Software Components Based on Use
Relations, IEEE Transactions on Sofware Engi-

件は具体的には以下の通りである．

neering, Vol. 31, No. 3, pp. 213–225 (2005).

いないため，C27 が遍在モジュールを特定するた• supplier：入次数が平均次数の 2 倍以上，かつ
CRV 平均以上[2] Luo, J., Zhang, L. and Sun, J.: A Hierarchical Decomposition Method for Object-Oriented
Systems Based on Identifying Omnipresent
Clusters, Proceedings of the 21st IEEE Inter-• client：出次数が平均次数の 3 倍以上• central：supplier かつ client• library：入次数が平均以上，かつ出次数が 0，かつ CRV 平均以上

5national Conference on Software Maintenance,
pp. 647–650 (2005).

まとめ[3] Mitchell, B. S.: A Heuristic Search Approachto Solving the Software Clustering Problem,
PhD Thesis, Drexel University, Philadelphia,

本稿では，コンポーネントランク法によって測定されるコンポーネントランク値を用いて遍在モ
ジュールを特定し，高凝集・低結合の原則に基づ

PA (2002).

くソフトウェアクラスタリングを改良できることを確認した．

[4] Mitchell, B. S. and Mancoridis, S.: Compar-

今後の課題としては，クラスタリング評価手法

ing the Decompositions Produced by Software-7-

clients
PDFOutput

PDFTestPDFDocument

PDFTestlibraries
PDFXref

StringTooLongException

PDFStringHelper

suppliers
TestPanel

HelpFrame

TestMenuBar

PDFJob

PDFObject

BoundingBox

PDFPageList
PDFJob

PDFCatalog

PDFPage
PDFJob$graphic

PDFInfo

PDFOutline

PDFPageList

PDFGraphics
PDFGraphics

PDFPage

PDFImage
PDFImage

PDFAnnot
PDFFont

PDFPage$procset

PDFStream

PDFAnnotPDFBorder

図 7: GNUJpdf における C1 でのクラスタリング結果
libraries
PDFStringHelper

centrals
PDFPage$procset

PDFTestPDFDocument

PDFOutput
PDFTestsuppliers
PDFPage

PDFOutput

BoundingBox

PDFObject

TestPanel

HelpFrame

TestMenuBar

PDFJobBoundingBox

PDFOutline

PDFJob

PDFCatalog

PDFXref

PDFAnnotStringTooLongException

PDFJob$graphic

PDFInfo

PDFAnnot

PDFOutline

PDFPageList

PDFGraphics
PDFGraphics

PDFBorder

PDFImage
PDFFont

PDFImage

PDFStream

図 8: GNUJpdf における C27，C28 でのクラスタリング結果

Clustering Algorithms using Similarity Mea-of Systems and Software, Vol. 77, pp. 213–223

surements, Proceedings of International Conference on Software Maintenance, pp. 744–753(2001).

(2005).
[9] Tzserpos, V. and Holt, R. C.: ACDC : An Alogorithm for Comprehension-Driven Clustering,[5] Mitchell, B. S. and Mancoridis, S.: On the
Automatic Modularization of Software Systems

Proceedings of the Seventh Working Conference
on Reverse Engineering, pp. 258–267 (2000).

Using the Bunch Tool, IEEE Transaction on
Software Engineering, Vol. 32, No. 3, pp. 193–
208 (2006).

[10] von Mayrhauser, A., Vans, A. M. and Lang,
S.: Program Comprehension and enhancementof software, IFIP World Computing Congress -[6] Müller, H. A., Orgun, M. A., Tilley, S. R. andUhl, J. S.: A Reverse Engineering Approach To

Information Technology and Knowledge Engineering, Vinna, Budapest (1998).

Subsystem Structure Identiﬁcation, Journal of
Software Maintenance: Research and Practice,Vol. 5, No. 4, pp. 181–204 (1993).

[11] Wen, Z. and Tzerpos, V.: An eﬀectiveness measure for software clustering algorithms, Proceedings of the International Workshop on Pro-

[7] Schwanke, R. W.: An Intelligent Tool For Reengineering Software Modularity, Proceedings

gram Comprehension (IWPC ’04) (2004).
[12]of the 13th International Conference on Software Engineering, pp. 83–92 (1991).

市井誠，横森励士， 松下誠，井上克郎：コンポーネントランクを用いたソフトウェアのクラス設計に関する分析手法の提案，電子情報通信学会技術研究報告，SS2005-37，Vol. 105,[8] Shokoufandeh, A., Mancoridis, S., Denton, T.
and Maycock, M.: Spectral and meta-heuristic
algorithms for software clustering, The Journal

No. 229, pp. 25–30 (2005).

-8-c