---

前言

學者們提出了軟件架構(SofwareArchitecture)的概念，并試圖在軟件需求與設計之間架起一座橋梁，·重點解決系統結構和需求向實現平坦過渡的問題。

12.1 軟件架構概述

• 軟件架構研究的主要內容涉及軟件架構描述、軟件架構風格、軟件架構評估和軟件架構的形式化方法等。

• 解決好軟件的復用、質量和維護問題，是研究軟件架構的根本目的。

12.1.1 軟件架構的意義

1. 架構是項目干系人進行交流的手段
2. 架構是早期設計決策的體現
3. 架構明確了對系統實現的約束條件
4. 架構決定了開發和維護組織的組織結構
5. 架構制約著系統的質量屬性
6. 架構使推理和控制更改更簡單
7. 架構有助于循序漸進的原型設計
8. 架構可以作為培訓的基礎
9. 架構是可傳遞和可復用的模型

12.1.2 軟件架構的發展史

縱觀軟件架構技術的發展過程，從最初的無架構設計到現行的基于架構的軟件開發。
經歷了4個階段:

1. 無架構設計階段。以匯編語言進行小規模應用程序開發為特征。（20世紀70年代以前）
2. 萌芽階段。出現了程序結構設計主題，以控制流圖和數據流圖構成軟件結構為特征。（20世紀70年代中后期）
3. 初級階段。出現了從不同側面描述系統的結構模型，以 UML為典型代表。（20世紀80年代—90年代中期）
4. 高級階段。以描述系統的高層抽象結構為中心，不關心具體的建模細節，劃分了架構模型與傳統軟件結構的界限。（20世紀90年代以后）

12.2 軟件架構建模

軟件架構設計的首要問題是如何表示軟件架構，即如何對軟件架構建模。
根據建模的側重點不同，可以把軟件架構的模型分為5種，分別是：

• 結構模型
• 框架模型
• 動態模型
• 過程模型
• 功能模型

“4+1”：視圖模型從5個不同的視角來描述軟件架構，每個視圖只關心系統的一個側面，5個視圖結合在一起才能反映軟件架構的全部內容：

• 邏輯視圖（靜態結構）
• 開發視圖（靜態結構）
• 進程視圖（動態結構）
• 物理視圖（動態結構）
• 場景：可以用文本表示，也可以用圖形表示

例如，圖12-2是一個小型電話呼叫系統場景片段的圖形描述，相應的文本表示如下：

12.3 軟件架構風格

12.3.1 軟件架構風格概述

• 軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。
• 體系結構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。對軟件體系結構風格的研究和實踐促進對設計的重用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。例如，如果某人把系統描述為“客戶/服務器”模式，則不必給出設計細節，我們立刻就會明白系統是如何組織和工作的。

12.3.2 數據流體系結構風格

1.批處理體系結構風格

2.管道-過濾體系結構風格

12.3.3 調用/返回體系結構風格

1.主程序/子程序風格

2.面向對象體系結構風格

3.層次型體系結構風格

4.客戶端/服務端體系結構風格

二層架構

表示層：表示層是系統的用戶接口部分，擔負著用戶與系統之間的對話功能。
數據層：負責對 DBMS 進行管理和控制。

三層C/S架構

• 表示層：表示層是系統的用戶接口部分，擔負著用戶與系統之間的對話功能。它用于檢查用戶從鍵盤等輸入的數據，顯示輸出的數據。
• 功能層：功能層也稱為業務邏輯層，是將具體的業務處理邏輯編入程序中。
• 數據層：數據層相當于二層 C/S 架構中的服務器，負責對 DBMS 進行管理和控制。

---

與傳統的二層 C/S 架構相比，三層CS 架構具有以下優點:

1. 允許合理地劃分三層的功能，使之在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統的可維護性和可擴展性。
2. 允許更靈活、有效地選用相應的平臺和硬件系統，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層，并且這些平臺和各個組成部分可以具有良好的可升級性和開放性。
3. 系統的各層可以并行開發，各層也可以選擇各自最適合的開發語言，使之能并行且高效地進行開發，達到較高的性能價格比。對每一層的處理邏輯的開發和維護也會更容易些。
4. 利用功能層可以有效地隔離表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑客手段非法訪問數據層，這就為嚴格的安全管理定了堅實的基礎。但是，若三層C/S架構各層間的通信效率不高，即使分配給各層的硬件能力很強，其作為整體來說也達不到所要求的性能。

此外，設計時必須慎重考慮三層間的通信方法、通信頻度和數據量，這是三層 C/S 架構設計的關鍵問題。

B/S層架構：

• 瀏覽器/服務器(Browser/Server，B/S)架構是三層C/S架構的一種實現方式，其具體結構為“瀏覽器/Web服務器/數據庫服務器”。B/S架構利用不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器就實現了原來需要復雜的專用軟件才能實現的強大功能,并節約了開發成本。從某種程度上來說，B/S架構是一種全新的軟件架構。

B/S層架構優點：

• 在B/S架構中，除了數據庫服務器外，應用程序以網頁形式存放于Web服務器上，用戶運行某個應用程序時，只需在客戶端的瀏覽器中鍵入相應的網址，調用 Web服務器上的應用程序，并對數據庫進行操作，完成相應的數據處理工作，最后將結果通過瀏覽器顯示給用戶。
• 基于 B/S架構的軟件，系統安裝、修改和維護全在服務器端解決。
• 用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級。

B/S層架構缺點，與C/S架構相比，B/S架構也有許多不足之處，例如：

• 缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理功能;
• 安全性難以控制
• 采用B/S架構的系統在數據查詢等響應速度上遠遠低于 C/S 架構
• B/S 架構的數據提交一般以頁面為單位，數據的動態交互性不強，不利于 OLTP 應用。

12.3.4 以數據為中心的體系結構風格

1.倉庫體系結構風格

2.黑板體系結構風格

12.3.5 虛擬機體系結構風格

1.解釋器體系結構風格

2.規則系統體系結構風格

12.3.6 獨立構件體系結構風格

1.進程通信體系結構風格

2.事件體系結構風格

12.3.7 面向服務的架構風格

面向服務的架構(Service-Oriented Architecture，SOA)

1.SOA概述

基本服務結構

SOA設計原則

服務構建與傳統構建

2.SOA關鍵技術

UDDI

WSDL

SOAP

REST

REST是一種只使用HTTP和XML進行基于Web通信的技術，可以降低開發的復雜性，提高系統的可伸縮性。它的簡單性和缺少嚴格配置文件的特性，使它與SOAP很好地隔離開REST從根本上來說只支持幾個操作(POST、GET、PUT和DELETE)，這些操作適用于所有的消息。

REST提出了如下一些設計概念和準則:

1. 網絡上的所有事物都被抽象為資源。
2. 每個資源對應一個唯一的資源標識
3. 通過通用的連接件接口對資源進行操作。
4. 對資源的各種操作不會改變資源標識。
5. 所有的操作都是無狀態的。

3.SOA實現方法

ＷebService

服務注冊表

企業服務總線ESB

12.4 軟件架構標準

軟件架構標準要素之間的關系，具體分為5個層次:

• 任務
• 環境
• 利益相關者
• 關注
• 關注點庫、模型

12.5 軟件架構實現

傳統軟件開發模型存在開發效率不高、不能很好地支持軟件重用等缺點。基于架構的軟，件開發模型(ABSDM)把整個基于體系結構的軟件過程劃分為體系結構需求、設計、文檔化、復審、實現和演化等6個子過程，

12.5.1 體系結構需求

1. 需求獲取

2. 標識構建

1. 生成類圖
2. 對類進行分組
3. 把類打包成構建

3. 架構需求評審

組織一個由不同代表(如分析人員、客戶、設計人員、測試人員)組成的小組，對體系結構需求及相關構件進行仔細的審查。審查的主要內容包括所獲取的需求是否真實反映了用戶的要求，類的分組是否合理，構件合并是否合理等。必要時，可以在“需求獲取一標識構件一需求評審”之間進行迭代。

12.5.2 體系結構設計

1. 提出體系結構模型
2. 映射構件
3. 分析構件間的相互作用
4. 產生體系結構
5. 設計評審
   

12.5.4 體系結構復審

• 體系結構設計、體系結構文檔化和體系結構復審是一個迭代過程。從這個角度來說，在分析一個主版本的軟件體系結構之后，要安排一次由外部人員(用戶代表和領域專家)參加的復審。

• 鑒于體系結構文檔標準化，以及風險識別的現實情況，通常我們根據架構設計，搭建一個可運行的最小化系統用于評估和測試體系架構是否滿足需要，是否存在可識別的技術和協作風險。

• 復審的目的是標識潛在的風險，及早發現體系結構設計中的缺陷和錯誤，包括體系結構能否滿足需求、質量需求是否在設計中得到體現、層次是否清晰、構件的劃分是否合理、文檔表達是否明確、構件的設計是否滿足功能與性能的要求等。

12.5.5 體系結構實現

12.5.6 體系結構的演化

12.6 軟件架構質量屬性

12.6.1 質量屬性概念

軟件系統質量屬性(Quality Attribute)是一個系統的可測量或者可測試的屬性，用來描述系統滿足利益相關者(Stakeholders)需求的程度。

基于軟件系統的生命周期，可以將軟件系統的質量屬性分為開發期質量屬性和運行期質量屬性兩部分。

1.開發期質量屬性

2.運行期質量屬性

12.6.2 面向架構評估的質量屬性

1.性能

2.可靠性

3.可用性

4.安全性

5.可修改性

6.功能性

7.可變性

8.互操作性

12.6.3 質量屬性場景描述

1.可用性質量屬性場景

2.可修改性質量屬性場景

3.性能質量屬性場景

4.可測試性質量屬性場景

5.易用性質量屬性場景描述

6.安全性質量屬性場景

總結

參考：
10種常見的架構風格，你用過幾種

---

關于博主

wx/qq：binary-monster/1113673178 （添加時注明來意，否則不予通過）
wxgzh: 二進制怪獸
CSDN：https://blog.csdn.net/qq1113673178
碼云：https://gitee.com/shiver
Github: https://github.com/ShiverZm
個人博客：https://www.binary-monster.top