用例描述了用戶如何使用系統來實現特定目標。用例圖由系統，相關用例和參與者組成，並將它們相互關聯以形象化：所描述的內容是什麼？（系統），誰在使用該系統？（參與者）以及參與者想要達到的目標？（用例）因此，用例通過從用戶的角度捕獲需求來幫助確保開發正確的系統。
在線商店用例圖
用例來源
目前，用例建模通常與UML相關聯，儘管它是在UML存在之前引入的。其簡史如下：
- 1986年，Ivar Jacobson首先制定了用於指定用例的文本和視覺建模技術。
- 1992年，他與人合著的著作“ 面向對象軟件工程 - 用例驅動方法”幫助推廣了捕獲功能需求的技術，特別是在軟件開發方面。
用例圖的目的
用例圖通常在開發的早期階段開發，人們通常將用例建模應用於以下目的：
- 指定係統的上下文
- 捕獲系統的要求
- 驗證系統架構
- 推動實施並生成測試用例
- 由分析師和領域專家共同開發
什麼是UML中的用例圖？
用例是動作或事件步驟的列表，通常定義角色的角色與實現目標的系統之間的交互。用例是用於識別，澄清和組織系統需求的有用技術。用例由系統和用戶之間的一組可能的交互序列組成，這些交互序列定義了要實現的特徵以及可能遇到的任何錯誤的解決方案。
雖然用例本身可能會深入探討關於每種可能性的許多細節（例如，事件和場景的流程），但用例圖可以幫助提供更高級別的系統視圖，提供簡化的圖形表示。系統必須實際做什麼。
用例（或用例集）具有以下特徵：
- 組織功能要求
- 模擬系統/參與者（用戶）交互的目標
- 描述一個主要事件流（主要方案）和可能的其他異常流（備選方案），也稱為路徑或用戶方案
用例圖表示法
用例定義外部參與者與系統之間的交互以實現特定目標。用例圖包含四個主要組件
參與者
參與者通常是根據其角色定義的系統參與者。參與者可以是人或其他外部系統。
例子
用例描述了actor如何使用系統來實現特定目標。用例通常由用戶發起，以實現描述實現目標所涉及的活動和變體的目標。
關係
參與者和用例之間的關係。
系統邊界
系統邊界定義了與周圍世界相關的感興趣系統。
用例圖的好處
- 用例是一種強大的技術，用於啟發和記錄黑盒功能需求。
- 因為，用例易於理解，並提供了與客戶和用戶進行通信的絕佳方式，因為它們是用自然語言編寫的。
- 用例可以通過將問題劃分為主要用戶功能（即用例）以及從用戶角度指定應用程序來幫助管理大型項目的複雜性。
- 通常由序列圖表示的用例場景涉及多個對象和類的協作，用例有助於識別將對象和類粘合在一起的消息（操作和所需的信息或數據 - 參數）。
- 用例為更高級模型的驗證（即參與者和一組協作對象之間的交互）之間的鏈接提供了良好的基礎，並隨後用於功能需求的驗證（即白盒測試的藍圖）。
- 用例驅動方法為項目跟踪提供了可跟踪的鏈接，其中關鍵的開發活動（例如實現，測試和交付的用例）從用戶的角度來實現目標。
如何繪製用例圖？
可以通過以下步驟開髮用例模型。
- 識別系統的Actors（用戶角色）。
- 對於每個類別的用戶，標識與系統相關的用戶所扮演的所有角色。
- 確定為實現這些目標而要執行系統所需的用戶。
- 為每個目標創建用例。
- 構造用例。
- 確定用戶的優先級，審核，評估和驗證。
請注意：為了使用例方法更加“敏捷”，不要詳細說明所有用例，但要在產品待辦事項中對它們進行優先級排序，您應該根據開發階段及時地在不同級別的詳細信息中優化用例而且還有足夠的方式。
你也可以：
- 繪製用於將用例邏輯分類到相關子系統的包。
構建用例
UML定義了用例之間關聯的三種原型：
<< include >>用例
使用<< include >>關係的時間是在完成所有主要用例的第一次剪切描述之後。您現在可以查看用例並確定用戶系統交互的常見順序。
<< extend >>用例
擴展用例實際上是基本用例的替代過程。<< extend >>用例通過概念性地將附加動作序列插入基本用例序列來實現這一點。
摘要和廣義用例
一般用例是抽象的。它無法實例化，因為它包含不完整的信息。抽像用例的標題以斜體顯示。
例
此示例描述了幾個業務用例（目標）的模型，它表示餐館（業務系統）與其主要參與者之間的交互。
在第一次切割中確定了基本用例之後，或許我們可以在第二輪修改中使用<< extend >>和<< include >>用例進一步構造這些用例，如下圖所示：
業務用例
業務用例在無技術術語中描述，該術語將業務流程視為黑盒子並描述其業務參與者使用的業務流程，而普通用例通常在系統功能級別描述並指定功能或者係統為用戶提供的服務。換句話說，業務用例表示在當前情況下如何手動完成工作，並且它不一定由系統完成或打算在目標系統的範圍內自動完成。
如何識別參與者
通常，人們發現通過識別參與者來啟動需求啟發過程是最容易的。以下問題可以幫助您識別系統的參與者（Schneider和Winters - 1998）：
- 誰使用該系統？
- 誰安裝了系統？
- 誰啟動了系統？
- 誰維護系統？
- 誰關閉了系統？
- 還有哪些系統使用這個系統？
- 誰從這個系統獲取信息？
- 誰向系統提供信息？
- 有什麼事情在現在自動發生嗎？
如何識別用例？
識別用例，然後通過詢問每個參與者所期望的外部可見，可觀察的值來繼續基於場景的啟發過程。一旦確定了參與者，可以詢問以下問題以確定用例（Schneider和Winters - 1998）：
- 參與者想要從系統中獲得什麼功能？
- 系統是否存儲信息？哪些參與者將創建，閱讀，更新或刪除此信息？
- 系統是否需要通知參與者內部狀態的機會？
- 是否有系統必須了解的外部事件？什麼參與者告訴系統這些事件？
用例圖提示
現在，請查看以下提示，了解如何在軟件項目中有效地應用usecase。
- 始終從actor的角度構建和組織用例圖。
- 用例應該從簡單開始，盡可能以最高的視圖開始。只有這樣，他們才能進一步完善和細化。
- 用例圖基於功能，因此應該關注“什麼”而不是“如何”。
用例級別的詳細信息
用例粒度是指在用例規範中組織信息的方式，在某種程度上，是指編寫它們的詳細程度。實現正確的使用級別案例粒度可以簡化利益相關者和開發人員之間的溝通，並改善項目規劃。
Alastair Cockburn _撰寫有效用例_為我們提供了一種通過思考海洋來可視化不同級別目標水平的簡單方法：
注意：
- 雖然用例本身可能會深入探討每種可能性的詳細信息，但用例圖通常用於更高級別的系統視圖作為藍圖。
- 在較粗略的粒度級別編寫用例並在不需要時使用較少的細節是有益的。
我希望您現在可以回答“什麼是用例圖”，並可以在您的項目中應用用例。如果您想了解有關其他UML圖類型的更多信息，請查看UML指南：14 UML圖類型概述。
僅以UML表示法顯示用例圖是不夠的。每個用例都附有說明用例目的的文本，以及在執行用例時完成的功能。
用例規範通常以迭代方式在分析和設計階段創建。
- 首先，僅寫入執行用例的正常流程所需的步驟的簡要描述（即，用例提供了什麼功能）。
- 隨著分析的進展，這些步驟將得到充實，以增加更多細節。
- 最後，特殊流程被添加到用例中
- 每個項目都可以採用標準用例模板來創建用例規範。
用例與用例規範
用例描述由執行者生成的任務，該任務生成業務的業務價值結果。用例可以顯示為用例圖或/和結構化文本規範格式：
用例（任務 - 客戶想要執行的）可能是：
- 交互式 - 系統用例描述了參與者與系統的交互，以實現定義的業務目標
- 手動 - 由參與者執行的一系列動作
- 自動 - 由程序或腳本執行的一系列步驟
用例特徵
用例有：
- 只有一個目標
- 一個起點
- 一個終點
- 從開始到結束的多條路徑
- ie指定各種可能條件的行為
- 每個條件都可能需要採取特定措施
例如 - 客戶支付賬單：
有多種途徑可以實現目標：
- 電話付款
- 通過郵件
- 親自
- 通過檢查
- 現金等
一條不會導致目標的路徑：
- 信用卡被拒絕
敏捷用例方法
用例模型及其各個用例隨著時間的推移逐級發展。並非所有模型的用例都必須指定為相同的細節級別。
準時和足夠
用例可以在不同的數據和範圍級別編寫，每個用例都有用：
- 摘要：系統功能或業務流程的一般描述和概述。
- 用戶級別：用戶的任務相關描述以及他們與系統的交互方式; 特定業務流程的描述。用戶級用例通常被認為是作為用戶主要工作的任務級別。
- 子功能：用於完成核心用例子部分的低級活動的描述。
注意：某些用例可以在II級之前充分指定。當使用及時和恰當的方式實現足夠的細節時，您就會停止。
詳細的用例規範
詳細用例是說明一系列事件以及某種格式的其他相關用例信息的文本表示。人們通常採用標準用例模板來記錄用例的詳細信息
用例模板 - ATM撤銷案例
如前所述，用例有幾種表示法樣式（例如圖表樣式，統一建模語言，文本格式）。無論使用何種符號都應該易於理解。您可以使用模板，例如來自Alistair Cockburn的模板，但也可以選擇使用最適合您團隊的模板。
用例規範 - 視覺範例
用例規範 - 基本路徑
用例規範 - 替代路徑
用例規範 - 業務規則
用例規範 - 非功能性要求
創建簡單的用例圖
如果您想繪製休閒案例圖表，Visual Paradigm Online將是您的最佳選擇。因為它完全免費，沒有限制，零設置和配置。
您還可以使用Visual Paradigm Community Edition，它也可以免費為各種平台創建用例。
執行正式用例建模和分析
如果您想要執行和開髮用例建模，建議您使用Visual Paradigm付費版本，這使您能夠開發如上所述的正確和完整的用例規範。
現在用Visual Paradigm Online 自己動手吧
立即嘗試，享受所有這些可立即編輯的示例和模板，如下所示：
