從業務流程中識別用例

開發團隊可以使用業務流程模型來視覺化地記錄業務工作流程，並將用例與這些業務流程關聯，以模擬系統應實現的期望功能。在本教程中，我們將詳細說明如何使用模型轉換功能來建立用例與業務流程之間的可追溯性。

什麼是 BPMN 和 BPD？

BPMN為業務分析師提供一組圖形符號，用於模擬業務流程。它最初由 業務流程管理倡議（BPMI）開發，現由 物件管理集團（OMG）維護。開發 BPMN 的其中一個動機是為不同角色、不同國家和/或使用不同語言的人提供一種通用的圖形語言，使他們能夠無障礙地理解相同的業務流程。

BPD，即 業務流程圖，是使用 BPMN 模擬業務流程的地方。它是一種類似流程圖的圖表，用以描述流程、參與者以及參與者之間的訊息交換。業務分析師繪製 BPD 來模擬不同參與者如何協作以達成業務目標。在與最終用戶驗證完完整的業務模型後，系統分析師便可開始規劃系統。

以下是某組織註冊流程的簡單 BPD。它涵蓋了您通常會看到的大多數典型建模符號。讓我們來看看。

符號	描述
	池 – 代表流程中的參與者。在 BPMN 中，池和泳道均用於表示參與者。泳道包含於池中，用以模擬父池的子區分。
	開始事件 – 流程的起點。可以定義觸發條件，以告知讀者在何種情況下流程將被觸發。例如，當收到電子郵件/當是星期一早上/當發生錯誤時。
	任務 – 指定參與者（由池/泳道建模）可能執行的原子活動。任務及其他流程對象連接在一起，形成完整的業務工作流程。
	結束事件 – 流程的終點。可以定義結果，以告知讀者流程結束時會發生什麼。例如，發出信號/產生錯誤等。

在本教程中，我們不會過度著重於 BPD 或業務流程建模。如果您想了解更多關於 BPMN、BPD 或業務流程建模的內容，請閱讀教程《BPMN 第一至第四部分.

什麼是用例圖？

用例建模是指使用 UML 用例圖來捕捉高階用戶需求的技術。用例模型是為軟體或系統設計師設計的，而非業務人員。

用例圖中有三個主要元素。

符號	描述
	用例 – 每個用例代表一個使用者目標，也就是系統使用者想要達成的目標。請注意，用例僅能用來呈現使用者想要執行的動作，而非開發人員需要開發的功能，儘管在某些情況下兩者可能相同。若要記錄或模擬用例中涉及的功能，可使用事件流程工具，或透過「」來詳述一個用例。順序圖／活動圖請記住，用例建模的目標在於模擬使用者想要達成的事物。
	參與者 – 系統的使用者。這裡的「使用者」並不限於人類，也可以是與我們系統互動以達成特定商業目標的系統。
	通訊連結／關聯 – 連接參與者與用例，以表示參與者對系統的存取。每個通訊連結都代表參與者與系統之間的一系列交易。

從BPD轉換至用例圖

雖然BPD與用例圖不一定需要相互依賴，但它們在某種程度上可以相互補充。通常，我們開發軟體是為了自動化或優化某些業務流程。透過BPD，你可以了解參與者如何協作，以及誰對何事負責，進而識別出他們需要系統支援的功能。使用者所期望的系統功能（工作流程或業務流程）可以透過用例來建模，並由團隊後續開發。因此，我們可以說，BPD有助於你識別待開發系統的用例。

Visual Paradigm 是一款視覺化建模工具，可透過模型轉移功能，在兩個模型之間建立可追蹤性連結，支援從執行業務流程到用例建模（從業務需求到應用需求）的整個過程。我們需要可追蹤性，原因如下：

• 透過研究用例所涉及的流程部分，我們可以確保系統能符合現實世界的使用情境。
• 透過追蹤用例所源自的流程部分，回答「我們為什麼需要這個（系統）功能？」之類的問題。
• 透過從BPD追蹤至用例圖，回答「某項特定操作是否已經實作？」之類的問題。

BPD 與用例圖

當你將BPD轉換為用例圖時，可從欄位／池產生參與者，並從任務／子流程產生用例。下表顯示了在模型轉換方面，池、欄位、參與者、任務、子流程與用例的特徵。

來源	目標	說明
		池／欄位轉為參與者 在BPD中，池代表業務流程的參與者，而欄位是池的子區分。任何有相關活動需要執行的人，都被視為參與者。在用例圖中，參與者代表系統的使用者。請記住，任何非系統使用者的人或角色都不應被視為參與者。
		任務／子流程轉為用例 在BPD中，任務／子流程（活動）指的是參與者為完成業務流程可能執行的任何動作。在用例圖中，用例呈現使用者使用系統所希望達成的目標。請記住，活動不一定與任何系統功能相關，且一個用例可能滿足多個活動。

有些人可能會認為用例圖與BPD類似，但在符號與目的上卻大不相同。請記住，BPMN是為業務人員設計的，而用例圖則是為系統分析師或系統開發人員所設計。它們有不同的用途，並從兩種截然不同的角度來理解業務。這也正是我在前一節中總結BPD與用例圖關係時，說出「BPD有助於你識別用例」的原因。BPD僅能在識別用例時提供提示。並無任何規則規定BPD中的每一項任務都等同於一個用例。但我們可以透過用例來詳述業務流程，以實現目標系統對某項功能的自動化。

