原文鏈接：https://blog.csdn.net/mj_ww/article/details/53020080
目錄
對於用例圖來說我們需要了解的是什麼叫用例圖，構成用例圖的要素，用例圖有哪些重要的元素，各個用例之間的關係。當然最重要的是如何根據需求創建用例圖。具體的創建通過一個簡單的學生管理的例子說明創建的過程和例子。
1 什麼是用例圖
1.1 用例圖的含義
由參與者（Actor）、用例（Use Case）以及它們之間的關係構成的用於描述系統功能的動態視圖稱爲用例圖。要在用例圖上顯示某個用例，可繪製一個橢圓，然後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。
要在用例圖上繪製一個參與者（表示一個系統用戶），可繪製一個人形符號。參與者和用例之間的關係使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關係中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。
在用例建模中，爲了更加清楚的描述用例或者參與者，會使用到註釋。
1.2 用例圖的作用
用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關係，幫助開發人員可視化的瞭解系統的功能。藉助於用例圖，系統用戶、系統分析人員、系統設計人員、領域專家能夠以可視化的方式對問題進行探討，減少了大量交流上的障礙，便於對問題達成共識。
用例圖可視化地表達了系統的需求，具有直觀、規範等優點，克服了純文字性說明的不足。
用例方法是完全從外部來定義系統功能，它把需求和設計完全的分離開來。我們不用關心繫統內部是如何完成各種功能的，系統對於我們來說就是一個黑箱子。
2 用例圖的構成要素
2.1 參與者
參與者（Actor）是指存在於系統外部並直接與系統進行交互的人、系統、子系統或類的外部實體的抽象。
每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。
在用例圖中使用一個人形圖標來表示參與者，參與者的名字寫在人形圖標下面。
2.2 參與者間的的關係
由於參與者實質上也是類，所以它擁有與類相同的關係描述，即參與者與參與者之間主要是泛化關係（或稱爲“繼承”關係）。泛化關係的含義是把某些參與者的共同行爲提取出來表示成通用行爲，並描述成超類。泛化關係表示的是參與者之間的一般/特殊關係，在UML圖中，使用帶空心三角箭頭的實線表示泛化關係。
2.3 系統邊界
在項目開發過程中，邊界是一個非常重要的概念。這裏說的系統邊界是指系統與系統之間的界限。通常我們所說的系統可以認爲是由一系列的相互作用的元素形成的具有特定功能的有機整體。
系統同時又是相對的，一個系統本身又可以是另一個更大系統的組成部分，因此，系統與系統之間需要使用系統邊界進行區分開來。我們把系統邊界以外的同系統相關聯的其他部分，稱之爲系統環境。
3 用例的重要元素
3.1 如何識別用例
任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關聯的用例。所以識別用例的最好方法就是從分析系統參與者開始，在這個過程中往往會發現新的參與者。
可以通過以下問題來尋找用例：
(1)參與者希望系統提供什麼功能？
(2)參與者是否會讀取、創建、修改、刪除、存儲系統的某種信息？如果是的話，參與者又是如何完成這些操作的？
(3)參與者是否會將外部的某些事件通知給系統？
(4)系統中發生的事件是否通知參與者？
(5)是否存在影響系統的外部事件。
3.2 用例的粒度
用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。
如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那麼得到的用例數就會很少。
如果用例數目過多會造成用例模型過大和引入設計困難大大提高。 如果用例數目過少會造成用例的粒度太大，不便於進一步的充分分析。
比如：網站後臺管理系統中的會員信息維護用例，管理員需要進行添加會員信息、修改會員信息、刪除會員信息等操作。
我們還可以根據具體的操作把它抽象成3個用例，它展示的系統需求和單個用例是完全一樣的。
3.3 用例規約
對於每一個用例，我們還需要有詳細的描述信息，以便讓別人對於整個系統有一個更加詳細的瞭解，這些信息包含在用例規約之中。
每一個用例的用例規約都應該包含以下內容：
(1)簡要說明:對用例作用和目的的簡要描述。
(2)事件流:事件流包括基本流和備選流。基本流描述的是用例的基本流程，是指用例“正常”運行時的場景。
(3)用例場景:同一個用例在實際執行的時候會有很多不同的情況發生，稱之爲用例場景，也可以說用例場景就是用例的實例。
(4)特殊需求: 特殊需求指的是一個用例的非功能性需求和設計約束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可擴展性等。例如法律或法規方面的需求、應用程序標準和所構建系統的質量屬性等。
(5)前置條件: 執行用例之前系統必須所處的狀態。例如，前置條件是要求用戶有訪問的權限或是要求某個用例必須已經執行完。
(6)後置條件:用例執行完畢後系統可能處於的一組狀態。例如，要求在某個用例執行完後，必須執行另一個用例。
4 用例之間的關係
4.1 包含
包含關係指用例可以簡單地包含其他用例具有的行爲，並把它所包含的用例行爲作爲自身行爲的一部分。在UML中，包含關係是通過帶箭頭的虛線段加<>字樣來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。
在處理包含關係時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成爲一個新的用例。主要有兩種情況需要用到包含關係：
第一，多個用例用到同一段的行爲，則可以把這段共同的行爲單獨抽 象成爲一個用例，然後讓其他用例來包含這一用例。
第二，某一個用例的功能過多、事件流過於複雜時，我們也可以把某一段事件流抽象成爲一個被包含的用例，以達到簡化描述的目的。
4.2 擴展
在一定條件下，把新的行爲加入到已有的用例中，獲得的新用例叫做擴展用例(Extension)，原有的用例叫做基礎用例(Base)，從擴展用例到基礎用例的關係就是擴展關係。
一個基礎用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。
4.3 泛化
用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關係就是泛化關係。
在用例的泛化關係中，子用例繼承了父用例所有的結構、行爲和關係，子用例是父用例的一種特殊形式。
子用例還可以添加、覆蓋、改變繼承的行爲。在UML中，用例的泛化關係通過一個三角箭頭從子用例指向父用例來表示。
泛化的示例：銀行存款有兩種方式，一種是銀行櫃檯存款，一種是ATM機存款。在這裏，銀行櫃檯存款和ATM機存款都是存款的一種特殊方式，因此“存款”爲父用例，“銀行櫃檯存款”和“ATM機存款”爲子用例。
使用Rose創建用例的步驟說明
1. 需求分析
“學生信息管理系統”部分功能性需求包括以下內容：
（1）系統管理員登錄後可以對班級的基本信息進行增加、刪除、修改、查詢等操作。學校領導登錄後可以對班級基本信息進行查詢操作。
（2）教師登錄後可以對學生的考試成績進行錄入、刪除、修改、查詢等操作。學生登錄後可以對考試成績進行查詢操作。
（3）學生登錄後可以瞭解所有選修課程的具體信息，可以根據自己的需要選擇不同課程。系統管理員登錄後可以增加、修改、查詢、刪除選修課程。
（4）系統管理員可以對賬號進行創建、設置、查看、刪除等操作。
2.識別參與者
對於一個學校來說，最重要的就是教育學生成才，所以我們首先要考慮到的參與者就是學生。
要給學生上課，必然就需要教師。教師負責教育學生、並且在日常管理中可以查詢學生的基本信息、查詢學生的考試成績。
作爲一個學校，除了教師和學生，還有不可或缺的就是校領導。爲了便於校領導掌握學校的基本情況，加強對學校的管理導.
不管什麼系統，基本都會有比較專業的人員來負責管理系統，本系統也不例外。系統管理員除了負責維護系統的日常運行，還要進行錄入學生基本信息、維護選課信息等工作。
3.構建用例模型
系統管理員直接參與的用例爲登錄、找回密碼、查看班級基本信息、刪除班級基本信息、修改班級基本信息和錄入班級基本信息。校領導直接參與用例登錄、找回密碼和查看班級基本信息。當登錄過程中發生忘記密碼的情況，就需要使用找回密碼的功能來找回密碼，而在正常情況下用不到找回密碼這個功能所以用例找回密碼”和用例登錄之間是擴展關係。
教師參與用例錄入成績、修改成績、保存成績、查詢成績、刪除成績和登錄。學生參與用例登錄和查詢成績。因爲修改成績和錄入成績的時候都要保存成績，所以將保存成績抽象出來作爲單獨的一個用例。用例錄入成績、修改成績和用例保存成績之間是包含關係，用例找回密碼和用例登錄之間是擴展關係。
學生作爲參與者直接參與用例查看課程信息、按課程編號查看、按課程名查看、選擇課程、刪除已選課程、登錄和找回密碼。系統管理員參與用例登錄、找回密碼和“維護課程信息”。其中查看課程信息有兩種方式，一種是按照課程名查看，另一種是按照課程編號查看。所以查看課程信息是父用例，而按照課程名查看和按照課程編號查看是子用例，他們之間的關係是泛化關係。用例找回密碼和用例登錄之間是擴展關係。
系統管理員參與用例創建新賬號、設置賬號、設置賬號基本信息、設置賬號權限、查看賬號和刪除賬號。在設置帳號時，主要分爲設置賬號的基本信息和設置賬號的權限，爲了便於修改和維護，將這兩個功能分別抽象爲兩個用例。所以用例設置賬號基本信息、設置賬號權限和用例設置賬號之間是包含關係