第一篇：UML實驗報告[推薦]

UML實驗報告

班 級：軟件0841

姓 名：張文成 學 號：081842173

實驗內容：

用例建模、分析建模、設計建模（1）、設計建模（2）

實驗一：用例建模

[實驗目的] 〃掌握客戶需求分析的方法和步驟

〃了解以用例驅動的軟件開發方法 〃識別并編寫用例

〃掌握用Rose 進行用例建模的具體方法和步驟

[實驗內容] 要求學生根據周圍的實際情況，自選一個小型應用項目，分析業務需求，識別并編寫用例、繪制用例圖以理解系統需求。亦可采用教師指定的“企業綜合信息管理系統”中的“進銷存管理子系統”

[實驗原理和步驟] 建模原理：

(1)需求獲取。以任務和客戶為中心，通過會議、面談等手段對客戶需求進行調研，獲得系統目標、范圍和功能要求的初步說明。(2)用例分析。確定用例，同時采用分層思想，對用例的層次級別進行劃分（高層用例、子系統級、用戶目標級）

（3）用例描述。分層繪制用例圖，撰寫用例的文字描述（采用單欄格式）。

步驟：

（1）需求獲取。自選題目，與相關客戶、領域專家等反復商討，獲得系統目標、范圍和功能要求的初步說明。（也可采用教師指定的題目：“企業綜合信息管理系統”中的“進銷存管理子系統”，但要仔細研讀“企業現狀”、“系統目標、范圍和功能要求”等文字說明）。（2）用例分析。確定系統范圍和邊界、確定參與者、確定用例。（3）用例描述。分層繪制用例圖、描述用例。

畫圖原理：

采用Rose 軟件進行用例建模必須建立在完好的系統用例分析基礎之上．只有做好系統用例分析，系統用例建模才能這到預期的效果。步驟：

（1）分層繪制用例圖，每層采用“包”進行管理。

（2）以“企業綜合信息管理系統”-> “進銷存管理”子系統-> “銷售管理”-> “合同管理”->“收款單處理”為主線，完成附錄2 中的操作過程（亦可選擇“企業綜合信息管理系統”-> “進銷存管理”子系統-> “庫存管理”-> “原材料出庫”->“領料單處理”主線）

[ 實驗結果]

實驗2 分析建模

[ 實驗目的](1)理解面向對象系統分析和對象類建模(概念建模)的概念(2)了解和掌握面向對象系統分析的方法和步驟(3)了解和掌握尋找待開發系統中類(概念)的方法和技巧(4)掌握使用ROSE 繪制概念模型的方法

[ 實驗內容] 在用例分析的基礎上，選擇第一個迭代周期打算開發的用例，建立相關的概念模型。

[ 實驗原理和步驟] 建模原理：

(1)使用概念目錄列表（見下圖）和非正式分析法（識別出問題域的文本描述中的名詞短語，然后將其作為概念或屬性的候選對象。）相結合的方法識別概念。因此，待開發用例的文字描述中，名詞可能成為概念或屬性的候選對象；表示行為的動詞詞組有可能成為事務型或過程型對象；形容詞詞組有可能對應抽象的名詞型概念。

采用的技術基本上就是：ER 圖+純行為+OO 的聚合、泛化。（2）最終關聯的數量介于“需要知道”型關聯與【“需要知道”型關聯+“需要理解”型（從通用關聯列表中派生出 的，見下圖）】之間。

步驟：

（1）識別關鍵用例作為第一個迭代周期的開發目標（一般是在用例圖中被依賴得比較多的用例）?？梢赃x“企業綜合信息管理系統”-> “進銷存管理”子系統-> “庫存管理”-> “原材料出庫”->“領料單處理”主線中的“領料單處理”用例；也可以選“企業綜合信息管理系統”-> “進銷存管理”子系統-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。（其實，選“庫存管理”主線更合適；當然，如果要實現產銷一體化，以銷售訂單指導生產和采購，并實現零庫存目標，那么一切工作就以銷售管理為中心。即便如此，首選“增加合同”用例也更為合適。）

（2）識別概念和重要屬性。

（3）建立概念間的關聯。

畫圖原理：

（1）可以采用“邏輯視圖”下的類圖描述概念模型，只不過每個類中只有類名和屬性，沒有方法。在概念建模 階段也沒有必要確定屬性的類型和訪問屬性。

（2）概念間的關聯可以采用一般關聯（無方向實線），當然，對于聚合和泛化，應采用相應的連線（組合：實心菱形+實線；聚合：空心菱形+實線；泛化：空三角形+實線）

步驟：

（0）前提條件：第一個迭代周期可以選“企業綜合信息管理系統”

-> “進銷存管理”子系統-> “庫存管理”->“原材料出庫”->“領料單處理”主線中的“領料單處理”用例；也可以選“企業綜合信息管理系統”->“進銷存管理”子系統-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。做好與此用例相關的概念模型

（1）建立相關的概念模型的基礎上，在“邏輯視圖”下的類圖中描述概念模型，可以直接在類圖main 中繪制，也可采用類似用例圖中用過的分包機制

(2）繪制概念和重要屬性。（3）繪制概念間的關聯。

[ 實驗結果]

[ 實驗總結] ① 對重點實驗結果進行分析；

② 實驗中的問題和提高：對自己的分析或設計進行評價，指出合理和不足之處，提出改進的方案。

③ 收獲與體會：篩選概念的要點；區分概念與屬性的要點；關聯取舍的要點；畫圖時如何防止關聯重名。

實驗3 設計建模（1）

[ 實驗日期]2011年5月20日 [ 實驗目的](1)理解順序圖的基本概念

（2）了解和掌握軟件工程中用例邏輯時序的分析方法（3）掌握使用ROSE 創建順序圖的方法

[ 實驗內容] 在用例模型和概念模型的基礎上，對首選的用例進行事件分解，識別出系統事件（系統操作），（并寫出契約的后置條件）；為每個系統事件畫順序圖，為對象分配職責。

[ 實驗原理和步驟] 原理：

(1)在系統順序圖中，所有的系統都被當成黑盒子看待，順序圖的重點是參與者發起的跨越系統邊界的事件。

(2)系統事件是由某參與者發起的指向系統的輸入事件。一個事件的發生能夠觸發一個響應操作的執行。

(3)請仔細研究下圖,考察它是如何從左邊的“購買商品”用例的文字描述中分解出3 個系統事件的。

（4）參照用例模型和概念模型，為每個系統操作估計后置條件。（實例創建、形成關聯、屬性修改）（5）按照設計模式為對象分配職責。

步驟：

（1）分析首選用例的文字描述，按事件進行分解，識別出系統事件。（下面以“企業綜合信息管理系統”-> “進銷存管理”子系統-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“收款單處理”用例為例）。

我們暫不考慮批處理。第一個核對，因為要將“貨款金額填寫到合同中”。后置條件顯然有“銷售合同”的屬性修改。此合同顯然已經存在，不需要創建，但需要根據合同編號find，然后形成關聯。第二個核對需要根據合同明細到倉庫的“存貨明細”（概念模型中還沒有）中去查。此核對發生前雖然敲了一下鍵盤，但隨后并沒有新的消息穿越系統邊界，因此這仍然是同一個系統事件。先考慮成功場景，應該向庫存系統發提貨單（概念模型中還沒有）就結束了。后續的削減庫存（核銷）、預警顯然不是銷售管理員的職權，并且真正的核銷必須由倉庫的發貨人執行，才能保證貨帳一致。并且“生產廠家”與“郵購公司”的運作方式不同，后者是自己的員工取貨并郵寄，而前者還有可能是來人來車取貨，這時倉庫收到取貨單后并不能立即自動處理（開發貨單），必須等取貨人到達才能處理。

根據題意，本項目應該是“生產廠家”模式。這又存在一個問題，如

果在開出提貨單后不修改庫存，可能影響并發用戶和后續付款單的處理。所以有必要設計一個“臨時存貨明細”（概念模型中還沒有）（不是真實的“存貨明細”）供修改，何時按存貨明細”進行刷新應該是庫存管理系統的事（比如每天夜里刷新，但因為雨雪天氣，取貨 人遲遲不提貨，是提貨單作廢（相當于退回銷售系統，付款單變為未處理）還是就強行刷新（此時有沖突危險）？）失敗場景。向“生產調度部門”發送“產品生產申請單”。如果是專門為此單進行生產，那么還應該有庫存系統發來的“產品入庫通知處理”用例來調用本用例進行發貨。本題顯然一概根據付款單運作，因此如果失敗，就不處 理付款單，但按日期把它排在待處理付款單的前面。從前面的分析來看，就一個系統事件，我們就命名為“付款單處理(pb:付款單)”（2）為每個系統事件估計后置條件。(以上已做了部分分析)（3）按設計模式進行設計。

首先考慮控制者,領域控制者選參與者角色，即“銷售人員”。為了避免使用FORM,窗口等表示層對象,我們人造一 個類”應用協調者”向控制者發送消息。

[ 實驗結果]

① 對重點實驗結果進行分析；

② 實驗中的問題和提高：對自己的分析或設計進行評價，指出合理和不足之處，提出改進的方案。

③ 收獲與體會：事件分解的要點；控制者選擇的要點；繪制順序圖的要點。

[ 實驗總結] ① 對重點實驗結果進行分析；

② 實驗中的問題和提高：對自己的分析或設計進行評價，指出合理和不足之處，提出改進的方案。

③ 收獲與體會：事件分解的要點；控制者選擇的要點；繪制順序圖的要點。

實驗4 設計建模（2）

[ 實驗日期] 2011年5月27日 [ 實驗目的](1)理解面向對象類之間關聯關系的概念(2)了解和掌握分析類之間的關聯關系的方法

(3)了解和掌握待開發系統中類之間關聯關系的分析方法(4)完善設計類圖，掌握使用ROSE 對關聯進行建模的過程

[ 實驗內容] 根據設計建模（1）中的交互分析，進一步設計關聯和對象可見性（補

上遺漏的關聯）,完善設計類圖。

[ 實驗原理和步驟] 建模原理：

（1）關聯關系描繪了給定類的對象個體之間的語義連接，是類與類之間的連接。關聯可以分為一般關聯、聚合關 聯、組合關聯和依賴關聯等。

（2）一般關聯包括一對類的二元關聯及多個類之間的多元關聯。

（3）聚合(Aggregation)表示整體和部分之間較強的關聯關系，聚合關系的多重性大于1，則稱為共享聚合。

（4）組合(Composition)關系表示整體和部分之間有比聚合關系更強的關系，它們之間是一對一的關系，即同生死共存亡，組合關系不能共享。

（5）依賴關系是一種使用關系，表現為一個對象僅僅調用了另一個對象的服務?？梢允褂孟铝械闹笇Х结樍谐鰰簳r性的關系：

(1)存在兩個或兩個以上的類相互之間就可能有關聯。(2)類的操怍(成員函數)的參數列表里出現其他類的對象。(3)一個類包含另一個類的對象(對象成員)。(4)根據一般常識可能會出現的關聯。步驟：

（1）分析已建立的設計類圖和交互圖，進一步設計關聯和

對象可見性（補上遺漏的關聯）。（下面以“企業綜合 信息管理系統”-> “進銷存管理”子系統-> “銷售管理”-> “合同管理”->“收款單處理”主線中 的“收款單處理”用例為例）。

在銷售管理子系統中，定義的各個類之間一般都有關系發生。銷售人員和客戶(大客戶)共同簽署銷售合同，銷售合同中涉及到多種可以銷售的產品，合同經公司經理審查并簽字后該合同才能生效，付款單需要客戶付款，銷售人員簽發催款單向客戶催繳欠款，銷售人員制定銷售計劃，銷售人員要檢查督促執行期合同按合同執行、履 約，履約后的合同轉到履約合同數據庫存檔備查等等。例如：

（a）銷售人員與客戶：一般關聯，多對多

（b）銷售合同與合同明細，銷售計劃與計劃明細：組合。（c）付款單與客戶：依賴關系。《如果付款單類中有“統計付款金額(客戶類客戶對象)”操作的話，付款 單類就依賴客戶類》（2）完善設計類圖 畫圖原理：

（1）關聯關系描繪了給定類的對象個體之間的語義連接，是類與類之間的連接。關聯可以分為一般關聯、聚合關 聯、組合關聯和依賴關聯等。

（2）一般關聯包括一對類的二元關聯及多個類之間的多元關聯。

（3）聚合(Aggregation)表示整體和部分之間較強的關聯關系，聚合關系的多重性大于1，則稱為共享聚合。

（4）組合(Composition)關系表示整體和部分之間有比聚合關系更強的關系，它們之間是一對一的關系，即同生死共存亡，組合關系不能共享。

（5）依賴關系是一種使用關系，表現為一個對象僅僅調用了另一個對象的服務。步驟：

（1）在關聯和對象可見性分析的基礎上，補充一般關聯、組合，泛化、依賴

（a）一般關聯關系要注意關聯的命名以及哪個是role A 哪個是role B。

(b)一般關聯選中role B detail 中的aggregate，就變成聚合；再選中by value 就變成組合。(c)依賴畫虛線箭頭。（2）完善設計類圖

[實驗結果] ① 對重點實驗結果進行分析；

② 實驗中的問題和提高：對自己的分析或設計進行評價，指出合理和不足之處，提出改進的方案。

③ 收獲與體會：分析依賴關系的要點，繪制關聯的要點。通過實驗了解UML的建模的步驟和方法，了解用例圖和類圖等的畫法，了解系統的分析和建模方法。增加動手和思維能力，使自己更加的了解軟件系統前期開發的軟件定義和分析方法。

第二篇：UML實驗報告

一：需求分析

在我國十年前ATM（自動取款機）還是一個很新鮮的事物，現在在城市的大街小巷隨處可見。我們在日常生活中也經常和ATM打交道。本章我們將以簡化的ATM系統為例將前面幾章中學到的用例圖、類圖、順序圖、狀態圖、活動圖及協作圖知識運用到此例中。二：銀行ATM機系統UML建模設計 1.用例圖

參與者“銀行儲戶”和ATM機。簡化后的ATM機僅有取款、存款及其余功能。其余功能不做詳細說明。

銀行儲戶在ATM機上完成取款、存款及其他業務。2.類圖

整個銀行系統包括了帳戶庫、銀行儲戶庫及ATM系統。

許多單個的帳戶組成了帳戶庫。帳戶具有帳戶類型、帳戶號、余額三個屬性，均為private，其類型分別為char，int，double。六個操作分別為setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance為protected其余均為public。

setType設置帳戶類型，返回類型為void，參數類型為char，輸入帳戶類型。getType獲取帳戶類型，返回類型為char，無參數。

setAccountNumbe設置帳戶號，返回類型為void，參數類型為int，輸入帳戶號。getAccountNumbe獲取帳戶號，返回類型為int，無參數。

caculateBalance計算余額，返回類型為void，參數為double，第一個參數為輸入存取款數額，第二個參數為存款余額，既為輸入也為輸出。getBalance獲取帳戶余額，返回類型為double，無參數。

許多銀行儲戶組成了儲戶庫。ATM系統包含了許多ATM機。銀行儲戶及ATM機兩個類包含哪些屬性，哪些操作，它們的可見性及操作的返回類型、參數個數、參數類型從類圖上都一目了然。更多的屬性及操作都可以一一加上，使這個類圖更詳細更完整，從而使參與項目的每個成員都能無歧義的明了整個設計的類的結構。同樣對于一個真正的銀行系統，這個類圖過于簡單。比如帳戶類型我們可以先定義一個abstract class，它包含一個帳戶最基本的屬性及操作。而有些操作先定義為abstract，如余額的計算。然后再繼承這個abstract class，我們可以有saving account 和checking account等等。不同的帳戶有不同的余額計算方法，我們可以加上具體的算法。對于不同的帳戶可能還有一些它特有的操作，我們也可以加上，比如saving account在存款達到多少時可以享受機票打折的優惠。通過類圖不僅可以使設計者明確的表達自己的設計意圖，也能幫組自己整理思路，充實及優化自己的設計。

3.順序圖

描述顧客在ATM機上取款時信息的流動情況。以時間為順序。因為是示例圖，所以整個過程是沒有出現任何故障時的流程，并且只畫到了取款結束。通過這個圖，我們可以看出消息是如何在系統中不同對象之間進行交互。

通過流程圖我們可以很清楚地看到系統是如何工作的，系統各部分之間的信息及控制是如何發送的，整個流程是否合理。流程圖對我們的設計起到了很好的幫助作用。注意在本圖沒有一個生命線終端有一個“X”，這是因為這個流程中還未遇到有對象生命結束。當有對象生命結束時需在對應的生命線終端畫“X”，表明這個對象在這時被銷毀。

首先銀行儲戶將ATM卡插入讀卡機，讀卡機將信息傳給客戶管理，客戶管理提出查詢密碼，顯示部分將輸入密碼請求顯示出來….銀行儲戶讀卡機顯示輸入設備客戶管理點鈔機事務管理1: 插入ATM卡2: 接受ATM卡3: 查詢密碼4: 顯示輸入密碼請求5: 輸入密碼6: 密碼傳遞7: 請求確認密碼的合法性8: 確認密碼的合法性9: 詢問服務類別10: 顯示輸入服務類別請求11: 輸入取款請求12: 取消請求13: 詢問取款數額14: 顯示輸入數額請求15: 輸入取款數額16: 傳遞取款數額17: 詢問取款數額確認18: 顯示確認數額請求19: 輸入確認20: 傳遞確認信息21: 數額合法性確認請求22: 確認數額的合法性23: 計算儲戶余額24: 出鈔請求25: 出鈔26: 取鈔27: 傳遞余額并詢問是否需要其它服務28: 顯示儲戶余額并顯示其它服務

第三篇：UML實驗報告

計 《面向對象分析與設計 U ＭL 》 實驗報告 學 學

號:180 １0 ８２１３ 姓 姓

名: 龐志偉 班 班

級:08 級軟件 2 班

指導老師:姚 姚 宇峰 峰 實驗及作業一 一、實驗目得

了解軟件工程等基礎知識,為后續得統一建模語言 UＭL 知識得學習做好準備工作。

二、實驗設備與環境

裝有Ｖisiｏ、RatｈionalRoｓｅ得計算機。

三、實驗內容 １、復習闡述“軟件工程開發模型”得相關概念,并分析各種模型得優缺點,寫成實驗報告。

２、熟悉ＵMＬ軟件設計工具 Vｉsio、Ratioｎal Rose 得安裝及環境

四、實驗過程及結果 1、軟件工程開發模型有(1)瀑布模型,(2)原型模型,(3)螺旋模型,(4)噴泉模型(１)瀑布模型 將功能得實現與設計分開,便于分工協作,即采用結構化得分析與設計方法將邏輯實現與物理實現分開。將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試與運行維護等六個基本活動,并且規定了它們自上而下、相互銜接得固定次序,如同瀑布流水,逐級下落。

優點: 1)為項目提供了按階段劃分得檢

瀑布模型查點。

2)當前一階段完成后,您只需要去關注后續階段。

3)可在迭代模型中應用瀑布模型。

缺點: １)在項目各個階段之間極少有反饋。

2)只有在項目生命周期得后期才能瞧到結果。

３)通過過多得強制完成日期與里程碑來跟蹤各個項目階段。

(2)原型模型 原型模型又稱快速原型,它就是增量模型得另一種形式;它就是在開發真實系統之前,構造一

個原型,在該原型得基礎上,逐漸完成整個系統得開發工作、快速原型模型得第一步就是建造一個快速原型,實現客戶或未來得用戶與系統得交互,用戶或客戶對原型進行評價,進一步細化待開發軟件得需求。通過逐步調整原型使其滿足客戶得要求,開發人員可以確定客戶得真正需求就是什么;第二步則在第一步得基礎上開發客戶滿意得軟件產品。

優點:克服瀑布模型得缺點,減少由于軟件需求不明確帶來得開發風險。

缺點:所選用得開發技術與工具不一定符合主流得發展;快速建立起來得系統結構加上連續得修改可能會導致產品質量低下。

(３)螺旋模型 螺旋模型采用一種周期性得方法來進行系統開發。這會導致開發出眾多得中間版本。使用它,項目經理在早期就能夠為客戶實證某些概念。該模型就是快速原型法,以進化得開發方式為中心,在每個項目階段使用瀑布模型法、這種模型得每一個周期都包括需求定義、風險分析、工程實現與評審 4 個階段,由這４個階段進行迭代、軟件開發過程每迭代一次,軟件開發又前進一個層次。螺旋模型基本做法就是在“瀑布模型”得每一個開發階段前引入一個非常嚴格得風險識別、風險分析與風險控制,它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險,直到所有得主要風險因素都被確定。

優點: １)設計上得靈活性,可以在項目得各個階段進行變更。

2)以小得分段來構建大型系統,使成本計算變得簡單容易。

3)客戶始終參與每個階段得開發,保證了項目不偏離正確方向以及項目得可控性。

4)隨著項目推進,客戶始終掌握項目得最新信息 , 從而她或她能夠與管理層有效地交互。

5)客戶認可這種公司內部得開發方式帶來得良好得溝通與高質量得產品。

缺點: 很難讓用戶確信這種演化方法得結果就是可以控制得。建設周期長,而軟件技術發展比較快,所以經常出現軟件開發完畢后,與當前得技術水平有了較大得差距,無法滿足當前用戶需求。

(4)噴泉模型 噴泉模型就是一種以用戶需求為動力,以對象為驅動得模型,主要用于采用對象技術得軟件開發項目。該模型認為軟件開發過程自下而上周期得各階段就是相互迭代與無間隙得特性。軟件得某個部分常常被重復工作多次,相關對象在每次迭代中隨之加入漸進得軟件成分。無間隙指在各項活動之間無明顯邊界,如分析與設計活動之間沒有明顯得界限,由于對象概念得引入,表達分析、設計、實現等活動只用對象類與關系,從而可以較為容易地實現活動得迭代與無間隙,使其開發自然地包括復用。

優點: 噴泉模型不像瀑布模型那樣,需要分析活動結束后才開始設計活動,設計活動結束后才開始編碼活動。該模型得各個階段沒有明顯得界限,開發人員可以同步進行開發。其優點就是可以提高軟件項目開發效率,節省開發時間,適應于面向對象得軟件開發過程。

缺點: 由于噴泉模型在各個開發階段就是重疊得,因此在開發過程中需要大量得開發人員,因此不利于項目得管理、此外這種模型要求嚴格管理文檔,使得審核得難度加大,尤其就是面對可能隨時加入各種信息、需求與資料得情況。

五、實驗小結: 通過本次實驗讓我了解了軟件工程開發得 4 中主要模型與這些模型得優缺點、初次安裝并使用 UML 軟件設計工具 Visio 與Ｒatioｎaｌ Rose 使我初步認識了軟件開發中 UML 得設計、實驗及作業二 一、實驗目得

1、了解面向對象得基本概念 2、熟悉面向對象得分析、設計過程 3、了解基于 UML 得面向對象分析設計過程

二、實驗設備與環境

裝有 Visio、ＲａthｉｏnaｌRose 得計算機。

三、實驗內容 1、熟悉 Raｔｉonal Rosｅ得使用。

２、熟悉利用統一建模語言進行分析、設計軟件得過程,完成作業:論述面向對象(OO)方法得特點、優勢以及存在得問題。

四、實驗過程及結果 面向對象方法(Oｂject—Oriented Ｍethod)就是一種把面向對象得思想應用于軟件開發過程中,指導開發活動得系統方法,簡稱 OO(Objｅcｔ－Ｏｒｉenｔed)方法,就是建立在“對象“概念基礎上得方法學。對象就是由數據與容許得操作組成得封裝體,與客觀實體有直接對應關系,一個對象類定義了具有相似性質得一組對象、而每繼承性就是對具有層次關系得類得屬性與操作進行共享得一種方式。所謂面向對象就就是基于對象概念,以對象為中心,以類與繼承為構造機制,來認識、理解、刻畫客觀世界與設計、構建相應得軟件系統、主要特征:封裝性,多態性 優勢:(１)強調從現實世界中客觀存在得事物(對象)出發來認識問題域與構造系統,這就使系統開發者大大減少了對問題域得理解難度,從而使系統能更準確地反映問題域。

(2)運用人類日常得思維方法與原則(體現于 OO 方法得抽象、分類、繼承、封裝、消息通訊等基本原則)進行系統開發,有益于發揮人類得思維能力,并有效地控制了系 統復雜性。

(3)對象得概念貫穿于開發過程得終,使各個開發階段得系統成分具良好得對應,從而顯著地提高了系統得開發效率與質量,并大大降低系統維護得難度。

(４)對象概念得一致性,使參與系統開發得各類人員在開發得各所段具有共同語言,有效地改善了人員之間得 交流與協作、(5)對象得相對穩定性與對易變因素隔離,增強了系統得應變能力。

(6)對象類之間得繼承關系與對象得相對獨立性,對軟件復用提供了強有力得支持。

存在得問題:(1)軟件重用性差

(2)軟件可維護性差

(3)開發出得軟件不能滿足用戶需要 五、實驗小結: 通過本次實驗了解 Raｔional Ｒose 得使用。學習利用統一建模語言進行分析、設計軟件得過程,通過上網查詢,了解有關面向對象(OO)方法得特點、優勢以及存在得問題。

實驗及作業三

三、實驗目得

1、講解用例、參與者、ＵＭＬ語境建模技術與ＵＭＬ需求建模技術。

2、通過實例使學生有一個初步認識,為后面得學習打下堅實得基礎。

四、實驗設備與環境

裝有 Visｉｏ、RationａlRosｅ得計算機。

四、實驗內容 1、掌握“參與者”、“用例”、“各種關系”在Ｖisio 或 Raｔｉonal Rosｅ中得設計方法。體會用例圖得設計方法。

2、以圖書館管理系統為例,完成其用例圖得設計。并書寫實驗報告、四、實驗過程及結果 圖書管理系統中得參與者有讀者、圖書管理員與系統管理員、讀者能夠進行查詢,借書(有擴展關系預定與續借),還書,罰款(有擴展關系超期罰款與損壞罰款),登陸;圖書管理員能夠進行登陸,處理借書,處理還書(有擴展關系收罰金),解除預定;讀者訂書借書還書刪除預訂信息圖書管理員<>罰款<> 系統管理員能夠進行登陸,管理用戶與管理圖書目錄(有擴展關系新增書籍與刪除書記);

