系統(tǒng)分析師-面向?qū)ο蠓椒▽W(xué)(二)

1、系統(tǒng)分析師-面向?qū)ο蠓椒▽W(xué)（二）（總分：42.00，做題時(shí)間：90分鐘）一、B單項(xiàng)選擇題/B（總題數(shù)：11,分?jǐn)?shù)：42.00）類庫(kù)是一種預(yù)先定義的程序庫(kù)，它以程序模塊的形式，按照U U 1 /U /U把一組類的定義和實(shí)現(xiàn)組織在一起：U U 2 /U /U對(duì)類庫(kù)的建設(shè)提供了強(qiáng)有力的支持。（分?jǐn)?shù)：3.00）（1）.« A.類的功能« B.類層次結(jié)構(gòu)« C.實(shí)例之間的調(diào)用關(guān)系« D.類的類型（分?jǐn)?shù)：1.00）A.B. VC.D.解析：（2）.* A.引用« B.重置4 C.類屬類« D.封裝（分?jǐn)?shù)：1.00）A.B.C. VD.解析：解析從

2、物理特征上來(lái)看，類庫(kù)和傳統(tǒng)例程庫(kù)是類似的，它們都是一種預(yù)先定義的程序庫(kù)。類庫(kù)是 一種預(yù)先定義的程序庫(kù)，它以程序模塊的形式，按照類層次結(jié)構(gòu)把一組類的定義和實(shí)現(xiàn)組織在一起。較上 層的類代表了較一般的事物，相反，較下層的類代表了較具體的事物，很好地體現(xiàn)了面向?qū)ο髾C(jī)制的繼承、重載等許多特征。類屬類（generic class）僅描述了適用于一組類型的通用樣板，由于其中所處理對(duì)象的數(shù)據(jù)類型尚未確定，因而程序員不可用類屬類直接創(chuàng)建對(duì)象實(shí)例，即一個(gè)類屬類并不是一種真正的類類型。類屬類必須經(jīng)過(guò)實(shí)例化后才能成為可創(chuàng)建對(duì)象實(shí)例的類類型。類屬類的實(shí)例化是指用某一數(shù)據(jù)類型替代類 屬類的類型參數(shù)。類屬類定義中給岀的類型

3、參數(shù)稱為形式類屬參數(shù)，類屬類實(shí)例化時(shí)給岀的類型參數(shù)稱為 實(shí)際類屬參數(shù)。如果類屬類實(shí)例化的實(shí)際類屬參數(shù)可以是任何類型，那么這種類屬類稱為無(wú)約束類屬類。然而在某些情況下，類屬類可能要求實(shí)際類屬參數(shù)必須具有某些特殊的性質(zhì)，以使得在類屬類中可應(yīng)用某 些特殊操作，這種類屬類稱為受約束類屬類。類屬類對(duì)類庫(kù)的建設(shè)提供了強(qiáng)有力的支持。（3）.用例（use+case）用來(lái)描述系統(tǒng)在對(duì)事件做出響應(yīng)時(shí)所采取的行動(dòng)。用例之間是具有相關(guān)性的。在一個(gè)“訂單輸入子系統(tǒng)”中，創(chuàng)建新訂單和更新訂單都需要核查用戶賬號(hào)是否正確。那么，用例“創(chuàng)建新訂單”、“更新訂單”與用例“核查客戶賬號(hào)”之間是U U /U /U關(guān)系。«

4、A.包含(include)« B.擴(kuò)展(extend)« C.分類(classification)« D.聚集(aggregation)(分?jǐn)?shù):1.00 )A. VB.C.D.解析：解析用例是在系統(tǒng)中執(zhí)行的一系列動(dòng)作，這些動(dòng)作將生成特定參與者可見(jiàn)的價(jià)值結(jié)果。它確定了 一個(gè)和系統(tǒng)參與者進(jìn)行交互并可由系統(tǒng)執(zhí)行的動(dòng)作序列。用例模型描述的是外部執(zhí)行者(actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開(kāi)發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開(kāi)發(fā)者和用 戶對(duì)需求規(guī)格達(dá)成的共識(shí)。兩個(gè)用例之間的關(guān)系可以概括為兩種情況。一種是用于重用的包含關(guān)系，用include表示

5、(在UML 1.x版本中用use表示)；另一種是用于分離出不同行為的擴(kuò)展，用extend表示(在UML 1x版本中用extends表示)。(1)包含關(guān)系。當(dāng)可以從兩個(gè)或兩個(gè)以上的原始用例中提取公共行為， 或者發(fā)現(xiàn)能夠使用一個(gè)構(gòu)件來(lái)實(shí)現(xiàn)某一個(gè)用例的部分功能很重要時(shí)，我們應(yīng)該使用包含關(guān)系來(lái)表示它們。(2)擴(kuò)展關(guān)系。如果一個(gè)用例明顯地混合了兩種或兩種以上的不同場(chǎng)景，即根據(jù)情況可能發(fā)生多種事情，則將這個(gè)用例分為一個(gè)主用例和一個(gè)或多個(gè)輔用例描述可能更加清晰。另外，用例之間還存在一種泛化關(guān)系。用例可以被特別列舉為一個(gè)或多個(gè)子用例，這被稱為用例泛化。當(dāng)父用例能夠被使用時(shí)，任何子用例也可 以被使用。例如，我們

6、購(gòu)買飛機(jī)票，既可以是電話訂票，也可以是網(wǎng)上訂票，則訂票用例就是電話訂票和 網(wǎng)上訂票的抽象。在UML中,對(duì)象行為是通過(guò)交互來(lái)實(shí)現(xiàn)的，是對(duì)象間為完成某一目的而進(jìn)行的一 系列消息交換。消息序列可用兩種圖來(lái)表示，強(qiáng)調(diào)消息時(shí)間次序的圖稱為 U U 4 /U /U，該圖的特點(diǎn)是U U 5 /U /U，強(qiáng)調(diào)參加交互的對(duì)象的組織圖稱為U U 6 /U /U，這兩種圖是UU 7 /U /U。(分?jǐn)?shù)：4.00)(1) .* A.活動(dòng)圖* B.狀態(tài)圖* C.順序圖* D.協(xié)作圖(分?jǐn)?shù)：1.00 )A.B.C. VD.解析：(2) .* A.有生命線及控制焦點(diǎn)，重點(diǎn)在消息的時(shí)間順序上* B.有路徑有順序號(hào)，為了一個(gè)消

7、息的時(shí)間順序給消息加數(shù)字前綴* C.是對(duì)系統(tǒng)、子系統(tǒng)或類的行為建模* D.本質(zhì)上是一個(gè)流程圖，顯示從活動(dòng)到活動(dòng)的信息流（分?jǐn)?shù):1.00）A. VB.C.D.解析：.« A.活動(dòng)圖 « B.狀態(tài)圖 « C.順序圖 « D.協(xié)作圖（分?jǐn)?shù):1.00 ）A.B.C.D. V解析：.A.同構(gòu)的，所以可以互相轉(zhuǎn)換B.異構(gòu)的，所以不可以互相轉(zhuǎn)換 C.強(qiáng)調(diào)對(duì)象行為的事件順序，常用于對(duì)反應(yīng)式系統(tǒng)建模« D.專注于系統(tǒng)的動(dòng)態(tài)視圖，狀態(tài)無(wú)法確定，所以不可以互相轉(zhuǎn)換（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：解析順序圖用來(lái)描述對(duì)象之間動(dòng)態(tài)的交互關(guān)系，著重體現(xiàn)對(duì)象間消

8、息傳遞的時(shí)間順序。順序圖允 許直觀地表示岀對(duì)象的生存期，在生存期內(nèi)，對(duì)象可以對(duì)輸入消息做岀響應(yīng)，并且可以發(fā)送信息。對(duì)象間的通信通過(guò)在對(duì)象的生命線間畫消息來(lái)表示。消息的箭頭指明消息的類型。順序圖中的消息可以是信號(hào)、操作調(diào)用或類似于 C+中的 RPC（Remote Procedure Call） 和 Java 中的 RMI（Remote Method Invocation） < 收到消息后，接收對(duì)象立即開(kāi)始執(zhí)行活動(dòng)，即對(duì)象被激活了。通過(guò)在對(duì)象生命線上顯示一個(gè)細(xì)長(zhǎng)矩形框來(lái) 表示激活。消息可以用消息名及參數(shù)來(lái)標(biāo)識(shí)，消息也可帶有順序號(hào)。消息還可帶有條件表達(dá)式，表示分支 或決定是否發(fā)送消息。如果用于

9、表示分支，則每個(gè)分支是相互排斥的，即在某一時(shí)刻僅可發(fā)送分支中的一 個(gè)消息。協(xié)作圖用于描述相互合作的對(duì)象間的交互關(guān)系和鏈接關(guān)系。雖然順序圖和協(xié)作圖都用來(lái)描述對(duì)象 間的交互關(guān)系，但側(cè)重點(diǎn)不一樣。順序圖著重體現(xiàn)交互的時(shí)間順序，協(xié)作圖則著重體現(xiàn)交互對(duì)象間的靜態(tài) 鏈接關(guān)系。順序圖和協(xié)作圖統(tǒng)稱為交互圖，是表示各組對(duì)象如何依某種行為進(jìn)行協(xié)作的模型。強(qiáng)調(diào)對(duì)象交 互行為時(shí)間順序時(shí)使用順序圖，強(qiáng)調(diào)對(duì)象協(xié)作關(guān)系時(shí)使用協(xié)作圖，它們之間沒(méi)有什么本質(zhì)不同，只是排版 不盡相同而已。用UML建立業(yè)務(wù)模型是理解企業(yè)業(yè)務(wù)過(guò)程的第一步。業(yè)務(wù)人員扮演業(yè)務(wù)中的角色及其交互方式，例如航空公司的售票員是業(yè)務(wù)人員，電話售票員也是業(yè)務(wù)人員，

10、他們之間的關(guān)系是U U 8 /U /U。在 UML中，用U U 9/U/U表示企業(yè)業(yè)務(wù)的工作流。這種圖顯示了工作流中的步驟、決策點(diǎn)，以及完成每一步驟的角色和對(duì)象。(分?jǐn)?shù)：3.00)(1) . A.關(guān)聯(lián)關(guān)系(Association)«B.依賴關(guān)系(Dependency)«C.聚集關(guān)系(Aggregation)«D.概括關(guān)系(Geneiralization)(分?jǐn)?shù)：1.00)A.B.C.D. V解析：.«A.活動(dòng)圖(activitv diagram)* B.業(yè)務(wù)圖(business diagram)« C.用例圖(use-case diagram)

11、«D.交互圖(interaction diagram)(分?jǐn)?shù)：1.00 )A. VB.C.D.解析：解析用UML建立業(yè)務(wù)模型時(shí)，可以把業(yè)務(wù)人員看做是系統(tǒng)中的角色或者類。在建立抽象模型時(shí)， 很少有類會(huì)單獨(dú)存在，大多數(shù)都將會(huì)以某種方式彼此通信，因此還需要描述這些類之間的關(guān)系。關(guān)系是事 物間的連接，在UML中，有幾個(gè)很重要的關(guān)系。(1)依賴關(guān)系。有兩個(gè)元素 A、B，如果元素A的變化會(huì)引起元素B的變化，則稱元素B依賴于元素A。在類中，依賴關(guān)系有多種表現(xiàn)形式，例如，一個(gè)類向另一個(gè) 類發(fā)消息；一個(gè)類是另一個(gè)類的成員；一個(gè)類是另一個(gè)類的某個(gè)操作參數(shù)等。(2)泛化關(guān)系。描述了一般事物與該事物中的特殊

12、種類之間的關(guān)系，也就是父類與子類之間的關(guān)系。繼承關(guān)系是泛化關(guān)系的反關(guān)系， 也就是說(shuō)子類是從父類中繼承的，而父類則是子類的泛化。在UML中，對(duì)泛化關(guān)系有3個(gè)要求。子類應(yīng)與父類完全一致，父類所具有的關(guān)聯(lián)、屬性和操作，子類都應(yīng)具有。子類中除了與父類一致的信息外，還包括額外的信息。可以使用父類實(shí)例的地方，也可以使用子類實(shí)例。(3)關(guān)聯(lián)關(guān)系。關(guān)聯(lián)表示兩個(gè)類的實(shí)例之間存在的某種語(yǔ)義上的聯(lián)系。例如，一個(gè)老師為某所學(xué)校工作，一所學(xué)校有多間教室。我們就認(rèn) 為老師和學(xué)校、學(xué)校和教室之間存在著關(guān)聯(lián)關(guān)系。關(guān)聯(lián)關(guān)系為類之間的通信提供了一種方式，它是所有關(guān) 系中最通用、語(yǔ)義最弱的。關(guān)聯(lián)關(guān)系通?？梢栽偌?xì)分成以下兩種：聚集關(guān)

