安徽工業(yè)大學(xué)《UML系統(tǒng)建模與分析設(shè)計(jì)》復(fù)習(xí)資料

1、論述基于 UML 的軟件開發(fā)的 一般過(guò)程 答：UML 是按 OO 思想進(jìn)行系統(tǒng)建模時(shí)使用的一組表示法，它并不對(duì)采用何種 OO 分析、設(shè)計(jì)以及開發(fā)過(guò)程模型構(gòu)成限制?；?UML 的軟件開發(fā)通常是以體系結(jié)構(gòu)為中心，用例驅(qū)動(dòng)的迭代和增量式開發(fā)，并結(jié)合職責(zé)分配模式進(jìn)行具體設(shè)計(jì)。開發(fā)過(guò)程可以包括計(jì)劃和細(xì)化、迭代的構(gòu)造和實(shí)施 3 大階段。在經(jīng)過(guò)一個(gè)初步的計(jì)劃和細(xì)化階段后，進(jìn)入若干 迭代構(gòu)造開發(fā)周期，每個(gè)周期都包含分析、設(shè)計(jì)、構(gòu)造和測(cè)試步驟。 （1）計(jì)劃和細(xì)化：通過(guò)各種傳統(tǒng)的需求獲取手段（調(diào)查、訪談、原型等）得出 系統(tǒng)目標(biāo)、系統(tǒng)功能和系統(tǒng)屬性，撰寫系統(tǒng)規(guī)格說(shuō)明?；趨⑴c者和外部事件（動(dòng)賓詞組）構(gòu)建用例，以增

2、 進(jìn)對(duì)領(lǐng)域過(guò)程和功能需求的 理解做什么。按照風(fēng)險(xiǎn) 、業(yè)務(wù)主線及對(duì)體系結(jié)構(gòu)的影響程度（系統(tǒng)屬性）劃分用例的優(yōu)先級(jí)，并據(jù)此決定用例的時(shí)間調(diào)度。對(duì)高優(yōu)先 用例采用擴(kuò)展格式細(xì)化。同時(shí)建立概念模型草案、系統(tǒng)體系結(jié)構(gòu)草案。 （2）分析階段：根據(jù)當(dāng)前周期的用例描述，采用概念目錄列表、非正式分析或 事務(wù)模式，識(shí)別出相關(guān)概念，建立初始概念模型，根據(jù)通用關(guān)聯(lián)列表和信息存儲(chǔ)的需要，為概念模型添加關(guān)聯(lián)和屬性。將用例分解為系統(tǒng)事件，并對(duì)應(yīng)系統(tǒng)操作，建立系統(tǒng)順序圖；分析系統(tǒng)操作被調(diào)用后系統(tǒng)狀態(tài)（概念）的變化，為系統(tǒng)操作建立契約，進(jìn)一步理解系統(tǒng)行為做的效果。 （3 ）設(shè)計(jì)階段：設(shè)計(jì)一個(gè)合理的體系結(jié)構(gòu)，建立真實(shí)用例 。針對(duì)每

3、個(gè)系統(tǒng)操作，使用操作契約和契約的后置條件以及用例描述文檔作為起點(diǎn)，按照職責(zé)分配模式或 BCE 模式為對(duì)象 （來(lái)自概念模型）分配職責(zé) ，通過(guò)協(xié)作圖體現(xiàn)對(duì)象間的 交互怎么做。同時(shí)參照概念模型和協(xié)作圖中的消息，建立設(shè)計(jì)類圖，并根據(jù)可見(jiàn)性要求設(shè)計(jì)關(guān)聯(lián) （4）構(gòu)造和測(cè)試階段：從設(shè)計(jì)類圖創(chuàng)建類的定義（屬性和方法原型），根據(jù)協(xié)作 圖創(chuàng)建方法實(shí)現(xiàn)。用 OOPL 實(shí)現(xiàn)設(shè)計(jì)制品到代碼的映射，對(duì)系統(tǒng)進(jìn)行相關(guān)的測(cè)試。 進(jìn)入下一個(gè)迭代周期，在制品同步以后，識(shí)別更多的需求，選取所需開發(fā)的用例，更新用例圖，擴(kuò)展概念模型，并運(yùn)用泛化、包和聚合等技術(shù)概括日益增多新概念，拓展系統(tǒng)順序圖和系統(tǒng)操作契約；運(yùn)用更多的職責(zé)分配模式進(jìn)行設(shè)

4、計(jì)（并根據(jù)需要設(shè)計(jì)與外部系統(tǒng)、其他子系統(tǒng)、持久化設(shè)施的交互機(jī)制）；進(jìn)一步構(gòu)造并測(cè)試。論述： 請(qǐng)談一談對(duì) OOD 中“一個(gè)中心”：開閉原則（OCP），“兩個(gè)基本點(diǎn)”：高內(nèi)聚，低耦 合，“四項(xiàng)基本原則”：Liskov 替換原則（L SP）,依賴倒置原則（DIP）,接口分離 原則（ISP），單一職責(zé)原則(SRP）的理解 開閉原則（OCP） OO 中最重要的設(shè)計(jì)原則,指一個(gè)模塊在擴(kuò)展性方面應(yīng)該是開放的，而在更改性方面應(yīng)該是封閉的 低耦合度：是在設(shè)計(jì)過(guò)程要記住的一個(gè)原則，它是一個(gè)時(shí)刻需要注意的隱含設(shè)計(jì)目標(biāo)。是一個(gè)檢驗(yàn)標(biāo)準(zhǔn)。 高聚合度：確保將復(fù)雜性保持在可控制的范圍內(nèi)，也是一個(gè)檢驗(yàn)標(biāo)準(zhǔn)。 Liskov 替

5、換原則 子類可以替換父類出現(xiàn)在父類能出現(xiàn)的任何地方. 軟件實(shí)體如果使用的是一個(gè)基類，那么一定適用于其子類，而且它根本不能察覺(jué)出基類對(duì)象和子類對(duì)象的區(qū)別。 依賴倒置原則依賴關(guān)系應(yīng)該是盡量依賴接口（或抽象）類，而不是依賴于具體類. 即針對(duì)接口編程，不要針對(duì)實(shí)現(xiàn)編程。 接口分離原則 一個(gè)類對(duì)另外一個(gè)類的依賴是建立在最小的接口上。設(shè)計(jì)時(shí)采用多個(gè)與特定客戶類（Client）有關(guān)的接口比采用一個(gè)通用接口更好. 單一職責(zé)原則:就一個(gè)類而言，應(yīng)該有且僅有一個(gè)引起它變化的原因。 論述前 5 個(gè)常用 GRAS P 職責(zé)分配模式的名稱、要點(diǎn)或意圖 專 家(expert)：將職責(zé) 分配給信息專 家掌握為 了履行職責(zé)所

6、 必需的信息的 類（誰(shuí)懂的 多就讓 誰(shuí)干） 創(chuàng)建者(creator)：大的對(duì) 象有責(zé)任創(chuàng)建小的對(duì)象，這是 OOD/P 中最常見(jiàn)的任務(wù)。 高聚合度或高內(nèi)聚(high cohesion)：是一個(gè)檢驗(yàn)標(biāo)準(zhǔn)，用于判斷一個(gè)類中的各個(gè)職責(zé)之間相關(guān)程度 和集中程度（可重用性的內(nèi)因）。 低 耦合度或低耦 合(low coupling)：是一 個(gè)檢驗(yàn)標(biāo)準(zhǔn)， 用于判斷類 間依賴程度 是否較小（可重用性的外在表現(xiàn)）。 控制者(controller)：誰(shuí)來(lái)統(tǒng)一協(xié)調(diào) 處理一個(gè)用例的各個(gè)系統(tǒng)事件，以使?fàn)顟B(tài)信息保持一致？ 論述后 4 個(gè)常用 GRAS P 職責(zé)分配模式的名稱、要點(diǎn)或意圖 多態(tài)：當(dāng)相關(guān)的可選擇的方法或行為隨著

7、類型變化時(shí)，將行為的職責(zé)使用多態(tài)(Polymorphism)的操作分配給那些行為變化的類型 純虛構(gòu)：給一個(gè)人造類分配一組高度內(nèi)聚的職責(zé)。人造類不代表問(wèn)題領(lǐng)域的任何事物它只是純虛構(gòu)的，為了支持高度的內(nèi)聚性、低耦合和重用。這個(gè)虛構(gòu)物的設(shè)計(jì)是非常干凈的或純的因此這是一個(gè)純虛構(gòu)。如持久存儲(chǔ)代理。 中介者：將職責(zé)分配給一個(gè)中間對(duì)象以便在其他構(gòu)件或服務(wù)之間進(jìn)行仲裁，這樣這些構(gòu)件或服務(wù)沒(méi)有被直接耦合。這個(gè)中間對(duì)象(intermediary) 在其他構(gòu)件或服務(wù)間創(chuàng)建一個(gè)中介者(Indirection)。如適配器、觀察者模式。 “不要和陌生人講話”： 分配職責(zé)給一個(gè)客戶端的直接對(duì)象以使它與一個(gè)間接對(duì)象進(jìn)行協(xié)作，

8、這樣客戶端就無(wú)需知道這個(gè)間接對(duì)象。目的是為了避免將一個(gè)客戶端同間接對(duì)象發(fā)生信息耦合和避免直接對(duì)象的內(nèi)部描述。 第 1 章 系統(tǒng)建模與分析設(shè)計(jì)技術(shù)的演變* 一、選擇題 ACDB 1封裝是指把對(duì)象的( A )結(jié)合在一起，組成一個(gè)獨(dú)立的對(duì)象。 A 屬性和操作 B信息流 C消息和事件 D數(shù)據(jù)的集合 2封裝是一種( C )技術(shù)，目的是使對(duì)象的生產(chǎn)者和使用者分離，使對(duì)象的定義和實(shí)現(xiàn)分開。 A工程化 B系統(tǒng)維護(hù) C信息隱蔽 D產(chǎn)生對(duì)象 3面向?qū)ο蠓椒ㄖ械? D )機(jī)制使子類可以自動(dòng)地?fù)碛?復(fù)制)父類全部屬性和操作。 A約束 B對(duì)象映射 C信息隱蔽 D繼承 4使得在多個(gè)類中能夠定義同一個(gè)操作或?qū)傩悦?，并在每?/p>

9、個(gè)類中有不同的實(shí)現(xiàn)的一種方法是( B )。 A繼承 B. 多態(tài)性 C. 約束 D. 接口 二、填空題 6軟件生存周期由（軟件定義）、（軟件開發(fā)）和（軟件使用與維護(hù)）三部分組成。 8面向?qū)ο蠹夹g(shù)采用以類為中心的（封裝）、（繼承）、（多態(tài)）等不僅支持軟件復(fù)用，而且使軟件維護(hù)工作可靠有效，可實(shí)現(xiàn)軟件系統(tǒng)的柔性制造。簡(jiǎn)答軟件過(guò)程模型的含義 軟件過(guò)程(Software Engineering Process)是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。套路 通常使用生命周期模型簡(jiǎn)潔地描述軟件過(guò)程。生命周期模型規(guī)定了把生命周期劃分成哪些階段及各個(gè)階段的執(zhí)行順序，因此，

10、也稱為過(guò)程模型。 請(qǐng)指出三種以上現(xiàn)實(shí)生活中的常用模型，并說(shuō)明它們分別在各自的領(lǐng)域中發(fā)揮了什么樣的作用。 1）電路圖：電子產(chǎn)品設(shè)計(jì)、生產(chǎn)、維修 2）園區(qū)沙盤：直觀、立體化地展示園區(qū)的景觀、布局 3）地圖：導(dǎo)航、指路等 請(qǐng)簡(jiǎn)要說(shuō)明建模的意義和建模的原則。 建議能夠幫助我們按照實(shí)際情況或按我們需要的樣式對(duì)系統(tǒng)進(jìn)行可視化；提供一種詳細(xì)說(shuō)明系統(tǒng)的結(jié)構(gòu)或行為的方法；給出一個(gè)指導(dǎo)系統(tǒng)構(gòu)造的模板；對(duì)我們所做出的決策進(jìn)行文檔化 在建模時(shí)應(yīng)遵循以下原則：選擇要?jiǎng)?chuàng)建什么模型對(duì)如何動(dòng)手解決問(wèn)題和如何形成解決方案有著意義深遠(yuǎn)的影響；每一種模型可以在不同的精度級(jí)別上表示；最好的模型是與現(xiàn)實(shí)相聯(lián)系的；單個(gè)模型是不充分的。對(duì)

11、每個(gè)重要的系統(tǒng)最好用一組幾乎獨(dú)立的模型去處理 第 2 章 統(tǒng)一建模語(yǔ)言 UML * 一、選擇題 ABCDB 1UML 的軟件以( A )為中心，以系統(tǒng)體系結(jié)構(gòu)為主線，采用循環(huán)、迭代、漸增的方式進(jìn)行開發(fā)。 A用例 B對(duì)象 C類 D程序2UML 的( B )模型圖由類圖、對(duì)象圖、包圖、構(gòu)件圖和配置圖組成。 A用例 B靜態(tài) C動(dòng)態(tài) D系統(tǒng) 3UML 的( C )模型圖由活動(dòng)圖、順序圖、狀態(tài)圖和合作圖組成。 A用例 B靜態(tài) C動(dòng)態(tài) D系統(tǒng) 4UML 的最終產(chǎn)物就是最后提交的可執(zhí)行的軟件系統(tǒng)和( D )。 A用戶手冊(cè) B類圖 C動(dòng)態(tài)圖 D相應(yīng)的軟件文檔資料 5在 UML 的需求分析建模中，( B )模型

12、圖必須與用戶反復(fù)交流并加以確認(rèn)。 A配置 B用例 C包 D動(dòng)態(tài) 二、填空題6UML 分析和設(shè)計(jì)模型由三類模型圖表示。三類模型圖是：(用例)模型圖、(靜態(tài))模型圖和(動(dòng)態(tài))模型圖。 8UML 開發(fā)過(guò)程是一種二維結(jié)構(gòu)軟件開發(fā)過(guò)程，軟件項(xiàng)目開發(fā)過(guò)程流包括的核心工作內(nèi)容是：(分析)、(設(shè)計(jì))、(實(shí)現(xiàn))、(測(cè)試)和(配置)。 9UML 中的五個(gè)不同的視圖可以完整地描述出所建造的系統(tǒng)，這五種視圖是（用例）視圖、（邏輯）視圖、（構(gòu)件）視圖、（進(jìn)程）視圖和（配置）視圖 10UML 中有 10 種基本圖可以完整地描述出所建造的系統(tǒng)，這 10 種圖是 （用例圖；類圖、對(duì)象圖、包圖、構(gòu)件圖、配置圖；活動(dòng)圖、順序圖、

13、狀態(tài)圖，合作圖） 四、綜合 （22、24、33） 簡(jiǎn)答22UML 軟件開發(fā)過(guò)程的特征是什么? UML 軟件開發(fā)的基本特征是：以用例驅(qū)動(dòng)開發(fā)過(guò)程，以系統(tǒng)體系結(jié)構(gòu)為中心，以質(zhì)量控制和風(fēng)險(xiǎn)管理為目標(biāo)，采用反復(fù)（迭代、循環(huán)）、漸增式的螺旋上升式開發(fā)過(guò)程。 簡(jiǎn)答24UML 中的類圖建模的目的與意義是什么? 名正言順事物是普遍聯(lián)系的 類圖是用類和它們之間的關(guān)系描述系統(tǒng)的一種圖示，展示了系統(tǒng)中類的靜態(tài)結(jié)構(gòu)和類與類之間的相互聯(lián)系，表示一個(gè)系統(tǒng)的邏輯結(jié)構(gòu)。類圖是構(gòu)件其他圖的基礎(chǔ)，沒(méi)有類圖，也就沒(méi)有狀態(tài)圖、合作圖等其他圖，也就無(wú)法表示系統(tǒng)的其他各個(gè)方面。 簡(jiǎn)答33UML 中的順序圖建模目的與意義是什么? 順序圖用

14、來(lái)描述對(duì)象之間動(dòng)態(tài)的交互關(guān)系，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序。作為動(dòng)態(tài)模型制品之一，順序圖可以描述系統(tǒng)的動(dòng)態(tài)行為和控制結(jié)構(gòu)。通過(guò)描述對(duì)象間動(dòng)態(tài)合作關(guān)系，顯示對(duì)象之間的交互過(guò)程以及交互順序，同時(shí)描述了為滿足用例要求所進(jìn)行的活動(dòng)以及活動(dòng)間的約束關(guān)系。 簡(jiǎn)答請(qǐng)說(shuō)明藍(lán)圖和草圖的區(qū)別，并簡(jiǎn)單描述其適用的場(chǎng)景。 藍(lán)圖一般是指采用 CASE 工具繪制的、正式的、規(guī)范的 UML 模型；而草圖則通常是指手工繪制的、規(guī)范度較低的在紙張的 UML 模型。 對(duì)于局部的、重要性不高的、共享范圍較小的 UML 模型，直接將草圖掃描到電腦存檔即可；對(duì)于全局的、重要性高的、高度共享的，在草圖的基礎(chǔ)上用 CASE 工具繪制成

15、為正式的藍(lán)圖，并將其納入統(tǒng)一的模型管理中 第 3 章 需求分析與用例建模 * 一、選擇 BACDDAA 1可行性研究分析包括經(jīng)濟(jì)可行性分析、技術(shù)可行性分析和( B )。 A風(fēng)險(xiǎn)可行性分析 B法律可行性分析 C資源可行性分析 D效益可行性分析 2UML 的客戶需求分析模型包括( A )模型、類圖、對(duì)象圖和活動(dòng)圖組成。 A用例 B靜態(tài) C動(dòng)態(tài) D系統(tǒng) 3UML 客戶需求分析使用的 CRC 卡上“責(zé)任”一欄的內(nèi)容主要描述類的( C )和操作。 A對(duì)象成員 B關(guān)聯(lián)對(duì)象 C屬性 D私有成員 4UML 客戶需求分析產(chǎn)生的用例模型描述了系統(tǒng)的( D )。 A狀態(tài) B體系結(jié)構(gòu) C靜態(tài)模型 D. 功能要求 5在

16、 UML 的需求分析建模中，用例模型必須與( D )反復(fù)交流并加以確認(rèn)。 A軟件生產(chǎn)商 B用戶 C軟件開發(fā)人員 D問(wèn)題領(lǐng)域?qū)＜?6在 UML 的需求分析建模中，對(duì)用例模型中的用例進(jìn)行細(xì)化說(shuō)明應(yīng)使用( A )。圖->-文字>圖 A活動(dòng)圖 B狀態(tài)圖 C配置圖 D. 構(gòu)件圖 7活動(dòng)圖中的分劈和同步接合圖符是用來(lái)描述 ( A )。A多進(jìn)程的并發(fā)處理行為 B. 對(duì)象的時(shí)序 C類的關(guān)系 D系統(tǒng)體系結(jié)構(gòu)框架 二、填空題10軟件項(xiàng)目的可行性研究分析中，技術(shù)可行性研究包括（風(fēng)險(xiǎn)分析）、（資源分析）、（技術(shù)分析）3 部分組成。 11在 UML 軟件開發(fā)過(guò)程的需求分析階段，建立用例模型的步驟分為（確定系

17、統(tǒng)范圍、參與者和用例）、（描述用例）、（用例分類、確定用例之間的關(guān)聯(lián)）、（建立用例圖）和（定義用例圖的層次結(jié)構(gòu)）及審核用例模型。 12用例圖中以實(shí)線方框表示系統(tǒng)的范圍和邊界，在系統(tǒng)邊界內(nèi)描述的是（用例或系統(tǒng)內(nèi)部元素），在邊 界外描述的是（參與者）。 13用例模型中的執(zhí)行者可以是（人）也可以是（外部系統(tǒng)）。 14用例模型中的用例之間的關(guān)聯(lián)有（繼承）關(guān)聯(lián)、（擴(kuò)展）關(guān)聯(lián)、（包含）關(guān)聯(lián)和（使用）關(guān)聯(lián)。 <<extend>>在 RUP 的“4+1”視圖中，這個(gè) 1 表示的是什么，它有什么作用。 這個(gè) 1 是用例視圖。它是最基本的需求分析模型，是可被最終用戶看到的系統(tǒng)行為的用例組成

