“4+1”視圖

“4+1”視圖是對邏輯架構進行描述，最早由 Philippe Kruchten 提出，他在1995年的《IEEE Software》上發表了題為《The 4+1 View Model of Architecture》的論文，引起了業界的極大關注，並最終被 RUP 採納，現在已經成為架構設計的結構標準。

簡介

該模型五個主要的視圖

01.“4+1”視圖模型

邏輯視圖（Logical View），設計的對象模型（使用面向對象的設計方法時）。
過程視圖（Process View），捕捉設計的並發和同步特徵。
物理視圖（Physical View），描述了軟體到硬體的映射，反映了分散式特性。
開發視圖（Development View），描述了在開發環境中軟體的靜態組織結構。
架構的描述，即所做的各種決定，可以圍繞著這四個視圖來組織，然後由一些用例 （use cases）或場景(scenarios)來說明，從而形成了第五個視圖。

邏輯架構

面向對象的分解

邏輯架構主要支持功能性需求――即在為用戶提供服務方面系統所應該提供的功能。系統分解為一系列的關鍵抽象，（大多數）來自於問題域，表現為對象或對象類的形式。它們採用抽象、封裝和繼承的原理。分解並不僅僅是為了功能分析，而且用來識別遍布系統各個部分的通用機制和設計元素。我們使用 Rational/Booch 方法來表示邏輯架構，藉助於類圖和類模板的手段 4。類圖用來顯示一個類的集合和它們的邏輯關係：關聯、使用、組合、繼承等等。相似的類可以劃分成類集合。類模板關注於單個類，它們強調主要的類操作，並且識別關鍵的對象特徵。如果需要定義對象的內部行為，則使用狀態轉換圖或狀態圖來完成。公共機制或服務可以在類功能 （class utilities）中定義。對於數據驅動程度高的應用程式，可以使用其他形式的邏輯視圖，例如 E-R 圖，來代替面向對象的方法（OO approach）。

邏輯視圖的表示法

02.邏輯視圖的表示法

邏輯視圖的標記方法來自 Booch 標記法4。當僅考慮具有架構意義的條目時，這種表示法相當簡單。特別是在這種設計級別上，大量的修飾作用不大。我們使用 Rational Rose 來支持邏輯架構的設計。

過程架構

過程分解

過程架構考慮一些非功能性的需求，如性能和可用性。它解決並發性、分布性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與過程結構相配合在一起－即在哪個控制執行緒上，對象的操作被實際執行。
過程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，過程架構可以視為一組獨立執行的通信程式（叫作“processes”）的邏輯網路，它們分布在整個一組硬體資源上，這些資源通過 LAN 或者 WAN 連線起來。多個邏輯網路可能同時並存，共享相同的物理資源。例如，獨立的邏輯網路可能用於支持離線系統與線上系統的分離，或者支持軟體的模擬版本和測試版本的共存。
過程是構成可執行單元任務的分組。過程代表了可以進行策略控制過程架構的層次（即：開始、恢復、重新配置及關閉）。另外，過程可以就處理負載的分散式增強或可用性的提高而不斷地被重複。
軟體被劃分為一系列單獨的任務。任務是獨立的控制執行緒，可以在處理節點上單獨地被調度。
接著，我們可以區別主要任務、次要任務。主要任務是可以唯一處理的架構元素；次要任務是由於實施原因而引入的局部附加任務（周期性活動、緩衝、暫停等等）。它們可以作為 Ada Task 或輕量執行緒來實施。主要任務的通訊途徑是良好定義的互動任務通信機制：基於訊息的同步或異步通信服務、遠程過程調用、事件廣播等。次要任務則以會見或共享記憶體來通信。在同一過程或處理節點上，主要任務不應對它們的分配做出任何假定。
訊息流、過程負載可以基於過程視圖來進行評估，同樣可以使用啞負載來實現“中空”的過程架構，並測量在目標系統上的性能。正如 Filarey et al. 在他的 Eurocontrol 實驗中描述的那樣。

過程視圖的表示法

03.過程視圖的表示法

我們所使用的過程視圖的表示方法是從Booch最初為 Ada 任務推薦的表示方法擴展而來。同樣，用來所使用的表示法關注在架構上具有重要意義的元素。

開發架構

子系統分解

開發架構關注軟體開發環境下實際模組的組織。軟體打包成小的程式塊（程式庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層為上一層提供良好定義的接口。
系統的開發架構用模組和子系統圖來表達，顯示了“輸出”和“輸入”關係。完整的開發架構只有當所有軟體元素被識別後才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見性。
大部分情況下，開發架構考慮的內部需求與以下幾項因素有關：開發難度、軟體管理、重用性和通用性及由工具集、程式語言所帶來的限制。開發架構視圖是各種活動的基礎，如：需求分配、團隊工作的分配（或團隊機構）、成本評估和計畫、項目進度的監控、軟體重用性、移植性和安全性。它是建立產品線的基礎。

開發視圖的表示方法

04.開發視圖的表示法

同樣，使用 Booch 方法的變形，僅考慮具有架構意義的項。

物理架構

軟體至硬體的映射

物理架構主要關注系統非功能性的需求，如可用性、可靠性（容錯性），性能（吞吐量）和可伸縮性。軟體在計算機網路或處理節點上運行，被識別的各種元素（網路、過程、任務和對象），需要被映射至不同的節點；我們希望使用不同的物理配置：一些用於開發和測試，另外一些則用於不同地點和不同客戶的部署。因此軟體至節點的映射需要高度的靈活性及對原始碼產生最小的影響。

物理視圖的表示法

05.物理視圖的表示法

大型系統中的物理視圖會變得非常混亂，所以它們可以採用多種形式，有或者沒有來自進程視圖的映射均可。

場景

綜合所有的視圖

四種視圖的元素通過數量比較少的一組重要場景（更常見的是用例）進行無縫協同工作，我們為場景描述相應的腳本（對象之間和過程之間的互動序列）。
在某種意義上場景是最重要的需求抽象，它們的設計使用對象場景圖和對象互動圖來表示。
該視圖是其他視圖的冗餘（因此“+1§），但它起到了兩個作用：
作為一項驅動因素來發現架構設計過程中的架構元素。
作為架構設計結束後的一項驗證和說明功能，既以視圖的角度來說明又作為架構原型測試的出發點。

場景的表示法

場景表示法與組件邏輯視圖非常相似（請對照圖 2），但它使用過程視圖的連線符來表示對象之間的互動（請對照圖 3），注意對象實例使用實線來表達。至於邏輯視圖，我們使用 Rational Rose 來捕獲並管理對象場景。