基于Android的鐵路貨運信息管理系統設計

發布時間：2023-07-17 14:40

摘要 I

Abstract II

第一章緒論 1

1.1課題研究的背景與意義 1

1.2國內外鐵路貨運信息系統的研究現狀 2

1.2.1國外研究現狀 2

1.2.2國內研究現狀 2

1.3移動客戶端在鐵路的發展現狀 3

1.4本文主要內容和組織結構 4

本章小結 5

第二章系統相關技術介紹與分析 6

2.1移動互聯網與Android系統優勢分析 6

2.2服務器端相關技術 7

2.2.1MVC三層架構設計模式 7

2.2.2數據交互的研究 8

2.3數據庫MySQL分析 8

2.4客戶端相關技術 9

2.4.1Android系統架構及基本組件 9

2.4.2移動客戶端開發工具Android Studio 10

本章小結 11

第三章系統的需求分析與功能描述 12

3.1擬解決的問題 12

3.2系統整體架構分析 12

3.3系統的功能需求分析 13

3.4系統的非功能需求分析 14

3.5移動客戶端功能模塊劃分 15

3.6移動客戶端主要功能模塊描述 17

3.6.1發貨及拼貨模塊 17

3.6.2物流查詢功能模塊 19

3.6.3發貨訂單管理模塊 20

3.6.4拼貨訂單管理模塊 21

本章小結 21

第四章拼貨裝載問題研究 22

4.1問題描述分析 22

4.1.1拼貨裝載問題描述 22

4.1.2拼貨優化概述 22

4.2拼貨裝載的影響因素及相關參數 23

4.2.1中途站停車時間 23

4.2.2班列編組輛數 23

4.2.3條件假設 24

4.2.4相關參數 24

4.3裝載問題模型構建 25

4.3.1目標函數 25

4.3.2約束條件 26

4.4模型求解 27

4.4.1遺傳算法概述 27

4.4.2拼貨裝載遺傳算法設計 28

4.5算例演示及結果分析 30

本章小結 31

第五章鐵路貨運信息管理系統的設計 32

5.1系統的結構設計 32

5.2服務器端模塊設計 32

5.2.1服務器與移動客戶端通信設計 32

5.2.2服務器與移動客戶端數據處理設計 34

5.3系統數據庫設計 34

5.3.1數據庫表設計 35

5.3.2E-R模型構建 38

5.4客戶端模塊設計 39

5.4.1主界面設計 39

5.4.2用戶管理功能模塊設計 40

5.4.3發貨及拼貨功能模塊設計 41

5.4.4支付功能模塊設計 42

5.4.5物流查詢功能模塊設計 43

5.4.6發貨（拼貨）訂單管理模塊設計 43

本章小結 44

第六章客戶端系統實現與測試 45

6.1移動客戶端實現 45

6.1.1主界面的實現 45

6.1.2用戶管理功能的實現 45

6.1.3發貨及拼貨功能的實現 47

6.1.4支付功能的實現 48

6.1.5物流査詢功能的實現 49

6.1.6發貨訂單管理的實現 49

6.1.7拼貨訂單管理的實現 50

6.2移動客戶端系統測試 51

6.2.1系統測試概述 51

6.2.2客戶端兼容性測試 52

6.2.3客戶端功能測試 53

6.2.4系統性能測試 55

本章小結 57

結論 58

參考文獻 60

附錄A關鍵程序代碼 62

攻讀碩士學位期間發表的學術成果 70

致謝 71

第一章緒論

1.1課題研究的背景與意義

隨著鐵路行業的飛速發展，鐵路信息化已經進入新的歷史階段。鐵路貨運作為鐵路發展的重要組成部分，在國民經濟中占據著舉足輕重的地位，與之相關的信息化發展也日益重要［嘰

近年來，運輸量的增加，促進了多種運輸方式的蓬勃發展。但是發展鐵路信息化的同時，鐵路運輸會出現各種問題，例如如何將鐵路貨運信息管理系統變得網絡化和智能化，如何采用全新的方式來吸引客戶群從而提高鐵路貨運的使用頻次等。隨著鐵路貨運標準的提升，現有的系統已經不能滿足需求，并出現了 “信息孤島”的問題SI。現代鐵路貨運需要更網絡化、智能化的管理，既要方便用戶能夠隨時查詢貨物信息又要從管理層面提高貨運的效率，并在保證貨運信息準確性的同時保障信息傳輸的高效性。

對鐵路貨運信息管理系統進行網絡化和智能化的管理，首要解決的是鐵路管理員和用戶之間對于鐵路運輸資源、方式和貨物運輸需求等信息的互通，著手解決上文提到的 “信息孤島”問題。針對上述的問題，要求用戶和鐵路管理員之間能夠及時準確知情貨運信息，這需要對鐵路貨運資源、需求信息等數據集中到智能化管理平臺，并對其進行管理。目前，在水運和空運領域，信息化技術已得到廣泛使用，但是鐵路貨運運輸效率還是有待改進。隨著經濟的高速發展，物流信息也在快速變化，行業和企業的需求日益增長，同時對鐵路貨物運輸的成本也有了新的要求。因此，采用新技術完善鐵路貨運組織、物流方式，使得整個運輸過程中站點靈活、能夠提前優化線路，從而對成本進行制約。這不僅對現代物流進行了補充，而且提高了運輸效率和資源的利用率。

除此之外，隨著信息和通訊技術的迅猛發展，對于手機功能和應用的需求也在不斷增強⑷，這就使得智能手機已經正式成為了現代通訊工具，智能手機應用也在各個領域中普及開來〔5-6］,例如運輸、交通、醫療等。在未來的發展中，移動電子商務一定會帶動新的一次科技革命，而手機上實現鐵路運輸管理就意味著這種革命性的變化［胡。若將鐵路運輸與移動智能終端完美的結合在一起，不僅能夠解決上述的問題而且還可以提升鐵路貨運的服務品質。

對鐵路貨運進行優化的最終目的是為了能夠實現對貨運更有效的管理，而拼貨裝載問題是鐵路貨運管理中重要的一部分，拼貨裝載運輸能夠提高貨運運輸的空間利用，從而降低運輸成本，進而提高鐵路貨運的運輸效率，也對鐵路信息化的經濟效益具有促進作用。若在鐵路貨運信息系統的客戶端基礎上，加入拼貨管理設計，兩者結合，可以實

現鐵路貨運的動態管理，必定會有良好的發展前景。

綜合以上所有的分析，本文開發了一款基于Android的鐵路貨運信息系統客戶端，該客戶端結合新技術對鐵路現有貨運物流方式起到了有益的補充，這不僅提高了運輸效率而且提高了資源的利用率，對鐵路信息化的經濟效益具有重要意義。

1.2國內外鐵路貨運信息系統的研究現狀

1.2.1國外研究現狀

隨著社會的發展，計算機和網絡技術的廣泛應用在一定程度上大大提高了人類的生產力和效率。鐵路部門是國民經濟的主干道，鐵路信息的收集、整理和應用已成為制約鐵路運輸效率提高的重要因素冏。因此，各國鐵路部門高度重視鐵路行業的信息化建設, 為鐵路信息化的發展做出了很多貢獻：

二十世紀六十年代，在美國，計算機技術在鐵路貨運中得到了普遍使用，許多鐵路相關貨運機構開始使用運輸信息管理系統，可實現對鐵路貨運的高效控制，包括貨物信息和狀態管理、貨運清算、客戶信息處理等［⑼。

二十世紀七十年代，法國國有鐵路公司（SNCF）建立了集中貨運管理信息系統（GCTM）,主要用于實現銷售管理、貨車應用和統計會計等功能。在此基礎上，構建了三個全方位貨運管理信息系統：新的貨運管理信息系統（NEW）,用于配置統一的貨運管理計劃；貨運商業業務運營管理信息系統（SESAME）,用于整合和管理貨運合、運輸成本、財務賬單等貨運信息；貨車檢修管理信息系統（ESTER）,構建貨運車輛數據庫，實現車輛信息全過程的跟蹤管理，為車輛維修部門提供準確的維修決策信息，降低維修成本⑴】。

二十世紀九十年代，德國鐵路公司建立了貨物運輸控制系統，完成貨物到達、運輸管理、貨物結算管理、列車運行信息管理、列車維護管理和編組站運營流程管理〔I%在貨運結構、營銷、客戶服務等方面，加拿大國家鐵路運輸公司（CN）建立了貨運生產信息化管理系統，實施貨運生產服務的綜合管理【刃。

隨著二十一世紀計算機技術的發展，鐵路貨運信息化的步伐加快。德國成立了杜伊斯堡客戶服務中心，該中心采用了大量的信息交換和處理技術。李克［⑶提到日本通過全球衛星定位實現了對所有鐵路貨運車輛的跟蹤和管理，并設計了集裝箱信息管理系統。

1.2.2國內研究現狀

中國進入了信息化快速發展的關鍵時期，主要集中在業務系統的建設和優化兩大方面，1999年原鐵道部進行了全路初次鐵路信息化總體規劃研究，在2000年10月本項總體規劃通過鐵道部專家會審。2004年中國鐵路信息化辦公室正式成立，2005年1月正式發布《鐵路信息化總體規劃》。2009年鐵路客戶服務中心正式開通運行，鐵路信息化建設進入到了新的歷史時期【9］。

北京鐵路局豐臺西站通過對貨物編組的方式構建了貨物監控平臺，雖然在原有的基礎上提升了整體運輸效率，但是由于實際作業過程中運用到的平臺及操作手段依然無法滿足鐵路不斷增加的貨運作業總量，因此改進現有的貨物運輸方式迫在眉睫［⑷。

石家莊南站提高鐵路貨物運輸工作效率通過采用減小時間間隔的方式，設計了綜合運輸信息管理系統。蘇家屯站為解決上述問題所采取的辦法是通過對比分析車輛信息、貨物運輸、財務統計等關鍵影響因素，設計了貨物運輸全生命周期管理【12】。

從鐵路運輸安排角度上講，傳統鐵路貨運模式相對單一，對客戶貨運信息的掌握來源缺乏，從而導致運輸效率在一定程度上降低。且現行的多種管理系統都不能從貨物組合方式出發最大程度提高發貨效率、減少資源浪費。從貨運客戶體驗上講，現有鐵路貨運管理系統，往往沒有給客戶足夠的選擇空間，甚至缺乏能夠提供諸如下單車次推薦、貨物運輸狀態查看等服務的平臺，影響用戶使用體驗。相比于針對鐵路客運的“鐵路 12306”用戶APP而言，貨運方面幾乎沒有在客戶層面的信息化管理方案，這在日益看重服務品質且高度信息化的當代社會非常容易造成客戶群體的流失。

1.3移動客戶端在鐵路的發展現狀

移動終端的市場在不斷地發展壯大，其中Android系統是移動終端危要代表。隨著該技術的不斷發展，鐵路部門也在不斷地吸引大量的新技術應用在其中。例如文獻［15］是2017年設計的一款基于Android的鐵路快運貨物的信息管理系統，該系統設計不繁瑣，易上手，只要有網絡就可以隨時對物流信息進行查詢，充分體現了移動終端的便攜性；文獻［16］于2018年在深入分析了貨票相關業務流程的基礎上，總結出傳統的紙質貨票工作效率不高的問題，從而導致部門之間信息資料共享困難等各種問題，從而提出了基于電子貨票形式對業務辦理流程和方式進行優化，解決所存在的問題。最后在對貨運 APP設計與開發上面進行完善，設計環節更加人性化，為后期鐵路系統的升級優化提供了較強的借鑒意義；文獻［17］于2018年研究基于Android的客運列車服務系統APP,目的是提高客運列車服務質量，增設了很多相關的功能，更加便捷。

通過對這些文獻的分析可以知道，釆用客戶端進行信息展示是現在大部分信息的呈現方式。同時也為保證鐵路通信緊隨通信技術的發展，鐵路部門在迅速地推進鐵路信息化。因此，移動技術在未來的鐵路運輸中一定能夠成為最生動且最具有感染力的重要組成部分。

1.4本文主要內容和組織結構

為了加強我國的經濟建設和國民經濟，完善鐵路貨運信息管理系統是非常必要的，這也是我國運輸體系走向完善的必經之路。鐵路貨運是目前人們最常使用的一種貨運運輸方式，而在這中間結合新技術運輸，對其起到了一定的補充作用。

本客戶端主要依附于Android技術和鐵路貨運研究背景，結合鐵路貨運信息管理系統的研究現狀，對移動客戶端在鐵路中的現狀也進行描述。本論文針對鐵路運輸的現實情況，設置了三個使用權限，權限的使用者分別是貨運用戶、鐵路管理員和系統管理員，但由于本文的重點對象，因此后面只詳細對貨運用戶和鐵路管理員進行模塊設計，同時分析了 Android Studio和數據庫的相關技術知識在系統中的應用，對客戶端進行測試，使本客戶端成為一個良好適用平臺。

本文共設計六個章節，每個章節的具體內容如下：

第一章：緒論。首先介紹課題的研究背景與意義，并從鐵路貨運信息系統和移動客戶端兩個方面介紹發展現狀，最后對整篇論文進行主要內容和組織結構的介紹。

第二章：系統相關技術介紹與分析。首先對移動互聯網技術和Android系統優勢進行基本分析，突出介紹Android系統的特點，并對該系統所涉及的服務器端中MVC三層架構設計和數據交互進行介紹，接著對系統數據庫進行綜述，并突出MySQL的優勢, 最后對客戶端中的Android系統進行介紹且闡述Android Studio開發平臺。

第三章：系統的需求分析與功能描述。首先對該系統需要解決的問題進行綜述，并對系統的總體結構進行分析。然后對系統的功能需求進行闡述，對客戶端中的各個模塊進行詳細描述，最后針對非功能需求進行分析。分別從兩個權限角度完成各個模塊相對應的具體功能，整體構成了一個相對完整且連貫的客戶端。

第四章：拼貨裝載問題研究。本章主要介紹關于鐵路貨運優化的基本內容以及在其他運輸方式中的拼貨裝載問題描述，構建屬于本文的拼貨裝載模型并對其進行求解，同時對本文所涉及的遺傳算法的優化性能進行驗證，并在鐵路貨運信息管理系統客戶端中體現算法。

第五章：鐵路貨運信息管理系統的設計。本章主要對系統的整體結構進行設計，將系統分為服務端與客戶端兩個部分。針對服務器端模塊，設計了服務器端與客戶端之間的通信和數據處理設計，并對系統數據庫中的表和E-R模型進行構建；對于客戶端進行四個相對應的模塊，并對其進行詳細設計。

第六章：客戶端系統實現與測試。首先對之前設計的客戶端系統進行實現，并完成客戶端的兼容性、功能性和性能三方面進行測試，從而來驗證鐵路貨運信息管理客戶端的穩定性及準確性。

本章小結

本章從鐵路貨運信息管理系統客戶端的研究背景總結出采用移動端的優勢，接著闡述了當前國內外發展現狀并對移動客戶端在鐵路的發展現狀進行描述。課題針對鐵路貨運信息管理系統客戶端的研究與設計，主要目的是為了鐵路貨運信息管理系統能夠達到高效且便攜的管理需求，最后對論文整體結構以及內容安排做出說明。

第二章系統相關技術介紹與分析

選擇一款良好的移動客戶端運行環境，非常有助于達到客戶端穩定運行且界面友好的設計目的，期望該運行系統環境具備技術優越性和經濟適用性陰⑼，方便研究使用。而Android系統因其具備諸多技術優勢而得到研究者的廣泛青睞，其優勢包括開放源代碼、分層設計思想和架構簡單等冊21],故在本設計中采用Android系統為開發環境。

2.1移動互聯網與Android系統優勢分析

移動互聯網是以傳輸移動無線通信數據為紐帶，將客戶端融入到互聯網的通信方式中。隨著社會科技的不斷發展，4G移動通信已經成為了國民經濟發展中不可缺少的技術，何其具有■很重要的地位。而當今的研究熱度集中在4G推動移動互聯網的發展當中，獲得了不少專家學者的青睞㈤。

自從移動智能終端誕牛•以來，多個系統的版本不斷產生和更新，由最初諾基亞公司的Symbian系統到現在最流行的Android系統㈡刑。市場上雖然出現蘋果公司中的iOS 系統，但在當今社會，仍然無法撼動Android系統在市場的地位。這是因為Android操作系統有諸多優點【25-28],如圖2.1所示。

圖2.1 Android操作系統的優點圖

Fig.2.1 Advantages of the Android operating system

隨著社會的需求和現代科技的發展，人們越來越多的選擇移動終端進行操作，從最開始的私人電腦(personal computer, PC)端轉移到了手機移動終端岡。雖然兩者都可以滿足人們對電子設備的需求，但由于它們本身對終端和網絡的要求不同，移動終端比 PC端占據更大的優勢，如表2.1所示是移動終端與PC端特點對比。

表2.1移動終端與PC端特點比較表

Table 2.1 Comparison of characteristics between mobile terminal and PC terminal

設備便攜度網絡覆蓋安全性位置相關性

移動終端體積小，重量輕，便于手持 3G,4G,

WIFI 較高隨時獲取

PC端體積較大，重量略重，

不方便攜帶有線網絡略低獲取較慢

上述特性決定了移動終端在鐵路貨運信息管理系統中必將快速占領重要位置，成為未來鐵路貨運的重要發展方向，具有廣闊的市場前景和一定的發展空間。而移動終端優于傳統PC端的特性，必將使鐵路貨運從PC端向移動終端進行轉移。

2.2服務器端相關技術際

2.2.1 MVC三層架構設計模式

所謂的MVC (Model-View-Controller)設計模式即“模型一視圖一控制器”,是一種Android平臺中的應用程序所使用的設計模式。其主要作用是可以將邏輯和業務進行分離，這樣不僅可以減少程序存在的耦合性還可以提高代碼的復用性［"I。如圖2.2所示是MVC設計模式的原理圖⑶

視圖

圖2.2 MVC原理圖

Fig.2.2 Schematic of MVC

2.2.2數據交互的硏究

當用戶使用移動終端進行數據操作時，終端將用戶數據封裝成JSON格式傳輸至服務器，服務器通過對接收的JSON數據進行解析，在數據庫中執行相應地查詢寫入等操作，并將結果封裝為JSON格式發送至終端卩2-33］。交互過程如圖2.3所示"I。

Fig.2.3 Data interaction between mobile terminal and server terminal

2.3數據庫MySQL分析

圖2.4 MySQL數據庫優勢示意圖

Fig.2.4 The advantages of the MySQL database

本課題所設計的鐵路貨運信息管理系統需要憑借著可靠且大量的數據庫平臺才能完成數據的存儲與處理陰。而MySQL數據庫是最好的選擇。MySQL數據庫由于具有 “開放源代碼”的優勢，成為了很多人的選擇。MySQL數據庫優勢如上圖2.4所示。

將當下最流行的兩種數據庫進行比較，如表2.2所示。

表2.2數據庫類型比較表

Table 2.2 Comparison of database types

數據庫名稱類型占用內存市場占有率

MySQL 小型數據庫較小，150M左右 20%

Qracle 大型數據庫較大，3G左右 40%

該信息管理系統的數據庫中所存儲的數據是貨物的屬性等相關數據，”數據特點是小型數據且占用內存較小。針對鐵路貨運信息管理系統的數據特點，應該建"用MySQL數據庫對數據進行存儲和處理。

2.4客戶端相關技術

2.4.1 Android系統架構及基本組件

I. i mix內核層

Display 11 Caine r a 11 Blue moth I I Flash Momory I I~Binder (I PC)

Driver 11 Driver 11 Driver 11 Driver 11 Driver

USB Driver Keypad WIFI 11 Audio Power

Driver Drivnr 11 Dr i ver Maiiagrinipiit

圖2.5 Android平臺架構圖

Fig.2.5 Platform architecture of Android

Android平臺的架構主要包括五部分，分別是應用層、應用框架層、函數庫、Android 運行時和Linux內核層卩6】。平臺架構中的應用層包括一些日常核心的基本應用軟件，其中所包含的所有程序可以根據自身需求來對其進行選擇性的替換或直接使用，并且所有程序都可以同時執行"38〕。如圖2.5所示為Alldroid平臺架構圖［39】。

一般來說，Android平臺應用程序的開發需要由五個基本組件來支持，它們之間的關系如上圖2.6所示a⑷〕。

I外部事件

存儲設備

圖2.6 Android基本組件圖

Fig.2.6 Basic components of Android

2.4.2移動客戶端開發工具Android Studio

移動客戶端的設計開發環境是采用Java語言在Android Studio環境下完成的，相比最早的Eclipse,該系統運行比較流暢，運行速度也快，相對提供了一個比較強大的UI 編輯器，其具有可以將代碼自動保存和補充完全等功能。此外，Android Studio提供了相對完善的插件系統，此系統更加方便用戶進行開發和調試工作。如圖2.7所示是該開發環境的界面。

在開發過程中，采用的是夜神模擬器對客戶端功能進行檢測，并不是選擇Android Studio自帶的模擬器運行，其原因是客戶端中的功能運行效果可以在PC端模擬運行，這樣就可以在開發客戶端的同時通過模擬器在手機端的運行效果，方便在開發過程中可以及時對功能進行預覽，該客戶端實現的所有界面圖都是在模擬器下運行的。

^/kml version^-1. 0* encoding="utf-8" ：»

,'3 〈LinearLayout xmlns :android=*，http: //schemas, android, coni/apk/res/android** 孑 android:layout_width="match_parent" ?

android:layout_height-"match_parent"

android:orientatior)="vertical* •

<TextView

android: layout_width="njatch_parent*

android:1ayout_height=wwrap_content"

android:textSize="25dp"

android：paddingTop=*10dp*

android:paddingLeft="5dp"

android:text=*基本f自息：">

<EditText

android: layout_width="match_parent" -

android:layout_height="wrap_content"

android :background="Onul K : S.

圖2.7程序開發界面圖

Fig.2.7 Interface of program development

本章小結

本章從移動互聯網出發，分析了 Android系統優勢，將系統分為了服務器端和客戶端兩個部分，對服務器端中的MVC三層架構設計模式和數據交互進行研究，并對系統數據庫MySQL進行優勢分析，最后針對客戶端部分介紹了 Android Studio開發工具，為下文系統的設計與實現提供了扎實的理論基礎。

第三章系統的需求分析與功能描述

本章主要是對鐵路貨運信息系統進行需求分析和功能描述，由第二章對平臺及關鍵技術的介紹可知，一個管理系統的需求分析應該分為功能性和非功能性，并對系統客戶端中的模塊進行描述。為此，本章對上述三個部分進行了詳細的介紹。

3.1擬解決的問題

隨著鐵路的不斷發展，現如今的鐵路貨運信息管理系統進行發貨時，只能滿足單一貨物進行運輸，當車廂貨物不能滿足車廂數時，會造成貨物的極大資源浪費，從而降低鐵路的運輸效率，同時受到體制的影響，會造成資源分配不均勻，貨主對發出的貨物仍處于不知情的狀態。因此，在新的體制下需要滿足諸多需求，在保證鐵路貨運運輸有效性的前提下，移動智能終端是最好實現移動性的選擇。

針對上述情況，本文開發了一種鐵路貨運信息管理系統，其主要目的是要將復雜的鐵路貨運信息系統建立在Android移動應用終端上，將發貨管理、拼貨管理、物流查詢等多功能集中于一個信息處理平臺上。當用戶使用本客戶端時，不僅可以對貨物信息查詢，還可以對貨物的物流信息進行掌握；而對于鐵路管理員來說，利用客戶端可以對用戶的請求進行審批，并結合自身的優化模型，在拼貨前，向用戶提供最適合方案，從而提高發貨效率，以滿足整體信息管理系統的需求。

鐵路貨運信息管理系統是」個龐大而復雜的信息管理系統，對于貨運用戶來說，使用方便、數據信息準確及花費最少是最重要的。因此，本文所設計的鐵路信息管理系統是在遺傳算法的基礎上進行拼貨，并在后臺數據庫中不斷給出拼貨的最優方案，以保證鐵路貨運運輸效率。

3.2系統整體架構分析

本文所研究設計的系統是為了滿足鐵路貨運信息管理系統的需求，從而提高鐵路貨物在運輸過程中的效率。因此，想要達到對客戶端的預期目標，首先要對鐵路貨運信息管理系統的物理拓撲結構有一定的了解。在經過一系列調查研究之后，得到如圖3.1所示的物理拓撲結構圖。

從圖可知，整個系統一共分成了服務器端、客戶端和數據庫三部分。當用戶進行數據請求時，請求從前端向后臺進行傳輸，并將其保存在數據庫中，最后由后臺對數據進行處理。處理后將最終的反饋再給前端，這樣就完成了一個用戶與服務器之間數據傳送。

3.3系統的功能需求分析

隨著鐵路的快速發展，對其要求也在不斷提高，提高鐵路運輸的效率和不斷完善鐵路貨運信息系統是目前鐵路運輸業所追求的首要目標。要想實現這一目標，必須使鐵路運輸信息便于人們査看，方便使用，只有這樣才能實現對鐵路貨運信息系統的管理。為了更好地在實際生活中應用該系統，結合現有的理論知識水平，通過對餓斷部門的詳細咨詢和調查，總結鐵路貨運信息系統的具體需求如下： $

(1)登錄模塊。客戶端具有貨運用戶和鐵路管理員兩個使用權限，其中貨運用戶需要輸入自己的用戶名進行登錄，而鐵路管理員需要輸入工號進行使用客戶端。

(2)常用聯系人模塊。貨運用戶使用客戶端時，需要在提交訂單前選擇聯系人進行添加，對于聯系人來說，只有身份信息真實有效的用戶才可以進行添加或刪除。

(3)發貨及拼貨模塊。這個模塊由兩部分組成，其中發貨功能介入移動終端是為了縮短發貨時間，從而提高發貨效率；而拼貨模塊根據自己的需求，系統會結合實際情況向用戶提供路線和班次的選擇，以保證鐵路貨運的運輸效率。

(4)物流查詢模塊。用戶可以使用移動終端進行物流查詢，方便對已經發出的貨物進行查詢，到站后及時對貨物進行交接。

(5)發貨及拼貨管理模塊。鐵路管理員對用戶的請求進行審批，其中在拼貨管理模塊中，如果出現拒絕請求的情況，系統會根據需求給出幾個方案意見，其中包括最優方案。

基于以上的實際需求，本文將其融合在軟件開發中，并將運輸的實際情況通過軟件能夠更好地傳給用戶，從而提高了鐵路的運輸效率。

3.4系統的非功能需求分析

任何一個軟件系統，對其開發不僅僅要滿足系統的功能需求還要滿足系統中的非功能需求［42】。只有當兩方面同時滿足之后，設計出來的軟件才能真正滿足用戶需求。決定客戶端質量的根本是非功能需求，同時在某種程度上影響著客戶端的功能需求定義。下面列出的是針對本鐵路貨運信息管理系統客戶端包含的非功能性需求⑷】：

⑴執行性能

執行性能是指客戶端完成用戶所需要的功能時做出的反應效率。在本課題研究過程中，為了確保客戶端的功能反應速率較快一些，服務器端要求一般的功能響應時間不能超過5秒鐘，較為關鍵的功能響應不能超過3秒鐘；而在客戶端中，要求界面與界面之間的跳轉反應時間不能超過3秒鐘，而且第三方界面調用跳轉時間不能超過5秒鐘。

(2)運行環境需求

運行環境需求從宏觀上來看主要分為兩大類：軟件環境和硬件環境。同時在服務器端的選擇也是至關重要的，服務器端是可以保證用戶在一個相對流暢的信息環境中對自己所需要的信息進行查找。同時為了保證服務器穩定且能高效地運轉，選擇一個較為專業的服務器操作系統和理想的數據庫是一個最明智的選擇。鐵路貨運信息管理系統作為信息服務平臺，目前該平臺還仍然處于一個需要完善的階段，為了考慮系統開發成本等一系列相關問題。

(3)操作易用性

客戶端的界面設計需要簡單易用，信息清晰，能夠將數據實時更新，有良好的人機交互作用。

⑷自適應需求

所謂的自適應需求是為了滿足不同屏幕尺寸和不同分辨率的移動端可以給用戶帶來足夠完全的界面體驗而設定的。本客戶端的設計釆用的就是自適應處理方式對界面進行優化，從而實現所定義的控件可以進行不同屏幕尺寸和分辨率的自適應處理，盡可能使用戶得到更完美的用戶界面體驗。

(5)安全性需求

安全性需求主要包括兩個方面，一個是數據安全，另一個就是軟件自身安全。所謂數據安全是指需要在提交個人信息到數據庫的過程中，必須要進行密碼操作，防止被他人盜取個人信息；而軟件自身安全是指避免被其他人惡意攻擊而導致系統崩潰出現故障。此外，該客戶端中的數據庫還添加了對數據進行備份和核對數據進行數據恢復兩個功能，使得數據安全更加有保證。

3.5移動客戶端功能模塊劃分

在鐵路貨運信息管理系統中，貨運用戶是對鐵路運輸有需求的人員，用戶需要在發貨之前向鐵路部門發出請求，請求對貨物進行發貨或者拼貨，因此這類人群是作為鐵路貨運的第一類適用人群；同時鐵路管理員要對發送的請求進行審批，是否批準貨主進行發貨，真實透明的了解貨主的貨物信息；最后管理員有最高的權限，可以對貨物的屬性和信息做到最基本的查看，起到一個督察的作用，因此本次鐵路貨運信息管理系統客戶端分別為三種不同的使用人群而設計，即貨運用戶、鐵路管理員和管理員。三種角色既有相同的地方，又有自己的特殊的職責，下面針對客戶端使用的不同人群進行功能模塊

劃分，如下表3.1所示。表3」角色權限劃分表

Table 3.1 Division of role rights

角色角色間的關系窪

貨運用戶貨運用戶是使用該客戶端的主要群體，對貨物進行發貨及拼貨請求；

鐵路管理員承擔主要的審批請求工作，服務于貨運用八，管理和維護著該系統的使用和操作核心資源，對請求的處理有決定權；

系統管理員(最高權限) 系統管理員對貨物的屬性和信息能夠做到基本的查看，起到一個督察的作用； ...

(1)貨運用戶權限的功能模塊

圖3.2貨運用戶功能模塊劃分圖

Fig.3.2 Functional module division of freight users

貨運用戶是本客戶端的主要適用人群。因此，本客戶端針對貨運用戶進行詳細的模塊劃分，主要分成四個模塊，其中包括用戶管理模塊、發貨及拼貨模塊、支付模塊和物流查詢模塊。用戶管理模塊是針對用戶進行客戶端的注冊、登錄和貨運管理；發貨及拼貨模塊是用戶進行訂單填寫和系統針對用戶的需求進行路徑優化分析；當訂單批準且確定之后用戶使用支付模塊進行訂單支付；用戶對發出的貨物進行物流查詢。功能模塊劃分如上圖3.2所示。

(2)鐵路管理員權限的功能模塊

鐵路管理員主要是指鐵路貨運管理中的貨運負責人，管理著貨物的全部信息，無論是發貨還是拼貨，鐵路員工都能夠對所發出的貨物進行審批和管理，使用戶實現對貨物的管理和物流查詢，同時能夠對貨物的狀態信息進行更新。其中在拼貨管理模塊中，當管理者拒絕用戶的拼貨申請時，會結合實際情況，向用戶提供方案意見，并給出最優方案。功能模塊劃分如圖3.3所示。

圖3.3鐵路管理員功能模塊劃分圖

Fig.3.3 Functional division of railway administrators

(3)系統管理員權限的功能模塊

圖3.4系統管理員功能模塊劃分圖

Fig.3.4 Division of functional modules of system administrators

管理員主要是指該系統的最高權限使用者，其主要職能是進行工號的登錄后，可以對貨物的屬性等相關信息進行查看，有最高的審核權。功能模塊劃分如上圖3.4所示。

3.6移動客戶端主要功能模塊描述

在移動客戶端中常常設置幾個使用權限，是因為每一類人群所包含的使用功能都不相同，本客戶端提供三種不相同的使用權限，其中有些模塊是相同的，為了保證操作更好的進行，簡單闡述一下使用權限的功能模塊：

(1)貨運用戶：用戶管理、發貨及拼貨、支付功能和物流査詢四大模塊；

(2)鐵路管理員：用戶管理、發貨訂單、拼貨訂單、訂單統計管理査看四大模塊；

(3)系統管理員：管理員中心、權限管理、數據管理和軟件異常管理四大模塊。

客戶端中的每個模塊之間都是相輔相成的，不可分割的，但是每個功能的實現不是單獨就可以完成的，是需要有后臺數據處理系統作為支撐和輔助，本客尸護也是基于此設計出來的。因此，本文主要針對客戶端進行介紹，不對后臺進行詳細矗，且本文主要研究貨運用戶和鐵路管理員兩大權限進行分析，不對系統管理員模塊進行設計。由于篇幅問題，對本客戶端主要模塊進行模塊劃分描述。

3.6.1發貨及拼貨模塊

移動客戶端發貨及拼貨模塊的設計是針對貨運用戶進行設計的，是整個客戶端中最核心的模塊。貨運用戶可以根據自己需求對貨物隨時進行發貨、拼貨的管理。該模塊將發貨及拼貨的功能設計分為兩部分，一是用戶正常填寫訂單進行發貨，二是為了節約鐵路部門的資源和極大程度地提高用戶的個人利益，進行拼貨，用戶根據自己的需要進行地點選擇，由于方案太多，用戶不能精準的選擇出適合自己的方案。因此，用戶可以根據需求，對拼貨貨物類型、發貨時間和中途是否停站進行選擇，系統自動匹配出適合拼貨的1-3個方案，用戶按照自己的需要選擇一個適合自己方案，進行提交，使資源進行

合理的安排。其具體功能描述如下表3.2、3.3所示。

表3.2貨運發貨功能描述表

Table 3.2 Functional description of shipping shipment

用例名稱貨運發貨功能描述；

參與者貨運用戶；

前置條件用戶登錄鐵路貨運客戶端，進入客戶端主界面；

后置條件訂單提交并跳轉至提交訂單界面；

1 用戶進入鐵路貨運客戶端主界面并點擊“我要發貨”按鈕；

續表3.2

基本事件流 2 用戶輸入企業（客戶）名稱、聯系方式、起始站、終點站、貨物名稱、件數和總重量，并選擇預約日期，點擊"確定”按鈕，若企業（客戶）名稱為空，則進入備選事件流1;若聯系方式為空或者格式不正確，則進入備選事件流2；若起始站為空，則進入備選事件流3；若終點站為空，則進入備選事件流4；若貨物名稱為空，則進入備選事件流5；若件數為空，則進入備選事件流6；若總重量為空，則進入備選事件流7；若預約時間未選擇，則進入備選事件流8；若貨運信息均合法，則數據庫將確定該訂單并保存到訂單管理中心；

3 用戶進入提交訂單子功能，點擊“聯系人”按鈕；

4 用戶自行選擇需要填寫的聯系人，若常用聯系人列表中無所需要的聯系人信息，則點擊“添加”并跳轉貨運用戶管理中心進行添加；若選擇聯系人錯誤，則點擊修改，重新進行選擇；

5 確定訂單后，點擊“提交”，后臺發送給數據庫，跳轉到支付功能界面；

備選事件流提示企業（客戶）名稱不能為空；

2 提示聯系方式不能為空或不正確；

3 提加起始站不能為空;

4 提示終點站站不能為空；

5 提示貨物民稱不能為空；

6 提示件數不能為空；

7 提示總重量不能為空；

8 提示預約時間不能為空；

表3.3貨運拼貨功能描述表

Table 3.3 Functional description of freight consolidation

用例名稱貨運拼貨管理；

參與者貨運用戶；

前置條件用戶登錄鐵路貨運客戶端，進入鐵路貨運客戶端主界面；

后置條件訂單提交并跳轉至提交訂單界面；

續表3.3

基本事件流 1 用戶進入鐵路貨運信息管理系統主界面，并點擊“拼貨查詢”按鈕；

2 用戶輸入起始點位置、終點站位置，由于方案太多，用戶不能精準的選擇出適合自己的方案，因此，用戶可以根據需求，對拼貨貨物類型、發貨時間和中途是否停站進行選擇，系統自動匹配出適合拼貨的1-3個方案，數據庫會自動匹配1-3個符合要求的方案，用戶選好方案后，點擊“確定” 按鈕，若起始點位置為空，則進入備選事件流1；若終點站位置為空，則進入備選事件流2；若查詢后無方案提供，則進入備選事件流3；用戶按返回按鈕回到主界面；若有方案可提供，點擊方案后，點擊“確定”按鈕，跳轉到提交訂單界面，數據庫將確定該訂單并保存到訂單管理中心；

3 用戶進入提交訂單子功能，點擊“聯系人”按鈕；

4 用戶自行選擇需要填寫的聯系人，若常用聯系人列表中沒危所需要的聯系人信息，則點擊“添加”并跳轉貨運用戶管理中心進行添力若選擇聯系人錯誤，則點擊修改，重新進行選擇；

5 確定訂單后，點擊“提交”，后臺發送給數據庫，跳轉到支付功能界面；

備選事件流 1 提示起始點不能為空；

2 提示終點站不能為空；

3 提示無方案可供選擇；

3.6.2物流查詢功能模塊

物流查詢模塊是整個系統在發貨之后對貨物進行服務的模塊，本系統對物流查詢有兩種方式，一種是訂單號手動輸入，用戶在發貨之后，鐵路部門會對用戶貨物進行貼條碼，條碼上面不僅有二維碼還有訂單號，用戶可以手動輸入訂單號查詢，另一種是二維碼掃描，用戶將二維碼對準掃描的區域，就可以直接調出物流信息。物流查詢功能模塊如下表3.4所示。

表3.4物流查詢功能描述表

Table 3.4 Functional description of logistics query

用例名稱物流查詢管理；

參與者貨運用戶；

前置條件用戶登錄鐵路貨運信息系統客戶端，進入客戶端主界面；

續表3.4

后置條件訂單號輸入成功并跳轉至訂單查詢結果界面；

基本事件流 1 用戶進入主界面并點擊“物流查詢”或“條碼查詢”中心；

2 用戶輸入訂單號或對準二維碼進行掃描，點擊“查詢”按鈕，若訂單號為空或輸入錯誤，則進入備選事件流1;若二維碼未放入對應框內或沒有掃描正確，則進入備選事件流2；若訂單號輸入正確或掃描正確，則跳轉到訂單查詢結果界面；

3 訂單查詢界面可以點擊“更新”按鈕，將運輸狀態不斷更新；若訂單一旦重新輸入或返冋，則點擊“返回”跳轉到上一級界面；

備選事件流提示訂單號為空或輸入錯誤；

2 提示掃描二維碼信息失敗；

3.6.3發貨訂單管理模塊

發貨訂單管理模塊是鐵路管理員權限可以登錄的界面。用戶對貨物信息發岀請求，鐵路員工要針對這個請求判斷出是否批準該請求。在這個列表中，無法展示貨物的具體情況，當鐵路管理員想對這個貨物進行詳細了解時，可以點擊“詳情”按鈕，將展示出貨物的起止站位置、貨物類型、貨物名稱和重量。發貨訂單功能描述如下表3.5所示。

表3.5發貨訂單管理功能描述表

Table 3.5 Functional description of the delivery order management

用例名稱發貨訂單管理；

參與者鐵路管理員；

前置條件鐵路管理員登錄鐵路貨運信息系統客戶端，進入客戶端主界面；

后置條件訂單批準并跳轉申請成功界面；

基本事件流 1 管理者進入主界面并點擊“發貨訂單管理”模塊按鈕；

2 管理者查看列表，若想清楚地了解貨物詳情，點擊“詳情”按鈕；若批準成功，則進入備選事件流1;若拒絕申請，則進入備選事件流2；

3 點擊返回，返回上一界面；

備選事件流提示發貨訂單申請成功；

2 提示請輸入拒絕原因；

3.6.4拼貨訂單管理模塊

拼貨訂單管理模塊是鐵路管理員權限可以登錄的界面。在這個模塊中，批準貨物的過程跟發貨訂單模塊基本一致，但是這個模塊中若拒絕請求后，系統會根據用戶需求給出幾個可行的方案，其中還可以為用戶選出最優方案，當用戶在其中選擇可行方案后，即可申請成功，具體描述如表3.6所示。

表3.6拼貨訂單管理功能描述表

Table 3.6 Functional description of the consolidati on order management

用例名稱拼貨訂單管理；

參與者鐵路管理員；

前置條件鐵路管理員登錄鐵路貨運信息系統客戶端，進入客戶端主界面；

后置條件訂單批準并跳轉申請成功界面；

1 管理者進入主界面并點擊“拼貨訂單管理”模塊按鈕；

基本事件流 2 管理者查看列表，若想清楚地了解貨物詳情，點擊“詳情”按鈕；若批準成功，則進入備選事件流1；若拒絕申請，則進入備選事件流2；

備選事件流 1 提示拼貨訂單申請成功； *

2 提示請輸入拒絕原因； »

本章小結

本章主要研究了鐵路貨運信息管理系統所需要解決的問題，并對總體功能進行需求分析，針對客戶端功能模塊進行描述，詳細闡述了客戶端中兩個權限所包括的模塊，實現了對鐵路貨運管理移動客戶端的功能描述。

第四章拼貨裝載問題研究

針對第三章的模塊劃分，本章從拼貨的角度出發，重點研究在拼貨之前，鐵路部門會根據實際情況向貨運用戶提供最優路徑和最優方案，從而降低運輸中的空駛率和提高運輸效率。

4.1問題描述分析

4.1.1拼貨裝載問題描述

貨物運輸中比較重要的問題之…是貨物裝載的優化，主要涉及到以下4個方面的內容：

(1)運輸起點和終點。運輸的起止點設置主要與大規模的貨物集散地有關系，往往以貨物中心站為起止點。

(2)運行區間。運行區間的設置主要參考大多數貨物的目的位置，一般選擇線路穩定且流量密度大的線路。

(3)開行數量。根據貨運流量需要并參考車站適應能力與最大開行頻率。

(4)停車方案。列車運行速度固定條件下，影響運輸效率的因素為停車次數和每次停車時間。良好的停車方案，即可滿足貨主需求,同時可以提高運輸效率。

4.1.2拼貨優化概述

貨運中的拼貨裝載業務是指一個貨主所運輸的貨物數量不足以達到整個車廂時，鐵路貨運的相關部門會根據運輸產品的目的地和產品性質進行分類，將托運到同一個目的地的貨物，按照同類或者相似的產品集中到同一個班列中，使車廂達到滿載，由于整個車廂內是由不同托運人所托運的貨物裝載到一起，稱之為拼貨業務。

拼貨裝載問題本質上是一個復雜且繁瑣的過程，針對在拼貨之前，考慮到車站和成本問題優化路徑并判斷是否接收貨物，還需要受到多種因素的影響。其最終的目的是要在有限的空間范圍內實現更大的運輸效率，將復雜的拼貨問題進行簡單化，這不僅可以降低運輸成本還可以減少運輸中的資源浪費。從數學建模的角度出發，拼貨裝載問題是一個典型的組合優化問題。即在同時滿足多個約束條件時，采用對應的優化算法對目標函數進行求解，再由鐵路管理員對最優解進行合理安排，避免成本的浪費。

合理的拼貨優化不僅可以提高鐵路運輸效率，還可以減少資源浪費，節約生產成本。拼貨裝載本質上是對貨物運輸進行整體的優化，是在保證不損壞貨物的同時可以減少車廂的空間浪費，進而提高整個鐵路運輸的運輸效率。

本文針對系統中的貨物裝載進行優化，拼貨裝載是一個很復雜且龐大的過程，從用戶下單選擇拼貨開始，直到系統進行合理分配，每一步都是從最基本的操作開始的，也適用于其他運輸方式，本文對系統的拼貨裝載問題進行建模并對其求解。

4.2拼貨裝載的影響因素及相關參數

4.2.1中途站停車時間

列車中途站停留時間消耗本質上是指列車在中途車站停留的總消耗的時間間隔，在拼貨之前，鐵路部門考慮到實際情況，優化路徑同時考慮到停靠站問題來判斷是否接收貨物。主要與列車停站次數與停站時間兩大因素有關，而在鐵路中間中轉的時間不包括在內。用戶應該選擇停站次數較少的車次，以減少相應的時間消耗。中途站停車時間計算公式，如下：

珂

丁停=環+培+常業+ f等待 (4-1)

式中，弘：列車停站時間消耗，h

/量：列車在中途站裝車作業時間，h

f嘗：列車在中途站卸車作業時間，h

瑋業:列車在中途站技術作業時間，h

r等待：列車在站作業等待時間，h

4.2.2班列編組輛數

現行貨運列車往往釆用固定編組，常常存在空廂運輸現象，浪費資源且不便于管理, 更不利于提高運輸效率。涉及到改變編組時，主要考慮如下兩個決定性標準：一個是列車停站點與裝卸線之間有效長度，另一個是區段規定的牽引列車最大牽引標準。

(1)停站點與裝卸線的有效長度決定了列車最大可編組數目加線路:

加線路-有效~/機)〃C (4.2)

式中，/有效：列車車站到裝卸線有效長，m；

k :安全附加距離，m；

Z機：牽引機車長度，m.

4：車輛長度，m；

(2)區段規定的牽引列車最大牽引質量標準決定了最大可編組數目加牽引；

加牽引=機)/(9自+9載) (4.3)

式中，e：牽引列車最大牽引質量標準，t；

。機：機車重量，t;

q自:車輛自重，t；

g載：車輛載重，t；

取上述加線路、加牽引中的較小值作為快遞班列的最大編組輛數，即

加編二min (加線路，加牽引) (4.4)

4.2.3條件假設

當涉及到具體問題時，考慮到運輸網絡復雜，為簡化問題，便于建模，對特定條件進行假設:

(1)封閉假設：假設鐵路貨運系統是封閉的，模型不考慮存在外部交換的情況。

(2)路徑假設：因為鐵路的特殊屬性，即線路固定。當確定起點、終點和主要途徑站之后，列車的運行路徑就確定下來。

(3)無中轉假設：假設貨物到達某一站點后，僅進行裝卸操作，而不通過該站進行鐵路內部的中轉。即對于貨物來說，只有起止點不存在中轉點。

(4)區段能力假設：假設列車通行的鐵路區段都能滿足列車通行和貨物運輸的要求。

(5)參數固定假設：本文研究通過拼貨方式來提高貨物運輸效率，并最終以列車停站時間，來作為衡量其運輸效率的參數。因此相關設備因素和各鐵路局各區段配速規定可認為是非重點參數，在利用算法優化時，認為這些參數是固定的。

4.2.4相關參數

在這里對模型中可能用到的參數進行定義：

(1)路網參數

路網參數非常龐大，這里僅對本文使用到的參數進行定義。

停站點集合S = {Sj\i = l,2,...,n}.運行區間里程集合£» = {如門=1,2,.貨物流

' , , 如為停站點6到Sj間的貨物流量.直達列車集合A^{a'\l = \,2,...,L},；表示路網內第/列開行的列車，比表示在停站點©到為間開行的列車；定義N箱為列車最大裝載能力，若車站®與巧不相鄰，則定義S”={s“卩工丿},其中％表示車站©與巧間的所有車站集合，同時也表示列車4.所有途經站的集合，且Sj,Sj生Sr；

(2)列車運行時間參數

定義T = {ti\i = \,2,...,ri},其中彳表示在6站始發的貨物候車時間(箱小時)；列車在中途站停站時間可定義為7；停={t'k\k = 1,2,...,n}，其中什表示列車；在中途k站的停站作業時間(箱小時)。

(3)貨物組織形式參數

本文中不涉及中轉作業方式，故只考慮在中途站是否停站的問題。其參數表示如下：

4.3裝載問題模型構建

4.3.1目標函數

在簡潔性的原則下，以貨物運輸時間為目標函數，從而評價貨物運輸效率。模型中的貨物運輸時間包括運輸過程中產生的始發站候車時間與中途站停站作業時間。

(1)貨物始發站候車時間

對于始發站來說，不論直達或是中轉，在車站耳消耗的總候車時間均可表示為加(Z),具體如下：

路網總始發站候車時間為:

(2)貨物中途站停站作業時間

當列車；需要在中途的k站進行停站作業，決策變量xlk=l, k站的停站作業時間是則車站耳始發的列車；在k站的停站作業時間為/停(/),具體如下：

f 停(7) - q* E (4.8)

運輸過程總停站作業時間為：

幾:為 I / (4.9)

/=l /-I /=1 j-}

因此，此目標函數可表示為：

幷 n L 斤 n

Z =卩直 + T候=»工％ + m為 * (4.10)

/=1 /=1 /=1 7=1 j~\ k&Sjj

4.3.2約束條件

除上述約束條件外，根據本文問題需要，增設約束條件如下：

(1)最大裝載量約束

列車的裝載能力受車廂尺寸和列車最大裝載質量限制，任意列車狀態均不能超過其最大裝載量。將列車最大狀態量表示為如下兩個參數：受裝載能力限制，某一列車在區段運行的現裝載量一定不成超過該列車和區段能承受的最大裝載量。列車d的裝載量約束表示如下：

式中，：Xj, y” Zj分別為貨物x方向，y方向，z方向的尺寸；

對應的X剜Yk, Z箱分別為箱體在x方向、y方向、在方向的尺寸;

N箱：列車的最大裝載質量。

(2)空駛率約束

為保證運輸服務質量，列車的裝載率應該大于該區段的貨物流量之和，因此列車在運行過程中，會存在一定的空載情況，即資源浪費情況。因此應該設置空駛率閾值，當空駛率過高就可能停開該列車，以保證收益。設置列車空駛率為9空，具體表示如下：

L n n L

q'jdij / £ N箱 9 S 2 (4.⑵

/=1 7=1 /=!

式中，diJ：區段里程； D：列車/的運行里程。

(3)決策變量球=1或0 (4.13)

4.4模型求解

4.4.1遺傳算法概述

圖4.1遺傳算法工作流程圖

Fig.4.1 Workflow of genetic algorithm

遺傳算法(Genetic Algorithm,GA)是基于遺傳學說和生物進化學說發展起來具備全局優化性能的隨機化搜索算法。作為一種有重要意義的計算尋優技術，遺傳算法主要用于研究各種非線性、多變量、多目標、復雜的自適應系統問題。遺傳算法模擬自然選擇和自然遺傳過程中發生的繁殖、交叉和基因突變現象，在每次迭代中都保留一組候選解, 并按照某種指標從解群中選取較優的個體，利用遺傳算子對這些個體進行組合，產生新 i代候選解群，重復此過程，直到滿足某種收斂指標為止。遺傳算法的具體工作流程如上圖4」所示。

4.4.2拼貨裝載遺傳算法設計

(1)染色體編碼

以是否停站作為決策變量(0-1)進行編碼。將停站與否作為求解變量構造矩陣， •個矩陣為」個染色體。針對本文的問題，將貨物流量設置為求解變量，某站貨物流量為1停站，反之不停站。最終將其問題轉化成二維矩陣，矩陣的行代表本方向列車集合, 矩陣的列代表所運輸的貨物流量集合。當列車數量為H,車站數量為n時，流量為m, 構造的Hxm矩陣形式如下：

(1 1 I \

912 913 ^n-l.n

xrl _ Q12 q】3 Qn-l,n

Nij = (4.14)

H H H

(912 4l3 4n-l,n 丿

本文僅研究上述矩陣涉及到的單線路單方向問題，其他上下行問題均不考慮。

(2)種群初始化

算法的運算能力與遺傳算法的種群規模有很大的關系。為了不影響染色體之間的交叉、變異操作，種群規模不能太小，不能低于染色體串的長度，同時為了保證算法的運算能力較強，一定要將較大規模的群體作為種群規模。

(3)適應度函數

適應度函數也稱評價函數，用以度量某個物種對于生存環境的適應程度。在遺傳算法中，依靠適應度函數值來區分每個個體優劣。適應度函數的構造非常重要，主要依據類別的可分性以及特征的分類能力來確定。適應度最大的個體即為種群中最好的個體，將其無條件復制到下一代新種群中，使其優良特性得到遺傳。參考本章的目標函數，可以將目標簡化為列車停站次數最少。同時，由選擇箱流量與列車裝載能力兩個主要約束條件加入到適應度函數中，即：

H H

心工GI工心- 9訂+：2(N箱-巴) (4.⑸

Z=1 kesv /

式中，X；' ：決策變量垠的相反形式，即停站為1,不停站為0,這是為了方便適應度函數的表示而設置的；

©,$2：懲罰函數，為使得到的解盡可能滿足約束而設置，數值較大。

(4)選擇操作

遺傳算法尋求最優解的過程從本質上來看就是一個迭代的過程，這個迭代過程是在多個父代與子代之間所產生的，并從中選取父代中適應度較高的個體進行下一代遺傳。本文所運用的這個算法就是將種群內個體按照適應度的高低先進行排序，采用最優個體保存方法將適應度排序中最高的父代直接保留下來。這樣的操作可以避免遺傳算法在尋求最優解的過程中對其產生遺漏的情況，并且可以保證這些最優個體不受到交叉或者變異操作的影響，可以正常進行。

(5)交叉與變異

染色體的交叉變異時產生新個體的根本原因，隨著新個體的產生才能找到最優的發貨方案。在染色體交叉變異過程中產生的編碼替換如表4.1所示。

表4.1染色體交叉過程

Table 4」Chromosome crossing process

染色體編碼選擇結果配對情況交叉點位置交叉結果

1 010010•…… 1-2 2 000010……

2 001101…•… 011101…

3 101011....... 3-4 4 101111……

4 110110….… 110010……

染色體變異方式用編碼表示主要表現為以下兩種，一種是編碼位置交換，另一種是 0、1互換，兩種效果基本相同。具體過程如表4.2所示。

表4.2染色體變異過程

Table 4.2 Chromosomal variation process

染色體編號選擇結果變異位置變異方式變異結果

1 010010...... 2,6 編碼互換 000011.....

2 101011…… 2,4 0、1互換 111111••…

遺傳算法的終止包括兩種方式，一種是迭代次數達到設定值，另外一種是適應度函數開始收斂。但是當迭代次數達到設定，適應度函數仍未收斂，則需要調整適應度函數權重或者采用其他約束條件使結果最優。

4.5算例演示及結果分析

根據之前的公式4.11可知，以北京到南京方向貨運列車為例，開行列車數目為3, 貨物流量為10,故構造3X10的變量矩陣。由于列車最大裝載能力為50,故設計變量的算法上限為50,從而確定編碼為6位編碼(F=64)。單個變量編碼完成后，將30 個變量的編碼組合在一起即形成一個180位0-1編碼的染色體，將本文染色體種群數取 120,交叉概率為0.8,變異概率為0.01,最大迭代次數為10000c

經過適應度函數的調整后，最終按照公式4.15設置懲罰因子能夠得到最優解。經過運算后，得到的算法迭代過程如圖4.2所示：

文件(F)編韜(E)查看(V)插入(I)工具(T)桌面(D)窗口(W)幫助(H)

2000 4000 6000 8000 10000

迭代次數—

圖4.2遺傳算法迭代過程圖

Fig.4.2 Iterative process of genetic algorithm

通過公式4.12可以計算出列車空駛率，僅考慮下行情況，如表4.3所示。

表4.3箱位空駛率表

Table 4.3 Empty rate of the position

列車編號 1 2 3 綜合

空駛率 9.18% 4.60% 35.24% 16.34%

由上表可知，列車空駛率達到了 16.34%,這是為了保證服務質量產生的必要冗余。當然，在實際問題中，我們可以采用靈活編組，并降低空駛率的方式來進一步降低運輸成本，提高運輸效率。

通過對拼貨裝載進行優化實驗再一次證明利用遺傳算法優化后的拼貨裝載系統進行空間利用率提高，載重率也有所上升，將之應用在鐵路貨運信息管理系統中具有良好的效果。當后臺服務器端進行判斷以后，將計算的方案成果發送到移動客戶端，終端界面顯示如圖4.3(a)、4.3(b)、4.3(c)所示。

北京返回方案息見

南京 <9北東一鯛4個頓

時長大的9B729分

中站感時問中

天

一蘇州剰余1M、車用

時長柚4時44分

切舷3j

需京東站快運張樹臚

枕一蘇州剩敘個傾

? 時長大釣仙 3分

0 _ A

•n A

(a)中途站點選擇 (b)種類選擇 (C)方案意見

(a)Midway site selection (b)Type selection (c)Program opinion

圖4.3拼貨裝載方案體現界面實現圖

Fig.4.3 Interface implementation embodied in the cargo loading schemes

本章小結

本章主要完成對拼貨裝載系統優化問題的分析描述，并對拼貨裝載整個過程中的影響因素和相關參數進行介紹，針對該問題進行模型的建立，利用遺傳算法對其進行求解, 以拼貨裝載系統的標準問題為例進行了實際的拼貨驗證，最后證明本文所設計的遺傳算法運行結構可靠，優化效果良好。

第五章鐵路貨運信息管理系統的設計

第三章對系統總體進行了需求分析，并對客戶端的功能模塊進行描述。本章分析系統整體設計，并從服務器、數據庫和客戶端三個角度進行設計。

5.1系統的結構設計

若要實現對鐵路貨運信息管理系統的數據統計，服務器必須對系統整體的數據進行采集并且加以儲存，如圖5.1所示。

圖5.1鐵路貨運信息管理系統總體結構圖

Fig.5.1 The overall structure of the railway freight infbrmation management system

當服務器采集到所需要的數據時,會將該數據存儲在數據庫中，當用戶在調用這些數據時會向客戶端發出請求指令，客戶端會將用戶請求的數據以JSON格式進行封裝后再發送給服務器，當服務器接收到指令后，再采用Servlet技術對客戶端進行響應，再由JDBCM2］技術實現與后臺數據庫的數據傳輸，最后服務器會對處理結果進行反饋，并反饋給客戶端。

本課題的主要完成的工作是完成客戶端與服務器端之間的通信設計和數據處理設計，并對客戶端部分進行功能實現，但對服務器端的設計不做詳細研究，一些相關的地方已經做出了描述。

5.2服務器端模塊設計

5.2.1服務器與移動客戶端通信設計

隨著設計的不斷發展，手機已經成為人們生活中必不可缺少的一部分。因此，人們對其要求也越來越高，它們應具有智能化方面的特點，不單是想通過手機來進行通訊，

而是選擇可以通過手機進行互聯網的訪問，從而達到與數據庫進行交互通信的目的。

客戶端的功能不只是簡單地向服務端發送請求，這一過程涉及到復雜的網絡數據傳輸訪問流程，也有多種可供使用的技術方法，Android系統中可采用Http Client方式陽, Http協議是目前網絡傳輸中使用最為廣泛的傳輸協議之一，在Java語言中，Http Client 是一種專門針對Http傳輸協議的類，它對Get、Post、Response等常用的網絡訪問的方法進行了封裝，極大的方便了代碼的編寫。

Http Get是向服務器發送GET請求，Http Post是向服務器發送POST請求，Http Response是獲取返回的響應數據的接口。Http Client發送的請求有GET請求和POST請求兩種，如圖5.2所示。

防火墻

圖5.2客戶端與數據庫通信方式示意圖

Fig.5.2 Schematic diagram of how the die nt comm un icates with the database

⑴發送GET請求

GET請求的功能一般用來進行信息查詢操作，例如對快遞、車次及信息等數據進行查詢。具體步驟如下： ?

①建立Http Client對象；

②建立Http Get對象；

③用“？ ”分隔后連接到URL地址中，各個參數通過“&”區分。當請求參數不夠用需要添加時，是可以選擇用Http Get的set Params()方法來進行添加；

④若采用Http Client的excute()方法，則會返回一個Http Client對象；

⑤若想要獲取服務器的響應頭，可以選用Http Response的get All Headers()等方法;

(2)發送POST請求

POST請求的功能是根據參數對服務器中的相關內容進行修改，例如發布信息和提交相關信息等較為復雜的操作。具體步驟如下：

①建立Http Client對象；

②建立Http Post對象；

③當請求參數不足需要添加時，可采用Http Post的set Params()和set Entity()方式進行參數設置；

④若采用Http Client的excute()方法，則會返回一個Http Client對象；

5.2.2服務器與移動客戶端數據處理設計

當用戶通過移動客戶端發送指令時，客戶端會經由網絡向服務器發送數據請求，月艮務器端使用Servlet對請求進行相應處理，并通過AD0來實現和后臺數據庫之間的信息傳輸，數據庫根據請求內容返回相應的查詢設置結果，并將返回結果打包成JSON格式的數據包，通過網絡傳輸給請求數據的移動終端。本課題所設計的Android鐵路貨運信息管理系統客戶端通過Web Service方式與服務器進行數據交互，如圖5.3所示。

圖5.3客戶端與服務端交互圖

Fig.5.3 Interaction between client and server

在本課題中通過使用Web Service技術來對SQL Server進行訪問。客戶端通過Volley 框架訪問網絡，Volley支持自定義request,由于需要將客戶端的請求進行排隊處理，同時，在格式上使用的是JSON數據格式。

所以本課題自定義了 JsonRequest,將客戶端的請求加入RequestQueue,實現了 Request的先進先出。Volley訪問網絡使用Request.Method.POST方法，該方法包含三種參數：

①url,它是一種網絡地址參數；

②object,它是實例化的JSONObject對象；

③Request.Listener,它是返回結果的監聽器。當返回為onResponse時，則表示成功, 當返回為onErrorResponse時，則表示失敗。

具體使用時，將查詢數據的sql語句插入object中傳輸給指定url的Web Server即可。Web Service訪問數據庫的代碼詳見附錄A。

5.3系統數據庫設計

鐵路貨運相關數據的特點是海量且多源的，與其他行業數據相比較，鐵路貨運數據的保存是更有重要意義的⑴】。數據庫的最主要的作用是將數據進行保存，同時完成軟件系統的交互，所以數據庫與系統軟件模塊是直接相關的。從鐵路貨運系統中可知，按照功能模塊劃分，數據庫能夠存儲用戶基本信息、常用聯系人信息、訂單填寫信息和收費標準信息等。并結合鐵路的實際相關情況，構建數據庫表的設計和數據庫E-R模型。

5.3.1數據庫表設計

所謂的數據庫表設計是建立在數據庫管理系統的基礎上，按照用戶的具體需求對數據庫的結構進行設計并建立數據庫的過程。衡量一個數據庫設計的是否合理是根據用戶需要在一定程度上節省數據的存儲空間，從而來提高存取效率同時保證數據的完整性。本系統中的大部分功能都是用來訪問數據庫，因此數據庫在系統中占據很重要的位置，并且數據庫設計的是否合理直接影響了系統性能的好壞。數據庫在進行邏輯設計時要滿足以下幾點囹鼻習：

(1)規范化命名

對于數據庫、數據表及域的命名都是需要遵循統一命名規則而執行的，同時對所有的命名都要進行相關的說明，便于査詢和維護的工作。

(2)采用視圖技術

視圖不是獨立存在的，它是依賴數據源而存在，實際問題上來說是一個虛擬的。視圖的作用就是將數據進行簡化，使用戶對數據有更好的理解，能夠及時且方便的看到自己所需的數據，因此視圖可以將復雜的數據處理成直觀的圖形，還可以節省出存儲空間從而提高運算速度。

(3)適當的冗余

數據表與字段之間是盡可能滿足第三范式的關系，但需要降低范式的標準來增加適當的冗余。用足夠的空間換取相對應的時間，這一目的是為了能夠提高數據庫的運行效率。除此之外，為了之后的維護、分析和擴展工作也可以采取適當的增加一些冗余字段進行。

本課題的數據庫設計設計了 4張數據表，如表5.1所示。

表5.1數據庫表

Table 5.1 Database table

表名稱表說明表名稱表說明

Table_User 用戶信息表 Table_Contact 常用聯系人表

Table_Order_Fill 訂單填寫信息表 Table_Charge_Standard 收費標準信息表

下面將詳細介紹本課題數據庫表設計所涉及的數據表具體如表S.2-5.5所示。

表5.2用戶信息表

Table 5.2 Information of user

序號字段名屬性數據類型主鍵/

外鍵是否

為空說明

1 Userjd INT(ll) 整型 PK N 由數據庫序列自動生成的

ID編號

2 Permission INT 字符串型 Y 權限

2 User_Name VARCHAR

(100) 字符串型 N 用戶名

3 User_Password VARCHAR

(100) 字符串型 N 用戶密碼

4 User_Real_Name VARCHAR

(100) 字符串型 Y 用戶姓名

5 User_Id_Number VARCHAR

(100) 字符串型 Y 用戶身份證號碼

6 User_Phone__Number VARCHAR

(100) 字符串型 N 用戶手機號碼

7 User_Email VARCHAR

(100) 字符串型 Y 用戶郵箱

8 Orderld INT(ll) 整型 FK N 訂單ID編號，由數據庫序列自動生成

9 Reserved 1 VARCHAR

(1000) 字符串型保留字段1

10 Reserved2 VARCHAR

(1000) 字符串型保留字段2

表5.3常用聯系人信息表

Table 5.3 Information of common contact

序號字段名屬性數據類型主鍵/

外鍵是否

為空說明

1 Contact_Id INT(ll) 整型 PK N 由數據庫序列自動生成聯

系人ID編號

2 Contact_Name VARCHAR

(100) 字符串型 N 聯系人姓名

3 Contact_Id_Number VARCHAR

(100) 字符串型 N 聯系人身份證號碼

續表5.3

4 Contact_Gender VARCHAR

(100) 字符串型 N 聯系人性別，用戶性別，

0表示男，1表示女

5 Contact_Phone_ Number VARCHAR

(100) 字符串型 N 聯系人電話號碼

6 Contact_Telephone_ Number VARCHAR

(100) 字符串型 N 聯系人固定號碼

7 Contact_Email VARCHAR

(100) 字符串型 N 聯系人郵箱

8 Contact_Address VARCHAR

(100) 字符串型 N 聯系人地址

9 Reserved 1 VARCHAR

(1000) 字符串型保留字段1

10 Reserved2 VARCHAR

(1000) 字符串型保留字段2

表5.4訂單填寫信息表

Table 5.4 Information of order filling

序號字段名屬性數據類型主鍵/

外鍵是否

為空說明

1 Order_Name VARCHAR

(100) 字符串型 N 訂單企業（客戶）名稱

2 Order_Phone_Number VARCHAR

(100) 字符串型 N 訂單負責人聯系方式

3 Order_Originating_ ststion VARCHAR

(W0) 字符串型 N 訂單起始站位置

4 Order_Terminal_ station VARCHAR

(100) 字符串型 N 訂單終點站位置

5 Commodity_Name VARCHAR

(100) 字符串型 N 貨物名稱

6 Commodity_Number VARCHAR

(100) 字符串型 N 貨物件數

7 Commodity_Total_ weight VARCHAR

(100) 字符串型 N 貨物總重量

8 APPointment_Time DATE 日期、時間型 N 預約日期

9 Order_Remark VARCHAR

(1000) 字符串型 Y 預約訂單信息備注

續表5.4

10 Reserved 1 VARCHAR

(100) 字符串型保留字段1

11 Reserved2 VARCHAR

(100) 字符串型保留字段2

表5.5 攵費標準信息表

Table 5.5 Information of charge standard

序號字段名屬性數據類型主鍵/

外鍵是否

為空說明

1 Charge_standard_

Type VARCHAR

(100) 字符串型 PK N 收費標準類型

2 Chargesta ndard_ Price VARCHAR

(100) 字符串型 N 收費單價

3 Chargestandard_

Description VARCHAR

(1000) 字符串型 Y 收費標準描述

4 Reserved 1 VARCHAR

(1000) 字符串型保留字段1

5 Reserved2 VARCHAR

(1000) 字符串型保留字段2

5.3.2 E-R模型構建

E-R模型全稱實體一聯系圖，在圖中充分展示實體類型、屬性和聯系之間的方法，因為其有較強的邏輯關系和清晰的描述方式，因此人們廣泛使用該模型。

通過對鐵路貨運信息管理系統的需求分析，劃分出實體與關系的聯系，構建出系統 E-R模型，如上圖5.4所示。

5.4客戶端模塊設計

5.4.1主界面設計

圖5.5界面文件結構關系圖

Fig.5.5 Structure relationship of in terface files

圖5.6主界面流程圖

Fig.5.6 Flow of main interface

根據MVC設計模式設計Android客戶端，采用一種業務邏輯、數據和界面顯示分離的方法組織代碼，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。對Android客戶端進行界面布局的方法主要有三種，即XML配置生成、通過用戶界面生成和直接代碼生成。

本論文選擇在XML文件中對界面UI組件進行修改，即通過添加或修改UI組件相應的XML屬性實現對界面的編輯。界面文件關系如上圖5.5所示。主界面的工作流程為如上圖5.6所示。

5.4.2用戶管理功能模塊設計

用戶管理模塊主要是用來對貨運用戶的信息進行管理，其中主要包括登錄注冊模塊和貨運用戶模塊。

(1)用戶注冊、登錄

在一個客戶端軟件中，最常見且不可缺少的模塊就是注冊和登錄模塊。本客戶端設計的登錄模塊包括兩個部分，一個是貨運用戶使用的權限，另一個是鐵路管理員。因此, 注冊本客戶端時需要兩種注冊方式，一種是注冊用戶名，另一種是注冊工號。并且為了保證注冊安全，設計了綁定身份證號和短信驗證，只有兩種信息同時滿足時才可以注冊成功。注冊和登錄子功能的流程圖，如上圖5.7所示。

在登錄功能子模塊時，用戶首先要填寫好自己注冊時所用的用戶名和密碼，然后向后臺服務器端發送登錄請求，經過Servlet處理請求后，驗證信息是否正確。若驗證成功，證明填寫的信息準確，則用戶登錄成功；若登錄信息錯誤，則提示用戶信息不正確，提示用戶進行修改。

5.4.3發貨及拼貨功能模塊設計

發貨及拼貨功能模塊為用戶提供兩種發貨方式，為更好地滿足不同用戶的需求，極大程度地方便所有的貨運用戶，從而提高鐵路貨運的效率。因此在本客戶端設計的主界面上，添加了兩種方式的按鈕，一個是“我要發貨”功能按鈕，一個是“拼貨查詢”功能按鈕。

圖5.8發貨及拼貨流程圖

Fig.5.8 Flow chart of delivery and blending

“我要發貨”功能模塊是將貨物的企業（客戶）名稱、聯系方式、起始站、終點站、貨物名稱、件數、重量和預約日期的信息填充完整，然后提交給數據庫，數據庫會根據用戶的需要安排合理的班列，當用戶判斷時間合適，可以進行貨運聯系人的選擇，當聯系人中沒有本次運輸的聯系人時，則進行常用聯系人添加，若選擇錯誤也可以進行重新選擇，所有信息填寫完畢后，確認無誤就可以提交信息給后臺。

“拼貨查詢”是用戶將自己的起始站和終點站輸入之后，可以根據自己的需求，選擇運輸的種類，時間和中途停的站點，后臺數據庫會根據用戶的需求調用出1-3個方案, 若沒有方案可以提供，數據庫會提示無方案提供選擇，用戶將合理地進行方案調整；若有方案提供，用戶將根據自己的要求，選擇合理的方案進行確定，界面也將會跳轉到提交訂單界面，進行上述的聯系人的選擇。發貨及拼貨流程圖如圖5.8所示。

5.4.4支付功能模塊設計

支付功能模塊是在貨運用戶確定訂單后，向鐵路部門進行發貨或者拼貨產生費用的一個專屬模塊。用戶通過這個模塊可以進行直接支付，方便快捷。

如圖5.9所示是客戶端支付功能模塊中的界面設計流程圖。

圖5.9支付流程圖

Fig.5.9 Flow chart of payment

支付寶支付是采用異步處理方式進行的，這樣使用戶更加方便和快捷。從開發的角度來看，用戶使用起來也很得心應手。

5.4.5物流查詢功能模塊設計

物流查詢功能模塊是本客戶端的重要一個環節，在用戶發貨后，對貨物的物流信息也十分關心。在本客戶端的設計上，為了滿足客戶的需求，分為兩種輸入訂單號的方式進行，一種是手動輸入訂單號，另一種是掃碼輸入。物流查詢流程圖如上圖5.10(a)、5.10(b) 所示。

圖5.10物流查詢模塊管理流程圖

Fig.5.10 Flow chart of logistics query module management

5.4.6發貨(拼貨)訂單管理模塊設計

發貨(拼貨)訂單管理模塊是本客戶端針對鐵路管理員權限進行的一個專屬模塊。在該模塊中，鐵路管理員可以對發貨(拼貨)訂單的屬性等相關信息進行查看，并具有對該訂單的批準、拒絕等權利。

當鐵路管理員對訂單信息了解不是很清楚時，可以點擊詳情按鈕進行查看相關信息。但是兩個模塊的區別在于，拼貨訂單管理模塊中如果拒絕申請的話，可以給出方案意見，貨運用戶可以自己的需求選擇是否接受方案意見。發貨(拼貨)訂單管理模塊的流程圖如圖5.11(a)、5.11(b)所示。

(開始)

(a)Flowchart of delivery order management module (b)Flow chart of filtration order management module

圖5.11管理模塊流程圖

Fig.5.11 Flow chart of management module

而針對系統管理員來說，訂單統計模塊是針對具有最高權限的管理員進行設計的，其主要作用是指管理員對貨物的屬性和信息能夠做到基本的查看，起到一個督察的作用。

本章小結

本章主要對鐵路貨運信息管理系統進行設計。首先對系統整體架構進行分析，將系統分成服務器端和客戶端兩部分進行設計。然后對服務器端模塊和數據庫進行設計，最后對客戶端所有模塊進行設計。

第六章客戶端系統實現與測試

第五章對本客戶端進行了詳細的設計，而本章是對所有設計的界面進行實現。鐵路貨運信息管理系統的研究是為了保障貨運的安全運行，在設計過程中，采取一系列針對性的測試，是非常必要的，其中包括兼容性測試、功能性測試以及性能測試。

6.1移動客戶端實現

6.1.1主界面的實現

針對兩種權限，分別設計了兩種主界面。如圖6.1(a)所示是貨運用戶的主界面圖, 圖6.1(b)所示是鐵路管理員的主界面。

6.1客戶端主界面圖

Fig.6.1 Main interface of the client

6.1.2用戶管理功能的實現

(1)貨運用戶(鐵路管理員)注冊與登錄

首次使用這個客戶端需要對賬戶進行注冊，注冊如圖6.2(a)所示，注冊成功后可以跳轉至登錄界面。在登錄該客戶端時，有兩個權限窗口，若是貨運用戶，則需要正確輸入用戶名和密碼進行登錄；若是鐵路管理員需要輸入工號和密碼進行登錄，從而對信息進行査看。用戶登錄如圖6.2(b)所示。用戶注冊時，為了保證信息安全，需要綁定手機,

因此向手機里面發送驗證碼,

如圖6.2(c)所示。

歡迎使用鐵路貨運客戶端！

(c)驗證短信

(a)用戶注冊

(a) User registration

(3)常用聯系人管理

個入中心

(b)用戶登錄

(b) User login

圖6.2用戶注冊登錄圖

Fig.6.2 User registration login

張三雲 210**-3520

常舞女 21

王飜農初X

礙髓立 240”"”"**喲08

題女 13V*~—5643

(a)個人中心

(a)Personal center

(b)常用聯系人

(b)Common contact

圖6.3常用聯系人管理圖

Fig.6.3 Common contact management

(C)添加聯系人

用戶登錄客戶端之后，可以隨時進入到個人中心功能模塊進行信息補充，對信息進行完善，如上圖6.3(a)所示。在常用聯系人中，可以查詢到已經輸入過的個人相關的用戶信息，再次使用時就可以直接點擊選擇，如上圖6.3(b)所示是常用聯系人列表。若要添加聯系人，則可以在圖6.3(c)中進行添加。

6.1.3發貨及拼貨功能的實現

發貨及拼貨模塊是本客戶端的核心。在發貨的過程中，首先需要用戶填寫網上電子訂單，填寫好自己運輸的企業(客戶)名稱、聯系方式、起始點、終點站、貨物名稱、件數、總重量及預約日期之后，點擊“確定”按鈕，即可完成訂單的上傳工作，如圖6.4(a) 所示。后臺數據庫會根據用戶的訂單要求，合理安排最符合用戶要求的班列，顯示在需要確定的訂單上，用戶確定信息合理，點擊“聯系人”按鈕，選擇在常用聯系人數據庫中的聯系人信息，若列表中沒有相關聯系人信息，則點擊旁邊的“添加”薯鈕進行聯系人添加；若在選擇聯系人過程中選擇錯誤，則點擊“刪除”按鈕進行重趙擇，提交訂

單如圖6.4(b)所示。

(a)發貨訂單 (b)提交訂單

(a)Delivery order (b) Submit orders

圖6.4發貨功能管理圖

Fig.6.4 Delivery function management

在拼貨過程中，用戶首先要選擇運輸的起始站和終點站的名稱，數據庫會根據用戶選擇的地點調出符合用戶的班列，該班列是已經存在運輸線路而且有多余車廂的班列，同時數據庫還會給出符合要求的1-3個不同車次的選項，其中包括時間長短、車廂多少等不同條件的班列，用戶根據自己的需求進行選擇，選擇完畢之后進行確定。拼貨訂單

如圖6.5(a)、6.5(b)所示，提交之后，數據會自動保存到數據庫中，由用戶對最后訂單進行確定并提交，如圖6.5(c)所示。

諄肋：＞S購(約使用4個車廂)(約使用\3個車馬)

Fig.6.5 Freighting function management

6.1.4支付功能的實現

寸閘原

2018^12^ 18E 出發

聯系人：張三

恭喜！支付成功

訂單總額

(a)訂單確定

(a)Order determination

圖6.6

出曳三明：2018S12引汩

出發時間

廬聶人:毬三

到達疋：江蘇當厲戸卍

題電話：438”"£147

(b)支付成功

(b) Payment success

支付功能管理圖

Fig.6.6 Payment function management

本客戶端設計的支付方式采用的是線上支付。因此，當用戶確定發貨和拼貨訂單之后，客戶端會跳轉至第三方支付平臺,即支付寶客戶端。用戶完成最終支付時，返回鐵路貨運信息管理系統客戶端，并將訂單最后確認的信息返回給用戶，支付成功如上圖 6.6(a)> 6.6(b)所示。

6.1.5物流查詢功能的實現

物流查詢功能是本客戶端所有功能中的一個輔助功能。貨物發貨后，用戶可以隨時查看物流信息，便于及時、快速的了解貨物情況，當貨物到站后，可以讓收貨人及時確認收貨。如圖6.7(a)、6.7(b)所示是物流查詢模塊圖。該模塊可以根據自己的需求，輸入訂單號或者掃描訂單號的二維碼進行查詢物流,從而極大程度上方便了用戶。如圖6.7(c) 所示是對掃描之后的訂單查詢結果的展示，訂單査詢結果可以進行不斷地更新，當貨物

沒有發出時，顯示的是待發貨狀態和起始點位置；當貨物在運輸過程中時，顯示的是運輸中狀態和貨物所在位置；當貨物到達收貨站時，顯示的是到站狀態和終點站位置。

(b)條碼掃描

(b)Bar code seanning 圖6.7物流查詢管理圖

Fig.6.7 Logistics query management

6.1.6發貨訂單管理的實現

鐵路管理員可以對整個系統中的所有發貨訂單進行查看，使用鐵路內部權限登錄客戶端之后，在主界面點擊訂單列表進行查看，列表中不能看出貨物的詳細情況，當管理者需要對信息進行查看時，點擊詳情進行查看，這樣鐵路管理員就會看到貨物屬性的相關信息。管理者需要根據實際情況選擇是否批準，若批準發貨，就可以點擊“批準”按

鈕，貨運用戶會收到自己申請成功的界面，如圖6.8(a)、6.8(b)、6.8(c)所示是訂單列表、

6.1.7拼貨訂單管理的實現

拼貨訂單模塊是鐵路管理員在用戶發送訂單之后，可以對訂單進行審核，當貨物屬性等相關問題都符合要求時，管理者可以對貨物進行批準，如上圖6.9(a)所示。

若要是拒絕拼單請求，需要將原因進行說明，同時系統會反饋給用戶幾個方案，其中包括最優方案，提供給用戶進行選擇，如上圖6.9(b)、6.9(c)所示為發貨訂單。

6.2移動客戶端系統測試

6.2.1系統測試概述

在設計一款軟件之后，尤為重要的是對其性能進行檢測。需要檢測軟件是否在運行過程中出現異常或者檢測在運行過程中該軟件是否出現很明顯的程序缺陷。這些都是設計應用軟件中所必須存在的后續操作。

倘若應用軟件不能完成系統所提供的測試工作，那么這款軟件的性價比相對較低。鐵路貨運信息管理系統客戶端中的每一個功能都嚴格按照檢測流程進行將•系列的檢査工作。

圖6.10系統測試流程圖

Fig.6.10 Flow chart of system test

對于一個客戶端的測試，主要從三個方面對系統進行測試，分別是兼容性、功能性和系統性能。系統測試之前需要準備所有書庫以及建立相關的測試用例，然后對其進行檢測，對于部門組測試要求的指標，要及時對有問題的部分進行修改及完善，完善之后再進行回歸測試。具體測試流程如上圖6.10所示。

6.2.2客戶端兼容性測試

在客戶端設計實現之后，需要對客戶端進行測試，其中最基本的就是兼容性測試。所謂兼容性測試就是在不同的安卓手機上下載客戶端，對客戶端進行檢測是否能夠正常顯示。在本文中，選擇三種不同型號不同品牌的安卓手機進行測試，其參數不同，具體如表6.1所示。

表6.1移動終端參數表

Table 6.1 Mobile terminal parameters

移動終端品牌及型號華為 Mate9 Pro 榮耀8 一加5T

網絡環境 4G 4G 4G

Android系統版本 Android9.0 Android&0 Android&0

主屏尺寸 5.5英寸 5.2英寸 6英寸

主屏分辨率 2560x1440 1920x1080 2160x1080

分別在如圖6.11所示的三款手機上進行運行，其能正常顯示界面，并且運行正常,

說明本文所設計的客戶端具有較好的兼容性。

圖6.11兼容性測試結果圖

Fig.6.11 The result of compatibility test

6.2.3客戶端功能測試

'客戶端功能測試是從用戶的需求角度出發，測試客戶端是否滿足用戶的需求，同時也對客戶端中模塊的功能進行驗證和檢測，以確定是否實現了所設定的目標。受限于篇幅，本文僅對主要功能模塊進行測試，具體如表6.2所示，測試結果如下圖6.12所示。

表6.2功能實現測試表

Table 6.2 Functional implementation test

用例號測試模塊操作步驟期望結果實際測試結果

Testi 用戶注冊可以注冊預測結果相同

Test2 用戶登錄可以登錄預測結果相同

Test3 用戶修改密碼可以修改密碼預測結果相同

Test4 用戶管理用戶找回密碼可以找回密碼預測結果相同

Test5 用戶個人中心查詢/修改可以個人中心查詢/修改 .預測結果相同

Test6 用戶添加/刪除常用聯系人可以添加/刪除常用聯系人 :預測結果相同

Test7 用戶新建常用聯系人可以新建常用聯系人預測結果相同

Test8 用戶填寫發貨訂單可以填寫發貨訂單預測結果相同

Test9 發貨及拼貨功能用戶提交發貨訂單可以提交發貨訂單預測結果相同

Test 10 用戶填寫拼貨地點可以填寫拼貨地點預測結果相同

Testi 1 用戶選擇拼貨方案可以選擇拼貨方案預測結果相同

Test 12 用戶提交拼貨訂單可以提交拼貨訂單 "籟測結果相同

Testi 3 支付功能用戶進行在線支付可以進行在線支付預測結果相同

Test 14 用戶信息査詢可以信息査詢預測結果相同

Testi 5 物流查詢用戶輸入訂單號可以輸入訂單號預測結果相同

Test 16 功能用戶條碼掃描可以條碼掃描預測結果相同

Testl7 用戶訂單查詢/更新可以訂單査詢/更新預測結果相同

Testi 8 管理者批準訂單可以批準訂單預測結果相同

Test 19 發貨訂單功能管理者拒絕訂單可以拒絕訂單預測結果相同

Test20 管理者詳情査看可以詳情查看信息預測結果相同

Test21 管理者批準訂單可以批準訂單預測結果相同

Test22 拼貨訂單管理者拒絕訂單可以拒絕訂單預測結果相同

Test23 功能方案意見查看可以查看方案預測結果相同

Test24 方案同意接受可以申請成功預測結果相同

Test25 訂單統計功能管理員查看信息可以信息査看預測結果相同

(a)訂單不能為空

(a) Order cannot be empty

(b)請選擇預約時間

(b) Select an APPointment time

(c)聯系人不能為空

(d)選擇合適方案

(e)訂單提交成功

(f)訂單號不存在

(d)Choose the right solution

(e)order submission successful

(f)Order number does not exist

(g)訂單號不正確

(g) Order number is in correct

—上hii.-lL!fli-IILflF—.r 一IH

(h)訂單已更新

(h) Order updated 圖6.12功能測試結果圖

Fig.6.12 The result of function test

(i)掃描失敗

(i) Scan failed

由上圖可知，客戶端各項功能模塊均能正常顯示，用戶在使用客戶端時，客戶端均會對相應的操作進行相關提示，表明鐵路貨運信息系統客戶端能夠實現各項功能，并達到設計要求，滿足用戶的實際需求。

6.2.4系統性能測試

鐵路貨運信息管理系統處理性能直接關乎今后的發展，故本小節對響應時間、內存占用和CPU占用進行測試。

(1)響應時間測試

在用戶體驗的層面上，客戶端應具備快速響應，極少發生卡頓的能力，出現卡頓大部分情況是因為客戶端在Android運行中使用了 AOT或簡單的JIT編譯方式，無法采取 iOS客戶端靜態編譯的方式。對此在測試中，本文擬定25位來自貨物管理中心工作人員安裝鐵路貨運信息管理系統客戶端，測試進入客戶端的響應時間，如圖6.13所示。

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

客戶端

圖6.13響應延遲測試結果圖

Fig.6.13 The result of responsive delay test

觀察且分析上圖可知，由于測試終端數量增多，占用服務器內存之后，平均響應時間出現增長現象。但是響應時間的增長并不影響用戶使用體驗，證明本文涉及到的鐵路貨運信息管理系統在用戶數量激增的情況下仍然可以穩定運行。

⑵內存占用

為保證用戶的綜合使用體驗，要使用戶在運行本應用的時候，手機仍然可以正常使用，不至于因為應用占用手機內存的原因，造成嚴重卡頓。因此本節對該應用占用內存情況進行了測試，以華為手機為例，每5秒檢測一次內存占用情況，其測試結果如圖6.14 所示。

占用內存(kB)

測試時A is)

圖6.14內存占用測試結果圖

Fig.6」4 The result of memory footprint test

分析上圖可知，鐵路貨運信息管理系統的內存占用一般是隨著運行時間的增加而增加，但是所有指標仍在合理的范圍內，且只占手機內存的一小部分，終端依舊正常使用,

這表明鐵路貨運信息管理系統的設計符合要求。

(3)CPU占用測試

除此之外，本文還對CPU的占用情況進行了測試，以驗證用戶終端的處理性能。此測試在手機無其他應用進程條件下進行測試，并綜合了多個手機的測試情況，避免因為系統進程的存在，造成測試結果的偏差。其檢測結果如圖6.15所示。

CPU占用

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85

測試時間(S)

圖6.15 CPU占用率測試結果圖

Fig.6」5 The result of CPU utilization teat

由上圖可知，隨著客戶端的測試時間不斷增加，CPU占用也在不斷上升，但是都在正常的范圍之內，而且只占用很小的一部分，因此客戶端可以正常使用，證明本文所設計的客戶端符合實際要求。

本章小結

本章按照前面對客戶端的設計要求，利用Android Studio開發環境對客戶端的所有模塊功能進行實現，并對核心內容進行具體詳細展示。同時本章在對客戶端模塊進行功能測試，并對系統進行實際測試。結果表明系統各項性能指標都符合設計標準。

結論

本文研究充分考慮到當前鐵路貨運信息管理過程中實際問題，設計了一種基于 Android的鐵路貨運信息管理系統。該系統將移動應用技術和智能化辦公的理念結合在一起，實現用戶通過手機對貨運的發貨、拼貨、支付等管理功能的同時，鐵路管理員還可以針對用戶的具體需求提供最優的方案進行選擇，二者的結合實現了鐵路貨運中信息管理系統的更新換代，為鐵路貨運提供了更加高效、靈活且便捷的信息化操作平臺。

本文主要完成的工作內容及研究成果如下：

(1)本文對我國貨運市場的的現狀進行了廣泛而深入的調研，特別是對北京到南京的貨運狀況進行統計，充分掌握了當前鐵路貨運所存在的問題，進而了解本系統設計的總體需求。通過需求分析完成了對移動客戶端的功能劃分，并詳細規劃各個功能模塊之間的關系和使用方法。

(2)根據鐵路貨運信息的實際情況，用戶根據自己的需求填寫訂單進行發貨和拼貨, 同時鐵路管理員針對請求進行審批，當審批拒絕時，管理者可以為用戶提供滿足系統條件的方案，通過例圖和表格的形式完成其子功能的規劃。

(3)對發貨及拼貨功能模塊中的拼貨子模塊進行算法研究。首先，將在拼貨過程中的實例問題轉化成數學模型，構建目標函數及其約束條件，并利用改進后的遺傳算法對其求解。其次，以北京到南京的貨物裝載問題為例進行了實際的拼貨驗證，最后證明本文所采用的遺傳算法可得到期望的效果。

(4)完成了鐵路貨運信息管理移動客戶端核心功能和服務功能的設計。客戶端部分針對貨運用戶主要是對用戶管理模塊、發貨及拼貨功能模塊、支付功能模塊和物流查詢功能模塊核心功能的設計，而鐵路管理員主要可以使用發貨訂單管理和拼貨訂單管理模塊，優化了信息管理系統的操作流程。同時，服務器端采用數據庫完成對數據庫表和 E-R圖的設計，并利用Web Service實現與客戶端之間的通信，確保客戶端正常運行。

(5)采用Android Studio作為移動客戶端的開發工具，采用MVC設計模式，實現了本文涉及到的貨運管理APP的功能。在夜神模擬器實現所有功能的測試，結果該系統滿足鐵路貨運管理需求；同時下載到手機上對所有模塊進行測試，結果表明，客戶端所有方面都達到了設計要求。

通過自己的努力與研究，完成了自己的預期目標，實現了基于Android平臺的移動貨運信息管理系統軟件，使貨運用戶和鐵路管理員同時使用這個軟件，這樣就不會因為不方便攜帶等問題導致人們忽略對貨物信息的管理，同時也節省了很多人力。目前系統可以運行出來，但是就目前這個系統而言還是有很多需要改進的地方：

(1)功能更豐富。諸如列車位置信息經過處理可推斷出貨物位置，從而使用戶清楚的知道貨物位置和運輸進程。

(2)對改進算法的進一步優化。在未來可以繼續改進遺傳算法，使迭代次數減少，從而得到更低的空駛率，提升實際運輸生產過程中列車編組的靈活性，降低拼貨綜合運輸的成本。

(3)美化客戶端界面。性能較好的移動客戶端不僅僅是實現功能，更多的是給用戶帶來舒適的使用體驗。因此，需要在未來工作中，更大程度的美化界面，提高使用舒適度。

參考文獻

[1]基于Android的醫院設備報修管理系統的設計和實現[A].中華醫學會(Chinese Medical Association),中華醫學會醫學工程學分會.中華醫學會醫學工程學分會第十五次全國學術年會論文匯編[C].中華醫學會(Chinese Medical Association)、中華醫學會醫學工程學分會:,2015:4.

[2]張映鋒，趙曦濱,孫樹棟，王軍強,司書賓•一種基于物聯技術的制造執行系統實現方法與關鍵技術 [J].計算機集成制造系統,2012,12:2634-2642.

[3]毛曉博.基于物聯網的車間制造執行系統的研究與實現[D].西安工業大學,2014.

[4]劉安戰，車戰斌，郭麗•基于Android和Web的設備維修動態管理系統.計算機應用與軟件.2014, 11:063.

⑸ Weidig C, Menck N, Aurich J C. Systematic Development of Mobile AR-APPlications Supporting Production Planning. Springer International Publishing. 2014:219-224.

[6]Ghose A, Biswas P, Bhaumik C etal. Road condition monitoring and alert APPlication:Using in-vehicle smartphone as internet-connected sensor. Pervasive Computing and Communications Workshops, 2012. IEEE International Conference on. IEEE, 2012:489-491.

[7]唐雄,張巨發，段昌奉等.基于Android智能手機的醫院移動護理信息系統開發及應用[D].中國數字醫學.2013,⑵:95-96.

[8]Hsieh C, Yun D, Bhatia A C etal. Patient Perception on the Usage of Smartphones for Medical Photography and for Reference in Dermatology. Dermatologic Surgery. 2015, 41(1): 149-154.

[9]董寶田，劉軍.鐵路信息化概論[M].北京：中國鐵道出版社,2014:1-11.

[10]張鵬.國外鐵路貨運信息化發展現狀及特點分析[J].鐵道貨運,2010, 20(1):50-52.

[11]Manyika J, Chui M, Brown B, etal.Big Data:The Next Frontier For Innovation, Competition, And Productivity[J]. Mckinsey Global Institute, 2011,5(33):222.

[12]苑寶印.蘇家屯鐵路貨運調度中心計算機管理系統[D].電子科技大學,2010.

[13]李珂.鐵路運輸貨物追蹤查詢系統的研究[D].成都:西南交通大學,2006.15.

[14]趙楠，李亮.貨檢手持機系統在實際生產中的應用卩].鐵道貨運,2010,28(7):30-33.

[15]卿周陽•基于Android的鐵路快運貨物信息管理系統的研究與開發[D].蘭州交通大學,2017.

[16]劉學進.鐵路電子貨票信息系統的設計與流程再優化[D].蘭州交通大學,2018.

[17]龍馳鵬.基于移動終端客運列車服務系統研究與開發[D].蘭州交通大學,2018.

[18]熊志君.Android在高校學生信息服務系統中的應用研究[D].南昌大學,2010.

[19]黃吉華.Android系統架構研究與應用[J].電子技術與軟件工程,2016(7):49-49.

[20]姚昱旻，劉衛國.Android的架構與應用開發研究[J].計算機系統應用,200& 11:110-112+24.

[21]Vlatko Nikolovski, Petre Lameski, Ivan Chorbev.Cloud Based Patient Monitoring Platform Using Android Smartphone Sensors[J]. Cybernetics and Information Technologies, 2015, 15(7). 67.

[22]張燕,汪衛霞.決策樹方法在藥物選擇模型中的應用[J]?大眾科S, 2013,(12):128-131.

[23]劉榮蓉•商務智能與財務信息化建設[J]•交通財會,2012, (7):50-54.

[24]D.S.Taubman, M.W. Mai*cellin. JPEG 2000: Image Compression Fundamental, Standards and Practice.

Journal of Electronic Imaging, 2002, 11(2):286-287.

[25]孟君，徐嵐，許健等.銀醫合作模式下一站式服務對門診流程優化改造究[J].中國醫院,2012, 16(2):15-1 &

[26]穆云慶，李剛榮，趙存現•基于“城市一卡通”的門診就醫流程設計[J].重慶醫學,2009,(13)： 1568-1569.

[27]陳力，楊雅各.門診銀醫一卡通項目的設計與應用[J].中國數字醫學,2009, (2):70-72.

[28]陳學軍，徐苗桑，蘇依燦.醫院門診預存消費模式下安全防范措施的研究與應用[J].中國醫院,2009, (6):55-56.

[29]蔡娟.基于Web的CRM系統研究[M].武漢:華中科技大學計算機科學與技術學院,2006.

卩0]鄒麗.基于MVC的高職學校設備管理系統設計與實現[D].大連理工大學,2016.

[31]曾露.MVC模式在Android中的應用研究[J].軟件,2016, 37(06):75-7&

[32]屈展，李嬋.JSON在Ajax數據交換中的應用研究卩].西安石油大學學報(自然科學版),2011,53(01):95-9&

[33]Ali Mesbah, Arie van Deursen.A component-and push-basedarchitectural style for AJAX APPlications[J]. The Journal of Sys-tems and Software, 2008, 81(12):2194-2209.

[34]Ryan M. Hope, Michael J. Schoelles, Wayne D. Gray. Simplifying the interaction between cognitive models and task environments with the JSON Network Interface[J]. Behavior Research Methods, 2014, Vol.46(4): 1007-1012.

卩5] Greenspan J, Bulger B. MySQL/PHP database Applications. John Wiley & Sons Inc. 2001.

[36]李剛•瘋狂Android講義[M]•電子工業出版社.2011.

[37]曾健平，邵艷潔.Android系統架構及應用程序開發研究[J].微計算機信息,201用09:1-3.

卩8]白文江.基于Android平臺的移動應用開發研究[J].太原大學學報,2011,03:117-120.

[39]王茜.Android嵌入式系統架構及內核淺析[J].電腦開發與應用,2011,04:59-61.

[40]范鋒.Android的架構與應用開發研究[J].信息與電腦(理論版),2012, 05:55-56.

[41]Ya Zhao, Xin Chen Zhang, Zhen Yang, Jia Xin Chen. Design on HEVC Streaming Media Player

Based for Android[J]. APPlied Mechanics and Materials, 2014, 2865(462).

[42]Fisher M, Ellis J, Bruce J C. JDBC API tutorial and reference. Pearson Education. 2003.

[43]周小雪.基于Android的教務系統客戶端的設計與實現[D].電子科技大學,2018.

[44]Connolly T M,康諾利,Begg C E等.數據庫設計教程.機械工業岀版社,2005.

[45]燕磊.基層醫院信息系統的數據庫設計及優化.電子制作.2014,3:121.