隨著VSTS2010的問世，UML已經可以直接在Visual Studio裡面設計，
UML就像ISO、CMMI一樣，是種趨勢，是種必備的工具和標準。
不會UML也不會死，會用也沒有加錢，
但是UML卻是一個開放的標準，當人與人之間溝通沒有一個橋樑時，開放的標準就會顯得格外重要。
UML diagram – Use Case Diagram

這幾乎是每一個案例第一個會用到的圖，為什麼？

1. 重要，從這張圖可以瞭解整個系統的Scope(Boundary)、需求(Use Case)、參與成員(Actor)。
2. 簡單，因為圖裡面使用的Element就只有上面這些，再加上箭頭來表示關聯。
   * 也因為簡單，所以這張圖連User也會看的懂，是少數不用教育訓練，就可以透過UML diagram讓雙方進行溝通。

Use Case Diagram主要就是用來捕捉系統功能需求的圖形。

然而，要畫圖之前，我們通常會有一堆文字，再用圖來解釋和溝通。

所以我們會先有使用案例敘述，這些條列性的文字，通常是經由SA與User訪談後，所表列出來的文字。
我們要從訪談過程，去引導出User真正需要什麼，從訪談記錄這堆文字裡面，瞭解User想要系統能作什麼，
整理歸納出來的每一個需求與目的，都是我們的Use Case。

有了Use Case，才能訂出來我們這個系統到底要做些什麼，到底有哪一些相關的成員，這些成員會使用什麼樣的功能。

Element介紹
1.Actor：成員，不一定是人，也有可能是外部系統，只要與這個系統有關的人或物都可以是Actor。

2.Use Case：使用案例，滿足實際使用者需求目的的功能，通常對應到系統裡，就是Business logic layer裡面的Service。

3.System Boundary：一個矩形框框，在這個框框裡的，就是我們的系統範圍內，在框框以外，就是外部的角色，
外部功能我們也不會在這張圖出現，因為沒有必要，太多東西反而會增加雜訊，這在每一張diagram都是相當重要的原則，
不要想用一張圖就表達出太多的東西。

4.Association：關聯，通常是Actor與Use Case之間的的關係，也可以是include或extend的關係。

這邊舉一個提款機系統來當例子：