このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!
記事ディレクトリ
5. 全体設計の結果を記録する文書を作成します。文書の内容は何ですか?
10. 抽象化とは何ですか? それはソフトウェア エンジニアリング プロセスとどのように関係しますか?
16. ソフトウェア開発において結合性と凝集性を追求するための基準は何ですか?
17. 結合度を低いものから高いものに並べ替えますか? そして例を挙げてください
18. 結束度は高い順に並べますか? そして、それぞれ例を挙げてください？
22. 階層図と階層ブロック図の線が表す意味の違いは何ですか?
23. プロセスで使用する階層図に適した設計ソフトウェアはどれですか?
25. 階層図や構造図はモジュール間の呼び出し順序を表現できますか?
26. データフロー指向の設計手法の目標は何ですか? 情報フローには何が含まれますか?
27. テスト計画の作成はテスト ケースの設計と同じですか? なぜ
1. 全体的なデザインの基本的な目的は何ですか?
全体設計は概要設計や予備設計とも呼ばれ、主に「一言で言えばシステムをどのように実装すべきか」という質問に答えるものです。
2. 全体的な設計タスクは?
- この作業段階を通じて、システムを構成する物理要素の境界が定められます。
- ソフトウェアの構造を設計し、システム内の各プログラムがどのモジュールで構成されているか、モジュール間の関係を決定します。
3. 設計プロセス全体の 2 つのフェーズとは何ですか?
システム設計フェーズ、構造設計フェーズ
4. 全体的なデザインの手順は?
- 代替案を想像する
- 合理的な解決策を選択する
- 最適なソリューションを提案します
- 機能分解
- ソフトウェア構造を設計する
- 設計データベース
- テスト計画を作成する
- 書類を書く
- 見直して見直して
5. 全体設計の結果を記録する文書を作成します。文書の内容は何ですか?
- 手順
- ユーザーマニュアル
- テスト計画
- 詳細な実施計画
- データベース設計の結果
6. データフロー指向の設計手法とは何ですか?
要件分析段階で得られたデータ フロー図は、設計全体の優れた出発点となります。データ フロー図が適切なレベルまで洗練されていれば、データ フロー図からソフトウェア構造を直接マッピングできます。これはデータです。フロー指向の設計手法。
7. 全体的なデザインはどのような原則に従っていますか?
- 基本単位
- 概要
- 段階的な改良
- 情報の隠蔽とローカリゼーション
- モジュールに依存しない
8. モジュール化とは何ですか?
モジュール化とは、プログラムを独立して名前が付けられ、独立してアクセス可能なモジュールに分割することです。各モジュールはサブ機能を完了し、これらのモジュールが統合されて全体を形成し、ユーザーのニーズを満たす特定の機能を完了できます。
9. モジュール化の利点は何ですか?
- モジュール化の原理を使用すると、ソフトウェア構造がより明確になり、設計が容易になるだけでなく、読みやすく理解しやすくなります。
- ソフトウェアのテストとデバッグを簡単にする
- ソフトウェアの信頼性の向上に役立ちます
- ソフトウェアの修正可能性の向上に役立ちます
- 開発プロジェクトの組織運営に貢献
10. 抽象化とは何ですか? それはソフトウェア エンジニアリング プロセスとどのように関係しますか?
抽象化とは、物事の詳細を考慮せずに、本質的な特徴を抽出することを指します
ソフトウェア エンジニアリング プロセスの各ステップは、ソフトウェア ソリューションの抽象化レベルを改良するものです。
11. 段階的改良とは何ですか?
段階的改善とは、「主要な問題の解決に集中するために、問題の詳細の検討をできるだけ 遅らせること」を指します。これは、人間が複雑な問題を解決するために使用する基本的な方法であり、社会の基礎でもあります。多くのソフトウェアエンジニアリング技術。洗練は実際には洗練のプロセスであり、抽象化と洗練は相補的な概念のペアです。
[注] 段階的解決とは、一定期間内に解決しなければならないさまざまな問題に優先順位を付けるための手法と考えることができます。
12. モジュールの独立性とは何ですか?
モジュールの独立性の概念は、モジュール性、抽象化、情報の隠蔽、およびローカリゼーションの概念の直接的な結果です。
13. モジュールの独立性が重要なのはなぜですか?
- 効果的なモジュール型ソフトウェアの開発は比較的簡単です
- 独立したモジュールはテストと保守が容易です
14. カップリングとは何ですか?
結合は、異なるモジュールが互いにどの程度密接に依存しているかを示す尺度です。結合の強さは、モジュール間のインターフェイスの複雑さ、モジュールへのエントリまたはアクセスのポイント、インターフェイスを通過するデータによって異なります。
15. 凝集性とは何ですか?
凝集度は、モジュールの要素が互いにどれだけ緊密に結合されているかを示す尺度です。
16. ソフトウェア開発において結合性と凝集性を追求するための基準は何ですか?
ソフトウェアの開発では「低結合と高凝集性」の原則が追求されていますが、実際には凝集性の方が重要であることがわかります。
17. 結合度を低いものから高いものに並べ替えますか? そして例を挙げてください
- データ結合: 2 つのモジュールはパラメーターを介して情報を交換します。交換される情報はデータのみです。例: 2 つのモジュールがある場合、モジュール A の演算結果がパラメータとしてモジュール B に渡され、計算に参加します。
- 制御結合：伝送情報の中に制御情報があり、制御結合によるモジュールの適切な分解をデータ結合に置き換えることができます。例：エアコンリモコンモジュールとエアコン室外機モジュールの結合
- 機能結合: データ構造全体をパラメーターとして渡し、呼び出されたモジュールはその要素の一部のみを使用します。例: 1 つのシステムには ID カード情報が必要で、もう 1 つのシステムには名前情報のみが必要ですが、ユーザー情報全体が渡されると、機能の結合が発生します。
- 共通環境結合: 2 つ以上のモジュールが共通のデータ環境を通じて対話します。例: 複数のモジュールがグローバル配列を共有し、異なるモジュールで読み取りおよび書き込みが可能
- コンテンツ結合: モジュールが他のモジュールの内部プロパティに関連している場合、呼び出しを行わずに他のモジュールのプログラム コードや内部データを直接使用することをコンテンツ結合といいます。GOTO文などは断固として避けること。
[注1] 無接続結合は最も結合度が低いですが、これを達成することはほぼ不可能です。
[注 2] 設計原則: データ結合を可能な限り使用し、制御結合と機能結合の使用を減らし、アナウンス環境結合の範囲を制限し、コンテンツ結合を完全に回避します。
18. 結束度は高い順に並べますか? そして、それぞれ例を挙げてください？
- 機能的結合: モジュール内のすべての処理要素は全体に属し、単一の機能を完了します。例: モジュール内のすべての操作は、人の年齢を計算することです。
- 逐次的結合: モジュール内の処理要素は同じ機能に密接に関連しており、処理は逐次的に実行される必要があります。例: 成績の平均点を計算するには、まずすべての成績を入力し、合計点を計算し、次に除算して平均点を計算する必要があります。合計スコアの計算の出力は、平均スコアの計算の入力として使用され、必要なデータ送信が行われるため、順序関係が制限されます。
- 通信の凝集性: モジュール内のすべての要素は、同じ入力データを使用するか、同じ出力データを生成します。例: 入力情報を処理してレポートを作成し、同時に既存のデータを入力データで更新するサブルーチンがあり、2 つの操作は同じデータ ソースを使用します。
- プロセスの凝集性: モジュール内の処理要素は関連しており、特定の順序で実行する必要があります。例: 各クラスの平均成績を計算するには、クラス 123 の成績を順番に出力する必要があります。
- 時間的集約: モジュールに含まれるタスクは同じ期間内に実行される必要があります。例: 複数の変数の初期化を同じモジュールに入れます。
- 論理的結合: モジュールによって実行されるタスクは、論理的に同じまたは類似のカテゴリに属します。たとえば、モジュールはさまざまなタイプの出力、印刷番号、印刷名、印刷配列などを生成しますが、それらの機能はすべて出力情報の印刷であり、機能は同じです。
- 偶発的な結合: モジュールは一連のタスクを完了しますが、タスクが相互に関連している場合でも、その関係は非常に緩やかです。たとえば、モジュール A には n 個のステートメントがありますが、これらのステートメントは相互に関係がありません。
19. ヒューリスティックルールとは何ですか?
- ソフトウェア構造の改善とモジュールの独立性の向上
- モジュールのサイズは適度である必要があります
- 深さ、幅、ファンイン、ファンアウトはすべて適切である必要があります
- モジュールのスコープは制御スコープ内にある必要があります
- モジュールインターフェイスの複雑さを軽減するよう努めます
- シングルエントリーおよびシングルイグジットモジュールの設計
- モジュールの機能は予測可能である必要があります
20. モジュールのスコープと制御ドメインは何ですか?
スコープ: そのモジュール内の述語の影響を受けるすべてのモジュールのセット
制御ドメイン: モジュール自体と、そのモジュールに直接または従属するすべてのモジュールのコレクション
[注] 上図は例であり、モジュール A の制御ドメインは A、B、C、D、E、F です。
21. 深さ、幅、ファンイン、ファンアウトとは何ですか?
- 深さ:ソフトウェア構造内の制御層の数を示し、多くの場合、システムのサイズと複雑さを大まかに示します。
- 幅:ソフトウェア構造内の同じレベルにあるモジュールの総数の最大値を示します。一般に、幅が大きいほど、システムはより複雑になります。幅に最も影響を与える要因はモジュールのファンアウトです。
- ファンアウト: モジュールが直接制御する (呼び出す)モジュールの数を示します。良好なシステムの平均ファンアウトは 3 ～ 4 です
- ファンイン:上位レベルのモジュールが呼び出す数を示します。ファンイン マルチサーフェス、モジュールはより多く呼び出されるほど優れています。
22. 階層図と階層ブロック図の線が表す意味の違いは何ですか?
階層図の接続線は呼び出し関係を表し、階層ブロック図の接続線は構成関係を表します。
[注] 2 番目の図は、エンティティの観点から分析した 階層ブロック図ですが、機能の観点から分析した階層図です。
23. プロセスで使用する階層図に適した設計ソフトウェアはどれですか?
トップダウン
24. 構造図の記号の意味は何ですか?
構造図はソフトウェア設計のためのもう 1 つの強力なツールです
ボックスはモジュールを表し、ボックス間の矢印はモジュール呼び出し関係を表し、注釈付きの矢印はモジュール呼び出しプロセス中にやり取りされるメッセージを表します。
25. 階層図や構造図はモジュール間の呼び出し順序を表現できますか?
階層図や構造図はモジュール間の呼び出し順序を厳密に表現することはできず、下位レベルのモジュールをいつ呼び出すかを示すものではなく、モジュールがどのモジュールを呼び出すかを示すだけです。
26. データフロー指向の設計手法の目標は何ですか? 情報フローには何が含まれますか?
データフロー指向の設計アプローチの目標は、ソフトウェア構造の設計に体系的なアプローチを提供することです。
情報フローには変換フローとトランザクション フローが含まれます
27. テスト計画の作成はテスト ケースの設計と同じですか? なぜ
この 2 つは異なります。テスト計画は設計全体の段階で策定されますが、現時点では具体的なコード実装がないため、それぞれのテスト ケースを具体的に記述することは不可能です。
28. 全体的なデザインの必要性?
グローバルなレベル に立って、より少ないコストで、より抽象的なレベルで考えられる複数のシステム実装スキームとソフトウェア構造を分析および比較し、その中から最適なスキームと最も合理的なソフトウェア構造を選択して、比較的低コストで高品質のソフトウェア システムを開発します。
章の最後にまとめ
全体的な設計フェーズの基本的な目的は、システムがあらかじめ決められたタスクを抽象的かつ一般的な方法でどのように完了するかを決定することです。つまり、システムの物理構成スキームを決定し、次にそれを実現する各プログラムの構造を決定する必要があります。システムを決定する必要があります。したがって、全体の設計フェーズは主に 2 つの小さなフェーズで構成されます。まず、システム設計を行う必要があります。データフロー図から始めて、システム機能を完成させるための合理的な物理スキームをいくつか想像し、アナリストがこれらのスキームを慎重に分析および比較し、最適なスキームをユーザーと共同で選択する必要があります。次に、ソフトウェアがどのようなモジュールから構成されているか、およびそれらのモジュール間の動的な呼び出し関係を決定するソフトウェア構造設計が行われます。階層図と構造図は、ソフトウェアの構造を表現するための一般的なツールです。
ソフトウェア構造の設計において従うべき最も重要な原則は、モジュールの独立性の原則です。つまり、ソフトウェアは、比較的独立したサブ機能を完了するモジュールのグループと、それらの間のインターフェイス関係で構成される必要があります。モジュールはできるだけシンプルである必要があります。抽象化と洗練は相補的な
概念 のペアであり、人間が複雑な問題を解決するために最も一般的に使用される効果的な方法でもあります。ソフトウェア構造設計における効果的な方法は、抽象から具体へソフトウェア階層を構築することです。ソフトウェア エンジニアは、長期にわたるソフトウェア開発の実践で豊富な経験を蓄積しており、これらの経験を要約して非常に価値のあるヒューリスティック ルールを導き出し、多くの場合、ソフトウェア設計を改善する方法について貴重なヒントを得ることができます。ソフトウェア開発のプロセスでは、これらのヒューリスティック ルールに十分な注意を払って利用するだけでなく、実際の状況から機械的にコピーすることも避けなければなりません。
トップダウンで段階的に調整するのがソフトウェア構造設計の一般的なアプローチですが、詳細なデータ フロー図がすでにある場合は、データ フロー指向の設計手法を使用して、データ フローからソフトウェアをマッピングすることもできます。形式化された図の構造。このように計画されたものは ソフトウェアの初期構造にすぎず、より高品質のモジュールを取得するには、ソフトウェアの初期構造を設計原則に基づいて、ヒューリスティック ルールを参照して慎重に分析および改善する必要があることに注意してください。そしてより合理的なソフトウェア構造。
詳細なプロセス設計やプログラミングを行う前に、ソフトウェア開発の初期段階でソフトウェア構造をグローバルレベルで最適化できることが構造設計の利点です。この期間中に最適化を行うと低コストで、ソフトウェアの品質が大幅に向上する可能性があります。
次の章:ソフトウェア エンジニアリング - 第 6 章 詳細な設計の知識ポイントの整理
繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう！