uml實驗報告

本科實驗報告

課程名稱：計算機網路

實驗專案：計算機網路

實驗地點：逸夫樓404

專業班級：軟體1319班學號：2013005655

學生姓名：張衛東

指導教師：柴晶

1. 實驗準備：熟悉uml建模環境

2. 實驗一用例圖

3. 實驗二類圖

4. 實驗三順序圖及通訊圖

5. 實驗四活**、狀態圖、元件圖及部署圖

實驗一用例圖

一、實驗目的

初步掌握uml用例圖的建立方法及其用例的描述。

二、實驗要求

1．結合工具startuml，熟悉uml用例圖的模型元素。

2．使用startuml工具建模網上書店系統的用例圖。

三、實驗主要裝置：台式或筆記本計算機

四、實驗內容：

根據下面給出的網上書店問題陳述，分析該系統總體需求，建模網上書店系統的用例圖並提供乙個主要用例的事件流文件。

網上書店陳述：

書店經理：我們原本是乙個傳統的實體書店，顧客要買書都是親自到書店裡來的，這樣挺不方便。面且隨著書店銷售圖書種類和數量的增加以及顧客的增長，尤其是大量顧客到書店選購圖書，使得書店場地不足，工作人員也很忙碌。

其實，還有一點就是，有不少人進入書店後並不買書，只是查詢一些資料。有的甚至會在這呆上很長的時間直到把書免費看完。這種行為，工作人員一般是不阻止的，結果最後這些被看過的書會因為有閱讀過的痕跡而影響銷售。

而且現在電子商務已經發展起來了，所以我們想到借助網路，讓顧客通過網上書店購買圖書。這樣我們書店可以省掉大量的場地維護和工作人員成本支出，同時計算機可以方便的檢索圖書資訊，讓顧客可以足不出戶以更優惠的**買到需要的書。

系統分析員：能談談您對網上書店的要求嗎?

書店經理：網上書店要能實現對外和對內的功能，對外是顧客能在網上書店訂購圖書，提交訂單。對內，書店工作人員能夠通過網上書店及時的看到這些訂單，並進行處理。

為了把書送到顧客手裡，我們已經聯絡了快遞公司，初步達成協議，由他們往返場客和書店之間把圖書送到顧客手裡。書店管理員受理訂單後，就會通知快遞公司送貨。當然，書店的圖書上架和下架也應該由網上書店完成了。

工作人員甲：實體店中，圖書是按照不同種類放置的，方便顧客挑選。網上書店的圖書也應該能夠按照這種模式分類顯示。

這樣，圖書的資訊和種類要由網上書店設定和管理。已有種類的新書或新種類的圖書上架，網上書店能夠儲存這些資訊。如果資訊輸入錯誤，能夠進行修改。

工作人員乙：另外書店會搞一些**，推出一些**圖書。以前這些**書的資訊，都是我們根據**活動整理出來，貼在書店的醒目位置。

**活動過後，**圖書會恢復原來的**。希望網上書店也能夠管理這些**圖書。

系統分析員：能談談平時買書的經過嗎?

顧客甲：一般都是先在書店裡看看圖書的簡要介紹，或者先找找看有沒有自己需要的書，有時是沒有目標的尋找，有時直奔一類圖書而去。找到我想買的書或者覺得看的書不錯，就會去櫃檯結帳。

工作人員丙：不過有時在結帳的時候，顧客會突然改變主意，不買一些書或者又回去挑選圖書了。

顧客甲：有時好像是這樣的。要是網上書店在結帳前能方便管理我所選購的圖書就好了，這樣通過計算機直接操作，就不用跑來跑去了。

系統分析員：可以使用虛擬的購物車。

工作人員丙：對，這樣在使用者確認購買前可自行管理選購的圖書，決定要不要購買還有的購買的數量。

系統分析員：顧客先使用虛擬的購物車選購管理圖書，然後提交訂單給書店處理，是這樣吧。

書店經理：沒錯，就這樣辦。另外最好顧客能夠留下自己的資訊，方便以後的購買。

顧客：你們可以實行會員制啊。就像我們在網上逛論壇一樣，會員才能發言，普通遊客只能看。這樣我們平時就在網上書店查查資料什麼的，只在購買圖書的時候才使用會員身份。

書店經理：嗯，這樣不僅可以保留你們的資訊，也可以保留購買記錄。

系統分析員：會員提交購買訂單後，書店打算如何收取或者說使用者怎麼付款?

書店經理：我們可以接受貨到付款，顧客也可以使用網上銀行、匯款等方式付款。

顧客：這樣我們就方便多了。對了那是不是付款前，我還多了一次「反悔」的機會啊。

書店經理：在我們書店沒有受理訂單之前，你們可以取消交易。不過受理後就不行了。

……通過幾次這樣的訪談（限於篇幅，在此並未列出所有訪談內容），可以獲得網上書店的需求資訊，確定系統範圍。網上書店是實現對實體書店內部圖書商品和顧客購買圖書的綜合管理系統。

