涵蓋所有考點(diǎn)，復(fù)習(xí)絕對(duì)高效，點(diǎn)贊+留郵箱獲取pdf版本

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

本提綱可以完全摘抄，考試命中率100%，先上考試帶的A4紙：

1. 名詞解釋題

1. 軟件工程三要素

• 方法：為軟件開發(fā)提供了“如何做 ”的技術(shù)，如項(xiàng)目計(jì)劃與估算、軟件系統(tǒng)需求分析、數(shù)據(jù)結(jié)構(gòu)、系統(tǒng)總體結(jié)構(gòu)的設(shè)計(jì)等；
• 工具：為軟件工程方法提供了自動(dòng)的或半自動(dòng)的軟件支撐環(huán)境，如把軟件工具集成起來(lái)，建立起稱之為計(jì)算機(jī)輔助軟件工程 (CASE) 的軟件開發(fā)支撐系統(tǒng)。CASE 將各種軟件工具、開發(fā)機(jī)器和一個(gè)存放開發(fā)過(guò)程信息的工程數(shù)據(jù)庫(kù)組合起來(lái)形成一個(gè)軟件工程環(huán)境；
• 過(guò)程：將軟件工程的方法和工具綜合起來(lái)以達(dá)到合理、及時(shí)地進(jìn)行計(jì)算機(jī)軟件開發(fā)的目的，它定義了：方法使用的順序，要求交付的文檔資料，為保證質(zhì)量和適應(yīng)變化所需要的管理，軟件開發(fā)各個(gè)階段完成的里程碑。

2. 軟件工程原則

• 抽象：抽取事物最基本的特性和行為，忽略非基本的細(xì)節(jié)，采用分層次抽象，自頂向下、逐層細(xì)化的辦法控制軟件開發(fā)過(guò)程的復(fù)雜性；
• 信息隱蔽：將模塊設(shè)計(jì)成“黑箱”，實(shí)現(xiàn)的細(xì)節(jié)隱藏在模塊內(nèi)部，不讓模塊的使用者直接訪問(wèn)。這就是信息封裝，使用與實(shí)現(xiàn)分離的原則，使用者只能通過(guò)模塊接口訪問(wèn)模塊中封裝的數(shù)據(jù)；
• 模塊化：模塊是程序中邏輯上相對(duì)獨(dú)立的成分，是獨(dú)立的編程單位，應(yīng)有良好的接口定義。如C語(yǔ)言程序中的函數(shù)過(guò)程，C++語(yǔ)言程序中的類。模塊化有助于信息隱蔽和抽象，有助于表示復(fù)雜的系統(tǒng)；
• 確定性：軟件開發(fā)過(guò)程中所有概念的表達(dá)應(yīng)是確定的、無(wú)歧義性的、規(guī)范的。這有助于人們之間在交流時(shí)不會(huì)產(chǎn)生誤解、遺漏，保證整個(gè)開發(fā)工作協(xié)調(diào)一致；
• 一致性：整個(gè)軟件系統(tǒng)（包括程序、文檔和數(shù)據(jù)）的各個(gè)模塊應(yīng)使用一致的概念、符號(hào)和術(shù)語(yǔ)。程序內(nèi)部接口應(yīng)保持一致。軟件和硬件、操作系統(tǒng)的接口應(yīng)保持一致。系統(tǒng)規(guī)格說(shuō)明與系統(tǒng)行為應(yīng)保持一致。用于形式化規(guī)格說(shuō)明的公理系統(tǒng)應(yīng)保持一致；
• 完備性：軟件系統(tǒng)不丟失任何重要成分，可以完全實(shí)現(xiàn)系統(tǒng)所要求功能的程度。為了保證系統(tǒng)的完備性，在軟件開發(fā)和運(yùn)行過(guò)程中需要嚴(yán)格的技術(shù)評(píng)審；
• 可驗(yàn)證性：開發(fā)大型的軟件系統(tǒng)需要對(duì)系統(tǒng)自頂向下、逐層分解。系統(tǒng)分解應(yīng)遵循系統(tǒng)易于檢查、測(cè)試、評(píng)審的原則，以確保系統(tǒng)的正確性。

3. 軟件生命周期

4. 軟件開發(fā)過(guò)程

按照項(xiàng)目的進(jìn)度、成本和質(zhì)量限制，開發(fā)和維護(hù)滿足用戶需求的軟件所必需的一組有序的軟件開發(fā)活動(dòng)集合。

5. 統(tǒng)一開發(fā)過(guò)程

不僅僅是一個(gè)簡(jiǎn)單的軟件過(guò)程，而是一個(gè)通用的過(guò)程框架，可用于不同類型的應(yīng)用系統(tǒng)，它是基于構(gòu)件的，所構(gòu)造的軟件系統(tǒng)是由軟件構(gòu)件通過(guò)明確定義的接口相互鏈接所建造起來(lái)的。并且它使用 UML 語(yǔ)言來(lái)制定系統(tǒng)的所有藍(lán)圖。

6. 軟件過(guò)程模型

軟件過(guò)程模型是軟件開發(fā)全過(guò)程中軟件開發(fā)活動(dòng)以及它們之間關(guān)系的結(jié)構(gòu)框架，用于指導(dǎo)軟件的開發(fā)。常用的軟件過(guò)程模型有：

瀑布模型

瀑布模型將開發(fā)階段描述為從一個(gè)階段瀑布般地轉(zhuǎn)換到另一個(gè)階段，一個(gè)階段必須在另一個(gè)階段開始之前完成，每一個(gè)階段都伴隨著定義明確的里程碑和可交付產(chǎn)品。順序?yàn)椋?/p>

• 需求分析：軟件需求規(guī)格說(shuō)明書；
• 系統(tǒng)設(shè)計(jì)：軟件系統(tǒng)設(shè)計(jì)文檔；
• 程序設(shè)計(jì)：軟件功能模塊算法和數(shù)據(jù)描述文檔；
• 編碼：源程序和注釋；
• 單元和集成測(cè)試：?jiǎn)卧图蓽y(cè)試報(bào)告；
• 系統(tǒng)測(cè)試：系統(tǒng)測(cè)試報(bào)告；
• 驗(yàn)收測(cè)試：驗(yàn)收測(cè)試報(bào)告；
• 運(yùn)行和維護(hù)：維護(hù)報(bào)告；

優(yōu)點(diǎn)：中間產(chǎn)品和接口的定義明確，開發(fā)人員可以專注于完成每一個(gè)小的階段，測(cè)試和審核流程完備，系統(tǒng)整體質(zhì)量高；

缺點(diǎn)：缺乏靈活性，速度慢，不能反映實(shí)際的代碼開發(fā)方式；對(duì)開發(fā)人員的要求很高，必須在項(xiàng)目開始前說(shuō)明全部需求；最終產(chǎn)品直到最后才出現(xiàn)，而軟件客戶無(wú)法在早期直到軟件原型。

適用場(chǎng)合：①有穩(wěn)定的產(chǎn)品定義和需求分析；②容易理解但很復(fù)雜的項(xiàng)目；③質(zhì)量需求高于成本需求和進(jìn)度需求；④開發(fā)團(tuán)隊(duì)的技術(shù)力量較弱或缺乏經(jīng)驗(yàn)。

原型模型

開發(fā)人員在與用戶進(jìn)行需求分析時(shí)，以較小代價(jià)快速建立一個(gè)能反映用戶需求的原型系統(tǒng)，綜合用戶的意見對(duì)原型系統(tǒng)進(jìn)行完善，然后再由用戶評(píng)價(jià)，重復(fù)這一過(guò)程直到用戶滿意，再開始正式設(shè)計(jì)。

優(yōu)點(diǎn)：符合人們認(rèn)識(shí)事物的規(guī)律，縮短了用戶和開發(fā)人員之間的距離，確保設(shè)計(jì)的軟件是符合用戶要求的，縮短了整體開發(fā)周期；

缺點(diǎn)：難以模擬大型系統(tǒng)和批處理系統(tǒng)，文檔容易被忽略，項(xiàng)目難以清晰地規(guī)劃和管理。

適用場(chǎng)合：①不能預(yù)先確切定義需求的軟件系統(tǒng)；②開發(fā)人員不能很好地交流的情況。

增量模型

先開發(fā)系統(tǒng)的主要功能，然后，隨著時(shí)間推進(jìn)，不斷增加新的次要功能，最終開發(fā)出一個(gè)完整的軟件產(chǎn)品。

優(yōu)點(diǎn)：①有利于增加客戶對(duì)系統(tǒng)的信心；②降低系統(tǒng)失敗風(fēng)險(xiǎn)；提高系統(tǒng)可靠性，穩(wěn)定性和可維護(hù)性；

