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視圖方法》，上篇將較多關注“從實踐理解理論”，下篇較多關注“將理論與實踐融合”。
因為實踐需要，所以多視圖必要 架構設計就是對系統“切、切、切”，有人這麼認為。 但是，和任何複雜的事物一樣，隨著瞭解慢慢加深，我們會發現一些比較深入的問題浮現出來。 我們雖已明了“架構設計應將系統切成不同部分”，但一旦開始深入實踐，就會產生不少疑問：l 從使用者角度而言，組成系統的是各種功能的模組，這屬於架構設計的範圍嗎？（屬於）l 對開發人員來說，他們認為系統是由不同的程式包組成的，架構設計師應不應該把這些統統丟給程式員決定呢？（不應該）l 更進一步而言，運行時系統又是由進程、線程等組成的，這屬不屬於架構設計的範圍呢？（當然屬於） 同樣，我們雖已明了“架構設計應規定系統各部分之間如何互動”，但一旦開始深入實踐，又困惑於：l 在使用者看來，抽象的功能模組之間可以相互（直接或間接）調用功能服務，只有這樣才能完成最終系統需要的業務功能，這是否屬於架構設計的決策範圍呢？（屬於）l 程式類組成程式包，程式包組成程式系統，這些程式碼之間的調用等互動關係既有局部於包內的，也有跨包進行的，那麼哪些屬於架構師應該考慮的呢？（一般而言，某種層級的程式包之間的互動屬於架構設計範圍，這通常會採用定義介面的方式進行。不過，對於習慣把“介面屬於客戶”原則貫徹到代碼結構設計中去的架構師而言，以及在進行架構開發的情況下，有可能出現介面定義在特定包比較密集的情況。）l 架構可以不關心進程或線程間的通訊和並發等問題嗎？畢竟軟體系統的效能和延展性等問題於此息息相關啊。（應關心） 由此看來，由於軟體架構概念是高度抽象的，所以在軟體架構概念與實踐之間，似乎存在某種“鴻溝”——即缺失某種概念，而這種概念可以串連軟體架構的概念和實際的開發實踐需要，為不同涉眾理解和交流架構提供更專一的視角。這個概念就是：軟體架構視圖。 總結：因為實踐需求，所以多視圖必要。稍微“可視化”一點兒的概括應該是： 純理論曰架構設計即切分<---->多視圖<---->現實是架構設計涉及面廣
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視圖方法進行架構設計時需要注意兩方面的問題，以適應實際情況的需要。 一個是多個架構視圖之間的同步問題。 不同軟體架構視圖之間是獨立的嗎？不完全是。因為它們分別反映同一個軟體系統的不同設計方面，它們最終合在一起才是完整的架構設計方案，所以不同架構視圖之間勢必有相互支撐的關係。所謂保持架構視圖之間的同步，就是要保證不同視圖之間是相互解釋的、而不是相互矛盾的。 例如，邏輯架構中的一個邏輯層到了開發視圖中可能變成了幾個具體的程式包，而程式包編譯（可能還包括打包）後的目標程式的部署（對嵌入式系統可能是燒寫）是物理架構所要考慮的。再如物理架構中可能會涉及資料的分布和傳遞備份，這就需要資料架構中有相應資料的定義和結構資訊等。
從理論到實踐：視圖的數量 另一個是架構視圖的數量問題。 正如上面所討論的，視圖之間的同步是多視圖方法的“開銷”所在，因此一般而言，我們應該限制軟體架構視圖的數量。我們常常遇到的情況包括：l 有些軟體系統並不涉及持久化資料，那麼就不需要進行資料架構設計；l 運行於個人電腦之上的孤立的案頭應用，由於不涉及程式的分布問題，所有往往不需要單獨的物理架構設計；l 對於商務邏輯較簡單的軟體（它們的計算邏輯未必簡單），在實踐中常常將邏輯視圖和開發視圖合二為一，此時“邏輯層”的概念可以和“程式包”的概念等同。 當然，如果需要，可以引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策。就拿安全性來說吧，如果安全性對軟體系統來說極為關鍵，就可以引入單獨的安全架構視圖。在很大程度上，安全架構視圖是其他視圖中的安全性相關內容的彙集，例如：會話管理和授權管理等邏輯單元的引入來自邏輯視圖；採用何種第三方密碼編譯演算法包來自開發視圖；訊息的驗證和轉寄涉及到運行視圖；SSL等安全通訊協定的使用原則來自物理視圖；對資料庫採用的專有安全限制策略來自資料檢視。
總結 ¨ 項目不同角色觀察軟體架構的視角各不相同，每個視角涉及的需求和技術也不盡相同，所以將軟體架構視圖用作架構歸檔的手段是順理成章的。¨ 軟體架構視圖可以被相對獨立地分析和設計，這就使軟體架構師可以暫時撇開其它問題、專註於特定問題進行深入的分析設計。¨ 是多個視圖，不是多個架構。多個視圖組成一個架構。¨ 視圖數量由具體實踐狀況決定。
