1. 概述
用例圖（Use Case Diagram）描述“使用者、需求、系統功能單元”之間的關係，是參與者所能觀察和使用到的系統功能模型圖。
用例圖用於需求分析階段
用例圖包含6個基本元素：參與者（Actor）、用例（Use Case）、泛化關係（Generalization）、擴充套件關係（Extend）、包含關係（Include）和關聯關係（Association）。
2、用例（Use Case）
用例是外部可見的系統功能部分，用例的主要作用是在不揭示系統內部構造的前提下定義了連貫的行為。
2.1>、初識用例
用例包含了所必需的全部行為，即執行用例的主線次序、標準行為的不同變形、一般行為下的所有異常情況及其預期的反應。從使用者角度來看，用例包含的行為可能是異常情況，但從系統角度來看，則是必須被描述和處理的附加情況。用例不是系統需求或功能的規格說明，而是系統所描述過程中的需求情況。
在UML中，用例用一個橢圓表示，並且每個用例都必須有一個名字，該名字不能與其他的用例重名。
在UML中，每個用例的執行都獨立於其他用例。每個用例都表示一個縱向的功能模組，這些模組在執行時會與其他用例混合執行。
用例的動態執行過程可以用UML中的狀態圖、協作圖、時序圖來描述，也可以用非正式的文字來描述。
2.2>、確定用例
確定用例最好的方法是從分析系統的參與者開始，考慮每個參與者是如何使用系統的。
確定系統用例要明確以下問題：
（1）特定參與者希望系統提供什麼功能？
（2）當系統改變狀態時，是否通知參與者？
（3）是否存在影響系統的外部事件？
（4）哪個參與者通知系統這些事件？
（5）系統是否儲存、檢索資訊？如果需要，則由哪些參與者出發？
2.3>、事件流
事件流描述的是一個系統“做什麼”，而不是“怎麼做”。事件流包括簡要說明、前置條件、主事件流和其他事件流、後置條件。
（1）簡要說明。每個用例都應該有一個說明，描述用例的作用。說明應該包括執行用例的不同型別使用者和通過用例所達到的效果。
（2）前置條件。即用例的必須滿足的條件。前置條件是另一個用例已經執行或使用者具體有執行當前用例的許可權。並不是每個用例都有前置條件。
（3）主事件流和其他事件流。用例的具體細節在主事件流和其他事件流中描述。事件流是從使用者角度描述執行用例的具體步驟，關注系統“做什麼”，而不是“怎麼做”。主事件流和其他事件流包括：用例的開始、用例的互動、用例的正常流程、用例的事件流變體、用例的錯誤流、其他事件的變體和錯誤流、用例的結束。
（4）後置條件。該項是用例執行完後必須為真的條件。並不是每個用例都有後置條件。
3、參與者（Actor）
參與者是系統外部的一個實體，它以某種方式參與用例的執行過程。參與者通過向系統中輸入或請求系統輸入某些事件來觸發系統的執行。
3.1>、初識參與者
每個參與者可以參與一個或多個用例，他通過交換資訊與用例發生互動，而和參與者的內部實現沒有關係。
參與者一般分為三類：系統使用者、其他系統、可執行的程式。
（1）系統使用者。該類參與者是最直接的，需要使用系統的使用者。
（2）其他系統。在當前專案範圍之外，需要建立與其他系統的介面。這類位於專案邊界之外的系統也是參與者。
（3）一些可執行的程式。如時間，當經過一定時間段後，發生系統中的某個事件時，時間成為參與者。
3.2>、識別參與者
獲取用例之前，首先要確定系統的參與者。參與者表示人和事物與系統發生互動時所扮演的角色，而不是特定的人或特定的事物，並且一個人可以扮演多個角色。
參與者的識別方法：
（1）系統主要功能的使用者；
（2）系統所服務的物件及要完成的工作；
（3）系統的維護、管理人員；
（4）系統所需要的硬體裝置；
（5）與該系統互動的其他系統；
（6）對本系統產生的結果感興趣的人或其他系統。
3.3>、參與者與參與者之間的關係
參與者不是具體的人或物，而是類，所以多個參與者之間關係是類與類之間的關係。在用例圖中，使用泛化關係來描述多個參與者之間的公共行為。
參與者之間的泛化關係
3.4 用例與用例之間的關係
用例之間的關係包括：包含關係、泛化關係、關聯關係、擴充套件關係，應用這些關係的目的是為了從系統中抽取公共行為及其變體。
3.4.1 包含關係
包含關係：一個用例可以簡單地包含其他用例具有的行為，並把它所包含的用例行為作為自身的一部分。在這種情況下，新用例不是初始用例的一個特殊例子，並且不能被初始用例所代替。
在UML中，包含關係用虛線箭頭加<<include>>來表示，箭頭指向被包含的用例。
包含關係把幾個用例的公共步驟分離成一個單獨的被包含用例。
示例：
3.4.2 泛化關係
用例泛化：一個用例可以被特別列舉為一個或多個子用例。當父用例能夠被使用時，任何子用例也可以被使用。
在UML中，用例泛化用一個三角箭頭從子用例指向父用例。
在用例泛化中，子用例表示父用例的特殊形式。子用例可以從父用例繼承屬性與行為，還可以新增、改變繼承的行為。
示例：
3.4.3 關聯關係
關聯關係描述參與者與用例之間的關係，用於表示類的關係的關聯元素的例項。
關聯關係表示參與者與用例之間的通訊，不同的參與者可以訪問同一個用例。
3.4.4 擴充套件關係
擴充套件關係是一個用例被定義為基礎用例的增量擴充套件，通過擴充套件關係把新的行為插入到已有用例中。擴充套件關係中，擴充套件用例是基礎用例的一個相對獨立並且可選的用例。
在UML中，擴充套件關係用虛線箭頭加<<extend>>表示，箭頭指向基礎用例，即被擴充套件的用例。
示例：讀者在歸還圖書館借書時，若超過應歸還日期，則需要超期罰款；若未超過歸還日期，則不需要超期罰款。
4、UML語境建模技術
在UML中，利用用例圖對系統語境進行建模，強調的是系統的外部參與者。具體建模方法如下：
（1）識別系統外部的參與者；
（2）在需要加深理解的地方，為每個參與者提供一個構造型；
（3）將參與者放入到用例圖中，並說明參與者與用例之間的通訊路徑；
（4）將類似參與者組織成泛化的結構層次。
5、UML需求建模技術
軟體需求是根據使用者對產品的功能的期望，提出產品外部功能的描述。需求分析師的工作是獲取系統的需求，歸納系統所要實現的功能，使最終的軟體產品最大限度貼近使用者的要求。需求分析師一般只考慮系統要做什麼，而儘可能不去考慮怎麼做。
對系統建模可以參考如下方法：
（1）識別系統外部的參與者，從而建立系統的語境；
（2）考慮每一個參與者期望的行為或需要系統提供的行為；
（3）把公共行為命名為用例；
（4）確定供其他用例使用的用例和擴充套件其他用例的用例；
（5）在用例圖中對用例、參與者和它們之間關係建模；
（6）用描述非功能需求的註釋修飾用例圖。