用例分析教程

什麼是用例圖？

UML用例圖是正在開發的新軟件程序的系統/軟件需求的主要形式。用例圖的目的是可視化系統應該做什麼（什麼）；在這個階段，它不考慮如何（如何）去做。

一旦指定了用例，就可以用文本和可視化的表示（即用例圖）來表示它。用例建模的一個關鍵概念是它幫助我們從最終用戶的角度設計系統。它是一種通過指定所有外部可見的系統行為以用戶術語來傳達系統行為的有效技術。

換言之，必須從外部來看待系統的使用，即不應該從內部來看待系統，而是從更高的層面來確定係統應該提供給外部參與者的功能。

用例圖的目的

用例圖通常是在開發的早期階段開發的，人們經常將用例建模用於以下目的。

• 指定係統的上下文
• 捕獲系統的需求
• 驗證系統架構
• 推動實施並生成測試用例
• 由分析師、領域專家和目標最終用戶共同開發

用統一建模語言定義了標準形式的用例圖，如下面的用例圖示例所示。

編輯此用例圖示例

用例圖的元素

演員

每個用例都會有至少一個參與者，可以理解為至少一個參與者（角色），參與者（角色）不一定是人，也可能是另一個系統或設備。一個參與者可以與多個用例交互，一個用例可以與多個參與者交互。

參與者不一定是人，即用戶，但他們實際上可以是非人，即係統或時間。

大多數情況下，用戶是參與用例圖的人，例如客戶、員工、主管等。

人類與非人類演員

有時，系統會受到各種事件的影響，以在給定情況下執行某些功能。比如審核通過後，系統主動發信通知人；那麼信件的發送是由系統自動執行的嗎？這個用例其實是由時間觸發的，那麼actor就是Timer；比如這個用例可以看成“每天5:00自動發送一封信”，那麼觸發這個事件——發送一封信——的actor就不是系統，實際上是Timer Actor

主要與次要演員

主要參與者是使用系統實現目標的參與者。用例記錄了系統和參與者之間的交互，以實現主要參與者的目標。次要參與者是系統需要協助以實現主要參與者目標的參與者。

• 演員可能是主要的或次要的。主要參與者啟動與系統的交互。
• 系統通常會調用次要參與者尋求幫助，並且次要參與者從不啟動用例。

請注意：演員的符號不區分主要演員和次要演員；必須從用例描述（也稱為用例敘述）中推斷出差異。

例如：

銀行信貸員想要審查客戶的貸款申請，部分流程涉及實時信用評級檢查。

編輯此用例圖示例

• 用例名稱。審查貸款申請
• 主要演員。信貸員
• 次要演員。信用評級系統

如何識別演員？

由於參與者不一定是人，而可能是外部系統、設計或計時器，我們通過詢問以下問題來找到更具體的參與者

• 一旦系統開發完成，誰將使用該系統？
• 系統需要從誰或哪些其他系統獲取數據？
• 該系統將為誰或其他哪些系統提供數據？
• 該系統將與哪些其他系統相關聯？
• 誰將維護和管理系統？

這些問題幫助我們抽像出系統的參與者。以 ATM 為例，回答這些問題可以讓我們找到更多的參與者，即

• 運營人負責維護和管理 ATM系統
• ATM 還需要與後端服務器通信以獲取有關用戶帳戶的信息。

用例

用例表示預期由系統實現的功能（通常是需求）。用例的細節，除了它的唯一名稱，沒有在圖中直觀地表示；這些細節在用例的敘述（文字描述）中給出。

用例是一系列動作或事件步驟，通常定義參與者角色與系統之間的交互以實現目標。用例是識別、澄清和組織系統需求的有用技術。用例由系統和用戶之間可能的交互序列組成，這些交互序列定義了要實現的功能以及可能遇到的任何錯誤的解決方案。

如何識別用例？

一旦我們找到了參與者，我們就可以根據參與者確定係統的用例，主要看每個參與者需要從系統提供哪些服務，或者參與者如何使用系統。用例的識別可以從以下問題開始（針對每個參與者）。

• 演員為什麼要使用這個系統？
• 參與者是否在系統中創建、修改、刪除、訪問和存儲數據？如果是這樣，演員如何執行這些操作？
• 參與者是否通知系統某些外部事件？
• 系統是否會通知參與者某些內部事件？

綜上所述，ATM系統的用例圖可以表示如下。

用例由橢圓、靜態或動態、任務或系統表示。

系統邊界

系統邊界通過在矩形邊界中對用例進行分組來描述系統，Visual Paradigm 中的系統邊界提供了用例包含行為。

參與者是與正在開發的系統交互的角色（人類參與者或非人類參與者）。因此，參與者應該被放置在系統邊界之外，並與放置在系統邊界內的用例進行交互。

注意： 

參與者由系統的邊界定義。如果我們要定義的系統邊界僅限於ATM本身，那麼後端服務器就是一個外部系統，可以抽象為一個actor。

如果我們要定義的系統邊界擴展到整個銀行系統，其中 ATM 和後端服務器都是整個銀行系統的一部分，那麼後端服務器不再被抽象為參與者。

關係

了解這三個關鍵符號後，繼續學習關係知識並繪製用例圖。繪製了參與者和用戶案例之間的直接關係，並將該關係用作沒有箭頭的線，表示雙向關係，稱為鏈接線。

一個用例可以分解成幾個用例，這些用例通過 <<include>>、<<extend>> 或 <<generalization>> 關係（在本文後面描述）連接起來。

通信鏈路關係

這表示參與者和用例之間的雙向通信，因此是二元關係。

編輯此用例圖示例

<<包含>> 關係

包含關係意味著用例將包含其他用例。包含關係的目的是使用包含關係來減少再次描述相同用例的重複。如果多個案例共享相同的部分功能，則可以將功能分離出來，並將其他用例包含在案例中。

例如，圖書管理員借書時需要讀取代碼記錄借書，還書時還需要讀取代碼記錄歸還圖書，因為讀取代碼是一個重複的動作部分，可以做成一個單獨的用例，讓借書和還書都包含這個用例。

編輯此用例圖示例

如果一個用例 A 包含另一個用例 B，那麼 A 的實現需要 B 的實現來完成它的任務。但是，B 是獨立於自身的。也就是說，B 不需要知道關於 A 的任何信息。B 也可以包含在任何其他用例中。

<<擴展>> 關係

如果一個用例 B 擴展了另一個用例 A，那麼 A 的實現可以有條件地包括 B 的實現以完成其任務。也就是說，在某些情況下，A 可以在沒有 B 的情況下完成其任務。但是，根據所描述的條件，A 可能需要 B。在這種情況下，B 依賴於 B。但是，根據所描述的條件，A 可能需要 B . 在這種情況下，B 依賴於 A，不能單獨存在。因此，B 不能擴展到一個以上的用例。A 的用例敘述將包括它需要 B 的執行步驟；這個點稱為擴展點。

編輯此用例圖示例

讓我們看另一個例子，當沒有庫存時系統會自動訂購貨物，這樣經理就不必直接執行訂單。請參見下面的用例圖：

編輯此用例圖示例

泛化關係

泛化關係類似於類圖中面向對象語言的泛化關係，可以應用於角色（參與者）和用例的泛化。

比如在訂票系統中，有兩種​​訂票方式：“電話訂票”和“網上訂票”，基礎用例“訂票機”，可以用泛化的方式來塑造案例，並將 <<essential>> 添加到父用例（預訂）以指示廣義關係。

編輯此用例圖示例

討論用例圖中的關係

• 在一般用例圖中，我們只表示參與者和用例之間的關係，即它們之間的通信關聯。
• 此外，我們還可以描述參與者和參與者之間的泛化，以及用例之間的包含、擴展和泛化關係。
• 我們使用這些關係來適應現有的用例模型，並提取一些通用信息以供重用，使用例模型更易於維護。
• 但是，我們在應用程序中選擇這些關係時必須小心。通常，這些關係會增加用例和關係的數量，從而增加用例模型的複雜性。
• 而且，用例模型通常是在完成後才進行調整，所以在用例建模的早期，不需要急於抽像用例之間的關係。

用例——事件流

用例圖為我們提供了系統功能的整體視圖，我們可以知道哪些參與者將與系統交互，以及每個參與者需要從系統中獲得哪些服務。

