使用 UML 進行有效的業務建模: 描述業務用例和實現

阿新 • • 發佈：2019-01-20

本文內容包括:

進行一個業務用例模型調查
進行業務用例說明
業務用例的實現
事件/動作與職責/活動之間的區別
將注意力放在過程自動化上
關注資訊流程
結論
附錄: 業務建模簡介

就像大多數的軟體開發從業者所知道的那樣，統一建模語言（UML）在表示真實世界的現象方面是非常優秀的。這種能力導致了 Business Modeling Profile 的發展，UML Business Modeling Profile 提供了擴充套件和原型以使使用者和分析人員之間的交流更加容易。

正考慮應用 Business Modeling Profile 的組織通常都會有一些實際的問題，比如下面的問題：

在什麼時候我們真正需要一個業務模型？什麼時候只需要用例模型就足夠了？
對於特定的業務建模情景，我們應該使用哪一種 UML 圖？例如，我如何知道應該使時序圖還是使用協作圖？
UML 業務模型使如何與其他 UML 模型（領域模型、用例模型等等）相關聯的？我應該所＝如何組織這些模型呢？

不幸的是，關注於這些問題和應用 UML 業務建模 Profile 的文獻資料比系統建模的資料相對來說少的多。這使那些認同使用 UML 進行業務建模的使用者和分析人員十分失望，但是他們還是被迫的去努力使用這些符號。

本文通過了解一個樣例用例來說明大家所關係的事情，這個樣例用例建模了一個負責管理外包開發的 IT 部分的採購流程。這個由法律顧問、企業架構師和專案經理構成的部門負責和約的、系統架構的和專案管理的問題。這個部門的任務是將終端使用者部分從 IT 相關的問題中解放出來，以便他們能夠將經理放在業務運作上。當這些部門需要採購新的系統或者改進已有的系統時，他們會讓 IT 部門準備最初的說明書，然後 IT 部門選擇合適的供應商交付被需要的系統。

我們這個討論的假設基礎

我們假設你對 Rational 統一過程（RUP）中描述的業務建模 Profile 的知識有一定的瞭解。如果你對這個 Profile 還不是很熟悉，請參考文章尾部的附錄。

進行一個業務用例模型調查

我們這個簡單例子的第一部時完成一個業務用例模型調查。

如圖 1 所示，存在兩個參與者和兩個用例。終端使用者 Manager 想要一個供應商來自動化一些工作流程，因此 IT 部門通過準備最初的需求文件和包含幾個候選供應商的方式來幫助業務部門。一旦和約敲定，採購部門將通過根據和約中的里程碑管理系統的交付來幫助終端使用者 Manager 。

圖 1: 業務用例模型

我們將業務用例總結如下：

準備 Tender： 描述準備系統說明的流程。
選擇供應商： 描述供應商選擇的流程，從 tender 的批准到與一個供應商簽訂能夠在合理的成本和時間計劃內滿足需求的和約。

我們將業務用例總結如下：

終端使用者方面的經理： 要求自動化工作流程的終端使用者部門的聯絡人。
供應商方面的經理： 供應商一方的代表，負責合同投標和系統實施的監控。

表 1 ：很長的工程流程

當終端使用者的部門要求一個額外的自動化以改進業務運作時，業務用例就開始了。這個用例的目標是選擇一個能夠交付終端使用者部門期望的系統的供應商。

1. 終端使用者的經理選派。採購部門為整個採購過程指派一名終端使用者的經理。

2. 準備需求系統說明。終端使用者的經理準備並向 IT 部門提交需求系統說明。

3. 準備 Tender 文件。IT 部門檢查被提交的需求說明並準備一份 tender 文件，增加一些和約性的需求說明。

4. Tender 文件的批准。終端使用者的經理檢查並批准 tender 文件。

5. 公開 Tender 。一旦 Tender 文件被批准， IT 部門將它送到一系列指定系統分類的供應商。

6. 準備投標。每個供應商準備一份投標估計成本和專案交付計劃，並提交給 IT 部門。

7. 縮小投標範圍。在招標期間的末期， IT 部門根據估計成本和交付計劃的可行性縮小候選投標商（供應商）的範圍。

8. 選擇供應商。從縮小的供應商列表中，終端使用者經理選擇最合適的一個。

9. 準備和約。 IT 部門與被選中的供應商準備一份和約。

10. 簽署和約。終端使用者經理和被選中的供應商簽署和約，並開始更詳細的系統計劃和設計。

在我們的例子中，採購一個新系統的核心業務目標是將目標分解成兩個子目標。