13、系。聚集關(guān)系(聚合關(guān)系)是關(guān)聯(lián)關(guān)系的特例，表示一種整體和部分的關(guān)系，其中整體和部分的生命周期不相同。例如，電話機(jī)和話筒的關(guān)系，計(jì)算機(jī)和顯示器的關(guān)系等都是聚集關(guān)系的例子。組合關(guān)系。組合關(guān)系也是表示一種整體和部分的關(guān)系，其中整體和部分的生命周期相同。例如，公司與部門之間的關(guān)系就是組合關(guān)系的例子。(4)實(shí)現(xiàn)關(guān)系。類之間的語(yǔ)義關(guān)系，其中的一個(gè)類指定了由另一個(gè)類保證執(zhí)行的契約。在UML中，活動(dòng)圖用來(lái)表示系統(tǒng)中各種活動(dòng)的次序，它的應(yīng)用非常廣泛，既可用來(lái)描述用例的工作流程，也可用來(lái)描述類中某個(gè)方法的 操作行為?；顒?dòng)圖是由狀態(tài)圖變化而來(lái)的，它們各自用于不同的目的?；顒?dòng)圖依據(jù)對(duì)象狀態(tài)的變化來(lái)捕獲 動(dòng)作(將要執(zhí)行

14、的工作或活動(dòng))與動(dòng)作的結(jié)果。活動(dòng)圖中一個(gè)活動(dòng)結(jié)束后將立即進(jìn)入下一個(gè)活動(dòng)(在狀態(tài)圖中狀態(tài)的變遷可能需要事件的觸發(fā))。(3).在CORB/體系結(jié)構(gòu)中，負(fù)責(zé)屏蔽底層網(wǎng)絡(luò)通信細(xì)節(jié)的協(xié)議是U U /U /U。« A.IDL« B.RPC« C.ORB« D.GIOP（分?jǐn)?shù):1.00 ）A.B.C. VD.解析：解析ORB（Object Request Broker，對(duì)象請(qǐng)求代理）作為一個(gè)“軟件總線"來(lái)連接網(wǎng)絡(luò)上的不同對(duì)象，提供對(duì)象的定位和方法調(diào)用，它是CORBAT現(xiàn)的關(guān)鍵。GIOP（General Intel-ORB Protocol，通用ORB之間的協(xié)

15、議）定義了一個(gè)不同 ORB之間的接口。GIOP是CORBAT法調(diào)用的核心部分。GIOP不基于任何特別的網(wǎng)絡(luò)協(xié)議，如IPX或TCP/IP。為了確?；ゲ僮餍?，OMG、須將GIOP定義在所有供應(yīng)商都支持的特定傳輸 之上。如果有詳細(xì)和簡(jiǎn)潔的消息規(guī)范，則不會(huì)提供互操作性，因?yàn)樗泄?yīng)商都使用不同的傳送機(jī)制來(lái)實(shí) 現(xiàn)這個(gè)互操作性。IDL（Interface DefinitionLanguage，接口定義語(yǔ)言）定義客戶和服務(wù)器之間的靜態(tài)接口，通過(guò)編譯器生成客戶存根、服務(wù)器框架，以及根據(jù)支持的語(yǔ)言映射，自動(dòng)生成來(lái)自一個(gè)CORBA IDL的代碼。目前支持的語(yǔ)言映射包括：Java、C+ Ada、SmallTalk和

16、Cobol等。CORBADL是由對(duì)象管理組織（Object Management Group）為定義所有的 CORBAT面而制定的。RPC（遠(yuǎn)程過(guò)程調(diào)用）是一種協(xié)議，程序可使用這種協(xié)議向網(wǎng)絡(luò)中的另一臺(tái)計(jì)算機(jī)上的程序請(qǐng)求服務(wù)。由于使用RPC的程序不必了解支持通信的網(wǎng)絡(luò)協(xié)議的情況，因此 RPC提高了程序的互操作性。在RPC中，發(fā)岀請(qǐng)求的程序是客戶程序，而提供服務(wù)的程序是服務(wù)器。在面向?qū)ο蠹夹g(shù)中，一個(gè)子類的對(duì)象同時(shí)又屬于父類，它繼承了父類的一切屬性， 這種多態(tài)性稱為U U 11 /U /U。同一個(gè)算子在不同的表達(dá)式中可能有不同的操作意義，這種多態(tài)性稱為U U 12 /U /U。編譯程序根據(jù)上下文判定

17、算子的操作意義，這稱為 U U 13 /U /U。（分?jǐn)?shù)：3.00 ）（1）.« A.參數(shù)多態(tài)* B.過(guò)載多態(tài)« C.包含多態(tài)* D.隱含多態(tài)（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：（2）.* A.參數(shù)多態(tài)* B.過(guò)載多態(tài)* C.包含多態(tài)* D.隱含多態(tài)（分?jǐn)?shù):1.00）A.B. VC.D.解析：.« A.算子鑒別B.算子操作« C.算子定義 « D.算子運(yùn)算（分?jǐn)?shù):1.00 ）A. VB.C.D.解析：解析在面向?qū)ο蠹夹g(shù)中，多態(tài)考慮的是類與類之間的層次關(guān)系，以及類自身內(nèi)部特定成員函數(shù)之 間的關(guān)系問(wèn)題，解決功能和行為的再抽象問(wèn)題。多態(tài)是指

18、類中具有相似功能的不同函數(shù)用同一個(gè)名稱來(lái)實(shí) 現(xiàn)，從而可以使用相同的調(diào)用方式來(lái)調(diào)用這些具有不同功能的同名函數(shù)。這也是人類思維方式的一種直接 模擬，比如一個(gè)對(duì)象中有很多求兩個(gè)數(shù)最大值的行為，雖然可以針對(duì)不同的數(shù)據(jù)類型，寫很多不同名稱的 函數(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ù)。嚴(yán)格地說(shuō)，多態(tài)性可分為4類，分別為過(guò)載多態(tài)（重載多態(tài)）、強(qiáng)制多態(tài)、包含多態(tài)和參數(shù)多態(tài)，其中前兩種統(tǒng)稱為專 用多態(tài)（特定多態(tài)），后面兩種也稱為通用多態(tài)。包含多態(tài)是研究類族中定義于不同類中的同名成

19、員函數(shù)的多態(tài)行為，主要通過(guò)虛函數(shù)來(lái)實(shí)現(xiàn)。包含多態(tài)最常見(jiàn)的例子就是子類型化，即一個(gè)類型是另一類型的子類 型。參數(shù)多態(tài)的應(yīng)用比較廣泛，被稱為最純的多態(tài)。這是因?yàn)橥粚?duì)象、函數(shù)或過(guò)程能以一致的形式用于 不同的類型。參數(shù)多態(tài)與類屬（類模板）相關(guān)聯(lián)，類屬是一個(gè)可以參數(shù)化的模板，其中包含的操作所涉及的 類型必須用類型參數(shù)實(shí)例化。這樣，由類模板實(shí)例化的各類都具有相同的操作，而操作對(duì)象的類型卻各不 相同。過(guò)載多態(tài)是同一算子（操作符、函數(shù)名等）被用來(lái)表示不同的功能，通過(guò)上下文以決定一個(gè)算子所代 表的功能，即通過(guò)語(yǔ)法對(duì)不同語(yǔ)義的對(duì)象使用相同的算子，編譯能夠消除這一模糊。強(qiáng)制多態(tài)是通過(guò)語(yǔ)義操作把一個(gè)變?cè)念愋图右宰?/p>

20、換，以符合一個(gè)函數(shù)的要求，如果不做這一強(qiáng)制性變換將岀現(xiàn)類型錯(cuò)誤。類 型的變換可在編譯時(shí)完成，通常是隱式地進(jìn)行，當(dāng)然也可以在動(dòng)態(tài)運(yùn)行時(shí)來(lái)做。從實(shí)現(xiàn)的角度來(lái)看，多態(tài)可劃分為兩類，分別是編譯時(shí)的多態(tài)和運(yùn)行時(shí)的多態(tài)。前者是在編譯的過(guò)程中確定同名操作的具體操作對(duì) 象，而后者則是在程序運(yùn)行過(guò)程中才動(dòng)態(tài)地確定操作所針對(duì)的具體對(duì)象。這種確定操作的具體對(duì)象的過(guò)程 就是聯(lián)編（編聯(lián)、束定或綁定）。聯(lián)編是指計(jì)算機(jī)程序自身彼此關(guān)聯(lián)的過(guò)程，也就是把一個(gè)標(biāo)識(shí)符名和一個(gè) 存儲(chǔ)地址聯(lián)系在一起的過(guò)程；用面向?qū)ο蟮男g(shù)語(yǔ)講，就是把一條消息和一個(gè)對(duì)象的方法相結(jié)合的過(guò)程。按照聯(lián)編進(jìn)行階段的不同，可以分為兩種不同的聯(lián)編方法，分別為靜態(tài)聯(lián)編

21、和動(dòng)態(tài)聯(lián)編，這兩種聯(lián)編過(guò)程分 別對(duì)應(yīng)著多態(tài)的兩種實(shí)現(xiàn)方式。聯(lián)編工作在編譯連接階段完成的情況稱為靜態(tài)聯(lián)編。因?yàn)槁?lián)編過(guò)程是在程序開(kāi)始執(zhí)行之前進(jìn)行的，因此有時(shí)也稱為早期聯(lián)編或前聯(lián)編。在編譯和連接過(guò)程中，系統(tǒng)就可以根據(jù)類型 匹配等特征確定程序中操作調(diào)用與執(zhí)行該操作代碼的關(guān)系，其確定了某一個(gè)同名標(biāo)識(shí)到底是要調(diào)用哪一段 程序代碼。有些多態(tài)類型，其同名操作的具體對(duì)象能夠在編譯、連接階段確定，通過(guò)靜態(tài)聯(lián)編解決，比如 過(guò)載、強(qiáng)制和參數(shù)多態(tài)等。和靜態(tài)聯(lián)編相對(duì)應(yīng)，聯(lián)編工作在程序運(yùn)行階段完成的情況稱為動(dòng)態(tài)聯(lián)編，也稱為晚期聯(lián)編或后聯(lián)編。在編譯、連接過(guò)程中無(wú)法解決的聯(lián)編問(wèn)題，要等到程序開(kāi)始運(yùn)行之后再來(lái)確定，包 含多態(tài)的操

22、作對(duì)象的確定就是通過(guò)動(dòng)態(tài)聯(lián)編完成的。在面向?qū)ο蠓治鲞^(guò)程中，用概念模型來(lái)詳細(xì)描述系統(tǒng)的問(wèn)題域，用U U 14 /U /U來(lái)表示概念模型；用U U 15 /U /U來(lái)描述對(duì)象行為。（分?jǐn)?shù)：5.00）（1）.« A.順序圖B.類圖« C.協(xié)作圖« D.用例圖（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：.« A.順序圖和協(xié)作圖« B.用例圖和活動(dòng)圖« C.狀態(tài)圖和活動(dòng)圖« D.用例圖和構(gòu)件圖（分?jǐn)?shù)：1.00 ）A. VB.B. VD.解析：解析在面向?qū)ο蠓治鲞^(guò)程中，用概念模型來(lái)詳細(xì)描述系統(tǒng)的問(wèn)題域，用類圖來(lái)表示概念模型。問(wèn) 題域是

23、指一個(gè)包含現(xiàn)實(shí)世界事物與概念的領(lǐng)域，這些事物和概念與所設(shè)計(jì)的系統(tǒng)要解決的問(wèn)題有關(guān)。而建 立概念模型，又稱為問(wèn)題域建模、域建模，也就是找到代表那些事物與概念的對(duì)象。（3）.在UML中，U U /U /U把活動(dòng)圖中的活動(dòng)劃分為若干組，并將劃分的組指定給對(duì)象，這些對(duì)象必須履行該組所包括的活動(dòng)，它能夠明確地表示哪些活動(dòng)是由哪些對(duì)象完成的。* A.組合活動(dòng)* B.同步條* C.活動(dòng)* D.泳道（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：解析在UML中，活動(dòng)圖中的活動(dòng)可以分成幾個(gè)區(qū)域，每個(gè)區(qū)域在圖中用虛線分開(kāi)，因此被叫做泳 道。泳道是活動(dòng)圖的內(nèi)容的組織單元。它沒(méi)有內(nèi)在的語(yǔ)義，但可以根據(jù)建模者的意愿使用。

24、通常，每個(gè)泳 道代表現(xiàn)實(shí)世界組織內(nèi)的一個(gè)組織單元。在活動(dòng)圖中，泳道用矩形框來(lái)表示，屬于某個(gè)泳道的活動(dòng)放在該 矩形框內(nèi)，將對(duì)象名放在矩形框的頂部，表示泳道中的活動(dòng)由該對(duì)象負(fù)責(zé)。（4）.在較高的抽象層次上，傳統(tǒng)的程序流程圖與UML中活動(dòng)圖最根本的區(qū)別在于U U /U /U« A.程序流程圖明確地指定了每個(gè)活動(dòng)的先后順序，而活動(dòng)圖僅描述了活動(dòng)和必要的工作順序B.活動(dòng)圖不能提供循環(huán)控制結(jié)構(gòu)，而程序流程圖提供C.活動(dòng)圖不能表示并發(fā)活動(dòng)，而程序流程圖可以表示并發(fā)活動(dòng)« D.兩者采用不同的圖形符號(hào)系統(tǒng)（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：解析在UML中，活動(dòng)圖描述活動(dòng)的次序，既支

25、持條件行為，也支持并發(fā)行為。它是狀態(tài)圖的一種變形，其中多數(shù)狀態(tài)都是活動(dòng)狀態(tài)。條件行為用分支與合并描述，并發(fā)行為是用分岔和匯合指明的。UML的活動(dòng)圖與傳統(tǒng)的程序流程圖有一定的相似性。程序流程圖明確地指定了每個(gè)活動(dòng)的先后順序，而活動(dòng)圖 僅描述了活動(dòng)和必要的工作順序，這是活動(dòng)圖和流程圖的最根本的區(qū)別。另外，流程圖一般都限于順序進(jìn) 程，而活動(dòng)圖則可以支持并發(fā)進(jìn)程。（5）.在關(guān)于用例的描述中，錯(cuò)誤的是 U U /U /U。* A.用例將系統(tǒng)的功能范圍分解成許多小的系統(tǒng)功能陳述B. 一個(gè)用例代表了系統(tǒng)的一個(gè)單一的目標(biāo)* C.用例是一個(gè)行為上相關(guān)的步驟序列« D.用例描述了系統(tǒng)與用戶的交互（分?jǐn)?shù)：

26、1.00 ）A.B.C.D. V解析：解析用例是在系統(tǒng)中執(zhí)行的一系列動(dòng)作，這些動(dòng)作將生成特定參與者可見(jiàn)的價(jià)值結(jié)果（一個(gè)目標(biāo)）。用例確定了一個(gè)和系統(tǒng)參與者進(jìn)行交互并可由系統(tǒng)執(zhí)行的動(dòng)作序列。用例模型描述的系統(tǒng)與用戶的交互， 是參與者所理解的系統(tǒng)功能，用于需求分析階段，它的建立是系統(tǒng)開(kāi)發(fā)者和用戶反復(fù)討論的結(jié)果，表明了 開(kāi)發(fā)者和用戶對(duì)需求規(guī)格達(dá)成的共識(shí)。在用例建模的過(guò)程中，若幾個(gè)用例執(zhí)行了同樣的功能步驟，這時(shí)可以把這些公共 步驟提取成獨(dú)立的用例，這種用例稱為U U 19 /U /U。在UML的用例圖上，將用例之間的這種關(guān)系標(biāo)記為U U 20 /U /U。（分?jǐn)?shù): 2.00 ）（1）.A.擴(kuò)展用例* B

27、.抽象用例* C.公共用例* D.參與用例（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：.« A.association« B.extend« C.include* D.inheritances（分?jǐn)?shù):1.00 ）A.B.C. VD.解析：解析請(qǐng)參考試題2的分析。UMI提供了 4種結(jié)構(gòu)圖用于對(duì)系統(tǒng)的靜態(tài)方面進(jìn)行可視化、詳述、構(gòu)造和文檔化。 其中U U 21 /U /U是面向?qū)ο笙到y(tǒng)建模中最常用的圖，用于說(shuō)明系統(tǒng)的靜態(tài)設(shè)計(jì)視圖；當(dāng)需要說(shuō)明系統(tǒng)的靜態(tài)實(shí)現(xiàn)視圖時(shí)，應(yīng)該選擇UU 22 /U /U;當(dāng)需要說(shuō)明體系結(jié)構(gòu)的靜態(tài)實(shí)施視圖時(shí)，應(yīng)該選擇UU 23 /U /U。（分?jǐn)?shù)：

28、10.00）（1）.« A.構(gòu)件圖* B.類圖« C.對(duì)象圖* D.部署圖（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：（2）.* A.構(gòu)件圖* B.協(xié)作圖* C.狀態(tài)圖* D.部署圖（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：.« A.協(xié)作圖« B.對(duì)象圖« C.活動(dòng)圖« D.部署圖（分?jǐn)?shù):1.00 ）A.B.C.D. V解析：解析從應(yīng)用的角度看，當(dāng)采用面向?qū)ο蠹夹g(shù)設(shè)計(jì)系統(tǒng)時(shí)，第一步是描述需求；第二步是根據(jù)需求 建立系統(tǒng)的靜態(tài)模型，以構(gòu)造系統(tǒng)的結(jié)構(gòu)；第三步是描述系統(tǒng)的行為。其中，第一步與第二步中所建立的 模型都是靜態(tài)的，包括類圖（

29、含包圖）、對(duì)象圖、構(gòu)件圖和配置圖等，是UML的靜態(tài)建模機(jī)制。第三步中所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時(shí)的時(shí)序狀態(tài)或交互關(guān)系。它包括用例圖、狀態(tài)圖、活動(dòng)圖、順 序圖和協(xié)作圖（通信圖）等，是UML的動(dòng)態(tài)建模機(jī)制。因此，UML的主要內(nèi)容也可以歸納為靜態(tài)建模機(jī)制和動(dòng)態(tài)建模機(jī)制兩大類。說(shuō)明：有些文獻(xiàn)將用例圖歸結(jié)為靜態(tài)建模機(jī)制。（4）.面向?qū)ο笙到y(tǒng)中有兩種基本的復(fù)用方式：框架復(fù)用和類庫(kù)復(fù)用。下列關(guān)于框架和類庫(kù)的描述不正確的是U U /U /U。 A.框架是一個(gè)“半成品”的應(yīng)用程序B.類庫(kù)只包含一系列可被應(yīng)用程序調(diào)用的類« C.框架會(huì)為一個(gè)特定的目的實(shí)現(xiàn)一個(gè)基本、可執(zhí)行的架構(gòu)D.類庫(kù)是框架的

30、一種擴(kuò)展形式（分?jǐn)?shù)：1.00）A.B.C.D. V解析：解析框架與類庫(kù)都可以認(rèn)為是一種基礎(chǔ)結(jié)構(gòu)，而我們編寫的代碼是應(yīng)用代碼，若是基礎(chǔ)代碼調(diào)用應(yīng)用代碼，則這種基礎(chǔ)結(jié)構(gòu)是框架。反之，若是應(yīng)用代碼調(diào)用基礎(chǔ)代碼，則這種基礎(chǔ)結(jié)構(gòu)是類庫(kù)。框架是一個(gè)“半成品”的應(yīng)用程序，而類庫(kù)只是包含一系列可被應(yīng)用程序調(diào)用的類。類庫(kù)給用戶提供了一系列可 復(fù)用的類，這些類的設(shè)計(jì)都符合面向?qū)ο笤瓌t和模式。用戶使用時(shí)，可以創(chuàng)建這些類的實(shí)例，或從這些類 中繼承岀新的派生類，然后調(diào)用類中相應(yīng)的功能。在這一過(guò)程中，類庫(kù)總是被動(dòng)地響應(yīng)用戶的調(diào)用請(qǐng)求。框架則會(huì)為某一特定目的實(shí)現(xiàn)一個(gè)基本、可執(zhí)行的架構(gòu)?？蚣苤幸呀?jīng)包含了應(yīng)用程序從啟動(dòng)到運(yùn)行的

31、主要 流程，流程中那些無(wú)法預(yù)先確定的步驟留給用戶來(lái)實(shí)現(xiàn)。程序運(yùn)行時(shí)，框架系統(tǒng)自動(dòng)調(diào)用用戶實(shí)現(xiàn)的功能 組件。這時(shí)，框架系統(tǒng)的行為是主動(dòng)的。所以，可以說(shuō)類庫(kù)是死的，而框架是活的。應(yīng)用程序通過(guò)調(diào)用類 庫(kù)來(lái)完成特定的功能，而框架則通過(guò)調(diào)用應(yīng)用程序來(lái)實(shí)現(xiàn)整個(gè)操作流程。框架是控制倒轉(zhuǎn)原則的完美體現(xiàn)。應(yīng)用程序和框架系統(tǒng)之間依賴關(guān)系的特點(diǎn)：（1）應(yīng)用程序和框架系統(tǒng)之間實(shí)際上是雙向調(diào)用，雙向依賴的關(guān)系。（2）依賴倒轉(zhuǎn)原則可以減弱應(yīng)用程序到框架之間的依賴關(guān)系。（3）控制反轉(zhuǎn)及具體的模板方法模式可以消解框架到應(yīng)用程序之間的依賴關(guān)系，這也是所有框架系統(tǒng)的基礎(chǔ)。（4）框架系統(tǒng)可以獨(dú)立重用。注：依賴是兩個(gè)模型元素之間的關(guān)

