3.4 分析業務用例場景
分別針對上節中業務用例視圖中的每一個用例，分析該業務用例在實際工作中是如何做的，一般使用業務活動圖來表述業務場景。在這個階段，有幾點需要特別注意的地方：
1、關注參與業務用例的各個參與者是如何協同的，如一個簡化的用戶開戶的流程就是填寫營業員提交開戶訂單-》主管審批訂單-》施工人員履行訂單；
2、對一個業務用例，如果有不同的實現路徑，需要做不同的場景分析。例如，用戶訂購產品，分網上訂購和營業廳訂購這兩種場景，兩個場景大不相同；
3、場景的步驟粒度：用戶的一個完整操作目的，如用戶開戶，則用戶填寫訂單是一個步驟，而不用細化到用戶取單、拿筆填單等；
3.5 產生業務對象模型
針對每個業務用例，根據業務用例場景，分析該用例中涉及的業務實體，并繪制業務對象模型圖。
3.6 產生業務用例實現視圖
業務用例實現指業務用例的一種實現路徑，一個業務用例實現對應著一個業務用例場景。業務用例實現視圖是表述業務用例實現的視圖。
3.7 分析業務用例實現場景
業務用例實現場景著重描述如何通過人機交互來完成業務，是業務用例場景的具體化。一般用活動圖來表述人機交互流程。這里每個步驟的粒度是人與系統或系統與人的一次交互。
3.8 領域建模
領域模型是描述特定問題域的對象及其相互關系。領域模型對業務對象做了進一步的精化。領域建模的步驟如下：
1、確定問題域：如CRM中的客戶模型比較關鍵，我們決定對其進行領域建模，則需要將設計客戶業務實體的用例全部識別出來；
2、領域建模：逐一分析涉及到操作客戶模型的業務用例場景，識別領域對象以及對象之間的關系；
3、驗證領域模型：使用序列圖作為工具，基于領域模型來編排實現各業務場景，如果能實現，證明領域模型ok。
領域對象跟業務對象有區別，我認為，業務對象不是領域對象。業務對象來自于業務用例，是業務中客觀存在的，而領域對象是對業務對象做進一步抽象、精化后的結果，是人對業務的主觀認識，這就是為什么不同廠商的產品模型會不一樣的原因，而且并不是所有的領域對象都是根據業務對象分析而來的。比如，某CRM產品面向全球市場，可定制能力是關鍵，為提升可定制性，需要構建一個快速開發框架，這個快速開發框架也是軟件系統的一部分，也是有領域模型的，但是它的領域模型跟業務對象沒半點關系。
3.9 產生邏輯架構草稿
通過上述步驟，我們已經有了部分領域模型，針對每一個可直接映射到業務對象一級的領域對象，可規劃相應的業務模塊，如有開戶訂單，那么可以有訂單管理，有客戶管理等。業務模塊的劃分粒度可依據大概的工作量而定，保證最低級別的業務模塊的工作量是大致均勻的。這僅僅是一個建議，可以根據項目的實際情況決定。
基于上述的成果，我們還只能產出一個邏輯架構的草稿，因為我們還沒有分析質量屬性，后續對質量屬性做設計的時候，還有可能會引入新的模塊。比如要讓業務流程可快速編排、定制，我們希望引入工作流，那么邏輯架構中也要引入一個工作流模塊。
待續。。。