產品經理經常與文檔打交道，而如果想輸出高質量的文檔更離不開 UML 的幫助。本文將通過具體的需求實例來介紹產品經理必須掌握的幾種 UML 圖、繪制方式以及各自的使用場景。

對于 UML 的定義及其語法在網絡上已經有了詳細的教程，本文不做詳細的展開說明，這里用一句話來定義：

UML（統一建模語言）是一種在軟件設計時提供給分析師、設計師和工程師之間的通用語言。

即通過面向對象的方式構建一個統一并通用的模型來解決問題，那么話說回來 UML 所構建的模型到底包括哪些內容呢？

我們知道，社會中各個領域都會存在或多或少的需求問題，在需求整理和分析時，可以將具有共性的需求抽象成一個基本模型。模型由其相關的對象組成，不同的對象具有不同的特征和操作。一般通過類來對對象進行實例化，其中對象的特征決定了對象的狀態，而對象之間則通過消息傳遞來進行信息交流。

這樣說可能有點過于抽象，舉一個很簡單的例子。

在某電商平臺上，用戶A需要購買電子商品、用戶B需要購買生活用品、用戶C需要購買生鮮食品...等等，這類需求就完全可以抽象為一個購物模型。該模型中包含的兩類對象分別為用戶和商家。其中用戶具有身份信息、購物需求等屬性，而商家則具有店鋪性質、商品價格等屬性。同時用戶可以進行加入購物車、下單等操作，商家則可以進行發布商品、發貨等操作。如果用戶已經購買的商品，那么他的狀態會變成無購買需求。在購物的整個過程中，用戶和商家之間通過平臺進行信息交流。

對于產品經理，熟練掌握 UML 的作用在于：

• 梳理產品需求及其業務流程
• 梳理產品實現價值及其運用場景
• 準確向設計及開發傳達產品需求

也就是說，UML 給產品經理們提供了一套既能分析問題又能準確交流的圖形化語言，所以說它是產品經理必備的利器之一。

下面本文將從產品經理工作及產品實現流程角度并結合具體案例，分別介紹幾種產品經理必備的 UML 圖。

一、用例圖

1.1 定義

用例圖是產品經理在產品需求分析中最常用的工具圖，在很多高質量的產品需求說明（PRD）中不難發現用例圖的蹤影。作為經常寫 PRD 的產品經理都知道用例是一種描述產品需求的方法，而產品需求的根本來源還是來自用戶。想要快速理解用例圖的含義只需要記住以下幾點：

• Where：需求在哪里產生，即需求產生的領域
• Who：誰是相關的用戶，即從用戶角度出發
• What：產品/系統是什么
• How：如何使用這個產品/系統
• No Why：用戶不關心產品/系統為什么可以實現

舉個例子來說，小明有網購的需求，那么從小明的角度來說，他只要知道某個電商網站滿足他的需求，并且知道如何使用即可，并不關心網站如何開發實現。

用一句話總結來說：

用例圖強調了從用戶自身角度解決其需求的產品/系統是什么以及如何使用，不關心它的具體實現。

而作為產品經理，使用用例圖最大的三個優點在于：

• 需求分析：根據不同的用例分析，產生不同的需求
• 指導測試：在產品/系統測試時，可以根據用例生成測試用例
• 便于溝通：產品經理與設計、開發以及客戶之間可以很容易的通過用例溝通需求

1.2 畫法

在學會如何畫用例圖之前，必須了解一個完整的用例圖具體包含哪些元素：

元素含義圖示備注

角色	參與使用系統/產品的用戶	①	一般是使用系統/產品的用戶
用例	用戶直接使用的功能	②	可以理解為用戶的某一個需求
子系統	由若干個聯系緊密的用例組成	③	若無則可以省略
關系	用例圖各部分之間的聯系	見下表	具體的關系類型見下表
注釋	對用例或關系進行說明	④	若無則可以省略
項目	用例對應的項目說明文檔鏈接	⑤	很少使用

其中關系分為四種：

關系含義圖示備注

關聯	角色與用例之間的關系	⑥	表示信息的傳遞
泛化	角色與角色、用例與用例之間的繼承關系	⑦	由子指向父
包含	將復雜用例分解成小功能	⑧	由復雜指向分解
擴展	為基礎用例增加附加功能	⑨	由附加指向基礎

1.3 案例

現在我們結合上述畫法，畫一個完整的電商平臺案例的用例圖。在畫圖之前先分析一下需求（個別需求為了迎合上述畫法而刻意說明，真實場景可能略有差異）：

• 購物網站一般有兩種用戶：注冊用戶、非注冊用戶
• 用戶整個購物系統可以分為四個過程：搜索、添加購物車、下單、付款
• 搜索又可以按價格、品牌等條件進行擴展篩選
• 付款可以通過支付寶、微信或銀行卡等方式

從用例圖中可以非常清晰的看到：

