系統(tǒng)架構(gòu)設(shè)計(jì)師-系統(tǒng)開發(fā)基礎(chǔ)

1、系統(tǒng)架構(gòu)設(shè)計(jì)師 - 系統(tǒng)開發(fā)基礎(chǔ)（ 總分： 45.00 ，做題時(shí)間： 90 分鐘 ）、單項(xiàng)選擇題（ 總題數(shù)： 37，分?jǐn)?shù)： 45.00）1. 需求工程活動(dòng)產(chǎn)生軟件運(yùn)行特征的規(guī)約，指明軟件和其他系統(tǒng)元素的接口并建立A. 數(shù)據(jù)流圖和數(shù)據(jù)字典 B 程序流程圖C.體系結(jié)構(gòu)模型 D 軟件必須滿足的約束條件（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：需求工程活動(dòng)產(chǎn)生軟件運(yùn)行特征的規(guī)約，指明軟件和其他系統(tǒng)元素的接口并建立軟件必須滿足的約 束條件。數(shù)據(jù)流圖和數(shù)據(jù)字典只是這些約束條件的表示方法，而程序流程圖和體系結(jié)構(gòu)模型是設(shè)計(jì)階段的 工作。2. 有兩種需求定義的方法嚴(yán)格定義和原型定義，在關(guān)于這兩種方法的描述

2、中，不正確的是_A. 嚴(yán)格定義方法假定所有的需求都可以預(yù)先定義B 嚴(yán)格定義方法假定軟件開發(fā)人員與用戶之間的溝通存在障礙C. 原型定義方法認(rèn)為需求分析中不可避免地要出現(xiàn)很多反復(fù)D. 原型定義方法強(qiáng)調(diào)用戶在軟件開發(fā)過(guò)程中的參與和決策（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：嚴(yán)格定義 （ 預(yù)先定義 ）是目前采用較多的一種需求定義方法。在采用嚴(yán)格定義的傳統(tǒng)的結(jié)構(gòu)化開發(fā)方 法中，各個(gè)工作階段排列成一個(gè)理想的線性開發(fā)序列，在每一工作階段中，都用上一階段所提供的完整、 嚴(yán)格的文檔作為指導(dǎo)文件，因此它本質(zhì)上是一種順序型的開發(fā)方法。在傳統(tǒng)的結(jié)構(gòu)化開發(fā)中，需求的嚴(yán)格定義建立在以下的基本假設(shè)上： 所有需求都能

3、夠被預(yù)先定義。假設(shè)意味著，在沒(méi)有實(shí)際系統(tǒng)運(yùn)行經(jīng)驗(yàn)的情況下，全部的系統(tǒng)需求均可通 過(guò)邏輯推斷得到。這對(duì)某些規(guī)模較小、功能簡(jiǎn)單的系統(tǒng)是可能的，但對(duì)那些功能龐大、復(fù)雜且較大的系統(tǒng) 顯然是困難的。即使事先做了深入細(xì)致的調(diào)查和分析，當(dāng)用戶見(jiàn)到新系統(tǒng)的實(shí)際效果時(shí)，也往往會(huì)改變?cè)?先的看法，會(huì)提出修改或更進(jìn)一步增加系統(tǒng)功能的要求，所以再好的預(yù)先定義技術(shù)也會(huì)經(jīng)常反復(fù)。這是因 為人們對(duì)新事物的認(rèn)識(shí)與理解將隨著直觀、實(shí)踐的過(guò)程進(jìn)一步加深，這是與人類認(rèn)識(shí)世界的客觀規(guī)律相一 致的。所以，能夠預(yù)先定義出所有需求的假設(shè)在許多場(chǎng)合是不能成立的。 開發(fā)人員與用戶之間能夠準(zhǔn)確而清晰地交流。假設(shè)認(rèn)為，用戶與開發(fā)人員之間，雖然每人

4、都有自己的專 業(yè)、觀點(diǎn)、行話，但在系統(tǒng)開發(fā)過(guò)程中可以使用圖形 / 文檔等通信工具進(jìn)行交流，進(jìn)行清晰、有效的溝通， 這種溝通是必不可少的?？墒牵趯?shí)際開發(fā)中，往往對(duì)一些共同的約定，每個(gè)人可能都會(huì)產(chǎn)生自己的理解 和解釋。即使采用結(jié)構(gòu)化語(yǔ)言、判定樹、判定表等工具，仍然存在精確的、技術(shù)上的不嚴(yán)密感。這將導(dǎo)致 人們有意無(wú)意地帶有個(gè)人的不同理解而各行其是，所以在多學(xué)科、多行業(yè)人員之間進(jìn)行有效的通信交流是 有一定困難的。 采用圖形 / 文字可以充分體現(xiàn)最終系統(tǒng)。在使用嚴(yán)格定義需求的開發(fā)過(guò)程中，開發(fā)人員與用戶之間交流、 通信的主要工具是定義報(bào)告，包括敘述文字、圖形、邏輯規(guī)則和數(shù)據(jù)字典等技術(shù)工具。它們都是靜止的

5、、 被動(dòng)的，不能實(shí)際表演，很難在用戶頭腦中形成一個(gè)具體的形象。因此，要用靜止的圖形 / 文字描述來(lái)體現(xiàn) 一個(gè)動(dòng)態(tài)的系統(tǒng)是比較困難的。除了所論述的情況外，上述基本假設(shè)還將導(dǎo)致嚴(yán)格定義的結(jié)構(gòu)化開發(fā)方法存在以下缺陷。 首先是文檔量大，由于在結(jié)構(gòu)化方法的每個(gè)階段都必須寫出規(guī)范、嚴(yán)密的各種文檔，這些文檔雖然有助于 開發(fā)人員之間、用戶與開發(fā)人員問(wèn)的通信交流，有助于開發(fā)過(guò)程的規(guī)范化，但由于編寫文檔花費(fèi)大量人力 和時(shí)間，導(dǎo)致系統(tǒng)開發(fā)周期增大。其次是開發(fā)過(guò)程可見(jiàn)性差，來(lái)自用戶的反饋太遲。由于在需求定義、系 統(tǒng)設(shè)計(jì)階段都不能在用戶終端顯示新系統(tǒng)的實(shí)際效果，一直到系統(tǒng)實(shí)現(xiàn)階段結(jié)束，用戶才有機(jī)會(huì)通過(guò)對(duì)新 系統(tǒng)的實(shí)際操

6、作和體會(huì)來(lái)提出他們對(duì)新系統(tǒng)的看法和意見(jiàn)，但此時(shí)整個(gè)開發(fā)已近尾聲，若想修改前幾段的 工作或修改需求定義，都將付出較大的代價(jià)，有時(shí)這種修改甚至?xí)?dǎo)致整個(gè)系統(tǒng)的失敗。綜上所述，需求的嚴(yán)格定義的基本假設(shè)在許多情況下并不成立，傳統(tǒng)的結(jié)構(gòu)化方法面臨著一些難以跨越的 障礙。為此，需要探求一種變通的方法。原型方法以一種與嚴(yán)格定義法截然不同的觀點(diǎn)看待需求定義問(wèn)題。原型化的需求定義過(guò)程是一個(gè)開發(fā)人員 與用戶通力合作的反復(fù)過(guò)程。從一個(gè)能滿足用戶基本需求的原型系統(tǒng)開始，允許用戶在開發(fā)過(guò)程中提出更 好的要求，根據(jù)用戶的要求不斷地對(duì)系統(tǒng)進(jìn)行完善，它實(shí)質(zhì)上是一種迭代的循環(huán)型的開發(fā)方式。 采用原型方法時(shí)需要注意以下幾個(gè)問(wèn)題：

7、 并非所有的需求都能在系統(tǒng)開發(fā)前被準(zhǔn)確地說(shuō)明。事實(shí)上，要想嚴(yán)密、準(zhǔn)確地定義任何事情都是有一定難度的，更不用說(shuō)是定義一個(gè)龐大系統(tǒng)的全部需求。用戶雖然可以敘述他們所需最終系統(tǒng)的目標(biāo)及大致功 能，但是對(duì)某些細(xì)節(jié)問(wèn)題卻往往不可能十分清楚。 一個(gè)系統(tǒng)的開發(fā)過(guò)程， 無(wú)論對(duì)于開發(fā)人員還是用戶來(lái)說(shuō)， 都是一個(gè)學(xué)習(xí)和實(shí)踐的過(guò)程，為了幫助他們?cè)谶@個(gè)過(guò)程中提出更完善的需求，最好的方法就是提供現(xiàn)實(shí)世 界的實(shí)例原型，對(duì)原型進(jìn)行研究、實(shí)踐，并進(jìn)行評(píng)價(jià)。 項(xiàng)目參加者之間通常都存在交流上的困難，原型提供了克服該困難的一個(gè)手段。用戶和開發(fā)人員通過(guò)屏 幕、鍵盤進(jìn)行對(duì)話和討論、 交流， 從他們自身的理解出發(fā)來(lái)測(cè)試原型， 一個(gè)具體的

8、原型系統(tǒng)， 由于直觀性、 動(dòng)態(tài)性而使得項(xiàng)目參加者之間的交流上的困難得到較好的克服。需要實(shí)際的、可供用戶參與的系統(tǒng)模型。雖然圖形和文字描述是一種較好的通信交流工具，但是，其最 大缺陷是缺乏直觀的、感性的特征，因而不易理解對(duì)象的全部含義。交互式的系統(tǒng)原型能夠提供生動(dòng)的規(guī) 格說(shuō)明，用戶見(jiàn)到的是一個(gè)“活”的、實(shí)際運(yùn)行著的系統(tǒng)。實(shí)際使用在計(jì)算機(jī)上運(yùn)行的系統(tǒng)，顯然比理解 紙面上的系統(tǒng)要深刻得多。 有合適的系統(tǒng)開發(fā)環(huán)境。隨著計(jì)算機(jī)硬件、軟件技術(shù)和軟件工具的迅速發(fā)展，軟件的設(shè)計(jì)與實(shí)現(xiàn)工作越來(lái)越方便， 對(duì)系統(tǒng)進(jìn)行局部性修改甚至重新開發(fā)的代價(jià)大大降低。 所以，對(duì)大系統(tǒng)的原型化已經(jīng)成為可能。 反復(fù)是完全需要和值得提

9、倡的，需求一旦確定，就應(yīng)遵從嚴(yán)格的方法。對(duì)系統(tǒng)改進(jìn)的建議來(lái)自經(jīng)驗(yàn)的發(fā) 展，應(yīng)該鼓勵(lì)用戶改進(jìn)他們的系統(tǒng)，只有做必要的改變后，才能使用戶和系統(tǒng)問(wèn)獲得更加良好的匹配，所 以，從某種意義上說(shuō)，嚴(yán)格定義需求的方法實(shí)際上抑制了用戶在需求定義以后再改進(jìn)的要求，這對(duì)提高最 終系統(tǒng)的質(zhì)量是有害的。另一方面，原型方法的使用并不排除嚴(yán)格定義方法的運(yùn)用，當(dāng)通過(guò)原型并在演示 中得到明確的需求定義后，應(yīng)采用行之有效的結(jié)構(gòu)化方法來(lái)完成最終系統(tǒng)的開發(fā)。3. 軟件需求分析產(chǎn)生軟件操作特征的規(guī)格說(shuō)明，指明軟件和其他系統(tǒng)元素的接口，建立軟件必須滿足的約 束。下面對(duì)于軟件需求分析的描述，不正確的是 。A. 分析員研究系統(tǒng)規(guī)約和軟件項(xiàng)

10、目計(jì)劃，并在系統(tǒng)語(yǔ)境內(nèi)理解軟件和復(fù)審， 從而生成計(jì)劃軟件范圍的估算B. 需求分析使得系統(tǒng)工程師能夠刻畫出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立軟件 必須滿足的約束C. 經(jīng)過(guò)仔細(xì)的需求分析活動(dòng)，分析員能夠得到詳細(xì)的系統(tǒng)規(guī)約D. 需求分析能夠?yàn)檐浖O(shè)計(jì)者提供可被翻譯成數(shù)據(jù)、體系結(jié)構(gòu)、界面和過(guò)程設(shè)計(jì)的模型分?jǐn)?shù)： 1.00 )A.B.C. VD.解析：需求分析使得系統(tǒng)工程師能夠刻畫出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立 軟件必須滿足的約束。需求分析能夠?yàn)檐浖O(shè)計(jì)者提供可被翻譯成數(shù)據(jù)、體系結(jié)構(gòu)、界面和過(guò)程設(shè)計(jì)的模 型。分析員研究系統(tǒng)規(guī)約和軟件項(xiàng)目計(jì)劃，并在系統(tǒng)語(yǔ)境內(nèi)理解

11、軟件和復(fù)審，從而生成計(jì)劃軟件范圍的估 算。4. 質(zhì)量功能部署（QFD）是一種將客戶要求轉(zhuǎn)化成軟件需求的技術(shù)。OFD的目的是最大限度地提升軟件工程過(guò)程中客戶的滿意度。為了這個(gè)目標(biāo)，OFD確認(rèn)了 3類需求，常規(guī)需求、 和意外需求。A. 期望需求B .基礎(chǔ)需求C .顯式需求D .功能需求（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：OFD確認(rèn)了 3類需求，分別是基本需求（常規(guī)需求）、期望需求和意外需求（興奮需求）。其中期望需 求指的是那些隱含在產(chǎn)品或系統(tǒng)中，可能由于非?；A(chǔ)以至于用戶沒(méi)有顯式說(shuō)明的需求。5. 需求分析的任務(wù)是借助于當(dāng)前系統(tǒng)的物理模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)“做什么”的問(wèn)

12、 題。 并不是需求分析的實(shí)現(xiàn)步驟之一。A. 獲得當(dāng)前系統(tǒng)的物理模型 B 抽象出當(dāng)前系統(tǒng)的邏輯模型C. 建立目標(biāo)系統(tǒng)的邏輯模型 D 確定目標(biāo)實(shí)現(xiàn)的具體技術(shù)路線（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析： 2 典型試題分析”中試題 21的分析。6. 希賽網(wǎng)軟件開發(fā)團(tuán)隊(duì)欲開發(fā)一套管理信息系統(tǒng)，在項(xiàng)目初期，用戶提出了軟件的一些基本功能，但是沒(méi) 有詳細(xì)定義輸入、處理和輸出需求。在這種情況下，該團(tuán)隊(duì)在開發(fā)過(guò)程應(yīng)采用。A. 瀑布模型B .增量模型C.原型開發(fā)模型 D 快速應(yīng)用程序開發(fā)（RAD）（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：瀑布模型也稱為生命周期法，是生命周期法中最常用的開發(fā)模型，它把軟

13、件開發(fā)的過(guò)程分為軟件計(jì) 劃、需求分析、軟件設(shè)計(jì)、程序編碼、軟件測(cè)試和運(yùn)行維護(hù) 6 個(gè)階段，規(guī)定了它們自上而下、相互銜接的 固定次序，如同瀑布流水，逐級(jí)下落。瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地 位，它提供了軟件開發(fā)的基本框架。瀑布模型主要用于需求明確或很少變更的項(xiàng)目。原型法適合于用戶沒(méi)有肯定其需求的明確內(nèi)容的時(shí)候。它是先根據(jù)已給的和分析的需求，建立一個(gè)原始模 型，這是一個(gè)可以修改的模型 （在生命周期法中，需求分析成文檔后一般不再進(jìn)行修改 ）。在軟件開發(fā)的各 個(gè)階段都把有關(guān)信息相互反饋，直至模型的修改，使模型漸趨完善。在這個(gè)過(guò)程中，用戶的參與和決策加 強(qiáng)了，最終的結(jié)果是更適

14、合用戶的要求。這種原型法成敗的關(guān)鍵及效率的高低，關(guān)鍵在于模型的建立及建 模的速度。增量模型融合了瀑布模型的基本成分（重復(fù)地應(yīng)用）和原型的迭代特征。采用隨著日程時(shí)間的進(jìn)展而交錯(cuò)的線性序列。每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”。當(dāng)使用增量模型時(shí)，第一個(gè)增量往往是核 心的產(chǎn)品，即實(shí)現(xiàn)了基本的需求，但很多補(bǔ)充的特性還沒(méi)有發(fā)布。核心產(chǎn)品交用戶使用，使用和/或評(píng)估的結(jié)果是下一個(gè)增量的開發(fā)計(jì)劃。該計(jì)劃包括對(duì)核心產(chǎn)品的修改，使其能更好地滿足用戶的需要，并發(fā)布一 些新增的特點(diǎn)和功能。這個(gè)過(guò)程在每一個(gè)增量發(fā)布后不斷重復(fù)，直到產(chǎn)生最終的完善產(chǎn)品。RAD是一個(gè)線性順序的軟件開發(fā)模型，強(qiáng)調(diào)極短的開發(fā)周期和可復(fù)用

15、程序構(gòu)件的開發(fā)。RAD莫型是瀑布模型的一個(gè)高速變種，通過(guò)使用基于構(gòu)件的建造方法獲得了快速開發(fā)。如果需求理解得很好，且約束了項(xiàng)目范 圍，RAD莫型使得一個(gè)開發(fā)組能夠在很短時(shí)間內(nèi)創(chuàng)建岀功能完善的系統(tǒng)。RAD方法主要用于信息系統(tǒng)應(yīng)用軟件的開發(fā)，它包含業(yè)務(wù)建模、數(shù)據(jù)建模、處理建模、應(yīng)用生成、測(cè)試及反復(fù)5個(gè)階段。7. 基于構(gòu)件的開發(fā)（CBD）模型，融合了 模型的許多特征。該模型本質(zhì)是演化的，采用迭代方法開發(fā)軟件。A. 瀑布B .快速應(yīng)用開發(fā)（RAD）C. 螺旋D 形式化方法（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：基于構(gòu)件的開發(fā)模型利用模塊化方法將整個(gè)系統(tǒng)模塊化，并在一定構(gòu)件模型的支持下復(fù)用構(gòu)件庫(kù)中

16、 的一個(gè)或多個(gè)軟件構(gòu)件，通過(guò)組合手段高效率、高質(zhì)量地構(gòu)造應(yīng)用軟件系統(tǒng)的過(guò)程。基于構(gòu)件的開發(fā)模型融合了螺旋模型的許多特征，本質(zhì)上是演化形的，開發(fā)過(guò)程是迭代的?；跇?gòu)件的開 發(fā)模型由軟件的需求分析和定義、架構(gòu)設(shè)計(jì)、構(gòu)件庫(kù)建立、應(yīng)用軟件構(gòu)建及測(cè)試和發(fā)布5個(gè)階段組成。統(tǒng)一軟件開發(fā)過(guò)程是一種基于面向?qū)ο蠹夹g(shù)的軟件開發(fā)過(guò)程，其特點(diǎn)是“用例驅(qū)動(dòng)，以架構(gòu)為核心，迭代 并增量”。統(tǒng)一軟件開發(fā)過(guò)程定義了4種通用的開發(fā)階段，它們按照過(guò)程順序分別是：起始階段、（8）構(gòu)建階段和（9），其中在構(gòu)建階段主要產(chǎn)生的文檔有（10）。（分?jǐn)?shù)：3.00 ）（1）.A 分析階段B 細(xì)化階段C 設(shè)計(jì)階段D 交付階段（分?jǐn)?shù)：1.00 ）

17、A.B. VC.D.解析：.A 分析階段B 細(xì)化階段C 設(shè)計(jì)階段D 交付階段（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：.A .初始用戶手冊(cè)B.用例模型C .項(xiàng)目計(jì)劃D .設(shè)計(jì)模型（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：統(tǒng)一過(guò)程適合于大、中型項(xiàng)目的開發(fā)，可以分為4個(gè)順序的階段，分別是初始階段、細(xì)化階段、構(gòu)建階段和移交階段。初始階段的任務(wù)是為系統(tǒng)建立業(yè)務(wù)模型并確定項(xiàng)目的邊界。在初始階段，必須識(shí)別所有與系統(tǒng)交互的外部 實(shí)體，定義系統(tǒng)與外部實(shí)體交互的特性。 在這個(gè)階段中所關(guān)注的是整個(gè)項(xiàng)目的業(yè)務(wù)和需求方面的主要風(fēng)險(xiǎn)。 對(duì)于建立在原有系統(tǒng)基礎(chǔ)上的開發(fā)項(xiàng)目來(lái)說(shuō)，初始階段可能很短。細(xì)化階段的任務(wù)是分

18、析問(wèn)題領(lǐng)域，建立健全的架構(gòu)基礎(chǔ)，淘汰項(xiàng)目中最高風(fēng)險(xiǎn)的元素。在細(xì)化階段，必須 在理解整個(gè)系統(tǒng)的基礎(chǔ)上，對(duì)架構(gòu)做岀決策，包括其范圍、主要功能和諸如性能等非功能需求，同時(shí)為項(xiàng) 目建立支持環(huán)境。在構(gòu)建階段，要開發(fā)所有剩余的構(gòu)件和應(yīng)用程序功能，把這些構(gòu)件集成為產(chǎn)品，并進(jìn)行詳細(xì)測(cè)試。從某種 意義上說(shuō)，構(gòu)建階段是一個(gè)制造過(guò)程，其重點(diǎn)放在管理資源及控制操作，以優(yōu)化成本、進(jìn)度和質(zhì)量。構(gòu)建 階段的主要任務(wù)是通過(guò)優(yōu)化資源和避免不必要的報(bào)廢和返工，使開發(fā)成本降到最低；完成所有所需功能的 分析、開發(fā)和測(cè)試，快速完成可用的版本；確定軟件、場(chǎng)地和用戶是否已經(jīng)為部署軟件做好準(zhǔn)備。在構(gòu)建 階段，開發(fā)團(tuán)隊(duì)的工作可以實(shí)現(xiàn)某種程度的

19、并行。即使是較小的項(xiàng)目，也通常包括可以相互獨(dú)立開發(fā)的構(gòu) 件，從而使各團(tuán)隊(duì)之間實(shí)現(xiàn)并行開發(fā)。當(dāng)基線已經(jīng)足夠完善，可以安裝到最終用戶實(shí)際環(huán)境中時(shí)，則進(jìn)入交付階段。交付階段的重點(diǎn)是確保軟件對(duì)最終用戶是可用的。交付階段的主要任務(wù)是進(jìn)行 B測(cè)試，制作產(chǎn)品發(fā)布版本；對(duì)最終用戶支持文檔定稿; 按用戶的需求確認(rèn)新系統(tǒng)；培訓(xùn)用戶和維護(hù)人員；獲得用戶對(duì)當(dāng)前版本的反饋，基于反饋調(diào)整產(chǎn)品，如進(jìn) 行調(diào)試、性能或可用性的增強(qiáng)等。根據(jù)產(chǎn)品的種類，交付階段可能非常簡(jiǎn)單，也可能非常復(fù)雜。例如，發(fā) 布現(xiàn)有桌面產(chǎn)品的新發(fā)布版本可能十分簡(jiǎn)單，而替換一個(gè)國(guó)家的航空交通管制系統(tǒng)可能就非常復(fù)雜。交付 階段結(jié)束時(shí)也要進(jìn)行技術(shù)評(píng)審，評(píng)審目標(biāo)是

20、否實(shí)現(xiàn)，是否應(yīng)該開始演化過(guò)程，用戶對(duì)交付的產(chǎn)品是否滿意 等。8. 敏捷軟件過(guò)程強(qiáng)調(diào)：讓客戶滿意和軟件盡早增量發(fā)布；小而高度自主的項(xiàng)目團(tuán)隊(duì)；非正式的方法；最小 化軟件工程工作產(chǎn)品，以及整體精簡(jiǎn)開發(fā)。 不是采用這種軟件開發(fā)過(guò)程的原因。A. 難以提前預(yù)測(cè)哪些需求是穩(wěn)定的和哪些需求會(huì)變化B. 對(duì)于軟件項(xiàng)目開發(fā)來(lái)說(shuō)，設(shè)計(jì)和實(shí)現(xiàn)可以做到基本分離C. 從制訂計(jì)劃的角度來(lái)看，分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試并不容易預(yù)測(cè)D. 可執(zhí)行原型和部分實(shí)現(xiàn)的可運(yùn)行系統(tǒng)是了解用戶需求和反饋的有效媒介（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：敏捷軟件過(guò)程主要有四大價(jià)值觀：個(gè)體和交互勝過(guò)過(guò)程和工具；可以工作的軟件勝過(guò)面面俱到的文 檔

21、；客戶合作勝過(guò)合同談判；響應(yīng)變化勝過(guò)遵循計(jì)劃。這種價(jià)值觀的前提是軟件需求是難以提前確定的， 而是會(huì)不斷地發(fā)生變化，可以采用可執(zhí)行原型和部分實(shí)現(xiàn)的可運(yùn)行系統(tǒng)來(lái)了解用戶需求，通過(guò)用戶的反饋 來(lái)明確需求。從制訂計(jì)劃的角度來(lái)看，分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試并不容易預(yù)測(cè)。逆向工程過(guò)程的抽象層次是指可從源代碼中抽取出來(lái)的設(shè)計(jì)信息的精制程度。抽象層次分為4層，其中,“最低層”抽象能夠?qū)邕^(guò)程的設(shè)計(jì)表示文檔，“低層”抽象能夠?qū)绯绦蚝蛿?shù)據(jù)結(jié)構(gòu)信息，“中層”能夠?qū)С觯?2），“高層”抽象能夠?qū)С?（13）。（分?jǐn)?shù)：2.00 ）（1）.A 實(shí)體關(guān)系模型B 程序和文檔結(jié)構(gòu)信息C.全部文檔信息 D .數(shù)據(jù)流和控制流模型（分

22、數(shù)：1.00 ）A.B.C.D. V解析：.A .實(shí)體關(guān)系模型B .模塊結(jié)構(gòu)圖C.完全的數(shù)據(jù)流圖 D 全部文檔信息（分?jǐn)?shù)：1.00 ）B.C.D.解析：逆向工程過(guò)程能夠?qū)С鲞^(guò)程的設(shè)計(jì)模型 （實(shí)現(xiàn)級(jí)，一種低層的抽象 ） 、程序和數(shù)據(jù)結(jié)構(gòu)信息 （結(jié)構(gòu)級(jí)， 稍高層次的抽象）、對(duì)象模型、數(shù)據(jù)和控制流模型 （功能級(jí)，相對(duì)高層的抽象）和uML狀態(tài)圖和部署圖（領(lǐng)域 級(jí)，高層抽象 ） 。隨著抽象層次增高，完備性就會(huì)降低。抽象層次越高，它與代碼的距離就越遠(yuǎn)，通過(guò)逆向 工程恢復(fù)的難度就越大，而自動(dòng)工具支持的可能性相對(duì)變小，要求人參與判斷和推理的工作增多。所以本題選D、A。關(guān)于逆向工程的詳細(xì)說(shuō)明，請(qǐng)參看“ 軟件開發(fā)

23、方法”中的逆向工程。9. 詳細(xì)的項(xiàng)目范圍說(shuō)明書是項(xiàng)目成功的關(guān)鍵。 不應(yīng)該屬于范圍定義的輸入。A. 項(xiàng)目章程B 項(xiàng)目范圍管理計(jì)劃C.批準(zhǔn)的變更申請(qǐng) D 項(xiàng)目文檔管理方案（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：在初步項(xiàng)目范圍說(shuō)明書中已文檔化的主要的可交付物、假設(shè)和約束條件的基礎(chǔ)上準(zhǔn)備詳細(xì)的項(xiàng)目范 圍說(shuō)明書，是項(xiàng)目成功的關(guān)鍵。范圍定義的輸入包括以下內(nèi)容： 項(xiàng)目章程。如果項(xiàng)目章程或初始的范圍說(shuō)明書沒(méi)有在項(xiàng)目執(zhí)行組織中使用，同樣的信息需要進(jìn)一步收集 和開發(fā)，以產(chǎn)生詳細(xì)的項(xiàng)目范圍說(shuō)明書。 項(xiàng)目范圍管理計(jì)劃。 組織過(guò)程資產(chǎn)。 批準(zhǔn)的變更申請(qǐng)。所以項(xiàng)目文檔管理方案不屬于范圍定義的輸入。10. 項(xiàng)目時(shí)間

24、管理包括使項(xiàng)目按時(shí)完成所必需的管理過(guò)程， 活動(dòng)定義是其中的一個(gè)重要過(guò)程。 通常可以使用 來(lái)進(jìn)行活動(dòng)定義。A. 魚骨圖B .工作分解結(jié)構(gòu)（WBS）C.層次分解結(jié)構(gòu)D .功能分解圖（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：項(xiàng)目時(shí)間管理包括使項(xiàng)目按時(shí)完成所必需的管理過(guò)程。項(xiàng)目時(shí)間管理中的過(guò)程包括：活動(dòng)定義、活 動(dòng)排序、活動(dòng)的資源估算、活動(dòng)歷時(shí)估算、制定進(jìn)度計(jì)劃及進(jìn)度控制。為了得到工作分解結(jié)構(gòu)（Work Breakdown Structure , WBS中最底層的交付物，必須執(zhí)行一系列的活動(dòng)。對(duì) 這些活動(dòng)的識(shí)別及歸檔的過(guò)程就是活動(dòng)定義。魚骨圖 （ 又稱為 Ishikawa 圖 ） 是一種發(fā)現(xiàn)問(wèn)題

25、“根本原因”的方法，通常用來(lái)進(jìn)行因果分析。11. 軟件的逆向工程是一個(gè)恢復(fù)設(shè)計(jì)的過(guò)程，從現(xiàn)有的程序中抽取數(shù)據(jù)、體系結(jié)構(gòu)和過(guò)程的設(shè)計(jì)信息。 逆向工程的完備性可以用在某一個(gè)抽象層次上提供信息的詳細(xì)程度來(lái)描述，在大多數(shù)情況下，抽象層次越高， 完備性就越低。下列可以通過(guò)逆向工程恢復(fù)的制品中，完備性最低的是。A.過(guò)程的設(shè)計(jì)模型 B .程序和數(shù)據(jù)結(jié)構(gòu)C.對(duì)象模型、數(shù)據(jù)和控制流 D . uML狀態(tài)圖和部署圖（分?jǐn)?shù):1.00）A.B.C.D. V解析：逆向工程過(guò)程及用于實(shí)現(xiàn)該過(guò)程的工具的抽象層次是指可從源代碼中抽取出來(lái)的設(shè)計(jì)信息的精密程度。理想地，抽象層次應(yīng)該盡可能高，即逆向工程過(guò)程應(yīng)該能夠?qū)邕^(guò)程的設(shè)計(jì)表示

26、（一種低層的抽象）；程序和數(shù)據(jù)結(jié)構(gòu)信息（稍高一點(diǎn)層次的抽象）；數(shù)據(jù)和控制流模型（一種相對(duì)高層的抽象）；以及實(shí)體關(guān)系模 型（一種高層抽象）。隨著抽象層次增高，軟件工程師獲得更有助于理解程序的信息。在試題給出的4個(gè)選項(xiàng)中，UMLL犬態(tài)圖和部署圖可以用來(lái)描述實(shí)體之間的關(guān)系，因此，其層次最高，完備 性最低。12. 把整個(gè)軟件開發(fā)流程分成多個(gè)階段，每一個(gè)階段都由目標(biāo)設(shè)定、風(fēng)險(xiǎn)分析、開發(fā)和有效性驗(yàn)證及評(píng)審構(gòu)成。A. 原型模型B .瀑布模型C .螺旋模型D . V模型（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：本題考查開發(fā)模型基礎(chǔ)知識(shí)，解這類題，需要對(duì)常見(jiàn)模型的核心特點(diǎn)有所了解。下面對(duì)選項(xiàng)中岀現(xiàn)的模型做一

27、個(gè)簡(jiǎn)單的總結(jié)。原型模型：針對(duì)需求不明確、原型可拋棄。瀑布模型：階段明晰、無(wú)法應(yīng)對(duì)需求不明確的情況。螺旋模型：瀑布模型+演化模型、循環(huán)、里程碑、風(fēng)險(xiǎn)分析。V模型：測(cè)試模型、測(cè)試全程介入、測(cè)試計(jì)劃提前。把以上特點(diǎn)與題目描述進(jìn)行對(duì)比，可以發(fā)現(xiàn)本題所描述的是螺旋模型。在RUP中采用“4+1”視圖模型來(lái)描述軟件系統(tǒng)的體系結(jié)構(gòu)。在該模型中，最終用戶側(cè)重于（18），系統(tǒng)工程師側(cè)重于（19）。（分?jǐn)?shù)：2.00 ）(1).A.實(shí)現(xiàn)視圖B.進(jìn)程視圖C .邏輯視圖D .部署視圖（分?jǐn)?shù)：1.00 )A.B.C.VD.解析:(2).A.實(shí)現(xiàn)視圖B.進(jìn)程視圖C .邏輯視圖D .部署視圖（分?jǐn)?shù)：1.00 )A.B.C.D.

