歡迎大家進入我們的個人博客網站一起交流討論。http://codeingshuang.com

目錄

• 緒論
• 第一章 軟件工程和軟件設計概述
• 第二章 軟件模型和描述
• 第三章 軟件體系結構建模和UML
• 第四章 軟件設計過程
• 第五章 軟件體系結構風格

緒論

案例一：圣·瑪麗亞大教堂
案例二：瑞典瓦薩戰艦
由建筑體系架構——>軟件體系結構。
總體的系統結構設計比計算算法和數據結構更為重要。

1.軟件體系結構發展史
高級語言 面向過程開發 面向對象開發 面向服務開發 云和移動服務開發 智能化軟件開發。

無體系結構——>概念和理論體系形成——>理論完善且普及應用
體系結構出現：1968年北大西洋公約組織（NATO）會議上第一次出現詞語“Software Architecture”（軟件體系結構/軟件架構）。

概念體系和理論體系形成：軟件體系結構定義逐漸明確，相關書籍出版。

理論完善與普及應用：1999年，1st IFIP軟件架構會議召開；Markup架構描述語言提出，支持廣泛的模型架構共享；軟件產品線被提出，引起了大量大型企業的關注；IEEE 1471—2000發布，為軟件架構普及定制標準化規范。

2.軟件體系結構定義
軟件體系結構=組件+連接件+約束
組件：具有某種功能的可重用的軟件模塊單元，表示了系統中重要的計算單元和數據存儲。
連接件：表示組件之間的交互。簡單連接件有：管道，過程調用，事件廣播等；復雜連接件有：客戶—服務器通信協議，數據庫和應用之間SQL連接。
約束：表示組件和連接件的拓撲邏輯和約束。

3.軟件體系結構的研究活動
軟件體系結構要解決的問題，軟件體系結構研究的內容，自適應軟件體系結構。

4.軟件體系結構的作用
軟件生命周期中的作用

第一章 軟件工程和軟件設計概述

1.1軟件的本質
軟件是一系列按照特定順序組織的計算機數據和指令的集合。
軟件不是有形的物理產品，而是人類思維的產物。
軟件不是被制造出來的 ，而是思考出來的。
軟件的限制—>軟件的復雜性

軟件特質和分類：

• 軟件是設計開發的
• 軟件不會磨損和老化
• 隨著構建構造模式的發展，軟件需要根據客戶需要定制
• 不斷變更是軟件退化的根本原因

軟件分類：

• 系統軟件
• 應用軟件
• 嵌入式軟件
• 科學和工程計算軟件產品線軟件
• 產品線軟件
• 人工智能軟件
• Web應用軟件

2.軟件工程
2.1軟件工程是：（1）將系統化的，規范化的，可量化的方法應用于軟件開發、運行和維護，即將工程化方法應用于軟件。（2）對（1）中所述的方法進行研究。

2.2軟件過程和軟件工程實踐
軟件過程：是工作產品構建時所執行的一系列活動、動作、任務的集合。

• 活動：實現寬泛的目標。
• 動作：包含了主要工作產品生產過程中的一系列任務。
• 任務：關注小而明確的目標，能夠產生實際產品。

2.一個通用的軟件工程過程包含一下5個內容活動：溝通，策劃，建模，構建，部 署。
3.軟件工程和軟件過程實踐——七條原則：存在價值，保持簡簡潔，保持愿景，關 注 使用者，面向未來，計劃復用，認真思考。

2.3網絡環境帶來的影響
（1）計算機軟件 = 程序 + 數據結構 + 文檔
（2）計算機軟件 = 滿足需求的信息 + 服務工具

3.軟件設計
3.1軟件工程過程中的設計
軟件設計在軟件工程過程中處于核心技術。

• 分析模型
• 數據/類設計
• 體系結構設計
• 接口設計
• 構建級設計

3.2軟件設計原則

• 抽象（過程抽象/數據抽象）
• 體系結構
• 模式
• 模塊化
• 信息隱蔽
• 功能獨立（內聚/耦合）
• 求精
• 重構
• 設計類（用戶接口類/業務域類/過程類/持久類/系統類）

軟件設計原則——設計類：完整性和充分性，原始性，高內聚性，低耦合性。
體系結構與設計：體系結構是系統設計的一部分，突出了某些細節，并通過抽象省略掉一些細節。所以，體系結構是設計的一個子集。

3.3軟件體系結構的內容——體系結構的研究領域
(1)通過提供一種新的體系結構描述語言解決體系結構描述問題
(2)體系結構領域知識的總結性研究
(3)針對特定領域的框架的研究
(4)軟件體系結構形式化支持的研究

3.4軟件體系結構設計方法：是指通過一系列的設計活動，獲得滿足系統功能性需求，并符合一定非功能性需求約束的軟件體系結構模型。
軟件體系結構設計方法分類：
(1)FR驅動的軟件體系結構設計
(2)NFR驅動的軟件體系結構設計
(3)集合FR和NFR的方法

3.5軟件體系結構設計經驗總結與復用
軟件體系結構所采用的主要手段：
（1）體系結構風格和模式

• 非形式化描述模型，并將其引入到體系結構設計過程中。
• 提供形式化規約，精確的說明風格的特征，并用于高層性質驗證

（2）領域特定的軟件體系結構和軟件產品線

第二章 軟件模型和描述

2.1什么是軟件模型

• 模型：一般指客觀世界中事物存在的一種抽象，事物可以是具體的，也可以是抽象的。
• 模型表達方法：用數學語言表達的模型稱為數學模型（形式化最高級別）；使用自然語言或圖形語言表達的模型是定性的描述（形式化級別較低）。
• 軟件模型：軟件的一種抽象，一般通過非數學模型來描述。

軟件模型可以看作是一種元模型。
軟件模型作為軟件組成的最基本單元的抽象，既反映軟件體系結構構建的核心思想，也奠定了軟件體系結構構建的基礎。

2.2軟件模型的發展歷程
功能模型—>對象模型—>組件模型—>配置型組件模型—>服務模型—>抽象模型

2.3軟件模型解析
1.功能模型
功能模型也可以成為過程模型或函數模型，它是模型化軟件構件方法的第一基本模型。
功能模型的基本原理：將一個系統分解為若干個基本功能模塊，基本功能模塊之間可以根據需求進行調用。
基本功能模型的抽象和耦合
功能模型的核心
遞歸思想的具體實現

2.對象模型
對象模型：以對象為核心，通過對象進行數據組織的抽象并實現數據組織和數據處理的統一，并在此基礎上建立面向對象的軟件構造方法。
對象模型的基本原理：將一個系統分解為若干個對象，對象之間可以通過發送消息按需求進行協作。
數據類型的抽象：允許用戶按需根據定義自己的數據類型：

• 對象模型的核心
• 同構（或同族）
• 對象關系的定義：體現在繼承和多態兩方面

3.組件模型
3.1組件模型：在對象模型的基礎之上，強調異族對象關系以及獨立性問題。
異族對象關系：組件內部完成組件功能的對象可以是同族的，也可以是異族的。
獨立性：組件建立在二進制基礎之上并獨立封裝，可以獨立部署。

3.2組件模型以接口為核心，通過接口抽象組件行為，并在此基礎上建立面向接口 的軟件構造方法。接口：值對象動態行為的集合，支持繼承機制。組件：能完成特 定功能并能獨立部署的軟件合成單元，一個組件一般具有一個多個接口，每個 接口的功能由一個或多個方法實現。

3.3組件對象模型是基于Windows平臺的一套組件對象接口標準，由一組構造規范 和組件對象庫組成。

3.4一般的對象由數據成員和作用在其上的方法組成，而組件對象與一般的對象雖 有相似性，但也有較大不同。組件對象不使用方法而是接口描述自身。

3.5接口被定義為“在對象上實現的一組語義上相關的功能”，其實質是一組由組件 實現的提供給客戶使用的函數，是一個包含函數指針數組的內存結構，數組元素是 一個由組件實現的函數地址。

3.6一個組件對象實現的接口數量沒有限制。
3.7框架：已實現部分功能的某類程序結構的實現。

3.8框架分類：（1）水平型：一般面向通用類程序的構造，與特定的應用領域無關。 （2）垂直型：一般面向特定應用領域，它抽象和封裝了該應用領域程序的基本構 造和共性基本組件。（3）符合文檔型：是一種比較通用的框架，它將一個程序抽象 為一個文檔，將構造程序的各個組件看作是文檔中不同的的獨立元素，這些獨立元 素通過事件消息相互聯系。

4.配置型組件模型
配置型組件模型又稱為服務器組件模型，它專門針對應用服務器，定義其基于組件 的基礎結構模型。
配置型組件模型的基本原理：將應用業務邏輯與系統基礎服務兩者解耦，由系統基 礎服務構成一個服務容器，自動隱式的為各種業務邏輯按需統一提供相應的基礎服 務。應用業務邏輯可以按需提出不同的基礎服務要求，即他是可配置的。

5.服務模型
服務：指一個封裝著高級業務概念、實現公共需求功能、可遠程訪問的獨立應用程 序模塊。
服務一般由數據、業務邏輯、接口及服務描述構成。
服務模型的基本原理：明確服務提供者和服務使用者，并通過服務中介實現兩者的 耦合。
服務模型的標準主要是Web Services.

6.抽象模型
基于歸納思維策略的可恢復程序語句組件模型
抽象模型
基于演繹思維策略的元模型
兩者都是面向抽象層的應用業務邏輯的描述，而不關注描述的具體實現平臺和環境，具有完整的技術獨立性和應用發展的適應性。

2.4深入認識軟件模型
２.４.１軟件體系結構的描述

• 軟件體系結構的描述指的是通過某種語言表達軟件體系結構。
• 描述的目的是為了實現對軟件體系結構的認識、理解和交流。
• 進而，基于描述，可以對軟件系統的各種行為和特征進行各種理論分析和仿真模擬， 以及實現軟件系統代碼的自動生成。

２.４.２軟件體系結構的描述—非形式化描述
典型代表——UML（一種通用的可視化建模語言）
非形式化描述的缺陷：

• 語義含糊
• 由語義含糊引起的溝通障礙
• 無法實現系統驗證

不適于描述體系結構行為
２.４.３軟件體系結構的描述—形式化描述
用于軟件和硬件系統的說明、開發和驗證的數學化方法。
理論基礎是數學化理論。

形式化的特點：

• 可以用于系統描述，并且可以在不同層次上進行描述
• 在體系結構行為描述上更勝一籌
• 使得系統驗證變得可行

２.４.４軟件體系結構的描述—典型的形式化描述

• Petri網
• Z語言
• 形式化描述的本質在于抽象，抽象的級別不同將導致方法的適用的范圍不同。

形式化描述存在的問題：

• 說明與實際代碼間的差距仍然巨大
• 受本身性質所限，形式化描述方法很難與軟件開發過程整合

２.４.５軟件體系結構的設計

• 基本任務：識別出構成系統的子系統并建立子系統控制和通信的基本框架，以滿足 系統功能性和非功能性需求。
• 軟件體系結構設計：使用某種體系結構描述方法或語言，通過某種設計工具和環境， 針對一個特定的軟件系統的構造，為其邏輯構成做出決策的一種創造性活動。
• 水平型設計：運用通用建模設計工具和表達語言所進行的軟 件體系結構的設計。
• 垂直型設計：運用面向體系結構的專用建模設計工具及其表 達模型所進行的軟件體系結構的設計。

２.５ADL簡介
體系結構描述語言：一種用于描述體系與體系結構的計算機語言，它可以在指定的抽象 層次上描述軟件體系結構。
ADL關注抽象層次上的整體結構而不是任意代碼模塊的實現細節，作為一種經典理論， Shaw和Garland定義了ADL的元素：

• 構件：抽象級別上組成系統的計算模塊。
• 操作：構件之間的交互機制。
• 模式：構建元素依照特定方式進行的組合。
• 閉包用于實現分層描述的概念。
• 規格說明：包括功能、性能、容錯能力等。

第三章 軟件體系結構建模和UML

3.1軟件體系結構建模概述
體系結構模型分為以下五類：

• 結構模型

• 框架模型

• 動態模型

• 過程模型

• 功能模型

3.2基于軟件體系結構的開發
體系結構的軟件開發過包括以下主要活動：
1.通過對特定領域應用軟件進行分析，提煉其中的穩定需求和易變需求，建立可 復用的領域模型。
2.在領域模型的基礎上提煉特定領域的軟件體系結構。
3.低層設計主要解決具體構件和連接件的設計問題，通過復用設計件庫中存放的 設計模式、對象和其他類型的可復用設計件，或根據情況設計情的構件，并提煉入 庫。低層設計的結果可以直接編程實現。

體系結構——>宏觀上描述系統的總體構件——>高層設計
設計模式和對象——>從微觀上解決設計的問題——>低層設計

3.3UML概述
3.3.1UML的特點和用途

• 統一標準
• 面向對象的特征
• UML在演變過程中還提出一些新的概念
• 獨立于過程
• UML對系統的邏輯模型和實際模型都能清楚地表示，可以用于復雜軟件系統 的建模

3.3.2UML2.0的建模機制

• 語言定義精確度提高
• 改良的語言組織
• 重點改進大規模的軟件系統模型性

3.4面向對象方法
面向對象方法學的出發點和基本原則是盡可能模擬人類習慣的思維方式，使開發軟件的 方法與過程盡可能接近人類認識世界、解決問題的方法與過程。
面向對象構造法則：

• 區分對象及其屬性
• 區分整體對象及其組成部分
• 不同對象類的形成以及區分

3.4.1 面向對象方法中的基本概念
（1）對象：對象指的是一個獨立的、異步的、并發的實體。
（2）類：類的定義，包括一組數據屬性和在數據上的一組合法操作。
（3）繼承性：廣義地說，繼承是指能夠直接獲得已有的性質和特性，而不必反復 定義他們。
（4）多態性：指子類對象可以向父類對象那樣使用，同樣的消息既可已發送給父 類對象也可以發送給子類對象。
（5）重載：有兩種重載：函數重載是指在同一作用域內的若干個參數特征不同的 函數可以使用相同的函數名；運算符重載是指同意運算符可以施加于不同類型的操 作數上面。
（6）消息和方法：在面向對象領域，兩個對象的賈湖是通過消息的發送和接收來 完成的。消息分為簡單消息、同步消息和異步消息。
（7）聚集：在客觀世界中有若干類，這些類之間有一點的結構聯系。通常有兩種 主要的結構聯系，即一般——具體結構關系，整體——部分結構關系。

3.4.2 面向對象方法的優勢

• 支持軟件的重用性
• 提高軟件可維護性和安全性

3.5 UML2.0中的結構建模
UML2.0中的結構建模包括：

• 類圖
• 包圖
• 對象圖
• 構件圖
• 組合結構圖
• 部署圖

3.5.1 類圖——類
（1）類是來描述具有相同特征、約束和語義的一樂對象，這些對象具有共同的操 作和屬性。
（2）類圖中的類可以簡單的只給出類名，也可以具體的列出該類擁有的成員變量 和方法，甚至更詳細的描述可見性、方法參數、變量類型等信息。

3.5.2 類圖——抽象類
（1）抽象類是指只提供操作名，而不對其進行實現。
（2）對這些操作的實現可以由其子類實現，并且不同的子類可以對同一操作具有 不同的實現。

3.5.3 類圖——接口
3.5.4 類圖——關聯關系
（1）描述了類結構之間的關系。
（2）當關聯使雙向的，那么就可以用無向連線表示。
（3）一般的關聯關系語義較弱。也有兩種語義較強，分別是聚合和組合。

3.5.5 類圖——依賴關系
（1）兩個類之間存在依賴關系，表明一個類使用或需要知道另一個類中包含的信 息。
（2）有多種形式，例如綁定、友元等。

3.5.6 類圖——聚合關系
3.5.7 類圖——合成關系
3.5.8 類圖——聚合關系與合成關系的區別
（1）聚合關系使has-a關系，組合關系是contains-a關系。
（2）聚合關系表示整體與部分的關系較弱，組合關系表示比較強。

3.5.9 類圖——泛化關系
泛化關系在面向對象中一般稱為繼承關系，存在于父類與子類，父接口與子接口之間。

3.5.10 對象圖
對象是類的實例，對象圖可以看作類圖的實例，對象之間的連接是類之間關聯關系 的實例。
對象圖顯示類的多個對象實例而不是真實的類。

3.5.11 構件圖
(1)構件圖用于靜態建模，是表示構建類型的組織以及各種構件之間依賴關系的圖。
(2)構建通過對構件間依賴關系的描述來估計修改系統構件可能給系統帶來的影響。
(3)構件的根本特征在于它的封裝性和可復用性，其內部構件被隱藏起來，只能通過接口向外部提供服務或請求外部的服務。
(4)構件是系統中遵從一組接口且提供其實現的物理的、可替換的部分。
(5)構件能獨立完成功能，它是軟件系統的組成部分。

3.5.12 部署圖
（1）部署圖描述的是系統運行時的，展示了硬件的配置及其軟件如何部署到網絡 結構中。
（2）一個系統模型只有一個部署，部署圖通常用來理解分布式系統。

3.5.13 行為建模（動態建模）
行為建模：刻畫系統中的動態行為、動作和過程。
UML行為建模中提供的試圖可以從不同側面描述軟件系統的動作過程。
1.用例圖
（1）用例圖定義：

• 被稱為參與者的外部用戶所能觀察到的系統功能的模型圖
• 用例圖列出了系統中的用例和系統外的參與者，并顯示哪個參與者參與了哪個用例的執行
• 用例圖多用于靜態建模階段（主要業務建模和需求建模）
• 參與者：指在系統外部與系統直接交互的人或事物。

用例：

• 用例的定義：是系統外部可見的一個系統單元。
• 參與者與用例之間的關系：關聯表示參與者與用例之間的交互、通信途 徑。

用例之間的關系：

• 包含：箭頭指向的用例為被包含的用例，稱為包含用例；箭頭出發 的 用例為基用例。包含用例是必選的，如果缺少包含用例，基用例 就不完整；包含用例必須被執行，不需要滿足某種條件，器質性不會 改變基用例的行為。
• 拓展：箭頭執行的用例為被拓展的用例，稱為拓展用例；箭頭出發 的用例為基用例。拓展用例是可選的，如果缺少拓展用例，不會影響 基用例的完整性，拓展用例在一定條件下才會執行，并且其執行會改 變基用例的行為。
• 參與者之間的關系：泛化關系是一般和關系，發出箭頭的一方表示特殊 的一方，箭頭指向的一方代表一般的一方，特殊的一方繼承了一般方的特 性并增加了新的特性。

2.順序圖

• 順序圖描述對象之間的動態交互關系，著重表現對象間消息傳遞的時間順序。
• 順序圖有兩個坐標軸：縱坐標軸表示時間，橫坐標軸表示不同的對象。
• 順序圖中的對象用一個矩形框表示，框內表有對象名。從表示對象的矩形框向下的垂直虛線是對象的“生命線”，用于表示在某段時間內該對象是存在的。

3.通信圖
通信圖主要關注參與交互的對象通過連接組成的結構。

4.交互概覽圖
交互概覽圖有兩種形式：

• 以活動圖為主線
• 以順序圖為主線

5.時序圖
時序圖是顯示對象之間交互的圖。這些對象是按時間排列的，時序圖中顯示的是參與交互的對象及其對象之間消息交互的順序。

6.狀態圖
狀態圖使用有窮狀態變遷圖的方式刻畫系統或元素的離散行為，可以用來描述一個類的實例、子系統甚至整個系統在其生存周期內，所處狀態如何隨外部刺 激而發生變化。

7.活動圖

• 活動圖是UML用于對系統的動態行為建模的另一種常用工具，他描述活動的順序，展現從一個活動到另一個活動的控制流。
• 活動圖在本質上是一種流程圖，是內部處理驅動的流程。
• 活動圖主要用于：業務建模時，用于詳述業務用例，描述一項業務的執行過程；設計時，描述操作的流程。
• UML活動圖包含的元素有動作狀態、活動狀態、動作流、分支與合并（分叉與匯合）、泳道和對象流等。

第四章 軟件設計過程

4.1軟件設計基礎
軟件設計主要針對需求分析過程得到的軟件需求規格說明，綜合考慮各種制約因素，探 求切實可行的軟件解決方案并最終給出方案的邏輯表示，包括文檔、模型等。
軟件設計的主要活動：
（1）軟件設計計劃

• 明確設計過程的輸入制品并使其處于就緒狀態

• 定義設計過程的目標、輸出制品及驗收準則

• 確定覆蓋設計過程中各個階段的全局性設計策略

• 分配設計過程中相關人員的職責

• 針對設計過程中的活動指定設工作計劃

（2）體系結構設計
目標是建立軟件系統的體系結構，有時也稱“頂層設計”。
在軟件體系結構設計過程中，需要注意以下規則：

• 改進軟件結構，提高模塊獨立性
• 模塊規模應該適中
• 深度、寬度、扇入、扇出都應該適當
• 模塊的作用域應該在控制域之內
• 力爭降低模塊接口的復雜程度
• 設計單入口、單出口模塊
• 模塊功能應該可以預測

（3）界面設計

• 結構設計
• 交互設計
• 視覺設計

良好的用戶界面一般都符合下列用戶界面規范：

• 易用性原則
• 規范性原則
• 幫助設施原則
• 合理性原則
• 美觀與協調性原則
• 容錯性考慮原則

（4）模塊/子系統設計
設計目標：

• 確定模塊的具體接口定義，并設計模塊的內部結構
• 盡量保持模塊的功能獨立性，遵循“高內聚，低耦合”的設計思想
• 力求將模塊的影響限制在模塊的控制范圍之內，使得軟件的日后修改和維護工作更加簡單

（5）過程/算法設計
主要任務是對模塊內部工作和執行過程進行描述，給出有關處理的精確說明。
（6）數據模型設計

• 把數據結構設計，數據庫設計，甚至數據文件設計都統一稱為數據模型設計
• 持久數據操作

4.2軟件體系結構設計
軟件設計一般首先設計軟件體系結構設計，然后再逐步精化進行更詳細的設計，知道設計可以被實現的程度。
軟件體系結構的設計方法是指通過一系列的設計活動，獲得滿足系統能性需求，并且符合一定非功能性需求約束的軟件體系結構模型。
（1）多重視圖建模（包含邏輯、開發、物理、過程視圖）
（2）基于評估與轉換的設計方法
對體系結構進行轉換可以通過下述三種方式實現：

• 使用合適的體系結構分割和模式，或者設計模式來改進體系結構設計。
• 把非功能性需求轉換為功能性解決方案，該功能性方案可以與問題與無關，但可以滿足質量屬性的要求。

（3）模式驅動的設計方法
常用的軟件體系結構風格如下：

• 數據流風格：批處理和管道/過濾器
• 調用/返回風格：主程序/子程序、層次結構和客戶機/服務器
• 面向對象風格
• 獨立部件風格：進程通訊和事件驅動
• 虛擬機風格：解釋器和基于規則的系統
• 數據共享風格：數據庫系統和黑板系統

（4）領域特定的軟件體系結構設計方法
領域特定的軟件體系結構是領域工程的核心部分，領域工程分析應用領域的共同特征和可變特征，對刻畫這些特征的對象和操作進行選擇和抽象，形成領域模型，并進一步生成DSSA。
DSSA與體系結構風格的區別：

• DSSA和軟件體系結構風格是從不同角度出發研究問題的兩種結果，前者從問題域出發，后者從解決域出發。
• DSSA只在某個特定的領域中進行經驗知識的提取、總結和組織，但可以使用多種軟件體系結構風格；而一種軟件體系結構風格所呈現的公共結構和設計方法可以拓展到多個應用領域。
• DSSA的體系結構表示和工具一般只適用于較小的范圍，在其他領域中是不適用并難以復用的。

（5）軟件產品線
指一組可管理的，具有公共特性的軟件應用系統的集合。
軟件產品線的主要組成部分：核心資源和軟件產品集合。
軟件產品的基本活動包括核心資源開發，利用核心資源的產品開發以及在這兩部風 中所需要的技術協調和組織管理。
在一個軟件產品線中，新產品形成的步驟如下：

• 從公共資產庫中選取合適的構件
• 使用預定義變化機制進行裁剪，如參數化，繼承等
• 必要時增加新的構件
• 在整個產品線范圍內公共的體系結構指導下進行構件的組裝，形成系統

（6）其他軟件體系結構設計方法
（1）基于目標圖推理的體系結構設計方法：該方法的目標是使模式背后的推理顯 示化，并且服從于系統的分析；該方法使用目標圖，表達模式在各種需求上的應用 效果。
（2）基于屬性的體系結構設計方法：是對通常體系結構風格描述的一種擴充，用 于獲取結構化分析SA層次上的結構和分析技巧，顯式地把推理框架（定性或定量） 與體系結構風格關聯起來。

4.3高可信軟件設計
（1）可信軟件的特點：

• 可信軟件：是指軟件系統的的運行行為及其結果總是符合人們的預期，而且在受到干擾時仍能提供聯系服務。
• 軟件系統的可信性質：只是該系統需要滿足的關鍵性質，當軟件系統一旦違背這些性質，會造成不可容忍的損失時，稱這些性質為高可信性質。

（2）軟件可信性質分為以下幾種：

• 可靠性：在規定的環境下、規定的時間內軟件無失效運行的能力。
• 可靠安全性：軟件運行不引起危險、災難的能力。
• 保密安全性：軟件系統對數據和信息提供保密性、完整性、可用性、真實性保障的能力。
• 生存性：軟件在受到攻擊或失效出現時連續提供服務并在規定時間內恢復所有服務的能力。
• 容錯性：軟件在故障（硬件，環境異常）出現時保證提供服務的能力。
• 實時性：軟件在規定時間內完成反應或提交輸出的能力。

（3）容錯設計

• 完全防止軟件失效在實踐中不可能的，任何試圖消除軟件失效的方法都會導致很高的成本，并且不能保證時效不會發生。
• 為了保證高可信系統即使在極端條件下也能按其規格說明執行，對硬件和軟件同時采用容錯計算非常重要。
• 為了達到硬件容錯，需要對所有關鍵硬件部件進行備份，為了軟件免受故障的影響，軟件邏輯和數據也必須備份。

恢復塊
軟件容錯設計方法
N—板塊編程
設計多樣性可以通過以下幾種方式達到：

• 使用不同的設計方法來實現需求
• 使用不同的程序設計語言來完成
• 使用不同的開發工具，且在不同的開發環境中完成
• 明確要求在實現某些關鍵過程時使用不同的算法

（4）軟件失效模式和影響分析
軟件失效模式和影響分析主要是在軟件開發階段的早期，通過識別軟件失效模式，研究分析各種失效模式產生的原因及其造成的后果，尋找消除和減少有害 后果的方法，以盡早發現潛在問題，并采取相應措施，從而提高軟件的可靠性 和安全性。

• 軟件失效：泛指程序在運行中喪失了全部或部分功能、出現偏離預期的正常狀態的事件。
• 軟件失效模式：指軟件失效的不同類型，通常用來描述軟件失效發生的方式，以及對設備運行可能產生的影響。
• 軟件失效的影響：指軟件失效模式對軟件系統的運行、功能或狀態等造成的后果。

（5）軟件故障樹分析
軟件故障樹是在軟件系統設計過程中，通過對可能造成系統故障的因素（包括硬件、軟件、環境、人為等因素）進行分析，畫出邏輯框圖（即故障樹），從而確定系統故障原因的各種可能組合，采取相應的糾正措施，提高系統可靠性的一種設計分析方法。
（6）形式化方法
形式化方法是在計算系統的開發中進行嚴格推理的理論、技術和工具，主要包括形式規約技術和形式驗證技術。
形式規約技術：使用具有嚴格數學定義語法和語義的語言刻畫軟件系統及其性質，可以盡早發現需求和設計中的錯誤、歧義、不一致和不完全。、
形式驗證技術：是在行使規約的基礎上建立軟件系統及其性質的關系，即分析系統是否具有所期望性質的過程，主要分為模型檢驗和定理證明。

4.4軟件設計規格說明

• 軟件設計過程中的各個活動的結果應該文檔化，形成正式的軟件規格說明，作為軟件設計的輸出。
• 形成的軟件規格說明將被評審，并作為后續軟件實現的依據。
• 軟件設計規格說明并沒有統一的格式，例如IEEE標準、IOS標準、各行業標準所建議的格式不盡相同。
• 使用不同的軟件設計方法學所得的設計模型也會有很大不同，導致設計規格的說明也會明顯不同。

4.5軟件設計評審
軟件設計評審的目標是確保軟件設計規格說明書能夠實現所有的軟件需求，及早發現設計中的缺陷和錯誤，并確保設計模型已經精化到合格的軟件實現工程師能夠構造出符合軟件設計者期望的目標軟件系統。
設計評審中需要重點關注的內容包括：

• 設計模型是否能夠充分地、無遺漏地支持所有軟件需求的實現。
• 設計模型是否已經精化至合理的程度，可以確保合格的軟件實現工程師能夠構造出符合軟件設計者期望的目標軟件系統。
• 設計模型的質量屬性，即設計模型是否都已經充分的優化，以確保依照設計模型構造出來的軟件產品能夠表現出良好的軟件質量屬性。

為了使設計評審達到預期效果，下面給出設計評審的一些建議性原則：

• 對產品進行評審，而不是開發人員
• 要有針對性，不要漫無目的
• 進行有限的爭辯
• 闡述問題所在，但不要嘗試去解決問題
• 要求事先準備，如果評審人你沒有準備好，則取消會議重新安排時間
• 為被評審的產品開發一個檢測表
• 缺點軟件元素是否遵循規格說明或標準，記錄任何不一致的地方
• 列出發現的問題、給出建議和解決該問題的負責人
• 堅持記錄并文檔化

第五章 軟件體系結構風格

5.1軟件體系結構風格概述

• 軟件體系結構設計的一個核心問題是能否使用重復的體系結構模式，即能否達到體系結構級的軟件重用。

• 能否在不同的軟件系統中使用同一種體系結構。

• 軟件體系結構風格是描述某一特定應用領域系統組織方式的慣用模式。體系結構風格定義一個系統家族，即一個體系結構定義一個詞匯表和一種約束。

• 體系結構風格反映了領域中眾多系統所共有的結構和語義特征，并指導如何講各個模塊和子系統有效地組織成一個完整的系統。

• 按照這種方式理解，軟件體系結構風格定義了描述系統的術語表和知道構建系統的規則。

5.2管道—過濾器
在管道—過濾器模式下，功能模塊成為過濾器；功能模塊間的連接看作是輸入、輸出數據流的通道，所以稱為管道。
（1）適應的設計問題
如果要建立一個必須處理或轉化輸入數據流的系統，用單個組件實現會顯得臃腫，需求不容易變動，所有可能要通過替換或重新排列處理步驟為靈活性做規劃。處理步驟的內部鏈接必須考慮一下步驟：

• 未來系統的升級通過替換處理步驟或重組處理步驟就能完成
• 不同的語境中小的處理步驟要比組件更易于重用
• 不相連的處理步驟不共享信息
• 存在不同的輸入數據源，例如網絡連接或通過硬件傳感器提供讀數
• 可以用多種方式給出或存放最終結果
• 明確存放中間結果
• 可能有并行或異步處理的要求

（2）解決方案

• 管道—過濾器的體系結構模式把系統任務分成幾個連貫的處理步驟。這些步驟通過系統的數據流鏈接，一個步驟的輸出是下一個步驟的輸入。
• 每個處理步驟由一個過濾器組件實現
• 過濾器消耗或轉發增長的數據，在產生輸出之前消耗它的所有輸入以達到低延遲并能夠真正的處理。
• 數據源、過濾器和數據匯點由管道順序連接起來，實現相連處理步驟間的數據流動。
• 通過管道聯合的過濾器序列稱為處理流水線。
• 從整個系統的輸入和輸出關系來看，各個過濾器對其輸入進行局部的地理處理交換，就可以產生部分計算結果。
• 過濾器按照激活方式可以分為被動式過濾器（通過函數或過程調用激發）和主動式過濾器（作為獨立的線程任務激發工作）。
• 過濾器是獨立運行的部件，不受其他過濾器的影響；非臨近的過濾器不共享任何狀態，自身也是無狀態的。
• 整個結果的正確性不依賴于各個過濾器運行的先后次序。

每種風格具有以下特征：

• 構建即過濾器，對輸入流進行處理轉換，處理的結果在輸出端流出。而這種計算常常是遞進的，所以可能在所有輸入接受完之前就開始輸出，可以并行地使用過濾器。
• 連接件位于過濾器之間，起到信息流的導管作用，即管道。
• 每個管道都有輸入/輸出集合 ，構建在輸入處讀取數據流，在輸出出生成數據流。
• 過濾器必須是獨立的實體。

采用管道—過濾器模式建立的系統具有如下優點：

• 由于每個構建的行為不受其他構建的影響，因此整個系統的行為比較易于理解。
• 支持功能模塊的復用。任意兩個過濾器只要在相互的輸入、輸出管道管道格式上達成一致，就可以連接在一起。
• 具有較強的可維護性和可拓展性。可維護性體現在系統過濾器部件的更新或升級。
• 支持特殊的分析：如吞吐量計算和死鎖檢測等。
• 支持并發執行。

管道—過濾器的不足：

• 往往會導致系統處理的成批操作。
• 在處理兩個獨立但又相關的數據流時可能會遇到困難。
• 在需求對數據傳輸處理進行特定的處理時，會導致對于每個過濾器的解析輸入和格式化輸出要做更多的工作，從而帶來系統復雜性的上升。根據實際設計的要求，需求對數據傳輸進行特定處理（如為了防止數據泄露而采取加密手段），導致過濾器必須對輸入、輸出管道中的數據流進行解析或反解析，增加了過濾器具體實現的復雜性。
• 并行處理獲得的效率往往是一種假象。

5.3數據抽象和面向對象風格

• 該風格建立在數據抽象和面向對象的基礎之上，數據的表示方法和它們相應的操作封裝在一個抽象數據類型或對象中。
• 該風格的構建是對象，或者說是抽象數據類型的實例。
• 對象是一種被稱為管理者的構件，因為它負責保持資源的完整性。
• 對象是通過函數和過程調用來交互的。

優點：

• 因為對相對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他的對象。
• 設計者可以將一些數據存取操作的問題，分解為一些交互代理程序的集合。

缺點：

• 為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識，只要一個對象的標識變了，就必須修改所有其他明確調用它的對象。
• 必須修改所有顯式調用它的其他對象，并消除由此帶來的一些副作用。

5.4基于事件的隱式調用風格

• 基于事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。
• 系統中的其他構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致另一個模塊中的過程調用。

主要特點：事件的觸發者并不知道哪些構件會被這些事件影響。
優點：

• 為軟件重用提供了強大的支持。當需要將一個構件加入現存系統時，只需將它注冊到系統的事件中。
• 為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響其他構件的接口。

缺點：

• 構件放棄了對系統計算的控制。
• 數據交換的問題。
• 既然過程的語義必須依賴于被觸發事件的上下文約束，關于正確性的推理就存在問題。

5.5分層系統風格

• 所謂分層系統，就是按層次組織軟件的一種軟件體系結構，其中，每一層軟件建立在第一的軟件層上。
• 位于同一層的軟件系統或子系統具有同等的通用性，在下一層的軟件比在上一層的軟件通用性更強。
• 一個層次可以視為同等通用檔次的一組系統。
• 一個分層的系統按照層次結構組織，每一層向它的上層提供服務，同時又是它下層的客戶。
• 在某些系統中，除了鄰接的層，一個內部層次對于其他外部層次是隱藏的，對體系結構的約束包括把系統的交互限制在鄰接層次之間。
• 交互只在相鄰的層間發生，并且，這些交互按照一定協議進行。
• 連接件可以用交互鍵的協議定義。
• 每一層是由不同的部件構成的實體集合。層內的部件可以交互。
• 相鄰層的部件可以直接從上向下調用，還可以設計統一的曾調用接口對層進行保護。

優點：

• 由于對層次的鄰接層進行限制，所以系統易于改進和拓展。
• 每一層的軟件都易于重用，并可為某一層次提供可互換的具體實現。
• 分層系統所支持的設計體現了不斷增加的抽象層次，這樣，一個復雜問題的求解被分解為一系列遞增的步驟。
• 標準化支持。
• 局部性依賴。
• 可替換性。

缺點：

• 如何界定層次間的劃分是一個較為復雜的問題。
• 更改行為的重疊。
• 降低效率。
• 不必要的工作。

5.6倉庫風格和黑板風格
倉庫風格的體系結構由兩個構件組成：一個中央數據結構，它表示當前狀態；一個獨立構件的集合，它對中央數據結構進行操作。
對于系統中數據和狀態的控制方法有兩種：一個傳統的方式是，由輸入事務進行選擇進行何種處理，并把執行結果作為當前狀態存儲到中央數據結構中，這時，倉庫是一個傳統的數據庫體系結構；另一種方法是，由中央數據結構的當前狀態決定進行何種處理。這時，倉庫是一個合辦體系結構，即黑板體系結合是倉庫體系結構的特殊化。

5.7模式—視圖—控制器風格——MVC模式

• MVC結構是為那些需要為同樣的數據提供多個視圖的應用程序而設計的，它很好地實現了技術層與表現層的分離。
• 作為一種開發模型，MVC通常用于分布式系統的設計和分析中，以及用于確定系統各部分間的組織關系。
• 對于界面可變性的需求，MVC把交互系統的組成分解為模型、視圖、控制器三種部件。
• 模型部件：是軟件所處理問題邏輯在獨立與外在顯示內容和形式情況下的內在抽象，封裝了問題的核心技術數據、邏輯和功能的計算關系，它獨立于具體的界面表達和I/O操作。
• 視圖部件：把表示模型數據及邏輯關系和狀態的信息吉他頂形式展示給用戶，它從模型獲得顯示信息，對于相同的信息可以有多個不同的顯示形式或視圖。
• 控制部件：用于處理用戶和軟件的交互操作，其職責是控制所提供模型中任何變化的傳播，確保用戶界面和莫相間的對應關系。通常，一個視圖具有一個控制器。
• 模型類：包含了應用問題的核心數據、邏輯關系和計算功能。它封裝了解決應用問題所需的數據，提供了問題處理的操作過程。
• 視圖類：通過顯示信息的形式把信息傳達給用戶，不同試圖通過不同的顯示來表達數據和狀態信息。
• 控制類：通過實踐處理過程對輸入事件進行處理，并為每個事件提供操作服務，把事件轉換成對模型或相關使徒的激發操作。

MVC的實現：

• 分析應用問題，對系統進行分離
• 設計和實現每個視圖
• 設計和實現每個控制器
• 使用和安裝、卸載控制器

5.8解釋器風格
解釋器風格通常用于建立一種虛擬機以彌合程序的語義與作為計算引擎的硬件的間隙。又有解釋器時間上建立了一個軟件虛擬出來的機器，所以這種風格又常常被稱為虛擬機風格。
程序設計語言的編譯器；基于規則的系統，；腳本語言。
由一個執行引擎+三個存儲器，一共四個構件組成：

• 正在被解釋的程序
• 執行引擎
• 被解釋的程序的當前狀態
• 執行引擎的當前狀態

優點：

• 有助于應用程序的可移植性與程序設計語言的跨平臺能力。
• 可以對為實現的硬件進行仿真。

缺點：
額外的間接層次帶來的系統性能的下降。

5.9C2風格
C2體系結構風格可以概括為通過連接件綁定在一起的、按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：

• 該系統的構建與連接件都有一個頂部和一個底部。
• 構件的頂部應連接到某連接件的底部，構件的底部應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的。
• 一個連接件可以和任意數目的其他構件和連接件連接。
• 當兩個連接件進行直接連時，必須由其中一個的底部到另一個的頂部。
• C2風格是最常用的一種軟件體系結構風格。

C2風格具有如下特點：

• 系統中的構建可以實現應用需求，并能將任意復雜度的功能封裝在一起。

• 所有構件之間的通信時通過以連接件為終結的異步信息交互機制來實現的。

• 構件相互獨立，構件之間依賴性較少。

5.10 C/S風格

• C/S體系結構有3各主要組成部分： 數據庫服務器、客戶應用程序和網絡。

服務器負責有效的管理系統的資源，其任務集中于以下幾個方面：

• 數據庫安全性的要求
• 數據庫訪問并發行的控制
• 數據庫前端的客戶應用程序的全局數據完整性規則
• 數據庫的備份與恢復

客戶端應用程序的主要任務：

• 提供用戶與數據庫交互的界面
• 向數據庫服務器提交用戶請求并接受來自數據服務器的信息
• 利用客戶端應用程序對存在與客戶端的數據執行應用邏輯要求
• 網絡通信軟件主要作用是完成數據庫服務器和客戶端應用程序之間的數據傳輸。

優點：

• 系統的客戶端應用程序和服務器構件分別運行在不同的計算機上，系統中的每臺服務器都可以是合格構件的要求，這對于硬件與軟件的變化顯示出極大的適應性和靈活性，而且易于對系統進行擴充和縮小。
• 在C/S體系結構中，系統中的功能充分分離，客戶端應用程序的開發集中于數據的現實和分析，兒數據服務器的開發則集中于數據的管理，不必在每個新的應用程序中都對DBMS進行編碼。
• C/S體系結構具有強大的數據操作和事務處理能力，模型思想簡單，易于人們理解和接受。

缺點：

• 開發成本高
• 客戶端程序設計復雜
• 信息內容和形式單一
• 用戶界面風格不一，使用復雜，不利于推廣使用。
• 軟件移植困難
• 軟件維護和升級困難
• 新技術不能輕易應用

5.11 三層C/S結構風格
表示層：

• 表示層是應用的用戶接口部分，它擔負著應用與用戶之間的對話功能，用于檢查用戶從鍵盤等輸入的數據，顯示應用輸出的數據。
• 再變更用戶界面時，只需改寫顯示控制和數據檢查程序，而不影響其他兩層。
• 檢查的內容也僅限于數據得形式和取值范圍，不包括業務本身的處理邏輯。

功能層：

• 功能層相當于應用的本體，用于將具體的業務處理邏輯編入程序。
• 表示層和功能層之間的數據交互要盡可能簡潔。
• 在功能層中包含確認用戶對應用與數據庫存取權限的功能以及記錄系統處理日志的功能。

數據層：

• 數據層就是數據庫管理系統，負責管理對數據庫的讀寫操作。
• 數據庫管理系統必須能迅速執行大量數據的更新和檢索。
• 中間件：一個用API定義的軟件層，是具有強大通信能力與良好可擴展性的分布式軟件 管理框架。
• 功能：在客戶機和服務器或者服務器和服務器之間傳送數據，實現客戶集群和服務器群之間的通信。
• 工作流程：在客戶機中的某個應用程序選喲駐留網絡上某個服務器的數據或服務時，搜 索此程序的C/S應用程序需要訪問中間件系統，該系統將查找數據源或服務，并在 發送應用程序請求后重新響應，將其傳送回應用程序。

三層C/S結構的優點：

• 允許合理的劃分三層結構的功能，使之在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統與軟件的可維護性和可拓展性。
• 允許更靈活有效的選用相應的平臺與硬件系統，使之在處理負荷能力上和處理特征上分別適應于結構清晰的三層，而且這些平臺與各個組成部分可以具有良好的可升級性和開放性。
• 應用的各層可以并行開發，各層也可以選擇各自最適合的開發語言，使之能并行的而且高效率的進行開發，達到較高的性價比，對每一層的處理邏輯的開發和維護也會更容易一些。
• 允許充分利用功能層有效的隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑客工具去非法的訪問數據層，這就為嚴格的安全管理奠定了堅實的基礎，整個系統的管理層次也更加合理和可控。

5.12B/S風格
B/S軟件體系結構是隨著Internet技術的興起，對C/S結構改進后得到的一種結構。
在B/S體系結構下，用戶界面完全通過WWW瀏覽器實現，部分事務邏輯在前端實現，但主要是無邏輯在服務器端實現。
他利用瀏覽器技術，結合瀏覽器的多種腳本語言并通過瀏覽器就實現了原本需要復雜的專業軟件才能實現的強大功能，是一種全新的軟件體系結構。

• 優點：
  簡化了客戶端，無需像C/S模式那樣在不同的客戶機安裝不同的客戶端應用程序，而只需安裝通用的瀏覽器軟件，就可以享受到無限豐富的永遠在不斷變化和發展中的信息服務。

特別適用于網上信息的發布。
通過Internet技術統一訪問不同種類的數據庫，提供了異種機器、異種網絡、異種應用服務之間的統一服務 的最現實開發基礎。

5.13C/S與B/S混合結構風格

• 優點： 外部用戶不直接訪問數據庫，從而能保證企業數據庫的相對安全， 企業內部的交互性較強，數據查詢和修改的的響應速度較快。
• 缺點： 企業外部用戶修改和維護數據時的速度較慢，較繁瑣，數據的動態交互性不強。

5.14 正交軟件體系結構的概念

• 正交軟件結構由組織層和線索的構件構成。
• 層是由一組具有相同抽象級別的構件構成的。
• 線索是子系統的特例，它由完成不同層次功能的構件構成（通過相互調用來關聯），每一條線索完成整個系統中相對獨立的一部分功能。
• 每一條線索的實現與其他線索的實現無關或關聯很少，在同一層中的構件之間是不存在相互調用的。

正交軟件體系結構的主要特征：

• 正交軟件體系結構有完成不同功能的n（n>1）個線索（子系統）組成。
• 系統具有m（m>1）個不同抽象級的層。
• 線索之間是相互獨立的。（正交的）
• 系統有一個公共驅動層（一般為最高層），和公共數據結構（一般為最底層）。

正交軟件體系結構的優點：

• 結構清晰，易于理解
• 易修改，可維護性強
• 可維護性強，重用粒度大

5.15 異構結構風格
使用異構結構的原因：

• 從最根本上來說，不同的結構由不同的處理能力的強項和弱點，一個系統的體系結構應該根據實際需要進行選擇，已解決實際問題。
• 軟語軟件包、框架、通信以及其他一些體系結構上的問題，目前存在多種標準。
• 實際工作中，總會遇到一些遺留下來的代碼，它們仍有效用，但是卻與信系統有某種程度上的不協調。
• 即使在某一單位中，規定了共享共同的軟件包或相互關系的一些標準，仍會存在解釋或表示習慣上的不同，在UNIX中就可以發現這類問題：即使規定用單一的標準（ASCII）來保證過濾器之間的通信，但不同人對關于在ASCII流中信息如何表示的不同假設，不同的過濾器之間仍可能不協調。

異構體系結構實例——“內外有別”模型
優點：

• 外部用戶不直接訪問數據庫服務器，能保證企業數據庫的相對安全。
• 企業內部用戶的交互性較強，數據查詢和修改的速度較快。

缺點：

• 企業外部用戶修改和維護數據時的速度較慢，較繁瑣，數據的動態交互性不強。

異構體系結構實例——“查改有別”模型
缺點：

• 外部用戶能夠直接通過Internet連接到數據庫服務器，企業數據容易暴露給外部用戶，給數據安全造成一定威脅。

總結

以上是生活随笔為你收集整理的软件体系结构1~5章知识点整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。