• 注冊用戶和非注冊用戶都屬于用戶的泛化
• 購物的四個過程組成的系統是一個電商網站的子系統
• 按條件進行搜索，這是對搜索功能的擴展，而不同的條件是篩選搜索的泛化
• 付款包含了支付寶、微信、銀行卡三種方式

上圖清晰并簡潔的描述了用戶、需求和系統主要功能之間的關系，這便是用例圖最大的優點。

二、順序圖

2.1 定義

在用例圖中，我們只關心用戶如何使用系統的各個功能（用例），但并不關心功能（用例）的具體實現。而順序圖通過引入時間的概念，展示了用例中各個對象的行為順序以及對象之間的消息交互過程，所以順序圖也叫做時序圖。

舉個（不嚴謹的）例子，在小明網購的用例中，參與的對象有小明自己、網購平臺和支付平臺。那么順序圖則可以展示從網購開始到結束這段時間內三者之間的消息傳遞過程。

同樣用一句話來定義：

順序圖是一種面向對象的動態圖形，顯示用例中參與交互的所有對象之間消息傳遞的時間順序。

而作為產品經理，順序圖能更加清晰的梳理業務關系及流程，保證產品需求的準確性、可實現性。

2.2 畫法

從定義中不難發現，順序圖是以對象和時間為維度的二維圖形，圖形中的對象是按照時間順序排列。在了解其畫法之前，先來看看順序圖中重要的元素（高級元素暫不介紹）：

元素含義圖示備注

角色	用戶或系統或子系統	①	并不是用例圖中的用戶，注意區分
對象	參與交互的所有對象	②	命名方式：類名:對象名、:對象名、類名（匿名對象）
生命線	由對象向下延伸的一條虛線，表示其存在時間	③	生命線上有兩種狀態：休眠和激活，生命線的長度為交互對象的全部生命周期
激活期	一段矩形表示對象的活躍時間	④	也被稱為控制焦點
消息	對象之間的通信方式	見下表	見下表

其中消息分為四種：

消息含義圖示

同步消息	發送者通過消息把信號傳遞給接收者并停止活動，等待接受者放棄、返回或控制。	⑤
異步消息	發送者通過消息把信號傳遞給接收者，并繼續活動，不等待接受者返回或控制。	⑥
返回消息	發送者發送消息后的反饋	⑦
自關聯消息	對象給自身發送消息，一般為相同對象中方法之間的調用	⑧

特別注意：

• 順序圖必須是兩個或兩個以上對象間進行交互
• 順序圖的閱讀是從上到下、從左到右進行
• 消息的傳遞代表的是責任分配，不代表數據傳遞

2.3 案例

結合上述畫法，繼續來看一個具體案例。該案例為用戶在購物平臺上從挑選商品到下單最后成功支付的過程，先來分析一下需求（個別需求為了迎合上述畫法而刻意說明，真實場景可能略有差異）：

• 用戶登錄購物網站，并進行搜索并確認商品，最后進行下單操作
• 創建訂單后進入第三方支付平臺進行支付操作
• 支付結果會反饋給平臺
• 購物結果會反饋給用戶

從上圖可以清晰的看到隨著時間變化，用戶與用例中其他對象的消息交互順序，這也為產品經理與開發之間提供了更加簡潔有效的溝通方式。

三、活動圖

3.1 定義

不知道大家有沒有了解或使用過泳道圖，泳道圖其實就是活動圖的一種，只不過在泳道圖中，各個活動會根據其對應的對象或系統來分隔。那么什么是活動圖呢？

活動圖與順序圖很相似，也是一種描述用例的動態圖形。與順序圖不同的是，活動圖強調了用例中各項活動之間的約束關系及其控制流程，說白了活動圖用于展示系統中一個功能（用例）的操作步驟。

用一句話來定義：

活動圖展示了用例的具體業務與工作流程，以及各項業務之間的約束關系。

作為產品經理，熟練掌握活動圖有以下幾個好處：

• 分析與梳理業務流程
• 深刻理解系統功能
• 挖掘潛在的業務需求

3.2 畫法

帶泳道的活動圖是產品經理必備的技能之一，在了解其畫法之前，先來了解活動圖中重要的元素：

元素含義圖示備注

起點與終點	表示活動的起始與結束	①	起點只有一個，終點可有多個
活動狀態	表示活動中的某個節點	②	可以是文字、表達式或方法
轉換	表示活動與活動之間的轉移	③	沒有觸發條件
判斷與條件	根據不同條件有不同的活動分支	④	類似流程圖中的判斷
分叉與合并	表示兩個或以上并發活動的開始與結束	⑤	判斷并不是并發，注意區別

注意：

• 活動圖很像流程圖，但不等同于流程圖
• 活動圖強調對象的活動，順序圖強調對象及其生命周期
• 泳道并不是必須的元素

3.3 案例

由于活動圖與順序圖很相似，所以我們可以將順序圖的案例改成一個帶泳道的二維活動圖，其中以活動作為縱軸，以對象/系統作為橫軸。先來分析一下需求（個別需求為了迎合上述畫法而刻意說明，真實場景可能略有差異）：

