【正文】 下一頁 計(jì)算機(jī)軟件基礎(chǔ) The software basic of puter 主講人：劉志強(qiáng) 第 16單元 傳統(tǒng)程序設(shè)計(jì)方法 下一頁 上一頁 停止放映 第 2 頁 教學(xué)目標(biāo) ?了解傳統(tǒng)程序設(shè)計(jì)方法 : – 基本概念 – 方法及特點(diǎn) – 步驟及準(zhǔn)則 下一頁 上一頁 停止放映 第 3 頁 本單元涉及內(nèi)容 ? 第十章 傳統(tǒng)的軟件開發(fā)方法 – 結(jié)構(gòu)化開發(fā)方法概述 – 系統(tǒng)分析與定義 – 系統(tǒng)設(shè)計(jì) – 系統(tǒng)編程 – 系統(tǒng)測(cè)試 – 系統(tǒng)維護(hù) ? P273~P333 下一頁 上一頁 停止放映 第 4 頁 一 、結(jié)構(gòu)化開發(fā)方法 ? 結(jié)構(gòu)化開發(fā)方法是傳統(tǒng)的軟件系統(tǒng)開發(fā)方法 。 ? 基本要點(diǎn)是： – 自頂向下 – 逐步求精 – 模塊化設(shè)計(jì) – 結(jié)構(gòu)化編碼 – 主程序員組織 – 結(jié)構(gòu)化設(shè)計(jì) SD ? SP的基本思想： 把一個(gè)復(fù)雜問題的求解過程分階段進(jìn)行 ， 每個(gè)階段處理的問題都控制在人們?nèi)菀桌斫夂吞幚淼姆秶鷥?nèi) 。 下一頁 上一頁 停止放映 第 5 頁 “自頂向下” ? 是將復(fù)雜的大問題 ， 分解為小問題 ， 找出問題的關(guān)鍵 、 重點(diǎn)所在 ， 同時(shí)找出技術(shù)難點(diǎn)來 。然后用精確的思維定性 、 定量地描述問題 。 ? 問題的核心是 ” 分解 “ 。 如何劃分 ？ 準(zhǔn)則是什么 ？ ? 實(shí)現(xiàn)的手段是 ” 子程序 “ 、 ” 函數(shù) “ ， 即模塊化 。 下一頁 上一頁 停止放映 第 6 頁 “逐步求精” ? 將現(xiàn)實(shí)世界的問題經(jīng)抽象轉(zhuǎn)化為邏輯空間或求解空間的問題 。 復(fù)雜問題經(jīng)抽象化處理變?yōu)橄鄬?duì)較簡(jiǎn)單的問題 。 經(jīng)幾次抽象 （ 精化 ） 處理 ，最后到求解域中只是非常簡(jiǎn)單的編程問題 。 求解 （ 抽象 ） 過程可以劃分為若干個(gè)階段 ， 在不同階段用不同工具來描述 。 實(shí)現(xiàn)細(xì)則在前期階段可以不去管它 。 在每個(gè)階段有不同的規(guī)劃和標(biāo)準(zhǔn) ， 產(chǎn)生出不同階段的文檔資料 。 ? 求解問題不是一下子就用計(jì)算機(jī)語言卻描述問題 ， 而是分階段；先用自然語言 、 DFD（ 數(shù)據(jù)流程圖 ） 等工具一步步地去抽象 、 描述 ， 最后用計(jì)算機(jī)語言卻實(shí)現(xiàn) 。 下一頁 上一頁 停止放映 第 7 頁 模塊化處理 ? 模塊化就是把程序劃分為若干個(gè)模塊 ， 而每個(gè)模塊完成一個(gè)子功能 ， 把這些模塊匯總起來構(gòu)成一個(gè)有機(jī)整體 ， 即可完成指定的功能 。 ? 模塊化的目的是為了降低軟件復(fù)雜度 ， 使軟件設(shè)計(jì) ， 調(diào)試和維護(hù)等操作變得簡(jiǎn)易 。 下一頁 上一頁 停止放映 第 8 頁 結(jié)構(gòu)化編碼 ? SP編碼的方法強(qiáng)調(diào) 清晰簡(jiǎn)潔 ， 它是一種構(gòu)造程序的技術(shù) ， 有利于提高軟件生產(chǎn)率及降低軟件維護(hù)代價(jià) 。 ? 1966年 Bohm和 Jacopin就證明了只要用三中基本結(jié)構(gòu) ， 就足以表示所有形式的程序控制結(jié)構(gòu) 。 ? 1978年 Kernihan和 Plauger對(duì)一些編碼風(fēng)格進(jìn)行歸納 ， 提出了 16種具體方法 。 下一頁 上一頁 停止放映 第 9 頁 結(jié)構(gòu)化編碼風(fēng)格 ? 盡量使用標(biāo)準(zhǔn)庫函數(shù) ? 程序講究清晰 ， 避免過于精巧 ? 對(duì)重復(fù)使用的表達(dá)式盡量調(diào)用公共函數(shù)代替 ? 使用括號(hào) ， 以避免二義性 ? 用邏輯表達(dá)式代替分支嵌套 ? 使用縮排格式 ? 避免使用 IF THEN 和空 ELSE ? 注意計(jì)算機(jī)運(yùn)算特點(diǎn) ， 如 ? 使用有意義的變量名 ? 對(duì)輸入進(jìn)行錯(cuò)誤判別 ? 注釋勿用太濫 ? 模塊化功能專一 ,模塊間偶合清晰 ? 遞歸定義的 DS盡量采用遞歸過程訪問 ? 把大程序分成小塊去編寫和測(cè)試 ? 勿追求不必要的效率 ,盡量采用基本控制結(jié)構(gòu) ? 避免循環(huán)多個(gè)出口 下一頁 上一頁 停止放映 第 10 頁 主程序員組織 ? 主程序員 組織負(fù)責(zé)人 ,全權(quán)負(fù)責(zé) ,包括解決技術(shù)難題 ,有時(shí)一些關(guān)鍵性技術(shù)問題 ,主程序員應(yīng)親自動(dòng)手遍程去解決；他必須是技術(shù)高手 ， 是程序生產(chǎn)過程中的總體設(shè)計(jì)師 。 ? 程序員 按任務(wù)書要求編程；是程序生產(chǎn)線上的 “ 工人 ” 。 ? 測(cè)試工程師 具有較高遍程水準(zhǔn)和經(jīng)驗(yàn) ， 負(fù)責(zé)系統(tǒng)測(cè)試；是程序生產(chǎn)過程中的檢驗(yàn)員 。 ? 文檔人員 自始至終參加程序生產(chǎn)活動(dòng) ， 負(fù)責(zé)編寫一切有關(guān)文檔資料 。 下一頁 上一頁 停止放映 第 11 頁 結(jié)構(gòu)化方法的體系結(jié)構(gòu) ? 結(jié)構(gòu)化方法的體系結(jié)構(gòu)是 : – 結(jié)構(gòu)化分析（ SA— Structure Analysis） – 結(jié)構(gòu)化設(shè)計(jì)（ SD— Structure Design） – 結(jié)構(gòu)化程序設(shè)計(jì)（ SP— Structure Programing） 下一頁 上一頁 停止放映 第 12 頁 結(jié)構(gòu)化分析 SA ? SA方法是建立在自頂向下 、 逐步求精思想基礎(chǔ)上的分析方法 ， 它的要點(diǎn)是 分解和抽象： – 把復(fù)雜問題自頂向下逐層分解 ， 再從分解出的對(duì)象中抽象出相對(duì)簡(jiǎn)單的子問題 。 – 經(jīng)過一系列分解和抽象 ， 到最底層的問題已經(jīng)是很容易求解的了 。 下一頁 上一頁 停止放映 第 13 頁 結(jié)構(gòu)化設(shè)計(jì) SD ? SD方法是由 IBM公司的 Constentine等人花了十幾年時(shí)間研究出來的一種程序設(shè)計(jì)方法 ， 發(fā)表于 1974年 。 ? SD是一種用于概要設(shè)計(jì)的方法 ， 與 SA方法配合使用 。 ? 其目標(biāo)：建立一個(gè)結(jié)構(gòu)良好的軟件系統(tǒng) 。 ? SD方法的基礎(chǔ)是數(shù)據(jù)流程圖 ， 因此也稱為面向數(shù)據(jù)流的設(shè)計(jì)方法 。 下一頁 上一頁 停止放映 第 14 頁 結(jié)構(gòu)化程序設(shè)計(jì) SP ? SP的思想最早是由著名計(jì)算機(jī)科學(xué)家 出的 。 ? 1966年 Bohm和 Jacopin證明了只用三種基本結(jié)構(gòu)就能實(shí)現(xiàn)任何一個(gè)入口 ， 一個(gè)出口的程序； ? 1977年 IBM公司的 Mills又進(jìn)一步提出： “ 程序應(yīng)該只有一個(gè)入口和一個(gè)出口 。 ? 在長(zhǎng)期程序設(shè)計(jì)的實(shí)踐中 ， SP方法不斷得以完善 ， 使之成為開發(fā)傳統(tǒng)應(yīng)用領(lǐng)域應(yīng)用系統(tǒng)的主要方法之一 。 下一頁 上一頁 停止放映 第 15 頁 關(guān)于 SP的定義 ? 北大王選院士認(rèn)為： – 沒有 GOTO語句 – 一個(gè)入口、一個(gè)出口 – 自頂向下，逐步求精的分解 – 主程序員組 ? 潭浩強(qiáng)認(rèn)為： – 自頂向下 – 逐步求精 – 模塊化設(shè)計(jì) – 結(jié)構(gòu)化編碼 下一頁 上一頁 停止放映 第 16 頁 關(guān)于 SP的定義（續(xù)） ? 另一種說法： – 自頂向下 ， 逐步求精 – 程序結(jié)構(gòu)按功能劃分為模塊 – 模塊功能單一 、 簡(jiǎn)單 – 模塊由三種基本結(jié)構(gòu)組成 – 程序由函數(shù) 、 子程序來實(shí)現(xiàn) 下一頁 上一頁 停止放映 第 17 頁 二、軟件需求定義 ? 軟件需求分析 就是明確軟件系統(tǒng)將來達(dá)到的目標(biāo)。換句話說，它的基本任務(wù)是準(zhǔn)確地回答系統(tǒng)“ 做什么 ？”這個(gè)問題。 ? 目標(biāo) 它要規(guī)定項(xiàng)目必須滿足的總目標(biāo)；確定項(xiàng)目的可行性；擬定完成項(xiàng)目各個(gè)目標(biāo)的策略，制定項(xiàng)目資源成本和進(jìn)度。 下一頁 上一頁 停止放映 第 18 頁 軟件需求定義的任務(wù) ? 理解和表達(dá)用戶要求，制定軟件開發(fā)計(jì)劃，編寫要求說明書。 ? 收集、理解、明確用戶的要求，明確系統(tǒng)做什么？建立系統(tǒng)的邏輯模型，寫出開發(fā)計(jì)劃和需求分析報(bào)告。 下一頁 上一頁 停止放映 第 19 頁 軟件需求定義的特點(diǎn) ? 它是軟件生存周期中最容易出錯(cuò)的一個(gè)階段，也是軟件工程中最困難的一個(gè)階段。困難在于： – 不能準(zhǔn)確地理解和清楚地描述 – 軟件系統(tǒng)非常復(fù)雜，以致用戶和軟件人員都不能完整、精確地理解它或不能清楚地表達(dá)出來；軟件人員和用戶缺乏共同語言。 – 用戶熟悉業(yè)務(wù)，但不了解計(jì)算機(jī)；而軟件人員則相反；這種隔閡使雙方不能進(jìn)行交流。 ? 這一階段與其它階段很不相同，它是其它階段的基礎(chǔ)，十分重要。一旦需求定義出現(xiàn)錯(cuò)誤，將導(dǎo)致整個(gè)軟件開發(fā)的失敗。而這一階段是面向用戶問題的，而不是面向軟件求解的。 下一頁 上一頁 停止放映 第 20 頁 確定對(duì)系統(tǒng)的綜合要求 ? 系統(tǒng)功能要求 找出系統(tǒng)必須完成的所有功能。 ? 系統(tǒng)性能要求 例如，聯(lián)機(jī)系統(tǒng)的響應(yīng)時(shí)間，系統(tǒng)需要的存儲(chǔ)容量以及后援存儲(chǔ)，重新啟動(dòng)和安全性等問題。 ? 運(yùn)行要求 對(duì)系統(tǒng)運(yùn)行環(huán)境的要求。例如，什么樣的硬件環(huán)境？采用哪種 DBMS？ OS平臺(tái)是什么？需要什么樣的外存儲(chǔ)器和數(shù)據(jù)通信接口等。 ? 將來可能提出的要求 為系統(tǒng)將來可能的擴(kuò)充和修改預(yù)做準(zhǔn)備。 下一頁 上一頁 停止放映 第 21 頁 軟件需求定義的工作流程 系統(tǒng)定義 用戶要求 軟件功能 范圍 功能說明書 軟件計(jì)劃 軟件定義 軟件功能 費(fèi)用、資源進(jìn)度 下一頁 上一頁 停止放映 第 22 頁 需求分析過程 ? 基本過程示意圖 ? 沿?cái)?shù)據(jù)流回溯 ? 用戶復(fù)查 ? 細(xì)化數(shù)據(jù)流圖 ? 修改開發(fā)計(jì)劃 ? 書寫文檔資料 ? 審查和復(fù)審 下一頁 上一頁 停止放映 第 23 頁 需求分析的基本過程 用戶 分析員 程序員 軟件開發(fā)計(jì)劃 軟件需求說明書 分析追蹤 數(shù)據(jù)流圖 用戶復(fù)查 細(xì)化數(shù)據(jù) 流圖 無補(bǔ)充 修改 需要分解 不要分解 有補(bǔ)充修改 交換意見 作出貢獻(xiàn) 下一頁 上一頁 停止放映 第 24 頁 沿?cái)?shù)據(jù)流回溯 ? 通常從數(shù)據(jù)流圖的輸出端著手分析，要搞清楚： – 數(shù)據(jù)元素從哪兒來？ – 每個(gè)輸出數(shù)據(jù)元素又是從哪兒來的？ 有時(shí)對(duì)用戶具體的數(shù)據(jù)元素還搞不清楚，則需要和用戶探討、商量解決。 ? 通常把分析過程中得到的有關(guān)部門數(shù)據(jù)元素信息記錄到數(shù)據(jù)字典 DD中。把對(duì)算法的簡(jiǎn)明描述記錄在IPO（輸入 |處理 |輸出圖）圖中。 ? 通過分析而補(bǔ)充的數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)和處理，應(yīng)該添加到 DFD的適當(dāng)位置上。 下一頁 上一頁 停止放映 第 25 頁 用戶復(fù)查 ? 經(jīng)分析將在數(shù)據(jù)流圖回溯過程中找出的數(shù)據(jù)元素，并由此定義的 DD和算法是否正確？這只能由最有發(fā)言權(quán)的用戶來復(fù)查。 ? 在復(fù)查過程中反映出新的問題，應(yīng)及時(shí)修改、補(bǔ)充 DFD、 DD和 IPO圖，并將對(duì)系統(tǒng)的新認(rèn)識(shí)及時(shí)記錄下來。實(shí)際上，追蹤 DFD和復(fù)查系統(tǒng)的邏輯模型這兩個(gè)步驟是交替進(jìn)行的循環(huán)過程。 下一頁 上一頁 停止放映 第 26 頁 細(xì)化數(shù)據(jù)流圖 ? 在反復(fù)循環(huán)的分析過程中，不斷細(xì)化DFD（即把數(shù)據(jù)流圖擴(kuò)展到更低的層次）。通過功能分解可以完成 DFD的細(xì)化，即將一些處理比較復(fù)雜的功能再劃分為若干個(gè)子功能。 下一頁 上一頁 停止放映 第 27 頁 修改開發(fā)計(jì)劃 ? 在分析過程中可能會(huì)不斷地修改原擬定的開發(fā)計(jì)劃，這是正常的。 下一頁 上一頁 停止放映 第 28 頁 書寫文檔資料 ? 在軟件生命周期的各個(gè)階段，作為階段成果的組成部分 ——文檔資料，其作用如何強(qiáng)調(diào)都不過份。本階段應(yīng)完成 4份文檔資料： –系統(tǒng)規(guī)格說明 描述目標(biāo)系統(tǒng)的概貌、功能要求、性能、運(yùn)行及將來可能提出的要求。 –用戶系統(tǒng)描述 從用戶角度描述系統(tǒng)，類似一份用戶手冊(cè)初稿。 –數(shù)據(jù)要求 包括 DD、數(shù)據(jù)結(jié)構(gòu)的層次框圖等。 –修改的開發(fā)計(jì)劃 包括成本估計(jì)、進(jìn)度計(jì)劃表、資源使用計(jì)劃等。 下一頁 上一頁 停止放映 第 29 頁 說明 ? 需求說明書主要內(nèi)容： – 概述 開發(fā)系統(tǒng)的意義、目的、背景及技術(shù)術(shù)語； – 現(xiàn)性系統(tǒng)的概況 業(yè)務(wù)流程、范圍、存在的問題等； – 需求說明 ? 功能描述 ? 信息描述： DFD、 DD、 DS、 IPO、接口等 ? 性能描述 – 運(yùn)行環(huán)境 – 系統(tǒng)限制 ? 用戶系統(tǒng)描述 – 系統(tǒng)功能和性能的描述 – 使用系統(tǒng)的主要步驟和方法 – 系統(tǒng)用戶的責(zé)任等 下一頁 上一頁 停止放映 第 30 頁 審查和復(fù)審 ? 分析階段最后一步是按結(jié)束標(biāo)準(zhǔn)對(duì)該階段的工作成果進(jìn)行正式的技術(shù)審查和管理審查。 下一頁 上一頁 停止放映 第 31 頁 需求分析的原則 ? 1． 能夠表達(dá)和理解問題的信息域 信息域反映的是用戶業(yè)務(wù)系統(tǒng)中數(shù)據(jù)的流向和對(duì)數(shù)據(jù)進(jìn)行加工的處理過程 ， 因此信息域是解決 “ 做什么 ？ ” 的關(guān)鍵因素 。 2． 要建立描述系統(tǒng)信息 、 功能和行為的模型 建立模型的過程是 “ 由粗到精 ” 的分析綜合的過程 。 3． 能夠?qū)λＰ桶匆欢ㄐ问竭M(jìn)行分解 分解是為了降低問