1.系統架構設計基礎知識

1.1.軟件架構概念

軟件架構定義

軟件架構（Software Architecture）或稱軟件體系結構，是指系統的一個或者多個結構，這些結構包括軟件的構件（可能是程序模塊、類或者是中間件）、構件的外部可見屬性及其之間的相互關系。體系結構的設計包括數據庫設計和軟件結構設計，后者主要關注軟件構件的結構作用，并通過多種視圖全面描述、屬性和交互。

軟件架構設計與生命周期

軟件架構是貫穿整個生命周期的，不同階段的作用和意義不同，各階段架構工作見表9

需求分析階段

需求分析階段軟件架構研究還處于起步階段。需求關注的是問題空間，架構關注的是解空間，需要保持二者的可追蹤性和轉換。從軟件需求模型向軟件架構模型的轉換主要關注兩個問題：
1）如何根據需求模型構建軟件架構模型。
2）如何保證模型轉換的可追蹤性。

設計階段

這一階段的研究主要包括：軟件架構模型的描述、軟件架構模型的設計與分析方法，以及對軟件架構設計經驗的總結與復用等。其中架構模型的描述研究包括：
1）組成SA模型（軟件架構模型）的基本概念。即構件和連接子的建模。
2）體系架構描述語言（Architecture Describe Language，ADL）。是用于描述軟件體系架構的語言，與其他建模語言最大的區別在于其更關注構件間互聯機制（連接子），典型的 ADL 語言包括Unicon、Rapide、Darwin、Wright、C2SADL、Acme、XADLOL、XYZ/ADL和 ABC/ADL等。
3）多視圖。反映的是一組系統的不同方面，體現了關注點分散的思想，通常與 ADL 結合起來描述系統的體系結構。典型的模型包括：4+1模型、Hofmesiter 的 4 視圖模型、CMU-Sei 的Views and Beyond 模型。視圖標準包括：IEEE的I471-2000、RM-ODP、UML以及IBM的Zachman。

實現階段

這一階段的體系結構研究的內容有：
1）基于SA的開發過程支持。
2）尋求從SA向實現過渡的途徑。
3）研究基于SA的測試技術。 縮小軟件架構設計與底層實現概念差距的手段：模型轉換技術、封裝底層的實現細節、在SA模型中引入實現階段的概念（如用程序設計語言描述）。

構件組裝階段

1）如何支持可復用構件的互聯，即對SA設計模型中規約的連接子的實現提供支持。
2）組裝過程中，如何檢測并消除體系結構失配問題。這些問題主要包括：①構件本身的失配；②連接子（互聯機制）的失配；③部分和整體的失配。

部署階段

部署階段的軟件架構對軟件部署的作用：

一是提供高層的體系結構視圖描述部署階段的軟硬件模型；

二是基于軟件架構模型可以分析部署方案的質量屬性，從而選擇合理的部署方案。

后開發階段

部署安裝后（后開發階段）的系統架構研究方向包括：動態軟件體系結構、體系結構恢復與重建。

體系結構重建的方法有：手工體系結構重建、工具支持的手工重建、通過查詢語言來自動建立聚集、使用其他技術（如數據挖掘）。

軟件架構的重要性

軟件架構設計是降低成本、改進質量、按時和按需交付產品的關鍵因素。軟件架構的重要性包括：
（1）架構設計能夠滿足系統的品質。
（2）架構設計使受益人達成一致的目標。
（3）架構設計能夠支持計劃編制過程。
（4）架構設計對系統開發的指導性。
（5）架構設計能夠有效地管理復雜性。
（6）架構設計為復用奠定了基礎。
（7）架構設計能夠降低維護費用。
（8）架構設計能夠支持沖突分析。

1.2.基于架構的軟件開發方法

體系結構的設計方法概述

基于體系結構（架構）的軟件設計（Architecture-Based Software Design，ABSD）方法是體系結構驅動的，即指構成體系結構的商業、質量和功能需求的組合驅動的。在基于體系結構的軟件設計方法中，采用視角與視圖來描述軟件架構，采用用例來描述功能需求，采用質量場景來描述質量需求。ABSD方法具有三個基礎：功能的分解、通過選擇體系結構風格來實現質量和商業需求、軟件模板的使用。ABSD是自頂向下、遞歸細化的，迭代的每一步都有清晰的定義，有助于降低體系結構設計的隨意性。

基于體系結構的開發模型

傳統的軟件開發模型開發效率較低，ABSDM模型把整個基于體系結構的軟件開發過程劃分為體系結構需求、設計、文檔化、復審、實現和演化六個子過程，如圖

體系結構需求

體系結構的需求工作包括獲取用戶需求和標識系統中擬用構件。
（1）需求獲取。體系結構需求的獲取一般來自三個方面：質量目標、系統的商業目標和系統開發人員的商業目標。
（2）標識構件。標識構件分三步完成：生成類圖→對類進行分組→把類打包成構件。
（3）架構需求評審的審查重點包括需求是否真實反映了用戶的要求、類的分組是否合理、構件合并是否合理等。

體系結構設計

軟件的體系設計過程：提出軟件體系結構模型→映射構件→分析構件相互作用→產生體系結構設計評審。設計評審必須邀請獨立于系統開發的外部人員。

體系結構文檔化

體系結構文檔化過程的主要輸出結果是體系結構規格說明和測試體系結構需求的質量設計說明書。

體系結構復審

一個主版本的軟件體系結構分析之后，要安排一次由外部人員（用戶代表和領域專家）參加的復審。復審的目的是標識潛在的風險，及早發現體系結構設計中的缺陷和錯誤，必要時，可搭建一個可運行的最小化系統用于評估和測試體系結構是否滿足需要。

