大話PM | 產品經理必備利器:UML
產品經理經常與文檔打交道,而如果想輸出高質量的文檔更離不開 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。
根據個人需求酌情擇優,畢竟只有適合自己的才是最好的。
參考資料:
本文由 @?iamxiarui 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖作者提供
主要用狀態圖,最討厭畫時序圖,用例圖、類圖,直接用思維圖框架帶了,差不多就行了,速度很重要 ~~
請問下博主用的是什么軟件畫的呢?
OmniGraffle:MacOS 下的 Visio
始終覺得那些架構、信息結構一類的東西抽象,可能還是經驗不夠吧
個人感覺產品對于類圖應該主要是為了表示結構,至于搜索這種行為用類圖來表示就不合適了,無論是微信、支付寶還是銀行卡(個人感覺應該是銀聯,因為銀行卡和支付渠道不在同一個抽象維度)應該在支付上抽象為支付渠道
類是對象的實例化?貌似反了
嚴格來說,應該是文中開頭所說:“通過類來對對象進行實例化”,換句話說用類創建對象的過程叫做實例化。這里只簡要說明圖中通過類創建的類實例都是對象的實例化,不對“類的概念”做展開說明。
購物系統的用例圖有個用例之間的關系畫錯了,幾種付款方式跟付款之間應該是泛化關系,不是包含
對 后面畫類圖的時候 也發現了這個問題 子類對父類的繼承應該是泛化 考慮到是一個簡單的示例 主要體現一些基本畫法 也就沒有更正 稍后會更正過來 感謝指正
各種uml圖之間的用法有時不太明確怎么破,有時感覺幾副圖最后表達的意思都一樣…
得看具體場景,開發用的類圖比較多,產品的話用例圖和泳道圖用的還是比較多的
得看具體場景 開發用的類圖比較多 產品用例圖和泳道圖很多
謝謝,正在學習這方面的知識,希望能應用到日常的prd文檔
經常使用的UML有用例圖 活動圖 狀態機圖 協作圖。
干貨~