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

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

3、對:軟件開發初期需求難以確定ii. 基本思想：快速建立原型,完善用戶需求iii. 優點：用戶參與、快速iv. 缺點：快速弱功能、對開發環境要求高c) 螺旋模型（風險驅動）d) 增量模型(模塊、功能驅動)e) 迭代模型f) 噴泉模型5、 軟件管理a) 區別于其他工業產品生產管理的特點b) 主要內容：開發計劃與進度管理、文檔管理、人員組織管理、成本管理、質量管理二、 傳統軟件工程方法：a) 軟件計劃i. 問題定義ii. 可行性研究1. 經濟可行性2. 技術可行性3. 法律可行性b) 需求分析i. 結構化分析SAii. 面向數據流的分析方法1. DFD四個組成部分（表示方法、命名)2. DFD作圖：

4、需求描述àDFD3. 層次分解法（保持父圖和其子圖的平衡）4. 數據字典（符號）c) 軟件設計i. 總體設計1. 模塊獨立性：高內聚2. 作用域是控制域的子集3. 單入單出4. 規模、深度、寬度、扇入、扇出適當ii. 傳統設計方法1. 面向數據流的設計方法（數據流圖)a) 結構化設計SDà對應有SD結構化需求分析、SP結構化實現b) DFDà軟件結構（層次圖)i. 變換設計ii. 事務設計c) 優缺點2. 面向數據結構的設計方法a) Jackson方法b) Jackson圖i. 三種元素間的邏輯關系:順序、選擇、重復ii. 可描述兩種數據結構:數據結構、程序結構c

5、) 思想：數據結構與程序處理過程相互轉換d) 步驟：I/O DSà對應關系àProgram Structureà細化求精e) 優缺點:i. 數據入手ii. 簡化數據處理程序的設計iii. 模塊與獨立性原則沒有給予應有的重視iv. 求提供對復雜系統設計過程的支持3. Parnas方法iii. 詳細設計1. 結構化程序設計SPa) 高效率-良結構b) 三種基本控制結構、單入單出2. 過程設計的工具d) 實現/編碼i. 語言1. 功能等價2. 描述問題方便性有差異a) 例如:OOPL-非OOPLii. 程序設計風格e) 軟件測試i. 目標ii. 方法1. 正確性證明2.

6、 靜態測試3. 動態測試a) 黑盒(功能)測試i. 等價類劃分ii. 邊界值分析iii. 錯誤推測b) 白盒(結構)測試i. 語句覆蓋ii. 判定覆蓋iii. 條件覆蓋iv. 判定條件覆蓋v. 條件組合覆蓋iii. 步驟f) 軟件維護i. 四種類型1. 校正性2. 適應性3. 完善性4. 預防性ii. 提高可維護性的措施三、 面向對象方法(Objectoriented Method)a) OOM與CM對比:區別優點i. 思維方式 iv。 穩定性ii. 可重用性 v。 可維護性iii. 大型軟件b) OOSE方法i. 三個階段、五個模型、ii. USE CASE第二章傳統軟件工程方法：軟件計劃具

7、體任務:項目定義、可行性分析、軟件計劃其中：可行性分析:1、 可行性研究實質：可行性研究試一次大大壓縮和簡化了的系統分析和設計過程，也就是在較高層次上以較抽象的方式進行的系統分析和設計過程。2、 主要內容： a) 經濟可行性：資金有無落實、成本-效益分析b) 技術可行性:開發的風險、資源的有效性、技術方案c) 操作可行性：用戶組織內的管理制度、人員素質、操作方式等是否可行。d) 法律及社會可行性e) 開發方案的選擇:折衷手段權衡.3、 可行性研究的主要步驟：a) 復查系統規模b) 研究正在使用的舊系統c) 導出高層邏輯模型d) 重新定義問題e) 導出多種解法f) 推薦行動方針g) 草擬開發計劃

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

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

10、知：采購員是終點倉庫管理員是源點接下來考慮處理： “采購部每天需要一張定貨報表” -采購部需要報表 “零件入庫或出庫稱為事務，通過放在倉庫中的CRT終端把事務報告給定貨系統." 事務的后果是改變庫存量可知：產生報表是一個處理處理事務是另一個處理最后考慮數據流和數據存儲: 系統把定貨報表送給采購部-定貨報表 事務需要從倉庫送到系統中-事務-需把事務數據存儲起來產生報表和處理事務在時間上不匹配, 當某種零件的庫存數量少于庫存量臨界值時就應該再次定貨,而每天打印一次定貨報表-需把定貨信息存儲起來可知:定貨報表、事務是數據流(數據流如報表包含零件編號零件名稱、定貨數量、目前價格、主要供應者和

11、次要供應者等信息.事務包含零件編號、事務類型、數量等。）庫存清單、定貨信息是數據存儲基本系統模型：功能數據流圖：注意符號進一步分解處理事務：命名1）為數據流(或數據存儲)命名 名字應代表整個數據流（或數據存儲)的內容，而不是僅僅反映它的某些成分 不要使用空洞的、缺乏具體含義的名字（如“數據"、“信息”、“輸入”之類） 如果在為某個數據流（或數據存儲)起名字時遇到了困難，則很可能是因為對數據流圖分解不恰當造成的2 ）為處理命名 通常先為數據流命名，然后再為與之相關聯的處理命名，體現了人類習慣的“由表及里”的思考過程 名字應該反映整個處理的功能 名字最好由一個具體的及物動詞，加上一個具體

12、的賓語組成。 通常名字中僅包括一個動詞 如果在為某個處理命名時遇到困難，則很可能是發現了分解不當的跡象，應考慮重新分解應注意的問題1 ）是數據流不是控制流畫數據流不是控制流；數據流圖反映系統“做什么”,不反映“如何做”,因此箭頭上的數據流名稱只能是名詞或名詞短語,整個圖中不反映加工的執行順序.2 )一般不畫物質流數據流反映的是能用計算機處理的數據,并不是實物，因此系統的數據流圖上一般不要畫物質流。3 ）加工的畫法每個加工至少有一個輸入數據數據流圖的用途：1）建立新系統邏輯模型的工具2）作為與用戶和開發人員交流信息的工具3）作為分析、設計乃至維護的依據數據字典：概念 數據字典是關于數據的信息的集

13、合 DD： Data Dictionary 是對DFD中包含的所有元素的定義的集合 在分析、設計和維護過程中供查閱用內容1)數據流2）數據流分量（即數據元素）3）數據存儲4）處理（IPO圖或PDL更加方便）是對上述四類元素的定義具體信息 名字數據、控制項、數據存儲或外部實體的主要名稱 別名-該元素等價的其他名字,盡量減少 使用地點與方式使用數據或控制項的處理的列表，以及使用這些對象的方式（例如作為處理的輸入,從處理輸出， 作為數據存儲，作為外部實體） 內容描述描述數據或控制項內容的符號 補充信息關于數據類型、預置值、限制等的其他信息 軟件項目的量化估算n 成本估算 工作量估算n 工程進度安排行

14、成本估算 階段成本估算甘特圖：歷史悠久、應用廣泛的進度計劃工具進度安排的任務網絡圖優點:簡單，能動態地反映開發進展缺點：難以反映多個任務間的邏輯關系第三章傳統軟件工程方法:需求分析需求分析n 1 目標和任務n 2 需求獲取技術n 3 需求內容n 4 需求建模方法需求分析任務n 問題分析n 需求描述n 需求評審需求建模方法1. 面向數據流的分析方法2. 面向對象的分析方法3. 面向數據結構的分析方法需求工程的任務需求開發包含四個過程：需求獲取、需求整理與分析、需求定義、需求驗證。需求分析的具體任務：需求獲取、確定和分析需求、開發原型系統、編寫SRS、需求驗證、變更管理、修正計劃軟件需求及需求的分

