【導(dǎo)讀】了解項目開發(fā)背景，分析項目進(jìn)度管理系統(tǒng)功能需求，研究其設(shè)計及實現(xiàn)技術(shù)。作為物流企業(yè)的管理軟件，系統(tǒng)必需能夠?qū)崿F(xiàn)諸如發(fā)送貨物、運輸貨物、裝載貨物、總結(jié)歸納所完成的任務(wù)，彌補不足，以最短的時間用最少的投入實現(xiàn)項目的開發(fā)。國民經(jīng)濟和社會發(fā)展中發(fā)揮著重要作用。本文在物流企業(yè)的正常運營中，基于。GIS的信息系統(tǒng)已經(jīng)成為不可或缺的管理工具。在對WebGIS技術(shù)和物流企業(yè)需。系統(tǒng)采用B/S架構(gòu)，服務(wù)器端通過網(wǎng)絡(luò)與車輛終端通。信，向車輛發(fā)送控制信息并獲取車輛的當(dāng)前狀態(tài)。交互，向客戶端提供地圖服務(wù)，并執(zhí)行Web客戶端的請求?？紤]到可擴展性，系統(tǒng)重點實現(xiàn)了服務(wù)器端進(jìn)行消息中。新消息隊列中消息處理方式。并通過對系統(tǒng)的測試，對其功能和性能進(jìn)行評估。進(jìn)行了總結(jié)，介紹了系統(tǒng)的特點和不足之處，指出了下一步的工作方向。

　　

