1、公交查詢系統的設計與實現班級：12物聯網工程學號：1202141057姓名：鄭秀成日期：2021年12月15日引言隨著因特網開展的日新月異,人們利用網絡實現資源共享以及協同工作越來越成為時代的潮流,使用各種網上的軟件方便生活,已經成為了一個不可扭轉的趨勢.以此設計題目為目的,選擇市作為實踐對象,以市公交系統為根底,再利用所學知識,熟練運用開發工具后,開發一個市公交線路查詢軟件,并且盡可能將其開發為一個方便大眾使用的公交線路查詢軟件.而且在當今公交出行線路多數是通過PC機查詢獲得的,但是假想一下在公交出行線路走到一半的時候方案有所變化,公交出行線路需要有所調整,那么如何能夠動態學握線路信息顯得尤

2、為重要,而且將來對生活的滿意度也不僅僅是百姓致富安居樂業就足以,而是逐漸趨向于一個更人性化的效勞.城市交通效勞以及附屬的一些效勞一直都在不斷的隨著社會的進步而進步,這些效勞從最開始的直接人力效勞轉向技術型效勞,如詢問,路牌等,然而這些效勞總是有比擬大的局限性,即縱然你知道了這條路該怎么走,下條路線該通到哪卻不知,于是開發這個公交線路查詢軟件,可在上隨時隨地對公交線路進行查詢,對用戶將要出行的路線了如指掌,這對用戶來說可以省去很多麻煩,節省不少時間.本次畢業設計結合市公交線路系統開發一個公交線路查詢軟件效勞于群眾.目錄第一章需求分析與概要設計1.1 可行性分析11.2 需求分析21.2.1 系統

3、功能需求21.2.2 效勞器端需求分析31.2.3 客戶端需求分析. 開發環境及工具需求分析51.3 概要設計61.3.1 開發流程61.3.2 系統數據流圖61.3.3 系統整體結構說明71.3.4 系統功能模塊的劃分8第二章模式設計122.1 C/S模式簡介122.2 B/S模式簡介122.3 B/S-C/S模式132.3.1 B/S-C/S模式定義 B/S-C/S模式特點1.5第三章數據庫設計163.1 數據庫結構163.2 效勞器數據庫設計：163.3 客戶端數據庫設計：203.3.1 SQLite簡介203.3.2 數據庫設計21第四章系統測試244.1

4、 系統測試方案24.4.2 性能分析24.2.6.總結第一章需求分析與概要設計1.1 可行性分析可行性分析是對系統進行全面、概要的分析.它的任務是確定工程開發時是否必要和可行.它的主要目標是：進一步明確系統的目標、規模和功能,對系統開發背景、必要性和意義進行調查分析,并且提出系統的邏輯模型和各種可能的方案,從而為系統開發工程的決策提供科學依據.主要從三個方面進行研究：1技術可行性：以現有技術進行系統開發及系統實施,是完全可行的.首先,從自身來分析,經過2年多的學習已經初步掌握了JSP空件、SQL數據庫等方面的編程技巧,對該軟件的設計并不存在技術上的難點.第二方面,在設計這個系統之前,我進行了一

5、系列先期調研,查閱了有關使用JSP!行數據庫開發方面的論著、教材和論文,更多是利用網絡的便利條件,從網上查閱了北京、上海、等大型城市的公交查詢系統,并認真地對其進行了分析研究,由于時間緊,任務重,我沒有更多的時間來開發完整的系統,所以就以查詢作為這個系統的核心.其次,從數據庫方面來分析,也是可行的.系統所建立的數據庫表中包含有五個字段：bus_number,bus_station1,bus_station2,bus_station3,bus_station4.bus_number用來存放車次,bus_station1,bus_station2,bus_station3,bus_station4

