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

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

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

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

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

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

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

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

• 關系：用例圖中涉及的關系有：關聯、泛化、包含、擴展。

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

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

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

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

總結

以上是生活随笔為你收集整理的UML——Use Case Diagram（用例图）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。