絕大多數構架師都認為業務建模是開發軟件解決方案中到一個非常重要的活動。成功的解決方案會支持這個業務，它們能夠解決業務問題并確保業務目標的實現。

當開發一個合理的業務模型以后，業務流程分析員能夠探究不同業務改進的選項，比如取消多余的任務，使重復且平凡的任務或者容易出現的錯誤實現自動化操作。 IBM? Rational Unified Process?，或者 RUP?，以及 Unisys 3D Visual Enterprise， 或者 3D-VE， 或者 3D-VE,提供了一個系統化的方法，利用統一建模語言（UML）可以直觀地表現業務模型，同時還可以派生出一個一致的且能夠追溯到這個業務模型的起點系統用例模型。

這篇文章提供了 RUP 業務建模的概述，并解決了以下的問題：

• 業務用例模型與系統用例模型有怎樣的相似之處？
• 業務用例模型與系統用例模型有什么不同之處？
• 構建業務模型應該使用哪個 UML 圖？
• 業務用例模型與系統用例模型之間有什么關系？

在談論這個問題之前，我想解釋一下為什么要挑選這個特殊的話題來寫。自從1990年我就作為一名軟件構架師從事系統用例的工作。當我是一名由 Unisys Global Public Sector 開發的 Integrated Justice Information Sharing (IJIS) 框架解決方案的總構架師時，還沒有接觸到業務用例，直到2002年。IJIS 現在已經發展成為 Unisys Information Sharing Management Framework (ISM)。

ISM 是一套支持信息共享的總體業務過程的可重用的組件。ISM Framework 利用 Service Oriented Architecture (SOA) 技術整合了不同類型的司法與公共安全系統，從而在關鍵決定點時分配關鍵的數據，文檔以及圖片。ISM 解決方案將為司法與公共安全 團體提供了一個業務框架、技術框架、基礎應用軟件以及方法，使政府機構能夠繼續使用他們的遺留系統。

ISM 是使用 RUP 進行設計的，ISM 業務模型是為 ISM 項目開發的首批工件之一。開發 ISM 業務模型對我來說是一個有意義的學習經歷：我認識到的一個問題是，對于如何開發一個業務模型有很多含混不清的地方，為開發 UML 業務模型提供指導的文獻相對比較少，而且有些不一致。

自從我離開 Unisys Global Public Sector 加入到 Unisys University 作為一名培訓和開發顧問后，就一直負責開發和交付軟件構架和 IBM Rational 工具培訓。我的職責之一就是 IBM Rational 課程 "Mastering Requirements Management with Use Cases" (MRMUC) 的教學。這門課程主要闡述的是開發系統用例，但是這門課程僅僅提供了什么是業務模型以及它如何與這個系統用例模型相聯系的一個很有限的討論。因此這篇文章的目的之一就是為 MRMUC 課程補充材料。

這篇文章假定您已經有了系統用例建模和 RUP 需求規程的基本知識。如果您對系統用例建模并不熟悉，我建議您學習 RUP 需求規程的知識。

正如前面提到的，這篇文獻關于業務建模的內容比較少，但是我們發現了一些非常有用的參考資料，遠遠多于您在 RUP 中找到的信息：

• Writing Effective Use Cases， 由 Alistair Cockburn 編著。這是我最喜歡的關于業務和系統用例說明的著作。Alistair 強調一個業務或者系統用例模型最重要的部分是用例說明。這本書強調的就是用例說明，而不是 UML。
• UML for the IT Business Analyst， 由 Howard Podeswa 編寫。本書主要強調的是利用 UML 來開發一個業務模型，以及對 Alistair 的書進行補充。?UML for the IT Business Analyst?幫助我完成了關于如何開發一個有效的業務用例模型的課程培訓。
• Rational Edge?中的文章“Effective Business Modeling with UML: Describing Business Use Cases and Realizations”，由 Pan-Wei Ng 編寫。那篇文章與這篇文章有些類似。那篇文章是從 UML 1.x 的角度來編寫的。而這篇文章是從一個 UML 2.0 的角度來編寫的，并且闡述了業務用例模型，業務分析模型，以及系統用例模型之間更深刻的關系。

既然我已經完成了預備工作，就讓我們開始提一些問題。

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

業務用例說明與系統用例說明的格式十分相似，但是在設計范圍上有些分歧。業務用例的設計范圍是業務操作。它是這個組織外部的業務參與者，實現與業務組織相關的業務目標。讓我們查看這個業務用例的 RUP 定義：

簡單地說，這個定義標識了一些重要點，比如：

• 一個業務用例描述的是業務過程——而不是軟件系統過程。
• 一個業務用例為涉眾創造價值。這些涉眾要么是業務參與者要么是業務工作者。
• 一個業務用例可以超越組織的邊界。有些構架師對于這一點有非常嚴密的態度。許多業務用例確實超越來組織的邊界，但是有些業務用例僅僅關注于一個組織。我稍后將在這篇中給出一些例子。

讓我們也看看 Podeswa 的書?UML for the IT Business Analyst?中對業務用例的定義：

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

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

Cockburn 的?Writing Effective Use Cases?給業務和系統用例使用了相同的用例說明模版。業務用例與系統用例說明使用這個模版的區別是設計范圍，而不是模版。Cockburn 想通過目標層次對用例進行分類，如表格1所示。

Cockburn 編寫?Writing Effective Use Cases?的最初目標是系統用例，但他在業務用例上也花了很多精力。他利用目標層次來區分業務與系統用例，而不是使用不同的模版類型。那么這些圖標和目標層次又意味著什么呢？

這些圖標本身代表著一個簡單的系統，它是根據用例與“海平面”（用戶的實際層次）的相對高低來確定的。系統用例的最佳點是用戶目標，通過海平面圖標來表明。有時候需要將復雜的系統用例分解成其它有子功能目標、通過魚圖標表明的用例。但是您應該盡量避免將海平面系統用例分解成蛤或者最低層系統用例。

也許您會猜測到，概要或者蛤用例應該是業務用例。云或者高層概要也可能是業務用例。

Cockburn 的方法是將這些用例看作是一個光譜，從一個組織的最高層次業務目標，到為實現這些業務目標而執行的軟件解決方案的需求詳細資料。這種方法將系統用例看作是一個業務用例的分解。這個用例分解方法可以用來幫助您從這個業務模型驅動系統用例模型，我稍后會對這個問題進行討論。

那么業務用例模型與系統用例模型圖有什么其他相似之處呢？

• 兩者都有參與者。在業務用例圖中，您將一個參與者原型化為 <<BusinessActor>>。
• 兩者都有用例。在業務用例模型中，您將一個用例原型化為 <<BusinessUseCase>>。
• 在參與者與用例之間兩者都有一個通信關聯。
• 業務用例和系統用例都能夠包含、擴展，以及一般化關聯。

用例圖中的通信關聯對于學習用例建模的人們來說，通常是一個容易混淆的地方。我應該使用箭頭嗎？這個箭頭應該指向什么方向呢？通信關聯已經被描繪出來，因為 1.4 UML 規范是一條實線。這條線可以配上一個箭頭。這條線和箭頭代表角色與系統之間的雙方對話。如果呈現出一個箭頭，那么說明只有這個關聯末尾的“這個事物”能夠發起通信。沒有箭頭的表明任何一方都可以發起通信（而不是兩端都發起通信）。

UML 2.0 規范使它更簡單。UML 2.0 不允許角色與用例之間或者業務角色與業務用例之間存在這種可靈活操作的關聯。我個人比較喜歡箭頭，但是如果您把 IBM Rational Software Architect (RSA) 當作您的 UML 建模工具，您就不能在角色和用例之間描繪出一個箭頭。此時的 RSA 是完全沒有錯的。 UML 2.0 是通信關聯不可靈活操作的原因。

既然我們已經討論了業務用例模型和系統用例模型之間的相似之處，下面我們就看看它們的不同點。

業務用例模型與系統用例模型之間主要有三點重大不同之處：設計范圍、白盒測試與黑盒測試，以及業務操作者。

在前面的部分中，我借助 Alistair Cockburn 的處于“水平線”上面、下面，或正好處于“水平線”的規定對設計范圍進行了討論。

業務用例著重于業務操作。它們表示實現業務目標的業務中的具體工作流。業務過程可能涉及手工和自動過程，并且在一段長期的時間內進行。

系統用例著重于要設計的軟件系統。參與者如何與軟件系統進行交互？我們在系統用例說明中書寫的事件流應該足夠詳細，從而用作編寫系統測試腳本的出發點。

業務用例常常是以白盒形式編寫的。它們描述了被建模的組織中的人和部門之間的交互。我們使用業務用例來說明在“現有”業務模型中組織如何工作。然后我們重構“現有”的業務用例模型，讓其面向將要建模的組織的未來設計。我們需要創建什么新角色和部門來提供更多價值，或者消除業務問題？什么角色和部門需要消失？

系統用例幾乎總是以黑盒形式編寫的。它們描述了軟件系統之外的參與者如何與將被設計的系統進行交互。系統用例詳細闡明了系統需求。系統用例模型的目的是從涉眾的角度說明需求，而不是設計如何滿足需求。

那么業務角色是什么？在系統用例圖中，您只讓參與者與用例進行交互。但在業務用例圖中，您可以讓業務參與者和業務角色與業務用例進行交互。

業務參與者是業務之外的人。它可以是一個角色或其他組織實體。例如，在刑事審判系統中，業務參與者可以是證人、嫌疑犯、外部的政府機構，例如健康服務，或業務實體，例如，業務資信咨詢機構。

業務角色是業務內部的某個人或某個部門。在刑事審判系統中，業務角色可以是治安人員、法官、檢察官，或假釋官。當您實現了一個業務用例，并且創建了時序圖和/或 通信圖來顯示業務參與者、業務角色，和業務實體如何協作執行業務用例時，您將會把業務角色從業務用例模型轉入業務分析模型，并且加入所需的額外業務角色來提供業務用例功能。圖 1 顯示了基于 ISM 項目的示例業務用例圖。

圖 1：ISM 業務用例圖

圖 1 顯示了一個業務參與者：嫌疑犯（Suspect）。有三個業務角色：執法人（Law Enforcement）、檢察官（Prosecutor）和法院（Court）。有四個業務用例：逮捕被告（Arrest Subject）、請求擔保（Request Warrant）、獲得指紋和嫌疑犯照片（Capture Fingerprints and Mugshot），以及保釋（Release on Bail）。獲取指紋和嫌疑犯照片總是作為來自逮捕被告基礎業務用例的強制行為。保釋是繼承逮捕被告業務用例的可選行為。

早先，我討論了業務用例如何跨越組織邊界，許多情況都是這樣的。請求擔保就是一個好例子。它涉及執法人和法院 。業務用例還可以只集中在一個組織上。獲得指紋和嫌疑犯照片就是這樣一個好例子。

在我討論您在業務建模中使用的 UML 圖之前，我想說一些關于使用 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 建模工程中添加概要文件來使用業務建模原型。

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

圖 2：ISM 逮捕被告業務用例活動圖

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

圖 3：業務分析模型圖

業務分析模型中的主要的圖是時序圖。您手工地創建顯示出業務參與者、業務角色，和業務實體如何交互執行業務用例的時序圖。時序圖顯示出以時間時序安排的對象交互。特別是，它顯示出參與交互的對象，以及消息交換的順序。

通信圖是以前在 UML 1.x 中所稱的協作圖（Collaboration diagram），它描述了對象之間交互的模式，通過對象間的鏈接和發送給對方的消息來展示參與交互的對象。通信圖和時序圖都顯示出交互，但它們強調了不同的方面。時序圖清楚地顯示出時間順序，但沒有明確地顯示出對象關系。通信圖清楚地顯示出對象關系，但必須從順序號那兒獲得時間順序。

兩個圖都顯示出同樣的行為，但方式不同。我個人喜歡時序圖，因為它通常比較容易讀懂。您還可以使用參與類的視圖（View of Participating Classes，VOPC）來顯示協作執行業務用例的業務參與者、業務角色和業務實體的靜態視圖。

圖 4 顯示出 ISM 逮捕被告業務用例實現的時序圖。圖 5 顯示出 ISM 逮捕被告業務用例實現的 VOPC。圖 6 顯示出 ISM 逮捕被告業務用例實現的通信圖。

圖 4：ISM 逮捕被告業務用例實現的時序圖

在 ISM 逮捕被告業務時序圖這部分中，如圖 4 所示，有三個從業務用例模型轉入的業務角色：執法人、簽署者（Subscriber）和刑事審判系統。刑事審判系統是執法人、法院、檢察官，等等的一般化。為了讓時序圖簡單化，我們使用該泛化來表示 ISM 可以使用的任意刑事審判系統。

圖 4 還顯示出引入到業務分析模型中的兩個新的業務角色：檔案管理系統（Records Management System，RMS）和 ISM Broker。RMS 通常是商業化成品（commercial off-the-shelf，COTS）解決方案，它將地方的執法用作刑事案件管理系統。ISM Broker 是 Unisys 計劃開發的軟件解決方案的自動化候選者或代理。

