第一個階段以計算爲中心，分析設計圍繞程序的運行效率，算法優劣，存貯優化來進行。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文檔中找到這些文檔的模板。
預告：下一篇筆者將講述如何根據業務模型建立系統概念模型。這裏先說一點，系統概念模型建立最主要依據的是第三步、第四步、第五步建立的業務/用例場景和業務實體模型。這也突顯了場景和實體模型的重要程度。
*********************************************************
作者coffeewoo 歡迎您訪問文章原始出處 : http://coffeewoo.itpub.net ，閱讀中有任何問題可以在BLOG上留言或發郵件到 [email protected]，我將盡力爲您解答。具有代表性的問題我會以 Q &A的形式收錄到對應的文章之後。希望本系列文章對您有幫助。歡迎轉載，敬請註明，謝謝 ^_^
期待ING 1-4都看過,學到很多.強烈期待還有下文~~
你讓學習成爲一種快樂 謝謝，並期待下文~~~
期待ing...... 寫的很不錯,期待下文......
請教一個問題...... 系統分析員通常都上些什麼網站
期待中......,謝謝!!!!!!
看完了1-4 寫的真不錯！期待下文，一定要寫下去啊
訂閱你的博客了
期待
謝謝coffeewoo 謝謝coffeewoo作者！我怕網絡有時不通，我都把上述文章下載到本機了。若coffeewoo作者能多結合一些自己在實際工作中碰到的實例來說明那就更理想了。希望能繼續寫下去。
下載的實例不知道怎麼用 作者，您好，我下載了實例，但是不知道怎麼用，請點撥一下，謝謝
下載的實例不知道怎麼用 作者，您好，我下載了實例，但是不知道怎麼用，請點撥一下，謝謝
實例用法 供下載的實例是用Rose生成的html文件，先解壓，打開example.html就可以了。解壓後有個"使用說明.txt"文件，裏面寫了用法。
要求你的機器上安裝有java虛擬機，到網上搜索，挺多的。如果你用的是MYIE等瀏覽器，請改用標準IE瀏覽器看。如果還是打不開，請檢查瀏覽器設置裏是否禁止了小java程序。
實例中沒有用例場景圖 實例中沒有用例場景圖，請檢查！！！謝謝
用例場景圖 看到用例場景圖了，非常感謝。
在您的第6篇中也詳細提到了，受益匪淺！
期待您能夠寫出更多的文章，以享讀者。衆目期待中。。。
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 你的文章我讀過幾遍了,有幾個問題請教一下:
你所講的建模步驟說得很好,但在建模步驟上如何體現出RUP(UP) 的迭代啊?(當然你說過,發生迭代的話上述步驟應當從頭到尾再執行一次)
那麼請問一下這些迭代在需求規格說明書中如何體現出來?(或者是需求規格說明書中只記載最終的迭代分析結果)
或者是迭代過程有其它的文檔來進行詳細說明嗎?
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 路過，看過，收益過！！ 不頂不行！！！
不僅僅對樓主的知識佩服，更對樓主的精神和人品讚揚。
樓主給我們做了榜樣，向樓主學習！！
附帶：現在很多人都恃才自傲，不可否認他們的知識令人折服，但他們的人品卻大打折扣。
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 附件中的文件不能打開提示加載java程序失敗，我已經裝了java虛擬機
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 可以了我的虛擬機版本太低了，換了一個謝謝你的例子
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 爲什麼你的示例一打開之後左面一直在閃動，
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 請教一下，業務分析人員進行業務分析的過程，是否遍佈於業務建模的4-7步驟的每個步驟，還是在建立好完整的業務模型之後，對業務模型圖統一的應用OO思維，進行歸納和總結等等業務分析方法呢？
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 業務場景圖 是不是各個業務用例的活動圖？
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 請教一下,在還書過程業務實體視圖中，還書申請單，借閱訂單是什麼關係，而且在業務實現場景中並沒有體現出來。
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 請教一下,在還書過程業務實體視圖中，還書申請單，借閱訂單是什麼關係，而且在業務實現場景中並沒有體現出來。
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 謝謝博主，博主的書在本月能面市嗎？
re: OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法 博主寫的此文的第二步、第三步、第四步描述的似乎有些自相矛盾，在第三步中，您說利用業務場景圖幫助分析業務流程，最好使用Activity diagram來描述，使用第二步中定義的業務用例名作爲活動名來繪製，與第四步所描述的矛盾。第四步中說用例場景圖只針對一個業務用例繪製該用例的執行過程，而且必須使用第一步中定義的業務用戶作爲泳道名，以第二步中定義的業務用例名作爲活動名來繪製。此處令人不解，既然是針對一個業務用例進行用例場景圖的繪製，爲什麼會牽扯到其它的業務用例上，一個業務用例應該是一個獨立的業務目標，跟其它的業務用例沒有太多的聯繫，而且仔細觀察了您的圖書館的建模實例，發現borrow process用例場景圖中的活動也並未採用Business Use Case 中的業務用例，此處十分不解，敬請博主幫忙解答，多謝多謝!