18、。常用的模型包括用例圖、交互圖、狀態(tài)圖、活動(dòng)圖等 簡(jiǎn)答用例、用例模型 用例：是一個(gè)敘述型文檔，用來(lái)描述一個(gè)參與者（一個(gè)外部的主動(dòng)者）使用系統(tǒng)完成某個(gè)過(guò)程時(shí)的事件發(fā)生順序。 (用例是對(duì)領(lǐng)域過(guò)程的描述，盡管它不是真正面向?qū)ο蟮?，但采用用例可以增進(jìn)對(duì)需求的理解，因此仍然 OO 方法學(xué)中非常重要和廣泛采用的需求分析制品。) 用例模型：是一種使用用例來(lái)描述系統(tǒng)功能需求的模型，包括高層用例、基本用例、（擴(kuò)展用例、真實(shí)用例）以及描述用例、參與者之間關(guān)系的用例圖。 簡(jiǎn)答何為契約？通常從哪幾方面描述后置條件 契約(contract)是一個(gè)描述某操作應(yīng)該得到什么結(jié)果的文檔。 它經(jīng)常采用敘述體，強(qiáng)調(diào)發(fā)生了什么而不是

19、如何發(fā)生。 通常契約是用前置和后置條件中描述的狀態(tài)變化來(lái)表達(dá)。 實(shí)例創(chuàng)建，形成關(guān)聯(lián)，屬性修改 分析根據(jù)要求畫用例圖。(10 分) 在圖書管理系統(tǒng)中，讀者可以通過(guò)管理員進(jìn)行借書、還書、預(yù)約借書和取消預(yù)約等操作。其中借書必須先進(jìn)行圖書查詢工作；還書時(shí)，如果讀者所借書籍超期，還要進(jìn)行超期罰款。 （1）請(qǐng)畫出描述該業(yè)務(wù)的用例圖（5 分） （2）說(shuō)明用例“借書”與“圖書查詢”之間，“還書”與“超期罰款”之間關(guān)系的含義。 （1） <include>圖書查詢借書 <include>讀者查詢管理員 還書超期罰款預(yù)約書籍讀者取消預(yù)約（2）include 意味著 must，表示大用例的流程

20、必須包含小用例的流程；extend 意味著 option，表示大用例的流程可選地被小用例的流程擴(kuò)展。 分析。 一個(gè)人事管理信息系統(tǒng)的需求如下：所有用戶需登錄系統(tǒng)；一般用戶可以查看一般報(bào)表，導(dǎo)出一般報(bào)表和打印一般報(bào)表；錄入員可以新增數(shù)據(jù)、查看數(shù)據(jù)和修改數(shù)據(jù)；領(lǐng)導(dǎo)可以查看高級(jí)報(bào)表。（1）請(qǐng)使用用例間的關(guān)系精化用例圖，使系統(tǒng)具有最好的用戶體驗(yàn)。（2）說(shuō)明所用用例之間關(guān)系的含義。 （1） （2）include 意味著 must，表示大用例的流程必須包含小用例的流程；extend 意味著 option，表示大用例的流程可選地被小用例的流程擴(kuò)展。 分析根據(jù)要求畫用例圖 在電子商城系統(tǒng)的“購(gòu)物用戶管理”模塊

21、中，“購(gòu)物用戶”（參與者）可以“注冊(cè)帳號(hào)”、“登錄系統(tǒng)”、“關(guān)閉帳號(hào)”和“查看個(gè)人資料”（有可能進(jìn)一步“查看歷史訂單”和“查看當(dāng)前訂單”）?！跋到y(tǒng)管理員”（參與者）可以“刪除購(gòu)物用戶”（提示：必須先“關(guān)閉帳號(hào)”） （1）請(qǐng)畫出描述該業(yè)務(wù)的用例圖 （2）說(shuō)明用例“刪除購(gòu)物用戶”與“關(guān)閉帳號(hào)”之間；“查看歷史訂單”與“查看個(gè)人資料”之間關(guān)系的含義。 分析某銀行計(jì)劃開發(fā)一個(gè)自動(dòng)存提款機(jī)模擬系統(tǒng)(ATM System)。系統(tǒng)通過(guò)讀卡器(CardReader)讀取 ATM 卡；系統(tǒng)與 客 戶 (Customer) 的 交 互 由 客 戶 控 制 臺(tái) (CustomerConsole) 實(shí) 現(xiàn) ； 銀 行

22、 操 作 員 (Operator) 可 控 制 系 統(tǒng) 的 啟 動(dòng)(SystemStartup)和停止(SystemShutdown)；系統(tǒng)通過(guò)網(wǎng)絡(luò)和銀行系統(tǒng)(Bank)實(shí)現(xiàn)通信。 當(dāng)讀卡器判斷用戶己將 ATM 卡插入后，創(chuàng)建會(huì)話(Session)。會(huì)話開始后，讀卡器進(jìn)行讀卡，并要求客戶輸入個(gè)人驗(yàn)證碼(PIN)。系 統(tǒng)將卡號(hào)和個(gè)人驗(yàn) 證碼信息送到銀 行系統(tǒng)進(jìn)行驗(yàn)證。 驗(yàn)證通過(guò)后。客 戶可從菜單選擇如 下事務(wù)(Transaction):從 ATM 卡賬戶取款(Withdraw)；向 ATM 卡賬戶存款(Deposit)；進(jìn)行轉(zhuǎn)賬(Transfer)；查詢(Inquire)ATM卡賬戶信息。 一次

23、會(huì)話可以包含多個(gè)事務(wù)，每個(gè)事務(wù)處理也會(huì)將卡號(hào)和個(gè)人驗(yàn)證碼信息送到銀行系統(tǒng)進(jìn)行驗(yàn)證。若個(gè)人驗(yàn)證碼錯(cuò)誤，則轉(zhuǎn)個(gè)人驗(yàn)證碼錯(cuò)誤處理(Invalid PIN Process)。每個(gè)事務(wù)完成后，客戶可選擇繼續(xù)上述事務(wù)或退卡。選擇退卡時(shí)系統(tǒng)彈出 ATM 卡，會(huì)話結(jié)束。 （1）完善用例圖中的用例和關(guān)系。（5 分） （2）說(shuō)明用例“Session”與“Transaction”之間，“Invalid PIN Process”與“Transaction”之間關(guān)系的含義。 （1） 對(duì)于一個(gè)電子商務(wù)網(wǎng)站而言，以下哪些不是合適的用例，指出并說(shuō)明理由。 輸入支付信息 將商品放入購(gòu)物車 結(jié)賬 預(yù)訂商品 用戶登錄 郵寄商品 查

24、看商品詳情 輸入支付信息：太小 郵寄商品：系統(tǒng)功能之外 查看商品詳情：太小 請(qǐng)指出下列用例不是有效用例的原因。 用例的執(zhí)行結(jié)果對(duì)參與者來(lái)說(shuō)是可觀測(cè)的和有意義的。填寫取款單不是取款人的目的。因此不是用例。 用例總是由一個(gè)參與者發(fā)起的參與者的愿望是這個(gè)用例存在的原因。ATM 是沒(méi)有吐鈔的愿望的因此不能發(fā)起用例 用例必然是以動(dòng)賓短語(yǔ)形式出現(xiàn)的。 用例間的包含關(guān)系不是象函數(shù)調(diào)用那樣為了得到返回值，用例必須與參與者有互動(dòng)。 第 4 章 系統(tǒng)分析與對(duì)象類建模 即概念建模 * 一、選擇題 1UML 的系統(tǒng)分析進(jìn)一步要確立的三個(gè)系統(tǒng)模型是( B )、對(duì)象動(dòng)態(tài)模型和系統(tǒng)功能模型。 A數(shù)據(jù)模型 B對(duì)象靜態(tài)模型 C

