天天看點

軟體體系結構期末複習總結

什麼是軟體體系結構?

軟體體系結構是具有一定形式的結構化元素,抽象的講,軟體體系結構包括構成系統的設計元素的描述,設計元素的互動,設計元素組合的模式,以及在這些模式中的限制。具體的講,體系結構 = 元件+連接配接件+限制

元件:具有某種功能的可重用的軟體子產品單元,表示了系統中主要的計算單元和資料存儲。

連接配接件:表示了元件之間的互動,簡單的連接配接件有:管道,過程調用,事件廣播等,複雜的連接配接件有:客戶-伺服器通信協定,資料庫和應用之間SQL連接配接等。

限制:表示了元件和連接配接件的拓撲邏輯和限制。

七種經典的軟體體系結構風格

軟體體系結構期末複習總結
能夠回答以下四個問題:
  1. define (定義和特性)
  2. component & connectors (元件和連接配接件)
  3. usage examples (應用示例)
  4. advantages and disadvantages (優點和缺點)

pipe and filter(管道-過濾器)

軟體體系結構期末複習總結
元件和連接配接件

元件: filters -->處理資料流,一個過濾器封裝了一個處理步驟。

連接配接件:pipes --> 連接配接一個源和一個目的過濾器。

定義和特性

每個過濾器都有一組輸入集和輸出集。過濾器從管道中讀入資料流,對輸入流進行内部轉換和增量計算(豐富,精煉,轉換,融合,分解),然後産生輸出資料流并寫入管道中。

特點:

  • 每個過濾器必須是一個獨立的實體:過濾器之間無需共享狀态,即filter無需知道其輸入管道和輸出管道所連接配接的其他過濾器的存在,更不必關注相鄰過濾器的實作細節。他僅僅需要對輸入資料流進行特定的内部転換和增量計算,篩選出合适的資料。
  • 資料到來是便被處理,不是收集然後處理,即在輸入被完全消費之前,輸出便産生了。
  • **管道是将資料從一個過濾器的輸出端移動到另一個過濾器的輸入端,是一個單向流。**不同的管道中流動的資料流,可能具有不同的資料格式。
應用示例

編譯器、Unix管道、圖像處理,信号處理,聲音與圖像處理

優點和缺點

優點

  • 良好的隐蔽性和高内聚、低耦合:可以将整個系統的輸入輸出行為看成多個過濾器功能的簡單合成。
  • 支援功能子產品的重用:任意兩個過濾器隻要互相間所傳輸的資料格式上達成一緻,就可以連接配接在一起
  • 系統容易維護和拓展:新的過濾器容易加入到系統中,舊的過濾器也可被改進的過濾器替換
  • 允許對一些如吞吐量,死鎖 等屬性進行分析
  • 支援并行執行:每一個過濾器既可以獨立運作,也可與其他過濾器并發執行。

缺點:

  • 不适合處理互動的應用
  • 系統性能不高,并增加了編寫過濾器的複雜性:資料傳輸缺乏通用标準,每個過濾器絕大部分時間消耗在資料格式的解析,轉換,合成上。同樣也不适用于大量共享資料的應用設定。

調用-傳回風格

主程式/子程式風格

軟體體系結構期末複習總結
元件和連接配接件

元件:過程和明确可見的資料

連接配接件:過程調用和顯式的共享資料

控制結構:單線程

特點

調用和定義層次結構,子系統通常通過子產品化來定義。

系統通常會被組織成一個主程式和一系列子程式的集合。主程式擔當子程式的驅動器,為子程式提供一個人控制環路,使子程式以某種次序順序執行。

ADT & OO

軟體體系結構期末複習總結
元件和連接配接件

元件:對象(抽象資料類型的執行個體)

連接配接件:過程調用

特點

在基于面向對象的模式中,操作和資料綁定在一起,隐藏實作和其他秘密。對象通過過程調用來實作互動。有兩個重要方面:

  • 對象維護自身表示的完整性
  • 這種表示對其他對象是隐藏的
優點和缺點

優點:

  • 面向對象易維護,易複用
  • 對象反映現實世界,容易分解一個系統
  • 對象對客戶實作了隐藏細節,所有可以在不影響其客戶的情況下改變對象的實作 。

缺點:

  • 對象的管理比較複雜,當一個對象和其他對象互動,必須知道其他對象的辨別。每當一個對象的辨別改變的時候,必須修改那些顯示調用它的對象。

分層系統

軟體體系結構期末複習總結
元件和連接配接件

元件: 在某些層中實作虛拟機

連接配接件: 協定, 規定了層次之間的互動方式

拓撲結構: 限制相鄰層之間的互動

特點
  • 一個分成系統是按照層次結構組織的,每一層向它的上層提供服務,同時它又是下層的客戶。
  • 上層必須知道下層的身份,不能調整層次之間的順序。
  • 大的問題分解成若幹漸進的小問題,逐漸解決,隐藏了很多複雜度。
  • 内層隻對其相鄰的層和某些用于輸出的函數是可見的,對其他外部的層是隐藏的。
  • 修改一層,最多影響兩層, 通常隻會影響上層。若層之間接口穩固,則不會造成其他影響
  • 層層相調,影響性能。
優點和缺點

優點:

  • 支援基于逐級抽象的系統設計,這允許設計者将一個複雜的問題分解成一系列遞增的步驟。
  • 支援擴充,由于分層系統每一層最多和上下兩層互動,對于任意一層功能的互動最多隻影響其他兩層。
  • 支援重用,如果能保證為相鄰的層提供一緻的接口,他允許系統中同一層的不同實作互相交換使用。(即給同一接口建立不同實作)

缺點

  • 定義一個合适的抽象層次可能會非常困難。比如,實際的通信協定體就很難映射到ISO架構中,因為其中許多協定跨多個層。

用戶端/伺服器風格

軟體體系結構期末複習總結
兩層C/S架構

特點

伺服器(背景)負責資料管理,客戶機(前台)完成與使用者的互動任務。“胖客戶機,瘦伺服器”

缺點

– 對用戶端軟硬體配置要求較高,用戶端臃腫

– 用戶端程式設計複雜

– 資料安全性不好。用戶端程式可以直接通路資料庫伺服器。

– 資訊内容和形式單一

– 使用者界面風格不一,使用繁雜,不利用推廣使用

– 軟體維護與更新困難。每個客戶機上的軟體都需要維護

三層C/S架構

與二層C/S結構相比,增加了一個應用伺服器。

應用功能分為表示層、功能層、資料層三層。

– 表示層是應用的使用者接口部分。通常使用圖形使用者界面

– 功能層是應用的主體,實作具體的業務處理邏輯

– 資料層是資料庫管理系統。

– 以上三層邏輯上獨立。

整個應用邏輯駐留在應用伺服器上,隻有表示層存在于客戶機上:“瘦客戶機”

浏覽器/伺服器風格

B/S架構

B/S體系結構是三層C/S體系結構的特例,用戶端有http浏覽器即可

• 隻能“拉”,不能“推”

• 客戶之間的通信隻能通過伺服器中轉

• 對客戶機資源和其他網絡資源的利用受限

• B/S結構的安全性較難控制(SQL注入攻擊…)

• B/S結構的應用系統在資料查詢等相應速度上,要遠遠低于C/S體系結構

• 伺服器的負荷大,客戶機的資源浪費

資料為中心的體系結構風格

定義

Data-centered style architectures involve a shared

data source approach to information passing.

以資料為中心的風格架構涉及到資訊傳遞的共享資料源方法。

典例: 系統資料庫 剪切闆

倉庫體系結構風格

倉庫是存儲和維護資料的中心場所。

元件: 中心資料結構,表示目前資料的狀态

連接配接件:倉庫與獨立構件之間的互動

應用場合:資料庫、倉庫形式的編譯器結構、倉庫形式的編譯器結構

軟體體系結構期末複習總結

黑闆體系結構風格

軟體體系結構期末複習總結
軟體體系結構期末複習總結

事件系統體系結構風格

軟體體系結構期末複習總結

主要特點

✓ 事件的觸發者并不知道哪些構件會被這些事件影響,互相保持獨立。

✓ 不能假定構件的處理順序,甚至不知道哪些過程會被調用。

✓ 各個構件之間彼此之間無連接配接關系,各自獨立存在,通過對事件的釋出和注冊實作關聯。