說明將要採購的系統。
選擇並評估一個候選供應商。

因此，準備 Tender 業務用例包括了表 1 中的步驟 1 到步驟 4，選擇供應商業務用例包括了表 1 中的步驟 5 到步驟 10 。有很多方法可以分割工作流程，與客戶討論選擇是重要的。然而，明白業務建模的真正價值在於理解被分解的工作流程之間是如何關聯的是十分重要的。

回頁首

進行業務用例說明

在這個部分，我們來看一下如何描述業務用例。RUP 中的業務用例模板由一些部分組成，但是我們將只關注在基本的和可選的工作流程上。我將在未來的文章中討論其他的部分－包括目標、風險、職責等等。表 2 顯示了為準備 Tender 業務用例的基本和可選的工作流程。

表 2: 業務用例說明

準備 Tender 的基本工作流程

當終端使用者部門要求額外的自動化以改進業務運作時，這個業務用例就開始了。目標是將能夠分發給候選供應商的 tender 文件最終定稿。

1. 終端使用者的經理選派。採購部門為整個採購過程指派一名終端使用者的經理。 2. 準備需求系統說明。終端使用者的經理準備並向 IT 部門提交需求系統說明。 3. 準備 Tender 文件。IT 部門檢查被提交的需求說明並準備一份 tender 文件，增加一些和約性的需求說明。 4. Tender 文件的批准。終端使用者的經理檢查並批准 tender 文件。

可選工作流程

1. 系統說明無效。在步驟 3 ，如果 IT 部門發現系統的說明是含糊不清或者是不可行的，終端使用者經理需要重新指定系統的說明。步驟 2 的業務用例也要重新開始，或者如果終端使用者經理不希望繼續的話，將中止整個過程。

2. 系統已經存在。在步驟 3 中，如果 IT 部門發現終端使用者部門需要的系統與在另一個部門中已有的系統非常的相似，那麼 IT 部門將讓終端使用者經理參考那個部門的系統。如果終端使用者經理希望繼續採購“新的”系統，他或者她必須在系統的說明中指出不同的特性，重新提交系統說明，並繼續步驟 2 。如果終端使用者在＝經理不希望繼續，業務用例中止。

3. Tender 文件不一致。在步驟 4 中，如果終端使用者經理注意到在 Tender 文件中的不一致，這個 Tender 文件將被拒絕，並且 IT 部門必須重新制作它。業務用例在步驟 3 處繼續。

回頁首

業務用例的實現

在這個部分，我們將討論幾個實現業務用例的方法：

關注工作流程。
關注流程自動化。
關注資訊流程

接下來的子部分描述了每種方法的好處，和這些方法是如何互相補充的。

關注工作流程

我們將看一下業務用例實現，它關注在包括業務執行者和他們的職責的工作流程上。如圖 2 所示，準備 Tender 業務用例有三個業務執行者。

IT 專案經理： 與終端使用者經理的主要聯絡點。
企業架構師： 通過確保被採購的系統能夠滿足組織的標準以降低系統整合的複雜度來幫助 IT 專案經理。
法律官員： 通過補充和檢查在 tender 內的合同條款來幫助 IT 專案經理。

圖 2: 業務執行者－準備 Tender

一個時序圖描述了準備 Tender 業務用例的基本工作流程的實現，如圖 3 所示。

圖 3: 準備 Tender （關注工作流程）的業務用例實現

在圖 3 中的訊息能夠被對映到每一個業務執行者的職責上，如圖 4 所示。這種技術非常類似於指導用例分析的技術，這恰恰是為什麼 RUP 的業務建模技術是如此強大的原因：相同的技術能夠被應用到業務建模和系統建模上。

圖 4: 業務參與者和業務執行者參與業務的檢視

回頁首

事件/動作與職責/活動之間的區別

在業務用例實現中，在訊息和操作中使用動詞如“準備”和“檢查”，並且避免如“提交”、“批准”和“拒絕”等等的動詞是最好的。這樣我們就能夠區分事件/動作與職責/活動之間差別。否則，我們就會範類似於圖 5 中的錯誤。

圖 5: 錯誤：事件和職責有同樣的名字

假設終端使用者傳送了一個訊息－ “提交系統說明” －給 IT 部門的經理，如圖 5 左側所示。這意味著 IT 專案經理有責任“提交系統說明”，但是這顯然是錯誤的。終端使用者的經理應該做這個事情。如果我們使用一個如圖 6 所示的從終端使用者經理到到它自身的反身訊息“提交系統說明”，情況仍然是糟糕的。圖 6 沒有顯示終端使用者經理必須要“提交系統說明”。

　

