熱門論文
最新論文
基于Node.is的物流信息 管理系統的研究與實現
發布時間：2022-12-24 11:13
目錄
第一章緒論 1
1.1研究背景及意義 1
1.1.1研究背景 1
1.1.2研究意義 1
1.2國內外研究現狀 2
1.2.1國外研究現狀 2
1.2.2國內研究現狀 3
1.3主要創新點 3
1.4研究內容與論文組織結構 4
1.4.1研究內容 4
1.4.2論文組織結構 4
1.5本章小結 5
第二章關鍵理論與技術概述
6
2.1概述 6
2.2Node.js 技術 6
2.2.1Node.js 基礎架構 6
2.2.2Node.js的運行機制 7
2.2.3Node.js 的特點 8
2.3MongoDB數據庫技術 8
2.3.1MongoDB 及其特性 8
2.4WebSocket 通信協議 9
2.4.1WebSocket 原理簡介 9
2.4.2WebSocket在本研究中的優勢 10
2.5單頁Web應用相關技術 11
2.5.1單頁 Web應用介紹 11
2.5.2Vue框架介紹 11
2.6遺傳算法 12
2.6.1遺傳算法簡介 12
2.6.2遺傳算法原理分析 13
2.6.3遺傳算法的優點 14
2.7本章小結 14
第三章系統需求分析 15
3.1概述 15
3.2可行性分析 15
3.2.1技術可行性分析 15
3.2.2操作可行性分析 16
3.2.3經濟可行性分析 16
3.3系統業務流程分析 16
3.4系統非功能性需求分析 17
3.4.1安全性 18
3.4.2可靠性 18
3.4.3易維護性 18
3.4.4易擴展性 18
3.5系統功能性需求分析 18
3.5.1系統管理 19
3.5.2采購管理 19
3.5.3倉儲信息管理 19
3.5.4入庫管理 20
3.5.5出庫管理 20
3.5.6盤點管理 21
3.5.7調撥管理 21
3.5.8配送管理 21
3.6本章小結 22
第四章系統總體設計 23
4」概述 23
4.2系統整體結構設計 23
4.3系統總體技術架構設計 25
4.3.1后端接口設計 25
4.3.2前端系統框架設計 25
4.4系統功能模塊設計 27
4.4.1用戶管理模塊設計 27
4.4.2單據管理模塊設計 28
4.4.3采購管理模塊設計 28
4.4.4貨位管理模塊設計 29
4.4.5庫存商品管理模塊設計 29
4.4.6入庫管理模塊設計 30
4.4.7出庫管理模塊設計 30
4.4.8盤點管理模塊設計 31
4.4.9調撥管理模塊設計 32
4.4.10配送管理模塊設計 33
4.5系統數據庫設計 33
4.5.1概念設計 33
4.5.2數據庫文檔設計 38
4.6木章小結 42
第五章系統實現 43
5」概述 43
5.2系統總體架構實現 43
5.2.1后端架構實現 43
5.2.2前端系統架構實現 44
5.3系統功能模塊實現 44
5.3.1登錄功能實現 44
5.3.2用戶管理模塊實現 45
5.3.3采購管理模塊實現 45
5.3.4貨位管理模塊實現 47
5.3.5庫存商品管理模塊實現 47
5.3.6入庫管理模塊實現 48
5.3.7出庫管理模塊實現 48
5.3.8盤點管理模塊實現 49
5.3.9調撥管理模塊實現 50
5.3.10配送管理模塊實現 51
5.4基于遺傳算法的揀貨路徑優化實現 52
5.4.1問題描述 52
5.4.2揀貨路徑優化的數學模型 53
5.4.3遺傳算法設計 55
5.4.4算法實現與分析 57
5.5本章小結 59
第六章系統測試 60
6.1概述 60
6.2測試環境 : 60
6.3功能測試 60
6.3.1ATF自動化測試系統介紹 61
6.3.2ATF測試系統測試步驟 61
6.4性能測試 65
6.5本章小結 66
第七章總結與展望 68
7.1總結 68
7.2展望 68
參考文獻 70
致謝 72
作者攻讀學位期間發表的學術論文目錄 73
第一章緒論
1.1研究背景及意義
1.1.1研究背景
自從國家實行改革開放政策以后，中國的經濟實現了持續飛速發展，物流業 也取得了長足的發展，已經成為國民經濟中的重要支柱。2017年，我國社會物流 總額達到252萬億元，按可比價格計算，同比增長6.7%,增速比上年同期提高 0.6個百分點［I根據最新數據,2018年1-11月全社會物流總額為257.9萬億元， 預計全年同比增長6.5%,勢頭依然迅猛。
我國的物流行業雖然發展勢頭良好，但仍然存在很多問題，物流業的發展面 臨著嚴峻的挑戰。一方面，我國物流業規模巨大，但物流成本高昂，社會物流總 費用在GDP中仍占據較高的比重。很多物流企業，特別是中小企業的物流管理 方法和管理手段較為落后［2】，物流各環節信息化程度不高，信息溝通不及時，造 成庫存、運力浪費⑶，效率低下，成本高昂。另一方面，傳統的物流管理系統和 運作流程己經無法滿足現代物流業的要求。互聯網、大數據、云計算等技術的發 展，對于物流各環節的運作提出了更高的要求，只有及時的信息傳遞、高效的信 息處理和海量的數據存儲才能滿足現代物流的要求。
對于企業來說，經營和管理成本的增加，使企業無法專注于自身的核心業務, 發展受到束縛。而先進、合理、完善的物流信息系統有助于實現物流各個環節之 間的信息的快速傳遞，提高物流企業對采購、運輸、配送等業務的處理能力，從 而提高企業的服務水平，降低企業的經營成本，增強企業的綜合競爭力。對于社 會和整個行業來說,物流企業的信息化水平偏低，物流管理理念和管理水平落后, 嚴重阻礙物流業的發展，也造成了社會資源的浪費。國務院于2014年印發的《物 流業發展中長期規劃(2014-2020)》文件中，明確地將降低物流成本列為發展重 點，要求物流企業采用現代物流管理理念，提高物流服務能力，加快企業物流信 息系統建設⑷。因此為了提高效率，降低成本，優化服務效果，節約社會資源, 提高企業生存能力，企業迫切需要從自身生產經營出發，建立滿足自身發展需要 的信息管理系統，提高物流管理的信息化管理水平。
基于以上背景，針對一家小型電商企業的具體業務需求，從實際需求出發, 研究并設計了一套基于Node.js的物流信息管理系統。該電商當前的物流信息管 理方式較為落后，倉儲管理未實現完全信息化,運輸配送等環節也存在效率低下、 資源浪費、信息傳遞不及時等問題。
1.1.2研究意義
據中科院預測中心預計，2019年社會物流總費用與GDP比重降至14%左 右，但仍遠遠高于發達國家,我國物流業面臨著降低成本、提高效率的嚴峻問題。 對于該電商企業來說，落后的信息管理模式造成了人力成本增加，信息溝通不及 時，服務質量低下等問題，不利于企業的綜合競爭。本文針對當前存在的問題, 為該電商企業研究并設計了基于Node.js的物流信息管理系統，具有以下重要意 義：
(1)提高物流各環節的管理效率，降低企業成本。
物流過程具有采購、倉儲、運輸、配送等多個環節，期間伴隨著商品流以及 “信息流”。每個環節都需要相應職責的管理人員進行商品的操作和信息的處理。 一個擁有完整體系的電商物流系統，可以大大地降低運營的成本，提高效率⑸。 本文所研究設計的信息管理系統能大大加快工作人員的處理速度，防止處理過程 中的紗匕漏，從而降低人力成本，減少物流環節的商品損耗，降低企業的經營成本。
(2)技術選型更加合理，促進先進技術的融合與應用。
隨著大數據、云計算、智能化集成等技術在物流業的應用越來越廣泛，物流 行業己經進入了智能物流時代⑹。智能物流要求“信息流”必須及時根據商品流 的更新而更新，必須將物流全過程的每個環節接入網絡，快速地將信息傳遞給各 個處理單元進行處理，然后實時地將結果反饋給其他相應環節，最后將大量的信 息數據存入數據庫等存儲設備。本設計選用了更加合理的后臺開發技術、前后端 通信技術以及數據存儲技術，將會大大促進先進技術在物流中的融合與應用。
(3)促進整個行業降本增效。
物流企業的信息化、智能化發展，是整個物流產業進步的基石。隨著每個物 流企業管理水平的提高，管理效率的增加，整個行業的信息化、智能化水平也會 提高。本設計具有易部署、易使用、便于企業二次開發的特點，維護成本低，大 大降低了企業特別是中小型企業的使用門檻，對于整個行業提高信息管理水平, 達到降本增效的目的，有著十分重要的意義。
1.2國內外研究現狀
1.2.1國外研究現狀
物流信息化在現代物流發展中扮演者重要角色，是現代物流的靈魂，也是現 代物流發展的必然要求和基石〔I國外特別是西方發達國家的信息技術起步較早, 發展較快，因此這些國家的學者很早便已開始了對物流信息管理的研究。
在物流信息管理系統的理論研究方面，Sethanan 在供應鏈的相關理論基 礎上，深入研究了基于供應鏈的物流信息管理系統中的資源共享、信息采集等問 題。MasmoudiM〔9］著眼于電子商務中的物流系統應用，其在分析了電子商務整體 環境與物流系統的關系的基礎之上，設計了關于電子商務的物流配送信息管理系 統框架。Kiessling Ta】等人研究了供應鏈協調發展的理論，設計了一個供應鏈協 調發展的物流信息管理系統，其在設計物流系統的過程中，在架構設計、功能設 計方面更關注系統之間的協調關系。
在物流信息管理系統的應用方面，隨著多年的研究與發展，物流信息管理系 統不斷成熟，在實踐中取得進步和完善，以美國、加拿大等國家為代表的西方國 家已經擁有了成熟的物流信息管理系統。美國的先進物流公司，已經可以根據客 戶對服務速度與質量的差異性需求，采取以陸、海、空等不同物流方式來為用戶 制定個性化的服務方式［⑴。這種服務模式是一種較為高級的高端定制服務模式， 其對物流公司的管理水平和物流過程的監控提出了非常高的要求，這也表明了美 國國內的物流企業，其物流信息管理已經達到了很高的水平。在全球范圍內，大 多數世界五百強企業己經配備了完整的信息化管理系統，可以實現對商品物流過 程的智能處理［啦131，［14］。
可以看出，發達國家的信息技術和物流業起步早，發展快，經過多年的研究 與發展，其物流信息管理水平己經相對成熟，先進的物流信息管理系統的應用也 十分普遍。
1.2.2國內研究現狀
與西方發達國家相比，我國的信息技術發展較晚，物流行業的信息化和智能 化發展也因此遠遠落后于發達國家。雖然近年來我國經濟經歷了騰飛式的發展進 程，但是物流業與發達國家發展的大差距是不爭的事實［⑸。近年來，為了推動國 家物流業向信息化、智能化發展，縮小與發達國家的差距，國內學者開始對物流 信息管理進行研究。
在理論研究方面，吳金椿（2001年）提出了物流管理信息化的理論，并認為物 流信息管理系統應該具有信息的可得性、信息的精確性、信息的及時性等特征； 肖蕾（2002年）分析了第三方物流企業信息管理系統建設的必要性，提出第三方物 流應具有信息化、網絡化、智能化、柔性化的特征，并提出了第三方物流企業信 息系統建設的設計方案和關鍵技術；趙文霞、董學杰等（2004年）提出將GIS/GPS 和可視化技術應用于物流信息管理系統；王曉思、孫靜（2013年）研究了基于云計 算和RFID技術的農產品物流信息系統，提出利用云計算平臺、RFID等先進技 術構建物流信息管理系統。
在設計開發方面，凌大榮等（1998年）在分析了經典物流信息管理系統具有缺 乏信息透明度、信息流通不及時等局限性后，提出了面向Web技術的物流信息 管理系統；其后隨著.NET、J2EE等IT技術的發展，基于B/S架構或C/S架構的 物流信息管理系統得到了廣泛應用；王真瓊（2009年）針對Web Service技術在物 流信息管理系統中的使用做了研究并提出設計方案。2010年以后，國內關于物 流信息管理系統的研究與設計的文獻如雨后春筍般涌現，大都是基于B/S架構和 J2EE技術而設計的。在此期間，RFID技術、GIS/GPS技術、可視化等技術在物 流信息管理中的應用也越來越成熟。
可以看出，我國物流業起步雖晚，但新世紀以來發展迅猛，物流信息管理也 得到了飛速發展，國內學者對此的研究水平逐漸提高，理論更加成熟，為物流企 業的信息化、智能化提供了巨大的幫助。但從近幾年研究文獻也可以看出，關于 物流信息管理系統的研究理論進步緩慢，創新性不足，對于新技術的嘗試和使用 熱情不高。
1-3主要創新點
基于上述背景與研究現狀，本文提出了基于Node.js的物流信息管理系統的 研究與設計方案，與當前大多數物流信息管理系統不同，本系統將采用Node.js 技術作為后端開發語言，采用Vue作為Web頁面的開發框架，同時引入 WebSocket通信協議作為信息交互的渠道，具有以下創新之處：
(1)使用Node.js,加快物流各個環節中的信息傳遞，使溝通更加及時、快速， 并降低物流企業的服務器維護成本。
(2)使用Vue.js降低物流企業對系統進行開發以及二次開發時的人力成本和 時間成本。
(3)使用遺傳算法對揀貨路徑進行優化，使倉儲工作人員能夠快速處理取貨 請求，提高工作效率，進而提高用戶滿意度。
1.4研究內容與論文組織結構
1.4.1研究內容
基于上述研究背景和國內外研究現狀，針對一家小型電商企業的具體業務需 求，從實際需求岀發,本文研究并設計了一套基于Node.js的物流信息管理系統。 本系統具有采購管理、倉儲管理、運輸管理等功能，可以改善該物流企業的信息 管理現狀，達到提高效率，降低成本，提升客戶滿意度的效果。本文的主要研究 內容分為以下幾個方面：
(1)關鍵理論和技術介紹
不同于當前常見的物流信息管理系統，本文研究并設計的管理系統使用了當 前流行的新型技術，以求達到提高管理水平、提升系統性能、加快信息傳遞與處 理的目的。本文將重點介紹信息管理系統開發所采用的Node.js技術和Vue框架， 存儲數據所使用的MongoDB技術，以及決策系統所采用的算法理論。
(2)系統需求分析
本文針對該電商企業的具體業務場景和當前的管理流程中存在的各種問題, 對具體的業務需求進行了詳細的分析，并按照功能性需求和非功能性需求分別闡 述了本系統所需要滿足的功能。
(3)系統功能模塊設計
在進行了全面的需求分析之后，針對需求分析中所提出的功能與要求，該部 分首先從宏觀上對整個系統架構做了完整的設計，然后又對每個功能模塊做了詳 細的設計，包括模塊功能設計、數據庫設計、前后端通信接口設計等。
(4)系統功能模塊實現
基于對系統功能模塊詳細的設計，本部分詳細描述了如何實現物流信息管理 系統的各個部分。本實現部分的內容包括每個頁面具體的功能以及所涉及到的前 后端通信的接口實現。最后本部分給出了最終實現的界面效果。
(5)系統測試
在實現了本文中所提出的所有功能之后，本部分詳細描述了對本系統做出的 測試工作，包括測試方法、測試內容以及測試結果分析，以保證本物流信息管理 系統能被正式投入使用。
1.4.2論文組織結構
本文的組織結構如下：
第一章緒論。介紹了本論文研究的背景及意義，通過查閱相關資料敘述了 當前關于物流信息管理系統的國內外研究現狀，敘述了本課題的創新點，并對本 文的主要研究內容和組織結構做了介紹。
第二章關鍵理論與技術。對本設計所涉及并使用的關鍵理論進行詳細論述 與介紹，重點分析了這些理論與技術的優勢所在。
第三章系統需求分析，對系統的整體需求和各個功能模塊的功能需求做出 詳細的分析。
第四章系統總體設計。在明確了整個系統的功能目標之后，對整個系統及 各個功能模塊做全面、詳細的設計。
第五章系統實現。基于整個系統的設計，使用Nodejs、MongoDB等相關 理論和技術，對物流信息管理系統做出實現，并給出實際效果展示。
第六章系統測試，本章介紹了軟件測試的基本方案，對整個系統做出功能 性測試和性能測試，以確保物流信息管理系統完成了系統設計的目標。
第七章總結與展望。本章對本文所做的工作進行全面的分析與總結，敘述 了本研究所具有的特點和不足，并對日后的研究方向和重點做出展望。
1.5本章小結
本章首先介紹了當前我國物流行業信息管理的現狀，指出了當前存在的問題。 在此背景下，介紹了進行本研究的重要意義和作用。隨后針對論文的研究內容， 說明了當前國內外研究的一般現狀，指出我國目前的研究與國外發達國家的差距。 隨后，論文從技術選型和系統功能角度，介紹了課題的創新之處。最后論文從整 體上介紹了論文的研究內容與組織結構。
第二章關鍵理論與技術概述
2.1概述
中國物流行業雖然發展勢頭良好，但是依然存在信息管理理念落后，信息化 水平較低，管理成本過高的問題，在此背景下，本文研究的系統具有信息化水平 較高、成本低廉、適合企業的特點，對物流企業具有重要的意義。本章將重點介 紹系統研究與實現過程中使用到的各種關鍵算法與技術，包括遺傳算法的原理、 Node.js關鍵技術、MongoDB數據庫技術等。
2.2Node.js 技術
近年來,NodeJs的發展，為Web研發模式帶來了新的解決思路t16-17kNode.js 是基于Google Chrome瀏覽器V8引擎構建的一個JavaScript運行環境〔罔，它保 留了 JavaScript語言的核心語法，去除了依賴于瀏覽器的DOM、BOM,這使得 原本只能運行于瀏覽器的JavaScript語言能夠運行在服務端,進行諸如文件操作、 網絡編程等任務。Node.js可以直接創建一個Web服務器，接收用戶的請求，進 行處理，并返回結果給用戶。Node.js使用C++語言編寫，這保證了 Node.js具有 較高的運行效率;Node.js運行在V8引擎之上,V8引擎保證了 Node.js的性能〔切。
2.2.1Node.js基礎架構
Google Chrome瀏覽器的V8引擎是當前最快最高效的JavaScript解析引擎。 Node.js的核心是一個獨立的封裝了 V8引擎的JavaScript虛擬機〔絢，Node.js在 實際運行時，運行的是底層的C++代碼，然后由C++代碼來調用V8引擎暴露出 的API接口。此外，Node.js還使用了高效的Libuv庫支持事件驅動和異步式 I/0[21]o
Node.js的架構如圖2-1所示，Node.js由底層的Libuv異步I/O模型庫和V8 引擎、C++模塊以及JavaScript模塊組成。
其中，Node.js的底層由V8引擎和Libuv組成。V8引擎負責JavaScript代碼 的解釋與執行，他為上層C++模塊提供API接口； Libuv用于為Node.js提供高 效的事件驅動和異步I/O機制。Libuv是Libeio/Libev和IOCP的抽象封裝，其 中，Libeio/Libev是用于為在Linux平臺的Node.js提供異步I/O, IOCP是為 Windows平臺提供異步I/Oo Libuv為開發者提供了跨平臺的統一的API調用。
C++模塊部分是由C++代碼實現的基于底層V8引擎和異步I/O的核心模塊 部分，該部分封裝了諸如網絡模塊net、字節操作模塊buffer,進程操作模塊等功 能模塊，以供上層JavaScript模塊調用。C++語言的高效性保證了該部分功能模 塊的高效性，這也是Node.js高效運行的基礎。
JavaScript模塊部分是由JavaScript語言實現的功能模塊，該部分通過調用下 層的C++模塊，封裝了一系列服務端編程所使用的功能函數，供Node.js使用者 來調用。這些模塊在使用時不需要額外加載，而是在Nodejs開始運行時便加載 到內存中。
JavaScript 模塊 http https fs
C/C++模塊 net buffer fs
Libuv
V8引擎
Libeio Libev IOCP
圖 2-1 Node.js 架構
2.2.2Node.js的運行機制
Node.js是基于事件驅動和異步I/O機制而運行的，如圖2-2所示。Node.js 將JavaScript代碼傳給V8引擎解釋并執行。程序開始執行后，便會初始化一個 事件循環機制，即Event Loop,此后程序給所有的異步任務，如網絡請求、文件 讀取等，設置完成后的回調函數，并將其分給不同的工作線程去執行。一旦異步 任務處理完成，便會將回調函數添加到事件隊列Event Queue, Event Loop會依 次循環地讀取事件隊列中的事件，將異步任務的返回結果傳入到回調函數中，根 據代碼進行相應的處理。
圖2-2 Node.js運行機制
2.2.3Node.js 的特點
如前文所述，Node.js是基于事件驅動和異步I/O機制而運行的。Node.js的 任務基本上都是以異步的形式執行的，而異步任務完成后的行為則由異步任務調 用時的回調函數來決定。Node.js的底層Libuv保證了這個機制在所有平臺包括 Linux和Windows上都可以運行。可以看出Node.js相比其他的服務器端語言， 有以下四個特點：
(1)異步I/O:以異步的方式進行I/O等操作，后續的任務可以不等待前面的 任務完成即可執行，這就可以保證后續任務的及時執行，并且能夠在異步 任務完成后，通過回調函數正確處理異步任務的結果。這樣既能使請求處 理更加及時，又保證了多任務執行的高效性。
(2)事件驅動模型：Node.js借鑒了在瀏覽器中廣泛應用的事件處理機制，許 多任務的執行依靠事件的發生來驅動，這樣的編程方式具有輕量級、松耦 合、只關注事務點等優勢〔22〕。
(3)單線程：Node.js在運行時只有一個主線程，所有的任務都將在此線程中 處理完成，這就避免了多線程語言中具有的狀態同步、死鎖、切換線程開 銷大等問題。同時，為了充分利用多核CPU的計算能力，Node.js引入了 子進程機制，允許用戶將任務分發給多個子進程處理，加快了處理速度。
(4)跨平臺：Node.js的異步I/O由Libuv實現，而Libuv封裝了 Linux平臺和 Windows平臺的異步I/O機制，這就使得Node.js可以在多個平臺無差別 運行。
基于以上特點，Node.js更適用于構建高并發、I/O密集型的Web應用，它 成為了開發快速、可擴展的Web應用的完美工具［23】。Node.js另外一個特點是, 它允許用戶統一使用JavaScript來編寫瀏覽器端和服務端代碼，能夠有效地提高 開發效率。
2.3MongoDB數據庫技術
2.3.1MongoDB及其特性
MongoDB是由C++編寫而成，是面向文檔的數據庫，是一個介于關系型與 非關系型之間的數據庫［2習。
在底層存儲方面，MongoDB基于分布式文件，以高效的二進制形式對數據 進行存儲。MongoDB中的數據以BSON(Binary JSON)的格式存在，這種格式結 構非常松散，與JSON數據十分相像。MongoDB支持完全索引，可以在包括內 部對象的任意屬性上建立索引。
在宏觀層面，MongoDB以集合和文檔的形式存儲所有的數據。一個數據庫 中有多個集合，類似于MySQL中的數據表，每一類的數據存儲在一個集合中， 集合中的每條數據都以文檔的形式存在。與MySQL不同的是，集合中的文檔不 必有固定的格式，隨時可以通過編程的方式存入不同的BSON數據。
MongoDB采用BSON格式的文檔存儲數據，這種格式與JavaScript中的 JSON數據格式十分相似，所以其支持嵌套數據，即某個屬性存儲的數據可以為 對象或者數據，并且數組中也可以存儲對象。如對于本系統中的商品數據，商品 包含有編碼、名稱、數量和存儲位置等信息，其中每個商品具有多個存儲位置, 所以該屬性存儲的是一個數組數據。數組中存儲的也是對象格式的數據，包含有 通道、貨架、列、層、數量等屬性。在傳統的關系型數據庫如MySQL中無法這 樣存儲，但是MongoDB中卻可以方便的存儲這樣的數據。其文檔數據表示如圖 2-3所示：
{
"unicodeCode": 2888473749506,
"goodsName": ■■讎範本電腦；
"account": 10,
"position":[
{'line■: T5： "shelf: "A； "col": ”4； "layer": ”13"},
{-line*: "15*, “shelf": "A； "col": “4； "layer": "14"},
]
}
圖2-3 MongoDB文檔數據結構
根據MongoDB的特點，其適用于以下場景：
(1)實時的數據更新與查詢應用場景[26];
(2)對數據格式不固定的對象及JSON數據的存儲;
(3)海量數據的存儲。
2.4WebSocket通信協議
2.4.1WebSocket 原理簡介
WebSocket通信協議誕生于2008年，在2011年成為國際標準，它是一種基 于TCP的持久化的網絡通信協議。與傳統的HTTP協議不同，WebSocket可以 在通信雙方之間建立一條持久鏈路，此后，通信雙方就可以在此鏈路上發送信息。
如圖2-4所示，客戶端和服務器使用傳統的HTTP協議進行通信時，每進行 一次信息傳遞，客戶端都需要發起一次通信請求，然后由服務器返回相應的響應 信息。這樣的通信模式有兩個缺點：
(1)多次進行連接的建立與釋放耗費資源較多；
(2)只能由客戶端發起通信請求，服務端無法主動向客戶端發送請求。
客戶端與服務端使用WebSocket進行通信時，瀏覽器端先發岀一個建立連 接的握手請求，然后服務器端返回握手信息，瀏覽器端驗證握手信息，如果信息 匹配說明服務器端支持WebSocket協議，那么就可以建立連接W 此后，客戶端 與服務端便可以進行雙向通信。通信結束時，由某一方發起斷開連接的請求，通 信鏈路就會斷開。
圖2-4 WebSocket與HTTP協議通信區別
WebSocket通信協議具有以下特點：
(1)支持文本和二進制數據；
(2)支持雙向通信，允許服務端主動向客戶端發送信息；
(3)數據格式較為輕量，性能好，通信效率高；
(4)不受同源策略的影響，瀏覽器可以和任何服務器進行信息交換。
2.4.2WebSocket在本研究中的優勢
如前文所述，WebSocke通信協議主要用于解決當前HTTP協議無法實現雙 向通信且資源消耗大的問題。在本研究中應用WebSocket通信協議能發揮出其 雙向通信、高效的優勢。
在物流信息管理系統中，需要客戶端與服務器實時保持連接并進行通信，來 將物流系統中的信息實時展示給管理人員，讓管理人員能及時了解物流中物品的 轉移情況。在傳統的物流信息管理系統中，通常使用Ajax輪詢的方式進行物流 信息的實時展示。這種方式使用HTTP通信協議，由客戶端每隔一定時間主動向 服務器請求一次數據，如果有新的信息產生，就會將信息返回給客戶端。這樣做 的缺點就如下：
(1)信息展示不及時。輪詢并不能做到服務器有了新的物流信息就及時展示 在客戶端界面上，而是由客戶端每隔一段時間去查詢有沒有新的物流信 息，這樣就會有信息更新的延遲。
(2)浪費資源。客戶端每次發起請求，都要建立HTTP連接。即使使用新的長 連接，由于HTTP協議的頭部所含信息較多，也造成了一定的浪費。
WebSocket通信協議非常好地解決了這兩個缺點。雙向通信的特點使得服務 器可以主動向客戶端推送信息，保證物流信息發生變化時，管理人員能第一時間 知曉，也有利于其他終端利用這些信息來進行規劃與預測。WebSocket通信協議 無需反復建立連接，并且通信時的頭部非常小，大約只有2Bytes,這極大地節約 了網絡資源，提高了通信效率。因此在本研究的部分通信中使用WebSocket協議 來替代傳統的HTTP協議，能大大提高物流信息管理的性能，有利于管理人員和 其他人員與設備及時進行相應的工作。
2.5單頁Web應用相關技術
2.5.1單頁Web應用介紹
伴隨著Web前端開發技術的發展，單頁Web應用(SPA)成為了當前十分 火熱的Web前端開發技術PS】。SPA是Single Page Application的縮寫，即單頁 應用技術。現在許多大型公司，如Facebook、Google、阿里巴巴等公司都在其網 站中使用了 SPA技術。SPA應用是一種特殊的Web應用，它將所有的活動局限 于一個html頁面中［29〕。SPA應用在與用戶交互時，不需要向服務器端請求新的 頁面，而是通過Ajax技術，向服務器請求新的信息，然后改變頁面的局部界面。 以物流信息管理系統的倉儲信息列表為例，當需要根據服務器的最新信息來更新 當前的列表時，傳統的網頁應用會將需要獲取的列表以參數的形式發送給服務器 端，然后服務器端返回一個新的頁面，以供用戶查看。而在SPA應用中，只需 要利用Ajax技術向服務器發送請求，并帶上所需要獲取的列表信息，服務器收 到請求會把新的列表信息返回給瀏覽器，利用JavaScript將列表信息進行動態更 新。
傳統的網頁應用每次更新信息都會刷新一次頁面，具有以下問題：
(1)服務器端任務較重。前端只是作為展示頁面，所有的邏輯處理都放在了服 務器端。這導致了服務器端開發人員任務重，開發慢、服務器負擔重。
(2)用戶體驗差。重新加載整個頁面會造成卡頓的現象，重新加載的頁面與之 前的頁面很難高度一致，這也給用戶造成了不好的體驗。
利用SPA技術來開發Web應用，可以非常好地解決上述問題，給用戶帶來 類似于本地應用的流暢體驗，不需要重新請求頁面，也可以減少數據請求，加快 界面的更新速度。在物流信息管理系統中，有大量的信息需要以圖表的形式進行 展示，并且有的頁面包含有多張圖表，使用SPA技術進行開發，能以最流暢的 形式進行頁面圖表的動態更新，給管理人員最佳的用戶體驗。
當前，眾多的前端框架都是基于SPA技術打造Web應用的，如React, Vue, Angular等。這些框架支持基于組件化的開發模式，并且包含模塊化系統、路由 管理、狀態管理等高級功能，能夠使開發人員快速進行開發，大大減少物流信息 管理系統開發的人力成本和時間成本。本研究在對比了眾多前端SPA框架之后， 選擇了 Vue作為前端開發的框架。
2.5.2Vue框架介紹
Vue是一個用于創建用戶界面的開源JavaScript框架，也是一個創建單頁應 用的Web應用框架。
Vue基于組件化和MWM模式進行Web界面的構建，其輕量級、高性能、 靈活性的特點，使其不僅適用于大型復雜的Web應用，而且適合移動場景a〕, 應用范圍十分廣泛。
如前文所述，單頁應用不會刷新當前頁面，而是通過動態更改web界面的布 局與內容來與用戶進行交互，這種方式避免了傳統web應用切換頁面導致用戶 體驗變差的缺點。在此原理之上，Vue將大型應用切割成小而獨立的、可復用的 組件，通過多級組件層層嵌套，構建完整的用戶界面。
如圖2-5所示，整個Vue應用以組件樹的形式搭建而成。開發時，將頁面分 割為幾個具有明顯特征的組，然后將這些組以組件的方式構建出來。為了使頁面 結構更加清晰，減少頁面某一部分對其他部分的影響，一個大的組件也可以拆分 為一個個子組件。
圖2-5 Vue組件樹模型
Vue框架具有的另一個特性就是基于MWM模式的響應式原理。傳統的 Web開發在更改界面時，需要在代碼中找出需要更改的界面元素，然后將數據應 用到元素中。但是在Vue構建的應用中，得益于MVVM模式，我們只需要在初 始化的時候將視圖與數據進行綁定即可。當需要更改視圖時，只需要更改視圖所 綁定的數據，Vue內部原理即可檢測到這一變更，然后對視圖進行更改。
2.6遺傳算法
2.6.1遺傳算法簡介
遺傳算法(GA,Genetic Algorithm)也稱進化算法，是由美國Michigan大學的 Holland教授于1969年提出，其后由Dejong、Goldberg等人[31-32-33吩析總結出 的一種智能優化算法。根據達爾文的生物進化論，生物種群在自然選擇、基因交 叉以及變異等進程中繁殖和成長，形成了生物進化的全過程[列。遺傳算法就是通 過模擬該過程而尋求最優解的。遺傳算法是一種高效、并行、全局搜索的方法, 能在搜索過程中自動獲取和積累有關搜索空間的知識，并自適應地控制搜索過程 以求得最佳解。
在生物進化過程中，種群是生物進化的基本單位，每種生物都是以種群為單 位開始進化的。在遺傳算法中，代表問題可能潛在的解集就形成了一個種群，通 常記為P(t),這里的t代表了進化的代數，也可稱為迭代次數。一般情況下，P(t) 中的元素的個數被稱為種群規模，其大小不會變化，常記為N。P(t)中的元素稱 為個體(或染色體)，記為齊(心2(。…和(r) [35]o
有了第一代種群，按照適者生存、優勝劣汰的原理，逐代進化得到越來越符 合要求的近似解。種群中的個體的適應度反映了個體所對應的解的好壞，適應度 越高，則該解越接近最優解。在種群的每一代中，按照個體的適應度的不同來選 擇個體，并通過交叉、變異，得到新的種群，也就是新的解集。種群中的個體經 過交叉或變異可以產生新個體。而個體通過變異也可以保持種群的多樣性。這個 過程會導致解集像種群中的自然進化一樣，后代解比前代解更加接近最優解，這 樣最后一代的解可以作為問題的近似最優解，也即我們要尋找的最優解。
2.6.2遺傳算法原理分析
遺傳算法的基本原理是將生物的遺傳與進化機制進行工程學上的模型化，算 法模擬了生物進化的過程，其包含的某些術語也都是與生物進化中的術語相同或 類似，將其術語列舉如下：
(1)編碼：編碼是一種轉換方式，將一個問題的可行解從解的空間轉移至遺傳 算法里去處理〔"I,需要將其改造為便于進行程序運算的串結構數據。
(2)初始群體：初始群體是指滿足問題要求的解的集合形成的種群，所有的進 化過程，如交叉、變異，都從該種群開始。
(3)適應度：種群中個體的適應度反映了個體對于環境的適應程度，也就是解 集中的解對于問題要求的符合程度。在遺傳算法中，通常會由一個適應度 函數來評估。適應度函數務必符合2個條件：非負；在優化進程里，目標 函數的變幻和群體進化過程里適應度函數變幻，兩者方向要相同a】。
(4)自然選擇：自然選擇模擬了生物進化中的自然選擇過程，它以某種方式從 種群中選擇一定量的個體保留下來。基本上選擇過程是一個以適應度為 標準的優勝劣汰、適者生存的過程。
(5)交叉：遺傳算法中，交叉是指把兩個父代個體的部分結構加以替換重組而 產生新個體的操作。在實現上，是將兩個編碼后的解進行組合交叉，一般 有兩步，一是對種群中的個體進行隨機配對。
(6)變異：遺傳算法中，變異是指將個體的部分特征進行隨機改變，體現在實 現上，即為將編碼后的解的某一部分進行隨機改變。變異的目的是增加種 群中個體的多樣性，克服遺傳操作可能限于局部最優解的缺點。
在算法執行過程方面，遺傳算法以問題的某些解組成的解集為初始種群，在 此基礎上，以適應度為基準進行種群的自然選擇，以及個體間的交叉、變異，不 斷產生新的個體。這樣逐代演化下去，直到滿足終止條件。
整個遺傳算法的執行過程如圖2-6示。
遺傳算法的具體執行過程描述如下：
(1)隨機產生一組初始個體組成初始種群，并評價每一個個體的適應度。
(2)判斷是否滿足算法收斂準則。若滿足則輸出搜索結果，否則執行以下步驟。
(3)根據適配值大小以一定方式執行復制操作。
(4)按照一定的概率執行交叉操作。
(5)按照一定的概率執行變異操作。
(6)返回步驟2。
圖2-6遺傳算法執行流程圖
2.6.3遺傳算法的優點
遺傳算法是一種非確定性的啟發式智能優化算法，具有較好的全局優化搜索 和魯棒能力，廣泛應用于科學領域，如數據挖掘、模式識別、搜索空間等。遺傳 算法的優點如下：
(1)遺傳算法原理簡單，可并行執行，適用于計算機進行大規模計算，尤其適 合處理傳統算法不容易處理的大型的、非線性組合的優化問題。
(2)遺傳算法的操作對象是對參變量進行編碼后生成的串數據，而非參變量 本身，其可直接對各種結構對象進行操作。
(3)遺傳算法使用概率變遷的方式作為在空間中搜索的準則，而不是使用確 定性規則。其以概率為工具進行啟發地搜索，具有明確的搜索方向。
(4)遺傳算法是從問題的一組解開始搜索最優解，而非從某個解開始尋找最 優解，即采用多條路徑來完成全局搜索，這樣尋找到全局最優解的概率最 大。
2.7本章小結
本章詳細描述了物流信息管理系統研究中涉及到的相關技術和理論。首先介 紹了本系統的基礎架構Node.js,分析了使用Node.js的特點以及其作為本系統的 后端語言的優勢；隨后依次介紹了 MongoDB數據庫、WebSocket通信協議、單 頁應用SPA技術的基本概念和原理，最后介紹了遺傳算法理論，并詳細分析了 其優點。
第三章系統需求分析
3.1概述
物流信息管理系統是物流企業為了及時、準確、全面地掌握整個物流過程中， 物品的轉移、物流信息的更新以及人員信息的更新等情況而使用的一種管理系統。 本論文在綜合、全面地考察了某電商企業的信息管理現狀，深入分析了其對于物 流信息的管理需求，并綜合考慮了企業的各種成本預算的基礎上，提出了開發一 套基于Node.js的物流信息管理系統的方案。
本論文研究的物流信息管理系統的目標是為物流企業、電商企業等提供全面 的信息管理功能，包括人員、庫存、貨物等相關信息的管理功能，提高信息管理 的有效性和準確性，減輕管理人員的工作負擔，提高物流工作人員的工作效率， 有效減少物流過程中出現的不必要的損失，降低物流企業和具有物流服務的電商 企業的成本。為此，本論文將從多個方面對系統的需求進行全面分析，為系統的 設計與開發奠定堅實的基礎。
3.2可行性分析
可行性分析是通過對系統的主要性能和功能進行描述和分析，從技術可行性、 操作可行性、經濟可行性三個方面對系統進行分析，并預測系統能夠產生的經濟 效益、社會影響，從而判斷系統是否具備開發的價值和完成的可能性。可行性分 析的目的是在較少時間、較低成本的條件下，判斷設定的目標是否能夠實現。可 行性分析的結果應保證科學、公正、可靠，并帶有一定的預測性。
3.2.1技術可行性分析
技術可行性是從開發系統所使用的技術層面上進行分析，確定論文提出的技 術方案是否具有可行性，即選擇的技術架構能否實現本系統的各種要求和功能。 本論文設計的物流信息管理系統整體上使用了以Node.js為基礎的技術棧，其中 前端使用Vue框架構造頁面，后端使用Koa框架提供后臺接口服務，前后端之 間使用Ajax技術和WebSocket通信協議進行通信，數據庫使用MongoDB對數 據進行存儲。
經過分析系統要求與功能，查找有關資料，發現在物流信息管理系統應用以 上所述技術棧是完全可行的。Nodejs架構具有異步I/O、事件驅動、單線程的優 點，非常適合作為需要實時交互、頻繁讀存取數據的I/O密集型Web應用的后 端架構。MongoDB作為原生支持類JSON數據格式的非關系型數據庫，與Node.js 配合使用能大大降低開發難度，提高開發效率。其具有的適合存儲海量數據的特 點，也更適用于物流信息管理系統的開發。前端使用當前最受歡迎的Vue框架開 發SPA應用，可以大大提高開發效率，優化網頁應用的流暢度，提高用戶體驗。
WebSocket通信協議的使用提高了前后端通信的效率和穩定性，為系統的流暢度 和穩定性提供了幫助。因此，本論文提出的技術方案具有非常高的可行性。
3.2.2操作可行性分析
具有良好的操作可行性的系統需要具備以下特點：
(1)系統易于安裝和使用；
(2)系統界面簡潔大方、便于操作；
(3)系統具有糾錯功能，防止使用人員誤操作。
本論文所研究的系統采用B/S架構，即用戶界面采用瀏覽器展示，數據處理 等邏輯交由服務器來完成。完成后的程序代將被部署在服務器端，管理人員在使 用時無需安裝，只需要訪問Web頁面即可。在對物流信息管理系統的功能需求 進行分析之后，明確了系統各個頁面具有的詳細功能，并針對這些功能做了詳細 的設計與策劃。在設計時，采用了簡潔大方的界面效果，并從各個方面為使用人 員考慮，大大降低了系統使用的入手難度，提高了物流管理人員操作的效率。因 此本系統在操作方面是可行的。
3.2.3經濟可行性分析
一個完整的物流信息管理系統的開發和使用成本主要有開發時的人力成本、 硬件設備購買成本以及后期的維護成本。當前的大多數物流公司缺乏對物流信息 的現代化、信息化管理，一個十分重要的原因就是定制的、完全符合物流企業實 際需求的物流信息管理系統的開發成本過高，同時后臺云服務器的購買和維護、 系統程序的部署、數據庫的維護等，也需要一定的成本。
本論文所研究的物流信息管理系統主要面向一家中型電商企業，考慮到企業 規模、資金投入規模、后期維護等因素，本系統選取了開發成本較低、開發周期 較短、部署和維護成本較低的技術方案。以JavaScript為統一開發語言的前后端 開發模式大大縮短了系統的開發周期，基于Node.js的后端服務器架構對于云服 務器的要求較低，并且后期維護簡單，管理人員經過簡單培訓即可熟悉操作流程。 本系統在開發、硬件設備購買和后期維護上都能只需要較低的成本付岀，因此從 經濟角度上考慮，本系統的研究與開發是可行的。
3.3系統業務流程分析
本論文研究的物流信息管理系統面向某電商企業，業務流程完全符合該企業 的實際業務場景。該電商企業擁有自己的一套完整的物流體系，包括貨物存儲以 及商品配送。本系統的業務流程如圖3-1所示。
圖3-1系統業務流程圖
在該物流信息管理系統中，以商品的轉移和信息的產生為線索，首先管理人 員根據現有的庫存信息，在需要進行釆購的情況下，對采購的物品名稱、數量、 價格等做詳細的規劃，然后提出采購申請。采購單由管理員審批通過之后，變為 正在執行狀態。當釆購的物品到貨之后，有倉庫管理人員對數量、商品規格和質 量進行核對，并生成商品的入庫申請。入庫申請審批通過之后，入庫操作由倉庫 管理人員執行，管理人員對貨物進行儲位分配，然后由倉庫工作人員將商品放置 到指定的儲位。
倉庫入庫之后，管理人員會對倉儲進行定期管理，，如庫存盤點、庫存調撥 等。庫存盤點是對當前的商品進行清點。庫存調撥是根據當前各個商品的儲位分 布情況，對部分儲位進行重新分配，以求在入庫、分揀等環節提高工作效率。
當有了訂單數據之后，由訂單數據中的商品名稱和數量，生成岀庫申請。出 庫申請審批通過之后，工作人員去進行處理，按照數量和名稱將商品分揀出來, 然后指定給配送人員進行配送。
3.4系統非功能性需求分析
在對該電商企業的業務現狀和需求進行了深入調研之后，并在對該系統的業 務流程進行分析的基礎上，需要對系統的非功能性需求進行分析，指定完成后的 系統應該具備的性能要求，在設計、開發過程中需要嚴格遵循這些要求。這樣的 系統才能在最大程度上實現為企業提高效率、降低成本、增大收益的目標。本系 統以Node.js作為基礎架構，可以實時處理和更新物流信息，在實現系統中各個 模塊的基本功能的同時，還需要兼顧其他方面，本論文將從安全性、可靠性、易 擴展性、易維護性四個方面進行分析。
3.4.1安全性
物流信息管理系統中包含了許多企業內部的保密信息和重要數據，所以在系 統的設計方面，一定要加強系統的安全性。系統要能應對來自網絡上的惡意進攻 擊，如XSS（跨站腳本進攻擊）、CSRF（跨站請求偽造攻擊），還需要應對來自其他 惡意用戶的不規范操作。整個管理系統需要設計權限管理機制，加強對系統的安 全防護。系統需要給每個用戶設定一定的權限，所有用戶需要登錄并在此權限下 進行規范操作。同時，為了避免由于硬件設備的損壞導致數據的丟失，本系統需 要有定時對數據進行備份的功能。
3.4.2可靠性
該電商企業的物流業務雖然不如大規模物流公司復雜、繁忙，但是平時的業 務量也十分可觀，需要高頻率、大規模地存儲和更新數據。為了不影響企業的日 常業務，需要物流信息管理系統具有較高的可靠性。可靠性具體要求有以下方面：
1.系統運行穩定，不隨意崩潰；
2.系統具有強糾錯功能，能最大程度上避免失誤操作。
3.硬件設備能長期穩定的運行。
4.某一方面出現問題之后，能具有備用方案。
該物流信息管理系統要求必須具有上述可靠性，才能真正達到為企業提高效 率、降低成本的目的。
3.4.3易維護性
易維護性是指系統部署完成、投入使用之后，系統維護人員能方便、快捷的 對系統進行維護和更新。系統需要具有完整的設計、開發文檔以及使用手冊，方 便使用人員快速熟悉系統。系統也應該具有日志管理功能，自動生成操作日志， 在出現異常之后能快速定位異常。良好的易維護性能夠降低企業在維護人員方面 的成本投入，為企業節約資金，也能使企業在系統的使用過程中達到較高的效率。
3.4.4易擴展性
易擴展性是指系統在首次開發完成后，可以方便地對其進行二次開發，以及 擴展現有的硬件設備，以便在現有系統的基礎上增加新的功能及獲得更強的性能。 首先，該電商企業的發展正處于上升期，隨著用戶的增加、業務量的提高，需要 對系統進行功能更改及優化，所以該系統必須方便開發人員進行二次開發。其次， 當前信息技術飛速發展，越來越多的新技術都應用到物流行業中，當功能需求變 更時，該系統必須容易接入各種新的信息技術。另外，隨著業務量的增大，服務 器、數據庫等硬件設施也應同步擴展，如服務器升級、數據庫擴容等。綜上，本 系統必須具有非常高的易擴展性。
3.5系統功能性需求分析
如前文的系統業務流程所述，物流信息管理系統的整體流程主要包含商品采 購、商品入庫、庫存盤點、倉庫調撥、商品出庫、商品配送等環節。除此之外， 整個系統還需要有權限管理機制，也就是需要對所有的用戶進行統一管理，防止 不必要的失誤操作。在該電商企業中，倉庫中的所有商品也應該納入統一管理， 以便與銷售部門協調一致，及時互通信息。下面將分模塊對系統所應具備的功能 做詳細分析。
3.5.1系統管理
(1)用戶管理功能
系統需要對每個工作崗位上的員工角色進行梳理、分析，并納入統一管理。 用戶根據崗位的不同，可分為高級管理員、部門主管及下屬工作人員。系統需要 為每個類型的用戶設置相應的操作權限，用戶根據享有的權限，能看到與其他用 戶不同的內容，并且只能在自己的權限內進行操作。
(2)用戶登錄管理功能
系統會給每個用戶設定初始密碼，用戶可以對自己的系統登陸密碼進行修改, 高級管理員具有查看和修改每個用戶密碼的功能。
(3)單據管理功能
在物流企業的業務流程中，各種操作均需要通過單據記錄操作的雙方以及處 理員工，因此在本系統中，需要對各種單據進行管理。
3.5.2采購管理
(1)采購申請功能
倉庫管理人員可以根據現有的庫存情況對某一種或幾種商品進行采購。此時, 應該先提出采購申請。確認申請后，需要在后臺數據中記錄此次采購的信息。
(2)采購審核功能
倉儲人員在系統中提出申請后，由倉庫管理員完成審核。審核通過的采購單， 則進入采購流程，并交由采購人員進行采購。倉庫管理人員在采購單完成審核之 前，可以對采購的詳情進行修改。
(3)采購商品簽收功能
采購的物品到達倉儲地點之后，由倉庫管理人員進行商品的簽收，并且在簽 收完成之后，系統需要能夠自動生成入庫申請，對商品進行入庫操作。
(4)采購單查詢功能
管理人員應該能夠通過系統查詢所有的采購信息。查詢應具備多條件查詢功 能，可以根據想要查看的采購單的不同信息來查詢采購單。
3.5.3倉儲信息管理
(1)庫存商品管理功能
物流信息管理系統需要將倉庫中所有存在的商品納入統一管理。每一種商品 必須進行唯一性的編碼，并記錄該商品的名稱、庫存數量和存儲位置。每一種商 品的信息都要及時根據實際操作進行更新。入庫、出庫操作后需要對商品的數量 信息進行更新，調撥操作后需要對商品的位置信息進行更新。
(2)貨位管理功能
系統需要對每一個貨位進行數字編碼，并將其納入統一管理。每個貨位都可 以存儲一個或多個商品，但是只能存儲同一類的商品，系統需要記錄每個貨位上 存儲的商品編碼、名稱和數量。
系統還需要記錄每個貨位的當前狀態。系統應提供對貨位信息進行修改的功 能。
3.5.4入庫管理
(1)生成入庫申請功能
當需要向倉庫中增加儲存商品時，就需要生成入庫申請。入庫申請一般有三 種來源：人工申請、簽收商品后自動生成、盤點后自動校正生成。人工申請是指 由倉庫管理人員手動在系統創建申請。簽收商品后自動生成是指在采購階段完成、 管理人員簽收商品之后，系統根據簽收的商品的名稱、數量自動生成入庫申請。 盤點后自動校正生成是指在進行庫存盤點之后，系統根據系統記錄的數據和實際 庫存的差別而生成的入庫申請。
(2)入庫處理功能
倉庫管理人員查看到有新的入庫申請之后，應該對每個申請進行處理。管理 人員需要為每種商品分配合適的貨位，在將商品全部入庫之后，需要在系統中詳 細記錄每種商品入庫的詳情，即商品存放的位置信息和對應位置的數量信息。
(3)入庫信息查詢功能
系統需要提供對所有入庫信息(包括入庫申請和已入庫記錄)的查詢功能。對 于入庫信息的展示，需要根據入庫信息不同的狀態進行不同的展示。
3.5.5出庫管理
(1)生成出庫申請功能
當需要從倉庫中移出儲存的商品時，就需要生成出庫申請。出庫申請一般有 三種來源：人工開單、收到訂單后自動生成、盤點后自動校正生成。人工開單是 指由倉庫管理人員手動在系統創建申請。收到訂單后自動生成是指物流信息管理 系統在接收到銷售部門的訂單之后，根據訂單購買的商品的名稱、數量自動生成 出庫申請。盤點后自動校正生成是指在進行庫存盤點之后，系統根據系統記錄的 數據和實際庫存的差別而生成的出庫申請。
(2)出庫處理功能
倉庫管理人員查看到有新的出庫申請之后，應該對每個申請進行處理。管理 人員需要在系統中詳細記錄每種商品出口的詳情，即商品從哪個貨位取出以及取 出的數量。
(3)揀貨路徑優化功能
工作人員在取得岀庫單之后，系統需要能根據被揀商品的位置和數量，自動 生成一條優化路徑。
(4)出庫信息查詢功能
系統需要提供對所有出庫信息(包括岀庫申請和已出庫記錄)的查詢功能。對 于出庫信息的展示，需要根據出庫信息不同的狀態進行不同的展示。
3.5.6盤點管理
(1)盤點開單功能
當需要對倉庫中的庫存信息進行盤點時，系統應該提供盤點開單功能。盤點 開單時，管理人員可以添加需要盤點的商品信息。系統會記錄需要盤點的商品名 單。
(2)盤點處理功能
盤點開單之后，倉庫工作人員可以根據盤點單對指定的商品進行處理。處理 完成后，工作人員需要根據盤點處理的結果，對現有記錄進行矯正，也就是生成 出入庫申請。處理完成后，就會在出入庫管理中自動生成相應的申請。盤點完成 并已經根據盤點結果對庫存數據進行矯正之后，工作人員可以將盤點任務標記為 完成狀態。
(3)盤點查詢功能
系統需要提供對所有盤點信息(包括尚未處理的盤點和己完成的盤點記錄) 的查詢功能。
3.5.7調撥管理
(1)調撥申請功能
當需要對倉庫中的商品進行調撥處理時，工作人員可以在系統中提出調撥申 請。調撥申請應該包含要調撥的商品的詳情。調撥申請應該準確記錄申請人和申 請時間。
(2)調撥審核功能
倉庫工作人員提出調撥申請之后，高級管理員可以查看調撥申請，并根據實 際情況對調撥申請進行審核。對于不通過的調撥申請，可以給出不通過的理由。
(3)調撥執行功能
調撥審核完成后，倉庫工作人員需要對調撥申請進行處理。首先工作人員將 調撥申請標記為正在處理，這表明該條申請己經由此員工著手處理。執行完成后, 工作人員需要將調撥信息標記為已完成狀態。這樣就會生成一條調撥記錄。
(4)調撥查詢功能
系統需要提供對所有調撥信息(包括尚未審核、尚未處理和己完成的調撥申 請)的查詢功能。
3.5.8配送管理
(1)訂單管理功能
系統需要對銷售部門傳過來的訂單信息進行記錄，訂單信息包括具體商品名 稱、數量及配送地址。倉儲部門需要根據訂單信息來進行貨物的分揀、出庫。配 送部門需要根據訂單的信息進行配送。訂單應該有不同的狀態，如正在揀貨、已 出庫待配送、已送達等。
系統需要提供對所有訂單信息(包括正在揀貨、己出庫待配送、配送中、己送 達的訂單)的查詢功能。
(2)配送路徑優化功能
配送人員進行配送時，會一次性配送多個訂單。系統應該提供對于配送路徑 的優化功能。工作人員輸入待配送的訂單信息后，根據目的地的各種特征，系統 應當給岀一條最優路徑供配送人員采用。
(3)配送查詢與監控功能
對于已經開始配送的訂單，系統應提供對于這些配送信息的查詢功能。在運 輸途中的配送人員，需實時傳輸自己的位置。配送完成后，需要及時修改訂單狀 態，并將信息傳達給銷售部門，在銷售系統中更改用戶訂單的狀態。
3.6本章小結
本章對物流信息管理系統的需求進行了詳盡地描述與分析。首先從技術、操 縱和經濟方面分析了系統的可行性，然后梳理了系統的業務流程，并給出了流程 框圖，最后從非功能性需求和功能性需求兩個方面對系統的各個模塊進行了詳細 地分析。
第四草系統總體設計
4.1概述
前文從技術、操作、經濟三個方面論證了系統研究與實現的可行性，并且從 非功能性和功能性兩個方面對系統需求進行了全面的分析。本章在此基礎上，對 系統的實現進行了全面詳細的設計。首先描述了系統整體的結構設計，然后介紹 了系統實現的總體技術架構，最后介紹了系統各個功能模塊的設計。
4.2系統整體結構設計
本系統根據某電商企業的實際業務需求開發，在對系統的功能性需求和非功 能性需求做了詳細的分析之后,對系統整體結構和各個模塊的功能做了詳細的設 計，如圖4-1所示。物流信息管理系統共分為五大模塊：用戶管理、采購管理、 倉儲管理、配送管理和訂單管理。其中，倉庫管理分為六個小的模塊，分別為貨 位管理、商品管理、入庫管理、出庫管理、盤點管理和調撥管理。
物流信息管理系統
圖4-1系統功能模塊設計圖
整個系統中，模塊間的相互關系如圖4-2所示。其中，盤點和調撥的結果直 接影響了商品管理模塊和貨位管理模塊。
圖4-2系統模塊交互關系圖
在對該電商企業的需求進行了詳細地分析之后，系統的整體流程圖如圖4-3 所示。
整個系統的運行流程描述如下：
(1)用戶訪問系統頁面，輸入用戶米與密碼，進行登錄。
(2)系統對用戶的輸入進行驗證，驗證未通過時提示錯誤信息，并返回登錄頁 面；驗證通過后，進入到用戶主頁面。
(3)系統根據用戶的類別和相應的權限級別，為用戶展示不同的操作界面。
(4)頁面展示成功后，當有外部數據傳入時，頁面會自動進行更新。
(5)用戶在相應的頁面上進行操作，如申請采購、審核采購等等。用戶的操作 會導致頁面的更新，從而返回步驟4。
(6)用戶點擊退出登錄按鈕，結束對系統的訪問。
4.3系統總體技術架構設計
4.3.1后端接口設計
后端使用Node.js流行的Koa框架，并使用Koa-router對HTTP請求進行解 析并根據請求路徑選擇對應的處理邏輯。整個服務端采用類似MVC的架構模式, MongoDB中的每個數據文檔都由對應的數據模型Model來定義其結構，并由控 制器Controller控制具體對數據庫的操作以及向瀏覽器端返回相應的數據。整個 流程設計如圖4-4所示。
圖4-4系統后端流程設計圖
程序開始時，由Koa框架的核心部分使用Mongoose插件來連接MongoDB 數據庫，并引入使用Koa-router定義的路由處理模塊。Koa運行主線程，在接收 到瀏覽器發來的HTTP請求之后，對請求進行解析，取出請求數據并保存起來， 然后將解析岀的數據發送給Koa-router路由模塊。路由模塊在在接收到這些數據, 判斷HTTP請求的方法和路徑，然后尋找對應的控制器，調用里面的處理函數， 由處理函數對數據進行處理。
在控制器的處理函數中，一般要對數據庫中的數據進行增刪改查等操作。數 據模型Model定義了數據庫中數據的文檔格式，并連接控制器Controller與數據 庫。控制器中的處理函數在對數據進行相應的讀寫操作之后，然后將正確的數據 返回給瀏覽器。這樣就完成了整個后端接口功能。
4.3.2前端系統框架設計
整個前端系統使用Vue構建單頁應用，為了方便的進行頁面的導航以及數 據的管理，配合使用了 Vue-router插件和Vuex插件，這樣使得頁面的結構更加 清晰，組織更加合理。
Vue-router與Vue組件的對應關系如圖4-5所示。Vue引入并初始化Vue- router 之后,由Vue-router定義路由和組件的映射關系。每個路徑對應一個組件， 路徑下的二級路徑對應組件下的子組件。
圖4-5 Vue組件與路由對應圖
在Vue中，每個頁面都是由多個組件構成的，多個組件之間需要共同對特定 的數據進行讀寫操作，并在數據更新之后進行同步，才能完成相應的功能。在本 系統中，為了更好的在各個組件之間保存數據、共享數據，使用了 Vuex來管理 數據。
綜合前文所述，前端系統架構的整體流程如圖4-7所示。
整個流程描述如下：
(1)用戶與Vue組件構建成的系統頁面進行交互，并觸發對應的事件。
(2)Vue在處理程序中判斷用戶的操作是否涉及到頁面間的導航。如果是，執 行步驟3；否則執行步驟4。
⑶Vue會調用Vue-router,根據事先規定好的路由映射表查詢出本次導航的 目的組件。
(4)Vue判斷是否對數據進行了修改。如果是，執行步驟5；否則，執行步驟 7O
(5)Vuex對中心狀態樹中的數據進行更改，并將數據更改廣播給所有的依賴 者。
(6)Vue根據新的數據和目的路由渲染出對應的組件，執行步驟8o
(7)根據目的路由渲染對應的組件，執行步驟8o
(8)Vue組件構成頁面，呈現給用戶。
圖4-7前端結構流程圖
4.4系統功能模塊設計
4.4.1用戶管理模塊設計
用戶管理模塊的功能如圖4-8所示。在用戶管理頁面，管理員可以根據需要 點擊新建按鈕，創建一個新的用戶，可以對某個用戶進行修改、刪除。在進行這 些操作時，必須校驗用戶是否有進行操作的權限。
管理員可以根據每個用戶的各項信息，對用戶列表進行篩選。在篩選時，系 統支持多條件篩選，并設置了根據用戶名稱、用戶賬號、部門名稱、工作職位和 狀態等條件。
用戶列表展示的信息項分別為用戶名稱、用戶賬號、部門名稱、工作職位、 聯系方式、當前狀態和備注。
用戶管理模塊
圖4-8用戶管理模塊功能圖
4.4.2單據管理模塊設計
單據管理模塊的功能如圖4-9所示。
單據管理模塊負責對物流業務流程中出現的各種單據進行統一管理，包括單 據的生成、查看、導出等功能。該功能模塊的主要功能包括：
1、 單據生成，主要負責在各個環節的操作發生時生成相應的單據；
2、 單據查詢，該功能負責實現對單據的査詢，包括按照各種條件進行查詢；
3、 單據審核，管理部門應當對所有生成的單據進行查看與審核，及時發現 不合理之處。
4.43采購管理模塊設計
采購管理模塊的功能如圖4-10所示。在釆購頁面，用戶點擊申請采購，在 填寫完采購的商品名稱、數量、價格以及供應商后，即可申請采購。對于管理員， 采購模塊需要有審核功能，用來對采購的商品進行審核。在審核通過后，工作人 員才可以進行采購操作，審核拒絕后，系統向提出申請的工作人員發出通知。
采購的商品到貨之后，由倉庫工作人員進行簽收，并執行入庫操作。簽收可 以按照釆購單整體簽收，也可以按照單個貨物進行簽收。
采購查詢設置了多條件查詢，可以按照采購編號、采購員、狀態和采購日期 來進行查詢。
釆購管理模塊
圖4-10采購管理模塊功能圖
4.4.4貨位管理模塊設計
貨位管理模塊的功能是對倉庫中的所有貨位進行統一管理，具體如圖4-11 所示。
根據該電商企業中的每個貨架的具體情況，系統對所有的貨位使用了 “通道 -貨架■■列-層“的編碼方式。每兩個貨架組成一個通道，分別編號A、B、C...每個 通道的兩個貨架編號為01貨架和02貨架。然后每個貨架又分為若干列，每一列 分為若干層。這樣組成4位統一編碼。
根據倉庫中的貨位實際情況，管理員可以創建貨位通道。每次創建一個通道, 即可同時創建此通道的所有貨位。
用戶可以根據倉庫中貨位的實際情況，更改貨位的狀態。當對商品進行入庫、 出庫、調撥等操作之后，系統會自動更新貨位上存儲的貨物情況。
|貨位管理模塊|
圖4-11貨位管理模塊功能圖
4.4.5庫存商品管理模塊設計
庫存商品管理是對倉庫中現有的所有商品進行統一管理。功能具體如圖4- 12所示。用戶可以根據系統提供的功能對庫存商品進行增刪改查等操作，同時， 在對庫存商品進行入庫、出庫、盤點、調撥等操作之后，商品應根據操作結果自 動更新數量信息和位置信息。由于每個商品會被存放在多個貨架上，所以在對商 曹信息進行展示時，不僅要展示其數量信息，還應該根據貨位的不同進行詳細展 zJx o
庫存商品管理模塊
[ I
圖4-12庫存商品管理模塊功能圖
4.4.6入庫管理模塊設計
入庫管理模塊提供對貨物的入庫操作。入庫操作的流程如圖4-13所示。
圖4-13入庫管理模塊流程圖
商品的入庫有三種：簽收商品入庫、盤點入庫和人工申請入庫。入庫模塊能 根據采購模塊的簽收結果更新入庫申請信息，同時也可以根據庫存盤點之后的自 動生成入庫申請來更新入庫信息。當需要往倉庫中存入其他商品時，可以點擊入 庫按鈕，創建一條入庫申請。
倉庫管理人員可以對入庫申請進行處理。每位員工開始處理時，都要對該條 入庫申請做更改狀態的操作，并在入庫操作完成后，將入庫申請的狀態改為己完 成。入庫操作完成后，管理人員必須在系統中記錄入庫操作的詳細信息，即商品 存入的具體位置和數量。
4.4.7出庫管理模塊設計
出庫管理模塊提供對貨物的出庫操作。出庫操作的流程如圖4-14所示。
商品的岀庫有三種：新的訂單請求、盤點出庫和人工申請岀庫。出庫模塊能 根據訂單信息自動出入申請，包括出庫的商品名稱、數量等。同時也可以根據庫 存盤點之后的自動生成出庫申請來更新出庫信息。當需要從倉庫中取出其他商品 時，可以點擊出庫按鈕，創建一條出庫申請。
倉庫管理人員可以對出庫申請進行處理。每位員工開始處理時，都要對該條 出庫申請做更改狀態的操作，并在出庫操作完成后，將出庫申請的狀態改為已完 成。出庫操作完成后，管理人員必須在系統中記錄出庫操作的詳細信息，即從哪 個貨架取出了多少商品。
為了能提高倉庫工作人員揀貨時行走的路程，提高工作效率，本模塊設計了 一套基于遺傳算法的揀貨路徑優化方案，工作人員得到取貨單之后，系統會自動 生成一條經過優化后的揀貨路徑，工作人員按照此路徑進行揀貨，可以減少時間， 提高效率。
圖4-14出庫管理模塊流程圖
4.4.8盤點管理模塊設計
盤點管理模塊提供對庫存進行盤點并記錄相關信息的功能。其流程圖如圖 4-15所示。首先倉庫管理人員需要盤點開單，創建盤點計劃。盤點開單時需要填 寫盤點的商品類別。盤點單創建成功后，由倉庫工作確認盤點信息，開始進行庫 存盤點。盤點完成后，工作人員要對每一種商品的盤點結果進行詳細的錄入，系 統會自動把盤點的結果與系統中記錄的信息做對比，當實際情況與系統記錄數據 不一致時，工作人員可以點擊生成出入庫申請按鈕，對該商品進行出入庫操作, 以糾正誤差。
4.4.9調撥管理模塊設計
調撥管理模塊記錄倉庫中對貨物的調撥情況，其功能如圖4-16所示。在該 電商企業中，調撥需要管理人員進行審核，確認后方能對倉庫內的商品進行調動。 首先，倉庫工作人員根據當前倉庫中貨物的位置分配情況，在需要重新規劃商品 的存放貨位時，提出調撥申請。在提出申請時，倉庫工作人員需要填寫具體的調 撥情況，包括商品的調出貨位和調入貨位，以及調撥的數量。
管理人員收到調撥申請之后，可以根據調撥的詳細信息對此次調撥進行審核。 如果審核通過，則由工作人員進行處理。工作人員處理完成之后，需要在系統中 確認完成信息。
調撥完成之后，系統需要自動更改所有相關的信息，如貨位和商品的存放信 '息、O
4.4.10配送管理模塊設計
配送管理模塊的功能如圖4-17所示，分別為訂單信息查詢、訂單狀態的更 新和配送信息的查詢。本系統的訂單信息由該電商企業的銷售部門進行傳入，并 在系統中創建訂單副本，可以通過本模塊進行訂單信息的查詢。在配送過程中, 如果有訂單己經送達，則實時更新這些訂單的狀態。同時，系統提供所有配送信 息的查詢功能，供管理人員進行查看。當在配送過程中出現問題時，管理人員能 及時做出應對處理。
配送管理模塊
圖4-17配送管理模塊功能圖
4.5系統數據庫設計
數據庫設計是指對于一個給定的應用環境，構造最佳的數據庫模式，使之能 夠有效地存儲數據，以此來滿足系統用戶的應用需求。數據庫設計與系統功能設 計是構建一個完善系統的兩個重要組成部分，數據庫設計關乎系統功能穩定性、 擴展性等多個方面的內容。因此，數據庫的良好設計顯得尤為重要。物流信息管 理系統采用了 MongoDB作為系統后臺數據庫，實現對系統數據的更新與維護, 對物流企業信息數據進行科學管理和儲存，其主要體現在對用戶信息、采購信息、 倉儲信息、訂單信息、配送信息等信息的管理和存儲。本系統的數據庫設計主要 是從概念設計和邏輯設計兩方面進行展開闡述。
4.5.1概念設計
概念設計是數據庫系統的核心和基礎，其通常采用E-R模型圖進行描述。通 過概念設計得到的概念模型是從現實世界的角度對所需要解決的問題的描述，這 種概念模型的管理即是概念設計的重點
1.用戶管理數據庫概念設計
用戶管理數據庫以用戶信息為實體，主要涉及的屬性有用戶名、用戶昵稱、 密碼、所屬部門、職位等。
用戶管理數據庫E-R關系模型圖如圖4-18所示。
圖4-18用戶管理數據庫E-R模型圖
2.采購信息數據庫概念設計
釆購信息數據庫主要記錄系統中的采購申請和采購記錄，以采購單為實體, 其包含的屬性有采購編號、采購申請人、采購日期、采購狀態和具體采購的商品。 采購商品作為一個獨立的實體，具有商品編號、商品名稱、采購數量等屬性。
采購管理數據庫E-R關系模型圖如圖4-19所示。
圖4-19采購管理數據庫E-R模型圖
3.貨位管理數據庫概念設計
貨位管理數據庫主要存儲倉儲系統中的貨位信息，即每個貨位具體的位置信 息和其所存儲的商品信息，包括貨位編號、通道編號、貨架編號、行編號、列編 號、商品編號、商品名稱、狀態等。
貨位管理數據庫的E?R關系模型圖如圖4?20所示。
圖4-20貨位管理數據庫E-R模型圖
4.商品管理數據庫概念設計
商品管理數據庫主要存儲倉儲系統中的商品信息，每個商品都是一個實體, 包括商品編號、商品名稱、商品數量、存儲位置等屬性。其中由于每個商品存放 的貨位不止一個，所以其貨位信息是一個列表，每個貨位也是一個實體，具有通 道編號、貨架編號、行編號、列編號、數量等屬性。
商品管理數據庫的E-R關系模型圖如圖4-21所示。
圖4-21商品管理數據庫E-R模型圖
5.入庫信息管理數據庫概念設計
入庫管理信息數據庫負責記錄倉庫的入庫信息，以入庫單為實體，具有唯一 編號、來源名稱、來源編碼、申請人、申請日期、處理人、狀態、入庫商品列表 等屬性。其中，每次入庫的商品會有多種，商品作為一個實體，擁有商品編號、 商品名稱、入庫總量、入庫的詳細位置等屬性。商品包含了貨位實體，用來記錄 入庫時的詳細位置信息。
入庫信息管理數據庫的E-R關系模型圖如圖4-22所示。
圖4-22入庫管理數據庫E-R模型圖
6.出庫信息管理數據庫概念設計
出庫管理信息數據庫負責記錄倉庫的出庫信息，以出庫單為實體，具有唯一 編號、來源名稱、出庫商品列表等屬性。商品作為一個實體，擁有商品編號、商 品名稱、出庫的詳細位置等屬性。商品包含了貨位實體，用來記錄出庫時的詳細 位置信息。
出庫信息管理數據庫的E-R關系模型圖如圖4-23所示。
圖4-23出庫管理數據庫E-R模型圖
7.盤點管理數據庫概念設計
盤點管理數據庫負責記錄倉儲系統中的盤點記錄。盤點單為一個實體，其擁 有多種屬性，并包含了具體的盤點商品。盤點商品也作為一個實體存在，具有商 品編號、商品名稱等屬性。
盤點管理數據庫的E-R關系模型圖如圖4-24所示。
&調撥管理數據庫概念設計
調撥管理記錄了倉儲系統中的調撥申請和調撥記錄。該數據庫以調撥單為實 體，記錄了調撥單的商品名稱、調撥數量、狀態等屬性。每次調撥均會記錄詳細 的調出貨位和調入貨位。
9.配送管理數據庫概念設計
配送管理數據庫記錄物流信息系統的訂單信息和配送信息，以及訂單中的商 品信息。其中，配送單實體包含訂單實體，訂單實體包含商品實體。
配送管理數據庫的概念設計如圖4-26所示。
圖4-26配送管理數據庫E-R模型圖
10.單據管理數據庫概念設計
單據管理數據庫用于記錄物流信息管理系統中因各種業務產生的票據流轉 信息。單據做為一個實體，具有單據編號、單據類型、開單日期、申請人、審核 人等屬性。
單據管理數據庫的概念設計如圖4-27所示。
圖4-27單據管理數據庫E-R圖模型
4.5.2數據庫文檔設計
本系統采用了非關系型數據庫MongoDB »如前文第二章第二節所述， MongoDB采用類JSON格式的文檔存儲數據，這種格式支持嵌套數據，即某個 屬性存儲的數據可以為對象或者數據，并且數組中的每一項既可以是基本數據類 型，如字符串，也可以是對象或者數組。數據庫設計如下列表格所示。
(1)用戶數據文檔如表4-1所示。
表4-1用戶文檔設計
屬性名 類型 描述
username 字符串 用戶名
nickname 字符串 用戶昵稱
password 字符串 密碼
department 字符串 所屬部門
position 字符串 職位
phoneNumber 字符串 聯系方式
state 數值 狀態
(2)采購信息的數據文檔如表4-2所示。每次采購可能會采購多種商品，考慮 到這些商品并非一次性全部到齊，有可能是分批次到達、簽收，所以給采 購單中的每個商品也設置了狀態屬性。
表4-2采購信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編號
purchaser 字符串 釆購申請人
purchasingDate 字符串 采購日期
state 數值 采購狀態
stateText 字符串 采購狀態文字描述
extra 字符串 備注
goodsList 數組 采購商品列表
其中，采購信息中的商品可能有多個，所以商品列表為數組類型，其中包含 有采購的商品信息，商品信息包含商品名稱、商品編號、單價、數量、總價、供 應商、狀態和狀態文字描述等屬性。
(3)貨位信息的數據文檔如表4-3所示。
表4-3貨位信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 貨位編號
line 字符串 通道編號
shelf 字符串 貨架編號
col 字符串 列編號
layer 字符串 層編號
goodsUniqueCode 字符串 存儲商品編號
goodsName 字符串 商品名稱
amount 數值 存儲商品數量
state 數值 狀態
stateText 字符串 狀態文字描述
(4)庫存商品信息的數據文檔如表4-4所示。
表4-4商品信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 商品編號
goodsName 字符串 商品名稱
amount 數值 商品數量
positions 數組 商品位置信息
(5)入庫記錄信息的數據文檔如表4-5所示。
表4-5入庫信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
resourceCode 數值 來源編號
resource 字符串 來源名稱
applicant 字符串 申請人
applicatingDate 字符串 申請日期
processor 字符串 處理人
state 數值 當前狀態
stateText 字符串 狀態的文字描述
extra 字符串 備注
goodsList 數組 入庫的商品列表
(6)岀庫記錄信息的數據文檔如表4-6所示。
表4-6出庫信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
resourceCode 數值 來源編號
resource 字符串 來源名稱
applicant 字符串 申請人
applicatingDate 字符串 申請日期
processor 字符串 處理人
state 數值 當前狀態
stateText 字符串 狀態的文字描述
goodsList 數組 出庫的商品列表
(7)盤點信息的數據文檔如表4-7所示。
表4-7盤點信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
applicant 字符串 申請人
applicatingDate 字符串 申請日期
executor 字符串 盤點執行人
executingDate 字符串 盤點日期
state 數值 當前狀態
(續上表)
屬性名 類型 描述
stateText 字符串 狀態的文字描述
extra 字符串 備注
goodsList 數組 盤點的商品列表
stateText 字符串 狀態的文字描述
(8)調撥信息的數據文檔如表4-8所示。
表4-8調撥信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
goodsUniqueCode 字符串 商品編碼
goodsName 字符串 商品名稱
amount 數值 商品庫存數量
transshipAmount 數值 調撥數量
applicant 字符串 申請人
applicatingDate 字符串 申請日期
processor 字符串 審核人
checkDate 字符串 審核日期
executor 字符串 調撥執行人
executingDate 字符串 調撥日期
state 數值 當前狀態
stateText 字符串 狀態的文字描述
extra 字符串 備注
details 數組 調撥詳情
(9)配送信息的數據文檔如表4-9所示。
表4-9配送信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
courier 字符串 配送員
state 數值 狀態編碼
stateText 字符串 狀態文字描述
orderList 數組 配送詳情數組
(10)訂單信息的數據文檔如表4-10所示。
表4*10訂單信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
state 數值 狀態編碼
stateText 字符串 狀態文字描述
name 字符串 收貨人
address 字符串 收貨地址
goodsList 數組 商品列表
⑴)單據信息的數據文檔如表4-11所示。
表4-11單據信息文檔設計
屬性名 類型 描述
uniqueCode 字符串 唯一編碼
createDate 字符串 開單日期
applicant 字符串 申請人
type 字符串 單據類型
checker 字符串 審核人
extra 字符串 備注
4.6本草小結
本章對系統的總體設計做了詳細的介紹。首先介紹了系統整體的功能結構設 計，列舉了所有的模塊以及模塊之間的連接關系。然后描述了總體的技術架構設 計，給出了后端使用Koa框架與MongoDB數據庫進行交互，并把數據返回給前 端的技術方案，還講述了前端系統的架構，給出了 Vue與Vue-router和Vuex相 互協作的設計方案。其次，本章對系統的各個模塊功能進行了詳盡地設計，并展 示了每個功能模塊的具體功能框圖或流程框圖。最后，本章給出了系統的數據庫 設計，描述了每個數據文檔的詳細設計。
第五章系統實現
5.1概述
本章在系統設計的基礎上，詳細描述了對系統的實現方案和實現效果。首先, 本章將介紹系統總體架構的實現，并給出整個實現的程序流程框圖，然后介紹了 系統各個功能模塊的具體實現方案和效果。
5.2系統總體架構實現
5.2.1后端架構實現
后端使用Node.js中流行的Koa框架作為核心框架，配合Koa-router插件對 HTTP請求進行處理。由于Nodejs只有一個主線程，因此Node.js程序的初始化 只需要在一個文件中完成即可。此后，Nodejs的事件循環機制便會不停地監聽 來自網絡中的請求，并根據請求的內容做出對應的處理。
整個Node.js程序的執行流程如圖5-1所示。
圖5-1 Nodejs程序流程圖
5.2.2前端系統架構實現
與后端的Nodejs需要運行一個主線程不同，前端主要以用戶和頁面的交互 為主，通過用戶的交互觸發各種事件，來推動HTTP請求的發送、數據的傳遞和 頁面的更新渲染。在單頁應用SPA中，只需要對所有的Vue組件進行初始化， 為需要監聽的事件注冊事件處理函數，即可在用戶與頁面交互時執行設置好的處 理邏輯。
在本系統的實現中，整個系統頁面使用一個Vue實例，各個功能模塊的頁面 采用子組件的方式進行展示。整個前端系統的初始化流程如圖5-2所示。
圖5-2前端主程序流程圖
5.3系統功能模塊實現
5.3.1登錄功能實現
登錄頁面是進入系統必經的頁面。在此頁面，系統將完成對登錄用戶的權限 審核與認證，只有輸入正確的用戶名和密碼，系統才會允許用戶登錄。系統的登 陸頁面如圖5-3所示。
5.3.2用戶管理模塊實現
用戶管理模塊主要的功能有新建用戶、修改用戶和刪除用戶。為了保證系統 里的數據不被隨意修改，在進行這些操作時會對操作人的權限進行審核。只有管 理員級別的用戶才能對用戶信息進行修改、刪除，其他人只能查看用戶的某些信 息，并且這些信息中不包含密碼等隱私信息。用戶管理模塊的主要界面如圖5-4 所示。用戶管理模塊實現了用戶的多條件搜索功能，只需要在頁面上方的輸入框 中輸入需要搜索的用戶的信息，即可在表格中列出相關用戶信息。
用戶管理
新建 刪除
狀態
用戶名稱 用戶賬號 部門名稱 工作職位 聯系方式 狀態
admin admin 正常 修改
zhaowu 采購部門 采購員 18723847364 正常 修改
共2條 20條/頁 1 前往 4 頁
圖5-4用戶管理界面
533采購管理模塊實現
在釆購管理頁面可以完成對商品的申請采購、審核以及簽收、申請入庫等功 能。其具體實現效果如圖5?5所示。
申請采購
采購編號 采購員 狀態 鈿 采購日期 種餉1；
采購編號 采購員 采購曰期 當前狀態 備注 作
154702027516
8 admin 2019-01-09 15:
51:15 全部簽收
154702079390
6 admin 2019-01-09 15:
59:53 全部簽收
圖5-5采購管理界面
在頁面上方，添加了申請采購的按鈕，點擊之后可以進入到采購申請子頁面, 如圖5-6所示。頁面上方的多個輸入框和選擇框，為采購記錄提供了多條件搜索 功能。
圖5-6采購申請子頁面
每一條采購申請都有如下幾個狀態：已回絕、未審核、未簽收、部分簽收、 全部簽收。
各個狀態之間的流轉關系如圖5-7所示。
倉庫人員 簽收完畢
圖5-7采購申請狀態流轉
工作人員提出釆購申請之后，釆購申請的狀態為未審核狀態。之后審核人員 對申請進行審核。如果審核未通過，采購申請的狀態即變為己回絕。如果審核通 過，釆購申請的狀態就會變為未簽收，此時采購人員即可對物品進行采購。當采 購的商品陸續到達倉庫之后，根據倉庫管理人員對商品的簽收情況，采購申請會 變為部分簽收和全部簽收。當本次采購全部簽收之后，采購模塊的任務便己完成。
在采購記錄的表格展示中，為了方便地查看采購的詳細信息，為每一條采購 記錄添加了額外的擴展表格，可通過點擊每一行左側的箭頭來展開。
5.3.4貨位管理模塊實現
貨位管理模塊實現對倉庫中所有貨位的管理功能，如圖5-8所示。通過該頁 面，可以查看當前倉庫中所有貨位的具體編號以及其當前的狀態、存儲的商品和 數量。還可以通過多條件查詢特定的貨位。在貨位管理中，設置了如下幾個字段 進行展示：貨位編號、位置詳情、具體的通道、貨架、列和層、狀態、存儲商品 名稱和數量。
倉儲管理 貨位管理
新建通道
通道編號
貨架編號
圖5-8貨位管理界面
5.3.5庫存商品管理模塊實現
庫存商品管理模塊實現了對倉庫中所有的商品的管理功能，包括對商品的新 建與刪除。可以方便地對商品的種類和數量以及位置進行查看和修改。如圖5-9 所示。在商品表格中，可以通過點擊每種商品左側的展開按鈕，查看商品存在的 各個位置以及每個位置上的數量。
倉儲筲理 庫存商品管理
新建 刪除
商品編號
商品名稱
入庫管理模塊實現了向倉庫中添加商品以及管理入庫記錄的功能，其界面如 圖5-10所示。在表格中展示了所有已完成和未完成的入庫申請。
對于入庫申請，需要倉庫管理人員點擊操作列的入庫按鈕，并詳細填寫每種 商品入庫的位置和數量。對于已經入庫完成的記錄，系統會展示其入庫情況的詳 細信息。
倉儲管理 入庫管理
申請人 狀態
申請人 申請日期 處理人 狀態 操作
admin 2019-01-09 15:59:43
商品名稱 商品編號
7 2液晶斷器 1547008574337 10
數塑
圖5-10入庫管理界面
5.3.7出庫管理模塊實現
出庫管理模塊負責處理并記錄商品的岀庫信息，其界面如圖5-11所示。當 有新的訂單產生或者人工提出了出庫申請時，列表中會增加一條新的出庫申請。
每條出庫申請都具有一下幾個狀態：待處理、正在揀貨、已出庫。當有新的 出庫申請到來時，工作人員需要點擊出庫申請的開始出庫按鈕，表明該申請已經 在正在揀貨狀態中。這時，系統會根據本次出庫申請中的商品位置信息，生成一 條優化路徑，工作人員按照此揀貨路徑進行揀貨。當工作人員揀貨完畢，需要點
擊錄入出庫信息按鈕，在系統中錄入每個貨位的具體出庫情況，包括位置和數量。 這時，該出庫申請便已完成。
倉儲管建 出庫S3
圖5-11出庫管理模塊
5.3.8盤點管理模塊實現
盤點管理模塊實現了對庫存盤點的管理功能，其界面如圖5-12所示。頁面 上方是盤點開單按鈕，點擊此按鈕，即可創建一個盤點計劃，如圖5-13所示。 按鈕下面的輸入框與選擇框可以為用戶提供多條件搜索功能。
倉儲管理 盤點管理
盤點開單
盤點編號 當前狀態
所有
歸單號 開單人 開單時間 當前狀態 盤點員 盤點時間 備注
VZ 1547112890437 admin 2019-01-10 已生成岀入
17:34:50 庫申請 admin 2019-01-11
00:35:20
商品編號 商品名稱
1547106039460 1020 18 -1002
圖 5-12盤點管理界面
圖5-13盤點開單
當需要對庫存商品進行盤點時，工作人員點擊盤點開單按鈕，創建一條新的 盤點計劃。每個盤點計劃有如下幾個狀態：未處理、正在處理、已錄入結果、完 成。其狀態流轉如圖5-14所示。
圖5-14盤點計劃狀態流轉
倉庫工作人員接收到盤點通知后，便可以點擊系統中的開始處理按鈕，表明 此次盤點已經由該工作人員負責。盤點計劃的狀態更改為正在盤點。當工作人員 盤點完成后，需要將盤點結果錄入系統中，此時該盤點計劃的狀態更改為已錄入 結果。每次盤點之后，由于實際庫存與系統中的記錄有誤差存在，所以需要根據 結果自動生成出庫和入庫申請，以校正系統中記錄的商品的位置和數量誤差。此 時，盤點流程便已完成。
5.3.9調撥管理模塊實現
調撥管理模塊實現了對于倉庫商品的調撥管理和記錄，其主界面如圖5-15 所示。
at»w 孵
圖5-15調撥管理界面
頁面上方設置了申請調撥按鈕，用于倉庫工作人員根據現有庫存情況，對商 品的位置進行合理調整。當需要對倉庫中的商品進行調撥時，工作人員可以點擊 頁面上方的申請調撥按鈕，并添加調撥的具體信息，如圖5-16所示。在此界面 中，工作人員可以添加商品，并設置商品的調出貨位和調入貨位，點擊確認后， 即可生成一條調撥申請。管理員對調撥申請進行審核，審核通過后，即可安排人 員對倉庫中的商品進行位置的調整。
工作人員在處理完成后需要返回此界面，對調撥計劃的狀態進行更改，表明 此次調撥已經完成。
5.3.10配送管理模塊實現
配送管理模塊實現了對訂單信息和配送信息的查詢、狀態更改等功能，主要 界面如圖5-17所示。商品出庫后，會由配送管理人員對商品的配送任務進行分 派。通過點擊頁面上上方的分配訂單按鈕，即可將訂單配送的任務分配給相應的 配送員。
每個配送信息下都會有一個訂單列表，顯示本次配送所包含得多個訂單信息, 包括訂單編號、訂單狀態、收貨人、聯系方式和收貨地址。
圖5-17配送管理界面
5.4基于遺傳算法的揀貨路徑優化實現
電商企業收到訂單后，需要先從倉庫中將商品從貨架上取下，然后整合、裝 載、配送，才能到達顧客手里。調査表明，工作人員在揀貨過程中經常面臨時間 長、任務重的問題，此過程中消耗的成本在整個倉儲管理中占有很大的比例卩刃， 所以解決揀貨路徑優化問題，對于企業降低揀貨作業成本及揀貨作業效率及競爭 力具有重要意義［佝。
5.4.1問題描述
對于電商企業而言，接到訂單后，能盡快地將貨物分揀、打包、出庫并配送 到顧客手中，能大大提高顧客的滿意度，同時提高倉庫中的分揀速度，也能提高 員工的工作效率，減少員工的負擔，進而節約商品的儲存成本，提高企業效益。 但是由于當前倉庫中存儲的商品眾多，工作人員在接到分揀任務后無法快速的找 到一條科學、合理的揀貨路徑，導致了揀貨效率的低下，提高了企業的時間成本 和經濟成本。因此本章節解決的問題是工作人員在接到取貨任務后，如何快速選 擇出最合理的揀貨路徑，從而減少工作人員行走的距離，節約過程中消耗的時間。
工作人員取貨的基本流程為：從倉庫入口開始，按照分揀單中的商品列表， 對每個存放所需商品的貨位訪問一次，最后回到倉庫入口，將商品進行分類、匯 總。所以本問題可以認為類似于傳統的商旅問題。
該電商企業的倉庫使用的是傳統的雙區型倉庫，這種倉庫由許多相互平行的、 寬度和長度都相等的通道組成，通道兩側是貨架，倉庫的整體分為兩排。倉庫的 平面布局圖如圖5-18所示。
In/Out
圖5-18倉庫平面布局圖
5.4.2揀貨路徑優化的數學模型
為了便于描述和求解，這里假設每個通道的寬度和貨架的長寬均為1米，中 間過道的寬度為2米。再此模型中，對貨位采用[a][b][c]格式的三位數組來編號， 其中a代表貨位所在的通道編號，范圍是1?5； b表示同一通道中左右兩側的貨 架，左側貨架為0貨架，右側貨架為1貨架；c代表貨架的列編號，取值范圍為 1 ?20。
計算揀貨路徑的距離，需要知道任意兩個貨位以及出入口與任意貨位之間的 距離。在本系統中，假設任意兩個貨位的編號為[ai][bi][ci]和血]中2]血],那么兩個 貨位之間的距離可以表示為：
|c,.-Cj|; ai =aJ,0<ci,cj < 10(10<c;,cy <20)
|c(.-Cj|+2; a,. = ay,0 < cz < 10<cy < 20(0 < cy < 10<c,. < 20)
{min© + C/,20- (c,. + cy)) + 21 at - a} \ +l;a(.工竹,0 < c;.,cy <10 (4-1)
min© + C/ - 20,40 - (c： + C/)) + 21 a： -幻 | +1; a} aj,\Q<cj,cj <20 |c,.-Cj|+2+2|a： 一勺|+1;再豐 a},0< ct < 10<cy < 20(0 < cy <10<^. < 20)
公式(4-1)中根據兩個貨位的位置情況分別給出了兩個貨位間距離的計算方 式。第1個公式指在同一條通道且同一側的兩個貨位之間的距離就是貨位編號的 距離。第2個公式是指在同一條通道但是不在同一側的兩個貨位的距離情況，其 距離值需要加上過道的寬度。第3、4個公式指不同通道但同側的兩個貨位之間 的距離情況，這種情況首先判斷從通道和過道交叉的哪個方向出來。第5個公式 指分別位于過道兩側的貨位，其距離為兩個貨位的橫向距離2|a;-a.|與豎向距離
|q-Cj|并加上過道寬度2。
利用上述距離的計算公式，對本模型的建立作出以下假設：
(1)假設一個訂單包括"種貨物，訂單總量小于揀貨車容量Q；
⑵揀貨車的起始位置固定為[1][0][0]；
(3)揀貨人員在同一條通道中揀貨時從一側轉到另一側的距離忽略不計。
則揀貨路徑的目標函數為:
(4-2)
其中，召為任意兩個貨位間的距離；
先為揀貨過程中從貨位j到貨位丿所走的次數。若揀貨員從貨位i去了貨位j , 則xtj = 1,否則七=0。
從貨位/到任意貨位/的總次數為:
11
=IQ H 丿;，=1〉2,3 …巾) (4-3)
7=1
從貨位j到任意貨位Z的總次數為:
工列=1(’ 豐 j； j = 1? 2,3...72)
/=1
綜上，整個揀貨路徑的優化模型為：
D = min工工認
i=\
si ：工％ =l(i 工 J;Z = 1,2,3..*)
工 r =l(z^y；7 = 1,2,3.../?)
i-1
= J1, 7與/之間存在揀貨路徑
了 與/之間不存在揀貨路徑
C-Cjl； a, = apQ< c/,c/ <10(10 < cz,c; < 20)
|c廠c』+2; a = aj.Q< cz < 10<c; < 20(0 < c; < 10<cz < 20)
dq = < min(cz + c;,20一(cy + cy)) + 21 % -aj \ +1;aj 工勺，0 v c」<10
mit!(Cj + c/ — 20,40 — (c, + c丿))+ 21 勺—q . | +1;q. H ，10 < ,c丿.5 20 ©-Cj|+2+2|e —Q」+l;q H a..0< cz < 10<c; < 20(0 < cy < 10<cz < 20)
5.4.3遺傳算法設計
在前文所述的數學模型中，為倉庫的每個貨位確定了三位編碼，分別表示貨 位所在的通道編號、貨架編號和列編號，并設定倉庫的入口位置為[0][0][0]o取 貨人員取貨時，會拿到一份待揀貨物的清單，然后從入口位置開始，按照一定的 路徑依次經過每個需要到達的貨位，并最終回到倉庫入口處。這中間所走的路程 即為本次取貨的總路程。
本文所提出的揀貨路徑優化問題屬于NP難問題，其求解方法多使用精確求 解算法和啟發式算法。本文的路徑優化問題規模相對較大、相對復雜，而精確求 解算法是以時間和空間的復雜度換取優質解的算法，所以并不適用于本模型的求 解。而在啟發式算法中，遺傳算法具有非常顯著的特點。遺傳算法是一種全局遍 歷的隨機尋優方法，并且看可以多路并行尋優，且簡單易用、魯棒性強，非常適 合本模型的求解。所以本模型使用遺傳算法進行求解。遺傳算法的求解需要有編 碼、交叉、選擇、變異等步驟，下面將給出遺傳算法的具體設計。
1.染色體編碼
將一批訂單中所有待揀選貨品合并，同一種商品不重復計數，將其在倉庫中 的位置采用符號集進行序列編號，貨位號和商品種類一一對應。用編號的先后順 序表示揀選路徑，例如“{1, 2, 4, 6, 5, 3, 7, 9, 8}”表示揀選路徑為：I/O f貨位貨位2~*貨位貨位6—貨位5—貨位3—貨位7~貨位貨位 I/Oo
其中，商品貨位號抽象為一個基因，一批訂單的一種揀選順序組成一條染色 體。
2.種群規模
種群規模的設置會對問題的優化程度產生較大影響。若種群規模過于小，則 種群的樣本多樣性減少，在接下來的迭代過程中會出現收斂過快的現象，有意義 的搜索點和最優點可能被丟失，最終收斂于局部最優解，得不到最優解。若種群 規模過于大，在接下來的迭代過程中無效計算量會大大增加，導致慢收斂率。本 文將種群規模設計為50 o
3.適應度函數
適應度函數是用來評判染色體好壞程度的指標，適應度函數的大小直接關系 到后續的選擇和交叉工作。在遺傳算法中，要求適應度越高的個體遺傳到下一代 的概率越大，所以要求適應度函數為正值。由于本文的目標函數為求最小值，優 化效果越好的個體，其目標函數值越小，所以需要將目標函數加以改進，組成適 應度函數，使得優化效果越好的個體的適應度函數越大，即得到下式：
F = f^-D
式中，F為適應度函數，其數值越大，表示優化效果越好，也即遺傳到下一 代的概率越大；/_為采取未進行優化時揀貨時工人行走的總路程；D為目標函 數。
其中，目標函數的求解過程如圖5-19所示。
圖5-19目標函數值求解流程圖
4.交叉算子
遺傳算法的交叉指隨機選定兩個染色體的某一位置，將這一位置之后的結構 交叉互換，生成新的染色體，交叉操作可以大大提高遺傳算法的搜索能力。在本 文的研究中，基因存在表示揀選某種商品，所以在新生成的染色體中，原有的基 因不能消失，也不能重復，故采取如下交叉策略：
父代染色體A： (1, 3, 5, 7, 9, 2, 4, 6, 8)
父代染色體B： (2, 4, 6, 8, 1, 3, 5, 7, 9)
隨機選擇一個交叉點;
父代染色體A： (1, 3, 5, 7, 9, 2|4, 6, 8)
父代染色體B： (2, 4, 6, 8, 1, 3|5, 7, 9)
將染色體A的交叉點后的基因拼接到染色體B的前邊，將染色體B的交叉 點后的基因拼接到染色體A的前邊：
A： (5, 7, 9|1, 3, 5, 7, 9, 2|4, 6, 8)
B： (4, 6, 8|2, 4, 6, 8, 1, 3|5, 7, 9)
保留新拼接上的基因和原染色體交叉點后的基因，將原染色體交叉點前的基 因中重復的部分去掉，生成子代染色體C、D：
C： (5, 7, 9, 1, 3, 2, 4, 6, 8)
D： (4, 6, 8, 2, 1, 3, 5, 7, 9)
本文選取交叉概率為£=0.8,即對每一條染色體，選取隨機數Pe[0,l],若 P<PC，則對染色體進行交叉操作。
5.選擇算子
遺傳算法中，適應度越高的染色體遺傳到下一代的概率越大，即被選擇的概 率越大。本文中每一條染色體被選擇的概率為：
1=1
選擇概率高的染色體被選中遺傳到下一代，產生新的種群。
6.變異算子
變異操作可以使遺傳算法具有局部搜索能力，同時可以提高種群多樣性、避 免遺傳過程陷于局部最優解。由于本文中的基因表示揀選的商品，所以基因不能 憑空消失，也不能隨意插入原染色體不存在的基因，故采用換位變異的方法。設 每條染色體變異的概率化=0.001,對于被選中進行變異操作的染色體，對其第
i位基因產生隨機數7^ 6[0,1], P最大的兩位基因互換位置，例如：
染色體X (1, 2, 3, 4, 5)
假設其被選中進行變異操作，且珀=0.1,馬=0.2, £=0.3,弓=0.4,人=0.5, 則第四位、第五位基因進行互換，變異后產生新染色體Y (1, 2, 3, 5, 4)。
7.進化終止條件
為了提高運算效率并得到滿意的運算結果，遺傳算法需要設置進化終止條件, 本文采用每次迭代的結果相差3以內時終止遺傳算法。
5.4.4算法實現與分析
本路徑優化算法的實現在前端使用JavaScript代碼實現。其核心代碼如下所 XjU O
function gaSearch(iteratorNum, chromosomeNum) {
var chromosomeMatrix = createGenerationQ;
for (var itlndex=l; itIndex<iteratorNum; itlndex++) { calAdaptability(chromosomeMatrix); cal SelectionProbability(adaptability); chromosomeMatrix = createGeneration(chromosomeMatrix);
}
}
其中，createGeneration函數為初始化種群第一代個體的代碼函數， calAdaptability函數為計算上一代染色體的適應度，calSelectionProbability為計算 自然選擇概率的函數，最后通過向createGeneration函數中傳入當前個體，生成
下一代新的個體。通過for循環，不停地對種群進行衍化、迭代，直到滿足終止 條件。
假設某一時間段內銷售中心收到5份訂單，將所有訂單匯總分類后得出貨品 所占的貨位數為15個，分別為
(1,1,1),(3,1,8),(4,1,14),(5,1,15),(1,1,9),(2,1,10),(3,1,1), (4,1,10),
(5,1,6),(1,0,19),( 3 ,0,16), (5,0,17), (4,0,16) ,(2,0,19),(1,0,14)。
針對仿真所使用的數據，仿真結果如圖5-20所示，算法逐漸收斂于130。
基于遺傳算法的揀貨路徑優化
採肖貉徑長度
圖5-20仿真結果
若不采用優化后的路徑，則揀貨人員需要對所有的通道與貨架做一次穿越式 訪問，如所示。根據貨架的數量和寬度，可知揀貨員行走的距離為162。通過仿 真實驗與優化前的數據對比，得出如表5-1的對比數據。
表5T優化效果對比
揀貨路徑 行走距離 優化效果
未優化 162 0
遺傳算法優化 130 20%
從實驗數據得知，當揀貨員采用傳統的穿越策略進行揀貨作業時，需要穿越 有待揀選貨物貨架所在的整條巷道，行走距離較長且浪費時間；若采用遺傳算法 優化揀選路徑，可以顯著減少行走距離，大大提高揀選作業的效率。
為避免實驗結果的偶然性，本文按照第一次實驗的步驟，再次隨機生成若干 訂單，進行了 6次實驗，實驗數據如表5-2所示。
表5-2遺傳算法優化揀選路徑各次實驗結果
實驗次數 傳統揀貨路徑 遺傳算械化路徑 優化效果(％)
1 239 184 23.01
2 251 187 25.50
3 242 201 16.94
4 219 175 20.09
5 243 179 26.34
6 207 182 12.08
由實驗結果可知，使用遺傳算法優化揀選路徑，可以顯著減少行走距離，大 大提高揀選作業的效率。
5.5本章小結
本章介紹了對于物流信息管理系統的具體實現方法和效果。首先從總體上, 對系統的前端和后端架構做了詳細的介紹，隨后針對系統的每個功能模塊，介紹 了具體的實現方法和效果。最后，本章詳細描述了使用遺傳算法優化揀貨路徑的 具體實現方案，給出了從模型建立到問題求解的詳細流程。
第六章系統測試
6.1概述
系統測試是指根據系統的功能需求分析和設計，把整個系統的硬件、軟件和 操作人員當作一個整體，在此基礎上對系統進行測試。通過系統測試，可以在系 統正式投入使用前發現系統的缺陷和錯誤，并及時進行修復，避免造成大規模損 失。系統測試的全面、有效進行，能夠保證系統在投入使用后，能流暢、穩定的 運行，并具有一定的應對突發狀況的能力。
物流信息管理系統功能眾多，各個模塊之間聯系緊密，并且有頻繁的數據流 通和更新，任何一個模塊的處理出現錯誤或漏洞，都可能造成整個管理過程的數 據錯誤，給物流企業造成經濟損失。因此，物流信息管理系統的測試，必須針對 所有模塊的功能，做出全面的測試。
為保證物流信息系統功能完善，系統健壯，本文從功能和性能兩方面對系統 進行了測試⑷〕。
6.2測試環境
基于Node.js單線程運行、無需占用過多內存的優勢，與Apache、Nginx等 服務器相比，Node.js服務器對機器的性能要求較低，無需購置超高性能的服務 器。因此本系統的測試環境采用了內存容量較小、CPU處理速度快的阿里云服務 器作為測試服務器，客戶端采用平時常見的計算機作為測試客戶端，其具體配置 如表6-1所示：
表6-1測試環境信息表
服務器名稱 配置信息
阿里云應用服務器 CPU2 核 2.5GHz;內存 8G；硬盤 300G； 系統 Linux RHEL 6.3
客戶端1 CPU 單核2.3GHz；內存8G；硬盤500G； Windows 10 系統；Chi'ome 瀏覽器
客戶端2 CPU單核2.3GHz；內存8G；硬盤500G； Windows7系統；Chrome瀏覽器
6.3功能測試
為了能更加快捷、更加全面的對系統功能進行測試，也為了方便在增加系統 功能后進行多次迭代測試，本次功能測試使用了 ATF自動化測試系統進行測試。
6.3.1 ATF自動化測試系統介紹
ATF自動化測試系統是本實驗室自主研發的、基于元素庫與對象庫的具有 可視化界面的測試系統。ATF系統使用用戶視角對Web系統中的操作對象進行 邏輯劃分，并將其抽象為頁面控件，讓測試人員無需關注被測系統背后的自動化 對象關系結構，而是使用可視化的操作行為完成對系統的測試。
不同于傳統的測試方法，ATF自動化測試系統通過對基礎腳本配置不同的 數據和步驟，批量生產大量用例腳本，以此覆蓋被測系統功能點的主干流程、分 支流程，來滿足不同用例的需求。同時，ATF的執行調度系統能夠對自動化測試 腳本集進行腳本篩選、腳本分發以及執行異常處理，能夠實現多執行機的并發運 行，并且進行執行機的負載均衡。
ATF實現了將測試過程中不同階段的管理、資源分配、測試執行有效整合, 在提高測試效率和測試質量的道路上邁出了一大步。
使用ATF自動化測試系統的操作流程如圖6-1所示。
6.3.2 ATF測試系統測試步驟
在使用ATF系統進行測試之前，首先需要建立相應的測試項目和測試系統, 本次測試新建的測試系統為'物流信息管理系統'，測試項目為'物流信息管理 系統測試'。下面將對使用ATF自動化測試系統的過程進行詳細敘述。
自動化構件維護
Web頁面上的各種元素的類型基本都是固定的，如輸入框、按鈕、下拉框等。 我們需要對這些元素的類型進行總結，并抽象出對應的自動化構件。在本次測試 中，將維護一份基本網站的抽象架構，并在架構中創建一系列的自動化構件。如
圖6?2所示。其中含有的自動化構件類型為：文本輸入框textarea控件、圖片展 示框image控件、輸入框webedit控件、按鈕webbutton控件等。
三ATF 芝…
疫件矣
■S«
圖6-2自動化構件維護圖
創建測試功能點
在測試過程中，需要對系統的功能點進行劃分。每個功能點為一系列操作之 和，如用戶登錄功能點，則需要打開頁面，輸入相關信息并點擊登錄按鈕。本次 測試中，按照不同的功能模塊，分為以下功能點:登錄、采購申請、采購管理、貨 位管理、新建庫存商品、入庫管理、入庫管理查詢、出庫管理、出庫記錄查詢、 調撥管理、盤點管理、貨物分派、訂單查詢。詳細的功能點管理界面如圖6-3所 示。每個功能點創建之后，需要對功能點進行元素庫與對象庫的維護，添加該功 能所用到的元素與對象，同時編寫好基礎腳本。
=ATF
圖6-3功能點管理
創建測試用例
測試用例（TestCase）是為某個特殊目標而編制的一組測試輸入、執行條件 以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。在ATF系 統中維護測試用例，可以方便迭代測試，提高多次測試的效率和準確性。
在本次測試中，每個功能點都必須設置多個測試用例，測試不同的操作和輸 入情況下，系統能否做出正確的反應。
測試用例創建如圖6-4所示。
添加用例
案例編號* 05319384 顯示詳情
后綴有•為必填項目
登錄測試點 片試任務* 普通測試 本號 1.0
物流信息管理系統（請勿硼: 功能點* 采購申請
注案例類 聯機 2級
1 2審者 1 : 執行者 1
評審通過 亍方式 自動化 7理方 腳本
■'* 用于測試登錄功能長否正常
i- 打開頁面-> 輸入用戶名-> 輸入密碼?> 點擊登
錄
* 成功I
圖6-4添加測試用例
需要注意的是，在創建測試用例時，執行者的選取需要和當前登錄用戶保持 一致，并且執行方式應選取自動化執行。
測試用例維護表格如圖6?5所示。
=ATF 壬曲•
■ - ；.i m 五 r.!--
顯示晞選 +添加 ?導入 ?導入記最 ■導出 O更改多種用例信息
奚例編號 功RE點 竇僥組成類型 狀念 關聯■本名稱 作看 執行者? 評審者 執行方式
05311035 5惠K理 系細請勿99住） 單用例 評審通過 查詢入庠列喪 chai 1 自動化
05311036 孑矗It理系緩（請勿99詢 出庫管湮 童洵岀庫記錄 chai chai 1 自動化
05311037 r息■理系歩（請勿■除） 產存商品驚玄 % 單用傍 評審通過 童詢列衰 (^al chai 1 自動化
評審通過
05311038 理系統（傭勿 新It庠存商占 、 越用例 新越失敗 chai chai 1 自動化
06020857 ■流a ［患*理JMt（請勿■隊） chai chai chai 自砂化
05311014 FJRKW系墩01勿翕渤 采陶申iH •用例 評審週過 職購成功 chai chai 1 自動化
05311015 、鼻蕾理系軟（謂勿flKINn 與購申請 潭加商品失散 chai chai chai 自動化
05311016 ■息■理系繃請勿■韻 •用例 評宙ifi過 采購失數 chai chai chai 自動化
05311017 H息■理 豪統（請 勿 韻勵 采腋申謂 單用例 評審週過 采購失敗2 chai chai chai 自動化
圖6-5測試用例展示
配置測試資源
編寫好測試用例之后，需要對每個測試用例配置測試資源。測試用例只是代 表了需要測試哪些功能，以及測試的目的等，只有配置了測試資源，才能真正決 定執行機在測試時執行何種操作。
測試資源配置如圖6-6所示。
S ATF
使用執行機執行測試
將測試用例添加到測試場景中后，在測試計劃與執行頁面，將測試場景添加 到執行計劃中，即可執行測試用例。
測試執行頁面如圖6-7所示。
三ATF 是…
灌試計1),99
att-<unr>er-y1
? 止51行
圖6-7測試執行界面圖
首次對本系統進行測試的結果如圖6-8所示。本次測試針對本物流信息管理 系統的功能點共編寫了 26個測試用例，其中24個測試用例全部執行成功，1個 測試用例執行失敗，并跳過1個測試用例。
圖6-8初次執行結果圖
在對系統進行修復之后，所有測試用例全部成功。結果如圖6-9所示。
圖6-9修復問題后的執行結果圖
在使用ATF自動化測試系統對本系統進行了一系列的功能測試之后，測試 結果表明，本系統基本上完成了功能需求分析中所提出的目標，達到了企業預期 的效果，在功能方面滿足了投入正式使用的條件。
6.4性能測試
為了保證系統的用戶在使用系統時能快速加載頁面，獲得較好的使用體驗, 文章專門對系統頁面的加載速度進行了測試。如圖6-10所示，可以通過開啟瀏 覽器的開發者模式，觀察頁面的響應時間。
Range: 0 - 1.52 $
41£ ms ■ Loading
883.5ms U Scripting
32.3 ms ■ Rendering
23 ms ■ Painting
74.9 ms Other
480.5ms idle
圖6-10 Web頁面性能查看界面圖
在本系統中，為了更方便的對每個頁面的加載時間進行統計，使用了前端打 點的方案。前端打點是指利用瀏覽器提供的API,統計頁面從開始渲染到渲染完 成期間的時間間隔，并將數據發送到后臺。在經過一系列用戶的訪問之后，統計 數據如圖6-11所示。
頁面加載時間柱狀圖
圖6-11頁面加載時間柱狀圖
由柱狀圖可知，本系統頁面的平均訪問時間為1040ms,即1.04s,并且加載 最慢的頁面所需要的時間為1335ms，均低于1500ms,在可以接受的范圍內。因 此，對于系統的性能測試結果為通過。
6.5本章小結
本章對系統測試的概念進行了詳細的解釋，并闡明了系統測試的目的與意義, 并提出對本系統進行功能測試與性能測試。隨后本章介紹了對本系統進行測試時 所采用的測試環境，以及具體的測試用例和測試方法，并針對測試結果進行了分 析。通過對系統的各個模塊進行測試M2】，表明本系統在功能與性能方面實現了基 本的要求，滿足了其應用于企業的條件，并能夠為企業提高管理水平、減少管理 成本。
第七章總結與展望
7.1總結
近年來中國物流行業發展迅速，在經濟中占有越來越大的比重，但是與此同 時，社會物流總費用在GDP中的占比也較高，物流成本高昂成了一大難題。當 前的物流行業中國，小型物流企業、電商企業越來越多，但是對于這些企業來說， 落后的信息管理模式造成了人力成本增加，信息溝通不及時，服務質量低下等問 題，不僅不利于企業的綜合競爭，還提高了企業經營的成本。本文以某小型電商 企業的物流信息管理的業務需求為實際背景，采用當前具有較大優勢的Node.js、 SPA等關鍵技術，為該企業設計與實現了一套物流信息管理系統。
本文在以下幾個方面對做了詳細和深入的研究。
(1)針對本系統中所使用到的關鍵技術進行了詳細的介紹，并重點闡述了在 本系統中采用這些技術的優勢，并在對企業的業務需求進行深入調研的 基礎上，對系統的需求進行了詳盡的分析。
(2)在需求分析的基礎上，針對系統功能，本文從總體架構到模塊的具體功 能，做了詳細的設計，給出了模塊的功能組成和流程圖，并且針對用到 的MongoDB數據庫文檔，給出了每個文檔的具體設計。
(3)最后，本文給出了本系統使用Node.js實現的具體流程和界面，并針對各 個模塊最終實現的功能做了介紹。同時，為了保證本系統完成了全部的 功能，并滿足投入企業使用的條件，本文對系統做了全面的功能測試和 性能測試，結果表明，本系統達到了預期效果，可以投入企業的實際使 用中。
本系統針對企業的實際業務需求，采用了 Node.js等技術，研究、設計并實 現了完全符合該電商企業需求的物流信息管理系統，能夠在企業的物流管理中， 提高物流各環節的管理效率，降低企業成本，同時，能夠促進物流行業內信息管 理系統的普及與升級，具有相當重要的意義。
7.2展望
物流信息管理系統的建立不但要符合物流企業的具體需求，還應該最大化的 方便工作人員進行使用。本系統依據了現有的業務需求和企業規模進行設計與實 現，并且限于人力與資源等問題，本系統仍存在一些不足，主要體現在以下方而：
(1).考慮到當前企業的物流信息規模中等，所以沒有發揮Node.js的多進程 優勢。
(2).考慮到當前該電商企業只有一個倉庫，因此倉庫管理部分沒有增加多倉 庫管理功能。
(3).沒有為系統提供移動端適配的系統界面，移動辦公較為困難。
(4).系統暫時未提供操作日志功能。
本系統應該在日后的工作中，著重改進以上幾個方面，使本系統提供更好的 服務，更加人性化的使用界面，并通過操作日志幫助工作人員排查錯誤。
參考文獻
[1]金妲穎.基于蟻群算法的X物流企業配送中心車輛調度系統設計與實現[D]. 北京：北京交通大學,201&
[2]鮑飪.中小企業物流管理的現狀及思考[J].現代經濟信息,2016(12): 93.
[3]魏際剛.中國物流業發展的現狀、問題與趨勢[J].北京交通大學學報(社會科 學版),2019(01): 1-&
[4]物流業發展中長期規劃(2014-2020年)[J].綜合運輸,2014(10): 78-86.
[5]劉宏.基于電子商務下的我國物流業發展的新思路[J].經濟師,2019(01): 286-287.
[6]馮潔心.大數據時代下物流信息管理系統的現狀及前景分析[J].商場現代化, 2017(13): 51-52.
[7]李藝.L公司物流信息管理平臺設計和實施研究[D].南京：南京理工大學, 2018.
[8]Sethanan K. Toward Sustainable Operations of Supply Chain and Logistics Systems[J]. Ecoproduction, 2015.
[9]Masmoudi M, Benaissa M, Chabchoub H. Optimisation of e-commerce logistics distribution system: problem modelling and exact resolution[JJ. 2014, 6(3/4): 358.
[10]Kiessling T, Harvey M, Akdeniz L. The evolving role of supply chain managers in global channels of distribution and logistics systems[J]. International Journal of Physical Distribution & Logistics Management, 2014, 44(8/9): 671-68&
[11]李敷基于J2EE技術的物流信息系統的設計與實現[D].長沙：湖南大學, 2017.
[12]楊冬梅.基于J2EE的高校自主招生管理系統的設計[J].電腦知識與技術, 2016,12(17): 47-48+51.
[13]王志軍.從管理系統導出數據批量提取房號信息[幾電腦知識與技術(經驗 技巧),2016(06): 38-39.
[14]方驥，謝慧敏，楊長春.基于Delphi的項目數據庫管理系統的實現[J].中國 管理信息化,2016, 19(16): 37-38.
[15]劉津津.信息化物流系統的發展[J].農家參謀,2019(01): 239.
[16]萬里晴，楊浩.探究基于V8引擎的Node.js在各應用領域的發展[J].通信世 界,2015(13): 97-97.
[17]王金龍，宋斌，丁銳.Node.js:一種新的Web應用構建技術[J].現代電子技術， 2015(6): 70-73.
[18]楊曉婷.基于Node.js的基礎框架設計與實現[D].北京：北京郵電大學,2017.
[19]樸靈.深入淺岀Node.js[M].北京：人民郵電出版社,2013:13.
[20]許會元，何利力.NodeJS的異步非阻塞I/O研究[J].工業控制計算機,2015(3).
[21]吳博.基于Node.js的高并發在線商城系統的設計與實現[D].北京：北京郵 電大學,2016.
[22]陸凌牛.Node.js權威指南[M].機械工業出版社,2014.
[23]楊振宇.基于Nodejs的云PACS系統的設計與實現[D].北京：北京交通大學, 2017.
[24]Chaniotis IK, Kyriakou KI D,Tselikas N D.Is Node.js a viable option for building modem web applications? Aperformance evaluation study [J]. Computing, 2015,97(10): 1023-1044.
[25]沈姝.NoSQL數據庫技術及其應用研究[D].南京：南京信息工程大學,2012.
[26]席季季.基于nodejs的web應用系統高并發處理模式的研究與實現[D].[北 京]:北京郵電大學,201&
[27]梁睦雨.基于Web的應急成品糧調度系統實時性通信的研究與實現[D].[北 京]:北京郵電大學,2017.
[28]徐玖超，程文琪.Web單頁技術在桌面程序開發中的應用[JJ.計算機產品與 流通,2018, 2⑵:3&
[29]喻好，陳鋒，程仁貴.對單頁Web應用開發探究及應用[JJ.福建電腦,2017, 33(02): 136-137.
[30]杜艷美，黃曉芳.面向企業級web應用的前后端分離開發模式及實踐[J].西 南科技大學學報,2018,33(2): 83-87.
[31]HOLLAND J.H.Adaptationin natural and artificial systems[M]? Aim Arbor: University of Michigan Press, 1975.
[32]DeJONGKA ? The analysis of the behavior of class of geneticadap-tive systems[D]. Ann Arbor: University of Michigan, 1975.
[33]D.E. Goldberg, J.H.Holland. Genetical gorithms in search,optimization and machine leaming[M]. Boston: Addison-Wesley Longman Press, 1989.
[34]Zu Qiaohong?Wu Ting. Application of radio frequency positioning technology in TDOA system based onimproved genetic algorithm]J]. International Conference on Pervasive Computing and Applications, 2010,10(5): 167-171.
[35]Chang wook Ahn,R.S.Ramakrishna, A genetic algorithm for shortest path routing problem and the sizing of populations . IEEE Transaction on evoluti onary computation]!], VOL. 6, NO.6, DECEMBER 2002.
卩6]馬永杰，云文霞.遺傳算法研究進展[幾計算機應用研究，2012(4): 1201- 1206,1210.
[37]韓萬林，張幼蒂.遺傳算法的改進[J].中國礦業大學學報(自然科學版)， 2000(1): 102-105.
[38]朱立元.S企業物流管理信息系統的設計與實現[D].長春：吉林大學,2017.
[3刃 Drury. Towards More Efficient Order Picldng[M].Cranfield.UK:The Institute of Materials Management. 1988.
[40]孫慧，張柯，張富金等.基于遺傳算法的雙區型倉庫人工揀貨路徑優化[JJ. 青島大學學報(工程技術版),2014, 29(1): 78-82, 94.
[41]祁志武.地質標本虛擬學習平臺構建[D].長江大學,201&
[42]何嬪媛.基于嵌入式Web服務器的遠程控制系統研究[J].信息技術,2017(07): 139-141.
上一篇：基于EPC物聯網和RFID的奶牛精細養殖信息管理系統
相關標簽:
