軟件工程答案整理

1、填空1 .軟件測試的目的是盡可能多地發(fā)現(xiàn)軟件中存在的2.測試階段的基本任務(wù)是根據(jù)軟件開發(fā)各階段的_錯(cuò)誤_，將_測試結(jié)果_作為糾錯(cuò)的依據(jù)。和程序的，精心設(shè)計(jì)一組，利用這些實(shí)例執(zhí)3.4.軟件測試方法一般分為兩大類:方法和方法。5.動態(tài)測試通過6.靜態(tài)測試采用的設(shè)計(jì)方法不同, 和的手段對程序進(jìn)行檢測。發(fā)現(xiàn)錯(cuò)誤。根據(jù)動態(tài)測試又分為與 兩類。7.8.的檢驗(yàn)，而軟件審查除了審查 計(jì)算機(jī)輔助靜態(tài)分析利用工具對測試程序進(jìn)行人工審查程序偏重于還要對各階段進(jìn)行檢驗(yàn)。分析。9.黑盒法只在軟件的要求。處進(jìn)行測試，依據(jù) _說明書，檢查程序是否滿足10.白盒法必須考慮程序的 和，以檢查的細(xì)節(jié)為基礎(chǔ)，對程序中盡可能多的邏輯

2、路徑進(jìn)行測試，被測對象是，以程序的為基礎(chǔ)設(shè)計(jì)測試用例。11.白盒測試是12邏輯覆蓋是對程序內(nèi)部有_存在的邏輯結(jié)構(gòu)設(shè)計(jì)測試用例，根據(jù)程序內(nèi)部的邏輯覆蓋程度又可分 和 6 種覆蓋技術(shù)。13實(shí)際的邏輯覆蓋測試中，一般以 測試標(biāo)準(zhǔn)。覆蓋為主設(shè)計(jì)測試用例，然后再補(bǔ)充部分用例，以達(dá)到覆蓋14.循環(huán)覆蓋是對程序內(nèi)部有15基本路徑測試是在程序_存在的邏輯結(jié)構(gòu)設(shè)計(jì)測試用例，它通過限制 _ 基礎(chǔ)上，通過分析控制構(gòu)造的復(fù)雜性，導(dǎo)出來測試。集合，從而設(shè)計(jì)測行_，找出軟件中潛在的各種和_。測試用例由和預(yù)期的兩部分組成。試用例。16 .黑盒測試是 和 。測試,用黑盒技術(shù)設(shè)計(jì)測試用例有 4種方法:17等價(jià)類劃分從程序的說明

3、，找出一個(gè)輸入條件（通常是），然后將每個(gè)輸入條件劃分成兩個(gè)或多個(gè).情況作為重點(diǎn)目標(biāo)，選取正好等于、剛剛大于或剛剛小于 如果輸入或輸出域是一個(gè)有序集合，則應(yīng)選取集合的19在測試程序時(shí)，根據(jù)經(jīng)驗(yàn)或直覺推測程序中可能存在的各種錯(cuò)誤，稱為20.因果圖的基本原理是通過畫圖，把用自然語言描述的轉(zhuǎn)換為18.邊界值分析是將測試的測試數(shù)據(jù)。元素和元素作為測試用例。，最后為每一列設(shè)計(jì)一個(gè)測試用例。21測試的綜合策略是在測試中，聯(lián)合使用各種方法。通常先用法設(shè)計(jì)基本的測試用例，再用法補(bǔ)充一些必要的測試用例。22 軟件測試過程中需要 3類信息:24.23 軟件測試一般經(jīng)過 4個(gè)測試：指對源程序中每一個(gè)程序單元進(jìn)行測試，

4、檢查各個(gè)模塊是否正確實(shí)現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法中的錯(cuò)誤，它涉及 和的文檔。25單元測試主要測試的5個(gè)基本特征：26.在單元測試中，需要為被測模塊設(shè)計(jì) 用來代替被測模塊所調(diào)用的模塊。模塊和模塊。用來模擬被測模塊的上級調(diào)用模塊,27.集成測試指在測試基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成一個(gè)完整的系統(tǒng)進(jìn)行的測試。也稱測試或測試。28. 集成測試的方法有兩種：29. 漸增式測試有兩種不同的組裝模塊的方法：30. 自頂向下漸增式測試不需要編寫 模塊，只需要編寫模塊，其步驟是從模塊開始，沿著被測程序的的控制路徑逐步向下測試，它有兩種組合策略:31.自底向上漸增式測試不需要編寫模塊。32.確

5、認(rèn)測試指檢查軟件的33.確認(rèn)測試在模擬環(huán)境下運(yùn)用模塊，只需要編寫與是否與_說明書中確定的指標(biāo)相符合，又稱測試方法，由和參加的測試。測試。34. 確認(rèn)測試開始前需要制定 計(jì)劃，結(jié)束后要寫出35. 軟件配置審查的任務(wù)是檢查軟件的所有文檔資料的報(bào)告。其測試用例要選用 和 。的數(shù)據(jù)。36.調(diào)試也稱，是在成功的測試之后才開始進(jìn)行，其目的是確定錯(cuò)誤的，并改正錯(cuò)誤。37.調(diào)試技術(shù)包括出發(fā)，而歸納法調(diào)試是從39.被測試程序不在機(jī)器上運(yùn)行，而是采用人工檢測和計(jì)算機(jī)輔助分析檢測的手段稱為 測試。38.回溯法調(diào)試是從入手。40.用等價(jià)類劃分法設(shè)計(jì)一個(gè)測試用例時(shí)，使其覆蓋41用等價(jià)類劃分法設(shè)計(jì)一個(gè)測試用例時(shí)，使其覆蓋

6、42在單元測試時(shí)，需要為被測模塊設(shè)計(jì)尚未被覆蓋的合理等價(jià)類。不合理等價(jià)類。43.在集成測試時(shí)有兩種測試方法，它們是 44軟件測試是為了而執(zhí)行程序的過程。45. 運(yùn)行被測程序的方法稱為46. 動態(tài)測試中，主要測試軟件功能的方法稱為47. 選擇測試用例，使得被測程序中每個(gè)判定的每個(gè)分支至少執(zhí)行一次，這種邏輯覆蓋標(biāo)準(zhǔn)稱為48. 要覆蓋含循環(huán)結(jié)構(gòu)的所有路徑是不可能的，一般通過限制測試。法。來測試。49. 用等價(jià)類劃分法設(shè)計(jì)測試用例時(shí)，如果被測程序的某個(gè)輸入條件規(guī)定了取值范圍，則可確定一個(gè)合理的等在和。50 憑經(jīng)驗(yàn)或直覺推測程序中可能存在的錯(cuò)誤而設(shè)計(jì)測試用例的方法是 51集成測試中的具體方法是。52.

7、確認(rèn)測試階段的兩項(xiàng)工作是53. 在單元測試中，測試一個(gè)模塊時(shí)，需要設(shè)計(jì) 。54. 軟件配置管理，簡稱 SCM它用于整個(gè)軟件工程過程。其主要目標(biāo)是:55. SCM是一組管理整個(gè)軟件生存期各階段中的活動。56基線的作用是把各階段的開發(fā)工作劃分得更加明確，便于檢查與確認(rèn)階段成果。因此，基線可以作為 項(xiàng)目的一個(gè)。2.文檔資料內(nèi)部結(jié)構(gòu)測試用例程序錯(cuò)誤缺陷3.輸入數(shù)據(jù)輸出數(shù)據(jù)4.動態(tài)測試靜態(tài)測試 5.運(yùn)行程序 測試用例黑盒測試 白盒測試6.人工檢測計(jì)算機(jī)輔助靜態(tài)分析 7.編碼質(zhì)量編碼 軟件產(chǎn)品8.靜態(tài)分析特性9.接口 需求規(guī)格功能10.內(nèi)部結(jié)構(gòu)處理過程處理過程測試11.結(jié)構(gòu)源程序內(nèi)部邏輯12.判定語句覆蓋

