本文由作者 羅文正雄?發布于社區

看到這個標題，產品的朋友們大概率會一頭霧水，為什么一個產品要學這么“奇怪”的東西？產品把產品本職工作做好就行了吧？

且聽我快速道來~

在我之前的產品經歷里，經常會遇到一個場景，在我拆解（或調研）某個業務系統時，無法梳理出一個系統層面清晰的脈絡，思考出整個業務和系統架構的融合方式，即使后期我梳理清楚了，也是一個“大力出奇跡”的方式，一步一步硬推出來的。

但這種蠻力的方式不是長久之計，如果我以后換了領域或者行業怎么辦？我的業務線調整裁掉了該怎么辦？都要硬啃嗎？顯然不行的

在工作中，我們接觸新領域/產品的時候，都會“開頭難”，這個難在于沒有在這個新領域下有歷史經驗，以致于用最笨的方法去調研，驗證，學習，然后積累出一點點優勢，慢慢滾雪球，形成加速。但如果又換一個新領域，我們很大概率還依賴這種行為方式，這就會造成認知的低效率。

我其實一直想找到一個比較底層的方法工具，便于快速切換領域和習得經驗。

我先后學習與應用了一些思考框架，如

• 用戶體驗要素五層框架（戰略層/范圍層/結構層/框/框架層/表現層）這套思考方式

• 需求蛋模型（一個集合里畫一條線，兩側分別是自身的功能與用戶的需求）

• 用戶故事地圖（按故事線去梳理一些用戶完整的story，然后快速開發）

• 商業模式畫布（一個梳理商業模式的框架圖，可用來自己做商業規劃，也可以用來調研分析競品，在執行上順序會略有不同）
  

但這些框架應用的條件，都是建立在我的需求可以被現實環境承載、以及我有這方面領域的邏輯下才可生效。我想要的是切換領域，最后直到我遇到了UML，只有它才能滿足我

所以我來推薦產品的朋友，或者其他有這方面困惑的朋友，了解UML這個工具

這篇介紹UML的文章，算是一個引子，后面營銷系統相關的文章會引用到這里，避免到時候閱讀上有信息割裂感

01

UML到底是個什么？

學名叫做“統一建模語言（Unified Modeling Language）”，下面用大白話解釋下

UML這個語言定位是個工具，是1997年OMG組織（不是哦買噶！是Object ManagementGroup對象管理組織）發布的統一建模語言，是一種編制軟藍圖的標準化語言
它的目標之一就是為開發團隊提供標準通用的設計語言來開發和構建計算機應用，提出了一套IT專業人員期待多年的統一標準建模符號，支持面向對象的技術。
通過使用UML，這些人員能夠閱讀和交流系統架構和設計規劃。（可以理解為想實現在不同世界的研發溝通時，達到車同軌書同文的效果）

除此之外，工作中還會遇到各種xxML，都是某類領域為了方便業內交流，或者戰略上為了制定行業標準而發明的建模語言，如VRML（虛擬現實建模語言），sysML（從UML2.0衍生并進化）等

02

為什么要學UML？我能得到什么？

在我看來，UML更是一種思想，誕生之初給研發人員使用，但也適合產品架構師，系統分析師這類的角色使用，掌握以后有這個幾個好處

好處1 思維方式的擴展

UML是一種面向對象的思考方式，用抽象的方式去反映現實世界的某個片段。如果去和前文提到“用戶體驗要素（戰略層/范圍層/結構層/框/框架層/表現層）”聯系的話，UML的作用處在范圍層&結構層

UML同時也是分而治之的思想的重要體現，在現實中也有其他類似的體現，比如工程測量中“先整體后局部，由高級到低級，由控制到碎部”

掌握了它，就可以在思考復雜問題的時候有層次有章法，面對再大再龐雜的系統，也可以逐個解開

好處2 識別“領域知識”，跨領域溝通與學習能力的提升

“領域知識”是一個元概念，有時候和用戶/客戶交流，你會被帶入到全新的領域（不理解領域的話，可類比行業去理解，實際不太一樣）中，和領域內的專家與客戶交談，他們的獨有的業務經驗，對你來講，就是一個“領域知識”，這種場景在B端業務中會更為常見。

如果我們無法定義一件事，就無法注意到它。

好了，我現在把定義引入進來了，大家可嘗試在工作或生活中注意到它：