28、V解析:在RUP中采用“4+1”視圖模型來(lái)描述軟件系統(tǒng)的體系結(jié)構(gòu)?！?+1 ”視圖包括邏輯視圖、實(shí)現(xiàn)視圖、進(jìn)程視圖、部署視圖和用例視圖。分析人員和測(cè)試人員關(guān)心的是系統(tǒng)的行為，因此會(huì)側(cè)重于用例視圖；最終用戶關(guān)心的是系統(tǒng)的功能，因此 會(huì)側(cè)重于邏輯視圖；程序員關(guān)心的是系統(tǒng)的配置、裝配等問(wèn)題，因此會(huì)側(cè)重于實(shí)現(xiàn)視圖；系統(tǒng)集成人員關(guān) 心的是系統(tǒng)的性能、 可伸縮性、 吞吐率等問(wèn)題， 因此會(huì)側(cè)重于進(jìn)程視圖； 系統(tǒng)工程師關(guān)心的是系統(tǒng)的發(fā)布、 安裝、拓?fù)浣Y(jié)構(gòu)等問(wèn)題，因此會(huì)側(cè)重于部署視圖。13. 軟件的橫向重用是指重用不同應(yīng)用領(lǐng)域中的軟件元素。 是一種典型的、原始的橫向重用機(jī)制。A. 對(duì)象B .構(gòu)件C .標(biāo)準(zhǔn)函數(shù)庫(kù)

29、D .設(shè)計(jì)模式（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：軟件重用是指在兩次或多次不同的軟件開發(fā)過(guò)程中重復(fù)使用相同或相似軟件元素的過(guò)程。按照重用 活動(dòng)是否跨越相似性較少的多個(gè)應(yīng)用領(lǐng)域，軟件重用可以區(qū)別為橫向重用和縱向重用。橫向重用是指重用 不同應(yīng)用領(lǐng)域中的軟件元素，例如數(shù)據(jù)結(jié)構(gòu)、分類算法和人機(jī)界面構(gòu)建等。標(biāo)準(zhǔn)函數(shù)是一種典型的、原始 的橫向重用機(jī)制?？v向重用是指在一類具有較多公共性的應(yīng)用領(lǐng)域之間進(jìn)行軟部件重用?？v向重用活動(dòng)的 主要關(guān)鍵點(diǎn)是域分析：根據(jù)應(yīng)用領(lǐng)域的特征及相似性預(yù)測(cè)軟部件的可重用性。14. 下列關(guān)于不同軟件開發(fā)方法所使用的模型的描述中，正確的是 。A. 在進(jìn)行結(jié)構(gòu)化分析時(shí)，必須使用

30、數(shù)據(jù)流圖和軟件結(jié)構(gòu)圖這兩種模型B. 采用面向?qū)ο箝_發(fā)方法時(shí)，可以使用狀態(tài)圖和活動(dòng)圖對(duì)系統(tǒng)的動(dòng)態(tài)行為進(jìn)行建模C. 實(shí)體聯(lián)系圖（E-R圖）是在數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)設(shè)計(jì)時(shí)才開始創(chuàng)建的模型D. UML的活動(dòng)圖與程序流程圖的表達(dá)能力等價(jià)（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的需求分析方法，其基本思想是自頂向下逐層分解。數(shù)據(jù)流圖是 進(jìn)行結(jié)構(gòu)化分析時(shí)所使用的模型，其基本成分包括數(shù)據(jù)流、加工、數(shù)據(jù)存儲(chǔ)和外部實(shí)體。在進(jìn)行結(jié)構(gòu)化設(shè) 計(jì)時(shí)，通過(guò)對(duì)數(shù)據(jù)流圖進(jìn)行變換分析和事務(wù)分析可以導(dǎo)出程序結(jié)構(gòu)圖。數(shù)據(jù)庫(kù)設(shè)計(jì)可以分為4個(gè)主要階段：用戶需求分析。數(shù)據(jù)庫(kù)設(shè)計(jì)人員采用一定的輔助工具對(duì)應(yīng)用對(duì)象

31、的 功能、性能、限制等要求所進(jìn)行的科學(xué)分析。概念設(shè)計(jì)。概念結(jié)構(gòu)設(shè)計(jì)是對(duì)信息分析和定義，如視圖模 型化、視圖分析和匯總。對(duì)應(yīng)用對(duì)象精確地抽象、概括而形成的獨(dú)立于計(jì)算機(jī)系統(tǒng)的企業(yè)信息模型。描述 概念模型的較理想的工具是 ER圖。邏輯設(shè)計(jì)。將抽象的概念模型轉(zhuǎn)化為與選用的DBM滬品所支持的數(shù)據(jù)模型相符合的邏輯模型，它是物理設(shè)計(jì)的基礎(chǔ)。包括模式初始設(shè)計(jì)、子模式設(shè)計(jì)、應(yīng)用程序設(shè)計(jì)、模 式評(píng)價(jià)及模式求精。物理設(shè)計(jì)。邏輯模型在計(jì)算機(jī)中的具體實(shí)現(xiàn)方案。UML是面向?qū)ο筌浖臉?biāo)準(zhǔn)化建模語(yǔ)言，其中狀態(tài)圖、活動(dòng)圖、順序圖和通信圖可以用來(lái)對(duì)系統(tǒng)的動(dòng)態(tài)行 為進(jìn)行建模?；顒?dòng)圖展現(xiàn)了在系統(tǒng)內(nèi)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的流程?；顒?dòng)

32、圖強(qiáng)調(diào)對(duì)象之間的控制流程。 在活動(dòng)圖上可以表示分支和匯合。活動(dòng)圖與傳統(tǒng)的程序流程圖是不等價(jià)的。15. 在實(shí)際的項(xiàng)目開發(fā)中， 人們總是希望使用自動(dòng)工具來(lái)執(zhí)行需求變更控制過(guò)程。 下列描述中， 不是這類工具所具有的功能。A. 可以定義變更請(qǐng)求的數(shù)據(jù)項(xiàng)及變更請(qǐng)求生存期的狀態(tài)轉(zhuǎn)換圖B. 記錄每一種狀態(tài)變更的數(shù)據(jù)，確認(rèn)做出變更的人員C. 可以加強(qiáng)狀態(tài)轉(zhuǎn)換圖使經(jīng)授權(quán)的用戶僅能做出所允許的狀態(tài)變更D. 定義變更控制計(jì)劃，并指導(dǎo)設(shè)計(jì)人員按照所制定的計(jì)劃實(shí)施變更分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：對(duì)許多項(xiàng)目來(lái)說(shuō)，系統(tǒng)軟件總需要不斷完善，一些需求的改進(jìn)是合理的而且不可避免，要使得軟件 需求完全不變更，也許

33、是不可能的，但毫無(wú)控制的變更是項(xiàng)目陷入混亂、不能按進(jìn)度完成或者軟件質(zhì)量無(wú) 法保證的主要原因之一。一個(gè)好的變更控制過(guò)程，給項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者提供了正式的建議需求變更機(jī)制。可以通過(guò)需求變更控制過(guò)程 來(lái)跟蹤已建議變更的狀態(tài)，使已建議的變更確保不會(huì)丟失或疏忽。在實(shí)際中，人們總是希望使用自動(dòng)工具 來(lái)執(zhí)行變更控制過(guò)程。有許多人使用商業(yè)問(wèn)題跟蹤工具來(lái)收集、存儲(chǔ)、管理需求變更；可以使用工具對(duì)一 系列最近提交的變更建議產(chǎn)生一個(gè)列表給變更控制委員會(huì)開會(huì)時(shí)做議程用。問(wèn)題跟蹤工具也可以隨時(shí)按變 更狀態(tài)分類包裹變更請(qǐng)求的數(shù)目。挑選工具時(shí)可以考慮以下幾個(gè)方面： 可以定義變更請(qǐng)求的數(shù)據(jù)項(xiàng)。 可以定義變更請(qǐng)求生存期的狀態(tài)轉(zhuǎn)換圖。

