農業公司果蔬批發信息管理系統的設計與實現

發布時間：2023-07-07 16:32

第 1 章緒論 1

1.1研究背景和意義 1

1.2國內外研究現狀 2

1.3研究內容與技術路線 3

1.3.1研究內容與目標 3

1.3.2技術路線 4

1.4論文組織結構 5

第 2 章農業公司果蔬批發信息管理系統開發技術介紹 7

2.1UML 7

2.1.1用例圖 7

2.1.2類圖 8

2.1.3時序圖 9

2.2Vue 9

2.3MyBatis 10

2.4jQuery AJAX 10

2.5本章小結 11

第 3 章農業公司果蔬批發信息管理系統分析 12

3.1可行性分析 12

3.1.1技術可行性 12

3.1.2管理可行性 12

3.1.3經濟可行性 13

3.2農業公司果蔬批發業務分析 13

3.2.1采購管理業務 13

3.2.2銷售定價管理 14

3.2.3產品銷售管理 15

3.2.4貨款回收管理 16

3.2.5產品售后業務 17

3.3系統功能需求分析 18

3.3.1系統管理 19

3.3.2基礎信息維護功能需求 20

3.3.3營銷管理功能需求 21

3.3.4采購管理功能需求 23

3.3.5產品質量管理功能需求 24

3.3.6數據統計功能需求 25

3.3.7客戶端功能需求 26

3.4非功能需求分析 27

3.5本章小結 28

第 4 章農業公司果蔬批發信息管理系統設計 29

4.1系統架構設計 29

4.2系統靜態結構設計 30

4.2.1系統管理功能類圖設計 30

4.2.2系統業務處理功能類圖設計 32

4.3數據庫設計 35

4.3.1數據庫概念設計 35

4.3.2數據庫邏輯結構設計 41

4.4系統時序圖建模 48

4.4.1系統管理功能時序圖設計 48

4.4.2出入庫管理和庫存盤點功能時序圖設計 49

4.4.3庫存預警功能時序圖設計 50

4.4.4公司客戶下單和員工訂單管理時序圖設計 51

4.4.5公司客戶售后申請和員工售后管理時序圖設計 52

4.5本章小結 53

第 5 章農業公司果蔬批發信息管理系統的實現 54

5.1系統管理功能的實現 54

5.2基礎信息管理功能的實現 55

5.3營銷管理功能的實現 57

5.3.1庫位管理功能實現 57

5.3.2庫存預警功能實現 59

5.3.3訂單管理功能實現 60

第 6 章系統測試 63

6.1測試意義及目標 63

6.2測試方法 63

6.3功能性測試 63

6.3.1系統管理功能測試 64

6.3.2基礎信息管理功能測試 64

6.3.3營銷管理功能測試 65

6.3.4財務管理功能測試 66

6.3.5經理審核功能測試 67

6.3.6客戶端功能測試 67

6.4測試結論 68

總結 68

參考文獻 69

致謝 70

第 1 章緒論

1.1 研究背景和意義

自改革開放后，我國農村扶貧政策和相關工作的開展從開拓階段上升到精準扶貧階段，農村貧困人口規模不斷縮減，扶貧發生率持續降低［1,2,3］。對于農業經濟領域的發展國家層面高度重視，從而提出了很多優惠支持政策來為農業發展助力，以推動我國農業領域邁上新的發展臺階。

（1978 年—1985 年）是我國改革開放初期，在這一階段，針對極端貧困地區，我國政府設立專項資金以支持當地的大農業發展，我國至此開始了廣義上的產業扶貧。（1986年—1993 年）是側重于工業領域的產業扶貧時期，這一時期我國提出側重于自我能力開發和經濟開發的扶貧原則，確立了包括林果業、生產性基礎設施、種養業、農產品加工等主要產業的扶貧理念。

《國家八七扶貧攻堅計劃》的發布標志著我國開啟了側重于打牢產業扶貧基礎（1994年—2000 年）的扶貧時期，在這一時期，我國針對貧困地區提出了多項稅收優惠與補貼、基礎設施建設等政策，以提高貧困地區社會發展水平。

《農村扶貧開發綱要（2001—2010 年）》中“積極推進農業產業化經營”等意味著我國開啟了培育式產業扶貧時期（2001 年—2010年），這一時期的扶貧重點是對貧困地區的經營模式、產業結構等進行優化調整。而《農村扶貧開發綱要（2011—2020 年）》則對產業扶貧的內涵、具體實踐等作出要求。

《中共中央國務院關于全面推進鄉村振興加快農業農村現代化的意見》于2021年 2月 21日公布，至此，鄉村建設被確立為社會主義現代化建設中的一項重要內容，全方位促進鄉村人才、產業、生態、文化等的振興，進一步激發農業產品供給、文化傳承、生態屏障價值，推動農村盡快實現現代化建設。

貴州省是農業大省，主要產業就是農業，當地政府積極牽頭推動當地鄉村振興戰略落地，讓農業企業化經營有了完備的制度環境。以農業企業化經營的方式在企業中引入農業生產，從而慢慢將農業由以往“家庭作坊”模式轉變為企業經營模式，讓農業生產水平實現跨越式提升，幫助農業增產、農民增收，促進農村和諧穩定。另外，在有力的市場環境中，農業生產也開始向著地域化、規范化、精準化、利潤化的集中型的方向發展［4］。貴州黔北富民現代農業科技有限公司即為當地農業企業化經營的表率。

貴州黔北富民現代農業科技有限公司成立于 2016 年，企業堅持綠色、生態發展觀，

積極建設綠色生產基地、全力開發綠色生產資料并開發綠色營銷體系，以建立包含種植采購、農產品深加工與社區配送批發的經營架構，形成獨具特色的“綠色生態產業鏈”，業務范圍非常豐富，囊括苗木、果林種植與銷售、水果加工與包裝、銷售等多項。公司

作為當地以“公司+基地+農戶”模式經營的鄉鎮農企，為當地特色農產品探索出一條獨特、光明的發展之路。公司現擁有員工120 多人，其中具有專業技術人員12人，擁有專業營銷人員15 余人，生產種植基地1080 畝。

信息技術是現代社會的核心生產力，該技術對于社會經濟的發展產生了深遠影響［5］。當前社會無論各政府部門或商業領域都非常重視信息技術的應用，通過信息技術的引入可以提高各單位、人員的工作效率并深化信息交互，基于信息技術的支持，可實現組織、個人工作效率的大幅提高［6,7］。當前來說，案例公司在蔬果批發環節有大量的工作依然采取傳統的手工記錄的方式，不僅工作效率非常低，還提高了工作復雜度和工作出錯的幾率，工作成本更高。考慮到這一點，企業可以引入信息化管理手段來優化其業務流程，幫助企業提高現有業務的工作效率和工作質量。基于信息化管理系統，企業各部門可以第一時間獲取到所需信息數據，很好地解決了因為信息誤差而出現的工作錯誤，基于信息化管理系統的支撐，各環節、各崗位可以大量、高效地處理相關業務信息，為企業在復雜的市場競爭中站穩腳跟提供重要支持。在應用信息化管理系統后，果蔬產品批發環節得到了全面監管，減少了不必要的運營支出的同時也提高了該項工作的開展效率，為企業果蔬農產品批發業務帶來了更大的利潤收益。實踐證實，信息化管理方式能夠很大程度上提高企業的運營效率［8］。所以，為維持企業果蔬農產品批發環節工作的高效進行，企業需要盡快開發、引入信息化管理系統。

本課題是針對貴州黔北富民農業科技有限公司批發業務進行研究，利用現代化互聯網技術，結合該企業果蔬農產品批發業務特征和需求可建立科學、完備的信息管理系統，所以本系統具有很強的實用性，基于信息管理系統可以高效、便捷地查詢該環節業務相關信息資料，基于現代化信息管理系統的支持可讓企業通過果蔬農產品批發環節獲取更多利潤收益。

1.2 國內外研究現狀

集基地生產管理、農產品售賣以及農業領域信息追溯等業務功能于一體的集成平臺被一家印度公司 CropIn 率先研究開發出來。該平臺使得農場主能夠通過科學高效的手段，采用多種方式來全方位地解決農業經營中的生產銷售管理問題［9］。該公司對農場、農作物展開科學管理，從而讓消費者能夠購買到綠色、健康的農產品。該公司的農場生產管理系統會通過監測合作農場（監測作物生長期間的種子、殺蟲劑、化肥的情況），讓農作物的生產、管理等工作可以得到非常科學的建議和指導。該平臺給每個農產品設置唯一的ID標識符號，通過這個符號在農產品在農場自生長到銷售全過程中實時追蹤農作物的生長、成熟收割、生產加工、運輸儲存、銷售等各個環節，讓消費者能夠購買到綠色、無公害的農產品。

在美國，Farmeron設計了以Web端為支撐的農產管理工具并搭建農業管理平臺。其于2011 年成功設計出農場管理工具，利用這一工具，農場主可以對各類農業生產信息進行歸納整合，并且可以根據農產主的需求出具農場檢測分析生產狀況報告，以使農場主農業生產計劃的制定有更加可靠的數據參考。

FarmLogs 是 2012 年在美國阿安伯市成立的。該公司研發的農業管理平臺是基于 SaaS 模式的云端管理開發，也就是意味著管理農場的平臺使用方式更為多樣，即可通過移動客戶端應用程序查看管理，又能通過網站頁面進行信息瀏覽，這充分體現了該平臺的人性化設計。中小農場主也可以利用這一系統來對農作物生產過程進行規劃、監管、分析等，公司可以出具農場地圖信息，讓農場主可以實時了解到農場天氣信息以及各類農作物的種植數據信息等，并且可以通過平臺獲取到農產品的市場價格信息。該系統的最大特點就是：基于移動終端，農戶可以將農場各項數據上傳、分析并查看分析結果，農場管理更為科學、方便，農戶不需要再在以往繁瑣、復雜的工作流程中浪費時間和精力［10］。

對比農業發展水平較高的西方國家來看，當前我國農業產業化發展水平也比較低，信息需求不大［11］。農業產業化需要進行產業規模的擴張，農業生產時根據市場情況而定的，從而一定會提高市場對信息的需求度，并且對信息獲取的效率也會有更高多大的要求。然而，提高信息交互的效率和便捷度需要進行引入相關技術，對于一些小體量、低效益的農業主體來說，他們無法在信息技術方面投入較多資金。信息技術的效用就通過其為農戶帶來的經濟效益進行評價。各個地區的農業生產水平、程度不一，農業種植生產應根據當地的實際情況開展，相應的，信息技術也是如此。但當下我國農業應用系統研發領域存在人才缺口較大的問題，系統開發效率低，現有的系統品類少，無法滿足農業生產銷售產業的信息技術應用需求，所以，當前我國需要針對農業生產和銷售業務開發實用、穩定的信息管理系統。

1.3研究內容與技術路線

1.3.1研究內容與目標

對于貴州黔北富民現代農業科技有限公司目前的手工業務處理，人工記賬，電話或面談方式向上級申請物料，產品出入庫審核等不規范，低效率的業務處理行為，根據當下的研究情況并參考相關文獻資料，在進行一系列調研與論證的前提下，對果蔬農產品批發管理信息系統的網絡建設及系統化相關問題進行分析歸納后，具體探究了這個管理系統的研究設計問題，從而開發出一個可進行庫存管理、營銷管理、批發與銷售管理等多項功能的系統。本系統的開發時在業務流程和需求的基礎上進行的，由此，前期工作是對貴州黔北富現代農業科技有限公司負責果蔬農產品批發管理的部門進行業務流程和工作需求的分析討論。系統目標的達成應以下列幾個方面的研究作支撐，即：需求分析、方案設計、核心技術方案、系統應用等，開發和應用過程是一步步遞進的。

果蔬農產品批發業務主要包括產品信息查詢、庫存管理、客戶批發管理以及財務核算等工作。客戶信息查詢、批發管理、批發退貨標準要求、供求信息發布等常用功能都需要能夠通過信息管理系統實現，該系統還需要結合企業后期業務發展方向提前預設一些功能，搭建起實用性強、使用便捷的平臺。

該系統具備以下目標：

(1)按時：進行需求分析，把握開發進度，要對各個環節的各項工作提出時間進度要求，保證能夠按時對系統進行測試。

(2)全面：所謂全面，即系統功能完備，在對系統進行分析的前提下，設定功能多樣、操作便捷的業務流程，為企業的全面管理提供有力支持。

(3)實用：主要強調的是便于操作，流程規范，對操作人員進行簡單培訓后期能夠快速上手，并且還要配備相應的操作手冊，以便在遇到問題時能夠及時解決。

(4)先進：系統開發所用的程序語言、工具、數據庫以及系統框架等都應與當下計算機系統以及語言平臺相契合，體現出前瞻性特點。有充裕的擴充空間，使用國際前沿技術來創建平臺，保證軟件系統在使用上較為穩定，有較長的生命周期。

(5)可靠：具體表現在安全性與穩定性層面，數據結構要科學合理，即便是高峰期也能夠讓用戶順暢地訪問系統，系統還需要考慮到保密性以及數據信息的備份、找回問題，系統要有一定的自我修復能力。

“果蔬批發信息管理系統”是需要以管理方科學、全面的管理作保障，這是企業管理方的計算機管理系統。要保證該項工作的順利推進才可以讓企業今后的信息化發展之路順利推進。

1.3.2技術路線

