目錄
摘要 1
Abstract 2
目錄 I
第一章引言 1
1.1項目背景 1
1.2同類系統研究與應用現狀 1
1.3研究的內容和主要工作 2
1.3.1研究的內容 2
1.3.2主要工作 2
1.4論文結構 3
第二章業務分析 4
2.1業務描述 4
2.1.1業務問題定義 4
2.1.2組織結構分析 4
2.1.3業務人員分析. 5
2. 2原有業務流程分析 7
2.2.1基礎信息管理 7
2.2.2事故接出警管理業務 8
2.2.3事故處理管理業務 9
2.2.4事故輔助管理業務 10
2.2.5査詢統計管理業務 11
2.3業務流程優化 12
2.3.1基礎信息管理業務優化 12
2.3.2事故接出警管理業務優化 13
2.3.3事故處理管理業務優化 14
2.3.4事故輔助管理業務優化 15
2.3.5查詢統計管理業務優化 16
第三章功能分析 18
3.1角色分析 18
3.2系統數據流分析 19
3.2.1頂層數據流 19
3.2.2 一層數據流 21
3.2.3二層數據流 24
3.3系統功能結構 50
3.3.1總體功能結構圖 50
3.3.2子功能結構圖 51
第四章數據分析 55
4.1實體關系分析 55
4.2數據庫表 64
第五章總結與展望 74
5.1總結 74
5.2進一步的工作 74
參考文獻 75
致謝 76
第一章引言
1.1項目背景
隨著中國經濟的不斷高速發展,國內汽車保有量持續走高。截止2014年底, 中國的機動車保有量已經達到了 2.64億輛,幾十年來我國高速公路里程數占公 路總里程數的不斷攀升和汽車品質和性能的井噴式發展,使得我國的汽車普及率 與發達國家的差距進一步縮小。如此驚人的數量帶來的不僅僅是國內經濟的穩定 前行,同時帶來的也有交通事故的頻發和一個個鮮活生命在輪胎之下被終結。就 萬車死亡人數這一數據來看,中國的數據遠遠高于歐美國家,我國的交通事故發 生率更高。究其原因:主要為酒駕,疲勞駕駛,逆行,駕駛過程中打電話或者使 用手機。
事故發生后交通事故處理環節變得尤為重要,如果出現不公平,不公正的現 象不但對事故當事人沒有教育意義,反而會誘發他進一步的錯誤甚至犯罪行為, 從而危害社會。當今交通事故的處理頻頻爆出丑聞,交通事故信息記錄量少,裁 決帶有強烈的主觀性,處理事件憑借個人經驗而不仔細了解情況等等,這樣的惡 劣行為不但有失我國法律的公平公正,而且也給了基層執法人員收賄受賄的機 會。就2014年的數據,我國一年交通事故報案總量已經達到了 470萬起左右, 在這一數字不斷增長的同時,交通部門的數量以及交通事故處理人員總數并沒有 相應上升。
就以上諸多原因,一套完整的交通事故處理信息管理系統的出現迫在眉睫。
1.2同類系統研究與應用現狀
在交通事故處理信息管理系統的研究和應用領域,美國,日本,加拿大走在 世界的前列,并取得了顯著的效果【譏美國研發并應用的事故分析報告系統FARS, 該系統的數據內容涵了全美過公路交通事故數據和血液酒精含量檢測數據,并且 這一數據可以在網絡上可以查詢。并且該系統可以得到全美各地區的實時交通事 故分布情況以及對事故高發地段的分布⑵。
就成功的例子來說,領先國家往往可以整合大量的數據并共享信息。可以從 系統中得到很多借鑒以及相應的處理規則,這與國內的地區性的系統有很大區 別,國內的系統大部分都是以客戶端與服務器的架構設計的(C/S模式)【8],并
沒有一個橫向的比較和處理辦法,更多的注重是處理事務的本事[3],這在一定程度 上限制了我國在該領域的發展。地區與地區之間不能互聯也是一個短板,這導致 由于地區的關系,不能磨滅所謂的地區性差異,存在一些由規則意外原因所產生 的差異。再者,我國屬于人口大國,事務數量必然是龐大的,單單只是靠人力, 不但工作效率低下,而且人不可避免的存在很多誤差和錯誤。也不符合我國信息 化發展的方針。我國經濟發展形勢一片大好,汽車的普及率也會越來越高,這樣 說明交通壓力也會越來越大,交通管理部門也將迎來更多是交通事故處理任務, 這也說明就純人力的管理和處理辦法是不可持續發展的。
就目前的國內情況和國外的發展開看,交通事故處理信息管理系統的研發和 應用勢在必行,也理所應當。
1.3研究的內容和主要工作
1.3.1研究的內容
本課題主要利用軟件工程專業中的結構化設計方法對南昌市道路交通事故 處理信息管理系統進行研究與設計,并結合南昌市交警大隊處理交通事故及管理 事故處理信息的實際工作,研究一款這對于南昌市交警大隊交通事故處理信息的 管理系統,主要提供對交通事故報警受理、交通事故處理以及查詢統計報表的管 理,使得交通事故處理信息的管理更加高效便捷。
本論文對南昌市交通事故處理信息管理系統進行研究與分析,主要研究的內 容是南昌市交警大隊對交通事故處理信息管理的業務需求和功能需求,主要包括 交通事故處理信息管理中的基礎信息管理模塊、事故接出警管理模塊、事故處理 管理模塊、事故輔助管理模塊、査詢統計管理模塊以及系統管理模塊。
1.3.2主要工作
針對本課題的需求與完成論文的技術需求,本人所做的主要有以下幾點:
(1)鞏固了之前所學的軟件設計與開發方面的知識,通過對比和分析,確 定了采用結構化的分析思想,對該系統進行研究和分析。
(2)利用網絡資源并結合自身工作經歷,深入地了解了交通事故處理的整 個過程;利用學校圖書館的資源,查閱了交通事故處理信息管理相關的文獻。通 過這些途徑,對交通事故處理信息管理系統有一個整體的認識和構思。
(3)對南昌市交通事故處理信息管理系統進行了業務需求分析,并據此設 計出業務流程圖。
(4)對南昌市交通事故處理信息管理系統的數據流進行詳細的分析,畫出 對應的數據流程圖。
(5)對南昌市交通事故處理信息管理系統的功能進行詳細分析,畫出功能 結構圖圖。
(6)對南昌市交通事故處理信息管理系統的數據需求進行分析,設計系統 中所需的數據庫表。
1.4論文結構
本論文共有五章,論文的結構如下:
第一章:引言。這一部分,我們首先介紹了南昌市交通事故處理信息管理系 統的項目背景以及需要解決的問題;然后介紹了交通事故處理信息管理系統的國 內外研究現狀,并將國內外的交通事故處理信息系統做了一個簡單的對比;接下 來介紹了論文的研究內容以及本人在課題研究中所做的工作,最后是本論文的論 文結構。
第二章:業務分析。這一部分,主要對南昌市交通事故處理信息管理系統進 行了業務上的分析和描述,確定將系統分成六大模塊,并且對這六個模塊進行了 業務流程的分析,并且在業務流程的基礎上,又進行了業務流程的優化。
第三章:功能分析。這一部分,主要是根據第二章業務需求的分析,對南昌 市交警大隊進行了角色分析,在角色分析完畢后,對系統六大模塊進行了詳細的 系統數據流分析和系統功能結構分析,使得系統功能結構更加清晰。
第四章:數據分析。這一部分,主要是對交通事故處理信息系統的數據需求 進行分析,其中包括實體屬性與實體關系的分析和數據庫表的設計。
第五章:總結與展望。這一部分,主要對南昌市交通事故處理信息管理系統 進行總結,并對本課題的下一步工作作出展望。
第二章業務分析
2.1業務描述
2.1.1業務問題定文
經濟的快速發展以及生活節奏的加快使得國內的汽車保有量大幅度提高,交 通事故也隨之增加。交警人員處從接收到報警信號開始的每一個環節都關系到事 故當事人的生命和財產,如何高效快速地處理道路交通事故以及系統地總結交通 事故處理經驗成為交通部門面臨的重大難題。通過對南昌市道路交通事故處理信 息管理的調查了解,發現目前的道路交通事故處理信息管理存在很多缺陷。
(1)數據化程度不高。當前對交通事故處理信息大多采用文字描述,這些文字
記錄不僅要消耗交警人員,還需要工作人員擁有很強的文案寫作能力。由 于工作人員在表達方式上存在差異,事故處理相關文件標準化程度不高, 這不利于計算機的處理。此外,文字化的描述不利于對交通事故的相關數 據進行分析,對于復雜的交通事故的深層次分析來說,缺少了強有力的數 據支持。
(2)事故處理程序繁雜。傳統的交通事故處理政策性強,又存在權利集中的現
象,這為交警人員及時快速地處理交通事故帶來了限制。繁雜的事故處理 程序不僅耽誤了事故現場處理的時間,而且給事故當事人的人生和財產帶 來重大損害。
2.1.2組織結構分析
南昌市交警大隊
圖2-1南昌市交警大隊組織結構圖
如上圖2-1所示,南昌市交警大隊由控制中心、宣傳科、法制科、科技科、 辦公室、政工科、秩序科、紀委、路面執勤大隊、車管所、告訴公路大隊、交通 違法處理大隊、事故大隊等部門組成。
控制中心主要負責南昌市所有監控點攝像頭的實時監控,并且負責指導和監 督交警執勤;宣傳科主要負責交警大隊的對外宣傳工作,管理公共事務;法制科 主要負責對交警執法行為的監督以及為交警執法行為提供法律保障,并且負責群 眾對交警的行政訴訟方面的事宜;科技科主要負責交警大隊的科技支持,其中包 括違法圖片的拍攝、交通事故影像的分析等等;辦公室主要負責交警大隊的后勤 工作以及財務管理方面的工作;政工科主要負責新人招募錄用工作以及辦公室做 好后勤保障方面的工作;秩序科主要是負責交通秩序的維護工作,比如道路劃線、 制作道路標牌等工作;紀委主要負責督察交警的執法行為以及交警的生活作風和 精神面貌,此外,還要負責前來投訴群眾的接待工作;路面執勤大隊,顧名思義, 就是負責路面上的巡邏執勤工作;車管所,主要負責車輛信息的采集,駕駛證件 的發放以及違紀扣分的處理;告訴公路大隊主要負責高速公路上交通行駛的管 理;交通違法處理大隊主要負責對違法事故的處理;事故大隊主要負責交通事故 的受理和處理工作。
2.1.3業務人員分析
一般交警:在原有業務流程分析中,交警在基礎信息管理的流程中,可以提 供交警的基礎信息以及對自己信息的核査,另外還可以獲取車輛信息、去短信息 以及法律法規信息,對這些信息進行登記;在査詢統計管理流程中,可以查詢案 件卷宗,對案件信息、扣放車臺賬以及保證金臺賬進行進行統計并制作成報表。
指揮調度組交警:在原有業務分析流程中,指揮調度組交警在事故接出警管 理的流程中,可以接收當面或電話形式的報警信息,并對報警信息進行登記,判 斷報警是否屬于受理范圍,并且安排出警人員出警。
事故組交警:在原有業務分析流程中,事故組交警在事故處理管理的流程中, 需要對事故現場進行處理,并對現場進行勘察取證,記錄事故的調查信息,還要 要求事故現場的當事人及證人簽名,并且可以扣留肇事車輛和事故相關人證件。
事故處理后交警:在原有業務流程分析中,事故處理后交警在事故輔助管理 的流程中,可以對事故處理后的公開聽證、責任認定、行政處罰以及事故調解信 息進行管理。事故處理后交警需要召開公開聽證會,并記錄全程信息,通過空開 聽證信息,作出責任認定書以及處罰意見,還可以對事故當事人進行事故調解。
大隊領導:在原有業務流程分析中,大隊領導在基礎信息管理的流程中,可 以對交警信息、車輛信息、區段信息以及法律法規信息進行審核;在事故接出警 管理的流程中,需要對調度組交警安排的出警信息進行審批;在事故處理管理的 流程中,可以指揮重大事故的現場救援及調査取證工作;在事故輔助管理的流程 中,對事故責任認定以及處罰意見進行審批;在查詢統計管理的流程中,可以對 交警的案件査詢申請進行審核,對案件統計信息、扣放車臺賬以及保證金信息進 行查閱和存檔。
2.2原有業務流程分析
2.2.1基礎信息管理
基礎借息鸞理流程圖
般交警 大隊領導
圖2-2基礎信息管理業務流程圖
圖2-3事故接出警恃理業務流程圖
如上圖2-3所示,原有的接處警管理業務都是手工操作的,指揮調度交警接 到報案后,首先對報案信息進行登記,再清楚了報警信息后,判斷報警是否在受 理范圍,不是則移交到相關部門,是的話就可以安排出警,填寫好出警登記表, 并交給大隊領導審批。
2.2.3事故處理管理業務
事故處理管理業務流程圖
2.2.4事故輔助管理業務
事故刪管理或務潼程圖
事故就理交警
召築弟故相關人員 事故發生的信息來認定事故責任人,然后對事故責任人進行行政處罰,最后計算 事故造成的損害和需要賠償的數目,對當事人進行調解。
2.2.5査詢統計管理業務
賁詢統計您輕業務流桎罔
大隊領導
査看審故貴任認定倍
息
圖2-6査詢統計管理業務流程圖
如上圖2-6所示,查詢統計管理主要是對案件以及案件相關的信息進行査 詢或統計。交警要查詢某個案件必須先寫查詢申請,由大隊領導審核通過了才能 到資料室查找。另外,交警還需要對案件信息、扣放車臺賬以及保證金臺賬進行 核對并分類統計,制成統計報表,最后將統計報表上交給大隊領導進行查看和存 檔。
2.3業務流程優化
2.3.1基礎信息管理業務優化
基礎信息管理流程圖
圖2-7卻信息管輕和化擁圖
如上圖2-7所示,基礎信息管理是交警與系統管理人員之間的信息交互,交 警在獲取到交警基本信息、車輛信息、區段信息和法律法規信息后,將這些基礎 信息錄入到交通事故處理信息系統,系統管理人員即時對基礎信息進行審核,審 核通過則確認保存這些基礎信息。
2.3.2事故接出警管理業務優化
反饌報警覺理佶息
圖Z8事故接出警管理業務優化流程圖
如圖2-8所示,優化后的事故接出警管理業務相比之前的效率更高,大大降
低了事故的損傷程度。指揮調度組交警在接到報警信息后,立即將報警信息錄入 系統,系統管理人員會對報警是否受理做出判斷,然后立即做出出警安排,在出 警審批上也避免了很多救援延緩的現象,即使大隊領導有事外出,還是可以進入 系統對出警安排做出審批。
2.3.3事故處理管理業務優化
事故處理管觀業務流程圖
零故組交警
圖2-9事故處理管理業務優化流程圖
如圖2-9所示,事故處理主要是對事故現場的處理,這一環節交警人員是無 可取代的。但是,優化后的事故處理管理業務對于事故處理信息的管理更加方便 有序了。事故組交警子現場處理完畢后,可以將事故處理的信息錄入系統,為以 后的事故處理工作提供參考和指導,還能對事故調查信息及相關信息進行管理。
2.3.4事故輔助管理業務優化
圖2-10事故輔助管理業務優化流程圖
如圖厶10所示,事故輔助管理主要是對事故后的問題處理。事故后處理組 交警要將公開聽證的整個過程錄入系統,然后根據事故事實確定事故責任人,再 錄入行政處罰意見,由大隊領導審批。最后,對事故進行調節,將調節結果公布。
235坤統計管理業務優化
金詢資任認進信息
圖241査詢統計業務優化流程圖
如圖2-11所示,優化后的查詢統計業務大大減輕了交警對案件的統計以及 對各種報表統計的工作量。原有的查詢統計業務都是由人工操作的,浪費了大量 的時間和人力,優化后的案件查詢,只需要管理人員對查詢人員進行可見設置, 統計工作也是由計算機自動完成的。
第三章功能分析
3.1角色分析
南昌市道路交通事故處理信息管理系統按照業務需求劃分,可以將角色劃分為一 般交警、指揮調度組交警、事故組交警、事故處理后交警、當事人、大隊領導和 系統管理人員。具體業務角色分析表如下表3-1所示。
表3-1業務角色分析表
角色 職責或功能
一般交警 系統主要參與者,可進行基礎信息的錄入和維護,查詢案件 信息,對案件信息、扣放車臺賬以及保證金臺賬進行進行統 計并制作成報表。
指揮調度組交警 系統主要參與者,可進行報警信息的登記以及事故的指揮調 度。
事故組交警 系統主要參與者,可進行事故處理過程的錄入和管理,對事 故現場的調查信息進行管理
事故處理后交警 系統主要參與者,對事故處理后的公開聽證信息、責任認定 信息以及事故調解信息進行維護管理。
大隊領導 系統主要參與者,可進行所有信息的査詢工作,對事故處理 相關文件進行審核和審批。
當事人 系統的主要參與者,可提供事故的詳細信息
系統管理人員 系統的維護管理人員,對系統的用戶信息、用戶權限信息以 及日志信息進行維護
I /項毎、
/私迦 \
H—糞故處理信息—i 劉遞焼 '汁一事故栢關統計信息- \ 事故信息 >\ 電巒嘛 /—事故相關信息—
I \ /
I \、o 毀/
八
。云燼!fc規瞰他狀是eM濱.於iffi-fc最硬e蠱鴨英 笛擲劇抽吹e舉fflteiunKY鎖拋燃矗”傾型輕顒敘呃欄»*劃塢廉笊劃®Y*汕
.酸蝕氷決罡**劃銀廉熾劃與他需丟y “螂陋他eM 必必'§、腿犧辱雖»,確、eMg輕M,酸妙勲罄v聯燃能瞅帥碩e酣敘輕*與除旺 家軌欣 彳碎O5SS ,Y*現,加辱丟y ,*敘“粼目朵爾瞞棉DECY卯 as懈能。煤能啟M云&'t 他 y—g長能隍毬SW迦酸eeMEM^e®耳宦* ®住崔迥杞tnmw溟転釀塢廉SE迦酸迴戢雖軽*陂叔怛nlmft.版區IrA
表3-2 “交警”數據源點條目描述
源點名稱:交警
別名:指揮調度組交警、事故組交警、事故后處理交警
描述:參與交通事故報警、出警、事故調査等動作執行
數據流:事故相關信息、案件查詢信息
數目:2
表3-3 “大隊領導”數據源點條目描述
源點名稱:大隊領導
別名:無
描述:參與交通交通事故出警以及處理的指導和審批方面的工作 數據流:事故相關信息、事故相關審批信息
數目:2
表3-4 “當事人”數據源點條目描述
源點名稱:當事人
別名:無
描述:提供事故事實信息
數據流;事故信息、事故處理信息
數目:2
表3-5 “管理人員”數據源點條目描述
源點名稱:管理人員
別名:無
描述:交通事故處理信息管理系統的管理者
數據流:事故相關信息、維護的參數信息
數目:2
3.2.2 —層數據流
圖3-2南昌市交通事故處理信息管理系統一層數據流圖
如上圖所示,南昌市交通事故處理信息管理系統的一層數據流圖包扌舌基礎信 息管理、事故接出警管理、事故處理管理、事故輔助管理、查詢統計管理和系統 管理六個模塊中的數據流。
表3-6 “基礎信息骨理”處理過程條目描述
處理過程名稱:基礎信息管理
處理過程編號:P1
簡述:對交警信息、車輛信息、區段信息、法律法規信息的維護
輸入數據流:基礎數據維護信息
輸出數據流:交警信息、車輛信息、區段信息、法律法規信息
處理邏輯:將交警信息、車輛信息、區段信息以及法律法規信息插入系統數據庫
表3-7 “事故接出警管理”處理過程條目描述
處理過程名稱:事故接出警管理
處理過程編號:P2
簡述:對接受到的報警信息進行錄入登記受理,并安排出警
輸入數據流:報警信息、出警信息、出警信息審批信息
輸出數據流:報警受理信息
處理邏輯:將報警信息錄入系統,系統自動做出是否受理判斷,自動安排岀警
信息
表3-8 “事故處理仙”處理過程條目描述
處理過程名稱:事故處理管理
處理過程編號:P3
簡述:對事故現場處理信息、現場勘查信息以及事故相關信息的記錄
輸入數據流:事故處理信息、事故處理意見審批信息
輸出數據流:事故登記表、事故處理信息表
處理邏輯:將事故現場處理的信息以及事故調查登記信息插入數據庫
表3-9 “事故輔助管理”處理過程條目描述
處理過程名稱:事故輔助管理
處理過程編號:P4
簡述:對事故的后續處理管理,主要是公開聽證、責任認定、行政處罰以及事故 調解的管理
輸入數據流:事故后處理信息、事故責任賠償審批信息、事故信息
輸出數據流:案件信息表
處理邏輯:事故調解信息、案件信息插入數據庫,從數據庫中查詢案件信息
表3>10 “査W統計管理”處理過程條目描述
處理過程名稱:查詢統計管理
處理過程編號:P5
簡述:對案件進行查詢并對其進行統計,對事故的扣放車輛、保證金臺賬進行統 計和管理
輸入數據流:案件查詢申請、統計報表信息、案件查詢審核信息
輸出數據流:査詢案件信息
處理邏輯:將案件、扣放車輛、保證金信息錄入數據庫并自動統計
表3-n處理過程“系統管理”條目描述
處理過程名稱:系統管理
處理過程編號:P6
簡述:對用戶、用戶權限及系統日志信息進行維護
輸入數據流:系統維護信息 '
輸出數據流:用戶信息、系統日志信息、權限信息
處理邏輯:將教育綜合得分計算機排名結果、黨員學習積極分子名單錄入數據庫
3.2.3二層數據流
圖3-3基礎信息管理二層數據流圖
如上圖3-3所示,信息管理二層數據流圖對系統一層數據流圖中的P1數據 流程進行了細化。P1數據流程由交警信息管理、車輛信息管理、區段信息管理、 法律法規管理四個處理過程構成。
表3-12 “交警信息骨理”處理過程條目描述
處理過程名稱:交警信息管理
處理過程編號:P1.1
簡述:將將交警的基本信息添加到交通事故處理信息管理系統
輸入數據流:交警基礎信息、交警數據維護信息
輸岀數據流:交警信息審核信息
處理邏輯:交警將自己的個人信息錄入數據庫,系統管理人員對交警信息進行維 護
表3-13 “車輛宿息管理”處理過程條目描述
處理過程名稱:車輛信息管理
處理過程編號:P1.2
簡述:將車輛的基本信息添加到交通事故處理信息管理系統
輸入數據流:車輛基礎信息、車輛數據維護信息
輸出數據流:車輛信息審核信息
處理邏輯:交警將車輛基礎信息錄入數據庫,系統管理人員對車輛信息進行維護
表3-14 “區段信息管理”處理過程條目描述
處理過程名稱:區段信息管理 、
處理過程編號:P1.3
簡述:將區段基本信息添加到交通事故處理信息管理系統
輸入數據流:區段信息、區段數據維護西信息
輸出數據流:車輛信息審核信息
處理邏輯:交警將區段基礎信息錄入數據庫,系統管理人員對區段信息進行維護
表3-15 “法律酬管理”處理過程條目描述
處理過程名稱:法律法規管理
處理過程編號:P1.4
簡述:對法律法規信息進行更新和修改
輸入數據流:法律法規更改信息、法律法規數據維護信息
輸出數據流:無
處理邏輯:交警提交法律法規更新信息,系統管理員對法律法規進行修改
表3-16 “交警信息”存儲詞條描述
數據流名稱:交警信息
簡述:系統中交警的詳細信息
數據組成:交警ID+交警姓名+用戶ID+用戶名+權限ID+性別+身份證號+所在地
+聯系電話+照片+參警年齡+文化程度+資格證編號+職務+警銜+是否空閑
存儲方式:以交警姓名為關鍵字
表3-17 “車輛信息”存儲詞條描述
數據流名稱:車輛信息
簡述:系統中車輛的基本信息
數據組成:車輛ID+車輛型號+車輛廠牌+車輛類型+載客數+載質量+輪胎數量+ 車輛軸距+車輛廠+車輛寬+車輛高
存儲方式:以車輛型號為關鍵字
表348 “區域信息”存儲詞條描述
數據流名稱:區域信息
簡述:系統中區域的基本信息
數據組成:區域路段ID+區域代碼+區域名稱+路段代碼+路段名稱+公里數
存儲方式:以路段名稱為關鍵字
表3-19 “法律法規信息”存儲詞條描述
數據流名稱:法律法規信息
簡述:系統中法律法規信息
數據組成:法律條文ID+隸屬類別+條文名稱+條文正文+查詢次數
存儲方式:以條文名稱為關鍵字
表3-20 “交警基本信息”數據流條目描述
數據流名稱:交警基本信息
簡述:交警注冊用戶信息時需要錄入的個人基本信息
來源:交警
去向:加工“交警信息管理”
數據組成:交警ID+交警姓名+用戶ID+用戶名+權限ID+性別+身份證號+所在地 +聯系電話+照片
表3-21 “好宿息審核信息”數據流條目播述
數據流名稱:交警信息審核信息
簡述:交警提交個人基礎信息時系統的審核信息
來源:加工“交警信息管理”
去向:交警
數據組成:審核信息
表3-22 “交警數據維護信息”數據流條目描述
數據流名稱:交警數據維護信息
簡述:系統管理人員對交警基礎信息的維護信息
來源:系統管理人員
去向:加工“交警信息管理”
數據組成:維護信息+維護人員ID
表3-23 “車舷礎信息”數據流條目描述
數據流名稱:車輛基礎信息
簡述:系統中錄入的車輛基礎信息
來源:交警
去向:加工“車輛信息管理”
數據組成:車輛ID+車輛型號+車輛廠牌+車輛類型+載客數+載質量+輪胎數量+ 車輛軸距+車輛廠+車輛寬+車輛高
表3~24 “車輛信息審核信息”數據流條目描述
數據流名稱:車輛信息審核信息
簡述:系統對車輛信息的審核信息
來源:加工“車輛信息管理”
去向:交警
數據組成:審核信息
表3-25詒撤據維護信息”數據流條目描述
數據流名稱:車輛數據維護信息
簡述:系統管理人員對車輛基礎信息的維護信息
來源:系統管理人員
去向:系統管理人員
數據組成:維護信息+維護人員ID
表3-26儉員基礎數據維護信息”數據流條目描述
數據流名稱:黨員基礎數據維護信息
簡述:系統管理人員對黨員信息的維護
來源:管理人員
去向:加工“黨員信息管理”
數據組成:用戶ED+用戶名+維護信息
表3-27 ”覚委基礎數據維護信息”數據流條目描述
數據流名稱:黨委基礎數據維護數據
簡述:系統管理人員對黨委信息的維護
來源:管理人員
去向:加工“黨委信息管理”
數據組成:用戶ID+用戶名+維護信息
表3-28 “黨支部基礎數據酣信息”數據流條目描述
數據流名稱:黨支部基礎數據維護信息
簡述:系統管理人對黨支部基礎信息的維護信息
來源:系統管理人員
去向:加工“黨支部信息管理“
數據組成:用戶ID+用戶名+維護信息
表3-29教育刪”琳流條目描述
數據流名稱:教育計劃
簡述:黨支部人員制定的教育計劃信息
來源:黨支部
去向:加工“教育計劃管理”
數據組成:教育計劃ID+計劃時間段+開始時間+教育計劃項目1+教育計劃項目
2+教育計劃項目3+綜合合格分數
表3-30 “教育計劃審批信息”數據流條目描述
數據流名稱:教育計劃審批信息
簡述:黨委對教育計劃的審批信息
來源:黨委
去向:加工“教育計劃管理" 數據組成:教育計劃ID+審批信息
如上圖3-4所示,事故接出警管理二層數據流圖對系統一層數據流圖中的
P2進行了細化。P2由報警信息登記、報警受理、出警安排、出警審批四個處理 過程構成。
表3-31 “報警信息登記”處理過程條目描述
處理過程名稱:報警信息登記
處理過程編號:P2.1
簡述:指揮調度組交警將接受的報警信息錄入系統
輸入數據流:報警信息
輸出數據流:提交狀態信息
處理邏輯:指揮調度組交警進入系統,將報警信息錄入系統,并保存到系統數據 庫
表3-32 “報警受理”處理過程條目描述
處理過程名稱:報警受理
處理過程編號:P2.2
簡述:系統管理人員對報警信息做出是否受理的判斷
輸入數據流:報警審核信息
輸出數據流:報警受理信息
處理邏輯:系統管理人查看報警信息,并對報警信息進行審核,做出是否受理的 選擇。
表3-33 “出警安排”處理過程條目描述
處理過程名稱:出警安排
處理過程編號:P2.3
簡述:系統管理人員根據報警信息安排出警人員
輸入數據流:出警信息
輸岀數據流:出警確認信息
處理邏輯:系統管理人員將出警信息錄入數據庫系統,系統提示出警信息錄入提 交狀態
表3-34 “出警審批”處理過程條目播述
處理過程名稱:出警審批
處理過程編號:P2.4
簡述:大隊領導對出警信息進行審批
輸入數據流:出警審批信息 ’
輸出數據流:出警信息反饋
處理邏輯:大隊領帶查看出警信息,并對出警信息作出審批,將審批信息錄入系 統數據庫
表3-35 “報警登13信息”存儲詞條描述
數據流名稱:報警登記信息
簡述:指揮調度組交警登記的報警信息
數據組成:報警ID+報警警號+報警時間+報警人姓名+報警電話+事故堰點+傷亡 情況+備注
存儲方式:以報警警號為關鍵字
表3-36 “出警信息”存儲詞條描述
數據流名稱:出警信息
簡述:系統管理人員安排的出警信息 嚴
數據組成:報警ID+岀警人1ID+岀警人2ID+出警人1姓名+出警人2姓名+出警 時間+審批信息+備注
存儲方式:以出警時間為關鍵字
表3-37 “報警信息”知流條目描述
數據流名稱:報警信息
簡述:指揮調度組交警登記的報警信息
來源:指揮調度組交警、
去向:加工“報警信息登記”
數據組成:報警ID+報警警號+報警時間+報警人姓名+報警電話+事故地點+傷亡 情況
表3-38 “戦狀態信息”數據流條目描述
數據流名稱:提交狀態信息
簡述:系統自動反饋的提交信息
來源:加工“報警信息登記”
去向:指揮調度組交警
數據組成:報警ID+提交狀態
表3-39 “報警審核宿息”數據流條目描述
數據流名稱:報警審核信息
簡述:系統管理人員對報警信息的審核
來源:系統管理人員
去向:加工“報警受理”
數據組成:報警ID+審核信息
表3-40 ”出警信息”數據流條目描述
數據流名稱:出警信息
簡述:系統管理人員安排的出警信息
來源:管理人員
去向:加工“出警安排”
數據組成:報警ID+岀警人1ID+岀警人2ID+出警人1姓名+出警人2姓名+出警 時間+審批信息
表3-41 “出警確認信息”數據流條目描述
數據流名稱:出警確認
簡述:系統自動反饋的出警確認信息
來源:加工“出警安排”
去向:系統管理人員
數據組成:確認信息
表3-42 “出警審批信息”數據流條目描述
數據流名稱:出警審批信息
簡述:大隊領導對岀警人員的審批信息
來源:大隊領導
去向:加工“出警審批" '
數據組成:報警ID+出警人1ID+出警人1姓名+出警人2ID+出警人2姓名+審批 信息
表3M3 “出警信息反饋”數據流條目描述
數據流名稱:出警信息反饋
簡述:系統管理人員獲得的出警反饋信息
來源:加工“出警審批”
去向:系統管理人員
數據組成:報警ID+出警人1ID+出警人1姓名+出警人2ID+出警人2姓名+審批 信息
如上圖3-5所示,事故處理管理二層數據流圖對系統一層數據流圖中的P3 數據流程進行了細化。P3數據流程由事故處理信息管理、事故調查信息管理、 事故相關信息管理三個處理過程構成。
表3M4 “事故處理信息管理”處理過程條目描述
處理過程名稱:事故處理信息管理
處理過程編號:P3.1
簡述:事故組交警在事故現場處理完后,將事故處理信息錄入系統數據庫 輸入數據流:事故處理信息
輸出數據流:處理信息反饋
處理邏輯:事故組將現場記錄的處理信息錄入到系統數據庫,
表3M5 “事故調査信息冷處理過程條目描述
處理過程名稱:事故調查信息管理
處理過程編號:P3.2
簡述:事故組交警對事故現場進行調查后,對事故調查信息進行登記
輸入數據流:事故調査信息、事故調查建議
輸出數據流:提交狀態、事故調査結果
處理邏輯:大隊領導提出事故調査建議,事故組交警根據建議調查事故現場,然 后將調查信息錄入系統數據庫
表3-46 “事故相關信息管理”處理過程條目描述
處理過程名稱:事故相關信息管理
處理過程編號:P3.3
簡述:事故組交警子調查現場后,需要對跟事故相關的證人,車輛進行登記管理 輸入數據流:事故相關信息
輸出數據流:提交狀態
處理邏輯:事故組交警獲取事故相關的證人信息、證件、相關車輛信息錄入系統 數據庫
表3-47 “事故處理信息表”存儲詞條描述
數據流名稱:事故處理信息表
簡述:對事故現場的處理信息
數據組成:處警ID+報警BD+出警人ID+出警人姓名+到達現場時間+現場結束時 間+處理方式+處置結果+結果反饋+暫扣車輛+匯報情況+處理狀態+備注 存儲方式:以處警ED為關鍵字
表3"8 “事故登記表”存儲詞條描述
數據流名稱:事故登記表
簡述:事故組交警登記的事故現場調查信息
數據組成:報警ID+警情地址+急救標志+涉及危險品+逃逸標志+發案區域編號+ 管轄中隊+處理人+記錄人+案件標志+注銷標志+是否歸檔
存儲方式:以活動名稱為關鍵字
表349 “事故處理信息”數據流條目描述
數據流名稱:事故處理信息
簡述:事故現場處理過程信息
來源:事故組交警
去向:加工“事故處理信息管理”
數據組成:處警ID+報警ID+出警人ID+出警人姓名+到達現場時間+確場結束時 間+處理方式+處置結果+結果反饋+暫扣車輛+匯報情況+處理狀態
表3-50 “處理信息反饋”數據流條目描述
數據流名稱:處理信息反饋
簡述:系統自動反饋的處理信息提交信息 來源:加工“事故處理信息管理”
去向:事故組交警
數據組成:處警ID+報警ID+提交信息
表3-51 “事故調査信息”數據流條目描述
數據流名稱:事故調查信息
簡述:事故組交警對事故的調查信息
來源:事故組交警
去向:加工“事故調查信息管理”
數據組成:報警ID+警情地址+急救標志+涉及危險品+逃逸標志+發案區域編號+ 管轄中隊+處理人+記錄人+案件標志
表3-52 “提交狀態”數據流條目描述
數據流名稱:提交狀態
簡述:系統自動反饋的事故調査信息提交狀態
來源:加工“事故調查信息管理"
去向:事故組交警
數據組成::報警ID+提交狀態信息
表3-53 “事故調議”數據流條目描述
數據流名稱:事故調查建議
簡述:大隊領導提出的事故調査建議
來源:大隊領導
去向:加工“事故調查信息管理”
數據組成:報警ID+建議信息
表3-54 “事故調查結果”數據流條目描述
數據流名稱:事故調査結果
簡述:大隊領導獲得的事故調查結果
來源:加工“事故調查信息管理”
去向:大隊領導
數據組成::報警DD+警情地址+急救標志+涉及危險品+逃逸標志+發案區域編號 +管轄中隊+處理人+記錄人+案件標志+是否注銷
表3-55 “事故相關借息”數據流條目描述
數據流名稱:事故相關信息
簡述:事故交警組收集的事故相關信息
來源:事故組交警
去向:加工“事故相關信息管理”
數據組成:報警ID+警情地址+急救標志+涉及危險品+逃逸標志+發案區域編號+ 管轄中隊+處理人+記錄人+案件標志+注銷標志+是否歸檔+證件編號+證件類型+ 目擊人姓名
4沖4.4事故調'l
\解管理>
亠、7
3-6事故輔助管理二層數據流圖
如上圖3-6所示,事故輔助管理二層數據流圖對系統一層數據流圖中的P4 數據流程進行了細化。P4數據流程由公開聽證管理、責任認定管理、行政處罰 管理、事故調解管理四個處理過程構成。流程中需要使用到的數據庫表包括案件 信息表以及事故調解信息表。 f
表3-56 “公開聽證管理”處理過程條目描述
處理過程名稱:公開聽證管理
處理過程編號:P4.1
簡述:事故后處理交警召集當事人進行公開聽證,并將公開聽證信息記錄下來 輸入數據流:公開聽證信息
輸出數據流:提交信息 .
處理邏輯:事故后處理交警將公開聽證信息錄入系統數據庫
表3-57 «責任認定管理”處理過程條目描述
處理過程名稱:責任認定管理
處理過程編號:P4.2
簡述:事故后處理交警根據公開聽證信息對事故責任人進行認定,并制作責任認 定書
輸入數據流:責任認定書、責任認定審批信息
輸出數據流:責任認定信息
處理邏輯:事故后處理交警制作責任認定書并上傳至系統,大隊領導對責任認定 信息進行審批
表3-58 “行政處罰管理”處理過程條目描述
處理過程名稱:行政處罰管理
處理過程編號:P4.3
簡述:事故處理組交警制定行政處罰意見,大隊領導對處罰意見進行審批
輸入數據流:行政處罰意見、行政處罰審批信息
輸出數據流:審批結果
處理邏輯:事故后處理交警將制定好的行政處罰意見上傳至系統,大隊領導查 看后,插入審批信息
表3-59 “事故調解管理”處理過程條目描述
處理過程名稱:事故調解管理
處理過程編號:P4.4
簡述:事故后處理交警征求當事人的調解意愿對事故進行調解,并將事故調解信
息錄入系統數據庫
輸入數據流:事故調解信息、事故損害賠償信息
輸出數據流:當事人調解意愿
處理邏輯:事故后處理交警在征求當事人的調解意愿后,制作事故調解書,并將 事故調解信息錄入系統數據庫
表3-60 “事故調解信息”存儲詞條描述
數據流名稱:事故調解信息
簡述:事故后處理交警根據當事人調解意愿記錄的事故調解信息
數據組成:案件ID+事故當事人1姓名+事故當事人2姓名+責任人姓名+損害賠 償數量+調解意愿+調節時間+調解結果
存儲方式:以教育活動名稱為關鍵字
表341 “公開聽證信息”數據流條目描述
數據流名稱:公開聽證信息
簡述:公開聽證會上記錄的公開聽證信息
來源:事故后處理交警
去向:加工“公開聽證管理”
數據組成:報警ID+警情地址+急救標志+涉及危險品+逃逸標志+發案區域編號+ 管轄中隊+處理人+記錄人+案件標志+注銷標志+是否歸檔+證件編號+證件類型+ 目擊人姓名
表3-62 “責任認定書”數據流條目描述
數據流名稱:責任認定書 *
簡述:事故后處理交警制作的責任認定書
來源:事故后處理交警
去向:加工“責任認定管理”
數據組成:案件ID+事故當事人1姓名+事故當事人2姓名+責任人姓名+損害賠 償數量
表3>63 “責任認定審批信息”數據流條目描述
數據流名稱:責任認定審批信息
簡述:大隊領導對責任認定書的審批信息
來源:大隊領導
去向:加工“責任認定管理”
數據組成:案件ID+事故當事人1姓名+事故當事人2姓名+責任人姓名+損害賠 償數量+審批信息+審批人
表3-64 “行政處罰意見”數據流條目描述
數據流名稱:行政處罰意見
簡述:事故后交警提出的行政處罰意見
來源:事故后處理交警
去向:加工“行政處罰管理”
數據組成:案件ID+責任人姓名+損害賠償數量+處罰意見
表345 “行政處罰童見審批借息”數據流條目描述
數據流名稱:行政處罰意見審批信息
簡述:大隊領導對行政處罰意見的審批信息
來源:大隊領導
去向:加工“行政處罰管理”
數據組成:案件ID+責任人姓名+損害賠償數量+處罰意見+審批意見+審批人
表3-66 “事故調解信息”數據流條目描述
數據流名稱:事故調解信息
簡述:事故后處理交警隊當事人調解意愿的記錄信息
來源:事故后處理交警
去向:加工“事故調解管理”
數據組成:案件ID+事故當事人1姓名+事故當事人2姓名+責任人姓名+損害賠 償數量+調解意愿
表3-67 “當事人調解意愿”數據流條目描述
數據流名稱:當事人調解意愿
簡述:事故當事人對事故的調解意愿
來源:加工“事故調解管理”
去向:事故后處理交警
數據組成:事故當事人姓名+調解意愿
表3_68 “事故賠償《害信息”數據流條目描述
數據流名稱:事故賠償損害信息
簡述:當事人獲得的事故損害賠償信息
來源:加工“事故調解管理”
去向:當事人
數據組成:案件ID+事故當事人1姓名+事故當事人2姓名+責任人姓名+損害賠
償數量
3.23.5査詢統計管理二層數據流圖
圖3-7查詢統計管理二層數據流圖
如上圖3-7所示,查詢統計管理二層數據流圖對系統一層數據流圖中的P5 數據流程進行了細化。P5數據流程由案件查詢管理、案件統計管理、扣放車臺 賬管理、保證金臺賬管理四個處理過程構成。該模塊涉及到的數據表有案件信息 表、案件統計報表、扣放車臺賬、保證金臺賬。
表3-69 “案件査詢管理”處理過程條目描述
處理過程名稱:案件查詢管理
處理過程編號:P5.1
簡述:交警對申請查詢案件,大隊領導設置案件對交警可見
輸入數據流:案件查詢申請、案件查詢審批信息
輸出數據流:案件信息
處理邏輯:交警提交案件査詢申請,大隊領導對查詢申請進行審批并設置案件對
該交警可見
表3-70 “案件統計管理” 婭過程條目描述
處理過程名稱:案件統計管理
處理過程編號:P5.2
簡述:交警隊日常報案信息進行統計
輸入數據流:日常辦案信息
輸出數據流:案件統計信息
處理邏輯:交警獲取日常辦案信息,并選擇統計方式,系統自動對日常辦案信息 進行統計
表3-71 “扣放車臺賬管理”處理過程條目描述
處理過程名稱:扣放車臺賬管理
處理過程編號:P5.3
簡述:系統管理人人員對扣放車臺賬進行統計
輸入數據流:扣放車信息
輸出數據流:扣放車輛統計信息
處理邏輯:系統管理人員獲取案件統計報表信息,并選擇扣放車信息,對其進行 統計,選擇統計方式,生成扣放車臺賬。
表,72 “保證金臺賬管理”處理過程條目描述
處理過程名稱:保證金臺賬管理
處理過程編號:P5.4
簡述:系統管理人人員對保證金臺賬進行統計
輸入數據流:保證金信息
輸出數據流:保證金統計信息
處理邏輯:系統管理人員獲取案件統計報表信息,并選擇保證金信息,對其進行 統計,選擇統計方式,生成保證金臺賬。
表3-73 "案件信息表”存儲詞條描述
數據流名稱:案件信息表
簡述:交警需要查詢的案件信息
數據組成:案件ID+案件歸檔時間+案件正文+報警ID+處警ID+案件爸注
存儲方式:以案件歸檔時間為關鍵字
表3-74 “案件統計報表”存儲詞條描述
數據流名稱:案件統計報表
簡述:交警隊日常辦案信息進行的統計信息
數據組成:統計報表ID+統計時間+統計項目1+統計結果1+統計項雯+統計結 果
存儲方式:以統計時間為關鍵字
表3-75 “扣放車臺賬”存儲詞條描述
數據流名稱:扣放車臺賬
簡述:系統管理人員對扣放車臺賬的統計
數據組成:扣放車臺賬ID+案件ID+扣放車ID+扣放車型號+扣放車所屬人姓名+ 扣留日期+扣放狀態
存儲方式:以扣放車型號為關鍵字
表3-76 “保證金臺賬”存儲詞條描述
數據流名稱:保證金臺賬
簡述:系統管理人員對保證金臺賬的統計
數據組成:保證金臺賬ID+案件ID+責任人姓名+保證金數目+繳納狀態+繳納數 目+繳納時間
存儲方式:以責任人姓名為關鍵字
表3-77 “案件査詢申請”數據流條目描述
數據流名稱:案件查詢申請
簡述:交警提交的案件查詢申請信息
來源:一般交警
去向:加工“案件查詢管理”
數據組成:案件ID+申請內容+申請日期+申請人
表3-78 “案件查詢審批信息”數據流條目描述
數據流名稱:案件査詢審批信息
簡述:大隊領導對案件査詢申請的審批信息
來源:大隊領導
去向:加工“案件查詢管理”
數據組成:案件ID+申請內容+申請日期+申請人+審批人+審批日期
表3-79 “案件信息”數據流條目描述
數據流名稱:案件信息
簡述:交警查詢到的案件信息
來源:加工“案件查詢管理”
去向:交警
數據組成:案件ID+案件歸檔時間+案件正文+報警ID+處警ID+案件備注
表3-80 “日常辦案信息”數據流條目描述
數據流名稱:日常辦案信息
簡述:交警收集的日常辦案信息信息
來源:交警
去向:加工“案件統計管理”
數據組成:案件ID+案件歸檔時間+案件正文+報警ED+處警ID+案件備注
表3-81 “案件統計信息”數據流條目描述
數據流名稱:案件統計信息
簡述:系統自動統計的案件信息
來源:加工“案件統計管理”
去向:交警
數據組成:統計報表ID+統計時間+統計項目1+統計結果1+統計項目片統計結 果
表3-82 “扣放車輛信息”數據流條目描述
數據流名稱:扣放車輛信息
簡述:管理人員選擇的扣放車輛信息
來源:系統管理人員 _
去向:加工“扣放車臺賬管理”
數據組成:案件ID+扣放車ID+扣放車型號+扣放車所屬人姓名+扣留日期+扣放 狀態
表3-83 “扣放車輸統計信息”數據流條目描述
數據流名稱:扣放車輛統計信息
簡述:系統管理人員選擇統計方式后,系統自動統計的扣放車輛信息
來源:加工“扣放車臺賬管理”
去向:系統管理人員
數據組成:扣放車臺賬ID+案件ID+扣放車ID+扣放車型號+扣放車所屬人姓名+ 扣留日期+扣放狀態
表3-84 “保證金信息”數據流條目描述
數據流名稱:保證金信息
簡述:系統管理人員獲取到的保證金信息
來源:系統管理人員
去向:加工“保證金臺賬管理”
數據組成:案件ID+責任人姓名+保證金數目+繳納狀態+繳納數目+繳納時間
表3-85 “保證金統計信息”數據流條目描述
數據流名稱:保證金統計信息
簡述:系統自動對保證金進行統計,生成保證金臺賬
來源:加工“保證金臺賬管理”
去向:系統管理人員
數據組成:保證金臺賬ID+案件ID+責任人姓名+保證金數目+繳納狀態+繳納數
目+繳納時間
3.2.3.6系統管理二層數據流圖
表3-86處理過程“用戶管理”條目描述
處理過程名稱:用戶管理
處理過程編號:P6.1
簡述:系統管理員對用戶信息的管理
輸入數據流:用戶維護信息
輸出數據流:用戶信息
處理邏輯:管理人員在數據庫中用戶信息進行添加、刪除、修改等維護操作
表3-87處理過程“用戶權限管理”條目描述
處理過程名稱:用戶權限管理
處理過程編號:P6.2
簡述:系統管理員對用戶權限的管理和維護
輸入數據流:權限維護信息 兼
輸出數據流:用戶權限信息
處理邏輯:管理人員對用戶進行權限分配和設置
表348處理過程志信息管理”條目描述
處理過程名稱:日志信息管理
處理過程編號:P6.3
簡述:管理人員對操作日志進行管理
輸入數據流:查詢范圍信息
輸出數據流:日志信息
處理邏輯:系統管理人員選擇要查詢的日志日期,查看或刪除日志信息
表3-89 “用戶信息”存儲詞條描述
數據流名稱:用戶信息
簡述:系統自動計算黨員的教育綜合評分并進行了排名系統所有用戶的信息 數據組成:用戶ID+用戶名+權限ID+姓名+性別+生日期+民族+身份證號+照片+ 電話號碼+郵箱地址+通訊地址
存儲方式:以黨員姓名為關鍵字
表3-90 “權限信息”存儲詞條描述
數據流名稱:權限信息
簡述:系統管理人員為用戶分配的權限信息
數據組成:權限ID+功能ID+功能名稱+權限說明
存儲方式:以功能名稱為關鍵字
表卻1 “系統H志信息”存儲W條描述
數據流名稱:系統日志信息
簡述:系統自動記錄的日志信息
數據組成:日志ID+操作類型+詳細信息+操作時間+用戶ID
存儲方式:以操作類型為關鍵字
表3-92 “用戶會信息”數據流條目描述
數據流名稱:用戶維護信息
簡述:管理人員對用戶信息的維護信息
來源:管理人員
去向:加工“用戶管理”
數據組成:用戶ID+用戶名+維護信息
表3-93 “用戶信息”數據流條目描述
數據流名稱:用戶信息
簡述:管理人員獲取到的用戶信息
來源:加工“用戶管理”
去向:管理人員
數據組成:用戶DD+用戶名+權限ID+姓名+性別+生日期+民族+身份證號+照片+ 電話號碼+郵箱地址+通訊地址
表3-94 “權限鞫信息”數據流條目描述
數據流名稱:權限維護信息
簡述:管理人員對用戶權限信息的維護信息
來源:管理人員
去向:加工“用戶權限管理”
數據組成:權限ID+功能ID+維護信息
表3-95 “權限信息”數據流條目描述
數據流名稱:權限信息
簡述:管理人員獲取到的用戶權限信息
來源:加工“用戶權限管理"
去向:管理人員
數據組成:權限ID+功能DD+功能名稱+權限說明
表3-96 “日志信息”數據流條目描述
數據流名稱:日志信息
簡述:管理人員獲取到的日志信息
來源:加工“系統日志管理”
去向:加工“教育綜合評價指標權重設置”管理人員 數據組成:日志ID+操作類型+詳細信息+操作時間+用戶ID
表3-97 “査詢范圍信息”數據流條目描述
數據流名稱:查詢范圍信息
簡述:管理人員輸入要查詢日志的日期信息
來源:管理人員
去向:加工“日志信息管理”
數據組成:日期
3.3系統功能結構
3.3.1總體功能結構圖
南呂市道路交通事故處理倍息管理系統
圖3-9總體功能結構圖
如上圖3-9所示,在對南昌市道路交通事故處理信息管理系統的一層數據流 圖進行分析后,我們可以將系統的總體功能結構分為六大功能模塊,分別是基礎 信息管理模塊、事故接出警管理模塊、事故處理管理模塊、事故輔助管理模塊、 查詢統計管理模塊和系統管理模塊。基礎信息管理模塊提供給交警對交警信息、 車輛信息、區段信息以及法律法規信息進行錄入,由系統管理人員對這些基礎數 據進行維護。事故接出警管理模塊主要提供給指揮調度組交警、大隊領導、系統 管理人員三種角色使用,指揮調度組交警利用該模塊對事故報警信息進行登記并 得到報警受理信息,系統管理人員利用該模塊對事故報警信息作出受理判斷,反 饋給事故調度組交警,大隊領導通過該模塊對出警信息進行審批。事故處理管理 模塊主要提供給事故組交警、大隊領導兩種種角色使用,事故組交警利用該模塊 進行事故處理信息以及事故相關信息進行錄入,大隊領導利用該模塊發布事故調 查意見。事故輔助管理模塊主要提供給事故處理后交警和大隊領導兩種角色使 用,事故后處理交警利用該模塊錄入交通事故聽證信息、事故責任認定書、事故 調解信息,大隊領導利用該模塊對責任認定以及行政處罰意見進行審批。查詢統 計管理模塊主要提供給一般交警、大隊領導、系統管理員三種角色種角色使用,
交警利用該模塊提交案件查詢申請,并對日常辦案信息進行統計,大隊領導利用 該模塊對案件查詢申請進行審批,系統管理人員利用査詢統計模塊對扣放車輛信 息以及保證金信息進行匯總統計。系統管理模塊主要提供給系統管理人員使用, 系統管理人員可以對用戶信息、權限信息以及日志信息進行維護。
3.3.2子功能結構圖
3.3.2.1基礎倩息管理功能
基礎信息管理
圖3-10基礎信息管理功能結構圖
如圖3-10所示,在對南昌市道路交通事故處理信息管理系統的基礎信息管 理模塊的二層數據流圖進行分析后,我們可以將模塊分為四個子功能模塊:交警 信息管理模塊、車輛信息管理、區段信息管理、法律法規信息管理。交警信息管 理模塊主要是對交警的基本信息進行添加、修改、刪除等維護管理;車輛信息管 理模塊主要是對車管所登記的車輛信息進行維護管理;區段信息管理模塊主要是 對南昌市的區段信息進行更新和維護;法律法規管理模塊主要是對需要更改的法 律條文進行更改,對新的法律法規進行添加。
3.3.2.Z事故接出警管理功能
事故接出警管理
圖3-11事故接出警管理功能結構圖
如圖3-11所示,在對南昌市交通事故處理信息系統的事故接出警管理模塊 的二層數據流圖進行分析后,我們可以將模塊分為報警信息登記、報警受理、出 警安排、出警審批四個子功能模塊。
3.3.2.3事故處理管理功能
事故處理管理
如圖3-13所示,在對南昌市交通事故處理信息系統的事故接出警管理的二 層數據流圖進行分析后,將此模塊分為事故處理信息管理、事故調查信息管理、 事故相關信息管理三個子功能模塊。
3.3.2.4事故輔助管理功能
事故輔助管理
I 〔
圖3-13事故輔助管理功能結構圖
如上圖3-13所示,在在對南昌市交通事故處理信息系統的事故輔助管理二 層數據流圖的分析后,我們可以把事故輔助信息管理模塊劃分為公開聽證管理、 責任認定管理、行政處罰管理以及事故調解管理四個子功能模塊。
3.3.2.5査詢統計管理功能
圖3-14 統計管理功能結構圖
如上圖3-14所示,在對南昌市交通事故處理信息系統的查詢統計管理模塊 的二層數據流圖的分析,我們確定將該模塊劃分為案件査詢管理、案件統計管理、 扣放車臺賬管理以及保證金臺賬管理四個子功能模塊。
3.3.2.6系統管理功能
系統管理
圖3-15系統管理功能結構圖
在對奉新縣供電公司黨員教育管理系統系統管理模塊的二層數據流圖進行 分析后,我們可以將模塊劃分為三個子功能,分別是用戶管理、用戶權限管理以 及日志信息管理。
第四章數據分析
4.1實體關系分析
實體屬性圖反映的是實體所具有若干屬性的一種圖形。依據系統數據流圖分 析,下面以模型圖的方式來表示系統涉及到的交警信息、車輛信息、區段信息、 法律法規信息、報警信息、出警信息、事故處理信息、事故登記信息、事故調解 信息、案件信息、案件統計報表、扣放車輛臺賬、保證金臺賬用戶信息、用戶權 限信息、日志信息等十九個實體。
如上圖4-1所示,交警信息實體的屬性包括交警ID、交警姓名、用戶ID、 用戶名、權限ID、性別、身份證號、所在地、警銜、聯系電話、照片、參警年 齡、是否空閑、文化程度、資格證編號、職務。
如上圖4-2所示,車輛信息實體的屬性有車輛ID、車輛型號、車輛廠牌、 車輛類型、載客數、載質量、輪胎數量、車輛軸距、車輛長、車輛寬、車輛寬。
如上圖4-3所示,區域信息實體的屬性有區域路段ID、區域代碼、區域名 稱、路段代碼、路段名稱、公里數。
如上圖44所示,法律法規信息實體的屬性有法律條文ID、隸屬類別、條 文名稱、條文正文、查詢次數。
如上圖4-5所示,報警登記實體的屬性有報警ID、報警警號、報警時間、報警 人姓名、報警電話、事故地點、傷亡情況、備注。
如上圖4-6所示,出警信息實體的屬性有報警ID、出警人1ID、出警人2ID、
如上圖4-7所示,事故處理信息實體的屬性有處警ID、報警ID、處警人姓 名、到達現場時間、現場結束時間、處理方式、處置結果、結果反饋、暫扣車輛、 匯報情況、處理狀態、備注。
如上圖4-8所示,事故登記信息實體的屬性有報警ID、警情地址、急救標 志、涉及危險品、逃逸標志、法按區域編號、管轄中隊、處理人、記錄入、案件 標志、注銷標志。
如上圖4-9所示,案件信息實體的屬性有案件ID、案件歸檔時間、案件正 文、案件備注、備注。
如上圖4-10所示,事故調解信息實體的屬性有案件ID、事故當事人1姓名、 事故當事人2姓名、責任人姓名、損害賠償數量、調解意愿、調解時間、調解結 果、備注。
如圖4-11所示,案件統計報表實體屬性有統計報表ID、統計時間、統計項 目1、統計結果1、統計項目2、統計結果2.
如上圖4-12所示,扣放車臺賬實體的屬性有扣放車臺賬ID、案件ID、扣放 車輛ID、扣放車型號、扣放車所屬人姓名、扣留日期、扣放狀態、備注。
如上圖4-13所示,保證金臺賬實體的屬性有保證金臺賬ID、案件ID、責任 人姓名、保證金數目、繳納狀態、繳納數目、繳納時間、備注。
如上圖4-14所示,用戶信息實體的屬性有用戶ID、用戶名、性別、姓名、
出生日期、民族、身份證ID、照片、電話號碼、郵箱地址、通訊地址、權限ID。
權限說明。
如上圖4-16所示,系統日志信息實體的屬性有日志ID、操作類型、詳細信 息、操作時間、用戶IDo
由于南昌市道路交通事故處理信息管理系統的基礎信息管理數據流圖涉及 交警信息、車輛信息、區段信息以及法律法規信息;事故接出警管理數據流圖涉 及報警登記信息、出警信息;事故處理管理數據流圖涉及事故處理信息、事故登 記信息;事故輔助管理數據流圖涉及事故調解信息;查詢統計管理數據流圖涉及 案件統計信息、扣放車輛信息以及保證金臺賬;系統管理涉及到用戶信息、用戶 權限信息、系統日志信息。因此,南昌市道路交通事故處理信息管理系統包含交 警信息、車輛信息、區段信息、法律法規信息、報警登記信息、出警信息、事故 處理信息、事故登記信息、事故調解信息、用戶信息、用戶權限信息、系統日志 信息共十六個實體。
圖4-17奉新縣供電公司黨員教育管理系統主要實體關系圖
如圖4-17所示,用戶信息包含用戶權限信息,所以用戶信息與用戶權限信 用戶息存在包含關系,并且一個用戶對應一種權限,所以用戶信息與用戶權限信 息存在1對1的關系;由于交警屬于系統的用戶,警信息與用戶信息存在從屬關 系,一個交警在系統中對應一個用戶,所以交警信息與用戶信息存在1對1關系; 由于交警可以獲取車輛信息,交警信息與車輛信息存在獲取關系,并且一個交警 可以獲取多個車輛信息,所以交警信息與車輛信息的關系是1對多;交警可以查 詢案件信息,因此交警信息和案件信息存在查詢關系,并且多個交警可以查詢多 個案件,所以交警信息與案件信息存在多對多的關系。
4.2數據庫表
(1)交警信息
保存交警的基本信息
表4-1交警信息表
字段名 數據類型 長度 鍵
交警1D 字符型 20 主鍵
交警姓名 字符型 20 否
用戶ID 字符型 20 外鍵
用戶名 字符型 20 否
權限ID 字符型 20 否
性別 布爾型 否
身份證號 字符型 20 否
所在地 字符型 20 否
聯系電話 字符型 20 否
照片 二進制型 否
參警年齡 字符型 20 否
文化程度 字符型 20 否
資格證編號 字符型 20 否
職務 字符型 20 否
警銜 字符型 20 否
是否空閑 布爾型 否
交警ID是表4-1交警信息表的主鍵,它是唯一標識該表中所有行的一個列 或一組列。用八II)是建立和加強表4T交警信息表與表4-14 JlJ/'fii息表數據鏈 接的一列,故用戶ID是表4-1黨員信息的外鍵。
(2)車輛信息表
保存車輛基本信息
表4-2車輛信息表
字段名 數據類型 長度 鍵
車輛ID 字符型 20 主鍵
車輛型號 字符型 20 否
車輛廠牌 字符型 20 否
車輛類型 字符型 20 否
載客數 字符型 20 否
載質量 布爾型 否
輪胎數量 字符型 20 否
車輛軸距 字符型 20 否
車輛長 字符型 20 否
車輛寬 字符型 20 否
車輛高 字符型 20 否
車輛ID是表4-2車輛信息表的主鍵,它是唯一標識該表中所有行的一個列 或一組列。
(3)區段信息表
保存區域路段信息
表4-3區段信息表
字段名 數據類型 長度 鍵
區域路段ID 字符型 20 主鍵
區域代碼 ?符型 20 否
區域名稱 字符型 20 否
路段代碼 字符型 20 否
路段名稱 字符型 20 否
公里數 字符型 20 否
區域路段ID是表4-3區域信息表的主鍵,它是唯一標識該表中所有行的一 個列或一組列。
(4)法律法規信息表
保存法律法規更新信息
表4-4法律法規信息表
字段名 數據類型 長度 鍵
法律條文ID 字符型 20 主鍵
隸屬類別 字符:里 20 否
條文名稱 字符型 20 否
條文正文 字符型 300 否
查詢次數 字符型 20 否
法律條文ID是表4-4法律法規信息表的主鍵,它是唯一標識該表中所有行的 一個列或一組列。
(5)報警登記表
保存報警信息
表4-5報警登記表
字段名 數據類型 長度 鍵
報警ID 字符型 20 主鍵
報警警號 字符型 20 否
報警時間 日期型 否
報警人姓名 字符型 20 否
報警電話 字符型 20 否
事故地點 字符型 20 否
傷亡情況 字符型 100 否
備注 字符型 20 否
報警ID是表4-5報警登記表的主鍵,它是唯一標識該表中所有行的一個列或 一組列。
(6)出警信息表
保存出警人員信息
表4-6出警信息表
字段名 數據類型 長度 鍵
報警ID 字符型 20 主鍵
出警人1ID 字符型 20 外鍵
出警人2ID 字符型 20 外鍵
出警人1姓名 字符型 20 否
出警人2姓名 字符型 20 否
出警時間 字符型 20 否
審批信息 字符型 2() 否
備注 字符型 20 否
報警ID是表4-6出警信息表的主鍵,它是唯一標識該表中所有行的一個列 或一組列。出警人1ID和出警人2ID等等是建立和加強表4-6出警信息表與表 4-1交警信息表數據鏈接的一列,故出警人1ID和出警人2ID等等是表4-6出警 信息表的外鍵。
(7)事故處理信息表
保存事故現場的處理信息
表4-7事故處理信息表
字段名 數據類型 長度 鍵
處警ID 字符型 20 主鍵
報警ID 字符型 20 外鍵
處警人ID 字符型 20 外鍵
處警人姓名 字符型 20 否
到達現場時間 字符型 20 否
現場結束時間 字符型 20 否
處理方式 字符型 20 否
處置結果 字符型 20 否
結果反饋 字符型 20 否
暫扣車輛 字符型 20 否
匯報情況 字符型 100 否
處理狀態 字符型 20 否
備注 字符型 20 否
處理ID是表4-7事故處理信息表的主鍵,它是唯一標識該表中所有行的一個 列或一組列。報警ID是建立和加強表4-5報警登記表與表4-7事故處理信息表 數據鏈接的一列,出警人ID是建立和加強表4-1交警信息表與表4-7事故處理 信息表數據鏈接的一列,故報警ID以及出警人ID是表4-7學習體會信息的外鍵。
(8)事故登記表
保存事故調查的信息
表4-8事故登記表
字段名 數據類型 長度 鍵
報警ID 字符型 20 主鍵
警情地址 字符型 20 否
急救標志 字符型 20 否
涉及危險品 字符型 20 否
逃逸標志 字符型 20 否
發案區域ID 字符型 20 外鍵
管轄中隊 字符型 20 否
處理人 字符型 20 否
記錄人 字符型 20 否
案件標志 字符型 20 否
注銷標志 字符型 20 否
是否歸檔 字符型 20 否
報警ID是表4-8事故登記表的主鍵,它是唯一標識該表中所有行的一個列或 —組列。發案區域ID是建立和加強表4-3區段信息表與表4-8事故登記表數據 鏈接的一列,故發案區域ID是表4-8事故登記表的外鍵。
(9)案件信息表
保存案件信息
表4-9案件信息表
字段名 妳類型 長度 鍵
案件ID 字符型 20 主鍵
案件歸檔時間 字符型 20 否
案件正文 字符型 200 否
報警ID 字符型 20 外鍵
處警ID 字符型 20 外鍵
案件備注 字符型 20 否
備注 字符型 20 否
案件ID是表4-9案件信息表的主鍵,它是唯一標識該表中所有行的一個列或 一組列。報警ID是建立和加強表4-5報警登記表與表4-9案件信息表數據鏈接 的一列,處警ID是建立和加強表4-7事故處理信息表與表4-9案件信息表數據 鏈接的一列,故報警ID以及處警ID是表4-9案件信息表的外鍵
(10)事故調解信息表
保存事故的調解信息
表表4-10事故調解信息表
字段名 數據類型 長度 鍵
案件ID 字符型 20 主鍵
事故當事人1姓名 字符型 20 否
事故當事人2姓名 字符型 20 否
責任人姓名 字符型 20 否
損害賠償數量 字符型 20 否
調解意愿 字符型 20 否
調解時間 1丨期型 否
調解結果 字符型 20 否
備注 字符型 20 否
案件ID是表4-10事故調解信息表的主鍵,它是唯一標識該表中所有行的一
個列或一組列。
(11)案件統計報表
保存案件的統計信息
表4-11案件統計報表
字段名 數據類型 長度 鍵
統計報表ID 字符型 20 主鍵
統計時間 字符型 20 否
統計項目I 字符型 20 否
統計結果1 字符型 20 否
統計項目2 字符型 20 否
統計結果2 字符型 20 否
統計報表ID是表4-11案件統計報表的主鍵,它是唯一標識該表中所有行的 一個列或一組列。
(12)扣放車臺賬
保存扣放車匯總信息
表4-12扣放車臺賬
字段名 數據類型 長度 鍵
扣放車臺賬ID 字符型 20 主鍵
案件ID 字符型 20 外鍵
扣放車型號 字符型 20 否
扣放車所屬人姓名 字符世 20 否
扣留日期 日期型 否
扣放狀態 布爾型 否
備注 字符型 20 否
扣放車臺賬ID是表4-12扣放車臺賬的主鍵,它是唯一標識該表中所有行的 一個列或一組列。案件ID是建立和加強表4-12扣放車臺賬與表4- 9案件信息 表數據鏈接的一列,故黨員ID是表4-12扣放車臺賬的外鍵。
(13)保證金臺賬
保存保證金統計信息
表4-13保證金臺賬
字段名 數據類型 長度 鍵
保證金臺賬ID 字符型 20 主鍵
案件ID 字符型 20 外鍵
責任人姓名 字符型 20 否
保證金數目 字符型 20 否
繳納狀態 布爾型 否
繳納數目 字符型 20 否
繳納時間 日期型 否
備注 字符型 20 否
保證金臺賬ID是表4-13保證金臺賬的主鍵,它是唯一標識該表中所有行的 一個列或一組列。案件ID是加強表4-13保證金臺賬和表4-9案件信息的數據鏈 接的一列,故案件ID是表4-13保證金臺賬的外鍵。
(14)用戶信息表
保存系統的用戶信息
表4-14用戶信息表
字段名 數據類型 長度 鍵
用戶1D 字符型 20 主鍵
用戶名 字符型 20 否
權限ID 字符型 20 否
姓名 字符型 20 否
性別 布爾型 否
出生日期 日期型 否
民族 字符型 20 否
身份證號 字符型 20 否
照片 二進制型 否
電話號碼 字符型 20 否
郵箱地址 字符型 20 否
通訊地址 字符型 20 否
用戶ID是表4-14用戶信息表的主鍵,它是唯一標識該表中所有行的一個列 或一組列。
(15)權限信息表
保存用戶的權限信息
表4-15權限信息表
字段名 數據類型 長度 鍵
權限ID 字符型 20 主鍵
功能ID 字符型 20 否
功能名稱 字符型 20 否
權限說明 字符型 20 否
權限ID是表4-15權限信息表的主鍵,它是唯一標識該表中所有行的一個列 或一組列。
(16)系統日志信息表
保存系統的日志信息
表4-16系統日志信息表
字段名 數據類型 長度 鍵
日志ID 字符型 20 主鍵
操作類型 字符型 20 否
詳細信息 字符型 20 否
操作時間 字符型 20 否
用戶ID 字符型 20 外鍵
日志ID是表4-16系統日志信息表的主鍵,它是唯一標識該表中所有行的一 個列或一組列。
第五章總結與展望
5.1總結
通過對本課題的研究,本人對南昌市交警大隊對道路交通事故處理信息管理 有了更進一步的了解,了解到了利用信息技術對交通事故處理信息的管理,可以 更加快速地對報警信息進行處理,對案件信息的管理也更加系統。以下列出了本 人在此次課題研究中的幾點總結:
(1)為了進行課題研究,本人回顧了軟件工程專業課程所學的內容,重新 梳理了結構化分析的過程。
(2)充分利用學校圖書館資源以及網絡資源,收集了大量有關交通事故處 理管理的文獻和資料,為南昌市道路交通事故處理信息管理系統的分析奠定基 礎。
(3)針對南昌市道路交通事故處理信息管理的現狀,對信息管理的過程做 了進一步優化,并進行了功能分析以及數據庫的設計。
(4)重新學習了數據庫系統的知識,掌握了數據庫邏輯結構的設計,并對 數據庫的范式有了概念性的理解。
5.2進一步的工作
在課題研究中,還出現了少許問題和想要擴展的其他工作,將其羅列如下:
(1)整體業務優化分析還有些不合理的地方,比如在事故處理管理模塊的 業務分析中,由于現場處理是必須要交警完成的,這種情況下對處理信息的記錄 就會岀現遺漏,上級獲取到的處理信息也有一定的滯后性。在下一步的工作中需 要將整體業務流程更加細化與合理化。
(2)數據庫表中字段的設計不夠精煉簡潔,需要刪除一些可有可無的字段, 完善數據庫表的設計。
(3)下一步,在對交通事故的這些信息進行記錄的同時,還可以利用這些 數據用來做進一步分析,挖掘出事故頻發地以及事故處理方式的一些信息,用來 預防交通事故大發生以及加快事故處理的速度。
(4)更多的加入系統的功能,減少其他人員的參與,減少人工成本與時間 成本。
參考文獻
[1]許博.無線局域網安全分析及其攻擊方法研究[D].西安電子科技大學,2010-06-25 11-12
[2]Extensible Markup Language(XML) 1.1 (Second Edition) [EB/OL],
[2007-07-26] .http://www.w3 .org/
[3]郭建華,黃衛,陸毅,劉新旺.高速公路工程質量管理系統數據庫設計[J].公路交通科
技,2001,18(4):35-39.
[4]呂禮佛.淺談道路交通事故處理[JJ.安全與健康,2006,15(18):4346.
⑸印洪浩.道路交通事故信息管理系統的研究與開發[J].重慶工學院學報,2006,21(02):56-5&
[6]邵祖峰,王秀華.道路交通事故處理難點調查分析[JJ.廣東公安科技,2007,8(02):55-57.
⑺郝建勛•道路交通事故分析方法應用研究[D].吉林大學,2008,16-19.
[8]劉紅梅.基于C/S和B/S體系結構應用系統的開發方法[J].唯實.2007(10)20-44
[9]張馳清,邵春福.公路交通信息管理系統的設計與實現[J].現代交通技術,2007,14(03):75-77.
[10]E.Memit. Calibration and Validation of CORSIM for Swedish Road Traffic Condition[J], Transportation Research Board Annual Meeting, 2004,24(13):89-92.
[11]常立冬,童械恭.溫州公安交警支隊交通事故處理系統數據交互更新方法探討[J].自動化與
信息技術,2010 (6):45-46.
[12]Pressman RS著,梅宏譯.軟件工程-實踐者的研究方法.[M]第5版.北京:機械工業出版 社 2012:432-436
[13]李剛.輕量級.NET交警應用實戰整合開發.[M]電子工業出版社2011:20-46
[14]陳次白.政府辦公自動化原理與應用.[M]北京:北京大學出版社,2010:31-32
[15]李一兵.道路交通事故處理系統設計與應用[J].公路交通科技,2003,(4):101 -104.
[16]李江.交通事故結案處理專家系統的初步探討[J].公路交通科技,2000,(1):51 -54.
[17]安實,王健,徐亞國等.城市智能交通管理技術與應用[M].北京:科學出版社,2007:
136?148
[18]劉麗英,潘景山,史永等.智能交通系統的發展狀況研究[JJ.信息技術與信息化, 2005, 6: 17-18
[⑼陸化普,王建偉,李江平等.城市交通管理評價體系[M].北京:科學出版社,2003: 1~ 7
[20]肖紅艷,盧國勝,代仁平.智能交通系統的體系結構淺析[J].城市公共交通,2006, 5: 25 ?27