マインドマップギャラリー 第4章 設計工学マインドマップ
第 4 章 設計エンジニアリング マインド マップ このマインド マップには、ソフトウェア設計エンジニアリング、ソフトウェア設計原則、ソフトウェア アーキテクチャ設計、コンポーネント レベルの設計テクノロジ、設計仕様、および設計レビューの概要が含まれています。
2023-11-14 21:39:57 に編集されました第4章 デザインプロジェクト
ソフトウェア設計エンジニアリングの概要
ソフトウェア設計エンジニアリングの概要
ソフトウェア要件分析は「何を行うか」という問題を解決し、ソフトウェア設計プロセスは「どのように行うか」という問題を解決します。
ソフトウェア設計は、ソフトウェア要件をソフトウェア表現に変換するプロセスであり、主にソフトウェア アーキテクチャ設計段階とコンポーネント レベルの設計の 2 つの段階で構成されます。
ソフトウェア設計タスク
設計アプローチを使用すると、ソフトウェア分析モデルのデータ、機能モデル、および動作モデルによって表されるソフトウェア要件に関する情報が設計フェーズに渡され、その結果、データ/クラス設計、アーキテクチャ設計、インターフェイス設計、コンポーネント レベルの設計が行われます。
データ/クラス設計: 分析クラス モデルをクラス実装とソフトウェア実装に必要なデータ構造に変換します。
クラスに記述された詳細なデータ内容、CRC およびデータ ディクショナリで定義されたデータ オブジェクトと関係は、データ設計アクティビティの基礎となります。
データ設計プロセスには、次の 2 つのステップが含まれます。
まず、要件分析フェーズで決定されたデータ オブジェクトの論理表現を選択するには、最も効果的な設計ソリューションを選択するためにさまざまな構造のアルゴリズム分析が必要です。
次に、個々のデータ設計上の決定の影響を制限または範囲設定するために必要な論理データ構造上で動作するプログラム モジュールを特定します。
アーキテクチャ設計: アーキテクチャ設計はソフトウェアの全体的な構造を定義します。
アーキテクチャ設計は、ソフトウェア コンポーネント、外部から見える属性、およびそれらの間の関係で構成されるソフトウェアの全体的な構造を定義します。
アーキテクチャ設計表現は、システム仕様、解析モデル、および解析モデルで定義されたサブシステムの相互作用から導き出すことができます。
インターフェイス設計: インターフェイス設計では、ソフトウェア内、ソフトウェアと協調システム間、およびソフトウェア仲間間で通信する方法を説明します。
インターフェイスの設計には主に次の 3 つの側面が含まれます。
ソフトウェアモジュール間のインターフェースを設計する
モジュールと他の人間以外の情報生成者および消費者 (外部エンティティなど) の間のインターフェイスを設計する
デザイナー(ユーザー)とコンピュータの間のインターフェース
コンポーネント レベルの設計: コンポーネント レベルの設計は、ソフトウェア アーキテクチャの構造要素をソフトウェア コンポーネントの手順記述に変換します。
コンポーネント レベルの設計では、ソフトウェア アーキテクチャの構造要素がソフトウェア コンポーネントの手順記述に変換されます。
クラスベース モデル、フロー モデル、および動作モデルから得られる情報は、コンポーネント設計の基礎となります。
ソフトウェア設計の目標
ソフトウェア設計のプロセスでは、ソフトウェアの品質要素に細心の注意を払う必要があります。
McGlanghlin ソフトウェア設計プロセスの目標は次のとおりです。
1) 設計は、解析モデルに記述されているすべての明示的な要件を実装する必要があり、ユーザーが期待するすべての暗黙的な要件を満たさなければなりません。
2) 設計は読みやすく理解しやすく、将来のプログラミング、テスト、保守が容易になるようにする必要があります。
3) 設計は実装の観点から開始し、データ、機能、動作に関連するソフトウェアの全体像を把握する必要があります。
測定設計に関する技術基準
1) ソフトウェアコンポーネント間の制御を確立するために、設計された構造は階層構造である必要があります。
2) 設計はモジュール式であり、ソフトウェアを特定の機能またはサブ機能を完了するコンポーネントに論理的に分割する必要があります。
3) 設計にはデータの抽象化とプロセスの抽象化の両方を含める必要があります。
4) 設計では、独立した機能特性を持つモジュールを確立する必要があります。
5) 設計では、モジュールと外部環境の間の複雑な接続を軽減するインターフェースを確立する必要があります。
6) 設計は、ソフトウェア要件分析から得られた情報に基づいて、実行可能で再現可能な方法を確立できなければなりません。
ソフトウェア設計プロセス
1) 仕様の策定
2) アーキテクチャとインターフェースの設計
3) データ/クラス設計
4) コンポーネントレベル(プロセス)設計
5) 設計書を書く
6) デザインレビュー
ソフトウェア設計原則
抽象化と段階的な洗練
抽象化は、ソフトウェア設計の規模が徐々に大きくなるにつれて、複雑さを制御するための基本戦略です。
抽象化のプロセスは、具体的なものから一般的なものへと進みます。上位概念は下位概念の抽象化であり、下位概念は上位概念の洗練と洗練です。
ソフトウェア エンジニアリング プロセスの各ステップは、より高いレベルの抽象化の解釈を具体的に記述したものです。
ソフトウェア設計における主な抽象化手法は、プロセス抽象化とデータ抽象化です。
プロセス抽象化 (機能抽象化とも呼ばれる) とは、明確に定義された機能を完了する操作はすべて、実際には一連の下位レベルの操作によって完了するにもかかわらず、ユーザーが単一のエンティティとして扱うことができることを意味します。
データの抽象化は、このタイプのオブジェクトに適用されるデータ型と操作の定義を指し、これらの操作を通じてのみデータを変更および観察できるオブジェクトの値の範囲を制限します。
徐々に洗練を求める
段階的な改善。問題解決プロセスをいくつかのステップまたは段階に分割し、各ステップが前のステップよりも洗練され、問題の解決に近づきます。
抽象化により、設計者は低レベルの詳細を無視しながらプロセスとデータを記述することができ、一方、洗練により、設計プロセス中に低レベルの詳細を明らかにすることができます。
モジュラー
モジュール化、つまり、規定の原則に従ってソフトウェアをより小さな、独立しているが相互に関連するコンポーネントに分割することは、実際にはシステムの分解と抽象化のプロセスです。
モジュールは、データ記述や実行可能ステートメントなどのプログラム オブジェクトの集合であり、個別に名前が付けられ、名前によってアクセスできます。
たとえば、プロセス。関数、サブルーチン、マクロなど
情報隠蔽
各モジュールの実装の詳細は他のモジュールから隠される必要があります。
ブロックに含まれる情報 (データとプロシージャを含む) は、この情報を必要としない他のモジュールで使用することはできません。
情報の隠蔽により、プロセスの詳細とモジュールのローカル データ構造に対するアクセス制限を定義し、強制することができます。
機能的に独立した
機能の独立性: 機能の独立性は、モジュール性、抽象化、情報の隠蔽、ローカリゼーションなどの概念の直接の結果です。機能の独立性は、機能的に特化し、他のモジュールとの過剰な相互作用を回避するモジュールを開発することによって実現できます。
機能的自立の重要性
機能が分離され、インターフェイスが簡素化され、ソフトウェアの開発が容易になります。
設計の変更やコーディングの変更によって引き起こされる副作用が限定されているため、エラーの広がりが減少し、モジュールの再利用が可能になり、ソフトウェアの保守とテストが容易になります。
機能の独立性は、凝集と結合の 2 つの指標によって測定できます。
凝集度は、モジュール内の要素が互いにどの程度緊密に統合されているかを示す尺度です。
一般的なモジュールの凝集度は 7 つのタイプに分類されます
1) 偶然の凝集性(偶発的凝集性):独立した機能を明確に示さない同一のプログラムコード部分を複数のモジュールに分離したモジュールを偶然性凝集性モジュールと呼びます。
2) 論理的結合: 論理的に関連する一連のタスクを完了するモジュールを指します。モジュールが呼び出されるとき、モジュールに渡される制御パラメータによって、モジュールが実行すべき機能が決定されます。
3) 時間収束: モジュール内のすべてのタスクが同じ時間内に実行されなければならないことを意味します。例: 初期化モジュールと終了モジュール
4) プロセスの凝集性: 複数のタスクを完了するモジュールを指し、これらのタスクは指定された手順 (手続き型) に従って実行される必要があります。
5) 通信の凝集性: モジュール内のすべての処理要素が特定のデータ構造の領域に集中していることを意味します
6) 逐次結合: 複数の機能を完了するモジュールを指し、これらの機能は順番に実行される必要があります。
7) 機能的凝集性: モジュールのすべての部分が連携して特定の機能を完了し、密接に関連しており、分割できないという事実を指します。
結合は、モジュール間の相対的な独立性 (モジュールが互いにどの程度緊密に接続されているか) の尺度です。
モジュール間の接続方法としては、一般に7種類が考えられます。
1) コンテンツ結合: 1 つのモジュールが別のモジュールの内部データに直接アクセスする場合、または 1 つのモジュールが通常の入り口を介して他のモジュールにアクセスしない場合、または 2 つのモジュールにプログラム コードの一部が重複する場合、または 1 つのモジュールに複数の入り口がある場合。その後、2 つのモジュール間でコンテンツの結合が発生します
2) パブリック結合: モジュールのグループがすべて同じ共通データ環境にアクセスする場合、モジュール間の結合はパブリック結合と呼ばれます。パブリック データ環境には、グローバル データ構造、共有通信エリア、メモリのパブリック カバレージ エリアなどがあります。
3) 外部結合: モジュールがソフトウェアの外部の環境を介して接続される場合 (モジュールを特定のデバイス、フォーマット、または通信プロトコルに結合する I/O など)、それは外部結合と呼ばれます。
4) 制御結合: あるモジュールから別のモジュールに送信されるパラメータに制御情報が含まれており、その制御情報が受信モジュールの実行ロジックを制御するために使用される場合、それは制御結合と呼ばれます。
5)タグ結合:データ構造の一部(特定のデータ構造の部分構造など)が、パラメータテーブルを通じて2つのモジュール間で受け渡される。これがタグ結合である。
6) データ結合: パラメータ テーブルを介して 2 つのモジュール間で単純なデータのみが転送されます。これはデータ結合と呼ばれます。
7) 間接結合: 2 つのモジュール間に直接的な関係がない場合、つまり、どちらかが他方に依存せず、独立して動作できる場合、この結合は間接結合と呼ばれます。
モジュール間の接続が緊密であればあるほど、接続数が多くなり、結合度が高くなり、機能的な独立性が弱くなります。
モジュール内のさまざまな要素間の接続が密であればあるほど、モジュールの凝集度は高くなります。
機能的な独立性が高いモジュールは、凝集性が高く、結合性が低いモジュールである必要があります。
ソフトウェアアーキテクチャ設計
ソフトウェア アーキテクチャは、ソフトウェア コンポーネント、これらのコンポーネントの外部から見えるプロパティ、およびそれらのコンポーネント間の関係を含む、システムの 1 つ以上の構造に焦点を当てます。
Bass 氏は、アーキテクチャが重要である 3 つの主な理由を提案しています。
① ステークホルダー間のコミュニケーションの円滑化
②制度設計の早期意思決定に貢献
③伝達可能なシステムレベルの抽象化
アーキテクチャ開発プロセス
共通のソフトウェアアーキテクチャ
単一ホスト構造k
C/S(クライアント/サーバー)構造
B/S(ブラウザ/サーバー)構造
ソフトウェアアーキテクチャスタイル
大部分は、比較的少数の建築様式の 1 つに分類できます。
各スタイルは、次のようなシステム カテゴリを記述します。
① システムに必要な機能を実装する一部のコンポーネント(データベース、演算モジュールなど)
②「通信・調整・協力」のためにコンポーネントを接続するための「コネクタ」のセット
③ コンポーネントの統合方法に関するシステム制約を定義する
④ 設計者がシステム全体の特性を理解し、既知の特性を分析できるようにするセマンティックモデル
データ中心のアーキテクチャ
一部のデータ (ファイルやデータベースなど) は構造の中心に保存され、他のコンポーネントによって頻繁に使用、追加、削除、または変更されます。
データフロースタイルのアーキテクチャ
この構造は、一連の計算または処理コンポーネントによって入力データが出力データに変換される場合に適しています。
呼び出しと戻りのスタイルのアーキテクチャ
このスタイルにより、ソフトウェア設計者は、変更や拡張が非常に簡単なアーキテクチャを設計できます。
内容: メイン プログラム/サブプログラム スタイルのアーキテクチャとリモート プロシージャ コール スタイルのアーキテクチャ
ここで理解すべき概念がいくつかあります。
プログラム構造の深さ: プログラム構造のレベルの数を構造の深さといいます。構造の深さは、プログラム構造のサイズと複雑さをある程度反映します。
プログラム構造の幅: 階層内の同じレベルにあるモジュールの最大数を構造の幅と呼びます。
モジュールのファンインとファンアウト: ファンアウトは、モジュールが直接呼び出す (または制御する) 他のモジュールの数を表します。ファンインは、特定のモジュールを呼び出す (または制御する) モジュールの数として定義されます。複数のファンアウトは、多くの下位モジュールを制御および調整する必要があることを意味します。マルチファンインモジュールは通常、一般的なモジュールです。
オブジェクト指向スタイルのアーキテクチャ
システムコンポーネントがデータをカプセル化し、データを操作するためのメソッド
コンポーネント間の対話と調整はメッセージを通じて行われます
階層型アーキテクチャ
この構造では、さまざまなレベルが定義されており、各レベルは外側のレベルよりも機械語命令に近い操作を実行します。
代替アーキテクチャを評価する
同じソフトウェア要件でも、さまざまな設計手法の異なる原則により、異なるソフトウェア構造が導き出されます。
同じ問題に対する異なるソフトウェア構造
ATAM(アーキテクチャトレードオフ分析手法)
1) アプリケーションシナリオ(シナリオ)の定義:ユースケース図を通じてユーザーの視点でシステムを表現する
2) 要件、制約、および環境の説明を導き出す: これは、顧客の懸念事項がすべてリストされていることを確認するための要件エンジニアリングの一部です。
3) 上記の状況と要件に対応できるアーキテクチャ スタイルを説明します。
4) システムの各パフォーマンスを個別に評価します。アーキテクチャ設計のパフォーマンスには、信頼性、パフォーマンス、セキュリティ、保守性、柔軟性、テスト容易性、移植性、再利用性、相互運用性などが含まれます。
5) さまざまなアーキテクチャ形式について、ステップ 4 で述べたパフォーマンスの感度を評価します。これは次の方法で評価できます。アーキテクチャ全体にいくつかの小さな変更を加え、アピールのパフォーマンスに微妙な変更があるかどうかを分析して判断します。アーキテクチャの変更によってパフォーマンスが大きく影響されるこれらのパフォーマンスは、センシティブ ポイントと呼ばれます。
6) ステップ 5 の感度分析を通じて、ステップ 3 で提案されたアーキテクチャを評価します。 SEI によって説明されている方法は次のとおりです。アーキテクチャの敏感なポイントを決定するとき、システム内で最も多くのトレードオフ ポイントを必要とする要因 (トレードオフ ポイント) を見つける必要があります。トレードオフ要因は、アーキテクチャ内のこの内容を変更すると、システムのパフォーマンスに微妙な変化が生じることを意味します。たとえば、クライアント/サーバー構成のシステムのパフォーマンスは、システム内のサーバーの数と密接に関係しています (たとえば、サーバーの数を増やすと、システムのパフォーマンスはある程度向上します)。この場合、サーバーの数がアーキテクチャのバランス ポイントになります。
ソフトウェア アーキテクチャを設計するときは、次のルールを参照できます。
(1) ソフトウェア構造の改善とモジュールの独立性の向上
(2) モジュールの適切な深さ、幅、ファンアウト、ファンイン
(3) モジュールの判断範囲は制御範囲内であること
(4) モジュールインターフェースの複雑さを軽減するよう努める
(5) 入口と出口が 1 つずつのモジュールを設計する
(6) モジュールの機能は予測可能である必要があり、モジュールのサイズは適度である必要があります。
(7) 一般に、モジュールには 30 ~ 50 個程度のステートメントが含まれることが望ましいです。
(8) 適切に設計されたソフトウェア構造は、通常、最上層のファンアウトが高く、中間層のファンアウトが少なく、最下層のファンインが高くなります。
コンポーネントレベルの設計技術
構造化分析および設計手法では、コンポーネントはモジュールと呼ばれることがよくあります。
オブジェクト指向の分析および設計では、コンポーネントはクラスと呼ばれます。コンポーネントベースの開発手法では、コンポーネントはコンポーネントと呼ばれます。
コンポーネントレベルの設計段階では、主に次の作業が完了します。
各コンポーネントに使用されるアルゴリズムを決定し、アルゴリズムのプロセスを表現する適切なツールを選択し、コンポーネントの詳細な手順の説明を作成します。
各コンポーネントが内部的に使用するデータ構造を決定する
コンポーネントレベルの設計の最後には、上記の結果がコンポーネントレベルの設計仕様書に書き込まれ、レビューを経て正式な文書として形成され、次の段階(コーディング段階)の基礎となります。
構造化プログラミング手法
より一般的な定義は次のとおりです。「プログラムのコード ブロックがシーケンス、選択、ループの 3 つの基本的な制御構造を通じてのみ接続されており、各コード ブロックの入り口と出口が 1 つだけある場合、プログラムは構造化されていると言われます。 。 の"
オブジェクト指向やソフトウェア再利用などの新しいソフトウェア開発手法や技術の開発により、より現実的で効果的な開発アプローチは、トップダウン手法とボトムアップ手法を有機的に組み合わせたものになる可能性があります。
グラフ表示
プログラムフローチャート
プログラム フローチャートはどのプログラミング言語からも独立しており、比較的直感的で明確で、学習と習得が簡単です。
フローチャートを使用して構造化されたプログラムを記述するには、フローチャートを 5 つの基本的な制御構造のみに制限する必要があります。
N-S線図
Nassi と Shneiderman は、ボックス図 (N-S 図とも呼ばれます) と呼ばれる、構造化プログラミングの原則に準拠したグラフィカル記述ツールを提案しました。
5つの基本制御構造
パッド
PAD は、Problem Analysis Diagram の略で、プログラム フローチャートから発展したものです。
5つの基本制御構造
デシジョンテーブル
アルゴリズムに複数のネストされた条件選択が含まれる場合、プログラム フローチャート、N-S ダイアグラム、または PAD を使用して明確に記述するのは困難です。
ただし、デシジョンテーブルは、複雑な条件の組み合わせと取るべきアクションとの対応を明確に表現できます。
デシジョンテーブルの利点は、すべての処理ルールを簡潔かつ明確に記述できることです。
ただし、デシジョンテーブルは、条件値の特定の組み合わせの下で起こり得る結果である静的なロジックを表現するものであり、処理シーケンスやループ構造を表現することはできません。
デザイン言語 PDL
PDL(Program Design Language)とは、アルゴリズムの設計や機能部品の処理内容を記述するための言語で、デザイン言語と呼ばれます。
一種の擬似コードです。一般的に、疑似コードの文法規則は「外部文法」と「内部文法」に分けられます。
外部構文は、一般的なプログラミング言語で一般的に使用されるステートメントの文法規則に準拠する必要があります。
内部文法では、英語の簡単な文、語句、および一般的な数学記号を使用して、プログラムが実行すべき機能を記述します。
PDLの使用例
PDL の機能
1. すべての構造化された制御構造、データ記述、コンポーネント機能を提供する固定キーワード外部構文があります。外国語文法に属するキーワードは、PDL テキストを構造的に分割して理解しやすくすることができる限られた語彙セットです。キーワードを区別するために、キーワードは大文字、その他の単語は小文字にすることが規定されています。
2. 内部文法は自然言語を使用して処理特性を記述します。内部構文は比較的柔軟で、明確に記述されていれば文法上の誤りを心配する必要がないため、アルゴリズムのロジックの記述に集中できます。
3. 単純なデータ構造 (スカラーや配列など) と複雑なデータ構造 (リンク リストや階層構造など) を含むデータ記述メカニズムがあります。
4. インターフェイスの記述をさまざまな方法で表現するためのサブルーチン定義と呼び出しメカニズムがあります。
設計仕様と設計レビュー
設計仕様
デザインレビュー
ソフトウェア設計の最終的な目標は、最適なソリューションを獲得することです
「最良」とは、開発コストの削減、リソース消費量の削減、開発期間の短縮などの条件に基づいて、すべての候補ソリューションの中から、より高い生産性、より高い信頼性、保守性を実現できるソリューションを選択することを意味します。
デザインレビューの内容
トレーサビリティ: ソフトウェアのシステム構造とサブシステム構造を分析して、ソフトウェア設計が特定されたソフトウェア要件をすべてカバーしているかどうか、およびソフトウェアの各コンポーネントが特定の要件まで追跡できるかどうかを確認します。
インターフェース: ソフトウェアのさまざまな部分間の接続を分析し、ソフトウェアの内部インターフェースと外部インターフェースが明確に定義されているかどうかを確認します。コンポーネントが高凝集性と低結合性の要件を満たしているかどうか。コンポーネントのスコープがその制御範囲内にあるかどうか。
リスク: ソフトウェア設計が既存の技術条件および予算内で予定通りに実装できるかどうかを確認します。
実用性:ソフトウェア設計がニーズの解決に実用的であるかどうかを確認します。
技術的な明確さ: ソフトウェア設計がコードに簡単に変換できる形式で表現されていることを確認する
保守性:ソフトウェア保守の観点から、将来の保守の利便性を考慮したソフトウェア設計になっているかを確認します。
品質: ソフトウェア設計が良好な品質特性を示しているかどうかを確認します。
さまざまなオプション: 他のオプションを検討したかどうか、さまざまなオプションを比較するための基準は何なのかを確認してください。
制限: ソフトウェアの制限が現実的であり、要件と一致しているかどうかを評価します。
その他の具体的な質問: ドキュメントの評価、テスト容易性、設計プロセスなど。
レビューには、正式なレビューと非公式なレビューの 2 種類があります。
正式なレビューでは、ソフトウェア開発者に加えて、通常は弁護の形でユーザー代表やドメイン専門家も参加するよう求められます。
非公式レビューは本質的には多かれ少なかれピアツーピアであり、時間や形式に制限されません。