軟件工程復(fù)習(xí)(針對(duì)性).doc

軟件工程復(fù)習(xí)一 軟件工程概述1 軟件危機(jī)的定義，如何克服2 軟件過程模型，螺旋模型，噴泉模型二可行性研究：經(jīng)濟(jì)可行性，技術(shù)可行性內(nèi)容三面向?qū)ο蟮姆椒ㄅcUML1. 面向?qū)ο笙到y(tǒng)的概念1） 對(duì)象的定義2） 繼承和多態(tài)重用3） 活動(dòng)和動(dòng)作的定義與區(qū)別2 UML模型元素3. UML中的圖四軟件需求工程1什么叫需求分析，每一步生成哪些文檔2數(shù)據(jù)流圖的定義3ONT的概念方法和模型（對(duì)象模型、動(dòng)態(tài)模型、功能模型）4面向?qū)ο蟮姆治鼋７椒?原型化方法，結(jié)構(gòu)化分析方法，及兩者間的關(guān)系。6.軟件需求規(guī)格說明書內(nèi)容，目標(biāo)，作用7.UML中類圖與對(duì)象圖（會(huì)話）五軟件設(shè)計(jì)工程1.軟件設(shè)計(jì)的目標(biāo)與準(zhǔn)則 2.了解“耦合性”概念 數(shù)據(jù)流圖-程序結(jié)構(gòu)圖（事物流/變換流）3.a結(jié)構(gòu)化設(shè)計(jì)與結(jié)構(gòu)化分析的關(guān)系 b事務(wù)流映射 c軟件模塊結(jié)構(gòu)改進(jìn)方法7條 記前3條（注：abc三條比較重要）4.a程序流程圖 bPAD圖5.Jackson系統(tǒng)方法適用范圍6.詳細(xì)設(shè)計(jì)，PAD圖（給算法畫PAD圖）、控制流圖、環(huán)路復(fù)雜度 六軟件實(shí)現(xiàn)1.源程序文檔化 2.Mecabe度量法（環(huán)路復(fù)雜度）七軟件測試工程 1.代碼檢查 2.什么是“樁”模塊，驅(qū)動(dòng)模塊八軟件測試用例 1.測試用例設(shè)計(jì)概述 2.動(dòng)態(tài)測試【白盒測試（基本路徑測試）、黑盒測試（等價(jià)類劃分）】 3. 9.3節(jié)基本路徑測試要看九軟件維護(hù) 1.軟件維護(hù)的目標(biāo) 2.程序修改的定義和副作用軟件工程復(fù)習(xí)知識(shí)點(diǎn)一 軟件工程概述1 軟件危機(jī)的定義，如何克服 （1）軟件危機(jī)：是指落后的軟件生產(chǎn)方式無法滿足迅速增長的計(jì)算機(jī)軟件需求，從而導(dǎo)致軟件的開發(fā)與維護(hù)過程中出現(xiàn)一系列嚴(yán)重問題的現(xiàn)象。 軟件危機(jī)包含下述兩方面的問題：如何開發(fā)軟件，以滿足對(duì)軟件日益增長的需求；如何維護(hù)數(shù)量不斷膨脹的已有軟件。 根源：與軟件本身的特點(diǎn)有關(guān)；由軟件開發(fā)和維護(hù)的方法不正確有關(guān)。 （2）如何克服軟件危機(jī)：開發(fā)：軟件開發(fā)技術(shù)、方法、工具，用科學(xué)的工程化思想來組織和指導(dǎo)軟件開發(fā)的各個(gè)階段 ；努力完善軟件質(zhì)量保障體系 重視軟件文檔；人員：必要的組織管理措施，各類人員協(xié)同共同完成軟件開發(fā)項(xiàng)目，聘用有經(jīng)驗(yàn)的專業(yè)人員，可以減少開發(fā)成本； 測試、維護(hù)：盡早并不斷改正的錯(cuò)誤。主要表現(xiàn)：l 開發(fā)人員開發(fā)的軟件產(chǎn)品不能完全滿足用戶的需求；l 軟件產(chǎn)品的質(zhì)量難以得到保障；l 開發(fā)周期開發(fā)經(jīng)費(fèi)和維護(hù)費(fèi)用很難被準(zhǔn)確估計(jì)從而給項(xiàng)目的管理帶來很多麻煩；l 隨著技術(shù)的更新，用戶的擴(kuò)大，已有的軟件產(chǎn)品不能靈活地適應(yīng)環(huán)境的改變；l 軟件文檔不完備并且存在文檔內(nèi)容與軟件產(chǎn)品不符的情況。原因：軟件開發(fā)是一項(xiàng)復(fù)雜的工程，需要用科學(xué)的工程化思想來組織和指導(dǎo)軟件開發(fā)的各個(gè)階段沒有完善的質(zhì)量保證體系軟件文檔的重要性沒有得到軟件開發(fā)人員和用戶的足夠重視從事軟件開發(fā)的專業(yè)人員對(duì)這個(gè)產(chǎn)業(yè)認(rèn)識(shí)不夠充分缺乏經(jīng)驗(yàn)軟件獨(dú)有的特點(diǎn)也給軟件的開發(fā)和維護(hù)帶來困難2 軟件過程模型，螺旋模型，噴泉模型（1） 螺旋模型：將瀑布模型與演化模型（快速原型模型）結(jié)合起來。沿著螺線旋轉(zhuǎn)，自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更完善的一個(gè)新版本。用于風(fēng)險(xiǎn)較大的大型軟件開發(fā)模型，分為制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程、客戶評(píng)估.（2）噴泉模型：現(xiàn)了迭代和無間隙的特性。是對(duì)象驅(qū)動(dòng)的過程。（階段相互重疊，全過程）特點(diǎn)：階段相互重疊，并行性；整個(gè)過程是一個(gè)迭代的、逐步細(xì)化的過程；是對(duì)象驅(qū)動(dòng)的過程；不但反映了系統(tǒng)的開發(fā)全過程，而且也反映了對(duì)象族的開發(fā)和復(fù)用的過程。相關(guān)題型： 螺旋模型將_瀑布_模型和_快速原型_模型結(jié)合起來，加入了兩種模型均忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了這兩種模型的不足。 螺旋模型將開發(fā)過程分為幾個(gè)螺旋周期，在每個(gè)螺旋周期內(nèi)分為4個(gè)工作步驟。第一步_目標(biāo)設(shè)定（或制定計(jì)劃）_，確定目標(biāo)，選定實(shí)施方案，明確開發(fā)限制條件。第二步_風(fēng)險(xiǎn)估計(jì)與弱化（或風(fēng)險(xiǎn)分析）_，分析所選方案，識(shí)別風(fēng)險(xiǎn)，通過原型消除風(fēng)險(xiǎn)。第三步_開發(fā)與確認(rèn)（或?qū)嵤┕こ蹋，實(shí)施軟件開發(fā)。第四步_計(jì)劃（客戶評(píng)價(jià)）_， 評(píng)價(jià)開發(fā)工作，提出修改意見，建立下一個(gè)周期的計(jì)劃。噴泉模型是一種以_用戶需求_為動(dòng)力，以_對(duì)象_作為驅(qū)動(dòng)的模型，適合于_面向?qū)ο蟮能浖?xiàng)目_的開發(fā)方法。它克服了瀑布模型不支持軟件重用和多項(xiàng)開發(fā)活動(dòng)集成的局限性。噴泉模型使開發(fā)過程具有_迭代_和_無間隙_。2 可行性研究：經(jīng)濟(jì)可行性，技術(shù)可行性內(nèi)容 經(jīng)濟(jì)可研究要對(duì)項(xiàng)目的開發(fā)總成本與開發(fā)系統(tǒng)將帶來的經(jīng)濟(jì)效益之間的差值進(jìn)行度量。經(jīng)濟(jì)可行性，需要進(jìn)行成本-效益分析。對(duì)可能取得的效益（有形的和無形的）進(jìn)行比較權(quán)衡。（1）經(jīng)濟(jì)可行性定義/內(nèi)容：進(jìn)行開發(fā)成本的估算以及了解取得效益的評(píng)估，確定要開發(fā)的項(xiàng)目是否值得投資開發(fā)。 有形的效益可以用貨幣的時(shí)間價(jià)值、投資回收期、純收入、投資回收率等指標(biāo)進(jìn)行度量。 無形的效益主要是從性質(zhì)上、心理上進(jìn)行衡量，很難直接進(jìn)行數(shù)量的比較。 幾種度量效益的方法：貨幣的時(shí)間價(jià)值投資回收期純收入投資回收率（2）技術(shù)可行性內(nèi)容： 根據(jù)待開發(fā)系統(tǒng)的功能、性能及實(shí)現(xiàn)系統(tǒng)的各種約束條件等，分析在現(xiàn)有的資源和技術(shù)條件下，技術(shù)風(fēng)險(xiǎn)有多大，系統(tǒng)是否能實(shí)現(xiàn)。技術(shù)可行性分析通常包括風(fēng)險(xiǎn)分析、資源分析和技術(shù)分析。技術(shù)型可行性研究是對(duì)技術(shù)解決方案的實(shí)用性、技術(shù)資源的可用性和設(shè)備條件作出評(píng)估。經(jīng)濟(jì)可研究要對(duì)項(xiàng)目的開發(fā)總成本與開發(fā)系統(tǒng)將帶來的經(jīng)濟(jì)效益之間的差值進(jìn)行度量三面向?qū)ο蟮姆椒ㄅcUML1. 面向?qū)ο笙到y(tǒng)的概念1） 對(duì)象的定義對(duì)象是客觀世界中存在的事物，也可以是概念化的實(shí)體，它由一組屬性和操作組成。2） 繼承和多態(tài)重用繼承表示類之間的層次關(guān)系，它使得某類對(duì)象可以自動(dòng)擁有另外一個(gè)或多個(gè)對(duì)象的全部屬性和操作。多態(tài)是一種使父類中定義的屬性或操作被子類繼承后可以有不同的實(shí)現(xiàn)的機(jī)制。3） 活動(dòng)和動(dòng)作的定義與區(qū)別行為事物是UML模型的動(dòng)態(tài)部分，包括交互和狀態(tài)機(jī)兩類。交互（Interaction）：交互由在特定的上下文環(huán)境中共同完成一定任務(wù)的一組對(duì)象之間傳遞的消息組。交互涉及的元素包括消息、動(dòng)作序列和鏈。狀態(tài)機(jī)（State Machine）：狀態(tài)機(jī)描述了一個(gè)對(duì)象或一個(gè)交互在生存周期內(nèi)響應(yīng)事件所經(jīng)歷的狀態(tài)序列。狀態(tài)機(jī)涉及的元素包括狀態(tài)、轉(zhuǎn)換、事件活動(dòng)等。2 UML模型元素UML的三個(gè)主要組成元素：1)基本構(gòu)造塊（basic building block)2)組織構(gòu)造塊的規(guī)則（rules）3)運(yùn)用于整個(gè)UML的公共機(jī)制（common mechanisms）補(bǔ)充：UML包括三種基本構(gòu)造塊（UML的模型元素）:1)事物（things）2)關(guān)系（relationships）3)圖（diagrams）3. UML中的圖四軟件需求工程(需求開發(fā)、需求管理)1什么叫需求分析，每一步生成哪些文檔(1)需求分析是在可行性研究的基礎(chǔ)上，將用戶對(duì)系統(tǒng)的描述，通過開發(fā)人員的分析概括，抽象為完整的需求定義，再形成一系列文檔的過程。(2)需求分析的步驟：獲取需求，識(shí)別問題用戶需求草稿（文檔）；分析需求，建立目標(biāo)系統(tǒng)的邏輯框架分析模型（非文檔）；將需求文檔化用戶需求和系統(tǒng)需求（文檔）；需求驗(yàn)證（需求評(píng)審）需求規(guī)格說明書（文檔）。軟件需求工程過程模型：需求分析階段需要編寫的文檔有:需求規(guī)格說明書,初步用戶使用手冊(cè)和確認(rèn)測試計(jì)劃.需求開發(fā)是一個(gè)迭代的過程，需求迭代是需求開發(fā)成功的關(guān)鍵。分析建模中建模方法有：結(jié)構(gòu)化分析法（SA）原型化方法 面向?qū)ο蟮姆治龇椒ㄜ浖O(shè)計(jì)中軟件結(jié)構(gòu)設(shè)計(jì)的方法：結(jié)構(gòu)化設(shè)計(jì)法（SD），面向?qū)ο蟮脑O(shè)計(jì)方法2數(shù)據(jù)流圖的定義 數(shù)據(jù)流圖DFD（data flow diagram）是描述系統(tǒng)中數(shù)據(jù)流的圖形工具，是一種用來表示信息流和信息變換過程的圖解方法，可以標(biāo)識(shí)一個(gè)系統(tǒng)的邏輯輸入和輸出，以及把邏輯輸入轉(zhuǎn)化為邏輯輸出所需的加工處理.3 OMT的概念方法和模型（對(duì)象模型、動(dòng)態(tài)模型、功能模型）Rumbaugh方法(OMTObject Modeling Technique ,對(duì)象模型化技術(shù)) 采用了面向?qū)ο蟮母拍?，并引入各種獨(dú)立于語言的表示符。開發(fā)工作的基礎(chǔ)是對(duì)真實(shí)世界的對(duì)象建模，然后圍繞這些對(duì)象使用分析模型來進(jìn)行獨(dú)立于語言的設(shè)計(jì)。Rumbaugh用來描述一個(gè)系統(tǒng)的三種模型：對(duì)象模型描述系統(tǒng)中對(duì)象的靜態(tài)結(jié)構(gòu)；動(dòng)態(tài)模型描述系統(tǒng)狀態(tài)隨時(shí)間變化的情況；功能模型描述系統(tǒng)中各個(gè)數(shù)據(jù)值的轉(zhuǎn)變。 該方法強(qiáng)調(diào)：系統(tǒng)設(shè)計(jì)(并發(fā)、數(shù)據(jù)、控制)和對(duì)象設(shè)計(jì)(算法)。適用于分析和描述以數(shù)據(jù)為中心的信息系統(tǒng)。 11. 由RumBaugh等人提出的一種面向?qū)ο蠓椒ń凶鰧?duì)象模型化技術(shù)(OMT)，即三視點(diǎn)技術(shù)，它要求把分析時(shí)收集的信息建立在三個(gè)模型中。第一個(gè)模型是( A 對(duì)象模型)，它的作用是描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，包括構(gòu)成系統(tǒng)的對(duì)象和類，它們的屬性和操作，以及它們之間的聯(lián)系。第二個(gè)模型是( B動(dòng)態(tài)模型 )，它描述系統(tǒng)的控制邏輯，主要涉及系統(tǒng)中各個(gè)對(duì)象和類的時(shí)序及變化狀況。( B )包括兩種圖， 即( C )和( D )。( C 狀態(tài)遷移圖 )描述每一類對(duì)象的行為，( D )描述發(fā)生于系統(tǒng)執(zhí)行過程中的某一特定場景。第三個(gè)模型是( E 功能模型)，它著重于描述系統(tǒng)內(nèi)部數(shù)據(jù)的傳送與處理，它由多個(gè)數(shù)據(jù)流圖組成。 供選擇的答案： A, B, E： 數(shù)據(jù)模型 功能模型 行為模型 信息模型 原型 動(dòng)態(tài)模型 對(duì)象模型 邏輯模型 控制模型 仿真模型 C, D： 對(duì)象圖 概念模型圖 狀態(tài)遷移圖 數(shù)據(jù)流程圖 時(shí)序圖 事件追蹤圖 控制流程圖 邏輯模擬圖 仿真圖 行為圖答案：11.A. B. C. D. E.4 面向?qū)ο蟮姆治鼋７椒ǚ治鼋Ｖ薪７椒ㄓ校航Y(jié)構(gòu)化分析法（SA）原型化方法 面向?qū)ο蟮姆治龇椒ó?dāng)前流行的面向?qū)ο蠼７椒ㄓ校築ooch方法Rumbaugh方法Coad&Yourdon方法Jacobson方法Wirfs-Brock方法UML的OOA方法5 原型化方法，結(jié)構(gòu)化分析方法（SA），及兩者間的關(guān)系。兩者之間的關(guān)系：都是需求工程中需求開發(fā)階段的分析建模的建模方法。兩者相互補(bǔ)充。 原型化方法：是用戶和軟件開發(fā)人員之間進(jìn)行的一種交互過程。原型：模擬某種產(chǎn)品的原始模型。軟件原型的分類：探索型 實(shí)驗(yàn)型 進(jìn)化型使用原型的策略：廢棄策略 追加策略結(jié)構(gòu)化分析方法（SA）：結(jié)構(gòu)化分析方法最初只是著眼于數(shù)據(jù)流，自頂向下，逐層分解，建立系統(tǒng)的處理流程，以數(shù)據(jù)流圖和數(shù)據(jù)字典為主要工具，建立系統(tǒng)的邏輯模型。擴(kuò)充后，將建模技術(shù)擴(kuò)展到數(shù)據(jù)建模、功能建模和行為建模，以實(shí)體-關(guān)系圖（E-R圖）、數(shù)據(jù)流圖和控制流圖、狀態(tài)-遷移圖為工具，數(shù)據(jù)字典為核心，從不同視點(diǎn)建立系統(tǒng)的分析模型。 -參考：紅色字體請(qǐng)注意看原型化方法：原型化方法是一種定義系統(tǒng)需求可采取的策略，實(shí)現(xiàn)時(shí)需經(jīng)過若干步驟，一般其采用的最后步驟應(yīng)是模型驗(yàn)證。基本思想:開發(fā)人員對(duì)用戶提出的問題進(jìn)行總結(jié)，就系統(tǒng)的主要需求取得一致意見后，開發(fā)一個(gè)原型（原型是由開發(fā)人員與用戶合作，共同確定系統(tǒng)的基本要求和主要功能，并在較短時(shí)間內(nèi)開發(fā)的一個(gè)實(shí)驗(yàn)性的、簡單易用的小型系統(tǒng)。原型應(yīng)該是可以運(yùn)行的，可以修改的。）并運(yùn)行之，然后反復(fù)對(duì)原型進(jìn)行修改，使之逐步完善，直到用戶對(duì)系統(tǒng)完全滿意為止。 優(yōu)點(diǎn):（1）需求表示清楚，用戶滿意度較高（2）降低開始風(fēng)險(xiǎn)和開發(fā)成本 缺點(diǎn):（1）原型法不適用于開發(fā)大型的信息系統(tǒng)（2）系統(tǒng)難于維護(hù)（3）如果用戶合作不好，盲目糾錯(cuò)，會(huì)拖延開發(fā)進(jìn)程. 適用范圍:（1）用戶需求不清，管理及業(yè)務(wù)不穩(wěn)定，需求經(jīng)常變化（2）規(guī)模小，不太復(fù)雜（3）開發(fā)信息系統(tǒng)的最終用戶界面.結(jié)構(gòu)化開發(fā)方法(Structured Developing Method)是現(xiàn)有的軟件開發(fā)方法中最成熟，應(yīng)用最廣泛的方法，主要特點(diǎn)是快速、自然和方便。結(jié)構(gòu)化開發(fā)方法由結(jié)構(gòu)化分析方法（SA法）、結(jié)構(gòu)化設(shè)計(jì)方法（SD法）及結(jié)構(gòu)化程序設(shè)計(jì)方法（SP法）構(gòu)成的。 結(jié)構(gòu)化設(shè)計(jì)方法（SD法 Structured Design）是結(jié)構(gòu)化開發(fā)方法的核心，與SA法，SP法密切聯(lián)系，主要完成軟件系統(tǒng)的總體結(jié)構(gòu)設(shè)計(jì)?；舅枷?在系統(tǒng)建立之前信息就能被充分理解。它要求嚴(yán)格劃分開發(fā)階段，用規(guī)范的方法與圖表工具有步驟地來完成各階段的工作，每個(gè)階段都以規(guī)范的文檔資料作為其成果，最終得到滿足用戶需要的系統(tǒng)。 優(yōu)點(diǎn):（1）邏輯設(shè)計(jì)與物理設(shè)計(jì)分開（2）開發(fā)過程中形成一套規(guī)范化的文檔，便于后期的修改和維護(hù)。 缺點(diǎn):（1）開發(fā)周期長（2）系統(tǒng)難以適應(yīng)環(huán)境的變化（3）開發(fā)過程復(fù)雜繁瑣 適用范圍：該方法適用于一些組織相對(duì)穩(wěn)定、業(yè)務(wù)處理過程規(guī)范、需求明確且在一定時(shí)期內(nèi)不會(huì)發(fā)生大的變化的大型復(fù)雜系統(tǒng)的開發(fā)。-需求建模遵循三個(gè)原則：1 劃分：描述需求的整體部分關(guān)系；2 抽象：描述需求的一般化特殊化關(guān)系；3 投影：描述需求的多維視圖；定義系統(tǒng)模型要區(qū)分邏輯模型和物理模型。常用模型有數(shù)據(jù)建模、功能建模和過程建模。常用的建模分析方法1st) 面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)2nd) 面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法(JSD)3rd) 原型化方法4th) 面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法(DSSD)5th) 面向?qū)ο蟮姆治龇椒?OOA) 等結(jié)構(gòu)化設(shè)計(jì)（SD）與結(jié)構(gòu)化分析方法（SA）：結(jié)構(gòu)化：面向數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)是數(shù)據(jù)的各個(gè)元素之間邏輯關(guān)系的一種表示。數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)應(yīng)確定數(shù)據(jù)的組織、存取方式、相關(guān)程度以及信息的不同處理方法。（典型的數(shù)據(jù)結(jié)構(gòu)：鏈表、樹狀結(jié)構(gòu)、網(wǎng)狀結(jié)構(gòu)、n維空間）軟件的結(jié)構(gòu)有2類：軟件的模塊結(jié)構(gòu) 軟件的數(shù)據(jù)結(jié)構(gòu)題目： 原型化方法是用戶和軟件開發(fā)人員之間進(jìn)行的一種交互過程，適用于( A )系統(tǒng)。它從用戶界面的開發(fā)入手，首先形成( B )，用戶( C )，并就( D )提出意見，它是一種( E )型的設(shè)計(jì)過程。供選擇的答案：A. 需求不確定性高的 需求確定的 管理信息 決策支持B. 用戶界面使用手冊(cè) 用戶界面需求分析說明書 系統(tǒng)界面原型 完善的用戶界面C. 改進(jìn)用戶界面的設(shè)計(jì) 閱讀文檔資料 模擬用戶界面的運(yùn)行 運(yùn)行用戶界面原型D. 同意什么和不同意什么 使用和不使用哪一種編程語言 程序的結(jié)構(gòu) 執(zhí)行速度是否滿足要求E. 自外向內(nèi)（從界面開始） 自頂向下 自內(nèi)向外 自底向上原型化方法：問題總結(jié)主要需求原型運(yùn)行修改、完善滿意6. 軟件需求規(guī)格說明書內(nèi)容，目標(biāo)，作用 需求規(guī)格說明包括（內(nèi)容）：系統(tǒng)應(yīng)提供的功能和服務(wù)；非功能需求；系統(tǒng)開發(fā)或運(yùn)行的限制條件；與系統(tǒng)互連的其他系統(tǒng)的信息。 軟件需求規(guī)格說明是描述需求的重要文檔，是軟件需求分析工作的主要成果。它應(yīng)著重反映軟件的功能需求、性能需求、外部接口、數(shù)據(jù)流程等多個(gè)方面。（在軟件開發(fā)過程、軟件運(yùn)行和維護(hù)過程的整個(gè)生存周期當(dāng)中，它都起著重要的作用。）軟件需求規(guī)格說明的目標(biāo)：在軟件產(chǎn)品方面，為在軟件開發(fā)人員與客戶之間達(dá)成共同協(xié)議建立基礎(chǔ)。它全面描述了要實(shí)現(xiàn)的軟件功能。提高開發(fā)效率。編制軟件需求規(guī)格說明的過程可讓客戶在軟件設(shè)計(jì)開始之前能周密地思考全部需求，從而減少事后重新設(shè)計(jì)、重新編碼和重新測試的返工活動(dòng)。為成本估算和編制進(jìn)度計(jì)劃提供基礎(chǔ)。軟件需求規(guī)格說明提供的對(duì)于開發(fā)軟件的描述成為軟件產(chǎn)品成本估算的基礎(chǔ)。成為編制進(jìn)度計(jì)劃的依據(jù)。為確認(rèn)和驗(yàn)證提供一個(gè)基準(zhǔn)。作為開發(fā)合同的一個(gè)部分，軟件需求規(guī)格說明可以提供一個(gè)可度量和可遵循的基準(zhǔn)。便于移植。有了軟件需求規(guī)格說明，可幫助開發(fā)人員把軟件移植到新的操作環(huán)境，以適應(yīng)客戶新的需要。成為軟件不斷改進(jìn)的基礎(chǔ)。由于軟件需求規(guī)格說明所涉及的只是軟件產(chǎn)品的外部視圖（軟件能做什么），而不涉及軟件產(chǎn)品的內(nèi)部設(shè)計(jì)（軟件如何做）。因此，軟件需求規(guī)格說明成為軟件產(chǎn)品改進(jìn)的基礎(chǔ)。軟件需求規(guī)格說明編制的原則：功能與實(shí)現(xiàn)分離，描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。要求使用面向處理的規(guī)格說明語言，從而得到“做什么”的規(guī)格說明。如果目標(biāo)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中。規(guī)格說明必須包括系統(tǒng)運(yùn)行的環(huán)境。題目：.軟件需求分析的任務(wù)不應(yīng)包括（A）。進(jìn)行需求分析可使用多種工具，但（B）是不適用的。在需求分析中，分析員要從用戶那里解決的最重要的問題是( C )。需求規(guī)格說明書的內(nèi)容不應(yīng)當(dāng)包括( D )。該文檔（需求規(guī)格說明書）在軟件開發(fā)中具有重要的作用，但其作用不應(yīng)當(dāng)包括( E )。供選擇的答案：A. 問題分析 信息域分 結(jié)構(gòu)化程序設(shè)計(jì) 確定邏輯模型（分析建模）B. 數(shù)據(jù)流圖 判定表 PAD圖（詳細(xì)設(shè)計(jì)） 數(shù)據(jù)詞典C. 要讓軟件做什么 要給該軟件提供哪些信息 要求軟件工作效率如何 要讓軟件具有什么樣的結(jié)構(gòu)D. 對(duì)重要功能的描述 對(duì)算法的詳細(xì)過程性描述 軟件確認(rèn)準(zhǔn)則 軟件的性能E. 軟件設(shè)計(jì)的依據(jù) 用戶和開發(fā)人員對(duì)軟件要“做什么”的共同理解 軟件驗(yàn)收的依據(jù) 軟件可行性分析的依據(jù)（可行性分析在需求分析階段之前）7. UML中類圖與對(duì)象圖（會(huì)畫圖）（綜合題）（1）類圖：（2） 對(duì)象圖：對(duì)象名：類名 屬性=屬性值對(duì)象間的鏈可以使類之間關(guān)聯(lián)的實(shí)例五軟件設(shè)計(jì)工程1.軟件設(shè)計(jì)的目標(biāo)與準(zhǔn)則 軟件設(shè)計(jì)的基本目標(biāo)是用比較抽象概括的方式確定目標(biāo)系統(tǒng)如何完成預(yù)定的任務(wù)，即軟件設(shè)計(jì)是確定系統(tǒng)的物理模型。軟件設(shè)計(jì)的目標(biāo)涉及性能、可靠性、成本及維護(hù)等多個(gè)方面。軟件設(shè)計(jì)的準(zhǔn)則：性能準(zhǔn)則:包括對(duì)系統(tǒng)速度和空間的需求?？煽啃詼?zhǔn)則:決定了對(duì)減少系統(tǒng)崩潰及隨后所造成危害所做的努力程度。成本準(zhǔn)則：包括開發(fā)、配置和管理系統(tǒng)的成本。維護(hù)準(zhǔn)則：確定在完成開發(fā)后再次改變系統(tǒng)的困難程度。最終用戶準(zhǔn)則：包括從用戶視點(diǎn)出發(fā)所需的屬性，但并沒有覆蓋性能準(zhǔn)則和可靠性準(zhǔn)則。2. 了解“耦合性”概念 數(shù)據(jù)流圖-程序結(jié)構(gòu)圖（事物流/變換流）耦合：是模塊之間互相連接的緊密程度的度量。內(nèi)聚：模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度的度量。數(shù)據(jù)流程圖（DFD）的基本圖形元素（4種）：外部實(shí)體、加工、數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)。畫法：頂層（0層），功能分解（1層），功能進(jìn)一步分解（2層）結(jié)構(gòu)圖（SC）的主要成分（4個(gè)）：模塊模塊的調(diào)用關(guān)系和接口模塊間的信息傳遞（數(shù)據(jù)信息、控制信息）重復(fù)（循環(huán)）調(diào)用和選擇調(diào)用的符號(hào)交換流型結(jié)構(gòu)圖：邏輯輸入C、C變換成D，邏輯輸出D（還有物理輸入A，物理輸出E）事務(wù)流型結(jié)構(gòu)圖：數(shù)據(jù)接收通路、得到結(jié)果的調(diào)度（若干有選擇關(guān)系的平行事務(wù)，）、輸出結(jié)果。舉例：（1） 變換流型結(jié)構(gòu)圖（2） 事務(wù)流型結(jié)構(gòu)圖3. （注：abc三條比較重要）a結(jié)構(gòu)化設(shè)計(jì)與結(jié)構(gòu)化分析的關(guān)系1) 結(jié)構(gòu)化設(shè)計(jì)（structured design，SD）是一種面向數(shù)據(jù)流的設(shè)計(jì)方法，即根據(jù)系統(tǒng)的處理過程進(jìn)行設(shè)計(jì)，故亦稱為過程驅(qū)動(dòng)的設(shè)計(jì)。軟件設(shè)計(jì)階段，用于軟件結(jié)構(gòu)設(shè)計(jì)，建立目標(biāo)系統(tǒng)的物理模型。2) 結(jié)構(gòu)化分析方法（SA）：是面向數(shù)據(jù)流的分析方法，自頂向下，逐層分解。（建立系統(tǒng)的處理流程，建模技術(shù)擴(kuò)展到數(shù)據(jù)建模、功能建模和行為建模，）以實(shí)體-關(guān)系圖（E-R圖）、數(shù)據(jù)流圖和控制流圖、狀態(tài)-遷移圖為工具，數(shù)據(jù)字典為核心，從不同視點(diǎn)建立系統(tǒng)的分析模型（即系統(tǒng)的邏輯模型）。需求開發(fā)階段，用于分析建模，即建立目標(biāo)系統(tǒng)的邏輯模型。3) 結(jié)構(gòu)化設(shè)計(jì)與結(jié)構(gòu)化分析的關(guān)系：軟件設(shè)計(jì)必須依據(jù)對(duì)軟件的需求來進(jìn)行，結(jié)構(gòu)化分析的結(jié)果為結(jié)構(gòu)化設(shè)計(jì)提供了最基本的輸入信息。左邊：SA；右邊：SD b事務(wù)流映射事務(wù)流映射（概念）：從事務(wù)流型數(shù)據(jù)流圖出發(fā)的，建立軟件結(jié)構(gòu)圖的方法叫做事務(wù)流映射。從分析數(shù)據(jù)流圖開始，自頂向下，逐步分解，建立系統(tǒng)的結(jié)構(gòu)。事務(wù)流型的DFD的組成：輸入流事務(wù)中心若干條活動(dòng)流。將事務(wù)流型DFD映射成高層系統(tǒng)結(jié)構(gòu)： 頂層模塊：其功能就是整個(gè)系統(tǒng)的功能。接收模塊：接收輸入數(shù)據(jù)。分派模塊：調(diào)度模塊，控制下層的所有活動(dòng)模塊。事務(wù)模塊：對(duì)應(yīng)活動(dòng)流，是該活動(dòng)流映射成的。c軟件模塊結(jié)構(gòu)改進(jìn)方法7條(記前3條)模塊功能完善化；一個(gè)完整的模塊應(yīng)當(dāng)有以下幾部分：執(zhí)行規(guī)定的功能的部分；出錯(cuò)處理的部分返回?cái)?shù)據(jù)給它的調(diào)用者時(shí)，返回一個(gè)狀態(tài)碼。消除重復(fù)功能，改善軟件結(jié)構(gòu)；模塊的作用范圍應(yīng)在控制范圍之內(nèi)；模塊的控制范圍包括它本身及其所有的從屬模塊。模塊的作用范圍是指模塊內(nèi)一個(gè)判定的作用范圍，凡是受這個(gè)判定影響的所有模塊都屬于這個(gè)判定的作用范圍。如果一個(gè)判定的作用范圍包含在這個(gè)判定所在模塊的控制范圍之內(nèi)，則這種結(jié)構(gòu)是簡單的，否則，它的結(jié)構(gòu)是不簡單的。盡可能減少高扇出結(jié)構(gòu)；避免或減少使用病態(tài)聯(lián)接；模塊的大小要適中；設(shè)計(jì)功能可預(yù)測的模塊，避免過分受限制的模塊。軟件包應(yīng)滿足設(shè)計(jì)約束和可移植性。注：軟件結(jié)構(gòu)：軟件模塊結(jié)構(gòu)軟件數(shù)據(jù)結(jié)構(gòu)題目：從下列關(guān)于模塊化程序設(shè)計(jì)的敘述中選出5條正確的敘述。（2,3,4,7,8） 程序設(shè)計(jì)比較方便，但比較難以維護(hù)。(N) 便于由多個(gè)人分工編制大型程序。(Y) 軟件的功能便于擴(kuò)充。(Y) 程序易于理解，也便于排錯(cuò)。(Y) 在主存儲(chǔ)器能夠容納得下的前提下，應(yīng)使模塊盡可能大，以便減少模塊的個(gè)數(shù)。(N) 模塊之間的接口叫做數(shù)據(jù)文件。(?) 只要模塊之間的接口關(guān)系不變，各模塊內(nèi)部實(shí)現(xiàn)細(xì)節(jié)的修改將不會(huì)影響別的模塊。(Y) 模塊間的單向調(diào)用關(guān)系叫做模塊的層次結(jié)構(gòu)。(Y?) 模塊越小，模塊化的優(yōu)點(diǎn)越明顯。一般來說，模塊的大小都在10行以下。(N?)4. a程序流程圖程序流程圖：直觀清晰，易于使用，但控制流程線不易限制,不易反映逐步求精的過程，不易表示數(shù)據(jù)結(jié)構(gòu)。是詳細(xì)設(shè)計(jì)階段使用的工具。bPAD圖PAD圖：是種由左往右展開的二維樹型結(jié)構(gòu)，其能清晰地反映程序的層次結(jié)構(gòu)，支持逐步求精的設(shè)計(jì)方法，支持結(jié)構(gòu)化程序設(shè)計(jì)原理，易讀易寫，使用方便；可自動(dòng)生成程序。是詳細(xì)設(shè)計(jì)階段使用的工具。5. Jackson系統(tǒng)方法適用范圍既能表示數(shù)據(jù)結(jié)構(gòu)也能表示程序結(jié)構(gòu)（因?yàn)榻Y(jié)構(gòu)程序設(shè)計(jì)也只使用三種基本結(jié)構(gòu)：順序結(jié)構(gòu)、選擇結(jié)構(gòu)、重復(fù)結(jié)構(gòu)）。6. 詳細(xì)設(shè)計(jì)階段：PAD圖（給算法畫PAD圖）、控制流圖、環(huán)路復(fù)雜度（綜合題）控制流圖：（程序流程圖程序控制流圖）環(huán)路復(fù)雜度=判定節(jié)點(diǎn)數(shù)+1 六軟件實(shí)現(xiàn)1. 源程序文檔化 源程序文檔化： 按實(shí)際意義命名 遵循一定命名規(guī)則 變量不要過于相似 定義時(shí)作出解釋； 數(shù)據(jù)說明； 語句構(gòu)造； 輸入輸出； 效率。文檔的作用是什么？ 在軟件工程中，文檔用來表示對(duì)需求、工程或結(jié)果進(jìn)行描述、定義、規(guī)定、報(bào)告或認(rèn)證的任何書面或圖示的信息。它們描述和規(guī)定了軟件設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié)，說明使用軟件的操作命令。文檔也是軟件產(chǎn)品的一部分，沒有文檔的軟件就不成為軟件。2. Mecabe度量法（環(huán)路復(fù)雜度）將環(huán)路復(fù)雜性定義為控制流圖中的區(qū)域數(shù)。（區(qū)域：即由邊和節(jié)點(diǎn)封閉起來的區(qū)域）V(G)=m-n+p 從入口點(diǎn)到出口點(diǎn)加一條虛線表示的有向邊，構(gòu)成強(qiáng)連同圖：有向連通圖G環(huán)路復(fù)雜度V(G)=m-n+1 ,其中m為圖G中弧數(shù)，n為圖G中結(jié)點(diǎn)數(shù)，p為圖G中強(qiáng)連通分量個(gè)數(shù)(p=1)。從入口點(diǎn)到出口點(diǎn)不加虛線：給定控制流圖G的圈復(fù)雜度V(G)=E-N+2，其中E是流圖中邊的數(shù)量，N是流圖中結(jié)點(diǎn)的數(shù)量。給定控制流圖G的圈復(fù)雜度V(G)=P+1，其中P是流圖中判定結(jié)點(diǎn)的數(shù)量七軟件測試工程 1.代碼檢查 人工測試技術(shù)：桌面檢查代碼檢查走查通行評(píng)審技術(shù)桌面檢查（Desk Checking）:由程序員自己檢查自己編寫的程序。代碼檢查（Code Inspection）：是以小組位單位閱讀代碼，應(yīng)用一系列規(guī)程和缺陷檢查技術(shù)，檢查實(shí)際產(chǎn)品，包括文檔和程序代碼，發(fā)現(xiàn)存在缺陷和缺陷的過程。 走查（Walkthrough）:與代碼檢查很相似，也以小組位單位進(jìn)行。不同點(diǎn)是規(guī)程稍微不同，采用的缺陷檢查技術(shù)不同。 2.什么是樁模塊，驅(qū)動(dòng)模塊驅(qū)動(dòng)模塊：在測試過程中，用以代替被測試模塊的上級(jí)模塊稱為驅(qū)動(dòng)模塊。樁模塊：在測試過程中，用以代替被測試模塊的下級(jí)模塊稱為樁模塊。八軟件測試用例 1.測試用例設(shè)計(jì)概述 測試用例是為了特定目的而設(shè)計(jì)的測試數(shù)據(jù)及與之相關(guān)的測試規(guī)程的一個(gè)特定的集合，或稱為有效地發(fā)現(xiàn)軟件缺陷的最小測試執(zhí)行單元。1 測試用例的重要性；2 測試用例數(shù)與軟件規(guī)模的關(guān)系：軟件規(guī)模越大，測試用例占的比例越大。3 測試用例設(shè)計(jì)說明的書寫規(guī)范：ANSI/IEEE829-1983標(biāo)準(zhǔn)。 黑盒測試：在測試時(shí)，吧、把程序看作一個(gè)不能打開的黑盒 黑盒測試 子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口處進(jìn)行測試。 白盒測試：是一種廣泛使用的邏輯測試技術(shù)。它的對(duì)象基本白盒測試上是源程序，是以程序的內(nèi)部邏輯結(jié)構(gòu)為基礎(chǔ)的一種測試技術(shù)。 2.動(dòng)態(tài)測試【