軟件工程簡答復習題解析

1、第一章1. 軟件的特點是什么？ 軟件是邏輯實體；具有抽象性；軟件的形態(tài)不可見 軟件的生產(chǎn)過程和生產(chǎn)方式與硬件不同。 軟件與硬件的維護方式不同。 軟件是復雜的。 軟件成本越來越高。2. 2006 年發(fā)布的國家分類標準是什么？1）按功能：系統(tǒng)軟件、支撐軟件、應用軟件2）按規(guī)模：微型軟件、小型軟件、大型軟件、甚大型軟件、極大型軟件3）按工作方式：實時處理軟件、分時軟件、交互式軟件、批處理軟件4）按服務對象：項目軟件、產(chǎn)品軟件5）按使用頻度：使用頻度低、使用頻度高6）按失效影響：不良影響、嚴重影響3. 軟件危機的表現(xiàn)有哪些？ 進度難以預測 成本難以控制 功能難以滿足用戶 質量無法保證 產(chǎn)品難以維護 缺

2、少適當?shù)奈臋n4. 產(chǎn)生軟件危機的原因是什么？ 用戶需求不明確 缺乏正確的理論指導 軟件開發(fā)規(guī)模越來越大 軟件開發(fā)復雜度越來越高注：（1和2是主觀：開發(fā)方法不正確； 3和 4客觀：邏輯部件規(guī)模龐大）5. 什么是軟件工程三要素 ?方法、工具、過程6. 軟件工程的基本目標是什么 ? 付出較低的開發(fā)成本 達到要求的軟件功能 取得較好的軟件性能 開發(fā)的軟件易于移植 需要較低的維護費用 能按時完成開發(fā)工作，及時交付使用7. 軟件工程的基本原則是什么？ 抽象： 采用分層次抽象，自頂向下、逐層細化的辦法控制軟件開發(fā)過程的復雜性。 信息隱蔽： 將模塊設計成 “黑箱 ”，實現(xiàn)的細節(jié)隱藏在模塊內部，不讓模塊的使用者

3、直接訪問。這就是信 息封裝，使用與實現(xiàn)分離的原則。 模塊化： 如 C 語言程序中的函數(shù)過程， C+ 語言程序中的類。模塊化有助于信息隱蔽和抽象，有助于表 示復雜的系統(tǒng)。 局部化： 要求在一個物理模塊內集中邏輯上相互關聯(lián)的計算機資源，保證模塊之間具有松散的耦合，模 塊內部具有較強的內聚。這有助于控制解的復雜性。 確定性： 軟件開發(fā)過程中所有概念的表達應是確定的、無歧義性的、規(guī)范的。 一致性： 整個軟件系統(tǒng)的各個模塊應使用一致的概念、符號和術語。程序內部接口應保持一致。軟件和 硬件、操作系統(tǒng)的接口應保持一致。系統(tǒng)規(guī)格說明與系統(tǒng)行為應保持一致。用于形式化規(guī)格說明的公理 系統(tǒng)應保持一致。 完備性：軟件

4、系統(tǒng)不丟失任何重要成分，可以完全實現(xiàn)系統(tǒng)所要求功能的程度。為了保證系統(tǒng)的完備性， 在軟件開發(fā)和運行過程中需要嚴格的技術評審。 可驗證性：開發(fā)大型的軟件系統(tǒng)需要對系統(tǒng)自頂向下、逐層分解。系統(tǒng)分解應遵循系統(tǒng)易于檢查、測試、 評審的原則，以確保系統(tǒng)的正確性。8. 軟件工程的基本原理是什么？ 用分階段的生命周期嚴格管理； 堅持進行階段評審； 實行嚴格的產(chǎn)品控制； 采用現(xiàn)代程序設計技術； 結果應能清楚地審查； 開發(fā)小組人員應少而精； 承認不斷改進軟件工程實踐的必要性。9. 瀑布模型有什么特點？1）其核心思想是按工序將問題簡單化2）采用結構化的分析與設計方法將邏輯實現(xiàn)以物理實現(xiàn)分開。3） 瀑布型將軟件生命

5、周期劃分為軟件計劃、需求分析和定義（前兩者為定義階段）、軟件設計、軟件編碼、軟件測試（前面為開發(fā)階段）、軟件運行維護（最后一個為維護階段）6個階段。9. 瀑布模型有什么特點？1）最早岀現(xiàn)的軟件開發(fā)模型，它提供了軟件開發(fā)的基本框架。2）瀑布模型的本質是一次通過，即每個活動只執(zhí)行一次，最后得到軟件產(chǎn)品。3）瀑布模型有利于大型軟件開發(fā)過程中人員的組織及管理，有利于軟件開發(fā)方法和工具的研究與使用，從 而提高了大型軟件項目開發(fā)的質量和效率。4）里程碑或基線驅動，或者說文檔驅動；瀑布模型的缺陷： 由于開發(fā)模型呈線性，所以當開發(fā)成果尚未經(jīng)過測試時，用戶無法看到軟件的效果。這樣軟件與用 戶見面的時間間隔較長，

6、也增加了一定的風險。 在軟件開發(fā)前期末發(fā)現(xiàn)的錯誤傳到后面的開發(fā)活動中時，可能會擴散，進而可能會造成整個軟件項 目開發(fā)失敗。 在軟件需求分析階段，完全確定用戶的所有需求是比較困難的，甚至可以說是不太可能的。瀑布模型即生存周期模型，其核心思想是按工序將問題化簡，將功能的實現(xiàn)與設計分開，便于分工協(xié)作，即采用結構化的分析與設計方法將邏輯實現(xiàn)與物理實現(xiàn)分開。瀑布模型將軟件生命周期劃分為軟件計劃、需求分析和定義、軟件設計、軟件編碼、軟件測試、軟件運行維護6個階段，規(guī)定了他們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。10. 說明生命周期的劃分？瀑布型將軟件生命周期劃分為軟件計劃、需求分析和定義（前

7、兩者為定義階段）、軟件設計、軟件編碼、軟件測試（前面為開發(fā)階段）、軟件運行維護（最后一個為維護階段）6個階段。10. 說明生命周期的劃分？一個軟件從定義、開發(fā)、使用和維護，直到最終被廢棄，所經(jīng)歷的生存過程稱為軟件生存期或叫生命期。包 括計劃、需求分析、軟件計劃、程序編碼、軟件測試和運行維護6各階段。11. 列岀軟件生存期的幾個主要模型？- 瀑布模型- 原型模型 螺旋模型- 增量模型4 構件組裝模型Q 統(tǒng)一過程模型Q 第四代技術12. 瀑布模型軟件開發(fā)方法的基本過程？定義階段：計劃、需求分析開發(fā)階段：設計、編碼、測試維護階段：運行維護13. 增量模型有什么特點？任務或功能模塊驅動，可以分階段提交

8、產(chǎn)品；有多個任務單，這些多個任務單的集合，構成項目的一個總任務書（總用戶需求報告）。13. 增量模型有什么特點？1）融合了線性順序模型的基本成份和原型實現(xiàn)模型的迭代特征。2）增量模型采用隨著日程時間的進展而交錯的線性序列。每一個線性序列產(chǎn)生軟件的一個可發(fā)布的增量'3）增量模型強調每一個增量均發(fā)布一個可操作產(chǎn)品。早期的增量是最終產(chǎn)品的可拆卸”版本，但他們確實提供了給用戶服務的功能，并且提供了給用戶評估的平臺。將軟件產(chǎn)品看作一組增量構件，每次設計、實現(xiàn)、集成、測試和交付一塊構件，直到所有構件全部實現(xiàn)為止。 特點：1）任務或功能模塊驅動，可以分階段提交產(chǎn)品；2）有多個任務單，這些多個任務單的

9、集合，構成項目的一個總任務書（總用戶需求報告）。14. 幾種主要的軟件開發(fā)方法？ 結構化開發(fā)方法 面向對象的方法15. 軟件工程中的五個面向”？面向流程分析、面向數(shù)據(jù)設計、面向對象實現(xiàn)、面向功能測試、面向過程管理。第二章1. 可行性分析的目的？1）用最小的代價在盡可能短的時間內確定問題是否能夠解決。2）確定問題是否能夠解決和值得解決。3）分析可能的利弊關系。2. 可行性分析最為敏感的方面是什么？經(jīng)濟可行性：經(jīng)濟效益能否超過開發(fā)成本？技術可行性：現(xiàn)有技術能否實現(xiàn)？技術風險的各種因素？ 操作可行性：用戶的接受程度如何？法律可行性：是否合法，是否侵犯他人的利益。3. 可行性研究的步驟有哪些 ？ 系統(tǒng)

10、調研（復查系統(tǒng)規(guī)模和目標） 現(xiàn)行系統(tǒng)分析（研究目前正在使用的系統(tǒng)） 建議新系統(tǒng)（導岀新系統(tǒng)的高層邏輯模型） 模型評審（重新定義問題） 導岀和評價可供選擇的解決方案 推薦一個方案并說明理由 推薦行動方針 書寫文檔提交審查（可行性分析報告）4. 軟件計劃的步驟有哪些 ？ 估計軟件的規(guī)模及所需的資源； 制定時間表； 鑒別和評估風險； 約定與限制條件。5. 軟件計劃書的內容有哪些 ? 軟件范圍 環(huán)境資源 進度安排 成本 / 效益分析 其它要考慮的因素6. 甘特圖有哪些優(yōu)點和缺點？ 甘特圖：是一種對各項活動進行計劃調度與控制的圖表。橫向表示時間，縱向列出任務。 優(yōu)點：它具有簡單、醒目和便于編制等特點。能

11、夠動態(tài)反映軟件項目開發(fā)進展的情況。 缺點：難以反映多個任務之間存在的復雜的邏輯關系。7. 什么是網(wǎng)絡計劃法的關鍵事件與關鍵路徑？ 關鍵事件：最早完成時間與最遲完成時間相等的事件。 關鍵路徑：關鍵事件聯(lián)結的各個活動所組成的路線。8. 常用的成本估算方法有哪些 ?(1) 基于代碼行的成本估算方法(2) 任務分解成本估算(3) 經(jīng)驗統(tǒng)計估算模型 參數(shù)方程 動態(tài)多變量參數(shù)模型 COCOMO 模型( constructive Cost Model )自動估算工具9. 軟件成本估算包括哪些內容 ?工作產(chǎn)品規(guī)模估計工作量及成本估計關鍵資源的量化估計10. 項目活動和項目約定計劃指的是什么 ? 活動指開發(fā)活動

12、和管理活動；約定指各種規(guī)范、標準、規(guī)則；規(guī)范：是對過程和行為的約束； 標準：是對產(chǎn)品的約束； 規(guī)則或規(guī)程：是對操作的約束。第三章1.為什么說需求獲取難？ 用戶需求具有動態(tài)性 (不穩(wěn)定性 ) 。 用戶需求具有模糊性 (不準確性 ) 。 對需求達成一致的艱難性。 管理體制、機構設置處在變革中。 軟件書籍沒有將需求分析講清楚。2. 需求分析的重點是哪些？業(yè)務模型、功能模型、性能模型、接口模型。3. 需求分析的 9 大任務是什么？ 畫出系統(tǒng)的組織結構圖、列出各部門的崗位角色（機構模型）。 畫出系統(tǒng)業(yè)務操作流程圖。 畫岀系統(tǒng)的數(shù)據(jù)流圖，掌握業(yè)務規(guī)則，獲得初步數(shù)據(jù)模型。 列出系統(tǒng)的功能點，即功能模型。 列

13、岀系統(tǒng)的性能點，即性能模型。 列岀系統(tǒng)的接口，即接口模型。 確定系統(tǒng)的運行環(huán)境，即環(huán)境模型。 確定系統(tǒng)的界面約定，即界面模型。 對開發(fā)工期、費用、開發(fā)進度、系統(tǒng)風險等分析與評估。4. 簡述需求分析的過程？Q 問題識別。 分析與綜合4 編制需求分析階段文檔Q 需求分析評審5. 獲取需求的常用方法有哪些？ 訪談/個別訪問：正式的和非正式的訪談 問卷調查/書面調查：發(fā)電子郵件、問卷調查即把需要調查的內容制成表格交給用戶填寫。該方法對需 要調查大量人員的意見時，十分有效。 情景分析/電話和電視會議：對目標系統(tǒng)解決某個具體問題的方法和結果，給出可能的情景描述，以獲知 用戶的具體需求。 實地考察/收集資料

