前一篇對基本的UML概念和關係做了介紹，本節以作者目前從事的製造企業信息化行業中的“生產訂單管理”業務需求爲例，介紹業務分析是如何進行的。
關於計算類控制類系統不適用UML的看法
也有說法說計算類的系統軟件是用不着UML業務分析的。我覺得也對，也不對。覺得不對是因爲計算類系統其實也是可以套用主角、用例和活動這一思路的，具體參見《大象-Thinking in UML（第2版）》p223第三個討論。另外，第一次接觸UML，實踐UML的時候就是在做核電力學分析法設計系統時。雖然當時感覺這一套太麻煩了，但至少能最後分析清楚，搭建出非常好的程序結構。說對，是因爲計算類系統更加註重的是系統內部的算法邏輯，很少考慮人機交互，考慮人的因素。拿我的CAE開發爲例，所有的CAE開發和二次開發都是前處理、求解器、後處理三大模塊順序執行，不會考慮業務目標，主角和用例。在開發的時候，只需要注意能讓客戶把參數設置完成，求解的時候能正確處理理論方程保證求解正確，能正確展示出來就行了。至於用例、活動、場景描述等都不是重要的內容。
名詞解釋
UML最基本的目的就是“統一建模語言”，是爲了讓不同業務人員、軟件工程人員等參與系統建設的參與者能夠用統一的語言進行交流溝通，避免產生歧義和錯誤理解。這點對於企業信息化來說是非常重要。在這幾年的產品研發過程中，確實發現工業軟件研發的一大障礙就是跨學科的綜合性人才匱乏，各學科人才協作工作不容易，無法很好的互相理解。
在領域驅動開篇也是提到，一定要統一語言，並且要向業務側的專業名詞靠攏，清晰統一名詞非常重要。但如果要做到名詞統一，必須深刻理解每個詞組甚至每個字的意思，才能精準的代表一類事物。這就要求較高的語文素養，有深究的意願。但需要注意的是，最後不要陷入文字遊戲的境地。我語文水平一般，只能模糊的給出以下兩個名詞的解釋：
生產訂單是指成品或半成品的生產指令；
生產任務是指現場人員可以具體執行的生產指令；
明確業務目標
對於製造業來說，生產訂單是一切生產活動的起點，一般是通過接受銷售訂單人工轉換成生產訂單或者使用MRP功能將銷售訂單拆解爲各個零部件的生產訂單和產品的裝配生產訂單。根據普通的中小型離散製造業對生產訂單管理的需求，可以梳理出如下一些業務目標：
1.生產訂單管理（瞭解銷售訂單業務和生產整體業務的人）（工廠計劃員）：
1.1.根據銷售訂單，創建成品和半成品的生產訂單；
1.2.可以通過手動錄入、導入和系統集成的方式創建生產訂單；如果創建的生產訂單僅僅是成品或獨立需求件的生產訂單，則可以根據BOM分解生成半成品的生產訂單；生產訂單可以修改，以更改日期、生產優先級、數量等；生產訂單可以進行數量的合併拆分，以優化生產執行；生產訂單可以撤銷、可以發佈；
1.3.生產訂單可以直接下發到車間，也可以按照工藝段（需支持子工藝路線）下發到車間，由車間根據產能和優先級安排生產分派；也可以根據工藝路線通過排程直接安排到具體的工位/設備/班組，生成生產任務；
1.4.可以查詢生產訂單狀態和進度信息；
一開始思考這個業務場景的時候，仍然是按照傳統老路，按照模塊去梳理用例和活動，迷惑到底銷售訂單拆分爲零部件的生產訂單到底算不算在生產訂單管理業務邊界內。回頭看看書，再理解下，發現當時忽略了業務目標。再以業務目標爲出發點，一下子就非常清晰了，而且也能得到比較好的業務邊界。
定義業務邊界
目標清楚後，就可以根據一個個的目標來定義業務邊界在哪裏。
1.1根據銷售訂單，創建成品和半成品的生產訂單。我們就可以知道，計劃員、銷售訂單管理員（如果負責拆分非獨立需求件訂單）可能都是這個目標相關的主角，而業務內部就是創建生產訂單的整個用例。
發現業務用例
原則上，每一個業務目標都會對應一套參與者、用例、實現等整個過程。但在真實應用中，業務目標不一定非常嚴謹，不一定邏輯正確。所以，折中的，可以彙集好幾個業務目標來生成一套用例過程。
以整個生產訂單管理所有業務目標出發，發現主角就是計劃員，計劃員要達成目標需要做以下事情：
- 創建生產訂單
- 根據銷售訂單和生產實際調整生產訂單
- 發佈生產訂單，安排生產；
- 查詢生產訂單進度；
以用例圖形式展示：
![在這裏插入圖片描述]()
在開始使用用例圖時，發現用例圖用例非常多，顆粒度不好掌握。慢慢的，才發現，按照業務目標去梳理用例圖時非常合適的。每個用例只需要能完整描述一個業務目標即可，但是不需要將如何實現的。 如何實現是在用例場景中去描述的。這就可以較好的控制用例的顆粒度了。
業務用例場景
理論上，需要爲每一個用例進行用例場景、實現場景建模；但如果業務複雜，時間和資源有限，只能將一些可以使用流程串到一起的用例集中進行描述；實際應用中，鑑於用例場景是描述如何實現用例的，要求每個用例至少用2個及兩個以上的活動來描述；對於無法放到流程中的用例，如果非常重要，則需要單獨描述，否則可以不描述，如調整生產訂單。
tips:
(最好不要以下圖方式，雖然節省時間，但可能比較亂，將多個用例放到了一張圖上，變成了“流程圖”)
在繪製用例場景活動圖或泳道圖時，最好按照標準的活動圖來繪製，這對開始學習非常重要。當用例場景存在多個主角和參與者時，以參與者維度使用泳道圖來描述會比較清晰。
用例實現場景
對於每個業務用例，對應有多個業務用例實現；如創建生產訂單，用戶可以通過手動添加，導入或第三方集成接口同步的方式實現創建生產訂單。即創建生產訂單用例對應了三種用例實現。對於創建生產訂單用例，在用例場景中已經分解爲1,2.1,2.2,2.3三個活動；理論上，可以對每個活動進行用例實現場景建模，即每個活動可能對應着三種實現場景。如1.查看銷售訂單等信息，可以通過excel查看，通過紙質單據查看或在其他系統中查看。
實際應用中，只需要對涉及到系統交互的某些關鍵性活動或複雜活動進行詳細的用例場景實現建模。爲節省時間和成本，可以將整個用例場景一起進行實現場景描述，僅對其中涉及到多個實現場景的活動做拆解描述，同時，可以過濾掉非本版本內容的實現場景。採用泳道圖或頁面流程圖採用實現分支描述清楚。
業務對象
通過這個流程，不難看出實現此業務目標的多個用例過程中，主要包括生產訂單這個業務對象。具體對象屬性就不再描述了。
總結
通過上面，我們非常清楚的實現了從業務目的不斷轉化成功能交互的過程。仔細回顧這個過程，是不是很自然而然的，邏輯性非常好。面對一個新的行業或新業務，是不是不再需要通過大腦網絡的黑盒計算，以自己都不知道功能是怎麼蹦出來的方式來設計功能了呢？最後，還有一點比較重要，就是初學時，一定要按照標準的UML規範來繪製各種圖，深入淺出，打好基礎，爲以後的靈活應變打好基礎。