程序開發(fā)和軟件工程PPT學習教案

1、會計學1程序開發(fā)和軟件工程程序開發(fā)和軟件工程n適應性：軟、硬件平臺中某部件升級或版本就不適應了。n可測試性：除了使用現(xiàn)場其它環(huán)境不能作有意義的測試第1頁/共30頁化，凡與其它模塊無關的數(shù)據(jù)盡可能作為局部量放在自己的模塊內(nèi)n可測試性：可測試性：程序的可測試性在設計程序結構時就得考慮，以免最后變得不可追蹤，不可測試n一致性：一致性：指程序編碼完成后，行文風格一致(排列對齊，空行、邊框、關鍵字都出現(xiàn)在同樣位置)、表達方法盡量一致第2頁/共30頁gfabcde53724643145求最大流量輸入地圖，指定起始位置顯示地圖，輸出結果輸入處理輸出第3頁/共30頁初始數(shù)據(jù)計算最大流輸出結果指定起止a，d顯示

2、地圖顯示路線、結果輸入地圖結點數(shù)結點名聯(lián)線權值abgf.342.bafc.356.cbfd.641.dcefe.134.effd.54.fgabcde725435gffa.74.鄰接矩陣A（7，7）權矩陣W（7，6）第4頁/共30頁MaxFlow初始化找最大流輸出查找路徑求最小權重Visio畫圖工具Visio畫圖工具顯示結果交互式輸入afgbdedcbgfcfgbdedbdcaadfdddfcdffddd.第5頁/共30頁作作1.1.模塊最后重組：將功能相差不多或模塊最后重組：將功能相差不多或不夠規(guī)范的模塊以規(guī)范的庫模塊取不夠規(guī)范的模塊以規(guī)范的庫模塊取代，模塊大小在不甚影響其功能、代，模塊大小

3、在不甚影響其功能、性能前題下調(diào)整性能前題下調(diào)整( (合并、切分合并、切分) )，增，增強一致性使程序簡單。強一致性使程序簡單。2. 2. 一致性完善：程序和輸出結果表一致性完善：程序和輸出結果表達風格的一致達風格的一致3.3.源程序級的程序優(yōu)化：盡可能用符源程序級的程序優(yōu)化：盡可能用符號常量、減少重復計算、循環(huán)內(nèi)的號常量、減少重復計算、循環(huán)內(nèi)的重復、不必要的計算，將循環(huán)次數(shù)重復、不必要的計算，將循環(huán)次數(shù)多的作內(nèi)循環(huán)多的作內(nèi)循環(huán)第6頁/共30頁看程序是否滿足預期結果看程序是否滿足預期結果n測試數(shù)據(jù)稱為測試用例測試數(shù)據(jù)稱為測試用例(testing (testing case)case)。測試用例的

4、選取和采用的。測試用例的選取和采用的測試技術有關。測試時，為了各個測試技術有關。測試時，為了各個擊破，一般編一段測一段擊破，一般編一段測一段(1) (1) 黑箱測試：只看輸入和程序結果，黑箱測試：只看輸入和程序結果，不管程序內(nèi)部執(zhí)行過程不管程序內(nèi)部執(zhí)行過程n等價類劃分：等價類劃分： 程序的輸入至少有兩程序的輸入至少有兩大類，分為有效輸入大類，分為有效輸入( (可得出正確值可得出正確值) )等價類，一為無效輸出等價類等價類，一為無效輸出等價類n邊值分析：在等價類的基礎上用邊邊值分析：在等價類的基礎上用邊界值進行測試界值進行測試(2) (2) 白箱測試：也叫路徑測試。所有白箱測試：也叫路徑測試。所

5、有的語句必須執(zhí)行一次以上，這是最的語句必須執(zhí)行一次以上，這是最起碼的要求。徹底些，每條路徑都起碼的要求。徹底些，每條路徑都要走到要走到第7頁/共30頁n找出出錯的位置(定位)n分析出錯原因，并改正之。n再測試消除找出的缺陷n找到出錯原因后，改正錯誤要十分小心。盡可能找出所有的錯再改，以減少它們彼此因修改而產(chǎn)生的相互影響第8頁/共30頁n1968年軟件業(yè)界和科學工作者提出了軟件工程的思想：任何軟件都應當和其它產(chǎn)業(yè)的產(chǎn)品一樣，由專業(yè)人員制作(軟件中是系統(tǒng)分析員、高級程序員、程序員)，以系統(tǒng)的、工程的方法開發(fā)，并提供全方位的售后服務管理(不能因開發(fā)者離開調(diào)走而無人管)5560657075808590

6、50%成本 100%硬件軟件第9頁/共30頁件工程是以系統(tǒng)的、規(guī)范的、定量的方法應用于軟件的開發(fā)、運營和維護，以及對這些方法的研究第10頁/共30頁系統(tǒng)分析軟件需求分析概要設計詳細設計編程與測試測 試使用維護用戶需要硬件需求分析系統(tǒng)規(guī)格說明書，可行性分析報告軟件規(guī)格說明書，軟件項目計劃，初步用戶手冊概要設計說明書設計說明書，測試大綱模塊測試報告，源程序文檔各種測試報告退役瀑布式生存周期模型瀑布式生存周期模型第11頁/共30頁求，軟件的功能、性能要求。用約定的符號或正文逐條列出。在整個分析間要和用戶充分協(xié)商(2) 分析與綜合n分析信息的流向、類型，如何處理等問題，判定信息處理的類型(3) 建模：

7、建立軟件解題模型，也是刻畫該問題的模型(4) 寫規(guī)格說明：說明軟件在什么條件下能做什么事情第12頁/共30頁(上崗)培訓計劃。(3) 初步用戶手冊：從用戶觀點描述一次規(guī)格說明，驗證需求定義是否遺漏，為正式用戶手冊打下基礎(4) 評審n由開發(fā)人員(高層)、用戶(業(yè)主)、同行專家(非本項目)對交付的文檔詳細評審，通過后才能投入下一階段。所有文檔一經(jīng)審批，改動需重申請第13頁/共30頁數(shù)據(jù)字典E-R圖DFD處 理規(guī) 格說明數(shù) 據(jù)對 象描 述狀態(tài)轉(zhuǎn)移圖控制規(guī)格說明CSPEC實體-關系數(shù)據(jù)流PSPEC第14頁/共30頁n雙線表示數(shù)據(jù)存儲加上箭頭指示，它成為:外部實體數(shù)據(jù)流處理數(shù)據(jù)存儲實體名數(shù)據(jù)名處理名名

8、數(shù)據(jù)源數(shù)據(jù)潭OracleUFS第15頁/共30頁管理復印產(chǎn)生用戶顯示故障診斷再裝紙讀輸入命令紙張狀態(tài)（卡/空）命令起/停復印裝紙裝滿診斷完正常/卡紙卡紙信息2信息1響鈴復印機的控制流圖第16頁/共30頁 有紙啟動引起manage-copying讀命令 空 閑 引起read-op-input復 印裝 紙 裝滿 read-op-input復印完引起read-op-input紙空引起reload-paper故障診斷卡 住Perform-diagnosis修 復read-op-input第17頁/共30頁111nnmnmE1E2R1R2R3R4寫了數(shù)字可不畫符號R3是必有的關系，且n:m多對多實體E1

9、、E2可以沒有R4關系，如果有是n:m關系第18頁/共30頁乒乓隊田徑隊籃球隊足球隊組成國 家 隊選手分成不合格一般選手優(yōu)秀干事國家隊國奧隊轉(zhuǎn)業(yè)轉(zhuǎn)隊用E-R圖表示層次關系用E-R圖表示聚集關系第19頁/共30頁(6) (6) 使用情況圖使用情況圖Use-caseUse-case對于面向?qū)ο筌浖?，根?jù)客觀世界發(fā)生的事情，描述可見對象間的交互行為，橢園表示行為，聯(lián)線表示事件，帶箭頭的線表示行為之間的關系(一般細化時加上)細化后：第20頁/共30頁數(shù)據(jù)設計整個軟件用到的數(shù)據(jù)體系結構設計整個軟件的程序組成過程設計每個組成如何實現(xiàn)界面設計用戶怎樣使用本軟件？軟件和環(huán)境如何相接第21頁/共30頁稱SC)，

10、其中表示數(shù)據(jù)流向,方框表示模塊(2) 分析細化的DFD圖，調(diào)整SC。并非每一框都如上述變成模塊。SC圖只說明邏輯上可以這樣去組成，但還要劃分和調(diào)整。原則：n找出數(shù)據(jù)流圖中數(shù)據(jù)流向的邊界n減少數(shù)據(jù)調(diào)用引起的模塊間耦合(3) 結構調(diào)整：邏輯上變成SC圖實際也可調(diào)整，例如一句話就可以表達的功能可以合并到另一模塊，數(shù)據(jù)傳遞頻繁也應合在一個模塊內(nèi)。太長太大都要分小(4) 調(diào)整時應考慮易于測試，越是獨立的模塊越好測試，結構圖是測試計劃的根據(jù)第22頁/共30頁完成數(shù)據(jù)、體系結構、界面設計之后，就按處理規(guī)格說明，或控制規(guī)格說明，或狀態(tài)轉(zhuǎn)移圖，一一寫出過程程序。選定或設計相應的算法作出設計。此時并非用某種程序設

11、計語言，而是類_xxx語言、PDL、細化圖形（設計詳細的結構化流程圖）第23頁/共30頁系統(tǒng)分析需求規(guī)格編碼軟件設計交付確認測試系統(tǒng)測試集成測試單元測試(a)軟件測試 (b)參與程度開發(fā)人員管理人員測試人員客戶用戶高級程序員程序員第24頁/共30頁驅(qū)動程序被測模塊樁樁結果界面數(shù)據(jù)結構邊界條件獨立路徑錯誤處理路徑測試用例圖4.18 模塊測試環(huán)境和用例內(nèi)容第25頁/共30頁據(jù)與局部數(shù)據(jù)結構的相互影響。邊界條件：保證在邊界值的情況下模塊依然可以正確操作，值出界時要有正確反應。獨立路徑：保證至少所有語句都要執(zhí)行一次以上，每個條件或子條件都執(zhí)行一次更好。錯誤處理路徑：不管程序有無異常處理都要察看出錯處理

12、路徑。在程序易出錯之處如類型比較、轉(zhuǎn)換錯，循環(huán)控制變量被賦值等，設置用例特別要考察是否死機。第26頁/共30頁處)，測完一塊向下走一塊。因而必然是增量式。n回歸測試：將測試過的用例的子集重新執(zhí)行，以確保新的變更不會產(chǎn)生不希望的邊界效應。主要的工作是收集有代表性的用例子集，可以人工整理，也可用找回歸(capture playback)工具輔助完 成 。 整 理 出 的 回 歸 測 試 集(suite)包含以下內(nèi)容:n程序的每種功能的典型樣板用例(為以后測試用)；n對每種更改特別敏感的用例；n已改好的軟件構件的用例第27頁/共30頁3. 確認測試確認測試一般是一系列的黑箱測試以驗證是否與需求規(guī)格說明的描述相符，測試計劃中要列出這類測試的規(guī)程并專為其設計測試用例，計劃和規(guī)程應能證實:所有功能需求均滿足；所有性能需求均達到；所有文檔均已改正；其它需求已滿足確認測試中還要做以下工作:(1)配置評審,有時叫審計(audit)，保證每個軟件配置項已開發(fā)并清晰歸類。 (2) 阿爾法與貝塔