456
讓技術人員看得懂的流程（6）——處理模型
讓技術人員看得懂的流程（6）
——處理模型
看完“實現模型”，你是否長籲一聲，準備拿起咖啡，愜意的喝上一杯？畢竟我們已經完成了從用例到編碼的全過程了，確實是值得慶祝的一件事情，但“革命尚未成功、同誌還需努力”，現在還不是享受的時候，接下來我們需要進入“處理模型”階段。
l “處理模型”階段的任務
“處理模型”英文是“Process Model”，Process在IT裏麵又叫“進程”，雖然和進程相關，但直接叫“進程模型”會誤導大家，所以我叫它“處理模型”，也就是和處理相關的設計。我們來看看“處理模型”階段的任務：
1）進程、線程設計；
2）子係統設計；
為什麼需要“處理模型”呢？相信看到上麵的任務後，聰明的你應該已經知道了原因：
1）隨著係統規模增大，處理性能要求增加，必須采用多進程多線程處理方式；
2）隨著係統規模增大，複雜度增加，加上需要考慮可擴展性、可測試性、可靠性等質量屬性，必須采用“分而治之”的方式劃分子係統（注意此時還不是架構設計，欲知詳情，請關注下一篇博文）；
l 為什麼現在才開始進行進程、線程、架構設計？
講到這裏，估計很多朋友都有疑惑了：按照一般的經驗，都是最開始就要進行子係統設計、進程線程設計的，怎麼你的這個流程到現在才開始進行進程、線程、子係統設計呢？
我們知道：進程、線程、子係統設計都必須有基礎，而不是憑空創造或者想象出來的。那種所謂的先畫一個圈表示係統、然後再在這個圈下麵畫幾個圈表示子係統、子係統下麵再畫幾個圈表示進程或者線程的自頂向下的設計方式就像“浮沙築高台”，其實是完全行不通的，為什麼呢？
因為這個時候劃分子係統沒有任何可靠的依據。架構設計、子係統設計、進程線程設計主要是為了解決性能、可靠性、可擴展性、可測試性、安全性等質量屬性，而不是客戶主要關注的功能屬性。性能、可靠性、安全性可以從客戶獲得，但無法像功能屬性那樣一步一步的映射到代碼（客戶說要“每秒支持10000個交易”，然後你畫了三個圈，說“這樣就可以達到每秒10000個交易”，誰會相信呢？），而可擴展性、可測試性在客戶需求階段根本不會體現。所以我們必須等到“實現模型”完了之後再進行進程、線程、子係統設計、架構設計。
可能大家還有疑問：按照你這個說法，豈不是要等到係統全部編碼完成後再來進行進程、線程、架構設計？
回答這個問題的關鍵詞就是“迭代”，第一個迭代（一般都叫做Demo）把最主要、最核心、最關鍵的需求按照“用例模型”->“領域模型”-> “設計模型”-> “實現模型”->“處理模型”走一遍流程，這樣第一個迭代就可以把架構、子係統、進程、線程初步設計完畢，後續的迭代基本上隻要走“用例模型”-> “設計模型”-> “實現模型”就可以了，即使有調整也不會太大，因為第一個迭代式把最主要、最核心、最關鍵的需求給實現了。
l 具體如何操作？
我們來看如何基於“實現模型”進行進程、線程、架構設計：
1）第一步：將已有的對象進行分組；
分組的原則其實就是大家常見的“高內聚、低耦合”，把最相關的、聯係最緊密的對象劃分到同一組；
2）第二步：將多個組劃分為進程、線程；
將對象組再分組劃分到具體的進程和線程，分組的原則主要看性能要求（響應時間、吞吐量），性能數據可以基於已有的“實現模型”進行評估或者測試。
3）第三步：設計進程的同步、通信；
既然是多進程、多線程，就必須設計出進程間同步和通信方式。
4）第四步：將進程劃分到不同的子係統；
結合根據“高內聚、低耦合”的原則、以及性能、可靠性、可擴展性、可測試性等質量屬性要求，將進程劃分到不同的子係統；劃分子係統也為下一個階段（賣個關子，先不說:-P）打下了基礎。
5）第五步：設計子係統間的同步、通信
和第三步類似，劃分為不同的子係統後，必須設計子係統間的同步和通信方式。
看起來步驟比較多，不過每個步驟其實都不難，簡單點說就是“排列組合”，將對象排列組合成進程線程，將進程排列組合成子係統。
千言萬語不如一個用例，我們還是繼續前麵的POST機樣例來看看“處理模型”階段如何操作吧。
經過“實現模型”階段後，我們的POST機可能是這樣實現的：“商品”、“交易”、“商品管理”、“商品清單”、“付款方式”、“店鋪”、“收銀機”、“VIP會員”、“供貨商”等對象了，接下來我們就要進行“處理模型”設計了：
1）第一步：將已有的對象進行分組；
1.1）“商品”“商品管理”都是商品相關的對象，因此劃為第一組，命名為“商品處理”；
1.2）“交易”“商品清單”“付款方式”都是和交易相關的對象，因此劃為第二組，命名為“交易處理”；
1.3）“店鋪”、“收銀機”都是係統靜態信息，因此劃為第三組，命名為“係統信息管理”；
1.4）“供貨商”、“VIP會員”都是第三方的管理信息，因此劃為第四組，命名為“第三方管理”
2）第二步：將多個組劃分為進程、線程；
初步評估，“商品處理”和“交易處理”的性能要求會很高（因為商品很多，交易也在不斷進行），而“係統信息”是一個基本靜態的信息，性能要求會很低，而“第三方管理”性能要求相對也不高，因此可以設計出3個進程：“商品處理”進程、“交易處理”進程、“信息管理”進程，其中“信息管理”進程負責 “係統信息管理”和“第三方管理” 兩組對象
3）第三步：設計進程的同步、通信；
進程間同步和通信和具體的實現有關，可以參考相關資料，例如Windows和Linux的可以參考我的博文《多核時代：並行程序設計探討（4）——Windows和Linux對決(進程間通信)》《多核時代：並行程序設計探討（5）——Windows和Linux對決(進程間同步)》。
4）第四步：將不同的進程劃分到不同的子係統；
第二步已經設計出三個進程了（實際情況會更多）：“商品處理”進程、“交易處理”進程、“信息管理”進程，因此可以劃分為三個子係統：商品管理係統、交易係統、信息係統。其中“信息係統”負責“係統信息管理”和“第三方管理”。
注意：由於此樣例比較簡單，所以出現了進程和子係統一一對應的情況，實際工作中應該是一個子係統包含1至多個進程。
5）第五步：設計子係統間的同步、通信
和第三步類似，劃分為不同的子係統後，必須設計子係統間的同步和通信方式。
由於子係統可以是進程、線程，也可以是獨立運行的程序，因此子係統間通信方式也隨著實現方式不同而不同。例如程序間通信可以采用共享文件、共享內存、Socket等方式。
====================未完待續，後麵更精彩==========================
最後更新：2017-04-02 04:01:45