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