第一篇：UML實(shí)驗(yàn)報(bào)告四

XI`AN TECHNOLOGICAL UNIVERSITY

實(shí)驗(yàn)報(bào)告

實(shí)驗(yàn)四 交互圖 專

業(yè)：

信息與計(jì)算科學(xué)

班

級(jí)：

121001

姓

名：

劉修花

學(xué)

號(hào)：

121001125

實(shí)驗(yàn)學(xué)時(shí)：

課時(shí)

指導(dǎo)教師：

時(shí)華

成績：

2015

年 10 月 30 日

西安工業(yè)大學(xué)實(shí)驗(yàn)報(bào)告 專業(yè) 信息與計(jì)算科學(xué) 班級(jí) 121001 姓名 劉修花 學(xué)號(hào) 121001125 實(shí)驗(yàn)課程 UML 系統(tǒng)建模 指導(dǎo)教師 時(shí)華 實(shí)驗(yàn)日期 2015-10-30 同實(shí)驗(yàn)者

實(shí)驗(yàn)項(xiàng)目 交互圖 實(shí)驗(yàn)設(shè)備及器材 電腦 一、實(shí)驗(yàn)?zāi)康木毩?xí)使用 Rational Rose 繪制時(shí)序圖、協(xié)作圖等交互圖。

二、實(shí)驗(yàn)原理

時(shí)序圖用以顯示對(duì)象之間的動(dòng)態(tài)合作關(guān)系。它強(qiáng)調(diào)對(duì)象之間消息發(fā)送的順序，同時(shí)也顯示對(duì)象之間的交互過程。

協(xié)作圖同序列圖是等價(jià)的，但著重描述對(duì)象間的協(xié)作關(guān)系。

三、

實(shí)驗(yàn)步驟、數(shù)據(jù)記錄及處理

時(shí)序圖

單擊菜單中的“Browse”子菜單的“Interaction Diagram”選項(xiàng)，屏幕中出現(xiàn)與創(chuàng)建用例圖類似的界面。選擇命令，進(jìn)入如下圖所示的界面。

在這個(gè)界面中選擇創(chuàng)建順序圖（Sequence），進(jìn)入如下圖所示界面。

訂餐者訂餐

根據(jù)訂餐者訂餐的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.2 商家管理店鋪

根據(jù)商家管理店鋪的時(shí)序圖可以創(chuàng)建如下協(xié)作圖

4.1.3 店鋪管理員管理店鋪信息

根據(jù)店鋪管理員管理店鋪信息的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.4 店鋪管理員建立客戶評(píng)價(jià)檔案

根據(jù)店鋪管理員建立客戶評(píng)價(jià)檔案的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.5 店鋪管理員建立商家監(jiān)察檔案

根據(jù)店鋪管理員建立商家監(jiān)察檔案的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.6 訂單管理員管理訂單

根據(jù)訂單管理員管理訂單的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.7 系統(tǒng)管理員管理訂餐者信息

根據(jù)系統(tǒng)管理員管理訂餐者信息的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.8 系統(tǒng)管理員管理商家信息

根據(jù)系統(tǒng)管理員管理商家信息的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

4.1.9 系統(tǒng)管理員維護(hù)系統(tǒng)

根據(jù)系統(tǒng)管理員維護(hù)系統(tǒng)的時(shí)序圖可以創(chuàng)建如下協(xié)作圖：

第二篇：UML實(shí)驗(yàn)報(bào)告

一：需求分析

在我國十年前ATM（自動(dòng)取款機(jī)）還是一個(gè)很新鮮的事物，現(xiàn)在在城市的大街小巷隨處可見。我們?cè)谌粘Ｉ钪幸步?jīng)常和ATM打交道。本章我們將以簡化的ATM系統(tǒng)為例將前面幾章中學(xué)到的用例圖、類圖、順序圖、狀態(tài)圖、活動(dòng)圖及協(xié)作圖知識(shí)運(yùn)用到此例中。二：銀行ATM機(jī)系統(tǒng)UML建模設(shè)計(jì) 1.用例圖

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

銀行儲(chǔ)戶在ATM機(jī)上完成取款、存款及其他業(yè)務(wù)。2.類圖

整個(gè)銀行系統(tǒng)包括了帳戶庫、銀行儲(chǔ)戶庫及ATM系統(tǒng)。

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

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

setAccountNumbe設(shè)置帳戶號(hào)，返回類型為void，參數(shù)類型為int，輸入帳戶號(hào)。getAccountNumbe獲取帳戶號(hào)，返回類型為int，無參數(shù)。

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

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

3.順序圖

描述顧客在ATM機(jī)上取款時(shí)信息的流動(dòng)情況。以時(shí)間為順序。因?yàn)槭鞘纠龍D，所以整個(gè)過程是沒有出現(xiàn)任何故障時(shí)的流程，并且只畫到了取款結(jié)束。通過這個(gè)圖，我們可以看出消息是如何在系統(tǒng)中不同對(duì)象之間進(jìn)行交互。

通過流程圖我們可以很清楚地看到系統(tǒng)是如何工作的，系統(tǒng)各部分之間的信息及控制是如何發(fā)送的，整個(gè)流程是否合理。流程圖對(duì)我們的設(shè)計(jì)起到了很好的幫助作用。注意在本圖沒有一個(gè)生命線終端有一個(gè)“X”，這是因?yàn)檫@個(gè)流程中還未遇到有對(duì)象生命結(jié)束。當(dāng)有對(duì)象生命結(jié)束時(shí)需在對(duì)應(yīng)的生命線終端畫“X”，表明這個(gè)對(duì)象在這時(shí)被銷毀。

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

第三篇：UML實(shí)驗(yàn)報(bào)告

UML 實(shí) 驗(yàn) 報(bào) 告

實(shí)驗(yàn)一

用例圖

一、實(shí)驗(yàn)結(jié)果

1、整理實(shí)驗(yàn)結(jié)果

2、小結(jié)實(shí)驗(yàn)心得體會(huì)

用例模型用于需求分析階段，它描述了待開發(fā)系統(tǒng)的功能需求，并驅(qū)動(dòng)了需求分析之后各階段的開發(fā)工作。用例圖是UML中用來對(duì)系統(tǒng)的動(dòng)態(tài)方面進(jìn)行建模的7種圖之一。用例圖描述了用例、參與者以及它們之間的關(guān)系。用例圖從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。

通過本次實(shí)驗(yàn)，我熟悉 Rational Rose 建模環(huán)境，更加清楚的了解了用例圖的語義和功能，如何清晰明了的識(shí)別參與者、用例，學(xué)會(huì)了如何使用事件流描述用例。同時(shí)掌握了用例間的類屬關(guān)系、Include關(guān)系和Extend關(guān)系的語義、功能和應(yīng)用。最后通過本次實(shí)驗(yàn)學(xué)習(xí)了如何使用用例圖為系統(tǒng)的上下文以及系統(tǒng)的需求建模。

二、思考題

1、如果要?jiǎng)h除參與者、用例，請(qǐng)問是在導(dǎo)航窗口刪除，還是在繪圖窗口刪除？

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

2、如果要?jiǎng)h除參與者和用例的聯(lián)系，用例和用例的聯(lián)系，請(qǐng)問是在繪圖中刪除，還是在參與者或用例的設(shè)置對(duì)話框中刪除？ 答：都可以刪除。

實(shí)驗(yàn)二

類對(duì)象模型的建立

一、實(shí)驗(yàn)結(jié)果 1．整理實(shí)驗(yàn)結(jié)果。

2．小結(jié)實(shí)驗(yàn)心得體會(huì)。

類圖是面向?qū)ο笙到y(tǒng)建模最常用的圖，描述了類圖、接口集、協(xié)作以及它們之間的關(guān)系。類圖描述了系統(tǒng)的靜態(tài)設(shè)計(jì)視，該視主要體現(xiàn)系統(tǒng)的功能需求，即系統(tǒng)應(yīng)該提供給用戶的服務(wù)。

通過本次實(shí)驗(yàn)，加深了我對(duì)類圖語義的理解和功能的應(yīng)用，掌握了類之間的聯(lián)系，關(guān)聯(lián)、依賴、聚合等，同時(shí)基本掌握了在 Rational Rose中繪制類的關(guān)聯(lián)、依賴、泛化關(guān)系。

二、思考題

選中一個(gè)模型對(duì)象，點(diǎn)擊鼠標(biāo)右鍵，比較快捷菜單項(xiàng)“Edit——Delete”與“Edit——Delete from Model”，它們二者之間區(qū)別在哪里？

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

實(shí)驗(yàn)三

順序圖、協(xié)作圖

一、實(shí)驗(yàn)結(jié)果 1.整理實(shí)驗(yàn)結(jié)果。

2.小結(jié)實(shí)驗(yàn)心得體會(huì)

順序圖描述了對(duì)象之間的動(dòng)態(tài)合作關(guān)系，它強(qiáng)調(diào)對(duì)象之間消息發(fā)送的時(shí)間順序，同時(shí)顯示對(duì)象之間的交互。協(xié)作圖與順序圖是同構(gòu)的，Rose 可自動(dòng)轉(zhuǎn)換。順序圖是強(qiáng)調(diào)消息的交互作用圖，協(xié)作圖描述了對(duì)象間的關(guān)系，是強(qiáng)調(diào)發(fā)送和接收消息的對(duì)象的組織結(jié)構(gòu)的交互作用圖。

通過本次實(shí)驗(yàn)，掌握了對(duì)圖書管理功能中的借書用例、還書用例進(jìn)行動(dòng)態(tài)建模。實(shí)驗(yàn)過程中由于對(duì)Rational Rose工具軟件的不熟識(shí)，導(dǎo)致出現(xiàn)了不該出現(xiàn)的錯(cuò)誤。在設(shè)計(jì)階段，順序圖中需要引入邊界類和控制類，在識(shí)別對(duì)象職責(zé)的基礎(chǔ)上，需要將消息轉(zhuǎn)換為類的方法，為方法定義參數(shù)、返回值類型，便于計(jì)算機(jī)的實(shí)現(xiàn)。其中，為方法定義參數(shù)、返回值類型的時(shí)候，還是不能夠快速準(zhǔn)確的作出判斷。

實(shí)驗(yàn)四

活動(dòng)圖

一、實(shí)驗(yàn)結(jié)果 1．整理實(shí)驗(yàn)結(jié)果。

2．小結(jié)實(shí)驗(yàn)心得體會(huì)

在UML中，活動(dòng)圖是為系統(tǒng)的動(dòng)態(tài)方面建模的7個(gè)圖之一。活動(dòng)圖主要是一個(gè)流圖，它描述了從活動(dòng)到活動(dòng)的控制流，它還可以用來描述對(duì)象在控制流的不同點(diǎn)從一個(gè)狀態(tài)轉(zhuǎn)移到另一個(gè)狀態(tài)時(shí)的對(duì)象流。

通過本次實(shí)驗(yàn)，我對(duì)活動(dòng)圖的語義和功能有了更深層次的理解和應(yīng)用，并對(duì)活動(dòng)圖的組成部分，包括動(dòng)作狀態(tài)、活動(dòng)狀態(tài)、分支、分叉和泳道、對(duì)象流，逐一進(jìn)行了學(xué)習(xí)。同時(shí)基本掌握了用活動(dòng)圖來描述系統(tǒng)中“借出圖書”用例的業(yè)務(wù)過程。實(shí)驗(yàn)過后本應(yīng)該有完整的截圖，由于自己的粗心馬虎，造成截圖的不完整性。

實(shí)驗(yàn)五

狀態(tài)圖

一、實(shí)驗(yàn)結(jié)果 1．整理實(shí)驗(yàn)結(jié)果。

2.小結(jié)實(shí)驗(yàn)心得體會(huì)。

狀態(tài)圖描述了一個(gè)特定對(duì)象的所有可能狀態(tài)，以及引起狀態(tài)躍遷的事件。狀態(tài)圖用來模擬系統(tǒng)的動(dòng)態(tài)方面，這些動(dòng)態(tài)方面指系統(tǒng)對(duì)象按事件發(fā)生順序排序的行為。狀態(tài)圖可以用來描述整個(gè)系統(tǒng)、子系統(tǒng)或類的動(dòng)態(tài)方面，還可以用來描述用力的一個(gè)腳本。

通過本次實(shí)驗(yàn)，我熟悉了狀態(tài)圖的基本功能和使用方法。掌握了如何使用建模工具繪制狀態(tài)圖方法。同時(shí)完成了圖書管理業(yè)務(wù)中，資源項(xiàng)“ResourceItem”的狀態(tài)圖。

實(shí)驗(yàn)六

組件圖和部署圖

一、實(shí)驗(yàn)結(jié)果 1．整理實(shí)驗(yàn)結(jié)果。

2．小結(jié)實(shí)驗(yàn)心得體會(huì)。

組件圖和部署圖是用來為面向?qū)ο笙到y(tǒng)的物理實(shí)現(xiàn)建模的兩種圖。組件圖描述了組件、組件間的關(guān)系，表示了組件之間的組織和依賴關(guān)系，它用來為系統(tǒng)的靜態(tài)實(shí)現(xiàn)視建模。部署圖描述了節(jié)點(diǎn)和運(yùn)行其上的組件的配置，它用來模擬系統(tǒng)的靜態(tài)部署視。

通過本次實(shí)驗(yàn)，我理解了組件圖的基本概念及組件圖的應(yīng)用：邏輯部署。理解了部署圖的基本概念。及部署圖的應(yīng)用：物理部署。掌握了組件圖和部署圖繪制的方法。完成了系統(tǒng)的組件圖和系統(tǒng)的部署圖。

二、思考題

1.為什么要求相對(duì)應(yīng)的類名、組件名和實(shí)現(xiàn)組件的文件名相同？

答：相應(yīng)的名字中能夠找到相應(yīng)的類的信息。如果組件名、類名和 Java 文件名不相同，會(huì)出現(xiàn)實(shí)體類的語法錯(cuò)誤。

實(shí)驗(yàn)七

正向工程

一、實(shí)驗(yàn)報(bào)告要求 1．整理實(shí)驗(yàn)結(jié)果。

2．小結(jié)實(shí)驗(yàn)心得體會(huì)。

正向工程是對(duì)一個(gè)系統(tǒng)物理結(jié)構(gòu)實(shí)現(xiàn)的高層抽象性、邏輯性及獨(dú)立性設(shè)計(jì)的傳統(tǒng)處理過程。通過本次試驗(yàn)，學(xué)會(huì)了利用 Rose 工具生成代碼框架及生成數(shù)據(jù)庫腳本，同時(shí)在實(shí)現(xiàn)過程中使用轉(zhuǎn)換后的代碼和數(shù)據(jù)庫腳本。了解了Java 編程綜合練習(xí)。

二、思考題

1．在本案例中，并未對(duì)實(shí)體類 ResourceTitle 設(shè)置主鍵，系統(tǒng)在生成數(shù)據(jù)庫腳本時(shí)是如何處理的？

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

2.本案例中，ResourceTitle 與BookTitle、DiscTitle的繼承關(guān)系，SQL Server 2000 關(guān)系型數(shù)據(jù)庫的轉(zhuǎn)換合理嗎？如不合理，請(qǐng)問該如何修改？ 答：不合理。

第四篇：UML實(shí)驗(yàn)報(bào)告總結(jié)

實(shí)驗(yàn)一 熟悉Rational Rose及建立用例模型 實(shí)驗(yàn)

二、時(shí)序圖和協(xié)作圖建模

實(shí)習(xí)三 UML類圖與包圖建模（2學(xué)時(shí)）實(shí)驗(yàn)四 狀態(tài)圖和活動(dòng)圖建模 實(shí)驗(yàn)五

組件與部署圖

實(shí)驗(yàn)一 熟悉Rational Rose及建立用例模型

（2學(xué)時(shí)）

一、實(shí)驗(yàn)名稱：熟悉（2學(xué)時(shí)）

二、實(shí)驗(yàn)?zāi)康呐c要求：

? 了解和掌握Rose建模工具的使用 ? 掌握怎樣進(jìn)行案例需求分析； ? 掌握UML用例圖建模技術(shù)

三、實(shí)驗(yàn)內(nèi)容：

1、熟悉rose上機(jī)環(huán)境及設(shè)置

2、根據(jù)以下談話設(shè)計(jì)出用例圖

Rational Rose及建立用例模型

四、實(shí)驗(yàn)步驟：

見實(shí)驗(yàn)說明書

實(shí)習(xí)二（2學(xué)時(shí)）

一、實(shí)驗(yàn)名稱：

時(shí)序圖和協(xié)作圖建模（2學(xué)時(shí)）

二、實(shí)驗(yàn)?zāi)康呐c要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進(jìn)行系統(tǒng)分析，并進(jìn)行UML靜態(tài)建模分析； ? 掌握UML時(shí)序圖和協(xié)作圖建模技術(shù)

三、實(shí)驗(yàn)內(nèi)容：

根據(jù)以下談話設(shè)計(jì)出時(shí)序圖和協(xié)作圖建模。

四、實(shí)驗(yàn)步驟：

、UML類圖與包圖建模（2學(xué)時(shí)）

一、實(shí)驗(yàn)名稱：UML類圖與包圖建模（2學(xué)時(shí)）

二、實(shí)驗(yàn)?zāi)康呐c要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進(jìn)行系統(tǒng)分析，并進(jìn)行UML動(dòng)態(tài)建模分析；

三、實(shí)驗(yàn)內(nèi)容：

四、實(shí)驗(yàn)步驟：

實(shí)習(xí)四（2學(xué)時(shí)）

一、實(shí)驗(yàn)名稱：

狀態(tài)圖和活動(dòng)圖建模（2學(xué)時(shí)）

二、實(shí)驗(yàn)?zāi)康呐c要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進(jìn)行系統(tǒng)分析，并進(jìn)行UML動(dòng)態(tài)建模分析； ? 掌握UML狀態(tài)圖和活動(dòng)圖建模技術(shù)

三、實(shí)驗(yàn)內(nèi)容：

四、實(shí)驗(yàn)步驟：

實(shí)習(xí)五

組件與部署圖與代碼生成（2學(xué)時(shí)）

一、實(shí)驗(yàn)名稱：

組件與部署圖（2學(xué)時(shí)）

二、實(shí)驗(yàn)?zāi)康呐c要求：

三、實(shí)驗(yàn)內(nèi)容：

四、實(shí)驗(yàn)步驟：

第五篇：UML實(shí)驗(yàn)報(bào)告[推薦]

UML實(shí)驗(yàn)報(bào)告

班 級(jí)：軟件0841

姓 名：張文成 學(xué) 號(hào)：081842173

實(shí)驗(yàn)內(nèi)容：

用例建模、分析建模、設(shè)計(jì)建模（1）、設(shè)計(jì)建模（2）

實(shí)驗(yàn)一：用例建模

[實(shí)驗(yàn)?zāi)康腯 〃掌握客戶需求分析的方法和步驟

〃了解以用例驅(qū)動(dòng)的軟件開發(fā)方法 〃識(shí)別并編寫用例

〃掌握用Rose 進(jìn)行用例建模的具體方法和步驟

[實(shí)驗(yàn)內(nèi)容] 要求學(xué)生根據(jù)周圍的實(shí)際情況，自選一個(gè)小型應(yīng)用項(xiàng)目，分析業(yè)務(wù)需求，識(shí)別并編寫用例、繪制用例圖以理解系統(tǒng)需求。亦可采用教師指定的“企業(yè)綜合信息管理系統(tǒng)”中的“進(jìn)銷存管理子系統(tǒng)”

[實(shí)驗(yàn)原理和步驟] 建模原理：

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

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

步驟：

（1）需求獲取。自選題目，與相關(guān)客戶、領(lǐng)域?qū)＜业确磸?fù)商討，獲得系統(tǒng)目標(biāo)、范圍和功能要求的初步說明。（也可采用教師指定的題目：“企業(yè)綜合信息管理系統(tǒng)”中的“進(jìn)銷存管理子系統(tǒng)”，但要仔細(xì)研讀“企業(yè)現(xiàn)狀”、“系統(tǒng)目標(biāo)、范圍和功能要求”等文字說明）。（2）用例分析。確定系統(tǒng)范圍和邊界、確定參與者、確定用例。（3）用例描述。分層繪制用例圖、描述用例。

畫圖原理：

采用Rose 軟件進(jìn)行用例建模必須建立在完好的系統(tǒng)用例分析基礎(chǔ)之上．只有做好系統(tǒng)用例分析，系統(tǒng)用例建模才能這到預(yù)期的效果。步驟：

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

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

[ 實(shí)驗(yàn)結(jié)果]

實(shí)驗(yàn)2 分析建模

[ 實(shí)驗(yàn)?zāi)康腯(1)理解面向?qū)ο笙到y(tǒng)分析和對(duì)象類建模(概念建模)的概念(2)了解和掌握面向?qū)ο笙到y(tǒng)分析的方法和步驟(3)了解和掌握尋找待開發(fā)系統(tǒng)中類(概念)的方法和技巧(4)掌握使用ROSE 繪制概念模型的方法

[ 實(shí)驗(yàn)內(nèi)容] 在用例分析的基礎(chǔ)上，選擇第一個(gè)迭代周期打算開發(fā)的用例，建立相關(guān)的概念模型。

[ 實(shí)驗(yàn)原理和步驟] 建模原理：

(1)使用概念目錄列表（見下圖）和非正式分析法（識(shí)別出問題域的文本描述中的名詞短語，然后將其作為概念或?qū)傩缘暮蜻x對(duì)象。）相結(jié)合的方法識(shí)別概念。因此，待開發(fā)用例的文字描述中，名詞可能成為概念或?qū)傩缘暮蜻x對(duì)象；表示行為的動(dòng)詞詞組有可能成為事務(wù)型或過程型對(duì)象；形容詞詞組有可能對(duì)應(yīng)抽象的名詞型概念。

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

步驟：

（1）識(shí)別關(guān)鍵用例作為第一個(gè)迭代周期的開發(fā)目標(biāo)（一般是在用例圖中被依賴得比較多的用例）。可以選“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “庫存管理”-> “原材料出庫”->“領(lǐng)料單處理”主線中的“領(lǐng)料單處理”用例；也可以選“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。（其實(shí)，選“庫存管理”主線更合適；當(dāng)然，如果要實(shí)現(xiàn)產(chǎn)銷一體化，以銷售訂單指導(dǎo)生產(chǎn)和采購，并實(shí)現(xiàn)零庫存目標(biāo)，那么一切工作就以銷售管理為中心。即便如此，首選“增加合同”用例也更為合適。）

（2）識(shí)別概念和重要屬性。

（3）建立概念間的關(guān)聯(lián)。

畫圖原理：

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

（2）概念間的關(guān)聯(lián)可以采用一般關(guān)聯(lián)（無方向?qū)嵕€），當(dāng)然，對(duì)于聚合和泛化，應(yīng)采用相應(yīng)的連線（組合：實(shí)心菱形+實(shí)線；聚合：空心菱形+實(shí)線；泛化：空三角形+實(shí)線）

步驟：

（0）前提條件：第一個(gè)迭代周期可以選“企業(yè)綜合信息管理系統(tǒng)”

-> “進(jìn)銷存管理”子系統(tǒng)-> “庫存管理”->“原材料出庫”->“領(lǐng)料單處理”主線中的“領(lǐng)料單處理”用例；也可以選“企業(yè)綜合信息管理系統(tǒng)”->“進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。做好與此用例相關(guān)的概念模型

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

(2）繪制概念和重要屬性。（3）繪制概念間的關(guān)聯(lián)。

[ 實(shí)驗(yàn)結(jié)果]

[ 實(shí)驗(yàn)總結(jié)] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：篩選概念的要點(diǎn)；區(qū)分概念與屬性的要點(diǎn)；關(guān)聯(lián)取舍的要點(diǎn)；畫圖時(shí)如何防止關(guān)聯(lián)重名。

實(shí)驗(yàn)3 設(shè)計(jì)建模（1）

[ 實(shí)驗(yàn)日期]2011年5月20日 [ 實(shí)驗(yàn)?zāi)康腯(1)理解順序圖的基本概念

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

[ 實(shí)驗(yàn)內(nèi)容] 在用例模型和概念模型的基礎(chǔ)上，對(duì)首選的用例進(jìn)行事件分解，識(shí)別出系統(tǒng)事件（系統(tǒng)操作），（并寫出契約的后置條件）；為每個(gè)系統(tǒng)事件畫順序圖，為對(duì)象分配職責(zé)。

[ 實(shí)驗(yàn)原理和步驟] 原理：

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

(2)系統(tǒng)事件是由某參與者發(fā)起的指向系統(tǒng)的輸入事件。一個(gè)事件的發(fā)生能夠觸發(fā)一個(gè)響應(yīng)操作的執(zhí)行。

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

（4）參照用例模型和概念模型，為每個(gè)系統(tǒng)操作估計(jì)后置條件。（實(shí)例創(chuàng)建、形成關(guān)聯(lián)、屬性修改）（5）按照設(shè)計(jì)模式為對(duì)象分配職責(zé)。

步驟：

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

我們暫不考慮批處理。第一個(gè)核對(duì)，因?yàn)橐獙ⅰ柏浛罱痤~填寫到合同中”。后置條件顯然有“銷售合同”的屬性修改。此合同顯然已經(jīng)存在，不需要?jiǎng)?chuàng)建，但需要根據(jù)合同編號(hào)find，然后形成關(guān)聯(lián)。第二個(gè)核對(duì)需要根據(jù)合同明細(xì)到倉庫的“存貨明細(xì)”（概念模型中還沒有）中去查。此核對(duì)發(fā)生前雖然敲了一下鍵盤，但隨后并沒有新的消息穿越系統(tǒng)邊界，因此這仍然是同一個(gè)系統(tǒng)事件。先考慮成功場景，應(yīng)該向庫存系統(tǒng)發(fā)提貨單（概念模型中還沒有）就結(jié)束了。后續(xù)的削減庫存（核銷）、預(yù)警顯然不是銷售管理員的職權(quán)，并且真正的核銷必須由倉庫的發(fā)貨人執(zhí)行，才能保證貨帳一致。并且“生產(chǎn)廠家”與“郵購公司”的運(yùn)作方式不同，后者是自己的員工取貨并郵寄，而前者還有可能是來人來車取貨，這時(shí)倉庫收到取貨單后并不能立即自動(dòng)處理（開發(fā)貨單），必須等取貨人到達(dá)才能處理。

根據(jù)題意，本項(xiàng)目應(yīng)該是“生產(chǎn)廠家”模式。這又存在一個(gè)問題，如

果在開出提貨單后不修改庫存，可能影響并發(fā)用戶和后續(xù)付款單的處理。所以有必要設(shè)計(jì)一個(gè)“臨時(shí)存貨明細(xì)”（概念模型中還沒有）（不是真實(shí)的“存貨明細(xì)”）供修改，何時(shí)按存貨明細(xì)”進(jìn)行刷新應(yīng)該是庫存管理系統(tǒng)的事（比如每天夜里刷新，但因?yàn)橛暄┨鞖猓∝?人遲遲不提貨，是提貨單作廢（相當(dāng)于退回銷售系統(tǒng)，付款單變?yōu)槲刺幚恚┻€是就強(qiáng)行刷新（此時(shí)有沖突危險(xiǎn)）？）失敗場景。向“生產(chǎn)調(diào)度部門”發(fā)送“產(chǎn)品生產(chǎn)申請(qǐng)單”。如果是專門為此單進(jìn)行生產(chǎn)，那么還應(yīng)該有庫存系統(tǒng)發(fā)來的“產(chǎn)品入庫通知處理”用例來調(diào)用本用例進(jìn)行發(fā)貨。本題顯然一概根據(jù)付款單運(yùn)作，因此如果失敗，就不處 理付款單，但按日期把它排在待處理付款單的前面。從前面的分析來看，就一個(gè)系統(tǒng)事件，我們就命名為“付款單處理(pb:付款單)”（2）為每個(gè)系統(tǒng)事件估計(jì)后置條件。(以上已做了部分分析)（3）按設(shè)計(jì)模式進(jìn)行設(shè)計(jì)。

首先考慮控制者,領(lǐng)域控制者選參與者角色，即“銷售人員”。為了避免使用FORM,窗口等表示層對(duì)象,我們?nèi)嗽煲?個(gè)類”應(yīng)用協(xié)調(diào)者”向控制者發(fā)送消息。

[ 實(shí)驗(yàn)結(jié)果]

① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：事件分解的要點(diǎn)；控制者選擇的要點(diǎn)；繪制順序圖的要點(diǎn)。

[ 實(shí)驗(yàn)總結(jié)] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：事件分解的要點(diǎn)；控制者選擇的要點(diǎn)；繪制順序圖的要點(diǎn)。

實(shí)驗(yàn)4 設(shè)計(jì)建模（2）

[ 實(shí)驗(yàn)日期] 2011年5月27日 [ 實(shí)驗(yàn)?zāi)康腯(1)理解面向?qū)ο箢愔g關(guān)聯(lián)關(guān)系的概念(2)了解和掌握分析類之間的關(guān)聯(lián)關(guān)系的方法

(3)了解和掌握待開發(fā)系統(tǒng)中類之間關(guān)聯(lián)關(guān)系的分析方法(4)完善設(shè)計(jì)類圖，掌握使用ROSE 對(duì)關(guān)聯(lián)進(jìn)行建模的過程

[ 實(shí)驗(yàn)內(nèi)容] 根據(jù)設(shè)計(jì)建模（1）中的交互分析，進(jìn)一步設(shè)計(jì)關(guān)聯(lián)和對(duì)象可見性（補(bǔ)

上遺漏的關(guān)聯(lián)）,完善設(shè)計(jì)類圖。

[ 實(shí)驗(yàn)原理和步驟] 建模原理：

（1）關(guān)聯(lián)關(guān)系描繪了給定類的對(duì)象個(gè)體之間的語義連接，是類與類之間的連接。關(guān)聯(lián)可以分為一般關(guān)聯(lián)、聚合關(guān) 聯(lián)、組合關(guān)聯(lián)和依賴關(guān)聯(lián)等。

（2）一般關(guān)聯(lián)包括一對(duì)類的二元關(guān)聯(lián)及多個(gè)類之間的多元關(guān)聯(lián)。

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

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

（5）依賴關(guān)系是一種使用關(guān)系，表現(xiàn)為一個(gè)對(duì)象僅僅調(diào)用了另一個(gè)對(duì)象的服務(wù)。可以使用下列的指導(dǎo)方針列出暫時(shí)性的關(guān)系：

(1)存在兩個(gè)或兩個(gè)以上的類相互之間就可能有關(guān)聯(lián)。(2)類的操怍(成員函數(shù))的參數(shù)列表里出現(xiàn)其他類的對(duì)象。(3)一個(gè)類包含另一個(gè)類的對(duì)象(對(duì)象成員)。(4)根據(jù)一般常識(shí)可能會(huì)出現(xiàn)的關(guān)聯(lián)。步驟：

（1）分析已建立的設(shè)計(jì)類圖和交互圖，進(jìn)一步設(shè)計(jì)關(guān)聯(lián)和

對(duì)象可見性（補(bǔ)上遺漏的關(guān)聯(lián)）。（下面以“企業(yè)綜合 信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中 的“收款單處理”用例為例）。

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

（a）銷售人員與客戶：一般關(guān)聯(lián)，多對(duì)多

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

（1）關(guān)聯(lián)關(guān)系描繪了給定類的對(duì)象個(gè)體之間的語義連接，是類與類之間的連接。關(guān)聯(lián)可以分為一般關(guān)聯(lián)、聚合關(guān) 聯(lián)、組合關(guān)聯(lián)和依賴關(guān)聯(lián)等。

（2）一般關(guān)聯(lián)包括一對(duì)類的二元關(guān)聯(lián)及多個(gè)類之間的多元關(guān)聯(lián)。

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

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

（5）依賴關(guān)系是一種使用關(guān)系，表現(xiàn)為一個(gè)對(duì)象僅僅調(diào)用了另一個(gè)對(duì)象的服務(wù)。步驟：

（1）在關(guān)聯(lián)和對(duì)象可見性分析的基礎(chǔ)上，補(bǔ)充一般關(guān)聯(lián)、組合，泛化、依賴

（a）一般關(guān)聯(lián)關(guān)系要注意關(guān)聯(lián)的命名以及哪個(gè)是role A 哪個(gè)是role B。

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

[實(shí)驗(yàn)結(jié)果] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：分析依賴關(guān)系的要點(diǎn)，繪制關(guān)聯(lián)的要點(diǎn)。通過實(shí)驗(yàn)了解UML的建模的步驟和方法，了解用例圖和類圖等的畫法，了解系統(tǒng)的分析和建模方法。增加動(dòng)手和思維能力，使自己更加的了解軟件系統(tǒng)前期開發(fā)的軟件定義和分析方法。