交通軟件系統分析與設計李志慧E_mail:lizhih@電話考教材張海藩編著，《軟件工程導論》，清華大學出版社鄭人杰編，《實用軟件工程》，清華大學出版社，1997年《數據結構》，嚴蔚敏等編著，清華大學出版社數據結構，殷人坤，清華大學出版社第一章緒論交通軟件系統分析與設計關注的問題：1、

軟件系統開發過程

2、

數據結構+算法

數據結構：相互之間存在一種或多種特點關系的數據元素的結合。由某一數據對象及該對象中所有數據成員之間的關系組成，表示為

data_structure={D,R}數據結構線性表

棧和隊列

串

數組和廣義表

二叉樹

樹和森林

圖

算法查找排序算法評價：空間復雜度

時間復雜度

生命周期各階段的任務（1）問題定義

問題定義階段必須回答的關鍵問題是：”要解決的問題是什么?”通過問題定義階段的工作，系統分析員應該提出關于問題性質、工程目標和規模的書面報告。（2）可行性研究該階段要回答的關鍵問題是：“對于上一個階段所確定的問題有行得通的解決辦法嗎?”

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據。

（3）需求分析該階段的任務不是具體地解決問題，而是準確地確定“為下解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。

（4）總體設計該階段必須回答的關鍵問題是：“概括地說，應該如何解決這個問題?生命周期各階段的任務(5)詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：“應該怎樣具體地實現這個系統呢?”（6）編碼和單元測試

該階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。（7）綜合測試該階段的關鍵任務是通過各種類型的測試(及相應的調試)使軟件達到預定的要求。（8）軟件維護

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

結構分析過程小節階段關鍵問題結束標準問題定義問題是什么關于規模和目標的報告書可行性研究有可行的解嗎?系統的高層邏輯模型：數據流圖、成本／效益分析需求分析系統必須做什么?系統的邏輯模型：數據流因、數據字典、算法描述總體設計概括地說，應該如何解決這個問題?可能的解法：系統硫程圖、成本／效益分析推薦的系統結構：層次圖或結構圖詳細設計怎樣具體地實現這個系統？編碼規格說明：

HIPO圖或PDL編碼和單元測試正確的程序模塊源程序清單‘單元測試方案和結果綜合測試符合要求的軟件綜合測試方案和結果；完整一致的軟件配置維護持久地滿足用戶需要的軟件完整準確的維護記錄軟件生存期模型軟件生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架瀑布模型螺旋模型噴泉模型智能模型瀑布模型瀑布模型特點：（1）為一個整體開發模型（2）開發前可完整、準確地定義系統各個階段

適用條件：

適用開發，如：編譯系統，數據庫系統于功能和性能明確、完整、無重大變化地軟件等螺旋模型螺旋模型（原型開發模型）特點：（1）降低軟件開發風險（2）按照軟件的演化規律進行開發

（3）開發初期不要求開發人員準確、無二義了解系統適用：適用與復雜系統的開發或系統目標不明確的情況噴泉模型噴泉模型

噴泉模型是一種以用戶需求為動力，以對象作為驅動的模型它以面向對象的軟件開發方法為基礎，以用戶需求作為噴泉模型的源泉。特點（1）噴泉模型規定軟件開發過程有4個階段，即分析、系統設計、軟件設計和實現（2）噴泉模型的各階段相互重疊，它反映了軟件過程并行性的特點。（3）噴泉模型以分析為基礎，資源消耗呈塔型，在分析階段消耗的資源最多‘（4）噴泉模型反映了軟件過程迭代的自然特性，從高層返回低層無資源消耗軟件開發方法結構化方法結構化方法由結構化分析、結構化設計和結構化程序設計構成，它是一種面向數據流的開發方法Jackson方法一種面向數據結構的開發方法維也納開發方法一種形式化的開發方法，軟件的需求用嚴格的形式語言描述，把描述模型逐步變換成目標系統面向對象的開發方法面向對象開發方法包括面向對象分析（OOA）、面向對象設計（OOD）和面向對象實現。

其包括Booch、Coad、OMT方法統一建模語言UML第二章可行性分析可行性分析的任務

1）“問題是否可行？”2）目的：可行性研究的目的就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。3）首先需要進一步分析和澄清問題定義。在澄清了問題定義之后，分析員應該導出系統的邏輯模型。然后從系統邏輯模型出發，探索若干種可供選擇的主要解法(即系統實現方案)。對每種解法都應該仔細研究它的可行性，一般說來，至少應該從下述三方面研究每種解法的可行性：(1)技術可行性

使用現有的技術能實現這個系統嗎?(2)經濟可行性

這個系統的經濟效益能超過它的開發成本嗎?(3)操作可行性

系統的操作方式在這個用戶組織內行得通嗎?可行性研究的步驟

(1)復查系統規模和目標(2)研究目前正在使用的系統(3)導出新系統的高層邏輯模型(4)重新定義問題（5）導出和評價供選擇的解法（6）推薦行動方針（7）草擬開發計劃（8）書寫文檔提交審查

系統流程圖

系統流程圖的作用：系統流程圖是描述物理系統的工具。所謂物理系統，就是一個具體實現的系統，也就是描述一個單位、組織的信息處理的具體實現的系統。在進行可行性研究過程中，要以概括的形式描述現有系統的高層邏輯模型，并通過概要的設計變成所建議系統的物理模型，可以用系統流程圖來描述所建議系統的物理模型。系統流程圖可用圖形符號來表示系統中的各個元素,表達了系統中各個元素之間的信息流動的情況畫系統流程圖時，首先要搞清業務處理過程以及處理中的各個元素，同時要理解系統的流程圖的各個符號的含義，選擇相應的符號來代表系統中的各個元素。所畫的系統流程圖要反映出系統的處理流程。系統流程圖的符號系統流程圖的符號例子某裝配廠有一座存放零件的倉庫，倉庫中現有的各種零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。當倉庫中零件數量有變化時，應該及時修改庫存清單主文件，如果那種零件的庫存量少于它的庫存量臨界值，則應該報告給采購部門以便定貨，規定每天向采購部門送一次定貨報告。該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，由放在倉庫中的CRT終端輸入到計算機中；系統中的庫存清單程序對事務進行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的定貨信息寫在磁帶上。最后，每天由報告生成程序讀一次磁帶，并且打印出定貨報告分層面對復雜的系統時，一個比較好的方法是分層次地描繪這個系統。首先用一張高層次的系統流程圖描繪系統總體格朗，表明系統的關鍵功能。然后分別把每個關鍵功能擴展到適當的詳細程度，面在單獨的一頁紙上。這種分層次的描繪方法便于閱讀者按從抽象到具體的過程逐步深入地了解一個復雜的系統。系統流程圖與程序流程圖系統流程圖表達的是信息在系統各部件之間流動的情況，而不是對信息進行加工處理的控制過程，因此盡管系統流程圖使用的某些符號和程序流程圖中用的符號相同，但是它卻是物理數據流因而不是程序流程圖。

數據流圖

數據流圖描繪系統的邏輯模型，圖中沒有任何具體的物理元素，只是描繪信息在系統中流動和處理的情況。設計數據流圖只需考慮系統必須完成的基本邏輯功能，完全不需要考慮如何具體地實現這些功能，所以它也是軟件設計的很好的出發點。符號例子假設一家工廠的采購部每天需要一張定貨報表，報表按零件編號排序，表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應該列出下述數據：零件編號，零件名稱，定貨數量，目前價格，主要供應者，次要供應者。零件入庫或出庫稱為事務、通過放在倉庫中的CRT終端把事務報告給定貨系統。當某種零件的庫存數量少于庫存量臨界值時就應該再次定貨。數據流圖有四種成分：源點或終點，處理，數據存儲和數據流。分析方法：數據字典

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元柬的定義的集合。數據流圖和數據字典共同構成系統的邏輯模型—般說來，數據字典由四類元素組成：

1)數據流

2)數據流分量(即，數據元素)3)數據存儲

4)處理。數據處理工具(如IPO圖或PDL)描述成本／效益分析

第三章需要分析需求分析是軟件定義時期的最后一個階段，它的基本任務是準確地回答“系統必須做什么?”這個問題。需求分析的任務是對目標系統提出完整、準確、清晰、具體的要求。可行性研究階段產生的文檔，持別是數據流圖，是需求分折的出發點。需求分析的結果是系統開發的基礎，關系到工程的成敗和軟件產品的質量。因此，必須用行之有效的方法對軟件需求進行嚴格的審查驗證。需求分析的任務

1、確定對系統的綜合要求

1）系統功能要求

2）系統性能要求

3）運行要求

4）將來可能提出的要求

2、分析系統的數據要求

數據結構表示數據元素之間的邏輯關系

3、導出系統的邏輯模型

導出系統的詳細的邏輯模型，通常用數據流圖、數據字典和主要的處理算法描述這個邏輯模型。

4、修正系統開發計劃

5、開發原型系統需求分析的特點

1、問題的復雜性。

2、交流障礙

3、不完備性和不一致性

4、需求易變性需求分析的原則

1、必須能夠表達相理解問題的數據域和功能域。

2、可以把一個復雜問題按功能進行分解并可逐層細化3、建模需求分析的方法1、功能分解方法2、結構化分析方法3、信息建模方法4、面向對象分析方法需求說明書的主要內容

(1)前言：說明項目的目的、范圍，所用的術語的定義；用到的縮略語和縮寫詞；資料。

(2)項目概述：產品的描述；產品的功能；用戶的特點，一般的約束等。

(3)具體需求：說明每個功能的輸入、處理和輸出；外部接口需求，包括用戶接口、軟件接口、硬件接口相通信接口；性能需求；設計約束；共他需求，包括數據庫、操作等第二節需求分析過程

分析步驟：1、建立用例關系圖2、細化數據流圖3、用戶復查4、細化數據流圖5、修正開發計劃6、書寫文檔7、審查和復審3.3.2用例模型(Usecasemodel)用例圖(Usecasediagram)從用戶角度描述系統功能,并指出各功能的操作者用例模型描述的是外部執行者(Actor)所理解的系統功能。它描述了待開發系統的功能需求。用例模型由若干個用例圖構成，用例圖中主要描述執行者和用例之間的關系。在UML中,構成用例圖的主要元素是用例和執行者及其它們之間的聯系。創建用例模型的工作包括：

定義系統、確定執行者和用例、描述用例、定義用例間的關系、確認模型。一、執行者(Actor)執行者是指用戶在系統中所扮演的角色。執行者在用例圖中是用類似人的圖形來表示,但執行者可以是人，也可以是一個外界系統。注意：用例總是由執行者啟動的。如何確定執行者：1、誰使用系統的主要功能(主執行者)?2、誰需要從系統獲得對日常工作的支持和服務？3、需要誰維護管理系統的日常運行（副執行者）？4、系統需要控制哪些硬件設備？5、系統需要與其它哪些系統交互？6、誰需要使用系統產生的結果（值）？一、執行者5.3.2用例模型供貨買飲料取貨款客戶供貨人收銀員圖5.15自動售貨系統回例1二、用例二、用例(usecase)

從本質上講,一個用例是用戶與計算機之間的一次典型交互作用。在UML中,用例被定義成系統執行的一系列動作（功能）。用例有以下特點:用例捕獲某些用戶可見的需求,實現一個具體的用戶目標。用例由執行者激活,并將結果值反饋給執行者。用例必須具有功能上的完整描述。如何確定用例：1、與系統實現有關的主要問題是什么？2、系統需要哪些輸入/輸出？這些輸入/輸出從何而來？到哪里去？3、執行者需要系統提供哪些功能？4、執行者是否需要對系統中的信息進行讀、創建、修改、刪除或存儲？二、用例5.3.2用例模型回例15.3.3用例圖

圖5.16用例圖的元素5.3.3用例圖用例圖描述了系統的功能需求，它是從執行者的角度來理解系統，由“執行者”、“用例”和“用例之間的關系”3類模型元素構成。圖中還有另外兩種類型的連接,即《使用》和《擴展》關系，是兩種不同形式的泛化關系。 用例2用例A用例執行者用例1用例3用例B《使用》《使用》《擴展》(a)(b)(c)《Use》表示一個用例使用另一個用例。《Extend》通過向被擴展的用例添加動作來擴展用例。用例圖實例用例圖實例圖5.18應用生命周期用例圖圖5.17金融貿易系統貿易經理風險分析設置邊界進行交易交易估價更新帳目《使用》《使用》《擴展》營銷人員超越邊界評價記帳系統銷售人員5.3.4用例圖實例應用設計者應用提供者

改變應用運行應用

實現應用<<使用>><<擴展>><<展開>>應用操作者<<實現>>設計應用5.3.4用例圖實例例1建立項目與資源管理系統的Usecase圖

系統的主要功能是：項目管理，資源管理和系統管理。項目管理包括項目的增加、刪除、更新。資源管理包括對資源和技能的添加、刪除和更新。系統管理包括系統的啟動和關閉，數據的存儲和備份等功能。1、分析確定系統的執行者(角色)到確定到確定

項目管理員、資源管理員、系統管理員、備份數據系統。項目管理，資源管理和系統管理。2、確定用例3、對用例進行分解，畫出下層的Usecase圖

對上層的用例進行分解,并將執行者分配到各層次的Usecase圖中。角色：角色職責：角色職責識別：圖5.19角色描述模板

還應畫出相應的執行者描述模板及用例描述模板。例1項目與資源管理系統（PRMS）添加技能刪除技能更新技能資源管理員添加資源刪除資源更新資源查找技能《Use》查找資源《Use》《Use》《Use》把技能指定給資源從資源中清除技能《Extend》《Extend》5.21資源管理UseCase圖UseCase圖可以自頂而下不斷精化，抽象出不同層次的UseCase圖。5.3.4用例圖實例系統管理員項目管理員資源管理員資源管理項目管理系統管理備份系統圖5.20PRMS高層UseCase圖例1項目與資源管理系統（PRMS）項目管理員添加項目刪除項目更新項目添加活動刪除活動更新活動查找項目《Use》添加任務《Use》把技能指定給資源從資源中清除技能《Extend》《Extend》刪除任務更新任務《Extend》《Extend》《Extend》《Extend》《Extend》《Extend》圖5.22項目管理UseCase圖5.3.4用例圖實例系統管理員圖5.23系統管理UseCase圖添加技能存儲數據啟動系統關閉系統查找技能《Use》《Use》《Use》備份資源數據備份項目數據《Extend》《Extend》《Use》備份數據備份系統

現有一醫院病房監護系統，病癥監視器安置在每個病房，將病人的病癥信號實時傳送到中央監視系統進行分析處理。在中心值班室里，值班護士使用中央監視系統對病員的情況進行監控，根據醫生的要求隨時打印病人的病情報告，定期更新病歷，當病癥出現異常時，系統會立即自動報警,并實時打印病人的病情報告，立及更新病歷。要求根據現場情景，對醫院病房監護系統進行需求分析，建立系統的Usecasemodel。

請對系統需求進行分析！經過初步的需求分析，得到系統功能要求：1、監視病員的病癥（血壓、體溫、脈搏等）2、定時更新病歷3、病員出現異常情況時報警。4、隨機地產生某一病員的病情報告。

例2醫院病房監護系統產生病情報告監視病情更新病歷情景教學二、簡單的需求分析說明

系統名稱：醫院病房監護系統根據分析系統主要實現以下功能：

1、病癥監視器可以將采集到的病癥信號（組合），格式化后實時的傳送到中央監護系統。

2、中央監護系統將病人的病癥信號開解后與標準的病癥信號庫里的病癥信號的正常值進行比較，當病癥出現異常時系統自動報警。

3、當病癥信號異常時，系統自動更新病歷并打印病情報告。

4、值班護士可以查看病情報告并進行打印。

5、醫生可以查看病情報告，要求打印病情報告，也可以查看或要求打印病歷。

6、系統定期自動更新病歷。退出上頁首頁下頁末頁需求分析三、用UML的靜態建模機制定義并描述系統的靜態結構

（一）建立系統的用例圖

1、通過以下六個問題識別角色

(1)誰使用系統的主要功能？

(2)誰需要系統的支持以完成日常工作任務？

(3)誰負責維護，管理并保持系統正常運行？

(4)系統需要應付（或處理）哪些硬設備？

(5)系統需要和哪些外部系統交互？

(6)誰（或什么）對系統運行產生的結果（值）感興趣？需求分析

通過回答這六個問題以后，再進一步分析可以識別出本系統的四個角色：值班護士，醫生，病人，標準病癥信號庫。角色描述模板角色：病人角色職責：提供病癥信號角色職責識別：負責生成、實時提供各種病癥信號。角色：值班護士角色職責：負責監視病人的病情變化角色職責識別：

(1)使用系統主要功能

(2)對系統運行結果感興趣角色:標準病癥信號庫角色職責：負責向系統提供病癥信號的正常值角色職責識別：

(1)負責保持系統正常運行

(2)與系統交互角色：醫生角色職責：對病人負責，負責處理病情的變化角色職責識別：

(1)需要系統支持以完成其日常工作

(2)對系統運行結果感興趣通過分析可以初步識別出系統的用例為：中央監護，病癥監護，提供標準病癥信號，病歷管理，病情報告管理。頂層用例圖為：角色描述

通過分析可以初步識別出系統的用例為：中央監護，病癥監護，提供標準病癥信號，病歷管理，病情報告管理。頂層用例圖為：提供標準病癥信號病歷管理病人標準病癥信號庫

醫生值班護士病癥監護病情報告管理中央監護《使用》《使用》《使用》角色描述將用例細化，可以得到分解的用例：1、中央監護

分解為：a分解信號將從病癥監護器傳送來的組合病癥信號分解為系統可以處理的信號。

b比較信號將病人的病癥信號與標準信號比較。

c報警如果病癥信號發生異常（即高于峰值），發出報警信號。

d數據格式化將處理后的數據格式化以便寫入病歷庫。2、病癥監護

分解為：e信號采集采集病人的病癥信號。

f模數轉化將采集來的模擬信號轉化為數字信號。

g信號數據組合將采集到的脈搏，血壓等信號數據組合為一組信號數據。

h采樣頻率改變根據病人的情況改變監視器采樣頻率。3、提供標準病癥信號

i（此用例不分解）用例細化4、病歷管理

分解為：j生成病歷

k查看病歷

l更新病歷

m打印病歷

5、病情報告

分解為：n顯示病情報告

在顯示器上顯示病情

o打印病情報告在打印機打印病情報告用例細化給出細化的用例圖病人模數轉化數據格式化值班護士報警信號采集比較信號標準病癥信號庫

醫生信號數據組合采樣頻率改變提供標準病癥信號生成病歷查看病歷更新病歷打印病歷顯示病情報告打印病情報告分解信號《Extend》《Extend》《Extend》《use》《use》《use》《use》《use》《use》《use》《use》細化的用例圖第三節概念模型和規范化

用戶的數據要求----需要哪些數據，數據之間有哪些聯系，數據本身有哪些性質，數據的結構等）。用戶的處理要求---對數據進行哪些處理，每個處理的邏輯功能。

概念性模型（信息模型）---一種面向問題的數據模型，是按照用戶的觀點來對數據和信息建模。表示概念性數據模型的最常用方法是實體-聯系方法，采用用ER圖的方式，這種表示又稱為ER模型。ER模型

實體：客觀世界中存在的且可區分的事物。聯系：客觀事物之間的聯系（三類--1：1，1：N，M:N）屬性：實體或聯系所具有的性質。教師姓名性別職稱職務教師號教1課程N課程號課名學時學分學M學生N學號姓名性別系年級成績

范式通常用范式定義消除數據的冗余度（略）ER關系圖與數據庫映射關系描述關系數據庫數據以2維表的形式進行表示，每個表的列表示字段、行表示數據庫表的一個記錄

Primarykey（主鍵）:字段的唯一標識Foreignkey（外鍵）:其它表的主鍵在該表的參考SQL（結構化查詢語言）：可以進行數據庫表記錄的操作.SQL語言基礎1、創建數據庫CREATEDATABASEdatabase-name

2、刪除數據庫dropdatabasedbname

3、創建新表createtabletabname(col1type1[notnull][primarykey],col2type2[notnull],..)

4、刪除新表droptabletabname

5、添加主鍵：Altertabletabnameaddprimarykey(col)

刪除主鍵：Altertabletabnamedropprimarykey(col)

6、創建索引：create[unique]indexidxnameontabname(col….)

刪除索引：dropindexidxname

SQL語言基礎7、創建視圖：createviewviewnameasselectstatement

刪除視圖：dropviewviewname

8、選擇：select*fromtable1where范圍

插入：insertintotable1(field1,field2)values(value1,value2)

刪除：deletefromtable1where范圍

更新：updatetable1setfield1=value1where范圍

E－R與數據庫映射E-R模型映射為數據庫表:屬性的映射每個實體映射為一個表實體的每個屬性映射為一個字段每個實體的個體映射為數據庫的一個記錄N：M關系映射為一個單獨的表1：N關系利用外鍵進行映射例子：E－R關系模型與數據庫表的映射ICitycityNameAirportairportCodeairportName**ServescityNameHoustonAlbanyMunichHamburgCityTablecityNameHoustonHoustonAlbanyMunichHamburgServesTableairportCodeIAHHOUALBMUCHAMAirportTableairportCodeIAHHOUALBMUCHAMairportNameIntercontinentalHobbyAlbanyCountyMunichAirportHamburgAirportPrimaryKey

N：M（多對多關系）:將關系映射為單個表SeparateTable例子：E－R關系模型與數據庫表的映射II

會議transactionID職員portfolioID...NportfolioID...PortfolioTabletransactionIDTransactionTableportfolioIDForeignKey1:N或N：1關系:隱藏外鍵的處理1例子：E－R關系模型與數據庫表的映射Ⅲ

doordoorIDskyskyID...*doorIDTransactionTabledoorID1-To-1關系門與鑰匙關系

習題給出E_R的數據庫設計教師姓名性別職稱職務教師號教1課程N課程號課名學時學分學M學生N學號姓名性別系年級E_R與數據結構映射關系數據元素四種基本結構：

（1）集合結構（2）線性結構

（3）樹狀結構（4）圖狀結構

應用舉例線性表、樹、圖數據內存的存儲順序存儲結構、鏈式存儲問題數據結構的核心：（1）關注數據元素在計算機內存的存儲問題；（2）根據數據關系，利用數據基本操作來描述與表達算法數據結構基本形式線性表：n個數據元素的有限序列如：樹:n個節點的有限集圖C語言描述C語言描述Typedefstruct{數據類型屬性1；數據類型屬性2；

數據類型屬性n；}structname;如：typedefstruct{Inti；chars；}Course；Coursetraffic[100]，*signal，；線性表順序存儲：

數組描述鏈式存儲：指針動態分配如線性表的元素若將上例改為合并為一個新的非遞減的集合，則算法為線性鏈表循環鏈表雙向鏈表棧：先進后出鏈棧鏈棧解決內存空間預分配不足問題如何出棧和入棧？？隊列：先進先出第四節.圖形工具

層次方框圖：用樹形結構的一系列多層次的矩形框描繪數據的層次結構。

產品

硬件

軟件

服務

處理機

存儲器外部設備系統軟件應用軟件軟件服務硬件維修培訓操作系統編譯程序軟件工具層次方框圖的一個例子

注意：層次方框圖即可以表示數據的層次結構，也可以表示程序的層次結構4.圖形工具（續）

Warnier圖：用樹形結構描繪數據的層次結構。軟件產品系統軟件操作系統(P1)編譯程序(P2)軟件工具編輯程序(P3)測試驅動程序(P4)設計輔助程序(P5)應用軟件⊕5.驗證軟件需求

從哪幾個方面驗證軟件需求的正確性（四個方面）一致性：任何一條需求不能和其他需求互相矛盾。完整性：規格說明書應該包括用戶需要的每一個功能和性能。現實性：指定的需求是用現有的硬件、軟件技術可以實現的。有效性：需求是正確有效的，確實能解決用戶面對的問題。

驗證軟件需求的方法一致性：人工審查---》形式化描述軟件需求，軟件工具自動驗證。現實性：參考以往的開發經驗，分析，仿真或模擬完整性和一致性：原型系統第四章總體設計總體設計的基本目的就是回答“概括地說，系統應該如何實現?”這個問題。總體設計又稱為概要設計或初步設計，其任務：（1）劃分出組成系統的物理元素----程序、文件、數據庫、人工過程和文檔通過這個階段的工作將劃分出組成系統的物理元素——程序、文件、數據庫、人工過程和文檔等等，但是每個物理元素仍然處于黑盒子級，這些黑盒子里的具體內容將在以后仔細設計。（2）總體設計階段的另一項重要任務是設計軟件的結構，也就是要確定系統中每個程序是由哪些模塊組成的，以及這些模塊相互間的關系。1總體設計的過程（兩個主要階段）：

系統設計：確定系統的具體實現方案。結構設計：確定軟件結構。設想供選擇的方案選取合理的方案推薦最佳方案功能分解設計軟件結構數據庫設計制訂測試計劃書寫文檔數據流圖

系統流程圖組成系統的物理元素清單成本/效益分析實現系統的進度計劃

系統說明用戶手冊測試計劃詳細的實現計劃數據庫設計結果審查和復審2軟件設計的概念和原理模塊是數據說明、可執行語句等程序對象的說明。

（1）模塊化：把程序劃分成若干個模塊，每個模塊完成一個子功能，把這些模塊集總起來組成一個整體，可以完成指定的功能，滿足問題的功能。C(P1+P2)>C(P1)+C(P2)E(P1+P2)>E(P1)+E(P2)成本模塊數目成本/模塊接口成本最小成本區

（2）抽象（3）信息隱蔽和局部化

信息隱蔽原理指出：使得一個模塊內包含的信息(過程和數據)對于不需要這些信息的模塊來說，是不能訪問的。所謂局部化是指把一些關系密切的軟件元素物理地放得彼此靠近。模塊化和軟件成本耦合：一個軟件結構內不同模塊之間互連程度的度量，耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。數據耦合：模塊之間通過參數交換數據信息。控制耦合：模塊之間傳遞的參數含有控制信息。公共環境耦合：兩個或多個模塊通過一個公共數據環境相互作用。內容耦合：如果出現下列情況之一，兩個模塊間就發生了內容耦（1）一個模塊訪問另一個模塊的內部數據；2）一個模塊不通過正常入口而轉到另一個模塊的內部；3）兩個模塊有一部分程序代碼重疊4）一個模塊有多個入口。

設計原則：盡量使用數據耦合，少用控制耦合，限制公共環境耦合，完全不用內容耦合。數據耦合控制耦合公共環境耦合內容耦合低高（4）模塊獨立----每個模塊完成一個相對獨立的子功能，并且和其他模塊之間的關系很簡單。模塊獨立的概念是模塊化、抽象、信息隱蔽和局部化概念的直接結果，獨立的優點：(1)有效的模塊化的軟件比較容易開發

(2)獨立的模塊比較容易測試和維護模塊的獨立程度兩個定性標準度量：內聚和耦合耦合衡量不同模塊彼此間互相依賴的緊密程度；內聚衡量一個模塊內部各個元素彼此結合的緊密程度。2軟件設計的概念和原理

----耦合非直接耦合數據耦合特征耦合控制耦合外部耦合公共耦合內容耦合弱耦合中耦合較強耦合強耦合模塊1模塊2模塊3模塊4數據耦合通過簡單變量交換數據特征耦合通過數據結構交換數據非直接耦合模塊之間沒有信息傳遞模塊A模塊B模塊C模塊D模塊L模塊N全局性數據結構公共耦合Flag=1?S1S2模塊1控制耦合模塊之間傳遞的是控制信息TF全局性簡單變量外部耦合模塊A

模塊B內容耦合

訪問其它模塊的內部數據直接跳到其他模塊內部執行2軟件設計的概念和原理（續1）內聚：一個模塊內各個元素彼此結合的緊密程度。偶然內聚：一個模塊完成一組任務，任務之間的關系很松散。公共語句。邏輯內聚：若干個邏輯功能類似的任務組成一個模塊。(如模板函數)時間內聚：若干個任務必須在同一段時間內執行。如初始化工作。低內聚中內聚高內聚過程內聚：模塊內的處理元素是相關的，且必須以特定次序執行。通信內聚：模塊中所有元素都使用同一個輸入數據，和/或產生同一個輸出數據。順序內聚：模塊中所有處理元素和同一個功能密切相關，且這些處理必須順序執行。功能內聚：所有處理元素屬于一個整體，完成一個單一的功能。模塊A模塊B模塊CS1;S2;模塊A模塊B模塊C模塊A模塊B模塊C模塊D2軟件設計的概念和原理（續2）

改進軟件結構提高模塊獨立性模塊規模應該適中深度、寬度、扇入、扇出都應適當扇入：一個模塊的扇人表明有多少個上級模塊直接調用它，扇入越大則共享該模塊的上級模塊數目越多。扇出：扇出是一個模塊直接控制(調用)的模塊數目，扇出過大意味著模塊過分復雜，需要控制和協調過多的下級模塊。模塊的作用域應該在控制域之內模塊的作用域：為受該模塊內一個判定影響的所有模塊的集合。模塊的控制域：這個模塊本身以及所有直接或間接從屬于它的模塊的集合。力爭降低模塊接口的復雜程度設計單入口單出口的模塊模塊的功能應該可以預測3啟發式規則4圖形工具

層次圖和HIPO圖層次圖用來描述軟件結構，層次圖+IPO圖=HIPO圖正文加工系統輸入輸出編輯加標題存儲檢索編目錄格式化添加刪除插入修改合并列表

結構圖方框之間的箭頭表示模塊的調用關系，帶注釋的箭頭表示模塊間來回傳遞的信息：空心圓—數據，實心圓—控制信息。結構圖還可以表示模塊的選擇調用或循環調用參見：P645面向數據流的設計方法1）變換流2）事務流3）設計過程時間輸入流輸出流變換流外部表示內部表示信息變換流：信息沿輸入通路進入系統，同時由外部形式變換成內部形式，進入系統的信息通過變換中心，經加工處理以后再沿輸出通路變換成外部形式離開軟件系統。當數據流圖具有這些持征時，這種信息流就叫作變換流。這種數據流是“以事務為中心的”．也就是說，數據沿輸入通路到達一個處理T，這個處理根據輸入數據的類型在若干個動作序列中選出一個來執行。這類數據流應該劃為一類特殊的數據流，稱為事務流。事務T事務中心活動通路事務中心T完成下述任務：接受輸入數據（事務）分析每個事務以確定它的類型根據事務類型選取一條活動通路變換流與事務流三要素變換流三要素輸入、輸出、變換中心

事務流三要素事務、事務中心、活動通路5面向數據流的設計方法（續）精化數據流圖流類型區分事務中心和數據接收通路映射成事務結構區分輸入和輸出分支映射成變換結構用啟發式設計規則精化軟件結構導出接口描述和全程數據結構復查詳細設計事務分析變換分析5面向數據流的設計方法（續）

變換分析：汽車數字儀表板功能：

1）通過A/D轉換實現傳感器和微處理器接口，

2）在發光二極管面板上顯示數據，

3）指示每小時英里數（mph)，行駛的里程，每加倫油行駛的英里數(mpg)等等。

4）指示加速或減速；

5）超速警告：如果車速超過55英里/小時，則發出超速警告鈴聲。A/D轉數計數器流量傳感器微處理機里程表車速表油效表油管系統加速/減速指示超速報警5面向數據流的設計方法（續）讀旋轉信號收集和求平均轉換成轉/分（rpm）計算里程確定加速/減速產生加速/減速顯示產生里程顯示計算mph和超速值計算燃料消耗發出鈴聲產生mph顯示產生mpg顯示讀和校核計算gph旋轉信號信號/秒SPS△SPSSPSrpmrpm箭頭指示上箭頭⊕⊕水平線下箭頭英里超速值顯示鈴聲mphmphmpggph燃料流燃料流傳感器信號Mpg顯示數字儀表板控制接受傳感器信號數據轉換控制驅動儀表板輸入控制變換控制輸入控制5面向數據流的設計方法（續）設計步驟：復查基本系統模型復查并精化數據流圖確定數據流圖具有變換特性還是事務特性確定輸入流和輸出流的邊界，劃分變換或事務中心完成“第一級分解”CmCaCtCe第一級分解的方法5面向數據流的設計方法（續）ADBCCmCaCBDA接受傳感器信號轉換成rpm收集SPS讀旋轉信號計算gph讀燃料流數字儀表板控制確定加/減速計算mph計算gpg計算里程驅動儀表板加速/減速顯示顯示mpg顯示mph顯示里程發出鈴聲發光二極管顯示5面向數據流的設計方法（續）數字儀表板控制接受傳感器信號轉換成rpm讀旋轉信號計算gph讀燃料流數字儀表板控制確定加/減速計算mph計算gpg計算里程驅動儀表板加速/減速顯示顯示mpg顯示mph顯示里程發出鈴聲發光二極管顯示數字儀表板軟件系統經過調整后的結構圖注意：紅色模塊的位置有所調整5面向數據流的設計方法（續）

事務分析432總控接收通路C通路B通路A通路調度A_CTL142+1321B_CTLC_CTL

設計優化設計優化應該力求做到在有效的模塊化的前提下使用最少量的模塊，以及在能夠滿足信息要求的前提下使用最簡單的數據結構。‘數據流圖軟件結構總體設計說明書的主要內容如下：(1)引言：編寫目的，背景，定義，參考資料。(2)總體設計：需求規定，運行環境，基本設計概念和處理流程，結構。(3)接口設計：用戶接口，外部接口，內部接口。(4)運行設計：運行模塊組合．運行控制，運行時間。(5)系統數據結構設計：邏輯結構設計，物理結構設計，數據結構與程序的關系，(6)系統出錯處理設計：出錯信息，補救措施．系統恢復設計。第五章詳細設計詳細設計：過程設計設計方法：結構程序設計結構序設計：一種程序設計技術，它采用自頂向下逐步求精的設計方法和單入口單出口的控制結構詳細設計階段的目標：確定應該怎樣具體地實現所要求的系統。精確地描述整個目標系統，從而在編碼階段可以把這個描述翻譯成用某種程序設計語言書寫的程序。詳細設計的基本任務1．算法設計用某種圖形、表格、語言等工具將每個模塊處理過程的詳細算法描述出來2．數據結構設計對于需求分析、概要設計確定的概念性的數據類型進行確切的定義。

3．物理設計對數據庫進行物理設計，即確定數據庫的物理結構。物理結構主要指數據庫的存儲記錄格式、存儲記錄安排和存儲方法，這些都依賴于具體所使用的數據庫系統。

4．其他設計根據軟件系統的類型，還可能要進行以下設計：(1)代碼設計；為了提高數據的輸入、分類、存儲及檢索等操作的效率空間，對數據庫中的某些數據項的值要進行代碼設計。(2)輸入／輸出格式設計。(3)人機對話設計：對于一個實時系統，用戶與計算機顛蟹對話，因此要進行對話方式、內容及格式的具體設計。5．編寫詳細設計說明書詳細設計說明書有下列的主要內容：(1)引言：包括編寫目的、背景、定義(2)程序系統的組織結構。(3)程序l(標識符)設計說明：(4)程序2(標識符)設計說明。(5)程序N(標識符)設計說明6．評審結構程序設計順序、選擇、循環三種基本結構BexpAABexpAAexpTFTTFF順序結構選擇結構循環結構1）“While”型循環2）Do….Until型循環結構程序設計技術好處：(1)自頂向下逐步求精的方法符合人類解決復雜問題的普遍規律。(2)先全局后局部、先整體后細節、先抽象后具體的逐步求精過程開發出的程序有清晰的層次結構，容易閱讀和理解。

(3)不使用GoTo語句僅使用單入口單出口的控制結構．使得程序的靜態結構和它的動態執行情況比較一致。

(4)控制結構有確定的邏輯模式，編寫程序代碼只限于使用很少幾種直截了當的方式，因此源程序清晰流暢，易讀易懂而且容易測試。(5)程序清晰和模塊化使得在修改和重新設計一個軟件時可以重用的代碼量最大。(6)程序的邏輯結構清晰，有利于程序正確性證明。習題1.For（inti=0;i<n;i++){A}2.while(i<100){A}3.Do{A}While(i<100)非結構化程序轉換方法：1、設置標志位2、變換結構1結構程序設計

經典的結構程序設計：順序，選擇，當型循環擴展的結構程序設計：順序，選擇+多分支，當型循環+直到型循環修正的結構程序設計：順序，選擇+多分支，當型循環+直到型循環，break結構詳細設計的工具程序流程圖開始或停止準備選擇多分支選擇注釋預先定義的處理,子程序循環下界循環上界處理控制流2詳細設計的工具----盒圖（N_S圖）S1S2S3條件FTElse部分Then部分Case條件值1值2。。。值nCase1部分Case2部分Casen部分循環條件Do-While

部分循環條件Do-Until

部分A特點：1）功能域（既一個特定控制結構的作用域）明確

2）不可能任意轉移控制

3）很容易確定局部和全程數據的作用域

4）很容易表現嵌套關系，也可以表示模塊的層次結構Nassi&Shneiderman2詳細設計的工具----PAD圖P1P2P1P2條件CPnP2P1WHILECPUNTILCPdef順序選擇Case型多分支選擇當型循環直到型循環語句標號定義2詳細設計的工具----PAD圖P1P2P3P4CP5P2defP6P3P8CUntilC3UNTILC2P9P10PAD圖的主要優點:使用PAD符號設計的程序必然是結構化的程序.PAD圖所描繪的程序結構十分清晰.用PAD圖表現程序邏輯,易讀，易記，易懂.容易將PAD圖轉換成高級語言源程序.可用軟件工具實現自動轉換.即可以表示程序邏輯,也可以描繪數據結構.支持自頂向下,逐步求精方法的使用.2詳細設計的工具----判定表程序流程圖、N-S圖、PAD圖或過程設計語言(PDL)都不易清楚的描述含有多重嵌套的條件選擇。判定表可以清晰的表示復雜的條件組合與其對應的處理之間的關系。例子假設某航空公司規定，乘客可以免費托運重量不超過30公斤的行李。當行李重量超過30公斤時，對頭等艙的國內乘客超重部分每公斤收費4元，對其它艙的國內乘客超重部分每公斤收費6元，對外國乘客超重部分每公斤收費比國內乘客多一倍，對殘疾乘客超重部分每公斤收費比正常乘客少一半。用判定表來表示與上述每種條件組合相對應的動作。所有條件條件組合矩陣與每種條件組合所對應的動作表所有可能的動作列表國內乘客頭等艙殘疾乘客行李≤30kg免費(W-30)*2(W-30)*3(W-30)*4(W-30)*6(W-30)*8(W-30)*2TTTFTTTTTTTTTTFFFFFFFFFFFFFFFFFFF×××××××××2詳細設計的工具----判定樹行李費算法行李重量

W>30國內乘客外國乘客頭等艙其它艙殘疾乘客----(W-30)*2正常乘客----(W-30)*4殘疾乘客----(W-30)*3正常乘客----(W-30)*6頭等艙其它艙殘疾乘客----(W-30)*4正常乘客----(W-30)*8殘疾乘客----(W-30)*6正常乘客----(W-30)*12行李重量

W≤30免費過程設計語言(PDL)PDL應該具有下述特點：

(1)關鍵字的固定語法，它提供了結構化控制結構、數據說明和模塊化的待點。為了使結構清晰和可讀性好，通常在所有可能嵌套使用的控制結構的頭和尾都有關鍵字，例如:if．．．fi(或endif)等等。

(2)自然語言的自由語法，它描述處理待點。

(3)數據說明的手段。應該既包括簡單的數據結構(例如純量和數組)，又包括復雜的數據結構(例如，鏈表或層次的數據結構)。

(4)模塊定義和調用的技術，應該提供各種接口描述模式。PDL作為一種設計工具的優點：(1)可以作為注釋直接插在源程序中間。這樣做能促使維護人員在修改程序代碼的同時也相應地修改PDL注釋，因此有助于保持文檔和程序的一致性，提高了文檔的質量。

(2)可以使用普通的正文編輯程序或文字處理系統，很方便池完成PDL的書寫和編輯工作。

(3)已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。

PDL的缺點是不如圖形工具形象直觀，描述復雜的條件組合百動作間的對應關系時，不如判定表清晰簡單。Jackson程序設計方法特點：面向數據結構的設計方法，也就是用數據結構作為程序設計的基礎方法：首先需要分析確定數據結構，并且用適當的工具清晰地描繪數據結構。Jackson圖數據元素彼此間的邏輯關系只有順序、選擇和重復三類順序結構順序結構的數據由一個或多個數據元素組成，每個元素按確定次序出現一次。選擇結構選擇結構的數據包含兩個或多個數據元素，每次使用這個數據時按一定條件從這些數據元素中選擇一個。重復結構重復結構的數據，根據使用時的條件由一個數據元素出現零次或多次構成。Jackson圖優點：·便于表示層次結構，而且是對結構進行自頂向下分解的有力工具；·形象直觀可瀆性好；·既能表示數據結構也能表示程序結構改進的Jackson圖Jackson方法Jackson結構程序設計方法基本上由下述五個步騾組成：1．分析并確定輸入數據和輸出數據的邏輯結構，并用Jackson圖描繪這些數據結構。

2．找出輸入數據結構和輸出數據結構中有對應關系的數據單元。

3．用下述三條規則從描繪數據結構的Jackson圖導出描繪程序結構的Jackson：第一，為每對有對應關系的數據單元，按照它們在數據結構圖中的層次在程序結構圖的相應層次畫一個處理框第二，根據輸入數據結構中剩余的每個數據單元所處的層次，分別為它們面上對應的處理框；第三，根據輸出數據結構中剩余的每個數據單元所處的層次，次分別為它們畫上對應的處理框。總之，描繪程序結構的Jackson圖應該綜合輸入數據結構和輸出數據結構的層次關系而導出來。

4.列出所有操作和條件(包括分支條件和循環結束條件)，并且把它們分配到程序結構圖的適當位置。

5．用偽碼表示程序。例子：

一個正文文件由若干個記錄組成，每個記錄是一個字符串。要求統計每個記錄中空格字符的個數，以及文件中空格字符的總個數。要求的輸出數據格式是，每復制一行輸入字符串之后，另起一行印出這個字符串中的空格數，最后印出文件中空格的總個數。5詳細設計的工具----程序復雜度的定量度量

利用軟件設計的基本原理和概念可以定性的衡量軟件模塊的質量。但定量的度量程序復雜程度的方法很有價值：估算程序中軟件故障的數量；估算軟件開發的工作量；比較兩個不同的設計或兩個不同算法的友劣；作為模塊規模的精確上限。程序定量度量方法是一個有待進一步研究的重要領域。1）McCabe方法程序圖–把程序流程圖中每個處理符號都退化成一個點，原來連接不同處理符號的箭頭變成連接不同點的有向弧，這樣得到的有向圖就稱為程序圖。程序圖僅僅描述程序內部的控制流程，完全不表現對數據的具體操作以及分支或循環的具體條件。入口點：程序圖中開始點后面的那個節點。出口點：程序圖中停止點前面的那個節點。用McCabe方法度量得出的結果稱為程序的環形復雜度。程序的環形復雜度=強連通圖中線性無關的有向環的個數。5詳細設計的工具----程序復雜度的定量度量2）環形復雜度的計算方法在一個強連通的有向圖中，線性無關環的個數由以下公式確定：

V(G)=m–n+p

其中：V(G)----有向圖G中的環數。

m----有向圖G中的弧數。

n----有向圖G中的節點數。

p----有向圖G中的分離部分的數目。（對于正常的程序，p=1）

一般來說，由于程序圖不是強連通的，要直接應用以上結論到程序圖中還不行，因此要對程序圖進行擴展，從其出口點到入口點增畫一條虛弧，則原程序圖必然成為強連通圖。這樣就可以應用以上公式來計算環形復雜度。3）環形復雜度的用途：程序的環形復雜度與程序控制流的復雜程度，也就是與程序結構的復雜程度有關。程序內分支數或循環個數增加時，環形復雜度就增加，因此它是對測試難度的一種度量，也能對軟件最終的可靠性給出某種預測。McCabe發現：環形復雜度高的程序往往是最困難、最容易出問題的程序。實踐表明：模塊規模以V（G）≤10為宜。也就是說，V（G）=10是模塊規模的一個更科學更精確的上限。5詳細設計的工具----程序復雜度的定量度量開始K=0L=0TOTAL=0輸入ADowhileTOTAL≤1000andA≠0A＞0TOTAL=TOTAL+AK=K+1輸入AL=L+1輸出K,L,TOTAL停止abcdefghijkabcdefghjikV(G)=13-11+1=313條弧11

個節點1

個獨立部分第六章編碼程序設計語言:人與計算機通信的基本工具，指揮計算機按人的意志工作。

1946—1954:機器語言和匯編語言，與計算機硬件操作一一對應。

1954：第一個高級語言FORTRAN語言。

高級語言的種類：基礎語言----Fortran,Basic,Cobol,Algol

結構化語言----Pl/1,Pascal,C,Ada

專用語言-------特殊應用如LISP,Prolog.

程序設計語言的特點：名字說明：類型說明：初始化：程序對象（語句，存儲，過程）的局部性：程序模塊：循環控制結構：分支選擇結構：異常處理：獨立編譯：選擇程序設計語言的原則：系統用戶的要求；可以使用的編譯程序；可以使用的軟件工具；工程規模；程序員的知識；軟件可移植要求；軟件的應用領域。在這個階段的任務是:把軟件設計的結果翻譯成計算機可以“理解”的形式

—用計算機語言表示的程序。第六章編碼（續）程序設計途徑寫程序的風格程序內部的文檔----恰當的意義明確的標識符,注解,程序的視覺組織(語句布局).數據說明----次序標準化,歸類化.語句構造----每個語句的構造應該簡單、直接和易于理解。一般不要為了節省紙張多個語句寫在一行；避免復雜的條件測試；減少對“非”條件的測試；避免大量使用循環嵌套和條件嵌套；利用括號使邏輯表達式或算術表達式的運算次序清晰直觀。輸入/輸出----效率----程序運行時間、存儲器效率、輸入和輸出的效率。程序設計方法論程序設計自動化----三種途徑（用戶需求形式化精確定義，組件技術，范型）程序設計工具----編譯程序代碼管理系統第七章測試基本概念軟件測試的目標或定義（G.Myers):1）測試是為了發現程序中的錯誤而執行程序的過程。

2）好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案。

3）成功的測試是發現了至今為止尚未發現的錯誤的測試。黑盒測試和白盒測試黑盒測試：已經知道了軟件產品應該具有的功能，通過測試來檢驗是否每個功能都能正常使用。這種測試方法又稱功能測試。白盒測試：知道軟件產品內部的工作過程，通過測試來檢驗產品內部動作是否按照規格說明書的規定正常進行。這種測試方法又稱結構測試。不論是每個功能或每個邏輯控制通路，如果對所有的情況都進行測試，這樣的測試成為窮盡測試。窮盡測試在一般情況下是實際不可行的。例一、Sum(inta,intb,intc){return(a+b+c);}假定int類型為16位整數。需要測試216*216*216次。每次1ms,約要1萬年循環20次各種組合，約520種例二：白盒測試7.1基本概念（1）軟件測試的步驟：模塊測試子系統測試系統測試平行運行

目的：保證每個模塊作為一個單元能夠正確運行，又稱為單元測試集成測試、組裝測試、聯合測試；重點在于測試模塊之間的接口；

將經過測試的子系統裝配成一個完整的系統來測試；發現設計和編碼的錯誤，驗證系統是否滿足需求說明所定義的功能及其動態特性；也稱為集成測試。同時運行新舊兩個系統，并且對處理的結果進行比較，以確定新系統是否滿足相關性能指標。驗收測試

有用戶參加的系統測試；驗證是否滿足用戶的需要。7.1基本概念（2）測試階段的信息流：測試軟件配置測試配置測試結果預期結果評價錯誤錯誤率數據調試可靠性模型正確可靠性預測測試與軟件開發各個階段的關系軟件開發過程是一個自頂向下，逐步細化的過程軟件計劃階段定義軟件作用域軟件需求分析建立軟件信息域、功能和性能需求、約束等軟件設計把設計用某種程序設計語言轉換成程序代碼測試過程是依相反順序安排的自底向上，逐步集成的過程。包括需求說明書、設計說明書、源程序清單等包括測試計劃和測試方案7.1基本概念（3）測試與軟件開發各個階段的關系（示意圖）7.2單元測試（1）單元測試又稱模塊測試，是針對軟件設計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。1.單元測試的內容在單元測試時，測試者需要依據詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。(1)模塊接口測試在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：調用本模塊的輸入參數是否正確；本模塊調用子模塊時輸入給子模塊的參數是否正確；全局量的定義在各模塊中是否一致；

模塊接口局部數據結構重要的執行通路出錯處理通路影響上述各方面特性的邊界條件7.2單元測試（2）

在做內外存交換時要考慮：文件屬性是否正確；

OPEN與CLOSE語句是否正確；緩沖區容量與記錄長度是否匹配；在進行讀寫操作之前是否打開了文件；在結束文件處理時是否關閉了文件；正文書寫／輸入錯誤，

I／O錯誤是否檢查并做了處理。

(2)局部數據結構測試不正確或不一致的數據類型說明使用尚未賦值或尚未初始化的變量錯誤的初始值或錯誤的缺省值變量名拼寫錯或書寫錯不一致的數據類型全局數據對模塊的影響(3)路徑測試選擇適當的測試用例，對模塊中重要的執行路徑進行測試。應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。對基本執行路徑和循環進行測試可以發現大量的路徑錯誤.(4)錯誤處理測試出錯的描述是否難以理解出錯的描述是否能夠對錯誤定位顯示的錯誤與實際的錯誤是否相符對錯誤條件的處理正確與否在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等7.2單元測試（3）(5)邊界測試注意數據流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素2.單元測試的步驟代碼審查：組長+程序設計、編寫、測試者模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。

驅動模塊(driver)：調用測試單元的“主程序”，它接受測試數據，把這些數據傳送給被測試的模塊并打印有關結果。

樁模塊(stub)──存根模塊：是被測試模塊單元所調用模塊的代替模塊，在模塊調用接口、相關數據處理、控制返回等方面對被代替模塊進行“模擬”。驅動模塊被測模塊樁模塊樁模塊樁模塊測試用例測試結果單元測試的測試環境7.3集成測試（1）

集成測試是組裝軟件的系統技術；組裝測試、聯合測試通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是：在把各個模塊連接起來的時侯，穿越模塊接口的數據是否會丟失；一個模塊的功能是否會對另一個模塊的功能產生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數據結構是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。在單元測試的同時可進行組裝測試，發現并排除在模塊連接中可能出現的問題，最終構成要求的軟件系統。子系統的組裝測試特別稱為部件測試，它所做的工作是要找出組裝后的子系統與系統需求規格說明之間的不一致。通常，把模塊組裝成為系統的方式有兩種一次性組裝方式：又稱為非漸增式測試；增殖式組裝方式：其中又分為自頂向下、自底向上和兩種方法混合測試方式。7.3集成測試（2）1.一次性組裝方式(bigbang)它是一種非增殖式組裝方式。也叫做整體拼裝。使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。系統結構圖單元測試整體組裝7.3集成測試（3）2.增殖式組裝方式這種組裝方式又稱漸增式組裝首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統在組裝的過程中邊連接邊測試