UML試題及答案

1、【用例圖】1. 用例圖的節(jié)點包括（ ABD）A用例B、邊界C、關聯(lián)D執(zhí)行者2. 用例之間的關系主要有（ BCD）A聚合B、繼承C擴展D包含3. 在采用用例模型捕獲需求時，需要執(zhí)行如下（ABCD操作A描述非功能需求 B、用例建模C、識別用例D、識別參與者4. 在識別用例時，以下（ABC問題可以幫助識別用例A當系統(tǒng)狀態(tài)發(fā)生故障時，是否需要通知參與者B、系統(tǒng)是否存在外部事件，如果存在，是哪個能參與者通知系統(tǒng)這些個部事件C參與者希望系統(tǒng)為他提供什么樣的功能D系統(tǒng)運行環(huán)境是什么5. 在用例圖中，可以用（D來表示整個軟件系統(tǒng)或其中一些子系統(tǒng) 的邊界，也可以用它表示軟件系統(tǒng)的不同發(fā)布版本的功能范圍A執(zhí)行者B

2、、關聯(lián)關系C、用例D邊界框6. （ B）作為完成用例任務的責任承擔者，協(xié)調(diào)、控制其他類共同完 成用例規(guī)定的功能或行為A數(shù)據(jù)對象 B控制類 C實體類D、邊界類7. 基于用例圖的需求捕獲的第一步就是確定系統(tǒng)的參與者，在尋找 系統(tǒng)參與者時，可以根據(jù)以下（ ABCD 等問題來確定A系統(tǒng)同環(huán)境如何進行交互B、由誰安裝系統(tǒng)C系統(tǒng)為哪些對象提供信息、服務D系統(tǒng)的使用者是誰8. 如果用例 B 是用例 A 的某項子功能，并且建模者確切地知道在 A 所對應的動作序列中何時將調(diào)用 B,則稱（A）A用例A擴展用例BB、用例A繼承用例BC用例A包括用例BD用例A實現(xiàn)用例B9. 如果用例A與用例B相似，但A的動作序列是通

3、過改寫B(tài)的部分 或者擴展B的動作而獲得的，則稱（B）A、用例A實現(xiàn)用例BB、用例A繼承用例BC用例A擴展用例BD用例A包括用例B10. 如果用例A與用例B相似，但A的功能較B多，A的動作序列是 通過在B的動作序列中的某些執(zhí)行點上插入附加的動作序列而構成 的，則稱（ C）A、用例A擴展用例BB、用例A包含用例BC用例A繼承用例BD用例A實現(xiàn)用例B11. 在UML中，（A）表示使用軟件系統(tǒng)的功能，與軟件系統(tǒng)交換信 息的外部實體A執(zhí)行者B、類C、用例D、用例圖12. 在用例圖中，執(zhí)行者之間的關系只有（B） 種A包含B、繼承C、擴展D、實現(xiàn)【靜態(tài)圖】1. 對于類，其屬性的可見性表示對類的外部世界的可見

4、性，它有以下（ABCD選項A、公開（PubliC ） B、包內(nèi)公開（PaCkage） C、保護（ProteCted ）D 私有（PriVate ）2. 在UML中，以下（ABCD是可以應用于包的構造型A、框架FrameworkB、虛包FacadeC子系統(tǒng)SubsystemD系統(tǒng)SyStem3. 兩個類之間的關聯(lián)表示他們之間存在一種不適于繼承的邏輯關 系。在關聯(lián)關系的表示圖元的兩端，可以表示參與關聯(lián)的（ ABCD 特 性。A、約束B、可見性C、角色名D、多重性4. 用例之間的關系主要有（ ABC）A、包含B、繼承C、擴展D、聚合5. 在構件中圖中，（D）用于顯示構件之間的關聯(lián)關系。A節(jié)點B、包C

5、構件D依賴關系6. （D）用于描述相互合作的對象間的交互關系的鏈接關系。A類圖B、通信圖C、用例圖D協(xié)作圖7. （D）是一種不包含操作的實現(xiàn)部分的特殊類。A概念類B、分析類C、實現(xiàn)類 D接口8. 在類圖中，（C）說明允許候選值范圍，如集合可以設定的大小?？梢哉f明可能用于關聯(lián)端、 組成類中的部分、 消息迭代次數(shù)和其他目 的。A角色B、多重性C注釋D、監(jiān)護條件9泛化使得（A）操作成為可能，即操作的實現(xiàn)是由它們所使用的對 象的類，而不是由調(diào)用確定的。A多態(tài)B、多重C、傳參D、傳值10. 將下圖中的接口映射為JaVa代碼，具有（D）形式。A、private interface ServiceB、pro

6、tect interface SerVice.C、Void interface SerVice.D、public interface SerVice11. (A)關系是類元的一般描述和具體描述之間的關系，具體描述 建立在一般描述的基礎之上， 并對其進行了擴展， 具體描述與一般描 述完全一致所有特性、成員和關系，并且包含補充的信息，它用從子 指向父的箭頭表示，指向父的是一個空三角形。A泛化B、繼承C、組成D、聚集12. (C)使用類圖的一個子集，用于強化某個時間點類實例之間的 關系。A交互圖B、協(xié)作圖C對象圖D狀態(tài)圖13. ( A)是用來反映代碼的物理結構。A構件圖B、用例圖C、類圖D、狀態(tài)機1

7、4. 類元之間的(A)將一個對象的兩個版本以連續(xù)一方式連接起來， 它表示一個對象的值、 狀態(tài)和位置的轉換， 可以將類元角色在一次相 互作用中連接起來。A流B、依賴C、泛化D、關聯(lián)15. ( D)是對象與其外界相互關聯(lián)的唯一途徑。A函數(shù)調(diào)用B、接口 C、狀態(tài)轉換 D消息傳遞16. 以下對部署圖說法正確的有( BCD)A部署圖有主要建模元素是構件B、使用部署圖可以顯示運行時系統(tǒng)的結構，同時還傳達構成應用程 序的硬件和軟件的配置的部署方式C從部署圖中，可以了解到軟件與硬件之間物理關系及處理節(jié)點的 組件分布情況D部署圖（deployment,配置圖）是用來顯示系統(tǒng)中軟件和硬件的物 理結構17. 利用部

8、署圖，可以（ ABCD）A探究系統(tǒng)和生產(chǎn)環(huán)境中的其它系統(tǒng)的依賴關系，這些系統(tǒng)可能是 已經(jīng)存在，或是將要引入的B、探究系統(tǒng)投產(chǎn)的相關問題C描述一個應用主要的部署結構D描述一個商業(yè)應用主要的部署結構，描述一個組織的硬件網(wǎng)絡基 礎結構【動態(tài)圖】1. 活動圖的邊包括（ BC）A數(shù)據(jù)流B、控制流C對象流D、消息2. 在UML舌動圖中，（B）表示一個操作完成后對其后續(xù)操作的觸發(fā)。A信息流B、控制流C、初始活動D、活動3. 在UML活動圖中，（C）表示活動需要輸入的對象或者作為活動的 處理結果輸出的對象。A并發(fā)控制B、決策點C對象D、活動4. 在活動圖中，（C）是從多個源活動匯合到一個A活動B、初始節(jié)點和活

9、動終點 C結合D分叉5. （C）是一種特殊形式的狀態(tài)機，用于對計算流程和工作流程建模CA時間圖B、流程圖C活動圖D、狀態(tài)圖6. 在活動圖中，（D）表示一個具有子結構的純粹計算的執(zhí)行，通常為操作或位于其內(nèi)的聲明的調(diào)用成真實世界程序的執(zhí)行。A狀態(tài)B、活動C、順序狀態(tài) D活動狀態(tài)7. 對于活動圖，以下說法正確的有（ ABD）A活動圖適用于精確地描述單個用例中的處理流程，也可用來描述 多個用例聯(lián)合起來形成的處理流程， 表達相對復雜的業(yè)務操作或軟件 處理過程，有時甚至可以針對類中某個個復雜的操作用活動圖給出實 現(xiàn)細節(jié)B、活動圖中包含控制流和信息流，控制流表示一個操作完成后對其后續(xù)操作的觸發(fā)，信息流則刻畫

10、操作這間的信息交換C活動圖的基本建模機制包括節(jié)點、邊及泳道D活動圖描述實體為完成某項功能面執(zhí)行的操作序列，其中的某些操作或者操作的子序列可以并發(fā)和同步8. 在UML舌動較中，（A）表示操作之間的信息交換。A信息流B、控制流C、初始活動D、活動9. UML的（A）表示消息源發(fā)出消息后不必等待消息處理過程的返回， 即可繼續(xù)執(zhí)行自己的后續(xù)操作。A異步消息B、返回消息C、同步消息D、簡單消息10. 在UML順序圖中，（A）對消息傳遞的目標對象的銷毀。A、銷毀（destory ）消息B、創(chuàng)建（Create ）消息C返回消息D、自消息11. 在順序圖中，下圖表示（ D）A、帶時廷的消息B、自消息C、異步消

11、息D同步消息12. 在UML順序圖中，如果一條消息從對象a傳向對象b,那么其（A） 是一條從 b 指向 a 的虛線有向邊， 它表示原消息的處理已經(jīng)完成處理 結果（如果有的話）給返回消息傳回。A返回消息B、自消息C、創(chuàng)建（Create ）消息D、銷毀（destory） 消息13. （ B）用于概述相互合作的對象流的交互關系和鏈接關系。A用例圖B、通信圖C協(xié)作圖D、類圖14. 時間圖中，包含以下（BCD幾個部分。A、值生命線 B消息標簽和消息端點 C、狀態(tài)生命線D、消息15. 要狀態(tài)機圖中，（A）表示兩個狀態(tài)之間的關系，源狀態(tài)和目的 狀態(tài)。A、轉換B、狀態(tài)C、事件D監(jiān)護條件【綜合】1. 在UML的

12、最上一層，視圖被劃分為（ACD視圖域。A、模型管理B、擴展機制 C動態(tài)行為D、結構分類2. 以下屬于UML模型視圖的有（CDA行為視圖B、結構視圖 C部署視圖和構件視圖D、用例視圖3. 以下對UMLffl圖說法正確的有（ABCDA結構分類描述了系統(tǒng)中的結構成員及其相互關系。類元包括類、用例、構件和節(jié)點。類元為研究系統(tǒng)動態(tài)行為奠定了基礎。類元視圖 包括靜態(tài)視圖、用例視圖和實現(xiàn)視圖。B、動態(tài)行為描述了系統(tǒng)隨時間變化的行為。待業(yè)用從靜態(tài)視圖中抽 取的瞬間值的變化來描述。 動態(tài)行為視圖包括狀態(tài)機視圖、 活動視圖 和交互視圖C模型管理說明了模型的分層組織結構。 包是模型的基本組織單元。 特殊的包還包括模

13、型和子系統(tǒng)。 模型管理視圖跨越了其他視圖并根據(jù) 系統(tǒng)開發(fā)和配置組織這些視圖。D UML還包括多種具的擴展能力的組件，這些擴展能力有限但很有 用。這些組件包括約束、構造型和標記值，它們適用于所有的視圖元 素4. ( B)是一個類對象所可能經(jīng)歷的所有歷程的模型圖A模型管理視圖 B狀態(tài)機視圖C、動態(tài)視圖D、靜態(tài)視圖5. (C)可用于描述用戶接口、設備控制器和其他具有反饋的子系統(tǒng)。 它還可用于描述在生命期中跨越多個不同性質階段的被動對象的行 為，在每一階段該對象都有自己特殊的行為A動態(tài)視圖B靜態(tài)視圖C狀態(tài)機視圖D、模型管理視圖6. (C)是在分析模型的基礎上，添加了設計元素的結構，使得分析 模型更加接

14、近系統(tǒng)實現(xiàn)。A領域模型B、數(shù)據(jù)模型 C設計模型D、概念模型7. （A）可以用于幫助設計人員在UML莫型為模型定義約束信息，創(chuàng) 建更為精確的設計模型A OCL B表達式C、屬性D、變量8. 在的基礎上，對如下（ABCD的建模能力進行了增強A活動B、交互C、復雜結構D、狀態(tài)機9. 在界面設計中，通常屏幕的（D）表示與軟件系統(tǒng)的運行狀態(tài)無關、 在任何情況下均沒有變化的文本、圖標（ icon ）、圖形（ graph） 、 圖象（image）等A用戶命令元素B、用戶輸入元素C、動態(tài)元素 D靜態(tài)元素10. 在界面設計中，通常屏幕的（C）表示在屏幕上預留空位、由用 戶在界面操作中填寫或選擇的界面元素， 包括

15、可編輯的文本、 單選鈕（radio ）、多選框（CheCkboX）、選擇列表（SeIeCt IiSt ）等A 靜態(tài)元素B、動態(tài)元素 C用戶輸入元素D、用戶命令元素11. 對于一個學校的課程注冊管理系統(tǒng)， 如果有一條需求為“學生只 能查看本人選課計劃； 教師只能查看本人所開課程的學生信息； 教務 管理員可以查看所有信息?！?，該屬于（D）類型的需求A可配置性需求B、可移植性需求C、功能需求 D安全性12. 對于一個學校的課程注冊管理系統(tǒng)， 如果有一條需求為“目前在校學生 1000 名，教師 100 名；以后每年逐步遞增，預計五年且翻番， 要示軟件產(chǎn)品不需修改即可適應學校規(guī)模的擴張?！?，該屬于（ B

