10 個創建專業用例圖的技巧

什麼是用例建模？

用例建模是對「使用者（客戶）想要什麼？」這個問題的簡單回答。它讓你能夠以視覺化方式呈現使用者使用最終產品（可以是系統、軟體、程式等）所希望達成的目標。用例建模是一種有用的技術，為軟體開發人員提供堅實基礎，以開發符合客戶需求的軟體系統。

儘管用例圖中使用的符號看似簡單且不傳達太多細節，但用例的收集、組織與詳述方式，對軟體開發生命週期的方向有著重大影響，進而影響最終軟體產品的品質。

10 個實用的用例建模技巧

在本文中，我們將介紹十個技巧，以最大化繪製用例圖的效率。我們不會詳細解釋什麼是用例，而是會涵蓋 UML 建模、用例圖與需求收集的一些關鍵概念。

1. 從終端使用者的角度思考

顯而易見的是，為了建立一個能運作的軟體系統，你必須了解使用者的期望，而這個原則在用例建模中尤為重要。許多人錯誤地將用例建模視為一種模擬系統功能的過程，這可能是錯誤的。準確來說，用例建模是模擬使用者真正想要的事物。用例圖中的每個用例都應透過使用者與最終軟體或系統的互動，產生可觀察的目標。有時，使用者目標與系統功能相同，但這並非總是如此。例如，「登入」是系統功能，但絕對不是使用者目標——沒有人會啟動程式、登入後就離開！因此，你在用例圖中繪製的系統功能越多，用例模型就越難有效表達使用者在整個軟體開發過程中的真實期望。因此，當你開發用例模型時，應首先從終端使用者的角度思考，再表達所有內容。

2. 避免使用過長的用例名稱

如果你正在閱讀為 ATM 系統準備的用例圖，你希望在圖中看到以下哪個用例？「提款」和「提款並更新帳戶餘額」。第二個用例似乎更具描述性，對吧？但如果擁有 50 個以上名稱如此長的用例呢？你可能已經不想再閱讀這張圖，甚至眼睛會感到不適。

我們需要建模的原因之一，是希望以簡單易懂的方式理解複雜的軟體系統。這正是 UML 提供多種不同符號的原因，每種符號代表描述完整軟體系統的特定視角。這種「精神」同樣適用於命名用例。如果我們試圖用詳細描述來命名用例，那為什麼不直接使用文字檔呢？為了讓用例圖容易理解，重要的是保持用例名稱簡短，同時仍具描述性。請保持名稱簡短，將詳細描述留給用例的描述部分。

3. 角色是角色，而不是真實的人

有些人試圖將組織中的員工表示為用例圖中的角色，結果產生了一個包含彼得、瑪麗、黛西等人的圖。請記住，角色代表一種獨特的角色，這種角色由具有獨特特徵的人、子系統或任何其他實體組成，並共享相同的目標和期望。

4. 使用關係來建模共用的用例

用例代表使用者目標，可透過一系列步驟達成。當在多個用例中發現完全相同的步驟時，可選擇為這些共用步驟建立新的用例，並與觸發這些步驟的用例相連接。透過使用包含的用例，可清楚表明包含的用例確實與被包含用例所代表的相同步驟共享，且無任何疑問。

5. 建模例外行為

擴展關係可用來指定用例的行為何時以及如何被另一個用例觸發。擴展發生在被擴展用例中定義的擴展點上。擴展用例定義了在特定條件下，被擴展用例可能執行的步驟。

6. 使用事件流程來建模情境

用例代表使用者目標，可透過一系列步驟達成。有些人試圖直接在用例圖上建模步驟，透過用許多關聯連接角色與用例，假裝這些關聯就是步驟，這肯定是錯誤的。相反地，用例的步驟可以在用例的事件流程編輯器中清楚描述。事件流程編輯器.

事件流程編輯器以表格形式呈現，每一列代表用例的一個步驟。您可以在其中寫下步驟，無論是否包含條件流程。您也可以對文字套用格式，以強調關鍵概念。

7. 善用造型符號進行分類

造型符號是一種機制，允許您引入除標準符號外的領域特定符號。當套用造型符號時，會以尖括號標示於圖形名稱上方。正確使用造型符號可幫助讀者更容易理解用例之間的差異。

8. 使用序列圖建模詳細的系統流程

序列圖可透過表示物件之間隨時間傳遞與交換訊息的方式來建模系統行為。但該從何處開始呢？不必猜測要建模哪些互動，您可以從使用者的需求出發，這正是用例模型所要呈現的內容。

我們知道，每個用例都代表一個獨特的使用者目標。從用例繪製序列圖，意味著您將建模電腦系統為滿足使用者需求應執行的動作。理想上，不會有任何重複設計，因為所有序列圖都是從代表使用者需求的用例所建立。

9. 在適當情況下對用例應用相同的寬度

由於用例名稱長度不同，用例呈現不同寬度是正常的。為了讓圖表更美觀且易於閱讀，將它們調整為相同寬度會比較理想。

10. 以有意義的方式放置角色與用例

一個角色與用例隨機放置的用例圖對讀者來說絕對是一場噩夢。讀者必須仔細檢視圖表，才能從分散的角色與用例中找出所需資訊。將圖形以有條理的方式排列會比較理想。如有需要，也可使用封裝形狀來群組用例。