概念
“4+1”視圖，是指從5個不同視角來描述軟件體系結構。
“4+1”分別指：
- 邏輯視圖
- 過程視圖
- 物理視圖
- 開發視圖
- 場景/用例 視圖
邏輯架構的描述可以圍繞前四個視圖進行組織，然后結合用例或場景進行說明，形成第五個視圖。
每個視圖只關心系統的一個側面，5個視圖結合起來，才能反映系統的全部內容。
關於視圖
軟件設計可以從不同的概念角度進行描述和記錄，這些角度通常被稱為視圖。
“視圖表示軟件體系結構的一部分，它顯示軟件系統的特定屬性”
不同的視圖涉及與軟件相關的不同問題。
總之，軟件設計是由設計過程產生的多方面的產物，通常由相對獨立的正交視圖組成，可以結合建築視圖理解。
邏輯視圖
當使用面向對象的設計方法時，邏輯視圖對應設計的對象模型，常用描述方法有UML類圖、E-R圖。
邏輯架構主要支持功能需求，即系統應該為用戶提供什么樣的服務。
系統被分解成一組關鍵抽象，以對象或對象類的形式從問題中表述。
類的設計遵循抽象、封裝和繼承的原則，這種分解不僅是為了進行功能分析，也是為了理清系統各個部分的通用機制和設計元素。
過程視圖
過程架構關注設計的並發和同步方面，考慮了一些非功能性需求，比如性能和可用性。
過程視圖可以在幾個抽象層次上進行描述，每個抽象層次處理不同的關注點：
- 在最高層次上關注進程，進程分布在由LAN或WAN連接的一組硬件資源上，作為一組獨立執行的通信程序邏輯網絡。
- 多個邏輯網絡可以同時存在，共享相同的物理資源。
主要任務是通過一組定義良好的任務間通信機制進行通信：基於同步和異步消息的通信服務、遠程過程調用、事件廣播等。
次要任務是可以通過集合或共享內存進行通信，避免重大任務在同一過程或處理節點上進行配置假設。
物理視圖
物理視圖描述軟件到硬件的映射，主要反映在分布式方面。
物理架構主要考慮系統的非功能性需求，如可用性、可靠性（容錯性）、性能（吞吐量）和可擴展性。
常見物理配置：
- 測試
- 為不同站點或不同客戶部署系統
開發視圖
開發視圖描述軟件在其開發環境中的靜態組織。
開發架構的重點：
- 對軟件開發環境中實際軟件模塊進行組織
- 將軟件打包成小的程序庫，或者打包成可以由一個或少量開發人員開發的子系統
系統的開發架構由模塊和子系統圖表示，表示成“導出”和“導入”關系。只有當軟件的所有元素都被識別之后，才能描述完整的開發架構。
在很大程度上，開發架構考慮發展的便利性、軟件管理、重用或通用性，以及工具集或編程語言施加的約束。
開發視圖是需求分配的基礎，便於開發團隊分配工作，有助於成本評估和提前計划、監控項目進度、軟件重用、可移植性和安全性的推理。通過開發視圖，容易得出項目開發人員的分工配置。
實際應用中，開發視圖會在邏輯視圖的基礎上增加大量內容，比如大量接口、輔助類等。
場景/用例 視圖
架構的描述決策可以圍繞前四個視圖進行組織，然后由一些選定的用例或場景（成為第五個視圖）進行說明。
其他四個視圖中的元素，可以通過一些重要的場景或用例進行更好的展示，比如：
- 構造更符合用例的實例
- 描述一些關聯腳本，如對象之間或進程之間的交互
總結
並非所有的軟件架構都需要完整的“4+1”視圖。
無用的視圖可以從架構描述中省略，例如：
- 如果只有一個處理器，則不需要物理視圖
- 如果只有一個進程或程序，則不需要進程視圖
- 對於非常小的系統，有可能邏輯視圖和開發視圖非常相似，不需要單獨描述
場景視圖在任何情況下都有用。