轉載自：
http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html 本篇開始之前先扯點閑話，商業應用系統開發經歷了三個階段：
第一個階段以計算為中心，分析設計圍繞程序的運行效率，算法優劣，存貯優化來進行。90年代的大學課程講的都是這些。
第二階段以數據為中心，分析設計圍繞數據流進行，以數據流程來模擬業務流程。這也就是所謂的面向過程的分析模式。
第三階段以人為中心，分析設計圍繞人的業務需求，使用要求，感受要求進行。這也就是現在的面象對象分析模式。
使用OO方法建立商業模型必須先定義涉眾。商業系統無論多復雜，無論什么行業，其本質無非是人，事，物，規則。人是一切的中心，人做事，做事產生物，規則限制人事物。人驅動系統，事體現過程，物記錄結果，規則則是控制。無論OO也好，UML也好，復雜的表面下其實只是一個簡單的規則，系統分析員弄明白有什么人，什么人做什么事，什么事產生什么物，中間有什么規則，再把人，事，物之間的關系定義出來，商業建模也就基本完成了。這時候可以說，系統分析員已經完全了解了用戶需求，可以進入系統建模階段了。
書歸正傳，上篇筆者歸納了一些典型的涉眾類型及他們的普遍期望。接下來，就是要將他們這些期望定義出來。這個過程，就是業務用例獲取的過程。筆者可以跟大家分享的經驗是通過以下步驟進行，這些步驟并非唯一正確，對于經驗不多的系統分析員來說，這些步驟很有指導意義。
筆者做了一個建模實例，有需要有讀者請到筆者的BLOG資源中心下載，實例以上一篇所述網上圖書館需求為藍本建立了業務用例模型，之后的概念模型、系統模型則抽取了其中的借閱過程作為例子。不記得了可以后頭找找。
建模第一步，從涉眾中找出用戶。并定義這些用戶之間的關系。在ROSE中，應該使用business actor 類型。參考上一篇的需求描述，下載實例
第二步，找出每個用戶要做的事，即業務用例，在ROSE中應使用Business use case類型。請參考《用例的類型與粒度》一文以幫助確定用例的粒度。筆者強烈建議為每一個business actor繪制一個業務用例圖，這能很好的體現以人為中心的分析模式，并且不容易漏掉business actor需要做的事。至于以參與者為中心的視圖容易漏掉某個業務用例的參與者的擔心，可以在第四步中得到消除。下載實例
第三步，利用業務場景圖幫助分析業務流程，在ROSE中，這個階段最好使用活動圖Activity diagram。在這個階段，業務場景圖非常重要，在繪制過程中，系統分析員必須采用第一步中定義的用戶名字作為泳道名，使用第二步中定義的業務用例名作為活動名來繪制。必須這么做的原因是，如果你無法把利用已經定義出來的 business actor 和 business use case完備的描繪業務流程，那么一定是前面的定義出問題了，你需要回頭審視是否 business actor 和 business use case定義不完善或錯誤。如果不是所有的business actor 和 business use case 都被用到，要么應該檢查業務流程調研時漏了什么，要么應該檢查是否定義了一些無用的business actor 和 business use case 。同時，繪制業務場景圖也非常有助于選擇合適的用例粒度并保持所有的用例都是同一粒度。下載實例
第四步，繪制用例場景圖。與業務場景圖不同的是，用例場景圖只針對一個用例繪制該用例的執行過程。筆者仍然強烈推薦使用activity diagram。在用例場景圖的繪制中，必須使用第一步中定義的業務用戶作為泳道。必須這么做的原因是，它能幫助你發現在定義業務用例圖時的錯誤，比如是否漏掉了某個業務用例的潛在使用者。不是每個業務用例都需要繪制場景圖，只有兩三個步驟的業務用例是不必一定繪制業務用例圖的，但仍然需要在業務用例規約文檔中寫明。下載實例
第五步，從第三步或第四步中繪制的活動圖中找到每一步活動將使用到的或產生的結果。這是找到物的過程。找到后，應當建立這些物之間的關系。在ROSE中，這稱為業務實體模型。應該使用business entity 類型。下載實例
第六步，在上述過程中，隨時補充詞匯表Glossary。將此過程中的所有業務詞匯，專業詞匯等一切在建模過程中使用到的需要解釋的名詞。這份文檔將成為模型建立人與讀者就模型達成一致理解的重要保證。
第七步，根據上一篇中提到的業主，老板等涉眾的期望審視建立好的模型，確定業務范圍，決定哪些業務用例在系統建設范圍內。那些不打算納入建設范圍內的業務用例有兩種情況，一種是該業務用例是被調用一方，那么應該把它改為 boundary 類型，意味著將來它是一個外部接口。另一種是該業務用例主動調用系統內業務用例，那么應該將它改為business actor類型。與普通business actor不同的是，由業務用例轉換而成的business actor不是人，而通常是一個外部系統進程，因此應該在被調用的系統內業務用例與它之間增加一個boundary元素，意味著我們的系統將為這樣一個外部進程提供一個接口。嚴格來說，那些需要納入建設范圍的business use case 應當對應的生成一個 business use case realization， 以后的設計工作將歸納到這些實現用例中。但筆者覺得這一步并非很關鍵的，實際中本人也經常省略這一步，而將協作圖，象活動圖，類交互圖等直接在business usecase下說明。不過本實例中筆者還是按照正規方法來建模的。下載實例
需要說明的是，上述的步驟并非一次性完成的，在每一個步驟中都可能導致對以前步驟的調整。即使建模已經完成，當遇到變化或發現新問題時，上述步驟應當從頭到尾再執行一次。這也是RUP倡導的迭代開發模式。
經過以上的步驟，我們已經建立了一個完整的業務模型。但這決不是建模工作的全部，以上過程只說明了建立一個完整業務模型的過程，不能說這樣就建立了一個很好的業務模型。因為上述的過程中并沒有提及業務分析過程。分析過程全憑系統分析員的經驗，對OO的理解和對行業業務的把握能力，對原始業務模型進行歸納，整理，抽象，重構，以建立一個更高效，合理，擴展性更強的模型。這個過程無法以步驟說明。或許以后筆者會專門針對模型分析寫點東西。另外除了模型，還至少需要寫業務架構文檔、用例規約和補充用例規約三種文檔。因為模型雖然可以較好的體現業務架構，但很不好表達業務規則和非業務需求，這些需要在文檔中說明。例如用例的前置條件和后置條件就是一種業務規則。讀者可以在RUP文檔中找到這些文檔的模板。