OO系統分析員之路--用例分析系列（4）--業務建模一般步驟和方法

本篇開始之前先扯點閑話，商業應用系統開發經曆了三個階段：

第一個階段以計算為中心，分析設計圍繞程式的運行效率，演算法優劣，存貯最佳化來進行。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文檔中找到這些文檔的模板。

預告：下一篇筆者將講述如何根據業務模型建立系統概念性模型。這裡先說一點，系統概念性模型建立最主要依據的是第三步、第四步、第五步建立的業務/用例情境和業務實體模型。這也突顯了情境和實體模型的重要程度。