前言

本文參考IBM官方的軟件架構模式，并參考UML視圖建模，將軟件架構視圖—4+1模式進行了小結。關于每種視圖的參考實例，會在隨后繼續補充進去。

架構模型

一、軟件架構

軟件架構概念：將若干結構元素進行裝配，從而滿足系統主要功能和性能需求，并滿足其他非功能性需求，如可靠性、可伸縮性、可移植性和可用性。用來處理軟件高層次結構的設計和實施。

軟件架構 ＝{元素，形式，關系/約束}

軟件架構涉及到抽象、分解和組合、風格和美學。用由多個視圖或視角組成的模型來描述軟件架構，該方法稱為多重視圖方法。

使用多重視圖的目的：

基于多個并發視圖的使用情況來說明描述軟件密集型系統架構的模型。

1、使用多重視圖允許獨立地處理各"風險承擔人"：最終用戶、開發人員、系統工程師、項目經理等所關注的問題，

2、并且能夠獨立地處理功能性和非功能性需求。

?

多重視圖方法從根本上說是需求種類的復雜性所致。

?

二、需求背景

1、需求的三個層次

軟件需求包括3個不同的層次――業務需求、用戶需求和功能需求。

業務需求 （Business requirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。

用戶需求?（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。

功能需求?（functional requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求 （behavīoral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什么。注意：用戶需求不總是被轉變成功能需求。產品特性，所謂特性（feature），是指一組邏輯上相關的功能需求，它們為用戶提供某項功能，使業務目標 得以滿足。對商業軟件而言，特性則是一組能被客戶識別，并幫助他決定是否購買的需求，也就是產品說明書中用著重號標明的部分。客戶希望得到的產品特性和用戶的任務相關的需求不完全是一回事。一項特性可以包括多個用例，每個用例又要求實現多項功能需求，以便用戶能夠執行某項任務。

系統需求?（system requirement）用于描述包含有多個子系統的產品（即系統）的頂級需求。系統可以只包含軟件系統，也可以既包含軟件又包含硬件子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。

業務規則?包括企業方針、政府條例、工業標準、會計準則和計算方法等。業務規劃本身并非軟件需求，因為它們不屬于任何特定軟件系統的范圍。然而，業務規則常常會限制誰 能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源于業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。

功能需求記錄在軟件需求規格說明（SRS）中。SRS完整地描述了軟件系統的預期特性。SRS我們一般把它當作文檔，其實，SRS還可以是包含需求信息的數據庫 或電子表格；或者是存儲在商業需求管理工具中的信息；而對于小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他 相關的項目功能都要用到 SRS。

除此之外，對于需求層次，我們還有其它的分法：組織級需求->業務需求->用戶需求->功能需求（有時也叫行為需求）。在此不做一一介紹。

除了功能需求外，SRS中還包含非功能需求，包括性能指標和對質量屬性的描述。

質量屬性 （quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束可用性（usability）的質量屬性，它規定了業務需求中“有效”（efficiently）一詞的含義。

約束?（constraint）限制了開發人員設計和構建系統時的選擇范圍。約束，在產品的架構設計中，是需要被首先考慮的問題。

如果說產品的功能代表了產品的能力，那么產品的質量屬性代表了產品的品質，產品的約束代表了產品必須去滿足的或者適應的條件！用人說“用戶體驗”是產品的靈魂，對于個人級的軟件這么說或許很恰當，當對于企業級甚至是行業級的產品，其靈魂有兩個：一個是產品帶個用戶的價值，另一個是產品的品質，簡單的說，就是價值和品質。但其成為一個產品的前提應該是滿足約束，否則就不應該設計、開發、進入市場而成為一個垃圾。

三、4+1架構視圖

架構視圖是對從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了與此方面無關的實體。

架構要涵蓋的內容和決策太多，采用"分而治之"的辦法從不同視角分別設計；同時，也為軟件架構的理解、交流和歸檔提供方便。

為了最終處理大型的、富有挑戰性的架構，該模型包含五個主要的視圖：

• 邏輯視圖（Logical View），設計的對象模型（使用面向對象的設計方法時）。
• 過程視圖（Process View），捕捉設計的并發和同步特征。
• 物理視圖（Physical View），描述了軟件到硬件的映射，反映了分布式特性。
• 開發視圖（Development View），描述了在開發環境中軟件的靜態組織結構。
• 場景視圖

3.1?邏輯視圖（LogicalView）

?邏輯試圖用來描述系統的功能需求，即在為用戶提供服務方面系統所應該提供的功能。在邏輯視圖中，系統分解成一系列的功能抽象、功能分解與功能分析，這些主要來自問

