| 級(jí)別: 初級(jí) Pan-Wei NgSoftware Engineering Specialist Rational Software Singapore
2004 年 5 月 01 日 就像大多數(shù)的軟件開發(fā)從業(yè)者所知道的那樣，統(tǒng)一建模語言 （UML）在表示真實(shí)世界的現(xiàn)象方面是非常優(yōu)秀的。這種能力導(dǎo)致了 Business Modeling Profile 的發(fā)展，UML Business Modeling Profile 提供了擴(kuò)展和原型以使用戶和分析人員之間的交流更加容易。 正考慮應(yīng)用 Business Modeling Profile 的組織通常都會(huì)有一些實(shí)際的問題，比如下面的問題： - 在什么時(shí)候我們真正需要一個(gè)業(yè)務(wù)模型？什么時(shí)候只需要用例模型就足夠了？
- 對(duì)于特定的業(yè)務(wù)建模情景，我們應(yīng)該使用哪一種 UML 圖？例如，我如何知道應(yīng)該使時(shí)序圖還是使用協(xié)作圖？
- UML 業(yè)務(wù)模型使如何與其他 UML 模型（領(lǐng)域模型、用例模型等等）相關(guān)聯(lián)的？我應(yīng)該所＝如何組織這些模型呢？
| 識(shí)別業(yè)務(wù)參與者（Actor）
為系統(tǒng)建模識(shí)別參與者是容易的 － 任何系統(tǒng)外部的事物都是一個(gè)參與者，并且邊緣十分清晰，因此人總是參與者。對(duì)于業(yè)務(wù)建模來說就不是那么簡單的，因?yàn)橐粋€(gè)人既可以是一個(gè)業(yè)務(wù)參與者（比如，一個(gè)與業(yè)務(wù)交互的外部人員）也可以是一個(gè)業(yè)務(wù)執(zhí)行者（比如，一個(gè)業(yè)務(wù)內(nèi)部的人員）。關(guān)于這個(gè)問題的一個(gè)方法是在將他們分類成為業(yè)務(wù)參與者或者業(yè)務(wù)執(zhí)行者之前識(shí)別出與業(yè)務(wù)場景相關(guān)的所有人員。這意味著你必須在同一抽象級(jí)別上定義業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者：他們都是人或者人的群體。 不要盡力的將任何系統(tǒng)都定義成為業(yè)務(wù)參與者，雖然在你挖掘系統(tǒng)用例時(shí)一些系統(tǒng)將成為參與者。在業(yè)務(wù)建模中，你希望將注意力集中在業(yè)務(wù)流程上，因此將系統(tǒng)問題的處理推遲到以后來做可以避免使業(yè)務(wù)用例模型混亂。 在我們的業(yè)務(wù)用例模型調(diào)查中，業(yè)務(wù)參與者是人，而不是人的群體；也就是說，我們有一個(gè)最終用戶的經(jīng)理 ，而不是一個(gè)最終用戶的部門，還有一個(gè)供應(yīng)商經(jīng)理，而不是一個(gè)供應(yīng)商。這樣在我們以后實(shí)現(xiàn)業(yè)務(wù)用例時(shí)，業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者是在同一抽象級(jí)別的。為了確定一個(gè)業(yè)務(wù)用例的范圍，通常我們?cè)陬愃票?1 中的某一個(gè)單獨(dú)的工作流程中跟蹤一個(gè)核心的圓舞曲目標(biāo)。如果被獲得的用例太長，我將細(xì)化核心的業(yè)務(wù)目標(biāo)成為多個(gè)子目標(biāo)，并將工作流程相應(yīng)的分段，同時(shí)將一個(gè)長的工作流程水平的劃分成幾個(gè)業(yè)務(wù)用例。 | | 不幸的是，關(guān)注于這些問題和應(yīng)用 UML 業(yè)務(wù)建模 Profile 的文獻(xiàn)資料比系統(tǒng)建模的資料相對(duì)來說少的多。這使那些認(rèn)同使用 UML 進(jìn)行業(yè)務(wù)建模的用戶和分析人員十分失望，但是他們還是被迫的去努力使用這些符號(hào)。 本文通過了解一個(gè)樣例用例來說明大家所關(guān)系的事情，這個(gè)樣例用例建模了一個(gè)負(fù)責(zé)管理外包開發(fā)的 IT 部分的采購流程。這個(gè)由法律顧問、企業(yè)架構(gòu)師和項(xiàng)目經(jīng)理構(gòu)成的部門負(fù)責(zé)和約的、系統(tǒng)架構(gòu)的和項(xiàng)目管理的問題。這個(gè)部門的任務(wù)是將最終用戶部分從 IT 相關(guān)的問題中解放出來，以便他們能夠?qū)⒔?jīng)理放在業(yè)務(wù)運(yùn)作上。當(dāng)這些部門需要采購新的系統(tǒng)或者改進(jìn)已有的系統(tǒng)時(shí)，他們會(huì)讓 IT 部門準(zhǔn)備最初的說明書，然后 IT 部門選擇合適的供應(yīng)商交付被需要的系統(tǒng)。 我們這個(gè)討論的假設(shè)基礎(chǔ) 我們假設(shè)你對(duì) Rational 統(tǒng)一過程（RUP）中描述的業(yè)務(wù)建模 Profile 的知識(shí)有一定的了解。如果你對(duì)這個(gè) Profile 還不是很熟悉，請(qǐng)參考文章尾部的附錄。 進(jìn)行一個(gè)業(yè)務(wù)用例模型調(diào)查 我們這個(gè)簡單例子的第一部時(shí)完成一個(gè)業(yè)務(wù)用例模型調(diào)查。 如圖 1 所示，存在兩個(gè)參與者和兩個(gè)用例。最終用戶 Manager 想要一個(gè)供應(yīng)商來自動(dòng)化一些工作流程，因此 IT 部門通過準(zhǔn)備最初的需求文檔和包含幾個(gè)候選供應(yīng)商的方式來幫助業(yè)務(wù)部門。一旦和約敲定，采購部門將通過根據(jù)和約中的里程碑管理系統(tǒng)的交付來幫助最終用戶 Manager 。
圖 1: 業(yè)務(wù)用例模型 我們將業(yè)務(wù)用例總結(jié)如下： - 準(zhǔn)備 Tender：描述準(zhǔn)備系統(tǒng)說明的流程。
- 選擇供應(yīng)商：描述供應(yīng)商選擇的流程，從 tender 的批準(zhǔn)到與一個(gè)供應(yīng)商簽訂能夠在合理的成本和時(shí)間計(jì)劃內(nèi)滿足需求的和約。
我們將業(yè)務(wù)用例總結(jié)如下： - 最終用戶方面的經(jīng)理 ：要求自動(dòng)化工作流程的最終用戶部門的聯(lián)系人。
- 供應(yīng)商方面的經(jīng)理 ：供應(yīng)商一方的代表，負(fù)責(zé)合同投標(biāo)和系統(tǒng)實(shí)施的監(jiān)控。
表 1 ：很長的工程流程 | 當(dāng)最終用戶的部門要求一個(gè)額外的自動(dòng)化以改進(jìn)業(yè)務(wù)運(yùn)作時(shí)，業(yè)務(wù)用例就開始了。這個(gè)用例的目標(biāo)是選擇一個(gè)能夠交付最終用戶部門期望的系統(tǒng)的供應(yīng)商。 1. 最終用戶的經(jīng)理選派。采購部門為整個(gè)采購過程指派一名最終用戶的經(jīng)理。 2. 準(zhǔn)備需求系統(tǒng)說明。最終用戶的經(jīng)理準(zhǔn)備并向 IT 部門提交需求系統(tǒng)說明。 3. 準(zhǔn)備 Tender 文檔。IT 部門檢查被提交的需求說明并準(zhǔn)備一份 tender 文檔，增加一些和約性的需求說明。 4. Tender 文檔的批準(zhǔn)。最終用戶的經(jīng)理檢查并批準(zhǔn) tender 文檔。 5. 公開 Tender 。一旦 Tender 文檔被批準(zhǔn)， IT 部門將它送到一系列指定系統(tǒng)分類的供應(yīng)商。 6. 準(zhǔn)備投標(biāo)。每個(gè)供應(yīng)商準(zhǔn)備一份投標(biāo)估計(jì)成本和項(xiàng)目交付計(jì)劃，并提交給 IT 部門。 7. 縮小投標(biāo)范圍。在招標(biāo)期間的末期， IT 部門根據(jù)估計(jì)成本和交付計(jì)劃的可行性縮小候選投標(biāo)商（供應(yīng)商）的范圍。 8. 選擇供應(yīng)商。從縮小的供應(yīng)商列表中，最終用戶經(jīng)理選擇最合適的一個(gè)。 9. 準(zhǔn)備和約。 IT 部門與被選中的供應(yīng)商準(zhǔn)備一份和約。 10. 簽署和約。最終用戶經(jīng)理和被選中的供應(yīng)商簽署和約，并開始更詳細(xì)的系統(tǒng)計(jì)劃和設(shè)計(jì)。 | 在我們的例子中，采購一個(gè)新系統(tǒng)的核心業(yè)務(wù)目標(biāo)是將目標(biāo)分解成兩個(gè)子目標(biāo)。 - 說明將要采購的系統(tǒng)。
- 選擇并評(píng)估一個(gè)候選供應(yīng)商。
因此，準(zhǔn)備 Tender 業(yè)務(wù)用例包括了表 1 中的步驟 1 到 步驟 4，選擇供應(yīng)商業(yè)務(wù)用例包括了表 1 中的步驟 5 到 步驟 10 。有很多方法可以分割工作流程，與客戶討論選擇是重要的。然而，明白業(yè)務(wù)建模的真正價(jià)值在于理解被分解的工作流程之間是如何關(guān)聯(lián)的是十分重要的。
進(jìn)行業(yè)務(wù)用例說明 在這個(gè)部分，我們來看一下如何描述業(yè)務(wù)用例。RUP 中的業(yè)務(wù)用例模板由一些部分組成，但是我們將只關(guān)注在基本的和可選的工作流程上。我將在未來的文章中討論其他的部分 － 包括目標(biāo)、風(fēng)險(xiǎn)、職責(zé)等等。表 2 顯示了為準(zhǔn)備 Tender 業(yè)務(wù)用例的基本和可選的工作流程。 表 2: 業(yè)務(wù)用例說明 | 準(zhǔn)備 Tender 的基本工作流程 當(dāng)最終用戶部門要求額外的自動(dòng)化以改進(jìn)業(yè)務(wù)運(yùn)作時(shí)，這個(gè)業(yè)務(wù)用例就開始了。目標(biāo)是將能夠分發(fā)給候選供應(yīng)商的 tender 文檔最終定稿。 1. 最終用戶的經(jīng)理選派。采購部門為整個(gè)采購過程指派一名最終用戶的經(jīng)理。 2. 準(zhǔn)備需求系統(tǒng)說明。最終用戶的經(jīng)理準(zhǔn)備并向 IT 部門提交需求系統(tǒng)說明。 3. 準(zhǔn)備 Tender 文檔。IT 部門檢查被提交的需求說明并準(zhǔn)備一份 tender 文檔，增加一些和約性的需求說明。 4. Tender 文檔的批準(zhǔn)。最終用戶的經(jīng)理檢查并批準(zhǔn) tender 文檔。 可選工作流程 1. 系統(tǒng)說明無效。在步驟 3 ，如果 IT 部門發(fā)現(xiàn)系統(tǒng)的說明是含糊不清或者是不可行的，最終用戶經(jīng)理需要重新指定系統(tǒng)的說明。步驟 2 的業(yè)務(wù)用例也要重新開始，或者如果最終用戶經(jīng)理不希望繼續(xù)的話，將中止整個(gè)過程。 2. 系統(tǒng)已經(jīng)存在。在步驟 3 中，如果 IT 部門發(fā)現(xiàn)最終用戶部門需要的系統(tǒng)與在另一個(gè)部門中已有的系統(tǒng)非常的相似，那么 IT 部門將讓最終用戶經(jīng)理參考那個(gè)部門的系統(tǒng)。如果最終用戶經(jīng)理希望繼續(xù)采購“新的”系統(tǒng)，他或者她必須在系統(tǒng)的說明中指出不同的特性，重新提交系統(tǒng)說明，并繼續(xù)步驟 2 。如果最終用戶在＝經(jīng)理不希望繼續(xù)，業(yè)務(wù)用例中止。 3. Tender 文檔不一致。在步驟 4 中，如果最終用戶經(jīng)理注意到在 Tender 文檔中的不一致，這個(gè) Tender 文檔將被拒絕，并且 IT 部門必須重新制作它。業(yè)務(wù)用例在步驟 3 處繼續(xù)。 |
業(yè)務(wù)用例的實(shí)現(xiàn) 在這個(gè)部分，我們將討論幾個(gè)實(shí)現(xiàn)業(yè)務(wù)用例的方法： | 基本和可選的工作流程
一個(gè)業(yè)務(wù)用例描述了一個(gè)業(yè)務(wù)執(zhí)行活動(dòng)的順序以生成對(duì)特定業(yè)務(wù)參與者有價(jià)值的觀察結(jié)果。在用例開始前識(shí)別出初始的條件是重要的 － 也包括用例的目標(biāo)?；竟ぷ髁鞒虘?yīng)該文檔化從初始條件直接到達(dá)最終目標(biāo)的步驟。從基本工作流程出發(fā)，集中的集體討論在每一步也許會(huì)出現(xiàn)的不同情況，并將他們文檔化為可選工作流程。 在會(huì)面期間，客戶常常描述很多可能的情況，這個(gè)可能會(huì)使分析人員的思想變得混亂，并且將分析人員的注意力從文檔化主要的工作流程中轉(zhuǎn)移。為了避免這種情況，分析人員能夠在一個(gè)“停車場”中文檔化這些可選的情景，（例如，對(duì)于將來的參考和討論的一個(gè)臨時(shí)但又明顯的位置，象白板的以角），在基本工作流程上專心的工作。然后，當(dāng)?shù)搅俗R(shí)別可選工作流程時(shí)，他能夠從“停車場”中的文檔中簡單的挑出需要的文檔。 作為流程定式的說明 業(yè)務(wù)用例說明描述了業(yè)務(wù)外部的視圖，相反業(yè)務(wù)用例實(shí)現(xiàn)則描述了業(yè)務(wù)內(nèi)部的視圖。但是對(duì)于業(yè)務(wù)流程分析人員來說定義什么是“內(nèi)部的”和什么是“外部的”通常不是很容易的。你總是僅僅描述業(yè)務(wù)參與者與業(yè)務(wù)之間的交互嗎？，或者你進(jìn)入到業(yè)務(wù)本身內(nèi)部運(yùn)作的細(xì)節(jié)了嗎？這是用例社區(qū)中經(jīng)典的“設(shè)計(jì)需求”方面的爭論：什么時(shí)候需求是實(shí)際意義上的需求？什么時(shí)候需求應(yīng)該轉(zhuǎn)化成設(shè)計(jì)？ 我所說的是，如果很難區(qū)別什么是內(nèi)部的和什么是外部的，為什么不使用業(yè)務(wù)用例說明來從什么能夠被重新設(shè)計(jì)中辨別過程定式（固定的元素）呢？然后，你能夠在你的業(yè)務(wù)用例實(shí)現(xiàn)中文檔化一個(gè)被選中的過程定式，并且在業(yè)務(wù)用例說明中的“可能的事情”部分列出其他的選項(xiàng)。 | | - 關(guān)注工作流程。
- 關(guān)注流程自動(dòng)化。
- 關(guān)注信息流程
接下來的子部分描述了每種方法的好處，和這些方法是如何互相補(bǔ)充的。 關(guān)注工作流程 我們將看一下業(yè)務(wù)用例實(shí)現(xiàn)，它關(guān)注在包括業(yè)務(wù)執(zhí)行者和他們的職責(zé)的工作流程上。如圖 2 所示，準(zhǔn)備 Tender 業(yè)務(wù)用例有三個(gè)業(yè)務(wù)執(zhí)行者。 - IT 項(xiàng)目經(jīng)理：與最終用戶經(jīng)理的主要聯(lián)系點(diǎn)。
- 企業(yè)架構(gòu)師：通過確保被采購的系統(tǒng)能夠滿足組織的標(biāo)準(zhǔn)以降低系統(tǒng)集成的復(fù)雜度來幫助 IT 項(xiàng)目經(jīng)理。
- 法律官員： 通過補(bǔ)充和檢查在 tender 內(nèi)的合同條款來幫助 IT 項(xiàng)目經(jīng)理。
圖 2: 業(yè)務(wù)執(zhí)行者 － 準(zhǔn)備 Tender 一個(gè)時(shí)序圖描述了準(zhǔn)備 Tender 業(yè)務(wù)用例的基本工作流程的實(shí)現(xiàn)，如圖 3 所示。
圖 3: 準(zhǔn)備 Tender （關(guān)注工作流程）的業(yè)務(wù)用例實(shí)現(xiàn) 在圖 3 中的消息能夠被映射到每一個(gè)業(yè)務(wù)執(zhí)行者的職責(zé)上，如圖 4 所示。這種技術(shù)非常類似于指導(dǎo)用例分析的技術(shù)，這恰恰是為什么 RUP 的業(yè)務(wù)建模技術(shù)是如此強(qiáng)大的原因：相同的技術(shù)能夠被應(yīng)用到業(yè)務(wù)建模和系統(tǒng)建模上。
圖 4: 業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者參與業(yè)務(wù)的視圖
事件/動(dòng)作與職責(zé)/活動(dòng)之間的區(qū)別 在業(yè)務(wù)用例實(shí)現(xiàn)中，在消息和操作中使用動(dòng)詞如“準(zhǔn)備”和“檢查”，并且避免如“提交”、“批準(zhǔn)”和“拒絕”等等的動(dòng)詞是最好的。這樣我們就能夠區(qū)分事件/動(dòng)作與職責(zé)/活動(dòng)之間差別。否則，我們就會(huì)范類似于圖 5 中的錯(cuò)誤。
圖 5: 錯(cuò)誤：事件和職責(zé)有同樣的名字 假設(shè)最終用戶發(fā)送了一個(gè)消息 － “提交系統(tǒng)說明” － 給 IT 部門的經(jīng)理，如圖 5 左側(cè)所示。這意味著 IT 項(xiàng)目經(jīng)理有責(zé)任“提交系統(tǒng)說明”，但是這顯然是錯(cuò)誤的。最終用戶的經(jīng)理應(yīng)該做這個(gè)事情。如果我們使用一個(gè)如圖 6 所示的從最終用戶經(jīng)理到到它自身的反身消息“提交系統(tǒng)說明”，情況仍然是糟糕的。圖 6 沒有顯示最終用戶經(jīng)理必須要“提交系統(tǒng)說明”。 |
關(guān)注業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者
理解業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者的職責(zé)是需求引出的非常重要的方面，因?yàn)槲覀兿霕?gòu)建正確的系統(tǒng)來滿足他們的需要并在他們的業(yè)務(wù)環(huán)境中高效的業(yè)務(wù)運(yùn)作。 通常分析人員在沒有考慮真實(shí)的問題、沒有對(duì)真正的需求進(jìn)行好的理解或者沒有在一些業(yè)務(wù)上下文中放入需求的情況下就直接跳到了系統(tǒng)說明中。這通常會(huì)導(dǎo)致需求的變更。因此，在首次嘗試實(shí)現(xiàn)業(yè)務(wù)用例時(shí)有意的關(guān)注業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者的職責(zé)是非常重要的。我強(qiáng)烈建議完全首次的嘗試一定不要包括任何系統(tǒng)做什么的考慮，尤其是一些遺留系統(tǒng)被包括的情況，因?yàn)檫@樣存在“忘記”那些系統(tǒng)在業(yè)務(wù)中應(yīng)該具有的職責(zé)的傾向。當(dāng)這種情況發(fā)生時(shí)，人們也會(huì)忘記詢問關(guān)鍵的業(yè)務(wù)流程和在舊系統(tǒng)中隱藏的規(guī)則，并且會(huì)忘記在新的業(yè)務(wù)環(huán)境中仔細(xì)的檢查他們。 也要注意，不論是業(yè)務(wù)遠(yuǎn)景文檔還是遠(yuǎn)景文檔都需要有對(duì)客戶、用戶和系統(tǒng)涉眾職責(zé)的描述。 一旦你理解了各種角色的職責(zé)，識(shí)別出他們中的哪一些是耗時(shí)間的，哪一些是資源密集的，或者有錯(cuò)誤傾向的 ，在哪里自動(dòng)化能夠創(chuàng)造最大的價(jià)值。在我的前一篇發(fā)表在 Rational Edge 的文章 ”Business Process Simulation with UML“ 中，描述了如何使用模擬從數(shù)量上估計(jì)不同的自動(dòng)化選擇。 | |
圖 6: 錯(cuò)誤：反身消息不能指明誰收到了系統(tǒng)說明 被推薦的方案是在圖 3 中使用消息 2 。子任務(wù)指明了系統(tǒng)說明準(zhǔn)備額完成。此外，消息 2 的方向也表明了系統(tǒng)說明被最終用戶經(jīng)理提交給 IT 項(xiàng)目經(jīng)理。 圖 7 顯示了對(duì)于一個(gè)直接的”提交系統(tǒng)說明“活動(dòng)的一個(gè)相似的錯(cuò)誤。被推薦的方案被顯示在圖 8 中；子任務(wù)是一個(gè)引發(fā)從”準(zhǔn)備系統(tǒng)說明“向”準(zhǔn)備 Tender 文檔“轉(zhuǎn)移的事件或者動(dòng)作。這樣做是更加簡明；注意圖 8 僅有兩個(gè)活動(dòng)而不象在圖 7 中的 3 個(gè)。
圖 7: 錯(cuò)誤：最終用戶經(jīng)理既擁有活動(dòng)也擁有動(dòng)作
圖 8: 方案：創(chuàng)建一個(gè)包含引發(fā)轉(zhuǎn)移的動(dòng)作的子任務(wù)
將注意力放在過程自動(dòng)化上 現(xiàn)在我們準(zhǔn)備探究業(yè)務(wù)參與者或者業(yè)務(wù)執(zhí)行者的職責(zé)自動(dòng)化 － 特別是他們什么時(shí)候和如何使用業(yè)務(wù)系統(tǒng)。在我們的例子中，我們有兩個(gè)業(yè)務(wù)系統(tǒng)，入圖 9 所示： - Tender 管理系統(tǒng) (TMS)：一個(gè)為準(zhǔn)備 tenders 和選擇供應(yīng)商被開發(fā)的新系統(tǒng)。
- 和約管理系統(tǒng)(CMS)：一個(gè)跟蹤已有和約的現(xiàn)有系統(tǒng)。
圖 9: 對(duì)于準(zhǔn)備 Tender 用例的業(yè)務(wù)系統(tǒng) RUP 中的業(yè)務(wù)對(duì)象模型指南建議了定義一個(gè)新的原型圖標(biāo)的可能性。在本文中我們將為業(yè)務(wù)系統(tǒng)使用 ”Business Worker“ 圖標(biāo)，但是他們將在新的 UML 業(yè)務(wù)建模 Profile 中有一個(gè)新的圖標(biāo)。注意，不管用何種方法，我們的業(yè)務(wù)系統(tǒng)的概念要嚴(yán)格的于在新的 Profile 中相同。 圖 10 顯示了一個(gè)用來描述準(zhǔn)備 Tender 業(yè)務(wù)用例的基本流程實(shí)現(xiàn)的時(shí)序圖，包括了被要求的業(yè)務(wù)系統(tǒng)。
圖 10: 業(yè)務(wù)用例實(shí)現(xiàn) － 自動(dòng)化準(zhǔn)備 Tender 用例 在圖 10 中的消息能夠根據(jù)每一個(gè)業(yè)務(wù)執(zhí)行者的職責(zé)進(jìn)行映射，如圖 11 所示。
圖 11: 由業(yè)務(wù)參與者、執(zhí)行者和系統(tǒng)構(gòu)成的視圖 圖 11 中的類圖顯示了 Tender 管理系統(tǒng) (TMS) 的上下文關(guān)系。通過這個(gè)關(guān)系，我們表達(dá)了需要 TMS 服務(wù)的客戶和對(duì)于操作 TMS 需要的供應(yīng)者。這個(gè)上下文關(guān)系能夠在用例圖中用另一種形式表示，如圖 12 所示。
圖 12: 源自業(yè)務(wù)用例實(shí)現(xiàn)的 Tender 管理系統(tǒng)的用例 在圖 12 中的用例的名字要嚴(yán)格的符合在圖 11 中 TMS 的操作的名字。在圖 12 中的參與者的名字要嚴(yán)格的符合在圖 11 中的業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者的名字。使用相同的命名習(xí)慣有利于從業(yè)務(wù)對(duì)象模型到系統(tǒng)用例模型的跟蹤。 探究自動(dòng)化選擇 在圖 10 中的時(shí)序圖闡明了 Tender 管理系統(tǒng) (TMS) 是如何從法律官員隱藏和約管理系統(tǒng)(CMS)的。這是可能的系統(tǒng)開發(fā)場景之一，包括： 場景 1: 沒有被集成的異構(gòu)系統(tǒng) 場景 2:僅僅提供一個(gè)新的前端系統(tǒng) 場景 3: 集成 | 有多少個(gè)業(yè)務(wù)用例？
總的來說，業(yè)務(wù)用例的數(shù)量應(yīng)該比系統(tǒng)用例的數(shù)量要少。業(yè)務(wù)用例的實(shí)現(xiàn)包括了業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者的參與，者兩者都將潛在的需要與系統(tǒng)進(jìn)行交互，并且因此擁有他們自己的用例集合。通常情況下，業(yè)務(wù)用例對(duì)系統(tǒng)用例的比率應(yīng)該在 1:5 到 1:10 之間。在我們的例子中，”準(zhǔn)備 Tender“ 業(yè)務(wù)用例被用五個(gè)系統(tǒng)用例來表示，如圖 12 。業(yè)務(wù)用例的價(jià)值在于它將用例放到了上下文關(guān)系中 － 顯示一個(gè)業(yè)務(wù)用例組如何能夠被實(shí)現(xiàn)以交付業(yè)務(wù)價(jià)值。 如果業(yè)務(wù)用例和系統(tǒng)用例的數(shù)量是可比的（比如， 1:1 到 1:3 的比率），我將提出對(duì)業(yè)務(wù)建模的要求。如果業(yè)務(wù)用例和系統(tǒng)用例的粒度是相似的，那么其中的一個(gè)類型就是多余的。 | | 在場景 1 中，沒有在 TMS 和 CMS 之間的集成，并且二者都被作為分離和獨(dú)立的系統(tǒng)處理。對(duì)于法律官員的時(shí)序圖被表示在圖 13 中；注意法律官員要直接訪問 CMS 。
圖 13: 時(shí)序圖 － 場景 1：沒有集成的異構(gòu)系統(tǒng) 對(duì)于源自圖 13 中的 TMS 的用例圖被在圖 14 中進(jìn)行了描述。注意 CMS 沒有出現(xiàn)在圖 14 中，因?yàn)樗缓?TMS 進(jìn)行交互。
圖 14: 用例圖：場景 1 ：沒有集成的異構(gòu)系統(tǒng) 在場景 2 中， TMS 提供了一個(gè)封裝 CMS 功能的前端系統(tǒng)。對(duì)于法律官員活動(dòng)的時(shí)序圖被顯示在圖 15 中。這個(gè)方法的目標(biāo)是為最終用戶提供一個(gè)一致的外觀。然而，在使用法律條款進(jìn)行檢查和補(bǔ)充 Tender 中，沒有額外的功能來支持法律官員。
圖 15: 時(shí)序圖 － 場景 2 ：提供新的前端系統(tǒng) 對(duì)于源自圖 15 的 TMS 的用例圖被在圖 16 中被描述。注意圖 16 包含一個(gè)新的用例，”查找和約“，它與 CMS 交互。
圖 16: 用例圖 － 場景 2：提供新的前端系統(tǒng) 場景 3 被顯示在圖 10 的消息 4 中。 TMS 提供了一個(gè) CMS 的前端，并且同時(shí)提供了方便法律官員用法律條款檢查和補(bǔ)充 Tender 的額外功能。 消息能夠映射到用例或流程上。在上面的討論中，在時(shí)序圖中的每一個(gè)消息被映射到一個(gè)用例。這意味著業(yè)務(wù)對(duì)象模型和用例模型一定是一致的 － 也就是說，用例是根據(jù)業(yè)務(wù)系統(tǒng)中的操作的名字命名的。這可能會(huì)太局限了，因?yàn)樵诤芏嗟那闆r下，我們想要彼此獨(dú)立的重構(gòu)用例模型或者業(yè)務(wù)對(duì)象模型。然而，重構(gòu)每一個(gè)模型都將使在兩個(gè)模型之間的映射變得無效，我們希望維護(hù)一致性或者一些可跟蹤的形式。我們能夠通過允許一個(gè)消息被映射到每一個(gè)整體用例或者一個(gè)用例的一部分來實(shí)現(xiàn)這個(gè)目的，作為一個(gè)與消息語義相應(yīng)的流程或者事件來支持這種映射。你可以在圖 17 和 18 中看到他的表示。
圖 17: 消息到用例的映射
圖 18: 操作到用例的映射
關(guān)注信息流程 現(xiàn)在，讓我們看一下關(guān)注與2信息流程的業(yè)務(wù)用例實(shí)現(xiàn) － 也就是，業(yè)務(wù)實(shí)體如何被使用。我們的例子有幾個(gè)業(yè)務(wù)實(shí)體，如圖 19 ： - 系統(tǒng)說明文檔，描述系統(tǒng)的需求。它由最終用戶經(jīng)理最初開發(fā)出來，并通過 IT 項(xiàng)目經(jīng)理被企業(yè)架構(gòu)師來補(bǔ)充。
- Tender 文檔，將被分發(fā)給候選的供應(yīng)商作為一個(gè)準(zhǔn)備投標(biāo)的基礎(chǔ)。它包括系統(tǒng)的說明和法律的條款。
- 法律條款，Tender 中的一個(gè)重要部分，定義了候選供應(yīng)商必須履行的法律條款和條件。
- 和約，能夠引用已有的相關(guān)和約，以便法律官員不必每一次都在和約中寫法律條款。
圖 19: 業(yè)務(wù)實(shí)體 － 準(zhǔn)備 Tender 用例 一個(gè)時(shí)序圖描述了準(zhǔn)備 Tender 業(yè)務(wù)用例的基本流程實(shí)現(xiàn)（信息流程），如圖 20 所示。
圖 20: 業(yè)務(wù)用例實(shí)現(xiàn) － 準(zhǔn)備 Tender 用例信息流程（順序） 相應(yīng)的協(xié)作圖描述了用例的實(shí)現(xiàn)（信息流程），如圖 21 所示。
圖 21: 業(yè)務(wù)用例實(shí)現(xiàn) － 準(zhǔn)備 tender 用例信息（協(xié)作） 在圖 20 和 21 中的消息能夠被映射到每一個(gè)業(yè)務(wù)實(shí)體的職責(zé)上，如圖 22 所示。
圖 22: 由業(yè)務(wù)參與者、執(zhí)行者和實(shí)體組成的視圖 注意，業(yè)務(wù)實(shí)體是被動(dòng)的，并且不能觸發(fā)與自身的交互。因此，在圖 20 和 21 中的消息代表可業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者如何操作這些實(shí)體，或者是手工操作或者是通過自動(dòng)化的工具操作（比如，Tender 系統(tǒng)或者和約管理系統(tǒng)）。在大多數(shù)的情況下，組織將有不止一個(gè)系統(tǒng)，因此一個(gè)單個(gè)的業(yè)務(wù)實(shí)體的職責(zé)可能被映射帶多個(gè)體統(tǒng)的職責(zé)上。在圖 20 中描述哪一個(gè)業(yè)務(wù)系統(tǒng)被用于操作哪一個(gè)業(yè)務(wù)實(shí)體將使圖 20 變得與圖 21 和 22 一樣復(fù)雜。 當(dāng)你進(jìn)行用例分析時(shí)，你能夠?qū)⒚枋霰幌到y(tǒng)操作的實(shí)體推遲到活來進(jìn)行。可選的，你可以有一個(gè)映射業(yè)務(wù)系統(tǒng)和業(yè)務(wù)實(shí)體的類圖。圖 22 能夠通過僅顯示參與的業(yè)務(wù)實(shí)體被簡化，如圖 23 。
圖 23: 業(yè)務(wù)實(shí)體參與的視圖 － 準(zhǔn)備 tender 用例 圖 23 也被作為領(lǐng)域視圖被引用，并且所有的業(yè)務(wù)實(shí)體集合組成了領(lǐng)域模型。領(lǐng)域模型也描述了動(dòng)態(tài)的行為，通常是通過狀態(tài)轉(zhuǎn)換圖。除了顯示不同業(yè)務(wù)實(shí)體之間的關(guān)系，顯示單獨(dú)的業(yè)務(wù)實(shí)體的狀態(tài)也是重要的。狀態(tài)圖顯示了能夠在每一個(gè)業(yè)務(wù)實(shí)體上執(zhí)行的操作。圖 24 是 tender 文檔的狀態(tài)圖。
圖 24: Tender 文檔的狀態(tài)圖 | 業(yè)務(wù)規(guī)則
在需求引出中的一個(gè)挑戰(zhàn)是如何組織業(yè)務(wù)規(guī)則和確保他們的完整性。我通常識(shí)別并對(duì)業(yè)務(wù)規(guī)則組進(jìn)行分類，因?yàn)檫z漏一個(gè)業(yè)務(wù)規(guī)則組要比遺漏一個(gè)組中的規(guī)則更具有破壞性。一些可能的業(yè)務(wù)規(guī)則組的來源是： - 在業(yè)務(wù)用例說明/實(shí)現(xiàn)中的可選流程。
- 在領(lǐng)域模型中的事件。
例如，在真北 tender 的業(yè)務(wù)用例說明中，我們有一個(gè)可選的流程 － A1：系統(tǒng)說明無效。這表明一個(gè)檢查列表被需要來確定是否系統(tǒng)說明是真的無效。這個(gè)檢查列表能夠作為一個(gè)業(yè)務(wù)規(guī)則組被文檔化。 在領(lǐng)域模型中的狀態(tài)表突出了可能發(fā)生的不同事件（比如，圖 24 ），事件能夠被筆筒的條件出發(fā)或者保持。因此，根據(jù)事件對(duì)業(yè)務(wù)規(guī)則分組是簡單自然的。 ”維護(hù)“用例 跨越”維護(hù)“類型的用例從業(yè)者經(jīng)常會(huì)問：這些”維護(hù)“用例是從哪里來的，他們的業(yè)務(wù)目標(biāo)是什么？在業(yè)務(wù)用例實(shí)現(xiàn)的每一個(gè)步驟中都有先決條件，這些條件能夠被先前的步驟或被”維護(hù)“用例實(shí)現(xiàn)。例如，”查找和約“要求一些和約的存在作為前提條件。當(dāng)在準(zhǔn)備 Tender 業(yè)務(wù)用例中沒有任何前提條件的創(chuàng)建一個(gè)和約，一個(gè)”維護(hù)“用例將被需要。對(duì)于”維護(hù)法律條款“用例沒有需要，因?yàn)榉蓷l款被作為”用法律圖奧擴(kuò)補(bǔ)充 Tender“步驟的一個(gè)部分被創(chuàng)建和更新。 | | 在圖 24 中，事件與 Tender 文檔中的操作有相同的名字。Guard 條件（比如，在 UML 中被 "[" and "]" 界定的表達(dá)式）表示了操作的不同終止條件。例如，檢查 Tender 文檔操作有三個(gè)可能的終止條件，命名為： - 可接受的
- 法律條款不可接受的
- 系統(tǒng)說明不可接受的
這些終止條件必須被在圖 12 中被識(shí)別的”檢查 Tender 文檔“用例處理。被接受的 Tender 文檔可以是用例的基礎(chǔ)流程，其他兩個(gè)條件可以是可選流程。從狀態(tài)轉(zhuǎn)換到用例的映射能夠得自于從如圖 25 。 一個(gè)被映射到用例得事件，看守條件被映射映射到用例得一個(gè)流程，并且動(dòng)作代表了下面的看守條件發(fā)覺的步驟。
圖 25: 從狀態(tài)轉(zhuǎn)換到用例的映射 這樣，在圖 24 中被準(zhǔn)備的 Tender 文檔的狀態(tài)被一個(gè)用例處理：檢查 Tender 文檔，如表 3 。準(zhǔn)備的 Tender 文檔的狀態(tài)有三個(gè)分支的轉(zhuǎn)換，他們被映射帶在＝基本流程的步驟 4 ，可選流程 A1 和 A2 上。 表 3: 檢查 Tender 文檔用例 基本流程
這個(gè)用例開始于最終用戶經(jīng)理被 IT 項(xiàng)目經(jīng)理通知文檔已經(jīng)完成后，最終用戶經(jīng)理想要檢查 tender 文檔。 1. 列舉 tender 文檔。系統(tǒng)為最終用戶返回并顯示一個(gè)一個(gè) tender 文檔的總結(jié)列表，并顯示他們的狀態(tài)。 2. 打開 tender 文檔。最終用戶經(jīng)理選擇一個(gè) tender 文檔。系統(tǒng)返回并顯示它。 3. 檢查 tender 文檔。最終用戶獎(jiǎng)勵(lì)檢查系統(tǒng)說明和法律條款。 4. Tender 文檔接受。如果最終用戶經(jīng)理接受了內(nèi)容，她或者他批準(zhǔn)這個(gè)文檔。系統(tǒng)記錄決定，并且 IT 部門能夠?yàn)檎袠?biāo)到開 Tender。用例終止。 可選流程 1. 法律條款不可接受。如果在基本流程的步驟 3 最終用戶經(jīng)理發(fā)現(xiàn)法律條款不可接受，拒絕他們的原因被標(biāo)注。系統(tǒng)通知 IT 項(xiàng)目經(jīng)理和拒絕的法律官員。用例終止。 2. 系統(tǒng)說明不可接受。如果在基本流程的步驟 3 最終用戶經(jīng)理發(fā)現(xiàn)系統(tǒng)說明不可接受，拒絕他們的原因被標(biāo)注。系統(tǒng)通知 IT 項(xiàng)目經(jīng)理和拒絕的企業(yè)架構(gòu)師。用例終止。 | 在表 3 中的可選流程處理Tender 文檔的拒絕。在表 3 中的基本流程的步驟 1 中，系統(tǒng)顯示tender文檔的總結(jié)列表和他們的狀態(tài)。這樣，在業(yè)務(wù)模型中的狀態(tài)圖提供了一種詳細(xì)描述以下方面用例的方法： - 識(shí)別可選流程。
- 實(shí)體的列舉狀態(tài)被顯示。
結(jié)論 軟件系統(tǒng)被開發(fā)以達(dá)到業(yè)務(wù)目標(biāo)。然而，用戶、分析人員和開發(fā)人員通常生活在不同的世界里；他們有不同的看法并使用不同的行業(yè)術(shù)語。在這些人之間的溝通障礙導(dǎo)致了很多關(guān)于各種系統(tǒng)需求的解釋和變更需求上的激烈討論。通常，這些變化的發(fā)生不是應(yīng)為最終用戶改變他們的想法，而是因?yàn)樽畛醯男枨笮枰怀吻濉?/p> 因此使用一種通用的符號(hào)系統(tǒng)（比如 UML）和通用的技術(shù)（UML 和 RUP 業(yè)務(wù)建模 Profile）是至關(guān)重要的，這些技術(shù)既可以描述業(yè)務(wù)流程也可以用于所有用戶、分析人員和開發(fā)人員理解系統(tǒng)。這種被改進(jìn)的溝通的確可以使軟件工程項(xiàng)目更加成功。 在本文中，我們討論了識(shí)別業(yè)務(wù)參與者和業(yè)務(wù)用例的步驟，并且使用三種方法描述了他們的實(shí)現(xiàn)，每一種都有不同的關(guān)注點(diǎn)（見表 4） 。 表 4: 描述業(yè)務(wù)用例實(shí)現(xiàn)的方法 | 關(guān)注點(diǎn) | 目的 | 好處 | | 工作流程 | 識(shí)別業(yè)務(wù)參與者和業(yè)務(wù)執(zhí)行者的職責(zé)。 | - 在不被系統(tǒng)或者信息描述分散注意力的情況下理解業(yè)務(wù)流程。
- 識(shí)別哪一個(gè)業(yè)務(wù)參與者和執(zhí)行者和職責(zé)是耗時(shí)的、資源集中的，或者是對(duì)自動(dòng)化需求的優(yōu)先級(jí)劃分的錯(cuò)誤傾向。
| | 流程自動(dòng)化 | 識(shí)別在業(yè)務(wù)參與者或者執(zhí)行者職責(zé)的支持中業(yè)務(wù)系統(tǒng)的職責(zé)。 | - 理解業(yè)務(wù)系統(tǒng)是如何被業(yè)務(wù)參與者和執(zhí)行者用作他們工作流程的部分。
- 便于系統(tǒng)用例的引出。
| | 信息流程 | 識(shí)別被業(yè)務(wù)參與者和執(zhí)行者使用的業(yè)務(wù)實(shí)體的操作。 | - 理解業(yè)務(wù)實(shí)體之間的關(guān)系。
- 使系統(tǒng)用例的細(xì)化和確認(rèn)更加容易。
|
附錄: 業(yè)務(wù)建模簡介 本文假設(shè)讀者對(duì) UML 有一定的了解，并對(duì)業(yè)務(wù)建模的 UML profile 有一些基本的理解。當(dāng)前的用于業(yè)務(wù)建模的 UML profile 的簡介在表 A-1 中。 表 A-1. 用于業(yè)務(wù)建模的 UML profile 的簡介 | 原型 | 描述 | UML 表示 | | 業(yè)務(wù)用例模型 | - 面向業(yè)務(wù)功能的模型。
- 被用作基本的輸入來識(shí)別組織中的角色和交付產(chǎn)物。
| 模型，作為”業(yè)務(wù)用例模型“的原型 | | 業(yè)務(wù)對(duì)象模型 | - 描述業(yè)務(wù)用例實(shí)現(xiàn)的對(duì)象模型
| 模型，作為”業(yè)務(wù)對(duì)象模型“的原型 | | 業(yè)務(wù)用例 | - 一個(gè)定義了業(yè)務(wù)用例實(shí)例集合的類；每一個(gè)實(shí)例是一個(gè)業(yè)務(wù)執(zhí)行的動(dòng)作序列，業(yè)務(wù)產(chǎn)生一個(gè)對(duì)特定業(yè)務(wù)參與者有價(jià)值的結(jié)果。
| 用例，作為”業(yè)務(wù)用例“的原型 | | 業(yè)務(wù)用例實(shí)現(xiàn) | - 描述一個(gè)特定的業(yè)務(wù)用例是如何根據(jù)協(xié)作的對(duì)象（業(yè)務(wù)執(zhí)行者和業(yè)務(wù)實(shí)體的實(shí)例）在業(yè)務(wù)對(duì)象模型中被實(shí)現(xiàn)的。
| 協(xié)作，作為”業(yè)務(wù)用例實(shí)現(xiàn)“的原型 | | 業(yè)務(wù)參與者 | - 代表在業(yè)務(wù)環(huán)境中與業(yè)務(wù)相關(guān)的人或者事的角色。
| 參與者，作為”業(yè)務(wù)參與者“的原型 | | 業(yè)務(wù)執(zhí)行者 | - 一個(gè)代表與系統(tǒng)交互的人的抽象的類。
- 與其他業(yè)務(wù)執(zhí)行者交互，當(dāng)參與業(yè)務(wù)用例實(shí)現(xiàn)時(shí)操作業(yè)務(wù)實(shí)體。
| 類，”業(yè)務(wù)執(zhí)行者“的原型 | | 業(yè)務(wù)實(shí)體 | - 一個(gè)不能發(fā)起與自身交互的被動(dòng)類。
- 可能會(huì)參與多個(gè)不同的業(yè)務(wù)用例實(shí)現(xiàn)。
- 在業(yè)務(wù)建模中，代表業(yè)務(wù)執(zhí)行者訪問、檢查、操作、產(chǎn)生等的對(duì)象。
- 提供在不同的業(yè)務(wù)用例實(shí)現(xiàn)中業(yè)務(wù)執(zhí)行者之間共享信息的基礎(chǔ)。
| 類，作為”業(yè)務(wù)實(shí)體“的原型 | | 組織單元 | - 業(yè)務(wù)執(zhí)行者、業(yè)務(wù)實(shí)體、關(guān)系、業(yè)務(wù)用例實(shí)現(xiàn)、圖和其他組織單元的集合。
- 通過劃分成更小的部分被用來結(jié)構(gòu)化業(yè)務(wù)對(duì)象模型。
| 在業(yè)務(wù)對(duì)象模型中的包，作為”組織單元“的模型 | | 
