軟件工程復(fù)習(xí)

1、1. 軟件：軟件是能夠滿足預(yù)定義的功能和性能的可執(zhí)行的計(jì)算機(jī)程序，包括使程序正常執(zhí)行所需要的輸入數(shù)據(jù)以及相關(guān)的使用文檔。2. 軟件工程的基本原理：a) 清晰第一，效率第二b) 設(shè)計(jì)先于編碼c) 使程序的結(jié)構(gòu)適合于問(wèn)題的結(jié)構(gòu)d) 開(kāi)發(fā)伴隨復(fù)用，開(kāi)發(fā)為了復(fù)用3. 軟件危機(jī)：指在軟件開(kāi)發(fā)過(guò)程中所遇到的一系列的問(wèn)題。4. 軟件危機(jī)的原因:a) 軟件維護(hù)費(fèi)用過(guò)高，直接威脅計(jì)算機(jī)應(yīng)用的擴(kuò)大b) 軟件生產(chǎn)技術(shù)發(fā)展緩慢，進(jìn)一步加劇了軟件危機(jī)5. 軟件的特征：a) 軟件的開(kāi)發(fā)不同于硬件的設(shè)計(jì)b) 軟件的生產(chǎn)不同于硬件的制造c) 軟件的維護(hù)不同于硬件的維修6. 軟件工程從第一代開(kāi)始已經(jīng)發(fā)展到了第三代，編程范型也經(jīng)

2、歷了三次的演變a) 過(guò)程式編程范型：著眼于程序的過(guò)程和基本控制結(jié)構(gòu)，粒度最小b) 面向?qū)ο缶幊谭缎停褐塾诔绦蛑械膶?duì)象c) 基于構(gòu)件技術(shù)的編程范型：著眼于適合整個(gè)領(lǐng)域的類(lèi)對(duì)象用編程粒度的大小比較三種編程范型的差異。7. 軟件工程學(xué)的范疇a) 軟件開(kāi)發(fā)技術(shù)i. 軟件開(kāi)發(fā)方法學(xué)ii. 軟件工具（幫助開(kāi)發(fā)軟件的軟件）iii. 軟件工程環(huán)境（方法與工具相結(jié)合，再加上配套的軟、硬件支持就形成環(huán)境）b) 軟件工程管理i. 軟件經(jīng)濟(jì)學(xué)ii. 軟件管理學(xué)iii. 軟件度量學(xué)軟件工程管理的目的是為了按照進(jìn)度及預(yù)算完成軟件計(jì)劃，實(shí)現(xiàn)預(yù)期的經(jīng)濟(jì)和社會(huì)效益。7. 軟件生存周期：軟件產(chǎn)品從形成概念，經(jīng)過(guò)開(kāi)發(fā)、使用和維護(hù)

3、，直到最后退役的全過(guò)程。8. 軟件生存周期一般劃分為：計(jì)劃、開(kāi)發(fā)、運(yùn)行三個(gè)階段。9. 將軟件生存周期劃分為若干個(gè)階段的意義將軟件生存周期劃分為若干個(gè)階段，每一個(gè)階段只賦予有限的活動(dòng)，這就使因軟件規(guī)模大大增長(zhǎng)而帶來(lái)的軟件復(fù)雜性變得容易控制和管理。10. 傳統(tǒng)的瀑布模型軟件生存周期的劃分階段：a) 需求分析b) 軟件分析c) 軟件設(shè)計(jì)d) 編碼e) 軟件測(cè)試f) 運(yùn)行維護(hù)11. 瀑布模型（一種基于軟件生存周期的線性開(kāi)發(fā)模型）的特點(diǎn)：a) 階段間的順序性和依賴性i. 順序性：只有前一階段的開(kāi)發(fā)工作完成后，后一階段才能進(jìn)行ii. 依賴性：前一階段的輸出文檔是后一階段的輸入文檔b) 推遲實(shí)現(xiàn)的觀點(diǎn)：瀑布

4、模型是一種線性模型，過(guò)早的編碼容易導(dǎo)致返工。所謂推遲實(shí)現(xiàn)是指將待開(kāi)發(fā)軟件的邏輯設(shè)計(jì)和物理實(shí)現(xiàn)區(qū)分開(kāi)來(lái)，即在需求分析和軟件設(shè)計(jì)階段只考慮系統(tǒng)的邏輯模型，等到編碼階段再完成實(shí)現(xiàn)。c) 保證質(zhì)量的觀點(diǎn)：i. 每一階段都必須要完成規(guī)定的文檔，不然不能視為完成該階段的任務(wù)ii. 每一階段都要對(duì)完成的文檔進(jìn)行復(fù)審，以便盡早發(fā)現(xiàn)問(wèn)題。d) 存有問(wèn)題，風(fēng)險(xiǎn)滯后釋放，不適合大型軟件的開(kāi)發(fā)12. 瀑布模型存在的問(wèn)題a) 不適合于需求模糊的系統(tǒng)b) 滯后的風(fēng)險(xiǎn)釋放13. 快速原型模型定義：先建立一個(gè)滿足用戶主要需求的原型，讓用戶了解整個(gè)軟件的概貌，以便判斷哪些功能是需要的，哪些方面還需要改進(jìn)。然后在此原型的基礎(chǔ)上進(jìn)

5、行開(kāi)發(fā)，直到建立起滿足用戶全部功能的軟件系統(tǒng)。14. 一個(gè)關(guān)鍵的問(wèn)題：到底用戶最終的需求是什么？ 術(shù)業(yè)有專攻，用戶不懂計(jì)算機(jī)，軟件系統(tǒng)分析員對(duì)用戶的專業(yè)也往往不了解，所以在開(kāi)發(fā)的初始階段很難弄清用戶的需要到底是什么。15. 增量模型是瀑布模型的順序特征和快速原型模型的迭代特征相結(jié)合的產(chǎn)物。增量模型將軟件視作一系列相互聯(lián)系的增量，每一次的迭代過(guò)程，采用瀑布模型或快速原型模型完成對(duì)一個(gè)增量的開(kāi)發(fā)。16. 螺旋模型：目前軟件開(kāi)發(fā)中最常用的一種軟件開(kāi)發(fā)模型，適合于大型軟件的開(kāi)發(fā)。17. 當(dāng)項(xiàng)目按順時(shí)針?lè)较蜓芈菪€移動(dòng)時(shí)，每輪螺旋均包含一下內(nèi)容：a) 計(jì)劃b) 風(fēng)險(xiǎn)分析c) 建立原型d) 用戶評(píng)審按以上

6、順序螺旋線周而復(fù)始，直到最后實(shí)現(xiàn)產(chǎn)品。螺旋模型每一次迭代過(guò)程都需要進(jìn)行一次風(fēng)險(xiǎn)分析。18. 構(gòu)件集成模型構(gòu)件是經(jīng)過(guò)適當(dāng)設(shè)計(jì)和實(shí)現(xiàn)的類(lèi)。19. 凈室模型是一種形式化的增量開(kāi)發(fā)模型。其基本思想是力求在分析和設(shè)計(jì)階段消除錯(cuò)誤，確保正確，然后在無(wú)缺陷或“潔凈”的狀態(tài)下實(shí)現(xiàn)軟件的制作。20 轉(zhuǎn)換模型：將形式化軟件開(kāi)發(fā)和程序自動(dòng)生成技術(shù)相結(jié)合的一種軟件開(kāi)發(fā)模型。（自動(dòng)或半自動(dòng)的程序變換）21.軟件工程開(kāi)發(fā)模型e) 傳統(tǒng)的軟件工程i. 瀑布模型ii. 快速原型模型f) 軟件演化模型：i. 增量模型ii. 螺旋模型iii. 構(gòu)件集成模型g) 形式化方法模型i. 轉(zhuǎn)換模型ii. 凈室模型22.7種軟件開(kāi)發(fā)模型的

7、特點(diǎn)及適用場(chǎng)合A. 瀑布模型是一種線性開(kāi)發(fā)模型，每一階段必須完成規(guī)定的文檔。適用于需求明確的中、小型軟件開(kāi)發(fā)B. 快速原型模型：用戶介入早，采用快速開(kāi)發(fā)工具，通過(guò)迭代完善用戶需求。適合于需求模糊的小型軟件開(kāi)發(fā)C. 增量模型：每次迭代完成一個(gè)增量，可用于OO開(kāi)發(fā)。適合于容易分塊的大型軟件開(kāi)發(fā)。D. 螺旋模型：典型的迭代模型，重視風(fēng)險(xiǎn)分析，可用于OO開(kāi)發(fā)。適合于具有不確定性的大型軟件開(kāi)發(fā)E. 構(gòu)件集成模型：軟件開(kāi)發(fā)與構(gòu)件開(kāi)發(fā)平行進(jìn)行，主要用于OO開(kāi)發(fā)。適用于領(lǐng)域過(guò)程、行業(yè)的中型軟件開(kāi)發(fā)。F. 轉(zhuǎn)換模型：形式化的需求規(guī)格說(shuō)明書(shū)，自動(dòng)的程序變換系統(tǒng)。適用場(chǎng)合：理想化模型，尚無(wú)成熟工具支持。G. 凈室模

8、型：形式化的增量開(kāi)發(fā)模型，在潔凈狀態(tài)下實(shí)現(xiàn)軟件制作。適合場(chǎng)合：開(kāi)發(fā)團(tuán)隊(duì)熟悉形式化方法，中小型軟件開(kāi)發(fā)。23. 軟件可行性的研究：a) 經(jīng)濟(jì)可行性b) 技術(shù)可行性c) 運(yùn)行可行性d) 法律可行性24. 可行性研究的目的是弄清待開(kāi)發(fā)的項(xiàng)目是不是可能實(shí)現(xiàn)和值得開(kāi)發(fā)，通常由系統(tǒng)分析員完成，并需寫(xiě)出可行性論證報(bào)告。25. 統(tǒng)一過(guò)程概念：統(tǒng)一過(guò)程描述了軟件開(kāi)發(fā)各個(gè)環(huán)節(jié)中應(yīng)該做什么，怎么做，什么時(shí)候做已經(jīng)為什么要做，描述了一組以某種順序完成的活動(dòng)。26. 結(jié)構(gòu)化分析與設(shè)計(jì)由結(jié)構(gòu)化程序設(shè)計(jì)擴(kuò)展而來(lái)。結(jié)構(gòu)化設(shè)計(jì)（SD）的軟件設(shè)計(jì)技術(shù)，結(jié)構(gòu)化分析技術(shù)（SA）。27. 結(jié)構(gòu)化分析SA有兩項(xiàng)基本任務(wù)：a) 建立系統(tǒng)分

9、析模型b) 編寫(xiě)軟件需求規(guī)格說(shuō)明書(shū)SRS。SRS是分析階段編寫(xiě)的，以文字為主的文檔。28. SA模型的組成：a) 數(shù)據(jù)字典（DD）：處于模型的核心部分，是系統(tǒng)涉及到的各種數(shù)據(jù)對(duì)象的總和。b) 實(shí)體聯(lián)系圖ER圖：用于描述數(shù)據(jù)對(duì)象間的關(guān)系。c) 數(shù)據(jù)流圖DFD：主要作用是指明系統(tǒng)中的數(shù)據(jù)是如何流動(dòng)和變換的，以及描述使數(shù)據(jù)流進(jìn)行變換的功能。d) 狀態(tài)變換圖STD:用于指明 系統(tǒng)在外部事件作用下將如何動(dòng)作，表明系統(tǒng)的各種狀態(tài)以及狀態(tài)間的轉(zhuǎn)換。e) 數(shù)據(jù)對(duì)象說(shuō)明f) 加工規(guī)格說(shuō)明（PSPEC）g) 控制規(guī)格說(shuō)明 （CSPEC）29. 數(shù)據(jù)流圖的組成符號(hào)：a) 圓框表示 數(shù)據(jù)加工（其中的內(nèi)容還應(yīng)進(jìn)行編號(hào)）

10、b) 方框表示 數(shù)據(jù)源點(diǎn)和終點(diǎn)c) 箭頭表示 數(shù)據(jù)流（單箭頭表示只讀或只寫(xiě)，雙向表示又讀又寫(xiě)，箭頭的方向表示從文件讀出）。d) 雙杠或單杠表示 數(shù)據(jù)文件或數(shù)據(jù)庫(kù)30. 數(shù)據(jù)字典a) 定義：關(guān)于數(shù)據(jù)信息的集合，對(duì)數(shù)據(jù)流圖中的每個(gè)元素作完整的定義與說(shuō)明b) 功能：對(duì)軟件中的每個(gè)數(shù)據(jù)規(guī)定一個(gè)定義條目。c) 組成：i. 數(shù)據(jù)流（由多個(gè)數(shù)據(jù)項(xiàng)組成）ii. 數(shù)據(jù)文件iii. 數(shù)據(jù)項(xiàng) 加過(guò)規(guī)格說(shuō)明：通常用結(jié)構(gòu)化語(yǔ)言、判定表或判定樹(shù)作為描述工具。31. 結(jié)構(gòu)設(shè)計(jì)模型SD由結(jié)構(gòu)分析模型SA映射而來(lái)。體系結(jié)構(gòu)設(shè)計(jì)用來(lái)確定軟件結(jié)構(gòu)，其描述工具為結(jié)構(gòu)圖（structure chart），簡(jiǎn)稱SC圖。32. 在SC圖中

11、，用矩形表示模塊，帶箭頭的連線表示模塊間的調(diào)用，并在調(diào)用線的兩旁標(biāo)出傳入和傳出模塊的數(shù)據(jù)流。SC圖允許使用6種模塊。33. 軟件設(shè)計(jì)目前的兩種主流方法：基于結(jié)構(gòu)化程序設(shè)計(jì)的結(jié)構(gòu)化軟件設(shè)計(jì)，基于面向?qū)ο蠹夹g(shù)的面向?qū)ο筌浖O(shè)計(jì)。34. SD模型的組成：a) 過(guò)程設(shè)計(jì)b) 接口設(shè)計(jì)c) 體系結(jié)構(gòu)設(shè)計(jì)d) 數(shù)據(jù)設(shè)計(jì)35. 結(jié)構(gòu)化系統(tǒng)分析就是使用DFD，DD，結(jié)構(gòu)化英語(yǔ)，判定表，判定樹(shù)等工具，來(lái)建立一種新的，稱為結(jié)構(gòu)化說(shuō)明書(shū)的目標(biāo)文檔。36. 結(jié)構(gòu)化分析的基本步驟：a) 自頂向下，進(jìn)行功能分解，畫(huà)出分層DFDb) 由后向前，定義系統(tǒng)的數(shù)據(jù)和加工，編制DD和PSPECc) 根據(jù)需要，建立復(fù)雜的數(shù)據(jù)模型d)

12、 編寫(xiě)SRS37. 為什么對(duì)DFD分層（畫(huà)分層數(shù)據(jù)流圖）對(duì)于大型規(guī)模的軟件系統(tǒng)，可能會(huì)有成百上千個(gè)DFD圖，不可能一次將所有的DFD圖畫(huà)完，所以必須要從系統(tǒng)的基本模型開(kāi)始，對(duì)系統(tǒng)逐層進(jìn)行分解。38. 分層DFD的優(yōu)點(diǎn)：a) 便于使用b) 便于實(shí)現(xiàn)39. 結(jié)構(gòu)化軟件的設(shè)計(jì)通常從DFD圖到SC圖的映射開(kāi)始。40. 從SA獲得的DFD，所有系統(tǒng)都可以歸結(jié)為變換型結(jié)構(gòu)和事務(wù)型結(jié)構(gòu)。a) 變換型結(jié)構(gòu)：只有一個(gè)傳入路徑，變換中心和傳出路徑組成。b) 事物型結(jié)構(gòu)：由至少一條接受路徑，一個(gè)事務(wù)中心和若干條動(dòng)作路徑組成。當(dāng)外部信息沿著接受路徑進(jìn)入系統(tǒng)后，進(jìn)過(guò)事務(wù)中心獲得某一個(gè)特定的值，就能據(jù)此啟動(dòng)某一條動(dòng)作路徑

13、。41. 優(yōu)化初始SC圖的指導(dǎo)準(zhǔn)則a) 對(duì)模塊劃分的原則b) 高扇入/低扇出的原則。（扇入高，則上級(jí)模塊多，能夠增加模塊的利用率；扇出低，則表示下級(jí)模塊少，可以減少模塊調(diào)用和控制的復(fù)雜度）42. 模塊化設(shè)計(jì)的原則與方法a) 清晰第一的設(shè)計(jì)風(fēng)格b) 結(jié)構(gòu)化的控制結(jié)構(gòu)c) 逐步細(xì)化的實(shí)現(xiàn)方法。43. 需求分析的步驟：需求獲?。恍枨筇釤?；需求描述；需求驗(yàn)證。44. 需求分析的任務(wù)：a) 需求分析主要有兩個(gè)基本任務(wù)：一是根據(jù)對(duì)用戶問(wèn)題的分析、理解和綜合建立分析模型；二是在全面理解用戶對(duì)系統(tǒng)的明確定義的基礎(chǔ)上，通過(guò)軟件需求規(guī)格說(shuō)明書(shū)SRS來(lái)描述用戶需求。45. 分析階段的任務(wù)是決定設(shè)計(jì)一個(gè)什么樣的系統(tǒng)，

14、即解決系統(tǒng)做什么的問(wèn)題，而不是去刻畫(huà)系統(tǒng)如何做。面向?qū)ο蟮能浖こ?. 對(duì)象是現(xiàn)實(shí)世界中個(gè)體或事物的抽象，具有特征和服務(wù)功能2. 類(lèi)是一組對(duì)象集合的描述，這些對(duì)象具有共同的屬性、操作、關(guān)系和語(yǔ)義解釋3. 面向?qū)ο蟮幕咎卣鳎篴) 抽象：忽略主題中與當(dāng)前目標(biāo)無(wú)關(guān)的因素，把充分的注意力放在與當(dāng)前目標(biāo)相關(guān)的因素上b) 封裝：將數(shù)據(jù)和操作包圍起來(lái)，對(duì)數(shù)據(jù)的操作只能通過(guò)已定義的類(lèi)接口實(shí)現(xiàn)c) 繼承：新的類(lèi)可以從已有的類(lèi)中派生出來(lái)d) 多態(tài)：不同類(lèi)的對(duì)象可以對(duì)同一消息做出響應(yīng)，執(zhí)行不同的處理。4. 面向?qū)ο蟮膬?yōu)點(diǎn)：a) 提高軟件的可擴(kuò)展性b) 提高軟件的可維護(hù)性c) 提高軟件的可復(fù)用性d) 容易建造模型，

15、更密切的映射現(xiàn)實(shí)世界5. UML是一種基于面向?qū)ο蟮目梢暬ＵZ(yǔ)言，它提供了豐富的以圖形符號(hào)表示的模型元素，這些標(biāo)準(zhǔn)的圖形符號(hào)隱藏了UML 的語(yǔ)法，而由這些圖形符號(hào)組成的各種模型表示了UML 的語(yǔ)義。6. UML的兩種模型元素：一類(lèi)模型元素用于表示模型中的某個(gè)概念；另一類(lèi)用于表示模型元素之間相互連接的關(guān)系。7. 按照UML 的語(yǔ)義，UML模型可定義為4個(gè)抽象層次（從低到高）：元元模型、元模型、模型、用戶模型。8. 元元模型定義了描述元模型的語(yǔ)言，它是任何模型的基礎(chǔ)；9. 元模型定義了用于描述模型的語(yǔ)言，它組成了UML的基本元素。10. 模型定義了用于描述信息領(lǐng)域的語(yǔ)言，它組成了UML 的模型1

16、1. 用戶模型是模型的實(shí)例，它用于表示一個(gè)模型的特定情況。（UML中用名稱下面帶有下劃線表示實(shí)例）12. UML的九種圖a) 靜態(tài)建模：i. 用例圖：描述系統(tǒng)的功能ii. 類(lèi)圖：描述系統(tǒng)的靜態(tài)結(jié)構(gòu)iii. 對(duì)象圖：描述系統(tǒng)在某個(gè)時(shí)刻的靜態(tài)結(jié)構(gòu)iv. 構(gòu)件圖：描述系統(tǒng)元素間的組織v. 部署圖：描述系統(tǒng)環(huán)境元素的配置b) 動(dòng)態(tài)建模：狀態(tài)圖：描述系統(tǒng)元素的狀態(tài)條件和響應(yīng)時(shí)序圖：按時(shí)間順序描述系統(tǒng)元素間的交互協(xié)作圖：按照連接關(guān)系描述系統(tǒng)元素間的交互活動(dòng)圖：描述系統(tǒng)元素的活動(dòng)流程13. 用例圖可描述軟件系統(tǒng)和外部參與者之間的交互。用例圖通常包含系統(tǒng)邊界、用例、參與者和關(guān)聯(lián)等組成符號(hào)。系統(tǒng)邊界以一個(gè)矩形表

17、示，上方標(biāo)注系統(tǒng)名稱，內(nèi)部包含一個(gè)或多個(gè)用例；每個(gè)用例由一個(gè)橢圓形表示，其中標(biāo)上用例的名稱；參與者用一個(gè)人形的符號(hào)表示；參與者和用例之間或用例和用例之間的關(guān)聯(lián)均用直線表示。14. 用例是一組動(dòng)作序列及其變體的描述。15. 消息是對(duì)象間通信的規(guī)約，對(duì)象間的交互通過(guò)對(duì)象間的消息傳遞完成。16. UML定義的消息有三種：簡(jiǎn)單消息；同步消息；異步消息。17. 狀態(tài)圖用于描述一個(gè)特定對(duì)象的所有可能狀態(tài)以及引起狀態(tài)遷移的事件。18. 時(shí)序圖用與描述對(duì)象之間的動(dòng)態(tài)交互，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序。它以垂直軸表示時(shí)間，水平軸表示不同的對(duì)象。對(duì)象用一個(gè)帶有垂直虛線的矩形框表示，并標(biāo)有對(duì)象名和類(lèi)名。垂直虛線

18、是對(duì)象的生命線，用于表示在某段時(shí)間內(nèi)對(duì)象是存在的。對(duì)象間的通信在對(duì)象的生命線間通過(guò)消息符號(hào)來(lái)表示，消息的箭頭指明消息的類(lèi)型。19. 協(xié)作圖用于描述相互協(xié)作的對(duì)象間的交換和鏈接。20. UML的特點(diǎn)：a) 統(tǒng)一標(biāo)準(zhǔn)b) 面向?qū)ο骳) 表達(dá)能力強(qiáng)大、可視化21. 軟件需求主要指一個(gè)軟件系統(tǒng)必須遵循的條件或具備的能力。軟件需求可以從兩方面描述：a) 系統(tǒng)的外部特性：用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或能力。b) 系統(tǒng)的內(nèi)部特性：系統(tǒng)為了滿足合同、規(guī)范或其他規(guī)定文檔所需具有的條件或能力。22. 需求分析的步驟：a) 需求獲取b) 需求建模c) 需求描述d) 需求驗(yàn)證23. 面向?qū)ο蟮男枨蠼) 畫(huà)用例

19、圖i. 確定參與者（參與者泛指所有存在于系統(tǒng)外部并與系統(tǒng)交互的人、硬件或其他系統(tǒng)。參與者主要是開(kāi)發(fā)系統(tǒng)的使用者）ii. 確定用例iii. 繪制和檢查用例圖b) 寫(xiě)用例規(guī)約i. 用例規(guī)約一般包含：1. 簡(jiǎn)要說(shuō)明2. 事件流3. 特殊需求4. 前置條件和后置條件c) 描述補(bǔ)充規(guī)約i. 補(bǔ)充規(guī)約用于記錄在用例模型中不宜表述的系統(tǒng)需求。24. 如何確定參與者：a) 系統(tǒng)開(kāi)發(fā)完成后，有哪些人使用該系統(tǒng)b) 系統(tǒng)需要從哪些人或系統(tǒng)中獲得數(shù)據(jù)c) 系統(tǒng)會(huì)為那些人或其他系統(tǒng)提供數(shù)據(jù)d) 系統(tǒng)會(huì)與哪些系統(tǒng)相關(guān)聯(lián)e) 系統(tǒng)由誰(shuí)來(lái)維護(hù)和管理25. 需求管理是伴隨著軟件需求的發(fā)展而成長(zhǎng)起來(lái)的管理技術(shù)。需求管理的5個(gè)實(shí)