25、對(duì)象關(guān)系模型 D體系結(jié)構(gòu)模型 2UML 的客戶需求分析、系統(tǒng)分析和系統(tǒng)設(shè)計(jì)階段產(chǎn)生的模型，其描述圖符( A )。 A完全相同 B完全不同 C不可以通用 D稍有差異 3類和對(duì)象都有屬性，它們的差別是：類描述了屬性的類型，而對(duì)象的屬性必須有( C )。 A正負(fù)號(hào) B動(dòng)作 C具體值 D私有成員 4UML 系統(tǒng)分析階段產(chǎn)生的包圖描述了系統(tǒng)的( B )。 A狀態(tài) B系統(tǒng)體系層次結(jié)構(gòu) C靜態(tài)模型 D功能要求 5設(shè)計(jì)模式在面向?qū)ο笙到y(tǒng)設(shè)計(jì)中是( B )的一種形式。 A軟件調(diào)用 B設(shè)計(jì)方法 C子系統(tǒng) D軟件復(fù)用 6"對(duì)象容器"設(shè)計(jì)模式對(duì)有限的對(duì)象進(jìn)行管理，它不能( C )。 A查找對(duì)象 B

26、修改對(duì)象 C創(chuàng)建對(duì)象 D刪除對(duì)象 二、填空題 7在 UML 軟件開發(fā)過(guò)程系統(tǒng)分析階段產(chǎn)生的對(duì)象模型有三種模型。它們是：對(duì)象的_模型、對(duì)象的_模型和對(duì)象的_模型。 8在 UML 的對(duì)象類圖中，類之間的關(guān)系有_關(guān)聯(lián)_、_聚集_、_繼承_、_依賴_和_細(xì)化_5 種。 9共享聚集的“部分”對(duì)象可以是任意“整體”對(duì)象的一部分，表示事物的整體部分關(guān)系較弱的情況，“整體”端的重?cái)?shù)應(yīng)該是_非 1_ 。 10在 UML 軟件開發(fā)過(guò)程的需求分析和系統(tǒng)分析階段，建立對(duì)象類模型的步驟分為（尋找確定對(duì)象類）、（定義類的接口）、（定義類間關(guān)系）、（建立對(duì)象類圖）和（建立系統(tǒng)包圖）。 11組合聚集是指“整體”擁有它的“部分

27、”，它具有強(qiáng)的物主身份，表示事物的整體部分關(guān)系較強(qiáng)的情況?！安糠帧鄙嬖凇罢w”中，不可分離，它們與“整體”一起存在或消亡。“整體”的重?cái)?shù)必須是_1_。 12系統(tǒng)分析是在客戶需求分析規(guī)格說(shuō)明的基礎(chǔ)之上對(duì)其進(jìn)行的（類和對(duì)象建模）_。 13類有實(shí)例，它的實(shí)例是一個(gè)對(duì)象。在 UML 中，包用來(lái)表示一個(gè)（子系統(tǒng)），包沒(méi)有實(shí)例。 三、解釋名詞 簡(jiǎn)答概念模型 概念模型(conceptual model) ：是問(wèn)題域中概念的描述。它展示出問(wèn)題域中有意義的概念，它是面向?qū)ο蠓治鲋凶钪匾闹破?。概念模型是真?shí)世界中各個(gè)事物的代表，而不是軟件中各構(gòu)件的代表。通過(guò)將問(wèn)題分解成多個(gè)單獨(dú)的概念或者對(duì)象，我們就可以識(shí)別出

28、問(wèn)題域中重要的概念、屬性和關(guān)聯(lián)，進(jìn)而得出一組刻畫問(wèn)題域的圖形。 簡(jiǎn)答在繪制類圖時(shí)，第一步就是發(fā)現(xiàn)類，最常用的方法是什么？請(qǐng)簡(jiǎn)要說(shuō)明它的使用方法。 發(fā)現(xiàn)類的方法有很多種，其中最廣泛應(yīng)用的莫過(guò)于“名詞動(dòng)詞法”，其主要規(guī)則是從名詞與名詞短語(yǔ)中提取對(duì)象與屬性；從動(dòng)詞與動(dòng)詞短語(yǔ)中提取操作與關(guān)聯(lián)；而所有格短短語(yǔ)通常表明名詞應(yīng)該是屬性而不是對(duì)象。 分析在下圖中，是一個(gè)倉(cāng)庫(kù)管理系統(tǒng)的類模型局部，其中 IncomeOrder 是指入庫(kù)單，OrderItem 是指入庫(kù)單中的每一項(xiàng)，Product 則是產(chǎn)品信息。請(qǐng)指出模型中的錯(cuò)誤，說(shuō)明原因并改正錯(cuò)誤。 IncomeOrder11ProductOrderItem倉(cāng)庫(kù)

29、管理系統(tǒng)類模型局部 根據(jù)題意和模型不難得知，一個(gè)入庫(kù)單（IncomeOrder）是由多個(gè)入庫(kù)單項(xiàng)（OrderItem）組成的，因此： （1）OrderItem 與 IncomeOrder 應(yīng)該是組合關(guān)系。 （2）一個(gè)入庫(kù)單不可能只涉及一個(gè)產(chǎn)品，合理的方式應(yīng)該是入每個(gè)入庫(kù)單項(xiàng)（OrderItem）與產(chǎn)品一對(duì)一關(guān)聯(lián)。 即應(yīng)該繪制為： 分析 請(qǐng)根據(jù)下列文字畫出概念模型，并說(shuō)明文字與圖形各自的優(yōu)缺點(diǎn)：一輛車身是紅色金屬漆的小轎車，裝備四個(gè)普利斯通牌的輪胎，它是一輛四門車，車門是加厚的，并且前后門玻璃上貼黑色的膜。前后擋風(fēng)玻璃里都 裝有電熱絲，后視鏡是電動(dòng)可調(diào)的。（注意：許多隱含信息被省略了，例如車身和

30、輪胎是安裝在汽車上的，車門是安裝在車身上的等等） 答： 文字有利于分析員與客戶間無(wú)障礙交流，因?yàn)闊o(wú)需經(jīng)過(guò)培訓(xùn)，客戶就可以看懂文字描述。缺點(diǎn)是無(wú)歧義的文字往往冗長(zhǎng)乏味。圖形更易于表達(dá)隱含的信息和文字中隱晦的含義，尤其是元素之間的關(guān)系一目了然 分析 如果打算給一個(gè)正規(guī)的大公司開發(fā)一個(gè)人事管理系統(tǒng)，請(qǐng)改進(jìn)以下局部概念模型，并說(shuō)明理由。 （1） （2）組合：正規(guī)的大公司一般不允許員工受雇多家公司；應(yīng)設(shè)計(jì)關(guān)聯(lián)類存儲(chǔ)薪金、職位、合同期 分析請(qǐng)按 Peter Coad 的事務(wù)模式（人、地、物、事務(wù)、后續(xù)事務(wù)等）快速勾勒出“酒店聯(lián)合訂房系統(tǒng)”的概念模型。 第 5 章系統(tǒng)設(shè)計(jì)與對(duì)象動(dòng)態(tài) 交互模型 * VS 動(dòng)態(tài)

