自由分布
括號圖
使用案例圖（Use Case Diagram）是由參與者（Actor）、用例（Use Case）以及它們之間的關係構成的用於描述系統功能的視圖，是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖。用例圖常在需求分析階段使用。
在開發系統之前，最重要的工作是獲取使用者的需求，而在使用者需求中最重要的是關於使用者提出的系統功能性需求，我們可以藉助使用用例圖來視覺化的表達使用者的需求。
視覺化用例圖
用例圖中主要的元素包括參與者、用例以及各元素之間的關係。除此之外，用例圖中還可以包含註解和約束。
1. 參與者的概念
參與者（Actor）是與主體系統互動的外部實體，參與者可以是系統外部的人、子系統、其它系統等。
每個參與者其實都是一個角色集。在UML中，參與者使用使用人形的圖形表示，並給這個參與者一個名字。如下圖的「讀者」即是圖書館借閱系統中的一個參與者。
用例圖參與者
參與者應位於系統邊界之外，而不是系統的一部分。
2. 如何辨識參與者
在進行用例建模時，確定參與者是使用用例圖建模的第一步。那麼，如何確定係統的參與者呢？我們可以從以下思路來考慮：
（1）系統的服務對象--如圖書館借閱系統中的讀者；
（2）為其提供支援以完成工作的人--如圖書館借閱系統中的圖書館工作人員，他需要藉助系統幫助讀者完成借閱、還書、催還工作；
（3）系統的維護者：負責安裝、維護和管理系統的人員，在這種情況下，需要係統確實提供了相關功能以幫助這類人員完成安裝、維護和管理工作；
（4）外部設備：需要向外部設備傳輸訊息或從外部設備讀入訊息，如讀卡機；
（5）其它系統或子系統：如藉閱系統中的財務系統，財務系統並非藉閱系統的功能，但藉閱系統需要向其傳遞訊息以完成超期罰款工作；
（6）時間：在預定的時刻，有特定事件自動發生，如自動備份、定時提醒等；
（7）特定事件：如外帶系統中自動接單，是由訂單產生事件所推動的。
在識別參與者時，要注意以下幾點：
（1）參與者位於系統的外部，而非系統的一部分；
（2）參與者透過系統邊界與系統互動；
（3）參與者的圖標雖然使用人形圖標來表示，但參與者不一定是人，也可能是其它子系統、其它系統、時間、溫度等其它因素。
3. 參與者間的關係
參與者間的主要關係是泛化。泛化使用實線空心三角形箭頭來表示，箭頭指向更一般的參與者，箭尾端在「具體」參與者這端。泛化關係是一般和特殊（具體）之間的關係。在泛化關係中一個參與者的抽象描述可以被一個或多個具體的參與者所分享。下圖描述了圖書館借閱系統中參與者之間的泛化關係：
圖書館借閱系統參與者泛化關係
上圖中，讀者是一個「一般」參與者，讀者下面的教職員、學生、退休教職員等是「具體」的參與者。參與者泛化可以理解為：「具體」參與者是一種「一般」參與者，如教職員是一種讀者。在參與者泛化中，表示「一般」參與者可執行的用例，作為「具體」（「特殊」）參與者也可以執行。
1. 用例的概念
用例是參與者可以感受到的系統服務或功能單元。它定義了系統要實現的一個目標。用例只定義系統的一個行為，而不顯示系統的內部結構。
用例最大的優點是站在使用者的角度描述系統功能。在圖形上，用例使用實線橢圓來表示，並在橢圓內部或下部標註用例的名稱：
借閱圖書用例
2. 識別用例
可以透過以下要點來識別用例：
（1）參與者需要係統提供哪些功能，以支援他的工作？
（2）參與者是否需要查詢系統中的某些資訊？
（3）參與者是否需要改變系統中的某些訊息，如建立、修改和刪除操作？
（4）系統發生的特定事件或狀態的改變是否需要通知參與者？
（5）系統哪些外部事件會促使系統執行相關功能以因應？
（6）系統是否提供相關功能以協助維護人員來維護系統？
3. 用例識別的要點
（1）識別出的用例應該反應出系統的目標，即“要做什麼”，而不是“怎麼做”，就是說用例不是系統實現的細節；
（2）從參與者（使用者）的角度出發定義用例，而非系統的角度；
（3）用例應提供參與者有價值的結果，而非動作的集合；
（4）避免陷入功能分解，步驟分解；
（5）每個參與者都應該有可執行的用例，每個用例都應關聯至少一個參與者。
4. 命名用例
在確定好系統的用例後，需要為各個用例進行命名。使用案例的命名需要站在使用者的角度描述參與者所達到的目標，可以使用下述命名方式：
動詞+賓語
也就是說，用例的名稱應該是動賓短語的格式。如選課、借閱圖書、訂購貨物、使用信用卡付款。
5. 用例的粒度
用例粒度是指用例細化或綜合系統功能的程度，也可以說用例所包含的系統服務或功能單元的多寡。用例粒度過粗或過大，則用例包含的系統功能就越多，反之越少。用例粒度過粗，不便於理解系統，粒度過細會使用例模型過於龐大，造成設計困難。用例粒度過細，可能會陷入功能分解，如：
用例粒度初始
事實上，系統中許多業務都包含這種增、刪、改、查的操作，這樣做並不能為用戶提供任何有意義的目標，反而會忽略了用戶的真正目的。
上面這種「增刪改查」無非是使用者管理，這才是參與者的真實目的。使用下面這種方式處理上面的用例也許會更好一些：
用例粒度精簡
管理使用者這種用例體現了系統管理員的一個目標或任務。如果要加入上增刪改查，可以使用下面的方式來表達會比較好。
用例粒度優化後
在用例建模中常犯的另一個錯誤是把步驟當作用例。如下面這個，似乎挺完美，但是很明顯是把操作步驟當作用例了：
操作步驟當作用例錯誤範例
上面這些步驟，無非就是完成使用者這個參與者的目標：註冊。因此，應該改成下面這個樣子：
用例優化後
在用例建模中，常犯的第3個錯誤是把系統活動當作用例。在下面這個用例圖中，建立連線物件、建立指令物件和執行SQL語句是系統內的活動，是使用者無法感知的，不是使用者的目的，使用者也不關心。所以這種用例圖是不準確的：
系統活動當用例錯誤範例
在用例建模中常犯的第4個錯誤是使用系統觀點來命名用例。
用系統觀點來命名用例錯誤範例
上面左右這兩個用例圖，哪個畫得更好呢？很明顯，右邊的比左邊的要好，因為右邊的是從用戶的角度命名的用例，而左側的用例是從系統的角度對用例進行命名，用戶看到後會感到莫名其妙的。
6. 用例規約
用例圖在總體上描述了使用者的功能需求（系統提供的功能或服務），但對於每個用例還要進行詳細的描述，以便讓人們知道這個用例具體要做什麼，這就是用例規約。也就是說，用例模型實質上是由用例圖和對每個用例的詳細描述（用例規約）所組成的。
一個用例規約（use case specification）應該包含以下內容：
（1）用例的標識與名稱；
（2）用例涉及到的參與者；
（3）用例的簡要說明；
（4）相關的其它用例；
（5）用例執行的前置條件
（6）基本事件流；
（7）備選事件流；
（8）用例執行的後置條件；
（9）其它訊息，如非功能性需求、設計約束、用例審核狀態、編制者、修改記錄等。
用例之間的關係主要包括泛化、包含和擴展三種。
當多個用例擁有相似的屬性或行為時，我們可以將它們的共通點抽象化為父用例，而其它用例作為泛化關係的子用例，子用例繼承父用例中的屬性和行為。用例的泛化關係可以理解為同一業務目的的不同實作路徑。
泛化（Generalization）關係在圖形上使用空心三角形箭頭的實作表示，箭頭由子用例指向父用例。
用例圖泛化關係
上面這個例子中，「支付方式1 」和「支付方式2 」是「支付」的子用例。在父用例「支付」中並不提供具體的支付方式，只提供支付必須的屬性和接口，而在其子用例中實現具體的支付功能。
在系統建模過程中，有些功能在不同業務情境中需要重複使用。這些重複使用的功能可以單獨剝離出來形成一個單獨的用例，而在執行相關功能時，可以把剝離出來的公共功能再包含到主流程中去。用例的包含關係可以描述這種情形，另外，如果一個基本用例的功能太多時，也可以將其拆解成多個小的用例。被包含的用例稱作提供者用例，包含其它用例的用例稱作客戶用例。
在UML中，包含（include）關係使用<<include>>構造型的虛線箭頭表示，箭頭由基本用例（包含用例/客戶用例）指向被包含的用例（提供者用例）。
用例圖包含關係
以下是一個具體的例子，在這個例子中，讀者要預借圖書，他需要執行查詢圖書用例，才能執行預借圖書，所以查詢圖書用例將被包含到預借圖書用例中來，同時，讀者要執行預借圖書時，前提他必須已經登入系統中，系統已經保存了他的登入狀態才能執行預借操作，所以驗證身分用例也將被包含到預借圖書用例中。查詢圖書即是一個讀者要求具有的一個基本功能，也是其它功能的一個必要操作過程。驗證身分不僅在預借圖書時要用到，還要在執行如查詢借閱記錄、繳納罰款時等用到的一個功能，把驗證身份單獨提出來形成一個用例比較合適：
讀者預借圖書包含關係
基本用例提供擴充點，在擴充點中可以加入新的行為，擴充用例提供了一組插入片段，這些片段能插入基本用例的擴充點。
· 基本用例僅提供擴充點，而不必知道擴充用例的任何細節。
· 基本用例即使沒有擴展用例也是完整的，這與包含關係不同。
· 一個用例可以提供多個擴充點，每個擴充點也可出現多次。
· 一般情況下，基本用例的執行不會涉及到擴充用例，只有在特定條件或事件發生時，才會執行擴充用例的功能。
在UML中，擴展關係使用帶有構造型<<extend>>的虛線箭頭表示。箭頭由擴充用例指向基本用例。
用例圖擴展關係
下面這個例子是圖書館借閱系統中，一個用例圖片段：
讀者繳納罰款擴展關係
在這個例子中，繳納罰款是讀者的一個基本用例，也是歸還書籍的擴展用例。 「繳納罰款」作為「歸還圖書」的擴展案例，只有在以下條件時，才會被執行：
（1）讀者圖書有超期或其它原因產生有罰款記錄，且未繳清；
（2）讀者選擇了在歸還圖書後，同時繳清罰款。
以上就是關於UML用例圖的相關內容，上述所有用例圖案例均使用ProcessOn繪製。
免費在線協作思維導圖和流程圖 免費使用 