14、：開調查會參加業(yè)務實踐 構造原型6. 需求分析的原則是什么？ 解決邏輯問題：需求分析是對問題的識別和說明，要回答“做什么”，而不是“怎么做”。 以運行環(huán)境為基礎：需求分析工作應以具體的運行環(huán)境為基礎，實事求是。 用戶參與的原則：需求分析工作是系統(tǒng)分析人員同用戶不斷交互的過程。 構造高質量的需求規(guī)格說明：需求規(guī)格說明是需求分析工作重要的完成標志。7. 需求分析的基本要求是什么？ 理解問題的數(shù)據(jù)域和功能域 自頂向下、逐層分解 給出系統(tǒng)的邏輯視圖和物理視圖8. 常見的需求分析方法有哪些？需求獲取、分析建模、文檔編寫、需求驗證；8. 常見的需求分析方法有哪些？ 面向數(shù)據(jù)流的分析方法 面向功能的分析方法

15、 面向數(shù)據(jù)的Jackson方法 面向對象的分析方法9. 需求分析方法有哪些共性？1. 支持數(shù)據(jù)域的分析機制2. 功能表示方法3接口的定義4. 問題的分解及抽象化5. 邏輯視圖和物理視圖6. 系統(tǒng)抽象模型4.1 思考題1. 軟件設計的具體任務包括哪些內容？(1) 制定規(guī)范(2) 結構設計(3) 處理方式設計(4) 數(shù)據(jù)結構及數(shù)據(jù)庫設計(5) 可靠性設計(質量設計)(6) 編寫軟件設計文檔(7) 設計審查和復審(8) 詳細設計2. 什么是數(shù)據(jù)的保護性設計？1) 防衛(wèi)性設計：在軟件設計中就插入自動檢錯，報錯和糾錯的功能2) 一致性設計： 在并發(fā)處理過程中使用封鎖和解除封鎖機制保持數(shù)據(jù)不被破壞3) 冗

16、余性設計：3. 軟件設計的目標是什么？ 軟件設計的最終目標：取得最佳方案 節(jié)省開發(fā)費用、 降低資源消耗、 縮短開發(fā)時間、 能夠贏得較高的生產(chǎn)效率、 較高的可靠性、 可維護性的方案。4. 模塊具有哪些基本屬性 ?“模塊”，又稱 “組件”。一般有四個基本屬性 功能：描述該模塊做什么？ 邏輯：描述模塊內部怎么做？ 狀態(tài)：模塊使用時的環(huán)境和條件。接口：指模塊的輸入與輸出。5. 什么是耦合？什么是內聚？如何增強模塊的獨立性？ 耦合：各模塊之間的互相連接的緊密程度。模塊之間的連接越緊密，聯(lián)系越多，耦合性就越高，而其獨 立性就越弱。內聚：模塊內各功能元素彼此結合的緊密程度。一個模塊內部各個元素之間的聯(lián)系越緊

17、密，則它的內聚 性就越高，相對地，它與其它模塊之間的耦合性就會減低，而模塊獨立性就越強。增強模塊獨立性的方法是盡量做到高內聚、低耦合。6. 模塊化的特征有哪些？ 抽象：用層次的方式構造和分析復雜系統(tǒng)。 逐步求精：幫助開發(fā)人員把精力集中在與當前開發(fā)階段最相關的那些問題上。 信息隱蔽：如果一個模塊內包含的信息 ( 過程和數(shù)據(jù) ) 不允許外部的模塊訪問的話，其它模塊不能對其訪 問。局部化：把一些關系密切的軟件元素物理地放得彼此靠近。7. 影響耦合度的因素有哪些？ 連接方式的類型。 接口的復雜性。 傳送的信息流類型。 耦合的時間。8. 降低耦合度的方法有哪些？ 耦合度是評價程序質量的重要指標，耦合度越

18、小，則每個模塊越容易獨立地被理解、編寫和修改，同時每個 模塊的錯誤越不容易擴散蔓延到其他模塊。 對需要了解的內容，隱含的改為明顯的，便于理解； 連接的方式盡量標準化，避免直接引用； 減少公共區(qū)，將公共區(qū)劃分為若干個邏輯子區(qū)； 輸入輸出應局限在少量模塊，不要分散在全系統(tǒng)；9. 軟件結構設計優(yōu)化的準則是什么？1) 劃分模塊時，盡量做到高內聚、低耦合，保持模塊相對獨立性。模塊劃分的準則： “將相關的各部分放在 一起，無關的東西不要放在一起。 ”2) 模塊的大小要適中。3) 模塊的接口要簡單、清晰、含義明確。便于理解，易于實現(xiàn)、易于測試和維護。4) 一個模塊的作用范圍應在其控制范圍之內。 且判定所在的

19、模塊， 應與受其影響的模塊在層次上盡量靠近。5) 軟件結構的深度、寬度、扇入、扇出應適當。6) 力求設計單入口和單出口的模塊。避免“病態(tài)連接” ，以防止內容耦合。7) 設計功能可預測模塊的劃分，應防止功能過分局限。4.2 思考題1. 結構化設計的優(yōu)點是什么？ 減少設計復雜性。將大化小，使復雜問題簡單化。 結構獨立。將程序劃分成多個相對獨立的模塊。 模塊功能單一化，可使軟件設計獲得最大的益處。 便于軟件的修改。 易于開發(fā)和維護。 加強了代碼的可重用性。3. 正交軟件體系結構的優(yōu)點是什么？ 層次結構清晰，便于理解。 可移植性強，重用粒度大。 易修改，可維護性強。4. 三層 C/S 結構的組成 表示

20、層：用戶接口部分，擔負著用戶與應用間的對話功能。 功能層：相當于應用的本體，將具體的業(yè)務處理邏輯程序。 數(shù)據(jù)層：數(shù)據(jù)庫管理系統(tǒng)，負責管理對數(shù)據(jù)庫數(shù)據(jù)的讀/ 寫。5. 三層結構設計的優(yōu)點是什么？ 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性。 允許更靈活有效地選用相應的平臺和硬件系統(tǒng)，使之在處理負荷能力上與處理特性上分別適應于結構清 晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性 。 三層 C/S 結構中，應用的各層可以并行開發(fā)，各層也可以選擇各自最適合的開發(fā)語言。 允許充分利用功能層有效地隔離開表示層與數(shù)據(jù)層，未授權的用戶難以繞過功能層而利用數(shù)據(jù)庫工具或 黑客手

21、段去非法地訪問數(shù)據(jù)層 。6. B/S 體系結構的不足之處 ? 缺乏對動態(tài)頁面的支持能力，數(shù)據(jù)庫處理能力差。 系統(tǒng)擴展能力差，安全性難以控制。 響應速度遠低于 C/S 體系結構。 數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務處理(OLTP )應用。7. C/S、B/S 混合結構的特點是什么 ?B/S 與 C/S 混合結構是一種典型的異構系統(tǒng)。C/S 與 B/S 混合結構的優(yōu)點：外部用戶不直接訪問數(shù)據(jù)庫服務器，能保證企業(yè)數(shù)據(jù)庫的相對安全。企業(yè) 內部用戶的交互性較強，數(shù)據(jù)查詢和修改的響應速度較快。C/S 與 B/S 混合結構的缺點：企業(yè)外部用戶修改和維護數(shù)據(jù)時，速度較慢，較煩瑣，數(shù)

22、據(jù)的動態(tài)交互性 不強。8. 列出幾種主要的菜單類型 ? 固定菜單 活動菜單 “彈出式 ”菜單 “下拉式 ”菜單9. 活動菜單的優(yōu)點是什么？ 不占用顯示工作空間， 可以根據(jù)用戶當前所處的操作狀態(tài)和要求動態(tài)出現(xiàn)。 需要注意的是不能濫用彈出菜單。4.3 思考題1. DBMS 有哪些基本功能？1) 建立數(shù)據(jù)庫的結構；2) 管理用戶的數(shù)據(jù)庫；3) 提供在數(shù)據(jù)庫上的各種操作；4) 提供數(shù)據(jù)庫對外的各種接口；2.DB、 DBMS 有何不同？在人們的交流中，習慣上常常將數(shù)據(jù)庫和 DBMS 混為一談，不加區(qū)別。所以要根據(jù)不同場合、不同習慣、以 及上下文來分析，所講的 “數(shù)據(jù)庫 ”三個字，到底是指數(shù)據(jù)庫，還是指

23、DBMS。2. DBMS 提供的三種語言是什么？ DDL (數(shù)據(jù)庫定義語言) ：如： CREATE， ALTER ，DROP ； DML (數(shù)據(jù)庫操作語言) ：如： SELECT ， UPDA TE ， INSERT ，DELETE ； DCL (數(shù)據(jù)庫控制語言) ：如： LOCK 、UNLOCK ；3. 四個表指的是什么？ 分別是：基本表、代碼表、中間表、臨時表4. 基本表的性質有哪些？為什么？1) 原子性?；颈碇械淖侄问遣豢稍俜纸獾?。2) 原始性?；颈碇械挠涗浭窃紨?shù)據(jù)(基礎數(shù)據(jù))的記錄。3) 演繹性。由基本表與代碼表中的數(shù)據(jù)，可以派生出所有的輸出數(shù)據(jù)。4) 穩(wěn)定性?；颈淼慕Y構是相對

24、穩(wěn)定的，表中的記錄是需要長期保存的。5. 怎樣正確認識“數(shù)據(jù)冗余”？1) 主鍵與外鍵在多表中的重復出現(xiàn) , 不屬于數(shù)據(jù)冗余，這個概念必須清楚，事實上有許多人還不清楚。2) 非鍵字段的重復出現(xiàn) , 才是數(shù)據(jù)冗余，而且是一種低級冗余，即重復性的冗余。3) 高級冗余不是字段的重復出現(xiàn)，而是字段的派生出現(xiàn)。第五章1. 代碼設計的主要原則是什么？1) 使用語言中的順序、選擇、重復等有限的基本控制結構表示程序邏輯。2) 選用的控制結構只準許有一個入口和一個出口。3) 程序語句組成容易識別的塊，每塊只有一個入口和一個出口。4) 復雜結構應該用基本控制結構進行組合嵌套來實現(xiàn)。2. 編程規(guī)范包括哪些內容？3.

25、良好的代碼設計風格包括哪些內容？1）規(guī)范化的程序內部文檔、2）數(shù)據(jù)結構的詳細說明、3）清晰的語句結構、4）遵守某一編程規(guī)范，內容包括：命名規(guī)范、界面規(guī)范、提示及幫助信息規(guī)范、熱鍵定義等。4. 代碼語句設計應遵從哪些原則？1）在一行內只寫一條語句：采取適當?shù)囊菩懈袷?，使程序的邏輯和功能變得更加明確。在一行內寫多個語句 會使程序可讀性變差。2）程序編寫清晰性第一：不要刻意追求技巧性，使程序編寫得過于緊湊。3）程序要能直截了當?shù)卣f明程序員的用意：程序編寫要簡單，清楚，直截了當?shù)卣f明程序員的用意。4）清晰第一，效率第二：不要為了追求效率而喪失了清晰性。事實上，程序效率的提高主要應通過 選擇高效的算法來

26、實現(xiàn)。5）先保證程序正確 , 再要求提高速度。6）避免使用臨時變量而使可讀性下降。7）讓編譯程序做簡單的優(yōu)化。8）盡可能使用庫函數(shù)和構件。9）避免不必要的轉移：盡量不用 GO TO 語句。10）盡量采用三種基本的控制結構編寫程序。11）避免使用空的 ELSE語句和IF THEN IF的語句。這種結構容易使讀者產(chǎn)生誤解?？赡墚a(chǎn)生 二義性問題。12）避免采用過于復雜的條件測試。13）盡量減少使用“否定”條件的條件語句。14）盡量用通俗易懂的偽碼來描述程序的流程：然后再翻譯成必須使用的語言。15）數(shù)據(jù)結構要有利于程序的簡化。16）要模塊化： 使模塊功能盡可能單一化， 模塊間的耦合能夠清晰可見。17）

27、利用信息隱蔽： 確保每一個模塊的獨立性。18）從數(shù)據(jù)出發(fā)構造程序。19）修補不好的程序，要重新編寫： 也不要一味地追求代碼的復用，要重新組織。20）大的程序要分塊編寫和測試： 然后再集成。21）對遞歸定義的數(shù)據(jù)結構盡量使用遞歸過程。5. I/O 代碼設計的原則是什么？1）輸入數(shù)據(jù)要檢驗：識別錯誤的輸入，以保證每個數(shù)據(jù)的有效性；2）檢查輸入項的各種重要組合的合理性：必要時報告輸入狀態(tài)信息；3）輸入的步驟和操作盡可能簡單：并保持簡單的輸入格式；4）應允許使用自由格式輸入數(shù)據(jù)；5）應允許缺省值；6）批數(shù)據(jù)輸入時，使用輸入結束標志：而不要由用戶指定輸入數(shù)據(jù)數(shù)目；7）交互式輸入時，屏幕上使用提示符明確提

28、示輸入的請求：指明可使用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結束時，也要在屏幕上給出狀態(tài)信息；8）程序設計語言對 I/O 格式有嚴格要求時，應 保持輸入格式與輸入語句要求的一致性；9）輸出加注解， 并設計輸出報表格式。10）軟件效率應該以什么為準 ?6. 軟件效率應該以什么為準 ?6. 答：軟件效率以需求為準7. 程序的效率與哪些因素有關 ?答：程序的效率與程序的簡單性、可讀性和正確性因素有關。7. 程序的效率與哪些因素有關 ?程序的效率是指程序的 執(zhí)行速度 及程序所需占用的內存的 存儲空間 。討論程序效率的準則：1）效率性能要求， 應在需求分析階段給出。 軟件效率以需求為準

29、 ，不應以人力所及為準。 好的設計可 以提高效率。2）程序的 效率與程序的簡單性相關 。3）一般說來， 任何對效率無重要改善， 且對程序的簡單性、 可讀性和正確性不利的程序設計方法都是 不可取的。8. 詳細設計向代碼設計轉換過程的指導原則是什么 ?1）盡可能簡化有關的算術表達式和邏輯表達式；2）檢查算法中的嵌套的循環(huán)，盡可能將某些語句或表達式移到循環(huán)外面；3）盡量避免使用多維數(shù)組；4）盡量避免使用指針和復雜的表；5）采用“快速”的算術運算；6）不要混淆數(shù)據(jù)類型，避免在表達式中出現(xiàn)類型混雜；7）盡量采用整數(shù)算術表達式和布爾表達式；8）選用等效的高效率算法；9. 影響存儲器效率的因素是什么 ?1）

30、存儲效率與OS的分頁功能直接有關。2）采用結構化程序設計。3）提高存儲器效率的關鍵是程序的簡單性。10. 提高 I/O 設備效率的指導原則有哪些 ?1 ） I/O 的請求應當最小化；2）對于所有的 I/O 操作，安排適當?shù)木彌_區(qū)，以減少頻繁的信息交換。3）對輔助存儲 （例如磁盤 ） ，選擇盡可能簡單的，可接受的存取方法；4）對輔助存儲的 I/O ，應當成塊傳送；5）對終端或打印機的 I/O ，應考慮設備特性，盡可能改善 I/O 的質量和速度；6）任何不易理解的，對改善輸入 / 輸出效果關系不大的措施都是不可取的；7）任何不易理解的所謂“超高效”的 I/O 毫無價值；11. 提示信息分哪幾類 ?

31、1）引導性提示信息： 該類提示信息一般在需要用戶干預時出現(xiàn)，要求用戶決定下一步的操作。如在退出時提示“修改的數(shù)據(jù)尚未存盤，存盤否？”。使用MessageBox進行提示。2）錯誤性提示信息： 該類提示信息一般在軟件運行出錯時出現(xiàn)，告訴用戶軟件遇到了問題。如“系統(tǒng)運行 出現(xiàn)故障，請與系統(tǒng)管理員聯(lián)系！”。3）狀態(tài)性提示信息： 該類提示信息一般在軟件處于“忙”狀態(tài)下提示，告訴用戶軟件正在進行什么操作，讓用戶耐心等待。如“正在進行數(shù)據(jù)傳輸，請稍待”。4）位置性提示信息 ：該類提示信息一般根據(jù)鼠標的位置進行提示，告訴用戶鼠標正指向什么功能。如“報 表打印”。12. 軟件實現(xiàn)過程由哪些文檔的組成？源程序清單

32、用戶使用手冊用戶安裝手冊系統(tǒng)管理員手冊13. 軟件實現(xiàn)過程包括哪些管理文檔 ? 用戶指南評審報告 模塊源程序行統(tǒng)計表（行 / 模塊名） 源程序工作量統(tǒng)計表(行 / 人天)思考題 5.21. 軟件測試的原則？ 軟件測試應當盡早和不斷地進行。 程序員應避免檢查自己的程序。 設計測試即應包括合理的、還應包括不合理的輸入條件。 經(jīng)驗表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。 妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。2. 軟件測試的最初定義 ?1) 軟件測試是測試中的特例，它的測試對象是人類的智力產(chǎn)品-軟件2) 最初定義 ： “軟件測試是為了發(fā)現(xiàn)錯誤而

33、執(zhí)行程序的過程?！?. 軟件測試的經(jīng)典定義 ?1)測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；2) 一個好的測試在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；3) 一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。4.測試的目的？ 以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。 能夠證明軟件的功能和性能與需求說明相符合。 測試結果數(shù)據(jù)為可靠性分析提供了依據(jù)。 測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤。5. 黑盒測試的優(yōu)點？ 對于較大的代碼單元來說，黑盒測試比白盒測試效率要高； 測試人員不需要了解實現(xiàn)的細節(jié)，包括特定的編程語言； 從用戶的角度進行測試，容易被理解和接受； 有助于暴露任何規(guī)格不一致

34、或有歧義的問題；6. 黑盒測試的缺點？ 要測試每個可能的輸入流幾乎是不可能的； 會有很多程序路徑?jīng)]有被測試到； 不能直接針對特定程序段測試，因此可能隱藏更多的問題。7. 白盒測試的優(yōu)點？ 迫使測試人員去仔細思考軟件的實現(xiàn)； 可以檢測代碼中的每條分支和路徑； 揭示隱藏在代碼中的錯誤； 對代碼的測試比較徹底。8. 白盒測試的缺點？ 成本昂貴； 忽略了從用戶角度考慮的測試問題；9. 測試報告包括哪些內容？測試任務描述測試環(huán)境說明功能測試描述性能測試描述 確認性測試描述 測試總結思考題 5.31.軟件維護分類有哪些？糾錯性維護；適應性維護；完善性維護；預防性維護；2. 影響軟件維護的因素有哪些？ 軟件

35、配置是否完整是影響維護工作量的重要因素；修改別人的程序增加了維護的難度；文檔不全的軟件，增加了修改后測試的工作量；軟件結構的不合理，增加了軟件修改的困難；軟件經(jīng)過多個版本的演化，很難追蹤修改的過程；軟件維護經(jīng)常受挫，降低了該項工作的吸引力。3. 軟件維護有哪些副作用？ 修改編碼： 使編碼更加混亂，程序結構更不清晰，可讀性更差，而且有連鎖反應。 修改數(shù)據(jù)結構： 數(shù)據(jù)結構是系統(tǒng)的骨架，修改數(shù)據(jù)結構是對系統(tǒng)傷筋動骨的大手術，在數(shù)據(jù)冗余與數(shù)據(jù)不一致方面，可能顧此失彼。 修改用戶數(shù)據(jù)： 需要與用戶協(xié)商，一旦有疏忽，可使系統(tǒng)發(fā)生意外。 修改文檔： 對非結構化維護不適應，對結構化維護要嚴防程序與文檔的不匹配

36、。9. 什么叫結構化維護和非結構化維護？答：結構化維護的前提是：軟件產(chǎn)品或軟件項目必須有完善的文檔，并且文檔與程序代碼互相匹配。反之 為非結構化維護。10. 可維護性的軟件應具備什么性質？ 答：可理解性、可測試性、可修改性、可靠性、可移植性、可使用性、效率11. 兩層結構和三層結構的軟件維護方法有什么不同？12. 怎么理解軟件產(chǎn)品的版本號？13. 怎么理解 UML/CMMI 對軟件維護的影響？軟件為什么需要維護？因為它程序上有缺陷，所以有面向程序的缺陷維護；因為它設計上功能不齊 全，所以有面向設計的功能維護。當軟件組織達到 CMM3 以上時，由于軟件過程的持續(xù)改善，對軟件質量的評審和審計活動的

37、加強， 軟件過程數(shù)據(jù)庫作用的發(fā)揮，關于 “程序上有缺陷 ”和“設計上功能不齊全 ”的情況，將會逐漸減少， 所以軟件的維護工作量也會逐漸減少。真正維護工作量大的單位，就是 CMM1 的軟件組織，因為他們管理無序，文檔不全，工作不規(guī)范， 表現(xiàn)形式就是：人治加個人英雄主義。第一章 軟件工程概述1軟件的特點 軟件是邏輯實體；具有抽象性；軟件的形態(tài)不可見；必須通過觀察、分析、思考、判斷來了解其功能、性能和其它特性。軟件是人腦思維的產(chǎn)物，其生產(chǎn)過程與硬件不同。開發(fā)過程的質量控制及軟件產(chǎn)品保護問題。軟件的開發(fā)和運行受計算機系統(tǒng)限制。軟件移植問題。軟件的開發(fā)技術落后，手工開發(fā)方式仍占統(tǒng)治地位。開發(fā)效率低。22

38、006 年發(fā)布的國家分類標準獨立式組合式集成式嵌入式3軟件危機的表現(xiàn)對開發(fā)成本和進度的估算偏差太大沒有適當?shù)奈臋n 軟件成本比重上升 質量很不可靠 供不應求 用戶很不滿意 4產(chǎn)生軟件危機的原因 客觀：軟件本身特點邏輯部件 規(guī)模龐大 主觀：不正確的開發(fā)方法忽視需求分析“軟件開發(fā) = 程序編寫 ”的錯誤觀念 輕視軟件維護5軟件工程的三要素方法：為軟件開發(fā)提供了 “如何做 ”的技術。工具：為軟件工程方法提供了支撐環(huán)境。過程：定義了方法使用的順序、要交付的文檔資料、為保證質量和適應變化所需要的管理、軟件開發(fā)各個階段完成的里程碑。6軟件工程項目的基本目標付出較低的開發(fā)成本達到要求的軟件功能取得較好的軟件性

39、能開發(fā)的軟件易于移植需要較低的維護費用能按時完成開發(fā)工作，及時交付使用7軟件工程基本原則抽象 信息隱蔽 模塊化 局部化 確定性 一致性 完備性 可驗證性8軟件工程的基本原理用分階段的生命周期嚴格管理；堅持進行階段評審；實行嚴格的產(chǎn)品控制；采用現(xiàn)代程序設計技術；結果應能清楚地審查；開發(fā)小組人員應少而精；承認不斷改進軟件工程實踐的必要性。瀑布模型的特點里程碑或基線驅動，或者說文檔驅動；過程逆轉性很差，或者說不可逆轉。10軟件生命周期 一個軟件從定義、開發(fā)、使用和維護，直到最終被廢棄，所經(jīng)歷的生存過程稱為軟件生存期或叫生命期。生命期的劃分：制定計劃 需求分析和定義 軟件設計 程序編寫 軟件測試 運行

40、 /維護定義階段 開發(fā)階段 維護階段11軟件生存期的主要模型瀑布模型 原型模型 螺旋模型 增量模型 構件組裝模型 統(tǒng)一過程模型 第四代技術12（好像考過，挺重要的）瀑布模型開發(fā)的基本過程（看書上的圖 ）運行、維護定義 計劃階段需求分析開發(fā)設計階段編碼測試維護階段（總用戶需求報告 ）13增量模型的特點 任務或功能模塊驅動，可以分階段提交產(chǎn)品； 有多個任務單，這些多個任務單的集合，構成項目的一個總任務書14幾種主要的軟件開發(fā)方法 面向過程的方法 面向數(shù)據(jù)的方法 面向對象的方法 15軟件工程中的 “五個面向面向流程分析、 面向數(shù)據(jù)設計、 面向對象實現(xiàn)、 面向功能測試、 面向過程管理。第二章 軟件策劃

