Software-engineering-software-design-basics

提供:Dev Guides
移動先:案内検索

ソフトウェア設計の基本

ソフトウェア設計は、ユーザーの要件を何らかの適切な形式に変換するプロセスであり、ソフトウェアのコーディングと実装のプログラマーを支援します。

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

ソフトウェア設計はSDLC(Software Design Life Cycle)の最初のステップであり、問​​題の領域からソリューションの領域に集中します。 SRSに記載されている要件を満たす方法を指定しようとします。

ソフトウェア設計レベル

ソフトウェア設計では、3つのレベルの結果が得られます。

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

モジュール化

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

モジュール設計は、意図せずに「分割して征服する」問題解決戦略のルールに従います。これは、ソフトウェアのモジュール設計には他にも多くの利点があるためです。

モジュール化の利点:

  • 小さいコンポーネントは保守が簡単です
  • プログラムは機能面に基づいて分割できます
  • 希望するレベルの抽象化をプログラムに組み込むことができます
  • 凝集力の高いコンポーネントは再利用できます
  • 同時実行が可能になります
  • セキュリティ面からの要望

並行性

昔のことですが、すべてのソフトウェアは順番に実行されるものです。 順次実行とは、コード化された命令が次から次へと実行されることを意味します。これは、プログラムの特定の部分のみが常にアクティブ化されることを意味します。 ソフトウェアには複数のモジュールがあり、すべてのモジュールのうち1つだけが実行中にアクティブであることがわかります。

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

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

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

カップリングと凝集

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

凝集

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

凝集には7つのタイプがあります。

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

カップリング

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

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

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

理想的には、最高のカップリングは考慮されません。

設計検証

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

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

その後、次のフェーズに進む前に出力を検証する必要があります。 誤りが早期に検出されると、より良いか、製品のテストまで検出されない場合があります。 設計段階の出力が正式な表記形式である場合は、検証用の関連ツールを使用する必要があります。そうでない場合は、検証と検証に徹底的な設計レビューを使用できます。

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