關於用例建模你需要知道的一切

用例圖的好處

1. 用例是一種強大的技術，用於獲取和記錄黑盒功能需求。
2. 因為，用例很容易理解，並提供了一種與客戶和用戶交流的絕佳方式，因為它們是用自然語言編寫的。
3. 用例可以幫助管理大型項目的複雜性，方法是將問題劃分為主要的用戶特徵（即用例）並從用戶的角度指定應用程序。
4. 用例場景，通常由序列圖表示，涉及多個對象和類的協作，用例幫助識別將對象和類粘合在一起的消息（操作和所需的信息或數據——參數）。
5. 用例為高級模型的驗證（即參與者和一組協作對象之間的交互）和隨後的功能需求驗證（即白盒測試的藍圖）之間的鏈接提供了良好的基礎。
6. 用例驅動方法為項目跟踪提供了可追溯的鏈接，其中關鍵的開發活動，如用例實施、測試和交付，從用戶的角度實現了目標和目的。

如何繪製用例圖？

可以按照以下步驟開髮用例模型。

1. 識別系統的參與者（用戶的角色）。
2. 對於每一類用戶，確定與系統相關的用戶所扮演的所有角色。
3. 確定用戶需要執行哪些系統才能實現這些目標。
4. 為每個目標創建用例。
5. 構建用例。
6. 對用戶進行優先級排序、審查、估計和驗證。

注意：為了使用例方法更“敏捷”，不要詳細說明所有用例，而是在產品 backlog 中優先考慮它們，您應該根據開發階段及時細化不同細節級別的用例和恰到好處的方式。

你也可以：

1. 將用於用例邏輯分類的包繪製到相關子系統中。

構建用例

UML 定義了用例之間關聯的三種原型：

<<include>> 用例

使用 <<include>> 關係的時間是在您完成所有主要用例的第一個剪輯描述之後。您現在可以查看用例並確定用戶-系統交互的常見序列。

<<擴展>>用例

實際上，擴展用例是基本用例的替代過程。<<extend>> 用例通過在概念上將附加動作序列插入基本用例序列來實現這一點。

抽象和概括的用例

一般用例是抽象的。它不能被實例化，因為它包含不完整的信息。抽像用例的標題以斜體顯示。

例子

此示例描述了幾個業務用例（目標）的模型，它表示餐廳（業務系統）與其主要參與者之間的交互。

在第一次切割中確定了基本用例之後，也許我們可以在第二輪潤色中使用 <<extend>> 和 <<include>> 用例進一步構建這些用例，如下圖所示：

業務用例

業務用例是用 無技術術語描述的 ，它將業務流程視為一個黑盒子並描述其業務參與者使用的業務流程，而普通用例通常在 系統功能級別進行描述 並指定功能或者係統為用戶提供的服務。換句話說，業務用例表示在當前情況下如何手動完成工作，不一定由系統完成或打算在目標系統範圍內自動化。

如何識別演員

通常，人們發現通過識別參與者來啟動需求獲取過程是最容易的。以下問題可以幫助您識別系統的參與者（Schneider 和 Winters — 1998）：

• 誰使用系統？
• 誰安裝系統？
• 誰啟動系統？
• 誰維護系統？
• 誰關閉了系統？
• 還有哪些其他系統使用該系統？
• 誰從這個系統中獲取信息？
• 誰向系統提供信息？
• 目前有什麼事情會自動發生嗎？

如何識別用例？

識別用例，然後通過詢問每個參與者想要什麼外部可見、可觀察的價值來進行基於場景的啟發過程。一旦確定了參與者，就可以提出以下問題來確定用例（Schneider 和 Winters — 1998）：

• 參與者希望系統提供哪些功能？
• 系統是否存儲信息？哪些參與者會創建、讀取、更新或刪除這些信息？
• 系統是否需要通知參與者有關內部狀態的機會？
• 系統是否必須知道任何外部事件？什麼參與者通知系統這些事件？

用例圖提示

現在，查看以下提示，了解如何在您的軟件項目中有效地應用用例。

• 始終從參與者的角度構建和組織用例圖。
• 用例應該從簡單和盡可能高的角度開始。只有這樣才能進一步細化和細化。
• 用例圖基於功能，因此應該關注“什麼”而不是“如何”。

用例級別的詳細信息

用例粒度是指在用例規範中組織信息的方式，在某種程度上，是指編寫它們的詳細程度。實現正確級別的用例粒度可以簡化利益相關者和開發人員之間的溝通，並改進項目規劃。

Alastair Cockburn 在 編寫有效用例 中為我們提供了一種簡單的方法，可以通過從海洋的角度來思考不同級別的目標級別：

注意：

• 雖然用例本身可能會深入了解每種可能性的大量細節，但用例圖通常用於作為藍圖的系統的更高級別視圖。
• 當不需要時，以較粗的粒度和較少的細節編寫用例是有益的。

我希望您現在可以回答“什麼是用例圖”，並可以在您的項目中應用用例。如果您想了解更多關於其他 UML 圖類型的信息，請查看 UML 指南：  Overview of the 14 UML Diagram Types。

僅以UML表示法顯示用例圖  是不夠的。每個用例都附有解釋用例目的的文本以及執行用例時完成的功能。

用例規範通常在分析和設計階段以迭代方式創建。

• 首先，只寫了執行用例的正常流程所需的步驟的簡要描述（即，用例提供了什麼功能）。
• 隨著分析的進行，這些步驟被充實以添加更多細節。
• 最後，將異常流添加到用例中
• 每個項目都可以採用標準用例模板來創建用例規範。

用例與用例規範

用例描述了由參與者執行的任務，該任務為企業產生了商業價值的結果。用例可以可視化為用例圖或/和結構化文本規範格式：

用例（任務——客戶想要執行）可能是：

• 交互式——系統用例描述了參與者與系統的交互，以實現已定義的業務目標
• 手動 – 演員執行的一系列動作
• 自動化 — 由程序或腳本執行的一系列步驟

用例的特徵

一個用例有：

• 只有一個目標
• 單一起點
• 單一的終點
• 從頭到尾的多種路徑
• 即為各種可能的條件指定行為
• 每個條件可能需要特定的操作

例如——客戶支付賬單：

實現目標有多種途徑：

• 電話支付
• 通過郵寄
• 親自
• 通過支票
• 用現金等

不通向目標的路徑：

• 信用卡被拒絕

敏捷用例方法

用例模型及其各個用例會隨著時間的推移逐級演進。並非模型的所有用例都必須指定為相同的詳細程度。

適時且恰到好處

用例可以在不同級別的數據和範圍內編寫，每個都有一個目的：

• 摘要：系統功能或業務流程的一般描述和全面概述。
• 用戶級別：與任務相關的用戶描述以及他們如何與系統交互；特定業務流程的描述。用戶級用例通常被認為是用戶主要工作的任務級別。
• 子功能：用於完成核心用例的子部分的較低級別活動的描述。

注意：某些用例可能被充分指定到 II 級。當使用及時和恰到好處的方式獲得足夠的細節時，您就會停下來。

詳細的用例規範

詳細用例是一種文本表示，它以某種格式說明一系列事件以及其他相關用例信息。人們通常採用標準用例模板來記錄用例的詳細信息