《軟件工程導論》主編：薛繼偉 哈爾濱工業大學出版社
第一章軟件工程概述
- 軟件：軟件是程序以及所有使程序正確運行所需的相關文檔和配置信息。軟件=程序+數據+文檔
- 軟件危機：隨着計算機應用的普及，軟件的數量急劇增加，衆多因素導致了軟件開發過程中所開發的軟件產品質量低下，衆多軟件無法滿足用戶需求，軟件的可維護性差，以至於問題不斷堆積矛盾日益尖銳，稱此現象爲軟件危機。
- 軟件工程：軟件工程是一類工程，是將理論和知識應用於實踐的學科，它借鑑了工程的原則和方法，以求高效的開發高質量的軟件。
- 軟件生命週期：是指軟件在生產到報廢的生命週期，包括可行性分析，項目開發計劃，需求分析，概要設計，詳細設計，編碼，測試，維護等階段。
- 瀑布模型：詳見《軟件工程導論》薛繼偉-哈爾濱工業大學出版社 P.6
- 快速原型原型模型:詳見《軟件工程導論》薛繼偉-哈爾濱工業大學出版社 P.7
- 增量模型：詳見《軟件工程導論》薛繼偉-哈爾濱工業大學出版社 P.9
第二章軟件工程方法與工具
- UML
- UML：UML是用來對軟件密集系統進行可視化建模的一種語言，是對面向對象開發系統的產品進行說明、可視化、和文檔編制的一種標準語言。
- 用例圖：用例描述了系統的工作方式，以及系統提供的服務。用例圖描述了系統外部參與者如何使用系統提供的服務。（P.37）
- 類圖：類圖用來表示系統中的類以及類與類之間的關係描述系統的靜態結構，用於邏輯視圖中。（P.38）
- 對象圖：對象圖是類圖的示例，描述了一組對象以及他們之間的關係，表示類的對象實例。對象圖表示在某一時刻這些類的實例以及這些實例之間的關係。
- 狀態圖：狀態圖表示一個狀態機，強調對象行爲的時間順序，顯示一個對象的狀態以及狀態與狀態之間的轉換。
- 對象之間的關係（圖形符號詳見課本P.34 圖2.7）
- 依賴：依賴是一種使用關係，表示一個元素以某一鍾方法依賴於另一個元素，一個事物的變化會影響到另一個使用它的事物。
- 關聯：關聯是一種結構關係，說明一個事物的對象與另一個事物的對象之間的聯繫，表示模型元素及鏈接實例。
- 泛化：泛化是一種“一般事物”（父類）與“特殊事物”（子類）之間的關係，表示一般與特殊關係，即“一般元素”是“特殊元素”的泛化，“特殊元素”是“一般元素”的特化。
- 聚集：聚集表示整體與部分的關係，即“部分元素”是“整體元素”的一部分。
- 面向對象（略）
- 對象
- 類
- 封裝
- 繼承
- 多態
- 消息
第三章軟件立項
- 可行性研究：可行性分析的目的是從各個方面去綜合對比分析，對比成功或者失敗的可能性有多大，是否值得進行立項等。一般可行性分析的要素有：市場可行性分析、政策（政府）可行性分析、技術可行性分析和成本效益分析。
第四章軟件需求分析
- 需求分析：收集用戶需求，找到用戶真正的需求，確定系統具體需要什麼功能。
- 需求規格說明書：需求分析的產物爲需求規格說明書。
- 需求驗證：需求驗證是指需求規格說明書完成之後，對需求規格說明書文檔進行驗證的活動，目的是發現並糾正說明書中的錯誤、遺漏和不一致的地方。以確保所有的系統需求規格說明書最大限度的正確、清晰、完整、無歧義並符合標準和規範。
- 數據流圖（泡圖）：從數據加工的角度，以圖形的方式來表達系統的邏輯功能，數據在系統內部的邏輯流向，和邏輯變換過程，是結構化系統分析方法的主要表達工具及用於表示軟件模型的一種圖示方法。
- 數據字典：數據字典是關於數據的信息集合，即數據字典的作用是爲數據流圖上的每一個成分加一定義和說明。
- ER圖（實體-聯繫圖）：表示數據對象及其關係，也叫做E-R圖。包括數據對象、對象的屬性、對象間相互連接的關係。（P.68）
- 功能模型：功能模型表示系統的“功能”性質，它指明瞭系統要應該“做什麼”，反映了用戶對目標系統的需求。
- 對象模型：表示靜態的，結構化的，系統的數據性質。是對模擬客觀世界實體的對象以及對象和對象之間的關係的映射，描述了系統的靜態結構。（P.78）
- 動態模型：UML動態模型圖主要包括交互圖和行爲圖，交互圖又分爲時序圖和協作圖，行爲圖又分爲狀態圖和活動圖。在開發交互式系統的時候動態模型非常重要。
- 程序設計語言（過程設計語言PDl）：又稱爲僞碼.它是一種用於描述模塊算法設計和處理細節的語言.
第五章軟件設計
- 概要設計：把需求轉換爲需要的體系結構，概要設計就是設計軟件的結構，該結構有哪些模塊組成，這些模塊的層次結構是怎麼樣的，模塊之間的調用關係是什麼樣的，每個模塊的功能是什麼。
- 詳細設計：爲每個模塊的功能進行詳細的描述，把功能描述轉變爲精確的、結構化的過程描述，即該模塊的控制結構是怎樣的，先做什麼，後座什麼，有什麼樣的判定條件，有生重複處理等，並用相應的表示工具將這些控制結構表示出來。
- 軟件體系結構：一個程序或者計算機系統的軟件體系包括一個或者一組軟件構件、軟件構件的外部的可見特徵性，及其相互關係。（1997年）
- 抽象：暫時忽略事物之間的微小差別，將彼此之間相似，共性的東西進行概括。（P.123）
- 控制抽象：從指令到彙編語言再到高級語言，讓程序員在更高的層次進行抽象，屏蔽不同機器和指令集之間的差異。
- 過程抽象：將處理過程抽象爲存儲過程，函數和方法，通過提供不同的參數實現具體化。
- 數據抽象：使用數據抽象能夠設計出數據庫表和字段，或者設計出類的屬性。
- 模塊：具有相對獨立性的，由數據說明執行語句等程序對象構成的集合。（在高級語言中模塊體現爲函數、子過程、過程）（P.123）
- 模塊化：每個模塊有特定的子功能，各個模塊按照一定的方法組合起來稱爲一個整體，從而從而實現整個系統的功能。
- 模塊獨立性：是指每個模塊只完成系統要求的獨立的子功能，並且與其他模塊的聯繫最小，接口最簡單。
- 信息隱蔽：是指一個模塊將自身的內部信息向其他模塊隱藏起來，以避免其他模塊不恰當的訪問和修改。
- 耦合：模塊與模塊之間的聯繫越高，耦合性就越大。（P.125）
- 數據耦合：兩個模塊之間僅僅通過模塊參數交換信息，且交換的信息全部爲簡單數據。
- 公共耦合：兩個或者多個模塊通過應用公共數據相互聯繫。
- 內容耦合：一個模塊對另一個模塊的內容進行了直接的引用甚至是修改，或者通過非正常的入口，進入到另一個的內部，或者一個模塊具有多個入口，或者兩個模塊共享一部分代碼。
- 控制耦合：一個模塊通過傳送開關、標誌、名字等控制信息，明顯的對另一個模塊的功能進行控制。
- 內聚: 標誌着一個模塊內各個元素彼此的緊密程度，他是信息隱藏和局部化概念的自然擴展。（P.125）主要有一下7中內聚類型，內聚性逐漸增大。
- 偶然內聚：一個模塊內各個語句段之間的聯繫十分鬆散或者直接沒有聯繫，或者根本沒有什麼聯繫，很可能是在一種場合允許修改該模塊，而另外一種場合不允許修改該模塊。
- 邏輯內聚：一個模塊實現多個邏輯上相同或類似的一類功能。
- 時間內聚：模塊內的多個功能在同一個時間內執行。
- 過程內聚：模塊內各個部分相關，並且必須按照特定的次序執行。
- 通信內聚：模塊內各個元素都使用同一個輸入數據和（或）都產生同一個數據輸出。
- 順序內聚：模塊的各個功能必須順序執行（往往後一個功能需要依託前一個功能的結果）。
- 功能內聚：模塊內所有處理元素屬於同一個整體，完成一個單一的功能。
- 數據流類型：（P.134）
- 變換型：信息流沿輸入通路進入系統，同時由外部形式裝換成內部形式，進入系統的數據流經過變換中心，加工處理之後，再沿輸出通路變換成外部形式離開軟件系統。
- 事務型：數據沿輸入通路進入到一個處理T後，這個處理根據輸入數據的類型在若干個動作系列中選擇一個來執行。
- 程序流程圖：即程序框圖。
- PAD圖：用於詳細設計的圖形表達工具，只能用於結構化程序的描述。（P.145）
- NS圖：即無線流程圖。
- 面向對象設計（OOD）：建立在面向對象分析之上的，把分析階段得到的需求轉變爲符合成本和重量要求的抽象的系統實現方案的過程。
第六章軟件實現
- 編碼：通過選定的程序語言，將詳細設計階段的模塊過程性描述，轉變爲特定語言書寫的源程序（源代碼）。
- 編碼風格：代碼應該是正確的、有效的、可維護的、易讀易懂的。
第七章軟件測試
一、軟件測試：是爲了發現錯誤而執行程序的過程，或者說是根據軟件開發的各個階段的規格說明書和程序內部結構而精心設計的一批測試用例。並且用這些用例來運行程序，發現其中的錯誤。有一下幾種測試方法：
1、黑盒測試：根據被測程序的功能來進行測試，也稱爲功能測試或者是數據驅動測試，主要着眼於程序的外部結構，不考慮內部的邏輯結構，針對軟件界面和軟件功能進行測試。（在已知產品的功能情款下，通過測試檢驗已知功能是否能正常使用）。（P.195）
- 等價類劃分法：完全不考慮軟件的內部結構，只是根基軟件的規格說明書設計測試用例，因爲不可能輸入所有情款的測試數據（窮舉測試是不可能實現的），所以採用等價類分化的方法將輸入數據的可能值分爲若干個等價類，使每一個等價類中的任何一個測試用例，都能代表同一等價類中的其他測試用例。
- 邊界值分析法：程序往往會在處理邊界情況是後發生錯誤，邊界值是指輸入或者輸出的等價類邊界上的值。當使用邊界值分析法選取測試用例的時候，選擇的測試數據應該剛好等於，剛好小於，剛好大於等價類的邊界值的數據。
- 錯誤推測法：往往根據測試人員的檢驗與直覺，推測程序中可能存在的各種錯誤，從而有針對性的編寫檢查這些錯誤的測試用例進行有針對性的測試。
- 因果圖法：在測試用例輸入條件之間會存在着聯繫，不同的聯繫會產生不同的結果。所以必須考慮一種適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮測試用例。
2、白盒測試：是以程序的結構爲依據，又稱爲結構測試。它是按照程序內部的結構測試程序。檢查程序中的每一條路是否都能按照預定的要求正常工作。（P.200）
- 邏輯覆蓋測試：是以程序內部的邏輯結構爲基礎的設計測試用例的技術。
- 語句覆蓋
- 判定覆蓋
- 條件覆蓋
- 判定/條件覆蓋
- 路徑測試：測試程序運行的路徑，保證程序中的每一條可能執行到的路徑至少測試一次。
####軟件測試過程：（P.206）- 1、單元測試：針對程序模塊，進行正確性的測試。
- 2、集成測試：又稱爲組裝測試或者聯合測試，在單元測試的基礎上，將模塊或組件按照設計的要求租轉起來，同時進行測試，主要目的是發現與接口有關的問題，即模塊與模塊之間的協作與通信。
- 3、確認測試：經過集成測試之後軟件已經組裝起來了，接口方面的錯誤也已經排除，之後進行確認測試（有效性測試），主要任務是驗證軟件的有效性，驗證軟件功能和性能是否與用戶的需求一直。
- α測試和β測試用以發現只有最終的用戶纔可以發現的錯誤。
- α測試：是在受控制的環境下進行的測試，主要是評價軟件的FURPS（即功能、可使用性、可靠性、性能、和支持），尤其注重產品的界面和特色。
- β測試：是指軟件的一個或者多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者不在測試現場，主要衡量產品的FURPS，着重於產品的支持性，包括文檔，客戶培訓和支持產品生產能力。
- 4、系統測試：通過確認測試之後的軟件作爲基於計算機系統的一個元素，除了被測程序之外硬件，等實際環境下的測試。
二、軟件調試（P.218）：調試的任務就是根據測試時發現的錯誤，找出錯誤的原因和具體位置，並進行改正。改正後重新測試。
第八章軟件維護
軟件維護：在軟件交付使用之後，爲了糾正軟件的錯誤，滿足新的需求，或者適應新的軟件、硬件環境而對軟件進行修改的過程。
- 可維護性：是指維護人員爲了滿足用戶的需求而對軟件系統出現的錯誤和缺陷進行修正，或對系統進行完善的難易程度。
- 改正性維護（糾錯性維護）：軟件產品投入使用支出會暴露出各種各樣的錯誤，改正性維護是針對在系統運行過程中暴露的錯誤而進行的一種維護活動。
- 完善性維護：隨着軟件產品平穩運行之後，用戶往往會提出新的需求或者對性能的要求，爲了滿足這種要求，維護人員需要擴展軟件的功能，提升軟件的性能，是產品有更高的效率。
- 適應性維護：軟件產品在使用過程中會隨着軟件、硬件環境的變化，爲了使軟件產品適應這種環境的變化而對軟件產品做出的維護，稱爲適應性維護。
- 預防性維護：此目的是爲了在問題有可能發生之前，主動的提高軟件的可靠性，爲今後的維護工作創造更加便利的條件，提高軟件的可維護性。
第九章軟件質量保證
- 軟件質量：軟件質量是軟件產品滿足規定的和隱含的與需求能力有關的全部特徵和特性。包括：①軟件產品滿足用戶需要的程度；②軟件擁有所期望的各種屬性組合的程度：③用戶對軟件產品的綜合反映度；④軟件在使用過程中滿足用戶需要的程度。
- 軟件質量的屬性：
- 功能性：軟件按照需求正確執行任務的能力。
- 可靠性：軟件在特定條件下和特殊時間內，不出故障，維持其正常性能水準的能力的程度。
- 易使用性：用戶爲使用一個軟件而付出的努力以及其他代價的程度，也就是用戶使用軟件的容易程度。
- 效率：指在特定的條件下，軟件功能與所佔用資源之間的比例關係。
- 可維護性：是指當發現錯誤，運行環境改變或用戶需求改變的時候，程序可被修改的難易程度。
- 可移植性：是指將軟件從一種環境移植到另一種環境的難易程度，主要體現爲代碼的可移植性。
#PS：
- 大二上學期期末考複習資料整理；
- 文章爲《軟降工程導論》（主編：薛繼偉 哈爾濱工業大學出版社）的內容要點抽取。知識點以原書爲準。