軟件工程簡答題復(fù)習(xí)

簡答題

1、簡述什么是軟件危機(jī)？

軟件危機(jī)是指在計算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。這些

問題絕不僅僅是"不能正常運(yùn)行的〃軟件才具有的，實際上幾乎所有軟件都不同程

度地存在這些問題。主要表現(xiàn)，如：對軟件開發(fā)成本和進(jìn)度估計不準(zhǔn)確、軟件產(chǎn)

品的質(zhì)量靠不住、用戶對“已完成的〃軟件系統(tǒng)不滿意、軟件開發(fā)速度跟不上、軟

件不可維護(hù)以及沒有適當(dāng)?shù)奈臋n資料等。

2、簡述軟件質(zhì)量保證的目標(biāo)。

(1)事前預(yù)防工作，例如，著重于缺陷預(yù)防而不是缺陷檢查。

⑵盡量在剛剛引入缺陷時即將其捕獲，而不是讓缺陷擴(kuò)散到下一個階段。

(3)作用于過程而不是最終產(chǎn)品，因此它有可能會帶來廣泛的影響與巨大的收益

(4)貫穿于所有的活動之中，而不是只集中于一點。

3、簡述螺旋模型的優(yōu)缺點。

螺旋模型具有以下優(yōu)點：

(1)設(shè)計上的靈活性，可以在項目的各個階段進(jìn)行變更。

(2)以小的分段來構(gòu)建大型系統(tǒng)，使成本計算變得簡單容易。

(3)客戶始終參與每個階段的開發(fā)，保證了項目不偏離正確方向以及項目的可控

性。

(4)隨著項目推進(jìn)，客戶始終掌握項目的最新信息，從而使得客戶能夠和管理層

有效地交0

⑸對可選方案和約束條件的強(qiáng)調(diào)有利于己有軟件的重用，也有助于把軟件質(zhì)作

為軟件開發(fā)的一個重要目標(biāo)。

螺旋模型也存在以下缺點：

螺旋模型是風(fēng)險驅(qū)動的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險評估經(jīng)驗和

這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險：當(dāng)項目實際上正在走向災(zāi)難時，開

發(fā)人員可能還以為一切正常。所以，很難讓用戶確信這種演化方法的結(jié)果是可以

控制的。

4、哪些方法有助于提高軟件的可理解性？

以下方法都有助于提高軟件的可理解性

(1)模塊化

(2)詳細(xì)的設(shè)計文檔

⑶結(jié)構(gòu)化設(shè)計方法

⑷程序內(nèi)部的文檔

⑸良好的高級程序設(shè)計語言

5、什么是單元測試？其內(nèi)容包括哪些？

單元測試又稱為模塊測試，是針對軟件設(shè)計的最小單位一程序模塊，進(jìn)行正確性

檢驗的測試工作，其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。它需要從程

序內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，多個模塊可以平行地獨立進(jìn)行。

內(nèi)容：1、模塊接口測試

2、局部數(shù)據(jù)結(jié)閡測試

3、重要路徑測試

4、錯誤處理測試

5、邊界測試

6、簡述PAD的優(yōu)點。

⑴使用PAD符號所設(shè)計出來的程序不能進(jìn)行隨意的控制轉(zhuǎn)移，必然是結(jié)構(gòu)化程

序。

(2)PAD圖描繪程序結(jié)構(gòu)清晰，圖中豎線的總條數(shù)就是程序的層次數(shù)，所以用PAD

圖表現(xiàn)程序邏輯易讀、易懂、易記。

(3)容易將PAD圖自動轉(zhuǎn)換為高級語言源程序。

⑷PAD圖既可以表示程序邏輯，也可用于描繪數(shù)據(jù)結(jié)構(gòu)。

⑸PAD圖的符號支持自頂向下、逐步求精方法的使用。

7、簡述問題定義的規(guī)范化要求。

(1)重視問題定義，不能把其當(dāng)作一件小事

(2)客觀、全面的定義，不能避重就輕、偷工減料

(3)清楚問題定義的工作內(nèi)容，不能把問題定義當(dāng)作解決方法

⑷深入分析，抓住問題的本質(zhì)

(5)嚴(yán)格評審

8、簡述瀑布模型的優(yōu)缺點。

瀑布模型具有下列優(yōu)點：

(1)可強(qiáng)迫開發(fā)人員采用規(guī)范化的方法

⑵嚴(yán)格地規(guī)定了每個階段必須提交的文檔。

⑶要求每個階段交出的所有產(chǎn)品都必須是經(jīng)過驗證的。

瀑布模型的缺點：

(1)由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟

件產(chǎn)品不能真正滿足用戶的需要。

(2)瀑布模型只適用于項目開始時需求已確定的情況。

9、數(shù)據(jù)流圖的基本圖形符號包括哪些？

(1)外部實體：數(shù)據(jù)輸入源或數(shù)據(jù)輸出匯點，不是目標(biāo)系統(tǒng)的一部分，只是外圍

環(huán)境中的實體部分，包括人員、組織、部門或其他相關(guān)的軟件系統(tǒng)。

⑵數(shù)據(jù)流：數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑，數(shù)據(jù)沿箭頭方向流動。數(shù)據(jù)流可以在加

工和加工之間也可以在數(shù)據(jù)存儲和加工之間傳送，數(shù)據(jù)流在數(shù)據(jù)存儲和加工之間

傳送時含義明確，數(shù)據(jù)存儲就足以說明數(shù)據(jù)流，所以不必命名。同一數(shù)據(jù)流圖上

不能有同名數(shù)據(jù)流。

⑶加工：又稱數(shù)據(jù)處理，是對數(shù)據(jù)對象進(jìn)行某些處理或變換，其名稱簡要的描

述完成什么加工。流入加工的可以是多個數(shù)據(jù)流，流出加工的也可以是多個數(shù)據(jù)

流。

(4)數(shù)據(jù)存儲：又稱數(shù)據(jù)文件，可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。流入

數(shù)據(jù)存儲的數(shù)據(jù)流表示寫入數(shù)據(jù)，流出數(shù)據(jù)存儲的數(shù)據(jù)流表示讀出數(shù)據(jù)。

10、簡述用例圖中《communicate》關(guān)系、《include》關(guān)系、《extend》關(guān)系和泛

化關(guān)系。

參與者和用例之間通過無方向的直線相連，并通過《communicate》關(guān)系進(jìn)行通

信

啟例0和用例之間可能存在包含關(guān)系，表示一個用例所執(zhí)行的功能中總是包括被包

含用例的功能，通過有向直線將具有包含關(guān)系的兩用例相連，箭頭指向被包含用

例，并在直線上標(biāo)明《include》關(guān)系。

用例和用例之間還可能存在擴(kuò)展關(guān)系，表示一個用例的執(zhí)行可能需要有其他用例

的功能來擴(kuò)展，但基本用例的功能并不依賴于擴(kuò)展用例，通過有向直線將具有擴(kuò)

展關(guān)系的兩用例相連，箭頭指向基本用例，并在直線上標(biāo)明《extend》關(guān)系。參

與者和參與者以及用例和用例之間可能存在泛化關(guān)系(也稱為繼承關(guān)系)，泛化

關(guān)系用帶空心箭頭的直線表示，箭頭指向被繼承方。

11、面向?qū)ο蟪绦蚣蓽y試策略主要有哪幾種？

⑴協(xié)作集成

⑵基于集成

⑶高頻集成

⑷基于事件(消息)的集成

⑸基于使用的集成

⑹客戶機(jī)/服務(wù)器的集成

⑺分布式集成

12、簡述過程設(shè)計階段的目標(biāo)和任務(wù)。

過程設(shè)計階段的目標(biāo)是確定具體的實現(xiàn)所要求的系統(tǒng)，從而在軟件實現(xiàn)階段可以

把這個系統(tǒng)設(shè)計直接翻譯成某種程序設(shè)計語言編碼實現(xiàn)，所以過程設(shè)計最重要的

是盡可能地將各模塊的處理過程描述得簡明易懂。

過程設(shè)計的任務(wù)包括：

⑴算法設(shè)計

(2)數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)和數(shù)據(jù)操作的設(shè)計

⑶輸入/輸出格式設(shè)計

(4)編寫過程設(shè)計說明書

13、什么是增量模型？有哪些優(yōu)點？

增量模型也稱為漸增模型，增量式開發(fā)該方法使得描述活動、開發(fā)活動和有效性

驗證括動交織在一起。系統(tǒng)的開發(fā)是建立一系列的版本(增量)，每個版本添加部

分功能到先前的版本中。

增量模型具有以下優(yōu)點：

(1)能在最套時間內(nèi)向用戶提交可完成一些有用的工作產(chǎn)品，即從第1個增量交

付之日起，用戶就能做一些有用的工作。

(2)逐步增加產(chǎn)品的功能可以使用戶有較充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減

少一個全新的軟件可能給用戶組織帶來的沖擊。

(3)項目失敗的風(fēng)險較低，雖然在某些增量構(gòu)件中可能遇到一些問題，但其他增

量構(gòu)件將能夠成功地交付給客戶。

(4)優(yōu)先級最高的服務(wù)首先交付，然后再將其他增量逐次集成進(jìn)來。因此，最重

要的系統(tǒng)服務(wù)將接受最多的測試。

14、簡述提高代碼重用性程序設(shè)計準(zhǔn)則。

⑴提高方法的內(nèi)聚

⑵減小方法的規(guī)模

⑶保持方法的一致

⑷把策略與實現(xiàn)分開

⑸全面覆蓋

⑹盡量不使用全局信息

⑺利用繼承機(jī)制

(8)使用委托機(jī)制

15、簡述需求獲取的原則和步驟。

需求獲取應(yīng)遵循以下原則：

(1)深入淺出的原則。就是說，需求獲取要盡可能全面、細(xì)致，獲取的需求是個

⑵私流程/基線的原則。在與用戶云流的過程中，應(yīng)該用流程將所有的內(nèi)容串

起來，如信息組織結(jié)構(gòu)、處理規(guī)則等，這樣便于交流溝通

步驟：

⑴深入了解應(yīng)用領(lǐng)域，開發(fā)高層的業(yè)務(wù)模型

(2)定義項目范圍和高層需求

⑶識別用戶類型和用戶代表

⑷獲取具體的需求

⑸確定目標(biāo)系統(tǒng)的業(yè)務(wù)工作流

⑹需求整理與總結(jié)

16、簡述關(guān)系數(shù)據(jù)庫管理系統(tǒng)的優(yōu)缺點。

優(yōu)點：

⑴謔供了各種最基本的數(shù)據(jù)管理功能

⑵為多種應(yīng)用提供了一致的接口。

(3)標(biāo)準(zhǔn)化的語言(大多數(shù)商品化關(guān)系數(shù)據(jù)庫管理系統(tǒng)都使用SQL語言)。

缺點：

⑴運(yùn)行開銷大。

⑵不能滿足高級應(yīng)用的需求

⑶與程序設(shè)計語言的連接不自然

17、簡述結(jié)構(gòu)化設(shè)計的原則。

⑴模塊化

(2)低耦合、高內(nèi)聚

⑶抽象

⑷信息隱藏

⑸一致性

18、簡述UML的特點。

⑴UML支持面向?qū)ο蠹夹g(shù)的主要概念，提供了一批基本的模型元素的表示圖形

和方法，能簡潔明了地表達(dá)面向?qū)ο蟮母鞣N概念，而且容易掌握和使用。

⑵UML統(tǒng)一了各種方法對不同類型的系統(tǒng)不同開發(fā)階段以及不同內(nèi)部概念的不

同觀點，從而有效的消除了各種建模語言之間不必要的差異。

⑶UML建模能力比其它面向?qū)ο蠼７椒ǜ鼜?qiáng)。

⑷UML是一種建模語言，而不是一個開發(fā)過程。

⑸用UML建立的軟件系統(tǒng)模型可以用Java、VC++、dephi等任何一種面向?qū)ο?/p>

的程序設(shè)計來實現(xiàn)。

19、什么是白盒測試？白盒測試的目的是什么？

白盒測試是一種測試方法，盒子指的是被測試的軟件，白盒是指盒子內(nèi)部是可見

的，即清楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的。在系統(tǒng)中出現(xiàn)一個缺陷往往

不是由一個原因?qū)е碌?，就需要通過白盒測試,提前把每個功能模塊都測試一次。

白盒測試的目的一般包括：

⑴保證程序中所有關(guān)鍵路徑都被測試到，防止系統(tǒng)投入使用后用戶發(fā)現(xiàn)系統(tǒng)問

題。

(2)便于衡量測試的完整性，即有沒有把某個功能點的所有可能情況都測試到。

(3)可以測試到程序中所有的真分支、假分支

(4)檢查局部數(shù)據(jù)結(jié)構(gòu)的有效性

⑸檢查程序的異常處理能力

⑹檢查代碼是否遵循編碼規(guī)范

20、通常，繼承關(guān)系的映射有哪三種方法？

(1)將基類和所有子類映射到一張表，表中包含基類和子類的所有屬性。這種方

法適用于子類的個數(shù)很少(一般只有兩個)，子類和基類的屬性都比較少的情況。

(2)將每個子類映射到一張表，沒有基類表.在每個子類的表中包括基類的所有

屬性。這種方法適用于子類的個數(shù)不多，基類屬性比較少的情況。

⑶將基類映射到一張表，每個子類映射到一張表。在基類對應(yīng)的表中定義主鍵,

而在子類定義的表中定義外鍵。這種方法適用于子類的屬性和基類的屬性都比較

多的情況。

21、簡述體系結(jié)構(gòu)的設(shè)計應(yīng)遵循啟發(fā)式設(shè)計原則，

⑴提高模塊獨立性

⑵模塊規(guī)模適中

⑶結(jié)構(gòu)圖的深度和寬度話中

⑷結(jié)構(gòu)圖中扇入和扇出適當(dāng)

⑸模塊的作用域應(yīng)在控制域之內(nèi)

⑹模塊功能的完善化

⑺消除重復(fù)功能，改善軟件結(jié)構(gòu)

22、簡述軟件測試的原則。

⑴應(yīng)當(dāng)把〃盡早地和不斷地進(jìn)行軟件測試〃作為軟件開發(fā)者的座右銘。

⑵測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。

⑶應(yīng)由第三方人員從事測試工作。

⑷在設(shè)計測試用例時，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件

(5)注意測試中的錯誤群集現(xiàn)象

⑹嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性。

⑺妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告。

23、什么是快速原型模型?有哪些優(yōu)缺點？

快速原型模型又稱原型模型，是增量模型的另一種形式。它是在開發(fā)真實系統(tǒng)之

前，構(gòu)造一個原型，即快速建立起來可以在計算機(jī)上運(yùn)行的程序，它所能完成的

功能往往是最終產(chǎn)品能完成的功能的一個子集。然后，在該原型的基礎(chǔ)上，逐漸

完成整個系統(tǒng)的開發(fā)工作。

快速原型模型具有如下優(yōu)點：

(1)有助于滿足用戶的真實需求。

(2)原型系統(tǒng)已經(jīng)通過與用戶的交互而得到驗證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠

正確地描述用戶需求。

⑶軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行。

(4)因為規(guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不

會因為發(fā)現(xiàn)規(guī)格說明文檔的錯誤而進(jìn)行較大的返工。

(5)開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，因此，在設(shè)計和編碼階段

發(fā)生錯誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯

誤的可能性。

(6)快速原型的突出特點是〃快速〃。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，

以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。

24、簡述軟件危機(jī)爆發(fā)的原因。

(1)軟件開發(fā)過程的進(jìn)展情況較難衡量，很難檢驗開發(fā)的正確性且軟件開發(fā)的質(zhì)

量也較難評價，因此，控制軟件開發(fā)過程相當(dāng)困難：軟件維護(hù)常常意味著修改原

來的設(shè)計，維護(hù)的費(fèi)用十分驚人，使得軟件較難維護(hù)。

⑵軟件開發(fā)的過程是多人分工合作，相當(dāng)多的軟件開發(fā)人員對軟件的開發(fā)和維

護(hù)存在不少錯誤的觀念，或多或少采用了一些錯誤的方法和技術(shù)，這是造成軟件

危機(jī)的主要原因。

(3)開發(fā)和管理人員只重視開發(fā)而輕視問題的定義，使軟件產(chǎn)品無法滿足用戶的

要求。

(4)軟件管理技術(shù)不能滿足現(xiàn)代軟件開發(fā)的需要，沒有統(tǒng)一的軟件質(zhì)量管理規(guī)范。

(5)在軟件的開發(fā)和維護(hù)關(guān)系問題上存在錯誤的觀念。軟件維護(hù)工作通常是在軟

件完成之后進(jìn)行的，因此是極端艱巨復(fù)雜的工作。

25、簡述單例模式的要點。

從單例模式的要點：

一是某個類只能有一個實例；

二是它必須自行創(chuàng)建這個實例；

三是它必須自行向整個系統(tǒng)提供這個實例。

從具體實現(xiàn)角度來說，就是以下三點：

一是單例模式的類只提供私有的構(gòu)造函數(shù)；

二是類定義中含有一個該類的靜態(tài)私有對象；

三是該類提供了一個靜態(tài)的公有的方法，用于創(chuàng)建或獲取它本身的靜態(tài)私有對象。

26、軟件維護(hù)存在哪些問題？

1)理解別人寫的程序通常非常困難，而且困難程度隨著軟件配置成分的減少而

迅速增加。如果僅有程序代碼沒有說明文檔，則會出現(xiàn)嚴(yán)重的問題。

(2)需要維護(hù)的軟件往往沒有合格的文檔，或者文檔資料顯著不足。認(rèn)識到軟件

必須有文檔僅僅是第一步，容易理解的并且和程序代碼完全一致的文檔才真正有

價值。

(3)當(dāng)要求對軟件進(jìn)行維護(hù)時，不能指望由開發(fā)人員給人們仔細(xì)說明軟件。由于

維護(hù)階段持續(xù)的時間很長，因此，當(dāng)需要解釋軟件時，往往原來寫程序的人已經(jīng)

不在附近了。

(4)絕大多數(shù)軟件在設(shè)計時沒有考慮將來的修改。除非使用強(qiáng)調(diào)模塊獨立原理的

設(shè)計方法學(xué)否則修改軟件既困難又容易發(fā)生差錯。

(5)軟件維護(hù)不是一項吸引人的工作。形成這種觀念很大程度上是因為維護(hù)工作

經(jīng)常遭受挫折。

27、簡述PDL語言的優(yōu)點。

⑴可以作為注釋直接插在源程序中間。

(2)可以使用普通的文字處理系統(tǒng)，很方便地完成PDL的編輯。

⑶可以自動由PDL生成程序代碼

28、軟件維護(hù)報告包含哪些信息？

⑴滿足維護(hù)要求表中提出的要求所需要的工作

⑵維護(hù)要求的性質(zhì)

⑶這項要求的優(yōu)先次序

⑷與修改有關(guān)的事后數(shù)據(jù)

29、簡述敏捷開發(fā)的原則。

⑴快速迭代

⑵讓測試人員和開發(fā)者參與需求討論

⑶編寫可測試的需求文檔

⑷多溝通，盡量減少文檔

⑸做好產(chǎn)品原型

⑹及早考慮測試

30、IOS9126軟件質(zhì)量模型。

它由6個特性和27個子特性組成，這個模型是軟件質(zhì)量標(biāo)準(zhǔn)的核心，對于大部

分的軟件，都可以考慮從這幾個方面著手進(jìn)行測評。

(1)功能性：軟件所實現(xiàn)的功能達(dá)到它的設(shè)計規(guī)范和滿足用戶需求的程度。

⑵可靠性：在滿足一定條件的應(yīng)用環(huán)境中軟件能夠正常維持其工作的能力。

(3)可用性：對于一個軟件，用戶在學(xué)習(xí)、操作和理解過程中所做努力的程度。

(4)效率：在規(guī)定條件下，用軟件實現(xiàn)某種功能所需的計算機(jī)資源(包括時間)的有

效程度。

⑸維護(hù)性：當(dāng)環(huán)境改變或軟件運(yùn)行發(fā)生故障時，為使其恢復(fù)正常運(yùn)行所做努力

的程度。

(6)可移植性：為使一個軟件從現(xiàn)有運(yùn)行平臺向另一個運(yùn)行平臺過度所做努力的

程度。

客觀題

1、引起軟件改變的原因主要有：運(yùn)行環(huán)境變化、需求變化、系統(tǒng)有錯。

2、在UML中，通過建立類圖來表示對象模型。

3、面對對象設(shè)計模型中的數(shù)據(jù)結(jié)構(gòu)對應(yīng)分析模型中的屬性。

4、面對對象分析模型包括：功能模型、對象模型、動態(tài)模型。

5、各種軟件維護(hù)的類型中最重要的是完善性維護(hù)。

6、在類圖中，表示繼承關(guān)系的是空心箭頭。

7,軟件生命周期的最后一個階段是軟件維護(hù)。

8、屬于軟件項目管理白勺是：軟件過程能力評估、風(fēng)險管理、質(zhì)量監(jiān)控。

9、UML的全稱是UnifiedModelingLanguage。

10、張三辦公用的那臺計算機(jī)是實例。

11、冰箱和海爾冰箱這兩個事物之間是泛也關(guān)系。

12、通過執(zhí)行對象的操作改變該對象的屬性，必須通過消息的傳遞。

13、UML中，包圖是一種分組機(jī)制。

14、信息隱藏概念與模塊的獨立性概念直接相關(guān)。

15、UML中描述類與類之間關(guān)系的圖是類圖。

1G、軟件維護(hù)產(chǎn)生的副作用，是指因修改軟件而產(chǎn)生的錯誤。

17、屬于軟件開發(fā)項E風(fēng)險的是：關(guān)鍵技術(shù)人員流失。

18、軟件按照設(shè)計要求，在規(guī)定時間和條件下不出故障，持續(xù)運(yùn)行的程度。屬于

可靠性軟件質(zhì)量要素。

19、屬于面向?qū)ο蠓椒▋?yōu)點的是：穩(wěn)定性好、可宜用性好、與人類習(xí)慣的思維方

法一致。

20、類的行為應(yīng)該屬于狀態(tài)圖進(jìn)行測試。

21、類是比較理想的可重用軟構(gòu)件。

22、對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作封裝于對象的統(tǒng)一體中。

23、軟件維護(hù)時，對測試階段未發(fā)現(xiàn)的錯誤進(jìn)行測試、診斷、定位、糾錯，直至

修改的回歸測試過程稱為改正性維護(hù)。

24、針對應(yīng)用系統(tǒng)運(yùn)行期間的數(shù)據(jù)特點，修改他的排序算法使其更高效，屬于軟

件維護(hù)中的完善性。

25、軟件項后贏度管理有許多方法,衛(wèi)圈圖的優(yōu)點是標(biāo)明了各任務(wù)的計劃進(jìn)度

