程序开发和软件工程课件

程式開發和軟體工程4.1程式設計過程4.1.1需求分析程式的內容就是對需要解決的問題的描述。它首先要建立電腦可以實現的計算模型建模僅僅是程式設計的基礎。程式在此模型上做什麼事,即程式的規格說明(specification)問題的提出只是用戶的需要(need)，把需要變為需求(requirement)是需求分析的工作，即有沒有可能用軟體來滿足用戶需要(可行性)。如果可行，這個程式應是什麼樣的(需求定義)，這就是程式的規格說明一個程式(軟體)經過分析可以分解為若干個子部分，除了總的規格說明之外，各子部分也要寫規格說明。它們也是這些子部分開發、測試、驗收的依據4.1.2程式設計除了功能、性能要求而外，程式設計還應該保證軟體的品質,如:可靠性：交付時規格說明均滿足，但時好時壞。安全性：由於使用不當導致所在系統崩潰。可維護性：修改一個小錯；引發一串大錯。可移植性：不同平臺上不能用適應性：軟、硬體平臺中某部件升級或版本就不適應了。可測試性：除了使用現場其他環境不能作有意義的測試1.設計準則模組化:一個大的程式按功能或數據原則分解成為較小的模組,可以極大地降低程式的複雜性,有利於閱讀、測試、修改結構化:每個模組內程式控制應是結構化的,以便於測試、查錯和修改。要採用結構化程式設計語言,不用或少用GoTo語句數據隱藏：模組化實質也是局部化，凡與其它模組無關的數據盡可能作為局部量放在自己的模組內可測試性：程式的可測試性在設計程式結構時就得考慮，以免最後變得不可追蹤，不可測試一致性：指程式編碼完成後，行文風格一致(排列對齊，空行、邊框、關鍵字都出現在同樣位置)、表達方法儘量一致2.設計方法需求分析定義的規格說明是建立在核心的、大致的計算解題模型之上的，設計時要具體刻畫出來，具體到能一一對應編碼為宜(1)自頂向下逐步求精

例：地圖上有若干城鎮及相互連接的道路，各城鎮間最大運輸能力標注在路線上。要求設計一程式，計算任意指定兩城鎮間的最大流通能力。進一步細化為：地圖用鄰接表矩陣(7×7)，對應權矩陣(7×6)進一步細化為：對“找最大化”細化。逐一查找所有路徑的演算法是一株搜索樹(2)面向對象設計

面向對象編程是典型的由底向上設計

對象建模的關鍵是找出對象。按Booch的方法：先用自然語言陳述它的解然後將集合名詞、概括(抽象)名詞作為對象候選具體名詞和形容詞作為屬性，動詞作為操作的候選，副詞可作屬性或操作。

4.1.3編碼即把以類_xxx語言描述的設計變成xxx語言的根源程式，還應完成如下工作1.模組最後重組：將功能相差不多或不夠規範的模組以規範的庫模組取代，模組大小在不甚影響其功能、性能前題下調整(合併、切分)，增強一致性使程式簡單。2.一致性完善：程式和輸出結果表達風格的一致3.根源程式級的程式優化：盡可能用符號常量、減少重複計算、迴圈內的重複、不必要的計算，將迴圈次數多的作內迴圈4.1.4測試與排錯程式是由人設計（構造）的，如何保證程式的正確性，如何證明和驗證程式的正確性就是一個極大的同時也是極為困難的問題。比較實用的驗證程式的方法就是測試。測試只能證明程式有錯，而不能確保程式的正確性。一個通過了某一測試的程式，也許還包含尚未發現的錯誤1.測試技術：測試是將可能的輸入值)輸入運行後看程式是否滿足預期結果測試數據稱為測試用例(testingcase)。測試用例的選取和採用的測試技術有關。測試時，為了各個擊破，一般編一段測一段(1)黑箱測試：只看輸入和程式結果，不管程式內部執行過程等價類劃分：程式的輸入至少有兩大類，分為有效輸入(可得出正確值)等價類，一為無效輸出等價類邊值分析：在等價類的基礎上用邊界值進行測試(2)白箱測試：也叫路徑測試。所有的語句必須執行一次以上，這是最起碼的要求。徹底些，每條路徑都要走到2.測試的經濟性測試是為了找出程式錯誤而執行程式的過程，應達到以下目標：沒有語法錯誤，·運行應當有結果典型用例結果正確典型有效數據結果正確，無效數據有預防措施對一切可能想得出的數據不出錯排錯(Debugging)也叫調試，排錯是消除程式中缺陷(bug)的過程：通過測試發現程式有錯找出出錯的位置(定位)分析出錯原因，並改正之。再測試消除找出的缺陷找到出錯原因後，改正錯誤要十分小心。盡可能找出所有的錯再改，以減少它們彼此因修改而產生的相互影響4.2軟體工程概述硬體技術高速發展，成本以十年兩位數的速度遞減，導致了對軟體的強烈需求。而軟體系統的規模越來越大、越來越複雜、開發週期越來越長，軟體的手工業生產方式使其成本急驟上升1968年軟體業界和科學工作者提出了軟體工程的思想：任何軟體都應當和其他產業的產品一樣，由專業人員製作(軟體中是系統分析員、高級程式員、程式員)，以系統的、工程的方法開發，並提供全方位的售後服務管理(不能因開發者離開調走而無人管)軟體工程以系統工程的方法製作軟體產品，它包括:軟體的系統(生存期)模型；與此模型相對應的各種規範和標準；為達到這些規範、標準的方法和工具；軟體開發的全面管理。軟體開發方法學的研究是軟體技術發展最活躍的因素。所謂方法學(Methodology)是一組規範了的方法，按這組方法執行，可以得到較為理想的結果。把這組方法施行過程標準化就是軟體開發標準根據美國電子工程學會(IEEE)的定義，軟體工程是以系統的、規範的、定量的方法應用於軟體的開發、運營和維護，以及對這些方法的研究4.3傳統的軟體工程 4.3.1生存週期模型瀑布式生存週期模型4.3.2需求分析

需求分析是摸清用戶需要用軟體解決什麼問題，這些問題有什麼特徵、特點？可以抽象為何種模型？然後定義軟體的規格說明，即指出什麼樣的軟體能滿足抽象出的模型。把對問題求解的描述變為對軟體的需求1.分析的任務(1)識別問題用戶要求具有的功能行為和特殊要求，軟體的功能、性能要求。用約定的符號或正文逐條列出。在整個分析間要和用戶充分協商(2)分析與綜合分析資訊的流向、類型，如何處理等問題，判定資訊處理的類型(3)建模：建立軟體解題模型，也是刻畫該問題的模型(4)寫規格說明：說明軟體在什麼條件下能做什麼事情2.需求階段的其他工作(1)可行性分析報告：論證本規格說明在給定時間、經費條件下、採用的技術和環境設施是可行的、儘量預計風險。對於較小系統，可行性分析寫入規格說明書的“背景”一段中，不另成文。(2)專案計畫列出本項目進度表，人員組織，經費支付，開發環境(可以利用軟體工具PERT圖完成)，以及招聘計畫，(上崗)培訓計畫。(3)初步用戶手冊：從用戶觀點描述一次規格說明，驗證需求定義是否遺漏，為正式用戶手冊打下基礎(4)評審由開發人員(高層)、用戶(業主)、同行專家(非本項目)對交付的文檔詳細評審，通過後才能投入下一階段。所有文檔一經審批，改動需重申請3.分析模型

作為軟體設計的基礎，分析模型必須反映用戶的要求，用它定義的需求集合應該易於驗證。圖形因表達概括能力強，資訊量大、直觀而成為通常的表示法(1)分析模型諸元素(2)數據流圖資訊在機內以數據形式出現，資訊流也是數據流。，數據流模型是一個很好的工具。數據流圖簡稱DFD，表示法很簡單，只有四種圖符雙線表示數據存儲加上箭頭指示，它成為:(3)控制流圖

擴充DFD圖為CFD(ControlFlowDiagram)圖把控制符號以虛線表示，數據利用雙箭頭表示連續輸入。虛箭頭上標明控制項(或事件)名。平行虛線表示控制項存儲，豎線模表示控制(規格)說明影印機的控制流圖(4)狀態轉移圖狀態轉移圖(state-TransitionDiagram)帶園角框表示某個狀態，狀態間用箭頭連線表示狀態轉移。箭頭線上標注事件及由事件引起的動作(5)實體關係圖

實體—關係圖(Entity-RelationshipDiagram簡稱ERD)的圖元是矩形框表示實體，中間寫數據對象名；實體間的連線即表示它們之間有關系，線上寫關係名。也可以把關系名寫在菱形框內。聯線兩端的符號表示在此關係下實體可以1對1出現，1對多，多對多出現。也可以指示此關係是可選的用E-R圖表示層次關係用E-R圖表示聚集關係(6)使用情況圖Use-case對於面向對象軟體，根據客觀世界發生的事情，描述可見對象間的交互行為，橢園表示行為，聯線表示事件，帶箭頭的線表示行為之間的關係(一般細化時加上)細化後：4.3.3設計根據分析得出的模型，以當今可用的技術和設施，作出決策：這個軟體總體是什麼結構(分幾部分，它們邏輯上有什麼關係)；它與使用者交互的介面是什麼？如何使用？它用到什麼內部和外部數據？以什麼演算法過程實現所要求的功能和性能？所以要設計出能運行的軟體要作到:數據設計整個軟體用到的數據體系結構設計整個軟體的程式組成過程設計每個組成如何實現介面設計用戶怎樣使用本軟體？軟體和環境如何相接1.數據設計：將需求分析中定義的數據模型進一步細化為軟體實現需要的數據結構，它對應為分析模型中的E-R模型和數據字典2.體系結構設計：主要目標是建立整個軟體的總體結構(1)細化DFD圖，每個處理框都可以細化為一子DFD圖。細化後作為上層模組，其中放共用數據，調用語句，細化後成為被調用的子模組的候選，可使用結構圖(StructuredChart簡稱SC)，其中→表示數據流向,方框表示模組(2)分析細化的DFD圖，調整SC。並非每一框都如上述變成模組。SC圖只說明邏輯上可以這樣去組成，但還要劃分和調整。原則：找出數據流圖中數據流向的邊界減少數據調用引起的模組間耦合(3)結構調整：邏輯上變成SC圖實際也可調整，例如一句話就可以表達的功能可以合併到另一模組，數據傳遞頻繁也應合在一個模組內。太長太大都要分小(4)調整時應考慮易於測試，越是獨立的模組越好測試，結構圖是測試計畫的根據3.介面設計：一般要考慮下麵幾點：管理輸入設備(滑鼠、鍵盤);確認用戶輸入;處理錯誤和顯示錯誤消息;提供輸入回饋(如輸入自動回聲);提供提示和幫助開發(開發者只要規定符號和提供幫助內容);窗口、域的顯示，重疊和內容滾展;提供和應用程式的介面;介面管理功能和應用程式隔離;允許用戶定制介面。4.過程設計完成數據、體系結構、介面設計之後，就按處理規格說明，或控制規格說明，或狀態轉移圖，一一寫出過程程式。選定或設計相應的演算法作出設計。此時並非用某種程式設計語言，而是類_xxx語言、PDL、細化圖形（設計詳細的結構化流程圖）4.3.4軟體測試軟體品質要經過驗證(Verification)和確認(Validation)過程，簡稱V&V。驗證是證實軟體正確地實現了某些功能(所作的軟體正確)；確認是證實所作軟體能夠滿足用戶的要求1.測試策略(1)測試的種類(2)單元測試對一個模組或幾個模組組成的小功能單元作測試，一般以白箱測試為主，多個模組可以並行進行測試用例應覆蓋以下內容:介面：內介面指本模組型構及對樁模組調用，參數個數，類型均應匹配。外界面指本模組有直接的I/O，則有關輸入/輸出檔開、關，數據格式、類型匹配與否均應測試。模組的數據結構：類型是否不正確、不一致？初始化、缺省值使用情況；變數名拼錯；上下溢出等數據異常，測試能否正確處理，即在一個演算法的所有執行步驟上數據存儲能否保證一致。個別情況下還要測全局數據與局部數據結構的相互影響。邊界條件：保證在邊界值的情況下模組依然可以正確操作，值出界時要有正確反應。獨立路徑：保證至少所有語句都要執行一次以上，每個條件或子條件都執行一次更好。錯誤處理路徑：不管程式有無異常處理都要察看出錯處理路徑。在程式易出錯之處如類型比較、轉換錯，迴圈控制變數被賦值等，設置用例特別要考察是否死機。(3)集成測試--最終將本項目所有模組總成交出完整程式產品由底向上集成:最底層的模組叫原子模組優點是總是測試“真實”模組，易於設計較充分的用例。缺點是不到最後總沒有一個“完整”的概念。自頂向下集成:從總控模組(主程序)，處處設樁(凡有調用子模組處)，測完一塊向下走一塊。因而必然是增量式。回歸測試：將測試過的用例的子集重新執行，以確保新的變更不會產生不希望的邊界效應。主要的工作是收集有代表性的用例子集，可以人工整理，也可用找回歸(captureplayback)工具輔助完成。整理出的回歸測試集(suite)包含以下內容:程式的每種功能的典型樣板用例(為以後測試用)；對每種更改特別敏感的用例；已改