轉 4+1視圖方法的3大特點——4+1視圖剖析系列

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

后來，Philippe Kruchten加入Rational，他的4+1視圖方法演變為著名的、為許多架構師所熟知的“RUP 4+1視圖方法”（如下圖所示）。

概括而言：

• 邏輯視圖（Logical View），設計的對象模型。
• 進程視圖（Process View），捕捉設計的并發和同步特征。
• 部署視圖（Deployment View），描述了軟件到硬件的映射，反映了分布式特性。
• 實現視圖（Implementation View），描述了在開發環境中軟件的靜態組織結構。
• 用例視圖（Use-Case View），該視圖是其他視圖的冗余（因此"＋1"）。

其實，就算不專門對比業界不同的多視圖方法（本系列文章后續將談及“業界種類繁多的多視圖方法”），有經驗的軟件從業者也會感覺到4+1視圖方法的3大特點撲面而來。

特點一，倚重OO

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

另一方面，幾個問題很有價值：

• 4+1視圖方法，是OO方法的分支嗎？
• OO高手，就想當然的是架構師了嗎？
• 難道大量采用C語言編程的嵌入式領域不需要多視圖？
• ……

于是，在每個人的心里留下了一個大大的問號：OO方法 與 多視圖的架構設計方法到底什么關系？

特點二，倚重用例

耐人尋味的“+1”。

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

用例技術不會和場景技術劃等號吧？

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

“邏輯視圖”也叫“邏輯架構視圖”也簡稱“邏輯架構”，但“用例架構”怎么這么別扭呢？

邏輯視圖架構師負責設計，用例視圖呢？

頗有影響的“用例驅動架構設計”的說法，如何評價？

一個個頗有價值的大問號不斷出現，請朋友們先自己分析分析。分析時別忘了三把有用的鑰匙：

• 需求 = 功能 + 質量 + 約束
• 用例是功能需求實際上的標準
• 用例涉及、但不涵蓋非功能需求

特點三，倚重建模

建模，很有用的能力。

但是，建模在架構設計中，到底占什么地位？凡事都需建模？

總結與展望

作為“4+1視圖剖析系列”的開篇之作，本文提煉出4+1視圖方法的3大特點。一則，對新手來說，便于建立總體印象，為理解后續內容做一下鋪墊。二則，為后續的“剖析”埋下伏筆。

本質而言，先有實踐，后有理論。再之后，就是“理論指導實踐”、“實踐促進理論”的綿綿無止的相互作用（多少有些類似“雞和蛋”、“蛋和雞”的繞繞關系）。

作為軟件行業的從業者，若【不能從實踐理解理論、不能將理論與實踐融合】，會極大地限制個人發展。

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

因為實踐需要，所以多視圖必要

架構設計就是對系統“切、切、切”，有人這么認為。

但是，和任何復雜的事物一樣，隨著了解慢慢加深，我們會發現一些比較深入的問題浮現出來。

我們雖已明了“架構設計應將系統切成不同部分”，但一旦開始深入實踐，就會產生不少疑問：

• 從用戶角度而言，組成系統的是各種功能的模塊，這屬于架構設計的范圍嗎？（屬于）
• 對開發人員來說，他們認為系統是由不同的程序包組成的，架構設計師應不應該把這些統統丟給程序員決定呢？（不應該）
• 更進一步而言，運行時系統又是由進程、線程等組成的，這屬不屬于架構設計的范圍呢？（當然屬于）

同樣，我們雖已明了“架構設計應規定系統各部分之間如何交互”，但一旦開始深入實踐，又困惑于：

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

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

總結：因為實踐需求，所以多視圖必要。稍微“可視化”一點兒的概括應該是：

純理論曰架構設計即切分<---->多視圖<---->現實是架構設計涉及面廣

4+1視圖之父談視圖

那么，什么是軟件架構視圖呢？Philippe Kruchten在其著作《Rational統一過程引論》中寫道：

一個架構視圖是對于從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了于此方面無關的實體。

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

視圖的另眼解讀

來看一個生活中視圖的例子。我們只有一個地球，但不同的時候我們會關心世界的不同問題：例如下圖（世界人口分布圖）是社會學家關心的，而氣候學家則更關心下下圖（世界年降水量分布圖）。

世界人口分布圖（圖片來源：www.dlpd.com）

世界年降水量分布圖（圖片來源：www.dlpd.com）

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

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

4+1視圖如何指導架構設計

因為實踐需要，所以多視圖必要。正如“純理論曰架構設計即切分<---->多視圖<---->現實是架構設計涉及面廣”所總結的那樣，4+1視圖方法告訴我們【通過哪些視角、每個視角關注什么】，以此指導架構設計實踐。

RUP 4+1視圖的說法是：邏輯架構、實現架構、進程架構、部署架構。

Philippe Kruchten 4+1視圖的說法是：邏輯架構、開發架構、進程架構、物理架構。

本“4+1視圖剖析系列”沿用更普遍的說法：邏輯架構、開發架構、運行架構、物理架構。

邏輯架構。邏輯架構關注功能，不僅包括用戶可見的功能，還包括為實現用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊、類等。

開發架構。開發架構關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行于其上的系統軟件或中間件。開發架構和邏輯架構之間可能存在一定的映射關系：比如邏輯架構中的邏輯層一般會映射到開發架構中的多個程序包；再比如開發架構中的源碼文件可以包含邏輯架構中的一到多個類（在C++里一個源碼文件可以包含多個類，即使在Java里一個源碼文件也可以同時包含一個類和幾個內部類）。

運行架構。運行架構關注進程、線程、對象等運行時概念，以及相關的并發、同步、通信等問題。運行架構和開發架構的關系：開發架構一般偏重程序包在編譯時期的靜態依賴關系，而這些程序運行起來之后會表現為對象、線程、進程，運行架構比較關注的是這些運行時單元的交互問題。

物理架構。物理架構關注“目標程序及其依賴的運行庫和系統軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理架構和運行架構的關系：運行架構特別關注目標程序的動態執行情況，而物理架構重視目標程序的靜態位置問題；物理架構還要考慮軟件系統和包括硬件在內的整個IT系統之間是如何相互影響的。

總結：一物看不清，就多角度看；多角度看一物，不同視角會相互影響。

4+1視圖方法自1995年提出至今，極大地推動了架構領域的發展，但是，為什么架構設計一線仍是壞訊頻傳呢？原因之一恰在于“用”字。

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

我給企業做架構培訓時又會專門補充強調：眼里沒有釘子，手里的錘子又有什么用呢？

總之，作為一線架構師，【方法和問題的結合】才是實踐之道。有方法，卻不能真正結合軟件一線的實際問題，則罔；有問題，卻不能以最合理的方法予以真正解決，則殆；參透方法，吃透問題，并能合理運用，才叫“架構設計力”。熟悉王國維“三境界”說的朋友，看了下面一張培訓幻燈片，會報以會心一笑嗎？

多視圖方法--------用于解決------->交流問題

第一個問題，軟件架構的表達與交流問題。

這是個很現實的問題。究其原因，由于角色和分工不同，整個軟件團隊以及客戶等涉眾各自需要掌握的技術或技能存在很大差異，為了完成各自的工作，他們需要了解整套軟件架構決策的不同子集。

所以，軟件架構師應當提供不同的軟件架構視圖，以便于交流和傳遞設計思想。例如，負責部署和運營維護的系統工程師最關心軟件系統基于何種操作系統之上、依賴于哪些軟件中間件、有沒有群集或備份等部署要求、駐留在不同機器上的軟件部分之間的通信協議是什么等決策；而開發人員則最關心軟件架構方案中關于模塊劃分的決定、模塊之間的接口如何定義、甚至架構指定的開發技術和現成框架是不是最流行的等問題；……不一而足。

