當用例檢視在外部使用者出現以前出現時，它捕獲到系統、子系統或類的行為。它將系統功能劃分成對參與者（即系統的理想使用者）有用的需求。而互動部分被稱作用例。用例使用系統與一個或者多個參與者之間的一系列訊息來描述系統中的互動。

用例圖包含六個元素，分別是：參與者(Actor)、用例(Use Case)、關聯關係(Association)、包含關係(Include)、擴充套件關係(Extend)以及泛化關係(Generalization)。

用例圖可一個包含註釋和約束，還可一個包含包，用於將模型中的元素組合成更大的模組。有時，可以將用例的例項引入到圖中。用例圖模型如下所示，參與者用人形圖示來標識，用例用橢圓來表示，連線表示它們之間的關係。

一．參與者（Actor）

1．參與者的概念

參與者是系統外部的一個實體，它以某種方式參與用例的執行過程。參與者通過向系統輸入或請求系統輸入某些事件來觸發系統的執行。參與著由參與用例時所擔當的角色來表示。在UML中，參與者用名字寫在下面的人形圖標表示。

每個參與者可以參與一個或多個用例。它通過交換資訊與用例發生互動（因此也與用例所在的系統或類發生了互動），而參與者的內部實現與用例是不相關的，可以用一組定義其狀態的屬性充分的描述參與者。

參與者有三大類：系統使用者、與所建造的系統互動的其它系統和一些可以執行的程序。

第一類參與者是真實的人，即使用者，是最常見的參與者，幾乎存在於每個系統中。命名這類參與者時，應當按照業務而不是位置命名，因為一個人可能有很多業務。

第二類參與者是其它的系統。這類位於程式邊界之外的系統也是參與者。

第三了參與者是一些可以執行的程序，如時間。當經過一定的時間觸發系統中的某個事件時，時間就成了參與者。

２．確定參與者

在獲取用例前首先要確定系統的參與者，開發人員可以通過回答以下的問題來尋找系統的參與者。

（1）         誰將使用該系統的主要功能。

（2）         誰將需要該系統的支援以完成其工作。

（3）         誰將需要維護、管理該系統，以及保持該系統處於工作狀態。

（4）         系統需要處理哪些硬體裝置。

（5）         與該系統那個互動的是什麼系統。

（6）         誰或什麼系統對本系統產生的結果感興趣。

在對參與者建模的過程中，開發人員必須要牢記以下幾點。

（1）         參與者對於系統而言總是外部的，因此它們可以處於人的控制之外。

（2）         參與者可以直接或間接的與系統互動，或使用系統提供的服務以完成某件事務。

（3）         參與者表示人和事物與系統發生交戶時所扮演的角色，而不是特定的人或者特定的事物。

（4）         每個參與者需要一個具有業務一樣的名字，在建模中不推薦使用類似“新參與者”的名字。

（5）         每一個參與者要必須有簡短的描述，從業務角度描述參與者是什麼。

（6）         一個人或事物在與系統發生互動時，可以同時或不同時扮演多個角色。

（7）         和類一樣，參與者可以具有表示參與者的屬性和可以接受的事件，但使用的不頻繁。

３．參與者之間的關係

因為參與者是類，所以多個參與者之間可以具有與類相同的關係。在用例檢視中，使用了泛化關係來描述多個參與者之間的公共行為。如果系統中存在幾個參與者，它們既扮演自身的角色，同時也扮演更具一般化的角色，那麼就用泛化關係來描述它們。這種情況往往發生在一般角色的行為在參與者超類中描述的場合。特殊化的參與者繼承了該超類的行為，然後在某些方面擴充套件了此行為。參與者之間的泛化關係用一個三角箭頭來表示，指向扮演一般角色的超類。這與UML中類之間的返還關係符號相同。

二用例（Use Case）

1．用例的概念

用例是外部可見的系統功能單元，這些系統功能由系統單元所提供，並通過一系列系統單元與一個或多個參與者之間交換的訊息所表達。用例的用途是，在不揭示系統內部構造的前提下定義連貫的行為。

用例的定義包含它所必須的所有行為——執行用例的主線次序、標準行為的不同變形、一般行為下的所有異常情況及其預期反應。從使用者的角度來看，上述情況很可能是異常情況；從系統的角度來看，它們是必須被描述和處理的附加情況。更確切地說，用例不是需求或功能的規格說明，但是也展示和體現其所描述的過程中的需求情況。在UML中，用例用一個橢圓表示。

