軟件工程知識(shí)點(diǎn)匯總

軟件工程學(xué)問(wèn)點(diǎn)匯總軟件工程、軟件工程方法學(xué)：三要素1?1軟件工程：01應(yīng)用系統(tǒng)化的、標(biāo)準(zhǔn)化的、可度量的方法來(lái)開(kāi)發(fā)、運(yùn)行和維護(hù)軟件，馬上工程應(yīng)用到軟件；02對(duì)。的各種方法的爭(zhēng)論1.2軟件工程是一門(mén)爭(zhēng)論用工程化方法構(gòu)建和維護(hù)有效的有用的和高質(zhì)量的軟件的學(xué)科1?3件工程方法和工具綜合起來(lái)以到達(dá)合理、準(zhǔn)時(shí)地進(jìn)行計(jì)算機(jī)軟件開(kāi)發(fā)這一目的軟件工程的原則包括：模塊化原則、信息隱蔽原則、抽象化原則、模塊獨(dú)立原則〔合〕、依靠倒轉(zhuǎn)原則、開(kāi)閉原則等1模塊化原則：指解決一個(gè)簡(jiǎn)單問(wèn)題時(shí)自頂向下逐層把軟件系統(tǒng)劃分為假設(shè)干模塊的過(guò)塊過(guò)小會(huì)導(dǎo)致整個(gè)系統(tǒng)表示過(guò)于簡(jiǎn)單，不利于掌握系統(tǒng)的簡(jiǎn)單性。單。向下，逐層細(xì)化的方法掌握軟件開(kāi)發(fā)過(guò)程的簡(jiǎn)單性。2.4〔即：高內(nèi)聚低耦合〕依靠倒轉(zhuǎn)原則：抽象不應(yīng)當(dāng)依靠于細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依靠于抽象。改是封閉的。務(wù)、特點(diǎn)、Z5意圖；軟件開(kāi)發(fā)模型〔也稱為軟件過(guò)程模型〕架3.1瀑布模型〔又稱線性模型〕:3.1.1工作原理：規(guī)定了它們自上而下、相互連接的固定次序，如同瀑布流水，逐級(jí)下落。前一階段的工作成果是后一階段工作開(kāi)頭的根底 所以，每個(gè)階段都必需交階段的工作階段：打算時(shí)期：?jiǎn)栴}定義、可行性爭(zhēng)論開(kāi)發(fā)時(shí)期：需求分析、設(shè)計(jì)、編碼、測(cè)試運(yùn)行時(shí)期：運(yùn)行和維護(hù)1.3各階段任務(wù)：方面，對(duì)軟件系統(tǒng)給出完整、準(zhǔn)確、具體的描述，用于確定軟件規(guī)格。分的功能與構(gòu)造的具體設(shè)計(jì)。編碼。通過(guò)程序單元測(cè)試，驗(yàn)證其是否滿足設(shè)計(jì)標(biāo)準(zhǔn)。進(jìn)展系統(tǒng)測(cè)試。測(cè)試完成后即交付用戶使用。件的錯(cuò)誤，就要修改軟件，可能會(huì)重復(fù)上述某個(gè)或多個(gè)階段的活動(dòng)。3.1.4 特點(diǎn)：①挨次性、依靠性：下一階段依靠上一階段的完成。遲進(jìn)展。③ 質(zhì)量保證：文檔完整、文檔評(píng)審，避開(kāi)錯(cuò)誤積存與放大效應(yīng)。3.1.5不意圖：快速原型3.2.1工作原理：快速原型是利用原型關(guān)心軟件開(kāi)發(fā)的一種思想。經(jīng)過(guò)簡(jiǎn)潔快速分建立需求規(guī)格原型法：先構(gòu)造一個(gè)功能簡(jiǎn)潔而質(zhì)量要求不高的模型系統(tǒng)，針對(duì)這個(gè)模型系統(tǒng)反復(fù)的進(jìn)展分析修改，從而形成較好的設(shè)計(jì)思直至全部性能全部滿足，此時(shí)原型模型也就是最終的產(chǎn)品。2.2統(tǒng)的根本要求，依據(jù)原型所要表達(dá)的特性〔形式等〕，描述根本需求規(guī)格說(shuō)明，以滿足開(kāi)發(fā)圓形的需要。要特性快速構(gòu)造一個(gè)可運(yùn)行的系統(tǒng)。段，目的是驗(yàn)證原型的正確程度，進(jìn)而開(kāi)發(fā)的并修改原有的需求。型。3.2.3特點(diǎn)1 增加了軟件開(kāi)發(fā)人員和用戶對(duì)系統(tǒng)需求的理解， 便于將用戶模糊的功能需求明確化為用戶供給了一種強(qiáng)有力的學(xué)習(xí)手段易于確定系統(tǒng)的性能，是理解和確定軟件需求規(guī)格說(shuō)明的良好工具軟件開(kāi)發(fā)供給一種完整、敏捷、近似動(dòng)態(tài)的需求規(guī)格說(shuō)明方法。3.2.4 示意圖噴泉模型3.3.13.3.2階段3.3.3每階段任務(wù)3.3.4之間沒(méi)有明顯的界限。3.5示意圖1移交階段：把開(kāi)發(fā)出的產(chǎn)品提交給用戶使用各階段功能：?jiǎn)栴}定義可行性爭(zhēng)論能夠解決。②階段性成果《工程可行性報(bào)告》需求分析階段戶對(duì)系統(tǒng)的具體要求。②階段性成果《需求規(guī)格說(shuō)明書(shū)》、數(shù)據(jù)字典、數(shù)據(jù)流圖(DFD)概要設(shè)計(jì)階段需求分析階段得到的規(guī)律模型來(lái)設(shè)計(jì)系統(tǒng)的物理模型②階段性成果《概要設(shè)計(jì)說(shuō)明書(shū)》具體設(shè)計(jì)階段①設(shè)計(jì)每個(gè)模塊的算法，確定每一模塊使用的數(shù)據(jù)構(gòu)造，確定模塊接口的細(xì)節(jié)，為每一個(gè)模塊設(shè)計(jì)一個(gè)測(cè)試用例，編寫(xiě)具體設(shè)計(jì)說(shuō)明書(shū)②《軟件具體設(shè)計(jì)》文檔編碼和單元測(cè)試系統(tǒng)測(cè)試軟件維護(hù)階段各階段所涉及的內(nèi)容〔文檔、工具、圖〕構(gòu)造化方法：生命周期中各階段任務(wù)獵取用戶需求、畫(huà)數(shù)據(jù)流圖、數(shù)據(jù)字典可行性分析、需求分析、設(shè)計(jì)〔概要設(shè)計(jì)+具體設(shè)計(jì)〕、測(cè)試、維護(hù)面對(duì)對(duì)象方法：核心概念、模型7.1面對(duì)對(duì)象中的根本概念：對(duì)象：代表了一個(gè)現(xiàn)實(shí)的或虛構(gòu)的實(shí)體類：對(duì)具有一樣數(shù)據(jù)和性：一個(gè)名字具有多種語(yǔ)義消息：對(duì)象間在交互中所傳送的通訊信息關(guān)聯(lián)：對(duì)象之間所存在的聯(lián)系7.2模型對(duì)象模型：即查找問(wèn)題域中的對(duì)象，從對(duì)象中抽象出類的定義，識(shí)別對(duì)象的內(nèi)部特型常常會(huì)經(jīng)過(guò)屢次必要的修改。003種形式的模型：對(duì)象模型描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)；動(dòng)態(tài)模內(nèi)容，相互影響、相互制約，有機(jī)地結(jié)合在一起，全面地表達(dá)對(duì)目標(biāo)系統(tǒng)的需求。對(duì)象模型表示靜態(tài)的、構(gòu)造化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。面對(duì)對(duì)象方法強(qiáng)調(diào)圍繞對(duì)象而不是功能來(lái)構(gòu)造系統(tǒng)。對(duì)象模型為建立動(dòng)態(tài)模型和功能模型，供給了實(shí)質(zhì)性的框架。1997年110MGUML1。1作為基于面對(duì)對(duì)象技術(shù)的標(biāo)準(zhǔn)建模語(yǔ)言。通常，UML的類圖來(lái)建立對(duì)象模型。在UML中術(shù)語(yǔ)“類”的實(shí)際含義是，“一個(gè)類及屬于該類的對(duì)象”狀態(tài)模型表示瞬時(shí)的、行為化的系統(tǒng)的“掌握”性質(zhì)，它規(guī)定了對(duì)象模型中的對(duì)象的合法變化序列。密不行分，一個(gè)大事隔開(kāi)兩個(gè)狀態(tài)，一個(gè)狀態(tài)隔開(kāi)兩個(gè)大事。大事表示時(shí)刻，狀態(tài)表示時(shí)間間隔。UML中用狀態(tài)圖來(lái)描繪對(duì)象的狀態(tài)、觸發(fā)狀態(tài)轉(zhuǎn)換的大事及對(duì)象的行為。每個(gè)類的動(dòng)態(tài)行態(tài)模型是基于大事共享而相互關(guān)聯(lián)的一組狀態(tài)圖的集合。映了用戶對(duì)目標(biāo)系統(tǒng)的需求。通常，功能模型由一組數(shù)據(jù)流圖組成。在00方法中，數(shù)據(jù)流圖遠(yuǎn)不自己的設(shè)計(jì)。UML中供給的用例圖也是進(jìn)展需求分析和建立功能模型的強(qiáng)有力工具。UML中把〔或每類〕o面對(duì)對(duì)象方法、UML獵取用戶需求、畫(huà)用例圖、對(duì)象模型、面對(duì)對(duì)象的方法

UML中的關(guān)系分析文檔包括問(wèn)題需求的陳述、對(duì)象模型、動(dòng)態(tài)模型和功能模型。系統(tǒng)設(shè)計(jì)：結(jié)合問(wèn)題域的學(xué)問(wèn)和目標(biāo)系統(tǒng)的體系構(gòu)造，將目標(biāo)系統(tǒng)分解為子系統(tǒng)，高層次的決策策略?；钚院涂蓴U(kuò)展性。:統(tǒng)一建模語(yǔ)言〔UML是一個(gè)通用的可視化建模語(yǔ)言，用于對(duì)軟件進(jìn)展描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)產(chǎn)品的文檔構(gòu)和動(dòng)態(tài)行為獵取用戶需求

。UML描述了一個(gè)系統(tǒng)的靜態(tài)結(jié)與用戶進(jìn)展充分溝通，了解用戶對(duì)軟件的需求；識(shí)別對(duì)象集合及對(duì)象間的關(guān)系；定義類〔包括屬性和操作〕并建立類間的層次關(guān)系；建立模型來(lái)表示對(duì)象之間的關(guān)系及行為特性。他模型建立、構(gòu)造設(shè)計(jì)、實(shí)現(xiàn)及測(cè)試工作等供給依據(jù)。一個(gè)用例模型是由假設(shè)干用例圖組成的的關(guān)系等工作，其中查找執(zhí)行者和用例是用例建模的關(guān)鍵。供給了實(shí)質(zhì)性的框架。通常，使用UML的類圖來(lái)建立對(duì)象模型。在UML中術(shù)語(yǔ)“類”的實(shí)際含義是，“一個(gè)類及屬于該類的對(duì)象”關(guān)系：測(cè)試：黑盒、白盒設(shè)計(jì)測(cè)試用例9.1白盒測(cè)試〔構(gòu)造測(cè)試、規(guī)律驅(qū)動(dòng)測(cè)試〕:9.1.1執(zhí)行一次推斷掩蓋：每個(gè)推斷至少都獲得一次“真”值和“假”值9.1.3條件掩蓋：每個(gè)推斷中的條件可能的取值至少被執(zhí)行一次9.1.4的內(nèi)部推斷式的真假值分支也要被執(zhí)行一遍9.1.5執(zhí)行一遍9.1.6路徑掩蓋：掩蓋程序中全部可能的路徑9.1.7六種規(guī)律掩蓋從弱到強(qiáng)的排列挨次9.2黑盒測(cè)試9.2.1等價(jià)類劃分：有效等價(jià)類和無(wú)效等價(jià)類9.2 2邊界值分析軟件工程治理：工程治理、五大過(guò)程、九大學(xué)問(wèn)領(lǐng)域、工程三角形工程治理：是為完成一個(gè)預(yù)定的目標(biāo)，而對(duì)任務(wù)和資源進(jìn)展規(guī)劃、組織和治理的程序工程三角形任務(wù)所需的工時(shí)。工程治理的五大過(guò)程：?jiǎn)?dòng)過(guò)程、打算過(guò)程、實(shí)施過(guò)程、掌握過(guò)程、收尾過(guò)程項(xiàng)冃治理的九選購(gòu)治理、綜合治理配置治理：配置治理、配置治理項(xiàng)、基線、里程碑O配置治理項(xiàng)：1。計(jì)算機(jī)程序--源代碼和可執(zhí)行程序2o描述計(jì)算機(jī)程序的文檔-一供技術(shù)人員或用戶使用3數(shù)據(jù)-一程序內(nèi)包含的或在程序外的。。。每個(gè)配置項(xiàng)的主要屬性知名稱、標(biāo)識(shí)符、文件狀態(tài)、版本、作者、口期等O基線：是一組配置項(xiàng)，這些配置項(xiàng)不能被任憑修改和變更?；€是軟件生存期中各開(kāi)發(fā)階段末尾的特定點(diǎn)，又稱里程碑。軟件開(kāi)發(fā)各階段的基線：構(gòu)造化方法與面對(duì)對(duì)象方法的比較：根本思想；分階段比較構(gòu)造化方法：根本掌握構(gòu)造組成。決問(wèn)題，保證軟件系統(tǒng)的穩(wěn)定性和可復(fù)用性以及良好的維護(hù)性。兩種方法的比較：應(yīng)。面對(duì)對(duì)象方法，對(duì)于需求不能預(yù)先確定的系統(tǒng)的開(kāi)發(fā)，可承受面對(duì)對(duì)象方法結(jié)合，這樣就能夠結(jié)合面對(duì)對(duì)象方法所具有的穩(wěn)定性好、可復(fù)用性好和可維護(hù)性好的特點(diǎn)。需求分析階段：構(gòu)造化方法：承受自頂向下功能分解的方法，強(qiáng)調(diào)規(guī)律功能而不是實(shí)現(xiàn)功能的具體方法，使用圖形進(jìn)展系統(tǒng)分析并表達(dá)分析的結(jié)果 --數(shù)據(jù)流圖，使用構(gòu)造的簡(jiǎn)潔、準(zhǔn)確、可理解的正確模型。最核心的。大型簡(jiǎn)單的軟件工程的開(kāi)發(fā)練習(xí)題：看書(shū)上實(shí)例A,理解RUP過(guò)程試爭(zhēng)論RUP過(guò)程的優(yōu)缺點(diǎn)RUP過(guò)程主要適用于何種工程？同？這種差異帶來(lái)了什么后果？為什么說(shuō)廣州本田牌汽車(chē)是小汽車(chē)類的特化，而發(fā)動(dòng)機(jī)不是小汽車(chē)類的特化？什么是對(duì)象？它與傳統(tǒng)的數(shù)據(jù)有何區(qū)分？試用面對(duì)對(duì)象分析方法設(shè)計(jì)下述程序：在顯示器屏幕上圓心坐標(biāo)為〔100,100〕的位置畫(huà)一個(gè)半徑為40的圓，在圓心坐標(biāo)為〔200,300〕20的圓，在圓心坐標(biāo)為〔400,150〕的位置畫(huà)一條3012050.9思考題1響應(yīng)。是既正確又不行靠思考題2、為什么在開(kāi)發(fā)軟件的過(guò)程中變化既是必要的又是不行避開(kāi)的？為什么必需進(jìn)展適應(yīng)，在必需變化時(shí)削減所需花費(fèi)的工作量，綜上所述，進(jìn)展配置治理是格外必要的3、某些軟件工程師不同意“目前國(guó)外很多軟件開(kāi)發(fā)組織把60%以上的人力用于維護(hù)已有的軟件”的說(shuō)法。他們爭(zhēng)論說(shuō)：“我并沒(méi)有花費(fèi)我的60%的時(shí)間去改正我所開(kāi)發(fā)的程序中的錯(cuò)誤”o請(qǐng)問(wèn)，你對(duì)上述爭(zhēng)論有何看法？答軟件維護(hù)并非僅僅是改正程序中的錯(cuò)誤它還包括適應(yīng)性維護(hù)完善性維護(hù)和預(yù)防性維護(hù)。糾錯(cuò)性維護(hù)只占維護(hù)活動(dòng)總量的 1/5,“目前國(guó)外很多軟件開(kāi)發(fā)組織把60%以上的人力用于維護(hù)已有的軟件”，指的是軟件開(kāi)發(fā)組織內(nèi)人力安排的整體狀況。至于具體到軟件組織內(nèi)的每一位工程師，則分工各不一樣?！矊Ｂ毦S護(hù)、專職開(kāi)發(fā)、兼職維護(hù)和開(kāi)發(fā)〕軟件維護(hù)人叫并非只負(fù)責(zé)維護(hù)自己開(kāi)發(fā)的程序，一名維護(hù)人員思考題4、假設(shè)你的任務(wù)是對(duì)一個(gè)已有的軟件做重大修改，而且只允許你從下述文檔中選取兩份：〔1〕程序的規(guī)格說(shuō)明〔2〕程序的具體設(shè)計(jì)結(jié)果〔自然語(yǔ)言描述加上某種設(shè)計(jì)工具表示〕〔3〕源程序清單〔其中有適當(dāng)數(shù)量的注釋〕你將選取哪兩份文檔？為什么這樣選??？答：“對(duì)件的體系構(gòu)造。規(guī)格說(shuō)明書(shū)描述了系統(tǒng)的數(shù)據(jù)要求、功能需求、性能需求、牢靠性、可用性、特別處理、接口需求、約束等內(nèi)容。對(duì)了解系統(tǒng)的總體狀況很重要。因此在對(duì)已有軟件做重大修改之前，需要認(rèn)真爭(zhēng)論這份文檔。避開(kāi)很多修改可能產(chǎn)生的錯(cuò)誤。應(yīng)中選取。有閱歷的軟件工程師通過(guò)閱讀含有適當(dāng)數(shù)量注解的源程序，不難搞清程序的實(shí)現(xiàn)算法。沒(méi)有具體設(shè)計(jì)結(jié)果的文檔并不會(huì)給思考題5某軟件公司擬實(shí)行下述措施提高他們所開(kāi)發(fā)的軟件產(chǎn)品的可維護(hù)性。請(qǐng)推斷哪些措施是正確的？哪些措施是不正確的？1、在分析用戶需求時(shí)同時(shí)考慮維護(hù)問(wèn)題2、測(cè)試完程序后，刪去程序中的注解以縮短源程序長(zhǎng)度3、在軟件開(kāi)發(fā)過(guò)程中盡量保證各階段文檔的正確性4、編碼時(shí)盡量多用全局變量2、 4錯(cuò)5