32、系，被依賴的模型元素發(fā)生變化就會(huì)影響到另一個(gè)模型元素。依賴倒轉(zhuǎn)（Dependency Inversion Principle） 的定義：上層模塊不應(yīng)該依賴于下層模塊，它們共同依賴于一個(gè)抽象；抽象不能依賴于具象，具象依賴于抽象。其含意是：為了消解兩個(gè)模塊間的依賴關(guān)系，應(yīng)該在兩個(gè)模塊之 間定義一個(gè)抽象接口，上層模塊調(diào)用抽象接口定義的函數(shù)，下層模塊實(shí)現(xiàn)該接口。（5）.下列有關(guān)面向?qū)ο蟮臄⑹霾徽_的是U U /U /U。 A.面向?qū)ο笤O(shè)計(jì)最根本的意圖是適應(yīng)需求變化 B.應(yīng)盡量針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程«C.盡量使用繼承而不是組合，因?yàn)槔^承使得類問(wèn)的耦合性最小D.盡量使用已有的類庫(kù)（分?jǐn)?shù)

33、：1.00）A.B.C. VD.解析：解析本題所考查的是面向?qū)ο笤O(shè)計(jì)的一些基本原則，這些原則如下：開(kāi)閉原則：一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。在設(shè)計(jì)一個(gè)模塊時(shí)，應(yīng)當(dāng)使這個(gè)模塊可以在不被修改的情況下被擴(kuò)展。關(guān)鍵在于抽象，抽象層要預(yù)見(jiàn)所有可能的擴(kuò)展，因此抽象層在任何擴(kuò)展情況下都不會(huì)改變，即對(duì)修改關(guān)閉。同時(shí)，由于從抽象層導(dǎo)出一個(gè)或多個(gè)新類，可以有不同的實(shí)現(xiàn)，改變系統(tǒng)的行為，此即對(duì)擴(kuò)展開(kāi)發(fā)。簡(jiǎn)而 言之，抽象層對(duì)修改關(guān)閉，通過(guò)擴(kuò)展實(shí)現(xiàn)改變系統(tǒng)行為。里氏代換原則：任何基類可以岀現(xiàn)的地方，子類一定可以岀現(xiàn)。依賴原則：要依賴于抽象，而不是具體實(shí)現(xiàn)。也可以這樣說(shuō)，要針對(duì)接口編程，不要 針對(duì)實(shí)現(xiàn)編程。接口分

34、離原則：應(yīng)當(dāng)為客戶端提供盡量小的單獨(dú)的接口，而不是提供大的接口。組合復(fù)用原則：要盡量使用組合而不是繼承關(guān)系達(dá)到復(fù)用目的。迪米特法則：又叫最少知識(shí)法則，就是說(shuō)一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象有盡可能少的了解。有關(guān)這些原則的詳細(xì)介紹，請(qǐng)學(xué)習(xí)指定教材系統(tǒng)分析師教程（張友生，清華大學(xué)出版社）第節(jié)。（6）.當(dāng)U U /U /U時(shí)，用例是捕獲系統(tǒng)需求最好的選擇。«A.系統(tǒng)具有很少的用戶* B.系統(tǒng)具有很少的接口C.系統(tǒng)算法復(fù)雜，功能單一«D.系統(tǒng)有很多參與者（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：解析用例模型描述的是用戶與系統(tǒng)的交互，是開(kāi)發(fā)者與用戶交流的工具，可用來(lái)很好地定義系統(tǒng) 的邊界。

35、所以，當(dāng)用戶較多時(shí)，采用用例能夠較好地捕獲系統(tǒng)需求。（7）.現(xiàn)有兩個(gè)用例UC1和UC2,其中UC2是一個(gè)完整的用例，可被實(shí)例化，而 UC儒要UC2中的事件流才 可被實(shí)例化，且UC1指定了使用UC2的精確位置，則UC1和 UC2之間的關(guān)系是“ U U /U /U ”* A.include* B.extend* C.generalize* D.call（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：解析題目中描述的用例間的關(guān)系為包含關(guān)系，使用include。（8）.下列關(guān)于面向?qū)ο蟮姆治雠c設(shè)計(jì)的描述，正確的是U U /U /U。*A.面向?qū)ο笤O(shè)計(jì)描述軟件要做什么« B.面向?qū)ο蠓治霾恍枰?/p>

36、慮技術(shù)和實(shí)現(xiàn)層面的細(xì)節(jié)« C.面向?qū)ο蠓治龅妮斎胧敲嫦驅(qū)ο笤O(shè)計(jì)的結(jié)果D.面向?qū)ο笤O(shè)計(jì)的結(jié)果是簡(jiǎn)單的分析模型（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：解析在面向?qū)ο蠓椒▽W(xué)中，面向?qū)ο蠓治觯∣OA）的結(jié)果是面向?qū)ο笤O(shè)計(jì)（OOD）的輸入，面向?qū)ο笤O(shè)計(jì)的結(jié)果是面向?qū)ο蟮某绦蛟O(shè)計(jì) （OOP ）的輸入。顯然，面向?qū)ο蟮姆治鍪敲枋鲕浖鍪裁?，而不需要考慮技術(shù)和實(shí)現(xiàn)層面的細(xì)節(jié)。（9）.協(xié)作圖主要描述對(duì)象間的交互與連接，它U U /U /U。* A.能夠表示消息的順序和嵌套關(guān)系* B.能夠表示消息的順序關(guān)系，但不能表示消息的嵌套關(guān)系* C.能夠表示消息的嵌套關(guān)系，但不能表示消息的順序關(guān)系* D.

37、既不能表示消息的順序關(guān)系，也不能表示消息的嵌套關(guān)系（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：解析協(xié)作圖能夠通過(guò)消息編號(hào)來(lái)表示消息的順序和嵌套關(guān)系。（10）.下列關(guān)于 UML敘述正確的是U U /U /U。* A.UML是一種語(yǔ)言，語(yǔ)言的使用者不能對(duì)其擴(kuò)展« B.UML僅是一組圖形的集合* C.UML僅適用于系統(tǒng)的分析與設(shè)計(jì)階段* D.UML是獨(dú)立于軟件開(kāi)發(fā)過(guò)程的（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：解析統(tǒng)一建模語(yǔ)言（Unified Modeling Language，UML）是一個(gè)通用的可視化建模語(yǔ)言，用于對(duì)軟 件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)制品的文檔。它記錄

38、了對(duì)必須構(gòu)造的系統(tǒng)的決定和理解， 可用于對(duì)系統(tǒng)的理解、設(shè)計(jì)、瀏覽、配置、維護(hù)和信息控制。UML適用于各種軟件開(kāi)發(fā)方法、軟件生命周期的各個(gè)階段、各種應(yīng)用領(lǐng)域及各種開(kāi)發(fā)工具，UML是一種總結(jié)了以往建模技術(shù)的經(jīng)驗(yàn)并吸收當(dāng)今優(yōu)秀成果的標(biāo)準(zhǔn)建模方法。UML包括概念的語(yǔ)義、表示法和說(shuō)明，提供了靜態(tài)、動(dòng)態(tài)、系統(tǒng)環(huán)境及組織結(jié)構(gòu)的模 型。它可被交互的可視化建模工具所支持，這些工具提供了代碼生成器和報(bào)表生成器。UML標(biāo)準(zhǔn)并沒(méi)有定義一種標(biāo)準(zhǔn)的開(kāi)發(fā)過(guò)程，但它適用于迭代式的開(kāi)發(fā)過(guò)程。它是為支持大部分現(xiàn)存的面向?qū)ο箝_(kāi)發(fā)過(guò)程而設(shè) 計(jì)的。已知3個(gè)類O P和Q類O中定義了一個(gè)私有方法F1、一個(gè)公有方法F2和一個(gè) 受保護(hù)的方法F

39、3;類P和類Q為類O的派生類，其繼承方式如下所示： class P : protected O class Q : public O在關(guān)于方法F1的描述中正確的是U U 31 /U /U。在關(guān)干方法F2的描述中正確的是U U 32 /U /U。在關(guān)于方法F3的描述中正確的是U U 33 /U /U。（分?jǐn)?shù)：3.00 ）（1）.*A. 方法F1無(wú)法被訪問(wèn)B. 只有在類0內(nèi)才能訪問(wèn)方法F1C. 只有在類P內(nèi)才能訪問(wèn)方法F1D. 只有在類Q內(nèi)才能訪問(wèn)方法F1（分?jǐn)?shù):1.00 )A.B. VC.D.解析：(2) .A. 類O P和Q的對(duì)象都可以訪問(wèn)方法F2B. 類P和Q的對(duì)象都可以訪問(wèn)方法 F2C.

40、類0和Q的對(duì)象都可以訪問(wèn)方法 F2D. 只有在類P內(nèi)才能訪問(wèn)方法F2（分?jǐn)?shù):1.00 )A.B.C. VD.解析：(3) .*A. 類O P和Q的對(duì)象都可以訪問(wèn)方法F3B. 類O P和Q的對(duì)象都不可以訪問(wèn)方法F3C. 類O的對(duì)象可以訪問(wèn)方法 F3,但類P的對(duì)象不能訪問(wèn)方法 F3D. 類P的對(duì)象可以訪問(wèn)方法 F3,但類Q的對(duì)象不能訪問(wèn)方法 F3（分?jǐn)?shù):1.00 )A.B. VC.D.解析：解析類實(shí)際上就是由一組描述對(duì)象屬性或狀態(tài)的數(shù)據(jù)項(xiàng)和作用在這些數(shù)據(jù)項(xiàng)上的操作（或稱為方法、成員函數(shù)等）構(gòu)成的封裝體。類的定義由關(guān)鍵字class打頭，后跟類名，類名之后的括號(hào)內(nèi)是類體，最后以“；”結(jié)束。 類與C中的

41、結(jié)構(gòu)大致相似，其不同之處在于類中規(guī)定了哪些成員可以訪問(wèn)，哪些成員不 可以訪問(wèn)。這些都通過(guò)訪問(wèn)指明符予以說(shuō)明。訪問(wèn)指明符有三種，分別是private、protected 和public。private成員私有化，除了該類的成員函數(shù)以外，誰(shuí)也不能訪問(wèn)它們。public成員公有化，程序中的所有函數(shù)（不管是類內(nèi)定義的還是類外定義的），都可以訪問(wèn)這些成員。protected 成員受限保護(hù)，只有該類及該類的子類的成員函數(shù)才能夠訪問(wèn)。在類的成員定義中，如果沒(méi)有指明符，則系統(tǒng)默認(rèn)為private。要注意的是，在C+中，一個(gè)類的友元是可以訪問(wèn)該類的所有成員的。繼承的限定也有三種，分別是private（私有繼承）

42、、protected（ 保護(hù)繼承）和public（ 公有繼承）。在public 繼承時(shí)，派生類（子類）的public、private、 protected型的成員函數(shù)可以訪問(wèn)基類中的public成員和protected成員，派生類的對(duì)象僅可訪問(wèn)基類中的public成員。在private 繼承時(shí)，派生類的 public、private、protected 型的成員函數(shù)可以訪問(wèn)基類 中的public成員和protected 成員，但派生類的對(duì)象不可以訪問(wèn)基類中的任何成員。在protected 繼承時(shí)，派生類的public、private、protected 型的成員函數(shù)可以訪問(wèn)基類中的public

43、 成員和protected 成員，但派生類的對(duì)象不可以訪問(wèn)基類中的任何成員。使用class關(guān)鍵字定義類時(shí)，默認(rèn)的繼承方式是private :也就是說(shuō)，當(dāng)繼承方式為 private 繼承時(shí)，可以省略叫 Private。在本題中，已知 3個(gè)類Q P和Q,類0 中定義了一個(gè)私有方法F1、一個(gè)公有方法F2和一個(gè)受保護(hù)的方法 F3;類P和類Q為類O的派生類，且P是保護(hù)繼承方式，Q是公有繼承方式。因?yàn)?F1是類O的私有方法，因此，只有在類O內(nèi)才能訪問(wèn)方法F1。F2是類O的公有方法，所以類O和Q的對(duì)象都可以訪問(wèn)方法 F2。F3是類O的受保護(hù)的方法，因此，類OP和Q的對(duì)象都不能訪問(wèn)方法F3o在一個(gè)客戶信息系統(tǒng)

44、中存在兩種類型的客戶：個(gè)人客戶和集團(tuán)客戶。對(duì)于個(gè)人客 戶，系統(tǒng)中保存了其客戶標(biāo)識(shí)和基本信息（包括姓名、住宅電話和E-mail）;對(duì) 于集團(tuán)客戶，系統(tǒng)中保存了其客戶標(biāo)識(shí)，以及與該集團(tuán)客戶相關(guān)的若干個(gè)聯(lián)系人 的信息（聯(lián)系人的信息包括姓名、住宅電話、E-mail、辦公電話和職位）。根據(jù)上述描述，得到了如圖7-1所示的UML類圖，其中類“客戶”的屬性有U U 34 /U /U;類“人”的屬性有U U 35 /U /U。I （分?jǐn)?shù)：3.00）（1）.* A.客戶標(biāo)識(shí)« B.姓名、住宅電話、 E-mail* C.姓名、住宅電話、辦公電話、E-mail、職位* D.客戶標(biāo)識(shí)、辦公電話、職位（分?jǐn)?shù)：

45、1.00 ）A. VB.C.D.解析：（2）.* A.客戶標(biāo)識(shí)* B.姓名、住宅電話、 E-mail* C.姓名、住宅電戶、辦公電話、E-mail、職位* D.客戶標(biāo)識(shí)、辦公電話、職位（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：解析因?yàn)樵囶}已經(jīng)給岀了有關(guān)類的描述?？蛻舭▊€(gè)人客戶和集團(tuán)客戶，因此，“客戶”類是“個(gè)人客戶”類和“集團(tuán)客戶”類的超類，即“客戶”類應(yīng)該有的屬性為“個(gè)人客戶”類和“集團(tuán)客戶”類的 公共屬性，即客戶標(biāo)識(shí)、姓名、住宅電話和E-mail。但是，在備選答案中，“客戶標(biāo)識(shí)”和“姓名、住宅電話和E-mail ”是分開(kāi)的，因此，第(34)空的正確答案為 A即把“姓名、住宅電話和E-

46、mail ”既作為“個(gè) 人客戶”類的屬性，也作為“集團(tuán)客戶”類的屬性。在本題中，“聯(lián)系人”類是“人”類的子類，“個(gè)人客戶”類與“人”類發(fā)生關(guān)聯(lián)，而“集團(tuán)客戶”類與“聯(lián)系人”類發(fā)生關(guān)聯(lián)。因此，“人”的屬性為應(yīng)該 包括“個(gè)人客戶”類和“集團(tuán)客戶”類的公共屬性，即“姓名、住宅電話和E-mail”。即第(35)空的正確答案為Bo(3) .根據(jù)圖7-2所示的UML圖可知，類Car和類Boat中的move()方法U U /U /UA. 引用了類 Transport 的 move()方法 B.重置了類 Transport 的 move()方法 C.是類 Transport 的 move() 方法的聚集D.是

47、類Transport的move()方法的泛化(分?jǐn)?shù)：1.00 )A.B. VC.D.解析：解析在面向?qū)ο蟮恼Z(yǔ)言中，可以定義一些不含方法體的方法，將其交給該類的子類根據(jù)自己的情況去實(shí)現(xiàn)。這樣的方法叫抽象方法，包含抽象方法的類叫抽象類。抽象方法用abstract修飾符來(lái)定義，任何帶有抽象方法的類都必須聲明為抽象類。抽象類不能被實(shí)例化，也就是不能用new關(guān)鍵字去產(chǎn)生對(duì)象。抽象方法只需聲明，不需要實(shí)現(xiàn)。含有抽象方法的類必須被聲明為抽象類，抽象類的子類必須覆蓋所有的 抽象方法后才能被實(shí)例化，否則這個(gè)子類還是個(gè)抽象類。在圖7-2中，因?yàn)門ransport類是一個(gè)抽象類，因此其子類Car和Boat的方法mo

48、ve()是對(duì)Transport類的方法move()的重置。在UML勺通用機(jī)制中，U U 37 /U /U用于把元素組織成組；U U 38 /U/U是系統(tǒng)中遵從一組接口規(guī)范且付諸實(shí)現(xiàn)的物理的、可替換的軟件模塊。(分?jǐn)?shù)：2.00 )(1).* A.包* B.類* C.接口* D.構(gòu)件（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：（2）.* A.包* B.類* C.接口* D.構(gòu)件（分?jǐn)?shù)：1.00 ）A.B.C.B. V解析：解析在UML勺通用機(jī)制中，包用于把元素組織成組；構(gòu)件是系統(tǒng)中遵從一組接口規(guī)范且付諸實(shí)現(xiàn) 的物理的、可替換的軟件模塊?；卣{(diào)（Callback）函數(shù)是面向過(guò)程的程序設(shè)計(jì)語(yǔ)言中常用的

49、一種機(jī)制，而設(shè)計(jì)模式中的U U 39 /U/U模式就是回調(diào)機(jī)制的一個(gè)面向?qū)ο蟮奶娲?。該模式的意圖是U U 40 /U /U。（分?jǐn)?shù)：4.00）（1）.« A.Strategy（策略）« B.Adapter（適配器）« C.Command 命令）« D.Observer（觀察者）（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：（2）.« A.使原本由于接口不兼容而不能一起工作的那些類可以一起工作B.將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，將請(qǐng)求排隊(duì)或記錄請(qǐng)求 日志，支持可撤銷的操作 C.定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一

50、個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都 得到通知并被自動(dòng)更新« D.使算法可獨(dú)立于使用它的客戶而變化（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：解析Command（命令）模式將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化， 對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤銷的操作。Comman（模式抽象出待執(zhí)行的動(dòng)作以參數(shù)化某對(duì)象， 我們可用面向過(guò)程語(yǔ)言中的回調(diào)函數(shù)表達(dá)這種參數(shù)化機(jī)制。所謂回調(diào)函數(shù)，是指函數(shù)先在某處注冊(cè)，而在 稍后某個(gè)需要的時(shí)候被調(diào)用。Comman（模式是回調(diào)機(jī)制的一個(gè)面向?qū)ο蟮奶娲?。Command模式在不同的時(shí)刻指定、排列和執(zhí)行請(qǐng)求。一個(gè)Command

51、寸象可以有一個(gè)與初始請(qǐng)求無(wú)關(guān)的生存期。如果一個(gè)請(qǐng)求的接收者可用一種與地址空間無(wú)關(guān)的方式表達(dá)，那么就可將負(fù)責(zé)該請(qǐng)求的命令對(duì)象傳送給另一個(gè)不同的進(jìn)程并 在那兒實(shí)現(xiàn)該請(qǐng)求。Command模式支持取消操作。Comman（模式的Execute操作可在實(shí)施操作前將狀態(tài)存 儲(chǔ)起來(lái)，在取消操作時(shí)這個(gè)狀態(tài)用來(lái)消除該操作的影響。Comman（接 口必須添加一個(gè) Unexecute操作，該操作取消上一次Execute調(diào)用的效果。執(zhí)行的命令被存儲(chǔ)在一個(gè)歷史列表中?？赏ㄟ^(guò)向后和向前遍歷這一 列表并分別調(diào)用Unexecute和Execute來(lái)實(shí)現(xiàn)重?cái)?shù)不限的"取消”和"重做”。Command模式支持修改日志，這樣當(dāng)系統(tǒng)崩潰時(shí)，這些修改可以被重做一遍。在Comman（接 口中添加裝載操作和存儲(chǔ)操作，可以用來(lái)保持