這七種UML圖的畫法，每個程序員都應該掌握！
眾所周知，軟件開發是一個分階段進行的過程。不同的開發階段需要使用不同的模型圖來描述業務場景和設計思路，在不同的階段輸出不同的設計文檔也是必不可少的，例如，在需求分析階段需要輸出領域模型和業務模型，在架構階段需要輸出物理架構設計，在詳細設計階段需要輸出數據庫設計等。這樣做可以更好地實踐軟件開發，并提高軟件開發的實用性。
軟件建模與設計過程可以分為三個階段：需求分析、架構設計和詳細設計。在這三個階段中，大量使用符合 UML 規范的模型圖，其中常用的有 7 種，包括類圖、序列圖、組件圖、部署圖、用例圖、狀態圖和活動圖。
在需求分析階段，使用用例圖和領域模型圖描述用戶需求和業務場景。在架構設計階段，使用組件圖和部署圖描述軟件系統的組成部分和部署情況。在詳細設計階段，使用類圖、序列圖和狀態圖描述軟件系統的實現細節。
下面我們將探討如何繪制這 7 種模型圖，以及如何在不同階段使用這些模型來生成相應的設計文檔。
類圖
類圖是軟件設計中使用最廣泛的 UML 圖形之一，用來描述類的特性以及類之間的靜態關系。在一個類圖中，每個類都由三個部分組成：類名、屬性列表和方法列表。
除了描述類的基本特征，類圖還用來表示類之間的關系，其中包括六種靜態關系：
- 關聯（Association）：表示一個類對象與另一個類對象之間的關系，比如訂單與客戶之間的關系。
- 依賴（Dependency）：表示一個類對另一個類的使用或調用，比如客戶下訂單時需要使用訂單類。
- 組合（Composition）：表示一種包含關系，表示一個類對象包含另一個類對象，比如一個訂單包含多個商品。
- 聚合（Aggregation）：也表示一種包含關系，但是聚合關系中包含的類對象可以被多個類共享，比如一個學校包含多個班級。
- 繼承（Inheritance）：表示一個類繼承自另一個類，可以從父類中繼承屬性和方法，并且可以添加新的屬性和方法。
- 泛化（Generalization）：與繼承關系相似，但泛化關系可以用來表示更抽象的關系，比如多個類都實現了一個接口。
通過繪制類圖，我們可以清晰地描述一個軟件系統中的類及其之間的關系，幫助開發人員更好地理解軟件系統的結構和功能。
在UML工具中把相關的一組類及其關系用一張圖畫出來，就是類圖。
圖片
如上圖所示，描述的就是一個典型的責任鏈模式的實現類圖。
類圖主要是在 詳細設計 階段畫，一旦類圖設計完成，開發工程師可以根據類圖來實現代碼。只要類方法的邏輯不是太復雜，不同工程師實現的代碼幾乎是一樣的，這有利于保證軟件的規范和統一性。在實際應用中，通常不需要畫出所有類的類圖，只需要畫出核心、代表性、技術難度較高的類圖即可。
圖片
除了在詳細設計階段繪制類圖外，還可以在需求分析階段使用類圖來表示關鍵領域模型對象。在這個階段中，我們不要將注意力集中在屬性或行為上，而應該專注于識別領域對象及其之間的關系。因此，可以使用簡化的類圖來描述，只需要繪制類的名稱和它們之間的關系即可。
如上所示描述的是在需求分析階段挖掘出SIM卡、運營商、手機、手機廠商等模型對象之間的關系。
序列圖
類圖之外，另一種常用的圖形是序列圖。
類圖描述類之間的靜態關系，而序列圖用于描述參與者之間的動態調用關系。每個參與者都有一條垂直向下的生命線，該生命線用虛線表示。參與者之間的消息按照從上到下的順序表示它們的調用順序關系，這就是序列圖這個詞的來源。每個生命線都有一個激活條，它是圖中的細長矩形條，只有在參與者活動時才是激活的。
圖片
通常使用序列圖表示對象之間的交互，這些對象可以是類對象，也可以是更大的參與者，如組件、服務器、子系統等。總之，只要涉及到不同參與者之間的交互，都可以使用序列圖，比如下面這張圖就是業務分析階段，系統建設后完成后的業務流程。
圖片
記住，在軟件設計的不同階段都可以使用序列圖。
組件圖
組件是比類更大粒度的設計元素，通常一個組件中包含多個類。組件圖有時與包圖的用途相似，通常用于描述物理組件，如JAR、DLL等。在實踐中，我們更多地使用組件圖進行模塊設計。
圖片
組件圖描述組件之間的靜態關系，主要是依賴關系。如果想要描述組件之間的動態調用關系，可以使用組件序列圖，以組件作為參與者，描述組件之間的消息調用關系。
由于組件的粒度較大，通常用于描述和設計軟件的模塊及其之間的關系。因此，在設計的早期階段就需要畫出組件圖，一般用于架構設計階段。
部署圖
部署圖描述的是軟件系統最終的物理部署情況，包括需要部署的服務器數量、關鍵組件的部署位置等。它是軟件系統最終呈現的物理藍圖，能夠讓客戶、老板和工程師清晰地了解系統的最終運行狀態，以及與現有系統和第三方服務器的關系。通過部署圖，可以預估服務器和第三方軟件的采購成本。
因此，部署圖是整個軟件設計模型中相當宏觀的一種圖，需要在設計早期就繪制。各方可以根據部署圖討論是否認可該方案，只有對部署圖達成共識，才能繼續后面的細節設計。部署圖主要用于架構設計階段，并且與組件圖要彼此呼應。
圖片
用例圖
用例圖分為業務用例和系統用例，業務用例圖主要體現在 業務分析階段， 描述一個承建系統的組織對外提供的能力，系統用例體現在需求分析階段描述系統對外提供的能力。
圖片
這張圖中，左邊是業務用例圖，右邊是系統用例圖。雖然它們的畫法相似，但它們本質上有很大的區別，具體可以查看我之前寫的這篇文章。
圖中的人形元素稱為角色，角色可以是人也可以是其他系統。由于系統的功能可能很復雜，用例圖可能僅包含其中的一小部分功能，這些功能被畫在一個矩形框內，這個矩形框是用例邊界。矩形框里面的橢圓表示單個功能，它們可以相互依賴或需要擴展。因為用例圖中的功能描述相對簡單，所以通常需要配以文字說明以形成需求文檔。
狀態圖
狀態圖用來展現單個對象生命周期中的狀態變遷。
在業務系統中，許多重要的領域對象都有相當復雜的狀態變化，比如訂單，它們可以有待付款、待審核、待發貨、待收貨、交易關閉和交易完成等各種狀態。
這些狀態變化可以在用例圖中用文本形式描述，并隨著各個用戶的不同操作而改變。但是，使用這種方法描述狀態時，狀態會分散到不同的地方，這樣可能會導致開發錯誤以及產品經理在設計時的困惑。
采用UML狀態圖可以有效地解決這些問題，因為它可以在一張圖表中展示對象的整個生命周期以及各個狀態和變遷之間的關系。比如下面的圖表展示了一個訂單從創建到交易完成的狀態變化。
圖片
狀態圖要在需求分析階段畫，描述狀態變遷的邏輯關系，在詳細設計階段也要畫，這個時候，狀態要用枚舉值表示，以指導具體的開發。
活動圖
活動圖常用于描述系統或業務流程中的動態行為。它可以清晰地展現從一個活動到另一個活動的控制流，描繪出系統或業務流程的邏輯和流程，讓開發人員更好地了解整個系統的運作方式。
在活動圖中，實心圓表示流程的開始，空心圓表示流程的結束，圓角矩形表示活動，菱形表示分支判斷。這些符號的使用能夠使活動圖更加規范化和可讀性，有助于提高系統開發的效率和質量。
圖片
此外，活動圖引入了一個重要的概念——泳道。活動圖可以根據活動的范圍，將活動根據領域、系統和角色等劃分到不同的泳道中，使流程邊界更加清晰。
流程圖也比較有普適性，可以在需求分析階段描述業務流程，也可以在架構設計階段描述子系統和組件的交互，還可以在詳細設計階段描述一個類方法內部的計算流程。
使用合適的 UML 模型構建一個設計文檔
UML 模型圖本身并不難掌握，但如何在正確的場合下用適當的 UML 模型表達設計意圖，形成一套清晰且詳細的軟件模型，并在團隊內外達成共識的設計文檔則需要注意。
根據軟件設計不同階段的需要，我們可以使用不同的模型圖進行建模。
在需求分析階段，我們可以使用用例圖、活動圖、時序圖和簡化的類圖進行領域模型抽象和關系描述。
在架構設計階段，通過組件圖、組件時序圖和部署圖描述系統物理藍圖和模塊關系。
在詳細設計階段，主要側重于類圖和類的時序圖，而對于復雜的方法邏輯，可以使用方法的活動圖進行描述。
小結
掌握類圖、時序圖、組件圖、部署圖、用例圖、狀態圖、活動圖這七種UML模型圖，根據實際場景，在需求分析、架構設計和詳細設計階段選擇并巧妙應用對應的模型圖，有助于有效地進行軟件建模和系統設計，成為一個掌控大局、指導技術團隊的優秀架構師。
要注意模型圖的規范和注釋，遵循命名規范，對模型元素進行命名，注釋模型元素的關系和屬性等，簡潔明了。此外，UML模型圖只是設計文檔的一部分，需要與其他文檔相結合，如需求文檔、設計文檔、測試文檔等，形成一個完整的設計文檔，指導軟件開發。
對于畫UML的工具，有收費的專業軟件設計工具像EA(Enterprise Architect) 、Astah和億圖，以及免費的在線工具比如draw.io，processon等，建議可以根據自身需要選擇合適的工具，同時也建議從簡單易用的工具入手。
