用例圖主要用來描述角色以及角色與用例之間的連線關係。說明的是誰要使用系統，以及他們使用該系統可以做些什麼。一個用例圖包含了多個模型元素，如系統、參與者和用例，並且顯示這些元素之間的各種關係，如泛化、關聯和依賴。它展示了一個外部使用者能夠觀察到的系統功能模型圖。
【用途】：幫助開發團隊以一種視覺化的方式理解系統的功能需求。

用例圖中包含6個元素，分別是執行者（Actor），用例（Use Case），關聯關係（Association），包含關係(Include)，擴充套件關係(Extend)以及泛化關係(Generalization)。

• 角色（Actor）：即使用本系統的有哪些角色，不同的角色使用的系統功能部分是不同的，在用例圖中用小人表示。

  其中，角色可能是人，也可能不是人，而是另外的一個系統，本系統與另外一個系統互動的話，可以將另外一個系統畫成某某角色。
  

  分析得到角色的原則，也可以看做是我們在獲得角色時，需要思考的內容：

    1）有哪些直接使用系統的人
  
    2）涉及到哪些維護人員
  
    3）使用哪些外設
  
    4）相連的其他系統
  
    5）還有哪些人和事物對這個系統產生的結果感興趣。
  

• 用例（Use Case）：即系統具有的功能，在用例圖中用橢圓圈表示，圈裡用文字描述該用例，一般為動賓短語。

  其中，某個用例不一定是隻屬於一個角色的，有些用例是同時屬於多個角色的，即被多個角色“共享”。
  

• 關係：用例圖中涉及的關係有：關聯、泛化、包含、擴充套件。

  1. 關聯（Association）：表示參與者與用例之間的通訊，任何一方都可傳送或接受訊息。【箭頭指向】：無箭頭，將參與者與用例相連線，指向訊息接收方
     
  2. 泛化（Inheritance）：就是通常理解的繼承關係，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關係。子用例可以使用父用例的一段行為，也可以過載它。父用例通常是抽象的。在實際應用中很少使用泛化關係，子用例中的特殊行為都可以作為父用例中的備選流存在。【箭頭指向】：指向父用例
     
  3. 包含（Include）：指用例可以簡單地包含其他用例具有的行為，並把它包含的用例行為作為自身行為的一部分。包含關係代表著基礎用例會用到被包含用例，將被包含用例的時間流插入到基礎用例的時間流中。【箭頭指向】：指向分解出來的功能用例。在處理包含關係時，具體的做法就是把幾個用例的公共部分單獨地抽象成一個新的用例。主要有以下兩種情況需要用到包含關係。多個用例用到同一段的行為，則可以把這段共同行為單獨地抽象成一個用例，然後讓其他用例來包含這一用例。當某一個用例功能過多，事件流過於複雜時，也可以把某一段事件流抽象成一個被包含的用例，以達到簡化描述的目的。
     
  4. 在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴充套件用例【箭頭指向】：指向基礎用例
     擴充套件關係和包含關係的不同
     
     • 在擴充套件關係中，基礎用例提供了一個或者多個插入點，擴充套件用例為這些插入點提供了需要插入的行為。而在包含關係中，插入點只有一個。
     • 在擴充套件關係中，基礎用例的執行並不一定會涉及到擴充套件用例，擴充套件用例只有在滿足一定條件下才會被執行。而在包含關係中，當基礎用例執行外後，被包含用例時一定要被執行的。
       即使沒有擴充套件用例，擴充套件關係中的基礎用例本身也是完整的。而包含關係，基礎用例在沒有被包含用例的情況下是不完整存在
       

• 子系統(Subsystem)：用來展示系統的一部分功能，這部分功能聯絡緊密。
  

簡單旅館訂房示例，如有錯誤請指出：

