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