軟件工程期末測試題

1、精選優(yōu)質文檔-傾情為你奉上判斷第一章概述1. 由于今天個人計算機不斷發(fā)展壯大，人們不再采用軟件團隊的開發(fā)方式。（） 2. 由于軟件是產(chǎn)品，因此可以應用其他工程制品所用的技術進行生產(chǎn)。（） 3. 購買大多數(shù)計算機系統(tǒng)所需的硬件比軟件更昂貴。（） 4. 大多數(shù)軟件產(chǎn)品在其生命周期中不需要增強功能。（） 5. 大多數(shù)軟件系統(tǒng)是不容易變化的，除非它們在設計時考慮了變化。（） 6. 一般來說，軟件只有在其行為與設計者的目標一致的情況下才能成功。（）第二章軟件過程3.軟件需求規(guī)格說明書在軟件開發(fā)過程中具有重要的作用，它是軟件可行性分析的依據(jù)。（） 軟件項目管理2.項目管理在現(xiàn)代軟件開發(fā)中是不太重要的，因為

2、大多數(shù)項目能夠及時完成并成功交付。（）13.隨著項目計劃的不斷形成，產(chǎn)品分解和過程分解經(jīng)常是同時發(fā)生的。（） 15.估算不可靠的唯一原因是估算人員缺乏經(jīng)驗。（） 16.由于軟件項目估算不完全可靠，所以項目開始后可以忽略這些估算。（） 19.估計待開發(fā)軟件產(chǎn)品的規(guī)模必須基于像代碼行等直接度量單位。（）24.功能點不能用于估算面向對象的軟件。（）25.軟件項目延遲是不可避免的，而且無法解釋其原因。（） 26.將開發(fā)團隊人數(shù)增加一倍可以保證項目完成時間減少一半。（） 28.主動的風險管理有時被描述為救火。（） 34.軟件工作產(chǎn)品一旦成為基線就不能再更改了。（） 35.如果開發(fā)小組使用自動化的項目數(shù)據(jù)

3、庫工具，那么就不需要變更控制。（） 需求工程1. 在需求分析過程中，分析員要從用戶那里解決的最重要的問題是明確軟件做 什么。（）2. 軟件需求規(guī)格說明書在軟件開發(fā)中具有重要的作用，它是軟件可行性分析的 依據(jù)。（） 6. 目前存在一個很普遍的現(xiàn)象，即不同的客戶提出的需求是相互矛盾的，但每個人都爭辯自己是正確的。（） 7. 利益相關者（stakeholders）是將來購買所開發(fā)軟件系統(tǒng)的人。（） 11.需求工程師的任務是將所有利益相關者的信息進行分類以便允許決策者選擇一 個相互一致的需求集。（） 13.開發(fā)人員與客戶創(chuàng)建用例以幫助軟件團隊理解有多少類型的最終用戶將使用這 些功能。（）16.用例參與

4、者總是人員而不是系統(tǒng)設備。（） 17.在需求確認過程中需求模型被評審以保證其技術可行性。（） 面向對象基礎1. 模型是對現(xiàn)實的簡化，建模是為了更好地理解所開發(fā)的系統(tǒng)。（） 2. UML 語言支持面向對象的主要概念，并與具體的開發(fā)過程相關。（） 面向對象分析1. 面向對象分析的核心在于建立一個描述軟件系統(tǒng)的模型。（） 5. 分析類用于描述系統(tǒng)中概念層次的對象。（） 7. 在基于用例的面向對象分析過程中，定義交互行為的關鍵在于通過描述分析 類實例之間 的消息傳遞將用例的職責分配到分析類中。（） 10. 需求評審人員主要由開發(fā)人員組成，一般不包括用戶。（） 面向對象設計1. 面向對象設計是在分析模型

5、的基礎上，運用面向對象技術生成軟件實現(xiàn)環(huán)境 下的設計模型。（） 2. 系統(tǒng)設計的主要任務是細化分析模型，最終形成系統(tǒng)的設計模型。（） 3. 關系數(shù)據(jù)庫可以完全支持面向對象的概念，面向對象設計中的類可以直接對 應到關系數(shù)據(jù)庫中的表。（） 4. 用戶界面設計對于一個系統(tǒng)的成功是至關重要的，一個設計得很差的用戶界 面可能導致用戶拒絕使用該系統(tǒng)。（）軟件實現(xiàn)1. 在程序設計中使用括號以改善表達式的清晰性。（） 2. 在程序設計中應盡可能對程序代碼進行優(yōu)化。（） 3. 不要修補不好的程序，要重新寫。（） 4. 程序中的注釋是可有可無的。（） 5. 對遞歸定義的數(shù)據(jù)結構不要使用遞歸過程。（） 軟件測試1.

6、 在軟件開發(fā)的過程中，若能推遲暴露其中的錯誤，則為修復和改正錯誤所花 費的代價就會降低。（） 2. 好的測試是用少量測試用例運行程序，發(fā)現(xiàn)被測程序盡可能多的錯誤。（） 3. 好的測試用例應能證明軟件是正確的。（） 4. 白盒測試僅與程序的內(nèi)部結構有關，完全可以不考慮程序的功能要求。（） 5. 等價類劃分方法將所有可能的輸入數(shù)據(jù)劃分成若干部分，然后從每一部分中 選取少數(shù)有代表性的數(shù)據(jù)作為測試用例。（）軟件演化1. 只有質量差的軟件產(chǎn)品才需要維護。（）2. 遺留系統(tǒng)是許多年以前開發(fā)的且已經(jīng)沒有商業(yè)價值的計算機系統(tǒng)。（） 3. 更換遺留系統(tǒng)是有業(yè)務風險的。（） 4. 軟件的維護成本通常比開發(fā)成本低。

7、（） 選擇第一章概述1. （ ）因素促使計算機系統(tǒng)越來越復雜。（D） A. 計算機內(nèi)存和存儲容量上的巨大增長 B. 外部輸入輸出選項的更加多樣性 C. 計算機體系結構方面的深刻變化 D. 以上所有選項 2. 下面的（ ）不再是現(xiàn)代軟件工程師關注的問題。（A） A. 為什么計算機硬件的成本這么高？ B. 為什么軟件需要很長時間才能完成？ C. 為什么開發(fā)一個軟件的成本這么高？ D. 為什么不能在產(chǎn)品發(fā)布前去除軟件錯誤？ 3. 軟件會逐漸退化而不會磨損，其原因在于（ ）。（C） A. 軟件通常暴露在惡劣的環(huán)境下 B. 軟件錯誤通常發(fā)生在使用之后 C. 不斷的變更使組件接口之間引起錯誤 D. 軟件備