圖 6: 錯誤：反身訊息不能指明誰收到了系統說明

被推薦的方案是在圖 3 中使用訊息 2 。子任務指明瞭系統說明準備額完成。此外，訊息 2 的方向也表明了系統說明被終端使用者經理提交給 IT 專案經理。

圖 7 顯示了對於一個直接的”提交系統說明“活動的一個相似的錯誤。被推薦的方案被顯示在圖 8 中；子任務是一個引發從”準備系統說明“向”準備 Tender 文件“轉移的事件或者動作。這樣做是更加簡明；注意圖 8 僅有兩個活動而不象在圖 7 中的 3 個。

圖 7: 錯誤：終端使用者經理既擁有活動也擁有動作

圖 8: 方案：建立一個包含引發轉移的動作的子任務

回頁首

將注意力放在過程自動化上

現在我們準備探究業務參與者或者業務執行者的職責自動化－特別是他們什麼時候和如何使用業務系統。在我們的例子中，我們有兩個業務系統，入圖 9 所示：

Tender 管理系統 (TMS)：一個為準備 tenders 和選擇供應商被開發的新系統。
和約管理系統(CMS)：一個跟蹤已有和約的現有系統。

圖 9: 對於準備 Tender 用例的業務系統

RUP 中的業務物件模型指南建議了定義一個新的原型圖示的可能性。在本文中我們將為業務系統使用 ”Business Worker“ 圖示，但是他們將在新的 UML 業務建模 Profile 中有一個新的圖示。注意，不管用何種方法，我們的業務系統的概念要嚴格的於在新的 Profile 中相同。

圖 10 顯示了一個用來描述準備 Tender 業務用例的基本流程實現的時序圖，包括了被要求的業務系統。

　

圖 10: 業務用例實現－自動化準備 Tender 用例

在圖 10 中的訊息能夠根據每一個業務執行者的職責進行對映，如圖 11 所示。

圖 11: 由業務參與者、執行者和系統構成的檢視

圖 11 中的類圖顯示了 Tender 管理系統 (TMS) 的上下文關係。通過這個關係，我們表達了需要 TMS 服務的客戶和對於操作 TMS 需要的供應者。這個上下文關係能夠在用例圖中用另一種形式表示，如圖 12 所示。

圖 12: 源自業務用例實現的 Tender 管理系統的用例

在圖 12 中的用例的名字要嚴格的符合在圖 11 中 TMS 的操作的名字。在圖 12 中的參與者的名字要嚴格的符合在圖 11 中的業務參與者和業務執行者的名字。使用相同的命名習慣有利於從業務物件模型到系統用例模型的跟蹤。

探究自動化選擇 在圖 10 中的時序圖闡明瞭 Tender 管理系統 (TMS) 是如何從法律官員隱藏和約管理系統(CMS)的。這是可能的系統開發場景之一，包括：

場景 1: 沒有被整合的異構系統

場景 2: 僅僅提供一個新的前端系統

場景 3: 整合

在場景 1 中，沒有在 TMS 和 CMS 之間的整合，並且二者都被作為分離和獨立的系統處理。對於法律官員的時序圖被表示在圖 13 中；注意法律官員要直接訪問 CMS 。

圖 13: 時序圖－場景 1：沒有整合的異構系統

對於源自圖 13 中的 TMS 的用例圖被在圖 14 中進行了描述。注意 CMS 沒有出現在圖 14 中，因為它不和 TMS 進行互動。

圖 14: 用例圖：場景 1 ：沒有整合的異構系統

在場景 2 中， TMS 提供了一個封裝 CMS 功能的前端系統。對於法律官員活動的時序圖被顯示在圖 15 中。這個方法的目標是為終端使用者提供一個一致的外觀。然而，在使用法律條款進行檢查和補充 Tender 中，沒有額外的功能來支援法律官員。

圖 15: 時序圖－場景 2 ：提供新的前端系統

對於源自圖 15 的 TMS 的用例圖被在圖 16 中被描述。注意圖 16 包含一個新的用例，”查詢和約“，它與 CMS 互動。

圖 16: 用例圖－場景 2：提供新的前端系統

場景 3 被顯示在圖 10 的訊息 4 中。 TMS 提供了一個 CMS 的前端，並且同時提供了方便法律官員用法律條款檢查和補充 Tender 的額外功能。

