1、.課程設計課程名稱題目名稱UML 系統建模采購管理系統.專業班級學生姓名學號指導教師二零一八年六月十五日.目錄一 問題描述1二 用例模型11. 收集供應貨物客商的信息22. 制定原材料采購計劃33. 簽訂采購合同34. 監督合同執行4三 靜態建模51. 問題域的靜態建模52. 實體類的靜態建模53. 供貨商供貨的活動圖84. 采購方購買的活動圖85. 采購方付款驗收的活動圖96. 商品檢查活動圖9四 創建動態模型101. 系統的通信圖102. 系統的順序圖113. 系統的狀態圖12五 設計總結14六 參考文獻15.一問題描述采購管理通過收集歷年來接觸到的供應商的基本信息建立數據庫。 可以對供應

2、商信息進行增加、 修改、刪除和查詢。每個供應商可以供貨多種產品，每個產品也可以由多個供應商供貨。 根據銷售管理部門提供的銷售計劃和庫存管理部門提供的“原材料（或零部件）庫存清單，來制定月、季度和全年的采購計劃。 采購計劃上報主管經理批準后， 分送庫存管理部門準備存儲空間，送財務管理部門準備流動資金。根據采購計劃和庫存管理提出的“超過庫存預警線的生產原材料（零部件）清單組織原材料的采購，與供貨商簽訂采購合同。合同簽訂后經主管經理簽字生效， 分送庫存管理部門準備存儲原材料（或零部件），送財務管理部門準備貨款。采購合同執行期間， 定期檢查合同履約情況。 督促供貨方及時發送貨物，通知倉庫一起對原材料進

3、行驗收入庫，通知財務部門案合同及時交付貨款。協同庫存管理部門按采購合同規定的產品名稱、規格、數量、來火時間，對采購的原材料進行驗收、 入庫。財務管理部門按采購合同及已收到的原材料的數量支付貨款給供應方。 采購合同涉及的原材料案合同全部到齊并驗收入庫，貨款也已經全部支付完畢，說明合同已經履約，執行完畢，設置履約標記，如果到期合同沒有履約，應注明違約方及違約原因。二用例模型用例在用例模型中描述。“采購管理系統”的用例模型中有三個參與者，分別是“供應方（”Supplier ）、“采購方（”Purchaser ）和“管理者（Manager ）”，三者都是系統的用戶。采購方可以查詢供應方的貨物信息、制定

4、采購計劃、簽定交易合同、監督合同的進展、貨物驗收、完成付款等。供應方可以對產品信息進行增加、修改、刪除和查詢、簽定交易合同、監督合同的進展、完成收款、檢查合同履約率等。管理者主要起督促的作用，監督發貨、督促付款、協同驗收貨物，三方都通過系統平臺輸入信息或者命令與系統交互。如圖1所示。.圖 11. 收集供應貨物客商的信息收集歷年來接觸到的供應商的基本信息建立數據庫。 可以對供應商信息進行增加、修改、刪除和查詢。每個供應商可以供貨多種產品，每個產品也可以由多個供應商供貨。用例名：收集信息概述：收集供應方客商的信息參與者： 采購管理部門前置條件： 需要進行采購主序列：步驟 1：收集歷年來接觸到的供應

5、商信息。步驟 2：根據收集到的信息建立數據庫。步驟 3：如果信息無需進行改動。步驟 4：提交數據庫。.可替換序列：步驟 1：如果信息需要增加，則用數據庫管理軟件進行信息插入。步驟 2：如果信息需要刪除，則用數據庫管理軟件進行信息刪除。步驟 3：如果信息需要修改，則用數據庫管理軟件進行信息修改。后置條件 ：已了解供貨商的信息。2. 制定原材料采購計劃根據銷售管理部門提供的銷售計劃和庫存管理部門提供的“原材料（或零部件）庫存清單，來制定月、季度和全年的采購計劃。采購計劃上報主管經理批準后， 分送庫存管理部門準備存儲空間，送財務管理部門準備流動資金。用例名：制定計劃概述：制定原材料采購計劃參與者：