體系結構實現

體系結構的實現過程是以復審后的文檔化體系結構說明書為基礎的，具體為：分析與設計→構件實現→構件組裝→系統測試。體系結構說明書中定義了系統中構件與構件之間的關系。測試包括單個構件的功能性測試及被組裝應用的整體功能和性能測試。

體系結構演化

體系結構演化史使用系統演化步驟去修改應用，以滿足新的需求。系統演化步驟為：需求變化歸類→體系結構演化計劃→構件變動→更新構件的相互作用→構件組裝與測試→技術評審→演化后的體系結構。

1.3.軟件架構風格

軟件架構風格概述

軟件體系結構設計的核心目標是重復的體系結構模式（軟件復用/重用）。軟件體系結構（架構）風格是描述某一特定應用領域中系統組織方式的慣用模式。體系結構風格定義一個系統家族，即一個體系結構定義一個詞匯表和一組約束。
（1）詞匯表：包含構件和連接件。
（2）約束：約束定義構件和連接件的組合方式。 體系結構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。

數據流體系結構風格

（1）批處理體系結構風格：每個處理步驟是一個獨立的程序，每一步必須在前一步結束后才能開始，且數據必須是完整，以整體的方式傳遞。
（2）管道和過濾器：把系統分為幾個序貫地處理步驟，每個步驟之間通過數據流連接，一個步驟的輸出是另一個步驟的輸入，每個處理步驟都有輸入和輸出，如圖

調用/返回體系結構風格

調用-返回風格在系統中采用了調用與返回機制。利用調用-返回實際上是一種分而治之的策略，主要思想是將一個復雜的大系統分解為若干個子系統，降低復雜度，增加可修改性。

主程序/子程序風格

采用單線程控制，把問題劃分為若干處理步驟，構件即為主程序和子程序。

面向對象體系結構風格

面向對象體系結構風格：構件是對象，即抽象數據類型的實例，如圖

層次型體系結構風格

每一層為上層服務，并作為下層的接口。僅相鄰層間具有層接口，如圖

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

1）二層C/S模式。主要組成部分：數據庫服務器（后臺：負責數據管理）、客戶應用程序（前臺：完成與用戶交互任務）和網絡。 優點：客戶應用和服務器構件分別運行在不同的計算機上。 缺點：開發成本高，客戶端設計復雜，信息內容和形式單一，不利于推廣，軟件移植困難，軟件維護和升級困難。
2）三層C/S模式：瘦客戶端模式。應用該功能分為表示層、功能層和數據層。

表示層：用戶接口與應用邏輯層的交互，不影響業務邏輯，通常使用圖形用戶界面。

功能層：實現具體的業務處理邏輯。

數據層：數據庫管理系統。

瀏覽器/服務器風格（B/S）

1）B/S 風格：是三層應用結構的實現方式，其三層結構分別為：瀏覽器；Web服務器；數據庫服務器。
2）相比于C/S的不足之處：動態頁面的支持能力弱、系統拓展能力差、安全性難以控制、響應速度不足、數據交互性不強。

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

（1）：存儲和維護數據的中心場所。由中央數據結構（說明當前數據狀態）和一組獨立構件（對中央數據進行操作）組成，如圖9.6所示。

倉庫體系結構風格

存儲和維護數據的中心場所。由中央數據結構（說明當前數據狀態）和一組獨立構件（對中央數據進行操作）組成，如圖

黑板體系結構風格

是一種問題求解模型，是組織推理步驟、控制狀態數據和問題求解之領域知識的概念框架。可通過選取各種黑板、知識源和控制模塊的構件來設計，應用于信號處理領域，如語音識別和模式識別，如圖

虛擬機體系結構風格

虛擬機體系結構風格基本思想是人為構建一個運行環境，可以解析與運行自定義的一些語言，增加架構的靈活性。

解釋器體系結構風格

通常被用來建立一種虛擬機以彌合程序語義與硬件語義之間的差異，缺點是執行效率較低，典型例子是專家系統，如圖

規則系統體系結構風格

包括知識庫、規則解釋器、規則/數據選擇器及工作內存（程序運行存儲區），如圖

獨立構件體系結構風格

獨立構件體系結構風格強調系統中的每個構件都是相對獨立的個體，它們之間不直接通信，以降低耦合度，提升靈活度。
（1）進程通信體系結構風格：構件是獨立的過程，連接件是消息傳遞。
（2）事件系統體系結構風格：構件不直接調用一個過程，而是觸發或廣播一個或多個事件。

C2風格

C2 風格通過連接件連接構件或某個構件組，構件與構件之間無連接，如圖

1.4.軟件架構復用

軟件架構復用的定義及分類

軟件復用是系統化的軟件開發過程：開發一組基本的軟件構件模塊，以覆蓋不同的需求/體系結構之間的相似性，提高系統開發的效率、質量和性能。
軟件架構復用的類型包括機會復用和系統復用。

機會復用是在開發過程中，只要發現有可復用的資產就復用。

系統復用是在開發前進行規劃，決定哪些復用。

軟件架構復用的原因

減少開發工作、減少開發事件、降低開發成本、提高生產力、提高產品質量，更好的互操作性。

軟件架構復用的對象及形式

可復用的資產包括：需求、架構設計、元素、建模分析、測試、項目規劃、過程+方法+工具、人員、樣本系統、缺陷消除。

一般形式的復用包括：函數的復用、庫的復用、面向對象開發中的類、接口和包的復用。

軟件架構復用的基本過程

首先構建/獲取可復用的軟件資產（復用前提）→管理可復用資產→使用可復用資產。

1.5.特定領域軟件體系結構

特定領域軟件架構的定義