附：UML用例UseCase的幾個理解誤區
參見UML用例UseCase的幾個理解誤區
誤區1：用例就是功能點
　　這是一個很大的誤區，也是技術人員容易犯的一個錯誤。功能點是站在軟體開發的角度來說的，而用例是站在使用者的角度來說的。獲取用例是領域專家乾的活，而最後的功能實現是技術專家乾的活，不同的角色。所以獲取用例的關鍵就是要站在使用者角度看問題。
　　怎麼獲得用例？首先確定位於系統邊界之外的主角是誰？他的期望和目的是什麼？這個期望和回報要求在系統之內。所以，用例是幫助確定系統邊界的一個好方法。用例也是獲取需求的一個方法。
　　誤區2：用例和步驟混淆
　　舉例來說，使用者輸入密碼，要有密碼錯誤提示，並且三次錯誤自動鎖定使用者，最後登入成功。“輸入密碼”是一個步驟，不是用例。整個過程是一個用例：“使用者登入”。中間步驟和場景可以有很多。比如輸入密碼是一個步驟；“要有密碼錯誤提示”這是一個業務需求，不是用例；“並且三次錯誤自動鎖定使用者”這是一個業務需求，也不是用例。
　　用例的特徵：有目的，有使用者期望，有回報預期。當結果不可定義或不清晰時不能用Use Cases，意思是如果目標成功或目標失敗不能有一個明確的定義，那就不是一個用例。舉例來說，使用者輸入密碼，這是不是一個用例？使用者輸入密碼的目的是什麼？是為了輸入密碼嗎？不是的，是為了登入系統，所以，使用者登入是一個用例。
　　誤區3：用例的粒度不明
　　用例的粒度大小要看情況，因地制宜，因時制宜。
　　因地制宜：一般系統用例10-50個為宜。比較小型系統可以粒度更小一些。
　　因時制宜：在業務建模階段，在概念建模階段，在系統建模階段都是不同的。在系統建模階段，用例的粒度是以每個用例能夠描述操作者與計算機的一次完整的互動為宜。根據專案的不同階段，不斷縮小邊界可以獲得更小的粒度用例。一個大的用例還可以include一個小的用例，比如網上下訂單是一個用例，修改訂單是一個子用例，因為除了使用者，管理員可以修改訂單，這個子用例有意義。
　　誤區4：用例和場景混淆
　　一個用例的執行是要有前因和後果的（前提是什麼，結果會怎麼樣）；比如，煮飯和炒菜是用例，他們各自都有步驟，各自有好幾個場景。比如煮飯，我可以用電飯鍋煮，也可以蒸飯，煮飯前要先淘米，等等，這些都是一個用例的不同場景，但使用者的最終目的都是一樣的。不要把用例和場景混淆。
　　誤區5：軟體工程是不是用例驅動？
　　軟體工程是不是用例驅動？需求是重要的，用例是構造需求的好方法。但如果你同時要考慮開發的所有因素包括重用，架構，花費，時間，你就無法僅僅從一個方面來驅動你的專案。好的軟體工程是被一系列重要因素所驅動的，而且因素也因不同的公司和專案有著不同的重要程度。這些因素包括： 技術上對於設計的考慮，使用者需求，重用，可更改性，系統性能，標準化，日程的安排以及其他的商務驅動。每個專案都有著自己不同的考慮。對於每一種情況，可以精確的說專案被域模型和用例共同驅動。
　　誤區6：用例直接推匯出設計
　　不要從用例直接推論出設計。如果這樣做，“用例開發”僅僅成為了功能分解的一個藉口。用例止於系統介面的邊界！用例應該描述參與者使用系統時所遵循的次序，但用例決不說明系統內部採用什麼步驟來響應參與者的刺激。
　　用例是幫助確定系統邊界的一個好方法。用例也是獲取需求的一個方法。用例也是產生測試用例的好方法。但是，從系統邊界、需求、到詳細設計還有很長的路要走。比如說，類圖，事實上類圖和用例圖沒有對應關係。換句話來說，用例是需求分析時的產物，類（邊界類外）的設計期的產物。