傻瓜用例教程

什麼是用例？

用例是系統分析中用於識別、闡明和組織系統需求的方法。

用例圖

用例 圖 模擬不同類型的用戶與系統交互以解決問題。因此，它描述了用戶的目標、用戶與系統之間的交互以及系統為滿足這些目標所需的行為。

用例 定義外部參與者和系統之間的交互，以實現特定目標。用例圖包含四個主要組件

（編輯上面的用例圖示例）

用例圖由許多模型元素組成。最重要的模型元素是：

演員

參與者通常是參與根據其角色定義的系統的個人。參與者可以是人或其他外部系統。

用例

用例描述了參與者如何使用系統來實現特定目標。用例通常由用戶發起，以實現描述實現目標所涉及的活動和變體的目標。

關係

參與者和用例之間的關係。

系統邊界

系統邊界定義了與周圍世界相關的感興趣系統。

用例特徵

一個用例（或一組用例）具有以下特徵：

• 組織功能需求
• 對系統/參與者（用戶）交互的目標進行建模
• 記錄從觸發事件到目標的路徑（稱為 場景）
• 描述一個主要的事件流（也稱為基本行動方案），以及可能的其他事件流，稱為 異常 事件流（也稱為替代行動方案）
• 是多層次的，因此一個用例可以使用另一個用例的功能。

用例和用例場景？

用例由系統和用戶在特定環境中並與特定目標相關的一組可能的交互序列組成。

用例裡面有什麼？

它由一組元素（例如，類和接口）組成，它們可以一起使用，其效果大於單獨元素組合的總和。用例應該包含對用戶有意義的所有系統活動。

用例類型

基本用例 以相對沒有技術和實現細節的理想形式表達；設計決策是延遲和抽象的，尤其是與用戶界面相關的決策。

具體或真實用例 具體描述了過程的真實當前設計，致力於特定的輸入和輸出技術等。當涉及用戶界面時，他們通常會顯示屏幕截圖並討論與小部件的交互。

抽像用例 不完整，沒有啟動它的參與者，但被另一個用例使用。

構建用例

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

<<include>> 用例

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

<<擴展>>用例

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

抽象和概括的用例

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

例子

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

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

（編輯上面的用例圖示例）

使用包構建用例

用例圖可能包含用於構建用例以簡化系統的分析、開發和維護的包。

（編輯上面的用例圖示例）

用例模型與用例圖

大部分用例模型實際上是文本的，文本捕獲在  與每個用例模型元素相關聯的用例規範中。這些規範描述了用例的事件流。

用例模型作為整個系統開發的統一線程。它被用作系統功能需求的主要規範、分析和設計的基礎、迭代計劃的輸入、定義測試用例的基礎和用戶文檔的基礎。

示例：用例描述

• 要編寫用例的內容，首先要選擇其中一個場景作為主要場景。
• 您可以通過將主要成功場景編寫為一系列編號的步驟來開始用例的主體。
• 然後，您可以採用其他方案並將它們編寫為擴展。擴展可以是成功的，如下面的 3a 所示，也可以是失敗的，如下面的 6b 所示。
• 每個用例都有一個主要參與者，它調用系統來提供服務。
• 用例中的每個步驟都是用戶和系統之間交互的一個元素。
• 一個用例中的共享活動卡車可以通過 <include> 用例被另一個用例重用。
• 在 UML 術語中，我們說第一個用例包括第二個用例。

購買產品 （取自 UML Distilled p101）

主要成功場景：

1. 客戶瀏覽目錄並選擇要通過的項目。
2. 顧客去結賬。
3. 客戶填寫發貨信息
4. 系統提供完整的定價信息
5. 客戶填寫信用卡信息
6. 系統授權購買
7. 系統確認銷售
8. 系統向客戶發送確認郵件

擴展

3a：客戶是常客

.1 系統顯示當前發貨信息

.2 客戶可以接受或推翻

6a：系統無法授權信用購買

.1 客戶可以重新輸入信用卡信息或取消

Visual Paradigm 說明的用例描述

事件流和擴展

• 記錄從觸發事件到目標的路徑（稱為 場景）

用例和 UML 建模

可以在軟件開發的多個階段使用用例，例如規劃系統需求、驗證設計、測試軟件以及為在線幫助和用戶手冊創建大綱。那麼用例圖與SDLC中的其他UML圖有什麼關係呢？

模型的選擇很重要

選擇創建什麼模型對如何解決問題以及如何形成解決方案有著深遠的影響。我們需要很好地選擇您的模型。

• 正確的模型將突出最關鍵的發展問題。
• 錯誤的模型會誤導你，導致你專注於不相關的問題。

例如：我們可以在軟件開發的不同階段使用不同類型的圖表。

參考

• 14 種 UML 圖類型概述
• 什麼是類圖？
• 什麼是組件圖？
• 什麼是部署圖？
• 什麼是對像圖？
• 什麼是封裝圖？
• 什麼是複合結構圖？
• 什麼是輪廓圖？
• 什麼是用例圖？
• 什麼是活動圖？
• 什麼是狀態機圖？
• 什麼是序列圖？
• 什麼是通信圖？
• 什麼是交互概覽圖？
• 什麼是時序圖
• 描述一個主要的事件流（也稱為基本行動方案），以及可能的其他事件流，稱為 異常 事件流（也稱為替代行動方案）
• 是多層次的，因此一個用例可以使用另一個用例的功能。