在進行研究后，制定了下圖1.1的研究技術路線。以下為此次研究的具體思路：首先對農產品為我國農業可持續發展產生的影響作歸納，之后具體分析、歸納和總結當下國內外在農業經營信息化管理方面進行的研究以及設計成果，從而確定了這一主題研究的目的和意義。在進行相關理論分析、案例研究并判斷系統的技術性問題后，接著對貴州黔北富民現代農業科技有限公司目前的果蔬批發業務進行分析并歸納匯總流程，然后對果蔬批發信息管理系統的功能需求進行了具體歸納。以需要實現的功能為前提考慮技術方面的可行性，開發設計了果蔬批發信息管理系統軟件。完成設計后，對系統的應用效果進行闡述并測試了系統各功能的穩定性。針對系統研究設計期間出現的各種問題，筆者進行回顧和反思并提出后續的研究方向。

圖 1.1 研究技術路線

1.4 論文組織結構

本論文總體包括七大章節，各章節主要的內容如下：第一章，緒論。首先對課題研究的背景及意義作介紹，其次通過研究調查本課題國內發展現狀，最后總結得到本次研究的內容目的以及總體采用的技術路線。

第二章，農業公司果蔬批發信息管理系統開發技術分析。主要介紹開發系統所運用的關鍵框架技術,包括前端框架Vue、面向對象建模UML語言、數據庫映射框架MyBatis 以及前后端 jQuery AJAX 異步跨域。

第三章,農業公司果蔬批發信息管理系統分析。為確定開發的可行性,首先對農業公司果蔬批發信息管理系統的可行性展開了分析,接著對貴州黔北富民現代農業科技有限公司目前圍繞果蔬批發展開進行的主要業務流程進行分析,進而對系統的各項功能進行用例設計。

第四章，農業公司果蔬批發信息管理系統設計。具體分析了案例公司果蔬批發信息管理平臺開發設計相關問題，比如系統架構、業務邏輯、數據庫等內容。

第五章，農業公司果蔬批發信息管理系統的實現。在前兩章內容的基礎上通過相關技術來實現系統設計，并對各功能相關核心代碼予以展示。

第六章，系統測試。具體有制定測試方案、測試用例與測試過程、測試效果等。

第七章，總結。對農業公司果蔬批發信息管理系統整個設計開發過程做出總結，并就下一階段對于升級優化該信息管理系統的研究做出展望。

第 2 章農業公司果蔬批發信息管理系統開發技術介紹

2.1UML

UML語言被用來在以針對對象方法的開發方式開發軟件時，在系統設計前對系統平臺應當實現的功能進行分析建模以及在具體的代碼編程工作開始的前一階段進行分析設計時展開系統的非動態的結構層次和動態的邏輯行為的建模。UML屬于面向對象建模語言,主要突出的是建立系統的模型與結構,而對編程語言和算法不作具體要求, 它與C、C++、JAVA等常規編程語言不同，屬于繪畫語言，使得設計人員通過繪制的方式制作軟件藍圖。

UML 是對相關通用的建模語言進行的定義，并進行圖形化的展示，便于建模者理解與應用Ml。UML對于一些興趣愛好者和普通人也非常適用，它非常清晰明確地體現系統的內在構造和外部活動。作為一個復雜度較低的建模機制，UML能夠幫助使用者基于現實情況或結合使用者的需求對系統進行圖形化展示，具體解釋說明了系統的非動態的屬性操作和業務處理邏輯的動態交互。簡單來說，UML就是一個模板，為構造系統提供極具價值的參考。

UML建模能夠將很多難以梳理的宏觀問題當中的細節放大并抽離［13］。UML建模的模型有很多種。此次研究中，在進行系統分析時，筆者是以用例圖的方式展開功能需求描述說明；在設計環節針對系統的靜態結構，以用類圖展開具體說明，通過時序圖來描述系統業務邏輯的動態行為。下面就將結合用例圖、類圖、時序圖展開說明。

2.1.1用例圖

用例圖(Use case diagrams)體現了以旁觀系統者的視角，以中立的態度看待系統，獲取的對系統的認知，著重強調的是系統的性質而并非系統的運行原理。通過用例模型可以回答兩個問題，一是通過系統完成了什么工作，二是軟件的服務對象是誰。

用例圖和情節深入交互［14］。情節指個人和系統互動的情況。角色是發動和該事件相關的人與事。角色扮演了人或對象的作用，它與用例建立起通訊聯系 communication association，詳見下圖2.1，將患者當作角色，用例就是預約掛號。

圖 2.1 用例圖示例

角色為人形圖標，用例以橢圓表示，連接二者之間的線即為用例。

用例圖即用例、角色，和二者間的聯系的集合。一個用例可被賦予多個角色。用例圖在系統的功能需求已經由分析人員設計定型的情況下出現了新的需求時需要再確定需求的情況下能產生極大的作用。并且使用用例圖能夠清晰地闡釋開發者和客戶二者間的聯系，此外使用用例圖還能生成測試用例。

2.1.2類圖

在面向對象系統建模中，類圖(ClassDiagram)非常重要且比較常見［15］。類圖是靜態的，也就是說顯示出能夠帶來的影響，但影響的時間不明確。通過類圖可以看出系統的靜態結構以及系統的復雜程度，因為類圖中包含多種類和其間關系。

UML 類的符號被劃分為類名，屬性，和操作這三塊方框：

圖 2.2 類

在UML類圖中，下列幾種關系最為常見:實現(Realization)，泛化(Generalization), 聚合(Aggregation)，關聯(Association)，依賴(Dependency)，組合(Composition)o 本文中，面向對象涉及階段類圖設計主要涉及泛化，關聯和依賴三類關系。

泛化關系：也叫繼承，表示共性和特性之間的關系。泛化關系中，父類的靜態數據和動態操作被子類所繼承。類圖中的泛化關系表示方法如下圖所示，線的箭頭指向被繼承者，即父類。如圖2.3所示，動物與大象是泛化關系，大象是一種更為具體的動物。

圖 2.3 泛化關系示例

關聯關系：體現的是擁有的關系，它能讓一個類了解另一個類性質與方法。關聯關系表示方法如下圖所示。圖中，一個老師指導教育多名學生，學生被多個老師傳授知識, 他們之間為雙向關聯。學生學習好幾門學科，一門課程可由多名學生學習，所以和課程是存在多對多的雙向關聯關系。

圖 2.4 關聯關系示例

依賴關系：體現的是使用與被使用。在類圖中依賴關系的表現形式參見下圖繪制方法。如圖 2.5，人對氧氣是依賴的，氧氣是被使用的對象，箭頭指向氧氣。

圖 2.5 依賴關系示例

2.1.3時序圖

對象消息交互的先后時間在時序圖中得到體現，在時序圖中，被強調的是時間順序［16］。其基本作用是將系統的功能需求以更為具體化精準化的形式呈現出來。另外，對于各個類的實例化對象的職責及其職責的內在原因等可以通過序列圖來進行有效描述。基于時序圖設計能夠對系統的業務邏輯展開梳理，讓后續編寫程序代碼更加高效。

圖 2.6 時序圖示例

如圖 2.6，水平方向排列對象，豎直方向排列消息，在各對象間，任務信息是水平傳遞的，豎直方向沿著時間順序排列。

2.2Vue

在進行本次信息管理系統開發時，用到了 Vue 框架來開發前端界面。

Vue.js這一框架屬于構建系統前端界面所用［17］。漸進式框架構Vue.js被用來搭建用戶界面。與別的重量級框架存在區別， Vue 是以自下向上增量開發形式進行設計，特別是對其核心庫視圖層予以重點關注。該框架學習起來比較容易，可以便捷地整合其它庫或已有項目。在實現視圖組件和數據與響應的捆綁過程中，Vue中復雜度較低的API 被使用來完成相關任務。

與和MVC模式存在區別，Vue屬于MVVM (Model-View-ViewModel)的設計模式, 該模式讓Vue能夠進行數據的雙向綁定［18］。其中View為數據映射層，Model封裝了界面行為， ViewModel 是一個實例化 Vue 對象。開發人員編寫數據映射層代碼，實現數據的持久化管理，實例化 Vue 可被用來同步數據映射層的方法修改行為，之后根據需要來對界面行為的數據進行修改，再利用Vue對象來更新數據映射層，由此實現自動同步。

基于Vue框架所具備的各項優點，進行農業公司果蔬批發信息管理系統的系統開發時用到了該框架來開發前端頁面，由此達到系統的前后端分離，讓兩端的系統開發獨立開來，并且兩項開發工作可同時進行，開發工作可以快速推進，軟件開發過程也更加靈活。

2.3MyBatis

本文采用 MyBatis 框架實現數據庫映射和存儲過程。

MyBatis基本作用是達成Java接口和普通Java類與數據庫記錄的映射,是當下非常常用的開源Java持久層框架，XML或注解在MyBatis進行配置過程中被用來作為技術支撐，而且使得JDBC被完全解除與手動配置參數的限制。MyBatis有三層功能架, 即：接口層、數據處理層和支持層。接口層的功能是讓外部用戶有接口可用，從而能夠操縱數據庫，在接到請求后立即調用相關數據處理層功能來處理數據。數據處理層是在接收到接口層的請求后，利用基礎支持層來操作數據庫，數據庫操作語言SQL對數據庫的訪問查詢等多種數據操作以及執行結果的解析情況均被包含在基礎支持層中。基礎支持層是支持數據處理層的功能實現，比如數據庫連接、事務、緩存、配置等各項處理工作。

2.4jQuery AJAX

AJAX的方法與函數均被完整地封裝在jQuery庫中［19］。在不對瀏覽器進行刷新的情況下獲取服務器中數據的高效率的數據訪問方法在AJAX中得到了實現。通過調用 AJAX方法，可以使遠程服務器上的文本數據、JSON參數、XML注解等數據被超文本傳輸協議HTTP中的兩種發送請求的方法，即請求獲取數據get方法和提交數據post 方法所獲取，并且這些數據會被直接加載到網頁中被選擇區域的對象元素。

AJAX即"Asynchronous Javascript And XML"，包含近七種語言，屬于一種語言粘合劑，該技術和服務端語言不相關，所有的動態網站都可使用。AJAX屬于無刷新的數據交互技術，其原理是：對服務器發出的請求以及服務器對此做出的響應工作由 Javascript方法所完成，在完成這項任務的同時，不會延遲對用戶顯示網頁，核心對象 XMLHTTPRequest負責完成其中最重要的請求和響應的解析工作。基于該對象，向服務器發送后臺數據，并經由服務器進行數據的請求和接收，頁面的狀態將不會被重新加載，就可以對數據進行更新，換言之，就是局部刷新的效果得到實現而不是整個頁面都被刷新。

所以，回復及時和在固定時間內被傳輸的最大資源數據數量得到最大利用的優勢通過AJAX方法得到體現I20】。當數據沒有在服務器中被檢索時，也不會影響用戶查看網頁并進行操作，因為AJAX方法實現了只有關鍵數據被發送到遠程服務器上的高效傳輸方法，應用程序具效率高、操作方便。本系統很多功能都涉及展示歷史的數據列表，當在歷史數據持續積累后，信息列表頁面數據記錄加載的越來越多，服務器負載大，因為 AJAX具備上述優勢，可以很好地應對系統運行中前后端數據傳輸問題，所以，在開發該系統是用到了 jQuery庫中的AJAX方法來達到異步跨域的效果。

2.5 本章小結

本章對系統建模語言UML作了基本介紹，通過前后端分離的形式，結合Vue框架來開發系統前端界面，基于Mybatis框架來達到對后臺數據的SQL查詢訪問以及存儲過程的數據庫映射。利用jQuery中提供的AJAX方法達成數據交互，讓客戶端和服務器實現異步通信。

第 3 章農業公司果蔬批發信息管理系統分析

這里的系統分析，主要是以客戶的產品需求為出發點而做出的綜合分析。在進行設計的時候，要求設計人員必須要站在使用者的立場，充分與他們溝通后從中提取有效的信息，這樣才能開發出對用戶足夠具有吸引力的好產品。

本章的主要內容是全面分析系統的可行性及需求。在一個系統被開發前，首先要對其可行性作出合理的分析，以此證明該系統在技術上能夠被支持且具有效用［21］。本章將從技術可行性、管理可行性和經濟可行性等角度進行論述分析，以此作為項目投資或者開發的參考，盡量減少損失的產生。

3.1可行性分析

可行性分析主要涉及的問題是某一項目中有什么，該項目應該如何發揮作用以及將會產生什么樣的效益和影響，這些問題的答案同樣也是決策者決策的根據［22］。從技術、經濟和管理出發的多角度可行性分析能夠為項目確定所需的各類資源；能夠為項目的實施提供技術選擇的參考；能夠了解項目產生的效益以及影響。在此基礎上形成的系統分析報告對于項目的實施而言具有科學的指導意義。本章將對上述的三個方面分別進行闡述分析。需求分析的主要內容則是在確定用戶需求的基礎上，對系統范圍和系統功能進行明確。

3.1.1技術可行性

一般而言，技術可行性的討論可以從硬件開發需求和軟件開發環境兩個角度入手，闡述如下［23］。

在硬件開發需求方面，由于科技的快速發展，當前的硬件條件發展水平差距并不大，再加上系統對其性能的要求不高，因此硬件上基本都能使系統的要求得到較好的滿足，局限性相對較小。

在軟件開發環境方面，本系統采用的是當前已經得到市場認可且被廣泛應用的 IntelliJIDEA,作為業界具有代表性的軟件開發工具，足以使系統的要求得到滿足，這讓信息管理系統的開發運行更具可操作性。

