第一篇：軟件工程知識點

1．什么是軟件危機，它有哪些典型表現？答：軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。概括地說，軟件危機包含下述兩方面的問題：如何開發軟件，以滿足對軟件日益增長的需求；如何維護數量不斷膨脹的已有軟件。

軟件危機典型表現：對軟件開發成本和進度的估計常常很不準確。用戶對“已完成的”軟件系統不滿意的現象經常發生。軟件產品的質量往往靠不住。軟件常常是不可維護的。軟件通常沒有適當的文檔資料。軟件成本在計算機系統總成本中所占的比例逐年上升。軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢.產生軟件危機的原因：一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。軟件不同于硬件，它是計算機系統中的邏輯部件而不是物理部件。管理和控制軟件開發過程相當困難。軟件是規模龐大，而且程序復雜性將隨著程序規模的增加而呈指數上升。目前相當多的軟件專業人員對軟件開發和維護還有不省糊涂觀念，在實踐過程中或多或少地采用了錯誤的方法和技術，這是使軟件問題發展成軟件危機的主要原因.2.簡述產生軟件危機的原因和解決的思路:答：軟件危機產生的原因一方面與軟件本身的特點有關，另一方面，是與已有軟件開發、維護的方法不正確有密切關系.解決軟件危機，既要有技術措施(方法和工具)，又要有必要的組織管理措施。即采用工程化的原則和方法組織軟件開發是擺脫軟件危機的一個主要出路.3.什么是軟件工程？它有哪些本質特性?答：軟件工程是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它.軟件工程本質特性：

1、軟件工程關注于大型程序的構造；

2、軟件工程的中心課題是控制復雜性；

3、軟件經常變化；

4、開發軟件的效率非常重要；

5、和諧地合作是開發軟件的關鍵；

6、軟件必須有效地支持它的用戶；

7、在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品.4.軟件工程是如何用來消除軟件危機的？軟件工程是從技術和管理兩個方面來研究如何更好地開發和維護計算機軟件，從源頭上消除軟件危機.5.軟件工程的目的是什么？為高質量的軟件開發提供一個科學的體系框架.6.什么是軟件工程方法學？軟件工程是一種什么樣的技術？包括哪三大要素？分為哪三個分支？軟件工程方法學就是指在軟件生命周期全過程中使用的一整套管理和開發技術方法的集合。目前，使用最廣泛的軟件工程方法學分別是傳統方法學和面向對象方法學.軟件工程作為一種層次化的技術，有方法、工具和過程三大要素，并由于其涉及學科內容的極為廣泛，而分為三個分支：軟件開發技術、軟件項目管理技術、軟件質量管理技術.7.什么是軟件生命周期？什么是軟件生命周期模型？軟件如同自然界任何事物一樣，都有其孕育、誕生、成長、成熟、衰亡的生存過程。軟件的這一過程，稱為軟件生命周期.軟件生命周期模型也稱軟件開發過程模型，是為了解決產業環境中的實際問題，而提出的開發策略。是反映整個軟件生命期中，系統開發、運行、維護等實施活動的一種結構框架.8.試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優缺點，說明它們各自的適用范圍.1．瀑布模型:瀑布模型廣為人知和歷史悠久，其優勢是規范及文檔驅動的方法。但問題是，往往不能夠真正滿足用戶的需求..適用于傳統軟件工程領域的結構化開發..2．原型模型:是為了克服瀑布模型的缺點而提出來的。通過快速構建一個在機器上可運行的原型系統，讓用戶試用原型，并收集反饋意見的辦法，來獲取用戶真實的需求..3．螺旋模型:螺旋模型適用于大型軟件項目，比起之前的其它模型而言，有其一定的優越性，但這些優越性并不是絕對的。主要體現在對開發人員的風險評估經驗和專門知識的要求較高。如果項目風險較大，而開發人員的水平較低，不能準確的識別和分析風險，則勢必造成重大損失..4．增量模型:具有在軟件開發早期階段使投資獲得明顯回報和交易維護的優點，但是要求軟件具有開放的結構.9.軟件過程(Software Procedure)是指軟件生存周期所涉及的一系列相關過程.10.軟件測試用例就是指導你對軟件執行操作，幫助你證明軟件功能或發現軟件缺陷的一種說明.11.單元測試——是最小粒度的測試，以測試某個功能或代碼塊.單元測試的對象是軟件設計的最小單位——模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多采用白盒測試技術，系統內多個模塊可以并行地進行測試.12.人機界面設計的三條“黃金規則”:1.置用戶于控制之下.2.減少用戶記憶負擔.3.保持界面一致.13.jackson圖:jackson結構化程序設計使用的圖。什么是HIPO圖：它是表示軟件系統結構的工具。HIPO圖以模塊分解的層次性以及模塊內部輸入、處理、輸出三大基本部分為基礎建立的.它既可以描述軟件總的模塊層次結構--H圖(層次圖)，又可以描述每個模塊輸入/輸出數據、處理功能及模塊調用的詳細情況--IPO圖.14.試說明Jackson方法是一種怎么樣的程序設計方法。它有哪些工作步驟:Jackson方法是以數據結構(data structure)為基礎設計每個模塊的處理過程，將數據結構轉化成程序結構。具體工作步驟有：第1步：用Jackson圖描述 IO 的數據結構;第2步：在兩個圖中指出有直接因果關系、可以同時處理的單元;第3步：將數據結構映射到程序結構;第4步：列出所有操作條件，并分配到上幅程序結構圖中;第5步：用Pseudocode 表示程序.15.簡述結構化設計的特點:1.自頂向下、逐步求精.2.具有單入、單出的控制結構.

第二篇：軟件工程知識點

第一章

軟件工程概述

一、軟件的定義和特性

(P2—P3)定義：軟件=程序+數據+文檔

程序：按照事先設計的功能和性能要求執行的指令或語句序列

數據：程序能正常操縱信息的數據結構

文檔：描述程序操作和使用的文檔 特性：

（1）軟件是一種邏輯實體，具有抽象性，不是一般的物理實體；

（2）軟件的成產與硬件存在某些相同點，但有根本上的不同，軟件開發是人的智力的高度發揮，而不是傳統意義上的制造，它更依賴于開發人員的素質，智力，人員和組合，合作和管理；

（3）軟件維護與硬件維修有著本質的差別，軟件維護沒有硬件維護那樣有可替換的標準零件；（4）軟件在運行和使用期間沒有硬件那樣的機械磨損，老化問題，但存在退化問題；

（5）基于構件的開發方法由于其自身的特點越來越受到人們的重視，這些技術可以減少開發時間、提高質量，并提高復用水平。

* 掌握P4圖1-2（b）軟件失效率曲線

二、計算機軟件的發展經歷了幾個階段？各有何特征？（P1—P2）

共經歷了四個階段

特征：第一階段——程序規模小且主要采用個體工作方式，開發的系統大多采用批處理技術

第二階段——引入人機交互的概念，實時系統出現，產生了第一代數據庫管理系統，程序編制采用了合作的工作方式，出現了早期的軟件危機

第三階段——分布式系統出現，嵌入式系統得到廣泛應用，低成本硬件

第四階段——強大的桌面系統和計算機網絡迅速發展時期，面向對象技術得到廣泛應用，人工智能技術和專家系統開始應用于軟件。

三、什么是軟件危機？其產生的原因是什么？

定義：軟件危機是指由于落后的軟件生產方式無法滿足迅速增長的計算機軟件應用需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。（P4）原因：（P5）

（1）用戶對軟件需求的描述不準確、不全面，甚至有錯誤，以及在開發過程中，不斷提出或者修改需求；（2）用戶和開發人員對軟件需求的理解存在差異，導致所開發的軟件產品和用戶需求不一致；

（3）大型軟件項目需要組織一定的人力共同完成，各類人員的信息交流不及時、不準確，有時還可能產生誤解，軟件開發人員對大型軟件缺少開發經驗，管理人員缺少相應的管理經驗；

（4）軟件開發人員不能有、獨立自主的處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤；

（5）開發技術落后，缺乏有效的方法學和工具方面的支持，過分依賴程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件產品的個性化

（6）軟件產品的特殊性和人類智力的局限性，導致人們無法處理“復雜問題”，因為軟件是邏輯產品，軟件開發進展情況較難衡量、軟件開發質量難以評價、管理和控制軟件開發過程相當困難。

四、什么是軟件工程？它的目標和內容是什么？

定義：將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中，并對方法的研究。（P6）

目標：在給定的成本和進度前提下，開發出具有可修改性、可理解性、可維護性、有效性、可靠性、可適用性、可重用性、可移植性、可跟蹤性和互操作性并且滿足用戶需求的軟件產品。（P7）

內容：主要內容包括軟件開發技術和軟件工程管理兩方面。（P6）

要素：方法，工具，過程

五、什么是軟件生存周期？它有哪幾個活動？

定義：（software life cycle）把軟件產品從形成概念開始，經過定義、開發、使用和維護直到最后退役的全過程。

活動：軟件定義、軟件開發、軟件使用維護和退役（P9）

六、什么是軟件生存周期模型？它有哪些主要模型？

定義：又稱為軟件開發模型，軟件過程模型，它清晰直觀地反映了軟件開發的全部過程、所涉及的活動和任務結構框架，并指出了開發了開發各階段的關系、開發活動的銜接情況。

主要模型：瀑布模型（waterfall model），原型（prototype）模型，螺旋（the spiral）模型，增量（incremental）模型，噴泉（fountain）模型，迭代（iterative）模型

七、簡述有哪些主要的軟件開發方法？（P22）

結構化方法：也稱為生命周期方法或傳統方法，由結構化分析（structured analysis）、結構化設計（SD）、結構化編程（SP）三部分有機組合而成。其基本思想是自頂向下，逐步求精，基本原則是抽象和分解。

面向對象方法（Object—Oriented Method）：把面向對象的思想應用于軟件開發過程中，指導開發活動的系統方法，簡稱OO。包括面相對象分析（OOA）、面向對象設計（OOD）、面向對象的程序設計（OOP）等過程。

八、軟件生命期各階段的任務是什么？（P10）

軟件定義：問題定義，系統的可行性研究，需求分析

軟件開發：概要設計，詳細設計，編碼實踐，軟件測試

軟件使用維護和退役：軟件發布與實施，軟件維護，版本更新或退役

九、簡述瀑布模型（P12）、原型模型特點。

瀑布模型：軟件開發的各項活動嚴格按照線性方式進行，各階段之間具有順序性和依賴性，且為了保證軟件的開發質量進行階段性評審。缺點是逆轉性差，若在評審中發現缺陷或錯誤往回追溯修正時要付出一定的代價。適合在軟件需求明確且很少發生變化、開發技術比較成熟、工程管理比較嚴格地場合使用。

原型模型：有助于用戶和軟件分析員雙方相互學習對方領域知識，使得用戶和開發人員統一對軟件需求的認識，理解，有助于需求的定義評審，從而有助于提高開發速度。缺點是用戶對原型沒有正確認識，會催促開發人員盡早交付軟件，同時也在一定程度上限制了軟件開發人員的創新。（P14）

第二章

軟件需求基礎

一、試述軟件需求、需求分析、需求建模概念的含義及區別。

軟件需求：指用戶對目標軟件系統在功能、性能、行為、涉及約束等方面的期望，這種期望可能是原始的、籠統的，也可能是抽象的太細節化的。（P26）

需求分析：通過對應用問題及其環境的分析與理解，采用一系列的分析方法和技術，將用戶的需求逐步精確化、完全化、一致化，最終形成需求規格說明文檔的過程。（P26）

需求建模：需求建模是為了更好的理解用戶所描述的需求所作出的一種抽象，是用符號語言對事務無歧義的書面描述。模型主要包括數據模型，功能模型和行為模型。（P38）

二、可行性研究的任務是什么？（P31）

用最小的代價在盡可能短的時間內確定該軟件項目是否能夠開發，是否值得去開發。

三、成本—效益分析可用哪些指標進行度量？（P32）

成本效益分析是衡量經濟可行性的。

指標：（1）貨幣的時間價值。（2）投資回收期（3）純收入

四、需求分析階段的基本任務是什么？（P27）

任務：深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求。

五、簡述需求分析階段的過程。（P36）

1．問題識別

2．分析與綜合3．編制需求分析階段的文檔

4．需求驗證

六、常用的初步軟件需求獲取的方法有哪些？為什么要用這些方法來進行需求獲取？（P33）

方法： 1．訪談與會議

2．觀察用戶工作流程

3．建立聯合小組

4．其他獲取方法：快速原型法，基于本體的需求獲取方法

原因：分析人員和用戶的共同知識領域可能不多，致使分析人員對問題往往知之不多，而用戶對目標軟件的要求及對要求的描述常常是零亂而模糊地，從而會造成相互交流和互相理解上的困難。

七、在軟件需求分析時，應首先建立當前系統的物理模型，在根據物理模型盡力當前系統的邏輯模型。試問：什么是當前系統？當前系統的物理模型與邏輯模型有什么差別？（P28）

當前系統：可能是需要改進的某個已在計算機運行的數據處理系統，也可能是一個人工的數據處理過程。

物理模型是確定待開發軟件系統的系統元素，并將功能和數據結構分配到這些系統元素中，它是軟件實現的基礎。邏輯模型忽視實現機制與細節，只描述系統要完成的功能和要處理的數據。

邏輯模型是在物理模型的基礎上去掉一些非本質因素形成的，它反應的是系統的本質。

第三章

軟件設計基礎

一、什么是軟件概要設計？該階段的基本任務是什么？

定義：設計人員依據軟件需求規格說明文檔，確定軟件的體系結構，建立軟件模塊間的關系，定義個功能模塊的接口，設計全局數據庫或數據結構，規定設計約束，指定組裝測試計劃。

任務：將軟件需求轉化為軟件的系統結構和數據結構（P49）

*力爭做到功能模塊之間有比較低的耦合度而功能模塊內部有較高的內聚度。

二、詳細設計的基本任務是什么？有哪幾種描述方法？

任務：通過對軟件結構細化，得到軟件的詳細的算法和數據結構。（P49）

描述方法：（過程設計）程序流程圖

盒圖（N-S圖）

問題分析圖（PAD圖）

判定表和判定樹

過程設計語言（PDL）（P77）

三、軟件設計的基本原理包括哪些內容？（P51）

抽象與逐步求精、模塊化、信息隱蔽、模塊獨立

四、衡量模塊獨立性的兩個標準時什么？各表示什么含義？

標準：內聚和耦合

含義：內聚（cohesion）——衡量一個模塊內部各個元素彼此結合的緊密程度

耦合（coupling）——衡量不同模塊之間的相對獨立性（互相連接的緊密程度）

五、模塊的耦合性有哪幾種？各表示什么含義？

種類：非直接耦合——兩個模塊之間沒有直接關系，他們中任何一個都不依賴于另一個而能獨立工作

數據耦合——一模塊訪問另一模塊，相互傳遞的信息已參數形式給出，并且傳遞的參數完全是簡單數據元素，而不是控制元素、公共數據結構和外部變量。

標記耦合——兩模塊之間都要使用同一數據結構的一部分，不是采用全程公共數據區共享，而是通過模塊接口界面傳遞數據結構的一部分。

控制耦合——一模塊傳遞給另一模塊的參數中包含了控制信息（開關，標記，名字等），該控制信息勇于控制接收模塊中的執行邏輯。

外部耦合——一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳遞該全局變量信息。