6、這四個字段用來存放站點.2經濟可行性：從這方面來說,本系統的開發作為課題來說不需要什么經濟投入,因此來說也是可行的.3營運可行性：國很早就開始應用公交查詢系統,我國大局部城市都有公交查詢系統.那么從這方面來說是可行的.1.2 需求分析公交線路查詢軟件最根本的功能是能夠有效的為用戶提供查詢效勞,在最短的時間給用戶一條或多條到達目標地的路徑.整個查詢過程中,只有數據信息是依靠效勞器同步獲取,其余功能均在端完成.在此分別對公交線路查詢軟件的效勞器端和客戶端做需求分析.1.2.1 系統功能需求本系統的用戶包括用戶和治理員兩類,其中治理人員對此系統進行數據的修改、刪除、查找、添加路線以及發布公交動態等功

7、能.而用戶那么可運用本系統合理有效的查詢路線、安排行程.功能規劃：本系統有兩大功能：查詢功能以及更新維護功能.其中查詢功能包括站站查詢功能、車次查詢功能、公交站點車次查詢三項根本功能.功能描述：a.站站查詢：乘客通過輸入起點和終點的站名,那么通過這兩個車站的所有車次就會顯示出來供乘客選擇適宜的乘車路線b.車次查詢：乘客通過輸入公交車車次就可以查詢出該車次經過的所有站點,乘客可以根據站點來選擇自己的乘車路線c.公交站點車次查詢：這種方案一般針對不城市公交不熟悉的人,通過輸入站點或者車次就可以同時顯示站點和車次兩種信息,根據這個就可以選出最正確的乘車方案.d.更新維護：治理員負責對公交路線修改和更

8、新,以及系統的維護,同時公布最新的變動信息包括車次變動和價格變動等或者有關城市公交的新聞對性能的一般性規定:1靈活性：當要對系統進行添加數據或刪除、更新等操作時,可以容易地對系統進行操作,并且不影響系統的正常運行,更不會有任何出錯的現象.2數據精確：由于此數據為系統部數據,所以要求不能有誤差.3時間特性:系統應有即時性,能盡快查詢出所需結果1.2.2 效勞器端需求分析效勞器作為后臺,需要專業人員對效勞器操作和維護,一般情況可由非專業人員借助治理軟件對效勞器進行常規維護.效勞器可以通過數據庫同步,為客戶端數據庫提供數據.通過仔細分析效勞器需求之后,效勞器端要完成以下功能：1、效勞器后臺治理功能效

9、勞器后臺治理是針對數據庫進行操作,具有增、刪、改、查功能.2、數據同步功能.采用Servlet技術,響應客戶端請求,返回給客戶端一端數據流,該數據流根據Xml語言規寫入數據流.效勞器端功能模塊劃分如圖1.1.1所示.圖1.2.1效勞器端功能模塊圖1.2.3 客戶端需求分析客戶端主要是,用戶無法通過對本地數據庫進行操作,也無法對服務器數據庫操作,治理員可以通過瀏覽器登錄到效勞器治理員頁面對數據庫進行操作,可以使用一些功能.該軟件應滿足假設干要求,比方能夠隨時掌握公交信息,動態更新最新數據等.也要考慮作為軟件可能會出現查詢速度慢,數據流量過大,過度依賴效勞器等問題.通過仔細分析用戶需求之后,該軟件

10、要完成以下功能：1、查詢線路功能獲得線路經過的每個站點信息以及線路的票價信息和發車時間信息.2、地圖查詢功能借助GoogleMap,完成公交查詢并顯示地圖線路.3、數據更新功能效勞器響應客戶端請求返回一段數據流,客戶端接收此數據流后,根據Xml語言規對數據流進行解析,解析后將數據存入客戶端數據庫.4、意見反應功能通過將意見發送到治理員的.客戶端功能模塊劃分如圖1.1.2所示.客戶端功能模塊圖圖1.2.2朋務磐發生時間票m信公交線路1.2.4 開發環境及工具需求分析效勞器端開發環境,以windows7操作系統為開發平臺,用Tomcat6.0做為效勞器,Mysql5.0作為數據源,JSP作為開發工

