實驗報告
姓名：陶麗婷
專業：電腦科學與技術
學號：129074019
指導老師：胡增濤
2023年5月
[ 實驗目的] ·掌握客戶需求分析的方法和步驟
·了解以用例驅動的軟體開發方法
·識別並編寫用例
·掌握用rose 進行用例建模的具體方法和步驟
[ 實驗內容] 要求學生根據周圍的實際情況，自選乙個小型應用專案，分析業務需求，識別並編寫用例、繪製用例圖以理解系統需求。亦可採用教師指定的「企業綜合資訊管理系統」中的「進銷存管理子系統」
[ 實驗原理和步驟] 建模原理：
(1) 需求獲取。以任務和客戶為中心，通過會議、面談等手段對客戶需求進行調研，獲得系統目標、範圍和功能要求的初步說明。
(2) 用例分析。確定用例，同時採用分層思想，對用例的層次級別進行劃分（高層用例、子系統級、使用者目標級）
（3）用例描述。分層繪製用例圖，撰寫用例的文字描述（採用單欄格式）。
步驟：（1）需求獲取。自選題目，與相關客戶、領域專家等反覆商討，獲得系統目標、範圍和功能要求的初步說明。
（也可採用教師指定的題目：「企業綜合資訊管理系統」中的「進銷存管理子系統」，但要仔細研讀「企業現狀」、「系統目標、範圍和功能要求」等文字說明）。
（2）用例分析。確定系統範圍和邊界、確定參與者、確定用例。
（3）用例描述。分層繪製用例圖、描述用例。
畫圖原理：
採用rose 軟體進行用例建模必須建立在完好的系統用例分析基礎之上．只有做好系統用例分析，系統用例建模才能這到預期的效果。
步驟：（1）分層繪製用例圖，每層採用「包」進行管理。
（2）以「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「銷售管理」 -> 「合同管理」 ->「收款單處理」為主線，完成附錄2 中的操作過程（亦可選擇「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「庫存管理」 -> 「原材料出庫」 ->「領料單處理」主線）
[ 實驗結果
[ 實驗總結]
（1）層用例圖之間相互關聯，對用例圖畫法和建立要清楚的熟悉操作資訊流程，否則很容易搞混；
（2） 用例圖的畫法步驟不是很熟悉，對工具的使用陌生，不能正確的畫出和表達用例，缺乏實踐；
（3）了解了各層用例之間的關係，以及用例圖的畫法，熟悉了工具的使用，對以後的實驗幫助很大。
[ 實驗目的]
(1) 理解物件導向系統分析和物件類建模(概念建模)的概念
(2)了解和掌握物件導向系統分析的方法和步驟
(3)了解和掌握尋找待開發系統中類(概念)的方法和技巧
(4) 掌握使用rose 繪製概念模型的方法
[ 實驗內容]
在用例分析的基礎上，選擇第乙個迭代週期打算開發的用例，建立相關的概念模型。
[ 實驗原理和步驟]
建模原理：
(1) 使用概念目錄列表（見下圖）和非正式分析法（識別出問題域的文字描述中的名詞短語，然後將其作為概念或屬性的候選物件。）相結合的方法識別概念。因此，待開發用例的文字描述中，名詞可能成為概念或屬性的候選物件；表示行為的動詞片語有可能成為事務型或過程型物件；形容詞片語有可能對應抽象的名詞型概念。
採用的技術基本上就是：er 圖+純行為+oo 的聚合、泛化。
（2）最終關聯的數量介於「需要知道」型關聯與【「需要知道」型關聯+「需要理解」型（從通用關聯列表中派生出
的，見下圖）】之間。
步驟：（1） 識別關鍵用例作為第乙個迭代週期的開發目標（一般是在用例圖中被依賴得比較多的用例）。可以選「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「庫存管理」 -> 「原材料出庫」 ->「領料單處理」主線中的「領料單處理」用例；也可以選「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「銷售管理」 -> 「合同管理」 ->「收款單處理」主線中的「增加銷售合同」或「收款單處理」用例。
（其實，選「庫存管理」主線更合適；當然，如果要實現產銷一體化，以銷售訂單指導生產和採購，並實現零庫存目標，那麼一切工作就以銷售管理為中心。即便如此，首選「增加合同」用例也更為合適。）
（2）識別概念和重要屬性。
（3）建立概念間的關聯。
畫圖原理：
（1） 可以採用「邏輯檢視」下的類圖描述概念模型，只不過每個類中只有類名和屬性，沒有方法。在概念建模
階段也沒有必要確定屬性的型別和訪問屬性。
（2） 概念間的關聯可以採用一般關聯（無方向實線），當然，對於聚合和泛化，應採用相應的連線（組合：實心菱形+實線；聚合：空心菱形+實線；泛化：空三角形+實線）
步驟：（0）前提條件：第乙個迭代週期可以選「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「庫存管理」 ->「原材料出庫」 ->「領料單處理」主線中的「領料單處理」用例；也可以選「企業綜合資訊管理系統」 ->「進銷存管理」子系統-> 「銷售管理」 -> 「合同管理」 ->「收款單處理」主線中的「增加銷售合同」或「收款單處理」用例。
做好與此用例相關的概念模型
（1）建立相關的概念模型的基礎上，在「邏輯檢視」下的類圖中描述概念模型，可以直接在類圖main 中繪製，也可採用類似用例圖中用過的分包機制
(2）繪製概念和重要屬性。
（3）繪製概念間的關聯。
[ 實驗結果]
[ 實驗總結]
（1） 實驗中類圖的畫法對程式的編制很重要，各類之間的關係對以後程式中的類繼承和多型有指導意義；
（2） 對類圖的不了解，以及不知道如何去辨別分析類與類之間的關係，在者還是開發工具不是很熟悉，缺乏實踐動手能力；
（3） 進一步了解uml分析建模的流程和重要性，對以後從事工作有很大幫助，看懂了類圖和用例圖對以後程式設計有重要作用。
[ 實驗目的]
(1) 理解順序圖的基本概念
（2）了解和掌握軟體工程中用例邏輯時序的分析方法
（3）掌握使用rose 建立順序圖的方法
[ 實驗內容]
在用例模型和概念模型的基礎上，對首選的用例進行事件分解，識別出系統事件（系統操作），（並寫出契約的後置條件）；為每個系統事件畫順序圖，為物件分配職責。
[ 實驗原理和步驟]
原理：(1) 在系統順序圖中，所有的系統都被當成黑盒子看待，順序圖的重點是參與者發起的跨越系統邊界的事件。
(2) 系統事件是由某參與者發起的指向系統的輸入事件。乙個事件的發生能夠觸發乙個響應操作的執行。
(3) 請仔細研究下圖,考察它是如何從左邊的"購買商品"用例的文字描述中分解出3 個系統事件的。
（4）參照用例模型和概念模型，為每個系統操作估計後置條件。（例項建立、形成關聯、屬性修改）
（5）按照設計模式為物件分配職責。
步驟：（1） 分析首選用例的文字描述，按事件進行分解，識別出系統事件。（下面以「企業綜合資訊管理系統」 -> 「進銷存管理」子系統-> 「銷售管理」 -> 「合同管理」 ->「收款單處理」主線中的「收款單處理」用例為例）。
我們暫不考慮批處理。第乙個核對，因為要將「貨款金額填寫到合同中」。後置條件顯然有「銷售合同」的屬性修改。
此合同顯然已經存在，不需要建立，但需要根據合同編號find，然後形成關聯。第二個核對需要根據合同明細到倉庫的「存貨明細」（概念模型中還沒有）中去查。此核對發生前雖然敲了一下鍵盤，但隨後並沒有新的訊息穿越系統邊界，因此這仍然是同乙個系統事件。
先考慮成功場景，應該向庫存系統發提貨單（概念模型中還沒有）就結束了。後續的削減庫存（核銷）、預警顯然不是銷售管理員的職權，並且真正的核銷必須由倉庫的發貨人執行，才能保證貨帳一致。並且「生產廠家」與「郵購公司」的運作方式不同，後者是自己的員工取貨並郵寄，而前者還有可能是來人來車取貨，這時倉庫收到取貨單後並不能立即自動處理（開發貨單），必須等取貨人到達才能處理。
根據題意，本專案應該是「生產廠家」模式。這又存在乙個問題，如果在開出提貨單後不修改庫存，可能影響併發使用者和後續付款單的處理。所以有必要設計乙個「臨時存貨明細」（概念模型中還沒有）（不是真實的「存貨明細」）供修改，何時按存貨明細」進行重新整理應該是庫存管理系統的事（比如每天夜裡重新整理，但因為雨雪天氣，取貨
人遲遲不提貨，是提貨單作廢（相當於退回銷售系統，付款單變為未處理）還是就強行重新整理（此時有衝突危險）？）失敗場景。向「生產排程部門」傳送「產品生產申請單」。
如果是專門為此單進行生產，那麼還應該有庫存系統發來的「產品入庫通知處理」用例來呼叫本用例進行發貨。本題顯然一概根據付款單運作，因此如果失敗，就不處
理付款單，但按日期把它排在待處理付款單的前面。從前面的分析來看，就乙個系統事件，我們就命名為「付款單處理(pb:付款單)」
（2） 為每個系統事件估計後置條件。(以上已做了部分分析)
（3） 按設計模式進行設計。
首先考慮控制者,領域控制者選參與者角色，即「銷售人員」。為了避免使用form,視窗等表示層物件,我們人造一
個類」應用協調者」向控制者傳送訊息。
[ 實驗結果]
[ 實驗總結]
（1） 對重點實驗結果進行分析，了解順序圖的建立步驟和方法，並結合案例，分析事件的發生時序，使人一目了然；
（2）實驗中的問題和提高：對自己的分析或設計進行評價，指出合理和不足之處，提出改進的方案。
（3）收穫與體會：學會了順序圖的建立方法，重點是其中事件發生的時序順序，清楚表達用例。
[ 實驗目的]
(1)理解物件導向類之間關聯關係的概念
(2)了解和掌握分析類之間的關聯關係的方法
(3)了解和掌握待開發系統中類之間關聯關係的分析方法
(4)完善設計類圖，掌握使用rose 對關聯進行建模的過程
[ 實驗內容]
根據設計建模（1）中的互動分析，進一步設計關聯和物件可見性（補上遺漏的關聯）,完善設計類圖。
[ 實驗原理和步驟]
建模原理：
（1）關聯關係描繪了給定類的物件個體之間的語義連線，是類與類之間的連線。關聯可以分為一般關聯、聚合關
聯、組合關聯和依賴關聯等。
（2）一般關聯包括一對類的二元關聯及多個類之間的多元關聯。
（3）聚合(aggregation)表示整體和部分之間較強的關聯關係，聚合關係的多重性大於1，則稱為共享聚合。
uml實驗報告
本科實驗報告 課程名稱 計算機網路 實驗專案 計算機網路 實驗地點 逸夫樓404 專業班級 軟體1319班學號 2013005655 學生姓名 張衛東 指導教師 柴晶 1.實驗準備 熟悉uml建模環境 2.實驗一用例圖 3.實驗二類圖 4.實驗三順序圖及通訊圖 5.實驗四活 狀態圖 元件圖及部署圖 ...
uml實驗報告
uml及其建模工具 實驗報告 實驗二 班級 電子商務09 2班 姓名 沈萬琴 學號 20095056 時間 2012 04 02 1.實驗目的 通過分析設計 圖書管理系統 並使用visio繪製 圖書管理系統 的設計建模圖，熟悉 圖書管理系統 的設計思路，理解利用uml進行資訊系統建模的一般原理，掌握...
uml實驗報告
桂林理工大學博文管理學院 uml實驗報告 專業 電腦科學與技術 班級 計算機08 1 班 學號 80806122 姓名 張琦 指導老師 羅培中 一 圖書管理系統 1 圖書管理系統用例分析 要開發乙個軟體系統，首先要對軟體系統的需求進行分析，要做的工作是深入描述目標系統的功能和效能，確定軟體設計的限制...