8、件很難訂購 4. 大多數(shù)軟件仍然是定制開發(fā)的，其原因在于（ ）。（C） A. 軟件組件重用是十分普遍的 B. 可重用的組件太昂貴而無法使用 C. 軟件在不使用其他組件的情況下很容易構造出來 D. 商業(yè)組件在很多應用領域中可以得到 5. 下面的（ ）說法是正確的。（C） A. 軟件危機在 20 世紀 70 年代末期全面爆發(fā) B. 當前先進的軟件工程方法已經(jīng)解決了軟件危機的問題 C. 軟件危機是指在計算機軟件的開發(fā)和維護過程中遇到的一系列嚴重問題 D. 軟件危機是指在軟件產(chǎn)品中存在一系列的質量問題 6. 軟件工程的基本目標是（ ）。（B） A. 消除軟件固有的復雜性 B. 開發(fā)高質量的軟件 C.

9、努力發(fā)揮開發(fā)人員的創(chuàng)造性潛能 D. 更好地維護正在使用的軟件產(chǎn)品 7. （ ）是將系統(tǒng)化的、規(guī)范的、可定量的方法應用于軟件的開發(fā)、運行和維護的過 程，它包括方法、工具和過程三個要素。（D） A. 軟件產(chǎn)品 B. 軟件過程 C. 軟件測試 D. 軟件工程 8. 軟件工程的基本要素包括方法、工具和（ ）。（C） A. 軟件系統(tǒng) B. 硬件環(huán)境 C. 過程 D. 人員 9. 軟件工程師在從事軟件工作時應使用下面的（ ）準則。（E） A. 從來不為個人獲利而竊取數(shù)據(jù) B. 從來不散布或出售項目中自己工作的信息 C. 從來不故意毀壞或修改別人的程序、文件或數(shù)據(jù) D. 從來不侵犯個人、小組或組織的隱私 E

10、. 以上所有選項第二章軟件過程1. （ ）是軟件生存期中的一系列相關軟件工程活動的集合，它由軟件規(guī)格說明、軟件 設計與開發(fā)、軟件確認、軟件改進等活動組成。（A） A. 軟件過程 B. 軟件工具 C. 軟件產(chǎn)品 D. 軟件工程 2. 軟件過程的基本活動是（ ）。（A） A. 分析、設計、實現(xiàn)、測試、演化 B. 溝通、計劃、建模、構造、部署 C. 計劃、分析、設計、實現(xiàn)、調(diào)試 D. 溝通、風險管理、度量、產(chǎn)品化、評審 4. 軟件開發(fā)的瀑布模型是（ ）。（A） A. 適用于需求被清晰定義的情況 B. 一種需要快速構造可運行程序的好方法 C. 最適合于大規(guī)模團隊開發(fā)的項目 D. 已不能用于現(xiàn)代環(huán)境的過

11、時模型 5. 軟件開發(fā)的增量模型是（ ）。（B）A. 適用于需求被清晰定義的情況 B. 一種需要快速構造核心產(chǎn)品的好方法 C. 最適合于大規(guī)模團隊開發(fā)的項目 D. 一種不適用于商業(yè)產(chǎn)品的創(chuàng)新模型 6. 快速原型開發(fā)模型是（ ）。（B） A. 適用于客戶需求被明確定義的情況 B. 適用于客戶需求難以清楚定義的情況 C. 最適合于大規(guī)模團隊開發(fā)的項目 D. 很難產(chǎn)生有意義產(chǎn)品的一種冒險模型 7. 演進式軟件過程模型（ ）。（D） A. 本質上是迭代的 B. 可以很容易適應需求的變化 C. 通常不會拋棄所產(chǎn)生的系統(tǒng) D. 以上所有選項 8. 螺旋模型（ ）。（C） A. 在軟件產(chǎn)品發(fā)布時結束 B.

12、比增量模型更加混亂 C. 在每一次迭代過程中包含項目風險評價 D. 以上所有選項 9. 基于組件的開發(fā)模型（ ）。（C） A. 只適用于計算機硬件設計 B. 不能支持可重用組件的開發(fā) C. 在面向對象技術獲得支持的情況下應用得更好 D. 增加了開發(fā)風險和成本 10. 形式化方法模型是將數(shù)學方法用于（ ）。（D） A. 定義計算機系統(tǒng)的規(guī)格說明 B. 開發(fā)無錯誤的計算機系統(tǒng) C. 驗證計算機系統(tǒng)的正確性 D. 以上所有選項 11. 下面的（ ）不是 RUP 模型的階段。（D） A. 啟動階段 B. 精化階段 C. 構造階段 D. 確認階段軟件項目管理1. 軟件項目管理的“4P”是（ ）。（C）

13、A. people，performance，payoff，product B. people，product，performance，process C. people，product，process，project D. people，process，payoff，product 3. 在軟件開發(fā)的各種資源中，（ ）是最重要的資源。（C） A. 開發(fā)工具 B. 方法 C. 硬件環(huán)境 D. 人員 4. 軟件項目規(guī)劃的第一步是（ ）。（D） A. 確定項目預算 B. 選擇團隊的組織模型 C. 確定項目的約束 D. 建立項目的目標和范圍 5. 下面的（ ）方法最不適合你向團隊成員解釋他或她為什么表

14、現(xiàn)不合格。（B） A. 個人談話 B. 項目團隊會議 C. 正式報告 D. 電子郵件 6. 功能點估算技術需要以（ ）為基礎進行問題分解。（A） A. 信息域 B. 項目進度 C. 軟件功能 D. 過程活動 7. 軟件開發(fā)團隊的每一個成員都應該參與計劃活動，以便（ ）。（C） A. 降低計劃的粒度 B. 深入地分析需求 C. 所有成員同意該計劃 D. 開始設計 8. 在攻克技術難題時，最佳的開發(fā)團隊組織模型是（ ）。（A） A. 民主式結構 B. 主程序員式結構 C. 技術管理混合式結構 D. 以上所有選項都不是 9. 在選擇開發(fā)團隊組織結構時應考慮（ ）因素。（E） A. 溝通的復雜程度 B

15、. 最終程序的規(guī)模大小 C. 發(fā)布日期的嚴格程度 D. 項目預算的多少 E. 選項 A，B 和 C 10. 在軟件開發(fā)過程中避免受挫的最佳方法之一是（ ）。（A） A. 給予團隊成員對于過程和技術決策的更多控制權 B. 給予團隊成員對于過程和技術決策的更少控制權 C. 向團隊成員隱瞞壞消息直到事情有所改善 D. 根據(jù)生產(chǎn)效率獎勵團隊成員 11. 下面的（ ）軟件特性不是引起項目協(xié)調(diào)困難的一個因素。（B） A. 互操作性 B. 性能 C. 規(guī)模 D. 不確定性 12. 在進行項目范圍活動時，問題分解的主要范圍是（ ）。（E） A. 客戶工作流程 B. 需要發(fā)布的功能 C. 用于發(fā)布功能的過程 D

16、. 軟件過程模型 E. 選項 B 和 C 14. 為了將項目失敗的風險減少到最小，項目經(jīng)理需要采取（ ）。（D） A. 將項目團隊規(guī)模增加一倍 B. 要求更大的預算 C. 順利地開始 D. 跟蹤過程 E. 選項 B 和 C 17. 軟件項目規(guī)劃的目的是（ ）。（C） A. 使客戶相信項目是可行的 B. 使用歷史項目數(shù)據(jù) C. 使項目管理者合理地估算成本和進度 D. 在投標項目之前確定大概的利潤邊界 18. 軟件項目所需的人數(shù)應該（ ）。（D） A. 在估計開發(fā)需要的努力之后決定 B. 由項目預算數(shù)量決定 C. 從評價系統(tǒng)復雜性來決定 D. 以上所有選項 19. （ ）估計待開發(fā)軟件產(chǎn)品的規(guī)模必

17、須基于像代碼行等直接度量單位。（B） A. 真 B. 假 20. 代碼行估算技術需要以（ ）為基礎進行問題分解。（C） A. 信息域值 B. 項目進度 C. 軟件功能 D. 軟件過程活動 21. 功能點估算技術需要以（ ）為基礎進行問題分解。（A） A. 信息域值 B. 項目進度 C. 軟件功能 D. 軟件過程活動 22. 經(jīng)驗估算模型是基于（ ）。（C） A. 專家基于過去項目經(jīng)驗的判斷 B. 期望值估計的細化 C. 來自歷史項目數(shù)據(jù)的回歸模型 D. 反復試驗決定參數(shù)和系數(shù) 23. COCOMO II 是現(xiàn)代經(jīng)驗估算模型的一個實例，它需要以（ ）為單位的程序規(guī)模信息。（B） A. 功能點 B

18、. 代碼行 C. 工作量 D. 以上任何選項 27. 任務集是（ ）的集合。（A） A. 工作任務、里程碑、工作產(chǎn)品 B. 任務分配、成本估算、度量單位 C. 里程碑、可交付物、度量單位 D. 責任、里程碑、文檔 29. 軟件風險總是包括（ ）兩個特性。（C） A. 救火和危機管理 B. 已知的和未知的風險 C. 不確定和損失 D. 安置人員和預算 30. 風險的三種主要類型是（ ）。（B） A. 商業(yè)風險、人員風險、預算風險 B. 項目風險、技術風險、商業(yè)風險 C. 計劃風險、技術風險、人員風險 D. 管理風險、技術風險、設計風險 31. 下面的（ ）是有效的軟件配置項。（E）A. 軟件工具

19、 B. 文檔 C. 可執(zhí)行程序 D. 測試數(shù)據(jù) E. 以上所有選項 32. 下面的（ ）配置對象通常不包括在項目數(shù)據(jù)庫中。（C） A. 設計規(guī)格說明書 B. 可執(zhí)行程序 C. 組織結構描述 D. 測試計劃 33. 基線（Baseline）是指在項目生命周期的不同時間點上，一個或一組配置項通過（ ） 而進入正式受控的一種狀態(tài)。（C） A. 存取控制 B. 質量控制 C. 正式評審 D. 變更管理 36. 下面的（ ）不是軟件配置管理的任務。（C） A. 變更控制 B. 配置狀態(tài)報告 C. 統(tǒng)計質量控制 D. 版本控制 37. 配置狀態(tài)報告的主要目的是（ ）。（C） A. 允許項目經(jīng)理修改項目進度

20、和成本估算 B. 評估軟件開發(fā)人員和組織的績效 C. 確保變更信息傳達到受影響的團體 D. 選項 A 和 C E. 選項 A、B 和 C需求工程3. 在項目初始階段，開發(fā)任務的目標是（ ）。（A） A. 理解基本問題 B. 確定所需的解決方案 C. 確定需要解決方案的人員 D. 以上選項都不是 E. 選項 A、B 和 C 4. 下面的（ ）將造成需求獲取困難的問題。（E） A. 預算（budgeting） B. 范圍（scope） C. 理解（understanding） D. 揮發(fā)性（volatility） E. 選項 B、C 和 D 5. 需求分析的結果是產(chǎn)生定義下面（ ）問題域的分析模型

21、。（D） A. 信息 B. 功能 C. 性能 D. 以上所有選項8. 需求規(guī)格說明描述了（ ）。（A） A. 計算機系統(tǒng)的功能、性能及其約束 B. 每個指定系統(tǒng)的實現(xiàn) C. 軟件體系結構的元素 D. 系統(tǒng)仿真所需要的時間 9. 組織需求評審的最好方法是（ ）。（D） A. 檢查系統(tǒng)模型的錯誤 B. 讓客戶檢查需求 C. 將需求發(fā)放給設計團隊去征求意見 D. 使用問題列表檢查每一個需求 10. 使用跟蹤表有助于（ ）。（C） A. 在后續(xù)的檢查運行錯誤時調(diào)試程序 B. 確定算法執(zhí)行的性能 C. 識別、控制和跟蹤需求的變化 D. 以上選項都不是12. 下面的（ ）不是在項目啟動階段被提出的“與環(huán)境

22、無關”的問題。（B） A. 成功的解決方案將帶來什么樣的經(jīng)濟收益？ B. 誰反對該項目？ C. 誰將為該項目付款？ D. 誰將使用該解決方案？14. 在各種不同的軟件需求中，（ ）描述了用戶使用產(chǎn)品必須要完成的任務，可以在用 例模型或方案腳本中予以說明，（ ）是從各個角度對系統(tǒng)的約束和限制，反映了應 用對軟件系統(tǒng)質量和特性的額外要求。（B，C） A. 業(yè)務需求 B. 功能需求 C. 非功能需求 D. 用戶需求 15. 需求導出后產(chǎn)生的工作制品將依賴于（ ）而不同。（B） A. 預算多少 B. 將要構建的產(chǎn)品規(guī)模 C. 正在使用的軟件過程 D. 利益相關者的需要18. 在需求開發(fā)過程中，軟件工程

23、師應與客戶合作共同定義（ ）。（E） A. 客戶可見的使用場景 B. 重要的軟件特性 C. 系統(tǒng)的輸入與輸出 D. 選項 A 和 B E. 選項 A、B 和 C面向對象基礎3. 類的結構是（ ）。（E） A. 由代碼來表示 B. 由屬性和關系來表示 C. 由操作來表示 D. 由對象的交互來表示 E. 選項 B 和 C 4. 類的行為是（ ）。（A） A. 由一組操作決定 B. 由類的屬性決定 C. 對類的每一個對象唯一的 D. 由父類決定 E. 選項 A 和 B 5. （ ）是把對象的屬性和操作結合在一起，構成一個獨立的對象，其內(nèi)部信息對外 界是隱蔽的，外界只能通過有限的接口與對象發(fā)生聯(lián)系。（

24、C） A. 多態(tài)性 B. 繼承 C. 封裝 D. 消息6. （ ）意味著一個操作在不同的類中可以有不同的實現(xiàn)方式。（A） A. 多態(tài)性 B. 多繼承 C. 消息 D. 封裝 7. UML 是（ ）的縮寫。（B） A. Unified Module Language B. Unified Modeling Language C. Universal Module Leveling D. Universal Module Language 8. 順序圖反映對象之間發(fā)送消息的時間順序，它與（ ）是同構的。（C） A. 用例圖 B. 類圖 C. 協(xié)作圖 D. 狀態(tài)圖 9. （ ）定義了系統(tǒng)的功能需求，

25、它是從系統(tǒng)的外部看系統(tǒng)功能，并不描述系統(tǒng)內(nèi)部 對功能的具體實現(xiàn)。（A） A. 用例圖 B. 類圖 C. 活動圖 D. 狀態(tài)圖 10. 狀態(tài)圖包括（ ）。（E） A. 類的狀態(tài) B. 狀態(tài)之間的轉換 C. 類執(zhí)行的動作 D. 觸發(fā)類的動作的事件 E. 所有選項面向對象分析2. 關于面向對象分析，下列的（ ）是正確的。（A） A. 它是系統(tǒng)需求建模的方法 B. 它是分析系統(tǒng)設計的技術 C. 可以從分析直接編寫代碼 D. 在軟件生命周期中，它出現(xiàn)在面向對象設計之后 3. 下列的（ ）不是分析建模的目的。（C） A. 定義可驗證的軟件需求 B. 描述客戶需求 C. 開發(fā)一個簡單的問題解決方案 D. 建

26、立軟件設計的基礎 4. 下列的（ ）不屬于面向對象分析模型。（C） A. 用例圖 B. 類圖 C. 實體關系圖 D. 順序圖6. 在分析類中，（ ）用于描述一個用例所具有的事件流控制行為。（D） A. 實體類 B. 界面類 C. 接口類 D. 控制類8. 開發(fā)人員使用（ ）可以將用例的行為分配到所識別的分析類中。（B） A. 用例圖 B. 順序圖 C. 類圖 D. 狀態(tài)圖 9. 分析模型一般采用（ ）方式進行驗證。（C） A. 總結 B. 階段性報告 C. 需求分析評審 D. 轉化成設計模型面向對象設計5. 內(nèi)聚表示一個模塊（ ）的程度，耦合表示一個模塊（ ）的程度。 （B，D） A. 可以被

27、更加細化 B. 僅關注在一件事情上 C. 能夠適時地完成其功能 D. 聯(lián)接其他模塊和外部世界 6. 良好設計的特征是（ ）。（E） A. 模塊之間呈現(xiàn)高耦合 B. 實現(xiàn)分析模型中的所有需求 C. 包括所有組件的測試用例 D. 提供軟件的完整描述 E. 選項 B 和 D F. 選項 B、C 和 D 7. （ ）是選擇合適的解決方案策略，并將系統(tǒng)劃分成若干子系統(tǒng)，從而建立整個系 統(tǒng)的體系結構；（ ）細化原有的分析對象，確定一些新的對象、對每一個子系統(tǒng)接 口和類進行準確詳細的說明。（A，B） A. 系統(tǒng)設計 B. 對象設計 C. 數(shù)據(jù)庫設計 D. 用戶界面設計 8. 下面的（ ）界面設計原則不允許用

28、戶保持對計算機交互的控制。（D） A. 允許交互中斷 B. 允許交互操作取消 C. 對臨時用戶隱藏技術內(nèi)部信息 D. 只提供一種規(guī)定的方法完成任務軟件實現(xiàn)6. 為了使程序能在不同的計算機上運行，程序應當具有較好的（ ）。（A） A. 可移植性 B. 可重用性 C. 可維護性 D. 可適用性 7. 對于開發(fā)面向數(shù)據(jù)庫應用的軟件，應當選擇的程序設計語言是（ ）。（C） A. C B. PASCAL C. SQL D. JAVA 8. 下面對提高程序編碼效率沒有影響的是（ ）。（D） A. 選擇良好的設計方法 B. 選擇良好的算法 C. 選擇良好的數(shù)據(jù)結構 D. 變量名的使用 9. 為了保證軟件的質

29、量，使其具有較好的可維護性，關鍵在于（ ）。（B） A. 選擇合適的程序設計語言 B. 選擇好的程序設計風格 C. 具有好的數(shù)據(jù)結構 D. 選擇好的運行環(huán)境 10. 下面的（ ）不是良好編碼的原則。（C） A. 在開始編碼之前建立單元測試 B. 建立一種有助于理解的直觀布局 C. 保持變量名簡短以便代碼緊湊 D. 確保注釋與代碼完全一致軟件測試6. 使用獨立測試團隊的最好理由是（ ）。（C） A. 軟件開發(fā)人員不需要做任何測試 B. 測試人員在測試開始之前不參與項目 C. 測試團隊將更徹底地測試軟件 D. 開發(fā)人員與測試人員之間的爭論會減少 7. 類的行為應該基于（ ）進行測試。（D） A.

