如何畫出規(guī)范的UML用例圖

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

1.不會找用例：業(yè)務用例、系統(tǒng)用例又都是啥啊？我該如何把用例寫對啊？

2.兩個用例圖分不清楚：業(yè)務用例圖和系統(tǒng)用例圖感覺好像啊，似乎沒啥區(qū)別??？

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

一、如何識別正確的用例

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

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

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

1.1 業(yè)務用例

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

?

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

1.2 系統(tǒng)用例

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

1.系統(tǒng)

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

2.系統(tǒng)執(zhí)行者

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

系統(tǒng)執(zhí)行者一定是在系統(tǒng)外的，可以是人或者其他系統(tǒng)；

系統(tǒng)執(zhí)行者必須是要和系統(tǒng)有交互的；

系統(tǒng)執(zhí)行者不一定是業(yè)務執(zhí)行者；

3.涉眾

涉眾是與要建設的業(yè)務系統(tǒng)相關的一切人和事，系統(tǒng)執(zhí)行者也是涉眾的一部分。

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

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

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

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

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

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

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

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

?

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

Tips:

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

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

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

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

二、如何區(qū)分業(yè)務用例圖和系統(tǒng)用例圖

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

?

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

?

三、如何用 PlantUML 畫出規(guī)范的用例圖

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

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

3.1 系統(tǒng)

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

@startuml


rectangle "xx 系統(tǒng)" {


}


@enduml

?

3.2 執(zhí)行者

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

@startuml


'系統(tǒng)執(zhí)行者的兩種寫法'
actor Actor1
:Actor2:


'業(yè)務執(zhí)行者的兩種寫法'
actor/ Actor3
:Actor4:/


@enduml

3.3 用例

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

@startuml


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


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

?

3.4 關系

系統(tǒng)用例圖中關系主要有四種，分別是關聯(lián)、包含、擴展、泛化。

3.4.1 關聯(lián)

關聯(lián)是執(zhí)行者和用例之間的一種關系，一般用實線 + 實心箭頭表示：

@startuml


actor Actor
rectangle "xx系統(tǒng)" {
  usecase "系統(tǒng)用例 1" as UC1
}


Actor -> UC1
@enduml

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

?

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

3.4.2 包含

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

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

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

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

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


actor Actor
rectangle "xx系統(tǒng)" {
  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系統(tǒng)" {
  usecase "基本用例" as UC1
  usecase "擴展用例" as UC2
}


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


@enduml

3.4.4 泛化

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

@startuml
left to right direction
actor Actor


rectangle "xx系統(tǒng)" {
  usecase "支付" as UC1
  usecase "微信支付" as UC2
  usecase "支付寶支付" as UC3
}


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


@enduml

?

四、一個案例

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

1.系統(tǒng)：那自然是這個 App

2.系統(tǒng)執(zhí)行者

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

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

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

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

@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- 企業(yè)用戶
Actor --> UC1


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


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


@enduml

整體用例圖如下：

審核編輯：黃飛