題領域（ProblemDefinition)。在面向對象技術中，表現為對象或對象類的形式，采用抽象、封裝和繼承的原理。用對象模型來代表邏輯視圖，可以用類圖（Class Diagram）來描述邏輯視圖。借助于類圖和類模板的手段?，類圖用來顯示一個類的集合和它們的邏輯關系：關聯、使用、組合、繼承等。相似的類可以劃分成類集合。類模板關注于單個類，它們強調主要的類操作，并且識別關鍵的對象特征。

邏輯視圖的表示法：
　　構件(Components)：類、類服務、參數化類、類層次?
　　連接件(Connectors)：關聯、包含聚集、使用、繼承、實例化?
　　?

邏輯視圖的風格采用面向對象的風格，其主要的設計準則是試圖在整個系統中保持單一的、一致的對象模型，避免就每個場合或過程產生草率的類和機制的技術說明。

?

3.2? ?過程視圖

過程視圖（ProcessView），又稱“進程視圖”，又稱“處理視圖”。

過程架構考慮一些非功能性的需求，如性能和可用性。它解決并發性、分布性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一起，即定義邏輯視圖中的各個類的具體操作是在哪一個線程（Thread）中被執行。過程視圖側重系統的運行特性。服務于系統集成人員，方便后續性能測試

??構件：進程、簡化進程、循環進程

??連接件：消息、遠程過程調用（RPC）、雙向消息、事件廣播?。

過程視圖：關注進程、線程、對象等運行時概念，以及相關的并發、同步和通信等問題。

進程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視為一組獨立執行的通信程序（叫作"processes"）的邏輯網絡，它們分布在整個一組硬件資源上，這些資源通過 LAN 或者 WAN 連接起來。多個邏輯網絡可能同時并存，共享相同的物理資源。

接著，我們可以區別主要任務、次要任務。主要任務是可以唯一處理的架構元素；次要任務是由于實施原因而引入的局部附加任務（周期性活動、緩沖、暫停等等）。主要任務的通訊途徑是良好定義的交互任務通信機制：基于消息的同步或異步通信服務、遠程過程調用、事件廣播等。次要任務則以會見或共享內存來通信。在同一過程或處理節點上，主要任務不應對它們的分配做出任何假定。

3.3? 物理視圖

物理視圖（PhysicalView）主要描述硬件配置。服務于系統工程人員，解決系統的拓撲結構、系統安裝、通信等問題。主要考慮如何把軟件映射到硬件上，也要考慮系統性能、規模、可靠性等。可以與進程視圖一起映射。物理架構主要關注系統非功能性的需求，如可用性、可靠性（容錯性），性能（吞吐量）和可伸縮性。

軟件在計算機網絡或處理節點上運行，被識別的各種元素（網絡、過程、任務和對象），需要被映射至不同的節點；我們希望使用不同的物理配置：一些用于開發和測試，另外一些則用于不同地點和不同客戶的部署。因此軟件至節點的映射需要高度的靈活性及對源代碼產生最小的影響。

物理視圖的表示法

???構件：處理器、計算機、其它設備

???連接件：通信協議等

?

?

3.4開發視圖

開發視圖（DevelopmentView），描述了在開發環境中軟件的靜態組織結構，即關注軟件開發環境下實際模塊的組織，服務于軟件編程人員。將軟件打包成小的程序塊（程序庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層為上一層提供良好定義的接口。

系統的開發架構用模塊和子系統圖來表達，顯示了"輸出"和"輸入"關系。完整的開發架構只有當所有軟件元素被識別后才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見性。

開發視圖的風格通常是層次結構，每個層為上一層提供良好定義的接口，層次越低，通用性越好。

開發視圖的表示方法：

???構件：模塊、子系統、層

???連接件：參照相關性、模塊/過程調用

大部分情況下，開發架構考慮的內部需求與以下幾項因素有關：開發難度、軟件管理、重用性和通用性及由工具集、編程語言所帶來的限制。開發架構視圖是各種活動的基礎，如：需求分配、團隊工作的分配（或團隊機構）、成本評估和計劃、項目進度的監控、軟件重用性、移植性和安全性。它是建立產品線的基礎。

?

3.5場景視圖

場景視圖，又稱“用例視圖”，它綜合所有的視圖。用于刻畫構件之間的相互關系，將四個視圖有機地聯系起來。可以描述一個特定的視圖內的構件關系，也可以描述不同視圖間的構件關系。

四種視圖的元素通過一組重要場景（更常見的是用例）進行無縫協同工作，我們為場景描述相應的腳本（對象之間和過程之間的交互序列）。在某種意義上場景是最重要的需求抽象，它們的設計使用對象場景圖和對象交互圖來表示。

