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

來源：http://www.uml.org.cn/requirementproject/200707024.asp

作者：Arthur V. English 出處：IBM

本文來自于  Rational Edge：學習有關業務用例與系統用例相似和不同之處的知識，包括應該使用什麼樣的 UML 圖，通過 IBM Rational Software Architect 或者其它模組化工具來模組化這些用例。 絕大多數構架師都認為業務模組化是開發軟體解決方案中到一個非常重要的活動。成功的解決方案會支援這個業務，它們能夠解決業務問題并確定業務目标的實作。 當開發一個合理的業務模型以後，業務流程分析員能夠探究不同業務改進的選項，比如取消多餘的任務，使重複且平凡的任務或者容易出現的錯誤實作自動化操作。 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所示。 圖1： Alistair Cockburn 對業務和系統用例的分類 高層概要 概要 使用者目标 子功能 最低層 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）中的業務分析模型。 1 業務用例模型中的主圖是業務用例圖。您還可以随意加入表示單個業務用例的 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 業務模組化和系統用例模組化的比較情況。我讨論了相似點和差别，以及業務用例模型和系統用例模型之間的關系。如果您對這些比較和關系有任何疑問，可以通過 [email protected] 聯系我。 1用例視圖（Use-Case View）、邏輯視圖（Logical View）是 UML 4+1 視圖模型架構（UML 4+1 View Model Architecture）的一部分。要了解更多關于 4+1 視圖模型架構的資訊，您應該學習分析與設計規程中的 URUP 軟體架構概念。 尊敬的讀者：現在有了一個特别為 Rational Edge 的文章創辦的 新論壇，現在您就可以分享您對本文或本期雜志或以前雜志中的其他文章的想法。閱讀世界各地您的同行們所說的内容，生成您自己的讨論，或者加入正在進行的讨論。單擊 此處開始。 您可以參閱本文在 developerWorks 全球網站上的 英文原文。 您可以參閱 Rational Edge 電子月刊中文版 的其他文章。 Cockburn，Alistair。 Writing Effective Use Cases. Addison-Wesley：2001 年。 Podeswa，Howard。 UML for the IT Business Analyst. Thomson Course Technology：2005 年。 Eriksson、Hans-Erik 和 Magnus Penker. Business Modeling with UML: Business Patterns and Business Objects. Wiley：1999 年。 Ng，Pan-Wei。 “Effective Business Modeling with UML: Describing Business Use Cases and Realizations.” Rational Edge：2002 年。 Booch、Grady、Jacobson、Ivar，和 Rumbaugh， James。The Unified Modeling Language Reference Manual，第二版. Addison-Wesley：2005 年。