用例圖主要用來描述角色以及角色與用例之間的連接關系。說明的是誰要使用系統，以及他們使用該系統可以做些什么。一個用例圖包含了多個模型元素，如系統、參與者和用例，並且顯示這些元素之間的各種關系，如泛化、關聯和依賴。它展示了一個外部用戶能夠觀察到的系統功能模型圖。
用例圖中包含6個元素，分別是執行者（Actor），用例（Use Case），關聯關系（Association），包含關系(Include)，擴展關系(Extend)以及泛化關系(Generalization)。
- 角色（Actor）：即使用本系統的有哪些角色，不同的角色使用的系統功能部分是不同的，在用例圖中用小人
表示。其中，角色可能是人，也可能不是人，而是另外的一個系統，本系統與另外一個系統交互的話，可以將另外一個系統畫成某某角色。
分析得到角色的原則，也可以看做是我們在獲得角色時，需要思考的內容：
1）有哪些直接使用系統的人
2）涉及到哪些維護人員
3）使用哪些外設
4）相連的其他系統
5）還有哪些人和事物對這個系統產生的結果感興趣。
- 用例（Use Case）：即系統具有的功能，在用例圖中用橢圓圈
表示，圈里用文字描述該用例，一般為動賓短語。
其中，某個用例不一定是只屬於一個角色的，有些用例是同時屬於多個角色的，即被多個角色“共享”。
- 關系：用例圖中涉及的關系有：關聯、泛化、包含、擴展。
1）關聯（Association）：表示參與者與用例之間的通信，任何一方都可發送或接受消息。【箭頭指向】：無箭頭或者Actor指向Use Case，將參與者與用例相連接，指向消息接收方 。圖標
或
2 ) 泛化（Generalization）：就是通常理解的繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。【箭頭指向】：子參與者指向父參與者或者子用例指向父用例
或
3 ) 包含（Include）：是指用例中的包含關系，通常發生在多個用例中，有可以提取出來的公共部分以便基用例復用.當兩個或多個用例中共用一組相同的動作，這時可以將這組相同的動作抽出來作為一個獨立的子用例，供多個基用例所共享。因為子用例被抽出，基用例並非一個完整的用例，所以include關系中的基用例必須和子用例一起使用才夠完整，子用例也必然被執行。include關系在用例圖中使用帶箭頭的虛線(Link/Traceability Link)
表示(在線上標注<<include>>)，箭頭從基用例指向子用例。 
注冊卡和刪除卡之前都必須檢驗卡是否存在，注冊卡和刪除卡着兩個用例並不完整，必須和查詢卡是否存在這個子用例一起才能完成它的功能。
文章管理包含添加文章，修改文章，刪除文章，審核文章才是一個完整的功能。
include的表示方法見如下圖所示;：
4 ) 擴展關系(Extend)：extend關系是對基用例的擴展，基用例是一個完整的用例，即使沒有子用例的參與，也可以完成一個完整的功能。extend的基用例中將存在一個擴展點，只有當擴展點被激活時，子用例才會被執行。 extend關系在用例圖中使用帶箭頭的虛線(Link/Traceability Link)表示(在線上標注<<extend>>)，箭頭從子用例指向基用例。
查詢學生信息可以獨立完成，不需要子用例的參與。只有點擊導出為excel按鈕或打印按鈕時才會執行相應的動作。
用戶登錄可以獨立完成，不需要子用例的參與。只有點擊QQ登錄或新浪帳號登錄才會執行相應的動作。
extend的表示方法見如下圖所示;：
- 一個完整的用例圖實例
- 附：UML用例UseCase的幾個理解誤區
誤區1：用例就是功能點
這是一個很大的誤區，也是技術人員容易犯的一個錯誤。功能點是站在軟件開發的角度來說的，而用例是站在用戶的角度來說的。獲取用例是領域專家干的活，而最后的功能實現是技術專家干的活，不同的角色。所以獲取用例的關鍵就是要站在用戶角度看問題。
怎么獲得用例？首先確定位於系統邊界之外的主角是誰？他的期望和目的是什么？這個期望和回報要求在系統之內。所以，用例是幫助確定系統邊界的一個好方法。用例也是獲取需求的一個方法。
誤區2：用例和步驟混淆
舉例來說，用戶輸入密碼，要有密碼錯誤提示，並且三次錯誤自動鎖定用戶，最后登錄成功。“輸入密碼”是一個步驟，不是用例。整個過程是一個用例：“用戶登錄”。中間步驟和場景可以有很多。比如輸入密碼是一個步驟；“要有密碼錯誤提示”這是一個業務需求，不是用例；“並且三次錯誤自動鎖定用戶”這是一個業務需求，也不是用例。
用例的特征：有目的，有用戶期望，有回報預期。當結果不可定義或不清晰時不能用Use Cases，意思是如果目標成功或目標失敗不能有一個明確的定義，那就不是一個用例。舉例來說，用戶輸入密碼，這是不是一個用例？用戶輸入密碼的目的是什么？是為了輸入密碼嗎？不是的，是為了登錄系統，所以，用戶登錄是一個用例。
誤區3：用例的粒度不明
用例的粒度大小要看情況，因地制宜，因時制宜。
因地制宜：一般系統用例10-50個為宜。比較小型系統可以粒度更小一些。
因時制宜：在業務建模階段，在概念建模階段，在系統建模階段都是不同的。在系統建模階段，用例的粒度是以每個用例能夠描述操作者與計算機的一次完整的交互為宜。根據項目的不同階段，不斷縮小邊界可以獲得更小的粒度用例。一個大的用例還可以include一個小的用例，比如網上下訂單是一個用例，修改訂單是一個子用例，因為除了用戶，管理員可以修改訂單，這個子用例有意義。
誤區4：用例和場景混淆
一個用例的執行是要有前因和后果的（前提是什么，結果會怎么樣）；比如，煮飯和炒菜是用例，他們各自都有步驟，各自有好幾個場景。比如煮飯，我可以用電飯鍋煮，也可以蒸飯，煮飯前要先淘米，等等，這些都是一個用例的不同場景，但用戶的最終目的都是一樣的。不要把用例和場景混淆。
誤區5：軟件工程是不是用例驅動？
軟件工程是不是用例驅動？需求是重要的，用例是構造需求的好方法。但如果你同時要考慮開發的所有因素包括重用，架構，花費，時間，你就無法僅僅從一個方面來驅動你的項目。好的軟件工程是被一系列重要因素所驅動的，而且因素也因不同的公司和項目有着不同的重要程度。這些因素包括： 技術上對於設計的考慮，用戶需求，重用，可更改性，系統性能，標准化，日程的安排以及其他的商務驅動。每個項目都有着自己不同的考慮。對於每一種情況，可以精確的說項目被域模型和用例共同驅動。
誤區6：用例直接推導出設計
不要從用例直接推論出設計。如果這樣做，“用例開發”僅僅成為了功能分解的一個借口。用例止於系統接口的邊界！用例應該描述參與者使用系統時所遵循的次序，但用例決不說明系統內部采用什么步驟來響應參與者的刺激。
用例是幫助確定系統邊界的一個好方法。用例也是獲取需求的一個方法。用例也是產生測試用例的好方法。但是，從系統邊界、需求、到詳細設計還有很長的路要走。比如說，類圖，事實上類圖和用例圖沒有對應關系。換句話來說，用例是需求分析時的產物，類（邊界類外）的設計期的產物。
下面是菜單說明：
一：新建一個用例的模型 File->new Model
二：設置一下讓畫圖區的那些頁面線不顯示，這樣就不會干擾我們的視線。Tools->Display Preferences
三：設置一下線的箭頭這樣可以更好的清楚用例的出發者，也更好描寫需求。
四：設置一下用例圖的線，不設置的話會畫成折線，我們一般喜歡用直線，這樣可以更好的描寫用例。
五：設置一下讓名稱和密碼不一致，因為一致的話很麻煩 Tools->General Options
六： 工具欄 View->Toolbox
