讓技術人員看得懂的流程（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.2）“交易”“商品清單”“付款方式”都是和交易相關的對象，是以劃為第二組，命名為“交易處理”；

1.3）“店鋪”、“收銀機”都是系統靜态資訊，是以劃為第三組，命名為“系統資訊管理”；

1.4）“供貨商”、“vip會員”都是第三方的管理資訊，是以劃為第四組，命名為“第三方管理”

初步評估，“商品處理”和“交易處理”的性能要求會很高（因為商品很多，交易也在不斷進行），而“系統資訊”是一個基本靜态的資訊，性能要求會很低，而“第三方管理”性能要求相對也不高，是以可以設計出3個程序：“商品處理”程序、“交易處理”程序、“資訊管理”程序，其中“資訊管理”程序負責 “系統資訊管理”和“第三方管理” 兩組對象

程序間同步和通信和具體的實作有關，可以參考相關資料，例如windows和linux的可以參考我的博文《多核時代：并行程式設計探讨（4）——windows和linux對決(程序間通信)》《多核時代：并行程式設計探讨（5）——windows和linux對決(程序間同步)》。

4）第四步：将不同的程序劃分到不同的子系統；

第二步已經設計出三個程序了（實際情況會更多）：“商品處理”程序、“交易處理”程序、“資訊管理”程序，是以可以劃分為三個子系統：商品管理系統、交易系統、資訊系統。其中“資訊系統”負責“系統資訊管理”和“第三方管理”。

注意：由于此樣例比較簡單，是以出現了程序和子系統一一對應的情況，實際工作中應該是一個子系統包含1至多個程序。

由于子系統可以是程序、線程，也可以是獨立運作的程式，是以子系統間通信方式也随着實作方式不同而不同。例如程式間通信可以采用共享檔案、共享記憶體、socket等方式。

====================未完待續，後面更精彩==========================