34、 可以加強(qiáng)狀態(tài)轉(zhuǎn)換圖使經(jīng)授權(quán)的用戶僅能做出所允許的狀態(tài)變更。 記錄每一種狀態(tài)變更的數(shù)據(jù)，確認(rèn)做出變更的人員。 可以定義在提交新請(qǐng)求或請(qǐng)求狀態(tài)被更新后應(yīng)該自動(dòng)通知的設(shè)計(jì)人員。 可以根據(jù)需要生成標(biāo)準(zhǔn)的或定制的報(bào)告和圖表。16. 黑盒測(cè)試法是根據(jù)軟件產(chǎn)品的功能設(shè)計(jì)規(guī)格說(shuō)明書，通過(guò)運(yùn)行程序進(jìn)行測(cè)試，證實(shí)每個(gè)已經(jīng)實(shí)現(xiàn)的功能是否符合設(shè)計(jì)要求。如果某產(chǎn)品的文本編輯框允許輸入1255個(gè)字符，采用測(cè)試方法，其測(cè)試數(shù)據(jù)為：0個(gè)字符、1個(gè)字符、255個(gè)字符和 256個(gè)字符。A.等價(jià)類劃分B .邊界值分析C. 比較測(cè)試D .正交數(shù)組測(cè)試（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：本題考查黑盒測(cè)試，常用的黑盒測(cè)試技術(shù)

35、包括等價(jià)類劃分、邊值分析、錯(cuò)誤推測(cè)和因果圖等。關(guān)于 這些技術(shù)的詳細(xì)介紹，請(qǐng)參看“ 測(cè)試與評(píng)審”。軟件開發(fā)環(huán)境是支持軟件產(chǎn)品開發(fā)的軟件系統(tǒng)，它由軟件工具集和環(huán)境集成機(jī)制構(gòu)成。環(huán)境集成機(jī)制包括：提供統(tǒng)一的數(shù)據(jù)模式和數(shù)據(jù)接口規(guī)范的數(shù)據(jù)集成機(jī)制；支持各開發(fā)活動(dòng)之間通信、切換、調(diào)度和協(xié)同的_（24）_ ;為統(tǒng)一操作方式提供支持的(25)。（分?jǐn)?shù):2.00 )(1).A .操作集成機(jī)制B .控制集成機(jī)制C.平臺(tái)集成機(jī)制D .界面集成機(jī)制（分?jǐn)?shù)：1.00 )A.B.VC.D.解析：.A .操作集成機(jī)制B .控制集成機(jī)制C.平臺(tái)集成機(jī)制D .界面集成機(jī)制（分?jǐn)?shù)：1.00 )A.B.C.B. V解析：軟件開發(fā)環(huán)

36、境(Software Development EnvironrrLent)是支持軟件產(chǎn)品開發(fā)的軟件系統(tǒng)。它由軟件工具集和環(huán)境集成機(jī)制構(gòu)成，前者用來(lái)支持軟件開發(fā)的相關(guān)過(guò)程、活動(dòng)和任務(wù)；后者為工具集成和軟件開 發(fā)、維護(hù)和管理提供統(tǒng)一的支持，它通常包括數(shù)據(jù)集成、控制集成和界面集成。數(shù)據(jù)集成機(jī)制提供了存儲(chǔ) 或訪問(wèn)環(huán)境信息庫(kù)的統(tǒng)一的數(shù)據(jù)接口規(guī)范；界面集成機(jī)制采用統(tǒng)一的界面形式，提供統(tǒng)一的操作方式；控 制集成機(jī)制支持各開發(fā)活動(dòng)之間的通信、切換、調(diào)度和協(xié)同工作。17. 是一個(gè)獨(dú)立可交付的功能單元，外界通過(guò)接口訪問(wèn)其提供的服務(wù)。A. 面向?qū)ο笙到y(tǒng)中的對(duì)象(Object)B. 模塊化程序設(shè)計(jì)中的子程序 (Sub

37、routine)C. 基于構(gòu)件開發(fā)中的構(gòu)件 (Component)D. 系統(tǒng)模型中的包(Package)(分?jǐn)?shù)：1.00 )A.B.C. VD.解析：在基于構(gòu)件的開發(fā)中，構(gòu)件包含并擴(kuò)展了模塊化程序設(shè)計(jì)中子程序、面向?qū)ο笙到y(tǒng)中對(duì)象或類和系 統(tǒng)模型中包的思想，它是系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和維護(hù)的基礎(chǔ)。構(gòu)件定義為通過(guò)接口訪問(wèn)服務(wù)的一個(gè)獨(dú)立可交付 的功能單元。平時(shí)我們所看到的 DLL文件就是封裝好的構(gòu)件。在基于構(gòu)件的軟件開發(fā)中，(27)描述系統(tǒng)設(shè)計(jì)藍(lán)圖以保證系統(tǒng)提供適當(dāng)?shù)墓δ?(28)用來(lái)了解系統(tǒng)的性能、吞吐率等非功能性屬性。(分?jǐn)?shù)：2.00 )(1) .A .邏輯構(gòu)件模型 B .物理構(gòu)件模型C. 組件接口模型

38、 D .系統(tǒng)交互模型(分?jǐn)?shù)：1.00 )A. VB.C.D.解析：(2) .A .邏輯構(gòu)件模型 B .物理構(gòu)件模型C.組件接口模型 D .系統(tǒng)交互模型(分?jǐn)?shù)：1.00 )A.B. VC.D.解析：在基于構(gòu)件的軟件開發(fā)中，邏輯構(gòu)件模型用功能包描述系統(tǒng)的抽象設(shè)計(jì)，用接口描述每個(gè)服務(wù)集合，以及功能之間如何交互以滿足用戶需求，它作為系統(tǒng)的設(shè)計(jì)藍(lán)圖以保證系統(tǒng)提供適當(dāng)?shù)墓δ?。物理?gòu)件模 型用技術(shù)設(shè)施產(chǎn)品、硬件分布和拓?fù)浣Y(jié)構(gòu)，以及用于綁定的網(wǎng)絡(luò)和通信協(xié)議描述系統(tǒng)的物理設(shè)計(jì)，這種架 構(gòu)用于了解系統(tǒng)的性能、吞吐率等許多非功能性屬性。18. 對(duì)象管理組織()MG)基于CORBAS礎(chǔ)設(shè)施定義了 4種構(gòu)件標(biāo)準(zhǔn)。其中，

39、的狀態(tài)信息是由構(gòu)件自身而不是由容器維護(hù)。A.實(shí)體構(gòu)件B 加工構(gòu)件C.服務(wù)構(gòu)件D 會(huì)話構(gòu)件(分?jǐn)?shù):1.00)A.B.C.D. V解析：對(duì)象管理組織(OMG基于CORB基礎(chǔ)設(shè)施定義了 4種構(gòu)件標(biāo)準(zhǔn)。實(shí)體(Entity)構(gòu)件需要長(zhǎng)期持久化并 主要用于事務(wù)性行為，由容器管理其持久化。加工(Process)構(gòu)件同樣需要容器管理其持久化，但沒(méi)有客戶 端可訪問(wèn)的主鍵。會(huì)話(Session)構(gòu)件不需要容器管理其持久化，其狀態(tài)信息必須由構(gòu)件自己管理。服務(wù) (Service)構(gòu)件是無(wú)狀態(tài)的。19. 分布式系統(tǒng)開發(fā)中，通常需要將任務(wù)分配到不同的邏輯計(jì)算層。業(yè)務(wù)數(shù)據(jù)的綜合計(jì)算分析任務(wù)屬于A.表示邏輯層B 應(yīng)用邏輯層C

40、 數(shù)據(jù)處理層D 數(shù)據(jù)層(分?jǐn)?shù)：1.00 )A.B. VC.D.解析：分布式系統(tǒng)開發(fā)分為 5個(gè)邏輯計(jì)算層：表示層實(shí)現(xiàn)用戶界面；表示邏輯層為了生成數(shù)據(jù)表示而必須 進(jìn)行的處理任務(wù)，如輸入數(shù)據(jù)編輯等；應(yīng)用邏輯層包括為支持實(shí)際業(yè)務(wù)應(yīng)用和規(guī)則所需的應(yīng)用邏輯和處理 過(guò)程，如信用檢查、數(shù)據(jù)計(jì)算和分析等；數(shù)據(jù)處理層包括存儲(chǔ)和訪問(wèn)數(shù)據(jù)庫(kù)中的數(shù)據(jù)所需的應(yīng)用邏輯和命 令，如查詢語(yǔ)句和存儲(chǔ)過(guò)程等；數(shù)據(jù)層是數(shù)據(jù)庫(kù)中實(shí)際存儲(chǔ)的業(yè)務(wù)數(shù)據(jù)。20. 系統(tǒng)輸入設(shè)計(jì)中，采用內(nèi)部控制方式以確保輸入系統(tǒng)數(shù)據(jù)的有效性， 用于驗(yàn)證數(shù)據(jù)是否位于合法的取值范圍。A.數(shù)據(jù)類型檢查 B .自檢位C .域檢查D .格式檢查(分?jǐn)?shù)：1.00 )A.B.

