軟件工程重點

軟件工程

1.1軟件危機

1.2軟件工程

1.3軟件生命周期

1.4軟件過程第1章軟件工程學概述第1章軟件工程學概述軟件的定義軟件（

Software）是計算機系統(tǒng)中與硬件相互依存的另一部分，它是包括程序（Program）

，數(shù)據(jù)（Data）及其相關文檔（Document）的完整集合。軟件=程序+數(shù)據(jù)+文檔程序=算法+數(shù)據(jù)結構1.1.1軟件危機的介紹軟件危機(軟件蕭條、軟件困擾)：是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。實際上，幾乎所有軟件都不同程度地存在這些問題。軟件危機包含下述兩方面的問題：如何開發(fā)軟件，滿足對軟件日益增長的需求；如何維護數(shù)量不斷膨脹的已有軟件。軟件危機的典型表現(xiàn)：（1）對軟件開發(fā)成本和進度的估計常常很不準確；（2）用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生；（3）軟件產(chǎn)品的質量往往靠不住；（4）軟件常常是不可維護的；（5）軟件通常沒有適當?shù)奈臋n資料；（6）軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升；（7）軟件開發(fā)生產(chǎn)率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。1.1.2產(chǎn)生軟件危機的原因（1）與軟件本身的特點有關軟件是邏輯部件。軟件不會被“用壞”，如果發(fā)現(xiàn)了錯誤，很可能是開發(fā)時期引入。軟件規(guī)模龐大，而且程序復雜性將隨著程序規(guī)模的增加而呈指數(shù)上升。（2）與軟件開發(fā)與維護的方法不正確有關忽視軟件需求分析的重要性。對用戶要求沒有完整準確的認識就匆忙著手編寫程序。越早開始寫程序，完成它所需要用的時間往往越長。認為軟件開發(fā)就是寫程序并設法使之運行。程序只是完整的軟件產(chǎn)品的一個組成部分。一個軟件產(chǎn)品必須由一個完整的配置組成，軟件配置主要包括程序、文檔和數(shù)據(jù)等成分。在軟件開發(fā)的不同階段進行修改需要付出的代價是很不相同的，見圖1.1。圖1.1引入同一變動付出的代價隨時間變化的趨勢輕視軟件維護。維護是極端艱巨復雜的工作，需要花費很大代價。軟件維護的費用占軟件總費用的55%~70%。軟件工程學的一個重要目標就是提高軟件的可維護性，減少軟件維護的代價。1.1.3消除軟件危機的途徑

對計算機軟件有正確的認識。認識到軟件開發(fā)是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目。應該推廣使用在實踐中總結出來的開發(fā)軟件的成功技術和方法，并繼續(xù)研究探索。應該開發(fā)和使用更好的軟件工具。總之，為了解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。

1.2.3軟件工程方法學

軟件工程包括技術和管理兩方面的內容。管理：通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。技術(軟件工程方法學)：通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學(methodology)，也稱為范型(paradigm)。軟件工程方法學3要素：方法：是完成軟件開發(fā)的各項任務的技術方法，回答“怎樣做”的問題；工具：是為運用方法而提供的自動的或半自動的軟件工程支撐環(huán)境；如，CASE(Computer-AidedSoftwareEngineering)工具過程：需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。1.3軟件生命周期

三個時期八個階段：軟件生命周期由軟件定義、軟件開發(fā)和運行維護(也稱為軟件維護)三個時期組成，每個時期又進一步劃分成若干個階段。三個時期：八個階段：軟件生命周期軟件定義軟件開發(fā)軟件維護問題定義可行性研究需求分析概要設計詳細設計編碼和單元測試綜合測試運行維護系統(tǒng)設計系統(tǒng)實現(xiàn)1.4軟件過程軟件過程：是為了獲得高質量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。過程定義了運用方法的順序、應該交付的文檔資料、為保證軟件質量和協(xié)調變化所需要采取的管理措施，以及標志軟件開發(fā)各個階段任務完成的里程碑。為獲得高質量的軟件產(chǎn)品，軟件過程必須科學、有效。傳統(tǒng)的瀑布模型實際的瀑布模型1.4.1瀑布模型瀑布模型的特點：1.階段間具有順序性和依賴性前一階段的工作完成之后，才能開始后一階段的工作；前一階段的輸出文檔就是后一階段的輸入文檔。2.推遲實現(xiàn)的觀點對于規(guī)模較大的軟件項目來說，往往編碼開始得越早最終完成開發(fā)工作所需要的時間反而越長。3.質量保證的觀點每個階段都必須完成規(guī)定的文檔，是“文檔驅動”的模型；每個階段結束前都要對所完成的文檔進行評審，盡早發(fā)現(xiàn)問題，改正錯誤。瀑布模型的優(yōu)點：可強迫開發(fā)人員采用規(guī)范的方法；嚴格地規(guī)定了每個階段必須提交的文檔；要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質量保證小組的仔細驗證。瀑布模型的缺點：只能通過文檔了解產(chǎn)品，不經(jīng)過實踐的需求是不切實際的。實際項目很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統(tǒng)開發(fā)完成瀑布模型適用于：

需求是預知的；軟件實現(xiàn)方法是成熟的；項目周期較短?？焖僭湍Ｐ?.4.2快速原型模型

快速原型：是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個子集。

快速原型模型的特點：快速原型模型不帶反饋環(huán)，軟件產(chǎn)品的開發(fā)基本上是線性順序進行的?？焖僭偷谋举|是“快速”。應該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約成本。根據(jù)原型的不同作用，有三類原型模型：探索型原型——用于開發(fā)的需求分析階段實驗型原型——主要用于設計階段演化型原型——用于及早向用戶提交一個原型系統(tǒng)快速原型模型的運用方式：

拋棄策略——探索型和實驗型采用此策略附加策略——演化型快速原型采用此策略1.4.3增量模型

增量模型把軟件產(chǎn)品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。

增量模型項目日歷時間軟件功能性和特征12345第2次增量發(fā)布增量212345第n次增量發(fā)布增量n12345第1次增量發(fā)布增量1┇5部署（發(fā)布，反饋）4構造（編碼，測試）3建模（分析，設計）2計劃1交流增量模型的優(yōu)點：人員分配靈活，剛開始不用投入大量人力資源。當配備的人員不能在設定的期限內完成產(chǎn)品時，它提供了一種先推出核心產(chǎn)品的途徑。逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學習和適應新產(chǎn)品。增量模型的難點：軟件體系結構必須是開放的。模型本身是自相矛盾的。整體——獨立構件。不同的構件并行地構建有可能加快工程進度，但是冒無法集成到一起的風險。增量模型適用于：適用于需求經(jīng)常改變的軟件開發(fā)過程。如果在項目既定的商業(yè)要求期限之前不可能找到足夠的開發(fā)人員，在這種情況下，增量模型顯得特別有用。1.4.4螺旋模型

螺旋模型的基本思想：使用原型及其他方法來盡量降低風險。把它看作在每個階段之前都增加了風險分析過程的快速原型模型。

簡化的螺旋模型完整的螺旋模型螺旋模型的優(yōu)點：主要優(yōu)勢在于它是風險驅動的。對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發(fā)的一個重要目標；減少了過多測試或測試不足所帶來的風險；維護只是模型的另一個周期，維護和開發(fā)之間沒有本質區(qū)別。螺旋模型的缺點：采用螺旋模型需要具有相當豐富的風險評估經(jīng)驗和專門知識，在風險較大的項目開發(fā)中，如果未能夠及時標識風險，勢必造成重大損失。過多的迭代次數(shù)會增加開發(fā)成本，延遲提交時間。螺旋模型適用于：特別適用于龐大、復雜并具有高風險的系統(tǒng)。適用于內部開發(fā)的大規(guī)模軟件項目。1.4.5噴泉模型

噴泉模型：是典型的面向對象生命周期模型。

“噴泉”這個詞體現(xiàn)了面向對象軟件開發(fā)過程迭代和無縫的特性。為避免使用噴泉模型開發(fā)軟件時開發(fā)過程過分無序，應該把一個線性過程(例如，快速原型模型或圖中的中心垂線)作為總目標。

噴泉模型的優(yōu)點：該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。多次反復地增加或明確目標系統(tǒng)，而不是本質性的改動，降低錯誤的可能性。噴泉模型的缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，不利于項目的管理。要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。噴泉模型適用于：適用于面向對象的軟件開發(fā)過程。第2章可行性研究回答“對于上一個階段所確定的問題有行得通的解決辦法嗎?”系統(tǒng)分析員需要進行一次大大壓縮和簡化了的系統(tǒng)分析和設計過程。研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。

2.1可行性研究的任務可行性研究的目的：不是解決問題，而是確定問題是否值得去解決。可行性研究的實質：進行一次大大壓縮簡化了的系統(tǒng)分析和設計的過程，也就是在較高層次上以較抽象的方式進行的系統(tǒng)分析和設計的過程。

可行性研究的內容：首先進一步分析和澄清問題定義，導出系統(tǒng)的邏輯模型；然后從系統(tǒng)邏輯模型出發(fā)，探索若干種可供選擇的主要解法(即系統(tǒng)實現(xiàn)方案)；對每種解法都研究它的可行性，至少應該從三方面研究每種解法的可行性

。主要方面：技術可行性，使用現(xiàn)有的技術能實現(xiàn)這個系統(tǒng)嗎?經(jīng)濟可行性，這個系統(tǒng)的經(jīng)濟效益能超過它的開發(fā)成本嗎?操作可行性，系統(tǒng)的操作方式在這個用戶組織內行得通嗎?其他方面：運行可行性，系統(tǒng)的運行方式是否可行？法律可行性，系統(tǒng)是否侵犯他人、集體或國家的利益，是否違反法律？2.4數(shù)據(jù)流圖數(shù)據(jù)流圖(DFD)：是一種圖形化技術，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換。在數(shù)據(jù)流圖中沒有任何具體的物理部件，它只是描繪數(shù)據(jù)在軟件中流動和被處理的邏輯過程。2.4.1符號基本符號：數(shù)據(jù)源點/終點：通常是人或部門，可重復表示；處理：一個處理框可以代表一系列程序、單個程序或程序的一個模塊；數(shù)據(jù)存儲：可以表示一個文件、文件的一部分、數(shù)據(jù)庫的元素或記錄的一部分等，數(shù)據(jù)存儲是處于lm靜止狀態(tài)的數(shù)據(jù)；數(shù)據(jù)流：描繪所有可能的數(shù)據(jù)流向，而不應該描繪出現(xiàn)某個數(shù)據(jù)流的條件，數(shù)據(jù)流是處于運動中的數(shù)據(jù)。2.5數(shù)據(jù)字典數(shù)據(jù)字典：是關于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型。2.5.1數(shù)據(jù)字典的內容數(shù)據(jù)字典的組成：數(shù)據(jù)流數(shù)據(jù)流分量(即數(shù)據(jù)元素)數(shù)據(jù)存儲處理(用其它工具描述更方便，如IPO圖)在數(shù)據(jù)字典中記錄數(shù)據(jù)元素的下列信息：一般信息定義使用特點控制信息分組信息

2.5.3數(shù)據(jù)字典的用途數(shù)據(jù)字典最重要的用途是作為分析階段的工具；數(shù)據(jù)字典中包含的每個數(shù)據(jù)元素的控制信息是很有價值的。很容易估計改變一個數(shù)據(jù)將產(chǎn)生的影響；數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步，而且是很有價值的一步。2.5.4數(shù)據(jù)字典的實現(xiàn)計算機實現(xiàn)：目前，數(shù)據(jù)字典幾乎總是作為CASE（計算機輔助軟件工程）“結構化分析與設計工具”的一部分實現(xiàn)的。在開發(fā)大型軟件系統(tǒng)的過程中，數(shù)據(jù)字典的規(guī)模和復雜程度迅速增加，人工維護數(shù)據(jù)字典幾乎是不可能的。人工實現(xiàn)：采用卡片形式書寫數(shù)據(jù)字典，每張卡片上保存描述一個數(shù)據(jù)的信息。每張卡片上主要應該包含下述這樣一些信息：名字、別名、描述、定義、位置。

3.1需求分析的任務

3.2與用戶溝通獲取需求的方法

3.3分析建模與規(guī)格說明

3.4實體-聯(lián)系圖

3.5數(shù)據(jù)規(guī)范化

3.6狀態(tài)轉換圖

3.7其他圖形工具

3.8驗證軟件需求第3章需求分析分析模型的結構需求分析過程應該建立3種模型，分別是：數(shù)據(jù)模型功能模型行為模型

數(shù)據(jù)字典：是分析模型的核心，它描述軟件使用或產(chǎn)生的所有數(shù)據(jù)對象。實體-聯(lián)系圖：描繪數(shù)據(jù)對象及數(shù)據(jù)對象之間的關系，是用于建立數(shù)據(jù)模型的圖形。數(shù)據(jù)流圖：描繪當數(shù)據(jù)在軟件系統(tǒng)中移動時被變換的邏輯過程，指明系統(tǒng)具有的變換數(shù)據(jù)的功能，因此，數(shù)據(jù)流圖是建立功能模型的基礎。狀態(tài)轉換圖(簡稱為狀態(tài)圖)：指明了作為外部事件結果的系統(tǒng)行為。為此，狀態(tài)轉換圖描繪了系統(tǒng)的各種行為模式(稱為“狀態(tài)”)和在不同狀態(tài)間轉換的方式。狀態(tài)轉換圖是行為建模的基礎。3.4實體-聯(lián)系圖概念性數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點對數(shù)據(jù)建立的模型。它描述了從用戶角度看到的數(shù)據(jù)，它反映了用戶的現(xiàn)實環(huán)境，且與在軟件系統(tǒng)中的實現(xiàn)方法無關。數(shù)據(jù)模型中包含3種相互關聯(lián)的信息：數(shù)據(jù)對象數(shù)據(jù)對象的屬性數(shù)據(jù)對象彼此間相互連接的關系

3.4.1數(shù)據(jù)對象