公共耦合——一組模塊都訪問同一個公共數據環境

內容耦合——一模塊直接訪問另一模塊的內部數據；一個模塊不通過正常入口轉到另一模塊內部；兩個模塊有一部分程序代碼重迭（只出現在匯編程序中）；一個模塊有多個入口。

*從上到下耦合性從低到高，獨立性從高到底

六、模塊的內聚有哪幾種？各表示什么含義？

種類：巧合內聚（偶然內聚）——將幾個模塊中沒有明確表現出獨立功能的相同程序代碼段獨立出來建立的模塊

邏輯內聚——完成一組在邏輯上相關的任務的模塊間具有邏輯內聚

時間內聚（經典內聚）——完成幾個必須在同一時間內進行的任務的模塊間具有時間內聚

過程內聚——一個模塊完成多個任務，這些任務必須按指定的過程執行。把流程圖中的某一部分劃出組成模塊就得到過程內聚模塊

通信內聚——一個模塊內所有成分都使用同一輸入數據或產生同一輸出數據，即一個模塊內所有處理元素都集中在某個數據結構的一塊區域中的模塊具有通信內聚

信息內聚——一個模塊內完成多個功能，各個功能都在同一數據結構上操作，每一項功能有一個唯一的入口點

七、結構化程序設計的基本要點是什么？

結構化程序設計是盡可能少用GOTO語句的程序設計方法。最好僅在檢測出錯誤時才使用GOTO語句，而且應該總是使用前句GOTO語句。

第四章 結構化分析與設計

一、什么是結構化分析方法？該方法使用什么描述工具？（P85—P86）

定義：結構化分析方法是一種利用自頂向下逐層分解、由粗到細、由復雜到簡單技術的求解方法。

工具：數據流圖（DFD 實體—關系圖（E-R）數據字典（DD）描述基本加工小說明（Process SPECification）

二、什么是數據流圖？其作用是什么？其中的基本符號各表示什么含義？（P87）

定義：數據流圖是描述數據加工處理過程的有效工具。它標識了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。

作用：主要描述系統的功能，即當前系統主要完成哪些功能。

基本符號：箭頭——數據流

圓或橢圓——加工（變換）

雙杠或單杠——數據

矩形框——外部實體

三、什么是數據字典？其作用是什么？共有哪些條目？（P94）

定義：數據字典是對所有與系統相關的數據元素的一個有組織的列表，以及精確地、嚴格地定義了每一個與系統相關的數據元素，并以字典式順序將它們組織起來，使得用戶和分析員對所有的輸入、輸出、存儲成分和中間計算有共同的理解。

作用：對系統所有的數據進行描述和解釋并進行管理。條目：數據項條目、數據流條目、數據庫文件條目（P96）

四、簡述如何畫分層數據流圖，對分層數據流圖的審查由哪些審查要點？（P88 P92）

畫法：首先，把整個系統看成一個加工作為頂層數據流圖（0層）；然后，逐層對大的加工進行分解，分解為更小的自加工；最后，直到所有的加工都成為基本加工（不需要再分解，足夠簡單可以直接解決的加工）為止。

審查：

1、數據流圖和程序流程圖的混淆

2、父圖和子圖的平衡問題

3、局部文件問題

4、分解的深度與層次

五、什么樣是“事物流”？什么事“變換流”？試將相應形式的數據流圖轉換為軟件結構圖。（P104）

事物流——數據沿傳入路徑到系統，由外部形式變換為內部形式后到達事務中心（完成分派任務），事務中心根據數據項計值結果從若干動作路徑中選定一條繼續執行。（事務中心）

變換流——信息以“外部世界”所具有的形式進入系統，經處理后又以這種形式離開系統。包括傳入路徑，變換中心，傳出路徑三部分。（變換中心）步驟：（1）對結構化分析階段產生的DFD圖進行復審；

（2）確定數據流圖的類型

（3）按照SD方法所規定的一組映射規則，把DFD圖轉換為初始SC圖

六、試述“變換分析”、“事務分析”設計步驟。（P106—P108）

變換分析：第一步——劃分DFD圖的邊界，也就是將DFD圖劃分為三個基本的組成部分，不同的設計人員可能產生不同的劃分結果；

第二步——完成第一級分解，建立初始SC圖的框架；

第三步——完成第二級分解，細化SC圖的每個分支，得到初始SC圖。

事務分析：首先確定事務中心，即幾條動作路徑的公共源頭；其次劃定接收路徑和發送路徑；然后分解和細化每個接收分支和發送分支，完成初始的SC圖。

七、簡述有哪些啟發式設計策略可以幫助軟件設計人員改善軟件質量，優化軟件結構。（P108—P110）

（1）模塊的高獨立性和規模適中

（2）保持高扇入和低扇出

（3）模塊的作用域應在控制域之內

（4）降低模塊接口的復雜度

第五章

面向對象的分析與設計

一、說明對象、類、類結構、消息的基本概念（P113）

對象：是封裝了數據結構及可以施加在這些數據結構上的操作的封裝體。

類：對具有相同屬性和操作的一組對象的抽象性描述，它描述了屬于該對象類型的所有對象的性質，包括外部特性和內部實現兩個方面。類結構：（實例）

消息：是用來請求對象執行某一處理或回答某一要求的信息。

二、試述面向對象方法學的優點。（P112）

1、開發的軟件比較容易理解

2、穩定性好

3、可重用性好

4、較易開發大型軟件產品

5、可維護性好

三、什么是UML？為什么使用UML？（P118）

定義：UML（Unified Modeling Language）是一個通用的、可視化標準建模語言。

使用原因：統一的標準

面向對象

可視化、表示能力強

獨立于過程

易掌握、易用

四、在UML中用例圖的作用是什么？其包括哪些符號？簡述各符號的含義。（P122）

作用：捕獲系統中用戶的需求

符號：人形（stickman）——活動者

橢圓——用例

實線——關系

五、簡述用例建模的步驟。

步驟：識別參與者——識別用例——識別關系——建模——用例規約

六、什么是用例規約？其包括哪些基本內容？什么是基本流和備選流？

定義：用例的補充說明，包括簡要說明，事件流，用例場景，特殊需求，前置條件，后置條件 基本流： 備選流：

七、在UML中的狀態圖，活動圖，時序圖在系統分析中各起到了什么作用？

狀態圖——描述對象在生命周期內處于哪些狀態，每一種狀態的行為以及什么樣的事件引起對象狀態發生改變，展示了系統的動態視圖。P144 活動圖——描述動作及對象狀態改變的結果，描述采取何種動作似的對象的狀態改變，動作的序列是什么及在何處發生。P148 時序圖——詳細表示對象之間以及對象與系統外部的參與者之間動態聯系的圖形文檔，它詳細而直觀地表現了一組相互協作的對象在執行一個（或少量幾個）用例時的行為依賴關系，以及操作和消息的時序關系。P139

八、簡述類圖中關聯和依賴關系的區別。

關聯表示兩個類的對象之間存在某種語義上的聯系。（組合/聚合關聯）如：學生選課，學生與課程間

依賴是類與類之間最弱的關系，它是兩個模型元素（類、用例等）之間的語義連接關系，其中一個模型元素是獨立，另一模型元素依賴于獨立的模型元素，如果獨立的模型元素改變了，將影響依賴于它的模型元素。如教師與粉筆。

九、類圖中類與類之間的關系有哪幾種？

類與類之間的靜態關系：關聯，泛化，依賴，細化

第六章

人機界面設計

一、簡述人機界面的設計過程。（P168）

1、確定任務的目標和含義；

2、將每個目標或含義映射為一系列特定的動作；

3、說明這些動作將來在界面上執行的順序；

4、指明系統狀態，及上述各動作序列中每個動作在界面上執行時界面呈現的形式；

5、定義控制機制，即用戶可用的改變系統狀態的設備和動作；

6、說明控制機制怎樣作用于系統狀態；

7、指明用戶如何根據界面上反映出的信息，解釋系統的狀態。

二、簡述人機界面設計過程中應考慮哪些一般問題？（P168）

系統響應時間

用戶幫助設施

出錯信息處理

命令交互

三、如何理解界面設計中“人的因素”（P162）

人對感知過程的認識

用戶的技能和用戶間的差異

第八章

軟件測試

一、什么是白盒測試法？有哪些覆蓋標準？P205

定義：（結構測試或邏輯驅動測試）測試時，把程序看做一個打開的盒子，它是知道產品內部工作過程，而不顧他的功能。

覆蓋標準：語句覆蓋

判定覆蓋

條件覆蓋

判定/條件覆蓋

條件組合覆蓋

路徑覆蓋

二、什么是黑盒測試法？采用黑盒技術測試用例有哪幾種方法？（P199）

定義：（功能測試或數據驅動測試）它是在已知產品所應具有功能的基礎上，通過測試來檢測每個功能是否都能正常使用。

方法：等價類劃分

邊界值分析

錯誤推測

因果圖

比較測試

三、軟件測試要經過哪些步驟？這些測試與軟件開發各階段之間有什么關系？

步驟：單元測試——集成測試——確認測試——系統測試

關系：單元測試（模塊測試）——是最小單位的測試，其依據是詳細設計說明書。測試者（程序員）根據詳細設計說明書和源程序清單了解模塊的I/O條件和模塊的邏輯結構。

集成測試（組裝測試、聯合測試、子系統測試、部件測試）——是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成為子系統或系統進行測試。

確認測試（有效性測試）——檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準（用戶參與）。

系統測試——針對整個產品系統進行的測試，驗證系統是否滿足了需求規格的定義，找出與需求規格不相復合或與之矛盾的地方。

四、單元測試有哪些內容？

模塊接口

局部數據結構測試

路徑測試

錯誤處理測試

邊界測試

五、什么是集成測試？非漸增式測試與漸增式測試有什么區別？漸增式測試如何組裝模塊？

定義：集成測試（組裝測試、聯合測試、子系統測試、部件測試）是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成為子系統或系統進行測試。

區別：P216自己看

組裝：

六、什么是回歸測試？（P218）

發生修改之后重新測試先前的測試以保證修改的正確性。目的在于檢驗以前出現過的但已修復好的缺陷不再出現。

七、什么是測試用例？（P194）

測試用例由測試輸入數據和預期輸出結果組成。

八、軟件測試和軟件調試有何區別？

第九章

軟件維護

一、軟件維護有哪些內容？（P229）

改正性維護

適應性維護

完善性維護

預防性維護

二、何為非結構化維護和結構化維護？（P231）

結構化維護——采用軟件工程的方法進行軟件的開發，則每一個階段都有相應的文檔，且文檔與程序代碼互相匹配，因此維護容易進行。

非結構化維護——沒有采用軟件工程的方法進行軟件的開發，開發出的軟件只有程序沒有文檔，或者僅有一些片段的說明性文檔。給維護工作帶來很大的困難，耗時耗力且代價高。

三、軟件維護的流程是什么？（P233）

提交維護申請報告——生成軟件修改報告——軟件修改——主要流程

四、軟件維護的副作用有哪些？（P240）

修改編碼的副作用 修改數據結構的副作用 修改文檔的副作用

第三篇：軟件工程知識點總結

7.1軟件的定義及特點

軟件（Software）是計算機系統中與硬件相互依存的另一部分，它是包括程序（Program），數據（Data）及其相關文檔（Document）的完整集合。

三個特點：

（1）軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性；（2）軟件的生產與硬件不同，在它的開發過程中沒有明顯的制造過程；（3）在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。

7.2軟件危機及其表現

軟件危機（softward crisis）是指在計算機軟件的開發和維護中所遇到的一系列嚴重問題。這些問題絕不僅僅是“不能正常運行的”軟件才具有，實際上幾乎所有軟件都不同程度地存在這些問題。

具體地說，軟件危機主要有下述一些表現。

（1）對軟件開發成本和進度的估計常常很不準確。

（2）用戶對“已完成的”軟件系統不滿意的現象經常發生。

（3）軟件產品的質量往往靠不住。

（4）軟件常常是不可維護的。

（5）軟件通常沒有適當的文檔資料。

（6）軟件成本在計算機系統總成本中所占的比例逐年上升。

7.3軟件工程及三要素

軟件工程：軟件工程是采用工程的概念、原理、技術和方法來指導軟件開發和維護的工程學科，以工程化的原理和方法來解決軟件問題。

軟件工程的特性：

（1）軟件工程關注于大型程序的構造（2）軟件工程的中心課題是控制復雜性（3）軟件經常變化

（4）開發軟件的效率非常重要（5）和諧地合作是開發軟件的關鍵（6）軟件必須有效地支持它的用戶

（7）在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人

軟件工程方法學包含3個要素：方法、工具和過程。

7.4軟件生命周期

軟件生命周期又稱為軟件生存周期或系統開發生命周期，是軟件的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、系統設計、編碼、調試和 測試、驗收與運行、維護升級到廢棄等階段，這種按時間分程的思想方法是軟件工程中的一種思想原則，即按部就班、逐步推進，每個階段都要有定義、工作、審 查、形成文檔以供交流或備查，以提高軟件的質量。

每個階段的任務如下

問題定義階段：該階段的關鍵任務是要明確：要解決的問題是什么？ 可性行研究階段：該階段的關鍵任務是要明確：做不做？ 需求分析階段：該階段的關鍵任務是要明確：做什么？

概要設計(總體設計)階段：該階段的關鍵任務是要明確：怎么做？ 詳細設計階段：該階段的關鍵任務是要明確：具體做法。

編碼和單元測試階段：該階段的關鍵任務是：編碼和單元測試。

綜合測試階段：該階段的關鍵任務是通過各種類型的測試（及調試）使軟件達到預定的要求。軟件維護階段：該階段的關鍵任務是通過各種必要的維護活動使系統持久地滿足用戶的要求。

7.4.1瀑布模型

瀑布模型有以下優點

1）為項目提供了按階段劃分的檢查點。

2）當前一階段完成后，您只需要去關注后續階段。3）可在迭代模型中應用瀑布模型。

4）它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。

瀑布模型適合于用戶需求明確、完整、無重大變化的軟件項目開發。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型。

瀑布模型有以下缺點

1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量。

2）由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。

3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。4）瀑布模型的突出缺點是不適應用戶需求的變化。

“瀑布模型是由文檔驅動的”這個事實也是它的一個主要缺點。實際項目很少按照該模型給出的順序進行，用戶常常難以清楚地給出所有需求，用戶必須有耐心，等到系統開發完成。

7.4.2 原型模型—快速原型模型

在用戶不能給出完整、準確的需求說明，或者開發者不能確定算法的有效性、操作系統的適應性或人機交互的形式等許多情況下，可以根據用戶的一組基本需求，快速建造一個原型（可運行的軟件），然后進行評估，進一步精化、調整原型，使其滿足用戶的要求，也使開發者對將要做的事情有更好的理解。優點：

（1）開發人員和用戶在“原型”上達成一致。這樣一來，可以減少設計中的錯誤和開發中的風險，也減少了對用戶培訓的時間，而提高了系統的實用、正確性以及用戶的滿意程度。（2）縮短了開發周期，加快了工程進度。（3）降低成本。

盡早發現需求，揭示風險 缺點：

⑴為了使原型盡快的工作，沒有考慮軟件的總體質量和長期的可維護性。

⑵為了演示，可能采用不合適的操作系統、編程語言、效率低的算法，這些不理想的選擇成了系統的組成部分。

⑶開發過程不便于管理。

7.4.3螺旋模型

螺旋模型的優點：（1）對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標

（2）減少了過多測試或測試不足（3）維護和開發之間并沒有本質區別 螺旋模型的缺點：

（1）風險驅動，需要相當豐富的風險評估經驗和專門知識，否則風險更大

（2）主要適用于內部開發的大規模軟件項目，隨著過程的進展演化，開發者和用戶能夠更好的識別和對待每一個演化級別上的風險

（3）隨著迭代次數的增加，工作量加大，軟件開發成本增加

7.4.4增量模型

增量模型優點：

（1）在較短時間內向用戶提交可完成部分工作的產品，并分批、逐步地向用戶提交產品。從第一個構件交付之日起，用戶就能做一些有用的工作。

（2）整個軟件產品被分解成許多個增量構件，開發人員可以一個構件一個構件地逐步開發。（3）逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。（4）采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計，但在設計階段多付出的勞動將在維護階段獲得回報。增量模型的缺點：

（1）在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。此外，必須把軟件的體系結構設計得便于按這種方式進行擴充，向現有產品中加入新構件的過程必須簡單、方便，也就是說，軟件體系結構必須是開放的。

（2）開發人員既要把軟件系統看作整體。又要看成可獨立的構件，相互矛盾。（3）多個構件并行開發，具有無法集成的風險。

7.4.5噴泉模型

主要用于支持面向對象開發過程體現了軟件創建所固有的迭代和無間隙的特征。噴泉模型的優點

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。

噴泉模型的缺點

由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

其特點如下：

（1）開發過程有分析、系統設計、軟件設計和實現4個階段。（2）各階段相互重疊，它反映了軟件過程并行性的特點。（3）以分析為基礎，資源消耗成塔型。

（4）反映了軟件過程迭代性的自然特性，從高層返回低層無資源消耗。（5）強調增量開發，整個過程是一個迭代的逐步提煉的過程。

7.4.6構件組裝模型

構件組裝模型導致軟件復用，而可復用性給軟件工程師提供了大量的可見的益處。軟件開發不

用一切從零開始，開發過程就是一個組裝構件的過程，維護的過程就是對構件升級、替換和擴充的過程，大大提高了軟件的開發效率。構件模型允許多個項目同時開發，降低了費用，提高了可維護性。

構件模型也存在一些缺點，如：由于存在多種構件標準，缺乏通用的構件組裝結構標準，如果自行定義會引入較大的風險；構件可重用性和軟件系統高效性之間不易協調；如果過分依賴構件，構件質量會影響最終的產品質量。

7.4.7 RUP RUP是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟件過程模型，也稱RUP（Rational Unified Process)。RUP重復一系列周期，每個周期由一個交付給用戶的產品結束。

每個周期劃分為初始、細化、構造和移交四個階段，每個階段圍繞著五個核心工作流（需求、分析、設計、實現、測試）分別迭代。模型見下圖：

1.4個階段

初始階段：進行問題定義，確定目標，評估其可行性，降低關鍵風險。細化階段：制定項目計劃、配置各類資源、建立系統架構（包括各類視圖）。構造階段：開發整個產品，并確保產品可移交給用戶。移交階段：產品發布、安裝、用戶培訓。

在每個階段的每次迭代的最后，用例模型、分析模型、設計模型、實現模型都會增量，每個階段結束的里程碑處，管理層做出是否繼續、進度、預算、是否給下一階段提供資助等決定。

不同階段工作流的側重點不同，前兩階段大部分工作集中在需求、分析和架構設計上；在構造階段，重點轉移到詳細設計、實現和測試上。

2.9個工作流

RUP中有9個核心工作流，分為6個核心過程工作流（Core Process Workflows）和3個核心支持工作流（Core Supporting Workflows）。

商業建模：深入了解使用目標系統的機構及其商業運作，評估目標系統對使用它的機構的影響。需求：捕獲客戶的需求，并且使開發人員和用戶達成對需求描述的共識。分析和設計：把需求分析的結果轉化成分析模型與設計模型。實現：把設計模型轉換成實現成果。

測試：檢查個子系統的交互與集成，驗證所有需求是否都被正確地實現了，識別，確認缺陷并確保在軟件部署之前消除缺陷。

部署：成功地生成目標系統的可運行版本，并把軟件移交給最終用戶。

配置和變更管理：跟蹤并維護在軟件開發過程中產生的所有制品的完整性和一致性。

軟件項目管理：提供項目管理框架，為軟件開發項目制定計劃，人員配備，執行和監控等方面的實用準則，并為風險管理提供框架。

環境：向軟件開發機構提供軟件開發環境，包括過程管理和工具支持。

7.5 UML UML適用于各種軟件開發方法、軟件生命周期的各個階段、各種應用領域以及各種開發工具。UML由以下5類圖來定義： 第1類：用例圖

第2類：靜態圖（包括類圖、對象圖和包圖）第3類：行為圖（包括狀態圖和活動圖）第4類：交互圖（包括時序圖和協作圖）第5類：實現圖（包括組件圖和配置圖）

第一類是用例圖：從用戶角度描述系統功能，并指出各功能的操作者。

第二類是靜態圖：包括類圖，對象圖，包圖。類圖描述系統中類的靜態結構，不僅定義系統中的類，表示類之間的聯系如關聯、依賴、聚合等也包括類的內部結構（類的屬性和動作）。

第三類是行為圖：描述系統的動態模型和組成對象之間的交互關系，其中狀態圖描述類的對象所有可能的狀態，以及事件發生時的狀態的轉移條件，通常，狀態圖為類圖的補充，在實用上并不需要為所有的類畫狀態圖，僅為那些有多個狀態其行為受外界環境的影響并且狀態發生改變的類畫狀態圖，活動圖描述滿足用例要求所要進行的活動以及活動的約束關系，有利于識別并行的活動。

第四類是交互圖：描述對象間的交互關系。其中順序圖顯示對象之間的動態合作關系，他強調對象之間消息發送的順序。

第五類是實現圖：其中構建圖描述代碼部件的物理結構和各部件之間的依賴關系，一個部件可能是一個資源代碼部件，一個二進制部件或者一個可執行部件。它包含邏輯類和實際類的有關信息。部件圖有利于分析和理解部件間的相互影響程度。

下面分別描述9個圖。

7.5.1 類圖

類圖展示了一組類、接口和協作及它們間的關系，在建模中所建立的最常見的圖就是類圖。用類圖說明系統的靜態設計視圖，包含主動類的類圖——專注于系統的靜態進程視圖。系統可有多個類圖，單個類圖僅表達了系統的一個方面。要在高層給出類的主要職責，在低層給出類的屬性和操作。

7.5.2對象圖

對象圖展示了一組對象及它們間的關系。用對象圖說明類圖中所反應的事物實例的數據結構和靜態快照。對象圖表達了系統的靜態設計視圖或靜態過程視圖，除了現實和原型的方面的因素外，它與類圖作用是相同的。

7.5.3用例圖

用例圖展現了一組用例、參與者以及它們間的關系。可以用用例圖描述系統的靜態使用情況。在對系統行為組織和建模方面，用例圖的是相當重要的。

用例(use case)：從用戶的觀點對系統行為的一個描述。用來從用戶的觀察角度收集系統需求。

用例圖表達系統的外部事物（參與者）與系統的交互，它表達了系統的功能，即系統所提供的服務。

整個軟件項目的開發可以采用Use Case 驅動的方式進行。

7.5.4交互圖

交互圖展現了按一定的目的進行的一種交互，它由在一個上下文中的一組對象及它們間交互的信息組成。交互圖也可用于描述一個用例的行為。順序圖和協作圖都是交互圖，順序圖和協作圖可以相互轉換。

順序圖和協作圖都是交互圖，它們既是等價的，又是有區別的。

順序圖和協作圖都能等價的表現系統運行中對象通過消息發生的交互行為。

順序圖表示了時間的消息序列，便于分析交互的時序，但沒有表示靜態對象關系，順序圖可以有效地幫助人們觀察系統的順序行為。

協作圖著重表示一個協作中的對象之間的聯系和消息。

7.5.5順序圖

展現了一組對象和由這組對象收發的消息，用于按時間順序對控制流建模。用順序圖說明系統的動態視圖。

7.5.6協作圖

展現了一組對象，這組對象間的連接以及這組對象收發的消息。它強調收發消息的對象的結構組織，按組織結構對控制流建模。

協作圖顯示某組對象為了由一個用例描述的一個系統事件而與另一組對象進行協

作的交互圖。

協作圖只對相互間有交互作用的對象和這些對象間的關系建模，而忽略了其他對象

和關聯。

協作圖中包括如下元素：1.對象（Object）、2.鏈（Link）和3.消息（Message）。

協作圖的用途：

如果按組織對控制流建模，應該選擇使用協作圖。協作圖強調交互中實例間的結構關系以及所傳送的消息。協作圖對復雜的迭代和分支的可視化以及對多并發控制流的可視化要比時序圖好。

協作圖有別于時序圖的兩點特性：（1）協作圖有路徑（2）協作圖有順序號

7.5.7狀態圖

展示了一個特定對象的所有可能狀態以及由于各種事件的發生而引起的狀態間的轉移。一個狀態圖描述了一個狀態機，用狀態圖說明系統的動態視圖。它對于接口、類或協作的行為建模尤為重要，可用它描述用例實例的生命周期。在任一給定的時刻，一個對象總是處于某一特定的狀態。

狀態圖主要表現一個對象所經歷的狀態序列，引起狀態或活動轉移的事件，以及因狀態或活動轉移而伴隨的動作。

7.5.8活動圖

活動圖是一種特殊的狀態圖，描述需要做的活動、執行這些活動的順序（多為并行的）以及工作流（完成工作所需要的步驟）。它對于系統的功能建模特別重要，強調對象間的控制流程。

活動圖實質上是一種流程圖，只不過表現的是從一個活動到另一個活動的控制流。活動圖描述活動的序列，并且支持對帶條件的行為和并發行為表達。

7.5.9時序圖

在一個運行的系統中，對象之間要發生交互，并且這些交互要經歷一定的時間。

順序圖表達的正是這種基于時間的動態交互。重點是完成某個行為的對象類和這些對象類之間所傳遞的消息的時間順序。

7.5.10構件圖

構件圖展現了一組構件之間的組織和依賴，用于對原代碼、可執行的發布、物理數據庫和可調整的系統建模。

組件圖代表系統的一個物理實現塊，代表邏輯模型元素如類、接口的物理打包。

7.5.11部署圖

部署圖展現了對運行時處理節點以及其中構件的配署。它描述系統硬件的物理拓撲結構(包括網絡布局和構件在網絡上的位置)，以及在此結構上執行的軟件（即運行時軟構件在節點中的分布情況）。用部署圖說明系統結構的靜態部署視圖，即說明分布、交付和安裝的物理系統

7.5.12區別

1.以描述系統狀態轉移為主的狀態圖和活動圖

狀態圖：用來描述對象，子系統，系統的生命周期。通過狀態圖可以了解一個對象所能達到的所有狀態，以及對象收到的事件對對象狀態的影響。

活動圖：顯示動作及其結果。著重描述操作（方法）實現中所完成的工作以及用例實例或對象中的活動，它是狀態圖的一個變種。

狀態圖與活動圖的區別：活動圖主要描述動作及對象狀態改變的結果。狀態圖主要描述的是事件對對象狀態的影響。

2.以描述系統系統對象通訊和交互為主的協作圖和序列圖

序列圖：描述對象是如何交互的。重點放在消息序列上，描述消息在對象間是如何收發的。

協作圖：描述協作對象的交互與鏈接。

協作圖和序列圖的區別：協作圖和序列圖都是描述對象交互的，但是序列圖強調的是時間，協作圖強調的空間。

7.6需求分析與用例建模

7.6.1需求分析的任務

需求分析的基本任務不是確定系統怎樣完成它的工作，而是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。----準確地回答“系統必須做什么?”。

需求分析的步驟： 需求獲取 分析建模 文檔編寫 需求驗證

7.6.2類圖

類(Class)、對象(Object)和它們之間的關系是面向對象技術中最基本的元素。類圖技術是OO方法的核心。

類圖標加上它們之間的關系就構成了類圖。

類圖用于對系統靜態設計視圖建模。與數據模型不同，它不僅顯示了信息的結構，同時還描述了系統的行為。

類圖中可以包含接口，包，關系等建模元素，也可以包含對象，鏈等實例。

類圖典型的應用在下面三類建模：（1）對系統的詞匯建模（2）對簡單協作建模

（3）對邏輯數據庫模式建模

類圖通常包含下述內容：類、接口、協作、依賴、泛化和關聯關系。

關系（Relationship）是事物間的關系。在類的關系中，最常用的4種分別為： 依賴（Dependency）：它表示類之間的使用關系 泛化（Generalization）：它表示類之間的一般和特殊的關系； 關聯（Association）：它表示對象之間的結構關系 實現（Realization）：它是規格說明和其實現之間的關系。

類主要包含以下幾個部分

（1）名稱（Name）名稱是每個類所必有的構成，用于和其他類相區分。（2）屬性（Attribute）類的一個組成部分描述了類所代表事物的屬性（3）操作（Operation）操作是對類的對象所能做的事務的抽象

類在UML中由專門的圖符表達，是分成3個分隔區的矩形,頂端為類的名字，中間存放類的屬性、屬性的類型和值，第3個分隔區放操作、操作的參數表和返回類型，如下圖：

7.6.3用例圖

在UML中，一個用例模型由若干個用例圖(use case diagram)描述。用例圖是顯示一組用例、參與者以及它們之間關系的圖。

用例圖是從用戶的角度來描述對軟件產品的需求，分析產品的功能和行為，因此，對整個軟件開發過程而言，用例圖是至關重要的。

用例圖定義和描述了系統的外部可見行為，是分析、設計直至組裝測試的重要依據。讓用戶參與前期的系統分析與設計。

用例圖的組成： 用例（Use Case）參與者（Actor）關系(Relationship)

1.什么是參與者

參與者：在系統之外，透過系統邊界與系統進行有意義交互的任何事物。參與者可能是人、另外一個系統、時間的流逝等。

UML中，參與者用“人形”圖標來表示，名字寫在圖標的下方。

參與者

2.什么是用例

用例（use case）一個用例是用戶與計算機之間的一次典型交互作用。在UML中,用例被定義成系統執行的一系列動作（功能）。

參與者和用例分別描述了“誰來做？”和“做什么？”這兩個問題。每個用例都必須有一個惟一的名字以區別于其他用例。用例用一個橢圓來表示，用例的名字可以書寫在橢圓的內部或下方。用例的UML圖標如圖所示。3.用例間、用例與參與者的關系

（1）泛化關系（Generalization）：一個用例可以被特別列舉為一個或多個子用例，這被稱為用例泛化：

（2）包含關系（Include）一個用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分，這被稱作包含關系。

（3）擴展關系（Extend）：一個用例也可以被定義為基礎用例的增量擴展，這稱作擴展關系，擴展關系是把新行為插入到已有用例的方法。

（4）關聯關系：關聯關系表示參與者與用例之間的通信。

4.用例間的關系

（1）泛化關系

當多個用例共同擁有一種類似的結構和行為的時候我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。

用例可以被特別列舉為一個或多個子用例，這被稱做用例泛化。（2）包含關系

包含是指基本用例(base use case)會用到包含用例(inclusion)，具體地講，就是將包含用例的事件流插入到基礎用例的事件流中。包含用例是可重用的用例──多個用例的公共用例。

（3）擴展關系

將擴展用例的事件流在一定的條件下按照相應的擴展點插入到基礎用例中。基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。擴展用例的行為是否被執行要取決于主事件流中的判定點。

擴展關系是從擴展用例到基本用例的關系，它說明為擴展用例定義的行為如何插入到為基本用例定義的行為中。它是以隱含形式插入的，也就是說，擴展用例并不在基本用例中顯示。在以下幾種情況下，可使用擴展用例：

a.表明用例的某一部分是可選的系統行為（這樣，您就可以將模型中的可選行為和必選行為分開）；

b.表明只在特定條件（如例外條件）下才執行的分支流；

5.用例之間的關系

包含用例與擴展用例的區別

①相對于基礎用例，擴展用例是可選的，而包含用例則不是。

②如果缺少擴展用例，基礎用例還是完整的，而缺少包含用例，則基礎用例就不完整了。③擴展用例的執行需要滿足某種條件，而包含用例不需要。④擴展用例的執行會改變基礎用例的行為，而包含用例不會。

6.識別用例的方法：

①參與者希望系統提供什么功能；

②系統是否存儲和檢索信息；如果是，這個行為由哪個參與者觸發； ③當系統改變狀態時，是否通知參與者；

④是否存在影響系統的外部事件，是哪個參與者通知系統這些外部事件。

7.6.4活動圖

1.什么是活動圖

活動圖是UML中描述系統動態行為的圖之一，是描述系統或業務的一序列活動構成的控制流，它描述了系統從一種活動轉換到另一種活動的整個過程。

2.活動圖用途

活動圖用于對系統的動態行為建模。

活動圖常用來描述業務或軟件系統的活動軌跡，描述了系統的活動控制流程。我們常用活動圖對業務過程、工作流和用例實現進行建模。

活動圖主要應用對兩個方面建模：一是在業務分析階段，對工作流程進行建模；二是在系統分析和設計階段，對操作流程進行建模。

7.6.5面向對象分析建立的3類模型

對象模型、動態模型、功能模型

對象模型

對象模型表示了靜態的、結構化的系統數據性質，描述了系統的靜態結構，它是從客觀世界實體的對象關系角度來描述，表現了對象的相互關系。該模型主要關心系統中對象的結構、屬性和操作，它是分析階段三個模型的核心，是其他兩個模型的框架。[2]

⒈對象和類 ⑴對象。

對象建模的目的就是描述對象。⑵ 類。

通過將對象抽象成類，我們可以使問題抽象化，抽象增強了模型的歸納能力。⑶ 屬性。

屬性指的是類中對象所具有的性質（數據值）。⑷ 操作和方法。

操作是類中對象所使用的一種功能或變換。類中的各對象可以共享操作，每個操作都有一個目標對象作為其隱含參數。

方法是類的操作的實現步驟。⒉關聯和鏈

關聯是建立類之間關系的一種手段，而鏈則是建立對象之間關系的一種手段。⑴ 關聯和鏈的含義。

鏈表示對象間的物理與概念聯結，關聯表示類之間的一種關系，鏈是關聯的實例，關聯是鏈的抽象。

⑵ 角色。

角色說明類在關聯中的作用，它位于關聯的端點。⑶ 受限關聯。

受限關聯由兩個類及一個限定詞組成，限定詞是一種特定的屬性，用來有效的減少關聯的重數，限定詞在關聯的終端對象集中說明。

限定提高了語義的精確性，增強了查詢能力，在現實世界中，常常出現限定詞。⑷ 關聯的多重性。

關聯的多重性是指類中有多少個對象與關聯的類的一個對象相關。重數常描述為“一”或“多”。⒊類的層次結構 ⑴ 聚集關系。

聚集是一種“整體－部分”關系。在這種關系中，有整體類和部分類之分。聚集最重要的性質是傳遞性，也具有逆對稱性。

聚集可以有不同層次，可以把不同分類聚集起來得到一顆簡單的聚集樹，聚集樹是一種簡單表示，比畫很多線來將部分類聯系起來簡單得多，對象模型應該容易地反映各級層次。

⑵一般化關系。

一般化關系是在保留對象差異的同時共享對象相似性的一種高度抽象方式。它是“一般---具體”的關系。一般化類稱為你類，具體類又能稱為子類，各子類繼承了父類的性質，而各子類的一些共同性質和操作又歸納到你類中。因此，一般化關系和繼承是同時存在的。一般化關系的符號表示是在類關聯的連線上加一個小三角形。

⒋對象模型

⑴模板。模板是類、關聯、一般化結構的邏輯組成。⑵對象模型。

對象模型是由一個或若干個模板組成。模板將模型分為若干個便于管理的子塊，在整個對象模型和類及關聯的構造塊之間，模板提供了一種集成的中間單元，模板中的類名及關聯名是唯一的

動態模型

動態模型是與時間和變化有關的系統性質。該模型描述了系統的控制結構，它表示了瞬間的、行為化的系統控制

性質，它關心的是系統的控制，操作的執行順序，它表示從對象的事件和狀態的角度出發，表現了對象的相互行為。

該模型描述的系統屬性是觸發事件、事件序列、狀態、事件與狀態的組織。使用狀態圖作為描述工具。它涉及到事件、狀態、操作等重要概念。

⒈事件

事件是指定時刻發生的某件事。

⒉狀態

狀態是對象屬性值的抽象。對象的屬性值按照影響對象顯著行為的性質將其歸并到一個狀態中去。狀態指明了對象對輸入事件的響應。

⒊狀態圖

狀態圖是一個標準的計算機概念，他是有限自動機的圖形表示，這里把狀態圖作為建立動態模型的圖形工具。

狀態圖反映了狀態與事件的關系。當接收一事件時，下一狀態就取決于當前狀態和所接收的該事件，由該事件引起的狀態變化稱為轉換。

狀態圖是一種圖，用結點表示狀態，結點用圓圈表示；圓圈內有狀態名，用箭頭連線表示狀態的轉換，上面標記事件名，箭頭方向表示轉換的方向。

功能模型

功能模型描述了系統的所有計算。功能模型指出發生了什么，動態模型確定什么時候發生，而對象模型確定發生的客體。功能模型表明一個計算如何從輸入值得到輸出值，它不考慮計算的次序。功能模型由多張數據流圖組成。數據流圖用來表示從源對象到目標對象的數據值的流向，它不包含控制信息，控制信息在動態模型中表示，同時數據流圖也不表示對象中值的組織，值的組織在對象模型中表示。

數據流圖中包含有處理、數據流、動作對象和數據存儲對象。⒈處理

數據流圖中的處理用來改變數據值。最低層處理是純粹的函數，一張完整的數據流圖是一個高層處理。

⒉數據流

數據流圖中的數據流將對象的輸出與處理、處理與對象的輸入、處理與處理聯系起來。在一個計算機中，用數據流來表示一中間數據值，數據流不能改變數據值。

⒊動作對象

動作對象是一種主動對象，它通過生成或者使用數據值來驅動數據流圖。

⒋數據存儲對象

數據流圖中的數據存儲是被動對象，它用來存儲數據。它與動作對象不一樣，數據存儲本身不產生任何操作，它只響應存儲和訪問的要求。

7.7設計階段

7.7.1詳細設計

詳細設計階段的根本目標是確定怎樣具體地實現所要求的系統，也就是說，經過這個階段的設計工作，應該得出對目標系統的精確描述，從而在編碼階段可以把這個描述直接翻譯成用某種程序設計語言書寫的程序。

詳細設計的目標: 設計出的處理過程應該盡可能簡明易懂。詳細設計的任務：

(1)為每個模塊確定采用的算法，選擇某種適當的工具表達算法的過程，寫出模塊的詳細過程性描述；

(2)確定每一模塊使用的數據結構；為以后的編寫程序做好充分的準備。(3)確定模塊接口的細節。

7.7.2總體設計

1.面向對象設計

面向對象設計的準則：優秀設計就是使得系統在其整個生命周期中的總開銷最小的設計, 其主要特點就是容易維護。

面向對象設計（OOD，Object-Oriented Design）是面向對象分析到實現的一個橋梁。面向對象分析是將用戶需求經過分析后，建立問題域精確模型的過程；而面向對象設計則根據面向對象分析得到的需求模型，建立求解域模型的過程。即分析必須搞清楚系統“做什么”，而設計必須搞清楚系統“怎么做”，從分析到設計不是傳統方法的轉換，而是平滑（無縫）過渡，而求解域模型是系統實現的依據。

靜態結構設計： ? 類設計 ? 包設計 ? 接口設計

動態結構設計（行為和交互建模）： ? 對象如何進行交互的

2.GUI（圖形用戶界面）設計概述

對于用戶來說，一個友好的界面是至關重要的。

用戶界面（User Interface）的設計質量直接影響用戶對軟件產品的評價，從而影響軟件產品的競爭力和使用壽命，因此，對人機界面的設計必須給予足夠的重視。

良好的ＧＵＩ設計原則

1、關注用戶及其任務，而不是技術

2、首先考慮功能，其次才是表現

3、與用戶對任務的看法保持一致

4、設計要符合常見情況

5、不要分散用戶對他們目標的注意力

6、促進學習，從外(用戶)到里(設計人員)思考，而不是相反。

7、傳遞信息，而不僅僅是數據

8、設計應滿足響應需求

9、通過用戶試用發現錯誤，然后修復它

3.數據庫設計

設計原則：

每一個類成為一個數據庫表。關系映射：

（1）一對多的關系映射為數據庫表的主外鍵關聯（1方的主鍵加入n方成為外鍵）

（2）一對一的關系映射為數據庫表的主外鍵關聯（1方的主鍵加入另一方成為外鍵）

（3）多對多的關系映射：產生第三張表，將兩個多方的主鍵加入其中成為外鍵，兩個外鍵的組合成為主鍵。

利用數據庫三范式檢查表，從而考察領域類圖的分析是否合理，消除冗余數據。檢查數據是否能夠反映用例視圖的需要；進一步與用戶再次確認使用的數據。

7.8注釋

夾在程序中的注釋是程序員與日后的程序讀者之間通信的重要手段。注釋決不是可有可無的。一些正規的程序文本中，注釋行的數量占到整個源程序的1/3到1/2，甚至更多。

注釋分為兩類：序言性注釋和功能性注釋。

1.序言性注釋

通常置于每個程序模塊的開頭部分，它應當給出程序的整體說明，對于理解程序本身具有引導作用。

序言性注釋包括： 程序標題；

有關本模塊功能和目的的說明； 主要算法；

接口說明：包括調用形式，參數描述，子程序清單；

有關數據描述：重要的變量及其用途，約束或限制條件，以及其它有關信息； 模塊位置：在哪一個源文件中，或隸屬于哪一個軟件包；

開發簡歷：模塊設計者，復審者，復審日期，修改日期及有關說明等。

2.功能性注釋

功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執行了下面的語句會怎么樣，而不要解釋下面怎么做。

要點：

描述一段程序，而不是每一個語句； 用縮進和空行，使程序與注釋容易區別；

7.9軟件測試

軟件測試的定義：軟件測試是使用人工和自動手段來運行或測試某個系統的過程，其目的在于檢測被測試軟件系統是否滿足規定的需要，或是弄清楚被測系統的預期結果與實際結果之間的差別。

黑盒測試：僅需要知道被測試對象的輸入和預期輸出，不需要了解代碼實現的細節。測試方法

主要分為兩類：功能層面的測試方法和函數層面的測試方法（邊界值測試、等價類測試、基于決策表測試）。側重于系統業務流程的梳理，是基于動態業務過程設計測試用例。

白盒測試：是針對程序代碼展開的測試，分為靜態測試和動態測試：關注對象包括源代碼和程序結構。靜態白盒測試的方法是代碼檢查。靜態測試不需要運行程序和設計測試用例，側重于源代碼的檢查和優化，直接查看源代碼和執行代碼，直接定位代碼中的缺陷。動態測試側重于程序結構的測試。

測試用例的定義：測試用例是一組測試輸入，執行條件和預期結果。目的是要滿足一個特定的目標。如果執行一條特定的程序路徑或者檢驗是否符合一個特定的需求的用例。測試用例：輸入+輸出+測試環境測試環境包括：硬件環境，軟件環境，網絡環境，歷史數據。

測試用例分為兩個階段：測試用例分析階段，測試用例設計階段。

7.9.1測試和調試的區別

1、目的不同

軟件測試的目的是發現錯誤，至于找出錯誤的原因和錯誤發生的地方不是軟件測試的任務，而是調試的任務.調試的目的是為了證明程序的正確，因此它必須不斷地排除錯誤.它們的出發點不一樣。前者是挑錯，是一種挑剔過程，屬于質盤保證活動。后者是排錯，是一種排除過程，是編碼活動的一部分。

2、任務不同

既然軟件測試屬于質量保證活動，因此它貫穿于整個開發過程.從需求分析開始，就要制訂軟件測試計劃，軟件設計時要設計系統軟件測試、集成側試用例，編碼階段要設計單元軟件測試用例并進行單元軟件測試，軟件測試階段要進行集成軟件測試、系統軟件測試等，直到產品交付。只要有修改就有軟件測試，產品交付后同樣。它是比較有規律的活動，有系統的方法、原則作指導。

而調試是編碼活動的一部分，因此有編碼就有調試.它的任務主要就是排錯。調試的方法經常與使用的開發工具有關，例如:解釋型的開發工具可以交互式調試，編譯型開發工具就很難較好地查錯。當然它有一些啟發式的方法，它是一種比較依賴開發人員經驗的活動。

3、指導原則和方法不同

軟件側試是一種有規律的活動，有一系列軟件軟件測試的原則.其中主要是制訂側試計劃，然后嚴格執行.其次是一種挑剔性行為，因此它不但要側試軟件應該做的，還需要側試軟件不應該做的事情。調試所遵循的規律主要是一些啟發式規則，是一個推理過程。例如使用歸納法、演繹法、回溯法等。

軟件測試的輸出是預知的，其軟件測試用例必須包括預期的結果，而調試的輸出大多是不可預見的，需要調試者去解釋、去發現產生的原因。

4、操作者

因為心理狀態是軟件測試程序的障礙，所以執行軟件測試的人一般不是開發人員，以使軟件測試更客觀、更有效，而調試人員一般都是開發人員.7.9.2軟件維護

軟件維護活動類型總起來大概有四種：糾錯性維護（校正性維護）、適應性維護、完善性維護或增強、預防性維護或再工程。

改正性維護

改正性維護是指改正在系統開發階段已發生而系統測試階段尚未發現的錯誤。這方面的維護工作量要占整個維護工作量的17%～21%。所發現的錯誤有的不太重要，不影響系統的正常運行，其維護工作可隨時進行：而有的錯誤非常重要，甚至影響整個系統的正常運行，其維護工作必須制定計劃，進行修改，并且要進行復查和控制。

適應性維護

適應性維護是指使用軟件適應信息技術變化和管理需求變化而進行的修改。這方面的維護工作量占整個維護工作量的18%～25%。由于計算機硬件價格的不斷下降，各類系統軟件屢出不窮，人們常常為改善系統硬件環境和運行環境而產生系統更新換代的需求；企業的外部市場環境和管理需求的不斷變化也使得各級管理人員不斷提出新的信息需求。這些因素都將導致適應性維護工作的產生。進行這方面的維護工作也要像系統開發一樣，有計劃、有步驟地進行。

完善性維護

