コンテンツにスキップ

Software complexity analysis using halstead metrics

アブストラクト

  • ソフトウェアの複雑さは内部のつながりに影響を与える
  • 測定を行わなければ、プログラムの複雑さを見つけるのは困難
  • ハルステッドの複雑さの尺度は、モジュール内のオペランド（演算子に作用する値）と演算子から複雑さの尺度を決めるためのメトリクス
  • 2つの異なる言語で作成されたプログラム間の相関関係から、両方の不確実性、時間、労力を比較し、どちらのプログラミング言語がより実行時間が短く、労力が最小であるかを判断

はじめに

  • ハルステッドの複雑さの尺度は、テスト時間、エラー、複雑さ、そして演算子やオペランドを用いてソフトウェアを実行するのにかかる労力を計算

Halsteadのメトリクス

  • 複雑さはプログラム全体から定義される必要がある
  • コードの行数が少ないプログラムが、コードの行数が多いプログラムよりも複雑さが少ないとは言えない
    • 複雑さは、プログラムの長さだけを考えるだけでは解決できない
    • なぜなら、1行に複数のソースコードを記述することで、プログラムを短くできるから
  • Halsteadの複雑さの尺度では、各行の演算子やオペランドなどを調べることで複雑さを測定できる
  • プログラム全体の複雑さを測るための基本的な要素
    • \(\text{n}_{1}\) = 独立した演算子の数
    • \(\text{n}_{2}\) = 独立した被演算子の数
    • \(\text{N}_{1}\) = 全ての演算子の数
    • \(\text{N}_{2}\) = 全ての被演算子の数
  • プログラム全体の複雑さを測るための指標
    • プログラムの長さ
      • \(\begin{equation*} \text{N}=\text{N}_{1}+\text{N}_{2} \end{equation*}\)
    • プログラムの語彙
      • \(\begin{equation*} \text{n}=\text{n}_{1}+\text{n}_{2} \end{equation*}\)
    • プログラムの体積
      • プログラムの情報量
      • 語彙が多いプログラムほど、各要素を区別するために多くのビットが必要になる
      • \(\begin{align*} &\text{V}=(\text{N}_{1}+\text{N}_{2})\ \log_{2}(\text{n}_{1}+\text{n}_{2})\\ &\text{V}=\text{N}\ \log_{2}(\text{n}) \end{align*}\)
    • プログラムの難易度
      • プログラムの理解や修正の難しさ
      • 被演算子の種類が少なく、繰り返し使用される場合や、演算子の種類が多く複雑な場合に難易度が高くなる
      • \(\begin{equation*} \text{D}=(\text{n}_{1}/2)^{\ast}(\text{N}_{2}/\text{n}_{2}) \end{equation*}\)
    • プログラムの潜在的あるいは最小の体積
      • 同じ機能を実装する最も簡潔なプログラムの体積
      • 体積の理論上の最小値
      • \(\begin{equation*} \text{V}^{\ast}=(2+\text{n}_{2})\ \log_{2}(2+\text{n}_{2}) \end{equation*}\)
    • プログラムの実装レベル
      • 実際のプログラムが理想的な実装にどれだけ近いかを表す
      • 値が1に近いほど理想的な実装に近いことを意味する
      • \(\begin{equation*} \text{L}=\text{V}^{\ast}/\text{V} \end{equation*}\)
    • プログラムのレベル
      • プログラムの抽象度
      • 値が大きいほど高レベルの実装であることを意味する
      • \(\begin{equation*} \text{L}^{\prime}=(2/\text{n}_{1})^{\ast}(\text{n}_{2}/\text{N}_{2}) \end{equation*}\)
    • プログラムの知的な内容
      • プログラムの抽象度とその情報量の積
      • プログラムに含まれる情報の質
      • \(\begin{equation*} \text{I}=\text{L}^{\prime} \text{V} \end{equation*}\)
    • プログラムの実装や理解に必要な労力
      • 難易度と体積の積
      • プログラムを開発または理解するのに必要な精神的な労力
      • \(\begin{equation*} \text{E}=\text{D}^{\ast}\text{V} \end{equation*}\)
    • プログラムに含まれると予想されるバグの数
      • 労力の指標に基づいて推定されるバグの数
      • 労力が増えるほどバグの可能性も高まるという考えに基づく
      • \(\begin{equation*} B = {E^{\frac{2}{3}}}/{S^\ast} \end{equation*}\) \([S^\ast = 3000]\)
      • 別のバージョン
        • プログラムの情報量とバグの関係に焦点を当てたもの
        • \(\begin{equation*} B = \text{V}/\text{S}^\ast \end{equation*}\)
    • プログラムを記述するのにかかると予想される時間
      • プログラムを実装するのに必要な時間を秒単位で推定
      • Sは1秒あたりに処理できる精神的な判断の数で、通常は18
      • \(\begin{equation*} \text{T}=\text{E}/\text{S} \end{equation*}\) \([S = 18]\)

サンプルコード

  • ナルシシスト数かどうかを判定するプログラムをC++とPythonを使用して作成
  • Halsteadの複雑さの尺度を使用してそれぞれのプログラムの複雑さを評価
  • C++の方が、プログラムに含まれると予想されるバグの数、プログラムの実装や理解に必要な労力、プログラムを記述するのにかかると予想される時間が大きかった
  • このことから、Halsteadの複雑さの尺度を用いることで、構文の抽象度や複雑さを評価できることが分かる

結論

  • Halsteadの複雑さの尺度は、実装が簡単で、プログラム構造を徹底的に調査する必要がない
  • Halsteadの複雑さの尺度はコードと密接に関連しており、設計では使用できない

引用情報

  • 著者: T Hariprasad, G Vidhyagaran, K Seenu, Chandrasegar Thirumalai
  • タイトル: Software complexity analysis using halstead metrics
  • 雑誌 / 会議名: 2017 International Conference on Trends in Electronics and Informatics (ICEI)
  • ページ: pp. 1109-1113
  • 出版日: May 2017
  • DOI: https://doi.org/10.1109/ICOEI.2017.8300883