【正文】 括：系統(tǒng)的模塊劃分 、 每個模塊的功能簡介 、 各個模塊之間的邏輯關系； – DS及 DB設計 用圖表把設計結果描述出來； – 接口設計 包括：人機界面設計 、 軟 、 硬件之間的接口設計 、 本系統(tǒng)與外界以及與支持軟件之間的接口關系； – 模塊設計 根據模塊的功能 ， 用相應的工具描述每個模塊的流程 ， 以及每個模塊用到的數據結構 。 對物理模型進行分析 ， 區(qū)別本質因素和非本質因素 ， 去掉非本質因素 ， 就成為邏輯模型 （ 本質因素是固有的 ， 不依賴于環(huán)境變化而變化的因素 ） 。用 Shell語言開發(fā)適于用該種語言書寫的程序時，所需的成本比用普通 PL開發(fā)時低得多。 下一頁 上一頁 停止放映 第 44 頁 超高級語言和第 4代語言 ? 超高級語言的語句功能很強，用少數語句就可以實現一個系統(tǒng)。軟件工具應滿足下列要求： –必須有形式化的語法（可讓計算機自動處理） –能夠導出詳細的文檔 –必須提供分析（測試）規(guī)格說明書的不一致性和冗余性的手段，并能產生指明對完整性分析結果的報告。 ? 例如， DO CASE CASE 時間 =12 R_rent=0。把一個復雜的問題，分解為一些相互獨立的子問題，再繪出分層DFD。 4． 分清系統(tǒng)的邏輯視圖和物理視圖 – 軟件需求的邏輯視圖描述的是系統(tǒng)要達到的功能和要處理的信息之間的關系 ， 這與實現細節(jié)無關； – 而物理視圖描述的是處理功能和信息結構的實際表現形式 ，這與實現細節(jié)是有關的 – 需求分析只研究軟件系統(tǒng) “ 做什么 ？ ” ， 而不考慮 “ 怎樣做 ？ ” 。本階段應完成 4份文檔資料： –系統(tǒng)規(guī)格說明 描述目標系統(tǒng)的概貌、功能要求、性能、運行及將來可能提出的要求。 ? 通過分析而補充的數據流、數據存儲和處理，應該添加到 DFD的適當位置上。 下一頁 上一頁 停止放映 第 20 頁 確定對系統(tǒng)的綜合要求 ? 系統(tǒng)功能要求 找出系統(tǒng)必須完成的所有功能。 下一頁 上一頁 停止放映 第 18 頁 軟件需求定義的任務 ? 理解和表達用戶要求，制定軟件開發(fā)計劃，編寫要求說明書。 ? 其目標：建立一個結構良好的軟件系統(tǒng) 。 下一頁 上一頁 停止放映 第 9 頁 結構化編碼風格 ? 盡量使用標準庫函數 ? 程序講究清晰 ， 避免過于精巧 ? 對重復使用的表達式盡量調用公共函數代替 ? 使用括號 ， 以避免二義性 ? 用邏輯表達式代替分支嵌套 ? 使用縮排格式 ? 避免使用 IF THEN 和空 ELSE ? 注意計算機運算特點 ， 如 ? 使用有意義的變量名 ? 對輸入進行錯誤判別 ? 注釋勿用太濫 ? 模塊化功能專一 ,模塊間偶合清晰 ? 遞歸定義的 DS盡量采用遞歸過程訪問 ? 把大程序分成小塊去編寫和測試 ? 勿追求不必要的效率 ,盡量采用基本控制結構 ? 避免循環(huán)多個出口 下一頁 上一頁 停止放映 第 10 頁 主程序員組織 ? 主程序員 組織負責人 ,全權負責 ,包括解決技術難題 ,有時一些關鍵性技術問題 ,主程序員應親自動手遍程去解決；他必須是技術高手 ， 是程序生產過程中的總體設計師 。 實現細則在前期階段可以不去管它 。 下一頁 上一頁 停止放映 第 5 頁 “自頂向下” ? 是將復雜的大問題 ， 分解為小問題 ， 找出問題的關鍵 、 重點所在 ， 同時找出技術難點來 。 如何劃分 ？ 準則是什么 ？ ? 實現的手段是 ” 子程序 “ 、 ” 函數 “ ， 即模塊化 。 下一頁 上一頁 停止放映 第 7 頁 模塊化處理 ? 模塊化就是把程序劃分為若干個模塊 ， 而每個模塊完成一個子功能 ， 把這些模塊匯總起來構成一個有機整體 ， 即可完成指定的功能 。 ? 文檔人員 自始至終參加程序生產活動 ， 負責編寫一切有關文檔資料 。 ? 1966年 Bohm和 Jacopin證明了只用三種基本結構就能實現任何一個入口 ， 一個出口的程序； ? 1977年 IBM公司的 Mills又進一步提出： “ 程序應該只有一個入口和一個出口 。困難在于： – 不能準確地理解和清楚地描述 – 軟件系統(tǒng)非常復雜，以致用戶和軟件人員都不能完整、精確地理解它或不能清楚地表達出來；軟件人員和用戶缺乏共同語言。例如，什么樣的硬件環(huán)境？采用哪種 DBMS？ OS平臺是什么？需要什么樣的外存儲器和數據通信接口等。實際上，追蹤 DFD和復查系統(tǒng)的邏輯模型這兩個步驟是交替進行的循環(huán)過程。 –修改的開發(fā)計劃 包括成本估計、進度計劃表、資源使用計劃等。 下一頁 上一頁 停止放映 第 33 頁 數據流圖 DFD ? 數據流圖（ DFD——Data Flow Diagram ）以圖形的方式表達數據處理系統(tǒng)中信息的變換和傳遞過程。 ? 數據字典的條目解釋通常采用規(guī)范的定義形式： 客帳 =帳號 +房租 +IDD費 +餐飲費 +洗衣費 +娛樂費 +日期 +經辦人 ? 內容 數據流：編號、名稱、簡述、別名、構成、來源、去向、流量 數據項目：編號、名稱、簡述、別名、類型、長度、位數 數據文件：編號、名稱、簡述、別名、構成、關鍵字、存取要求 ? 處理 編號、名稱、簡述、別名、處理條件、 I/O內容、處理邏輯 下一頁 上一頁 停止放映 第 38 頁 編寫 DD的要求 ? 一致性、無冗余 ? 與 DFD相互引用 ? DD的建立和維護是件細致而又復雜的工作。 下一頁 上一頁 停止放映 第 40 頁 判定表 ? 采用判定樹能把加工邏輯表示的更加清楚。 ? PSL/PSA 問題陳述語言 /問題陳述分析程序系統(tǒng)。它非常簡潔，用它書寫程序所化時間很少。但它表達算法類知識的能力較弱，不善于解決計算問題；效率較低。 下一頁 上一頁 停止放映 第 47 頁 SA的基本特點：分析與抽象 ? 采用用戶容易理解的圖形工具 ? 從全局認識系統(tǒng) ,采用自頂向下 ,逐級分析的方式 銷售 MIS 銷售 MIS 經營 庫存 財務 1） 2） 3） 銷售 MIS 經營 庫存 財務 市場分析 統(tǒng)計分析 客戶檔案 盤點結存 訂貨管理 工資核算 采購計劃 工資核算 成本核算 面向用戶 ,強調邏輯而非實現 (在該階段 ,不考慮系統(tǒng)的實現問題 ) 以獲取分離數據和加工為動機 (這點很重要 )。 ? 要想得到一個滿意的設計結果 ， 不光要有基本設計原則的指導 ， 還要有系統(tǒng)化的設計方法和科學嚴格的評審機制相結合才能達到預想的目的 。 下一頁 上一頁 停止放映 第 58 頁 結構形態(tài)準則示意圖 深度 寬度 扇出 扇入 下一頁 上一頁 停止放映 第 59 頁 控制、影響范圍示意圖 ? B模塊的控制范圍是 B、 D、 E、 F、 G、 H； ? 假設 E中有一個判別條件 ， 受其影響的模塊有 F、 G、H， 則 E的影響范圍是 F、G、 H。具有獨立性的模塊，開發(fā)容易、能減少錯誤的傳播，使模塊重組、分解方便，容易調試和維護。 如果是動態(tài)并發(fā)程序 ， 情況就更復雜了 。 下一頁 上一頁 停止放映 第 67 頁 內聚性分類： ? 共存內聚 幾個無關的任務組合在一起 ? 邏輯內聚 將幾個邏輯上相關的任務組合在一起 ? 時態(tài) （ 時間 ） 內聚 將在某一時刻同時要執(zhí)行的 任務組合在一起 ? 過程內聚 指幾個相關聯(lián)的任務組合在一起 ? 通訊內聚 指在同一 DS上進行操作的幾個任務 組合在一起 ? 順序內聚 指模塊的幾個任務總是前者的輸出即為 后者的輸入 ， 表現出按一定順序執(zhí)行 。 ?當事物流中的 事物流到事物 中心后，事物 中心分析每個 事物，確定其 類型；并根據 事物類型選擇 一個事物路徑 繼續(xù)進行處理。由此可見 ， 這是一個典型的變換流類型 。 – 轉換模塊的設計無規(guī)律性，一般可根據中心加工的子加工來建立模塊。 下一頁 上一頁 停止放映 第 93 頁 SP中的優(yōu)點 ? 自頂向下 ， 逐步求精方法符合人們解決復雜問題的普遍規(guī)律；抽象 、 分解 、 找出關鍵問題所在 。 下一頁 上一頁 停止放映 第 94 頁 SP中的缺點 ? SP方法是面向過程的設計方法 ， 它的出發(fā)點是 “ 怎樣做 ？ ” 。 程序員在編程時必須隨時考慮要處理的數據的格式： – 不同格式的數據 ， 即使做相同的處理 ， 也要編寫不同的代碼； – 數據格式一樣 ， 但處理不同 ， 也要用不同的代碼； – 相容性問題 。 ? 初始化 變量在沒使用前是何種狀態(tài) （ 值 ） ， 在不同語言中是不確定的 。 – 有些語言做了相應的處理 ， 例如 ， C中增加了 default語句 。 ? 選擇語言時 ， 不僅要考慮理論上的標準 ， 還必須同時考慮使用方面的各種限制 。 下一頁 上一頁 停止放映 第 102 頁 選擇語言的重要實用標準（二） ? 軟件的應用領域 選擇語言時應充分考慮目標系統(tǒng)的應用范圍： FORTRAN 科學計算首選語言 COBOL 適合于商業(yè)應用 C和 Ada 適合于系統(tǒng)和實時應用 LISP 適合于組合問題的應用 PROLOG 適合于表達知識和推理應用 下一頁 上一頁 停止放映 第 103 頁 寫程序的風格 ? 指程序員在編程時所表現出來的特點 、 邏輯思路 、 結構等 。 下一頁 上一頁 停止放映 第 107 頁 輸入 /輸出 ? 在編碼時要考慮下列 I/O風格的規(guī)則： – 對所有的輸入數據進行檢驗 – 檢查重要的輸入項組合的合法性 – 保持輸入格式的簡單 – 使用數據結束標記 ， 不要要求用戶指定數據的數目 – 明確提示交互式輸入的請求 ， 詳細說明可用的選擇或邊界數值； – 當程序設計語言對格式有嚴格要求時 ， 保持輸入格式一致 – 設計良好的輸出報表 – 給所有的輸出加標志 下一頁 上一頁 停止放映 第 108 頁 提高程序質量的技巧 ? 《 編程風格要點 》一書中討論了提高程序質量的種種技巧： – 避免使用過于相似的變量名 – 變量名中盡量不含數字 – 同一變量名不要具有多種意義 – 顯式說明所有變量 – 注意浮點運算的誤差 – 注意整數運算的特點 – 避免不必要的 GOTO語句 – 盡量少用語句標號 下一頁 上一頁 停止放映 第 109 頁 效率 ? 程序運行時間 源程序的效率由算法的效率決定 ， 但寫程序的風格也能對程序的執(zhí)行速度和存儲器要求產生影響 ， 可應用下述規(guī)則： – 寫程序前先簡化算術和邏輯表達式 – 盡量避免使用多維數組 ， 盡量避免使用指針和復雜的表 – 使用時間短的算術運算 – 不要混合使用不同的數據類型 – 盡量使用整數運算和布爾表達式 ? 存儲器效率 提高存儲器效率的關鍵是 “ 簡單 ” ? I/O效率 簡單清晰是提高人 機通信效率的關鍵 ， 應采用： – 所有 I/O都應該有緩沖 ， 以減少用于通信的額外開銷 – 對二級存儲器 （ 磁盤 ） 應選用最簡單的訪問方法 – 二級存儲器的 I/O應該以信息組為單位進行 。 ? 結論 由于測試目標是為了找出程序中的錯誤 ， 因此 ， 由程序設計者本人進行測試是不明智的 。 4）應該長期保留所有的測試用例，直到該系統(tǒng)被廢棄不用為止。 if(a=2||x＞ 1） ｘ＝ｘ＋１； ｝ 結束 程序邏輯結構圖 開始 a1amp。 下一頁 上一頁 停止放映 第 121 頁 邏輯覆蓋分析 ——條件覆蓋 ? 使判別中每個條件可能的值至少出現一次，及條件表達式中各個條件取兩個不同的值。 下一頁 上一頁 停止放映 第 123 頁 邏輯覆蓋分析 ——判別組合覆蓋 ? 使每個判定中的條件的各種組合都出現一次。 ? 劃分等價類需要經驗，以下是一些啟發(fā)性原則： – 若輸入條件規(guī)定了輸入值的范圍，則可能劃分一個有效的等價類和兩個無效的等價類（小于 MIN或大于 MAX）； – 如果規(guī)定輸入數據必須遵循的規(guī)則，則可劃分出一個有效的等價類（符合規(guī)則）和若干個無效的等價類（不符合規(guī)則）。 下一頁 上一頁 停止放映 第 127 頁 測試實施方法