3.1.2管理可行性

本系統以面向對象方法作為基礎理論框架，因此具有高穩定性的特征。這為系統管理提供了良好的管理環境，管理人員可以在對管理可行性作出全面了解的基礎上，從而對系統管理的各方面進行完善，使管理的可行性得以實現。

3.1.3經濟可行性

經濟可行性的本質是系統開發運行后所得的實際收益要大于前期的投入成本［24］。衡量該系統是否具有經濟可行性以及可行性程度高低的標準是看其是否可以給當前的市場帶來實際的效益。根據市場的實際發展以及對以往經驗的參考，不難發現的是信息管理系統軟件的開發成本并不算高。首先是硬件上，臺式電腦作為當代公司運作最為重要的硬件設備之一，大部分公司都有配備，并不需要進行額外大規模的硬件設施采買；其次是人力成本上，系統一旦被開發成功，運用到公司實際生產經營之中，將比傳統的手工記賬更有效率，這樣就可以撤銷一些沒有必要的崗位，降低人力支出。當產品業務管理的水平得到提升之后，公司整體的效率也將隨之上升，從在市場競爭中得到更多的效益。

3.2 農業公司果蔬批發業務分析

就目前而言，本文研究的貴州黔北富民農業科技有限公司以果蔬批發為核心，并圍繞展開業務活動，包括產品采購、產品售前定價、產品銷售、貨款回收、售后服務等主要業務。

3.2.1采購管理業務

采購業務是批發果蔬的第一步，農業公司不僅要從其自生產基地獲取產品來源，還需通過采購的方式獲得貨源。公司在每次產品出庫之后均會盤點氣調庫中剩余的果蔬儲存量。由于生產基地中蔬果一旦成熟就必須采摘下來入庫恒溫保存，氣調庫中果蔬儲量一旦處于緊張狀態，即各品類儲量小于 100 斤，公司營銷部員工需及時安排人員與合作的果蔬批發供應商聯系采購產品補充庫存。農業公司由其長期合作的供貨商供給所需產品，再將產品整合入庫，以進行下一步業務操作。

在進行產品采購過程中，首先是由營銷部員工找好貨源，與供貨商進行談判，初次擬定合作協議。然后合作協議需要由財務部進行審批，財務若審批不通過，認為金額有誤，則營銷部再次進行談判直至通過交由經理過目審批簽字，從而確定正式合作協議。根據合作協議，若需預付款給供貨商，則營銷部提交財務部預付款額表，由財務審核金額數，最后交由經理簽字。然后財務安排打款，并通知供貨商發貨。若協定最終一次付清采購貸款，則營銷部直接通知供貨商發貨。收到產品后，營銷部需要進行質檢，質檢不合格的產品需進行退貨，對于合格的產品則按量計價付清采購貸款并安排產品入庫。若已預付款，則付尾款前由財務審核，經理簽字確認。采購業務流程圖如圖 3.1 所示。

圖 3.1 采購業務流程圖

3.2.2銷售定價管理

水果蔬菜這一類的產品，由于其生產運輸中的不確定性以及季節性消費需求的波動性，導致果蔬產品的銷售單價是不確定的，是隨著生產成本以及銷售市場波動的。因此，公司營銷部員工會定期進行市場調研，了解產品售價，在產品自生產基地摘取和采購產品整箱入庫后，需在產品售出前，結合市場信息以及生產成本對產品進行售前定價，提出價格方案，然后財務根據公司經營成本，計算售價的合理性，并交由經理審批，最終確定價格方案。銷售定價流程圖如圖3.2所示。

圖 3.2 銷售定價流程圖

3.2.3產品銷售管理產品銷售是公司經營的核心業務，也就是公司的批發業務。公司營銷部門是員工最多的部門，營銷部負責找客源，同批發市場、超市以及果蔬零售商推廣洽談果蔬產品，洽談成功便起草合作協議由財務與經理審核此次批發銷售訂單，然后與客戶敲定協議，并通知客戶預付貸款。財務部查收預付款后，通知營銷部備貨，并仔細檢查產品質量，質檢不合格則重新備貨，最后將合格的貨物發出給客戶，并由財務進行尾款結算催繳。產品銷售流程圖如圖 3.3 所示。

按照公司業務規定，除特殊情況外，經過公司經理確認，每筆交易一旦成立，客戶需打款至公司財務賬號交易合同金額總額的 65%預付款，財務查收款項后，通知營銷部員工安排產品出貨進行運送。

圖 3.3 產品銷售流程圖

3.2.4貨款回收管理

當公司將貨物發出后，客戶收到貨物且核對產品數量信息等，需交付貨款。公司在規定時間內未收到貨款，將整合信息，聯系客戶進行貨款催繳。貨款回收流程圖如圖 3.4 所示。

按照公司規定，產品出庫后有兩種配送方式，省外地區的客戶將使用第三方物流配送自客戶所在地，省內地區將由公司貨車自行配送。無論哪種配送方式，當產品配送到客戶所在地后10天內，是客戶自行支付剩余貨款的有效時間，當客戶確認收到貨物且無售后需求之日起10 天后，公司員工將組織人員聯系客戶進行貨款催繳。

圖 3.4 貨款回收流程圖

3.2.5產品售后業務由于水果蔬菜本身具有的易受損性，每次批發銷售出去的果蔬很難完好無損地送達客戶手中，尤其是距離較遠運輸時間長的省外地區的客戶。加上與客戶洽談確認交易后，通知備貨，質檢到果蔬產品出庫配送各個環節均由工作人員人為操作，其中某個環節由于溝通不到位等因素出現差錯就可能導致客戶收到的產品品類或數量與確認的交易信息不符。因此在公司營銷部員工將貨物發出后，客戶收到貨物核對檢查蔬菜水果是否存在磕破損壞情況并核對產品數量后，一經發現產品數量或者品類與交易訂單不符或者有損壞情況，可聯系公司申請售后。并且規定貨物送達后10 天內為售后有效期。

營銷部員工收到索賠申請后，首先組織此次發貨的相關員工分析出現的問題，并聯系客戶了解具體情況，進行協商，根據協商結果，營銷部擬定解決方案，交由經理審批，然后按照方案實施售后，最后聯系客戶問詢反饋評價，完成此次售后。營銷部需對售后進行復盤，總結經驗與教訓，并記錄存檔，交由經理審閱。產品售后流程圖如圖 3.5所示。

圖 3.5 產品售后流程圖

3.3系統功能需求分析

需求分析是通過形式化的分析方法和工具使得用戶對系統的口語通俗化的功能需求被轉化為符合程序開發的規范且完整的需求說明，其目的就是在于確定軟件設計與開發的具體任務［25］。需求分析主要包括系統開發的功能性需求以及非功能性需求分析。一般來說，需求分析要求開發者與用戶深入溝通，準確了解用戶對于系統功能及性能的要求，從而確立系統的模塊結構。在軟件開發的生命周期中，作為其中最重要的環節之一，需求分析使得開發人員更加清晰地意識到系統需要實現的是什么，明確系統開發的意義就是充分滿足用戶的使用需求。在這一階段不僅要考慮到系統的主要功能構造，還應分析系統在性能、可擴展性以及安全性等方面的需求。

在系統需求分析階段，必須完成的任務就是對系統功能進行需求分析，這也是需求分析中最困難的部分［26］。由于因為系統往往應用領域較廣，其中包含不同的業務處理并涉及不同的用戶類型，因此難以精準確定需求；在整個系統開發的過程中，系統的需求可能會隨著實際的業務變化或者制度改革等而發生變化；在軟件開發人員與用戶、專家等就需求進行溝通時，因角色、認知理解、知識背景等因素而難以達成共識。可以成功完成系統的功能需求分析就決定最終系統的開發順利實現。

農業公司果蔬批發信息管理系統是一整套供消費者、農業公司使用者應用使用的軟件系統，本文研究設計開發的整個系統主要針對貴州黔北富民現代農業科技有限公司的員工以及公司客戶。研究分析后該企業批發業務信息管理系統所涉及的角色包括管理員用戶、農業公司員工、產品批發客戶。其中農業公司員工用戶包括營銷部，財務部，總經理三類角色。系統功能主要包括營銷員維護系統基礎信息、營銷業務管理、管理采購以及管理產品質量；財務查看公司數據統計結果并審核售后和銷售訂單信息；總經理審批訂單與售后；公司客戶查看產品列表、管理個人訂單、提交售后申請服務，下文將就每個功能主題進行詳細的用例分析。

3.3.1系統管理

本文中，整個系統用戶包括三類角色，包括管理員用戶，公司員工用戶以及公司客戶用戶。其中管理員用戶是最高菜單權限使用者，管理員能查看并修改系統中包括基礎信息以及業務信息在內的所有數據，也就是說管理員可以對系統中的所有功能模塊進行一定操作。管理員管理用戶即可查看用戶信息，并添加使用系統的新用戶，當公司員工離職或客戶終止合作，便刪除對應的用戶信息。系統中所有用戶的賬號密碼均由管理員設置。管理員根據該公司的員工人員情況，以及該公司目前合作的客戶對員工和客戶類用戶的信息以及菜單定義進行管理。管理員系統管理功能用例圖如圖 3.6 所示。

表 3.1 “新增用戶”用例說明

用例名稱新增用戶

用例描述管理員增加系統用戶，設置用戶登錄系統的用戶名密碼

參與者管理員

前置條件管理員登錄系統

基本事件流 1、管理員進入維護用戶信息界面，選擇新增用戶；

2、管理員輸入新增用戶信息，包括用戶名，密碼，姓名，角色，手機號，郵箱等信息保存；

3、系統保存新用戶信息；

替代事件流 2a、管理員輸入用戶郵箱格式錯誤，保存失敗；

2b、管理員輸入用戶名已存在，保存失敗；

2c、管理員輸入確認密碼與密碼不一致，保存失敗；

后置條件新用戶的各項基本信息數據被成功寫入至數據庫，成功添加新用戶，返回用戶信息界面；

3.3.2基礎信息維護功能需求

為了實現農業公司果蔬批發信息管理系統的系統維護、系統升級和系統信息錄入等功能需求，必須實現基礎信息維護模塊的功能。基礎信息維護模塊功能主要為營銷部員工提供整個系統中客戶信息、員工信息、蔬菜水果產品信息及其所屬種類信息六大類信息的管理功能，即對客戶、員工、蔬菜的種類品類以及水果的種類品類屬性信息進行增刪改查操作。營銷部員工結合公司實際運營情況，通過該模塊，對相關基礎信息進行更新同步，進一步為其他業務處理功能模塊提供完整的數據依據。基礎信息維護功能用例圖如圖 3.7 所示。

圖 3.7 基礎信息維護用例圖

表 3.2 “批量刪除”用例描述

用例名稱批量刪除

用例描述營銷部員工多選信息記錄進行刪除（以員工信息為例）

主要參與者營銷部員工

前置條件營銷部員工進入維護員工信息界面

基本事件流 1、營銷部員工多選需刪除的員工信息記錄刪除；

2、系統數據庫刪除所選員工基本數據，維護員工信息界面不再呈現所選員工信息記錄

替代事件流無

后置條件蔬菜品類信息保存到數據庫蔬菜品類信息表或從數據庫表刪除成功，返回蔬菜品類列表界面。

3.3.3營銷管理功能需求

營銷管理模塊需求是實現農業公司果蔬批發信息管理系統的核心功能需求，是實現農業公司果蔬批發信息管理系統的基礎。營銷管理模塊主要包括營銷部員工查看市場調研信息記錄并根據實際調研情況選擇新增調研記錄。營銷部員工、經理、以及財務可查看客戶提交的產品需求訂單，結合實際審核通過訂單，且查看每筆訂單的合同信息。此

外，還有氣調庫管理功能、售后服務管理功能和加工管理功能，其中氣調庫管理部分需求包括庫位信息維護、入庫管理、出庫管理、盤庫管理、庫存預警和報廢申請等子功能；加工中心管理需求包括加工計劃管理、成品管理。營銷部調研員到市場進行實地考察后，將調研結果信息錄入系統備份，為產品的定價等提供數據支撐。營銷部負責與客戶洽談建立合作關系，并商議貨物批發的價格、配送方式等，客戶在系統提交產品需求單后，營銷部安排產品包裝出庫，每筆訂單均需備份相應合同。在產品出庫、庫存盤點的過程中均會產生報廢產品，工作人員需根據實際情況將產品報廢信息錄入系統備份。根據每次的庫存盤點，系統將在庫存預警模塊顯示庫存量處于緊張狀態的所有庫位，以便提示

營銷部進行產品采摘入庫或采購。營銷管理模塊的用例圖框圖如圖 3.8 所示：

圖 3.8 營銷管理用例圖

表 3.3 “審批客戶訂單”用例描述

用例名稱審批客戶訂單

用例描述營銷部員工、財務和經理對客戶提交的訂單信息進行審核

主要參與者營銷部員工、財務、經理

續表 3.3 “審批客戶訂單”用例描述

前置條件客戶在客戶端提交訂單

基本事件流 1、營銷部員工登錄系統，選擇查看客戶提交的訂單信息；

2、營銷部員工核對訂單金額數量信息無誤，則確認審核訂單；

3、系統保存營銷部員工已確認的訂單，在經理端訂單審核界面顯示該訂單，在客戶端同時更新訂單處理狀態；

4、經理查看訂單信息，確認無誤，審批通過訂單；

