繁體中文用例建模是捕獲需求的有用工具。它提供了軟件系統需求的圖形表示。
隨著Ivar Jacobson (1991) 的《面向對象的軟件工程，用例驅動方法》一書的出版，用例建模有效地成為了一種實用的分析技術”。今天，Jacobson 繼續推廣這種系統分析方法，並將其升級到用例 2.0，正式成為14 種 UML 圖類型之一。
由於用例模型在概念和外觀上都比較簡單，因此與非技術人員（如客戶）討論其正確性相對容易。
用例不是過程、過程或功能。
用例圖的元素
用例圖的元素是參與者（外部實體）和用例本身。從廣義上講，用例是系統中的一個功能單元（需求）或服務。
演員
參與者是設計系統外部的任何實體，無論是個人還是其他非人類實體。系統的用戶是參與者的典型示例。其他類型的參與者包括與當前系統（例如，數據庫系統）集成的軟件系統、傳感器等外部硬件。
UML 規範中有兩種表示法：
對演員使用火柴人更具表現力，但如果演員實際上不是人，而是機器或外部設備，則會導致混淆。矩形符號是類的標準UML表示法。
演員是角色而不是真人
參與者代表與當前系統交互的實體的角色，而不是實例。 演員符號表示實體是一個類而不是讀取實例（即真實用戶 John 或 Mary）。演員之所以是一類的，是不是演員本人，而是
他/她所扮演的角色。
例如，參與者可以代表銀行的客戶，而不是為每個客戶指定單獨的參與者。類似地，可能有另一個參與者代表銀行經理。有趣的是，在現實世界中，一家銀行的經理也可能是同一家銀行的客戶。換句話說，同一個人同時扮演客戶和經理的角色。
用例的主要參與者是需要係統提供其服務的利益相關者。它有一個與系統相關的目標——系統運行可以滿足的目標。主要參與者通常（但不總是）是觸髮用例的參與者。
次要角色由系統使用，但它們不與系統交互。換句話說，次要參與者不會啟動任何用例。
用例通常由主要參與者發起。系統通過一組用例使用數據庫等輔助角色。用例和參與者之間的關聯代表了一種雙向通信。
因此，對於由主要參與者發起的每個用例，必須響應連接的用例。類似地，對於次要參與者和用例之間的每個關聯，通信都從用例開始，次要參與者應該響應啟動。
用例
用例代表系統預期實現的功能（通常是需求）。用例的細節，除了其唯一的名稱，在圖中沒有直觀的表達；這些細節在用例描述中給出。
用例通常由關鍵參與者發起。系統通過一組用例使用數據庫和其他輔助參與者。
用例和參與者之間的關聯代表了雙向通信。因此，對於主要參與者發起的每個用例，都必須響應後者。類似地，對於次要參與者和用例之間的每個關聯，通信都從用例開始，次要參與者應該響應啟動。
系統邊界
系統邊界定義了與周圍世界相關的感興趣系統。
用例圖示例：航空公司預訂系統
用例定義外部參與者和系統之間的交互，以實現特定目標。用例圖包含四個主要組件
在票務預訂系統的用例圖中，系統由包含許多不同用例的框表示。主要參與者是客戶，次要參與者是管理員。客戶啟動用例，例如預訂、瀏覽和取消航班，而管理員啟動用例，例如更新航班記錄，但在取消航班用例中被視為次要參與者，因為她只是幫助完成客戶發起的用例。
構建用例
根據應用領域和設計者的選擇，一個用例可以分解成多個用例，通過<<include>>或<<extend>>關係連接起來。
關聯鏈接表示參與者和用例之間的雙向通信，因此是二元關係。由於它是雙向通信，因此對於由主要參與者發起的每個用例，該參與者必須從用例中獲得響應。
類似地，對於用例和次要參與者（由用例發起）之間的每次通信，次要參與者必須將響應發送回用例。
概括
泛化表示之間的關係
- 角色或
- 用例。
如果兩個參與者通過這種關係連接，那麼箭頭末端（連接到三角形底部）的參與者（或用例）是另一端參與者（或用例）的特殊版本。
通常，底端（連接到三角形底部）的參與者（或用例）被稱為另一端參與者（或用例）的專用版本。
泛化意味著專用版本具有通用版本的所有功能，甚至可能更多。
包含 是兩個用例之間的一種特殊關係。如果一個用例 A 包含另一個用例 B，那麼 A 的實現需要 B 的實現來完成它的任務。但是，B 是獨立於自身的。也就是說，B 不需要知道關於 A 的任何信息。B 也可以包含在任何其他用例中。
擴展是兩個用例之間的另一種特殊關係。如果一個用例 B 擴展了另一個用例 A，那麼 A 的實現可以有條件地包括 B 的實現以完成其任務。也就是說，在某些情況下，A 可以在沒有 B 的情況下完成其任務。但是，取決於所描述的條件。
用例圖符號
執行用例分析的 9 個簡單步驟
- 確定誰將直接使用該系統。這些人就是演員。
- 選擇這些演員之一。
- 定義該參與者想要對系統做什麼。參與者想要對系統做的每一件事都成為一個用例。
- 對所有其他用例重複步驟 2-3 為您
確定的用例確定次要角色和非人工角色支持。 - 繪製用例的初始版本，此時不要過度複雜化用例關係
- 與用戶討論和審查以驗證每個用例的目標（提議功能的好處） 修改後，您可以繼續在步驟 8 – 10 中詳細說明用例
- 對於每個用例，確定參與者在使用系統時將遵循的最常見流程。通常會發生什麼。
- 在用例描述中描述這個基本過程。
- 一旦您對基本流程感到滿意，現在考慮替代方案並將其添加為擴展用例。
用例模型和規範
僅用 UML 表示法顯示用例圖是不夠的。每個用例都附有解釋用例目的和執行用例時完成的功能的文本。
用例描述了由參與者執行的任務，該任務為企業產生業務價值結果。用例可以可視化為用例圖或/和結構化文本規範格式。
用例場景
一個用例由許多場景組成，每個場景代表用例的一個特定實例，對應於參與者的特定輸入或環境中的特定條件。每個場景都描述了系統運行的另一種方式，或者它可能描述失敗或異常。
一個用例有：
- 只有一個目標
- 單一起點
- 單一的終點
- 從頭到尾的多種路徑
- 即為各種可能的條件指定行為
- 每個條件可能需要特定的操作
例如 – 客戶支付賬單：
實現目標有多種途徑 ：
- 電話支付
- 通過郵寄
- 親自
- 通過支票
- 用現金等
不通向目標的路徑 ：
- 信用卡被拒絕
使用包對用例進行分組
您還可以： 將用於用例邏輯分類的包繪製到相關子系統中。
詳細的用例規範
詳細用例是一種文本表示，它以特定格式描述事件流和其他相關用例信息。標準用例模板通常用於記錄用例的詳細信息
什麼是用例描述
用例描述是對分析師為完成完整系統事務而執行的一系列步驟的書面描述。它由參與者發起，為參與者提供價值，並且是參與者在系統中工作的目標。
參與者——任何在系統外部使用系統或與系統交互以實現目標的人或系統。每個參與者都被賦予一個角色來代表他們與解決方案的交互。人物演員應該以角色的形式命名，而不應該被分配實際名稱。參與者通常分為主要、次要或利益相關者
主要參與者——啟動用例的參與者。
次要參與者——對主要參與者執行的動作做出反應或響應的參與者。
利益相關者——不直接與用例交互，但對用例的結果感興趣的場外參與者。
事件流（路徑） ——參與者和解決方案執行用例必須採取的步驟序列。通常，用例由主要成功路徑（也稱為基本或主要）、備用路徑和異常路徑組成。
正常路徑——參與者的輸入和系統的響應——代表了實現參與者目標的最常見的成功路徑。
備用路徑——來自參與者和系統響應的輸入，代表完成參與者目標的其他不太常見的路徑
異常路徑——來自參與者和系統響應的輸入，表示參與者的目標無法實現時的不成功路徑。
| 用例描述 | |
|---|---|
| 用例名稱： | 提取現金 |
| 演員： | 客戶（主要）、銀行系統（次要） |
| 摘要說明： | 允許任何銀行客戶從他們的銀行賬戶中提取現金。 |
| 優先： | 一定有 |
| 狀態： | 中等細節水平 |
| 前提： | 銀行客戶有一張卡要插入 ATM ATM 正常在線 |
| 後置條件： |
|
| 基本路徑： |
|
| 替代路徑： |
|
| 商業規則： |
|
| 非功能性要求： |
|
繁體中文
English
简体中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский