【正文】 理 設備管理 高速緩沖存儲器 Ｏ Ｓ 對虛擬文件的字節(jié)流 , 虛擬文件可為任何設備和實體 抽象 ?逐步求精 ?逐步求精是人類解決復雜問題時采用的基本技術， 也是軟件工程技術的基礎 。 ? 抽象是人類認識復雜現(xiàn)象問題的思維工具之一，抽象就是提取客觀世界中一群事物的某些本質共性（屬性、特征），暫時忽略它們非本質的細節(jié)。也就是說 ， 系統(tǒng)的增大 ， 分析工作的復雜程度不會隨之增大 ， 只是工作量的增大罷了 ， 復雜性不會隨系統(tǒng)的增大而增大 。 ? 分解與抽象 ? 由于大型軟件往往非常復雜 ， 控制軟件復雜性的基本手段是 “ 分解 ” 。模塊保護性 。 如果系統(tǒng)需要微小變更只導致單個模塊的修改 ， 那么 ， 變更引起的副作用就會被最小化 。 ? 模塊可理解性 。 如果一種軟件設計方法能把現(xiàn)存的 （可重用的 ） 設計構件組裝成一個新系統(tǒng) ， 那么 ， 它就能提供一種不是一切從頭開始的模塊化解決方案 。 ? 模塊可分解性 。 當把所有的模塊組裝在一起 ， 就可以獲得問題的解 。 設計人員應該確保檢查設計上的主要概念 ， 避免出現(xiàn)歧義性 、 不一致性。 ? 在創(chuàng)建設計時就應該能夠評估系統(tǒng)的質量 。 即使是在構件設計時 ， 所進行的詳細過程性描述 ， 設計模式的抽象級別也比源代碼高 。 ? 設計應該具有容錯性和異常處理的能力 。 設計人員應該運用設計概念和各種技術 （ 例如 ， 模塊化 、 重用性 、 設計模式等等 ） ， 使得設計具有適應變更能力 。 ? 設計應該具有一致性和集成性 。 也就是“ 問題解 ” 的結構應該盡量模擬 “ 問題域 ” 的結構 。 ? 設計不應該每次從頭做起 。 設計模型滿足需求跟蹤是必要的 ， 設計模型的單獨一個元素經(jīng)常跟蹤到多個需求 。 ? 設計過程不應該受到 “ 隧道視野 ” 的限制 。通過使用軟件分析過程中所獲得的信息，導出可重用的方法。降低模塊和外部環(huán)境連接復雜性的接口 。具有功能獨立的構件 。從可識別的數(shù)據(jù)模式導出數(shù)據(jù)結構 ， 并且適合于將被實現(xiàn)的對象 。包含數(shù)據(jù) 、 體系結構 、 接口和構件 （ 模塊 ） 等的表示 。模塊化 ， 即軟件被邏輯地劃分為特定功能和子功能的構件 。展示一種層次性結構 ， 該結構 （ 1） 已經(jīng)使用可識別的設計模式來建造； （ 2） 由展示良好的設計特征的構件構成； （ 3） 可以用演化的方式實現(xiàn) ， 從而 ， 便于軟件的實現(xiàn)和維護 。 ? 為了更好地評估一個系統(tǒng)的設計質量 ， 應該建立一個良好的設計技術指標 。設計必須具有良好的可讀性和可理解性 ， 以便于代碼的生成 ， 以及軟件測試和維護； ? 映射 軟件設計目標 ? 軟件設計是一個把軟件需求轉化為軟件表示的過程 ， 也就是把它加工為在程序細節(jié)上非常接近于源程序的軟件表示 （ 描述 ） 。第四章 軟件設計 主要內(nèi)容： ▲ 軟件設計的基本概念和原則 ▲ 軟件設計模型 ▲ 軟件重用技術 ▲ 軟件設計模式 167。 ?設計指的是應用各種技術和原理對一個設備 、 一個過程或者一個系統(tǒng)做出足夠詳細的規(guī)定 ， 使之能夠在物理上得以實現(xiàn) 。 軟件需求：解決 “ 做什么 ” 軟件設計：解決 “ 怎么做 ” 問題結構 (軟件需求 ) 軟件結構 從軟件需求規(guī)格說明書出發(fā)，形成軟件的具體設計方案。設計必須實現(xiàn)分析模型中所有的功能和性能的需求； ? 設計應該是完整的 ， 包括數(shù)據(jù) 、 體系結構 、 功能 、 行為 、 接口等設計 。 ? ? ? ? ? ? ? 軟件設計原則 ? 軟件設計人員應該具有創(chuàng)造能力 ， 根據(jù)問題的要求和可用的資源 ， 以及設計的概念進行判斷 ， 采用適當?shù)脑O計手段 。設計應該可以跟蹤到分析模型 。 ? 很多模式在過去也許已經(jīng)用過 ， 系統(tǒng)應該使用一系列設計模式來構造 。軟件設計的結構應該盡量模擬問題域結構 。 ? 整個系統(tǒng)具有統(tǒng)一的風格和格式；如果構件具有良好的接口 ， 那么 ， 系統(tǒng)就容易集成 。設計應該適應變更 。 ? 一個良好的系統(tǒng)應該從不 “ 徹底崩潰 ” ， 當它遇到異常的條件 （ 例如異常的數(shù)據(jù) 、 事件 、 操作條件等 ） 也能夠平滑處理 。設計不是編碼 。 ? 事實上 ，目前很多設計方法都支持對設計模型的評審 。應該評審設計以減少概念性的錯誤 。 軟件設計原理 – 模塊化 ?把軟件按照規(guī)定的原則 ， 劃分為一個個較小的相互獨立 ， 但又相關的部件 ， 每一個部件稱為模塊 ， 注意到模塊可以獨立命名和編址 ， 系統(tǒng)模塊化又稱模塊設計 。 ? 如果一種軟件設計方法提供了將問題分解成子問題的系統(tǒng)化機制 ， 那么 ， 它就能降低整個系統(tǒng)的復雜性 ， 從而可以實現(xiàn)一種有效的模塊化解決方案。模塊可組裝性 。 ? 如果一個模塊不用參考其他模塊可以作為一個獨立的單位被理解 ， 那么 ， 它就易于構造和修改 。模塊連續(xù)性 。 ? 如果模塊內(nèi)出現(xiàn)異常情況 ， 并且它的影響限制在該模塊內(nèi)部 ， 那么 ， 由錯誤引起副作用就會被最小化 。 在系統(tǒng)分析中 ， 無論系統(tǒng)有多么大 ， 總可以有計劃地把它分解足夠小的子問題 。 這種思想方法依然可用于設計階段 ， 分解是處理復雜問題常用的方法 。由特殊到一般的思維（由底向上），上層是下層的一個抽象；反之，由頂向下可以解釋為由抽象到具體，下層是對上層的精化、細化。 所謂逐步求精是 “為了能集中精力解決主要問題而盡量推遲問題細節(jié)的考慮 ” 。 逐步求精是確保每一個問題在適當?shù)臅r候得到解決 。 – 信息隱藏 ?信息隱藏來自于 1972 ： ?(1)模塊內(nèi)部的數(shù)據(jù)和過程 ， 對于那些不需要這些信息的模塊不可訪問 （ 隱藏 ） ； ?(2)每一個模塊只完成一個相對獨立的特定功能； ?(3)模塊之間僅僅交換那些完成系統(tǒng)功能必須交換的信息 （ 該交換的才交換 ） 。 模塊獨立性不僅使模塊重用性好 ， 而且易于測試 、組裝和維護等等 。 數(shù)據(jù)設計的基礎是 ， 分析模型中數(shù)據(jù)模型和數(shù)據(jù)字典 。 體系結構設計也就是建立基于計算機的系統(tǒng)的框架 ， 它包括系統(tǒng)主要組件以及通信的識別 ， 可以從系統(tǒng)規(guī)格 、 分析模型以及分析模型中定義的子系統(tǒng)的交互導出 。 一個接口意味著信息流和特定的行為類型 ， 數(shù)據(jù)流和控制流的信息是接口設計的基礎 。 過程設計的基礎是處理規(guī)格說明 、 控制規(guī)格說明 、 狀態(tài)轉換圖的信息。 體系結構設計表示要建造一個基于計算機系統(tǒng)所需要的數(shù)據(jù)和程序構件的結構 ， 而重點關注的是軟件構件結構 ， 構件的性質以及它們的交互 。系統(tǒng)結構化 。 ? 建立系統(tǒng)各個部分之間控制關系的構成模型 。 ? 把子系統(tǒng)進一步分解成模塊， 這時 ， 軟件結構設計是要確定模塊的類型以及模塊之間的關聯(lián) 。 ?（ 2） 一個模塊通常是一個能提供一個或者多個服務的系統(tǒng)組件 （ 構件 ） ， 它能利用其他模塊提供的服務 。 體系結構的重要性 ? ? ?例如，系統(tǒng)的組成有多少個子系統(tǒng)或者模塊，以及各個組成成分之間的相互關系。 P69 圖 43 ?塊狀結構把系統(tǒng)垂直地分解成若干個相對獨立的低耦合的子系統(tǒng) ， 一個子系統(tǒng)相當于一塊 ， 每塊提供一種類型的服務 ， 所以稱為塊狀組織形式 。 位于同一層的多個軟件或者子系統(tǒng) ，具有同等的通用度 （ 通用性程度 ） ， 低層的軟件比高層的軟件更具有通用性 。 P69 圖 44 系統(tǒng)的塊狀結構與層次結構 層次結構 : ? 第一層，最高層應該是應用系統(tǒng)層，可包括多個應用系統(tǒng)。 ? 第二層，次高層是構件系統(tǒng)層，同理，也可以包括多個構件系統(tǒng)，應用系統(tǒng)建立在構件系統(tǒng)之上。 ? 第三層，中間層，它為構件系統(tǒng)提供實用軟件類，這些實用軟件通常不依賴平臺。其中，對象請求代理是使得一個駐留在客戶端的對象，可以發(fā)送消息到封裝在駐留在服務器上的另一個中的方法，對象請求代理標準（ CORBA）得到廣泛地應用。 ? 第四層，它是系統(tǒng)軟件層，例如，一般操作系統(tǒng)、網(wǎng)絡操作系統(tǒng)，硬件接口等。 基于構件系統(tǒng)的分層體系及引用關系 分布式系統(tǒng)體系結構 ?客戶機 /服務器體系結構 。 P71 圖 47 ?主要組成元素 : 一組提供服務的單機服務器 。 一個連接服務器與客戶機的網(wǎng)絡 . ?分布式對象體系結構 。 P72 圖 48 模塊化分解 ?在傳統(tǒng)軟件工程面向數(shù)據(jù)流的方法中，可以通過對數(shù)據(jù)流的分析和設計導出系統(tǒng)的結構圖（變換分析與變換設計、事務分析與事務設計），也就是從數(shù)據(jù)流模型到軟件體系結構的變換方法。 模塊劃分的準則 1． 模塊耦合度 ?模塊耦合度是對軟件結構中各個不同模塊之間互相關聯(lián)程度的度量。 模塊耦合度有 7個等級 ： ?（ 1） 非直接耦合 ?（ 2） 數(shù)據(jù)偶合 ?（ 3） 特征偶合 ?（ 4） 控制耦合 ?（ 5） 外部耦合 ?（ 6） 公共耦合 ?（ 7） 內(nèi)容耦合 ?模塊設計的基本原則是要盡量使用數(shù)據(jù)耦合，減少控制耦合，限制外部耦合和公共耦合，不使用內(nèi)容耦合。 模塊 1 模塊 2 模塊 3 模塊 4 (2) 數(shù)據(jù)耦合 一模塊調(diào)用另一模塊時，被調(diào)用模塊的輸入、輸出都是簡單的數(shù)據(jù) (若干參數(shù) )。 數(shù)據(jù)耦合舉例 開發(fā)票 計算水費 單價 數(shù)量 金額 (3) 標記耦合 (特征耦合 ) 如兩個模塊通過傳遞 數(shù)據(jù)結構 (不是簡單數(shù)據(jù)，而是記錄、數(shù)組 等 )加以聯(lián)系，或都與一個 數(shù)據(jù) 結構 有關系 , 則稱這兩個模塊 間存在標記偶合。 控制耦合舉例 A 計算平均分 或最高分 B 平均 /最高 (控制信號 ) 成績 讀入分數(shù) 輸出結果 計算平均分 計算最高分 平均 /最高 ? B 控制耦合增加了理解和編程的復 雜性，調(diào)用模塊必須知道被調(diào)模 塊的內(nèi)部邏輯，增加了相互依賴 去除模塊間控制耦合的方法： (1)將被調(diào)用模塊內(nèi)的判定上移到調(diào) 用模塊中進行 (2)被調(diào)用模塊分解成若干單一功 能模塊 改控制耦合為數(shù)據(jù)耦合舉例 A 計算平均分 B1