缺點(diǎn)：①增量粒度難以選擇；②每個(gè)增量必須依賴之前的增量，耦合度增加；③容易退化為邊做邊改，失去軟件過(guò)程的整體性。

適用場(chǎng)合：①進(jìn)行已有產(chǎn)品升級(jí)或新版本開發(fā)；②完成期限嚴(yán)格要求的產(chǎn)品；③已有原型系統(tǒng)；④開發(fā)人員整體水平有限，可以邊學(xué)習(xí)邊開發(fā)。

螺旋模型

螺旋模型的基本做法是在“瀑布模型”的每?個(gè)開發(fā)階段前，引入?個(gè)非常嚴(yán)格的風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)控制。它把軟件項(xiàng)目分解成?個(gè)個(gè)小項(xiàng)目，每個(gè)小項(xiàng)目都標(biāo)識(shí)?個(gè)或多個(gè)主要風(fēng)險(xiǎn)，直到所有的主要風(fēng)險(xiǎn)因素都被確定。

四象限：螺旋模型每次迭代有四個(gè)任務(wù)，依次是：計(jì)劃、目標(biāo)/可選方案、風(fēng)險(xiǎn)評(píng)估、 開發(fā)與測(cè)試；

四循環(huán)：螺旋模型共有四次迭代，依次是：操作概念、軟件需求、軟件設(shè)計(jì)、開發(fā)與測(cè)試。

優(yōu)點(diǎn)：①支持需求的動(dòng)態(tài)變化，具有良好的擴(kuò)展性；②易于用戶和開發(fā)人員共同理解需求，還可作為繼續(xù)開發(fā)的基礎(chǔ)；③強(qiáng)調(diào)風(fēng)險(xiǎn)分析，使軟件最終的安全性和穩(wěn)定性都大大提升；

缺點(diǎn)：①需要開發(fā)人員有豐富的風(fēng)險(xiǎn)評(píng)估知識(shí)；②開發(fā)周期長(zhǎng)，迭代次數(shù)多，可能延遲項(xiàng)目驗(yàn)收時(shí)間。

敏捷開發(fā)模型

為緩和傳統(tǒng)開發(fā)模型固守成規(guī)的缺點(diǎn)，提出了敏捷開發(fā)模型，它以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)，總體目標(biāo)是：盡早地、持續(xù)性地交付有價(jià)值的軟件，使客戶滿意。

敏捷宣言：

• 個(gè)人和交互 > 過(guò)程和工具：面對(duì)面溝通而不是文檔溝通；
• 軟件的生產(chǎn) > 文檔的編寫：成功的指標(biāo)是軟件正確工作的程度；
• 與客戶合作 > 合同和談判：以客戶的需求為主導(dǎo)核心；
• 對(duì)變化的反應(yīng) > 遵循計(jì)劃：不可能在開始時(shí)就能預(yù)測(cè)到所有變化。

極限編程：

是典型的敏捷開發(fā)方法，包含 4 個(gè)理念：①交流：客戶與開發(fā)人員之間持續(xù)地交換看法；②簡(jiǎn)單性：選擇簡(jiǎn)單的實(shí)現(xiàn)來(lái)滿足客戶的需要；③勇氣：盡早和經(jīng)常性地做出交付的承諾；④反饋：各種反饋活動(dòng)應(yīng)該貫穿整個(gè)過(guò)程。

敏捷管理實(shí)踐：

• 每日站立會(huì)議：每日工作前，由 Scrum Master 帶領(lǐng)團(tuán)隊(duì)成員準(zhǔn)時(shí)例行溝通項(xiàng)目進(jìn)展和解決方案；
• 可視化管理：將項(xiàng)目狀態(tài)通過(guò)物理實(shí)體實(shí)時(shí)展示，讓團(tuán)隊(duì)所有成員直觀地獲取當(dāng)前項(xiàng)目進(jìn)展信息；
• 用戶故事：站在用戶的視角，用簡(jiǎn)短的語(yǔ)句描述用戶需求；
• 結(jié)對(duì)編程：使用一個(gè)鍵盤，兩個(gè)結(jié)成對(duì)的程序員，一個(gè)負(fù)責(zé)敲入代碼，而另外一個(gè)實(shí)時(shí)檢視每一行敲入的代碼；
• 測(cè)試驅(qū)動(dòng)開發(fā)：在編寫任何代碼之前，首先編寫定義代碼功能的測(cè)試用例，編寫的代碼要通過(guò)用例；
• 持續(xù)集成：團(tuán)隊(duì)的成員經(jīng)常集成他們的工作，通常每人每天至少集成一次，大幅度縮短反饋周期；

優(yōu)點(diǎn)：①采用簡(jiǎn)單計(jì)劃策略，不需要長(zhǎng)期計(jì)劃和復(fù)雜模型，開發(fā)周期短；②在全過(guò)程采用迭代增量開發(fā)、反饋修正和反復(fù)測(cè)試的方法，能夠適應(yīng)用戶經(jīng)常變化的需求；③注重市場(chǎng)快速反應(yīng)能力，客戶前期滿意度高；

缺點(diǎn)：①注重人員的溝通，忽略文檔的重要性，若項(xiàng)目人員流動(dòng)大太，給維護(hù)帶來(lái)不少難度；②對(duì)編碼人員的經(jīng)驗(yàn)要求高，若項(xiàng)目存在新手比較多時(shí)，老員工比較累。

適用范圍：①項(xiàng)目經(jīng)常發(fā)生變更；②高風(fēng)險(xiǎn)的項(xiàng)目實(shí)施；③開發(fā)人員水平高，可以參與決策；④有優(yōu)秀的敏捷顧問(wèn)。

7. 跟蹤項(xiàng)目進(jìn)展

• 項(xiàng)目進(jìn)度：項(xiàng)目進(jìn)度是對(duì)特定項(xiàng)目的軟件開發(fā)周期的刻畫。包括對(duì)項(xiàng)目階段、步驟、活動(dòng)的分解，對(duì)各個(gè)離散活動(dòng)的交互關(guān)系的描述，以及對(duì)各個(gè)活動(dòng)完成時(shí)間及整個(gè)項(xiàng)目完成時(shí)間的初步估算。

• 活動(dòng)：項(xiàng)目的一部分，一般占用項(xiàng)目進(jìn)度計(jì)劃的一段時(shí)間；

• 里程碑：特定的時(shí)間節(jié)點(diǎn)，標(biāo)志著活動(dòng)的結(jié)束，通常伴隨著提交產(chǎn)物；

• WBS：Work Breakdown Structure，項(xiàng)?按?定的原則分解，項(xiàng)?分解成任務(wù)，任務(wù)再分解成?項(xiàng)項(xiàng)?作，再把?項(xiàng)項(xiàng)?作分配到每個(gè)?的??；顒?dòng)中，直到分解不下去為?，樹形表示；

• WBS 分解方法：①類比法：參考類似的項(xiàng)目方法或模板；②自頂向下法；③自底向上法；

• 活動(dòng)圖：描述活動(dòng)之間的依賴關(guān)系，圖中結(jié)點(diǎn)是項(xiàng)目里程碑，線表示活動(dòng)；

• AOE 網(wǎng)絡(luò)：有向圖 G 中，若用頂點(diǎn)代表事件，有向邊表示活動(dòng)，有向邊上的權(quán)值表示一項(xiàng)活動(dòng)持續(xù)的時(shí)間，則稱圖 G 為 AOE 網(wǎng)絡(luò)；

  • 關(guān)鍵路徑：從源點(diǎn)到匯點(diǎn)的最長(zhǎng)路徑；
  • 關(guān)鍵活動(dòng)：關(guān)鍵路徑上的活動(dòng)?；?qū)φ麄€(gè)工程的最短完成時(shí)間有影響的活動(dòng)。即如它不能按期完成就會(huì)影響整個(gè)工程。；

• 項(xiàng)目組織：

  • 民主制程序員組：小組成員完全平等，互相交流以做出決策，適用規(guī)模較小的組織；
  • 主程序員組：每個(gè)小組成員必須經(jīng)常與主程序員交流，而不必與其他小組成員交流；
  • 現(xiàn)代程序員組：結(jié)合民主制程序員組和主程序員組的優(yōu)點(diǎn)，“主程序員”由兩人擔(dān)任，技術(shù)負(fù)責(zé)人負(fù)責(zé)小組的技術(shù)活動(dòng)，行政負(fù)責(zé)人負(fù)責(zé)所有非技術(shù)的管理決策。

8. 軟件規(guī)模評(píng)估方法

①代碼行分析法；②功能點(diǎn)分析法；③專家判斷技術(shù)；④標(biāo)準(zhǔn)回歸技術(shù)；⑤神經(jīng)網(wǎng)絡(luò)技術(shù)；⑥貝葉斯分析技術(shù)；⑦類比法。

9. 軟件風(fēng)險(xiǎn)

使軟件項(xiàng)目的實(shí)施受到影響和損失、甚至導(dǎo)致失敗的、可能會(huì)發(fā)生的事件。

• 風(fēng)險(xiǎn)影響：發(fā)生風(fēng)險(xiǎn)后會(huì)造成的損失；
• 風(fēng)險(xiǎn)概率：發(fā)生風(fēng)險(xiǎn)的概率；
• 風(fēng)險(xiǎn)暴露：= 風(fēng)險(xiǎn)影響 × 風(fēng)險(xiǎn)概率，量化風(fēng)險(xiǎn)所造成的影響；
• 降低風(fēng)險(xiǎn)的三種策略：
  • 避免風(fēng)險(xiǎn)：通過(guò)改變軟件的性能或功能需求；
  • 轉(zhuǎn)移風(fēng)險(xiǎn)：把風(fēng)險(xiǎn)分配到其它系統(tǒng)中，或購(gòu)買保險(xiǎn)；
  • 控制風(fēng)險(xiǎn)：預(yù)先假設(shè)風(fēng)險(xiǎn)會(huì)發(fā)生，接受并采取措施提前控制；
• 風(fēng)險(xiǎn)杠桿：= (降低前的風(fēng)險(xiǎn)暴露 - 降低后的風(fēng)險(xiǎn)暴露) / 降低風(fēng)險(xiǎn)的成本，如果杠桿值不夠高，不足以證明采取措施的理由，那么可以采取其它措施降低風(fēng)險(xiǎn)。

10. CASE

計(jì)算機(jī)輔助軟件工程，用來(lái)支持管理系統(tǒng)開發(fā)的、由各種計(jì)算機(jī)輔助軟件和工具組成的大型綜合性軟件開發(fā)環(huán)境，如圖工具、流程建模工具、文檔編寫工具、集成測(cè)試工具的集合。

11. 需求

需求是對(duì)期望的行為的表達(dá)，是用戶需解決某一問(wèn)題或達(dá)到某一目標(biāo)所需的軟件功能；

• 功能需求：描述系統(tǒng)預(yù)期提供的功能或服務(wù)；
• 非功能需求：指那些不直接與系統(tǒng)具體功能相關(guān)的一類需求，如并發(fā)性，響應(yīng)時(shí)間，可靠性；
• 領(lǐng)域需求：源于系統(tǒng)的應(yīng)用領(lǐng)域需求，如敏感信息下載后要及時(shí)刪除；

12. OCL（對(duì)象約束語(yǔ)言）

Object Constraint Language，是一個(gè)形式化語(yǔ)言，和 ER 圖或 UML 緊密結(jié)合在一起，用于表示類圖中的不變量、前置條件、后置條件、轉(zhuǎn)移條件等，幫助類圖表示地更清晰。

13. 原型化需求

開發(fā)人員快速構(gòu)建一個(gè)原型以確保是否符合用戶需求，在需求確定后再開始正式開發(fā)；

• 拋棄型原型：編寫快速但不考慮質(zhì)量的原型，可以迅速抓住問(wèn)題的核心，一旦確定需求就拋棄掉它，速度快但可迭代性差；
• 演化型原型：編寫的原型不僅要抓住問(wèn)題核心，還要迭代成為最終產(chǎn)品，速度慢但可迭代性高；
• 快速原型化：上述兩種方法統(tǒng)稱為快速原型化。

14. 設(shè)計(jì)過(guò)程模型：

軟件系統(tǒng)設(shè)計(jì)是一個(gè)迭代的過(guò)程，最終結(jié)果是軟件體系結(jié)構(gòu)文檔（SAD）。

15. 分解

自頂向下地分解軟件涉及的每一個(gè)模塊，幫助開發(fā)者更好地把握軟件設(shè)計(jì)流程，幾個(gè)流行的分解方案為：

• 面向功能的分解：把功能或需求分解成模塊；
• 面向特征的分解：也是把功能或需求分解成模塊，但是為模塊制定了細(xì)化的特征；
• 面向數(shù)據(jù)的分解：將數(shù)據(jù)分解成模塊；
• 面向進(jìn)程的分解：將系統(tǒng)分解成一系列并發(fā)的進(jìn)程；
• 面向事件的分解：將系統(tǒng)處理的事件分解成模塊；
• 面向?qū)ο蟮姆纸猓簩?duì)象分解成模塊；

16. 模塊化的

當(dāng)系統(tǒng)的每個(gè)活動(dòng)都僅由對(duì)應(yīng)的軟件單元實(shí)現(xiàn)，并且每個(gè)軟件單元的輸入和輸出都已經(jīng)明確地被定義時(shí)，設(shè)計(jì)才可以說(shuō)是模塊化的；

17. 定義明確的

如果一個(gè)軟件單元的接口能夠準(zhǔn)確無(wú)誤地指定該單元的外部可見行為，則稱該軟件單元是定義明確的；

18. 視圖

將軟件分解形成為構(gòu)件后，將它們合適地排列以展示各個(gè)構(gòu)件之間的交互和系統(tǒng)整體的架構(gòu)的一種表示形式；體系結(jié)構(gòu)視圖包含以下幾種：

• 分解視圖：例如 UML 用例圖，是層次化的分解，使用了多種模型，每個(gè)模塊是可編程的；
• 依賴視圖：展示了軟件單元之間的依賴關(guān)系，幫助確定哪些單元是獨(dú)立的，哪些是耦合的；
• 泛化視圖：展示了一個(gè)軟件單元是否被另一個(gè)單元所泛化，在設(shè)計(jì)抽象單元時(shí)經(jīng)常使用；
• 執(zhí)行視圖：傳統(tǒng)的 方框->箭頭 視圖，展示了系統(tǒng)運(yùn)行時(shí)的結(jié)構(gòu)，每個(gè)構(gòu)件都是執(zhí)行實(shí)體；
• 實(shí)現(xiàn)視圖：在代碼單元和源文件之間建立映射，有助于管理源代碼；
• 部署視圖：在運(yùn)行實(shí)體和 IT 資源之間建立映射，幫助分析系統(tǒng)的底層設(shè)計(jì)；
• 工作分配視圖：每個(gè)構(gòu)件是分配給團(tuán)隊(duì)成員的任務(wù)，有助于項(xiàng)目管理；

19. 體系結(jié)構(gòu)風(fēng)格

體系結(jié)構(gòu)風(fēng)格反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語(yǔ)義特性，并指導(dǎo)如何將各個(gè)模塊和子系統(tǒng)有效地組織成一個(gè)完整的系統(tǒng)。

經(jīng)典的體系結(jié)構(gòu)風(fēng)格：

• 管道/過(guò)濾器：將數(shù)據(jù)輸入到過(guò)濾器中得到輸出數(shù)據(jù)，通過(guò)管道將數(shù)據(jù)從一個(gè)過(guò)濾器中傳輸?shù)较乱粋€(gè)過(guò)濾器；

  • 優(yōu)點(diǎn)：
    • 各個(gè)模塊相對(duì)獨(dú)立，在輸入和輸出定義清楚后，便于模塊化開發(fā)和測(cè)試；
    • 支持一些特定的分析，例如吞吐量計(jì)算和死鎖檢測(cè)；
    • 并發(fā)性高，當(dāng)一個(gè)模塊的吞吐量達(dá)到瓶頸后，可以新增一個(gè)同樣的構(gòu)建分擔(dān)壓力；
  • 缺點(diǎn)：
    • 交互式處理能力弱；
    • 具體實(shí)現(xiàn)比較復(fù)雜，例如要考慮數(shù)據(jù)流同步問(wèn)題和數(shù)據(jù)加解密問(wèn)題；

• 層次結(jié)構(gòu)：整個(gè)系統(tǒng)被組織成一個(gè)分層結(jié)構(gòu)，每一層為上層提供服務(wù)，并作為下一層的客戶。

  

  • 優(yōu)點(diǎn)：

    • 層次結(jié)構(gòu)風(fēng)格支持系統(tǒng)設(shè)計(jì)過(guò)程中的逐級(jí)抽象；
    • 基于層次結(jié)構(gòu)風(fēng)格的系統(tǒng)具有較好的可擴(kuò)展性；
    • 層次結(jié)構(gòu)風(fēng)格支持軟件復(fù)用；

  • 缺點(diǎn)：

    • 并不是每個(gè)系統(tǒng)都可以很容易地劃分為分層的模式；
    • 很難找到一個(gè)合適的、正確的層次抽象方法；

• C/S 風(fēng)格：C/S 體系結(jié)構(gòu)有三個(gè)主要組成部分：客戶機(jī)、服務(wù)器和專用的網(wǎng)絡(luò)；

  • 優(yōu)點(diǎn)：①界面豐富，可操作性高；②安全性高；③響應(yīng)速度快；
  • 缺點(diǎn)：①適用范圍窄；②用戶群固定；③維護(hù)成本高；④需安裝專門的軟件；

• B/S 風(fēng)格：B/S體系結(jié)構(gòu)有三個(gè)主要組成部分：瀏覽器、 Web 服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器；

  • 優(yōu)點(diǎn)：①維護(hù)和升級(jí)方式簡(jiǎn)單；②交互性強(qiáng)；③對(duì)客戶機(jī)的配置要求低；
  • 缺點(diǎn)：①在速度和安全性上需要花費(fèi)巨大的成本；②需要刷新頁(yè)面；③通信開銷大；

20. 設(shè)計(jì)原則

設(shè)計(jì)原則是指把系統(tǒng)功能和行為分解成模塊的指導(dǎo)方針。

六種重要的設(shè)計(jì)原則：

• 模塊化：把系統(tǒng)中各不相關(guān)的部分進(jìn)行分離的原則，以便于各部分能夠獨(dú)立研究，也稱為關(guān)注點(diǎn)分離，每個(gè)模塊都有自己唯一的目的，并且相對(duì)獨(dú)立于其它模塊。

  使用兩個(gè)概念來(lái)度量模塊的獨(dú)立程度：耦合度和內(nèi)聚度；

  • 耦合度：兩個(gè)模塊之間存在著很強(qiáng)的依賴關(guān)系稱為緊密耦合，兩個(gè)模塊之間存在較少依賴關(guān)系稱為松散耦合，模塊之間沒(méi)有任何依賴關(guān)系稱為無(wú)耦合。耦合越松散，模塊之間的聯(lián)系就越小，模塊的獨(dú)立性就越強(qiáng)。

    常見的耦合類型：

    • 非直接耦合：兩個(gè)模塊都能獨(dú)立地工作而不需要另一個(gè)模塊的存在，耦合度最低；
    • 數(shù)據(jù)耦合：兩個(gè)模塊彼此之間通過(guò)傳參交換數(shù)據(jù)，稱為數(shù)據(jù)耦合；
    • 標(biāo)記耦合：兩個(gè)模塊之間傳參交換復(fù)雜的數(shù)據(jù)結(jié)構(gòu)變量，如數(shù)組、類名；
    • 控制耦合：兩個(gè)模塊之間傳遞的信息是控制信息，表現(xiàn)在循環(huán)和條件判斷語(yǔ)句中；
    • 公共耦合：各模塊訪問(wèn)同一個(gè)公共數(shù)據(jù)，如共享內(nèi)存區(qū)，只讀的公共耦合是松散耦合，讀寫的公共耦合是緊密耦合；
    • 內(nèi)容耦合：耦合度最高，①一個(gè)模塊直接訪問(wèn)另一個(gè)模塊的內(nèi)部數(shù)據(jù)；②一個(gè)模塊通過(guò)分支進(jìn)入了另一個(gè)模塊；③模塊之間的代碼發(fā)送重疊；

    盡量使用數(shù)據(jù)耦合，少用控制耦合，限制公共耦合的范圍，完全不采用內(nèi)容耦合。

  • 內(nèi)聚度：內(nèi)聚是衡量一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度，一個(gè)模塊內(nèi)聚程度越高，說(shuō)明該模塊內(nèi)部各元素之間的關(guān)聯(lián)也就越強(qiáng)。

    內(nèi)聚度由低到高為：

    • 偶然內(nèi)聚：只是因?yàn)榍珊匣蚍奖愕脑?，不相關(guān)的功能、進(jìn)程或數(shù)據(jù)處于同一個(gè)模塊中，是最差的一種內(nèi)聚，模塊不易理解，不易維護(hù)，不易重用；
    • 邏輯內(nèi)聚：模塊中的各個(gè)部分只通過(guò)代碼的邏輯結(jié)構(gòu)相關(guān)聯(lián)，但實(shí)際功能沒(méi)有關(guān)聯(lián)；
    • 時(shí)間內(nèi)聚：各個(gè)元素必須在同一時(shí)間內(nèi)執(zhí)行（比如系統(tǒng)初始化），優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，缺點(diǎn)是模塊結(jié)合了許多無(wú)關(guān)的任務(wù)，一旦模塊失敗，難以定位錯(cuò)誤位置；
    • 過(guò)程內(nèi)聚：元素之間有順序關(guān)系，調(diào)用前面元素之后，緊接著調(diào)用后面的，例如必須先進(jìn)行詞法分析，才能進(jìn)行語(yǔ)法分析；
    • 通信內(nèi)聚：模塊各功能部分都操作同一輸入 ，或產(chǎn)生同一輸出，例如語(yǔ)法分析和語(yǔ)義分析都操作詞法分析的結(jié)果，都輸出中間代碼；
    • 順序內(nèi)聚：模塊內(nèi)的處理元素和同一個(gè)功能密切相關(guān)，而且這些處理必須順序執(zhí)行，前一元素的輸出就是下一元素的輸入，例如將詞法分析–>語(yǔ)法分析–>語(yǔ)義分析和中間代碼生成整合成一個(gè)模塊；順序內(nèi)聚模塊中的各個(gè)部分在功能和執(zhí)行順序上都密切相關(guān)，構(gòu)成個(gè)不可分割的整體，因此內(nèi)聚程度高且易于理解；
    • 功能內(nèi)聚：一個(gè)模塊內(nèi)所有處理元素僅為完成功能而協(xié)同工作，緊密聯(lián)系，不可分割，且沒(méi)有副作用，則稱為功能內(nèi)聚。功能內(nèi)聚是最高程度的內(nèi)聚。在設(shè)計(jì)時(shí)應(yīng)盡可能使模塊到達(dá)功能內(nèi)聚這一級(jí)。

• 接口：接口定義了模塊能正確工作的環(huán)境，以及格式化的輸入輸出，隱藏了模塊實(shí)現(xiàn)細(xì)節(jié)；

• 信息隱藏：對(duì)使用模塊的用戶隱藏模塊實(shí)現(xiàn)相關(guān)的信息，例如用戶只需要知道函數(shù)能夠排序，而不需管其底層是冒泡排序還是快速排序；

• 增量式開發(fā)：將每個(gè)模塊看作一個(gè)增量組件，并按優(yōu)先級(jí)分批次分析、設(shè)計(jì)、開發(fā)、測(cè)試和交付增量組件；

• 抽象：忽略細(xì)節(jié)，提煉出模塊之間的共性，或建設(shè)整體視圖，或設(shè)計(jì)接口類；

• 通用性：開發(fā)軟件時(shí)，盡量使其成為通用的軟件，以便在將來(lái)將其復(fù)用到另一系統(tǒng)中；

21. 面向?qū)ο笕笤瓌t

封裝、繼承和多態(tài)；

22. 面向?qū)ο笤O(shè)計(jì)原則

• 單一職責(zé)原則：一個(gè)類只負(fù)責(zé)一個(gè)職責(zé)，這樣可以增加模塊的可復(fù)用性，系統(tǒng)整體高內(nèi)聚、低耦合；

• 開閉原則：一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉，即在不改變本身代碼的情況下其行為能擴(kuò)展，面臨新的需求時(shí)，不要更改已有的代碼，而是在其基礎(chǔ)上進(jìn)行擴(kuò)展；

  • 抽象化是開閉原則的關(guān)鍵；

• 里氏代換原則：一個(gè)軟件如果使用的是一個(gè)父類的話，那么一定適用于其子類，而察覺(jué)不出父類對(duì)象和子類對(duì)象的區(qū)別。也即是說(shuō)，在軟件里面，把父類替換成它的子類，程序的行為不會(huì)有變化，簡(jiǎn)單地說(shuō)，子類型必須能夠替換掉它們的父類型；

  • 反過(guò)來(lái)則不成立，如果一個(gè)軟件實(shí)體使用的是一個(gè)子類的話，那么它不一定能夠使用基類；
  • 在程序中盡量使用基類類型來(lái)對(duì)對(duì)象進(jìn)行定義，而在運(yùn)行時(shí)再確定其子類類型，用子類對(duì)象來(lái)替換父類對(duì)象；
  • 子類可以擴(kuò)展父類的方法，但是不能修改父類的方法，本質(zhì)上也是對(duì)開閉原則的一種完善；

• 依賴倒轉(zhuǎn)原則：高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。

  • 要針對(duì)接口編程，不要針對(duì)實(shí)現(xiàn)編程；
  • 常用實(shí)現(xiàn)方式之一是在代碼中使用抽象類，而將具體類放在配置文件中；
  • 以抽象方式耦合是依賴倒轉(zhuǎn)原則的關(guān)鍵；

  例如，下圖1未實(shí)現(xiàn)依賴倒轉(zhuǎn)原則，圖2實(shí)現(xiàn)了依賴倒轉(zhuǎn)原則：

  

  

• 合成復(fù)用原則：盡量使用對(duì)象組合，而不是繼承來(lái)達(dá)到復(fù)用的目的；

  • 復(fù)用時(shí)要盡量使用 組合/聚合 關(guān)系，少用繼承；
  • 繼承復(fù)用稱為白箱復(fù)用，因?yàn)楦割悓?duì)子類是完全透明的，組合/聚合 復(fù)用是黑箱復(fù)用；

  例如，下圖1是繼承復(fù)用，冗余項(xiàng)多且龐雜，圖2是聚合復(fù)用，簡(jiǎn)介且易維護(hù)：

  

  

• 迪米特法則：又稱為最少知識(shí)原則，一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少的與其他實(shí)體發(fā)生相互作用，這樣，當(dāng)一個(gè)模塊修改時(shí)，就會(huì)盡量少的影響其他的模塊，擴(kuò)展會(huì)相對(duì)容易；

  • 可以降低類之間的耦合度，從而允許它們獨(dú)立地被開發(fā)、優(yōu)化、使用和修改；
  • 迪米特法則的主要用途在于控制信息的過(guò)載，例如應(yīng)盡量創(chuàng)造松耦合的類，盡量降低對(duì)類成員變量和函數(shù)的訪問(wèn)權(quán)限，盡量降低類對(duì)象對(duì)其它對(duì)象的引用次數(shù)；

  例如，下圖1未使用迪米特原則，圖2使用了迪米特原則：

  

  

23. 面向?qū)ο笤O(shè)計(jì)模式

是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)，設(shè)計(jì)模式通過(guò)實(shí)現(xiàn)面向?qū)ο笃叽笤瓌t，從而達(dá)到了代碼復(fù)用、增加可維護(hù)性的目的。

• 單例模式：這種模式涉及到一個(gè)單一的類，該類負(fù)責(zé)創(chuàng)建自己的對(duì)象，同時(shí)確保只有單個(gè)對(duì)象被創(chuàng)建。這個(gè)類提供了一種訪問(wèn)其唯一的對(duì)象的方式，可以直接訪問(wèn)，不需要實(shí)例化該類的對(duì)象。

  • 為避免其它程序過(guò)多地建立該類的對(duì)象，先禁止其它程序建立該類對(duì)象實(shí)例；
  • 餓漢式：對(duì)象預(yù)先加載，線程是安全的，在類創(chuàng)建好的同時(shí)對(duì)象生成，調(diào)用獲得對(duì)象實(shí)例的方法反應(yīng)速度快，代碼簡(jiǎn)練；
  • 懶漢式：對(duì)象延遲加載，效率高，只有在使用的時(shí)候才實(shí)例化對(duì)象，若設(shè)計(jì)不當(dāng)線程會(huì)不安全，代碼相對(duì)于餓漢式復(fù)雜，第一次加載類對(duì)象的時(shí)候反應(yīng)不快。

• 建造者模式：將一個(gè)復(fù)雜對(duì)象的構(gòu)造與它的表示分離，使同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示，這樣的設(shè)計(jì)模式被稱為建造者模式。它是將一個(gè)復(fù)雜的對(duì)象分解為多個(gè)簡(jiǎn)單的對(duì)象，然后一步一步構(gòu)建而成。它將變與不變相分離，即產(chǎn)品的組成部分是不變的，但每一部分是可以靈活選擇的。

  • 實(shí)例：

    用建造者（Builder）模式描述客廳裝修。

    分析：客廳裝修是一個(gè)復(fù)雜的過(guò)程，它包含墻體的裝修、電視機(jī)的選擇、沙發(fā)的購(gòu)買與布局等?？蛻舭蜒b修要求告訴項(xiàng)目經(jīng)理，項(xiàng)目經(jīng)理指揮裝修工人一步步裝修，最后完成整個(gè)客廳的裝修與布局，所以本實(shí)例用建造者模式實(shí)現(xiàn)比較適合。

    這里客廳是產(chǎn)品，包括墻、電視和沙發(fā)等組成部分。具體裝修工人是具體建造者，他們負(fù)責(zé)裝修與墻、電視和沙發(fā)的布局。項(xiàng)目經(jīng)理是指揮者，他負(fù)責(zé)指揮裝修工人進(jìn)行裝修。

    另外，客廳類中提供了 show() 方法，可以將裝修效果圖顯示出來(lái)。客戶端程序通過(guò)對(duì)象生成器類 ReadXML 讀取 XML 配置文件中的裝修方案數(shù)據(jù)，調(diào)用項(xiàng)目經(jīng)理進(jìn)行裝修。其類圖如圖所示：

    

    • 建造者模式的主要優(yōu)點(diǎn)如下：

      • 客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)，將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過(guò)程解耦，使得相同的創(chuàng)建過(guò)程可以創(chuàng)建不同的產(chǎn)品對(duì)象；
      • 每一個(gè)具體建造者都相對(duì)獨(dú)立，與其他的具體建造者無(wú)關(guān)，因此可以很方便地替換具體建造者或增加新的具體建造者，擴(kuò)展方便，符合開閉原則；
      • 可以更加精細(xì)地控制產(chǎn)品的創(chuàng)建過(guò)程；

    • 其缺點(diǎn)如下：

      • 建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點(diǎn)，其組成部分相似，如果產(chǎn)品之間的差異性很大，不適合使用建造者模式，因此其使用范圍受到一定的限制；
      • 如果產(chǎn)品的內(nèi)部變化復(fù)雜，可能會(huì)需要定義很多具體建造者類來(lái)實(shí)現(xiàn)這種變化，導(dǎo)致系統(tǒng)變得很龐大，增加了系統(tǒng)的理解難度和運(yùn)行成本。

• 觀察者模式：觀察者（Observer）是指多個(gè)對(duì)象間存在一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。這種模式有時(shí)又稱作發(fā)布-訂閱模式、模型-視圖模式，它是對(duì)象行為型模式。

  • 模式動(dòng)機(jī)：建立一種對(duì)象與對(duì)象之間的依賴關(guān)系，一個(gè)對(duì)象發(fā)生改變時(shí)將自動(dòng)通知其他對(duì)象，其他對(duì)象將相應(yīng)做出反應(yīng)。在此，發(fā)生改變的對(duì)象稱為觀察目標(biāo)，而被通知的對(duì)象稱為觀察者，一個(gè)觀察目標(biāo)可以對(duì)應(yīng)多個(gè)觀察者，而且這些觀察者之間沒(méi)有相互聯(lián)系，可以根據(jù)需要增加和刪除觀察者，使得系統(tǒng)更易于擴(kuò)展，這就是觀察者模式的模式動(dòng)機(jī)。

  • 實(shí)例：

    利用觀察者模式設(shè)計(jì)一個(gè)程序，分析人民幣匯率的升值或貶值對(duì)進(jìn)口公司進(jìn)口產(chǎn)品成本或出口公司的出口產(chǎn)品收入以及公司利潤(rùn)率的影響。

    分析：當(dāng)“人民幣匯率”升值時(shí)，進(jìn)口公司的進(jìn)口產(chǎn)品成本降低且利潤(rùn)率提升，出口公司的出口產(chǎn)品收入降低且利潤(rùn)率降低；當(dāng)“人民幣匯率”貶值時(shí)，進(jìn)口公司的進(jìn)口產(chǎn)品成本提升且利潤(rùn)率降低，出口公司的出口產(chǎn)品收入提升且利潤(rùn)率提升。

    這里的匯率（Rate）類是抽象目標(biāo)類，它包含了保存觀察者（Company）的 List 和增加/刪除觀察者的方法，以及有關(guān)匯率改變的抽象方法 change(int number)；而人民幣匯率（RMBrate）類是具體目標(biāo)， 它實(shí)現(xiàn)了父類的 change(int number) 方法，即當(dāng)人民幣匯率發(fā)生改變時(shí)通過(guò)相關(guān)公司；公司（Company）類是抽象觀察者，它定義了一個(gè)有關(guān)匯率反應(yīng)的抽象方法 response(int number)；進(jìn)口公司（ImportCompany）類和出口公司（ExportCompany）類是具體觀察者類，它們實(shí)現(xiàn)了父類的 response(int number) 方法，即當(dāng)它們接收到匯率發(fā)生改變的通知時(shí)作為相應(yīng)的反應(yīng)。下圖所示是其 UML 結(jié)構(gòu)圖。

    

  • 觀察者模式的優(yōu)點(diǎn)：

    • 具體目標(biāo)和具體觀察者是松耦合關(guān)系，觀察者接口的引入降低了系統(tǒng)的復(fù)雜度；
    • 觀察模式滿足“開-閉原則”。目標(biāo)接口僅僅依賴于觀察者接口，系統(tǒng)的可復(fù)用性和可擴(kuò)展性得到提升。

  • 觀察者模式的缺點(diǎn)：

    • 如果一個(gè)觀察者關(guān)聯(lián)很多實(shí)例的話，將所有的實(shí)例都通知到會(huì)花費(fèi)很多時(shí)間；
    • 如果在觀察者和觀察目標(biāo)之間有循環(huán)依賴的話，觀察目標(biāo)會(huì)觸發(fā)它們之間進(jìn)行循環(huán)調(diào)用，可能導(dǎo)致系統(tǒng)崩潰；
    • 觀察者模式?jīng)]有相應(yīng)的機(jī)制讓觀察者知道所觀察的目標(biāo)對(duì)象是怎么發(fā)生變化的，而僅僅只是知道觀察目標(biāo)發(fā)生了變化。

• 中介者模式：定義一個(gè)中介對(duì)象來(lái)封裝一系列對(duì)象之間的交互，使原有對(duì)象之間的耦合松散，且可以獨(dú)立地改變它們之間的交互。中介者模式又叫調(diào)停模式，它是迪米特法則的典型應(yīng)用。

  • 實(shí)例：

    用中介者模式編寫一個(gè)“房地產(chǎn)交流平臺(tái)”程序。

    分析：首先，定義一個(gè)中介公司（Medium）接口，它是抽象中介者，它包含了客戶注冊(cè)方法 register(Customer member) 和信息轉(zhuǎn)發(fā)方法 relay(String from,String ad)；再定義一個(gè)房地產(chǎn)中介（EstateMedium）公司，它是具體中介者類，它包含了保存客戶信息的 List 對(duì)象，并實(shí)現(xiàn)了中介公司中的抽象方法。

    然后，定義一個(gè)客戶（Customer）類，它是抽象同事類，其中包含了中介者的對(duì)象，和發(fā)送信息的 send(String ad) 方法與接收信息的 receive(String from，String ad) 方法的接口，由于本程序是窗體程序，所以本類繼承 JPmme 類，并實(shí)現(xiàn)動(dòng)作事件的處理方法 actionPerformed(ActionEvent e)。

    最后，定義賣方（Seller）類和買方（Buyer）類，它們是具體同事類，是客戶（Customer）類的子類，它們實(shí)現(xiàn)了父類中的抽象方法，通過(guò)中介者類進(jìn)行信息交流，其結(jié)構(gòu) UML 圖如下：

    

  • 中介者模式的優(yōu)點(diǎn)為：

    • 類之間各司其職，符合迪米特法則；
    • 降低了對(duì)象之間的耦合性，使得對(duì)象易于獨(dú)立地被復(fù)用；
    • 將對(duì)象間的一對(duì)多關(guān)聯(lián)轉(zhuǎn)變?yōu)橐粚?duì)一的關(guān)聯(lián)，提高系統(tǒng)的靈活性，使得系統(tǒng)易于維護(hù)和擴(kuò)展；

  • 中介者模式的缺點(diǎn)為：

    • 中介者模式將原本多個(gè)對(duì)象直接的相互依賴變成了中介者和多個(gè)同事類的依賴關(guān)系。當(dāng)同事類越多時(shí)，中介者就會(huì)越臃腫，變得復(fù)雜且難以維護(hù)。

24. 復(fù)用

有兩種類型的復(fù)用：生產(chǎn)者復(fù)用和消費(fèi)者復(fù)用；

• 生產(chǎn)者復(fù)用：正在設(shè)計(jì)的構(gòu)件要在以后的應(yīng)用中進(jìn)行復(fù)用；
• 消費(fèi)者復(fù)用：正在使用的構(gòu)件是之前為其它應(yīng)用開發(fā)的構(gòu)件；

25. 編程過(guò)程

XP、結(jié)對(duì)編程、融合、小組協(xié)同；

26. 軟件測(cè)試術(shù)語(yǔ)

• 錯(cuò)誤（error）：往往是人為導(dǎo)致的故障；
• 故障（fault）：程序中不正確的步驟，過(guò)程或者數(shù)據(jù)定義，導(dǎo)致程序出現(xiàn)了非故意的、不可預(yù)料的行為，通常是由 error 導(dǎo)致的；
• 失效（failure）：一個(gè)系統(tǒng)或者組件不能完成它被要求的功能，通常是 fault 導(dǎo)致的；

27. 故障類型

• 算法故障：源代碼編寫或算法設(shè)計(jì)上的一些錯(cuò)誤導(dǎo)致的故障；
• 計(jì)算故障和精度故障：算術(shù)表達(dá)式錯(cuò)誤或計(jì)算結(jié)果未達(dá)到要求的精度；
• 文檔故障：文檔與程序?qū)嶋H做的事情不一致；
• 能力故障或邊界故障：系統(tǒng)活動(dòng)到達(dá)指定的極限時(shí)，系統(tǒng)性能會(huì)變得不可接受；
• 計(jì)時(shí)故障或協(xié)調(diào)故障：實(shí)時(shí)系統(tǒng)的并發(fā)進(jìn)程之間同步互斥關(guān)系出現(xiàn)故障；
• 吞吐量故障或性能故障：系統(tǒng)不能以需求規(guī)定的速度執(zhí)行；
• 標(biāo)準(zhǔn)和過(guò)程故障：代碼規(guī)范或風(fēng)格不合符組織的要求；

28. 軟件測(cè)試基本步驟

• 單元測(cè)試：將系統(tǒng)中的每個(gè)程序構(gòu)件與其它構(gòu)件隔離，單獨(dú)測(cè)試每個(gè)構(gòu)件是否能正常運(yùn)行；
• 集成測(cè)試：確保構(gòu)件之間的接口能正常運(yùn)行，各構(gòu)件正常協(xié)作；
• 功能測(cè)試：是對(duì)系統(tǒng)的整體評(píng)估，以確定集成的系統(tǒng)是否確實(shí)執(zhí)行了需求規(guī)格中描述的功能，其結(jié)果是一個(gè)可運(yùn)轉(zhuǎn)的系統(tǒng)；
• 性能測(cè)試：測(cè)試系統(tǒng)在客戶的實(shí)際工作環(huán)境中能否成功執(zhí)行，其結(jié)果是一個(gè)確認(rèn)的系統(tǒng)；
• 驗(yàn)收測(cè)試：與客戶交換意見，以確定滿足了客戶的預(yù)期，與客戶進(jìn)行確認(rèn)后完成驗(yàn)收；
• 安裝測(cè)試：將驗(yàn)收后的系統(tǒng)安裝在它實(shí)際工作的環(huán)境中，確保能正確工作。

29. 單元測(cè)試方法

• 靜態(tài)測(cè)試（程序不執(zhí)行）：一般是檢查代碼的風(fēng)格和規(guī)范。

  • 靜態(tài)分析器（自動(dòng)工具）；
  • 代碼評(píng)審（人工方式）；

• 動(dòng)態(tài)測(cè)試（程序執(zhí)行）：通過(guò)選擇適當(dāng)?shù)臏y(cè)試用例，執(zhí)行程序。

  • 黑盒測(cè)試（測(cè)試功能）：不考慮程序的內(nèi)部結(jié)構(gòu)與特性，只根據(jù)程序功能或程序的外部特性設(shè)計(jì)測(cè)試用例。

    • 等價(jià)類分類法：將可能的輸入劃分成若干等價(jià)的類，每一個(gè)類選擇一個(gè)測(cè)試用例；

      • 有效等價(jià)類：有意義、合理的輸入數(shù)據(jù)，用于評(píng)估系統(tǒng)功能；
      • 無(wú)效等價(jià)類：無(wú)意義、不合理的輸入數(shù)據(jù)，用于檢測(cè)程序異常；

      例如，注冊(cè)某網(wǎng)站。要求：用戶名的長(zhǎng)度為8_{12的數(shù)字與字母組合而成的字符，，密碼長(zhǎng)度為6}16位的數(shù)字、字母的組合。請(qǐng)寫出測(cè)試案例：

      

      確定了等價(jià)類之后我們就可以設(shè)計(jì)測(cè)試用例了，測(cè)試用例需要覆蓋到所有的等價(jià)類，即有效等價(jià)類和無(wú)效等價(jià)類。具體情況請(qǐng)看下表：

      

    • 邊值分析法：對(duì)輸入的邊界值進(jìn)行測(cè)試，例如，對(duì)16-bit 的整數(shù)而言 32767 和 -32768 是邊界；屏幕上光標(biāo)在最左上、最右下位置。

    • 錯(cuò)誤推測(cè)法：在測(cè)試程序時(shí)，人們可以根據(jù)經(jīng)驗(yàn)或直覺(jué)推測(cè)程序中可能存在的各種錯(cuò)誤，從而有針對(duì)性地編寫檢查這些錯(cuò)誤的測(cè)試用例的方法。

    • 因果圖法：適合輸入條件比較多的情況，可以測(cè)試所有的輸入條件的排列組合?！?因 ” 就是輸入條件，“ 果 ” 就是輸出結(jié)果。

  • 白盒測(cè)試（測(cè)試結(jié)構(gòu)）：分析程序的內(nèi)部邏輯結(jié)構(gòu)，注意選擇適當(dāng)?shù)母采w標(biāo)準(zhǔn)，設(shè)計(jì)測(cè)試用例，對(duì)主要路徑進(jìn)行盡可能多的測(cè)試。

    白盒法又稱為邏輯覆蓋法，常用的邏輯覆蓋標(biāo)準(zhǔn)：

    • 語(yǔ)句覆蓋：程序中每個(gè)語(yǔ)句至少都能被執(zhí)行一次；
    • 判定覆蓋：程序中每個(gè)判定至少為 true 或 false 各一次；
    • 條件覆蓋：判定語(yǔ)句中的每個(gè)條件表達(dá)式都至少為 true 或 false 各一次，滿足條件覆蓋的，不一定滿足判定覆蓋；
    • 判定/條件覆蓋： 同時(shí)滿足判定覆蓋和條件覆蓋；
    • 條件組合覆蓋： 判定中條件的各種可能組合都至少出現(xiàn)一次，例如判定語(yǔ)句 i 有 n 個(gè)條件，每個(gè)條件有 true 和 false 選項(xiàng)，則至少需要 2^n 個(gè)用例才能覆蓋語(yǔ)句 i。

30. 集成測(cè)試

把功能模塊或程序單元組合起來(lái)進(jìn)行測(cè)試，發(fā)現(xiàn)模塊在組合過(guò)程中的缺陷。

• 驅(qū)動(dòng)模塊：用于模擬待測(cè)模塊的上級(jí)模塊。驅(qū)動(dòng)模塊在集成測(cè)試中接受測(cè)試數(shù)據(jù)，將相關(guān)的數(shù)據(jù)傳送給待測(cè)模塊，啟動(dòng)待測(cè)模塊，并打印出相應(yīng)的結(jié)果；
• 樁模塊：用于模擬待測(cè)模塊工作過(guò)程中所調(diào)用的模塊。樁模塊由待測(cè)模塊調(diào)用，它們一般只進(jìn)行很少的數(shù)據(jù)處理，以便于檢驗(yàn)待測(cè)模塊與下級(jí)模塊的接口。

集成測(cè)試的分類：

• 非增量式集成策略：對(duì)所有模塊進(jìn)行單元測(cè)試后，將各模塊連接起來(lái)，把連接后的程序當(dāng)作一個(gè)整體進(jìn)行測(cè)試。

• 增量式集成策略：逐次將未曾集成測(cè)試的模塊和已經(jīng)集成測(cè)試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過(guò)程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過(guò)程中產(chǎn)生的問(wèn)題。

  增量式集成測(cè)試又可以分為三種不同的方法：

  • 自頂向下增量式測(cè)試：模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按 DFS 或 BFS 方式集成到結(jié)構(gòu)中去。

    整個(gè)過(guò)程由 3 個(gè)步驟完成：

    • 主控模塊作為測(cè)試驅(qū)動(dòng)器；
    • 下層的樁模塊一次一次地被替換為真正的模塊；
    • 每個(gè)模塊被集成時(shí)，都必須進(jìn)行單元測(cè)試。重復(fù)第2步，直到整個(gè)系統(tǒng)被測(cè)試完成。

    例題：對(duì)如下結(jié)構(gòu)采用自頂向下深度優(yōu)先策略進(jìn)行測(cè)試：

    

    

    優(yōu)缺點(diǎn)分析：

    • 優(yōu)點(diǎn)：①較早地驗(yàn)證了主要控制和判斷點(diǎn)；②可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；③功能較早證實(shí)，帶來(lái)信心；④只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開發(fā)的費(fèi)用；
    • 缺點(diǎn)：①樁的開發(fā)量大；②底層驗(yàn)證被推遲；
    • 適用范圍：①產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；②高層接口變化較小；③底層接口未定義或經(jīng)?？赡鼙恍薷?；④產(chǎn)品控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；⑤希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

  • 自底向上增量式測(cè)試：最常用的集成策略，從具有最小依賴性的底層組件開始，按照依賴關(guān)系樹的結(jié)構(gòu)，逐層向上集成，以檢驗(yàn)系統(tǒng)的穩(wěn)定性。

    整個(gè)過(guò)程由 4 個(gè)步驟完成：

    • 起始于模塊依賴關(guān)系樹的底層葉子模塊；
    • 使用驅(qū)動(dòng)模塊對(duì)步驟１選定的模塊進(jìn)行測(cè)試；
    • 用實(shí)際模塊代替驅(qū)動(dòng)模塊，與它已測(cè)試的直屬子模塊組裝成一個(gè)更大的模塊進(jìn)行測(cè)試；
    • 重復(fù)上面的行為，直到系統(tǒng)最頂層模塊被加入到已測(cè)系統(tǒng)中。

    

    優(yōu)缺點(diǎn)分析：

    • 優(yōu)點(diǎn)：①對(duì)底層組件行為較早驗(yàn)證；②工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；③能較好鎖定軟件故障所在位置。

    • 缺點(diǎn)：①驅(qū)動(dòng)的開發(fā)工作量大；②對(duì)高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。

    • 適用范圍：①適應(yīng)于底層接口比較穩(wěn)定；②高層接口變化比較頻繁；③底層組件較早被完成。

  • 三明治增量式測(cè)試：把系統(tǒng)劃分成三層，中間一層為目標(biāo)層，目標(biāo)層之上采用自頂向下集成，之下采用自底向上集成。

    

    整個(gè)過(guò)程由 4 個(gè)步驟完成：

    • 首先對(duì)目標(biāo)層之上一層使用自頂向下集成；
    • 其次對(duì)目標(biāo)層之下一層使用自底向上集成；
    • 其三，把目標(biāo)層下面一層與目標(biāo)層集成；
    • 最后，把三層集成到一起。

    優(yōu)缺點(diǎn)分析：

    • 優(yōu)點(diǎn)：集合了自頂向下和自底向上兩種策略的優(yōu)點(diǎn)；
    • 缺點(diǎn)：中間層測(cè)試不充分，難以選擇；
    • 適用范圍：適應(yīng)于大部分軟件開發(fā)項(xiàng)目。

31. 軟件缺陷數(shù)目估計(jì)方法

• 播撒模型：

  • Mills 模型：人工隨機(jī)置入錯(cuò)誤 M 個(gè)錯(cuò)誤，測(cè)試得出 m 個(gè)人工置入的錯(cuò)誤，n 個(gè)程序固有的錯(cuò)誤，則估算系統(tǒng)固有錯(cuò)誤為：
    $$N=\frac{n\times M}{m}$$

  • Hyman 模型：兩人同時(shí)進(jìn)行測(cè)試，A 發(fā)現(xiàn) n 個(gè)錯(cuò)誤，B 發(fā)現(xiàn) m 個(gè)錯(cuò)誤，其中共同錯(cuò)誤有 q 個(gè)，則估算系統(tǒng)的固有錯(cuò)誤為：
    $$N=\frac{m\times n}{q}$$

• 靜態(tài)模型：根據(jù)軟件的規(guī)模和復(fù)雜性進(jìn)行估計(jì)。

• 根據(jù)測(cè)試覆蓋率的預(yù)測(cè)模型：

  

2. 綜合題

2.1 繪制 AOE 網(wǎng)

步驟：

• 計(jì)算事件的最早發(fā)生時(shí)間表，earliest(j) = max{earliest(i) + w(i, j)}；
• 計(jì)算事件的最晚發(fā)生時(shí)間表，latest(i) = mim{latest(j) - w(i, j)}；

例1

如下圖所示的AOE網(wǎng)（弧上權(quán)值代表活動(dòng)的持續(xù)天數(shù)，求：

1）繪制事件的最早發(fā)生時(shí)間和最晚發(fā)生時(shí)間；

2）繪制活動(dòng)的最早開始時(shí)間和最晚開始時(shí)間；

3）哪些是關(guān)鍵活動(dòng)，給出關(guān)鍵路徑；

4）完成此工程最少所需要多少天。

2.2 COCOMO 模型

