ソフトウェア設計の複雑さ

複雑さという用語は、複数の相互接続されたリンクと非常に複雑な構造を持つイベントまたは物事の状態を表します。ソフトウェアプログラミングでは、ソフトウェアの設計が実現するにつれて、要素の数とそれらの相互接続が次第に膨大になり、一度に理解するのが難しくなります。

ソフトウェア設計の複雑さは、複雑さのメトリックと測定値を使用せずに評価することは困難です。3つの重要なソフトウェアの複雑さの測定値を見てみましょう。

ハルステッドの複雑さの測定

1977年、モーリスハワードハルステッド氏は、ソフトウェアの複雑さを測定するためのメトリックを導入しました。Halsteadのメトリックは、プログラムの実際の実装とそのメジャーに依存します。これらは、静的な方法で、ソースコードの演算子とオペランドから直接計算されます。これにより、C / C ++ / Javaソースコードのテスト時間、語彙、サイズ、難易度、エラー、および労力を評価できます。

ハルステッドによれば、「コンピュータープログラムは、演算子またはオペランドのいずれかに分類できるトークンのコレクションと見なされるアルゴリズムの実装です」。Halsteadメトリックは、プログラムを一連の演算子とそれに関連するオペランドと見なします。

彼は、モジュールの複雑さをチェックするためのさまざまな指標を定義しています。

パラメータ	意味
n1	一意の演算子の数
n2	一意のオペランドの数
N1	演算子の合計発生数
N2	オペランドの合計出現数

ソースファイルを選択してその複雑さの詳細をメトリックビューアに表示すると、メトリックレポートに次の結果が表示されます。

メトリック	意味	数学的表現
n	単語	n1 + n2
N	サイズ	N1 + N2
V	ボリューム	長さ* Log2語彙
D	困難	（n1 / 2）*（N1 / n2）
E	尽力	難易度*ボリューム
B	エラー	ボリューム/ 3000
T	テスト時間	時間=努力/ S、ここでS = 18秒。

循環的複雑度の測定

すべてのプログラムには、実行する必要のあるステートメントを決定するタスクやその他の意思決定ステートメントを実行するために実行するステートメントが含まれています。これらの意思決定構造は、プログラムの流れを変えます。

同じサイズの2つのプログラムを比較すると、プログラムの制御が頻繁にジャンプするため、意思決定ステートメントが多いプログラムはより複雑になります。

McCabeは、1976年に、特定のソフトウェアの複雑さを定量化するための循環的複雑度測定を提案しました。これは、if-else、do-while、repeat-until、switch-case、gotoステートメントなどのプログラムの意思決定構造に基づくグラフ駆動型モデルです。

フロー制御グラフを作成するプロセス：

• 意思決定構造によって区切られた、プログラムを小さなブロックに分割します。
• これらの各ノードを表すノードを作成します。
• 次のようにノードを接続します。

• コントロールがブロックiからブロックjに分岐できる場合

  円弧を描く

• 出口ノードから入口ノードへ

  円弧を描きます。

プログラムモジュールの循環的複雑度を計算するには、次の式を使用します-

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

上記のモジュールの循環的複雑度は次のとおりです。

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

P. Jorgensenによると、モジュールの循環的複雑度は10を超えてはなりません。

ファンクションポイント

ソフトウェアのサイズを測定するために広く使用されています。ファンクションポイントは、システムによって提供される機能に重点を置いています。システムの特徴と機能は、ソフトウェアの複雑さを測定するために使用されます。

ファンクションポイントは、外部入力、外部出力、論理内部ファイル、外部インターフェイスファイル、および外部照会という名前の5つのパラメーターに依存します。ソフトウェアの複雑さを考慮するために、各パラメーターはさらに単純、平均、または複雑に分類されます。

ファンクションポイントのパラメータを見てみましょう：

外部入力

外部からのシステムへのすべての一意の入力は、外部入力と見なされます。2つの入力が同じ形式であってはならないため、入力の一意性が測定されます。これらの入力は、データまたは制御パラメーターのいずれかです。

• Simple -入力数が少なく、内部ファイルへの影響が少ない場合

• Complex -入力数が多く、より多くの内部ファイルに影響を与える場合

• Average -単純なものと複雑なものの中間。

外部出力

システムによって提供されるすべての出力タイプは、このカテゴリにカウントされます。出力フォーマットや処理が一意である場合、出力は一意であると見なされます。

• Simple -出力数が少ない場合

• Complex -出力数が多い場合

• Average -単純なものと複雑なものの間。

論理内部ファイル

すべてのソフトウェアシステムは、その機能情報を維持し、適切に機能するために内部ファイルを維持します。これらのファイルは、システムの論理データを保持します。この論理データには、機能データと制御データの両方が含まれる場合があります。

• Simple -レコードタイプの数が少ない場合

• Complex -レコードタイプの数が多い場合

• Average -単純なものと複雑なものの間。

外部インターフェースファイル

ソフトウェアシステムは、ファイルを外部ソフトウェアと共有する必要がある場合や、処理のために、またはパラメータとして関数にファイルを渡す必要がある場合があります。これらのファイルはすべて、外部インターフェイスファイルとしてカウントされます。

• Simple -共有ファイルのレコードタイプの数が少ない場合

• Complex -共有ファイルのレコードタイプの数が多い場合

• Average -単純なものと複雑なものの間。

外部からのお問い合わせ

照会は入力と出力の組み合わせであり、ユーザーは入力として照会するデータを送信し、システムは照会の出力を処理してユーザーに応答します。クエリの複雑さは、外部入力と外部出力以上のものです。クエリの入力と出力が形式とデータの点で一意である場合、クエリは一意であると言われます。

• Simple -クエリに必要な処理が少なく、出力データが少量の場合

• Complex -クエリに高いプロセスが必要で、大量の出力データが生成される場合

• Average -単純なものと複雑なものの間。

システム内のこれらの各パラメーターには、クラスと複雑さに応じて重みが付けられます。次の表は、各パラメーターに与えられた重みを示しています。

パラメータ	シンプル	平均	繁雑
入力	3	4	6
出力	4	5	7
問い合わせ	3	4	6
ファイル	7	10	15
インターフェイス	5	7	10

上記の表は、生のファンクションポイントを示しています。これらのファンクションポイントは、環境の複雑さに応じて調整されます。システムは、14の異なる特性を使用して記述されます。

• データ通信
• 分散処理
• パフォーマンス目標
• 操作構成のロード
• 取引率
• オンラインデータ入力、
• エンドユーザーの効率
• オンラインアップデート
• 複雑な処理ロジック
• Re-usability
• インストールの容易さ
• 操作のしやすさ
• 複数のサイト
• 変化を促進したい

これらの特性係数は、以下に説明するように、0から5まで評価されます。

• 影響なし
• Incidental
• Moderate
• Average
• Significant
• Essential

次に、すべての評価がNとして合計されます。Nの値の範囲は0〜70です（14種類の特性x 5種類の評価）。これは、次の式を使用して、複雑さ調整係数（CAF）を計算するために使用されます。

CAF = 0.65 + 0.01N

次に、

Delivered Function Points (FP)= CAF x Raw FP

このFPは、次のようなさまざまなメトリックで使用できます。

Cost = $ / FP

Quality =エラー/ FP

Productivity = FP /人-月