軟體體系結構期末複習總結

A component(Event Source) can annonce (or broadcast) one or more events. 一個元件可以廣播一些事件。

Other components(Event Handlers) in the system can register an interest in an event by associating a procedure with it. 系統中的其它構件可以注冊自己感興趣的事件,并将自己的某個過程與相應的事件進行關聯。

When the event is announced the system (Event Manager) itself invokes all of the procedures that have been registered for the event. 當一個事件被釋出,系統自動調用在該事件中注冊的所有過程。

應用示例

調試器中的斷點處理
軟體體系結構期末複習總結

Event Source:debugger (調試器)

Event Handler:editor and variable monitor (編輯器與變量螢幕)

Event Manager:IDE (內建開發環境)

✓ 編輯器與變量螢幕向調試器注冊,接收“斷點事件”;

✓ 遇到斷點,調試器釋出事件,進而觸發“編輯器”與“變量監測器”

✓ 編輯器将源代碼滾動到斷點處;

✓ 變量監測器則更新目前變量值并顯示出來。

美團平台
軟體體系結構期末複習總結

事件系統派遣機制

軟體體系結構期末複習總結

無獨立排程子產品的事件系統

This module is usually called Observable/Observer (被觀察者/觀察者).

Each module allows other modules to declare interest in events that they are sending. (每一個子產品都允許其他子產品向自己所能發送的某些消息表明興趣)

Whenever a module sends an event, it sends that event toexactly those modules that registered interest in that event.

(當某一子產品發出某一事件時,它自動将這些事件釋出給那些曾經向自己注冊過此事件的子產品)

軟體體系結構期末複習總結

有獨立事件派遣子產品的事件系統

事件派遣子產品是負責接收到來的事件并派遣它們到其它子產品。

全廣播式(All broadcasting) :派遣子產品将事件廣播到所有的子產品,但隻有感興趣的子產品才去取出事件并觸發自身的行為;

選擇廣播式(Selected broadcasting) :派遣子產品将事件送到那些已經注冊的子產品中。

軟體體系結構期末複習總結
軟體體系結構期末複習總結

選擇廣播式的兩種政策:基于事件被執行的方式

Point-to-Point (message queue)(點對點模式:基于消息隊列)

Publish-Subscribe(釋出-訂閱模式)

軟體體系結構期末複習總結
軟體體系結構期末複習總結

軟體體系結構描述

文檔建立的原則

◆ 1.從讀者的角度寫。

◆ 2.避免不必要的重複。

◆ 3.避免歧義。

◆ 4.使用标準組織結構。

◆ 5.記錄理由。

◆ 6.保持文檔時效性但不是頻繁更新(有限的穩定性)。

◆ 7.審查文檔是否符合需求

軟體體系結構模組化

軟體體系結構期末複習總結

“4+1”視圖模型從5個不同的視角包括邏輯視圖、程序視圖、實體視圖、開發視圖和場景視圖

來描述軟體體系結構。每一個視圖隻關心系統的一個側面,隻有5個視圖結合在一起才能反映系統的軟體體系結構的全部内容。

用例視圖 (場景)

◼ 從外部世界的角度描述正在模組化的系統的功能。

◼ 需要使用此視圖來描述系統應該執行的操作。 所有

其他視圖都依靠用例視圖(場景)來指導它們,這

就是将模型稱為4 + 1的原因。

◼ 該視圖通常包含用例圖,描述和概述圖。

用例圖
軟體體系結構期末複習總結

了解系統功能需求,系統提供的功能的描述。

用于顯示若幹角色以及這些角色與系統提供的用例之間的連接配接關系。

重要的是記住用例代表了系統的外部視圖。是以,不要期望用例與系統内部的類之間存在任何關聯。

邏輯視圖

◼ 描述系統各部分的抽象描述。用于模組化系統的組成部分以及各組成部分之間的互動方式。

◼ 通常包括類圖,對象圖,狀态圖和協作圖。

類圖
軟體體系結構期末複習總結

類圖表示系統中的類和類與類之間的關系,它是對系統靜态結構的描述。

對象圖
軟體體系結構期末複習總結

對象圖是某個時間點系統中對象的快照,因為它顯示的是執行個體而不是類,是以通常稱為執行個體圖。

狀态圖
軟體體系結構期末複習總結

狀态圖是描述類的對象所有可能的狀态以及事件發生時狀态的轉移條件。

協作圖
軟體體系結構期末複習總結

協作圖是一種互動圖,強調的是發送和接收消息的對象之間的組織結構。一個協作圖顯示了一系列的對象及對象之間的聯系以及對象間發送和接收的消息。

過程視圖

◼ 描述系統中的程序。 當 可視化系統中一定會發生的事情時,此視圖特别有用。

◼ 該視圖通常包含活動圖。

活動圖
軟體體系結構期末複習總結

描述滿足用例要求所要進行的活動以及活動間的限制關系,有利于識别并行活動

開發視圖

◼ 描述系統的各部分如何被組織為子產品群組件。管理系統體系結構中的層非常有用。

◼ 該視圖通常包含包圖群組件圖。

包圖
軟體體系結構期末複習總結

包是在UML中用類似于檔案夾的符号表示的模型元素的組合,允許從UML中擷取任何結構,并将其元素分組到更進階别的單元中。

元件圖
軟體體系結構期末複習總結

元件圖描述代碼構件的實體結構及各構件之間的依賴關系。将系統劃分為元件并希望通過接口或元件細分為較低級别的結構來顯示其互相關系

實體視圖

◼ 描述如何将前三個視圖中所述的系統設計實作為一組現實世界的實體。該視圖中的圖表展示了抽象部分如何映射到最終部署的系統中。

◼ 該視圖通常包含部署圖。

部署圖
軟體體系結構期末複習總結

部署圖定義系統中軟硬體的實體體系結構。描述了一個運作時的硬體結點,以及在這些結點上運作的軟體元件的靜态視圖。 顯示了系統的硬體,安裝在硬體上的軟體,以及用于連接配接異構的機器之間的中間件。

品質屬性場景

六個組成部分

➢ 刺激源(source):誰造成的刺激

➢ 刺激(stimulus):一個影響系統的情況

➢ 制品(artifact):系統被影響的部分

➢ 環境(environment):刺激發生時系統所處的狀态

➢ 響應(response):刺激所産生的結果

➢ 響應衡量名額(response measure):如何評估響應

生活案例
軟體體系結構期末複習總結

可用性

關注點

✓ 是否發生了故障(無法提供正常的服務,被外界發現)

✓ 故障的後果

衡量名額

✓ 可用(或故障)時間百分比

✓ 修複故障所需的時間

✓ 平均無故障時間

軟體體系結構期末複習總結

➢刺激源

✓ 故障的迹象(來自内部或外部)

➢刺激

✓ 系統出錯

✓ 系統崩潰(反複出錯)

✓ 給出結果不準時(早或晚)

✓ 給出錯誤結果

➢制品

✓ 計算 or 存儲 or 網絡傳輸

➢環境

✓ 正常狀态 or “亞健康”狀态

➢響應

✓ 記錄日志(錯誤報告),回傳給廠家

✓ 通知管理者或其他系統

✓ 關閉系統,系統在維修期間不可用

➢響應衡量名額

✓ 故障時間百分比、修複故障所需時間、平均無故障時間……

提升可用性的政策

➢ 方向1:故障檢測

  • Ping/echo

監控元件不定期向被監控元件發出ping消息,并根據收到的echo消息(是否收到、延時)做出響應

  • Heartbeat(心跳)

被監控元件定期向監控元件發出心跳消息

在節點間保持周期性的心跳信号以檢測各個節點的狀态。若連續未收到的心跳信号到了一定的數目,就認為相應的系統已經出現故障。

  • Exceptions(異常)

抛出 + 捕獲 + 處理

需要程式設計語言支援

➢ 方向2:故障恢複

  • 投票
    1. 多個備援的元件,用統一或不同的算法來完成同一個任務。如果計算結
    果不同,則少數服從多數
    1. 為降低同時出錯的機率,多個元件可以由不同的開發團隊在不同的軟、
    硬體平台上開發
  • 主動備援
    1. A、B伺服器完成同樣的運算(A和B的狀态時刻保持一緻),平時隻取
    A算出的結果
    1. 當A出現故障時,系統可以極快地切換到B
  • 被動備援
    1. A伺服器完成運算後的一定時間内把自身狀态告知B,B再把自身狀态更
    新為A的狀态。
    1. 當A出現故障時,首先需要确認B的狀态是最新的.
  • 内測

    開發人員修正bug,并在内部進行測試,确認無誤後再釋出更新檔

  • 檢查點/復原

    定期儲存,便于恢複

➢ 方向3:故障避免

  • 服務下線
    1. 惹不起,躲得起
    2. 如果明确知道即将遭到毀滅性攻擊,不如主動下線
  • 事務
    1. 多個操作必須全部完成(銀行轉賬)
  • 程序監控
    1. Windows任務管理器

可修改性

關注點

✓修改的成本

✓系統的哪些部分被修改

✓修改發生的時間

✓修改由誰來進行

軟體體系結構期末複習總結
提升可修改性政策

目标:降低修改的時間和成本

限制修改範圍:讓修改所影響的軟體範圍盡可能的小

  • 子產品高内聚、低耦合:盡量把對程式的修改控制在一個子產品内,可以借助架構、中間件
  • 考慮到可能會發生的修改

➢有助于評估子產品間責任的劃分

➢ 讓一個點的修改隻影響一個子產品

➢ 避免完全無關的多個修改會影響同一個子產品

  • 讓子產品通用:“解釋器”風格的思路
  • 隐藏資訊:面向對象機制中的可通路性(public/private)
  • 維持接口不變:在接口不變的情況下,接口連接配接的雙方可以獨立變化
  • 限制通信路徑:設計模式中的Façade模式
  • 使用中介

➢ 資料中介:共享資料的風格

➢ 服務中介:設計模式中的bridge、factory method等模式

  • 命名伺服器(name server):查詢所需資源 / 對象的位置,解決位置依賴
  • 按需建立執行個體:借助設計模式中的建立型模式

延遲綁定時間:讓軟體在運作期間仍可進行靈活修改

  • 配置檔案:修改配置檔案,而不用修改代碼
  • 釋出-訂閱模式

➢ 軟體體系風格部分已有介紹(事件系統)

➢ 設計模式中的“觀察者模式”

  • 多态:用不同的子類,實作不同的功能

性能

關注點

✓ 系統響應事件的速度

✓ 和事件的數量和到達模式有關

響應衡量名額

✓ 處理事件所花的時間

✓ 機關時間内處理事件的數目

✓ 處理的錯誤率/丢失率

軟體體系結構期末複習總結
提升性能的政策

方向1:資源的需求

  1. 在要處理的資料量不變的情況下,提高計算效率

➢ 使用更高效率的算法

➢ 減少處理事件時對資源的占用

  1. 減少要處理的資料總量

➢ 控制事件到來的速率

➢ 隻抽取一部分請求來處理

  1. 限制執行時間
➢ 在規定時間内得到近似解
  1. 限制待處理事件隊列長度
➢ 直接放棄處理一部分事件

方向2:資源的管理

利用并發機制:多線程、多程序、多核、多機……

增加可用資源: 計算資源、存儲資源、帶寬資源……

方向3:資源的仲裁

➢ 先來先服務

➢ 固定優先級排程

➢ 動态優先級

安全性

關注點

✓ 在保證合法使用者使用系統的前提下,抵抗對系統的攻擊

提升安全性的政策

軟體體系結構期末複習總結

方向1:抵抗攻擊

  1. 使用者的證明:密碼、驗證碼、生物識别……
  2. 使用者的授權: 确認使用者的操作是在其權限範圍
  3. 維持資料的保密性:給資料和傳輸過程加密
  4. 維持資料的完整性:MD5碼校驗
  5. 減少暴露:關閉無用端口、自啟動的服務、無線路由SSID等
  6. 限制通路:白名單、黑名單

方向2:檢測攻擊

軟體和人結合:入侵檢測系統、安全專家

方向3:從攻擊中恢複

恢複狀态:使用“可用性”中的相關政策

攻擊者的識别:也能震懾潛在的攻擊者

可測試性

關注點

✓ 讓軟體的bug容易被測試出來

✓ 驗證軟體産品與它的需求規格是否比對(存在不符或缺失)

✓ 使用最小的成本和工作量來驗證軟體的品質

軟體體系結構期末複習總結
提升可測試性的政策

黑盒測試

記錄 / 回放: 自動化/半自動化測試

把接口和實作分離開:不同的排序算法,使用相同的接口

提供專用的測試路徑

白盒測試

内部監控:IDE提供的斷點等調試工具、WinDbg等工具

Appium(APP UI測試)

Selenium(Web UI測試)

JMeter(接口測試、性能測試)

易用性

關注點

✓ 讓使用者使用軟體的難度降低

軟體體系結構期末複習總結
提升易用性的政策

方向1:運作時政策

  1. 系統猜測使用者要完成的任務:輸入法聯想、搜尋引擎聯想
  2. 系統給使用者适當的回報:提示拷貝檔案所需的剩餘時間、浏覽器打開頁面的進度
  3. 系統給使用者提供一緻的體驗:滑鼠提供DPI調整,适應不同的分辨率
  4. 支援撤銷操作:減少誤操作的影響

方向2:設計時政策

把使用者界面和系統其它部分隔離開:MVC模式,支援使用者界面的獨立修改(甚至使用者可以自行修改使用者界面)

體系結構評估ATAM(Architecture Trade-off Analysis Method )

utility tree

軟體體系結構期末複習總結

效用是樹的根結點,代表系統的整體品質。品質屬性構成樹的二級節點。在每個品質屬性下對該品質屬性做了進一步的說明。所設定的優先級是用高(H)、中(M)、低(L)的形式。

(M,L)優先級解釋

  • 第一個字母代表:每個場景對系統成功的重要影響程度
  • 第二個字母代表:體系結構設計師所估計的實作這種場景的難度

risks, non-risks, sensitivity points, and tradeoffs

sensitivity points

A sensitivity point is a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response.

“The level of confidentiality in a virtual private network might be sensitive to the number of bits of encryption. ”

敏感點是一個或多個元件(和/或元件關系)的屬性,對于實作特定的品質屬性響應至關重要。

e.g. 虛拟專用網絡的保密級别可能對加密的位數很敏感。

tradeoff

A tradeoff point is a property that affects more than one attribute and is a sensitivity point for more than one attribute.

“Changing the level of encryption could have a significant impact on both security and performance.”

權衡點是影響多個屬性和的屬性,是多個屬性的敏感點。

e.g.“改變加密級别可能會對安全性和性能産生重大影響。

risks

A risk is a potentially problematic architectural decision.

“The level of confidentiality in a virtual private network might be sensitive to the number of bits of encryption. ”

風險是一個潛在的有問題的架構決策。

e.g.“虛拟專用網絡的機密程度可能對加密的比特數很敏感。”

non-risks

Non-risks are good architectural decisions that are deemed safe upon

analysis.

“Assuming message arrival rates of once per second, a processing

time of less than 30 ms, and the existence of one higher priority

process, a 1 second soft deadline seems reasonable.”

無風險是被認為是安全的良好架構決策分析。

e.g.假定消息的到達速率是每秒一次,一次處理的時間小于30ms。如果對一個更高優先級的處理的響應時間要求是1秒鐘,此系統可行

期末考試

客觀題(30分)

兩道簡答題(5*2 = 10)

  1. 什麼是軟體體系結構?
  2. 描述“虛拟機風格”體系結構,并舉出一個典型例子

十道選擇題(2*10 = 20)

  1. 六種品質屬性的提升政策
  2. 看圖檔中所給的是哪種體系結構風格
  3. UML各種圖的功能和結構

三道大題(70分)

  1. 場景題:
    • 涉及到什麼品質屬性
    • 畫出每一種品質屬性的場景(六要素:刺激源,刺激,制品,環境,響應,響應衡量名額)
    • 針對每種品質屬性,至少寫出兩種提升政策
    • 該系統最适合用什麼體系結構風格,說明原因,并闡述該種體系風格的優點和缺點
  2. 畫效應樹
  3. 寫風險點,非風險點,敏感點,權衡點的概念,并将下面的陳述句歸類到這四種裡。

剛考完試,發波筆記攢人品,過過過! 2020/8/18

參考

《軟體體系結構》 Mary Shaw David garlan著

課件

繼續閱讀