jude-Use Case Diagram概述

原文：http://www.dotblogs.com.tw/jimmyyu/archive/2010/01/18/use-case-diagram.aspx

本篇主要針對Use Case Diagram 的目的、撰寫注意事項、Use Case不做哪些事情做些說明。

目的
Use Case Diagram 主要是為了增進我們與客戶間的需求雜訊，避免客戶的期望與系統分析師的認知有落差，之前有寫過一篇文章，其實Use Case Diagram 是解決此問題一個很好的方法：[系統分析]談談需求分析(RA)

Use Case Diagram主要是描述一個系統或類別提供給外界之交互作用者的功能。簡單來說就是說明一個系統的功能及其使用者。

Use Case透過很簡單的表達方式，讓我們可以較輕易的向客戶確認需求，以下說明一下Use Case如何撰寫。

撰寫注意事項
Use Case Diagram非常單純，主要分為以下兩個部分：

• Actor：代表使用者與系統使用案例互動的代表，一般而言角色可為：人(human)、硬體設備(hardware device)、其他系統，而非只針對人而已。
• Use Case：使用案例描述系統要完成的成果，而不是如何進行，通常Use Case是一個動作，例如：儲存資料、加入會員等等…

 
如果以jude這套UML工具來說，Actor與Use Case的圖示分別如下，非常簡單且可愛。

 

在VS2010中則分別是：

 

簡單的Use Case範例如下，代表了兩個Use Case，其中一個是Customer觸發了Browse Web Site的Use Case，另一個則是Customer觸發了Buy Merchandise的動作，從這樣的範例中，我們就可以跟客戶說，一個Customer對我們網路購物車，最少會有這兩個可能的Use Case，並詢問客戶是否還有其他動作需要再加的。

上圖中Actor與Use Case間的連接線，我們稱為連結(Association)，它表現出參與者(Actor)與系統使用案例之間的溝通 (communicate )，可以在雙方之間傳送及接收訊息(Message)，其他相關的關連還有：

• Extends：單一Use Case的功能被選擇性地插入到叧一個 Use Case，如下例，客戶瀏覽網站不見得會購買商品。

• Includes：單一Use Case的功能完全包含到叧一個 Use Case，如下例，要寄出訂購的商品前，一定要先填寫訂單才行。

 

不過以上兩個我們儘量少用，避免我們的Use Case Diagram過度分支而複雜，原則上我們撰寫的Use Case一定要讓客戶跟開發人員都能看懂，否則這個Use Case就不是一個好的Use Case了。

Use Case不做的事情
Use Case並不是將所有的需求都描述進去，以下幾項是不會在Use Case中被撰寫的：

• Implementation details：不要描述實作細節，只講概要功能就好，例如不要說明資料將被存到Oracle資料庫，而說資料將被儲存就好。
• GUI Information：不要講UI上的內容，例如按下『存檔』按鈕，避免到時候畫面作多國語言時，我們還要將Use Case改成多語內容。
• Internal processing unrelated to a stakeholder request：不要講與使用者無關的系統內部作業，這一點跟第一項很像，就是不用講過多的邏輯內容在裡頭。
• Non-functional requirements：不要講非功能性需求，例如系統每個操作要在2秒內回應，同時上線人數要達3000人等。

 
Use Case Diagram本身並不複雜，最困難的還是在識別出系統的關鍵人員(Actor)跟關鍵應用(Use Case)，只要找出這兩者，圖很快就可以畫出來，並跟客戶做確認了，若有興趣討論這部分我可以再分享一下。