1.　用例圖：

此處由學生填寫

2.確認訂單用例事件流

1.用例確認訂單的事件流

1.1前置條件

在用例確認訂單開始之前，用例登入該系統以及用例使用虛擬購物車必須完成。

1.2後置條件

如果確認訂單的事件成功後，就可以提交訂單或者若顧客改變主意，不想購買圖書，則交給虛擬購物車進行管理。

1.3擴充點

無1.4事件流

1.4.1基流

登陸系統，顧客先以普通顧客的身份查詢所需要購買的圖書並新增到購物車，此時用例確認訂單開始，系統提示顧客所想要選擇的動作：購買、不購買、稍後再買。

如果所選的活動是購買，執行分支流s-1：購買所需要的圖書。

如果所選的活動是不買，執行分支流s-2：不夠買該書但保留其資訊。

如果所選的活動是稍後購買，執行分支流s-3：稍後再購買該書，保留其資訊等待購買。

1.4.2分支流

s-1購買

系統提示是否購買該書，顧客選中購買，並選中要購買的書名及購買的數量（e-1或e-2)，系統顯示資訊可以購買，並建立購買連線。

s-2不購買

系統提示是否購買該書，顧客選中不購買，此時系統將儲存該書的記錄並不作任何處理。

s-3稍後購買

系統提示是否購買該書，顧客選中稍後購買，此時系統將保留該書資訊並等待顧客購買。

1.4.3替代流

e-1如果所選的書該書店沒有存貨，系統提示該書缺貨無法購買，顧客可選擇其他書進行購買；；

e-2如果所選的書數量超過該書店的所擁有的數量，則系統提示書的數量過多無法購買，並提示可選擇少量進行購買。

5、分析與討論

1.建模用例圖的步驟、方法？

1.尋找參與者尋找參與者

所謂的參與者是指所有存在於系統外部並與系統進行互動的人或其他系統。

2.確定用例

找到參與者之後，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什麼樣的服務，或者說參與者是如何使用系統的。

3.描述用例規約

應該避免這樣一種誤解――認為由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。除此之外，我們還需要描述每乙個有例的詳細資訊，這些資訊包含在用例規約中，用例模型是由用例圖和每乙個用例的詳細描述――用例規約所組成的.

4.檢查用例模型

用例模型完成之後，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。

2.如何識別系統的參與者？

誰是系統的主要使用者

誰向系統提供資訊

誰改變系統的資料

誰從系統獲取資訊

誰需要系統的支援以完成日常工作任務

誰負責日常維護、管理並保證系統正常執行

系統需要操縱那些硬裝置

系統需要和那些外部系統互動

誰（或什麼）對系統執行產生的結果（值）感興趣

時間、氣溫等內部外部條件

……3.應該如何劃分用例，應注意哪些問題？

1、使用功能點劃分，細化每個功能點，到這個功能點不能再拆分。

2、所要測試模快對該系統的整體影響。看其重要性。

3、最好在用例編寫前，專案的測試工程師可以討論出乙個適合專案的統一測試粒度。

應注意：

1、測試粒度不宜過細，測試用例分解的測試粒度過細會給測試工程師帶來成倍的額外工作量，對於專案管理來講，這樣是不合算的。

2、測試粒度不宜過粗，這是因為如果乙個測試用例，裡面包含了太多驗證點。比如在寫取錢的用例時，要檢查餘額查詢，使用者最大額度查詢類似的本可以單獨乙個用例的東西都硬拼到了一起，那麼用例的執行進度和專案的進度肯定不能劃等號。簡單說就是有的用例簡單有的用例複雜，所以有的也許要驗證半天，有的只需要10分鐘。

這樣的話，文章開頭的等式就當然不相等了。

粒度過粗還有個麻煩就是，發現很多bug都對應著乙個用例。這樣給缺陷管理和統計起來也帶來麻煩。在專案後期的報告中不能清晰的統計缺陷。

4.．心得

我認為，用例就是功能，用例圖就是對功能的圖示描述；也就是功能模組的表示。同時用例圖是對使用者的需求進行描述，所以，從用例圖中能看出現實的功能需求，貌似是對現實世界想要完成某件事情的物理結構進行畫圖表示。用例圖的粒度是第一次聽說，經過老師的講解，感覺粒度就是個數的意思，搞不懂為什麼翻譯為粒度（granularity）。

也就是乙個軟體劃分為多少個模組。這就涉及到模組的耦合和內聚了。模組太少不能把使用者的需求功能描述清楚，太多了，又過於冗雜，同樣不能把功能描述清楚。

用例圖是開發乙個軟體時用到的第乙個圖，所以，uml用例圖畫好了，對後面的開發至關重要。用例圖就是對現實需求的第一步抽象，把功能用圖表述出來。在畫用例圖的時候就應該把用各個用例之間的關係表達清楚。

uml實驗報告

uml實驗報告

UML實驗報告

uml實驗報告

相關推薦