41、16可行性分析的目的 用最小的代價在盡可能短的時間內確定問題是否能夠解決。 確定問題是否能夠解決和值得解決。分析可能的利弊關系17可行性分析最為敏感的方面 經(jīng)濟可行性：經(jīng)濟效益能否超過開發(fā)成本？ 技術可行性：現(xiàn)有技術能否實現(xiàn)？技術風險的各種因素 ? 操作可行性：用戶的接受程度如何？ 法律可行性：是否合法，是否侵犯他人的利益。18可行性研究的步驟 復查系統(tǒng)規(guī)模和目標（系統(tǒng)調研） 研究目前正在使用的系統(tǒng)（系統(tǒng)分析） 導出新系統(tǒng)的高層邏輯模型（系統(tǒng)分析） 重新定義問題（模型評審） 導出和評價可供選擇的解決方案 推薦一個方案并說明理由 推薦行動方針 書寫文檔提交審查19軟件計劃的步驟 估計軟件的規(guī)模及

42、所需的資源； 制定時間表； 鑒別和評估風險； 約定與限制條件。20軟件計劃書的內容軟件范圍環(huán)境資源進度安排成本 /效益分析其它要考慮的因素21甘特圖有哪些優(yōu)點和缺點 甘特圖：是一種對各項活動進行計劃調度與控制的圖表。橫向表示時間，縱向列出任務。 優(yōu)點：它具有簡單、醒目和便于編制等特點。能夠動態(tài)反映軟件項目開發(fā)進展的情況。 缺點：難以反映多個任務之間存在的復雜的邏輯關系。22什么是網(wǎng)絡計劃法的關鍵事件與關鍵路徑 關鍵事件：最早完成時間與最遲完成時間相等的事件。 關鍵路徑：關鍵事件聯(lián)結的各個活動所組成的路線。23常用的成本估算方法(1) 基于代碼行的成本估算方法(2) 任務分解成本估算(3) 經(jīng)驗

43、統(tǒng)計估算模型參數(shù)方程 動態(tài)多變量參數(shù)模型 COCOMO 模型( constructive Cost Model )自動估算工具24軟件成本估算包括哪些內容貨幣的時間價值投資回收期純收入投資回收率25項目活動和項目約定計劃指的是什么活動指開發(fā)活動和管理活動； 約定指各種規(guī)范、標準、規(guī)則 規(guī)范是對過程和行為的約束； 標準是對產(chǎn)品的約束；規(guī)則或規(guī)程是對操作的約束。第三章 需求分析26需求獲取為什么難？ 用戶需求具有動態(tài)性 (不穩(wěn)定性 ) 。 用戶需求具有模糊性 (不準確性 ) 。 對需求達成一致的艱難性。 管理體制、機構設置處在變革中。 軟件書籍沒有將需求分析講清楚。27需求分析的重點 業(yè)務模型、功

44、能模型、性能模型、接口模型。28需求分析的 9 項任務 畫出目標系統(tǒng)的組織機構模型。 畫出目標系統(tǒng)業(yè)務操作流程圖。 畫出目標系統(tǒng)的數(shù)據(jù)流圖。 列出目標系統(tǒng)的功能點列表，即功能模型。 列岀系統(tǒng)的性能點列表，即性能模型。 列岀目標系統(tǒng)的接口列表，即接口模型。 確定目標系統(tǒng)的運行環(huán)境，即環(huán)境模型。 目標系統(tǒng)的界面約定，即界面模型。 分析與評估開發(fā)工期、費用、進度、風險等。29. 需求分析的過程Q 問題識別0 分析與綜合O 編制需求分析階段文檔Q 需求分析評審30. 獲取需求的常用方法 訪談：正式的和非正式的訪談 問卷調查：問卷調查即把需要調查的內容制成表格交給用戶填寫。該方法對需要調查大量人員的意

45、見時，十分有效。 情景分析：情景分析就是對目標系統(tǒng)解決某個具體問題的方法和結果，給出可能的情景描述，以獲 知用戶的具體需求。 實地考察 構造原型31 需求分析的原則 解決邏輯問題：需求分析是對問題的識別和說明，要回答“做什么”，而不是“怎么做”。 以運行環(huán)境為基礎：需求分析工作應以具體的運行環(huán)境為基礎，實事求是。 用戶參與的原則：需求分析工作是系統(tǒng)分析人員同用戶不斷交互的過程。 構造高質量的需求規(guī)格說明：需求規(guī)格說明是需求分析工作重要的完成標志。32. 需求分析的基本要求理解問題的數(shù)據(jù)域和功能域自頂向下、逐層分解給出系統(tǒng)的邏輯視圖和物理視圖33. 需求分析方法面向數(shù)據(jù)流的分析方法面向功能的分析

46、方法面向數(shù)據(jù)的Jackson方法面向對象的分析方法第四章軟件設計34.軟件設計的具體任務(1)制定規(guī)范結構設計(3)處理方式結構設計數(shù)據(jù)結構及數(shù)據(jù)庫設計(5)可靠性設計（質量設計）(6)編寫軟件設計文檔(7)設計審查和復審(8)詳細設計35.數(shù)據(jù)的保護性設計防衛(wèi)性設計：在軟件設計中就插入自動檢錯，報錯和糾錯的功能一致性設計：在并發(fā)處理過程中使用封鎖和解除封鎖機制保持數(shù)據(jù)不被破壞冗余性設計：36軟件設計的目標 軟件設計的最終目標是要取得最佳方案。即：節(jié)省開發(fā)費用、降低資源消耗、縮短開發(fā)時間、能夠贏得較高 的生產(chǎn)效率、較高的可靠性和可維護性的方案。 并且使開發(fā)軟件滿足以下特點： 功能、性能都符合指

47、定的要求；軟件是可維護的，可方便地進行修改 ； 除了代碼，還有一套配置齊全的文檔。37模塊的基本屬性“模塊”，又稱 “組件”。一般有四個基本屬性 功能：描述該模塊做什么？ 邏輯：描述模塊內部怎么做？ 狀態(tài)：模塊使用時的環(huán)境和條件。接口：指模塊的輸入與輸出。 38什么是耦合？什么是內聚？如何增強模塊的獨立性？ 耦合：各模塊之間的互相連接的緊密程度。模塊之間的連接越緊密，聯(lián)系越多，耦合性就越高，而 其獨立性就越弱。內聚：模塊內各功能元素彼此結合的緊密程度。一個模塊內部各個元素之間的聯(lián)系越緊密，則它的 內聚性就越高，相對地，它與其它模塊之間的耦合性就會減低，而模塊獨立性就越強。 增強模塊獨立性的方法

