本文由作者?冰冰醬?發布于社區

第一次接觸UML（Unified Modeling Language統一建模語言）是在2年前，當時正在學項目管理。當書中講到系統設計階段時，作者引入了UML的相關內容，但是2年過去了，筆者對UML的印象也就只停留在概念和樣式上，并沒有進行實操理解。

統一建模語言(Unified Modeling Language，UML)是一種為面向對象系統的產品進行說明、可視化和編制文檔的一種標準語言，是非專利的第三代建模和規約語言。UML是面向對象設計的建模工具，獨立于任何具體程序設計語言。

在這2年期間，在筆者PRD中出現頻率最多的就是流程圖（+泳道）以及狀態機圖。對這些圖的使用和理解都是憑直覺和經驗，并沒有過多去深挖他們的區別和原理，也沒有想過是否還有其他能夠更好表述自己思想的圖。

巧合的是，在最近正在上的產品訓練營課中，再次聽到主講老師講到了他使用UML來向工程師描述需求的案例，同時課堂中的一些引導和實操也讓我對「系統了解和學習UML」產生了好奇心。

于是，在經過學習后筆者整理輸出了下面4個產品經理對UML最關注的4個問題：

• 產品經理是否有必要學習UML？

• 如何學習UML？

• 如何選擇哪種圖來表達？

• 如何把控畫圖的粒度？

話不多說，下面將就上述4個問題進行一一解答。

01

產品經理是否有必要學習UML？

答案是肯定的，但是沒有必要全學。

UML，表面上是一種以圖來展示的語言，但其本質是一種看待事物的思想和角度。通過UML，我們能夠擁有一個抓手，快速去挖掘到事物背后的屬性、特征和行為。

舉個例子，當你要向公司請假時，需要先向leader溝通審批；leader同意后，再將請假條拿給HR存檔；財務則要在核對上班和請假天數后計算出你的當月最終工資。

這件事涉及到了時間、請假、4個崗位部門的人、請假條、薪資等多個角度的內容，其中有人、有物、有事，怎樣才能有一個抓手讓我們快速去捋清楚這件事的全貌和特征呢？

我們最慣用的就是流程圖，而流程圖就正和UML中的活動圖不謀而合，通過時間的先后順序去捋清楚事件（活動）的時間線及邏輯，這是我們最常慣用的一種角度；

但是，在這種角度下，如果我想快速了解請假這整件事的當前狀態和狀態之間的變換方式時，就需要依賴UML中的狀態機圖，這樣我們就能快速了解做哪些事可以發起請假、哪些事會被leader拒絕等。

由UML中的活動圖和狀態機圖舉例來看，UML能夠賦予我們看待事物的不同角度，幫助我們快速找到問題和事物的本質。看到這里，是不是就和我們進行需求分析的目標有共同之處了？

因此，個人是比較推薦產品經理去學習一下UML的，我們不僅可以用UML對事物的本質進行更多視角的解讀，也可以借用它在我們和工程師之間搭建一座溝通的橋梁，更好地向工程師表達和闡述我們的產品和思想。

02

如何學習UML？

UML總共有十多種圖，包含類圖、活動圖、狀態機圖、順序圖、用例圖、部署圖、構建圖、包圖、時序圖、交互概覽圖、組合結構圖。

我們是不是要全部掌握呢？

當然不是！作為一般的業務型產品經理，只需要掌握類圖、活動圖、狀態機圖、順序圖和用例圖即可。這5種圖能夠幫助我們更好地進行問題解構和需求分析，也是沒有技術背景的產品經理很好掌握的5種圖。

一般我們會把UML圖分為結構型圖和行為型圖2種。結構型圖描述的是事物及事物之間的結構，這個結構在某段時間內應該是穩定的、靜態的；而行為圖則描述的是事物的行為，是動態的。

在這5種圖中，類圖是其中唯一的一種靜態結構型圖，其余4種都是行為型圖。下面我們逐一來和大家講解一下這5種圖：

2.1 ?類圖?class diagram

在這5種圖中，類圖可謂作是其他圖的基礎。因為每個系統都涉及到了大量的人、事、物，這些抽象出來的人事物或者概念就是我們所說的類。而任何UML圖都需要建立在有概念和類的基礎上才能展開結構和行為的描述。

