1、第一章 軟件工程學概論1、軟件危機產生的原因軟件本身的特點 ：難于維護、邏輯復雜 軟件開發與維護的方法不正確 ：忽略需求分析重要性、輕視軟件維護 課本表述：1、軟件不同于硬件，它是計算機中的邏輯部件而不是物理部件2、軟件不同于一般程序， 它的一個顯著特點是規模龐大， 而且程序的復雜性將規模的 增加而呈現指數上升。3、軟件本身特有的特點確實給開發和維護帶了一些客觀困難4、軟件開發與維護有關的許多錯誤認識與做法有關(忽略需求分析，輕視軟件維護)5、對用戶要求沒有完整準確的認識就匆忙開始著手編寫程序6、在軟件不同階段進行修改需要付出的代價是很不相同的2、軟件危機的表現(什么是軟件危機)(1) 、成本

2、高：(2) 、軟件質量得不到保證： 軟件質量問題導致失敗的軟件項目非常多(3) 、進度難以控制：項目延期比比皆是 由于進度問題而取消的軟件項目較常見 只有一小部分的項目能夠按期完成(4) 、維護十分困難：軟件維護的多樣性軟件維護的復雜性軟件維護的副作用3、克服軟件危機(1) 、管理的角度： 軟件開發過程的研究、文檔的標準化以及人員的交流方式等(2) 、軟件開發方法的研究 結構化軟件開發方法 , 面向對象的開發4、軟件工程的定義概括的說，軟件工程師指導計算機軟件開發和維護的一門工程學科。采用工程的概念、 原理、技術和方法來開發和維護軟件， 把經過時間考驗而證明正確的管理技術和當前能夠得這就是軟件

3、到的最好的技術方法結合起來， 以經濟地開發出高質量的軟件并有效地維護它， 工程。( 1)、軟件工程就是建立和使用一套合理的工程原理，從而經濟地獲得可靠的、 可以在實際機器上高效運行的軟件。(2) 、把系統的、規范的、可度量的方法應用于軟件開發、運行和維護的過程，也就 是把工程應用于軟件 .研究中提到的途徑總之：軟件工程是應用計算機科學、 數學及管理科學等原理開發軟件的工程。 他借鑒傳 統工程的原理、方法，以提高質量，降低成本為目的。5、軟件工程的本質特性1、關注與大型程序的構造2、中心課題是控制復雜度3、軟件經常變化4、開發軟件的效率非常重要5、和諧的合作是開發軟件的關鍵6、軟件必須有效地支持

4、它的用戶7、在軟件工程領域中通常由具有一個文化背景的人替另外一種文化背景的人創造產 品6、軟件工程的基本原理1、用分階段的生命周期計劃嚴格管理2、堅持進行階段評審3、實行嚴格的產品控制4、采用現代程序設計技術5、結果應能清楚地審查6、開發小組應該少而精7、承認不斷改進軟件工程實踐的必要性軟件工程學包含 3 個要素：方法、工具和過程7、軟件生命周期(1) 、概念 : 軟件生命周期由軟件定義、軟件開發和運行維護(也成軟件維護)3 個時期組成。(2) 、內容：廠:問題定義軟件定義1可行性研憲需求分析總體設廿軟件主命周期軟件開發彳黑跖十I*元測試 綜合測試L 耘行維護持久滿足用戶需求1、問題定義回答要

5、解決的問題是什么？,寫出關于問題性質、工程目標和工程規模的書面報告2、可行性分析回答”對于問題是否有行得通的解決辦法 ？：即探索問題是否值得去解， 是否有可行的辦法3、需求分析確定”為了解決這個問題，目標系統必須做什么，確定目標系統必須具備哪些功能，得到需求規格說明書。4、總體設計回答”概括地說，應該怎樣實現目標系統？確定程序由哪些模塊組成以及模間的關系5、詳細設計回答”應該怎樣具體地實現這個系統呢 ？”確定實現模塊功能所需要的算法與數據結構6、編碼和單元測試寫出正確的容易理解、容易維護的程序模塊，然后仔細測試每個模塊7、綜合測試通過各種類型的測試(及相應的調試)是軟件達到預定要求8、軟件維護

6、通過各種必要活動是系統持久地滿足用戶需求&生命周期模型(1)、瀑布模型傳統瀑布模型特點：1、階段間具有順序性與依賴性2、推遲實現的觀點3、質量保證的觀點 瀑布模型優點：1、可強迫開發人員使用規范的方法(例如：結構化技術)；2、嚴格規定每個階段必須提交的文檔；3、要求每個階段交出的所有產品都必須通過驗證。缺點：1、“瀑布模型是由文檔驅動的 ”成為主要缺點適用范圍：適合于 用戶需求明確、完整、無重大變化 的軟件項目開發。 (2)、快速原型模型適用范圍：用戶不能給出完整、 準確的需求說明， 或者開發者不能確定算法的有效性、 操 作系統的適應性或人機交互的形式等情況。(3) 、增量模型特點：1

7、、反復的應用瀑布模型的基本成分和原型模型的迭代特征，每一個線型過程 產生一個“增量”的發布或提交，該增量均是一個可運行的產品。2、早期的版本實現用戶的基本需求，并提供給用戶評估的平臺。 優點：1、在較短時間內向用戶提交可完成部分工作的產品；2、逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊； 缺點：1、軟件體系結構必須是開放的；2、開發人員既要把軟件系統看作整體。又要看成可獨立的構件，相互矛盾；3、多個構件并行開發，具有無法集成的風險。(4) 、螺旋模型基本思想：使用原型或其他方法來降低風險。適用范圍：適用于內部開發大規模軟件項目。優點

8、：1、對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質 量作為軟件發的一個重要目標2、減少了過多測試或測試不足3、維護和開發之間并沒有本質區別缺點：1、風險驅動，需要相當豐富的風險評估經驗和專門知識，否則風險更大2、隨著迭代次數的增加，工作量加大，軟件開發成本增加(5) 、噴泉模型 特點：噴泉模型是一種以用戶需求為動力， 以對象為驅動的模型， 主要用于采用對象技術的軟件開發項目。 該模型認為軟件開發過程自下而上周期的各階段是相互 迭代和無間隙的特性。（6）、 Rational 統一過程RUP重復一系列周期，每個周期由一個交付給用戶的產品結束。每個周期劃分為初始、細化、構造和移交

9、四個階段，每個階段圍繞著五個核心工作流（需求、分析、 設計、實現、測試）分別迭代。第二章 可行性研究1、概念（目的）用最小的代價在盡可能短的時間內確定問題是否能夠解決，不是解決問題， 而是確定問題是否值得去解決。2、可行性研究任務了解客戶的要求及現實環境， 從技術、經濟和社會因素等三方面研究并論證本軟件 項目的可行性，編寫可行性研究報告，制定初步項目開發計劃。即對軟件開發以后的行動方針提出建議。3、研究內容1） 技術可行性2） 經濟可行性3） 操作可行性4） 法律可行性使用現有的技術能實現這個系統嗎 ? 這個系統的經濟效益能超過它的開發成本嗎 系統的操作方式在這個用戶組織內行得通嗎 新系統開發

10、是否會侵犯法藤、集體或國家利益4、數據字典（1）、內容1、數據流2、數據流分量（即數據元素）3、數據存儲4、處理（2）、作用 對于數據流圖中出現的所有被命名的圖形元素在字典中作為一個詞條加以定 義，使得每一個圖形元素都有一個確切的定義。第三章需求分析1、需求分析的任務（1）確定對系統的綜合要求（2）分析系統的數據要求（3）導出系統的邏輯模型（4）修正系統的開發步驟2、獲取需求的方法(1)訪談(2)面向數據流自頂向下(3)簡易的應用規模說明技術(4)快速建立軟件模型3、實體-關系圖（？?）、層次方框圖（？?）和IPO圖（？? 4、結構化分析模型根據結構化分析準則F需求分析過程應該數據模型（實體-

11、聯系圖） 建心種模型q功能模里（數據流圖）I行為模型（狀態轉換圖）數據流圖：描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功能，是建立功能模型的基礎實體-聯系圖：描繪數據對象及數據對象之間的關系，用于建立數據模型。狀態轉換圖：指明了作為外部事件結果的系統行為。描繪了系統的各種行為模式（稱為“狀態”）和在不同狀態間轉換的方式。是行為建模的基礎第四章 總體設計1、模塊獨立性與耦合性（ ? ?）?（1）模塊化 把程序劃分成獨立命名且可獨立訪問的模塊， 每個模塊完成一個子功能， 把這 些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求模塊化的優點：1. 使軟件結構清晰

12、，容易設計也容易閱讀與理解2. 容易測試與調試，提高可靠性3. 提高軟件的可修改性4. 有助于軟件開發工程的組織管理（2）模塊獨立的重要性O有效的模塊化（即具有獨立的模塊）的軟件比較容易開發出來O獨立的模塊比較容易測試和維護（3）耦合 衡量不同模塊彼此間互相依賴 （連接 ）的緊密程度，耦合要低，即每個模塊和其 他模塊之間的關系要簡單1、數據耦合： 兩個模塊之間通過參數交換信息，而且交換的信息僅僅是數據2、控制耦合： 傳遞的信息中有控制信息3、特征耦合： 當把整個數據結構作為參數傳遞而被調用的模塊只需要使用其 中一部分數據元素4、公共環境耦合： 兩個或多個模塊通過一個公共環境相互作用5、內容耦合

13、： 出現一下情況之一，則為內容耦合：1、一個模塊訪問另一個模塊的內部數據2、一個模塊不通過正常入口而轉到另一個模塊的內部3、兩個模塊有一部分代碼重疊4、一個模塊有多個入口數據耦合 控制耦合 特征耦合 公共環境耦合 內容耦合（4） 內聚（ ?）? 衡量一個模塊內部各個元素彼此結合的緊密程度。 內聚要高， 每個模塊完成一 個相對獨立的特定子功能信息隱藏（ ?）?應該這樣設計和確定模塊，使得一個模塊內包含的信息（過程和數據 ）對于不需要這些信息的模塊來說，是不能訪問的2、啟發規則1、 改進軟件結構提高模塊獨立性2、模塊規模應該適中3、深度、寬度、扇入、扇出都應適中4、模塊的作用域應該在控制域之內5、

14、力爭降低模塊接口的復雜度6、設計單入口、單出口模塊7、模塊功能應該可以預測3、層次圖和HIPO圖（？?）？4、面向數據流的設計方法（ ? ?）?（1）概念 面向數據流設計就是把信息流映射成軟件結構， 信息流的類型決定了映射的方法。信息流包括變換流、事物流。（2）變換分析與事務分析（ ?105 ）5、小 結i. 進行軟件結構設計遵循的最主要的原理是模塊獨立原理ii. 抽象和求精是一對互補概念iii. 軟件工程師在實踐中總結經驗得出一些很有參考價值的啟發式規則iv. 自頂向下逐步求精是進行軟件結構設計的常用途徑v. 用形式化的方法由數據流圖映射出軟件結構第五章 實現1、 選 擇程序設計語言為了使程

15、序容易測試和維護以減少軟件的總成本，所選用的高級語言程序應該有 理想的模塊化機制，以及可讀性好的控制結構和數據結構：為了便于調試和提高軟件 可靠性，語言特點應該是編譯程序能夠盡可能多地發現程序中的錯誤；為了降低軟件 開發和維護的成本，選用的高級語言應該有良好的獨立編譯機制。第六章 軟件測試2、 測試的概念(1) 測試是為了發現程序中的錯誤而執行程序的過程(2) 好的測試方案是極可能發現了至今為止尚未發現的錯誤的測試方案。(3) 成功的測試是發現了至今為止尚未發現的錯誤的測試。3、 測試的過程與步驟( ? ?)?大型軟件的測試過程基本由下述幾個步驟組成(1) 模塊測試(單元測試) 發現編碼和詳細

16、設計的錯誤(2) 子系統測試(3) 系統測試(集成測試)(4) 驗收測試(確認測試)(5) 平行運行4、 單元測試( ? ?)?著重從下述 5 個模塊進行測試(主要使用白盒測試技術)(1) 模塊接口(2) 局部數據結構(3) 重要的執行通路(4) 出錯處理通路(5) 邊界條件5、 集成測試( ? ?)? 集成測試就是測試和組裝軟件的系統化技術，主要目標是發現與接口有關的問題。 有兩種集成策咯(1) 自頂向下集成(2) 自底向上集成6、確認測試( ? ?)?也稱驗收測試，它的目標是驗證軟件的有效性。通常使用黑盒測試法。7、白盒測試技術( ? ?)?白盒方法測試軟件時設計測試數據的典型技術(1)

17、邏輯覆蓋1、 語句覆蓋2、 判定覆蓋3、 條件覆蓋4、 判定 / 條件覆蓋5、 條件組合覆蓋6、 點覆蓋7、 邊覆蓋8、 路徑覆蓋(2) 控制結構測試1、 基本路徑測試2、 條件測試3、 循環測試8、黑盒測試技術( ? ?)?黑盒測試力圖發現下述類型的錯誤：(1) 功能不正確或遺漏了功能。(2) 界面錯誤。(3) 數據結構錯誤或外部訪問數據庫錯誤(4) 性能錯誤(5) 初始化和終止錯誤 黑盒測試用到的技術(1) 等價劃分(2) 邊界值分析(3) 錯誤推測第七章 維護1、 維護的定義( ?)?所謂軟件維護就是在軟件已經交付使用周， 為了改正錯誤或滿足新的需要而修改軟 件的過程。根據交付使用之后可

18、能進行的 4 項活動具體定義軟件維護(1) 改正性維護 糾正在使用過程中暴露出來的錯誤；診斷和改正錯誤的過程，(2) 適應性維護 為了和變化了的環境適當地配合而進行的修改軟件活動(3) 完善性維護 在使用軟件的過程中增加新的功能或修改已有功能， 還可能提出一般性的改進 意見的過程(4) 預防性維護 為了改進未來的可維護性與可靠性， 或為了給未來的改進奠定更好的基礎而修 改軟件的過程。2、 維護的過程( ?)?(1) 維護組織(2) 維護報告(3) 維護的事件流(4) 保存維護記錄(5) 評價維護活動3、小結1、 軟件生命周期每個階段的工作都和軟件可維護性有密切關系。2、 再工程過程可以在完成任

19、意一個活動之后中止第八章 面向對象技術1、面向對象方法學要點 （? ?）?面向對象方法學的出發點和基本原則， 是盡可能模擬人類思維方法， 是開發軟件盡 可能接近人類認識世界解決問題的方法與過程。2、 面向對象方法學優點1、 與人類習慣的思維方法一致2、穩定性好3、可重用性好4、較易開發大型軟件產品5、可維護性好3、對象模型 （? ?）?對象模型表示靜態的， 結構化的系統的 “數據”性質。 它是對模擬客觀世界實體的對 象以及對象彼此之間的關系的映射，描述了系統的靜態結構。4、動態模型 （? ?）?動態模型表示瞬時的、 行為化的系統的 ”控制“性質， 它規定了對象模型中的對象的 合法序列。5、功能

20、模型 （? ?）?功能模型表示變化的系統的 ”功能“性質，他指明了系統應該 ”做什么 ”，因此更直接 反映了用戶對目標系統的需求。6、三種模型之間的關系（？?）？功能模型指明了系統應該“做什么”；動態模型明確規定了什么時候（即在何種狀 況下接受什么時間的觸發）做；對象模型則定義了做事情的實體。在面向對象方法學中，對象模型是最基本的，它為其他兩種模型奠定了基礎，人們依靠對象模型完成了 3中模型的集成。下面扼要地敘述3種模型之間的關系。三種模型描述了系統的不同方面:對象模型動態模型功能模型對象的靜態結構 及相互關系與時間和順序有關的系統性質與值的變化有關的系統性質描述系統的數據 結構控制結構系統的功能干事的主體”什么時候干”干什么”功能模型與對象模型的關系-對象模型描述了功能模型中的動作對象，數據存儲以及數據流結構-功能模型中的處理對應于對象模型中的操作動態模型與對象模型的關系-狀態轉換驅使行為發生，這些行為在DFD中被映射成處理，它們同時與對象模 型的操作相對應-針對每個建立的動態模型描述了類實例的生命周期或運行周期動態模型與功能模型的關系-功能模型中的處理可能產生動態模型