需求用例分析之五：業務用例之Rational系

作者：張克強    作者微網誌：張克強-靈活307

RUP中對于業務用例的說明

  業務用例的定義："業務用例從一個外部的，增加值的角度來描述一個業務過程。為了給這個業務的涉衆創造價值，業務用例是超越組織邊界的業務過程，很可能包括合作夥伴和供應商。"

    業務用例執行個體是在業務中執行的一系列動作，這些動作為業務的個體主角産生具有可見價值的結果。 業務用例定義了一組業務用例執行個體。業務用例具有名稱。

業務用例是定義一組業務用例執行個體，其中每個執行個體都是業務執行的一個操作序列，對于特定的業務主角來說，操作序列所産生的結果是可見值。

對于業務用例的檢查點

§ 即使對于業務工程團隊以外的人員來說，它的名稱和簡要說明是否清楚并且易于了解？

§ 從局外人（主角）的角度，每個業務用例是否完整？

§ 每個業務用例是否涉及至少一個主角？

§ 每個支撐用例是否涉及至少一個主角？如果不是，它必須通過内部事件啟動，而且不必與主角互相作用以執行它的活動。

§ 用例工作流程是否清楚而且可以了解？

§ 為使項目團隊以外的人員了解，措詞是否足夠口語化？

§ 它是否說明工作流程，而且不僅僅說明用例的目的？

§ 它是否從外部觀點來說明工作流程？

§ 用例是否隻執行業務内部的活動？

§ 是否屬于用例的所有可能的活動都得到說明？

§ 是否隻提到與用例互相作用的主角？

§ 是否隻說明屬于用例的活動？

§ 它是否隻提到與其相關的用例？

§ 它是否明确指出何時不需要固定活動順序？

§ 工作流程是否構造合理？

§ 是否清楚說明工作流程的起始和結束？

§ 是否清楚說明每個擴充關系以便确定插入用例的方式和時間？

對于抽象業務用例，您可以補充提問：

§ 作為其自身的抽象業務用例，該業務用例是否足夠真實可靠？

§ 它是否包含邏輯相關的活動？

§ 是否有理由使業務用例存在？

業務用例與業務用例實作 

在受用例驅動的業務模組化項目中，您将制作業務的兩個視圖。

業務用例本身展示了業務的外部視圖，它确定了業務為了向主角傳遞期望結果，關鍵要執行什麼。同時還确定了執行業務用例時，業務與主角之間需要進行哪些互動。必須在确定并同意每個業務用例的工作時制作該視圖。這一系列業務用例描述了業務的概貌，對雇員了解執行業務的哪些不同部分以及所期望的結果十分有用。

另一方面，業務用例實作給出了業務用例的内部視圖，它确定了如何組織和執行工作來獲得期望的結果。實作中包含了業務角色和業務實體，它們涉及業務用例的執行，以及進行該工作所需的業務角色和業務實體之間的關系。必須制作該視圖，以便确定并同意為獲得期望的結果，如何在每個業務用例中組織工作。

兩種業務用例視圖面向的主要對象都是業務中的人員 - 外部視圖供業務用例外的人員使用，而内部視圖則供業務用例内的人員使用。

業務用例的範圍 

有時，我們很難确定一項服務是一個業務用例還是多個業務用例。在機場登記流程中應用業務用例的定義。一個旅客将機票和行李交給登記處服務人員，他為 旅客找到一個座位，然後列印登機牌并開始處理行李。如果旅客攜帶的是普通行李，登記處服務人員将列印行李标簽和旅客行李領取牌，在行李上貼好行李标簽，最 後将行李領取牌和登機牌一起交給旅客，進而完成該業務用例。如果行李形狀或所裝東西比較特殊，不能按普通行李運輸，則旅客必須将行李送往特殊行李台。如果 行李過重，旅客必須去機場票務處交納費用，因為登記處服務人員不負責收取費用。

您是否要為登記處、特殊行李台和票務處各設一個業務用例呢？或者您隻需要一個業務用例？的确，該處理過程涉及三種不同的操作。但問題是，是否每個操 作對攜帶特殊行李的旅客都是有意義的？當然不是，隻有整個過程（從旅客到達登記處直到他補交完行李超重費）對旅客來說才是有意義的。是以，涉及三個不同櫃 台的整個過程才是一次完整的使用，即一個業務用例。

除了這個标準之外，另一個實用的方法就是将密切相關服務的說明放在一起，這樣您可以同時對它們進行複審、修改和測試，為它們編寫手冊，并将它們作為一個單元來管理。

值得注意的是兩個獨立的業務用例可能有相似的開始。

好的業務用例的特征 

§ 其名稱和簡要說明清晰易懂，甚至對業務模組化團隊之外的人來說也是如此。

§ 從外部（即主角的）角度看，每個業務用例都是完整的。例如，保險公司的“索賠處理”業務用例以一個客戶送出索賠請求開始。如果不包含保險公司向客戶發出有關索賠請求處理決定的通知或（在同意賠償的情況下）保險賠償的支付，則“索賠處理”業務用例是不完整的。

