2025年6月7日
今週の活動
- メソッド・クラス単位でソフトウェアメトリクスを計算するライブラリを調査・選定
- 条件
- Javaなどの主要な言語をサポートしていること
- 複数のソフトウェアメトリクスを測定できること
- オープンソースであること
- 候補
- SonarQube
- https://github.com/SonarSource/sonarqube
- 利点
- 30以上の言語をサポートしている
- 循環的複雑度、LOC、重複コードを算出できる
- ルールを拡張できる
- 欠点
- 大規模プロジェクトでは解析時間が長い
- 不要な検出ルールをオプトアウトする必要があり、測定結果のフィルタリングが難しい
- 言語ごとに利用できるルールが異なっており、例えばJavaでは利用できるがC#では利用できないルールがある
- PMD
- scc
- lizard
- rust-code-analysis
- Qualitas Corpusデータセットに代わる、メトリクスとバグの関連性が明確なデータセットを調査
- Qualitas Corpusデータセットの問題点
- クラスやメソッドごとにメトリクスが測定されていない
- リリースごとにソースコードが存在するため、仮にメトリクス値を計算しても、その変化を比較する際の粒度が大きすぎる
- コードスメルのような潜在的な問題の検出に焦点を当てており、保守性低下の要因をコードの改善方法と関連付けるのが難しい
- BugHunterデータセット
- 4月から5月までの進捗をまとめる
- 当初の目標
- 達成したこと
- 既存の静的解析ツールでソースコードの保守性が固定的に評価されていることやその固定値を確認した
- 保守性の評価のために使用されている主要なメトリクスを整理した
- ソフトウェアメトリクスとバグ密度の分布関係を理解した
- リファクタリングにおけるコードスメルの役割とソフトウェアメトリクスとの関係を理解した
- 例: 長いパラメーターリストがメソッドの複雑度を上昇させる、神クラスがクラスサイズを増加させる
- 初期分析としてBugHunterデータセットを使用し、続いてASFのプロジェクトを分析する計画を立てた
- 達成できなかったこと
- データ収集手順の詳細化
- ASFのプロジェクトにおけるリポジトリの選定基準
- コミットごとにメトリクスを測定する方法の策定
得られた成果
- 5つの主要なメトリクス測定ライブラリを比較し、利点と欠点を整理した
- メトリクスを測定するためには各言語のパーサーを実装する必要があるため、基本的にはライブラリがサポートする言語の数が多いほど測定できるメトリクスの種類が少ない
- プロジェクトの分析を行う際は言語をJavaなどの主要なものに統一した方がいい
直面した課題
- コードスメルと保守性に関するメトリクスを関連付けるのが難しい
- メトリクス値とバグ密度は相関があることが先行研究で分かっている
- 一方で、コードスメルに関してはその一部がメトリクス値と相関があると思われるが、全てがメトリクス値と関係しているとは言えない
- 例えば、ネストや多重switch文は循環的複雑度やNPath複雑度と相関があるが、マジックナンバーやデッドコードは意味論的な問題であるため、メトリクスとの相関が低い
- 作業の順番を変え、初めにメトリクス値からバグの有無を推測し、次にバグの原因になったコードスメルを分析するのが良いのではないか？
来週の計画
- BugHunterデータセットの分析手法のベースラインを決める
- 先行研究で使用された分析手法の課題を整理し、それを解消する方法を考える