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

1、軟件工程知識(shí)點(diǎn)匯總1 軟件工程、軟件工程方法學(xué)：三要素1.1 軟件工程：應(yīng)用系統(tǒng)化的、規(guī)范化的、可度量的方法來(lái)開發(fā)、運(yùn)行和維護(hù)軟件，即將工程應(yīng)用到軟件；對(duì)的各種方法的研究1.2 軟件工程是一門研究用工程化方法構(gòu)建和維護(hù)有效的實(shí)用的和高質(zhì)量的軟件的學(xué)科1.3 軟件工程三要素是：方法、工具、過(guò)程軟件工程的方法：是指完成軟件開發(fā)各項(xiàng)任務(wù)的技術(shù)方法軟件工具：是指為軟件工程方法的運(yùn)用提供自動(dòng)半自動(dòng)的軟件支撐環(huán)境軟件工程過(guò)程：是指將軟件工程方法和工具綜合起來(lái)以達(dá)到合理、及時(shí)地進(jìn)行計(jì)算機(jī)軟件開發(fā)這一目的2 軟件工程的原則包括：模塊化原則、信息隱蔽原則、抽象化原則、模塊獨(dú)立原則（內(nèi)聚、耦合）、依賴倒轉(zhuǎn)原則、開

2、閉原則等2.1 模塊化原則：指解決一個(gè)復(fù)雜問題時(shí)自頂向下逐層把軟件系統(tǒng)劃分為若干模塊的過(guò)程。模塊是程序中相對(duì)獨(dú)立的成分，一個(gè)獨(dú)立的編程單位，應(yīng)有良好的編程接口，模塊的大小要適中，模塊過(guò)大會(huì)使模塊內(nèi)部的復(fù)雜性增加不利于模塊的理解和修改，模塊過(guò)小會(huì)導(dǎo)致整個(gè)系統(tǒng)表示過(guò)于復(fù)雜，不利于控制系統(tǒng)的復(fù)雜性。2.2 信息隱蔽原則：采用封裝技術(shù)，將程序模塊的實(shí)現(xiàn)細(xì)節(jié)隱藏起來(lái)，使模塊接口盡量簡(jiǎn)單。2.3 抽象化原則：抽取事物最基本的特性和行為，忽略非本質(zhì)細(xì)節(jié)，采用分層次抽象，自頂向下，逐層細(xì)化的辦法控制軟件開發(fā)過(guò)程的復(fù)雜性。2.4 模塊獨(dú)立原則：是指每個(gè)模塊只完成系統(tǒng)要求的獨(dú)立子功能，并且與其他模塊的聯(lián)系最少且接

3、口簡(jiǎn)單。要求在一個(gè)物理模塊內(nèi)集中邏輯上相互關(guān)聯(lián)的計(jì)算機(jī)資源，保證模塊間由松散的偶合關(guān)系，模塊內(nèi)部有較強(qiáng)的內(nèi)聚性，這有助于控制系統(tǒng)的復(fù)雜性。（即：高內(nèi)聚低耦合）2.5 依賴倒轉(zhuǎn)原則：抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。2.6 開閉原則：軟件實(shí)體應(yīng)該是可擴(kuò)展的，但是不可以修改。即對(duì)于擴(kuò)展是開放的，對(duì)于更改是封閉的。3 軟件開發(fā)模型：瀑布模型；快速原型；噴泉模型；各種模型的工作原理、階段、每階段任務(wù)、特點(diǎn)、示意圖；軟件開發(fā)模型（也稱為軟件過(guò)程模型）：是從軟件項(xiàng)目需求定義開始直至軟件經(jīng)使用后廢棄為止，跨越整個(gè)生命周期的系統(tǒng)開發(fā)、運(yùn)行和維護(hù)所實(shí)施的全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架3.1 瀑布模型（又

4、稱線性模型）：3.1.1 工作原理：規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。前一階段的工作成果是后一階段工作開始的基礎(chǔ).所以,每個(gè)階段都必須交出合格的文檔,必須對(duì)前階段的工作進(jìn)行評(píng)審,前一階段的工作完成后才可以開始后一階段的工作3.1.2 階段：計(jì)劃時(shí)期：?jiǎn)栴}定義、可行性研究開發(fā)時(shí)期：需求分析、設(shè)計(jì)、編碼、測(cè)試運(yùn)行時(shí)期：運(yùn)行和維護(hù)3.1.3 各階段任務(wù)：1.需求分析和定義在軟件項(xiàng)目進(jìn)行過(guò)程中，需求分析是從軟件定義到軟件開發(fā)的關(guān)鍵步驟，是今后軟件，開發(fā)的基本依據(jù)，同時(shí)也是用戶對(duì)軟件產(chǎn)品進(jìn)行驗(yàn)收的基本依據(jù)。需求分析和定義是以用戶需求為基本依據(jù)，從功能、性能、數(shù)據(jù)、操作等多個(gè)

5、方面，對(duì)軟件系統(tǒng)給出完整、準(zhǔn)確、具體的描述，用于確定軟件規(guī)格。2 / 142.軟件設(shè)計(jì)根據(jù)系統(tǒng)需求的定義，確定系統(tǒng)的結(jié)構(gòu)，進(jìn)行系統(tǒng)的概要設(shè)計(jì)和各部分的功能與結(jié)構(gòu)的詳細(xì)設(shè)計(jì)。3.編碼與單元測(cè)試在這一階段，根據(jù)軟件設(shè)計(jì)文檔完成了程序模塊或程序單元的編碼。通過(guò)程序單元測(cè)試，驗(yàn)證其是否滿足設(shè)計(jì)規(guī)范。4.集成和系統(tǒng)測(cè)試程序模塊或程序單元被組裝集成起來(lái)成為一個(gè)軟件系統(tǒng)，然后進(jìn)行系統(tǒng)測(cè)試。測(cè)試完成后即交付用戶使用。5.運(yùn)行和維護(hù)通常這是軟件生命周期中最長(zhǎng)的一個(gè)階段。如果在運(yùn)行期發(fā)現(xiàn)了軟件的錯(cuò)誤，就要修改軟件，可能會(huì)重復(fù)上述某個(gè)或多個(gè)階段的活動(dòng)。3.1.4 特點(diǎn)： 順序性、依賴性：下一階段依賴上一階段的完成。

6、 推遲實(shí)現(xiàn)：階段任務(wù)結(jié)束形成文檔，并審核后方能進(jìn)行設(shè)計(jì)任務(wù)，將程序的實(shí)現(xiàn)推遲進(jìn)行。 質(zhì)量保證:文檔完整、文檔評(píng)審，避免錯(cuò)誤積累與放大效應(yīng)。3.1.5 示意圖：3.2 快速原型3.2.1 工作原理：快速原型是利用原型輔助軟件開發(fā)的一種新思想。經(jīng)過(guò)簡(jiǎn)單快速分析，快速實(shí)現(xiàn)一個(gè)原型，用戶與開發(fā)者在試用原型過(guò)程中加強(qiáng)通信與反饋，通過(guò)反復(fù)評(píng)價(jià)和改進(jìn)原型，減少誤解，彌補(bǔ)漏洞，適應(yīng)變化，最終提高軟件質(zhì)量。廢棄型：也稱快速建立需求規(guī)格原型法：先構(gòu)造一個(gè)功能簡(jiǎn)單而質(zhì)量要求不高的模型系統(tǒng)，針對(duì)這個(gè)模型系統(tǒng)反復(fù)的進(jìn)行分析修改，從而形成較好的設(shè)計(jì)思想，據(jù)此設(shè)計(jì)出更加完整、準(zhǔn)確、一致可靠的最終系統(tǒng)，系統(tǒng)構(gòu)造完成后，原來(lái)的

7、模型就被廢棄追加型：也稱快速建立漸進(jìn)原型法。它采用循序漸進(jìn)的開發(fā)方式，對(duì)系統(tǒng)模型作連續(xù)精化，即先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系統(tǒng)，最為最終系統(tǒng)的核心，將系統(tǒng)需要具備的性能逐步添加上去，通過(guò)不斷地?cái)U(kuò)充修改，逐步追加新的要求，直至所有性能全部滿足，此時(shí)原型模型也就是最終的產(chǎn)品。3.2.2 階段及任務(wù)原型快速分析：是指在分析者和用戶的緊密配合下，快速確定軟件系統(tǒng)的基本要求，根據(jù)原型所要體現(xiàn)的特性（總體結(jié)構(gòu)、處理功能、模擬性能、界面形式等），描述基本需求規(guī)格說(shuō)明，以滿足開發(fā)圓形的需要。原型構(gòu)造：在快速原型分析的基礎(chǔ)上，根據(jù)基本需求規(guī)格說(shuō)明，忽略細(xì)節(jié)只考慮主要特性快速構(gòu)造一個(gè)可運(yùn)行的系統(tǒng)。原型

