-
前言
架構視圖是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了於此方面無關的實體。架構視圖如同在建築學中的不同種類的藍圖。
-
背景
軟件架構文檔過分強調軟件開發的某一個方面。
架構不能解決所有風險承擔者所關注的問題。
每個軟件系統都有多個風險承擔者：最終用戶、開發人員、系統工程師、項目經理等。
軟件工程師欲使用單張視圖來捕捉所有的系統架構要點，努力地在單一視圖中表達超過其表達限度的藍圖。
使用多個併發的視圖來組織軟件架構的描述，每個視圖僅用來描述一個特定的所關注的方面的問題集合。
-
模型
軟件架構涉及到抽象、分解和組合、風格和美學。RUP4+1架構方法採用用例驅動，在軟件生命週期的各個階段對軟件進行建模，從不同視角對系統進行解讀，從而形成統一軟件過程架構描述。
用例視圖（Use Cases View）
最初稱爲場景視圖，關注最終用戶需求，爲整個技術架構的上線文環境.通常用UML用例圖和活動圖描述。
邏輯視圖（Logical view）
主要是整個系統的抽象結構表述，關注系統提供最終用戶的功能，不涉及具體的編譯即輸出和部署，通常在UML中用類圖，交互圖，時序圖來表述，類似與我們採用OOA的對象模型
處理視圖（進程視圖）（Process view）
處理視圖關注系統動態運行時，主要是進程以及相關的併發、同步、通信等問題。處理視圖和開發視圖的關係：開發視圖一般偏重程序包在編譯時期的靜態依賴關係，而這些程序運行起來之後會表現爲對象、線程、進程，處理視圖比較關注的正是這些運行時單元的交互問題，在UML中通常用活動圖表述。
物理視圖（Physical view ）
物理視圖通常也叫做部署視圖(deploymentview)，是從系統工程師解讀系統，關注軟件的物流拓撲結，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理視圖和處理視圖的關係：處理視圖特別關注目標程序的動態執行情況，而物理視圖重視目標程序的靜態位置問題；物理視圖是綜合考慮軟件系統和整個IT系統相互影響的架構視圖。
開發視圖(Development View)
描述軟件在開發環境下的靜態組織，從程序實現人員的角度透視系統，也叫做實現視圖(implementation view)。開發視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件, 在UML中用組件圖，包圖來表述。開發視圖和邏輯視圖之間可能存在一定的映射關係：比如邏輯層一般會映射到多個程序包等。
-
架構
邏輯架構：
視 角：最終用戶
關注點：功能性需求，即在爲用戶提供服務方面系統所應該提供的功能。
表示法：Booch標記法，UML（類圖、交互圖、順序圖、狀態圖），E-R圖。
系統分解爲一系列的關鍵抽象，表現爲對象或對象類的形式。它們採用抽象、封裝和繼承的原理。
分解並不僅僅是爲了功能分析，而且用來識別遍佈系統各個部分的通用機制和設計元素。
處理架構
進程是構成可執行單元任務的分組。
視 角：系統集成者
關注點：非功能性需求，如併發性、分佈性、系統完整性、容錯性。
表示法：Booch標記法，UML（活動圖、交互圖、狀態圖）。
進程架構可以在多層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視爲一組獨立執行的通信程序的邏輯網絡，它們分佈在整個一組硬件資源上，這些資源通過LAN或者WAN連接起來。多個邏輯網絡可能同時並存，共享相同的物理資源。
軟件被劃分爲一系列單獨的任務。任務是獨立的控制線程，可以在處理節點上單獨地被調度。
區別主要任務、次要任務。
開發架構：
視 角：程序員、軟件項目經理
關注點：軟件開發環境下實際模塊的組織（受開發難度、軟件管理、重用性和通用性及由工具集、編程語言所帶來的限制）。
表示法：Booch標記法，UML（包圖）。
產品線的基礎。
軟件打包成小的程序塊（程序庫或子系統），它們可以由一位或幾位開發人員來開發。
子系統可以組織成分層結構，每個層爲上一層提供良好定義的接口。
物理架構：
視 角：系統工程師
關注點：依賴於硬件的非功能性需求，如可用性、可靠性、性能吞吐量和可伸縮性等。
表示法：UML（部署圖）。
分別用於開發和測試、部署的物理配置。
軟件至節點的映射需要高度的靈活性及對源代碼產生最小的影響。
-
場景
視 角：所有視圖的用戶、評估人
關注點：系統一致性、驗收。
表示法：用例文本，UML（用例圖）。
在某種意義上場景是最重要的需求抽象。
該視圖是其他視圖的冗餘（因此“＋1”）。
場景視圖的兩個作用：
作爲一項驅動因素來發現架構設計過程中的架構元素。
作爲架構設計結束後的一項驗證和說明功能。
-
視圖關聯
Correspondence Between the Views
各視圖並不是完全正交的或獨立的。視圖的元素根據某種設計規則和啓發式方法與其他視圖中的元素相關聯。
從邏輯視圖到進程視圖 From the Logical to the Process View
在邏輯視圖中，每個對象均是主動的，具有潛在的“併發性”。爲每個對象實施各自的控制線程，在目前的技術狀況下是不現實的。對象是併發的，必須以某種抽象形式來調用它們的操作。同時使用兩種策略來決定併發的程度和定義所需的過程集合：
從內至外：由邏輯架構開始。由外至內：從物理結構開始。
其結果是將類和對象映射至一個任務集合和進程架構中的進程。
從邏輯視圖到處理視圖 From the Logical View to the Development View
邏輯視圖和處理視圖非常接近，但具有不同的關注點。項目規模越大，視圖間的差距也越大。
從處理視圖到物理視圖 From the Process View to the Physical View
進程和進程組以不同的測試和部署配置映射至可用的物理硬件。
模型的剪裁 Tailoring the Model：
並不是所有的軟件架構都需要“4＋1”個視圖。無用的視圖可以從架構描述中省略。
場景對於所有的情況均適用。
-
迭代過程
開始階段：
基於風險和優先級爲某次迭代選擇一些場景，形成“稻草人式的架構”，並對場景進行描述，以識別主要的抽象。將所發現的架構元素分佈到四個藍圖中。然後實施、測試該架構，捕獲經驗教訓。
循環階段：
重新評估風險。擴展考慮的場景，選擇能夠減輕風險或提高結構覆蓋的額外的少量場景。試着在原架構中描述這些場景，發現額外的架構元素，更新四個主要視圖。根據變更修訂現有場景，升級實現工具以支持新的場景。測試、評審視圖，捕獲經驗教訓。終止循環。
-
總結
“4+1”視圖模型是從不同的視角、使用多個併發的視圖來組織軟件架構的描述。
“4+1”視圖模型具有普遍適用性，實踐證明能在許多大型項目中成功運用。
-
思考
框架、架構和設計模式的區別？
軟件架構文檔中的視圖是否越多越好？
轉載自：
1. 軟件體系結構——4+1視圖（整理資料）
2. 軟件架構RUP 4+1 視圖模型