熱門論文
最新論文
橋梁信息管理系統的設計與實現
發布時間：2023-07-25 09:39
摘要 I
Abstract Ill
第1章弓I言 1
1.1研究背景和意義 1
1.2國內外發展現狀 1
1.3本文主要研究內容與目標 2
1.3.1研究內容 2
1.3.2研究目標 3
1.4文章的組織結構 3
第2章相關技術介紹 5
2.1Java Web 開發技術 5
2.2Android : 6
2.3微信小程序技術 7
2.4高德開放平臺 7
2.5安全防范 8
2.6本章小結 10
第3章 系統需求分析 11
3.1可行性分析 11
3.1.1原有系統的研究 11
3.1.2新系統的高層邏輯模型 12
3.1.3技術可行性 13
3.1.4社會可行性 14
3.1.5經濟可行性 14
3.2系統的綜合要求 15
3.2.1功能需求 15
3.2.2性能需求 16
3.2.3環境需求 17
3.3系統的邏輯模型 18
3.3.1數據庫的概念設計 18
3.3.2系統邏輯模型設計 22
3.4本章小結 25
第4章 系統概要設計 26
4.1硬件體系結構 26
4.2軟件體系結構 27
4.3系統架構設計 28
4.4系統功能結構設計 29
4.5數據庫邏輯設計 30
4.6本章小結 35
第5章 系統詳細設計 36
5.1移動終端模塊 36
5.1.1數據傳輸 36
5.1.2地圖定位 39
5.2橋梁巡檢 39
5.2.1橋梁巡檢介紹 39
5.2.2橋梁巡檢流程設計 40
5.3橋梁技術狀況評定 41
5.3.1橋梁技術狀況評定介紹 41
5.3.2《公路橋涵養護規范》(JTGH11-2004)的評定方法 41
5.3.3橋梁技術狀況評定變權評定法 43
5.3.4橋梁技術狀況評定流程設計 43
5.4橋梁管理輔助決策 45
5.4.1管理輔助決策介紹 45
5.4.2資源分配方案決策 45
5.4.3養護維修方案決策 49
5.5本章小結 51
第6章 系統實現與測試 52
6.1主要功能實現 52
6.1.1用戶登錄 52
6.1.2主界面 53
6.1.3橋梁總覽和橋梁檢索 54
6.1.4橋梁錄入 55
6.1.5橋梁巡檢 57
6.1.6養護維修 57
6.1.7任務管理 58
6.1.8橋梁預警 58
6.1.9個人中心 59
6.2系統測試 60
6.2.1功能測試 60
6.2.2兼容性測試 61
6.2.3性能測試 61
6.3本章小結 62
第7章 總結與展望 63
7.1總結 63
7.2展望 63
參考文獻 65
致謝 68
攻讀碩士學位期間參與項目與成果情況 69
揚州大學學位論文原創性聲明和版權使用授權書 70
第1章引言
本章首先介紹該項目開發的背景和意義，然后分析該類系統目前在國內外的發展現 狀，最后闡述本文的研究內容和研究目的。
1.1研究背景和意義
近年來，隨著我國經濟快速發展，我國橋梁工程建設也取得了顯著的成就，在橋梁的 建設規模和質量上都有了很大的提升。但是橋梁在運營過程中仍然會受到惡劣環境的影 響，如天氣，行車荷載，交通事故等客觀外在因素，以及結構設備的逐漸衰老⑴，導致需 要維修加固的橋梁數量日益增長。不斷增長的交通量，使橋梁的養護維修工作也越來越繁 瑣。而我國目前部分城市橋梁管理采用的管理模式為紙質檔案模式，紙質檔案模式存在管 理效率低下的弊端，無法滿足橋梁在管理和養護上要求的信息化需求⑵。
目前我國大部分橋梁管理部門在橋梁出現明顯病害時，才對橋梁進行狀態評估，而橋 梁從出現病害到引起事故的時間一般都很短，所以橋梁管理人員有必要對橋梁進行經常性 的檢查并及時進行養護維修⑶，從而確保橋梁安全運營。
為了科學系統地管理橋梁資料，合理分配資金，材料，人員，提升橋梁養護管理水平， 保證橋梁處于安全的運行狀態，橋梁管理部門希望有一個用于橋梁管理的計算機輔助系 統，能夠方便地管理橋梁基礎資料，巡檢資料，評定橋梁技術狀況，輔助制定橋梁養護維 修計劃。
2014年6月23日，中華人民共和國住房和城鄉建設部發布了《住房建設部關于加快 城市道路橋梁建設改造的通知》(建城[2014]90號)⑷。其中提到：“到2015年底前，地 級以上城市要建成橋梁信息管理系統，東部地區要率先建成省級城市橋梁信息管理系 統。”。所以，開發一個橋梁信息管理系統來實現橋梁的科學管理勢在必行。
1.2國內外發展現狀
(1)國外發展現狀
30多年來，部分發達國家依次建成了橋梁管理系統(Bridge Management System, BMS)⑸，極大地促進了橋梁信息管理系統的研究和發展。BMS從產生到發展通常被分為 3個階段：第1代BMS能夠存儲橋梁基礎檔案信息，同時提供檢索、統計等功能；第2 代BMS除了能夠存儲橋梁基礎檔案信息，還存儲了橋梁巡檢信息和養護維修信息等；第3 代BMS在第二代基礎上添加了輔助決策功能，并使用數學方法對養護維修方案進行優化， 提供養護維修策略建議，系統可以輔助橋梁管理人員進行決策〔叫
丹麥橋梁病害主要由冰凍和鹽害引起。丹麥是最先發展橋梁信息管理系統的國家。丹 麥橋梁信息管理系統DANBRO主要通過對橋梁定期檢查和養護維修，來保證橋梁處于最 佳運營狀態，確保安全使用⑺。
美國從1987年開始橋梁信息管理系統的研究。研究分成兩個階段進行，第一階段重 點是構件數據庫，檢測維護作業分類，評分法，優先排序公式建立。第二階段對上個階段 成果進行整合并開發出了橋梁信息管理系統P0NTIS［8］o它主要通過對橋梁養護維修的投 資和利潤進行分析來提出合理的養護維修方案，其中利潤是指立即維修橋梁和延期一段時 間后再維修相比較所節省的費用［9】。
日本1995年建成第一版橋梁信息管理系統，它的優點是可以逐年更新橋梁的實際檢 測資料。為了能夠建立并管理大量的檢測資料和圖片等多媒體資料，提升數據傳輸速率， 日本在1998年結合營建信息運籌管理與產品資料交換標準(CALS/STEP)技術，進一步 完善橋梁信息管理系統。該系統將簡化橋梁檢測與維修的準備工作為主要目標，同時借助 互聯網簡化資料傳輸。此系統結合原來的橋梁信息管理系統，通過計算機網絡使橋梁維修 方和管理方能夠高效率的傳送資料和溝通［呵。
(2)國內發展現狀
我國已經開發了一些橋梁信息管理系統。例如，交通部開發了 “公路橋梁管理系統 (CBMS) ” o該系統結合了橋梁工程、病害機理、檢測技術和數據采集技術，運用計算 機對現有的橋梁進行信息采集、技術狀況評定、輔助決策，是一種能夠為橋梁養護維修、 技術狀況評定、輔助決策提供高效管理方法的輔助決策和綜合管理工具［⑴。
臺灣省在橋梁信息管理系統建設方面也取得了很大的進步。從1987年開始設計并開 發了橋梁信息管理系統。該系統包含基礎資料、檢測資料、統計分析、維修記錄、維修成 本估算、橋梁狀況排序六大功能模塊。各大功能模塊的運轉仍然以數據庫為核心。此外， 該系統使用地理信息系統技術實現了空間查詢分析功能。
蘇州市吳江區橋梁信息管理系統從2011年11月起正式上線運行。該系統主要提供橋 梁基礎信息管理、文檔管理、谷歌地圖定位、站內信通訊等功能，大幅提升橋梁管理工作 的效率。另外普通市民也能夠使用該系統了解橋梁信息并提交橋梁管理建議，提升橋梁管 理工作的質量。
1.3本文主要研究內容與目標
1.3.1研究內容
本文研究了國家現行橋梁養護評定規范，詳細分析了橋梁養護管理業務流程和管理細 節，對橋梁管理員進行需求訪談獲取需求。針對橋梁基礎信息管理、橋梁巡檢、橋梁技術 狀況評定、橋梁養護維修整個流程制定了一套可量化、可程序化的管理機制。研究了吳江 橋梁信息管理系統，發現不足，并在該系統的基礎上開發出一套功能全面，多平臺的橋梁 信息管理系統。針對決策人員、橋梁管理員、普通市民等不同的用戶群體開發出了不同的 功能模塊。
本文在原有基于Java Web的橋梁信息管理系統的基礎上,開發基于安卓的橋梁信息管 理系統。運用WebService和Socket技術實現了數據從安卓端到服務器端的傳輸；研究高 德地圖API,并以此為基礎進行二次開發，實現橋梁定位功能；研究安卓平臺的硬件API 和圖片編碼技術，實現拍照上傳功能；研究微信小程序技術，開發出針對普通市民的有橋 梁病害舉報功能和服務評價功能的微信小程序。
本文用多目標線性規劃(MOP)[12]的方法求解輔助決策中資源分配最優化問題，以滿足 在有限的養護資金和養護人員的條件下達到最好的養護維修效果。針對資源分配最優化問 題建立0-1多目標線性規劃模型，通過線性加權將多目標線性規劃轉化為0-1單目標線性 規劃，最后使用MATLAB中的intlinprog函數求最優解，根據最優解生成比較好的養護維 修決策建議。
在養護維修方案決策方面，本文構件橋梁養護維修知識庫，采用決策樹模型，通過選 擇橋梁類型、病害部件、病害部位、病害類型等條件來檢索知識庫中相應的養護維修對策， 展現給決策人員，來為決策人員提供養護維修方案建議。
1.3.2研究目標
本文設計并實現一個橋梁信息管理系統。和原有系統用相比，該系統具備對數據統計 分析的能力，且能夠多平臺使用，具備移動信息采集的能力。該系統能夠存儲橋梁基礎信 息，巡檢資料，根據橋梁基礎資料和巡檢資料對橋梁做出技術狀況評定，能夠提供養護維 修方案建議，輔助制定養護維修計劃。橋梁管理員能夠使用移動終端子系統進行橋梁檔案 資料的錄入，橋梁巡檢，橋梁養護維修；普通市民能夠通過微信小程序來向橋梁管理部門 舉報橋梁病害信息評價管理部門的工作；決策人員能夠使用該系統來制定養護維修計劃， 合理分配資金，人力。
1.4文章的組織結構
第1章為引言部分。主要介紹本文的研究背景和意義，國內外發展現狀，本文研究的 主要內容和目標以及本文的組織結構。
第2章為相關技術介紹。首先介紹了系統主要用到的開發技術，分別是Java Web開發 技術、Android開發技術、微信小程序開發技術以及Java Web開發中所用到的Spring MVC 和MyBatis兩大框架。然后主要闡述角色訪問控制和網絡安全技術。
第3章為系統的需求分析。首先分析了目前使用系統，然后導出新系統的邏輯模型并 對新系統進行可行性分析，最后從功能需求、性能需求、環境需求三方面來對系統進行需 求分析，給出了數據庫的概念設計和系統的邏輯模型設計。
第4章為系統的概要設計。主要介紹了系統用的硬件體系結構、軟件體系結構、系統 架構設計，并在需求分析的基礎上給出了系統的功能結構設計和數據庫的邏輯設計。
第5章為系統的詳細設計。詳細介紹了移動終端功能模塊的設計要點，闡述了橋梁巡 檢，橋梁技術狀況評定和輔助決策功能模塊的具體業務流程和詳細設計。
第6章為系統的實現與測試。對部分主要子功能模塊的實現進行了說明，簡要介紹了 系統測試。
第7章為總結和展望。對本文的研究成果以及不足之處進行總結歸納，對系統將來的 完善和發展進行展望。
第2章相關技術介紹
本章簡要介紹了橋梁信息管理系統開發過程中用到的一些開發語言、開發框架、開發 技術以及第三方API。
2.1 Java Web開發技術
［.Java語言
Java語言是革命性編程語言，因為傳統軟件對實現環境存在依賴，只要環境發生改變 那么就必須對軟件做出修改，這不僅耗時而且費力。相比較于其他編程語言，Java語言具 備了其他一些語言的優點，同時也彌補了它們的不足。其最大優點在于編寫的軟件在執行 碼上能夠兼容、能在所有平臺上運行。所以，Java是現在各大企業運用最廣的編程語言之 一。Java語言具有簡單性、平臺獨立性、面向對象［⑸、多線程［⑷、動態性、安全性、穩定 性、解釋性、可移植性［均等多種特性。
2.Web開發技術
隨著Web應用程序的發展，Web應用程序開發技術逐步成為研究Web信息系統開發 理論與方法的綜合性技術。目前Web應用開發主要有兩種形式：
(1)采用客戶端/服務器(Client/Server, C/S)結構的桌面應用；
(2)采用瀏覽器/服務器(Browser/Server, B/S)結構的網頁應用。隨著Web應用程 序的推廣，Web應用漸漸成為企業應用的主流〔⑹。
Web應用開發包括基于Java平臺的開發和基于Microsoft ASP.NET［17］平臺的開發。這 兩大平臺有很多共同特點，都可以使用超文本標記語言(Hypertext markup language, HTML) ［18\可擴展標記語言(Extensible markup language, XML)和數據庫技術等，并 且其客戶端開發技術也逐步兼容。
3.Java Web開發框架
(1)Spring MVC
Spring MVC問由 Spring Framework 發展而來，已被整合到 Spring Web Flow［20］內部。 Spring框架0】擁有構建Web應用的全功能MVC©】模塊。在進行Web應用開發時，我們可 以使用Spring MVC框架，也可以集成其他MVC開發框架，如Struts 1, Struts2等。
Spring MVC作為一個標準的MVC開發框架，不像Struts^】等框架都是變種或者部分 基于MVC設計模式。此外，它和Tapestry—樣，都屬于純正的Servlet系統。
(2)MyBatis
MyBatis 由屬于 Apache 的開源項目 iBatis 發展而來。2010 年 iBatis 從 Apache Software Foundation 遷移到 Google Code,更名為 MyBatiso 2013 年 11 月遷移到 Githubo
MyBatis是一個持久層框架，該框架集成了 SQL查詢、存儲過程調用和高級映射。它 封裝了幾乎全部通過手工設置的JDBC代碼，只需要進行簡單的XML配置和注解就能將 Java的POJOs映射成數據庫中的記錄〔卻。
每個MyBatis應用程序都是以SqlSessionFactory對象為核心的。創建SqlSessionFactory 對象，一般先通過xml配置文件或者預定義的配置類實例來獲取一個 SqlSessionFactoryBuilder,然后通過 SqlSessionFactoryBuilder 即可獲取 SqlSessionFactory 的 實例嘰
2.2 Android
1.Android平臺簡介
Android平臺Ml是針對移動設備開發的平臺。該平臺包含了操作系統、中間件和應用 程序。2007年，Google正式發布Android平臺□ 2010年底，Android平臺發展成為世界最 受歡迎的智能手機平臺。
2.Android平臺架構
Android 平臺主要包括 Applications （應用程序）,Application Framework （應用程序 框架），Libraries （庫），Android Runtime[27] （Android 運行時）和 Linux Kernel （Linux 內核）幾部分。
（1） Applications
Android平臺自帶了一些用Jaw語言編寫的應用程序，包括Email客戶端、SMS程序、 日歷程序、地圖程序、瀏覽器、通訊錄等[絢。
（2） Application Framework
Android的所有應用程序，都需要以Application Framework為基礎°使用Application Framework,不僅可以讓代碼編寫變得簡單，還能夠增強代碼的復用性口刃。
（3） Libraries
Android具備一組用C/C++編寫的庫，能夠為平臺的不同組件所使用。開發者能夠通 過Applications Framework來調用這些不同功能的庫。
（4） Android Runtime
Android Runtime包含核心庫和Dalvik虛擬機卩①兩大組成部分。核心庫的作用是為 Android平臺提供Java核心庫所具備的大部分功能。虛擬機的作用是為程序運行提供環境。 Dalvik虛擬機是專為移動設備設計的，具備效率高、占用內存少的優點。
(5)Linux Kernel
Android平臺是基于Linux2.6⑶］版本內核的，使用了 Linux系統的內存管理、進程管理 等核心系統服務。
3.安卓網絡編程技術
(1)WebService
WebService［32］也被叫做XML WebService,能夠接收從網絡上的其他系統中傳過來的 請求，屬于輕量級的獨立通訊技術。WebService是使用SOAP®】協議在網絡上提供的軟件 (服務)，通過WSDL文件進行說明，并使用UDDI注冊。WebService為實現跨平臺的可 互操作性，完全基于XML (可擴展標記語言)，不依賴于平臺和軟件供應商的標準。 Webservice可以在分布式計算環境中動態地描述、發布、發現和調用服務。
(2)Socket
網絡上的兩個程序采用一個雙向通信連接來實現數據交換，該連接就是一個Socketo Socket是采用的通信模式是C/S模式。在客戶端，使用Socket對指定網絡位置的某個服務 器端口發出連接請求，連接成功后會話開始，會話結束后關閉端口。客戶端端口一般是動 態的而且是隨機分配的。在服務器端，首先將SeverSocket和需要進行通訊的端口進行綁 定，對端口進行監聽。客戶請求連接成功后，服務器進行連接，完成會話，然后關閉連接。 2.3微信小程序技術
1.微信小程序簡介
微信小程序，又叫小程序，是一種基于微信平臺的、不需要下載安裝就能夠使用的應 用軟件。用戶可以通過掃描小程序二維碼或者搜索小程序名稱來打開并使用微信小程序。 微信小程序和微信平臺上的訂閱號、服務號、企業號是并行的。
2.微信小程序開發
微信小程序有單獨的一套開發框架。開發人員能夠使用該框架簡單、高效地開發出具 有原生APP體驗的微信小程序。該框架具備專門的視圖層描述語言WXML和WXSS,用 JavaScript編寫邏輯層代碼，而且為視圖層和邏輯層之間交互提供了專門的數據傳輸機制和 事件系統。該框架能夠讓開發者將關注點放在數據和邏輯上［珂。開發人員還能夠利用框架 內部的一系列現成的組件來進行快速開發。此外，框架還支持大部分微信原生API,開發 人員能夠使用這些API來調用微信的部分功能，如捕獲用戶信息、本地存儲厲】。
2.4高德開放平臺
1.平臺簡介
高德開放平臺的目的是將高德地圖的定位、地圖、導航等功能和LBS服務開源出來， 供開發人員使用。高德開放平臺提供地圖、定位、導航、搜索、路徑規劃、室內地圖等服 務〔叭
2.地圖API
高德開放平臺提供的地圖有2D地圖、3D地圖和衛星地圖等多種地圖形式。開發人員 可以根據自己需要的地圖模式調用相應的API和SDK來完成地圖搭建。此外，高德開放 平臺還具備強大的地圖二次開發能力，提供全面的地圖數據，擁有離線在線兩種地圖使用 方式，多種地圖交互模式，能夠滿足多種不同需求卩久
3.定位SDK
高德開放平臺的定位SDK采用GPS、基站、WiFi多種定位方式混合的定位模式進行 定位。混合定位模式的優點是可以根據天氣，地理位置等因素的不同選擇精度最高的定位 方式定位，從而達到在不同的環境下都能夠實現精準定位的目的［何。目前最新版Android 定位SDK能夠全球定位，同時具備室內定位功能。
2.5安全防范
1.基于角色的訪問控制
訪問控制的作用是保障信息及資源被合法訪問和使用。典型的訪問控制模型有：自主 訪問控制模型；強制訪問控制模型；基于角色的訪問控制模型；基于任務的訪問控制模型 等等［39］。
其中，基于角色的訪問控制(Role-Based Access Control, RBAC)是通過給用戶指定 角色，然后再給角色分配權限，這樣用戶和權限之間就通過角色建立了關聯，從而控制用 戶使用某些功能的權限［佝。一般RBAC模型的基本思想是建立一個角色集合，將用戶集合 與權限集合映射⑷］,如圖2-1所示：
圖2-1 RBAC模型圖
每一種角色都被分配了相應的權限，當某個系統用戶被指定為某種角色時，該用戶就 會獲得該角色的所有權限。這樣做的優點是創建用戶時只需要指定用戶的角色，而不需要 給每個用戶都分配具體的權限。此外，當我們需要修改某類用戶的權限時，不需要逐個修 改用戶的權限，只要更改用戶對應角色的權限即可。這大大簡化了用戶權限管理，降低權 限管理模塊開發成本［竝】。
RBAC是政策中立的授權模型，具備如下特點：相對靈活容易管理；支持職責分離的 原則；可以很容易地集成到現有的技術中［切；可以進行擴展網。
2.SQL注入攻擊的防范
SQL (Structure Query Language)是一種結構化的查詢語言。它不僅是一種查詢語言, 還是一種使用廣泛且功能強大的關系型數據庫語言，可以支持關系數據的三級模式。
微軟中國技術中心對其描述為［◎:
(1)腳本注入式的攻擊；
(2)惡意用戶輸入用來影響被執行的SQL腳本。
因此，SQL注入攻擊通常是指通過SQL注入技術來進行網絡攻擊跑。SQL注入攻擊 就是攻擊者在提交內容到服務器時，在瀏覽器地址欄或Web表單中輸入一些符號或語句， 讓系統執行的SQL語句變為攻擊者希望的語句，從而改變執行結果。攻擊者根據返回的執 行結果就能夠非法獲取一些隱私數據，比如管理員賬號、密碼、數據庫名、表名、字段名 等等敏感數據。然后根據獲取的數據就能進一步獲取對系統的操作權限［切。
SQL注入攻擊的實質就是在Web應用程序中輸入SQL語句，并通過一定的語法處理 進行攻擊。最容易被攻擊的Web應用程序就是在開發編程過程中，并沒有嚴格地檢查和處 理過濾SQL語句傳入的參數。
SQL注入攻擊有如下特點：
(1)廣泛性。當沒有嚴格處理輸入的SQL語句時，都可能會存在SQL注入漏洞；
(2)技術難度不高。網絡上現存多款SQL注入工具，很輕易就可以進行SQL注入攻 擊；
(3)危害性大。在成功進行SQL注入攻擊后，有的只是對網站首頁進行改動，但是 嚴重的則會通過網絡滲透等攻擊技術來進一步非法獲得數據以及絕密資料。
SQL注入攻擊是比較普遍的，而SQL漏洞有時難以發現，但它依舊是有一定的規律 性以及特定預防方法的。關鍵就是對網站接受數據可能存在的危險性字符進行檢測和處 理，防止網站程序執行由攻擊者惡意構造的SQL語句〔伺。
SQL注入攻擊有以下預防措施：
(1)檢測和處理客戶端輸入數據。SQL攻擊最常用的方法是在客戶端輸入數據中插 入惡意代碼，提交給服務器執行。所以分析和處理客戶端輸入內容是防范SQL注入攻擊的 重要方法；
(2)約定參數值的數據類型。如果用戶傳遞過來的數據不符合指定類型時，就對數 據執行強制類型轉換。如果轉換出現異常，終止程序執行；
(3)將用戶密碼等隱私數據加密之后保存。在進行用戶登錄校驗時，會將密碼加密 之后的密文和數據庫中的對應密文進行比較。Java提供了一個對字符串進行MD5算法加 密的方法，可用于系統用戶密碼的加密；
(4)用存儲過程代替查詢。使用存儲過程的參數集合，則傳輸的內容都將不會被當 作可執行代碼，反被當作為文本值。因此，數據庫將不在執行包含在其中的惡意程序；
(5)屏蔽程序異常和錯誤信息。攻擊者通常能夠從Web程序的異常和錯誤信息中獲 取制定SQL注入攻擊策略所需要的信息。屏蔽異常信息能夠增強網站對SQL注入攻擊的 防御能力；
(6)采用客戶端和服務器端的雙重驗證；
(7)采用最小權限原則。控制網站查詢數據庫的用戶權限，如普通用戶僅可以查看, 他的權限將不包括添加、刪除或更新。以不影響網站正常使用為前提條件，盡力把用戶的 系統權限縮減至最小范圍；
(8)定期檢查日志。對網站訪問日志的檢查要做到定時定期，這會有利于及時發現 攻擊者的來源，并分析攻擊的方式，以及攻擊的切入點等關鍵問題，還可以盡快實施相對 應的補救工作以及日后防范［呵。
2.6本章小結
本章簡要介紹了橋梁信息管理系統需要使用的Java Web開發技術、Android開發技術、 微信小程序開發技術，以及實現定位功能要使用的高德地圖API,以及為了增強系統安全 性能所使用的安全保障措施。本章的技術介紹為接下來的系統需求分析、設計和實現做好 鋪墊。
第3章系統需求分析
本章主要介紹系統的需求分析，確定了系統必須完成的工作。首先對系統進行可行性 分析，然后分析系統功能需求、性能需求、環境需求、最后根據需求導出新系統的邏輯模 型。
3.1可行性分析
系統的可行性分析的目的是確定問題是否有研究和解決的價值，就是花費最小的成本 和盡量短的時間來確定問題是否有解。軟件工程中通常從三方面來研究系統開發的可行 性，分別是技術可行性、經濟可行性、操作可行性。本章通過研究目前正在使用的系統， 導出新系統高層邏輯模型，然后從上述三方面分析新系統開發的可行性。
3.1.1原有系統的研究
目前正在使用的系統是進行系統可行性分析的重要信息來源。如果一個系統已經上線 運行，那么該系統肯定能正常完成某些工作，那么新系統也就必須能夠完成原有系統能夠 完成的工作。如果原有系統不存在問題，那么也就沒有開發新系統的必要。所以要進行新 系統開發，必須要發現原有系統的不足之處，并且新系統要能夠彌補原有系統中的缺點。 以下通過研究原有系統，了解原有系統的功能結構，找出系統不足之處。
1.吳江橋梁信息管理系統功能分析
2011年11月起，蘇州市吳江橋梁信息管理系統已經在吳江住建局上線運行，軟件已 經達到了當時預定的各項技術指標要求，運行良好，至今仍在維護和使用。橋梁管理員能 夠使用該系統進行橋梁基礎信息管理、文檔管理、發送站內信和在地圖上查看橋梁具體位 置。目前該系統已經錄入了 535座橋梁的基礎信息和所有吳江區橋梁管理員信息。該系統 的功能結構圖如圖3-1所示：
登陸注冊
圖3-1吳江橋梁信息管理系統功能結構圖
經過進一步抽象，吳江橋梁信息管理系統功能可以劃分為以下幾大模塊：動態信息管 理、靜態信息管理、系統管理、報告指令、文件管理。
（1） 動態信息管理模塊：主要提供橋梁管理、養護單位責權分配、巡檢工作任務管 理、病害錄入管理等功能。
（2） 靜態信息管理模塊：主要提供各種橋梁信息、檔案資料的錄入和組織管理功能。
（3） 系統管理模塊：提供系統日志、用戶權限、用戶登錄管理等基礎功能。
（4） 報告指令模塊：提供不同權限、不同類別用戶之間的交互通信功能。
（5） 文件管理模塊：主要對輸入系統并存儲的各種數據、文檔資料進行管理（文件 上傳下載，在線瀏覽等）。
系統功能模塊圖如圖3-2所示：
圖3-2吳江橋梁信息管理系統功能模塊圖
2.吳江橋梁信息管理系統的不足
結合國內外橋梁信息管理系統發展現狀，比較分析了無錫市、東莞市、鹽城市等城市 的橋梁信息管理系統。分析發現吳江橋梁信息管理系統存在以下不足之處：
（1） 沒有配套的移動終端子系統。錄入新建橋梁的信息時，橋梁管理員只能先行記 錄釆集到的橋梁信息，然后從Web端將信息錄入數據庫。
（2） 沒有橋梁技術狀況評定功能模塊。技術狀況評定主要是根據橋梁的結構特點， 使用功能要求，服務水平要求等，對橋梁進行數據采集和分析。橋梁技術狀況評定是制定 橋梁養護維修方案，項目優化排序等功能的重要依據。
（3） 沒有輔助決策分析功能模塊。輔助決策的目標是對現有橋梁數據進行統計分析, 合理配置資源，在確保橋梁安全運營的前提下達到盡可能大的養護維修效益。并且能夠制 定養護維修計劃，分配養護維修任務。
3.1.2新系統的高層邏輯模型
通過以上分析，發現吳江橋梁信息管理系統已經不能滿足現在的需求，存在一些明顯 缺陷。這些問題在新系統終將被解決。新系統將在原有系統的基礎上新增3個模塊，基于 安卓的移動終端模塊、基于微信小程序的市民監管模塊、基于Web的輔助決策模塊。新系
統的模塊圖如圖3-3所示：
圖3-3新系統的功能模塊圖
3.1.3技術可行性
技術可行性是指決策的技術和決策方案的技術能否突破組織所擁有的或有關人員所 掌握的資源條件的邊界。技術可行性至少包括3個方面：能否在規定時間內完成需求說明 中的功能；軟件的質量如何；軟件的產率如何。本文涉及到的相關技術包含：安卓開發技 術、微信小程序開發技術、Web服務器、數據庫、Java Web開發框架、軟件開發工具、操 作系統、系統分析與設計工具等。具體分析如下：
1.安卓開發技術：基于安卓的移動終端模塊的開發選用安卓原生開發模式。原生開發 相對于移動Web開發和混合開發，技術上都更為成熟。原生開發具有安裝包小、性能高、 用戶體驗好、可使用手機全部功能、支持大量圖形和動畫的優點。考慮到該模塊將要實現 定位，拍照等功能，需要調用安卓系統本身的一些API。所以使用原生開發模式更容易實 現該模塊的開發。
2.微信小程序開發技術：微信小程序擁有觸手可及、用完即走的特點，方便快捷，完 全符合市民監管模塊的要求。騰訊云也正式提供了微信小程序在云端服務器的技術方案。 因此用微信小程序開發市民監管模塊在技術上是可行的。
3.Web服務器：本文選用的是Tomcat服務器，Tomcat服務器是一個免費的開源輕量 級應用服務器。Tomcat服務器憑借技術先進、性能穩定的優點，成為目前應用比較廣泛的 Web應用服務器。該服務器完全符合本文的運行要求。
4.數據庫：本文選用的是Oracle數據庫，大部分的主流操作系統都能夠支持Oracle, 完全支持所有的工業標準。在安全性方面，Oracle數據庫的性能也是最高的。因此Oracle 數據庫是本系統開發的首要選擇。
5.Java Web開發框架：本文輔助決策模塊采用的是SSM開發框架，SSM框架是 Spring+Spring MVC+MyBatis的一個集成框架，是目前廣泛使用的一種Web應用程序開發 框架。該框架具有良好的可擴展性、可維護性，滿足本文的開發要求。
6.軟件開發工具：移動終端模塊的開發使用的是Android Studio,市民監管模塊使用 的是微信Web開發者工具，輔助決策模塊使用的開發工具是Eclipseo這些工具都是目前 使用比較成熟的開發工具，并且能夠滿足本文的開發要求。
7.操作系統：軟件部署系統選用的是Windows系統，它具有使用廣泛、操作簡單等 特點，因此Windows系統很適合用于軟件部署。
&設計工具：系統分析設計主要采用的是UML (Unified Modeling language)建模語 言，并采用Rational Rose進行制<> Rational Rose是一款開源的UML開發工具，滿足UML 建模的工作需求，很適合用于本文的建模分析。
3.1.4社會可行性
社會可行性是在特定環境下對項目的開發與實施，社會的可行性包括：法律可行性、 社會推廣可行性、使用可行性等。
1.法律可行性：系統開發將不會侵犯任何個人，集體和國家利益，也不會違反國家的 政策與法律。
2.社會推廣可行性：該項目一經測試通過，將在相關部門內進行推廣使用。
3.操作可行性：本系統將做到界面簡潔，功能明了，容易操作。橋梁管理員經過培訓 將能夠使用本系統的移動終端子系統進行移動辦公。有使用微信小程序經驗的普通市民可 以使用該產品的市民監管模塊功能。有計算機基礎的知識完全能夠使用該產品的輔助決策 模塊相關功能。
3.1.5經濟可行性
經濟可行性分析主要是為綜合本文在開發和維護時所需要的代價，以及本系統開發完 成之后能夠帶來的效益之間的關系。系統開發、運維成本以及經濟效益主要包括以下3點：
1.軟硬件購買成本
本系統所使用的技術以及軟件大部分都是開源的，并且基本都有免費的授權，軟件的 購買成本比較低。
本系統需要使用的硬件包括：Web服務器、數據庫服務器、客戶端電腦、安卓手機等。 而新系統的硬件要求跟原有系統的硬件要求基本一致，除了安卓手機，其他完全可以使用 之前的硬件。因此，系統開發完成之后，在原有的服務器上進行軟件部署，將避免硬件資 源的重復購買。所以也不需要太多的硬件購買成本。
2.系統維護成本
降低維護成本的思想將會貫穿整個軟件系統設計的過程。本系統的三個模塊的開發都 是采用MVC設計模式，將頁面表現和功能代碼分開，便于維護。并且軟件項目設計將采 用模塊化的設計原理，實現模塊高內聚，模塊之間低耦合，將能夠很大程度上降低軟件的 復雜度，讓系統便于維護。因此該系統后期維護成本也是比較低的。
3.系統帶來的效益
該系統上線運行之后將能夠實現橋梁管理員的移動辦公，方便梁管理員采集橋梁信 息，提高辦公效率。普通市民能夠通過市民監管模塊，隨時隨地上傳橋梁病害信息，提高 橋梁病害監管力度，確保橋梁安全使用。決策人員能夠通過輔助決策模塊，了解橋梁的巡 檢周期，橋梁預警等信息，并為決策人員提供養護建議，使決策人員能夠更準確，快速的 做出相關決策。因此，本系統帶來的經濟效益相當可觀。所以本系統具備經濟可行性。
3.2系統的綜合要求
通常對系統的綜合要求分為功能性需求、性能需求和環境需求。
3.2.1功能需求
本系統分為三大功能模塊，針對每個模塊介紹模塊應具備的功能。
1.移動終端模塊
移動終端模塊主要面向的用戶是橋梁管理員。由于橋梁信息采集的工作具有移動性的 特點，橋梁管理員需要現場釆集信息，所以對現有電腦端的系統輔之以移動終端模塊，可 以使橋梁管理員采集橋梁信息更方便，提高橋梁信息釆集的效率。并且能夠方便橋梁管理 員及時收到相關通知。移動終端模塊主要包括橋梁管理、橋梁巡檢、養護維修、橋梁技術 狀況評定、任務管理、橋梁預警6個主要功能。
（1） 橋梁管理：能夠實現橋梁信息錄入、信息查詢功能。橋梁信息錄入功能要能夠 實現手機定位和拍照上傳圖片。信息查詢功能要能夠利用經緯度數據將橋梁的具體位置在 地圖上顯示出來。
（2） 橋梁巡檢：橋梁管理員能夠隨時使用該功能對橋梁進行巡檢并將巡檢結果錄入 數據庫，要包含經常檢查和定期檢查兩大模塊。
（3） 養護維修：橋梁管理員在執行完維修任務后通過該功能可以立即將維修情況錄 入數據庫，向上級部門匯報。對于來源于市民舉報的橋梁病害的維修結果將通過微信小程 序反饋給市民，市民可進行服務評價。
（4） 橋梁技術狀況評定：橋梁管理員在定期檢查中對橋梁各個部件進行打分，然后 橋梁管理員選擇橋梁部件權重表，就能夠使用該功能對橋梁進行技術狀況評定。該功能基 于定期檢查的部件評分結果，為決策人員提供決策支持。
（5） 任務管理：該功能將上級部門分配的任務展示給橋梁管理員，任務包括巡檢任 務和維修任務兩類。橋梁管理員能夠通過該功能查看自己的任務并執行。
（6） 橋梁預警：本系統的預警功能主要是針對橋梁經常檢查和定期檢查的周期。對 臨近巡檢周期和超出巡檢周期的橋梁該系統將通過推送的方式提醒橋梁負責人。
2.市民監管模塊
市民監管模塊以微信小程序的形式實現，主要面向的是普通市民。雖然設置有經常檢 查、定期巡檢、特殊檢查等多種巡檢方式來確保橋梁的安全運營，但是在巡檢周期上仍然 存在漏洞。可能在兩次巡檢間隔期間出現突發事件，致使橋梁存在安全隱患。讓普通市民 加入橋梁監管能夠更進一步的確保橋梁的安全使用。而市民監管模塊就是用來實現讓普通 市民加入橋梁監管的功能模塊。主要包括病害舉報，服務評價兩大主要功能。
（1） 病害舉報：普通市民發現橋梁病害之后能夠通過微信小程序客戶端提交病害圖 片和病害描述到服務器端供市政部門查閱從而做出維修養護決策。
（2） 服務評價：橋梁維修工作完成之后，市民會收到維修結果反饋，并且能夠參照 實際維修結果，對維修質量和維修人員做出評價。評價結果將作為橋梁管理員的績效考核 的參考資料。
3.輔助決策模塊
（1） 制定部件權重：決策人員能夠向系統錄入各類型橋梁的部件權重，權重來源可 以是國家現行橋梁評定規范，也可以是地方自行擬定的橋梁部件權重。可以同時錄入多套 權重以供選擇。
（2） 養護維修方案決策：決策人員通過提供橋梁類型，病害的部位，種類等信息的 條件下，系統能夠在知識庫中查找相應的養護維修方案，為決策人員制定養護維修方案提 供參考。另外專家也能夠將新的養護維修方法錄入系統，以供查閱參考。
（3） 資源分配方案決策：對于待養護維修橋梁可以通過資源分配方案決策功能給出 決策建議。在資源充分利用的情況下優先養護最重要的，最危險的，養護維修效益最高的， 從而合理配置資源，達到較好的養護維修效益。
（4） 制定任務：決策人員可以制定橋梁的巡檢和維修任務，下達給橋梁管理員執行。
3.2.2性能需求
性能需求主要包括用戶界面需求、安全性需求。
1.用戶界面需求
（1）系統響應時間：系統響應時間有長度和易變性這兩個重要屬性。系統響應時間 過長會給用戶帶來焦慮感，系統響應時間過短會讓用戶操作節奏失控，容易產生誤操作。 系統響應時間易變性高會讓用戶對系統的工作狀態正常與否產生懷疑。將系統響應時間控 制在O.ls?2.5s變化為宜。
(2)用戶幫助設施：大部分交互式系統都應當給用戶提供幫助。系統完成基礎功能 之后需要給系統增添幫助設施，用戶和系統交互遇到問題時，可以通過幫助設施來查看幫 助信息。
(3)出錯信息處理：對于系統中的交互出現錯誤給出有用的錯誤信息。錯誤信息的 描述應當使用容易理解的術語，為用戶提供對從錯誤中恢復有幫助的意見，提示用戶錯誤 可能帶來的負面影響，要有視覺上的提示，不能指責用戶。
2.安全性需求
(1)用戶安全：系統通過識別用戶輸入的用戶名和密碼判斷是否是合法用戶。用戶 向服務器提交密碼采用MD5加密算法，確保即使密碼在傳輸過程中丟失也不影響安全性。
(2)權限控制：系統中包含四類用戶，分別是系統管理員、決策人員、橋梁管理員、 普通市民。系統給不同權限的用戶提供不同的信息，同時確保不同權限的用戶對數據的合 法操作，確保數據的安全。
(3)數據安全：指定數據庫的詳細備份制度和方案，定期將相關數據導出備份，確 保數據的安全。對部署在應用服務器上的應用程序制定定期備份制度，確保應用程序出現 故障時能夠及時恢復。
3.可靠性需求
系統開發過程中，需要考慮程序設計和匯總過程中可能出現的錯誤數量并將其控制在 比較低的水平，防止錯誤伴隨著程序設計的進度增加。確保20人可以同時在客戶端登錄， 系統正常運行，正確提示相關內容。考慮到突發事件對系統的影響，確保系統能夠穩定運 行，以達到最大平均無故障時間。
3.2.3環境需求
1.客戶端：普通PC
CPU： P4 1.8GHZ
內存：512M以上
顯示器：推薦使用1024*768像素
2.Web服務器
CPU： CONRORE2 (酷睿 2 雙核)，2.66G (臺式機)
內存：2G DDR2及以上
HD： 160G SATA HD+
3.數據庫服務器
CPU： C0NR0RE2 （酷睿 2 雙核），2.66G （臺式機）
內存：2G DDR2及以上
HD： 160G SATAHD+
4.移動端
CPU： 1.5GHz處理器及以上
RAM： 1G及以上
ROM： 8G及以上
網絡：支持3G/4G網絡以及GPS定位功能
屏幕：分辨率1280*720及以上
攝像頭：后置攝像頭800W像素及以上
系統版本：推薦Android4.2及以上
3.3系統的邏輯模型
經過以上兩個步驟的分析可設計出系統詳細的邏輯模型。本文用實體聯系圖、數據流 圖來描述系統的邏輯模型。
3.3.1數據庫的概念設計
數據庫的概念設計是把需求分析階段得到的用戶需求抽象成信息結構的過程，是依照 用戶觀點對數據建模，與軟件在系統中的實現無關。數據模型中包含3種互相關聯的信息: 數據對象、數據對象的屬性以及數據對象彼此間的聯系。
通過對本系統的需求分析，圍繞本系統中的幾個主要子系統，用ER圖來描繪本系統 的數據模型。
1.權限管理
權限管理功能涉及到的實體有：系統管理員、用戶、單位、角色、權限。其中系統管 理員負責給用戶指定角色以及給角色分配權限。一個用戶只能對應一個角色，一個角色可 以對應多個用戶。一個角色就可以擁有多種權限，一種權限也可以被多個用戶所共有。權 限管理的ER圖如圖3-4所示：
圖3-4權限管理ER圖
2.橋梁管理
橋梁管理功能主要涉及了 3個實體：橋梁、決策人員、橋梁管理員。橋梁管理員負責 管理橋梁，決策人員負責對橋梁管理進行審核。一個橋梁管理員可以管理多座橋梁，一個 橋梁只能由一個橋梁管理員管理。一個決策人員可以審核多個橋梁的信息管理，一個橋梁 的信息管理審核只能由一個決策人員負責。橋梁管理的ER圖如圖3-5所示：
1
圖3-5橋梁管理ER圖
3.橋梁巡檢
橋梁巡檢功能涉及了 5個實體：決策人員、橋梁管理員、橋梁、巡檢任務、巡檢結果。 決策人員負責分派巡檢任務、審核巡檢結果、橋梁管理員負責執行巡檢任務。一座橋梁只
對應一條當前有效的巡檢任務，一個巡檢任務對應一條巡檢結果。一個巡檢任務只能被一 個橋梁管理員執行，一個橋梁管理員可以執行多個橋梁巡檢任務。一個決策人員可以生成 多個橋梁巡檢任務，但是一個巡檢任務只能由一個決策人員生成。一個決策人員可以審核 多個巡檢結果，但是一個巡檢結果只能被一個決策人員審核。ER圖如圖3-6所示：
圖3-6橋梁巡檢ER圖
4.橋梁養護維修
橋梁養護維修功能涉及到6個實體：病害舉報、巡檢結果、養護維修計劃、養護維修 任務、決策人員、橋梁管理員。決策人員通過審核病害舉報和巡檢結果，并根據舉報的病 害和巡檢結果來制定養護維修計劃，根據計劃分配維修任務，最后由橋梁管理員執行養護 維修任務。ER圖如圖3-7所示：
5.新聞通告
新聞通告功能涉及了 3個實體：新聞通告、系統管理員、橋梁管理員。系統管理員負 責管理新聞通告，橋梁管理員查閱新聞通告。橋梁管理員和新聞通告是多對多的關系。新 聞通告功能的ER圖如圖3-8所示：
6.市民監管
市民監管功能涉及到5個實體：決策人員、橋梁管理員、市民、
任務。一個市民可以提交多個病害舉報，但是一個病害舉報只能由一個市民提交。一個決 策人員可以審核多個病害舉報，一個病害舉報只能由一個決策人員審核。一個決策人員可 以為多個病害舉報分配養護維修任務，但是一個病害舉報的養護維修任務只能由一個決策 人員分配。ER圖如圖3-9所示：
3.3.2系統邏輯模型設計
本文用數據流圖(data flow diagram, DFD)來表示系統的邏輯模型。數據流圖的作用 是將系統的邏輯功能、數據在系統內的邏輯流向和邏輯變化過程用圖形的方式表示出來。 本文圍繞系統的幾個主要功能來描繪系統的邏輯模型。
1.權限管理
權限管理功能，由橋梁管理員錄入角色和權限對應信息以及用戶和角色對應信息，最
2.橋梁管理
橋梁管理功能，由橋梁管理員更新橋梁信息，系統管理員負責審核橋梁信息，最后用 戶可以查看橋梁信息。系統管理員審核之后，橋梁管理員能夠查看審核結果，根據審核結
果，橋梁管理員重新提交更新或者撤銷更新。數據流圖如圖3-11所示:
圖3-11橋梁管理數據流圖
3.橋梁巡檢
橋梁巡檢分為經常檢查和定期檢查，兩種巡檢的高層邏輯模型一致，詳細設計將在論 文第五章闡述。橋梁管理員和決策人員收到橋梁巡檢周期提醒之后都能夠制定該橋梁的巡 檢任務。橋梁管理員負責執行巡檢任務，提交巡檢結果，決策人員負責審核巡檢結果，并 將審核結果反饋給橋梁管理員，數據流圖如圖3-12所示：
橋梁信息
巡檢周期
圖3-12橋梁巡檢數據流圖
4.橋梁養護維修
橋梁養護維修功能，需要養護維修的橋梁來源于橋梁巡檢和市民舉報橋梁病害。決策 人員審核通過后制定養護維修計劃，然后制定養護維修任務，由橋梁管理員負責執行，最 后提交養護維修結果，并反饋給決策人員查看確認。數據流圖如圖3-13所示：
巡檢結果
巡檢結果
圖3-13橋梁養護維修數據流圖
5.新聞通告
新聞通告功能，系統管理員收到發布要求之后，負責將新聞通告發布到系統中，用戶
可以通過系統進行查閱。數據流圖如圖3-14所示：
圖3-14新聞通告數據流圖
6.市民監管
市民監管功能，市民可以上傳橋梁病害信息，評價維修結果。決策人員負責根據制定 維修任務。橋梁管理員負責執行維修任務，提交維修結果。數據流圖如圖3-15所示：
圖3-15市民監管數據流圖
3.4本章小結
在本章中，對系統進行了可行性分析和需求分析。結合對吳江橋梁信息管理系統的分 析，從技術、社會、經濟三方面論述了新系統的開發是可行的。在可行的基礎上，從功能、 性能和環境三方面對新系統進行需求分析，基本描繪出了新系統的高層邏輯模型。接下來 將在系統邏輯模型的基礎上，對系統進行概要設計。
第4章 系統概要設計
系統概要設計主要是把需求分析階段得到的邏輯模型轉化為軟件結構和數據結構。本 章首先介紹了系統硬件體系結構設計、軟件體系結構設計、系統架構設計。然后根據需求 分析階段得到的邏輯模型對系統功能進行細化，在數據庫概念設計基礎上完成數據庫邏輯 設計。
4.1硬件體系結構
本系統主要采用瀏覽器/服務器模式（B/S模式）。B/S模式可以跨平臺訪問各種資源, 根據HTTP和Web瀏覽器可以訪問多個服務器，獲取服務器和數據庫上的信息。當系統開 始運維或者是再次開發時，修改服務器端的程序即可。B/S模式解決了跨平臺性能差的問 題，同時B/S模式不需要像C/S模式那樣需要安裝客戶端，方便快捷。而且B/S模式能夠 提供圖像、音頻、視頻等服務，顯著增強了界面的視覺效果，給用戶帶來了友好的用戶體 驗。
本系統部署在住建局信息中心的服務器上，住建局工作人員在IE瀏覽器中輸入系統網 址即可訪問本系統。此外為了減輕服務器的壓力，我們把數據庫和服務端程序分開部署在 不同的服務器上。同時為了防止系統遭到惡意破壞，在內網和外網分別部署了防火墻以確 保系統的安全。
此外本系統在原有系統的基礎上增加了基于Android平臺的功能模塊。該功能模塊采 用的是客戶/服務器模式（C/S模式）。客戶端為每個用戶所專有，而服務器端被所有用戶 共享。用戶可以使用安卓智能機上的客戶端接入并使用本系統。系統的硬件體系結構如圖 4-1所示：
圖4-1硬件體系結構
4.2軟件體系結構
本系統開發采用三層架構的體系結構，明確分離表示層、業務邏輯層和數據訪問層。 三層架構的使用降低了層與層之間的耦合，能夠確保應用服務邏輯的一致性和穩定性、結 構的開放性、功能的可擴展性和可維護性，使結構更加明確。開發人員能夠將注意力集中 在具體的某一層。本系統還采用了其他一些開源框架來確保系統開發的經濟性。
三層架構的各功能層如下：
（1） 數據訪問層：主要是對非原始數據（數據庫或者文本文件等存放數據的形式） 的操作層，主要是對數據的增添、刪除、修改、查詢。
（2） 業務邏輯層：主要是對數據層的操作，封裝了對數據的業務處理邏輯。
（3） 表示層：是用戶看到的可視化界面，為用戶提供系統的訪問接口，主要負責接 收用戶請求，將返回數據展示給用戶。
系統的軟件體系結構圖如圖4-2所示：
數據庫
圖4-2軟件體系結構圖
4.3系統架構設計
根據系統需求分析以及系統軟件體系結構得出的系統架構分為四個層次：基礎平臺
層、數據資源層、業務支撐層、應用系統層。系統架構如圖4-3所示：
圖4-3系統架構圖
4.4系統功能結構設計
根據需求分析階段的系統模型，將系統功能結構進一步細化。分別介紹移動終端模塊, 市民監管模塊和輔助決策模塊的功能結構。
1.移動終端模塊主要用戶為橋梁管理員，主要功能有橋梁管理、橋梁巡檢、養護維修、 任務管理、橋梁預警、新聞通告等子功能，功能結構如圖4-4所示：
2.輔助決策模塊主要用戶為決策人員，主要有資源配置方案決策、養護維修方案決策、 審核橋梁錄入、審核橋梁養護維修、審核橋梁巡檢等子功能，功能結構如圖4-5所示：
圖4-5輔助決策模塊圖
3.市民監管模塊主要用戶為普通市民，主要有病害舉報、服務評價和查看橋梁3個子 功能，功能結構如圖4-6所示：
圖4-6市民監管模塊圖
4.5數據庫邏輯設計
在需求分析階段完成了數據庫的概念設計，概要設計階段需要將數據庫的概念設計轉 化成被Oracle數據庫支持的數據庫模型，即數據庫的邏輯結構。包括選擇數據庫產品；落 實數據庫的實體和實體屬性；設置字段；選擇數據類型；推敲長度；測算精度；以及調節 頁面大小等。數據庫邏輯設計是整個數據庫設計的重要任務，包含了實體與關系、實體標 準化等。下面列出部分數據庫表的設計，在表中列出部分關鍵字段。
數據庫命名采用系統名字首字母開頭，別名用和實體有相同意義的英文單詞表示，并 約定表名中出現的英文單詞皆為單數形式。
1.用戶信息表（QL_User）用于記錄用戶基礎信息。表中包括用戶編號、用戶名等。 其中用戶編號為主鍵，單位編號為外鍵。用戶信息表（QL_User）如表4-1所示：
表4-1用戶信息表（QL User）
屬性 數據類型 標識 主鍵 外鍵 備注
Userid NUMBER©,0) 是 是 用戶編號
UseiName VARCHAR2(50 BYTE) 用戶名
Password VARCHAR2(50 BYTE) 用戶密碼
Name VARCHAR2(50 BYTE) 姓名
Age NUMBER(3,0) 年齡
Gender NUMBER(l,0) 性別
Address VARCHAR2(100 BYTE) 地址
Phone VARCHAR2(50 BYTE) 電話
Mobile VARCHAR2(50 BYTE) 手機
(續表4-1)
屬性 數據類型 標識 主鍵 外鍵 備注
Email VARCHAR2(50 BYTE) 電子郵箱
QQ VARCHAR2(50 BYTE) qq
Unitld NUMBER©,0) 是 單位編號
Roleld NUMBER(l,0) 是 角色編號
2.單位信息表（QL_Unit）用于記錄用戶所在單位的相關信息。表中包括單位編號、 單位名稱、單位地址、聯系人、聯系電話等。其中單位編號為主鍵。單位信息表如表
（QL_Unit） 4-2 所示：
表4-2單位信息表（QL Unit）
屬性 數據類型 標識 主鍵 外鍵 備注
Unitld NUMBER(5,0) 是 是 單位編號
Name VARCHAR2(100 BYTE) 單位名稱
Adress VARCHAR2(100 BYTE) 單位地址
Contact NUMBER(5,0) 是’ 聯系人
Phone VARCHAR2(50 BYTE) 聯系電話
3.角色信息表（QL_Role）用于記錄系統中擁有的角色類型。表中包括角色編號、角 色名稱、創建日期。其中角色編號為主鍵。角色信息表（QL_Role）如表4-3所示： 表4-3角色信息表（QL Role）
屬性 數據類型 標識 主鍵 外鍵 備注
Roleld NUMBER©,0) 是 是 角色編號
RoleName VARCHAR2(30 BYTE) 角色名稱
DateTime DATE 創建日期
4.系統功能表（QL_Func）用于記錄系統中的一些功能。表中包括功能編號、功能名 稱、父級功能編號、功能路徑。其中功能編號為主鍵，父級功能編號為外鍵。系統功能表 （QL Func）如表4-4所示：
表4-4系統功能表（QL Func）
屬性 數據類型 標識 主鍵 外鍵 備注
Funcld NUMBER(5,0) 是 是 功能編號
FuncName VARCHAR2(30 BYTE) 功能名稱
SuperFuncId NUMBER(5,0) 是 父級功能編號
FuncUrl VARCHAR2(50 BYTE) 功能路徑
5.角色功能表(QL_RoleFunc)用于記錄系統中角色和功能的對應信息。表中包括記 錄編號、角色編號、功能編號。其中記錄編號為主鍵，角色編號和功能編號為外鍵。角色 功能表(QL_RoleFunc)如表4-5所示：
表4-5 角色功能表(QL RoleFunc)
屬性 數據類型 標識 主鍵 外鍵 備注
Id NUMBER©,0) 是 是 記錄編號
Roleld NUMBER(5,0) 是 角色編號
Funcld NUMBER©,0) 是 功能編號
6.橋梁信息表(QL_Bridge)用于記錄橋梁的基本信息。表中包括橋梁編號、橋梁名 稱、地址、街道、養護人員等屬性。其中橋梁編號為主鍵，養護單位和養護人員為外鍵。 橋梁信息表(QL_Bridge)如表4-6所示：
表4-6橋梁信息表(QL Bridge)
屬性 數據類型 標識 主鍵 外鍵 備注
Bridgeld NUMBER(5,0) 是 是 橋梁編號
Name VARCHAR2(50 BYTE) 名稱
Introduce VARCHAR2(2000 BYTE) 簡介
Adderss VARCHAR2(100 BYTE) 地址
Road VARCHAR2(100 BYTE) 街道
Longitude NUMBER(10,6) 經度
Latitude NUMBER(1096) 緯度
BuildTime DATE 建造時間
BuildUnit VARCHAR2(100 BYTE) 建造單位
Maintain_Unit NUMBER(5,0) 是 養護單位
Maintain_Staff NUMBER(5,0) 是 養護人員
Bridge_Lentgth NUMBER(5,2) 橋長
Bridge_Width NUMBER(5,2) 橋寬
Roadway_Width NUMBER(5,2) 車行道寬
Sideway_Width NUMBER®,2) 人行道寬
Abutment^_Sort VARCHAR2(20 BYTE) 橋臺類型
Deck_Sort VARCHAR2(20 BYTE) 鋪裝類型
LoadGrade VARCHAR2(20 BYTE) 荷載等級
Maintain Grade VARCHAR2(2 BYTE) 養護等級
(續表4-6)
屬性 數據類型 標識 主鍵外鍵 備注
Evaluate_Grade VARCHAR2(2 BYTE) 評定等級
Evaluatelndex NUMBER(5,2) 評定指數
Diseaselntroduce VARCHAR2(2000 BYTE) 病害說明
Miantainlntroduce VARCHAR2(2000 BYTE) 養護說明
Imagel_Path VARCHAR2(200 BYTE) 病害圖片1
Image2_Path VARCHAR2(200 BYTE) 病害圖片2
Image3_Path VARCHAR2(200 BYTE) 正面圖片
Image4_Path VARCHAR2(200 BYTE) 側面圖片
Inspect_Cycle NUMBER(5,0) 巡檢周期
Last Inspect DATE 上次巡檢日期
7.新聞通告表(QL_News)用于記錄新聞通告的相關信息。表中包括新聞通告編號、 新聞通告標題、新聞通告內容、發布者、發布時間。其中新聞通告編號為主鍵，發布者為 外鍵。新聞通告表(QL_News)如表4-7所示：
表4-7新聞通告表(QL News)
屬性 數據類型 標識 主鍵 外鍵 備注
Newsld NUMBER(5,0) 是 是 新聞通告編號
Title VARCHAR2(200 BYTE) 新聞通告標題
Content VARCHAR2(200 BYTE) 新聞通告內容
Sender NUMBER(5,0) 是 發布者
Date DATE 發布日期
&巡檢結果表(QL_Inspect)用于記錄橋梁的巡檢結果。表中包括巡檢編號、橋梁編 號、巡檢日期、巡檢人員等屬性。其中巡檢編號為主鍵，橋梁編號和巡檢人員為外鍵。橋 梁巡檢釆用填寫橋梁各部件缺損狀況來進行，狀況完好則不填寫，默認為空，有缺損則填 寫缺損描述信息。巡檢結果表(QL_Inspect)如表4-8所示：
表4-8巡檢結果表(QL Inspect)
屬性 數據類型 標識 主鍵 外鍵 備注
Inspectld NUMBER(5,0) 是 是 巡檢編號
Bridgeld NUMBER(5,0) 是 橋梁編號
Date DATE 巡檢日期
InspectStaff NUMBER(5,0) 是 巡檢人員
(續表4-8)
屬性 數據類型 標識 主鍵 外鍵 備注
WingWall VARCHAR2(2000 BYTE) 翼墻
ProtectSlope VARCHAR2(2000 BYTE) 護坡
Abutment VARCHAR2(2000 BYTE) 橋臺
Pier VARCHAR2(2000 BYTE) 橋墩
Foundation VARCHAR2(2000 BYTE) 地基沖刷
Support VARCHAR2(2000 BYTE) 支座
TopChange VARCHAR2(2000 BYTE) 上部結構異常變形
BRConnection VARCHAR2(2000 BYTE) 橋路連接
Expansionjoint VARCHAR2(2000 BYTE) 伸縮縫
Sideway VARCHAR2(2000 BYTE) 人行道
Guardrail VARCHAR2(2000 BYTE) 護欄
Sign VARCHAR2(2000 BYTE) 標志
Drainage VARCHAR2(2000 BYTE) 排水設施
lighting VARCHAR2(2000 BYTE) 照明系統
Cleaning VARCHAR2(2000 BYTE) 橋面清潔
Structure VARCHAR2(2000BYTE) 調治構造物
Other VARCHAR2(2000 BYTE) 其他
IsRepair NUMBERS,0) 是否建議維修
9.病害舉報表(QL_Report)用于記錄普通市民舉報病害的記錄。表中包括病害舉報 編號、市民電話、病害描述、橋梁編號等。其中病害舉報編號為主鍵，橋梁編號為外鍵。 病害舉報表(QL_Report)如表4-9所示：
表4-9病害舉報表(QL Report)
屬性 數據類型 標識 主鍵 外鍵 備注
Reportld NUMBER(5,0) 是 是 病害舉報編號
Date DATE 舉報時間
Phone VARCHAR2(50 BYTE) 市民電話
Introduce VARCHAR2(2000 BYTE) 病害描述
Bridgeld NUMBER©,0) 是 橋梁編號
State NUMBER(l,0) 審核狀態
10.維修任務表(QL_RepairTask)用于記錄由決策人員審核市民病害舉報清單和橋梁
管理員巡檢結果清單之后生成的維修任務。表中包括任務編號、維修人員、橋梁編號、維 修措施、維修結果、維修時間、舉報人員等。其中任務編號為主鍵，橋梁編號、維修人員、 舉報人員為外鍵。維修任務表(QL_RepairTask)如表4-10所示：
表4-10維修任務表(QL RepairTask)
屬性 數據類型 標識 主鍵 外鍵 備注
Taskld NUMBER(5?0) 是 是 任務編號
Bridgeld NUMBER(5,0) 是 橋梁編號
Part VARCHAR2(2000 BYTE) 病害位置
Course VARCHAR2(2000 BYTE) 病害原因
RepairSatff NUMBER(5,0) 是 維修人員
ReportStaff NUMBER(5,0) 是 舉報人員
Step VARCHAR2(2000 BYTE) 維修措施
Result VARCHAR2(2000 BYTE) 維修結果
Date DATE 維修時間
Evaluate VARCHAR2(2000 BYTE) 任務評價
Score NUMBER(5,0) 任務打分
Audit_State NUMBER(l,0) 審核狀態
Perform_State NUMBER(l,0) 執行狀態
11.巡檢任務表(QL_InspectTask)用于記錄由決策人員制定的橋梁巡檢任務。表中包 括任務編號、橋梁編號、巡檢人員、巡檢時間、審核狀態、執行狀態。其中任務編號為主 鍵，橋梁編號，巡檢人員為外鍵。巡檢任務表(QL_InspectTask)如表4-11所示：
表 4-11 巡檢任務表(QL InspectTask)
屬性 數據類型 標識 主鍵 外鍵 備注
Taskld NUMBER(5,0) 是 是 任務編號
Bridgeld NUMBER(5,0) 是 橋梁編號
InspectSatff NUMBER(5,0) 是 巡檢人員
Date DATE 巡檢時間
Audit_State NUMBER(l,0) 審核狀態
Perfdrm_State NUMBER(l,0) 執行狀態
4.6本章小結
本章中，簡要介紹了系統的硬件體系結構、軟件體系結構以及系統架構的設計，并在 數據流圖的基礎上進一步細化，得到了系統功能結構設計，在數據庫概念設計的基礎上得 到了數據庫的邏輯設計。后面將在概要設計的基礎上將功能模塊進行細化，詳細介紹功能 的實現原理和相關算法。
第5章系統詳細設計
本文的詳細設計圍繞主要的功能模塊，闡述各個功能模塊的具體業務流程，實現細節 以及設計要點。
5.1移動終端模塊
5.1.1數據傳輸
1.文本數據傳輸
安卓系統是不能直接訪問數據庫的，要建立安卓端和數據庫的連接需要通過服務器端 程序來間接訪問。本系統采用WebService技術實現安卓端和數據庫的交互。而WebService 只能傳輸可以序列化的參數，所以需要借助Json【“］類將數據進行封裝并轉化為Json字符 串，再進行傳輸。提交數據和加載數據過程類似，本文給出提交數據的具體過程：
(1)安卓端發出提交數據請求；
(2)將數據封裝到Json對象中；
(3)將Json對象轉換成Json字符串；
(4)將Json字符串提交到服務器端WebService；
(5)服務器端WebService接收到請求和Json字符串；
(6)WebServcie中將Json字符串轉換成Json對象；
(7)解析Json對象，獲取屬性名和屬性值；
(8)將解析出的數據保存在數據庫中。
2.帶圖片的數據傳輸
帶圖片的數據傳輸通常要將圖片數據和文本數據分開傳輸。文本數據傳輸和之前的方 法相同。下面給出三種帶圖片數據的傳輸方法，做出比較后選擇性能較優的方法。
(1)采用 WebService 傳輸
因為WebService只接受字符串類型的參數，所以要想傳輸圖片，必須將圖片轉換成字 符串的格式，然后通過WebService傳輸。可以先將圖片文件轉化為字節數組字符串，然后 通過Base64編碼處理，轉換為字符串。
缺點：手機性能和電腦相比差距較大，對圖片編碼速度很慢，不適合手機端向服務器 傳輸圖片。
(2)采用Socket傳輸
用Socket傳輸圖片，客戶端只需要將圖片讀入到FilelnputStream中，然后封裝到 DataoutputStream中提交給服務器。在服務器端新建Socket,并設置成阻塞狀態，一旦服 務器端有提交圖片請求，就會從阻塞狀態變為非阻塞狀態，執行后續代碼，獲取圖片。
缺點：因為創建Socket需要為Socket綁定單獨的端口，而系統其它數據傳輸都使用的 是WebService, WebService依賴于Tomcat的8080端口。這樣就需要使用兩個端口，造成 額外的端口開銷。
（3）采用AsyncTask異步任務處理框架
AsyncTask⑸】異步任務處理框架封裝了文件傳輸的邏輯，只要根據文件路徑創建File 對象，然后通過調用框架的相關API即可實現傳輸圖片。將圖片路徑和圖片的文件名對應 存放在兩個列表中提交給框架的API即可實現圖片批量傳輸。
相比較前兩種方法，使用AsyncTask異步任務處理框架傳輸圖片對移動端性能沒有過 高的要求，也不需要額外的端口開銷，使用也比較簡單，容易理解。為了增強系統可維護 性，本系統采用這種方法傳輸圖片。
3.保存帶圖片的數據.
一條完整的橋梁記錄由文本數據和圖片數據兩部分組成，保存時也保存在兩個位置， 將圖片路徑和其他文本數據保存在數據庫中，將圖片數據保存在服務器指定目錄中。本文 給出了保存帶圖片的橋梁數據的方案。
因為原系統已有的數據中的圖片有既定的存放目錄，且目錄有一定的規律性，為了保 持新錄入數據和原有數據的一致性，在服務器端需要根據橋梁的所屬分類查找此類橋梁的 文件目錄，然后按照文件目錄規則，動態生成圖片的保存路徑。本文給出兩種保存方案， 然后擇優采用。
方案1：
（1） 客戶端提交橋梁記錄的文本數據。
（2） 服務器端接受橋梁記錄的文本數據。
（3） 根據橋梁記錄的屬性查找圖片應保存的文件目錄，并動態生成即將保存的圖片 的路徑。
（4） 將圖片路徑和其他文本數據一起保存到服務器端。
（5） 返回圖片路徑到客戶端。
（6） 客戶端提交圖片以及圖片路徑到服務器端，并根據保存路徑保存圖片。
方案1保存數據流程圖如圖5-1所示：
圖5-1方案1流程圖
方案2：
(1)客戶端提交圖片和橋梁部分屬性到服務羈端。
(2)服務器端接收圖片，根據橋梁部分屬性查找該類橋梁圖片的保存路徑，動態生 成圖片保存路徑，并保存圖片。
(3)返回圖片路徑到客戶端。
(4)客戶端接收圖片保存路徑，并將保存路徑和橋梁其他文本數據一起提交給服務 器端。
(5)服務器端接收橋梁的文本數據，并保存到數據庫。
方案2保存數據流程圖如圖5-2所示：
圖5-2方案2流程圖
比較上述兩種方案發現，方案1存在隱患。如果是先保存圖片路徑，然后再提交圖片 進行保存，在上傳圖片期間可能會有其他用戶提交數據，如果之前圖片還未上傳完成，查 找圖片保存路徑的時候，就會生成和之前要保存的圖片相同的路徑，從而產生沖突。而方 案2先保存圖片的方式不存在這樣的沖突。所以本系統采用的是第2種方案來保存帶圖片 的數據。
5.1.2地圖定位
(1)坐標系選取
目前主流的地圖坐標系有3種，分別是大地坐標系統(WGS-84) QI,火星坐標系統 (GCj-02),百度坐標系統(BD-09)。谷歌地圖和高德地圖使用的坐標系是火星坐標系 統，可以互通。而百度地圖使用的是百度坐標系統。
原系統定位功能使用的是谷歌地圖提供的API,谷歌地圖API從2012年開始收費，因 為條件限制不能使用。所以使用高德地圖API來進行安卓端定位功能的開發與設計。
(2)定位功能
定位功能包括兩個部分：一個是從數據庫讀取經緯度信息將橋梁的坐標點顯示在地圖 上；另一個是定位當前位置信息，存儲到數據庫中。
將已知經緯度的橋梁坐標點顯示在地圖上，調用MapView接口顯示地圖，然后通過 創建MarkerOption對象并向該對象傳遞經緯度參數，就能將目標點標記在地圖上。
定位當前位置將經緯度存儲到數據庫中有兩種方案：
方案1：完全依賴手機定位，獲取經緯度信息后直接存儲，不做檢驗。這個調用高德 地圖的定位回調監聽器AMapLocationListener監聽當前位置的經緯度信息，然后再將定位 回調監聽器設置給AmapLocationClient對象即可實時獲取當前位置信息。
方案2：手機定位的經緯度信息不夠精準，需要打開地圖人工校對，手動拖拽坐標點 調整。首先需要調用MapView接口顯示地圖，然后獲取當前位置經緯度，并顯示在地圖 上。然后通OnMarkerDragListener監聽器監聽用戶拖拽動作，覆寫拖拽方法，設置拖拽結 束后獲取最新位置點的經緯度信息。
實際應用中，以上兩種方法配合使用，首先調用的是方案1,當手機定位滿足用戶需 求時，直接傳回經緯度信息。如果精度不能滿足用戶需求，啟用方案2,用戶手動微調到 滿意為止，然后傳回經緯度信息。
5.2橋梁巡檢
5.2.1橋梁巡檢介紹
橋梁巡檢按照巡檢頻率和巡檢規模的不同可以將其劃分為經常檢查、定期檢查和特殊 檢查。
1.經常檢查
經常檢查的周期通過分析橋梁技術狀況來確定，通常1個月至少檢查1次，汛期需要 適當增加檢查次數。經常檢查需要現場完成“橋梁經常檢查記錄表”，還要當場確定檢查 橋梁的缺損類型，估算橋梁缺損范圍和養護維修工作量，可以提出養護維修建議，為橋梁 養護維修(小修保養)計劃提供參考。發現橋梁重要部件缺損時應立即向決策部門報告。
2.定期檢查
定期檢查也是通過橋梁技術狀況等級來確定周期，3年至少執行1次。新建橋梁正式 運營1年后，進行1次全面檢查。臨時橋梁1年至少檢查1次。橋梁重要部(構)件缺損 明顯達到三、四、五類技術狀況時，需要立即執行1次定期檢查。
定期檢查主要工作如下：
(1)當場核對橋梁基本數據。
(2)現場完成“橋梁定期檢查表”填寫，對橋梁各部件技術狀況打分并記錄缺損狀況。
(3)判斷缺損原因，估算維修范圍，提出維修建議。
(4)對難以判斷缺損原因和程度的情況，建議執行特殊檢查。
(5)對損壞嚴重，不能安全運營的橋梁，建議交通管制和改建。
(6)根據檢查結果，確定下次檢查日期。
特殊檢查應委托有相應資質和能力的單位承擔，本文不做細述。
5.2.2橋梁巡檢流程設計
1.經常檢查流程設計
橋梁達到經常檢查的巡檢周期之后，負責相應橋梁的橋梁管理員和決策人員會收到巡 檢提醒。負責相應橋梁的橋梁管理員可以執行巡檢任務，并在需要巡檢的橋梁上添加經常 檢查。橋梁管理員對需要填寫經常檢查記錄表，說明缺損部件的缺損類型、缺損范圍和養 護維修工作量，并提出養護維修建議。經常檢查業務流程如圖5-3所示：
圖5-3經常檢查業務流程圖
2.定期檢查流程設計
橋梁到達定期檢查的巡檢周期之后，負責相應橋梁的橋梁管理員和決策人員會收到巡 檢提醒。橋梁管理員可通過系統對橋梁添加定期檢查。首先橋梁管理員需要現場核對橋梁 靜態數據，填寫橋梁定期檢查記錄表，并對部件打分。如果有部件缺損，說明缺損原因，
維修范圍并提出養護維修建議。不能說明缺損原因的，存在重要部(構)件的缺損明顯達 到三、四、五類技術狀況或者橋梁整體技術狀況為四、五類的需要提出特殊巡檢的申請。
定期檢查業務流程圖如圖5-4所示：
圖5-4定期檢查業務流程圖
5.3橋梁技術狀況評定
5.3.1橋梁技術狀況評定介紹
橋梁評定包括一般評定和適應性評定。一般評定是根據橋梁定期檢查資料，對橋梁各 部件技術狀況進行綜合評定，確定橋梁的技術狀況等級，提出養護維修建議。本系統只進 行一般評定的設計。
5.3.2《公路橋涵養護規范》(JTGH11-2004)的評定方法
1.橋梁技術狀況評定流程
(1)確定橋梁部件的權重，將橋梁劃分為具有固定權重值的部件。
(2)現場檢測橋梁部件的缺損程度、缺損對結構使用功能的影響以及缺損發展變化 狀況等三個方面，按照評定標度給橋梁部件打分。
（3） 通過累加每個部件的得分得出橋梁的整體標度。
（4） 將各個部件的缺損狀況評定標度和固定權值代入公式計算全橋結構技術狀況評 定得分。
（5） 根據橋梁技術狀況評定得分，將橋梁技術狀況評定按等級分為一類，二類，三 類，四類，五類。
2.橋梁技術狀況評定方法如下
（1）根據缺損程度（大小，多少或輕重）、缺損對結構使用功能的影響（無，小， 大）和缺損發展變化狀況（趨向穩定，發展緩慢，發展較快）三個方面，通過累加評分確 定橋梁技術狀況。評定方法見表5-1所示：
表5-1橋梁部件缺損狀況評定方法
缺損狀況及標度 組合評定標度
缺損程度及標度 程度 小大
少一*多 輕度T嚴重
標度 0 1 2
缺損對結構使用功能的影響程度 無，不重要 0 0 1 2
小，次要 +1 1 2 . 3
大，重要 +2 2 3 4
以上兩項評定組合標度 0 1 2 3 4
缺損發展變化狀況的修正 趨向穩定 -1 0 1 2 3
發展緩慢 0 1 2 3 4
發展較快 +1 1 2 3 4 5
最終評定結果 0 1 2 3 4 5
橋梁技術狀況及分類 完好 良好 較好 較差 差的 危險
一類 二類 三類 四類 五類
注：“0”表示狀態完好，或者該部件不存在。當缺損標度為“0”時，不再進行疊加;
“5”表示狀態危險，或者表示需要補設的部件。
（2） 重要部件（如墩臺與基礎，上部承重構件，支座）用缺損最嚴重的構件評分作 為部件評分：其他部件，參考多數構件缺損狀況評分。
（3） 各地區可以使用《公路橋涵養護規范》（JTG H21-2004）中推薦的各部件的權 重值，也可以根據當地的環境和養護要求，用專家評估法重新擬定部件權重。
（4） 綜合評定計算式：
少=100- %”/5
）=1
R,：按表6-1方法對各部件確定的評定標度（0-5）；
闿：各部件權重，IX =100；
Dr：全橋結構技術狀況評分（0-100）；評分高表示結構狀況好，缺損少。
（5） 評定分類
Dr >88： 一類；
88>Dr >60：二類；
60 >0.240：三類；
40>Dr:四類，五類。
說明：Dr >60的橋梁，并不排除其中有評定標度& >3的部件，仍然有需要維修的可 能。
5.3.3橋梁技術狀況評定變權評定法
橋梁狀況變權評定法是保證在《公路養護技術規范》中規定構件之間權重比例不變的 情況下，改變構件權重值，使總權重為100。
本文參照《公路橋梁技術狀況評定標準》（JTG/TH21-2011） 4.1.3節中對于未設部件 的權重進行重新分配的原理，對實際橋梁中不存在的部件，根據此部件的隸屬關系，將部 件權重值分配給其他既有部件，分配原則根據各既有部件在全部既有部件權重之和中所占 比例進行分配。計算公式如下：
Wr = W +
W,：橋梁中未設置部件的初始權重。
W廠橋梁中既有部件的初始權重。
W”：橋梁中某一既有部件重新分配后的權重。
叫：橋梁中某一既有部件的初始權重。
5.3.4橋梁技術狀況評定流程設計
1.生成不同類型橋梁部件權重表
本文在《公路橋涵養護規范》的基礎上做出了改進，本系統可以事先針對不同橋梁類 型錄入不同的部件權重。并且在橋梁巡檢表之前，根據橋梁擁有的具體部件種類采用變權 評定法，生成一套實用性更強的部件權重。生成不同類型橋梁部件權重表流程如圖5-5：
圖5-5生成不同類型橋梁部件權重表流程圖
2.生成橋梁技術狀況評定巡檢表
橋梁技術狀況評定是建立在巡檢基礎上的，所以生成一個符合特定橋梁技術狀況評定 巡檢要求的巡檢表至關重要。在橋梁管理員巡檢某座橋梁時候，需要先確定橋梁的類型， 然后系統通過識別橋梁類型，列出該類型橋梁可能具備的所有部件，然后橋梁管理員在這 些部件中選擇該座橋梁實際存在的部件，從而生成適合該座橋梁的巡檢表，并通過變權算 法生成和巡檢表對應的權重表。生成橋梁技術狀況評定巡檢表流程如圖5-6所示：
圖5-6生成橋梁技術狀況評定巡檢表流程圖
3.橋梁技術狀況評定
橋梁技術狀況評定首先參照《公路橋梁技術狀況評定標準》(JTG/TH21-2011)第五 章至第十章關于各橋型病害定性定量描述的條款進行構件評分，填寫技術狀況評定巡檢表 中各個部件的標度。填寫完成后需要選擇是使用《公路橋梁技術狀況評定標準》推薦的權 重，還是使用專家評估法擬定的權重。選擇權重方案之后，通過橋梁技術狀況評定計算模 型計算得出橋梁的技術狀況評定得分。但是在橋梁技術狀況評定得分D” >60的情況下， 可能仍然存在橋梁部件的評定標度；?, >3 »如果存在部件評定標度/?, >3 ,同樣需要將該 座橋梁設定為需要維修的橋梁。橋梁技術狀況評定流程如圖5-7所示：
圖5-7橋梁技術狀評定流程圖
5.4橋梁管理輔助決策
5.4.1管理輔助決策介紹
橋梁信息管理系統中的輔助決策是指制定合理的養護計劃并且將養護資金，養護人員 充分合理的配置，從而保證橋梁處于一個安全運營的狀態的過程。
橋梁管理輔助決策的目的是根據橋梁管養部門提供的橋梁的相關信息，確定橋梁技術 狀況評定等級，需要采取什么樣的養護措施，以及在總預算一定的情況下，如何合理分配 資金，才能確保橋梁安全運營的情況下達到養護維修收益最大。
本系統的橋梁管理輔助決策模塊包含兩大核心功能，養護項目的資源分配方案決策和 養護維修方案決策。資源分配采用線性規劃的方法，養護維修方案決策采用決策樹方法。
5.4.2資源分配方案決策
1.條件說明
對橋梁進行養護維修有兩種途徑，一種是針對病害輕微的橋梁，養護維修比較簡單， 由橋梁管理部門內部人員進行；另一種是針對病害嚴重的橋梁，養護維修比較復雜，橋梁 管理部門難以完成，由橋梁管理部門出資，專業的橋梁養護維修公司進行養護維修。
本系統的資源分配方案決策功能只針對病害輕微的橋梁，對內部人員能夠進行的養護 維修的情況進行資源配置分析，需要承包給其他專業公司進行養護維修的情況不在本系統 的考慮范圍之內。
2.多目標線性規劃
多目標線性規劃在多目標最優化理論占據重要地位。因為多個目標之間存在著矛盾性 和不可公度性，所以要讓所有目標都取得最優解是不可能的。因此多目標規劃問題通常僅 求取有效解(非劣解)。通常采用將多目標問題轉化為單目標規劃問題的方法來求得多目 標規劃問題的非劣解。
本文采用線性加權法將多目標線性規劃轉為單目標線性規劃。線性加權法是將每一個 目標函數值乘以一個權重，然后加起來作為單目標，然后再采用單目標線性規劃方法求取 最優解。權重不同，最后得到的最優解也不相同，決策者可以根據目標的重要程度給出相 應權重。
n個目標Zj(x)(/ = 1,2,...,”)乘以相應的權重Ay(j = l,2,...,n)且工易=1,右＞0,然后 7=1
求和即可得到單目標函數：
3.模型建立
在有多座橋梁待養護維修，資金和人員都有限的情況下，合理配置資源讓養護維修效 益最大化就是一個最優化問題。而養護維修效益包括多個方面，包含緊急程度，維修效果， 重要程度等。而且對于每種決策方案中的每一座橋梁都有被選擇和不被選擇兩種狀態，所 以該問題是一個多目標0-1線性規劃問題。本系統維修效益只從緊急程度、維修效果、重 要程度三方面考慮。對這三方面做如下定義：
緊急程度：橋梁需要維修的迫切程度，由100和橋梁技術狀況評分差值定量表示，分 越低緊急程度越高。
維修效果：維修之后橋梁技術狀況提升度，用預估的維修后的技術狀況評分和維修前 的技術狀況評分差值定量表示。分差越大，維修效果越好。
重要程度：用橋梁每天通過的車流量表示，車流量越大，重要程度越高。
(1)假設預養護維修計劃中有n座待養護維修橋梁，分別記做旺，勺，…，x”，引 入0-1變量勺，第i座橋梁被選擇養護時，x,.=l,否則x, =0o系統提供n座橋梁的資料 如表5-2所示:
表5-2橋梁資料表
橋梁 所需人員所需費用 維修前評分 維修后評分 緊急程度 維修效果 重要程度
Si "1 W1 vi
a2 C2 S2 s’2 “2 巧
«3 C3 S3 S3 "3 e3 %
x” Q/t c” S” Sn e” V”
說明： u. = lOO-^i
e, =s'i _込
(2)決策變量為橋梁被選擇的狀態x,(z- 1,2,...,”) o
(3)從維修效果，維修的緊急程度，橋梁的重要程度出發，最優決策方案需要達到 維修效果最好，維修的橋梁的維修緊急程度最高，重要程度最高。所以目標函數如下：
維修效果最好：maxZ] = +x2e2 + ... + x”e”
緊急程度最高：maxZ2 =%]«] +x2u2 + ... + x„u„
重要程度最高：maxZ3 =x1v1 +x2v2 +- + xnvn
(4)資源的分配包含資金和人員的分配，受養護資金總額和養護人員總數的約束。 假設養護資金總額為C,養護人員總數為A。那么約束條件為：
養護資金約束：+x2al2 +... + x„aln
養護人員約束：xla2l+x2a22+... + xna2n
(5)給三個目標函數進行線性加權。權值越大表示越重要，權值之和為1,權值通過 專家經驗法給出。賦權值之后將多目標0-1線性規劃問題轉換為單目標0-1線性規劃問題, 得到最終目標函數如下：
” ” ”
MaxZ(x) = + A252xzwf. + 幾3 工兀片
/=! /=1 /=1
x}au +x2aI2 + ... + xrtaln <C
S.t. 旺。21 +兀2°22 +…+ 兀“02"
xi = 0 或
(6)轉化成標準形式
新版的MATLAB中有專門用于求解0-1整數線性規劃的函數intlinprogo為了能夠使 用intlinprog函數求解，需要將目標函數進行調整，轉化為標準形式。
令 E = (eJ”” , K = (v,)ly„, A = (ap2x„ > B = (C,P')T , X = {xx,x2,...,xn)T .
函數intlinprog是用來求解整數線性規劃的，對于0-1線性規劃只需要將決策變量約束 在0和1之間就可以使用函數來進行求解。
目標函數可轉化為如下形式：
MINZ(x)= -(人 E + + 心”
AX<B
s.t.
(0)“”
(7)用intlinprog函數進行求解
intlinprog函數的一個原型為：
[x,fval,exitflag]= intlinprog(£intcon,A,b,Aeq,beq,lb,ub)。
說明：f為目標函數的系數矩陣，intcon為整數約束變量所在位置。A為線性規劃不等 式約束變量系數矩陣，b為不等式約束的資源數。Aeq和beq是對應等式約束的變量系數 矩陣和資源數。lb和ub分別為變量的上區間和下區間。返回值x為求得的每個變量的值, fval為最優化的值，通常是一標量，exitflag是函數的退出標志。
目標函數中變量和intlinprog函數原型中變量的對應關系如下：
/ = -(21£ + 22t/ + ^r)；
intcon = (l,2,...,n)r；
A = A；
b = B ；
Aeq和Beq為空；
lb = (0)lx„;
ub = (l)lx„;
將相應變量帶入函數中運算可得
(8 )把MATLAB函整合到java程序中
在MATLAB創建好包含函數求解邏輯的文件，創建deployment project,將文件打包 成jar文件。然后通過在Java代碼中導入jar包的方式使用intlinprog函數。
4.資源分配業務流程
待維修養護的橋梁的信息存放在橋梁養護維修計劃表中，決策人員可以選擇按照維修 效果，緊急程度，重要程度中任意一個因素排序，然后依次分配資源，也可以綜合考慮3 個因素，由系統給出最優的分配方案。確定分配方案之后決策人員可以進行資源分配并制 定橋梁養護維修任務。當有任意一個任務執行完成之后，之前任務占用的一些資源會回歸 到剩余資源中。然后判斷橋梁養護維修計劃表中是否還有待維修的橋梁，如果有就再次進
行資源分配，制定新一輪的養護維修計劃，如果沒有就結束業務流程，等待下次有待維修 橋梁的時候再進行。資源分配業務流程如圖5-8所示：
圖5-8資源分配業務流程圖
5.4.3養護維修方案決策
養護維修方案決策主要是根據橋梁的類型，橋梁病害種類和部位等信息提供橋梁養護 維修方案，以供決策人員和橋梁管理員參考。在橋梁管理系統中，進行決策所采用的方法 主要有：經驗法，經濟分析法，排序和優化。其中經驗法主要分為決策樹法和專家系統法。 本文采用決策樹法實現該功能。
1.決策樹法簡介
決策樹法是屬于經驗決策法中的一種，它的基本原理是以橋梁養護工程師長期積累的 經驗，借助系統化方法對這些經驗進行提煉，將橋梁合理的養護維修對策以過程化的形式 提出。
2.決策樹模型
在橋梁信息管理系統中，選擇哪種養護維修方案，主要決定因素為：橋梁類型，結構，
病害部位，病害類型。在使用的時候，一般是通過專家調查的方法結合工程師的養護維修 經驗，將總結出的養護維修經驗存儲在知識庫中。橋梁管理員或者決策人員通過決策樹從 知識庫中檢索適合橋梁某一病害的養護維修方案，從而達到輔助養護維修方案決策的目 的。本文以幾種典型的橋梁病害為例，簡要介紹該模型，決策樹模型如下圖5-9所示：
結構 病害部位 病害類型 維修養護方案
圖5-9決策樹模型圖
5.5本章小結
本章中，介紹了開發過程中遇到的問題，并對已有解決方案對比，選擇比較有效的解 決方案。詳細介紹了橋梁信息管理系統移動終端模塊的數據傳輸和地圖定位技術，橋梁巡 檢的設計規范，橋梁技術狀況評定的流程和準則，以及輔助決策模塊中資源分配的算法和 提供養護維修方案的方法。
第6章 系統實現與測試
本章主要介紹系統主要功能模塊的具體實現，并簡單介紹實現原理，并通過系統截圖 進行輔助說明。最后介紹系統測試，本文通過對登錄功能進行測試為例，介紹本系統的主 要測試方法和過程。
6.1主要功能實現
6.1.1用戶登錄
登錄功能中又包括登錄驗證、記住密碼、自動登錄3個子功能。
1.記住密碼：勾選“記住密碼”復選框，點擊登錄按鈕之后，用戶下次登錄時用戶名 和密碼自動填充。系統采用Android自帶的Sharedpreferences類將用戶名和密碼以鍵值對 的形式存放在本地文檔中，下次登錄直接從文檔中讀取。
2.自動登錄：勾選“自動登錄”復選框，點擊登錄按鈕之后，用戶下次登錄的時候則 不需要點擊登錄按鈕，直接登錄。系統將“記住密碼”和“自動登錄”兩個復選框的選中 狀態也用Sharedpreferences類保存在本地文檔，下次登錄先讀取復選框的狀態，然后決定 是否自動登錄。
3.登錄驗證：本系統將用戶密碼用MD5加密算法加密后保存在數據庫中，用戶從客 戶端提交用戶名和密碼到服務器端，在服務器端將用戶密碼進行MD5加密得到密碼的密 文，再從數據庫中取出和用戶名對應的密碼的密文，然后將兩個密文進行比較，一致就判 定登錄成功，不一致判定登錄失敗。保證了用戶密碼的安全性。用戶登錄密碼校驗流程如 圖6-1所不：
圖6-2用戶登錄界面
6.1.2主界面
1.主界面展示了橋梁信息管理系統安卓端的重要功能模塊，包含橋梁總覽、橋梁檢索、 負責橋梁、橋梁錄入、橋梁巡檢、養護維修、任務管理、技術狀況評定、橋梁預警、最新 新聞、個人中心和設置。用戶可以根據需要選擇使用不同的功能。
2.最新通告：橋梁管理部門發布的最新通告的簡要信息顯示在主界面的下半部分，包 含通告的標題和發布日期。用戶點擊通告，可以進入通告的詳細信息界面查看通告。
主界面和最新通告界面如圖6-3、圖6-4所示:
6.1.3橋梁總覽和橋梁檢索
橋梁總覽和橋梁檢索功能都是用來查看橋梁信息，區別在于總覽功能查看所有橋梁, 檢索功能通過條件檢索査看特定橋梁。
1.橋梁總覽
以列表的形式加載顯示橋梁的概要信息，用戶可以點擊翻頁按鈕翻頁瀏覽全部的橋 梁，也可以手動輸入頁數跳轉到指定頁查看。該功能釆用了分頁查詢，將較長的查詢時間 分成了若干份，然后用戶每次翻頁都不用等待過長時間。點擊相應橋梁可查看橋梁詳細信 息。橋梁總覽界面如圖6-5所示：
2.橋梁檢索
選擇橋梁檢索屬性，在輸入框中輸入橋梁檢索的關鍵字，點擊開始檢索按鈕，會檢索 出對應屬性的屬性值包含輸入的關鍵字的所有橋梁記錄。檢索出的記錄顯示在界面下方。
點擊相應橋梁可查看橋梁詳細信息。以檢索“江陵大橋”為例，檢索結果如圖6-6所示:
圖6-5橋梁總覽界面 圖6-6橋梁檢索界面
3.詳細信息
用戶在橋梁總覽界面和橋梁檢索界面都可以通過點擊橋梁條目來跳轉到橋梁詳細信 息界面。該界面顯示橋梁的一些基本屬性以及橋梁正側面圖片和橋梁病害圖片。用戶點擊 最上方的“地圖顯示”按鈕可以跳轉到地圖界面，查看橋梁的具體位置。以查看“江陵大 橋”為例，橋梁詳細信息和地圖位置信息分別如圖6-7、圖6-8所示：
6.1.4橋梁錄入
橋梁錄入功能包含橋梁錄入、自動定位、輔助定位、添加圖片等子功能。
1.橋梁錄入
橋梁錄入功能用于錄入橋梁的基礎信息，包括橋梁名稱、地址、建造單位、管理單位 等信息。橋梁管理員能夠實地勘察橋梁的各項屬性，然后通過手機端登錄該系統進行錄入, 確保提交橋梁信息的及時性。
2.自動定位和輔助定位
在橋梁錄入信息填寫界面，經緯度輸入框上方有一個自動定位的開關按鈕，點擊按鈕 系統將自動定位并將當前位置信息自動填入輸入框。用戶也可以點擊自動定位開關按鈕上 方的輔助定位按鈕跳轉到輔助定位的地圖界面。在該界面用戶能夠發現地圖自動定位的坐 標點，如果覺得定位不夠精準，可以手動拖拽坐標點進行定位，點擊坐標點可查看經緯度。 確定最終坐標之后點擊提交按鈕返回到橋梁信息錄入界面，剛剛定位的經緯度就會自動填 充在經緯度輸入框內。
以錄入“江陵大橋”為例，橋梁錄入界面和輔助定位界面分別如圖6-9、圖6-10所示:
3.添加圖片
基本參數填寫完之后，點擊下一步按鈕跳轉到添加圖片界面。用戶可以添加圖片，并 提交保存到服務器對應文件夾中。添加圖片有兩種方式，一種是添加手機本地已經存儲的 圖片，另一種是調用相機接口拍照上傳。添加圖片功能界面如圖6-11、圖6-12所示:
22:31 口 g| 人◎ ♦ 028
箴消 選擇圖片
潑新 瞬用 榜籀
6.1.5橋梁巡檢
橋梁管理員能夠從任務管理功能或巡檢功能進入該功能界面。橋梁巡檢功能包括經常 檢查、定期檢查以及巡檢結果的查看子功能。
1.經常檢查：對于每個部件，橋梁管理員需要填寫缺損狀況和維修建議兩個屬性，屬 性不填寫默認完好。
2.定期檢查：對于每個部件，橋梁管理員要填寫部件評分、缺損狀況、維修方式、維 修費用四個屬性，屬性不填寫默認完好。
3.巡檢結果查看：為了方便了解橋梁病害歷史以及核實巡檢結果，提供了巡檢結果查 看功能。
如圖6-13、圖6-14、圖6-15所示：
6.1.6養護維修
可從任務管理或者養護維修功能進入該功能界面。橋梁管理員完成橋梁養護維修任務 后需要填寫養護維修表，包括維修日期、維修人員、維修的概要信息以及維修后的技術狀 況，填寫完成后提交給上級部門審核。養護維修功能界面如圖6-16所示：
09.44 ft A a
纔緣日期2017 年5 瘡21 B
繼総人貴：
維修裁件1：橋臺
魏擾狀況：橋臺垢工砌體義面風化，剝落。損 壞深度約3cmo
維修建議：用水泥砂漿抹面侈補，砂漿強度等 級一般不應低于M5。
維修方案：用水泥砂漿抹面修補，砂漿歪 級一般不應低于剛5。
維修結果：維修完成，健康狀況良好。
圖6-16養護維修界面
6.1.7任務管理
橋梁管理員通過任務管理功能查看管理自己的任務。任務分為巡檢任務和維修任務兩 種，可以按照時間排序和優先級排序來查看。橋梁管理員點擊執行按鈕后，系統可以根據 維修任務的不同跳轉到不同的功能界面。任務管理功能界面如圖6-17所示:
4如歸插 巡蛭 2017.5.24 mH
5花園綽 巡檢 2017.5.21 埶行
圖6-17任務管理界面
6.1.8橋梁預警
橋梁預警主要用來查看巡檢超期的橋梁，可以選擇按照橋梁技術狀況評分排序或者超
期天數排序查看，也可以通過分類查看來查看危橋或者全部橋梁。在數據庫中添加了巡檢 周期(Inspect_Cycle)和上次巡檢日期(Last_Inspect_Date)兩個屬性，通過這兩個屬性值 再結合當前日期就能夠計算出當前超岀橋梁巡檢周期的天數。橋梁預警界面如圖6-18所
示:
1啦S3 ■人* 雪a ♦■他
橋梁KV
地址評分超期
1 TJ1橋 周津大遵92.33 1
2 TJ2轎 同津大適 90 1
3 方尖灣加T 同津大道 891 3
4 葉港橋 創新路 88.52 2
5 江幔西路S6 61 1
6 XT7橋 大江河路 85 1
7 臚鄉北路8432 3
8 響宏橋位 鏗鄉路 B0 11 /
圖6-18橋梁預警界面
6.1.9個人中心
用戶可以使用該功能查看并修改個人信息。為了方便管理，部分用戶信息沒有提供修
不能夠隨意修改。個人中心功能界面如圖6-19、圖6-20所示:
用戶名 shenyan 用戶名 shenyan
性名： 沈蕭 姓名： 沈照
年齡： 23
地址: 江蘇齒，瘍卅市，祁江區 年齡： 23
電it： 17715123047 地址： 江蘇省，揚州韋，祁江區
手機： 15380327891
郵箱： 543071788@qq.com 電話: 17715123047
qq： 3251124231
手林： 15380327891
郵箱：543O71788@qq.com
qq： 3251124231
6.2系統測試
系統測試主要包括功能測試，性能測試，兼容性測試，安全性測試和回歸測試。該系 統主要進行了功能測試，兼容性測試，性能測試。
6.2.1功能測試
功能測試的基本方法是構造一些輸入，檢查輸出與期望值是否一致，如果一致，則說 明測試通過，不一致，則說明功能存在問題。本文采用了等價劃分和邊界值法設計功能測 試方案。本文以設計登錄功能的測試用例為例，測試結果如表6-1所示：
表6-1登錄功能測試用例
用例ID 用戶名: 用例名冷 用例入匚 用例描立 WJBridge-01-TC
shenyan,密碼：110
仁系統登錄。
了 ：點擊app,進入登錄界面。
該組測試用例用來測試登錄系統的登錄功能是否符合規格說明。
測試用
例ID 場景 測試步驟 預期結果 實際結果
TC1 初始頁 面顯示 從用例入口進入 頁面兀素完整，顯不 與功能規格說明一 致。 頁面元素完整，顯示 與功能規格說明一 致。
TC2 用戶名 輸入驗 證 輸入數字："123456” 輸入成功 輸入成功
TC3 用戶名 輸入驗 證 輸入字符：“admin” 輸入成功 輸入成功
TC4 密碼輸 入驗證 輸入數字：“123456” 輸入成功 輸入成功
TC5 密碼輸 入驗證 輸入字符：“admin” 輸入成功 輸入成功
TC6 用戶名 和密碼 輸入框 判空驗 證 不輸入用戶名和密碼 點擊登錄 提示：用戶名和密碼 不能為空 提示：用戶名和密碼 不能為空
TC7 密碼輸 入框判 空驗證 輸入用戶名："admin”， 不輸入密碼，點擊登錄 提示：用戶名和密碼 不能為空 提示：用戶名和密碼 不能為空
TC8 用戶名 輸入框 判空驗 證 不輸入用戶名，輸入密 碼："admin”，點擊登 錄 提示：用戶名和密碼 不能為空 提示：用戶名和密碼 不能為空
（續表6-1）
測試用例ID 場景 測試步驟 預期結果 實際結果
TC9 用戶名有效性驗 證 輸入不存在的用 戶名:"admin", 錯誤密碼：“111” 在登錄按鈕上方 以紅色的字提 示：用戶名不存 在 在登錄按鈕上方 以紅色的字提 示：用戶名不存 在
TC10 密碼有效性驗證 輸入存在的用戶 名："shenyan", 錯誤的密碼：
“111” 在登錄按鈕上方 以紅色的文字提 示：密碼錯誤 在登錄按鈕上方 以紅色的文字提 示：密碼錯誤
TC11 登錄成功驗證 輸入存在的用戶 名：“shenyan”， 正確的密碼： “110” 在登錄按鈕上方 以綠色的文字提 示登錄成功，之 后跳轉到主界 面，登錄成功 在登錄按鈕上方 以綠色的文字提 示登錄成功，之 后跳轉到主界 面，登錄成功
6.2.2兼容性測試
本系統兼容性測試時通過一站式移動應用測試平臺Testin來完成的。選取了市面上主 流的50款機型作為測試機型。測試包括安裝、啟動、卸載、Monkey測試四項。50款機型 中有4款測試未通過，3款安裝失敗，1款初始化失敗，測試通過率為92%O測試結果良 好，有較強兼容性。部分測試結果如圖6-21所示：
終ss列表
g-SSgSNoteS • V
X20 • V
ESGalaxj Win Pjo • v*
W0X20 • X
OPPO A79 • 7
ElGaisr? ricte u r 呢傅煖） • 7
y*Z}C8813D • V
圖6-21兼容性測試結果
6.2.3性能測試
本系統性能測試主要測試了系統的連續運行時間和并發性。
連續運行時間測試以90天作為測試時間，測試期間定期登錄系統并進行操作，檢查
系統是否良運行良好，達到預期目標。測試用例如表6-2所示：
表6-2連續運行時間測試用例
測試用例名稱 連續運行時間嚴重
目的 驗證系統能否連續運行90天
前置條件 1個用戶成功登錄系統
測試用例級別 性能測試
（續表6-2）
測試用例執行日期 2017-08-12 至 2017-10-11
測試用例名稱 連續運行時間嚴重
測試流程 服務器保持開機，每隔五天登錄一次系統，進行操作。
預期結果 系統運行良好，響應時間在0.ls~2.5s之間
實際結果 系統運行良好，響應時間在0.1s~2.5s之間
結論 系統能夠連續90天良好運行
本系統采用Loadrunnerl2壓力測試工具進行并發性測試。首先進行腳本錄制，然后將 用戶數設置為指定值，進行腳本回放，模擬多個用戶同時訪問系統，觀察系統運行情況。 根據應用場景，本系統并發測試的用戶數量為100人。測試用例如表6-3所示：
表6-3并發性測試用例
測試用例名稱 多個用戶同時訪問系統
目的 驗證多個用戶同時訪問系統并進行同樣操作，系統是否良好運行
前置條件 系統服務器配置正確，用戶能成功登錄系統
測試用例級別 性能測試
測試用例執行 日期 2017-10
測試流程 錄制腳本，將用戶數量設置為100人，回放腳本，查看日志
預期結果 系統運行良好，響應時間在0.1S-2.5S之間，無死鎖和其他性能問題
6.3本章小結
本章中，主要介紹了橋梁信息管理系統的各個功能模塊實現效果，并簡要介紹了功能 模塊實現原理。最后以測試系統登錄功能為例簡要介紹了該項目所采用的測試方法，測試 結果。系統仍存在不少問題，尤其是系統測試不夠全面，仍需要進一步完善。
第7章總結與展望
7.1總結
本文立足于原有的橋梁信息管理系統，結合國內外橋梁信息管理系統發展現狀，分析 原有橋梁信息管理系統的不足，然后對原有橋梁信息管理系統進行補充，并給出了設計方 案和系統實現。
本系統對原有系統改進有如下幾點：
(1)原有系統僅僅給出了 Web端實現，橋梁管理員采集橋梁信息需要先記錄在紙上， 再錄入到系統中。新系統給出了安卓端實現，橋梁管理員能夠通過安卓手機定位橋梁位置, 拍攝橋梁照片，并且能夠使用無線網絡即時上傳采集的橋梁信息。給橋梁管理員的新橋錄 入，橋梁巡檢工作帶來了極大的便利。
(2)原有系統沒有實現橋梁技術狀況評定，技術狀況評定都是由專業人員參照養護 規范進行評定。新系統在原有系統基礎上補充了橋梁巡檢功能，主要作用是將橋梁養護規 范結合到系統中，非專業人員也可以通過填寫橋梁巡檢表，然后由系統實現橋梁技術狀況 評定。
(3)原有系統的管理人員僅僅包含了橋梁管理部門的工作人員，管理效果比較局限。 新系統以微信小程序的方式向廣大普通市民提供接口，將市民納入橋梁管理的工作中。市 民能夠通過微信小程序及時舉報危橋壞橋，能夠進一步保證橋梁的安全運營。
(4)原有系統只對橋梁信息進行了檔案管理，沒有對橋梁信息做統計分析，不利于 橋梁管理人員作出決策。新系統對養護維修費用，養護人員數量，養護維修效果進行了綜 合考慮，使用多目標線性規劃的方法，給出有效的養護方案建議，從而輔助決策人員作出 有效決策。決策人員還能夠通過選擇橋梁病害種類獲取到橋梁養護規范中的養護維修措 施。
7.2展望
開發一個運行良好的橋梁信息管理系統是一個比較龐大的工程。橋梁管理規范錯綜復 雜，決定橋梁信息管理系統涉及到大量的數據庫建設和模塊的開發。到目前為止，主要實 現了橋梁信息管理系統的基本功能，主要以橋梁檔案信息管理，信息釆集，橋梁巡檢，橋 梁技術狀況評定，養護維修，任務管理，橋梁預警，病害舉報功能為主。該系統還有一些 功能有待增加或完善。
(1)使用無線傳感器網絡檢測橋梁健康狀況。在橋梁的關鍵部位安置無線傳感器， 釆集橋梁健康狀況信息，然后通過信息采集子系統收集整理傳感器獲取的數據，最后通過 數據傳輸子系統將獲取的數據傳輸到服務器端存儲起來。橋梁管理員在辦公室就能實現對 橋梁健康的隨時監測，保證橋梁安全運營。
（2） 增加行程規劃功能。橋梁管理員可能一天之內有多個地方巡檢任務或者養護維 修任務，合理規劃行程，能夠節省時間，提高工作效率。該功能通過優化算法將執行任務 的地方和出發點進行排序，使總行程最短。
（3） 提供專家擬定橋梁部件權重的接口。國家橋梁規范中的推薦權重不適用所有地 方。將來的系統中可以采用AHP層次分析法，通過讓專家填寫對比矩陣的方式，來計算 得到一套適合當地狀況的橋梁部件權重。這樣橋梁信息管理系統將具有更強的實用性和更 廣的適用范圍。
（4） 兼容iOS。目前該系統的移動端僅支持Adroid系統，但是目前iOS系統也占據 了很大的市場，不可忽略。將原來采用Android原生開發的系統業務邏輯提取出來，重新 采用混合開發技術，開發出兼容Andriod和iOS兩大系統的橋梁信息管理系統的移動端app。
因此，我相信在已經完成的系統的基礎上，將開發出一套更加完善的橋梁信息管理系 統。
參考文獻
[1]劉美銘.橋梁事故分析[D].西南交通大學,2015.
[2]王翔.基于GIS的橋梁管理系統的設計與研究[J].無線互聯科技,2016,2(4):145-146.
[3]候林濤.基于GIS的橋梁狀態評估信息系統研究[D].西安科技大學,2011.
[4]中華人民共和國住房和城鄉建設部.《住房城鄉建設部關于加快城市道路橋梁建設改 造的通知》(建城[2014]90 號)[EB/OL] .http://www.mohurd.gov.cn/wj fb/201407/ t20140716_218491.html, 2014.
[5]Akgul F. Bridge management in Turkey:a BMS design with customised functionalities^]. Structure & Infrastructure Engineering, 2016, 12(5):647-666.
[6]林劉贊.基于損傷的橋梁狀態評估決策系統研究[D].同濟大學,2009.
[7]李東昇.軌道梁橋養護管理綜合數據平臺研究與開發[D].北京交通大學,2009.
[8]宋子嬪.公路橋梁建養一體化信息管理研究[D].東南大學,2015.
[9]何帆.橋梁管理系統發展現狀及問題[J].建筑工程技術與設計,2015(7):力0-771.
[10]李忠軍.基于Web-GIS的橋梁養護管理系統研究與開發[D].東南大學,2005.
[11]梁錚，曹明蘭.國內外橋梁管理系統發展綜述[J].建筑管理現代化,2007(95):54-56.
[12JM.K. Luhandjula, M.J.Rangoaga. An approach for solving a fuzzy multiobjective programming problem[J], European Journal of Operational Research. 2014(2):249-255.
[13]黃俊爽，李聰，李相儉等.淺談Java面向對象程序設計[J].科技信息,2010(13):47-47.
[14]哇俊華，劉慧娜，王建鑫等.多核多線程技術綜述[J].計算機應用，2013, 33(sl):239-242.
[15]黃學雨，張茂新基于Java應用程序的可移植緩存模型[J].微電子學與計算機，2014, 31(9):101-104.
[16]徐繞山.Java Web應用開發模式研究[J].信息化研究,2012, 38(3):1-13.
[17]仰燕蘭，金曉雪，葉樺.ASP.NET AJAX框架研究及其在Web開發中的應用[J].計算機 應用與軟件,2011, 28(6):195-198.
[18]黃玉春.淺談下一代Web開發標準的核心技術一HTML5[J],計算機時代2004):3-5.
[19]舒禮蓮.基于Spring MVC的Web應用開發[J].計算機與現代化,2013(11):167-173.
[20]翟高粵.Spring Web Flow在Web應用開發中的研究[J].微計算機應用，2011, 32(01):47-52.
[21]宋濤，王洪鑫，徐慶增.J2EE平臺標準下的SPRING3.0輕量級框架技術概述[J].通訊世 界,2015(23):306-307.
[22]李詠.Web開發中MVC設計模式的研究與應用[J]?企業技術開發,2014, 33(9):55-56.
[23]王剛.Struts框架技術簡析[J].長春師范學院學報,2012,31(9):25-28.
[24]榮艷冬 關于Mybatis持久層框架的應用研究[J]•信息安全與技術,2015, 6(12):86-88.
[25]時月梅.基于Spring MVC、MyBatis實現數據分頁顯示處理[J].信息技術與信息化， 2015(7):203-206.
[26]張建源.Anroid開發技術的學習及應用[J].現代工業經濟和信息化,2014, 4(6):62-64.
[27]李霞.Android虛擬機運行時技術的分析與評測[D]?東南大學,2015.
[28]明日科Android從入門到精通[M].北京：清華大學出版社,2012:4.
[29]Cui Fang Xing, Feng Qin Wang, Yang Sun. A New Web Application Framework Based on SSH[J], Applied Mechanics and Materials, 2015, 713(1):2203-2207?
[30]伊鵬翔.Dalvik虛擬機結構與性能的研究[D].吉林大學,2011.
[31]Nicolas Palix, Gael Thomas, Suman Saha, Christophe Calves, Gilles Muller, Julia Lawall. Faults in Linux 2.6[J]. ACM Transactions on Computer Systems (TOCS), 2014, 32(2): l?40.
[32]Na Wei, Mei Na Song, Ke Xu, Chao Jiang. A Novel WebService Architecture Based on REST[J]. Advanced Materials Research, 2011? 1043(143):1213-1217.
[33]Juris Tihomirovs, Janis Grabis. Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics[J]. Information Technology and Management Science, 2016, 19(1):92-97.
[34]騰訊.微信公眾平臺•"小程序-開發-框架[EB/OL]. https://mp.weixin.qq.com/debug/ wxadoc/dev/framework/MINA.htinl, 2016.
[35]騰訊.微信公眾平臺■小程序-開發-API[EB/OL], https://mp.weixin.qq.com/debug/ wxadoc/dev/api/, 2016.
[36]百度百科.高德開放平臺[EB/OL]. https://baike.baidu.com/item/高德開放平臺/19856770? fi=aladdin, 2016.
[37]阿里巴巴.高德開放平臺-產品介紹■地圖[EB/OL]. http://lbs.amap.com/getting-started/ map/, 2016.
[38]阿里巴巴.高德開放平臺■•產品介紹■定位[EB/OL], http://lbs.amap.com/getting-started/ locate, 2016.
[3刃 Ferraiolo D, Chandramouli R, Kuhn D. Richard, et al. Role-Based Access Control ModelsfJ]. Computer Science, 2009, 4(3):190-251.
[40]周偉平，陸松年JRBAC訪問控制研究[J].計算機安全,2007(2):11-13.
[41]常彥德.基于角色的訪問控制技術研究進展[J].計算機與現代化,2011, 12(⑵:5-&
[42]榮艷冬.Android軟件權限系統的設計與實現[J].軟件,2014, 35(02):50-52.
[43]羅鈞，趙傳智，汪飛.基于RBAC模型的權限高效管理方法[J].計算機研究與發展, 2016, 53(05):1000-100&
[44]王志瑞，顧問，劉正濤.基于RBAC模型的權限組件[J].計算機系統應用，2015, 24(3):156-160.
[45]陳小兵，張漢煜，駱力明等.SQL注入攻擊及其防范檢測技術研究[J].計算機工程與應 用,2007, 43(11):150-152.
[46]Dorai R, Kannan V. SQL Injection-Database Attack Revolution And Prevention[J], Applied Mechanics & Materials, 2011, 6(4):810-814.
[47]楊永國.SQL的注入攻擊及防范措施探討——以Microsoft SQL Server為例[J].軟件導 干 IJ,2O13, 12(4):155-156.
[48]車延雪，王志強.SQL注入式攻擊與防范[J].網絡安全技術與應用,2014(11):89.
[4刃 Asha. N, Varun Kumar M. Preventing SQL Iiy ection Attacks[J], International Journal of Computer Applications, 2012, 52(13):28-32.
[50]高靜，段會川.JSON數據傳輸效率研究[J].計算機工程與設計,2011, 32(07):2267-2270.
[51]申翔翔，王魯，謝楚鵬，李景嶺.Android中多線程機制的探究[J].科技廣場， 2015(06):234-239.
[52]孫曉光.WGS-84與地方坐標系轉換參數的優化選擇[J].測繪與空間地理信息，
2007(02):152-154.
下一篇：沒有了
相關標簽:
