優(yōu)秀的架構(gòu)師是怎樣繪制系統(tǒng)架構(gòu)藍(lán)圖的？

1 前言

今天我們來了解一些關(guān)于軟件設(shè)計文檔的基礎(chǔ)知識，這樣你在學(xué)習(xí)后面的具體案例時，就能更加清楚地理解文檔是基于什么方式來組織的了。

首先，請你設(shè)想這樣一個場景：如果公司安排你做架構(gòu)師，要你在項目開發(fā)前期進(jìn)行軟件架構(gòu)設(shè)計，你該如何開展你的工作？如何輸出你的工作成果？如何確定你的設(shè)計是否滿足用戶需求？你是否有把握最后交付的軟件是滿足要求的？是否有把握讓團(tuán)隊每個工程師清楚自己的職責(zé)范圍并有效地完成開發(fā)工作……

這些問題其實都是軟件開發(fā)管理與技術(shù)架構(gòu)的核心訴求，而架構(gòu)師的核心工作就是做好軟件設(shè)計，解決這些訴求。這些問題搞定了，軟件的開發(fā)過程和結(jié)果也就都得到了保證。那怎么實現(xiàn)這些訴求呢？我們主要的手段就是軟件建模，以及將這些軟件模型組織成一篇有價值的軟件設(shè)計文檔。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2 軟件建模

所謂軟件建模，就是為要開發(fā)的軟件建造模型。

模型是對客觀存在的抽象，例如著名的物理學(xué)公式 E=mc2，就是質(zhì)量能量轉(zhuǎn)換的物理規(guī)律的數(shù)學(xué)模型。除了物理學(xué)公式以外，還有一些東西也是模型，比如地圖是對地理空間的建模；機(jī)械裝置、電子電路、建筑設(shè)計的各種圖紙是對物理實體的建模。而軟件，也可以通過各種圖進(jìn)行建模。

軟件系統(tǒng)龐大復(fù)雜，通過軟件建模，我們可以抽象軟件系統(tǒng)的主要特征和組成部分，梳理這些關(guān)鍵組成部分的關(guān)系。在軟件開發(fā)過程中依照模型的約束開發(fā)，系統(tǒng)整體的格局和關(guān)系就會可控。相關(guān)人員從始至終都能清晰了解軟件的藍(lán)圖和當(dāng)前的進(jìn)展，不同的開發(fā)工程師會清晰自己開發(fā)的模塊和其他同事工作內(nèi)容的關(guān)系與依賴，并按照這些模型開發(fā)代碼。

那么我們是根據(jù)什么進(jìn)行軟件建模的呢？要解答這個疑問，你需要先知道，在軟件開發(fā)中，有兩個客觀存在。

一個是我們要解決的領(lǐng)域問題。比如我們要開發(fā)一個電子商務(wù)網(wǎng)站，那么客觀的領(lǐng)域問題就是如何做生意，賣家如何管理商品、管理訂單、服務(wù)用戶，買家如何挑選商品，如何下訂單，如何支付等等。對這些客觀領(lǐng)域問題的抽象就是各種功能及其關(guān)系、各種模型對象及其關(guān)系、各種業(yè)務(wù)處理流程。

另一個客觀存在就是最終開發(fā)出來的軟件系統(tǒng)。軟件系統(tǒng)要解決的問題包括軟件由哪些主要類組成，這些類如何組織構(gòu)成一個個的組件，這些類和組件之間的依賴關(guān)系如何，運(yùn)行期如何調(diào)用，需要部署多少臺服務(wù)器，服務(wù)器之間如何通信等。

而對這兩個客觀存在進(jìn)行抽象化處理的手段，就是我們的軟件模型。

一方面我們要對領(lǐng)域問題和要設(shè)計的軟件系統(tǒng)進(jìn)行分析、設(shè)計、抽象，另一方面，我們根據(jù)抽象出來的模型進(jìn)行開發(fā)，最終實現(xiàn)出一個軟件系統(tǒng)，這就是軟件開發(fā)的主要過程。而對領(lǐng)域問題和軟件系統(tǒng)進(jìn)行分析、設(shè)計和抽象的這個過程，就是軟件建模設(shè)計。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