圖書維護讀者信息維護新增圖書刪除圖書系統維護系統管理員 五、實驗小結: 通過本次實驗第一次使用ＲOＳE 畫用例圖使我初步了解了什么就是用例圖,如何進行畫用例圖。通過畫圖書管理系統得用例圖后,使我能夠正確使用ＲOSE 軟件畫用例圖、實驗及作業四 一、實驗目得

講解靜態視圖中得類圖、對象圖等建模知識,并通過圖書館管理系統得靜態視圖進行實例講解,為學生以后得學習打下堅實得基礎。

二、實驗設備與環境

裝有Ｖiｓio、ＲationalRose 得計算機。

三、實驗內容 實現并改進圖書館管理系統中得類圖。

四、實驗過程及結果 根據實驗三得用例圖畫出如下得類圖、1、讀者,圖書管理員,與系統管理員都就是用戶,就是用戶類得泛化;2、登錄與用戶就是依賴關系,登錄需要取決于用戶類里得用戶名與密碼。

五、實驗小結:

通過本次實驗就是我初步了解了如何將用例圖轉換成相應得類圖。在畫類圖就是需要弄清楚類與類之間得各種關系,只有弄清楚類之間得關系后才能畫好類圖。

《面向對象分析與設計(UML)》實驗五 一、實驗目得

了解動態視圖中得狀態圖得設計、建模,包括:狀態機、狀態、轉移等概念。

二、實驗設備與環境

裝有 Vｉsio、RａtionaｌRose 得計算機、三、實驗內容 實現并改進圖書館管理系統中得狀態圖、四、實驗過程及結果

新書可借書刪除已預定 已借書借書 預定借書還書取消預定

新用戶 賬戶可借書可借書不可借書還書達借書上限刪除用戶戶欠款還款借書超期或者損壞 五、實驗小結:

通過本次實驗得練習,讓我初步了解并使用 Rｏsｅ畫圖書管理系統得狀態圖。在畫圖中通過分析畫出圖書管理系統得每個狀態過程。

《面向對象分析與設計(UML)》實驗六 一、實驗目得

了解活動圖得設計方法及建模技術。重點介紹了活動圖得構成要素、判定、對象流、泳道等概念,以及活動圖與狀態圖得關系、活動圖與流程圖得區別。

二、實驗設備與環境

裝有 Viｓio、ＲａtionaｌRｏse 得計算機。

三、實驗內容 實現并改進圖書館管理系統中得活動圖。

四、實驗過程及結果

登錄更新用戶信息更新新圖書信息 五、實驗小結:

通過本實驗得練習就是我初步了解了如何畫活動圖、《面向對象分析與設計(ＵML)》實驗七 一、實驗目得

了解動態視圖中得時序圖、協作圖得設計、建模。

二、實驗設備與環境

裝有 Visio、RatiｏｎａlRose 得計算機。

三、實驗內容 實現并改進圖書館管理系統得時序圖,并在此基礎上做出相應得協作圖。

四、實驗過程及結果 圖書管理系統時序圖: 1、借閱者預定圖書

2、系統管理員添加新圖書

３、系統管理員刪除舊圖書 借閱者 圖書系統 圖書名 預定記錄登陸查找返回查找...預定圖書生成預定記錄系統管理員 圖書系統 圖書名 圖書條目添加...查找返回創建新...4、圖書管理員處理還書 系統管理員 圖書系統 圖書名 圖書條錄刪除圖書...查找返回刪除圖書...刪除...圖書管理員 還書 圖書名 借閱者 借書記錄 圖書條目掃描...查找圖書條目更新圖書...刪除借閱...更新借閱者可借圖...查找

5、圖書管理員處理借書 協作圖如下: １、借閱者借書 2、圖書管理員處理還書 ３、圖書管理員處理借書 ４、系統管理員新增圖書 圖書管理員 借書 圖書名 借閱者 借書記錄 圖書條目查找圖...查找查找圖書...查找...驗證借閱者...查找創建借閱...借閱者 圖書系統圖書名圖書目錄借書記錄1: 驗證借閱者ID2: 預定圖書4: 預定3: 查找圖書名5: 創建借書記錄圖書管理員圖書系統借書記錄圖書名 圖書目錄1: 查找借閱者ID2: 還書4: 還書 5: 更新記錄3: 更新目錄圖書管理員圖書系統借書記錄圖書目錄圖書名預定記錄4: 驗證是否達借書數量上限1: 驗證借閱者ID5: 借書2: 查找是否有預定記錄3: 更新借書記錄6: 更新記錄

5、系統管理員刪除舊圖

五、實驗小結

通過這 8個課時得課程學習,使我初步了解什么就是時序圖與協作圖,如何使用Ｒose 畫時序圖與協作圖。時序圖就是消息時間順序得交互圖,描述了對象之間消息傳遞得時間順序,在實驗課上通過分析與畫出了圖書管理系統得時序圖。而協作圖描述得就是與對象結構相關得信息,表示一個類操作得實現。通過時序圖可以清楚得了解到圖書管理系統所有對象之間消息傳遞得時間順序,通過協作圖又能夠清楚得瞧到各個對象之間得結構關系。

Ｒ ＲOSE 雙向工程實驗八 五、實驗目得

1、了解 UML 模型與代碼得對應關系。

２、了解 ROSE 得雙向工程、六、實驗設備與環境

裝有Ｖｉsiｏ、RatｉonaｌRosｅ得計算機。

六、實驗內容 1、掌握正向工程在 Visio 或Ｒationaｌ Ｒose 中得實現、體會類圖中類關系在源代碼中得體現。

(１)簡單類、在類中添加屬性與方法、類可見性設置。

(2)類圖中得關系:泛化關系、關聯關系(包括一對一關聯、一對多關聯、多對多關聯、聚合關系、組合關系)、依賴關系、實現關系、系統管理員圖書系統圖書名圖書目錄1: 添加新書 2: 查找3: 更新目錄系統管理員圖書系統圖書名 圖書目錄刪除圖書1: 2: 查找3: 更新

請依次將上述實驗內容得ＵML 圖與生成得代碼附在實驗過程及結果中,并說明UMＬ中得模型在源代碼中就是否體現、２、掌握逆向工程在 Visio 或 Ratioｎａl Rｏse 中得實現。體會 Rａtional Ｒoｓe 在閱讀代碼中得好處。

六、實驗過程及結果 1.1 在 Rｏse 得 LｏgicａlＶiew 下新建簡單類Ｐｅopｌe 如下:

通過使用 UＭＬ中得正向工程得到代碼如下:

1。２類圖中得關系 Ａ:泛化關系

生成代碼如下:

B:關聯關系

(1)一對一:

生成代碼如下:

(2)一對多

生成代碼如下:

(３)多對多

?生成代碼如下:

(4)聚合關系

生成代碼如下:

C:依賴關系:

生成代碼如下:

D:實現關系:

生成代碼如下:

七、實驗小結: 通過本次課程得學習與實驗得聯系就是我初步了解到如何使用Rose 進行ＵML 得正向工程與逆向工程,通過正向工程可以將類圖轉化成代碼,通過逆向工程可以將代碼轉換正相應得類。

組件圖與配置圖設計 實驗九 九 一、實驗目得

1、了解組件圖得概念及應用。

２、了解配置圖得概念及應用。

二、實驗設備與環境

裝有 Visio、Rａtiｏnal Ｒｏse 得計算機。

三、實驗內容 1、實現并完善圖書管理系統中得組件圖、配置圖、四、實驗過程及結果 1、組件圖: 通過對系統中得組件與組件得接口進行建模得到如下圖書館管理系統組件圖:

2、部署圖: 通過對系統中得節點進行建模得到如下圖書管理系統得部署圖:

五、實 驗小結: 通過這次課時得學習,使我初步了解 了什么就是組件圖與部署圖。組件圖描述 了軟件得各種組件與它們之間得依賴關系。而部署圖即配置圖,配置圖描述了運行 軟件得系統中硬件與軟件得物理結構、通 過實驗得練習,我完成得圖書管理系統得 組件圖與部署圖。

圖書管理系統圖書條目圖書借書記錄預定記錄讀者信息數據庫服務器借書機圖書管理員系統管理員

第四篇：UML實驗報告

UML 實 驗 報 告

實驗一

用例圖

一、實驗結果

1、整理實驗結果

2、小結實驗心得體會

用例模型用于需求分析階段，它描述了待開發系統的功能需求，并驅動了需求分析之后各階段的開發工作。用例圖是UML中用來對系統的動態方面進行建模的7種圖之一。用例圖描述了用例、參與者以及它們之間的關系。用例圖從用戶角度描述系統功能，并指出各功能的操作者。

通過本次實驗，我熟悉 Rational Rose 建模環境，更加清楚的了解了用例圖的語義和功能，如何清晰明了的識別參與者、用例，學會了如何使用事件流描述用例。同時掌握了用例間的類屬關系、Include關系和Extend關系的語義、功能和應用。最后通過本次實驗學習了如何使用用例圖為系統的上下文以及系統的需求建模。

二、思考題

1、如果要刪除參與者、用例，請問是在導航窗口刪除，還是在繪圖窗口刪除？

答：都可以刪除，但在繪圖窗口中有兩種刪除方式：一種是只刪除參與者、用例，而不改變其在導航窗口中的存在，另一種是從建模中完全刪除。

2、如果要刪除參與者和用例的聯系，用例和用例的聯系，請問是在繪圖中刪除，還是在參與者或用例的設置對話框中刪除？ 答：都可以刪除。

實驗二

類對象模型的建立

一、實驗結果 1．整理實驗結果。

2．小結實驗心得體會。

類圖是面向對象系統建模最常用的圖，描述了類圖、接口集、協作以及它們之間的關系。類圖描述了系統的靜態設計視，該視主要體現系統的功能需求，即系統應該提供給用戶的服務。

通過本次實驗，加深了我對類圖語義的理解和功能的應用，掌握了類之間的聯系，關聯、依賴、聚合等，同時基本掌握了在 Rational Rose中繪制類的關聯、依賴、泛化關系。

二、思考題

選中一個模型對象，點擊鼠標右鍵，比較快捷菜單項“Edit——Delete”與“Edit——Delete from Model”，它們二者之間區別在哪里？

答：“Edit——Delete”只刪除繪圖窗口中的圖形，而不改變其在導航窗口中的存在；“Edit——Delete from Model” 是從建模中完全刪除。

實驗三

順序圖、協作圖

一、實驗結果 1.整理實驗結果。

2.小結實驗心得體會

順序圖描述了對象之間的動態合作關系，它強調對象之間消息發送的時間順序，同時顯示對象之間的交互。協作圖與順序圖是同構的，Rose 可自動轉換。順序圖是強調消息的交互作用圖，協作圖描述了對象間的關系，是強調發送和接收消息的對象的組織結構的交互作用圖。

通過本次實驗，掌握了對圖書管理功能中的借書用例、還書用例進行動態建模。實驗過程中由于對Rational Rose工具軟件的不熟識，導致出現了不該出現的錯誤。在設計階段，順序圖中需要引入邊界類和控制類，在識別對象職責的基礎上，需要將消息轉換為類的方法，為方法定義參數、返回值類型，便于計算機的實現。其中，為方法定義參數、返回值類型的時候，還是不能夠快速準確的作出判斷。

實驗四

活動圖

一、實驗結果 1．整理實驗結果。

2．小結實驗心得體會

在UML中，活動圖是為系統的動態方面建模的7個圖之一?；顒訄D主要是一個流圖，它描述了從活動到活動的控制流，它還可以用來描述對象在控制流的不同點從一個狀態轉移到另一個狀態時的對象流。

通過本次實驗，我對活動圖的語義和功能有了更深層次的理解和應用，并對活動圖的組成部分，包括動作狀態、活動狀態、分支、分叉和泳道、對象流，逐一進行了學習。同時基本掌握了用活動圖來描述系統中“借出圖書”用例的業務過程。實驗過后本應該有完整的截圖，由于自己的粗心馬虎，造成截圖的不完整性。

實驗五

狀態圖

一、實驗結果 1．整理實驗結果。

2.小結實驗心得體會。

狀態圖描述了一個特定對象的所有可能狀態，以及引起狀態躍遷的事件。狀態圖用來模擬系統的動態方面，這些動態方面指系統對象按事件發生順序排序的行為。狀態圖可以用來描述整個系統、子系統或類的動態方面，還可以用來描述用力的一個腳本。

通過本次實驗，我熟悉了狀態圖的基本功能和使用方法。掌握了如何使用建模工具繪制狀態圖方法。同時完成了圖書管理業務中，資源項“ResourceItem”的狀態圖。

實驗六

組件圖和部署圖

一、實驗結果 1．整理實驗結果。

2．小結實驗心得體會。

組件圖和部署圖是用來為面向對象系統的物理實現建模的兩種圖。組件圖描述了組件、組件間的關系，表示了組件之間的組織和依賴關系，它用來為系統的靜態實現視建模。部署圖描述了節點和運行其上的組件的配置，它用來模擬系統的靜態部署視。

通過本次實驗，我理解了組件圖的基本概念及組件圖的應用：邏輯部署。理解了部署圖的基本概念。及部署圖的應用：物理部署。掌握了組件圖和部署圖繪制的方法。完成了系統的組件圖和系統的部署圖。

二、思考題

1.為什么要求相對應的類名、組件名和實現組件的文件名相同？

答：相應的名字中能夠找到相應的類的信息。如果組件名、類名和 Java 文件名不相同，會出現實體類的語法錯誤。

實驗七

正向工程

一、實驗報告要求 1．整理實驗結果。

2．小結實驗心得體會。

正向工程是對一個系統物理結構實現的高層抽象性、邏輯性及獨立性設計的傳統處理過程。通過本次試驗，學會了利用 Rose 工具生成代碼框架及生成數據庫腳本，同時在實現過程中使用轉換后的代碼和數據庫腳本。了解了Java 編程綜合練習。

二、思考題

1．在本案例中，并未對實體類 ResourceTitle 設置主鍵，系統在生成數據庫腳本時是如何處理的？

答：（1）設置類的持久化特性和主鍵：在導航窗口右擊類，如“Loan”，選擇快捷菜單“Open Standard Specification”菜單項，打開類設置對話框。選中“Detail”選項卡中的“Persistent”特性。點擊 OK按鈕，關閉設置對話框。然后，在導航窗口中展開類的屬性，鼠標右擊類的某個屬性，如類“Loan”的屬性“LoanID”，選中快捷菜單中的“Data Modeler”的“Part of Object Identity”屬性，這樣，在生成數據模型時，該屬性就成為表 Loan 的主鍵。（2）創建數據庫組件。（3）在導航窗口中選擇所生成的數據庫模式 S_0，單擊鼠標右鍵，選擇快捷菜單項“Data Modeler——Forward Engineer”，出現生成數據庫腳本的導航界面，鼠標單擊“Next”按鈕，在導航界面輸入腳本文件的保存路徑，注意 SQL Server2000 的腳本文件擴展名用.sql。單擊“Next”直至完成腳本文件的生成。

2.本案例中，ResourceTitle 與BookTitle、DiscTitle的繼承關系，SQL Server 2000 關系型數據庫的轉換合理嗎？如不合理，請問該如何修改？ 答：不合理。

第五篇：UML實驗報告

《OO & UML》實驗報告

班級：

學號：

姓名：

實驗一

業務建模

一、實驗目的

二、實驗內容

三、實驗過程和結果分析

四、總結

1． 實驗內容總結 2． 心得體會