如果你在做設計過程中有一些困惑，如：不會找用例、兩個用例圖分不清楚、不知道自己畫的對不對。那么希望本文能幫助厘清上面幾個問題，真正掌握用例圖，在后面的設計中能運用的得心應手。 在做設計的時候你是否有以下困惑？

1.不會找用例：業務用例、系統用例又都是啥啊？我該如何把用例寫對啊？

2.兩個用例圖分不清楚：業務用例圖和系統用例圖感覺好像啊，似乎沒啥區別啊？

3.不知道自己畫的對不對：照貓畫虎畫了個用例圖，但是我也不知道畫的對不對，萬一評審的人也不會呢，就這樣交差吧? 如果你在做設計過程中有以上困惑，那么希望本文能幫助厘清上面幾個問題，真正掌握用例圖，在后面的設計中能運用的得心應手。

一、如何識別正確的用例

首先看用例的概念，百科上定義“用例是軟件工程或系統工程中對系統如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術”。什么意思呢，這里我引用《大象：Thinking in UML》里面的一段話來解釋下這個定義

這個世界的功能性體現在，首先有某人的一個愿望，這個愿望驅使人去做事并獲得一個確定的結果。如果沒有愿望，功能性就無從談起。一個系統就是由各種各樣的愿望組成的，換句話說，各種各樣的人為著各自的目的做著各種各樣的事情共同組成了一個系統。如果我們要描述一個系統的功能性需求，就要找到對這個系統有愿望的人，讓他們來說明他們會在這個系統里做什么事，想要什么結果。如果所有對系統有愿望的人要做的所有事情都找全了，那這個系統的功能性就被確定下來了。

用例的一個最主要的特征是它是相對獨立的。這意味著它不需要與其他用例交互而獨自完成參與者的目的，也就是說用例從“功能”上說是完備的。用例本質體現了系統參與者的愿望，不能完整達到參與者愿望的不能稱為用例。例如取錢是一個有效的用例，填寫取款單卻不是，因為完整的目的是取到錢，沒有人會為了填寫取款單而專門跑一趟銀行的。 用例有兩種，業務用例和系統用例，那么我們如何準確的識別用例呢？接下來我們就對業務用例、系統用例逐一分析。

1.1 業務用例

業務用例的定義是業務執行者希望通過和所研究組織交互獲得的價值。 我們可以看到一個關鍵詞--價值，這個價值不是指你（組織）能提供什么而是指我（執行者）想要什么，這個時候就需要把視角放在組織外部，切換到執行者上，看看他希望從組織獲得什么，而不是把視角放在組織內部，看組織能提供什么。比如說以餐館這個組織為例，其業務執行者主要是顧客，雖然餐館可以提供零錢兌換、球賽播放、充電寶租借等服務，但是顧客來餐館就是為了吃飯的，顧客->就餐就是餐館的業務用例，提供就餐服務就是餐館這個組織最大的價值。

?

試想一個餐館如果不圍繞“提供物美價廉的就餐服務”這一理念去經營，而是飯菜質量做的很差，提供了很多充電寶服務，那么這個餐館的結果可想而知。

1.2 系統用例

說完業務用例我們再來看看系統用例，系統用例的定義是系統能夠為執行者提供的、涉眾可以接受的價值。其中的幾個概念：

1.系統

封裝了自身的數據和行為，能獨立對外提供服務的東西才能稱為系統。需要注意的系統是一個整體，系統可能會有很多子系統。比如銀行轉賬交易時候需要做風控，如果有商家向銀行售賣交易系統，那么風控這個子系統肯定是包含在整個交易系統內的，一起打包賣給銀行的。

2.系統執行者

系統執行者的定義是在所研究系統外，與該系統發生功能性交互的其他系統。這里需要注意幾點：

系統執行者一定是在系統外的，可以是人或者其他系統；

系統執行者必須是要和系統有交互的；

系統執行者不一定是業務執行者；

3.涉眾

涉眾是與要建設的業務系統相關的一切人和事，系統執行者也是涉眾的一部分。

這里還是以餐館為例，假如顧客是通過口頭告訴服務員（不是自己掃碼下單）我要點啥菜，服務員通過下單系統為顧客下單，那么研究這個下單系統可以得出：

1.系統執行者：服務員，雖然顧客作為餐館這個組織的業務執行者，但是與下單系統直接交互的是服務員，所以服務員才是點餐系統的系統執行者；