特定領域軟件架構（Domain Specific Software Architecture，DSSA）是在一個特定應用領域中為一組應用提供組織結構參考的標準軟件體系結構，即用于某一類特定應用領域的標準軟件構件集合。DSSA的特征：領域性、普遍性、抽象性、可復用性。

DSSA的基本活動

DSSA的基本活動有領域分析、領域設計、領域實現。
（1）領域分析：通過分析領域中系統的共性需求，建立領域模型。
（2）領域設計：設計DSSA，且DSSA需要具備領域需求變化的適應性。
（3）領域實現：獲取可重用信息。

參與DSSA的人員

參與DSSA的人員有領域專家、領域分析師、領域設計人員和領域實現人員。

DSSA的建立過程

DSSA的建立過程是并發的、遞歸的、反復的螺旋模型，分為五個階段：
（1）定義領域范圍。
（2）定義領域特定元素。
（3）定義領域特定的設計和實現約束。
（4）定義領域模型和體系結構。
（5）產生、搜集可重用的單元。

---

2.系統質量屬性與架構評估

2.1.軟件系統質量屬性

基本概念

軟件系統質量屬性是一個系統的可測量或可測試的屬性，基于軟件系統的生命周期，可將軟件系統的質量屬性分為開發期質量屬性和運行期質量屬性，見表

面向架構評估的質量屬性

在架構評估過程中，評估人員普遍關注的質量屬性見表

（1）可用性。提升可用性的策略可以從以下幾個方面考慮：
錯誤檢測：心跳、Ping/Echo、異常。
錯誤恢復：表決、主動冗余、被動冗余、重新同步、內測、檢查點/回滾。
錯誤避免：服務下線、事務、進程監控器。
（2）性能。提升性能的策略可以從以下幾個方面考慮：
資源的需求：減少處理事件時對資源的占用、減少處理事件的數量、控制資源的使用。
資源管理：并發機制、增加資源。
資源仲裁：先來先服務、固定優先級、動態優先級、靜態調度。
（3）可修改性。提升性能的策略可以從以下幾個方面考慮：
局部化修改：高內聚低耦合、預測變更、使模塊通用。
防止連鎖反應：信息隱藏、維持現有接口、限制通信路徑、使用中介。
推遲綁定時間：運行時注冊、多態、配置文件。
（4）安全性。提升安全性的策略可以從以下幾個方面考慮：
抵抗攻擊：用戶身份驗證、用戶授權、維護數據機密性與完整性、限制暴露、限制訪問。
檢測攻擊：入侵檢測系統。
從攻擊中恢復：恢復狀態、識別攻擊者。

質量屬性場景描述

質量屬性場景是一種面向特定質量屬性的需求，由刺激源、刺激、環境、制品、響應、響應度量組成。
（1）刺激源（Source）：某個生成該刺激的實體（人、計算機系統或者任何其他刺激器）。
（2）刺激（Stimulus）：指當刺激到達系統時需要考慮的條件。
（3）環境（Environment）：指該刺激在某些條件內發生。當激勵發生時，系統可能處于過載、運行或者其他情況。
（4）制品（Artifact）：某個制品被激勵，可能是整個系統，也可能是系統的一部分。
（5）響應（Response）：指在激勵到達后所采取的行動。
（6）響應度量（Measurement）：當響應發生時，應當能夠以某種方式對其進行度量，以對需求進行測試。

2.2.系統架構評估

系統架構評估中的重要概念

（1）敏感點：實現質量目標時應注意的點，是一個或多個構件的特性。
（2）權衡點：影響多個質量屬性的敏感點。
（3）風險承擔者或利益相關人：影響體系結構或被體系結構影響的群體。
（4）場景：確定架構質量評估目標的交互機制，一般采用觸發機制（教材中解釋為“刺激”）、環境和影響三方面來描述。

系統架構評估方法

軟件架構分析方法（Software Architecture Analysis Method，SAAM）

SAAM是卡耐基梅隆大學軟件工程研究所的Kazman等人于1983年提出的一種非功能質量屬性的架構分析方法，是最早形成文檔并得到廣泛應用的軟件架構分析方法。SAAM的主要輸入是問題描述、需求說明和架構描述，其分析過程主要包括場景開發、架構描述、單個場景評估、場景交互和總體評估，如圖

架構權衡分析法（Architecture Tradeoff Analysis Method，ATAM）

ATAM 是一種系統架構評估方法，主要在系統開發之前，針對性能、可用性、安全性和可修改性等質量屬性進行評價和折中。傳統的ATAM可以分為4個主要的活動階段，包括需求收集、架構視圖描述、屬性模型構造和分析、架構決策與折中，整個評估過程強調以屬性作為架構評估的核心概念。 現代的ATAM方法采用效用樹對質量屬性進行分類和優先級排序。用ATAM方法評估軟件體系結構分為演示、調查和分析、測試和報告，如圖

演示（Presentation）

使用ATAM評估軟件體系結構的初始階段，包括3個步驟：
①介紹ATAM：描述ATAM評估過程。
②介紹業務驅動因素：著重業務視角，提供有關系統功能、主要利益相關方、業務目標和其他限制等信息。
③介紹要評估的體系結構：側重可用性以及體系結構的質量要求。

調查和分析

使用ATAM技術評估架構第2階段，對一些關鍵問題徹底調查，包括3個步驟：
①確定架構方法：涉及能夠理解系統關鍵需求的關鍵架構方法。
②生成質量屬性效用樹：確定最重要的質量屬性，并確定優先次序。
③分析體系結構方法：徹底調查和分析，找出處理相應質量屬性架構的方法。包括4個主要階段：調查架構方法→創建分析問題→分析問題的答案→找出風險、非風險、敏感點和權衡點。

測試

①頭腦風暴和優先場景：將頭腦風暴的優先列表與生成質量屬性效用樹中所獲取的優先方案進行比較。
②分析架構方法。

報告ATAM

提供評估期間收集的所有信息，呈現給利益相關者。 上述兩種主要評估方法的對比，見表

成本效益分析法（Cost Benefit Analysis Method，CBAM）

分為整理場景→對場景進行求精→確定場景的優先級→分配效用→架構策略涉及哪些質量屬性及響應級別→使用內插法確定“期望的”質量屬性響應級別的效用→計算各架構策略的總收益→根據受成本限制影響的ROI 選擇架構策略。

其他評估方法

1）SAEM方法：將軟件架構看作一個最終產品以及涉及過程中的一個中間產品，從外部質量屬性和內部質量屬性闡述的評估模型。
2）SAABNet 方法：輔助架構的定性評估，幫助診斷軟件問題的可能原因，分析架構中的修改給質量屬性帶來的影響、預測架構的質量屬性，幫助架構設計人員做決策。SAABNet 度量的對象包括架構屬性、質量準則和質量因素。
3）SACMM 方法：一種軟件架構修改的度量方法，首先基于內核定義差異度量準則來計算兩個軟件架構之間的距離，然后分析對象之間的相似性。
4）SASAM方法：通過對預期架構和實際架構進行映射和比較來靜態地評估軟件架構。
5）ALRRA 方法：是軟件架構可靠性風險評估方法，使用動態復雜度準則和動態耦合度準則來定義組件和連接件的復雜性因素。
6）AHP方法：把定性分析和定量計算相結合，對各種決策因素進行處理。
7）COSMIC+UML方法：針對不同表達方式的軟件架構，采用統一的軟件度量COSMIC方法來進行度量和評估。來定義組件和連接件的復雜性因素。 來進行度量和評估。

---

3.軟件可靠性基礎知識

3.1.軟件可靠性基本概念

軟件可靠性的定義

軟件可靠性是指在規定的時間內，軟件不引起系統失效的概率。該概率是系統輸入和系統使用的函數，也是軟件中存在的缺陷函數；系統輸入將確定是否會遇到已存在的缺陷。

軟件可靠性的定量描述

軟件的可靠性是在軟件使用條件、在規定時間內、系統的輸入/輸出、系統使用等變量構成的數學表達式，如圖

可靠性的目標

軟件可靠性是指用戶對所使用的軟件的性能滿意程度的期望。可以用可靠度、平均失效時間和故障強度等來描述。

可靠性測試的意義與目的

可靠性測試的意義是：
（1）軟件失效可能造成災難性的后果。
（2）軟件的失效在整個計算機系統失效中的比例較高。
（3）相比硬件可靠性技術，軟件可靠性技術不成熟。
（4）軟件可靠性問題會造成軟件費用增長。
（5）系統對軟件的依賴性強，對生產活動和社會生活影響日益增大。
可靠性測試的目的如圖

廣義的可靠性測試與狹義的可靠性測試

（1）廣義的可靠性測試是為了最終評價軟件系統的可靠性而運用建模、統計、試驗、分析和評價等一系列手段對軟件系統實施的一種測試。
（2）狹義的可靠性測試指為了獲取可靠性數據，按預先確定好的測試用例，在軟件預期使用環境中，對軟件實施的一種測試。

3.2.軟件可靠性建模

影響軟件可靠性的因素

運行環境、軟件規模、軟件的內部結構、軟件的開發方法和開發環境、軟件的可靠性投入。

軟件可靠性模型的組成和特性

軟件可靠性模型的組成和特性，如圖

軟件可靠性建模方法分類

種子法、失效率類、曲線擬合類、可靠性增長、程序結構分析、輸入域分類、執行路徑分析方法、非齊次泊松過程、馬爾可夫過程、貝葉斯分析。

3.3.軟件可靠性管理

軟件可靠性管理的各階段

3.4.軟件可靠性設計

容錯設計技術

容錯設計技術：恢復塊設計、N版本程序設計、冗余設計。
1）恢復塊設計：選擇一組操作作為容錯設計單元，把普通的程序塊變成恢復塊。
2）N版本程序設計：通過設計多個模塊或不同版本，對相同初始條件和相同輸入的操作結果，實行多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務。
3）冗余設計：在一套完整的軟件系統之外，設計一種不同路徑、不同算法或不同實現方式方法的模塊或系統作為備份，在出現故障時可使用冗余部分進行替換。

檢錯技術

1）檢錯技術代價低于容錯技術和冗余技術，但是不能自動解決故障，需要人工干預。
2）檢錯技術著重考慮檢測對象、檢測延時、實現方式、處理方式四個要素。

降低復雜度設計

降低復雜度設計思想是在保證實現軟件功能基礎上，簡化軟件結構、縮短程序代碼長度、優化軟件數據流向、降低軟件復雜度、提高軟件可靠性。

系統配置技術

可以分為雙機熱備技術和服務器集群技術。
1）雙機熱備技術。
采用“心跳”方法保證主系統與備用系統的聯系。
根據兩臺服務器的工作方式分為雙機熱備模式（一臺工作，一臺后備）、雙機互備模式（兩臺運行相對獨立應用，互為后備）、雙機雙工模式（兩臺同時運行相同應用，互為后備）。
2）服務器集群技術。
集群內各節點服務器通過內部局域網相互通信，若某節點服務器發生故障，這臺服務器運行的應用被另一節點服務器自動接管。

3.5.軟件可靠性測試

軟件可靠性測試概述

軟件可靠性測試包括：可靠性目標的確定、運行剖面的開發、測試用例的設計、測試實施、測試結果分析等。

定義軟件運行剖面

為軟件的使用行為建模，開發使用模型，明確需測試內容。

軟件可靠性測試用例設計

測試用例要能夠反映實際的使用情況，優先測試最重要的和最頻繁使用的功能，其組成如圖11.6 所示。設計測試用例，針對組合功能或特定功能，編寫成相關文檔。

軟件可靠性測試的實施

用時間定義的軟件可靠性數據分為4類：失效時間數據、失效間隔時間數據、分組時間內的失效數、分組時間的累積失效數。 測試記錄與測試報告的組成如圖11.7所示

3.6.軟件可靠性評價

軟件可靠性評價概念

評估和預測軟件可靠性過程包括：
（1）選擇可靠性模型。
（2）收集可靠性數據。
（3）可靠性評估和預測。

如何選擇可靠性模型

可以從以下幾方面選擇可靠性模型：
（1）模型假設的適用性。
（2）預測的能力與質量。
（3）模型輸出值能否滿足可靠性的評價需求。
（4）模型使用的簡便性。

可靠性數據的收集

數據收集可行的辦法有：
（1）盡可能早地確定可靠性模型。
（2）數據收集計劃要有較強的可操作性。
（3）重視測試數據的分析和整理。
（4）充分利用技術手段（數據庫技術）來完成分析和統計。

軟件可靠性的評估和預測

（1）軟件可靠性的評估和預測的目的是評估軟件系統的可靠性狀況和預測將來一段時間的可靠性水平。
（2）軟件可靠性的評估和預測以軟件可靠性模型分析為主，以失效數據的圖形分析法和試探性數據分析技術等為輔。

---

4.軟件架構的演化和維護

4.1.軟件架構演化和定義的關系

演化的重要性

（1）保障軟件系統具備諸多好的特性。
（2）有效管控軟件系統的整體復雜性和變化性，降低軟件檢修和修改成本。
（3）保證軟件系統演化的一致性和正確性，增加便捷性。

演化和定義的關系

軟件架構包括組件、連接件和約束三大要素，此軟件架構演化主要關注組件、連接件和約束的添加、修改和刪除。

4.2.面向對象軟件架構演化過程

對象演化

對架構設計的動態行為產生影響的演化包括Add Object（AO）和Delete Object（DO）。
（1）AO 是在系統需要添加新的對象來實現某種新的功能，或需將現有對象的某個功能獨立以增加架構靈活性時發生。
（2）DO 是在系統需要移除某個現有的功能，或需合并某些對象及其功能來降低架構的復雜度的時候發生。

消息演化

消息演化包括Add Message（AM）、Delete Message（DM）、Swap Message Order（SMO）、Overturn Message（OM）、Change Message Module（CMM）。
（1）AM：增添一條新的消息，產生在對象之間需要增加新的交互行為的時候。
（2）DM：刪除當前的一條消息，產生在需要移除某交互行為的時候。
（3）SMO：交換兩條消息的時間順序，發生在需要改變兩個交互行為之間的時候。
（4）OM：反轉消息的發送對象與接收對象，發生在需要修改某個交互行為本身的時候。
（5）CMM：改變消息的發送或接收對象，發生在需要修改某個交互行為本身的時候。

復合片段演化

復合片斷的演化包括Add Fragment（AF）、Delete Fragment（DF）、Fragment Type Change（FTC）、Fragment Condition Change（FCC）。
（1）AF：在某幾條消息上新增復合片段，發生在需要增添新的控制流時。
（2）DF：刪除某個現有的復合片段，發生在需要移除當前某段控制流時。
（3）FTC：改變復合片段的類型，發生在需要改變某段控制流時。
（4）FCC：改變復合片段內部執行的條件，發生在改變當前控制流的執行條件時。

約束演化

約束演化包括Add Constraint（AC）、Delete Constraint（DC）。
（1）AC：直接添加新的約束信息，需判斷當前設計是否滿足新添加的約束要求。
（2）DC：直接移除某條約束信息，發生在去除某些不必要條件的時候。

4.3.軟件架構演化方式的分類

軟件架構演化時期

（1）設計時演化：發生在體系結構模型與之相關的代碼編譯之前。
（2）運行前演化：發生在執行之前、編譯之后。
（3）有限制運行時演化：只發生在某些特定約束滿足時。
（4）運行時演化：發生在運行時不能滿足要求時。

軟件架構靜態演化

（1）靜態演化需求：設計時演化需求、運行前演化需求。
（2）靜態演化的一般過程：軟件理解→需求變更分析→演化計劃→系統重構→系統測試
（3）靜態演化的原子演化操作。

• 與可維護性相關的架構演化操作：AMD（Add Module Dependence）、RMD（Remove ModuleDependence）、AMI（Add Module Interface）、RMI（Remove Module Inferface）、AM（Add Module）、RM（Remove Module）、SM（Split Module）、AGM（Aggregate Modules）。
• 與可靠性相關的架構演化操作：AMS（Add Message）、RMS（Remove Message）、AO（Add Object）、RO（Remove Object）、AF（Add Fragment）、RF（Remove Fragment）、CF（Change Fragment）、AU（Add Use Case）、RU（Remove Use Case）、AA（Add Actor）、RA（Remove Actor）。

軟件架構動態演化

（1）動態演化需求：軟件內部執行所導致的體系結構改變、軟件系統外部的請求對軟件進行的重配置。
（2）動態演化的類型。

• 1）軟件動態性的等級：交互動態性、結構動態性、架構動態性。
• 2）動態演化的內容：屬性改名、行為變化、拓撲結構改變、風格變化。