§ 每個業務用例一般至少涉及一個主角。業務用例由主角啟動，通過與主角進行互動來完成活動并傳遞結果。

§ 支援用例可能不與主角進行互動，不過這種情況不太常見。如果業務用例由某個内部事件啟動，并且不必和主角進行互動即可完成活動，則可能出現上述情況。

好的抽象業務用例的特征 

§ 具有實質性。請記住，具體業務用例與其抽象業務用例必須易于了解。是以，一個抽象業務用例不應該太小。如果某個抽象業務用例不具有實質性，您應該将其删去，而其活動應在受影響的具體業務用例中進行說明。

§ 它包含邏輯上相關的活動。

§ 它為某個特定原因而存在。一個抽象業務用例應該包含以下三類活動中的任意一類：多個業務用例中共用的活動；可選的活動；或那些非常重要、要在模型中強調的活動。

§ 

業務用例的屬性字段

RUP使用了“特征名”來指代屬性字段，見下表。

特征名	簡要說明	UML 表示
名稱	業務用例的名稱。	模型元素上的“名稱”的屬性。
簡要說明	業務用例的角色和目的的簡要說明。	标注值，“短文本”類型。
目标	業務用例的可評測目标的規約。	标注值，“格式文本”類型。
性能目标	與業務用例相關的度量規約和使用這些度量的目标的定義。	标注值，“格式文本”類型。
工作流程	業務用例所代表的工作流程的文本說明。該流程應描述業務為将值傳遞給業務主角所做的事件，而不是業務解決問題的方式。所有業務人員都應能了解該說明。	标注值，“格式文本”類型。
類别	業務用例的類别是“核心”、“支撐”或“管理”。	标注值，“短文本”類型。  另外，您可以選擇使用帶有特殊圖示的構造型來區分用例的類别。
風險	執行和/或實施業務用例的風險的規約。	标注值，“格式文本”類型。
可能性	業務用例的估計改進可能性的說明。	标注值，“格式文本”類型。
流程擁有者	對業務流程擁有者的定義是管理變更和計劃變更的人。	标注值，“格式文本”類型。
特殊需求	如前所述，工作流程未涵蓋的業務用例特征。	标注值，“短文本”類型。
擴充點	一組在業務用例的事件流程内的位置，在這些位置中使用擴充關系可插入其他行為。	标注值，“短文本”類型。
關系	用例參與的關系，如通信關聯關系、包含關系和擴充關系。	由附帶包通過聚合關系“owns”擁有。
活動圖	這些圖顯示工作流程的結構。	通過可追蹤到用例協作上的“types”和“relationships”的聚合關系擁有參與者。
用例圖	這些圖顯示涉及用例的關系。	通過可追蹤到用例協作上的“types”和“relationships”的聚合關系擁有參與者。
工作流程圖解	手繪的草圖或根據示意闆制作會議繪制的圖。	标注值，未解釋的類型。

來自于Rational後續的關于業務用例的文章

在《使用UML進行有效的業務模組化：描述業務用例和實作》中給出了詳盡的例子，依次用到了如下圖：

1. 業務用例圖

2. 業務用例實作的序列圖

3. 業務參與者和業務執行者參與業務的協作圖

a) 本段落花費了大段文字和圖表說明如何命名消息

4. 源自業務用例實作的用例圖

5. 狀态圖

仔細分析這個文章，可以發現全文充分運用了UML工具和各類UML圖，包括協助圖，序列圖等等，對接下去識别類，得到類圖很有幫助。此文對于業務用例與系統用例的比例給出了如下提示：

有多少個業務用例？

總的來說，業務用例的數量應該比系統用例的數量要少。業務用例的實作包括了業務參與者和業務執行者的參與，者兩者都将潛在的需要與系統進行互動，并且是以擁有他們自己的用例集合。通常情況下，業務用例對系統用例的比率應該在 1:5 到 1:10 之間。在我們的例子中，”準備 Tender“ 業務用例被用五個系統用例來表示，如圖 12 。業務用例的價值在于它将用例放到了上下文關系中 － 顯示一個業務用例組如何能夠被實作以傳遞業務價值。

如果業務用例和系統用例的數量是可比的（比如， 1:1 到 1:3 的比率），我将提出對業務模組化的要求。如果業務用例和系統用例的粒度是相似的，那麼其中的一個類型就是多餘的。

上述文字前中後竟然是沖突的。前半段提到“通常情況下，業務用例對系統用例的比率應該在 1:5 到 1:10 之間”，後半段卻講“如果業務用例和系統用例的數量是可比的（比如， 1:1 到 1:3 的比率），我将提出對業務模組化的要求。”，最後講“如果業務用例和系統用例的粒度是相似的，那麼其中的一個類型就是多餘的。” 這是明顯的邏輯錯亂。 當中如果修改為“如果業務用例和系統用例的數量是可比的（約1:5 到 1:10 的比率），我将提出對業務模組化的要求。”才合乎其全文邏輯。

就此文的例子而言，直接識别5個系統用例并不困難，可以講是比較容易，留意下原文的表2即可證明。

而關于目前流行的“業務價值”判斷，在靈活開發實踐，使用者故事的顆粒度一般而言要比用例小，而在使用者故事上開展的業務價值判斷、優先級調整已經得到廣大軟體界的公認，其有效而且高效。那麼回到業務用例和系統用例，何必非要在業務用例這個層面來判斷業務價值，直接在系統用例上判斷是完全可行的。而在目前短疊代增量開發的情況下，對于整個業務用例的優先級判斷無法指導具體疊代的範圍選擇，因為業務用例的體量往往大于一個疊代能夠完成的體量。甚至于系統用例都很可能超過一個疊代能完成的體量，是以最新的Use-Case 2.0引入了Use-Case slice的概念來切分用例，以便短疊代處理。

在《使用 UML 進行業務模組化：了解業務用例與系統用例的相似和不同之處》中

業務用例與系統用例的相似之處：兩個模型都有用例說明。如果您對業務用例模型以及系統用例模型的 RUP 模版進行檢查，您會發現它們的格式十分相似。兩者都包含先決條件、後置條件、擴充點 以及特殊需求。業務用例說明有基本的工作流和可選擇的工作流，進而取代了基本的事件流和可選流。

 文中提到了UML for the IT Business Analyst 中對業務用例的定義：

"業務用例：業務過程是描述這個業務的具體工作流的；一次涉衆與實作業務目标的業務之間的互動。它可能包含手工和自動化的過程，也可能發生在一個長期的時間段中。"

這個定義表明了通過實作業務目标創造價值的觀點。它通過把一個業務過程描述成一個可能包含手工和自動化過程的具體工作流來詳述 RUP 的定義。這個定義還指出，工作流可能發生在一個長期時間段中。所有的這些都十分的重要。

那麼系統用例又是怎樣的呢？系統用例的設計範圍就是這個計算機系統設計的範圍。它是一個系統參與者，與計算機系統一起實作一個目标。系統用例就是參與者如何與計算機技術相聯系，而不是業務過程。

UML 業務模型包括兩個模型：用例視圖（Use-Case View）中的業務用例模型和邏輯視圖（Logical View）中的業務分析模型。業務用例模型中的主圖是業務用例圖。您還可以随意加入表示單個業務用例的 UML 活動圖，來圖形化地顯示工作流過程。

業務分析模型描述了通過業務角色和業務實體的互動來實作業務用例。它用作業務角色和業務實體需要如何相關聯，以及它們需要如何協作，來執行業務用例的抽象。業務分析模型中有三種類型的 UML 圖，如圖 3 所示：類（Class）、時序（Sequence）和通信（Communication）圖。

關于使用 RSA 和 UML 2.0 建立業務用例圖的提示：

§ 在 UML 1.x 中，您可以将參與者原型化為業務角色。在 UML 2.0 中，您必須建立一個類，然後将其原型化為業務角色。在 UML 2.0 中，您可以将參與者原型化為業務參與者，但您不能将參與者原型化為業務角色。

§ 在 UML 2.0 中，業務用例和業務角色之間的關聯是可導航的。業務參與者和業務用例之間的關聯是不可導航的。

§ 作為最佳實踐，我推薦斷開業務用例和業務角色之間的導航，進而保持業務角色與業務參與者的一緻。業務角色及其用例關聯應該按照業務參與者與業務用例通信的同樣方式來繪制。

§ 您必須在您的工程的 Properties 标簽頁中選擇 Profiles 頁籤，然後單擊 Add Profile 按鈕，來向您的工程中添加業務模組化和健壯性分析原型。在 IBM Rational Rose 中，這是自動包含的。在 UML 2.0 中，概要檔案用于包裝原型和标記值 UML 擴充。UML 2.0 規範要求您向 UML 模組化工程中添加概要檔案來使用業務模組化原型。

圖 7 顯示了業務模型中所找到的東西和系統用例模型中的東西之間的清晰映射。在此特殊的執行個體中，可以看出，系統能夠将業務角色的職責自動化。它還顯示出關鍵的業務角色是自動化的候選者。

記住，業務模型包含業務用例模型和業務分析模型。業務分析模型是業務用例模型的實作，并且擁有緊密的內建化和可追溯性。系統用例模型可以追溯到業務分析模型。業務分析模型可以追溯到業務用例模型。

使用該方法，您可以建構從業務分析模型演化來的系統用例模型。這向您的整個 UML 模型提供了一緻性和可追溯性。

對于Rational系業務用例的小結

如果隻通過以上文字，我估計讀者是難以真正了解業務用例，但是可以得出如下2點：

1，圍繞着業務用例的使用起源于RUP，後續雖然有演化，仍然有明顯的RUP痕迹，後續配套手段需要UML工具支撐，後續可以關聯到了類和類圖。

2，相關于業務用例的術語在RUP中有：業務用例，業務用例執行個體，業務用例實作，業務角色，業務實體，具體業務用例，抽象業務用例，業務流程，業務參與者和業務執行者等等。除了搞需求方法論研究的人（比如筆者），誰還能分辨其中差異和聯系？對比到使用者故事和用例分析，誰還願意選擇這業務用例分析？