熱門論文
最新論文
公安交警勤務考核信息管理系統的 設計與實現
發布時間：2023-07-22 14:08
目錄
摘要 I
ABSTRACT III
插圖索引 V
表格索引 VII
縮略語對照表 IX
第一章 緒論 1
1.1研究背景及意義 1
1.2國內研究現狀 2
1.3主要研究內容 3
1.4論文章節結構 3
第二章 相關技術概述 5
2.1系統核心技術介紹 5
2.1.1J2EE 體系結構 5
2.1.2B/S 架構開發模式 5
2.1.3SSH開源集成框架 5
2.1.4MySQL 數據庫 6
2.1.5Tomcat 服務器 6
2.2本章小結 6
第三章 系統需求分析 7
3.1系統可行性分析 7
3.2整體需求分析 7
3.3系統用戶角色分析 8
3.4功能性需求分析 9
3.4.1系統信息管理 9
3.4.2考核信息管理 10
3.4.3考核情況查詢 11
3.5系統數據模型構建分析 13
3.6系統性能需求分析 14
3.7本章小結 15
第四章 系統詳細設計 17
4.1系統總體設計 17
4.1.1整體結構設計 17
4.1.2業務流程設計 18
4.2數據庫設計 19
4.2.1實體聯系設計 19
4.2.2數據表表結構 22
4.3系統模塊設計 25
4.3.1系統信息管理模塊設計 25
4.3.2考核信息管理模塊設計 28
4.3.3考核情況查詢模塊設計 30
4.4本章小結 32
第五章 系統實現與測試 33
5.1系統功能模塊實現 33
5.1.1系統信息管理模塊實現 33
5.1.2系統考核管理模塊實現 39
5.1.3考核情況查詢模塊實現 42
5.2系統功能模塊測試 44
5.2.1系統信息管理模塊測試 45
5.2.2考核信息管理模塊測試 45
5.2.3考核情況查詢模塊測試 46
5.3系統非功能測試 47
5.3.1性能測試 47
5.3.2兼容性測試 47
5.3.3人機界面測試 47
5.4測試結論 47
5.5本章小結 47
第六章 總結與展望 49
6.1總結 49
6.2展望 49
參考文獻 51
致謝 53
作者簡介 55
第一章 緒論
1.1研究背景及意義
在當前階段，在實踐中探索和運用信息化手段是提高公安機關戰斗力的主流途 徑，也是提升基層公安單位基礎工作水平的重要途徑［1］。近年來，由于地理條件限制， 貴州省大量城市的城區道路長度和道路面積年平均增加量很少，致使實際交通需求與 城區路網總容量之間的缺口日益擴大。同時隨著社會經濟的高速發展，大部分城鄉結 合部及城中村的改造施工提上日程使得城市交通壓力劇增、堵點多發，嚴重影響了居 民的日常出行。從現實情況來看我們過去陳舊的公安交通管理模式存在種種弊端，已 難以滿足與日俱增的交管工作需求，主要體現在：一是，缺乏科學的考核方式導致工 作模式粗放、管理措施實用性不足等問題，無法體現區域、崗位類別差異，警力部署 全憑經驗、缺乏科學性，沒有依托充分的數據分析作為支撐、沒有實用的軟件平臺進 行數據研判，工作措施的施行不能較好的解決現有社會矛盾，群眾滿意度難以提升； 二是，管理考核監督方式滯后于實際需求，過去投入大量警力人工收集工作數據計算 考核的方式耗費大量時間，也無法及時、準確的反映工作短板、體現管理盲區、無益 于領導決策，民警工作主動性日趨向弱、管事率及見警率長期處于較低水平，隊伍逐 漸產生惰性，只會按部就班地聽口令做動作，各項工作的推進和開展難以為繼，考核 方式形同虛設，民警無法準時掌握近期考核結果及時查漏補缺，長此以往也就對考評 成績不關注、不關心，考核初衷和管理效果背道而馳、考核機制體系形同虛設；三是， 激勵考核機制不夠健全，滯后的考核方式造成我們對“基層公安交管部門與中層干 部”、“中層干部與民警”、“民警與輔警”三對關系的監督力度不夠，長期養成的承包 制管理思維造成上層部門只負責將工作攤派給中層部門，而不會過多的關心中層部門 以下負責具體實施任務的民警個體，使得無法準確掌握實際情況，造成交管工作有“成 績”沒“成效”，表面上看各項工作蒸蒸日上，實際上民警在開展工作的過程中存在應 付及從眾心理，脫崗、坐崗現象依然存在。此外，部門與干部、干部與民警之間的考 核未全面掛鉤，也未建立切實有效的激勵機制，導致干部及民警在開展交通管理工作 過程中主觀能動性及集體榮譽感不夠強，養成了“個人自掃門前雪”、“一人吃飽，全 家不餓”的思想，民警“各自為政”無法形成合力、干部“得過且過”都是差不多先生。 因此，研究并開發一套科學、實用的考核管理系統，對于打破基層公安交管部門困局 迫在眉睫［2］。
基層民警的績效考核制度是新時期公安交通管理工作改革的一項內容，對于加強 新時期公安交通管理工作，服從服務于全面建設小康社會的戰略目標，具有非常重要 的意義。主要表現在：
在長期的公安工作實踐中，我們發現公安交通管理工作政策性強，工作完成情況 較難量化統計，在目標考核中難以通過分值準確描述民警工作數量和質量。實行平臺 系統自動化考核，確定了工作規范和標準，使得相同崗位間能夠橫向對比，不同崗位 間能夠縱向比拼，考核結果間的高低分值差異促進了民警間的相互學習。
對于基層道路交通管理部門，受益于規章制度與考評的掛鉤關聯，隊伍管理效果 得到較大提高；對于被管理對象——基層交通民警，由于績效考核在公開、透明的機 制下實施，工作積極性形成良性循環。通過對考核結果的獎罰運用，民警的職務行為 逐漸由散漫向規范轉變，組織向心力、隊伍凝聚力逐步得到加強，過去領導主觀評價 占主導的評價體系被數據分析體系取代，極大的激勵了民警的工作積極性。
1.2國內外研究現狀
近年來國內各省市公安交管部門為解決民警素質差異、超負荷工作、與時代要求 不適應等現狀對績效考核工作進行了不斷的探索、研究，通過查閱文件資料，實地考 察學習交流，現將其綜述如下。
貴州省交警總隊為進一步落實公安交警系統大數據考核評價工作責任，提高考核 評價工作的透明度和公信力，促進和規范全省公安交警系統大數據考核評價管理工作 制定了《貴州省公安交警系統大數據考核評價工作管理辦法》通過“貴州省公安交警 系統大數據考核評價系統”平臺對全省兩級公安交通管理部門（省級部門、市級支隊） 的工作效能進行網上考核評價［3］。以“大數據、云平臺”為支撐，以工作績效考核、等 級評定為核心，以表彰獎勵為主要手段，依托網考信息系統，應用科學的定性和定量 方法，對省、市兩級公安交通管理工作進行公平、公正、科學、高效的考核評價，著 力構建全省公安交警系統績效考評體系，全面提高全省公安交通管理警務實戰效能。
南昌交警支隊堅持民意導向，建立健全督導檢查機制，智慧考核打造考核平臺， 綜合評分，明確了交通秩序整治的重點，突出了交通事故預防工作，全面推進信息化 建設。考核數據系統自動生成，大隊能夠隨時可查目標完成情況，真正做到考核公平、 公正、公開［4］。
針對績效管理系統的研究，國外已經形成了較為完善的理論體系，并在一些企業 中得到了廣泛的推廣和實踐。國外學者認為：構建成功的績效考核系統關鍵在于認識 其目的是減少因主觀偏差造成評價有誤的影響。由于不同國家和區域的管理理念有所 不同同時受到地區文化的影響，表現在績效管理系統的實現上也有不少差異。對于資 質的關注是近年來興起的一種評估方式并被廣泛應用。除此之外，國外專家還融入心 理學研究，添加人格特征和能力趨向從而提高管理精度，通過績效管理軟件進行嚴格
的量化分析。
1.3主要研究內容
運用軟件設計的專業思維，選取公安交通管理勤務考核系統為研究對象，以解決 工作實際問題、提高工作效能為出發點，在充分調研現有基礎公安交通管理部門需求 的基礎上，運用計算機軟件工程的方法，實現公安交通管理勤務考核系統的基本應用。 從而解放更多的警力投入到一線執勤工作，提升部門管理水平，凝聚民警向心力，為 探索和實踐科學、高效的交管工作方式提供實踐經驗。
研究的內容主要如下：
一、 深入一線勤務部門做好需求調研，將能夠體現民警工作成效的數據進行梳理、 整合，做好系統需求設計，讓系統貼近實際，有較強的實用意義。
二、 實現考核項目在考核系統核算成績時的增、減調整功能，讓系統能夠實現部 分項目的自定義考核。
三、 利用系統將手工核算考核成績轉變為自動核算考核成績的高效特點，將考核 對象由部門延伸到民警個體，實現部門、干部、民警等各個類別考核對象能夠在系統 內分類排名。
四、 按照軟件分層設計的思維模式，把不同模型、視圖、控制器三個功能模塊進 行分離，為后續考核系統升級提供基礎。
1.4論文章節結構
論文的整體結構分為六個章節，各章的內容提綱如下：
第一章，緒論。對公安交警勤務考核信息管理系統設計、開發的背景和意義進行 闡述；
第二章，相關技術概述。對公安交警勤務考核信息管理系統用到的核心技術和軟 件：J2EE體系結構郵］、B/S架構開發模式I7】、SSH開源集成框架［8］、MySQL數據庫 ［9］［10］、 Tomcat 服務器［11］等進行介紹；
第三章，系統需求分析。對公安交警勤務考核信息管理系統的系統可行性、整體 需求、功能需求、非功能需求進行分析；
第四章，系統詳細設計。結合第三章的需求分析對公安交警勤務考核信息管理系 統的設計要求進行進一步闡述；
第五章，系統實現與測試。介紹系統模塊實現情況，通過測試對其進行總結分析； 第六章，總結展望。對系統設計和實現情況進行總結以及對后續工作的展望。
第二章 相關技術概述
2.1系統核心技術介紹
2.1.1J2EE 體系結構
J2EE是基于sun公司開發的Java2平臺，為便捷企業解決復雜問題的一種被廣泛 運用的體系結構，其主要用于企業級服務器服務和應用的創建，J2EE具備“一次編寫、 各處運行”等特點。
J2EE體系所提供的集成框架由于具備可行、可靠、可擴展等特征，使得應用開 發成本低廉、復雜性較低，加之其所囊括的組件、架構有通用的標準和規格，解決了 應用跨平臺難以兼容這一難題，所以該體系被廣泛使用。
2.1.2B/S 架構開發模式
B/S結構即瀏覽器/服務器模式，是一種得益于Web興起后從傳統的C/S模式發 展起來的新的網絡結構模式。在該結構中Web瀏覽器是其客戶端最主要的應用軟件。 B/S模式實現了客戶端的統一和開發維護的簡化，用戶PC和服務器只需分別安裝有 瀏覽器和數據庫管理軟件就能使用。B/S模式其結構具備可無限擴展的優點，它能夠 從單獨服務器和少量用戶的小型系統擴展成為擁有海量用戶的大型系統。B/S結構的 主要工作流程為：第一步，由Web客戶端發送請求，通過用戶在客戶端提交表單操 作，從而向服務器發送請求，等待響應；第二步，后臺服務器端在接收請求后進行處 理，并產生響應；第三步，服務器端把用戶請求的數據(圖片、音視頻文件、文本 文件等)返回給客戶端；第四步，由Web瀏覽器解釋執行，呈現用戶界面。
2.1.3SSH 開源集成框架
J2EE中有許多優秀的框架，但大多存在架構復雜、配置繁瑣等問題，這為業務 組件的移動帶來很多不便。正是由于這些弊端的存在，人們致力于開發更輕量、靈活、 便捷的框架，這些框架具有易維護、高內聚、高彈性的特點。在這些框架中又以SSH 和SSM 表現突出，SSH 框架是Struct2+Spring+Hibernate而SSM 是指的 Spring-MVC+Spring+MyBatis，而本論文所涉及的系統選擇的是SSH框架。在SSH 中，Struts負責控制控制邏輯關系、Spring負責解耦、Hibernate負責操作數據庫。
1、 Struct2［12］框架
Struts2是基于MVC設計模式［13］的一個Web應用框架，它實質上相當于一個 servlet，在MVC的設計模式中，Struts2是以控制器(Controller)的身份來建立模型與 視圖的數據交互的。Struts 2是Struts更新后的下一代產品，它是在Struts、WebWork 的基礎上合并成為的全新框架。究其原因主要是因為JSF、Tapestry和Spring MVC 等應用了最新的設計理念的競爭視圖層框架的出現，促使Struts吸取大量經驗，克服 很多不足進而促成了 Struts2的出現。
2、 Spring[14]框架
Spring 框架由一系列定義好的模塊組成，通過在 Spring 下的核心容器中定義 bean 的管理方式使得它的各個功能模塊既能單獨存在又能與其他模塊組合使用。
3、 Hibernate[15]框架
Hibernate 是對 java 數據庫連接進行了封裝的開源對象關系映射框架。開發人員 可以很便捷的運用面向對象編程思想對數據庫進行各種操作。同時，得益于可配置文 件， Java 對象能夠映射到數據庫中，開發人員能夠通過對其進行增、刪、改、查等操 作來達到對數據庫表中數據進行操作的目的。
2.1.4MySQL 數據庫
MySQL是由Oracle旗下的瑞典MySQLAB公司開發的關系型數據庫，它是目前 最流行的在Web應用方面最好的關系數據庫管理系統之一。MySQL使用簡單、門檻 較低，執行性能非常高，運行速度非常快，只要稍具有IT背景的技術人員均能通過 參照文檔自學掌握安裝運行和使用MySQLoMySQL是開源的，也意味著安全和免費， 技術愛好者可以一起審核程序、修補問題。MySQL雖然與大型數據庫相比有它的不 足之處，但是對于普通開發者及企業，MySQL所提供的功能已足夠且能夠節約大量 開發成本。
2.1.5Tomcat 服務器
Tomcat是一個實現了 JAVAEE標準的小型WEB服務器，由于其技術優勢明顯、 運用穩定且開源等特點，深受開發者的喜愛，是目前比較流行的Web應用服務器。
2.2本章小結
本章簡要介紹了設計和開發信息管理系統所需要用到的計算機技術類型和軟件 工具。除了對各技術類型和軟件工具的特點進行了概括外，還對其核心工作機制進行 了簡要描述，包括：J2EE體系結構、B/S架構開發模式、SSH開源集成框架、MySQL 數據庫、Tomcat服務器。通過分析介紹，確定了用于實現公安交警勤務考核管理系 統的技術基礎和軟件架構。
第三章 系統需求分析
3.1系統可行性分析
公安交通管理勤務考核系統在基層交管部門的實踐和應用的優勢，主要是為解決 如下幾個方面的需求：一是，根據考核結果倒推工作措施，精準化拉動警力，合理調 配警力資源，同時細化職責，引導民警正向工作；二是，思考完善監督的方式、方法， 更好的通過“數據”監督民警的履職情況，引導民警向工作所需要的方向發展，使得在 日常工作中發現問題的途徑更豐富、發現問題的方式更可信、發現問題的時機更及時。 而這一系列監督項目都作為考核指標納入考核系統中，形成考核閉環，推動工作質量 和效率的雙提升；三是，捆綁考核民警與干部，在系統中實現“中隊干部綜合評分由 中隊干部個人得分和所轄民警平均分各占一半”的計算邏輯，通過捆綁考核并排名的 方式進行考核，最大限度提升數據監管機制的效果、增加民警的工作積極性，提升中 隊干部的危機意識；四是，利用系統的實時便捷性，有針對性的對個別或部份項目進 行單列排名，及時從數據波動中發現異常，查找問題源頭，通過“發現數據、運用數 據、跟蹤管理數據”的方式，提高工作效率、提升管理精度，在工作、生活上都能夠 做到對民警的提醒、關心，真正在內部范圍內營造“比學趕超”的氛圍；五是，系統的 實現是“推行程序化、標準化的監督”[16]的現實體現，體現了管理模式由粗放型向精準 化轉變。
分局已建立勤務目標考核體系，在考核方案中已明確了考核對象工作職責、量化 了各項考核指標要求，執行方式和目的清晰，本系統設計初衷就是將手工計算考核成 績、排名的方式改善為通過計算機運行實現，從而提高工作效率、節約人力投入、最 大限度消除考核計算錯誤等異常情況，綜上所述系統功能通過現有技術手段不難實 現。
3.2整體需求分析
本系統業務工作分為系統信息管理、考核信息管理、考核情況查詢三個部分。因 此總體來看，系統整體設計主要由系統信息管理模塊、考核信息管理模塊、考核情況 查詢模塊構成。其中系統信息管理模塊是登陸系統的前提；考核信息管理模塊是系統 運行產生結果的基礎，它又包括考核類目管理、考核指標管理、考核數據管理三個子 模塊；考核情況查詢模塊能夠最終實現考核結果的形象展示，即通過系統考核信息管 理、運算得出考評結果，并通過圖表形式展示得分、排名結果。系統總體結構圖見表
3.1。
圖 3.1 系統總體結構圖
3.3系統用戶角色分析
系統的操作建立在角色用戶必須成功登錄的前提之下，登錄不同用戶將賦予不同 權限，系統用戶角色主要分為系統普通用戶、系統錄入員、系統管理員三類。其中系 統普通用戶為全部參與考核的民警，系統錄入員為參與考核的業務部門工作人員，系 統管理員為分管考核工作的部門干部。
在用戶訪問系統時，所輸入用戶名和密碼能夠成功與數據庫信息進行比對校驗， 只有通過才能成功登錄，反之提示“密碼錯誤請重新登錄”。登錄成功后的用戶將根據 其角色有相應模塊的訪問權限。
普通用戶為全部參與考核的民警，其均能登錄系統對考核結果和排名情況進行查 詢。系統錄入員由負責考核工作的民警構成，其主要工作為根據近期分局考核機制變 動、調整情況，對新的考核類目、考核指標進行增錄，對舊的不夠完善的考核類目、 考核指標進行修改或刪除，同時負責按照考核要求將考核數據導入系統用于考評記 分、排名。系統管理員為分局分管考核工作的部門干部，負責對用戶權限、基礎信息 和部門基礎信息進行維護管理。系統登錄用戶角色及對應權限劃分見表 3.1。
表 3.1 系統登錄用戶角色一覽表
用戶角色 操作內容 權限
系統普通用戶 查看考核結果 僅限查閱考核結果
系統錄入員 查看考核類目、指標、數據、結果；考核類目
錄入、查詢、修改、刪除；考核指標錄入、查
詢、修改、刪除；考核數據導入、查詢、修改 可查閱考核結果及對考核類 目、指標、數據進行維護
系統管理員 查看考核結果；系統用戶錄入、查詢、修改、
刪除；部門錄入、查詢、修改、刪除 可查閱考核結果，同時能夠對 系統用戶信息和權限進行維 護、對系統部門進行維護
3.4功能性需求分析
3.4.1系統信息管理
登錄系統后，僅系統管理員能夠對部門信息和用戶信息、權限進行查看、調整， 用例圖如圖 3.2 所示。
系統信息管理模塊關系到系統的正常運作，為確保各項考核數據能夠完全按照相 應考核機制明確的“查詢、錄入、發布”工作流程正常運轉，不因權限錯亂造成考核混 亂，失去監督意義故其權限具有唯一性。其具體功能需求見表3.2。
表 3.2 系統信息管理模塊功能需求表
功能模塊 功能 描述 所屬角色 權限
系統信息
管理 部門查看 以表格清單的形式顯示所有已錄入系統的部門信息 系統管理員
部門調整 錄入新的部門，對已錄入系統的部門信息進行改、刪操作 系統管理員
用戶查看 以表格清單的形式顯示所有已錄入系統的用戶信息 系統管理員
用戶調整 錄入新的用戶及其權限，對已錄入系統的用戶信息（含權
限）進行改、刪操作 系統管理員
密碼修改 對已錄入系統的用戶密碼進行修改 系統管理員
角色查看 以表格清單的形式顯示所有已錄入系統的角色信息 系統管理員
角色維護 錄入新的角色類型，對已錄入系統的角色類型進行改、刪 操作 系統管理員
菜單分配 對已錄入系統的角色類型能夠操作的菜單權限進行分配 系統管理員
3.4.2考核信息管理
本模塊僅系統錄入員能夠訪問進行相關業務操作，用例圖如圖3.3所示。
圖 3.3 系統錄入員用例圖
考核信息管理是本系統的核心模塊，其主要功能在于整理和確定用于對應考核類 目下的某一批考核指標，并通過數據維護來實現分值核算、保存，為后續考核結果、 排名展示提供核心依據。根據設計思路，用戶在登錄系統后系統將根據訪問用戶信息 進行權限判定，只顯示允許其訪問的功能子模塊，其余功能子模塊將進行隱藏。
下面就該模塊功能需求進行深入分析：
1.考核類目子模塊。考核類目即考核項目，也就是某一考核指標的集合，簡單來 說月考核、季度考核、全年考核、專項工作考核都為考核類目，不同考核類目下的考 核指標可能相同，也可能不同，其涉及的考核數據的統計時間范圍也根據其規則有所 區別。該子模塊的設立，目的在于讓系統具有更靈活的特性，能夠實現自定義添加， 滿足單位對考核對象在對某一部分工作或者某一階段的工作完成后進行評估，從而為 隊伍管理以及后續政策施行進行決策。
2.考核指標子模塊。考核指標為考核類目的下屬項目，該模塊的設立目的在于確 定某考核類目所包括的考核指標構成，另外，每一個不同類目的考核指標都有對應基 數，該基數是通過考核數據，運用數學方法核算考核分值的唯一標準。用戶在訪問該 模塊進行考核指標錄入或修改時，需要明確選擇該考核指標所屬的具體類目，未選擇 則不能進行保存，特殊情況下若同樣的考核指標分屬不同考核類目，則需要多次錄入。
3.考核數據子模塊。考核數據即考核對象完成考核指標的具體數字，該數據主要 是由負責考核的工作人員收集后通過該模塊進行錄入。數據錄入為一次性錄入，也就 是針對某次考核涉及對象的數據要求集中錄入，錄入后數據被分類保存在數據庫對應 的表中，后續進行計分排名時系統將根據用戶所選定的考核類目、考核部門或人員對 分值和排名進行展示。
考核信息管理模塊的具體功能需求見表 3.3。
表 3.3 考核信息管理模塊功能需求表
功能模塊 功能 描述 所屬角色 權限
系統考核信 息管理 考核類目查看 以表格清單的形式顯示所有已成功錄入 系統的考核類目信息 系統錄入員
考核類目調整 錄入新的考核類目，對已錄入系統的考 核類目信息進行改、刪操作 系統錄入員
考核指標查看 以表格清單的形式顯示所有已成功錄入 系統的考核指標信息 系統錄入員
考核指標調整 錄入新的考核指標，對已錄入系統的考 核指標信息進行改、刪操作 系統錄入員
考核數據導入 將對應類目的考核數據表單上傳系統后
臺數據庫 系統錄入員
考核數據查看 以表格清單的形式顯示所有已成功錄入 系統的考核數據 系統錄入員
考核數據調整 對已錄入系統的考核指標所對應的考核
數據進行錄、改操作 系統錄入員
3.4.3考核情況查詢
本模塊所有用戶均能夠訪問進行相關業務操作，用例圖如圖 3.4。
考核情況查詢是對本考核系統運行結果展示的窗口模塊。對大多數用戶來說，他 不關心考核功能運算和實現的過程，他只關注能否直觀的顯示排名結果、名次。本系 統的考核對象主要分為三類：民警、部門干部、部門。民警考核結果和排名是為了體 現民警個體差異；部門干部考核結果和排名是為了體現部門干部的管理水平；部門考 核結果和排名是為了說明這個部門的整體趨勢。為避免領導干部單打獨斗的現象出 現，按照考核機制，民警、部門干部、部門三個考核對象在核算考核分值時有具體的 綁定標準見表 3.4。
表 3.4 考核對象計分情況一欄表
考核對象 考核方式 考核規則
民警 以各指標計算出個人得分 根據已錄入的民警考核指標數據計算單項得 分，結果相加為民警考核成績
干部 以各指標計算出的部門干 部個人得分與部門民警個 人得分進行運算 根據已錄入的部門干部個人考核指標數據計算 個人單項得分，將其與本部門所有民警平均得 分求和除以二，結果為部門干部考核成績
部門 部門考核對象平均分 部門所有民警、部門干部考核成績平均值，結
果為部門考核成績
計算出具體考核對象的分值和排名后，最重要的就是進行數據展示。展示主要以 表格的形式為主，按照民警、部門干部、部門三類考核對象逐項列出本考核所屬類目、 全部考核指標的對應分值、總分、排名。此外，在用戶登錄系統后停留在首頁還未點 擊選擇具體功能模塊時，為便于直觀查閱考核結果，系統將以圖形的形式默認顯示最 近一期考核類目下的指標分布情況、民警和部門考核排名情況。考核情況查詢模塊的
具體功能需求見表 3.5。
表 3.5 考核情況查詢模塊功能需求表
顯示區域 顯示方式 顯示內容
民警考核情況查詢 子模塊 選定考核類目后執行查 詢操作 逐項列出本考核所屬類目所有民警的全 部考核指標的對應分值、考核成績、排名
部門干部考核情況 查詢子模塊 選定考核類目后執行查 詢操作 逐項列出本考核所屬類目全部部門干部 的個人總分、所屬民警平均考核成績、部 門干部考核成績、排名
部門考核情況查詢 子模塊 選定考核類目后執行查
詢操作 逐項列出本考核所屬類目部門人數、總
分、排名
系統首頁 登錄系統后默認顯示 最近一期考核類目下的指標分布圖，民警 考核排名圖、部門考核排名圖
特別說明一下，考核指標得分計算方法為考核指標完成情況和考核指標對應基數
的商乘以考核指標分值，足額或超額完成按滿分計算。
3.5系統數據模型構建分析
如圖 3.5 所示，考核系統中對應的用戶都有各自權限所約束的操作子模塊，各子 模塊的操作都涉及數據庫，根據系統需求數據以表的形式進行保存，各相互關聯的數 據在各子模塊間傳遞，最終完成考核結果和排名的計算并顯示在系統界面且［17］。
3.6系統性能需求分析
1.并發量。考核系統能夠支持最大同時在線用戶 50 個以上，在 50 個用戶同時在 線訪問系統時，響應速度流暢、無顯著降低。
2.界面加載響應速度。在 100M 局域網環境下，95%以上系統頁面加載時間不超 過 1 秒。
3.統計事務響應速度。在 100M 局域網環境下，對需要執行數據庫操作并將數據 進行展示的系統頁面加載時間不超過 3 秒。
4.系統訪問安全性。由于系統架設在局域網內，所以對設備安全等級和相關性能 要求不是很高。主要是采取權限管理的方式確保系統安全，沒有相應權限的用戶無法 訪問相應子模塊 [18]。
3.7本章小結
本章主要對公安交警勤務考核信息管理系統進行細致的需求分析。首先論證系統 設計的可行性，能否滿足實際需求；其次對系統的業務模塊需求和實現功能進行總體 概述；然后針對系統使用參與者有哪幾類角色進行劃分并明確權限；接著對系統進行 用例分析，闡述系統各模塊需要達到的功能要求；隨后用圖形的形式展現系統建模過 程［19］；最后介紹系統的性能需求。通過邏輯關聯和細致的需求分析，為后續系統的詳 細設計和實現奠定了基礎。
第四章 系統詳細設計
本章主要根據第三章的系統需求分析針對公安交警勤務考核信息管理系統展開 具體設計。詳細設計是為后續系統代碼編寫做準備，是系統從思考到實現的關鍵步驟。 本章首先針對系統實際特點對系統架構進行了設計，其次對系統業務流程進行了明 確，然后對系統數據庫設計方面的內容展開了論述，最后對主要實體對象進行了討論 并對其關聯關系進行了描述。
4.1系統結構流程設計
4.1.1整體結構設計
本系統采用 MVC 框架進行設計，分別由數據訪問、系統界面、業務邏輯三層體 系構成，對應“模型一視圖一控制器”。系統界面層由Struts2框架搭建，其與業務邏 輯層的數據傳遞通過JQuery［20］的Ajax方式［2】］進行,業務邏輯層包括有系統信息管理、 考核信息管理、考核情況查詢三大模塊，數據訪問是對數據庫的訪問操作，通過利用 Spring所提供的DAO［22］來完成對JDBC的封裝［23］,并運用Spring的聲明性事務管理。 MVC 設計模式圖如圖 4.1 所示。
圖 4.1 MVC 設計模式圖
4.1.2業務流程設計
根據需求分析，本系統的功能主要是錄入人員、部門信息，添加考核信息，上傳
考核數據，計算考核結果并排名展示。具體系統流程簡圖如圖 4.2所示。
讀取用戶角色權限
圖 4.2 系統流程圖
本系統的主要功能包括有系統信息管理、考核信息管理、考核情況查詢三個模塊， 其中系統信息管理的功能主要是對登陸用戶和部門信息的維護，考核信息管理的功能 主要是對考核類別和指標的管理以及考核數據的導入，考核情況查詢的功能主要是產 生考核結果及排名，同時顯示對最近考核情況的分析圖表。系統統功能模塊劃分如圖
4.3所示。
4.2數據庫設計
公安交警勤務考核信息管理系統的基礎數據來源于公安內網統計，由于無法連接 公安內網接口自動獲取數據，故只能通過從人工從內網導出然后倒入本系統的方式進 行操作。因系統在設計初就考慮了考核方式的自定義，即在數據錄入后能夠隨時新建 考核類目和對應考核指標計算排名成績，故本系統來源于公安內網統計的基礎考核數 據 Excel 表需要長期保存。
4.2.1實體聯系設計
通過對系統進行功能需求分析，我們可以不難看出，系統中共有多種不同角色的 用戶，不同權限的用戶對應的可操作模塊存在差異。下面就對考核過程中所需要的用 戶、數據、計分標準等實體進行分析。以下是幾個關鍵的實體關系圖。
圖 4.4 用戶實體圖
用戶實體 E-R 圖如圖 4.4 所示，用戶實體是所有能夠登錄系統的用戶，該實體主 要包括了用戶編號、警員編號、用戶密碼、用戶姓名、用戶手機號碼、職務、角色編 號、部門編號等屬性。所有用戶在登錄系統后的操作過程中不需要進行注冊實現，全 部由系統管理員添加，用戶名和默認密碼均為警號。因警號不能為空，但可以變更， 故設計用戶編號為用戶實體的主鍵。在錄入用戶數據時系統管理員、系統錄入員、普 通用戶三者并無區別，只需要指定已由系統管理員提前添加好的部門和權限信息既 可。三種角色均設計有對應的功能模塊，從而實現對系統的分權操作。
圖 4.5 部門實體圖
部門實體 E-R 圖如圖 4.5 所示，考核部門信息由系統管理員以數據字典的形式進 行維護，呈樹狀圖分布［24］。其實體屬性包括：部門編號、部門名稱、上級部門編號、 排序號、備注等。因部門與部門間存在上下隸屬關系，所以在部門實體屬性設計上增 加上級部門編號，便于在包含部門信息維護這一功能的業務模塊實現按層級處理。在 錄入部門數據時，系統管理員只需進入不同層級目錄進行部門信息維護，就能將正在 維護的部門信息綁定在上級部門之下，實現部門間上下隸屬的關聯，從而也滿足了本 系統按層級查詢部門數據，對部門進行分類考核排名的目的。
圖 4.6 考核類目實體圖
考核類目實體 E-R 圖如圖 4.6 所示。實體主要包含了考核類目編號、參與本類目 考核部門類型編號、考核類目開始時間、考核類目結束時間、考核類目創建時間、考 核類目創始人、考核類目描述、考核類目名稱等。考核類目實體實際就是對某一次考 核的文字定義，考核類目編號為系統自動生成，不會為空也不能修改，故設計其為考 核類目實體的主鍵。
圖 4.7 考核指標實體圖
考核指標實體 E-R 圖如圖 4.7 所示。實體主要包含了考核指標編號、考核類目編 號、創建時間、考核指標創建人編號、考核指標技術、考核指標分值、考核指標名稱、 考核指標文字描述等。考核指標實體是對考核內容的表達，根據部門考核需求，可以 新建不同考核類目并在該類目下自定義添加需要納入考核的指標，所以在考核指標實 體中增加考核類目編號屬性。考核基數及分值是后續根據考核對象指標完成情況核算 分值的基礎數據，必須要填寫。
圖 4.8 考核數據實體圖
考核數據實體 E-R 圖如圖 4.8 所示。實體主要包含了考核數據編號、考核指標完 成數據、考核類目編號、考核指標編號、被考核對象編號、考核數據得分、考核數據
創建時間、考核指標文字描述。考核數據實體是對考核指標完成情況的描述，每一個 指標由于可能有多個考核對象用于考核所以會出現多條考核數據，為了對這類數據進 行區分，將考核數據編號設置為系統自動生成，不會為空也不能修改，故設計其為考 核數據實體的主鍵。
4.2.2表結構設計 考核數據由考核工作負責人員從公安內網中獲取并導出，同時通過導入功能上傳 到數據庫中。對于考核人員和部門信息系統管理員負責手動錄入。本考核系統采用關 系型數據庫MySQL進行數據存儲。數據庫存儲的表是通過上文分析的實體轉化獲得, 以下是所有表結構。
用戶信息表結構見表 4.1,該表主要包括：用戶編號、警員編號、用戶密碼、用 戶姓名、用戶手機號、角色編號、部門編號、職務等字段。在上述字段中角色編號用 于區分不同類型用戶,部門編號用于區分用戶所在部門,職務用于區分用戶的級別。
表 4.1 用 戶信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 用戶編號
account varchar(32) 32 默認為空 警員編號
password varchar(32) 32 默認為空 用戶密碼
realname varchar(32) 32 默認為空 用戶姓名
mobile varchar(32) 32 默認為空 用戶手機號碼
roleUuid varchar(32) 32 默認為空 角色編號
deptUuid varchar(32) 32 默認為空 部門編號
job varchar(1) 1 默認為空 職務
部門信息表結構見表 4.2 ，該表主要包括：部門編號、部門名稱、上級部門編 號、排序號、備注等字段。在上述字段中上級部門編號用于描述部門與部門間的層級 關系，排序號用于查詢部門信息時按照錄入先后進行顯示。
表 4.2 部門信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 部門編號
codeName varchar(32) 32 默認為空 部門名稱
parentUuid varchar(32) 32 默認為空 上級部門編號
sort int(4) 4 默認為空 排序號
bak varchar(128) 128 默認為空 備注
菜單信息表結構見表4.3,該表主要包括：菜單編號、菜單名稱、菜單url地址、 上級菜單編號、排序號、圖標信息等字段。在上述字段中菜單url地址為后續增加菜 單模塊時的保留功能,上級菜單編號用于描述菜單與菜單間的層級關系,排序號用于 查詢菜單信息時按照錄入先后進行顯示。
表 4.3 菜單信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 菜單編號
menuName varchar(64) 64 默認為空 菜單名稱
menuUrl varchar(128) 128 默認為空 菜單 url 地址
parentUuid varchar(32) 32 默認為空 上級菜單編號
sort int(4) 4 默認為空 排序號
iconCls varchar(25) 25 默認為空 圖標信息
角色信息表結構見表4.4,該表主要包括：角色編號、角色名稱等字段。主要用 于存儲系統中用戶的身份類別。
表 4.4 角色信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 角色編號
roleName varchar(32) 32 默認為空 角色名稱
角色與菜單關聯信息表結構見表 4.5,該表主要包括：角色菜單關聯編號、角色 編號、菜單編號等字段。該表主要用于存儲不同角色用戶所能夠操作的菜單種類。
表 4.5 角色與菜單關聯信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 角色菜單關聯編號
roleuuid varchar(32) 32 非空 角色編號
menuuuid varchar(32) 32 非空 菜單編號
考核類目信息表結構見表 4.6,該表主要包括：考核類目編號、參與本類目考核 部門類型編號、考核類目開始時間說明、考核類目結束時間說明、考核類目創建時間、 考核類目創建人、考核類目名稱、考核類目描述等字段。
表 4.6 考核類目信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 考核類目編號
deptId varchar(32) 32 非空 本類目考核部門類型編號
beginTime varchar(20) 20 默認為空 考核類目開始時間說明
endTime varchar(20) 20 默認為空 考核類目結束時間說明
createTime varchar(20) 20 默認為空 考核類目創建時間
createUid varchar(32) 32 默認為空 考核類目創建人
title varchar(128) 128 默認為空 考核類目名稱
content varchar(128) 128 默認為空 考核類目描述
考核指標信息表結構見表 4.7,該表主要包括：考核指標編號、考核類目編號、 創建時間、考核指標創建人編號、考核指標基數、考核指標分值、考核指標名稱、考 核指標文字描述、排序號等字段。在上述字段中考核指標基數為本考核項目計算得分 的參考數據,考核指標分值為本考核項目的最高得分。
表 4.7 考核指標信息表
字段名稱 數據類型名 數據長度 默認值 備注說明
uuid varchar(32) 32 主鍵,非空 考核指標編號
typeId varchar(32) 32 非空 考核類目編號
createTime varchar(20) 20 默認為空 創建時間
createUid varchar(32) 32 默認為空 考核指標創建人編號
base decimal(10,2) 10 默認為空 考核指標基數
score double(10,2) 10 默認為空 考核指標分值
title varchar(128) 128 默認為空 考核指標名稱
content varchar(128) 128 默認為空 考核指標文字描述
sort int(4) 4 默認為空 排序號
考核數據信息表結構見表 4.8,該表主要包括：考核數據編號、考核指標的完成 數據、考核類目編號、考核指標編號、被考核對象編號、考核數據得分、考核數據創 建時間等字段。在上述字段中被考核對象編號用于區分考核對象,考核指標類目編號 和考核指標編號用于描述本考核數據所屬具體哪一個考核類目下的具體指標,考核數 據得分為本項數據在考核下的最終得分。
表 4.8 考核數據信息表
字段名稱 數據類型名 數據長度 說明 備注
uuid varchar(32) 32 主鍵，非空 考核數據編號
data decimal(10,2) 10 默認為空 考核指標的完成數據
typeId varchar(32) 32 非空 考核類目編號
elementId varchar(32) 32 非空 考核指標編號
createUid varchar(32) 32 非空 被考核對象編號
score decimal(10,2) 10 默認為空 考核數據得分
createTime varchar(20) 20 默認為空 考核數據創建時間
4.3系統模塊設計
4.3.1系統信息管理模塊設計
1、模塊功能設計
作為考核系統初始化工作中重要模塊,系統信息管理主要分為人員管理、部門管 理、菜單管理、角色管理四個部分。其中人員管理是指對被考核人員的基本信息、權 限進行維護,只有已錄入的人員才能登陸系統操作被授權模塊；部門管理是指對部門 信息進行錄入,通過人員信息與部門信息關聯實現后續對部門的考核；菜單管理主要 是實現對系統信息管理、考核管理、考核情況查詢所屬子模塊歸屬關系的可調整,若 后續有新增子模塊也可通過該功能直接鏈接到對應JSP頁面，實現菜單功能的可拓 展；角色管理是對權限的詳細管理維護,可以定義新的權限類型名并分配其所能操作 的模塊范圍。
2、算法步驟
以人員管理為例，本模塊算法的主要步驟如下：
輸入：查詢用戶信息、添加用戶信息、編輯用戶信息、刪除用戶信息、修改用戶 密碼
輸出：人員信息列表 步驟一：選擇待執行功能,若選擇查詢用戶信息,執行步驟二；選擇添加用戶信 息執行步驟三；選擇編輯用戶信息執行步驟四；選擇刪除用戶信息執行步驟五；選擇 修改用戶密碼執行步驟六。
步驟二：輸入需要查詢的用戶姓名,如果條件合法則執行查詢操作,反饋結果； 否則反饋結果顯示為空。
步驟三：輸入需要添加的人員信息記錄,如果合法則存入數據庫,提示保存成功； 否則提示請檢查參數。
步驟四：選擇需要編輯的人員信息記錄,檢查輸入的修改信息,如果合法則存入 數據庫,提示保存成功；否則提示請檢查參數。
步驟五：選擇需要刪除的人員信息記錄,提示是否刪除,選擇確認后顯示刪除成 功。
步驟六：選擇需要修改密碼的人員信息記錄,輸入需要新密碼并確認,若條件合 法則執行修改操作,提示修改成功；若輸入的新密碼和確認密碼不一致,則提示兩次 輸入密碼不一致,未輸入時提示請檢查參數。
人員管理模塊活動圖如圖 4.10 所示。
3、類關系
以人員管理子模塊中的人員信息添加為例，該功能類圖如圖 4.11所示。其主要 類分別為 BaseServlet、UserServlet、BaseBuss、UserBuss、BaseDao 和 UserDao。系 統通過 SSH 架構實現，其中 UserServlet 類是負責與用戶界面進行交互的類， UserServlet 類將收到的添加人員的請求傳遞給 UserBuss 類，該類負責處理業務邏輯 并通過 UserDao 類與數據庫進行交互，完成添加人員功能。
圖 4.11 人員信息添加功能類圖
4.3.2考核信息管理模塊設計
1、模塊功能設計
作為系統運行的核心模塊，考核信息管理主要分為考核類目管理、考核指標管理、 考核數據管理三個部分。其中考核類目管理是對考核類型進行定義，同時明確考核面 對的部門類型，該模塊的設計目的在于讓系統不局限于一種考核模式，可以根據實際 情況對所需要的考核類型進行自定義；考核指標管理是對考核類目的細化，通過將需 要納入考核的指標綁定在考核類目之下完成對考核類型的詳細描述，同樣該模塊也能 夠滿足考核單位靈活自定義考核標準的需要；考核數據通過上傳完成，減少了手動輸 入的繁瑣，對于已上傳的數據無法再次上傳成功，但能夠通過編輯功能進行修改。
2、算法步驟 以進行一次簡單考核為例，本模塊算法的主要步驟如下： 輸入： 考核類目：類目標題、部門類型、開始時間、結束時間、類目描述 考核指標：考核指標名稱、考核指標基數、考核指標分值、指標描述 考核數據：導入 Excel 數據表
輸出：
考核類目信息表、考核指標信息表、考核對象數據表 步驟一：選擇待執行功能，若選擇考核類目增加，執行步驟二；選擇考核指標增 加，執行步驟三；選擇考核數據導入，執行步驟四。
步驟二： 輸入需要增加的考核類目標題、部門類型、開始時間、結束時間、類 目描述，如果條件合法則執行增加操作，提示保存成功并以列表的方式顯示考核類目 信息表；否則提示請檢查參數。
步驟三：先選定需要增加考核指標的類目，未選定則無法選擇添加考核指標功能。 隨后輸入需要增加的考核指標名稱、基數、分值、描述，如果條件合法則執行增加操 作，提示保存成功并以列表的方式顯示考核指標信息表；否則提示請檢查參數。
步驟四：先選定需要導入考核數據的考核類目，未選定則提示請選擇類目。在上 傳考核數據時，如果條件合法則執行導入操作，提示保存成功；否則提示導入錯誤原 因。
步驟五：在考核數據上傳成功后，以列表的方式顯示考核對象數據表。
考核信息管理模塊活動圖如圖 4.12 所示。
圖 4.12 考核信息管理模塊活動圖
3、類關系
以考核信息管理子模塊中的考核指標修改為例，該功能類圖如圖4.13 所示。其 主要類分別為 MvcController、ElementController、MvcBuss、ElementBuss、MvcDao 和 ElementDao 。系統通過 SSH 架構實現，其中 ElementController 類是負責與用戶界 面 進 行 交 互 的 類 ， ElementController 類 將 收 到 的 修 改 指 標 信 息 的 請 求 傳 遞 給 ElementBuss 類，該類負責處理業務邏輯并通過 ElementDao 類與數據庫進行交互，實 現考核指標參數修改。
圖 4.13 考核指標修改功能類圖
4.3.3考核情況查詢模塊設計
1、模塊功能設計 考核情況查詢是考核系統運行的最終目的和展示，主要分為民警、干部、部門三 類得分和排名查詢。上述三類考核均需要指定考核類目，系統通過關聯考核類目下各 指標的具體分值、完成數據，通過計算得到單項得分，進而計算總分進行排名展示。
2、算法步驟
輸入：考核類目
輸出：考核對象信息、考核分值、考核排名等 步驟一：選擇需要具體查看的考核類別，若選擇查看民警考核成績，則執行步驟 二；選擇查看干部考核成績執行步驟三；選擇查看部門考核成績執行步驟四。
步驟二：選擇考核類目及部門，未選部門默認本考核類目下全部部門，以列表形 式展示民警的排名、部門、姓名、警號、各項考核指標完成數據及基數、總分。
步驟三：選擇考核類目及部門，未選部門默認本考核類目下全部部門，以列表形 式展示干部的排名、部門、姓名、警號、各項考核指標完成數據及基數、個人得分、 本部門民警平均分、干部總分。
步驟四：選擇考核類目以列表形式展示排名、部門、人數、得分。
考核情況查詢模塊活動圖如圖 4.14 所示。
圖 4.14 考核情況查詢模塊活動圖
3、類關系
以考核成績查詢中的民警成績查詢為例，該功能類圖如圖 4.15 所示。其主要類 分別為 MvcController、TypeController、MvcBuss、TypeBuss、MvcDao 和 TypeDao。 系統通過 SSH 架構實現，其中 TypeController 類是負責與用戶界面進行交互的類， TypeController 類將收到的查詢信息的請求傳遞給 TypeBuss 類，該類負責處理業務邏 輯并通過 TypeDao 類與數據庫進行交互，完成考核成績查詢功能。
圖 4.15 考核情況查詢功能類圖
4.4本章小結
本章從公安交警勤務考核信息管理系統的整體、流程、數據庫、具體模塊設計等 幾個方面對系統的開發做出要求。在整體結構設計中明確了系統采用MVC設計模式, 在業務流程設計中通過圖例對系統功能的開發要求進行了詳細描述，在數據庫設計中 通過實體和數據字典對表結構及其關系進行了整理。最后對系統三大模塊的實現通過 算法步驟描述、類關系說明進行了詳細描述。
第五章 系統實現與測試
在軟件開發過程中軟件測試是軟件實現后不可或缺的重要環節,它是保證軟件可 靠、高效運行的重要手段［25］。通過用例測試,開發者能夠及時發現系統在開發過程中 未解決缺陷。本章主要對系統功能模塊的實現進行展示、介紹并通過實例測試進行結 果描述。
5.1系統功能模塊實現
公安交警勤務考核信息管理系統登陸界面如圖 5.1 所示,只有用戶輸入正確的用 戶名和密碼方能登陸進行相關操作。在本系統中不同權限的用戶能夠進行的操作有所 不同。在登陸過程中若用戶名不正確會提示賬號或密碼有誤；如果正確,則會對用戶 權限進行判斷,根據其權限進入相應界面。
圖 5.1 系統登陸界面圖
下文就以系統管理員（以下簡稱“用戶”）的操作權限為例對系統進行展示。
5.1.1系統信息管理模塊實現
如圖 5.2 所示,是用戶成功登陸系統后的顯示主界面。左邊為系統信息管理、考 核信息管理、考核情況查詢三個模塊的操作入口,右邊為系統默認對最近一次考核進 行統計分析的圖形展示。
圖 5.2 系統主界面圖
如圖 5.3 所示的是用戶進入人員管理的主要界面圖。進入該界面后，人員信息默 認全部顯示，并提供姓名模糊查詢框供快速查詢［26］。
首頁 系統信息管理人員管理J
圖 5.3 人員管理模塊主界面圖
除此之外，系統還提供有如圖 5.4 所示的添加功能。在保存新增的人員信息時系
統會對警號、姓名、角色、部門和職務進行前端校驗，若為空則無法保存成功。
圖 5.4 人員添加功能界面圖
如圖 5.5 所示的是用戶信息編輯功能。
圖 5.5 人員修改功能界面圖
如圖 5.6 所示的是用戶刪除功能。
圖 5.6 人員刪除功能界面圖
如圖 5.7 所示的是用戶密碼修改功能。在保存修改后的密碼時，系統會對新密碼 和確認密碼進行校驗，若兩次輸入的密碼不一致，則無法保存成功。
圖 5.7 人員密碼修改功能界面圖
如圖 5.8 所示的是部門管理的主界面。進入該界面后，部門信息默認全部顯示， 用戶可通過點擊“進入”查看本部門下級部門。同時提供可按部門名稱模糊查詢的查詢 框，供用戶快速查詢。
圖 5.8 部門管理模塊主界面圖
如圖 5.9 所示的是部門信息添加功能。用戶在添加部門信息時可通過選定列表的 方式選擇上級部門。
圖 5.9 部門添加功能界面圖
如圖 5.10 所示的是系統進入菜單管理的主要界面。進入該界面后，菜單信息默 認全部顯示，用戶可通過點擊“進入”查看本菜單下級菜單。同時提供可按菜單名稱模 糊查詢的查詢框，供用戶快速查詢。
圖 5.10 菜單管理模塊主界面圖
如圖 5.11 所示的是菜單信息添加功能。用戶在添加菜單信息時可用選過定列表 的方式選擇上級菜單。
圖 5.11 菜單添加功能界面圖
如圖 5.12 所示的是系統進入角色管理的主要界面。進入該界面后角色類型信息 默認全部顯示。
圖 5.12 角色管理模塊主界面圖
如圖 5.13 所示的是用戶對角色進行菜單權限分配的主要界面。進入該界面后已 存在的菜單信息默認全部顯示，用戶可通過勾選的方式授權。
圖 5.13 角色授權功能界面圖
5.1.2系統考核管理模塊實現
如圖 5.14 所示的是用戶進入考核類目管理的主要界面圖。進入該界面后，類目 信息默認全部顯示，并提供可按類目名稱模糊查詢的查詢框，供用戶快速查詢。
圖 5.14 考核類目管理主界面圖
如圖 5.15 所示的是考核類目添加功能。在保存新增的類目信息時系統會對類目 名稱、部門類型、開始時間和結束時間進行前端校驗［27］，若為空則無法保存成功。
圖 5.15 考核類目添加功能界面圖
如圖 5.16 所示的是用戶進入考核指標管理的主要界面圖。進入該界面后，需要 先選定需要管理指標對應的類目類型方能顯示全部指標信息。
圖 5.16 考核指標管理模塊主界面圖
如圖 5.17 所示的是考核指標添加功能，該功能前提是用戶必須已經選定所屬類 目。在保存新增的指標信息時系統會對指標名稱、指標基數、指標分值進行校驗，若 為空則無法保存成功。
圖 5.17 考核指標添加功能界面圖
如圖5.18所示的是考核數據導入功能，該功能通過上傳Excel文檔實現。用戶可 通過下載上傳模板來指導上傳操作。
圖 5.18 考核數據上傳功能界面圖
如圖 5.19 所示的是考核數據編輯功能，該功能主要是用于對上傳后的數據進行 編輯、修正。
圖 5.19 考核數據編輯功能界面圖
5.1.3考核情況查詢模塊實現
如圖 5.20 所示的是民警考核成績展示功能。
圖 5.20 民警考核成績展示界面圖
如圖 5.21 所示的是干部考核成績展示功能。
圖 5.21 干部考核成績展示界面圖
如圖 5.22 所示的是部門考核成績展示功能。
圖 5.22 部門考核成績展示界面圖
5.2系統功能模塊測試
本節主要對公安交警勤務考核信息管理系統進行測試和分析，首先是確定系統的 測試環境，其次針對系統各功能模塊的具體實現進行逐一測試。
系統的正常運行與計算機硬件和軟件環境的正確搭載、良好支撐密切相關。 系統環境搭載情況如下表 5.1 所示。
表 5.1 系統軟硬環境信息表
環境類型 硬/軟件名稱 參數
硬件環境 處理器 Intel Pentium B960
內存 4G
硬盤 500G
顯示器 1366x768 增強色（32 位）
軟件環境 操作系統 Windows 7
數據庫 MySQL 5.5
編程環境 Myeclipse 10
服務器 Tomcat 7.0.86
瀏覽器 IE8及以上、360安全瀏覽器、Google Chrome等
本系統的運行環境主要由安裝有MySQL數據庫、Tomcat服務器等軟件的服務器 組成。系統采用瀏覽器/服務器模式，所以用戶只需在任意滿足上述環境的主機上安 裝有瀏覽器并能夠連接互聯網即可運行本系統。
下面就對系統各功能模塊進行逐一測試，通過測試來檢測模塊功能是否達到預期 要求。依據黑盒測試的原則，在測試過程中我們不考慮程序內部結構和特性，只檢查 模塊功能是否按照系統需求的要求正常使用，能否準確無誤的輸入、輸出數據［28］。由 于系統功能較多，故只對部分重點功能的具體測試情況列出如下。
5.2.1系統信息管理模塊測試 系統信息管理模塊主要是對參與考核對象進行初始化，即維護用戶（即考核人 員）、部門信息。下列測試主要針對增刪改查功能處理異常情況進行重點測試。測試 實例及結果見表 5.2。
表 5.2 系統信息管理測試用例表
被測模塊 測試功能 測試用例 預期結果 實際結果 結果評價
用戶管理 用戶信息 查詢 不輸入內容，點擊查詢 顯示全部內容 顯示全部內容 符合要求
輸入某個字，點擊查詢 根據用戶名匹配情況顯示 查詢結果 根據用戶名匹配情 況顯示查詢結果
添加用戶 異常 不輸入警號、姓名等必 輸項，點擊保存 提示請檢查參數，不能保 存 提示請檢查參數，不 能保存 符合要求
添加用戶的警號已存 在 提示已存在該警員警號 提示已存在該警員 警號
用戶信息 刪除 刪除已有考核數據的
用戶 成功刪除 成功刪除 符合要求
密碼修改 異常 兩次新密碼輸入不一
致 無法修改成功 無法修改成功 符合要求
部門管理 部門添加 異常 不輸入部門名稱，點擊
保存 提示請檢查參數，不能保 存 提示請檢查參數，不 能保存 符合要求
添加已存在的部門名 稱 提示已存在該名稱的部門 提示已存在該名稱 的部門
部門刪除 異常 對已存在用戶的部門 進行刪除 提示本部門有人員無法刪 除 提示本部門有人員 無法刪除 符合要求
進入和返 回不同部 門層級 點擊進入或返回能夠 完成增、刪、改查操作 操作成功 操作成功 符合要求
5.2.2考核信息管理模塊測試
考核信息管理模塊主要是對考核類目及指標進行初始化工作，即上傳考核數據。
下列測試主要針對增刪改查、數據上傳等功能處理異常情況進行重點測試。測試實例 及結果見表 5.3。
表 5.3 考核信息管理測試用例表
被測模塊 測試功能 測試用例 預期結果 實際結果 結果評價
考核類目管理 考核指標 查詢 不輸入內容，點擊查詢 顯示全部內容 顯示全部內容 符合要求
輸入某個字，點擊查詢 根據類目名匹配情況顯 示查詢結果 根據類目名匹配情 況顯示查詢結果
添加類目 異常 不輸入類目名稱、部門 類型等必輸項，點擊保 存 提示請檢查參數，不能
保存 提示請檢查參數，不 能保存 符合要求
類目信息 刪除 刪除已有考核類目 成功刪除 成功刪除 符合要求
考核指標管理 指標添加 異常 不選擇類目，點擊增加
指標 按鈕為灰色，無法增加 按鈕為灰色，無法增 加 符合要求
不輸入指標名稱、基數、 分值等必輸項，點擊保 存 提示請檢查參數，不能
保存 提示請檢查參數，不 能保存
考核數據管理 數據導入 異常 不選擇類目，點擊導入 提示請選擇類目，無法
導入 提示請選擇類目，無 法導入 符合要求
導入文件非 Excel 文件 操作成功 操作成功 符合要求
導入文件模板字段錯誤 提示模板錯誤,請查看模 板表頭信息 提示模板錯誤,請查
看模板表頭信息 符合要求
導入文件中部分數據未
填 提示具體數據不能為空 提示具體數據不能 為空 符合要求
5.2.3考核情況查詢模塊測試 考核情況查詢模塊主要是對參加考核的民警、干部、部門三類對象進行考核成績 和排名圖標展示。下列測試主要針對不按要求操作是否能夠正常統計和展示考核結果 進行重點測試。測試實例及結果見表 5.4。
表 5.4 考核情況查詢測試用例表
被測模塊 測試功能 測試用例 預期結果 實際結果 結果評價
考核情況查詢 查詢異常 不輸選擇類目 不顯示選擇查詢內容 不顯示選擇查詢內容 符合要求
選擇部門 顯示該部門查詢內容 顯示該部門查詢內容
5.3系統非功能測試
5.3.1性能測試
通過大量用戶集中試用不同用戶和相同用戶來對系統運行情況進行測試。經過測 試，系統在50 人同時登陸時未出現性能明顯降低的情況，響應時間低于1秒，點擊 各業務功能事務成功率達到 100%，同時在多個用戶登陸同一賬號時，先登陸賬號會 提示賬號已在另一處登陸，并強制退出系統。
5.3.2兼容性測試
根據現階段用戶經常使用的瀏覽器類型及版本，主要對IE7、360安全瀏覽器、 Google Chrome 瀏覽器等瀏覽系統各頁面，使用各功能模塊，觀察字體和外觀，經過 用戶測試偶爾存在外觀和字體差異，但無功能不兼容現象。
5.3.3人機界面測試
組織參與考核的民警和工作人員對系統進行小范圍試用，調研其對界面友好度、 運行流暢度、功能實用性等反饋情況，經了解均反饋系統良好，同時根據反饋情況對 系統部分界面進行了優化。
5.4測試結論
通過系統功能性測試和性能、兼容性、界面等非功能性測試，驗證了系統實現了 需求分析的設計要求，運行和試用情況符合預期，能夠實現跨瀏覽器運行，達到了設 計預期目標。
5.5本章小結
本章描述了公安交警勤務考核信息管理系統系統信息管理、考核信息管理、考核 情況查詢三個模塊的具體功能實現。在功能性上通過極端用例對其模塊功能的容錯率 進行了測試；在非功能性上通過性能、兼容性、界面友好度進行了調研論證測試，驗 證實現的系統滿足了設計預期目標，能夠運用并投入到實際工作當中。
第六章 總結與展望
6.1總結
本文描述的公安交警勤務考核信息管理系統是根據某基層公安交警大隊實際情 況，結合考核部門提供的需求，在翻閱大量文獻書籍確定 J2EE 技術類型和 SSH 架構 后開發實現的。公安交警勤務考核信息管理系統中的系統信息管理、考核信息管理、 考核情況查詢三個模塊實現了考核所需的全部功能。
在實際軟件開發過程中采用了 B/S 結構，運用了 UML 等建模軟件，使用了 MyEclipse 開發工具，在降低對客戶端的處理能力要求的同時，提高了開發效率，確 保了系統后續更易于維護［29］［30］。
6.2展望
本文雖然實現了對公安交警勤務考核信息管理系統的基本功能，但由于時間緊湊 部分功能開發還有不完善之處，這些問題都將在后續工作中進行優化，在下一步準備 從以下三個方面進行拓展：
（1）功能拓寬
為了將考核應用面擴大，在第二期開發中將著重完善考核公式自定義功能，實現 將現階段考核公式通過數據庫查詢后運算顯示升級為考核公式可配置，適應更多考核 場景［31］。
（2）界面美化
目前系統界面較為樸素，從試用者的反饋意見來看，系統美觀性還有提高的空間。
（3）可移植性
待功能拓展基本固定后將針對系統開發手機端版本，便于參與考核對象實時查看 數據，將系統的作用發揮到最大［32］。
參考文獻
[1]王海仁.堅持以信息化為牽引推動公安事業跨越式發展J].公安學刊(浙江警察學院學報)， 2011(2):50-52.
[2]向靖鋆.關于公安派出所績效考核的思考J].湖南警察學院學報,2006,18(2):100-102.
[3]田強，李唯睿.“五位一體”鑄規范執法“貴州樣本”一貴州交警挖潛大數據“聚通用”J].當代 貴州, 2017(15).
[4]張鵬.“情指勤督”四位一體發揮武漢警力效能[J].道路交通管理,2018(5).
[5]曹靜，李梅，付惠茹，等.基于J2EE的輕量級SSH框架應用[J].電子技術與軟件工程， 2017(19):153-154.
[6]肖愛華，汪詩林.J2EE通用數據訪問對象(DAO)模式設計與實現[J].計算機應用與軟 件，2005，09:136-138.
[7]基于B/S結構的安全管理平臺設計與實現[D].北京工業大學，2016.
[8]肖睿,郭泰,王丁磊.SSH框架企業級應用實戰[M].人民郵電出版社.2018-01-01.
[9]周凱，王民.一種基于Java和MySQL的物流服務協同平臺[J].電子技術與軟件工程， 2018(10).
[10]茍文博，于強.基于MySQL的數據管理系統設計與實現[J].電子設計工程,2017,06:62-65.
[11]張奇偉.基于HTML5的移動應用的研究與開發[D].北京郵電大學,2013.
[12]李剛.Struts 2.x權威指南[M].電子工業出版社,2012.
[13]趙璘，王紅霞.基于Spring MVC+JDBCTemplate的Web系統的研究與應用[J].軟件工程， 2017，20(1):5-8.
[14]劉正，張書鋒，趙鶴鳴.MVC模式下多層分布式軟件系統架構設計[J].現代電子技術,2018, 41(7).
[15]基于Struts+Hibernate+Spring框架的Web應用與實現[D].武漢理工大學,2008.
[16]王健.公安標準化建設探析[J].公安研究,2009(1):58-62.
[17]錢樂秋，趙文耘，牛軍鈺.軟件工程(第2 版)[M].清華大學出版社.2013-08-01.
[18]陳志賓，王云麗，邵云霞.基于等級保護的網絡設備安全防護研究[C]//全國信息安全等級保 護技術大會會議. 2013.
[19]陳冠元.軟件工程中的UML建模技術[J].電子技術與軟件工程,2018(5).
[20]車云月.jQuery開發指南[M].清華大學出版社.2017-11-01.
[21]周強，李宇，管仲.Ajax技術分析及應用[J].計算機技術與發展,2008,18(12).
[22]李曉東，魏惠茹，于景茹.DAO設計模式研究[J].2014,7:36-37.
[23]韓兵，江燕敏，方英蘭.基于JDBC的數據訪問優化技術[J].計算機工程與設計,2017,
38(8):1991-1996.
[24]楊春，強勇軍，袁靜.數據字典的實現與應用J].四川師范大學學報(自然科學版),1999, 22(3):352-354.
[25]上海艾微軟件技術有限公司.軟件測試技術概論[M].清華大學出版社,2004.
[26]張穎超，葉小嶺，吳士芬，等.基于SQL的模糊查詢技術研究與實現J].微電子學與計算機,
2005, 22(1):113-117.
[27]聶常紅.Web前端開發技術:HTML、CSS、JavaScript[M].人民郵電出版社,2013.
[28]萬年紅.軟件黑盒測試的方法與實踐[J].計算機工程,2000,26(12):91-93.
[29]陳冠元 軟件工程中的UML建模技術[J].電子技術與軟件工程,2018(5).
[30]任培花.J2EE架構與MVC模式下企業內部BBS系統的設計與實現[J].計算機與數字工程,
2010,38(12):187-189+197.
[31]孫文娟.企業績效管理系統設計與實現[D].華東師范大學,2009.
[32]范懷宇.Android開發精要[M].機械工業出版社,2012.
下一篇：沒有了
相關標簽:
