用例圖使用戶 與開發人員交流的一種重要的方式，是對用戶需求的一種描述。開發人員從用戶的角度整體上理解系統的功能。
用例圖主要有三種元素：參與者（Actor），用例，以及用例圖中對象間到的關系。其中關系有包含、擴展是用例圖中特有的，泛化在其他類圖中同樣存在。
包含:當可以從兩個或兩個以上的用例中提取公共行為時，應該使用包含的關系來表示它們。其中這個提取出來的公共用例成為抽象用例，而把原始用例成為基本用例或基礎用例。其中“<<include>>”是包含關系的構造型，箭頭指向抽象用例。
例如，在機房收費系統中“注冊學生信息”和“充值”兩個用例都需要操作員或者管理員登陸，為此，可以定義一個抽象用例“用戶登陸”。用例“注冊學生信息”和“充值”與用例“用戶登陸”之間的關系就是包含關系。
如圖 
有時當某用例的事件流過於復雜時，為了簡化用例的描述，我們也可以抽象出一個基用例，來包含這些顆粒的用例
作用：當多個用例需要使用同一段事件流時，抽象成為公共用例，可以避免在多個用例中重復地描述這段事件流，也可以防止這段時間流在不同用例中的描述出現不一致。當需要修改這段公共的需求時，也只要修改一個用例，避免同時修改多個用例而產生的不一致和重復性工作。另外，當某個用例的事件流過於復雜時，為了簡化用例的描述，也可以將某段事件流抽象成為一個被包含的用例。
2、擴展關系
如果一個用例明顯地混合了兩種或者兩種以上的不同場景，即根據情況可能發生多種分支，則可以將這個用例分為一個基本用例和一個或多個擴展用例，這樣可能會使描述更加清晰。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此他能根據基用例中擴展點的當前狀態來決定是否執行自己。而擴展用例對基用例不可見。如機房收費系統中“維護學生信息”操作時如果發現信息有誤或者更新則需要使用“修改學生信息”用例完成更新，所以用例“查詢上機記錄”和“導出EXCEL”之間的關系就是擴展關系。“<<extend>>”是擴展關系的構造型，箭頭指向基本用例。
如圖 
包含關系和擴展關系的聯系和區別
聯系：都是從現有的用例中抽取出公共的那部分信息，作為一個單獨的用例，然后通后過不同的方法來重用這個公共的用例，以減少模型維護的工作量。
區別：擴展關系中基本用例的基本流執行時，擴展用例不一定執行，即擴展用例只有在基本用例滿足某種條件的時候才會執行。
包含關系中基本用例的基本流執行時，包含用例一定會執行。
3、泛化
當多個用例共同擁有一種類似的結構和行為時，可以將他們的共性抽象成為父用例，其他的用例作為泛化關系的子用例。在用例的泛化關系中，子用例是父用例的一種特殊形式，它繼承了父用例的所有結構、行為、關系。其中三角箭頭指向父用例。假如在機房收費系統的注冊可以通過本地注冊和網上注冊。則
用例圖如 
同樣，一般用戶，操作員，管理員之間也存在泛化的關系
如圖 
轉：UML中擴展和泛化的區別
泛化表示類似於OO術語“繼承”或“多態”。UML中的Use Case泛化過程是將不同Use Case之間的可合並部分抽象成獨立的父Use Case，並將不可合並部分單獨成各自的子Use Case；包含以及擴展過程與泛化過程類似，但三者對用例關系的優化側重點是不同的。如下：
●泛化側重表示子用例間的互斥性；
●包含側重表示被包含用例對Actor提供服務的間接性；
●擴展側重表示擴展用例的觸發不定性；詳述如下：
既然用例是系統提供服務的UML表述，那么服務這個過程在所有用例場景中是必然發生的，但發生按照發生條件可分為如下兩種情況：
⒈無條件發生：肯定發生的；
⒉有條件發生：未必發生，發生與否取決於系統狀態；
因此，針對用例的三種關系結合系統狀態考慮，泛化與包含用例屬於無條件發生的用例，而擴展屬於有條件發生的用例。進一步，用例的存在是為Actor提供服務，但用例提供服務的方式可分為間接和直接兩種，依據於此，泛化中的子用例提供的是直接服務，而包含中的被包含用例提供的是間接服務。同樣，擴展用例提供的也是直接服務，但擴展用例的發生是有條件的。
另外一點需要提及的是：泛化中的子用例和擴展中的擴展用例均可以作為基本用例事件的備選擇流而存在。