用例是最簡單的UML元素，用例圖是最簡單的UML圖，但它也可能是UML中最有用的元素之一。儘管我們用包將工作分解為工作包、團隊任務或單項任務，也就是説包是組織UML中的各種圖及元素的工具。但是用例圖可以幫助我們確定任務，以及應當如何將它們分組並確定工作範圍。
每個用例都代表用户希望系統幫助實現的一個目的或目標。例如，對於銀行ATM機，客户希望使用它來取款、存款、轉賬或者修改密碼等，而銀行則希望使用它可以獲得存取款明細等。
要使系統具有實用性，它就必須為用户帶來價值。例如銀行ATM機，對於客户而言，可以省去或節約人工櫃枱排隊等候的時間，對於銀行而言可以降低人力資源成本。在用例的術語中，對於所有與系統產生交互的對象我們統稱為“參與者（Actor）”。參與者涵蓋了所有與系統產生交互的用户，例如客户、工作人員、管理人員、維護人員等。任何可以使用系統（主動或者被動）的人都可以被視為參與者。
對於圖書館系統，參與者包括讀者、圖書管理員、編目人員、出入庫人員等；對於打車APP，參與者包含乘客、司機、管理人員、客服等；對於銀行ATM，參與者包含客户、款箱管理員、運維人員等。
此外，與當前系統相關聯的其他系統、設備、傳感器等都可以視為參與者。
回到用例本身，用例必須為參與者提供價值。許多程序員對“用例為參與者提供價值”感到困惑，經常與函數或子程序返回一個值混淆。所謂提供價值意味着實現了某種期望的結果，它是比函數或子程序返回值更高層次的結果。例如對於銀行ATM，“取款”是一個用例，它的價值在於實現了客户獲得現金的目標，而為了實現這個目標，銀行ATM識別卡片、客户輸入密碼及ATM判斷密碼是否正確等只是“取款”這個用例實現的步驟，它們都有返回值，但是這些並非客户的目標，它沒有為客户帶來價值或讓客户受益，因此它們不是用例。
用例是行為模型的一部分。一個業務用例通常描述一個完整的業務，一個系統用例通常描述一個完整的系統功能。一個用例描述一個場景，它也可以表示一組具有相似目標的相關場景。通常使用結構化文本（用例規約）、故事板、序列圖、狀態機或活動圖來詳細描述這些場景。
在UML中使用橢圓表示用例，用例的名稱寫在橢圓內部，如下圖所示。用例的名稱表示參與者的目標。通常，用例名稱應當使用“動賓”結構，例如存款、取款、修改密碼等，而這個動賓結構的主語就是對應的參與者，即客户存款、客户取款、客户修改密碼等。

關於用例命名，有一個簡單實用的技巧，即在參與者目標前加上“系統，請幫我……”或類似的變體。例如：

• 系統，請幫我取款。
• 系統，請幫我修改密碼。
• ……

遵循上述形式獲得的用例名稱通常是正確的，並且很容易理解。然而有些特殊的用例不適用這種命名的方法。例如，在系統或參與者具備自主能力的場景下，一個機器人系統會自行進入休眠狀態，一個時鐘會自動計時，此時沒有具有傳統目標的傳統參與者。
用例圖簡單易懂，幾乎不需要經過專業訓練就可以閲讀和開發，而用例圖又是描述需求的手段，故而通常它由需求分析人員與參與者的代表共同開發，或者由需求分析人員開發後，與參與者討論修改而成。最終形成的用例圖還須交給各參與者代表進行審查。參與者代表審查用例圖非常有必要且有價值，因為參與者可以明確知道用例圖是否包含了他們自己所有的目標，或者是否存在跟他們不相關的目標。也正是基於此，在為用例命名時應當使用參與者的術語，而避免使用IT術語或者實現時的概念，同時力求簡單、明確，確保每個人都能理解。
系統開發人員傾向於圍繞用例來組織項目，因為這樣可以使項目更易於相關各方理解。通常一個項目應當生成需求或設計文檔，可以考慮先按參與者再按用例來組織文檔結構（如下圖所示），同時也可以通過創建相關用例的包來構建包結構。

本文簡單討論了用例的概念及如何發現用例，關於用例與參與者更深入的概念與知識，請參閲博客下UML合集中的其他相關文章。