2.涉眾，這個就很多了，顧客、服務員、餐館老板、廚師等等都是涉眾，因為都是下單系統的利益關系者；

a.顧客擔心自己下單沒成功，等了很久不上菜； b.服務員擔心沒出單導致顧客投訴，自己獎金被扣； c.老板擔心系統故障引起很多顧客投訴，生意受到影響；

d.廚師擔心下單系統分配不合理，所有的菜都分配給自己做；

一般這個下單系統可以登錄、下單，查看下單記錄，這些都是下單系統的一些功能。我們再來回顧下系統用例的概念：系統用例指的是系統能夠為執行者提供的、涉眾可以接受的價值。那我們接下來就從每個涉眾的視角分析一下對這些功能的需要情況。

	登錄	下單	查看下單記錄
服務員	我需要，要不然別人下錯單了怪我頭上咋辦	I need it！	我需要，方便查看顧客菜品上齊了沒
顧客	I don't care！	能不能下單直接影響我能不能吃上飯	我也需要，得打印出來我的菜單，結賬時候好核對
老板	我也需要，可以看看服務員的工作情況	下單系統不能下單我買它來干啥	我需要，方便訂單管理，也方便看看哪個菜客人點的最多
廚師	I don't care！	不能下單誰告訴我該做什么菜	我需要，要不然說我少做了一道菜沒法解釋

所以，從上可以得出下單、查看下單記錄滿足系統用例的概念，系統用例圖如下?

?

可以看到，和業務用例不同的是在研究系統用例時我們需要把視角切換到系統，從系統出發看看能為執行者提供什么樣的、涉眾都可以接受價值。?

Tips:

1.用例的名字一般是動賓結構，也就是“動詞+名詞”，但是不嚴格要求的。比如“成果分析”這個行業術語沒必要硬倒過來改成“分析成果”

2.老老實實去研究業務流程，做好業務建模，盡量從業務序列圖中映射出系統用例，這樣得到的系統用例才是是最真實的。

3.用例是可以有主執行者和輔執行者的：主執行者從執行者指向用例，而輔執行者從用例指向執行者，主執行者發起用例的交互，輔執行者在交互過程中被動參與進來。一般說來，輔執行者是人肉系統的情況比較少，更多時候是另一個非人智能系統。

4.主執行者和輔執行者是相對于用例來說的，“ xx 是xx用例的主/輔執行者” 是正確的，“ xx 是xx系統的主/輔執行者” 說法是錯誤的。

二、如何區分業務用例圖和系統用例圖

相信經過上面的分析，你已經發現了兩個用例圖的異同點，如果沒有，我再貼一下兩個圖（便于對比下單系統就簡化成下單這個一個用例），便于更直觀的對比：

?

沒錯，兩個圖的最大的不同就是有無“/”，業務用例圖在業務執行者和業務用例上是有“/”的，系統用例圖在系統執行者和系統用例圖上沒有“/”，就是這么簡單。所以現在再看到下面這個幾個圖，你是不是可以一眼看出其中的問題了。?

?

三、如何用 PlantUML 畫出規范的用例圖

PlantUML 是一個快速創建 UML 圖形的組件或者可以說是語言，通過簡單和直觀的語言來定義圖形。其在學習成本、效率、團隊協同以及維護成本上都有比較大的優勢，所以推薦使用 PlantUML 來畫圖。

用例圖畫起來其實很簡單，主要就是四個要素，這里以系統用例為例，四個要素分別是系統、執行者、用例、關系。

3.1 系統

系統用一個矩形塊表示，在 UML語法中是rectangle。如下：

@startuml


rectangle "xx 系統" {


}


@enduml

?

3.2 執行者

執行者是用火材人表示，在 UML 語法中是actor，主要有兩種寫法，如下：

@startuml


'系統執行者的兩種寫法'
actor Actor1
:Actor2:


'業務執行者的兩種寫法'
actor/ Actor3
:Actor4:/


@enduml

3.3 用例

用例是用一個橢圓表示。在UML 語法中是usecase ，業務用例和系統用例的兩種寫法如下：

@startuml


usecase/ " 業務用例 1" as UC1
'業務用例的第二種寫法：() + 用例名稱 + /'
(業務用例 2)/ as UC3


usecase "系統用例 1" as UC2
'系統用例的第二種寫法：() + 用例名稱 '
(系統用例 2)
@enduml

?

3.4 關系

系統用例圖中關系主要有四種，分別是關聯、包含、擴展、泛化。

3.4.1 關聯

關聯是執行者和用例之間的一種關系，一般用實線 + 實心箭頭表示：

@startuml


actor Actor
rectangle "xx系統" {
  usecase "系統用例 1" as UC1
}


Actor -> UC1
@enduml

這里有一點需要注意的是，雖然表示關聯關系可以直接用實線如A-B這樣表示，但是在用例圖中我們盡量用實線+箭頭表示，否則如下：?

?

你無法區分 Actor1 和 Actor2 誰是主執行者誰是輔執行者，又或者兩個都是主執行者？加上箭頭后就非常容易區分，如下

3.4.2 包含

包含是用例之間的一種關系，其中一個用例（稱為基本用例）的行為包含了另一個用例（稱為包含用例）的行為，用虛線箭頭 + <>表示，箭頭指向包含用例。

包含關系意味著包含用例是基本用例中不可缺少的一個執行步驟，如果缺少了該包含用例，基本用例就會變得不完整，可類比類圖中對象之間的組合關系。使用包含關系的兩個場景：

當基本用例較復雜時，可以分解出一些包含用例；

當兩個或以上的基本用例存在一些重復行為時，可以提煉出一個包含用例；

@startuml
'加入下面代碼指定方向，使 UML 從左往右更直觀'
left to right direction


actor Actor
rectangle "xx系統" {
  usecase "基本用例" as UC1
  usecase "包含用例 1" as UC2
  usecase "包含用例 2" as UC3
}


Actor --> UC1
UC1 ..> UC2 : <>
UC1 ..> UC3 : <>


@enduml?

上面我用了Actor --> UC1、UC1 ..> UC2，有興趣的可以換成->、.>看看效果

3.4.3 擴展關系

擴展是用例之間的一種關系，其中一個用例（稱為擴展用例）的行為增強了另一個用例（稱為基本用例）的行為，用虛線箭頭 + <>表示，箭頭指向基本用例。

擴展用例是對基本用例的一種補充或強化，即使沒有該擴展用例，對基本用例也不會產生直接影響，基本用例自身仍然是完整的。也就是說擴展用例是基本用例的一種可能的補充，如購買運費險就是對下單這一用例的擴展，買不買運費險都不影響下單。

@startuml
left to right direction


actor Actor
rectangle "xx系統" {
  usecase "基本用例" as UC1
  usecase "擴展用例" as UC2
}


Actor --> UC1
UC1 <.. UC2 : <>


@enduml

3.4.4 泛化

泛化關系也可以稱作繼承關系（類比類圖中的泛化），用一個實線 + 空心箭頭來表示，可以表示執行者間的關系也可以表示用例之間的關系。

@startuml
left to right direction
actor Actor


rectangle "xx系統" {
  usecase "支付" as UC1
  usecase "微信支付" as UC2
  usecase "支付寶支付" as UC3
}


Actor --> UC1
UC1 <|-- UC2 
UC1 <|-- UC3


@enduml

?

四、一個案例

這里我們以某銀行的 App 為例，作為銀行的一個系統我們對其進行分析：

1.系統：那自然是這個 App

2.系統執行者

a.主執行者：一般來銀行辦業務的客戶都是主執行者，包括個人用戶和企業用戶；

b.輔執行者：銀行，用戶在 App 辦理的所有業務都需要銀行來配合執行；

3.系統用例：作為銀行的線上業務，包含轉賬、查詢余額、理財、貸款。

4.關系：這里需要注意的是轉賬過多有可能會超過限額，這個時候會提示超限；在辦貸款業務之前，銀行肯定會對用戶的資產進行評估，這樣才能決定其貸款額度。

@startuml
left to right direction
actor 客戶 as Actor
actor 銀行 as Actor2


rectangle "某銀行App" {
  usecase "轉賬" as UC1
  usecase "查詢余額" as UC2
  usecase "理財" as UC3
  usecase "貸款" as UC4
  usecase "評估資產" as UC5
  usecase "提示限額" as UC6
}


Actor <|-up- 個人用戶
Actor <|-up- 企業用戶
Actor --> UC1


Actor --> UC2
Actor --> UC3
Actor --> UC4
UC1 ----> Actor2
UC2 ----> Actor2
UC3 ----> Actor2
UC4 ----> Actor2


UC4 .left.> UC5 :<>
UC1 <.down. UC6 :<>


@enduml

整體用例圖如下：

審核編輯：黃飛