软体工程导论课件.ppt
第8章 軟體工程導論,內容,8.1 節介紹軟體工程的概念和專用術語8.2 節討論規格書的編寫方式8.3 節簡單地紹軟體設計的程序8.4 節介紹物件導向的軟體設計方式8.5 節討論個別元件和完整系統的測試策略,8.1 軟體工程觀念的介紹,8.1.1 節將描述軟體工程技術發展過程中所遭遇的一些問題8.1.2 節討論軟體開發程序中的各個階段8.1.3 節將深入探討軟體維護和發展的一些重要階段,8.1.1 背景與定義,軟體工程之工具與方法的發展源起於1960 年代，主要是希望能夠解決所謂的軟體危機（software crisis）。隨著軟體系統的逐漸龐大以及趨於複雜，為了解決衍生的成本、生產力以及可靠度的問題，軟體工程學科因應而生。,軟體工程的定義,為了在電腦上獲得有效率而且經濟的軟體，所建立並使用之健全的工程原則（Bauer,1972）在建立軟體系統程序中，可以降低軟體成本和複雜度，並提高可靠度和彈性的技術（Ramamoorthy and Siyan,1983）；以系統化、嚴謹、量化等方式，來開發、操作和維護軟體；也就是將工程原則應用於軟體之上（IEEE,1990）。,8.1.2 軟體發展程序,瀑布軟體生命週期模型（waterfall software life-cycle model）第一階段是需求分析（requirements analysis），主要是確定軟體系統必須執行的項目。第二階段的系統規格（system specification）會以軟體開發的術語，明確地描述所需的系統。,瀑布軟體生命週期模型,第三階段是系統設計（system design），此階段開始提出解決問題之道。第四階段是實作（implementation）最後一個階段是系統測試，通常是軟體開發過程中成本最高，也是最耗時的部份。根據估計，測試需要耗費整體開發工作量的30%至50%（Marciniak,1994）,圖8.1 軟體生命週期（瀑布模型）,8.1.3 軟體維護與發展,。一個系統在長期的使用時間中，總是無可避免地不斷更改以符合需求的變動。根據某些評估，維護成本將佔軟體總成本的三分之二（Sommerville,1996）。,四種主要類別,修正性維護（Corrective maintenance）是修改最初系統設計和實作中的錯誤 即系統中不符合原先需求的狀況。完美性維護（Perfective maintenance）是改善系統，例如，使系統變得更有效率或者改善使用者介面。調適性維護（Adaptive maintenance）是為了迎合環境變化以及符合使用者需求所進行的系統改善。增強（Enhancement）是增加新的功能至系統中，這些功能並非原先的需求，而且也不是原先的設計。,8.2 系統規格,8.2.1 節將討論規格所應具備的特質，並審視規格與軟體發展中其他部分之間的關係。8.2.2 節將說明數種不同類型的規格，並以一個簡易的組譯器範例來說明這些規格。8.2.3 節將討論錯誤處理的一些重要議題，並說明系統規格與這些議題的相關性。,8.2.1 系統規格的目標,需求文件（requirements document）主要以使用者為出發點，是一種較高層次的觀點，通常包含大多數重要的細節。著重的是系統要執行什麼，而不是如何完成。系統規格同樣也是系統測試階段的基礎,8.2.2 規格的型態,以一個組譯器為例介紹系統規格因為規格涉及一些條件或條件的組合，經常會發現無法使用如圖8.2 的簡單敘述來表達。決策表（decision table）表格的上半部是一組條件，下半部是依照條件所採取的相關動作。,圖8.2 程式規格範例,圖8.3 決策表規格範例,8.2.3 錯誤狀況,在正確的規格中，應明訂哪些類型的輸入是不被接受的回應錯誤較好的方式是產生錯誤訊息，並且繼續執行下去。回應錯誤較好的方式是產生錯誤訊息，並且繼續執行下去。,圖8.4 規格衍生的輸入錯誤範例,8.3 程序系統設計,8.3.1 節介紹資料流程圖（data flow diagrams）8.3.2 節將討論模組設計（modular design）的一般原則和目的8.3.3 節描述如何將資料流程圖劃分為數個模組（module）的方法8.3.4 節將描述模組之間和模組與資料物件之間如何互動，以及這些介面如何文件化,8.3.1 資料流程圖,主要是用於表示輸入（input）經由中間資料物件的處理，直到最後系統輸出的資訊流程和轉換過程。可以表示軟體系統中儲存體與處理過程之間的資訊流動狀況主要顯示系統中的資料物件（data objects），例如檔案、變數以及資料結構主要的處理動作（processing actions），包含移動、建立或者轉換資料等，以及物件與動作之間的資料流動。,基本表示法,長方格表示處理動作圓形則表示資料物件箭頭表示物件和動作之間的資訊流動,圖8.5 資料流程圖範例,圖8.6 組譯器的高層次資料流程圖,圖8.7 調整後的組譯器資料流程圖,圖8.7 調整後的組譯器資料流程圖,圖8.7 調整後的組譯器資料流程圖,8.3.2 模組化設計的一般原則,模組化設計程序的目的，是希望進行符合系統規格的軟體設計。然而，設計一個容易實作、了解和維護的系統，也是同樣的重要。模組應具備高內聚力模組之間應具備低耦合性,8.3.3 資料流程圖的分割,模組化設計程序可以將資料流程圖分割為多個模組。定義這些模組時，同時也定義了模組與物件所用資料結構之間的介面。一種常用的分割方法，是自上而下的設計（top-down design）。二種標準方法功能執行的順序功能執行的型態,圖8.8 組譯器之資料流程圖的二階段分割,圖8.9 符號表的隔離設計,圖8.10 組譯器的模組化設計,8.3.4 模組介面,圖8.10 說明如何將一個問題分解成為一些模組的集合。然而，並未指出模組的執行順序，或者模組之間的介面模組結構中資料物件的配置，是一項相當重要的議題。,圖8.11(a)組譯器模組的呼叫結構,圖8.11(b)組譯器模組的參數和呼叫順序,8.4 物件導向系統設計,8.4.1 節將介紹物件導向的基本原則和概念。8.4.2 節說明如何將物件導向方式套用於組譯器的設計上。,8.4.1 物件導向程式原則,程式是由物件，而不是由程序所組成的。一個物件中包含一些資料以及處理資料的一些動作，而這些動作可供其他程式的引用。物件所包含的資料值儲存於實體變數中。通常外部物件不能存取這些實體變數。程式其它部份只能呼叫物件所定義的方法，來檢視或者運用儲存於物件中的資料。,8.4.1 物件導向程式原則,封裝（encapsulation）:抽象化（data abstraction）及資訊隱藏（data hiding）每個物件即是某個類別的實體（instance）。一個類別可視為是定義實體變數和方法的一個範本，可以由一個類別來建立許多的物件利用子類別和繼承的觀念，可以重複使用已撰寫完成的程式碼多型（polymorphism）是最為強大的方法之一,圖8.12 類別之間關係的範例,8.4.2 物件導向設計的組譯器,Booch（1994）提出二種主要的發展程序，稱為微觀（micro）和宏觀（macro）。,宏觀程序,建立軟體的需求（概念）。發展系統行為的全面性模組（分析）。建立實作的架構（設計）。按部就班的進行實作（進展）。對於交付的系統進行持續的管理（維護）。,微觀程序,識別系統的物件和類別。建立物件和類別的行為和其他屬性 如每個類別的方法。分析類別與物件之間的關係 如聯集、繼承和多型的使用。具體說明類別和物件的實作 如每一個資料結構和演算法。,圖8.13 組譯器之物件的主要規格,圖8.13 組譯器之物件的主要規格,圖8.13 組譯器之物件的主要規格,圖8.13 組譯器之物件的主要規格,圖8.13 組譯器之物件的主要規格,圖8.13 組譯器之物件的主要規格,圖8.14 組譯器的物件圖,圖8.15 組譯器的互動圖,8.5 系統測試方法,8.5.1 節介紹一些名詞，並且簡短說明軟體測試的各個階段。8.5.2 和8.5.3節討論二種常用測試方式。,8.5.1 測試的階段,單位測試（unit test）階段:從系統中抽離個別模組出來進行測試。黑箱測試（black boxtesting）配合模組的測試案例（test case）是依據規格所產生，而不考量程式碼白箱測試（white box testing）設計一些測試案例，以強迫執行模組中的某些敘述或某些順序的敘述,8.5.1 測試的階段,整合測試（integration testing）結合一些模組來進行測試，以確定彼此的介面是否運作正確。模組納入系統的方式通常是採用由下而上（bottom-up）或者由下而上（top-down）系統測試（system testing 確認整個系統是否符合規格（specifications）和需求（requirements）Alpha 測試；Beta 測試,8.5.2 由下而上測試,以階層式的呼叫架構為基礎。首先測試位於最低階層的模組（離根部最遠的模組），其次為較高層，以此類推。對於單位測試和模組整合而言，由下而上測試是最常使用的方法,圖8.16 Access_symtab 模組的測試驅動程式,8.5.3 由上而下測試,由階層架構中，最高階層的模組開始進行由上而下測試時，必須設計末端程式（stub）來模擬低層次的模組。由上而下測試能夠較早偵測到模組間呼叫介面的錯誤。實務的情況下，會採用由下而上和由上而下的混合方式,圖8.17 組譯器中模組末端程式的範例,