6、采購管理部門前置條件： 根據計劃和清單需要進行采購主序列：步驟 1：銷售部和庫存部準備清單。步驟 2：根據清單建立采購計劃。步驟 3：按照采購計劃進行采購。可替換序列：步驟 2：如果庫存正常，則不會進行建立計劃。后置條件 ：采購命令已下達。3. 簽訂采購合同.根據采購計劃和庫存管理提出的“超過庫存預警線的生產原材料（零部件）清單組織原材料的采購，與供貨商簽訂采購合同。合同簽訂后經主管經理簽字生效，分送庫存管理部門準備存儲原材料（或零部件），送財務管理部門準備貨款。用例名：簽合同概述：簽訂采購合同參與者： 采購管理部門、供貨商前置條件： 采購方有計劃買、供貨商有貨賣主序列：步驟 1：采購管理部門

7、根據采購清單購買相應貨物。步驟 2：采購方確定合同。步驟 3：供貨商確認合同。可替換序列：步驟 2：如果不確定，則訂單取消。步驟 3：如果不確定，則訂單取消。后置條件 ：合同簽訂。4. 監督合同執行采購合同執行期間， 定期檢查合同履約情況。 督促供貨方及時發送貨物，通知倉庫一起對原材料進行驗收入庫， 通知財務部門案合同及時交付貨物款項。協同庫存管理部門按采購合同規定的產品名稱、 規格、數量、來火時間，對采購的原材料進行驗收、 入庫。財務管理部門按采購合同及已收到的原材料的數量支付貨款給供應方。 采購合同涉及的原材料案合同全部到齊并驗收入庫，貨款也已經全部支付完畢，說明合同已經履約，執行完畢，設

8、置履約標記，如果到期合同沒有履約，應注明違約方及違約原因。.用例名 ：審查概述：監督合同執行參與者 ：采購方、供貨方前置條件 ：采購合同執行期間主序列 ：步驟 1：檢查合同履約情況。步驟 2：如果供貨方按合同履約，那么執行3。步驟 3：采購方通知倉庫一起對商品進行驗收入庫。步驟 4：采購方按合同及時交付貨款。可替換序列 :步驟 1：如果供貨方沒有按合同按時發送貨物，那么督促供貨方發貨。步驟 2：如果供貨方按沒有按合同履約，那么按合同違約處理。步驟 3：如果按照合同上商品出問題，那么按合同違約處理。步驟 4：如果采購方沒有付款，那么按照合同違約處理。后置條件 ：供貨方以按合同按時發貨、采購方按時

9、付款。.三靜態建模1. 問題域的靜態建模我們做的是采購管理系統， 所以必定少不了一個能把采購方、供應方匯聚在一起的一個實體，也就是系統平臺。 供貨方在購物平臺上上貨， 進入被購買狀態。與此同時，采購方發現倉庫沒有貨物了，所以才去購買，于是和合同、審計發生了關系。圖 2.2. 實體類的靜態建模因為有兩種用戶，采購方和供貨方，所以我創建兩個對應的類。采購商品肯定少不了商品類和合同類。（1）供貨商類名：供貨商類的類型：該類用于辨別供貨商用戶的依據，供貨商用戶有自己的操作權限，并把其操作存入數據庫中。功能：用上貨、收款、驗收。屬性：公司名、地址、電話、介紹、信譽、供貨類型、郵編。操作：修改商品信息（）

10、、增加商品信息（）、刪除商品信息（）、查找商品信息（），確認合同（）、驗收合同（）。（2）采購商類名：采購商類的類型：該類用于辨別供采購用戶的依據，采購商用戶有自己的操作權限，并把其操作存入數據庫中。功能：購買、付款、驗收。屬性：公司名、地址、電話、郵編。操作：查詢商品（）、下單購買（）、確認合同（）、驗收合同（）。.（3）商品類名：商品類的類型：該類用于存儲商品信息。功能：存儲商品信息。屬性：商品名、數量、單位、價格、介紹、供貨方信息。操作：初始化商品（）。（4）合同類名：合同類的類型：該類用于管理購物。功能：存儲購物信息。屬性：商品名、采購方名稱、供貨方名稱、單位、數量、單位、數量、發貨時