用例描述了參與者和系統之間的對話，但是這個對話的細節並沒有在用例圖中表示，所以對於每個用例，我們可以用事件流來描述這個對話的細節。

用例場景和事件流程 – ATM 取款

例如，ATM 系統中的“取款”案例可以用如下事件流來表示：

正常場景——提款——事件的基本流程：

1. 用戶插入信用卡
2. 輸入密碼
3. 輸入提款金額
4. 提取現金
5. 退出系統並取回信用卡

但這僅描述了提款用例的正常場景。作為一個真正的 ATM 系統，我們還必須考慮可能出現的各種其他情況，例如：

• 無效的信用卡，
• 密碼錯誤，
• 用戶賬戶現金餘額不足等

所有這些可能的情況（正常和異常）都稱為用例場景，場景也稱為用例實例。場景也稱為用例的實例。在一個用例的各種場景中，最常見的場景由基本流程描述，而其他場景由替代流程描述。

替代方案

對於 ATM 系統中的“取款”用例，我們可以得到一些替代流程，如下所示。

提款 – 替代事件流程。

1. 備選方案 I：用戶可以在基本流程的任何步驟選擇退出，並轉到基本流程的第 5 步。
2. 備選流程二：在基本流程的第1步，用戶插入一張無效的信用卡，系統顯示錯誤並退出信用卡，用例結束。
3. 備選流程三：基本流程第2步，用戶輸入錯誤密碼，系統顯示錯誤提示用戶重新輸入密碼，返回基本流程第2步；密碼輸入錯誤 3 次後，信用卡被系統沒收，用例結束。
4. …

通過結合基本場景和替代場景，可以清楚地描述一個用例中可能發生的所有各種情況。在描述一個用例的事件流程時，我們希望盡可能描述所有可能的場景，以保證需求的完整性。

用例模型與用例圖

重要的是要避免將由參與者和用例組成的用例圖是用例模型的誤解，因為用例圖只是系統可以提供的服務的可視化表示，讓我們大致了解系統的功能。

用例模型包括一個用例圖和每個用例的詳細描述，即用例規範，它在 RUP 中作為模板提供。

簡要說明
簡要說明用例的作用和目的。

事件 
流 事件流應該代表所有場景，包括基本場景和替代場景。

用例場景
包括成功場景和失敗場景，場景主要是基礎流程和備選流程的結合。

特殊需求
描述與用例相關的非功能性需求（包括性能、可靠性、可用性、可擴展性等）和設計約束（操作系統、開發工具等）。

前置條件
在執行用例之前系統必須處於的狀態。

後置條件
執行用例後系統可能處於的狀態集。

用例規範本質上是一種文本表示，可以選擇使用狀態圖、活動圖或序列圖來幫助更清楚地描述事件流。用戶界面和流程的任何圖形表示或其他圖形（即線框）都可以附加到用例中，只要它們有助於提高表示的清晰度即可。

例如：

• 活動圖可用於描述複雜的決策過程，
• 狀態轉換圖可用於描述與狀態相關的系統行為，以及
• 序列圖適用於描述基於時間的消息傳遞。

用例工具

網絡版

免費繪圖工具Visual Paradigm Online（VP Online）免費版支持UML、ERD和組織結構圖。您可以使用直觀的 UML 繪圖編輯器快速繪製用例圖。這個免費的UML工具沒有廣告，沒有限制訪問期限，也沒有圖表數量，形狀數量等限制。自由繪製UML。自由繪製UML。您擁有您為個人和非商業目的創建的圖表。

桌面版

Visual Paradigm Community Edition於 2004年推出，僅提供用於非商業目的的免費 UML 軟件，支持剛開始 UML 建模的用戶，以及需要免費的跨平台 UML 建模軟件的用戶個人使用，例如在學生項目中應用 UML。

參考

• 什麼是用例圖？
• 用例模型中的參與者類型
• 用用例圖識別用戶需求
• 什麼是用例規範？
• 敏捷軟件開發的用戶故事與用例
• 敏捷開發的用例驅動方法

UML 資源

• 什麼是 UML？
• 為什麼要進行 UML 建模？
• 14 種 UML 圖類型概述