Using Cohesion and Coupling for Software Remodularization: Is It Enough?
アブストラクト
- ソフトウェアの再モジュール化を行う際に開発者を支援する様々な方法が提案されている
- これらの方法のほとんどは、開発者がシステムのクラスをモジュール化する際に、凝集度と結合度の最適なバランスを追求するという前提に基づいている
- しかし、そのようなバランスが開発者にとって望ましいものであるという経験的証拠はまだない
- この論文では、この現象を客観的・主観的に分析することを目的とする
- 100のオープンソースシステムについて、パッケージの凝集度と結合度の観点からモジュール化の品質を分析
- 29人の開発者を対象に、モジュール化の作業を実施する際の考慮事項を理解することを目的とした調査を実施
はじめに
- ソフトウェアシステムは、新たな要件を満たすため、不具合を修正するため、あるいは品質を最適化するために少しずつ変更される
- このような変更は、以前に実装された要件や決められた設計と衝突することがある
- そのため、ソフトウェアに継続的な変更を加えると、システムが無秩序になっていく傾向がある
- この傾向があるシステムは、凝集度が低く、結合度が高いという特徴がある
- 開発者はこの問題を解決するために、リファクタリングによる再モジュール化を行い、ソフトウェアシステムを修復する必要がある
- 再モジュール化は、手動で実施するには非常にコストがかかることがある
- そのため、再モジュール化を支援するための様々な方法が提案されている
- これらの方法の背後にある考え方
- 凝集度の高いソースコードをモジュールにグループ化すること
- モジュール間の結合を減らすこと
- しかし、凝集度と結合度は対照的な目標である
- そのため、モジュール化を行う既存の手法は、いずれも凝集度と結合度のバランスをとり、ソースコードを分割する
- この論文では、ソフトウェア・システムのモジュール化において凝集度と結合度が果たす役割を客観的・主観的に調査することを目的とした2つの研究を実施
- 研究1: 100のJavaオープンソースシステムで実施された大規模な実証研究
- 研究2: 研究1で利用された100のシステムにコントリビュートしている29人の開発者を対象に実施された調査
- 調査から示唆されること
- 研究1: オープンソースシステムのモジュール化は、一般に、構造的および概念的凝集度・結合度の両方に関して、最適なモジュール化からは程遠い
- 研究2: 調査した開発者の83%が、凝集度と結合度以外の他の特性がシステムのモジュール化を導くと主張している
背景
ソフトウェアのモジュール化
- モジュール化を可視化するためにモジュール依存性グラフ（MDG）やモジュール品質メトリック（Modularization Quality, MQ）が存在
- 遺伝的アルゴリズムを使うことで、MQの値を最大化するために、2つのソフトウェアコンポーネントを同じパッケージに配置する必要があるかどうかを自動的に評価できる
- この論文では、構造情報とテキスト情報を利用して、対象システムの元の設計の最適性を、凝集度と結合度の観点から評価
遺伝的アルゴリズム
- 遺伝的アルゴリズムは、最適化問題を近似的に解くために種の進化をシミュレートする進化的アルゴリズムの一種
- 進化的アルゴリズムは、与えられた問題に対する解を表す固体の集団を反復的に生成し、調査中の問題に対する最適値の最良近似を与える解を探索
- 適応度関数を用いて個体によって表される解の良さを評価し、選択と繁殖に基づく遺伝的演算子を用いて新しい集団を生成
研究1: ソフトウェアリポジトリマイニング
- 目的
- オープンソースシステムのモジュール化の品質を客観的に分析すること
- 開発者が構造的および概念的な凝集度・結合度の観点から最適なモジュール化を定義する際に注意を払うかどうかを調査
研究デザイン
- RQ1
- オープンソースプロジェクトのモジュール化は、凝集度と結合度の観点からどの程度離れているのか？
- RQ2
- オープンソース開発者は、モジュール化を定義する際に、凝集度と結合度の間の適切な妥協点を探しているか？
- MoJoFM（MoJo eFfectiveness Measure）を利用して、準最適な概念的凝集度・結合度や構造的凝集度・結合度に対する実際の値の差を求め、RQ1に答える
- MoJoFMは類似度を表すため、MoJoFMが大きいほど、一方を他方に変換するために必要な労力が小さい
- \(MoJoFM = 100 - (実際の変換コスト/最大変換コスト × 100)\)
結果の分析
- RQ1
- オープンソースシステムのモジュール化は、構造的および概念的凝集度・結合度の観点から、最適とは程遠い
- 構造的メトリクス（構造的凝集度・結合度）を最適化することを考えたとき、準最適なモジュール化と実際のモジュール化の間のMoJoFMの中央値は13.3であるため、理想的なモジュールの構造からおよそ87%異なっている
- 概念的メトリクス（概念的凝集度・結合度）を最適化することを考えたとき、準最適なモジュール化と実際のモジュール化の間のMoJoFMの中央値は16.2であるため、理想的なモジュールの構造からおよそ84%異なっている
- RQ2
- 100の対象システムのうち、57%が凝集度、9%が結合度、34%が凝集度と結合度の両方の点で近似値よりも劣っている
- したがって、一般に、オープンソース開発者は、システムのモジュール化を定義する際に、構造的結合度よりも構造的凝集度を優先する傾向がある
- これは、ソフトウェアのソースコードがレイヤーごとに整理されることが多く、ソースコードを集約しにくいためであると考えられる
研究2: ソフトウェア開発者の調査
- 目的
- 開発者がソフトウェアの再モジュール化にどれだけ頻繁に対処しているかを理解すること
- 開発者がシステムのクラスをモジュール化する際に考慮することを理解すること
研究デザイン
- RQ3
- オープンソース開発者向けの高品質なモジュール化の特性は何か？
- 29人のオープンソースシステムのコントリビューターにアンケート調査を行った
結果の分析
- 回答者の75%がモジュール化の品質は重要である、または非常に重要であると考えている
- 回答者の86%がシステムの再モジュール化を目的としたリファクタリングを実施したことがある
- しかし、リファクタリングによる再モジュール化の作業中にツールによる支援を受けた開発者は52%である
妥当性への脅威
- 構成概念妥当性への脅威
- パッケージの凝集度・結合度の不正確さ
- ソフトウェアの特性のうち、凝集度・結合度に焦点を当てていること
- 重み付けされていないMDGを使用したこと
- 遺伝的アルゴリズムによる近似解の算出
- 内的妥当性への脅威
- 開発者が1つの属性のみに基づいてシステムを再モジュール化するとは限らないこと
- 結論妥当性への脅威
- 研究2のアンケート調査の回答率が11%であったこと
- 外的妥当性への脅威
- 研究1ではMavenリポジトリでホストされている最も一般的な1,000システムの中から、対象システムをランダムに選択した
- そのため、研究1の結果は、特定のアーキテクチャを利用するシステムや、他の言語で書かれたシステムには一般化できない可能性がある
結論
- 開発者の視点から意味のある再モジュール化方法を提案するには、凝集度と結合度だけではおそらく不十分である
- 分析されたシステムのうち、大多数のものは、その凝集度と結合度が理想的な値から離れていた
- 調査した開発者の83%は凝集度と結合度以外の特性がシステムのモジュール化を進めると回答した
- モジュール化を提案する際には、リファクタリングの労力を明示的に考慮する必要がある
引用情報
- 著者: Ivan Candela, Gabriele Bavota, Barbara Russo, Rocco Oliveto
- タイトル: Using Cohesion and Coupling for Software Remodularization: Is It Enough?
- 雑誌 / 会議名: ACM Transactions on Software Engineering and Methodology (TOSEM)
- 巻号: vol. 25
- 出版日: June 2016
- DOI: https://doi.org/10.1145/2928268