在與客戶交談時，注意客戶描述業務實體的名詞術語，這些名詞術語會被當成「類」，還要注意聽到的動詞，這些動詞可能會構成「類」中的「操作」，然后還有其他名詞可能變為「類」中的「屬性」。
當梳理出來之后，再去詢問客戶每個「類」的作用，客戶會告訴你「類」的職責，這樣就能快速了解該領域的基礎邏輯。

就是我開篇提到的痛點，在學習了UML之后，對“領域知識”有了新的認知，有信心在進入陌生領域時系統的建立起認知

好處3 完全是私貨 對思考的習慣有很大影響

學了UML后，我甚至可以對人際關系有了更冷靜的感知，比如溝通的時候，溝通的是你，你的關系，別人，還是你身上的某部分屬性，都可以想的很透徹，更能接近事實和本質，可提高思考的深度

這種深度的提高，對我這種傻實在的人來說，很有幫助。或者對社會經驗不太足的學生來說，也會有幫助

03

UML都包含哪些內容，如何快速上手？

引了這么多，直接看UML有啥東西吧！
主要可分為如下圖兩大類：

1、結構元素，圖例左半部分，自上而下為類圖，接口，用例圖，關系，分組，注釋
2、行為元素，圖例右半部分，自上而下為狀態圖，時序圖，協作圖，活動圖

可以理解為這就是咱們現實世界的粗暴分解，結構和過程組成了世界上的一切，形成了時空

再奉上一張網上超級經典的圖，UML拆解的樣例，這里基本用上了UML中高頻使用的圖例類型，請保存好，后面會持續用到

那么，產品同學要掌握的圖有哪些？

結構元素

結構元素-類圖

類，是一類或者一組具有類似屬性和共同行為的事物，映射到現實中，可參考我上面的那個黃顏色的圖

類圖（Class Diagram）是面向對象系統建模中最常用和最重要的圖，是定義其它圖的基礎，主要是用來顯示系統中的類、接口以及它們之間的靜態結構和關系的一種靜態模型

類圖描述一個類的屬性和操作，以及對系統的約束。它們是唯一的，可以直接映射到面向對象的語言的 UML圖。請看詳解

「類」的實例，叫做「對象」

類和類之間，也會存在相互關系，這個關系也有專門的標識方式，這里要先引入“面向對象”的一些相關概念了，如下圖

面向對象的思考方式，是以開發出能夠反映出現實世界某個特定片段為目標的，或者叫建模。
對象是類的實例，比如你和我都是“人”這個「類」的實例，對象具有自身的結構，屬性和操作。

比如抽象，是過濾掉對象的一部分屬性，保留解決問題所夠用的屬性和操作，因為現實生活中，解決問題不一定需要全部的信息

再就是繼承，我們的電冰箱，電烤箱可以看成單獨的「類」，都是電器這個「類」下的子類，繼承了電器的“開”與“關”，但冰箱有冷凍功能，烤箱有加熱功能。對應的，電器這個「類」也是電冰箱電烤箱的「超類」

其他的可以看圖，要解釋下本圖不是UML全部的內容，但足夠本文章講和使用了

好了，終于可以講正題了！

「類」之間存在的關系，有如圖幾種，我們詳細用圖片展示

關聯
接觸過數據庫的同學對這個定義比較熟悉，基本等同于ER的思考邏輯
使用直線表示

就像「類」和「對象」的層級關系，「類」和「類」之間的“關聯”關系，也是一個「類」，且這個「關聯類」對應的「對象」叫做「鏈」。
聽起來有點套娃，但這個就是核心的思考方式了，可以向上抽象思考，也可以向下實例思考

關聯講完了，咱們來講
抽象，繼承，泛化
這三個放到一塊講，是他們的聯系可放到一塊去思考，在設計游戲時，「計時器類」是從「投球計時類」和「游戲計時類」抽象出來的，對應的子類用空心實線箭頭指向被繼承的類，這個箭頭就是泛化關系，代表“is a kind of……”

好好琢磨下哈，然后咱們繼續介紹下
接口和實現
接口跟封裝可以一起介紹，可以理解為你在使用冰箱的時候，不需要知道冰箱怎么制冷的。只需要插電和開關冰箱門就好了。冰箱把制冷的細節都封裝在了里面，給你留下了開關和插電的接口
冰箱這個「類」對應的他的開關接口，這之間的關系就是實現，使用空心虛線箭頭標識

