01引言
在軟件開發領域， 成為一名架構師是很多程式設計師的「終極夢想」 。架構師所需具備的技術能力是多維度且全面的。但成為架構師，首要的能力一定是繪制架構圖，因為系統需要設計，設計就需要架構圖，而架構師就是那個畫架構圖的人。俗話說「一圖勝千言」，架構圖作為架構師和產品經理、開發工程師、測試工程師等各種角色之間進行溝通的語言和橋梁，其重要性不言而喻。
我們先看一張關於架構的架構圖，架構圖是描述系統主要組成部份及其關系的圖。那麽架構自身由哪些部份組成？與其相關聯的部份有哪些？這些部份之間的關系是什麽？
如上圖所示，每個系統都有一個架構，架構由架構元素和元素間關系組成，這些元素和關系又會透過架構文件來展示。架構文件需要滿足不同相關方的關註點，比如開發工程師關註程式碼如何實作；運維工程師關註系統需要多少硬件、網絡布局如何；業務方關註實作的功能有哪些；架構文件為了滿足不同的關註點，需要透過不同的架構檢視來呈現。這些架構檢視就是我們常說的架構圖，所以， 實際工作中，架構師不是要畫好一張架構圖，而是要根據不同需求，畫好很多張架構圖。
02 UML 常見的架構圖
畫架構圖的方法有很多，目前最主流的方法依然是 UML，即統一建模語言。UML 包含的圖形總共有10種，其中常用的有7種：類圖、序列圖、元件圖、部署圖、用例圖、狀態圖和活動圖。
類圖
類圖是最常見的 UML 圖形，用來描述類的特性和類之間的靜態關系。
一個類包含三個部份：類的名字、類的內容列表和類的方法列表。類之間有6種靜態關系：關聯、依賴、組合、聚合、繼承、泛化。把相關的一組類及其關系用一張圖畫出來，就是類圖，類圖範例如下圖：
時序圖
類圖之外，另一種常用的圖是時序圖，類圖描述類之間的靜態關系，時序圖則用來描述參與者之間的動態呼叫關系。
從圖中可以看出，每個參與者有一條垂直向下的生命線，這條線用虛線表示。而參與者之間的訊息從上到下表示其呼叫的前後順序關系，這正是「時序圖」這個詞的由來。每個生命線都有若幹個啟用條，也就是那些細長的矩形條，只要這個條出現，就表示參與者是啟用狀態的。
時序圖通常用於表示參與者之間的互動，這個參與者可以是類物件，也可以是更大粒度的參與者，比如元件、伺服器、子系統等。總之，只要是描述不同參與者之間互動的，都可以使用時序圖。
元件圖
元件是比類粒度更大的設計元素，一個元件中通常包含很多個類。元件圖通常用來描述物理上的元件，比如一個 JAR、一個 DLL 等等。在實踐中，我們進行模組設計的時候，用得更多的就是元件圖。
元件圖描述元件之間的靜態關系，主要是依賴關系，如果你想要描述元件之間的動態呼叫關系，可以使用元件時序圖，以元件作為參與者，描述元件之間的訊息呼叫關系。
部署圖
部署圖描述軟件系統的最終部署情況，比如需要部署多少伺服器，關鍵元件都部署在哪些伺服器上。
部署圖是軟件系統最終物理呈現的藍圖，根據部署圖，所有相關者，諸如客戶、老板、工程師都能清晰地了解到最終執行的系統在物理上是什麽樣子，和現有的系統伺服器的關系，和第三方伺服器的關系。根據部署圖，還可以估算伺服器和第三方軟件的采購成本。
因此部署圖是整個軟件設計模型中，比較宏觀的一種圖，是在設計早期就需要畫的一種模型圖。根據部署圖，各方可以討論是否對這個方案認可。只有對部署圖達成共識，才能繼續後面的細節設計。
用例圖
用例圖反映使用者和軟件系統的互動，描述系統的功能需求。
圖中小人形象的元素，被稱為角色，角色可以是人，也可以是其他的系統。系統的功能可能會很復雜，所以一張用例圖可能只包含其中一小部份功能，這些功能被一個矩形框框起來，這個矩形框被稱為用例的邊界。框裏的橢圓表示一個一個的功能，功能之間可以呼叫依賴，也可以進行功能擴充套件。
狀態圖
狀態圖用來展示單個物件生命周期的狀態變遷。
業務系統中，很多重要的領域物件都有比較復雜的狀態變遷，比如賬號，有建立狀態、啟用狀態、凍結狀態、欠費狀態等等各種狀態。此外，使用者、訂單、商品、紅包這些常見的領域模型都有多種狀態。
這些狀態的變遷描述可以在用例圖中用文字描述，隨著角色的各種操作而改變，但是用這種方式描述，狀態散亂在各處，不要說開發的時候容易搞錯，就是產品經理自己在設計的時候，也容易搞錯物件的狀態變遷。而 UML 的狀態圖可以很好地解決這一問題，一張狀態圖描述一個物件生命周期的各種狀態，及其變遷的關系。
如圖所示，在一個網約車系統中，訂單狀態有創單、派單中、已派單、行程中、已取消、待支付、已完成幾種，而每種狀態之間變遷的原因可以在圖中清楚呈現，狀態與變遷關系用一張狀態圖就可以搞定。
活動圖
活動圖主要用來描述過程邏輯和業務流程。UML 中沒有流程圖，很多時候，人們用活動圖代替流程圖。
活動圖和早期流程圖的圖形元素也很接近，實心圓代表流程開始，空心圓代表流程結束，圓角矩形表示活動，菱形表示分支判斷。
此外，活動圖引入了一個重要的概念——泳道。泳道表示一個領域範圍，有時候也被稱為子體，如上圖中三個領域範圍：酒店、區塊鏈、車輛營運公司。活動圖可以根據活動的範圍，將活動根據領域、系統和角色等劃分到不同的泳道中，使流程邊界更加清晰。
03架構圖在軟件開發周期中的套用場景與時機
在軟件開發的過程中，架構圖不僅是溝通的工具，更是指導設計與實施的關鍵藍圖。它們幫助開發團隊在需求分析、概要設計、詳細設計等各個階段中，清晰地定義系統結構、功能劃分及互動關系。對於這七種常見架構圖在軟件設計不同階段的選用原則與套用場景，我根據自己的設計實踐，有如下建議：
需求分析階段
主要是透過
用例圖
來描述系統的功能與使用場景；
對於關鍵的業務流程，可以透過
活動圖
描述；
如果在需求階段就提出要和現有的某些子系統整合，那麽可以透過
時序圖
描述新系統和原來的子系統的呼叫關系；
可以透過簡化的
類圖
進行領域模型抽象，並描述核心領域物件之間的關系；
如果某些物件內部會有復雜的狀態變化，比如使用者、訂單這些，可以用
狀態圖
進行描述。
在概要設計階段
透過
部署圖
描述系統最終的物理藍圖；
透過
元件圖
以及
元件時序圖
設計軟件主要模組及其關系；
還可以透過元件
活動圖
描述元件間的流程邏輯。
詳細設計階段
主要輸出的就是
類圖
和類的
時序圖
，指導最終的程式碼開發，
如果某個類方法內部有比較復雜的邏輯，那麽可以將這個方法的邏輯用
活動圖
進行描述。
04結語
UML 是一種 language，語言的主要用途有兩個：一個是 思考 ，一個是 交流 。所以，在思考軟件架構的時候，不妨動手把思考畫下來；當想要告訴別人你的架構設計的時候，也不妨畫一些架構圖給對方。
也正如交流的目的是為了溝通思想，而不是炫耀語法；畫架構圖的目的也是為了讓他人（包括自己）了解架構的設計，而不是畫得漂亮。 所以畫架構圖的時候，不必糾結自己畫得是不是標準、圖形元素是不是使用正確，而是要考慮你的架構圖是否準確表達了你的架構設計意圖，別人是否能正確理解。
在上面的UML圖範例中，使用了一些不規範的UML模型元素，就像說話一樣，即使你發音是有些口音、包含一些方言，但是只要對方能聽懂，就沒有問題，反而是 如果怕發音不標準而不敢說話，才可能會錯過整個世界。
