設計的目的是什麼？它和uml是怎樣的關系？在程式猿（媛）的工作中，設計是如何開展的？
帶着這些疑問，請各位在本文中細細品嘗，相信大家能夠從作者的思想中找到答案。
設計的目的在于從現實世界中發現問題，經過抽象轉化，變成機器世界了解的需求，最終由軟體程式來完成。
而設計的過程，我們期望是可以模型化的（可複用），而描述這個模型的方法，我們稱之為模組化語言。在百家争鳴的初期，模組化語言超過50種。
uml：unified model language，統一模組化語言。分久必合，模組化語言經過多年的發展，逐漸向統一演進，uml逐漸成為設計模組化的首選方法。
上圖是uml常用的幾個設計圖形，通過這幾個圖形，我們是如何完成設計模組化的工作的？
經典的設計模組化過程是4+1模型，感興趣的大家可以在網上查閱一下。本文中根據作者自身的設計經曆，将設計模組化過程稍作修改，變成上述三個過程：業務模組化、領域模組化、行為模組化。
業務模組化一般指的是描述需求的模型，為了描述需求，我們需要重點把握兩條主線：<b>價值動機和價值假設</b>。福特汽車創始人亨利福特說過一句經典名言“如果問使用者要什麼？那使用者希望是更快的馬車，而不是汽車”這句話說明了兩個内容，需求是需要挖掘，而不是使用者告訴你（這裡需要挖掘需求的價值動機是更快的速度），另一方面則是在産品未開發之前，你需要領域專家來假設産品是能夠滿足需求的（這裡的價值假設是汽車比馬車更快），根據這兩條主線，我們如何開展業務模組化？
用例圖是描述需求最常用的方法，此處忽略系統邊界要素（作者認為這個不是很難）。
使用用例圖描述需求首先需要識别産品的使用者角色，然後根據使用者角色來挖掘其價值動機，并賦予實際場景（功能）來假設滿足角色的需求。同時還需要識别假設的場景（功能）對外部的依賴性，決策其是否可行（依賴因素越多，其代價越大，可行性越低）。
分享：京東需求模型是由市場評估需求的價值，由研發評估需求實作的成本，最終根據成本效益來決定需求的優先級。
上述描述的業務模組化中，經常會犯以下幾個錯誤
1)描述功能，而不是描述價值。價值是能被直接了解的，而功能還需要進一步啟發。例如一個查詢告警的功能，對研發人員，它的價值是定位問題，對統計人員，它的價值是統計故障率。是以用例圖中盡量描述價值。
2)過早細化需求。業務模組化除了用例圖，一般還可以輔助序列圖、活動圖來描述需求，然而這需要根據業務情況來分析，我們隻需抓住一點：是否有利于識别價值？對于erp系統來說，業務流程的每個節點都有重要的使用者角色參與，則其輔助序列圖描述對價值識别是非常有用的。對于一些整機産品來說，使用者角色一般不知道産品内部的構造，是以細化需求大可不必。
3)用例圖流程化。例如一個異常場景，會讀取告警，再讀取日志，那麼則可以用一條語句描述清楚，或者輔助序列圖、活動圖來描述。不建議分出多個子用例來描述這個過程（它會對價值識别産生幹擾，特别是用例比較多的時候）
上圖描述領域模組化過程主要從領域知識源（實際的對象），經過領域分析，最後轉換成系統、包、類等分析模型（領域對象）。
本處作者的建議是多開闊眼界，學習已有的領域模型（例如分層架構、設計模式，幫後面的教育訓練做個廣告^_^），并思考這些領域模型是否可以解決我們的問題。
目前的領域模型經過多年的發展，工作中大部分的問題都能尋找到好的模型解決。是以作者更鼓勵“微創新”，例如設計模式應用到解決問題中，這是“微創新”；多種設計模式組合應用，這是“微創新”；将已有的領域模型結合項目情況形成新的領域模型，這同樣是“微創新”（作者曾經有過一個階段，總想自己創造一個模型，借用一句話，簡單的事情，想複雜了，最後覺得自己很低能-_-!）
行為模組化包括序列圖、活動圖，除此之外，作者還加入了狀态圖，這主要是因為如果沒有互動關系模型的建立，需要直接識别出狀态關系，會十分困難，而且容易出錯（如果業務模組化有流程圖，則可以先識别狀态關系）。
回到行為模組化，在設計層次上一般分為概要和詳細設計。但是工作中，往往覺得寫兩種設計比較備援，結果會将兩個層次的設計混在一起，實際上這是存在風險的，作者對這種文檔的評價是基本沒人看。
曾經有開發人員對設計人員建議“先别設計與xx系統的互動流程，現在還無法确定xx系統準備怎麼做”，結果設計文檔把内部的流程設計完了，空留下外部接口未設計。然後。。。就沒有然後了，等xx系統的互動流程确定後，原來的流程也需要更改，但基本沒人會返工修改，這篇設計文檔經過設計、評審、歸檔等大量人力代價，結果變成一篇廢文檔。
對于這種現象，作者的建議是先在業務模組化時确定好依賴關系，确定要不要做。确定要做以後，則在概要層面使用序列圖分析好系統級别的互動關系，經評審确認可行後，最後進行系統内的詳細設計。詳細設計作者建議使用活動圖，其靈活性更大，更易于描述細節。
1) 實踐出真理，設計能力的提升是基于不斷的鍛煉。曾經有位設計的同僚說過“設計缺少的不是知識，缺少的是鍛煉”。在工作中，程式員往往不被要求寫設計文檔，但這不是借口。作者過往接觸到非常多的由se完成的概要設計文檔，但是作為特性的owner，作者有強烈的想法，想用自己的語言将其描述出來，是以形成了對應的詳細設計文檔。而這個過程就是不斷的重複前面的過程，讓自己的設計能力得到不斷的鍛煉提升。
2) 那些年我們追過的優秀設計，擴充眼界，站在巨人的肩膀才能看的更遠。簡單的看書是枯燥的，學以緻用才能培養興趣。（用不到怎麼辦？自己想辦法創造，例如多和同學們溝通，到技術論壇上發帖，更多碰撞讓眼界更開闊）
3) 時不時重溫一下自己寫過的設計，優化歸納，紮實的向上走。（這點真的很難，但是看到自己寫的設計文檔變成廢物會讓作者更加難受，正是這點強迫作者不斷的更新維護自己寫過的設計，而這個過程也是在不斷的為自己創造鍛煉的機會）
<b> </b><b> 中生代技術分享群微信公衆号</b>
本文作者 <b>鼎橋通信 符章文</b>