ソフトウェア部品分類手法への コンポーネントランク法の応用 大阪大学　大学院情報科学研究科 中塚 剛 松下 誠 井上 克郎

ソフトウェアクラスタリング ソフトウェア理解が必要になる場面 ⇒ソフトウェアクラスタリング ソフトウェア保守 ソフトウェア部品の再利用 システム内の各モジュール（クラス・ファイル）を分類して，サブシステムへ分解 システム構造に注目 依存関係が密な部分をまとめる[1] サブシステムが高凝集・低結合になるように⇒サブシステムごとに理解しやすい 依存関係グラフ モジュール 依存関係 ソフトウェア理解の必要性→ソフトウェア・クラスタリング サブシステム （クラスタ） [1] B. S. Mitchell and S. Mancoridis: “On the Automatic Modularization of Software Systems Using the Bunch Tool”, IEEE Transaction on Software Engineering, vol. 32, no. 3, pp. 193-208, 2006

ソフトウェアクラスタリングの問題点 遍在モジュール（omnipresent module）[2] 従来の遍在モジュール特定法 多くのモジュールと依存関係のあるモジュール いわゆるライブラリ・ユーティリティ java.awt.Componentなどの抽象クラス クラスタリング対象から除去する必要がある 特定のサブシステムだけで使われているわけではない サブシステムが巨大化する可能性がある 従来の遍在モジュール特定法 次数がある閾値より高いもの 単純すぎる 十分な考察が行われていない 遍在モジュール [2] H. A. Müller et al.: “A Reverse Engineering Approach To Subsystem Structure Identification”, Journal of Software Maintenance: Research and Practice, Vol. 5, No. 4, pp. 181–204, 1993.

コンポーネントランク法 Javaソフトウェア部品検索システムSPARS-Jで使用 ソフトウェア部品再利用のために，過去に作成されたクラス・インターフェースを検索 検索結果のランク付けに使われる 相互利用関係に基づいて部品の重要度を表すコンポーネントランク値（CRV）を測定 多くの部品に利用されている部品は重要 重要な部品に利用されている部品は重要 CRV=0.4 a 0.2 0.2 c CRV=0.2 0.2 0.4 b CRV=0.4 CRVが高い部品は遍在モジュールの候補ではないか

研究の目的 コンポーネントランク法を利用した新たな遍在モジュール特定手法の提案 遍在モジュールを適切に特定することによって，従来のソフトウェアクラスタリング手法の解を改良 ソフトウェアクラスタリングシステムとしてBunchを使用 実験によって，適切な遍在モジュールを特定できているか調査

ソフトウェアクラスタリングシステム Bunch 高凝集・低結合に基づくソフトウェアクラスタリングを実装したシステム[1] 最適なクラスタリング結果を探す探索問題として実装 目的関数を定義して，目的関数値が最も高い結果を探す 局所探索法である山登り法（hill climbing）を用いて近似解を求める クラスタリング結果の数はO(n!) (n:頂点数) →NP困難 4種類の遍在モジュールを定義 supplier: 入次数が平均次数の3倍以上 client: 出次数が平均次数の3倍以上 central: supplierかつclient library: 出次数が0 APIを公開 [1] B. S. Mitchell and S. Mancoridis: “On the Automatic Modularization of Software Systems Using the Bunch Tool”, IEEE Transaction on Software Engineering, vol. 32, no. 3, pp. 193-208, 2006

Bunchの目的関数MQ 凝集度と結合度のトレードオフを関数化 各クラスタでのトレードオフ： CF (Cluster Factor) あるクラスタ i において （1≦ i ≦k） （k:クラスタ数） 　 : クラスタ i 内の辺の数 : クラスタ i からクラスタ j への辺の数 CFの合計値：MQ (Modularization Quality) クラスタに関連する辺のうち，クラスタ内に存在する辺の割合

Bunch APIを用いたクラスタリング・システム ソースコードファイル ------------ ----------- ソースコードを分析 依存関係グラフを作成 モジュール・依存関係の定義はAnalyzerに依存 改良 出力 依存関係グラフ Bunch API Analyzer 改良 ・依存関係グラフを受け取る ・遍在モジュールを受け取る ・アルゴリズム中のパラメータの決定 ⇒解の出力 Omnipresent Modules Detector 遍在モジュール ・遍在モジュールを決定 どのように遍在モジュールを特定すればよいか　⇒実験によって決定

遍在モジュール特定手法決定のための実験 2種類の実験によって比較 遍在モジュール特定条件を40個作成 Bunchオリジナル条件 遍在モジュールを考慮しないもの Bunchオリジナル条件での閾値を2, 2.5, 3.5に変えたもの library（Bunchにおいて非常に多い）を考慮しないもの CRVを使用したもの supplier client central library 入次数 出次数 平均3倍以上 2種類の実験によって比較 ・CRVは平均以上で固定 （CRV平均以上のモジュールは全モジュールの約20%） ・入次数条件を厳しくしていくことで，supplierを減らしていく supplier 入次数 CRV 平均以上 平均1.5倍以上 平均2倍以上 平均2.5倍以上 平均3倍以上 library 入次数 出次数 CRV 平均以上 ・supplierとclientの条件両方満たしているもの ・オリジナル条件にCRVを足したもの オリジナル条件 libraryを減らすために library無し 入次数・CRV条件を追加 client 出次数 平均3倍以上 central 入次数 出次数 CRV supplierかつclient 平均3倍以上 平均以上 CRVは使えないのでオリジナル条件で固定 × × ×

