System-analysis-and-design-strategies
設計戦略
トップダウン戦略
トップダウン戦略では、モジュール方式を使用してシステムの設計を開発します。 最上位または最上位のモジュールから始まり、最下位のモジュールに向かって移動するため、そう呼ばれます。
この手法では、ソフトウェアを開発するための最高レベルのモジュールまたはメインモジュールが識別されます。 メインモジュールは、各モジュールによって実行されるタスクに基づいて、いくつかのより小さくシンプルなサブモジュールまたはセグメントに分割されます。 次に、各サブモジュールは、さらに下位レベルのいくつかのサブモジュールにさらに分割されます。 各モジュールを複数のサブモジュールに分割するこのプロセスは、さらに細分化できない最下位レベルのモジュールが識別されなくなるまで続きます。
ボトムアップ戦略
ボトムアップ戦略は、モジュール方式に従ってシステムの設計を開発します。 最下部または最も基本的なレベルのモジュールから始まり、最上位のモジュールに向かって移動するため、そう呼ばれます。
この手法では、
- 最も基本的なレベルまたは最も低いレベルのモジュールが識別されます。
- これらのモジュールは、各モジュールで実行される機能に基づいてグループ化され、次のより高いレベルのモジュールを形成します。
- 次に、これらのモジュールをさらに組み合わせて、次の上位モジュールを形成します。
- いくつかのより単純なモジュールをグループ化してより高いレベルのモジュールを形成するこのプロセスは、システム開発プロセスのメインモジュールが達成されるまで続きます。
構造化設計
構造化設計は、開発システムの入力と出力の識別に役立つデータフローベースの方法論です。 構造化設計の主な目的は、複雑さを最小限に抑え、プログラムのモジュール性を高めることです。 構造化された設計は、システムの機能面を記述するのにも役立ちます。
構造化設計では、システム仕様は、DFDの助けを借りてソフトウェア開発に含まれるデータの流れとプロセスのシーケンスをグラフィカルに表現するための基礎として機能します。 ソフトウェアシステムのDFDを開発したら、次のステップは構造図を開発することです。
モジュール化
構造化設計は、プログラムを小さな独立したモジュールに分割します。 これらは、下に詳細が示された上から下に向かって構成されています。
したがって、構造化設計では、モジュール化または分解と呼ばれるアプローチを使用して、複雑さを最小限に抑え、問題をより小さなセグメントに分割することで問題を管理します。
メリット
- 重要なインターフェースが最初にテストされます。
- 抽象化を提供します。
- 複数のプログラマーが同時に作業することができます。
- コードを再利用できます。
- コントロールを提供し、士気を向上させます。
- 構造の識別が容易になります。
構造化チャート
構造化チャートは、システム開発のさまざまなモジュールと各モジュール間の関係を定義するモジュール式のトップダウンシステムを設計するための推奨ツールです。 システムモジュールとそれらの間の関係を示しています。
モジュール、接続矢印、または線を表す長方形のボックスで構成される図で構成されます。
- 制御モジュール-*下位モジュール*と呼ばれる、下位レベルのモジュールを指示する上位レベルのモジュールです。
- ライブラリモジュール-再利用可能なモジュールであり、チャートの複数のポイントから呼び出すことができます。
構造化チャートを設計するには、2つの異なるアプローチがあります-
- Transform-Centered Structured Charts -すべてのトランザクションが同じパスをたどるときに使用されます。
- トランザクション-中心構造化チャート-すべてのトランザクションが同じパスをたどらない場合に使用されます。
構造フローチャートを使用する目的
- トップダウン設計を奨励するため。
- モジュールの概念をサポートし、適切なモジュールを識別するため。
- システムのサイズと複雑さを表示します。
- 各機能内の容易に識別可能な機能およびモジュールの数を特定するため。
- 特定可能な各機能が管理可能なエンティティであるか、またはより小さなコンポーネントに分割する必要があるかを示します。
システムの複雑さに影響する要因
良質のシステムソフトウェアを開発するには、優れた設計を開発する必要があります。 したがって、システムの設計を開発する際の主な焦点は、ソフトウェア設計の品質です。 優れた品質のソフトウェア設計は、ソフトウェア開発の複雑さとコスト支出を最小限に抑えるものです。
システムの複雑さを判断するのに役立つシステム開発に関連する2つの重要な概念は、*カップリング*と*凝集*です。
カップリング
結合は、コンポーネントの独立性の尺度です。 システム開発の各モジュールの依存関係の度合いを定義します。 実際には、これは、システム内のモジュール間の結合が強いほど、システムの実装と保守が難しくなることを意味します。
各モジュールには、他のモジュールとのシンプルでクリーンなインターフェースが必要です。また、最小限のデータ要素をモジュール間で共有する必要があります。
高カップリング
これらのタイプのシステムには、相互に依存するプログラム単位との相互接続があります。 1つのサブシステムを変更すると、他のサブシステムに大きな影響を与えます。
低カップリング
これらのタイプのシステムは、独立した、またはほぼ独立したコンポーネントで構成されています。 1つのサブシステムを変更しても、他のサブシステムには影響しません。
カップリング対策
- コンテンツカップリング-あるコンポーネントが実際に別のコンポーネントを変更する場合、変更されたコンポーネントは変更に完全に依存します。
- 共通結合-共通データストアからデータにアクセスできるようにシステム設計を整理することにより、結合の量がいくぶん削減される場合。
- Control Coupling -あるコンポーネントが別のコンポーネントのアクティビティを制御するためにパラメータを渡すとき。
- スタンプカップリング-あるコンポーネントから別のコンポーネントに情報を渡すためにデータ構造が使用される場合。
- データ結合-データのみが渡される場合、コンポーネントはこの結合によって接続されます。
凝集
凝集度は、そのコンポーネント間の関係の近さの尺度です。 モジュールのコンポーネントの依存関係の量を定義します。 実際には、これはシステム設計者が次のことを確認する必要があることを意味します-
- 重要なプロセスを断片化されたモジュールに分割しません。
- DFD上のプロセスとして表される無関係なプロセスを無意味なモジュールにまとめません。
最適なモジュールは、機能的に凝集したモジュールです。 最悪のモジュールは、偶然にまとまりのあるものです。
最悪の凝集度
偶発的な凝集は、部品が他の部品と無関係であるコンポーネントに見られます。
- 論理的結合-論理的に関連するいくつかの機能またはデータ要素が同じコンポーネントに配置される場所です。
- Temporal Cohesion -システムの初期化または変数の設定に使用されるコンポーネントがいくつかの機能を順番に実行しますが、機能は関連するタイミングによって関連付けられます。
- 手続き的に結合-この順序を保証するためだけに、関数がコンポーネントにグループ化される場合です。
- Sequential Cohesion -コンポーネントのある部分からの出力が、その次の部分への入力である場合です。
