編輯導語：UML的目標是以面向對象圖的方式來描述任何類型的系統(tǒng)，具有很寬的應用領域；產品經理在日常工作中也需要掌握一點UML的知識，可以對一個事物有多角度的認知；本文作者分享了關于UML的詳細分析以及問題解答，我們一起來看一下。

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

統(tǒng)一建模語言(Unified Modeling Language，UML)是一種為面向對象系統(tǒng)的產品進行說明、可視化和編制文檔的一種標準語言，是非專利的第三代建模和規(guī)約語言。

UML是面向對象設計的建模工具，獨立于任何具體程序設計語言。

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

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

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

• 產品經理是否有必要學習UML？
• 如何學習UML？
• 如何選擇哪種圖來表達？
• 如何把控畫圖的粒度？

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

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

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

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

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

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

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

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

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

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

二、如何學習UML？

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

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

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

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

在這5種圖中，類圖是其中唯一的一種靜態(tài)結構型圖，其余4種都是行為型圖。

下面我們逐一來和大家講解一下這5種圖：

1. 類圖?class diagram

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

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

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

包含

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

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

（聚合關系）

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

（組合關系）

繼承：

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

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

依賴：

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

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

• 作者將文章發(fā)表在微信公眾平臺
• 讀者前往微信公眾平臺閱讀文章
• 作者可以發(fā)布0到多篇文章，但一篇文章僅屬于1個作者
• 讀者也可以閱讀0到多篇文章，1篇文章也可以被0到多個讀者閱讀

2. 活動圖?activity diagram

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

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

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

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

3. 狀態(tài)機圖?state machine diagram

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

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

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

4. 順序圖?sequence diagram

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

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

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

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

5. 用例圖?use case diagram

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

用例圖是以操作者的角度出發(fā)，去看這個產品能夠帶給他哪些價值、支持他去操作和查看哪些東西。

繼續(xù)沿用審批舉例：

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

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

三、如何選擇哪種圖來表達？

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

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

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

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

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

最后，我們就要在狀態(tài)機圖、順序圖、活動圖中去做抉擇來描述具體流程了。

這3種圖各自有各自的優(yōu)缺點，下面給出一些選擇上的參考建議：

1. 順序圖的特點

• 強調角色之間的交互，信息傳遞很明確；
• 強調按時間順序分別發(fā)生了什么事情；
• 不太適合表達復雜的特殊流程（循環(huán)分支、條件分支、可選分支）；

2. 活動圖的特點

• 強調每個角色做了什么事情，這些事情的先后關系；
• 適合表達各種特殊流程，如分支、并發(fā)等；

3. 狀態(tài)機圖的特點

• 事情圍繞某東西開展；
• 該東西有不同的狀態(tài)，狀態(tài)會因為發(fā)生了一些事情而變化（來自《火球uml》）。

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

四、如何把控畫圖的粒度？

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

對于新手而言，粒度把控是一個需要持續(xù)練習后才能逐漸掌握的難點。

那么，我們應該如何掌控畫圖的粒度呢？

• 明確該圖背后想表達的內容和重點，以目標為導向，看看自己的圖能否表達出對方想要理解到的內容；
• 先用宏觀的繪制一版粗粒度的圖出來，隨后再進行粒度的逐層細化；
• 畫完后可以多與讀者（工程師）交流，希望對方從閱讀角度提出改善建議，幫助自己持續(xù)貼近粒度的最佳把控點。

看到這里，是不是覺得UML也沒有那么地高深和難懂，不過是一種看待事物的角度和思想罷了。

本文沒有太細講繪圖語法，如果大家有興趣繼續(xù)深挖和學習，推薦幾本還不錯的書《火球UML》《大象UML》《UML和模式應用》；其中，《火球UML》更適合缺少技術背景的產品經理來看，基本可以無障礙學完。

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

作者：冰冰醬；公眾號：setmefree

本文由 @冰冰醬 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議