1、? 從需求分析到軟件設計之間的過渡過程稱為軟件架構。
軟件架構為軟件系統提供了一個結構、行為和屬性的高級抽象,由構件的描述、構件的相互作用(連接件)、指導構件集成的模式以及這些模式的約束組成。
軟件架構不僅指定了系統的組織結構和拓撲結構,并且顯示了系統需求和構件之間的對應關系,提供了一些設計決策的基本原理。
解決好軟件的復用、質量和維護問題,是研究軟件架構的根本目的。
2、? 軟件架構(Software Architecture,SA)設計與生命周期
(1)需求分析階段:關注的兩個問題,一是如何根據需求模型構建SA模型,二是如何保證模型轉換的可追蹤性。
(2)設計階段:設計階段是SA研究關注最早和最多的階段。支持構件、連接件及其配置的描述語言稱為體系結構描述語言(Architecture Description Language,ADL),ADL對連接子的重視成為區分ADL和其他建模語言的重要特征之一。
(3)實現階段
(4)構件組裝階段:支持可復用構件的互聯,檢測并消除體系結構失配問題(由構件引起的失配、由連接子引起的失配、由于系統成分對全局體系結構的假設存在沖突引起的失配)
(5)部署階段
(6)后開發階段:軟件部署之后的階段,這一階段SA研究主要圍繞維護、演化、復用等方面進行。典型的研究方向包括動態軟件體系結構、體系結構恢復與重建
邏輯視圖:設計的對象模型,關注系統功能
開發視圖:描述了在開發環境中軟件的靜態組織結構,關注源代碼、組件、DLL
進程視圖(過程視圖):關注并發、同步特征
物理視圖:關注軟件到硬件的映射關系,反映分布式特性
當采用面向對象的設計方法描述對象模型時,通常使用類圖表達類的內部屬性和行為,以及類集合之間的交互關系;采用狀態圖定義對象的內部行為。
3、? 軟件架構的重要性
軟件架構設計師降低成本、改進質量、按時和按需交付產品的關鍵因素。
(1)架構設計能能夠滿足系統的品質
(2)架構設計使受益人達成一致的目標
(3)架構設計能夠支持計劃編寫過程
(4)架構設計對系統開發的指導性
(5)架構設計能夠有效地管理復雜性
(6)架構設計為復用奠定了基礎
(7)架構設計能降低維護成本
(8)架構設計能支持沖突分析
4、? 軟件架構風格:是指描述特定應用領域系統組織方式的慣用模式。組織方式描述了系統的組成構件和這些構件的組織方式,慣用模式反映了眾多系統共有的結構和語義。
分類 | 具體風格 | 描述 | 常考關鍵詞及實例 |
數據流風格 | 批處理 | 每個處理步驟是一個單獨的程序。數據必須是完整的,以整體的方式從前一階段傳給后一階段。基本構件是獨立的應用程序,連接件是某種類型的媒介。 | 傳統編譯器,每個階段產生的結果作為下一個階段的輸入 |
管道-過濾器 | 每個處理步驟由一個過濾器實現,步驟之間通過數據流連接,數據不必整體方式傳輸。基本構件是過濾器,連接件是數據流傳輸管道。 | ||
調用/返回風格 | 主程序/子程序 | 一般采用單線程控制,構件是主程序和子程序,連接件是過程調用。主程序直接調用子程序,屬于顯示調用 | |
面向對象 | 建立在數據抽象和面向對象的基礎上。對象是構件,連接件是對象之間的交互方式 | ||
層次結構 | 構件組織成一個層次結構,連接件通過決定層間如何交互的協議定義。每一層為上一層提供服務,并作為下一層的客戶。越靠近底層,抽象級別越高;越靠近頂層,抽象級別越低。內部的層接口只對相鄰的層可見,每一層最多只影響兩層,為軟件重用提供了強大的支持 | 操作系統 | |
客服端/服務器 | 即C/S架構,基于資源不對等,且為實現共享而提出的。分為2層C/S架構和3層C/S架構。2層C/S架構有3個主要組成部分:數據庫服務器、客戶應用程序和網絡,應用邏輯在客戶應用程序上完成,稱為“胖客戶機,瘦服務器”。3層C/S架構有4個主要主要組成部分:數據庫服務器、應用服務器、客戶應用程序和網絡,應用邏輯駐留在應用服務器上,只有表示層存在于客戶機,稱為“瘦客戶機”,應用功能分為表示層、功能層和數據層。 | ||
以數據為中心風格 | 倉庫(數據庫系統) | 也叫數據庫系統風格,構件有兩種:一是中央共享數據源,保存當前系統的數據狀態;二是一組對中央數據進行操作的獨立構件。連接件即為倉庫與獨立構件之間的交互。 | 以數據為中心,也叫數據共享風格 |
黑板 | 適用于解決復雜的非結構化的問題。黑板系統是一種問題求解模型。包括知識源、黑板和控制三部分。知識源包括若干獨立計算的不同單元,提供解決問題的知識。知識源響應黑板的變化,也只修改黑板,黑板是一個全局數據庫,是知識源相互作用的唯一媒介。 | 現代編譯器的集成開發環境IDE、信號處理領域,如語言識別、問題規劃、模式識別、編譯優化 | |
超文本 | 構件以網狀連接方式相互連接,用戶可以在構件之間進行按照人類的聯想思維方式任意跳轉到相關構件。 | 常應用在互聯網領域 | |
虛擬機 | 解釋器 | 解釋器通過包括一個完成解釋工作的解釋引擎、一個包含將被解釋的代碼的存儲區、一個記錄解釋引擎當前工作狀態的數據結構,以及一個記錄源代碼被解釋執行的進度的數據結構 | 自定義流程,按流程執行,規則隨時改變,靈活定義,業務靈活組合,專家系統,java虛擬機、機器人 |
規則系統 | 包括規則集、規則解釋器、規則/數據選擇器和工作內存 | 人工智能 | |
獨立構件 | 進程通信 | 構件是獨立的過程,連接件是消息傳遞。構件通常是命名過程,消息傳遞的方式可以是點對點、異步或同步、遠程過程調用等 | |
事件驅動 | 構件不直接調用一個過程,而是觸發或廣播一個或多個事件,屬于隱式調用。優點是為軟件復用提供強調的支持,為構件的維護和演化帶來了方便;其缺點是構件放棄了對系統計算的控制 | 事件觸發推動動作,如程序語言的語法高亮、語法錯誤提示 | |
閉環 | 過程控制 | 發出控制命令并接受反饋,循環往復達到平衡 | 設定參數,并不斷調整。汽車巡航定速、空調溫度調節 |
5、? 基于服務的架構(SOA)
一個組件模型,它將應用程序的不同功能單元(稱為服務)通過這些服務間定義好的接口和契約聯系起來。接口是采用中立的方式定義,它獨立于實現服務的硬件平臺、操作系統和編程語言。
服務是一種為了滿足某項業務需求的操作、規則等的邏輯組合
SOA的特點:松散耦合、粗粒度、標準化接口
服務構件與傳統構件區別:
(1)服務構件的實現與語言無關,傳統構件綁定某種特定語言
(2)服務構件粒度大于傳統構件粒度,傳統構件粒度大于對象粒度
(3)服務構件接口是標準的,主要是WSDL(Web服務描述語言)接口,傳統構件常以具體API形式出現
(4)服務構件可以通過構件容器提供QoS服務,傳統構件完全由程序代碼直接控制
SOA的實現方式:
(1)Web Service
(2)ESB
企業服務總線是傳統中間件技術與XML、WEB服務等技術結合的產物,主要支持異構系統集成。ESB基于內容的路由和過濾器,具備復雜數據的傳輸能力,可以提供一系列的標準接口。
作用與特點:
(1)SOA的一種實現方式,起到總線的作用,將各種服務進行連接與整合
(2)描述服務的元數據和服務注冊管理
(3)在服務請求者和服務提供者之間傳遞數據,以及對數據進行轉換,并支持同步模式、異步模式
(4)發現、路由、匹配和選擇的能力,以及支持服務之間的動態交互,解耦服務請求者和服務提供者。高一級的能力還包括對安全的支持、服務質量保證、可管理性和負載平衡等。
主要功能包括:
服務位置透明性
消息路由和尋址服務
傳輸協議轉換
消息格式轉換
服務注冊和命名管理
日志與監控
安全性
(3)服務注冊表
SOA設計原則:
(1)無狀態
(2)單一實例:避免功能冗余
(3)明確定義的接口
(4)自包含和模塊化
(5)粗粒度
(6)松耦合
(7)重用能力
(8)互操作性、兼容和策略聲明
SOA關鍵技術和協議
REST技術特點:
(1)網絡上的所有事物都被抽象為資源
(2)每個資源都對應一個唯一的資源標識
(3)通過通用的連接器接口對資源進行操作
(4)對資源的各種操作不會改變資源標識
(5)所有的操作都是無狀態的
6、? 微服務架構:是SOA架構的進一步優化,去除了ESB企業服務總線,是一個真正意義上去中心化的分布式架構,更加強調服務個體的獨立性、拆分粒度更小。
特點:
(1)小,且專注于做一件事
(2)輕量級通信機制
(3)松耦合、獨立部署
優勢:
(1)技術異構性
(2)彈性
(3)擴展
(4)簡化部署
(5)與組織結構相匹配
(6)可組合性
7、? 架構描述語言(ADL):一種形式化語言,它在語義模型的支持下,為軟件系統的概念體系結構建模提供了具體語法和概念框架。基于底層語義的工具為體系結構的表示、分析、演化、細化、設計過程等提供支持。
ADL的三個基本要素:構件、連接件、構件配置
8、? 特定領域軟件架構(Domain Specific Software Architecture,DSSA):在一個特定應用領域中為一組應用提供組織結構參考的標準軟件系統結構。
DAAS具有的特征:
(1)嚴格定義的問題域和解決域
(2)具有普遍性,使其可以用于領域中某個特定應用的開發
(3)對整個領域有合適程度的抽象
(4)具備該領域固定的、典型的在開發過程中可重用元素
基本活動和領域劃分分類:
參與DSSA的人員:
(1)領域專家:有經驗的用戶、從事該領域中系統的需求分析、設計、實現以及項目管理的有經驗的軟件工程師。領域專家的主要任務包括提供關于領域中系統的需求規約和實現的知識
(2)領域分析人員:應由具有知識工程背景的有經驗的系統分析員來擔任
(3)領域設計人員:應由有經驗的軟件設計人員來擔任
(4)領域實現人員:應由有經驗的程序設計人員來擔任
DSSA的建立過程:
DSSA三層次模型:
9、? 質量屬性
軟件系統屬性包括功能屬性和質量屬性,軟件架構重點關注的是質量屬性。架構的基本需求是在滿足功能屬性的前提下,關注軟件系統質量屬性。
軟件系統質量是軟件系統與明確地和隱含地定義的需求相一致的程度。
軟件系統質量屬性(Quality Attribute)是一個系統的可測量或者可測試的屬性,用來描述系統滿足利益相關者需求的程度。
10、? 面向架構評估的質量屬性
(1)性能:指系統的響應能力,即要經過多長時間才能對某個事件做出響應,或者在某段時間內系統所能處理的事件個數。如響應時間、吞吐量。設計策略:優先隊列、增加計算資源、減少計算開銷、引入并發機制、采用資源調度等
(2)可靠性:軟件系統在規定的條件下和規定的時間內完成規定功能的能力。如MTTF(平均失效等待時間)、MTBF(平均失效間隔時間)、可靠度(系統在規定時間內無故障的概率)。設計策略:心跳、Ping/Echo、冗余、選舉。備注:失效強度是失效概率關于時間的導數
(3)可用性:是系統能夠正常運行的時間比例,經常用兩次故障之間的時間長度或者在出現故障時系統能夠恢復正常的速度來表示。如故障間隔時間。設計策略:心跳、Ping/Echo、冗余、選舉。
(4)安全性:指系統在向合法用戶提供服務的同時能夠阻止非授權用戶使用的企圖或拒絕服務的能力。如保密性、完整性、不可抵賴性、可控性。設計策略:入侵檢測、入侵防護、用戶認證、用戶授權、追蹤審計。
(5)可修改性:指能夠快速地以較高的性價比對系統進行變更的能力。通常以某些具體的變更為基準,通過考察這些變更的代價來衡量。包括可維護性、可擴展性、結構重組、可移植性。設計策略:接口-實現分類、抽象、信息隱藏
(6)功能性:是系統能完成所期望的工作能力。一項任務的完成需要系統中許多或大多數構件的相互協作。
(7)可變性:指系統結構經擴充或變更而成為新體系結構的能力。這種新體系結構應該符合預先定義的規則,在某些具體方面不同于原有的架構。
(8)互操作性:本軟件系統與其他系統交換數據和相互調用服務的難易程度。
11、? 架構風險:是指架構設計中潛在的、存在問題的架構決策所帶來的隱患
12、? 風險點和非風險點:可能引起風險的因素,可成為風險點。某個做法如果有隱患,有可能導致一些問題,則為風險點。而如果某件事是可行的、可接受的,則為非風險點。
敏感點:為了實現某種特定的質量屬性,一個或多個構件所具有的特性。
權衡點:是指影響多個質量屬性的特性,是多個質量屬性的敏感點。
13、? 軟件架構評估方法:
(1)基于調查問卷(檢查表)的方式
(2)基于度量的方式
(3)基于場景的方式
14、? 基于場景的方式
軟件架構分析法(SAAM)
架構權衡分析法(ATAM)
成本效益分析法(CBAM)
SAAM:最初用于分析架構可修改性,后擴展到其它質量屬性
ATAM:在SAAM基礎上發展起來的,主要針對性能、可用性、安全性和可修改性,在系統開發之前,對這些質量屬性進行評價和折中,整個評估過程強調以屬性作為架構評估的核心概念。
15、? 系統可靠性分析
系統可靠性(Software Reliability)是軟件產品在規定的條件下和規定的時間區間完成規定功能的能力,也就是系統無故障運行的概率。規定的條件是指軟件運行時的外部輸入條件;規定的時間區間是指軟件的實際運行時間區間;規定功能是指提供的服務。
系統可用性是指在某個給定時間點上系統能夠按照需求執行的概率。
16、? 軟件可靠性與硬件可靠性的區別
(1)復雜性:軟件復雜性比硬件高,大部分失效來自于軟件失效
(2)物理退化:硬件失效主要是物理退化所致,軟件不存在物理退化
(3)唯一性:軟件是唯一的,每個COPY版本都一樣,而兩個硬件不可能完全一樣
(4)版本更新周期:硬件較慢,軟件較快
17、? 可靠性指標
可靠度:系統在規定的條件、規定的時間區間不發生失效的概率
失效率:又稱風險函數,也稱條件失效強度,是指運行至此刻系統未出現失效的情況下,單位時間系統出現失效的概率
18、? 可靠性設計
(1)避錯技術:從設計、開發、測試等階段著手
(2)容錯技術:結構冗余(硬件冗余、軟件冗余)、信息冗余(校驗碼)、時間冗余(重復多次執行相同的計算),其中軟件冗余包括N版本程序設計(靜態冗余)、恢復塊設計(動態冗余)、防衛式程序設計
(3)檢錯技術:出錯后報警,人工處理、成本低
(4)降低復雜度設計
動態冗余是通過故障檢測、故障定位及故障恢復等手段達到容錯的目的,其中主要方式是多重模塊待機儲備,當系統檢測到某工作模塊出現錯誤時,就用一個備用的模塊來替代它并重新運行。各備用模塊在其待機時,可與主模塊一樣工作,也可以不工作。
19、? N版本程序設計
一種靜態的故障屏蔽技術,其設計思想是用N個具有相同功能的程序同時執行一項計算,結果通過多數表決來選擇。其中N個版本的程序必須由不同的人獨立設計,使用不同的方法、設計語言、開發環境和工具來實現,目的是減少N個版本的程序在表決點上相關錯誤的概率。
20、? 恢復塊設計
選擇一組操作作為容錯設計單元,從而把普通的程序塊變成恢復塊。被選用構造恢復塊的程序塊可以是模塊、過程、子程序和程序段等。恢復塊設計時必須保證實現主塊和后備塊之間的獨立性,避免相關錯誤的產生,使主塊備份塊之間的共性錯誤降到最低程度
21、? N版本程序設計與恢復塊設計的區別
恢復塊設計 | N版本程序設計 | |
硬件運行環境 | 單機 | 多機 |
錯誤檢測方法 | 驗證測試程序 | 表決 |
恢復策略 | 后向恢復 | 前向恢復 |
實時性 | 差 | 好 |
前向恢復:使當前的計算繼續下去,把系統恢復成連貫的正確狀態,彌補當前狀態的不連貫情況
后向恢復:系統恢復到前一個正確狀態,繼續執行
22、? 通過在系統配置中采用容錯技術來實現系統的可靠性,常用的系統配置技術分別有:雙機熱備技術、服務器集群技術
雙機熱備模式(主系統、備用系統)
雙機互備份模式(同時提供不同的服務,心不跳則接管)
雙機雙工模式(同時提供相同的服務,集群的一種)