• 用戶登錄有成功和失敗判斷
• 下單直接購買和結算購物車兩種方式
• 不管用哪種下單方式，最后都會進入支付流程
• 支付有成功和失敗判斷

注：用戶應該參與全過程，這里為了說明二維泳道圖的畫法，刻意去除了購物與支付流程的參與。

從圖中可以清晰的看到用戶從登錄到購物結束的整個活動過程，并能看到每個活動所對應的對象，這在業務流程梳理環節能給產品經理們提供很大的幫助。

四、類圖

4.1 定義

與順序圖、活動圖這兩種動態圖形不同的是，類圖顯示的是系統/產品中的靜態關系及關系。在介紹什么是類圖之前提個問題，還記得本文開頭對 UML 框架的說明中對類的定義嗎？如果記得的話，你會知道：通過類創建的類實例是對象的實例化。

通過前三種圖形的學習，我們對對象這個概念已經很熟悉了，你可以簡單看成是系統/產品的參與者（可以作為使用者參與，也可以作為子系統參與）。在對象實例化成類后，參與者的特征及操作也被相應的實例化成屬性和方法。

那么有沒有一種圖形可以描述用例中不同的類的數據和方法之間的關系呢？沒錯，那就是類圖。這里給出一句話定義：

類圖是用于描述系統/產品結構化設計的靜態圖形，顯示了類、類的方法、類的接口以及它們之間靜態結構和關系。

作為產品經理，運用類圖可以理清業務概念以及它們的關系，能更加深入地剖析系統/產品業務。

4.2 畫法

從定義中不難發現，類圖需要表現各個類之間的關系。在了解其畫法之前，先來看看類圖中重要的元素：

元素含義圖示備注說明

類	對象的實例化	①	類中有其屬性和方法
接口	只可以被實現，不可以實例化	②	其結構與類相似
泛化	子類與父類之間的繼承關系	③	子類擁有父類的所有屬性和方法
實現	類與接口之間的繼承關系	④	類擁有接口的所有屬性和方法
聚合	整體與部分的關系，兩者可以分開	⑤	另外一種組合關系，兩者不可以分開，這里省略說明
關聯	類與類之間的聯系	⑥	雙向關聯有兩個箭頭或沒有箭頭，單向關聯有一個箭頭
依賴	一個類依賴于另一個類	⑦	此關系經常體現在某個類的方法使用另一個類的對象作為參數

其中多樣性示例如下：

多樣性示例含義

n..m	有n到m個實例，n可以是0
0..* 或 *	沒有實例個數的限制，可以沒有
1	只有一個實例
1..*	最少一個實例

注意：

• 類的操作是針對類自身，并不是操作其他類
• 由于類圖中關系復雜，一定要注意規范
• 一個復雜的實例可以被分為多個類

4.3 案例

結合上述畫法，繼續來看一個具體案例，仍然是用戶網購用例，先來分析一下需求（個別需求為了迎合上述畫法而刻意說明，真實場景可能略有差異）：

• 用戶必須使用電腦/手機才能進行網購，也就是用戶依賴于電腦/手機
• 搜索可以按照關鍵字/價格/品牌等進行搜索，那么搜索可以封裝成接口
• 在整個訂單中包含了訂單詳情，發貨狀態等部分
• 可以通過支付寶/微信等方式進行支付，相當于繼承了支付的所有功能

從圖中可以清晰的看到各個被實例化之后的對象（也就是類）之間的相互關系，既能幫助產品經理更深刻的認識整個用例系統，也能便于其與開發人員之間的溝通。

五、總結

好了，已經將 UML 中四種產品經理最常用且最有用的四種圖介紹完了，現在來總結一下各圖作用以及它們的使用場景：

圖形作用使用場景

用例圖	從用戶角度介紹整個系統/產品是什么	分析用戶需求
順序圖	顯示整個用例中各個對象的生命周期	分析業務流程中對象的交互時間順序
活動圖	顯示整個用例中各對象與各活動的業務流程	分析某個用例具體的工作流
類圖	顯示系統/產品的靜態結構及關系	分析用例具體的實例及其方法、接口

產品經理可以根據根據實際情況選取最佳的圖形，那么作為產品經理該如何選取畫 UML 的工具？

使用畫圖工具的意義在于提升效率，而計算效率時一定要除去學習工具的時間成本，有很多非常專業的軟件學習起來比較吃力，極不推薦。又由于產品經理遇到的圖形非常多，如果每種圖形都使用一種工具的話，不僅切換麻煩而且兼容性、一致性都很差。在這里只簡單推薦幾款：

• 頻繁使用、專業使用 UML ：推薦 StarUML
• 作為輔助工具使用：Win 端 Visio，Mac 端 OmniGraffle
• 在線協作：ProcessOn

根據個人需求酌情擇優，畢竟只有適合自己的才是最好的。

總結

以上是生活随笔為你收集整理的大话PM | 产品经理必备利器——UML的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。