16、） 類型A、可配置性需求 B可伸縮性需求C、功能需求D、安全性需求13. 對于一個學校的課程注冊管理系統(tǒng)， 如果有一條需求為“本軟件 必須通過接口定義文檔規(guī)定的接口 API 與計費系統(tǒng)、學籍管理系統(tǒng)、 教師信息管理系統(tǒng)交互?！痹搶儆冢–）類型。A、 可集成性需求B 、可伸縮性需求C可互操作性需求D安全性需求14. 對與OCL說法正確的是（ABCDA使用OCL在模型的方法上定義不變量B、將OCL作為一種查詢語言C使用OCL對構造型（StereotyPeS ）定義前置和后置條件D使用OCLffi述類型的前置和后置條件15. UML的（B）是由建模者設計的新的建模元素，但是這個模型元素的設計要建立在

17、UML已定義的模型元素基礎上A標記值B、構造型C、注釋D、約束16. UML通過圖形化的表示機制從多個側面對系統(tǒng)的分析和設計模型進行刻畫，其中（C）包括構件圖，它描述軟件系統(tǒng)中各組成構件，構件的內(nèi)部結構以及構件之間的依賴關系A行為視圖B、結構視圖C構件視圖D、用例視圖【設計模式】1. 以下屬于面向對象的設計原則的有（）A、最少知識原則B、依賴倒轉原則C接口隔離原則D無循環(huán)依賴原則（包圖）ABCD2. 從模式所提供的解決方案的抽象程度來看， 模式可以分為 （ ）A測試模式B、面向軟件實現(xiàn)的設計模式C軟件子系統(tǒng)或構件設計模式D體系結構設計模式BCD3. 在設計模式中，（）的核心是緩存和共享A外觀模

18、式B、工廠模式C對象池模式D單例模式C4. 在面向對象的設計原則中，（）表示軟件實體應當對擴展開放， 對修改關閉，即軟件實體應當在不修改的前提下擴展。A單一責任原則 B開放封閉原則C、完全替換原則D、合成/聚合 復用原則5. （）將整個軟件系統(tǒng)劃分為模型、視圖和控制器三個部分。A MVC B分層模式C、管道模式D、架構模式6. 在面向對象的設計原則中，（）表示在一個新的對象里面使用一 些已有的對象， 便之成為新對象的一部分， 新的對象通過向這些對的 委派達到復用已有功能的目的。A完全替換原則B、開放封閉原則 C合成/聚合復用原則D單一 責任原則C7. 當使用單件（單例）設計模式時，可以獲得如下

19、（）優(yōu)點。A對唯一實例提供受控訪問B、縮小名稱空間C、允許對操作和表示進行精化操作D、運行可變數(shù)目的類實例數(shù)ABCD8. 設計（）的目的是，將目標軟件系統(tǒng)中依賴于系統(tǒng)運行環(huán)境的數(shù) 據(jù)存取部分與其他部分相分離。A外部接口 B、外觀模式 C數(shù)據(jù)持久存儲服務D、系統(tǒng)架構C9. 在面向對象的的設計原則中，（）表示高層模塊不應該依賴于低 層模塊，都應該依賴于抽象，抽象不應該依賴于細節(jié)，細節(jié)應該依賴 于抽象。A依賴倒轉原則B、開放封閉原則C、創(chuàng)建持久存儲服務 D唯一 責任原則A10. （）是指以設計復用為目的，采用一種良好定義、正規(guī)的、一致 的方式記錄的軟件設計經(jīng)驗。A.架構 B. 模型C.設計模式D.設

20、計數(shù)據(jù)C11. 在設計模式中，（）保證每個類只要單個實例。A. 工廠模式 B. 對象池模式 C. 外觀模式D.單例模式D12. 當客戶程序與抽象類的實現(xiàn)部分之間存在很大的依賴性時， 可以 考慮使用（）A、單例模式B、對象池模式C、工廠模式 D外觀模式D13. 當需要強調(diào)一系列相關產(chǎn)品對象的設計以便進行聯(lián)合使用， 可以 考慮使用（）。A. 工廠模式 B. 對象池模式 C. 外觀模式 D. 單 例模式A14. （）將整個軟件系統(tǒng)分為若干層次，最頂層直接面向用戶提供軟 件系統(tǒng)的操作界面。其余各層為緊鄰其上的層次提供服務。A. 分層模式C.架構模式 D. 管道模式A15. 在面向對象的原則中， （）表

21、示使用多個專門的接口比使用單一 的總接口要好，一個類對另一個來的依賴性應當是建立在最小的接口 上的。A.單一責任原則B.接口隔離原則 C. 依賴倒轉原則D. 合成 / 聚合復用原則B16. 在面向對象的設計原則中， （）表示在包的依賴關系圖中不允許 存在環(huán)。A. 最少知識原則 B. 依賴倒轉原則 C. 接口隔離原則D. 無循環(huán)依賴原則D17. 希望創(chuàng)建一個可復用的類， 該類必須能夠與接口不可預訂的類協(xié) 同工作，可以考慮使用（）A單例模式B、對象池模式C、工廠模式 D適配器模式D18. 在需要構建一個層次結構的子系統(tǒng)時， 可以使用門面模式定義子 系統(tǒng)中每層的入口點，可以考慮使用（）。A. 外觀模

22、式 B. 工廠模式 C. 對象池模式 D. 單例模式A19. 當需要在不同時刻指定、 排列和執(zhí)行請求是， 可以考慮使用 （）。A. 單例模式B. 命令模式 C. 工廠模式 D. 適配器模式B20. 當某個系統(tǒng)需要多個產(chǎn)品系列中的一個來配置， 可以考慮使用（）A單例模式B、對象池模式 C工廠模式D、外觀模式C【代碼重構】1. 在如下（）情況下，可以考慮使用重構A修改錯誤時B、復審程序代碼時C、添加功能時D、需求分析時ABC2. 當一個臨時變量僅僅在使用它的方法中可見，則用一個（），取 代變理會使得代碼更加易讀， 這也相當于為信息創(chuàng)建一個單獨的訪問 機制A提升方法重構B、采用查詢替換臨時變量重構

23、C、MoVe Method 重構 D、 Extract Method 重構B【新增】1、在UM沖，（）可以對模型元素進行有效組織，如類，用例,構件，從而構成具有一定意義的單元。A連接B包C構件D節(jié)點B2、UMLI過圖形化的表示機制從多個側面系統(tǒng)的分析和設計模型進 行刻畫，其中（ ）包括類圖、對象圖和包圖，他們分別從不同 的層表面表示系統(tǒng)的靜態(tài)結構。A 構件視圖 B 行為視圖 C 結構視圖 D 用例視圖3、以算法和數(shù)據(jù)結構為中心， 其系統(tǒng)功能有一系列的處理步驟構成， 相鄰的處理步驟之間數(shù)據(jù)流通管道相互連接（ ）A MVC B 分層模式 C 流程處理模式 D 架構模式C4、UMLI過圖形化的表示機

24、制從多個側面對系統(tǒng)的分析設計模型進行刻畫。其中（ ）包括交互圖、狀態(tài)圖與活動圖，他們從不同的側 面刻畫系統(tǒng)的動態(tài)行為。A 結構視圖 B 用例視圖 C 行為視圖 D 構件視圖C5、當需要支持日志修改時，可以考慮使用（ ）A 命令模式 B 工廠模式 C 單例模式 D 適配器模式A6、對于某些類來說，只有一個實例是非常重要的，例如，系統(tǒng)中可 以有都種類型的打印機， 但是只能有一個打印機假脫機， 只應該一個 文件系統(tǒng)和一個窗口管理器，為此，可以使用（）。A 對象模式 B 工廠模式 C 單例模式 D 外觀模式C7、（） 是在領域模型的基礎上，對系統(tǒng)驚醒進一步的分析獲得的，它 有三種非常有效的模型，實體類、控制類和邊界類。A 設計模型 B 分析模型 C 概念模型 D E-R 模型8、當一個抽象模型有兩個方面，其中一個方面依賴于另一方面，將 這兩者封裝在獨立的對象中以使它們可以各自獨立地改變和復用， 以考慮使用（）A觀察者模式B命令模式C適配器模式D單例模式A9、在需求分析中，實體類（）A負責保存目標軟件系統(tǒng)中具有持久意義的信息項并向其他類提供信息訪問的操作B作為完成用例任務的責任承擔者，負責協(xié)調(diào)，控制其他類共同完成用例規(guī)定的功能后行為C負責實現(xiàn)用戶的業(yè)務邏輯D負責目標軟件系統(tǒng)與外部執(zhí)行者之間的交互A10