完善性維護是為擴充功能和改善性能而進行的修改，主要是指對已有的軟件系統增加一些在系統分析和設計階段中沒有規定的功能與性能特征。這些功能對完善系統功能是非常必要的。另外，還包括對處理效率和編寫程序的改進，這方面的維護占整個維護工作的50%～60%，比重較大．也是關系到系統開發質量的重要方面。這方面的維護除了要有計劃、有步驟地完成外．還要注意將相關的文檔資料加入到前面相應的文檔中去。

預防性維護

預防性維護為了改進應用軟件的可靠性和可維護性，為了適應未來的軟硬件環境的變化，應主動增加預防性的新的功能，以使應用系統適應各類變化而不被淘汰。例如將專用報表功能改成通用報表生成功能，以適應將來報表格式的變化。這方面的維護工作量占整個維護工作量的4%左右。

第一章

1.軟件有哪些種類？

答：1.按功能特征進行劃分：

(1)系統軟件(2)支撐軟件(3)應用軟件

2.按規模大小進行劃分

微型、小型、大型、甚大型、極大型

4.結合自己的親身經歷，談談軟件工具在軟件開發過程中的作用。

使軟件開發更加模式化，工程化，從而提高軟件開發的效率和封裝性。

第二章

2.軟件瀑布模型為什么要劃分階段？各個階段的任務是什么？

在軟件開發早期，開發只是被簡單地分成編寫代碼和修改代碼兩個階段。往往在拿到項目后立刻編寫程序，然后調試通過后直接交付給用戶使用。如果應用中出現錯誤，或者有新的要求，都需要重新修改代碼。這種小作坊式的軟件開發方法有明顯的弊端，如缺乏統的項目規劃、不太重視需求的獲取和分析、對軟件的測試和維護考慮不周等，這些都會導致軟件項目的失敗。

概念階段：計劃、需求分析

開發階段：設計、編碼、測試

維護階段：運行維護

3.舉例說明哪些項目的開發適用于原型模型或螺旋模型，哪些不適于采用這兩種模型。

螺旋模型適合于大型軟件的開發，應該說它是最為實際的方法，它吸收了軟件工程“演化”的概念，使得開發人員和客戶對每個演化層出現的風險有所了解，繼而做出應有的反應。

不適用:小型軟件。

原型般是指對某種產品進行模擬的初始版本或者原始模型，在工程領域中具有廣泛應用。

不適用:大型軟件項目；含有對于計算量大、邏輯性較強的程序模塊：

第三章

1.可行性研究的任務是什么？

可行性研究的任務是以最小的代價在盡可能短的時間內確定問題是否能夠解決。簡單的說，可行性研究的最終結果是決定項目y做還是小做”而不是“如何做”。2.項目開發計劃有哪些內容？

引言(目的、背景、參考文獻、術語)；項目概述(功能、條件、運行環境、產品、程序、文檔、服務、驗收標準、實施計劃、工作任務分解、進度、預算、人員)

第四章

1.什么是需求工程？需求工程包括哪些活動？

需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的 門學科。它通過合適的工具和記號系統地描述待開發系統，及其行為特征和相關約束，形成需求文檔；并對用戶不斷變化的需求演進給予支持。

一個良好的需求開發過程應該包括需求獲取、需求分析與建模、編寫需求規格說明書和需求評審4個主要活動。

2.需求工程過程包括哪些主要活動？ 需求開發過程應該包括需求獲取、需求分析與建模、編寫需求規格說明書和需求評審4個主要活動。3.有哪兩種主要的需求分析模型？它們的主要思想是什么？

答：面向對象分析模型，結構化分析模型。前者是采用面向對象的思想進行軟件需求分析的建模過程，而后者模型的核心是DD，它是設計各種數據對象的總和。他們的模型分別起到了描述數據模型，功能模型與行為模型的作用。

4.需求規格說明書的主要作用是什么？應該包括哪些主要內容？ 作用：

(1)作為用戶方和開發方之間的合同，為雙方相互了解提供基礎。

(2)反映問題的結構，作為系統設計和編碼的依據。

(3)作為測試和驗收目標系統的依據。內容：

用戶可以通過需求規格說明書檢查需求描述是否滿足原來的期望。設計人員根據軟件需求規格說明書的描述了解所需開發軟件的功能和性能，以及開發軟件時必須滿足的約束，將其作為軟件設計的依據。測試人員根據軟件需求規格說明書中對產品的描述，設計測試計劃、測試用例和測試過程。產品發布人員根據軟件需求規格說明和用戶界面設計編寫用戶手冊和幫助信息

第五章

2.簡述數據流圖分解時的注意事項。

?上層可分解得快些（即分解成子數據處理個數多些），這是因為上層是綜合性描述，對可讀性的影(即分解成的子數據處理個數多些)，這是因為上層是綜合性描述，對可讀性的影響小。而下層應分解得慢性。

?在不影響可讀性的前提下，應適當多分解成幾部分，以減少分解層數。3.數據字典的作用是什么？它有哪些基本內容？ ?分解應自然，概念上要合理、清晰。

作用：數據字典作為分析階段的工具，有助于改進分析人員和用戶.間的通信，進而消除很多的誤解，同時也有助于改進不同開發人員之間的通信；.內容:數據字典的內容主要是對數據流圖中的數據項、數據流、加工邏輯、數據存儲和外部實體

第六章

1.什么是面向對象方法？與傳統軟件開發方法相比，面向對象方法有什么優點？ 是一種把面向對象的思想應用于軟件開發過程中，指導開發活動的系統方法。優點：

1.符合人們對問題的認識習慣

2.增強問題域與最終軟件系統之間的銜接

3.易于維護和復用

4.易于開發大型軟件產品

2.什么是模型？在軟件開發過程中為什么需要建立模型？

在軟件開發過程中，建立軟件模型具有十分重要的作用，主要體現在以下幾個方面：

有助于問題的簡化，通過抽象降低復雜性；

有助于和其他開發小組成員，各種用戶以及系統相關者進行交流；

有助于維護人員了解軟件設計的思路和細節，為以后的維護和升級提供了文檔。

第七章

1．面向對象分析包括哪些活動？應該建立哪些類型的模型？

面向對象分析OOA模型的過程包括理解用例模型、識別分析類、定義交互行為、建立分析類圖、評審分析模型5個活動組成。

目標是建立一個符合問題域、滿足用戶需求的OOA模型。

2.什么是實體類、邊界類和控制類？為什么將分析類劃分成這3種類型？

實體類：用于描述必須存儲的信息，同時描述相關的行為。實體類代表擬建系統中的核心信息。在RUP的有關文檔中對實體類的解釋為：“實體類是用于對必須存儲的信息和相關行為建模的類。邊界類：在系統與外界之間，為它們交換各種信息與事件。邊界類處理軟件系統的輸入和輸出。在RUP的有關文檔中對邊界類的解釋為：邊界類是一種用于對系統外部環境與其內部運作之間的交互進行建模的類。

控制類：與業務過程相關，它們控制整個業務的流程和執行次序。在RUP的有關文檔中對控制類的解釋為：控制類用于對一個或幾個用例所持有的控制行為進行建模。

控制類對象可以和邊界對象交互，也可以和實體對象交互，但不能和用例的參與者直接進行交互。

第八章

1.什么是軟件設計？它的目標和任務是什么？

<1>軟件設計：在需求分析的基礎上通過抽象和分解將系統分解成模塊，確定系統功能的實現。即把軟件需求轉換為軟件包表示的過程。

<2>目標：軟件設計的最終目標是產生一個設計規約，該規約包括體系結構、描述數據、接口和構件的設計模型。

軟件設計的任務，就是把分析階段產生的軟件需求規格說明轉換為用適當手段表示的軟件設計文檔。

2.完成良好的軟件設計應遵循哪些原則？

模塊化與模塊獨立性；抽象與逐步求精；信息隱藏。3.如何理解模塊獨立性？用什么指標來衡量模塊獨立性？

<1>模塊的獨立性是指軟件系統中每個模塊只涉及軟件要求的具體的子功能，而和軟件系統中其他的模塊的接口是簡單的。

<2>一般采用兩個準則度量模塊獨立性，即模塊的內聚性和模塊間的耦合性 4.說明軟件設計階段的任務和過程 軟件設計分兩步完成，即總體設計與詳細設計。第個階段是總體設計，即概要設計或初步設計。這、階段主要確定實現目標系統的總體思想和設計框架，確定程序由哪些模塊組成，以及模塊與模塊之間的關系，最后提出概要設計說明書。第二個階段是詳細設計，即過程設計或構件級設計，其任務是通過對結構表示進行細化，確定各個軟件構件的詳細數據結構和算法，產生描述各個軟件構件的詳細設計文檔。

5.試說明軟件體系結構在軟件設計階段中的重要性。

良好的體系結構設計是決定軟件系統成功的重要因素。軟件體系結構設計的好壞往往會成為一個系統設計成敗的關鍵。通常，軟件體系結構涉及軟件的總體組織、全局控制、數據存取及子系統之間的通信協議等。

6.簡述面向對象設計階段要做的工作。

OOD主要包括三個方面的工作：系統體系結構設計、用例實現方案設計和用戶界面設計。

第十一章

1.簡述程序設計語言的基本特征及分類。

基本特征包括心理特性，工程特性和技術特性三個方面。語言的的—心理特性對人機通信的質量有主要的影響；語言的工程特性對軟件開發成功與否有重要的影響，此外語言的技術特性也會影響軟件設計的質量

?按程序設計語言的歷史發展過程，計算機語言可分為機器語言、匯編語言、高級程序設計語言。

?按與機器的依賴程度，可分為低級、中級和高級語言。

?按應用范圍，可分為通用語言與專用語言兩大類，通用語言義可細分為系統程序設計語言、科學計算語言、事務處理語言和實時控制語言等。

?按程序的設計方法，可分為命令性語言和作用性語言。

?按語言的成分，可以分成順序語言、并行語言和實時語言等。

?按語言的組成方法，可以分成匯集式語言和可擴充語言。2.為了具有良好的程序設計風格，應該注意哪些方面的問題？

要形成良好的程序設計風格，應從源程序文檔化、數據說明、語句構造、輸入輸出和追求效率幾個方面加以注意。

3.什么是軟件測試？軟件I則試的原則有哪些？

軟件測試是按照特定的規則，發現缺陷而執行程序的過程。

一個好的測試用例是指盡可能找到迄今為止尚未發現缺陷的用例。一個成功的測試是指揭示了迄今為止尚未發現缺陷的測試。軟件測試的原則：

(l)所有的測試都應該能追溯到用戶需求。

(Z)應該在測試之前就制定出測試計劃。

(3)Pareto原理可應用于軟件測試。

(4)測試應從“小規模”開始，逐步轉向“大規模”

(S)窮舉測試是不可能的。

(6)既要做通過性測試，又要做失效性測試。

(D為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。

第十四章

1.為什么說軟件維護是不可避免的？

因為軟件的開發過程中，一般很難檢測到所有的錯誤，其次軟件在應用過程中需要隨用戶新的要求或運行環境的變化而進行軟件的修改或糾正軟件開發過程未發現的錯誤，增強、改進和完善軟件的功能和性能，以適應軟件的發展，延長軟件的壽命，軟件的維護是不可避免的。2.什么是軟件再工程？軟件再工程的主要活動有哪些？

指在逆向工程所獲信息的基礎上修改重構已有的系統，產生的―個新版本，或者說利用這些信息修改或重構軟件系統的工作。

它定義了6為活動r即庫存目錄分析、文檔重構、逆向工程、代碼重構、數據重構、正向工程。3.軟件調試與軟件測試有什么區別？

1、目的不同

軟件測試的目的是發現錯誤，至于找出錯誤的原因和錯誤發生的地方不是軟件測試的任務，而是調試的任務。調試的目的是為了證明程序的正確，因此它必須不斷地擠除錯誤.它們的出發點不一樣“前者是挑錯，是一種挑剔過程，屬于質盤保證活動。后者是排錯，是-種排除過程，是編碼活動的部分?

2、任務不同

既然軟件測試屬于質量保證活動，因此它貫穿十整個計發過程.從需求分析開始，就要制訂軟件測試計劃，軟件設計時要設計系統軟件測試、集成側試用例，編碼階段要設計單元軟件測試用例并進行單元軟件測試，軟件測試階段要進行集成軟件測試、系統軟件測試等，直到產品交付。只要有修改就有軟件測試，產品交付后同樣。它是比較有規律的活動，有系統的方法、原則作指導。

而調試是編碼活動的部分，因此有編碼就有調試它的任務主要就是排錯。調試的方法經常與使用的開發工具有關，例如解釋型的開發工具可以交互式調試，編譯型開發工具就很難較好地查錯。當然它有些啟發式的方法，它是.種比較依賴開發人員經驗的活動。

3、指導原則和方法不同

軟件側試是種有規律的活動，有一系列軟件軟件測試的原則.其中主要是制U側試計劃，然后嚴格執行。其次是種挑剔性行為，因此它不但要側試軟件應該做的，還需要側試軟件個應該做的事情。調試所遵循的規律主要是些啟發式規則，是”個推理過程。例如使用歸納法、演繹法、回溯法等。

軟件測試的輸出是預知的，其軟件測試用例必須包括預期的結果，而調試的輸出大多是不可預見的，需要調試者去解釋、去發現產生的原因。

4、操作者

因為心理狀態是軟件測試程序的障礙，所以執行軟件測試的人一般不是開發人員，以使軟件測試更客觀、更有效，而調試人員一般都是開發人員?

5、操作環境、配置、工具不同

調試在開發的編碼環境下進行。如果編碼使用解釋型語言，則可以進行人機交互式調試，設里斷點、單步調試等。如果編碼使用編譯型語言，也可以設置斷點、顯示調試變量值等。而軟件測試是在軟件測試環境下進行，直接運行開發完成的程序，可能不再需要一些開發時的驅動程序、動態鏈接庫等.使用不同的工具，環境配置也不同。

簡答題，1.什么是軟件工程？請分析軟件工程的目標是什么？

答案：軟件工程是：1將系統化的、規范的、可度量的方法應用于軟件的升發、運行和維護過程，也就是說將工程化應用于軟件開發和管理之中；2對1中所選方法的研究”

軟件工程旨在開發滿足用戶需要、及時交付、不超過預算和無故障的軟件，其主要目標如下: a)實現預期的軟件功能，達到較好的軟件性能，滿足用戶的需求。

b)增強軟件過程的可見性和可控性，保證軟件的質量。

c)提高所開發軟件的可維護性，降低維護費用。

d)提高軟件開發生產率，及時交付使用。

e)合理預算開發成本，付出較低的開發費用。

3.根據相關的法律，對于侵犯軟件著作權的行為，根據情節應當給予什么處罰？

對于侵犯軟件著作權的行為，要根據情況承擔停止侵害、消除影響、賠禮道歉、賠償損失等民事責任；損害社會公共利益的，由著作權行政管理部門責令停止侵權行為，沒收違法所得，沒收、銷毀侵權復制品，并處罰款；情節嚴重的，著作權行政管理部門可以沒收用子制作侵權復制品的材料、工具、設備等；觸犯刑律的，依法追究刑事責任。

4根據你的理解，列舉出職業化軟件工程師要注意的三個主要問題，請給出理由。沒有唯一答案。

1)不遵守標準和規范：職業化的重要特征是遵守行業標準，不能肆意按照自己的想象來發揮。自從人們認識到軟件危機以來，總結軟件開發的失敗教訓和成功經驗，并把它們總結成為最佳實踐，進而形成標準，要充分利用這些最佳實踐和標準來指導軟件過程。任何閉門造車、想當然的行為都是不被提倡的，注定要走彎路。

