原文地址：http://www.uml.org.cn/zjjs/201305172.asp
談到流程，大家都會想到熟悉的瀑布模型、螺旋模型、迭代開發、敏捷、RUP等一堆軟體工程相關的軟體開發流程，但是請不要誤會，本文的流程和這些管理流程完全不同，為了以示區分，我把瀑布模型、敏捷、RUP等流程成為專案流程，也就是說這是給專案管理用的；而本文的流程是技術流程，是給技術人員（主要是設計人員）看的流程。
在開始講解之前，看看如下問題你是否能夠回答？
1、客戶的需求是描述性的，例如“我們需要一個POS機”，而程式碼是一個一個具體的類和函式，那麼如何從描述性的語言最後轉化到具體的類和函式呢？
2、具體語言的特性，例如Java和C++的private、protected、public這些屬性是從哪裡來的？什麼時候設計的？
3、不管什麼程式碼，最後都要執行在具體的平臺上，如Windows、Linux、UNIX等，那麼這些平臺相關的程式、執行緒什麼時候設計、如何設計？（不要說你所有的產品都是單執行緒或者單程式哈：-P）
4、如果是稍微大一點的產品，需要執行在多臺機器上，那麼如何確定需要多少機器？如何分工？
怎麼樣？以上這些問題是否似曾相識，或者自己是否考慮過？
如果你的第一反應是去翻開《軟體工程》、RUP、敏捷開發等相關著作，那麼我可以很肯定的告訴你你會失望的，就像前面提到的，這些東西不是管理流程的事情，而是技術流程的事情。
如果你心有疑問，或者不敢肯定自己的答案，那麼“不懂的人有福了”，因為我將通過幾篇短的博文和一個例項來簡明概要的講述這個流程，概要的講，主流程如下：
用例模型->領域模型->設計模型->實現模型->程式模型->部署模型
一般的管理流程都將軟體專案劃分為“需求->分析->設計->實現->維護”，對應的技術流程中首先也肯定是要將需求明確，而“用例模型”就是用於獲得和分析需求的。
簡單來說，用例模型就是要將客戶的需求寫下來。“需求”不是很好理解，更加通俗的講法是“故事(story)”。我覺得“故事”這個詞非常好，非常形象，非常容易理解！我們看看為什麼“故事”更加容易適合說明客戶要求：
（1）故事中有很多角色，而需求中也有很多角色；
（2）故事有具體的經過，有開始、進行、結束；而需求也是一個完整的流程，有輸入、處理、輸出。
（3）故事必須有意義，而需求對客戶來說，也是必須有意義的；
具體的用例格式等這裡就不詳細描述了，大家上網搜尋一下就知道了，如何更好的把握需求可以參考我的博文《需求分析的故事——如何練就需求分析的火眼金晴？》，下面我把用例模型階段容易犯的錯誤重點說明一下。
1）“需求”和“功能”混淆
很多朋友在分析需求的時候，將“功能”和“需求”混淆起來，導致了需求的粒度不合理，或者把握不住重點的需求，我總結出一個很簡單的區分辦法：“需求是對客戶有價值的東西，功能是為了實現需求而作的東西”。
以POS機為例：對於客戶來說，“買單”是一個有價值的東西，因為客戶買完單就可以把商品拿走了；而買單過程中的“讀商品條形碼”、“計算商品總額”、“列印購物清單”等都是功能，因為它們當中任何一個獨立的功能對客戶沒有價值（你不會跑到超市“讀商品條形碼”玩吧:-P），只是為了實現“買單”而做的。
2）在用例模型階段進行系統分解
除了容易將“功能”和“需求”混淆外，用例模型階段還有一個常見的錯誤就是在用例模型階段對系統進行分解。
以POS機為例，有的人將需求描寫為：掃描機掃描商品條形碼資訊，然後將資訊發給庫存系統，庫存系統返回詳細的商品資訊給交易系統……在用例模型階段這樣做是不對的，因為這樣轉移了我們的注意力：從關注使用者需求轉到了系統分析了。
記住：用例模型關注的是使用者需求，不需要進行系統分解，把系統當做一個黑盒看待就可以了。
下面我們給出POS機一個簡單的用例片段，有興趣的可以自己寫一個完整的（這個完整的可不簡單哦，至少可以寫3頁）：
1）顧客攜帶商品到收銀臺；
2）收銀員掃描商品條形碼；
3）系統根據條形碼獲取並顯示商品資訊；
4）收銀員重複2~3步，直到所有商品掃描完畢；
5）系統計算商品總額；
n）系統打出商品清單，完成交易。
SSD即系統順序圖，目的就是站在系統的角度，以UML的順序圖來描述系統與“外部實體”（包括人、其它系統、輸入輸出裝置）的互動過程，簡單來說就是“圖形化的用例”。
那為什麼有了文字化的用例文件，還要圖形化的SSD呢？其實很簡單：字不如表，表不如圖，因為圖可以一目瞭然的看出互動過程。
可能有的朋友又要問了：既然圖那麼好，還要文字描述的用例做什麼呢？有兩個原因：第一個是客戶不會用UML給你描述需求，客戶只會用自然語言描述需求；第二個就是圖形的優點是簡潔、一目瞭然，但圖形的缺點就是不能承載太多資訊，詳細和豐富的資訊還是要文字來承載。
用一句話總結就是：互動用圖形，說明用文字！
那麼，是否一個用例就要寫一個SSD呢？基本上不需要，因為SSD重點在描述系統的互動過程，如果用例本身沒有什麼互動、或者互動很少或者很簡單，就不需要SSD。只有主要的、複雜的用例才需要SSD。
按照一般的專案管理過程，“需求”之後是“分析”，那麼在分析階段對應的技術流程又是哪個？如何將需求階段和分析階段聯絡起來呢？答案就是“領域模型”
什麼是“領域模型”呢？只要抓住“領域（Domain）”二字就可以理解，也就是說領域模型是幫助我們理解相關領域知識的模型。
進一步來問：為什麼需要領域模型？前面不是有“用例模型”嗎，看起來用例模型好像就是描述相關領域知識的，是否完成用例模型就可以進行設計了？
如果你曾經寫過用例文件，或者仔細看過用例文件，那麼你肯定知道“用例”本身和“物件導向”、“類”這些都沒有關係，用例就是純自然的語言（比如英語、漢語）寫的，因為用例實際上由客戶口述給我們、然後由我們形成文件化的用例文件，客戶才不管我們是什麼物件導向還是程式導向還是阿貓阿狗的。
因此，單純從用例來看，是沒有類的概念的，無法完成從自然語言到面嚮物件語言的轉換。但是，既然我們已經完成了用例模型，那麼就必須基於用例模型進行分析(否則用例模型豈不是白做了)，而“領域模型”就是自然語言向面嚮物件語言的一座橋樑。
讓我們來看看“領域模型”階段我們要做什麼、該怎麼做。其實很簡單，簡單概括就是“找名詞”，分為四個步驟：（1）找出用例模型中的名詞，（2）然後識別這些名詞本身的相關資訊，（3）以及名詞之間的相互關聯關係，（4）用UML畫出領域模型。
我們來看在“用例模型”章節中的POST用例如何得出領域模型。
第一步：找出用例模型中的名詞
原有用例如下，用藍色加黑標出名詞（重複的就不標了）：
1）顧客攜帶商品到收銀臺；
2）收銀員掃描商品條形碼；
3）系統根據條形碼獲取並顯示商品資訊；
4）收銀員重複2~3步，直到所有商品掃描完畢；
5）系統計算商品總額；
n）系統打出商品清單，完成交易。
這個用例中的名詞有“顧客”、“商品”、“收銀臺”、“收銀員”、“商品條形碼”、“系統”、“商品資訊”、“商品總額”、“商品清單”、“交易”。稍加整理：
1）“顧客”、“收銀員”是系統的外部物件，不需要我們進行設計，但這些物件要和系統進行互動；
2）“商品”、“商品條形碼”、“商品資訊”、“商品總額”、“商品清單”、“交易”是領域物件，但“商品條形碼”、“商品資訊”可以算作“商品”的屬性、“商品總額”可以算作“交易”的屬性，最後從這個用例總結出來的領域物件有“商品”、“商品清單”、“交易”三個。
第二步：識別這些名詞本身的相關資訊
一個物件的屬性可能分佈在多個用例中，因此可以通過迭代不斷的完善一個物件的屬性，大家可以看到，我們在第一步中的樣例就已經分析了一部分了：“商品條形碼”、“商品資訊”可以算作“商品”的屬性。
物件除了屬性外，還有一些約束或者限制，這些在用例中可能有，也可能沒有，這就需要分析人員來發現了。比如說交易金額必須大於0.1元小於99999元這種約束，用例中不一定會體現，可能需要分析人員向客戶諮詢。
第三步：識別物件間的關係
物件導向設計就是依靠物件間的互相協作來配合完成相應的功能，因此識別出物件和物件本身的屬性外，還要識別物件間的關係，例如1對多、1對1、依賴等，詳細的各種關係可以參考UML的標準定義。
我們以第一步識別的三個物件為例：“商品清單”包含多個“商品”、一次“交易”對應一個“商品清單”、一個“商品”只能屬於一個“交易”等。
第四步：畫出領域模型UML圖
UML這裡就不囉嗦了，我們結合前三步的分析，畫出這個樣例的UML領域模型圖：
（由於CSDN關閉了圖片上傳功能，因此無法貼出，大家可以根據前三步自己畫一個）
大家可以看到，經過“領域模型”的分析後，已經完成了自然語言到面嚮物件語言的初步轉化了，領域物件已經識別出來，物件導向已經初具雛形。
需要提醒的是：領域模型過程中識別出來的物件和具體的語言無關，也沒有方法。換句話說，public、private、函式這些物件導向的屬性在領域模型階段不需要分析出來。
完成了“領域模型”階段後，物件導向已經初具雛形，我們已經看到了那熟悉的“物件”了，例如“商品”、“交易”、“商品清單”等，看起來已經進入了物件導向的世界了，你是否已經摩拳擦掌，躍躍欲試，準備開始編碼了呢？
且慢，“領域模型”只是萬里長征的第一步，通過領域模型分析得到的類還不能指導編碼，還需要經過“設計模型”這個階段的處理，才能基本上指導編碼。
前面我們提過，領域模型的物件是沒有方法的，但最終的實現肯定是有方法的，因此設計模型的第一個任務就是“為物件新增方法”。
那麼是否給領域模型中的物件新增完方法就算是完成了設計模型呢？沒有這麼簡單，給領域模型中的物件新增方法只是設計模型中最簡單的一部分工作，設計模型階段第二個任務是“圍繞領域物件設計出非領域物件”。
這句話看起來比較難拗口，為什麼要設計出非領域物件呢？道理很簡單：領域模型中的物件是靜態的，要讓這些靜態的物件動起來，才能最終完成客戶需求。因此必須新增非領域物件，讓這些非領域物件來完成讓領域物件動起來的事情。
例如：“商品”本身是一個領域物件，但是這個物件是誰建立、誰使用、誰管理呢？領域模型中並沒有相關的物件來完成這些職責，因此需要我們設計額外的物件來完成這些職責。
經過前兩步之後，看起來設計模型的物件都已經出來了，但是我們如何知道設計得好還是不好，以什麼標準來判斷我們的設計是否正確呢？相信基礎紮實的朋友們已經想到了，這就是萬人期待、萬眾矚目的，大家都耳熟能詳的一個東東：設計模式。設計模型第三個任務就是“應用設計模式、設計原則”。
通過應用設計模式、設計原則，又會新增一批新的物件，介面、父子類、繼承、依賴等物件導向的相關概念也逐步清晰，這樣就為最終的編碼打下了堅實的基礎。
到這裡為止，“設計模型”階段的任務基本講述完了，下面我們看一個簡單的樣例，還是以POST機為例：
在“領域模型”階段我們已經分析出了“商品”、“商品清單”、“交易”三個領域物件，我們按照前面所講的三個步驟一步一步來看“設計模型”階段如何做（都以“商品”物件為例）。
第一步：“為物件新增方法”
商品物件的方法有：“獲取名稱”、“獲取條形碼”、“獲取價格”等（有興趣的朋友可以自己完善），這樣物件的幾個方法就出來了：getName（）、getBarCode（）、getPrice（）。
第二步：“圍繞領域物件設計出非領域物件”
“商品”物件的生命週期包括：建立、修改、使用、銷燬，這些任務物件本身是無法完成的，必須新增新的物件來完成，這裡我們新增一個新的物件“商品管理”來完成這些任務。這樣“商品管理”物件就出來了，而這個物件在用例模型和領域模型中都是沒有的。
第三步：“應用設計模式、設計原則”
我們簡單的應用DIP原則（可以參考我的Blog《軟體設計漫談之三：30分鐘掌握物件導向類的設計原則》）就可以發現，“商品”本身應該作為一個介面，因為不同的商品之間是有很大差異，“商品”又可以分為“食品類商品”、“飲料類商品”、“服裝類商品”等等。這樣應用了設計原則後，在領域模型中作為物件的“商品”，在設計模型中不再是具體物件，而是介面，然後這個介面派生出“食品類商品”、“飲料類商品”、“服裝類商品”等具體物件。
以上的步驟不是瀑布式的，而是迭代式的，例如：第三步識別出“飲料類商品”這個物件後，也需要為它新增方法、設計出相關的類。
經過前面的“用例模型”、“領域模型”、“設計模型”的講解，物件導向分析設計都完了，物件導向已經基本成型，接下來就是要具體實現了，對應的就是“實現模型”。
“實現模型”是整個技術流程中大家接觸最多的階段，只要是做開發的，基本上都是先參與這個階段的工作。顧名思義：實現模型就是使用具體的技術來實現設計，也就是通常意義上的編碼。
但要注意的是，編碼不等於敲鍵盤，之所以稱為“實現模型”，因為這裡還是有設計的，只不過這個設計和具體的實現技術有關。
例如：Interface在C++中沒有，而Java中就有，具體編碼的時候如果要實現設計圖中的interface，那麼就只能分別如下實現：
1）C++：宣告沒有成員變數、所有成員函式都是純虛擬函式的Class；
2）Java：直接宣告為interface。
由於具體的實現技術差別很大，因此沒有什麼通用的方法，“實現模型”階段需要大家積累具體的技術知識和經驗。
看完“實現模型”，你是否長吁一聲，準備拿起咖啡，愜意的喝上一杯？畢竟我們已經完成了從用例到編碼的全過程了，確實是值得慶祝的一件事情，但“革命尚未成功、同志還需努力”，現在還不是享受的時候，接下來我們需要進入“處理模型”階段。
- “處理模型”階段的任務
“處理模型”英文是“Process Model”，Process在IT裡面又叫“程式”，雖然和程式相關，但直接叫“程式模型”會誤導大家，所以我叫它“處理模型”，也就是和處理相關的設計。我們來看看“處理模型”階段的任務：
1）程式、執行緒設計；
2）子系統設計；
為什麼需要“處理模型”呢？相信看到上面的任務後，聰明的你應該已經知道了原因：
1）隨著系統規模增大，處理效能要求增加，必須採用多程式多執行緒處理方式；
2）隨著系統規模增大，複雜度增加，加上需要考慮可擴充套件性、可測試性、可靠性等質量屬性，必須採用“分而治之”的方式劃分子系統（注意此時還不是架構設計，欲知詳情，請關注下一篇博文）；
- 為什麼現在才開始進行程式、執行緒、架構設計？
講到這裡，估計很多朋友都有疑惑了：按照一般的經驗，都是最開始就要進行子系統設計、程式執行緒設計的，怎麼你的這個流程到現在才開始進行程式、執行緒、子系統設計呢？
我們知道：程式、執行緒、子系統設計都必須有基礎，而不是憑空創造或者想象出來的。那種所謂的先畫一個圈表示系統、然後再在這個圈下面畫幾個圈表示子系統、子系統下面再畫幾個圈表示程式或者執行緒的自頂向下的設計方式就像“浮沙築高臺”，其實是完全行不通的，為什麼呢？
因為這個時候劃分子系統沒有任何可靠的依據。架構設計、子系統設計、程式執行緒設計主要是為了解決效能、可靠性、可擴充套件性、可測試性、安全性等質量屬性，而不是客戶主要關注的功能屬性。效能、可靠性、安全性可以從客戶獲得，但無法像功能屬性那樣一步一步的對映到程式碼（客戶說要“每秒支援10000個交易”，然後你畫了三個圈，說“這樣就可以達到每秒10000個交易”，誰會相信呢？），而可擴充套件性、可測試性在客戶需求階段根本不會體現。所以我們必須等到“實現模型”完了之後再進行程式、執行緒、子系統設計、架構設計。
可能大家還有疑問：按照你這個說法，豈不是要等到系統全部編碼完成後再來進行程式、執行緒、架構設計？
回答這個問題的關鍵詞就是“迭代”，第一個迭代（一般都叫做Demo）把最主要、最核心、最關鍵的需求按照“用例模型”->“領域模型”-> “設計模型”-> “實現模型”->“處理模型”走一遍流程，這樣第一個迭代就可以把架構、子系統、程式、執行緒初步設計完畢，後續的迭代基本上只要走“用例模型”-> “設計模型”-> “實現模型”就可以了，即使有調整也不會太大，因為第一個迭代式把最主要、最核心、最關鍵的需求給實現了。
- 具體如何操作？
我們來看如何基於“實現模型”進行程式、執行緒、架構設計：
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等方式。
在上一篇博文“處理模型”中已經提到：在“處理模型”階段劃分為子系統後，為下一階段打下了基礎。當時賣了個關子沒說具體是什麼，本博就來揭開它的面紗，這就是：“部署模型”。
- “部署模型”階段的任務
“部署模型”英文是“Deployment Model”，正好對應UML中的“Deployment Diagrams”，有的文章或者書籍也叫“物理模型”。我之所以沒有用“物理模型”，是因為“物理模型”的概念容易誤解大家認為這個階段只需要關注物理裝置，而“部署模型”相對更加全面。我們來看部署模型的任務：
1） 確定部署實體，即採用什麼樣的物理裝置，例如PC機、伺服器、小型機；
2） 確定部署方式，例如區域網部署，企業網部署，因特網部署；
3） 確定部署連線，即組網方案，設計如何將這些物理裝置連線起來；
- 具體操作步驟
1）確定部署實體
在“處理模型”階段我們已經將子系統劃分出來了，但如果你的系統效能、可靠性等質量屬性要求很高，那麼就需要進一步考慮將子系統再“排列組合”，分佈到不同的機器上去。
“排列組合”的原則還是和劃分子系統的第四步一樣：根據“高內聚、低耦合”的原則、以及效能、可靠性、可擴充套件性、可測試性等質量屬性要求，將子系統劃分到不同的機器上去。
簡單的說就是“一臺不夠用兩臺，兩臺不夠用三臺；PC不夠用工作站，工作站不夠用小型機”。那麼是不是機器數量越多越好，質量越高越好呢？也不盡然，因為還需要考慮成本的因素，這就需要架構師、設計師進行權衡了（可以參閱我的博文：《軟體設計漫談之一：什麼是軟體設計？》）。
2）確定部署方式
確定好“部署實體”後，就需要考慮部署方式，因為不同的部署方式決定了需要採用不同的網路裝置和組網方式。
常見的部署方式有：區域網部署、企業網部署、因特網部署，下面簡單的介紹一下：
（1） 區域網部署：俗稱LAN，即機器都在一個區域網內部，通過Hub、Lanswitch、網橋等連線，這是範圍最小的一種部署方式；
（2）企業網部署：金融、電信、物流等稍微大的公司都會有企業內部網，企業網內部還會劃分VPN等，通過路由器、交換機等進行連線，這是中等範圍的部署方式；
（3）因特網部署：相信大家對這個都很熟悉，最常見的就是網站，如Sina、CSDN等，需要向寬頻服務商如電信等申請因特網IP地址，這是範圍最廣的一種部署方式；
具體採用哪種方式呢？其實很簡單：客戶會告訴你的：）
當然客戶不會直接告訴你說“我們要採用企業網部署”，客戶會在需求中隱含描述出來，比如說“分公司將資料發給總公司”，這句話就隱含了要採用“企業網部署”或者“因特網部署”這種方式。
3）確定部署連線
確定好部署實體和部署方式後，就需要考慮如何將這些機器連線起來了，即常說的組網，這時就是TCP/IP大顯身手的時候，我們看看具體如何應用TCP/IP：
（1）確定IP地址：包括網段、子網掩碼、每臺機器的IP地址；
（2）確定連線方式：單連線、雙連線、四連線，至於八連線，好像還沒有見過：）
（3）確定連線裝置：連線裝置和部署方式有關，同時也和效能、可靠性有關。例如：區域網要求不高的可以用hub，要求再高點就要低端的Lanswitch了；企業網和因特網就需要路由器了。
千言萬語不如一個樣例，讓我們來看看POS系統在“部署階段”如何操作。在“處理模型”階段我們已經劃分出3個子系統了：商品管理系統、交易系統、資訊系統，我們基於這3個系統進行簡要分析：
1）確定部署實體
假設要買POS系統的超市的物流和庫存是集中管理，而交易是由各個分店分散管理，那麼“商品管理系統”和“資訊系統”可以部署在同一臺小型機上面（根據效能和可靠性等要求的不同，可能是兩臺、三臺甚至更多，樣例中我們假設一臺就夠了）。
“交易系統”由於是分散的，伺服器配置應該就夠了，每個分店一臺。
2）確定部署方式
從需求可以很容易看出：POS系統最好採用企業網部署的方式，因為有分店、有總店，這些分店和總店是分散的。
3）確定部署連線
IP地址的分配根據具體情況分配即可。根據部署方式可以推斷出需要採用路由器型別的裝置進行連線，而為了保證交易系統的可靠性（總不能網線一斷，超市就關門不做生意了吧），需要雙連線甚至是四連線。