訊息能夠對映到用例或流程上。 在上面的討論中，在時序圖中的每一個訊息被對映到一個用例。這意味著業務物件模型和用例模型一定是一致的－也就是說，用例是根據業務系統中的操作的名字命名的。這可能會太侷限了，因為在很多的情況下，我們想要彼此獨立的重構用例模型或者業務物件模型。然而，重構每一個模型都將使在兩個模型之間的對映變得無效，我們希望維護一致性或者一些可跟蹤的形式。我們能夠通過允許一個訊息被對映到每一個整體用例或者一個用例的一部分來實現這個目的，作為一個與訊息語義相應的流程或者事件來支援這種對映。你可以在圖 17 和 18 中看到他的表示。

圖 17: 訊息到用例的對映

圖 18: 操作到用例的對映

回頁首

關注資訊流程

現在，讓我們看一下關注與2資訊流程的業務用例實現－也就是，業務實體如何被使用。我們的例子有幾個業務實體，如圖 19 ：

系統說明文件，描述系統的需求。它由終端使用者經理最初開發出來，並通過 IT 專案經理被企業架構師來補充。
Tender 文件，將被分發給候選的供應商作為一個準備投標的基礎。它包括系統的說明和法律的條款。
法律條款，Tender 中的一個重要部分，定義了候選供應商必須履行的法律條款和條件。
和約，能夠引用已有的相關和約，以便法律官員不必每一次都在和約中寫法律條款。

圖 19: 業務實體－準備 Tender 用例

一個時序圖描述了準備 Tender 業務用例的基本流程實現（資訊流程），如圖 20 所示。

圖 20: 業務用例實現－準備 Tender 用例資訊流程（順序）

相應的協作圖描述了用例的實現（資訊流程），如圖 21 所示。

圖 21: 業務用例實現－準備 tender 用例資訊（協作）

在圖 20 和 21 中的訊息能夠被對映到每一個業務實體的職責上，如圖 22 所示。

圖 22: 由業務參與者、執行者和實體組成的檢視

注意，業務實體是被動的，並且不能觸發與自身的互動。因此，在圖 20 和 21 中的訊息代表可業務參與者和業務執行者如何操作這些實體，或者是手工操作或者是通過自動化的工具操作（比如，Tender 系統或者和約管理系統）。在大多數的情況下，組織將有不止一個系統，因此一個單個的業務實體的職責可能被對映帶多個體統的職責上。在圖 20 中描述哪一個業務系統被用於操作哪一個業務實體將使圖 20 變得與圖 21 和 22 一樣複雜。

當你進行用例分析時，你能夠將描述被系統操作的實體推遲到活來進行。可選的，你可以有一個對映業務系統和業務實體的類圖。圖 22 能夠通過僅顯示參與的業務實體被簡化，如圖 23 。

圖 23: 業務實體參與的檢視－準備 tender 用例

圖 23 也被作為領域檢視被引用，並且所有的業務實體集合組成了領域模型。領域模型也描述了動態的行為，通常是通過狀態轉換圖。除了顯示不同業務實體之間的關係，顯示單獨的業務實體的狀態也是重要的。狀態圖顯示了能夠在每一個業務實體上執行的操作。圖 24 是 tender 文件的狀態圖。

圖 24: Tender 文件的狀態圖

在圖 24 中，事件與 Tender 文件中的操作有相同的名字。Guard 條件（比如，在 UML 中被 "[" and "]" 界定的表示式）表示了操作的不同終止條件。例如，檢查 Tender 文件操作有三個可能的終止條件，命名為：

可接受的
法律條款不可接受的
系統說明不可接受的

這些終止條件必須被在圖 12 中被識別的”檢查 Tender 文件“用例處理。被接受的 Tender 文件可以是用例的基礎流程，其他兩個條件可以是可選流程。從狀態轉換到用例的對映能夠得自於從如圖 25 。

一個被對映到用例得事件，看守條件被對映對映到用例得一個流程，並且動作代表了下面的看守條件發覺的步驟。

圖 25: 從狀態轉換到用例的對映

這樣，在圖 24 中被準備的 Tender 文件的狀態被一個用例處理：檢查 Tender 文件，如表 3 。準備的 Tender 文件的狀態有三個分支的轉換，他們被對映帶在＝基本流程的步驟 4 ，可選流程 A1 和 A2 上。

表 3: 檢查 Tender 文件用例

基本流程
　

這個用例開始於終端使用者經理被 IT 專案經理通知文件已經完成後，終端使用者經理想要檢查 tender 文件。

