在迭代開發中，我們并非一次就實現所有需求。

在多個迭代里對同一用例進行增量式開發。

細化階段：構建核心架構，解決高風險元素，定義大部分需求，以及預計總體進度和資源。（包括了三到四次的細化迭代）
關鍵思想和最佳實踐：
 實行短時間定量、風險驅動的迭代
 及早開始編程
 對架構的核心和風險部分進行適應性設計、實現和測試
 盡早、頻繁、實際的測試
 基于來自測試、用戶、開發者的反饋進行調整
 通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代進行一次
制品：領域模型、設計模型、軟件架構文檔、數據模型、用例、用戶界面原型。

領域模型
領域模型是對領域內的概念類或現實世界中對象的可視化表示。
應用UML表示法，領域模型被描述為一組沒有定義操作的類圖，反映屬性和關聯。（一定注意，它不是軟件對象！是概念對象！）
準則：
  使用領域術語
  認真汲取領域專家所使用的核心詞匯和概念
  如果某概念類不是現實世界中的數字或文本，那么她可能是概念類而不是屬性
  需要描述類：1、需要有關商品或服務的描述，獨立于任何商品或服務的現有實例；2、減少冗余或重復信                 息
  避免加入大量關聯，添加關聯是為了突出對重要關系的大致理解，而非記錄對象或數據的結構
  通過關聯而不是屬性來表示概念類之間的關系，領域模型中屬性的類型應該是數據類型（基本類型）
  對數量和單位建模
每次迭代的領域建模不超過幾個小時。

系統順序圖
系統順序圖（SSD）是為闡述與所討論系統相關的輸入和輸出事件而快速、簡單地創建的制品。是操作契約和對象設計的輸入。
SSD展示了直接與系統交互的外部參與者、系統（作為黑盒）以及由參與者發起的系統事件。這些事件是通過用例文本總結出來的。
應為每一個用例的主成功場景，以及頻繁發生的或者復雜的替代場景繪制SSD。
基本上軟件系統要對三種事件進行響應：來自于參與者的外部事件，時間事件，錯誤和異常（通常源于外部）。
系統事件應該在意圖的抽象級別而非物理的輸入設備級別來表達。

操作契約
操作契約使用前置和后置條件的形式，描述領域模型里對象的詳細變化。其中的關鍵元素是后置條件。
為系統操作定義操作契約。系統操作在繪制SSD草圖時確定。
后置條件描述了領域模型內對象狀態的變化。可分為三種類型：創建或刪除實例，屬性值的變化，形成和消除關聯。注意，它描述的是所需的變化，而不是這些變化是如何完成的。以說明性的、被動式的過去時態編寫后置條件。（例如，創建了xx，而不是創建xx）

邏輯架構和UML包圖
邏輯架構是軟件類的宏觀組織結構，它將軟件類組織為包（或命名空間）、子系統和層等。
UML包圖常用于描述系統的邏輯架構--層、子系統、包等。
將系統的大型邏輯結構組織為獨立的、職責相關的離散層，具有清晰、內聚的關注分離。
協作和耦合是從較高層到較低層進行的，要避免從較低層到較高層的耦合。較低層包含可復用功能。
可以將應用邏輯層更準確地稱為架構的領域層，即包含領域對象（注意領域模型與領域對象是不同的兩個概念），處理應用邏輯的層。
領域層是軟件的一部分，領域模型是概念角度分析的一部分。
從UI層發送到領域層的消息將是SSD中所描述的消息。

輕量級繪圖然后編碼。


http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）