用UML進行有效業務建模(編譯)

關鍵字：UML 業務建模大多數軟件開發實踐者都知道，UML在對真實世界的現象進行建模時非常優秀。這一特性可以有效幫助分析員和客戶進行溝通。

一些希望使用業務建模的團隊常常有一些經驗性的問題，例如：

１、什么時候真正需要業務模型？什么時候用例模型獨立存在？ 

２、我在進行精確的業務建模時我能用哪些UML圖形？我如何知道是否用順序圖或者交互圖。有例子嗎？ 

３、業務模型如何涉及到其他模型（如領域模型，用例模型等等）呢？我如何有機地組織這些模型？ 

很不幸，本文的焦點集中于應用UML進行業務建模的問題，而很少把業務建模和系統建模進行比較。這將使用戶和分析員對使用UML進行業務建模的感到灰心。

本文主要通過一個例子講述它們的關系。這個例子主要用來改進某企業的流程，主要涉及到IT部門、法律顧問、企業架構師、項目經理。 

1.        業務用例模型概覽
在這個簡單的例子中的第一步是完成業務用例模型概覽。如圖所示，有兩個業務主角和兩個業務用例。

       我們總結業務用例如下：

Prepare Tender:   準備系統說明書的流程。

Select Vendor:      選擇賣方的流程。

       我們總結業務主角如下：

End User Manager:      公司內的需要自動控制系統的部門。 

Vendor Manager:        賣方的管理者。

在這個例子中，得到一個新系統的核心業務目標被精化為兩個子目標： 

詳細說明想得到的系統。 
選擇并評估候選人。 
1.        業務用例規約
在這一部分，我們來看看如何描述業務用例，雖然RUP中對業務用例規約有很詳細的模版，但我們主要把精力放在基本流和擴展流上。

Prepare Tender的基本流： 

       用例的目標是確定招標文件，同時可以將招標文件發布給候選賣主。 

１、      指定用戶代表。 

２、      用戶代表準備系統規約。 

３、      IT部門復審系統規約，并改進它，形成招標文件。 

４、      用戶代表批準招標文件。 

擴展流： 

１、      系統規約無效。當IT部門發現需求太含糊，最終用戶的管理者必須重新制作需求。那么這個用例從第二步從新開始，如果最終用戶管理者不想繼續，也可以終止。 

２、      系統已存在。如果IT部門發現這個需要的系統和其它部門存在的系統很類似，IT部門就提交給最終用戶管理者。如果最終用戶管理者希望繼續尋找新系統，他必須寫出該系統的特色，并重新提交該說明書，回到第二步，如果最終用戶管理者不想繼續，也可以終止。 

３、      招標文件和需求規約沖突。在第四步，最終用戶管理者發現招標文件有問題，它將被拒絕，IT部門必須重新做它，用例在第三步繼續。 

2.        業務用例實現
在這部分，我們從幾個方面去實現業務用例。 

n         以工作流為中心 

n         以流程自動化為中心

n         以信息處理為中心 

焦點集中在工作流
       我們要精力集中在業務角色的職責上，如圖所示，Prepare Tender有三個業務角色：

原文轉自：http://www.anti-gravitydesign.com