軟件工程作業(yè)全部答案.doc

1.3 請讀者詳細解釋軟件的定義和程序的定義。軟件的定義：軟件 = 程序 + 數(shù)據(jù) + 文檔。這里的程序是指程序系統(tǒng)。這里的數(shù)據(jù)不僅包括初始化數(shù)據(jù)、測試數(shù)據(jù)，而且包括研發(fā)數(shù)據(jù)、運行數(shù)據(jù)、維護數(shù)據(jù)，也包括軟件企業(yè)積累的項目工程數(shù)據(jù)和項目管理數(shù)據(jù)中的大量決策原始記錄數(shù)據(jù)。這里的文檔指的是軟件開發(fā)過程中的分析、設計、實現(xiàn)、測試、維護文檔、管理文檔。現(xiàn)在有一種新提法正在引起關注，這種提法是：軟件 = 知識 + 程序 + 數(shù)據(jù) + 文檔。程序是計算機為完成特定任務而執(zhí)行的指令的有序集合。從應用的角度可理解為：面向過程的程序 = 算法 + 數(shù)據(jù)結構面向?qū)ο蟮某绦?= 對象 + 信息面向構件的程序 = 構件 + 構架。1.5 讀者同意“四種開發(fā)方法”和“五個面向理論”的提法嗎？為什么？ “四種開發(fā)方法”是指“面向過程的方法、面向?qū)ο蟮姆椒?、面向?shù)據(jù)的方法、形式化方法”，面向過程的方法來源于面向過程的程序設計，面向?qū)ο蟮姆椒▉碓从诿嫦驅(qū)ο蟮某绦蛟O計，面向數(shù)據(jù)的方法就是面向元數(shù)據(jù)的方法，它來源于關系數(shù)據(jù)庫程序設計，形式化方法來源于離散數(shù)學中的集合運算和邏輯運算。四種方法各適用于不同的場合，各有優(yōu)缺點，互相促進，構成一個開發(fā)方法論的多極化世界?！拔鍌€面向理論”是指“面向流程分析、面向數(shù)據(jù)設計、面向?qū)ο髮崿F(xiàn)、面向功能測試、面向過程管理”，它是在綜合“四種開發(fā)方法”各自的優(yōu)點之后提出的軟件工程實施理論，是對前者的繼承與發(fā)展?？傊?，上述提法既精彩又實用。2.1 為什么要選擇軟件開發(fā)模型？軟件開發(fā)模型與軟件生存周期有什么關系？因為軟件開發(fā)模型是軟件工程研究的四大內(nèi)容之一，它雖然不是軟件工程研究的重點，但是在宏觀上特別重要。軟件公司的項目組在開發(fā)一個大項目或產(chǎn)品時，首先在技術上必須選擇一個開發(fā)模型，使開發(fā)模型非常適合這個項目或產(chǎn)品的生存周期；隨后通過對生存周期的裁減，來給出適合與本項目或產(chǎn)品的軟件生存周期定義。軟件的開發(fā)模型與軟件生存周期有關：不同的開發(fā)模型，可能對應著不同的生存周期。生存周期不同，該軟件的開發(fā)階段劃分、評審次數(shù)、基線標準都有所不同，甚至維護方法都有所區(qū)別。 2.2簡述瀑布模型、增量模型、迭代模型、原型模型的優(yōu)缺點。答案：表 8-2 開發(fā)模型優(yōu)缺點：序 號模 型 名 稱優(yōu) 點缺 點1瀑布模型簡單好學逆轉(zhuǎn)性差2增量模型可以分階段提交有時用戶不同意3迭代模型克服瀑布模型的缺點對開發(fā)人員要求高4原型模型開發(fā)速度快不利于創(chuàng)新4.2需求分析的目的是什么？需求分析的難點在哪里？軟件需求分析，其目的是用于說明軟件產(chǎn)品或軟件項目需要滿足的條件和限制。在軟件工程項目中首先要獲取用戶的需求，通過對軟件需要的提取、分析、文檔化以及驗證，為進一步的設計和實現(xiàn)提供依據(jù)。需求分析的難點是：在系統(tǒng)的功能、性能和接口方面，開發(fā)者與客戶達成完全一致的需求，讓客戶最終簽字確認，并保證在項目驗收前，需求相對穩(wěn)定不變。萬一需求有點變化，雙方必須履行“需求變更管理程序”，而變更管理程序在簽訂合同時已經(jīng)做了規(guī)定。要知道，合同是具有法律效力的。4.6解釋術語：元數(shù)據(jù)、實體、中間數(shù)據(jù)。元數(shù)據(jù)是組織數(shù)據(jù)的數(shù)據(jù)，描述數(shù)據(jù)的數(shù)據(jù)，關于數(shù)據(jù)的數(shù)據(jù)。實體（指實體集或?qū)嶓w型），是一組相關元數(shù)據(jù)的集合。中間數(shù)據(jù)是組織統(tǒng)計數(shù)據(jù)的數(shù)據(jù)，描述統(tǒng)計數(shù)據(jù)的數(shù)據(jù)，關于統(tǒng)計數(shù)據(jù)的數(shù)據(jù)。5.13軟件開發(fā)計劃書應包括哪些內(nèi)容？軟件開發(fā)計劃書是軟件策劃的輸出文檔，它包括如下10個方面的內(nèi)容：（1）軟件項目的目的、范圍、目標和對象。（2）軟件生存周期的選擇與裁剪。（3）確定軟件開發(fā)和維護的規(guī)范、方法和標準。（4）軟件工作產(chǎn)品的確定。（5）對工作產(chǎn)品規(guī)模的估計。（6）對工作量和成本的估計。（7）關鍵計算機資源的估計和使用情況。（8）項目的進度、里程碑和評審計劃。（9）風險的識別和評估。（10）項目工程設施和工具的計劃。6.1 軟件設計的輸入輸出是什么？ 對于簽訂合同的項目，軟件設計的輸入時用戶需求報告/需求規(guī)格說明書，輸出是概要設計說明書和詳細設計說明書。對于立項的項目，軟件設計的輸入時需求規(guī)格說明書，輸出是概要設計說明書和詳細設計說明書。6.8為什么軟件設計要遵守“抽象，分解與模塊化，低藕合高內(nèi)聚，封裝，接口和實現(xiàn)分離”的設計原理？當前，軟件設計過程仍然是一個非確定性過程，經(jīng)常是摸著石頭過河。不同的設計人員對相同的問題可以得到不同的設計方案。由于設計過程是一個啟發(fā)式過程，不是確定性過程，因此不可能得到一個完全預測的結果。為此，只能規(guī)定一些設計原理或原則，供設計人員共同遵守。這些原理或原則是“抽象，分解與模塊化，低藕合高內(nèi)聚，封裝，接口和實現(xiàn)分離”。7.2請簡述UML的宏觀建模思想和微觀建模思想。UML的宏觀建模思想是：以“個模型”和“張視圖”為綱，以“種圖”為目，建立系統(tǒng)的UML模型。“個模型”包括：業(yè)務模型、領域模型、用例模型、分析模型、設計模型、過程模型、部署模型、實現(xiàn)模型、測試模型。“種圖”包括：類圖、對象圖、用例圖、順序圖、協(xié)作圖、狀態(tài)圖、活動圖、構件圖、實施圖。 “張視圖”包括：用例視圖、設計視圖、進程視圖、實現(xiàn)視圖、實施視圖。UML的微觀建模思想是：基本結構模型、高級結構模型、基本行為模型、高級行為模型、體系結構模型（5個方面，66個微觀建模）?；窘Y構模型包括：對類建模、對關系建模、對公共機制建模、對圖建模、對類圖建模。高級結構模型包括：對類的語義建模,對關系網(wǎng)絡建模,對接口、類型和角色建模,成組的元素建模,對體系結構視圖建模,對具體實例、原型實例建模,對對象結構建模?；拘袨槟Ｐ桶ǎ簩换ソ?、對用例建模、對用例圖建模、對交互圖建模、對活動圖。高級行為模型包括：對信號族、異常情況建模、對狀態(tài)機建模、對進程和線程建模、對時間空間建模、對狀態(tài)圖建模。體系結構模型包括：對構件建模、對實施建模、對協(xié)作建模、對模式和框架建模、對構件圖建模、對實施圖建模、對系統(tǒng)建模。一般而言，人們最常用的是建立系統(tǒng)的用例圖、類圖和順序圖。7.8 請說明“三個模型”的定義，以及三者之間的關系。功能模型是描述系統(tǒng)能做什么，即對系統(tǒng)的功能、性能、接口和界面進行定義。業(yè)務模型是描述系統(tǒng)在何時、何地、由何角色、按什么業(yè)務規(guī)則去做，以及做的步驟或流程，即對系統(tǒng)的操作流程進行定義。數(shù)據(jù)模型是描述系統(tǒng)工作前的數(shù)據(jù)來自何處，工作中的數(shù)據(jù)存什么地方，工作后的數(shù)據(jù)放到何處，以及這些數(shù)據(jù)之間的關聯(lián)，即對系統(tǒng)的數(shù)據(jù)結構進行定義。功能模型和業(yè)務模型是在需求分析時建模，是兩個基本點。數(shù)據(jù)模型是一個中心，在設計時建模。功能模型和業(yè)務模型給數(shù)據(jù)模型提供數(shù)據(jù)與維護數(shù)據(jù)，數(shù)據(jù)模型支持功能模型和業(yè)務模型的正常運行。通常，數(shù)據(jù)模型建模用Power Designer，ER win或Oracle Designer工具實現(xiàn)；功能模型用功能點列表（或用況圖）表示；業(yè)務模型用自然語言加上流程圖（或順序圖）表示8.1 軟件實現(xiàn)的輸入/輸出是什么？軟件實現(xiàn)的輸入是詳細設計說明書，輸出是源程序、目標程序以及用戶指南。8.5 編碼技術包括哪些內(nèi)容？ 圖8-4顯示編碼技術包括的內(nèi)容： 編碼技術 編碼標準 代碼布局 實體命名 錯誤處理代碼重構 成對編程9.4試闡述軟件測試V模型的思想、不足之處和改進方法？軟件測試V模型的基本思想，如圖8-5所示，我們可以初步了解，左側是開發(fā)階段，右側是測試階段。開發(fā)階段先從定義軟件需求開始，然后要把這些需求不斷的轉(zhuǎn)換到概要設計和詳細設計中去，最后形成程序代碼。測試階段是在代碼編寫完成以后，先作單元測試開始，然后是集成測試、系統(tǒng)測試和驗收測試。圖8-5 軟件測試V模型對V模型的進一步闡述是：當需求分析完成后，驗收測試計劃也應完成。當概要設計完成后，系統(tǒng)測試計劃也應完成。當詳細設計完成后，集成測試計劃也應完成。當編碼完成后，單元測試計劃也應完成。可見，V模型提高了測試的時間與地位。以上的測試V模型，好像只適合于瀑布開發(fā)模型，若是迭代開發(fā)模型，就顯得不足了。實際工作中，V模型只是提高了測試工作的地位，具體測試方法，仍然是黑白兩個盒子法。9.6 試說出黑盒測試和白盒測試的區(qū)別和聯(lián)系？黑盒測試又稱功能測試。在這里，盒子指的是被測試的軟件，“黑盒”就是只知道被測試軟件的外部情況，主要是界面和接口，被測試軟件的內(nèi)部邏輯結構和數(shù)據(jù)結構，對測試人員來說是不可見的，主要關注被測試軟件的功能實現(xiàn)。白盒測試就是對程序執(zhí)行路徑的測試，又叫做玻璃盒測（Glass Box Testing）、透明盒測試（Clea