uml試驗報告總結(jié)

1、本科實驗報告課程名稱：計算機網(wǎng)絡(luò)實驗項目：計算機網(wǎng)絡(luò)實驗地點：逸夫樓404專業(yè)班級：軟件1319班 學號：2013005655學生姓名：張衛(wèi)東指導教師：柴晶目 錄1 .實驗準備：熟悉 UML建模環(huán)境2 .實驗一用例圖3 .實驗二類圖4 .實驗三順序圖及通信圖5 .實驗四活動圖、狀態(tài)圖、組件圖及部署圖實驗一用例圖一、實驗?zāi)康某醪秸莆誙Mlffl例圖的創(chuàng)建方法及其用例的描述。二、實驗要求1 .結(jié)合工具StartUML,熟悉UMLffl例圖的模型元素。2 .使用StartUML工具建模網(wǎng)上書店系統(tǒng)的用例圖。三、實驗主要設(shè)備：臺式或筆記本計算機四、實驗內(nèi)容：根據(jù)下面給出的網(wǎng)上書店問題陳述，分析該系統(tǒng)總

2、體需求，建模網(wǎng)上書店系統(tǒng)的用 例圖并提供一個主要用例的事件流文檔。網(wǎng)上書店陳述：書店經(jīng)理：我們原本是一個傳統(tǒng)的實體書店，顧客要買書都是親自到書店里來的，這樣挺不方 便。面且隨著書店銷售圖書種類和數(shù)量的增加以及顧客的增長，尤其是大量顧客到書店選購圖書， 使得書店場地不足，工作人員也很忙碌。其實，還有一點就是，有不少人進入書店后并不買書，只 是查找一些資料。有的甚至會在這呆上很長的時間直到把書免費看完。這種行為，工作人員一般是 不阻止的，結(jié)果最后這些被看過的書會因為有閱讀過的痕跡而影響銷售。而且現(xiàn)在電子商務(wù)已經(jīng)發(fā) 展起來了，所以我們想到借助網(wǎng)絡(luò)，讓顧客通過網(wǎng)上書店購買圖書。這樣我們書店可以省掉大量

3、的 場地維護和工作人員成本支出，同時計算機可以方便的檢索圖書信息，讓顧客可以足不出戶以更優(yōu) 惠的價格買到需要的書。系統(tǒng)分析員：能談?wù)勀鷮W(wǎng)上書店的要求嗎？書店經(jīng)理：網(wǎng)上書店要能實現(xiàn)對外和對內(nèi)的功能，對外是顧客能在網(wǎng)上書店訂購圖書，提交訂 單。對內(nèi)，書店工作人員能夠通過網(wǎng)上書店及時的看到這些訂單，并進行處理。為了把書送到顧客 手里，我們已經(jīng)聯(lián)系了快遞公司，初步達成協(xié)議，由他們往返場客和書店之間把圖書送到顧客手里。 書店管理員受理訂單后，就會通知快遞公司送貨。當然，書店的圖書上架和下架也應(yīng)該由網(wǎng)上書店 完成了。工作人員甲：實體店中，圖書是按照不同種類放置的，方便顧客挑選。網(wǎng)上書店的圖書也應(yīng)該 能夠

4、按照這種模式分類顯示。這樣，圖書的信息和種類要由網(wǎng)上書店設(shè)置和管理。已有種類的新書 或新種類的圖書上架，網(wǎng)上書店能夠保存這些信息。如果信息輸入錯誤，能夠進行修改。工作人員乙：另外書店會搞一些促銷，推出一些特價圖書。以前這些特價書的信息，都是我們 根據(jù)促銷活動整理出來，貼在書店的醒目位置。促銷活動過后，特價圖書會恢復(fù)原來的價格。希望 網(wǎng)上書店也能夠管理這些特價圖書。系統(tǒng)分析員：能談?wù)勂綍r買書的經(jīng)過嗎？顧客甲：一般都是先在書店里看看圖書的簡要介紹，或者先找找看有沒有自己需要的書，有時 是沒有目標的尋找，有時直奔一類圖書而去。找到我想買的書或者覺得看的書不錯，就會去柜臺結(jié) 帳。工作人員丙：不過有時在

