UML課后習題答案整理

1UML 課后習題答案整理2目錄第 1章 面向?qū)ο蠓治雠c設計引論 .41.1 填空題 .42.1 選擇題 .43.1 簡答題 .4第 2章 統(tǒng)一建模語言 UML與建模工具 Rational Rose.51.1 填空題 .52.1 選擇題 .53.1 簡答題 .5第 3章 需求分析與用例模型 .71.1 填空題 .72.1 選擇題 .73.1 簡答題 .74.1 練習題 .7第 4章 系統(tǒng)靜態(tài)分析與靜態(tài)模型 .131.1 填空題 .132.1 選擇題 .133.1 簡答題 .134.1 練習題 .14第 5章 系統(tǒng)動態(tài)分析與交互模型 .151.1 填空題 .152.1 選擇題 .153.1 簡答題 .154.1 練習題 .16第 6章 系統(tǒng)動態(tài)分析與行為模型、 .191.1 填空題 .192.1 選擇題 .193.1 簡答題 .204.1 練習題 .21第 7章 系統(tǒng)設計與實現(xiàn)模型 .261.1 填空題 .262.1 選擇題 .263.1 簡答題 .2634.1 練習題 .27第 8章 軟件工程引論與統(tǒng)一軟件過程 RUP.281.1 填空題 .282.1 選擇題 .283.1 簡答題 .28第 9章 分工情況 .314第 1章 面向?qū)ο蠓治雠c設計引論1.1填空題（1）面向過程程序=算法+數(shù)據(jù)結(jié)構（2）對象（3）屬性 操作2.1選擇題（1）A（2）A3.1簡答題（1）面向過程方法和面向?qū)ο蠓椒ǖ谋容^：面向過程方法首先關心的是功能，強調(diào)以過程為中心，采用模塊化、自頂向下、逐步細分的解決問題的方法，結(jié)構清晰、可讀性好。然而，由于用戶的需求和軟、硬件技術的不斷發(fā)展變化，經(jīng)常出現(xiàn)互相矛盾的數(shù)據(jù)需求，因此分析和設計越來越困難，開發(fā)過程前期入手快而后期頻繁改動的現(xiàn)象比較常見。面向?qū)ο蠓椒▌t從所處理的數(shù)據(jù)入手，以數(shù)據(jù)為中心來描述系統(tǒng)。數(shù)據(jù)相對于功能而言，具有更強的穩(wěn)定性，這樣設計出的系統(tǒng)模型往往能較好地映射問題域模型。面向?qū)ο蠓椒ǖ挠行裕好嫦驅(qū)ο蟪绦蛟O計是一種自下而上的程序設計方法，往往從問題的一部分著手，一點一點地構建出整個程序。面向?qū)ο笤O計以數(shù)據(jù)為中心，類作為表現(xiàn)數(shù)據(jù)的工具，成為劃分程序的基本單位。面向?qū)ο笫前褬嫵蓡栴}的事物分解成各個對象，建立對象的目的不是為了完成一個步驟，而是為了描述某個事物在整個解決問題的步驟中的行為。（2） 面向?qū)ο蠓治?OOA)、面向?qū)ο笤O計(OOD）、面向?qū)ο缶幋a（OPP)、面向?qū)ο鬁y試(OOT)、面向?qū)ο缶S護(OOM)5第 2章 統(tǒng)一建模語言 UML與建模工具 Rational Rose1.1 填空題（1）Grady Booch James Rumbaugh Ivar Jacobson（2）用例（3）部署（4）Rational Rose PowerDesigner Visio（5）用例視圖 邏輯視圖 構件視圖 部署視圖（6) 部署2.1選擇題（1）B（2）AB（3）D（4）BC（5）AC（6）A（7）AC3.1 簡答題（1）統(tǒng)一建模語言 特點:用圖形化的符號描述分析與設計（2）需求分析、分析、設計、構造、測試（3）視圖：由一組圖構成，代表完整系統(tǒng)描述中的一個抽象，顯示這個系統(tǒng)中的一個特定的方面。UML 包含九種視圖，一類是靜態(tài)圖，包含用例圖、類圖、對象圖、構件圖、部署圖；另一類是動態(tài)圖，包括序列圖、協(xié)作圖、狀態(tài)圖和活動圖。（4）畫圖、積累、導航、多用戶支持、產(chǎn)生代碼、逆轉(zhuǎn)、集成、覆蓋模型的所有抽象層、模型互換6（5）選擇待轉(zhuǎn)換的目標模型、檢查 java 語言的語法錯誤、設置代碼生成屬性、生成代碼（6）用例視圖：包括系統(tǒng)中的所有參與者、用例和用例圖，關注系統(tǒng)功能的高層抽象，適合于對系統(tǒng)進行分析和獲取需求，而不關注于系統(tǒng)的具體實現(xiàn)方法。邏輯視圖：關注系統(tǒng)如何實現(xiàn)用例中所描述的功能，主要是對系統(tǒng)功能性需求提供支持。構件視圖：用來描述系統(tǒng)中各個實現(xiàn)模塊以及它們之間的依賴關系。部署視圖：包括進程、處理器和設備，顯示系統(tǒng)的實際部署情況，是為了便于理解系統(tǒng)在一組處理節(jié)點上的物理分布。7第 3章 需求分析與用例模型1.1填空題（1）參與者、用例、關系（2）關聯(lián)關系、泛化關系、包含關系、擴展關系2.1選擇題（1）D（2）D3.1簡答題（1）參與者：參與者必須與系統(tǒng)有交互；參與者必須是系統(tǒng)外部的；參與者的名稱一般是名詞或名詞短語。用例：用例是外部可見得系統(tǒng)功能單元，這些功能由系統(tǒng)單元所提供，并通過一系列系統(tǒng)單元與一個或多個參與者之間交換的消息所表達；用例的名字是一個動詞短語字符串。（2）簡要說明、事件流、用例場景、特殊需求、前置條件、后置條件。（3）用戶、系統(tǒng)、天氣（4）不正確。參與者之間泛化關系的含義是：把某些參與者的共同行為抽取出來表示為通用行為，且把它們描述成為超類（父類）。普通瀏覽者和系統(tǒng)管理員的基本行為不一致，不能作為子用例。因此泛化關系使用不正確。（5）不正確。購物和修改會員資料應是登錄的包含關系。4.1練習題用例編號：001用例名：系統(tǒng)管理員登錄用例描述：系統(tǒng)管理員根據(jù)賬號和密碼，登錄學生信息管理系統(tǒng)8參與者：系統(tǒng)管理員前置條件：系統(tǒng)正常運行時間后置條件：若系統(tǒng)管理員成功，管理員可以對學生的基本信息、班級信息、賬號進行管理；若管理員未登錄成功，則不能進行這些操作?；韭窂剑?、管理員進入系統(tǒng)；2、管理員輸入賬戶和密碼；3、管理員提交信息；4、系統(tǒng)對管理員輸入的信息進行有效性檢查；5、管理員可對學生信息等進行操作；擴展點：1、管理員的賬號錯誤（1）系統(tǒng)彈出錯誤窗口；（2）管理員重新輸入2、 管理員密碼錯誤（1）系統(tǒng)彈出密碼錯誤（2）管理員重新輸入（3）管理員找回密碼用例編號：002用例名：查詢學生信息用例描述：管理員輸入學生信息，系統(tǒng)顯示該生信息參與者：管理員前置條件：管理員登錄成功后置條件：管理員輸入學生信息后系統(tǒng)顯示該生信息，查詢成功后可進行修改或 刪除等。基本路徑：1、管理員輸入查看某位學生信息；2、管理員提交信息；93、系統(tǒng)對應信息查看數(shù)據(jù)庫；4、系統(tǒng)顯示該生信息；擴展點：輸入學生信息不存在；用例編號：003用例名：錄入學生信息用例描述：教師錄入學生信息；參與者：教師前置條件：教師登錄成功后置條件：數(shù)據(jù)庫中錄入該信息成功，之后可以查看到該信息；基本路徑：1、教師輸入某位學生的基本信息；2、教師提交信息；3、系統(tǒng)數(shù)據(jù)庫添加該信息；4、系統(tǒng)顯示該生信息；擴展點：無用例編號：004用例名：學生查詢成績用例描述：學生查詢自己的成績；參與者：學生前置條件：學生登錄成功；后置條件：學生查詢個人成績成功進行其它操作；基本路徑：101、學生輸入自己的信息；2、學生提交信息；3、系統(tǒng)數(shù)據(jù)庫查詢該生成績；4、系統(tǒng)顯示該生成績 ；擴展點：無4-1 學生用例圖114-2 教師用例圖124-3 校領導用例圖4-4 系統(tǒng)管理員用例圖13第 4章 系統(tǒng)靜態(tài)分析與靜態(tài)模型1.1填空題（1）對象 鏈（2）關聯(lián)關系 依賴關系 泛化關系 實現(xiàn)關系（3）類2.1選擇題（1）AB（2）D（3）D（4）C3.1簡答題（1）類圖包括：名稱、屬性和操作（2）對象圖包括名稱和屬性（3）類圖可以為系統(tǒng)的詞匯建模，模型化簡單的協(xié)作，模型化邏輯數(shù)據(jù)庫模式對象圖能夠說明復雜的數(shù)據(jù)結(jié)構，可以表示快照中的行為。（4）關系：類圖和對象圖是兩種最重要的靜態(tài)模型。UML 中的類圖和對象圖顯示了系統(tǒng)的靜態(tài)結(jié)構，其中類，對象和關聯(lián)是圖形元素的基礎。14不同：類圖 對象圖類圖包括：名稱，屬性和操作 對象圖包括：名稱和屬性在類的名稱分欄中只有類名 對象的名稱形式為：“對象名：類名”，匿名對象的名稱形式為“：類名”類的屬性分欄定義了所有屬性的特征 對象則指定了屬性的當前值以便測試用例類中列出了操作 對象圖中不包括操作，因為對于同屬于一個類的對象來說，其操作都是相同的類使用關聯(lián)連接，關聯(lián)使用名稱，角色，多重性以及約束等特征定義。類代表的是對對象的分類，所以必須說明可以參與關聯(lián)的對象數(shù)目對象使用鏈連接，鏈擁有名稱，角色，但沒有多重性。對象代表的是單獨的實體，所有的鏈都是一對一的，因此不涉及到多重性。4.1練習題確定類：系統(tǒng)管理員，銷售員，用戶，商品15第 5章 系統(tǒng)動態(tài)分析與交互模型1.1填空題（1）對象、生命線、激活、消息（2）生命線（3）激活（4）發(fā)送者、接收者、活動（5）類元角色、關聯(lián)角色（6）對象、消息、鏈（7）交互（8）鏈（9）消息2.1選擇題（1）ABCD（2）C（3）ABC（4）BCD（5）C（6）D（7）D3.1簡答題（1）在序列圖中，創(chuàng)建對象操作使用帶箭頭的消息表示，箭頭指向被創(chuàng)建對象的框。對象創(chuàng)建之后就會具有生命線，就像序列圖中的任何其他對象一樣。對象符號下方是對象的生命線，它持續(xù)到對象被銷毀或者圖結(jié)束。在序列圖中，對象被銷毀是使用在對象的生命線上畫大“X”表示，在銷毀新創(chuàng)建的對象或者序列圖中是任何其他對象時，都可以使用，“X”的位置16是在導致對象被銷毀的信息上或者在對象自我終結(jié)的地方。（2）序列圖中的消息有普通消息、自身消息、返回消息、過程調(diào)用消息、同步消息、異步調(diào)用消息、阻止消息和超時消息等。（3）為用例建造邏輯模型。為某個用例的泛化功能提供其所缺乏的解釋。 記錄一個存在系統(tǒng)的對象現(xiàn)在如何交互。 用來演示某個用例最終產(chǎn)生的所有的路徑。（4）序列圖是由對象、生命線、激活和消息等構成的。（5）協(xié)作圖就是表現(xiàn)對象協(xié)作關系的圖，它表示了協(xié)作中作為各種類元角色的對象所處的位置，在圖中主要顯示了類元角色（Classifier Roles）和關聯(lián)角色（Association Roles）。作用分為以下三個方面：通常描繪對象之間消息的傳遞情況來反映具體的使用語境的邏輯表達、顯示對象及其交互關系的空間組織結(jié)構、表現(xiàn)一個類操作的實現(xiàn)。（6）協(xié)作圖和序列圖都是交互圖，它們既是等價的，又有所區(qū)別。 序列圖表示了時間消息序列，但沒有表示靜態(tài)對象關系。序列圖可以有效的幫助我們觀察系統(tǒng)的順序行為。 協(xié)作圖用于表示一個協(xié)同中的對象之間的關系和消息以及描述一個操作或分類符的實現(xiàn)。 在對系統(tǒng)進行行為建模時，通常做法是用序列圖按時間順序?qū)刂屏鹘＃脜f(xié)作圖按對象組織對控制流建模。4.1練習題（1）如圖 4-1 所示。174-1 還書序列圖模型（2）如圖 4-2 所示。4-2 打印文件工作流的序列圖18（3）如圖 4-3 所示。4-3 ATM 機取款序列圖19第 6章 系統(tǒng)動態(tài)分析與行為模型1.1填空題（1）轉(zhuǎn)換（2）事件（3）簡單狀態(tài) 組成狀態(tài)（4）歷史狀態(tài)（5）內(nèi)部（6）泳道（swimlane）（7）活動圖（8）分叉 結(jié)合（9）動作狀態(tài)（10）對象流2.1選擇題（1）D（2）ABCD（3）A（4）D（5）C（6）AB（7）D（8）B（9）D203.1簡答題（1）狀態(tài)機是一種記錄下給定時刻狀態(tài)的設備，它可以根據(jù)各種不同的輸入對每個給定的變化而改變其狀態(tài)或引發(fā)一個動作。在 UML 中狀態(tài)機由對象的各個狀態(tài)和連接這些狀態(tài)的轉(zhuǎn)換組成，是展示狀態(tài)與狀態(tài)轉(zhuǎn)換的圖。一個狀態(tài)圖本質(zhì)上就是一個狀態(tài)機，或者是狀態(tài)機的特殊情況，它本質(zhì)上是一個狀態(tài)機中的元素的投影。 （2）狀態(tài)圖的組成要素：狀態(tài)、轉(zhuǎn)換、判定、同步、事件等。 （3）簡單狀態(tài)指的是不包含其他狀態(tài)的狀態(tài)，簡單狀態(tài)沒有子結(jié)構，但是它可以具有內(nèi)部轉(zhuǎn)換、進入動作、退出動作等。組成狀態(tài)是在簡單狀態(tài)之外，一種可以包含嵌套子狀態(tài)的狀態(tài)。（4）順序組成狀態(tài)中最多只能有一個初態(tài)和一個終態(tài)，在順序組成狀態(tài)中多個子狀態(tài)是互斥的，不能同時存在。并發(fā)組成狀態(tài)有兩個或多個并發(fā)的子狀態(tài)，能說明很多事情發(fā)生在同一時刻，為了分離不同的活動，組成狀態(tài)被分解成區(qū)域，每個區(qū)域都包含一個不同的狀態(tài)圖，各個狀態(tài)圖在同一時刻分別運行。（5）活動圖的組成要素：動作狀態(tài)、活動狀態(tài)、組合活動、分叉與結(jié)合、分支與合并、泳道、對象流等。（6）分叉用粗黑線表示。分叉具有一個輸入轉(zhuǎn)換、兩個或者多個輸出轉(zhuǎn)換，每個轉(zhuǎn)換都可以是獨立的控制流。分支是轉(zhuǎn)換的一部分，它將轉(zhuǎn)換路徑分為多個部分，每一部分都有單獨的監(jiān)護條件和不同的結(jié)果，分支的每個路徑的監(jiān)護條件是互斥的，這樣可以保證只有一條路徑的轉(zhuǎn)換被激發(fā)。（7）合并匯合了兩個以上的控制路徑，在任何執(zhí)行中每次只走一條，不同路徑之間是互斥的關系。而結(jié)合則匯合了兩條或兩條以上的并行控制路徑。在執(zhí)行過程中，所有路徑都要走過，先到的控制流要等其他路徑的控制流到達后才能繼續(xù)運行。（8）活動圖是用來描述一個目標所實施一系列活動的過程，描述了系統(tǒng)的動態(tài)特征?；顒訄D是模型中的完整單元，表示一個程序或工作流，常21用于計算流程和工作流程建模?；顒訄D的作用：1）描述一個操作執(zhí)行過程中所完成的工作，說明角色、工作流、組織和對象是如何工作的。2）活動圖對用例描述尤其有用，它可建模用例的工作流，顯示用例內(nèi)部和用例之間的路徑，也可以說明用例的實例是如何執(zhí)行動作以及如何改變對象狀態(tài)的。3）顯示如何執(zhí)行一組相關的動作，以及這些動作如何影響它們周圍的對象。4）活動圖對理解業(yè)務處理過程十分有用?；顒訄D可以畫出工作流用以描述業(yè)務，有利于與領域?qū)＜疫M行交流。通過活動圖可以明確業(yè)務處理操作是如何進行的，以及可能產(chǎn)生的變化。5）描述復雜過程的算法，在這種情況下使用的活動圖和傳統(tǒng)的程序流程圖的功能是相似的。4.1練習題（1）如圖 4-1 所示。224-1 IC 卡電話機狀態(tài)圖23（2）如圖 4-2 所示。4-2 UNIX 進程的狀態(tài)圖24（3）如圖 4-3 所示。4-3 還書過程的狀態(tài)圖25（4）如圖 4-4 所示。4-4 預訂圖書過程的活動圖26第 7章 系統(tǒng)設計與實現(xiàn)模型1. 1填空題（1）代碼特征 身份特征（2）構件圖（3）構件 構件 類或接口（4）虛包（5）部署圖2.1選擇題（1）ABD（2）B（3）ABD（4）CD（5）AD3.1簡答題（1）構件圖適用于下列建模需求：系統(tǒng)源代碼、系統(tǒng)的發(fā)布版本、物理數(shù)據(jù)庫、自適應系統(tǒng)、用于建立業(yè)務模型和用于系統(tǒng)的開發(fā)管理等。 （2）二者都有名稱，都可以實現(xiàn)一組接口，都可以參與依賴關系，都可以被嵌套，都可以有實例，都可以參與交互。類描述了軟件設計的邏輯組織和意圖，而構件這描述了軟件設計的物理實現(xiàn)，類可以有屬性和操作，構件只有操作，只有通過構件使得接口才能使用。（3）在一張基本構件圖中，構件之間最常見的關系是依賴關系和實現(xiàn)關系。（4）在 UML 中，構件主要包括配置構件、工作產(chǎn)品構件和可執(zhí)行構件。274.1練習題（1）如圖 4-1 所示。MainSystem FormDataManager StudentSystemManager4-1 學生信息構件圖（2）如圖 4-2 所示。務務 務務務 務務務務4-2 系統(tǒng)部署圖28第 8章 軟件工程引論與統(tǒng)一軟件過程 RUP1.1填空題（1 ）傳統(tǒng)軟件開發(fā)方法學；軟件開發(fā)新方法學（2）統(tǒng)一軟件開發(fā)過程（Rational Unified Process，RUP）；敏捷方法；微軟方法（3）軟件開發(fā)（4）角色；活動；產(chǎn)物；工作流（5）配置和變更控制工作流；項目管理工作流；環(huán)境工作流2.1選擇題（1）ABCD（2）BCD（3）BCD3.1簡答題（1）它定義了進行軟件開發(fā)的工作步驟，可以保證軟件項目有序的、可控的、高質(zhì)量的完成；可以將面向?qū)ο蠹夹g應用于軟件開發(fā)的所有過程，使軟件系統(tǒng)開發(fā)的所有過程全面結(jié)合，最大限度適應用戶不斷變化的需求，有效降低風險，更好地適應需求變化。（2）優(yōu)點：便于分工協(xié)作；嚴格規(guī)定了每階段必須調(diào)教的文檔；為項目提供了按階段劃分的檢查點。缺點：各階段間具有順序性和依賴性。（3）Rational 統(tǒng)一過程(RUP)是 Rational 軟件公司（現(xiàn)在 Rational 公司被 IBM 并購）創(chuàng)造的軟件工程方法。RUP 描述了如何有效地利用商業(yè)的可靠的方法開發(fā)和部署軟件，是一種重量級過程（也被稱作厚方法學），因此29特別適用于大型軟件團隊開發(fā)大型項目。（4）RUP 是軟件開發(fā)過程的一種，它為有效的使用統(tǒng)一建模語言 UML 提供了指導。RUP 集合了成功的工程實踐經(jīng)驗、面向?qū)ο蟮姆椒?、迭代開發(fā)成要素，能夠把 UML 建模語言和軟件開發(fā)的過程很好地結(jié)合在一起，非常適合面向?qū)ο蟮能浖_發(fā)。 UML 作為一種建模語言，要和具體的軟件過程相結(jié)合。這就實現(xiàn)了 UML 與 RUP 相結(jié)合。（5）RUP 的軟件生命周期在時間上被分解為四個順序的階段，分別是：初始階段、細化階段、構造階段和交付階段。每個階段結(jié)束于一個主要的里程碑；每個階段本質(zhì)上是兩個里程碑之間的時間跨度。初始階段。也稱先啟階段。目標是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。初始階段結(jié)束時的第一個重要的里程碑：生命周期目標里程碑。細化階段。細化階段是四個階段中最為關鍵和重要的階段。目標是分析問題領域，建立健全的體系結(jié)構接觸，編制項目計劃，淘汰項目中最高風險的元素。細化階段結(jié)束時的第二個重要的里程碑：生命周期結(jié)構里程碑。構造階段。在構造階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細測試。構造階段結(jié)束時是第三個重要的里程碑：初始功能里程碑。交付階段。交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準備的產(chǎn)品測試，基于用戶反饋的少量的調(diào)整。在交付階段的終點是第四個里程碑：產(chǎn)品發(fā)布里程碑。（6）RUP 的六個核心工作流為核心過程工作流，分別如下：商業(yè)建模該工作流的主要目的是對系統(tǒng)的商業(yè)環(huán)境和范圍進行建模，確保所有參與人員對開發(fā)系統(tǒng)有共同的認識，并在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程、角色和責任。需求分析需求工作流的目標是描述系統(tǒng)應該做什么，并使開發(fā)人員和用戶就這一描述達成共識。為了達成該目標，需要對 需求的功能和約束進行提取、組織、文檔化；最重要的是定義系統(tǒng)功能及用戶界面，明確可以需要的系統(tǒng)的功30能。分析與設計分析與設計工作流講需求轉(zhuǎn)換成未來系統(tǒng)的設計。為系統(tǒng)開發(fā)一個健壯的結(jié)構并調(diào)整設計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。實現(xiàn)實現(xiàn)工作流包含定義代碼的組織結(jié)構、實現(xiàn)