軟工復(fù)習(xí)材料

軟件工程復(fù)習(xí)材料第1頁共8頁2.1軟件工程&軟件過程概述什么是軟件，軟件的特點軟件是在計算機系統(tǒng)支持下，能夠完成特定功能和性能的程序、數(shù)據(jù)和相關(guān)的文檔。（書本）軟件是計算機程序、規(guī)程以及運行計算機系統(tǒng)可能需要的相關(guān)文檔和數(shù)據(jù)。（課件）軟件=知識+程序+數(shù)據(jù)+文檔（書本）軟件=程序+規(guī)程+數(shù)據(jù)+文檔（課件）軟件的特點：軟件是抽象的邏輯產(chǎn)品，而不是物理產(chǎn)品。靈活性和不會磨損和老化。軟件開發(fā)更依賴于開發(fā)人員的業(yè)務(wù)素質(zhì)、智力、人員的組織、合作和管理。軟件存在潛伏錯誤，硬件錯誤一般能排除。軟件開發(fā)成后，只需對原版進行復(fù)制。軟件在使用過程中維護復(fù)雜：（1）糾錯性維護-改正運行期間發(fā)現(xiàn)的潛伏錯誤；(2)完善性維護-提高或完善軟件的性能；（3）適應(yīng)性維護-修改軟件，以適應(yīng)軟硬件環(huán)境的變化；（4）預(yù)防性維護-改進軟件未來的可維護性和可靠性。（5）軟件不會磨損和老化。什么是軟件危機，軟件危機的表現(xiàn)軟件危機是指在軟件開發(fā)和維護中所遇到的一系列嚴(yán)重的問題。軟件危機的表現(xiàn)對軟件開發(fā)成本和進度的估計常常很不準(zhǔn)確。用戶對已完成的軟件不滿意的現(xiàn)象時有發(fā)生。軟件產(chǎn)品的質(zhì)量往往是靠不住的。軟件常常是不可維護的。軟件通常沒有適當(dāng)?shù)奈臋n資料。軟件工程的定義、目標(biāo)及原則定義是：1將系統(tǒng)化的、規(guī)范化的、可量化的的方法應(yīng)用于軟件的開發(fā)、運行和維護的過程；2對1中所述方法的研究目標(biāo)：是在給定成本，進度的前提下，開發(fā)出滿足用戶或市場需求的高質(zhì)量的軟件產(chǎn)品。原則：抽象、信息隱藏、模塊化、局部化、一致性、完全性和可驗證性。軟件質(zhì)量要素產(chǎn)品轉(zhuǎn)移：可移植性、可重用性、互操作性產(chǎn)品運行：正確性、可靠性、效率、完整性、實用性產(chǎn)品校正：可維護性、靈活性、可測試性8個質(zhì)量要素：（1）正確性（2）可用性（3）可靠性（4）有效性（5）可維護性可移植性（7）安全性（8）可復(fù)用性人月神話(1)缺乏合理的時間進度是造成項目滯后的最主要原因，它比其他所有因素加起來影響還大。(2)良好的烹飪需要時間，某些任務(wù)無法在不損害結(jié)果的情況下加快速度。(3)所有的編程人員都是樂觀主義者：“一切都將運作良好”。(4)由于編程人員通過純粹的思維活動來開發(fā)，所以我們期待在實現(xiàn)過程中不會碰到困難。(5)但是，我們的構(gòu)思是有缺陷的，因此總會有bug。(6)我們圍繞成本核算的估計技術(shù)，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數(shù)量和時間是可以相互替換的。(7)在若干人員中分解任務(wù)會引發(fā)額外的溝通工作量——培訓(xùn)和相互溝通。(8)關(guān)于進度安排，我的經(jīng)驗是為1/3計劃、1/6編碼、1/4構(gòu)件測試以及1/4系統(tǒng)測試。(9)作為一個學(xué)科，我們?nèi)狈?shù)據(jù)估計。(10)因為我們對自己的估計技術(shù)不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。(11)Brook法則：向進度落后的項目中增加人手，只會使進度更加落后。(12)向軟件項目中增派人手從三個方面增加了項目必要的總體工作量：任務(wù)重新分配本身和所造成的工作中斷；培訓(xùn)新人員；額外的相互溝通。瀑布模型、快速原型、增量模型、螺旋模型、通用軟件過程模型等軟件過程模型的特點、適用范圍瀑布模型的特點：1.階段間具有順序性和依賴性2推遲實現(xiàn)的觀點3.質(zhì)量保證的觀點瀑布模型的缺點：1.各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；2.開發(fā)過程中很難響應(yīng)客戶的變更要求；3.早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴(yán)重的后果。瀑布模型的適用于：1.需求是預(yù)知的2軟件實現(xiàn)方法是成熟的3項目周期較短4.在開發(fā)的早期階段軟件需求被完整確定?？焖僭湍康模罕M早與用戶見面，減少開發(fā)風(fēng)險和需求不確定性?？焖僭托枰杆俳ㄔ煲粋€可以運行的軟件原型，以便理解和澄清問題，使開發(fā)人員與用戶達成共識。原型是軟件的一個早期可運行的版本，它反映了最終系統(tǒng)的部分重要特性?？焖僭偷娜秉c：1.原型系統(tǒng)的內(nèi)部結(jié)構(gòu)可能不好。2.開發(fā)人員需要掌握建立快速原型的開發(fā)技術(shù)和工具?？焖僭偷倪m用于：1.小型或中等規(guī)模的交互式系統(tǒng)。2.大型系統(tǒng)的某些部分，例如用戶界面3.生命周期較短的系統(tǒng)。增量模型的特點：1.能在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品。2.逐步增加產(chǎn)品功能可以使用戶有效充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一惡搞全新的軟件可能給用戶組織帶來的沖擊。增量模型的優(yōu)點：1.整個產(chǎn)品被分解成若干個構(gòu)件逐步交付，用戶可以不斷地看到所開發(fā)軟件的可運行中間版本。2.將早期增量作為原型有助于明確后期增量的需求3.降低開發(fā)風(fēng)險4.重要功能被首先交付，從而使其得到最多的測試。增量模型的缺點：1.需要軟件具備開發(fā)式的體系結(jié)構(gòu)；2.需求難以在增量實現(xiàn)之前詳細(xì)定義，因此增量與需求的準(zhǔn)確映射以及所有增量的有效集成可能會比較困難。3.容易退化為邊改方式，使軟件過程的控制失去整體性。螺旋模型的優(yōu)點：1.關(guān)注軟件的重用；2.關(guān)注早期錯誤的消除3.將質(zhì)量目標(biāo)放在首位。4.邊學(xué)習(xí)、邊建模、邊開發(fā)、邊使用、邊開進。螺旋模型的缺點：1.風(fēng)險分析需要成本，影響收益，所以只適用于大規(guī)模軟件項目；2.客戶未必能接受，所以往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)；3.需要風(fēng)險評估的經(jīng)驗，否則會帶來更大風(fēng)險。通用軟件過程模型形式化方法模型是采用形式化的數(shù)學(xué)方法將系統(tǒng)描述轉(zhuǎn)化成可執(zhí)行的程序。形式化適用：特別適合于那些對安全性、可靠性和保密性要求極高的軟件系統(tǒng)，這些系統(tǒng)需要在投入運行前進行驗證。形式化優(yōu)點:由于數(shù)學(xué)方法具有嚴(yán)密性和準(zhǔn)確性，形式化方法開發(fā)過程所交付的軟件系統(tǒng)具有較少的缺陷和較高的安全性形式化缺點：1.開發(fā)人員需要具備一定技能并經(jīng)過特殊訓(xùn)練2.形式化描述和轉(zhuǎn)換是一項費時費力的工作3.現(xiàn)實應(yīng)用的系統(tǒng)大多數(shù)是交互性強的軟件，但是這些系統(tǒng)難以用形式化方法進行描述。任務(wù)思維與過程思維思維過程包括分析、綜合、比較、抽象、概括判斷和推理等基本過程。RUP軟件過程的基本特點、階段劃分、主要工作流RUP階段劃分：1.初始階段2.細(xì)化階段3.構(gòu)造階段4.移交階段5.生產(chǎn)階段主要工作流1.業(yè)務(wù)建模工作流2.需求工作流3.設(shè)計工作流4.實現(xiàn)工作流5.驗證和確認(rèn)（V&V）工作流6.部署工作流7.配置和變更管理工作流8.項目管理工作流9.環(huán)境工作流2.2SA&OO結(jié)構(gòu)化分析方法的特點、數(shù)據(jù)流圖作用對象、類、接口、封裝、繼承、多態(tài)、消息、關(guān)聯(lián)、組合、聚合、依賴、實現(xiàn)對象是現(xiàn)實世界中個體或事物的抽象標(biāo)識，是其屬性和相關(guān)操作的封裝。類是某些對象的共同特征（屬性和操作）的標(biāo)識。繼承，類之間的繼承關(guān)系是現(xiàn)實世界中遺傳關(guān)系的直接模擬，它表示類之間的內(nèi)在聯(lián)系以及對屬性和操作的共享，即子類可以沿用父類（被繼承類）的某些特征。聚合部分與整體的關(guān)系。多態(tài)是指在父類及其子類中，對外接口的定義形式相同，卻可以對應(yīng)多種接口的實現(xiàn)形態(tài)。消息傳遞是對象與其外部世界相互關(guān)聯(lián)的唯一途徑。概念、用途、畫法：用例圖、類圖、對象圖、狀態(tài)圖、活動圖、順序圖、協(xié)作圖類的關(guān)系、用例的關(guān)系類的關(guān)系常見的關(guān)系有：繼承（Inheritance），關(guān)聯(lián)關(guān)系（Association），聚合關(guān)系（Aggregation），復(fù)合關(guān)系（Composition），依賴關(guān)系（Dependency）。用例的關(guān)系:包含關(guān)系:基本用例的行為包含了另一個用例的行為。2.3需求工程業(yè)務(wù)需求、用戶需求、功能需求和非功能需求、系統(tǒng)需求的基本概念業(yè)務(wù)需求就是系統(tǒng)目標(biāo)，它必須是業(yè)務(wù)導(dǎo)向、可度量、合理、可行的。就是說你做的東西，用戶能做什么，對用戶有什么幫助，他的價值用戶需求：是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行為，而不涉及系統(tǒng)的內(nèi)部特性。用戶需求的描述原則：應(yīng)該易于用戶的理解。一般不采用技術(shù)性很強的語言，而是采用自然語言和直觀圖形相結(jié)合的方式（用例圖、用例描述、活動圖、領(lǐng)域概念模型）進行描述。問題：自然語言表達容易含糊和不準(zhǔn)確。系統(tǒng)需求：是更加詳細(xì)地描述系統(tǒng)應(yīng)該做什么，通常包括許多不同的分析模型。（用例圖、交互圖、分析類圖、狀態(tài)圖）。系統(tǒng)需求主要是面向開發(fā)人員進行描述，是開發(fā)人員進行軟件設(shè)計的基礎(chǔ)。功能需求：描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，一般不考慮系統(tǒng)的實現(xiàn)細(xì)節(jié)。非功能需求：從各個角度對系統(tǒng)的約束和限制，反映了應(yīng)用對軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時間、數(shù)據(jù)精度、可靠性、開發(fā)過程的標(biāo)準(zhǔn)等。舉例：（1）系統(tǒng)應(yīng)在20秒之內(nèi)響應(yīng)所有的請求。（2）系統(tǒng)每周7天、每天24小時都可以使用。（3）對于一個沒有經(jīng)驗的用戶而言，經(jīng)過兩個小時的培訓(xùn)就可以使用系統(tǒng)的所有功能。需求工程的過程模型，每個環(huán)節(jié)的主要任務(wù)（1）需求工程策劃（2）需求獲?。?）需求分析（4）需求規(guī)范化（5）需求驗證（6）總結(jié)需求獲取的過程模型，每個環(huán)節(jié)的主要任務(wù)（1）定義軟件問題（2）創(chuàng)建框架用例（3）精化用例（4）評審用例模型主要項目干系人的角色及作用需求調(diào)研的常見方法、優(yōu)缺點、注意事項什么是用例，正確識別Actor及用例，用例識別的誤區(qū)用例描述了一個完整的系統(tǒng)事件流程，其重點在于參與者與系統(tǒng)之間的交互而不是內(nèi)在的系統(tǒng)活動，并對參與者產(chǎn)生有價值的可觀測結(jié)果。用例分析以參與者為中心，用例粒度以完成參與者目的為依據(jù)。框架用例的作用業(yè)務(wù)用例：業(yè)務(wù)建模階段，每個用例以能說明一件完整的事情，可以描述一項完整的業(yè)務(wù)流程。概念用例：概念建模階段，每個用例一能描述一個完整的事件流為宜，可以描述一項完整業(yè)務(wù)中的一個步驟。系統(tǒng)用例：系統(tǒng)建模階段，每個用例以能夠描述操作者與計算機的一次完整交互為宜。一個系統(tǒng)的業(yè)務(wù)用例定義在多于10個，不超過30個之間。在同一個需求階段，所有用例的粒度應(yīng)該是同一量級的。粒度選擇的問題本質(zhì)上是因為邊界認(rèn)定不同而產(chǎn)生的。構(gòu)建完整用例的步驟（1）重新研究用例名稱、用例目標(biāo)、標(biāo)識所有執(zhí)行者（2）標(biāo)識觸發(fā)條件和前置條件（3）描述或精化原有的基本交互動作序列（4）提煉并描述擴展的交互動作序列（5）描述用戶與系統(tǒng)交互過程中傳遞的信息項（6）標(biāo)識后置條件可行性分析的主要關(guān)注點需求分析的過程模型,每個環(huán)節(jié)的主要任務(wù)(1)需求優(yōu)先級分析為每項需求確定優(yōu)先級（功能性需求，非功能需求）安排待分析用例的優(yōu)先次序據(jù)此編排調(diào)整軟件開發(fā)計劃對重要、緊迫的需求（給予更多關(guān)注，分配更多的開發(fā)資源，確保其優(yōu)先實現(xiàn)，確保實現(xiàn)質(zhì)量）(2)用例分析不斷加深理解用例模型，更深入理解軟件需求用更精確uml語言表述需求（刪除需求的模糊性，檢查需求的一致性，消除需求的冗余性）引入用例功能的邏輯設(shè)計方案（檢查需求的可實現(xiàn)性，識別需求的實現(xiàn)風(fēng)險，提高需求的可驗證性）(3)構(gòu)建快速原型糾結(jié)的問題（自然語言可能存在的模糊性、不一致性。UML語言用戶理解可能有難度，用戶說不出心中所想，開發(fā)人員解釋不清系統(tǒng)模樣）(4)分析模型評審評審用例模型（正確性、完全性、可行性）需求優(yōu)先級概念什么是分析模型，分析模型的作用領(lǐng)域概念模型精化領(lǐng)域概念模型的方法：需求獲取，領(lǐng)域模型，用例描述，術(shù)語詞典。領(lǐng)域概念模型：發(fā)現(xiàn)表象下的本源，找出最基本的對象及相互間關(guān)系，描繪出它們?nèi)绾谓换ザ纬梢治龅膯栴}領(lǐng)域。領(lǐng)域就是分析問題時將整體分解以后的相對獨立的部分。針對項目成敗影響最為關(guān)鍵的部分建模（針對核心業(yè)務(wù)建模，適用二八原則。針對系統(tǒng)難點建模，關(guān)注非功能性需求，特殊應(yīng)用環(huán)境，客戶特殊要求。）建立領(lǐng)域概念模型必須首先標(biāo)識關(guān)鍵概念，來源包括：需求描述與用例說明，業(yè)務(wù)領(lǐng)域中的相關(guān)規(guī)范、標(biāo)準(zhǔn)和術(shù)語定義，反映業(yè)務(wù)領(lǐng)域知識的既往經(jīng)驗。UML類圖是表示領(lǐng)域概念模型的適當(dāng)機制。邊界類、實體類、控制類的概念，如何識別邊界類、實體類、控制類邊界類：描述外部的參與者與系統(tǒng)之間的交互?？刂祁悾好枋鲆粋€用例所具有的事件流控制行為。實體類：描述必須存貯的信息及其相關(guān)行為。識別邊界類應(yīng)當(dāng)注意的問題:邊界類應(yīng)關(guān)注于參與者與用例之間交互的信息或者相應(yīng)的事件，不要描述窗口組件等界面的組成元素。在分析階段，力求使用用戶的術(shù)語描述界面。邊界類實例的生命周期并不僅限于用例的事件流，如果兩個用例同時與一個參與者交互，那么它們有可能會公用一個邊界類（如聽課，聽音樂），以便增加邊界類的復(fù)用性。識別控制類當(dāng)用例比較復(fù)雜時，特別是產(chǎn)生分支事件流的情況下（一個用例可以有多個控制類，每個類負(fù)責(zé)用例的某項子功能）在某些情況下，用例事件流的邏輯結(jié)構(gòu)十分簡單，這是沒有必要使用控制類，邊界類可以實現(xiàn)用例的行為。如果不同用例包含的任務(wù)間存在著比較密切的聯(lián)系，則這些用例可以使用一個控制類，其目的是復(fù)用相似部分以便降低復(fù)雜性。通常情況下，應(yīng)該按照一個用例對應(yīng)一個控制類的方法識別出多個控制類，再分析這些控制類找出它們之間的共同之處。識別實體類實體類通常是用例中的參與對象，對應(yīng)著現(xiàn)實世界中的“事物”需要開發(fā)人員進一步理解應(yīng)用領(lǐng)域來源于用例描述、詞匯表、領(lǐng)域概念模型是具有持久意義的信息項軟件需求規(guī)格說明的內(nèi)容、作用。需求驗證的作用、要點需求變化的理解、需求變更控制過程2.4軟件設(shè)計軟件設(shè)計基本原則：抽象與逐步求精、模塊化、信息隱藏、關(guān)注點分離耦合度和內(nèi)聚性的概念耦合度：表示兩個子系統(tǒng)（或類之間的關(guān)聯(lián)程度）內(nèi)聚性：是子系統(tǒng)內(nèi)部的相關(guān)程度耦合：表示兩個子系統(tǒng)（或類）之間的關(guān)聯(lián)程度。當(dāng)一個子系統(tǒng)（或類）發(fā)生變化時對另一個子系統(tǒng)（或類）的影響很小，則稱它們是松散耦合的；反之，如果變化的影響很大時，則稱它們是緊密耦合的。塊間聯(lián)系的大小可從三個方面衡量（方式、作用、數(shù)據(jù)）耦合性幾種類型（內(nèi)容耦合、公共耦合、控制耦合、復(fù)合耦合、數(shù)據(jù)耦合）內(nèi)聚內(nèi)聚性：是子系統(tǒng)內(nèi)部的相關(guān)程度。高內(nèi)聚：子系統(tǒng)中彼此相關(guān)的多個對象執(zhí)行類似的任務(wù)。低內(nèi)聚：子系統(tǒng)內(nèi)的多個對象彼此不相關(guān)時。高內(nèi)聚的方法：做且僅做一件事，這會很容易理解與維護。高內(nèi)聚的類：表示且僅表示一種類型的對象。偶然型，邏輯型，瞬時型，通信型，順序型，功能型（內(nèi)聚性弱到強）軟件設(shè)計的過程模型、每個環(huán)節(jié)的主要任務(wù)單一職責(zé)、開閉原則、里氏互換、依賴反轉(zhuǎn)、接口隔離、迪米特法則單一職責(zé)：可以看做是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申里氏互換：任何基類出現(xiàn)的地方，子類一定可以出現(xiàn)軟件體系結(jié)構(gòu)定義軟件體系結(jié)構(gòu)主要包括哪些視圖，每種視圖的作用邏輯視圖、開發(fā)視圖、物理視圖、運行視圖、數(shù)據(jù)視圖。包的劃分原則、包的依賴及消除軟件構(gòu)件的概念體系結(jié)構(gòu)設(shè)計的過程模型、每個環(huán)節(jié)的主要任務(wù)3簡答題（35分）3.1軟件工程&軟件過程概述關(guān)于人月神話的一些思考。掌握常見幾種軟件生命周期的特點、適用范圍；能夠針對給定的一些軟件項目，選擇相應(yīng)的生命周期模型，并簡要陳述理由。辯證看待程序語言、開發(fā)工具、編程技巧以及軟件工程方法在成功進行軟件開發(fā)中所起的作用。麥當(dāng)勞薯條生產(chǎn)的思考。3.2軟件需求關(guān)于李大嘴做月餅的思考。理解軟件需求的質(zhì)量：正確性、無二義性、完整性、可驗證性、一致性、可修改性、可跟蹤性；能夠針對給定的需求陳述語句，判斷需求描述是否滿足質(zhì)量要求。能夠識別錯誤的用例描述，并予以改正。能夠識別給定用例圖的錯誤。理解軟件需求在軟件開發(fā)中的重要作用。理解軟件開發(fā)中需求管理困難的原因。理解軟件需求確認(rèn)的內(nèi)涵及作用。理解軟件需求變更控制的基本策略。需求工程的過程模型中主要包括哪些設(shè)計活動？3.3軟件設(shè)計能夠識別類之間的關(guān)系并予繪制。如何消除包的依賴關(guān)系理解軟件結(jié)構(gòu)的形態(tài)要求軟件設(shè)計的過程模型中主要包括哪些設(shè)計活動？軟件分析設(shè)計的思想原則用戶需求遠(yuǎn)比技術(shù)重要需求其實很少改變，改變的是對需求的理解接受變化不要低估軟件規(guī)模的需求在軟件設(shè)計中沒有捷徑可以走任何設(shè)計模式、體系結(jié)構(gòu)都有優(yōu)缺點溝通對設(shè)計質(zhì)量的的提高同樣重