和當(dāng)前進(jìn)度，能動態(tài)地反映軟件開發(fā)進(jìn)展情況，但難以反映多個任務(wù)之間存在的

復(fù)雜的邏輯關(guān)系。

26、“淘寶定時確認(rèn)收貨”屬于面向?qū)ο笤O(shè)計任務(wù)中的時鐘驅(qū)動型任務(wù)。

27、UML中能夠描述對象的行為，反映出對象的狀態(tài)與事件關(guān)系的是狀態(tài)圖。

28、為適應(yīng)軟件運(yùn)行環(huán)境的變化而修改軟件的活動稱為適應(yīng)性維護(hù)。

29、系統(tǒng)分析員Analyst在做儲蓄系統(tǒng)的需求開發(fā)是，發(fā)現(xiàn)：①“取款”用例、

②“查詢余額”用例、③“更改密碼”用例都要使用、④“驗證卡號和密碼”用

例的功能。那么①②③三個用例與用例④的關(guān)系是包金逸。

30、面向?qū)ο蟮闹饕卣鞒龑ο笪ㄒ恍?、封裝、繼承外，還有多態(tài)性。

31、面向?qū)ο笤O(shè)計模型中算法對應(yīng)分析模型中的方法。

32、面向?qū)ο蠓椒ǖ挠美龍D中，q遑n出關(guān)系表示一個用例的執(zhí)行可能需要用其

他用例的功能來擴(kuò)展。

33、軟件開發(fā)成本度量主要指軟件開發(fā)項目所需的財務(wù)性成本的估算。主要方法

包括：周期估算法、類比估算法、細(xì)分估算法。

34、UML中表示對象之間交互的圖為順序圖。

35、火車是一種路上交通工具。火車和陸上交通工具之間的關(guān)系是博區(qū)的關(guān)

系。

36、版本控制是軟件配置管理的核心功能。

37、面向?qū)ο蠓治鲞^程中，獲取用戶需求的是：參觀用戶的.1：作流程，觀察用戶

的操作；與同行、專家交談，聽取他們的意見；向用戶群體發(fā)調(diào)查問卷。

38、在ATM自動取款機(jī)的工作模型中（用戶通過輸入正確的用戶資料，從銀行

取錢的過程），取款不是參與者,ATM取款機(jī)，用戶，ATM取款機(jī)管理員是參與

者。

39、面向?qū)ο蟮姆治龇椒ㄖ饕墙⑷惸Ｐ停簩ο竽Ｐ汀⒔换ツＰ?、用例模型?/p>

40、定時消息推送屬于皿驅(qū)動任務(wù)。

41>用例圖中，<extend〉;<<extend>>;獷展關(guān)系表示一個用例的執(zhí)行可能需要由

其他用例的功能來擴(kuò)展。

42、繼承是子類自動地共享基類；父類中定義的數(shù)據(jù)和方法的機(jī)制。

43、軟件的可移植性是指把程序從一種計算環(huán)境轉(zhuǎn)移到另一種計算環(huán)境的難易

程度。

44、小鳥牌熱水器和熱水器這兩個事物之間是繼圣美系。

45、類和類之間的靜態(tài)關(guān)系包括：泛化關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系。

46、用例圖中，<include>;<<indude>>;包含關(guān)系表示一個用例所執(zhí)行的功能總是

包括被包含用例的功能。

47、用例圖中的參與者是與系統(tǒng)交互的外部實體。

48、如果發(fā)現(xiàn)一個類中對象都是由另一個類中多個對象組合而成，那么這兩個類

就具有聚合關(guān)系。

49、C++是在C語言的基礎(chǔ)上開發(fā)的一種面向?qū)λ斓木幊陶Z言。

50、由于軟件是邏輯產(chǎn)品，軟件質(zhì)量較容易直接度量。（X）

51、任務(wù)子系統(tǒng)中的協(xié)調(diào)任務(wù)不僅作協(xié)調(diào)工作，也可以讓其再承擔(dān)其他服務(wù)工作。

（X）

52