P3_C8-11：細化階段-基礎迭代

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（契約）

1. 從SSD中肯定系統操做
2. 當系統操做複雜時，在用例中不清楚，就建立操做契約
3. 使用如下類別來描述後置條件 - 建立和刪除實例/修改屬性/造成和清除關聯