41、C. VD.解析：系統(tǒng)輸入設(shè)計(jì)中，通常通過(guò)內(nèi)部控制的方式驗(yàn)證輸入數(shù)據(jù)的有效性。數(shù)據(jù)類型檢查確保輸入了正確 的數(shù)據(jù)類型；白檢位用于對(duì)主關(guān)鍵字進(jìn)行基于校驗(yàn)位的檢查；域檢查用于驗(yàn)證數(shù)據(jù)是否位于合法的取值范 圍：格式檢查按照已知的數(shù)據(jù)格式對(duì)照檢查輸入數(shù)據(jù)的格式。系統(tǒng)測(cè)試由若干個(gè)不同的測(cè)試類型組成，其中(32)檢查系統(tǒng)能力的最高實(shí)際限度，即軟件在一些超負(fù)荷情況下的運(yùn)行情況；(33)主要是檢查系統(tǒng)的容錯(cuò)能力。(分?jǐn)?shù)：2.00 )(1).A .強(qiáng)度測(cè)試B .性能測(cè)試C .恢復(fù)測(cè)試D .可靠性測(cè)試(分?jǐn)?shù)：1.00 )A. VB.C.D.解析：.A .強(qiáng)度測(cè)試B .性能測(cè)試C .恢復(fù)測(cè)試D .可靠性測(cè)試(分?jǐn)?shù)：

42、1.00 )A.B.B. VD.解析：本題考查測(cè)試的相關(guān)概念，我們只要了解每一種測(cè)試的主要工作，就能解答此題?；謴?fù)測(cè)試：恢復(fù)測(cè)試監(jiān)測(cè)系統(tǒng)的容錯(cuò)能力。檢測(cè)方法是采用各種方法讓系統(tǒng)岀現(xiàn)故障，檢驗(yàn)系統(tǒng)是否按照要求能從故障中恢復(fù)過(guò)來(lái)，并在約定的時(shí)間內(nèi)開始事務(wù)處理，而且不對(duì)系統(tǒng)造成任何傷害。如果系統(tǒng)的恢 復(fù)是自動(dòng)的（由系統(tǒng)自動(dòng)完成），需要驗(yàn)證重新初始化、檢查點(diǎn)、數(shù)據(jù)恢復(fù)等是否正確。如果恢復(fù)需要人工 干預(yù)，就要對(duì)恢復(fù)的平均時(shí)間進(jìn)行評(píng)估并判斷它是否在允許的范圍內(nèi)。強(qiáng)度測(cè)試：是對(duì)系統(tǒng)在異常情況下的承受能力的測(cè)試，是檢查系統(tǒng)在極限狀態(tài)下運(yùn)行時(shí)，性能下降的幅度 是否在允許的范圍內(nèi)。因此，強(qiáng)度測(cè)試要求系統(tǒng)在非正常數(shù)

43、量、頻率或容量的情況下運(yùn)行。強(qiáng)度測(cè)試主要 是為了發(fā)現(xiàn)在有效的輸入數(shù)據(jù)中可能引起不穩(wěn)定或不正確的數(shù)據(jù)組合。例如，運(yùn)行使系統(tǒng)處理超過(guò)設(shè)計(jì)能 力的最大允許值的測(cè)試?yán)樱皇瓜到y(tǒng)傳輸超過(guò)設(shè)計(jì)最大能力的數(shù)據(jù)，包括內(nèi)存的寫入和讀岀等。性能測(cè)試：檢查系統(tǒng)是否滿足系統(tǒng)設(shè)計(jì)方案說(shuō)明書對(duì)性能的要求。性能測(cè)試覆蓋了軟件測(cè)試的各階段，而不是等到系統(tǒng)的各部分所有都組裝之后，才確定系統(tǒng)的真正性能。通常與強(qiáng)度測(cè)試結(jié)合起來(lái)進(jìn)行，并同時(shí) 對(duì)軟件、硬件進(jìn)行測(cè)試。軟件方面主要從響應(yīng)時(shí)間、處理速度、吞吐量、處理精度等方面來(lái)檢測(cè)?？煽啃詼y(cè)試：通常使用以下兩個(gè)指標(biāo)來(lái)衡量系統(tǒng)的可靠性： 平均失效間隔時(shí)間（Mean Time Between

44、Faihires MTBF是否超過(guò)了規(guī)定的時(shí)限，因故障而停機(jī)時(shí)間 （Mean Time To Repairs，MTTR在一年中不應(yīng)超過(guò)多少時(shí) 間。21. 需求管理是CMM可重復(fù)級(jí)中的6個(gè)關(guān)鍵過(guò)程域之一，其主要目標(biāo)是 。A. 對(duì)于軟件需求，必須建立基線以進(jìn)行控制，軟件計(jì)劃、產(chǎn)品和活動(dòng)必須與軟件需求保持一致B. 客觀地驗(yàn)證需求管理活動(dòng)符合規(guī)定的標(biāo)準(zhǔn)、程序和要求C. 策劃軟件需求管理的活動(dòng)，識(shí)別和控制已獲取的軟件需求D. 跟蹤軟件需求管理的過(guò)程、實(shí)際結(jié)果和執(zhí)行情況（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：過(guò)程能力成熟度模型（Capability Maturity Model ，CMM在軟件開發(fā)機(jī)

45、構(gòu)中被廣泛用來(lái)指導(dǎo)軟件過(guò) 程改進(jìn)。該模型描述了軟件成立能力的5個(gè)成熟級(jí)別，每一級(jí)都包含若干關(guān)鍵過(guò)程域 （Key Process . Areas，KPA）。CMM勺第二級(jí)為可重復(fù)級(jí)，它包括6個(gè)關(guān)鍵過(guò)程域，分別是：需求管理、軟件項(xiàng)目計(jì)劃、軟件項(xiàng)目跟蹤和監(jiān)督、軟件分包合同管理、軟件質(zhì)量保證和軟件配置管理。需求管理的目標(biāo)是為軟件需求建立一個(gè)基線，提供給軟件工程和管理使用；軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致。UML的事物是對(duì)模型中最具有代表性的成分的抽象，（35）是模型的靜態(tài)部分，描述概念或物理元素；（36）用來(lái)描述、說(shuō)明和標(biāo)注模型的任何元素。（分?jǐn)?shù)：2.00 ）（1）.A .結(jié)構(gòu)事物B .分組事物

46、C .行為事物D .注釋事物（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：.A .分組事物B .注釋事物C .結(jié)構(gòu)事物D .行為事物（分?jǐn)?shù)：1.00 ）A.C.D.解析：UML有3種基本的構(gòu)造塊，分別是事物 （元素）、關(guān)系和圖。事物是 UML中重要的組成部分。關(guān)系把 事物緊密聯(lián)系在一起。圖是很多有相互相關(guān)的事物的組。UML中的事物也稱為建模元素，包括結(jié)構(gòu)事物、動(dòng)作事物、分組事物和注釋事物。這些事物是UML模型中最基本的面向?qū)ο蟮臉?gòu)造塊。 結(jié)構(gòu)事物。 結(jié)構(gòu)事物在模型中屬于最靜態(tài)的部分，代表概念上等或物理上的元素。 總共有 7 種結(jié)構(gòu)事物：首先是類，類是描述具有相同屬性、方法、關(guān)系和語(yǔ)義的對(duì)象的集

