大多數軟件開發實踐者都知道，UML在對真實世界的現象進行建模時非常優秀，
用UML進行有效業務建模
。這一特性可以有效幫助分析員和客戶進行溝通。一些希望使用業務建模的團隊常常有一些經驗性的問題，例如：
什么時候真正需要業務模型？什么時候用例模型獨立存在？
我在進行精確的業務建模時我能用哪些UML圖形？我如何知道是否用順序圖或者交互圖。有例子嗎？
業務模型如何涉及到其他模型（如領域模型，用例模型等等）呢？我如何有機地組織這些模型？
很不幸，本文的焦點集中于應用UML進行業務建模的問題，而很少把業務建模和系統建模進行比較。這將使用戶和分析員對使用UML進行業務建模的感到灰心。
本文主要通過一個例子講述它們的關系。這個例子主要用來改進某企業的流程，主要涉及到IT部門、法律顧問、企業架構師、項目經理。
業務用例模型概覽
在這個簡單的例子中的第一步是完成業務用例模型概覽。如圖所示，有兩個業務主角和兩個業務用例。
我們總結業務用例如下：
Prepare Tender: 準備系統說明書的流程。
Select Vendor: 選擇賣方的流程。
我們總結業務主角如下：
End User Manager: 公司內的需要自動控制系統的部門。
Vendor Manager: 賣方的管理者。
在這個例子中，得到一個新系統的核心業務目標被精化為兩個子目標：
詳細說明想得到的系統。
選擇并評估候選人。
業務用例規約
這一部分，我們來看看如何描述業務用例，雖然RUP中對業務用例規約有很詳細的模版，但我們主要把精力放在基本流和擴展流上。
Prepare Tender的基本流：
用例的目標是確定招標文件，同時可以將招標文件發布給候選賣主。
指定用戶代表。
用戶代表準備系統規約。
IT部門復審系統規約，并改進它，形成招標文件。
用戶代表批準招標文件。
擴展流：
系統規約無效。當IT部門發現需求太含糊，最終用戶的管理者必須重新制作需求。那么這個用例從第二步從新開始，如果最終用戶管理者不想繼續，也可以終止。
系統已存在。如果IT部門發現這個需要的系統和其它部門存在的系統很類似，IT部門就提交給最終用戶管理者。如果最終用戶管理者希望繼續尋找新系統，他必須寫出該系統的特色，并重新提交該說明書，回到第二步，如果最終用戶管理者不想繼續，也可以終止。
招標文件和需求規約沖突。在第四步，最終用戶管理者發現招標文件有問題，它將被拒絕，IT部門必須重新做它，用例在第三步繼續，
管理資料
《用UML進行有效業務建模》(http://salifelink.com)。業務用例實現
在這部分，我們從幾個方面去實現業務用例。
以工作流為中心
以流程自動化為中心
以信息處理為中心
焦點集中在工作流
我們要精力集中在業務角色的職責上，如圖所示，Prepare Tender有三個業務角色：
下面的順序圖描述了Prepare Tender的基本流。
上圖中的消息可以映射到每個業務角色的職責（如下圖所示）。這個技術非常類似于用例分析。由此可見RUP業務建模的技術是很強大的：相同的技術可用于業務建模和系統建模。
焦點集中在流程自動化
現在我們準備去探索業務主角和業務角色職責，明確什么時候使用業務系統以及如何使用業務系統。在我們的例子中，我們有兩個業務系統，如下圖所示。
TMS是準備招標和選擇賣主的系統。這是一個新系統。
CMS是跟蹤合同的系統，已存在。
在RUP中，業務對象建模的指導方針建議可以對“業務系統”定義一個新的泛型圖標，在這篇文章中我們將使用“業務角色”圖標來表示“業務系統”。將有一個新的圖標在新的UML業務建模規范中。
下面的順序圖描述了Prepare Tender基本流的實現，包含了需求的業務系統。
上圖中的消息可以映射到業務角色的職責。如下圖所示：
從上圖中可以得到系統用例，如下圖：
焦點集中在信息處理
現在讓我們看看業務用例在信息處理上的實現，這就是說，有多少業務實體。經過分析，我們將得到四個業務實體，如下圖：
下圖是實現Prepare Tender的交互圖（側重于信息處理）。
上面兩張圖的消息可以映射到每上業務實體的職責，如下圖：
下圖是上圖的一個簡化。
結論
軟件系統開發出來是為了達到業務目標，可是，用戶，分析員，和開發人員常常生活在不同的世界；他們有不同的看法和用不同的行話。小組間的通訊障礙導致在解釋各種系統需求時發生很多激烈的爭論。具有代表性的一點是，他們的改變不是因為用戶改變了想法，而是因為最初的需求需要凈化。
來自：http://tech.it168.com/m/2008-01-10/200801101004390.shtml