【正文】 創(chuàng)建適當(dāng)?shù)哪Ｐ?，并將其傳遞到視圖以供顯示。在 MapBuilder 中 分別對應(yīng)于模式（ Model）、飾件（ Widget）、工具（ Tool）三種東北大 學(xué)本科畢業(yè)設(shè)計（論文） 第 2 章 相關(guān)技術(shù)簡介 9 類型的 JavaScript 對象，實現(xiàn)了數(shù)據(jù)管理、信息表達(dá)和交互操作的模塊化。 MVC 模式中的一個重要問題是數(shù)據(jù)的組織管理，對于 MapBuilder 而言就是數(shù)據(jù)模型。 MapBuilder 不提供通常的點、線、面等幾何對象的封裝，整個數(shù)據(jù)流完全通過 XML配置與解析進(jìn)行管理，其優(yōu)點是標(biāo)準(zhǔn)化程度高、客戶端使用便捷、無需編碼。這些數(shù)據(jù)流包括系統(tǒng)配置、地圖配置以及服務(wù)器端交互所產(chǎn)生的各種GML 數(shù)據(jù)。其中系統(tǒng)配置文件按照 資源描述框架 (Resource Description Framework, RDF)語法以 ObjectPropertyValue 格式定義所需對象，每個對象被賦予一個唯一標(biāo)識的 ID，通過 ID 在全局域中可直接以 來應(yīng)用指定的對象實例。地圖配置文件則按照 OGC 的 WMC（ Web Map Context）規(guī)范定義地圖所需各參數(shù)，所有配置文件都將在頁面加載時被自動解析，映射成為所定義的對象實例。系統(tǒng)配置自身被映射為模型對象 Config，所有模型對象都派生自抽象類 ModelBase，統(tǒng)一調(diào)用 GET 方法獲取數(shù) 據(jù)信息，并以 SET 方法設(shè)置、修改模型信息和狀態(tài)。 GML 數(shù)據(jù)僅作為中間交換數(shù)據(jù)存在，通常需要進(jìn)行 XPath 或XSLT 轉(zhuǎn)換處理。 MVC 模式的另一個重要問題就是消息的傳遞和相應(yīng)。 MapBuilder 中由兩種消息類型：一種是瀏覽器定義的各類系統(tǒng)消息，如鼠標(biāo)按下事件等；另一種是自定義消息，如加載模型事件 loadModel 等。系統(tǒng)消息由派生自 ToolBase 類的工具對象處理，如響應(yīng)鼠標(biāo)點擊事件。這些工具對象常作為飾件對象的一個屬性配置在系統(tǒng)文件。事件對象則通過 DIV 等標(biāo)記與網(wǎng)頁建立關(guān)聯(lián)來展現(xiàn)模型信息，一般派生自 WidgetBase 類。 WidgetBase 類與 ModelBase 類擁有共同的父類 Listener，因此飾件對象注冊給一個模型對象即可通過調(diào)用事件監(jiān)聽器互通自定義信息。模型的修改會影響飾件狀態(tài)，飾件同樣可以將系統(tǒng)事件的影響傳遞給模型處理 [12]。 Ajax 架構(gòu) Ajax 是一種創(chuàng)建交互網(wǎng)頁的技術(shù)，由 Adaptive Path 的咨詢顧問 Jesse James Garrett 首先提出。它不是單一的技術(shù)，而是 JavaScript、 CSS 、 DOM、XMLHttpRequest 對象的集合。其中 JavaScript 是通用的 腳本語言， Web 瀏覽器中嵌入的 JavaScript 解釋器允許通過程序與瀏覽器的很多內(nèi)建功能進(jìn)行交互。CSS（層疊樣式表）為 Web 頁面元素提供了一個可重用的可視化樣式的定義方法。它提供了簡單而強大的方法，以一致的方式定義和使用可視化式樣。 DOM（文檔對象模型）以一組可以使用 JavaScript 操作的可編程對象展示出 Web 頁面的結(jié)構(gòu)。 XMLHttpRequest 對象允許 Web 程序 從 Web 服務(wù)器以后臺活動的方式獲取數(shù)據(jù)。在 Ajax 的使用當(dāng)中， JavaScript 定義了業(yè)務(wù)規(guī)則和程序流程。應(yīng)用程東北大 學(xué)本科畢業(yè)設(shè)計（論文） 第 2 章 相關(guān)技術(shù)簡介 10 序使用 XMLHttpRequest 對象以后臺方式從服務(wù)器獲得數(shù)據(jù)。 DOM 對象根據(jù)服務(wù)器得到的數(shù)據(jù)修改客戶端 Web 頁面中的元素值。 CSS 利用規(guī)定好的樣式將DOM 對象顯示到瀏覽器中 [13]。 Spring 架構(gòu) Spring 是一個開源的架構(gòu)，由 Rod Johnson 開發(fā)并在他的著作 Expert OneonOne: J2EE Design and Development 中進(jìn)行描述。它用來簡化企業(yè)應(yīng)用程序的開發(fā)，使得 程序僅僅 利用 JavaBean 就能夠完成以前只能由 EJB 來完成的工作。任何的 Java 應(yīng)用程序都能從 Spring 框架的簡 單、可測試性和松耦合中得到好處，而不僅僅限定為服務(wù)器端的程序。在 J2EE 中， EJB 的原意是為了解決諸如分布式對象和遠(yuǎn)程事務(wù)等問題而設(shè)計的復(fù)雜的組件。 對于 復(fù)雜度不高的企業(yè)項目，在開發(fā)時也必須要承擔(dān) EJB 的眾多的 Java 源文件、繁雜的部署描述以及重型容器等不便。即使要解決的問題很簡單， EJB 的 使用 也會使得 企業(yè)系統(tǒng)的復(fù)雜度 大大增加 。所以 使用 Spring 來替代 EJB，它使得系統(tǒng)的復(fù)雜度 依賴 于 要解決的問題，減少了容器對設(shè)計的侵蝕。在簡化開發(fā)的同時，它盡量提供 了 和 EJB 相同的功能。 Spring 的信條是： J2EE 應(yīng)當(dāng)是 易于使用的。 簡單來說， Spring 是一個輕型的、控制反轉(zhuǎn)的并且支持面向方面的容器框架[14]。輕量級的容器意味著對程序代碼做最少的改動，就可以獲得 Spring 核心帶來的好處。 Spring 框架的核心基于依賴注入（ Dependency Injection, DI）技術(shù)。在 Spring 中，所有類資源都被應(yīng)用為 Bean，只需要遵循 JavaBean 的命名規(guī)則，DI 機制就可以類屬性配置操作與代碼相分離。對于基于接口編程的程序，通過采用 DI，為基于接口的設(shè)計而編寫的輔助代碼大大減少，接近于零。 Spring 框架中 DI 帶來 的好處主要有： (1) 減少“粘合”代碼。 DI 可以消除為了連接應(yīng)用程序的各個部分而編寫的大量代碼。 (2) 依賴的外置化。 Spring 中 DI 的通過外置的配置文件來實現(xiàn)，所以可以將依賴外置化。要改變依賴只需要修改配置文件而不需要修改代碼。 (3) 在統(tǒng)一的地方管理依賴。采用傳統(tǒng)方式管理依賴時，依賴關(guān)系會在代碼中散布開，改變它們通常會帶來問題。當(dāng)時用 DI 的時候，所有關(guān)于依賴的信息都通過一個簡單的庫進(jìn)行管理，使得管理依賴變得既簡單又不容易出錯。 (4) 提高可測試性。當(dāng)面向 DI 設(shè)計類時，類之間的依賴可以方便的進(jìn)行 改變。這一點在系統(tǒng)進(jìn)行測試時特別方便 [15]。 除了 DI 之外， Spring 框架還提供：面向方面（ AOP）編程機制、對數(shù)據(jù)訪東北大 學(xué)本科畢業(yè)設(shè)計（論文） 第 2 章 相關(guān)技術(shù)簡介 11 問的優(yōu)化、事務(wù)管理、 Web 層的 MVC 架構(gòu)、簡化整合 J2EE 功能、遠(yuǎn)程訪問（ Demoting）支持、 Mail 支持、計劃任務(wù)支持以及源代碼級的 Metadata（元數(shù)據(jù)）等功能。 本章小結(jié) 本章首先 對 GIS技術(shù)進(jìn)行了介紹，包括 GIS技術(shù)的基本功能 、 應(yīng)用范圍 、 以及將來的發(fā)展趨勢等。然后介紹 了 WebGIS，說明了 WebGIS的概念和優(yōu)點；介紹了 OGC組織以及它所提出來的 GML、 WMS、 WFS、 WCS等 WebGIS所用到的 OpenGIS協(xié)議，分析了每個協(xié)議的作用和相互的關(guān)系；同時介紹了支持 WebGIS開發(fā)的開源平臺，包括 WebGIS服務(wù)器軟件GeoServer、支持 GIS操作的數(shù)據(jù)庫 PostGIS以及實現(xiàn)了 WMS/WFS協(xié)議 采用 MVC模式 架構(gòu)的MapBuilder地圖操作組件。 最后對用于 Ajax架構(gòu)，以及用于簡化 J2EE開發(fā)的Spring做了介紹。 由本章的分析可知， J2EE平臺下的 WebGIS開發(fā)的協(xié)議已經(jīng)漸漸規(guī)范，有利于 GIS系統(tǒng)的開發(fā)和不同系統(tǒng)的相互訪問；支持軟件也日漸增多， 功能越發(fā)強大。其中 Spring框架 的出現(xiàn)更使得 J2EE服務(wù)器編程變得愈發(fā)簡單化和自動化 。 東北大學(xué)本科畢業(yè)設(shè)計（論文） 第 3 章 需求分析 12 第 3章 需求分析 需求分析是軟件開發(fā)流程中重要的一個環(huán)節(jié)， 需求分析的基本任務(wù)是根據(jù)用戶的需求，準(zhǔn)確定義要完成的系統(tǒng)的目標(biāo) ，回答系統(tǒng)必須 “做什么 ”的問題。它的主要用途是明確 系統(tǒng)需求，是用戶和開發(fā)人員之間進(jìn)行討論的基礎(chǔ)，并作為系統(tǒng)設(shè)計、實現(xiàn)以及測試的依據(jù) 。 只有準(zhǔn)確全面的需求獲取與分析才能保證系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)的順利進(jìn)行，為后期測試提供必要的支持。在參考了現(xiàn)有的 GIS 物流監(jiān)控系統(tǒng)的功能，并且考慮到了系統(tǒng)的擴展性和 成本 的基礎(chǔ)上， 最后制定了本系統(tǒng)的具體需求。 系統(tǒng)實現(xiàn)目標(biāo) 物流企業(yè)中，首先要對 貨物從發(fā)貨人發(fā)送貨物到收貨人提取貨物的整個過程進(jìn)行管理和記錄，要求能夠 隨時了解貨物的位置、狀態(tài)等屬性。同時管理人員通過系統(tǒng)能夠獲取 企業(yè)里 運輸車輛的位置、速度、方向、所載貨物等參數(shù)，并能夠發(fā)送命令給車輛，實時監(jiān)控和管理 整個 貨物運輸流程。 為保證物流系統(tǒng)能夠有效地為物流企業(yè)管理人員服務(wù)，從功能上必須達(dá)到以下目標(biāo)： (1) 必須實現(xiàn)物流企業(yè)中業(yè)務(wù)流程的所有必需功能。作為物流企業(yè)的管理軟件，系統(tǒng)必需能夠?qū)崿F(xiàn)諸如發(fā)送貨物、運輸貨物、裝載貨物、卸載貨物、車 輛線路編輯等功能。保證系統(tǒng)實現(xiàn)的功能的有效性。 (2) 必須保證管理人員得到信息的及時性和真實性。管理人員作為整個系統(tǒng)的調(diào)度者，系統(tǒng)的信息必須及時地顯示給管理人員。對于重要的信息，系統(tǒng)應(yīng)該使用彈出警告窗口、修改顯示信息的字體顏色等手段引起管理人員的注意，保證系統(tǒng)調(diào)度的及時性。 (3) 必須保證管理人員和運輸車輛之間進(jìn)行有效地、及時地通信。對于物流系統(tǒng)來說，系統(tǒng)的實時調(diào)度和管理是十分重要的，其中對車輛的調(diào)度尤其重要。所以，要保證管理人員和運輸車輛之間通信的及時性，提高系統(tǒng)調(diào)度的效率。 系統(tǒng)運行環(huán)境 為了充分使 用物流企業(yè)的現(xiàn)有軟硬件資源，在保障物流信息系統(tǒng)穩(wěn)定、高效運行的前提下，達(dá)到降低成本的目的。根據(jù)系統(tǒng)需求，設(shè)定了物流信息系統(tǒng)的運行環(huán)境。 網(wǎng)絡(luò) 環(huán)境： 東北大學(xué)本科畢業(yè)設(shè)計（論文） 第 3 章 需求分析 13 服務(wù)器和操作主機都需要采用 Inter,車輛終端通過 GPRSInter 網(wǎng)關(guān)最終連接到 Inter。 硬件環(huán)境： (1) 服務(wù)器主機配置： CPU使用 Intel P 4 Xeon, 雙 CPU，內(nèi)存為 2GB，選用2 塊 120GB 的 SCSI 硬盤進(jìn)行同時讀寫。 (2) 客戶端機器配置： CPU最低 Intel PIII 800MHz以上，內(nèi)存 128MB 以上。 (3) 車輛終端配置：每個車輛配置 GPS 數(shù)據(jù)收發(fā)器一個，用來獲取 GPS 數(shù)據(jù)，通過 GPRS 網(wǎng)絡(luò)和服務(wù)器進(jìn)行通信。 (4) 其他配置： GPRSInter 數(shù)據(jù)轉(zhuǎn)換網(wǎng)關(guān)若干，用來將 GPRS 網(wǎng)絡(luò)中車輛數(shù)據(jù)轉(zhuǎn)換為 Inter 網(wǎng)絡(luò)中的數(shù)據(jù)。 軟件環(huán)境： 服務(wù)器： Windows 2020 服務(wù)器版操作系統(tǒng)， 服務(wù)器， 地圖服務(wù)器， 數(shù)據(jù)庫。 客戶端： Windows2020 操作系統(tǒng)以上， 以上、 以上或者Netscape6 以上。 系統(tǒng)的開發(fā)環(huán)境 考慮到系統(tǒng)成本問題，全部采用開源 軟件和框架 來構(gòu)建此系統(tǒng)。相對來說，開源軟件成本低，功能相對簡單。 服務(wù)器端軟件環(huán)境： Web 服務(wù)器采用 ，它部署和使用起來都很方便，支持的功能對本系統(tǒng)來說已經(jīng)足夠。地圖服務(wù)器采用 ，它是一個全面支持 OGC 開放性協(xié)議的開源地圖服務(wù)器，能夠分別以圖片和實際數(shù)據(jù)的方式發(fā)布地圖數(shù)據(jù)。數(shù)據(jù)庫服務(wù)器采用 ，它是對 的補充，有豐富的數(shù)據(jù)類型和處理地理 數(shù)據(jù)的函數(shù)，而且 GeoServer 與 PostGIS之間的操作經(jīng)過一定的優(yōu)化。 客戶端環(huán)境搭建：地圖顯示采用 MapBuilder 地圖操作組件 ，它是由 Javascript語言實現(xiàn)的一個庫文件，可以方便的嵌入到網(wǎng)頁中去。系統(tǒng)信息實時顯示與實時更新的實現(xiàn)，需要采用 Ajax 技術(shù)的支持。 開發(fā)工具與支持環(huán)境：系統(tǒng)開發(fā)采用 Eclipse?？紤]到 系統(tǒng)的擴展性和實體類的獨立性 ，采用 Spring作為 J2EE實現(xiàn)的服務(wù)器端容器，數(shù)據(jù)庫訪問則采用 Ibatis組件實現(xiàn) 。 這些開源軟件的采用，降低了系統(tǒng)開發(fā)難度， 提高了軟件的可復(fù)用性。 功能性 需求描述 東北大學(xué)本科畢業(yè)設(shè)計（論文） 第 3 章 需求分析 14 在面向?qū)ο蟮南到y(tǒng)分析中，獲取功能需求的最常用的技術(shù)就是用例建模技術(shù)。它能夠直觀地向客戶展示系統(tǒng)的功能，方便技術(shù)人員準(zhǔn)確地獲取需求。在項目開發(fā)的前期，它幫助開發(fā)人員理解系統(tǒng)的需求而不考慮具體的實現(xiàn)方法。用例，表示系統(tǒng)的一種行為或者某個功能。它是在特定條件下，為了達(dá)到某種目的，系統(tǒng)和用戶之間進(jìn)行交互的一個序列。用例模型由參與者和用例組成。參與者是與系統(tǒng)進(jìn)行交互的外部實體，可能是某個人或者是某個事物 [16]。圖 顯示的就是本系統(tǒng)的用例圖。 本系統(tǒng)中，參與者有五個，管理人員、發(fā)貨人、收貨人、車輛和 定時器。對于用例分析來說，只有用例圖和用例描述相結(jié)合才能表示系統(tǒng)的需求，相關(guān)的用例描述如下。 系 統(tǒng)顯 示 實 時 信 息 系 統(tǒng)傳 遞 消 息發(fā) 送 實 時 狀 態(tài) 信 息配 置 車 輛 險 路查 詢 系 統(tǒng) 信 息查 詢 貨 物 狀 態(tài)發(fā) 送 貨 物提 貨