用例圖 (Use Case Diagram) 是用來顯示一組用例、參與者以及它們之間關係的圖。它描述了使用者希望如何使用一個系統。通過用例圖可以知道誰是系統相關的使用者，他們希望系統提供哪些服務，以及他們需要為系統提供什麼樣的服務。
用例圖能給我們帶來什麼？
- 用來描述要開發的系統的功能需求和系統的使用場景。
- 促進開發過程中各個階段工作的進展。
- 用來驗證與確認系統需求。
用例建模是實現系統需求分析的一個很好的方法，通過它可以使得系統分析員和客戶之間能夠更好地溝通系統的需求。
用例圖的組成
在介紹中我們說到用例圖是顯示一組用例、參與者之間關係的圖。接下來的內容詳細的闡述了什麼是用例、什麼是參與者以及他們之間有什麼樣的關係。
參與者 (Actor)
參與者也叫角色，它表示了系統的使用者。這裡需要注意的是：這裡的使用者並不特指人，如果我們開發的是公共 API 專案，那麼這個時候，API 的呼叫者就是我們的使用者。
參與者指的不是使用者本身，而是它在系統中所扮演的角色。舉個例子來說，張三是淘寶店的店主，這個時候他參與淘寶的互動時，他既可以是店主這個角色，也可以作為買家在淘寶上購買東西，這個時候張三在系統中扮演了兩個角色，這兩個角色是兩個不同的參與者即買家和賣家。
參與者的作用是：
- 建立系統的外部使用者模型
- 對系統邊界之外的物件進行描述
我們先來看兩個案例：
例：銷售員每天下班前將當日銷售情況通過郵件傳送給銷售經理，由銷售經理將總的銷售記錄進行彙總錄入到系統中。
這個時候和系統進行互動的人是銷售經理，所以銷售經理是系統的參與者。
參與者在我們程式碼中，本質上還是類，所以在參與者中也存在繼承的關係（分析階段一般用泛化關係來表示繼承）。泛化關係 (Generalization) 表示一個一般性的參與者（父參與者）和另一個特殊參與者（子參與者）之間的聯絡。參與者之間的泛化關係用帶空心箭頭的實線來表示，箭頭端表示父參與者。
在上面的圖中，我們可以發現，管理員和普通使用者都是使用者的特殊化，所以可以抽象出一個父參與者來，管理員和普通使用者都擁有使用者的全部特性，同時還具有自己特殊的特性。
用例(Use Case)
需求分析是軟體開發流程中必不可少的一個環節，其主要目的就是建立待開發系統的模型，而用例則是建立這些的最好方法。
用例是對一組動作的描述，系統通過執行這些動作將對用例的參與者產生可以看到的結果。用來描述參與者可以感受到的系統服務或者功能。
在 UML 中，用例通常用一個橢圓形符號來表示：
在電商系統中，“加入購物車”就是一個用例，在社交軟體中，“傳送訊息給某人”就是一個用例。
使用用例進行系統需求分析的特點：
- 用例是從系統的使用者角度來描述系統中的資訊，即在系統的外部所能看到的系統的功能，而不考慮系統內部對該功能的具體實現
- 用例描述了一下可見需求，對應一個具體的使用者目標。使用用例可以用來劃分系統與外部實體的界限。
- 用例通常由某個參與者來執行。
- 用例把執行結果返回給參與者。
- 用例在功能上具有完整性。它從參與者接受輸入，再將產生的結果輸出給參與者。
一般情況下，我們如果向其他人描述一個一個功能的具體資訊呢？我們通過文字來對功能進行講解。用例圖只是簡單的用圖形方式描述系統，關於功能的完整解說還是需要用文字來表達。所以，對於用例，我們需要由詳細的說明，這樣才能讓其他人更加清楚的瞭解這個系統。這個時候我們就需要編寫用例描述了。
通常不會對用例描述做硬性規定，但是一些複雜的或者是重要的用例還是要編寫用例描述。用例描述一般包括用例編號、用例說明、前置條件、基本事件流、其他事件流、異常事件流和後置條件等。
下面是“加入購物車”用例的詳細描述：
| 元素 | 描述 |
|---|---|
| 用例名稱 | 加入購物車 |
| 用例標識 | UC001 |
| 簡要說明 | 將商品新增到使用者購物車中 |
| 前置條件 | 使用者已經登入 |
| 基本事件流 | 使用者向系統傳送加入購物車的請求，系統需要對商品的庫存、使用者購物車數量進行驗證來判斷是否能夠加入到購物車中 |
| 其它事件流 | 無 |
| 異常事件流 | 如果商品庫存不足，則告知使用者庫存不足無法新增；如果使用者購物車已達上限，則告知使用者購物車已滿，需要刪除部分商品後才能新增 |
| 後置條件 | 新增成功後，需要對使用者購物車數量重新進行統計 |
| 註釋 | 無 |
說完用例，我們來說說用例之間的關係
用例之間的關係
包含關係
包含關係指的是兩個用例之間，其中一個用例(基本用例)的行為包含了另外一個用例(包含用例)。
在 UML 圖中，包含關係用帶箭頭的虛線表示，並且線上標有<<include>>，箭頭的方向是從基本用例到包含用例。
擴充套件關係
擴充套件關係是對基本用例的擴充套件，基本用例是一個完整的用例，即使沒有子用例參與，也可以完成一個完整的功能。擴充套件的基本用例中存在一個擴充套件點，只有擴充套件點被啟用時，子用例才會被執行。擴充套件關係是從擴充套件用例到基本用例的關係，它說明擴充套件用例如何插入到基本用例中。
擴充套件用例的使用場景：
- 表明用例的某一部分是可選行為
- 表明只在特定條件下才執行的分支
- 表明可能有一組行為，其中的一個或多個行為可以在基本用例中的擴充套件點處插入。所插入的行為和順序取決於在執行基本用例時與主角進行的互動。
在 UML 圖中，使用帶箭頭的虛線表示，並且虛線上標有 <<extend>>:
泛化關係
泛化關係指的是一般(父用例)與特殊(子用例)的關係。當多個用例共同擁有一種類似的結構和行為時，可以將它們的共性抽象為父用例，其他的用例作為泛化關係中的子用例。
分組關係
在一些用例圖中，用例數量可能很多，這個時候就需要把這些用例組織起來。
用例圖建模及應用
建立用例圖模型主要包含3部分內容：
- 識別系統中的角色和用例
- 區分用例之間的先後次序
- 建立用例圖模型結構
識別系統中的角色和用例
這部分工作通常由系統分析員通過和客戶溝通來完成。
要獲取系統的用例，首先要找出系統的角色。
要獲取系統角色可以在與客戶溝通時，詢問使用者一些問題來識別角色。可以參考下列問題：
- 誰將使用系統的主要功能？
- 是需要系統的支援以完成日常工作？
- 誰負責維護、管理系統並保持系統正常執行？
- 系統需要與哪些外部系統互動？
- 系統需要處理哪些硬體裝置？
- 誰對系統執行產生的結果比較感興趣？
當我們獲取到系統角色後，我們可以通過角色來列出它的用例。可以通過回答下列問題來識別用例：
- 每個角色執行的操作有什麼？
- 什麼角色將要建立、儲存、改變、刪除或者讀取系統中的資訊？
- 什麼用例會建立、儲存、改變、刪除或讀取這個資訊？
- 角色需要通知外部系統的突然變化嘛？
- 系統需要通知角色正在發生的事情嗎？
- 什麼用例將支援和維護系統？
區分用例優先次序
某些用例必須在其他用例完成之前完成，因為它們是相互依賴的。例如在購買商品前，使用者必須先登入。
構建用例圖模型
將已經確定並細化的角色和用例放入用例圖。再借助包含、擴充套件和泛化的關係給出用例之間的結構模型。
在系統需求分析中需要考慮系統用例圖模型需要哪些檢視、每個檢視包含什麼內容，以及檢視中成員是否需構成包。
小結
用例建模是實現系統需求分析的一個很好的方法，使得系統分析員和使用者之間能夠更好地溝通系統的需求。