1995年，Philippe Kruchten在《IEEE Software》上發(fā)表了題為《The 4+1 View Model of Architecture》的論文，引起了業(yè)界的極大關(guān)注。

后來(lái)，Philippe Kruchten加入Rational，他的4+1視圖方法演變?yōu)橹?、為許多架構(gòu)師所熟知的“RUP 4+1視圖方法”（如下圖所示）。

概括而言：

• 邏輯視圖（Logical View），設(shè)計(jì)的對(duì)象模型。
• 進(jìn)程視圖（Process View），捕捉設(shè)計(jì)的并發(fā)和同步特征。
• 部署視圖（Deployment View），描述了軟件到硬件的映射，反映了分布式特性。
• 實(shí)現(xiàn)視圖（Implementation View），描述了在開(kāi)發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。
• 用例視圖（Use-Case View），該視圖是其他視圖的冗余（因此"＋1"）。

其實(shí)，就算不專門對(duì)比業(yè)界不同的多視圖方法（本系列文章后續(xù)將談及“業(yè)界種類繁多的多視圖方法”），有經(jīng)驗(yàn)的軟件從業(yè)者也會(huì)感覺(jué)到4+1視圖方法的3大特點(diǎn)撲面而來(lái)。

特點(diǎn)一，倚重OO

80年代到90年代OO技術(shù)是大有作為，例如許多人都知道C++是1985年橫空出世的。4+1視圖方法根植于Philippe Kruchten的一線架構(gòu)設(shè)計(jì)實(shí)踐，所以4+1視圖方法倚重OO并不令人奇怪。

另一方面，幾個(gè)問(wèn)題很有價(jià)值：

• 4+1視圖方法，是OO方法的分支嗎？
• OO高手，就想當(dāng)然的是架構(gòu)師了嗎？
• 難道大量采用C語(yǔ)言編程的嵌入式領(lǐng)域不需要多視圖？
• ……

于是，在每個(gè)人的心里留下了一個(gè)大大的問(wèn)號(hào)：OO方法 與 多視圖的架構(gòu)設(shè)計(jì)方法到底什么關(guān)系？

特點(diǎn)二，倚重用例

耐人尋味的“+1”。

Philippe Kruchten 4+1視圖最初的“+1”，指場(chǎng)景視圖（如下圖）。RUP 4+1視圖的“+1”，指用例視圖（參考上圖）。

用例技術(shù)不會(huì)和場(chǎng)景技術(shù)劃等號(hào)吧？

4+1視圖前后的“變遷”，為什么呢？（小沈陽(yáng)味兒）

“邏輯視圖”也叫“邏輯架構(gòu)視圖”也簡(jiǎn)稱“邏輯架構(gòu)”，但“用例架構(gòu)”怎么這么別扭呢？

邏輯視圖架構(gòu)師負(fù)責(zé)設(shè)計(jì)，用例視圖呢？

頗有影響的“用例驅(qū)動(dòng)架構(gòu)設(shè)計(jì)”的說(shuō)法，如何評(píng)價(jià)？

一個(gè)個(gè)頗有價(jià)值的大問(wèn)號(hào)不斷出現(xiàn)，請(qǐng)朋友們先自己分析分析。分析時(shí)別忘了三把有用的鑰匙：

• 需求 = 功能 + 質(zhì)量 + 約束
• 用例是功能需求實(shí)際上的標(biāo)準(zhǔn)
• 用例涉及、但不涵蓋非功能需求

特點(diǎn)三，倚重建模

建模，很有用的能力。

但是，建模在架構(gòu)設(shè)計(jì)中，到底占什么地位？凡事都需建模？

總結(jié)與展望

作為“4+1視圖剖析系列”的開(kāi)篇之作，本文提煉出4+1視圖方法的3大特點(diǎn)。一則，對(duì)新手來(lái)說(shuō)，便于建立總體印象，為理解后續(xù)內(nèi)容做一下鋪墊。二則，為后續(xù)的“剖析”埋下伏筆。

