chap4-程序開發(fā)和軟件工程_第1頁
chap4-程序開發(fā)和軟件工程_第2頁
chap4-程序開發(fā)和軟件工程_第3頁
chap4-程序開發(fā)和軟件工程_第4頁
chap4-程序開發(fā)和軟件工程_第5頁
已閱讀5頁,還剩50頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、第四章第四章 程序開發(fā)與軟件工程程序開發(fā)與軟件工程l 程序開發(fā)的過程程序開發(fā)的過程l“軟件危機軟件危機”l 軟件工程概念軟件工程概念l 本章將介紹軟件工程的基本思想和本章將介紹軟件工程的基本思想和 方法方法軟件危機軟件危機l硬件生產(chǎn)率大幅提高;軟件規(guī)模越來越大;硬件生產(chǎn)率大幅提高;軟件規(guī)模越來越大;軟件生產(chǎn)率很低;硬、軟件供需失衡軟件生產(chǎn)率很低;硬、軟件供需失衡l軟件危機的具體體現(xiàn)軟件危機的具體體現(xiàn) 軟件開發(fā)進度難以預測 軟件開發(fā)成本難以控制 用戶對產(chǎn)品功能難以滿足 軟件產(chǎn)品質量無法保證 軟件缺少適當?shù)奈臋n資料 軟件危機軟件危機(續(xù))(續(xù))l 最典型失敗系統(tǒng)的例子最典型失敗系統(tǒng)的例子 IBM公

2、司開發(fā)OS/360系統(tǒng),共有4000多個模塊,約100萬條指令,投入5000人年,耗資數(shù)億美元,結果還是延期交付。在交付使用后的系統(tǒng)中仍發(fā)現(xiàn)大量(2000個以上)的錯誤 軟件危機軟件危機(續(xù))(續(xù))l軟件危機是指在計算機軟件的開發(fā)和維軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。為護過程中所遇到的一系列嚴重問題。為了研究、解決軟件危機,誕生了一門新了研究、解決軟件危機,誕生了一門新興學科興學科軟件工程學軟件工程學。它把軟件作為。它把軟件作為工程對象,從技術措施和組織管理兩個工程對象,從技術措施和組織管理兩個方面來研究、解決軟件危機方面來研究、解決軟件危機 4.1 4.1 程

3、序設計過程程序設計過程l 程序設計程序設計(Programming)(Programming)需求分析需求分析程序設計程序設計編碼編碼測試與排錯測試與排錯一一 需求分析需求分析l 程序的程序的形式形式是程序語言描述的程序正文是程序語言描述的程序正文l 程序的程序的內(nèi)容內(nèi)容就是對需要解決的問題的描述就是對需要解決的問題的描述l 建模建模是計算機解題中的難點,也是計算機解題成敗是計算機解題中的難點,也是計算機解題成敗的關鍵的關鍵 建立計算機可以實現(xiàn)的計算模型。就是解題的數(shù)學模型 通過數(shù)值分析將計算模型化為等價的計算機可接受的方程 非數(shù)值問題更要依賴模型需求分析需求分析(續(xù))(續(xù))l 程序的規(guī)格說明

4、程序的規(guī)格說明(specification)(specification)規(guī)格說明是程序設計必須遵從的“憲法”沒有模型就難于寫出準確的規(guī)格說明一個程序(軟件)經(jīng)過分析可以分解為若干個子部分,除了總的規(guī)格說明之外,各子部分也要寫規(guī)格說明。它們也是這些子部分開發(fā)、測試、驗收的依據(jù)需求分析需求分析(續(xù))(續(xù))l一般子模塊規(guī)格說明的內(nèi)容一般子模塊規(guī)格說明的內(nèi)容 名稱名稱( (名稱最好有較強的概括性,如矩陣二次型名稱最好有較強的概括性,如矩陣二次型) ) 開發(fā)者開發(fā)者/ /日期:日期: 輸入輸入: : 算法模型:數(shù)學模型寫公式,圖模型畫圖算法模型:數(shù)學模型寫公式,圖模型畫圖 功能特征功能特征: : 輸出

5、輸出: : 性能約束性能約束: :需求分析需求分析(續(xù))(續(xù))l 整個應用程序的規(guī)格說明的內(nèi)容應包括:整個應用程序的規(guī)格說明的內(nèi)容應包括: 名稱名稱: 開發(fā)者開發(fā)者/日期日期: 功能特征功能特征: 程序結構:列出子部分名稱、規(guī)格程序結構:列出子部分名稱、規(guī)格(特征特征) 使用資源:使用資源: 軟件型號、規(guī)格軟件型號、規(guī)格 軟件平臺型號、版本軟件平臺型號、版本 數(shù)據(jù)庫型號、版本數(shù)據(jù)庫型號、版本 輸入輸入: 輸出輸出: 性能約束性能約束: 其它:保密級別、口令等其它:保密級別、口令等 需求分析需求分析(續(xù))(續(xù))l規(guī)格說明一般寫在源程序頭部的注釋行中,規(guī)格說明一般寫在源程序頭部的注釋行中,這種風格

6、流傳至今這種風格流傳至今l也可單獨寫規(guī)格說明文檔(從軟件工程的也可單獨寫規(guī)格說明文檔(從軟件工程的角度來說,應當這樣。后面將討論這個問角度來說,應當這樣。后面將討論這個問題),對于大的源程序題),對于大的源程序(千句以上千句以上)這種重這種重復是必要的復是必要的二二 程序設計程序設計l流程圖流程圖 流程圖可清楚地看出執(zhí)行邏輯。畫流程圖是作設計。設計先于編碼l程序設計包括程序的控制流設計程序設計包括程序的控制流設計( (算法設計算法設計) )和和數(shù)據(jù)設計數(shù)據(jù)設計 只要數(shù)據(jù)結構定下來,算法的設計就比較容易。對大多數(shù)問題來說,兩者并重 算法和數(shù)據(jù)結構設計應滿足功能要求,還要滿足規(guī)格說明對性能的要求l

7、程序設計還應該保證軟件的程序設計還應該保證軟件的質量質量 可靠性,安全性,可維護性,可移植性,適應性,可測試性等程序設計準則程序設計準則l 模塊化模塊化較小的模塊;降低程序的復雜性;避免數(shù)據(jù)耦合少用全局變量,少通過嵌套作用域來傳遞參數(shù)l 結構化結構化每個模塊內(nèi)程序控制應是結構化的,即只有三種基本控制結構并層層嵌套;不用或少用GoTo語句l 數(shù)據(jù)隱藏數(shù)據(jù)隱藏凡與其它模塊無關的數(shù)據(jù)盡可能作為局部量放在自己的模塊內(nèi)程序設計準則程序設計準則(續(xù))(續(xù))l 可測試性可測試性l 一致性一致性行文風格一致(排列對齊,空行、邊框、關鍵字都出現(xiàn)在同樣位置)表達方法盡量一致(同樣的數(shù)據(jù)、控制結構同樣表達,如用鏈表

8、都鏈表,用數(shù)組都數(shù)組)設計方法設計方法l需求分析定義的規(guī)格說明是在一個核心的、需求分析定義的規(guī)格說明是在一個核心的、大致的解題大致的解題模型模型之上,設計時要具體刻畫出之上,設計時要具體刻畫出來,來,具體到能一一對應編碼為宜具體到能一一對應編碼為宜l程序開發(fā)是從抽象到具體的過程。兩種典型程序開發(fā)是從抽象到具體的過程。兩種典型方法方法: :自頂向下逐步求精自頂向下逐步求精面向對象設計面向對象設計:面向對象編程是典型的由底向上設計;對象建模的關鍵是找出對象三三 編碼編碼l 編碼編碼(Coding)(Coding)是是正式地編寫某種程序語言的源正式地編寫某種程序語言的源程序,還包括以下工作:程序,還

9、包括以下工作: 模塊最后重組 一致性完善 源程序級的程序優(yōu)化:l 盡可能用符號常量l 減少重復計算l 將循環(huán)次數(shù)多的作內(nèi)循環(huán)l 減少不必要的計算l 除了時間優(yōu)化而外,還有空間優(yōu)化即少占存儲四四 測試與排錯測試與排錯l軟件測試是為了發(fā)現(xiàn)程序中的錯誤而進軟件測試是為了發(fā)現(xiàn)程序中的錯誤而進行的一系列工作過程。它有以下特征:行的一系列工作過程。它有以下特征: 測試的挑剔性 完全測試的不可能性l程序的可靠性程序的可靠性定義為定義為“在給定的時間和給定的環(huán)在給定的時間和給定的環(huán)境下,系統(tǒng)成功地執(zhí)行所指定功能的概率境下,系統(tǒng)成功地執(zhí)行所指定功能的概率” 測試的經(jīng)濟性測試技術測試技術l測試是將可能的輸入值測試

10、是將可能的輸入值( (一組數(shù)據(jù)一組數(shù)據(jù)) )輸入輸入運行后看程序是否滿足預期結果運行后看程序是否滿足預期結果( (機器動機器動作正確或輸出值正確作正確或輸出值正確) )。這一組測試數(shù)據(jù)。這一組測試數(shù)據(jù)稱為測試用例稱為測試用例(testing case)(testing case) 黑箱測試黑箱測試 白箱測試白箱測試黑箱測試黑箱測試l按規(guī)格說明指明的輸入和預期的功能、性按規(guī)格說明指明的輸入和預期的功能、性能進行測試。程序的使用性能是測試的主能進行測試。程序的使用性能是測試的主要目標。一般說的程序測試即指黑箱測試要目標。一般說的程序測試即指黑箱測試l等價類劃分等價類劃分l邊值分析邊值分析l測試用例

11、設計是一個需要創(chuàng)造性的工作,測試用例設計是一個需要創(chuàng)造性的工作,力求例子少而精,覆蓋面大,且無一遺漏力求例子少而精,覆蓋面大,且無一遺漏白箱測試白箱測試l讓程序的每一條語句都執(zhí)行一次本測試用讓程序的每一條語句都執(zhí)行一次本測試用例,這就是白箱測試例,這就是白箱測試l白箱測試也叫白箱測試也叫路徑測試路徑測試。所有的語句必須。所有的語句必須執(zhí)行一次以上,這是最起碼的要求。徹底執(zhí)行一次以上,這是最起碼的要求。徹底些,每條路徑都要走到。些,每條路徑都要走到。所有路徑都走一所有路徑都走一遍還不能保證徹底遍還不能保證徹底。因為每個判斷的子條。因為每個判斷的子條件也可能從未用過。只有每個判斷的子判件也可能從未

12、用過。只有每個判斷的子判斷為斷為真真為為假假都走一遍才相對徹底都走一遍才相對徹底排排 錯錯l排錯排錯(Debugging)(Debugging)也叫調(diào)試,排錯是消除也叫調(diào)試,排錯是消除程序中缺陷程序中缺陷(bug)(bug)的過程。一般有以下步的過程。一般有以下步驟:驟: 通過測試發(fā)現(xiàn)程序有錯 找出出錯的位置(定位) 分析出錯原因,并改正之 再測試消除找出的缺陷排排 錯錯(續(xù))(續(xù))l 編碼階段的測試盡可能采用白箱技術。當一組數(shù)據(jù)多次運行有相同的錯誤則證明此模塊有錯。語法錯誤最好查,好的編譯會指出出錯地點。不能運行完的一般是連接錯誤,有的系統(tǒng)也會自動指出。能運行但不能得出正確結果是排錯最常見的

13、工作l 錯誤定位的思維方法是“步步為營”、“縮小包圍圈”。利用工具或人為設置檢查點,每個檢查點顯示當前執(zhí)行情況(數(shù)據(jù)值)l 一般需要接口處設檢查點,以便了解進入本塊的最初情況排排 錯錯(續(xù))(續(xù))l 找到出錯原因改正錯誤要十分小心。不要找到一個就改,盡可能找出所有的錯再改,以減少它們彼此因修改而產(chǎn)生的相互影響。經(jīng)驗表明,改一個錯誤派生出3-4個錯是常有的事。對每次測試條件、結果的詳細記錄是十分重要的!l 一般把編碼階段的測試稱為模塊測試,對于不大的程序系統(tǒng),以上方法和技術就足以應付了。對于較大的程序系統(tǒng),下一步是整個程序系統(tǒng)的測試,將在軟件工程中講述4.24.2 軟件工程概述軟件工程概述l 軟

14、件的發(fā)展:軟件的發(fā)展:程序設計階段(1946年1955年底)軟件設計階段(1956年1970年)軟件工程階段(1970年至今): l由于軟件危機的產(chǎn)生,迫使人們不得不研究、改變軟件開發(fā)的技術手段和管理方法。從此軟件生產(chǎn)進入軟件工程時 軟件工程概述軟件工程概述(續(xù))(續(xù))l1968年軟件業(yè)界和科學工作者提出了軟件工程的概念:任何軟件都應當和其它產(chǎn)業(yè)任何軟件都應當和其它產(chǎn)業(yè)的產(chǎn)品一樣,由專業(yè)人員制作的產(chǎn)品一樣,由專業(yè)人員制作( (軟件中是系軟件中是系統(tǒng)分析員、高級程序員、程序員統(tǒng)分析員、高級程序員、程序員) ),以,以系統(tǒng)系統(tǒng)的、工程的的、工程的方法開發(fā)制作,并提供全方位方法開發(fā)制作,并提供全方位

15、的售后服務管理的售后服務管理( (不能因開發(fā)者離開調(diào)走而不能因開發(fā)者離開調(diào)走而無人管無人管) )軟件工程概述軟件工程概述(續(xù))(續(xù))l所謂系統(tǒng)的方法是任何產(chǎn)品都有其創(chuàng)意、開發(fā)、生產(chǎn)、調(diào)試、使用、維護、退役的全過程,而不是只考慮其中的一部分(例如,軟件開發(fā))l所謂工程方法要有工程規(guī)范和工程管理。工程產(chǎn)品不要求絕對完善,只要求在給定時間、給定的經(jīng)費和當前技術條件下符合規(guī)范的要求的最佳。工程管理要考慮到可行性、計劃性、投入/產(chǎn)出、費用/效益軟件工程概述軟件工程概述(續(xù))(續(xù))l 軟件開發(fā)不再是完成為解決某一問題而必需滿足的功能、性能要求,而是作為一個軟件產(chǎn)品的全面功能、性能要求。例如,可維護性、可擴

16、充性、可識性、可移植性等。軟件工程以系統(tǒng)工程的方法制作軟件產(chǎn)品,它包括:軟件的系統(tǒng)軟件的系統(tǒng)( (生存期生存期) )模型模型與此模型相對應的各種規(guī)范和標準與此模型相對應的各種規(guī)范和標準為達到這些規(guī)范、標準的方法和工具為達到這些規(guī)范、標準的方法和工具軟件開發(fā)的全面管理軟件開發(fā)的全面管理軟件工程概述軟件工程概述(續(xù))(續(xù))l 軟件不僅僅是可運行的程序系統(tǒng),為了維護和適應市場技術的發(fā)展,它必須有全套完整的文檔,所以軟件=程序+文檔l 軟件開發(fā)方法學的研究是軟件技術發(fā)展最活躍的因素。所謂方法學(Methodology)是一組規(guī)范了的方法,按這組方法執(zhí)行,可以得到較為理想的結果。把這組方法施行過程標準化

17、就是軟件開發(fā)標準軟件工程概述軟件工程概述(續(xù))(續(xù))l 有了軟件規(guī)范和標準,軟件工具才有市場。軟件工具從最初的編譯器、連接器、加載運行的必備工具(現(xiàn)在已納入操作系統(tǒng)范疇)到測試排錯工具、格式美化器,到當今可執(zhí)行的規(guī)范說明語言、模型描述代碼自動生成工具。以“軟件開發(fā)軟件”的大量自動工具的出現(xiàn),構成了良好的軟件開發(fā)環(huán)境(Environment,開發(fā)環(huán)境即開發(fā)工具集的總稱)。這些工具的互連和集成(在單一的界面上可以方便、靈活地使用這些工具)就構成了軟件開發(fā)平臺(flat)4.3 4.3 傳統(tǒng)的軟件工程傳統(tǒng)的軟件工程l軟件工程是以系統(tǒng)的、規(guī)范的、定量的方軟件工程是以系統(tǒng)的、規(guī)范的、定量的方法應用于軟件

18、的開發(fā)、運營和維護,以及法應用于軟件的開發(fā)、運營和維護,以及對這些方法的研究對這些方法的研究l軟件工程一開始就以高質量、高效率、低軟件工程一開始就以高質量、高效率、低成本開發(fā)大型軟件系統(tǒng)為己任。強調(diào)采用成本開發(fā)大型軟件系統(tǒng)為己任。強調(diào)采用強類型語言,嚴格規(guī)范、步步為營,實現(xiàn)強類型語言,嚴格規(guī)范、步步為營,實現(xiàn)軟件的工程化開發(fā)軟件的工程化開發(fā)一一 生存周期模型生存周期模型瀑布式生存周期模型瀑布式生存周期模型 / 線性順序線性順序l原型模型(原型模型(Prototyping)l螺旋模型(螺旋模型(Spiral)l構件組裝模型(構件組裝模型(Component)l快速應用開發(fā)(快速應用開發(fā)(RAD)

19、業(yè)務模型業(yè)務模型數(shù)據(jù)模型數(shù)據(jù)模型處理模型處理模型應用生成應用生成測試與交付測試與交付6090天天二二 需求分析需求分析l將用戶需要抽象為模型,并指出什么樣將用戶需要抽象為模型,并指出什么樣的軟件能滿足抽象出的模型的軟件能滿足抽象出的模型l分析任務分析任務:識別問題分析與綜合建模寫規(guī)格說明國家標準GB856D-88規(guī)格說明的內(nèi)容 1. 1. 引言引言 1.1 1.1 編寫說明編寫說明 1.2 1.2 背景背景 立項根據(jù)或合同立項根據(jù)或合同 1.3 1.3 定義定義 指文中用到的術語、概念指文中用到的術語、概念 1.4 1.4 參考資料參考資料 2. 2. 任務概述任務概述 2.1 2.1 目標目

20、標 2.2 2.2 用戶特點用戶特點 2.3 2.3 假定和約束假定和約束 本軟件前題條件本軟件前題條件 3. 3. 需求規(guī)定需求規(guī)定 3.1 3.1 對功能的規(guī)定對功能的規(guī)定 可按信息結構分述可按信息結構分述國家標準GB856D-88規(guī)格說明的內(nèi)容(續(xù)) 3.2 3.2 對性能的規(guī)定對性能的規(guī)定 3.2.1 3.2.1 精度精度 3.2.2 3.2.2 時間特性時間特性 3.2.3 3.2.3 靈活性靈活性 3.3 3.3 對輸入輸出的要求對輸入輸出的要求 3.4 3.4 對數(shù)據(jù)管理能力要求對數(shù)據(jù)管理能力要求 3.5 3.5 故障處理要求故障處理要求 3.6 3.6 其它專門要求其它專門要求

21、 4. 4. 運行環(huán)境規(guī)定運行環(huán)境規(guī)定 4.1 4.1 設備設備 4.2 4.2 支持軟件支持軟件 4.3 4.3 接口接口 4.4 4.4 控制控制 需求分析需求分析(續(xù))(續(xù))l需求階段的其他工作需求階段的其他工作 除了建模和寫規(guī)格說明書之外,在需求階段還要做以除了建模和寫規(guī)格說明書之外,在需求階段還要做以下工作下工作 可行性分析報告 項目計劃 初步用戶手冊 評審分析模型分析模型l 分析模型諸元素分析模型諸元素數(shù)據(jù)模型:描述數(shù)據(jù)之間的關系,常用E-R圖功能模型:描述軟件如何處理數(shù)據(jù),常用DFD圖行為模型:以軟件的數(shù)據(jù)狀態(tài)改變來刻劃軟件的行為,事件是促使狀態(tài)改變的動因,使狀態(tài)轉移,常用狀態(tài)轉

22、移圖STDl 數(shù)據(jù)流圖數(shù)據(jù)流圖DFDDFDl 控制流圖控制流圖CFDCFD數(shù)據(jù)流圖數(shù)據(jù)流圖 DFDDFDl 信息在機內(nèi)以數(shù)據(jù)形式出現(xiàn)。數(shù)據(jù)流圖信息在機內(nèi)以數(shù)據(jù)形式出現(xiàn)。數(shù)據(jù)流圖(DataFlow Diagram)(DataFlow Diagram)的表示法很簡單。的表示法很簡單。只有四種圖符只有四種圖符外部實體數(shù)據(jù)流處理數(shù)據(jù)存儲實體名數(shù)據(jù)名處理名名數(shù)據(jù)庫查詢應用的細化數(shù)據(jù)庫查詢應用的細化DFDDFD圖圖得到命令分析命令命令重組輸出信息檢查完整性得歷史記錄休整命令換成SQLDBMS分析應答輸出數(shù)據(jù)用戶命令歷史命令命令合法命令出錯1出錯2終端數(shù)據(jù)被檢數(shù)據(jù)出錯了信息標志數(shù)據(jù)DB應答查詢請求完整命令完

23、整命令不完整記錄請求*數(shù)據(jù)庫文件右圖是細化的DFD圖。*表示“與”,+表示“或”,也可用文字注明。一個圈就是一個過程/函數(shù),可退化為一語句,也可再分解為一子DFD圖,出入的數(shù)據(jù)流不變實體關系圖實體關系圖 ERDERDl實體實體關系圖關系圖(Entity-Relationship (Entity-Relationship DiagramDiagram簡稱簡稱ERDERD) )的圖元是矩形框表示的圖元是矩形框表示實體,中間寫數(shù)據(jù)對象名;實體間的連實體,中間寫數(shù)據(jù)對象名;實體間的連線即表示它們之間有關系,線上寫關系線即表示它們之間有關系,線上寫關系名。也可以把關系名寫在凌形框內(nèi)。聯(lián)名。也可以把關系名

24、寫在凌形框內(nèi)。聯(lián)線兩端的符號表示在此關系下實體可以線兩端的符號表示在此關系下實體可以1 1對對1 1出現(xiàn),出現(xiàn),1 1 對多,多對多出現(xiàn)。也可對多,多對多出現(xiàn)。也可以指示此關系是可選的以指示此關系是可選的實體關系圖實例實體關系圖實例l E-R圖可以表示實體聚集和層次關系,如下圖:選手分成不合格一般選手優(yōu)秀干事國家隊國奧隊轉業(yè)轉隊用用E-RE-R圖表示層次關系圖表示層次關系乒乓隊田徑隊籃球隊足球隊組成國 家 隊用用E-R圖表示聚集關系圖表示聚集關系三三 設計設計l 設計是構造軟件的重要階段,它根據(jù)分析得出的設計是構造軟件的重要階段,它根據(jù)分析得出的模型,以當今可用的技術和設施,作出決策。所模型,

25、以當今可用的技術和設施,作出決策。所以要設計出能運行的軟件要作到以要設計出能運行的軟件要作到: :數(shù)據(jù)設計數(shù)據(jù)設計 整個軟件用到的數(shù)據(jù)體系結構設計體系結構設計 整個軟件的程序組成過程設計過程設計 每個組成如何實現(xiàn)界面設計界面設計 用戶怎樣使用本軟件?本 軟件和環(huán)境如何相接設計設計(續(xù))(續(xù))l早期的設計分為概要設計早期的設計分為概要設計(preliminary (preliminary design)design)和詳細設計和詳細設計(detail design)(detail design)兩個兩個階段階段l設計不等于編碼,設計不等于編碼,“邊設計、邊編碼、邊邊設計、邊編碼、邊測試測試”是約

26、定俗成的,設計是約定俗成的,設計分析也無嚴分析也無嚴格界線格界線數(shù)據(jù)設計數(shù)據(jù)設計l數(shù)據(jù)設計(Data Design)是將需求分析中定義的數(shù)據(jù)模型進一步細化為軟件實現(xiàn)需要的數(shù)據(jù)結構,它對應為分析模型中的E-R模型和數(shù)據(jù)字典l數(shù)據(jù)設計還要決定選用文件還是數(shù)據(jù)庫系統(tǒng)l基于數(shù)據(jù)庫的應用有時還需選定數(shù)據(jù)庫系統(tǒng)并創(chuàng)建數(shù)據(jù)庫。這些在需求分析時就應定下來,這個階段是具體創(chuàng)建數(shù)據(jù)庫體系結構設計體系結構設計l體系結構設計(Architectural design)的主要目標是建立整個軟件的總體結構,在分析階段中高層的模型圖大體可以劃分子系統(tǒng),以及子系統(tǒng)間的數(shù)據(jù)聯(lián)系l由于DFD圖一般能反映數(shù)據(jù)和處理軟件功能的兩個方

27、面,所以從細化DFD圖開始,完成后轉成結構圖(Structured Chart簡稱SC)建立體系結構的大體思路建立體系結構的大體思路l 細化細化DFDDFD圖圖l 分析細化的分析細化的DFDDFD圖,調(diào)整圖,調(diào)整SCSCl 結構調(diào)整結構調(diào)整l 調(diào)整時應考慮易于測試調(diào)整時應考慮易于測試界面設計界面設計管理輸入設備(鼠標、鍵盤);確認用戶輸入;處理錯誤和顯示錯誤消息;提供輸入反饋(如輸入自動回聲);提供提示和幫助開發(fā)(開發(fā)者只要規(guī)定符號和提供幫助內(nèi)容);窗口、域的顯示,重疊和內(nèi)容滾展;提供和應用程序的接口;界面管理功能和應用程序隔離;允許用戶定制界面。 對應用開發(fā)者此刻要先做:界面的規(guī)格說明;界面

28、設計原則;定義到外部數(shù)據(jù)和外部設備或系統(tǒng)的接口過程設計過程設計l完成數(shù)據(jù)、體系結構、界面設計之后,就按處理規(guī)格說明,或控制規(guī)格說明,或狀態(tài)轉移圖,一一寫出過程程序。選定或設計相應的算法作出設計。此時并非用某種程序設計語言,而是類_xxx語言、PDL、細化圖形(設計詳細的結構化流程圖)四四 軟件測試軟件測試l 軟件測試軟件測試是保證軟件質量中的一種活動,軟件質量要經(jīng)過驗證(Verification)和確認(Validation)過程,簡稱V&V驗證驗證是證實軟件正確地實現(xiàn)了某些功能(所作的軟件正確)確認確認是證實所作軟件能夠滿足用戶的要求(作出了正確的軟件)測試是為發(fā)現(xiàn)軟件錯誤而執(zhí)行程序

29、的過程本節(jié)從軟件工程角度系統(tǒng)地介紹測試測試的種類測試的種類l 單元(Unit,一個或多個模塊)測試,它驗證編碼是否正確l 集成(Intergrated)測試,即按項目要求做完一完整軟件,驗證其功能、性能是否達到設計要求l 確認(Validation)測試,即全面驗證本軟件是否達到需求定義的規(guī)格說明的要求l 系統(tǒng)(System)測試,即全面測試作為軟件產(chǎn)品的功能與性能,如錯誤恢復能力、安全性、抗干撓能力、極限能力等測試文檔測試文檔l在軟件分析和設計時就要準備寫出測試在軟件分析和設計時就要準備寫出測試計劃。到設計完成后即時寫出測試規(guī)模計劃。到設計完成后即時寫出測試規(guī)模說明說明( (包含測試計劃包含測試計劃) )。測試規(guī)格說明的。測試規(guī)格說明的大體內(nèi)容如下頁表大體內(nèi)容如下頁表: :測試規(guī)格說明測試規(guī)格說明. . 測試范圍測試

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論