編輯導語(yǔ)：可能很多產(chǎn)品經(jīng)理會(huì )有疑問(wèn)，UML是什么？為什么要學(xué)習這個(gè)？學(xué)習了之后會(huì )有什么作用？它其實(shí)是一個(gè)工具，是IT專(zhuān)業(yè)人員期待多年的統一標準建模符號，支持面向對象的技術(shù)。學(xué)習UML，有助于快速切換領(lǐng)域和習得經(jīng)驗，一起來(lái)看看吧。
看到這個(gè)標題，產(chǎn)品的朋友們大概率會(huì )一頭霧水，為什么一個(gè)產(chǎn)品要學(xué)這么“奇怪”的東西？產(chǎn)品把產(chǎn)品本職工作做好就行了吧？且聽(tīng)我快速道來(lái)~
在我之前的產(chǎn)品經(jīng)歷里，經(jīng)常會(huì )遇到一個(gè)場(chǎng)景，在我拆解（或調研）某個(gè)業(yè)務(wù)系統時(shí)，無(wú)法梳理出一個(gè)系統層面清晰的脈絡(luò )，思考出整個(gè)業(yè)務(wù)和系統架構的融合方式，即使后期我梳理清楚了，也是一個(gè)“大力出奇跡”的方式，一步一步硬推出來(lái)的。
但這種蠻力的方式不是長(cháng)久之計，如果我以后換了領(lǐng)域或者行業(yè)怎么辦？我的業(yè)務(wù)線(xiàn)調整裁掉了該怎么辦？都要硬啃嗎？顯然不行的在工作中，我們接觸新領(lǐng)域/產(chǎn)品的時(shí)候，都會(huì )“開(kāi)頭難”，這個(gè)難在于沒(méi)有在這個(gè)新領(lǐng)域下有歷史經(jīng)驗，以致于用最笨的方法去調研，驗證，學(xué)習，然后積累出一點(diǎn)點(diǎn)優(yōu)勢，慢慢滾雪球，形成加速。
但如果又換一個(gè)新領(lǐng)域，我們很大概率還依賴(lài)這種行為方式，這就會(huì )造成認知的低效率。我其實(shí)一直想找到一個(gè)比較底層的方法工具，便于快速切換領(lǐng)域和習得經(jīng)驗。
我先后學(xué)習與應用了一些思考框架：
但這些框架應用的條件，都是建立在我的需求可以被現實(shí)環(huán)境承載、以及我有這方面領(lǐng)域的邏輯下才可生效。
我想要的是切換領(lǐng)域，最后直到我遇到了UML，只有它才能滿(mǎn)足我所以我來(lái)推薦產(chǎn)品的朋友，或者其他有這方面困惑的朋友，了解UML這個(gè)工具這篇介紹UML的文章，算是一個(gè)引子，后面營(yíng)銷(xiāo)系統相關(guān)的文章會(huì )引用到這里，避免到時(shí)候閱讀上有信息割裂感
學(xué)名叫做“統一建模語(yǔ)言（Unified Modeling Language）”，下面用大白話(huà)解釋下UML這個(gè)語(yǔ)言定位是個(gè)工具，是1997年OMG組織（不是哦買(mǎi)噶！是Object ManagementGroup對象管理組織）發(fā)布的統一建模語(yǔ)言，是一種編制軟藍圖的標準化語(yǔ)言它的目標之一就是為開(kāi)發(fā)團隊提供標準通用的設計語(yǔ)言來(lái)開(kāi)發(fā)和構建計算機應用，提出了一套IT專(zhuān)業(yè)人員期待多年的統一標準建模符號，支持面向對象的技術(shù)。
通過(guò)使用UML，這些人員能夠閱讀和交流系統架構和設計規劃。（可以理解為想實(shí)現在不同世界的研發(fā)溝通時(shí)，達到車(chē)同軌書(shū)同文的效果）除此之外，工作中還會(huì )遇到各種xxML，都是某類(lèi)領(lǐng)域為了方便業(yè)內交流，或者戰略上為了制定行業(yè)標準而發(fā)明的建模語(yǔ)言，如VRML（虛擬現實(shí)建模語(yǔ)言），sysML（從UML2.0衍生并進(jìn)化）等
在我看來(lái)，UML更是一種思想，誕生之初給研發(fā)人員使用，但也適合產(chǎn)品架構師，系統分析師這類(lèi)的角色使用，掌握以后有這個(gè)幾個(gè)好處。
UML是一種面向對象的思考方式，用抽象的方式去反映現實(shí)世界的某個(gè)片段。
如果去和前文提到“用戶(hù)體驗要素（戰略層/范圍層/結構層/框/框架層/表現層）”聯(lián)系的話(huà)，UML的作用處在范圍層&結構層。UML同時(shí)也是分而治之的思想的重要體現，在現實(shí)中也有其他類(lèi)似的體現，比如工程測量中“先整體后局部，由高級到低級，由控制到碎部”掌握了它，就可以在思考復雜問(wèn)題的時(shí)候有層次有章法，面對再大再龐雜的系統，也可以逐個(gè)解開(kāi)。
“領(lǐng)域知識”是一個(gè)元概念，有時(shí)候和用戶(hù)/客戶(hù)交流，你會(huì )被帶入到全新的領(lǐng)域（不理解領(lǐng)域的話(huà)，可類(lèi)比行業(yè)去理解，實(shí)際不太一樣）中，和領(lǐng)域內的專(zhuān)家與客戶(hù)交談，他們的獨有的業(yè)務(wù)經(jīng)驗，對你來(lái)講，就是一個(gè)“領(lǐng)域知識”，這種場(chǎng)景在B端業(yè)務(wù)中會(huì )更為常見(jiàn)。
如果我們無(wú)法定義一件事，就無(wú)法注意到它。
好了，我現在把定義引入進(jìn)來(lái)了，大家可嘗試在工作或生活中注意到它：在與客戶(hù)交談時(shí)，注意客戶(hù)描述業(yè)務(wù)實(shí)體的名詞術(shù)語(yǔ)，這些名詞術(shù)語(yǔ)會(huì )被當成「類(lèi)」，還要注意聽(tīng)到的動(dòng)詞，這些動(dòng)詞可能會(huì )構成「類(lèi)」中的「操作」，然后還有其他名詞可能變?yōu)椤割?lèi)」中的「屬性」。
當梳理出來(lái)之后，再去詢(xún)問(wèn)客戶(hù)每個(gè)「類(lèi)」的作用，客戶(hù)會(huì )告訴你「類(lèi)」的職責，這樣就能快速了解該領(lǐng)域的基礎邏輯。就是我開(kāi)篇提到的痛點(diǎn)，在學(xué)習了UML之后，對“領(lǐng)域知識”有了新的認知，有信心在進(jìn)入陌生領(lǐng)域時(shí)系統的建立起認知。
學(xué)了UML后，我甚至可以對人際關(guān)系有了更冷靜的感知，比如溝通的時(shí)候，溝通的是你，你的關(guān)系，別人，還是你身上的某部分屬性，都可以想的很透徹，更能接近事實(shí)和本質(zhì)，可提高思考的深度這種深度的提高，對我這種傻實(shí)在的人來(lái)說(shuō)，很有幫助?；蛘邔ι鐣?huì )經(jīng)驗不太足的學(xué)生來(lái)說(shuō)，也會(huì )有幫助。
引了這么多，直接看UML有啥東西吧！主要可分為如下圖兩大類(lèi)：
再奉上一張網(wǎng)上超級經(jīng)典的圖，UML拆解的樣例，這里基本用上了UML中高頻使用的圖例類(lèi)型，請保存好，后面會(huì )持續用到。
那么，產(chǎn)品同學(xué)要掌握的圖有哪些？
類(lèi)，是一類(lèi)或者一組具有類(lèi)似屬性和共同行為的事物，映射到現實(shí)中，可參考我上面的那個(gè)黃顏色的圖類(lèi)圖（Class Diagram）是面向對象系統建模中最常用和最重要的圖，是定義其它圖的基礎，主要是用來(lái)顯示系統中的類(lèi)、接口以及它們之間的靜態(tài)結構和關(guān)系的一種靜態(tài)模型類(lèi)圖描述一個(gè)類(lèi)的屬性和操作，以及對系統的約束。
它們是唯一的，可以直接映射到面向對象的語(yǔ)言的 UML圖。請看詳解「類(lèi)」的實(shí)例，叫做「對象」。
類(lèi)和類(lèi)之間，也會(huì )存在相互關(guān)系，這個(gè)關(guān)系也有專(zhuān)門(mén)的標識方式，這里要先引入“面向對象”的一些相關(guān)概念了，如下圖面向對象的思考方式，是以開(kāi)發(fā)出能夠反映出現實(shí)世界某個(gè)特定片段為目標的，或者叫建模。
對象是類(lèi)的實(shí)例，比如你和我都是“人”這個(gè)「類(lèi)」的實(shí)例，對象具有自身的結構，屬性和操作。比如抽象，是過(guò)濾掉對象的一部分屬性，保留解決問(wèn)題所夠用的屬性和操作，因為現實(shí)生活中，解決問(wèn)題不一定需要全部的信息再就是繼承，我們的電冰箱，電烤箱可以看成單獨的「類(lèi)」，都是電器這個(gè)「類(lèi)」下的子類(lèi)，繼承了電器的“開(kāi)”與“關(guān)”，但冰箱有冷凍功能，烤箱有加熱功能。
對應的，電器這個(gè)「類(lèi)」也是電冰箱電烤箱的「超類(lèi)」其他的可以看圖，要解釋下本圖不是UML全部的內容，但足夠本文章講和使用了。
好了，終于可以講正題了！「類(lèi)」之間存在的關(guān)系，有如圖幾種，我們詳細用圖片展示。
關(guān)聯(lián)接觸過(guò)數據庫的同學(xué)對這個(gè)定義比較熟悉，基本等同于ER的思考邏輯使用直線(xiàn)表示。
就像「類(lèi)」和「對象」的層級關(guān)系，「類(lèi)」和「類(lèi)」之間的“關(guān)聯(lián)”關(guān)系，也是一個(gè)「類(lèi)」，且這個(gè)「關(guān)聯(lián)類(lèi)」對應的「對象」叫做「鏈」。
聽(tīng)起來(lái)有點(diǎn)套娃，但這個(gè)就是核心的思考方式了，可以向上抽象思考，也可以向下實(shí)例思考。
關(guān)聯(lián)講完了，咱們來(lái)講抽象，繼承，泛化這三個(gè)放到一塊講，是他們的聯(lián)系可放到一塊去思考，在設計游戲時(shí)，「計時(shí)器類(lèi)」是從「投球計時(shí)類(lèi)」和「游戲計時(shí)類(lèi)」抽象出來(lái)的，對應的子類(lèi)用空心實(shí)線(xiàn)箭頭指向被繼承的類(lèi)，這個(gè)箭頭就是泛化關(guān)系，代表“is a kind of……”
好好琢磨下哈，然后咱們繼續介紹下接口和實(shí)現接口跟封裝可以一起介紹，可以理解為你在使用冰箱的時(shí)候，不需要知道冰箱怎么制冷的。只需要插電和開(kāi)關(guān)冰箱門(mén)就好了。
冰箱把制冷的細節都封裝在了里面，給你留下了開(kāi)關(guān)和插電的接口冰箱這個(gè)「類(lèi)」對應的他的開(kāi)關(guān)接口，這之間的關(guān)系就是實(shí)現，使用空心虛線(xiàn)箭頭標識。
依賴(lài)用虛線(xiàn)單箭頭表示，一個(gè)類(lèi)使用了另一個(gè)類(lèi)，比如在設計報表類(lèi)系統時(shí)，會(huì )存在類(lèi)似的關(guān)系?！罢故緢蟊怼钡墓δ?，使用了“報表”這個(gè)類(lèi)，有一個(gè)前置的邏輯，形成了依賴(lài)關(guān)系。
最后就是類(lèi)圖里的最后一塊聚集和組成這其中有點(diǎn)形似與混合物 與 化合物的區別。聚集，用空心菱形剪頭，從部分指向整體，一種混合物的關(guān)系組成，用實(shí)心菱形剪頭，代表強聚集關(guān)系，類(lèi)似化合物的關(guān)系，桌子由桌面和桌腿組成。當然這只是為了沒(méi)接觸的同學(xué)好理解，如果有ETC精請克制自己不要自動(dòng)抬杠……
篇幅最長(cháng)的類(lèi)圖介紹完了，接下來(lái)介紹一個(gè)也很常用的用例圖，相對簡(jiǎn)單很多，跟畫(huà)畫(huà)一樣，一個(gè)小人兒和一大堆氣泡發(fā)生了連線(xiàn)的關(guān)系用例圖可以在設計系統或者需求的時(shí)候，理清楚實(shí)際的場(chǎng)景，排坑。比如設計某功能時(shí)，總會(huì )有一些操作場(chǎng)景被遺漏，導致進(jìn)入測試階段中了，才發(fā)現有問(wèn)題，要修補。
使用用例圖，能很大程度上在設計階段避免這種情況。
小人兒就是參與者氣泡就是用例二者之間使用依賴(lài)線(xiàn)連接， 上面可以標記<< include>> 或 << extend>><< include>>可理解為用例間包含的關(guān)系，一個(gè)用例包含了下一層級的用例。
<< extend>>可以理解為此用例還有其他場(chǎng)景可以使用，擴展出了一個(gè)入口用例圖只用來(lái)標識參與者和用例的關(guān)系，并不代表先后順序。
用例圖在交付時(shí)通常給客戶(hù)和開(kāi)發(fā)組參考，每個(gè)用例圖的場(chǎng)景描述至少占一頁(yè)文檔，包含：·發(fā)起用例的參與者·用例的假設條件·用例的前置條件·場(chǎng)景中的步驟·場(chǎng)景完成后的后置條件·從用例中獲益的參與者。
終于大半篇幅講完了結構元素，本節開(kāi)始講行為元素了，如果小伙伴們看麻了，可以收藏后面繼續看~
行為元素對于產(chǎn)品同學(xué)來(lái)講，基本是不陌生的，如果經(jīng)常繪制業(yè)務(wù)流程圖的話(huà)，會(huì )發(fā)現有很多一致的地方，很正常，都是團隊的溝通工具嘛。
這種圖在制作大型業(yè)務(wù)系統的時(shí)候，肯定會(huì )用到，比如我在設計CRM系統的時(shí)候，里面的商機就會(huì )有多種狀態(tài)流轉，就用到了這個(gè)圖。給研發(fā)兄弟看，也會(huì )溝通的很順暢，因為研發(fā)在實(shí)際工作中會(huì )頻繁用到這里，他們基于這些狀態(tài)去設計代碼層面的調用邏輯。便于他們設計的時(shí)候提前規劃，提高研發(fā)的效率。
研發(fā)最怕的，是做一半了中途改了基礎底層狀態(tài)的設計，分分鐘掀桌子狀態(tài)圖的定義，可以說(shuō)是對象改變了自己的狀態(tài)，以響應事件和時(shí)間的流逝，比如燈的開(kāi)與關(guān)。
狀態(tài)圖和類(lèi)圖的差別，是狀態(tài)圖針對的是單個(gè)對象來(lái)建模，類(lèi)圖可以針對一組類(lèi)來(lái)建模繪制方法，圓角矩形代表一個(gè)狀態(tài)，狀態(tài)間帶箭頭的實(shí)現代表狀態(tài)的遷移，箭頭指向目標狀態(tài)。實(shí)心圓點(diǎn)代表狀態(tài)轉移的起點(diǎn)，牛眼圓圈代表重點(diǎn)記不住那么多沒(méi)關(guān)系，有專(zhuān)門(mén)的工具，跟visio一樣，直接找來(lái)拖就行了，文章末尾會(huì )介紹繪制工具。
下圖是基于工單類(lèi)的審批流程繪制的狀態(tài)圖。
時(shí)序圖，也叫順序圖，強調了時(shí)間維度，時(shí)序圖的關(guān)鍵思想是強調了對象之間的交互按照特定時(shí)間發(fā)生，這些特定時(shí)間的交互序列，從開(kāi)始到結束需要一定的時(shí)間。時(shí)序圖通常用對象標識，從每個(gè)對象下方延展出一條生命線(xiàn)，一個(gè)時(shí)序圖可以用單個(gè)或者多個(gè)如下單元組成。
每個(gè)線(xiàn)程對象之間可以用消息通信，有兩類(lèi)一類(lèi)消息叫調用，這是一個(gè)來(lái)自消息發(fā)送者對象的請求，它被傳遞給消息的接收對象，請求接收者對象執行某種操作。通常，需要發(fā)送者等待接收者執行，等待反饋，這種消息又叫做同步消息。
如下圖，帶有實(shí)心箭頭的實(shí)線(xiàn)表示發(fā)送的消息，帶有線(xiàn)狀箭頭的虛線(xiàn)表示返回消息。
另一類(lèi)消息叫做異步消息，這種機制下發(fā)送者把控制權交給了接收者，并不等待操作完成，這種消息用帶有線(xiàn)狀箭頭的實(shí)線(xiàn)表示。
時(shí)序圖跟跨職能流程圖有些許相似，不過(guò)時(shí)序圖可以更清晰的展示每個(gè)線(xiàn)程的動(dòng)作順序，以及線(xiàn)程之間的通信關(guān)系，如果是用跨職能流程圖的方式來(lái)繪制，就不便于展示每個(gè)線(xiàn)程之間的多條通信了依然拿請假的流程舉例，如圖。
時(shí)序圖還有幀化的概念，不過(guò)對于非研發(fā)工作來(lái)講，沒(méi)必要學(xué)習，基本用不到。不再贅述。
終于到了最后的類(lèi)型了！活動(dòng)圖，用圓角矩形表示，與狀態(tài)圖不同的是，活動(dòng)圖的圖例更接近橢圓。一個(gè)活動(dòng)的處理一旦完成，就自動(dòng)引起下一個(gè)活動(dòng)發(fā)生。
狀態(tài)圖側重于描述對象的狀態(tài)變化，活動(dòng)圖側重于描述活動(dòng)，與業(yè)務(wù)單線(xiàn)流程圖大多數邏輯類(lèi)似，不過(guò)區別是活動(dòng)圖更適合展示判斷過(guò)程，和并發(fā)路徑。如果用基礎的單線(xiàn)流程圖標識，會(huì )不太直觀(guān)比如判斷是類(lèi)似的表示方法。
并行路徑的表示方法
如果日常工作中使用流程圖較多，也不必非要用這個(gè)，UML本質(zhì)目的是快速溝通，能溝通清楚就行。
下面講下我平時(shí)是怎么應用的，有兩類(lèi)案例，一類(lèi)是研究一個(gè)系統，多數的時(shí)候是憑借興趣研究的，感覺(jué)很有意思。另一個(gè)是工作里實(shí)際使用時(shí)展示的。
saleforce是CRM業(yè)界非常知名的一個(gè)產(chǎn)品，因為這個(gè)系統太過(guò)于龐大，UML的類(lèi)圖是快速理解的一個(gè)利器。此時(shí)應用UML不是還原到如何實(shí)現，而是為了理解它是怎么設計的。通過(guò)demo很難有機會(huì )能接觸到更深層的實(shí)現細節。
在設計內部BI系統時(shí)，用到了類(lèi)圖，和用例圖。
在設計CRM系統時(shí)，商機（例子）狀態(tài)的流轉圖。CRM的設計，我會(huì )單起一系列文章講。
除了這些還有很多應用，不過(guò)都差不多，應該可以給大家足夠的幫助了。關(guān)于UML的介紹內容，就到此結束，下面我做下對應的答疑。
在調研UML是否值得學(xué)習的時(shí)候，我也會(huì )經(jīng)?？吹竭@樣那樣的問(wèn)題，比如：
我看完了，真的有必要學(xué)嗎？研發(fā)不看怎么辦？
我的個(gè)人建議是，如果自身喜歡這方面的思考，可以憑興趣去學(xué)；如果是B端從業(yè)且想繼續發(fā)展的業(yè)務(wù)產(chǎn)品，建議去學(xué)，學(xué)了以后會(huì )有如虎添翼的功效，不過(guò)學(xué)習需要時(shí)間，建議收藏，或者轉發(fā)給小號后續?？?，我平時(shí)看到東西也這么干哈哈。
最好能買(mǎi)書(shū)學(xué)，更系統UML本質(zhì)還是溝通工具，可以跟研發(fā)去協(xié)商，看團隊更傾向用什么方式溝通，UML只是一種，如果有別的更合適的表示方法，能把邏輯梳理清楚，歧義消除干凈，最好不過(guò)了。
UML和數據建模是否有關(guān)系？
跟研發(fā)同事交流過(guò)，他們說(shuō)UML其實(shí)就跟JAVA編程過(guò)程中的思考很接近，不斷抽象和建模，平時(shí)也會(huì )用到。數據庫建模與UML有一定的聯(lián)系，數據庫建模的過(guò)程是邏輯層到物理層的逐層過(guò)程，都是構造模型，但側重點(diǎn)不一樣，數據庫建模側重數據層面邏輯效率，模型可用性等等。
UML之后如何使用？
除了上面的那些基本功能點(diǎn)以外，使用UML的本質(zhì)目的就是為了多方理解，盡管UML有一些法則，也不要被禁錮，能達到溝通順暢無(wú)歧義的目的，就足夠了。
畫(huà)圖使用什么工具呢？
starUML。win/mac平臺都有，win的平臺有個(gè)版本很復古，但是功能很完善。mac有starUML4.0的版本，顏值很高，但是感覺(jué)畫(huà)起來(lái)沒(méi)win的好用。
大家可以百度搜下?！isio?？梢援?huà)的圖很多，包含了UML的基礎圖例，不過(guò)看個(gè)人習慣，我Visio和starUML都用，Visio常用來(lái)畫(huà)流程·其他有用的也可以推薦下，工具嘛，趁手就行。
有哪些書(shū)籍推薦？
UML基礎、案例與應用（入門(mén)），大象UML（進(jìn)階），大話(huà)設計模式（感興趣可以看），系統架構（值得反復長(cháng)期啃，我確實(shí)還沒(méi)看完，太大了，不過(guò)是本神書(shū)）另外其他的書(shū)，可以白嫖微信讀書(shū)無(wú)限卡，香滴很！
未來(lái)，我會(huì )出一些關(guān)于業(yè)務(wù)系統的相關(guān)文章，盡量大白話(huà)，可能有些大佬看著(zhù)文字會(huì )評價(jià)我的思考膚淺，但能有人聽(tīng)懂和交流，才是我的初衷。
我期望我的些許產(chǎn)出，可以讓新手產(chǎn)品同學(xué)們不再像我當年那樣隨機漫步，能快速度過(guò)無(wú)人帶領(lǐng)自己摸索的成長(cháng)期，我愿意做一塊鋪路石~肝了這么久，不知道你們學(xué)廢了沒(méi)有，如果有收獲，還請點(diǎn)個(gè)贊鼓勵一下我~哈哈哈感謝感謝。
聯(lián)系客服