8、運(yùn)行與評(píng)價(jià)：是軟件開發(fā)人員與用戶頻繁通信、發(fā)現(xiàn)問題、消除誤解的用藥階段，目的是驗(yàn)證原型的正確程度，進(jìn)而開發(fā)新的并修改原有的需求。原型修改：根據(jù)評(píng)價(jià)原型的活動(dòng)結(jié)果進(jìn)行修改。若原型未滿足需求說(shuō)明的要求，說(shuō)明對(duì)需求說(shuō)明存在不一致的理解或?qū)崿F(xiàn)方案不夠合理，則根據(jù)明確的要求迅速修改原型。3.2.3 特點(diǎn)1增強(qiáng)了軟件開發(fā)人員和用戶對(duì)系統(tǒng)需求的理解，便于將用戶模糊的功能需求明確化2為用戶提供了一種強(qiáng)有力的學(xué)習(xí)手段3易于確定系統(tǒng)的性能，是理解和確定軟件需求規(guī)格說(shuō)明的良好工具4按照快速建立漸進(jìn)原型法建立的原型即為最終的產(chǎn)品利用快速原型化技術(shù)可以為軟件開發(fā)提供一種完整、靈活、近似動(dòng)態(tài)的需求規(guī)格說(shuō)明方法。3.2.4

9、 示意圖3.3 噴泉模型3.3.1 工作原理：噴泉模型是一種以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過(guò)程。該模型認(rèn)為軟件開發(fā)過(guò)程自下而上周期的各階段是相互重疊和多次反復(fù)的，各個(gè)開發(fā)階段沒有特定的次序要求，并且可以交互進(jìn)行，可以在某個(gè)開發(fā)階段中隨時(shí)補(bǔ)充其他任何開發(fā)階段中的遺漏。3.3.2 階段3.3.3 每階段任務(wù)3.3.4 特點(diǎn)：噴泉模型體現(xiàn)了軟件創(chuàng)建所固有的迭代和無(wú)間隙的特征。迭代指系統(tǒng)中某個(gè)部分常常重復(fù)工作多次，無(wú)間隙指活動(dòng)之間沒有明顯的間隙，如在分析和設(shè)計(jì)之間沒有明顯的界限。3.3.5 示意圖。4 軟件生命周期：階段、各階段功能、所涉及的內(nèi)容（圖、工具和文檔）

10、4.1 軟件生命周期：是指一個(gè)計(jì)算機(jī)軟件從功能確定、設(shè)計(jì)到開發(fā)成功投入使用，并在使用中不斷地修改、增補(bǔ)和完善，知道被新的需求所替代而停止該軟件的使用全過(guò)程。4.2 四個(gè)工作階段：初始階段：建立業(yè)務(wù)模型，定義最終產(chǎn)品視圖，并且確定項(xiàng)目的范圍。精化階段：設(shè)計(jì)并確定系統(tǒng)的體系結(jié)構(gòu)，制定項(xiàng)目計(jì)劃，確定資源需求。構(gòu)建階段：開發(fā)出所有構(gòu)件和應(yīng)用程序，把它們集成為客戶需要的產(chǎn)品，并且詳盡地測(cè)試所有功能。移交階段：把開發(fā)出的產(chǎn)品提交給用戶使用4.3 各階段功能：1問題定義可行性研究可性研究的任務(wù)是以最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否值得解決、是否能夠解決。階段性成果項(xiàng)目可行性報(bào)告2需求分析階段需求分析的

11、主要任務(wù)就是要通過(guò)軟件開發(fā)人員與用戶的交流和討論，準(zhǔn)確地獲取用戶對(duì)系統(tǒng)的具體要求。階段性成果需求規(guī)格說(shuō)明書、數(shù)據(jù)字典、數(shù)據(jù)流圖（DFD）3概要設(shè)計(jì)階段劃分出組成系統(tǒng)的物理元素，設(shè)計(jì)軟件的結(jié)構(gòu)，即確定模塊及模塊間的關(guān)系，根據(jù)需求分析階段得到的邏輯模型來(lái)設(shè)計(jì)系統(tǒng)的物理模型階段性成果概要設(shè)計(jì)說(shuō)明書4詳細(xì)設(shè)計(jì)階段設(shè)計(jì)每個(gè)模塊的算法，確定每一模塊使用的數(shù)據(jù)結(jié)構(gòu)，確定模塊接口的細(xì)節(jié)，為每一個(gè)模塊設(shè)計(jì)一個(gè)測(cè)試用例，編寫詳細(xì)設(shè)計(jì)說(shuō)明書軟件詳細(xì)設(shè)計(jì)文檔5編碼和單元測(cè)試6系統(tǒng)測(cè)試7軟件維護(hù)階段4.4 各階段所涉及的內(nèi)容（文檔、工具、圖）5 結(jié)構(gòu)化方法: 生命周期中各階段任務(wù).獲取用戶需求、畫數(shù)據(jù)流圖、數(shù)據(jù)字典6

12、可行性分析、需求分析、設(shè)計(jì)（概要設(shè)計(jì)+詳細(xì)設(shè)計(jì)）、測(cè)試、維護(hù)7 面向?qū)ο蠓椒ǎ汉诵母拍?、模?.1 面向?qū)ο笾械幕靖拍睿簩?duì)象：代表了一個(gè)現(xiàn)實(shí)的或虛構(gòu)的實(shí)體類：對(duì)具有相同數(shù)據(jù)和相同操作的一組相似對(duì)象的定義繼承：子類自動(dòng)的共享父類中定義的數(shù)據(jù)和方法的機(jī)制多態(tài)性：一個(gè)名字具有多種語(yǔ)義封裝：將屬性和操作包裝成一個(gè)單元，使得對(duì)狀態(tài)的訪問和修改只能通過(guò)封裝提供的接口進(jìn)行消息：對(duì)象間在交互中所傳送的通訊信息關(guān)聯(lián)：對(duì)象之間所存在的聯(lián)系7.2 模型對(duì)象模型：即尋找問題域中的對(duì)象，從對(duì)象中抽象出類的定義，識(shí)別對(duì)象的內(nèi)部特征，定義屬性，識(shí)別對(duì)象的外部關(guān)系，識(shí)別主題。動(dòng)態(tài)模型：即建立交互圖、狀態(tài)圖和活動(dòng)圖，進(jìn)一步定

13、義用例。功能模型：即用例分析，以用例對(duì)用戶需求進(jìn)行規(guī)范化描述；為了更好地理解問題，人們常采用建立建立問題模型的方法。模型就是為了理解事物而對(duì)事物作出的一種抽象，是對(duì)事物的一種無(wú)歧義的書面描述。通常，模型由一組圖示符號(hào)和組織這些符號(hào)的規(guī)則組成。模型是一種思考工具，可以把知識(shí)規(guī)范地表示出來(lái)。對(duì)于那些因過(guò)分復(fù)雜而不能直接理解的系統(tǒng)，特別需要建立模型，建模的目的主要是為了減少?gòu)?fù)雜性。一旦建立起模型之后，就要經(jīng)受用戶和各個(gè)領(lǐng)域?qū)＜业膰?yán)格審查。模型常常會(huì)經(jīng)過(guò)多次必要的修改。用OO方法開發(fā)軟件，通常需要建立3種形式的模型：對(duì)象模型-描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)；動(dòng)態(tài)模型-描述系統(tǒng)控制結(jié)構(gòu)；功能模型-描述系統(tǒng)功能；這三種

14、模型各自從不同的側(cè)面反映軟件系統(tǒng)的內(nèi)容，相互影響、相互制約，有機(jī)地結(jié)合在一起，全面地表達(dá)對(duì)目標(biāo)系統(tǒng)的需求。對(duì)象模型表示靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。面向?qū)ο蠓椒◤?qiáng)調(diào)圍繞對(duì)象而不是功能來(lái)構(gòu)造系統(tǒng)。對(duì)象模型為建立動(dòng)態(tài)模型和功能模型，提供了實(shí)質(zhì)性的框架。1997年11月，國(guó)際對(duì)象管理組織OMG批準(zhǔn)把UML1。1作為基于面向?qū)ο蠹夹g(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ì)象的合法變化序列。一旦建立起對(duì)象模型之后，就需要考察對(duì)象的動(dòng)

15、態(tài)行為。所有對(duì)象都具有自己的生命周期。狀態(tài)，是對(duì)對(duì)象屬性值的一種抽象。各對(duì)象之間相互觸發(fā)就形成了一系列的狀態(tài)變化。一個(gè)觸發(fā)行為稱作一個(gè)事件。對(duì)象對(duì)事件 的響應(yīng)，取決于接受該觸發(fā)的對(duì)象當(dāng)時(shí)所處的狀態(tài)，響應(yīng)包括改變自己的狀態(tài)或者又形成一個(gè)新的觸發(fā)行為。狀態(tài)有持續(xù)性，它占用一段時(shí)間間隔。狀態(tài)與事件密不可分，一個(gè)事件隔開兩個(gè)狀態(tài)，一個(gè)狀態(tà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)圖來(lái)描繪，各個(gè)類的狀態(tài)圖通過(guò)共享事件合并起來(lái)，從而構(gòu)成系統(tǒng)的動(dòng)態(tài)模型。動(dòng)態(tài)模型是基于事件共享而互相關(guān)聯(lián)的一組狀態(tài)圖的集合。-功能模

16、型表示變化的系統(tǒng)的“功能”性質(zhì)，它指明了系統(tǒng)應(yīng)該“做什么”，因此更直接地反映了用戶對(duì)目標(biāo)系統(tǒng)的需求。通常，功能模型由一組數(shù)據(jù)流圖組成。在OO方法中，數(shù)據(jù)流圖遠(yuǎn)不如在結(jié)構(gòu)化方法中那樣重要。但建立功能模型有助于開發(fā)人員更深入地理解問題域，改進(jìn)和完善自己的設(shè)計(jì)。UML中提供的用例圖也是進(jìn)行需求分析和建立功能模型的強(qiáng)有力工具。UML中把用例圖建立起來(lái)的系統(tǒng)模型稱為用例模型。使用用例模型代替?zhèn)鹘y(tǒng)的功能說(shuō)明，往往能夠更好地獲取用戶需求，它所回答的問題是“系統(tǒng)應(yīng)該為每個(gè)（或每類）用戶做什么”。8 面向?qū)ο蠓椒?、UML：獲取用戶需求、畫用例圖、對(duì)象模型、UML中的關(guān)系1.面向?qū)ο蟮姆椒ǎ?）分析：包括問題描述

17、、構(gòu)建對(duì)象模型、構(gòu)建動(dòng)態(tài)模型、構(gòu)建功能模型。最后得到的分析文檔包括問題需求的陳述、對(duì)象模型、動(dòng)態(tài)模型和功能模型。（2）系統(tǒng)設(shè)計(jì)：結(jié)合問題域的知識(shí)和目標(biāo)系統(tǒng)的體系結(jié)構(gòu)，將目標(biāo)系統(tǒng)分解為子系統(tǒng)，標(biāo)識(shí)由問題所規(guī)定的并發(fā)性，設(shè)計(jì)適當(dāng)?shù)目刂茩C(jī)制組織子系統(tǒng)協(xié)調(diào)工作，然后選擇數(shù)據(jù)管理的基本策略，考慮對(duì)邊界條件的處理。最后得到的系統(tǒng)設(shè)計(jì)文檔包括基本的系統(tǒng)體系結(jié)構(gòu)和高層次的決策策略。（3）對(duì)象設(shè)計(jì)：以分析模型為基礎(chǔ)，首先定義類，設(shè)計(jì)類屬性及操作，為每個(gè)操作選擇合適的數(shù)據(jù)結(jié)構(gòu)并定義算法，調(diào)整類結(jié)構(gòu)以強(qiáng)化繼承性；然后創(chuàng)建對(duì)象，設(shè)計(jì)消息以補(bǔ)充對(duì)象關(guān)聯(lián)；通過(guò)關(guān)聯(lián)發(fā)現(xiàn)新的對(duì)象或交互條件時(shí)，修改類組織以優(yōu)化對(duì)數(shù)據(jù)的訪問，改

18、善設(shè)計(jì)結(jié)構(gòu)。最后得到的對(duì)象設(shè)計(jì)文檔包括細(xì)化的對(duì)象模型、細(xì)化的動(dòng)態(tài)模型和細(xì)化的功能模型。（4）實(shí)現(xiàn)：將設(shè)計(jì)轉(zhuǎn)換為特定編程語(yǔ)言代碼并在相應(yīng)環(huán)境運(yùn)行，同時(shí)保持可追蹤性、靈活性和可擴(kuò)展性。2.UML：統(tǒng)一建模語(yǔ)言（UML）是一個(gè)通用的可視化建模語(yǔ)言，用于對(duì)軟件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)產(chǎn)品的文檔 。UML描述了一個(gè)系統(tǒng)的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為3.獲取用戶需求（1）與用戶進(jìn)行充分溝通，了解用戶對(duì)軟件的需求；（2）識(shí)別對(duì)象集合及對(duì)象間的關(guān)系；（3）定義類（包括屬性和操作）并建立類間的層次關(guān)系；（4）建立模型來(lái)表示對(duì)象之間的關(guān)系及行為特性。4.用例圖：用例模型描述外部執(zhí)行者所理解的系統(tǒng)功能。用例模

19、型用于需求分析階段，描述待開發(fā)系統(tǒng)的功能要求，幫助軟件設(shè)計(jì)人員理解系統(tǒng)要做的工作，同時(shí)用例模型還可以為其他模型建立、結(jié)構(gòu)設(shè)計(jì)、實(shí)現(xiàn)及測(cè)試工作等提供依據(jù)。一個(gè)用例模型是由若干用例圖組成的，進(jìn)行用例建模的過(guò)程主要包括尋找執(zhí)行者、尋找用例、描述用例、確定執(zhí)行者和用例之間的關(guān)系等工作，其中尋找執(zhí)行者和用例是用例建模的關(guān)鍵。5.對(duì)象模型：對(duì)象模型表示靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。面向?qū)ο蠓椒◤?qiáng)調(diào)圍繞對(duì)象而不是功能來(lái)構(gòu)造系統(tǒng)。對(duì)象模型為建立動(dòng)態(tài)模型和功能模型，提供了實(shí)質(zhì)性的框架。通常，使用UML的類圖來(lái)建立對(duì)象模型。在UML中術(shù)語(yǔ)“類”的實(shí)際含義是，“一個(gè)類及屬于該類的對(duì)象”6

20、.關(guān)系：依賴關(guān)聯(lián)泛化實(shí)現(xiàn)9 測(cè)試：黑盒、白盒設(shè)計(jì)測(cè)試用例9.1 白盒測(cè)試（結(jié)構(gòu)測(cè)試、邏輯驅(qū)動(dòng)測(cè)試）：9.1.1 語(yǔ)句覆蓋：設(shè)計(jì)若干個(gè)測(cè)試用例，使得被測(cè)試的程序中的每條可執(zhí)行語(yǔ)句至少被執(zhí)行一次9.1.2 判斷覆蓋：每個(gè)判斷至少都獲得一次“真”值和“假”值9.1.3 條件覆蓋：每個(gè)判斷中的條件可能的取值至少被執(zhí)行一次9.1.4 判斷與條件覆蓋：每個(gè)判斷的真假值分支至少被執(zhí)行一遍，并且每個(gè)判斷的條件的內(nèi)部判斷式的真假值分支也要被執(zhí)行一遍9.1.5 條件組合覆蓋：程序中每個(gè)判斷條件的內(nèi)部判斷式的各種真假值組合可能都至少執(zhí)行一遍9.1.6 路徑覆蓋：覆蓋程序中所有可能的路徑9.1.7 六種邏輯覆蓋從弱到

21、強(qiáng)的排列順序語(yǔ)句覆蓋-à判斷覆蓋-à條件覆蓋-à判斷條件覆蓋à條件組合覆蓋-à路徑覆蓋9.2 黑盒測(cè)試9.2.1 等價(jià)類劃分：有效等價(jià)類和無(wú)效等價(jià)類9.2.2 邊界值分析10 軟件項(xiàng)目管理：項(xiàng)目管理、五大過(guò)程、九大知識(shí)領(lǐng)域、項(xiàng)目三角形項(xiàng)目管理：是為完成一個(gè)預(yù)定的目標(biāo)，而對(duì)任務(wù)和資源進(jìn)行規(guī)劃、組織和管理的程序項(xiàng)目三角形：時(shí)間：反映在項(xiàng)目計(jì)劃中的項(xiàng)目完成所需時(shí)間。資金：即項(xiàng)目的預(yù)算，取決于資源的成本，這些資源包括完成任務(wù)所需的人員、設(shè)備和材料。范圍：項(xiàng)目的目標(biāo)和任務(wù)，以及完成這些目標(biāo)和任務(wù)所需的工時(shí)。項(xiàng)目管理的五大過(guò)程：?jiǎn)?dòng)過(guò)程、計(jì)劃過(guò)程、實(shí)施過(guò)程

22、、控制過(guò)程、收尾過(guò)程項(xiàng)目管理的九大知識(shí)領(lǐng)域：范圍管理、時(shí)間管理、成本管理、質(zhì)量管理、風(fēng)險(xiǎn)管理、人力資源管理、溝通管理、采購(gòu)管理、綜合管理11 配置管理：配置管理、配置管理項(xiàng)、基線、里程碑配置管理：是一組追蹤和控制活動(dòng)，它們開始于軟件項(xiàng)目開始時(shí)，結(jié)束于軟件被淘汰之時(shí)。配置管理項(xiàng)：1。計(jì)算機(jī)程序-源代碼和可執(zhí)行程序2。描述計(jì)算機(jī)程序的文檔-供技術(shù)人員或用戶使用3。數(shù)據(jù)-程序內(nèi)包含的或在程序外的。每個(gè)配置項(xiàng)的主要屬性有名稱、標(biāo)識(shí)符、文件狀態(tài)、版本、作者、日期等基線：是一組配置項(xiàng)，這些配置項(xiàng)不能被隨便修改和變更?；€是軟件生存期中各開發(fā)階段末尾的特定點(diǎn)，又稱里程碑。軟件開發(fā)各階段的基線：12 結(jié)構(gòu)化方

23、法與面向?qū)ο蠓椒ǖ谋容^：基本思想；分階段比較1結(jié)構(gòu)化方法：基本思想：可以概括為自頂向下、逐步求精，采用模塊化技術(shù)和功能抽象將系統(tǒng)按功能分解為若干模塊，從而將復(fù)雜的系統(tǒng)分解成若干易于控制和處理的子系統(tǒng)，子系統(tǒng)又可分解為更小的子任務(wù)，最后的子任務(wù)都可以獨(dú)立編寫成子程序模塊，模塊內(nèi)部由順序、選擇、循環(huán)等基本控制結(jié)構(gòu)組成。2面向?qū)ο蠓椒ɑ舅枷耄好嫦驅(qū)ο蠓椒ǖ某霭l(fā)點(diǎn)和基本原則，是盡可能模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法與過(guò)程盡可能接近人類認(rèn)識(shí)世界、解決問題的方法與過(guò)程，將客觀世界中的實(shí)體抽象為問題域中的對(duì)象。 使用現(xiàn)實(shí)的概念抽象地思考問題，從而自然地解決問題，保證軟件系統(tǒng)的穩(wěn)定性和可復(fù)用性以及良

24、好的維護(hù)性。 3 兩種方法的比較：傳統(tǒng)的結(jié)構(gòu)化方法，是軟件工程中最為成熟的方法。對(duì)于能夠預(yù)先確定需求的系統(tǒng)的開發(fā)，采用結(jié)構(gòu)化方法非常有效，但是對(duì)于需求是模糊的或隨時(shí)間變化的系統(tǒng)開發(fā)這種方法不能適應(yīng)。面向?qū)ο蠓椒?，?duì)于需求不能預(yù)先確定的系統(tǒng)的開發(fā)，可采用面向?qū)ο蠓椒ńY(jié)合，這樣就能夠結(jié)合面向?qū)ο蠓椒ㄋ哂械姆€(wěn)定性好、可復(fù)用性好和可維護(hù)性好的特點(diǎn)。需求分析階段：結(jié)構(gòu)化方法：采用自頂向下功能分解的方法，強(qiáng)調(diào)邏輯功能而不是實(shí)現(xiàn)功能的具體方法，使用圖形進(jìn)行系統(tǒng)分析并表達(dá)分析的結(jié)果-數(shù)據(jù)流圖，使用結(jié)構(gòu)化分析方法獲得的需求規(guī)格說(shuō)明書由數(shù)據(jù)流圖、數(shù)據(jù)詞典及補(bǔ)充材料組成。面向?qū)ο蠓椒ǎ好嫦驅(qū)ο蠓治龅年P(guān)鍵是識(shí)別出問

25、題域中的對(duì)象，并分析它們之間的關(guān)系，最終建立起問題域的簡(jiǎn)潔、精確、可理解的正確模型。面向?qū)ο蠓治瞿Ｐ屯ǔ０▽?duì)象模型、動(dòng)態(tài)模型和功能模型。對(duì)象模型是最重要、最基本、最核心的。設(shè)計(jì)階段：結(jié)構(gòu)化軟件是功能的集合,通過(guò)模塊調(diào)用實(shí)現(xiàn)系統(tǒng)。面向?qū)ο筌浖鞘挛锏募?通過(guò)對(duì)象及聯(lián)系實(shí)現(xiàn)系統(tǒng)。結(jié)構(gòu)化軟件=過(guò)程+數(shù)據(jù),以過(guò)程為中心。面向?qū)ο筌浖?數(shù)據(jù)+相應(yīng)操作,以數(shù)據(jù)為中心。結(jié)構(gòu)化軟件采用順序處理方式,由過(guò)程驅(qū)動(dòng)控制;面向?qū)ο筌浖捎媒换ナ健⒉⑿刑幚矸绞?由消息驅(qū)動(dòng)控制;結(jié)構(gòu)化方法的重點(diǎn)是設(shè)計(jì)；面向?qū)ο蠓椒ǖ闹攸c(diǎn)是分析。結(jié)構(gòu)化方法更適合數(shù)據(jù)類型比較簡(jiǎn)單的軟件項(xiàng)目的開發(fā)；面向?qū)ο蠓椒ǜm合大型復(fù)雜的軟件項(xiàng)目的開

26、發(fā)練習(xí)題：1. 看書上實(shí)例A，理解RUP過(guò)程2. 試討論RUP過(guò)程的優(yōu)缺點(diǎn)3. RUP過(guò)程主要適用于何種項(xiàng)目？4. 用面向?qū)ο蠓椒ㄩ_發(fā)軟件時(shí)與結(jié)構(gòu)化方法開發(fā)軟件時(shí)相比較，軟件的生命周期有何不同？這種差異帶來(lái)了什么后果？5. 為什么說(shuō)廣州本田牌汽車是小汽車類的特化，而發(fā)動(dòng)機(jī)不是小汽車類的特化？6. 什么是對(duì)象？它與傳統(tǒng)的數(shù)據(jù)有何區(qū)別？7. 試用面向?qū)ο蠓治龇椒ㄔO(shè)計(jì)下述程序：8. 在顯示器屏幕上圓心坐標(biāo)為（100,100）的位置畫一個(gè)半徑為40的圓，在圓心坐標(biāo)為（200,300）的位置畫一個(gè)半徑為20的圓，在圓心坐標(biāo)為（ 400,150 ）的位置畫一條弧，起始角為30度，結(jié)束角度為120度，半徑為

27、50.9. 思考題1、一個(gè)程序能夠既正確又不可靠嗎？請(qǐng)解釋你的答案。軟件可靠性是程序在給定的時(shí)間間隔內(nèi)按規(guī)格說(shuō)明書的規(guī)定成功地運(yùn)行的概率。軟件可靠性即包含正確性又包含健壯性。即程序在正常環(huán)境下應(yīng)能正確地完成預(yù)期功能，在意外環(huán)境下，也應(yīng)能作出適當(dāng)?shù)捻憫?yīng)。如果某程序在正常環(huán)境下可正常運(yùn)行，在異常環(huán)境下不能作出適當(dāng)?shù)捻憫?yīng)，則該項(xiàng)程序就是既正確又不可靠思考題2、為什么在開發(fā)軟件的過(guò)程中變化既是必要的又是不可避免的？為什么必須進(jìn)行配置管理？在軟件開發(fā)過(guò)程中，下述原因會(huì)導(dǎo)致軟件配置項(xiàng)發(fā)生變化，新的市場(chǎng)條件導(dǎo)致需求或業(yè)務(wù)規(guī)則變化，客戶的需求也會(huì)或多或少地發(fā)生變化。企業(yè)改組或業(yè)務(wù)縮減，引起項(xiàng)目?jī)?yōu)先級(jí)或軟件工程

28、隊(duì)伍結(jié)構(gòu)變化，預(yù)算或進(jìn)度限制，導(dǎo)致對(duì)目標(biāo)系統(tǒng)的重新定義，發(fā)現(xiàn)了前期階段的錯(cuò)誤，必須加以改正。因此，在開發(fā)軟件的過(guò)程中，變化既是必要的，又是不可避免的。如果不能適當(dāng)?shù)乜刂坪凸芾碜兓?，?shì)必造成混亂并產(chǎn)生許多嚴(yán)重的錯(cuò)誤。軟件配置管理是在軟件的整個(gè)生命期內(nèi)管理變化的一組活動(dòng)，可以認(rèn)為軟件配置管理是應(yīng)用于整個(gè)軟件生命期的軟件質(zhì)量保證活動(dòng)，是專門用于管理變化的軟件質(zhì)量保證活動(dòng)，軟件配置管理的目標(biāo)是使變化更正確且更容易被適應(yīng)，在必須變化時(shí)減少所需花費(fèi)的工作量，綜上所述，進(jìn)行配置管理是十分必要的3、某些軟件工程師不同意“目前國(guó)外許多軟件開發(fā)組織把60%以上的人力用于維護(hù)已有的軟件”的說(shuō)法。他們爭(zhēng)論說(shuō)：“我并沒有花費(fèi)我的60%的時(shí)間去改正我所開發(fā)的程序中的錯(cuò)誤”。請(qǐng)問，你對(duì)上述爭(zhēng)論有何看法？答：軟件維護(hù)并非僅僅是改正程序中的錯(cuò)誤，它還包括適應(yīng)性維護(hù)、完善性