2)對待計劃不嚴肅：軟件工程強調計劃性，計劃的內容包括；設備資源、進度安排、人力資源、任務分配等等。在項目的進行中要跟蹤計劃執行情況，記錄計劃執行過程中的偏差，對任何變更都要經過評審和批準才能付諸行動。

3)不主動與人溝通：軟件不可見的特性，需要軟件工程師進行大量書面的、口頭的或面對面的溝通，溝通的目的是為了使相關的人員了解項目的進展、遇到的問題、應用的技術、采用的方法。5．軟件工程為什么要強調規范化和文檔化？.軟件工程強調規范化和文檔化。規范化的目的是使眾多的開發者遵守相同的規范，使軟件生產擺脫個人生產方式，進入標準化、工程化的生產方式。文檔化是將軟件的設計思想、設計過程和實現過程完整地記錄下來，以便于后人的使用和維護，在開發過程中各類相關人員借助于文檔進行交流和溝通。另外，在開發過程中產生的各類文檔使得軟件的生產過程由不可見變為可見，便于管理

者對軟件生產進度和開發過程進行管理。在用戶最終驗收時可以通過對提交的文檔進行技術審查和管理審查，保證軟件的質量。

6．請簡單說明結構化分析的主要步驟。

根據用戶的需求畫出初始的數據流程圖，寫出數據字典和初始的加工處理說明(lPO圖)，實體關系圖。以初始數據流程圖為基礎，從數據流程圖的輸出端開始回溯。在對數據流程圖進行回溯的過程中可能會發現丟失的處理和數據，應將數據流程圖補充完善。對軟件性能指標、接口定義、設計和實現的約束條件等逐一進行分析。系統分析人員與用戶起對需求分析的結果進行復查。根據細化的需求修訂開發計劃。編寫需求規格說明書和初始的用戶手冊，測試人員開始編寫功能測試用的測試數據。

7．設計類的屬性時必須要定義是哪兩項？

設計類的屬性時必須要定義的內容：

1)屬性的類型：設計屬性時必須要根據開發語言確定每個屬性的數據類型?如果數據類型不夠，設計人員可以利用已有的數據類型定義新的數據類型。

2)屬性的可見性。在設計屬性時要確定公有屬性、私有屬性、受保護屬性。活動圖反映系統中從一個活動到另一個活動的流程，強調對象間的控制流程。活動圖特別適合描述工作流和并行處理過程。具體地說活動圖可以描述一個操作過程中需要完成的活動；描述一個對象內部的工作；描述如何執行組相關的動作，以及這些動作如何影響它們周圍的對象；說明個業務活動中角色、工作流、組織和對象是如何工作的。

順序圖用于描述一組交互對象間的交互方式，它表示完成某項行為的對象和這些對象之間傳遞消息的時間順序。

8面向對象的分析通常要建立三個模型，請問三個模型的作用？

a)功能模型：表達系統的詳細需求，為軟件的進一步分析和設計打下基礎。在面向對

象方法中，由用例圖和場景描述組成。

b)對象模型：表示靜態的、結構化的系統“數據”性質。描述現實世界中實體的對象以及它們之間的關系，表示目標系統的靜態數據結構。在面向對象方法中，類圖是構件對象模型的核心上具。

c)動態模型：描述系統的動態結構和對象之間的交互，表示瞬時的、行為化的系統的“控制”特性。面向對象方法中，常用狀態圖、順序圖、合作圖、活動圖構件系統的動態模型。

9.面向對象的設計活動中，有構架師、用例工程師和構件師參加，他們每個角色的職責是什么？

構架設計的目的是要勾畫出系統的總體結構，這項工作由經驗豐富的構架設計師主持完成。該活動以用例模型、分析模型為輸入，生成物理構架、子系統及其接口、概要的設計類(即設計階段定義的類)。

根據分析階段產生的高層類圖和交互圖，由用例設計師研究已有的類，將它們分配到相應的用例中。檢查每個用例的功能，這些功能依靠當前的類能否實現，同時檢查每個用例的.特殊需求是否有合適的類來實現。細化每個用例的類圖，描述實現用例的類及其類之間的相互關系，其中的通用類和關鍵類可用粗線框區分，這些類將作為項目經理檢查項目時的重點。

經過前面兩個活動，構架設計師已經將系統的構架建立起來，用例設計師按照用例的功能將每個類分配給相應的用例。現在要由構件工程師詳細設計每個類的屬性、方法和關系。10.提高程序可讀性有哪些招數？對你來講比較靈驗的是哪些？

a)源程序文件頭說明，函數應有函數頭說明，內容包括：程序標題；有關該模塊功能和目的說明；主要算法說明；接O說明，包括調用形式、參數描述、子程序清單、有關數據的說明。

b)主要變量(結構、聯合、類或對象)的定義能夠反映其內在含義。c)變量定義最規范化，說明的先后次序固定。

d)處理過程的每個階段和典型算法前都有相關注釋說明。

三、簡答題：

2、什么是軟件工程？包括哪些內容？

答: 軟件工程：用科學知識和技術原理來定義、開發、維護軟件的一門學科。軟件工程的內容：

１）軟件開發技術：軟件開發方法、軟件開發過程、軟件開發工具和環境。２）軟件開發管理：軟件管理學、軟件經濟學、軟件心理學。

軟件工程的目標:是成功的建造一個大型軟件系統，所謂成功是要達到以下幾個目標：①付出較 低的開發成本;②面到要求的軟件功能;③取得較好的軟件性能;④開發的軟件易于 移植;⑤需要較低的維護費用;⑥能按時完成開發任務，及時交付使用;⑦開發的軟 件可靠性高;軟件工程過程：生產一個最終能滿足需求且達到工程目標的軟件產品所需要的步驟。軟件工 程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。

軟件工程的框架可概括為：①目標、②過程和③原則。

軟件工程的原則：是指圍繞工程設計、工程支持以及工程管理在軟件開發過程中必須遵循的原則。基本原理：⑴用分階段的生命周期計劃嚴格管理；⑵堅持進行階段評審；⑶實行嚴格的產品控制； ⑷采用現代程序設計技術；⑸結果應能清楚地審查；⑹開發小組的人員應該少而精； ⑺承認不斷改進軟件工程實踐的必要性；（工程化的方法開發軟件基本原理）

軟件工程方法學：軟件工程包括技術和管理兩方面的內容，是技術與管理緊密結合所形成的工 程學科。

軟件工程方法學包括：①傳統方法學（結構化范型）和②面向對象方法學。

面向對象的要點: ①把對象作為融合了數據及在數據上的操作行為的統一的軟件構件。②把所 有對象都劃分成類。③按子類與父類的關系,把類組成一個層次結構。④對象彼此之 間僅能通過傳遞消息互相聯系。

軟件工程方法學三要素是：①方法；②工具；③過程。

3、軟件生命周期由哪三個時期組成，又劃分為哪8個階段？

答：軟件生存周期：一個軟件從提出開發要求開始直到該軟件報廢為止的整個時期。軟件生命周期是

由：⑴軟件定義時期；⑵軟件開發時期；⑶軟件維護時期三個時期組成的。又劃分為：①問題定義、②可行性研究、③需求分析、④總體設計、⑤詳細設計、⑥編碼和單元測試、⑦綜合測試、⑧維護八個階段。

1、問題的定義及規劃 此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。

2、需求分析 在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。“唯一不變的是變化本身。”，同樣需

求也是在整個軟件開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。

3、軟件設計 此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設計和詳細設計。好的軟件設計將為軟件程序編寫打下良好的基礎。

4、程序編碼 此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。

5、軟件測試 在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。

6、運行維護 軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。

4、什么是白盒測試法？什么是黑盒測試法？

答：白盒測試：所謂白盒測試就是在知道產品內部工作過程或程序內部結構和處理過程的前提下,檢

驗產品內部動作是否按照規格說明書的規定正常進行或按照程序內部的邏輯測試程序,檢驗程序中的每條通路是否都能按照預定要求正確工作的測試方法.因此白盒測試又稱為結構測試或邏輯測試。

從覆蓋源程序語句的詳盡程度分析，大致有以下一些不同的覆蓋標準：⑴語句覆蓋；⑵判定覆蓋；⑶條件覆蓋；⑷判定/條件覆蓋；⑸條件組合覆蓋；⑹點覆蓋；⑺邊覆蓋；⑻路徑覆蓋。黑盒測試：所謂黑盒測試是指在完全不考慮程序的內部結構和處理過程的前提下,在程序接口進行的測試,它只檢查程序功能是否能按照規格說明書的規定正常使用,程序是否能適當地接受輸入數據產生正確的輸出信息,并且保持外部信息的完整性.因此,又稱為功能測試。特點：等價類劃分、邊界值分析、因果圖、錯誤推測。

優點 1.基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了 2.設計完測試例之后，下來的工作就是爽了，當然更苦悶的是確定crash原因 缺點 1.結果取決于測試例的設計，測試例的設計部分來勢來源于經驗，OUSPG的東西很值得借鑒

2.沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作

3.就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不

是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

5、什么是集成測試？非漸增式和漸增式有什么區別？漸增式如何組裝模塊？

答：將模塊組合起來成為一個完整的系統對其進行測試。非漸增式是將模塊先進行單元測試然后組裝

在一起進行測試。漸增式是逐個將未測試的模塊組裝到已經測試過的模塊上去進行集成測試，每加入一個就測試一次。非漸增式需要樁模塊和驅動模塊、非漸增式開始可以并行測試、漸增式可以及時的發現接口錯誤，非漸增式很難發現接口發現錯誤、漸增式開始不能并行測試、漸增式測試比較徹底。漸增式組裝模塊有自頂向下和自底向上兩種組裝方式。

6、什么是確認測試？該階段有那些工作？

答：調試的目的是發現錯誤的位置并改正錯誤。簡單調試、演繹調試、遞歸調試、回溯調試。

7、面向對象方法學與傳統方法學有何區別？

答：面向對象方法學注重的是軟件的重用性，而傳統的方法學則在這一問題解決上不理想。面向對象

方法學和傳統的方法學在問題分析上的切入點不同。面向對象里面，系統是長出來的，傳統的方法學里面，系統是放進去的。傳統方法：⑴結構化開發方法，注重的是系統功能，自頂向下，從大到小的功能分解，從DFD到MSD，往往系統需求變化最大就是功能，一段較長的時間內，商業的流程可能已經發生了很大的變化，這樣基于功能和過程的方法顯然難以維護的，代碼重用率可想而知，而商業過程中的數據可能變化不會很大，⑵信息工程法，注重的是數據，事件流－＞信息流，（資金流，物流）－＞數據流，數據的輸入和轉化輸出，數據流程圖，狀態轉化圖，事件順序圖，過程依賴圖，兩者都是由事件驅動．面向的是問題，是為了要解決某一個具體問題，其觀察事物的方法不是本體客體本身，而是對本體客體相互作用過程抽象，轉化成邏輯模型。面向對象方法學：其切入點是客觀世界的主體和客體，通過封裝實現了信息交流的安全，抽象和繼承使得事物的一完整表述和容易修改新的變化，聚合，關聯反映事物間的相互作用和關系，通過關聯類管理，這樣把事物和事物間的關系分開．減少了復雜度，便于維護，大大提高了代碼重用率。

8、軟件開發模型有幾種?各有什么特點? 軟件生存周期模型：是描述軟件開發過程中各種活動如何執行的模型。（模型：是為了理解事物而 對事物做出一種抽象，它忽略不必要的細節，它也是事物的一種抽象形式、一個規劃、一個程式。）主要模型：①瀑布模型；②增量模型；③螺旋模型；④噴泉模型；⑤變換模型；⑥基于知識的模 型等

瀑布模型：①它提供了一個摸板，這個摸板使分析、設計、編碼、測試和支持的方法可以在該摸 板下有一個共同的指導；②雖然有不少缺陷但比在軟件開發中隨意的狀態要好得多。快速原型模型：①開發速度快，質量有保證。②對信息系統特別有效。

增量模型：①人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人

力實現下一個增量。②當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑，這樣就可以先發布部分功能給客戶，對客戶起到鎮靜劑的作用。③具有一定的市場。

螺旋模型：①對于大型系統及軟件的開發，這種模型是一個很好的方法。開發者和客戶能夠較好

地對待和理解每一個演化級別上的風險。②對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標；減少了過多測試或測試不足所帶來的風險。

9、可行性研究：⑴系統流程圖；⑵數據流程圖；

系統流程圖：系統流程圖是概括地描繪物理系統的傳統工具。基本思想是用圖形符號以黑盒子形

式描繪組成系統的每個部件。其表達的是數據在系統各部件之間流動的情況，而不是對數據進行加工處理的控制過程。

數據流程圖：簡稱DFD,是描述數據處理過程的工具。數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的移動變換過程，是一種功能模型。作用：它以圖形的方式描繪數據在系統中流動和處理的過程,反映系統必須完成的邏輯功能。基本符號有四種：→,箭頭,表示數據流；○,圓或橢圓,表示加工； =,雙杠,表示數據存儲；□,方框,表示數據的源點或終點。

可行性研究的任務：(1)經濟可行性。確定待開發系統是否值得投資開發。(2)技術可行性。對待

開發的系統進行功能、性能和限制條件的分析，確定在現有資源的條件下技術風險有多大，系統是否能實現。(3)法律可行性。確認待開發系統可能會涉及的任何侵犯、妨礙、責任等問題。(4)抉擇。對系統開發的不同方案進行比較評估。

10、什么是字據字典？其作用是什么？它有哪些條目？

字據字典：簡稱ＤＤ，就是用來定義數據流圖中的各個成分具體含義的，它以一種準確的、無二義性 的說明方式為系統的分析、設計及維護提供了有關元素的一致的定義和詳細的描述。

作 用：⑴為系統的分析設計及維護提供了有關元素的一致的定義和詳細的描述.⑵為分析人員查找

數據流圖中有關名字的詳細定義而服務的.⑶它和數據流圖共同構成了系統的邏輯模型,是需求規格說明書的主要組成部分.條 目：數據流、數據項、數據存儲、基本加工。

11、需求分析的任務是什么? 答: 需求分析是指：開發人員要準確理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳 述轉化為完整的需求定義，再由需求定義轉換到相應的形式主義功能規約(需求規格說明)的過程。需求分析的主要任務：⑴正確地確定對系統綜合要求,充分理解和表達用戶的需求。⑵通過結構分

析的方法對系統進行分解,以確定軟件系統的主要成分或軟件系統的構成。⑶是對以上已進行的兩項工作進行描述,以形成需求文檔。⑷編寫用戶手冊；⑸編寫驗收計劃；⑹修正可行性研究階段所制訂的軟件項目開發計劃。

12、結構化分析方法：結構化分析方法就是用抽象模型的概念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止。

主要工具：數據流圖、數據詞典、結構化英語、判定表和判定樹。3種模型：①數據模型、②功能模型和③行為模型。

驗證軟件需求：⑴一致性；⑵完整性；⑶現實性；⑷有效性；

結構化分析方法步驟： ①了解當前系統的工作流程,獲得當前系統的物理模型。②抽象出當前系 統的邏輯模型。③建立上標系統的邏輯模型。④作進一步補充和優化。

結構化程序設計基本要點：⑴采用自頂向下、逐步求精的程序設計方法；⑵使用三種基本程序控 制結構構造程序（①順序方式；②選擇方式；③循環方式；）。⑶主程序員組的組織形式。

13、總體設計過程由兩個主要階段組成：①系統設計階段，確定系統的具體實現方案；②結構設計階段，確定軟件結構。

模塊：軟件系統的層次結構正是模塊化的具體體現。將整個軟件劃分成若干單獨命名和可編址的部分，稱之為模塊。模塊化：就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集 成起來構成一個整體，可以完成指定的功能滿足用戶的需求。模塊是構成程序的基本構件。

模塊化的根據：把復雜的問題分解成許多容易解決的小問題，原來的問題也就容易解決了。這就是模塊化的根據。

14、衡量模塊獨立性的兩個標準是什么？它們各表示什么含義？ 兩個定性的度量標準：耦合與內聚性。

耦合：是模塊之間的相對獨立性(互相連接的緊密程度)的度量。模塊之間的連接越緊密，聯系越多，耦合性就越高，而其模塊獨立性就越弱。按耦合度從低到高依次有7種耦合方式：①非直接耦

合（獨立運行）；②數據耦合（用參數表傳遞簡單數據）；③標記耦合（傳遞數據結構或者一部分）；④控制耦合（傳遞的信息包括控制模塊的信息）；⑤外部耦合（模塊與軟件之外的環境有關）；⑥公共耦合（多個模塊引用同一全局的數據區）；⑦內容耦合（訪問內部數據，代碼重疊或者多個入口）。

內聚：是模塊功能強度(一個模塊內部各個元素彼此結合的緊密程度)的度量。一個模塊內部各個元素

之間的聯系越緊密，則它的內聚性就越高。按內聚度從低到高依次有7種內聚種類： ①偶然內聚（模塊完成的多個任務，任務之間的關系松散）；②邏輯內聚（模塊完成邏輯相關的一組任務）；③瞬時內聚（模塊的所有任務必須在同一時間間隔內執行）；④過程內聚（模塊的處理元素相關而且按照特定的次序執行）；⑤通信內聚（模塊的所有元素集中在一個數據結構區域上）；⑥順序內聚（模塊的處理元素相關，必須順序執行）；⑦功能內聚（模塊完成單一的功能，各個部分協調工作，而且不可缺少）

耦合和內聚的關系：一般說來，在系統中各模塊的內聚越大，則模塊間的耦合越小。但這種關系并不

是絕對的。耦合小使得模塊間盡可能相對獨立，從而各模塊可以單獨開發和維護。內聚大使得模塊的可理解性和維護性大大增強。因此，在模塊的分解中應盡量減少模塊的耦合，力求增加模塊的內聚。

15、Jackson方法的步驟：(1)實體動作分析：從問題的描述中，提取軟件系統要產生和運用的實體，以及

現實世界作用于實體上的動作。(2)實體結構分析：把作用于實體的動作或由實體執行的動作，按時間發生的先后次序排序，構成進程，并用一個層狀的Jackson結構圖表示。(3)定義初始模型：把實體和動作表示成一個進程模型，定

義模型與現實世界的聯系。(4)功能描述：說明與已定義的動作相對應的功能，為已定義的動作加入功能函數。(5)決定系統時間特性：對進程加入時間因素，對進程調度特性進行評價和說明。(6)實現：設計組成系統的硬件和軟件，實現系統的原型。

16、測試階段的信息流：這個階段的輸入信息有兩類：(1)軟件配置，包括需求說明書、設計說明書和源 程序清單等；

(2)測試配置，包括測試計劃和測試方案。

自頂向下集成：從主控制模塊開始，沿著程序的控制

層次向下移動，逐漸把各個模塊結合起來。在把附屬于主控制模塊的那些模塊組裝到程序結構中去時，或者使用深度優先的策略，或者使用寬度優先的策略。

深度優先的結合方法先組裝在軟件結構的一條主控制通路上的所有模塊。選擇一條主控制通路取決于應用的特點，并且有很大任意

性。而寬度優先的結合方法是沿軟件結構水平地移動，把處于同一個控制層次上的所有模塊組裝起來。

集成測試的策略：當使用漸增方式把模塊結合到程序中去時，有自頂向下和自底向上兩種集成策略。

17、決定軟件可維護性的因素：⑴可理解性；⑵可測試性；⑶可修改性；⑷可移植性；⑸可重用性；

軟件維護:是指在軟件已經交付使用之后,為了改正錯誤或滿足新的需要而修改軟件的過程.軟件維護 是軟件生命周期的最后一個階段,也是持續時間最長代價最大的一個階段。軟件的可維護性可以定義為:維護人員理解,改正和改動軟件的難易程度。

18、對象：是對現實世界實體的正確抽象，它是由描述內部狀態表示靜態屬性的數據，以及可以對這些數 據施加的操作，封裝在一起所構成的統一體。對象之間通過傳遞消息互相聯系，以模擬現實世界中不同事物彼此之間的聯系。

對象的特點：①以數據為中心；②對象是主動的；③實現了數據封裝；④本質上具有并行性；⑤模塊 工程規模：此系統中應包含接受模塊和信息處理與輸出模塊。可能的解決方案及其評價 從三方面研究每種解決方法的可行性：

(1).技術可行性 使用現在的技術完全可以實現該系統

(2).經濟可行性 這個系統的開發成本不高，節省的經濟資源以及經濟消息能夠超過該系統的開發成本(3).操作可行性 該教學事務管理系統在校院的各個辦公室都可以實現，操作人員為在校師生，所以不存在技術、能力問題。推薦行動方針 通過從技術，經濟，可操作三方面的研究，分析的出結論，此系統是可行的。16.構成E-R圖的基本要素是實體型、屬性和聯系，其表示方法為：

· 實體型(Entity)：用矩形表示，矩形框內寫明實體名；比如學生張三豐、學生李尋歡都是實體。如果是弱實體的話，在矩形外面再套實線矩形。

· 屬性(Attribute)：用橢圓形表示，并用無向邊將其與相應的實體連接起來；比如學生的姓名、學號、性別、都是屬性。如果是多值屬性的話，再橢圓形外面再套實線橢圓。如果是派生屬性則用虛線橢圓表示。

· 聯系(Relationship)：用菱形表示，菱形框內寫明聯系名，并用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型（1 : 1，1 : n或m : n）。比如老師給學生授課存在授課關系，學生選課存在選課關系。如果是弱實體的聯系則在菱形外面再套菱形。(猜考畫圖，或25題)第一章 軟件工程介紹 ? 軟件的特性

1． 軟件是設計開發的，而不是傳統意義上的生產制造的。2． 軟件不會“磨損”。3． 雖然整個工業向著基于構件的構造模式發展，然而大多數軟件扔是根據實際的顧客需

求定制的。? 計算機軟件的七大分類：系統軟件、應用軟件、工程/科學軟件、嵌入式軟件、產品線軟件、Web應用軟件、人工智能軟件。?

遺留系統發生系統演化的原因：1.軟件需要修改其適應性，從而滿足新的計算環境或者技術的需求；2.軟件必須根據新的業務需求進行升級；3.軟件必須擴展以具有與更多現代系統和數據庫的協作能力；4.軟件架構必須進行改建以適應多樣化的網絡環境。? 軟件神話：管理者，用戶，從業者 ? 軟件的定義：程序、數據和文檔。?

軟件工程的目的就是為開發高質量的軟件產品提供一個工程框架。第二章 過程綜述

? 軟件工程的三個要素：工具，過程，方法。

? 通用軟件過程框架：溝通，策劃，建模，構建，部署。?

能力成熟度模型：第0級，不完全級；第1級，已執行級；第2級，已管理級；第三級，已定義級；第4級，已定量管理級；第5級，優化級。

第三章 過程模型

? 簡述慣例框架包含的主要活動：溝通、策劃、建模、構建、部署。? 簡述瀑布模型所包含的主要框架活動：策劃、建模、構建、部署。?

簡述瀑布模型在實際運用中所面臨的問題（缺點）：“瀑布模型是由文檔驅動的”這個事實也是它的一個主要缺點。實際項目很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統開發完成。

演化過程模型產生的背景：業務和產品需求經常變化、嚴格的交付時間、了解了核心產品和系統需求后沒有定義產品或系統擴展的細節問題 ?

簡述基于原型開發模型的軟件開發過程：在用戶不能給出完整、準確的需求說明，或者開發者不能確定算法的有效性、操作系統的適應性或人機交互的形式等許多情況下，可以根據用戶的一組基本需求，快速建造一個原型（可運行的軟件），然后進行評估，進一步精化、調整原型，使其滿足用戶的要求，也使開發者對將要做的事情有更好的理解。溝通-》快速策劃-》建模快速設計-》構建模型-》部署交付品及反饋

? 簡述原型開發的缺點：1.為了使原型盡快的工作，沒有考慮軟件的總體質量和長期的可

維護性。2.為了演示，可能采用不合適的操作系統、編程語言、效率低的算法，這些不理想的選擇成了系統的組成部分。3.開發過程不便于管理 ? 統一過程的三個特點：用例驅動，以架構為核心，迭代并增量

? 簡述統一過程（UP）的5個階段的主要內容：起始，細化，構建，轉換和生產 ? 螺旋模型強調了其他模型均忽略了的（風險分析）?

橫切關注點的定義：一個信用卡處理系統的核心關注點是借貸/存入處理，而系統級的關注點則是日志、事務完整性、授權、安全及性能問題等許多關注點，我們叫它橫切關注點 第四章 敏捷視角下的過程 ?

軟件工程的敏捷理念強調4個關鍵問題：1.具有控制力的自我組織團隊對所開展工作的重要性；2.團隊成員之間、開

發參與者與客戶之間的交流與合作；3.對“變更代表機遇”的認識；4.以及強調快速軟件交付以讓客戶滿意。?

簡述極限編程（XP）過程模型所包含的4個主要框架活動：策劃，設計，編碼，測試 第五章 系統工程

? 計算機系統的6個系統要素：軟件，硬件，人員，數據庫，文檔，規程

? Hatley-Pirbhai建模方法：用戶界面，輸入，系統功能和控制，輸出，維護和自檢 ? 系統環境圖（System Context Diagram）的表示方法（實例）第六章 需求工程

? 需求工程的過程：起始，導出，精化，協商，規格說明，確認和管理 ?

在項目（起始）階段，軟件工程師會詢問一些似乎與項目無直接關系的問題，目的是對

問題、方案需求方、期望方案的本質、客戶和開發人員之間初步的交流和合作的效果建立基本的諒解。

? 為什么導出需求這么困難：范圍問題，理解問題，易變問題。? 用例的定義：講述了能表達主題場景的故事：最終用戶如何在一特定環境下和系統交互 ?

在需求工程的導出階段，三個主要的需求收集活動是：主持人會議、QFD和用戶場景開發 第七章 構建分析模型

? 分析模型在系統描述和設計模型之間建立橋梁。

? 分析模型必須實現的目標：1。描述客戶需要什么；2。為軟件設計奠定基礎；3。定義在軟件完成后可以被確認的一組需求。

? 分析模型的所有元素都可以直接跟蹤到設計模型。

? 分析模型的4個元素：基于場景的元素，面向信息流的元素，基于類的元素，行為元素 ? UML泳道圖是活動圖的一種變形，可以讓建模人員表示用例所描述的活動流，同時指示哪個參與者或分析類對活動矩形所描述的活動負責。

? UML狀態圖為每個類表現活動狀態和導致這些活動狀態變化的事件 ? UML順序圖說明事件如何引發一個對象到另一個對象的轉移

? 簡述CRC建模的內容：CRC提供了一個簡單方法，可以識別和組織與系統或產品需求相關的類。? 使用UML類圖來舉例說明組合和聚合之間的區別 ? 使用UML類圖舉例說明關聯和依賴之間的區別

系統分析的經驗原則（1）系統開發是面向客戶的，應從客戶的角度考慮。

（2）諸如系統開發生命周期之類的產品更新換代機構應該在所有的信息系統開發項目中建立起來。

（3）信息系統開發的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。（4）如果系統的成功可能性受到很大限制時，應取消整個項目。（5）文檔材料是系統開發生命周期中重要的可遞交成果，應加以重視 第八章 設計工程 ?

簡述良好設計的三個特征：1。設計必須實現所有包含在分析模型中的明確需求，而且必須滿足客戶期望的所有隱含需求；2。對于那些生成代碼的人和那些進行測試以及隨后維護軟件的人而言，設計必須是可讀的、可理解的指南；3。設計必須提供軟件的全貌，從實現的角度說明數據域、功能域和行為域。? 設計模型包含的四種元素是什么：數據/類設計、體系結構設計、接口設計、構建級設計

? 軟件體系結構的定義：軟件的整體結構和這種結構為系統提供概念上完整性的方式 ? 模塊應該詳細說明且精心設計以求在某個模塊中包含的信息不被不需要這些信息的其他模塊訪問

?

重構的定義：是使用這樣一種方式改變軟件系統的過程：不改變代碼設計的外部行為而是改進其內部結構

? 舉例說明逐步求精 ?

框架和設計模式之間的區別：框架能使應用程序的開發簡單，價格低廉，但是開發框架不

是一件容易的事。它是一個需要領域和設計經驗的反復過程。設計模式可以簡化這個過程，因為它提供了對過去經驗的抽象。框架能高度抽象同一領域內的問題，進而降低開發難度和強度。因此，在軟件開發過程中把框架和模式配合起來使用，可以極大地提高軟件的重用。框架是軟件，而設計模式是軟件的知識 第九章 進行體系結構設計 ?

簡述軟件體系結構的作用：1。軟件體系結構的表示有助于對計算機系統開發感興趣的各方（共利益者）開發交流；2。體系結構突出了早期設計決策，這些決策對隨后的所有軟件工程工作有深遠的影響，同時對系統作為一個可運行實體的最后成功有重要作用。3。體系結構“構建了一個相對小的，易于理解的模型，該模型描述了系統如何構成以及其構建如何一起工作”

? 軟件體系結構的典型分類：以數據為中心，數據流體系結構，調用和返回體系結構，面向對象體系結構，層次體系結構（以圖例來說明）?

體系結構環境圖所包含的要素，以圖例來說明 第十二章 軟件測試策略

? 簡述軟件測試策略的螺旋模型：單元測試，集成測試，確認測試，系統測試 ?

簡述單元測試中驅動程序和樁程序的作用：驅動程序只是一個“主程序”，它接收測試用例數據，將這些數據傳遞給（將要測試的）構件并打印相關結果。樁程序的作用是替換那些從屬于將要測試的構件或被其調用的構件。? 集成測試的兩種方式：一步到位和增量集成

? 試以圖例描述自頂向下集成測試方法的過程 ? 簡述確認測試的兩種主要方法：α測試和β測試 ? 系統測試的主要方法：恢復測試，安全測試，壓力測試，性能測試 ? 三種調試方法：蠻力法，回溯法，原因排除法 第十三章 測試戰術

? 好的測試所具有的特性：1。好的測試具有較高的發現錯誤的可能性；2。好的測試是不冗余的；3。好的測試應該是“最佳品種”4。好的測試應該既不太簡單也不太復雜。?

黑盒測試的定義：所謂黑盒測試是指在完全不考慮程序的內部結構和處理過程的前提下,在程序接

口進行的測試,它只檢查程序功能是否能按照規格說明書的規定正常使用,程序是否能適當地接受輸入數據產生正確的輸出信息,并且保持外部信息的完整性.因此,又稱為功能測試。