1. 列舉 tender 文件。系統為終端使用者返回並顯示一個一個 tender 文件的總結列表，並顯示他們的狀態。

2. 開啟 tender 文件。終端使用者經理選擇一個 tender 文件。系統返回並顯示它。

3. 檢查 tender 文件。終端使用者獎勵檢查系統說明和法律條款。

4. Tender 文件接受。如果終端使用者經理接受了內容，她或者他批准這個文件。系統記錄決定，並且 IT 部門能夠為招標到開 Tender。用例終止。

可選流程

1. 法律條款不可接受。如果在基本流程的步驟 3 終端使用者經理髮現法律條款不可接受，拒絕他們的原因被標註。系統通知 IT 專案經理和拒絕的法律官員。用例終止。

2. 系統說明不可接受。如果在基本流程的步驟 3 終端使用者經理髮現系統說明不可接受，拒絕他們的原因被標註。系統通知 IT 專案經理和拒絕的企業架構師。用例終止。

在表 3 中的可選流程處理Tender 文件的拒絕。在表 3 中的基本流程的步驟 1 中，系統顯示tender文件的總結列表和他們的狀態。這樣，在業務模型中的狀態圖提供了一種詳細描述以下方面用例的方法：

識別可選流程。
實體的列舉狀態被顯示。

回頁首

結論

軟件系統被開發以達到業務目標。然而，使用者、分析人員和開發人員通常生活在不同的世界裡；他們有不同的看法並使用不同的行業術語。在這些人之間的溝通障礙導致了很多關於各種系統需求的解釋和變更需求上的激烈討論。通常，這些變化的發生不是應為終端使用者改變他們的想法，而是因為最初的需求需要被澄清。

因此使用一種通用的符號系統（比如 UML）和通用的技術（UML 和 RUP 業務建模 Profile）是至關重要的，這些技術既可以描述業務流程也可以用於所有使用者、分析人員和開發人員理解系統。這種被改進的溝通的確可以使軟體工程專案更加成功。

在本文中，我們討論了識別業務參與者和業務用例的步驟，並且使用三種方法描述了他們的實現，每一種都有不同的關注點（見表 4）。

表 4: 描述業務用例實現的方法

關注點	目的	好處
工作流程	識別業務參與者和業務執行者的職責。	在不被系統或者資訊描述分散注意力的情況下理解業務流程。識別哪一個業務參與者和執行者和職責是耗時的、資源集中的，或者是對自動化需求的優先順序劃分的錯誤傾向。
流程自動化	識別在業務參與者或者執行者職責的支援中業務系統的職責。	理解業務系統是如何被業務參與者和執行者用作他們工作流程的部分。便於系統用例的引出。
資訊流程	識別被業務參與者和執行者使用的業務實體的操作。	理解業務實體之間的關係。使系統用例的細化和確認更加容易。

回頁首

附錄: 業務建模簡介

本文假設讀者對 UML 有一定的瞭解，並對業務建模的 UML profile 有一些基本的理解。當前的用於業務建模的 UML profile 的簡介在表 A-1 中。

表 A-1. 用於業務建模的 UML profile 的簡介

原型	描述	UML 表示
業務用例模型	面向業務功能的模型。被用作基本的輸入來識別組織中的角色和交付產物。	模型，作為”業務用例模型“的原型
業務物件模型	描述業務用例實現的物件模型	模型，作為”業務物件模型“的原型
業務用例	一個定義了業務用例例項集合的類；每一個例項是一個業務執行的動作序列，業務產生一個對特定業務參與者有價值的結果。	用例，作為”業務用例“的原型
業務用例實現	描述一個特定的業務用例是如何根據協作的物件（業務執行者和業務實體的例項）在業務物件模型中被實現的。	協作，作為”業務用例實現“的原型
業務參與者	代表在業務環境中與業務相關的人或者事的角色。	參與者，作為”業務參與者“的原型
業務執行者	一個代表與系統互動的人的抽象的類。與其他業務執行者互動，當參與業務用例實現時操作業務實體。	類，”業務執行者“的原型
業務實體	一個不能發起與自身互動的被動類。可能會參與多個不同的業務用例實現。在業務建模中，代表業務執行者訪問、檢查、操作、產生等的物件。提供在不同的業務用例實現中業務執行者之間共享資訊的基礎。	類，作為”業務實體“的原型
組織單元	業務執行者、業務實體、關係、業務用例實現、圖和其他組織單元的集合。通過劃分成更小的部分被用來結構化業務物件模型。	在業務物件模型中的包，作為”組織單元“的模型