依賴
用虛線單箭頭表示，一個類使用了另一個類，比如在設計報表類系統時，會存在類似的關系。“展示報表”的功能，使用了“報表”這個類，有一個前置的邏輯，形成了依賴關系

最后就是類圖里的最后一塊

聚集和組成
這其中有點形似與混合物 與 化合物的區別。
聚集，用空心菱形剪頭，從部分指向整體，一種混合物的關系
組成，用實心菱形剪頭，代表強聚集關系，類似化合物的關系，桌子由桌面和桌腿組成。當然這只是為了沒接觸的同學好理解，如果有ETC精請克制自己不要自動抬杠……

結構元素-用例圖

篇幅最長的類圖介紹完了，接下來介紹一個也很常用的用例圖，相對簡單很多，跟畫畫一樣，一個小人兒和一大堆氣泡發生了連線的關系

用例圖可以在設計系統或者需求的時候，理清楚實際的場景，排坑。比如設計某功能時，總會有一些操作場景被遺漏，導致進入測試階段中了，才發現有問題，要修補。使用用例圖，能很大程度上在設計階段避免這種情況。

小人兒就是參與者
氣泡就是用例
二者之間使用依賴線連接，?上面可以標記<< include>> 或 << extend>>

<< include>>可理解為用例間包含的關系，一個用例包含了下一層級的用例。

<< extend>>可以理解為此用例還有其他場景可以使用，擴展出了一個入口
用例圖只用來標識參與者和用例的關系，并不代表先后順序

用例圖在交付時通常給客戶和開發組參考，每個用例圖的場景描述至少占一頁文檔，包含：
·發起用例的參與者
·用例的假設條件
·用例的前置條件
·場景中的步驟
·場景完成后的后置條件
·從用例中獲益的參與者

行為元素

終于大半篇幅講完了結構元素，本節開始講行為元素了，如果小伙伴們看麻了，可以收藏或者轉發給自己的小號，后面繼續看~

行為元素對于產品同學來講，基本是不陌生的，如果經常繪制業務流程圖的話，會發現有很多一致的地方，很正常，都是團隊的溝通工具嘛

行為元素-狀態圖（狀態機圖）

這種圖在制作大型業務系統的時候，肯定會用到，比如我在設計CRM系統的時候，里面的商機就會有多種狀態流轉，就用到了這個圖。

給研發兄弟看，也會溝通的很順暢，因為研發在實際工作中會頻繁用到這里，他們基于這些狀態去設計代碼層面的調用邏輯。便于他們設計的時候提前規劃，提高研發的效率。研發最怕的，是做一半了中途改了基礎底層狀態的設計，分分鐘掀桌子

狀態圖的定義，可以說是對象改變了自己的狀態，以響應事件和時間的流逝，比如燈的開與關。

狀態圖和類圖的差別，是狀態圖針對的是單個對象來建模，類圖可以針對一組類來建模

繪制方法，圓角矩形代表一個狀態，狀態間帶箭頭的實現代表狀態的遷移，箭頭指向目標狀態。實心圓點代表狀態轉移的起點，牛眼圓圈代表重點

記不住那么多沒關系，有專門的工具，跟visio一樣，直接找來拖就行了，文章末尾會介紹繪制工具

下圖是基于工單類的審批流程繪制的狀態圖

行為元素-時序圖

時序圖，也叫順序圖，強調了時間維度，時序圖的關鍵思想是強調了對象之間的交互按照特定時間發生，這些特定時間的交互序列，從開始到結束需要一定的時間。

時序圖通常用對象標識，從每個對象下方延展出一條生命線，一個時序圖可以用單個或者多個如下單元組成

每個線程對象之間可以用消息通信，有兩類

一類消息叫調用，這是一個來自消息發送者對象的請求，它被傳遞給消息的接收對象，請求接收者對象執行某種操作。通常，需要發送者等待接收者執行，等待反饋，這種消息又叫做同步消息。

如下圖，帶有實心箭頭的實線表示發送的消息，帶有線狀箭頭的虛線表示返回消息

另一類消息叫做異步消息，這種機制下發送者把控制權交給了接收者，并不等待操作完成，這種消息用帶有線狀箭頭的實線表示

時序圖跟跨職能流程圖有些許相似，不過時序圖可以更清晰的展示每個線程的動作順序，以及線程之間的通信關系，如果是用跨職能流程圖的方式來繪制，就不便于展示每個線程之間的多條通信了

依然拿請假的流程舉例，如圖。

