n 4+1視圖模型概況 Kruchten 提出了一個"4+1"視圖模型，從5個不同的視角包括包括邏輯試圖、進程視圖、物理視圖、開發視圖、場景視圖來描述軟件體系結構。每一個視圖只關心繫統的一個側面，5個試圖結合在一起才能反映系統的軟件體系結構的全部內容。如下圖： 
n 邏輯視圖（Logic View） 邏輯試圖主要是用來描述系統的功能需求，即系統提供給最終用戶的服務. 在邏輯視圖中，系統分解成一系列的功能抽象、功能分解與功能分析，這些主要來自問題領域（Problem Definition)。 在面向對象技術中，通過抽象、封裝、繼承,可以用對象模型來代表邏輯視圖，可以用類圖（Class Diagram）來描述邏輯視圖。如下圖: 構件(Components)：類、類服務、參數化類、類層次 連接件(Connectors)：關聯、包含聚集、使用、繼承、實例化 
n 開發視圖（Development/Module View) 開發視圖主要用來描述軟件模塊的組織與管理（通過程序庫或子系統）。服務於軟件編程人員， 方便後續的設計與實現。它通過系統輸入輸出關係的模型圖和子系統圖來描述。要考慮軟件的內部需求：開發的難易程度、重用的可能性，通用性，侷限性等等。開發視圖的風格通常是層次結構，層次越低，通用性越好（底層庫：Java SDK，圖像處理軟件包）。如下圖: 構件：模塊、子系統、層 連接件：參照相關性、模塊/過程調用 
n 進程視圖 進程試圖側重系統的運行特性，關注非功能性的需求（性能，可用性）。服務於系統集成人員，方便後續性能測試。強調併發性、分佈性、集成性、魯棒性（容錯）、可擴充性、吞吐量等。定義邏輯視圖中的各個類的具體操作是在哪一個線程（Thread）中被執行。 如下圖: 構件：進程、簡化進程、循環進程 連接件：未指定，消息、遠程過程調用（RPC）、雙向消息、事件廣播 
n 物理視圖 物理試圖主要描述硬件配置。服務於系統工程人員，解決系統的拓撲結構、系統安裝、通信等問題。主要考慮如何把軟件映射到硬件上，也要考慮系統性能、規模、可靠性等。可以與進程視圖一起映射。如下圖: 構件：處理器、計算機、其它設備 連接件：通信協議等 
n場景(Scenarios) 場景用於刻畫構件之間的相互關係，將四個視圖有機地聯繫起來。可以描述一個特定的視圖內的構件關係，也可以描述不同視圖間的構件關係。文本、圖形表示皆可。 n 小結 邏輯視圖、開發視圖，都主要是用來描述系統的靜態結構。 進程視圖、物理視圖，主要是用來描述系統的動態結構。 並非每個系統都必須把5個視圖都畫出來，而是各有側重。例如MIS系統側重於邏輯視圖、開發視圖，而實時控制系統則側重於進程視圖、物理視圖
通常我們選擇UML來表現各種視圖，以下列出了UML和各視圖的對應關係
4+1視圖 UML
場景視圖 use case
邏輯視圖 類圖
開發視圖 類圖，組件圖
進程視圖 無完全對應
部署視圖 部署圖
在架構設計穩定中通常不會給出較多的用例描述，這些是在需求穩定中定義。但是往往架構文檔會選擇一些用例，列入文檔中，這些用例和一些非功能性需求一起用以證明架構的有效和正確性。在邏輯視圖中用例的實現是必不可少的一節，儘管架構設計更關注非功能性需求。
融入MDA的思想
對於邏輯視圖和開發視圖所應包含的內容常常會覺得很難區分兩者間的明顯界限。邏輯視圖包含更多的分析模型與實現技術本身相關性應該較少，如業務對象模型及其擴展。而開發視圖則會與實現技術緊密相關。
隨着MDA思想的推廣，在架構設計文檔的撰寫方面也產生了影響，我們不難把MDA的PIM和邏輯視圖聯繫起來，而把MDA中的PSM和開發視圖聯繫起來。
在編寫邏輯視圖是我們應該描述與技術平臺無關的模型，而開發視圖則描述與實現技術平臺相關的模型。
如在邏輯視圖中表現的某些實體類，我們會在開發視圖中轉換爲EJB組件（實體Bean）。
這種做法不僅有利於我們編寫架構設計文檔，同時更是一種好的架構設計思考流程。
=========================================================================================
前言：
在看UML視頻的時候，看到了4+1視圖結構模型那張圖，於是乎就查了一下這都是幹什麼的，在這裏分享給大家。
內容：
（1）4+1視圖由來：
“4+1”視圖是對邏輯架構進行描述，最早由 Philippe Kruchten 提出，他在1995年的《IEEE Software》上發表了題爲
《The 4+1 View Model of Architecture》的論文，引起了業界的極大關注，並最終被 RUP 採納，現在已經成爲架構
設計的結構標準。
（2）4+1視圖介紹：
（3）UML 4+1視圖：
