【正文】 軟 件 體 系 結 構 第一部分 天津大學計算機學院 饒國政 課 程 內 容 ◇ 軟件危機 ◇ 軟件體系結構概念 ◇ 軟件體系結構模式 ◇ 體系結構的設計模式 ◇ 基礎結構模式 ◇ 軟件體系結構的其它研究領域 第一章 軟件危機 ? 軟件 ? 軟件的發(fā)展階段 ? 軟件危機 ? 軟件生命周期 軟件 ? 軟件＝程序、數據和相關文檔的完整集合 ? 軟件的特點： – 軟件是一個邏輯實體，而非物理實體； – 軟件是人類抽象思維的產物； – 開發(fā)過程沒有明顯的制作過程； – 生產成本隨著軟件的復雜程度急劇增加（指數級）； – 容易復制、傳播； – 維護工作復雜。 軟件的發(fā)展階段 ? 三個發(fā)展階段 – 程序設計階段（ 50~60年代中期） – 程序系統階段（ 60中期 ~70年代中期） – 軟件工程階段（ 70年代中期以來） 軟件危機 ◇ 軟件危機的表現 ◎ 軟件成本估計不準確 ? 隨著軟件規(guī)模增長，軟件開發(fā)成本往往成指數級增長。 ◎ 開發(fā)進度難以控制 由于軟件是邏輯、智力產品，軟件的開發(fā)需建立龐大的邏輯體系，這是與其他產品的生產不一樣的。 在軟件開發(fā)過程中 ， 用戶需求變化等各種意想不到的情況層出不窮 ， 令軟件開發(fā)過程很難保證按預定的計劃實現 ，給項目計劃和論證工作帶來了很大的困難 。 盲目增加軟件開發(fā)人員并不能成比例地提高軟件開發(fā)能力 。 相反 ， 隨著人員數量的增加 ， 人員的組織 、 協調 、 通信 、 培訓和管理等方面的問題將更為嚴重 。 ◎ 軟件質量差 軟件項目即使能按預定日期完成，結果卻不盡人意。1965年至 1970年，美國范登堡基地發(fā)射火箭多次失敗，絕大部分故障是由應用程序錯誤造成的。 在 “ 軟件作坊 ” 里，由于缺乏工程化思想的指導，程序員幾乎總是習慣性地以自己的想法去代替用戶對軟件的需求，軟件設計帶有隨意性，很多功能只是程序員的 “ 一廂情愿 ”而已，這是造成軟件不能令人滿意的重要因素。 ◎ 軟件開發(fā)缺乏適當的文檔資料 文檔資料對于軟件開發(fā)和軟件維護是至關重要的。 ◎ 軟件維護困難 由于在軟件設計和開發(fā)過程中，沒有嚴格遵循軟件開發(fā)標準，各種隨意性很大，沒有完整的真實反映系統狀況的記錄文檔，給軟件維護造成了巨大的困難。 特別是在軟件使用過程中，原來的開發(fā)人員可能因各種原因已經離開原來的開發(fā)組織，使得軟件幾乎不可維護。 有資料表明，工業(yè)界為維護軟件支付的費用占全部硬件和軟件費用的 40%75%。 ◇ 如何克服軟件危機 人們面臨的不光是技術問題，更重要的是管理問題。管理不善必然導致失敗 。 要提高軟件開發(fā)效率，提高軟件產品質量，必須采用 工程化 的開發(fā)方法與工業(yè)化的生產技術。 ＝＝ 》 軟件工程 軟件生命周期 ? 軟件從孕育、誕生、成長、衰亡的生存過程，稱為軟件的生命周期。 ? 六個步驟： – 制定計劃：問題分析、可行性研究 – 需求分析 – 軟件系統設計：總體設計、詳細設計 – 軟件編碼 – 軟件測試 – 軟件維護 第二章 軟件體系結構 ? 基本概念 ? 重要性 ? 組件與連接器 ? 風格與模式 ? 非功能屬性 第一節(jié) 基本概念 ? 定義還沒有達到共識。 ? 以下幾個有助于我們的理解 – 軟件體系結構是一組具有一定形式的結構化元素（設計元素）組成。 – 軟件體系結構超越了計算過程中的算法設計和數據結構。 – 四視圖觀點：概念上的體系結構、模塊體系結構、代碼體系結構和運行體系結構。 – 四模式觀點：概念模式、框架模式、動態(tài)模式、進程模式 ? 所以： ? 軟件體系結構對軟件系統的構造起著指導性作用。 ? 它回避了軟件系統的功能細節(jié)，著重于討論軟件系統的總體構架。 ? 它關注的是系統結構及其組成組件。 ? 修正后的軟件生命周期： – 需求分析 – 體系結構設計 ：選擇模式，選擇組件，組件之間的關系以及它們之間的約束。以此為框架，為詳細設計奠定基礎。－原為 “ 總體設計 ” – 詳細設計 – 實現 – 維護 第二節(jié) 重要性 ? 良好的體系結構設計是決定軟件系統成功的重要因素。 ? 早期的教訓： IBM OS/360（ 19631966） 軟件體系結構的指導意義 ? 作為軟件開發(fā)的基本指導方針 ? 整個軟件設計的開端，決定著開發(fā)工作的整體結構，具有更大的決策性和約束性。 ? 體系結構給予后繼開發(fā)人員一個可實現的指導和約束。 軟件體系結構的指導意義 ? 對軟件質量保證具有重大的影響 ? 支配了從開發(fā)到維護項目的團隊組織結構 ? 對軟件的修改、變動提供了保證和約束。 ? 提供了軟件的可重用性 為什么體系結構沒能早日引進來呢？ ? 早期軟件開發(fā)被認為是個人創(chuàng)造力的產物，靈活性很高，從而導致開發(fā)者無規(guī)可循。 ? 早期軟件開發(fā)的規(guī)模較小，開發(fā)通常由個人或者小的團隊來完成，團隊易于溝通交流，體系結構的要求不迫切。 ? 軟件產品提交給用戶的為編譯后的軟件，不能看到源代碼，其他人難以分析其結構，阻礙了技術的傳播。 第三節(jié) 組件和連接器 ? 現代軟件系統通常采用組件（構件）的開發(fā)方法 ? 組件： 系統中的結構塊，是軟件功能設計和實現的承載體。 ? 連接器： 組件之間進行連接的組件。 ? 軟件體系結構的兩大構成：組件、連接器 組件 ? 組件： 系統中的結構塊，是軟件功能設計和實現的承載體。 ? 組件的表達形式： – 組件是由 封裝的內部數據結構及其操作 ，以及 對外提供的操作方法集合 組成。－例： 公安局 組件 接口 組件的特性 （ 略 ） 連接器 ? 連接： 組件之間建立和維護行為關聯及信息傳遞的途徑。 ? 連接包含兩方面： – 物質基礎：連接發(fā)生和維持的機制； – 規(guī)約協議：連接能夠正確地、無二義、無沖突地進行信息交換的保證。 – 例： 電源轉接板 簡單連接：兩個組件直接連接 ? 復雜連接：專門的連接組件（連接器） 連接器 A組件 A組件 B組件 B組件 ? 連接的特性（略）： 方向性、激發(fā)、響應特性 ? 連接的匹配（連接器如何工作的呢）： – 修改組件： 有源代碼 – 進行包裝： 常用方法 – 加入中介： 比較復雜或要求靈活性的 – 握手： 經常變動的系統 第四節(jié) 風格和模式 ? 軟件設計人員在長期開發(fā)某種類型軟件過程中摸索到該類軟件的一些規(guī)律性的東西，經過提煉總結，得到了具有普遍性的構建 模式 或稱為構建 風格 。 ? 本課程將討論學習應用較廣泛的體系結構風格或模式。 ? 使用軟件體系結構的風格和模式的意義： – 便于設計開發(fā)者之間互相交流 – 促進了設計的復用 – 也促進了代碼的復用 – 使用標準的風格和模式有利于支持互操作 所以： 有利于交流和理解； 有利于提高軟件設計實施的效率和質量； 風格和模式的完善和系統化，也標志軟件體系結構的成熟。 ? 我們對風格、模式和框架不加區(qū)分。 ? 我們講解側重于 模式。 ? 模式分為三個層次： – 系統體系結構模式（第三章） – 體系結構的設計模式（第四章） – 基礎結構模式（第五章） 系統體系結構模式 體系結構的設計模式 基礎結構模式 范圍最大 ， 層次最高 中等規(guī)模 ， 獨立于特定語言 最低層 、 最基礎的模式 ，和特定語言有關 系統體系結構模式 體系結構的設計模式 基礎結構模式 ? 卷一、卷二、卷三 參考書 ? Robert C. Martin ? 清華大學出版社 第五節(jié) 非功能屬性 ? 功能屬性 ? 非功能屬性： – 易修改性： ? 可維護性 ? 可擴展性 ? 結構重組 – 可移植性： ? 硬件平臺、 ? 操作系統、 ? 用戶界面、 ? 編程語言 – 互操作性 : ? 軟件需要經常與其它系統和周圍的硬軟件軟件入口 – 可靠性 ? 容錯能力 ? 健壯性 – 效率 ? 響應時間、吞吐率、存儲空間 – 可重用性 ? 重用現有的組件和重用以前的項目、商業(yè)庫、設計分析、設計說明。 ? 為重用進行軟件開發(fā) – 可測試性 ? 軟件系統變的越來越大，越來越復雜，軟件測試工作也變得越來越困難和昂貴。 第三章 系統體系結構模式 ? 十種模式： ?管道－過濾器、 ?分層、 ?知識庫（黑板）、 ?MVC、 ?PAC、 ?客戶與服務器 、 ?COM/DCOM/COM+、 ?代理者 、 ?微核 、 ?映像 、 ?異構 每種體系結構的講解內容 ? 概述 ? 結構：靜態(tài) ? 動態(tài)特性 ? 實現 ? 特性 ? 變體 ? 優(yōu)缺點 Google八周歲了 ！ 第 1節(jié) 管道－過濾器 ? 概述