在模型中，每個用例的執行都獨立與其它用例，儘管在執行一個用例時由於用例之間共享物件的原因可能會在用例之間產生隱含的依賴關係。每個用例都表示一個縱向的功能塊，這個功能塊的執行會和其它用例的執行混合在一起。

用例的動態執行過程可以用UML的互動來說明，可用用狀態圖、時序圖、協作圖或非正式的文字描述來表示。用例功能的執行通過系統中類之間的協作來實現。一個類可以參與多個協作，因此也參與了多個用例。

在系統層，用例表示整個系統對外部使用者可見的行為。一個用例就像外部使用者可以使用的系統操作。但是，它不又與操作不同，用例可以在執行過程中持續接受參與者的輸入訊息。用例也可以被像子系統和獨立類這樣的系統小單元所應用。一個內部用例表示了系統的一部分對其它部分呈現出的行為。例如，某個類的用例表示了一個連貫的功能塊，這個功能塊是該類提供給系統內其它有特定作用的類的。一個類可以有多個用例。

２．識別用例

用例圖對整個系統建模過程非常重要，在繪製系統用例圖前，還有許多工作要做。系統分析者必須分析系統的參與者和用例，他們分別描述了“誰來做”和“做什麼”這兩個問題。

識別用例最好的方法就是從分析系統的參與者開始，考慮每一個參與者是如何使用系統的。使用這種策略的過程中可能會發現新的參與者，這對完善整個系統的建模有很大的幫助。用例建模的過程是一個迭代和逐步精華的過程，系統分析者首先從用例的名稱開始，然後新增用例的細節資訊。這些資訊由簡短的描述組成，它們被精華成完整的規格說明。

在識別用例的過程中，通過回答以下幾個問題，系統分析者可以獲得幫助。

（1）         特定參與者希望系統提供什麼功能。

（2）         系統是否儲存和檢索資訊，如果是，由哪個參與者觸發。

（3）         當系統改變狀態時，是否通知參與者。

（4）         是否存在影響系統的外部事件。

（5）         哪個參與者通知系統這些事件。

３．用例與事件流

用例分析處於系統的需求分析階段，這個階段應該儘量避免考慮系統實現的細節問題。但是要實際建立系統，則需要更加具體的細節，這些細節寫在事件流檔案中。事件流的目的是為用例的邏輯流程建立文件，這個文件詳細描述系統使用者的工作和系統本身的工作。

雖說事件流很詳細，但其仍然是獨立於實現的方法的。換句話說，事件流描述的是一個系統“做什麼”而不是“怎麼做”。事件流通常包括：簡要說明、前提條件、主事件流、其它事件流和事後事件流。

（1）         簡要說明。每個用例應當有一個相關的說明，描述該用例的作用，說明應當簡明扼要，但應包括執行用例的不同型別的使用者和通過這個用例要達到的結果。

（2）         前提條件。用例的前提條件列出用例之間必須滿足的條件。例如，前提條件是另一個用例已經執行或使用者具有運行當前用例的許可權。但並不是所有用例都有前提條件。

（3）         主事件流和其它事件流。用例的具體細節在主事件流和其它事件流中描述。事件流是從使用者角度描述執行用例的具體步驟，關注系統“做什麼”，而不是“怎麼做”。主事件流和其它事件流包括：用例如何開始和結束、用例如何與參與者互動、用例的正常流程（主流程）、用例主事件流（其它事件流）的變體和錯誤流。

（4）         事後條件。事後條件是用例執行完畢後必須為真的條件。例如，可以在用例完成之後設定一個標識，這種資訊就是事後條件。與前提條件一樣，事後條件可以增加用例次序方面的資訊，如果要求一個用例執行完後必須執行另一個用，那麼就可以在事後條件中說明這一點。當然，並不是每個用例中都有事後條件。

三用例間的關係

用例除了與參與者發生關係外，還可以具有系統中的多個關係，這些關係包括包含關係、擴充套件關係和泛化關係。應用這些關係的目的是為了從系統中抽取出公共行為和其變體。

1．關聯關係（Association）

關聯關係描述參與者與用例之間的關係，它是用於表示類的掛系的關聯元類的例項。在UML中，關聯關係用箭頭來表示。

關聯關係表示參與者與用例之間的通訊。不同的參與者可以訪問相同的用例，一般說來它們和該用例的互動是不一樣的，如果一樣的話，說明它們的角色可能是相同的。如果兩中互動的目的也相同，說明它們的角色是相同的，就可以將它們合併。

２．包含關係（Include）

