原文連結:https://blog.csdn.net/mj_ww/article/details/53020080

　　UML,即Unified Model Language,統一建模語言。百度百科對他的定義是：它是一個支援模型化和軟體系統開發的圖形化語言，為軟體開發的所有階段提供模型化和視覺化支援，包括由需求分析到規格，到構造和配置。作為一個軟體工程師，很多技能並不一定說非得具備，但是，一旦我們具備了，很多時候機會總是會多那麼一點點。

　　對於用例圖來說我們需要了解的是什麼叫用例圖，構成用例圖的要素，用例圖有哪些重要的元素，各個用例之間的關係。當然最重要的是如何根據需求建立用例圖。具體的建立通過一個簡單的學生管理的例子說明建立的過程和例子。
　　我的所有例子都是是使用Rose這個軟體來畫的，現在雖然有新的UML模型畫圖軟體，但是我比較喜歡用這個Rose，如果你還沒有裝這個軟體需要先裝一個，或者使用你比較喜歡的UML畫圖軟體。下面我們直接進入正題吧，學習一下用例圖的相關概念和具體的建立過程。

什麼叫用例圖

1. 用例圖的含義 　　

　　由參與者（Actor）、用例（Use Case）以及它們之間的關係構成的用於描述系統功能的動態檢視稱為用例圖。要在用例圖上顯示某個用例，可繪製一個橢圓，然後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。
　　要在用例圖上繪製一個參與者（表示一個系統使用者），可繪製一個人形符號。參與者和用例之間的關係使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關係中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。

　　在用例建模中，為了更加清楚的描述用例或者參與者，會使用到註釋。

2. 用例圖的作用

　　用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關係，幫助開發人員視覺化的瞭解系統的功能。藉助於用例圖，系統使用者、系統分析人員、系統設計人員、領域專家能夠以視覺化的方式對問題進行探討，減少了大量交流上的障礙，便於對問題達成共識。
　　用例圖視覺化地表達了系統的需求，具有直觀、規範等優點，克服了純文字性說明的不足。
　　用例方法是完全從外部來定義系統功能，它把需求和設計完全的分離開來。我們不用關心繫統內部是如何完成各種功能的，系統對於我們來說就是一個黑箱子。

用例圖的構成要素

1. 參與者

　　參與者（Actor）是指存在於系統外部並直接與系統進行互動的人、系統、子系統或類的外部實體的抽象。
每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。
　　在用例圖中使用一個人形圖示來表示參與者，參與者的名字寫在人形圖示下面。

2. 參與者間的的關係

　　由於參與者實質上也是類，所以它擁有與類相同的關係描述，即參與者與參與者之間主要是泛化關係（或稱為“繼承”關係）。
泛化關係的含義是把某些參與者的共同行為提取出來表示成通用行為，並描述成超類。泛化關係表示的是參與者之間的一般/特殊關係，在UML圖中，使用帶空心三角箭頭的實線表示泛化關係。

3. 系統邊界

　　在專案開發過程中，邊界是一個非常重要的概念。這裡說的系統邊界是指系統與系統之間的界限。通常我們所說的系統可以認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。
　　系統同時又是相對的，一個系統本身又可以是另一個更大系統的組成部分，因此，系統與系統之間需要使用系統邊界進行區分開來。我們把系統邊界以外的同系統相關聯的其他部分，稱之為系統環境。

用例的重要元素

1. 如何識別用例

　　任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關聯的用例。所以識別用例的最好方法就是從分析系統參與者開始，在這個過程中往往會發現新的參與者。
　　
可以通過以下問題來尋找用例：
　　 (1)參與者希望系統提供什麼功能？
　　 (2)參與者是否會讀取、建立、修改、刪除、儲存系統的某種資訊？如果是的話，參與者又是如何完成這些操作的？
　　 (3)參與者是否會將外部的某些事件通知給系統？
　　 (4)系統中發生的事件是否通知參與者？
　　 (5)是否存在影響系統的外部事件。
　　

2.用例的粒度

　　用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。
　　如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那麼得到的用例數就會很少。
　　如果用例數目過多會造成用例模型過大和引入設計困難大大提高。 如果用例數目過少會造成用例的粒度太大，不便於進一步的充分分析。

　　比如：網站後臺管理系統中的會員資訊維護用例，管理員需要進行新增會員資訊、修改會員資訊、刪除會員資訊等操作。

　　我們還可以根據具體的操作把它抽象成3個用例，它展示的系統需求和單個用例是完全一樣的。

3.用例規約

　　對於每一個用例，我們還需要有詳細的描述資訊，以便讓別人對於整個系統有一個更加詳細的瞭解，這些資訊包含在用例規約之中。
　　
每一個用例的用例規約都應該包含以下內容：
　　 (1)簡要說明:對用例作用和目的的簡要描述。
　　(2)事件流:事件流包括基本流和備選流。基本流描述的是用例的基本流程，是指用例“正常”執行時的場景。
　　 (3)用例場景:同一個用例在實際執行的時候會有很多不同的情況發生，稱之為用例場景，也可以說用例場景就是用例的例項。
　　 (4)特殊需求: 特殊需求指的是一個用例的非功能性需求和設計約束。特殊需求通常是非功能性需求，包括可靠性、效能、可用性和可擴充套件性等。例如法律或法規方面的需求、應用程式標準和所構建系統的質量屬性等。
　　 (5)前置條件: 執行用例之前系統必須所處的狀態。例如，前置條件是要求使用者有訪問的許可權或是要求某個用例必須已經執行完。
　　 (6)後置條件:用例執行完畢後系統可能處於的一組狀態。例如，要求在某個用例執行完後，必須執行另一個用例。

用例之間的關係

1. 包含

　　包含關係指用例可以簡單地包含其他用例具有的行為，並把它所包含的用例行為作為自身行為的一部分。在UML中，包含關係是通過帶箭頭的虛線段加<>字樣來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。

　　在處理包含關係時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為一個新的用例。主要有兩種情況需要用到包含關係：
　　第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽 象成為一個用例，然後讓其他用例來包含這一用例。
　　第二，某一個用例的功能過多、事件流過於複雜時，我們也可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。
 

2. 擴充套件

　　在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴充套件用例(Extension)，原有的用例叫做基礎用例(Base)，從擴充套件用例到基礎用例的關係就是擴充套件關係。
　　一個基礎用例可以擁有一個或者多個擴充套件用例，這些擴充套件用例可以一起使用。

3.泛化

　　用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關係就是泛化關係。
　　在用例的泛化關係中，子用例繼承了父用例所有的結構、行為和關係，子用例是父用例的一種特殊形式。
　　子用例還可以新增、覆蓋、改變繼承的行為。在UML中，用例的泛化關係通過一個三角箭頭從子用例指向父用例來表示。

　　泛化的示例：銀行存款有兩種方式，一種是銀行櫃檯存款，一種是ATM機存款。在這裡，銀行櫃檯存款和ATM機存款都是存款的一種特殊方式，因此“存款”為父用例，“銀行櫃檯存款”和“ATM機存款”為子用例。

使用Rose建立用例的步驟說明

1. 需求分析

學生資訊管理系統”部分功能性需求包括以下內容：
　　 （1）系統管理員登入後可以對班級的基本資訊進行增加、刪除、修改、查詢等操作。學校領導登入後可以對班級基本資訊進行查詢操作。
　　 （2）教師登入後可以對學生的考試成績進行錄入、刪除、修改、查詢等操作。學生登入後可以對考試成績進行查詢操作。
　　 （3）學生登入後可以瞭解所有選修課程的具體資訊，可以根據自己的需要選擇不同課程。系統管理員登入後可以增加、修改、查詢、刪除選修課程。
　　 （4）系統管理員可以對賬號進行建立、設定、檢視、刪除等操作。
　　

2.識別參與者

　　對於一個學校來說，最重要的就是教育學生成才，所以我們首先要考慮到的參與者就是學生。
　　要給學生上課，必然就需要教師。教師負責教育學生、並且在日常管理中可以查詢學生的基本資訊、查詢學生的考試成績。
　　作為一個學校，除了教師和學生，還有不可或缺的就是校領導。為了便於校領導掌握學校的基本情況，加強對學校的管理導.
　　不管什麼系統，基本都會有比較專業的人員來負責管理系統，本系統也不例外。系統管理員除了負責維護系統的日常執行，還要進行錄入學生基本資訊、維護選課資訊等工作。
　　

3.構建用例模型

　　系統管理員直接參與的用例為登入、找回密碼、檢視班級基本資訊、刪除班級基本資訊、修改班級基本資訊和錄入班級基本資訊。校領導直接參與用例登入、找回密碼和檢視班級基本資訊。當登入過程中發生忘記密碼的情況，就需要使用找回密碼的功能來找回密碼，而在正常情況下用不到找回密碼這個功能所以用例找回密碼”和用例登入之間是擴充套件關係。

　　教師參與用例錄入成績、修改成績、儲存成績、查詢成績、刪除成績和登入。學生參與用例登入和查詢成績。因為修改成績和錄入成績的時候都要儲存成績，所以將儲存成績抽象出來作為單獨的一個用例。用例錄入成績、修改成績和用例儲存成績之間是包含關係，用例找回密碼和用例登入之間是擴充套件關係。

　　學生作為參與者直接參與用例檢視課程資訊、按課程編號檢視、按課程名檢視、選擇課程、刪除已選課程、登入和找回密碼。系統管理員參與用例登入、找回密碼和“維護課程資訊”。其中檢視課程資訊有兩種方式，一種是按照課程名檢視，另一種是按照課程編號檢視。所以檢視課程資訊是父用例，而按照課程名檢視和按照課程編號檢視是子用例，他們之間的關係是泛化關係。用例找回密碼和用例登入之間是擴充套件關係。

　　系統管理員參與用例建立新賬號、設定賬號、設定賬號基本資訊、設定賬號許可權、檢視賬號和刪除賬號。在設定帳號時，主要分為設定賬號的基本資訊和設定賬號的許可權，為了便於修改和維護，將這兩個功能分別抽象為兩個用例。所以用例設定賬號基本資訊、設定賬號許可權和用例設定賬號之間是包含關係