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