（3）動態軟件架構（DSA）。

• 1）基于DSA實現動態演化的基本原理是運行時刻體系結構相關信息的改變可用來觸發、驅動系統自身的動態調整。
• 2）DSA描述語言：基于行為視角的π-ADL、基于反射視角的Pilar、基于協調視角的LIME。
• 3）DSA演化工具：使用反射機制、基于組件操作、基于π演算、利用外部的體系結構演化管理器

（4）動態軟件架構應用實例—PKUAS：包括容器系統、公共服務、工具和微內核4種類型。
（5）動態重配置。

• 1）動態重配置模式：主從模式、中央控制模式、客戶端/服務器模式、分布式控制模式。
• 2）例子：可重用、可配置的產品線架構。
• 3）動態配置難點：約束定義困難、性能約束難以靜態衡量、難以管理所有方面、需同時保證組件系統完整性和重配置策略的正確和安全性。

4.4.軟件結構演化原則

軟件結構包括18種可持續演化原則：
（1）演化成本控制原則：演化成本要控制在預期的范圍之內。
（2）進度可控原則：架構演化要在預期的時間內完成。
（3）風險可控原則：架構演化中的經濟風險、時間風險、人力風險、技術風險和環境風險在可控范圍內。
（4）主體維持原則：軟件演化的平均增量的增長須保持平穩，保證軟件系統主體行為穩定。
（5）系統總體結構優化原則：使演化后的軟件系統整體結構（布局）更加合理。
（6）平滑演化原則：軟件的演化速率趨于穩定。
（7）目標一致原則：架構演化的階段目標和最終目標要一致。
（8）模塊獨立演化原則：軟件中各模塊自身的演化最好相互獨立。
（9）影響可控原則：如果一個模塊發生變更，給其他模塊帶來的影響在可控范圍內。
（10）復雜性可控原則：必須控制架構的復雜性，保障軟件的復雜性在可控范圍內。
（11）有利于重構原則：使演化后軟件架構便于重構。
（12）有利于重用原則：演化最好能維持，甚至提高整體架構的可重用性。
（13）設計原則遵循性原則：架構演化最好不能與架構設計原則沖突。
（14）適應新技術原則：軟件要獨立于特定的技術手段，可運行于不同平臺。
（15）環境適應性原則：架構演化后的軟件版本比較容易適應新的硬件環境和軟件環境。
（16）標準依從性原則：演化不違背相關質量標準（國際標準、國家標準、行業標準等）。
（17）質量向好原則：使所關注的某個質量指標或質量指標的綜合效果變更好。
（18）適應新需求原則：很容易適應新的需求變更。

4.5.軟件架構演化評估方法

演化過程已知的評估

評估流程：將架構度量應用到演化過程中，通過對演化前后的不同版本的架構分別進行度量，得到度量結果的差值及其變化趨勢，并計算架構間質量屬性距離，進而對相關質量屬性進行評估。

演化過程未知的評估

4.6.大型網站系統架構演化實例

第一階段：單體架構。 應用程序、數據庫、文件等所有資源都在一臺服務器上。
第二階段：垂直架構。 將應用和數據分離，整個網站使用3臺服務器：應用服務器、文件服務器、數據服務器。
第三階段：使用緩存改善網站性能。 包括在應用服務器上的本地緩存和在專門的分布式緩存服務器上的遠程緩存。
第四階段：使用服務集群改善網站并發處理能力。 通過負載均衡調度服務器，將來自用戶瀏覽器的訪問請求分發到應用服務器集群中的任何一臺服務器上，解決高并發、海量數據問題。
第五階段：數據庫讀寫分離。 應用服務器在寫數據時，訪問主數據庫，主服務器通過主從復制機制將數據更新同步到從服務器。在應用服務器讀數據時，訪問從數據庫。
第六階段：使用反向代理和CDN加速網站響應。CDN和反向代理的基本原理都是緩存。

• （1）CDN部署在網絡提供商的機房，用戶在請求網站服務時，可在距離最近的網絡提供商機房獲取數據。
• （2）反向代理部署在網站的中心機房，用戶請求到達中心機房后，先訪問反向代理服務器。

第七階段：使用分布式文件系統和分布式數據庫系統。 進行業務分庫，將不同業務的數據部署在不同的物理服務器上。
第八階段：使用NoSQL和搜索引擎。
第九階段：業務拆分。 將一個網站拆分成許多不同的應用，每個應用獨立部署。
第十階段：分布式服務。

4.7.軟件架構維護

軟件架構知識管理

1）架構知識的定義：架構知識=架構設計+架構設計決策。
2）架構知識管理的含義：側重于軟件開發和實現過程所涉及的架構靜態演化，在架構文檔等信息來源中捕捉架構知識，提供架構的質量屬性及其設計依據進行記錄和評價
3）架構知識管理的需求：防止關鍵的設計知識“沉沒”在軟件架構中。

軟件架構修改管理

主要是建立一個隔離區域，保障該區域中任何修改對其他部分影響最小。

軟件架構版本管理

為軟件架構演化的版本演化控制、使用和評價提供可靠依據。

軟件架構可維護性度量實踐

架構可維護性的6個度量指標：圈復雜度（CNN）、扇入扇出度（FFC）、模塊間耦合度（CBO）、模塊的響應（RFC）、緊內聚度（TCC）、松內聚度（LCC）

---

5.未來信息綜合技術

5.1.信息物理系統技術概述

信息物理系統的概念

信息物理系統（Cyber-Physical System，CPS），最早由美國國家航空航天局于 1992 年提出，后科學家海倫·吉爾給出詳細描述。信息物理系統是控制系統、嵌入式系統的擴展與延伸。CPS通過集成先進的感知、計算、通信、控制等信息技術和自動控制技術，構建了物理空間與信息空間中人、機、物、環境、信息等要素相互映射、適時交互、高效協同的復雜系統，實現系統內資源配置和運行的按需響應、快速迭代、動態優化。CPS 的本質是構建一套信息空間與物理空間之間基于數據自動流動的狀態感知、實時分析、科學決策、精準執行的閉環賦能體系，解決生產制造、應用服務過程中的復雜性和不確定性問題，提高資源配置效率，實現資源優化。

CPS的實現

CPS的體系結構分為：單元級、系統級、SOS級。

CPS技術體系主要包括CPS總體技術（頂層設計技術）、CPS支撐技術（基于應用支撐）、CPS核心技術（基礎技術）。

CPS技術了分為四大核心技術要素：“一硬”（感知和自動控制，是CPS實現的硬件支撐）、“一軟”（工業軟件，CPS核心）、“一網”（工業網絡，是網絡載體）、“一平臺”（工業云和智能服務平臺，是支撐上層解決方案的基礎）。

信息物理系統的建設和應用

CPS 典型應用場景有：
（1）智能設計方面：產品及工藝設計、生產線/工廠設計。
（2）智能生產方面：設備管理應用場景、生產管理應用場景、柔性制造應用場景。
（3）智能服務方面：健康管理、智能維護、遠程征兆診斷、協同優化、共享服務。
（4）智能應用方面：無人裝備、產業鏈互動、價值鏈共贏。

CPS 的建設路徑是：CPS體系設計、單元級CPS建設、系統級CPS建設、SOS級CPS建設

5.2.人工智能技術概述

人工智能的概念

人工智能是利用數字計算機或數字計算機控制的機器模擬、延伸和擴展人的智能，感知環境、獲取知識并使用知識獲得最佳結果的理論、方法、技術及應用系統。人工智能根據是否能真正實現推理、思考和解決問題，分為弱人工智能和強人工智能。

人工智能的發展歷程

圖靈測試→“人工智能”術語→機器學習→專家系統→計算機戰勝雙陸棋世界冠軍→決策樹模型和神經網絡→IBM深藍戰勝國際象棋世界冠軍→深度學習→爆發式發展。

人工智能關鍵技術

（1）自然語言處理：包括機器翻譯、語義理解、問答系統等。
（2）計算機視覺：如自動駕駛、機器人、智能醫療。
（3）知識圖譜：可用于發欺詐、不一致性驗證、組團欺詐等對公共安全保障形成威脅的領域。
（4）人機交互：傳統的基本交互、圖形交互、語音交互、情感交互、體感交互及腦機交互等。
（5）虛擬現實或增強現實：在一定范圍內生成與真實環境在視覺、聽覺等方面高度近似的數字化環境。
（6）機器學習。

• 1）按學習模式不同分為監督學習（需提供標注的樣本集）、無監督學習（不需提供標注的樣本集）、半監督學習（需提供少量標注的樣本集）、強化學習（需反饋機制）。
• 2）按學習方法不同分為傳統機器學習（需手動完成）、深度學習（需大量訓練數據集和強大GPU服務器提供算力）。
• 3）機器學習常見算法：遷移學習、主動學習、演化學習。

5.3.機器人技術概述

機器人的定義和發展歷程

（1）定義：具體腦、手、腳等三要素個體；具有非接觸傳感器和接觸傳感器；具有平衡覺和固定覺的傳感器。
（2）發展歷程：第一代機器人（示教再現型機器人）→第二代機器人（感覺型機器人）→第三代機器人（智能型機器人）。

機器人4.0核心技術

機器人4.0核心技術包括云—邊—段的無縫協同計算、持續學習與協同學習、知識圖譜、場景自適應和數據安全。

機器人分類

（1）按控制方式分類包括：操作機器人、程序機器人、示教再現機器人、智能機器人和綜合機器人。
（2）按應用行業分類包括：工業機器人、服務機器人、特殊領域機器人。

5.4.邊緣計算

邊緣計算概念

邊緣計算就是將數據的處理、應用程序的運行以及一些功能服務的實現，由網絡中心下放到網絡邊緣節點上。關于邊緣計算的具體定義目前有以下幾種觀點：
（1）邊緣計算產業聯盟對邊緣計算的定義：云計算在數據中心之外匯聚節點的延伸和演進，包括云邊緣、邊緣云和云化網關三類落地形態；以“邊云協同”和“邊緣智能”為核心和發展方向。
（2）OpenStack 社區的定義概念：為應用開發者和服務提供商在網絡邊緣側提供云服務和IT環境服務，目標是在靠近數據輸入或用戶的地方提供計算、存儲和網絡帶寬。
（3）ISO/IEC JTC1/SC38 對邊緣計算給出的定義：在靠近物或數據源頭的網絡邊緣側，融合網絡、計算、存儲、應用核心能力的開放平臺，就近提供邊緣智能服務。
（4）國際標準組織定義：提供移動網絡邊緣IT服務和計算能力，靠近移動用戶。

邊緣計算的特點

邊緣計算的特點包括聯接性、數據第一入口、約束性、分布性。具體內容如下：
（1）聯接性：所聯接物理對象的多樣性及應用場景的多樣性，需要邊緣計算具備豐富的聯接功能，如各種網絡接口、網絡協議等。
（2）數據第一入口：邊緣計算擁有大量、實時、完整的數據，可基于數據全生命周期進行管理與價值創造，將更好地支撐預測性維護、資產效率與管理等創新應用。
（3）約束性：邊緣計算產品需適配工業現場相對惡劣的工作條件與運行環境。在工業互聯場景下，對邊緣計算設備的功耗、成本、空間也有較高的要求。邊緣計算產品需要考慮通過軟硬件集成與優化，以適配各種條件約束，支撐行業數字化多樣性場景。
（4）分布性：邊緣計算實際部署天然具備分布式特征。這要求邊緣計算支持分布式計算與存儲、實現分布式資源的動態調度與統一管理、支撐分布式智能、具備分布式安全等能力。

邊云協同

（1）資源協同：邊緣節點提供計算、存儲、網絡、虛擬化等基礎設施資源，具有本地資源調度管理能力，同時可與云端協同，接受并執行云端資源調度管理策略，包括邊緣節點的設備管理、資源管理以及網絡連接管理。
（2）數據協同：邊緣節點主要負責現場/終端數據的采集，按照規則或數據模型對數據進行初步處理與分析，并將處理結果以及相關數據上傳給云端；云端提供海量數據的存儲、分析與價值挖掘。邊緣與云的數據協同，支持數據在邊緣與云之間可控有序流動，形成完整的數據流轉路徑，高效低成本對數據進行生命周期管理與價值挖掘。
（3）智能協同：邊緣節點執行推理，實現分布式智能；云端開展模型訓練，并將模型下發邊緣節點。
（4）應用管理協同：邊緣節點提供應用部署與運行環境，并對本節點多個應用的生命周期進行管理調度；云端主要提供應用開發、測試環境，以及應用的生命周期管理能力。
（5）業務管理協同：邊緣節點提供模塊化、微服務化的應用/數字孿生/網絡等應用實例；云端主要提供按照客戶需求實現應用/數字孿生/網絡等的業務編排能力。
（6）服務協同：邊緣節點按照云端策略實現部分ECSaaS服務，通過ECSaaS與云端SaaS的協同實現面向客戶的按需SaaS服務；云端主要提供SaaS服務在云端和邊緣節點的服務分布策略，以及云端承擔的SaaS服務能力。

邊緣計算的安全

邊緣安全的價值體現在：提供可信的基礎設施、為邊緣應用提供可信賴的安全服務、提供安全可信的網絡和覆蓋。

邊緣計算應用場合

邊緣計算應用場合包括智慧園區、安卓云與云游戲、視頻監控、工業物聯網、Cloud VR。

5.5.數字孿生體技術概述

數字孿生體的定義

數字孿生體是現有或將有的物理實體對象的數字模型，通過實測、仿真和數據分析來實時感知、診斷、預測物理實體對象的狀態，通過優化和指令來調控物理實體對象的行為，通過相關數字模型間的相互學習來進化自身，同時改進利益相關方在物理實體對象生命周期內的決策。

數字孿生體的關鍵技術

數字孿生體的核心技術：建模、仿真和基于數據融合的數字線程。

數字孿生體的應用

數字孿生體主要應用于制造、產業、城市和戰場。

5.6.云計算和大數據技術概述

云計算技術概述

“云計算”是同時描述一個系統平臺或一類應用程序的術語，包含平臺和應用。

云計算的服務方式與部署模式

1）軟件即服務（SaaS）：服務提供商將應用軟件統一部署在云計算服務器上。
2）平臺即服務（PaaS）：服務提供商將分布式開發環境與平臺作為一種服務來提供。
3）基礎設施即服務（IaaS）：服務提供商將多臺服務器組成“云端”基礎設施作為計量服務提供給客戶。
云計算的部署模式：公有云、社區云、私有云、混合云。

大數據分析步驟

數據獲取/記錄→信息抽取/清洗/注記→數據集成/聚集/表現→數據分析/ 建模→數據解釋。

大數據應用領域

制造業、服務業、交通行業、醫療行業。

---

6.系統規劃

6.1.系統規劃概述

系統規劃的主要步驟

（1）對現有系統進行初步調查。
（2）分析和確定系統目標。
（3）分析子系統的組成和基本功能。
（4）擬定系統的實施方案。
（5）進行系統的可行性研究，編寫可行性研究報告，召開可行性論證會。
（6）制訂系統建設方案。

6.2.系統調查

初步調查

在規劃階段進行初步調查可了解企業的組織結構和系統功能等。

具體包括：初步需求分析、企業基本狀況、管理方式和基礎數據管理狀況、現有系統狀況。

詳細調查

詳細調查則可以深入了解系統的處理流程。調查的內容有：現有系統的運行環境和狀況、組織結構、業務流程、系統功能、數據資源與數據流程、資源情況、約束條件和薄弱環節等。

6.3.成本效益分析技術

成本

固定成本

是指其總額在一定時期和一定業務量范圍內，不受業務量變動的影響而保持固定不變的成本。如管理人員的工資、辦公費、固定資產折舊費、員工培訓費等。

變動成本

也叫可變成本，指在一定時期和一定業務量范圍內其總額隨著業務量的變動而成正比例變動的成本。如直接材料費、產品包裝費、外包費用、開發獎金等。

混合成本

即混合了固定成本和變動成本的性質的成本。這些成本通常有一個基數，超過這個基數就會隨業務量的增大而增大。如質量保證人員的工資、設備動力費等成本在一定業務量內是不變的，超過了這個量便會隨業務量的增加而增加。

盈虧臨界點

盈虧臨界點也稱盈虧平衡點或保本點，是指項目收入和成本相等的經營狀態，就是既不盈利又不虧損的狀態。相關公式如下：
（1）利潤＝(銷售單價?單位變動成本)×銷售量?總固定成本。
（2）盈虧臨界點銷售量＝總固定成本/(銷售單價?單位可變成本)。
（3）盈虧臨界點銷售額＝總固定成本/(1?總可變成本/銷售收入)。