




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領
文檔簡介
1、軟件工程-原理、方法與應用【第 三版】重點第一章緒論1. 軟件:是能夠完成預定功能和性能的可執(zhí)行的計算機誠信度。包括使程序正常執(zhí)行所需的數(shù)據(jù),以及有關描述程 序操作和使用的文檔。即:軟件 =程序+文檔2. 軟件的特征:軟件的開發(fā)不同于硬件設計、不同于硬件制造、不同于硬件維修。3. 軟件工程方法學:把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合。三要素:方法、工具、過程4. 軟件工程學的范疇:軟件開發(fā)技術(shù)(軟件開發(fā)方法學、軟件工具、軟件工程環(huán)境)、軟件工程管理(軟件管理學、軟件經(jīng)濟學、度量學)。5. 軟件工程:是指導計算機軟件開發(fā)和維護的工程學科。它采用工程的概念、原理、技術(shù)和方法來開發(fā)與維
2、護軟件, 目的是為了實現(xiàn)按照預期的進度和經(jīng)費完成軟件生產(chǎn)計 戈同時提高軟件的生產(chǎn)率和可靠性。6. 軟件的發(fā)展:大體經(jīng)歷了 程序、軟件、軟件產(chǎn)品3個階段。7. 工具和方法是軟件開發(fā)技術(shù)的2大支柱。8.3種編程泛型:過程式編程泛型、面向?qū)ο缶幊谭盒?、?于構(gòu)件技術(shù)的編程泛型9. 面向?qū)ο蟪绦蛟O計中,數(shù)據(jù)和操作被封裝在一個對象中,對象之間則是通過消息相互聯(lián)系。10. 構(gòu)件:標準化/規(guī)格化的對象類。11. 3種編程泛型的差異:粒度由小到大依次是:過程式編 程范式、面向?qū)ο缶幊谭妒健⒒跇?gòu)件的編程泛型。12. 軟件工程的分化:1、傳統(tǒng)軟件工程2、面向?qū)ο筌浖?程3、基于構(gòu)件的軟件工程13. 消除軟件危
3、機的途徑:正確認識計算機軟件;充分 認識到軟件開發(fā)是一種組織良好、管理嚴密、各類人員 協(xié)同工作的工程項目;推廣使用在實踐中總結(jié)出來的開 發(fā)軟件的成功的技術(shù)和方法;開發(fā)和使用更好的軟件 工具。第二章軟件生存周期與軟件過程1. 軟件生存周期:計劃、開發(fā)、運行 3個時期。需求分析-軟件分析-軟件設計-編碼測試-軟件測試- 運行維護2. 需求分析(用戶視角):功能需求、性能需求、環(huán)境約束、外部接口描述。3. 軟件分析(開發(fā)人員視角):建立與需求模型一致的,與實現(xiàn)無關的軟件分析模型。4. 軟件設計:總體設計/概要設計、詳細設計(確定軟件的數(shù)據(jù)結(jié)構(gòu)和操作)。5. 軟件測試:單元測試、集成測試、系統(tǒng)測試。6
4、. 軟件開發(fā)方法可區(qū)分:形式化方法、非形式化方法。開發(fā)模型特點場合瀑布模型(歷史悠久、廣為人知,它的優(yōu)勢在于它是規(guī)范的、 文檔驅(qū)動的方法;這種模型的問題是,最終開發(fā)的軟件產(chǎn)品可能并不是客戶 真正需要的)線性模型,每個階段必須完成 固定文檔需求明確的中小型軟件開發(fā)快速原型模型(正是為了克服瀑布模型的缺點提出來的,他通過快速構(gòu)建起一個可以在計算機上運行的原型系統(tǒng),讓用戶使用原型并收集用戶反饋意見的方法,獲取用戶的真實需求)用戶介入早,通過迭代完善用戶需求,應用快速開發(fā)工具需求模糊的小型軟件開發(fā)增量模型(具有可在軟件開發(fā)的早期階使投資獲得明顯回報和 交易維護的優(yōu)點,但是,要求軟件具有開放的結(jié)構(gòu)是使用
5、這種模型固有的困 難。)每次迭代完成一個增量,可用 于OO開發(fā)容易分塊的大型軟件開發(fā)螺旋模型(適用于內(nèi)開發(fā)的大型軟件項目,但是只有在開發(fā)人員具有風險分 析和排除風險的經(jīng)驗及專門知識時,使用這種模型才會成功。)典型迭代模型,重視風險分析,可用于OO開發(fā)具有不確定性的大型軟件開發(fā)構(gòu)件集成模型(面向?qū)ο蠡跇?gòu)件庫,融合螺旋模型的特 征,支持軟件開發(fā),迭代方法,軟件復用思想)軟件開發(fā)與構(gòu)件開發(fā)平行進 行,主要用于OO開發(fā)領域工程, 件開發(fā),主行業(yè)的中型軟它要用于00開發(fā)轉(zhuǎn)換模型(是將形式化軟件開發(fā)和程序自動生成技術(shù)相結(jié)合的 一種軟件開發(fā)模型。)形式化的需求規(guī)格說明書,自 動的程序變換系統(tǒng)理想化的模型,
6、尚無成熟工具支持凈室模型(是一種形式化的增量開發(fā)模型,其基本思想是力求 在分析和設計階段就消除錯誤,確保正確,然后在無缺陷或潔凈的狀態(tài)下實 現(xiàn)軟件的制作。)形式化的增量開發(fā)模型,在潔凈狀態(tài)下實現(xiàn)軟件的制作開發(fā)團隊熟悉形式化方法,中小型軟件開發(fā)7. 形式化開發(fā)模型:轉(zhuǎn)換模型、凈室模型8. 軟件可行性研究:經(jīng)濟可行性、技術(shù)可行性、運行可行性、法律可行性。9. 可行性研究的步驟:對當前系統(tǒng)進行調(diào)查研究、導出新系統(tǒng)的解決方案、提出推薦方案、編寫可行性論證報告。10. 可行性論證報告的內(nèi)容:系統(tǒng)概述、可行性分析、結(jié)論 意見。11. 軟件風險分析包括:風險識別(項目風險、技術(shù)風險、 商業(yè)風險)、風險預測、
7、風險的駕馭和監(jiān)控。12. 軟件計劃的7種類型:項目實施計劃、質(zhì)量保證計劃、 軟件測試計劃、文檔編制計劃、用戶培訓計劃、綜合支 持計劃、軟件分發(fā)計劃。第三章結(jié)構(gòu)化分析與設計1. 瀑布模型的生命周期:需求定義與分析-總體設計-詳細設計-編碼-測試-維護2. 系統(tǒng)的開發(fā)流程(SA和SD流程):結(jié)構(gòu)化分析(工具:DFD PSPEC -分析模型(分層DFD 圖)+SRS結(jié)構(gòu)化設計(工具:SC圖(映射)-初始設計模型(初 始SC圖)初始設計模型(初始SC圖)(優(yōu)化)最終設計模型(最終SC圖)3. SA需求分析的兩項基本任務:建立系統(tǒng)分析模型、編寫SRS4. 分析模型組成:功能模型、數(shù)據(jù)模型、行為模型3種,
8、5. 抽象 和 分解 是結(jié)構(gòu)化分析的主要指導思想,細化的實質(zhì)是分解。分解 和 細化 是軟件設計的策略6. SD階段把分析模型中的DFD圖轉(zhuǎn)換為 最終SC圖。7. 傳統(tǒng)軟件的開發(fā)技術(shù):結(jié)構(gòu)化設計、模塊設計。8. 軟件設計:總體設計/概要設計(初始SC圖、最終SC圖)、詳細設計(用逐步細化的方法,完成模塊的說明)。9. 需求分析的步驟:需求獲取、需求提煉、需求描述、需求驗證。10. DFD圖不能表示程序的控制結(jié)構(gòu)(如選擇、循環(huán)結(jié)構(gòu))11. 加工規(guī)格說明通常用結(jié)構(gòu)化語言、判定表、判定樹作為描述工具12. 軟件中的數(shù)據(jù)分為3類:數(shù)據(jù)項(數(shù)據(jù)元素)、數(shù)據(jù)流(多個相關數(shù)據(jù)項)、數(shù)據(jù)文件和數(shù)據(jù)庫。13. 數(shù)
9、據(jù)字典的組成:數(shù)據(jù)項、數(shù)據(jù)流、數(shù)據(jù)存儲(文件或數(shù) 據(jù)庫)、加工(處理邏輯)、外部項(人、物或其它軟件系 統(tǒng))。14. SD模型是由SA模型映射而來的。SA模型的數(shù)據(jù)字典可轉(zhuǎn)換為待開發(fā)系統(tǒng)的數(shù)據(jù) 設計數(shù)據(jù)流圖可轉(zhuǎn)換為體系結(jié)構(gòu)設計(SC圖)與接口設計加工規(guī)格說明可轉(zhuǎn)換為模塊內(nèi)部的詳細過程設計15. SD模型的組成:從上到下依次是:過程設計、接口設計、體系結(jié)構(gòu)設計、數(shù)據(jù)設計16. 結(jié)構(gòu)化分析的基本步驟:自頂向下對系統(tǒng)進行功能分解,畫出 DFD圖;由后向前定義系 統(tǒng)的數(shù)據(jù)和加工;編制 DD和 PEPES寫出SRS17. 把不需要分解的加工成為基本加工。把逐步分解成為“自 頂向下,逐步細化”。18. D
10、FD的優(yōu)點:便于實現(xiàn),便于使用。19. 傳統(tǒng)的軟件設計可細分為:面向數(shù)據(jù)流設計(SD方法)、 面向數(shù)據(jù)結(jié)構(gòu)設計(Jackson方法)。20. 用數(shù)據(jù)流圖表示邏輯模型,在設計階段,按照數(shù)據(jù)流圖的不同類型(變換型、事務型)轉(zhuǎn)換為相應的軟件結(jié)構(gòu)21. 結(jié)構(gòu)化設計通常從DFD圖到SC圖的映射開始。22.面向數(shù)據(jù)流的設計方法:從圖到SC圖的映射的4個步變授和DFD爭帖"DFD變換甘析事務分析初始scDFD驟:1、復審DFD圖,必要時可再次進行修改或細化;2、鑒別DFD圖的結(jié)構(gòu)特征:事務?變換?;3、按照規(guī)則,把DFD圖為初始的SC圖;4、改進初始的SC圖23. 變換型結(jié)構(gòu):由輸入、變換中心和輸
11、出三部分組成 事務型結(jié)構(gòu):具有在多種事務中選擇執(zhí)行某類事物的能力。24. 變換映射的步驟:劃分DFD圖的邊界、建立初始SC圖的 框架、分解SC圖的各個分支。事務映射的步驟:在 DFD圖上確定邊界、畫出SC圖框架、分 解和細化接受分支和發(fā)送分支。25. 優(yōu)化結(jié)構(gòu)設計的指導規(guī)則:對模塊分割、合并和變動調(diào) 用關系的指導規(guī)則、保持高扇入/低扇出的原則、作用域 /控制域規(guī)則。26. 模塊設計(詳細設計)的主要任務是編寫軟件的模塊設 計說明書。目的是確定模塊采用的算法和塊內(nèi)數(shù)據(jù)結(jié)構(gòu)。27. 模塊設計的原則:清晰第一的設計風格、結(jié)構(gòu)化的控制 結(jié)構(gòu)、逐步細化的實現(xiàn)方法。28. 結(jié)構(gòu)化程序設計原理和逐步細化的實
12、現(xiàn)方法是完成模塊 設計的基礎。第四章面向?qū)ο蠛蚒ML1. 面向?qū)ο蟮幕咎卣鳎撼橄?、圭寸裝、集成、多態(tài)。2. 面向?qū)ο箝_發(fā)的優(yōu)點:提高軟件系統(tǒng)的可復用性、可擴展性、可維護性、面向?qū)ο蠓先祟惲晳T的思維方式。3. 元素之間的聯(lián)系有:關聯(lián)、泛化、依賴、實現(xiàn)、聚集、組合。4. UML的4個抽象層次:用戶模型、模型、元模型、元元模型。5. UML的2類圖:靜態(tài)圖(用例圖、類圖、對象圖、構(gòu)件圖、部署圖); 動態(tài)圖(狀態(tài)圖、時序圖、協(xié)作圖、活動圖)UML的5種視圖:用例視圖、邏輯視圖、進程視圖、構(gòu)件視圖、 部署視圖。6. UML的特點:統(tǒng)一標準、面向?qū)ο蟆⒈磉_能力強,可視化。7. UML模型作為測試階段的
13、依據(jù):單元測試使用類圖和類規(guī)格說明;集成測試使用構(gòu)件圖和協(xié)作 圖;系統(tǒng)測試使用用例圖來驗證系統(tǒng)行為。8. UML中用例圖由系統(tǒng)邊界、用例、參與者、關聯(lián)組成。用例之間存在的關系:擴展關系、包含關系。包與包之間的關系有:依賴、泛化。9. 根據(jù)類/對象之間的具體情況,可分為普通關聯(lián),遞歸關聯(lián)、多重關聯(lián)、有序關聯(lián)、限制關聯(lián)、或關聯(lián)、關聯(lián)類10. 消息(類里面的方法加參數(shù)):簡單消息、同步消息、異 步消息。狀態(tài)圖有:初態(tài)、終態(tài)、中間態(tài)。11. 時序圖中的消息可以是信號或操作調(diào)用。12. 時序圖著重體現(xiàn)交互的時間順序;協(xié)作圖著重體現(xiàn)交互 對象間的靜態(tài)鏈接。13. 時序圖和協(xié)作圖適合描述單個用例中幾個對象的
14、行為;活動圖適合表現(xiàn)跨越多用例或多線程的復雜行為。14. 構(gòu)件圖可以用來表現(xiàn)、編譯、鏈接、執(zhí)行時構(gòu)件間的依 賴關系。15. UML用圖表示語法,用元模型表示語義,米用模型來描 述系統(tǒng)的結(jié)構(gòu)(靜態(tài)特征)以及行為(動態(tài)特征)。第五章需求工程和需求分析1. 軟件需求的3個層次:業(yè)務需求、用戶需求、功能需求。軟件項目中40%60的問題源自軟件需求階段。2. 軟件需求的6個特性:功能性、可用性、可靠性、性能、可支持性、設計約束。3. 需求分析的步驟:需求獲取、需求建模、需求描述(編寫SRS、需求驗證。4. 需求分析的主要任務:建立需求模型。需求分析是迭代過程。常見模型有:用例圖、數(shù)據(jù)流圖、實體聯(lián)系圖、控
15、制流圖、狀 態(tài)轉(zhuǎn)換圖。5. 需求獲取的方法:1、建立聯(lián)合分析小組2、用戶訪談。6. 獲得用例的方法通過問問題:1、系統(tǒng)用戶是誰?系統(tǒng)維護時誰?從哪獲得信息?給誰?7. 需求建模方法:結(jié)構(gòu)化分析建模方法、面向?qū)ο蠓治鼋!?. 結(jié)構(gòu)化需求模型由3部分組成:功能模型(數(shù)據(jù)流圖、加工規(guī)格說明書)、數(shù)據(jù)模型(數(shù)據(jù)字典、ER圖)、行為模 型(狀態(tài)轉(zhuǎn)換圖、控制流圖、控制規(guī)格說明書)。9. 面向?qū)ο笮枨竽P停河美P停ㄓ美龍D、用例規(guī)約)、補充規(guī)約、術(shù)語表。10. 面向?qū)ο笮枨蠼5牟襟E:畫用例圖、寫用例規(guī)約、描 述補充規(guī)約、編寫術(shù)語表、調(diào)整優(yōu)化。11. 用例規(guī)約文檔的內(nèi)容:簡要說明、事件流、特殊需求、 前置
16、條件和后置條件。12. 用例規(guī)約的檢查:功能需求的完備性、模型是否易于理 解、是否存在不一致性、避免二義性。13. 軟件需求規(guī)格說明書SRS的內(nèi)容:引言、信息描述、功 能描述、行為描述、質(zhì)量保證、接口描述、其他描述。14. 需求管理的流程:需求確認、需求跟蹤、需求變更。需 求跟蹤有兩種方式,正向跟蹤與逆向跟蹤。需求變更的流程:變更申請、審批、更改、更新確認。第六章面向?qū)ο蠓治?. 建立面向?qū)ο蠓治瞿P筒襟E:1、建立類/對象層(抽象出類和對象)、2、建立屬性層(設計靜態(tài)屬性和關系)、3、 建立服務層(定義動態(tài)屬性和消息通信)、4、建立結(jié)構(gòu) 層(定義層次結(jié)構(gòu)關系)、5、建立主題層2. OOA方法的
17、共同特征:類和類層次的表示、建立對象-關系 模型、建立對象-行為模型。3. 面向?qū)ο箝_發(fā)的全過程:00A(分析)、00(設計)、OOP(編碼)、00(測試)。4. 用例模型是面向?qū)ο蠓治鲎畛S玫囊环N模型。5. 分析類的類型:邊界類、控制類、實體類。6. 每個參與者與用例之間確定一個邊界類,每個用例設置一個控制類,而實體類為現(xiàn)實生活中的對象,類(屬性與 方法)或用于保存和更新信息的有關對象。7. 邊界類包括:用戶界面類、系統(tǒng)接口類、設備接口類。如事務管理器、資源協(xié)調(diào)器、錯誤處理器都可為控制類。8. 控制類分離邊界類和實體類,可用來建立系統(tǒng)的動態(tài)行為模型。實體類用于保存和更新一些對象的有關信息。9
18、. 為分析類分配職責是00D勺重點。實體類具有持久性。10. 對象-關系模型的內(nèi)容:分析類的屬性、分析類的關聯(lián)、 分析類圖、分析類的合并。(用類圖來表示)11. 對象行為模型用狀態(tài)轉(zhuǎn)換圖、時序圖、協(xié)作圖、活動圖 來表示。12. 面向?qū)ο蠓治鰰r:1、確定分析類,2、靜態(tài)模型建立畫 類圖,3、動態(tài)模型建立畫時序圖和協(xié)作圖。13. 時序圖中的元素有:對象、對象生命線、消息。協(xié)作圖 中的元素有:對象、鏈接、消息流。14. 面向?qū)ο蠓治龅娜蝿帐牵簩⑿枨箅A段產(chǎn)生的需求模型轉(zhuǎn) 換為軟件分析模型。面向?qū)ο笤O計的任務是:將分析階段建立的分析模型轉(zhuǎn)換為軟件設計模型。第七章面向?qū)ο笤O計1. 軟件設計的基本概念:模塊
19、(擁有明確定義的輸入、輸出和特性的程序?qū)嶓w)與構(gòu)件、抽象與細化、信息隱藏、 軟件復用。2. 軟件設計的基礎:分析階段對目標系統(tǒng)的數(shù)據(jù)、功能、行為建模。3. 軟件設計的任務:把分析階段產(chǎn)生的分析模型轉(zhuǎn)換為軟件設計模型。4. 軟件設計包括:數(shù)據(jù)設計、體系結(jié)構(gòu)設計、接口設計、過程設計。5. 面向?qū)ο笤O計準則:模塊化;抽象;信息隱藏;弱耦合;強內(nèi)聚;可重用6. 分解和模塊獨立性是實現(xiàn)模塊設計的重要指導思想。7. 模塊的獨立性從2個方面度量:模塊本身的內(nèi)聚、模塊之間的耦合。8. 內(nèi)聚分類:低內(nèi)聚(偶然性內(nèi)聚、邏輯性內(nèi)聚、時間性內(nèi)聚)、中內(nèi)聚(過程性內(nèi)聚、通訊性內(nèi)聚)、高內(nèi)聚(順序性內(nèi)聚、功能性內(nèi)聚)。9
20、. 耦合分類:弱耦合(非直接耦合、數(shù)據(jù)耦合、特征耦合)中耦合(控制耦合)、較強耦合(外部耦合、公共耦合) 強耦合(內(nèi)容耦合)。10. 一個模塊,一個功能 是模塊化設計的一條準則。11. OO設計模型由系統(tǒng)架構(gòu)層、類和對象層、消息層、責任 層4個層次組成。12. 面向?qū)ο笤O計中,數(shù)據(jù)和過程被封裝為類/對象的屬性和 操作;接口被封裝為對象間的消息,而體系結(jié)構(gòu)的設計 則體現(xiàn)為系統(tǒng)的技術(shù)基礎設施和具有控制流程的對象間的協(xié)作。13. 傳統(tǒng)的軟件設計任務包括:概要設計和詳細設計14. 概要設計(總體設計):包括軟件的結(jié)構(gòu)和接口設計,并 編寫概要設計文檔。詳細設計,確定模塊內(nèi)部的算法和 數(shù)據(jù)結(jié)構(gòu),產(chǎn)生描述各
21、模塊程序過程的詳細文檔。每個 階段完成的文檔都必須經(jīng)過復審。15. 00D勺軟件設計任務可劃分為2個層次:系統(tǒng)架構(gòu)設計、 系統(tǒng)元素設計。16. 系統(tǒng)架構(gòu)設計的內(nèi)容:系統(tǒng)高層結(jié)構(gòu)設計、確定設計元 素、確定任務管理策略、實現(xiàn)分布式機制、設計數(shù)據(jù)存 儲方案、人機界面設計。系統(tǒng)元素設計的內(nèi)容:子系統(tǒng) 設計、分包設計、類/對象設計。17. 常用的架構(gòu)模式有:層次架構(gòu)、模型-視圖-控制(MVC 架構(gòu)、管道-過濾器架構(gòu)、黑板架構(gòu)。18. 面向并行需求,任務管理策略主要 3種解決方案:多處 理機方案、操作系統(tǒng)方案、應用程序方案。19. 分包的原則:將邊界類打包、將功能相關的類打包。高 內(nèi)聚-低耦合的原則,包之
22、間的耦合表現(xiàn)為依賴關系。20. a向b發(fā)送消息的必要條件是a能夠引用b,a可以通過 4種方式引用b,對應于從a到b的4種連接可見度:1、全局:b是可以在全局范圍內(nèi)直接引用的對象。2、參數(shù):b作為a的某一項操作的參數(shù)或返回值。3、局部:b在a的某一操作中充當臨時變量。4 、域:b作為a的數(shù)據(jù)成員。21. 操作的可見性:公有:除了累本身以外,操作對其他模 型元素也是可見的;也可以用“ +”表示;保護:操作只對類本身、它的子類也是可見的; 也可以用“ #”表示。私有:操作只對類本身是可見的,也可以用“一”表示。第八章編碼和測試1. 編碼的風格:1、追求“聰明”和“技巧”-提倡“簡明”和“直接” 2、
23、使用標準的控制結(jié)構(gòu) 3、清晰的前 提下求取效率2. 編碼的目的:設計模型(不可執(zhí)行的)->(編碼)源程序-可執(zhí)行代碼3. 選擇編碼語言的標準:1、應用領域2、算法與計算復雜性3、數(shù)據(jù)結(jié)構(gòu)的復雜性4、效率的考慮4. 測試和糾錯:測試(testing )的目的與任務:目的:發(fā)現(xiàn)程序的錯誤;任 務:通過執(zhí)行程序,暴露潛在的錯誤。糾錯(debugging )的目的與任務:目的:定位和糾正錯誤; 任務:消除軟件故障,保證程序的可靠運行。5. 測試的特性:挑剔型、復雜性、不徹底性、經(jīng)濟型。6. 測試分類:靜態(tài)分析(靜態(tài)分析器分析、代碼評審(代碼會審、走查、辦公桌檢查);動態(tài)測試(黑盒測試(功能測試)
24、、白盒測試(結(jié)構(gòu)測試)c7. 黑盒測試分類(根據(jù)被測試程序功能來進行測試):等價類法、邊界值法、錯誤猜測法。8. 白盒測試分類(以程序結(jié)構(gòu)為依據(jù)的測試方法):路經(jīng)測試(點覆蓋、邊覆蓋、路徑覆蓋)、邏輯覆蓋測試(語句 覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合發(fā)硯錯誤的能力語句覆蓋每條語匂至少執(zhí)行一次判走環(huán)蓋每判矩的海個分支至少執(zhí)存次遙件頊蓋每一判宦中的毎個聚件,分別按*直片、 欄假歩至少各執(zhí)行一次判定漆件 覆蓋同時満足判定覆蓋和條件覆蓋的更求條件組合求出判走中所有條件的各種可能組合信. 每一可能的養(yǎng)呷組合至少執(zhí)行一次第九章軟件維護毗;iU血1. 決定軟件可維護性的因素修改數(shù)據(jù)的副作2.
25、 軟件副作用的類型:修改編碼的副作用、 用、修改文檔的副作用。3什么是再工程:將新技術(shù)和新工具應用于老的軟件的一種 較“徹底”的預防性維護。4. 軟件配置項包括:程序(源代碼和可執(zhí)行程序),文檔,數(shù)據(jù)5. 基線(Baseline) 是軟件文檔或源碼(或其它產(chǎn)出物)的一個穩(wěn)定版本,它是進一步開發(fā)的基礎。6. 維護的代價i.有形代價:ii.無形代價:占用資源以致延誤開發(fā);修改不及時引起用戶不滿;維 護引入新錯誤,降低了軟件質(zhì)量;等等。維護工作量的經(jīng)驗模型:M = P + KeA(c-d)其中:M =維護用的總工作量;P =生產(chǎn)性活動(如. 分析,評價,修改設計,編碼,測試等);K = 經(jīng) 驗系數(shù);
26、c=復雜度(非結(jié)構(gòu)化設計和缺少文檔會增加復 雜度)d = 維護人員對軟件的熟悉程度.第十章軟件復用1.軟件復用的定義:(SR)定義為利用工程知識或方法,由一 已存在的系統(tǒng),來建造一新系統(tǒng)。目的:這種技術(shù),可 改進軟件產(chǎn)品質(zhì)量和生產(chǎn)率。還有軟件檢查、軟件計量、 軟件可靠性、軟件可維修性、軟件工具評估和選擇等。2. 軟件復用的目的是能更快、更好、成本更低地生產(chǎn)軟件制品。3. 按照可復用的粒度,軟件制品從小到大分為以下幾類:源代碼復用(高級語言編寫的源代碼)、軟件體系結(jié)構(gòu)復用 (已有軟件的體系結(jié)構(gòu))、應用程序生成器(對整個軟件 體系結(jié)構(gòu)、相應的子系統(tǒng)、特定的數(shù)據(jù)結(jié)構(gòu)和算法)、領 域特定的軟件體系結(jié)構(gòu)
27、的復用(特定領域中存在的公共 體系結(jié)構(gòu)及其構(gòu)件)。4. 領域:指的是一組具有相似或相近軟件需求的應用系統(tǒng)所覆蓋的功能區(qū)域。領域工程:通過領域分析(domain an alysis) 找出最優(yōu)復用, 對它們進行設計和構(gòu)造,形成為可復用構(gòu)件,進而建立大 規(guī)模的軟件構(gòu)件倉庫的過程。5. 橫向復用:是指復用不同應用領域中的軟件元素??v向復用:是指在一類具有較多公共性的應用領域之間進行軟 件構(gòu)件進行復用。6. 領域分析:領域分析是在特定應用領域?qū)ふ易顑?yōu)復用,以公共對象、類、子集合和框架等形式進行標識、分析和 規(guī)約。目標:是獲得領域分析模型。7. 構(gòu)件應具有的特征:通用性、可變性、易組裝性;基于面向?qū)ο蠹?/p>
28、術(shù)的復用通用構(gòu)件8. 領域構(gòu)件的設計框架:標準數(shù)據(jù):標識標準的全局數(shù)據(jù)結(jié)構(gòu);標準接口協(xié)議:三個層次(構(gòu)件內(nèi)、夕卜、人機接口); 程序模板:成形的結(jié)構(gòu)模型作為新程序的體系結(jié)構(gòu)設計 的模板9. 幾種流行的構(gòu)件技術(shù):組件對象模型技術(shù)(COM)、公共對象請求代理體系結(jié)構(gòu)(CORB)開放式文檔接口。10. 建立可復用構(gòu)件庫目前最常用的有三種分類模式 :枚舉 分類、呈面分類(呈面=8)、屬性-值分類。11. 應用系統(tǒng)工程(ASE:定義:在基于構(gòu)件的軟件開發(fā)中, 通過復用構(gòu)件系統(tǒng)開發(fā)某個特定應用系統(tǒng)的構(gòu)件工程。12. ASE過程的基本步驟:獲取需求(建立用例模型)、分析(用用例模型輸入來組裝和特化分析構(gòu)件)
29、、設計應用系 統(tǒng)(用分析模型輸入來組裝和特化設計構(gòu)件)、實現(xiàn)應用 系統(tǒng)(用設計模型輸入來組裝和特化實現(xiàn)構(gòu)件)、測試應 用系統(tǒng)(組裝和特化測試構(gòu)件,測試應用系統(tǒng))、應用系 統(tǒng)打包。13. OO方法對軟件復用的支持: OOA模型、OOA與OO的分 工、對象的表示、一般-特殊結(jié)構(gòu)、整體-部分結(jié)構(gòu)、 實例連接、類描述模板、用例。14. 復用技術(shù)對OC方法的支持:類庫、構(gòu)件庫、構(gòu)架庫、工具、00A過程。題目1多模塊程序的測試有哪些層次?各層測試主要解決 什么問題?解答:多模 塊測 試的 層次所 處 時 段解決的問題涉及測試方 法成果單元 測試/ 模塊 測試編 碼 階 段1. 對模塊代碼進行編譯,發(fā)現(xiàn)并糾
30、正其語法錯誤;2. 進行靜態(tài)分析,驗證模塊結(jié)構(gòu)及其內(nèi) 部調(diào)用序列是否正確;3. 確定模塊的測試策略,并據(jù)此設計一 組測試用例和必要的測試軟件;4. 用選定的測試用例對模塊進行測試, 直至滿足測試終止標準為止;5. 注重執(zhí)行路徑、岀錯處理路徑、局部 數(shù)據(jù)結(jié)構(gòu)、模塊的對外接口的測試6. 編制單元測試報告。黑盒測試程序夕卜 部測試、功能 性測試測試報告白盒測試程序內(nèi) 部測試、覆蓋 測試集成測試集 成 測 試 階1. 制訂集成測試實施策 略2. 確定集成測試的實施 步驟,設計測試用例3. 逐地添加模塊,進行模塊(子系統(tǒng) 或小系統(tǒng))集 成測試;訓練 驅(qū)動與樁的 設計、組合及已組 裝軟 件段測試集成測試。
31、高確集1.進步驗證軟件的有已確級認成效性,即驗證軟件的功認軟測 試測試測 試 階 段能和性能是否與用戶的要求致件系驗1.測試是否與硬件協(xié)調(diào)系統(tǒng)的性能可運統(tǒng)收運行檢驗和軟件行的測試階 段2. 測試是否和原來就有 的其它軟件協(xié)調(diào)運行3. 測試是否完成SRS對 它的要求系統(tǒng)實時運 行狀況的測試系統(tǒng)軟件測試表7.1“電話號碼”的等價分類輸入數(shù)據(jù)地區(qū)碼1有效等價類空2、3位數(shù)字無效等價類3、非空,但有非數(shù)字字符4、非空,位數(shù)小于3位數(shù)字5、非空,位數(shù)多于3位數(shù)字電話號碼前三位6、非000'111'的 3 非位數(shù)7、空&非三空,但有非字數(shù)字:9、非于310、于3字符三空,位數(shù)小位數(shù)
32、字非空,位數(shù)多位數(shù)字電話號碼后四位11、任意4位數(shù)字12、13、數(shù)字:14、于415、于4空非空,但有非 字符非空,位數(shù)小 位數(shù)字非空,位數(shù)多位數(shù)字表7.2有效等價類的測試用例測試數(shù)據(jù)期望結(jié)果測試范圍地區(qū)碼號碼前三位號碼后 四位NULL1234567輸入有效1、 6、 110102345678輸入有效2、 6、 1131 /41表7.3無效等價類的測試用例測試數(shù)據(jù)期望結(jié)果測試范圍地區(qū)碼號碼前三位號碼后四位#1*1234567地區(qū)碼輸入無效3、 6、 11012345678地區(qū)碼輸入無效4、 6、 1101232588888地區(qū)碼輸入無效5、 6、 11NULLNULL8888號碼前三位 輸入無
33、效1、 7、 11010#1*6666號碼前三位 輸入無效1、& 11020456688號碼前三位 輸入無效1、 9、 11NULL7898866號碼前三位 輸入無效1、 10、 11NULL666NULL號碼后四位 輸入無效2、 6、 12010888*02#號碼后四位 輸入無效2、6、1302068823號碼后四位2、 6、 14輸入無效NULL86645678號碼后四位 輸入無效2、6、15閱讀下列程序:PROCEDURE SAMPAL (A, B: REAL VARX: REAL);BEGINIF (A>3) AND (B=2)THEN X:=X/AIF (A=6) OR
34、 (X>4)THEN X:=X+1END;為上述程序設計測試用例(參考教材相關例題)。 實驗要求:形成相應的實驗報告。包括:1、畫出程序流程圖,程序圖2、實現(xiàn)語句覆蓋用例設計3、實現(xiàn)判定覆蓋用例設計4、實現(xiàn)條件覆蓋用例設計5、實現(xiàn)判定/條件覆蓋用例設計6、實現(xiàn)條件組合覆蓋用例設計7、實現(xiàn)路徑覆蓋用例設計(完全覆蓋)第一部分:程序流程圖、程序圖F-T-.(A>3) AND (B=2)-Cb1開始aF_(A=6) OR (X>4) f'JdTeX=X+1結(jié)束設本例中的兩個判斷IF (A>3) AND(B=2)記為P1,IF (A=6) OR (X>4)記為 P
35、2。第二部分:語句覆蓋用例設計使程序中每個語句至少執(zhí)行-次。測試用例P1P2執(zhí)行路徑ABX6236TTa-c-e第三部分:判定覆蓋用例設計一一使每個判定的真假分支都至少執(zhí)行一次測試用例P1P2執(zhí)行路徑ABX8232TFa-c-d6032FTa-b-e第四部分:條件覆蓋用例設計一一使每個判定的每個條件的 可能取值至少執(zhí)行一次。第一判定表達式:設條件A>3取真記為T1假-T1條件B=2取真記為T2假-T2第二判定表達式:設條件A=6取真記為T3假-T3條件X>4取真記為T4假-T4測試用例第判定表 達式第二判定表達式執(zhí)行路 徑ABXA>3B=2A=6X>43236-T1T2
36、-T3T4a-b-e6024T1-T2T3-T4a-b-e未覆蓋c、d分支,不滿足判定覆蓋的要求。條件覆蓋不一定包含判定覆蓋,判定覆蓋也不一定包含條件覆第五部分:判定/條件覆蓋用例設計一一選取足夠多的測試用 例,使判斷中的每個條件的所有可能取值至少執(zhí)行一次, 同時每個判斷本身的所有可能判斷結(jié)果至少執(zhí)行一次。測試用例第判定表 達式第二判定表達式執(zhí)行路;徑ABXA>3B=2A=6X>46236T1T2T3T4a-c-e3236-T1T2-T3T4a-b-e6024T1-T2T3-T4a-b-e6024-T1-T2-T3-T4a-b-d能同時滿足判定、條件兩種覆蓋標準。第六部分:條件組合
37、覆蓋用例設計一一所有可能的條件取值組合至少執(zhí)行一次。A>3, B=2; A>3 B 半 2; A> 3, B=2; A> 3,2A=6, X>4; A=6, X >4 ; Am 6, X>4; Am 6, X> 4測試用例第判定表第二判定表執(zhí)行路徑達式達式aBXA>3B=2A=6X>46236T1T2T3T4a-c-e3236-T1T2-T3T4a-b-e6024T1-T2T3-T4a-b-e6024-T1-T2-T3-T4a-b-d第七部分:實現(xiàn)路徑覆蓋用例設計一一覆蓋每一個可能的路徑測1試用例第判定表 達式第二判定表達式執(zhí)行路徑a
38、BXA>3B=2A=6X>46236T1T2T3T4a-c-e4216T1T2-T3-T4a-c-d3024-T1-T2-T3T4a-b-e6024-T1-T2-T3-T4a-b-d第一早1、什么是軟件危機?為什么會產(chǎn)生軟件危機?答:軟件危機是指在計算機軟件的開發(fā)和維護過程中遇到的一系 列嚴重問題,如軟件費用、軟件可靠性、軟件維護、軟件生 產(chǎn)、軟件重用等。(1).軟件維護費用急劇上升,直接威脅計29 /41算機應用的擴大。(2).軟件生產(chǎn)技術(shù)進步緩慢2、何謂面向?qū)ο筌浖こ蹋亢喪鏊c傳統(tǒng)軟件工程的差別和聯(lián)系?傳統(tǒng)方法學:采用結(jié)構(gòu)化技術(shù);軟件生命周期的全過程依次劃分為若干階段;自頂向
39、下順序完成;八1什么是軟件生存周期?把生存周期劃分為階段的目的是什価千AT怖屁.個階段米用科學的管理技術(shù)和良好的技術(shù) 和對數(shù)據(jù)的操作結(jié) 消理解互相聯(lián)化;么?答:軟件生存周期是指一個軟件從提出需求開始直到該軟件報 廢為止的整個時期。需求分析、軟件分析、軟件設計、編 碼、軟件測試、運行維護等活動,可以將這些活動以適當 方式分配到不同階段去完成。;把整個生存周期劃分為較 小的階段,給每個階段賦予確定而有限的任務,就能夠化 簡每一步的工作內(nèi)容,使因為軟件規(guī)模而增長而大大增加 了軟件復雜性變得交易控制和管理。2傳統(tǒng)的瀑布模型把生存周期分為哪些階段?瀑布模型軟件 開發(fā)有哪些特點?答:瀑布模型在編碼以前安排
40、了分析階段和設計階段;階段間 具有順序性和依賴性。3 什么是快速原型法?其快速表現(xiàn)在哪里?答:首先建立一個能夠反映用戶主要需求的原型,讓用戶實際 看一看未來系統(tǒng)的概貌,以便判斷哪些功能是符合需要 的,哪些方面還需要改進。然后將原型改進,最終建立完 全符合用戶要求的新系統(tǒng)。它的快速表現(xiàn)在能夠縮短開發(fā) 周期的語言和工具,能在短時間內(nèi)提供出成品,但不包括 成品中的細節(jié),然后讓客戶進行對比。6比較增量模型和螺旋模型的特點,有什么不同和相似的地 方?答:增量模型是瀑布模型的順序特征與快速原型法的迭代特征 相結(jié)合的產(chǎn)物。螺旋模型是一種迭代模型,每迭代一次, 螺旋線就前進一周。增量模型每個增量具有高內(nèi)聚低耦
41、 合,高度的獨立性。而螺旋模型它在結(jié)合瀑布模型與快速 原型的基礎上還增加了風險分析。8哪些開發(fā)模型適用于面向?qū)ο蟮能浖_發(fā)? 答:構(gòu)件集成模型、轉(zhuǎn)換模型、凈室模型。第三章問題1 .需求分析的任務是什么?怎樣理解分析階段的任務是決定 “做什么”,而不是“怎么做”?答:需求分析主要有兩個任務:第一是通過對問題及其環(huán)境的 理解、分析和綜合建立分析模型;第二是在完全弄清用戶 對軟件系統(tǒng)的確切要求的基礎上,用"軟件需求規(guī)格說明 書”把用戶的需求表達出來。需求分析的任務就是為了明 確要開發(fā)的是一個什么樣的系統(tǒng),而不是去怎么去實現(xiàn)這個系統(tǒng)2 需求分析要經(jīng)過哪些步驟? 答:需求獲取、需求提煉、需求描
42、述、需求驗證。3. 有哪兩種主要的分析模型,它們有什么聯(lián)系?答:面向?qū)ο蠓治瞿P?、結(jié)構(gòu)化分析模型。前者是采用面向?qū)?象的思想進行軟件需求分析的建模過程,而后者模型的核 心是DD,它是設計各種數(shù)據(jù)對象的總和。他們的模型分別 起到了描述數(shù)據(jù)模型,功能模型與行為模型的作用。5什么是面向?qū)ο蠓治觯科渲饕枷胧鞘裁???OOA面向?qū)ο蟮姆治鍪遣捎妹嫦驅(qū)ο蟮乃枷脒M行軟件需求 分析建模的過程主要思想是采用面向?qū)ο蟮乃枷搿?.為什么DFD要分層?畫分層DFD要遵循哪些原則?答:大型復雜的軟件系統(tǒng),其 DFD可能含有數(shù)百乃至數(shù)千個加 工,不能設想一次就將它們?nèi)慨孆R。正確的做法是:從 系統(tǒng)的基本模型(把整個系統(tǒng)
43、看成一個加工)開始,逐層 地對系統(tǒng)進行分解。原則:由頂向下,逐步細化。第四章問題1、面向?qū)ο笥心男┗咎卣鳎?封裝,繼承,抽象,多態(tài)2、uml中提供了哪9種圖?試訴每種圖所描述的內(nèi)容1、用例圖描述角色以及角色與用例之間的連接關系。說明的是 誰要使用系統(tǒng),以及他們使用該系統(tǒng)可以做些什么。一個用例圖包含了多個模型元素,如系統(tǒng)、參與者和用例,并 且顯示了這些元素之間的各種關系,如泛化、關聯(lián)和依賴。2、類圖類圖是描述系統(tǒng)中的類,以及各個類之間的關系的靜 態(tài)視圖。能夠讓我們在正確編寫代碼以前對系統(tǒng)有一個全 面的認識。類圖是一種模型類型,確切的說,是一種靜態(tài) 模型類型。3、對象圖與類圖極為相似,它是類圖的
44、實例,對象圖顯示類的 多個對象實例,而不是實際的類。它描述的不是類之間的 關系,而是對象之間的關系。4、活動圖描述用例要求所要進行的活動,以及活動間的約束關 系,有利于識別并行活動。能夠演示出系統(tǒng)中哪些地方存 在功能,以及這些功能和系統(tǒng)中其他組件的功能如何共同 滿足前面使用用例圖建模的商務需求。5、狀態(tài)圖描述類的對象所有可能的狀態(tài),以及事件發(fā)生時狀態(tài) 的轉(zhuǎn)移條件??梢圆东@對象、子系統(tǒng)和系統(tǒng)的生命周期。 他們可以告知一個對象可以擁有的狀態(tài),并且事件(如消 息的接收、時間的流逝、錯誤、條件變?yōu)檎娴?)會怎么隨 著時間的推移來影響這些狀態(tài)。一個狀態(tài)圖應該連接到所 有具有清晰的可標識狀態(tài)和復雜行為的類
45、;該圖可以確定 類的行為,以及該行為如何根據(jù)當前的狀態(tài)變化,也可以 展示哪些事件將會改變類的對象的狀態(tài)。狀態(tài)圖是對類圖 的補充。6、序列圖(順序圖)序列圖是用來顯示你的參與者如何以一系列順序的步 驟與系統(tǒng)的對象交互的模型。順序圖可以用來展示對象之 間是如何進行交互的。順序圖將顯示的重點放在消息序列 上,即強調(diào)消息是如何在對象之間被發(fā)送和接收的。7、協(xié)作圖和序列圖相似,顯示對象間的動態(tài)合作關系??梢钥?成是類圖和順序圖的交集,協(xié)作圖建模對象或者角色,以 及它們彼此之間是如何通信的。如果強調(diào)時間和順序,則 使用序列圖;如果強調(diào)上下級關系,則選擇協(xié)作圖;這兩 種圖合稱為交互圖。8構(gòu)件圖(組件圖)描述
46、代碼構(gòu)件的物理結(jié)構(gòu)以及各種構(gòu)建之間的依賴關 系。用來建模軟件的組件及其相互之間的關系,這些圖由 構(gòu)件標記符和構(gòu)件之間的關系構(gòu)成。在組件圖中,構(gòu)件時 軟件單個組成部分,它可以是一個文件,產(chǎn)品、可執(zhí)行文 件和腳本等。9、部署圖(配置圖)是用來建模系統(tǒng)的物理部署。例如計算機和設備,以 及它們之間是如何連接的。部署圖的使用者是開發(fā)人員、 系統(tǒng)集成人員和測試人員。3、用uml所提供的圖形符號建立工資管理系統(tǒng)的靜態(tài)模型第五章問題1、軟件需求的任務是什么?要經(jīng)過哪些步驟?2、有哪兩種主要的需求模型?它們各由哪些部分組成 ?1 .結(jié)構(gòu)化需求模型該模型主要由3部分組成:即包括數(shù)據(jù)流圖和加工規(guī)格說明書 的功能模型
47、;主要由數(shù)據(jù)字典和 E-R圖組成的數(shù)據(jù)模型; 由狀態(tài)轉(zhuǎn)換圖,控制圖和控制規(guī)格說明書等組成的行為模 型。2. 面向?qū)ο笮枨竽P陀扇糠纸M成:用例模型,補充規(guī)約和術(shù)語表。其中用例模型 包括用例圖跟用例規(guī)約。3、建立用例模型時,如何確定參與者和用例?參與者泛指所有存在于系統(tǒng)外部并與系統(tǒng)進行交互的人,硬件或其他系統(tǒng)。通俗地講,參與者主要是待開發(fā)系統(tǒng)的使用 者,尋找參與者可從以下問題入手:a. 系統(tǒng)開發(fā)完成后,有那些人會使用這個系統(tǒng)?b. 系統(tǒng)需要從那些人或其他系統(tǒng)中獲取數(shù)據(jù)?c. 系統(tǒng)會為納西爾或者其他系統(tǒng)提供數(shù)據(jù)?d. 系統(tǒng)會與哪些其他系統(tǒng)相關聯(lián)?e. 系統(tǒng)是由誰來維護和管理?第六章問題1、軟件分析的目標是什么?包含哪些任務 ?2、軟件模型包含哪些內(nèi)容?它們之間有什么聯(lián)系?3、用哪種uml圖可以表示對象間的交互?第七章問題1、面向?qū)ο笤O計的任務是什么?設計階段的主要任務是數(shù)據(jù)設計,體系結(jié)構(gòu)設計,接口設計和 過程設計2、什么是模塊獨立性?可用什么來度量?答:模塊獨立性指每個模塊只完成系統(tǒng)要求的獨立的子功能 并且與其他模塊的聯(lián)系最少且接口簡單。模塊獨立的概念 是模塊化、抽象、信息隱蔽和局部化概念的直接結(jié)果。獨立性可以從兩個方面來度量: 模塊本身的內(nèi)聚性(Cohesion) 和模塊之間
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 上海徐匯金杯租車合同范本
- 監(jiān)控弱電維護合同范本
- 醫(yī)院電動車租售合同范本
- 單位之間借支合同范本
- 2003勞務合同范本
- 出售廢舊方木模板合同范本
- 二手工具買賣合同范本
- 勞務waibao合同范本
- 公司勞動用工合同范本簡版
- 前期住宅物業(yè)合同范本
- 川教版六年級《生命.生態(tài).安全》下冊第1課《我們的閑暇時光》課件
- 2024年建筑業(yè)10項新技術(shù)
- 重大風險管控方案及措施客運站
- 新編大學英語跨文化交際教程 課件 Unit 1-A Chinese Character
- 方案偏離處理措施
- 顱腦損傷的護理診斷及護理措施
- 純電動乘用車 技術(shù)條件
- 德力西質(zhì)量獎自評報告領導樣本
- IT總監(jiān)年終述職報告
- 環(huán)境衛(wèi)生整治推進行動實施方案
- 經(jīng)顱磁刺激技術(shù)操作指南
評論
0/150
提交評論