5、系統將經理審批通過的訂單在財務端界面進行顯示，并在客戶端同步更新訂單處理狀態；

6、財務產看訂單信息，確認金額數目無誤，則審核通過，選擇訂單打印該訂單票據；

7、系統在客戶端更新訂單處理狀態。

替代事件流無

后置條件各個參與者確認審核訂單成功，系統返回至訂單信息界面。

表 3.4 “（維護出庫信息）新增”用例描述

用例名稱（維護出庫信息）新增

用例描述營銷部員工在系統中記錄每次出庫的信息

主要參與者營銷部員工

前置條件客戶端客戶提交產品訂單

基本事件流 1、營銷部員工在界面輸入出庫信息，包括庫位號，訂單號，產品出庫量，出庫時間；

2、系統保存出庫信息到數據庫表，新增成功。

替代事件流 la、員工輸入產品出庫量與對應訂單中的出貨量不一致，新增失敗。

后置條件系統將產品出庫信息成功保存到數據庫表，返回到出庫信息界面。

3.3.4采購管理功能需求

當庫存不足時，營銷部根據庫存預警，需要及時采購產品。采購管理功能需求既是營銷部錄入每筆采購的信息，提供銷售統計的數據依據，也是為企業的經營成本提供數據依據，每筆采購單必須有對應的一份合同管理。采購管理用例圖如圖 3.9 所示。

表 3.5 “修改合同記錄”用例描述

用例名稱修改合同記錄

用例描述營銷部員工和財務在系統中修改每次采購的交易合同信息

主要參與者營銷部員工、財務

前置條件無

基本事件流 1、營銷部員工選擇增加合同記錄，輸入合同信息，包括合同金額，簽訂人，簽訂日期；

2、系統保存合同信息到數據庫，系統顯示營銷部員工修改后的采購合同記錄。

3、財務核對營銷部員工登記的采購合同金額，金額有誤，選擇修改合同信息；

4、系統保存合同修改信息到數據庫。系統顯示修改后的合同記錄。

替代事件流無

后置條件采購合同信息存入數據庫，修改成功返回上級界面。

3.3.5產品質量管理功能需求

產品質量管理功能是必不可少的功能需求，包括產品質量檢測的計劃管理以及檢測結果管理。營銷部員工使用產品質量管理功能，根據當次所檢產品，錄入檢測計劃安排，記錄每次質檢的詳細信息，并將最終檢測結果錄入系統。質量管理用例圖如圖 3.10 所示

圖 3.10 產品質量管理用例圖

表 3.6 “新增計劃”用例描述

用例名稱新增計劃

用例描述營銷部員工在系統中錄入產品質量檢測計劃

主要參與者營銷部員工

前置條件營銷部員工查看檢測計劃

基本事件流 1、營銷部員工在系統界面輸入檢測計劃信息，包括檢測員工姓名，檢測時間，檢測產品名稱，檢測數量；

2、系統保存檢測計劃信息至數據庫，提示新增計劃成功。

替代事件流 1a、輸入檢測員工姓名不存在，重新選擇檢測員姓名。

后置條件產品質量檢測計劃信息數據存入數據庫成功，返回檢測計劃信息界面。

3.3.6數據統計功能需求

數據統計是系統中重要功能涉及到的能體現企業生產經營狀況數據的統計，企業所有部門員工均可使用查看該功能，以了解當前銷售經營情況。數統計模塊為系統用戶展示歷史采購產品的金額統計、銷售金額以及銷售量的數據統計、產品入庫量以及出庫量

統計以及產品加工成品總量和加工原料使用量的數據統計，所有數據的統計結果以圖形方式呈現給用戶查看。每個用例僅提供圖形查看功能，所以不再展開用例說明。數據統計用例圖如圖 3.11 所示。

3.3.7客戶端功能需求

客戶端模塊是提供給消費者客戶使用的簡易在線下單模塊子系統。客戶使用此功能模塊在查看瀏覽產品的信息列表后可根據需求選擇產品進行下單，并在訂單管理功能查看訂單審核狀態以了解跟進訂單情況，并根據收到產品的情況進行售后申請索賠。客戶端模塊用例圖如圖 3.12 所示。

圖 3.12 客戶端用例圖

表 3.7 “下單”用例描述

用例名稱下單

用例描述客戶查看果蔬產品列表并進行下單

主要參與者客戶

前置條件客戶登錄系統查看產品列表

基本事件流 1、客戶選擇產品，在系統中輸入產品需求數量下單；

2、系統生成訂單信息，保存到數據庫，并將訂單信息在訂單界面進

行顯示

替代事件流 1a、客戶輸入的產品需求數量超過產品庫存量，下單失敗，重新輸入需求數量

后置條件客戶購買產品相關的信息數據成功寫入數據庫表中，系統返回產品列表頁面。

3.4 非功能需求分析

1）操作簡單

由于農業公司果蔬批發信息管理系統是供公司客戶、農業公司人員操作使用，而系統使用者由于文化水平和認知能力的差別，對于該系統的學習能力也存在個體差異，影響對系統的使用情況。為了使使用者能夠更快、更好地掌握農業公司果蔬批發信息管理系統的操作方法，在這一階段就系統操作流程簡介易懂提出了設計要求。一種操作簡單的系統可以縮短農業公司果蔬批發信息管理系統的使用培訓時間并極大降低使用人員操作失誤的可能性。因此，設計一種操作簡潔明了的農業公司果蔬批發信息管理系統具有非常重要的意義。

2）可靠性高農業公司果蔬批發信息管理系統需要在線處理客戶訂單、庫存出入庫記錄，并且采購與售后訂單的查詢審核等均為在線處理。因此農業公司果蔬批發信息管理系統需要保持長期的、穩定的可靠運行，即便用戶使用系統處理業務時出現運行故障也能迅速得到解決，恢復正常運行。因此，設計一種可靠性高的農業公司果蔬批發信息管理系統具有非常重要的意義。

3）安全性好農業公司果蔬批發信息管理系統的數據庫中存儲有客戶、農業公司員工的個人資料、各類訂單資料以及財務信息等隱私數據。農業公司果蔬批發信息管理系統在設計過程中必須嚴格考慮信息安全問題，通過設計周密的系統防護機制，從而確保系統信息資源不會被非法盜用。

4）可擴展性強農業公司果蔬批發信息管理系統在使用過程中，為了保證農業公司果蔬批發信息管理系統的可擴展性功能的升級使用，在設計農業公司果蔬批發信息管理系統的過程中需要預留可擴展功能的接口、數據庫操作接口等，為后續系統升級更新做好準備。

5）實用性強系統在設計中首先要考慮到實用性，即盡可能滿足客戶、農業公司員工提出的實際使用要求。在系統設計之前已經通過對研究主題的意義目的以及研究方法進行了具體的分析論述，明確了系統的功能需求，從公司業務處理的實際情況和需求出發，在滿足需求的前提下來實現操作簡單易懂、可靠性高、安全性好、可擴展性強的農業公司果蔬批發信息管理系統。

3.5 本章小結

本章主要對農業公司果蔬批發信息管理系統進行了可行性分析，論述了系統開發的可實施性，并結合貴州黔北富民現代農業科技有限公司目前的批發銷售相關的核心業務，具體分析了業務流程，從而進一步對系統的功能通過用例圖以及相關用例說明進行詳細的需求分析，具體闡述了系統應該實現的功能，并系統介紹了在非功能性上進行軟件開發時開發人員應考慮到的方面，通過明確非功能性的需求，可以提高接下來進行的系統設計和程序代碼編寫實現系統等工作效率。

第 4 章農業公司果蔬批發信息管理系統設計

4.1 系統架構設計

在結合本次研究開發的系統功能特點，分析了目前軟件普遍使用的技術框架之后，

前端開發采用基于MVVM模式的Vue框架并使用JQuery AJAX實現異步跨域，前后端數據以 json 格式進行傳輸。后端使用 SprinBoot+Mybatis 框架。農業公司果蔬批發信息

本次研究開發的系統在開發全局上采用分離前后端的開發技術，即前端負責系統界面呈現效果設計，后端接收與前端的交互數據，進行數據處理并返回前端請求的參數。如此前端界面呈現如何實現，界面如何反應用戶交互操作不再受到后端的影響控制，真正意義上實現了界面與后臺的低耦合，同時降低了服務器載荷，使得系統的運行速率得到更大的提升。通過前后端兩者開發的同步展開進行，也大大提高了軟件的開發效率，使開發方式更為靈活。

后端應用層包含控制層與業務邏輯層。控制層接收前端傳遞的參數，處理相關數據，后端處理完畢請求后，以 json 形式將參數傳遞給前端。業務邏輯層包括對業務處理過程中的邏輯運算。數據層是系統開發過程中所有業務邏輯運算的信息基礎，主要分為數據訪問和數據存儲，通過訪問業務操作相關數據，進行信息的邏輯運算，得到操作結果并

存儲操作結果數據，經過這一系列流程以實現業務功能。數據訪問層使用Mybatis技術將后臺服務器上的常用操作進行封裝，并封裝了一些常用的數據庫操作方法，以此來實現持久化管理數據庫。

本系統的數據庫管理工具軟件使用的是SQL Server數據庫。

4.2系統靜態結構設計

根據前文第三章介紹的農業公司果蔬批發信息管理系統的功能需求，綜合考慮系統開發的困難程度與軟件實際業務操作中的應用，農業公司果蔬批發信息管理系統功能主要包括用戶角色權限管理功能，即為系統管理員進行系統用戶管理與角色權限定義操作的功能，以及基礎信息維護、營銷、品質管理、數據統計、財務管理、經理審核以及客戶端等為系統員工和客戶用戶提供的業務操作功能。

類圖是軟件開發設計階段的進行繪制的靜態結構圖，體現了系統中的各個類及其之間存在的多種關系［27］。通過類圖可以簡潔明了的看出系統的非動態的結構層次，從而了解系統的復雜程度。

下文將對農業公司果蔬批發信息管理系統針對系統管理員的用戶角色管理功能、針對企業部門員工以及公司客戶的業務處理功能進行類圖設計。各功能的具體設計如下各節介紹。

4.2.1系統管理功能類圖設計

為了實現系統的各種數據、資源的安全訪問管理，提高系統的數據、資源安全權限，系統需要設置一種角色權限的系統管理模塊的功能。系統管理包括使用系統的公司部門員工以及客戶的名稱、角色、聯系方式并設置每位系統用戶的登錄名和密碼等。因此，系統管理功能涉及到的類主要有用戶（User）、角色類（Role）以及菜單類（Menu）, 系統管理類圖便是按照這三個類之間的關系從而進行建模繪制。這三個類中，用戶有自己唯一的系統角色，多名用戶可以屬于一種角色，故而用戶類與角色類為多對一的關聯關系。一類角色有且僅有一種菜單權限，所以角色類與菜單類之間屬于一對一的關聯關系。系統管理類圖如圖 4.2。

圖 4.2 系統管理類圖

以下將對各個類中所包含的主要操作方法進行簡要介紹。

用戶類中的方法主要有：

•findByUsername():通過用戶名獲取用戶信息，并進行顯示。

•findById()：通過用戶ID獲取用戶信息并進行顯示。

•getUserAndRoleById()：通過用戶ID獲取用戶信息和角色信息

•listAllUserByRoldId()：列出某角色下的所有用戶

•editUser()：使用該方法修改用戶相關信息。

•hasUser()：用于判斷用戶名是否存在。

•hasEmail()：用于判斷郵箱是否存在。

•hasNumber()：用于判斷編碼是否存在。

•saveUser()：使用該方法保存用戶新新建或修改后的用戶信息。

•deleteUser()：刪除用戶，即刪除用戶關聯數據。

•listUsersForWindow()：顯示用戶列表，列出所有系統用戶角色。

•writeDB()：該方法用于判斷姓名、用戶名以及郵箱是否重復，郵箱格式是否規范，并將用戶信息導入到數據庫。

角色類中的方法主要有：

•findById()：該方法通過角色ID獲取所有信息數據。

•getRoleById()：該方法通過id查找，并返回角色對象。

•add()：添加角色。

•edit()：編輯修改角色。

•deleteRoleById()：通過角色ID刪除角色數據。

•setAllRights()：該方法用于給當前角色賦予菜單權限，具體方法為通過角色ID

與權限菜單ID 對應起來。

•listAllMenu()：用于顯示菜單列表。根據角色ID獲取角色對象，進而取出本角色菜單權限。

•saveMenuqx()：保存角色菜單權限，通過id獲取角色對象并更新當前角色菜單權限。

•b4Button()：該方法給角色ID授權了增刪改查按鈕權限操作。通過msg參數區分增刪改查。

•roleListWindow()：用于選擇角色。通過關鍵詞檢索條件，列出所有角色。菜單類中的方法主要為對菜單的新增、信息編輯、刪除等基礎操作，此處不再贅述。

4.2.2系統業務處理功能類圖設計

在系統的業務功能中，營銷管理是整個系統的核心功能主題，其中又包括了市場營銷管理、合同管理、氣調庫管理、售后服務以及訂單管理等。在對氣調庫進行業務相關操作的過程中，又涉及到產品的入庫、出庫功能，氣調庫庫位管理功能，庫存盤點以及記錄報廢產品的功能。由于篇幅限制，在本小節僅針對核心業務處理的相關對象進行類圖設計建模。