時序圖還有幀化的概念，不過對于非研發工作來講，沒必要學習，基本用不到。不再贅述

行為元素-活動圖

終于到了最后的類型了！活動圖，用圓角矩形表示，與狀態圖不同的是，活動圖的圖例更接近橢圓。一個活動的處理一旦完成，就自動引起下一個活動發生。

狀態圖側重于描述對象的狀態變化，活動圖側重于描述活動，與業務單線流程圖大多數邏輯類似，不過區別是活動圖更適合展示判斷過程，和并發路徑。如果用基礎的單線流程圖標識，會不太直觀

比如判斷是類似的表示方法

并行路徑的表示方法

如果日常工作中使用流程圖較多，也不必非要用這個，UML本質目的是快速溝通，能溝通清楚就行

04

實戰應用

下面講下我平時是怎么應用的，有兩類案例，一類是研究一個系統，多數的時候是憑借興趣研究的，感覺很有意思。另一個是工作里實際使用時展示的

拆解與理解saleforce

saleforce是CRM業界非常知名的一個產品，因為這個系統太過于龐大，UML的類圖是快速理解的一個利器。
此時應用UML不是還原到如何實現，而是為了理解它是怎么設計的。通過demo很難有機會能接觸到更深層的實現細節

應用到工作

在設計內部BI系統時，用到了類圖，和用例圖。

在設計CRM系統時，商機（例子）狀態的流轉圖。CRM的設計，我會單起一系列文章講

除了這些還有很多應用，不過都差不多，應該可以給大家足夠的幫助了。關于UML的介紹內容，就到此結束，下面我做下對應的答疑

高頻的疑問解答

在調研UML是否值得學習的時候，我也會經常看到這樣那樣的問題，比如

1、我看完了，真的有必要學嗎？研發不看怎么辦？
我的個人建議是，如果自身喜歡這方面的思考，可以憑興趣去學；
如果是B端從業且想繼續發展的業務產品，建議去學，學了以后會有如虎添翼的功效，不過學習需要時間，建議收藏，或者轉發給小號后續常看，我平時看到東西也這么干哈哈，最好能買書學，更系統

UML本質還是溝通工具，可以跟研發去協商，看團隊更傾向用什么方式溝通，UML只是一種，如果有別的更合適的表示方法，能把邏輯梳理清楚，歧義消除干凈，最好不過了。

2、UML和數據建模是否有關系？
跟研發同事交流過，他們說UML其實就跟JAVA編程過程中的思考很接近，不斷抽象和建模，平時也會用到。
數據庫建模與UML有一定的聯系，數據庫建模的過程是邏輯層到物理層的逐層過程，都是構造模型，但側重點不一樣，數據庫建模側重數據層面邏輯效率，模型可用性等等。

3、UML之后如何使用？
除了上面的那些基本功能點以外，使用UML的本質目的就是為了多方理解，盡管UML有一些法則，也不要被禁錮，能達到溝通順暢無歧義的目的，就足夠了

4、畫圖使用什么工具呢？
·starUML。win/mac平臺都有，win的平臺有個版本很復古，但是功能很完善。mac有starUML4.0的版本，顏值很高，但是感覺畫起來沒win的好用。大家可以百度搜下。
·Visio。可以畫的圖很多，包含了UML的基礎圖例，不過看個人習慣，我Visio和starUML都用，Visio常用來畫流程
·其他有用的也可以推薦下，工具嘛，趁手就行

5、有哪些書籍推薦？
·UML基礎、案例與應用（入門）
·大象UML（進階）
·大話設計模式（感興趣可以看）
·系統架構（值得反復長期啃，我確實還沒看完，太大了，不過是本神書）
另外其他的書，可以白嫖微信讀書無限卡，香滴很！

結語

未來，我會出一些關于業務系統的相關文章，盡量大白話，可能有些大佬看著文字會評價我的思考膚淺，但能有人聽懂和交流，才是我的初衷。

我期望我的些許產出，可以讓新手產品同學們不再像我當年那樣隨機漫步，能快速度過無人帶領自己摸索的成長期，我愿意做一塊鋪路石~

肝了這么久，不知道你們學廢了沒有，如果有收獲，還請點個贊鼓勵一下我~哈哈哈感謝感謝

↘好文推薦：

所有人問「貼吧之父」俞軍

產品經理邏輯學通識

干貨?|?產品經理要了解的技術類知識

👇歡迎關注：

點個“在看”吧

總結

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

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