數(shù)據(jù)對象：是對軟件必須理解的復合信息的抽象。復合信息是指具有一系列不同性質或屬性的事物，僅有單個值的事物不是數(shù)據(jù)對象。數(shù)據(jù)對象可以是外部實體、事物、行為、事件、角色、單位、地點或結構等。數(shù)據(jù)對象彼此間是有關聯(lián)的。3.4.2屬性屬性：定義了數(shù)據(jù)對象的性質。必須把一個或多個屬性定義為“標識符”。根據(jù)對問題的理解來確定特定數(shù)據(jù)對象的合適的屬性。

3.4.3聯(lián)系聯(lián)系：數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關系。聯(lián)系可分為以下3種類型：一對一聯(lián)系(1∶1)一對多聯(lián)系(1∶N)多對多聯(lián)系(M∶N)聯(lián)系也可能有屬性。3.4.4實體-聯(lián)系圖的符號ER圖中包含：實體(即數(shù)據(jù)對象)，用矩形框表示；關系，用連接相關實體的菱形框表示；屬性，用橢圓形或圓角矩形表示，并用直線把實體(或關系)與其屬性連接起來。例1：某校教學管理系統(tǒng)的ER圖ER圖的優(yōu)點：比較接近人的習慣思維方式；用簡單的圖形符號表達系統(tǒng)分析員對問題域的理解，用戶也容易理解，可以作為用戶與分析員之間有效的交流工具。數(shù)據(jù)建模工具：以自動化的方式創(chuàng)建ER圖、數(shù)據(jù)字典及相關模型。AllFusionERWin輔助設計數(shù)據(jù)庫、數(shù)據(jù)對象、結構、關鍵元素ER/Studio支持實體-關系建模OracleDesigner建模、應用系統(tǒng)和數(shù)據(jù)庫設計MetaScope圖形化顯示數(shù)據(jù)ModelSphereVisibleAnalyst模型可視化分析例2：習題3.3，銀行儲蓄系統(tǒng)的ER圖銀行計算機儲蓄系統(tǒng)的工作過程大致如下：儲戶填寫的存款單或取款單由業(yè)務員鍵入系統(tǒng)，如果是存款則系統(tǒng)記錄存款人姓名、住址(或電話號碼)、身份證號碼、存款類型、存款日期、到期日期、利率及密碼(可選)等信息，并印出存單給儲戶；如果是取款而且存款時留有密碼，則系統(tǒng)首先核對儲戶密碼，若密碼正確或存款時未留密碼，則系統(tǒng)計算利息并印出利息清單給儲戶。銀行儲蓄系統(tǒng)的ER圖ER圖練習題：請為某倉庫的管理設計一個ER模型。該倉庫主要管理零件（包括零件編號、名稱、顏色、重量）的定購和供應等事項。倉庫向工程項目（包括項目編號、項目名稱、開工日期）供應零件，并且根據(jù)需要向供應商（包括供應商編號、名稱、地址）定購零件。倉庫管理系統(tǒng)的ER圖4.1概述4.2有窮狀態(tài)機4.3Petri網(wǎng)4.4Z語言第4章形式化說明技術軟件工程使用方法的分類：非形式化，用自然語言描述需求規(guī)格說明；半形式化，用數(shù)據(jù)流圖或實體-聯(lián)系圖建立模型；形式化，是描述系統(tǒng)性質的基于數(shù)學的技術，也就是說，如果一種方法有堅實的數(shù)學基礎，那么它就是形式化的。

4.1概述

4.1.1非形式化方法的缺點矛盾，指一組相互沖突的陳述。二義性，指讀者可以用不同方式理解的陳述。含糊性，幾乎不可避免地會出現(xiàn)含糊性。不完整性，不完整性可能是在系統(tǒng)規(guī)格說明中最常遇到的問題之一。抽象層次混亂，指在非常抽象的陳述中混進了一些關于細節(jié)的低層次陳述。

4.1.2形式化方法的優(yōu)點數(shù)學能夠簡潔準確地描述物理現(xiàn)象、對象或動作的結果，因此是理想的建模工具。特別適合于表示狀態(tài)，也就是表示“做什么”?？梢栽诓煌能浖こ袒顒又g平滑地過渡。不僅功能規(guī)格說明，而且系統(tǒng)設計也可以用數(shù)學表達，當然，程序代碼也是一種數(shù)學符號。它提供了高層確認的手段?？梢允褂脭?shù)學方法證明，設計符合規(guī)格說明，程序代碼正確地實現(xiàn)了設計結果。第5章總體設計5.1設計過程5.2設計原理5.3啟發(fā)規(guī)則5.4描繪軟件結構的圖形工具5.5面向數(shù)據(jù)流的設計方法設計階段：從工程管理的角度，可以將軟件設計分為總體設計階段和詳細設計階段。從技術的角度，傳統(tǒng)的結構化方法將軟件設計劃分為體系結構設計、數(shù)據(jù)設計、接口設計和過程設計4部分。面向對象方法則將軟件設計劃分為體系結構設計、類設計/數(shù)據(jù)設計、接口設計和構件級設計4部分。模塊獨立程度的兩個定性標準度量：耦合衡量不同模塊彼此間互相依賴(連接)的緊密程度。耦合要低，即每個模塊和其他模塊之間的關系要簡單；內聚衡量一個模塊內部各個元素彼此結合的緊密程度。內聚要高，每個模塊完成一個相對獨立的特定子功能。1.耦合耦合：是對一個軟件結構內不同模塊之間互連程度的度量。要求：在軟件設計中應該追求盡可能松散耦合的系統(tǒng)?？梢匝芯?、測試或維護任何一個模塊，而不需要對系統(tǒng)的其他模塊有很多了解；模塊間聯(lián)系簡單，發(fā)生在一處的錯誤傳播到整個系統(tǒng)的可能性就很小；模塊間的耦合程度強烈影響系統(tǒng)的可理解性、可測試性、可靠性和可維護性。耦合程度的度量：(1)非直接耦合/完全獨立(nodirectcoupling)如果兩個模塊中的每一個都能獨立地工作而不需要另一個模塊的存在，那么它們完全獨立。在一個軟件系統(tǒng)中不可能所有模塊之間都沒有任何連接。(2)數(shù)據(jù)耦合(datacoupling)如果兩個模塊彼此間通過參數(shù)交換信息，而且交換的信息僅僅是數(shù)據(jù)，那么這種耦合稱為數(shù)據(jù)耦合。評價：系統(tǒng)中至少必須存在這種耦合。一般說來，一個系統(tǒng)內可以只包含數(shù)據(jù)耦合。數(shù)據(jù)耦合是理想的目標。維護更容易，對一個模塊的修改不會是另一個模塊產(chǎn)生退化錯誤。(3)控制耦合(controlcoupling)如果兩個模塊彼此間傳遞的信息中有控制信息，這種耦合稱為控制耦合。評價：控制耦合往往是多余的，把模塊適當分解之后通?？梢杂脭?shù)據(jù)耦合代替它。被調用的模塊需知道調用模塊的內部結構和邏輯，降低了重用的可能性。(4)特征耦合(stampcoupling)當把整個數(shù)據(jù)結構作為參數(shù)傳遞而被調用的模塊只需要使用其中一部分數(shù)據(jù)元素時，就出現(xiàn)了特征耦合。評價：被調用的模塊可使用的數(shù)據(jù)多于它確實需要的數(shù)據(jù)，這將導致對數(shù)據(jù)的訪問失去控制，從而給計算機犯罪提供了機會。無論何時把指針作為參數(shù)進行傳遞，都應該仔細檢查該耦合。(5)公共環(huán)境耦合(commoncoupling)當兩個或多個模塊通過一個公共數(shù)據(jù)環(huán)境相互作用時，它們之間的耦合稱為公共環(huán)境耦合。公共環(huán)境可以是全程變量、共享的通信區(qū)、內存的公共覆蓋區(qū)、任何存儲介質上的文件、物理設備等等。公共環(huán)境耦合的類型：

一個模塊往公共環(huán)境送數(shù)據(jù)，另一個模塊從公共環(huán)境取數(shù)據(jù)。數(shù)據(jù)耦合的一種形式，是比較松散的耦合。兩個模塊都既往公共環(huán)境送數(shù)據(jù)又從里面取數(shù)據(jù)，這種耦合比較緊密，介于數(shù)據(jù)耦合和控制耦合之間。評價：與結構化編程矛盾，生成的代碼完全不可讀。如果在一個模塊中對一個全局變量的聲明進行修改，必須修改能夠訪問該全局變量的每一個模塊。公共環(huán)境耦合的模塊難于重用，必須提供一個全局變量的清單。即使模塊本身不改變，它和產(chǎn)品中其他模塊之間公共環(huán)境耦合的實例數(shù)也會變化非常大。潛在危險很大。模塊暴露出必需要更多的數(shù)據(jù)，難以控制數(shù)據(jù)存取，而且會導致計算機犯罪。有些情況下公共環(huán)境耦合更好。(6)內容耦合(contentcoupling)最高程度的耦合是內容耦合。如果出現(xiàn)下列情況之一，兩個模塊間就發(fā)生了內容耦合：一個模塊訪問另一個模塊的內部數(shù)據(jù)；一個模塊不通過正常入口轉到另一個模塊的內部；兩個模塊有一部分程序代碼重疊；一個模塊有多個入口。耦合是影響軟件復雜程度的一個重要因素。應該采取下述設計原則：

盡量使用數(shù)據(jù)耦合，

少用控制耦合和特征耦合，

限制公共環(huán)境耦合的范圍，

完全不用內容耦合。2.內聚內聚：標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱藏和局部化概念的自然擴展。簡單地說，理想內聚的模塊只做一件事情。要求：設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚不要使用。內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。實踐表明內聚更重要，應該把更多注意力集中到提高模塊的內聚程度上。內聚程度的度量：(1)偶然內聚(coincidentalcohesion)如果一個模塊完成一組任務，這些任務彼此間即使有關系，關系也是很松散的，就叫做偶然內聚。MA=B+CGETCHERIFR=5THENS=1評價：模塊內各元素之間沒有實質性聯(lián)系，很可能在一種應用場合需要修改這個模塊，在另一種應用場合又不允許這種修改，從而陷入困境；可理解性差，可維護性產(chǎn)生退化；模塊是不可重用的。解決方案：將模塊分成更小的模塊，每個小模塊執(zhí)行一個操作。(2)邏輯內聚(logicalcohesion)如果一個模塊完成的任務在邏輯上屬于相同或相似的一類，則稱為邏輯內聚。評價：接口難以理解，造成整體上不易理解；完成多個操作的代碼互相糾纏在一起，即使局部功能的修改有時也會影響全局，導致嚴重的維護問題；難以重用。解決方案：模塊分解。(3)時間內聚(temporalcohesion)如果一個模塊包含的任務必須在同一段時間內執(zhí)行，就叫時間內聚。執(zhí)行初始化打開舊主文件、新主文件、事務文件和打印文件；初始化銷售地區(qū)表；讀第一條事務記錄和第一條舊主文件記錄；評價：時間關系在一定程度上反映了程序某些實質，所以時間內聚比邏輯內聚好一些。模塊內操作之間的關系很弱，與其他模塊的操作卻有很強的關聯(lián)。時間內聚的模塊不太可能重用。(4)過程內聚(proceduralcohesion)如果一個模塊內的處理元素是相關的，而且必須以特定次序執(zhí)行，則稱為過程內聚。使用程序流程圖作為工具設計軟件時，常常通過研究流程圖確定模塊的劃分，這樣得到的往往是過程內聚的模塊。評價：比時間內聚好，至少操作之間是過程關聯(lián)的。仍是弱連接，不太可能重用模塊。解決方案：分割為單獨的模塊，每個模塊執(zhí)行一個操作。(5)通信內聚(communicationalcohesion)如果模塊中所有元素都使用同一個輸入數(shù)據(jù)和(或)產(chǎn)生同一個輸出數(shù)據(jù)，則稱為通信內聚。即在同一個數(shù)據(jù)結構上操作。評價：模塊中各操作緊密相連，比過程內聚更好。不能重用。解決方案：分成多個模塊，每個模塊執(zhí)行一個操作。(6)順序內聚(sequentialcohesion)如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執(zhí)行，則稱為順序內聚。評價：根據(jù)數(shù)據(jù)流圖劃分模塊時，通常得到順序內聚的模塊，這種模塊彼此間的連接往往比較簡單。(7)功能內聚(functionalcohesion)如果模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚。評價：模塊可重用，應盡可能重用；可隔離錯誤，維護更容易；擴充產(chǎn)品功能時更容易。七種內聚的優(yōu)劣評分結果：高內聚：功能內聚10分順序內聚 9分 中內聚：通信內聚 7分 過程內聚 5分低內聚：時間內聚 3分邏輯內聚 1分偶然內聚 0分設計時力爭做到高內聚，并且能夠辨認出低內聚的模塊。第6章詳細設計6.1結構程序設計6.2人機界面設計6.3過程設計的工具6.4面向數(shù)據(jù)結構的設計方法6.5程序復雜程度的定量度量6.6小結6.1結構程序設計定義：如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結構進行連接，并且每個代碼塊只有一個入口和一個出口，則稱這個程序是結構化的。70年代初N.Wirth在Pascal語言中設置支持“順序結構”、“IF-THEN-ELSE選擇結構”、“DO-WHILE重復結構”或“DO-UNTIL重復結構”三種基本控制結構語句。6.13種基本的控制結構6.3過程設計的工具1．圖形工具：利用圖形工具可以把過程的細節(jié)用圖形描述出來。如程序流程圖，N-S圖，PAD。2．表格工具：用一張表來描述過程的細節(jié)，在這張表中列出了各種可能的操作和相應的條件。如判定表,判定樹。3．語言工具：用某種高級語言（叫做偽碼）來描述過程的細節(jié)。如PDL。

缺點：本質上不具備逐步求精的特點，使程序員過早地考慮程序的控制流程，而不去考慮程序的全局結構；轉移控制太方便；不易表示數(shù)據(jù)結構。

趨勢：使用越來越少。

ISO認可的規(guī)定符號：優(yōu)點：直觀、容易掌握，且歷史“久”，使用廣泛。6.3.1程序流程圖（程序框圖）圖6.3程序流程圖中使用的符號。(1)順序型AB3種基本控制結構(2)選擇型PBAFT(2)多情況選擇型(case)TA1FP=1TA2FP=2…TAnFP=n(3)先判定型循環(huán)

(do-while)TPSF后判定型循環(huán)

(do-until)FSTP例1、某模塊有兩個輸入a和b，一個輸出c，當滿足條件(a>0)and(b<2)時，c=a+b，否則c=a-b。畫出該模塊的程序流程圖。ab(a>0)and(b<2)c=a-bc=a+bFTc6.3.2盒圖(N-S圖)

Nassi和Shneiderman

1973年提出，是一種符合結構化程序設計原則的圖形描述工具，用方框圖代替?zhèn)鹘y(tǒng)的流程圖。圖6.4盒圖的基本符號

3種基本控制結構：

(1)順序型ABCABF

PTthen–部分else–部分(2)選擇型（If–then–else）

(2)多分支選擇型(CASE型)A1＝1A2An........P＝2＝n(3)WHILE重復型UNTIL重復型

S（循環(huán)體）DO-WHILEPS（循環(huán)體）DO-UNTILP(先測試循環(huán))(后測試循環(huán))循環(huán)條件移出標記ACBFX6TA:D(調用結構)x4TFDo-Untilx5ighfkx1TFbDo-Untilx6ajx21cDo-Whilex323dek:例：圖4.43盒圖（N-S圖）的特點：(1)功能域(即，一個特定控制結構的作用域)明確，可以從盒圖上一眼就看出來。(2)不可能任意轉移控制。(3)很容易確定局部和全程數(shù)據(jù)的作用域。(4)很容易表現(xiàn)嵌套關系，也可以表示模塊的層次結構。注、使程序員用結構化的方式思考和解決問題。例1、某模塊有兩個輸入a和b，一個輸出c，當滿足條件(a>0)and(b<2)時，c=a+b，否則c=a-b。畫出該模塊的N-S圖。c=a+b(a>0)and(b<2)TFbac=a-bc【例2、某模塊有三個輸入a、b和c，一個輸出s，當a=1時，s=b+2c，當a=2時，s=2b-c，當a=3時，s=b。畫出該模塊的N-S圖。】a23s=2b-cs=bcbas=b+2c1s6.3.3PAD圖（問題分析圖）1973年由日本日立公司發(fā)明。它用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。圖6.5PAD圖的基本符號

3種基本控制結構:(1)順序型(2)選擇型

ABCABTFP(2)多分支選擇型(CASE型)

A1A2An...P＝1＝2＝n(3)WHILE重復型

WHILE

PS(先測試循環(huán))等價的PASCAL語言：WHILEPDOSUNTIL重復型

(后測試循環(huán))UNTIL

PS等價的PASCAL語言：REPEATSUNTILPdef格式：def

開始

結束

aj

Untilx5i

Untilx6bx1fx4ghx2de=1=2=3

While

x3c例：開始

結束

aj

Untilx5i

Untilx6bx1kfx4gh例：defkx2de=1=2=3

Whilex3c定義PAD圖的主要優(yōu)點：（1）使用表示結構化控制結構的PAD符號所設計出來的程序必然是結構化程序。（2）PAD圖所描繪的程序結構十分清晰。圖中最左面的豎線是程序的主線，即第一層結構。隨著程序層次的增加，PAD圖逐漸向右延伸，每增加一個層次，圖形向右擴展一條豎線。PAD圖中豎線的總條數(shù)就是程序的層次數(shù)。(3)用PAD圖表現(xiàn)程序邏輯，易讀、易懂、易記。PAD圖是二維樹形結構的圖形，程序從圖中最左豎線上端的結點開始執(zhí)行，自上而下，從左向右順序執(zhí)行，遍歷所有結點。(4)容易將PAD圖轉換成高級語言源程序，這種轉換可用軟件工具自動完成，從而可省去人工編碼的工作，有利于提高軟件可靠性和軟件生產(chǎn)率。(5)即可用于表示程序邏輯，也可用于描繪數(shù)據(jù)結構。(6)PAD圖的符號支持自頂向下、逐步求精方法的使用。開始時設計者可以定義一個抽象的程序，隨著設計工作的深入而使用def符號逐步增加細節(jié)，直至完成詳細設計。例1、某模塊有兩個輸入a和b，一個輸出c，當滿足條件(a>0)and(b<2)時，c=a+b，否則c=a-b。畫出該模塊的PAD。abc=a+bc=a-b(a>0)and(b<2)c【例2、某模塊有三個輸入a、b和c，一個輸出s，當a=1時，s=b+2c，當a=2時，s=2b-c，當a=3時，s=b。畫出該模塊的PAD?！縜bcs=b+2cs=2b-cs=ba＝1＝3＝2s*P141:3畫出下列偽碼程序的程序流程圖、盒圖和PAD圖。STARTIFPTHENWHILEqDOfENDDOELSEBLOCKgnENDBLOCKENDIFSTOP作業(yè)及解答（第6章）TqfF程序流程圖g

WhileqfpnPAD圖N-S圖6.3.6過程設計語言（PDL）/偽碼

一種用于描述功能模塊的算法設計和加工細節(jié)的語言。結構化語言介于自然語言和形式語言之間的半形式化語言。結構化語言（PDL)結構化語言是一種書寫過程規(guī)范的方法，它將結構化編程技術和敘述性英語結合起來。結構化語言非常適合用來描述帶有一系列處理步驟和相對簡單的控制邏輯（ifthenelse;whiledo;repeatuntil;caseof等）的過程。例：PROCEDUREspell_checkISBEGIN

SplitdocumentintosinglewordsLookupwordsindictionaryDisplaywordswhicharenotindictionaryCreateanewdictionaryENDspell_checkExternalstatementsInternalStatements特點：①有固定的關鍵字（一律大寫）外語法，用于定義控制結構和數(shù)據(jù)結構；例：上頁②內語法用自然語言描述；③有數(shù)據(jù)說明，例如：

TYPEnumberISSTRINGLENGTH(12)TYPEtableISINSTANCEOFsymboltable

抽象類型④模塊定義和調用的技術，應該提供各種接口描述模式定義：

PROCEDURE<子程序名><屬性>

INTERFACE<參數(shù)表>

I\O等

pseudocodelines（偽碼行）

END

調用：

PERFORM<子程序名>USING<參數(shù)表>PDL優(yōu)點：可以作為注釋直接插在源程序中間。(2)可以使用普通的正文編輯程序或文字處理系統(tǒng)，很方便地完成PDL的書寫和編輯工作。(3)可以自動由PDL生成程序代碼。PDL缺點:不如圖形工具形象直觀；描述復雜的條件組合與動作間的對應關系時，不如判定表清晰簡單。注、通常以PDL為主，對存在復雜判斷問題的加工邏輯，可輔之以判定表和判定樹，判定表更嚴密，判定樹更易讀。6.5程序復雜程度的定量度量

軟件復雜性主要表現(xiàn)在程序的復雜性。程序的復雜性主要指模塊內程序的復雜性。它直接關聯(lián)到軟件開發(fā)費用的多少、開發(fā)周期長短和軟件內部潛伏錯誤的多少。同時它也是軟件可理解性的另一種度量。McCabe方法Halstead方法6.5.1McCabe方法McCabe方法：根據(jù)程序控制流的復雜程度定量度量程序的復雜程度。其結果稱為程序的環(huán)形復雜度。方法:先畫出流圖，然后用該圖的環(huán)路數(shù)作為程序復雜性的度量值。流圖流圖：是“退化了的”程序流程圖，僅僅描繪程序的控制流程，不表現(xiàn)對數(shù)據(jù)的具體操作以及分支或循環(huán)的具體條件。流圖組成：圓：結點（一個圓代表一條或多條語句）。箭頭線：邊。同下圖一樣。圖6.16由PDL翻譯成的流圖*畫出下列偽碼程序的程序圖，并求出復雜性度量值V(G)?2.計算環(huán)形復雜度的方法(1)環(huán)形復雜度=流圖中的區(qū)域數(shù)。(2)環(huán)形復雜度V(G)=E-N+2,其中E是邊數(shù)，N是結點數(shù)。(3)環(huán)形復雜度V(G)=P+1，其中P是判定結點數(shù)。圖6.16由PDL翻譯成的流圖R1R2R3R4(2)V(G)=E-N+2

=11-9+2=4(1)封閉區(qū)域個數(shù)4procedure:sort1:dowhilerecordsremain2:readrecord:

ifrecordfield1=03:thenprocessrecord;storeinbuffer;incremertcounter;4:elseifrecordfield2=05:thenresetcounter;6:elseprocessrecord;storeinfile;7a:endifendif7b:enddo8:end(3)3個判定,V(G)=3+1=43.環(huán)形復雜度的用途McCabe研究大量程序后發(fā)現(xiàn)，環(huán)形復雜度高的程序往往是最困難、最容易出問題的程序。實踐表明，模塊規(guī)模以V(G)≤10為宜，V(G)=10是模塊規(guī)模的一個更科學更精確的上限。缺點：①對于不同種類的控制流的復雜度不能區(qū)分。②簡單IF語句與循環(huán)語句的復雜性同等看待。③嵌套IF語句與簡單CASE的復雜性是一樣的。④模塊間接口當成一個簡單分支一樣處理。⑤一個具有1000行的順序程序與一行語句的復雜性相同。第7章實現(xiàn)7.1編碼7.2軟件測試基礎7.3單元測試7.4集成測試7.5確認測試7.6白盒測試技術7.7黑盒測試技術7.8調試7.9軟件可靠性7.2.3測試方法黑盒測試(功能測試)：把程序看作一個黑盒子；完全不考慮程序的內部結構和處理過程；是在程序接口進行的測試。白盒測試(結構測試)：把程序看成裝在一個透明的盒子里；測試者完全知道程序的結構和處理算法；按照程序內部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預定要求正確工作。黑盒測試與白盒測試優(yōu)缺點比較：黑盒測試白盒測試優(yōu)點①適用于各階段測試②從產(chǎn)品功能角度測試③容易入手生成測試數(shù)據(jù)①可構成測試數(shù)據(jù)使特定程序部分得到測試②有一定的充分性度量手段③可獲較多工具支持缺點①某些代碼得不到測試②如果規(guī)格說明有誤，則無法發(fā)現(xiàn)③不易進行充分性測試①通常不易生成測試數(shù)據(jù)②無法對未實現(xiàn)規(guī)格說明的部分進行測試③工作量大，通常只用于單元測試，有應用局限性質一種確認技術，回答“我們在構造一個正確的系統(tǒng)嗎？”一種驗證技術，回答“我們在正確地構造一個系統(tǒng)嗎？”7.2.4測試步驟1.模塊測試(單元測試)保證每個模塊作為一個單元能正確運行；發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。2.子系統(tǒng)測試把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試；著重測試模塊的接口。3.系統(tǒng)測試把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試；發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤；不論是子系統(tǒng)測試還是系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。4.驗收測試(確認測試)把軟件系統(tǒng)作為單一的實體進行測試；它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試；發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。5.平行運行同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)；比較新舊兩個系統(tǒng)的處理結果；可以在準生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風險；用戶能有一段熟悉新系統(tǒng)的時間；可以驗證用戶指南和使用手冊之類的文檔；能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，可以用測試結果驗證性能指標。7.3.3計算機測試必須為每個單元測試開發(fā)驅動程序和(或)存根程序。驅動程序是一個“主程序”，它接收測試數(shù)據(jù)，傳送給被測試的模塊，并且印出有關的結果。存根程序代替被測試的模塊所調用的模塊。它使用被它代替的模塊的接口，可能做最少量的數(shù)據(jù)操作，印出對入口的檢驗或操作結果，并且把控制歸還給調用它的模塊。驅動程序和存根程序代表開銷，通常并不把它們作為軟件產(chǎn)品的一部分交給用戶。7.4集成測試集成測試是測試和組裝軟件的系統(tǒng)化技術，主要目標是發(fā)現(xiàn)與接口有關的問題。由模塊組裝成程序時有兩種方法：非漸增式測試方法漸增式測試方法非漸增式測試方法：先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序；非漸增式測試一下子把所有模塊放在一起，并把龐大的程序作為一個整體來測試，測試者面對的情況十分復雜。在龐大的程序中想要診斷定位一個錯誤是非常困難的，改正錯誤更是極端困難，而且一旦改正一個錯誤之后，馬上又會遇到新的錯誤。漸增式測試方法：把下一個要測試的模塊同已經(jīng)測試好的那些模塊結合起來進行測試；測試完以后再把下一個應該測試的模塊結合進來測試，每次增加一個模塊；實際上同時完成單元測試和集成測試；把程序劃分成小段來構造和測試，在這個過程中比較容易定位和改正錯誤；漸增方式有兩種集成策略：自頂向下自底向上7.4.1自頂向下集成從主控制模塊開始，沿著程序的控制層次向下移動，逐漸把各個模塊結合起來。在把附屬于主控制模塊的那些模塊組裝到程序結構中去時，或者使用深度優(yōu)先的策略，或者使用寬度優(yōu)先的策略。深度優(yōu)先：先組裝在軟件結構的一條主控制通路上的所有模塊。寬度優(yōu)先：沿軟件結構水平地移動，把處于同一個控制層次上的所有模塊組裝起來。按深度優(yōu)先策略組裝按寬度優(yōu)先策略組裝把模塊結合進軟件結構的過程由下述4個步驟完成：第一步，對主控制模塊進行測試，測試時用存根程序代替所有直接附屬于主控制模塊的模塊；第二步，根據(jù)選定的結合策略(深度優(yōu)先或寬度優(yōu)先)，每次用一個實際模塊代換一個存根程序(新結合進來的模塊往往又需要新的存根程序)；第三步，在結合進一個模塊的同時進行測試；第四步，為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試(即，全部或部分地重復以前做過的測試)。從第二步開始不斷地重復進行上述過程，直到構造起完整的軟件結構為止。優(yōu)點：能夠在測試的早期對主要的控制或關鍵的抉擇進行檢驗。如果選擇深度優(yōu)先的結合方法，可以在早期實現(xiàn)軟件的一個完整的功能并且驗證這個功能。缺點：存根程序代替了低層次的模塊，在軟件結構中沒有重要的數(shù)據(jù)自下往上流。用下述步驟可以實現(xiàn)自底向上的結合策略：第一步，把低層模塊組合成實現(xiàn)某個特定的軟件子功能的族；第二步，寫一個驅動程序(用于測試的控制程序)，協(xié)調測試數(shù)據(jù)的輸入和輸出；第三步，對由模塊組成的子功能族進行測試；第四步，去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。上述第二步到第四步實質上構成了一個循環(huán)。7.4.2自底向上集成自底向上結合自底向上結合7.4.3不同集成測試策略的比較不同集成測試方法的比較：方法優(yōu)點缺點非漸增式?jīng)]有錯誤隔離手段主要設計錯誤發(fā)現(xiàn)遲潛在可重用代碼測試不充分需要驅動程序和存根程序自頂向下具有錯誤隔離手段主要設計錯誤發(fā)現(xiàn)早不需要驅動程序潛在可重用代碼測試不充分需要存根程序自底向上具有錯誤隔離手段潛在可重用代碼能充分測試不需要存根程序主要設計錯誤發(fā)現(xiàn)遲需要驅動程序混合具有錯誤隔離手段主要設計錯誤發(fā)現(xiàn)早潛在可重用代碼能充分測試混合策略：改進的自頂向下測試方法基本上使用自頂向下的測試方法，但是在早期使用自底向上的方法測試軟件中的少數(shù)關鍵模塊。能在測試的早期發(fā)現(xiàn)關鍵模塊中的錯誤；測試關鍵模塊時需要驅動程序。混合法對軟件結構中較上層使用的自頂向下方法與對軟件結構中較下層使用的自底向上方法相結合。兼有兩種方法的優(yōu)缺點，當被測試的軟件中關鍵模塊比較多時，這種混合法可能是最好的折衷方法。7.6白盒測試技術所謂測試方案包括具體的測試目的（例如，預定要測試的具體功能），應該輸入的測試數(shù)據(jù)和預期的結果。通常又把測試數(shù)據(jù)和預期的輸出結果稱為測試用例。7.6.1邏輯覆蓋有選擇地執(zhí)行程序中某些最有代表性的通路是對窮盡測試的惟一可行的替代辦法。從覆蓋源程序語句的詳盡程度分析，大致有以下一些不同的覆蓋標準：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋1.語句覆蓋含義：選擇足夠多的測試數(shù)據(jù)，使被測程序中每個語句至少執(zhí)行一次。分析：執(zhí)行路徑sacbed測試用例：A＝2，B＝0，X＝4

覆蓋sacbed語句覆蓋特點：語句覆蓋對程序的邏輯覆蓋很少。語句覆蓋只關心判定表達式的值，而沒有分別測試判定表達式中每個條件取不同值時的情況。語句覆蓋是很弱的邏輯覆蓋標準。

2.判定覆蓋（分支覆蓋）含義：不僅每個語句必須至少執(zhí)行一次，而且每個判定的每種可能的結果都應該至少執(zhí)行一次。所有判定分支：(1)a點判定為T(2)a點判定為F(3)b點判定為T(4)b點判定為F測試用例：Ⅰ.滿足(1)(4)A＝3，B＝0，X＝3

覆蓋sacbdⅡ.滿足(2)(3)A＝2，B＝1，X＝1覆蓋sabed或者Ⅰ.滿足(1)(3)A＝2，B＝0，X＝3

覆蓋sacbed

Ⅱ.滿足(2)(4)A＝3，B＝1，X＝1

覆蓋sabd特點：比語句覆蓋強，但對程序邏輯的覆蓋程度仍不高。

3.條件覆蓋含義：不僅每個語句至少執(zhí)行一次，而且使判定表達式中的每個條件都取到各種可能的結果。所有條件：(1)A＞1(2)A≤1(3)B＝0(4)B≠0(5)A＝2(6)A≠2(7)X＞1(8)X≤1測試用例：Ⅰ.滿足(1)(3)(5)(7)A＝2，B＝0，X＝4

覆蓋sacbed

Ⅱ.滿足(2)(4)(6)(8)A＝1，B＝1，X＝1覆蓋sabd

或者Ⅰ.滿足(1)(3)(5)(8)A＝2，B＝0，X＝1

覆蓋sacbed

Ⅱ.滿足(2)(4)(6)(7)

A＝1，B＝1，X＝2

覆蓋sabed或者……條件覆蓋特點：條件覆蓋通常比判定覆蓋強，因為它使每個條件都取到了兩個不同的結果，判定覆蓋卻只關心整個判定表達式的值。但也有反例，如第二組測試用例。判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋。4.判定/條件覆蓋含義：使得判定表達式中的每個條件都取到各種可能的值，每個判定表達式也都取到各種可能的結果。測試用例：Ⅰ.滿足條件(1)(3)(5)(7)

和判定(1)(3)A＝2，B＝0，X＝4

覆蓋sacbed

Ⅱ.滿足條件(2)(4)(6)(8)和判定(2)(4)A＝1，B＝1，X＝1

覆蓋sabd

特點：有時判定/條件覆蓋也并不比條件覆蓋更強。

5.條件組合覆蓋含義：要求選取足夠多的測試數(shù)據(jù)，使得每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次。條件組合：(1)A＞1，B＝0

(2)A＞1，B≠0(3)A≤1，B＝0

(4)A≤1，B≠0(5)A＝2，X＞1

(6)A＝2，X≤1(7)A≠2，X＞1

(8)A≠2，X≤15.條件組合覆蓋測試用例：Ⅰ.滿足(1)(5)A＝2，B＝0，X＝4

覆蓋sacbed

Ⅱ.滿足(2)(6)A＝2，B＝1，X＝1

覆蓋sabedⅢ.滿足(3)(7)A＝1，B＝0，X＝2

覆蓋sabed

Ⅳ.滿足(4)(8)A＝1，B＝1，X＝1

覆蓋sabd條件組合覆蓋特點：條件組合覆蓋是前述幾種覆蓋標準中最強的。滿足條件組合覆蓋標準的測試數(shù)據(jù)，也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋標準。但是，條件組合覆蓋標準的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。（4組數(shù)據(jù)都沒有測試到sacbd）

從對程序路徑的覆蓋程度分析的邏輯覆蓋標準：6.點覆蓋含義：選取足夠多的測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖的每個結點一次。特點：由于流圖的每個結點與一條或多條語句相對應，因此點覆蓋標準和語句覆蓋標準是相同的。7.邊覆蓋含義：選取足夠多測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖中每條邊一次。特點：通常邊覆蓋和判定覆蓋是一致的。8.路徑覆蓋含義：選取足夠多測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。

語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋點覆蓋邊覆蓋7.6.2控制結構測試1.基本路徑測試基本路徑測試是TomMcCabe提出的一種白盒測試技術。首先計算程序的環(huán)形復雜度；以該復雜度為指南定義執(zhí)行路徑的基本集合；從該基本集合導出的測試用例可保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值。

i=1;total.input=total.valid=0;sum=0;DOWHILEvalue[i]<>-999 ANDtotal.input<100incrementtotal.inputby1;IFvalue[i]>=minimumANDvalue[i]<=maximumTHENincrementtotal.validby1;sum=sum+value[i];ENDIFincrementiby1;ENDDOIFtotal.valid>0THENaverage=sum/total.valid;ELSEaverage=-999;ENDIF例：求平均值過程

(1)根據(jù)過程設計結果畫出相應的流圖。1234567891011121312345698710121113(2)計算流圖的環(huán)形復雜度。

V(G)=6(3)確定線性獨立路徑的基本集合。所謂獨立路徑是指至少引入程序的一個新處理語句集合或一個新條件的路徑。用流圖術語描述，獨立路徑至少包含一條在定義該路徑之前不曾用過的邊。

路徑1：1－2－10－11－13路徑2：1－2－10－12－13路徑3：1－2－3－10－11(12)－13路徑4：1－2－3－4－5－8－9－2－10－11(12)－13路徑5：1－2－3－4－5－6－8－9－2－10－11(12)－13路徑6：1－2－3－4－5－6－7－8－9－2－10－11(12)－137.7黑盒測試技術黑盒測試著重測試軟件功能，錯誤類型為：功能不正確或遺漏了功能；界面錯誤；數(shù)據(jù)結構錯誤或外部數(shù)據(jù)庫訪問錯誤；性能錯誤；初始化和終止錯誤。測試標準：測試用例盡可能少；一個測試用例能指出一類錯誤。7.7.1等價劃分等價劃分是一種黑盒測試技術，把程序的輸入域劃分成若干個數(shù)據(jù)類，據(jù)此導出測試用例。等價劃分法力圖設計出能發(fā)現(xiàn)若干類錯誤的測試用例，從而減少測試用例的數(shù)目。

每類中的一個典型值在測試中的作用與這一類中所有其他值的作用相同。使用等價劃分法設計測試方案首先需要劃分輸入數(shù)據(jù)的等價類。常常還需要分析輸出數(shù)據(jù)的等價類，以便根據(jù)輸出數(shù)據(jù)的等價類導出對應的輸入數(shù)據(jù)等價類。7.7.2邊界值分析經(jīng)驗表明，處理邊界情況時程序最容易發(fā)生錯誤。例如，許多程序錯誤出現(xiàn)在下標、純量、數(shù)據(jù)結構和循環(huán)等等的邊界附近。使用邊界值分析方法設計測試方案首先應該確定邊界情況。選取的測試數(shù)據(jù)應該剛好等于、剛剛小于和剛剛大于邊界值。通常設計測試方案時總是聯(lián)合使用等價劃分和邊界值分析兩種技術。7.7.3錯誤推測不同類型不同特點的程序通常又有一些特殊的容易出錯的情況。因此必須依靠測試人員的經(jīng)驗和直覺，從各種可能的測試方案中選出一些最可能引起程序出錯的方案。錯誤推測法在很大程度上靠直覺和經(jīng)驗進行。它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)它們選擇測試方案。7.9軟件可靠性

7.9.1基本概念軟件可靠性：程序在給定的時間間隔內，按照規(guī)格說明書的規(guī)定成功地運行的概率。軟件的可用性：程序在給定的時間點，按照規(guī)格說明書的規(guī)定，成功地運行的概率。第8章維護8.1軟件維護的定義8.2軟件維護的特點8.3軟件維護過程8.4軟件的可維護性8.5預防性維護8.6軟件再工程過程

8.1軟件維護的定義所謂軟件維護就是在軟件已經(jīng)交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程。可分為4項活動：

改正性維護

適應性維護

完善性維護

預防性維護

改正性維護：把診斷和改正錯誤的過程稱為改正性維護。改正性維護占17%～21%。

適應性維護：為了和變化了的環(huán)境適當?shù)嘏浜隙M行的修改軟件的活動，是既必要又經(jīng)常的維護活動。包括外部環(huán)境和數(shù)據(jù)環(huán)境的變化。適應性維護占18%～25%。

完善性維護：為了滿足在用戶提出的增加新功能或修改已有功能的要求和一般性的改進要求，需要進行完善性維護。包括功能和性能的要求。完善性維護占50%～66%。預防性維護：“把今天的方法學應用于昨天的系統(tǒng)以滿足明天的需要?！?/p>

采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分，主動地進行重新設計、編碼和測試。預防性維護占4%左右。

只有預防性維護是主動的，其他維護都是被動的。各類維護工作量所占比例維護工作量在軟件生命周期所占比例9.1.1傳統(tǒng)方法的缺點★結構化分析方法：面向功能 軟件結構嚴重依賴于功能，而功能是軟件開發(fā)中最不穩(wěn)定的因素?！飻?shù)據(jù)和操作相分離9.1.2面向對象開發(fā)方法OOSD

（Object-OrientedSoftwareDevelopment）是一種把面向對象的思想應用于軟件開發(fā)過程，指導開發(fā)活動的系統(tǒng)方法。

面向對象=對象(objects)+類(classes)+繼承(inheritance)+通信(communicationwithmessages)9.1.3面向對象方法的要點

認為客觀世界是由各種對象組成的，任何事物都是對象。

把所有對象都劃分成各種對象類(簡稱為類，class)，每個對象類都定義了一組數(shù)據(jù)和一組方法。

按照子類(或稱為派生類)與父類(或稱為基類)的關系，把若干個對象類組成一個層次結構的系統(tǒng)(也稱為類等級)。

對象彼此之間僅能通過傳遞消息互相聯(lián)系。9.1.4面向對象方法組成

OOSD由三部分組成：

OOA(Object-OrientedAnalysis)面向對象的分析

OOD(Object-OrientedDesign)面向對象的設計

OOP(Object-OrientedProgram)面向對象的程序設計OOA強調的是對一個系統(tǒng)中的對象特征和行為的定義。建立系統(tǒng)的三類模型。OOD與OOA密切配合順序實現(xiàn)對現(xiàn)實世界的進一步建模。OOP是面向對象的技術中發(fā)展最快的，使用面向對象的程序設計語言，進行編碼。9.2面向對象的概念對象1.類(class)2.實例(instance)3.消息(message)4.方法(method)5.屬性(attribute)6.封裝(encapsulation)7.繼承(inheritance)8.多態(tài)性(polymorphism)9.重載(overloading)9.3面向對象建模(I)

面向對象方法最基本的原則，是按照人們習慣的思維方式，用面向對象觀點建立問題域的模型，開發(fā)出盡可能自然地表現(xiàn)求解方法的軟件。

OMT（ObjectModelTechnology）是一種軟件工程方法學，支持整個面向對象軟件生命周期，它覆蓋了問題構成、分析、設計和實現(xiàn)等階段。

9.3面向對象建模(II)面向對象開發(fā)軟件，需要建立3種