系統業務處理功能涉及的類包括用戶類(User)、員工類(Stuff)、客戶類(Client)、產品類(Product)、氣調庫類(Stock_Info)、訂單類(Order)、訂單處理類(Order_Process)、合同信息類(Contract_Info)售后訂單類(Aftersales_Order)、入庫類(Stock_In)、出庫類(Stock_Out)、庫存預警類(Stock_Warning)、庫存盤點類(Stock_Check)、產品報廢類(Product_Scrap )、售后處理類(Aftersales_Process )、市場調研信息類 (Market_Research)、產品種類類(Category)以及產品檢測類(Product_Testing)。上一小節已就用戶類的定義展開了詳細的描述，故不再進行說明。

在系統業務處理中主要涉及系統兩大類用戶，即員工與客戶。員工類與客戶類均繼承用戶類，繼承了父類用戶類中的屬性及方法。員工根據實際調研情況多次記錄市場調研信息，員工類與市場調研信息類之間為一對多的關聯關系，員工類可調用市場調研信息類中的set()、get()方法獲取查看、設置賦值市場調研信息類中的屬性值。同樣的，員工每次進行產品入庫出庫操作，均記錄相關信息，故員工類與入庫類、出庫類屬于一對多的關聯關系，可獲取賦值入庫出庫類中的屬性值，同時每次產生入庫出庫對象，調用 updateStock()方法更新庫位中產品庫存值屬性。同理，產品報廢和庫存盤點兩個業務控制類在每次產生盤點或報廢操作時均調用方法更新庫位庫存值。庫存預警類包含 countStock()方法計算庫位庫存值并判斷是否處于庫存緊張狀態，從而計算出庫存緊張的庫位及其庫存值，從而將參數傳給前端 Echarts 插件進行圖形顯示。入庫類、出庫類、庫存盤點類、產品報廢類均依賴于庫位類，通過庫位編碼(stockNo)獲取相關屬性及方法。庫存預警類依賴于庫存盤點類，通過盤點編碼獲取庫位最新庫存信息從而計算每個庫位庫存進行庫存預警。每個庫位中存放一定量的產品，庫位類與產品類之間為一對多的關聯關系。產品種類中包括多個品類的產品，因此產品種類類與產品類屬于一對多的關聯關系。產品質檢類依賴于產品類，每次產生產品質檢對象即調用updateQuality()方法更新產品的品質等級屬性(quality)。產品加工類與產品類屬于依賴關系，產品加工依賴于產品的定義，每次產生產品加工對象，即調用addProduct()方法增加產品對象，添加產品成品。員工使用訂單處理類處理訂單，調用toAudit()方法審核訂單，每次由各職責員工完成訂單審核，調用updateStatus()方法更新訂單狀態屬性，一份訂單由各個職責的員工進行審核處理，員工審核處理多份訂單，因此員工與訂單處理類屬于多對多的關聯關系。而訂單處理類和訂單類二者之間的關系中，訂單類是被依賴的對象，訂單處理類中的操作方法的實現取決于訂單類的定義。客戶類使用訂單類，獲取查詢訂單屬性值，客戶可多次下單并查看多份訂單的信息，二者屬于一對多的關聯關系。售后訂單類繼承了訂單類，售后訂單類的定義決定了售后處理類的方法實現，售后處理類使用售后訂單類進行售后業務處理，通過售后訂單唯一標識符獲取客戶提交售后申請的詳細情況信息。員工類使用售后處理類通過toAudit()方法調用來確認審核售后，售后處理須由各職位員工多次審核操作，客戶類使用售后處理類通過submit()方法調用提交售后訂單申請，生成新的售后訂單對象，因此員工類與售后處理類為多對多的關聯關系，客戶類與售后處理類之間存在一對多的關聯關系。系統業務處理功能類圖設計如圖 4.3。

圖 4.3 營銷管理功能類圖

以上類圖中，每個類中的操作行為基本類似，均包含對類中屬性的get獲取和set 賦值操作，故此處對每個類中的方法不再展開具體的解釋說明。

4.3 數據庫設計

數據庫設計的主要任務是構造系統中信息數據存儲的數據庫模式，從而使得用戶的系統應用需求即信息及對其處理的需求得到有效充分的滿足。以下小節將對數據庫概念展開分析和設計建模，并對數據庫中體現數據庫的數據存儲層次結構的數據表進行詳細說明。

本次農業公司果蔬批發信息管理系統開發數據庫系統使用的數據庫管理工具是 SQL Server數據庫。在數據庫設計階段，主要結合系統功能需求歸納抽象出操作的對象及其屬性信息，從而進行數據庫概念結構建模，得到數據庫的概念結構圖，即實體聯系圖，然后按照實體關聯關系在數據庫概念結構圖中的呈現，設計數據庫表結構，從而完成數據庫的設計實現。

4.3.1數據庫概念設計

數據庫概念設計是數據庫設計的關鍵，在此將需求對象轉換成實體關系模型［28］，本文通過繪制E-R圖，從而描述顯示出實體、屬性以及兩者之間的聯系。由于篇幅限制，本次數據庫概念設計時經過了充分詳盡的分析考慮，但在 E-R 圖建模設計過程中將僅展示系統數據庫涉及到的主要實體及其包含的屬性信息。

在農業公司果蔬批發信息管理系統在數據庫概念模型中的實體主要包括系統用戶、角色和菜單權限系統基礎實體以及員工、客戶、訂單、產品、合同、售后、市場調研信息、庫位等業務處理相關實體。并且實體與實體之間存在著多種聯系。例如用戶唯一對應一種角色，多個用戶可能均對應一種角色，因此二者之間存在一對多的聯系；每個角色有不同的的系統菜單功能的使用權限，因此兩個實體間屬于一對多的聯系；每名員工對應系統一名用戶，故員工與用戶實體之間屬于一對一的聯系；一份訂單對應一份合同，一份合同只屬于一份訂單，因此訂單與合同存在一對一的聯系等；客戶可以申請多項售后，因此客戶與售后存在一對多的聯系；員工可以處理多項售后；一項售后由多名員工進行審核處理，因此用戶與售后存在多對多的聯系；客戶可以多次下單，因此客戶與訂單屬于一對多的聯系；訂單須由多名員工進行審核，因此員工與訂單屬于多對多的聯系；員工根據實際業務操作，記錄每次市場調研信息，安排產品加工包裝，安排質量檢測，記錄入庫單、出庫單、庫存盤點單以及報廢單，故員工與市場調研、加工、質檢、入庫單、出庫單、盤點單以及報廢單均為一對多的聯系。通過E-R圖可以清晰地顯示實體與實體間的多種抽象的聯系。在對實際業務流進行詳細的梳理分析后，繪制得到包含農業公司果蔬批發信息管理系統實體及其間關系的整體的E-R圖，如圖4.4所示。下文將對圖中實體展開具體描述。

用戶編碼、用戶名、密碼等用戶登錄系統的基本數據屬于用戶實體的包含屬性，此

角色實體主要包括角色名，角色編碼以及角色說明。角色實體如圖4.6中（a）圖所示。菜單實體主要包括菜單編碼，菜單名，菜單路徑以及角色編碼。其中角色編碼表示該項菜單使用權限所屬的角色，菜單實體如圖4.6中⑹圖所示。

圖 4.6 角色和菜單實體

庫位實體包括庫位編碼，氣調庫庫位溫度，狀態，當前是否閑置，若轉租其租金情

況等屬性。庫位實體如圖 4.7 所示

圖 4.7 庫位實體

訂單實體包含了客戶需求訂單的主要信息，包括訂單日期，所含產品名稱及其計量

方式，客戶需求貨量，產品單價等屬性。如圖 4.8 所示。

圖 4.8 訂單實體

每份訂單均對應一份合同。合同包含了訂單編碼，合同的簽訂日期，合同金額及其簽訂人等信息。如圖 4.9 所示。

圖 4.9 合同實體

農業公司定期派出員工調研市場信息，調研員反饋調研結果。市場調研信息中包括產品名稱，被調研的產品在批發市場的單位售價，批發市場地名，農貿市場地名，被調研產品在農貿市場中的單位售價，調研員工編碼，調研時間，調研的日期等屬性。如圖 4.10 所示。

產品是當前該農業的核心實體。產品包括產品編碼，名稱，種類編碼，計量方式，

最低庫存，最高庫存，訂單編碼，品質等級，庫位編碼，儲存方式等信息，如圖 4.11

所示。

每個品種的產品均由所屬的產品種類。產品種類實體主要包括種類編碼，種類名以

及種類說明屬性。產品種類實體如圖 4.12 所示。

售后服務需處理的信息包括訂單編碼，漏發量，破損量，破損程度，圖片證明，解

決方式，客戶編碼，以及申請日期等信息，如圖 4.13 所示。

圖 4.13 售后實體

客戶是一類用戶。客戶實體主要包括客戶名稱、用戶編碼、聯系人、客戶榮譽、合

作起始時間、合作終止時間、電話，地址等屬性，客戶實體如圖 4.14所示。

員工是一類系統用戶，員工實體包含員工姓名、性別、用戶編碼、身份證號、出身

日期、進入公司就職日期以及文化水平的基礎信息屬性。員工實體如圖 4.15 所示。

（用戶編碼）

（身份證號） ( 出生日期）

（姓名k A Z X入職時間）

（腳么一（學歷）

員工

圖 4.15 員工實體

客戶下單，產生訂單，員工記錄出庫信息。出庫單實體包含出庫編碼、出庫時間、

出庫量等出庫相關信息屬性，還包括產品ID、訂單ID、操作員工ID以及庫位ID，以

產品入庫，員工記錄入庫信息。入庫實體包括入庫ID、入庫量、入庫時間等基礎信息屬性，還包括產品ID、操作員工ID以及庫位ID屬性用以關聯入庫涉及的實體。入庫單實體如圖 4.17 所示。

4.3.2數據庫邏輯結構設計

根據數據庫概念規律模型，將E-R模型中所呈現的實體及其間關系進行歸納總結得出數據庫的邏輯規律結構，也就是用數據表的形式展示出來，用主鍵和外鍵來描述實體之間的關系，實體及其屬性用數據表來表示［30］。在農業公司果蔬批發信息管理系統中涉及的主要數據表有用戶數據表、權限數據表、角色數據表、員工數據表、客戶數據表、產品數據表、產品種類數據表、庫位數據表、入庫數據表、出庫數據表、訂單數據表、合同數據表、市場調研數據表等 10 余張數據表。其主要的表結構及其屬性的數據類型介紹如下。

（1）員工表員工數據表用來存儲員工包括營銷部員工、財務部員工以及經理的基本情況信息，其中，用戶編號USER_ID為主鍵，與用戶表主鍵一致，表示員工與用戶之間一對一的關系。根據用戶編碼可用來關聯用戶表從而獲取登錄系統所需的數據。員工表的結構設計如表 4.1 所示。

表 4.1 STAFFINFO 員工表

屬性名稱屬性含義類型定義長度置為主鍵可否置空

USER ID 用戶編號 varchar 11 是否

SNAME 姓名 varchar 45 否否

SBIRTHDAY 出生日期 varchar 45 否是

SGENDER 性別 varchart 2 否是

SIDCARD 身份證號 Varchar 25 否是

SEDUCATION 學歷 Varchar 25 否是

SINDATE 入職時間 Varchar 25 否是

2）客戶表

該表用來存儲公司客戶的基本情況信息，包括用戶編碼，客戶名稱，聯系人，電話，合作起始時間，合作結束時間，對接公司員工編號，客戶榮譽等，其中，用戶編號USER_ID 為主鍵，字段對接公司員工編號為外鍵，對應STAFFINFO員工表中的主鍵用戶編碼 USER_ID，系統根據該字段獲取員工表中該客戶對接的員工信息。客戶表的結構設計如表 4.2 所示。

表 4.2 CUSTOMERINFO 客戶表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

USER ID 用戶編號 varchar 11 是否

續表4.2 CUSTOMERINFO 客戶表

CNAME 客戶名稱 varchar 45 否是

CCONTACT 聯系人 varchar 45 否是

CPHONE 電話 varchar 45 否是

CADDRESS 配送地址 varchar 45 否是

CSTARTTIME 合作起始時間 varchar 25 否是

CENDTIME 合作結束世間 varchar 25 否是

STUFF ID 對接公司員工編碼 varchar 25 外鍵是

CHONOR 客戶榮譽 varchar 30 否是

（3）產品種類信息表產品種類信息表用來存儲公司產品種類的基本情況信息，包括種類編碼，種類名，儲存方式。其中，種類編碼TYPE_ID為主鍵。產品種類信息表的結構設計如表4.3所示。

表 4.3 PRODUCTTYPEINFO 產品種類信息表

屬性名稱屬性含義類型定義長度置為主鍵可否置空

TYPE ID 種類編碼 varchar 10 是否

TYPENAME 種類名 varchar 45 否否

DESCRIBE 種類說明 varchar 45 否是

4）產品信息表

產品信息表用來存儲公司水果蔬菜產品的基本情況信息，包括產品編號，產品名稱，種類編碼，計量方式，儲存方式，保質期，最低庫存，最高庫存，建議庫存，菜品等級，庫位編碼等。其中，產品編號PRODUCT_ID為主鍵，種類編碼PORDUCTTYPE_ID為外鍵，對應產品種類信息表中的主鍵TYPE_ID，通過PORDUCTTYPE_ID可關聯獲取產品所屬種類的信息。庫位編碼KW_ID為外鍵，對應氣調庫位信息表中的主鍵WH_ID，系統根據該字段判斷果蔬產品的存放庫位，進行庫存管理。產品信息表的結構設計如表

4.4所示。

表 4.4 PORDUCTINFO 產品信息表

屬性名稱屬性含義類型定義長度置為主鍵可否置空

PORDUCT ID 產品編號 varchar 10 是否

PORDUCT NAME 產品名稱 varchar 45 否是

PORDUCTTYPE ID 種類編碼 varchar 10 外鍵否

MEASURE 計量方式 varchar 45 否是

STORAGETYPE 儲存方式 varchar 45 否是

續表4.4 PORDUCTINFO 產品信息表

BZT 保質期 varchar 10 否是

MINKC 最低庫存 int 20 否是

MAXKC 最高庫存 int 20 否是

SUGGESTKC 建議庫存 int 10 否是

PRICE 參考售價 float 25 否是

QUALITY 質量等級 varchar 25 否是

KW ID 庫位編碼 varchar 25 外鍵否

5）用戶表

用戶信息表用來存放系統用戶登錄系統時必須的信息以及對應的角色編碼等信息。其中用戶編碼USER_ID為主鍵，角色編碼ROLE_ID為外鍵，對應角色表的主鍵，通過角色編碼關聯到用戶的角色信息。用戶表設計結構如表4.5所示。

表 4.5 SYS USER 用戶表

屬性名稱屬性含義類型定義

長度置為主鍵可否置空

USER ID 用戶編碼 varchar 10 是否

USER NAME 用戶名 varchar 45 否否

PASSWORD 密碼 varchar 45 否否

ROLE ID 角色編碼 varchar 10 外鍵否

E-mail 郵箱 varchar 50 否是

PHONE 聯系方式 varchar 45 否是

LAST LOGIN 最近登陸時間 varchar 45 否是

LAST IP 上次登錄 IP varchar 45 否是

6）菜單表

菜單表存放系統每個角色的菜單權限數據，包括菜單編碼、菜單路徑等信息。其中菜單編碼 RIGHT_ID 為主鍵，菜單路徑即為功能菜單的資源路徑。角色編碼為外鍵，對應角色表主鍵ROLE_ID，用來制定菜單的使用權所屬的角色。菜單表的結構設計如表 4.6 所示。

表 4.6 SYS RIGHT 菜單表

屬性名稱屬性含義類型定義長度置為主鍵可否置空

RIGHT ID 菜單編碼 varchar 10 是否

RIGHT NAME 菜單名 varchar 45 否否

續表 4.6 SYS RIGHT 菜單表

PATH 菜單路徑 varchar 45 否是

ROLE ID 角色編碼 varchar 10 外鍵否

（7）角色表

角色表用來存儲系統中包含的每類角色的基本信息數據。其中，角色編碼ROLE_ID 主鍵。角色表的設計結構如表4.7所示。

表 4.7 SYS ROLE 角色表

屬性名稱屬性含義類型定義長度置為主鍵可否置空

ROLE ID 角色編碼 varchar 10 是否

ROLE NAME 角色名 varchar 45 否否

DESCRIBE 角色說明 varchar 100 否是

（8）氣調庫信息表氣調庫位信息表用來存儲公司氣調庫房的基本信息，比如溫度，租金，庫房狀態，是否閑置等。其中，庫位編碼WH_ID主鍵。氣調庫信息表的設計結構如表4.8所示。

表 4.8 WHINFO 氣調庫位信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

WH ID 庫位編碼 varchar 10 是否

TEMPERATURE 庫位溫度 varchar 25 否是

RENT 庫位租金 float 25 否是

STATUS 庫位狀態 varchar 25 否是

ISEMPTY 是否閑置 varchar 25 否是

9）入庫單信息表

入庫信息表用來存儲公司每次進行產品入庫記錄的基本信息，包括入庫單編號，庫位編碼，產品編碼，入庫數量，入庫操作員編碼，入庫時間。其中，入庫單編號RKD_ID 為主鍵，庫位編碼為外鍵，對應氣調庫位信息表主鍵WH_ID，系統依據該字段查找對應每次進行入庫的庫位，從而管理該庫位庫存。產品編碼為外鍵，對應產品信息表主鍵 PRODUCT_ID，系統根據該字段查找產品名稱等產品基礎信息。操作員工編碼為外鍵，引用員工表主鍵USER_ID,以區別每次入庫負責操作的員工。入庫單信息表的結構設計如表 4.9 所示。

表 4.9 INWARE 入庫單信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

RKD ID 入庫單編號 varchar 10 是否

WH ID 庫位編碼 varchar 25 外鍵否

PORDUCT ID 產品編碼 varchar 25 外鍵否

NUM 入庫數量 int 25 否是

OPERATOR 入庫操作員編碼 varchar 25 外鍵否

DATE 入庫時間 varchar 25 否是

10）出庫單信息表

出庫信息表用來存儲公司每次進行產品出庫記錄的基本信息，包括出庫單編號，庫位編碼，訂單編碼，出庫數量，出庫操作員編碼，出庫時間。其中，出庫單編號CKD_ID 為主鍵，庫位編碼WH_ID、產品編碼CONDUCTID、操作員工編碼OPERATOR以及訂單編碼 ORDERID 為外鍵，系統依據庫位編碼查找對應每次進行出庫的庫位，從而管理該庫位庫存，依據訂單編碼查找每次出庫所對應的訂單，從而使訂單中產品量與每次產品出庫量數據一致，根據產品編碼獲取出庫產品產品名稱、計量方式等信息，根據操作員工編碼，查找每次出庫的負責員工。出庫單信息表的結構設計如表4.10所示。

表 4.10 OUTWARE 出庫單信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

CKD ID 出庫單編號 varchar 10 是否

WH ID 庫位編碼 varchar 25 外鍵否

ORDERID 訂單編碼 varchar 25 外鍵否

CONDUCTID 產品編碼 varchar 25 外鍵否

NUM 出庫數量 int 25 否是

OPERATOR 操作員工員編碼 varchar 25 外鍵否

DATE 出庫時間 varchar 25 否是

11）市場調研信息表

市場調研信息表用來存儲公司每次派出員工進行市場調研的結果數據，包括調研編號，調研時間、產品編碼、農貿市場名、市場售價、批發市場名、批發售價、調研員工編碼以及錄入時間。其中，調研編號RESEARCHED為主鍵，調研員工編碼RSTUFF_ID 為外鍵，對應于員工表主鍵USER_ID,系統根據調研員工編碼，查找每次市場調研的負責員工。市場調研信息表的結構設計如表4.11所示。

表 4.11 MARKETRESEARCH 市場調研信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

RESEARCH ID 調研編號 varchar 10 是否

PRONAME 產品名稱 varchar 25 否否

RTIME 調研時間 varchar 25 否是

FMNAME 農貿市場名 varchar 25 否是

FMPRICE 市場售價 float 25 否是

WMNAME 批發市場名 varchar 25 否是

WPRICE 批發售價 float 25 否是

RSTUFF ID 員工編碼 varchar 25 外鍵否

12）訂單信息表

訂單信息表存儲的是客戶進行下單產生的訂單中的產品信息，包括訂單編碼、產品編碼、客戶編碼、要貨量、成交日期等。其中訂單編碼ORDER_ID為主鍵，產品編碼 CONDUCTID和客戶編碼CLIENT_ID為外鍵，對應產品信息表主鍵PRODUCT_ID和客戶表主鍵USER_ID,系統依據產品編碼獲取訂單中的產品的名稱、計量方式等信息, 根據客戶編碼，區分不同客戶的訂單。訂單信息表結構如表4.12所示。

表 4.12 ORDERINFO 訂單信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

ORDER ID 訂單編碼 varchar 25 主鍵否

CLIENT ID 客戶編碼 varchar 25 外鍵否

CONDUCTID 產品編碼 varchar 25 外鍵否

DEMAND 需求貨量 int 25 否是

DEALDATE 訂單日期 varchar 25 否是

UNIT 產品單價 float 10 否是

（13）合同信息表合同信息表中包括合同編碼，訂單編碼，簽訂日期，合同金額，客戶編碼。合同編碼為主鍵，訂單編碼 ORDER_ID 為主鍵。合同信息表結構如表 4.13 所示。

表 4.13 CONTRACTINFO 合同信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

ORDER ID 訂單編碼 varchar 25 主鍵否

續表 4.13 CONTRACTINFO 合同信息表

CDATE 簽訂日期 varchar 25 否是

CAMOUNT 合同金額 int 25 否否

QDR 簽訂人 varchar 25 否是

14）售后信息表

售后信息表存放客戶申請售后的詳細情況信息。表中字段包括售后編碼、漏發量、破損量、解決方式、客戶編碼等。其中售后編碼SF_ID為主鍵，客戶編碼CLIENT_ID 為外鍵，對應客戶表主鍵USER_ID,用來獲取申請該售后的客戶相關信息。

表 4.14 AFTERSALES 售后信息表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

SF ID 售后編碼 varchar 10 主鍵否

DAMAGE 破損量 float 25 否否

MISS 漏發量 float 25 否是

DAMAGE DEGREE 破損程度 varchar 10 否是

PHOTO 圖片說明 varchar 50 否是

SOLUTION 解決方式 varchar 15 否是

CLIENT ID 客戶編碼 varchar 10 外鍵否

APPLY DATE 申請日期 varchar 10 否是

15）售后審批狀態表

售后審核表存放員工審核客戶申請售后的詳細信息。表中字段包括員工編碼，訂單編碼，售后狀態。員工編碼STUFF_ID和訂單編碼ORDER_ID共同構成主鍵，構成主鍵的員工編碼和訂單編碼均為外鍵，分別對應員工表與訂單表主鍵。該表體現的是某筆客戶售后申請由某員工審核的結果狀態。訂單審核狀態表結構如表4.15所示。

表 4.15 AFTERSALES SATUS 售后審核狀態表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

STUFF ID 員工編碼 varchar 10 外鍵否

ORDER ID 客戶編碼 varchar 25 外鍵否

ORDER SATUS 售后狀態 varchar 25 否是

16）訂單審核狀態表

訂單審核表存放員工審核訂單的結果信息。表中字段包括員工編碼，訂單編碼，訂單狀態。員工編碼STUFF_ID和訂單編碼ORDER_ID共同構成主鍵，構成主鍵的員工編碼和訂單編碼均為外鍵，分別對應員工表與訂單表主鍵。該表為員工審核訂單的多對多關系表，體現的是某筆訂單由某員工審核的結果狀態。訂單審核狀態表結構如表4.16 所示。

表 4.16 ORDER SATUS 訂單審核狀態表

屬性名稱屬性含義類型定義

長度置為

主鍵可否

置空

STUFF ID 員工編號 varchar 10 外鍵否

ORDER ID 客戶編碼 varchar 25 外鍵否

ORDER SATUS 訂單狀態 varchar 25 否是

4.4 系統時序圖建模

軟件開發是為了對實際業務進行信息化的管理。其中可能涉及到比較復雜的業務處理邏輯。而通過繪制時序圖，業務可以得到具體明了的詮釋，并使得后續編寫代碼效率大大提升。

時序圖呈現了對象之間發送聯系信息的前后順序，體現其間交互行為的順序［29］。系統與用戶間的行為交互被抽象為角色與系統中處理對象之間的信息傳遞。通過時序圖可以看出對象之間的動態協作以及對象狀態出現改變時對象外部的觸發點，最終明確業務邏輯。

下文將通過建立時序圖模型來對系統的各個用例的業務邏輯進行分析。

4.4.1系統管理功能時序圖設計

管理員進行系統用戶角色權限信息管理的先決條件是成功登錄進入管理頁面，進入用戶信息管理頁面后通過加載 listUSERFORWindow 方法獲取用戶信息，并讀取數據庫信息，從而返回USER對象給界面進行展示。管理員進入管理頁面后，添加角色信息并給角色定義菜單權限，頁面加載add方法，添加新角色，調用add方法添加角色權限，在數據庫對應表中插入新記錄，操作成功返回MENU對象給新定義的角色類型賦予其系統菜單使用權限。添加用戶用例中，頁面加載add方法，添加一個新用戶對象，并在數據庫中插入新用戶記錄，并調用get方法獲取新添加的USER對應的角色信息。

系統管理功能的時序圖如圖 4.20 所示。

圖 4.20 系統管理功能時序圖

4.4.2出入庫管理和庫存盤點功能時序圖設計營銷部員工登錄系統進入入庫管理頁面后通過加載 addRecord 方法添加入庫記錄，并調用toEdit方法編輯修改對應庫位的屬性，根據STOCK_ID庫位編碼，數據庫更新對應的庫位信息，返回操作結果 bool 值。

出庫管理與入庫管理操作順序基本一致，只是當添加出庫對象時，將調用 ORDER 對象的get方法，獲取出庫對應的ORDER中的信息屬性，以確保出庫產品量與訂單要貨量的數額對應一致。

營銷部員工進行庫存盤點管理的前提條件是員工成功登錄進入庫存盤點頁面，進入庫存盤點頁面后通過加載 add 方法添加盤點記錄，調用 updateStock 方法編輯修改對應庫位的屬性，根據STOCK_ID庫位編碼，數據庫更新對應的庫位信息，返回操作結果 bool 值。

出入庫管理和庫存盤點功能時序圖如圖 4.21。

圖 4.21 出入庫管理和庫存盤點功能時序圖

4.4.3庫存預警功能時序圖設計

營銷部員工進入庫存預警頁面后通過加載getCurrentStock方法獲取每個庫位的當前庫存并對當前庫存值是否低于100進行判斷，返回庫存低于100的庫存對象列表到頁面。前端庫存預警頁面實例化一個echarts圖表插件對象Mychart，并請求獲取庫存緊張的庫位對象列表， Mychart 調用 setOption 方法將庫存緊張庫位的信息參數附加到柱狀圖軸參數，繪制柱狀圖并返回繪制結果圖，對營銷部員工進行展示。數據統計用例中各個包含用例的數據圖形展示操作順序與庫存預警基本一致，故不再額外進行時序圖繪制說明。

庫存預警功能時序圖如圖 4.22。

4.4.4公司客戶下單和員工訂單管理時序圖設計公司客戶成功登錄系統進入產品列表頁面，進入產品列表頁面后通過加載 readProlist方法通過ORDER_PROCESS對象調用get方法獲取PRODUCT對象，獲取產品信息列表，PRODUCT對象從數據庫中獲取查詢產品信息結果，并返回產品對象給頁面進行信息展示。公司財務員工與經理登錄系統進入訂單管理頁面，加載toAudit方法審核訂單，并調用upstateStatus方法更新ORDER對象的狀態屬性。客戶進入訂單管理頁面調用 Query 方法，獲取訂單對象，返回至頁面展示訂單信息及其處理進度。

公司客戶下單和員工訂單管理時序圖如圖 4.23 所示。

圖 4.23 公司客戶下單和員工訂單管理時序圖

4.4.5公司客戶售后申請和員工售后管理時序圖設計

公司客戶登錄系統進入售后申請頁面后通過加載submit方法調用售后訂單對象add 方法，添加新的售后訂單對象，在數據庫中插入對應數據。

公司經理成功登錄進入售后申請頁面詢，加載toAudit方法審核訂單，并調用 updateStatus方法更新售后訂單AFTERSALESE_ORDER對象的狀態屬性。

營銷部員工進入售后服務頁面，通過調用Query方法，獲取售后對象屬性信息，并加載PRODUCT產品對象get方法讀取產品信息，返回給售后訂單對象，從而對客戶提交的售后申請信息詳情進行頁面展示。

公司客戶售后申請和員工售后管理時序圖如圖 4.24所示。

圖 4.24 公司客戶售后申請和員工售后管理時序圖

4.5 本章小結

本章首先介紹了系統的架構設計。接著設計類圖，建立系統的靜態概念模型。然后進行數據庫設計，利用E-R圖描述了農業公司果蔬批發信息管理系統的實體及其屬性的設計，并進行數據表中的規律結構設計。最后通過時序圖設計梳理系統的業務處理邏輯。

第 5 章農業公司果蔬批發信息管理系統的實現

5.1系統管理功能的實現

管理員登錄系統后，進入系統的用戶角色管理模塊。用戶角色權限管理模塊主要包含用戶管理功能與角色菜單權限管理功能。管理可查看編輯系統菜單權限，頁面如圖 5.1 所示。用戶管理是管理員進行系統用戶角色菜單權限管理的主體功能，管理員在用戶信息界面可查看系統中已存在的用戶，頁面如圖 5.2，并新增進入創建系統用戶的賬號、密碼等信息頁面，如圖5.3所示。

主頁數齢典裁用戶

E 報熬

ffl 用戶管理

S 談灑鳩歸戶

+ 莒銷宓

NO 褊號用戶名姓名角色郵箱最近登錄上次登錄IP 操作

1 admin 刃y 歆員艇員 23456@qq.sm 2021-03-11 04:29:39 127.0.0.1 X

2 kehu kehu 審戶公司喜戶 123456@qq.com 2021-03-11 02:27:02 127.0.0.1 曰夕X

3 Z003 wangwu EH 5555555@qq.com 2021-03-11 01:54:28 127.0.0.1 已夕X

4 Z002 li引李四財務 12221121@qq.com 2021-03-11 01:53:53 127.0.0.1 日夕X

5 z001 zhangsan MX 18765888888@qq.con 2021-03-10 23:23:03 127.0.0. t 已夕X

新堵刪除發站內信共5條跳轉首頁 "1下頁尾頁共1頁10 *

圖 5.2 用戶管理頁面

圖 5.3 創建用戶頁面

5.2基礎信息管理功能的實現

農業公司果蔬批發信息管理系統中的基礎信息管理功能包括對整個系統的核心數據果蔬產品信息的管理，包括水果蔬菜的種類及其品類信息，以及公司員工客戶的基礎信息。每個主題界面均呈現該主題的數據列表，并進行增刪改查操作。頁面如圖 5.5 蔬菜品類信息管理界面與圖 5.6 新增界面所示。

NO 菜屈名稱菜品編號菜品種婪榮品種芙編號計星單位建議儲存方式保質期最低庫存最高庫存建議庫存參耳

員工信息、客戶信息、蔬菜種類信息、水果種類信息、水果品類信息管理中的信息增刪改查操作代碼與界面與實現方法類似，故不再展開描述。

5.3營銷管理功能的實現

農業公司果蔬批發信息管理系統中的營銷管理是系統的核心功能，涵蓋了訂單、氣調庫、產品質量檢測、產品加工，訂單售后的業務操作與信息管理。氣調庫管理包括庫位管理、出入庫、庫存盤點、庫存預警，實現同步實際新增氣調庫庫位，并增刪改出入庫、庫存盤點的信息記錄，基于這些信息記錄將對庫位的庫存緊張情況進行顯示。營銷管理中的訂單或售后管理用于顯示客戶端提交的訂單/售后申請信息，并將其提交至經理端審核界面，經理進入該界面審閱該訂單/售后申請信息，審核通過則將該訂單/售后申請提交至財務端管理界面由財務進行最終審核。訂單每次被審核，客戶端界面同步展示審核結果。

用戶本小節將結合經理用戶的審核功能實現、客戶端下單與售后申請功能實現以及財務審核功能實現進行方法論述，故不再另設小節展示經理審核、客戶端下單與售后申請以及財務審核功能的實現方法。

5.3.1庫位管理功能實現

庫位管理即查看氣調庫的每個庫位并修改每個庫位的具體屬性。頁面如圖 5.8 所示

控制層WareHouseController調用edit方法，實例化PageData對象，獲取庫位編輯頁面的數據，訪問業務服務層 warehouseService ，調用 warehouseService.save 方法將 getPageData方法返回的數據保存至數據庫。以下是修改庫位屬性的部分實現代碼。

i^RequestMappingf value= )

@RequiresPermissions("ivarehouse :edit1F) ^ResponseBody

public Object edit() throws Exception{ Hap

ingjObject> map = neiv HashMap

String errlnfo = 'Success1*;

PageData gd = n已 F話gw［打二才打 pd = this .getPa呂日()； ^.■arehouaeSertfice.edit(pd);

map.put(' result11 j rlnfo) j

return map;

}

圖 5.9 修改庫位屬性代碼

產品入出庫、庫存盤點以及報廢申請通過其控制層的調用add方法，獲取添加出入庫或庫存盤點記錄表單的數據，并將其作為參數，訪問業務服務Service層的save方法將表單數據寫入數據庫。其界面代碼實現類似，故不再展開描述。添加入庫記錄表單如圖 5.10 添加入庫信息頁面所示。

圖 5.10 添加入庫信息頁面

5.3.2庫存預警功能實現

庫存預警即在頁面以柱狀圖的形式顯示庫存緊張的庫位編號。頁面如圖 5.11 所示

圖 5.11 庫存預警頁面

控制層 StockWarningController 調用 listWarning 方法，當前頁面實例化對象 Page 作為參數傳遞，調用setPd方法，以庫存盤點頁面數據初始化當前頁面數據，訪問業務服務層 pdrecordingService 接口，調用 pdRecord 方法，將庫存盤點的庫存數據列表賦值給 varList變量。循環varList變量，計算每個庫位的總庫存量，并計算庫存量緊張的庫位并存儲庫位號及其庫存量數據。前端頁面通過map參數獲取庫存緊張的每個庫位庫位號及其總庫存，引入Echarts插件實例化echarts對象，設置參數，最終調用setOption方法使用設置的配置項和數據來顯示圖形，進行庫存預警展示。以下是庫存預警的部分實現代碼。

圖 5.12 庫存預警代碼

5.3.3訂單管理功能實現

訂單管理涉及客戶端、營銷端、經理端以及財務端的操作。首先在客戶端產品列表界面進行下單操作，如圖 5.13，圖 5.14，營銷端訂單管理界面會顯示客戶提交的訂單列表，并進行訂單的提交審批操作，如圖 5.15。然后進入經理端訂單審批界面顯示營銷部已確認訂單列表并進行訂單審批通過操作，財務端顯示經理已審批的訂單列表，并進行訂單最終審核確認。最后客戶端在訂單管理界面根據訂單信息列表中訂單當前狀態屬性，查看訂單處理進程，如圖 5.16。

圖 5.13 產品列表頁面

圖 5.15 營銷部提交審批訂單頁面

圖 5.16 查看訂單處理進度頁面

訂單管理中，首先客戶端在產品界面下單，控制層 ClientOrderController 類調用 addOrder()方法，實例化一個新的Order對象，通過訪問OrderService訂單實體服務層接口，調用set()方法將前端產品列表界面傳遞的參數賦值給訂單對應屬性。此時設置訂單狀態屬性STATUS值為0，表示訂單狀態為已提交。然后前端營銷端clientOrder_edit界面用戶提交審核訂單操作后，設置訂單當前狀態屬性參數至后臺， OrderManagementController 控制層調用 updateStatus()方法，訪問 OrderService 接口，調用set()方法將STATUS置為1,表示訂單待審批。前端經理以及財務審核頁面用戶審核操作后，前端返回當前狀態參數，后臺控制調用set()方法將STATUS置為2和3，表示訂單待財務確認以及訂單已發貨狀態。以此來實現系統中各個端訂單管理的業務處理邏輯。

售后服務功能同訂單管理功能類似，同樣設計四個端的協同操作，代碼與界面的實現方法基本一致，故不再展開描述。

此外系統還包含數據統計與質量檢測功能與營銷端產品加工、采購管理、合同管理以及市場調研信息管理功能的實現。因篇幅限制，且實現方法與以上功能沒有太大差異，故不再贅述。

第 6 章系統測試

6.1 測試意義及目標

在完成對軟件系統的代碼編寫并調試運行成功后，需要驗證系統運轉工作是否正常，找出軟件運行時出現的問題錯誤［31］。在軟件開發周期過程中，作為必不可缺的一個階段，為開發人員提供發現影響軟件質量的問題錯誤，這對全面完善系統功能，提高系統運行效率，為用戶提供更好的使用體驗具有重大意義。

找出錯誤是系統測試最根本的目的，而不是去證明系統是否正確［32］。從系統外部使用者用戶的角度出發，功能全面，系統運行順暢不出錯，就是系統開發出來要達成的目的。因此，經過系統測試后，將有助于開發者進一步完善系統，使其得到用戶認可。

6.2 測試方法

系統測試按照不同的分類標準可分為多種測試方法。以測試對象為標準進行分類，系統測試可分為黑盒測試，白盒測試以及灰盒測試三種方法：

黑盒測試就是功能性測試，主要針對系統的各項模塊功能展開測試［33］。黑盒測試中，內部程序代碼的規律結構是不為測試人員所知的，僅檢驗系統的各個功能模塊在滿足預設需求的條件下是否正常運行，即測試軟件外在功能是否可用。

白盒測試則是在了解系統內部程序代碼的邏輯結構情況下進行的。白盒測試中，通過對系統內部程序代碼的邏輯結構的檢查，從而檢測出程序實際運行狀態是否符合預定要求，軟件底層代碼的功能是否均正常工作。因此，白盒測試也叫做結構測試。

以測試手段為標準，系統測試又被分為人工手動測試和自動化測試兩種方法：

人工手動測試即由測試人員以手動的方式人為檢驗被測試目標對象，使用這種方法可以根據測試者實際情況更加靈便地改變操作方式和測試環境。

自動化測試是以計算機為硬件條件進行的自動化計算檢測方式，它具體又分為兩種測試形式，一種是測試人員自己編寫腳本運行測試，還有一種就是使用第三方工具直接對測試目標進行測試［34］。

本次開發的農業公司果蔬批發信息管理系統測試采用的是黑盒測試法并且手工進行測試。程序啟動后，結合軟件需求功能，依次進入每個功能界面，手動點擊菜單按鈕，查看其功能是否符合功能需求。

6.3 功能性測試

下文將通過設計測試用例，結合系統功能需求的分析設計，通過實際手動使用操作

系統功能，從而記錄功能測試的實際結果是否與預期項符合。因文章篇幅所限，故下文

僅對系統各個功能模塊的部分功能詳細描述測試用例。

6.3.1系統管理功能測試

表 6.1 系統管理功能測試用例

用例名稱管理員管理用戶角色權限

被測試功能描述此功能用于管理員管理用戶及其角色菜單權限

測試用例 1、管理員輸入信息數據，增加新用戶。

2、管理員輸入系統中已存在的用戶名，添加用戶。

3、管理員刪除已存在的用戶。

4、管理員修改角色的菜單權限。

測試預設結果 1、提示保存成功。

2、保存失敗，提示“用戶已存在”。

3、提示刪除成功。使用被刪除的用戶的賬號密碼登錄系統，提示“用戶名不存在”

4、提示保存成功。使用被修改菜單權限的角色下某一用戶的賬號登陸系統，發現功能菜單改變。

實際呈現結果 1、用例1 保存后，提示保存成功。

2、用例 2 點擊保存后，保存失敗，彈出提示框“用戶已存在”。 3、提示刪除成功。使用被刪除的用戶的賬號密碼登錄系統，登錄界面提示“用戶名不存在”。

4、修改前使用被修改菜單權限的角色中的某一用戶賬號密碼登錄系統查看功能菜單，用例4 點擊保存后，提示保存成功。再次使用該一用戶的賬號登錄系統后，發現功能菜單改變。

6.3.2基礎信息管理功能測試

表 6.2 基礎信息管理功能測試用例

用例名稱員工管理基礎信息

被測試功能描述此功能用于營銷部員工管理員工、客戶以及產品信息

測試用例 1、增加改蔬菜種類信息。

4、增刪改蔬菜品類信息。

5、增加水果種類信息。

6、增刪改水果品類信息。

續表 6.2 基礎信息管理功能測試用例

測試預設結果 1、增加改蔬菜種類信息成功。員工增加蔬菜品類的時，點擊下拉框選擇蔬菜種類，可選擇新增蔬菜種類。

4、增刪改蔬菜品類信息成功。

5、增加改水果種類信息成功。員工增加水果品類的時，點擊下拉框選擇水果種類，可選擇新增水果種類。

6、增刪改水果品類信息成功。

實際呈現結果 1、增刪改新員工信息成功。提示保存/刪除成功。

2、增刪改客戶信息成功。提示保存/刪除成功。

3、增加改蔬菜種類信息成功。員工增加蔬菜品類的時，點擊下拉框選擇蔬菜種類，可選擇項包含新增蔬菜種類。

4、增刪改蔬菜品類信息成功。提示保存/刪除成功。

5、增加改水果種類信息成功。員工增加水果品類的時，點擊下拉框選擇水果種類，可選擇項包含新增水果種類。

6、增刪改水果品類信息成功。提示保存/刪除成功。

6.3.3營銷管理功能測試

表 6.3 訂單管理功能測試用例

用例名稱管理訂單

被測試功能描述此功能用于營銷部員工提請審核訂單

測試用例進入訂單管理界面，查看審核客戶下的訂單信息，點擊提交申請

測試預設結果系統提示提交成功，經理端訂單審核界面新增該待審批訂單。

實際呈現結果提示提交成功，進入經理端訂單審核界面，新增被提交的待審批訂單，客戶查看訂單界面對應訂單處理進度更新為“待審批”。

表 6.4 庫位管理功能測試用例

用例名稱營銷部員工管理氣調庫庫位

被測試功能描述此功能用于營銷部員工管理氣調庫每個庫位的信息

測試用例 1、員工進入庫位管理界面，點擊新增，輸入庫位信息，包括庫位號，庫位狀態，庫位溫度，是否閑置，租金，點擊保存。

2、員工點擊庫位圖標，更改其中的屬性信息，點擊保存。

測試預設結果 1、提示保存成功，庫位管理界面新增一個庫位圖標。

2、系統提示保存成功。

1、提示保存成功，庫位管理界面新增一個庫位圖標。入庫出庫新增記錄信息界面庫位下拉框選項包括新增庫位。

2、員工點擊庫位圖標，彈出庫位信息界面，員工輸入信息點擊保存后，系統提示保存成功。

表 6.5 售后服務管理功能測試用例

功能測試用例售后服務

功能描述此功能用于營銷部員工確認客戶提交的售后申請

測試用例確認售后申請

測試預期結果確認成功，經理端售后審批界面顯示已確認售后訂單。

測試實際結果進入售后申請界面，界面顯示客戶端提交的售后申請，點擊操作，跳轉至售后申請信息界面，點擊提交審批，提示提交成功，經理售后審批界面顯示該條待審批售后訂單。客戶售后申請界面對應售后訂單處理進度更新為“待審批”

6.3.4財務管理功能測試

表 6.6 財務訂單管理功能測試用例

功能測試用例財務訂單管理

功能描述此功能用于財務部員工審批訂單

測試用例提交審批

測試預期結果審批成功，客戶端訂單管理界面訂單狀態更新。

測試實際結果進入訂單管理界面，點擊審批，查看訂單信息，點擊審批通過，提示審批成功，訂單管理界面不再顯示該訂單，客戶查看訂單界面對應訂單處理進度更新為“已發貨”。

表 6.7 售后退款功能測試用例

功能測試用例財務售后退款

功能描述此功能用于財務部員工給客戶安排退款打款之后審批售后訂單

測試用例確認已打款

測試預期結果確認已打款售后申請成功，客戶端訂單當前狀態更新為“售后完成”。

測試實際結果進入售后退款界面，點擊操作，彈出審批通過的售后申請信息界面，點擊已打款，提示確認成功，界面不再顯示該項售后信息，客戶售后申請界面該項售后申請處理進度更新為“售后完成”。

6.3.5經理審核功能測試

表 6.8 訂單審批功能測試用例

功能測試用例經理審批訂單

功能描述此功能用于經理審批通過營銷部提交審批的訂單

測試用例審批通過訂單

測試預期結果提示審批成功，客戶端訂單管理界面訂單狀態更新為“待財務確認”。

測試實際結果進入經理訂單審核界面，點擊操作，彈出提交審批的客戶訂單信息界面，點擊審批通過，提示確認成功，財務端訂單管理界面顯示該項待審批訂單，客戶查看訂單列表界面該訂單處理進度更新為“待財務確認”。

表 6.9 訂單審批功能測試用例

功能測試用例經理審批售后

功能描述此功能用于經理審批通過營銷部提交審批的客戶售后申請

測試用例審批通過售后

測試預期結果提示審批成功，客戶端訂單管理界面訂單當前狀態更更新為“審批通過”。

測試實際結果進入經理售后審核界面，點擊操作，彈出提交審批的客戶售后申請信息界面，點擊審批通過，提示確認成功，財務端訂單管理界面顯示該項待退款售后，客戶售后申請界面該訂單處理進度更新為“審批通過”。

6.3.6客戶端功能測試

表 6.10 產品列表下單功能測試用例

功能測試用例產品下單

功能描述此功能用于公司客戶在產品列表頁下單

測試用例客戶進入產品列表界面，選擇某產品，在下單界面輸入產品需求數量，點擊保存。

測試預期結果下單成功，訂單管理界面顯示該待確認訂單。

測試實際結果客戶進入蔬菜/水果產品列表界面，界面顯示所有蔬菜/水果產品的信息列表，選擇產品點擊操作，系統彈出產品下單界面，輸入產品需求量，確認下單，系統提示下單成功，查看下單界面顯示該筆下單記錄，且處理進度為“待確認”，營銷端查看訂單列表頁新增顯示該待確認訂單。

表 6.11 售后申請功能測試用例

功能測試用例申請售后

功能描述此功能用于公司客戶提交售后服務申請

測試用例員工進入售后申請界面，查看歷史售后申請記錄信息，點擊新增，在提交申請界面輸入訂單號，產品名稱，漏發/破損產品量，破損程度，上傳圖片證明，選擇解決方案（退款/補發），申請人姓名，聯系電話，點擊提交售后申請。

測試預期結果系統提示提交成功，售后申請界面顯示該項待確認售后。

實際結果員工進入售后申請界面，點擊新增，系統彈出售后申請信息表單界面，員工輸入售后申請信息，點擊提交，系統提示提交成功，客戶端售后申請界面顯示該項售后，售后當前狀態為“待確認”，營銷端售后服務界面新增顯示該項待確認售后申請。測試通過。

6.4 測試結論經過對上述測試結果的分析，本此設計開發的農業公司果蔬批發信息管理系統具有針對公司批發業務的基本全面的功能，并且具備操作簡單、運行性能好等特點，可以投入實際的運營使用。

總結

在如今這個信息技術飛速發展的時代，農業企業化經營結合當代信息技術開展工作對企業來說是一個全新的發展方向。企業經營方式的信息化對企業來說是一次全新的大膽的嘗試。由于公司業務操作人員生產基地當地農戶，由于認知的局限性，對于信息技術的陌生感均會導致企業信息管理系統投入實際使用收到阻礙。因此，系統的功能操作界面必須盡可能設計得簡潔易懂。本文通過分析貴州黔北富民現代農業科技有限公司的管理組織結構以及批發業務的實際處理情況，采用面向對象分析與設計的方法對公司的果蔬批發信息管理系統進行開發，根本目的就是避免手工記錄操作導致的錯誤數據帶來的錯誤信息，進而造成公司的損失。通過信息技術處理公司業務，使公司員工職責更為清晰分明，大大提升對批發銷售的數據處理效率，降低業務管理的成本，提高工作效率。每名客戶交易全程平均處理時間縮短了近一周時間，節省了公司支付給業務員工一周的工作薪酬和時間成本，相當于每年為公司創造收益 43 萬元，并隨著業務量增加而逐年增加。

本文首先就選題背景、研究目的以及系統開發利用到的技術、所需的開發環境等進行分析概述，然后在分析公司業務處理流程的基礎上，進行系統的需求分析進而研究設計系統的技術架構以及靜態結構，利用 Process On 設計系統部分 UML 模型，最終以 ER 圖呈現系統數據庫中實體間的關聯關系，并設計數據庫中表的包含字段的二維表以呈現表結構。

目前，該果蔬批發信息管理系統正在公司內部進行試用，該系統基本能夠滿足批發業務的功能需求。但是，系統的功能與技術實現還是存在問題與不足。一方面是客戶下單問題，其中涉及的付款方式需要調用微信、支付寶與銀聯接口，涉及到與第三方的合作協商以及付費問題，因此沒有在系統中實現這一功能。另一方面主要是部分功能模塊仍有改進之處，前期開發時間以及技術所限，未能對部分功能進行全方面的設計實現。比如，本系統中對于公司果蔬產品的管理僅限于產品信息的增刪改查，對于產品入庫之前在生產基地中的種植培育未能設計實現對應的管理功能模塊。對于氣調庫的庫位管理未能實現出租功能以及庫位的平面圖展示。針對以上問題，本人后期會繼續進行詳細的設計與實現，完善系統功能，使系統更為完整，能實際地充分地滿足公司業務處理功能的需求，更為具體地解決公司實際人為處理信息的問題。

參考文獻

[1]李忠雙.堅持農業農村優先發展加快推進農業農村現代化[J].新長征,2021(02):22-23.

[2]蔡麗麗.精準扶貧背景下農產品營銷模式探討J].商展經濟,2020(14):75-77.

[3]丁亮.中國農業信息化與現代農業化協調發展研究[D].西北農林科技大學,2016.

[4]姜仕貴“龍頭企業+合作社+農戶”組織方式創新研究一以貴州省黔西南州為例J].黨政干部論壇,2019(11):39-41.

[5]施國斌.基于.NET農產品批發市場信息發布系統的設計與實現[D].吉林大學,2014.

[6]吳宇軒.互聯網品流通新+背景下農產模式構建研究[D].首都經濟貿易大學,2017.

[7]王雨晨.農產品批發市場管理信息系統的設計[D].河北科技師范學院,2016.

[8]霍彥臻.農業企業營銷策略研究一以山西冠霖農業科技有限公司為例J].山西農經,2019(11):131.

[9]LIANG W.An empirical research on poor rural agricultural information technology services to adopt[J].Procedia Engineering,2012(29):1578-1583.

[10]HAMID ElB,MOHAMMAD SA.Transition towards sustainability in agriculture and food systems:Role of information and communication technologies[J].Information Processing in Agriculture,2018(5):456-464.

[11]巫云仙，張春華.企業史視野下美國農業企業化及其經營特點和啟示[J].世界農業,2020(03):99-106.

[12]Martin Fowler, Kendall Scott. UML精粹(第2版)標準對象建模語言簡明指南[M].徐家福譯.北京：清華大學出版社，2002.

[13]Dorodnykh N O,Nikolaychuk O A,Yurin A Y. Using UML class diagrams for content ontology design patterns engineering[J]. Journal of Physics: Conference Series,2021,1801(1).

[14]李波，楊弘平,呂海華，史江萍,代欽.UML2基礎、建模與設計實戰[M].北京：清華大學出版社， 2014.

[15]Grady Booch, James Rumbaugh, Ivar Jacobson. UML 用戶指南(第 2 版•修訂版)[M].邵維忠，等譯. 北京：人民郵電出版社， 2013.

[16]劉秋香，劉振偉.淺析幾款主流的UML建模工具[J].電腦知識與技術.2018.14(32): 245-253.

[17]朱二華.基于Vue.js的Web前端應用研究[J].科技與創新,2017(20):119-121.

[18]王志任.基于Vue.js的開發平臺的設計與實現[D].廣州：廣東工業大學,2018.

[19]張新朝,霍冰鵬.基于AJAX的數據跨域傳輸技術分析[J].晉城職業技術學院學報,2020,13(02):72-74.

[20]周柱，郎朗.Ajax技術在B/S架構中的數據傳輸應用研究[J].新余學院報,2016,21(03):109-113.

[21]覃雷.計算機軟件開發中軟件工程方法的運用[J].電子世界,2020(18):62-63.

[22]吳文慶，修雅慧.基于軟件工程方法在軟件開發中的應用研究[J].科技資訊,2018,16(15):31+33.

[23]朱希敏.基于關聯分析的農產品銷售管理系統的研究與設計[D].重慶三峽學院,2019.

[24]Bagsby D L. Distributed computer system for telecommunications operational support: US, US8700753 B2[P]. 2014.

[25]Brannen S H, ColyerA M, Harrop R, et al. Computer system and a method of deploying an application in a computer system: US, US8997089[P]. 2015.