本質(zhì)而言，先有實(shí)踐，后有理論。再之后，就是“理論指導(dǎo)實(shí)踐”、“實(shí)踐促進(jìn)理論”的綿綿無(wú)止的相互作用（多少有些類似“雞和蛋”、“蛋和雞”的繞繞關(guān)系）。

作為軟件行業(yè)的從業(yè)者，若【不能從實(shí)踐理解理論、不能將理論與實(shí)踐融合】，會(huì)極大地限制個(gè)人發(fā)展。

《實(shí)踐中的4+1視圖方法》，上篇將較多關(guān)注“從實(shí)踐理解理論”，下篇較多關(guān)注“將理論與實(shí)踐融合”。

因?yàn)閷?shí)踐需要，所以多視圖必要

架構(gòu)設(shè)計(jì)就是對(duì)系統(tǒng)“切、切、切”，有人這么認(rèn)為。

但是，和任何復(fù)雜的事物一樣，隨著了解慢慢加深，我們會(huì)發(fā)現(xiàn)一些比較深入的問(wèn)題浮現(xiàn)出來(lái)。

我們雖已明了“架構(gòu)設(shè)計(jì)應(yīng)將系統(tǒng)切成不同部分”，但一旦開(kāi)始深入實(shí)踐，就會(huì)產(chǎn)生不少疑問(wèn)：

• 從用戶角度而言，組成系統(tǒng)的是各種功能的模塊，這屬于架構(gòu)設(shè)計(jì)的范圍嗎？（屬于）
• 對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，他們認(rèn)為系統(tǒng)是由不同的程序包組成的，架構(gòu)設(shè)計(jì)師應(yīng)不應(yīng)該把這些統(tǒng)統(tǒng)丟給程序員決定呢？（不應(yīng)該）
• 更進(jìn)一步而言，運(yùn)行時(shí)系統(tǒng)又是由進(jìn)程、線程等組成的，這屬不屬于架構(gòu)設(shè)計(jì)的范圍呢？（當(dāng)然屬于）

同樣，我們雖已明了“架構(gòu)設(shè)計(jì)應(yīng)規(guī)定系統(tǒng)各部分之間如何交互”，但一旦開(kāi)始深入實(shí)踐，又困惑于：

• 在用戶看來(lái)，抽象的功能模塊之間可以相互（直接或間接）調(diào)用功能服務(wù)，只有這樣才能完成最終系統(tǒng)需要的業(yè)務(wù)功能，這是否屬于架構(gòu)設(shè)計(jì)的決策范圍呢？（屬于）
• 程序類組成程序包，程序包組成程序系統(tǒng)，這些程序代碼之間的調(diào)用等交互關(guān)系既有局部于包內(nèi)的，也有跨包進(jìn)行的，那么哪些屬于架構(gòu)師應(yīng)該考慮的呢？（一般而言，某種級(jí)別的程序包之間的交互屬于架構(gòu)設(shè)計(jì)范圍，這通常會(huì)采用定義接口的方式進(jìn)行。不過(guò)，對(duì)于習(xí)慣把“接口屬于客戶”原則貫徹到代碼結(jié)構(gòu)設(shè)計(jì)中去的架構(gòu)師而言，以及在進(jìn)行框架開(kāi)發(fā)的情況下，有可能出現(xiàn)接口定義在特定包比較密集的情況。）
• 架構(gòu)可以不關(guān)心進(jìn)程或線程間的通訊和并發(fā)等問(wèn)題嗎？畢竟軟件系統(tǒng)的性能和可伸縮性等問(wèn)題于此息息相關(guān)啊。（應(yīng)關(guān)心）

由此看來(lái)，由于軟件架構(gòu)概念是高度抽象的，所以在軟件架構(gòu)概念與實(shí)踐之間，似乎存在某種“鴻溝”——即缺失某種概念，而這種概念可以連接軟件架構(gòu)的概念和實(shí)際的開(kāi)發(fā)實(shí)踐需要，為不同涉眾理解和交流架構(gòu)提供更專一的視角。這個(gè)概念就是：軟件架構(gòu)視圖。

總結(jié)：因?yàn)閷?shí)踐需求，所以多視圖必要。稍微“可視化”一點(diǎn)兒的概括應(yīng)該是：

