1、論述基于 UML 的軟件開發的 一般過程 答：UML 是按 OO 思想進行系統建模時使用的一組表示法，它并不對采用何種 OO 分析、設計以及開發過程模型構成限制。基于 UML 的軟件開發通常是以體系結構為中心，用例驅動的迭代和增量式開發，并結合職責分配模式進行具體設計。開發過程可以包括計劃和細化、迭代的構造和實施 3 大階段。在經過一個初步的計劃和細化階段后，進入若干 迭代構造開發周期，每個周期都包含分析、設計、構造和測試步驟。 （1）計劃和細化：通過各種傳統的需求獲取手段（調查、訪談、原型等）得出 系統目標、系統功能和系統屬性，撰寫系統規格說明。基于參與者和外部事件（動賓詞組）構建用例，以增

2、 進對領域過程和功能需求的 理解做什么。按照風險 、業務主線及對體系結構的影響程度（系統屬性）劃分用例的優先級，并據此決定用例的時間調度。對高優先 用例采用擴展格式細化。同時建立概念模型草案、系統體系結構草案。 （2）分析階段：根據當前周期的用例描述，采用概念目錄列表、非正式分析或 事務模式，識別出相關概念，建立初始概念模型，根據通用關聯列表和信息存儲的需要，為概念模型添加關聯和屬性。將用例分解為系統事件，并對應系統操作，建立系統順序圖；分析系統操作被調用后系統狀態（概念）的變化，為系統操作建立契約，進一步理解系統行為做的效果。 （3 ）設計階段：設計一個合理的體系結構，建立真實用例 。針對每

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