11、具,Dreamweaver8.0作為輔助開發工具,運行在一般的PC機上即可.客戶端開發環境,以Android操作系統為開發平臺,用Android操作系統自帶的SQLite作為數據源.Java語言和Xml語言作為開發工具,Eclipse3.5作為輔助開發工具.整個Android操作系統是在AndroidSDK提供的虛擬機中運行,該虛擬機運行在windows7操作系統上,所以客戶端的開發是在windows7操作系統上運行的Android操作系統中進行的二次開發.1.3 概要設計1.3.1 開發流程開發流程如圖1.3.1所示.,調查研究,確定功能編寫程序匚二調試程序壯運行測試優化完善圖1.3.1開發

12、流程圖1.3.2 系統數據流圖系統數據流程如圖1.3.2所示.圖1.3.2系統數據流圖1.3.3 系統整體結構說明該系統包括前臺和后臺兩局部,主要包括用登陸、站點輸入、線路輸出、站點修改、線路更新等功能.系統的整體功能模塊圖如圖1.2.3所示：公交查詢系統后臺治理系統前臺查詢系統本站導航圖1.3.3整體功能模塊圖1.3.4 系統功能模塊的劃分公交查詢系統功能劃分模塊如下：1查詢系統模塊該模塊實現公交查詢功能.可實現按起點-中轉站-終點查詢查詢和按線路查詢兩種查詢方式.圖1.3.4查詢系統模塊2錄入系統模塊該模塊實現數據的錄入、修改、刪除功能.該模塊由公交站點治理與公交線路治理兩局部組成.詳細設

13、計視圖如圖1.3.5錄入系統模塊所示：丫J生成漫游方案Y在生成放大方案Y開始丁用戶錄入地圖信息1將用戶輸入信息傳入mapOperatemapOperate的、參數是否漫游/NmapOperate的參數是否放大.NjXmapOperate的參生成縮小方案Ymap生成測距方案3信息輸入輸出模塊如圖數是否縮/1/NnOperate的參_N是否是測距/|日一,、專顯不乘車力案*圖1.2.5錄入系統模塊1.3.6所示：圖1.3.6信息輸出模塊第二章模式設計2.1C/S模式簡介精簡白說：C/S模式是一種三層結構的系統,第一層在客戶機上安裝了客戶機應用程序,第二層在效勞器上安裝效勞器治理程序,第三層是數據訪

14、問層.在C/S模式的工作過程中,客戶機程序發出請求,效勞器程序接收并且處理客戶機程序提出的請求然后返回結果.C/S模式特點：(1)C/S模式將應用與效勞別離,系統具有穩定性和靈活性(2)C/S模式配備的是點對點的結構模式,適用于局域網,有可靠的平安性(3)由于客戶端實現與效勞器端的直接連接,沒有中間環節,因此響應速度快(4)在C/S模式中,作為客戶機的計算機都要安裝客戶機程序,一旦軟件系統開每臺客戶機都要安裝客戶機程序,系統升級和維護較為復雜發.2.2 B/S模式簡介精簡白說：B/S模式是一種從傳統的三層C/S模式開展起來的新的網絡結構模式,其本質也是三層結構的C/S模式.在用戶的計算機上安裝

15、瀏覽器軟件,在效勞器上存放數據并且安裝效勞應用程序,效勞器有WWW效勞器和文件效勞器等.用戶通過瀏覽器訪問效勞器,進行信息瀏覽、文件傳輸和電子等效勞.B/S模式特點：(1)系統開發、維護、升級方便每當效勞器應用程序升級時,只要在效勞器上升級效勞應用程序即可,用戶計算機上的瀏覽器軟件不需要修改,系統開發和升級維護方便.(2)B/S模式具有很強的開放性在B/S模式下,用戶通過通用的瀏覽器進行訪問,系統開放性好.(3)B/S模式的結構易于擴展由于Web的平臺無關性,B/S模式的結構可以任意擴展,可以從包含一臺效勞器和幾個用戶的小型系統擴展成為擁有成千上萬個用戶的大型系統.(4)用戶使用方便B/S模式

16、的應用軟件都是基于Web瀏覽器的,而Web瀏覽器的界面是類似的.對于無用戶交換功能的頁面.用戶接觸的界面都是一致的,用戶使用方便.2.3 B/S-C/S模式2.3.1 B/S-C/S模式定義B/S-C/S模式是將B/S模式和C/S模式組合而來的,吸取這兩種模式的優點,到達互補的作用.B/S模式和C/S模式都是三層結構,B/S模式第一層是表現層,第二層是業務邏輯層,第三層是數據訪問層.C/S模式三層結構中第一層是客戶端與B/S模式中的第一層不一樣,其余兩層相同.在B/S模式和C/S模式數據訪問過程和業務邏輯處理過程中是在效勞器端完成,用戶只需接受效勞器返回的結果.在B/S-C/S模式中,一局部數

17、據訪問過程和業務邏輯處理過程在客戶端完成,另外一局部數據訪問過程和業務邏輯處理過程在效勞器端完成.本公交線路查詢軟件一局部功能只要依靠本地數據庫就可以實現,令外一局部功能需要借助互聯網實現.目前不管是硬件還是計算機硬件,更新速度很快,而且硬件的配置水平也越來越高,在硬件條件允許的情況下把一局部業務處理、數據訪問的過程放在客戶端去完成,那么對效勞器的硬件要求就會低一些,甚至一些高性能的PC機就可以作為效勞器.從整個作業量來看,本質上是把作業量往客戶端多分攤一部分,降低效勞器的作業量,因此,對客戶端的硬件要比擬高的.B/S-C/S模式結構如圖2.3.1所示.本軟件系統采用B/S-C/S模式,系統框

18、架如圖2.3.2所示圖2.3.2系統框架圖2.3.2 B/S-C/S模式特點B/S-C/S模式在28承了B/S模式和C/S模式的優點之后,還具有以下特點：(1)可靠性高1、客戶端不必完全依賴于效勞器,即便脫離效勞器,還有數據庫的支持,可以繼續使用一局部功能.2、客戶端的數據喪失的時候,可以采用數據庫同步的方式從效勞器獲得新的數據信息.(2)省資源一局部作業在客戶端完成,效勞器的訪問量和作業量都會減少,省資源,維護起來會更加方便.第三章數據庫設計3.1 數據庫結構效勞器數據庫為總數據源,每一個客戶端都擁有獨立的小型數據庫.客戶端數據庫信息從效勞器端同步獲得效勞器的數據庫是基于Mysql建立,客戶

19、端數據庫是基于SQUte建立數據庫體圖3.1.1數據庫體系結構圖3.2 效勞器數據庫設計：用戶的需求具體表達在對各種信息的提供、保存、更新和查詢等方面.因此,一個滿足要求的數據庫必須充分滿足對各種信息的輸入輸出需要.公交查詢系統應滿足以下信息需求：治理員必須先登錄系統后臺治理才能對系統中線路、站點等信息進行添加、刪除、修改等工作.普通用戶不需進行注冊就可以直接查詢相關信息.一輛公交車經過多個站點.每個站點有多輛公交叫信息.一輛公交只有一條行駛線路.一條線路包括多個站點.綜合上面對網上購物系統數據庫的需求分析,考慮到未來功能上的擴展,設計如下的數據項結構：治理員信息包括的數據項：帳號、姓名和密碼

20、.公交車信息包括的數據項：線路號、始發時間、末班時間、車輛等級、車輛類型、始發站、終點站.站點信息包括的數據項：站點名稱、要經過的線路號.線路信息包括的數據項：線路號、線路中包括的站點號.通過上面數據庫的需求分析可知,該系統的實體有治理員實體、公交車實體、線路實體、站點實體.治理員實體如圖3.2.1所示：治理員圖3.2.1治理員實體圖公交車實體圖如圖3.2.2所示:圖3.2.2公交車實體圖線路實體如圖3.2.3所示:圖3.2.3線路實體圖站點實體圖如圖3.2.4所示:圖3.2.4站點實體圖各實體間關系的E-R圖如圖3.2.5所示:圖3.2.5各實體間關系E-R圖根據上面的E-R圖,本軟件效勞器

