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