コンポーネントランク法を用いた Java クラス分類手法の提案

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

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

3. ソフトウェア・クラスタリングの問題点 • 遍在モジュール（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.

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

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

6. ソフトウェア・クラスタリング・システム 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

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

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

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

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

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

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

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

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

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