4、計（并根據需要設計與外部系統、其他子系統、持久化設施的交互機制）；進一步構造并測試。論述： 請談一談對 OOD 中“一個中心”：開閉原則（OCP），“兩個基本點”：高內聚，低耦 合，“四項基本原則”：Liskov 替換原則（L SP）,依賴倒置原則（DIP）,接口分離 原則（ISP），單一職責原則(SRP）的理解 開閉原則（OCP） OO 中最重要的設計原則,指一個模塊在擴展性方面應該是開放的，而在更改性方面應該是封閉的 低耦合度：是在設計過程要記住的一個原則，它是一個時刻需要注意的隱含設計目標。是一個檢驗標準。 高聚合度：確保將復雜性保持在可控制的范圍內，也是一個檢驗標準。 Liskov 替

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

6、 必需的信息的 類（誰懂的 多就讓 誰干） 創建者(creator)：大的對 象有責任創建小的對象，這是 OOD/P 中最常見的任務。 高聚合度或高內聚(high cohesion)：是一個檢驗標準，用于判斷一個類中的各個職責之間相關程度 和集中程度（可重用性的內因）。 低 耦合度或低耦 合(low coupling)：是一 個檢驗標準， 用于判斷類 間依賴程度 是否較小（可重用性的外在表現）。 控制者(controller)：誰來統一協調 處理一個用例的各個系統事件，以使狀態信息保持一致？ 論述后 4 個常用 GRAS P 職責分配模式的名稱、要點或意圖 多態：當相關的可選擇的方法或行為隨著

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

8、這樣客戶端就無需知道這個間接對象。目的是為了避免將一個客戶端同間接對象發生信息耦合和避免直接對象的內部描述。 第 1 章 系統建模與分析設計技術的演變* 一、選擇題 ACDB 1封裝是指把對象的( A )結合在一起，組成一個獨立的對象。 A 屬性和操作 B信息流 C消息和事件 D數據的集合 2封裝是一種( C )技術，目的是使對象的生產者和使用者分離，使對象的定義和實現分開。 A工程化 B系統維護 C信息隱蔽 D產生對象 3面向對象方法中的( D )機制使子類可以自動地擁有(復制)父類全部屬性和操作。 A約束 B對象映射 C信息隱蔽 D繼承 4使得在多個類中能夠定義同一個操作或屬性名，并在每一

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

10、也稱為過程模型。 請指出三種以上現實生活中的常用模型，并說明它們分別在各自的領域中發揮了什么樣的作用。 1）電路圖：電子產品設計、生產、維修 2）園區沙盤：直觀、立體化地展示園區的景觀、布局 3）地圖：導航、指路等 請簡要說明建模的意義和建模的原則。 建議能夠幫助我們按照實際情況或按我們需要的樣式對系統進行可視化；提供一種詳細說明系統的結構或行為的方法；給出一個指導系統構造的模板；對我們所做出的決策進行文檔化 在建模時應遵循以下原則：選擇要創建什么模型對如何動手解決問題和如何形成解決方案有著意義深遠的影響；每一種模型可以在不同的精度級別上表示；最好的模型是與現實相聯系的；單個模型是不充分的。對

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

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

13、狀態圖，合作圖） 四、綜合 （22、24、33） 簡答22UML 軟件開發過程的特征是什么? UML 軟件開發的基本特征是：以用例驅動開發過程，以系統體系結構為中心，以質量控制和風險管理為目標，采用反復（迭代、循環）、漸增式的螺旋上升式開發過程。 簡答24UML 中的類圖建模的目的與意義是什么? 名正言順事物是普遍聯系的 類圖是用類和它們之間的關系描述系統的一種圖示，展示了系統中類的靜態結構和類與類之間的相互聯系，表示一個系統的邏輯結構。類圖是構件其他圖的基礎，沒有類圖，也就沒有狀態圖、合作圖等其他圖，也就無法表示系統的其他各個方面。 簡答33UML 中的順序圖建模目的與意義是什么? 順序圖用

14、來描述對象之間動態的交互關系，著重體現對象間消息傳遞的時間順序。作為動態模型制品之一，順序圖可以描述系統的動態行為和控制結構。通過描述對象間動態合作關系，顯示對象之間的交互過程以及交互順序，同時描述了為滿足用例要求所進行的活動以及活動間的約束關系。 簡答請說明藍圖和草圖的區別，并簡單描述其適用的場景。 藍圖一般是指采用 CASE 工具繪制的、正式的、規范的 UML 模型；而草圖則通常是指手工繪制的、規范度較低的在紙張的 UML 模型。 對于局部的、重要性不高的、共享范圍較小的 UML 模型，直接將草圖掃描到電腦存檔即可；對于全局的、重要性高的、高度共享的，在草圖的基礎上用 CASE 工具繪制成

15、為正式的藍圖，并將其納入統一的模型管理中 第 3 章 需求分析與用例建模 * 一、選擇 BACDDAA 1可行性研究分析包括經濟可行性分析、技術可行性分析和( B )。 A風險可行性分析 B法律可行性分析 C資源可行性分析 D效益可行性分析 2UML 的客戶需求分析模型包括( A )模型、類圖、對象圖和活動圖組成。 A用例 B靜態 C動態 D系統 3UML 客戶需求分析使用的 CRC 卡上“責任”一欄的內容主要描述類的( C )和操作。 A對象成員 B關聯對象 C屬性 D私有成員 4UML 客戶需求分析產生的用例模型描述了系統的( D )。 A狀態 B體系結構 C靜態模型 D. 功能要求 5在

16、 UML 的需求分析建模中，用例模型必須與( D )反復交流并加以確認。 A軟件生產商 B用戶 C軟件開發人員 D問題領域專家 6在 UML 的需求分析建模中，對用例模型中的用例進行細化說明應使用( A )。圖->-文字>圖 A活動圖 B狀態圖 C配置圖 D. 構件圖 7活動圖中的分劈和同步接合圖符是用來描述 ( A )。A多進程的并發處理行為 B. 對象的時序 C類的關系 D系統體系結構框架 二、填空題10軟件項目的可行性研究分析中，技術可行性研究包括（風險分析）、（資源分析）、（技術分析）3 部分組成。 11在 UML 軟件開發過程的需求分析階段，建立用例模型的步驟分為（確定系

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

18、。常用的模型包括用例圖、交互圖、狀態圖、活動圖等 簡答用例、用例模型 用例：是一個敘述型文檔，用來描述一個參與者（一個外部的主動者）使用系統完成某個過程時的事件發生順序。 (用例是對領域過程的描述，盡管它不是真正面向對象的，但采用用例可以增進對需求的理解，因此仍然 OO 方法學中非常重要和廣泛采用的需求分析制品。) 用例模型：是一種使用用例來描述系統功能需求的模型，包括高層用例、基本用例、（擴展用例、真實用例）以及描述用例、參與者之間關系的用例圖。 簡答何為契約？通常從哪幾方面描述后置條件 契約(contract)是一個描述某操作應該得到什么結果的文檔。 它經常采用敘述體，強調發生了什么而不是

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

20、必須包含小用例的流程；extend 意味著 option，表示大用例的流程可選地被小用例的流程擴展。 分析。 一個人事管理信息系統的需求如下：所有用戶需登錄系統；一般用戶可以查看一般報表，導出一般報表和打印一般報表；錄入員可以新增數據、查看數據和修改數據；領導可以查看高級報表。（1）請使用用例間的關系精化用例圖，使系統具有最好的用戶體驗。（2）說明所用用例之間關系的含義。 （1） （2）include 意味著 must，表示大用例的流程必須包含小用例的流程；extend 意味著 option，表示大用例的流程可選地被小用例的流程擴展。 分析根據要求畫用例圖 在電子商城系統的“購物用戶管理”模塊

21、中，“購物用戶”（參與者）可以“注冊帳號”、“登錄系統”、“關閉帳號”和“查看個人資料”（有可能進一步“查看歷史訂單”和“查看當前訂單”）。“系統管理員”（參與者）可以“刪除購物用戶”（提示：必須先“關閉帳號”） （1）請畫出描述該業務的用例圖 （2）說明用例“刪除購物用戶”與“關閉帳號”之間；“查看歷史訂單”與“查看個人資料”之間關系的含義。 分析某銀行計劃開發一個自動存提款機模擬系統(ATM System)。系統通過讀卡器(CardReader)讀取 ATM 卡；系統與 客 戶 (Customer) 的 交 互 由 客 戶 控 制 臺 (CustomerConsole) 實 現 ； 銀 行

22、 操 作 員 (Operator) 可 控 制 系 統 的 啟 動(SystemStartup)和停止(SystemShutdown)；系統通過網絡和銀行系統(Bank)實現通信。 當讀卡器判斷用戶己將 ATM 卡插入后，創建會話(Session)。會話開始后，讀卡器進行讀卡，并要求客戶輸入個人驗證碼(PIN)。系 統將卡號和個人驗 證碼信息送到銀 行系統進行驗證。 驗證通過后。客 戶可從菜單選擇如 下事務(Transaction):從 ATM 卡賬戶取款(Withdraw)；向 ATM 卡賬戶存款(Deposit)；進行轉賬(Transfer)；查詢(Inquire)ATM卡賬戶信息。 一次

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

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

25、對象關系模型 D體系結構模型 2UML 的客戶需求分析、系統分析和系統設計階段產生的模型，其描述圖符( A )。 A完全相同 B完全不同 C不可以通用 D稍有差異 3類和對象都有屬性，它們的差別是：類描述了屬性的類型，而對象的屬性必須有( C )。 A正負號 B動作 C具體值 D私有成員 4UML 系統分析階段產生的包圖描述了系統的( B )。 A狀態 B系統體系層次結構 C靜態模型 D功能要求 5設計模式在面向對象系統設計中是( B )的一種形式。 A軟件調用 B設計方法 C子系統 D軟件復用 6"對象容器"設計模式對有限的對象進行管理，它不能( C )。 A查找對象 B

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

27、”，它具有強的物主身份，表示事物的整體部分關系較強的情況。“部分”生存在“整體”中，不可分離，它們與“整體”一起存在或消亡。“整體”的重數必須是_1_。 12系統分析是在客戶需求分析規格說明的基礎之上對其進行的（類和對象建模）_。 13類有實例，它的實例是一個對象。在 UML 中，包用來表示一個（子系統），包沒有實例。 三、解釋名詞 簡答概念模型 概念模型(conceptual model) ：是問題域中概念的描述。它展示出問題域中有意義的概念，它是面向對象分析中最重要的制品。概念模型是真實世界中各個事物的代表，而不是軟件中各構件的代表。通過將問題分解成多個單獨的概念或者對象，我們就可以識別出

28、問題域中重要的概念、屬性和關聯，進而得出一組刻畫問題域的圖形。 簡答在繪制類圖時，第一步就是發現類，最常用的方法是什么？請簡要說明它的使用方法。 發現類的方法有很多種，其中最廣泛應用的莫過于“名詞動詞法”，其主要規則是從名詞與名詞短語中提取對象與屬性；從動詞與動詞短語中提取操作與關聯；而所有格短短語通常表明名詞應該是屬性而不是對象。 分析在下圖中，是一個倉庫管理系統的類模型局部，其中 IncomeOrder 是指入庫單，OrderItem 是指入庫單中的每一項，Product 則是產品信息。請指出模型中的錯誤，說明原因并改正錯誤。 IncomeOrder11ProductOrderItem倉庫

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

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

31、狀態模型 一、選擇題2順序圖和合作圖主要用于對用例圖中( B )的建模，用它們來描述用例圖的行為。 A數據流 B控制流 C消息流 D數據字典 3順序圖的模型元素有( A )、消息、鏈接等，這些模型元素表示某個用例中的若干個對象和對象之間所傳遞的消息，來對系統的行為建模。 A對象 B箭線 C活動 D狀態 4順序圖描述( D )對象之間消息的傳遞順序。 A某個 B單個 C一個類產生的 D一組 5順序圖和合作圖建立了 UML 面向對象開發過程中的對象動態( A )模型。 A交互 B狀態 C體系結構 D軟件復用 二、填空題7（順序）圖和（合作）圖用來表達對象之間的交互，是描述一組對象如何合作完成某個行

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

33、度和集中程度（可重用性的內因）。 低耦合度或低耦合(low coupling)：是一個檢驗標準，用于判斷類間依賴程度是否較小（可重用性的外在表現）。 控制者(controller)：誰來統一協調處理一個用例的各個系統事件，以使狀態信息保持一致？ 四、綜合題 22系統動態建模包括哪些模型? 動態交互模型和動態狀態模型 23描述對象交互行為有哪幾種圖? 順序圖、合作圖、狀態圖、活動圖 簡答UML 中的交互圖有兩種，分別是順序圖和協作圖，請分析一下兩者之間的主要差別和各自的優缺點。掌握利用兩種圖進行的設計的方法。 答：協作圖可視化地表示了對象之間隨時間發生的交互，它除了展示對象之間的關聯，還顯示出對

34、象之間的消息傳遞。與順序圖一樣，協作圖也展示對象之間的交互關系。順序圖強調的是交互的時間順序，而協作圖強調的是交互的語境和參與交互的對象的整體組織。順序圖按照時間順序布圖，而協作圖按照空間組織布圖。 順序圖可以清晰地表示消息之間的順序和時間關系，但需要較多的水平方向的空間。 協作圖在增加對象時比較容易，而且分支也比較少，但如果消息比較多時難以表示消息之間的順序。 分析請根據以下用例描述，結合 Ivar Jacobson 的 BCE 模式，畫出順序圖。 分析將給出的協作圖轉化為等價的順序圖。（10 分）同時要求能將順序圖轉協作圖 第 6 章 系統動態建模狀態模型 * 一、選擇題 1.狀態圖可以表

35、現( B )在生存期的行為、所經歷的狀態序列、引起狀態轉移的事件以及因狀態轉移而引起的動作。 A一組對象 B一個對象 C多個執行者 D幾個子系統 2.狀態圖描述一個對象在不同( A )的驅動下發生的狀態遷移。 A事件 B對象 C執行者 D數據 4.活動圖中動作狀態之間的遷移不是靠( B )觸發的，當活動<動作>狀態中的活動完成時遷移就被觸發。 A對象 B事件 C執行者 D系統 5.狀態圖和活動圖建立了 UML 面向對象開發過程中的對象動態( B )模型。 A交互 B狀態 C體系結構 D軟件復用 二、填空題 6.順序狀態表明狀態之間的遷移是(串行的)的，即一個接一個順序遷移。 9.在

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

37、系統體系結構 D系統框架 4.( D )要對系統的構件、結點的配置進行描述。 A軟件(邏輯)系統體系結構 B系統體系結構 C系統架構 D硬件(物理)系統體系結構 5.( A )是軟件(邏輯)系統體系結構(類、對象、它們間的關系和協作)中定義的概念和功能在物理體系結構中的實現。 A構件 B結點 C軟件 D模塊 6.( C )由結點和結點之間的聯系組成，描述了處理器、設備和軟件構件運行時的體系結構。A構件圖 B狀態圖 C配置圖 D 順序圖 7.( D )的基本元素有結點、構件、對象、連接、依賴等。 A構件圖 B狀態圖 C順序圖 D配置圖 二、填空題 8.系統體系結構建模可分為（軟件體系結構）建模和

38、（硬件體系結構）建模。 9.構件是（軟件系統體系結構）(類、對象、它們間的關系和協作)中定義的概念和功能在（物理體系結構）中的實現。 10.構件圖主要用于建立系統的（軟件體系結構）模型。 第 8 章 設計模式及其應用 * 一、選擇題 1設計模式( B )具體的編程語言。A依賴于 B獨立于 C依附于 D指定了 2設計模式是面向對象軟件工程中的一個重要概念，是由軟件模式分支中衍生出來的一個解決( A )的重要方案之一。 A具體問題 B抽象問題 C需求分析 D數據流程 3445 節介紹的“對象集合管理器”模式就是本章介紹的( D )模式。 A工廠方法 B抽象工廠 C單例 D簡單工廠 4單例模式屬于對

39、象創建型模式，它保證一個類僅有( C )。 A一個屬性 B一個操作 C一個實例 D一個對象成員 5在面向對象設計中，設計模式是系統( B )的基礎，正確地使用設計模式，有助于快速開發出可復用的系統。 A分析 B可復用 C設計 D實現(編程)6設計模式就是對( D )的描述或解決方案，往往直接對應一段程序代碼。 A某個構件 B成熟的設計 C一個用例 D特定問題 7簡單一點兒講，模式就是解決特定問題的經驗，實質上就是軟件的( C )。 A建模 B一個模塊 C復用 D一個構件 二、填空題 9工廠模式有 3 種形態：（簡單工廠）模式、（工廠方法）模式和（抽象方法）模式。 11設計模式按照模式的目的將其

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

41、B資源浪費 C開發和維護的成本 D代價 2軟件復用是面向對象系統分析與設計的核心支持技術之一，軟件復用的核心是( D )。 A對象類 B模塊 C設計模式 D軟件構件技術 3軟件構件是已經通過全面測試并在( A )中運行過的可復用、功能獨立、完整且具有通用性的程序模塊。 A實際系統 B實驗室 C系統調試 D用戶測試 4CORBA 由( B )制定，是體系結構最完整、最清晰、跨越平臺最多的分布式對象模型。 ASun 公司 B對象管理組織 CMicrosoft 公司 D國際標準化組織 5CORBA 是一套( A )，為應用開發提供一個公共框架，推動構件市場的發展。 A規約 B建模語言 C設計范本 D

42、編程語言 6持久對象是( C )其構造過程的對象。 A依賴于 B區別于 C獨立于 D不是 二、填空題 10關系數據庫不能直接存取（持久對象），必須有一個轉換程序將應用系統中的（暫時對象）映射為關系數據庫中的二維表格列對應類中的（屬性），每一行對應該類的一個（實例）。 補充題 將對象包起來，使外界只能看到對象的接口，而不能知道對象內部的具體內容，這是對對象進行（ C ）。 A、結合 B、隱藏 C、封裝 D、抽象 以下選項中，不屬于對象的特點是（ C ）。 A、獨立性 B、封閉性 C、聯合性 D、動態性 類之間共享屬性和操作的機制稱為（ C ）。A、靜態綁定 B、動態綁定 C、繼承 D、多態型 1

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

44、B、UML 命名C、UML 模型 D、UML 約束7、軟件生存期包括計劃，需求分析和定義，（B），編碼，軟件測試和運行維護A、軟件開發 B、軟件設計（詳細設計）C、軟件支持 D、軟件定義8、（A）模型的缺點是缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題A、瀑布模型 B、原型模型C、增量模型 D、螺旋模型9、下圖是（B）A、類圖 B、用例圖C、活動圖 D、狀態圖10、下圖中的分叉和匯合是用 ROSE 中的（B）工具實現的。A、關系 B、同步條C、用例 D、實體11、（A）技術是將一個活動圖中的活動狀態進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。A、泳道 B、分叉

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

46、C、接口 D、組件18、（A）是通過到實現語言的映射而把模型轉換為代碼的過程A、正向工程 B、匿向工程C、前向工程 D、后向工程19、軟件是計算機系統中與硬件相互依存的另一部分，它包括程序，數據及相關（A）的完整集合。A、文檔 B、代碼C、圖 D、描述20、一個對象和另一個對象之間，通過消息來進行通信。消息通信在面向對象的語言中即（C）A、方法實現 B、方法嵌套C、方法調用 D、方法定義21、（D）是可復用的，提供明確接口完成特定功能的程序代碼塊。A、模塊 B、函數C、用例 D、軟件構件22、下圖中的空心箭頭連線表示（A）關系A、泛化 B、包含C、擴展 D、實現23、組件圖展現了一組組件之間的

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