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