30、數(shù)據(jù)流圖 B. 用例圖 C. 對象圖 D. 狀態(tài)圖 8. 下面的（ ）說法是正確的。（C，D，E） A. 恢復測試是以各種方式迫使軟件失效從而檢測軟件是否能夠繼續(xù)執(zhí)行的一種系統(tǒng) 測試。 B. 安全測試是檢測系統(tǒng)中的保護機制是否可以保護系統(tǒng)免受非正常的攻擊。 C. 壓力測試是檢測在極限環(huán)境中使用系統(tǒng)時施加在用戶上的壓力。 D. 功能測試是根據(jù)軟件需求規(guī)格說明和測試需求列表，驗證產(chǎn)品的功能實現(xiàn)是否符 合需求規(guī)格。 E. 安裝測試是保證應用程序能夠被成功地安裝軟件演化5. 逆向工程（Reverse Engineering）通常用在軟件生命周期的（ ）階段，它是從源 代碼或目標代碼中提取設計信息。（D

31、） A. 需求分析 B. 軟件設計 C. 軟件測試 D. 軟件維護概念第一章概述1. 軟件與其他工程學科所產(chǎn)生的制品有什么根本區(qū)別？ 答：（1） 軟件是人類思維和智能所延伸的產(chǎn)物，其數(shù)據(jù)、狀態(tài)和邏輯關系的組合以及人類思維的 復雜性和不確定性導致它本身具有極高的復雜性； （2） 軟件具有不可見性，它是抽象的，形式化和邏輯化的。 （3） 軟件具有可變性，有用的軟件需要不斷地修改和擴展，但是頻繁的修改可能導致軟件的 退化； （4） 軟件的開發(fā)在很大程度上依然是手工作坊式的，難以實現(xiàn)工廠化的生產(chǎn)。2. 軟件工程包括哪些基本要素？請簡要說明這些要素及其作用。 答：軟件工程包括過程、方法和工具三個要素。

32、1軟件工程過程定義了技術方法的采用、工程產(chǎn)品（包括模型、文檔、數(shù)據(jù)、報告、表格 等）的產(chǎn)生、里程碑的建立、質量的保證和變更的管理，從而將人員、技術、組織與管 理有機地結合在一起，實現(xiàn)在規(guī)定的時間和預算內(nèi)開發(fā)高質量軟件的目標； 2軟件工程方法為軟件開發(fā)提供了“如何做”的技術，通常包括某種語言或圖形的模型表 示方法、良好的設計實踐以及質量保證標準等； 3軟件工程工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境，輔助軟件開發(fā)任 務的完成?，F(xiàn)有的軟件工具覆蓋了從需求分析、系統(tǒng)建模、代碼生成、程序調(diào)試和軟件 測試等多個方面，形成了集成化的軟件工程開發(fā)環(huán)境 CASE3. 結合IEEE/ACM軟件工程職

33、業(yè)道德和職業(yè)行為準則，試分別距離闡述每一項原則。答：（1） 公眾：軟件工程人員應始終與公眾利益保持一致；（2） 客戶和雇主：在與公眾利益保持一致的原則下，軟件工程人員應滿足客戶和雇主的最大利益；（3） 產(chǎn)品：軟件工程人員應當確保他們的產(chǎn)品及其改進符合盡可能高的專業(yè)標準；（4） 判斷：軟件工程人員應當具備公正和獨立的職業(yè)判斷力；（5） 管理：軟件工程管理者和領導者應擁護和倡導合乎道德的有關軟件開發(fā)和維護的管理方法；（6） 職業(yè)：在與公眾利益一致的原則下，軟件工程人員應當提高職業(yè)的信譽；（7） 同行：軟件工程人員對其同行應保持平等和支持的態(tài)度；（8） 自我：軟件工程人員應當終身學習專業(yè)知識，促進合

34、乎道德的職業(yè)實踐方法。4. 軟件工程是以系統(tǒng)的、可控的、有效的方式產(chǎn)生高質量的軟件，請說明你對“高質量軟件”含義的理解。 答：軟件質量是軟件產(chǎn)品與明確的和隱含的需求相一致的程度，它通常由一系列的質量特性來進行描述，包括正確性、可靠性、有效性、可用性、復用性、可維護性、可移植性等。例如，除了要求軟件正確運行之外，人們可能還希望軟件運行的響應時間符合要求、軟件使用方便快捷、程序代碼易于理解等，而“程序代碼易于理解”往往是一種用戶沒有明確提出的需求，但卻是影響軟件演化的重要因素。 5.有人認為“軟件工程過于耗費時間，并且妨礙開發(fā)人員的編程效率。”你是否認同這種觀點？請闡述理由。 答：這一觀點是不正確

35、的。 軟件開發(fā)遠不只是編程，管理不當導致的混亂、工作重復、交流不暢等才是大多軟件項目效率低下的主要原因。雖然直接編程在開發(fā)前期看來效率高，但是不完整的、不清晰的或錯誤的需求和設計將導致在開發(fā)后期反復地修改程序，反而降低了整個開發(fā)效率，其質量也無法保證，甚至導致軟件開發(fā)最終失敗的結果。 軟件工程是幫助人們在有限的時間、金錢預算和人力、物力資源的約束下開發(fā)出質量盡量高的軟件的一系列理論和工具，雖然它在編程之外的工作上花費了大量時間，但所耗費的時間與精力并不像其表面上所看起來的那樣冗余與低效，而是從總體上做好整個體系的設計與把握，全方位地規(guī)劃開發(fā)過程，對節(jié)省成本、提高效率、保證最終產(chǎn)品質量起到了事半

36、功倍的作用。 第2章 軟件過程1. 請簡要說明軟件過程的概念和基本元素。 答： 軟件過程是軟件工程人員為了獲得軟件產(chǎn)品在軟件工具支持下實施的一系列軟件工程活動，它應該明確定義以下元素： 過程中所執(zhí)行的活動及其順序關系 每一個活動的內(nèi)容和步驟 團隊人員的工作和職責 2. 請描述快速原型過程模型的各個階段。 答： 快速原型方法的目的是解決軟件需求不明確給開發(fā)帶來風險的問題，其關鍵在于盡可能“快速”地建造原型，通過用戶對原型的評價最終確定系統(tǒng)的需求。 快速原型過程模型包括以下階段： 原型需求分析：分析和提煉所收集到的客戶需求； 原型開發(fā)：基于初步的需求快速建造一個可以運行的軟件原型，實現(xiàn)客戶或未來的

37、用戶與系統(tǒng)的交互； 原型評價：由用戶或客戶對該原型進行評價，需要的話再進一步細化待開發(fā)軟件的需求，并繼續(xù)調(diào)整原型直至需求確定下來為止。 3.對于下列每一個過程模型，分別列舉一個可以適用的具體軟件項目，并說明在開發(fā)中如何應 用該模型。（1）瀑布模型（2）快速原型模型（3）增量模型（4） 形式化方法模型 （5） 基于組件的開發(fā)模型 答：（1） 瀑布模型 項目舉例：某項目需要在一種新型機器上，為一種已知語言開發(fā)一個普通的編譯器。 選用分析：由于該項目的語言是已知的，需求是明確的和穩(wěn)定的，整個系統(tǒng)屬于中小規(guī)模， 因此適合采用瀑布模型進行軟件開發(fā)。 階段說明：略。 （2） 快速原型模型 項目舉例：某公司

38、需要給火車站開發(fā)一個交互式火車車次查詢系統(tǒng)，這是火車站首次使用該 系統(tǒng)。 選用分析：本項目的主要問題在于用戶需要方面，該系統(tǒng)與最終用戶的交互是十分關鍵的， 但是在項目初期用戶的需求基本上是不知道的，因此適合采用快速原型方法來確定用戶需 求，在需求確定的基礎上再開發(fā)最終系統(tǒng)。 階段說明：略。 （3） 增量模型 項目舉例：某公司開發(fā)一個通用 CAD 軟件產(chǎn)品，產(chǎn)品需求是逐步完善的，某些需求在一定 范圍內(nèi)是明確的，某些需求需要進一步細化，但是迫于市場競爭的壓力產(chǎn)品需要盡快上市。 選用分析：通用 CAD 軟件產(chǎn)品具有一定的成熟度，總體需求和軟件系統(tǒng)結構是可以確定的， 但是實現(xiàn)該產(chǎn)品所有功能需要比較長的

39、開發(fā)周期。為了盡快上市可以采用增量模型實行多版 本的發(fā)布策略，既可以很快占領市場又可以為后續(xù)版本的需求定義奠定基礎。 階段說明：略。 （4） 形式化方法模型 項目舉例：某公司開發(fā)一個汽車防抱死剎車控制系統(tǒng)。 選用分析：由于該系統(tǒng)對安全性和可靠性要求極高，需要在系統(tǒng)運行之前進行相關性能的檢 驗，因此適合采用形式化方法開發(fā)該系統(tǒng)。 階段說明：略。 （5） 基于組件的開發(fā)模型 項目舉例：某公司開發(fā)企業(yè)管理 ERP 系統(tǒng)，包括銷售、庫存、生產(chǎn)、財務、物流、人力資 源等部分，在系統(tǒng)實施過程中不同的企業(yè)具有一定的需求差異。 選用分析：企業(yè) ERP 系統(tǒng)具有組件化的結構，在不同企業(yè)實施時應該盡量重用已有的組

40、件， 因此適合采用基于組件的開發(fā)模型開發(fā)該系統(tǒng)，在直接應用或者修改使用的基礎上，最終進 行組件開發(fā)和系統(tǒng)集成。 階段說明：略。4. 在螺旋模型中，風險分析的作用是什么？ 答： 在螺旋模型中，軟件開發(fā)是在風險等級的指導下進行的。首先確定該階段的目標，完成這些目標的選擇方案及其約束條件；其次從風險角度分析方案的開發(fā)策略，努力排除各種潛在的風險，在需求不適當?shù)那闆r下可能需要建造原型系統(tǒng)；如果某些風險不能排除，該方案可能立即終止，否則繼續(xù)啟動下一步的軟件開發(fā)和驗證工作，并再次通過風險分析規(guī)定過程遵循的策略；最后，評價該階段的結果，并規(guī)劃下一個迭代。 從上述過程中可以看出，風險分析的作用是通過識別項目中

41、的高風險問題，使開發(fā)人員制定適當?shù)拈_發(fā)策略消除這些風險。 5. 某大學準備開發(fā)一個新的學生注冊選課系統(tǒng)，以替換一個現(xiàn)有的系統(tǒng)。請設計一個適用于該系統(tǒng)開發(fā)的過程模型，并進一步描述該模型。 答： 假設原有的學生注冊課程系統(tǒng)是由學生手工提交書面選課單，教師手工提交成績單，教務管理人員在客戶端錄入學生選課結果和課程成績；而在新的選課系統(tǒng)中，所有用戶在自己的計算機上通過Internet訪問和操作該系統(tǒng)，該軟件系統(tǒng)需要更新服務器和數(shù)據(jù)庫等系統(tǒng)，并擴充一些新功能和提高系統(tǒng)性能。 從該系統(tǒng)的具體情況來看，系統(tǒng)的需求是比較容易明確的，整個系統(tǒng)的結構需要重新設計，但是原有的遺留系統(tǒng)中有些部分是可以重用的，因此我們

42、可以采用組件模型實施軟件開發(fā)： 系統(tǒng)需求分析：由于該系統(tǒng)是現(xiàn)有系統(tǒng)的擴展，因此首先可以經(jīng)過一個簡單的需求分析階段，從而確定新系統(tǒng)的需求。 遺留系統(tǒng)分析：在需求確定的基礎上，開發(fā)人員分析遺留系統(tǒng)并研究新系統(tǒng)的總體結構，選擇重用原有的課程信息管理部分，重新開發(fā)選課部分，必要時適當修改系統(tǒng)需求，最終確定系統(tǒng)需求和總體結構。 設計開發(fā)階段：開發(fā)人員進一步設計相關子系統(tǒng)，將原有的課程信息管理部分封裝為子系統(tǒng)，重新開發(fā)學生選課子系統(tǒng)，并實現(xiàn)與外部付費系統(tǒng)的接口。 系統(tǒng)測試階段：開發(fā)人員將所有子系統(tǒng)集成在一起，交給測試人員開始全面的功能測試和性能測試。根據(jù)所報告的測試問題，開發(fā)人員調(diào)試和修改程序。 系統(tǒng)交付

43、階段：測試通過后，開發(fā)人員將系統(tǒng)及其相關文檔交付用戶驗收。 6. 請舉例說明不同的過程模型組合使用的情況。 答： 在前面提到的企業(yè)管理ERP系統(tǒng)項目中，可以將快速原型方法、組件開發(fā)模型和增量模型組合在一起使用，即在需求分析階段采用原型方法確定需求，采用組件化的結構設計整個系統(tǒng)，并采用增量方式逐步交付整個系統(tǒng)。 軟件項目管理2. 某個軟件項目需要 30 名開發(fā)人員，現(xiàn)有兩種人員組織方案： （1） 將 30 人劃為一個開發(fā)組統(tǒng)一管理； （2） 按每個小組 6 人的方式，將 30 人分為 5 個小組。 請分析比較上述兩種方案的優(yōu)缺點。 參考答案： 由于軟件規(guī)模的增大，需要多人組成開發(fā)小組共同參與一個

44、項目的開發(fā)。但是當多個人共同承 擔軟件開發(fā)項目中的某一任務時，人與人之間必須通過交流來解決各自承擔任務之間的接口問題， 這就產(chǎn)生了所謂溝通復雜性的問題。溝通需要花費時間和代價，也會引起軟件錯誤的增加，降低開 發(fā)效率。 （1） 優(yōu)點：30 人集中在同一個開發(fā)小組，人員任務的分配和調(diào)度相對容易； 缺點：溝通復雜性高，從而導致人員之間配合混亂，開發(fā)效率低。 （2） 優(yōu)點：30 人劃分成 5 個小組，降低了溝通復雜性，提高開發(fā)效率； 缺點：小組之間的協(xié)調(diào)配合難度大。3. 在選擇人員進行軟件項目開發(fā)時，應該考慮哪些因素？ 參考答案： 需求工程1. 請舉例說明使用自然語言描述用戶需求和系統(tǒng)需求的問題。 答

45、： 用自然語言描述比較詳細的需求時經(jīng)常暴露以下問題，從而容易引起誤解。 由于自然語言存在二義性，因此人們對同一個術語經(jīng)常存在語義理解上的偏差。 用自然語言描述需求存在比較大的隨意性，人們對同一個事物有完全不同的方式進行描述。 自然語言描述需求缺乏模塊化，因此很難發(fā)現(xiàn)所描述需求之間的相關性。 2. 請指出下面需求描述存在的問題，并進行適當?shù)男薷摹?（1） 系統(tǒng)用戶界面友好。 （2） 系統(tǒng)運行時應該占用盡量少的內(nèi)存空間。 （3） 即使在系統(tǒng)崩潰的情況下，用戶數(shù)據(jù)也不能受到破壞。 （4） ATM 系統(tǒng)允許用戶查詢自己銀行帳戶的現(xiàn)存余額。 （5） ATM 系統(tǒng)應該快速響應用戶的請求。 （6） ATM

46、系統(tǒng)需要檢驗用戶存取的合法性。 （7） 所有命令的響應時間小于 1 秒；BUILD 命令的響應時間小于 5 秒。 （8） 軟件應該用 JAVA 語言實現(xiàn)。 答： （1） 問題：“友好”是不可驗證的。 改正：具有一年計算機使用經(jīng)驗的用戶經(jīng)過 3 小時的培訓就可以學會使用該系統(tǒng)。 （2） 問題：“盡量少”存在歧義。 改正：系統(tǒng)運行時所占用的最大內(nèi)存空間是 256MB。 （3） 問題：“不能受到破壞”是不可驗證的。 改正：如果系統(tǒng)發(fā)生崩潰，那么該系統(tǒng)重新正常啟動后，可以將用戶數(shù)據(jù)恢復到最后 未完成操作執(zhí)行前的狀態(tài)。 （4） 該描述是正確的。 （5） 問題：“快速”是不可驗證的。 改正：ATM 系統(tǒng)將

47、在 1 秒鐘之內(nèi)響應用戶的請求。 （6） 問題：“如何驗證合法性”是存在歧義的。 改正：ATM 系統(tǒng)將通過用戶名和口令驗證其存取的合法性。 （7） 問題：所有命令中必然會包括 BUILD 命令，因此這兩個需求描述是矛盾的。 改正：去掉關于 BUILD 命令的需求描述。 （8） 問題：該描述不是功能需求或非功能需求，應該是對設計實現(xiàn)的一個約束條件。3. 需求工程包括哪些基本活動？每一項活動的主要任務是什么？ 答： 需求工程分為需求開發(fā)和需求管理兩個部分，而需求開發(fā)又可進一步分為需求獲取、需求分 析、規(guī)格說明和需求驗證四個階段。這些基本活動的主要任務包括： （1） 需求獲?。翰杉?、識別和提取用戶的

48、需求，對問題和需求形成文檔化的描述，使各種 人員達成一致的理解和認可。 （2） 需求分析：分析和綜合所采集的信息，建立系統(tǒng)的詳細邏輯模型。 （3） 需求規(guī)格說明：編寫軟件需求規(guī)格說明書，明確、完整和準確地描述已確定的需求。 （4） 需求驗證：評審軟件需求規(guī)格說明，以保證其正確性、一致性、完備性、準確性和清 晰性。 （5） 需求管理：定義需求基線，在整個項目過程中跟蹤需求狀態(tài)及其變更情況。4. 請比較本章介紹的幾種主要需求獲取技術，說明每一種技術的優(yōu)缺點和適用場合。 答： （1） 用戶面談 優(yōu)點： 可以與項目相關人員一對一地進行交談和討論； 具有私密性，使被訪者可以直率地和無隱瞞地回答問題； 便

49、于探查一些附加信息或反饋信息； 有利于與客戶建立良好的關系。 缺點： 面談是一種非常費時和高成本的方式； 難以解決不同的項目干系人之間的沖突和矛盾； 在地理位置相距較遠的情況下很難實施。 適用場合： 適用于在初步理解整體概念的情況下討論和交流一些細節(jié)問題。 （2） 需求專題討論會 優(yōu)點： 有助于了解系統(tǒng)需求； 有利于共享系統(tǒng)開發(fā)的成果； 給用戶一種主人的感覺； 可以與足夠多的項目干系人進行討論和交流，且節(jié)省時間； 支持頭腦風暴式的討論。 缺點： 需要占用參與人員比較長的整塊時間； 主持人的能力和會議的準備工作必須是非常好的，否則結果很糟。 適用場合： 適用于討論和審查軟件系統(tǒng)方案和模型，解決不

50、同項目干系人之間的沖突和矛盾。 （3） 觀察用戶工作流程 優(yōu)點： 通過直接觀察的方式提取用戶或系統(tǒng)的特性； 有助于理解難以用語言描述清楚的復雜業(yè)務。 缺點： 觀察可能使用戶緊張，從而表現(xiàn)得與往常不同。 適用場合： 適用于理解難以用語言描述清楚復雜業(yè)務過程。 （4） 原型化方法 優(yōu)點： 通過一個可以運行的軟件原型直觀地理解和澄清問題，便于使開發(fā)人員與用戶達成共識。 缺點： 用戶容易產(chǎn)生誤解，認為軟件系統(tǒng)可以在原型的基礎上很容易地構建，但實際上該原型的內(nèi)部結構和程序質量比較差。 適用場合： 適用于用戶需求不明確或描述不清楚的情況。5. 哪些人應該參與需求評審？請畫出一個需求評審的組織過程模型。 答

51、： 通常情況下，參與需求評審的人員應該包括需求分析員、項目經(jīng)理、體系架構設計師、軟件設計工程師、系統(tǒng)測試工程師、質量保證員、用戶或市場代表、文檔編寫人員、領域專家和技術支持代表。 6. 在某些緊急情況下，軟件可能在需求變更請求被批準之前就進行修改。請給出一個修改過程模型，確保需求文檔和系統(tǒng)實現(xiàn)不會產(chǎn)生不一致。 答： 一般來說，應該盡量避免在需求變更請求被批準之前就直接修改程序的情況，這很容易導致變更失控而且需求描述與系統(tǒng)實現(xiàn)不一致。一旦出現(xiàn)這種情況，必須在系統(tǒng)變更完成后重新執(zhí)行需求跟蹤控制。 8. 請給出以下問題描述的用例模型。 一個新的音像商店準備采用計算機系統(tǒng)向比較廣泛的人群銷售或租借錄像

52、帶和光碟。該音像商店將存有大約1000盤錄像帶和500張光碟，這些訂購涉及多家訂購商。所有的錄像帶和光碟都有一個條碼，可以使用條碼掃描儀來支持銷售和返還，客戶會員卡也同時條碼化。 客戶可以預定錄像帶并在指定日期來取。系統(tǒng)必須擁有靈活的搜索機制來回答客戶的詢問，包括關于該音像商店還沒有進貨的電影（但可能是已經(jīng)請求訂購了）。 參考答案： 面向對象基礎1. 請解釋下列術語，并舉例說明之。 對象、類、屬性、操作、關聯(lián)、泛化、聚合、依賴 參考答案： （1） 對象（Object） 對象是系統(tǒng)中用來描述客觀事物的一個實體，它是構成系統(tǒng)的一個基本單位，由一組屬性和對這組屬性進行操作的一組服務組成。 舉例：中國

53、就是一個對象。 （2） 類（Class） 類是具有相同屬性和服務的一組對象的集合，它為屬于該類的全部對象提供了統(tǒng)一的抽象描述，包括屬性和服務兩個主要部分。 舉例：學生、人、樹木等都是類。 （3） 屬性（Attribute） 屬性是用來描述對象靜態(tài)特征的一個數(shù)據(jù)項。 舉例：學生具有姓名、性別、年齡等屬性。 （4） 操作（Operation） 操作是類的實例被要求執(zhí)行的服務，具有名字和參數(shù)列表。 舉例：學生具有入學注冊、選課等操作。 （5） 關聯(lián)（Association） 關聯(lián)是一種結構關系，說明一個事物的對象與另一個事物的對象之間的聯(lián)系。 舉例：學生與課程之間的關系就是關聯(lián)，一個學生可以選修多門

54、課程，一門課程也可以被多個學生選修。 （6） 泛化（Generalization） 泛化是一種一般事物（父類）和特殊事物（子類）之間的關系。 舉例：學生與研究生之間是泛化關系，研究生是一類特殊的學生。 （7） 聚合（Aggregation） 聚合是一種特殊類型的關聯(lián)，描述了整體和部分間的結構關系。 舉例：學校和系之間存在聚合關系，系是學校的一個組成部分。 （8） 依賴（Dependency） 依賴是一種使用關系，描述了一個事物發(fā)生變化會影響到另一個使用它的事物。 舉例：課程表使用課程，二者之間是依賴關系。 2. 請簡要說明類圖和順序圖的組成。 參考答案： 在系統(tǒng)中，類圖由類、類的屬性和操作以及

55、類之間的各種聯(lián)系所組成。下圖顯示了計算機及其組成部分，如處理器、內(nèi)存、鍵盤、硬盤、顯示器等。 時序圖表示對象之間的交互順序，它由角色、對象、生命線和消息組成，其中角色代表與系統(tǒng)交互的外部事物。下圖顯示了時序圖的一種通用表示方法。 3. 在軟件開發(fā)過程中為什么需要建立模型？ 答案要點： 在軟件開發(fā)過程中，建立軟件模型具有十分重要的作用，主要體現(xiàn)在以下方面： 1.有助于問題的簡化，通過抽象降低復雜性；2.有助于和其他開發(fā)小組成員、各種用戶以及系統(tǒng)相關者進行交流；3.有助于維護人員了解軟件設計的思路和細節(jié)，為以后的維護和升級提供了文檔。4. UML關系包括關聯(lián)、聚合、泛化、實現(xiàn)、依賴等5種類型，請指

56、出下面關系的類型，并采用UML符號表示這些關系。 （1） 在學校中，一個學生可以選修多門課程，一門課程可以由多個學生選修，那么學生和課程之間是什么關系？ （2） 類A的一個操作調(diào)用類B的一個操作，且這兩個類之間不存在其他關系，那么類A和類B之間是什么關系？ （3） 接口及其實現(xiàn)類或構件之間是什么關系？ （4） 一個汽車有四個輪子，那么類“汽車”和“輪子”之間是什么關系？ （5） 學生與研究生之間是什么關系？ 參考答案： （1） 關聯(lián) （2）依賴 （3）實現(xiàn) （4）聚合 （5）泛化 5. 請根據(jù)下面的描述，給出表示一本書的類圖。 一本書由許多部分組成，而這些部分又由許多章組成，章由節(jié)組成。 一本書包括出版商、出版日期和ISBN；一部分包括一個標題和一個序號；一章包括一個標題、一個序號和一個摘要；一節(jié)包括一個標題和一個序號。 參考答案： 6. 考慮習題5的類圖，注意部分、章和節(jié)等類都包括標題和序號屬性，請修改類圖，添加一個抽象類和一個泛化關系，將標題和序號這兩個屬性提