20、踐：a) 獲得對(duì)需求的理解b) 獲取需求承諾c) 管理需求變更d) 在需求變更后維護(hù)對(duì)需求的雙向可追溯性e) 標(biāo)識(shí)項(xiàng)目工作與需求的不一致性面向?qū)ο蠓治?. 面向?qū)ο蠓治鯫OA的首要任務(wù)：a) 首先要理解用戶的需求，包括全面理解和分析用戶需求，明確所開(kāi)發(fā)的系統(tǒng)的職責(zé)，形成文件并規(guī)范的加以表述b) 然后進(jìn)行分析，提取類(lèi)和對(duì)象，并結(jié)合分析進(jìn)行建模。其步驟是：標(biāo)識(shí)類(lèi)，定義屬性和方法；刻畫(huà)類(lèi)的層次；表示對(duì)象以及對(duì)象與對(duì)象之間的關(guān)系；對(duì)象的行為建模。這些步驟可反復(fù)進(jìn)行，直至完成建模。結(jié)構(gòu)化分析SA有兩項(xiàng)基本任務(wù)：a) 建立系統(tǒng)分析模型b) 編寫(xiě)軟件需求規(guī)格說(shuō)明書(shū)SRS。SRS是分析階段編寫(xiě)的，以文字為主的

21、文檔。2. P 139 SA、OOA模型。3. 分析類(lèi)的查找：a) 邊界類(lèi)對(duì)象擔(dān)負(fù)著協(xié)調(diào)用例與參與者之間進(jìn)行交互的職責(zé)。一對(duì)（用例/參與者）對(duì)應(yīng)一個(gè)邊界類(lèi)b) 為每個(gè)用例設(shè)置一個(gè)控制類(lèi)c) 實(shí)體類(lèi)：需要長(zhǎng)期存儲(chǔ)的數(shù)據(jù)面向?qū)ο笤O(shè)計(jì)1. 模塊：模塊是一個(gè)擁有明確定義的輸入、輸出和特性的程序?qū)嶓w2. 模塊化設(shè)計(jì)的目的是按照規(guī)定的原則把大型軟件劃分為一個(gè)個(gè)較小的、相對(duì)獨(dú)立但相互關(guān)聯(lián)的模塊3. 分解和模塊獨(dú)立性是模塊化設(shè)計(jì)的兩個(gè)重要指導(dǎo)思想。a) 分解b) 模塊獨(dú)立性：概括了把軟件劃分為模塊時(shí)所要遵守的準(zhǔn)則。4. 模塊獨(dú)立性從兩個(gè)方面度量：模塊本身的內(nèi)聚和模塊間的耦合a) 內(nèi)聚指模塊內(nèi)部各個(gè)成分之間的聯(lián)

22、系b) 耦合指一個(gè)模塊和其他模塊間的聯(lián)系5. 內(nèi)聚是從功能的角度對(duì)模塊內(nèi)部聚合能力的度量a) 偶然性內(nèi)聚（在組成成分上互不相關(guān)，內(nèi)聚程度最弱）b) 邏輯性內(nèi)聚c) 時(shí)間性內(nèi)聚d) 過(guò)程性內(nèi)聚e) 通信性內(nèi)聚f) 順序性內(nèi)聚g) 功能性內(nèi)聚（塊內(nèi)聯(lián)系最強(qiáng)的內(nèi)聚，所有成分結(jié)合在一起，用于完成一個(gè)單一的功能）6. 耦合是對(duì)軟件內(nèi)部塊間聯(lián)系的度量：a) 非直接耦合b) 數(shù)據(jù)耦合c) 特征耦合d) 控制耦合e) 外部耦合f) 公共耦合g) 內(nèi)容耦合7. 面向?qū)ο笤O(shè)計(jì)的任務(wù)a) 系統(tǒng)架構(gòu)設(shè)計(jì)i. 系統(tǒng)高層結(jié)構(gòu)設(shè)計(jì)ii. 確定設(shè)計(jì)元素iii. 確定任務(wù)管理策略iv. 確定分布式實(shí)現(xiàn)機(jī)制v. 確定數(shù)據(jù)存儲(chǔ)策略

23、vi. 設(shè)計(jì)人機(jī)交互界面b) 系統(tǒng)元素設(shè)計(jì)i. 確定類(lèi)/對(duì)象ii. 確定子系統(tǒng)iii. 確定包8.軟件維護(hù)1. 軟件維護(hù)是指系統(tǒng)在交付運(yùn)行以后，為改正或滿足新的需要所進(jìn)行修改的過(guò)程。2. 軟件維護(hù)是軟件生存周期中花錢(qián)最多，延續(xù)時(shí)間最長(zhǎng)的環(huán)節(jié)。3. 軟件維護(hù)的類(lèi)型a) 完善性維護(hù)（在整個(gè)維護(hù)工作量中，占比高達(dá)50%60%，居于第一位）：不斷改善和加強(qiáng)產(chǎn)品的功能和性能，以滿足用戶日益增長(zhǎng)的需要。b) 適應(yīng)性維護(hù)：指使軟件適應(yīng)運(yùn)行環(huán)境的改變而進(jìn)行的一類(lèi)維護(hù)c) 糾錯(cuò)性維護(hù)：糾正在開(kāi)發(fā)期間未能發(fā)現(xiàn)的錯(cuò)誤d) 預(yù)防性維護(hù)：改善軟件的可維護(hù)性，減少今后對(duì)它們維護(hù)時(shí)所需要的工作量。4. 可維護(hù)性：衡量維護(hù)容

24、易程度的一種軟件屬性?？删S護(hù)性取決于軟件的可理解性、可修改性和可測(cè)試性，三者一起構(gòu)成軟件的質(zhì)量屬性。5. 軟件再工程：所謂軟件再工程是指將新技術(shù)和新工具應(yīng)用于老的軟件的一種較“徹底”的預(yù)防性維護(hù)。軟件測(cè)試1. 軟件測(cè)試是動(dòng)態(tài)查找程序代碼中的各類(lèi)錯(cuò)誤和問(wèn)題的過(guò)程。2. 測(cè)試的目的是為了發(fā)現(xiàn)程序中的錯(cuò)誤；糾錯(cuò)的目的是為了定位和改正程序中的錯(cuò)誤。3. 測(cè)試的任務(wù)是通過(guò)在計(jì)算機(jī)上執(zhí)行程序，暴露其中潛在的錯(cuò)誤；糾錯(cuò)的任務(wù)是消除軟件故障，保證程序的可靠運(yùn)行。4. 測(cè)試用例：一次程序執(zhí)行所需要的測(cè)試數(shù)據(jù)稱為一個(gè)測(cè)試用例。5. 測(cè)試用例 ：= 測(cè)試數(shù)據(jù)+期望結(jié)果，測(cè)試結(jié)果：=測(cè)試數(shù)據(jù)+期望結(jié)果+實(shí)際結(jié)果6.

25、測(cè)試的特性：a) 挑剔性：測(cè)試是為了證明程序有錯(cuò)而不是為了證明程序沒(méi)有錯(cuò)誤。只有抱著證明程序有錯(cuò)的目的去測(cè)試，才能把程序中潛在的所有錯(cuò)誤都找出來(lái)。b) 復(fù)雜性：測(cè)試用例的設(shè)計(jì)需要細(xì)致和高度的技巧。c) 不徹底性：程序測(cè)試只能證明程序錯(cuò)誤的存在，不能證明錯(cuò)誤不存在。其根本原因在于在實(shí)踐中無(wú)法進(jìn)行窮舉測(cè)試，即將所有的輸入情況在被測(cè)程序下執(zhí)行一遍。d) 經(jīng)濟(jì)型：要選擇典型的、有代表性的測(cè)試樣例。7. 測(cè)試的方法：a) 靜態(tài)分析法（并非由計(jì)算機(jī)執(zhí)行）i. 靜態(tài)分析器分析ii. 人工審查法1. 代碼會(huì)審2. 走查法3. 辦公桌檢查b) 動(dòng)態(tài)分析法i. 黑盒測(cè)試（測(cè)試系統(tǒng)的功能）ii. 白盒測(cè)試（測(cè)試系統(tǒng)的結(jié)構(gòu)）8. 黑盒測(cè)試：將待測(cè)試對(duì)象視作一個(gè)黑盒子，測(cè)試人員不考慮系統(tǒng)內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)在特性，只依據(jù)程序的需求規(guī)格說(shuō)明書(shū)，檢查程序的功能是否符合它的功能說(shuō)明。9. 黑盒測(cè)試的四種技術(shù)：a) 等價(jià)分類(lèi)法b) 邊界值分析法c) 錯(cuò)誤猜測(cè)法d) 因果圖法10. 白盒測(cè)試：將測(cè)試對(duì)象視作一個(gè)透明的盒子，測(cè)試人員可以根據(jù)系統(tǒng)的內(nèi)部特性和邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試樣例，對(duì)程序的所有邏輯路徑