用例建模 - IT 觀察者隨筆

Table of Contents hide

UML 用例圖是正在開發的新軟件程序的系統/軟件需求的主要形式。用例指定了系統的預期行為（什麼），而不是實現它的確切方法（如何）。一套完整的用例指定了使用系統的所有不同方式，因此定義了限制系統範圍的系統所需的所有行為。

用例建模的一個關鍵概念是它幫助我們從最終用戶的角度設計系統。它是一種通過指定所有外部可見的系統行為來以用戶的方式傳達系統行為的有效技術。

用例圖一覽

用統一建模語言定義了標準形式的用例圖，如下面的用例圖示例所示：

什麼是用例？

用例是討論中的系統與其與特定目標相關的外部參與者之間可能的交互序列的集合。
從用戶的角度來看，每個用例都是系統中事件的完整過程。
用例一旦指定，就可以用文本和視覺表示（即用例圖）表示。
用例是組件和對象社區喜歡用來指定需求並確實推動整個軟件開發過程的方法。
用例通常堅持相當大的任務；不需要為用戶可以執行的每個操作編寫它們。

用例方法的好處

除了定義用戶需求之外，用例還提供了許多好處。用例可用於：

用例幫助捕獲系統的功能需求。
用例是可追溯的。
用例可以作為估計、調度和驗證工作的基礎。
用例可以在每次迭代中從捕獲需求的方法演變為程序員的開髮指南，再到測試用例，最後演變為用戶文檔。
用例替代路徑捕獲可以提高系統穩健性的其他行為。
事實證明，用例很容易被業務用戶理解，因此被證明是軟件開發人員和最終用戶之間的良好橋樑。
識別業務域類及其關聯

演員

有人與用例（系統功能）交互。
以名詞命名。
演員在商業中扮演角色
類似於用戶的概念，但一個用戶可以扮演不同的角色
例如：
一個教授。可以是講師，也可以是研究員
在兩個系統中扮演 2 個角色
參與者觸髮用例。
Actor 對系統負責（輸入），Actor 對系統有期望（輸出）。

用例

系統功能（過程——自動或手動）
以動詞+名詞（或名詞短語）命名。
即做某事
每個 Actor 必須鏈接到一個用例，而某些用例可能沒有鏈接到 Actor。

通訊鏈接

參與者在用例中的參與通過將參與者連接到用例中來顯示。
參與者可以通過關聯連接到用例，這表明參與者和用例使用消息相互通信。

系統邊界

系統邊界可能是需求文檔中定義的整個系統。
對於大型複雜系統，每個模塊都可能是系統邊界。
例如，對於一個組織的 ERP 系統，每個模塊，如個人、工資、會計等。
可以為特定於這些業務功能中的每一個的用例形成系統邊界。
整個系統可以跨越所有這些描述整個系統邊界的模塊

6 步用例分析

在開髮用例時，您應該從功能分區開始——目標系統的主要功能類別的列表。這將有助於確定需要關注哪些領域。

第 1 步 — 確定參與者：確定誰將直接使用系統。這些是演員。

用例開發的主要組成部分之一是參與者。
參與者是系統用戶扮演的特定角色，代表在使用系統時表現出類似行為的一類用戶。
參與者可能是人或計算機系統。
主要參與者是具有需要係統幫助的目標的參與者。
次要參與者是系統需要幫助以實現其目標的參與者。
其中一個參與者被指定為正在討論的系統。
一個人可以扮演多個角色，從而代表多個參與者，例如計算機系統操作員或最終用戶。

第 2 步：選擇其中一個演員。

為了識別目標系統的用例，我們識別系統參與者。
一個好的起點是檢查系統設計並確定它應該幫助誰。

第 3 步——識別用例：定義參與者想要對系統做什麼。參與者想要對系統做的每一件事都成為一個用例。

演員想要對系統做的事情成為目標。
目標是用戶行為的最終結果。有兩種類型的目標。第一種是剛性目標。
這個目標必須完全滿足並描述了目標系統的最低要求。
為了識別用例，我們可以從參與者的角度閱讀需求規範，並與將充當參與者的用戶進行討論。
通過定義每個參與者在與系統交互時能夠做的所有事情，系統的完整功能就被定義了。

第 4 步 – 確定正常用例場景：對於每個用例，決定該參與者使用系統時最常用的路線。通常會發生什麼。

一個用例包含一門基礎課程和幾門備選課程。
基礎課程是最簡單的課程，可以毫無困難地交付請求。
可能有替代課程來描述基礎課程的變體以及可能發生的錯誤。
這些被記錄為用例的擴展。

第 5 步 — 開髮用例描述：在用例描述中描述基本課程。

使用場景是從用戶的角度以通俗易懂的語言編寫的。
寫出實現確定目標所需的步驟，稱為事件流。

第 6 步 – 開髮用例替代路徑：一旦您對基礎課程感到滿意，現在考慮替代方案並將其添加為擴展用例。

用例的替代方案

用例還描述了當事情不正確或不正確時系統應該如何響應，但不是我們在主要成功場景中描述的方式。我們稱這些情況 為擴展。

有兩種變體： exceptions 和 alternates。
例外情況是失敗條件（出現問題）。
替代方案只是讓事情順利進行的另一種方式。

用例級別的詳細信息

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

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

注意：

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

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