3 軟件設(shè)計方法

因此，軟件設(shè)計其實就是軟件建模的過程。我們通過軟件建模工具，將軟件模型畫出來，實現(xiàn)軟件設(shè)計。

在實踐中，通常用來進(jìn)行軟件建模畫圖的工具是 UML，統(tǒng)一建模語言。UML 包含的軟件模型有 10 種，其中常用的有 7 種：類圖、序列圖、組件圖、部署圖、用例圖、狀態(tài)圖和活動圖。

下面我們簡單了解下這 7 種常用 UML 圖的使用場景和基本樣例。在專欄后面的設(shè)計文檔中，你會多次見到它們，看多了，你就懂了，也就自然會畫了。當(dāng)然，如果你想更詳細(xì)地學(xué)習(xí) UML 知識，我也非常鼓勵，并且推薦你閱讀馬丁富勒的《UML 精粹》一書。

類圖

類圖是最常見的 UML 圖形，用來描述類的特性和類之間的靜態(tài)關(guān)系。

一個類包含三個部分：類的名字、類的屬性列表和類的方法列表。類之間有 6 種靜態(tài)關(guān)系：關(guān)聯(lián)、依賴、組合、聚合、繼承、泛化。把相關(guān)的一組類及其關(guān)系用一張圖畫出來，就是類圖。

比如你在后面的課程中會遇到下面這幅圖，它就是類圖。你可以把我上面說的類圖包含元素和圖片一一對照，感受類圖的用法。

時序圖

類圖之外，另一種常用的圖是時序圖，類圖描述類之間的靜態(tài)關(guān)系，時序圖則用來描述參與者之間的動態(tài)調(diào)用關(guān)系。

組件圖

組件是比類粒度更大的設(shè)計元素，一個組件中通常包含很多個類。組件圖有的時候和包圖的用途比較接近，組件圖通常用來描述物理上的組件，比如一個 JAR、一個 DLL 等等。在實踐中，我們進(jìn)行模塊設(shè)計的時候，用得更多的就是組件圖。

組件圖描述組件之間的靜態(tài)關(guān)系，主要是依賴關(guān)系，如果你想要描述組件之間的動態(tài)調(diào)用關(guān)系，可以使用組件時序圖，以組件作為參與者，描述組件之間的消息調(diào)用關(guān)系。

部署圖

部署圖描述軟件系統(tǒng)的最終部署情況，比如需要部署多少服務(wù)器，關(guān)鍵組件都部署在哪些服務(wù)器上。

部署圖是軟件系統(tǒng)最終物理呈現(xiàn)的藍(lán)圖，根據(jù)部署圖，所有相關(guān)者，諸如客戶、老板、工程師都能清晰地了解到最終運(yùn)行的系統(tǒng)在物理上是什么樣子，和現(xiàn)有的系統(tǒng)服務(wù)器的關(guān)系，和第三方服務(wù)器的關(guān)系。根據(jù)部署圖，還可以估算服務(wù)器和第三方軟件的采購成本。

因此部署圖是整個軟件設(shè)計模型中，比較宏觀的一種圖，是在設(shè)計早期就需要畫的一種模型圖。根據(jù)部署圖，各方可以討論對這個方案是否認(rèn)可。只有對部署圖達(dá)成共識，才能繼續(xù)后面的細(xì)節(jié)設(shè)計。

用例圖

用例圖通過反映用戶和軟件系統(tǒng)的交互，描述系統(tǒng)的功能需求。

圖中小人形象的元素，被稱為角色，角色可以是人，也可以是其他的系統(tǒng)。系統(tǒng)的功能可能會很復(fù)雜，所以一張用例圖可能只包含其中一小部分功能，這些功能被一個矩形框框起來，這個矩形框被稱為用例的邊界。框里的橢圓表示一個一個的功能，功能之間可以調(diào)用依賴，也可以進(jìn)行功能擴(kuò)展。