31、狀態(tài)模型 一、選擇題2順序圖和合作圖主要用于對(duì)用例圖中( B )的建模，用它們來(lái)描述用例圖的行為。 A數(shù)據(jù)流 B控制流 C消息流 D數(shù)據(jù)字典 3順序圖的模型元素有( A )、消息、鏈接等，這些模型元素表示某個(gè)用例中的若干個(gè)對(duì)象和對(duì)象之間所傳遞的消息，來(lái)對(duì)系統(tǒng)的行為建模。 A對(duì)象 B箭線 C活動(dòng) D狀態(tài) 4順序圖描述( D )對(duì)象之間消息的傳遞順序。 A某個(gè) B單個(gè) C一個(gè)類產(chǎn)生的 D一組 5順序圖和合作圖建立了 UML 面向?qū)ο箝_發(fā)過(guò)程中的對(duì)象動(dòng)態(tài)( A )模型。 A交互 B狀態(tài) C體系結(jié)構(gòu) D軟件復(fù)用 二、填空題7（順序）圖和（合作）圖用來(lái)表達(dá)對(duì)象之間的交互，是描述一組對(duì)象如何合作完成某個(gè)行

32、為的模型化工具。 9。線程是（進(jìn)程內(nèi)）的一個(gè)動(dòng)作流，能夠與其他線程并發(fā)執(zhí)行。 10（主動(dòng)對(duì)象）是一個(gè)擁有進(jìn)程或線程的對(duì)象，能初始化控制活動(dòng)，可以獨(dú)立并發(fā)運(yùn)行。 11（被動(dòng)對(duì)象）是一個(gè)必須由其他對(duì)象發(fā)來(lái)的消息進(jìn)行觸發(fā)才執(zhí)行動(dòng)作的對(duì)象。 三、解釋名詞 已標(biāo)為論述5 個(gè)常用 GRASP 職責(zé)分配模式的名稱、要點(diǎn)或意圖 專家(expert)：將職責(zé)分配給信息專家掌握為了履行職責(zé)所必需的信息的類（誰(shuí)懂的多就讓誰(shuí)干） 創(chuàng)建者(creator)：大的對(duì)象有責(zé)任創(chuàng)建小的對(duì)象，這是 OOD/P 中最常見(jiàn)的任務(wù)。 高聚合度或高內(nèi)聚(high cohesion)：是一個(gè)檢驗(yàn)標(biāo)準(zhǔn)，用于判斷一個(gè)類中的各個(gè)職責(zé)之間相關(guān)程

33、度和集中程度（可重用性的內(nèi)因）。 低耦合度或低耦合(low coupling)：是一個(gè)檢驗(yàn)標(biāo)準(zhǔn)，用于判斷類間依賴程度是否較?。芍赜眯缘耐庠诒憩F(xiàn)）。 控制者(controller)：誰(shuí)來(lái)統(tǒng)一協(xié)調(diào)處理一個(gè)用例的各個(gè)系統(tǒng)事件，以使?fàn)顟B(tài)信息保持一致？ 四、綜合題 22系統(tǒng)動(dòng)態(tài)建模包括哪些模型? 動(dòng)態(tài)交互模型和動(dòng)態(tài)狀態(tài)模型 23描述對(duì)象交互行為有哪幾種圖? 順序圖、合作圖、狀態(tài)圖、活動(dòng)圖 簡(jiǎn)答UML 中的交互圖有兩種，分別是順序圖和協(xié)作圖，請(qǐng)分析一下兩者之間的主要差別和各自的優(yōu)缺點(diǎn)。掌握利用兩種圖進(jìn)行的設(shè)計(jì)的方法。 答：協(xié)作圖可視化地表示了對(duì)象之間隨時(shí)間發(fā)生的交互，它除了展示對(duì)象之間的關(guān)聯(lián)，還顯示出對(duì)

34、象之間的消息傳遞。與順序圖一樣，協(xié)作圖也展示對(duì)象之間的交互關(guān)系。順序圖強(qiáng)調(diào)的是交互的時(shí)間順序，而協(xié)作圖強(qiáng)調(diào)的是交互的語(yǔ)境和參與交互的對(duì)象的整體組織。順序圖按照時(shí)間順序布圖，而協(xié)作圖按照空間組織布圖。 順序圖可以清晰地表示消息之間的順序和時(shí)間關(guān)系，但需要較多的水平方向的空間。 協(xié)作圖在增加對(duì)象時(shí)比較容易，而且分支也比較少，但如果消息比較多時(shí)難以表示消息之間的順序。 分析請(qǐng)根據(jù)以下用例描述，結(jié)合 Ivar Jacobson 的 BCE 模式，畫出順序圖。 分析將給出的協(xié)作圖轉(zhuǎn)化為等價(jià)的順序圖。（10 分）同時(shí)要求能將順序圖轉(zhuǎn)協(xié)作圖 第 6 章 系統(tǒng)動(dòng)態(tài)建模狀態(tài)模型 * 一、選擇題 1.狀態(tài)圖可以表

35、現(xiàn)( B )在生存期的行為、所經(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) 2.狀態(tài)圖描述一個(gè)對(duì)象在不同( A )的驅(qū)動(dòng)下發(fā)生的狀態(tài)遷移。 A事件 B對(duì)象 C執(zhí)行者 D數(shù)據(jù) 4.活動(dòng)圖中動(dòng)作狀態(tài)之間的遷移不是靠( B )觸發(fā)的，當(dāng)活動(dòng)<動(dòng)作>狀態(tài)中的活動(dòng)完成時(shí)遷移就被觸發(fā)。 A對(duì)象 B事件 C執(zhí)行者 D系統(tǒng) 5.狀態(tài)圖和活動(dòng)圖建立了 UML 面向?qū)ο箝_發(fā)過(guò)程中的對(duì)象動(dòng)態(tài)( B )模型。 A交互 B狀態(tài) C體系結(jié)構(gòu) D軟件復(fù)用 二、填空題 6.順序狀態(tài)表明狀態(tài)之間的遷移是(串行的)的，即一個(gè)接一個(gè)順序遷移。 9.在