5、結(jié)帳的時候，顧客會突然改變主意，不買一些書或者又回去挑選圖書了。顧客甲：有時好像是這樣的。要是網(wǎng)上書店在結(jié)帳前能方便管理我所選購的圖書就好了，這樣 通過計算機直接操作，就不用跑來跑去了。系統(tǒng)分析員：可以使用虛擬的購物車。工作人員丙：對，這樣在用戶確認購買前可自行管理選購的圖書，決定要不要購買還有的購買 的數(shù)量。系統(tǒng)分析員：顧客先使用虛擬的購物車選購管理圖書，然后提交訂單給書店處理，是這樣吧。書店經(jīng)理：沒錯，就這樣辦。另外最好顧客能夠留下自己的信息，方便以后的購買。顧客：你們可以實行會員制啊。就像我們在網(wǎng)上逛論壇一樣，會員才能發(fā)言，普通游客只能看。這樣我們平時就在網(wǎng)上書店查查資料什么的，只在購買

6、圖書的時候才使用會員身份。書店經(jīng)理：嗯，這樣不僅可以保留你們的信息，也可以保留購買記錄。系統(tǒng)分析員：會員提交購買訂單后，書店打算如何收取或者說用戶怎么付款？書店經(jīng)理：我們可以接受貨到付款，顧客也可以使用網(wǎng)上銀行、匯款等方式付款。顧客：這樣我們就方便多了。對了那是不是付款前，我還多了一次“反悔”的機會啊。書店經(jīng)理：在我們書店沒有受理訂單之前，你們可以取消交易。不過受理后就不行了。通過幾次這樣的訪談（限于篇幅，在此并未列出所有訪談內(nèi)容），可以獲得網(wǎng)上書店的需求信息, 確定系統(tǒng)范圍。網(wǎng)上書店是實現(xiàn)對實體書店內(nèi)部圖書商品和顧客購買圖書的綜合管理系統(tǒng)。1 .用例圖：此處由學生填寫2 .確認訂單用例事件流

7、1 .用例確認訂單的事件流1.1 前置條件在用例確認訂單開始之前,用例登錄該系統(tǒng)以及用例使用虛擬購物車必須完成。1.2 后置條件如果確認訂單的事件成功后，就可以提交訂單或者若顧客改變主意，不想購買圖書, 則交給虛擬購物車進行管理。1.3 擴充點無1.4 事件流登陸系統(tǒng)，顧客先以普通顧客的身份查找所需要購買的圖書并添加到購物車，此時 用例確認訂單開始、系統(tǒng)提示顧客所想要選擇的動作：購買、不購買、稍后再買。如果所選的活動是購買，執(zhí)行分支流 S-1 :購買所需要的圖書。如果所選的活動是不買，執(zhí)行分支流S-2 :不夠買該書但保留 其信息。如果所選的活動是稍后購買，執(zhí)行分支流 S-3:稍后再購買該書，保

8、留其信息等待 購買。S-1購買系統(tǒng)提示是否購買該書，顧客選中購買，并選中要購買的書名及購買的數(shù)量（E-1或E-2）,系統(tǒng)顯示信息可以購買，并建立購買連接。S-2不購買系統(tǒng)提示是否購買該書，顧客選中不購買，此時系統(tǒng)將保存該書的記錄并不作任何 處理。S-3稍后購買系統(tǒng)提示是否購買該書，顧客選中稍后購買，此時系統(tǒng)將保留該書信息并等待顧客 購買。E-1如果所選的書該書店沒有存貨，系統(tǒng)提示該書缺貨無法購買，顧客可選擇其他書進 行購買；E-2如果所選的書數(shù)量超過該書店的所擁有的數(shù)量，則系統(tǒng)提示書的數(shù)量過多無法購買，并提示可選擇少量進行購買。五、分析與討論1 .建模用例圖的步驟、方法？2 .尋找參與者尋找參

9、與者所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進行交互的人或其他系統(tǒng)。3 .確定用例找到參與者之后，我們就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各參與者需 要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。4 .描述用例規(guī)約應(yīng)該避免這樣一種誤解一一認為由參與者和用例構(gòu)成的用例圖就是用例模型，用例圖 只是在總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們對于系統(tǒng)的功能有一個總體 的認識。除此之外，我們還需要描述每一個有例的詳細信息， 這些信息包含在用例規(guī)約 中，用例模型是由用例圖和每一個用例的詳細描述一一用例規(guī)約所組成的.5 .檢查用例模型用例模型完成之后，可以對用例模型進行檢查，看看是否有

