ソフトウェア設計の基本

ソフトウェア設計は、ユーザーの要件を適切な形式に変換するプロセスであり、プログラマーがソフトウェアのコーディングと実装を行うのに役立ちます。

ユーザー要件を評価するために、SRS（ソフトウェア要件仕様）ドキュメントが作成されますが、コーディングと実装のために、ソフトウェア用語でより具体的で詳細な要件が必要です。このプロセスの出力は、プログラミング言語での実装に直接使用できます。

ソフトウェア設計は、SDLC（ソフトウェア設計ライフサイクル）の最初のステップであり、問題領域からソリューション領域に集中力を移します。SRSに記載されている要件を満たす方法を指定しようとします。

ソフトウェア設計レベル

ソフトウェア設計は、次の3つのレベルの結果をもたらします。

Architectural Design - 建築設計は、システムの最高の抽象バージョンです。これは、ソフトウェアを、多くのコンポーネントが相互作用するシステムとして識別します。このレベルで、設計者は提案されたソリューションドメインのアイデアを得ることができます。
High-level Design- 高レベルの設計は、アーキテクチャ設計の「単一エンティティ-複数コンポーネント」の概念を、サブシステムとモジュールのより抽象化されていないビューに分割し、それらの相互作用を示します。高レベルの設計は、システムとそのすべてのコンポーネントをモジュールの形式で実装する方法に焦点を当てています。各サブシステムのモジュール構造と、それらの相互関係および相互作用を認識します。
Detailed Design- 詳細設計では、前の2つの設計でシステムとそのサブシステムと見なされていたものの実装部分を扱います。モジュールとその実装について詳しく説明します。各モジュールの論理構造と、他のモジュールと通信するためのインターフェースを定義します。

モジュール化

モジュール化は、ソフトウェアシステムを複数の個別の独立したモジュールに分割する手法であり、タスクを独立して実行できることが期待されます。これらのモジュールは、ソフトウェア全体の基本的な構成として機能する場合があります。設計者は、モジュールを個別に独立して実行および/またはコンパイルできるようにモジュールを設計する傾向があります。

モジュラー設計は、ソフトウェアのモジュラー設計に付随する他の多くの利点があるため、意図せずに「分割統治」問題解決戦略のルールに従います。

モジュール化の利点：

コンポーネントが小さいほどメンテナンスが簡単です
プログラムは機能面に基づいて分割できます
必要なレベルの抽象化をプログラムに取り入れることができます
凝集度の高い部品は再利用可能
同時実行が可能になります
セキュリティ面からの要望

並行性

昔は、すべてのソフトウェアは順番に実行されるようになっています。順次実行とは、コード化された命令が次々に実行されることを意味し、プログラムの一部のみが常にアクティブ化されることを意味します。たとえば、ソフトウェアに複数のモジュールがある場合、実行時にアクティブであることがわかるのは、すべてのモジュールのうちの1つだけです。

ソフトウェア設計では、並行性は、ソフトウェアをモジュールのように複数の独立した実行単位に分割し、それらを並行して実行することによって実装されます。言い換えると、並行性は、コードの複数の部分を互いに並行して実行する機能をソフトウェアに提供します。

プログラマーと設計者は、並列実行できるモジュールを認識する必要があります。

例

ワードプロセッサのスペルチェック機能は、ワードプロセッサ自体と並行して実行されるソフトウェアのモジュールです。

結合と凝集度

ソフトウェアプログラムがモジュール化されると、そのタスクはいくつかの特性に基づいていくつかのモジュールに分割されます。ご存知のように、モジュールはいくつかのタスクを実行するためにまとめられた一連の命令です。ただし、これらは単一のエンティティと見なされますが、相互に参照して連携する場合があります。モジュールの設計の品質とモジュール間の相互作用を測定できる手段があります。これらの測定は、結合と凝集と呼ばれます。

凝集

凝集度は、モジュールの要素内の内部依存性の程度を定義する尺度です。凝集力が大きいほど、プログラムの設計は優れています。

結束には7つのタイプがあります。

Co-incidental cohesion -これは計画外のランダムな結束であり、モジュール化のためにプログラムをより小さなモジュールに分割した結果である可能性があります。計画外であるため、プログラマーに混乱をもたらす可能性があり、一般的に受け入れられていません。
Logical cohesion - 論理的に分類された要素がモジュールにまとめられるとき、それは論理的凝集度と呼ばれます。
Temporal Cohesion - モジュールの要素が同じ時点で処理されるように編成されている場合、それは時間的凝集度と呼ばれます。
Procedural cohesion - モジュールの要素がグループ化され、タスクを実行するために順番に実行される場合、それは手続き型凝集度と呼ばれます。
Communicational cohesion - モジュールの要素がグループ化され、順番に実行され、同じデータ（情報）を処理する場合、それは通信の凝集度と呼ばれます。
Sequential cohesion - ある要素の出力が別の要素への入力として機能するなどの理由でモジュールの要素がグループ化される場合、それは順次凝集度と呼ばれます。
Functional cohesion - 最高の凝集度とされており、大いに期待されています。機能的凝集度のモジュールの要素は、すべてが単一の明確に定義された機能に寄与するため、グループ化されます。再利用することもできます。

カップリング

結合は、プログラムのモジュール間の相互依存性のレベルを定義する尺度です。モジュールがどのレベルで干渉し、相互作用するかを示します。カップリングが低いほど、プログラムは優れています。

結合には5つのレベルがあります。

Content coupling - モジュールが別のモジュールのコンテンツに直接アクセス、変更、または参照できる場合、それはコンテンツレベル結合と呼ばれます。
Common coupling- 複数のモジュールがいくつかのグローバルデータへの読み取りおよび書き込みアクセス権を持っている場合、それは共通またはグローバル結合と呼ばれます。
Control coupling- 2つのモジュールは、一方が他方のモジュールの機能を決定したり、その実行フローを変更したりする場合、制御結合と呼ばれます。
Stamp coupling- 複数のモジュールが共通のデータ構造を共有し、その異なる部分で機能する場合、それはスタンプ結合と呼ばれます。
Data coupling- データ結合とは、2つのモジュールが（パラメーターとして）データを渡すことによって相互作用する場合です。モジュールがデータ構造をパラメーターとして渡す場合、受信モジュールはそのすべてのコンポーネントを使用する必要があります。

理想的には、どのカップリングも最良とは見なされません。

設計検証

ソフトウェア設計プロセスの出力は、設計ドキュメント、擬似コード、詳細な論理図、プロセス図、およびすべての機能要件または非機能要件の詳細な説明です。

ソフトウェアの実装である次のフェーズは、上記のすべての出力に依存します。

次に、次のフェーズに進む前に、出力を確認する必要があります。ミスが早期に検出されるほど、問題が改善されるか、製品のテストまで検出されない可能性があります。設計フェーズの出力が正式な表記形式である場合は、検証に関連するツールを使用する必要があります。そうでない場合は、検証と妥当性確認に徹底的な設計レビューを使用できます。

構造化された検証アプローチにより、レビュー担当者は、いくつかの条件を見落とすことによって引き起こされる可能性のある欠陥を検出できます。優れた設計レビューは、優れたソフトウェア設計、精度、および品質にとって重要です。