本文筆者將為大家總結一些在需求分析與設計階段會常用的到的UML圖，并且對每一個UML圖進行了詳細講解。

最近在學習UML相關的知識，結合了以往的項目以及之前學習編程時的面向對象思想，瞬間感覺UML真的是產品需求分析和設計的強大武器（尤其針對于復雜的2B類項目）！同時，在產品文檔中多融入UML圖也可以很好的增加文檔的可讀性。

本文就來總結一下UML的相關知識吧~

一、UML基礎知識

UML的全稱是Unified Modeling Language，翻譯過來就是統一建模語言。

UML是一種開放的方法，用于說明、可視化、構建和編寫一個正在開發的、面向對象的、軟件密集系統的制品的開放方法。UML展現了一系列最佳工程實踐，這些最佳實踐在對大規模，復雜系統進行建模方面，特別是在軟件架構層次已經被驗證有效（摘自百度百科，真拗口……）。

UML其實就是一系列的圖形，那么為什么說是語言呢？

——因為語言是包括文字和圖形的，在機械工程或建筑領域，設計圖紙內都是包含大量圖形和語言的，在這兩個領域都有各自的標準來描述設計。

那么同理，在軟件開發界，就需要UML來幫助我們完成軟件開發的工作，UML就是軟件領域的標準。當然，UML并不是唯一的標準，只不過UML是業內比較推崇的一類罷了。

二、UML有何作用？

很多初學UML的人會認為：UML是開發人員專門使用的，可以用來生成代碼，可以用來指導編程，如果不是開發人員會很難理解UML的。

其實不然，我認為：UML可以很有效的幫助產品經理或產品設計師進行前期的產品需求分析與產品的設計。在我們梳理項目的業務流程時就會用到活動圖，在我們整理系統功能時就會用到用例圖，在我們與客戶面對面進行溝通調研時用例圖、活動圖、順序圖等UML可以使得溝通變得更加順暢。

將UML應用在項目需求分析和設計時，會使得它的學習門檻大大降低，而且也不一定需要掌握開發知識。通過學習應用UML，將會使我們的工作事半功倍。

三、UML圖

廢話不多說了，開始介紹幾種在需求分析和設計階段會用到的UML圖（在以下的介紹中，我會加入各種UML圖的推薦指數，這個推薦指數是針對于在需求分析與設計階段的一個推薦度）。

1. 活動圖

（1）什么是活動圖?

活動圖強調從活動到活動的控制流。

這里的活動，可以指企業的活動，也可以指應用程序中的活動。因此，也可說活動圖是用來陳述活動與活動之間的流程控制的遷移。

（2）活動圖的畫法

活動圖的繪制涉及幾個重要的元素：

起始點：是一連串活動的開始點，在一個活動圖中，有且只有一個起始點。

起始點的圖示：

結束點：是一連串活動的終結點，在一個活動圖中，可以有多個結束點。

結束點的圖示：

活動：是活動圖最核心的元素，指人或系統的一連串執行細節。比如，用戶在淘寶APP內的“要求退貨”就是一個活動，在這個活動中，可能會包括用戶的一連串的動作——比如“打開APP、進入訂單頁面”等，但是這些細節都要通過“要求退貨”這個活動來表達。

活動的圖示：

遷移：代表流程控制權的遷移，當某一個活動結束后，流程的控制權就通過遷移給另一個活動。如下圖：

分支：代表一個判斷的準則，以菱形塊表示。當指定一個分支時，從分支連接出去的遷移必須要有必要條件，這在UML中稱為約束。在UML中，使用“[]”來表示約束：

分叉以及會合：代表對于后續活動的同步處理，這也是活動圖區分與流程圖的關鍵一點。當某個活動結束后，需要同時進行兩個以上的活動，此時需要用分叉來表達；而當某個活動必須要等其前置的多個活動完成后方可執行，此時會用會合來表達。

分叉與會合的圖示都是：

通常來說，分叉與會合會搭配出現，當活動圖中出現了分叉點，那么在后續的某個特定環節必定會有會合點。

泳道：對于產品經理來說并不陌生，利用泳道可以分配對應的角色，可以幫助我們清晰地知道發起活動的角色是誰。

泳道的圖示：

活動圖范例：

（3）活動圖的使用場景

由于活動的定義不是十分的明確，因此，在系統設計時不會利用活動圖來表達應用程序的架構?；顒訄D通常適用于表達企業或系統的工作流程關系，例如：在梳理業務流程時，我們通常會使用帶泳道的活動圖。

此外，活動圖非常類似于流程圖，因此也適用于表達程序的內部的工作流或結構。

（4）推薦指數

活動圖在需求分析與規劃階段是梳理業務流程的必備工具，同時在涉及單獨模塊流程時也應用頻繁。因此，推薦指數：★★★★★

2. 用例圖

（1）什么是用例？

根據用例的創始人Ivar Jacobson的定義：“用例是在一個系統中所進行的一連串的活動，該活動要能夠滿足系統外部的執行者對系統的預期”。

其實說白了，一個產品或系統的用例，就是用戶對于產品或系統的某一個完整的預期。從另一個角度來說，用例也代表著一個具體的業務場景。

（2）用例圖的畫法

用例圖涉及到的幾個重要元素：

用例：如前所述，用例代表著用戶對于產品或系統的完整預期，也就是用戶在系統內期望的事，在完成了該預期后用戶可以離開產品或系統。是不是有點“用完即走”的意思？微信的一個用例，就可以是“聊天、支付或發朋友圈”等。

用例通常會用一個橢圓形表示：

執行者/角色：即是扮演著某個角色的用戶或系統，執行者通常版扮演者對于產品或系統來說有實際作用的用戶或其他系統。

在UML中，執行者的圖示如下：

系統邊界：展示了系統的內外之分，明確的劃分了開發過程中需要關心和不需要關心的邊界。系統邊界的圖示：

泛化：執行者之間可以有泛化關系，泛化關系可以簡單理解為繼承關系——比如：職員擁有“申請開票”功能，經理擁有“申請開票、審核”功能，那么經理類就可以是職員類泛化生成的。用例之間也會具有泛化關系，比如“篩選用例”可以泛化出“按播放量”和“按訂閱數”的用例。

泛化通常是子類指向基類：

關聯：執行者與用例之間，只能有關聯的關系。

關聯用來連接執行者和用例：

擴展：擴展是用例與用例之間的關系，指的是一個用例的擴展功能——比如：“登錄”用例的擴展用例是“忘記密碼”，這個“忘記密碼”功能不一定會使用。

擴展一般使用extend表示（注意箭頭方向）：

包括：區別于擴展，包括指的是一個用例內，包括的子用例——比如：“角色管理”用例包括“創建角色”、“查詢角色”等用例。

包括使用include表示（注意箭頭方向）：

用例圖范例：

（3）用例圖的使用場景

用例圖表達的是：什么角色通過軟件系統能做什么事情？

從用戶的角度描述了系統的功能，并指出各個功能的執行者，強調用戶的使用者，系統為執行者完成哪些功能。因此，我們可以使用用例圖系統地表達軟件系統的絕大部分功能性需求。

（4）推薦指數

用例圖通常應用在需求分析，和產品或系統的功能描述與定義上。因此，對于需求分析與描述是至關重要的，推薦指數：★★★★★

3. 序列圖

（1）什么是序列圖？

序列圖也叫順序圖，序列圖最主要的目的就是表達對象與對象之間是如何溝通與協作的。

用例常常被細化為一個或者更多的序列圖，同時序列圖更有效地描述如何分配各個類的職責以及各類具有相應職責的原因。

（2）序列圖的畫法

序列圖涉及到的幾個重要元素：

對象：在序列圖中，每個參與部分都是對象。在序列圖中，主要是以“對象名稱”的方式來表述。

圖示：

消息：對象與對象之間只能通過消息來進行聯系，消息可以理解為對象的某一個操作。消息分為同步消息、異步消息和自關聯消息，同步消息需要同步等待消息。

圖示為：

異步發送消息時不需要等待，圖示為：

自關聯消息是對象給自身發送消息，圖示為：

生命線：對象是有生命周期的，因此對象必須在其生命線中才能彼此交換消息。

序列圖中生命線的圖示如下：

約束：是對象與對象之間進行消息交互式的約束條件，也就是要完成此次消息交互必須需要的條件約束。

約束通常使用“[]”表示，圖示：

注釋：一般是對象行為的解釋性內容，圖示為：

序列圖范例：

（3）序列圖的使用場景

序列圖強調了角色/對象之間的交互，信息傳遞是非常明確的。當流程內涉及到多種角色或對象，并且會經過這些角色或對象展開交互，并且會有信息進行傳遞時，順序圖就會派上用場了。

比如：在用戶網購時，就會涉及到譬如“用戶、平臺、訂單中心、支付平臺”等對象之間的交互。

再比如：小程序內基于微信支付的支付業務，也會用序列圖來進行描述。

（4）推薦指數

在分析對角色或對象之間的交互時，會使用到序列圖進行分析交互過程。序列圖通常會搭配活動圖和用例圖進行使用，我個人還是比較喜歡序列圖的，所以推薦指數：★★★★★

4、狀態機圖

（1）什么是狀態機圖？

狀態機圖從某個對象的狀態是如何變化的角度來展示流程的，是一種由狀態、變遷、事件和活動組成的狀態機，用來描述類的對象所有可能的狀態以及時間發生時狀態的轉移條件。

（2）狀態機圖的畫法

狀態機圖涉及到的幾個重要元素：

起始狀態：在一個狀態機圖里，只能有一個起始狀態，這一點類似于活動圖。

起始狀態的圖示：

結束狀態：結束狀態代表整個狀態到此活動結束。在一個狀態機圖中，可以有多個結束狀態。

結束狀態的圖示：

狀態：狀態顯示了狀態的變化。

圖示為：

復合狀態：指的是某個狀態內包括其他的狀態組合。

例如：

遷移。狀態之間使用遷移表達期間的關系，圖示為：

警戒條件：如果某個狀態需要在某個特殊的條件下才可發生，可以在遷移條件上標注警戒條件。警戒條件用一個“[]”表示。

狀態機圖范例：

（3）狀態機圖的使用場景

在產品的需求分析中，如果一個流程是圍繞某一事物/對象的狀態變化而展開時，我們應該優先使用狀態機圖。

比如：常見的訂單流程就可以使用訂單的狀態圖來表示訂單對象的流程。再比如，在請假系統中，請假條的狀態變化流程也可以用狀態機圖來進行分析。

（4）推薦指數

狀態機圖通常會搭配活動圖、用例圖和序列圖來共同使用，方便分析事物或對象的狀態變化過程，在需求分析與設計階段也會用的到。推薦指數：★★★★

5. 類圖

（1）什么是類圖？

類圖其實更加的貼近于開發，一些UML的工具可以通過類圖直接生成代碼。我理解的類圖，是根據之前的用例抽象而成的，一個用例往往就是一個類。類圖描述了類的內部結構和類和類之間的關系。

對于類，一些沒有面向對象基礎的同學可能很不好理解，其實類就是對一些業務對象的抽象。

以游戲為例：在穿越火線游戲中，槍可以是一個類，那么AK、43等型號的槍可是繼承于“槍類”的泛化類。再比如，人是一個類，男人和女人就可以是繼承于“人類”的泛化類。

通過學習編程我了解到，類也可以是數據表，表中的字段就是這個類的屬性。

（2）類圖的畫法

類機圖涉及到的幾個重要元素：

類：圖中最重要的就是類，類是由名稱、屬性和操作組成。屬性可以簡單理解為這個類包括的字段，操作就是該類可以實現的方法。

圖示如下：

類圖中最為重要的，就是類之間的關系，UML類圖中有六大關系。

關聯關系：類與類之間最基本的關系。關聯表達了兩個類的對象之間的結構性關系，比如老師類與課程類之間有一個關聯，那么就代表著一個老師一定會管理著一個學生（一對一家教或多對多的學習）。

關聯的圖示：

泛化：在用例圖中我們介紹過泛化，同理，類與類之間的泛化關系也可以理解為繼承，也就是特殊類與一般類之間的關系。泛化圖示，通常為子類指向基類：

實現：是一種類與接口的關系，表示類是接口所有特征和行為的實現?？梢岳斫鉃?，類通過接口實現了什么功能。

實現的圖示：

依賴：是一種使用關系，比如司機使用汽車。

依賴的圖示：

聚合：是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。

聚合的圖示：

組合：是整體與部分的關系，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系，沒有公司就不存在部門。

組合的圖示：

類圖范例：

（3）類圖的使用場景

類圖顯示了類、類的方法、類的接口以及它們之間靜態結構和關系。運用類圖可以理清業務概念以及它們的關系，能更加深入地剖析系統/產品業務。

類圖可能不容易上手，使用類圖時，盡量從用例圖出發，每一個用例抽象為一個類。類圖可以初步用來梳理概念性的內容，比如：在理清訂單概念時，訂單都會涉及什么字段（屬性），訂單與其他對象類之間的關系如何，訂單類可以提供哪些方法等。

（4）推薦指數

相較于上述幾個行為型的UML圖，類圖在使用上不是那么的好上手，對于有面向對象編程基礎的同學比較好理解，但是個人覺得類之間的這些關系在梳理業務概念時還是很有用的。

推薦指數：★★★

6. 其他UML圖

在上面介紹類圖中，說到了活動圖、用例圖、序列圖和狀態機圖都屬于行為型的UML圖。那么，UML圖為什么會分為結構型和行為型兩種呢?

結構型的圖描述的是某種結構，這種結構在某段時間內應該是穩定的，“靜態”的；而結構型的圖描述的是某種行為，是“動態”的。

分析系統需求時，我們會面對很多業務概念，它們之間會有某些關系，這些內容可以看成是“靜態”的，我們可以利用UML的結構性的圖來分析，比如上述的類圖。

同時，業務會涉及大量的流程、過程等，這些內容是“動態”的，此時就可以用行為型的UML圖來分析，比如活動圖、用例圖、序列圖和狀態機圖。

行為型的UML圖除了活動圖、用例圖、序列圖和狀態機圖，還包括通信圖和時間圖。結構型的UML圖除了類圖，還包括對象圖，包圖，組件圖和部署圖。

（1）通信圖

通信圖其實和序列圖表達的是同一件事，并且通信圖和序列圖在一些UML工具中二者是可以相互轉換的。在涉及多對象或系統的交互描述時，序列圖會比通信圖更加明確。所以，在需求分析與設計階段，幾乎不會用到通信圖，有此方面的需求使用序列圖就可以了。

通信圖范例：

（2）時間圖

時間圖是表示某對象或系統的狀態隨時間變化而變化的一種圖，如下圖是一個ATM操作的時間圖：

時間圖是UML2.0新增加的一個圖形，從圖中可以看出時間圖的重要元素包括：生命線、狀態、時間軸、時間線和事件。

在需求分析與設計階段，用到時間圖的情況幾乎沒有。

（3）對象圖

在面向對象的編程中，對象是由類實例化得到的。對象圖和類圖的樣子很相似，對象是類的實例化，“person : Person”表示對象person是類Person的實例。

對象圖往往只在需要描述復雜算法時才會使用，畫出來的對象圖往往不會只有一個對象，該圖只畫了一個對象，其目的是盡量簡化以便讀者的理解什么是對象圖。

在需求分析與設計工作中基本上不需要使用對象圖，通常會用類圖完成相關工作。

（4）包圖

包圖是一個高階的UML視圖。包圖的主要用途是“打包”類圖。用類圖描述業務概念時，很多時候會因為業務類太多，而導致類圖非常龐大，不利于閱讀，這時可以將某些類放入“包”中，通過包圖來組織業務概念圖。

如下圖所示，包圖包括的元素有包、命名空間（在包的下方加入一個用小括號表達的說明方式）和依賴關系。

包圖在需求分析與設計階段很少會使用到。

（5）組件圖

組件圖也叫構件圖。一個軟件往往是由很多“物理部件”(如：控件、重用構件等)組成的，構件圖就是用來描述軟件內部物理組成的一種圖。

如下圖所示，組件圖涉及的元素包括組件、提供接口、需求接口和依賴關系。

在需求分析和設計工作中，需要用到組件圖的情況不是很多，除以下情況：

• 待開發的系統需要與第三方的系統、原有系統、某些老系統等交互，這時可用構件圖描述交互要求。
• 客戶對軟件設計有某些特殊要求，這時可用構件圖來描述要求。

構件圖有時不會單獨使用，還會和部署圖一起結合使用。

（6）部署圖

部署圖是用來描述系統如何部署、本系統與其他系統是怎樣的關系的一種圖。

從下圖可以看出，部署圖包括的要素有：節點（代表某個物理資源，如存儲設備或計算機）、組件、關聯關系和依賴關系。

在為客戶開發項目時，有的客戶場地會具備一定的IT基礎環境，比如：局域網、服務器等。我們的系統需要基于當前的IT環境來進行規劃和設計，比如：電視臺的客戶，通常都會有自己的服務器和數據庫，是不允許外網訪問的。此時就可以使用部署圖來描述IT環境。

分析系統軟件的需求，不能忽略系統架構、部署、IT架構等方面的要求，我們要基于客戶當前的IT基礎環境，做出一個最符合客戶利益的規劃設計。

組件圖和部署圖的應用，通常需要具備一定的IT技術架構以及軟件設計知識。在業務需求分析與設計階段更多的還是分析業務，提煉功能需求，用到組件圖和部署圖的情況還是比較少的。但是，作為有抱負的青年，我還是希望自己能逐步積累，慢慢了解IT架構方面的知識。

四、總結

本文我們總結了一些在需求分析與設計階段會常用的到的UML圖，并且對每一個UML圖進行了詳細講解。對于那些我覺得不太會常用到的UML圖就沒有做過多的表述。希望可以利用好UML圖，讓UML圖成為支持我們工作的得力助手。

系統學寫了UML后，對比自己之前項目中繪制的一些流程圖，確實不是特別的規范。在未來的項目中，我打算要充分利用好UML了。

最后推薦給大家繪制UML的工具——ProcessOn，用著還不錯~

#專欄作家#

流年，人人都是產品經理專欄作家?；ヂ摼W產品設計師，4年互聯網產品設計經驗。擅長用戶體驗設計，喜歡鉆研需求功能背后的技術實現方式；在成為綜合型產品設計師的道路上不斷努力前進！

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議