純理論曰架構(gòu)設(shè)計(jì)即切分<---->多視圖<---->現(xiàn)實(shí)是架構(gòu)設(shè)計(jì)涉及面廣

4+1視圖之父談視圖

那么，什么是軟件架構(gòu)視圖呢？Philippe Kruchten在其著作《Rational統(tǒng)一過(guò)程引論》中寫道：

一個(gè)架構(gòu)視圖是對(duì)于從某一視角或某一點(diǎn)上看到的系統(tǒng)所做的簡(jiǎn)化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無(wú)關(guān)的實(shí)體。

軟件架構(gòu)的每個(gè)視圖分別關(guān)注不同的方面，針對(duì)不同的目標(biāo)和用途。也就是說(shuō)，架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過(guò)了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設(shè)計(jì)；同時(shí)，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。

視圖的另眼解讀

來(lái)看一個(gè)生活中視圖的例子。我們只有一個(gè)地球，但不同的時(shí)候我們會(huì)關(guān)心世界的不同問(wèn)題：例如下圖（世界人口分布圖）是社會(huì)學(xué)家關(guān)心的，而氣候?qū)W家則更關(guān)心下下圖（世界年降水量分布圖）。

世界人口分布圖（圖片來(lái)源：www.dlpd.com）

世界年降水量分布圖（圖片來(lái)源：www.dlpd.com）

其實(shí)上面就運(yùn)用了“視圖”作為手段，用不同的視圖來(lái)刻畫我們這個(gè)世界的不同方面。如果你喜歡，你完全可以將“世界人口分布圖”稱為“世界的人口分布視圖”。這里引入視圖的作用在于：世界地圖的繪制者很難將不同的信息都繪制到同一幅圖中；而看地圖的人也希望有一幅地圖是專門針對(duì)他的需要的。

而且，更進(jìn)一步而言，同一事物的不同視圖之間是有聯(lián)系的。對(duì)比上面兩幅圖，除了南美洲之外基本都是降水量足的地方人口較密集——多好的例子呀！于是不難理解：軟件架構(gòu)的不同視圖之間也存在相互影響。

4+1視圖如何指導(dǎo)架構(gòu)設(shè)計(jì)

因?yàn)閷?shí)踐需要，所以多視圖必要。正如“純理論曰架構(gòu)設(shè)計(jì)即切分<---->多視圖<---->現(xiàn)實(shí)是架構(gòu)設(shè)計(jì)涉及面廣”所總結(jié)的那樣，4+1視圖方法告訴我們【通過(guò)哪些視角、每個(gè)視角關(guān)注什么】，以此指導(dǎo)架構(gòu)設(shè)計(jì)實(shí)踐。

RUP 4+1視圖的說(shuō)法是：邏輯架構(gòu)、實(shí)現(xiàn)架構(gòu)、進(jìn)程架構(gòu)、部署架構(gòu)。

Philippe Kruchten 4+1視圖的說(shuō)法是：邏輯架構(gòu)、開(kāi)發(fā)架構(gòu)、進(jìn)程架構(gòu)、物理架構(gòu)。

本“4+1視圖剖析系列”沿用更普遍的說(shuō)法：邏輯架構(gòu)、開(kāi)發(fā)架構(gòu)、運(yùn)行架構(gòu)、物理架構(gòu)。

邏輯架構(gòu)。邏輯架構(gòu)關(guān)注功能，不僅包括用戶可見(jiàn)的功能，還包括為實(shí)現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊、類等。

開(kāi)發(fā)架構(gòu)。開(kāi)發(fā)架構(gòu)關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫(kù)，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。開(kāi)發(fā)架構(gòu)和邏輯架構(gòu)之間可能存在一定的映射關(guān)系：比如邏輯架構(gòu)中的邏輯層一般會(huì)映射到開(kāi)發(fā)架構(gòu)中的多個(gè)程序包；再比如開(kāi)發(fā)架構(gòu)中的源碼文件可以包含邏輯架構(gòu)中的一到多個(gè)類（在C++里一個(gè)源碼文件可以包含多個(gè)類，即使在Java里一個(gè)源碼文件也可以同時(shí)包含一個(gè)類和幾個(gè)內(nèi)部類）。

運(yùn)行架構(gòu)。運(yùn)行架構(gòu)關(guān)注進(jìn)程、線程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問(wèn)題。運(yùn)行架構(gòu)和開(kāi)發(fā)架構(gòu)的關(guān)系：開(kāi)發(fā)架構(gòu)一般偏重程序包在編譯時(shí)期的靜態(tài)依賴關(guān)系，而這些程序運(yùn)行起來(lái)之后會(huì)表現(xiàn)為對(duì)象、線程、進(jìn)程，運(yùn)行架構(gòu)比較關(guān)注的是這些運(yùn)行時(shí)單元的交互問(wèn)題。

物理架構(gòu)。物理架構(gòu)關(guān)注“目標(biāo)程序及其依賴的運(yùn)行庫(kù)和系統(tǒng)軟件”最終如何安裝或部署到物理機(jī)器，以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理架構(gòu)和運(yùn)行架構(gòu)的關(guān)系：運(yùn)行架構(gòu)特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理架構(gòu)重視目標(biāo)程序的靜態(tài)位置問(wèn)題；物理架構(gòu)還要考慮軟件系統(tǒng)和包括硬件在內(nèi)的整個(gè)IT系統(tǒng)之間是如何相互影響的。

總結(jié)：一物看不清，就多角度看；多角度看一物，不同視角會(huì)相互影響。

4+1視圖方法自1995年提出至今，極大地推動(dòng)了架構(gòu)領(lǐng)域的發(fā)展，但是，為什么架構(gòu)設(shè)計(jì)一線仍是壞訊頻傳呢？原因之一恰在于“用”字。

人常說(shuō)：手里只有一把錘子，看什么都像釘子。

我給企業(yè)做架構(gòu)培訓(xùn)時(shí)又會(huì)專門補(bǔ)充強(qiáng)調(diào)：眼里沒(méi)有釘子，手里的錘子又有什么用呢？

總之，作為一線架構(gòu)師，【方法和問(wèn)題的結(jié)合】才是實(shí)踐之道。有方法，卻不能真正結(jié)合軟件一線的實(shí)際問(wèn)題，則罔；有問(wèn)題，卻不能以最合理的方法予以真正解決，則殆；參透方法，吃透問(wèn)題，并能合理運(yùn)用，才叫“架構(gòu)設(shè)計(jì)力”。熟悉王國(guó)維“三境界”說(shuō)的朋友，看了下面一張培訓(xùn)幻燈片，會(huì)報(bào)以會(huì)心一笑嗎？

多視圖方法--------用于解決------->交流問(wèn)題

第一個(gè)問(wèn)題，軟件架構(gòu)的表達(dá)與交流問(wèn)題。

這是個(gè)很現(xiàn)實(shí)的問(wèn)題。究其原因，由于角色和分工不同，整個(gè)軟件團(tuán)隊(duì)以及客戶等涉眾各自需要掌握的技術(shù)或技能存在很大差異，為了完成各自的工作，他們需要了解整套軟件架構(gòu)決策的不同子集。

所以，軟件架構(gòu)師應(yīng)當(dāng)提供不同的軟件架構(gòu)視圖，以便于交流和傳遞設(shè)計(jì)思想。例如，負(fù)責(zé)部署和運(yùn)營(yíng)維護(hù)的系統(tǒng)工程師最關(guān)心軟件系統(tǒng)基于何種操作系統(tǒng)之上、依賴于哪些軟件中間件、有沒(méi)有群集或備份等部署要求、駐留在不同機(jī)器上的軟件部分之間的通信協(xié)議是什么等決策；而開(kāi)發(fā)人員則最關(guān)心軟件架構(gòu)方案中關(guān)于模塊劃分的決定、模塊之間的接口如何定義、甚至架構(gòu)指定的開(kāi)發(fā)技術(shù)和現(xiàn)成框架是不是最流行的等問(wèn)題；……不一而足。

反過(guò)來(lái)，試想所有架構(gòu)設(shè)計(jì)決策如果都混在一起表達(dá)會(huì)怎樣？如此一來(lái)，不同的角色都會(huì)看到一個(gè)過(guò)于復(fù)雜的架構(gòu)文檔；更糟糕的是，誰(shuí)都覺(jué)得難以理解這一軟件架構(gòu)，畢竟，將不同涉眾關(guān)心的邏輯層（Layer）、物理層（Tier）、子系統(tǒng)、模塊、接口、進(jìn)程、線程、消息、協(xié)議等概念堆砌到一起，每個(gè)涉眾都有可能看不懂了。

多視圖方法--------用于解決------->思維問(wèn)題

第二個(gè)問(wèn)題，軟件架構(gòu)設(shè)計(jì)的問(wèn)題。

這個(gè)問(wèn)題更為關(guān)鍵。軟件架構(gòu)是個(gè)復(fù)雜的整體，架構(gòu)師可以“一下子”把它想清楚嗎？當(dāng)然不能。有關(guān)思維的科學(xué)研究表明，越是復(fù)雜的問(wèn)題越需要分而治之的思維方式。而每個(gè)軟件架構(gòu)視圖關(guān)注軟件架構(gòu)不同的方面，使問(wèn)題得以清晰化和簡(jiǎn)化，利于軟件架構(gòu)師完成架構(gòu)設(shè)計(jì)工作。對(duì)此，Peter Herzum等人在《Business Component Factory》一書中就曾指出：

總的來(lái)說(shuō)，“架構(gòu)”一詞涵蓋了軟件架構(gòu)的所有方面，這些方面緊緊地纏繞在一起，決定如何將之分割成部分和主題顯得相當(dāng)主觀。既然如此，就必須引入“架構(gòu)視點(diǎn)”作為討論、歸檔和理解大型系統(tǒng)架構(gòu)的手段（Generally speaking, the term architecture can be seen as covering all aspects of a software architecture. All its aspects re deeply intertwined, and it is really a subjective decision to split it up in parts and subjects. Having said that, the usefulness of introducing architectural viewpoints is essential as a way of discussing, documenting, and mastering the architecture of large-scale systems.）。

軟件架構(gòu)設(shè)計(jì)中，會(huì)牽扯到很多概念和技術(shù)，例如邏輯層（Layer）、物理層（Tier）、子系統(tǒng)、模塊、接口、進(jìn)程、線程、消息、協(xié)議等等。而利于軟件架構(gòu)視圖的方法，可以一次只圍繞少數(shù)概念和技術(shù)展開(kāi)，分別著重研究軟件架構(gòu)的不同方面。

必須強(qiáng)調(diào)

多重視圖的軟件架構(gòu)不僅僅是架構(gòu)歸檔的方式，更是架構(gòu)設(shè)計(jì)的思維方法。

但是，筆者注意到，大多數(shù)書籍中都強(qiáng)調(diào)多視圖方法是軟件架構(gòu)歸檔方法、描述方法（下圖為某書目錄），卻忽視了該方法對(duì)架構(gòu)設(shè)計(jì)思維的指導(dǎo)作用。

更多具體書籍我就不列舉了，寫B(tài)log圖個(gè)輕松交流，太累則不長(zhǎng)遠(yuǎn)。

由于我職業(yè)特點(diǎn)的關(guān)系，大量接觸一線的架構(gòu)設(shè)計(jì)人員，我發(fā)現(xiàn)：“4+1視圖 = 架構(gòu)歸檔方法”這一觀點(diǎn)已貽害無(wú)窮了。許多架構(gòu)師甚至認(rèn)為架構(gòu)師就是個(gè)“建模和寫文檔的活兒”。所以必須引起注意！

從理論到實(shí)踐：視圖間同步

在運(yùn)用5視圖方法進(jìn)行架構(gòu)設(shè)計(jì)時(shí)需要注意兩方面的問(wèn)題，以適應(yīng)實(shí)際情況的需要。

一個(gè)是多個(gè)架構(gòu)視圖之間的同步問(wèn)題。

不同軟件架構(gòu)視圖之間是獨(dú)立的嗎？不完全是。因?yàn)樗鼈兎謩e反映同一個(gè)軟件系統(tǒng)的不同設(shè)計(jì)方面，它們最終合在一起才是完整的架構(gòu)設(shè)計(jì)方案，所以不同架構(gòu)視圖之間勢(shì)必有相互支撐的關(guān)系。所謂保持架構(gòu)視圖之間的同步，就是要保證不同視圖之間是相互解釋的、而不是相互矛盾的。

例如，邏輯架構(gòu)中的一個(gè)邏輯層到了開(kāi)發(fā)視圖中可能變成了幾個(gè)具體的程序包，而程序包編譯（可能還包括打包）后的目標(biāo)程序的部署（對(duì)嵌入式系統(tǒng)可能是燒寫）是物理架構(gòu)所要考慮的。再如物理架構(gòu)中可能會(huì)涉及數(shù)據(jù)的分布和傳遞備份，這就需要數(shù)據(jù)架構(gòu)中有相應(yīng)數(shù)據(jù)的定義和結(jié)構(gòu)信息等。

從理論到實(shí)踐：視圖的數(shù)量

另一個(gè)是架構(gòu)視圖的數(shù)量問(wèn)題。

正如上面所討論的，視圖之間的同步是多視圖方法的“開(kāi)銷”所在，因此一般而言，我們應(yīng)該限制軟件架構(gòu)視圖的數(shù)量。我們常常遇到的情況包括：

• 有些軟件系統(tǒng)并不涉及持久化數(shù)據(jù)，那么就不需要進(jìn)行數(shù)據(jù)架構(gòu)設(shè)計(jì)；
• 運(yùn)行于個(gè)人電腦之上的孤立的桌面應(yīng)用，由于不涉及程序的分布問(wèn)題，所有往往不需要單獨(dú)的物理架構(gòu)設(shè)計(jì)；
• 對(duì)于業(yè)務(wù)邏輯較簡(jiǎn)單的軟件（它們的計(jì)算邏輯未必簡(jiǎn)單），在實(shí)踐中常常將邏輯視圖和開(kāi)發(fā)視圖合二為一，此時(shí)“邏輯層”的概念可以和“程序包”的概念等同。

當(dāng)然，如果需要，可以引入新的架構(gòu)視圖，從而更加突出和明確地制定和表達(dá)特定方面的架構(gòu)決策。就拿安全性來(lái)說(shuō)吧，如果安全性對(duì)軟件系統(tǒng)來(lái)說(shuō)極為關(guān)鍵，就可以引入單獨(dú)的安全架構(gòu)視圖。在很大程度上，安全架構(gòu)視圖是其他視圖中的安全性相關(guān)內(nèi)容的匯集，例如：會(huì)話管理和授權(quán)管理等邏輯單元的引入來(lái)自邏輯視圖；采用何種第三方加密算法包來(lái)自開(kāi)發(fā)視圖；消息的驗(yàn)證和轉(zhuǎn)發(fā)涉及到運(yùn)行視圖；SSL等安全通信協(xié)議的使用策略來(lái)自物理視圖；對(duì)數(shù)據(jù)庫(kù)采用的專有安全限制策略來(lái)自數(shù)據(jù)視圖。

總結(jié)

• 項(xiàng)目不同角色觀察軟件架構(gòu)的視角各不相同，每個(gè)視角涉及的需求和技術(shù)也不盡相同，所以將軟件架構(gòu)視圖用作架構(gòu)歸檔的手段是順理成章的。
• 軟件架構(gòu)視圖可以被相對(duì)獨(dú)立地分析和設(shè)計(jì)，這就使軟件架構(gòu)師可以暫時(shí)撇開(kāi)其它問(wèn)題、專注于特定問(wèn)題進(jìn)行深入的分析設(shè)計(jì)。
• 是多個(gè)視圖，不是多個(gè)架構(gòu)。多個(gè)視圖組成一個(gè)架構(gòu)。
• 視圖數(shù)量由具體實(shí)踐狀況決定。