《軟件工程復習重點》由會員分享，可在線閱讀，更多相關《軟件工程復習重點（57頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、三大塊內容： 軟件危機與軟件工程 傳統(tǒng)軟件開發(fā)方法 面向對象方法 一、 軟件危機與軟件工程： 軟件、軟件危機、軟件生存期、軟件開發(fā)模型、軟件管理 1、 軟件： 軟件是能夠完成預定功能和性能的可執(zhí)行的計算機程序 +使程序正常運行所需要的數(shù)據(jù) +描述軟件開發(fā)過程及其管理、程序的操作和使用的有關文檔。 文檔：分開發(fā)、管理、用戶、維護文檔，作用是記錄及解決不可視性、通信與交流、管理與維護、用戶服務 2、 軟件危機 a) 表現(xiàn)：軟件成本高、難于控制開發(fā)進度、軟件工作量估計困難、軟件質量低、軟件修改維護困難 b) 原因：需求問題(描述不精確、理解不一致)、管理問題、

2、方法和工具問題、軟 件本身的特點 3、 軟件生存期： a) 三個時期： 定義時期(軟件計劃、需求分析)—>開發(fā)時期(軟件設計、編碼實現(xiàn)、測試)—>使用和維護時期(維護) b) 六個階段：軟件計劃à需求分析à設計à編碼à測試à使用與維護 c) 生命周期方法特點：順序性、依賴性，推遲程序的物理實現(xiàn)、質量保證的觀點(利于盡早發(fā)現(xiàn)錯誤，如階段文檔、評審) 4、 軟件開發(fā)模型 a) 瀑布模型：文檔驅動 i. 階段劃分、分而治之、控制開發(fā)過程的復雜性 ii. 自頂向下、由抽象到具體，順序進行 優(yōu)點：規(guī)范管理開發(fā)過程、文檔驅動 缺點：初期系統(tǒng)的需求難以完全確定、文檔驅動、

3、周期長 b) 原型模型： i. 針對：軟件開發(fā)初期需求難以確定 ii. 基本思想：快速建立原型，完善用戶需求 iii. 優(yōu)點：用戶參與、快速 iv. 缺點：快速弱功能、對開發(fā)環(huán)境要求高 c) 螺旋模型(風險驅動) d) 增量模型(模塊、功能驅動) e) 迭代模型 f) 噴泉模型 5、 軟件管理 a) 區(qū)別于其他工業(yè)產(chǎn)品生產(chǎn)管理的特點 b) 主要內容：開發(fā)計劃與進度管理、文檔管理、人員組織管理、成本管理、質量管理 二、 傳統(tǒng)軟件工程方法： a) 軟件計劃 i. 問題定義 ii. 可行性研究 1. 經(jīng)濟可行性 2. 技術可行性 3. 法律可行性 b)

4、 需求分析 i. 結構化分析SA ii. 面向數(shù)據(jù)流的分析方法 1. DFD四個組成部分(表示方法、命名) 2. DFD作圖：需求描述àDFD 3. 層次分解法(保持父圖和其子圖的平衡) 4. 數(shù)據(jù)字典(符號) c) 軟件設計 i. 總體設計 1. 模塊獨立性：高內聚 2. 作用域是控制域的子集 3. 單入單出 4. 規(guī)模、深度、寬度、扇入、扇出適當 ii. 傳統(tǒng)設計方法 1. 面向數(shù)據(jù)流的設計方法(數(shù)據(jù)流圖) a) 結構化設計SD-à對應有SD結構化需求分析、SP結構化實現(xiàn) b) DFDà軟件結構(層次圖) i. 變換設計 ii. 事務設計 c) 優(yōu)缺點

5、 2. 面向數(shù)據(jù)結構的設計方法 a) Jackson方法 b) Jackson圖 i. 三種元素間的邏輯關系：順序、選擇、重復 ii. 可描述兩種數(shù)據(jù)結構:數(shù)據(jù)結構、程序結構 c) 思想：數(shù)據(jù)結構與程序處理過程相互轉換 d) 步驟：I/O DSà對應關系àProgram Structureà細化求精 e) 優(yōu)缺點： i. 數(shù)據(jù)入手 ii. 簡化數(shù)據(jù)處理程序的設計 iii. 模塊與獨立性原則沒有給予應有的重視 iv. 求提供對復雜系統(tǒng)設計過程的支持 3. Parnas方法 iii. 詳細設計 1. 結構化程序設計SP a) 高效率---良結構 b) 三種基本控制

6、結構、單入單出 2. 過程設計的工具 d) 實現(xiàn)/編碼 i. 語言 1. 功能等價 2. 描述問題方便性有差異 a) 例如：OOPL---非OOPL ii. 程序設計風格 e) 軟件測試 i. 目標 ii. 方法 1. 正確性證明 2. 靜態(tài)測試 3. 動態(tài)測試 a) 黑盒(功能)測試 i. 等價類劃分 ii. 邊界值分析 iii. 錯誤推測 b) 白盒(結構)測試 i. 語句覆蓋 ii. 判定覆蓋 iii. 條件覆蓋 iv. 判定—條件覆蓋 v. 條件組合覆蓋 iii. 步驟 f) 軟件維護 i. 四種類型 1. 校正性 2. 適應性

7、 3. 完善性 4. 預防性 ii. 提高可維護性的措施 三、 面向對象方法(Object-oriented Method) a) OOM與CM對比：區(qū)別—優(yōu)點 i. 思維方式 iv. 穩(wěn)定性 ii. 可重用性 v. 可維護性 iii. 大型軟件 b) OOSE方法 i. 三個階段、五個模型、 ii. USE CASE 第二章．傳統(tǒng)軟件工程方法：軟件計劃 具體任務：項目定義、可行性分析、軟件計劃 其中：可行性分析： 1、 可行性研究實質：可行性研究試一次大大壓縮和簡化了的系統(tǒng)分析和設計過程，也就是在較高層次上以較抽象的方式進行的系統(tǒng)分析和設

8、計過程。 2、 主要內容： a) 經(jīng)濟可行性:資金有無落實、成本—效益分析 b) 技術可行性:開發(fā)的風險、資源的有效性、技術方案 c) 操作可行性:用戶組織內的管理制度、人員素質、操作方式等是否可行。 d) 法律及社會可行性 e) 開發(fā)方案的選擇:折衷手段權衡。 3、 可行性研究的主要步驟： a) 復查系統(tǒng)規(guī)模 b) 研究正在使用的舊系統(tǒng) c) 導出高層邏輯模型 d) 重新定義問題 e) 導出多種解法 f) 推薦行動方針 g) 草擬開發(fā)計劃 h) 書寫文檔并提交審查 系統(tǒng)流程圖(物理建模工具)：會讀、讀懂。 數(shù)據(jù)流

9、圖： 概述 ? 描繪系統(tǒng)的邏輯模型的工具 ? DFD: Data Flow Diagram ? 描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng) 受的變換 數(shù)據(jù)從哪里來，到哪里去，經(jīng)過怎樣的處理，保存在哪里 ? 沒有任何具體的物理部件，只是描繪數(shù)據(jù)在軟件中 流動和被處理的邏輯過程。是系統(tǒng)邏輯功能的圖形表 示。 ?是分析員和用戶溝通的工具 是后期設計的出發(fā)點 DFD的繪制一般采用自頂向下、逐步細化的方法，主要步驟如下： ·明確系統(tǒng)界面。識別出那些不受系統(tǒng)控制但又影響系統(tǒng)運行的外部環(huán)境。 ·繪制基本系統(tǒng)模型。 基本系統(tǒng)模型由若干源點、終點和一個基本處理組成，表明系統(tǒng)

10、對數(shù)據(jù)加工變換的基本功能。 ·逐層細化基本系統(tǒng)模型得到功能級DFD和詳細DFD。下面即分層數(shù)據(jù)流圖。 假設一家工廠的采購部每天需要一張定貨報表，報表按零件編號排序，表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應該列出下述數(shù)據(jù)；零件編號零件名稱、定貨數(shù)量、目前價格、主要供應者和次要供應者。 零件入庫或出庫稱為事務，通過放在倉庫中的CRT終端把事務報告給定貨系統(tǒng)。當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次定貨。 從問題描述中提取數(shù)據(jù)流圖的四種成分。 首先考慮數(shù)據(jù)的源點和終點： ? “采購部每天需要一張定貨報表” ? “通過放在倉庫中的CRT終端把事務報告給定貨系

11、統(tǒng)” 可知： 采購員是終點 倉庫管理員是源點 接下來考慮處理： ? “采購部每天需要一張定貨報表” --采購部需要報表 ? “零件入庫或出庫稱為事務，通過放在倉庫中的 CRT終端把事務報告給定貨系統(tǒng)?！?--事務的后果是改變庫存量 可知： 產(chǎn)生報表是一個處理 處理事務是另一個處理 最后考慮數(shù)據(jù)流和數(shù)據(jù)存儲： ? 系統(tǒng)把定貨報表送給采購部----定貨報表 ? 事務需要從倉庫送到系統(tǒng)中----事務----需把事務數(shù)據(jù)存儲起來 產(chǎn)生報表和處理事務在時間上不匹配, 當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次定貨，而每天打印一次定貨報表-----需把定貨信息存儲起來

12、 可知： 定貨報表、事務是數(shù)據(jù)流(數(shù)據(jù)流如報表包含零件編號零件名稱、定貨數(shù)量、目前價格、主要供應者和次要供應者等信息。事務包含零件編號、事務類型、數(shù)量等。) 庫存清單、定貨信息是數(shù)據(jù)存儲 基本系統(tǒng)模型： 功能數(shù)據(jù)流圖：注意符號 進一步分解處理事務： 命名 1）為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名 ? 名字應代表整個數(shù)據(jù)流(或數(shù)據(jù)存儲)的內容，而不是僅僅反映它的某些成分 ? 不要使用空洞的、缺乏具體含義的名字(如“數(shù)據(jù)”、“信息”、“輸入”之類) ? 如果在為某個數(shù)據(jù)流(或數(shù)據(jù)存儲)起名字時遇到了困難，則很可能是因為對數(shù)據(jù)流圖分解不恰當造成的 2 ）為處理命名 ?

13、通常先為數(shù)據(jù)流命名，然后再為與之相關聯(lián)的處理命名，體現(xiàn)了人類習慣的“由表及里”的思考過程 ? 名字應該反映整個處理的功能 ? 名字最好由一個具體的及物動詞，加上一個具體的賓語組成。 ? 通常名字中僅包括一個動詞 ? 如果在為某個處理命名時遇到困難，則很可能是發(fā)現(xiàn)了分解不當?shù)嫩E象，應考慮重新分解 應注意的問題 1 ）是數(shù)據(jù)流不是控制流 畫數(shù)據(jù)流不是控制流；數(shù)據(jù)流圖反映系統(tǒng)“做什么”，不反映“如何做”，因此箭頭上的數(shù)據(jù)流名稱只能是名詞或名詞短語，整個圖中不反映加工的執(zhí)行順序。 2 ）一般不畫物質流 數(shù)據(jù)流反映的是能用計算機處理的數(shù)據(jù)，并不是實物，因此系統(tǒng)的數(shù)據(jù)流圖上一般不要畫物質

14、流。 3 ）加工的畫法 每個加工至少有一個輸入數(shù)據(jù) 數(shù)據(jù)流圖的用途： 1）建立新系統(tǒng)邏輯模型的工具 2）作為與用戶和開發(fā)人員交流信息的工具 3）作為分析、設計乃至維護的依據(jù) 數(shù)據(jù)字典： 概念 ? 數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合 ? DD: Data Dictionary ? 是對DFD中包含的所有元素的定義的集合 ? 在分析、設計和維護過程中供查閱用 內容 1）數(shù)據(jù)流 2）數(shù)據(jù)流分量（即數(shù)據(jù)元素） 3）數(shù)據(jù)存儲 4）處理（IPO圖或PDL更加方便）——是對上述四類元素的定義 具體信息 ? 名字——數(shù)據(jù)、控制項、數(shù)據(jù)存儲或外部實體的主要名稱 ? 別名—

15、—該元素等價的其他名字，盡量減少 ? 使用地點與方式——使用數(shù)據(jù)或控制項的處理的列表，以及使用這些對象的方式(例如作為處理的輸入，從處理輸出， 作為數(shù)據(jù)存儲，作為外部實體) ? 內容描述——描述數(shù)據(jù)或控制項內容的符號 ? 補充信息——關于數(shù)據(jù)類型、預置值、限制等的其他信息 軟件項目的量化估算 n 成本估算 & 工作量估算 n 工程進度安排 行成本估算 階段成本估算 甘特圖：歷史悠久、應用廣泛的進度計劃工具 進度安排的任務網(wǎng)絡圖 優(yōu)點：簡單，能動態(tài)地反映開發(fā)進展 缺點：難以反映多個任務間的邏輯關系 第三章．傳統(tǒng)軟件工程方法：需求分析 需求分析 n

16、 1 目標和任務 n 2 需求獲取技術 n 3 需求內容 n 4 需求建模方法 需求分析任務 n 問題分析 n 需求描述 n 需求評審 需求建模方法 1. 面向數(shù)據(jù)流的分析方法 2. 面向對象的分析方法 3. 面向數(shù)據(jù)結構的分析方法 需求工程的任務 需求開發(fā)包含四個過程：需求獲取、需求整理與分析、需求定義、需求驗證。 需求分析的具體任務：需求獲取、確定和分析需求、開發(fā)原型系統(tǒng)、編寫SRS、需求驗證、變更管理、修正計劃 軟件需求及需求的分類 軟件需求：以一種清晰、簡潔、一致且無二義性的方式，描述用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望，是在開發(fā)過

17、程中對系統(tǒng)的約束。（表達做什么而不描述如何做。） Requirement is the Basics of Quality，軟件需求的作用： ①分理解現(xiàn)實中的業(yè)務問題，并作為軟件設計的基礎；②為軟件項目的成本、時間、風險估計提供準確的依據(jù)；③少開發(fā)工作量，避免將時間與資源浪費在設計與實現(xiàn)錯誤的需求上；④通提供需求文檔和需求基線，來有效的管理系統(tǒng)演化與變更；⑤為顧客與開發(fā)團隊之間正式合同的一部分；⑥最終的驗收測試提供標準和依據(jù) 需求的分類： 業(yè)務需求à業(yè)務需求指導需求獲取à用戶需求à轉化用戶需求為系統(tǒng)需求à系統(tǒng)需求 前四個為原始問題空間、后面系統(tǒng)需求為解決方案空間。 業(yè)務需求

18、(Business Requirements)： 客戶對于系統(tǒng)的高層次目標要求(highlevel objectives) ，定義了項目的遠景和范疇(vision and scope) 1、 業(yè)務：屬于哪類業(yè)務范疇？應完成什么功能？為何目的？ 2、 客戶：軟件為誰服務？目標客戶是誰？ 3、 特性：區(qū)別于其他競爭產(chǎn)品的特性是什么？ 4、 價值：價值體現(xiàn)在那些方面？ 5、 優(yōu)先級：功能特性的優(yōu)先級次序是什么？ 用戶需求(User Requirements)： 從用戶角度描述的系 統(tǒng)功能需求與非功能需求，通常只涉及系統(tǒng)的外部行 為而不涉及內部特性。 系統(tǒng)需求(System Requ

19、irements, SR)： 系統(tǒng)應該提供 的功能或服務，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之 間的交互，不考慮系統(tǒng)內部的實現(xiàn)細節(jié) 系統(tǒng)需求的類型分： 功能性需求：描述了系統(tǒng)與其實現(xiàn)環(huán)境之間的交互。環(huán)境包括用戶和任何其他與該系統(tǒng)進行交互的外部系統(tǒng)。 功能需求可以以不同的詳細程度反復編寫和細化 功能需求描述應該完整而且一致和準確 完整性意味著用戶所需的所有的服務應該全部給出描述 一致性意味著需求描述不能前后矛盾 準確性是指需求不能出現(xiàn)模糊和二義性的地方 非功能性需求： 描述了不直接關聯(lián)到系統(tǒng)功能行為的系統(tǒng)的方方面面。從各個角度對系統(tǒng)的約束和限制，反映了客戶對

20、軟件系統(tǒng)質量和性能的額外要求，如響應時間、數(shù)據(jù)精度、可靠性等。 可用性(Usability):是一種用戶可以學會的操作、輸入準備、解釋一個系統(tǒng)或者構件輸出的狀況。 可靠性(Reliability):是系統(tǒng)或構件在給定時間內、指定條件下，完成其要求功能的能力。 性能(Performance):需求要考慮系統(tǒng)的定量屬性，比如響應時間，吞吐量、有效性和準確性。 可支持性(Supportability):需求關注于在進行部署后系統(tǒng)的變化狀況，比如包括可適配性、可維護性、可移植性等。 需求獲取技術 略 需求分析：分析方法 結構化分析方法SA 核心思想是模塊化，自頂向下逐步求精對系統(tǒng)

21、進行分析。 使用多個需求分析視圖，建立系統(tǒng)的數(shù)據(jù)、功能和行為模型 數(shù)據(jù)流圖DFD 加工說明PSPEC 數(shù)據(jù)字典DD 狀態(tài)遷移圖STD 關聯(lián)圖 E-R圖 面向對象分析方法OOA 核心思想是利用OO的概念和方法對軟件需求建造模型，以使用戶需求逐步精確化、一致化、完全化。 結構化分析建模(與SA區(qū)分)，就是面向數(shù)據(jù)流的分析方法 結構化分析方法是一種傳統(tǒng)的系統(tǒng)建模技術，它提出來一組提 高軟件結構合理性的準則。 結構化分析：使用數(shù)據(jù)流程圖、數(shù)據(jù)字典、結構化英語、判定 表和判定樹等工具，來建立一種新的、稱為結構化說明書的目 標文檔－需求規(guī)格說明書。

22、 結構化分析方法的要點是：面對數(shù)據(jù)流的分解和抽象；把復雜 問題自頂向下逐層分解 、 其中，只要求數(shù)據(jù)流圖和數(shù)據(jù)字典。 DFD是描繪系統(tǒng)邏輯模型的常用圖形工具。它描繪了信息流和數(shù)據(jù)從輸入端移動到輸出端的過程中所經(jīng)受的變換。 在DFD中沒有具體的物理元素，只是描述信息在系統(tǒng)中的流動、處理和存儲的邏輯過程，表明系統(tǒng)必須完成的基本邏輯功能。 DFD中只有四種元素，不包括任何有關物理實現(xiàn)的細節(jié)，所以，絕大多數(shù)用戶可以理解和評價它。 DFD是分析和設計的工具。 實體關系圖—E-R圖 數(shù)據(jù)流圖--DFD圖 狀態(tài)轉換圖—STD圖 DFD組成成分： （4）加工分解原則 a

23、) 1加工 ≤7子加工 b) 按問題的邏輯特性分解 c) 盡量少分解層次 d) 分解均勻 模型中還需要描述數(shù)據(jù)是如何被加工處理的：1、結構化語言 2、判定表 3、判定樹 判定表： 第四．傳統(tǒng)軟件工程方法：軟件設計中的總體設計。 軟件設計兩個階段：概要設計 詳細設計 作用：SE核心過程 軟件設計階段的任務 從工程管理的角度，分為總體設計階段和詳細設計階段； 技術的角度，分體系結構設計、數(shù)據(jù)設計、接口設計和過程設計 總體設計分兩個階段： ① 系統(tǒng)設計階段 確定系統(tǒng)的具體實現(xiàn)方案。 ② 結構設計階段 確定軟件結構 確定系統(tǒng)中每個

24、程序是由哪些模塊組成的，以及這些模塊相互間的關系。 總體設計的重要性：總體設計是軟件開發(fā)過程中一個非常重要的階段。可以肯定，如果軟件系統(tǒng)沒有經(jīng)過認真細致的總體設計，就直接考慮它的算法或直接編寫源程序，這個系 統(tǒng)的質量就很難保證。許多軟件就是因為結構上的問題，使得它經(jīng)常發(fā)生故障，而且很難維護 什么是好的軟件設計 軟件質量評價標準： 定性評價： q 用戶角度：達到需求、界面友好、簡單易學 q 開發(fā)人員角度：良結構、易測試、易維護、可移植 … 定量評價：軟件度量 宏觀標準：可靠性 良軟件結構 文檔齊全 軟件結構 軟件的各個組成部分之間的關系的表示， 決定了整個系

25、統(tǒng)的結構和質量 扇出：直接由一個塊所控制的塊數(shù) 扇入：直接調用它的上級塊數(shù)目 深度：控制的總層數(shù) 寬度：跨度最寬層的跨度數(shù) 模塊化 依據(jù)：復雜程度 工作量 模塊重要特征： 1.抽象：忽略細節(jié)，分層理解問題，自頂向下層層細化。 2. 信息隱藏 F 細節(jié)隱藏 F 可理解性 F 修改副作用小 F 錯誤副作用小 模塊獨立性 度量：耦合—塊間聯(lián)系 內聚—塊內聯(lián)系 耦合 零耦合：塊間無任何連接 數(shù)據(jù)耦合：兩模塊通過參數(shù)交換信息，只交換數(shù)據(jù)。 控制耦合：傳遞的信息有控制信息（有時以數(shù)據(jù)形式出現(xiàn)） 公共環(huán)境耦合：兩個多個模塊通過一個公共數(shù)據(jù)環(huán)境相互作用

26、問題：§ 公共部分的改動將影響所有調用它的模塊 § 公共部分的數(shù)據(jù)存取無法控制 § 復雜程度隨耦合模塊的個數(shù)增加而增加 內容耦合： n 一個模塊訪問另一個模塊的內部數(shù)據(jù) n 一個模塊不通過正常入口而轉到另一個模塊的內部 n 兩個模塊有一部分程序代碼重疊（只可能出現(xiàn)在匯編程序中） n 一個模塊有多個入口 耦合度與軟件結構 原則：盡量使用數(shù)據(jù)耦合，少用控制耦合，限制公共環(huán)境耦合的范圍，完全不用內容耦合。 內聚 高內聚意味著松耦合，內聚更重要 偶然內聚 邏輯內聚 時間內聚 過程內聚 通信內聚 順序內聚 功能內聚 內聚度與軟件結構 軟

27、件模塊分解的過程： 業(yè)務域分解/問題域分解 領域專家，企業(yè)戰(zhàn)略；系統(tǒng)à子系統(tǒng) 業(yè)務功能域分解 服務，資源；子系統(tǒng)拆分為多個服務 技術域分解 功能需求和非功能需求，當前IT技術；業(yè)務域和業(yè)務功能域分解出的元素進行整合 在模塊分解時，要注意以下幾點： n 低耦合高內聚：“從弱耦合入手，切斷聯(lián)系” n 層次性：先業(yè)務后技術，循序漸進 n 正交原則：相互獨立，職責沒有重疊 n 抽象原則 n 穩(wěn)定性原則 n 復用性原則度量 (迭代演化 面向對象) 軟件度量 度量 測量 估算 軟件度量 n 軟件復雜性度量 q 規(guī)模 q 文本復雜性 q 控制結構的復雜性

28、 n 軟件可靠性度量 q 系統(tǒng)故障率 q 軟件修復與軟件有效性 q 軟件可靠性估算 軟件設計的啟發(fā)規(guī)則 1.提高模塊獨立性 q 松耦合，高內聚 q 增加內聚，減少耦合 2.模塊規(guī)模適中 3.深度/寬度/扇入/扇出適當 4.作用域在控制域內 F 控制域：模塊本身以及所有直接或間接從屬于它的模塊的集合 F 作用域：受該模塊內一個判定影響的所有模塊的集合 n 修改軟件結構 q 判斷點上移 q 受影響塊下移 5.降低接口的復雜程度 q 接口復雜可能表明模塊的獨立性差 q 接口復雜或不一致（看起來傳遞的數(shù)據(jù)間無聯(lián)系），是緊耦合或低

29、內聚的征兆 6、單出單入，避免內容耦合 7、模塊功能可預測 q 相同輸入必產(chǎn)生相同輸出 q 模塊中使用全局變量可能導致不可預測 軟件結構劃分方式 水平劃分 n 按主要功能定義模塊結構的各分支 n 頂層控制模塊，下層輸入、處理、輸出三個分支 n 優(yōu)點：功能分離，易修改擴充 n 缺點：模塊接口傳遞數(shù)據(jù)多，信息流的整體控制復雜化 垂直劃分 n 自頂向下逐層分布工作 n 頂層模塊控制，低層模塊實際處理 n 優(yōu)點：對低層模塊的修改不易引起副作用 n 便于將來的維護 軟件系統(tǒng)設計技術 面向數(shù)據(jù)流(DFD)的設計方法 面向數(shù)據(jù)結構的設計方法

30、 原型法 結構化設計（Structured Design, SD） 基于模塊化、自頂向下求精、結構化程序設計技術基礎上發(fā)展起來 面向數(shù)據(jù)流的設計方法 數(shù)據(jù)流圖映射到軟件結構 用啟發(fā)式規(guī)則對結構進行細化 面向數(shù)據(jù)流的設計方法(結構化設計SD) 軟件結構設計中的圖形工具 ? 層次圖(H圖)-----系統(tǒng)結構圖; ------Hierarchy n 描述軟件結構，而非數(shù)據(jù)結構 n 矩形框：模塊 n 連線：調用關系，而非組成關系 ? HIPO圖=H圖+IPO表 n H圖 + IPO圖（Input-process-output Diagram） n 在

31、H圖中,除最頂層方框外,在每一個方框內加上一個編號,編號次序依次為:1.0,2.0,…； 2.1,2.2,…；3.1,3.2… n 對于H圖中的每一個方框,有一張IPO圖描述這個方框所代表模塊的處理過程 ? 結構圖------模塊聯(lián)系圖 1.結構圖是軟件結構設計的另一種工具, 與層次圖類似。 2.它在層次圖的每一個方框內注明的是模塊的名字或主要功能。 3.方框之間的直線表示模塊的調用關系。 4.用帶注解的箭頭表示模塊調用過程中傳遞的信息 基于數(shù)據(jù)流（SD ）的設計方法 又稱為結構化設計方法； 目標：給出設計軟件結構的一個系統(tǒng)化途徑； 作用：該方法定

32、義了一些不同的“映射”，利用這些映射可以把數(shù)據(jù)流圖變換成軟件結構圖。 另注: 通過結構化分析來得到DFD，SA是結構化需求分析、SD是結構化設計、SP是結構化實現(xiàn) 數(shù)據(jù)流的類型:變換流、事務流、混合型 1.變換流:所有信息都可以歸結為變換流 變換流參看圖形，信息沿輸入通路進入系統(tǒng)，同時由外部形式變換成內部形式，進入系統(tǒng)的信息通過變換中心，經(jīng)過加工處理以后再沿輸出通路變換成外部形式離開軟件系統(tǒng)。當數(shù)據(jù)流具有這些特征時，這種信息流稱為變換流。 變換型的軟件結構圖 2.事務流：當信息流具有明顯的“事務中心”時，可歸結為事務流 輸入通路到達一個處理T，這個處理根據(jù)輸入數(shù)據(jù)的類型在

33、若干個動作序列中選出一個來執(zhí) 行。這種“以事務為中心的”的數(shù)據(jù)流，稱為“事務流”。 T稱為事務中心 n 接收輸入數(shù)據(jù)； n 分析每個事務以確定它 的類型； n 根據(jù)事務類型選取一條 活動通路 事務型軟件結構圖 3.混合型，兼具兩種特征。 面向數(shù)據(jù)流方法的設計過程 一定要重點看總體設計部分后面的P140左右的例題 第五．傳統(tǒng)軟件工程方法：軟件設計中的詳細設計 詳細設計的任務 結構化程序設計 詳細設計的工具 面向數(shù)據(jù)結構設計 人機界面設計 詳細設計說明書 程序復雜性的度量 詳細設計的任務： 1. 用偽代碼、圖或表等工具描繪每個模塊的算法

34、流程。 2. 確定每個模塊的局部數(shù)據(jù)結構、數(shù)據(jù)庫的物理結構、模塊間的接口和輸入輸出數(shù)據(jù) 3. 為每個模塊設計測試用例，使得編碼階段對具體模塊的調試測試更加方便 4. 編寫詳細設計說明書 結構化程序設計(SP結構化實現(xiàn)，與結構化設計SA區(qū)分) a) 高效率---良結構 b) 三種基本控制結構、單入單出 程序代碼僅使用順序、選擇和循環(huán)這三種基本的控制結構進行連接，且每個代碼塊只有一個 入口和一個出口，只在檢測錯誤和退出循環(huán)處使用非基本結構技術。 詳細設計的工具 圖形描述 程序流程圖（ PFC）趨勢是使用的人越來越少。 優(yōu)點：直觀清晰、廣泛易學 缺點:不能逐步求

35、精，不易表示數(shù)據(jù)結構，隨意轉移控制造成非結構化 盒圖（ N-S） 本質上的改進是沒有箭頭，不能隨意轉移控制。 PAD圖 PAD圖優(yōu)點:本質上的改進是層次清晰。 結構化程序 結構清晰表現(xiàn)程序邏輯，易讀、易懂、易記 描繪數(shù)據(jù)結構 支持自頂向下、逐步求精方法的使用 PAD圖à高級程序設計語言 表格描述 判定表 判定樹 語言描述 過程設計語言PDL/偽碼 優(yōu)點:可作注釋直接插在源程序中、編輯簡單、PDLàcodes 缺點：不如“圖”直觀、復雜條件 — 不如判定表清晰、簡單 面向數(shù)據(jù)結構的設計方法 JSD法：將Jackson方法用于大系統(tǒng)設計時會出現(xiàn)復

36、雜的難以對付的結構沖突。 Jackson圖 優(yōu)點 便于表示層次結構，結構的自頂向下分解，直觀，可讀性好 數(shù)據(jù)入手 簡化數(shù)據(jù)處理程序的設計 既能表示數(shù)據(jù)結構，也能表示程序結構 缺點 沒有表示條件，不易直接把圖翻譯成程序，斜線不易打印 模塊與獨立性原則沒有給予應有的重視 求提供對復雜系統(tǒng)設計過程的支持 改進的Jackson圖 Jackson方法 1. 畫數(shù)據(jù)結構的Jackson圖 2. 找輸入—輸出數(shù)據(jù)結構的對應關系 3. 以輸出數(shù)據(jù)結構為基礎，導出程序結構的Jackson圖 有關系的數(shù)據(jù)單元 –– 合畫一個處理框 輸入數(shù)據(jù)結構中余下的數(shù)據(jù)單元 –– 各畫

37、一個 輸出數(shù)據(jù)結構中余下的數(shù)據(jù)單元 –– 各畫一個 4. 列出所有操作、條件 5. 偽碼表示程序 JACKSON的偽碼表示程序 （1）順序結構 A seq B C D A end （2）選擇結構 A select condition1 B A or condition2 C A or condition3 D A end （3）重復結構 A iter until（或while）condition B A end 第六章．傳統(tǒng)軟件工程方法：實現(xiàn)與測試。 編碼 軟件測試基礎 測試用例設計 軟件測試步驟與策略 調試

38、 軟件可靠性 一、編碼 語言： 1、 語言的元計算模型等價 → 功能等價 2、 描述問題的方便性有差異 程序設計語言的特點及其對軟件的影響： 機器求解問題的基本工具:思維方式、解題方式、人機通信的方式、理解程序的難以程度 選擇程序設計語言的理想標準：模塊化機制、語言特點、開發(fā)工具、獨立編譯機制、標準化 選擇程序設計語言的實用標準：系統(tǒng)用戶的要求、工程規(guī)模、程序員的知識、軟件的應用領域 程序設計風格： “好”程序的標準 q源程序代碼的邏輯簡明清晰、易讀易懂 遵循原則： 程序內部的文檔、數(shù)據(jù)說明、語句構造盡量簡單而直接、輸入輸出規(guī)則、效率

39、 效率：效率主要指處理機時間和存儲器容量兩個方面 n 關于效率的三條原則 q 第一，效率是性能要求，應該在需求分析階段確定效率方面的要 求； q 第二，效率是靠好設計來提高的； q 第三，程序的效率和程序的簡單度是一致的，不要犧牲程序的清 晰性和可讀性來不必要地提高效率 n 三個方面 q 程序的運行時間 q 存儲器效率 q 輸入輸出效率 二、軟件測試基礎 測試目標: 為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程 測試用例:一組用于測試的輸入數(shù)據(jù)和預期得出的正確輸出 測試方案:測試用例和用例預定要檢驗的功能、測試環(huán)境的規(guī)劃、測試工具的選擇。 測試計劃:要進行的測試的組織

40、、資源、風險、原則和進度安排等進行規(guī)定和約束 軟件測試方法分：靜態(tài)測試(人工檢查代碼，不在機器上運行)和動態(tài)測試(白盒與黑盒)。 窮盡測試：(不可能，只能選少量”最有效”做到完備)：包含所有可能情況的測試 黑盒測試 —— 功能測試 目的： q 功能是否正常使用？ q 輸入 → 正確輸出？ q 保持外部信息的完整性？ q 時機：測試的后期，如：集成測試、確認測試 白盒測試 關注軟件內部邏輯結構（ control structure） 測試每條邏輯通路 檢查斷點（ break point） 狀態(tài) 測試方案對程序邏輯的覆蓋程度決定測試的完全性程度 時機：測試的

41、早期，例如：單元測試 成本高，通常對結構比較復雜的模塊進行白盒測試 三、測試用例設計 黑盒法——依據(jù)對程序的需求和說明 等價劃分法 邊界值分析法 錯誤推測法 白盒法 邏輯覆蓋 控制結構 測試用例是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件、執(zhí)行步驟以及預期結果等等。 黑盒測試技術 a. 黑盒(功能)測試 i. 等價類劃分 ii. 邊界值分析 iii. 錯誤推測 白盒測試技術 白盒測試技術是基于程序的內部實現(xiàn)結構和邏輯 尋找軟件中的缺陷 覆蓋準則可以作為測試停止或/和選取測試數(shù)據(jù)的 標準 軟件測試的步驟與策略 第七章．傳統(tǒng)軟件

42、工程方法：維護。 軟件維護的概念和內容 軟件維護的過程 軟件的可維護性 軟件再工程過程 一、軟件維護的概念和內容 定義： 就是在軟件已經(jīng)交付使用之后，因為下列原因而修改軟件的過程。 軟件中的bug需要修復——改正性維護 軟件在使用過程中，新的需求不斷出現(xiàn)——完善性維護 商業(yè)環(huán)境在不斷地變化、計算機硬件和軟件環(huán)境的升級需要更新現(xiàn)有的系統(tǒng)—適應性維護 軟件的性能和可靠性需要進一步改進——預防性維護 類型: n 校正性維護/糾錯性維護（corrective maintenace） n 適應性維護（adaptive maintenance） n 完善性維護（perfecti

43、ve maintenance） n 預防性維護（preventive maintenace） 維護的代價： n 表面上看來合理的改錯或修改不能完全滿足用戶的要求，就會引起用戶的不滿。 n 由于維護時對軟件的改動，哪怕是很小的改動，在軟件中也會引入潛在的隱患或錯誤，使得整個軟件的質量降低， 特別是不可再現(xiàn)錯誤。 n 在開發(fā)工作期間，由于工作需要必須把軟件工程師調去從事維護工作，就會對開發(fā)工作造成不良影響。 n 軟件維護會使生產(chǎn)率大幅度下降 維護中的問題 n 閱讀和理解問題 n 人員問題 n 文檔資料 n 軟件的修改 n 軟件維護相對于軟件系統(tǒng)開發(fā)工作來說則毫無吸

44、引力 二、軟件維護過程 軟件維護過程定義：本質上是修改和壓縮了的軟件定義和開發(fā)過程。 n 建立維護組織 n 提出維護申請報告及評價 n 維護實施 n 保存維護記錄 n 評價維護活動 三、可維護性 軟件可維護性是指糾正軟件系統(tǒng)出現(xiàn)的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度 可維護性的決定因素 可理解性 可測試性 可修改性 可靠性 可移植性 可使用性 效率。 提高可維護性的措施 維護的副作用 F 修改軟件后導致新錯誤的發(fā)生 n 編碼的副作用 n 數(shù)據(jù)的副作用 文檔資料的副作用 完善的設計文檔資料可以減少數(shù)據(jù)的副作用。

45、利用文檔資料對數(shù)據(jù)及其用途所作的詳細描述 ，提供了數(shù)據(jù)項、記錄、文件及其他結構與軟件模塊間相關的參照表，是維護期間對數(shù)據(jù)結構進行修改的主要依據(jù)。 第七章 軟件管理 軟件管理內容 n 開發(fā)計劃與進度管理 n 成本估算與控制 n 人員管理、組織管理 n 質量管理 n 文檔管理 軟件管理原則 n 軟件生存期 n 按階段確認 n 質量檢查 n 自頂向下SP/OOP n 職責分明 n 人員少而精 n 不斷充實 軟件管理特點 n 知識密集，非實物性 n 單品生產(chǎn)，開發(fā)過程不確定 n 開發(fā)周期長 n 內容復雜，正確性難保證 n 勞動密

46、集，自動化程度低 n 軟件用法繁瑣，維護困難，費用高 指定軟件開發(fā)計劃三要素：規(guī)模 人員 交付日期 進度安排與控制 n 軟件開發(fā)進度安排，實際上就是對軟件開發(fā)中各個階段所需要的工作量，結合項目的起始時間，體現(xiàn)在一張編制的進度表里(甘特圖)。 n 軟件開發(fā)的進度往往與人的因素有關，對人的依賴性很大。 n 進度控制是對計劃執(zhí)行情況的監(jiān)督、調整和修改。 成本管理與控制 n 工時數(shù)成本管理 n 開發(fā)設備的購置、使用管理 人員管理、組織管理 n 人員管理 q 高技術、高知識，個人作用突出 q 多層次 —— 合理配備各類人員 q 知識更新快 q 流動性大 ——

47、保持人員相對穩(wěn)定，吸引優(yōu)秀人才 n 組織管理 q 集中式 —— 易決斷、易管理，難發(fā)揮多數(shù)人的積極性 q 非集中式 —— 發(fā)揮大家主觀能動性、難管理 質量管理 n 軟件生產(chǎn) q 分階段 q 規(guī)范化 q 合理分工 n 度量軟件質量的標準 文檔管理 第八章--面向對象方法學引論。 面向對象方法學概述 面向對象的概念 面向對象建模 一、面向對象方法學概述 OO和PO的本質區(qū)別是：對象是一元的還是過程是一元 OOM四要素：1對象 2類 3繼承 4方法與消息 二、面向對象的概念 對象： 對象是一個程序模塊，該模塊由一組操

48、作構成的集合 對象是對問題域中某個東西的抽象，這種抽象反應了系統(tǒng)保存有關這個東西的信息或與它交互的能力。 對象是一臺自動機 對象特點 n 數(shù)據(jù)為中心 n 主動的 n 數(shù)據(jù)封裝 n 并行性 n 模塊獨立性好 繼承的優(yōu)點 n 共享程序代碼和數(shù)據(jù)結構 n 減少了冗余信息 n 修改方便 q 擴充：調用基類方法并增加代碼 q 改變：改寫同名方法 q 新增：定義新方法 n 軟件重用 OOM的主要優(yōu)點 n 與人類習慣的思維方法一致 CM n 面向過程設計，以算法為核心，送數(shù)據(jù)到函數(shù) n 數(shù)據(jù)與操作分離，不易理解 OOM q 以o

49、bject 為核心，強調對現(xiàn)實概念的模擬而不強調算法 q “面向對象方法學的基本原則，是按照人們習慣的思維方式建立問題域的模型，開發(fā)出盡可能直觀、自然地表現(xiàn)求解方法的軟件系統(tǒng)” q 數(shù)據(jù)和操作封裝成統(tǒng)一體，送消息到對象 n 穩(wěn)定性好 Cm q 結構依賴于功能，不穩(wěn)定 q 功能需求變，易引起軟件結構整體修改 Oom q 軟件系統(tǒng)結構根據(jù)問題域模型建立 q 以object模擬實體，實體相對穩(wěn)定，故系統(tǒng)也相應穩(wěn)定 q 需求變化不會引起結構的整體變化，只需局部性修改 n 可重用性好 CM q 過程（函數(shù)）是重用層 q 建立標準函數(shù)庫來重用軟構件 q 標準函數(shù)缺乏“

50、柔性”，難以適應不同場合的不同需要 q 功能內聚的模塊不是自含和獨立的 OOM q 類是重用層 q object具有較強的自含性和獨立性 q object和class提供了理想的模塊化機制和可重用的軟件成分 q 繼承性為OOM提供了比CM更廣泛、更規(guī)范、更簡單的重用機制 n 可維護性好 CM q 開發(fā)出來的軟件難維護 OOM q 穩(wěn)定性好：功能需求變化不牽動全局，只需局部修改 q 容易修改 n Class 獨立性強 n Inheritance和多態(tài)性(polymorphism) q 容易理解 q 容易測試、調試 n 較易開發(fā)大型軟件產(chǎn)品，對系統(tǒng)的復

51、雜性具有較強的處理能力 CM q 組織開發(fā)人員的方法不恰當 q 強調自頂向下功能分解，限制了可重用性，重復工作，生產(chǎn)率低 q 好的SD將控制集中在高層模塊，因而對于復雜系統(tǒng)、GUI的交互式系統(tǒng)、控制要求突出的系統(tǒng)，不能適應需求的變動 OOM q 把一個大型產(chǎn)品看作是一系列本質上相互獨立的小產(chǎn)品來處理 q 降低了開發(fā)的技術難度，而且也使得對開發(fā)工作的管理變得容易 q 自底向上分析和設計，自頂向下實現(xiàn)（繼承），可重用性好 q OOM并不是減少了開發(fā)時間，而是通過提高可重用性、可維護性，進行擴充和修改的容易程度等，從長遠角度改進了軟件的質量 OO建模方法 Booch的面向對象開

52、發(fā)方法 OOA和OOD法 對象建模技術（OMT） 面向對象軟件工程(OOSE) 統(tǒng)一建模語言UML 對象模型技術（OMT） 對象模型(OM) 結構：歸納關系 組合關系 關聯(lián)關系（看書?。? 動態(tài)模型（DM） n 基于事件共享而互相關聯(lián)的一組狀態(tài)圖的集合 n 表示系統(tǒng)瞬時的控制性質 n 三要素 q 事件 (event)：引發(fā) object 狀態(tài)改變的控制信息（瞬時） q 狀態(tài)(status):即 object 的 attributes 所處的情形（可持續(xù)） q 行為(action): Object 要達到某種 status 所做的操作（耗時） 功能模型

53、(FM) 表明系統(tǒng)應該做什么 數(shù)據(jù)流圖 IPO圖 OOM的工作重點在分析階段，確定objects 三模型關系 n FM：做什么（What） n DM：何時做（When） n OM：操作的實體（Who） 面向對象程序設計語言（OOPL） 優(yōu)點 一致的表達方式 可重用性好 可維護性好 類型檢查 按編譯時進行類型檢查的嚴格程度，分為強類型（每個變量（屬性）必須準確屬于某個類） 弱類型（僅要求每個變量（屬性）隸屬于一個對象） 面向對象分析（OOA） 1.提取用戶需求—理解 表達 驗證 2.建立三個模型—OM FM DM

54、 面向對象設計（OOD） 兩個階段： 系統(tǒng)設計 對象設計 界限模糊，不嚴格劃分 SD設計準則：模塊化 抽象 信息隱藏 模塊獨立性 OOD設計準則： 模塊化（模塊—類/對象） 抽象（過程抽象 數(shù)據(jù)抽象 參數(shù)化抽象） 信息隱藏（隱藏=對象封裝） 弱耦合（交互耦合盡量松 繼承耦合盡量緊） 強內聚（服務內聚 類內聚 一般-特殊內聚） 可重用（代碼重用 設計重用 分析重用） 可重用兩方面含義： q 盡量使用已有的類 q 創(chuàng)建新類時應考慮將來的可重用性 面向對象實現(xiàn) 步驟： OOA->OOD->OOP->OOT 面向對

55、象分析->面向對象設計-面向對象編碼->面向對象測試 OO軟件開發(fā)模型---噴泉模型 面向對象開發(fā)技術 OOA／OOD：依據(jù)生命周期，按部就班的方法，便以執(zhí)行線索途徑尋找對象。 OMT：建立在實體／關系模型基礎上，并延伸到類、繼承和操作。 OOSE面向對象的軟件工程，該方法建立在系列模式基礎上，是一個操作性很強方法。 面向對象軟件工程（OOSE） 模型及關系 n 需求模型（RM：Requirement Model） n 分析模型（AM：Analysis Model） n 設計模型（DM：Design Model） n 實現(xiàn)模型（IM：Implementation Model） n 測試模型（TM：Test Model）