軟體工程導論 張海藩（第五版） 整理

 

              第一章，軟體工程導論
一、軟體工程是指導計算機軟體開發和維護的一門工程學科
二、件工程的七條基本原理：
　　   1. 用分階段的生命週期計劃嚴格管理
       2. 堅持進行階段評審
       3. 實行嚴格的產品控制
       4. 採用現代程式設計技術
       5. 結果應能清楚地審查
　   　6. 開發小組的人員應該少而精
       7. 承認不斷改進軟體工程實踐的必要性
三、軟體工程方法學包含3個要素：方法、工具和過程。
方法是完成軟體開發的各項任務的技術方法，回答"怎樣做"
的問題；工具是為運用方法而提供的自動的或半自動的軟體
工程支撐環境；過程是為了獲得高質量的軟體所需要完成的
一系列任務的框架，它規定了完成各項任務的工作步驟。

四、 軟體工程方法學： 傳統方法學、物件導向方法學.

五、 軟體生命週期：軟體定義、軟體開發和執行維護(也稱
為軟體維護)3個時期組成。
　　

　1軟體定義主要任務：問題定義、可行性研究和需求分析

　2開發時期主要任務：總體設計，詳細設計，編碼和單元
測試，綜合測試（前兩者為系統設計，後兩者為系統實現）

　3維護時期主要任務：通過各種維護性活動使系統持久地
滿足使用者的需求，通常有四類維護：1，改正性維護，也就
是診斷和改正在使用過程中發現的軟體錯誤；，2適應性維
護，即修改軟體以適應環境的變化；3，完善性維護，即根
據使用者的需求改進若擴充軟體使它更完善,4，預防性維護，
即修改軟體，為將來的維護活動預先做準備。

　
//①問題定義階段必須回答的關鍵問題是："要解決的問題
是什麼？"②可行性研究~：對於上一個階段所確定的問題
有行得能的解決辦法嗎？③需求分析：確定目標系統必須具
備哪些工能 ④總體設計：概括地說，應該怎樣實現目標系
統？⑤詳細設計：應該怎樣具體地實現這個系統呢？⑥編碼
和單元測試：寫出正確的容易理解、容易維護的程式模組 ⑦
綜合測試：通過各種型別測（及相應的除錯）使軟體達到預
定的要求，最基本的測試是整合測試和驗收測試，整合測試
是根據設計的軟體結構，把經過單元測試檢驗的模組按某種
選定的策略裝配起來，在裝配過程中對程式進行必要的測
試；驗收測試則是按照規格說明的規定，由使用者對目標系統
驗收
　

六、 軟體過程的各種模型：
1）瀑布模型(1.階段間具有順序行和依賴性2，推遲實
現的觀點，3，質量保證的觀點)

2）快速原型模型（快速建立起來的可以在計算機上運
行的程式，它所能完成的功能往往是最終產品能完成
的功能的一個子集）
　3）增量模型（把軟體產品作為一系列的增量構件來設
計，編碼，整合和測試。每個構件由多個相互作用的模組
構成並能完成特定的功能）
　4）螺旋模型（使用原型及其他方法來儘量降低風險，
風險驅動）
　
　5）噴泉模型
　
　
              第二章  可行性研究

一、可行性研究的任務
目的：就是用最小的代價在儘可能短的時間內確定問題是否
能夠解決。

分析幾種主要的可能解法的利弊，從而判斷原定的系統規模
和目標是否現實，系統完成後所能帶來的效益是否大到值得
投資開發這個系統的程度

二、可行性
   (1) 技術可行性  使用現有的技術能實現這個系統嗎?
   (2) 經濟可行性  這個系統的經濟效益能超過它的開發
成本嗎？
   (3) 操作可行性  系統的操作方式在這個使用者組織內行
得通嗎?
   (4)必要時還要從法律，社會效益等方面研究。（可選）
  
三、可行性研究過程
1. 複查系統規模和目標、2. 研究目前正在使用的系統
3. 匯出新系統的高層邏輯模型、4. 進一步定義問題
5. 匯出和評價供選擇的解法、6. 推薦行動方針
7. 草擬開發計劃、8. 書寫文件提交審查

四、系統流程圖：是概括地描繪物理系統的傳統工具。
　 
    資料流圖：  描繪資訊流和資料從輸入移動到輸出的過
程中所經受的變換。資料流圖是系統邏輯功能的圖形表示
　
　  資料字典：資料字典是關於資料的資訊的集合，也就是
對資料流圖中包含的所有元素的定義的集合。

一般說來，資料字典應該由對下列4類元素的定義組成：
(1)資料流
(2)資料流分量(即資料元素)
(3)資料儲存
(4)處理
       
 

          第三章    需求分析
  需求分析是軟體定義時期的最後一個階段，它的基本任務
是準確地回答"系統必須做什麼"這個問題。（可選）

一、 需求分析的任務還不是確定系統怎樣完成它的工作，
而僅僅是確定系統必須完成哪些工作，也就是對目標
系統提出完整、準確、清晰、具體的要求。

二、3.1.1 確定對系統的綜合要求
1. 功能需求、2. 效能需求、3. 可靠性和可用性需求
4. 出錯處理需求、5. 介面需求、6. 約束
7. 逆向需求、8. 將來可能提出的要求

三、3.1.2  分析系統的資料要求
   分析系統的資料要求通常採用建立資料模型的方法
3.1.3  匯出系統的邏輯模型
  綜合上述兩項分析的結果可以匯出系統的詳細的邏輯模
型，通常用資料流圖、實體-聯絡圖、狀態轉換圖、資料字
典和主要的處理演算法描述這個邏輯模型。

 

四、獲取需求的方法
3.2.1  訪談
3.2.2  面向資料流自頂向下求精
3.2.3  簡易的應用規格說明技術
3.2.4  快速建立軟體原型

 

五、3.3.1  分析建模
需求分析過程應該建立3種模型，它們分別是資料模型、功
能模型和行為模型。

3.4節將介紹的實體-聯絡圖，描繪資料物件及資料物件之間
的關係，是用於建立資料模型的圖形。
2.4節講過的資料流圖，描繪當資料在軟體系統中移動時被
變換的邏輯過程，指明系統具有的變換資料的功能，因此，
資料流圖是建立功能模型的基礎。

3.6節將介紹的狀態轉換圖(簡稱為狀態圖)，指明瞭作為外
部事件結果的系統行為。為此，狀態轉換圖描繪了系統的各
種行為模式(稱為"狀態")和在不同狀態間轉換的方式。狀態
轉換圖是行為建模的基礎。

3.4  實體-聯絡圖（資料物件、屬性、聯絡）
3.6  狀態轉換圖（狀態、事件、符號）
3.7  其他圖形工具、3.7.1  層次方框圖
3.7.2  Warnier圖、3.7.3  IPO圖

六、驗證軟體需求（可選）
(1) 一致性 所有需求必須是一致的，任何一條需求不能和
其他需求互相矛盾。
(2) 完整性 需求必須是完整的，規格說明書應該包括使用者
需要的每一個功能或效能。
(3) 現實性 指定的需求應該是用現有的硬體技術和軟體技
術基本上可以實現的。對硬體技術的進步可以做些預測，對
軟體技術的進步則很難做出預測，只能從現有技術水平出發
判斷需求的現實性。
(4) 有效性 必須證明需求是正確有效的，確實能解決使用者
面對的問題。

               第4章  形式化說明技術（不考）
有窮狀態機、petri網、z語言

               第5章  總體設計
1，總體設計又稱為概要設計或初步設計。它的基本目的就
是回答"概況地說，系統應該如何實現？"這個問題。（可
選）

劃分出組成系統的物理元素（黑盒子級）--程式、檔案、
資料庫、人工過程和文件等

2， 總體設計過程通常由兩個主要的階段組成：系統設計階
段，確定系統地具體實現方案；結構設計階段，確定軟體結
構。（可選）

3、設計軟體的結構
      1、確定系統中每個程式是由哪些模組組成
　　　2、這些模組相互間的關係
　　　
二、設計過程包括九個步驟：

設想供選擇的方案、選取合理的方案、推薦最佳方案
功能分解、設計軟體結構、 設計資料庫
制定測試計劃、書寫文件、審查和複審

三、 設計原理：模組化、 抽象、逐步求精  資訊隱藏和局
部化、模組獨立

四、模組獨立性的度量：
　兩個定性標準度量：內聚和耦合
耦合：衡量不同模組間互相依賴(連線)的緊密程度
內聚：衡量一個模組內部各個元素彼此結合的緊密程度

五、耦合
資料耦合 (Data Coupling)（低耦合）
特徵耦合
控制耦合 (Control Coupling) 
公共環境耦合（Common Coupling）
內容耦合 (Content Coupling)（高耦合）

六、設計原則
耦合是影響軟體複雜程度的一個重要因素。
     儘量使用資料耦合、少用控制耦合和特徵耦合，限制
公共環境耦合的範圍，完全不用內容耦合。
    
七、模組內聚

八、設計原則，如果給上述7種內聚的優劣評分，將得到如
下結果：
功能內聚 10分    順序內聚 9分
通訊內聚 7分    過程內聚  5分
時間內聚 3分     邏輯內聚  1分
偶然內聚 0分  
力爭做到高內聚、識別提高低內聚的模組

九、啟發規則：
1. 改進軟體結構提高模組獨立性2. 模組規模應該適中
3. 深度、寬度、扇出和扇入都應適當4. 模組的作用域應該
在控制域之內5.力爭降低模組介面的複雜程度
6. 設計單入口單出口的模組7. 模組功能應該可以預測

十、描繪軟體結構的圖形工具（可選）
 層次圖    HIPO圖    結構圖
 面向資料流的設計方法：資訊流的型別：變換流 、事務流
分析步驟：
第1步 複查基本系統模型、第2步 複查並精化資料流圖
第3步 確定資料流圖具有變換特性還是事務特性。
第4步 確定輸入流和輸出流的邊界，從而孤立出變換中心。
第5步 完成"第一級分解"。變換型資料流圖被對映成一個
輸入、變換和輸出的資訊處理過程。
第6步 完成"第二級分解"。把資料流圖中的每個處理對映
成軟體結構中一個適當的模組。
第7步 使用設計度量和啟發式規則對第一次分割得到的軟
件結構進一步精化。

                    第6章  詳細設計

6.1目標：系統的具體實現。
    6.1.1應該得出對目標系統的精確描述，從而在編碼階段可
以把這個描述直接翻譯成用某種程式設計語言書寫的程式。
    6.1.2結構程式設計的經典定義如下所述："如果一個程式的
程式碼塊僅僅通過順序、選擇和迴圈這3種基本控制結
構進行連線，並且每個程式碼塊只有一個入口和一個出
口，則稱這個程式是結構化的。"
    6.13 如果只允許使用順序、IF-THEN-ELSE型分支和
DO-WHILE型迴圈這3種基本控制結構，則稱為經典
的結構程式設計；
    6.1.4如果除了上述3種基本控制結構之外，還允許使用
DO-CASE型多分支結構和DO-UNTIL型迴圈結構，
則稱為擴充套件的結構程式設計；
    6.1.5 如果再加上允許使用LEAVE(或BREAK)結構，則稱為
修正的結構程式設計。

6.2   人機介面設計: 1. 系統響應時間、 2. 使用者幫助設施
        3. 出錯資訊處理、4. 命令互動

6.3  過程設計的工具：
　   程式流程圖、盒圖(N-S圖)、 PAD圖、判定表
    判定樹、 過程設計語言

 

6.4 面向資料結構的設計方法：
      6.4.1 Jackson方法和Warnier方法是最著名的兩個面向資料
結構的設計方法.
 使用面向資料結構的設計方法，當然首先需要分析確
定資料結構，並且用適當的工具清晰地描繪資料結構。
 Jackson方法：
       
        (1) 分析並確定輸入資料和輸出資料的
邏輯結構，並用Jackson圖描繪這些資料結構。
 
        (2) 找出輸入資料結構和輸出資料結構中有對應關係
的資料單元。所謂有對應關係是指有直接的因果關係，
在程式中可以同時處理的資料單元(對於重複出現的數
據單元必須重複的次序和次數都相同才可能有對應關
系)。
 (3) 用下述3條規則從描繪資料結構的Jackson圖匯出
描繪程式結構的Jackson圖：
        第一，為每對有對應關係
的資料單元，按照它們在資料結構圖中的層次在程式
結構圖的相應層次畫一個處理框(注意，如果這對資料
單元在輸入資料結構和輸出資料結構中所處的層次不
同，則和它們對應的處理框在程式結構圖中所處的層
次與它們之中在資料結構圖中層次低的那個對應)；
 第二，根據輸入資料結構中剩餘的每個資料單元所處
的層次，在程式結構圖的相應層次分別為它們畫上對
應的處理框；
 第三，根據輸出資料結構中剩餘的每個資料單元所處
的層次，在程式結構圖的相應層次分別為它們畫上對
應的處理框。
 在匯出程式結構圖的過程中，由於改進的Jackson圖規
定在構成順序結構的元素中不能有重複出現或選擇出
現的元素，因此可能需要增加中間層次的處理框
 (4) 列出所有操作和條件(包括分支條件和迴圈結束條
件)，並且把它們分配到程式結構圖的適當位置。
 (5) 用偽碼錶示程式

6.5  程式複雜程度的定量度量： McCabe方法、Halstead方法

 

　                第7章  實現
7.1通常把編碼和測試統稱為實現。

7.2所謂編碼就是把軟體設計結果翻譯成用某種程式設計
語言書寫的程式。

7.3測試的目的就是在軟體投入生產性執行之前，儘可能
多地發現軟體中的錯誤。

單元測試、綜合測試

7.4軟體測試的目標：(1) 測試是為了發現程式中的錯誤而
執行程式的過程；(2) 好的測試方案是極可能發現迄今為止
尚未發現的錯誤的測試方案；(3) 成功的測試是發現了至今
為止尚未發現的錯誤的測試。
測試方法：
n 黑盒測試： 如果已經知道了產品應該具有的功能，可
以通過測試來檢驗是否每個功能都能正常使用；
n 白盒測試：如果知道產品的內部工作過程，可以通過
測試來檢驗產品內部動作是否按照規格說明書的規定
正常進行。

7.5  測試步驟：（重點）
1模組測試、2 子系統測試、3. 系統測試
4. 驗收測試、5. 平行執行

7.6整合測試：
1、自頂向下整合2、自底向上整合
 
7.7 白盒測試技術   邏輯覆蓋：

1. 語句覆蓋2. 判定覆蓋3. 條件覆蓋4. 判定/條件覆蓋
5. 條件組合覆蓋6. 點覆蓋7. 邊覆蓋8 . 路徑覆蓋

控制結構測試：
1. 基本路徑測試：
第一步，根據過程設計結果畫出相應的流圖。
第二步，計算流圖的環形複雜度。
第三步，確定線性獨立路徑的基本集合。
第四步，設計可強制執行基本集合中每條路徑的測試用例。

 

7.8 黑盒測試技術：

等價劃分、邊界值分析、錯誤推測
軟體可靠性：基本概念、估算平均無故障時間的方法
4. 估計錯誤總數的方法：
1) 植入錯誤法 2) 分別測試法
 
第8章 維護

8.1  軟體維護的定義：
　　軟體已經交付使用之後，為了改正錯誤或者滿足新的需
要而修改軟體的過程。
　　
改正性維護：在任何大型程式的使用期間，使用者必然會發
現程式錯誤，並且把他們遇到的問題報告給維護人員。
適應性維護:也就是為了和變化了的環境適當地配合而進行
的修改軟體的活動，是既必要又經常的維護活動。
完善性維護：在使用軟體的過程中使用者往往提出增加新功
能或修改已有功能的建議，還可能提出一般性的改進意見。
預防性維護：當為了改進未來的可維護性或可靠性，或為
了給未來的改進奠定更好的基礎而修改軟體