## 連載：面向對象葵花寶典：思想、技巧與實踐（27） - 動態模型設計 類模型指導我們如何**聲明類**，動態模型指導我們如何**實現類**！ 動態模型設計一般都是在類模型設計完成后才開始，因為動態模型設計的時候一般都需要用到類模型中的類。相對類模型來說，動態模型要相對簡單一些，主要原因在于動態模型設計的時候沒有什么設計原則和設計模式需要應用，只需要對照用例模型，根據用例模型的特點，選取一個合適的動態模型將其表述出來即可。 動態模型在實際開發過程中有非常重要的作用，簡單來說，如果沒有動態模型，那么你雖然完成了類設計，但還是不能編碼，或者只能編寫類的聲明代碼（類屬性、方法名稱），但不能寫類的實現代碼（方法里面的實現邏輯，即：每個方法的實現）。動態模型就是用來指導我們如何編寫具體的方法的。 ? 有的同學可能會有疑問：那些地方要進行動態模型設計呢？ 還是那句老話，你覺得比較復雜你就設計，簡單你就不設計，總之：**你需要你就設計**！ 像我在實際開發中，基本上一個中等項目就一兩個業務設計動態模型（小項目看到需求就編碼了 ：） ），其它業務看需求文檔就能看出如何編碼，這也是有經驗和經驗不足的差別。 參考UML標準，常見的動態模型如下： ### 【狀態模型】 狀態模型主要用于描述對象的生命周期的狀態變化。通過狀態圖，我們可以了解到對象有哪些狀態，狀態之間如何轉換，轉換的觸發條件等。當我們發現一個對象的狀態比較復雜的時候，就需要設計對象的狀態模型。 UML中使用狀態圖來描述狀態模型 **【活動模型】** 活動模型主要用于描述一個工作流程或者計算流程。其關注點是在完成某項工作的過程中，系統中的哪些對象承擔了什么樣的任務、做了什么處理，以及這些對象之間的先后交互關系。當我們發現一個處理流程比較復雜的時候，就需要設計流程的活動模型。 UML中使用活動圖來描述活動模型 **【序列模型】** 序列模型主要用于描述對象按照時間順序組織的消息交互過程，其關鍵特征是強調按照“時間順序”來組織對象的交互，所以序列圖有時又稱為“時序圖”或者“順序圖”。序列模型是我們最常用的動態模型，特別適合將用例模型或者SSD轉換為系統的動態模型。 UML中使用序列圖來描述序列模型 **【協作模型】** 協作模型主要用于描述按照對象之間的關聯來組織的消息交互過程，其關鍵特征是強調“對象關系”來組織對象的交互。協作模型的作用和序列模型一樣，只是強調的點不同，大部分的時候我們都是選擇“序列模型”，因為序列模型的時間順序很多時候和用例模型的步驟不謀而合。 UML中使用協助圖來描述協作模型 注意：以上模型并不是每個都必須有的，根據實際需要選擇即可 **建模實踐** 以上這些模型都可以從用例模型推導出來，活動模型、序列模型、協作模型基本上都是和用例模型一一對應的，或者對應用例中的某個分支。一般情況下不推薦一個模型中包含多個分支，因為這樣會導致圖比較復雜，而且主題不突出。 ? 狀態模型和其它模型相比要復雜一些，因為并不能從單個用例或者單個用例分支推導出某個對象的所有狀態，而需要綜合多個用例模型，從中提取出和某個對象狀態相關的內容，再統一設計狀態模型。 ? 從用例模型推導出動態模型是一個“分解和分配”的過程，因為在用例模型中，系統是當做一個“黑盒”來看待的，而在動態模型中，系統不再是一個黑盒，而是分解成了一個一個的類。因此我們需要將原來籠統的劃分給系統的功能和職責，進一步分解并分配給不同的類。通俗的講，動態模型就是說：為了完成系統的XXX功能，?先需要類A做任務1，然后需要類B需要做任務2，再由類C做任務3。。。。。。依次分解下去，最終就能夠實現將類串起來，相互配合，最后實現了系統的需求。 ? 我們以POS機為例，假設我們基于買單這個用例的正常分支設計“序列模型”，則可以得到如下的“序列模型”：  有了上面這個“序列圖”，假設我們要開始寫代碼，則基本可以按照如下偽碼的方式實現（實際的編碼肯定不會這么簡單，但方法是一樣）： ~~~ main(){ Trade trade = new Trade(); Integer tradeId =trade.makeNewTrade(); //創建 trade.addGoods(); //增加商品 trade.cacuMoney(); //計算總額 ............//省略一大段代碼 Receipt receipt = new Receipt(); receipt.print(trade); //打印小票 ...........//省略一大段代碼 trade.finish(); //結束 } ~~~