47、合。一個(gè)類實(shí)現(xiàn)一個(gè)或多個(gè)接口。第2 種是接口，接口是指類或組件提供特定服務(wù)的一組操作的集合。因此，一個(gè)接口描述了類或組件的對(duì) 外的可見(jiàn)的動(dòng)作。一個(gè)接口可以實(shí)現(xiàn)類或組件的全部動(dòng)作，也可以只實(shí)現(xiàn)一部分。第3 種是協(xié)作，協(xié)作定義了交互的操作，是一些角色和其他元素一起工作，提供一些合作的動(dòng)作，這些動(dòng) 作比元素的總和要大。因此，協(xié)作具有結(jié)構(gòu)化、動(dòng)作化、維的特性。一個(gè)給定的類可能是幾個(gè)協(xié)作的組成 部分。這些協(xié)作代表構(gòu)成系統(tǒng)的模式的實(shí)現(xiàn)。第4 種是用例，用例是描述一系列的動(dòng)作，這些動(dòng)作是系統(tǒng)對(duì)一個(gè)特定角色執(zhí)行，產(chǎn)生值得注意的結(jié)果的 值。在模型中用例通常用來(lái)組織動(dòng)作事物。用例是通過(guò)協(xié)作來(lái)實(shí)現(xiàn)的。第5 種是活動(dòng)

48、類，活動(dòng)類是這種類，它的對(duì)象有一個(gè)或多個(gè)進(jìn)程或線程?；顒?dòng)類和類很相像，只是它的對(duì) 象代表的元素的行為和其他的元素是同時(shí)存在的。第6 種是構(gòu)件，構(gòu)件是物理上或可替換的系統(tǒng)部分，它實(shí)現(xiàn)了一個(gè)接口集合。在一個(gè)系統(tǒng)中，可能會(huì)遇到不同種類的構(gòu)件，女口 DCOM EJB第7 種是節(jié)點(diǎn)，節(jié)點(diǎn)是一個(gè)物理元素，它在運(yùn)行時(shí)存在，代表一個(gè)可計(jì)算的資源，通常占用一些內(nèi)存和具 有處理能力。一個(gè)組件集合一般來(lái)說(shuō)位于一個(gè)節(jié)點(diǎn)，但有可能從一個(gè)節(jié)點(diǎn)轉(zhuǎn)到另一個(gè)節(jié)點(diǎn)。 動(dòng)作事物：動(dòng)作事物是 uML模型中的動(dòng)態(tài)部分。它們是模型的動(dòng)詞，代表時(shí)間和空間上的動(dòng)作?？偣灿?兩種主要的動(dòng)作事物。第1種是交互 （內(nèi)部活動(dòng) ） ，交互是由一組對(duì)象

49、之間在特定上下文中，為達(dá)到特定的目的而進(jìn)行的一系列消 息交換而組成的動(dòng)作。 交互中組成動(dòng)作的對(duì)象的每個(gè)操作都要詳細(xì)列出， 包括消息、 動(dòng)作次序 （消息產(chǎn)生的 動(dòng)作 ） 、連接 （ 對(duì)象之間的連接 ） 。第2 種是狀態(tài)機(jī)，狀態(tài)機(jī)由一系列對(duì)象的狀態(tài)組成。內(nèi)部活動(dòng)和狀態(tài)機(jī)是 UML模型中最基本的兩個(gè)動(dòng)態(tài)事物元素，它們通常和其他的結(jié)構(gòu)元素、主要的類、對(duì) 象連接在一起。 分組事物。分組事物是 UML模型中組織的部分，可以把它們看成是個(gè)盒子，模型可以在其中被分解?？?共只有一種分組事物，稱為包。包是一種將有組織的元素分組的機(jī)制。結(jié)構(gòu)事物、動(dòng)作事物甚至其他的分 組事物都有可能放在一個(gè)包中。與組件 （存在于運(yùn)

50、行時(shí) ）不同的是包純粹是一種概念上的東西，只存在于開 發(fā)階段。 注釋事物。注釋事物是 UML模型的解釋部分。22. 希賽公司欲開發(fā)一個(gè)在線交易系統(tǒng)。 為了能夠精確表達(dá)用戶與系統(tǒng)的復(fù)雜交互過(guò)程， 應(yīng)該采用 UIVlL 的 進(jìn)行交互過(guò)程建模。A.類圖B 順序圖C 部署圖D 對(duì)象圖（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：顯然，為了能夠精確表達(dá)用戶與系統(tǒng)的復(fù)雜交互過(guò)程，應(yīng)該使用交互圖。在UML中，交互圖包括順序圖、通信圖、定時(shí)圖和交互概覽圖。順序圖強(qiáng)調(diào)消息的時(shí)間次序，通信圖強(qiáng)調(diào)消息流經(jīng)的數(shù)據(jù)結(jié)構(gòu)，定 時(shí)圖強(qiáng)調(diào)消息跨越不同對(duì)象或角色的實(shí)際時(shí)間，交互概覽圖是順序圖和活動(dòng)圖的混合體。23. 雇員類含

51、有計(jì)算報(bào)酬的行為， 利用面向?qū)ο蟮?，可以使得其派生類專職雇員類和兼職雇員類計(jì)算報(bào)酬的行為有相同的名稱，但有不同的計(jì)算方法。A.多態(tài)性B .繼承性C .封裝性D .復(fù)用性（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：本題是一個(gè)純概念題。在面向?qū)ο蠹夹g(shù)中，多態(tài)考慮的是類與類之間的層次關(guān)系，以及類自身內(nèi)部 特定成員函數(shù)之間的關(guān)系問(wèn)題，是解決功能和行為的再抽象問(wèn)題。多態(tài)是指類中具有相似功能的不同函數(shù) 用同一個(gè)名稱來(lái)實(shí)現(xiàn)，從而可以使用相同的調(diào)用方式來(lái)調(diào)用這些具有不同功能的同名函數(shù)。這也是人類思 維方式的一種直接模擬， 例如，一個(gè)對(duì)象中有很多求兩個(gè)數(shù)最大值的行為， 雖然可以針對(duì)不同的數(shù)據(jù)類型， 寫很多

52、不同名稱的函數(shù)來(lái)實(shí)現(xiàn)，但事實(shí)上，它們的功能幾乎完全相同。這時(shí)，就可以利用多態(tài)的特征，用 統(tǒng)一的標(biāo)識(shí)來(lái)完成這些功能。這樣，就可以達(dá)到類的行為的再抽象，進(jìn)而統(tǒng)一標(biāo)識(shí)，減少程序中標(biāo)識(shí)符的 個(gè)數(shù)。24. 面向?qū)ο蠓治龅囊豁?xiàng)重要任務(wù)是發(fā)現(xiàn)潛在對(duì)象并進(jìn)行篩選，錯(cuò)誤的做法是刪除 。A.系統(tǒng)范圍之外的名詞 B .表示事件的名詞C.不具有獨(dú)特行為的名詞 D 一個(gè)對(duì)象的同義詞（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：在00A中，并不是所有的名詞都表示了問(wèn)題域內(nèi)有用的業(yè)務(wù)對(duì)象，通過(guò)刪除對(duì)象的同義詞、系統(tǒng)范 圍之外的名詞、不具有獨(dú)特行為的名詞、不清楚的名詞和另一個(gè)對(duì)象的行動(dòng)或?qū)傩缘拿~來(lái)最終清理候選 對(duì)象列表。25. 面向?qū)ο蠓治龅娜蝿?wù)不包含 。A.建模系統(tǒng)功能B .發(fā)現(xiàn)并確定業(yè)務(wù)對(duì)象C.建模各對(duì)象的狀態(tài) D .組織對(duì)象并確定對(duì)象間的關(guān)系（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：00A基于用例模型，通過(guò)對(duì)象建模記錄確定的對(duì)象、對(duì)象封裝的數(shù)據(jù)和行為，以及對(duì)象之間的關(guān)系。00A包括3個(gè)活動(dòng)，分別是建模系統(tǒng)功能、發(fā)現(xiàn)并確定業(yè)務(wù)對(duì)象、組織對(duì)象并確定對(duì)象問(wèn)的關(guān)系。26. 系統(tǒng)測(cè)試將軟件、硬件、網(wǎng)絡(luò)等其他因素結(jié)合，對(duì)整個(gè)軟件進(jìn)行測(cè)試。不是系統(tǒng)測(cè)試的內(nèi)容。A.路徑測(cè)試B 可靠性測(cè)試C 安裝測(cè)試D 安全測(cè)試分?jǐn)?shù)： 1.00 )A. VB.C.B. 解析：系統(tǒng)測(cè)試是將已