2025年5月17日
今週の活動
得られた成果
- ソフトウェアの複雑さの分類に基づいてこの研究で扱う領域を明確化
- A survey on metric of software complexityでは、Brooksが唱えたソフトウェアの複雑さの分類を拡張し、3つの分類を示している
- 本質的複雑さ
- ソフトウェアが解決しようとする問題によるもの
- 実質的には仕様に依存する複雑さ
- 選択的複雑さ
- プログラミング言語、問題のモデリング手法、ソフトウェア設計手法によるもの
- 偶発的複雑さ
- この研究で扱う「保守性」は実装後のリファクタリングによって軽減されるもの
- つまり、この研究は偶発的複雑さを管理・軽減する手法の提案が目的であると考えられる
- ソフトウェアメトリクスを併用することの重要性
- コードの行数、Halsteadの複雑さの尺度、循環的複雑度などのメトリクスは併用することで相乗効果を得られることが示されている
- コードの行数: モジュール分割の適切さを量的に測る
- 凝集度や結合度: モジュール分割の適切さを質的に測る
- Halsteadの複雑さの尺度: データフローの複雑さを測る
- 循環的複雑度: 制御フローの複雑さを測る
直面した課題
- メトリクスによっては計算式の定義が複数あり、精度が定義ごとに異なる
- 例: Halsteadのメトリクスにおける「バグの推定数\(B\)」
- 今回は単一のメトリクスのみを使用する訳ではないため、実験前にどちらの定義を使用するかを決めておけば問題ないと思われる
- 最適な値がプログラミング言語に依存するメトリクスがある
- 例1: 抽象度
- HaskellやScalaなどの関数型言語では高い抽象化が推奨されるが、CやJavaなどの手続き型言語では抽象化によってコードが冗長になりやすい
- 例2: 継承の深さ
- 単一継承ではメソッドの起源を辿るのは比較的簡単であるが、多重継承では、1つのメソッドの変更が複数の継承パスに影響するため、単一継承に比べて継承関係の把握が難しい
- 言語依存のメトリクスを使用する場合は、基準値を設定した上で、言語特性を考慮して基準値に重み付けをすることもできる
来週の計画
- リファクタリング 既存のコードを安全に改善するの第5章、第6章を読む
- Qualitas Corpusのeリリース（10以上のバージョンがあるシステム）を使用してソフトウェアメトリクス（コードの行数、Halsteadの複雑さの尺度、循環的複雑度）の変化を計測
- 少なくとも1つの異常検出アルゴリズムを実装し、メトリクスと組み合わせる
- 凝集度と結合度についての研究を調べる
- 保守性低下の兆候のうち、どれを採用でき、どれを採用できないのかを可視化する