コンポーネントランク法を用いたJavaクラス分類手法の提案 コンピュータサイエンス専攻 井上研究室 博士前期課程2年 中塚 剛

ソフトウェア・クラスタリング ソフトウェア理解が必要になる場面 ⇒ソフトウェア・クラスタリング ソフトウェア保守 ソフトウェア部品の再利用 システム内の各モジュール（クラス・ファイル）を分類して，サブシステムへ分解 システム構造に注目 依存関係が密な部分をまとめる[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] 従来の遍在モジュール特定法 多くのモジュールと依存関係のあるモジュール いわゆるライブラリ・ユーティリティなど 特定のサブシステムに入れたくない 全てのサブシステムに入れたい→「遍在」 クラスタリング対象から外す必要がある 従来の遍在モジュール特定法 次数がある閾値より高いもの 単純すぎる 十分な考察が行われていない 遍在モジュール [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が高い部品は遍在モジュールの候補ではないか

研究の目的 従来のソフトウェア・クラスタリング・アルゴリズムの解を改良するための，コンポーネントランク法を利用した遍在モジュール特定手法の提案 クラスタリング・アルゴリズムはBunchの実装を利用 新たな遍在モジュール特定手法を利用したソフトウェア・クラスタリング手法を提案

ソフトウェア・クラスタリング・システム Bunch 高凝集・低結合に基づくソフトウェア・クラスタリングを実装したシステム[1] 最適なクラスタリング結果を探す探索問題として実装 目的関数を定義して，目的関数値が最も高い結果を探す クラスタリング結果の数はO(n!) (n:頂点数) →NP困難 局所探索法である山登り法（hill climbing）を用いて近似解を求める 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) クラスタに関連する辺のうち，クラスタ内に存在する辺の割合 CFの式の説明はしない．簡単な説明で済ます．

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

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

実験の概要 実験1 実験2 クラスタリング結果の見易さ・理解し易さをメトリクスによって評価 後述 クラスタリング結果の実際の構造に対する評価 適当と思われる解（ベンチマーク）を作成して比較 割愛

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

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

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

クラスタリング結果の例 GNUJpdf（25モジュール）に適用した例 Bunchオリジナル 提案手法

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