其實在了解類圖時，我不自覺聯想到了之前學習數據庫時的E-R圖（Entity-Relationship實體-關系圖），這里類和實體的概念其實是有一些相似之處的。類圖也是一種幫助我們快速提煉出業務概念并識別出其屬性和關系的工具。

類的屬性我們這里不過多展開，下面重點來了解下類之間的關系。常見的類與類之間的關系有：包含、繼承、依賴，其中包含又分為聚合aggregation和組合composition。

包含

類的包含關系分為聚合aggregation和組合composition2種，從中文上看起來有些不直觀，我們直接用圖說話。

下圖為聚合關系，其中A只能屬于B一個類，那么我們稱A和B是聚合（強包含）關系。例如A員工只能屬于某一個部門。

（聚合關系）

而這張圖中A既可以屬于B，也可以屬于C，二者不是強包含關系，則他們為組合（弱包含）關系。例如A員工既在B部門工作，又兼任C部門的部分工作。

（組合關系）

繼承

繼承關系指A繼承了B的屬性，但同時也有自己特有的特點。例如，老師和學生都是「人」，但是老師和學生各自有各自的特性，那么他們就和「人」之間是一種繼承關系。

繼承關系有助于我們抽絲剝繭地觀測到事物之間的本質，是一種進行業務提煉的重要手段。

依賴

依賴關系指A需要B協助才能完成某事，但并不是必須和賴以生存的關系。就像我們開會依賴于使用投影儀一樣，但沒有投影儀我們也照樣完成會議，只是可能沒那么方便。

下面，我們用一個例子來完整表示一下類圖。以大家閱讀這篇文章為例，這次閱讀事件所涉及到的類有：讀者、作者、文章、微信公眾平臺。

• 作者將文章發表在微信公眾平臺

• 讀者前往微信公眾平臺閱讀文章

• 作者可以發布0到多篇文章，但一篇文章僅屬于1個作者

• 讀者也可以閱讀0到多篇文章，1篇文章也可以被0到多個讀者閱讀

2.2 活動圖 activity diagram

活動圖應該是這5種圖中最不需要多廢口舌的，因為它和我們常見的流程圖很像，就是按照時間順序將活動的邏輯整理出來。

下圖就是一個簡單的審批活動圖，通過該圖我們能清晰地了解一個完整的審批流程和邏輯。

看到這里，自然有人會問，這些實心圓圈、圓角矩形等的具體UML繪圖語法必須要全部掌握嗎？按下圖這樣「原始」的畫法去畫有沒有問題？

其實，在日常的工作中，基本沒有工程師會太過于糾結你的繪圖語法正確與否。因此，形式和語法不用太過學院派，只要能夠向讀者清晰表達和傳遞意思即可。

2.3 狀態機圖?state machine diagram

活動圖是將流程分解為一個個的活動，通過活動的先后順序來展示流程；而狀態機圖則是圍繞一個事物的狀態為中心來講述流程。

還是以審批為例，這次我們圍繞審批單為中心來描述流程。假設審批單有待審批、已撤銷、審批通過和審批拒絕這4種狀態，那么我們繪制的狀態機圖如下：

通過這個審批單的狀態機圖，我們能夠清晰地看出審批單的狀態以及影響其狀態的原因和活動。在一定程度上，它幫助我們減輕了設計審批單的工作量，也幫助工程師對審批流程有更好的理解。

2.4 順序圖?sequence diagram

順序圖，有時候也會被混稱為時序圖，中文名字大家可以不用糾結，重點記住sequence這個單詞就好。

在前述的活動圖中，雖然流程較為清晰，但我們很難清晰地定義角色的具體職責邊界和通信交互，而順序圖則幫助我們補充到了這一點。

下面，我們嘗試一下從順序圖的角度來描述審批流程：

從上圖中能夠很明顯的看出銷售負責什么、系統負責什么、而管理員又負責什么；同時也能清晰看出這3個角色各自的輸入輸出。由此可見，順序圖能夠幫助我們逐層撥開一個復雜業務的內部運作。

2.5 用例圖 use case diagram

對于產品經理而言，用例圖應該也是相對比較容易掌握的一種圖。

用例圖是以操作者的角度出發，去看這個產品能夠帶給他哪些價值、支持他去操作和查看哪些東西。繼續沿用審批舉例：

