在小公司做事的好處是終于可以眉毛胡子一把抓，來(lái)個(gè)全棧式控制，好吧，人人都有控制欲。
商業(yè)項(xiàng)目中的上游設(shè)計(jì)一旦展開，UML設(shè)計(jì)變成一個(gè)巨大的工程，每個(gè)設(shè)計(jì)者都被淹沒在UML中一根根線條，標(biāo)記符號(hào)，顆粒度的大小爭(zhēng)論，optional flow的全與不全，DB ER圖上字段的正則等等細(xì)節(jié)之中，這樣的設(shè)計(jì)往往會(huì)要三個(gè)月，大規(guī)模項(xiàng)目甚至6個(gè)月。
從Agile，Scram開始，個(gè)人的觀點(diǎn)UML完全可以簡(jiǎn)化下來(lái)，收縮在概要層次，然后在開發(fā)中細(xì)化或者也不一定去細(xì)化修改。
簡(jiǎn)要?dú)w納一下UML最小配置。
UML的關(guān)鍵點(diǎn)是要有映射關(guān)系，如同辭典一樣可以互相檢查，保證可以追蹤。
Usecase：
一般USECASE的文字記錄足夠了，因?yàn)閳D形還不如用業(yè)務(wù)流程圖去表示更清晰一些。
UC是對(duì)業(yè)務(wù)流程的歸納總結(jié)，是概要設(shè)計(jì)的基礎(chǔ)和源頭，包含了客戶的要件內(nèi)容（非性能要求不算）一般和客戶的IT部門溝通業(yè)務(wù)細(xì)節(jié)，主要靠UC。（UC技巧和注意事項(xiàng)在此不贅述，教科書太多）
UC中可以標(biāo)記出頁(yè)面和BusinessRule，為后面的詳細(xì)設(shè)計(jì)做準(zhǔn)備。
頁(yè)面是User Interface的重要部分，通常頁(yè)面的wireframe 設(shè)計(jì)在概要設(shè)計(jì)階段都會(huì)給出，這樣才能和沒有IT經(jīng)驗(yàn)的客戶做比較順暢的溝通。
BR是詳細(xì)的業(yè)務(wù)邏輯實(shí)現(xiàn)，一般僅對(duì)比較復(fù)雜的業(yè)務(wù)計(jì)算邏輯做BR，例如有算法實(shí)現(xiàn)或者業(yè)務(wù)邏輯細(xì)節(jié)非常復(fù)雜，或者要調(diào)用其他子系統(tǒng)進(jìn)行實(shí)現(xiàn)。
Sequence圖：
UC之后可以寫Sequence圖，在sequence 圖中非常重要的是需要識(shí)別object, 在MVC模型中則分為boundary, control and entity， 這些object 是今后類圖設(shè)計(jì)的基礎(chǔ)，中大型項(xiàng)目分為概念時(shí)序圖和分析時(shí)序圖，概念時(shí)序圖是給出概要Object，而分析時(shí)序圖中Object位置則出現(xiàn)的是實(shí)際的class 圖，和類圖要一一對(duì)應(yīng)。
此處的object識(shí)別將作為后面類圖設(shè)計(jì)的依據(jù)。
Class圖：
可以直接寫靜態(tài)類圖設(shè)計(jì)，但也可以一邊做時(shí)序圖的分析模型一邊將類中的method/function 剝離分析出來(lái)，再填入類圖，這樣可以保證關(guān)鍵的方法函數(shù)被包含。 類圖是詳細(xì)設(shè)計(jì)，設(shè)計(jì)過(guò)于繁瑣細(xì)節(jié)，會(huì)妨礙開發(fā)，或者說(shuō)這部分其實(shí)應(yīng)該由開發(fā)人員在開發(fā)中完善。
動(dòng)態(tài)生成類圖文檔可以直接將這步覆蓋，但是對(duì)于類的分類和粒度選定，確實(shí)一定要在設(shè)計(jì)過(guò)程中定下。
通常Object可以是Classe圖中的父類、基類、抽象類的基準(zhǔn)。
BR：
BR（business rule) 需要在分析時(shí)序圖中和類方法函數(shù)標(biāo)注對(duì)應(yīng)，基本確定下來(lái)在什么類中實(shí)現(xiàn)哪部分BR，因?yàn)轭惖闹赜迷O(shè)計(jì)和BR放在何處有緊密聯(lián)系，如果做得不夠好會(huì)導(dǎo)致大量代碼的拷貝，重復(fù)寫。
BR當(dāng)中需要break down 的是： API （調(diào)用外部接口） 和 Message （和其他子系統(tǒng)通訊）
有些項(xiàng)目會(huì)另外做個(gè)對(duì)API和Msg的匯總，便于倒過(guò)來(lái)檢查。
頁(yè)面設(shè)計(jì)+遷移圖：
頁(yè)面設(shè)計(jì)非常重要，這部分是和客戶溝通的基礎(chǔ)，而數(shù)據(jù)又和背后的數(shù)據(jù)庫(kù)，數(shù)據(jù)模型連攜。
頁(yè)面的wireframe 將頁(yè)面功能基本理出來(lái)。這部分頁(yè)面設(shè)計(jì)和美工無(wú)關(guān)，主要是功能性整理，并要決定有些頁(yè)面狀態(tài)更新是否會(huì)向后臺(tái)傳送數(shù)據(jù)，在前端技術(shù)發(fā)展迅猛的當(dāng)下，很多功能處理在前端完成，因此這部分的設(shè)計(jì)需要前端開發(fā)經(jīng)驗(yàn)。
頁(yè)面設(shè)計(jì)+頁(yè)面遷移圖，完整說(shuō)明客戶界面和流程。
狀態(tài)遷移圖：
對(duì)于一些和流程相關(guān)的程序，需要專門寫一下狀態(tài)遷移圖，并定義狀態(tài)標(biāo)志，這些標(biāo)志有的是中間暫時(shí)狀態(tài)，數(shù)據(jù)在過(guò)程中被銷毀，有的則需要計(jì)入數(shù)據(jù)庫(kù)或者數(shù)據(jù)模型以便于跟蹤。
狀態(tài)的標(biāo)志要和各個(gè)類中的關(guān)鍵屬性以及DB的字段做好對(duì)應(yīng)。
數(shù)據(jù)庫(kù)ER圖：
這部分是對(duì)前面的綜合概括，通常ER和類圖有映射關(guān)系，POJO，OR映射關(guān)系反應(yīng)了這種關(guān)系，MVC模型也被流行很久，但除此之外，要考慮batch 對(duì)數(shù)據(jù)庫(kù)的修改，但這些通?？梢钥醋鍪呛笈_(tái)操作。
項(xiàng)目的估算：
估算是門非常古老的藝術(shù)，對(duì)，我說(shuō)的是藝術(shù)，不是技術(shù)。
綜上所述，開發(fā)工數(shù)估算應(yīng)該包含：
類的開發(fā)工數(shù)估算（包括BR的復(fù)雜度）
頁(yè)面復(fù)雜度，包括頁(yè)面遷移帶來(lái)的batch 實(shí)現(xiàn)難度
外部接口調(diào)用復(fù)雜度
外部通訊msg 的復(fù)雜度
測(cè)試一般以比例計(jì)算，但是系統(tǒng)間測(cè)試最好單獨(dú)考慮一下。
所謂估算的藝術(shù)，是要在以上邏輯性的考慮上再考慮一下客戶的預(yù)算，橫向的比較，此處不做贅述。
為什么需要UML？
對(duì)于業(yè)務(wù)應(yīng)用的開發(fā)，UML是業(yè)務(wù)層和技術(shù)開發(fā)層的橋梁，也可以防止功能的遺漏，以及功能需求的曖昧，最終落實(shí)到技術(shù)語(yǔ)言層面。
對(duì)于一些Framework型的項(xiàng)目，最重要的是做好接口的整理。
從技術(shù)角度出發(fā)的人，可能是從類圖的topdown設(shè)計(jì)開始，而UML是從業(yè)務(wù)角度，客戶需求角度的視角開始。
如何簡(jiǎn)化UML？
1）BR如果可以獨(dú)立讓開發(fā)人員定下來(lái)，可以省略，或者僅做簡(jiǎn)單的標(biāo)識(shí)。
2）關(guān)鍵method 和屬性之外，可以省略
3）分析時(shí)序圖可以省略，僅留概念時(shí)序圖
4）DB的ER圖可以過(guò)后補(bǔ)全，但是基本框架要在
5）可以在頁(yè)面表示的一些機(jī)能以及動(dòng)態(tài)聯(lián)系，可以在時(shí)序圖和UC中寫得較為省略
