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

信学技報
TECHNICAL REPORT OF IEICE.

コンポーネントランクを用いたソフトウェアのクラス設計に関する分析
手法の提案
市井

誠†

横森

励士††

松下

誠†

井上 克郎†† 大阪大学 大学院情報科学研究科†† 南山大学 数理情報学部 情報通信学科
E-mail: †{m-itii,matusita,inoue}@ist.osaka-u.ac.jp, ††yokomori@it.nanzan-u.ac.jp
あらまし コンポーネントランク法は，利用関係を基にソフトウェア部品の重要度の評価を行う手法であり，ソフト
ウェアリポジトリ中の重要な部品や再利用性の高い部品を知る事が出来る．本研究では，コンポーネントランク法を用いて，ソフトウェアのクラス設計に関する分析を行う手法を提案する．具体的には，ソフトウェア中で重要な役割をもつクラスを特定することにより，ソフトウェアのクラス設計の理解支援を行う．また，実際にソフトウェアに対する提案手法の適用実験を行った結果，ソフトウェア中で重要な部品を特定することができた．
キーワード

コンポーネントランク, クラス設計, ソフトウェア理解

An Analysis Method of Software Class Design using Component Rank
Makoto ICHII† , Reishi YOKOMORI†† , Makoto MATSUSHITA† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University†† Department of Information and Telecommunication Engineering, Nanzan University
E-mail: †{m-itii,matusita,inoue}@ist.osaka-u.ac.jp, ††yokomori@it.nanzan-u.ac.jp
Abstract Component Rank is a method for evaluating software component signiﬁcance based on use relations,and we can know which component is signiﬁcance or highly reusable in a software repository. In this paper, we
propose a method analyzing software class design with component rank. Speciﬁcally, identiﬁcation of importantclass for software comprehension. Also, we performed a case study with softwares and found that this method canidentify important classes in the software.
Key words Component Rank, Class Design, Software Comprehension

1. は じ め に
近年のソフトウェア開発の大規模化，および複雑化に伴い，も言い換える事ができ，検索結果の順位付けにコンポーネント
ランクを利用する事で，SPARS-J は検索者に対してより再利用性が高く，重要な部品を提供する事ができる．

ソフトウェアの再利用および管理を目的としたソフトウェア部

このように，コンポーネントランクは登録されたソフトウェ

品の蓄積および解析，検索を行うシステムが必要とされている．

ア中の部品を再利用する際に用いられてきたが，登録されたソ

SPARS-J [10] は Java を対象としたソフトウェア部品検索シス

フトウェアそのものの分析にも利用できると考えられる．

テムであり，依存や類似といったソフウェア部品の特徴を生かあるソフトウェア中のクラスに対してコンポーネントランク

した検索機能を提供する．また，パッケージブラウザやメトリを適用し，順位付けを行った結果について考える．この時上位

クスの出力機能を用いてシステムの全体像が把握できる点から，に来るクラスは，ソフトウェア中の多くのクラスから利用され企業でのソフトウェア資産の管理にも有用である [3].

ているクラスである．このようなクラスは，そのソフトウェア

SPARS-J は部品の順位付け手法としてコンポーネントラン

で中心となるクラスとみなす事ができる．また，コンポーネン

ク法 [2], [3], [11] を用いている．この手法では，多くの部品からトランクにおいては上位クラスから利用されるクラスもまた上利用されている部品は重要であり，また，重要な部品から利用

位に順位付けされるため，中心となるクラスと深い関連を持つされている部品も重要であるという概念に基づき，それぞれのクラスもまた上位に順位付けされる．このように，コンポーネ

部品の順位付けが行われる．この重要度は再利用実績の高さとントランクを用いる事でソフトウェアの中心となるクラスを知—1—

る事ができると考えられる．
ソフトウェア，特にオブジェクト指向設計の理解においては，

c4

c5

c1

c1'

C4

C5

まず中心となるクラスおよびその関連クラスの理解が重要であると考えられる．ソフトウェアの設計時には，ドメイン分析なC1

どにより中心となるオブジェクトを抽出し，関連の記述や詳細化を行いクラス設計を行う． 続いて，シナリオやユースケースなどをオブジェクト間のメッセージのやりとりとし，周辺のク

c2

c2'

C2

c3

(a) Relation of Components

C3(b) Relation of Clustered Components

ラスを設計する [8]．
図 1 部品グラフと部品群グラフ

このことから，中心となるクラスを理解する事により，ソフ
トウェア全体の理解が容易になると考えられる．しかし，ソフ

り，部品群に属する部品はそれぞれトウェアの規模が大きくなれば，その把握は困難となる．設計

C1 = {c1 , c01 },に関するドキュメントが存在すれば理解の助けになるが，ドC4 = {c4 },キュメントが巨大である，古い，そもそも存在しないなどの理由で参考に出来ない場合もある．

C2 = {c2 , c02 },C3 = {c3 },C5 = {c5 } である．

各部品群に対する評価値は，この部品群グラフを元に求められる．まず各頂点に対して，総和が 1 となるような重みを与え

このようなソフトウェアのクラス設計に関する情報は，ソフる．続いて，各頂点の重みをその頂点を始点とする有向辺に配トウェアの開発者ならば与えられなくても把握できている事が分する形で，各辺の重みを決定する．そして，各頂点の重みを，多い．しかし，ソフトウェアの開発者と保守者が異なる事は珍

その頂点を終点とする辺の重みの合計値として再定義する．以しく無く，このような場合は保守の作業に先駆けてソフトウェ

上を各頂点の重みが収束するまで繰り返した時の最終的な重みアの理解が必要となる．しかし，前述した理由により，クラス

が，対応する部品群に対する評価値: コンポーネントランク値

設計に関する理解は困難であると考えられる．

となる．

そこで，本研究では，コンポーネントランクを用いてソフ

ただし実際には以下のように求められる．W を各頂点の重トウェア中の重要部品を特定する事による，ソフトウェアのク

みのベクトル, 行列 D を配分率，すなわち各有向辺の重みのそラス設計に関する分析手法の提案を行う．また，実際のソフトの始点の重みに対する割合の行列とし，Dt は D の転置行列とウェアに対する適用実験を行い，その結果に関する考察を行う．

する．

以降，まず 2. 節でコンポーネントランクについて述べた上で，3. 節で提案する手法の詳細について述べる．4. 節ではソフ

W = Dt W(1)

トウェアの適用実験について述べる．5. 節では関連研究についこの W を求めることで，各頂点に対応する部品群の評価値て述べる．最後に，6. 節でまとめと今後の課題について述べる．

を計算することができる．式 (1) の性質より，Dt の固有値 1 の2. コンポーネントランク

固有ベクトルを求める事で W を求める事ができる．
以降，以上により求められた評価値をコンポーネントランク

2. 1 コンポーネントランク法による順位付け

値，コンポーネントランク値の高い順に部品を整列した際の順

一般にソフトウェア部品とは再利用出来るように設計された

位をコンポーネントランクと呼ぶ．

部品の事を指す [5]．ここではより一般的に，再利用の対象とコンポーネントランク値は，開発者が，開発者が利用関係になるソフトウェア資産の単位を指してソフトウェア部品，また沿って参照を行うと仮定した場合の各部品の参照されやすさを

は単に部品と呼ぶ．特に Java を対象とした場合については，

あらわしており，よく利用される部品や，重要な部品から利用

Java のクラスがソフトウェア部品となる．

される部品の順位が高くなる．

ソフトウェアは構成要素の部品間で相互に属性や振る舞いを

2. 2 SPARS-J

利用し合うことで一つの機能を提供する．いま，ある部品があSPARS-J は Java を対象としたソフトウェア部品検索システる部品を利用する時，この部品間に利用関係が存在すると言う．

ムであり，登録された部品に対してコンポーネントランク法を

部品を頂点，利用関係を有向辺としたグラフを部品グラフ

適用し，順位付けを行っている．SPARS-J は図 2 に示すようと呼ぶ．図 1(a) は部品グラフで，この場合，部品 c2 は c1 を，

c02 , c3 は c01 を，c1 は c4 を，c01 は c5 をそれぞれ利用していることを表している．

な構成となっている．
登録部 (Register) は与えられた Java ソースファイルをデータ
ベース (Database) へ部品として登録する．この時，Java ソー

実際の部品の集合には，全く同じ，もしくはほとんど同じ部

スファイルからの単語の切り出しや利用関係の解析などが行わ品が複数存在している事がある．これらは，ある部品がコピー，れる．コンポーネントランク計算部 (Ranker) はデータベース

もしくはコピー後一部を変更して再利用されているとみなす事に登録された部品全てに対し，利用関係に基づきコンポーネンができる．コンポーネントランク法ではこのような部品を類似

トランク値の計算を行い，結果をデータベースに登録する．検部品群としてまとめ，解析の単位としている．

索部 (Searcher) には，部品の検索や，表示を行う CGI，およ図 1(a) において，部品 c1 と c01 ，部品 c2 と c02 はそれぞれ類似した部品とする．このとき，図 1(b) が，部品群グラフとなび部品情報の一覧出力を行うコマンドが含まれ，データベースに登録された部品情報をユーザに提供する．

—2—

照しながら調査する．続いて閾値 (2) のクラスに関して，閾値

(1) 以上のクラスとの関連に注意しながら，役割や関連を調査する．さらに，閾値 (3) 以上のクラスに関しても同様に，コン
ポーネントランク上位のクラスとの関連に注意しながら，役割や関連を調査する．
この時，コンポーネントランクによる順位と，被参照数による順位を比較し，それらの差が大きいクラスについては何らかの設計的な要素が影響していると考えられるので注意して分析を行う．例えば，被参照数での順位と比較してコンポーネント
ランクで上位にあるクラスは，ソフトウェア中で重要な部分で利用されるクラスである事が考えられる．逆にコンポーネント
ランクによる順位の方が低いクラスについては，あまり重要な図 2 SPARS-J の構成

役割の無い，様々な所から呼び出されるユーティリティ的なクラスである事が考えられる．

3. 提 案 手 法

また，ソースコードからのリバースエンジニアリングにより，
閾値以上のクラスのみから構成されるクラス図を作成する．こ本研究では，2. 節で説明したコンポーネントランク法を利用

れにより，重要クラス間の関連を視覚的に確認でき，分析作業

し，クラス設計に関する分析を行う手法を提案する．コンポーがより容易になると考えられる．一般に，ソースコードから生

ネントランク法では，単純な被参照数，すなわち対象のクラス成したクラス図は，全てのクラスおよび関連を取得し表示してを利用しているクラスの総数を用いた評価と異なり，重要なクしまうために巨大で理解が困難になりがちである． しかし，こラスから利用されるクラスに対してより大きな値が与えられる．

こで生成されるクラス図は，コンポーネントランクにより重要

これより，単に多くのクラスから利用されるクラスだけではななクラスのみに絞られているために，小規模で理解しやすく，

く，ソフトウェア中で重要な意味を持つクラスや，重要な部位

かつ要点を押さえている事が期待できる．

から利用されるクラスを知る事が出来る．ソフトウェアのクラス設計の理解において，コンポーネントランクの上位クラスの4. 適 用 実 験

理解から開始する事により，全体の把握が容易になると考えら

本節では，提案手法の有用性を評価するために，実際のソフ

れる．

3. 1 手トウェアに対して適用を行う．そして，クラス設計に関する重順提案手法の手順を以下に示す．

要な情報が分析できるかどうかを評価する．
適用対象は，研究室内で開発されたソフトウェアおよび，あ（ 1 ） コンポーネントランク値の計算る企業で開発されたソフトウェアである．以下，それぞれにつ

解析対象のソースコードを用意し，SPARS-J への登録を行いて述べる．

いコンポーネントランク値を計算する．この際，利用している

4. 1 研究室内で開発されたソフトウェア

ライブラリの Jar アーカイブや，ビルドのためのクラスパス情

4. 1. 1 適 用 対 象

報などは必要無く，解析対象のソースコードのみが有れば良い．

適用実験はコードクローン分析ツール Aries [4] のクローン情（ 2 ） 重要クラスの特定

報表示部のソースコードに対して行った． 総クラス数は 283 ク

コンポーネントランク順に全てのクラスをソートし，閾値以ラス，総行数は 31,000 行である．

上の順位のクラスを重要クラスとする．閾値は以下の 3 段階でAries 全体ではなくデータ表示部のみを対象とした理由は以設定する．

下の通りである．Aries は大きく分けてクローン解析部とクロー閾値 (1) 上位 3〜10 クラス

ン情報表示部，およびそれらを統合的に扱う部分に分かれるが，

閾値 (2) 上位 10%

それぞれの間で依存関係は無く，独立している．これらを同時閾値 (3) 上位 20%に扱った場合，元々関連の薄いクラスを同時に分析する事にな

なお，この時のクラス数や割合は，総部品数およびコンポーネ

り，分析の煩雑さが増大するからである．また，これらの中でントランク値の分布に応じて増減させるべきだと考えられる．

データ表示部が最も大きい規模であったため，データ表示部にまた，この際に被参照数による順位も求めておく．

対する分析を行った．

（ 3 ） 重要クラスの分析

4. 1. 2 適用結果および考察

重要クラスに関して，役割や他クラスとの関連をソースコーa ) コンポーネントランク値の分布

ドの内容から調査する．まず，閾値 (1) 以上のクラスに関し

図 3 より，ごく一部のクラス，具体的には上位 5 クラス程度て，役割や，それらの間での関連を SPARS-J 検索部の部品表が特に高いコンポーネントランク値を持ち，以降はなだらかに

示機能・利用関係表示機能を用いて調査する．またメソッドやなっている．これより，閾値 (1) は 5 クラスに設定する．また，フィールドの意味について，可能ならば他のドキュメントも参閾値 (2),(3) に関しては，前節で示した値，すなわち上位 10%,—3—

フィールド名より，このクラスにはファイルに関する情報やクローングループに関する情報が含まれる事がわかる．また，6000000

Variable の各フィールドを引数とするメソッド addVariable()，Component Rank Value

5000000

Variable の配列を返値とするメソッド toArray() をもつことか
ら Variable の集合を内包することがわかる．また，CloneSet

4000000

が Fragment を持つ事より，CloneSet, Variable, Fragment の3000000

3 クラスは関連を持つことがわかる．

2000000

DeclarationUnit Java クラスの単位をあらわし，その位置1000000

情報やメトリクスを保持するデータクラスである.
0
1

12

23

34

45

56

67

78

89 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276Classes

PackageName パッケージ名，およびクラス名をあらわす
データクラス．被参照数では 44 位であり，重要な箇所で利用されることがわかる．

図 3 CR 値の分布

以上より，上位クラスはクローン分析時の重要な概念である
クローンセットや，その関連クラスをあらわすエンティティク

上位 20%に設定する．

ラスである事がわかった．これは，Aries がコードクローン分析b ) 重要クラス

ツールであり，特に，対象としている表示部は解析済みのデー閾 値 以 上 の 重 要 ク ラ ス を 表 1 に 示 す．こ こ で は 閾 値 (2)タを扱う，という事実と一致する．また，Variable については以上のもののみ示しており，閾値 (1) 以上のクラスについ直接コードクローンと関係ないが，Aries はコードクローンがては太字で示している．クラスの概要とは，ソースコード

リファクタリング可能であるかどうかの判断要素としてクロー

中のクラスのドキュメンテーションコメントを要約したもンの外部定義変数を用いている事から，重要クラスとして妥当ので，利用関係や内部構造については考慮していない．まであると考えられる．

た，パッケージ名はソフトウェア内で共通な部分についてはii ) 閾値 (2) 以上のクラスの分析

省略して記述している．例えば，パッケージ data.clone は，

図 4 より, CloneSet はサブクラス StatementCloneSet, Dec-

正 確 には jp.ac.osaka u.es.ics.sel.gesmcoc.data.clone であ り，larationCloneSet, ProcessCloneSet を持つ．それらの被利用ク

jp.ac.osaka u.es.ics.sel.gesmcoc. については省略している．

ラスのうち，閾値 (2) 以上のものをみると，例えば Statement-

また，クラス図の生成に関しては UML モデリングツール

CloneSet ならば， パッケージ gui.cloneset.statement.metrics

JUDE [6] を用い，ソースコードからクラス図へのリバースエの ク ラ ス MetricsGraph か ら 利 用 さ れ て い る ．Declara-

ンジニアリングを行った．閾値 (3) 以上のクラスでのクラス図

tionCloneSet についても同様に，パッケージ名のみが異なるの一部を図 4 に示す．

同名クラスから利用されている．これは，Aries ではクローン

図中で示される関連は，ラベルとして示される名前でフィー

セットは文単位・宣言単位・メソッド単位という単位別に扱わ

ルドが宣言されている事をあらわしている．ローカル変数の宣れ，それぞれ別のメトリクスグラフをもち，さらにそれぞれは言や，メソッドの引数および返り値で利用されている場合につ独立したクラスで実装されているという事実を反映している．

いては関連は引かれておらず，この図からは読み取る事はでき

CloneGroup クラスに注目する．このクラスは，互いに依存ない．また，閾値以上でも図中に無いクラスへの関連は非表示関係を持つクローンセットをあらわすエンティティクラスであとしてある．

り，概念として重要であるが，他のエンティティクラスと比較

c ) 重要クラスの分析

して順位が低い．これは，全体の中でクローングループを扱うi ) 閾値 (1) 以上のクラスの分析

機能の比重が低いという事をあらわしている．実際，クローン閾値 (1) 以上のクラスに関して，表 1 およびソースコードか

グループは最近実装され始めた機能である．

ら詳しく分析を行った結果は以下の通りである．

また，その他の GUI 部品クラスとして，ClassListViewPop-

CloneSet クローンセットを表現する抽象クラスであり，各upMenu, PackageTreePopupMenu, SourceCodePainView，

種のメトリクスをフィールドとして持つ．また，Fragment を引

MetricsGraph な ど が 挙 げ ら れ る ．こ れ ら よ り，Aries の 画数とするメソッド add()・Fragment の配列を返値とする toAr-

面を構成する要素を読み取る事ができる．ただし，直感的ray() メソッドをもつ事から，意味的に Fragment の集合を内には ClassListViewPopupMenu よりも，閾値 (2) 以下である

包する事がわかる．

ClassListView の方がより重要でありコンポーネントランクでVariable クローンの外部で定義される変数をあらわすクラの順位に反している．この点に関しては理解を妨げていると考スである．String 型, およびプリミティブ型のフィールドのみえられる．しかし，Aries においてはポップアップメニューが多を持つデータクラスである．被参照数では 17 位であるが，コ用されているという点を考えると大きな問題では無いと言える．

ンポーネントランクでは上位である事から，重要な部分で利用

その他に読み取れる点としては，ファイル関連の FileData

されている事が分かる．

などのクラスがあり，単なるデータ入出力では無くクローン

Fragment クローンのコード片をあらわすクラスである．

分析に利用されるファイルのことである点や，このソフトウェ

—4—

表1
CR 順位
1
2
3
4
5
6
7
7
9
10
10
10
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

パッケージ名data.clone
data.clone
data.clone
data.classes
data.classes
data.clone
gui.classes.list
gui.classes.tree
data.classes
gui.classes.source
gui.clonegroup.source
gui.cloneset.common.source
data.clone
data.ﬁledata.clone
gui.cloneset
gui.cloneset
gui.classes.tree
data.clone
data.ﬁledata.clone
gui.classes.list
data.clone
gui.cloneset.declaration.metrics.graphgui.cloneset.declaration.metrics.graphgui.cloneset.statement.metrics.graphdata.ﬁledata.clone閾値 (2) 以上のクラス群

クラス名
CloneSet
Variable
Fragment
DeclarationUnit
PackageName
CloneTypeClassListViewPopupMenu
PackageTreePopupMenu
DeclarationUnitData
SourceCodeUI$SourceCodePlainView
SourceCodeUI$SourceCodePlainView
SourceCodeUI$SourceCodePlainView
VariableData
FileData
StatementCloneSet
MetricsGraph
MetricsGraphPopupMenu
PackageTree
ProcessCloneSet
Element
DeclarationCloneSet
ClassListView
CloneSetData
MetricsGraph
MetricsGraphPopupMenu
MetricsGraph
Key
CloneGroup

被参照数での順位
4
17
1
6
44
3
17
17
23
96
96
96
96
2
5
7
9
9
7
23
9
12
17
16
22
17
96
23

クラスの概要クローンセット
クローンの外で宣言された変数
クローンセットに含まれるコード片
単体のクラスパッケージ名もしくはクラス名
クローンのタイプに関する定数定義
クラス一覧のポップアップメニュー
パッケージツリーのポップアップメニュー
単体のクラスの集合
ソースコード表示領域
同上
同上
Variable の集合
ファイルの集合
文単位でのクローンセット
メトリクスグラフ
メトリクスグラフのポップアップメニュー
パッケージツリー
メソッド単位でのクローンセット
ファイル
宣言単位でのクローンセット
クラス一覧の表示領域
クローンセットのデータ
メトリクスグラフ
メトリクスグラフのポップアップメニュー
メトリクスグラフ
Element を比較するキー
クローングループ

CloneSetData
CloneSet
StatementCloneSetData
ProcessCloneSet

StatementCloneSet- processCloneSet- selectedCloneSet- statementCloneSet- selectedCloneSet

DeclarationCloneSet- declarationCloneSet
ClassCloneSet- selectedCloneSet

CloneSetView- parentContainer

FragmentView

CloneSetView- parentContainer

FragmentView- statementCloneSetData- statementCloneSetData
MetricsGraphPopupMenu- metricsGraphPopupMenu

CloneSetView- parentContainer

ProcessCloneSetData- processCloneSetData- processCloneSetData
MetricsGraphPopupMenu- metricsGraphPopupMenu

DeclarationCloneSetData- declarationCloneSetData- declarationCloneSetData
MetricsGraphPopupMenu- metricsGraphPopupMenu- parentContainer

FragmentView

MetricsGraph- parentContainer
MetricsGraph- parentContainer
MetricsGraph- metricsGraph- fileData- fileData- fileData- fileData- fileData

FileData

ClassListView- parentContainer- classListViewPopupMenu

CloneType- parentContainer- fileData

MetricsView- fileData- metricsGraph- parentContainer

MetricsView

MetricsView

Fragment- declarationUnitData

ClassListViewPopupMenu- metricsGraph- parentContainer- variableData
VariableData

DeclarationUnitData

図 4 閾値 (3) 以上のクラス図の一部

アではエンティティクラスの集合を Collection などではなくび GUI 部品のクラスを特定し，その機能や関連を確認する事

DeclarationUnitData，VariableData，CloneSetData などのができた．また，この結果は，実際の Aries の設計と一致し，クラスを通して扱っている，という点が挙げられる.

本手法が有効である事を示している．

iii ) 閾値 (3) 以上のクラスの分析

4. 2 企業における適用実験

ソースコードおよびクラス図をもとに分析を行う．

4. 2. 1 適 用 対 象

CloneSetData は ，サ ブ ク ラ ス StatementCloneSetData,

対象としたソフトウェアはデータベース・ロジック・プレゼ

DeclarationCloneSetData, ProcessCloneSetData をもち，そンテーションの 3 層構造をもつ Web アプリケーションであり，れぞれ，StatementCloneSet, DeclarationCloneSet, Process-

規模は約 850 クラス,110,000 行である．それぞれのレイヤーを

CloneSet の集合をあらわすクラスで，MetricsGraph との関連担当するクラスおよび，エンティティクラスを含む共通クラスをもつことがわかる．

群や，レイヤー間のデータ受け渡しを行うパラメタクラスが存

ま た CloneSetView，SourceCodeUI，MetricsView，Flag-

mentView など，主要な GUI 部品が含まれる．このようなGUI 部品の関連は，クラス図により容易に確認できる．例えば，

在する．また，自動生成クラスも含まれている．なお，分析は閾値 (1) 以上のクラスに関する分析のみを行った．

4. 2. 2 適用結果および考察

CloneSetView は FragmentView の親コンテナであり，どちら閾値 (1) としては，上位 10 クラスとした．その内訳としても他の CloneSet の子クラスのいずれか (StatementCloneSet

は，エンティティクラスが 5 クラス, ユーティリティクラスがなど) を扱う事がわかる．

2 クラス，および自動生成のパラメタクラスが 3 クラスであっ

4. 1. 3 分析に関する考察

た．開発者への聞き取り調査により，これらのクラスがソフト以上の分析より，Aries の主要なエンティティクラス，およウェア中での重要クラスとして妥当である事が確認できた．

—5—しかし，レイヤー間の受け渡しは局所的な役割であり，閾値

(1) 以上に来る事は不自然であるとの見方もできる．このよう対する適用が必要であると考えられる．また，より規模の大きいソフトウェアに対しての適用も必要である．

なクラスが上位に順位付けされたのは，以下の 2 点が原因だと

謝辞 本研究は一部，文部科学省リーディングプロジェクト考えられる．まず 1 つめの理由としては，実際にその部位がシ「e-Society 基盤ソフトウェアの総合開発」の支援を受けている．

ステム中で大きな比重を占めている事である．実際に，関連するレイヤーであるデータベース層・ロジック層は，あわせて全体の半分以上である 480 クラスをもっている．もう 1 つの理由として，JSP ファイルの登録を行わなかった為に，利用関係が不完全であった事が考えられる．JSP ファイルから Java ファ
イルへの変換は対象ソフトウェアの実行環境に依存し，今回の実験では行わなかったが，出来る限り変換を行い登録する事が望ましいと考えられる．

5. 関 連 研 究
クラス設計の分析手法として，ソフトウェア中のクラスをライブラリとしてのクラスとアプリケーションとしてのクラスに分類する手法 [1] が提案されている．この手法は，汎化-特化構
造の指標 (HF)，全体-一部構造の指標 (RF)，ポリモルフィズ
ムの指標 (PF) の 3 つの指標を定義し，これらを組み合わせる
事でクラスの分類を行っている．
コンポーネントランクの応用として，版管理されている部品の各リビジョンにおけるコンポーネントランク値を求め，その変遷よりソフトウェア開発の状況を推測する手法 [9] が提案されている．また，再利用を目的とした，コンポーネントランクを用いた理解支援手法 [7] も提案されている．この手法では，まずメソッドをひとつ決定し，そのメソッドに依存するメソッド
を分析する．それらのメソッド内でコンポーネントランクの計算・およびメソッドごとのサイクロマチック数の計算を行い，最初のメソッドの理解に重要なメソッドを示す事で，再利用時の理解支援に役立てている．