如上圖所示，我們能夠清晰地看出銷售能夠發起審批、撤銷審批和編輯審批，管理員能夠查看和執行審批。換言之，用例圖能夠幫助業務方、產品和工程師以最直觀的角度認識到產品能給客戶帶來什么價值，產品在幫助客戶做什么事。

用例圖關注的是系統的外在表現、系統與人的交互、系統與其他系統的交互。用例圖沒有太多的技術用語和實現細節，在需求初期對團隊和客戶都是一種非常好的溝通工具。

03

如何選擇哪種圖來表達？

UML有這么多種圖，如何去快速選擇最適合自己當前需要的圖呢？

筆者的建議是按照「類圖-用例圖-狀態機圖/順序圖/活動圖」這樣的順序去使用。

在需求前期，我們可以先使用類圖來識別類、類的屬性和關系。就像讀一段英語句子時，老師告訴我們要快速抓住句子的主謂賓結構，從而更快地理解句子意思。類圖也是一樣，在我們兩眼一抹黑的時候，能夠先讓我們了解到這件事中牽扯到的所有人事物，之后我們才能根據這些「素材」去展開后續的分析。

接下來，我們可以通過用例圖去和客戶、工程師溝通產品的價值和能做的事，以一個粗粒度的角度框定產品范圍，看當前的范圍是否能夠滿足客戶需求，幫助我們確立能夠開發出有價值有意義的產品。

同時借助用例圖，產品也能夠向研發積極傳遞當前所做產品的價值，避免工程師因功能價值理解不足而產生開發受阻的問題。

最后，我們就要在狀態機圖、順序圖、活動圖中去做抉擇來描述具體流程了。這3種圖各自有各自的優缺點，下面給出一些選擇上的參考建議：

順序圖的特點

• 強調角色之間的交互，信息傳遞很明確

• 強調按時間順序分別發生了什么事情

• 不太適合表達復雜的特殊流程（循環分支、條件分支、可選分支）

活動圖的特點

• 強調每個角色做了什么事情，這些事情的先后關系

• 適合表達各種特殊流程，如分支、并發等

狀態機圖的特點

• 事情圍繞某東西開展

• 該東西有不同的狀態，狀態會因為發生了一些事情而變化（來自《火球uml》）

從上述三個點中，我們能夠看出這3種流程分析圖之間的區別，在使用時加以選擇即可；同時也不要限制自己只能選擇一種，完成可以同時使用多種圖來從多個角度分析問題。

04

如何把控畫圖的粒度？

畫圖相對是一個主觀性比較高的行為，看似掌握了，但實操中往往會容易遇到粒度把控的問題：要不粒度過細了、什么細節都想往圖上添；要不就是粒度不一致，這一分支的粒度很粗、而另一粒度的分支則很細，讓讀者看得云里霧里。

對于新手而言，粒度把控是一個需要持續練習后才能逐漸掌握的難點。那么，我們應該如何掌控畫圖的粒度呢？

• 明確該圖背后想表達的內容和重點，以目標為導向，看看自己的圖能否表達出對方想要理解到的內容

• 先用宏觀的繪制一版粗粒度的圖出來，隨后再進行粒度的逐層細化

• 畫完后可以多與讀者（工程師）交流，希望對方從閱讀角度提出改善建議，幫助自己持續貼近粒度的最佳把控點

看到這里，是不是覺得UML也沒有那么高深和難懂，不過是一種看待事物的角度和思想罷了。本文沒有太細講繪圖語法，如果大家有興趣繼續深挖和學習，推薦幾本還不錯的書《火球UML》《大象UML》《UML和模式應用》。其中，《火球UML》更適合缺少技術背景的產品經理來看，基本可以無障礙學完。

u1s1，最好的UML學習方式就是邊學邊畫，如果你躍躍欲試，那就快找一個案例上手試試吧。

↘好文推薦：

俞軍：產品經理必備的2個模型 用戶細分指南：6種模型與5類維度 產品方案：我的PRD撰寫規范

點個“在看”吧

總結

以上是生活随笔為你收集整理的干货！一文解决产品经理对UML的全部疑问的全部內容，希望文章能夠幫你解決所遇到的問題。

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