軟體架構設計-軟體架構風格、分層架構

一、軟體架構設計

軟體或計算機系統的軟體架構是該系統的一個（或多個）結構，而結構由軟體元素、元素的外部可見屬性及它們之間的關系組成，

軟體系統架構是關于軟體系統的 結構、行為和屬性 的高級抽象，指定了軟體系統的組織結構和拓撲結構，

軟體架構是可傳遞可復用的模型，架構就是體系結構，架構設計介于需求分析和軟體設計之間，架構設計就是需求分配，即滿足，需求的職責分配到組件上，

軟體架構設計是降低成本、改進質量、按時和按需交付產品的關鍵因素，架構設計能夠滿足系統的性能、可維護性等品質；能夠使得不同的利益相關人（stakeholders）達成一致的目標；能夠支持專案計劃和專案管理等活動；能夠有效地管理復雜性；等等，然而系統架構的給出必須建立在需求明確的基礎上，

軟體架構能夠在設計變更相對容易的階段，考慮系統結構的可選方案，便于技術人員與非技術人員就軟體設計進行互動，能夠展現軟體的結構、屬性與內部互動關系，但是軟體架構與用戶對系統的功能性需求沒有直接的對應關系，

二、架構的模型 4+1視圖

邏輯視圖：主要支持系統的功能需求，即系統提供給最終用戶的服務，（用戶關注）

開發視圖：也稱為模塊(實作)視圖，主要側重于軟體模塊的組織和管理，（程式員）

行程視圖：側重于系統的運行特性，主要關注一些非功能性的需求，例如系統的性能和可用性，（并發，集成人員）

物理視圖：主要考慮如何把軟體映射到硬體上，它通常要考慮到解決系統拓撲結構、系統安裝、通信等問題，（軟體到硬體，系統工程人員）

場景：可以看作是那些重要系統活動的抽象，它使四個視圖有機地聯系起來，從某種意義上說，場景是最重要的需求抽象，（用例圖）

邏輯視圖和開發視圖描述系統的靜態結構，而行程視圖和物理視圖描述系統的動態結構，

三、軟體架構風格

軟體架構風格是描述特定軟體系統組織方式的慣用模式，組織方式描述了系統的組成構件和這些構件的組織方式；慣用模式則反映眾多系統共有的結構和語意特性，強調對軟體設計的重用，

架構風格定義一個系統家族，即一個架構定義一個詞匯表和一組約束，詞匯表中包含一些構件和連接件型別，而這組約束指出系統是如何將這些構件和連接件組合起來的，架構風格反映了領域中眾多系統所共有的結構和語意特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統，對軟體架構風格的研究和實踐促進對設計的重用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題，例如，如果某人把系統描述為“客戶/服務器”模式，則不必給出設計細節，我們立刻會明白系統是如何組織和作業的，

1. 資料流風格

1. 批處理序列

   強調資料作為一個整體（資料必須是完整的，以整體的方式傳遞）

2. 管道和過濾器

   每個構件都有一組輸入和輸出,構件讀輸入的資料流，經過內部處理，然后產生輸出資料流. (構件–>過濾器;連接件–>管道) （資料流的形式）

2. 呼叫/回傳風格

1. 主程式/子程式

   計算構件作為子程式協作作業,由一個主程式順序地呼叫這些子程式,構件通過共享存盤區交換資料. 曾經作為結構化開發方法的主要選擇，具有結構清晰，維護方便的特點，缺點是主子程式劃分缺乏標準，較難實作不同設計人員間設計的子程式復用，

2. 面向物件風格

   面向物件在類的層次實作高度內聚，整個系統通過不同類的組合呼叫實作不同功能，便于類的復用，只是面向物件是一個通用風格，類的劃分不同設計人員設計結果有很大不同，對實際架構設計指導意義不大，

3. 層次結構風格

   分層結構將整個系統按照抽象層次不同分為多層，每個層次的程式只需要負責與相鄰的上下兩層打交道，簡化了系統中呼叫關系復雜度，允許每層用不同的方法實作，為軟體重用提供了強大的支持，（二層C/S、三層C/S、MVC、MVP、MVVP、RIA富互聯網應用）

3. 獨立構件風格

