uml綜合練習(xí)習(xí)題及答案_第1頁
uml綜合練習(xí)習(xí)題及答案_第2頁
uml綜合練習(xí)習(xí)題及答案_第3頁
uml綜合練習(xí)習(xí)題及答案_第4頁
uml綜合練習(xí)習(xí)題及答案_第5頁
已閱讀5頁,還剩8頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、一、選擇題1. 軟件設(shè)計中的( ) 設(shè)計指定各個組件之間的通信方式以及各組件之間如何相互作用。 A數(shù)據(jù) B接口 C結(jié)構(gòu) D組件 2. UML 是一種( ) 。 A面向?qū)ο蟮某绦蛟O(shè)計語言 B面向過程的程序設(shè)計語言 C軟件系統(tǒng)開發(fā)方法D軟件系統(tǒng)建模語言 3. 面向?qū)ο笾械模?)機(jī)制是對現(xiàn)實世界中遺傳現(xiàn)象的模擬,通過該機(jī)制,基類的屬性和方法被遺傳給派生類。 A封裝 B多態(tài) C繼承 D變異 4. 下面關(guān)于類、對象和實例的敘述中,錯誤的是( ) 。 A 類是創(chuàng)建對象的模板 B 對象是類的實例 C 類是對象的實例 D 類是一組具有共同特征的對象集合 5. 下列 不在UP的初始階段中完成的A編制簡要的愿景文

2、檔 B粗略評估成本C定義大多數(shù)的需求 D業(yè)務(wù)案例6. 下面那一種模式是不屬于GRASP模式的A 多態(tài)(Ploymorphism) B 行為對象(pure fabrication)C 中間者(Indirection) D GoF 7. 類是一組具有相同屬性的和相同服務(wù)的對象的抽象描述,類中的每個對象都是這個類的一個。A例證 B用例 C實例 D例外8. 類之間共享屬性與服務(wù)的機(jī)制稱為(22)。A多態(tài)性B動態(tài)綁定 C靜態(tài)綁定D繼承9. 一個對象通過發(fā)送 來請求另一個對象為其服務(wù)。A調(diào)用語句 B消息C命令D口令10. 下面的陳述中,對迭代和增量式開發(fā)描述錯誤的是()。A. 迭代是時間定量的B. 系統(tǒng)是

3、增量式增長的C. 迭代是以循環(huán)反饋和調(diào)整為核心驅(qū)動力的D. 當(dāng)?shù)鸁o法依照時間表來集成、測試和穩(wěn)定局部系統(tǒng)時,可以推遲完成日期。11. 有關(guān)UP階段的說法,不正確的是()A. UP的一個開發(fā)周期(以系統(tǒng)發(fā)布作為產(chǎn)品結(jié)束標(biāo)志)由多個迭代組成;B. 初始階段不是需求階段,而是研究可行性的階段。C. 細(xì)化階段就是需求或設(shè)計階段;D. 細(xì)化階段就是迭代地實現(xiàn)核心架構(gòu)并解決高風(fēng)險問題的階段;12. 下面關(guān)于領(lǐng)域模型的描述,不正確的是()A. 領(lǐng)域模型就是軟件對象圖;B. 應(yīng)用UML表示法,領(lǐng)域模型被描述為一組沒有定義操作的類圖;C. 創(chuàng)建領(lǐng)域模型的原因之一是幫助理解關(guān)鍵業(yè)務(wù)概念和詞匯;D. 領(lǐng)域模型和領(lǐng)

4、域?qū)邮褂孟嗨频拿梢詼p少軟件表示與我們頭腦中的領(lǐng)域模型之間的差異。13. 封裝是指把對象的( )結(jié)合在一起,組成一個獨立的對象。A 屬性和操作 B 信息流 C 消息和事件 D 數(shù)據(jù)的集合14. 封裝是一種( )技術(shù),目的是使對象的生產(chǎn)者和使用者分離,使對象的定義和實現(xiàn)分開。A 工程化 B 系統(tǒng)維護(hù) C 信息隱藏 D 產(chǎn)生對象15. 面向?qū)ο蠓椒ㄖ械模?)機(jī)制使子類可以自動地?fù)碛校◤?fù)制)父類全部屬性和操作。A 約束 B 對象映射 C 信息隱藏 D 繼承16. 使得在多個類中能夠定義同一個操作或?qū)傩悦?,并在每一個類中有不同的實現(xiàn)的一種方法是()。A 繼承 B 多態(tài)性 C 約束 D 接口17. 順

5、序圖和協(xié)作圖主要用于對用例圖中( )的建模,用它們來描述用例圖的行為。A 數(shù)據(jù)流 B控制流 C 消息流 D 數(shù)據(jù)字典18. 順序圖的模型元素有( )、消息、鏈接等,這些模型元素表示某個用例中的若干個對象和對象之間所傳遞的消息,來對系統(tǒng)的行為建模。A 對象 B 箭線 C 活動 D 狀態(tài)19. 順序圖描述( )對象之間消息的傳遞順序。A 某個 B 單個 C 一個類產(chǎn)生的 D 一組20. 順序圖和協(xié)作圖建立類UML面向?qū)ο箝_發(fā)過程中的對象動態(tài)( )模型。A 交互 B 狀態(tài) C 體系結(jié)構(gòu) D 軟件復(fù)用21. 狀態(tài)圖可以表現(xiàn)( )在生存期的行為、所經(jīng)歷的狀態(tài)序列、引起狀態(tài)轉(zhuǎn)移的事件以及因狀態(tài)轉(zhuǎn)移而引起的

6、動作。A 一組對象 B 一個對象 C 多個執(zhí)行者 D 幾個子系統(tǒng)22. 狀態(tài)圖描述一個對象在不同( )的驅(qū)動下發(fā)生的轉(zhuǎn)臺遷移。A 事件 B 對象 C 執(zhí)行者 D 數(shù)據(jù)23. 一個( )遷移圖符可以有多個源狀態(tài)或目標(biāo)狀態(tài),它們可以把一個控制分解為并行運行的并發(fā)線程,或多個并發(fā)線程接合成單個線程。A 狀態(tài) B 對象 C 活動 D 同步并發(fā)24. 活動圖中動作狀態(tài)之間的遷移不是靠( )觸發(fā)的,當(dāng)活動(動作)狀態(tài)中的活動完成時就被觸發(fā)。A 對象 B 事件 C 執(zhí)行者 D 系統(tǒng)25. 狀態(tài)圖和活動圖建立了UML面向?qū)ο箝_發(fā)過程中的對象動態(tài)( )模型。A 交互 B 狀態(tài) C 體系結(jié)構(gòu) D 軟件復(fù)用26.

7、UML中關(guān)聯(lián)的多重度是指( )A 一個類有多個方法被另一個類調(diào)用B 一個類的實例能夠與另一個類的多個實例相關(guān)聯(lián)C 一個類的某個方法被另一個類調(diào)用的次數(shù)D 兩個類所具有的相同的方法和屬性27. 在某個信息系統(tǒng)中,存在如下的業(yè)務(wù)陳述:一個客戶提交0個或多個訂單;一個訂單由一個且僅由一個客戶提交。系統(tǒng)中存在兩個類:“客戶”類和“訂單”類。對應(yīng)每個“訂單”類的實例,存在 (1)B “客戶”類的實例;對應(yīng)每個“客戶”類的實例,存在 D(2) 個“訂單”類的實例。供選擇的答案:A 0個 B 1個 C 1個或多個 D 0個或多個28. 什么是關(guān)聯(lián)類( )A 它描述了可以存在于類之間的各種關(guān)系。B 它在另外兩

8、個類之間的關(guān)聯(lián)中添加屬性和/或行為。C 它關(guān)聯(lián)對象和該對象所屬的類。29. 為什么層在子系統(tǒng)設(shè)計中非常重要( )(多選題)A 更容易改變實現(xiàn)方式B 減少了實現(xiàn)代碼中類的數(shù)量C 提高了重用性D 降低了復(fù)雜性30. 如果兩個顧客在世界的不同地方,要購買音樂會的最后一張票,如何分配這張票( )參與者和角色之間的差別A 引入一個額外的業(yè)務(wù)規(guī)則,把可用票的查詢和臨時預(yù)定合并起來。B 使顧客參與軟件“競爭”,以買到票。C 不允許賣出最后一張票,因為這對其中的一位顧客是不公平的。31. 如圖6-12所示:(1)X1、X2和X3是什么( )(單選題)用例模型的用途就是列出系統(tǒng)中的用例和參與者A 角色 B Pr

9、ima donnas C 參與者 D 棒(2)下面哪個語句是正確的( )(多選題)A X3可以使用UC4與系統(tǒng)交互。B X1可以使用UC1和UC4與系統(tǒng)交互。C X1、X2與X3不同。D UC3是沒有步驟的抽象用例。(3)下面哪個語句是正確的( )(多選題)A UC5是UC4的補(bǔ)充部分。B UC4是UC5的可選部分。C UC1是沒有用的。D UC2是UC4的可選部分。E UC4是UC2的補(bǔ)充部分。32. 如圖所示,下面哪些陳述是正確的( )A 汽車總是有相同的車身B 一些汽車有備用輪胎C 汽車有一個引擎,引擎在汽車之間不共享D 所有的汽車都有四或五個輪胎E 汽車必須有至少一個司機(jī)F 乘客不可能

10、是司機(jī) 33. 如圖,A、B和C是什么對象A A是實體,B是控制者,C是邊界。B A是邊界,B是實體,C是控制者。C A是實體,B是邊界,C是控制者。D A是控制者,B是實體,C是邊界。 1334. 領(lǐng)域模型是一組表示( ),在設(shè)計工作中廣泛用來啟發(fā)設(shè)計軟件對象.A 真實世界的概念類 B 虛擬世界的概念類 C 軟件部件的模型 D 硬件部件的模型35. UML提供了一系列的圖支持面向?qū)ο蟮姆治雠c設(shè)計,其中_(1)_F_給出系統(tǒng)的靜態(tài)設(shè)計視圖;_(2)_B_對系統(tǒng)的功能進(jìn)行組織和建模是非常重要的;_(3)_C_和_(4)_E_都是描述系統(tǒng)動態(tài)視圖的交互圖,其中_(5)_C_描述了以時間順序組織的對

11、象之間的交互活動,_(6)_E_強(qiáng)調(diào)收發(fā)消息的對象的組織結(jié)構(gòu)。A 狀態(tài)圖 B 用例圖 C 序列圖 D 部署圖 E 協(xié)作圖 F 類圖36. 類是一組具有相同屬性的和相同服務(wù)的對象的抽象描述,類中的每個對象都是這個類的一個(1)c。類之間共享屬性與服務(wù)的機(jī)制稱為d(2)。一個對象通過發(fā)送b(3)來請求另一個對象為其服務(wù)。(1)A例證B用例C實例D例外(2)A多態(tài)性B動態(tài)綁定C靜態(tài)綁定D繼承(3)A調(diào)用語句B消息C命令D口令37. 領(lǐng)域模型又稱為()A業(yè)務(wù)流程模型B.用例模型C.概念模型D.設(shè)計模型 38. 在面向?qū)ο蟮姆椒▽W(xué)中,對象可看成是屬性及對于這些屬性的專用服務(wù)的封裝體。封裝是一種(1)技術(shù)

12、,封裝的目的是使對象的(2)分離。(1)A組裝B產(chǎn)品化C固化D信息隱藏(2)A定義和實現(xiàn)B設(shè)計和測試C設(shè)計和實現(xiàn)D分析和定義39. 如果你想對一個類的意義進(jìn)行描述,那么應(yīng)該采用 A. 標(biāo)記值B. 規(guī)格描述 C. 注釋D.構(gòu)造型40. 軟件復(fù)用是面向?qū)ο笙到y(tǒng)分析與設(shè)計的核心支持技術(shù)之一,軟件復(fù)用的核心是( )。A 對象類 B 軟件構(gòu)件技術(shù) C 設(shè)計模式 D模塊41. 軟件測試通常采用黑盒測試和白盒測試。其中黑盒測試根據(jù)軟件的( a) 設(shè)計測試用例,白盒測試根據(jù)軟件的(c ) 設(shè)計測試用例。 A功能規(guī)格說明 B需求說明 C內(nèi)部結(jié)構(gòu)和邏輯 D數(shù)據(jù)流圖 42. 將軟件從一種計算機(jī)環(huán)境轉(zhuǎn)換到另一種環(huán)境運

13、行的難易程度是指軟件的(B) 。在規(guī)定的條件下和規(guī)定的時間間隔內(nèi),按設(shè)計要求,軟件成功運行的特性稱為(A ) 。 A可靠性 B可移植性 C可使用性 D靈 性 43. 原型化方法是動態(tài)確定軟件需求的方法之一,該方法適應(yīng)于( ) 的系統(tǒng)。 A需求不確定性高 B需求確定 C結(jié)構(gòu)簡單 D可移植性好 44. 瀑布模型是傳統(tǒng)的軟件開發(fā)過程模型,它強(qiáng)調(diào)各階段的嚴(yán)格性,其主要缺點是( ) 。 A需要軟件人員和用戶進(jìn)行溝通 B需要付 較高的維護(hù)成本 C開發(fā)的軟件不易于移植 D不適應(yīng)需求不確定的軟件開發(fā) 45. 軟件設(shè)計中的( ) 設(shè)計指定各個組件之間的通信方式以及各組件之間如 何相互作用。 是什么語言A數(shù)據(jù) B

14、接口 C結(jié)構(gòu) D組件 46. ( ) 不是面向?qū)ο蟪绦蛟O(shè)計語言。 AXML BJava CC# DSimula 47. 在畫SSD圖時, 應(yīng)該如何對待所涉及的系統(tǒng):A.詳細(xì)描述其內(nèi)部結(jié)構(gòu)及其功能;B.簡單描述其內(nèi)部結(jié)構(gòu),但是羅列系統(tǒng)所有的功能C.詳細(xì)描述其內(nèi)部結(jié)構(gòu),并不列出系統(tǒng)的功能D.不對系統(tǒng)的內(nèi)部結(jié)構(gòu)與功能進(jìn)行描述.48. 定義大多數(shù)的需求和范圍的工作是在UP中的 階段完成的。A初始階段 B細(xì)化階段 C構(gòu)造階段 D提交階段49. 下列 不在UP的初始階段中完成的A編制簡要的愿景文檔B粗略評估成本C定義大多數(shù)的需求D業(yè)務(wù)案例二、簡答題1. 統(tǒng)一過程中有哪四個階段,各階段需要完成的主要工作有哪

15、些 答:1)初始階段:編制簡要的愿景文檔、 業(yè)務(wù)案例、 確定范圍、 粗略評估成本。2)細(xì)化階段:細(xì)化愿景文檔、 迭代地實現(xiàn)核心構(gòu)架、 解決高風(fēng)險的問題、 定義大多數(shù)的需求和范圍、 進(jìn)一步評估成本3)構(gòu)造階段:迭代地實現(xiàn)系統(tǒng)的其余部分、 準(zhǔn)備部署4)提交階段:beta 測試、部署2. 統(tǒng)一過程中的核心工作流有哪些 答:業(yè)務(wù)建模、 需求分析、 設(shè)計、 實現(xiàn)、 測試。3. UP的核心思想有哪些 答:短時間盒的迭代式開發(fā)開發(fā)過程中不斷進(jìn)行調(diào)整在早期的迭代中解決高風(fēng)險和高價值的主要問題不斷與用戶銜接,及時得到反饋意見早期注意構(gòu)造核心的體系結(jié)構(gòu)早期進(jìn)入實現(xiàn)和測試,不斷進(jìn)行質(zhì)量檢驗使用用況(use case

16、)可視化建模(用UML)仔細(xì)地管理需求控制變更4. 什么是增量開發(fā) 答:增量開發(fā)包括兩層意思: 1)對復(fù)雜的用況分多次迭代,一部分一部分地實現(xiàn)2)將所有用況按其優(yōu)先級分別安排在不同的迭代中實現(xiàn) 三、畫圖題1. 已知三個類和C.其中類A由類B的一個實類和類C的1個或多個實類構(gòu)成.請畫出能夠正確表示類A,B和C之間關(guān)系的UML類圖。2. 畫出下面場景的順序圖 1.收款員(Cashier)啟動一次銷售(makeNewSale() 2.收款員輸入商品標(biāo)識(enterItem(itemID,quantity) 3.銷售結(jié)束,系統(tǒng)計算并顯示總金額(endSale()4.顧客付款,系統(tǒng)(System)處理支

17、付。(makePayment(amount)3. 下面一段代碼為 UserInfo類和Company類的定義的代碼,請根據(jù)代碼畫出類圖(類及其關(guān)系),并標(biāo)記出類之間關(guān)系的重數(shù)。public class UserInfo private Company oneCompany; 客帶著購買的商品或服務(wù)來到POS收款臺 (2).收款員啟動一次銷售 (3).收款員輸入商品標(biāo)識 (4).系統(tǒng)記錄商品,并且顯示該商品說明,價格,并計算總金額。按一組計價規(guī)則計算單價。四、案例分析PizzaBase案例分析PizzaBase飯館想把顧客預(yù)定比薩的過程自動化。每張桌子都配備一個觸摸式屏幕,顧客可以用它瀏覽所供應(yīng)

18、的比薩,并點菜。該飯館供應(yīng)兩種基本類型的比薩:自助類只有西紅柿醬,顧客可以選擇任意數(shù)量的配料,每種配料的價格都是固定的。預(yù)制類有幾個小類,每個小類都有固定的配料。每種比薩都可以預(yù)定酥脆型和松軟型,有三種規(guī)格:6英寸、9英寸和12英寸。顧客還可以預(yù)定飲料,例如可樂類和檸檬類,每種飲料都有大杯和小杯兩種規(guī)格。顧客確認(rèn)了預(yù)定的食物后,就顯示總價。之后,屏幕顯示食物的準(zhǔn)備和烹飪進(jìn)度。在顧客吃完后,可以以方便的方式付費。(1)在PizzaBase案例分析中,在分析階段的屬性列表是哪一個( )A 可樂、基本類型、價格、規(guī)格、檸檬、付費方式B 口味、品種、付費方式、總價、顯示、肉類、西紅柿C 進(jìn)度、品種、口味、價格、觸摸式屏幕、規(guī)格、飲料D 基本類型、價格、品種、規(guī)格、進(jìn)度、口味(2)如圖所示,哪個圖是PizzaBase飯館中比薩的最佳模型( )A 圖1B 圖2C 圖3(3)在PizzaBase案例分析中,分析類最有可能是哪個列表( )A Payment, Order, Drink, Topping, Pizza, Restaurant, Base, SauceB Customer, Table, Pizza, Topping, Drink, Restaurant, OrderC PizzaBase, Cola, Restaurant, Lemonade, D

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論