UML 用例圖詳解

用例圖 (Use Case Diagram) 是用來顯示一組用例、參與者以及它們之間關係的圖。它描述了用戶但願如何使用一個系統。經過用例圖能夠知道誰是系統相關的用戶，他們但願系統提供哪些服務，以及他們須要爲系統提供什麼樣的服務。markdown

用例圖能給咱們帶來什麼？

用來描述要開發的系統的功能需求和系統的使用場景。
促進開發過程當中各個階段工做的進展。
用來驗證與確認系統需求。

用例建模是實現系統需求分析的一個很好的方法，經過它可使得系統分析員和客戶之間可以更好地溝通系統的需求。spa

用例圖的組成

在介紹中咱們說到用例圖是顯示一組用例、參與者之間關係的圖。接下來的內容詳細的闡述了什麼是用例、什麼是參與者以及他們之間有什麼樣的關係。code

參與者 (Actor)

參與者也叫角色，它表示了系統的用戶。這裏須要注意的是：這裏的用戶並不特指人，若是咱們開發的是公共 API 項目，那麼這個時候，API 的調用者就是咱們的用戶。orm

參與者指的不是用戶自己，而是它在系統中所扮演的角色。舉個例子來講，張三是淘寶店的店主，這個時候他參與淘寶的交互時，他既能夠是店主這個角色，也能夠做爲買家在淘寶上購買東西，這個時候張三在系統中扮演了兩個角色，這兩個角色是兩個不一樣的參與者即買家和賣家。對象

參與者的做用是：繼承

創建系統的外部用戶模型
對系統邊界以外的對象進行描述

咱們先來看兩個案例：事件

例：銷售員天天下班前將當日銷售狀況經過郵件發送給銷售經理，由銷售經理將總的銷售記錄進行彙總錄入到系統中。開發

這個時候和系統進行交互的人是銷售經理，因此銷售經理是系統的參與者。it

參與者在咱們代碼中，本質上仍是類，因此在參與者中也存在繼承的關係（分析階段通常用泛化關係來表示繼承）。泛化關係 (Generalization) 表示一個通常性的參與者（父參與者）和另外一個特殊參與者（子參與者）之間的聯繫。參與者之間的泛化關係用帶空心箭頭的實線來表示，箭頭端表示父參與者。io

在上面的圖中，咱們能夠發現，管理員和普通用戶都是用戶的特殊化，因此能夠抽象出一個父參與者來，管理員和普通用戶都擁有用戶的所有特性，同時還具備本身特殊的特性。

用例(Use Case)

需求分析是軟件開發流程中必不可少的一個環節，其主要目的就是創建待開發系統的模型，而用例則是創建這些的最好方法。

用例是對一組動做的描述，系統經過執行這些動做將對用例的參與者產生能夠看到的結果。用來描述參與者能夠感覺到的系統服務或者功能。

在 UML 中，用例一般用一個橢圓形符號來表示：

在電商系統中，「加入購物車」就是一個用例，在社交軟件中，「發送消息給某人」就是一個用例。

使用用例進行系統需求分析的特色：

用例是從系統的使用者角度來描述系統中的信息，即在系統的外部所能看到的系統的功能，而不考慮系統內部對該功能的具體實現
用例描述了一下可見需求，對應一個具體的用戶目標。使用用例能夠用來劃分系統與外部實體的界限。
用例一般由某個參與者來執行。
用例把執行結果返回給參與者。
用例在功能上具備完整性。它從參與者接受輸入，再將產生的結果輸出給參與者。

通常狀況下，咱們若是向其餘人描述一個一個功能的具體信息呢？咱們經過文字來對功能進行講解。用例圖只是簡單的用圖形方式描述系統，關於功能的完整解說仍是須要用文字來表達。因此，對於用例，咱們須要由詳細的說明，這樣才能讓其餘人更加清楚的瞭解這個系統。這個時候咱們就須要編寫用例描述了。

一般不會對用例描述作硬性規定，可是一些複雜的或者是重要的用例仍是要編寫用例描述。用例描述通常包括用例編號、用例說明、前置條件、基本事件流、其餘事件流、異常事件流和後置條件等。

下面是「加入購物車」用例的詳細描述：

元素	描述
用例名稱	加入購物車
用例標識	UC001
簡要說明	將商品添加到用戶購物車中
前置條件	用戶已經登陸
基本事件流	用戶向系統發送加入購物車的請求，系統須要對商品的庫存、用戶購物車數量進行驗證來判斷是否可以加入到購物車中
其它事件流	無
異常事件流	若是商品庫存不足，則告知用戶庫存不足沒法添加；若是用戶購物車已達上限，則告知用戶購物車已滿，須要刪除部分商品後才能添加
後置條件	添加成功後，須要對用戶購物車數量從新進行統計
註釋	無

說完用例，咱們來講說用例之間的關係

用例之間的關係

包含關係

包含關係指的是兩個用例之間，其中一個用例(基本用例)的行爲包含了另一個用例(包含用例)。

在 UML 圖中，包含關係用帶箭頭的虛線表示，而且線上標有<<include>>，箭頭的方向是從基本用例到包含用例。

擴展關係

擴展關係是對基本用例的擴展，基本用例是一個完整的用例，即便沒有子用例參與，也能夠完成一個完整的功能。擴展的基本用例中存在一個擴展點，只有擴展點被激活時，子用例纔會被執行。擴展關係是從擴展用例到基本用例的關係，它說明擴展用例如何插入到基本用例中。

擴展用例的使用場景：

代表用例的某一部分是可選行爲
代表只在特定條件下才執行的分支
代表可能有一組行爲，其中的一個或多個行爲能夠在基本用例中的擴展點處插入。所插入的行爲和順序取決於在執行基本用例時與主角進行的交互。

在 UML 圖中，使用帶箭頭的虛線表示，而且虛線上標有 <<extend>>:

泛化關係

泛化關係指的是通常(父用例)與特殊(子用例)的關係。當多個用例共同擁有一種相似的結構和行爲時，能夠將它們的共性抽象爲父用例，其餘的用例做爲泛化關係中的子用例。

分組關係

在一些用例圖中，用例數量可能不少，這個時候就須要把這些用例組織起來。

用例圖建模及應用

建立用例圖模型主要包含3部份內容：

識別系統中的角色和用例
區分用例之間的前後次序
建立用例圖模型結構

識別系統中的角色和用例

這部分工做一般由系統分析員經過和客戶溝通來完成。

要獲取系統的用例，首先要找出系統的角色。

要獲取系統角色能夠在與客戶溝通時，詢問用戶一些問題來識別角色。能夠參考下列問題：

誰將使用系統的主要功能？
是須要系統的支持以完成平常工做？
誰負責維護、管理系統並保持系統正常運行？
系統須要與哪些外部系統交互？
系統須要處理哪些硬件設備？
誰對系統運行產生的結果比較感興趣？

當咱們獲取到系統角色後，咱們能夠經過角色來列出它的用例。能夠經過回答下列問題來識別用例：

每一個角色執行的操做有什麼？
什麼角色將要建立、存儲、改變、刪除或者讀取系統中的信息？
什麼用例會建立、存儲、改變、刪除或讀取這個信息？
角色須要通知外部系統的忽然變化嘛？
系統須要通知角色正在發生的事情嗎？
什麼用例將支持和維護系統？

區分用例優先次序

某些用例必須在其餘用例完成以前完成，由於它們是相互依賴的。例如在購買商品前，用戶必須先登陸。

構建用例圖模型

將已經肯定並細化的角色和用例放入用例圖。再借助包含、擴展和泛化的關係給出用例之間的結構模型。

在系統需求分析中須要考慮系統用例圖模型須要哪些視圖、每一個視圖包含什麼內容，以及視圖中成員是否需構成包。

小結

用例建模是實現系統需求分析的一個很好的方法，使得系統分析員和用戶之間可以更好地溝通系統的需求。