在案例研究中，我將提供一些關於你在將BPD轉換為用例圖時應注意事項的提示。如此一來，你將能理解它們之間的差異。

案例研究：真水純水公司

真水純水公司是一家位於城市的年輕純水供應商，他們將純水銷售給企業與家庭使用。以下是其送水流程的文字描述。

訂購純水的方式，客戶可撥打訂購熱線或寄送電子郵件給我們。目前，90%的訂單來自電話，而10%則是透過電子郵件下單。接獲訂單的客服人員會確認該客戶是現有客戶還是新客戶。若客戶從未下過單，客服人員將先為其建立客戶帳戶，再進行送水作業。 純水的送達每週一次，固定於每週三進行。因此，每週三早上，客服人員會將訂單轉交至物流部門進行送達。一旦物流部門的經理收到訂單，便會安排送達，透過指派工人處理不同訂單、列印並張貼排程表。工人收到通知後，便依指示將水送達客戶。

根據上述描述，已建立一個業務流程模型。現在我們要求你開發一套電腦系統，以優化整個流程。你首先需要做的事，是建立一個用例模型。在BPD的協助下，嘗試建立一個用例圖。

1. 下載 純水送達.vpp。你也可以在本教學的底部找到此檔案。
2. 在 Visual Paradigm 中開啟下載的 .vpp 檔案。若要開啟專案，請選擇專案 > 開啟於應用程式工具列中。
3. 開啟 BPD純水訂購流程。仔細研究流程。
   
4. 流程在客戶下訂單時開始。在此我們可以考慮一個使用案例——下訂單。使用案例將透過提供介面讓客戶在無需客服助理協助的情況下下訂單，協助驗證客戶身分，並在客戶不存在時建立帳戶。右鍵按一下「下訂單」，然後選擇相關元素 > 轉移至新使用案例…於捷選功能表中。
   
5. 這會觸發轉移模型元素視窗，您可以在其中選擇要放置使用案例與參與者之模型，並重新命名。在此情況下，我們對使用案例與參與者的名稱感到滿意。讓我們保持不變。按一下確定.
   
   這會在 UeXceler 中形成一個新的使用案例圖。
   
6. 回到 BPD。
7. 讓我們考慮一下任務建立客戶帳戶。在業務流程中，客服助理需要為每位新客戶建立帳戶。在新系統中，這可以是「下訂單」使用案例的一部分，或由客服助理手動觸發的獨立使用案例。在現實情況下，您應與相關方釐清此類疑問，因為錯誤的使用案例模型將導致開發出不符合使用者期望的功能。在此範例中，我們假設使用者希望「建立客戶帳戶」任務由客服助理執行。讓我們從此任務建立一個使用案例。右鍵按一下下訂單使用案例，或由客服助理手動觸發的獨立使用案例。在現實情況下，您應與相關方釐清此類疑問，因為錯誤的使用案例模型將導致開發出不符合使用者期望的功能。在此範例中，我們假設使用者希望「建立客戶帳戶」任務由客服助理執行。讓我們從此任務建立一個使用案例。右鍵按一下建立客戶帳戶，然後選擇相關元素 > 轉移至新使用案例…於捷選功能表中。
   
8. 再次，我們對使用案例與參與者的名稱感到滿意。請保持「轉移模型元素」視窗中的所有內容不變。按一下確定。用例圖已更新，新增了一個用例和參與者。我們來看一下。
   
9. 回到BPD。我們繼續討論子流程安排配送。物流部門的經理可以使用系統進行排程並通知員工送水。因此，這也是系統的一個用例。右鍵按一下子流程安排配送，並選擇相關元素 > 轉移至新用例……自彈出式功能表中。
10. 在轉移模型元素視窗中勾選參與者「經理」。如果我們保留參與者的名稱為經理，這在用例模型中會產生歧義，因為公司內可能有許多部門，每個部門都有不同的經理。因此，請將參與者重新命名為物流部門經理.
    
11. 按一下確定。用例圖已更新。
    
12. 回到BPD。最後一項任務送水是一項只能由人類完成的工作，與系統互動無關。因此，我們不需要為它建立用例。
13. 假設區域經理希望系統支援一個新功能，可產生報告以顯示訂單統計資料。此功能可協助他檢視並優化行銷策略。雖然此功能尚未在業務流程模型中建模，但我們可以直接在用例圖中繪製。開啟用例圖。繪製參與者區域經理。從中建立一個用例產生統計報告，並以關聯連接。
    
14. 假設客戶希望允許客戶檢視帳單明細並取消訂單。此外，客戶也希望允許物流部門經理列印物流報告。請分別繪製這些用例。
    
15. 整理圖面。
    
16. 轉移關係可讓您從用例模型追溯至業務流程模型（反之亦然）。我們來試試看。將滑鼠指標放在下單 使用案例。
    
17. 點擊模型轉接器 資源，位於形狀的右下角。選擇轉接來源 > 蒸餾水訂購流程<。下單 從彈出式選單中。
    
    這會開啟 BPD，並選取任務下單 已選取。