軟件體系結構知識點總結（更新中）
軟件體系結構
公式
? 體系架構=組件+連接件+約束
? SoftwareArchitecture=Components+Connectors+Constrains
風格決定因素
? 組件類型（例如：數據容器，過程，對象）
? 連接件類型/交互機制（例如：過程調用，事件，管道）
? 組件的拓撲分布
? 拓撲和行為的約束（例如：數據容器不能自己改變數據，管道不能是循環的）
? 風格的代價和益處（優缺點）
? 異質的風格 Heterogeneous style）： 一個系統是由不止一種風格構建的
幾種軟件體系結構風格
數據流 Data Flow:
實例：流水改卷
? 兩種方法：
? 方式1：一位老師改完1分卷子，就傳給下一位老師
? 方式2：一位老師改完整班卷子，再傳給下一位老師
特點
? 由數據控制計算
? 系統結構由數據在處理之間的有序移動決定
? 數據流系統的結構是比較明顯的
? 在純數據流系統中，處理之間除了數據交換，沒有任何其他的交互
風格
? 組件：
? 組件的接口是輸入端口還是輸出端口
? 計算模型：從輸入中讀取數據，計算，然後寫到出口
? 連接件：單向，通常是異步有緩沖的
? 系統：
? 任意的拓撲結構
? 不同組件完成不同的功能
模式：
? 我們主要研究近似線性數據流或者是在限度內的循環數據流
? 如果一個軟件系統的數據流的流向無序很可能說明該系統不應采用數據流的體系結構
?
例子：
批處理
- 每個處理步驟是一個獨立的程序
- 每一步必須在前一步結束後才能開始（有次序）
- 數據必須是完整的，以整體的方式傳遞
管道過濾器
特性：
每個組件 都有一組輸入和輸出，組件讀取輸入的數據流，經過內部處理，產生輸出數據流。
這個過程通常通過對輸入流的變換及增量計算來完成。
這裏的組件成為過濾器，連接件像是對輸入流傳輸的管道，將一個過濾器的輸出傳到另一個過濾器的輸入。
管道過濾器的通用結構：
- 管道：限制了系統的拓撲結構，只能是過濾器的線性序列
- 有界管道：限制了在管道中能夠容納的數據量
- 類型定義管道：要求定義在兩個過濾器間傳出的數據類型
過濾器的角色：
- 讀取數據流，把處理後的數據流作為輸出
執行流式的轉換
- 遞增地轉換數據，數據邊到來邊處理，不是先收集好，再處理
- 不同過濾器之間是獨立的
管道的角色
- 移動數據，從一個過濾器的輸出到另一個過濾器的輸入
全部的操作
- 數據傳送引起系統動作
- 當沒有數據可用，沒有更多的計算的時候，管道過濾器系統停止工作
讀取與處理數據流的方式
- 遞增地讀取和消費數據流
- 在輸入被完全處理之前，輸出便產生了
優點
使軟件具有良好的隱蔽性和高內聚，低耦合的特點（過濾器可以看做是黑盒）
可將整個系統的I/O特性，理解為各個過濾器功能的簡單合成。（多個地級過濾器可以合並成一個高級過濾器）
支持功能模塊的重用（任意兩個過濾器只要在相互所傳輸的數據格式上達成一致，就可以連接在一起）
系統易於維護和擴展（新的過濾器容易加入到系統中，舊的過濾器也可以被改進的過濾器替換）
支持某些特性屬性的分析（入吞吐量和死鎖檢測）
支持多個過濾器的並發執行（適合多核/多線程環境）
理想情況下是組件之間只有數據依賴
缺點
- 不適合在交互性很強的應用
- 在數據傳輸上沒有通用的標準，每個過濾器都增加了解析數據的工作
- 處理兩個獨立但相關的數據流可能會遇到困哪
- 某些過濾器可能需要大尺寸的cache
批處理和管道過濾器這兩種數據流風格，無法從拓撲結構上進行區分
比較：
相同點：
- 都是把任務分解為一系列固定順序的計算單元（組件）
不同點：
批處理 管道過濾器 全部 增量 高延遲 立即有結果 輸入隨機訪問 輸入的處理是局部的 沒有並發性 可能有反饋回路 沒有交互性 有交互性
怎麽選擇：
- 任務是數據主導
- 事先知道數據的確切流向
考法：
- 選擇這個結構為什麽可以滿足需求，為什麽這個結構的缺點是可容忍的
控制
開環控制
- 系統無反饋
- 由人進行反饋
閉環控制
系統有反饋，不需要人進行反饋
兩種形式：
- 反饋控制：根據受控變量的測量值來調整過程
- 前饋控制：通過測量其他過程變量，來預計輸入變量對被控變量將產生的影響。前饋控制這些變量來調整過程
當軟件系統的運行受到外部幹擾（軟件不可見或不可控的力量或事件）的影響時，需要為軟件體系結構考慮的一種過程控制方式。
和許多線性的數據流體系結構不同，控制環路體系結構需要有循環的拓撲結構
在什麽情況下選擇控制這種風格：
- 任務包含連續的動作、行為、狀態的改變
- 不適合人參與的情況
- 一般是軟硬件結合的系統
call/return 調用/返回 體系結構風格：
特點
- 每層為上一層提供服務，使用下一層的服務，只能見到與自己鄰接的層
- 大的問題分解為若幹漸進的小問題，逐步解決，隱藏了很多復雜度
- 修改一層，最多影響兩層，通常只會影響上層。若層之間接口穩固，則不會造成其他影響
- 上層必須知道下層的身份，不能調整層次之間的順序
- 層層相調，影響性能。
Client/Server Style:
兩層C/S
缺點：
- 對客戶端軟硬件配置要求較高
- 客戶端程序設計復雜
- 數據安全性不好，客戶端程序可以直接訪問數據庫服務器
- 信息內容和形式單一
- 用戶界面風格不一，使用繁雜，不利於推廣使用
- 軟件維護與升級困難，每個客戶機上的軟件都需要維護
三層C/S
B/S(瀏覽器/服務器)
Data Centered/Shared Data:
repository
這種風格描繪很多系統
共同特點是共享數據
典型的例子：數據庫、剪貼板、註冊表
優點：
很容易增加數據的生產者和消費者
種類：
- 設計者預先定義好 編譯器
- 輸入流的信息類型決定 數據庫事物系統
- 系統其他部分的新信息決定 Scratchboard（刮板）
- 機會主義：計算的狀態決定 Blackboard
blackboard
什麽是黑板？
黑板的作用相當於“共享內存”，如同多位不同專長的專家在同一黑板上交流思想，每個專家都可以獲得別的專家卸載黑板上的信息，同時也可以用自己的分析去更新黑板上的信息，從而影響其他專家。
解決無確定性求解策略問題
組成
知識源（專家）
包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，他們之間的交互只通過黑板來完成，一個知識源只能解決問題的一部分
- 提供解決問題的知識
- 變現為過程、規則、邏輯斷言
- 僅能修改黑板，無法與其他知識源交互
- 知道何時能發揮作用
- 低耦合的子任務，或者有特別的能力
黑板數據結構
按照與應用程序相關的層次結構來組織的解決問題的數據，知識源利用黑板的借口對黑板進行讀寫，通過不斷地改變黑板數據來解決問題
保存知識源要使用的數據
保存來自解空間的數據
分層；同層或者不同層的對象的之間的關聯
與倉庫的區別：
- 黑板：黑板的狀態觸發進一步的操作
- 倉庫：操作的執行次序是預先確定的
控制（仲裁者）
控制完全由黑板的狀態驅動，監控黑板的變化，決定下一步選哪個知識源進行工作
- 讓知識源相應偶然事件
- 連接各個知識源的能力，決策解決問題的步驟
- 控制機制是與時俱進、隨機應變的
黑板模型：
Knowledge Sources
- 把問題分成幾個部分，每個部分獨立計算
- 對黑板的變化做出反應
Blackboard Data Structure
- 全局數據庫包含解決方案的全部狀態
- 知識源互相關聯的唯一媒介
Control
- 完全由黑板的狀態驅動，黑板的狀態的改變決定使用的特定知識
- Knowledge sources respond "opportunistically"，讓知識源響應偶然事件
Blackboard Problem Characteristics
沒有直接的算法可解
- 多種方法都可能解決問題
- 需要多個領域的專門知識協作解決
不確定性 uncertainty
- 數據和解決方法可能錯誤或變化
- 數據中信噪比的變化
- 算法借口的變化
問題沒有唯一個解答，或者“正確”答案會變化
Virtual Machine
什麽是虛擬機
一種軟件
創建了虛擬的環境
屏蔽了底層平臺
分類：
- 系統級（硬件虛擬機）：將一臺電腦虛擬為運行不同os的電腦
- 進程級（應用程序虛擬機）：JVM
- 機器耦合：雲計算
分類
解釋器（Interpreters）
組件：一個狀態機（解釋引擎）、三個存儲區
連接件：過程調用/對存儲區的數據訪問
優點：
功能性 Functionality
- 可以仿真非本地的功能
測試性 Testing
- 能夠仿真災難的模式
靈活性 Flexibility
- 多用途的工具
缺點：
效率 Efficiency
- 比硬件效率慢的多
- 比編譯系統慢
測試性 Testing
- 增加了軟件要去驗證的層數
解釋器和編譯器的區別：
- 解釋器的執行速度慢於編譯器產生的目標代碼的執行速度，但低於“編譯+鏈接+執行”的總時間
- 每次解釋執行時，都需要分析程序結構，而編譯器只需要一次性編譯代碼
規則系統 Rule-based system
結構：
解決的問題：
- 業務規則很復雜時，不宜用if-else結構
- 按照OCP（開放/封閉原則），應把可變部分與不變部分進行分離，在前者變化時不影響後者
基於規則的系統：一種特殊的虛擬機，使用模式匹配搜索來尋找規則，並在正確時機應用正確的規則
特點：
1引擎
- rule interoreter
3存儲區
- knowledge base
- rule/data selection
- working memory
優點：
- 降低修改業務邏輯的成本與風險
- 縮短開發時間
- 規則可在多個應用中共享
與解釋器風格的不同：
- 解釋器：在高級程序語言與OS/硬件平臺間建立虛擬機
- 基於規則的系統：在自然語言/XML規則和高級程序語言建立虛擬機
常見的規則：
- 用戶界面輸入的合法性檢查
- 安全規則/權限控制規則
- 業務策略（如VIP折扣策略等）
獨立構件（Independent Component）
分類：
Communicating Processes
結構：
完成任務需要多個proc協同，proc間的協同通過msg完成，msg是顯性的，即需要指明源和目的地。
組件間相對獨立，依靠發消息通信。
模型：
解決方案
- 系統模型：獨立的通信的(communicating)進程
- 組件：收發消息的過程
- 連接件：消息
- 控制結構：每一個進程有自己的控制線程
重要的變量
- 通信網絡的拓撲結構
- 每條消息接收者的數量
Event Systems
組件對事件進行訂閱，並在事件被觸發時得到通知。而事件並不知道都有誰訂閱了自己。
隱式調用：
解決方案：
- 系統模型： 獨立的反應過程
- 組件：一個進程，不知道接收者信號的重要的事件
- 連接件：自動地調用
- 控制結構：分散的；沒有意識到接受者信息的獨立的構件
基於事件的隱式調用風格的思想：
構件不直接調用一個過程，而是觸發一個或者多個時間
其他構件中的過程註冊一個或多個事件，當一個事件被觸發，系統自動調用在這個事件中註冊的所有過程
構件是一些模塊（過程，或者事件的集合）
主要特點是：事件的觸發者並不知道哪些構件會被這些事件影響
- 不能假定構件的處理順序，甚至不知道哪些過程會被調用
- 許多隱式調用的系統也包含顯示調用作為構建交互的補充形式
優點：
問題分解：
- 為軟件重用提供了強大的支持。當需要將一個構建加入現存系統中時，只需將它註冊到系統的事件中。新的關註者不對現有的關註者構成任何影響
系統維護和重用
- 為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其他構件的接口。
性能
- 調用可以是並行的
魯棒性
- 一個構件的故障不會影響其它構件
核心思想：系統分解為多個低耦合的模塊
缺點：
- 構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件註冊了哪些構件的構成，它也不能保證這些過程被調用的順序。
- 數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基於事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
- 既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。
Other Familiar Styles
C2 Architecture Style
通過連接件綁定在一起的按照一組規則運行的並行構件網絡。
系統組織規則：
- 系統中的構件和連接件都有一個頂部和一個底部
- 構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的
- 一個連接件可以和任意數目的其他構件和連接件連接
- 當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
特點：
- 系統中的構件可實現應用需求，並能將任意復雜度的功能封裝在一起
- 所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的
- 構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
異質的體系結構
（Heterogeneous Architectures）
組合方式
聚合方式
- 組件的體系結構。例如：編譯器中的文法分析組件
聯合放肆
- 某一個組件或連接件成為兩種以上體系機構聯系的紐帶
- 可能是聚合方式的展開
- 例如：視頻點播系統
混合方式
- 把多種體系結構的優點，混合使用。主要體現在連接件的混合使用。
- 例如：事件驅動的CASE系統。
B/S與C/S混合軟件體系結構
- 內外有別模型
- 查改有別模型
對等網（P2P）
特點：
整體穩定，不會因為一點的錯誤影響全局
資源共享，任務分攤
- 我為人人，人人為我
- 每點還要承擔一定量的中轉負荷
對網絡帶寬占用極大
內容很難有效控制
?
軟件體系結構知識點總結（更新中）