36、活動(dòng)圖中，（虛箭線）也稱為對(duì)象流，對(duì)象流表示動(dòng)作狀態(tài)或活動(dòng)狀態(tài)與對(duì)象之間的關(guān)聯(lián)。 11活動(dòng)圖中活動(dòng)狀態(tài)的遷移（不是）由事件進(jìn)行觸發(fā)，一個(gè)活動(dòng)執(zhí)行完畢（可以直接）進(jìn)入下一個(gè)活動(dòng)狀態(tài)。 第 7 章 系統(tǒng)體系結(jié)構(gòu)建模 * 一、選擇題 1.系統(tǒng)體系結(jié)構(gòu)是用來(lái)描述系統(tǒng)各部分的結(jié)構(gòu)、接口以及它們用于通信的( A )。 A一種機(jī)制 B形式 C原理 D結(jié)構(gòu) 2.UML 可以描述硬件之間的互聯(lián)關(guān)系，也能描述硬件單元上的( B )系統(tǒng)的分布。 A對(duì)象 B軟件 C系統(tǒng)體系結(jié)構(gòu) D數(shù)據(jù) 3.( B )是對(duì)系統(tǒng)的用例、類、對(duì)象、接口以及相互間的交互和協(xié)作進(jìn)行描述。 A系統(tǒng)體系結(jié)構(gòu) B軟件(邏輯)體系結(jié)構(gòu) C硬件(物理)

37、系統(tǒng)體系結(jié)構(gòu) D系統(tǒng)框架 4.( D )要對(duì)系統(tǒng)的構(gòu)件、結(jié)點(diǎn)的配置進(jìn)行描述。 A軟件(邏輯)系統(tǒng)體系結(jié)構(gòu) B系統(tǒng)體系結(jié)構(gòu) C系統(tǒng)架構(gòu) D硬件(物理)系統(tǒng)體系結(jié)構(gòu) 5.( A )是軟件(邏輯)系統(tǒng)體系結(jié)構(gòu)(類、對(duì)象、它們間的關(guān)系和協(xié)作)中定義的概念和功能在物理體系結(jié)構(gòu)中的實(shí)現(xiàn)。 A構(gòu)件 B結(jié)點(diǎn) C軟件 D模塊 6.( C )由結(jié)點(diǎn)和結(jié)點(diǎn)之間的聯(lián)系組成，描述了處理器、設(shè)備和軟件構(gòu)件運(yùn)行時(shí)的體系結(jié)構(gòu)。A構(gòu)件圖 B狀態(tài)圖 C配置圖 D 順序圖 7.( D )的基本元素有結(jié)點(diǎn)、構(gòu)件、對(duì)象、連接、依賴等。 A構(gòu)件圖 B狀態(tài)圖 C順序圖 D配置圖 二、填空題 8.系統(tǒng)體系結(jié)構(gòu)建?？煞譃椋ㄜ浖w系結(jié)構(gòu)）建模和

38、（硬件體系結(jié)構(gòu)）建模。 9.構(gòu)件是（軟件系統(tǒng)體系結(jié)構(gòu)）(類、對(duì)象、它們間的關(guān)系和協(xié)作)中定義的概念和功能在（物理體系結(jié)構(gòu)）中的實(shí)現(xiàn)。 10.構(gòu)件圖主要用于建立系統(tǒng)的（軟件體系結(jié)構(gòu)）模型。 第 8 章 設(shè)計(jì)模式及其應(yīng)用 * 一、選擇題 1設(shè)計(jì)模式( B )具體的編程語(yǔ)言。A依賴于 B獨(dú)立于 C依附于 D指定了 2設(shè)計(jì)模式是面向?qū)ο筌浖こ讨械囊粋€(gè)重要概念，是由軟件模式分支中衍生出來(lái)的一個(gè)解決( A )的重要方案之一。 A具體問(wèn)題 B抽象問(wèn)題 C需求分析 D數(shù)據(jù)流程 3445 節(jié)介紹的“對(duì)象集合管理器”模式就是本章介紹的( D )模式。 A工廠方法 B抽象工廠 C單例 D簡(jiǎn)單工廠 4單例模式屬于對(duì)

39、象創(chuàng)建型模式，它保證一個(gè)類僅有( C )。 A一個(gè)屬性 B一個(gè)操作 C一個(gè)實(shí)例 D一個(gè)對(duì)象成員 5在面向?qū)ο笤O(shè)計(jì)中，設(shè)計(jì)模式是系統(tǒng)( B )的基礎(chǔ)，正確地使用設(shè)計(jì)模式，有助于快速開發(fā)出可復(fù)用的系統(tǒng)。 A分析 B可復(fù)用 C設(shè)計(jì) D實(shí)現(xiàn)(編程)6設(shè)計(jì)模式就是對(duì)( D )的描述或解決方案，往往直接對(duì)應(yīng)一段程序代碼。 A某個(gè)構(gòu)件 B成熟的設(shè)計(jì) C一個(gè)用例 D特定問(wèn)題 7簡(jiǎn)單一點(diǎn)兒講，模式就是解決特定問(wèn)題的經(jīng)驗(yàn)，實(shí)質(zhì)上就是軟件的( C )。 A建模 B一個(gè)模塊 C復(fù)用 D一個(gè)構(gòu)件 二、填空題 9工廠模式有 3 種形態(tài)：（簡(jiǎn)單工廠）模式、（工廠方法）模式和（抽象方法）模式。 11設(shè)計(jì)模式按照模式的目的將其

40、分為（創(chuàng)建型）、（結(jié)構(gòu)型）和（行為型）。這三種類型的設(shè)計(jì)模式分別描述了對(duì)象在創(chuàng)建、組合以及相互作用的過(guò)程中如何降低它們之間的耦合性、提高復(fù)用性的種種成功方案。 三、解釋名詞 16設(shè)計(jì)模式： 簡(jiǎn)答設(shè)計(jì)模式的概念 有經(jīng)驗(yàn)的面向?qū)ο蟮拈_發(fā)人員建立了一套一般原則和常用解決方案的“指令集”，用來(lái)指導(dǎo)軟件設(shè)計(jì)。這些原則和慣用法如果用結(jié)構(gòu)化的格式編撰成文，文中描述了所要解決的問(wèn)題和對(duì)應(yīng)的解決方案，并且被賦予名字，那么這些原則和慣用法就被稱為模式(pattern) 第 9 章 軟件復(fù)用與構(gòu)件接口技術(shù) * 一、選擇題 1軟件復(fù)用技術(shù)的目的是降低軟件( C )、提高軟件開發(fā)的效率和縮短軟件開發(fā)周期。 A技術(shù)難度

41、B資源浪費(fèi) C開發(fā)和維護(hù)的成本 D代價(jià) 2軟件復(fù)用是面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)的核心支持技術(shù)之一，軟件復(fù)用的核心是( D )。 A對(duì)象類 B模塊 C設(shè)計(jì)模式 D軟件構(gòu)件技術(shù) 3軟件構(gòu)件是已經(jīng)通過(guò)全面測(cè)試并在( A )中運(yùn)行過(guò)的可復(fù)用、功能獨(dú)立、完整且具有通用性的程序模塊。 A實(shí)際系統(tǒng) B實(shí)驗(yàn)室 C系統(tǒng)調(diào)試 D用戶測(cè)試 4CORBA 由( B )制定，是體系結(jié)構(gòu)最完整、最清晰、跨越平臺(tái)最多的分布式對(duì)象模型。 ASun 公司 B對(duì)象管理組織 CMicrosoft 公司 D國(guó)際標(biāo)準(zhǔn)化組織 5CORBA 是一套( A )，為應(yīng)用開發(fā)提供一個(gè)公共框架，推動(dòng)構(gòu)件市場(chǎng)的發(fā)展。 A規(guī)約 B建模語(yǔ)言 C設(shè)計(jì)范本 D