狀態(tài)圖

狀態(tài)圖用來展示單個對象生命周期的狀態(tài)變遷。

業(yè)務(wù)系統(tǒng)中，很多重要的領(lǐng)域?qū)ο蠖加斜容^復(fù)雜的狀態(tài)變遷，比如賬號，有創(chuàng)建狀態(tài)、激活狀態(tài)、凍結(jié)狀態(tài)、欠費(fèi)狀態(tài)等等各種狀態(tài)。此外，用戶、訂單、商品、紅包這些常見的領(lǐng)域模型都有多種狀態(tài)。

這些狀態(tài)的變遷描述可以在用例圖中用文字描述，隨著角色的各種操作而改變，但是用這種方式描述，狀態(tài)散亂在各處，不要說開發(fā)的時候容易搞錯，就是產(chǎn)品經(jīng)理自己在設(shè)計的時候，也容易搞錯對象的狀態(tài)變遷。

UML 的狀態(tài)圖可以很好地解決這一問題，一張狀態(tài)圖描述一個對象生命周期的各種狀態(tài)，及其變遷的關(guān)系。如圖所示，門的狀態(tài)有開 Opened、關(guān) Closed 和鎖 Locked 三種，狀態(tài)與變遷關(guān)系用一張狀態(tài)圖就可以搞定。

活動圖

活動圖主要用來描述過程邏輯和業(yè)務(wù)流程。UML 中沒有流程圖，很多時候，人們用活動圖代替流程圖。

活動圖和早期流程圖的圖形元素也很接近，實心圓代表流程開始，空心圓代表流程結(jié)束，圓角矩形表示活動，菱形表示分支判斷。

此外，活動圖引入了一個重要的概念——泳道。活動圖可以根據(jù)活動的范圍，將活動根據(jù)領(lǐng)域、系統(tǒng)和角色等劃分到不同的泳道中，使流程邊界更加清晰。

我們上面介紹了 UML 建模常用的 7 種模型，那么這 7 種模型分別應(yīng)用在軟件設(shè)計的什么階段？用來表達(dá)什么樣的設(shè)計意圖呢？

4 軟件文檔設(shè)計

軟件設(shè)計文檔就是架構(gòu)師的主要工作成果，它需要闡釋本文開頭提到的各種訴求，描繪軟件的完整藍(lán)圖，而軟件設(shè)計文檔的主要組成部分就是軟件模型。

軟件設(shè)計過程可以拆分成需求分析、概要設(shè)計和詳細(xì)設(shè)計三個階段。

在需求分析階段，主要是通過用例圖來描述系統(tǒng)的功能與使用場景；對于關(guān)鍵的業(yè)務(wù)流程，可以通過活動圖描述；如果在需求階段就提出要和現(xiàn)有的某些子系統(tǒng)整合，那么可以通過時序圖描述新系統(tǒng)和原來的子系統(tǒng)的調(diào)用關(guān)系；可以通過簡化的類圖進(jìn)行領(lǐng)域模型抽象，并描述核心領(lǐng)域?qū)ο笾g的關(guān)系；如果某些對象內(nèi)部會有復(fù)雜的狀態(tài)變化，比如用戶、訂單這些，可以用狀態(tài)圖進(jìn)行描述。

在概要設(shè)計階段，通過部署圖描述系統(tǒng)最終的物理藍(lán)圖；通過組件圖以及組件時序圖設(shè)計軟件主要模塊及其關(guān)系；還可以通過組件活動圖描述組件間的流程邏輯。

在詳細(xì)設(shè)計階段，主要輸出的就是類圖和類的時序圖，指導(dǎo)最終的代碼開發(fā)，如果某個類方法內(nèi)部有比較復(fù)雜的邏輯，那么可以將這個方法的邏輯用活動圖進(jìn)行描述。

