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

下載本文檔

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

文檔簡(jiǎn)介

./一、選擇題軟件設(shè)計(jì)中的〔〕設(shè)計(jì)指定各個(gè)組件之間的通信方式以與各組件之間如何相互作用。A.?dāng)?shù)據(jù)B.接口C.結(jié)構(gòu)D.組件UML是一種〔〕。A.面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言B.面向過(guò)程的程序設(shè)計(jì)語(yǔ)言C.軟件系統(tǒng)開發(fā)方法D.軟件系統(tǒng)建模語(yǔ)言面向?qū)ο笾械摹病硻C(jī)制是對(duì)現(xiàn)實(shí)世界中遺傳現(xiàn)象的模擬,通過(guò)該機(jī)制,基類的屬性和方法被遺傳給派生類。A.封裝B.多態(tài)C.繼承D.變異下面關(guān)于類、對(duì)象和實(shí)例的敘述中,錯(cuò)誤的是〔〕。A類是創(chuàng)建對(duì)象的模板B對(duì)象是類的實(shí)例C類是對(duì)象的實(shí)例D類是一組具有共同特征的對(duì)象集合下列不在UP的初始階段中完成的A編制簡(jiǎn)要的愿景文檔B粗略評(píng)估成本C定義大多數(shù)的需求D業(yè)務(wù)案例下面那一種模式是不屬于GRASP模式的A多態(tài)〔Ploymorphism〕B行為對(duì)象〔purefabrication〕C中間者〔Indirection〕DGoF類是一組具有相同屬性的和相同服務(wù)的對(duì)象的抽象描述,類中的每個(gè)對(duì)象都是這個(gè)類的一個(gè)。A例證B用例C實(shí)例D例外類之間共享屬性與服務(wù)的機(jī)制稱為〔22〕。A多態(tài)性B動(dòng)態(tài)綁定C靜態(tài)綁定D繼承一個(gè)對(duì)象通過(guò)發(fā)送來(lái)請(qǐng)求另一個(gè)對(duì)象為其服務(wù)。A調(diào)用語(yǔ)句B消息C命令D口令下面的陳述中,對(duì)迭代和增量式開發(fā)描述錯(cuò)誤的是〔〕。A.迭代是時(shí)間定量的B.系統(tǒng)是增量式增長(zhǎng)的C.迭代是以循環(huán)反饋和調(diào)整為核心驅(qū)動(dòng)力的D.當(dāng)?shù)鸁o(wú)法依照時(shí)間表來(lái)集成、測(cè)試和穩(wěn)定局部系統(tǒng)時(shí),可以推遲完成日期。有關(guān)UP階段的說(shuō)法,不正確的是〔〕A.UP的一個(gè)開發(fā)周期〔以系統(tǒng)發(fā)布作為產(chǎn)品結(jié)束標(biāo)志〕由多個(gè)迭代組成;B.初始階段不是需求階段,而是研究可行性的階段。C.細(xì)化階段就是需求或設(shè)計(jì)階段;D.細(xì)化階段就是迭代地實(shí)現(xiàn)核心架構(gòu)并解決高風(fēng)險(xiǎn)問(wèn)題的階段;下面關(guān)于領(lǐng)域模型的描述,不正確的是〔〕A.領(lǐng)域模型就是軟件對(duì)象圖;B.應(yīng)用UML表示法,領(lǐng)域模型被描述為一組沒(méi)有定義操作的類圖;C.創(chuàng)建領(lǐng)域模型的原因之一是幫助理解關(guān)鍵業(yè)務(wù)概念和詞匯;D.領(lǐng)域模型和領(lǐng)域?qū)邮褂孟嗨频拿梢詼p少軟件表示與我們頭腦中的領(lǐng)域模型之間的差異。封裝是指把對(duì)象的〔〕結(jié)合在一起,組成一個(gè)獨(dú)立的對(duì)象。A屬性和操作B信息流C消息和事件D數(shù)據(jù)的集合封裝是一種〔〕技術(shù),目的是使對(duì)象的生產(chǎn)者和使用者分離,使對(duì)象的定義和實(shí)現(xiàn)分開。A工程化B系統(tǒng)維護(hù)C信息隱藏D產(chǎn)生對(duì)象面向?qū)ο蠓椒ㄖ械摹病硻C(jī)制使子類可以自動(dòng)地?fù)碛小矎?fù)制〕父類全部屬性和操作。A約束B對(duì)象映射C信息隱藏D繼承使得在多個(gè)類中能夠定義同一個(gè)操作或?qū)傩悦?并在每一個(gè)類中有不同的實(shí)現(xiàn)的一種方法是〔〕。A繼承B多態(tài)性C約束D接口順序圖和協(xié)作圖主要用于對(duì)用例圖中〔〕的建模,用它們來(lái)描述用例圖的行為。A數(shù)據(jù)流B控制流C消息流D數(shù)據(jù)字典順序圖的模型元素有〔〕、消息、等,這些模型元素表示某個(gè)用例中的若干個(gè)對(duì)象和對(duì)象之間所傳遞的消息,來(lái)對(duì)系統(tǒng)的行為建模。A對(duì)象B箭線C活動(dòng)D狀態(tài)順序圖描述〔〕對(duì)象之間消息的傳遞順序。A某個(gè)B單個(gè)C一個(gè)類產(chǎn)生的D一組順序圖和協(xié)作圖建立類UML面向?qū)ο箝_發(fā)過(guò)程中的對(duì)象動(dòng)態(tài)〔〕模型。A交互B狀態(tài)C體系結(jié)構(gòu)D軟件復(fù)用狀態(tài)圖可以表現(xiàn)〔〕在生存期的行為、所經(jīng)歷的狀態(tài)序列、引起狀態(tài)轉(zhuǎn)移的事件以與因狀態(tài)轉(zhuǎn)移而引起的動(dòng)作。A一組對(duì)象B一個(gè)對(duì)象C多個(gè)執(zhí)行者D幾個(gè)子系統(tǒng)狀態(tài)圖描述一個(gè)對(duì)象在不同〔〕的驅(qū)動(dòng)下發(fā)生的轉(zhuǎn)臺(tái)遷移。A事件B對(duì)象C執(zhí)行者D數(shù)據(jù)一個(gè)〔〕遷移圖符可以有多個(gè)源狀態(tài)或目標(biāo)狀態(tài),它們可以把一個(gè)控制分解為并行運(yùn)行的并發(fā)線程,或多個(gè)并發(fā)線程接合成單個(gè)線程。A狀態(tài)B對(duì)象C活動(dòng)D同步并發(fā)活動(dòng)圖中動(dòng)作狀態(tài)之間的遷移不是靠〔〕觸發(fā)的,當(dāng)活動(dòng)〔動(dòng)作〕狀態(tài)中的活動(dòng)完成時(shí)就被觸發(fā)。A對(duì)象B事件C執(zhí)行者D系統(tǒng)狀態(tài)圖和活動(dòng)圖建立了UML面向?qū)ο箝_發(fā)過(guò)程中的對(duì)象動(dòng)態(tài)〔〕模型。A交互B狀態(tài)C體系結(jié)構(gòu)D軟件復(fù)用UML中關(guān)聯(lián)的多重度是指<>A一個(gè)類有多個(gè)方法被另一個(gè)類調(diào)用B一個(gè)類的實(shí)例能夠與另一個(gè)類的多個(gè)實(shí)例相關(guān)聯(lián)C一個(gè)類的某個(gè)方法被另一個(gè)類調(diào)用的次數(shù)D兩個(gè)類所具有的相同的方法和屬性在某個(gè)信息系統(tǒng)中,存在如下的業(yè)務(wù)陳述:①一個(gè)客戶提交0個(gè)或多個(gè)訂單;②一個(gè)訂單由一個(gè)且僅由一個(gè)客戶提交。系統(tǒng)中存在兩個(gè)類:"客戶"類和"訂單"類。對(duì)應(yīng)每個(gè)"訂單"類的實(shí)例,存在〔1〕B"客戶"類的實(shí)例;對(duì)應(yīng)每個(gè)"客戶"類的實(shí)例,存在D〔2〕個(gè)"訂單"類的實(shí)例。供選擇的答案:

A0個(gè)B1個(gè)C1個(gè)或多個(gè)D0個(gè)或多個(gè)什么是關(guān)聯(lián)類?〔〕A它描述了可以存在于類之間的各種關(guān)系。B它在另外兩個(gè)類之間的關(guān)聯(lián)中添加屬性和/或行為。C它關(guān)聯(lián)對(duì)象和該對(duì)象所屬的類。為什么層在子系統(tǒng)設(shè)計(jì)中非常重要?〔〕〔多選題〕A更容易改變實(shí)現(xiàn)方式B減少了實(shí)現(xiàn)代碼中類的數(shù)量C提高了重用性D降低了復(fù)雜性如果兩個(gè)顧客在世界的不同地方,要購(gòu)買音樂(lè)會(huì)的最后一X票,如何分配這X票?〔〕參與者和角色之間的差別?A引入一個(gè)額外的業(yè)務(wù)規(guī)則,把可用票的查詢和臨時(shí)預(yù)定合并起來(lái)。參與者和角色之間的差別?B使顧客參與軟件"競(jìng)爭(zhēng)",以買到票。C不允許賣出最后一X票,因?yàn)檫@對(duì)其中的一位顧客是不公平的。如圖6-12所示:〔1〕X1、X2和X3是什么?〔〕〔單選題〕用例模型的用途就是列出系統(tǒng)中的用例和參與者A角色BPrimadonnasC參與者D用例模型的用途就是列出系統(tǒng)中的用例和參與者〔2〕下面哪個(gè)語(yǔ)句是正確的?〔〕〔多選題〕AX3可以使用UC4與系統(tǒng)交互。BX1可以使用UC1和UC4與系統(tǒng)交互。CX1、X2與X3不同。DUC3是沒(méi)有步驟的抽象用例。<3>下面哪個(gè)語(yǔ)句是正確的?〔〕〔多選題〕AUC5是UC4的補(bǔ)充部分。BUC4是UC5的可選部分。CUC1是沒(méi)有用的。DUC2是UC4的可選部分。EUC4是UC2的補(bǔ)充部分。如圖所示,下面哪些陳述是正確的?〔〕A汽車總是有相同的車身B一些汽車有備用輪胎C汽車有一個(gè)引擎,引擎在汽車之間不共享D所有的汽車都有四或五個(gè)輪胎E汽車必須有至少一個(gè)司機(jī)F乘客不可能是司機(jī)如圖,A、B和C是什么對(duì)象?AA是實(shí)體,B是控制者,C是邊界。BA是邊界,B是實(shí)體,C是控制者。CA是實(shí)體,B是邊界,C是控制者。DA是控制者,B是實(shí)體,C是邊界。.領(lǐng)域模型是一組表示<>,在設(shè)計(jì)工作中廣泛用來(lái)啟發(fā)設(shè)計(jì)軟件對(duì)象.A真實(shí)世界的概念類B虛擬世界的概念類C軟件部件的模型D硬件部件的模型UML提供了一系列的圖支持面向?qū)ο蟮姆治雠c設(shè)計(jì),其中____<1>_F__給出系統(tǒng)的靜態(tài)設(shè)計(jì)視圖;___<2>___B_對(duì)系統(tǒng)的功能進(jìn)行組織和建模是非常重要的;____<3>_C__和____<4>__E_都是描述系統(tǒng)動(dòng)態(tài)視圖的交互圖,其中___<5>_C__描述了以時(shí)間順序組織的對(duì)象之間的交互活動(dòng),___<6>_E___強(qiáng)調(diào)收發(fā)消息的對(duì)象的組織結(jié)構(gòu)。A狀態(tài)圖B用例圖C序列圖D部署圖E協(xié)作圖F類圖類是一組具有相同屬性的和相同服務(wù)的對(duì)象的抽象描述,類中的每個(gè)對(duì)象都是這個(gè)類的一個(gè)〔1〕c。類之間共享屬性與服務(wù)的機(jī)制稱為d〔2〕。一個(gè)對(duì)象通過(guò)發(fā)送b〔3〕來(lái)請(qǐng)求另一個(gè)對(duì)象為其服務(wù)?!?〕A例證 B用例 C實(shí)例 D例外〔2〕A多態(tài)性 B動(dòng)態(tài)綁定 C靜態(tài)綁定 D繼承〔3〕A調(diào)用語(yǔ)句 B消息 C命令 D口令領(lǐng)域模型又稱為〔〕A.業(yè)務(wù)流程模型 B.用例模型C.概念模型 D.設(shè)計(jì)模型在面向?qū)ο蟮姆椒▽W(xué)中,對(duì)象可看成是屬性與對(duì)于這些屬性的專用服務(wù)的封裝體。封裝是一種〔1〕技術(shù),封裝的目的是使對(duì)象的〔2〕分離?!?〕A組裝 B產(chǎn)品化 C固化D信息隱藏〔2〕A定義和實(shí)現(xiàn) B設(shè)計(jì)和測(cè)試C設(shè)計(jì)和實(shí)現(xiàn) D分析和定義如果你想對(duì)一個(gè)類的意義進(jìn)行描述,那么應(yīng)該采用?A.標(biāo)記值 B.規(guī)格描述C.注釋 D.構(gòu)造型軟件復(fù)用是面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)的核心支持技術(shù)之一,軟件復(fù)用的核心是〔〕。A對(duì)象類B軟件構(gòu)件技術(shù)C設(shè)計(jì)模式D模塊軟件測(cè)試通常采用黑盒測(cè)試和白盒測(cè)試。其中黑盒測(cè)試根據(jù)軟件的〔a〕設(shè)計(jì)測(cè)試用例,白盒測(cè)試根據(jù)軟件的〔c〕設(shè)計(jì)測(cè)試用例。A.功能規(guī)格說(shuō)明B.需求說(shuō)明C.內(nèi)部結(jié)構(gòu)和邏輯D.?dāng)?shù)據(jù)流圖將軟件從一種計(jì)算機(jī)環(huán)境轉(zhuǎn)換到另一種環(huán)境運(yùn)行的難易程度是指軟件的〔B〕。在規(guī)定的條件下和規(guī)定的時(shí)間間隔內(nèi),按設(shè)計(jì)要求,軟件成功運(yùn)行的特性稱為〔A〕。A.可靠性B.可移植性C.可使用性D.靈性原型化方法是動(dòng)態(tài)確定軟件需求的方法之一,該方法適應(yīng)于〔〕的系統(tǒng)。A.需求不確定性高B.需求確定C.結(jié)構(gòu)簡(jiǎn)單D.可移植性好瀑布模型是傳統(tǒng)的軟件開發(fā)過(guò)程模型,它強(qiáng)調(diào)各階段的嚴(yán)格性,其主要缺點(diǎn)是〔〕。A.需要軟件人員和用戶進(jìn)行溝通B.需要付較高的維護(hù)成本C.開發(fā)的軟件不易于移植D.不適應(yīng)需求不確定的軟件開發(fā)軟件設(shè)計(jì)中的〔〕設(shè)計(jì)指定各個(gè)組件之間的通信方式以與各組件之間如何相互作用。是什么語(yǔ)言?A.?dāng)?shù)據(jù)B.接口C.結(jié)構(gòu)D.組件是什么語(yǔ)言?〔〕不是面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言。A.XMLB.JavaC.C#D.Simula在畫SSD圖時(shí),應(yīng)該如何對(duì)待所涉與的系統(tǒng):A.詳細(xì)描述其內(nèi)部結(jié)構(gòu)與其功能;B.簡(jiǎn)單描述其內(nèi)部結(jié)構(gòu),但是羅列系統(tǒng)所有的功能C.詳細(xì)描述其內(nèi)部結(jié)構(gòu),并不列出系統(tǒng)的功能D.不對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)與功能進(jìn)行描述.定義大多數(shù)的需求和X圍的工作是在UP中的階段完成的。A初始階段 B細(xì)化階段 C構(gòu)造階段 D提交階段下列不在UP的初始階段中完成的A編制簡(jiǎn)要的愿景文檔B粗略評(píng)估成本C定義大多數(shù)的需求D業(yè)務(wù)案例二、簡(jiǎn)答題統(tǒng)一過(guò)程中有哪四個(gè)階段,各階段需要完成的主要工作有哪些?答:1〕初始階段:編制簡(jiǎn)要的愿景文檔、業(yè)務(wù)案例、確定X圍、粗略評(píng)估成本。2〕細(xì)化階段:細(xì)化愿景文檔、迭代地實(shí)現(xiàn)核心構(gòu)架、解決高風(fēng)險(xiǎn)的問(wèn)題、定義大多數(shù)的需求和X圍、進(jìn)一步評(píng)估成本3〕構(gòu)造階段:迭代地實(shí)現(xiàn)系統(tǒng)的其余部分、準(zhǔn)備部署4〕提交階段:beta測(cè)試、部署統(tǒng)一過(guò)程中的核心工作流有哪些?答:業(yè)務(wù)建模、需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試。UP的核心思想有哪些?答:短時(shí)間盒的迭代式開發(fā)開發(fā)過(guò)程中不斷進(jìn)行調(diào)整在早期的迭代中解決高風(fēng)險(xiǎn)和高價(jià)值的主要問(wèn)題不斷與用戶銜接,與時(shí)得到反饋意見早期注意構(gòu)造核心的體系結(jié)構(gòu)早期進(jìn)入實(shí)現(xiàn)和測(cè)試,不斷進(jìn)行質(zhì)量檢驗(yàn)使用用況〔usecase〕可視化建?!灿肬ML〕仔細(xì)地管理需求控制變更什么是增量開發(fā)?答:增量開發(fā)包括兩層意思:1〕對(duì)復(fù)雜的用況分多次迭代,一部分一部分地實(shí)現(xiàn)2〕將所有用況按其優(yōu)先級(jí)分別安排在不同的迭代中實(shí)現(xiàn)三、畫圖題已知三個(gè)類A.B和C.其中類A由類B的一個(gè)實(shí)類和類C的1個(gè)或多個(gè)實(shí)類構(gòu)成.請(qǐng)畫出能夠正確表示類A,B和C之間關(guān)系的UML類圖。畫出下面場(chǎng)景的順序圖1.收款員〔Cashier〕啟動(dòng)一次銷售<makeNewSale<>>2.收款員輸入商品標(biāo)識(shí)<enterItem<itemID,quantity>>3.銷售結(jié)束,系統(tǒng)計(jì)算并顯示總金額〔endSale〔〕〕4.顧客付款,系統(tǒng)〔System〕處理支付。<makePayment<amount>>下面一段代碼為UserInfo類和Company類的定義的代碼,請(qǐng)根據(jù)代碼畫出類圖〔類與其關(guān)系〕,并標(biāo)記出類之間關(guān)系的重?cái)?shù)。publicclassUserInfo{privateCompanyoneCompany;//……其他的成員定義}publicclassCompany{privateArrayListallUserInfo;//……其他的成員定義}找出下面場(chǎng)景中的概念類:〔1〕.顧客帶著購(gòu)買的商品或服務(wù)來(lái)到POS收款臺(tái)〔2〕.收款員啟動(dòng)一次銷售〔3〕.收款員輸入商品標(biāo)識(shí)〔4〕.系統(tǒng)記錄商品,并且顯示該商品說(shuō)明,價(jià)格,并計(jì)算總金額。按一組計(jì)價(jià)規(guī)則計(jì)算單價(jià)。四、案例分析PizzaBase案例分析PizzaBase飯館想把顧客預(yù)定比薩的過(guò)程自動(dòng)化。每X桌子都配備一個(gè)觸摸式屏幕,顧客可以用它瀏覽所供應(yīng)的比薩,并點(diǎn)菜。該飯館供應(yīng)兩種基本類型的比薩:自助類只有西紅柿醬,顧客可以選擇任意數(shù)量的配料,每種配料的價(jià)格都是固定的。預(yù)制類有幾個(gè)小類,每個(gè)小類都有固定的配料。每種比薩都可以預(yù)定酥脆型和松軟型,有三種規(guī)格:6英寸、9英寸和顧客還可以預(yù)定飲料,例如可樂(lè)類和檸檬類,每種飲料都有大杯和小杯兩種規(guī)格。顧客確認(rèn)了預(yù)定的食物后,就顯示總價(jià)。之后,屏幕顯示食物的準(zhǔn)備和烹飪進(jìn)度。在顧客吃完后,可以以方便的方式付費(fèi)。〔1〕在PizzaBase案例分析中,在分析階段的屬性列表是哪一個(gè)?〔〕A可樂(lè)、基本類型、價(jià)格、規(guī)格、檸檬、付費(fèi)方式B口味、品種、付費(fèi)方式、總價(jià)、顯示、肉類、西紅柿C進(jìn)度、品種、口味、價(jià)格、觸摸式屏幕、規(guī)格、飲料D基本類型、價(jià)格、品種、規(guī)格、進(jìn)度、口味〔2〕如圖所示,哪個(gè)圖是PizzaBase飯館中比薩的最佳模型?〔〕A圖1B圖2C圖3〔3〕在PizzaBase案例分析中,分析類最有可能是哪個(gè)列表?〔〕APayment,Order,Drink,Topping,Pizza,Restaurant,Base,SauceBCustomer,Table,Pizza,Topping,Drink,Restaurant,OrderCPi

溫馨提示

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

最新文檔

評(píng)論

0/150

提交評(píng)論