软体工程导论课件

第8章軟體工程導論第8章軟體工程導論內容8.1節介紹軟體工程的概念和專用術語8.2節討論規格書的編寫方式8.3節簡單地紹軟體設計的程序8.4節介紹物件導向的軟體設計方式8.5節討論個別元件和完整系統的測試策略內容8.1節介紹軟體工程的概念和專用術語8.1軟體工程觀念的介紹8.1.1節將描述軟體工程技術發展過程中所遭遇的一些問題8.1.2節討論軟體開發程序中的各個階段8.1.3節將深入探討軟體維護和發展的一些重要階段8.1軟體工程觀念的介紹8.1.1節將描述軟體工程技術發8.1.1背景與定義軟體工程之工具與方法的發展源起於1960年代，主要是希望能夠解決所謂的「軟體危機」（softwarecrisis）。隨著軟體系統的逐漸龐大以及趨於複雜，為了解決衍生的成本、生產力以及可靠度的問題，軟體工程學科因應而生。8.1.1背景與定義軟體工程之工具與方法的發展源起於196軟體工程的定義為了在電腦上獲得有效率而且經濟的軟體，所建立並使用之健全的工程原則（Bauer,1972）在建立軟體系統程序中，可以降低軟體成本和複雜度，並提高可靠度和彈性的技術（RamamoorthyandSiyan,1983）；以系統化、嚴謹、量化等方式，來開發、操作和維護軟體；也就是將工程原則應用於軟體之上（IEEE,1990）。軟體工程的定義為了在電腦上獲得有效率而且經濟的軟體，所建立並8.1.2軟體發展程序瀑布軟體生命週期模型（waterfallsoftwarelife-cyclemodel）第一階段是需求分析（requirementsanalysis），主要是確定軟體系統必須執行的項目。第二階段的系統規格（systemspecification）會以軟體開發的術語，明確地描述所需的系統。8.1.2軟體發展程序瀑布軟體生命週期模型（waterfa瀑布軟體生命週期模型第三階段是系統設計（systemdesign），此階段開始提出解決問題之道。第四階段是實作（implementation）最後一個階段是系統測試，通常是軟體開發過程中成本最高，也是最耗時的部份。根據估計，測試需要耗費整體開發工作量的30%至50%（Marciniak,1994）瀑布軟體生命週期模型第三階段是系統設計（systemdes圖8.1軟體生命週期（瀑布模型）圖8.1軟體生命週期（瀑布模型）8.1.3軟體維護與發展。一個系統在長期的使用時間中，總是無可避免地不斷更改以符合需求的變動。根據某些評估，維護成本將佔軟體總成本的三分之二（Sommerville,1996）。8.1.3軟體維護與發展。一個系統在長期的使用時間中，總是四種主要類別修正性維護（Corrective

maintenance）是修改最初系統設計和實作中的錯誤─即系統中不符合原先需求的狀況。完美性維護（Perfectivemaintenance）是改善系統，例如，使系統變得更有效率或者改善使用者介面。調適性維護（Adaptivemaintenance）是為了迎合環境變化以及符合使用者需求所進行的系統改善。增強（Enhancement）是增加新的功能至系統中，這些功能並非原先的需求，而且也不是原先的設計。四種主要類別修正性維護（Correctivemainten8.2系統規格8.2.1節將討論規格所應具備的特質，並審視規格與軟體發展中其他部分之間的關係。8.2.2節將說明數種不同類型的規格，並以一個簡易的組譯器範例來說明這些規格。8.2.3節將討論錯誤處理的一些重要議題，並說明系統規格與這些議題的相關性。8.2系統規格8.2.1節將討論規格所應具備的特質，並審8.2.1系統規格的目標需求文件（requirementsdocument）主要以使用者為出發點，是一種較高層次的觀點，通常包含大多數重要的細節。著重的是系統要執行什麼，而不是如何完成。系統規格同樣也是系統測試階段的基礎8.2.1系統規格的目標需求文件（requirements8.2.2規格的型態以一個組譯器為例介紹系統規格因為規格涉及一些條件或條件的組合，經常會發現無法使用如圖8.2的簡單敘述來表達。決策表（decisiontable）表格的上半部是一組條件，下半部是依照條件所採取的相關動作。8.2.2規格的型態以一個組譯器為例介紹系統規格圖8.2程式規格範例圖8.2程式規格範例圖8.3決策表規格範例圖8.3決策表規格範例8.2.3錯誤狀況在正確的規格中，應明訂哪些類型的輸入是不被接受的回應錯誤較好的方式是產生錯誤訊息，並且繼續執行下去。回應錯誤較好的方式是產生錯誤訊息，並且繼續執行下去。8.2.3錯誤狀況在正確的規格中，應明訂哪些類型的輸入是不圖8.4規格衍生的輸入錯誤範例圖8.4規格衍生的輸入錯誤範例8.3程序系統設計8.3.1節介紹資料流程圖（dataflowdiagrams）8.3.2節將討論模組設計（modulardesign）的一般原則和目的8.3.3節描述如何將資料流程圖劃分為數個模組（module）的方法8.3.4節將描述模組之間和模組與資料物件之間如何互動，以及這些介面如何文件化8.3程序系統設計8.3.1節介紹資料流程圖（data8.3.1資料流程圖主要是用於表示輸入（input）經由中間資料物件的處理，直到最後系統輸出的資訊流程和轉換過程。可以表示軟體系統中儲存體與處理過程之間的資訊流動狀況主要顯示系統中的資料物件（dataobjects），例如檔案、變數以及資料結構主要的處理動作（processingactions），包含移動、建立或者轉換資料等，以及物件與動作之間的資料流動。8.3.1資料流程圖主要是用於表示輸入（input）經由中基本表示法長方格表示處理動作圓形則表示資料物件箭頭表示物件和動作之間的資訊流動基本表示法長方格表示處理動作圖8.5資料流程圖範例圖8.5資料流程圖範例圖8.6組譯器的高層次資料流程圖圖8.6組譯器的高層次資料流程圖圖8.7調整後的組譯器資料流程圖圖8.7調整後的組譯器資料流程圖圖8.7調整後的組譯器資料流程圖圖8.7調整後的組譯器資料流程圖圖8.7調整後的組譯器資料流程圖圖8.7調整後的組譯器資料流程圖8.3.2模組化設計的一般原則模組化設計程序的目的，是希望進行符合系統規格的軟體設計。然而，設計一個容易實作、了解和維護的系統，也是同樣的重要。模組應具備高內聚力模組之間應具備低耦合性8.3.2模組化設計的一般原則模組化設計程序的目的，是希望8.3.3資料流程圖的分割模組化設計程序可以將資料流程圖分割為多個模組。定義這些模組時，同時也定義了模組與物件所用資料結構之間的介面。一種常用的分割方法，是「自上而下的設計」（top-downdesign）。二種標準方法功能執行的順序功能執行的型態8.3.3資料流程圖的分割模組化設計程序可以將資料流程圖分圖8.8組譯器之資料流程圖的二階段分割圖8.8組譯器之資料流程圖的二階段分割圖8.9符號表的隔離設計圖8.9符號表的隔離設計圖8.10組譯器的模組化設計圖8.10組譯器的模組化設計8.3.4模組介面圖8.10說明如何將一個問題分解成為一些模組的集合。然而，並未指出模組的執行順序，或者模組之間的介面模組結構中資料物件的配置，是一項相當重要的議題。8.3.4模組介面圖8.10說明如何將一個問題分解成為一圖8.11(a)組譯器模組的呼叫結構圖8.11(a)組譯器模組的呼叫結構圖8.11(b)組譯器模組的參數和呼叫順序圖8.11(b)組譯器模組的參數和呼叫順序8.4物件導向系統設計8.4.1節將介紹物件導向的基本原則和概念。8.4.2節說明如何將物件導向方式套用於組譯器的設計上。8.4物件導向系統設計8.4.1節將介紹物件導向的基本原8.4.1物件導向程式原則程式是由物件，而不是由程序所組成的。一個物件中包含一些資料以及處理資料的一些動作，而這些動作可供其他程式的引用。物件所包含的資料值儲存於「實體變數」中。通常外部物件不能存取這些「實體變數」。程式其它部份只能呼叫物件所定義的「方法」，來檢視或者運用儲存於物件中的資料。8.4.1物件導向程式原則程式是由物件，而不是由程序所組成8.4.1物件導向程式原則「封裝」（encapsulation）:抽象化（dataabstraction）及資訊隱藏（datahiding）每個物件即是某個類別的「實體」（instance）。一個類別可視為是定義實體變數和方法的一個範本，可以由一個類別來建立許多的物件利用子類別和繼承的觀念，可以重複使用已撰寫完成的程式碼多型（polymorphism）是最為強大的方法之一8.4.1物件導向程式原則「封裝」（encapsulati圖8.12類別之間關係的範例圖8.12類別之間關係的範例8.4.2物件導向設計的組譯器Booch（1994）提出二種主要的發展程序，稱為「微觀」（micro）和「宏觀」（macro）。8.4.2物件導向設計的組譯器Booch（1994）提出二宏觀程序建立軟體的需求（概念）。發展系統行為的全面性模組（分析）。建立實作的架構（設計）。按部就班的進行實作（進展）。對於交付的系統進行持續的管理（維護）。宏觀程序建立軟體的需求（概念）。微觀程序識別系統的物件和類別。建立物件和類別的行為和其他屬性─如每個類別的方法。分析類別與物件之間的關係─如聯集、繼承和多型的使用。具體說明類別和物件的實作─如每一個資料結構和演算法。微觀程序識別系統的物件和類別。圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.13組譯器之物件的主要規格圖8.14組譯器的物件圖圖8.14組譯器的物件圖圖8.15組譯器的互動圖圖8.15組譯器的互動圖8.5系統測試方法8.5.1節介紹一些名詞，並且簡短說明軟體測試的各個階段。8.5.2和8.5.3節討論二種常用測試方式。8.5系統測試方法8.5.1節介紹一些名詞，並且簡短說明8.5.1測試的階段「單位測試」（unittest）階段:從系統中抽離個別模組出來進行測試。「黑箱測試」（blackboxtesting）配合模組的「測試案例」（testcase）是依據規格所產生，而不考量程式碼「白箱測試」（whiteboxtesting）設計一些測試案例，以強迫執行模組中的某些敘述或某些順序的敘述8.5.1測試的階段「單位測試」（unittest）階段8.5.1測試的階段「整合測試」（integrationtesting）結合一些模組來進行測試，以確定彼此的介面是否運作正確。模組納入系統的方式通常是採用「由下而上」（bottom-up）或者「由下而上」（top-down）「系統測試」（systemtesting確認整個系統是否符合規格（specifications）和需求（requirements）「Alpha測試」；「Beta測試」8.5.1測試的階段「整合測試」（integration8.5.2由下而上測試以階層式的呼叫架構為基礎。首先測試位於最低階層的模組（離根部最遠的模組），其次為較高層，以此類推。對於單位測試和模組整合而言，「由下而上測試」是最常使用的方法8.5.2由下而上測試以階層