42、編程語(yǔ)言 6持久對(duì)象是( C )其構(gòu)造過(guò)程的對(duì)象。 A依賴于 B區(qū)別于 C獨(dú)立于 D不是 二、填空題 10關(guān)系數(shù)據(jù)庫(kù)不能直接存?。ǔ志脤?duì)象），必須有一個(gè)轉(zhuǎn)換程序?qū)?yīng)用系統(tǒng)中的（暫時(shí)對(duì)象）映射為關(guān)系數(shù)據(jù)庫(kù)中的二維表格列對(duì)應(yīng)類中的（屬性），每一行對(duì)應(yīng)該類的一個(gè)（實(shí)例）。 補(bǔ)充題 將對(duì)象包起來(lái)，使外界只能看到對(duì)象的接口，而不能知道對(duì)象內(nèi)部的具體內(nèi)容，這是對(duì)對(duì)象進(jìn)行（ C ）。 A、結(jié)合 B、隱藏 C、封裝 D、抽象 以下選項(xiàng)中，不屬于對(duì)象的特點(diǎn)是（ C ）。 A、獨(dú)立性 B、封閉性 C、聯(lián)合性 D、動(dòng)態(tài)性 類之間共享屬性和操作的機(jī)制稱為（ C ）。A、靜態(tài)綁定 B、動(dòng)態(tài)綁定 C、繼承 D、多態(tài)型 1

43、、組成 UML 有三種基本的建筑塊是：（A），事物和圖A、關(guān)系 B、類C、用例 D、實(shí)體2、UML 中的事物包括：結(jié)構(gòu)事物，分組事物，注釋事物和（D）A、實(shí)體事物 B、邊界事物C、控制事物 D、動(dòng)作事物3、UML 中有四種關(guān)系是：依賴，泛化，關(guān)聯(lián)和（C ） A、繼承 B、合作C、實(shí)現(xiàn) D、抽象4、UML 中哪種圖（B）用來(lái)描述過(guò)程或操作的工作步驟A、狀態(tài)圖 B、活動(dòng)圖C、用例圖 D、部署圖5、在 UML 中，（B）圖顯示了一組類、接口、協(xié)作以及它們之間的關(guān)系。A、狀態(tài)圖 B、類圖C、用例圖 D、部署圖6、UML 體系包括三個(gè)部分：UML 基本構(gòu)造塊，（A）和 UML 公共機(jī)制A、UML 規(guī)則

44、B、UML 命名C、UML 模型 D、UML 約束7、軟件生存期包括計(jì)劃，需求分析和定義，（B），編碼，軟件測(cè)試和運(yùn)行維護(hù)A、軟件開發(fā) B、軟件設(shè)計(jì)（詳細(xì)設(shè)計(jì)）C、軟件支持 D、軟件定義8、（A）模型的缺點(diǎn)是缺乏靈活性，特別是無(wú)法解決軟件需求不明確或不準(zhǔn)確的問(wèn)題A、瀑布模型 B、原型模型C、增量模型 D、螺旋模型9、下圖是（B）A、類圖 B、用例圖C、活動(dòng)圖 D、狀態(tài)圖10、下圖中的分叉和匯合是用 ROSE 中的（B）工具實(shí)現(xiàn)的。A、關(guān)系 B、同步條C、用例 D、實(shí)體11、（A）技術(shù)是將一個(gè)活動(dòng)圖中的活動(dòng)狀態(tài)進(jìn)行分組，每一組表示一個(gè)特定的類、人或部門，他們負(fù)責(zé)完成組內(nèi)的活動(dòng)。A、泳道 B、分叉

45、匯合C、分支 D、轉(zhuǎn)移12、下面中（C）圖表示結(jié)束狀態(tài)。A、B、 C、D、13、對(duì)反應(yīng)型對(duì)象建模一般使用（A）圖A、狀態(tài)圖 B、順序圖C、活動(dòng)圖 D、類圖14、類圖應(yīng)該畫在 Rose 的哪種（B）視圖中A、Use Case View B、Logic View C、Component View D、Deployment View15、類通常可以分為實(shí)體類，（C）和邊界類A、父類 B、子類C、控制類 D、祖先類16、順序圖由類角色，生命線，激活期和（B）組成A、關(guān)系 B、消息C、用例 D、實(shí)體17、（D）是系統(tǒng)中遵從一組接口且提供實(shí)現(xiàn)的一個(gè)物理部件，通常指開發(fā)和運(yùn)行時(shí)類的物理實(shí)現(xiàn)A、部署圖 B、類

46、C、接口 D、組件18、（A）是通過(guò)到實(shí)現(xiàn)語(yǔ)言的映射而把模型轉(zhuǎn)換為代碼的過(guò)程A、正向工程 B、匿向工程C、前向工程 D、后向工程19、軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它包括程序，數(shù)據(jù)及相關(guān)（A）的完整集合。A、文檔 B、代碼C、圖 D、描述20、一個(gè)對(duì)象和另一個(gè)對(duì)象之間，通過(guò)消息來(lái)進(jìn)行通信。消息通信在面向?qū)ο蟮恼Z(yǔ)言中即（C）A、方法實(shí)現(xiàn) B、方法嵌套C、方法調(diào)用 D、方法定義21、（D）是可復(fù)用的，提供明確接口完成特定功能的程序代碼塊。A、模塊 B、函數(shù)C、用例 D、軟件構(gòu)件22、下圖中的空心箭頭連線表示（A）關(guān)系A(chǔ)、泛化 B、包含C、擴(kuò)展 D、實(shí)現(xiàn)23、組件圖展現(xiàn)了一組組件之間的

47、組件和依賴。它專注于系統(tǒng)的（B）實(shí)現(xiàn)圖A、動(dòng)態(tài) B、靜態(tài)C、基礎(chǔ) D、實(shí)體24、若將活動(dòng)狀態(tài)比作方法，那么動(dòng)作狀態(tài)即（C）A、方法名 B、方法返回值C、方法體中的每一條語(yǔ)句 D、方法的可見(jiàn)性25、事件可以分為內(nèi)部事件和外部事件。按下按鈕和打印機(jī)的中斷是（B）事件A、內(nèi)部事件 B、外部事件C、信號(hào)事件 D、調(diào)用事件26、（A）是用于把元素組織成組的通用機(jī)制A、包 B、類C、接口 D、組件27 類表示邏輯抽象，而（D）表示存在于計(jì)算機(jī)中的物理抽象A、包 B、節(jié)點(diǎn)C、接口 D、組件28、（C）是一組用于描述類或組件的一個(gè)服務(wù)的操作A、包 B、節(jié)點(diǎn)C、接口 D、組件29、沒(méi)有計(jì)算能力的節(jié)點(diǎn)稱為（B）A、處理器 B、設(shè)備C、組件 D、接口30、（B）是被節(jié)點(diǎn)