UML用例圖總結來源於網絡

前言

 

用例圖主要用來描述「用戶、需求、系統功能單元」之間的關係。它展現一個外部用戶可以觀察到的系統功能模型圖。用例圖多用於靜態建模階段（主要是業務建模和需求建模），幫助開發團隊以一種可視化的方式理解系統的功能需求。下面將從各個部分來分析和理解用例圖。

參與者（Actor）

在系統外部與系統直接交互的人或事物；須要注意如下兩點：

1. 參與者是角色而不是具體的人，它表明了參與者在與系統打交道的過程當中所扮演的角色。因此在系統的實際運做中，一個實際用戶可能對應系統的多個參與者。不一樣的用戶也能夠只對應於一個參與者，從而表明同一參與者的不一樣實例。
2. 參與者做爲外部用戶（而不是內部）與系統發生交互做用，是它的主要特徵。

在UML中，參與者使用如圖所示的一個小人表示：

用例（Use Case）

系統外部可見的一個系統功能單元。系統的功能由系統單元所提供，並經過一系列系統單元與一個或多個參與者之間交換的消息所表達。用橢圓表示，橢圓中的文字簡述系統的功能：

子系統（Subsystem）

用來展現系統的一部分功能，這部分功能聯繫緊密。

關係（Relationship）

用例圖中涉及的關係有：

1. 關聯
2. 泛化
3. 包含
4. 擴展

關聯（Association）

表示參與者與用例之間的交互，通訊途徑，任何一方均可發送或接受消息。
箭頭指向：指向消息接收方。

泛化（Inheritance）

在編程中，泛化關係是一種很重要的關係，咱們隨處可見。
泛化關係是通常和特殊關係，就是一般理解的繼承關係，子用例和父用例類似，但表現出更特別的行爲；子用例將繼承父用例的全部結構、行爲和關係。子用例可使用父用例的一段行爲，也能夠重載它。父用例一般是抽象的。
箭頭指向（須要特別注意）：指向父用例。

包含（Include）

包含關係用來把一個較複雜用例所表示功能分解成較小的步驟。包含用例是必須的，若是缺乏包含用例，基用例就不完整；包含用例必須被執行。
箭頭指向：指向分解出來的功能用例。

擴展（Extend）

擴展關係是指用例功能的延伸，至關於爲基礎用例提供一個附加功能。擴展用例是可選的，若是缺乏擴展用例，不會影響到基用例的完整性。
箭頭指向（須要特別注意）：指向基用例

下圖提供一個完整的系統的用例圖，讓你們有一個感官上的全面認識。

總結

用例圖雖然做爲UML中的一部分，給團隊成員提供一種形象的系統表述，可是，用例圖也由它自己的缺陷，用例圖通常在需求分析階段就給出了，有的時候對於系統的需求，並不能很好的表述，對於沒有UML背景的人來講，更是一種痛苦與折磨，可是，話又說回來，做爲軟件開發人員，沒有UML背景是說不過去的；有的時候，咱們須要藉助用例圖對客戶講解系統，而讓客戶去理解用例圖則是很困難的。
雖然，在用例圖中的關係種類不是不少，也不是很複雜，可是UML的表示確實很讓人費解的，別的還好，特別是擴展（Extend）和包含（Include），表示方式都同樣的，僅靠上面的說明來進行區分，在一個複雜的系統中，是很容易看錯的，從而理解出錯，同時，擴展（Extend）中的箭頭指向一直是讓我很費解的，爲何須要讓箭頭指向基用例呢？
鑑於用例圖有的時候並不能清楚地表達功能需求，開發中你們一般用用例描述表來補充某些不易表達的用例，請你們參考下圖：