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

◆ 軟件架構設計

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

軟件系統架構是關於軟件系統的 結構、行爲和屬性 的高級抽象。指定了軟件系統的組織結構和拓撲結構。

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

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

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

◆ 架構的模型 4+1 視圖

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

**開發視圖：**也稱爲模塊 (實現) 視圖，主要側重於軟件模塊的組織和管理。（程序員）

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

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

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

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

◆ 軟件架構風格

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

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

1. 數據流風格

批處理序列

強調數據作爲一個整體（數據必須是完整的，以整體的方式傳遞）

管道和過濾器

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

2. 調用 / 返回風格

主程序 / 子程序

計算構件作爲子程序協作工作, 由一個主程序順序地調用這些子程序, 構件通過共享存儲區交換數據. 曾經作爲結構化開發方法的主要選擇，具有結構清晰，維護方便的特點，缺點是主子程序劃分缺乏標準，較難實現不同設計人員間設計的子程序複用。

面向對象風格

面向對象在類的層次實現高度內聚，整個系統通過不同類的組合調用實現不同功能，便於類的複用，只是面向對象是一個通用風格，類的劃分不同設計人員設計結果有很大不同，對實際架構設計指導意義不大。

層次結構風格

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

3. 獨立構件風格

進程通訊

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

事件系統子風格（隱式調用 ）

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

4. 虛擬機風格

解釋器

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

基於規則的系統

基於規則的系統包括規則集、規則解釋器、規則 / 數據選擇器及工作內存。（一般用在人工智能領域和 DSS 中）

5. 倉庫風格

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

數據庫系統

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

超文本系統

主要應用於靜態網頁。

黑板風格

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

6. 閉環控制架構

過程控制

工業中的過程控制是指以溫度、壓力、流量、液位和成分等工藝參數作爲被控變量的自動控制。過程控制也稱實時控制，是計算機及時的採集檢測數據，按最佳值迅速地對控制對象進行自動控制和自動調節，如數控機牀和生產流水線的控制等。（比如空調製冷，溫度大於設定溫度製冷，小於等於時停止，一旦大於繼續運作）

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. 架構風格和設計模式的區別

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

而設計模式着眼於解決某一特定的局部問題，是一種局部解決方案的應用。例如，在很多的軟件系統中，創建對象時，希望有統一的機制對這些對象的創建進行管理，所以出現了工廠模式，創建者模式等設計模式。比如 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。

10. 擴展知識

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

來源：

https://blog.csdn.net/qq_43692950/article/details/117848595

“IT 大咖說” 歡迎廣大技術人員投稿，投稿郵箱：aliang@itdks.com

** IT 大咖說  | **** 關於版權**

**由 “IT 大咖說（ID：itdakashuo）” 原創的文章，轉載時請註明作者、出處及微信公衆號。**投稿、約稿、轉載請加微信：ITDKS10（備註：投稿），茉莉小姐姐會及時與您聯繫！

感謝您對 IT 大咖說的熱心支持！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/DgnWbZ8jfdrZmGeL0uY2mw

猜你喜歡