Unisys ISM 解決方案利用中心輻射型 SOA 技術整合了多個各種各樣的司法系統，從而在重要決策點處，分享關鍵任務的數據、文檔、圖像和事務。ISM 可以在 Microsoft BizTalk Server 或 IBM WebSphere Business Integration 上實現。ISM Broker 作為在審判團之中數據共享的導管，并且利用當前的技術來推、拉、發布和訂閱信息，從而支持日常的審判操作。

圖 5：ISM 逮捕被告業務用例實現的 VOPC 圖

圖 5 中的 VOPC 圖顯示了參與逮捕被告業務用例的業務參與者、業務角色和業務實體的靜態視圖。注意為每個業務角色顯示的操作。這些操作被稱為業務職責。VOPC 圖的更精確的名稱是參與的業務參與者、業務角色和業務實體的視圖（View of Participating Business Actors,、Business Workers 和 Business Entities）。在本實例中，只有業務角色協作執行業務用例。

圖 6：ISM 逮捕被告業務用例實現的通信圖

如前面所提到的，通信圖（如圖 6 所示）是觀察時序圖中所示行為的另一種方法。RSA 提供了從時序圖創建通信圖的自動能力，反之亦然。

還有一個要回答的問題。

圖 7，業務用例到系統用例的向下流動（Business to System Use-Case Flow Down），出自我所教授的 IBM Rational 課程“Mastering Requirements Management with Use Cases”。

圖 7，業務用例到系統用例的向下流動

圖 7 例舉了課程中最難教授的主題之一，因為您要理解該圖所需的大部分基礎不在標準課程材料之內。本文的其中一個目的是提供額外的基礎。

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

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

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

那么系統參與者和系統用例從那里來的呢？系統參與者是根據業務分析模型中的業務參與者和業務角色而生成的。與業務角色自動化候選者交互的業務參與者總是成為系統參與者。不是自動化候選者的，與業務角色自動化候選者交互的業務角色成為系統參與者。例如，ISM 業務分析模型中的執法人和法院成為了系統參與者。ISM Broker 是“純”自動化候選者。它不會成為系統參與者。

我所謂的純是什么意思呢？簡單的說，自動化候選者的唯一目的就是成為我們正在開發的軟件解決方案的代理。注意到圖 7 中的 Loan Specialist。Loan Specialist 業務角色轉換為系統參與者和系統用例。讓我來解釋一下。

Loan Specialist 是圖 7 中所示的業務模型中的角色。在我們的系統用例模型中，需要有作為 Loan Specialist 角色的參與者。但是，在我們正在開發的新的軟件解決方案中將 Loan Specialist 的一些業務職責自動化了。業務分析模型中的那些業務職責成為了系統用例模型中的系統用例。

其他的純業務角色自動化候選者將不會轉換為系統用例模型中的系統角色。這回答了問題，“系統用例是從哪里來的？”系統用例是根據業務分析模型中的業務角色自動化候選者的業務職責而創建的。如果您回到圖 5，顯示了 ISM Broker 的 VOPC 圖，每個業務職責，例如 Query for Information，都可以轉換為系統用例模型中的系統用例。

分析模型顯示了業務實體如何映射到系統分析模型中的類上。這些類表示系統將使用的“數據”。

我的目標是概括出 RUP 業務建模和系統用例建模的比較情況。我討論了相似點和差別，以及業務用例模型和系統用例模型之間的關系。如果您對這些比較和關系有任何疑問，可以通過 arthur.english@unisys.com 聯系我。

¹用例視圖（Use-Case View）、邏輯視圖（Logical View）是 UML 4+1 視圖模型架構（UML 4+1 View Model Architecture）的一部分。要了解更多關于 4+1 視圖模型架構的信息，您應該學習分析與設計規程中的 URUP 軟件架構概念。

尊敬的讀者：現在有了一個特別為?Rational Edge?的文章創辦的?新論壇，現在您就可以分享您對本文或本期雜志或以前雜志中的其他文章的想法。閱讀世界各地您的同行們所說的內容，生成您自己的討論，或者加入正在進行的討論。單擊?此處開始。

• 您可以參閱本文在 developerWorks 全球網站上的?英文原文。
• 您可以參閱?Rational Edge 電子月刊中文版?的其他文章。