21、端定義的arashmen數據庫設計了以下4表：站點表：station表2、線路表：routes表3、發車時間表：departuretime表4、票表:fare表5.本軟件效勞器數據庫所包含的表的描述如表1.表3.1治理員信息表數據名稱字段類型說明Account文本治理員帳號NamePassWord文本治理員姓名文本治理員密碼線路的信息表如表3.2所不:表3.2線路信息表數據名稱字段類型說明LineName文本線路名稱BeigenStEndSt文本起始站點文本終止站點Note文本線路信息公交車的信息表如表3.3所不：表3.3公交車信息表BusNum文本公交線路號BeigenStEndStBusL

22、evel文本始發站文本終點站文本公交等級BusState文本公交類型BeigenTimeEndTime文本始發時間文本末班時間站點的信息表如表3.4所不:表3.4站點信息表數據名稱字段類型說明StNameStNote文本站點信息3.3 客戶端數據庫設計：3.3.1 SQLite簡介Android數據庫使用的是SQLiteDatabase,我們來簡單的介紹下Android:臺上的SQLiteDatabase.SQLite是一款輕型的數據庫,是遵守ACID的關聯式數據庫治理系統,它的設計目標是嵌入式的,而且目前已經在很多嵌入式產品中使用了它,它占用資源非常的低,在嵌入式設備中,可能只需要幾百K的存

23、就夠了.它能夠支持Windows/Linux/Unix等等主流的操作系統,同時能夠跟很多程序語言相結合,比如Tcl、PHP、Java等,還有ODBC接口,同樣比起Mysql、PostgreSQL這兩款世界著名開源的數據庫治理系統來講,它的處理速度比他們都快.該軟件數據庫的建立是完全在Android平臺上執行Java代碼,通過DVM編譯來建立的,沒有什么輔助工具,由于整個SQLite數據庫是非可視化操作,所有對數據庫的操作都是通過執行Java代碼實現,在完成其查詢功能的時候沒有使用數據庫高級編程,較為麻煩的關節是在如何有機的將客戶端數據庫整體結構實現出來,實現過程是無可視界面,也沒有數據庫輔助工

24、具情況下,整個過程很抽象.且表的設計應盡量簡單,不要有錯綜復雜的關系,每表都是獨立的,不存在任何約束,數據庫也是獨立數據庫,不采用Android特有的可共享數據庫.3.3.2 數據庫設計E-R關系如圖3.3.1所示.圖3.3.1客戶端數據庫E-R圖根據上面的E-R圖,本軟件客戶端定義的arashmen數據庫中包含以下4表:站點表：station表7、線路表：routes表8、發車時間表：departuretime表9、票表:fare表10.本軟件效勞器數據庫所包含的表的描述如表6o表3.6數據庫概況表表名描述主要字段stations站點表保存站點信息ID,stationroutes線路表保存線

25、路信息ID,RouteName,ContentDeparturetime保存首班發車時間RouteName發車時間表保存末班發車時間FirstDepartureTime,LastDepartureTimefare票價信息表保存公交線路票價信息ID,isFixed,FullFare表3.7站點表/idInt4PKID,自動增長StationVarchar50表3.8線路表數據類型主4t/外鍵默認值RouteNameChar20PK線路名稱ContentLongText表3.9發車時1日表字段名數據類型長度主4t/外鍵默認值idInt4PKID,自動增長RouteNameChar20FK線路名稱F

26、irstDepartureTimeTime首班發車時間LastDepartureTimeTime末班發車時間表3.10票價信息表長度主4t/外鍵默認值idInt4PKID,自動增長RouteNameChar20FK線路名稱isFixedFareChar5是否為分段計費FullFareDouble8全程票價第四章系統測試4.1 系統測試方案根據本程序的實際情況,進行了如下測試：1)輸入異常數據或進行異常操作在主頁面中輸入與車次無關的站點信息,系統將對所輸入的信息與數據庫中的信息作比擬,如果沒有找到相對應的信息,那么系統顯示為空.當用戶沒有輸入任何字符的時候,系統會提示用戶輸入相應的信息,以便查詢.只有符合數據庫中的信息,才能進行相應的查找.2)災難恢復性測試由于本系統需要一個數據庫作為數據存儲的平臺,所以當數據庫遭到破壞的時候就無法運行,所以治理員在日常的添加、修改和刪除前都要進行必要的數據庫備份工作.另外由于本系統是靜態網頁,所以