1995年，Philippe Kruchten在《IEEE Software》上發(fā)表了題為《The 4+1 View Model of Architecture》的論文，引起了業(yè)界的極大關(guān)注。
后來，Philippe Kruchten加入Rational，他的4+1視圖方法演變?yōu)橹?、為許多架構(gòu)師所熟知的“RUP 4+1視圖方法”（如下圖所示）。
概括而言：
邏輯視圖（Logical View），設(shè)計的對象模型。 進程視圖（Process View），捕捉設(shè)計的并發(fā)和同步特征。 部署視圖（Deployment View），描述了軟件到硬件的映射，反映了分布式特性。 實現(xiàn)視圖（Implementation View），描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。 用例視圖（Use-Case View），該視圖是其他視圖的冗余（因此"＋1"）。
其實，就算不專門對比業(yè)界不同的多視圖方法（本系列文章后續(xù)將談及“業(yè)界種類繁多的多視圖方法”），有經(jīng)驗的軟件從業(yè)者也會感覺到4+1視圖方法的3大特點撲面而來。
特點一，倚重OO
80年代到90年代OO技術(shù)是大有作為，例如許多人都知道C++是1985年橫空出世的。4+1視圖方法根植于Philippe Kruchten的一線架構(gòu)設(shè)計實踐，所以4+1視圖方法倚重OO并不令人奇怪。
另一方面，幾個問題很有價值：
4+1視圖方法，是OO方法的分支嗎？ OO高手，就想當然的是架構(gòu)師了嗎？ 難道大量采用C語言編程的嵌入式領(lǐng)域不需要多視圖？ ……
于是，在每個人的心里留下了一個大大的問號：OO方法 與 多視圖的架構(gòu)設(shè)計方法到底什么關(guān)系？
特點二，倚重用例
耐人尋味的“+1”。
Philippe Kruchten 4+1視圖最初的“+1”，指場景視圖（如下圖）。RUP 4+1視圖的“+1”，指用例視圖（參考上圖）。
用例技術(shù)不會和場景技術(shù)劃等號吧？
4+1視圖前后的“變遷”，為什么呢？（小沈陽味兒）
“邏輯視圖”也叫“邏輯架構(gòu)視圖”也簡稱“邏輯架構(gòu)”，但“用例架構(gòu)”怎么這么別扭呢？
邏輯視圖架構(gòu)師負責設(shè)計，用例視圖呢？
頗有影響的“用例驅(qū)動架構(gòu)設(shè)計”的說法，如何評價？
一個個頗有價值的大問號不斷出現(xiàn)，請朋友們先自己分析分析。分析時別忘了三把有用的鑰匙：
需求 = 功能 + 質(zhì)量 + 約束 用例是功能需求實際上的標準 用例涉及、但不涵蓋非功能需求
特點三，倚重建模
建模，很有用的能力。
但是，建模在架構(gòu)設(shè)計中，到底占什么地位？凡事都需建模？
總結(jié)與展望
作為“4+1視圖剖析系列”的開篇之作，本文提煉出4+1視圖方法的3大特點。一則，對新手來說，便于建立總體印象，為理解后續(xù)內(nèi)容做一下鋪墊。二則，為后續(xù)的“剖析”埋下伏筆。
本質(zhì)而言，先有實踐，后有理論。再之后，就是“理論指導實踐”、“實踐促進理論”的綿綿無止的相互作用（多少有些類似“雞和蛋”、“蛋和雞”的繞繞關(guān)系）。
作為軟件行業(yè)的從業(yè)者，若【不能從實踐理解理論、不能將理論與實踐融合】，會極大地限制個人發(fā)展。
《實踐中的4+1視圖方法》，上篇將較多關(guān)注“從實踐理解理論”，下篇較多關(guān)注“將理論與實踐融合”。
因為實踐需要，所以多視圖必要
架構(gòu)設(shè)計就是對系統(tǒng)“切、切、切”，有人這么認為。
但是，和任何復(fù)雜的事物一樣，隨著了解慢慢加深，我們會發(fā)現(xiàn)一些比較深入的問題浮現(xiàn)出來。
我們雖已明了“架構(gòu)設(shè)計應(yīng)將系統(tǒng)切成不同部分”，但一旦開始深入實踐，就會產(chǎn)生不少疑問：
從用戶角度而言，組成系統(tǒng)的是各種功能的模塊，這屬于架構(gòu)設(shè)計的范圍嗎？（屬于） 對開發(fā)人員來說，他們認為系統(tǒng)是由不同的程序包組成的，架構(gòu)設(shè)計師應(yīng)不應(yīng)該把這些統(tǒng)統(tǒng)丟給程序員決定呢？（不應(yīng)該） 更進一步而言，運行時系統(tǒng)又是由進程、線程等組成的，這屬不屬于架構(gòu)設(shè)計的范圍呢？（當然屬于）
同樣，我們雖已明了“架構(gòu)設(shè)計應(yīng)規(guī)定系統(tǒng)各部分之間如何交互”，但一旦開始深入實踐，又困惑于：
在用戶看來，抽象的功能模塊之間可以相互（直接或間接）調(diào)用功能服務(wù)，只有這樣才能完成最終系統(tǒng)需要的業(yè)務(wù)功能，這是否屬于架構(gòu)設(shè)計的決策范圍呢？（屬于） 程序類組成程序包，程序包組成程序系統(tǒng)，這些程序代碼之間的調(diào)用等交互關(guān)系既有局部于包內(nèi)的，也有跨包進行的，那么哪些屬于架構(gòu)師應(yīng)該考慮的呢？（一般而言，某種級別的程序包之間的交互屬于架構(gòu)設(shè)計范圍，這通常會采用定義接口的方式進行。不過，對于習慣把“接口屬于客戶”原則貫徹到代碼結(jié)構(gòu)設(shè)計中去的架構(gòu)師而言，以及在進行框架開發(fā)的情況下，有可能出現(xiàn)接口定義在特定包比較密集的情況。） 架構(gòu)可以不關(guān)心進程或線程間的通訊和并發(fā)等問題嗎？畢竟軟件系統(tǒng)的性能和可伸縮性等問題于此息息相關(guān)啊。（應(yīng)關(guān)心）
由此看來，由于軟件架構(gòu)概念是高度抽象的，所以在軟件架構(gòu)概念與實踐之間，似乎存在某種“鴻溝”——即缺失某種概念，而這種概念可以連接軟件架構(gòu)的概念和實際的開發(fā)實踐需要，為不同涉眾理解和交流架構(gòu)提供更專一的視角。這個概念就是：軟件架構(gòu)視圖。
總結(jié)：因為實踐需求，所以多視圖必要。稍微“可視化”一點兒的概括應(yīng)該是：
純理論曰架構(gòu)設(shè)計即切分<---->多視圖<---->現(xiàn)實是架構(gòu)設(shè)計涉及面廣
4+1視圖之父談視圖
那么，什么是軟件架構(gòu)視圖呢？Philippe Kruchten在其著作《Rational統(tǒng)一過程引論》中寫道：
一個架構(gòu)視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無關(guān)的實體。
軟件架構(gòu)的每個視圖分別關(guān)注不同的方面，針對不同的目標和用途。也就是說，架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設(shè)計；同時，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。
視圖的另眼解讀
來看一個生活中視圖的例子。我們只有一個地球，但不同的時候我們會關(guān)心世界的不同問題：例如下圖（世界人口分布圖）是社會學家關(guān)心的，而氣候?qū)W家則更關(guān)心下下圖（世界年降水量分布圖）。
世界人口分布圖（圖片來源：www.dlpd.com）
世界年降水量分布圖（圖片來源：www.dlpd.com）
其實上面就運用了“視圖”作為手段，用不同的視圖來刻畫我們這個世界的不同方面。如果你喜歡，你完全可以將“世界人口分布圖”稱為“世界的人口分布視圖”。這里引入視圖的作用在于：世界地圖的繪制者很難將不同的信息都繪制到同一幅圖中；而看地圖的人也希望有一幅地圖是專門針對他的需要的。
而且，更進一步而言，同一事物的不同視圖之間是有聯(lián)系的。對比上面兩幅圖，除了南美洲之外基本都是降水量足的地方人口較密集——多好的例子呀！于是不難理解：軟件架構(gòu)的不同視圖之間也存在相互影響。
4+1視圖如何指導架構(gòu)設(shè)計
因為實踐需要，所以多視圖必要。正如“純理論曰架構(gòu)設(shè)計即切分<---->多視圖<---->現(xiàn)實是架構(gòu)設(shè)計涉及面廣”所總結(jié)的那樣，4+1視圖方法告訴我們【通過哪些視角、每個視角關(guān)注什么】，以此指導架構(gòu)設(shè)計實踐。
RUP 4+1視圖的說法是：邏輯架構(gòu)、實現(xiàn)架構(gòu)、進程架構(gòu)、部署架構(gòu)。
Philippe Kruchten 4+1視圖的說法是：邏輯架構(gòu)、開發(fā)架構(gòu)、進程架構(gòu)、物理架構(gòu)。
本“4+1視圖剖析系列”沿用更普遍的說法：邏輯架構(gòu)、開發(fā)架構(gòu)、運行架構(gòu)、物理架構(gòu)。
邏輯架構(gòu)。邏輯架構(gòu)關(guān)注功能，不僅包括用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊、類等。
開發(fā)架構(gòu)。開發(fā)架構(gòu)關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。開發(fā)架構(gòu)和邏輯架構(gòu)之間可能存在一定的映射關(guān)系：比如邏輯架構(gòu)中的邏輯層一般會映射到開發(fā)架構(gòu)中的多個程序包；再比如開發(fā)架構(gòu)中的源碼文件可以包含邏輯架構(gòu)中的一到多個類（在C++里一個源碼文件可以包含多個類，即使在Java里一個源碼文件也可以同時包含一個類和幾個內(nèi)部類）。
運行架構(gòu)。運行架構(gòu)關(guān)注進程、線程、對象等運行時概念，以及相關(guān)的并發(fā)、同步、通信等問題。運行架構(gòu)和開發(fā)架構(gòu)的關(guān)系：開發(fā)架構(gòu)一般偏重程序包在編譯時期的靜態(tài)依賴關(guān)系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，運行架構(gòu)比較關(guān)注的是這些運行時單元的交互問題。
物理架構(gòu)。物理架構(gòu)關(guān)注“目標程序及其依賴的運行庫和系統(tǒng)軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網(wǎng)絡(luò)來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理架構(gòu)和運行架構(gòu)的關(guān)系：運行架構(gòu)特別關(guān)注目標程序的動態(tài)執(zhí)行情況，而物理架構(gòu)重視目標程序的靜態(tài)位置問題；物理架構(gòu)還要考慮軟件系統(tǒng)和包括硬件在內(nèi)的整個IT系統(tǒng)之間是如何相互影響的。
總結(jié)：一物看不清，就多角度看；多角度看一物，不同視角會相互影響。
4+1視圖方法自1995年提出至今，極大地推動了架構(gòu)領(lǐng)域的發(fā)展，但是，為什么架構(gòu)設(shè)計一線仍是壞訊頻傳呢？原因之一恰在于“用”字。
人常說：手里只有一把錘子，看什么都像釘子。
我給企業(yè)做架構(gòu)培訓時又會專門補充強調(diào)：眼里沒有釘子，手里的錘子又有什么用呢？
總之，作為一線架構(gòu)師，【方法和問題的結(jié)合】才是實踐之道。有方法，卻不能真正結(jié)合軟件一線的實際問題，則罔；有問題，卻不能以最合理的方法予以真正解決，則殆；參透方法，吃透問題，并能合理運用，才叫“架構(gòu)設(shè)計力”。熟悉王國維“三境界”說的朋友，看了下面一張培訓幻燈片，會報以會心一笑嗎？
多視圖方法--------用于解決------->交流問題
第一個問題，軟件架構(gòu)的表達與交流問題。
這是個很現(xiàn)實的問題。究其原因，由于角色和分工不同，整個軟件團隊以及客戶等涉眾各自需要掌握的技術(shù)或技能存在很大差異，為了完成各自的工作，他們需要了解整套軟件架構(gòu)決策的不同子集。
所以，軟件架構(gòu)師應(yīng)當提供不同的軟件架構(gòu)視圖，以便于交流和傳遞設(shè)計思想。例如，負責部署和運營維護的系統(tǒng)工程師最關(guān)心軟件系統(tǒng)基于何種操作系統(tǒng)之上、依賴于哪些軟件中間件、有沒有群集或備份等部署要求、駐留在不同機器上的軟件部分之間的通信協(xié)議是什么等決策；而開發(fā)人員則最關(guān)心軟件架構(gòu)方案中關(guān)于模塊劃分的決定、模塊之間的接口如何定義、甚至架構(gòu)指定的開發(fā)技術(shù)和現(xiàn)成框架是不是最流行的等問題；……不一而足。
反過來，試想所有架構(gòu)設(shè)計決策如果都混在一起表達會怎樣？如此一來，不同的角色都會看到一個過于復(fù)雜的架構(gòu)文檔；更糟糕的是，誰都覺得難以理解這一軟件架構(gòu)，畢竟，將不同涉眾關(guān)心的邏輯層（Layer）、物理層（Tier）、子系統(tǒng)、模塊、接口、進程、線程、消息、協(xié)議等概念堆砌到一起，每個涉眾都有可能看不懂了。
多視圖方法--------用于解決------->思維問題
第二個問題，軟件架構(gòu)設(shè)計的問題。
這個問題更為關(guān)鍵。軟件架構(gòu)是個復(fù)雜的整體，架構(gòu)師可以“一下子”把它想清楚嗎？當然不能。有關(guān)思維的科學研究表明，越是復(fù)雜的問題越需要分而治之的思維方式。而每個軟件架構(gòu)視圖關(guān)注軟件架構(gòu)不同的方面，使問題得以清晰化和簡化，利于軟件架構(gòu)師完成架構(gòu)設(shè)計工作。對此，Peter Herzum等人在《Business Component Factory》一書中就曾指出：
總的來說，“架構(gòu)”一詞涵蓋了軟件架構(gòu)的所有方面，這些方面緊緊地纏繞在一起，決定如何將之分割成部分和主題顯得相當主觀。既然如此，就必須引入“架構(gòu)視點”作為討論、歸檔和理解大型系統(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è)計中，會牽扯到很多概念和技術(shù)，例如邏輯層（Layer）、物理層（Tier）、子系統(tǒng)、模塊、接口、進程、線程、消息、協(xié)議等等。而利于軟件架構(gòu)視圖的方法，可以一次只圍繞少數(shù)概念和技術(shù)展開，分別著重研究軟件架構(gòu)的不同方面。
必須強調(diào)
多重視圖的軟件架構(gòu)不僅僅是架構(gòu)歸檔的方式，更是架構(gòu)設(shè)計的思維方法。
但是，筆者注意到，大多數(shù)書籍中都強調(diào)多視圖方法是軟件架構(gòu)歸檔方法、描述方法（下圖為某書目錄），卻忽視了該方法對架構(gòu)設(shè)計思維的指導作用。
更多具體書籍我就不列舉了，寫B(tài)log圖個輕松交流，太累則不長遠。
由于我職業(yè)特點的關(guān)系，大量接觸一線的架構(gòu)設(shè)計人員，我發(fā)現(xiàn)：“4+1視圖 = 架構(gòu)歸檔方法”這一觀點已貽害無窮了。許多架構(gòu)師甚至認為架構(gòu)師就是個“建模和寫文檔的活兒”。所以必須引起注意！
從理論到實踐：視圖間同步
在運用5視圖方法進行架構(gòu)設(shè)計時需要注意兩方面的問題，以適應(yīng)實際情況的需要。
一個是多個架構(gòu)視圖之間的同步問題。
不同軟件架構(gòu)視圖之間是獨立的嗎？不完全是。因為它們分別反映同一個軟件系統(tǒng)的不同設(shè)計方面，它們最終合在一起才是完整的架構(gòu)設(shè)計方案，所以不同架構(gòu)視圖之間勢必有相互支撐的關(guān)系。所謂保持架構(gòu)視圖之間的同步，就是要保證不同視圖之間是相互解釋的、而不是相互矛盾的。
例如，邏輯架構(gòu)中的一個邏輯層到了開發(fā)視圖中可能變成了幾個具體的程序包，而程序包編譯（可能還包括打包）后的目標程序的部署（對嵌入式系統(tǒng)可能是燒寫）是物理架構(gòu)所要考慮的。再如物理架構(gòu)中可能會涉及數(shù)據(jù)的分布和傳遞備份，這就需要數(shù)據(jù)架構(gòu)中有相應(yīng)數(shù)據(jù)的定義和結(jié)構(gòu)信息等。
從理論到實踐：視圖的數(shù)量
另一個是架構(gòu)視圖的數(shù)量問題。
正如上面所討論的，視圖之間的同步是多視圖方法的“開銷”所在，因此一般而言，我們應(yīng)該限制軟件架構(gòu)視圖的數(shù)量。我們常常遇到的情況包括：
有些軟件系統(tǒng)并不涉及持久化數(shù)據(jù)，那么就不需要進行數(shù)據(jù)架構(gòu)設(shè)計； 運行于個人電腦之上的孤立的桌面應(yīng)用，由于不涉及程序的分布問題，所有往往不需要單獨的物理架構(gòu)設(shè)計； 對于業(yè)務(wù)邏輯較簡單的軟件（它們的計算邏輯未必簡單），在實踐中常常將邏輯視圖和開發(fā)視圖合二為一，此時“邏輯層”的概念可以和“程序包”的概念等同。
當然，如果需要，可以引入新的架構(gòu)視圖，從而更加突出和明確地制定和表達特定方面的架構(gòu)決策。就拿安全性來說吧，如果安全性對軟件系統(tǒng)來說極為關(guān)鍵，就可以引入單獨的安全架構(gòu)視圖。在很大程度上，安全架構(gòu)視圖是其他視圖中的安全性相關(guān)內(nèi)容的匯集，例如：會話管理和授權(quán)管理等邏輯單元的引入來自邏輯視圖；采用何種第三方加密算法包來自開發(fā)視圖；消息的驗證和轉(zhuǎn)發(fā)涉及到運行視圖；SSL等安全通信協(xié)議的使用策略來自物理視圖；對數(shù)據(jù)庫采用的專有安全限制策略來自數(shù)據(jù)視圖。
總結(jié)
項目不同角色觀察軟件架構(gòu)的視角各不相同，每個視角涉及的需求和技術(shù)也不盡相同，所以將軟件架構(gòu)視圖用作架構(gòu)歸檔的手段是順理成章的。 軟件架構(gòu)視圖可以被相對獨立地分析和設(shè)計，這就使軟件架構(gòu)師可以暫時撇開其它問題、專注于特定問題進行深入的分析設(shè)計。 是多個視圖，不是多個架構(gòu)。多個視圖組成一個架構(gòu)。 視圖數(shù)量由具體實踐狀況決定。
