山東大學-軟件工程復習重點整理

1、第一章1.1軟件工程（SE的定義、方向、作用:SE :在將有關軟件開發(fā)與應用的概念科學體系化的基礎上，研究如何有計劃、有效率、經濟的開發(fā)和利用能在就算機上正確運行的軟件的理論和技術的工程方法學，一些開發(fā)和維護軟件的方法、過程、原則。是一個系統(tǒng)工程，既有對技術問題的分析與綜合，也有對開發(fā)過程和參 與者的管理。SE的方向：面向對象模式，結構化模式，基于過程的模式等SE的作用：付出較低的開發(fā)成本，達到要求的軟件功能，取得較好的軟件性能，開發(fā)的軟件 易于移植，需要較低的維護費用，能按時完成開發(fā)工作，及時交付使用。1.2開發(fā)模式：軟件開發(fā)的全部過程，活動和任務的結構框架，它能直觀的表達的表達軟件開 發(fā)全

2、過程，明確要完成的主要活動，任務和開發(fā)策略。込說明錯誤、故障和失效的含義及聯(lián)系（并舉例）:錯誤：是在軟件生產過程中人為產生的錯誤（需求說明中的錯誤，代碼中的錯誤）故障：是在功能實現過程中產生的問題；是錯誤導致的結果，是在軟件中一個錯誤的表現 （一個錯誤可能產生多個缺陷，靜態(tài)存在的）失效：是相對于系統(tǒng)指定行為的偏離，系統(tǒng)違背了它應有的行為（動態(tài)存在的）聯(lián)系：當一個開發(fā)者編寫程序時，會在代碼中出現錯誤。當這個程序被編譯或集成到一個系 統(tǒng)中時，系統(tǒng)就存在故障。當你運行這個系統(tǒng)時，可能會導致失效，即人們產生錯誤，故障是 錯誤的結果（內部觀角：從開發(fā)者的角度看待問題），當故障執(zhí)行時出現失效（外部視角：從

3、 用戶角度看到的問題）。并不是所有的錯誤會導致故障，并非每個缺陷都對應相應的失敗。1.4 軟件質量應從哪幾個方面衡量，論述之：（1產品的質量）（2過程的質量）（3商業(yè)環(huán)境背景下的質量）（1） 產品的質量：用戶從失敗的數目和類型等外部特征進行評價，如果軟件具有足夠的 功能 并且易于學習和使用，用戶就斷定軟件是高質量的；開發(fā)者從 缺陷的數目和類型等內部特征 來 作為產品質量的依據。（2） 過程的質量：有很多過程都會影響到最終的產品質量，只要有活動出了差錯，產品的質 量就會受到影響；開發(fā)和維護過程的質量與產品的質量是同等重要的。（3）商業(yè)環(huán)境背景下的軟件質量：將技術價值和商業(yè)價值統(tǒng)一起來。1.5軟件

4、系統(tǒng)的系統(tǒng)組成（系統(tǒng)的要素有哪些）：對象（實體） +活動+ 關系+ 系統(tǒng)邊界活動：活動是發(fā)生在系統(tǒng)中的某些事情，通常描述為由某個觸發(fā)器引發(fā)的事件，活動通過改 變屬性把一個事物變成另一個事物。對象：活動中涉及的元素稱為對象。關系：是指活動與對象之間的關系。系統(tǒng)邊界：即系統(tǒng)包含的功能與系統(tǒng)不包含的功能之間的界限。1.6現代軟件工程大致包含幾個階段及各個階段的文檔：（1）需求分析：主要包括問題定義、可行性分析、需求分析需求規(guī)格說明書（2）系統(tǒng)設計：主要包括用戶界面和軟件結構圖（3）程序設計：包括模塊功能算法與數據描述（4）程序實現：主要包括編程的代碼和注釋（5）單元測試：模塊測試與性能測試（6）集成

5、測試：按照結構圖進行測試產生測試報告（7）系統(tǒng)測試：按 SRS對系統(tǒng)總體功能進行測試（8）系統(tǒng)提交：交付產品（9）系統(tǒng)維修：修改軟件的過程，為滿足改錯或新需求1.7使現代軟件工程實踐發(fā)生變化的關鍵因素是什么？（1）商用產品投入市場時間的緊迫性（2）計算技術在經濟中的轉變：更低的硬件成本，更高的開發(fā)、維護成本（3）功能強大的桌面計算的可用性（4）廣泛的局域網和廣域網（5）面向對象技術的采用及其有效性（6）使用窗口、圖標、菜單和指示器的圖形用戶界面（7）軟件開發(fā)瀑布模型的不可預測性1.8什么是抽象？抽象是在某種概括層次上對問題的描述 ，使得我們能夠 集中于問題的關鍵方面 而不陷入細節(jié), 也就是對細

6、節(jié)的隱藏。1.9什么是重（復）用？重（復）用采用 以前開發(fā)的軟件系統(tǒng)中具有共性的部件，用到新的開發(fā)項目中去。（這里的重用不僅僅是代碼的重用。）1.10什么是軟件危機？它有哪些典型表現？為什么會出現軟件危機？軟件危機：落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發(fā)與 維護過程中出現一系列嚴重問題的現象。典型表現：（1）對軟件開發(fā)成本和進度的估計常常很不準確。（2）用戶對“已完成”軟件系統(tǒng)不滿意的現象經常發(fā)生。（3）軟件產品的質量往往靠不住。（4）軟件常常是不可維護的。（5）軟件通常沒有適當的文檔資料。（6）軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升。（7）軟件開發(fā)生產率

7、提高的速度，遠跟不上計算機應用迅速普及深入的趨勢出現的原因：一方面與軟件本身的特點有關，另一方面也和軟件開發(fā)與維護的方法不正確有 關。（1）軟件缺乏“可見性”，管理和控制軟件開發(fā)過程相當困難（2）軟件規(guī)模龐大，而且程序復雜性將隨著程序規(guī)模的增加而呈指數上升（3）開發(fā)時期引入錯誤，導致軟件維護通常意味著改正或修改原來的設計，客觀上使得軟件較難維護（4）軟件專業(yè)人員對軟件開發(fā)和維護中或多或少地采用了錯誤的方法和技術1.11開發(fā)隊伍的組成角色有哪些？需求分析人員、設計人員、程序員、測試人員、培訓人員、維護人員、資料員、配置管理人員CMM是指"能力成熟度模型”，其英文全稱為 Capabili

8、ty Maturity Model for Software，英文縮寫為SW-CMM簡稱CMM它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程 的實踐中各個發(fā)展階段的描述。CMM勺核心是把軟件開發(fā)視為一個過程。SRSSoftware Requireme nts Specificatio n）,軟件需求說明書 的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎。包含硬件、功能、性能、輸入輸出、接口界面、警示信息、保密安全、數據與數據庫、文檔和法規(guī)的要求。第二章2.1什么叫過程（生命周期）？過程是一組有序的任務，它涉及活動、約束和資源使用 的一

9、系列步驟，用于產生某種想要的 輸出。我們有時也把 涉及產品構建的這種過程稱為生命周期 。因此，有時把軟件開發(fā)過程稱為 軟件生命周期。2.2什么是軟件過程，軟件過程的重要性是什么？軟件過程：將軟件開發(fā)中的一組有序的任務稱為軟件過程，它涉及活動、約束和資源使用的 一系列步驟，用于產生某種想要的輸出。重要性：（1 ）它強制活動具有一致性和一定的結構，使程序的集合組合起來以產生滿足目標和標準的產品，（2）過程結構允許我們 分析、理解、控制和改進組成過程的活動，并以此來指導我們的行動（3）它能使我們獲取經驗并把它創(chuàng)收給他人。2.3什么是軟件生命周期模型？軟件生命周期模型，是從一個特定角度提出的對軟件過程

10、的簡化描述，是對軟件開發(fā)實際過程的抽象，它包括構成軟件過程的各種活動、軟件工件以及參與角色等。2.4瀑布模型及其優(yōu)缺點瀑布模型：瀑布模型將開發(fā)階段描述為從一個開發(fā)階段瀑布般地轉換到另外一個階段，一個開發(fā)階段必須在另一個開發(fā)階段開始之前完成。瀑布模從一種非常高層的角度描述了開發(fā)過程 中進行的活動，并且提出了要求開發(fā)人員經過的時間序列。優(yōu)點：（1）瀑布模型一直用來規(guī)范軟件開發(fā)活動，每一個過程活動都有與其相關聯(lián)的里程碑和可交付產品，以便于項目經理能夠用模型判斷在某一時刻項目里最后完成還有多遠。（2）它的簡單性使得開發(fā)人員很容易向不熟悉軟件開發(fā)用戶作出解釋。（3） 很多更復雜的模型實際上是在瀑布模型的

11、基礎上的潤色，如加入反饋循環(huán)以及額 外的活動。缺點：（1）它并不能反映實際的代碼開發(fā)方式。除了一些理解非常充分的問題之外，實際上軟件是通過大量的迭代 進行開發(fā)的。（2）它沒有揭示每一個活動如何把一種制品轉化為另外一種制品（3）沒有把軟件看做一個問題求解的過程，而是從制造業(yè)的角度來看待軟件開發(fā)的， 軟件開發(fā)應該是一個創(chuàng)造的過程，而不是制造的過程。2.5什么是原型？原型是一個部分開發(fā)的產品，它使客戶和開發(fā)人員能夠對計劃開發(fā)的系統(tǒng)的相關方面進行檢 查，以決定它對最終產品是否合適或恰當。2.6V模型及其特點V模型是瀑布模型的變種，它說明測試活動是如何與分析和設計相聯(lián)系 的，編碼處于 V形符號的頂點，分

12、析和設計在左邊，測試和維護在右邊。特點：V模型使得隱藏在瀑布模型中的迭代和重做活動更加明確。瀑布模型關注的通常是文 檔和制品，而V模型關注的則是活動和正確性。2.7原型模型不僅僅是附屬于瀑布模型的，同時也是一種有效的過程模型的基礎。原型模型允許開發(fā)人員 快速構造整個系統(tǒng)或系統(tǒng)的一部分以理解或澄清問題。依據原型化的目標，可以取消原型化需求、設計或系統(tǒng)中的一個或多個循環(huán)，但是總體目標 保持不變，即減少開發(fā)中的風險和不確定性。2.8可轉換模型可轉換模型通過 去除某些主要開發(fā)步驟來設法減少出錯的機會。2.9階段化開發(fā)模型的含義、分類和特點（運行系統(tǒng)和開發(fā)系統(tǒng)的概念）階段化開發(fā)模型的含義：系統(tǒng)被設計為一

13、部分一部分地交付，從而在系統(tǒng)其余部分正在開發(fā)的同時，用戶已經獲得了一部分的功能。分類：（1）增量開發(fā)：系統(tǒng)按照功能劃分為子系統(tǒng)，定義發(fā)布時首先定義一個小的功能子系 統(tǒng)，然后在每一個新的發(fā)布中增加新功能。（2）迭代開發(fā)：一開始就提交一個完整的系統(tǒng)，然后在每一個新的發(fā)布中改變每個子 系統(tǒng)的功能。特點：（1）即使還缺少某些功能，但在早期的發(fā)布中就可以開始培訓。（2）可以及早為那些以前從未提供的功能開拓市場。（3）當運行系統(tǒng)出現未預料到的問題時，經常性的發(fā)布可以使開發(fā)人員能全面、快速 地修復這些問題（4）針對不同的發(fā)布版本，開發(fā)團隊將重點放在不同的專業(yè)領域技術上。2.10螺旋模型的含義、目的、四個象限

14、的任務及四重迭代的含義含義：螺旋模型將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統(tǒng)。目的：把開發(fā)活動和風險管理結合起來，以將風險減到最小并控制風險。四個象限的任務依次是：評估可選方案及風險；確定目標、可選方案及約束；計劃；開發(fā)與測試四重迭代的含義：（1）操作概念 是第一次迭代的產品；（2）需求是第二次迭代的主要產品；（3）第三次迭代產中，系統(tǒng)開發(fā) 產生設計；（4）第四次迭代能夠進行測試。（5）螺旋模型的 每一次迭代都根據需求和約束進行風險分析，以權衡不同的選擇，并且在確定某一特定選擇之 前，通過原型化驗證可行性或期望度。當風險確認之后，項目經理必須決

15、定如何消除或最小化 風險。2.11敏捷方法的含義、特點和目標：含義：以人為核心、迭代、循序漸進。在敏捷開發(fā)中，軟件項目的構建被切分成多個子項目， 各個子項目的成果都經過測試，具備集成和可運行的特征。特點：（1）規(guī)則游戲（2）小的發(fā)布（3）隱喻（4）簡單設計（5）首先編寫測試（6）重構（7）對編程（8）集體所有權（9）持續(xù)集成（10）可以忍受的步伐（11）在現場的客戶（12） 代碼標準目標：通過盡可能早地、持續(xù)地交付有價值的軟件使客戶滿意。2.12在所有的軟件開發(fā)模型中，你認為哪些過程給予你最大的靈活性以應對需求的變更?階段開發(fā)模型和螺旋模型補充：統(tǒng)一過程（UP可以用三句話來表達：它是用例驅動的

16、、以基本架構為中心的、迭代式和增量性的軟件開發(fā)過程框架，它使用對象管理組織 （OMGQbject Management Group）的UML并與對象管理組織（OMG的軟件過程工程原模型（SPEM（ Software Process EngineeringMeta-Model ）軟件過程工程元模型）等相兼容。第三章3.1什么是項目進度？項目進度通過 列舉項目的各個階段， 把每個階段分解成離散的任務或活動，來描述特定項目的軟件開發(fā)周期。進度還描繪這些活動之間的交互，并估算每項任務或活動將或花費時間。3.2什么是活動？什么是里程碑？活動：活動是項目的一部分，它在一段時間內發(fā)生。 里程碑：里程碑是活動

17、的完成 -某一特定時刻。3.3軟件人員應該具備的能力是什么？（1）完成工作的能力（2）對工作的興趣（3）開發(fā)類似應用的經驗（4）使用類似工具或語 言的經驗（5）使用類似開發(fā)環(huán)境的經驗（6）使用類似技術的經驗（7）培訓（8）與其他人交 流的能力（9）與其他人共同承擔責任的能力（10）管理技能 3.4軟件項目組織的基本結構Chief programmerAssistant chrcf programmer3.5專家估測法的大致含義：很多工作量估算方法依賴于專家的判斷。使用專家的知識和經驗，對軟件項目的工作量進行評估，預測的精確性基于估算者的能力、經驗、客觀性和洞察力。是對構建整個系統(tǒng)或其子系 統(tǒng)所

18、需的工作量做出經驗性的猜測。主要有類推法，Delphi技術，Wolwerton模型(該模型受變化和主觀性的影響，還受當前數 據相關性的影響 )(x+4y+z)/6對個人估算的規(guī)范化 3.6算式估算法的大致含義：研究人員已經創(chuàng)建出表示工作量和影響工作量的因素之間關系的模型。這些模型通常用方程 式描述，其中工作量是因變量，而其他因素是自變量。大部分模型認為項目規(guī)模是方程式中影 響最大的因素，表示工作量的方程式是：E = (a + bSAc) m(X)其中S是系統(tǒng)規(guī)模的估算，而 a、b、和c是常量。X是從x1到xn的一個成本因素的向量，m是基于 ：這些因素的一個調整因子。3.7試述COCOM模型的三

19、個階段基本工作原理或含義：在階段一，項目通常構建原型以解決包含用戶界面、軟件和系統(tǒng)交互、性能和技術成熟性等方面在內的高風險問題。這時，人們對正在創(chuàng)建的最終產品可能的規(guī)模知之甚少，因此COCOMOn用應用點來估算規(guī)模。在階段二，即早期設計階段，已經決定將項目開發(fā)向前推進，但是設計人員必須研究幾種可 選的體系結構和操作的概念。同樣，仍然沒有足夠的信息支持準確的工作量和工期估算，但是 遠比第一階段知道的信息要多。在階段二， COCOMO使用功能點對規(guī)模進行測量。在階段三，即后體系結構階段，開發(fā)已經開始，而且已經知道了更多的信息。在這個階段， 可以根據功能點或代碼行來進行規(guī)模估算，而且可以較為輕松地估

20、算很多成本因素。3.8什么是風險？風險的特點是什么？有哪幾種降低風險的策略？風險：是一種具有負面后果的、人們不希望發(fā)生的事情。風險的特點（區(qū)別風險和其他項目事件）：（1）與事件有關的損失：與風險有關的損失稱為風險影響（2）事件發(fā)生的可能性：對風險進行的測量稱為風險概率（3）更夠改變結果的程度：能降低或消除風險所采取的行動稱為風險控制（4）風險成本（風險暴露） =風險影響*風險概率三種策略來降低風險：（1）通過改變性能或功能需求，避免風險（2） 通過把風險分配到其他系統(tǒng)中，或者購買保險以便在風險成為事實時彌補經濟上的損 失，從而轉移風險。（3）假設風險會發(fā)生，接受并用項目資源控制風險。3.9風險

21、管理的幾個重要步驟:Risk Management ActivitiesRisk idenlficationRisk assessmeirt Risk analysis.Risk prioritization廠 Checklisr_ Decomposition_ Assumption analysis_ Decision driverafialysis.-System dynamics Performance models-Cost models-Network analvsisf-Decision analysis1- Quality risk factor analysisRisk man

22、agement-Risk reductionRisk control- management planning-Risk resolutioRisk exposureCompound risk reduction 一 Buying infoTmation -Rislc avoidance 一 Risk transfer Risk reduction liveragE -DeveloptnenT processRisk element planningRisk plan integrationRisk mitigationRisk monitoring and Rfeffisessmenr第四章

23、4.1需求的含義是什么？需求的目標是什么？需求：是對期望行為的表達。需求處理的是對象或實體，它們可能處于的狀態(tài)，以及用于改 變狀態(tài)或對象特征的功能。需求的目標：是理解客戶的問題和需要，需求集中于客戶和問題，而不是解決方案的實現。4.2 確定需求的過程（獲取需求的過程）是什么?(1)引發(fā)收集用戶需求(2)分析理解和建模期望的行為(3)規(guī)格說明文檔化要開發(fā)的軟件系統(tǒng)的行為(4)確認檢查我們的規(guī)格說明是否與用戶需求匹配(5)軟件需求規(guī)格說明（SRS)圖:4.3舉例說明獲取需求時，若有沖突發(fā)生，如何考慮到優(yōu)先級的需求分類及相互關系?請求客戶對需求進行優(yōu)先級劃分通常是有用的，這可以迫使客戶思考提議的服務

24、或特征中哪 些是最重要的。一種大致的優(yōu)先計劃分方案可能將需求分為3類：（1）絕對要滿足的需求（必須的）（2）非常值得要的但并非必須的需求（值得要的）（3）可要可不要的需求（可選的）舉例：信用卡記賬系統(tǒng)必須能夠列出最近的費用，將他們加起來并要求在某個日期前支付， 這是必須的需求。但是，該記賬系統(tǒng)也可能按照購買類型區(qū)分費用，以幫助消費者理解購買的 模式，這是值得要的需求。最后，記賬系統(tǒng)可能要求用黑色來打印貸方賬目，用紅顏色打印借 方賬目，這用需求是有用的，但它是可選的需求。按照類型對需求進行優(yōu)先級的分類，能夠幫助所有相關人員理解自己到底需要什么。當軟件 開發(fā)項目受到時間或資源的限制時，如果系統(tǒng)的成

25、本太高或者開發(fā)的時間太長，就可以去掉可 選需求，并對值得要的需求進行分析，考慮是去掉還是延期。還可解決與質量需求之間的矛盾。4.4如何使需求變得可測試？（1）指定每個副詞和形容詞的定量描述，這樣限定詞的含義就清楚、明確了（2 ）用特定實體的名稱替換代名詞（3）要確保在需求文檔的某個地方，正確地定義每個名詞。4.5需求文檔分為哪兩類？（1）需求定義：是客戶想要的每一件事情的完整列表（2）需求規(guī)格說明：將需求重新陳述為關于要構建的系統(tǒng)將如何運轉的規(guī)格說明4.6 什么是功能需求和非功能需求（質量需求）功能需求：根據要求的活動來描述需求的行為。（功能需求定義問題解決方案空間的邊界） 非功能需求（質量需

26、求）：描述一些軟件解決方案必須擁有的質量特征，如快速的響應時間、 易使用性、高可靠性或低維護代價等4.7什么是設計約束和過程約束？設計約束：是已經做出的設計決策或限制問題解決方案集的設計決策。過程約束：是對用于構建系統(tǒng)的技術和資源的限制。4.8需求的特征：（1）正確性（2）一致性（3）無二義性（確定性）（4）完備性（5）可行性（6）相關性（7）可測試性（8）可跟蹤性4.9在原型化需求方面，什么是拋棄式原型，什么是進化式原型？原型化需求的目的： A:有的需求難以用文字和符號說明，而原型化的過程可幫助我們找到“好的視覺和感覺” B:對非功能性需求，可以評價性能和效率拋棄式原型：僅用于了解問題、探索

27、可行性，并不打算用來作為將來實際提交系統(tǒng)的一部分，而是用完扔掉進化式原型：用于了解問題，并作為將來準備提交的系統(tǒng)的一部分 這兩種技術有時都稱為快速原型化，因為它們都是為了回答需求的問題而構建軟件。第五章5.1什么是設計？設計是將問題轉換為解決方案的創(chuàng)造性過程。5.2什么是概念設計？什么是技術設計？概念設計：確切地告訴客戶系統(tǒng)要做什么技術設計：一旦客戶認可概念設計，系統(tǒng)構建人員就將概念設計轉換為更為詳細的文檔，即 技術設計，技術設計確切的告訴開發(fā)人員系統(tǒng)將如何運轉。概念設計強調的是系統(tǒng)功能，而技術設計描述的是系統(tǒng)將要采取的方式。5.3三種設計層及其關系設計分三層：體系結構、代碼設計和可執(zhí)行設計（

28、1）體系結構將需求格式說明中確定的系統(tǒng)能力與實現這些能力的系統(tǒng)構件關聯(lián)起來。（2）代碼設計包含算法和數據結構（3）可執(zhí)行設計在比代碼設計的層次還要低的靜態(tài)層次處理代碼設計，討論內存分配、數據格 式、位模式等關系：自頂向下設計有益的：首先設計體系結構，然后進行代碼設計，最后是可執(zhí)行設計5.4什么是模塊化？什么是抽象？模塊化：在模塊化的設計中，構件清晰地定義了輸入和輸出，設計目標明確，功能獨立，可 以做獨立測試。抽象：對細節(jié)的隱藏稱為抽象， 是基于某種歸納水平的問題描述，是我們集中于問題的關系。5.5論述設計用戶界面應考慮的問題（1）應處理以下幾個關鍵要素：1. 隱喻：可識別和學習的基本術語，圖片

29、和概念2. 頭腦中的模型：數據、功能、任務和角色的構成和表現3. 模型的導航沒規(guī)則：怎樣在數據、功能、活動和角色中轉移4. 外觀：系統(tǒng)向用戶傳輸信息的外觀特征5. 感覺：向用戶提供有吸引力的體驗的交互技術（2）文化問題：需要考慮使用系統(tǒng)的那些用戶的信仰、價值觀、道德規(guī)范、傳統(tǒng)、風俗和傳說。兩種解決方法：1.排除特定的文化參考或偏見，讓界面變得盡可能“國際化”2.采用無偏見設計并使之時應使用軟件的文化（3）用戶偏愛：可以為不同用戶涉及多個界面。5.6耦合的概念，如何分類？耦合：指構件之間的相互依賴性，可分為（1）內容耦合：一個構件直接修改了另外一個構件（當一個構件修改了另外一個構件的內部數據項時

30、，或一個構件內的分支轉移到另外一個構件中的時候，就可能出現內容耦合）（2）公共耦合：不同構件訪問公共數據。例如，一個公共變量可以被不同的構件修改（3） 控制耦合：某個構件通過傳遞參數來控制另外一個構件的活動，模塊間傳遞的是控制量。（4） 標記耦合：用一個數據結構來從一個構件到另一個構件傳送信息，而且傳遞的是該數據 結構本身。（5）數據耦合：構件間通過傳遞數據來完成信息的傳遞。5.7內聚的概念，如何分類？內聚：指構件內部的“粘合”程度，可分為：（1）巧合內聚：構件的各部分互不相關（2）邏輯內聚：幾個邏輯相關的功能或數據元素放在同一個構件中（3）時態(tài)內聚：構件順序執(zhí)行若干個功能，但是各功能只和涉及

31、的時間相關（4）過程內聚：構件中的功能組合在一起只是為了確保這個順序（5）通信內聚：將某些功能關聯(lián)起來，因為它們是操作或生成同一個數據集的（6）順序內聚：一個構件的某部分的輸出正好是下一部分的輸入（7） 功能內聚：每一個處理元素對于執(zhí)行單個功能來說都是必須的，并且在一個構件內包含了 所有必需的元素。5.8什么是被動故障檢測？什么是主動故障檢測？被動故障檢測：設計一個系統(tǒng)，在執(zhí)行的過程中一直等到一個失效發(fā)生主動故障檢測：定期檢查故障的征兆，或設法預見何時發(fā)生故障。第六章6.1什么是面向對象？面向對象是一種軟件開發(fā)方法，它將問題和問題的解決方案組織為離散對象的集合，數據結構和行為都包含在對象的表示

32、中。6.2面向對象有什么特征？（1）標識（2）抽象（3）分類（4） 封裝（5）繼承（6）多態(tài)（7）持久性6.300開發(fā)有何優(yōu)勢？（1）語言的一致性。我們可以用同樣的術語描述問題及其解決方案：類、對象、方法、屬性 和行為（2）過程的一致性。00的過程使用數據和行為的封裝形成的獨立的單元。它從需求到應用 實現和測試用相同語義的概念來表示系統(tǒng)。6.400開發(fā)過程有幾個步驟？00需求，00設計，00編碼和測試第七章7.1為什么說編碼工作紛繁復雜甚至令人氣餒？（1）設計人員可能沒有處理平臺和編程環(huán)境的所有特性。易于用圖表描述的結構和關系并不是總能夠直截了當的編寫成代碼(2) 我們必須以這樣一種方式編寫代

33、碼：不僅要在再次使用代碼進行測試的時候便于自己理 解，而且當系統(tǒng)隨著時間演化時，也便于他人理解(3) 在創(chuàng)建易于復用的代碼的同時，還必須利用這些特征：設計的組織結構、數據結構、編 程語言的概念。7.2 般性的編程原則應該從哪些方面考慮？(1控制結構：當設計轉變成代碼時，我們希望保留組件的控制結構，在隱含調用的面向對 象設計中，控制是基于系統(tǒng)狀態(tài)和變量而變化的。(2) 算法：在編寫代碼時，程序設計通常會制定一類算法，用于編寫組件。(3) 數據結構：編寫程序時，應該安排數據的格式并進行存儲，這樣的數據管理和操作才能 簡明易懂。7.3論述編碼階段實現某種算法時說涉及的問題。(1) 編寫更快代碼的代價

34、?？赡軙谴a更加復雜，從而要花費更多的時間編寫代碼(2) 測試代碼的時間代價。代碼的復雜度要求有更多的測試用例或測試數據(3) 用戶理解代碼的時間代價。(4) 需要修改代碼時，修改代碼的時間代價。7.4在編程程序內部文檔時，除了HCE外，還應添加什么注釋信息？(1) 對程序正在做什么，為程序提供逐行的解釋。(2) 用注釋將代碼分解成標識主要活動的段，接著每個活動還可以分解成更小的步驟。(3) 隨著時間進行修改的記錄7.5什么是極限編程(XP)?極限編程是敏捷過程的一種具體形式，提供敏捷方法最一般原則的指導方針。XP的支持者強調敏捷方法的4個特性：交流、簡單性、勇氣以及反饋。交流是指客戶與開發(fā)

35、人員之間持續(xù)地交換看法；簡單性激勵開發(fā)人員選擇最簡單的設計或實 現來處理客戶的需要；勇氣體現在今早地和經常交付功能的承諾；在軟件開發(fā)過程中的各種活 動中，都包含反饋循環(huán)。例如，程序員一起工作，針對實現設計的最佳方式，相互提供反饋； 客戶和程序員一起工作時，以完成計劃的任務。7.6什么是結對編程？結對編程屬于主要的敏捷開發(fā)方法，開發(fā)方式是兩個程序員共同開發(fā)程序，且角色分工明確：一個負責編寫程序，另一個負責復審和測試，兩個人定期交換角色。第八章8.1產生時失效的原因有哪些？(1 )規(guī)格說明可能是錯誤的，或者遺漏了某個需求。(2 )對于指定的硬件和軟件，說明中可能包含不可能實現的需求(3) 系統(tǒng)設計

36、中可能包含故障(4) 程序設計中可能包含故障(5) 程序代碼可能是錯誤的8.2故障分類的理由：在編碼完程序構件之后，我們通常對代碼進行檢查，以找出故障并立刻去除它們。當不存在 明顯的故障時，我們測試程序，通過創(chuàng)造一些條件，是代碼不能像計劃的那樣做出反應，看一 看能否發(fā)現更多的故障。因此，知道我們正在查找什么類型的故障是很重要的。8.3幾種主要的故障類型：（1）算法故障：由于處理步驟中的某些錯誤，使得對于給定的輸入，構件的算法或邏輯沒有 產生適當的輸出。（2）計算故障和精度故障：一個公式的實現是錯誤的，或者計算結果沒有達到要求的精度。（3）文檔故障：文檔與程序實際做的事情不一致。（4）壓力故障（過載故障）：填充數據結構時超過了它們規(guī)定的能力（5）能力故障（邊界故障）：系統(tǒng)活動到達指定的極限時，系統(tǒng)性能會變得不可接受（6）計時故障（協(xié)調故障）：在開發(fā)實時系統(tǒng)時，一個關鍵的考慮因素是幾個同時執(zhí)行的或 按仔細定義的順序執(zhí)行的進程之間的協(xié)調問題，當協(xié)調這些事件的代碼不適當時，就會出現計 時故障。（7）吞吐量