15、類軟件需求：以一種清晰、簡潔、一致且無二義性的方式，描述用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望,是在開發過程中對系統的約束。（表達做什么而不描述如何做.）Requirement is the Basics of Quality，軟件需求的作用：分理解現實中的業務問題,并作為軟件設計的基礎；為軟件項目的成本、時間、風險估計提供準確的依據；少開發工作量，避免將時間與資源浪費在設計與實現錯誤的需求上；通提供需求文檔和需求基線，來有效的管理系統演化與變更;為顧客與開發團隊之間正式合同的一部分；最終的驗收測試提供標準和依據需求的分類：業務需求à業務需求指導需求獲取à

16、;用戶需求à轉化用戶需求為系統需求à系統需求前四個為原始問題空間、后面系統需求為解決方案空間。業務需求(Business Requirements)： 客戶對于系統的高層次目標要求（highlevel objectives） ，定義了項目的遠景和范疇(vision and scope）1、 業務:屬于哪類業務范疇？應完成什么功能？為何目的？2、 客戶：軟件為誰服務？目標客戶是誰？3、 特性：區別于其他競爭產品的特性是什么？4、 價值：價值體現在那些方面？5、 優先級:功能特性的優先級次序是什么？用戶需求（User Requirements）： 從用戶角度描述的系統功能需求與

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

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

19、個需求分析視圖，建立系統的數據、功能和行為模型數據流圖DFD加工說明PSPEC數據字典DD狀態遷移圖STD關聯圖ER圖面向對象分析方法OOA核心思想是利用OO的概念和方法對軟件需求建造模型，以使用戶需求逐步精確化、一致化、完全化。結構化分析建模(與SA區分）,就是面向數據流的分析方法結構化分析方法是一種傳統的系統建模技術，它提出來一組提高軟件結構合理性的準則。結構化分析：使用數據流程圖、數據字典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔需求規格說明書。結構化分析方法的要點是：面對數據流的分解和抽象；把復雜問題自頂向下逐層分解、其中，只要求數據流圖和數據字典。

20、DFD是描繪系統邏輯模型的常用圖形工具。它描繪了信息流和數據從輸入端移動到輸出端的過程中所經受的變換.在DFD中沒有具體的物理元素,只是描述信息在系統中的流動、處理和存儲的邏輯過程,表明系統必須完成的基本邏輯功能。DFD中只有四種元素，不包括任何有關物理實現的細節,所以,絕大多數用戶可以理解和評價它。DFD是分析和設計的工具。實體關系圖E-R圖數據流圖-DFD圖狀態轉換圖STD圖DFD組成成分:（4）加工分解原則a) 1加工 7子加工b) 按問題的邏輯特性分解c) 盡量少分解層次d) 分解均勻模型中還需要描述數據是如何被加工處理的：1、結構化語言 2、判定表 3、判定樹判定表: 第四傳統軟件工

21、程方法：軟件設計中的總體設計。軟件設計兩個階段:概要設計 詳細設計作用:SE核心過程軟件設計階段的任務從工程管理的角度，分為總體設計階段和詳細設計階段； 技術的角度，分體系結構設計、數據設計、接口設計和過程設計總體設計分兩個階段： 系統設計階段確定系統的具體實現方案。 結構設計階段確定軟件結構確定系統中每個程序是由哪些模塊組成的，以及這些模塊相互間的關系.總體設計的重要性：總體設計是軟件開發過程中一個非常重要的階段。可以肯定，如果軟件系統沒有經過認真細致的總體設計,就直接考慮它的算法或直接編寫源程序，這個系統的質量就很難保證。許多軟件就是因為結構上的問題，使得它經常發生故障，而且很難維護什么是

22、好的軟件設計軟件質量評價標準:定性評價：q 用戶角度：達到需求、界面友好、簡單易學q 開發人員角度：良結構、易測試、易維護、可移植 定量評價:軟件度量宏觀標準：可靠性 良軟件結構 文檔齊全軟件結構軟件的各個組成部分之間的關系的表示，決定了整個系統的結構和質量扇出：直接由一個塊所控制的塊數扇入：直接調用它的上級塊數目深度:控制的總層數寬度：跨度最寬層的跨度數模塊化依據：復雜程度 工作量模塊重要特征:1.抽象：忽略細節，分層理解問題，自頂向下層層細化.2. 信息隱藏F 細節隱藏F 可理解性F 修改副作用小F 錯誤副作用小模塊獨立性度量：耦合塊間聯系 內聚塊內聯系耦合零耦合:塊間無任何連接數據耦合:

23、兩模塊通過參數交換信息，只交換數據。控制耦合：傳遞的信息有控制信息(有時以數據形式出現)公共環境耦合：兩個多個模塊通過一個公共數據環境相互作用問題：§ 公共部分的改動將影響所有調用它的模塊 § 公共部分的數據存取無法控制 § 復雜程度隨耦合模塊的個數增加而增加內容耦合：n 一個模塊訪問另一個模塊的內部數據n 一個模塊不通過正常入口而轉到另一個模塊的內部n 兩個模塊有一部分程序代碼重疊(只可能出現在匯編程序中）n 一個模塊有多個入口耦合度與軟件結構原則：盡量使用數據耦合，少用控制耦合，限制公共環境耦合的范圍，完全不用內容耦合。內聚高內聚意味著松耦合，內聚更重要偶然內

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

25、 軟件可靠性度量q 系統故障率q 軟件修復與軟件有效性q 軟件可靠性估算軟件設計的啟發規則1.提高模塊獨立性q 松耦合，高內聚q 增加內聚,減少耦合2。模塊規模適中3。深度/寬度/扇入/扇出適當4。作用域在控制域內F 控制域：模塊本身以及所有直接或間接從屬于它的模塊的集合 F 作用域：受該模塊內一個判定影響的所有模塊的集合n 修改軟件結構q 判斷點上移q 受影響塊下移5。降低接口的復雜程度q 接口復雜可能表明模塊的獨立性差q 接口復雜或不一致（看起來傳遞的數據間無聯系）,是緊耦合或低內聚的征兆6、單出單入,避免內容耦合7、模塊功能可預測q 相同輸入必產生相同輸出q 模塊中使用全局變量可能導致不

26、可預測軟件結構劃分方式水平劃分 n 按主要功能定義模塊結構的各分支n 頂層控制模塊，下層輸入、處理、輸出三個分支n 優點：功能分離,易修改擴充n 缺點：模塊接口傳遞數據多,信息流的整體控制復雜化垂直劃分n 自頂向下逐層分布工作n 頂層模塊控制，低層模塊實際處理n 優點：對低層模塊的修改不易引起副作用n 便于將來的維護軟件系統設計技術面向數據流（DFD）的設計方法 面向數據結構的設計方法 原型法結構化設計（Structured Design, SD）基于模塊化、自頂向下求精、結構化程序設計技術基礎上發展起來面向數據流的設計方法數據流圖映射到軟件結構用啟發式規則對結構進行細化面向數據流的設計方法（

27、結構化設計SD)軟件結構設計中的圖形工具Ø 層次圖（H圖）-系統結構圖； -Hierarchyn 描述軟件結構，而非數據結構n 矩形框：模塊n 連線：調用關系,而非組成關系Ø HIPO圖=H圖+IPO表n H圖 + IPO圖（Inputprocessoutput Diagram）n 在H圖中,除最頂層方框外,在每一個方框內加上一個編號，編號次序依次為:1.0,2.0,；2。1，2。2,；3.1，3.2n 對于H圖中的每一個方框，有一張IPO圖描述這個方框所代表模塊的處理過程Ø 結構圖-模塊聯系圖1。結構圖是軟件結構設計的另一種工具, 與層次圖類似。2。它在層次圖的

28、每一個方框內注明的是模塊的名字或主要功能。3.方框之間的直線表示模塊的調用關系。4。用帶注解的箭頭表示模塊調用過程中傳遞的信息基于數據流（SD )的設計方法又稱為結構化設計方法；目標：給出設計軟件結構的一個系統化途徑；作用:該方法定義了一些不同的“映射”，利用這些映射可以把數據流圖變換成軟件結構圖。另注： 通過結構化分析來得到DFD，SA是結構化需求分析、SD是結構化設計、SP是結構化實現數據流的類型：變換流、事務流、混合型1.變換流:所有信息都可以歸結為變換流變換流參看圖形,信息沿輸入通路進入系統，同時由外部形式變換成內部形式，進入系統的信息通過變換中心，經過加工處理以后再沿輸出通路變換成外

29、部形式離開軟件系統.當數據流具有這些特征時，這種信息流稱為變換流。變換型的軟件結構圖2.事務流：當信息流具有明顯的“事務中心”時,可歸結為事務流輸入通路到達一個處理T，這個處理根據輸入數據的類型在若干個動作序列中選出一個來執行。這種“以事務為中心的”的數據流，稱為“事務流”。T稱為事務中心n 接收輸入數據;n 分析每個事務以確定它的類型；n 根據事務類型選取一條活動通路事務型軟件結構圖3。混合型，兼具兩種特征。面向數據流方法的設計過程一定要重點看總體設計部分后面的P140左右的例題第五傳統軟件工程方法：軟件設計中的詳細設計詳細設計的任務結構化程序設計詳細設計的工具面向數據結構設計人機界面設計詳

30、細設計說明書程序復雜性的度量詳細設計的任務:1。 用偽代碼、圖或表等工具描繪每個模塊的算法流程。2. 確定每個模塊的局部數據結構、數據庫的物理結構、模塊間的接口和輸入輸出數據3。 為每個模塊設計測試用例，使得編碼階段對具體模塊的調試測試更加方便4。 編寫詳細設計說明書結構化程序設計（SP結構化實現，與結構化設計SA區分）a) 高效率-良結構b) 三種基本控制結構、單入單出程序代碼僅使用順序、選擇和循環這三種基本的控制結構進行連接，且每個代碼塊只有一個入口和一個出口，只在檢測錯誤和退出循環處使用非基本結構技術。詳細設計的工具圖形描述程序流程圖（ PFC)趨勢是使用的人越來越少.優點：直觀清晰、廣

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

32、表示層次結構,結構的自頂向下分解，直觀，可讀性好數據入手簡化數據處理程序的設計既能表示數據結構，也能表示程序結構缺點沒有表示條件,不易直接把圖翻譯成程序,斜線不易打印模塊與獨立性原則沒有給予應有的重視求提供對復雜系統設計過程的支持改進的Jackson圖Jackson方法1. 畫數據結構的Jackson圖2。 找輸入輸出數據結構的對應關系3. 以輸出數據結構為基礎，導出程序結構的Jackson圖有關系的數據單元 合畫一個處理框輸入數據結構中余下的數據單元 各畫一個輸出數據結構中余下的數據單元 各畫一個4。 列出所有操作、條件5。 偽碼表示程序JACKSON的偽碼表示程序（1）順序結構A seqB

33、 CDA end（2）選擇結構A select condition1BA or condition2CA or condition3DA end（3）重復結構A iter until（或while）conditionBA end第六章傳統軟件工程方法：實現與測試。編碼軟件測試基礎測試用例設計軟件測試步驟與策略調試軟件可靠性一、編碼語言：1、 語言的元計算模型等價 功能等價2、 描述問題的方便性有差異程序設計語言的特點及其對軟件的影響:機器求解問題的基本工具：思維方式、解題方式、人機通信的方式、理解程序的難以程度選擇程序設計語言的理想標準:模塊化機制、語言特點、開發工具、獨立編譯機制、標準化選擇

34、程序設計語言的實用標準：系統用戶的要求、工程規模、程序員的知識、軟件的應用領域程序設計風格:“好”程序的標準q源程序代碼的邏輯簡明清晰、易讀易懂遵循原則：程序內部的文檔、數據說明、語句構造盡量簡單而直接、輸入輸出規則、效率效率：效率主要指處理機時間和存儲器容量兩個方面n 關于效率的三條原則q 第一,效率是性能要求，應該在需求分析階段確定效率方面的要求;q 第二，效率是靠好設計來提高的；q 第三，程序的效率和程序的簡單度是一致的,不要犧牲程序的清晰性和可讀性來不必要地提高效率n 三個方面q 程序的運行時間q 存儲器效率q 輸入輸出效率二、軟件測試基礎測試目標： 為了發現程序中的錯誤而執行程序的過

35、程測試用例：一組用于測試的輸入數據和預期得出的正確輸出測試方案：測試用例和用例預定要檢驗的功能、測試環境的規劃、測試工具的選擇。測試計劃:要進行的測試的組織、資源、風險、原則和進度安排等進行規定和約束軟件測試方法分:靜態測試（人工檢查代碼，不在機器上運行)和動態測試（白盒與黑盒）.窮盡測試：（不可能，只能選少量”最有效”做到完備）:包含所有可能情況的測試黑盒測試 功能測試目的：q 功能是否正常使用？q 輸入 正確輸出?q 保持外部信息的完整性?q 時機：測試的后期，如:集成測試、確認測試白盒測試關注軟件內部邏輯結構( control structure）測試每條邏輯通路檢查斷點（ break

36、point） 狀態測試方案對程序邏輯的覆蓋程度決定測試的完全性程度時機：測試的早期,例如：單元測試成本高，通常對結構比較復雜的模塊進行白盒測試三、測試用例設計黑盒法依據對程序的需求和說明等價劃分法邊界值分析法錯誤推測法白盒法邏輯覆蓋控制結構測試用例是為某個特殊目標而編制的一組測試輸入、執行條件、執行步驟以及預期結果等等。黑盒測試技術a. 黑盒（功能）測試i. 等價類劃分ii. 邊界值分析iii. 錯誤推測白盒測試技術白盒測試技術是基于程序的內部實現結構和邏輯尋找軟件中的缺陷覆蓋準則可以作為測試停止或/和選取測試數據的標準軟件測試的步驟與策略第七章傳統軟件工程方法:維護。軟件維護的概念和內容軟件

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

38、上看來合理的改錯或修改不能完全滿足用戶的要求,就會引起用戶的不滿。n 由于維護時對軟件的改動,哪怕是很小的改動,在軟件中也會引入潛在的隱患或錯誤，使得整個軟件的質量降低, 特別是不可再現錯誤。n 在開發工作期間，由于工作需要必須把軟件工程師調去從事維護工作，就會對開發工作造成不良影響。 n 軟件維護會使生產率大幅度下降 維護中的問題n 閱讀和理解問題 n 人員問題n 文檔資料 n 軟件的修改 n 軟件維護相對于軟件系統開發工作來說則毫無吸引力二、軟件維護過程軟件維護過程定義:本質上是修改和壓縮了的軟件定義和開發過程。n 建立維護組織n 提出維護申請報告及評價n 維護實施n 保存維護記錄n 評價

39、維護活動三、可維護性軟件可維護性是指糾正軟件系統出現的錯誤和缺陷,以及為滿足新的要求進行修改、擴充或壓縮的容易程度可維護性的決定因素 可理解性 可測試性可修改性 可靠性可移植性 可使用性效率。提高可維護性的措施維護的副作用F 修改軟件后導致新錯誤的發生n 編碼的副作用n 數據的副作用 文檔資料的副作用完善的設計文檔資料可以減少數據的副作用。利用文檔資料對數據及其用途所作的詳細描述 ，提供了數據項、記錄、文件及其他結構與軟件模塊間相關的參照表，是維護期間對數據結構進行修改的主要依據。第七章 軟件管理軟件管理內容n 開發計劃與進度管理n 成本估算與控制n 人員管理、組織管理n 質量管理n 文檔管理

40、軟件管理原則n 軟件生存期n 按階段確認n 質量檢查n 自頂向下SP/OOPn 職責分明n 人員少而精n 不斷充實軟件管理特點n 知識密集，非實物性n 單品生產，開發過程不確定n 開發周期長n 內容復雜，正確性難保證n 勞動密集,自動化程度低n 軟件用法繁瑣，維護困難,費用高指定軟件開發計劃三要素:規模 人員 交付日期進度安排與控制n 軟件開發進度安排，實際上就是對軟件開發中各個階段所需要的工作量，結合項目的起始時間，體現在一張編制的進度表里（甘特圖). n 軟件開發的進度往往與人的因素有關，對人的依賴性很大。n 進度控制是對計劃執行情況的監督、調整和修改。成本管理與控制n 工時數成本管理n

41、開發設備的購置、使用管理人員管理、組織管理n 人員管理q 高技術、高知識，個人作用突出q 多層次 合理配備各類人員q 知識更新快q 流動性大 保持人員相對穩定,吸引優秀人才n 組織管理q 集中式 - 易決斷、易管理，難發揮多數人的積極性q 非集中式 - 發揮大家主觀能動性、難管理質量管理n 軟件生產q 分階段q 規范化q 合理分工n 度量軟件質量的標準文檔管理第八章-面向對象方法學引論.面向對象方法學概述面向對象的概念面向對象建模一、面向對象方法學概述OO和PO的本質區別是：對象是一元的還是過程是一元OOM四要素:1對象 2類 3繼承 4方法與消息二、面向對象的概念對象：對象是一個程序模塊，該

42、模塊由一組操作構成的集合對象是對問題域中某個東西的抽象，這種抽象反應了系統保存有關這個東西的信息或與它交互的能力。對象是一臺自動機對象特點n 數據為中心n 主動的n 數據封裝n 并行性n 模塊獨立性好繼承的優點n 共享程序代碼和數據結構n 減少了冗余信息n 修改方便q 擴充:調用基類方法并增加代碼q 改變:改寫同名方法q 新增：定義新方法n 軟件重用OOM的主要優點n 與人類習慣的思維方法一致CMn 面向過程設計,以算法為核心,送數據到函數n 數據與操作分離，不易理解 OOMq 以object 為核心,強調對現實概念的模擬而不強調算法q “面向對象方法學的基本原則,是按照人們習慣的思維方式建立

43、問題域的模型,開發出盡可能直觀、自然地表現求解方法的軟件系統"q 數據和操作封裝成統一體,送消息到對象n 穩定性好Cmq 結構依賴于功能,不穩定q 功能需求變，易引起軟件結構整體修改Oomq 軟件系統結構根據問題域模型建立q 以object模擬實體，實體相對穩定，故系統也相應穩定q 需求變化不會引起結構的整體變化，只需局部性修改n 可重用性好CMq 過程（函數）是重用層q 建立標準函數庫來重用軟構件q 標準函數缺乏“柔性”，難以適應不同場合的不同需要q 功能內聚的模塊不是自含和獨立的OOMq 類是重用層q object具有較強的自含性和獨立性q object和class提供了理想的模塊化機制和可重用的軟件成分q 繼承性為OOM提供了比CM更廣泛、更規范、更簡單的重用機制n 可維護性好CMq 開發出來的軟件難維護OOM