Software-engineering-software-design-complexity

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

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

ソフトウェア設計の複雑さは、複雑さの指標と尺度を使用せずに評価することは困難です。 3つの重要なソフトウェアの複雑さの尺度を見てみましょう。

ハルステッドの複雑さの尺度

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

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

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

Parameter	Meaning
n1	Number of unique operators
n2	Number of unique operands
N1	Number of total occurrence of operators
N2	Number of total occurrence of operands

ソースファイルを選択してその複雑さの詳細をMetric Viewerで表示すると、次の結果がMetric Reportに表示されます。

Metric	Meaning	Mathematical Representation
n	Vocabulary	n1 + n2
N	Size	N1 + N2
V	Volume	Length *Log2 Vocabulary
D	Difficulty	(n1/2)* (N1/n2)
E	Efforts	Difficulty * Volume
B	Errors	Volume/3000
T	Testing time	Time = Efforts/S, where S=18 seconds.

循環的複雑度の測定

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

同じサイズの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つの入力が同じ形式であってはならないため、入力の一意性が測定されます。 これらの入力は、データまたは制御パラメーターのいずれかです。

• シンプル-入力カウントが少なく、内部ファイルへの影響が少ない場合
• 複雑-入力カウントが多く、より多くの内部ファイルに影響する場合
• 平均-単純と複雑の中間。

外部出力

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

• シンプル-出力数が少ない場合
• 複雑-出力数が多い場合
• 平均-単純と複雑の中間。

論理内部ファイル

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

• シンプル-レコードタイプの数が少ない場合
• 複雑-レコードタイプの数が多い場合
• 平均-単純と複雑の中間。

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

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

• シンプル-共有ファイルのレコードタイプの数が少ない場合
• 複雑-共有ファイルのレコードタイプの数が多い場合
• 平均-単純と複雑の中間。

外部からの問い合わせ

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

• シンプル-クエリの処理が少なく、少量の出力データが生成される場合
• 複雑-クエリが高いプロセスを必要とし、大量の出力データを生成する場合
• 平均-単純と複雑の中間。

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

Parameter	Simple	Average	Complex
Inputs	3	4	6
Outputs	4	5	7
Enquiry	3	4	6
Files	7	10	15
Interfaces	5	7	10

上記の表は、未加工の関数ポイントを生成します。 これらの機能ポイントは、環境の複雑さに応じて調整されます。 システムは、14の異なる特性を使用して説明されます。

• データ通信
• 分散処理
• 性能目標
• 操作構成の負荷
• 取引レート
• オンラインデータ入力、
• エンドユーザーの効率
• オンライン更新
• 複雑な処理ロジック
• 再利用性
• インストールが簡単
• 操作性
• 複数のサイト
• 変更を促進したい

次に、これらの特性係数は、以下に示すように0から5に評価されます

• 影響なし
• 偶発
• 適度な
• 平均
• 重要な
• エッセンシャル

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

CAF = 0.65 + 0.01N

その後、

Delivered Function Points (FP)= CAF x Raw FP

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