大話PM | 產品經理必備利器:UML

15 評論 42748 瀏覽 443 收藏 18 分鐘

產品經理經常與文檔打交道,而如果想輸出高質量的文檔更離不開 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 畫法

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

其中多樣性示例如下:

注意:

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

4.3 案例

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

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

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

五、總結

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

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

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

在這里只簡單推薦幾款:

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

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

參考資料:

UML 實踐詳細經典教程

UML 基礎教程

 

本文由 @?iamxiarui 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖作者提供

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 主要用狀態圖,最討厭畫時序圖,用例圖、類圖,直接用思維圖框架帶了,差不多就行了,速度很重要 ~~

    來自江蘇 回復
  2. 請問下博主用的是什么軟件畫的呢?

    來自四川 回復
    1. OmniGraffle:MacOS 下的 Visio

      來自安徽 回復
  3. 始終覺得那些架構、信息結構一類的東西抽象,可能還是經驗不夠吧

    來自上海 回復
  4. 個人感覺產品對于類圖應該主要是為了表示結構,至于搜索這種行為用類圖來表示就不合適了,無論是微信、支付寶還是銀行卡(個人感覺應該是銀聯,因為銀行卡和支付渠道不在同一個抽象維度)應該在支付上抽象為支付渠道

    來自上海 回復
  5. 類是對象的實例化?貌似反了

    回復
    1. 嚴格來說,應該是文中開頭所說:“通過類來對對象進行實例化”,換句話說用類創建對象的過程叫做實例化。這里只簡要說明圖中通過類創建的類實例都是對象的實例化,不對“類的概念”做展開說明。

      來自江蘇 回復
  6. 購物系統的用例圖有個用例之間的關系畫錯了,幾種付款方式跟付款之間應該是泛化關系,不是包含

    來自四川 回復
    1. 對 后面畫類圖的時候 也發現了這個問題 子類對父類的繼承應該是泛化 考慮到是一個簡單的示例 主要體現一些基本畫法 也就沒有更正 稍后會更正過來 感謝指正

      來自江蘇 回復
  7. 各種uml圖之間的用法有時不太明確怎么破,有時感覺幾副圖最后表達的意思都一樣…

    來自廣東 回復
    1. 得看具體場景,開發用的類圖比較多,產品的話用例圖和泳道圖用的還是比較多的

      來自江蘇 回復
    2. 得看具體場景 開發用的類圖比較多 產品用例圖和泳道圖很多

      回復
    3. 謝謝,正在學習這方面的知識,希望能應用到日常的prd文檔

      來自廣東 回復
  8. 經常使用的UML有用例圖 活動圖 狀態機圖 協作圖。

    回復
  9. 干貨~

    回復