8、判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋 路徑覆蓋13.條件組合 路徑14.循環(huán)循環(huán)次數(shù)15.控制流程圖 環(huán)路基本路徑16.功能等價(jià)類劃分邊界值分析錯(cuò)誤推測因果圖17.功能一句話一個(gè)短語等價(jià)類18.邊界邊界值第一 個(gè)最后一個(gè)19.錯(cuò)誤推測法20.因果功能說明 判定表判定表21.測試黑盒白盒22.軟件配 置測試配置測試工具23.單元測試集成測試確認(rèn)測試系統(tǒng)測試24.單元測試編碼詳細(xì)設(shè)計(jì)25.模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)重要的執(zhí)行路徑錯(cuò)誤處理邊界條件26.驅(qū)動樁驅(qū)動模塊樁模塊27.單元 組裝聯(lián)合28.非漸增式測試漸增式測試29.自頂向下結(jié)合自底向上結(jié)合30.驅(qū)動樁頂層軟件結(jié)構(gòu)圖深度優(yōu)先策略寬度優(yōu)先策

9、略31.樁驅(qū)動32.功能性能需求規(guī)格有效性33.黑盒專門測試人員用戶34.測試測試分析實(shí)際運(yùn)用35.完整性正確性36.糾錯(cuò)原因位置37.簡單調(diào)試歸納法調(diào)試演繹法調(diào)試回溯法調(diào)試38.程序產(chǎn)生錯(cuò)誤的地方測試結(jié)果發(fā)現(xiàn)的線索39.靜態(tài)40 盡可能多的41.一個(gè)42 驅(qū)動模塊與樁模塊 43.漸增式和非漸增式 44.發(fā)現(xiàn)錯(cuò)誤45 動態(tài) 測試46.黑盒法47.判定覆蓋48.循環(huán)次數(shù)49.兩個(gè)不合理的等價(jià)類 50.錯(cuò)誤推測法51 .漸增式和非漸增式測試方法52.進(jìn)行確認(rèn)測試和軟件配置審查53 驅(qū)動模塊和樁模塊 54.標(biāo)識變更控制變更確保變更正確地實(shí)現(xiàn)報(bào)告有關(guān)變更55.變更56.檢查點(diǎn)三個(gè)方面。1程序設(shè)計(jì)語言的

10、特性主要有心理特性、工程特性和技術(shù)特性2.程序語言的工程特性主要表現(xiàn)為可移植性、開發(fā)工具的可利用性、軟件的可重用性和可維護(hù)性。3.為了提高程序的易讀性，同時(shí)為減少錯(cuò)誤，提高軟件開發(fā)效率，編碼時(shí)應(yīng)注意養(yǎng)成良好的 風(fēng)格。程序設(shè)計(jì)4 程序加注釋對理解程序提供了明確指導(dǎo)，根據(jù)作用不同注釋分 釋 。序言性注釋和功能性注5.軟件需求分析之后, 術(shù)特性。軟件的設(shè)計(jì)、編碼、測試與語言的特性有很大的關(guān)系，這個(gè)特性主要是語言的6.語句構(gòu)造的原則是簡單直接，不能為了追求效率而使代碼復(fù)雜化。7. FORTRAN 語言上世界上第一個(gè)被正式推廣應(yīng)用的計(jì)算機(jī)語言,它不僅面向科學(xué)計(jì)算， 數(shù)據(jù)處理能力也極強(qiáng)。是面向機(jī)器的，可以

11、完成高級語言無法滿足要求的特殊功能，如與外部設(shè)備之間的一些接口操作。9.為了使數(shù)據(jù)定義更容易理解和維護(hù)，一個(gè)語句說明多個(gè)變量時(shí)，各變量名按 字典排列。是將詳細(xì)設(shè)計(jì)得到的處理過程的描述轉(zhuǎn)換為基于某種計(jì)算機(jī)語言的程序。1.軟件原來沒有幫助信息，使用不方便，現(xiàn)在要增加幫助信息。這種維護(hù)性活動稱之為 護(hù)。10. 編碼完善性維2.調(diào)試也稱 糾錯(cuò) ，是在成功的測試之后才開始進(jìn)行,其目的是確定錯(cuò)誤的原因和 位置(5)并改正錯(cuò)誤。3調(diào)試技術(shù)包括簡單調(diào)試歸納法調(diào)試演繹法調(diào)試和 回溯法調(diào)試4.回溯法調(diào)試是從程序產(chǎn)生錯(cuò)誤的地方出發(fā)，而歸納法調(diào)試是從測試結(jié)果發(fā)現(xiàn)的線索入手。簡答題1簡述1983年IEEE為軟件下的定義

12、。 5822926計(jì)算機(jī)程序、方法、規(guī)則、相關(guān)的文檔資料以及在計(jì)算機(jī)上運(yùn)行程序時(shí)所必需的數(shù)據(jù)。2簡述軟件危機(jī)的表現(xiàn)有哪些？以及解決軟件危機(jī)的途徑有哪些？軟件危機(jī)的主要表現(xiàn)包括:(1)軟件開發(fā)進(jìn)度難以預(yù)測，開發(fā)成本難以控制，導(dǎo)致超預(yù)算、超時(shí); 產(chǎn)品功能難以滿足用戶需求；軟件產(chǎn)品質(zhì)量無法保證；軟件缺少適當(dāng)?shù)奈臋n資料，維護(hù)困難；軟件成本超過硬件成本；(6)解決軟件危機(jī)的途徑有:軟件開發(fā)生產(chǎn)率的提高速度跟不上計(jì)算機(jī)應(yīng)用普及深入的趨勢；1管理措施：項(xiàng)目管理、配置管理、過程管理、質(zhì)量控制2技術(shù)措施：開發(fā)過程、開發(fā)技術(shù)與方法和開發(fā)工具3 軟件工程的定義1993 年 IEEE 給出的定義：軟件工程是： 系統(tǒng)的

13、、規(guī)范的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行和維護(hù)過程，也就是把工程應(yīng)用于軟件;軟件工程 =計(jì)算機(jī)科學(xué) +工程學(xué) +管理學(xué) 研究中提到的途徑?！?軟件工程是圍繞軟件開發(fā)的一門交叉學(xué)科：4 軟件工程的 10 個(gè)知識領(lǐng)域(Software Design )(Software Construction)(Software Testing)(Software Maintenance)軟件工程過程 ( Software Engineering Process) 軟件工程工具和方法 ( Software Engineering Tools and Methods ) 軟件需求 (Software Requi

14、rement)l 軟件設(shè)計(jì) 軟件構(gòu)造 軟件測試 軟件維護(hù) 軟件配置管理 (Software Configuration management) 軟件工程管理 ( Software Engineering management ) 軟件質(zhì)量 ( Software Quality)5 軟件工程的目標(biāo)是什么，軟件工程的三要素都是什么？ 軟件工程的目標(biāo)：軟件工程必須以有組織的質(zhì)量保證為基礎(chǔ)，進(jìn)行全面質(zhì)量管理，不斷地過程改進(jìn)使軟件 工程方法走向成熟。軟件工程的三要素包括：過程、方法和工具 過程為及時(shí)合理地開發(fā)出滿足用戶需求的計(jì)算機(jī)軟件而進(jìn)行一系列有組織的活動。過程定義了技術(shù)方法的 采用、工程產(chǎn)品 (包括

15、模型、文檔、數(shù)據(jù)、報(bào)告、表格等 ) 的產(chǎn)生、里程碑的建立、質(zhì)量的保證和變更的管 理。方法為軟件開發(fā)提供“如何做”的技術(shù)，它涵蓋了項(xiàng)目計(jì)劃、需求分析、系統(tǒng)設(shè)計(jì)、程序?qū)崿F(xiàn)、測試與維 護(hù)等一系列的開發(fā)活動如何來做。開發(fā)方法經(jīng)歷了從面向結(jié)構(gòu)、面向?qū)ο?、面向組件到面向服務(wù)的發(fā)展工 程。工具為過程和方法提供自動的或半自動的支持。這些軟件工具被集成起來，建立起一個(gè)支持軟件開發(fā)的系 統(tǒng)，稱之為計(jì)算機(jī)輔助軟件工程 (CASE ， Computer Aided Software Engineering) 。6 軟件工程的七條基本原理美國著名的軟件工程專家巴利 ?玻姆 (Barry Boehm) 提出了軟件工程的七

16、條基本原理： 用分階段的生命周期計(jì)劃嚴(yán)格管理;堅(jiān)持進(jìn)行階段評審;實(shí)行嚴(yán)格的產(chǎn)品控制;采納現(xiàn)代程序設(shè)計(jì)技術(shù);結(jié)果應(yīng)能清楚地審查; 開發(fā)小組的人員應(yīng)少而精;承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。7 簡述軟件過程的定義，軟件過程又可以分為那幾個(gè)類型？軟件過程 (Software Procedure) 是為獲得軟件產(chǎn)品，在軟件工具支持下由軟件工程師完成的一系列軟件工 程活動。組織軟件過程可概括為基本過程、支持過程和組織過程等三種類型。 其中，基本過程包括：獲取過程、供應(yīng)過程、開發(fā)過程、運(yùn)作過程和維護(hù)過程。支持過程包括：文檔編制 過程、配置管理過程、質(zhì)量保證過程、驗(yàn)證過程、確認(rèn)過程、聯(lián)合評審過程和問題解決過

17、程等過程。過程包括：管理過程、基礎(chǔ)設(shè)施過程、改進(jìn)過程和培訓(xùn)過程。8里程碑(Mile Stone ) 思想，降低項(xiàng)階段工作的目標(biāo)進(jìn)行總結(jié)、評審、調(diào)整和部署下一個(gè)里程碑。目的：合理分配，細(xì)化管理“粒度” 目風(fēng)險(xiǎn)。9基線思想基線是指一個(gè)(或一組)配置項(xiàng)在項(xiàng)目生命周期的不同時(shí)間點(diǎn)的一種狀態(tài)，各階段有各階段的基線：需求基 線、設(shè)計(jì)基線、測試基線等?；€一旦建立后變化需要受控制。10簡述軟件生存周期的概念，說明軟件生存周期劃分為那幾個(gè)主要時(shí)期？每個(gè)時(shí)期有包括哪些主要階 段？軟件生存周期是指軟件產(chǎn)品從定義到開發(fā)、使用和維護(hù)，直到最終被棄用的時(shí)期，稱為生存周期。 生存周期的可劃分為計(jì)劃時(shí)期、開發(fā)時(shí)期和運(yùn)行時(shí)期

18、等三個(gè)主要時(shí)期。其中計(jì)劃時(shí)期包括問題定義和可行性研究兩個(gè)階段。開發(fā)時(shí)期包括需求分析、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)和實(shí)現(xiàn) 等四個(gè)階段。運(yùn)行時(shí)期的又稱為運(yùn)行和維護(hù)階段。11簡述教材中介紹了那些軟件開發(fā)模型？這些模型各有什么特點(diǎn)？教材中重點(diǎn)介紹了瀑布、原型、增量、螺旋四個(gè)傳統(tǒng)模型和RUP XP兩個(gè)現(xiàn)代模型。其中，瀑布模型嚴(yán)格按照生存周期開發(fā)軟件，每個(gè)階段必須完成規(guī)定的、完整、準(zhǔn)確的合格文檔，前一階 段的輸出文檔就是后一階段的輸入文檔。其主要特點(diǎn)包括：活動間具有順序性和依賴性；推遲實(shí)現(xiàn)的觀點(diǎn)；質(zhì)量保證的觀點(diǎn)； 做出系統(tǒng)原型，及早向用戶展示系統(tǒng)要實(shí)現(xiàn)的界面及功能，增強(qiáng)用戶的合作容易交流，消除理解上的歧義；修改集中

19、在前期的原型確認(rèn)上，較大程度減入手快，加快開發(fā)進(jìn)度；先完成一個(gè)系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加子集，如此遞增下去直至快速原型模型法是開發(fā)人員在一個(gè)基本的需求的基礎(chǔ)上快速開發(fā)出一個(gè)軟件原型，然后由用戶使用和評價(jià) 原型、開發(fā)人員根據(jù)用戶意見再修改原型，然后再使用評價(jià)再修改、直至將原型進(jìn)化為最終產(chǎn)品。 快速原型模型的特點(diǎn)包括： 信心；直觀化的表達(dá)， 少后期實(shí)施中的返工。 增量模型是一種演化模型， 滿足全部系統(tǒng)需求。每個(gè)增量可按快速原型法進(jìn)行。增量模型的特點(diǎn)包括： 無須等待獲取完整需求就可入手，盡快見到成果，增強(qiáng)雙方信心；分步開發(fā),降低復(fù)雜性和難度，減少技術(shù)風(fēng)險(xiǎn)，并可并行開發(fā)；邊開發(fā)邊投入，可及

20、早發(fā)現(xiàn)問題，減少投資風(fēng)險(xiǎn)；各個(gè)子集是逐漸并入已有的系統(tǒng)中，加入子集不能破壞已構(gòu)造好的部分，這需要軟件具備開放式的體系結(jié)構(gòu)；適用于需求不完整的軟件開發(fā)，指的是需求逐漸摸清、逐步完善，并非隨意改變，需求改變過大 會導(dǎo)致整體性失控。后面要介紹的XP (極限編程)屬于該模型。螺旋模型(Spiral model) 是一種融合了瀑布模型、快速原型模型和增量模型的演進(jìn)模型，并引入風(fēng)險(xiǎn)分析 機(jī)制。適合大型復(fù)雜的系統(tǒng)開發(fā)。螺旋模型特點(diǎn) 包括：多種模型結(jié)合的一種演進(jìn)模型，融合了瀑布模型、快速原型和增量模型的所有特點(diǎn)，融進(jìn)了循環(huán)往復(fù)、迭代演進(jìn)的思想；增加風(fēng)險(xiǎn)分析，一旦風(fēng)險(xiǎn)成立，原方案應(yīng)終止、修訂，力求風(fēng)險(xiǎn)可控客戶始

21、終參與每個(gè)階段的開發(fā)，每個(gè)階段的成果需客戶確認(rèn)，避免錯(cuò)誤的積累。統(tǒng)一過程 RUP (Rational Unified Process) 是由Rational 公司在推出統(tǒng)一建模語言 UML后，推出的一個(gè) 軟件開發(fā)框架RUP稱為軟件統(tǒng)一開發(fā)過程。12統(tǒng)一過程RUP定義了那幾個(gè)主要階段？(Lifecycle初始階段(Inception): 主要完成商業(yè)需求，確定項(xiàng)目邊界。里程碑是生命周期目標(biāo) Objective)，評價(jià)項(xiàng)目基本的生存能力。細(xì)化階段(Elaboration):主要完成領(lǐng)域問題分析和軟件設(shè)計(jì)。獲取用戶需求(功能和非功能需求)，建立需求模型；進(jìn)一步確立體系結(jié)構(gòu)和設(shè)計(jì)軟件結(jié)構(gòu)等工作。里程碑