基本工作量計(jì)算公式如下：
$$E=a\times KLO{C}^b\times F$$

① 基本 COCOMO：

$$E=a\times KLO{C}^b\times 1$$

一個(gè) 33.3 KLOC 的軟件開發(fā)項(xiàng)目，屬于中等規(guī)模、半有機(jī)型的項(xiàng)目，采用基本COCOMO：a = 3.0，b = 1.12，則：
$$E=3.0\times 33.3^{1.12}\times 1=152pm$$

② 中等 COCOMO：

$$F=\prod _{i=1}^{17}E{M}_i$$

$$E=a\times KLO{C}^b\times F$$

一個(gè) 33.3 KLOC 的軟件開發(fā)項(xiàng)目，屬于中等規(guī)模、半有機(jī)型的項(xiàng)目，采用中等 COCOMO 模型。 a = 3.0，b=1.12，則：
$$F＝0.70\times 0.85\times ...\times 1.15=1.09$$

$$E=3.0\times 33.3^{1.12}\times 1.09＝16pm$$

③ 高級(jí) COCOMO：

$$b=0.91+0.01\sum _{i=1}^5{b}_i$$

$$F=\prod _{i=1}^{17}E{M}_i$$

$$E=a\times KLO{C}^b\times F$$

a 是校正常數(shù)，通常取值 2.94（根據(jù)公司大量數(shù)據(jù)進(jìn)行調(diào)整）。

2.3 決策樹分析

2.4 E-R 圖

在 ER 圖中有如下 4 個(gè)成分：

• 矩形框：表示實(shí)體，在框中記入實(shí)體名；
• 菱形框：表示實(shí)體和實(shí)體之間的聯(lián)系，在框中記入聯(lián)系名；
• 橢圓形框：表示實(shí)體或聯(lián)系的屬性，將屬性名記入框中，對(duì)于主屬性名應(yīng)加入下劃線；
• 連線：實(shí)體與屬性之間；實(shí)體與聯(lián)系之間；聯(lián)系與屬性之間用直線相連，并在直線上標(biāo)注聯(lián)系的類型；
  • 對(duì)于一對(duì)一聯(lián)系(1 ∶1)：要在兩個(gè)實(shí)體連線方向各寫1；
  • 對(duì)于一對(duì)多聯(lián)系(1 ∶N) ：要在一的一方寫1，多的一方寫N；
  • 對(duì)于多對(duì)多關(guān)系(N∶M) : 則要在兩個(gè)實(shí)體連線方向各寫 N,M。

例題1：用圖書、作者兩個(gè)實(shí)體及其屬性和聯(lián)系構(gòu)建E-R圖。

• 圖書的屬性：書號(hào)、書名、出版社、價(jià)格；
• 作者的屬性：身份證號(hào)、姓名、年齡；

例題2：某企業(yè)集團(tuán)有若干工廠，每個(gè)工廠生產(chǎn)多種產(chǎn)品，且每一種產(chǎn)品可以在多個(gè)工廠生產(chǎn)，每個(gè)工廠按照固定的計(jì)劃數(shù)量生產(chǎn)產(chǎn)品，計(jì)劃數(shù)量不低于300；每個(gè)工廠聘用多名職工，且每名職工只能在一個(gè)工廠工作，工廠聘用職工有聘期和工資。工廠的屬性有工廠編號(hào)、廠名、地址，產(chǎn)品的屬性有產(chǎn)品編號(hào)、產(chǎn)品名、規(guī)格，職工的屬性有職工號(hào)、姓名、技術(shù)等級(jí)。

2.5 UML 圖

類圖以反映類的結(jié)構(gòu)(屬性、操作)以及類之間的關(guān)系為主要目的，描述了軟件系統(tǒng)的結(jié)構(gòu)，是一種靜態(tài)建模方法。從上到下分為三部分，分別是類名、屬性和操作。

類圖中的關(guān)系：

• 依賴關(guān)系：描述了一個(gè)類的變化對(duì)依賴于它的類產(chǎn)生影響的情況；

  虛線 + 箭頭表示

  

  

  

• 關(guān)聯(lián)關(guān)系：用帶箭頭的線段表示，表示類之間的聯(lián)結(jié)，一個(gè)類使用了另一個(gè)類的方法；

  

  

  

• 聚合關(guān)系：特殊關(guān)聯(lián)關(guān)系，指明一個(gè)聚集（整體）和組成部分之間的關(guān)系。例如，多名學(xué)生聚合成了一個(gè)班級(jí)，學(xué)生不會(huì)因?yàn)榘嗉?jí)的解散而無(wú)法存在，教室需要同時(shí)知道班級(jí)和學(xué)生的信息，二者的生命周期是獨(dú)立的；

  

• 組合關(guān)系：語(yǔ)義更強(qiáng)的聚合，部分和整體具有相同的生命周期。例如，學(xué)生由器官組成，器官的生命周期被嚴(yán)格封裝在學(xué)生中，只需要了解學(xué)生的信息即可；

  

  

• 泛化關(guān)系：在面向?qū)ο笾幸话惴Q為繼承關(guān)系，存在于父類與子類、父接口與子接口之間；

  

  

  

• 實(shí)現(xiàn)關(guān)系：對(duì)應(yīng)于類和接口之間的關(guān)系；

  虛線 + 空心三角形表示

  

  

  

2.6 Petri 網(wǎng)

例題1

例題2

有一工業(yè)生產(chǎn)線，要完成兩項(xiàng)操作，分別為變遷 t1 和 t2 表示，變遷 t1 將進(jìn)入生產(chǎn)線，半成品 s1s2 用兩個(gè)部件 s3 固定在一起，后形成中間件 s4。然后第2個(gè)變遷 t2 將 s4 和 s5 用 3 個(gè)部件 s3 固定在一起形成中間件 s6。完成 t1 和 t2 都需要用到工具 s7。

假設(shè)受空間限制，s2、s5 最多不能超過(guò) 100 件， s4 最多不能超過(guò) 5 件，s3 最多不能超過(guò) 1000 件。

其 Petri 網(wǎng)結(jié)果如下：

2.7 數(shù)據(jù)流圖

頂層圖：中間的橢圓是需要開發(fā)的系統(tǒng) , 周邊的矩形表示外部實(shí)體人或組織；

中層圖：將 “頂層數(shù)據(jù)流圖” 進(jìn)行細(xì)化，外部實(shí)體不變；

底層圖：針對(duì)每個(gè)加工 節(jié)點(diǎn) , 將其拆分 , 繪制其中的更詳細(xì)的數(shù)據(jù)流轉(zhuǎn)情況；

**例題：**圖書預(yù)訂系統(tǒng)：書店向顧客發(fā)放訂單，顧客將所填訂單交由系統(tǒng)處理，系統(tǒng)首先依據(jù)圖書目錄對(duì)訂單進(jìn)行檢查并對(duì)合格訂單進(jìn)行處理，處理過(guò)程中根據(jù)顧客情況和訂單數(shù)目將訂單分為優(yōu)先訂單與正常訂單兩種，隨時(shí)處理優(yōu)先訂單，定期處理正常訂單。最后系統(tǒng)根據(jù)所處理的訂單匯總，并按出版社要求發(fā)給出版社。

• 第一步，畫出關(guān)聯(lián)數(shù)據(jù)流圖：

  

• 第二步，逐層分解加工，畫出下層 DFD：

  

• 第三步，細(xì)化中間過(guò)程，畫出底層 DFD：

  

2.8 UML 用例圖

類似于頂層的數(shù)據(jù)流圖，描述了系統(tǒng)和用戶的上層交互情況。

• 用例圖中的關(guān)系及解釋

  

• 例題1：

  參與者：經(jīng)理，安全主管，保安

  用例：管理人事，批準(zhǔn)預(yù)算，批準(zhǔn)安全證書，監(jiān)視周邊

  

• 例題 2：

  短途旅行但汽車的油不足以應(yīng)付全部路程。那么為汽車加油的動(dòng)作在旅行的每個(gè)場(chǎng)景（事件流）中都會(huì)出現(xiàn)，不加油就不會(huì)完成旅行。吃飯則可以由司機(jī)決定是否進(jìn)行，不吃飯不會(huì)影響旅行的完成。

  

2.9 故障樹分析

故障樹是一種為研究系統(tǒng)某功能故障而建立的一種倒樹狀的邏輯因果關(guān)系圖。

割集樹的邊緣就是故障樹的割集，表示引起樹頂失效所需事件的最小集合。

若已知故障樹的割集以及底事件發(fā)送的概率，則頂事件發(fā)送的概率為各割集元素發(fā)生概率之和。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-548108.html

到了這里，關(guān)于【軟件工程】山東大學(xué)軟件工程復(fù)習(xí)提綱的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！