白盒測試的定義：所謂白盒測試就是在知道產品內部工作過程或程序內部結構和處理過程的前提下, 檢驗產品內部動作是否按照規格說明書的規定正常進行或按照程序內部的邏輯測試程序,檢驗程序中的每條通路是否都能按照預定要求正確工作的測試方法.因此白盒測試又稱為結構測試或邏輯測試。? 基本路徑測試的環復雜度計算方法和獨立路徑集合的識別V(G)=E-N+2;其中E為流圖 的邊數，N為流圖的結點數。? 控制結構測試的3個主要方法：條件測試，數據流測試，循環測試 ? 黑盒測試的兩個主要方法：等價類劃分，邊界值分析 ? 類級可應用的測試方法：隨機測試，劃分測試 ? 面向對象的類級劃分測試的主要方法：基于狀態劃分，基于屬性劃分，基于類別劃分 ?

以圖例說明從行為模型導出測試用例 第十四章 產品度量

? 軟件度量為產品內部屬性的質量評估提供了一種（定量）方法，從而可以是軟件工程師在產品開發出來之前進行質量評估

? 軟件測量的5個主要活動：公式化，收集，分析，解釋，反饋 ?

面向目標的軟件測量（GQM范型）的內容：1。確定特定過程活動的明確的測量目標或將要評估的產品特性；2。定義一組必須回答的問題以達到目標；3。確定被良好公式化的度量以幫助回答這些問題 ?

有效軟件度量的屬性1。簡單的和可計算的2。在經驗上和直覺上有說服力3。一致的和客觀的4。單位和量綱的使用是一致的。5。編程語言的獨立性6。高質量反饋的有效機制

第四篇：軟件工程知識點總結

軟件工程知識點總結

軟件工程知識點總結

1.軟件危機：指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。

2.軟件危機產生的原因：1.軟件本身的復雜性、難衡量的特點；2.軟件開發與維護的方法不正確。

3.軟件的定義：計算機程序、方法、規則、相關文檔資料以及在計算機上運行程序時所必需的數據

4.軟件不是程序，軟件是程序、數據以及相關文檔的完整集合。

5.程序是能夠完成預定功能和性能的可執行的指令序列；數據是使程序能夠適當地處理信息的數據結構；文檔是開發、使用和維護程序所需要的圖文資料。

6.軟件生命周期：一個軟件從定義、開發、使用和維護，直到最終被廢棄所經歷的一個漫長時期。

7.軟件開發的過程：

①問題定義：確定要求解決的問題是什么

②可行性研究：決定該問題是否存在一個可行的解決辦法

③需求分析：深入了解用戶的要求，在要開發的目標系統必須做什么問題和用戶取得完全一致的看法。④概要設計：概括回答怎樣實現目標系統。概要設計又叫邏輯設計、總體設計、高層設計。

⑤詳細設計：把解法具體化，設計出程序的詳細規格說明。詳細設計也叫模塊設計、底層設計。⑥編碼和單元測試：編寫程序的工作量只占軟件開發全部工作量的10%－20％。

⑦綜合測試：軟件測試的工作量通常占軟件開發全部工作量的40%－50％。

⑧軟件維護：軟件維護的費用通常占軟件總費用的55％－70%。

①②③為軟件定義時期，④⑤⑥⑦為軟件開發階段。④⑤為系統設計，⑥⑦為系統實現。

中國國家標準《計算機軟件開發規范》將軟件生命周期分為：可行性研究與計劃，需求分析，概要設計，詳細設計，實現，組裝測試，確認測試，使用和維護8個階段。

8.軟件工程：是指導計算機軟件開發和維護的工程學科。軟件工程采用工程的概念、原理、技術和方法來開發和維護軟件，結合正確的管理技術和先進可靠的技術方法，經濟地開發出高質量的軟件，并有效地維護它。

9.軟件工程方法學：方法、工具和過程。普遍使用的是傳統方法學和面向對象方法學。

10.瀑布模型：唯一被廣泛采用的模型，各階段間具有順序性和依賴性：前階段完成才能進行下一階段。文檔驅動。

原型模型：快速建立一個能反映用戶主要需求的原型系統讓用戶試用，并根據用戶意見修改原型。原型的用途是獲知用戶真正需求，一旦需求確定，原型將被拋棄。當用戶對系統的目標不是很清楚，難以定義需求，可用此法。

增量模型：也叫漸增模型。整個軟件被分解成許多各增量構件，設計人員分批地逐步向用戶提交產品，每次用戶都得到一個滿足部分需求的可運行產品。優點：能在短時間內向用戶提交可完成部分工作的有用產品，易于維護。

螺旋模型：使用原型及其他方法來盡量降低風險。它類似于原型法，不過在每個階段之前都增加了風險分析過程。

螺旋模型適用于內部開發的大規模軟件項目。螺旋模型的優勢在于它是風險驅動的。

V型模型：從需求分析就開始編寫測試計劃一直到系統交付。需求分析對應于驗收測試，概要設計對應于系統測試，詳細設計對應于集成測試，編碼對應于單元測試，這樣先產生計劃再執行測試,在測試的每個階段都進行審查.噴泉模型：是一種典型的適合于面向對象范型的過程模型，支持開發過程中的迭代。

瀑布模型注重凍結需求的理念、Up模型注重增量迭代/用例驅動、V型模型講究質量保證理念、Xp模型講究溝通。

11.實體－關系圖（E－R圖），用于建立數據模型，其中包含了實體、關系、屬性。

12.數據流圖（DFD）：描繪信息流和數據輸入輸出的移動過程。是結構化分析過程中使用的主要建模工具。功能建模。

13.狀態轉換圖：通過描述系統的狀態及引起系統狀態轉換的事件，表示系統的行為，提供了行為建模的機制。

3/29/2013 1

軟件工程知識點總結

14.數據字典：描述在數據模型、功能模型和行為模型中出現的數據對象和控制信息的特征，給出這些對象的精確定義。數據字典是分析模型的核心，通常使用CASE工具來創建和維護數據字典。

15.結構化設計的幾個階段：數據設計、體系結構設計、接口設計、過程設計（是詳細設計階段的主要任務）。

結構設計屬于概要設計階段。接口設計（包括I/O設計）和過程設計屬于詳細設計階段。人機界面設計屬接口設計。

16.基本設計原理：模塊化、抽象、逐步求精、信息隱藏、模塊獨立（功能獨立，和其它模塊沒有過多相互作用）。

模塊獨立的好處：易開發、易測試、易維護。模塊獨立程度的衡量標準：內聚和耦合。

17.內聚衡量模塊內各元素之間結合的緊密程度。耦合衡量不同模塊之間連接的緊密程度。

數據耦合→控制耦合→公共環境耦合→內容耦合（高）

（低內聚）偶然內聚→邏輯內聚→時間內聚→（中內聚）過程內聚→通信內聚→（高內聚）順序內聚→功能內聚

模塊獨立性設計原則：提高內聚，降低耦合18.表示軟件結構：層次圖、HIPO圖、結構圖。過程設計：程序流程圖、盒圖（N－S圖）、PAD圖、判定表、判定樹。

19.軟件測試分：單元測試和綜合測試。軟件項目管理從項目計劃開始，第一項計劃活動是估算。

白盒測試：也稱結構測試，邏輯驅動測試，基于代碼的測試，測試程序內部的邏輯結構和過程性細節，前期使用。

黑盒測試：即功能測試，在程序接口進行測試，測試后期使用。具體辦法：等價劃分、邊界值分析、錯誤推測。

20.IEEE 1058.1給出軟件項目管理計劃的框架；ISO9000－3標準適用于軟件的開發、供應、維護；

ISO/IEC12207是指導軟件過程實施的標準；ISO/IEC TR 15504是軟件過程評估標準。軟件質量保證－SQA。

21.軟件重用是降低軟件整體成本、提高軟件質量和開發生產率的合理有效途徑。

可重用的軟件成分：軟件的技術表示（結構模型、設計和代碼）、文檔、測試數據、與過程相關的任務（如審查）。

22.軟件可移植性：指軟件從某一環境移植到另一環境下的難易程度。為方便移植，要盡量采用通用的程序設計語言。

3/29/2013 2

第五篇：軟件工程知識點總結

第二章軟件生命周期和過程模型

2.1軟件生命周期是什么？分為哪幾個階段？每個階段干什么？

2.2.1瀑布模型

1、軟件生命周期是指軟件產品從考慮其概念開始到交付使用，直至最終退役為止的整個過程。軟件生命周期可以劃分為軟件定義、軟件開發和運行維護三個時期。

2、軟件生命周期各個階段的任務：

時期階段任務

軟件定義確定待開發的軟件系統要做什么

問題定義確定解決什么問題

可行性研究確定“上一個階段所確定的問題是否有行得通的解決方法”需求分析確定“目標系統必須做什么”這個問題

軟件開發具體設計和實現軟件

概要設計確定“怎樣實現目標系統”

詳細設計在概要設計階段只是以一種比較抽象概括的方式給出解

決問題的辦法。在詳細設計階段，需要將解法具體化，確

定“應該怎樣具體實現這個系統”

編碼和單元測試 在前面階段的基礎上，寫出正確的、易理解、易維護的程

序。

綜合測試通過各種類型的測試及調試，發現功能、邏輯和實現上可

能存在的缺陷，使軟件達到預定的要求。（其中最基本的測試是集成測試和驗收測試）

運行和維護根據軟件運行中的問題，對其進行各種修改，使系統能持

久地滿足用戶的需要。

3、瀑布模型

瀑布模型包含了各項軟件工程活動，即（概念階段）制訂開發計劃、進行需求分析、（開發階段）軟件設計、程序編碼、測試、（維護階段）運行維護。通常情況下，運 行維護活動是一個具有最長生命周期的階段。

4.原型模型

原型一般是指對某種產品進行模擬的初始版本或原始模型。在使用原型時，可以采取兩種不同的策略：廢棄策略、追加策略。

5、螺旋模型

基本思想：使用原型及其他方法來降低風險。包含4種活動：制定計劃、風險分析、實施工程、客戶評價。

6、噴泉模型(迭代模型)

噴泉模型認為軟件開發具有的兩個固有屬性：迭代性、無間隙性。他認為軟件開發過程的各個階段是相互重疊，多次反復的，就像噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。

7、增量模型（漸增模型）

主要面向市場開發

第三章 可行性研究

1、可行性研究考慮哪幾方面的研究？（4）

a）技術可行性；b）經濟可行性；c）操作可行性；d）社會可行性

第四章 需求工程

1、需求工程經過哪4步？P63小結

需求開發過程可以按照需求獲取、分析建模、編寫規格說明書、需求評審。

2、需求分析階段要完成的任務就是最終形成一份經開發方和用戶認可或達成共識的軟件需求規格說明書。

第五章 結構化方法

數據流圖 結構圖

第六章 面向對象基礎

1、類和對象的區別面向對象和面向過程區別

第七章 面向對象分析

時序圖 用例模型

第八章 軟件設計基礎

第九章 結構化設計方法

第十章 面向對象的設計

1、面向對象的設計，各設計原則是什么？及各原則是干什么的？

a）單一職責原則(SRP)：單一職責就是要求系統中一個具體設計元素（類）只完成某一

類功能（職責），盡可能避免出現一個“復合”功能的類----在同

一個類中完成多個不同的功能。關鍵詞：提高內聚性

b）開放—封閉原則（OCP）：基本思想是：“不用修改原有類就能擴展一個類的行為”。

關鍵詞： 抽象封裝多態

c）Liskov替換原則（LSP）：子類應當可以替換父類并出現在父類能夠出現的任何地方。d）接口隔離原則（ISP）：采用多個與特定客戶類有關的接口比采用一個通用的涵蓋多個業務方法的接口更好。

e）依賴倒置原則（DIP）：是指應用系統中的高層模塊不應依賴于底層模塊，兩者都應該依賴于抽象：抽象不應依賴于細節實現，實現細節應該依賴與抽象。

第十一章 用戶界面設計

1、用戶界面設計原則：

a）置用戶于控制之下；b）減少用戶的記憶負擔；c）保持界面一致

第十二章 軟件實現

12．3軟件編碼規范（要求：會修改代碼）

注釋一般遵守以下原則：1）注釋的縮進要與相應代碼一致；2）每行注釋用至少一個空行分開；3）對于所有的常量、變量、數據結構聲明，在聲明時都必須加以注釋，說明其含義。

4）頭文件、源文件的頭部都應進行注釋。

命名規范：類名，類型名，方法名大小寫混用，首字母大寫，分個字母大寫枚舉類型，常量名，宏名全部大寫

指針變量p

全局變量g

靜態變量s

第十三章軟件測試

1、黑盒測試：又稱為功能性測試或行為測試，完全不考慮程序的內部結構和處理過程。

2、白盒測試：又稱透明測試，已知產品內部工作過程，通過測試檢驗產品內部動作是否按

照產品規格說明的規定正常進行。

3、動態測試：指通常意義上的測試，即使用和運行軟件。

4、靜態測試：指測試不運行的部分，只是靜態檢查和審核。

5、靜態黑盒測試：測試產品說明書屬于靜態黑盒測試。（產品說明書是書面文檔，而不是

可執行程序，因此是靜態的。可利用書面文檔進行黑盒測試認真查找其中的缺陷）。

6、動態黑盒測試：不深入代碼細節測試軟件的方法。（它是動態的，因為程序在運行，同

時它是黑盒的。）

7、靜態白盒測試：是在不執行軟件的條件下有條理地仔細檢查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時稱為結構化分析。（這是在程序員編碼完成后立馬完成的，由程序員做的）。

8、動態白盒測試：是指利用查看代碼功能和實現方法得到的信息，來確定哪些需要測試、哪些不需要測試、如何展開測試。它也稱為結構化檢測。（有軟件測試員設計和執行）。

9、軟件測試的一般過程？各過程測試哪個方面？

單元測試：（白盒測試，一般有程序員實施）

也稱模塊測試，是針對軟件設計的最小單元程序模塊進行測試的工作。目的是發現模塊內部的軟件缺陷，修改這些缺陷使其代碼能夠正確運行。

集成測試：（只能是黑盒測試）

也稱組裝測試，它的任務是按照一定的策略對單元測試的模塊進行組裝，并在組裝過程中進行模塊接口與系統功功能測試。

確認測試:（Alpha測試和Beta測試）

也稱有效性測試，目的是驗證軟件的有效性，即驗證軟件的功能和性能及其他

特性是否符合用戶要求。

系統測試：主要任務：測試軟件系統是否能與硬件協調工作，測試與其他軟件協調運行的情況。

第十四章 軟件維護

1、軟件維護的一般類型？（4類，最重要的是：完善性維護）

軟件維護的分類：糾錯性維護、適應性維護、完善性維護和預防性維護

第十五章軟件項目管理

1、軟件配置管理和基線的概念。

軟件過程的輸出信息可以分為3個主要類別：計算機程序，描述計算機程序的文檔，數據。這些項包含了所有在軟件過程中產生的信息，總稱為軟件配置。

基線：是一個軟件配置管理的概念，幫助我們在不嚴重阻礙合理變化的情況下來控制變化。定義：已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，并且只能通過正式的變化控制過程的改變。

軟件配置管理（SCM）：是一套管理軟件開發和軟件維護以及各種中間軟件產品的方法和規則。可被視為應用于整個軟件過程的軟件質量保證活動。