文

献[1] 青木 淳: ” オブジェクト指向システム分析設計入門”, ソフトリ
サーチセンター, 1992.
[2] Katsuro Inoue, Reishi Yokomori, Hikaru Fujiwara, Tetsuo
Yamamoto, Makoto Matsushita, Shinji Kusumoto: ”Component Rank: Relative Signiﬁcance Rank for Software Component Search”, Proceedings of the 25th International Conference on Software Engineering (ICSE2003), pp14-24, Portland, Oregon, U.S.A., 2003.
[3] Katsuro Inoue, Reishi Yokomori, Tetsuo Yamamoto,
Makoto Matsushita, Shinji Kusumoto: ”Ranking Signiﬁcance of Software Components Based on Use Relations”,
IEEE Transactions on Software Engineering, Vol.31, No.3,
pp.213-225, 2005.
[4] 肥後 芳樹, 神谷 年洋, 楠本 真二, 井上 克郎: ” コードクローンを対象としたリファクタリング支援環境”, 電子情報通信学会論
文誌 D-1, Vol.J88-D-I, No.2, pp.186-195, 2005.
[5] I. Jacobson, M. Griss and P. Jonsson: ”Software Reuse”,
Addison Wesley, 1997.
[6] ”JUDE”, http://jude.esm.jp/[7] 小堀 一雄, 山本 哲男, 松下 誠, 井上 克郎: ” メソッド間の依存関係を利用した再利用支援システムの実装”, 電子情報通信学会
技術研究報告, SS2004-58, pp.13-18, Vol.104, No.722, 2005.
[8] J. Schmuller: ”Teach Yourself UML in 24 Hours”, Sams
publishing, 1999.
[9] 横森 励士, 市井 誠, 井上 克郎: ” コンポーネントランクを用いた開発プロセス評価手法の有効性について”, 情報処理学会研究報告, 2005-SE-149, 2005. (掲載予定)[10] 横森 励士, 梅森 文彰, 西 秀雄, 山本 哲男, 松下 誠, 楠本 真二, 井
上 克郎: ”Java ソフトウェア部品検索システム SPARS-J”, 電
子情報通信学会論文誌 D-I, Vol.J87-D-I, No.12, pp.1060-1068,
2004.
[11] 横森 励士, 藤原 晃, 山本 哲男, 松下 誠, 楠本 真二, 井上 克郎: ”
利用実績に基づくソフトウェア部品重要度評価システム”, 電子情報通信学会論文誌 D-I, Vol.J86-D-I, No.9, pp.671-681, 2003.

6. ま と め
本研究では，コンポーネントランク値を用いてソフトウェアのクラス設計を分析する手法を提案した．また，実際のソフトウェアに対する適用実験を行い，提案手法はソフトウェアをクラス設計の面から理解する事に有効である事が分かった．
今後の課題としては，適切な閾値の決定が挙げられる．今回
はクラス数とコンポーネントランク値の分布から閾値を決定し，良好な結果が得られたが，全ての場合に適用できるかどうかは分からないため，適切な閾値の決定方法の確立が今後の課題となっている．
また，本研究ではクラス図の生成に一般の UML ツールを利用したが，閾値以上のクラスを人間が選択し，図に加えていく，という作業が必要であった．また，全ての関連が表示できていないという問題があった．これらより，分析に必要な情報を備えたクラス図を自動生成する事が望ましいと考えられる．
最後に，より多くの適用実験が挙げられる．本研究では表示に重点が置かれた GUI ソフトウェアに対して適用を行ったが，処理に重点が置かれたソフトウェアや，大量のエンティティク
ラスを扱うソフトウェアなど，異なった設計のソフトウェアに—6—