反過來，試想所有架構設計決策如果都混在一起表達會怎樣？如此一來，不同的角色都會看到一個過于復雜的架構文檔；更糟糕的是，誰都覺得難以理解這一軟件架構，畢竟，將不同涉眾關心的邏輯層（Layer）、物理層（Tier）、子系統、模塊、接口、進程、線程、消息、協議等概念堆砌到一起，每個涉眾都有可能看不懂了。

多視圖方法--------用于解決------->思維問題

第二個問題，軟件架構設計的問題。

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

總的來說，“架構”一詞涵蓋了軟件架構的所有方面，這些方面緊緊地纏繞在一起，決定如何將之分割成部分和主題顯得相當主觀。既然如此，就必須引入“架構視點”作為討論、歸檔和理解大型系統架構的手段（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.）。

軟件架構設計中，會牽扯到很多概念和技術，例如邏輯層（Layer）、物理層（Tier）、子系統、模塊、接口、進程、線程、消息、協議等等。而利于軟件架構視圖的方法，可以一次只圍繞少數概念和技術展開，分別著重研究軟件架構的不同方面。

必須強調

多重視圖的軟件架構不僅僅是架構歸檔的方式，更是架構設計的思維方法。

但是，筆者注意到，大多數書籍中都強調多視圖方法是軟件架構歸檔方法、描述方法（下圖為某書目錄），卻忽視了該方法對架構設計思維的指導作用。

更多具體書籍我就不列舉了，寫Blog圖個輕松交流，太累則不長遠。

由于我職業特點的關系，大量接觸一線的架構設計人員，我發現：“4+1視圖 = 架構歸檔方法”這一觀點已貽害無窮了。許多架構師甚至認為架構師就是個“建模和寫文檔的活兒”。所以必須引起注意！

從理論到實踐：視圖間同步

在運用5視圖方法進行架構設計時需要注意兩方面的問題，以適應實際情況的需要。

一個是多個架構視圖之間的同步問題。

不同軟件架構視圖之間是獨立的嗎？不完全是。因為它們分別反映同一個軟件系統的不同設計方面，它們最終合在一起才是完整的架構設計方案，所以不同架構視圖之間勢必有相互支撐的關系。所謂保持架構視圖之間的同步，就是要保證不同視圖之間是相互解釋的、而不是相互矛盾的。

例如，邏輯架構中的一個邏輯層到了開發視圖中可能變成了幾個具體的程序包，而程序包編譯（可能還包括打包）后的目標程序的部署（對嵌入式系統可能是燒寫）是物理架構所要考慮的。再如物理架構中可能會涉及數據的分布和傳遞備份，這就需要數據架構中有相應數據的定義和結構信息等。

從理論到實踐：視圖的數量

另一個是架構視圖的數量問題。

正如上面所討論的，視圖之間的同步是多視圖方法的“開銷”所在，因此一般而言，我們應該限制軟件架構視圖的數量。我們常常遇到的情況包括：

• 有些軟件系統并不涉及持久化數據，那么就不需要進行數據架構設計；
• 運行于個人電腦之上的孤立的桌面應用，由于不涉及程序的分布問題，所有往往不需要單獨的物理架構設計；
• 對于業務邏輯較簡單的軟件（它們的計算邏輯未必簡單），在實踐中常常將邏輯視圖和開發視圖合二為一，此時“邏輯層”的概念可以和“程序包”的概念等同。

當然，如果需要，可以引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策。就拿安全性來說吧，如果安全性對軟件系統來說極為關鍵，就可以引入單獨的安全架構視圖。在很大程度上，安全架構視圖是其他視圖中的安全性相關內容的匯集，例如：會話管理和授權管理等邏輯單元的引入來自邏輯視圖；采用何種第三方加密算法包來自開發視圖；消息的驗證和轉發涉及到運行視圖；SSL等安全通信協議的使用策略來自物理視圖；對數據庫采用的專有安全限制策略來自數據視圖。

總結

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