我們在每個設(shè)計階段使用幾種 UML 模型對領(lǐng)域或者系統(tǒng)進(jìn)行建模，然后將這些模型配上必要的文字說明寫入到文檔中，就可以構(gòu)成一篇軟件設(shè)計文檔了。

我們專欄中的十幾講軟件設(shè)計案例，都是按照這樣的方式組織的，你可以在學(xué)習(xí)的過程中，一方面了解各種系統(tǒng)軟件是如何設(shè)計的，一方面也可以借鑒設(shè)計文檔是如何寫作的。

同時也要說明一下，設(shè)計文檔的寫法并沒有一定之規(guī)，最重要的是這個文檔能否向閱讀者傳遞出架構(gòu)師完整的設(shè)計意圖。而不同的閱讀者關(guān)注點是不同的，老板、客戶、運(yùn)維、測試、開發(fā)這些角色都是設(shè)計文檔的閱讀者，他們想要看到的東西顯然是不一樣的。

客戶和測試人員可能更關(guān)注功能性需求和實現(xiàn)邏輯，老板和運(yùn)維人員可能更關(guān)注非功能需求和整體架構(gòu)，而開發(fā)人員可能更關(guān)注整體架構(gòu)與關(guān)鍵技術(shù)細(xì)節(jié)。

我們專欄的案例基本上是以開發(fā)人員作為閱讀視角進(jìn)行編寫的，你在閱讀這些案例時，會明顯感覺到我的表達(dá)方式和其他專欄文章不太一樣，措辭會更“堅硬”一點，文字和讀者的距離也有點“疏離”，而這正是設(shè)計文檔自身的特質(zhì)。

架構(gòu)、系統(tǒng)，文檔、相關(guān)人員之間的關(guān)系可以參考下面這張圖。

每個軟件系統(tǒng)都需要有一個架構(gòu)，每個架構(gòu)都包含若干架構(gòu)元素。架構(gòu)元素就是前面提到的服務(wù)器、組件、類、消息、用例、狀態(tài)等等。這些元素之間的關(guān)系是什么？如何把它們組織在一起？我們可以用部署圖、組件圖、時序圖等各種模型圖來描述。

架構(gòu)最終需要一個文檔來承載，把這些模型圖放進(jìn)這個文檔，再配以適當(dāng)?shù)奈淖终f明，就是一篇架構(gòu)設(shè)計文檔。而設(shè)計文檔是給人閱讀的，這些人就是系統(tǒng)的相關(guān)方。不同的相關(guān)方關(guān)注點不同，也需要由不同的模型圖來進(jìn)行表達(dá)，所以架構(gòu)師應(yīng)該針對不同的相關(guān)方，使用不同的模型圖輸出不同的架構(gòu)文檔。

5 小結(jié)

軟件設(shè)計就是在軟件開發(fā)之前，對要解決的業(yè)務(wù)問題和對要實現(xiàn)的軟件系統(tǒng)進(jìn)行思考，并將這個思考的結(jié)果通過軟件模型表達(dá)出來的過程。

人類作為萬物之靈，最大的特點就是，在行動之前就已經(jīng)在頭腦中將行動的過程和行動的結(jié)果構(gòu)建成了一個藍(lán)圖，然后將這個藍(lán)圖付諸實踐。我們的祖先將第一塊石頭打磨成石器的時候，就已經(jīng)擁有了這種能力。軟件系統(tǒng)的開發(fā)是一個復(fù)雜的智力活動，參與其中的我們更需要擁有構(gòu)建藍(lán)圖并付諸實踐的能力。

目前有個很火的詞叫“元宇宙”，“元”通俗地講，就是一切開始的地方，是關(guān)于如何用自己描述自己，是抽象之上的抽象。這種“元”能力對架構(gòu)師而言，非常重要。架構(gòu)師只有掌握各種技術(shù)背后的技術(shù)，了解各種問題背后的問題，才能超越當(dāng)下的種種羈絆，設(shè)計出面向未來的架構(gòu)。