大多數(shù)軟件開發(fā)實踐者都知道，UML在對真實世界的現(xiàn)象進(jìn)行建模時非常優(yōu)秀，

用UML進(jìn)行有效業(yè)務(wù)建模

    一些希望使用業(yè)務(wù)建模的團(tuán)隊常常有一些經(jīng)驗性的問題，例如：

什么時候真正需要業(yè)務(wù)模型？什么時候用例模型獨立存在？

我在進(jìn)行精確的業(yè)務(wù)建模時我能用哪些UML圖形？我如何知道是否用順序圖或者交互圖。有例子嗎？

業(yè)務(wù)模型如何涉及到其他模型（如領(lǐng)域模型，用例模型等等）呢？我如何有機地組織這些模型？

    很不幸，本文的焦點集中于應(yīng)用UML進(jìn)行業(yè)務(wù)建模的問題，而很少把業(yè)務(wù)建模和系統(tǒng)建模進(jìn)行比較。這將使用戶和分析員對使用UML進(jìn)行業(yè)務(wù)建模的感到灰心。

    本文主要通過一個例子講述它們的關(guān)系。這個例子主要用來改進(jìn)某企業(yè)的流程，主要涉及到IT部門、法律顧問、企業(yè)架構(gòu)師、項目經(jīng)理。

    業(yè)務(wù)用例模型概覽

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

    我們總結(jié)業(yè)務(wù)用例如下：

Prepare Tender:  準(zhǔn)備系統(tǒng)說明書的流程。

Select Vendor:     選擇賣方的流程。

    我們總結(jié)業(yè)務(wù)主角如下：

End User Manager: 公司內(nèi)的需要自動控制系統(tǒng)的部門。

Vendor Manager:    賣方的管理者。

    在這個例子中，得到一個新系統(tǒng)的核心業(yè)務(wù)目標(biāo)被精化為兩個子目標(biāo)：

詳細(xì)說明想得到的系統(tǒng)。

選擇并評估候選人。

    業(yè)務(wù)用例規(guī)約

    這一部分，我們來看看如何描述業(yè)務(wù)用例，雖然RUP中對業(yè)務(wù)用例規(guī)約有很詳細(xì)的模版，但我們主要把精力放在基本流和擴展流上。

    Prepare Tender的基本流：

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

指定用戶代表。

用戶代表準(zhǔn)備系統(tǒng)規(guī)約。

IT部門復(fù)審系統(tǒng)規(guī)約，并改進(jìn)它，形成招標(biāo)文件。

用戶代表批準(zhǔn)招標(biāo)文件。

    擴展流：

系統(tǒng)規(guī)約無效。當(dāng)IT部門發(fā)現(xiàn)需求太含糊，最終用戶的管理者必須重新制作需求。那么這個用例從第二步從新開始，如果最終用戶管理者不想繼續(xù)，也可以終止。

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

招標(biāo)文件和需求規(guī)約沖突。在第四步，最終用戶管理者發(fā)現(xiàn)招標(biāo)文件有問題，它將被拒絕，IT部門必須重新做它，用例在第三步繼續(xù)，

管理資料

    業(yè)務(wù)用例實現(xiàn)

    在這部分，我們從幾個方面去實現(xiàn)業(yè)務(wù)用例。

以工作流為中心

以流程自動化為中心

以信息處理為中心

    焦點集中在工作流

    我們要精力集中在業(yè)務(wù)角色的職責(zé)上，如圖所示，Prepare Tender有三個業(yè)務(wù)角色：

    下面的順序圖描述了Prepare Tender的基本流。

    上圖中的消息可以映射到每個業(yè)務(wù)角色的職責(zé)（如下圖所示）。這個技術(shù)非常類似于用例分析。由此可見RUP業(yè)務(wù)建模的技術(shù)是很強大的：相同的技術(shù)可用于業(yè)務(wù)建模和系統(tǒng)建模。

    焦點集中在流程自動化

    現(xiàn)在我們準(zhǔn)備去探索業(yè)務(wù)主角和業(yè)務(wù)角色職責(zé)，明確什么時候使用業(yè)務(wù)系統(tǒng)以及如何使用業(yè)務(wù)系統(tǒng)。在我們的例子中，我們有兩個業(yè)務(wù)系統(tǒng)，如下圖所示。

    TMS是準(zhǔn)備招標(biāo)和選擇賣主的系統(tǒng)。這是一個新系統(tǒng)。

    CMS是跟蹤合同的系統(tǒng)，已存在。

    在RUP中，業(yè)務(wù)對象建模的指導(dǎo)方針建議可以對“業(yè)務(wù)系統(tǒng)”定義一個新的泛型圖標(biāo)，在這篇文章中我們將使用“業(yè)務(wù)角色”圖標(biāo)來表示“業(yè)務(wù)系統(tǒng)”。將有一個新的圖標(biāo)在新的UML業(yè)務(wù)建模規(guī)范中。

    下面的順序圖描述了Prepare Tender基本流的實現(xiàn)，包含了需求的業(yè)務(wù)系統(tǒng)。

    上圖中的消息可以映射到業(yè)務(wù)角色的職責(zé)。如下圖所示：

    從上圖中可以得到系統(tǒng)用例，如下圖：

    焦點集中在信息處理

    現(xiàn)在讓我們看看業(yè)務(wù)用例在信息處理上的實現(xiàn)，這就是說，有多少業(yè)務(wù)實體。經(jīng)過分析，我們將得到四個業(yè)務(wù)實體，如下圖：

    下圖是實現(xiàn)Prepare Tender的交互圖（側(cè)重于信息處理）。

    上面兩張圖的消息可以映射到每上業(yè)務(wù)實體的職責(zé)，如下圖：

    下圖是上圖的一個簡化。

    結(jié)論

    軟件系統(tǒng)開發(fā)出來是為了達(dá)到業(yè)務(wù)目標(biāo)，可是，用戶，分析員，和開發(fā)人員常常生活在不同的世界；他們有不同的看法和用不同的行話。小組間的通訊障礙導(dǎo)致在解釋各種系統(tǒng)需求時發(fā)生很多激烈的爭論。具有代表性的一點是，他們的改變不是因為用戶改變了想法，而是因為最初的需求需要凈化。

    來自：http://tech.it168.com/m/2008-01-10/200801101004390.shtml