実験における依存関係グラフの定義 モジュール：クラス，インターフェース 依存関係：インスタンス参照，メンバ参照，継承，インターフェース実装 内部クラスも1つのモジュールとする 依存関係：インスタンス参照，メンバ参照，継承，インターフェース実装 重み付けは行わない CRV測定も同様の依存関係グラフ上で行う

実験1：方針 クラスタリング結果の理解しやすさを評価 平均CF値が高く，遍在モジュール数が少ない（多すぎない）条件が優れている 平均CF値：全てのクラスタのCFの平均値 CF：各クラスタにおいての，凝集度と結合度のトレードオフ 平均CF値が高ければ，クラスタ間に辺が少なくなり，結果が見やすくなる 遍在モジュール数 遍在モジュール数が多いほど，平均CF値が上がりやすくなる 遍在モジュールはサブシステムに属さないため理解しにくい 従来手法では若干多すぎる（約40%） library（出次数0のモジュール）が多すぎる

実験1：結果と考察 Javaで書かれたオープン・ソース・システム15個での平均値 CRVを使うと，クラスタリング対象モジュール数，平均CF値共に改善している条件が存在 supplierの条件を厳しくしていくにつれて，クラスタリング対象モジュール数が増加，平均CF値は減少 ただし，調和平均値が改善されている Javaで書かれたオープン・ソース・システム15個での平均値 遍在モジュールが減ったが平均CF値が悪化している （トレードオフの関係） クラスタリング対象モジュール数と平均CF値のどちらを優先するか ⇒クラスタリング対象モジュール数を優先 理由：遍在モジュールとして除去されるより，少し見づらくてもクラスタに分類されたほうが理解しやすい Bunchオリジナル条件 C27～C29が良い supplier client central library 入次数 出次数 平均3倍以上 supplier client central library 入次数 出次数 平均3.5倍以上 supplier client central library 条件 入次数 CRV 出次数 C27 平均2倍以上 平均以上 平均3倍以上 supplierかつclient C28 C29 遍在モジュールに特定されなかったモジュールの割合 supplier条件 CRV無し CRV:1 CRV:1, in:1 CRV:1, in:1.5 CRV:1, in:2 CRV:1, in:2.5 CRV:1, in:3

実験2：方針 クラスタリング結果の中身の評価 ベンチマーク（適当と思われる解）を作成 どのくらい一致しているかを測定 2つの分割されたグラフの類似度を計る2種類のメトリクス EdgeSim (Edge Similarity) 辺の類似度を測定 MeCl (Merge Clusters) 一方のグラフを分割・マージすることで他方に一致させるためのコストを測定 共にパーセント尺度で，数値が高いほど類似度が高い 遍在モジュールを考慮できないため，問題あり 目視評価

実験2：結果と考察（1/3） GNUJpdf（25モジュール）でベンチマークを作成 EdgeSim, MeClが遍在モジュールを考慮できないため，評価が正しくない （実際の結果はベンチマークとほど遠い） Bunchオリジナル条件 類似度が非常に高くなっている Bunch APIにバグが存在 （遍在モジュールの選び方によってあるモジュールが結果に現れなくなる） ⇒結果を改変して測定 相関係数：0.88 CRV:1 CRV:1, in:1 CRV:1, in:1.5 CRV:1, in:2 CRV:1, in:2.5 CRV:1, in:3 実験1で良い結果

実験2：結果と考察（2/3） libraryが非常に多い クラスタ間の辺が多い ベンチマーク PDFPageの種類が違うだけ C29 PDFPage$procsetが存在しない libraryが非常に多い PDFPageの種類が違うだけ クラスタ間の辺が多い C27，C28 ベンチマークと一致 C1(Bunchオリジナル)

実験2：結果と考察（3/3） Bunch APIのバグが明らかに ⇒C28, C29はこのバグを起こし得る 遍在モジュールの選び方によって，特定のモジュールが結果に現れなくなる centralの条件が「supplierかつclient」になっていない場合のみ起こり得る ⇒C28, C29はこのバグを起こし得る supplier client central library 条件 入次数 CRV 出次数 C27 平均2倍以上 平均以上 平均3倍以上 supplierかつclient C28 C29 C27 平均2倍以上 平均以上 平均3倍以上 supplierかつclient

実験のまとめ CRVを利用すると，従来手法より良い結果を得られる 実験1，実験2を通して評価が良かった条件：C27 supplier: 入次数が平均次数の2倍以上，CRV平均以上 client: 出次数が平均次数の3倍以上 central: supplierかつclient library: 出次数が0，入次数平均以上，CRV平均以上

まとめと今後の課題 コンポーネントランク法を用いて遍在モジュールを特定することによって，より優れたクラスタリング・システムを構築可能 遍在モジュールが多すぎず，高凝集・低結合 今後の課題 さらなる条件の追加（CRVを変動させる） 遍在モジュールを考慮した距離測定メトリクスの提案 より大規模なシステムでのベンチマーク評価