このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!
記事ディレクトリ
4. 複雑な問題のオブジェクト モデルは通常、5 つのレベルで構成されていますか?
6. オブジェクト モデルを作成するにはどのような手順を実行しますか?
10. オブジェクト指向分析の主なタスクは何ですか? なぜ？
11. 大規模で複雑なシステムの開発 複雑さを軽減するために、人々は慣れていますか?
14. 時間の流れと脚本を書くプロセスを説明する脚本の本質は何ですか?
1. 分析作業の主な3つの内容は何ですか?
すべての分析プロセスはシステム要件を抽出するプロセスであり、分析作業には主に理解、表現、検証が含まれます。
2. オブジェクト指向分析のプロセスは何ですか?
オブジェクト指向分析は、ユーザーの要件を抽出して整理し、問題領域の正確なモデルを確立するプロセスです。
3. 要件記述は明確に定められていますか?
いいえ。要件記述は不完全、不正確、非公式であることが多く、固まっていないため、要件を洗練し洗練するための基礎として使用する必要があります。
4. 複雑な問題のオブジェクト モデルは通常、5 つのレベルで構成されていますか?
- テーマレイヤー
- クラスとオブジェクト層
- 構造層
- 属性レイヤー
- サービス層
【注意】:これら 5 つのタスクを順番に完了する必要はありません。また、1 つのタスクを完了してから別のタスクを開始する必要もありません。
5. モデルの構築順序をオブジェクト指向で分析しますか?
通常の順序では、最初にオブジェクト モデルを確立し、オブジェクト モデル内の各クラスのサービスを定義する前に、動的モデルと機能モデルを確立します。
6. オブジェクト モデルを作成するにはどのような手順を実行しますか?
- クラスとオブジェクトを識別する
- 関連性を決定する
- テーマを分ける
- 属性の決定
- 継承を特定する
7. オブジェクト指向分析の一般的な順序は何ですか?
- クラスとオブジェクトの検索
- 認識構造
- テーマを特定する
- プロパティを定義する
- 動的モデルを作成する
- 機能モデルを構築する
- サービスを定義する
8. 督促状の内容はどのようなものですか？
- 問題領域
- 機能要件
- 性能要件
- アプリケーション環境と前提条件
9. 要件ステートメントは不変の文書ですか?
いいえ。要件ステートメントは単純なものでも複雑なものでも構いません。これはユーザーのニーズを理解するための出発点にすぎず、静的な文書ではありません。
10. オブジェクト指向分析の主なタスクは何ですか? なぜ？
オブジェクト指向分析の最初のタスクは、問題領域のオブジェクト モデルを確立することです。
オブジェクト モデルはターゲット システムの静的データ構造を表し、静的データ構造はアプリケーションの詳細への依存度が低く、決定が容易で、より安定しているためです。
11. 大規模で複雑なシステムの開発 複雑さを軽減するために、人々は慣れていますか?
システムをさらにいくつかの異なるトピックに分割し、機能的な分解方法ではなく問題のドメインによって特定するのが一般的です。
12. 動的モデルの構築には何が含まれますか?
- 状態図を作成する
- シーケンス図（シーケンス図）を作成する
- アクティビティ図の作成
13. スクリプトを書く目的は何ですか?
重要なインタラクション手順が見逃されないように、インタラクション プロセス全体の正確性と明確性を確保するのに役立ちます。
14. 時間の流れと脚本を書くプロセスを説明する脚本の本質は何ですか?
本質的には、システムの対話動作に対するユーザーの要件を分析するプロセスです。
15. イベント トレース図とはそもそも何ですか?
イベント トレース図は本質的には拡張スクリプトであり、イベント トレース図は簡略化された UML シーケンス図と考えることができます。
章の最後にまとめ
分析は、システム要件を抽出し、問題領域の正確なモデルを確立するプロセスであり、理解、表現、検証という3 つの主要なタスクが含まれます。オブジェクト指向分析の主な作業は、問題領域内のオブジェクトとオブジェクト間の関係を分析および決定し、問題領域のオブジェクト モデルを確立することです。
大規模で複雑なシステムのオブジェクト モデルは、通常、サブジェクト層、クラスとオブジェクト層、構造層、属性層、サービス層の 5 つのレベルで構成されます。これらは、オブジェクト モデルの構築プロセスで実行する必要がある 5 つのタスクに対応しています。
ほとんどの分析モデルは一度では完了しないため、問題領域の完全な意味を理解するには、分析を何度も繰り返す必要があります。したがって、分析作業は、厳密に決められた順序に従って行うものではなく、要件定義を機械的に分析モデルに変換する作業ではない。アナリストは、ユーザーやドメインの専門家とコミュニケーションを取り、繰り返し相談して、誤解を修正し、不足している情報をタイムリーに補足する必要があります。
分析モデルは、システム アナリストがユーザーやドメインの専門家とコミュニケーションを図るための効果的なコミュニケーション ツールです。最終モデルは、ユーザーとドメインの専門家によって検証される必要があります。コミュニケーションと確認のプロセスにおいて、プロトタイプはプロモーションにおいて大きな役割を果たすことがよくあります。
優れた分析モデルは、問題の本質的な属性を正確かつ完全に反映しており、無関係な内容が含まれていてはなりません。分析の目標は、問題領域を包括的かつ深く理解することであり、特定の実装に関する考慮事項は含まれるべきではありません。しかし、実際の分析プロセスにおいて実装関連の影響を完全に排除することは非現実的です。分析の目的は、要件定義を分析モデルに置き換え、その分析モデルを設計の基礎として使用することですが、実際には、分析と設計の間に絶対的な境界はありません。
次の章：ソフトウェアエンジニアリング—第 11 章 オブジェクト指向設計の知識ポイントの整理
繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう！