案例一：聖·瑪麗亞大教堂
案例二：瑞典瓦薩戰艦
由建築體系架構——>軟體體系結構。
總體的系統結構設計比計算演算法和數據結構更爲重要。
1.軟體體系結構發展史
高階語言 程序導向開發 物件導向開發 面向服務開發 雲和移動服務開發 智慧化軟件開發。
無體系結構——>概念和理論體系形成——>理論完善且普及應用
體系結構出現：1968年北大西洋公約組織（NATO）會議上第一次出現詞語「Software Architecture」（軟體體系結構/軟體架構）。
概念體系和理論體系形成：軟體體系結構定義逐漸明確，相關書籍出版。
理論完善與普及應用：1999年，1st IFIP軟體架構會議召開；Markup架構描述語言提出，支援廣泛的模型架構共用；軟體產品線被提出，引起了大量大型企業的關注；IEEE 1471—2000發佈，爲軟體架構普及定製標準化規範。
2.軟體體系結構定義
軟體體系結構=元件+連線件+約束
元件：具有某種功能的可重用的軟體模組單元，表示了系統中重要的計算單元和數據儲存。
連線件：表示元件之間的互動。簡單連線件有：管道，過程呼叫，事件廣播等；複雜連線件有：客戶—伺服器通訊協定，數據庫和應用之間SQL連線。
約束：表示元件和連線件的拓撲邏輯和約束。
3.軟體體系結構的研究活動
軟體體系結構要解決的問題，軟體體系結構研究的內容，自適應軟體體系結構。
4.軟體體系結構的作用
軟體生命週期中的作用
1.1軟體的本質
軟體是一系列按照特定順序組織的計算機數據和指令的集合。
軟體不是有形的物理產品，而是人類思維的產物。
軟體不是被製造出來的 ，而是思考出來的。
軟體的限制—>軟體的複雜性
軟體特質和分類：
軟體分類：
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（一種通用的視覺化建模語言）
非形式化描述的缺陷：
不適於描述體系結構行爲
２.４.３軟體體系結構的描述—形式化描述
用於軟體和硬體系統的說明、開發和驗證的數學化方法。
理論基礎是數學化理論。
形式化的特點：
２.４.４軟體體系結構的描述—典型的形式化描述
形式化描述存在的問題：
２.４.５軟體體系結構的設計
２.５ADL簡介
體系結構描述語言：一種用於描述體系與體系結構的計算機語言，它可以在指定的抽象 層次上描述軟體體系結構。
ADL關注抽象層次上的整體結構而不是任意程式碼模組的實現細節，作爲一種經典理論， Shaw和Garland定義了ADL的元素：
3.1軟體體系結構建模概述
體系結構模型分爲以下五類：
結構模型
框架模型
動態模型
過程模型
功能模型
3.2基於軟體體系結構的開發
體系結構的軟件開發過包括以下主要活動：
1.通過對特定領域應用軟體進行分析，提煉其中的穩定需求和易變需求，建立可 複用的領域模型。
2.在領域模型的基礎上提煉特定領域的軟體體系結構。
3.低層設計主要解決具體構件和連線件的設計問題，通過複用設計件庫中存放的 設計模式、物件和其他型別的可複用設計件，或根據情況設計情的構件，並提煉入 庫。低層設計的結果可以直接程式設計實現。
體系結構——>宏觀上描述系統的總體構件——>高層設計
設計模式和物件——>從微觀上解決設計的問題——>低層設計
3.3UML概述
3.3.1UML的特點和用途
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.活動圖
4.1軟體設計基礎
軟體設計主要針對需求分析過程得到的軟體需求規格說明，綜合考慮各種制約因素，探 求切實可行的軟體解決方案並最終給出方案的邏輯表示，包括文件、模型等。
軟體設計的主要活動：
（1）軟體設計計劃
明確設計過程的輸入製品並使其處於就緒狀態
定義設計過程的目標、輸出製品及驗收準則
確定覆蓋設計過程中各個階段的全域性性設計策略
分配設計過程中相關人員的職責
針對設計過程中的活動指定設工作計劃
（2）體系結構設計
目標是建立軟件系統的體系結構，有時也稱「頂層設計」。
在軟體體系結構設計過程中，需要注意以下規則：
（3）介面設計
良好的用戶介面一般都符合下列用戶介面規範：
（4）模組/子系統設計
設計目標：
（5）過程/演算法設計
主要任務是對模組內部工作和執行過程進行描述，給出有關處理的精確說明。
（6）數據模型設計
4.2軟體體系結構設計
軟體設計一般首先設計軟體體系結構設計，然後再逐步精化進行更詳細的設計，知道設計可以被實現的程度。
軟體體系結構的設計方法是指通過一系列的設計活動，獲得滿足系統能性需求，並且符合一定非功能性需求約束的軟體體系結構模型。
（1）多重檢視建模（包含邏輯、開發、物理、過程檢視）
（2）基於評估與轉換的設計方法
對體系結構進行轉換可以通過下述三種方式實現：
（3）模式驅動的設計方法
常用的軟體體系結構風格如下：
（4）領域特定的軟體體系結構設計方法
領域特定的軟體體系結構是領域工程的核心部分，領域工程分析應用領域的共同特徵和可變特徵，對刻畫這些特徵的物件和操作進行選擇和抽象，形成領域模型，並進一步生成DSSA。
DSSA與體系結構風格的區別：
（5）軟體產品線
指一組可管理的，具有公共特性的軟體應用系統的集合。
軟體產品線的主要組成部分：核心資源和軟體產品集合。
軟體產品的基本活動包括核心資源開發，利用核心資源的產品開發以及在這兩部風 中所需要的技術協調和組織管理。
在一個軟體產品線中，新產品形成的步驟如下：
（6）其他軟體體系結構設計方法
（1）基於目標圖推理的體系結構設計方法：該方法的目標是使模式背後的推理顯 示化，並且服從於系統的分析；該方法使用目標圖，表達模式在各種需求上的應用 效果。
（2）基於屬性的體系結構設計方法：是對通常體系結構風格描述的一種擴充，用 於獲取結構化分析SA層次上的結構和分析技巧，顯式地把推理框架（定性或定量） 與體系結構風格關聯起來。
4.3高可信軟體設計
（1）可信軟體的特點：
（2）軟體可信性質分爲以下幾種：
（3）容錯設計
恢復塊
軟體容錯設計方法
N—板塊程式設計
設計多樣性可以通過以下幾種方式達到：
（4）軟體失效模式和影響分析
軟體失效模式和影響分析主要是在軟件開發階段的早期，通過識別軟體失效模式，研究分析各種失效模式產生的原因及其造成的後果，尋找消除和減少有害 後果的方法，以儘早發現潛在問題，並採取相應措施，從而提高軟體的可靠性 和安全性。
（5）軟體故障樹分析
軟體故障樹是在軟件系統設計過程中，通過對可能造成系統故障的因素（包括硬體、軟體、環境、人爲等因素）進行分析，畫出邏輯框圖（即故障樹），從而確定系統故障原因的各種可能組合，採取相應的糾正措施，提高系統可靠性的一種設計分析方法。
（6）形式化方法
形式化方法是在計算系統的開發中進行嚴格推理的理論、技術和工具，主要包括形式規約技術和形式驗證技術。
形式規約技術：使用具有嚴格數學定義語法和語意的語言刻畫軟件系統及其性質，可以儘早發現需求和設計中的錯誤、歧義、不一致和不完全。、
形式驗證技術：是在行使規約的基礎上建立軟件系統及其性質的關係，即分析系統是否具有所期望性質的過程，主要分爲模型檢驗和定理證明。
4.4軟體設計規格說明
4.5軟體設計評審
軟體設計評審的目標是確保軟體設計規格說明書能夠實現所有的軟體需求，及早發現設計中的缺陷和錯誤，並確保設計模型已經精化到合格的軟體實現工程師能夠構造出符合軟體設計者期望的目標軟件系統。
設計評審中需要重點關注的內容包括：
爲了使設計評審達到預期效果，下面 下麪給出設計評審的一些建議性原則：
5.1軟體體系結構風格概述
軟體體系結構設計的一個核心問題是能否使用重複的體系結構模式，即能否達到體系結構級的軟體重用。
能否在不同的軟件系統中使用同一種體系結構。
軟體體系結構風格是描述某一特定應用領域系統組織方式的慣用模式。體系結構風格定義一個系統家族，即一個體繫結構定義一個詞彙表和一種約束。
體系結構風格反映了領域中衆多系統所共有的結構和語意特徵，並指導如何講各個模組和子系統有效地組織成一個完整的系統。
按照這種方式理解，軟體體系結構風格定義了描述系統的術語表和知道構建系統的規則。
5.2管道—過濾器
在管道—過濾器模式下，功能模組成爲過濾器；功能模組間的連線看作是輸入、輸出數據流的通道，所以稱爲管道。
（1）適應的設計問題
如果要建立一個必須處理或轉化輸入數據流的系統，用單個元件實現會顯得臃腫，需求不容易變動，所有可能要通過替換或重新排列處理步驟爲靈活性做規劃。處理步驟的內部鏈接必須考慮一下步驟：
（2）解決方案
每種風格具有以下特徵：
採用管道—過濾器模式建立的系統具有如下優點：
管道—過濾器的不足：
5.3數據抽象和麪向物件風格
優點：
缺點：
5.4基於事件的隱式呼叫風格
主要特點：事件的觸發者並不知道哪些構件會被這些事件影響。
優點：
缺點：
5.5分層系統風格
優點：
缺點：
5.6倉庫風格和黑板風格
倉庫風格的體系結構由兩個構件組成：一箇中央數據結構，它表示當前狀態；一個獨立構件的集合，它對中央數據結構進行操作。
對於系統中數據和狀態的控制方法有兩種：一個傳統的方式是，由輸入事務進行選擇進行何種處理，並把執行結果作爲當前狀態儲存到中央數據結構中，這時，倉庫是一個傳統的數據庫體系結構；另一種方法是，由中央數據結構的當前狀態決定進行何種處理。這時，倉庫是一個合辦體系結構，即黑板體系結合是倉庫體系結構的特殊化。
5.7模式—檢視—控制器風格——MVC模式
MVC的實現：
5.8直譯器風格
直譯器風格通常用於建立一種虛擬機器以彌合程式的語意與作爲計算引擎的硬體的間隙。又有直譯器時間上建立了一個軟體虛擬出來的機器，所以這種風格又常常被稱爲虛擬機器風格。
程式設計語言的編譯器；基於規則的系統，；指令碼語言。
由一個執行引擎+三個記憶體，一共四個構件組成：
優點：
缺點：
額外的間接層次帶來的系統效能的下降。
5.9C2風格
C2體系結構風格可以概括爲通過連線件系結在一起的、按照一組規則運作的並行構件網路。C2風格中的系統組織規則如下：
C2風格具有如下特點：
系統中的構建可以實現應用需求，並能將任意複雜度的功能封裝在一起。
所有構件之間的通訊時通過以連線件爲終結的非同步資訊互動機制 機製來實現的。
構件相互獨立，構件之間依賴性較少。
5.10 C/S風格
伺服器負責有效的管理系統的資源，其任務集中於以下幾個方面：
用戶端應用程式的主要任務：
優點：
缺點：
5.11 三層C/S結構風格
表示層：
功能層：
數據層：
三層C/S結構的優點：
5.12B/S風格
B/S軟體體系結構是隨着Internet技術的興起，對C/S結構改進後得到的一種結構。
在B/S體系結構下，用戶介面完全通過WWW瀏覽器實現，部分事務邏輯在前端實現，但主要是無邏輯在伺服器端實現。
他利用瀏覽器技術，結合瀏覽器的多種指令碼語言並通過瀏覽器就實現了原本需要複雜的專業軟體才能 纔能實現的強大功能，是一種全新的軟體體系結構。
特別適用於網上資訊的發佈。
通過Internet技術統一存取不同種類的數據庫，提供了異種機器、異種網路、異種應用服務之間的統一服務 的最現實開發基礎。
5.13C/S與B/S混合結構風格
5.14 正交軟體體系結構的概念
正交軟體體系結構的主要特徵：
正交軟體體系結構的優點：
5.15 異構結構風格
使用異構結構的原因：
異構體系結構範例——「內外有別」模型
優點：
缺點：
異構體系結構範例——「查改有別」模型
缺點：