北京交通大學軟件工程(完整教程).ppt

軟件工程 SoftwareEngineering 第1章 軟件工程學概述 1 1軟件危機60年代中期以前 通用硬件相當普遍 軟件卻是為某個具體的應用而編寫的 60年代中到70年代中 軟件作坊 軟件危機 計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題 正常 不正常運行軟件都具有這種問題 1 1 1軟件危機的介紹 1 對軟件開發(fā)成本和進度的估計常常很不準確 2 用戶對完成的軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生 3 軟件產(chǎn)品的質(zhì)量往往靠不住 軟件危機的典型表現(xiàn) 4 軟件常常是不可維護的 5 軟件通常沒有適當?shù)奈臋n資料 6 軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升 7 軟件開發(fā)生產(chǎn)率提高的速度跟不上計算機應用的發(fā)展趨勢 1 1 2產(chǎn)生軟件危機的原因 1 軟件本身特點造成 2 軟件開發(fā)與維護的方法不正確 主要表現(xiàn) a 忽視軟件需求分析 b 認為軟件開發(fā)就是寫程序并使之運行 c 輕視軟件維護 在軟件開發(fā)的不同階段進行修改需要付出的代價很不相同 1 推廣使用在實踐中總結出來的開發(fā)軟件的成功技術和方法 并研究探索更有效的技術和方法 2 開發(fā)和使用更好的軟件工具 3 良好的組織管理措施 1 1 3解決軟件危機的途徑 為了解決軟件危機產(chǎn)生的問題 軟件工程與方法學逐漸形成 然后出現(xiàn)了兩個相互相承又各有側(cè)重的學科 1 軟件工程學 主要應用工程的方法和技術研究軟件開發(fā)與維護的方法 工具和管理的一門交叉學科 2 程序設計方法學 主要應用數(shù)學的方法研究程序的性質(zhì)以及程序設計的理論和方法的學科 1 2軟件工程 1 2 1軟件工程的介紹 1968年NATO會議 軟件工程就是為了經(jīng)濟地獲得可靠的且能在實際機器上有效地運行的軟件 而建立和使用完善的工程原理 1993年IEEE 軟件工程是 1 把系統(tǒng)的 規(guī)范的 可度量的途徑應用于軟件開發(fā) 運行和維護過程 2 研究 1 中提到的途徑 1 軟件工程關注于大型程序的構造 2 軟件工程的中心課題是控制復雜性 3 軟件經(jīng)常變化 4 開發(fā)軟件的效率非常重要 5 和諧地合作是軟件開發(fā)的關鍵 6 軟件必須有效地支持它的用戶 7 在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品 軟件工程的本質(zhì)特性 1 2 2軟件工程的基本原理 1 用分階段的生命周期計劃嚴格管理 2 堅持進行階段評審 3 實行嚴格的產(chǎn)品控制 4 采用現(xiàn)代程序設計技術 5 結果能清楚地審查 6 開發(fā)小組的人員應該少而精 7 承認不斷改進軟件工程實踐的必要性 1 2 3軟件工程方法學通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學 Methodology 也稱為范型 Paradigm 軟件工程方法學的3要素 方法 工具和過程 1 傳統(tǒng)方法學也稱為生命周期方法學或結構化范型 結構化方法 StructureMethod 有 1 結構化設計方法 SD 2 結構化分析方法 SA 3 結構化分析與設計技術 SADT 4 JACKSON方法5 WARNIER方法 2 面向?qū)ο蠓椒▽W把數(shù)據(jù)和對數(shù)據(jù)的操作緊密結合起來的方法 模擬人類認識世界解決問題的方法和過程 面向?qū)ο蟮姆椒?對象 屬性與服務的封裝 分類 繼承 通過消息的通訊 1 適用于實時事物處理系統(tǒng)的有限狀態(tài)機方法 FSM 2 適用于并發(fā)軟件系統(tǒng)的PETRI網(wǎng)方法 3 以數(shù)學概念和理論為基礎的形式化方法 如SDC公司的形式化開發(fā)方法FDM FormalDevelopmentMethodology IBM公司的維也納開發(fā)方法VDM ViennaDevelopmentMethod 3 其他開發(fā)方法 1 3軟件生命周期 軟件生命周期 指軟件從提出到最終被淘汰的這個存在期 軟件生命周期組成 1 軟件定義 A 問題定義B 可行性研究C 需求分析2 軟件開發(fā) D 總體設計E 詳細設計F 編碼和單元測試G 綜合測試3 運行維護 1 問題定義 2 可行性研究 3 需求分析 4 總體設計 概要設計 5 詳細設計 6 編碼與單元測試 7 綜合測試 8 維護 軟件生命周期各個階段 1 4軟件過程 軟件過程 為了獲得高質(zhì)量軟件所需要完成的一系列任務的框架 它規(guī)定了完成各項任務的工作步驟 軟件過程 ISO9000 使用資源將輸入轉(zhuǎn)化為輸出的活動所構成的系統(tǒng) 輸入 如軟件需求輸出 如軟件產(chǎn)品 1 4 1瀑布模型 1 階段間具有順序性和依賴性2 推遲實現(xiàn)的觀點3 質(zhì)量保證的觀點 優(yōu)點 采用規(guī)范的方法 嚴格規(guī)定每個階段提交的文檔 要求每個階段交出的產(chǎn)品必須經(jīng)過驗證 1 4 2快速原型模型優(yōu)點 不帶反饋環(huán) 基本上是線性順序進行 1 4 3增量模型 優(yōu)點 能較短時間內(nèi)提交可完成部分工作的產(chǎn)品 可以使用戶有充裕的時間學習和適應新產(chǎn)品 一種風險更大的增量模型 1 4 4螺旋模型可把它看作在每個階段之前都增加風險分析的快速原型模型 1 4 5噴泉模型 典型的面向?qū)ο筌浖_發(fā)過程模型之一 1 4 6Rational統(tǒng)一過程 1 RUP軟件開發(fā)經(jīng)驗 1 迭代式開發(fā) 2 管理需求 3 使用基于構件的體系結構 4 可視化建模 5 貫穿于開發(fā)過程的軟件質(zhì)量驗證 6 控制軟件變更 1 4 7敏捷過程與極限編程 1 敏捷過程具有高效 快速響應變化的開發(fā)過程 1 個體和交互勝過過程和工具 2 可以工作的軟件勝過面面俱到的文檔 3 客戶合作勝過合同談判 4 響應變化勝過遵循計劃 2 極限編程敏捷過程中最著名的一種 指把好的開發(fā)實踐運用到極致 多應用于軟件需求模糊的場合 1 4 8微軟過程 1 微軟過程準則2 微軟軟件生命周期 1 規(guī)劃階段 2 設計階段 3 開發(fā)階段 4 穩(wěn)定階段 5 發(fā)布階段3 微軟過程模型 問題定義就是要確定為用戶建立什么樣的軟件系統(tǒng) 軟件叫什么樣的名稱等等 問題 是指軟件最基本的問題 如 軟件的總體目標什么 有什么用途 為那些用戶設計 1 5問題定義階段 問題定義報告的內(nèi)容包括 1 軟件項目標題 2 軟件目標 3 軟件用戶對象 4 軟件規(guī)模 問題定義是軟件生命周期中時間最短的階段 一般都比較簡單 因此在實際開發(fā)中它是最容易被忽視的一個階段 這一階段工作主要由系統(tǒng)分析員來完成 系統(tǒng)分析員要盡可能從較高的角度概括軟件所要做的工作 而不用寫明問題的實現(xiàn)細節(jié) 第2章 可行性研究 可行性研究就是要回答 所定義的問題有可行的解決辦法嗎 可行性研究的目的是 用最小的代價在盡可能短的時間內(nèi)確定問題是否有解 以及是否值得去解 2 1可行性研究的任務 可行性研究所需的時間取決于工程的規(guī)模 所需要的成本要占工程總成本的5 10 可行性研究的內(nèi)容 1 技術可行性技術可行性要分析各種技術因素 例如 使用現(xiàn)有的技術能否實現(xiàn)這個系統(tǒng) 是否有勝任開發(fā)該項目的熟練技術人員 能否按期得到開發(fā)該項目所需的軟件 硬件資源 2 經(jīng)濟可行性對經(jīng)濟合理性進行評價 所要考慮的問題是 這個系統(tǒng)的經(jīng)濟效益能否超過它的開發(fā)成本 這就需要對項目進行價格 利益分析 即 投入 產(chǎn)出 分析 由于利益分析取決于軟件系統(tǒng)的特點 因此在軟件開發(fā)之前 很難對新系統(tǒng)產(chǎn)生的效益作出精確的定量描述 所以往往采用一些估算方法 3 操作可行性操作可行性評價系統(tǒng)運行后會引起的各方面變化 如 對組織機構管理模式 用戶工作環(huán)境等產(chǎn)生的影響 4 社會可行性社會可行性主要討論法律方面和使用方面的可行性 例如 被開發(fā)軟件的權利歸屬問題 軟件所使用的技術是否會造成侵權等問題 2 2可行性研究的步驟 1 復查系統(tǒng)規(guī)模和目標 2 研究目前正在使用的系統(tǒng) 3 導出新系統(tǒng)的高層邏輯模型 數(shù)據(jù)流圖 數(shù)據(jù)字典 4 重新定義問題 5 導出和評價供選擇的解法 物理解決方案 6 推薦行動方案 7 草擬開發(fā)計劃 8 書寫文檔提交審查 2 2可行性研究的步驟 2 3系統(tǒng)流程圖 描繪物理系統(tǒng)的工具 2 3 1符號 2 3 2例子 2 4數(shù)據(jù)流圖 描繪數(shù)據(jù)在系統(tǒng)中流動的邏輯過程 2 4 1符號 注意 處理 可表示 單個程序 一系列程序 程序的一個模塊 人工處理過程等等 數(shù)據(jù)存儲 可表示 一個文件 文件的一部分 數(shù)據(jù)庫記錄等等 數(shù)據(jù)流圖忽略出錯處理 打開文件 關閉文件 2 4 2繪制數(shù)據(jù)流圖的例子 2 4 2繪制數(shù)據(jù)流圖的例子 倉庫管理員 采購員 定貨系統(tǒng) 事務 定貨報表 圖2 5定貨系統(tǒng)的基本系統(tǒng)模型 2 4 2繪制數(shù)據(jù)流圖的例子 庫存清單 倉庫管理員 采購員 事務 定貨報表 圖2 6定貨系統(tǒng)的功能級數(shù)據(jù)流圖 定貨信息 定貨信息 組成該例子的數(shù)據(jù)流圖的元素 上述數(shù)據(jù)流圖所描述的功能夠詳細了嗎 2 4 2繪制數(shù)據(jù)流圖的例子 1 為數(shù)據(jù)流 或數(shù)據(jù)存儲 命名A 名字應該代表整個數(shù)據(jù)流 或數(shù)據(jù)存儲 的內(nèi)容 B 不要使用空洞的 缺乏具體含義的名字 如 數(shù)據(jù) 輸入 2 4 3命名 C 如果為某個數(shù)據(jù)流 或數(shù)據(jù)存儲 起名字時遇到困難 則很可能是因為對數(shù)據(jù)流圖的分解不恰當造成的 應該試試重新分解數(shù)據(jù)流圖 2 為處理命名A 通常先為數(shù)據(jù)流命名 然后再為與之相關聯(lián)的處理命名 B 名字應該反映整個處理的功能 C 應該盡量避免空洞籠統(tǒng)的動詞做名字 如 處理 加工 D 通常用一個動詞命名 如果必須用兩個動詞才能描述整個處理的功能 則可能要把這個處理分解成兩個處理更恰當 E 如果在為某個處理命名時遇到困難 則很可能是發(fā)現(xiàn)了分解不當?shù)那闆r 應考慮重新分解 通常 為 數(shù)據(jù)源點 終點 命名時 采用它們在問題域中習慣使用的名字 如 倉庫管理員 采購員 1 利用它作為交流信息的工具 2 作為軟件分析和設計的工具 2 4 4數(shù)據(jù)流圖的用途 2 4 4數(shù)據(jù)流圖的用途 圖2 8對應的物理實現(xiàn)硬件方案 2 4 4數(shù)據(jù)流圖的用途 圖2 9對應的物理實現(xiàn)硬件方案 數(shù)據(jù)字典 對數(shù)據(jù)流圖中包含的所有元素的定義的集合 可行性研究階段 數(shù)據(jù)流圖與數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型 2 5數(shù)據(jù)字典 2 5 1數(shù)據(jù)字典的內(nèi)容數(shù)據(jù)字典應該對下列元素進行定義 1 數(shù)據(jù)流 2 數(shù)據(jù)元素 數(shù)據(jù)流分量 3 數(shù)據(jù)存儲 4 處理 1 數(shù)據(jù)元素字典定義其定義的基本內(nèi)容有 A 數(shù)據(jù)元素編號 名稱及其含義 B 數(shù)據(jù)類型和長度 C 合理取值 D 其他內(nèi)容 如它與其它數(shù)據(jù)的邏輯關系等 2 5 2定義數(shù)據(jù)的方法 數(shù)據(jù)元素字典定義實例 2 數(shù)據(jù)流字典定義其定義的基本內(nèi)容有 A 數(shù)據(jù)流編號及名稱 B 數(shù)據(jù)流來源 C 數(shù)據(jù)流去處 D 數(shù)據(jù)流的組成 E 流通量 F 峰值 數(shù)據(jù)流字典定義實例 3 數(shù)據(jù)存儲字典定義其定義的基本內(nèi)容有 A 數(shù)據(jù)存儲編號及名稱 B 數(shù)據(jù)存儲的組成 C 其它要求 4 數(shù)據(jù)處理字典定義其定義的基本內(nèi)容有 A 數(shù)據(jù)處理編號及名稱 B 簡單描述 C 輸入 輸出 D 功能描述 E 有關數(shù)據(jù)存儲 數(shù)據(jù)處理字典定義實例 5 組成數(shù)據(jù)項的表示方法 表示 等價于 或 定義為 表示 與 與 表示 或 表示重復 表示可選項通訊錄 通訊地址 通訊地址 姓名 郵編 省 直轄市 自治區(qū) 市 縣 街道 門牌號 電話 1 作為分析階段的重要工具 2 數(shù)據(jù)元素的控制信息非常有用 3 有助于開發(fā)數(shù)據(jù)庫 2 5 3數(shù)據(jù)字典的用途 實現(xiàn)數(shù)據(jù)字典 1 程序處理 2 卡片式人工書寫 2 5 4數(shù)據(jù)字典的實現(xiàn) 2 6成本 效益分析 1 代碼行技術軟件成本 每行代碼的平均成本 估計的源代碼總行數(shù) 2 6 1成本估計 2 任務分解技術軟件開發(fā)項目分解為若干個相對獨立的任務 分別估計每個單獨任務的成本 單獨任務成本 任務所需人力估計值 每人每月平均工資 軟件開發(fā)項目總成本估計 各個單獨任務成本估計值之和 常用的辦法是按開發(fā)階段劃分任務 典型環(huán)境下各個開發(fā)階段需要使用的人力百分比大致如下 3 自動估計成本技術采用自動估計成本的軟件工具估計 1 Putnam模型1978年Putnam提出的 一種動態(tài)多變量模型 軟件開發(fā)成本估算的經(jīng)驗模型 Ck為技術狀態(tài)常數(shù) 它反映 妨礙開發(fā)進展的限制 取值因開發(fā)環(huán)境而異 見下表 2 COCOMO模型 constructivecostmodel 這是由TRW公司開發(fā) Boehm提出的結構化成本估算模型 是一種精確的 易于使用的成本估算方法 基本COCOMO模型估算工作量和進度的公式如下 工作量 MM r KDSI c 人月 開發(fā)時間 TDKV a MM b 月 DSI 源指令條數(shù) 不包括注釋 1KDSI 1000DSIMM 開發(fā)工作量 以人月計 1MM 19人日 152人時 1 12人年經(jīng)驗常數(shù)r c a b取決于項目的總體類型 COCOMO模型中 考慮開發(fā)環(huán)境 軟件開發(fā)項目的類型可以分為3種 1 組織型 organic 相對較小 較簡單的軟件項目 開發(fā)人員對開發(fā)目標理解比較充分 與軟件系統(tǒng)相關的工作經(jīng)驗豐富 對軟件的使用環(huán)境很熟悉 受硬件的約束較小 程序的規(guī)模不是很大 50000行 2 嵌入型 embedded 要求在緊密聯(lián)系的硬件 軟件和操作的限制條件下運行 通常與某種復雜的硬件設備緊密結合在一起 對接口 數(shù)據(jù)結構 算法的要求高 軟件規(guī)模任意 如大而復雜的事務處理系統(tǒng) 大型 超大型操作系統(tǒng) 航天用控制系統(tǒng) 大型指揮系統(tǒng)等 3 半獨立型 semidetached 介于上述兩種軟件之間 規(guī)模和復雜度都屬于中等或更高 最大可達30萬行 COCOMO模型按其詳細程度可以分為三級 1 基本COCOMO模型是一個靜態(tài)單變量模型 它用一個以已估算出來的原代碼行數(shù) LOC 為自變量的經(jīng)驗函數(shù)計算軟件開發(fā)工作量 基本COCOMO模型通過統(tǒng)計63個歷史項目的歷史數(shù)據(jù) 得到如下計算公式 2 中級COCOMO模型在基本COCOMO模型的基礎上 再用涉及產(chǎn)品 硬件 人員 項目等方面的影響因素調(diào)整工作量的估算 3 詳細COCOMO模型包括中級COCOMO模型的所有特性 但更進一步考慮了軟件工程中每一步驟 如分析 設計 的影響 1 貨幣的時間價值假設年利率為i 如果現(xiàn)在存入P元錢 則n年以后可以得到的錢數(shù)為 反之 如果n年后能收入F元錢 那么這些錢現(xiàn)在的價值是 2 6 2成本 效益分析 例 修改一個已有的庫存管理系統(tǒng) 估計需要5000元 系統(tǒng)修改后使用5年 每年可節(jié)省2500元 請進行成本 效益分析 表1 將來的收入折算成現(xiàn)在值 2 投資回收期第一 第二年回收 4225元第三年用于回收投資要 5000 4225 1779 0 44年總的投資回收期 2 44年 3 純收入9011 94 5000 4011 94 元 4 投資回收率其中 P是現(xiàn)在的投資額 Fi是第i年年底的效益 i 1 2 3 n n是系統(tǒng)的使用壽命 一般假設n 5 j是投資回收率 上述修改系統(tǒng)的工程的投資回收率是41 42 第2章小結 可行性分析報告說明該軟件開發(fā)項目的實現(xiàn)在技術上 經(jīng)濟上和社會因素上的可行性 評述為了合理地達到開發(fā)目標可供選擇的各種可能實施方案 說明并論證所選定實施方案的理由 項目開發(fā)計劃為軟件項目實施方案制訂出具體計劃 應該包括各部分工作的負責人員 開發(fā)的進度 開發(fā)經(jīng)費的預算 所需的硬件及軟件資源等 第3章 需求分析 3 1 1確定對系統(tǒng)的綜合要求1 功能需求2 性能需求如 相應時間 速度 主存容量 磁盤容量 安全性 等 3 1需求分析的任務 3 可靠性和可用性需求4 出錯處理需求系統(tǒng)發(fā)現(xiàn)錯誤時采取的行動 主要在系統(tǒng)關鍵部分設置 5 接口需求用戶接口 硬件接口 軟件接口 通信接口 等 6 約束精度 工具和語言 設計約束 硬件約束 標準 等 7 逆向需求8 將來可能提出的要求 3 1 3導出系統(tǒng)的邏輯模型包括完善的數(shù)據(jù)流圖 實體 聯(lián)系圖 狀態(tài)轉(zhuǎn)換圖 數(shù)據(jù)字典 主要的處理算法 IPO圖 等 3 1 2分析系統(tǒng)的數(shù)據(jù)要求通過建立數(shù)據(jù)模型來分析 如數(shù)據(jù)字典 層次方框圖 Warnier圖 并將數(shù)據(jù)結構規(guī)范化 3 1 4修正系統(tǒng)開發(fā)計劃修訂前期制定的開發(fā)進度計劃 等 3 2與用戶溝通獲取需求的方法 3 2 1訪談 正式訪談 系統(tǒng)分析員提出事先準備好的問題 非正式訪談 提出一些用戶可以自由回答的開放性問題 鼓勵被訪者說出自己的想法 需要訪問大量人員時 利用調(diào)查表訪問較佳 3 2 2面向數(shù)據(jù)流自頂向下求精 借助數(shù)據(jù)流圖 數(shù)據(jù)字典 IPO圖等 細化 完善詳細的數(shù)據(jù)流圖 等到各處理環(huán)節(jié)對應的功能 例 分析銷售趨勢 統(tǒng)計功能 3 2 3簡易的應用規(guī)格說明技術 面向團隊的需求收集法 用戶與開發(fā)者配合 1 初步訪談 2 開發(fā)者和用戶分別寫出 產(chǎn)品需求 3 開會討論 各自展示需求列表 4 得出一致意見 為需求列表制定小型規(guī)格說明 5 根據(jù)會議成果 起草完整的軟件需求規(guī)格說明 3 2 4快速建立軟件原型 快速建立能演示目標系統(tǒng)主要功能的程序 1 第四代技術 2 可重用的軟件構件 3 形式化規(guī)格說明和原型環(huán)境 3 3分析建模與規(guī)格說明 3 3 1分析建模為了開發(fā)復雜的系統(tǒng) 應從不同角度 模型 抽象出目標系統(tǒng)的特性 數(shù)據(jù)模型 功能模型 行為模型 1 實體聯(lián)系圖 建立數(shù)據(jù)模型 描述數(shù)據(jù)對象及數(shù)據(jù)對象之間的關系 2 數(shù)據(jù)流圖 建立功能模型的基礎 3 狀態(tài)轉(zhuǎn)換圖 描繪系統(tǒng)的狀態(tài)和狀態(tài)間轉(zhuǎn)換的方式 3 3 2軟件需求規(guī)格說明 3 4實體 聯(lián)系圖 數(shù)據(jù)對象可以是外部實體 事物 行為 事件 角色 單位 地點 結構等 3 4 1數(shù)據(jù)對象 3 4 2屬性屬性定義了數(shù)據(jù)對象的性質(zhì) 屬性 3 4 3聯(lián)系 1 一對一聯(lián)系 1 1 2 一對多聯(lián)系 1 N 3 多對多聯(lián)系 M N 在ER圖中 用菱形框表示聯(lián)系 聯(lián)系 例子 通常用范式定義消除數(shù)據(jù)冗余的程度 1 第一范式2 第二范式3 第三范式 3 5數(shù)據(jù)規(guī)范化 3 6狀態(tài)轉(zhuǎn)換圖 3 6 1狀態(tài)狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式 一個狀態(tài)代表系統(tǒng)的一種行為模式 3 6 2事件事件是某個特定時刻發(fā)生的事情 它是引起系統(tǒng)做動作或狀態(tài)轉(zhuǎn)換的控制信息 3 6 3符號 3 6 4例子 3 7其他圖形工具 層次方框圖用樹形結構的一系列多層次的矩形框描繪數(shù)據(jù)的層次結構 3 7 1層次方框圖 Warnier圖也用樹形結構描繪信息 但是這種圖形工具比層次方框圖提供了更豐富的描繪手段 3 7 2Warnier圖 IPO圖是輸入 處理 輸出圖 3 7 3IPO圖 3 8驗證軟件需求 1 一致性2 完整性3 現(xiàn)實性4 有效性 3 8 1驗證軟件需求的正確性 1 驗證需求的一致性2 驗證需求的現(xiàn)實性3 驗證需求的完整性和有效性 3 8 2驗證軟件需求的方法 用于需求分析的軟件應該滿足下列要求 1 必須有形式化的語法2 使用這個軟件工具能夠?qū)С鲈敿毜奈臋n3 必須提供分析規(guī)格說明書的不一致性和冗余性的手段4 使用這個軟件工具后 應該能夠改進通信狀況 3 8 3用于需求分析的軟件工具 RSL 需求陳述語言 信息集 ASSM PASCAL模擬程序PSL PSA 問題陳述語言 問題陳述分析程序 系統(tǒng) 第3章小結 軟件需求說明書 軟件規(guī)格說明書 對所開發(fā)軟件的功能 性能 用戶界面及運行環(huán)境等作出詳細的說明 它是在用戶與開發(fā)人員雙方對軟件需求取得共同理解并達成協(xié)議的條件下編寫的 也是實施開發(fā)工作的基礎 該說明書應給出數(shù)據(jù)邏輯和數(shù)據(jù)采集的各項要求 為生成和維護系統(tǒng)數(shù)據(jù)文件做好準備 第4章 形式化說明技術 1 非形式化方法 自然語言描述2 半形式化方法 數(shù)據(jù)流圖或?qū)嶓w 聯(lián)系圖3 形式化方法 基于數(shù)學技術描述 4 1概述 4 1 1非形式化方法的缺點自然語言書寫的系統(tǒng)規(guī)格說明書可能存在 1 矛盾 2 二義性 如 操作員標識由操作員姓名和密碼組成 密碼由6位數(shù)字構成 當操作員登陸系統(tǒng)時它被存儲在注冊文件中 3 含糊性 4 不完整性 5 抽象層次混亂 4 1 2形式化方法的優(yōu)點 1 數(shù)學是理想的建模工具 適合于表示系統(tǒng)狀態(tài)和描述系統(tǒng)需求 2 用數(shù)學表達的需求可在不同開發(fā)階段平滑過渡 4 1 3應用形式化方法的準則 1 選擇合適的形式化方法 2 需要形式化 但不能過渡形式化 不能放棄傳統(tǒng)的需求表達方法 3 應該有形式化方法的專家提供指導 4 2有窮狀態(tài)機法 FSM 4 2 1概念 鎖的三個位置 1 2 3 轉(zhuǎn)盤可向左 L 或右 R 鎖密碼 1L 3R 2L 一個有窮狀態(tài)機包括5部分 1 狀態(tài)集J 保險箱鎖定 A B 保險箱解鎖 報警 2 輸入集K 1L 1R 2L 2R 3L 3R 3 轉(zhuǎn)換函數(shù)T 如表4 14 初始狀態(tài)S 保險箱鎖定5 終態(tài)集F 保險箱解鎖 報警 更形式化的術語 一個有窮狀態(tài)機可表示一個為5元組 J K T S F 狀態(tài)轉(zhuǎn)換形式 當前狀態(tài) 菜單 事件 所選擇的項 下個狀態(tài)加入謂詞集P 把系統(tǒng)擴展成一個6元組后 當前狀態(tài) 菜單 事件 所選擇的項 謂詞 下個狀態(tài) 計算機系統(tǒng)中每個菜單驅(qū)動的用戶界面都是一個有窮狀態(tài)機的實現(xiàn) 定義狀態(tài) 1 M d e f 電梯e正沿d方向移動 即將到達第f層樓 2 S d e f 電梯e停在f層樓 將朝d方向移動 未關門 3 W e f 電梯e在f層等待 已關門 4 DC e f 電梯e在樓層f關上門 5 ST e f 電梯e靠近f層時觸發(fā)傳感器 電梯控制器決定在當前樓層是否停下 6 RL 電梯按鈕或樓層按鈕被按下進入打開狀態(tài) 4 2 2例子 電梯的狀態(tài)轉(zhuǎn)換 電梯狀態(tài)轉(zhuǎn)換規(guī)則 S U e f DC e f M U e f 1 S D e f DC e f M D e f 1 S N e f DC e f W e f 4 2 3評價有窮狀態(tài)機描述規(guī)格說明 當前狀態(tài) 事件 謂詞 下個狀態(tài)易于書寫 驗證 轉(zhuǎn)變成設計或程序代碼 有窮狀態(tài)機方法比數(shù)據(jù)流圖技術更精確 一樣易于理解 但不能處理定時需求 4 3Petri網(wǎng) 4 3 1概念 Petri網(wǎng)包含4種元素 1 一組位置P 上例P P1 P2 P3 P4 2 一組轉(zhuǎn)換T 上例T t1 t2 3 輸入函數(shù)I 上例I t1 P2 P4 I t2 P2 4 輸出函數(shù)O 上例O t1 P1 O t2 P3 P3 更形式化的Petri網(wǎng)結構 是一個4元組 P T I O 權標向量 1 2 0 1 權標向量 2 1 0 0 權標向量 2 0 2 0 更形式化地 標記M P 0 1 2 Petri網(wǎng)成為一個5元組 P T I O M 對Petri網(wǎng)的一個重要擴充是加入禁止線 4 3 2例子1 電梯按鈕 EBf電梯中樓層f的按鈕 Fg樓層g Ff樓層f 2 樓層按鈕 FBfu第f樓層向上按鈕 FBfd第f樓層向下按鈕 小結基于數(shù)學的形式化說明技術 目前還沒有在軟件產(chǎn)業(yè)界廣泛應用 應該把形式化方法與傳統(tǒng)方法有機結合 第5章 總體設計 5 1設計過程 1 設想供選擇的方案 2 選擇合理的方案對每個合理的方案要提供 A 系統(tǒng)流程圖B 組成系統(tǒng)的物理元素清單C 成本 效益分析D 實現(xiàn)這個系統(tǒng)的進度計劃 3 推薦最佳方案4 功能分解5 設計軟件結構6 數(shù)據(jù)庫設計A 模式設計B 子模式設計C 完整性和安全性設計D 優(yōu)化 7 制定測試計劃8 書寫文檔A 系統(tǒng)說明B 用戶手冊C 測試計劃D 詳細的實現(xiàn)計劃E 數(shù)據(jù)庫設計結果9 審查和復審 5 2設計原理 如果一個大型程序僅由一個模塊組成 很難被人理解 設函數(shù)C x 定義問題x的復雜程度 函數(shù)E x 定義解決問題x需要的工作量 時間 對于兩個問題P1和P2 如果 C P1 C P2 那么E P1 E P2 根據(jù)解決問題的經(jīng)驗 有一個規(guī)律是 C P1 P2 C P1 C P2 于是有E P1 P2 E P1 E P2 5 2 1模塊化 5 2 2抽象 5 2 3逐步求精 模塊的獨立性很重要 因為 1 有效的模塊化的軟件比較容易開發(fā)出來 2 獨立的模塊比較容易測試和維護 5 2 4信息隱蔽和局部化 5 2 5模塊獨立 一 耦合 耦合 指軟件結構內(nèi)不同模塊彼此之間相互依賴 連接 的緊密程度 模塊獨立程度可以由兩個定性標準度量 耦合與內(nèi)聚 模塊的偶合分四類 1 數(shù)據(jù)耦合兩個模塊之間只是通過參數(shù)交換信息 而且交換的信息僅僅是數(shù)據(jù) 數(shù)據(jù)耦合是最低程度的耦合 2 控制耦合兩個模塊之間所交換的信息包含控制信息 控制耦合是中等程度的耦合 圖中模塊A的內(nèi)部處理程序判斷是執(zhí)行C還是執(zhí)行D 要取決于模塊B傳來的信息狀態(tài) Status 3 公用耦合兩個或多個模塊通過一個公共區(qū)相互作用時的耦合 公共區(qū)可以是 全程數(shù)據(jù)區(qū) 共享通信區(qū) 內(nèi)存公共覆蓋區(qū) 任何介質(zhì)上的文件 物理設備等 軟件結構中存在大量的公用耦合時會給診斷錯誤帶來困難 圖中存在公用耦合 假設模塊A C E都存取全程數(shù)據(jù)區(qū) 如公用一個磁盤文件 中的一個數(shù)據(jù)項 如果A模塊讀取該項數(shù)據(jù) 然后調(diào)用C模塊對該項重新計算 并進行數(shù)據(jù)更新 如果此時C模塊錯誤地更新了該項數(shù)據(jù) 在往下的處理中模塊E讀該數(shù)據(jù)項時出現(xiàn)錯誤 表面上看 問題由模塊E產(chǎn)生 實際上由模塊C引起 4 內(nèi)容耦合一個模塊與另一個模塊的內(nèi)容直接發(fā)生聯(lián)系 內(nèi)容耦合對維護會帶來嚴重的困難 程序中如果一個模塊直接把程序轉(zhuǎn)移到另一個模塊中 或一個模塊使用另一個模塊內(nèi)部的數(shù)據(jù) 都會產(chǎn)生內(nèi)容耦合 內(nèi)容耦合是最高程度的耦合 應該避免采用 軟件設計應追求盡可能松散耦合 避免強耦合 這樣模塊間的聯(lián)系就越小 模塊的獨立性就越強 對模塊的測試 維護就越容易 因此建議 盡量使用數(shù)據(jù)耦合 少用控制耦合 限制公用耦合 完全不用內(nèi)容偶合 二 內(nèi)聚 內(nèi)聚 一個模塊內(nèi)部各個元素彼此結合的緊密程度 它是衡量一個模塊內(nèi)部組成部分間整體統(tǒng)一性的度量 常見的內(nèi)聚有七類 1 功能內(nèi)聚 FunctionalCohesion 如果一個模塊內(nèi)所有處理元素完成一個 而且僅完成一個功能 則稱為功能內(nèi)聚 功能內(nèi)聚是最高程度的內(nèi)聚 但在軟件結構中 并不是每個模塊都能設計成一個功能內(nèi)聚模塊 2 順序內(nèi)聚 SequentialCohesion 如果一個模塊內(nèi)處理元素和同一個功能密切相關 而且這些處理元素必須順序執(zhí)行 則稱為順序內(nèi)聚 如圖 一個求一元二次方程根的模塊由三個處理元素組成 該模塊中存在順序內(nèi)聚 通常 順序內(nèi)聚中一個處理元素的輸出是另一個處理元素的輸入 3 通信內(nèi)聚 CommunicationalCohesion 如果一個模塊中所有處理元素都使用同一個輸入數(shù)據(jù)和 或 產(chǎn)生同一個輸出數(shù)據(jù) 稱為通信內(nèi)聚 如圖 模塊A的處理單元將根據(jù)同一個數(shù)據(jù)文件FILE的數(shù)據(jù)產(chǎn)生不同的表格 因此它存在通信內(nèi)聚 通信內(nèi)聚有時也稱為數(shù)據(jù)內(nèi)聚 4 過程內(nèi)聚 ProceduralCohesion 如果一個模塊內(nèi)的處理元素是相關的 而且必須以特定的次序執(zhí)行 稱為過程內(nèi)聚 過程內(nèi)聚與順序內(nèi)聚的區(qū)別是 順序內(nèi)聚中是數(shù)據(jù)流從一個處理單元流到另一個處理單元 而過程內(nèi)聚是控制流從一個動作流向另一個動作 5 時間內(nèi)聚 TemporalCohesion 如果一個模塊包含的任務必須在同一段時間內(nèi)執(zhí)行 稱為時間內(nèi)聚 也稱為瞬時內(nèi)聚 例如 完成各種初始化工作的模塊 或者處理故障的模塊都存在時間內(nèi)聚 如圖 在 緊急故障處理模塊 中 關閉文件 報警 保留現(xiàn)場 等任務都必須無中斷地同時處理 6 邏輯內(nèi)聚 LogicalCohesion 如果模塊完成的任務在邏輯上屬于相同或相似的一類 稱為邏輯內(nèi)聚 如圖 A B C模塊合并成ABC模塊之后 ABC模塊就是邏輯內(nèi)聚模塊 對邏輯內(nèi)聚模塊的調(diào)用 常常需要有一個功能開關 由上層調(diào)用模塊向它發(fā)出一個控制信號 在多個關聯(lián)性功能中選擇執(zhí)行某一個功能 這種內(nèi)聚較差 增加了模塊之間的聯(lián)系 不易修改 7 偶然內(nèi)聚 CoincidentalCohesion 如果一個模塊由完成若干毫無關系的功能處理元素偶然組合在一起的 就叫偶然內(nèi)聚 偶然內(nèi)聚是最差的一種內(nèi)聚 常犯這種錯誤的一種情況是 有時在寫完程序后 發(fā)現(xiàn)一組語句在多處出現(xiàn) 于是為了節(jié)省空間而將這些語句作為一個模塊設計 就出現(xiàn)偶然內(nèi)聚 如圖 模塊A B C出現(xiàn)公共代碼段W 于是將W獨立成一個模塊 而W中這些語句并沒有任何聯(lián)系 如果在測試中發(fā)現(xiàn)模塊A不需要做 X Y Z 而應該做 X Y Z 此時對W的維護就很困難了 軟件設計中應該 力求做到高內(nèi)聚 盡量少用中內(nèi)聚 不用低內(nèi)聚 5 3啟發(fā)式規(guī)則 1 改進軟件結構提高模塊獨立性2 模塊規(guī)模應該適中 3 深度 寬度 扇出和扇入都應適當深度 軟件結構中控制的層數(shù) 寬度 軟件結構內(nèi)同一個層次上的模塊總數(shù)的最大值 扇出 一個模塊直接控制 調(diào)用 其它模塊的數(shù)目 扇入 一個模塊被其它模塊調(diào)用的數(shù)目 對扇出 扇入過大的改進 4 模塊的作用域應該在控制域之內(nèi) 作用域 受該模塊內(nèi)一個判定影響的所有模塊的集合 控制域 模塊本身以及所有從屬于它的模塊的集合 如 QUAD ROOT TBL X 求一元二次方程的根的模塊 其中TBL X都為數(shù)組 分別代表方程的系數(shù)和方程的根 應該使接口更簡單 如 QUAD ROOT A B C ROOT1 ROOT2 A B C是方程的系數(shù) ROOT1 ROOT2是方程的根 5 力爭降低模塊接口的復雜度 6 設計單入口 單出口的模塊 7 模塊功能應該可以預測 5 4圖形工具5 4 1層次圖和HIPO圖 HIPO圖是 層次圖 輸入 處理 輸出圖 5 4 2結構圖 5 5面向數(shù)據(jù)流的設計方法 面向數(shù)據(jù)流設計 DataFlow OrientedDesign DFOD 是與數(shù)據(jù)流分析 DFA 對應的結構化軟件設計技術 面向數(shù)據(jù)流的設計將得到以數(shù)據(jù)流圖為基礎的軟件模塊結構圖 數(shù)據(jù)流可以分為兩種類型 1 變換型數(shù)據(jù)流2 事務型數(shù)據(jù)流 5 5 1變換流與事務流 一 變換流具有較明確的輸入 變換 或稱主加工 和輸出界面的數(shù)據(jù)流圖稱為變換型數(shù)據(jù)流圖 如圖所示 該變換中心可以理解為數(shù)據(jù)的加工和處理程序 事務型數(shù)據(jù)流圖中存在一個事務中心 也就是數(shù)據(jù)處理 加工中心 它將輸入分離成若干個發(fā)散的數(shù)據(jù)流 形成許多活動路徑 并根據(jù)輸入值選擇其中一條路徑 二 事務流 通常 一個實際系統(tǒng)的數(shù)據(jù)流圖是變換型和事務型兩種類型的混合體 如圖所示 中間的子塊屬事務型數(shù)據(jù)流 如果把中間子塊視為一個處理整體的話 整個程序?qū)僮儞Q型程序 面向數(shù)據(jù)流設計軟件結構的基本步驟有七步 1 復審并精化數(shù)據(jù)流圖 2 確定數(shù)據(jù)處理流圖的類型 3 確定變換中心或事務中心 5 5 2面向數(shù)據(jù)流設計的步驟 4 將數(shù)據(jù)流圖映射成軟件模塊結構圖 設計出該數(shù)據(jù)流圖對應的第一層模塊結構 5 基于數(shù)據(jù)流圖逐步分解 設計下層模塊 6 運用模塊設計和優(yōu)化準則優(yōu)化軟件結構 7 描述模塊的接口 變換設計就是從變換型數(shù)據(jù)流圖映射出軟件模塊結構的過程 也稱以變換為中心的設計 5 5 3變換設計 變換設計的基本方法有兩步 1 分解第一層模塊結構就是把整個變換分解成輸入控制模塊Ci 輸出控制模塊Co和變換中心控制模塊Ct 由主控模塊控制 2 分別設計輸入 輸出和處理的下層模塊結構方法是 從變換中心邊界向兩側(cè)移動 分別把輸入通路和輸出通路的每個處理映射成輸入控制模塊Ci和輸出控制模塊Co的下屬模塊 變換中心的下層模塊 是把每個處理映射成變換中心控制模塊Ct的一個直接下屬模塊 事務設計就是從事務型數(shù)據(jù)流圖映射出軟件模塊結構的過程 也稱為以事務為中心的設計 5 5 4事務設計 事務設計的基本方法有兩步 1 建立主控模塊 接收輸入類型分析模塊和事務調(diào)度模塊 2 分別設計輸入類型分析模塊和調(diào)度模塊的下層模塊結構 方法是 將輸出的每條通路作為調(diào)度模塊的一個判斷分支 而輸入類型分析模塊的下層模塊與變換設計類似 第5章小結 概要設計說明書該說明書是概要實際階段的工作成果 它應說明功能分配 模塊劃分 程序的總體結構 輸入輸出以及接口設計 運行設計 數(shù)據(jù)結構設計和出錯處理設計等 為詳細設計提供基礎 第6章 詳細設計 目標 確定如何具體實現(xiàn)所要求的系統(tǒng) 不是具體編寫程序 而是設計程序的 藍圖 詳細設計的結果決定最終程序代碼的質(zhì)量 E W Dijkstra最早提出結構程序設計 程序質(zhì)量與程序中包含的Goto語句的數(shù)量成反比 1965 1966 Bohm Jacopini 證明了只用 順序 選擇 循環(huán) 控制結構就能實現(xiàn)任何單入口單出口程序 6 1結構程序設計 理論上 最基本的控制結構只有兩種 順序 循環(huán)結構 選擇結構可由其兩者構造 學界認識到 不是簡單去掉Goto語句的問題 而是要創(chuàng)立一種新的程序設計方法 結構化程序設計 IBM率先成功運用 結構程序設計 一種設計程序的技術 它采用自頂向下逐步求精的設計方法和單入口單出口的控制結構 使用結構程序設計技術的好處 1 提高軟件開發(fā)工程的成功率和生產(chǎn)率 2 系統(tǒng)有清晰的層次結構 容易閱讀理解 3 單入口單出口的控制結構 容易診斷糾正 4 模塊化可以使得軟件可以重用 5 程序邏輯結構清晰 有利于程序正確性證明 經(jīng)典的結構程序設計 只允許使用順序 IF THEN ELSE選擇和DO WHILE循環(huán) 擴展的結構程序設計 除了三種基本控制結構 還使用DO CASE和DO UNTIL循環(huán) 修正的結構程序設計 除了三種基本控制結構和兩種擴充結構 還使用BREAK等結構 流程圖通常由三種結點組成 1 函數(shù)結點如果一個結點有一個入口線和一個出口線 則稱為函數(shù)結點 由于函數(shù)結點一般對應于賦值語句 所以F也表示了這一個結點對應的函數(shù)關系 6 1 1結構化程序6 1 1 1控制結構 2 謂詞結點如果一個結點有一個入口線和兩個出口線 而且它不改變程序的數(shù)據(jù)項的值 則稱為謂詞結點 P是一個謂詞 根據(jù)P的邏輯值 T或F 結點有不同的出口 3 匯點如果一個結點有兩個或多個入口線和一個出口線 而且它不執(zhí)行任何運算 則稱為匯點 1 順序結構 相當于 A B 2 三種基本控制結構 2 選擇結構相當于 IfexpthenAelseBendif 3 循環(huán)結構 相當于 WhileexpdoA 1 多分支結構相當于 CaseIofI 1 C1 I 2 C2 I 3 C3 I n Cn 3 擴充兩種控制結構 2 UNTIL循環(huán)結構相當于 RepeatAUntilexp 6 1 1 2正規(guī)程序定義1 一個流程圖程序如果滿足下面兩個條件 稱為正規(guī)程序 1 具有一個入口線和一個出口線 2 對每一個結點 都有一條從入口線到出口線的通路通過該結點 由于正規(guī)程序有一個入口線和一個出口線 因而一個正規(guī)程序總可以抽象為一個函數(shù)結點 定義2 如果一個正規(guī)程序的某個部分仍然是正規(guī)程序 那么稱它為該正規(guī)程序的正規(guī)子程序 先給出一個概念 封閉結構定義3 流程圖中 兩個結點之間所有沒有重復結點的通路組成的結構稱為封閉結構 6 1 1 3基本程序 如圖 封閉結構為 a b1 b2 b3 c1 c2 d1 d2 d3 e f 1 不包括多于一個結點的正規(guī)子程序 即它是一種不可再分解的正規(guī)程序 程序自身不可視為正規(guī)子程序 2 如果存在封閉結構 封閉結構都是正規(guī)程序 6 1 1 3基本程序 定義4 一個正規(guī)程序 如果滿足以下兩個條件 則稱之為基本程序 基本程序形式有多種 前面提到的三種基本控制結構 順序結構 選擇結構 循環(huán)結構 和兩個擴充控制結構 多分支結構 UNTIL循環(huán)結構 都是基本程序 定義5 用以構造程序的基本程序的集合稱為基集合 如 順序 if then else whiledo 順序 if then else repeat until 都是基集合 定義6 如果一個基本程序的函數(shù)結點用另一個基本函數(shù)程序替換 產(chǎn)生的新的正規(guī)程序稱為復合程序 循環(huán)結構的A函數(shù)結點用另一循環(huán)結構代替 即嵌套循環(huán) 就產(chǎn)生了復合程序 由于復合程序是由一些基本程序組成 因此 無論從總體上看或是從每個組成部分看 都滿足 一個入口 一個出口 的原則 這樣的程序就是通常說的好結構程序 或者結構化程序 定義7 由基本程序的一個固定的基集合構造出的復合程序 稱為結構化程序 結構化定理 任一正規(guī)程序都可以函數(shù)等價于一個由基集合 順序 If else then While do 產(chǎn)生的結構化程序 實際上 只要能證明可以將任一正規(guī)程序轉(zhuǎn)換成等價的結構化程序就可以證明這個結構化定理 6 1 2結構化定理 證明 分三步進行結構化程序的轉(zhuǎn)換 步驟一 從程序入口處開始給程序的函數(shù)結點和謂詞結點編號 1 2 3 n 同時 將每個函數(shù)和謂詞結點的出口線用它后面的結點的號碼進行編號 如果出口線后面沒有結點 也就是說該結點的出口線與程序的出口線相連時 出口線編號為0 步驟二 對原程序中每一個編號為i 出口線編號為j的函數(shù)結點H 構造一個新的序列程序Gi 如圖 類似地 對于每個編號為i 出口線分別為j和k的謂詞結點 構造一個新的選擇程序Gi 如圖 步驟三 利用已經(jīng)得到的一些Gi程序 i 1 2 3 n 按下圖的形式構造一個While do循環(huán) 圖中的循環(huán)體是一個對L從1到n的嵌套選擇 if then else 程序 轉(zhuǎn)換后的程序與原程序是等價的 是由基集合 順序 選擇 循環(huán) 所復合成的結構化程序 這種方法并不是唯一的把程序轉(zhuǎn)變?yōu)榻Y構化程序的方法 所得的程序也不一定是最好的 它的目的是為了證明結構化定理 例1 把圖示的非結構化程序轉(zhuǎn)換成結構化程序 用結構化定理證明過程提供的方法轉(zhuǎn)換 6 1 3非結構化程序到結構化程序的轉(zhuǎn)換 1 進行結點及其出口線的編號 2 將圖中的四個結點構造新的程序G1 G2 G3 G4 3 利用得到的G1 G2 G3 G4按介紹的方法構造一個While do循環(huán) 最終結果如圖 6 2人機界面設計 6 2 1設計問題1 系統(tǒng)響應時間 2 用戶幫助 3 出錯信息處理 4 命令交互 6 2 2設計過程6 2 3人機界面設計指南1 一般交互指南 2 信息顯示指南 3 數(shù)據(jù)輸入指南 6 3過程設計的工具 6 3 1程序流程圖 程序流程圖 是一種描述程序的控制結構流程和指令執(zhí)行情況的有向圖 歷史悠久 使用廣泛 直觀描繪控制流程 便于初學者掌握 ASP檢索程序流程圖 2 程序流程圖中用箭頭代表控制流 因此程序員不受任何約束 可以完全不顧結構程序設計的精神 隨意轉(zhuǎn)移控制 3 程序流程圖不易表示數(shù)據(jù)結構 程序流程圖的缺點 1 程序流程圖本質(zhì)上不是逐步求精的好工具 它誘使程序員過早地考慮程序的控制流程 而不去考慮程序的全局結構 6 3 2盒圖 N S圖 盒圖的特點有 1 功能域明確 可以從盒圖上一眼就看出來 2 不可能任意轉(zhuǎn)移控制 3 很容易確定局部和全程數(shù)據(jù)的作用域 4 很容易表現(xiàn)嵌套關系 也可以表示模塊的層次結構 盒圖例子 PAD ProblemAnalysisDiagram 是問題分析圖 日立公司發(fā)明和推廣 1973 6 3 3PAD圖 例子 PAD圖的優(yōu)點 1 使用表示結構化控制結構的PAD符號所設計出來的程序必然是結構化程序 2 PAD圖所描繪的程序結構十分清晰 圖中最左面的豎線是程序的主線 即第一層結構 隨著程序?qū)哟蔚脑黾?PAD圖逐漸向右延伸 每增加一個層次 圖形向右擴展一條豎線 PAD圖中豎線的總條數(shù)就是程序的層次數(shù) 3 用PAD圖表現(xiàn)程序 通俗易懂 程序從圖中最左豎線上端的結點開始執(zhí)行 自上而下 從左向右順序執(zhí)行 遍歷所有結點 4 容易將PAD圖轉(zhuǎn)換成高級語言源程序 這種轉(zhuǎn)換可以用軟件工具自動完成 5 可用于表示程序邏輯 也可用于描繪數(shù)據(jù)結構 6 PAD圖的符號支持自頂向下 逐步求精的方法 判定表由四部分組成 左上部列出所有條件左下部是所有可能做的動作右上部表示各種條件組合右下部是和每種條件組合相對應的動作 6 3 4判定表 6 3 5判定樹判定樹是判定表的變種 PDL也稱為偽碼 如 ifI 0then執(zhí)行訂單數(shù)據(jù)輸入模塊else報告出錯信息endif 6 3 6過程設計語言 PDL PDL的優(yōu)點 1 可以作為注釋直接插在源程序中間 2 可以使用普通的正文編輯程序或文字處理系統(tǒng)來完成PDL的書寫和編輯工作 3 現(xiàn)在已經(jīng)有一些自動處理程序可以自動地把PDL生成程序代碼 PDL的缺點 不如圖形工具形象直觀 6 4面向數(shù)據(jù)結構的設計方法 1 順序結構 6 4 1Jackson圖 2 選擇結構 3 重復結構 6 4 2改進的Jackson圖 Jackson方法的目標是 得出對程序處理過程的詳細描述 6 4 3Jackson方法 Jackson結構程序設計方法由五個步驟組成 1 分析并確定輸入數(shù)據(jù)和輸出數(shù)據(jù)的邏輯結構 并用Jackson圖描繪這些數(shù)據(jù)結構 2 找出輸入數(shù)據(jù)結構和輸出數(shù)據(jù)結構中有對應關系的數(shù)據(jù)單元 3 用三條規(guī)則從描繪數(shù)據(jù)結構的Jackson圖導出描繪程序結構的Jackson圖 A 為每對有對應關系的數(shù)據(jù)單元 按照它們在數(shù)據(jù)結構圖中的層次在程序結構圖的相應層次畫一個處理框 B 根據(jù)輸入數(shù)據(jù)結構中剩余的每個數(shù)據(jù)單元所處的層次 在程序結構圖的相應層次分別為它們畫上對應的處理框 C 根據(jù)輸出數(shù)據(jù)結構中剩余的每個數(shù)據(jù)單元所處的層次 在程序結構圖的相應層次分別為它們畫上對應的處理框 4 列出所有操作和條件 包括分支條件和循環(huán)結束條件 并且把它們分配到程序結構圖的適當位置 5 用偽碼表示程序 順序結構 AseqBCDAend 與三種基本結構對應的偽碼是 選擇結構Aselectcond1BAorcond2CAorcond3DAend 重復結構Aiteruntil 或while condBAend 例 一個正文文件由若干記錄組成 每個記錄是一個字符串 如 Record1 Howmanystagesarethereinthetraditionalsoftwaredevelopmentmodel Record2 Afterenteringtheroom walktothepersonsittingnearesttoyouandgreethim herwitha highfive Record3 Whatareencapsulatedintoanobject Record4 Whatdiagramisthefollowingdiagram Simplydescribethemeaningofit 要求 1 設計程序統(tǒng)計每個記錄中空格字符的個數(shù) 輸出數(shù)據(jù)的格式是 每讀入一個記錄 字符串 之后 另起一行打印出這個字符串及其空格數(shù) 2 最后打印出文件中空格的總個數(shù) 分析輸入 輸出數(shù)據(jù)結構 用Jackson圖描繪 并找出兩者對應的數(shù)據(jù)單元 導出描繪程序結構的Jackson圖 1 停止 2 打開文件 3 關閉文件 4 印出字符串 5 印出空格數(shù)目 6 印出空格總數(shù) 7 sum sum 1 8 totalsum totalsum sum 9 讀入字符串 10 sum 0 11 totalsum 0 12 pointer 1 13 pointer pointer 1I 1 文件結束I 2 字符串結束S 3 字符是空格 列出所有操作和條件 6 5程序復雜度的定量度量 定量度量程序復雜度的作用 1 可估算軟件中錯誤的數(shù)量及軟件開發(fā)工作量 2 度量的結果可用來比較不同設計或不同算法的優(yōu)劣 3 程序的復雜度可作為模塊規(guī)模的限度 1 流圖 退化 的程序流程圖 僅描繪程序的控制流程 不表現(xiàn)對數(shù)據(jù)的具體操作及循環(huán) 選擇的條件 6 5 1McCabe方法 一個圓代表一條或多條語句 一個順序結構可以合并成一個結點 匯點也是結點 一個順序處理框序列和一個判斷框可映射成一個結點 復合條件 包含了一個或多個布爾運算符 OR AND NOR等 應把復合條件分解為簡單條件 每個條件對應一個結點 2 計算環(huán)形復雜度的方法1 環(huán)形復雜度V G 等于流圖中的區(qū)域數(shù) 2 環(huán)形復雜度V G E N 2 其中E是流圖中邊的條數(shù) N是結點數(shù) 3 環(huán)形復雜度V G P 1 其中P為流圖中判定結點的數(shù)目 例 計算下列程序圖的程序復雜度 解 方法一 程序圖把平面分為4個區(qū)域 程序復雜度V G 4 方法二 邊的條數(shù)E 11 結點數(shù)N 9 程序復雜度V G E N 2 4 方法三 判定結點為1 2 4點 數(shù)目為P 3個 所以V G P 1 4 3 環(huán)形復雜度的用途對測試難度的一種定量度量 也能對軟件最終的可靠性給出某種預測 實踐表明 模塊規(guī)模以V G 10為宜 根據(jù)程序中運算符和操作數(shù)的總數(shù)來度量程序復雜度 N N1 N2其中 N定義為程序長度 N1為程序中運算符出現(xiàn)的總次數(shù) N2為操作數(shù)出現(xiàn)的總次數(shù) 6 5 2Halstead方法 Halstead給出預測程序長度的公式為 H n1log2n1 n2log2n2其中 H定義為程序預測長度 n1為程序中使用的不同運算符 包括關鍵字 的個數(shù) n2為程序中使用的不同操作數(shù) 變量和常量 的個數(shù) 多次驗證都表明 程序的預測長度H和實際程序長度N非常接近 Halstead還給出了預測程序中包含錯誤的個數(shù)的公式 E Nlog2 n1 n2 3000 第6章小結 詳細設計說明書著重描述每一模塊是怎樣實現(xiàn)的 包括實現(xiàn)算法 邏輯流程等 第7章 實現(xiàn) 編碼和測試統(tǒng)稱為實現(xiàn) 編碼 把軟件設計結果翻譯成程序 測試 檢測程序并改正錯誤的過程 計算機程序設計語言基本上可以分為兩大類 1 匯編語言 2 高級語言 7 1編碼 7 1 1選擇程序設計語言 從應用特點看 高級語言可分為 1 基礎語言如BASIC FORTRAN COBOL ALGOL等2 結構化語言如ALGOL PL 1 PASCAL C ADA等3 專用語言如APL BLISS FORTH LISP PROLOG等 選擇一種編程語言的理論標準 1 有理想的模塊化機制 2 可讀性好的控制結構和數(shù)據(jù)結構 3 便于調(diào)試和提高軟件可靠性 4 編譯程序發(fā)現(xiàn)程序錯誤的能力強 5 有良好的獨立編譯機制 選擇語言時除了考慮理論上的標準 還必須同時考慮主要的實用標準 1 系統(tǒng)用戶要求 2 可以使用的編譯程序 3 可以得到的軟件工具 4 工程規(guī)模 5 程序員知識 6 軟件可移植性要求 7 軟件的應用領域 1 程序內(nèi)部的文檔選取含義鮮明的名字 如果使用縮寫 縮寫規(guī)則要一致 并給每個名字加注釋 通常在每個模塊開始處要有一段注釋 描述模塊功能 算法 接口特點等 程序清單布局應利用適當?shù)碾A梯形式 使程序的層次結構清晰明顯 7 1 2寫程序的風格 2 數(shù)據(jù)說明數(shù)據(jù)說明的次序應該標準化 如按數(shù)據(jù)類型確定說明的次序 多個變量名在一個語句中說明時 應該按字母順序排列這些變量 如果設計時使用了復雜的數(shù)據(jù)結構 應該用注釋說明實現(xiàn)該數(shù)據(jù)結構的方法和特點 3 語句構造4 輸入 輸出5 效率A 程序運行時間B 存儲器效率C 輸入 輸出效率 程序設計工具實例 VisualC 運用VisualC 開發(fā)工具需要掌握 C 語言特點 語法 Windows編程基礎 MFC相關知識 VisualC 集成開發(fā)工具環(huán)境的使用 一 C 語言特點 語法 C 語言是在C語言的基礎是擴展而成的 兩種語言的基本語法和語義是相同 C 中加入了面向?qū)ο蟪绦蛟O計 OOP 的特征 封裝性 通過 類 把屬性和函數(shù)組合在一起 繼承性 派生類可從先前定義的基類中繼承函數(shù)和屬性 多態(tài)性 一個函數(shù)名 由不同的對象解釋執(zhí)行 可得到不同的執(zhí)行效果 二 Windows編程基礎 API API是Windows應用程序編程接口 API是一個程序內(nèi) 或一組相關程序內(nèi) 的一組函數(shù)調(diào)用 程序員用它創(chuàng)建其他程序 程序員不必知道函數(shù)內(nèi)部 只要知道API的函數(shù)原型及返回值 API的函數(shù)原型及返回值形式可由相關的技術規(guī)范資料獲得 現(xiàn)在的Win32API中 核心部分依靠三個主要組件提供Windows的大部分函數(shù) 這三個組件分別是 USER32 DLL GDI32 DLL KERNEL32 DLL Windows消息機制 1 基于消息的事件驅(qū)動消息可以是由硬件發(fā)來的 存于系統(tǒng)隊列 也可以由Windows系統(tǒng)和應用程序發(fā)來 存于程序隊列中 每一個Windows程序在不停的捕捉各種消息 并進行處理 每個窗口都必須有一個窗口函數(shù) 來負責消息的判斷與處理 2 窗口函數(shù)對消息的處理窗口函數(shù)是一個回調(diào)函數(shù) 可以處理收到的消息 在程序中不需要用戶顯式調(diào)用 該窗口函數(shù)的形式通常為 WndProc 每個窗口類必須在初始化時指定一個窗口函數(shù) 三 MFC MFC 即Microsoft基本類 該類庫封裝了SDK 軟件開發(fā)工具包 結構 功能及應用程序框架內(nèi)部技術 它提供了許多可以重用的類 使得Windows程序員避免了許多重復性工作 四 VisualC 集成開發(fā)工具環(huán)境1 開發(fā)工具的使用 2 掌握Win32程序開發(fā)流程 一個win32程序由兩大塊組成 程序代碼 用戶接口資源 用戶接口資源 菜單 對話框 圖標 光標等 這些資源的實際內(nèi)容 二進制代碼 由各種工具產(chǎn)生 并以各種擴展名的文件存在 資源描述文件 rc 中對用戶接口資源進行描述 RC編輯器 RC exe 根據(jù)該資源描述文件 rc 將所有用戶接口資源集中構造一個 RES文件 RES文件與程序代碼結合起來 構成一個Win