48、是：高內聚、低耦合39模塊化的特征抽象：用層次的方式構造和分析復雜系統(tǒng)。 逐步求精：幫助開發(fā)人員把精力集中在與當前開發(fā)階段最相關的那些問題上。 信息隱蔽：如果一個模塊內包含的信息 （ 過程和數(shù)據(jù) ） 不允許外部的模塊訪問的話，其它模塊不能對 其訪問。局部化：把一些關系密切的軟件元素物理地放得彼此靠近。 40影響耦合度的因素 連接方式的類型。 接口的復雜性。 傳送的信息流的類型。 耦合的時間。 41降低耦合度的方法： 對于需要了解的內容，若是隱含的，應改為明顯的，以便更容易理解； 連接的方式盡量標準化，不要直接引用； 減少公共區(qū)，將公共區(qū)劃分為若干個邏輯子區(qū)； 輸入輸出應局限在少量模塊，不要分散

49、在全系統(tǒng)； 延遲耦合時間。 42軟件結構設計優(yōu)化的準則1. 劃分模塊時，盡量做到高內聚、低耦合，保持模塊相對獨立性。模塊劃分的準則： “將相關的各部分放 在一起，無關的東西不要放在一起。 ”2. 模塊的大小要適中。3. 模塊的接口要簡單、清晰、含義明確，便于理解，易于實現(xiàn)、易于測試和維護。4. 一個模塊的作用范圍應在其控制范圍之內，且判定所在的模塊，應與受其影響的模塊在層次上盡量靠 近。5. 軟件結構的深度、寬度、扇入、扇出應適當。6. 力求設計單入口和單出口的模塊，避免“病態(tài)連接” ，以防止內容耦合。7. 設計功能可預測模塊的劃分，應防止功能過分局限。43結構化設計的優(yōu)點 減少設計復雜性。將

50、大化小，使復雜問題簡單化。 結構獨立。將程序劃分成多個相對獨立的模塊。 模塊功能單一化，可使軟件設計獲得最大的益處。 易于進行軟件修改。 易于開發(fā)和維護。 加強了代碼的可重用性。44. Jackson圖的優(yōu)點 便于表示層次結構，是對結構進行自頂向下分解的有力工具； 形象直觀，可讀性好； Jackson圖不僅能表示數(shù)據(jù)結構，也能表示程序結構。45. 正交軟件體系結構的優(yōu)點 層次結構清晰，便于理解。 可移植性強，重用粒度大。 易修改，可維護性強。46. 三層 C/S 結構的組成表示層：用戶接口部分，它擔負著用戶與應用間的對話功能。 功能層：相當于應用的本體，它是將具體的業(yè)務處理邏輯編入程序中。 數(shù)

51、據(jù)層：數(shù)據(jù)庫管理系統(tǒng)，負責管理對數(shù)據(jù)庫數(shù)據(jù)的讀寫。47. 三層 C/S 結構的優(yōu)點 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性。 允許更靈活有效地選用相應的平臺和硬件系統(tǒng)，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性。 三層 C/S 結構中，應用的各層可以并行開發(fā)，各層也可以選擇各自最適合的開發(fā)語言。 允許充分利用功能層有效地隔離開表示層與數(shù)據(jù)層，未授權的用戶難以繞過功能層而利用數(shù)據(jù)庫工 具或黑客手段去非法地訪問數(shù)據(jù)層 。48. B/S 體系結構的不足之處 缺乏對動態(tài)頁面的支持能力，數(shù)據(jù)庫處理功能差。 系統(tǒng)擴展

52、能力差，安全性難以控制。 響應速度遠低于 C/S 體系結構。 數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務處理（OLTP）應用。49. C/S、B/S 混合結構的特點B/S與C/S混合結構是一種典型的異構系統(tǒng)。C/S 與 B/S 混合結構的優(yōu)點：是外部用戶不直接訪問數(shù)據(jù)庫服務器，能保證企業(yè)數(shù)據(jù)庫的相對安全。 企業(yè)內部用戶的交互性較強，數(shù)據(jù)查詢和修改的響應速度較快。C/S 與 B/S 混合結構的缺點：是企業(yè)外部用戶修改和維護數(shù)據(jù)時，速度較慢，較煩瑣，數(shù)據(jù)的動態(tài) 交互性不強。50. 主要的菜單類型固定菜單活動菜單“彈出式 ”菜單“下拉式 ”菜單51. 活動菜單的優(yōu)點不占用顯示工作

53、空間；可以根據(jù)用戶當前所處的操作狀態(tài)和要求動態(tài)出現(xiàn)。需要注意：不能濫用彈出菜單。52 DBMS 的基本功能：管理用戶的數(shù)據(jù)庫； 提供在數(shù)據(jù)庫上的各種操作； 提供數(shù)據(jù)庫對外的各種接口；53. 數(shù)據(jù)庫（DB）與DBMS的不同在人們的交流中，習慣上常常將數(shù)據(jù)庫和 DBMS 混為一談，不加區(qū)別。所以要根據(jù)不同場合、不同習慣、以 及上下文來分析，所講的“數(shù)據(jù)庫”三個字，到底是指數(shù)據(jù)庫，還是指DBMS 。54. DBMS 提供的三種語言DBMS 自帶許多語句（命令） ，可分為三大類： 數(shù)據(jù)定義語言 DDL ：如： CREATE， ALTER ，DROP ； 數(shù)據(jù)操作語言 DML ：如： SELECT ， UPDA TE ， INSERT ，DELETE ； 數(shù)據(jù)控制語言 DCL ： 如：分支語句、循環(huán)語句。55. 數(shù)據(jù)庫的組成（四個表指的是什么）基本表：存放原始數(shù)據(jù)的表。 代碼表：存放信息代碼數(shù)據(jù)的表。 中間表：存放統(tǒng)計數(shù)據(jù)的表。 臨時表：存放臨時數(shù)據(jù)的表。注：原始數(shù)據(jù)和信息代碼數(shù)據(jù)，統(tǒng)稱為基礎數(shù)據(jù)； 基本表和代碼表