1. 行程通訊

   行程通訊架構將系統建設成一個個獨立構件，構件間采用命名的訊息傳遞來實作溝通與協作，

2. 事件系統子風格（隱式呼叫 ）

   事件驅動架構風格與行程通訊風格類似，也是將系統分各個為獨立的構件，不同的是不同構件間通訊不采用命名的訊息，而是采用隱式呼叫的方式，先將一個個構件的程序注冊到某個事件中，當這個事件發生時，所有注冊到該事件的程序自動被觸發執行，這類風格的好處是獨立構件間耦合度進一步降低，方便構件修改及替換，缺點是觸發事件放棄了對被觸發執行程式組的控制，

4. 虛擬機風格

1. 解釋器

   具有運行時系統行為 (自)定義與改變能力 ，如專家系統，

2. 基于規則的系統

   基于規則的系統包括規則集、規則解釋器、規則/資料選擇器及作業記憶體，（一般用在人工智能領域和DSS中）

5. 倉庫風格

在倉庫風格中，有兩種不同的構件：中央資料結構說明當前狀態，獨立構件在中央資料存盤上執行，

1. 資料庫系統

   構件主要有兩大類,一個是中央共享資料源,保存當前系統的資料狀態,另一個是多個獨立處理元素,處理元素對資料元素進行操作，中央資料庫管理系統通過自身機制如資料排它鎖，共享鎖等，實作資料高速訪問，資料一致性，資料完整性，同時各獨立資料處理單元之間互相不受約束， (如編譯器，傳統編譯器采用批處理架構，現代編譯器采用資料共享架構風格，分析樹是共享資料，)

2. 超文本系統

   主要應用于靜態網頁，

3. 黑板風格

   由一個作為全域共享資料的黑板，一個控制單元和多個知識源組成，主要應用與專家問題解決系統，通過專家知識和反饋逐步得到正確結果. (如語音識別)

6. 倍訓控制架構

1. 程序控制

   工業中的程序控制是指以溫度、壓力、流量、液位和成分等工藝引數作為被控變數的自動控制，程序控制也稱實時控制，是計算機及時的采集檢測資料，按最佳值迅速地對控制物件進行自動控制和自動調節，如數控機床和生產流水線的控制等，（比如空調制冷，溫度大于設定溫度制冷，小于等于時停止，一旦大于繼續運作）

2. C2
   

   通過連接件系結在一起按照一組規則運作的并行構件，

   1. 構建和連接件都有一個頂部和一個底部
   2. 構建的頂部都要連接連接件的底部，構建的底部都要連接連接件的頂部，構建 之間不允許直連，
   3. 一個連接進行直接連接時，必須有其中一個的底部到另一個的頂部，

四、分層C/S架構風格演化

1. 二層 C/S

1. 二層 C/S 結構為單一服務器且以局域網為中心，所以難以擴展至大型企業廣域網或Internet；(使用范圍)
2. 軟、硬體的組合及集成能力有限；(擴展性)
3. 服務器的負荷太重，難以管理大量的客戶機，系統的性能容易變壞；(性能)
4. 資料安全性不好，因為客戶端程式可以直接訪問資料庫服務器，那么，在客戶端計算機上的其他程式也可想辦法訪問資料庫服務器，從而使資料庫的安全性受到威脅，(安全)

2. 三層C/S架構

1. 表現層（Web層）
   負責接收客戶端請求，向客戶端回應結果，通常客戶端使用http協議請求 web，web層需要接收 http請求，完成http回應，
   表現層包括展示層和控制層：控制層負責接收請求，展示層負責結果的展示，
   表現層依賴業務層，接收到客戶端請求一般會呼叫業務層進行業務處理，并將處理結果回應給客戶端，
   表現層的設計一般都使用 MVC 模型， MVC 是表現層的設計模型，和其他層沒有關系，
2. 業務層 （Service層）
   它負責業務邏輯處理，和我們開發專案的需求息息相關，web層依賴業務層，但是業務層不依賴Web層，
   業務層在業務處理時可能會依賴持久層，如果要對資料持久化需要保證事務一致性， (事務應該放到業務層來控制）
3. 持久層 （dao 層）
   負責資料持久化，包括資料層即資料庫和資料訪問層，資料庫是對資料進行持久化的載體，資料訪問層是業務層和持久層互動的介面；業務層需要通過資料訪問層將資料持久化到資料庫中，
   持久層就是和資料庫互動，對資料庫表進行增刪改査的，

優點:

（1）允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統和軟體的可維護性和可擴展性，(邏輯獨立清晰, 可維護性/可擴展性)

（2）允許更靈活有效地選用相應的平臺和硬體系統，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性，(可升級性/開放性)

（3）三層C/S架構中，應用的各層可以并行開發，各層也可以選擇各自最適合的開發語言，使之能并行地而且是高效地進行開發，達到較高的性能價格比；對每一層的處理邏輯的開發和維護也會更容易些，(開發維護成本/速度/技術門檻)

（4）允許充分利用功能層有效地隔離開表示層與資料層，未授權的用戶難以繞過功能層而利用資料庫工具或黑客手段去非法地訪問資料層，這就為嚴格的安全管理奠定了堅實的基礎；整個系統的管理層次也更加合理和可控制，(安全)

3. 三層B/S架構

用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級，(客戶端)

基于B/S架構的軟體，系統安裝、修改和維護全在服務器端解決，(服務端)

B/S架構還提供了異種機、異種網、異種應用服務的聯機、聯網、統一服務的最現實的開放性基礎，(開放性)

缺點:

1. B/S架構缺乏對動態頁面的支持能力，沒有集成有效的資料庫處理功能，
2. B/S架構的系統擴展能力差，安全性難以控制，
3. 采用B/S架構的應用系統，在資料查詢等回應速度上，要遠遠地低于C/S架構，(性能)
4. B/S架構的資料提交一般以頁面為單位，資料的動態互動性不強，不利于OLTP應用.

五、MVC的架構風格

MVC 全名是 Model ViewController，是模型(model)－視圖(view)－控制器(controller)的縮寫，它是分層架構風格的一種，主要解決 將與 UI 相關的邏輯都定義在針對視圖的相關元素的事件上 的問題，

MVC 中各個部分的分工與協作：

1. Model 是對應用狀態和業務功能的封裝，我們可以將它理解為同時包含資料和行為的領域模型，Model 接受 Controller 的請求并完成相應的業務處理，在狀態改變的時候向 View 發出相應的通知，
2. View 實作可視化界面的呈現并捕捉最終用戶的互動操作（例如滑鼠和鍵盤的操作），
3. View 捕獲到用戶互動操作后會直接轉發給 Controller，后者完成相應的 UI 邏輯，如果需要涉及業務功能的呼叫，Controller 會直接呼叫 Model，在完成 UI 處理后，Controller 會根據需要控制原 View 或者創建新的 View 對用戶互動操作予以回應，

六、MVP 的架構風格

MVP 是從經典的模式 MVC 演變而來，它們的基本思想有相通的地方：Controller/Presenter 負責邏輯的處理，Model 提供資料，View 負責顯示，

當然 MVP 與 MVC 也有一些顯著的區別，MVC 模式中元素之間“混亂”的互動主要體現在允許 View 和 Model 直接進行“交流”，這在 MVP 模式中是不允許的，在 MVP 中 View 并不直接使用 Model，它們之間的通信是通過 Presenter （MVC 中的 Controller）來進行的，所有的互動都發生在 Presenter 內部，而在 MVC 中 View 會直接從 Model 中讀取資料而不是通過 Controller，從而避免了 View 和 Model 之間的耦合，

擴展：

1. MVVM架構

2. 富互聯網應用（RIA）

3. 分布式架構

客戶機/服務器系統開發時可以采用不同的分布式計算架構：

1. 分布式表示架構是將表示層和表示邏輯層遷移到客戶機，應用邏輯層、資料處理層和資料層仍保留在服務器上；
2. 分布式資料架構是將資料層和資料處理層放置于服務器，應用邏輯層、表示邏輯層和表示層放置于客戶機；
3. 分布式資料和應用架構資料層和資料處理層放置在資料服務器上，應用邏輯層放置在應用服務器上，表示邏輯層和表示層放置在客戶機，

4. ANSI

在ANSI/IEEE 1471-2000標準中，系統是為了達成利益相關人（Stakeholder）的某些使命（Mission），在特定環境（Enviroment）中構建的，每一個系統都有一個架構（Architecture），架構（Architecture）是對所有利益相關人的關注點（Concern）的回應和回答，通過架構描述（Architecture Description）來說明，每一個利益相關人都有各自的關注點，這些關注點是指對其重要的，與系統的開發、運營或其他方面相關的利益，架構描述（Architecture Description）本質上是多視圖的，每一個視圖（View）是從一個特定的視角（Viewpoint）來表述架構的某一個獨立的方面，試圖用一個單一的視圖來覆寫所有的關注點當然是最好的，但實際上這種表述方式將很難理解，視角（Viewpoint）的選擇，基于要解決哪些利益相關人的哪些關注點，它決定了用來創建視圖的語言、符號和模型等，以及任何與創建視圖相關的建模方法或者分析技術，一個視圖（View）包括一個或者多個架構模型（Model），一個模型也可能參與多個視圖，模型較文本的表述的好處在于，可以更容易的可視化、檢查、分析、管理和集成，

5. 需求和架構

需求和軟體架構設計面臨的是不同的物件：一個是問題空間；另一個是解空間，保持兩者的可追蹤性和轉換，一直是軟體工程領域追求的目標，

6. 架構風格和設計模式的區別

1. 架構風格往往是從全域的角度來考慮問題，他是一種獨立于實際問題的通用組織結構，例如，常用的B/S架構，在很多不同的系統中，都有應用，

2. 而設計模式著眼于解決某一特定的區域問題，是一種區域解決方案的應用，例如，在很多的軟體系統中，創建物件時，希望有統一的機制對這些物件的創建進行管理，所以出現了工廠模式，創建者模式等設計模式，比如java記憶體垃圾的回識訓制也做成了一種設計模式，

7. 軟體架構需求

軟體架構需求是指用戶對目標軟體系統在功能、行為、性能和設計約束等方面的期望，需求程序主要是獲取用戶需求，標識系統中所要用到的構件，并進行架構需求評審，其中標識構件又詳細分為生成類圖、對類圖進行分組和將類打包成構件三步，軟體架構需求并不應該包括設計構件的程序，

8. 面向構件的編程（COP）

面向構件的編程（COP）關注于如何支持建立面向構件的解決方案，一個基于一般 OOP 風格的 COP 定義如下（Szyperski，1995）： “面向構件的編程需要下列基本的支持：

1. 多型性（可替代性）；
2. 模塊封裝性（高層次資訊的隱藏）；
3. 后期的系結和裝載（部署獨立性）；
4. 安全性（型別和模塊安全性），”

系統構件組裝分為三個不同的層次：定制（ Customization）、集成（Integration）、擴展（Extension），這三個層次對應于構件組裝程序中的不同任務，

9. OMG介面定義語言IDL

IDL 是一種介面定義語言，具體的定義會涉及到介面以及相關部分，檔案包含的主要元素有：介面描述、模塊定義、型別定義、常量定義、例外、值型別，介面描述是IDL檔案中最核心的內容，

由于IDL只是一種介面定義語言，最侄訓是要落地與語言對接的，所以IDL的資料型別要與實作語言進行映射，以Java為例，IDL介面映射為Java類，而該介面的操作映射為相應的成員函式，模塊定義映射為Java 語言中的包 (Package)或C++的namespaces，

9. 擴展知識

一個軟體的架構設計是隨著技術的不斷進步而不斷變化的，以編譯器為例，其主流架構經歷了管道-過濾器到資料共享為中心的轉變程序，早期的編譯器采用管道-過濾器架構風格，以文本形式輸入的代碼被逐步轉化為各種形式，最終生成可執行代碼，早期的編譯器采用管道-過濾器架構風格，并且大多數編譯器在詞法分析時創造獨立的符號表，在其后的階段會不斷修改符號表，因此符號表并不是程式資料的一部分，現代的編譯器采用以資料共享為中心的架構風格，主要關心編譯程序中程式的中間表示，現代的編譯器采用以資料共享為中心的架構風格，分析樹是在語法分析階段結束后才產生作為語意分析的輸入，分析樹是資料中心中重要的共享資料，為后續的語意分析提供了幫助，