10、遺漏或錯誤之處。6 .如何識別系統(tǒng)的參與者？?誰是系統(tǒng)的主要用戶?誰向系統(tǒng)提供信息?誰改變系統(tǒng)的數(shù)據(jù)?誰從系統(tǒng)獲取信息?誰需要系統(tǒng)的支持以完成日常工作任務(wù)?誰負責日常維護、管理并保證系統(tǒng)正常運行?系統(tǒng)需要操縱那些硬設(shè)備?系統(tǒng)需要和那些外部系統(tǒng)交互?誰（或什么）對系統(tǒng)運行產(chǎn)生的結(jié)果（值）感興趣?時間、氣溫等內(nèi)部外部條件7 .應(yīng)該如何劃分用例，應(yīng)注意哪些問題？8 .1、使用功能點劃分，細化每個功能點，到這個功能點不能再拆分。9 .2、所要測試模快對該系統(tǒng)的整體影響?？雌渲匾浴?0 3、最好在用例編寫前，項目的測試工程師可以討論出一個適合項目的統(tǒng)一測試粒度。_5_*、，、一、4 .應(yīng)汪忠：1、測試

11、粒度不宜過細，測試用例分解的測試粒度過細會給測試工程師帶來成倍的 額外工作量，對于項目管理來講，這樣是不合算的。2、測試粒度不宜過粗，這是因為如果一個測試用例，里面包含了太多驗證點。比如在寫取錢的用例時，要檢查余額查詢，用戶最大額度查詢類似的本可以單獨一個用例 的東西都硬拼到了一起，那么用例的執(zhí)行進度和項目的進度肯定不能劃等號。簡單說就是有的用例簡單有的用例復(fù)雜，所以有的也許要驗證半天，有的只需要10分鐘。這樣的話，文章開頭的等式就當然不相等了。粒度過粗還有個麻煩就是，發(fā)現(xiàn)很多 bug都對應(yīng)著一個用例。這樣給缺陷管理和 統(tǒng)計起來也帶來麻煩。在項目后期的報告中不能清晰的統(tǒng)計缺陷。4.心得我認為，

12、用例就是功能，用例圖就是對功能的圖示描述；也就是功能模塊的表示。同時用例圖是對用戶的需求進行描述， 所以，從用例圖中能看出現(xiàn)實的功能需求， 貌似 是對現(xiàn)實世界想要完成某件事情的物理結(jié)構(gòu)進行畫圖表示。用例圖的粒度是第一次聽 說，經(jīng)過老師的講解，感覺粒度就是個數(shù)的意思，搞不懂為什么翻譯為粒度 (granularity )。也就是一個軟件劃分為多少個模塊。這就涉及到模塊的耦合和內(nèi)聚了。模塊太少不能把用戶的需求功能描述清楚， 太多了，又過于冗雜，同樣不能把功能描述7清楚用例圖是開發(fā)一個軟件時用到的第一個圖，所以，UML用例圖畫好了，對后面的開發(fā)至關(guān)重要。用例圖就是對現(xiàn)實需求的第一步抽象， 把功能用圖表

13、述出來。在畫用例圖的時候就應(yīng)該把用各個用例之間的關(guān)系表達清楚。實驗二類圖一、實驗?zāi)康牧私忸悎D的基本用法；初步掌握 UM送圖的創(chuàng)建及其方法。二、實驗要求1、結(jié)合工具StartUML ,熟悉UML類圖的模型元素。2、建模網(wǎng)上書店類圖。三、實驗主要設(shè)備：臺式或筆記本計算機四、實驗內(nèi)容：創(chuàng)建類圖的步驟如下：(1)使用名詞識別法識別類。(2)建模類與類之間的關(guān)系。(3)為類圖中的關(guān)聯(lián)關(guān)系添加合適的角色名。(4)為已被封裝到類中的獨立功能建模類。(5)為類圖中的類添加必要的特性和操作。(6)迭代并細化該模型1 .識別類：(刪除以下樣式，填寫)顧客(普通顧客，會員)，書店工作人員，虛擬購物車，圖書(特價圖書

14、)2 .定義類：(刪除以下樣式，填寫)圖2.1定義類圖2.2完善后的類圖五、分析與討論1 .如何使用文本分析技術(shù)從問題陳述中識別對象和類?識別對象: 識別類：識別問題中的實體，實體的描述用名詞，名詞短語,名詞性代詞的形式出現(xiàn)。分別找出：邊界類：邊界類處理系統(tǒng)環(huán)境與系統(tǒng)內(nèi)部之間的通信，邊界類為用戶或另一個系統(tǒng)(即參與者)提供了接口。實體類：實體類是模擬必須被存儲的信息和其關(guān)聯(lián)行為的類。控制類：控制類是用來為特定于一個或多個用例的控制行為建模的類。參數(shù)類：參數(shù)類又被稱為模板類(Template Classes ),模板類定義了類族。2 .心得通過本次實驗，我對類圖有了新的認識，類圖 (Class

15、diagram)是顯示了模型的靜態(tài)結(jié)構(gòu)，特別是模型中存在的類、類的內(nèi)部結(jié)構(gòu)以及它們與其他類的關(guān)系等。 類圖(Class diagram)是最常用的UML圖，顯示出類、接口以及它們之間的靜態(tài)結(jié)構(gòu)和關(guān)系，它 用于描述系統(tǒng)的結(jié)構(gòu)化設(shè)計。類的UML表示是一個長方形，垂直地分為三個區(qū)。畫類圖時，首先要從問題中出所有的名詞，再從中選擇出可以作為類的名詞作為候 選類，然后找分別邊界類、實體類和控制類初步定出類的概念層， 然后找出這些類的屬 性和操作最終確定出分析層，進而完善成完整的類圖。實驗三順序圖及通信圖、實驗?zāi)康某醪秸莆誙ML順序圖的建模及其思想、實驗要求1、結(jié)合工具StartUML和Rose ,熟悉U

16、ML順序圖的模型元素102、建模網(wǎng)上書店交互圖。三、實驗主要設(shè)備：臺式或筆記本計算機四、實驗內(nèi)容：1,給出網(wǎng)上書店的一個用例的順序圖， 例如，書店管理員登錄順序圖、會員添加圖書 到購物車順序圖或其他用例的順序圖。（順序圖）2,把以上順序圖轉(zhuǎn)換為通信圖。（通信圖）五、分析與討論1.如何從用例圖建模順序圖？從用例圖中選擇一個具體的用例，對這個用例的每個操作用順序圖具體的劃分出來2,順序圖和通信圖的比較？順序圖和通信圖都屬于交互圖。這兩種圖之間的區(qū)別在于：順序圖基于時間，按時間順序顯示出現(xiàn)的任務(wù)；而通信圖顯 示任務(wù)和信息（對象）的交互方式。在通信中，時間以編碼形式顯示，很難選取。雖然存在這些根本區(qū)別

17、，但這兩類圖有相同之處：都用于顯示對象和用戶如何交互以執(zhí) 行任務(wù)。3.心得通過本次試實驗，我知道了用例圖和通信圖以不同的方式表達了類似的信息，順序圖強調(diào)消息的時間順序，適合與描述實時系統(tǒng)和復(fù)雜的腳本； 通信圖則描述了對象之間11 的關(guān)系。這兩個圖用于為系統(tǒng)動態(tài)方面的建模，同時，通過對 StarUML軟件的學習讓 我對這點理解更加深刻。這兩種圖之間的區(qū)別在于：順序圖基于時間，按時間順序顯示出現(xiàn)的任務(wù)；而通信 圖顯示任務(wù)和信息。寸象）的交互方式。在通信中，時間以編碼形式顯示，很難選取。雖 然存在這些根本區(qū)別，但這兩類圖有相同之處：都用于顯示對象和用戶如何交互以執(zhí)行 任務(wù)。另外，我認為，首先根據(jù)自己

18、的喜好和實際的表現(xiàn)需要來選擇順序圖或通信圖。不過由于它們在語義上是等價的，因此可以繪制出一種，再通過建模工具來自動轉(zhuǎn)換成 另一種圖，分析模型中的交互圖徹重于分析類的職責分配和交互流程， 而設(shè)計模型中的 交互圖則徹重于設(shè)計類的引入和實際方法的調(diào)用與流程控制，先確定參與交互的對象、對象之間的關(guān)系（通信圖），然后確定對象間的消息交互流程 （用同步調(diào)用、異步消息、 返回消息表示），并利用交互片斷（順序圖）或迭代標記及監(jiān)護條件來表示循環(huán)和分支 結(jié)構(gòu)實驗四 活動圖、狀態(tài)圖及部署圖一、實驗?zāi)康?. 了解活動圖、狀態(tài)圖及部署圖的基本用法；2,初步掌握活動圖、狀態(tài)圖及部署圖建模方法。二、實驗要求1、結(jié)合工具StartUML ,熟悉UML活動圖、狀態(tài)圖及部署圖的基本模型元素。2、建模網(wǎng)上書店的活動圖、狀態(tài)圖及部署圖。三、實驗主要設(shè)備：