雖然每個用例的例項都是獨立的，但是一個用例可以用其它的更簡單的用例來描述。這有點像通過繼承父類並增加附加描述來定義一個類。一個用例可以簡單地包含其它用例具有的行為，並把它所包含的用例行為作為自身行為的一部分，這被稱作包含關係。在這種情況下，新用例不是初始用例的一個特殊例子，並且不能被初始用例所代替。愛UML中，包含關係表示為虛線箭頭交<<include>>字樣，箭頭指向被包含的用例。

包含關係把幾個用例的公共步驟分離成一個單獨的被包含用例。被包含用例稱作提供者用例，包含用例稱作客戶用例，提供者用例提供功能給客戶使用。用例間的包含關係允許包含提供者用例的行為到客戶用例的事件中。

包含關係使一個用例的功能可以在另一個用例中使用，如下所述。

（1）         如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另外一個用例中。其它用例可以和這兩個用例建立包含關係。

（2）         一個用例的功能太多時，可以用包含關係建模兩個小用例。

要使用包含關係，就必須在客戶用例中說明提供者用例行為別包含的詳細位置。這一點同功能呼叫有點類似。事實上，它們在某種程度上具有相似的語義。

３．擴充套件關係（Extend）

一個用例也可以被定義為基礎用例的增量擴充套件，這被稱作擴充套件關係，擴充套件關係是把新的行為插入到已有的用例中的方法。同一個基礎用例的幾個擴充套件用例可以在一起應用。基礎用例的擴充套件增加了原有的語義，此時基礎用例而不是擴充套件用例被作為例子使用。在UML中，擴充套件關係表示為虛線箭頭加<<extend>>字樣，箭頭指向被擴充套件展的用例。

基礎用例提供了一組擴充套件點，在這些新的擴充套件點中可以新增新的行為，而擴充套件用例提供了一組插入片片段，這些片段能夠被插入到基礎用例的擴充套件點上。基礎用例不必知道擴充套件用例的任何細節，它僅為其提供擴充套件點。事實上，基礎用例即使沒有擴充套件用例也是完整的，這點與包含關係有所不同。一個用例可能有多個擴充套件點，每個擴充套件點可以出現多次。但是一般情況下，基礎用例的執行不和涉及到擴充套件用例，只有特定的條件發生，擴充套件用例才被執行。擴充套件關係為處理異常或構建靈活的系統框架提供了一種有效的方法。

４．泛化關係（Generalization）

一個用例可以被特別列舉為一個或多個用例，這被稱為用例泛化。當父用例能夠被使用時，任何子用例也可以被使用。在UML中用例泛化與其它泛化關係的表示法相同，用一個三角箭頭從子用例指向父用例。

在用例泛化中，子用例表示父用例的特殊形式。子用例從父用例處繼承行為和屬性，還可以新增、覆蓋或改變繼承的行為。如果系統中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關係。

用例建模技術

一．對語境建模

對於一個系統，會有一些事物存在於其內部，而一些事物存在於其外部。存在於系統內部的事物的任務是完成系統外部事物所期望的系統行為，存在於系統外部並與其進行互動的事物構成了系統的語境，即系統存在的環境。在UML建模中，用例圖對系統的語境進行建模，強調的是系統的外部參與者。對系統語境建模應當遵循以下的方法：

（1）         用以下幾組事物來識別系統外部的參與者：需要從系統中得到幫助以完成其任務的組；執行系統功能時所必須的組；與外部硬體或其它軟體系統進行互動的組；為了管理和維護而執行某些輔助功能的組。

（2）         將類似的參與者組織成泛化/特殊化的結構層次。

（3）         在需要加深理解的地方，為每個參與者提供一個構造型。

（4）         將參與者放入到用例圖中，並說明參與者與用例之間的通訊路徑。

二．對需求建模

需求就是根據使用者對產品功能的期望，提出產品外部功能的描述。需要分析所要做的工作是獲取系統的需求，歸納系統所要實現的功能，使最終的軟體產品最大限度的貼近使用者的要求。對系統需求建模可以參考以下的方法。

（1）         識別系統外部的參與者來建立系統的語境。

（2）         考慮每一個參與者期望的行為或需要系統提供的行為。

（3）         把公共的行為命名為用例

（4）         分解公共行為，放入到新的用例中以供其它的用例使用：分解異常行為，放入新用例中以延伸為主要的控制流。簡而言之，就是確定提供者用例和擴充套件用例。

（5）         在用例檢視中對用例、參與者和它們之間的關係進行建模。