ソフトウェア要件分析は「何を行うか」という問題を解決し、ソフトウェア設計プロセスは「どのように行うか」という問題を解決します。

ソフトウェア設計は、ソフトウェア要件をソフトウェア表現に変換するプロセスであり、主にソフトウェア アーキテクチャ設計段階とコンポーネント レベルの設計の 2 つの段階で構成されます。

設計アプローチを使用すると、ソフトウェア分析モデルのデータ、機能モデル、および動作モデルによって表されるソフトウェア要件に関する情報が設計フェーズに渡され、その結果、データ/クラス設計、アーキテクチャ設計、インターフェイス設計、コンポーネント レベルの設計が行われます。

データ/クラス設計: 分析クラス モデルをクラス実装とソフトウェア実装に必要なデータ構造に変換します。

アーキテクチャ設計: アーキテクチャ設計はソフトウェアの全体的な構造を定義します。

インターフェイス設計: インターフェイス設計では、ソフトウェア内、ソフトウェアと協調システム間、およびソフトウェア仲間間で通信する方法を説明します。

コンポーネント レベルの設計: コンポーネント レベルの設計は、ソフトウェア アーキテクチャの構造要素をソフトウェア コンポーネントの手順記述に変換します。

ソフトウェア設計のプロセスでは、ソフトウェアの品質要素に細心の注意を払う必要があります。

McGlanghlin ソフトウェア設計プロセスの目標は次のとおりです。

1) ソフトウェアコンポーネント間の制御を確立するために、設計された構造は階層構造である必要があります。

2) 設計はモジュール式であり、ソフトウェアを特定の機能またはサブ機能を完了するコンポーネントに論理的に分割する必要があります。

3) 設計にはデータの抽象化とプロセスの抽象化の両方を含める必要があります。

4) 設計では、独立した機能特性を持つモジュールを確立する必要があります。

5) 設計では、モジュールと外部環境の間の複雑な接続を軽減するインターフェースを確立する必要があります。

6) 設計は、ソフトウェア要件分析から得られた情報に基づいて、実行可能で再現可能な方法を確立できなければなりません。

1) 仕様の策定

2) アーキテクチャとインターフェースの設計

3) データ/クラス設計

4) コンポーネントレベル（プロセス）設計

5) 設計書を書く

6) デザインレビュー

抽象化は、ソフトウェア設計の規模が徐々に大きくなるにつれて、複雑さを制御するための基本戦略です。

徐々に洗練を求める

モジュール化、つまり、規定の原則に従ってソフトウェアをより小さな、独立しているが相互に関連するコンポーネントに分割することは、実際にはシステムの分解と抽象化のプロセスです。

モジュールは、データ記述や実行可能ステートメントなどのプログラム オブジェクトの集合であり、個別に名前が付けられ、名前によってアクセスできます。

たとえば、プロセス。関数、サブルーチン、マクロなど

各モジュールの実装の詳細は他のモジュールから隠される必要があります。

ブロックに含まれる情報 (データとプロシージャを含む) は、この情報を必要としない他のモジュールで使用することはできません。

情報の隠蔽により、プロセスの詳細とモジュールのローカル データ構造に対するアクセス制限を定義し、強制することができます。

機能の独立性: 機能の独立性は、モジュール性、抽象化、情報の隠蔽、ローカリゼーションなどの概念の直接の結果です。機能の独立性は、機能的に特化し、他のモジュールとの過剰な相互作用を回避するモジュールを開発することによって実現できます。

機能的自立の重要性

機能の独立性は、凝集と結合の 2 つの指標によって測定できます。

① ステークホルダー間のコミュニケーションの円滑化

②制度設計の早期意思決定に貢献

③伝達可能なシステムレベルの抽象化

共通のソフトウェアアーキテクチャ

大部分は、比較的少数の建築様式の 1 つに分類できます。

各スタイルは、次のようなシステム カテゴリを記述します。

一部のデータ (ファイルやデータベースなど) は構造の中心に保存され、他のコンポーネントによって頻繁に使用、追加、削除、または変更されます。

この構造は、一連の計算または処理コンポーネントによって入力データが出力データに変換される場合に適しています。

このスタイルにより、ソフトウェア設計者は、変更や拡張が非常に簡単なアーキテクチャを設計できます。

内容: メイン プログラム/サブプログラム スタイルのアーキテクチャとリモート プロシージャ コール スタイルのアーキテクチャ

ここで理解すべき概念がいくつかあります。

システムコンポーネントがデータをカプセル化し、データを操作するためのメソッド

コンポーネント間の対話と調整はメッセージを通じて行われます

この構造では、さまざまなレベルが定義されており、各レベルは外側のレベルよりも機械語命令に近い操作を実行します。

同じソフトウェア要件でも、さまざまな設計手法の異なる原則により、異なるソフトウェア構造が導き出されます。

