12.1 構造解析と設計
DFD: データフロー図
12.1.1 要件の説明
12.1.2 構造分析
最終結果: データ フロー ダイアグラム、データ ディクショナリ、および処理の説明。
12.1.3 全体の設計
データフロー図の各処理をモジュール化した上で、モジュール間の呼び出し関係を与えます。
12.1.4 詳細設計
各モジュールの詳細フローチャート
12.2 データベースの分析と設計
12.2.1 データベース設計の戦略と手順
1. 戦略: トップダウンとボトムアップ
2. 設計ステップ:
(1) ユーザーニーズ分析
(2) 概念設計
(3) 論理設計
(4) 物理設計
12.2.2 要件分析
1.要件分析のタスク、目標、および方法2.
要件分析段階のドキュメント 要件分析段階の成果物: データ フロー図、データ ディクショナリ、および要件仕様。
12.2.3 構造の概念設計
1. 概念構造設計の戦略と方法
戦略: トップダウン、ボトムアップ、段階的拡張、混合戦略。
方法論: エンティティ関係図 (ER 図)
2. ER法による概念モデルの確立
ER図の矛盾
12.2.4 論理構造設計
1.ER図関係モードの変換
ER 図をリレーショナル モデルに変換する原則
1. 各エンティティ タイプをリレーショナル モデルに変換します。
2. 連絡先をリレーショナル モデルに変換します。
(1) 1 対 1 の連絡先を変換するには 2 つの方法があります。
独立関係モード: 両端の主キーと関係自体の属性を組み込みます。(主キー: どちらか一方の主キー) マージ (どちらか一方の端): もう一方の端で主キーをマージし、自身の属性に接続します。(主キー: 変更なし)
(2) 1 対多の関係を変換するには 2 つの方法があります。独立関係モード: 両端の主キーと関係自体の属性を組み込みます。(主キー: 多端子主キー)
マージ (多端子): 相手側の主キーにマージし、自身の属性に接続します。(主キー: 変更なし)
(3) 多対多の関係を変換する方法は 1 つだけです.
独立関係モード: 両端の主キーと関係自体の属性を組み込みます。（主キー：両端の主キーの複合キー）
2. リレーショナルスキーマの標準化
(1) データ依存関係の決定
(2) パラダイムの決定
(3) リレーショナルスキーマの分解
(4) リレーショナルスキーマの評価と修正
3. 整合性の制約を決定する
エンティティの整合性: 主な属性を null にすることはできないと規定されています。
参照整合性 (参照整合性とも呼ばれます): 外部キーが参照テーブルの主キー値または null 値であることが規定されています。ユーザー定義の整合性:特定のアプリケーションに含まれるデータが満たさなければならない要件を反映して、特定の
リレーショナル データベースに対するユーザーの制約を指します。これはアプリケーション環境によって決定されます。たとえば、年齢は次の範囲の正の整数として定義されます。 0 ～ 150 。トリガー: 複雑な整合性制約。
4. ユーザービューの決定
12.2.5 データベースの物理設計
1. データ分散を決定する
2. データ ストレージ構造を決定する
3. データ アクセス方法を決定する
12.2.6 データベースの実装と保守
1. データベースの実装
1) 実際のデータベース構造を確立する
構造、データベース スキーマ、完全性記述、セキュリティ記述、物理ストレージ パラメータ記述
2) データ読み込み
手入力、データ変換ツールを使用
3) データベースの試運転と評価
2. データベースの保守
(1) 性能の監視と改善
(2) データベースのバックアップと障害復旧
(3) データベースの再編成と再構築
12.3 オブジェクト指向の分析と設計
12.3.1 オブジェクト指向分析および設計の手順
(1) システム機能のモデル化
(2) ドメインモデルの定義
(3) 相互作用、振る舞い、状態の定義
(4) 設計クラス図の定義
12.3.2 要件の説明
12.3.3 ユースケースのモデリング
12.3.4 モデリング活動
ユースケース図：
ユースケース間の関係：
包含関係：抽出された公開ユースケースを抽象ユースケースと呼び、元のユースケースを基本ユースケースまたは基本ユースケースと呼ぶ：複数のユースケースから抽出できる場合パブリック ビヘイビアを使用する場合は、包含関係を使用して表現する必要があります。
拡張関係: ユースケースが明らかに 2 つ以上の異なるシナリオを混合する場合、つまり、状況に応じて複数の分岐が発生する可能性がある場合、このユースケースは基本的なユースケースと 1 つ以上の拡張されたユースケースに分けることができます。より明確になる可能性があります。
汎化関係: 複数のユースケースが同様の構造と動作を共有する場合、それらの共通性は親ユースケースとして抽象化でき、他のユースケースは汎化関係のサブユースケースとして使用できます。ユース ケースの汎化関係では、サブ ユース ケースは親ユース ケースの特殊な形式であり、サブ ユース ケースは親ユース ケースのすべての構造、動作、および関係を継承します。
12.3.5 設計クラス図
クラス ダイアグラム: クラス ダイアグラムは、一連のクラス、インターフェイス、コラボレーション、およびそれらの間の関係を記述します。オブジェクト指向システムのモデル化において
、最も一般的な図はクラス図です。クラス図はシステムの静的な設計ビューを提供し、アクティビティ クラスのクラス図はシステムの静的なプロセス ビューを提供します。
12.3.6 モデル化されたオブジェクトの状態
オブジェクトの状態は、その寿命のある時点でのオブジェクトの状態を表し、プロパティの 1 つ以上の値を変更するイベントによって、オブジェクトの状態が変化します。
状態図。状態図は、状態、遷移、イベント、およびアクティビティで構成されるステート マシンを記述します。状態図は、オブジェクトの動的ビューを提供します。インターフェイス、クラス、またはコラボレーションの動作をモデル化するために特に重要であり、イベントに起因するオブジェクトの動作に重点を置いているため、リアクティブ システムのモデル化に非常に役立ちます。
12.3.7 相互作用のモデリング
シーケンス図 (シーケンス図、シーケンス図)。シーケンス図は、
一連のオブジェクトまたはアクターと、それらの間で送信される可能性のあるメッセージで構成される相互作用を示す相互作用図です。相互作用図は、システムの動的ビューに焦点を当てています。シーケンス図は、メッセージの時系列順を強調する相互作用図です。
12.4 アルゴリズムの分析と設計
12.4.1 C プログラミング言語と実装
[このモジュール ノートは無意味です。コードから学ぶ必要があります。】
1. ポインタ型
2. ポインタとデータ構造
12.4.2 アルゴリズムの設計と実装
アルゴリズムの実行に必要な時間の一般的な尺度:
O(1)<O(log2n)<O(n)<O(nlog2n)<O(n2)<O(n3)<O(2n)
ソートアルゴリズム
12.5 オブジェクト指向プログラミングと実装
この知識ポイントは、通常、午後の試験の最後の質問です. デザインパターンに従ってコードを記入し、文脈や文法などに注意してください. 一般に、ある程度のコード基礎を持っている人はあまり問題になりません.
回答方法については、私の記事:事例分析と質問作成スキルを参照してください。