場景視圖是其他視圖的冗余（因此"＋1"），但它起到了兩個作用：

• 作為一項驅動因素來發現架構設計過程中的架構元素。
• 作為架構設計結束后的一項驗證和說明功能，既以視圖的角度來說明，又作為架構原型測試的出發點。

作為一項驅動因素，源于迭代開發中有場景驅動（scenario-driven）方法。場景驅動方法認為系統大多數關鍵的功能以場景（或 use cases）的形式被捕獲。關鍵意味著：最重要的功能，系統存在的理由，或使用頻率最高的功能，或體現了必須減輕的一些重要的技術風險。

關于驅動開發方法：

開始階段:

• 基于風險和重要性為某次迭代選擇一些場景。場景可能被歸納為對若干用戶需求的抽象。
• 形成"稻草人式的架構"。然后對場景進行"描述"，以識別主要的抽象（類、機制、過程、子系統）。
• 所發現的架構元素被分布到 4 個藍圖中：邏輯藍圖、進程藍圖、開發藍圖和物理藍圖。
• 然后實施、測試、度量該架構，這項分析可能檢測到一些缺點或潛在的增強要求。
• 捕獲經驗教訓。

循環階段:下一個迭代過程開始進行：

• 重新評估風險，
• 擴展考慮的場景選擇板。
• 選擇能減輕風險或提高結構覆蓋的額外的少量場景，

然后:

• 試著在原先的架構中描述這些場景。
• 發現額外的架構元素，或有時還需要找出適應這些場景所需的重要架構變更。
• 更新4個主要視圖：邏輯視圖、進程視圖、開發視圖和物理視圖。
• 根據變更修訂現有的場景。
• 升級實現工具（架構原型）來支持新的、擴展了的場景集合。
• 測試。如果可能的話，在實際的目標環境和負載下進行測試。
• 然后評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
• 更新設計準則和基本原理。
• 捕獲經驗教訓。

然后:

• 試著在原先的架構中描述這些場景。
• 發現額外的架構元素，或有時還需要找出適應這些場景所需的重要架構變更。
• 更新4個主要視圖：邏輯視圖、進程視圖、開發視圖和物理視圖。
• 根據變更修訂現有的場景。
• 升級實現工具（架構原型）來支持新的、擴展了的場景集合。
• 測試。如果可能的話，在實際的目標環境和負載下進行測試。
• 然后評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
• 更新設計準則和基本原理。
• 捕獲經驗教訓。

終止循環

為了實際的系統，初始的架構原型需要進行演進 。較好的情況是在經過2 次或 3 次迭代之后，結構變得穩定：主要的抽象都已被找到。子系統和過程都已經完成，以及所有的接口都已經實現。接下來則是軟件設計的范疇，這個階段可能也會用到相似的方法和過程。

?

場景視圖的表示法：

場景表示法與組件邏輯視圖非常相似，但它使用過程視圖的連接符來表示對象之間的交互，對象實例使用實線來表達。

備注：以上所有視圖的實例，在后續的文章中有附上。

四、UML中的圖和各視圖的對應關系

n?場景視圖：用例圖

n?邏輯視圖：類圖和對象圖

n?開發視圖：類圖和組件圖

n?進程視圖：順序圖、協作圖、狀態圖、活動圖、組件圖

n?部署視圖：部署圖

五、架構的文檔化

架構設計中產生的文檔可以歸結為兩種：

• 軟件架構文檔，其結構遵循"4+1"視圖（請對照下圖3，一個典型的提綱）
• 軟件設計準則，捕獲了最重要的設計決策。這些決策必須被遵守，以保持系統架構的完整性。?
  圖?3 －軟件架構文檔提綱
  ?

?

結束語

無論是否經過一次本地定制的和技術上的調整，"4＋1"視圖都能在許多大型項目中成功運用。事實上，它允許不同的"風險承擔人"找出他們就軟件架構所關心的問題。系統工程師首先接觸物理視圖，然后轉向進程視圖；最終用戶、顧客、數據分析專家從邏輯視圖入手；項目經理、軟件配置人員則從開發視圖來看待"4＋1"視圖。 在 Rational 和其他地方，提出并討論了其他系列視圖，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我們發現其他視圖通常可以歸入我們所描述的 4 個視圖中的一個。例如Cost&Schedule 視圖可以歸入開發視圖，將一個數據視圖歸入一個邏輯視圖，以及將一個執行視圖歸入進程視圖和物理視圖的組合。

表?1 － "4＋1"視圖模型一覽表

總結

以上是生活随笔為你收集整理的软件架构视图—4+1模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。