11、間、到貨時間、付款時間。操作：初始化合同（）。（5）倉庫類名：倉庫類的類型：該類用于存儲商品。功能：存儲商品、提供已儲存貨物的信息。屬性：貨物名、貨物量、貨物信息介紹、商品本身操作：當有貨物不足時提醒采購方（）。.（6）審查類名：審計類的類型：該類用于維護購物的進行。功能：維護購物的進行。屬性：供貨方、采購方、貨物、倉庫、合同操作：判斷時間、判斷金額、判斷數量、判斷種類、合同確認。如類圖2圖 3:類圖 1.圖 3:類圖 23. 供貨商供貨的活動圖根據已經建立的用例圖和業務需求確定對象類，及其屬性和操作。通過檢查類的定義、分析問題的需求和運用該領域的知識來完善和確定類的屬性，根據系統功能要求和系

12、統設計需要完善和確定類的操作。.圖 54. 采購方購買的活動圖圖 65. 采購方付款驗收的活動圖.圖 76. 商品檢查活動圖圖 8四創建動態模型.1. 系統的通信圖通信圖是一種 UML 交互圖，它從動態的視角描繪了一組對象是怎樣通過對象間消息傳遞來進行相互交互。 在通信圖中， 對象之間的消息發送序列是由消息序列的編號來描述。 通信圖中的消息序列應該和用例中描述的參與者和系統之間的交互順序相對應。圖 9：供貨商信息錄入通信圖圖 10 ：采購方計劃通信圖.圖 11：簽訂合同通信圖2. 系統的順序圖對象之間的交互也可以用順序圖來表示， 順序圖按時間順序展示了對象之間的交互。一個順序圖展示了所有參與交

13、互的對象以及塔門之間的消息來往順序。順序圖也可以用來描述循環和迭代。.圖 11 ：供貨商信息錄入順序圖圖 12 ：采購方計劃順序圖圖 13：簽訂合同順序圖3. 系統的狀態圖狀態圖是一個誒的對象所有可能的生命歷程的模型。狀態機圖通過對類對象的生存周期建立模型來描述對象隨時間變化的動態行為，也可以用來描述用例、協作和方法的動態行為，它是展示狀態與狀態轉換的圖。.圖 14: 供貨商對商品信息操作的狀態圖圖 15: 采購方“購物”的狀態圖.五設計總結統一建模語言（ UML ，UnifiedModelingLanguage）是面向對象軟件的標準化建模語言。 UML 因其簡單、統一的特點，而且能表達軟件設

14、計中的動態和靜態信息，目前已成為可視化建模語言的工業標準。在軟件無線電系統的開發過程中，統一建模語言可以在整個設計周期中使用，幫助設計者縮短設計時間，減少改進的成本，使軟硬件分割最優。對于建模過程中遇到的問題通過上網查資料，詢問老師，和同學進行討論，得到了比較滿意的解決， 避免了自己眼高手低， 從實踐中發現自己的不足，并及時改正。采用該方法優于傳統的過程開發方式，能夠對整個開發過程提供靈活、一致、易讀的表達， 在很大程度上降低了軟件開發的風險性， 提高了軟件開發的質量。更讓我明白， UML 的知識是十分豐富的，我現在的認識還不夠，我將會在以后的學習中，不斷提高自己的 UML 知識，更好地讓 U

15、ML 為將來的編程設計服務。.六參考文獻1Alexander,C,1997,.TheTimelessWayofBuilding.New York:OxfordUniversity Press2Atkinson,C.,J.Bayer,O.Laitenberger,etal2002.Component-BasedProductLineEngineering with UML.Bost:Addision-Wesley3Buschmann,F.,R.Meunier,H.Rohnert,etal.1996.Pattern-OrientedSoftwareArchitecture:A systemof Patterns New York:Wiley4Coad,P.,andE.Yourdon.1991.Object-OrientedAnalysis.UpperSaddleRiver,NJ:Prentice Hall.5Gomaa,H.1986. ” SofrrwareDevelopmentofRealTimeSystems. ” Communications of the ACM 29(7):657 -668.6Kobryn,C.1999.” UML2001: