在專案開發的過程中，瞭解使用者的需求是一件很重要的事情。但往往很有可能連使用者自己都不是很清楚自己需要的是什麼，只知道「想要」什麼。所以很容易在蒐集需求的時候就掉入「細節」的陷阱而不自知，因而導致開發的進度越來越慢。
今天要跟大家介紹的是在UML中的使用者案例圖(Use Case Diagram)。

使用案例圖的符號其實很簡單，學起來也很輕鬆。可是說真的要用，可以說是很容易也可以說是很難。就像中文字一樣，筆畫越是少的字月難寫的漂亮，反倒是筆畫多寫起來相對容易許多。

首先我們先來看一下 Use Case Diagram 的符號：
在 Use Case Diagram 中只有兩種角色：1. Actor(參與者) 2. Use Case (使用案例) 3. Boundary (邊界)

1.參與者：絕大多數的情況下都是用一個小人來表示：

當然 actor 也可以使用自定義的符號來表示。這個 actor 在 Use Case 中有兩種角色：1. 使用者(User) 2. 支援者 (Supporter)

一開始UML在制訂的時候，當我們把 actor 擺在 Use Case Diagram 左邊時，這個 actor 就代表這個系統的使用者、相對的右邊就是支援者；不過後來 UML 在 Use Case Diagram 的關連上可以加上箭頭，所以現在也沒有強制規定左邊一定是使用者、而右邊一定是支援者。

此外，在Use Case中的參與者除了人之外也可以是系統或者系統服務。而這個參與者所代表的是一個特殊的角色，並不是一個個體。

舉例來說：有三位學生向學生資訊系統分別申請加選三門課程，而加選課程需要這三位老師的核准才能加選。雖然這個事件總共有六個人，但是對Actor來說只有兩個角色(Role)：老師跟學生。

2. 使用案例(Use Case):
   使用案例在UML中有三中畫法：

Use Case (使用案例)在 Use Case Diagram 中代表的意義為：一個目的。所以在替 Use Case 命名時都是要以動詞+名詞為規範。

3. 系統邊界(Boundary)
   這是在 Use Case Diagram 中最重要的關鍵點之一。他的圖形非常簡單，就是一個方形將 Use Case 包圍起來，並且在最上方有一個名稱。

為什麼會說這是最重要的呢？因為在需求的蒐集時若不先定義系統邊界，那很有可能所蒐集到的需求會越來越廣，廣到包山包海。

接下來我們來看一個範例：

首先我們來看「登入系統」這個使用案例。為什麼我會用紅色框起來呢？因為這個使用案例很特別，以UML的語法來說他並沒有錯。但是每一個使用案例都是一個「目的」，也就是說除非在蒐集需求的時候想要特別強調「登入系統」這個功能（可能是特別難、或需要花特別多時間開發或者其他任何理由），否一般不是很建議將這個需求列在上面。因為學生在使用這個系統時，他的「目的」應該不會只是想「登入系統吧」。

第二，再申請成績單這個部分：當學生向系統提出「申請成績單」這個需求時，系統當然無法幫他執行「寄送成績單」這個服務阿，所以我才會在右邊增加一個「支援者」的角色。

就這樣嗎？其實還有，就是包含關係。

<<include>>代表：當顧客角費時，系統一定會做「檢查票卡」這個動作。
<<extend>>代表：顧客角費時，系統可以做「列印發票」也可不「列印發票」。也就是選擇性的。（這只是範例，真正的停車費繳費系統一定會列印發票啦）。

後記：
有老師說過：『Use Case Diagram是易學難精』。在繪製 Use Case Diagram 時，就像寫文章一樣，可以畫的很複雜，也可以畫得很簡單。不過還是建議在抓 Use Case時能夠月精要越好，儘量不要將細節當成 Use Case 來使用，因為細節很可能會一直變，只有核心的目的是不會變的。就拿申請成績單這件事來說：成績單個表格格式可以很多種，也可以是中文、英文成績單，可是不管怎樣核心的目標「申請成績單」這件事情是不會變的。

文章導覽
全系列
上一篇
下一篇