第一章 軟件工程學概述（15分）
1.1 軟件危機
軟件危機是指在軟件開發和維護過程中所遇到的一系列嚴重問題
表現：成本/進度估計不准確；閉門造車，用戶不滿意；不可維護；軟件成本的比例逐年上升；供不應求；沒有適當的文檔資料。
產生軟件危機的原因（理解即可 by csb）
規模加大、復雜性提高；軟件是邏輯產品，缺乏“可見性”；缺乏有效的、系統的技術手段和管理方法；用戶和軟件開發人員的理解鴻溝（Gap)；錯誤的認識和做法：忽視軟件需求分析的重要性、認為軟件開發就是寫程序並設法使之運行、輕視軟件測試和軟件維護。
維護的費用占軟件總費用的55%-70%（維護與測試比編寫程序重要得多）
測試工作量占開發總工作量的40%-50%
編寫程序只占開發工作量的10%-20%
軟件是程序、數據及相關文檔的完整集合。文檔是開發、使用和維護程序所需要的圖文資料。
1.2 軟件工程
軟件工程 是指導計算機軟件開發和維護的一門工程學科，以經濟地開發出高質量的軟件並有效地維護它 （無論怎么解釋，就是用工程化的方法開發軟件 by csb）
1.2.1 軟件工程的本質特性
關注大型程序的構造；中心課題是控制復雜性；軟件經常變化；開發效率非常重要；和諧合作：紀律是軟件開發項目的一個關鍵；軟件必須有效地支持它的用戶；一種文化背景的人替另一種文化背景的人創造產品
1.2.2 軟件工程七個基本原理（讀兩遍即可, by csb）
用分階段的生命周期計划嚴格管理；堅持進行階段評審；實行嚴格的產品控制；采用現代程序設計技術；結果應能清楚地審查；開發小組的人員應該少而精；承認不斷改進軟件工程實踐的必要性。
1.2.3 軟件工程方法學
包括技術和管理兩方面
軟件工程三要素：工具、方法、過程
使用最廣泛的方法學：面向對象方法學（將數據和行為看成是同等重要的）、傳統方法學
1.3 軟件生命周期（讀幾遍 by csb）
軟件生命周期是軟件產品一系列相關活動的全周期
三個大階段（8個任務）：
1.軟件定義: 確定軟件開發總目標；確定工程的可行性；導出實現策略及系統功能；估計資源和成本，並且制定工程進度表。
（問題定義、可行性研究、需求分析）
2.軟件開發: 具體設計和實現在前一個時期定義的軟件
（總體設計、詳細設計、編碼和單元測試、綜合測試）
3.軟件維護: 使軟件持久地滿足用戶的需要
生命周期中各階段的任務
1.問題定義： 要解決的問題是什么?
2.可行性研究： 問題是否有可行的解決辦法?
3.需求分析： 目標系統必須做什么 (規格說明書)
4.總體設計（概要設計）：概括地說，應該怎樣實現目標系統? （確定體系結果，確定程序模由哪些模塊組成、以及模塊間的關系）
5.詳細設計： 怎樣具體地實現系統?（也成為模塊設計，在這個階段將詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構）
6.編碼和單元測試： 編寫易理解、易維護的程序； 測試編每個模塊
7.綜合測試： 集成測試、驗收測試、現場測試或平行運行
8.軟件維護： 使系統持久地滿足用戶的需要
1.4 軟件過程
通常使用生命周期模型簡介地描述軟件過程。因此也成為過程模型，將生命周期划分成階段及各階段的執行順序
1.4.1 瀑布模型(Waterfall model)：文檔驅動
特點：
1.階段的順序性和依賴性
2.推遲實現：區分邏輯與物理設計
3.質量保證（文檔驅動）
缺點：
1.開發過程一般不能逆轉
2.開發后期客戶才能看到軟件
文檔驅動既是瀑布模型的優點也是其缺點
1.4.2 快速原型開發模型
1.4.3 增量模型
1.4.4 螺旋模型：風險驅動
1.4.5 噴泉模型
1.4.6 敏捷開發（讀幾遍）
1.4.7 RUP：4個階段
開始：建立業務模型，定義項目范圍
精化：系統的體系結構、項目計划、 資源需求、
構造：構件開發，軟件產品
移交：軟件產品移交給用戶
第二張 可行性研究
2.1 可行性研究的任務(by csb)
從三方面研究：
1.技術可行性
2.經濟可行性
3.操作可行性
*4.必要時還應該從法律、社會效益等廣泛的方面研究每種解法的可行性
2.2 可行性研究過程（理解就行）8個
2.3 系統流程圖
概括地描繪物理系統的傳統工具
2.4 數據流圖（DFD） 15分大題
描繪數據在軟件中流動和被處理的邏輯, 不涉及具體的物理部件
2.5 數據字典
關於數據的信息的集合
●對數據流圖元素（數據流、數據元素、數據存儲、處理）的定義
●由數據元素組成數據的方式
（1）3種基本類型：順序、選擇、重復
（2）重復的特殊情況：可選
[]:選擇、():可選、下界{重復}上屆
數據流圖+數據字典=系統的邏輯模型
第三章 需求分析
需求分析的任務
1.回答“系統必須做什么?”
2.結果：軟件需求規格說明書
軟件需求：用戶解決問題或達到目標所需要的條件或能力
需求層次：業務需求 -> 用戶需求 -> 功能與非功能需求
3.1 具體任務
1.確定綜合要求
功能需求、非功能需求（性能、可靠性、可用性、出錯處理、接口、約束等）
2.分析數據要求
3.導出邏輯模型
4.修正開發計划
3.2 獲取需求的方法
1.訪談
2.面向數據流自頂向下求精
3.簡易的應用規格說明技術
4.快速建立軟件原型
3.6 狀態圖（大題）
初態用實心圓，終點用一對同心圓（中間實心）
圓角矩形中畫狀態名，活動表
do/ 動作寫哪里 整張圖要保持一致
事件表達式：事件說明[守衛條件]/動作表達式
3.8 需求驗證的四個方面
1.一致性： 需求不互相矛盾
2.完整性： 包括用戶需要的每一個功能或性能
3.現實性： 現有技術可以實現
4.有效性： 確實能解決用戶面對的問題
第五章 總體設計
"概括地說，系統應該如何實現？” . 2個階段
●系統設計
划分系統：程序、文件、數據庫、人工過程和文檔等
●結構設計
划分程序：模塊以及模塊間的關系，建立軟件結構
設計過程（分清是不是這9個）
①設想方案
②選取合理方案（至少3種方案：低、中、高成本）
③推薦最佳方案
————之后進入結構設計階段————（by csb)
④功能分解
⑤設計軟件結構
⑥設計數據庫
⑦制定測試計划
⑧書寫文檔
⑨審查和復審
Q：結構設計是不是總體設計的一部分
A：yes
5.2 設計原理
1.模塊化
模塊不是越小越好，太小會增加接口的成本。最小成本區，曲線。
2.抽象：關注事物的本質特性，暫不考慮細節
3.逐步求精：推遲對問題細節的考慮，逐步增加細節
4.信息隱藏：內部信息(過程和數據)對外不可訪問
5.局部化：把關系密切的元素放在一起
6.模塊獨立程度的2個定性度量標准
•內聚：模塊內各元素的相關程度
•耦合：模塊間的交互程度
耦合（含義）
1.內容耦合
2.共用（公共環境）耦合
3.控制耦合
4.印記（特征）耦合
5.數據耦合
原則：多用數據耦合，少用控制耦合和特征耦合，限制公用耦合，不用內容耦合，記住最好最壞！
內聚（含義）
1.偶然性內聚
2.邏輯性內聚
3.時間性內聚
4.過程性內聚
5.通信性內聚
6.順序內聚
7.功能性內聚
8.信息性內聚
原則：力爭高內聚，識別低內聚，改進以提高內聚度，記住最好最壞！
5.3 啟發規則（讀幾遍）
1.提高模塊獨立性
2.模塊規模適中
3.深度、寬度、扇出和扇入都應適當
4.模塊的作用域應該在控制域之內
模塊的作用域：受一個判定影響的所有模塊集合
模塊的控制域：模塊及其直接或間接的從屬模塊集
5.降低模塊接口的復雜度
6.設計單入口單出口的模塊
7.模塊功能可以預測
5.4 結構圖（陳聖波沒提）
描述軟件的模塊層次，反映各模塊之間的調用和數據傳遞，不指定模塊的調用順序。
傳遞兩種信息：數據信息（尾部空心圓）、控制信息（尾部實心圓）。
5.5 面向數據流的設計
DFD -> 結構圖
兩種信息流：變換流和事務流
變換流：信息以“外部世界”的形式進入，經過處理以后再以“外部世界”的形式離開。
事務流：分析每個十五以確定它的類型，並根據類型選取一條活動通路。
變換流到軟件結構圖的轉換。
第六章 詳細設計
任務
怎樣具體地實現這個系統?
設計程序的“藍圖”，確定模塊的處理過程
6.1結構化程序設計
結構化定理
66年被證明：任何單入口單出口的程序都可由“順序”、“選擇”和“循環”三種基本結構實現
經典定義：如果一個程序的代碼塊僅有順序、選擇和循環這3個基本控制結構進行連接，並且只有一個入口和出口，則稱這個程序是結構化的。（五個關鍵！ by csb）
工具（會做）
程序流程圖（不易表示數據結構）
盒圖 (NS圖，容易表現嵌套關系，不可能任意轉移控制）
PAD圖（其描述的處理過程最容易轉換成與之對應的高級語言程序）
判定表（互斥條件放上，動作放下）
第七章 實現 (+維護=15分)
實現=編碼+測試
7.1 編碼（讀幾遍 by csb）
編碼風格的作用就是使代碼容易讀；風格良好的代碼更容易閱讀和理解，錯誤更少
1.使用一致和有意義的標識符名
2.用縮進顯示程序結構
3.用加括號的方式排除二義性
4.盡量不要進行浮點數的相等比較
5.避免大量使用循環嵌套和條件嵌套
6.當心運算符的副作用
7.把數定義稱常量
8.利用sizeof()計算對象的大小
9.清晰的代碼，而非最巧妙的代碼
10.程序的注釋
序言性注釋和功能性注釋
對一段程序注釋，而不是每一個語句
11.用數據結束標記（EOF、BOF），而非讓用戶給出數據數目
7.2 測試（重點，好好讀）
對軟件規格說明、設計和編碼的最后復審
測試目的：發現軟件中的錯誤
調試：診斷並改正錯誤，由程序員完成
開發總工作量的40%以上
好的測試方案是極可能發現迄今尚未發現的錯誤（找不到錯誤就是不好的 by csb）
成功的測試是發現了至今尚未發現的錯誤的測試（沒有發現錯的測試是不成功的 by csb）
測試不能證明程序中沒有錯誤
7.2.2 測試准則（讀幾遍 by csb）
Pareto原理：80%的錯誤很可能是20%的模塊造成的
從“小規模”測試逐步到“大規模”測試
窮舉測試不可能
應該由獨立的第三方從事測試工作
7.2.3 測試方法
黑盒測試：又稱功能測試或數據驅動測試
白盒測試：又稱結構測試或邏輯驅動測試
7.2.4 測試步驟
●模塊測試（單元測試）：
主要發現編碼和詳細設計的錯誤
●子系統測試：
模塊放在一起形成一個子系統來測試；着重測試模塊的接口
●系統測試：
將子系統裝配成一個完整的系統；主要發現軟件設計中的錯誤，也可能發現需求說明中的錯誤
●驗收測試（確認測試）：
驗證軟件的有效性（是否與用戶期待相符）；用戶參與，使用實際數據測試；主要發現系統需求說明書中的錯誤
●平行運行
*其中子系統測試和系統測試為集成測試
7.3 單元測試
檢測最小單元—模塊；主要使用白盒測試
7.3.1 測試重點
模塊接口、局部數據結構、重要的執行通路、出錯處理、邊界條件
7.3.2 代碼審查
審查小組對代碼進行復審，可發現30%～70%的錯誤
7.3.3 計算機測試
●驅動程序
模擬被測模塊的調用模塊，接收測試數據，打印測試結果
●存根程序
模擬被測模塊的子模塊，印出入口檢驗或操作結果
7.4 集成測試方法（通讀一遍，優缺點）
●非漸增式集成
所有模塊按設計進行一次性集成
先進行單元測試，再進行集成測試
●漸增式集成
將單元測試與集成測試結合在一起
逐個將待集成的模塊同已集成的那些模塊結合起來進行測試
1.自頂向下集成
2.自底往上集成
3.三明治式（混合式）集成
*幾種集成測試方法的優缺點
7.5 確認測試
回歸測試
重新執行已經做過的測試的某個子集，以保證變化（程序改錯、新模塊加入等）沒有帶來非預期的副作用
(a) Alpha測試
在開發者的指導下，用戶在開發現場進行
(b) Beta測試
用戶在實際使用環境下進行測試
7.6 白盒測試技術：
7.6.1 邏輯覆蓋
測試用例 = 測試數據+預期輸出
以程序內部的邏輯結構為基礎的設計測試用例的技術
1.語句覆蓋：每個語句至少執行一次
2.判定覆蓋（分支覆蓋）：每個判定的每個分支至少執行一次
3.條件覆蓋：每個判定中的每個條件都取到可能的值
4.判定／條件覆蓋：每判定中的每個條件都取到可能值，且每個判定的每個分支都至少執行一次
5.條件組合覆蓋：每個判定中的各種條件組合都至少執行一次
Q：畫出程序流程圖，並根據流程圖出數據，設計測試用例（會做）
7.7 黑盒測試技術
1.等價划分
把輸入域划分成數據類，取每類中的一個典型值進行測試
設計測試用例
(1) 新增測試用例盡可能多地覆蓋尚未被覆蓋的有效等價類
(2) 新增測試用例覆蓋一個尚未被覆蓋的無效等價類
2.邊界值分析
着重測試輸入等價類和輸出等價類的邊界，選取的測試數據應該剛好等於、剛剛小於和剛剛大於邊界值。
eg:若輸入應為數值，則無效輸入需有非數值型數據
7.8 調試（by csb）
目標：尋找軟件錯的原因並改正錯誤。
三種方法：
1.蠻干法
2.回溯法
3.原因排除法
7.9 軟件可靠性
7.9.1 基本概念
軟件可靠性：程序在給定的時間間隔內，按照規格說明書的規定成功地運行的概率。
軟件可用性：在給定的時間點，按照規格說明書的規定，成功地運行的概率。
軟件兼容性：書上沒有，自己理解。（by csb）（指硬件之間、軟件之間或是軟硬件組合系統之間的相互協調工作的程度）
第八章 維護 (+實現 15分)
使軟件持久地滿足用戶的需要。
軟件維護的本質是修改和壓縮了的軟件定義和開發過程。
占生命周期的60%以上
軟件工程的一個重要目標：提高軟件的可維護性，減少軟件維護的代價。
四類維護
●改正性維護：診斷和改正錯誤的過程。17%～21%
●適應性維護：適應環境的變化而適當地修改軟件。 18%～25%
●完善性維護：增加新功能或修改已有功能。 50%～66%（維護的大部分工作）
●預防性維護：改進未來的可維護性或可靠性。4%左右
8.4 可維護性
理解、改正、改進軟件的難易程度
提高可維護性是支配軟件工程方法學的關鍵目標
決定軟件可維護性的因素
1）可理解性
2）可測試性
3）可修改性
4）可移植性
5）可重用性
第九、十章 面向對象 （10分）
9.1 面向對象方法學概述
●1960’s：Simula-67,引入類和對象
●1980’s：面向對象分析與設計
●1980’s：面向對象方法
面向對象方法學的4個要點
1) 軟件系統是由對象（Object）組成
2) 對象組成對象類(Class)
3) 類可以組成一個類層次，子類繼承(inheritance)父類
4) 對象間僅能通過傳遞消息(Message)互相聯系
OO=objects+classes+inheritance+communication with messages
面向對象 = 對象 + 類 + 繼承 + 消息通信
簡化了軟件的開發與維護，提高了條件的可重用性
一些概念
●對象：數據結構及這些數據結構上的操作的封裝體
●類：具有相同數據和相同操作的一組相似對象的集合
●消息：要求某個對象執行某個操作的規格說明
●方法：對象所能執行的操作（服務）
●屬性：類中所定義的數據
●封裝：對象的狀態數據、代碼和局部數據，外面不能直接訪問
●繼承：子類共享基類中定義的數據和方法的機制
●多態性：同一方法，不同的子類有不同的實現。
●函數重載：同一作用域內多個參數特征不同的函數使用相同函數名
9.3 面向對象建模
三種模型
1.對象模型：模擬客觀世界實體的對象以及對象彼此間的關系的映射，描述系統的數據結構。最基本的、核心模型
2.動態模型：描述系統的控制結構。
3.功能模型：描述系統的功能
建模圖形工具
類圖：描述類及類與類之間的靜態關系（關聯、聚集、泛化等）
類的狀態圖：描繪對象狀態及引起狀態轉換的事件
用例圖：描述外部行為者所理解的系統功能
事件跟蹤圖（順序圖）
9.4 對象模型
通常使用UML提供的類圖來建立對象模型
類圖的關系：
1.關聯（重數、
2.聚集（共享聚集、組合聚集）
3.泛化（繼承）
9.5 功能模型
通常，用UML提供的狀態圖來描繪對象的狀態、觸發狀態轉換的時間以及對象的行為。
9.6 用例模型
用例之間的關系：
1.擴展
2.包含
3.繼承（派生）
第十一章 面向對象設計 （5分）
csb強調兩種設計
●系統設計: 確定實現系統的策略和目標系統的高層結構
●對象設計: 確定解空間中的類、關聯、接口形式及實現服務的算法
11.1 面向對象設計的准則
●模塊化、抽象、信息隱藏（相似）
●耦合
(1) 交互耦合：對象之間的耦合通過消息連接來實現
減少消息中包含的參數個數，降低參數的復雜程度
減少對象發送(或接收)的消息數
(2) 繼承耦合：一般化類與特殊類之間耦合
使特殊類盡量多繼承並使用其一般化類的屬性和服務
●內聚（csb說不用管）
（1） 服務內聚
一個服務應該完成一個且僅完成一個功能
（2） 類內聚
類的屬性和服務應該全都是完成該類對象的任務所必需的
（3） 一般-特殊內聚
一般-特殊結構應該是對相應的領域知識的正確抽取
●可重用（csb強調）
從設計階段開發
11.2 啟發規則（讀一讀）
設計清晰易懂
一般-特殊結構深度適當：7 ± 2
設計簡單的類
•1頁紙大小？
•類任務明確簡單
•屬性和服務不要過多，簡化對象間協作
使用簡單的協議，消息參數少 (不要超過3個, by csb)
使用簡單的服務
•3~5行源程序（動賓詞描述功能）
•復雜的CASE語句 -> 一般-特殊結構代替的可能性
重用（再用或復用）
同一事物不修改或稍加改動后可重復使用
軟件重用層次
知識重用。如，軟件工程知識的重用。
方法和標准的重用。如，開發方法或國標。
軟件成分的重用
代碼重用：剪貼、包含、繼承等；
設計結果重用；
分析結果重用。
類構件的重用方式
(1) 實例重用
–按需創建類實例
–用對象成員創建出更復雜的類
(2) 繼承重用
–為提高繼承重用的效果，關鍵是設計一個合理的、具有一定深度的類構件繼承層次結構。
(3) 多態重用
–轉換接口：重用必須重新定義的服務的集合
–擴充接口：如派生類沒給出接口的新算法，則繼承父類算法
extra - 題目說明
數據流圖15分，用例5分，類圖5分，狀態圖5分，順序圖5分，（白盒黑盒，NS, PAD, 判定樹/表） 15分
排列性強，字比較短——填空；
用例圖：小人的名字要寫出來，小人用例要關聯起來，用例和用例畫關系圖；
類圖：比較簡單，類已經幫你找出來了，自己負責連線（補充多重性和關系，要從題中讀出來，不能瞎寫）；
順序圖：參與者，按照過程全部寫下來，四條線，一條線一分。
狀態圖：比較簡單。eg：借書。每個人可借多本書；借閱證的狀態：可借閱和不可借閱；注意狀態是圓角矩形。可借閱變為不可借閱狀態：借滿；不可變為可借：還書。若是信用卡：欠錢之后還能借錢（難）。