软件工程期末复盘
文章目錄
- ch.1 軟件工程概述
- ch.2 軟件過程
- 2.1 軟件生命周期
- 2.2 軟件過程
- 2.2.1 軟件過程模型
- 傳統
- 現代
- ch.3 可行性分析
- ch.4 需求工程
- 需求分析的模型概述
- 功能模型：數據流圖
- ch5.面向過程（結構化）的軟件設計
- 軟件設計的基本原則：
- 數據流圖映射到軟件結構圖
- 詳細設計
- ch.6 面向對象方法基礎：介紹和UML
- UML建模工具
- 事務：
- 關系：
- 圖
- 用例圖 Use Case Diagram
- ch.7 面向對象分析
- 第一步：用例建模
- 第二步：對象建模
- 第三步：動態建模
- 第四步：評審
- ch.8 軟件體系結構與設計模式
- ch.9 用戶界面設計與軟件實現
- ch.10 軟件測試與維護
- ch.11 敏捷開發
ch.1 軟件工程概述
ch.2 軟件過程
是什么？
為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。描述了 who、when、what、how，用以實現某一個特定的具體目標。
2.1 軟件生命周期
2.1.1 是什么？從考慮概念開始，到交付使用，到最終退役為止的整個過程。
2.1.2 各時期的任務：
（1）軟件定義時期的任務：確定必須完成的總目標；確定工程的可行性；確定完成目標的總策略和必須完成的功能； 估計資源、成本；制定工程進度表。 （分為 3 個階段：問題定義，可行性研究，需求分析）；
（2）軟件開發時期的任務：把用戶的要求轉變為軟件產品。包括：把需求轉換成設計，把設計用代碼實現，測試該 代碼，有時還要進行代碼安裝和交付運行。這些活動可以重疊，執行時也可迭代 （分為 4 個階段：系統設計{總體設計(概要設計)，詳細設計}，系統實現{編碼和單元測試，綜合測試）}；
（3）運行維護時期的任務：使軟件持久地滿足用戶的需要；
2.2 軟件過程
2.2.1 軟件過程模型
傳統
瀑布模型：理想的線性開發模式，缺乏靈活性
在軟件開發初期就確定完整的需求很難。
原型模型：做一個“樣機”（也叫原型，軟件早期可運行的版本）給客戶看，征求意見
用戶參與，風險降低；大型項目的原型難構建。
增量模型：每開發一部分，向用戶展示一部分
開發周期小，降低風險；
螺旋模型：使用原型及其他方法來盡量降低風險 可看作是在每個階段之前都增加了風險分析過程的快 速原型模型。 強調版本和版本升級。
適用范圍：主要適用于內部開發的大規模軟件項目。支持 需求不明確的大型軟件系統的開發，并支持面 向規格說明、面向過程、面向對象等多種軟件 開發方法，是一種具有廣闊前景的模型。
噴泉模型：各個開發階段沒有特定的次序要求，并且可以交互進 行，可以在某個開發階段中隨時補充其他任何開發階 段中的遺漏。該模型認為軟件開發過程自下而上周期的各階段是相 互重疊和多次反復的，就像水噴上去又可以落下來， 類似一個噴泉。
效率高，節約時間；不易于管理。
現代
ch.3 可行性分析
? 技術可行性：做得了嗎？做得好嗎？做得快嗎？
? 經濟可行性：這個系統的經濟效益能超過它的開發成本嗎？
? 操作可行性：系統的操作方式在這個用戶組織內行得通嗎?
? 社會可行性：法律、道德、社會影響力
ch.4 需求工程
軟件工程的子領域
需求工程的定義：應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。
任務：最終形成一份經開發方和用戶認可或達成共識的軟件需求規格說明書
內容
需求分析的模型概述
數據模型：ER圖
功能模型：數據流圖
分層數據流圖：
step1 頂層圖：系統的輸入和輸出
step2 0層圖：系統內部
step3 加工內部
例子：考試管理系統
頂層圖
0層圖：
加工1（考試報名）：
加工2（統計成績）：
數據字典
由不同的數據條目組成，而數據條目是對數據流圖中的不同組成元素（源和宿、數據流、加工、文件）的說明
ch5.面向過程（結構化）的軟件設計
軟件設計的基本原則：
（1）概念：解決一個復雜問題時，自頂向下逐層把軟件劃分成若干模塊的過程
（2）目標：模塊獨立性
（3）衡量模塊獨立性的兩個準則：
內聚： 模塊內部各成分之間的聯系，也稱塊內聯系或模塊強度
耦合： 一個模塊與其它模塊之間的聯系，也稱為塊間聯系
🔥內聚性最高的是功能內聚。非直接耦合的模塊獨立性最強！
（4）模塊的獨立性高：塊內聯系強，塊間聯系弱，追求高內聚，低耦合
（5）好處：每一模塊的設計、測試和維護相對獨立。模塊間的聯系少，錯誤的傳播也少。耦合增加了系統的可理解性、可測試性、可靠性和可維護性。
忽略細節，分層理解問題，自頂向下層層細化，包括對過程、數據和控制的抽象。
求精實際是一個詳細描述的過程。
在設計和確定模塊時，使得一個模塊內包含的信息（過程和數據）對于不需要這些信息的模塊來說，是不可訪問的。
數據流圖映射到軟件結構圖
(1) 接收輸入數據(輸入數據又稱為事務)。
(2) 分析每個事務以確定它的類型。
(3) 根據事務類型選取一條動作路徑。
模塊分解的啟發式規則
4. 模塊大小適當：經驗表明，一個模塊的規模不應過大，通常規定其語句行數為50～100 行，最多不超過500 行。
5. 深度、寬度、扇入、扇出適當
6. 盡可能減少高扇出結構，隨著深度增大扇入。如果一個模塊的扇出數過大，就意味著該模塊過分復雜，需要協調和控制過多的下屬模塊。應當適當增加中間層次的控制模塊。
7. 模塊的作用域應在控制域之內
（1）模塊的作用域：受該模塊內一個判定影響的所有模塊的集合。
（2）模塊的控制域：這個模塊本身以及所有直接或間接從屬于它的模塊的集合。
詳細設計
?程序流程圖
?盒圖
? PAD 圖
? PDL
? IPO 圖
ch.6 面向對象方法基礎：介紹和UML
面向對象=對象 + 類 + 消息 + 繼承 + 多態
比較面向對象對象開發方法與結構化開發方法（面向過程）的異同：
面向過程：“怎樣做”，著重功能分解，面向對象：“是什么”，著重建立對象模型。面向過程側重線，面向對象側重點。面向過程優點是簡單、實用，適合于數據處理領域，缺點是不適應大型規模、復雜的項目，難以解決軟件重用，難以適應需求變化，難以解決維護問題。面向對象方法更容易獲得符合用戶需求、可靠的、適應性強的系統。
三大特性是：封裝,繼承,多態
五大基本原則
是指一個類的功能要單一，不能包羅萬象。如同一個人一樣，分配的工作不能太多，否則一天到晚雖然忙忙碌碌的，但效率卻高不起來。
一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。比如：一個網絡模塊，原來只服務端功能，而現在要加入客戶端功能，
那么應當在不用修改服務端功能代碼的前提下，就能夠增加客戶端功能的實現代碼，這要求在設計之初，就應當將服務端和客戶端分開，公共部分抽象出來。
子類應當可以替換父類并出現在父類能夠出現的任何地方。比如：公司搞年度晚會，所有員工可以參加抽獎，那么不管是老員工還是新員工，
也不管是總部員工還是外派員工，都應當可以參加抽獎，否則這公司就不和諧了。
這個時候，B不應當直接使用A中的具體類： 而應當由B定義一抽象接口，并由A來實現這個抽象接口，B只使用這個抽象接口：這樣就達到
了依賴倒置的目的，B也解除了對A的依賴，反過來是A依賴于B定義的抽象接口。通過上層模塊難以避免依賴下層模塊，假如B也直接依賴A的實現，那么就可能造成循環依賴。一個常見的問題就是編譯A模塊時需要直接包含到B模塊的cpp文件，而編譯B時同樣要直接包含到A的cpp文件。
模塊間要通過抽象接口隔離開，而不是通過具體的類強耦合起來
UML建模工具
Unified Modeling Language（統一建模語言）是對象管理組織（OMG）制定的一個通用的、可視化的建模語言標準，可以用來可視化（visualize） 、描述（specify）、構造（construct）和文檔化（document）軟件密集型系統的各種工件（artifacts，又譯制品）。
事務：
關系：
(ternary)、多元關聯(higher order)。
關聯類（不重要）：OO建模的一個普遍問題是，當類之間具有多對多關系時，一些屬性不能容易地放人任何一個類中。例如，下圖所示的公司與員工的類關系。
在UML2.0中的依賴種類如下：Access(訪問)， bind(綁定 ) ， call( 調 用 ) ， create( 創 建 ) ， derive( 派 生 ) ，instantiate( 實例化 ) ， permit( 允 許 ) ， realize( 實 現 ) ，refine(精化)，send(發送)，substitute(替換)，trace(追蹤依賴)，use(使用)。
聚合（Aggregation）是一種特殊形式的關聯，它表示類之間的整體與部分的關系，組合（Composition）是一種特殊形式的聚集，組合關系中的整體與部分具有同樣的生存期。
5. 實現
圖
用例圖 Use Case Diagram
（1）是什么？說明和定義軟件系統的功能需求，從系統外部觀看系統功能，并不描述系統內部對功能的具體實現，展現一組用例、參與者及其它們之間的關系。
（2）用例之間的關系：
泛化：一個用例描述的執行場景是另一個用例描述的執行場景的特例；
包含：一個用例描述的執行場景是另一個用例所描述的場景中的一步；
擴展：一個用例描述的執行是對另一用例所描述的執行場景的擴展；
用例之間的包含關系：一個用例是對另一個用例描述的活動序列的某個活動
的細化
類圖
展示系統中的類、類的屬性和操作、以及類與類之間的關系(關聯、依賴、聚合等)
類圖怎么畫？名稱、屬性、操作
類圖的可視性標記：“+”：公共，可以被外部對象訪問。“#”：保護，可以被本類或子類的對象訪問。“-”：私用：不可以被外部對象訪問，只能為本類的對象使用
派生：另一種可以為屬性提供的信息是派生值，它可以使用數學函數、字符串函數或者將要在應用程序中實現的其他商務邏輯。 要想指出一個屬性是派生的，需要在屬性名之前添加一個前斜線（／）， 并且要附加一個注釋，其中包含了派生屬性值的指令。
序列圖：
ch.7 面向對象分析
是什么？找出并規定該問題域中根據系統各項要求而行動并相互作用的對象，并依據這些對象及其關系建立問題域模型。
步驟：
第一步：用例建模
建立軟件系統的用例模型，用例圖+用例描述
用例圖：（用例圖詳細內容看ch.6）
用例描述：
第二步：對象建模
理解用例描述
識別類和類的屬性（怎么識別？分析類）
三種分析類
👌邊界類：描述與參與者直接打交道的對象，一般是一些UI界面
👌控制類：描述系統的行為，即系統做什么
👌實體類：描述系統的中的數據信息（有些數據是實體類，而有些是實體類的屬性）
識別類的操作（怎么識別？為用例建立順序圖）
確定類與類之間的關系
評審
建立軟件系統的靜態結構模型，類圖
第三步：動態建模
描述系統的行為
第四步：評審
面向對象建模考試不會考，暫時停滯在這里，以后有機會的話再來補充。
ch.8 軟件體系結構與設計模式
不考，不總結了
上課pdf
🔥
設計模式是一套被人反復使用、多數人知曉、經過分類編目的、代碼設計經驗的總結，描述了軟件系統設計過程中常見問題的一些解決方案，通常是從大量的成功實踐中總結出來的且被廣泛公認的實踐和知識，描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方案
使用設計模式，我們就能一次一次地利用已有方案而不必做重復勞動
更重要的是可以使我們更加深刻地理解面向對象的設計思想，非常有利于我們更好地使用面向對象語言解決設計中的問題。
ch.9 用戶界面設計與軟件實現
本節所處的地位：
不考，不總結了
上課pdf
ch.10 軟件測試與維護
從是否關心軟件內部結構和具體實現的角度：
黑盒測試、白盒測試
從是否執行程序的角度：
靜態測試、動態測試
在軟件交付使用后對其進行的修改，以糾正故障，改善性能，使產品適應改變了的環境。
目的：就是保證軟件系統能持續地與用戶環境、數據處理操作相協調，最終使系統穩定運行。
（1）是什么？屬于動態白盒的測試內容。測試程序的狀態以及程序流程，設法進入和退出每一個模塊，執行每一行的代碼，進入軟件的每一條邏輯和決策分支。
（2）包括：語句覆蓋，分支覆蓋，條件覆蓋
（3）滿足分支覆蓋一定滿足語句覆蓋。
ch.11 敏捷開發
不考，不總結了
上課pdf
總結
- 上一篇： 累.....
- 下一篇： R语言批量下载PubMed摘要