一些希望使用業務建模的團隊常常有一些經驗性的問題，例如：
１、什么時候真正需要業務模型？什么時候用例模型獨立存在？
２、我在進行精確的業務建模時我能用哪些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.kjueaiud.com/