22、是生命周期結(jié)構(gòu)(LifecycleArchitecture) 。，產(chǎn)構(gòu)造階段(Construction):主要完成系統(tǒng)實(shí)現(xiàn)、測試，里程碑是初始功能(Initial Operational)品版本常被稱為beta ”版。交付階段仃ransition):重點(diǎn)是確保軟件對最終用戶是可用的。里程碑：產(chǎn)品發(fā)布(Product Release)13統(tǒng)一過程RUP工作流個(gè)核心過程工作流(Core Process Workflows)商業(yè)建模(Business Modeling):弄清項(xiàng)目邊界和約束，做出計(jì)劃。需求(Requirements):描述系統(tǒng)應(yīng)做什么，開發(fā)人員和用戶達(dá)成需求基線。分析和設(shè)計(jì)(Anal

23、ysis & Design):將需求轉(zhuǎn)化成計(jì)算機(jī)可以實(shí)現(xiàn)的模型。實(shí)現(xiàn)(Im piementation):用程序設(shè)計(jì)語言將設(shè)計(jì)模型組織成可執(zhí)行的文件、數(shù)據(jù)。 測試(Test):是發(fā)現(xiàn)軟件中的錯(cuò)誤，在實(shí)驗(yàn)環(huán)境下驗(yàn)證所有的需求是否被正確的實(shí)現(xiàn)。部署(Deployment):將軟件分發(fā)給最終用戶，安裝在真實(shí)的環(huán)境下，由用戶操作運(yùn)行。個(gè)核心支持工作流(Core Supporting Workflows)是對核心過程工作流的配套支持和管理，保障核心過程工作流順暢、高效運(yùn)行。配置和變更管理：工作文檔的管理，在版本更新、需求變更中做到各類文檔及時(shí)、同步跟蹤, 保證各文檔內(nèi)容完整、一致。項(xiàng)目管理(Project

24、 Management):資源配置、評估監(jiān)控、風(fēng)險(xiǎn)控制、計(jì)劃調(diào)整等管理工作，目 的效益最大化。環(huán)境(Environment):軟件開發(fā)環(huán)境，包括人員、設(shè)備、過程和工具，以及各種規(guī)范、指導(dǎo)手冊 和保障措施。14簡述rup模型中基線與里程碑的概念，二者之間的關(guān)系?；€，是軟件文檔或源碼(或其它產(chǎn)出物)的一個(gè)穩(wěn)定版本，它是進(jìn)一步開發(fā)的基礎(chǔ)，也可以理解成為一個(gè)階 段的起點(diǎn)并已經(jīng)制定了相應(yīng)的工作標(biāo)準(zhǔn)，并且只有經(jīng)過授權(quán)后才能變更這個(gè)標(biāo)準(zhǔn)。里程碑，是計(jì)劃中確定的階段性工作完成目標(biāo)，要求提交階段交付物，作為階段評估的標(biāo)準(zhǔn)。 基線和里程牌的關(guān)系：基線是為了建立參照點(diǎn)，是階段的起點(diǎn)；里程牌是建立階段性目標(biāo)，是階段

25、終點(diǎn)， 最后的里程牌可能是一次迭代的終結(jié)。15簡述軟件計(jì)劃的目標(biāo)和主要工作 .、經(jīng)費(fèi)，掌握開發(fā)進(jìn)度,軟件計(jì)劃的目標(biāo)：研究項(xiàng)目的可行性，研究合理地運(yùn)用軟件項(xiàng)目開發(fā)所需的資源 控制項(xiàng)目開發(fā)過程按此計(jì)劃進(jìn)行。主要工作包括：確定項(xiàng)目實(shí)施范圍、定義遞交的工作成果、評估實(shí)施過程中主要的風(fēng)險(xiǎn)、制定項(xiàng)目實(shí)施的時(shí) 間計(jì)劃、成本和預(yù)算計(jì)劃、人力資源計(jì)劃等。16軟件計(jì)劃的活動有哪些？這些活動的內(nèi)容是什么？軟件計(jì)劃主要活動包括：問題定義，可行性研究，項(xiàng)目計(jì)劃。這些活動的內(nèi)容是：問題定義：確定項(xiàng)目實(shí)施范圍，回答項(xiàng)目“做什么？ ”的問題。可行性研究：項(xiàng)目的必要性和可能性。制定項(xiàng)目計(jì)劃：編制項(xiàng)目開發(fā)計(jì)劃。17簡述問題定義的

26、目的和主要任務(wù)。問題定義的目的：弄清要計(jì)算機(jī)解決的根本問題所在(要解決的問題是什么？)，確定新系統(tǒng)的作用域，以及項(xiàng)目所需的資源、工期和經(jīng)費(fèi)。問題定義的主要任務(wù)：編寫項(xiàng)目報(bào)告提交審查，作為可行性分析的依據(jù)。18簡述可行性分析的目的、任務(wù)和內(nèi)容?？尚行苑治龅哪康模捍_定項(xiàng)目的必要性和可能性?？尚行苑治龅娜蝿?wù)包括：可行性分析；寫可行性研究報(bào)告；編制開發(fā)計(jì)劃。 可行性分析的內(nèi)容包括：技術(shù)、經(jīng)濟(jì)和社會三個(gè)方面的可行性：。準(zhǔn)19 簡述需求分析的目的、必要性和參與角色 需求分析的目的是：弄清用戶對系統(tǒng)的細(xì)節(jié)要求，完整、準(zhǔn)確、清晰、具體地回答目標(biāo)系統(tǒng)“做什么” 確地理解用戶提出的軟件功能、性能及其環(huán)境的要求。5

27、0%是需求不合理，早期錯(cuò)需求分析的必要性：用戶與開發(fā)者的知識領(lǐng)域不同，產(chǎn)生歧義；軟件開發(fā)失敗 誤易放大。 參與角色：開發(fā)方包括分析師、設(shè)計(jì)師和架構(gòu)師。用戶方包括領(lǐng)域?qū)＜?、用戶和部門負(fù)責(zé)人。20 需求開發(fā)的任務(wù)有哪些？ 需求開發(fā)的任務(wù)包括 需求獲取：收集用戶對目標(biāo)軟件系統(tǒng)在功能、性能、行為、設(shè)計(jì)約束等方面的期望。 需求分析：通過符號和文字說明描述系統(tǒng)模型，使用戶和開發(fā)者間建立共同語言基礎(chǔ)，消除理解上的歧義 的過程。需求說明：既編寫需求文檔，也稱編寫需求規(guī)格說明書。需求說明書是需求分析階段的最終成果，也是需 求分析階段復(fù)審的依據(jù)；是用戶領(lǐng)域?qū)＜摇④浖治鰩?、軟件設(shè)計(jì)師共同交流的途徑和媒介；是交付給

28、用 戶文檔的一部份；需求驗(yàn)證 : 即需求評審。根據(jù)需求說明書，分析師、設(shè)計(jì)師、客戶會審文檔，對需求的正確性、一致性、完 整性、無二義行進(jìn)行評審、確認(rèn)。21 需求的層次 軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求、用戶需求、功能需求，也包括非功能需求。 1業(yè)務(wù)需求 (business requirement)業(yè)務(wù)需求是反映企業(yè) / 組織對軟件系統(tǒng)的高層次目標(biāo)要求 , 即軟件系統(tǒng)的建設(shè)目標(biāo)。業(yè)務(wù)需求通常是“問題定義”或“可行性研究”階段獲取的內(nèi)容；在需求規(guī)格說明書中反映在項(xiàng)目背景、 系統(tǒng)目標(biāo)或任務(wù)概述的描述中。獲取的主要對象是客戶方的高管、專家、部門負(fù)責(zé)人。2用戶需求 (user requirement

29、)用戶需求： 用來描述用戶使用產(chǎn)品必須要完成的任務(wù)； 使用業(yè)務(wù)領(lǐng)域的術(shù)語描述，采用開發(fā)者與用戶都能 理解的語言和圖形表達(dá)。 用戶需求是經(jīng)過調(diào)查、歸納后雙方認(rèn)同的結(jié)果。獲取的主要對象是部門負(fù)責(zé)人、軟件的操作者或稱終端用戶。3. 功能需求 (functional requirement) 功能需求定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，結(jié)果在需求規(guī)格說明書中; 功能需求用軟件行業(yè)術(shù)語表達(dá)：通常是需求建模的結(jié)果即目標(biāo)系統(tǒng)的邏輯模型，如結(jié)構(gòu)化的功能模型、數(shù)據(jù)模型、行為模型，面向?qū)ο蟮?類模型等。4. 非功能需求 特性是指一些非功能需求，是滿足業(yè)務(wù)需求的性能要求。如界面的交互性、數(shù)據(jù)的安全性、數(shù)據(jù)的事務(wù)性、

30、用戶的并發(fā)性、響應(yīng)的快速性、操作的實(shí)時(shí)性、錯(cuò)誤與異常的恢復(fù)性、軟件的容錯(cuò)性等等。 項(xiàng)目的失敗或 拖延一般不是在功能上，而恰恰倒是在性能要求上，因?yàn)檫@些性能與軟件的體系結(jié)構(gòu)有關(guān)，與構(gòu)成系統(tǒng)的 網(wǎng)路與硬件環(huán)境等底層技術(shù)有關(guān)，往往超越一般開發(fā)人員的技術(shù)能力。22 需求獲取的一般方法 需求獲取方法以采訪、觀察、座談、對先前的系統(tǒng)版本的測試等。必要時(shí)采用快速原型法。 先集中在使用者對系統(tǒng)的觀點(diǎn)上，以收集用戶原始資料，數(shù)據(jù)、工作方式、工作流程、使用要求等為 工作起點(diǎn)，深入到部門、車間、班組，做好原始紀(jì)錄； 然后根據(jù)對問題及環(huán)境的理解與開發(fā)經(jīng)驗(yàn)，改正用戶需求的模糊、歧義和不一致性要求，排除用戶的 不合理要求

31、，挖掘用戶尚未提出但具有價(jià)值的潛在需求，使用戶需求逐步精確化、一致化和完全化； 需求獲取非一次完成：需要往復(fù)進(jìn)行、逐步深化。 需求獲取的內(nèi)容：寫進(jìn)“需求規(guī)格說明書” ，確認(rèn)。23需求獲取的策略循序漸進(jìn)的策略；確定優(yōu)先級：先進(jìn)行重點(diǎn)的需求調(diào)研，有助于識別出重大的風(fēng)險(xiǎn)，并為制定迭代計(jì)劃提供指導(dǎo)；不要陷入技術(shù)：需求未明確，應(yīng)回避對技術(shù)問題討論。挖掘用戶需求：“誘導(dǎo)式”就是挖掘用戶需求?？蛻舨⒎荌T專業(yè)人士，需求的概念是模糊的、籠統(tǒng)的,而且尺度難以把握，預(yù)測潛在需求。區(qū)分不必要的需求：客戶對有些需求提不出來，自然也會提出一些不必要的需求。24簡述概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)的內(nèi)容。軟件設(shè)計(jì)包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)

32、。概要設(shè)計(jì)又分為體系結(jié)構(gòu)設(shè)計(jì)和領(lǐng)域問題結(jié)構(gòu)設(shè)計(jì)。體系結(jié)構(gòu)設(shè)計(jì)：是支撐和管理軟件運(yùn)行的環(huán)境設(shè)計(jì)。由于現(xiàn)代的軟件是處在操作系統(tǒng)、網(wǎng)絡(luò)、各種服務(wù)器 共同搭建的環(huán)境下運(yùn)行，并且具有并發(fā)、安全、事務(wù)等多方面的管理，是軟件設(shè)計(jì)優(yōu)先考慮的問題。領(lǐng)域問題結(jié)構(gòu)設(shè)計(jì)：滿足需求的軟件功能設(shè)計(jì)，核心所在。將領(lǐng)域問題的分析模型細(xì)化成軟件結(jié)構(gòu)模型， 也就是劃分軟件的模塊結(jié)構(gòu)及確定模塊之間的關(guān)系。 詳細(xì)設(shè)計(jì)又分為如下三個(gè)部分:對模塊內(nèi)部的過程和數(shù)據(jù)結(jié)構(gòu)進(jìn)行設(shè)計(jì)。也就是對模塊內(nèi)進(jìn)行算法分析和程序設(shè)計(jì)。人機(jī)交互界面的具體設(shè)計(jì)，還有與其它外部系統(tǒng)接口設(shè)計(jì)。完成對數(shù)據(jù)庫的物理設(shè)計(jì)概要設(shè)計(jì)是根據(jù)需求確定軟件和數(shù)據(jù)的總體框架；詳細(xì)設(shè)計(jì)

33、是進(jìn)一步精化成軟件的算法和數(shù)據(jù)結(jié)構(gòu)。25 25簡述衡量軟件模塊獨(dú)立性的度量標(biāo)準(zhǔn)有哪些?模塊獨(dú)立性是指模塊能夠完成獨(dú)立的功能；模塊符合信息隱藏和信息局部化原則；模塊間關(guān)連和依賴程度 盡量小。衡量軟件模塊獨(dú)立性的度量標(biāo)準(zhǔn)的指標(biāo)有取決于模塊的內(nèi)部特征的指標(biāo)內(nèi)聚度和取決于模塊的外部特征的 指標(biāo)耦合度。內(nèi)聚度：一個(gè)模塊內(nèi)部各個(gè)元素間 （語句和程序段）彼此的緊密程度的度量。耦合度：指軟件結(jié)構(gòu)中各模塊間相互聯(lián)系緊密程度的一種度量。26簡述內(nèi)聚度的七個(gè)等級？內(nèi)聚度表示一個(gè)模塊內(nèi)部各成分之間彼此結(jié)合的緊密程度。內(nèi)聚度按其高低程度可分為七級，高內(nèi)聚度模 塊獨(dú)立性強(qiáng)，設(shè)計(jì)盡可能提高模塊內(nèi)聚度。偶然性內(nèi)聚：是指一個(gè)模

34、塊內(nèi)各成分為完成一組功能而組合在一起，它們相互之間即使有關(guān)系, 也很松散。邏輯性內(nèi)聚：模塊內(nèi)完成的諸任務(wù)邏輯上相關(guān)。 該類內(nèi)聚的缺點(diǎn)是執(zhí)行中要從模塊外引入用 斷的開關(guān)量，從而 增加了塊間偶合（控制偶合）。時(shí)間性內(nèi)聚： 過程性內(nèi)聚： 執(zhí)行；通訊性內(nèi)聚：如果一個(gè)模塊包含的諸任務(wù)必須在同一時(shí)間段內(nèi)執(zhí)行，則稱之為時(shí)間性內(nèi)聚 模塊的過程性內(nèi)聚度是指模塊內(nèi)成份彼此相關(guān)，并且必須按特定的次序在本模塊內(nèi)是指模塊中各組成成分都將對某個(gè)數(shù)據(jù)結(jié)構(gòu)的同一區(qū)域進(jìn)行操作，以達(dá)到通信的目作判的。一個(gè)模塊內(nèi)的各處理成分均與同一功能相關(guān)，且這些處理必須順序執(zhí)行，通常，一順序性內(nèi)聚：個(gè)處理成分的輸出是另一個(gè)處理成分的輸入。功能性

35、內(nèi)聚：模塊內(nèi)所有成分形成一個(gè)整體，完成單個(gè)功能，則稱功能內(nèi)聚，功能內(nèi)聚是最高程 度的內(nèi)聚形式。27耦合度的七個(gè)等級耦合度是模塊獨(dú)立性最顯著特征。耦合度按其高低程度可分為七級，松耦合是軟件設(shè)計(jì)一直追求的目標(biāo)。兩模塊間通過參數(shù)交換數(shù)據(jù)信息，則稱這兩模塊為數(shù)據(jù)耦合。模塊之間除傳遞關(guān)鍵數(shù)據(jù)外還附加公共數(shù)據(jù)?？刂岂詈?控制耦合。外部耦合非直接耦合 : 模塊不依賴另一個(gè)模塊能獨(dú)立工作，這是最松的耦合。 數(shù)據(jù)耦合 特征耦合如果兩模塊間通過參數(shù)交換信息，此時(shí)若傳遞的信息中含有控制信息，則為公共耦合 內(nèi)容耦合當(dāng)若干模塊均與同一個(gè)外部環(huán)境關(guān)聯(lián)，它們之間便存在外部耦合。 當(dāng)若干模塊通過全局的數(shù)據(jù)環(huán)境相互作用時(shí)，它們

36、之間存在公共耦合。當(dāng)一個(gè)模塊使用另一個(gè)模塊內(nèi)部的數(shù)據(jù)或控制信息； 一個(gè)模塊直接轉(zhuǎn)移到另一 個(gè)模塊內(nèi)部等 , 模塊間的耦合就是內(nèi)容耦合。28 簡述模塊的作用域與控制域的概念及其相關(guān)設(shè)計(jì)原則。 模塊的作用域:從功能方面考慮，受模塊內(nèi)一個(gè)判定影響的所有模塊的集合； 模塊的控制域:從結(jié)構(gòu)方面考慮，包括它自己及其所有下屬模塊的集合。相關(guān)設(shè)計(jì)原則是:模塊的作用域應(yīng)在控制域之內(nèi)。29 詳細(xì)設(shè)計(jì)的表達(dá)方式有哪些？1. 偽代碼(Pseudocode):是一種算法描述語言，也稱PDL語言(Program Design Language)。偽代碼介于自然語言與編程語言之間，用偽代碼描述的算法可以容易用任何一種編程語

37、言實(shí)現(xiàn)。偽代碼表達(dá)算法必須結(jié) 構(gòu)清晰、代碼簡單、可讀性好。2. 程序流程圖:用圖形符號表達(dá)算法，直觀表達(dá)循環(huán)、分支等復(fù)雜結(jié)構(gòu)，是喜聞樂見的表現(xiàn)形式。3. 盒圖(N-S) (Nassi和Shneiderman):也是一種圖形符號表達(dá)方式，同樣可以表達(dá)各種流向控制，但比程 序流程圖緊湊、功能域明確。圖(PAD-Problem Analysis Diagram)28:同樣是用圖形符號表達(dá)算法，但它具有結(jié)構(gòu)化的表達(dá)方式，因此結(jié)構(gòu)十分清晰，很容易翻譯成程序代碼。PAD支持自頂向下，逐步求精方法的使用。判定表與判定樹:對于規(guī)則較多，判定條件較復(fù)雜的情況，宜采用這兩種方法表達(dá)。SA方法中，有哪些建模方法？數(shù)

38、據(jù)流圖 DFD(Data Flow Diagram)+ 數(shù)據(jù)字典 DD(Data Dictionary) 實(shí)體關(guān)系圖 ERD(Entity Relation Diagram)；狀態(tài)轉(zhuǎn)換圖 STD(State Transform Diagram)；PESPEC(Process SPECification) 和判定表等輔助工具。5. 判定表與判定樹:對于規(guī)則較多，判定條件較復(fù)雜的情況，宜采用這兩種方法表達(dá)。30 簡述面向數(shù)據(jù)流的結(jié)構(gòu)化分析功能建模數(shù)據(jù)建模行為建模加工說明31簡述數(shù)據(jù)流圖(DFD的圖形符號有哪些？ 數(shù)據(jù)流:表示數(shù)據(jù)流的名稱和數(shù)據(jù)的流向(從加工出發(fā)或流向加工 )； 外部實(shí)體:系統(tǒng)外與系

39、統(tǒng)交互的人或?qū)嶓w； 數(shù)據(jù)加工:數(shù)據(jù)處理； 數(shù)據(jù)存儲:數(shù)據(jù)進(jìn)行持久保存的環(huán)節(jié)；32 簡述數(shù)據(jù)字典的作用、內(nèi)容和組成元素有哪些？ 數(shù)據(jù)流圖描述了數(shù)據(jù)加工，但沒有描述數(shù)據(jù)的內(nèi)容。數(shù)據(jù)流圖必須與描述并組織數(shù)據(jù)條目的數(shù)據(jù)字典 DD(Data Dictionary) 配套使用。數(shù)據(jù)字典描述的對象:描述數(shù)據(jù)流圖中出現(xiàn)的所有數(shù)據(jù)和加工。這里的數(shù)據(jù)描述是概念性的，屬數(shù)據(jù)結(jié)構(gòu) 的抽象描述；加工采用加工小說明進(jìn)行概念性的描述。數(shù)據(jù)字典的組成元素包括:數(shù)據(jù)流條目、 數(shù)據(jù)存儲條目、數(shù)據(jù)項(xiàng)條目；加工條目 (也稱為小說明 )； 33 簡述面向?qū)ο蟮幕靖拍钣心男? 對象與面向?qū)ο髮ο? Object ):即表示客觀世界中

40、的某個(gè)具體的事物。面向?qū)ο? Object Oriented ):是人類的活動，是 人類認(rèn)知、觀察客觀事物的方法論。2. 面向?qū)ο蟮某橄笈c分類3. 類的封裝與對象的整體性4. 關(guān)聯(lián)性與交互性客觀事物都不是孤立存在的，萬物之間相互依存、相互交流。關(guān)聯(lián)性表達(dá)客觀事物的社會性、共存性、組 織性，是靜態(tài)的結(jié)構(gòu)描述。消息機(jī)制是對象的交互性，表示對象生存環(huán)境的依賴性。5繼承性對事物的分類本身就體現(xiàn)繼承性。軟件開發(fā)利用繼承性可對 Object更好地分類，軟件結(jié)構(gòu)更嚴(yán)謹(jǐn)，代碼的復(fù)用性更強(qiáng)。6. 多態(tài)性對象在不同的條件下，同樣的行為會表現(xiàn)不同的效果，這就是 Object的多態(tài)(polymorphism)。 面向

41、對象編程語言提供抽象類、接口、重載等技術(shù)支持多態(tài)的實(shí)現(xiàn)。34面向?qū)ο蟮奈宕筇匦杂心男?？面向?qū)ο蟮奶匦杂谐橄笮浴⒎庋b性、繼承性、多態(tài)性和消息機(jī)制等五大特性。35簡述面向?qū)ο箝_發(fā)過程的內(nèi)容有哪些? 需求獲?。洪_發(fā)者以O(shè)O的觀點(diǎn)(OOV)來觀察客觀世界的目標(biāo)即獲取需求，然后用自然語言寫到需求規(guī)格說明(OOS)中，也就是對客觀世界的最高層抽象。 面向?qū)ο蠓治?OOA (Object Oriented Analysis)與面向?qū)ο笤O(shè)計(jì) OODQbject Oriented Design)。 面向?qū)ο缶幊?Object Oriented Program(OOP)與面向?qū)ο鬁y試 Object Oriente

42、d Testing (OOT) 是代碼實(shí)現(xiàn)過程，它依賴于編程語言和工具。361.軟件維護(hù) Object Oriented Software Maintenance(OOSM) 。 與傳統(tǒng)的軟件開發(fā)方法相比較，面向?qū)ο箝_發(fā)的主要優(yōu)點(diǎn)有哪些? 自然性即客觀性2.操作數(shù)據(jù)對象而非數(shù)據(jù)實(shí)體3.階段銜接平滑4.結(jié)構(gòu)性好、復(fù)用性強(qiáng)5.提高擴(kuò)展性和維護(hù)性用例圖(Use Case)描述系統(tǒng)參與者與領(lǐng)域問題的功能類圖(Class)描述系統(tǒng)的邏輯結(jié)構(gòu)，類、接口及它們的協(xié)作關(guān)系包圖(Package )描述類的復(fù)用組織一分組對象圖(Object)描述類的實(shí)例在某時(shí)刻的關(guān)系構(gòu)件圖(Component)描述系統(tǒng)按構(gòu)件組成

43、上的關(guān)系配置圖(Deployment)描述系統(tǒng)運(yùn)行環(huán)境的配置情況時(shí)序圖(Sequence)描述某些對象共同合作完成某項(xiàng)功能而按時(shí)間順序進(jìn)行的消息傳遞協(xié)作圖(Collaboration)描述某些對象共同合作完成某項(xiàng)功能的依賴關(guān)系活動圖(Activity)描述某個(gè)用例按事件流轉(zhuǎn)所經(jīng)歷的的活動，即業(yè)務(wù)流程37簡述UML中定義了那些圖形符號？并簡述起作用。狀態(tài)圖(State chart)描述某個(gè)業(yè)務(wù)流程按事件流轉(zhuǎn)所經(jīng)歷的狀態(tài)，即狀態(tài)機(jī)38簡述用例圖中有哪些模型元素？并簡述其含義？ 參與者：指存在于系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，代表系統(tǒng)的使用者或使用環(huán)境。 用例（Use Case），用例用于

44、表示系統(tǒng)提供的服務(wù)，它定義了系統(tǒng)是如何與參與者交互，描述了參與者與 系統(tǒng)之間的交互過程。 角色與用例間的關(guān)系關(guān)聯(lián)，它表示參與者與系統(tǒng)中的哪些用例交互。用例之間的關(guān)系：包含 vvinclude和擴(kuò)充關(guān)系以及泛化關(guān)系。參與者之間的泛化關(guān)系。39簡述類圖中有哪些模型元素？并簡述其含義?提示：一切可以出現(xiàn)在類圖中的元素。類： 類名、屬性、方法（可見性、作用域）特殊類：接口類之間的關(guān)系的定義、表示和屬性：關(guān)聯(lián)、依賴、聚合、組合、泛化、實(shí)現(xiàn)。各種類關(guān)系之間的關(guān)系。40簡述包圖中有哪些模型元素？并簡述其含義?提示：一切可以出現(xiàn)在包圖中的元素。包和包之間的關(guān)系。41簡述活動圖中有哪些構(gòu)成元素？并簡述這些元素的

45、含義?42簡述00A模型的結(jié)構(gòu)00A勺核心任務(wù)是搞清用戶需求，最終要建立起00A模型。UML的 00/模型由“用例模型”和“概念模型”兩大部分組成。UML語言表達(dá)的模型，主要面向用戶，反映用戶需 用例模型，是將用自然語言描述的領(lǐng)域問題，轉(zhuǎn)換成 求。完整的用例模型由用例圖和業(yè)務(wù)場景描述兩個(gè)部分組成，用例圖表示功能的劃分； 業(yè)務(wù)場景描述則對每個(gè)用例的事件流進(jìn)行描述； 概念模型（類模型/結(jié)構(gòu)模型/靜態(tài)模型）。將用例模型映射成類模型：從用例模型中找出類，面向設(shè)計(jì)人員。主要工作是：根據(jù)用例圖進(jìn)行類的劃分與封裝；描述類間的靜態(tài)關(guān)系與結(jié)構(gòu)；用交互圖表達(dá)類對象間的消 息傳遞。43對象間的可訪問性屬性可見性：B

46、是A的一個(gè)屬性（關(guān)聯(lián)、聚合）；參數(shù)可見性：B的對象是A的一個(gè)方法的參數(shù)；局部聲明可見性：B的對象是在A的一個(gè)方法中聲明的一個(gè)局部變量； 全局可見性：B的對象在某種程度上全局可見；44對象持久化對象持久化常用技術(shù)實(shí)體類的實(shí)例稱為數(shù)據(jù)對象，對象持久化主要用于數(shù)據(jù)對象的持久化，簡稱數(shù)據(jù)持久化。 一個(gè)數(shù)據(jù)對象的持久化就是保存到實(shí)體表中的一條記錄，對實(shí)體對象的訪問就是操作屬性的值。 對象持久化常用技術(shù)對象的序列化 指將對象的相關(guān)信息（對象序列號、屬性名、屬性值等）轉(zhuǎn)換為字節(jié)流，然后再把字節(jié)流寫入數(shù)據(jù)流。可 以把對象這些信息存儲在本地的文件里，也可以把它通過網(wǎng)絡(luò)傳輸?shù)竭h(yuǎn)程。通過對象反序列化，得到原對象完全

47、相同的副本。 對象持久化到數(shù)據(jù)庫中數(shù)據(jù)庫可以是對象數(shù)據(jù)庫或關(guān)系數(shù)據(jù)庫。用 XML( extensible Mark up Language)存儲。45“實(shí)體模型”到“關(guān)系模型”的OR映射一個(gè)對象類可以映射為一個(gè)以上的庫表，當(dāng)類間有一對多的關(guān)系時(shí)，一個(gè)表也可以對應(yīng)多個(gè)類。定義相應(yīng)的主鍵 PK (Primary key )和外鍵 FK( Foreign key(3) 單一繼承的泛化關(guān)系可以對超類、子類分別映射表 反之，也可以不定義子類表而讓父類表擁有全部子類屬性。(4) 對多重繼承的超類和子類分別映射表，對多次多重繼承的泛化關(guān)系也映射一個(gè)表。(5) 對映射后的庫表進(jìn)行冗余控制調(diào)整，使其達(dá)到合理的關(guān)

48、系范式。 46軟件測試的定義,也可以不定義父類表而讓子類表擁有父類屬性;對象關(guān)系(一對一、一對多、多對多)的映射可能有多種情況，但一般映射為一個(gè)表或多個(gè)表，在表間 )建立實(shí)體間的關(guān)系。軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而運(yùn)行程序的過程；軟件測試的目的是發(fā)現(xiàn)程序中的錯(cuò)誤，是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)；測試對象不僅是程序，還應(yīng)該包括開發(fā)過程中產(chǎn)生的所有產(chǎn)品，包括文檔，其目的 是為了盡早地、盡可能多的發(fā)現(xiàn)并排除軟件中潛在的錯(cuò)誤。47軟件測試的基本原則 Who來測試？測試工作應(yīng)該由獨(dú)立的、專業(yè)的軟件測試機(jī)構(gòu)來完成，設(shè)計(jì)人員和程序員要參與測試；對測試結(jié)果一定要 有一個(gè)確認(rèn)的過程，一般由角色 A測試出來的錯(cuò)

49、誤，一定要有一個(gè)角色B來確認(rèn)，嚴(yán)重的錯(cuò)誤可以召開評審會進(jìn)行討論和分析； 測試What？程序員交付的模塊、系統(tǒng)和文檔； 測試Extent ？設(shè)計(jì)測試用例，充分覆蓋所有條件或所有語句即可； When測試？盡早和不斷的測試，即將這種“測試”貫穿于軟件開發(fā)的各個(gè)階段，堅(jiān)持各個(gè)階段的技術(shù)評審，以便盡早 地發(fā)現(xiàn)和預(yù)防錯(cuò)誤； How測試？設(shè)計(jì)測試用例時(shí)不僅要考慮到合法的輸入，還要考慮到不合法的輸入以及各種邊界條件；對發(fā)現(xiàn)錯(cuò)誤較多 的程序模塊，應(yīng)進(jìn)行重點(diǎn)測試。48軟件缺陷，軟件缺陷的屬性：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的錯(cuò)誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是 系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失

50、效或違背。軟件缺陷的屬性：缺陷標(biāo)識、缺陷類型、缺陷嚴(yán)重、程度缺陷、優(yōu)先級、缺陷狀態(tài)、缺陷起源、缺陷來源、缺陷根源等。49簡述測試用例的概念測試用例(Test Case)是關(guān)于具體測試步驟的文檔，以判斷被測軟件的工作是否正常。內(nèi)容包括：測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果等。從表現(xiàn)形式上看，測試用例可以是 純文本的文檔，也可以是用程序設(shè)計(jì)語言編寫的一段代碼。50簡述基本測試方法的分類情況測試方法分類內(nèi)容靜態(tài)測試走查評審邏 輯 覆 蓋 法語句覆蓋語句覆蓋是最簡單、最弱覆蓋。它只覆蓋可執(zhí)行語句至少執(zhí)行一次。判定覆蓋判定覆蓋又叫分支覆蓋，是對每個(gè)判定式取真、假各一次，使每個(gè)判定的 每個(gè)分支

51、都至少執(zhí)行一次，同時(shí)滿足語句覆蓋。條件覆蓋條件覆蓋是把程序中每個(gè)判斷的每個(gè)條件為真和假各取值一次。條件覆蓋 深入到判定中的每個(gè)條件，但不一定滿足判定覆蓋的要求。判定/條件覆蓋判定/條件覆蓋能同時(shí)滿足判定、條件兩種覆蓋標(biāo)準(zhǔn)的取值。就是使得判定 中每個(gè)條件的所有可能取值至少執(zhí)行一次，同時(shí)每個(gè)判定本身所有取值至 少執(zhí)行一次。條件組合覆蓋條件組合覆蓋是按每個(gè)判斷的所有條件取值進(jìn)行組合。這是5種覆蓋中最強(qiáng)的覆蓋。它不但可覆蓋所有條件，還可覆蓋所有判斷的可取分支?；韭窂礁采w法基本路徑測試步驟： 導(dǎo)出程序流程圖的拓?fù)浣Y(jié)構(gòu)-流圖(控制流程圖)； 計(jì)算流圖G的環(huán)路復(fù)雜性 V(G); 確定只包含獨(dú)立路徑的基本路

52、徑集 ； 設(shè)計(jì)測試用例；等價(jià)類劃分法對測試數(shù)據(jù)進(jìn)行區(qū)間劃分，從這些區(qū)間中選取典型值作為用例代表，認(rèn)為 測試等價(jià)類中的一個(gè)代表值的結(jié)果就等于對該類其它值的測試。邊界值分析法邊界值分析法就是對輸入或輸出的邊界值進(jìn)行測試的一種方法。錯(cuò)誤推測法因果圖法測試黑盒測試簡述軟件測試過程的主要內(nèi)容。白 盒511.2.3.需求與設(shè)計(jì)評審單元測試(Unit Testing)集成測試4.功能測試5.6.系統(tǒng)測試 驗(yàn)收測試7.a 與 3測試1)2)用黑盒進(jìn)行模塊邊界條件的測試3)4)用白盒進(jìn)行模塊局部數(shù)據(jù)結(jié)構(gòu)和算法的測試用白盒進(jìn)行模塊中獨(dú)立路徑的測試5)53模塊中各條錯(cuò)誤處理路徑的測試簡述集成測試的主要內(nèi)容集成測試也

53、叫組裝測試或聯(lián)合測試。集成測試是在單元測試基礎(chǔ)上， 再將單元按照概要設(shè)計(jì)規(guī)格說明的要求組裝成更大的模塊、1)非漸增式集成測試子系統(tǒng)或系統(tǒng)。非漸增式集成測試又叫一次性集成測試，就是把所有經(jīng)過單元測試的模塊按照設(shè)計(jì)規(guī)格說明書一次性組裝 成系統(tǒng)，然后進(jìn)行統(tǒng)一的測試。52簡述單元測試(Unit Testing)的主要內(nèi)容。單元測試又稱模塊測試，是針對軟件設(shè)計(jì)的最小單位程序模塊(函數(shù)、類等)進(jìn)行正確性檢驗(yàn)的測試工作。單元測試采用黑盒+白盒混合方式，采用黑盒測試為主為先，白盒測試為輔為后的策略。 用黑盒進(jìn)行模塊接口測試2)漸增式集成測試漸增式集成測試即把下一個(gè)要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試

54、，測完后，再把下一個(gè)應(yīng) 該測試的模塊結(jié)合進(jìn)來測試。54. 簡述驗(yàn)收測試的概念驗(yàn)收測試是軟件交付之前的最后一個(gè)測試操作，驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用 戶將其用于執(zhí)行軟件的既定功能和任務(wù)。55. a 與 3測試 這兩種測試是針對商用軟件的系統(tǒng)測試。商用軟件與合同定制式軟件不同，它面向的使用群體數(shù)量大、不確定，沒用針對性的驗(yàn)收用戶。因此在軟 件正式面市之前免費(fèi)供用戶試用，由用戶在試用中發(fā)現(xiàn)問題，這就是P測試。提供給用戶的P版如果 BUG太多，客戶將無法試用和承受，因此首先軟件開發(fā)組織內(nèi)部人員模擬各類用戶 對即將面市軟件產(chǎn)品進(jìn)行測試，此時(shí)稱為a測試。56簡述軟件維護(hù)的概念軟件維護(hù)

55、是在軟件交付使用之后，為了改正錯(cuò)誤或滿足新的需求而修改軟件的過程。 57軟件維護(hù)的分類糾錯(cuò)性維護(hù)(Corrective Maintenance )糾錯(cuò)性維護(hù)是在軟件交付后，糾正哪些在運(yùn)行中發(fā)現(xiàn)的殘留錯(cuò)誤，也稱改正性維護(hù)。 適應(yīng)性維護(hù)(Adaptive Maintenance )為適應(yīng)軟件運(yùn)行環(huán)境(軟件生態(tài)環(huán)境)的變化而修改軟件的活動稱為適應(yīng)性維護(hù)。 完善性維護(hù)(Peffective Maintenance ) 根據(jù)用戶在軟件使用過程中提出的建設(shè)性意見(需求變化)而進(jìn)行的維護(hù)活動稱為改善性維護(hù)。預(yù)防性維護(hù)(Preventive Maintenance )為了進(jìn)一步改善軟件的可靠性和易維護(hù)性，或者為將來的維護(hù)奠