滴！學生卡（憋縮話，不服來戰！）老司機們快上車啦，咱們今天聊聊流程開發的事兒。當然，此流程非彼流程，睜大雙眼咱們一起去發現流程開發之美......本文嚴格面向技術開發人員，力争為大家帶來飛一般的感受。come on，一起來指點江山揮斥方遒，武裝大腦，淬煉軀殼，洗滌靈魂，朝着升職加薪、迎娶白富美、榮升ceo、走上人生巅峰之路上大步邁進吧。
ps：據說有人按耐不住蠢蠢欲動的心靈，公然求放妹紙靓照！像我這麼正直無畏、三觀嚴謹的人......當然無底線滿足你啦，不多說，上照。
好了好了，言歸正傳，咱們可是正經人。
<b>讓技術人員看得懂的流程（1）——面向對象設計全流程概述</b>
談到流程，大家都會想到熟悉的瀑布模型、螺旋模型、疊代開發、靈活、rup等一堆軟體工程相關的軟體開發流程，但是請不要誤會，本文的流程和這些管理流程完全不同，為了以示區分，我把瀑布模型、靈活、rup等流程成為項目流程，也就是說這是給項目管理用的；而本文的流程是技術流程，是給技術人員（主要是設計人員）看的流程。
下面将通過幾篇短的博文和一個執行個體來簡明概要的講述這個流程，概要來說主流程如下：用例模型>領域模型>設計模型>實作模型>程序模型>部署模型。執行個體就用一個簡單的pos機系統來講解。
欲知詳情如何，且聽下回分解！
<b>讓技術人員看得懂的流程（2）——用例模型</b>
一般的管理流程都将軟體項目劃分為“需求>分析>設計>實作>維護”，對應的技術流程中首先也肯定是要将需求明确，而“用例模型”就是用于獲得和分析需求的。簡單來說，用例模型就是要将客戶的需求寫下來。“需求”不是很好了解，更加通俗的講法是“故事(story)”。
下面我把用例模型階段容易犯的錯誤重點說明一下：
1.“需求”和“功能”混淆：需求是對客戶有價值的東西，功能是為了實作需求而作的東西；
2.在用例模型階段進行系統分解：用例模型關注的是使用者需求，不需要進行系統分解，把系統當做一個黑盒看待就可以了。
字不如表，表不如圖，因為圖可以一目了然的看出互動過程。用一句話總結就是：互動用圖形，說明用文字。
<b>讓技術人員看得懂的流程（3）——領域模型</b>
按照一般的項目管理過程，“需求”之後是“分析”，那麼在分析階段對應的技術流程又是哪個？如何将需求階段和分析階段聯系起來呢？答案就是“領域模型”。
讓我們來看看“領域模型”階段我們要做什麼、該怎麼做。簡單概括就是“找名詞”，分為四個步驟：
1.找出用例模型中的名詞；
2.然後識别這些名詞本身的相關資訊；
3.以及名詞之間的互相關聯關系；
4.用uml畫出領域模型。
經過“領域模型”分析後，可以完成自然語言到面向對象語言的初步轉化，領域對象已經識别出來，面向對象已經初具雛形。
ps一點：領域模型過程中識别出來的對象和具體的語言無關。換句話說，public、private、函數這些面向對象的屬性在領域模型階段不需要分析出來。
<b>讓技術人員看得懂的流程（4）——設計模型</b>
完成了“領域模型”階段後，面向對象已經初具雛形，我們已經看到了那熟悉的“對象”了，例如“商品”、“交易”、“商品清單”等，看起來已經進入了面向對象的世界了，你是否已經摩拳擦掌，躍躍欲試，準備開始編碼了呢？
且慢，“領域模型”隻是萬裡長征的第一步，通過領域模型分析得到的類還不能指導編碼，還需要經過“設計模型”這個階段的處理，才能基本上指導編碼。那莫，設計模型階段的任務都有哪些呢？
第一個任務就是“為對象添加方法”；
第二個任務是“圍繞領域對象設計出非領域對象”；
第三個任務就是“應用設計模式、設計原則”。
重要的一點是，以上的步驟不是瀑布式的，而是疊代式的，need action。
<b>讓技術人員看得懂的流程（5）——實作模型</b>
經過前面的“用例模型”、“領域模型”、“設計模型”的講解，面向對象分析設計都完了，面向對象已經基本成型，接下來就是要具體實作了，對應的就是“實作模型”。
“實作模型”是整個技術流程中大家接觸最多的階段，隻要是做開發的，基本上都是先參與這個階段的工作。顧名思義：實作模型就是使用具體的技術來實作設計，也就是通常意義上的編碼。但要注意的是，編碼不等于敲鍵盤，之是以稱為“實作模型”，因為這裡還是有設計的，隻不過這個設計和具體的實作技術有關。
由于具體的實作技術差别很大，是以沒有什麼通用的方法，“實作模型”階段需要大家積累具體的技術知識和經驗。
<b>讓技術人員看得懂的流程（6）——處理模型</b>
看完“實作模型”，你是否長籲一聲，準備拿起咖啡，惬意的喝上一杯？畢竟咱們已經完成了從用例到編碼的全過程了，确實是值得慶祝的一件事情，但“革命尚未成功、同志還需努力”啊，現在還不是享受的時候，接下來我們需要進入“處理模型”階段。“處理模型”英文是“process model”，process在it裡面又叫“程序”，雖然和程序相關，但直接叫“程序模型”會誤導大家，是以我叫它“處理模型”，也就是和處理相關的設計。我們來看看“處理模型”階段的任務：
1.程序、線程設計；
2.子系統設計。
我們來看如何基于“實作模型”進行程序、線程、架構設計：
第一步：将已有的對象進行分組：分組的原則其實就是大家常見的“高内聚、低耦合”；
第二步：将多個組劃分為程序、線程；
第三步：設計程序的同步、通信；
第四步：将程序劃分到不同的子系統；
第五步：設計子系統間的同步、通信。
<b>讓技術人員看得懂的流程（7）——部署模型（完結篇）</b>
在上一篇博文“處理模型”中已經提到：在“處理模型”階段劃分為子系統後，為下一階段打下了基礎。當時賣了個關子沒說具體是什麼，本篇就來揭開它的面紗：“部署模型”。“部署模型”英文是“deployment model”，正好對應uml中的“deployment diagrams”，有的文章或者書籍也叫“實體模型”。我之是以沒有用“實體模型”，是因為“實體模型”的概念容易誤解大家認為這個階段隻需要關注實體裝置，而“部署模型”相對更加全面。我們來看部署模型的任務：
1.确定部署實體，即采用什麼樣的實體裝置，例如pc機、伺服器、小型機；
2.确定部署方式，例如區域網路部署，企業網部署，網際網路部署；
3.确定部署連接配接，即組網方案，設計如何将這些實體裝置連接配接起來。
看不夠？還不快戳詳情連結！我戳戳戳......