プログラミングの複雑さ

プログラミングの複雑さ(またはソフトウェアの複雑さ)) は、ソフトウェアの多くのプロパティを含む用語であり、そのすべてが内部相互作用に影響します。何人かの解説者によると、「複雑」という用語と「複雑」という用語には区別があるそうです。複雑とは、理解するのが難しいことを意味しますが、時間と労力をかけて最終的には理解できるようになります。一方、複雑とは、多数のエンティティ間の相互作用を表します。エンティティの数が増えると、それらの間の相互作用の数が指数関数的に増加し、それらすべてを知り理解することが不可能な点に達します。同様に、ソフトウェアの複雑さのレベルが高くなると、インタラクションに意図せず干渉するリスクが増大するため、変更を行う際に欠陥が発生する可能性が高くなります。さらに極端なケースでは、ソフトウェアの変更が事実上不可能になる可能性があります。ソフトウェアの複雑さをソフトウェアの保守性と結び付けるという考えは、以下の研究者によって広範囲に検討されてきました。マニー・リーマン教授は、自身の研究からソフトウェア進化の法則を開発しました。彼と共著者のLes Belady は、よく引用される著書[1]の中で、ソフトウェアの状態を測定するために使用できる多数のソフトウェア メトリクスを検討し、最終的に唯一の実用的な解決策は次のようなものを使用することであるという結論に達しました。決定論的な複雑さのモデルを使用します。

対策

ソフトウェアの複雑さの尺度は数多く提案されています。これらの多くは、複雑さをうまく表現していますが、簡単な測定には適していません。より一般的に使用されるメトリクスには、次のようなものがあります。

  • McCabe の循環的複雑さの指標
  • ハルステッド ソフトウェア サイエンス メトリクス
  • Henry と Kafura は、1981 年に情報フローに基づくソフトウェア構造メトリクスを導入しました[2]。これはファンインとファンアウトの関数として複雑さを測定します。彼らは、プロシージャのファンインを、そのプロシージャへのローカル フローの数に、そのプロシージャが情報を取得するデータ構造の数を加えたものとして定義します。ファンアウトは、そのプロシージャから出るローカル フローの数に、プロシージャが更新するデータ構造の数を加えたものとして定義されます。ローカル フローは、問題のプロシージャを呼び出す、またはプロシージャから呼び出されるプロシージャとの間で受け渡されるデータに関連します。Henry と Kafura の複雑さの値は、「プロシージャの長さとファンインの 2 乗とファンアウトの積」 (長さ × (ファンイン × ファンアウト)²) として定義されます。
  • オブジェクト指向設計のためのメトリクス スイート[3]は、タイトルが示すように、オブジェクト指向コードに特化したメトリクスに焦点を当てて、1994 年に Chidamber と Kemerer によって導入されました。彼らは 6 つのオブジェクト指向の複雑さの指標を導入しています。クラスごとの重み付けされたメソッド、オブジェクト クラス間の結合、クラスの応答、子の数、継承ツリーの深さ、メソッドの凝集性の欠如

プログラミングの複雑さを測定するために使用できる指標が他にもいくつかあります。

  • 分岐の複雑さ (Sneed メトリック)
  • データアクセスの複雑さ (カードメトリック)
  • データの複雑さ (Chapin メトリック)
  • データ フローの複雑さ (エルスホフ メトリック)
  • 意思決定の複雑さ (マクルーア指標)
  • パスの複雑さ (Bang メトリック)

テスラーの法則は、人間とコンピューターの相互作用に関する格言、すべてのアプリケーションには、除去したり隠したりすることのできない量の固有の複雑さが存在すると述べています。

種類

プログラムの変更に伴う複雑さは、既存のプログラムの複雑さに関連し、それに依存します。問題の複雑さは 2 つの部分に分けることができます: [4]

  1. 偶発的な複雑さ: 選択したソフトウェア エンジニアリング ツールが原因でプログラマーが直面する困難に関連します。より適切に適合するツール セットまたはより高レベルのプログラミング言語を使用すると、この問題が軽減される可能性があります。偶発的な複雑さは、ソリューションの形式、つまりコードを構成するためにドメインを使用していないことの結果であることもよくあります。[要出典]偶発的な複雑さを回避するのに役立つ 1 つの手法は、ドメイン駆動設計です。
  2. 本質的な複雑さ: 解決すべき問題の特性によって引き起こされ、軽減することはできません。

Chidamber と Kemerer のメトリクス

Chidamber と Kemerer [3]は、多くの測定や学術論文で広く使用されている一連のプログラミング複雑さの指標を提案しました。これらは、以下に説明する WMC、CBO、RFC、NOC、DIT、および LCOM です。

  • WMC - クラスごとの重み付けメソッド
    • n はクラスのメソッドの数です
    • メソッドの複雑さです
  • CBO - オブジェクトクラス間の結合
    • 結合されている(使用中または使用中の)他のクラスの数
  • RFC - クラスの応答
    • どこ
    • メソッド i によって呼び出されるメソッドのセットです
    • クラス内のメソッドのセットです
  • NOC - 子供の数
    • このクラスまたはその子孫を継承するすべてのクラスの合計
  • DIT - 継承ツリーの深さ
    • このクラスの継承ツリーの最大の深さ
  • LCOM - 手法の一貫性の欠如
    • クラスメソッドで共通に使用される属性の共通部分を測定します。
    • どこ
    • Withは、クラスの - 番目のメソッドによってアクセスされる (読み取りまたは書き込みされる) 属性 (インスタンス変数) のセットです。

こちらも参照

参考文献

  1. ^ MM レーマム LA ベラディ; プログラムの進化 - ソフトウェア変更のプロセス 1985
  2. ^ ヘンリー、S. Kafura, D. IEEE Transactions on Software Engineering Volume SE-7、Issue 5、1981 年 9 月 ページ: 510 - 518
  3. ^ チダンバー、SR; Kemerer、CF、IEEE Transactions on Software Engineering、第 20 巻、第 6 号、1994 年 6 月 ページ:476 ~ 493
  4. ^ ソフトウェアエンジニアリングでは、問題は偶然の複雑さと本質的な複雑さに分けられます[1]。