Iteration 1 Basics
閱讀書上第8章
在迭代開發中不是一次性實現所有需求，而是在多次迭代中對同一個用例進行增量開發
Elaboration（細化）
- 是一般項目中最初的一系列迭代
- 構建核心架構
- 定義主要需求
- 解決/規避高風險元素、估計整體進度安排和資源
相關製品
- 領域模型
- 設計模型：軟件類圖、對象交互圖、包圖
- 軟件架構文檔
- 數據模型：數據庫建模
- 用例storyboard、UI原型
通過以下三個要素來組織需求和迭代
- risk：包括技術難度、可用性的不確定性等
- coverage：對大量構件進行“廣泛膚淺“的實現
- criticality： 客戶認爲具有高業務價值的功能
Domain Models
閱讀書上第9章
領域模型定義
- 一組沒有定義操作的類圖
- 對概念類/現實世界中的對象的可視化表示，而不是軟件語言中的對象
- 也叫做 conceptual model， domain object models，analysis object models
領域模型的重點
- 提供了conceptual perspective
- 概念類（domain object或conceptual classes）
- 關聯（association）
- 屬性（attributes）
如何創建領域模型(重點) 書上P116
- 找到概念類
- reuse or modify existing models
- use a category list
- Identify noun phrases from the case text
- 識別名詞，這些名詞有可能是候選概念類，也可能是概念類的屬性
- 在POS案例中”Receipt（收據）“是否需要成爲一個概念類
- 不需要：收據是顯示其他信息的報表、彙總，所以沒有必要
- 需要：在退貨情況下，需要持票據才能退貨，模型就需要表示
- 如果認爲某概念類X不是現實世界中的數字或文本，那麼X可能就是概念類而不是屬性
- 描述類：一個具體的item可能有序列號表示物理實例，一個productdescription 則記錄item的描述信息
- 把概念類當做UML類圖草圖畫出（沒有方法）
- 添加必要的關聯來記錄概念類之間的關係
- 關聯名稱首字母需要大寫
- 添加必要的屬性來滿足需求信息
- 可見性 名稱： 類型 多重性 = 默認值 {特性表}
- 一般可見性默認爲私有
- ‘/’表示導出屬性
- 定義新的數據類型類
- 任何屬性不表示外鍵，應該採用關聯，而不是外鍵屬性
state diagram（狀態圖）
- 描述一個事物/對象受外部刺激/消息產生可見的狀態（屬性/屬性組合）的數據變化
- 確定狀態集合
- 確定外部時間和變遷條件
- 檢查邏輯完整性：終點可達性、循環分析
System Sequence Diagrams
閱讀書上第10章
SSD
- 用例文本、系統事件作爲輸入，SSD中的操作作爲操作契約和對象設計的輸入
- 對於用例的一個特定場景，外部參與者產生的時事件，其順序和系統之內的事情
- ”：“和下劃線表示其爲實例
Operation Contracts
閱讀書上第11章
sections of contract
- operation：操作的名稱與參數
- cross reference：發生此操作的用例
- precondition：執行操作之前，系統或對象狀態的重要假設
- postcondition：完成操作之後，領域模型對象的狀態
system operation
- 在畫SSD時，其中的系統事件調用系統操作
postconditions
- 描述領域模型中狀態的改變，包括實例創建/建立或取消關聯/改變屬性
- 描述後置條件，可以使得系統操作的效果更加明顯
如何編寫contract（契約）
- 從SSD中確定系統操作
- 當系統操作複雜時，在用例中不清楚，就創建操作契約
- 使用以下類別來描述後置條件
- 創建和刪除實例/修改屬性/形成和清除關聯