-
構造分析の目的 ** ユースケース(外部仕様)を実現するためにはシステム内部でどんあオブジェクトが必要になるかを分析する ** この段階ではまだシステムの「振る舞い」（処理）を意識したオブジェクトは抽出しない ** オブジェクト図、クラス図からステート図を作成する ** PIM(プラットフォーム依存) ** 振る舞い分析がこの後に登場する *** 相互作用図、ステートマシン図、クラス図 ！！！
-
構造分析の手順 ** オブジェクトの抽出 ** オブジェクト間のリンク定義 ** オブジェクト図の作成 ** インスタンスを考えてから、抽象化してオブジェクト図を作成する ** データモデリングの場合は異なる ** クラス図の場合、正解は一つではない。 ** データモデルの場合は正解は一つ。 ** クラス図の妥当性はインスタンス図で証明する ** データベース設計する場合は、作成したクラス図からO/Rマッピングするような形で設計する ** データベースの設計は本来オブジェクトモデルを作成してからデータモデルを作成する *** 日本だと先にデータモデルを作成しているが間違いである *** これをやるとMVCの構造にならない
-
オブジェクト図 ** オブジェクト図の作成（抽出）方法 *** ユースケースのシナリオからオブジェクトを作成する ** 1. 名詞を抽出する ** 2. オブジェクトの候補を探す
-
クラス図の作成 ** 多重度は必須。仕様が明確化されるため。 ** コンポジション。強い関係。全体がなくなると他も無くなる。 ** 矢印は誘導可能性。矢印の方向しか呼び出さない *** 矢印はプログラムレベルだと出てくる
-
クラスの導出 ** オブジェクトの共通点を枠ぐみとして抜き出す ** 「/」のついた項目は何かしらの処理で導出される項目（計算結果など）
-
かけるようになるための近道は・・・ ** よいクラス図（合っているクラス図）をいっぱい見る ** パターンを覚える *** ヘッダー・明細パターン *** アナリシスパターン (絶版かも）に書いてある *** デザインパターンも近いものもある *** コンポジットパターン （デザインパターン） ＝ 組織（パーティー）パターン
*演習
ユースケース名: 目的： 基本アクター： 事前条件： ステップ： 事後条件：
ユースケース名:ホテルの予約サイトを開く 目的： 基本アクター： 事前条件： ステップ： 事後条件：