第6章 軟件體系結構建模

1、5.1 “4+1” 視圖模型5.2 軟件體系結構的核心模型5.3 軟件體系結構的生命周期模型研究軟件體系結構的首要問題是：如何表示軟件體系結構，即如何對軟件體系結構 建模 結構模型：以構件、連接件等概念刻畫軟件結構 框架模型：更側重描述整體結構 動態(tài)模型：描述系統(tǒng)的重新配置或演化過程 過程模型：描述構造軟件的步驟和過程 功能模型：描述功能構件的層次組成關系23最終用戶：功能需求最終用戶：功能需求編程人員：軟件管理編程人員：軟件管理系統(tǒng)集成人員：性能系統(tǒng)集成人員：性能可擴充性、吞吐量等可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等拓撲、安裝、通信等每個視圖只關注軟件系統(tǒng)

2、的一個側面五個視圖結合起來才能反映系統(tǒng)軟件體系結構的全部內容4軟件體系架構設計應“將系統(tǒng)劃分成不同模塊”但一旦開始深入實踐，就會產(chǎn)生不少疑問： 從用戶角度而言，組成系統(tǒng)的是各種功能的模塊，這屬于架構設計的范圍嗎？ 對開發(fā)人員來說，他們認為系統(tǒng)是由不同的程序包組成的，架構設計師應不應該把這些都丟給程序員決定呢？ 此外，運行時軟件系統(tǒng)又是由進程、線程等組成的，這屬不屬于架構設計的范圍呢？5軟件體系架構設計應“規(guī)定系統(tǒng)各模塊之間如何交互”, 但一旦開始深入實踐，又困惑于： 在用戶看來，抽象的功能模塊之間可以相互（直接或間接）調用功能服務，只有這樣才能完成最終系統(tǒng)需要的業(yè)務功能，這是否屬于架構設計的決

3、策范圍呢？ 程序類組成程序包，程序包組成程序系統(tǒng)，這些程序代碼之間的調用等交互關系既有局部于包內的，也有跨包進行的，那么哪些屬于架構師應該考慮的呢？ 架構可以不關心進程或線程間的通訊和并發(fā)等問題嗎？6由于軟件體系結構概念是高度抽象的，所以在軟件體系結構概念與結構設計實踐之間，似乎存在某種“鴻溝”軟件結構視圖連接軟件體系結構的概念和實際的開發(fā)實踐需要軟件體系結構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設計軟件體系結構的每個視圖分別關注不同的方面，同時也為軟件體系結構的理解、交流和歸檔提供了方便78同一事物的不同視圖之間是有聯(lián)系的。對比上

4、面兩幅圖，除了南美洲之外基本都是降水量足的地方人口較密集9最終用戶：功能需求最終用戶：功能需求編程人員：軟件管理編程人員：軟件管理系統(tǒng)集成人員：性能系統(tǒng)集成人員：性能可擴充性、吞吐量等可擴充性、吞吐量等系統(tǒng)工程人員：系統(tǒng)系統(tǒng)工程人員：系統(tǒng)拓撲、安裝、通信等拓撲、安裝、通信等每個視圖只關注軟件系統(tǒng)的一個側面五個視圖結合起來才能反映系統(tǒng)軟件體系結構的全部內容10邏輯架構關注功能，不僅包括用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊、類等開發(fā)架構關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于

5、其上的系統(tǒng)軟件或中間件運行架構關注進程、線程、對象等運行時概念，以及相關的并發(fā)、同步、通信等問題。開發(fā)架構一般偏重程序包在編譯時期的靜態(tài)依賴關系，而運行架構比較關注的是這些運行時單元的交互問題物理架構關注“目標程序及其依賴的運行庫和系統(tǒng)軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠性、可伸縮性等要求1112面向對象：類圖等面向對象：類圖等層次結構框架：層次越低，通用性越強層次結構框架：層次越低，通用性越強基于層次的基于層次的C/SC/S結構及擴展結構及擴展系統(tǒng)工程人員：系統(tǒng)系統(tǒng)工程人員：系統(tǒng)場景可以看作是那些重要系統(tǒng)活動的抽象，它可以幫助設計者找到體系結構的構件

6、和它們之間的作用關系。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的顯示及用戶接口機械服務基本元素航空信息空中交通管理飛行管理外部接口網(wǎng)關仿真和培訓會話終端控制器轉換服務連接服務編號計劃13公用構件1低層服務支撐機制：通信、時間、儲存、資源管理等2航空類、空中交通管制類3空中交通管制功能區(qū)：飛行管理、雷達管理等4人機接口外部系統(tǒng)5離線工具測試工具各種各樣的空中交通管制系統(tǒng)特定的空中交通管制系統(tǒng)構件空中交通管制系統(tǒng)框架分布式虛擬機基本元素硬件、操作系統(tǒng)、數(shù)據(jù)庫領域特定領域無關通用空中交通管制代碼客戶定制14控 制 器 進 程慢 周 期 控制 器 任 務快 周 期 控

7、制 器 任 務主 控 制器 任 務終 端 進 程15C主KKKKKKKKF備份F主F備份F主C備份16（1）摘機小王:控制器編號計劃小王:終端小王:會話（2）撥號音（3）號碼（4）號碼（5）打開會話17邏輯視圖和開發(fā)視圖描述系統(tǒng)的靜態(tài)結構運行視圖和部署視圖描述系統(tǒng)的動態(tài)結構場景視圖對于所有的情況均適用并不是所有的軟件架構都需要“41”視圖： 只有一個處理器，則可以省略部署視圖 如果僅有一個進程或程序，則可以省略運行視圖 對于小型系統(tǒng)，可能邏輯視圖與開發(fā)視圖非常相似，而不需要分開的描述181920設備調試員通過使用該系統(tǒng)，可以察看設備狀態(tài)，設備的狀態(tài)信息由專用的數(shù)據(jù)采集器實時采集、發(fā)送調試命令

8、約束性需求：企業(yè)級的商業(yè)考慮（如：項目預算有限）, 最終用戶級的實際情況（如：用戶的平均電腦操作水平偏低）, 具體技術的明確要求（如：能在Linux上運行）, 考慮開發(fā)團隊的真實狀況（如：開發(fā)人員分散在不同地點）運行期質量屬性：主要指軟件系統(tǒng)在運行期間表現(xiàn)出的質量水平，例如：軟件系統(tǒng)的易用性、性能、持續(xù)可用性、安全性等此類屬性非常關鍵，因為它們直接影響著客戶對軟件系統(tǒng)的滿意度，大多數(shù)客戶也不會接受運行期質量屬性拙劣的軟件系統(tǒng) 應用層負責設備狀態(tài)的顯示，并提供模擬控制臺供用戶發(fā)送調試命令 嵌入層負責對調試設備的具體控制，以及高頻度地從數(shù)據(jù)采集器讀取設備狀態(tài)數(shù)據(jù) 應用層通過通訊層與嵌入層交互，通訊

9、層負責在RS232協(xié)議之上實現(xiàn)一套專用的“應用協(xié)議“：當應用層發(fā)送來包含調試指令的協(xié)議包，由通訊層負責將之傳遞給嵌入層，當嵌入層發(fā)送來原始數(shù)據(jù)，由通訊層將之解釋成應用協(xié)議包發(fā)送給應用層考慮到“一部分開發(fā)人員沒有嵌入式開發(fā)經(jīng)驗”, 架構師有必要明確說明系統(tǒng)的目標程序是如何編譯而來的：(1) 應用層目標程序 pc-moduel.exe (2) 嵌入式模塊rom-module.hex多線程異步交互數(shù)據(jù)緩沖中斷應用層中的線程代表主程序的運行，它直接利用了MFC的主窗口線程。無論是用戶交互，還是串口的數(shù)據(jù)到達，均采取異步事件的方式處理，杜絕了任何忙等待無謂的耗時，也縮短了系統(tǒng)響應時間通訊層有獨立的線程控

10、制著上上下下的數(shù)據(jù)，并設置了數(shù)據(jù)緩沖區(qū)，使數(shù)據(jù)的接收和數(shù)據(jù)的處理相對獨立，從而數(shù)據(jù)接收不會因暫時的處理忙碌而停滯，增加了系統(tǒng)吞吐量嵌入層的設計中，分別通過時鐘中斷和RS232口中斷來激發(fā)相應的處理邏輯，達到輪詢和收發(fā)數(shù)據(jù)的目的 描述了設備調試系統(tǒng)軟件和硬件的映射關系: 嵌入部分駐留在調試機中（調試機是專用單板機），而PC機上是常見的桌面可執(zhí)行程序的形式 32構件：具有某種功能的可重用的軟件單元，可分為原子構件及復合構件連接件：構件之間的交互，如過程調用、協(xié)議、SQL鏈接配置：構件和連接件的拓撲邏輯和約束端口：構件和外部環(huán)境交互點角色：連接件接口由一組角色組成，每一個角色定義了該連接件表示的交互

11、的參與者軟件體系結構配置連接件構件端口角色1:N1:N1:N34在軟件開發(fā)引入了軟件體系結構之后，軟件應用系統(tǒng)的構造過程變?yōu)椋?問題定義 需求分析 軟件體系結構設計 軟件系統(tǒng)設計 軟件實現(xiàn) 軟件測試與維護在建立軟件體系結構時：設計師主要是從結構的角度對整個系統(tǒng)進行分析，選擇恰當?shù)臉嫾?，構件間的相互作用關系以及對它們的約束，最后形成一個系統(tǒng)框架以滿足用戶需求，為后續(xù)的軟件設計奠定基礎需求分析：獲取用戶需求，確定系統(tǒng)所要用到的構件。包括：明確軟件功能及滿足質量屬性的非功能需求；生成類圖并完善及分組；把類打包成構件；需求評審（構件是否合理）等階段建立體系結構：選擇合適的體系結構風格，將構件集成其中，

12、并細化構件間的交互關系設計、實現(xiàn)及測試：設計構件間的詳細接口；實現(xiàn)構件并組裝構件，完成整個軟件的合成；測試單個構件的功能，并測試組裝后整體軟件的功能及性能等體系結構的非形式化描述體系結構的形式化基礎（數(shù)學模型）體系結構的規(guī)范描述體系結構演化體系結構提供、評價和度量體系結構的終結體系結構實施體系結構求精的驗證體系結構求精體系結構的性質分析需要演化或擴展否否是需要求精否是否為什么需要多視圖模型4+1 視圖模型的內容軟件體系結構的核心模型軟件體系結構的生命周期模型381、閱讀英文文章： Architectural BlueprintsThe “4+1” View Model of Software Architecture - Kruchten