熱門論文
最新論文
交警執法記錄信息管理系統的設計與實現
發布時間：2023-08-02 13:47
第一章 緒論
隨著計算機技術的發展和執法記錄儀在交警執法過程中的普遍應用，自動化管理 執法數據已經成為發展的趨勢，如何有效的管理執法記錄儀數據已經成為一個重要話 題，建立健全的交警執法記錄信息管理能夠使公安部門執法更加透明化，規范化。
1.1論文的背景及意義
近年來，隨著社會的發展，廣大人民群眾法律意識在不斷地增強，人們的維權意 識也在迅速增強，尤其是涉及到自身利益的時候。由于互聯網的發展，社會上的各大 媒體、網絡以及群眾時刻監督著執法人員的辦案情況，公安機關的執法方式不得不發 生變化，經多方面調查，因執法過程中缺少視音頻等電子證據導致的執法糾紛情況和 糾紛投訴責任無法認定的情況時有發生。當遇到事后監督維權的案例發生的時候，如 何利用科學的手段來維護權益，做到公平公正處理，增強廣大人民群眾對執法部門的 公信力和說服力，減少執法成本，提高交警部門執法辦案效率，已成為當前迫切需要 解決的難題。
受到建設平安城市的影響，國家逐漸增強了對城市報警系統和監控系統的建設， 國家為了拓展交警的辦案方法，針對交警執法過程中缺乏電子證據的事實，促使了交 警執法記錄儀的誕生，目前交警執法記錄儀已經在我國公安部門得到了廣泛的使用。 根據公安部發表的《關于交警系統執法記錄儀使用管理規定（試行）通知》（公交管 〔2013〕231 號）的相關規定［1］，公安機關應該為交通管理部門在外執勤人員配備符 合技術要求標準的電子設備——執法記錄儀，這表示執法記錄儀已經成為道路執勤人 員和事故處理現場日常工作中必不可少的信息化裝備［2］。
在執法記錄儀的使用過程中屢次出現警員不隨身佩戴、使用不規范等各種問題， 因此公安部門對執法記錄儀的使用分別制定了一系列規范，要求交警在日常工作中必 須佩戴和正確使用執法記錄儀，這對于加強民警執法監督和推動陽光執法發揮了很大 的作用，同時防止和減少了執法過程中的違法亂紀行為。
為了解決交警執法記錄儀使用問題以及更加有效地、充分地利用執法采集數據， 在經過充分地調研溝通，本著統一性、規范性、實用性的原則，交警支隊規劃建設一 個具有音視頻拍攝、分級應用管理、警員管理于一體的交警執法記錄信息管理系統， 實現對采集的圖片、音視頻數據的集中統一的存儲、管理、使用以及對警員的規范化 管理［3-4］。
1.2國內外研究現狀
1.2.1 國內研究現狀
社會的不斷發展，科技的不斷進步，互聯網已經無時無刻的伴隨著我們，如何高 效的利用計算機技術改變我們的辦公方式，成為各行各業的熱門話題，尤其是處在這 樣一個信息化時代。交警執法記錄儀的使用，使得執法部門辦案更加規范化，由于執 法記錄儀的快速的發展，執法數據的不斷壯大，因此在執法記錄儀的使用過程中暴露 出很多其它的問題。人們開始思考如何利用科技的手段，集中化、規范化的管理使用 交警執法記錄儀，如何利用執法數據開展交警的工作。因此國內外的很多知名企業開 始投入到這方面的研究，對關于交警執法數據的管理和交警日常管理提出了自己的解 決方案［5］。
浙江大華技術服務有限公司專門從事計算軟件開發、產品設計、生產、安裝等業 務，服務的對象廣泛，涉及到交通、教育和司法等很多領域。經過將近20多年的快 速發展，已經有自己的專業品牌，旗下有自己的執法記錄儀產品，該公司針對執法記 錄儀管理平臺提出了解決方案，包括視頻采集、數據的管理、大量非結構化數據的分 布式存儲及快速查詢等多個功能。該平臺主要由數據采集終端（執法記錄儀設備）、 數據采集站、執法數據監管平臺三部分組成。在省公安廳部署執法數據監管平臺，各 個管轄區的派出所部署相應的采集站，執法記錄儀采集到的數據能夠上傳到采集站 內。執法記錄儀采集站和執法數據監管平臺通過公安內網進行連接，從基層的交警執 法人員到公安廳的不同警員可以通過瀏覽器訪問數據監管平臺，職能不同的警員，權 限也不同。該系統通過實現執法數據的自動化上傳、拷貝，從而節省大量的時間。同 時還增加了對采集信息的標注、評論，對執法監督實現了現場的錄入功能，對執法數 據監管平臺完成數據的統計模塊，還增添了日志的審查一級系統管理等重要模塊，形 成一個完成的執法數據管理以及監管平臺。該系統一個重要的特點是采用分布式技 術，實現對各執法記錄儀上傳采集站上的數據的分布式管理。該系統是在浙江大華公 司的云存儲架構上設計開發，部署更加簡單靈活。
由于信息時代數據的大爆炸，大數據、信息云等新的技術引起了大量的關注，許 多國家也將這種新的技術列為發展戰略之一，數據就是黃金 ，從數據中挖掘黃金， 從而掌握主動權。 TCL 是通過對行業用戶的深度調查，分析用戶需求，最先提出“警 云”的概念，同時自主開發了“警云”數據管理平臺。前端采集系統、執法記錄儀、服 務接口對接和后端管理系統四大部分共同合作，構成了“警云”系統。在實現數據的自 動導入、分類、使用的問題上，將大量的采集數據存儲大了云端，從而有效的解決了 數據大量非結構化數據的存儲問題，還提高了交警日常工作效率，節省了人力。采用 云存儲計算機技術，適合大量高清數據分析，數據還可以關聯其他數據信息，避免了 信息孤島的形成［6］。
1.2.2 國外研究現狀
美國對交通部門并沒有設置專門的交通警察部門，美國的警察既要管理治安問 題，同時還要管理交通問題，體現的是一職多能的特點。警察通過以開罰單的形式通 知違反交通規則的人，然后在公民的個人計算機數據庫中錄入違反交通規則的相關信 息。政府部門和法院等相關部門都可以通過計算機數據庫查詢檢索需要的信息。
美國LLC信息技術有限責任公司（ITI）是一個向公共安全行業提供軟件解決方 案和服務的前方為服務提供商，該公司的典型客戶有警察、治安部門、縣監獄和市政 法院等執法部門，Law Enforcement Records Management System是該公司研發的一個 典型的產品。該產品包含一個先進的報告系統，旨在滿足任何執法機構的需求。RMS 的核心是攻擊和事件報告功能，該系統中設計開發了一個強大的數據輸入工具，加速 收集、報告、批準和傳播犯罪活動和事件報告，除了提供用于刑事案件的報告外， “罪 行和事件”報告模塊還收集統計信息，以便與內置的統一犯罪報告（UCR）和可選的 州立特定事件報告（IBR）功能一起使用。
該系統使用別名，同時關聯了客戶相關的朋友的信息，允許執法者能夠快速地搜 索找到與客戶相關的人，內部提供可以上傳圖像和附件功能，支持執法人員提供犯罪 現場，人員，車輛或相關照片，可以通過任何類型的電子附件，直接做報告，每個圖 像或附件都能夠使用電子簽名自動簽名。系統還可以跟蹤其數據的真實性并提供監管 鏈報告，每個文件將自動存儲在 Microsoft SQL 數據庫。 RMS 還包括逮捕報告，實地 訪談報告（FIR）、執法人員日常監督和罪犯注冊等強大功能。內置的證據管理模塊提 供全面的監管鏈的報告以及條形碼打印和庫存功能。使用內置案例管理模塊，可以輕 松管理案例、案例分配和案例加載，甚至可以根據執法記錄報告案例庫搜索相關推薦 案例。
1.3 論文的主要研究內容
通過調研和交流的方式，對交警日常業務進行了解，分析交警執法過程中的功能 需求和業務需求，設計并實現交警執法記錄信息管理系統。系統采用先進的計算機技 術，依托現有的公安網絡，建設具有分級應用管理、警員管理于一體的執法記錄信息 管理系統。利用專用的執法記錄儀采集工作站提供靈活、高效、安全的數據導入機制， 滿足全市范圍內交警人員對視頻數據的快速流暢的檢索和瀏覽。
1.在實現海量視頻數據存儲和管理的基礎上，根據支隊的管理需要，將警務業 務需求融入執法監管平臺，設計并實現了包括登錄認證、系統管理、執法監督、業務 監督、使用監督、監督考評、信息標注、統計分析、日志管理、設備管理等十個功能 模塊，從而有效的提高了警員的日常工作效率和集中、自動化的管理執法數據［7-10］。
2.交警執法記錄信息管理系統主要是基于 B/S 架構的 Web 應用程序，由客戶端 與服務器兩部分組成。用戶通過瀏覽器完成與服務器之間的交互，瀏覽器起到對服務 器返回信息的解析工作，將用戶請求查看的資源以一種簡單直觀的方式展現出來。服 務端接收客戶端發送過來的請求，同時將客戶的請求給予相應的處理，找到客戶需要 的資源信息，最后把查找到的資源返回給客戶端。
3.HTML 是用來保存靜態的內容，隨著社會的發展以及需求的不斷增加，靜態頁 面很難滿足實際應用的需求， Servlet 是采用 Java 語言編寫的服務器端的程序，用于 生成動態的 Web 內容，其工作的主要模式是請求響應的方式。
4.交警執法記錄信息管理系統采用的是 MySQL 數據庫，通過對系統進行概念建 模，物理建模等，實現了對該系統的數據庫設計與實現，用戶可以通過瀏覽器實現對 數據庫數據的操作。
1.4 論文的組織結構
本文的結構安排如下： 第一章：緒論。主要介紹了交警執法信息管理系統的項目背景，開發目的及意義。 在此基礎上，給出了本論文的研究內容和結構安排。
第二章：介紹相關技術。首先介紹了執法記錄儀和采集站的基本知識，以及執法 記錄儀與采集站的接入和數據采集系統的功能，然后闡述了開發過程中采用的 B/S 架 構、 UML 統一建模語言和前端開發框架等相關技術，為后續開發完成奠定基礎。
第三章：交警執法記錄信息管理系統的需求分析。交警執法記錄信息管理系統的 業務描述，功能分析、需求建模以及數據庫建模。
第四章：交警執法記錄信息管理系統的設計與實現。具體描述了系統的物理架構 和系統架構設計，完成數據庫的物理結構設計與實現，詳細介紹了各個模塊的設計與 實現。
第五章：交警執法記錄信息管理系統的測試與分析。在完成系統的設計與實現之 后，部署測試環境，根據需求分析，對系統的功能性與非功能需求進行測試，并對測 試結果進行分析。
第六章：結束語。概況總結論文的主要工作，并提出對下一步需要研究的內容的 展望。
第二章 相關技術介紹
交警執法記錄信息管理系統設計與開發過程中，用到了一些基礎技術理論以及相 關的軟件開發技術，這些技術和理論都是確保系統能夠成功開發的重要保障。本章將 對這些技術理論進行介紹。
2.1執法記錄儀和采集站基本知識
2.1.1 執法記錄儀
執法記錄儀是公安民警執法時隨身佩戴的電子設備，具有拍攝照片、視音頻攝錄 等功能。該產品的研發主要是針對執法部門現場取證的產品，由于體積小、佩戴靈活 多變，適用于多種警鐘。交警利用現代化電子產品執法記錄儀進行執法，代表著一線 交警執法技術的科技含量的逐漸增加，執法方式的規范性。執法記錄儀的使用為交警 執法的有效性和公正性提供了有力的證明資料，有效的保護了執法人民的正當利益和 執法人員的人身安全，同時還提高了交警執法的質量和工作效率，為執法智能化、自 動化辦公做出了貢獻，提升了交警執法的管理水平。執法記錄儀能夠采集取證，同時 可以保證采集數據的轉存和回放，能夠避免不法分子的刻意斷章取義和惡意投訴等問 題。執法記錄儀的外觀如圖 2.1 所示：
圖 2.1 執法記錄儀外觀
執法記錄儀功能如下：
1．攝錄功能：執法記錄儀在開機的狀態下，將會進入取景模式，選擇攝錄功能， 執法記錄儀就會自動開始拍攝執法現場的視頻數據；按下停止鍵，執法記錄儀將會停 止記錄視頻，并將拍攝的內容保存在執法記錄儀磁盤內。
2．錄音功能：執法記錄儀在開機狀態下，將會進入取景模式，選擇錄音功能， 執法記錄儀開始自動進行錄音，當錄音完成之后，按下停止鍵，執法記錄儀將會停止 錄音并且保存錄音的內容。
3．拍照功能：執法記錄儀在開機狀態下，將會進入取景模式，通過顯示屏進行 取景；按下拍照鍵，就會拍照，然后將拍攝的照片信息保存在執法記錄儀內。
4．現場回放功能：通過時間等查詢方式，執法記錄儀能夠對采集數據進行瀏覽、 檢索和回放。
5．字符疊加功能：通過對攝錄的視頻、音頻和圖片等數據進行自動疊加信息， 以防止拍攝的視頻、音頻和圖片等數據被篡改和惡意修改，疊加的信息主要有執法記 錄儀編號、時間和設備信息水印等。
6．提示功能：執法記錄儀能夠提供相關的操作步驟，有相應的狀態顯示功能。
7．電池續航時間：執法記錄儀可以持續使用超過 6 個小時以上。
8．操作日志：執法記錄儀能夠記錄執法人員的操作日志。
9．防護等級：執法記錄儀的防塵等級是 5 級以上，具有很強的防水功能，達到
6 級防水，能夠防止 2 米以下的自由跌落。
2.1.2 采集站
近年，執法記錄儀在國內的市場已經得到了廣泛的應用，最初由于警務部門只有 少數的人配備了執法記錄儀，很對警員將執法記錄儀上的執法數據直接拷貝到自己辦 公用的 PC 機上進行管理，但是執法的數據的不斷增加以及執法部門的規范化管理需 求，急切的需要一臺能夠集中化存儲和管理交警執法的視音頻數據的設備。執法記錄 儀采集站則是專門用于存儲流媒體數據的設備，廣泛應用于公安、交警、城管等各個 執法單位。
執法記錄儀現場采集到的數據需要上傳到采集站上，市場上執法記錄儀大多都出 自不同的廠家。然而采集站是一個很大的磁盤陣列，需要設計開發相應配套的數據采 集系統，能夠識別不同廠商出廠的執法記錄儀，下面介紹執法記錄儀數據采集系統的 基本知識，主要包括執法記錄儀的接入管理和數據上傳。
1.執法記錄儀接入管理
由于不同的廠商研發的執法記錄儀不同，接口也不同，執法記錄儀接入管理的主 要作用是識別執法記錄儀和執法數據，接入執法記錄儀，掛載執法記錄儀文件系統， 判斷執法記錄儀是否合法等。現場執法記錄儀接入采集站的示意圖如圖 2.2 所示，執 法記錄儀接入管理界面示意圖如圖 2.3 所示：
2.執法數據采集
執法數據采集主要實現執法數據的導入、轉存和上傳功能，即當執法記錄儀接入 采集站時，采集站將執法數據（如音頻、視頻、圖片等）導入本機，然后在空閑時間 上傳到后臺多媒體文件服務器。具體流程如下：
1．接入執法記錄儀。
2．將執法記錄儀掛載為大容量存儲設備。
3．采集站讀取文件目錄，將視頻文件、圖片、標注信息等復制到采集站數據目 錄。
4．刪除執法記錄儀上已復制文件。
5．連接多媒體文件服務器。
6．上傳視頻文件、圖片等文件。
7．刪除采集站數據目錄的已上傳的文件。
數據采集站作為執法數據的采集設備，在數據采集中起到了存儲轉發的作用。所 有的執法數據最終保存到服務器端的磁盤陣列中，用戶可以通過執法記錄信息管理系 統訪問和管理服務器端的視頻、音頻、圖像等數據。執法記錄儀數據上傳采集站的示 意圖如圖 2.4 所示：
分布式云存儲服務器
樹雷胃雷 mis胃雷
圖 2.4 執法記錄儀數據上傳示意圖
2.2B/S 架構
B/S和C/S可以處理相同的業務，是企業應用系統的兩種軟件架構方式。B/S 架構是隨著 Web 技術的發展，逐漸流行的一種網絡結構模式。 B/S 架構與 C/S 架構 是計算機技術上兩個主流的架構方式，各自存在著自己的優缺點，兩者之間最顯著 的一個不同在于， C/S 架構需要客戶在自己的 PC 機安裝專用的客戶端軟件，然而 B/S 架構僅需要客戶機上存在任何一個 Web 瀏覽器，就能夠通過瀏覽器的網址訪問 該系統，使用系統的功能，對系統中的數據進行相應的操作。
C/S 架構是通過客戶端安裝應用程序與服務器提供相應服務的方式工作的，是一 種典型的兩層架構。用戶可以在一臺或者多臺用戶的電腦上安裝客戶端程序，但是服 務器端則只有數據庫服務器和 Socket 服務器兩種。由于 C/S 架構通常用于局域網， 并且在實際應用中的維護成本比較高，每當系統升級一次，導致C/S架構的適用面非 常窄。隨著互聯網技術的發展，B/S架構的優點則是客服了此缺陷，軟件的客戶端不 受地理位置的限制，只需要客戶機上存在瀏覽器即可隨時訪問服務端的 Web 應用程 序。B/S架構是由表示層、業務邏輯層和數據訪問層的三層結構圖[11], B/S架構圖如
圖 2.5 所示：
2.3Bootstrap 框架
Bootstrap 是目前比較流行的 Web 前端工具，是一個開源的項目，開發者可以在 官網上下載最新的 Bootstrap 源碼。它是基于由 CSS、 JavaScript 編寫而成，適用于響 應式設計與開發。 Bootstrap 框架封裝了大量的可擴展的庫，并提供相關的文檔，有 利于開發者閱讀，一些開發者只需要在這些庫的基礎上擴展自己的項目，能夠很大程 度上提高開發者的效率。 Bootstrap 框架還包含幾十個組件，具有很強的兼容性，它 利用基于網格發展而來的柵格(Grids)系統，保證了前端頁面的響應式設計，開發者可 以根據前端頁面的大小進行自動調整頁面布局情況，適用的范圍也非常的廣泛， PC 端的網頁、 iPad 以及手機界面等都可以用它來進行設計。 Bootstrap 框架同時提供了 預編譯和源碼兩種形式的壓縮包，當用戶需要在任意的 Web 項目中使用框架的時候， 開發者選擇預編譯版本，預編譯版本可以用于任意的 Web 項目中直接使用。源碼是 由預編譯的 CSS、JS 和圖標字體文件，通過安裝和調用兩種方法使用 Bootstrap 框架 的基本樣式。 Bootstrap 利用柵格系統構建自己需要的布局效果，包含很多可復用的 組件，并且這些組件與 JQuery 插件具有相互交互的功能，這些為 Bootstrap 的組件增 添了新的活力［12-13］。
2.4UML 統一建模語言
1997年OMG標準的制定是UML語言的開端，UML統一建模語言是IT人員在 進行計算機軟件開發過程中的一種建模工具。它是利用圖形化、模型化的方式，清楚 地、簡潔的描述系統的一種語言，應用于軟件開發的各個階段，包括從軟件的需求分 析，軟件設計，系統工作流程到系統的構造和配置。 UML 主要由事物、圖及關系三 種元素構成。事物主要包含行為事物、組織事務以及輔助事務等。通過關聯、依賴、 泛化及實現四種關系來描述 UML 中事物以之間的聯系。當一個類的對象需要訪問另 外一個類的對象則用關聯關系表示。當兩個對象之間無法獨立執行變化的時候，表示 兩個對象之間存在著依賴關系。泛化關系定義個表示子類和父類之間的集成關系，例 如動物和狗兩個對象之間存在著泛化關系，動物具有的一些屬性和行為，狗也具有相 同的特征，狗繼承了動物對象的特點，但是又有自己獨有的屬相和行為。圖是很多有 關系的事物的組合，用戶、分析人員和測試人員一般使用用例視圖進行描述系統需求。 UML 的圖分類靜態模型和動態模型。靜態模型記錄一個系統的靜態特征，動態建模 主要用于展示系統的動態行為集［14-15］。
2.5本章小結
本章主要介紹了執法記錄信息管理系統的基本知識和相關技術。首先介紹了執法 記錄儀和采集站的基本知識和特點、執法記錄儀與采集站之間的接入方式以及數據采 集系統的功能特性，然后對系統采用的 B/S 架構進行闡述，通過對比了 B/S 架構與 C/S 架構的區別，分析總結 B/S 架構的優點。介紹 Bootstrap 框架，它是目前比較流 行的 Web 前端開發的框架，最后對系統設計過程中采用的 UML 統一建模語言進行描 述。
第三章 交警執法記錄信息管理系統的需求分析
軟件需求分析需要開發人員深入了解交警日常工作的業務流程，站在用戶的角 度，完全理解用戶對軟件的需求，是項目軟件開發的重要階段。本章首先通過調查分 析目前交警執法過程中存在的問題，然后分析交警的日常工作的業務流程，總結交警 執法記錄信息管理系統的功能性需求和非功能性需求，最后對系統的數據進行建模。
3.1 交警執法記錄信息管理系統的業務陳述
3.1.1交警執法存在的問題
交警部門的設立主要是為了維護我國的交通治安為題，一線的交警日常的工作大 多是在路面執勤，公安部門為每一位在外執勤的執法人員配備相應的執法記錄儀設 備，執法記錄儀采集的數據是交警執法辦案過程中的重要資料，作為執法辦案的重要 電子證據，應當嚴格地、規范地根據相關法律規定管理和使用這些電子證據，維護執 法辦案的真實性、可靠性、安全性。但是目前對這些資源的使用仍然存在著以下問題 [16]：
1.部分執法人員對執法記錄儀的使用不規范，執法部門缺乏相關管理制度。執 法記錄儀的使用情況沒有加入到執法人員的日常考核中, 不能利用視音頻數據對民 警辦案的規范性、合法性進行監督和考核，不利于量化的手段提升民警的辦案素質和 能力。
2.采集數據的使用過于隨意，無權限設置，存在巨大的安全漏洞，缺少集中的 信息化管理工具，不能有效利用執法記錄儀采集數據，保護民警和當事人的合法權益。
3.部分工作人員使用個人工作機存儲執法記錄儀采集的數據，無統一存儲管理 執法記錄儀數據的工具，導致執法數據的分散存儲，以及刪除、拷貝沒有統一規范化 管理，操作無審計，造成執法數據的泄漏、丟失和損壞等情況。
4.采集數據缺少與交警日常工作業務相互關聯的信息，辦案過程通常使用光盤 刻錄的方式作為辦案紙質卷宗提交和保存，辦案結果無記錄，執法單一，使用不方便， 無法檢索、統計和分析相關數據，不能和辦案的其他重要信息進行關聯，不能通過條 件進行查詢、瀏覽，形成一種信息孤島的現象，嚴重影響了采集數據的重要作用。
3.1.2交警執法的業務陳述
一線民警目前配備的交警執法記錄儀，交警利用執法記錄儀終端完成數據的采集 工作，主要數據包含拍攝發生的交通事故現場的視頻、音頻和圖片等數據，同時需要 將數據上傳到采集站上，完成數據的導入工作。為了民警能夠高效快速的完成數據導 入過程，應該盡量減少對執勤時間的占用或者減少對執勤的影響，然后在非上崗執勤 時間通過工作站或者PC上進行數據的處理。因此民警的業務功能包括數據的采集（導 入）、上傳、存儲、編輯、歸檔、刪除、導出、查詢、統計、報表等等。
為了實現對執法記錄儀的普遍使用以及對交警執法數據的集中管理，做到辦公智 能化、簡潔化、自動化的特點，開發了一套擁有系統管理、安全審計、權限管理等多 個功能模塊的綜合性執法記錄信息管理系統，可以有效地幫助支隊管理人員完成日常 的綜合業務。根據交警執法的業務分析，總結交警執法信息管理系統主要包括權限管 理、系統管理、執法監督、業務監督、監督考評、統計分析、日志管理、數據接收等 功能模塊。
該系統的主要的角色包括系統管理員、部門領導、普通用戶（交警），不同的角 色具有不同的權限，用戶能夠使用的業務也不同，只有系統管理員可以查看和使用所 有的業務［17-18］。
1.權限管理
權限管理主要是針對不同職位的交警設計的，完成系統的分級管理，不同角色的 人具有不同的權限。完成權限管理首先需要對系統功能頁面進行管理，然后才能添加 不同權限的用戶。系統需要對實現的功能模塊進行統一的管理，頁面管理主要是針對 交警執法記錄信息管理系統中的 Web 功能頁面進行管理，該功能主要展現系統設計 中的所有功能頁面，主要包含增加、刪除和更新的操作。權限分配主要是根據業務需 求，達到分級管理，根據用戶的權限分配其相應的職能，系統管理員可以通過該功能 實現權限的設置，主要包含角色的增加、刪除和更新權限設置操作。
2.系統管理
系統管理是交警執法記錄信息管理系統的基礎模塊，每一個信息管理系統都存在 自己的用戶，結合交警的日常需求，每個用戶屬于不同的部門，因此，系統管理主要 包括部門管理、用戶管理、執法記錄儀管理以及公告管理四部分的業務關系。四個功 能模塊有各自的功能性需求，部門管理主要包括部門的增加、刪除、更新和查詢功能， 部門之間存在著上下級關系，即為一級部門和二級部門，系統管理員和部門管理員具 有權限對此模塊進行操作。用戶管理包括用戶信息注冊、刪除、更新、查詢等操作， 根據業務需求還提供了賬戶的凍結以及解凍用戶功能，當賬號被凍結之后，該賬號在 解凍之前就不能再使用。執法記錄儀的管理是該系統的重要部分，新的執法記錄儀在 使用 之前， 需要預先在執法記錄儀根目錄新建 config.ini 文件， 其內容格式如 ID=66888,其中66888為該執法記錄儀的唯一編號，根據不同的執法記錄儀進行修 改，同時需要在交警執法記錄信息管理系統中添加該設備的設備編號和其他的設備屬 性，執法記錄儀管理包括執法記錄儀信息的錄入、更新、刪除以及查詢功能。
3. 執法監督
執法監督即對交警日常工作情況進行監督的業務模塊，通過日常監督、隨機抽查、 抽查記錄三方面進行監督，日常監督模塊將警員信息和采集的數據一一對應起來，利 用列表的形式直觀的顯示出來，用戶可以在此界面上查看采集到的數據源（圖片、視 音頻等數據），查看之后可以對數據進行信息標注、打分評價和執法關聯等業務操作， 用戶還可以根據自己的需求進行條件查詢；上級領導可以對警員采集數據的情況進行 日常抽查，從抽查的角度總結分析警員采集數據的情況。抽查記錄用于顯示所有被抽 查過的數據，提供利用關鍵字和時間范圍查詢功能。當需要查看交警日常工作中采集 的數據的時候，點擊日常監督，系統則會顯示相應的信息列表，用戶可以多字段查詢、 批量下載日常監督信息。當需要對警員日常工作進行抽查的時候，點擊隨機抽查模塊， 將頁面轉換到隨機抽查模塊，在抽查框中填入抽查的條數，系統會隨機抽取相應的條 數的數據并利用列表的形式顯示出來。如果需要查看抽查過的警員信息，則點擊抽查 記錄頁面，同時可以根據部門或者警員編號進行查詢。
4.業務監督
業務監督主要是針對警務人員一些執法業務管理，主要包括執法查處、事故處理、 路面執勤和車輛管理。執法查處記錄發生的事故的一些后期處理結果，用來管理執法 對象對于每次執法過程的投訴和反饋情況，主要包含添加、查詢以及導出功能，用于 事后審查等工作。執法查處處理的結果需要一些視音頻支持，事故處理是將執法結果 與相關的視音頻圖片等非結構化數據進行連接，可以查看顯示事故現場的非結構化數 據。路面執勤提供了對交警路面執勤記錄進行搜索和查看功能；交警部門中的所有車 輛需要在在系統中進行登記，主要包括該車輛的車牌號和所屬部門，包含的功能有車 輛信息的增加、修改、刪除和查詢等功能，當交警工作過程中需要配備車輛的時候， 需要申請配備車輛，因此該功能模塊包括車輛的配備和結束用車的功能。
用戶進入業務監督功能模塊對交警執法業務進行管理，當警員需要錄入執法過程 信息時候，點擊執法查處，點擊添加，填寫相關的執法信息，點擊保存，如果想要查 詢或者導出執法查處信息，點擊相應的功能即可。當需要查看相關的事故處理數據源 的時候，點擊事故處理功能模塊，可以查看事故處理結果，還能夠根據條件查詢事故 處理結果。每個交警部門都有自己的公用車輛，當需要添加車輛信息的時候，進入車 輛管理功能模塊，點擊添加車輛信息，填寫相關信息，點擊保存，則添加成功，可以 根據條件查詢車輛信息，查看車輛的使用情況。
5.使用監督
使用監督主要是針對交警日常工作中的電子設備的使用情況進行監督的功能模 塊，包括部門監督和使用異常兩個功能模塊。部門監督用于以部門為單位對執法記錄 儀的使用、備用數量和報損數量進行統計，對采集站的使用、備用數量和采集站的容 量進行統計。執法記錄儀采集到的數據也有異常的情況，使用異常模塊用于統計執法 記錄儀使用異常的詳細情況。用戶可以查看部門監督和設備使用異常情況。當需要導 出相應的信息時，點擊導出按鈕，選擇保存路徑，點擊保存，設備的使用情況將會以 表格的形式保存在硬盤上。
6. 監督考評
監督考評從專項考評、考勤考評和攝錄考評三個方面對警員的工作情況進行監督 考評。按照交警隊要求，每次執法過程必須錄像取證，如果沒有達到要求則要對相應 執法人員扣分，專項考評用于查詢和顯示各個支隊或者部門的執法人員扣分情況以及 搜索和顯示每個執法交警的執法情況考評打分結果和所攝錄視頻的時長；信息標注用 于對執法交警攝錄執法視頻的分類標注，對每一個標注信息設置基礎的分值，提供每 段視頻滿足其他功能所需的查詢條件的功能。交警隊需要考核每個執法人員的出勤 率，考勤考評則是從警員出勤時間、采集視頻總數對警員進行考評。攝錄考評用于搜 索和顯示每個交警執法攝錄的視頻總數和總視頻長度。考勤考評則是根據攝入視頻的 時間判斷交警的考勤情況，然后計算該交警的考勤考評是否達到標準。專項考評主要 是對每個部門的綜合考核，包含日常檢查、標注事件、執法無視頻 3 個方面的總體扣 分和平均扣分情況，最后計算出總體的扣分情況。
專項考評模塊，則會查看各個部門的考評情況。當需要進行評價打分的時候，點 擊評價打分管理按鈕，系統轉入到評價打分頁面，對打分評價進行管理。專項考評模 塊內，用戶可以對信息標注進行管理，點擊信息標注管理按鈕，頁面轉入信息標注管 理頁面，用戶可以根據業務需求設置相應的標注信息。如果需要查看考勤考評和攝錄 考評的時候，點擊相應的頁面則會顯示考評的結果，對其結果具有查詢和導出的功能。
7. 統計分析
統計分析是針對交警執法記錄信息管理系統中涉及的警員、采集數據和執法記錄 儀進行集中的統計，主要包括信息統計、趨勢圖、趨勢對比圖、警員信息統計和部門 信息統計五個功能模塊的數據的統計。信息統計則是按照部門或者支隊，在指定的時 間段內對所有執法記錄進行統計和顯示，統計內容包括設備使用量、警員人數、執法 標注類型、事故處理數、視頻總時長等；趨勢圖則是根據搜索條件，圖形化顯示指定 時間段內某個部門攝入的數據總數信息；趨勢對比圖則是以部門為單位，直觀的顯示 最近一年內每個部門攝錄的執法數據視音頻數據總數的折線圖；部門統計同樣以部門 為單位，統計每個部門的總人數、攝入圖片、視音頻數據的總數、執法記錄儀數量、 標注率等相關信息進行統計。警員統計信息則是以警員為中心，對每位警員的攝入圖 片、視音頻總數等與警員相關的數據進行統計。
用戶在此模塊可以根據條件查詢采集數據的總體情況、部門、警員的統計報表， 審查業務的數據和總結分析趨勢報告等。當需要查看某位警員采集數據的情況，點擊 查看警員信息統計模塊，可以對該警員日常工作總體情況進行分析和總結。如果想要 站在部門的角度，查看部門的日常工作情況，則點擊部門統計信息模塊，系統將以列 表的形式顯示部門統計信息。點擊趨勢圖，選擇需要查看的部門，系統將通過折線圖 直觀的顯示該部門最近上傳數據的情況。點擊趨勢對比圖，選擇查看需要查看的最近 一年的數據類型（視頻，音頻，圖片），系統顯示出來每個部門采集數據的折線圖。
8. 日志管理 日志管理主要從系統日志、執法記錄儀日志和采集站日志三個方面對系統的日志 進行管理。用于搜索和查看管理員賬號登錄系統的操作日志、數據錄入和數據查看記 錄、執法記錄儀設備的使用記錄，方便后期對系統操作行為的追訴和審計。
進入到系統日志模塊，頁面上將會清楚的顯示出系統的相關日志，同時可以根據 查詢條件，查看和導出相應的日志。當系統需要升級的時候，點擊版本管理按鈕，增 加版本，瀏覽文件的位置，點擊添加，則添加成功。進入采集站日志或者執法記錄儀 日志頁面，輸入查詢條件，點擊查詢，可以快速的查出相關的信息，同時可以點擊導 出按鈕，導出相關的日志信息。
9. 文件服務器數據接收模塊 數據采集系統將執法記錄儀上面的視頻、音頻和圖片等數據導入到采集站上，然 后實現數據的轉存和上傳功能，但是采集站上已經上傳的數據會進行定期清理和刪 除，所以需要一個文件服務器對數據進行統一的管理，該文件服務器掛載磁盤整列， 大約190多T,能夠存儲大量的數據，數據接收模塊主要是接收數據采集系統在空閑 時間內發送的視音頻圖片數據、警員信息以及執法記錄儀信息，然后將接收到的圖片、 視音頻數據保存在文件服務器上，將相應的警員信息、執法記錄儀信息和接收到的視 音頻文件的屬性記錄在交警執法記錄信息管理系統的數據庫中，數據接收模塊實現將 采集系統上傳的數據的轉存與管理，是交警執法記錄信息管理系統的數據源 。
該系統的主要的角色包括系統管理員、部門領導、普通用戶（交警），不同的角 色具有不同的權限，用戶能夠使用的業務也不同，只有系統管理員可以查看和使用所 有的業務功能模塊［17-18］。普通用戶的活動圖如圖 3.1 所示。用戶首先需要輸入用戶名、 密碼和驗證碼，驗證成功之后，進入系統。如果輸入的賬號、密碼或者驗證碼錯誤， 則系統會提示登錄失敗。登錄成功之后，系統會查詢該用戶的權限，然后根據權限， 顯示權限內的功能模塊，普通用戶可以使用的功能包含系統管理中的用戶管理和執法 記錄儀管理、業務監督、監督考評、執法監督、使用監督、查看統計數據，交警退出 系統結束所有的活動。
系統管理員是該系統同權限最大的用戶，相比于普通用戶增添了權限管理、發布 公告、日志管理、部門管理等多個活動。系統管理員可以根據業務的需求對不同的人 進行權限設置。系統管理員的活動圖如圖 3.2 所示。系統管理員首先需要輸入用戶名、
密碼和驗證碼，驗證成功之后，進入系統。如果輸入的賬號、密碼或者驗證碼錯誤， 則系統會提示登錄失敗。登錄成功之后，系統會查詢系統管理員的權限，然后根據權 限，顯示權限內的功能模塊，系統管理員可以使用的功能包含系統管理、業務監督、 監督考評、執法監督、使用監督、統計分析、權限管理等多個功能模塊，系統管理員 退出系統，結束所有的活動。
圖 3.1 系統管理員活動圖
圖 3.2 普通用戶活動圖
3.2 交警執法記錄信息管理系統的需求建模
3.2.1 功能性需求
交警執法記錄信息管理系統主要是針對使用執法記錄儀中的數據的統一管理，包 含對案件的處理、數據的集中管理、人員的考察等多個功能點，用戶可以進行增加、 刪除、修改、查詢、導入、導出等功能性操作［19-20］。用例模型是用來描述系統中的用 例和參與直接之間的關系，并指出參與者參與的用例執行情況。交警執法記錄信息管 理系統的參與者主要包括系統管理員、部門管理員、普通用戶（警員），實現了系統 的分級管理，三者對系統的總體用例圖如圖3.3所示：
圖中普通用戶的用例包含登錄、監督考評、執法監督、業務監督、使用監督和統 計分析等，部門管理員和普通用戶之間是泛化關系，包含了普通用戶的所有用例，還 包含權限管理和日志管理的用例，系統管理員的權限最大，系統管理員和普通用戶之 間也存在泛化的關系，系統管理員包含了普通用戶的所有用例，同時還具有公告管理、 權限管理、日志管理的用例。
1. 系統管理
系統管理模塊主要分為四個功能點，部門管理、用戶管理、執法記錄儀管理以及 部門管理。用戶管理主要是針對管理所有的警務人員信息，警務人員在使用該系統的 時候需要有自己的賬號信息，并通過注冊的賬號信息進行登錄使用。而該賬號的來源 則是通過系統管理員進行統一注冊，同時錄入警務人員的基本信息。系統管理員可以 通過用戶管理界面注冊用戶，查看所有用戶、更新用戶信息，刪除用戶賬號以及凍結 用戶賬號等操作。同時針對部門管理、執法記錄儀和公告管理進行相應的增加、刪除、
修改、查詢操作。用例圖如圖 3.4 所示：
管理等用例，部門管理員和普通用戶之間是泛化關系，部門管理員具有普通用戶的所 有用例，部門管理員還具有部門管理的用例，系統管理員和普通用戶之間也存在泛化 的關系，具有普通管理員的所有用例，系統管理員還具有公告管理和部門管理的用例。
2. 日志管理
部門管理員可以查詢和導出用戶的操作日志、執法記錄儀日志和采集站日志。部 門管理員還具備對系統的版本的管理，系統版本管理包括系統版本的增加、刪除、修 改用例。普通用戶沒有使用該模塊的功能權限，系統管理員和部門管理員是泛化管理，
3. 權限管理 權限管理主要是由權限管理和頁面管理兩個部分，系統管理員能夠對權限管理模 塊中的角色進行增加、刪除以及修改的用例，對系統頁面管理模塊也具有相同的用例。 系統增加了功能模塊需要在頁面管理中進行添加，添加完成之后可以對用戶進行權限 分配。用例圖如圖 3.6 所示：
普通用戶包含查看趨勢對比圖、趨勢圖的用例，還有具有查詢和導出統計信息的 用例，部門管理員和普通用戶之間存在著泛化關系，具有普通用戶的所有用例，還具 有查詢和導出警員統計信息的用例，系統管理員和普通用戶也是泛化關系，包括普通 用戶的所有用例，同時具有查詢、導出部門警員統計信息的用例和查詢、導出部門統 計信息的用例。統計分析用例圖如圖3.7所示：
5. 監督考評
監督考評主要包含專項考評、攝錄考評、專項考評三個部分，普通用戶包含的用 例為查看和導出專項考評、考勤考評、攝錄考評的用例，同時因為考評的需要，還包 含評價打分管理、信息標注管理的用例。評價打分管理和信息標注都具有增加、刪除、 修改、的操作。系統管理員和部門管理員都與普通用戶之間存在泛化關系，所以部門 管理員和系統管理員都具有相同的用例。監督考評用例圖如圖3.8所示：
所有用戶可以查看每個部門的相關情況，可以快速查詢和了解想要查看的部門相 關信息，同時還設有導出的功能。使用異常主要是針對執法記錄儀采集到的數據的一 些不合法數據的統計，主要也包括查詢和導出信息用例。使用監督用例圖如圖3.9所 示：
7. 業務監督
業務監督包含執法查處、事故處理、路面執勤、車輛管理四個部分的業務需求， 普通用戶包含執法查處、事故處理、路面執勤、增加、刪除、修改、查詢車輛信息、 分配車輛和結束用車的用例，執法查處、路面執勤和事故處理還包含執法結果的錄入、 查詢和導出用例，系統管理員和普通用戶存在著泛化關系，部門管理員和普通用戶之 間也存在著泛化關系，所以系統管理員和部門管理員都包含著普通用戶所有的用例。 業務監督用例圖如圖3.10所示：
8. 執法監督
系統管理員和部門管理員都與普通用戶存在泛化的關系，因此所有的用戶具有執 法監督包含的所有權限。執法監督包含日常監督、查看抽查記錄和隨機抽查三個部分， 普通用戶具有批量下載日常監督信息、刪除日常監督信息、查看資料源、查詢日常監 督信息、查看抽查記錄和隨機抽查用例，查看數據源和評價打分、信息標注和關聯執 法單號用例存在擴展的關系。執法監督用例圖如圖3.11所示：
3.2.2 非功能性需求
1.界面設計方面，系統在設計開發時，需要充分考慮用戶的具體情況及使用操作， 不但要理論上可行，更重要的是實際上可用，更好地適應用戶需求。
2.兼容性方面，Web界面的設計需要具有很好的兼容性，能夠支持現在流行的瀏 覽器，同時還需要具有很好的自適應能力，能夠支持不同分辨率下的有效、正常運行。
3.系統安全方面，系統平臺需要通過嚴格的流程與權限控制，做到嚴格審核與分 配系統權限，嚴禁未經許可的用戶訪問和操作。
3.3 系統的數據建模
信息管理系統則主要指的是對數據庫中的數據對象的存儲，以及對數據對象進行 的增加、刪除、修改、查詢等相關的基本業務操作。采用實體關系（E-R）圖對交警 執法記錄信息管理系統的數據庫進行建模。 E-R 圖是通過實體、屬性和聯系的方法 來描述現實世界中的事物，從而建立系統的概念模型。實體指的是利用概念來抽象的 表示具有相同屬性的一組事物的所有實例，實體包括人、地點、對象、事件、概念等， 每一個實體有存在自身的特點，當需要保存這些實體的特性的時候，那么就需要確定 想要存儲關于給定的實體的相關特性數據，這些數據被稱為屬性。在現實生活里面， 每個實體與另外一個實體之間存在著某種聯系，利用聯系來表示兩個屬性之間的關 系。根據交警執法記錄儀信息管理系統的業務需求，以及業務的進一步細化，分析數 據建模過程中所需實體的E-R圖［21-22］。由于篇幅所限，這里只介紹系統中比較重的 實體的概念結構設計。
1. 用戶表
用戶表主要用來存儲用戶的基本信息，它的屬性包括用戶賬號、密碼、職務、手 機號、用戶姓名、、警員編號、注冊時間、狀態、角色、性別、郵箱、備注等。 用 戶表的 E-R 圖如圖 3.12 所示：
圖 3.12 用戶表 E-R 圖
2. 部門表 部門表用來存儲系統的部門信息，它的主要屬性包括部門名稱、部門編號、上級 部門。部門表的 E-R 圖如圖 3.13 所示：
圖 3.13 部門表 E-R 圖
3. 執法記錄儀表 執法記錄儀表示用來存儲設備信息的表，它的主要屬性包括硬件序列號、制造廠 商、是否備用、備注。執法記錄儀表的 E-R 圖如圖 3.14 所示：
4. 權限管理表 權限管理表主要是用來管理創建用戶權限的表，主要屬性包括權限名稱、權限內 容、權限角色。權限管理表的 E-R 圖如圖 3.15 所示：
圖 3.15 權限管理表 E-R 圖
5. 文件表
文件表是用來存儲接收來的數據信息的表，主要屬性包括文件名稱、文件大小、
文件類型、文件開始時間、文件結束時間、下載時間、文件路徑、文件總時長等。文
件表的 E-R 圖如圖 3.16 所示：
6. 執法記錄儀日志表 執法記錄儀日志表用來存儲用戶對執法記錄儀的相關操作日志，主要屬性包括執 法記錄儀編號（硬件序列號）、操作時間、操作類型、警員姓名、警員部門。執法記 錄儀日志的E-R圖如圖3.17所示：
根據對系統的業務分析，系統中設計的表還包括有日常監督表、抽查記錄表、部 門監督表、使用異常表、評價打分、信息標注、公告管理表、頁面管理表、車輛信息 表、系統升級表等，由于篇幅所限，這些表的概念模型就不詳細描述。
下面對上述的實體的關系進行分析和總結，用戶和數據（文件）兩個實體是執法 記錄信息管理系統中的兩個主要實體，其他的一些實體都是圍繞著交警日常的相關業 務展開的。一個用戶具有一種權限，一種權限類別可以分配給多個用戶，用戶信息表 和權限表是一對多的關系，一個用戶只能屬于一個部門，但一個部門由多個用戶組成， 所以用戶表和部門之間存在著一對多的關系。一個部門可以有多臺車輛，一臺車輛只 能屬于一個部門。文件表的屬性比較多，將文件的清晰度和類型分開兩個表進行存儲， 則一個文件只能屬于一種文件類型，一種文件類型包含多種文件，文件類型和文件表
屬于一對多的關系，同時文件的清晰度和文件表的關系也是一對多的關系。根據分析 結果畫出該系統的 E-R 圖如圖 3.18 所示：
圖 3.18 系統總體 E-R 圖
3.4 本章小結
本章主要針對交警執法記錄信息管理系統的需求進行了分析，首先對交警執法記 錄信息管理系統的業務進行描述，通過活動圖對系統中各個模塊的業務流程進行描 述。然后通過用例圖分析交警對系統的功能性需求。最后，通過利用E-R,對系統進 行數據建模。
第四章 交警執法記錄信息管理系統的設計與實現
本章首先介紹了交警執法記錄信息管理系統的架構設計，然后設計并完成交警執 法記錄信息管理系統數據庫的物理結構，最后分別介紹了系統管理、日志管理、統計 分析等模塊的功能進行了詳細設計與實現方法。
4.1 交警執法記錄信息管理系統的架構設計
4.1.1交警執法記錄信息管理系統的物理架構設計
交警執法主要包括三部分，即數據采集站，服務器集群，以及操作終端［23］。本系 統的物理架構如圖 4.1 所示：
圖 4.1 系統物理架構圖
數據采集站主要負責外勤民警執法數據的轉存和上傳。白天民警佩戴執法記錄儀 上崗，錄制執法數據，下班收工后，將執法記錄儀接入數據采集站，數據采集系統讀 取執法記錄儀上錄制的視頻、圖片等文件，將這些文件轉存到數據采集站，然后在指 定時間內與多媒體文件服務器連接，將采集站上的數據上傳到多媒體文件服務器上， 保存到多媒體文件服務器上，同時將警員等其他相關的信息寫入到執法記錄信息管理 系統的數據庫。
服務器集群包括數據上傳服務器、主多媒體文件服務器、備用多媒體文件服務器、 主數據庫服務器、備用數據庫服務器、WEB服務器等。數據上傳服務器主要負責上 傳采集站上的數據，多媒體文件服務器負責將這些數據進行分類，保存到多媒體文件 服務器和數據庫中。多媒體文件服務器主要保存執法過程中攝錄的音視頻和圖片文件 等非結構化數據，為了安全起見，多媒體服務器主備并行工作。數據庫服務器主要保 存執法記錄、民警信息、部門信息等結構化數據。 WEB 服務器部署后臺管理系統， 提供執法數據的遠程管理功能，系統管理員、支隊領導、民警可以通過該系統對執法 數據進行查詢、分析等工作。
操作終端包括系統管理員操作終端、民警操作終端、支隊領導操作終端等，通過 公安內網訪問執法數據信息管理系統，對執法記錄進行查詢、標注等。
4.1.2交警執法記錄信息管理系統的邏輯架構設計
交警執法記錄信息管理系統平臺由物理層、網絡層、數據采集層、應用支撐層、 系統應用層、信息展示層等組成。本系統邏輯架構如圖 4.2 所示：
信息展示層
內部網站
網絡層
LAN
物理層
運算資源 存儲資源 外部設備
圖 4.2 系統邏輯架構圖
1.物理層：提供主機、存儲等物理資源，為系統平臺提供硬件支持。
2.網絡層：負責主機（服務器）和終端、不同主機間網絡的互聯互通，為平臺 與平臺之間的數據網絡發布、傳輸提供基礎。
3.數據采集層：負責執法記錄儀音頻、視頻以及圖片數據的采集與整理。
4.應用支撐層：提供執法記錄數據庫、多媒體文件系統、統計數據庫為系統應 用層提供支撐。
5.系統應用層：由執法數據采集系統、執法記錄信息管理系統、以及外部數據 交換模塊組成。執法數據采集系統負責將執法記錄儀錄制的音視頻及圖片數據上傳到 系統后臺數據庫和多媒體文件系統中。執法記錄信息管理系統向各級領導、民警、系 統管理員提供系統應用服務，包括登錄認證、系統管理、權限管理、執法監督、業務 監督、使用監督、監督考評、信息標注、統計分析、日志管理、設備管理等多個功能 模塊。外部數據交換模塊負責與公安“六合一”平臺進行數據之間的交互和共享。
6.信息展示層：由網站、監控中心等組成，負責信息的發布、顯示及管理［24-26］。
4.2 系統數據庫設計
4.2.1 數據庫表結構設計
根據交警執法記錄信息管理系統的業務以及功能分析，交警執法數據庫主要存儲 以及管理的數據包含用戶管理、業務監督、日志分析等多個模塊過程中產生的數據、 交警執法記錄上傳到采集站的數據、用戶信息以及車輛信息等。根據第三章中設計的 數據庫概念模型（E-R圖），將概念模型中的E-R圖轉換為MySQL的數據模型，對 每個實體創建一個表，對每個實體的屬性創建一個字段，設置每個屬性的約束條件以 及數據類型，指定每個實體的主鍵、外鍵和索引等信息， 最終實現數據庫的物理結 構設計［31-32］。結合項目設計中的具體情況，數據庫的設計主要利用第三方數據庫管理 工具，完成數據庫表的設計與實現，導出項目中涉及到的相關數據庫表結構如下所示， 由于文章篇幅限制，下面只列舉出幾個相對重要的基本表。
1. 信息標注表
信息標注的主要字段包括id,類型，分數。Id屬性為自動增長型，該字段為該表 的主鍵，用來標志數據的唯一性，類型屬性和分數屬性在排序規則 utf8_general_ci， 不區分大小寫。信息標注的詳細表結構如表4.1所示：
表 4.1 信息標注表 tb annotation
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
annotation_number varchar(40) utf8_general_ci YES null
annotation_type varchar(40) utf8_general_ci YES null
2. 執法記錄儀信息表
執法記錄儀信息表的主要屬性包含id、用戶id、部門id、設備編號、設備名稱、 存儲時間、廠家、狀態。Id為自動增長型，設備表為混合型主鍵，由id和設備編號 組成，部門id、用戶id為外鍵。設備表的具體表結構如表4.2所示：
表 4.2 執法記錄儀信息表 tb device
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
user_id int(11) (NULL) YES 0
department_id int(11) (NULL) YES 0
device_number varchar(40) utf8_general_ci NO PRI null
device_name varchar(30) utf8_general_ci YES null
storage_time Timestamp (NULL) YES (NULL)
enterprise_name varchar(50) utf8_general_ci YES null
reason_callback varchar(90) utf8_general_ci YES null
Status varchar(20) utf8_general_ci YES null
Remark varchar(90) utf8_general_ci YES null
3. 文件質量信息表
文件質量表的主要屬性包括id、文件類型id、文件質量。Id為自動增長型，為 文件質量表的主鍵,文件類型 id 為外鍵。文件質量表的具體表結構如表 4.3 所示：
表 4.3 文件質量信息表 tb file quality
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
file_type_id int(11) (NULL) YES 0
file_quality varchar(20) utf8_general_ci YES null
4. 文件信息表
文件信息表的主要屬性包含id、文件名稱、設備id、文件類型id、文件質量id、 用戶id、部門id、標注id、文件大小、下載時間、開始時間、結束時間、總周期、文 件路徑。Id為自動增長型，為該表的主鍵。設備id、文件類型id、文件質量id、用
戶id、部門id、標注id為外鍵和索引。文件表的具體結構如表4.4所示:
表 4.4 文件信息表 tb file
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
file_name varchar(50) utf8_general_ci YES null
device_id int(11) (NULL) YES MUL 0
file_type_id int(11) (NULL) YES MUL 0
file_quality_id int(11) (NULL) YES MUL 1
user_id int(11) (NULL) YES MUL 0
department_id int(11) (NULL) YES MUL 0
annotation_id int(11) (NULL) YES MUL 0
file_size varchar(20) utf8_general_ci YES null
file_uploadTime Timestamp (NULL) YES (NULL)
file_startTime Timestamp (NULL) YES (NULL)
file_endTime Timestamp (NULL) YES (NULL)
file_totalPeriod varchar(20) utf8_general_ci YES null
file_path varchar(100) utf8_general_ci YES null
file_score_evaluation varchar(200) utf8_general_ci YES null
evaluation_type_id varchar(40) utf8_general_ci YES null
Remark varchar(100) utf8_general_ci YES null
5. 用戶信息表
用戶信息表主要屬性包括id、角色id、部門id、賬戶、密碼、警員編號、用戶姓 名、性別、信息錄入者、注冊時間、標題、退出時間、登錄編號、狀態、備注、電話 號、手機號。 Id 為自動增長型，用戶表的主鍵為混合型主鍵，由 id 和賬號組成， id 和賬號同時具有唯一性，其中角色id、部門id是外鍵。賬號和角色id分別為索引。 用戶信息表的具體結構如表4.5所示:
表 4.5 用戶信息表 tb user
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
role_id int(11) (NULL) YES MUL 0
department_id int(11) (NULL) YES 0
Account varchar(30) utf8_general_ci NO PRI null
Password varchar(30) utf8_general_ci YES null
police_number varchar(45) utf8_general_ci YES null
user_name varchar(10) utf8_general_ci YES null
Gender varchar(8) utf8_general_ci YES null
Creater varchar(10) utf8_general_ci YES null
create_time Timestamp (NULL) YES (NULL)
logout_time Timestamp (NULL) YES (NULL)
login_count int(11) (NULL) YES 0
Status varchar(10) utf8_general_ci YES null
Remark varchar(100) utf8_general_ci YES null
phone_number varchar(45) utf8_general_ci YES 0
person_number varchar(45) utf8_general_ci YES 0
6.文件類型信息表
文件類型表的主要屬性包括id、文件后綴、類型名稱。Id為自動增長型，是文件 類型表的主鍵。文件類型表的具體表結構如表 4.6 所示：
表 4.6 文件類型信息表 tb file type
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
file_suffix varchar(20) utf8_general_ci YES null
file_type varchar(20) utf8_general_ci YES null
7. 部門表
部門表的主要屬性包含id、部門名稱、部門編號、上級部門、是否存在、部門等 級、備注、上級部門id。Id為自動增長型，部門表為混合型主鍵，由id和部門名稱 組成。部門表的具體表結構如表 4.7 所示:
表 4.7 部門表 tb department
Field Type Collation Null Key Default
Id int(11) (NULL) NO PRI (NULL)
department_name varchar(30) utf8_general_ci NO PRI null
department_number varchar(20) utf8_general_ci YES null
parent_name varchar(30) utf8_general_ci YES null
if_valid int(11) (NULL) YES 0
department_level varchar(20) utf8_general_ci YES null
Remark varchar(100) utf8_general_ci YES null
parent_id int(11) (NULL) YES 0
4.2.2 數據庫總體結構設計
系統采用MySQL數據庫，利用Workbench數據庫管理工具，對系統的表結構進 行詳細設計，結合項目設計與實現過程中的實際情況，設計完成之后，將Workbench 里面的表結構導出，導出后的交警執法數據庫的部分表格總體結構如圖 4.3 所示:
圖 4.3 交警執法數據庫總體設計圖
4.3 系統功能模塊的設計與實現
交警執法記錄信息管理系統包括登錄認證、系統管理、執法監督、業務監督、使 用監督、監督考評、信息標注、統計分析、日志管理、權限管理等十個功能模塊。具 體功能模塊圖如圖 4.4 所示，由于圖片限制，只畫出了部分功能模塊。
交警執法記錄信息管理系統
圖 4.4 系統功能模塊圖
登錄模塊主要是系統的入口，權限管理模塊、評價管理模塊和信息標注模塊等 模塊是業務需求中的基本模塊，功能點主要是對基礎數據的增刪改查，這些功能點在 其他模塊中也有涉及，設計思路也相同，所以就沒有進行詳細的介紹。下面利用類圖 序列圖以及流程圖對系統中幾個重要的設計與實現進行詳細介紹［27-30］。
4.3.1 系統管理模塊
系統管理模塊主要包括的類有用戶類、部門類、執法記錄儀類等，系統管理模塊 的類圖如圖 4.5 所示：
User 類是一個用戶信息類，類里面定義了用戶信息的基本屬性和方法，方便對 用戶信息的操作, 中 User 類的屬性只寫了一個 id 屬性的 get 和 set 方法。部門和用戶 之間是聚合關聯關系，其他的虛線帶箭頭的均表示依賴關系。
Department 類是一個部門信息類，部門信息類里面包括部門的所有屬性以及各個 屬性 get 和 set 方法，圖中 Department 類的屬性只寫了一個 id 屬性的 get 和 set 方法。
Notice 類是一個通告信息類，通告類里面包括通告的所有屬性以及各個屬性 get 和 set 方法，圖中 notice 類的屬性只寫了一個 id 屬性的 get 和 set 方法。
Device 類是一個執法記錄儀信息類，執法記錄儀信息類里面包括執法記錄儀的所
有屬性以及各個屬性 get 和 set 方法，圖中 Device 類的屬性只寫了一個 id 屬性的 get 和 set 方法。
DepartmentServlet 類、 NoticeServlet 類、 DeviceServlet 類、 UserActionServlet 類 繼承了 HttpServlet 類， 主要處理用戶的動態請求，響應客戶端請求，主要包括用戶 信息、部門信息、通告信息、執法記錄儀信息的增加、刪除、更新等請求函數，以及 用戶信息的凍結和解凍的操作請求函數。本文中的 Servlet 類均繼承了 HttpServlet 類。
ManageServlet 類實現了信息復合搜索的功能，客戶端可以通過部門名稱和警員 編號實現對用戶信息的查詢。通過部門名稱查詢部門的詳細信息，通過發布人、標題 以及時間對通告的具體內容符合進行查詢，對執法記錄儀詳細信息的查詢條件主要包 括部門名稱、警員編號、設備狀態和時間等進行復合查詢。
DB類封裝了連接數據庫的方法，實現對數據庫的操作，封裝了對用戶信息、部 門信息、通告信息以及執法記錄儀信息的查詢、增加、刪除、更新操作的函數，查詢 分為通過 id 查詢和警員編號查詢等方法。本文中 DB 里面封裝的函數比較多，圖中 沒有一一列舉出來， DB 里面主要封裝的函數還包括， 所有的處理用 戶 請求 processRequest()函數中與數據庫的所有交互的函數，圖中統一只寫了 insert。、find()、 query。、update()四個函數為代表。
基礎數據的增加、刪除、查詢和修改等工作。以添加用戶為例，在添加用戶之前需要 先添加部門信息作為預設置，用戶需要在用戶管理的界面上點擊“添加”按鈕，然后進 入用戶添加的界面交互頁面，填寫用戶信息和用戶所在部門信息，點擊添加按鈕，則 添加用戶成功。管理員通過 WebInterface 發出 request 消息， departmentServlet 會調用
show_department()函數，然后向DB查詢部門信息名稱列表，DB將查詢到的部門信 息放入到ArrayList內返回給show_department()函數，show_department()函數將返回 的ArrayList數據進行處理，通過JSON字符串返回給界面，最后通過JavaScript技術 實現數據的解析，將信息通過 Web 界面顯示出來部門名稱列表，管理員選擇該用戶 的部門信息后，添加用戶的其他信息，然后再次向UserActionServlet發出請求，然后 通過調用add_user()函數進行處理該請求，add_user()調用DB的insert()方法，insert。 調用User內封裝的get方法，將用戶填寫的信息分別寫入到數據庫中，完成用戶信息 的插入，返回插入成功的消息。其序列圖如圖 4.6 所示:
4.3.2 監督考評模塊
監督考評模塊功能主要的操作主要是針對交警執法記錄儀數據管理系統中的部 門和警員考評情況，主要從日常檢查扣分、標注事件得分數、執法無視頻三個方面考 察警員的得分情況，該模塊還包含了評價管理的增加、刪除、修改、查詢操作以及專 項考評、考勤考評和攝錄考評的查詢和導出操作。監督考評類圖如圖4.7所示:
Supervise_examinationServlet 類是專項考評信息復合搜索的響應類，用于以部門 為單位，對日常檢查，標注事件、執法無視頻等情況的分數的統計，顯示各個部門的 專項考評信息列表以及通過部門名稱和時間對考評信息進行查詢的響應類。
Attendance_manageServlet 類是針對警員考勤考評的復合搜索的響應類，對每一
位警員采集的視頻總數進行計算，并進行考勤評判，顯示每個警員的考勤信息列表以 及通過部門名稱、警員編號和時間對考評信息進行查詢的響應類。
Video_examinationServlet 類針對警員攝錄考評的復合搜索的響應類，對每一位警
員采集的視頻總數和視頻總長度進行計算。顯示每個警員的攝錄視頻信息列表以及通
過部門名稱、警員編號和時間對考評信息進行查詢的響應類。
ExcelServlet 類用于導出專項考評、攝錄考評和考勤考評信息，該類除了封裝了 處理請求的processRequest()函數以外，還包含generateFileName()函數和download() 函數。
DB 類封裝考勤考評、攝錄考評和考勤考評數據的顯示方法。
圖 4.7 監督考評類圖
以專項考評為例，導出專項考評信息序列圖如圖 4.8 所示，用戶進入專項考評頁
面 ， 系 統 首 先 會 向 Supervise_examinationServlet 類 發 送 請 求 消 息 ， Supervise_examinationServlet 類內封裝的 processRequest()方法，處理頁面的請求，調 用DB模塊內的query()方法，查詢出需要計算專項考評的相關數據，返回給 processRequest()方法，processRequest()方法內封裝了計算專項考評數據的分數，最后 返回給前端，前端將數據信息解析出來并顯示。
圖 4.8 導出專項考評信息序列圖
4.3.3 業務監督模塊
業務處理模塊主要是針對業務監督模塊中的執法查處和事故處理兩部分，利用類
圖描述交警日常業務處理模塊的詳細設計，類圖如圖 4.9 所示：
圖 4.9 執法查處類圖
Law_enforcement類是執法信息類，包括執法信息的所有屬性以及get和set方法, 上面的類圖中只寫了 id 的 get 和 set 方法。
Law_enforcementServlet 類是處理執法查處的請求與響應類，用于顯示執法查處 信息列表以及通過部門名稱、警員編號、執法編號、執法類型和時間條件的復合條件 搜索請求響應類。
ExcelServlet 類適用于導出執法查處信息的類。
Add_law_enforceServlet 類是處理執法查處增加的請求與響應類，當請求添加執 法信息的時候，接收請求數據，響應請求的結果。
Accident_solveServlet 類是處理事故處理的請求與響應類，用于顯示事故處理列 表以及通過部門名稱、警員編號和時間進行復合查詢請求響應類。
DB 類封裝了插入執法信息的方法，將需要增加的執法信息數據寫入到數據庫中。 封裝執法查處信息和事故處理信息數據的顯示方法。
車輛管理模塊的類圖如圖 4.10 所示，該類圖主要是針對業務監督模塊中的車輛
管理和路面執勤情況進行監督，利用類圖描述車輛管理模塊的詳細設計。
圖 4.10 車輛管理類圖
Car類是車輛信息類，包括車輛信息的所有屬性以及get和set方法，上面的類圖 中只寫了 id 的 get 和 set 方法。
Car_manageServlet 類是處理車輛復合搜索的響應類，用于顯示使用車輛情況以 及通過部門名稱、車牌號、車輛使用狀態和時間多個條件的復合條件搜索響應類。
ExcelServlet類用于導出執法查處信息的類。
Car_manageActionServlet類車輛管理的響應類，封裝了車輛信息的增加、刪除、 更新的方法，同時封裝了分配車輛和結束用車的方法。
Road_dutyServlet 類是處理路面執勤的響應類，用于顯示路面執勤信息列表以及 通過部門名稱和時間進行復合查詢警員路面執勤情況的響應類。
DB類封裝了車輛信息錄入，刪除、更新的數據庫操作方法，車輛信息和路面執 勤信息數據的顯示方法以及車輛信息和路面執勤信息的顯示方法。
業務監督模塊的車輛管理設計的流程圖如圖 4.11 所示，用于在車輛管理頁面點 擊添加車輛，系統跳轉到添加車輛界面，然后填寫車輛信息，點擊保存，系統會自動 調用 car_manageAction Servlet 類中的 add_car_manage()方法，在 add_car_manage()方 法中將會調用數據庫中的query_car_number_add()方法，判斷車牌號碼是否重復，如 果數據庫中存在添加的車牌號，則用戶界面返回車牌號已存在，添加失敗，否則調用 DB類中的insert_car_manage()方法，將車輛信息插入到數據庫中，返回添加成功消息。 車輛信息添加成功之后，可以查詢可以使用的車輛信息，用于警員分配車輛。輸入查
詢的條件，點擊頁面中的查詢信息，調用 car_manage Servlet 類， car_manage 類中封 裝了處理根據輸入查詢的條件的請求，連接數據庫查詢車輛信息，調用 DB 類中的 show_car_manage()方法，將數據顯示在Web頁面上。點擊分配警員用車，系統將會 彈出添加警員用車信息界面，填寫警員信息和用車時間，點擊提交，系統則會向 car_manageAction Servlet發送請求，通過調用 update_car_manage()方法，實現具體的 分配車輛功能。
圖 4.11 車輛管理設計流程圖
4.3.4 統計分析模塊
系統的統計分析模塊主要通過以圖形或者列表的方式，直觀的將信息顯示給用 戶，方便用戶進行條件查詢和分析，方便領導對工作在做出總結以及為領導的決策提 供依據。該系統主要是通過對比分析法、趨勢分析法對數據進行分析，通過統計出來 的數據計算標注總數、標注率、管事率、執法記錄儀啟用率等多個指標，領導可以根 據統計及計算出來的指標，分析考核警員的總體情況。類圖如圖 4.12 所示：
Get_chars_totalVideo 是執法記錄儀攝入情況的趨勢對比響應類，根據客戶端的請 求，以時間為橫軸動態的顯示每個部門攝入的所有某種類型媒體信息的總數，利用 Highchats 插件實現將每個部門采集的數據總數顯示出來，利用折線圖直觀的顯示出 來，不同顏色的折線圖代表不同的部門。
Get_totalReportServlet 是執法數據的趨勢圖響應類，按照部門分類，根據條件查 詢，顯示指定時間段內某個部門每個月采集某種數據類型的數量。
Statics_userServlet 是警員報表的響應類，統計每一個警員執法數據的個數和業績 情況，計算出每個警員采集數據的標注總個數、標注率、管事率等信息，并將統計和 計算的信息傳送給前端，警員可以通過部門名稱、警員編號和時間對統計信息進行查 詢。
Statics_departmentServlet 是部門數據報表響應類，以每個部門為單位，統計各個 部門的媒體攝入情況，計算出每個部門媒體攝入的標注總個數、標注率、管事率等信 息，顯示每個部門相關的具體信息列表，警員可以通過部門名稱和時間對統計信息進 行查詢。
Statistic_infoServlet 類是對數據管理系統中與業務相關的原始數據的統計響應 類，主要是以部門為單位，統計出來各個部門基本信息、執法信息和媒體攝入情況， 顯示每個部門相關的具體信息列表，可以通過部門名稱和時間對統計信息進行查詢。
ExcelServlet 類用于導出信息統計報表、部門統計報表和警員統計報表。
DB類封裝了趨勢對比圖、趨勢圖、統計信息、部門數據報表和警員數據報表的 顯示方法。
統計分析模塊功能主要是針對交警執法記錄儀數據管理系統中的部門、警員與數
據和設備之間的一種關系的總體統計，包括統計信息、警員、部門統計報表的查詢與 導出操作和以部門為單位的統計分析折線圖。以趨勢對比圖為例，用戶發出查看最近 一年采集數據的視頻數據的趨勢圖， Get_totalReportServlet 類里面封裝的 processRequest()方法，調用DB里面的show_totalReport()方法，查詢同一個部門一年 內的視頻文件，存放在Map表中，返回給processRequest。，processRequest()將返回 的數據進行處理計算，返回給前端，前端利用Highchats插件，實現趨勢對比圖的形 象化顯示。趨勢對比圖序列圖如圖 4.13 所示：
圖 4.13 查看趨勢對比圖序列圖
4.3.5 日志管理模塊
日志管理模塊是對系統操作日志等信息的記錄，利于后期的追訴和審計工作，類 圖如圖 4.14 所示：
System_updateServlet 類是上傳系統升級包的響應類,將升級的系統版本上傳到服 務器上，記錄.exe文件上傳的時間以及版本號。
System_updateServlet 類是刪除系統升級版本的響應類。
Law_recorder_logServlet 類是處理執法記錄儀日志響應類，記錄警員對執法記錄 儀的操作日志，顯示執法記錄儀日志信息，可以通過部門名稱、警員編號和時間對執 法記錄儀日志信息進行查詢。
Data_device_logSerlet 類是處理采集站的日志響應類，記錄采集站的相關信息， 顯示采集站日志信息，可以通過部門名稱和時間對采集站日志信息進行查詢。
System_log_manageServlet 類是處理系統日志的響應類，記錄每一位登錄者的操 作日志，顯示出登錄者的基本信息以及操作，顯示系統日志信息，可以通過部門名稱、
警員編號和時間對采集站日志信息進行查詢。
ExcelServlet 類用于導出系統日志、采集站日志和執法記錄儀日志。
DB 類封裝了執法記錄儀日志、采集站日志、系統日志的顯示方法。
圖 4.14 日志模塊類圖
以版本升級為例，用戶請求刪除版本信息，前端頁面調用利用 JavaScript 編寫的 delete()函數，發出請求，System_updateServlet類中封裝了處理前端頁面請求的方法, 調用DB內封裝的delete()函數，刪除請求刪除的版本信息，其刪除版本信息序列圖 如圖 4.15 所示：
圖 4.15 版本升級序列圖
4.3.6 執法監督模塊 執法監督模塊包括日常監督模塊類、批量下載類等，類圖如圖 4.16 所示：
Daily_supervisionServlet 類是查詢和顯示日常監督的響應類，用于顯示監督信息 列表以及通過部門名稱、警員編號、標注類型、媒體類型和時間等多個條件的復合查 詢響應類。
FileActionServlet 類是刪除日常監督信息的響應類，客戶端請求刪除某條監督信 息，該類中封裝了根據id刪除該文件的方法。
Downloadtozip 類是批量下載日常監督信息的類
Random_checkServlet 類是日常抽查響應類，客戶端輸入抽查的條數，該類中編 寫了處理該請求的方法，顯示出抽查內容列表。
Check_recordServlet 類是處理抽查記錄的響應類，用于顯示抽查記錄列表以及通 過部門名稱、警員編號和時間等多個條件的復合查詢響應類。
DB類封裝了日常監督刪除信息的方法，日常監督、日常抽查和抽查記錄信息數 據的顯示方法以及批量下載的路徑方法。
yHttpServlet
首先警員點擊日常監督頁面，向 Daily_supervisionServlet 類發出請求，該類中 封裝的processRequest()方法，processRequest()方法調用數據庫中的查詢方法，查詢日 常監督需要顯示的數據，然后返回給processRequest()方法，該方法將數據庫返回的 數據進行處理，然后通過JSON字符串傳送給前端，前端頁面將數據呈現出來。如果 警員需要查看日常監督數據源，則需要向查看數據源發送請求消息， getPath Servlet 類中封裝了通過數據庫查詢file表中的物理路徑，然后返回給界面，界面將根據路徑
加載查看數據源文件。數據文件查看完成之后可以對文件進行評價打分、查看媒體信 息、信息標注和關聯信息等操作，交警發出關聯信息的請求之后， add_data_rel ation Servlet 處理添加執法關聯的請求， add_data_relation Servlet 中封裝的方法首先需 要查詢該數據有沒有關聯執法單號，如果關聯執法單號，則會提醒用戶已經關聯執法 單號，如果沒有，則關聯執法單號成功。日常監督模塊中的關聯執法單號功能設計實 現流程圖如 4.17 所示：
4.3.7 文件服務器數據接收模塊
數據接收模塊的主要類包括文件接收類、TCP連接類、線程類等，類圖如圖4.18 所示：
FileReceiver 類是用于接收文件的響應類，里面封裝了三個方法，通過在初始化 過程中創建線程實例。
TCPServer類里面封裝了兩個函數，一個自身的構造函數，另外一個是handler() 方法，該方法創建了 TCPServerThread實例，利用start()方法啟動線程。
TCPServerThread 類實現了 Runnable 接口，重寫了 run()方法，創建了 socket 實 例，用于接收文件數據。
TCPResponseThread類同樣實現了 Runnale接口，重寫了 run()方法，具體處理接 收到的數據，調用DB中的方法。
Fileinfo類是文件數據類，包括文件數據的所有屬性以及get和set方法，上面的 類圖中只寫了 file_name的get和set方法。
DB 中封裝了將接收到的數據插入到數據庫中的方法。
圖 4.18數據接收類圖
數據接收模塊的設計流程圖如圖4.19所示，主要通過Java的Socket編程實現客 戶端與文件服務器之間的數據傳輸，FileReceiver Servlet類中封裝了 ini方法，該方法 中首先定義了用于連接數據庫的各個變量，創建一個TCPServer類的實例tcps，將定 義的變量作為參數傳給 tcp， tcps 實例調用 TCPServer 類中 handler 方法， Handler 方 法創建線程 Thread。 TCPServerThread 類承了 Runnable 接口，重寫 Runnable 的 run 方法，在 run 方法中創建 socket 線程，指定客戶端的端口號，連接客戶端。通過調用 TCPResponseThread 類的實例，該類同樣重寫的 run 方法， run 方法主要用于將讀取 接收客戶端傳輸的結構化數據和非結構化數據，將接收到的非結構化數據保存在文件 服務器中，文件的命名方式是執法記錄儀編號加上接收時間加上數據類型，同時連接 交警執法記錄信息管理系統的數據庫，將相關的文件信息、警員信息和執法記錄儀信
息寫入到數據庫中。
圖 4.19 數據接收模塊設計流程圖
4.3.8 系統子模塊集成
系統各個模塊之間的模塊集成主要是通過接口管理的，設計并實現各個功能模塊 之后，通過統一建模語言的類圖對各個模塊之間的交互關系進行描述，包含模塊之間 的交互邏輯和系統運行過程中的數據交互過程，交警執法記錄信息管理系統的總體類 圖如圖 4.20 所示，由于圖片大小限制，圖中通過類圖詳細介紹了幾個直接參與業務 的主要類，其中包含兩個基本的實體數據類。用于注冊警員信息和用戶登錄的 User 類， department 類則是用于對警員的信息進行分組的類，每個警員都有各自的部門信 息，所以警員類和部門類之間屬于聚合關系， Role 類則是用于權限分配，不同級別 的用戶可以通過權限設置選擇不同的業務。一個人具有一種權限。filelnfo類和device 類是交警執法信息管理系統的基礎數據和核心數據類。交警圍繞執法數據產生的業務 功能實體類包含執法查處類law_enforcement，考勤考評類attendance、系統操作日 志類system_log、車輛信息類car。該圖只列畫出了 6個業務模塊的類交互關系及重 要屬性。
Fileinfo：文件實體類，是該系統的核心數據類，文件服務器模塊接收到的數據包
含采集數據的警員編號和文件信息，將接收到的相關文件信息分離寫入到數據庫中， 是數據管理的核心業務處理類，其他的業務都要圍繞該數據進行相關處理，用戶可以 對文件的質量進行評價打分和信息標注業務操作。同時還可以通過瀏覽器查看文件的 數據源信息，包含視音頻、圖片等文件的播放功能。
Device：設備實體類，是系統管理模塊的核心業務處理類，該類的主要功能是提 供登記設備信息，交警在執勤過程中利用執法記錄儀電子設備進行執勤，在使用之前 需要對執法設備信息進行注冊，設備中有唯一的設備編號，根據設備的硬件唯一編號 序列區分設備，在該系統中可以對設備的使用情況進行統計，主要操作包括設備信息 的增加、刪除、修改和查詢。
需 getldO ： mt
setldO : void
圖4.20系統總體類圖
System_log：操作日志實體類，是日志模塊的核心業務類，類的主要功能是記 錄系統的操作日志，主要包含操作人，操作的內容，備注等信息，用于對系統的審計 工作，主要包含操作日志的查詢和導出。日志模塊還包含執法記錄儀日志和采集站日 志。
Attendance :考勤考評類，是監督考評模塊的核心業務處理類，類的主要功能是 以警員為單位，顯示警員姓名、部門名稱、考勤開始時間和結束時間、采集視頻總數、 考勤得分等信息，該模塊通過統計調用數據庫的數據，進行多表的聯合查詢，對警員 采集的視頻信息和考勤考評信息進行統計。主要包含考評考勤信息的查詢和導出操 作。
Check_record :抽查記錄實體類，是執法監督模塊的核心業務處理類，類的主要 功能是記錄被抽查過的警員信息情況，部門領導可以對警員采集的數據進行抽查，從 而考察警員采集數據的情況，因此抽查記錄與fileinfo和user類之間存在著依賴關系， 抽查人選擇抽查警員的個數，被抽查到的警員信息和文件信息就會記錄在抽查記錄當 中，主要包含抽查記錄的復合查詢操作。
Law_enforcement：執法查處實體類，是業務監督模塊的核心業務處理類，用于 類顯示執法查處信息列表，主要包含的信息有執法交警、當事人姓名、當事人車牌號、 執法地點、執法類型等數據，通過調用警員信息接口，記錄執法查處信息，包含的主 要操作有添加執法查處信息、修改執法查處信息、查詢執法查處信息。警員添加執法 查處信息以后，可以在日常監督模塊內，對相應的執法數據源添加執法關聯信息，執 法結果和采集到的執法數據就會相互關聯起來，警員可以通過事故處理頁面查看執法 單號相互關聯的數據源信息。
4.4 本章小結
本章主要完成對系統的詳細設計與實現，首先從物理架構設計和系統架構設計兩 個方面對系統的架構設計進行詳細的描述，然后對系統地數據庫進行詳細的設計與實 現，主要包括數據庫表結構的設計和數據庫的總體結構設計圖，最后通過類圖、序列 圖和流程圖對系統中的各個功能模塊的設計與實現做了具體的介紹。
第五章 交警執法記錄信息管理系統測試
軟件測試是軟件開發生命周期的一個非常重要的一部分，軟件設計與開發完成之 后都是可能產生錯誤的，因此需要對開發的軟件進行反復的測試，盡量通過測試審查 的方式發現并且糾正軟件中的錯誤［33-34］。
系統測試需要大量的測試數據，執法記錄儀終端、數據采集系統、執法記錄信息 管理系統三者之間的互相協作的，測試交警執法記錄信息管理系統的業務功能需要有 幾個預設置，首先需要對執法記錄儀的配置文件進行設置，編寫該執法記錄儀的編號， 其次登錄交警執法記錄信息管理系統注冊警員信息、部門信息和執法記錄儀信息，數 據采集系統遠程讀取注冊的執法記錄儀信息和用戶信息，然后執法記錄儀接入到數據 采集系統中，數據采集系統將執法記錄儀采集的數據存儲到采集站上，文件服務器的 數據接收模塊遠程接收數據采集系統發送過來的執法記錄儀數據。系統操作流程圖如 圖 5.1 所示：
圖 5.1 系統操作流程圖
該系統是在Windows7操作系統下進行測試，具體的軟硬件需求以及配置情況如 下：
1.該系統運行的網絡環境是公安內網，通過公安內將各個服務器之間聯系起來。
2.數據采集系統，該系統為執法數據記錄信息管理系統提供數據源。
3.Web服務器和文件服務器安裝JDK7.0以及執法Tomcat8服務器，提供軟件 運行的軟件環境。
4.數據庫服務器安裝MySQL5.8以及數據庫管理工具Workbench軟件。
5.執法記錄儀，用于采集執法數據。
PC終端的配置要求：
硬件要求：CPU: Intel 酷睿 i3 540 (4M Cache,3.06GHz, 2.5GT/s)以上；內存：16GB 以上；硬盤： 1TB；
軟件要求： Windows7 以上版本；
5.1 測試內容
本節采用黑盒測試方法，按照用戶的功能性需求和非功能性需求兩個方面，對系
統進行測試，驗證系統能否交付。測試的內容如表5.1所示：
表 5.1 測試內容表
測試類型 測試內容 測試目的 測試方法
功能 用戶登錄、系統管理模 塊、權限管理、執法監 督、業務監督、使用監 督、監督考評、信息標 注、統計分析、日志管 理等。 根據用戶需求，使用該系統同， 檢驗能否正常使用所有的功能 點。
1.業務流程檢驗：各個流程滿足 用戶需求，使用沒有疑問。
2.數據正確性：各種輸入輸出數 據計算準確。 黑盒測試、手工 測試、邊界值測 試、等價類劃分 等測試方式
用戶界面 鏈接、頁面結構包括菜 單、背景顏色、字體、 按鈕、標題、提示信息 一致性、正確性等。 檢測網站風格符合設計要求，能 夠保證用戶界面友好型，易操作 性，符合大眾的操作習慣。 手工測試
安全性和訪
問控制 密碼、權限設置、登錄
超時限制 檢測用戶權限，核實用戶只能操 作權限以內的業務，長時間沒有 操作的安全限制。 黑盒測試、手工
測試
兼容性 利用不同版本的瀏覽器
訪問系統、例如火狐、
IE8.0、Google 等瀏覽器。 核實系統在不同的瀏覽器中的 使用情況，檢測系統的兼容性。 黑盒測試、手工
測試
5.1.1 功能性測試用例和結果
1. 系統登錄
登錄測試主要是為了檢測系統的登錄功能能否正常使用。測試列表如表5.2所示：
表 5.2 系統登錄功能性測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 系統登錄 輸入正確
的數據 輸入用戶名 admin 輸入密碼 admin 輸入正確的驗證碼 登錄成功 通過
2. 輸入錯誤
的數據 輸入錯誤的用戶名
輸入密碼
輸入正確的驗證碼 輸入用戶名錯 誤，登錄失敗 請檢驗輸入 用戶名和密 碼、登錄失敗
3. 輸入錯誤
的數據 輸入正確的用戶名 輸入錯誤的密碼 輸入正確的驗證碼 輸入密碼錯 誤，登錄失敗 請檢驗輸入 用戶名和密 碼、登錄失敗
4. 輸入錯誤
的數據 輸入正確的用戶名 輸入正確的密碼 錯誤的驗證碼 輸入的驗證碼
錯誤 驗證碼錯誤
測試結果：系統登錄測試通過。用戶可以通過用戶名、密碼和驗證碼登錄系統。 如果有輸入錯誤或者沒有輸入的情況，系統會給出相應的提示。系統登錄測試保證軟 件數據安全性。
2. 系統管理 系統管理主要包括對用戶管理、部門管理、執法記錄儀、公告管理四個部分的增 加、刪除、修改、查詢操作以及數據顯示的正確性測試，測試在進行操作過程中每一 步是否具有提示信息，提示信息是否正確，系統在測試添加用戶信息之前，管理員需 要先測試添加部門信息和權限信息，然后才能夠測試添加用戶，賬戶不能夠與已經注 冊的賬戶重復，否則注冊失敗。當系統中已經存在的部門信息發生變更的時候 ，可 以對變更的部門信息進行修改，修改成功之后，注冊用戶的所屬部門也會發生對應的 變化。部門信息中也存在上下級的關系，當上級部門信息發生變化時，對下級部門也 會產生相應的影響，對上級部門進行修改之后，下級部門的相關信息也會發生變化。 以用戶管理為例，對用戶管理模塊的功能性測試做詳細的介紹。系統管理模塊其他的 功能性測試詳細結果如表 5.3 所示：
表 5.3 系統管理模塊測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 用戶管理 添加用戶信息 點擊添加用戶信 息，在添加用戶信 息頁面上填寫信 息，點擊添加 用戶信息添加成
功 同預期結果 執行結果如 圖5.2
2. 更新用戶信息 點擊更新按鈕，在 彈出的信息列表 中 修改需 要更改 的信息 修改成功 同預期結果
3. 刪除用戶信息 點擊需要刪除用 戶信息的刪除按 鈕 刪除成功 同預期結果
4. 凍結用戶 點擊凍結按鈕 賬號的狀態轉變
為無效，解凍之
前賬號不能使用 同預期結果
5. 解凍用戶 點擊解凍按鈕 賬號由原來的無
效轉換為有效，
能夠正常登錄 同預期結果
6. 查詢用戶信息 選擇不同的條件， 點擊查詢按鈕 顯示正確的查詢
信息 顯示正確的
查詢信息
7. 部門管 理、 執法 記錄儀管 理、 公告 管理 部門信息、執法 記錄儀管理、公 告管理的增加、 刪除、更新、查 詢功能 在對應功能界面 上進行操作，具體 步驟與用戶管理 相應的功能點步 驟相同 部門信息、執法 記錄儀管理、公 告管理的增加、 刪除、更新、查 詢功能沒有異常 同預期結果 結果如圖
5.3
圖 5.2 用戶管理界面實現圖
圖 5.3 更新部門管理測試圖
3. 執法監督
執法監督主要包括日常監督、隨機抽查和抽查記錄三部分，測試執法監督模塊的 前置條件需要從采集站上接收采集到的數據，對警員和數據進行日常監督，當數據庫 中存在警員信息和數據的時候，測試隨機抽查功能的正確性，對于抽查過的數據通過 抽查記錄進行記錄，測試抽查記錄的前置條件則是已經進行過隨機抽查。具體測試項 如表 5.4 所示：
表 5.4 執法監督模塊測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 日常監督 查詢監督信
息 選擇查詢的條件
(部門和媒體類
型)，點擊查詢按鈕 顯示正確的查詢信
息 同預期結果
執行結果如
圖5.9
2. 刪除信息 點擊刪除按鈕 刪除成功 同預期結果
3. 批量下載信 息 1.選擇需要下載的
信息
2.點擊下載按鈕 下載成功 同預期結果
4. 查看資料源 點擊查看，查看資 料 可以查看資料源數 據，能夠進行打分 評價、信息標注、 關聯信息的操作 同預期結果
5. 隨機抽查 查看抽查信 息 輸入抽查的條數(5) 顯示相應條數的抽
查信息 同預期結果
執行結果如
圖5.4
6. 抽查記錄 查詢抽查記
錄 選擇查詢的條件，
點擊查詢按鈕 顯示正確的查詢信 息 同預期結果
4. 業務監督
業務監督主要包括執法查處、事故處理、路面執勤和車輛管理四個部分，具體測
試項如表 5.5 所示：
表 5.5 業務監督測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 執法查處 查詢 選擇查詢的條件 （部門），點擊查 詢按鈕 顯示正確的
查詢信息 同預期結果
2. 添加 點擊添加，填寫信 息，點擊添加 添加成功 同預期結果
3. 導岀 點擊導岀 成功導岀信
息 同預期結果
4. 事故處理 查詢事故處理
情況 選擇查詢的條件，
點擊查詢按鈕 顯示正確的
查詢信息 同預期結果
5. 路面執勤 查詢路面執勤
情況 1.選擇不同的條 件
2.點擊查詢按鈕 顯示正確的
查詢信息 同預期結果
6. 車輛管理 查詢用車信息 1.選擇查詢的條
件
2.點擊查詢按鈕 顯示正確的
查詢信息 同預期結果 執行結果如 圖5.5
7. 錄入車輛信息 點擊錄入車輛信 息，填寫信息，點 擊添加 添加成功 同預期結果
8. 刪除車輛信息 點擊刪除按鈕 刪除成功 同預期結果
9. 更新車輛信息 1.點擊更新按鈕
2.在彈岀 的信息
列表中修改需要
更改的信息 修改成功 同預期結果
10. 分配車輛 點擊分配警員，選
擇分配警員編號 配車成功 同預期結果
11. 結束用車 點擊結束用車，填
寫時間 結束用車 同預期結果
5. 統計分析
統計分析主要包括統計信息、警員統計、部門統計、趨勢圖和趨勢對比圖五個部 分，具體測試項如表 5.6 所示：
表 5.6 統計分析模塊測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 統計信息 查詢統計信息 1.選擇不同的條 件
2.點擊查詢按鈕 顯示正確的查詢
信息 同預期結果
2. 導岀統計信息 點擊導岀 成功導岀信息 同預期結果
3. 警員統計 查詢警員信息
統計結果 1.選擇不同的條 件
2.點擊查詢按鈕 顯示正確的查詢
信息 同預期結果 實現結果如 圖5.7
4. 導岀警員信息
統計結果 點擊導岀 成功導岀信息 同預期結果
5. 部門統計 查詢部門統計
結果 1.選擇不同的條 件
2.點擊查詢按鈕 顯示正確的查詢
信息 同預期結果
6. 導岀部門信息
統計結果 點擊導岀 成功導岀信息 同預期結果
7. 趨勢圖 視頻統計趨勢
圖 點擊不同的部門 顯示該部門攝入
視頻的折線圖 同預期結果
8. 音頻統計趨勢
圖 點擊不同的部門 顯示該部門攝入
音頻的折線圖 同預期結果
9. 圖片統計趨勢
圖 點擊不同的部門 顯示該部門拍攝
圖片的折線圖 同預期結果
10. 趨勢對比圖 查看一年內攝
錄的視頻總覽 點擊查看一年攝
入的視頻 顯示岀各個部門 一年內攝入視頻 的折線圖 同預期結果
11. 查看一年內攝
錄的音頻總覽 點擊查看一年攝
入的音頻 顯示岀各個部門 一年內攝入音頻 的折線圖 同預期結果
12. 查看一年內拍
攝的圖片總覽 點擊查看一年拍
攝的圖片 顯示岀各個部門 一年內拍攝圖片 的折線圖 同預期結果
6. 日志管理 統計分析主要包括系統日志管理、版本管理、采集站日志、執法記錄儀日志四個
部分，具體測試項如表5.7所示：
表 5.7日志管理模塊測試表
編號 測試模塊 測試項 測試方法 預期結果 實際結果
1. 系統日志管
理 查詢系統日志 選擇查詢的條件
（交警一大隊），
點擊查詢按鈕 顯示正確的查
詢信息 同預期結果 執行結果如 圖5.8
2. 導岀系統日志 點擊導岀 成功導岀信息 同預期結果
3. 版本管理 增加版本信息 點擊添加，填寫
信息，點擊添加 添加成功 同預期結果
4. 刪除版本信息 點擊刪除按鈕 刪除成功 同預期結果
5. 查詢版本信息 點擊更新按鈕， 在彈岀的信息列 表中修改需要更 改的信息 修改成功 同預期結果
6. 采集站日志
管理 查詢采集站日志 選擇查詢的條 件，點擊查詢按 鈕 顯示正確的查
詢信息 同預期結果
7. 導岀采集站日志 點擊導岀 成功導岀信息 同預期結果
8. 執法記錄儀 日志管理 查詢設備日志 選擇不同的條 件，點擊查詢按 鈕 顯示正確的查
詢信息 同預期結果
圖 5.5 查詢車輛使用執行結果圖
5.1.2系統界面顯示測試用例和結果 系統登錄界面是該系統的入口，登錄界面如圖 5.6 所示：用戶在登錄狀態下長時 間沒有進行操作，系統岀于安全的考慮將會岀現身份重新驗證的消息，然后返回到登 錄界面重新登錄。
技術軸：昱舸技
圖 5.6 系統登錄界面
根據執法記錄儀數據管理系統的業務需求，系統的使用人員具有不同的權限，主 要分為系統管理員、普通用戶、部門管理員。權限不同，進行的操作也會不同，不同 角色的權限使用情況具體如表 5.8 所示：
表 5.8 角色模塊分配表
功能模塊名稱 系統管理員 部門管理員 普通用戶
執法監督
業務監督
使用監督
統計信息
趨勢對比圖
趨勢圖
警員信息統計
部門信息統計
系統管理
公告管理
日志管理
權限管理
不同的用戶分組，登入的界面不同，具體的權限主要通過左側的導航窗口直觀的 體現，用戶權限可以由系統管理員分配。下面分別測試不同權限的用戶登錄界面。
系統管理員是具有最大的權限，能夠使用系統的任何功能模塊，系統管理員登錄 系統后，右上角的賬戶信息顯示賬號為admin，權限為系統管理員，登錄界面如圖5.7 所示，由圖中的信息可以直觀的看岀，滿足系統需求設計的要求。
鼻證理棗詵日志
A
I o 和 EJtm
Hi+^tSf
M g 目期.
*»-***.
J5»-XR\
■R-55 E5
圖 5.7系統管理員查詢系統日志管理界面測試
部門管理員只能夠訪問自己所在的大支隊以及下屬支隊的部門的信息，不能跨部 門查看其它的信息和發布通告，右上角上用來顯示登錄系統的賬號信息，登錄界面如 圖5.8所示，圖中登錄系統的賬戶信息顯示賬號為test，權限為部門管理員的用戶,
由圖中的信息可以直觀的看岀，該用戶只能查看該部門（交警二大隊的相關信息）， 左邊的功能導航條只有部門管理員的相關功能，設計滿足系統需求設計的要求。
不能跨部門查看其它大隊和支隊信息的信息，同時不能查看系統的日志信息、權限管
理功能和發布通告，右上角的賬戶信息顯示賬號為test2，權限是普通用戶，登錄界
面如圖 5.9 所示，左面的導航條上只有對應的警員功能模塊，由圖中的信息可以直觀 的看岀，符合系統需求設計的要求。
交警執法記錄信息管理系統
* WiKfif
任WWK fntCT)
辟日期:
wfWESid^：1
圖 5.9 普通用戶查看日常監督功能界面測試
上面測試了系統的權限分配功能，符合設計要求。實際工作中，針對 Web 應用
程序，也就是經常說的 B/S 系統，可以從導航測試、圖形測試、內容測試、表格測試、 整體界面測試幾個方面倆進行用戶界面測試，由于篇幅所限，并且通過上面的權限測 試圖形可以直觀的看岀系統的整體界面風格，測試的詳細結果如表 5.9 所示：
表 5.9 界面測試結果
測試項 測試結果
整個系統的界面是否保持一致？ 整體風格統一、界面一致。
所有的界面展示的圖片樣式是否一致？ 所有的界面圖片一致。
每個頁面的提示字體的顏色、格式是否 每個頁面的提示顏色格式一致，符合設
統一準確？ 計要求。
操作是否友好？ 操作簡練，易操作。
界面所有的按鈕、下拉框是否有響應？ 按鈕、下拉框均正常。
界面中是否存在錯別字？ 無錯別字，符合設計要求。
所有的導航、鏈接是否正常？ 導航正常、鏈接正確、符合設計要求。
內容顯示是否正確？ 所有的查詢顯示數據正常。
界面中的提示說明敘述是否太啰嗦，字 界面的提示說明簡潔、一致，符合設計
體、顏色顯示格式是否一致？ 要求。
5.1.3 兼容性測試結果
由于現在的操作系統和瀏覽器越來越多，軟件需要具備很好的兼容性，能夠支持 在不同的瀏覽器上運行已經成為必須可少的需求，因此需要對系統的兼容性進行測 試，將交警執法記錄信息管理系統部署在硬件平臺上，兼容性測試主要是針對不同 的瀏覽器和分辨率進行的測試，測試結果如表 5.10 所示：
表 5.10 兼容性測試結果表
測試項 測試結果
瀏覽器測試 系統可以在 Firefox 、 Chrome 、 IE9.0 、 Opera 等 多個主流瀏覽器上正常運行。
分辨率測試 頁面版式在 640x400、 600x800 或 1024x768 的
分辨率模式下顯示正常。
5.2 測試結果分析
從系統的功能和非功能方面進行測試，測試結果表明，系統基本滿足了軟件設計 的要求，滿足了需求分析中的功能性需求，實現了對執法記錄數據的管理，包含有添 加、刪除、查詢、修改、導入、導出等數據操作功能。界面簡單易用、設計風格統一， 基本上支持主流的瀏覽器，用戶使用系統過程中，提供的相關操作相關的、委婉的、 一致的和可理解性的提示語。安全方面具有登錄限制，沒有注冊的用戶不能登錄，登 錄時間過長的用戶，再次使用需重新登錄，以防止信息泄露。
5.3 本章小結
本章主要對執法記錄信息管理系統的測試相關內容進行簡單介紹。首先，設計系 統各個模塊的功能測試用例，對系統各個模塊進行功能性測試。然后，從 Web 界面 實現的角度上，對系統的界面風格進行測試。最后，對系統的兼容性和界面進行測試。 經過多方面、全方位、反復性的測試，總結岀測試結果，系統滿足設計要求。
第六章 總結與展望
6.1 論文工作總結
交警執法記錄儀信息管理系統主要是圍繞交警利用交警執法記錄儀日常工作中 的數據進行系統化、集中化管理的軟件，主要包括數據采集站子系統和執法記錄管理 子系統，本文主要圍繞執法記錄管理子系統的設計與實現進行討論，同時簡單介紹了 與管理子系統僅僅相關的數據采集子系統。在設計初期，通過深入了解現階段交警日 常的工作以及各個部門之間的關系，研究分析了交警執法過程中的業務需求，總結系 統的詳細功能需求。利用軟件工程開發方法設計與實現系統的開發工作，整個系統的 開發過程包括業務需求分析、功能模塊的劃分、技術理論分析、具體的功能模塊實現、 數據庫的設計與實現以及系統的測試工作。
本文的主要工作詳細如下：
1.詳細介紹了選題的背景和意義。了解并介紹了國內外類似項目的研究現狀，介 紹本文項目相關的理論知識和相關技術，相關的理論知識主要包括交警執法記錄儀和 采集站的基本理論知識，相關技術主要包括 B/S 架構和項目分析設計階段用到的統一 建模語言（UML ）以及相應建模工具。
2.通過對項目的需求進行分析，劃分出各個功能模塊。從用戶的角度，利用統一 建模語言（UML）的用例圖，分析各個功能模塊中用戶對系統的需求用例，利用活 動圖展示用戶的工作步驟。通過分析系統業務需求過程中需要的實體，分析各個實體 的屬性，使用 E-R 圖對系統進行數據建模。
3.根據上述對系統的需求分析，利用類圖、序列圖和流程圖，詳細介紹各個功能 模塊的設計與實現方法。開發的主要技術采用B/S架構，利用HTML、CSS、avaScript、 Bootstrap 框架完成前端頁面的實現、利用 Servlet 技術，實現前后端的交互。詳細介 紹了數據庫表的物理結構，完成關系型數據庫的設計與實現。
4.在系統設計并實現的基礎上，完成對系統的綜合測試。首先介紹系統的運行的 軟硬件需求和環境部署，通過常用的測試方法，完成對系統的功能測試、界面測試、 兼容性測試等內容，分析測試結果，驗證系統的可用性。
6.2 后續工作展望
對于交警執法數據信息管理系統的設計、開發、測試工作已經基本完成，然而隨 著時間的變化、系統對系統的需求以及性能方面也會有不同的需求，系統還需不斷的 完善，具體的工作可以從以下幾個方面進行進一步研究：
1.采集站中存儲的數據會隨著時間的推移，數據量會逐漸增大，對信息管理系 統的數據庫的性能要求也會隨之增加，信息管理系統可以研究大數據庫系統、分布式 任務調度系統等實現視頻數據的大容量、高性能、故障自動檢測恢復等存儲特性等功 能，并且提供對視頻進行語義標簽、時間切片以及視頻摘要等關鍵性功能的支持，以 及基于海量標簽數據進行高速索引的搜索功能。
2.由于本系統主要是針對執法記錄儀數據和警員的統一化管理，所以對資料源 視頻播放僅僅滿足了功能需求，系統可以進一步研究系統中查看資料源視頻的播放功 能，提高更加穩定、功能更加齊全視頻的播放功能，使得用戶能夠更加公平、公正的 處理事務。
隨著科技的不斷發展，交警執法信息管理系統在投入使用的過程中可以不斷的完 善，提高對執法數據的自動化、透明化管理，為警員辦案提供更好的辦案平臺。
參考文獻
[1]公安部交管局《關于印發＜交警系統執法記錄儀使用管理規定＞的通知》(公交管 [2013]460 號).
[2]公安部交管局《交警系統執法記錄儀使用管理規定》.
[3]李兆功.西安公安交警執法問題與對策研究[D].長安大學,2014.
[4]賈培艷.利用執法記錄儀進一步加強隊伍建設[N].人民公安報•交通安全周刊,2013-09-17(001).
[5]劉健楠.公安現場執法記錄儀使用研究J].湖北警官學院學報,2013,(11):20-22.
[6]TCL亮劍——TCL攜執法取證整體解決方案J].中國安防,2015,(22):92.
[7]吳曉東.《交警執法記錄儀及后臺管理系統建設和應用要點》. 2014.
[8]交 警 系 統 執 法 記 錄 儀 設 備性能和后臺管理系 統 設 計參考要 點 _交宣. 甘肅科 技,2013,(23):22-23.
[9]梁衛,陳光晨.關于執法記錄儀在交警日常工作中的應用思考——以青島交警執法記錄儀信息 管理系統為視角[J].電子世界,2016,(10):58-59.
[10]崔乘剛.執法記錄儀及后臺管理設備方案技術解讀[J].道路交通管理,2014,(03):18-19.
[11]張原齊.基于B/S的交警隊績效考核系統的設計與實現[D].電子科技大學,2014.
[12]謝益輝，朱鈺.Bootstrap方法的歷史發展和前沿研究[J].統計與信息論壇,2008,(02):90-96.
[13]李金亮,李春青.基于Bootstrap的WEB開發設計研究[J].中小企業管理與科技(中旬 刊),2014,(05):217.
[14]喬鋼柱,曾建潮,郭銀章等.基于 UML/Power Designer 的信息系統分析方法. 電腦知識與技 術.2006(5):78-81.
[15]李波，楊弘平等.UML2基礎、建模與設計實踐[M].北京：清華大學岀版社,2014.
[16]趙池龍，姜義平等.軟件工程實踐教程[M].北京:電子工業岀版社,2007.
[17]曹通,吳旖旎.警用執法記錄儀使用效能及現存問題研究[J].云南警官學院學報,2013,(05):85-87.
[18]馬雙柱，孫瑩瑩.執法記錄儀在法警工作中使用現狀及反思[J].經營管理者,2016,(30):25 8.
[19]楊世欣.基于UML的面向對象建模方法的研究[J].現代電子技術,2010,(18):47-50.
[20]邵維忠，梅宏.統一建模語言UML述評[J].計算機研究與發展,1999,(04):2-11.
[21]王珊,薩師煊.數據庫系統概論(第四版)[M].北京:高等教育岀版社.
[22]劉甫迎,黨晉蓉.數據庫原理及 CASE 技術教程.北京:人民郵電大學岀版社.2005.
[23]溫昱.軟件架構設計[M].北京:電子工業岀版社.2012.
[24]Josh Juneau. Java Web Services[M].Apress:2013.
[25]樊振宇.深入理解SERVLET和JSP原理[J].電腦知識與技術,2011,(11):2570-2572.
[26]NODATORU(JP).Web server having function of Java servlet, method for updating Java program
and computer program [P].：US2004064822,2004-4-1.
[27]石晶,龔震宇.基于Java Servlet實現交互式Web應用[J].計算機工程,2001,(09):160-162.
[28]Vandana Pursnani. An introduction to Java servlet programming; FIRSTSERVLET[J]. Crossroads,2001,8(2):.
[29]池亞平，方勇.Servlet技術與應用方法[J].北京郵電大學學報,2003,(S1):137-139+143.
[30]Krill, Paul. Apache readies Tomcat Java servlet container upgrade[J]. Info World.com,2009,:.
[31]沈綺.淺談Web數據庫訪問技術[J].電腦知識與技術,2009,(18):4648-4649+4655.
[32]姚文江.Web數據庫訪問的安全性技術分析[J].計算機工程,2004,(S1):334-336.
[33]鄭文強.軟件測試基礎教程[M].北京:清華大學岀版社.2015.
[34]張坤.軟件測試基礎與測試案例分析[M].北京:清華大學岀版社.2014.
下一篇：沒有了
相關標簽:
