用例圖是用來描述什么角色通過某某系統能做什么事情的圖，用例圖關系的是系統的外在表現，系統與人的交互，系統與其它系統的交互。

下面逐一說明用例圖中各種符號的意義：?
小人： ?
對使用某系統的用戶進行分類后，可以總結出使用本系統有哪些角色，不同的角色的工作責任不太一樣，他們需要用到的系統的功能也會不太一樣。?
小人就是角色，它給了我們一個啟示，我們思考某系統的需求時，可從不同角色的角度來思考。?
例如：我們要做一個考勤系統，你會怎樣思考呢？會一下子列出很多功能？比較好的方式，應該是先思考什么人會用這個系統，我們大概可以估計一般員工、高層領導、前臺、財務等都會用這個系統，對于一般員工來說除了打卡，他還關注什么？對于前臺，她是不是要做一些考勤的統計？而財務是不是要根據考勤情況來調整員工的薪金？這樣的思考方式，會讓我們更容易全面發掘系統的需求。?
還需要特別說明的是：角色可能是人，也可能不是人，而是另外的一個系統，本系統與另外一個系統交互的話，可以將另外一個系統畫成某某角色。?
圈圈： ?
圈圈里面會有一段動賓結構的文字，也就是“動詞+名詞”這樣的方式，這個圈圈+圈圈里面的文字，就是用例，這些用例表明了系統能做什么事情。?
以考勤系統為例：有兩個用例叫“打卡”、“查看自己的考勤情況”，這個兩個圈圈分別用一條線連到了“一般員工”這個角色，我們可以按這樣的順序來讀這個圖：先讀出角色的名字，然后讀出用例中的文字。按著這樣的讀法，我們可以得到兩句完整的句子：?
“一般員工打卡”?
“一般員工查看自己的考勤情況”?
大家可以用這樣的方式來檢查自己用例圖是否畫得合適。?
某用例不一定是只屬于某個角色的，有不少用例是多個角色“共享”的。?
大框框： ?
在所有用例的外面，有一個方框，這個方框只框住了用例，沒有框住角色，這個東西就叫做系統邊界，框框的上部會注明本系統的名字。?
我們所做的系統，是不可能包括角色的，系統要發揮各種作用，要靠各角色“穿越”系統邊界來使用本系統的用例。?
系統邊界能清晰表達出系統的范圍，并不是所有的用例圖都需要畫出系統邊界的，一般只需要在全局用例圖中畫出系統邊界，當對用例進行細化時，不需要畫出系統邊界。?
線條：?
線條是指角色與用例之間的線條，線條有三種：無箭頭的，指向用例的箭頭，指向角色的箭頭。無論是否有箭頭，這些線條是用來聯系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。?
有箭頭的線條，表示角色與系統交互的過程中，數據的流向，如果箭頭指向用例，就說明角色需要往系統輸入數據，如果箭頭指向角色，說明系統往角色輸出數據。?
而沒有箭頭的線條，則沒有明確表示數據的流向，一般情況下不需要明確表示數據的流向，只需要畫無箭頭的線條就可以了。

用例圖中的Extend、Include、繼承

“打印報表”這個用例有一條指向“查看一般報表”用例的虛線，虛線上有“<<extend>>”的字樣，這表示“打印報表”擴展了“查看一般報表”，用戶可以在“打印報表”的基礎上做“打印報表”的工作，這就是Extend的意思。如果“打印報表”這個用例不存在，是不會影響“查看一般報表”這個用例的，而“查看一般報表”這個用例如果不存在，則用戶無法在“查看一般報表”的基礎上做“打印報表”的工作了。?
“管理數據”有三根虛線，箭頭分別指向“查看數據”、“新增數據”、“修改數據”，虛線上有“<<include>>”字眼，這表示“管理數據”包含“查看數據”、“新增數據”、“修改數據”三個子用例，這就是Include的意思。在以下情況下，會用到Include：?
1)某些用例的其中一些步驟可以單獨抽離出來，成為一個子用例。?
2)以“樹”的方式條理化各種用例，用Include來組織好父子用例，子用例可以再次Include自己的子用例。?
上圖中將“管理數據”進一步分解為子用例，其實是沒有必要的，實際項目中數據的查看、增加、修改、刪除操作是很常見的，我們在描述用例的時候一般只需要將這4種操作說成“管理XX”就可以了。?
細心的朋友可能會發現，角色與角色之間怎么會有一個類圖中的“繼承”符號呢？從上圖看來，就是錄入員繼承一般用戶，領導繼承錄入員，什么意思呢？?
無論是錄入員還是領導，都需要先登錄系統，才能使用各種功能，我們是否需要分別在“登錄用戶”與“錄入員”、“領導”之間各拉一條線？?
一般用戶可以查看一般報表、打印報表，那么錄入員、領導是否也可以呢？?
錄入員這個角色繼承了一般用戶，其實就是表示一般用戶能做的事情，錄入員也能做，同意道理，錄入員能做的事情，領導也能做，這個“繼承”符號就是這個意思。在實際工作中，我們往往需要用好這個“繼承”符號，將角色進行適當的抽象。

用例圖何時需要分解、何時不需要分解？?
也就是分解的粒度通常情況下是多大呢？

用例的表達粒度是由自己控制的，以下幾點建議供參考：?
1.在客戶能準確全面理解的基礎上，用例約精簡越好。?
2.重點難點用例，應詳細去描述。?
3.用例需要開發人員去實現，要讓開發人員能看懂。?
4.用例圖不是萬能的，也不是表達需求的唯一方式，我往往會以用例圖為主同時附加其它的表達方式來表達，某些特殊項目，我甚至不用用例圖來描述需求。

?

用例圖 usr case