同じ問題に対する異なるソフトウェア構造

1) アプリケーションシナリオ（シナリオ）の定義：ユースケース図を通じてユーザーの視点でシステムを表現する

2) 要件、制約、および環境の説明を導き出す: これは、顧客の懸念事項がすべてリストされていることを確認するための要件エンジニアリングの一部です。

3) 上記の状況と要件に対応できるアーキテクチャ スタイルを説明します。

4) システムの各パフォーマンスを個別に評価します。アーキテクチャ設計のパフォーマンスには、信頼性、パフォーマンス、セキュリティ、保守性、柔軟性、テスト容易性、移植性、再利用性、相互運用性などが含まれます。

5) さまざまなアーキテクチャ形式について、ステップ 4 で述べたパフォーマンスの感度を評価します。これは次の方法で評価できます。アーキテクチャ全体にいくつかの小さな変更を加え、アピールのパフォーマンスに微妙な変更があるかどうかを分析して判断します。アーキテクチャの変更によってパフォーマンスが大きく影響されるこれらのパフォーマンスは、センシティブ ポイントと呼ばれます。

6) ステップ 5 の感度分析を通じて、ステップ 3 で提案されたアーキテクチャを評価します。 SEI によって説明されている方法は次のとおりです。アーキテクチャの敏感なポイントを決定するとき、システム内で最も多くのトレードオフ ポイントを必要とする要因 (トレードオフ ポイント) を見つける必要があります。トレードオフ要因は、アーキテクチャ内のこの内容を変更すると、システムのパフォーマンスに微妙な変化が生じることを意味します。たとえば、クライアント/サーバー構成のシステムのパフォーマンスは、システム内のサーバーの数と密接に関係しています (たとえば、サーバーの数を増やすと、システムのパフォーマンスはある程度向上します)。この場合、サーバーの数がアーキテクチャのバランス ポイントになります。

(1) ソフトウェア構造の改善とモジュールの独立性の向上

(2) モジュールの適切な深さ、幅、ファンアウト、ファンイン

(3) モジュールの判断範囲は制御範囲内であること

(4) モジュールインターフェースの複雑さを軽減するよう努める

(5) 入口と出口が 1 つずつのモジュールを設計する

(6) モジュールの機能は予測可能である必要があり、モジュールのサイズは適度である必要があります。

(7) 一般に、モジュールには 30 ～ 50 個程度のステートメントが含まれることが望ましいです。

(8) 適切に設計されたソフトウェア構造は、通常、最上層のファンアウトが高く、中間層のファンアウトが少なく、最下層のファンインが高くなります。

各コンポーネントに使用されるアルゴリズムを決定し、アルゴリズムのプロセスを表現する適切なツールを選択し、コンポーネントの詳細な手順の説明を作成します。

各コンポーネントが内部的に使用するデータ構造を決定する

コンポーネントレベルの設計の最後には、上記の結果がコンポーネントレベルの設計仕様書に書き込まれ、レビューを経て正式な文書として形成され、次の段階（コーディング段階）の基礎となります。

より一般的な定義は次のとおりです。「プログラムのコード ブロックがシーケンス、選択、ループの 3 つの基本的な制御構造を通じてのみ接続されており、各コード ブロックの入り口と出口が 1 つだけある場合、プログラムは構造化されていると言われます。 。 の"

オブジェクト指向やソフトウェア再利用などの新しいソフトウェア開発手法や技術の開発により、より現実的で効果的な開発アプローチは、トップダウン手法とボトムアップ手法を有機的に組み合わせたものになる可能性があります。

プログラムフローチャート

N-S線図

パッド

アルゴリズムに複数のネストされた条件選択が含まれる場合、プログラム フローチャート、N-S ダイアグラム、または PAD を使用して明確に記述するのは困難です。

ただし、デシジョンテーブルは、複雑な条件の組み合わせと取るべきアクションとの対応を明確に表現できます。

デシジョンテーブルの利点は、すべての処理ルールを簡潔かつ明確に記述できることです。

ただし、デシジョンテーブルは、条件値の特定の組み合わせの下で起こり得る結果である静的なロジックを表現するものであり、処理シーケンスやループ構造を表現することはできません。

PDL（Program Design Language）とは、アルゴリズムの設計や機能部品の処理内容を記述するための言語で、デザイン言語と呼ばれます。

一種の擬似コードです。一般的に、疑似コードの文法規則は「外部文法」と「内部文法」に分けられます。

PDLの使用例

PDL の機能

ソフトウェア設計の最終的な目標は、最適なソリューションを獲得することです

「最良」とは、開発コストの削減、リソース消費量の削減、開発期間の短縮などの条件に基づいて、すべての候補ソリューションの中から、より高い生産性、より高い信頼性、保守性を実現できるソリューションを選択することを意味します。

デザインレビューの内容

レビューには、正式なレビューと非公式なレビューの 2 種類があります。