熱門論文
最新論文
網約車安全信息管理平臺的設計與實現
發布時間：2023-01-02 16:35
目錄
摘要 iii
ABSTRACT v
1引言 1
1.1項目背景 1
1.2國內外發展現狀 1
1.2.1國內發展現狀 2
1.2.2國外發展現狀 2
1.3項目目標 3
1.4論文組織結構 3
1.5本章小結 4
2相關理論及技術概述 5
2.1Vue 5
2.2Echarts 5
2.3Spring Boot 6
2.4Postman 6
2.5MobileNet -V2 6
2.6本章小結 7
3網約車安全信息管理平臺需求分析 9
3.1需求分析綜述 9
3.11 產品特色分析 9
3.1.2用戶特征分析 11
3.2功能性需求分析 11
3.2.1綜合管理模塊需求分析 11
3.2.2數據展示模塊需求分析 14
3.2.3車單信息操作模塊需求分析 16
3.2.4安全規則定制模塊需求分析 18
3.2.5安全判責模塊需求分析 21
3.3非功能性需求分析 22
3.4本章小結 23
4網約車安全信息管理平臺概要設計 25
4.1設計目標 25
4.2總體功能結構 25
4.3技術實現架構 27
4.4數據庫設計 27
4.4.1綜合管理模塊 28
4.4.2數據展示模塊和車單信息操作模塊 30
4.4.3安全規則定制模塊 32
4.4.4安全判責模塊 34
4.5本章小結 36
5網約車安全信息管理平臺詳細設計與實現 37
5.1綜合管理模塊 37
5.1.1用戶登錄校驗 37
5.1.2操作文檔中心 41
5.2數據展示模塊 43
5.3車單信息操作模塊 45
5.3.1訂單號查詢訂單詳情信息 45
5.3.2關鍵字查詢和安全事件類型查詢 49
5.4安全規則定制模塊 53
5.4.1清洗規則制定 53
5.4.2操作清洗任務 56
5.5數據清洗實現部分 58
5.6安全判責模塊 60
5.7本章小結 62
6系統測試 65
6.1測試環境 65
6.2功能性測試 65
6.3非功性能測試 70
6.4本章小結 72
7總結與展望 73
7.1全文總結 73
7.2展望 74
參考文獻 75
作者簡歷及攻讀碩士/博士學位期間取得的研究成果 77
獨創性聲明 79
學位論文數據集 81
1引言
本章主要對網約車安全信息管理平臺進行概述，從項目的背景和意義、國內 外發展現狀、項目的目標以及組織結構等多個方面進行詳細的說明。
1.1項目背景
近年來隨著科技的發展，“網約車”開始走入了人們的生活，隨時隨地約車，相 比傳統打車，網上打車極大的方便了我們的日常，網約車改變了傳統的出行理念, 緩解了城市地出行壓力［1］。其特有的模式推動了現有出租車行業的改革升級，對傳 統的車行服務帶來了很大的改變［2］。同時，網約車也促進了共享經濟的發展，提高 汽車資源的利用率，為大家的生活帶來方便⑷。2015年至2019年網約車客運量連 續5年穩步提升，2018年網約車完成客運量突破200億人次。網上打車服務已經 覆蓋了全國31個省，可謂當下最“流行”的出行方式。
但與此同時，“網約車”的安全問題開始凸顯，相關法律法規還處于初創階段， 安全隱患如跗骨之蛆般時刻制約著網約車的發展⑷。全國多地接連發生網約車交通 事故、肢體沖突、失聯等安全事件，2018年5月鄭州空姐順風打車遇害一案更是 引爆了公眾神經，網約打車流程不規范、易發安全事故、事故發生后難以定責等 問題亟待解決。
網約車數據數量龐大，包含文字、圖片、語音、視頻、表格等多種類型，整 理復雜，問題排查步驟繁瑣，人工操作耗時長。傳統的安全數據處理方式通過純 人工從數目龐大的數據中排查隱患，分析識別車輛行程是否存在安全問題、違規 行為，不僅效率低下，而且正確性和實時性無法得到保障。為有效緩解此類問題 設計并研發了網約車安全信息管理平臺，用以統一整合公司內部網約車數據，對 數據進行分類、篩選、記錄和展示，協助安全工作人員進行安全制定、記錄和判 責。網約車安全信息管理平臺結合圖像識別、語音識別等算法和傳統前后端技術, 為上述問題提供了展示和操作場景，成為公司內部安全管理人員和運維人員提高 工作效率的有力工具，可作為網約車公司保障乘客乘車安全的重要組成部分。
1.2國內外發展現狀
網約車作為新興事物，還處于發展上升期，網約車新穎有效的運行方式對傳 統出租行業發起了有力的沖擊，在全球各地改善著當地居民的出行狀況岡。但是不 管國內還是國外，網約車安全策略都是難題，國內外網約車公司目前都未有成熟 的安全信息管理平臺，大都處于開發摸索中。
1.2.1國內發展現狀
國內主要網約車公司有滴滴出行、神州專車、易道、曹操專車等，各家網上 打車公司近些年如雨后春筍般的不斷涌現，各家雖有不同的服務側重點，但打車 模式接近相同，在網約車管理部分都處在探索發展階段。這其中滴滴出行作為國 內最大的網約車平臺，不管是打車的用戶還是加盟滴滴的車主和車輛也是最多的。 滴滴出行是一站式移動出行平臺，在亞洲、拉美和澳洲為5.5億用戶提供出行和運 輸服務，年運送乘客超過100億人次。自滴滴與快滴合并，又收購了 Uber中國之 后，滴滴出行已坐穩了國內網約車頭把交椅，占據了網約車客運量的絕大部分， 同樣，滴滴出行在打車過程中出現的安全問題也是最多的。
自2018年“順風車事件”以來，乘車安全和打車流程規范化已經成為滴滴出 行公司發展的重中之重。為此滴滴出行公司內部制定了多套相關規則和流程來提 高乘車的安全指數，不斷迭代安全功能和升級安全策略，如升級乘客端APP25次, 嘗試推出了“加密行程錄音、錄像”“醉酒報備”“黑名單”等新功能；加強警企合作， 優化警方調證流程；提升客服處置效率，持續增強線上、線下司乘安全教育；公 開、透明安全運營情況［7］。重點布局在乘車流程信息記錄、檢測、預警和安全事故 處理等方面，加大了客服和安全事件處理人員配置，并初步衍生出一批信息管理 和安全處理應用悶。但數據分散在各個職能部門，不同部門平臺間的數據交互成本 較高，數據還多以原始形態保存，在數據處理和篩選上還有待提升，內部客服、 安全工作人員處理安全事宜效率受制于龐大且種類紛繁的數據，往往無法直觀高 效的獲取所需的車單數據。安全規則制定人員、數據運維人員和安全事件操作人 員在數據的溝通上尚有一定壁壘，公司內部智能數據處理平臺仍在發展和迭代過 程中。
1.2.2國外發展現狀
國外網約車公司起步比中國略早，經過最初的野蠻發展，如今形成了以Uber （優步）為首，Lyft （來福特）緊隨其后的格局叫國外網約打車模式與我們所熟 知的流程基本相同，在公司布局全球市場的過程中，也面臨著與國內公司相似的 一些窘境，下面重點介紹一下國外網約車龍頭企業Uber的狀況。Uber（Uber Technologies,Inc.）中文翻譯做“優步”，是一家美國的科技公司。2009年加利福尼 亞大學洛杉磯分校學生特拉維斯•卡蘭尼克和好友加勒特•坎普(Garrett Camp)二 人一同創立了優步，公司主營同名打車APP,該APP平臺允許乘客通過手機發送 乘車請求，進而實現網上約車，優步因成功運營和發展此種新興打車出行模式而 名聲大噪回。Uber2014年3月進入中國大陸，并在全球范圍內覆蓋了 70多個國家 的400余座城市。優步公司在網約車的運營、平臺管理方面都有長足的發展，在 傳統駕駛行業與算法結合和自動駕駛等方面也有一定的發展［10］。但優步同樣為安 全問題所困擾，據統計，過去幾年，美國至少有100多名Uber司機被指控性侵乘 客。在經歷慘痛教訓后，優步公司也制定了多套安全措施，包括設定一鍵求救按 鈕，一旦用戶遭遇到危險，無需講話，直接點擊求救按鈕就可以給 911 發送自己 的姓名、實時位置、所乘車輛的品牌等，建立突發事件處理服務；加強司機背景 調查，與警方合作建立司機個人信息和信譽檔案等，用以改進和加強網約車運營 安全。優步的做法值得國內借鑒，但仍存在信息碎片化，安全取證困難，安全規 則難以適應各國各州不同的法律法規等問題。
1.3項目目標
該安全信息管理平臺的設計與實現旨在服務網約車公司內部安全相關工作人 員，提高工作人員處理安全數據的效率，助力減少安全隱患，增強網約車運營安 全。主要實現以下業務目標：
(1)實現打車過程全數據的存儲、展示和按需導出，提供數據的發展走向、 分布、變化等一系列圖表實現數據可視化，輔助安全預警。
(2)實現對數據的加工、分類和篩選，依托圖像識別、語音識別等算法對數 據進行智能操作。
(3)提供安全規則的配置、編輯和使用等功能。
(4)提供判責操作平臺，可對嫌疑車單進行甄別、判責和反饋等操作，輔助 規范打車流程。
1.4論文組織結構
本文共分為七個章節，每個章節主要內容如下： 第一章：引言，介紹本項目的背景、意義，對行業國內外發展狀況進行分析， 進而整理出項目的目標，并劃分論文的組織結構。
第二章：相關理論及技術概述，主要介紹網約車安全信息管理平臺在整個開 發和使用過程中所用到和涉及到的關鍵技術和理論。
第三章：需求分析，從產品特色、用戶特征、功能性需求和非功能性需求幾 個不同方面對項目的需求進行詳細的說明。
第四章：概要設計，本章闡述項目的設計目標，明確項目的整體功能結構和 技術架構，同時對數據庫表的設計內容進行了詳細的舉例和說明。
第五章：詳細設計與實現，通過文字結合流程圖、時序圖、類圖和相應實現 界面的截圖對項目五個模塊的詳細設計內容和實現狀況進行了細致的介紹。
第六章：系統測試，介紹系統的測試環境，對各個部分的功能測試和非功能 測試都給與介紹和舉例說明。
第七章：總結與展望：回顧整個過程，對項目取得的成果和不足進行總結， 同時結合行業發展的實際情況對項目未來的發展進行了展望。
1.5本章小結
本章對項目的背景和意義進行了分析，同時闡述國內外主要網約車公司對安 全事件和數據管理的狀況，由上述幾個方面總結出項目的主要目標，并對論文的 組織結構進行概括性的說明。
2相關理論及技術概述
本章節主要介紹信息管理平臺開在發過程中所用到的相關理論及技術，該平 臺采用B/S架構開發，前端部分主要采用HTML+CSS+JavaScript，框架使用Vue 以及Vue全家桶，采用MVVM模式，視圖組件和可視化方面使用了 iView和 Echarts。后端部分使用java編譯，框架為SpringBoot，數據庫采用MySQL，版本迭 代使用gitlab，測試接口使用了 Postman。
2.1Vue
目前前端最火的三個框架分別是Vue、React和angula，它們各有優缺點。其 中Vue是由國人尤雨溪開發的一套用于構建用戶界面的漸進式的JavaScript框架， 具有靈活、易用和高效等特點，其核心庫只關注視圖層，方便與第三方庫或既有 項目整合。相比較其他前端框架，Vue特點鮮明，基于MVVM模式，其特有的基 于Object.Property的數據雙向綁定極大地方便了前端開發過程中視圖與數據間的 處理，配套的Vue全家桶更是簡便了開發的復雜度，為程序開發者提供了一整套 集成服務［11］。
相比于React，Vue是一套輕量級的框架，代碼簡潔干凈，適合小型團隊和小 型項目。在前端框架的選擇過程中，綜合考慮到網約車安全信息管理平臺的項目 復雜度、前端展示需求和項目體量后，認為選用Vue作為前端框架更為合適。本 文的項目中還協同采用了 webpack進行配置打包，iView提供組件庫，使用Vuex 進行數據狀態存儲管理。
2.2Echarts
“數無形時少直覺”圖像可視化展示是當今數據管理平臺必不可少的一部 分。Echarts是由百度研發的基于JavaScript實現的開源可視化庫，它可以流暢的 運行在PC和移動設備上，兼容當前絕大部分瀏覽器(IE8/IE9/IE10/IE11, Chrome， Firefox，Safari等)，底層依賴矢量圖形庫ZRender，提供直觀，交互豐富，可高度 個性化定制的數據可視化圖表［12］。ECharts提供了常規的折線圖、柱狀圖、散點圖、 餅圖等多種可視化圖表，并且支持圖與圖之間的混搭。網約車安全信息管理平臺 承載了數量眾多且格式多樣的數據，這些數據需要以表格、折線圖、散點圖等眾 多樣式展現給用戶，讓安全數據直觀的體現出數據背后的信息。Echarts內置的 dataset屬性支持直接傳入包括二維表，key-value等多種格式的數據源，通過簡單 的設置就可完成從數據到圖形的映射，這種方式更符合可視化的直覺，省去了大 部分場景下數據轉換的步驟，使得多個組件可共用一套數據。Echarts結合Ajax技 術傳輸可以方便簡單的實現對數據的可視化展示，Echarts優秀的數據處理和展示 能力十分符合網約車安全信息管理平臺的開發需求購。
2.3Spring Boot
Spring Boot是由Pivotal團隊開發的框架，其設計目的是用來簡化新Spring應 用的初始搭建以及開發過程。換句話來說Spring Boot是一個簡化Spring開發的框 架，用來監護spring應用開發，約定大于配置，去繁就簡，just run就能創建一個 獨立的，產品級的應用。Spring Boot提供spring的自動配置，無需配置XML，無 代碼生成，開箱即用［14］。而Spring為簡化企業級開發而生，使用Spring開發可以 將Bean對象、Dao組件對象、Service組件對象等交給Spring容器來管理，這樣使 得很多復雜的代碼在Spring中開發卻變得非常的優雅和簡潔，有效的降低代碼的 耦合度，極大的方便項目的后期維護、升級和擴展。Spring的核心思想是IOC （控 制反轉），DI （依賴注入）和AOP （面向切面編程）。通過使用spring，我們將創 建的權力交給IOC，注入的問題交給DI，根本不需要考慮什么時候new這個類對 象，只需要在applicationContext.xml中配置bean，通過注入的方式，注入給類中的 屬性就行了，從而降低耦合度，方便測試。
2.4Postman
Postman是一款功能強大的接口測試工具，可以提供功能強大的Web API和 HTTP請求的調試，它能夠發送任何類型的HTTP請求（GET，POST，PUT， DELETE…），并且能附帶任何數量的參數和Headers。無論是接口調試還是接口測 試，Postman都算的上很優秀的工具，好多接口測試平臺、接口測試工具框架的設 計也都能看到Postman的影子。因此選用Postman來做接口測試。
2.5MobileNet-V2
MobileNet-V2是由谷歌在2018年發布的輕量化卷積神經網絡，它在 MobileNet-V1的基礎上獲得了顯著的提升，并推動了移動視覺識別技術的有效發 展，包括分類、目標檢測和語義分割。相較于第一代，MobileNet-V2具有兩大創 新點：Inverted residuals 和 inverted residuals［15］。通常的 residuals block 是先經過一 個1*1的Conv layer，把feature map的通道數“壓”下來，再經過3*3 Conv layer， 最后經過一個1*1的Conv layer，將feature map通道數再“擴張”回去，即先“壓縮”， 最后“擴張”回去，從而防止可提取特征值過少的情況，inverted residuals就是 先“擴 張”，最后“壓縮”。Linear bottlenecks指的是為了避免Relu對特征的破壞，在residual block的Eltwise sum之前的那個1*1 Conv不再采用Relu，而是使用Linear，從而 減少對特征的破壞［16］。MobileNet-V2使用深度可分卷積(Depth-wise separable convolution)進而減少了大量的運算量以及參數量，使得其十分輕量，效率高，基 于MobileNet-V2的特點，項目選取它來做抽煙狀態的檢測血。
2.6本章小結
本章主要對網約車安全信息管理平臺所使用的關鍵技術和框架做了簡要的概 述，敘述了所用技術和算法的基本原理和功能，信息管理平臺在采用前后端分離 的開發模式下，前端基于Vue，后端基于Spring Boot開發，數據庫采用mySql， 抽煙圖像檢測使用了 MobileNet-V2算法。同時結合項目本身的特點和需求，闡述 了選用以上技術和框架的原因。
3網約車安全信息管理平臺需求分析
在敘述完網約車安全信息管理平臺使用的主要技術后，本章將對網約車安全 信息管理平臺進行需求分析，通過使用用例圖來說明用戶的功能性需求，從可用 性、可靠性、可重用性和安全性等方面進行非功能性需求描述。本章明確該平臺 的系統范圍和實現目標，對平臺系統進行功能模塊的劃分，并逐一分析闡述，為 之后的概要設計、詳細設計和測試驗證打下堅實的基礎。
3.1需求分析綜述
需求分析是軟件定義時期的最后一個階段，他的基本任務是準確的回答“系 統應該做些什么”的問題［18］。為了開發出真正滿足用戶需求的軟件產品，首先必 須知道用戶的需求，網約車安全信息管理平臺的用戶是需要處理單獨事務的公司 內部員工，而非大眾用戶，平臺所提供的功能包含對眾多車單數據的多維展示、 對各類安全相關信息的靈活操作，平臺需求圍繞數據存儲展示和高效操作這兩個 方面。相比傳統數據管理平臺而言，力求為用戶提供更加有效和精準的數據獲取， 減少冗余無效信息干擾；力求為用戶帶來更為智能的數據操作體驗，通過使用機 器處理降低人工數據處理的工作量，優化數據操作的流程，提供更多的數據操作 空間。
3.1.1產品特色分析
網約車安全信息管理平臺主要面向公司內部工作人員，服務安全事件客服人 員、判責工作人員、數據運維分析人員、安全策略制定人員等，所服務的人員可 能來自不同的事業群、不同的部門。作為安全數據管理平臺，該平臺主要針對數 據提供一系列存儲、展示、篩選等工作，核心是安全服務，圍繞不同地區產生的 不同類型的安全服務需求組織處理數據，方便不同崗位的工作人員針對自身實際 工作需要對安全數據的操作使用，提高安全事件處理效率［19］。現將整體平臺分成 如下五個模塊：綜合管理模塊、數據展示模塊、車單信息操作模塊、安全規則定 制模塊和安全判責模塊。具體的功能模塊劃分圖如 3-1 所示。
圖 3-1 平臺功能模塊劃分圖
Figure 3-1 Platform function module division
基于以上分析，該平臺系統的需求點為：
（1）數據的多元化展示：作為一個數據管理平臺，數據的展示是基本工作， 本項目承載了眾多數量、種類的數據，而數據的展示形式直接影響著使用者的感 受，能否針對不同數據、不同需求、不同人員以最合適的方式展示相應的數據， 是一個數據管理平臺成功的關鍵［20］。鑒于安全信息的需求特點，本項目擬采用以 下方式滿足數據展示需求：使用折線圖展示日、月訂單數據發展趨勢、安全數據 走向，同時提供柱狀圖、餅狀圖對事件的分部和類型進行補充。采用表格展示詳 細數據，結合地圖展示實時數據分部，時間軸方式展示訂單流程，基于ECharts使 得多種統計圖像數據支持用戶交互，實現定點展示和詳情展示，方便不同使用者 的使用需求。支持多種格式的數據導出，同時支持圖片、語音和視頻等多種格式 的回流數據展示。
（2） 平臺的易操作性：網約車安全信息管理平臺的使用者工作性質不同，個 人背景不同，多數用戶沒有專業技術背景，而本平臺項目又包含種類繁多的數據 展示、條件查詢，眾多內部專有規則命名，部分功能涉及算法處理，且考慮到各 國各地政策法規不同隨之帶來的安全事故種類和判責標準的不同，平臺的操作過 程必須直觀友好，使用方式必須簡單有效，功能和規則的命名需要直觀易懂。需 要在多個功能區域提供提示、推薦等輔助措施，真正的幫助使用者提高工作效率。
（3） 平臺的可擴展性：網約車作為新興事物，還處在發展階段。當前無論是 國內還是國外都沒有一套成熟的安全措施和配套的管理工具，各國對應的政策法 規也在不斷出臺不斷調整，所以網約車安全信息管理平臺面臨著需求變化升級， 技術的更新換代，已有功能完善加強甚至刪除等眾多情況［21］。要想使得該平臺能 夠長久使用，平臺可擴展性的重要意義不言而喻，從最初的設計，到技術的架構， 代碼的實現都需要充分考慮項目的可擴展性。
3.1.2用戶特征分析
網約車安全信息管理平臺的使用用戶雖然都是公司內部人員，但卻來自不同 的部門不同的事業群，主要有安全事件判責工作人員、客服人員、數據分析運維 人員和安全策略制定人員。這些用戶工作職能不同，個人背景不同，不能以專業 化的角度對用戶一致對待。經過調研分析，本項目的用戶人群主要有以下幾個特 點：
（1） 重視數據的直觀性：用戶每天跟數目繁多的數據打交道，對冗雜且無序 的數據很是反感，據調查反饋，用戶經常花費時間得到一大堆相關信息后，卻難 以從得到的數據中提煉出有用信息，或是想尋求圖片等直觀信息卻只能叨叨一堆 描述文字數據或鏈接。因為沒有直觀高效的數據展示，導致用戶在此類情況上花 費了大量的時間，嚴重制約了用戶的工作效率。
（2） 用戶群體年輕：網約車安全信息管理平臺的用戶大多比較年輕，據調查， 公司內部的運維、客服等人員大多在 30 歲以內，他們工作時長長，接觸學習新鮮 事物的能力強，樂于通過軟件、人工智能等新科技新技術來輔助自己辦公。但同 時他們因為年輕，業務熟練度沉淀不夠，耐心較差了，不愿意學習過多的文檔字 典等操作相關文件。
3.2功能性需求分析
功能需求制定系統必須提供的服務，通過功能分析應該劃分出系統必須完成 的所有功能。經過對用戶的調研和訪問，網約車安全信息管理平臺的主要功能包 括：數據展示、數據條件查詢、數據導出、數據修改、安全規則制定、數據清洗、 判責操作、歷史記錄查詢，數據反饋等功能。本小節將從綜合管理模塊、數據展 示模塊、撤單信息操作模塊、安全規則定制模塊和安全判責模塊五大模塊對平臺 系統的主要功能展開主要的分析。
3.2.1綜合管理模塊需求分析
綜合管理模塊作為網約車安全信息管理平臺的入口界面，主要包含登錄認證、 人員信息管理和文檔中心三個功能區域。綜合管理模塊的用例圖如圖 3-2所示，關 鍵用例說明如表3-1、表3-2、表3-3 所示。
圖 3-2 綜合管理模塊的用例圖
Figure 3-2 Use case diagram of the integrated management module
表 3-1 用戶登錄認證
Table 3-1 User login authentication
用例編號 UC-01 用例名稱 用戶登錄認證
活動者 公司內部員工 優先級 高
用例描述 該用例用來描述用戶登錄平臺后進行登錄的操作，以及登錄請求后權限的校
驗以及相對應頁面反饋。
前置條件 用戶打開瀏覽器，輸入平臺網址進入平臺。
基本事件流 用戶進入平臺頁面后點擊登錄按鈕，按照提示輸入賬號密碼進行登錄；
登錄失敗后按照提示重新登錄；
登錄成功后嘗試進入文檔中心、個人信息管理和數據展示頁面，以及數據展 示、車單信息操作、安全規則定制和安全判責幾個模塊的頁面。
異常事件流 1a. 用戶賬號或密碼錯誤，登錄失敗。
3a. 用戶登錄成功后權限校驗失敗或無平臺瀏覽權限，嘗試進入數據展示頁 面，數據展示頁面跳轉失敗。
3b. 用戶權限不足進入數據展示、安全規則定制、安全判責等頁面失敗。
后置條件 進入綜合管理模塊主界面。
表 3-2 人員信息管理
Table 3-2 Personnel information management
用例編號 UC-02 用例名稱 人員信息管理
活動者 用戶 優先級 高
用例描述 該用例用來描述用戶成功登錄平臺后，查看自己個人信息，查看或修改他人
信息或權限的操作
前置條件 輸入平臺網址進入平臺，且成功登陸。
基本事件流 用戶成功登陸后進入個人信息界面，查看自己個人基本信息，查看自身權限
詳情；
用戶查看平臺內其他用戶個人基本信息和其權限詳情； 用戶修改自身或他人權限信息。
異常事件流 2a. 用戶權限不足，查看他人信息和權限操作失敗。
3a. 用戶無管理員權限，修改他人權限信息操作失敗。
后置條件 無
表 3-3 文檔中心管理
Table 3-3 Document Center Management
用例編號 UC-03 用例名稱 文檔中心管理
活動者 用戶 優先級 低
用例描述 該用例用來描述用戶成功登錄平臺后，查看或修改文檔信息的操作。
前置條件 輸入平臺網址進入平臺。
基本事件流 用戶點擊文檔中心按鈕，進入文檔中心；
用戶查看文檔中心文檔列表和文檔具體內容； 用戶上傳新文檔；
用戶刪除已有文檔。
異常事件流 2a. 用戶權限不足，查看安全數據新相關文檔內容失敗。
3a. 用戶權限不足，上傳文檔操作失敗。
4a. 用戶權限不足，刪除文檔操作失敗。
后置條件 無
（1）登錄認證：當用戶在谷歌瀏覽器輸入平臺網址進入初始頁面后，即可進
行登錄認證。輸入賬號密碼后，后端驗證登錄信息，登錄成功則可進入數據展示 模塊，否則予以登錄失敗的提示，可重新再登錄。登錄成功的同時會對登錄人員 信息進行判定，明確登錄人員的相關權限，對其無權限查看或操作的部分予以隱 藏或無權限提示。在未登錄的狀況下僅可查看文檔中心部分信息，不顯示安全數 據信息，點擊其他模塊會自動調至登錄界面提醒登錄。
（2） 人員信息管理：登陸成功后即可進入人員信息管理部分，首先在該部分 可以查看到自己的基本個人信息，可以看到自己的權限詳情，自己可以查看可以 修改的內容。具有管理員身份的用戶可以查看其他用的基本信息和權限詳情，可 以為其他用戶分配權限，同時可以修改刪除其他用戶的權限。
（3） 文檔中心：網約車安全信息管理平臺包含數據眾多，不同的數據有相應 的操作限制，且平臺內包含很多公司內部專有規則名稱、元能力（安全事故類型） 名稱、數據字段名稱等，所以需要一份詳細的文檔來說明專有名稱含義、操作功 能介紹、權限介紹等等。
3.2.2數據展示模塊需求分析
數據展示模塊為該平臺項目的核心模塊之一，網約車安全信息管理平臺的數 據可視化功能大多在該模塊實現，該模塊主要通過宏觀角度來展示網約車的數據 信息。通過表格、折線圖、曲線圖、時間軸等方式展示按照時間、地點、事件類 型等條件分類后的數據，給用戶以直觀的數據感受。該模塊主要包含每日網約車 運行數據展示、每月網約車運行數據展示、安全事件數據展示和地區綜合信息展 示四個部分。數據展示模塊的相關用例圖如圖 3-3 所示，關鍵用例說明如表 3-4 所 示。
Figure 3-3 Use case diagram of data display module
表 3-4 數據展示模塊管理
Table 3-4 Data display module management
用例編號 UC-04 用例名稱 數據展示模塊管理
活動者 公司內部員工優先級 高
用例描述 該用例用來描述用戶按需查看每日、每月車單數據變化，各類安全事件信息
發生狀況等信息，以及數據導出等操作。
前置條件 用戶成功登陸，進入數據展示頁面。
基本事件流 查看每日網約車運行數據部分，選擇不同日期、不同地區查看圖表展示結果，
查看折線圖上具體點的詳情信息；
查看每月網約車運行數據部分，選擇不同月份、不同地區，查看選擇結果的
折線圖、柱狀圖；
按不同事件類型和地域搜索網約車數據；
導出并保存每日網約車運行數據圖表。
異常事件流 1a. 用戶權限不足，進入頁面后查看網約車運行可視化數據失敗。
4a. 用戶權限不足，可視化圖表數據導出操作失敗。
后置條件 無
（1） 每日網約車運行數據：進入數據展示模塊后最先展示的部分，即數據展 示模塊不做他選時的默認展示本日的數據。該部分包含以日為單位，展示所選日 的網約車的運行數據。包含24 小時網約車車單數量變化折線圖、柱狀圖， 24 小時 網約車的安全事故車單數量變化折線圖、柱狀圖，當日已完成網約車的類型占比 餅狀圖，當日已完成車單基本信息的展示表格。當日的網約車的運行數據支持按 照時間查詢往日數據，支持按照地點、網約車的類型等條件篩選數據，擁有數據 分析權限的用戶可導出該部分的數據。
（2） 每月網約車運行數據：進入數據展示模塊后可跳轉至該部分，該部分包 含以月為單位，展示所選月份的網約車的運行數據。包含當月網約車車單數量日 變化折線圖、柱狀圖，當月網約車的安全事故車單數量日變化折線圖、柱狀圖， 當月已完成網約車的類型占比餅狀圖，當月已完成車單的基本信息的展示表格。 當月的網約車的運行數據支持按照時間查詢過往月份的數據，支持按照地點、網 約車類型等條件篩選數據，擁有數據分析權限的用戶可導出該部分的數據。同時 該部分還展示本年度每月的網約車車單數量月變化折線圖、柱狀圖，本年度每月 每月網約車的安全事故車單數量約變化折線圖、柱狀圖。
（3） 安全事件數據：進入數據展示模塊后可跳轉至安全事件數據部分，該部 分主要展示所發生的安全事故的相關數據信息，包含有安全事件數量變化的折線 圖、柱狀圖，安全事件類型占比的餅狀圖，包含判責結果的安全事故車單詳細數 據表格。該部分支持按照時間、地點、安全事件類型等條件進行篩選，支持通過 訂單號確定到具體訂單的安全事故信息，擁有數據分析權限的用戶可導出該部分 的數據。
（4）地區綜合信息：進入數據展示模塊后可跳轉至地區綜合信息部分，該部 分按照地區的不同，分別展示不同地區的網約車數據，包含車單數據變化、網約 車類型比例，安全事件數據信息，當地車單詳情信息。同時該部分會展示所選地 區的網約車相關政策法規要點，以及公司內部針對當地出臺的網約車運行策略和 規定。
3.2.3車單信息操作模塊需求分析
車單信息操作模塊有別于數據展示模塊，車單信息操作模塊從微觀角度細致 的展示單個車單所產生的相關數據。車單信息操作模塊支持按照訂單號、安全事 件類型、關鍵字等條件進行查詢。安全判責模塊可攜帶訂單號跳轉至該模塊，該 模塊在選中訂單信息后同樣可以攜帶訂單號跳轉至安全判責模塊。車單信息操作 模塊支持文件信息單個導出和批量導出。車單信息操作模塊的用例圖如圖 3-4 所 示，關鍵用例說明如表 3-5 所示。
Figure 3-4 Use case of vehicle data operation module
表 3-5 車單信息操作模塊管理
Table 3-5 Vehicle Bill Information Operation Module Management
用例編號 UC-05 用例名稱 車單信息操作模塊管理
活動者 公司內部員工 優先級 高
用例描述 該用例用來描述用戶按需查看特定車單的詳情信息的操作。
前置條件 用戶成功登陸，進入車單信息操作頁面。
基本事件流 輸入訂單號，查詢該訂單的具體信息；
查看選定車單的時間軸信息，觸碰時間軸關鍵點查看關鍵點詳情信息及表格 數據； 進入選定車單詳情信息頁面，查看通話復現的聊天頁面，聽取選定車單的錄 音信息；
輸入關鍵字批量查詢車單信息，并導出所得結果； 選擇安全事件類型和時間查詢車單信息，查看并導出所得結果。
異常事件流 1a. 輸入訂單號有誤或該訂單號已過期，查詢操作失敗。
4a. 所輸入關鍵字無效，查詢操作失敗。
4b. 用戶權限不足，導出操作失敗。
5a. 用戶權限不足，導出操作失敗。
后置條件 無
車單信息操作模塊中針對不同的查詢方式，提供了不同的數據處理方式，具 體如下：
（1） 訂單號查詢：其結果為單條訂單數據，默認為展示該訂單的信息數據時 間軸，時間軸上標注該訂單開始時間、結束時間、關鍵行為時間、關鍵行為說明、 訂單取消時間（如有）、違規行為發生時間（如有）和違規行為詳情數據的表格， 且時間軸支持用戶鼠標觸碰后顯示相關詳細信息。進入單條訂單信息界面后可從 時間軸展示切換至訂單基本信息表格，訂單基本信息表格包含人員信息、行程常 規信息和安全判責信息。其中人員信息包括司機和乘客雙方的基本信息，可查看 司機的信譽信息檔案。行程常規信息包含文字、圖片和語音，行程常規信息內還 還原了訂單過程中產生的聊天內容畫面。安全判責信息包含該訂單有無判責信息， 若有則顯示判責信息的詳細數據。訂單號查詢方式所得結果支持導出。
（2） 關鍵字查詢和安全事件類型查詢：關鍵字查詢的輸入為訂單相應的關鍵 字，安全事件類型查詢為選擇相關安全事件類型作為查詢條件。二者查詢結果皆 為多條訂單數據組成的表格。關鍵字查詢和安全事件類型查詢的所得訂單信息均 支持批量導出。
3.2.4安全規則定制模塊需求分析
安全規則定制模塊主要負責安全相關的規則制定和其相關操作，結合公司在 相關法規背景下的安全策略，對該模塊的執行流和操作內容進行設計和改良，具 體流程為：在個性化制定安全相關規則后，便可使用這些規則制定數據清洗任務， 執行數據清洗任務，喚醒所需的回流數據［22］。安全規則定制模塊包含制定安全規 則和制定數據清洗任務兩個部分，安全規則定制模塊的相關用例圖如圖 3-5 所示， 關鍵用例說明如表 3-6、表 3-7 所示。
Figure 3-5 Security rule customization module use case diagram
表 3-6 安全規則管理
Table 3-6 Security rule management
用例編號 UC-06 用例名稱 清洗任務管理
活動者 用戶 優先級 高
用例描述 該用例用來描述用戶對安全規則的查看、創建、修改等操作。
前置條件 用戶成功登陸，具備規則操作權限。
基本事件流 進入安全規則頁面，查看規則列表，按需篩選已存在的規則；
點擊規則列表中的規則，進入規則詳情頁面查看該條規則詳情信息； 查看選中規則操作的歷史記錄；
修改選中規則的詳情信息； 點擊創建規則，配置場景名稱、喚醒詞和規則模型等信息；
異常事件流 4a. 用戶權限不足，修改操作失敗。
5a. 用戶權限不足，創建操作失敗。
5b. 單次任務閾值輸入非法，創建失敗。
5c. 所創建規則已存在，創建操作失敗。
后置條件 創建成功后，回退至規則展示頁面。
（1）制定安全規則：該部分有規則列表、規則詳情，規則新建、規則修改和 歷史操作記錄組成。當用戶跳轉到安全規則定制模塊后默認進入安全規則列表頁 面，在該可發起規則的創建、修改等操作。規則列表支持條件篩選，規則由規則 基本信息和清洗模型規則選項構成。其中規則基本信息包含規則名稱、規則描述、 單次任務閾值、場景名、喚醒詞和數據清洗類型。模型規則包含人聲檢測、圖像 檢測、以及具體識別配置。規則修改時只可修改除數據清洗類型、、場景名和喚醒 詞以外的信息。規則詳情頁面可查看歷史操作記錄，根據修改記錄的時間軸可以 查看固定修改次的規則詳情，規則可以整條刪除。
表 3-7 清洗任務管理
Table 3-7 Cleaning task management
用例編號 UC-07 用例名稱 車單信息操作模塊管理
活動者 用戶 優先級 高
用例描述 該用例用來描述用戶對清洗任務的查看、創建、啟動等操作。
前置條件 用戶成功登陸，具備清洗任務操作權限。
基本事件流 進入喚醒數據回流頁面，查看清洗任務列表；
選中一項清洗任務，查看該任務的當前狀態； 修改選中任務的狀態，開始任務清洗操作； 修改選中任務的狀態，暫停任務清洗操作； 查看選中任務的清洗結果； 配置任務數據，創建一項清洗任務； 選中一項任務，對該任務進行質檢； 查看選中任務的質檢結果，并對該任務二次質檢；
異常事件流 3a. 用戶權限不足，開啟任務操作失敗。
4a. 用戶權限不足，暫停任務操作失敗。
5a. 任務清洗未完成，查看操作失敗。
6a. 用戶權限不足，創建任務操作失敗。
6b. 該任務已存在，任務創建操作失敗。
7a. 用戶權限不足，質檢操作失敗。
8a. 用戶權限不足，二次質檢操作失敗。
后置條件 無
（2）制定數據清洗任務：制定清洗任務部分包含數據清洗任務列表展示、配 置清洗任務、修改清洗任務、開始清洗任務和和查看任務狀態四個功能。其中清 洗任務列表頁面支持條件篩選，可在該頁面發起其他三項功能的操作。配置清洗 任務需要配置場景名稱、喚醒詞、SDK版本號、開始時間和結束時間。喚醒詞選 項為元能力列表，元能力為人車不符、索要聯系方式、切單、代叫車、涉性、酗 酒、車程不符等固定的違規詞條。結束時間默認為當前時間前一天，開始時間默 認為距離默認結束時間前一個月的時間點，開始時間不可以選在結束時間之后。 任務創建后支持修改任務數據，任務狀態包含待清洗、進行中、已清洗、清洗失 敗和暫停五種狀態。任務開始后可暫停，清洗任務可刪除，清洗后的數據被標注 上安全狀態。智能清洗數據標注和傳統的人工清洗標注都作為車單標注的方法，
二者標注的結果都會經過質檢復核。
3.2.5安全判責模塊需求分析
安全判責模塊負責為判責工作人員提供操作的場景，該模塊的操作需要用戶 具備判責權限。該模塊提供判責數據展示和判責定責兩部分功能，其中判責數據 展示部分包含待處理車單數據、已判責車單數據和已驗收車單數據，判責信息列 表支持條件查詢。判責定責部分包含判責定責操作界面、判責輔助信息和信息反 饋，安全判責模塊在選定一條判責信息后，可攜帶選定單號跳轉至該條信息的訂 單詳情頁面，同時可從訂單詳情頁面跳轉回當前操作的安全判責模塊界面。安全 判責模塊的相關用例圖如圖 3-6 所示，關鍵用例說明如表 3-8 所示。
Figure 3-6 Security use case diagram
判責數據展示界面展示判責相關的訂單信息，以表格的形式展現，該信息支 持按照時間、地理位置、安全事故類型等條件進行篩選。判責數據狀態分為待處 理、判責中、已判責和已驗收，四者都可單獨的展示，都可進入選定車單的判責 詳情信息，待處理車單為已經標記后的車單，對待處理車單進行判責后，該車單 進入判責中狀態，判責全部完畢進入已判責狀態，當已判責的車單被驗收后，狀 態變為已驗收狀態。判責詳情信息頁面包含車單基本信息、待判責的事件類型或 已判責的事件類型等信息，可從判責詳情信息頁面可攜帶選定單號跳轉至該條信 息的訂單詳情頁面，在訂單詳情頁面查看訂單各類詳細信息進行核實，核實完畢 后可跳回至判責詳情信息頁面進行判責處理。
表 3-8 安全判責操作管理
Table 3-8 Operation management of safety judgment
用例編號 UC-08 用例名稱 安全判責操作管理
活動者 用戶 優先級 高
用例描述 該用例用來描述用戶進行安全判責相關的一系列操作。
前置條件 用戶成功登陸，具備判責操作權限。
基本事件流 進入安全判責模塊頁面，查看判責任務列表，按需篩選任務；
選中任務條目，查看該判責任務的當前狀態及任務詳情； 進入選中任務的判責頁面，填寫判責信息，進行判責； 進入選中任務的驗收頁面，填寫驗收信息，進行驗收； 進入判責任務管理界面，為工作人員指派判責任務。
異常事件流 6a. 用戶無管理員權限，任務指派操作失敗。
后置條件 無
從判責詳情信息頁面可查看判責輔助信息，輔助信息提供判責關鍵字、判責 建議和相關法參考律法規條文等信息，幫助工作人員按照規定流程，快速定位到 有效信息在訂單信息中的那一部分，從而有針對的去核實信息，準備判責［23］。核 實后進行判責定責操作，確認該車單是否有責，若有責為何種責任，判定結束后 需要驗收復核，驗收復核后該單進入已驗收狀態。已驗收的車單可以進行信息反 饋操作，向相關人員反饋該單的判責操作，同時接受他人的反饋信息。
3.3非功能性需求分析
為使得網約車安全信息管理平臺能更好服務用戶，為切實提高用戶的使用體 驗，在考慮功能性需求的同時也提出幾點非功能性需求，主要包括易用性、安全 性、可靠性和可復用性，具體內容如下：
（ 1）易用性：為使得不同崗位不同背景的用戶都能快速使用網約車安全信息 管理平臺，在平臺設計之初就投入了大量精力在項目的易用性上，提供多種個性 化篩選、可保留使用狀態回退、攜帶訂單信息跳轉、友好的操作提示、完備的文 檔中心等多項功能，用以保障用戶快速上手，高效操作平臺。
（2）安全性：網約車安全信息管理平臺上承載了大量公司內部數據，平臺需 連接內網方可使用，同時設置不同用戶的權限管控，嚴控數據導出權限，為不同 用戶提供不同服務，防止因操作不當帶來的不必要損失，同時需要對部分信息頁
面做添加水印的處理，防止數據泄露，便于追源。平臺還提供操作歷史記錄、日 志等信息，方便用戶對錯誤操作進行定位和回退。
（3） 可靠性：平臺對數據操作、輸入輸出、判定修改有相應的成功或失敗等 提示，防止異常的發生。對數據有檢測功能，一定程度上排查無用信息，同時對 數據清洗涉及的相關算法經過反復的實驗核實，對算法識別的準確率有著明確的 要求。
（4） 兼容性：本平臺主要運行在 pc 端的網頁上，故此兼容性主要考慮平臺 在不同類型瀏覽器上的運行情況和在不同分辨率的屏幕上的自適應情況。考慮到 用戶的實際使用情況，網約車安全信息管理平臺需要在Chrome、Safari、火狐、IE9 等主流瀏覽器上有良好的運行表現，同時在 2880*1800、2560*1600 1920*1080 等常用分辨率 的顯示屏上運行時可自動根據屏幕分辨率調整平臺頁面的布局展示。
（5） 可復用性：網約車安全信息管理平臺作為網約車安全數據方面的探索產 品，在積累相應經驗并完善后有機會走出公司內部推向市場，為眾多公司提供一 套完善的網約車安全數據管理體系，提供行之有效的判責管理模式，故而在開發 過程中應充分考慮產品的可復用性，從設計到實現降低模塊間的耦合程度，提高 功能內聚，封裝好功能模塊，為平臺日后的發展和維護打下堅實的基礎。
3.4本章小結
一份好的需求分析是完成一項好項目的重要基礎，通過與用戶訪談溝通，充 分分析整合產品需求之后，本章在產品特色、用戶特點、產品功能需求和非功能 需求方面做了詳細的論述，明確了不同模塊的需求信息，為后面的項目設計、實 現和測試提供了可靠的依據。
4網約車安全信息管理平臺概要設計
上一章對網約車安全管理平臺做了詳細的需求分析，本章重點論述網約車安 全管理平臺的概要設計。本章內容認真的參考了軟件工程設計規范，遵循模塊化、 抽象、逐步求精和模塊獨立的設計原則，力主做到高內聚低耦合，提高模塊的復 用率［24］。本章以上一章需求分析為依據，將具體從系統設計目標、平臺架構和系 統功能結構幾方面來論述，同時也將數據庫表進行設計。
4.1設計目標
網約車安全信息平臺的設計目標是提供一套完整的安全數據操作平臺，為公 司內部人員提供便捷有效的數據支持，輔助安全事務的處理。通過與用戶的反復 溝通和總結可以得出網約車安全信息平臺的主要設計目標如下：
（1） 簡易友好的操作流程：一款好的數據管理平臺是在呈現復雜數據的同時 提供簡易的操作，操作流程的簡易程度，所提供的結果是否友好直觀直接影響著 一個數據管理平臺的質量，在系統操作邏輯的實際過程中要充分考慮流程的合理 性，盡量保證與多數用戶習慣保持一致，在必要的地方添加提示框或提示標語， 提供確認選項，防止不必要的操作失誤［25］。
（2） 智能高效的數據操作：作為旨在提高用戶數據操作效率的平臺，結合算 法賦能數據操作帶來的智能化數據處理是本數據平臺區別于傳統數據平臺的兩點 之一。在設計系統的過程中，要在取代純手工操作數據的基礎上更近一步，充分 結合語音、圖像識別技術對語音、圖像等數據實現數據按需清洗，精準識別，真 正為用戶提供其所需要的數據，有效的縮短排查范圍，降低判定難度，提高判責 效率和準確度。
（3） 良好的可擴展性：網約車安全信息管理平臺仍是網約車這一新領域在數 據處理上的開拓和探索，現實的情況決定了該平臺在未來還有很長的優化過程， 無論是技術的革新還是規則的變化，都要求系統在設計的過程中應當充分考慮可 擴展性，為今后系統的性能優化和功能變遷打下基礎。
4.2總體功能結構
遵循軟件工程的思路［26］，在第三章需求分析中已經將網約車安全信息管理平 臺分為了綜合管理模塊、數據展示模塊、撤單信息操作模塊、安全規則定制模塊
和安全判責五大模塊，網約車安全信息管理平臺的總體功能模塊劃分如圖 4-1 所
示。
在網約車安全信息管理平臺中，綜合管理模塊為初始化模塊，提供登錄、個 人信息和文檔等服務。數據展示模塊和車單信息操作模塊提供各種類型數據的多 種展示方式，是數據展示的主體部分。安全規則定制模塊和安全判責模塊為判責 操作服務，提供數據清洗、縮減數據排查范圍、智能輔助等服務。其中安全判責 模塊和車單信息操作模塊可攜帶訂單號相互跳轉，可保存當前瀏覽狀態。
4.3技術實現架構
考慮到網約車安全信息管理平臺是PC端網頁操作平臺，所以系統采用B/S架 構［27］。平臺的具體架構圖如圖 4-2 所示。
圖 4-2 平臺架構圖
Figure 4-2 Platform architecture diagram
前端部分采用HTML、CSS、JavaScript結合Vue框架搭建遵循MVVM模式, 使用iView組件，Echarts實現可視化。后端部分采用Spring Boot，遵循MVC模 式，數據庫訪問和數據存儲分別采用 Mybatis 和 MySQL。
4.4數據庫設計
數據庫技術是信息資源管理的有效手段，它要求對于給定的應用環境，構建 出適當的數據庫模式，建立起數據庫應用系統，并使系統有效地存儲數據，滿足 用戶應用方面的各種需求［28］。經過之前的分析，網約車安全信息管理平臺選用 MySQL數據庫作為存儲信息數據的工具，網約車安全信息管理平臺的整體E-R圖 如圖 4-3 所示。
圖4-3系統E-R圖
Figure 4-3 System E-R diagram
接下來對各個模塊涉及到的重要部分數據表進行說明。
4.4.1綜合管理模塊
該模塊主要負責實現登錄功能、個人信息操作和文檔管理。根據系統 E-R 圖
設計出綜合管理模塊涉及的數據庫表，主要為用戶信息（l_user）和文檔信息 （［document ）兩個表。
（1）用戶信息表（l_user），如表4-1所示。
表4-1用戶信息表(l_user)
Table 4-1 User information table (l user)
序號 字段名稱 數據類型 約束條件 描述
1 id int 不許為空， 自增 主鍵
2 user_id bigint(20) 不許為空， 無重復 員工號
3 name varchar(100) 不許為空 用戶名
4 company varchar(50) 不許為空 歸屬部門
5 email_prefix varchar(100) 不許為空 郵箱前綴
6 role_id int 不許為空 職務
用戶信息表主要由員工號、用戶名、歸屬部門、郵箱前綴和職務組成，其中 員工號為用戶在公司的唯一員工編號，用以定位該用戶個人信息，關聯該用戶的 權限信息、操作記錄等。郵箱前綴為公司郵箱的前綴部分，職務部分記錄枚舉的 ID 號。
(2)文檔信息表([document)，如表4-2所示。
表4-2文檔信息表(l—document)
Table 4-2 Document information table (l document)
序號 字段名稱 數據類型 約束條件 描述
1 id int 不許為空， 自增 主鍵
2 user_id bigint(20) 不許為空， 無重復 員工號
3 name varchar(100) 不許為空 用戶名
4 company varchar(50) 不許為空 歸屬部門
5 email_prefix varchar(100) 不許為空 郵箱前綴
6 role_id int 不許為空 職務
文檔信息表主要由文檔編號、文檔標題、文檔內容的鏈接、文檔狀態、上傳 該文檔的用戶的員工號和創建時間組成。其中文檔編號為每篇文檔的固定編號， 文檔的狀態分為正常和已經刪除。
4.4.2數據展示模塊和車單信息操作模塊
數據展示模塊和車單信息操作兩個模塊所展示的數據是同一套網約車車單數 據的不同展示方式，數據展示模塊側重于展示眾多車單數據組成的整體數據的宏 觀變化，車單信息操作側重于展示單體的詳細內容。根據系統 E-R 圖設計出數據 展示模塊和車單信息操作兩個模塊所涉及的數據庫表，主要為車單信息表 (c_order)、司機信息表(c_driver)和乘客信息表(c_passenger)，司機信息和乘客 信息屬于車單信息。
(1)車單信息表(c_order)，如表4-3所示。
表4-3車單信息表(c_order)
Table 4-3 Car list information table (c order)
序號 字段名稱 數據類型 約束條件 描述
1 id int 不許為空， 自增 主鍵
2 goid bigint(20) 不許為空， 無重復 車單號
3 create_time timestamp 不許為空 創建時間
4 end_time timestamp 無 結束時間
5 cancel_time timestamp 無 取消時間
6 order_photos Varchar(200) 無 圖片
7 order_voice Varchar(200) 無 語音
8 type int 不許為空 車單類型
9 ability_type int 不許為空 安全事件類型
10 status int 不許為空 車單狀態
11 chat_record Varchar(255) 無 聊天記錄
車單信息表主要由車單號、創建時間、結束時間、取消時間、圖片信息、語 音信息、車單類型、安全事件類型、車單狀態和聊天記錄組成。其中車單號為該 車單唯一識別號碼，當車單正常結束時有結束時間無取消時間，當車被取消時有 取消時間，車單類型包含快車、出租車、拼車、豪華車等，車單狀態為正常、已 標注、已判責、已驗收等。
(2)司機信息表(c_driver)，如表4-4所示。
表4-4司機信息表(c_driver)
Table 4-4 Driver information table (c driver)
序號 字段名稱 數據類型 約束條件 描述
1 driver_id bigint(20) 不許為空，非重復 司機工號，主鍵
2 name varchar(100) 不許為空 司機姓名
3 gender int 不許為空 司機性別
4 age int 不許為空 司機年齡
5 phone_num int 不許為空 聯系電話
6 adress varchar(255) 不許為空 歸屬地
7 credit varchar(100) 不許為空 信譽信息
司機信息表從屬于車單信息，主要由司機工號、司機姓名、性別、年齡、聯 系電話、歸屬地、信譽信息和車輛信息組成。其中司機工號是每位司機的唯一工 作身份號碼，通過司機工號可以查看該司機完成的所有車單以及車單的車單號， 車單號同樣可以反查該車單的執行司機。
(3)乘客信息表(c_passenger)，如表4-5所示。
表4-5乘客信息表(c_passenger)
Table 4-5 Passenger information table (c passenger)
序號 字段名稱 數據類型 約束條件 描述
1 passenger_id bigint(20) 不許為空，非重復 乘客ID，主鍵
2 name varchar(100) 不許為空 乘客姓名
3 gender int 不許為空 乘客性別
4 adress varchar(255) 不許為空 歸屬地
5 phone_num int 不許為空 聯系電話
6 combination int 不許為空 拼車信息
乘客信息表也從屬于車單信息，主要由乘客ID、乘客姓名、性別、年齡、聯 系電話和歸屬地。其中乘客ID為每位乘客的身份標識，一份車單數據可以對應多 個乘客信息。拼車信息包含無拼車、單人拼車、多人拼車等狀態。
4.4.3安全規則定制模塊
安全規則定制模塊主要實現清洗規則的創建、修改和展示，清洗任務的配置、 創建和操作，清洗后的數據會打上標識，以供后續判責操作，同時清洗任務結果 的準確性會由相關工作人員進行質檢，并記錄質檢相關信息。根據系統 E-R 圖設 計出安全規則定制模塊所涉及的數據庫表，主要為元能力信息表(b_ability)、清 洗規則信息表(v_rule)、清洗任務信息表(v_task)和質檢信息表(l_inspect)。
(1)元能力信息表(b_ability)，如表4-6所示。
表4-6元能力信息表(b_ability)
Table 4-6 Meta capability information table (b ability)
序號 字段名稱 數據類型 約束條件 描述
1 id int 不許為空，非重復 主鍵
2 ability_name varchar(100) 不許為空 元能力標題
3 description varchar(255) 無 元能力描述
4 category int 不許為空 元能力種類
5 status int 不許為空 元能力狀態
元能力信息表主要由元能力標題、元能力描述、元能力種類和元能力狀態組
成。其中元能力標題包含人車不符、索要聯系方式、切單、代叫車、涉性、酗酒、 車程不符等。單一元能力或者組合元能力配上其他配置信息可組成清洗規則。
(2)清洗規則信息表(v_rule)，如表4-7所示。
表4-7清洗規則信息表(v_rule)
Table 4-7 Cleaning rule information table (v rule)
序號 字段名稱 數據類型 約束條件 描述
1 id bigint(20) 不許為空，自增 主鍵
2 rule_name varchar(100) 不許為空 規則名稱
3 rule_desc varchar(500) 無 規則描述
4 creator varchar(50) 不許為空 創建人
5 mender varchar(50) 不許為空 修改人
表 4-7(續表)
Table 4-7(Cont.)
序號 字段名稱 數據類型 約束條件 描述
號6 create_time bigint(20) 不許為空 創建時間
7 mend_time bigint(20) 不許為空 修改時間
8 record_max bigint(20 不許為空 單次最大閾值
9 rule_md5 varchar(100) 不許為空 規則標識
10 model Text 不許為空 模型信息
11 wash_type varchar(32) 不許為空 數據清洗類型
清洗規則信息表主要由規則名稱、規則描述、創建人、創建時間、修改時間、 單次最大閾值等組成。其中創建人和修改人皆保存操作人員的郵箱前綴，并以創 建時間和修改時間為節點可展示該條清洗規則的歷史記錄。規則標識可用來迅速 定位該條規則，模型信息為 json 存儲，保存了該條清洗規則所配置的模型數據， 包含喚醒詞類型場景名稱和喚醒詞等信息。清洗規則信息表包含的信息眾多，所 包含的信息隨智能技術部門對接要求、版本更新和現實場景需求有所調動和更改。
(3)清洗任務信息表(v_task)，如表4-8所示。
表4-8清洗任務信息表(v_task)
Table 4-8 Cleaning task information table (v task)
序號 字段名稱 數據類型 約束條件 描述
1 id bigint(20) 不許為空，自增 主鍵
2 task_name varchar(100) 不許為空 任務名稱
3 task _desc varchar(500) 無 任務備注
4 creator varchar(50) 不許為空 創建人
5 create_time bigint(20) 不許為空 創建時間
6 sdk_version varchar(32) 不許為空 sdk 版本號
7 rule_md5 varchar(100) 不許為空 對應的規則
8 end_time bigint(20) 不許為空 終止時間
9 status Int 不許為空 任務狀態
清洗任務信息表主要由任務名稱、任務備注、任務創建人、任務創建時間、 對應的規則標識、sdk版本號、終止時間和任務狀態等組成。其中創建人部分保存 操作人員的郵箱前綴，對應規則負責匹配規則內容，任務狀態由未開始、清洗中、 已暫停、已完成和失敗5 種狀態組成，一個清洗任務可對應一個清洗規則。
(4)質檢信息表(l_inspect)，如表4-9所示。
表4-9質檢信息表(l_inspect)
Table 4-9 Quality inspection information table (l inspect)
序號 字段名稱 數據類型 約束條件 描述
1 id bigint(20) 不許為空 質檢 ID
2 task_id int(11) 不許為空 清洗任務 ID
3 inspector_id int(11) 不許為空 質檢人 ID
4 inspector_name varchar(100) 不許為空 質檢人姓名
5 create_time timestamp 不許為空 創建時間
6 inspect_suggest varchar(500) 不許為空 質檢意見
7 inspect_result int 不許為空 質檢結果
8 inspect_round int(11) 不許為空 質檢輪次
9 update_user_id int(11) 不許為空 最后一次修改人
10 update_time timestamp 不許為空 更新時間
清洗任務信息表主要由質檢ID、清洗任務ID、質檢人姓名、質檢人ID、創建 時間、質檢意見、質檢結果、質檢輪次、最后一次修改人和更新時間組成。其中 質檢結果包含通過、修改和不通過。質檢人員會對清洗任務進行隨機抽查，核對 清洗任務和清洗結果的正確率，進而給出質檢結果。
4.4.4安全判責模塊
安全判責模塊是用戶進行判責的操作模塊，主要提供判責相關的車單信息， 對需要判責的車單進行判責和驗收操作。根據系統 E-R 圖設計出安全判責模塊所 涉及的數據庫表，主要為判責信息表(l_judgment)和驗收信息表(l_accept)。
(1)判責信息表(l_judgment)，如表4-10所示。
表4-10判責信息表(l_judgment)
Table 4-10 Judgment Information Table (l judgment)
序號 字段名稱 數據類型 約束條件 描述
1 id bigint(20) 不許為空 主鍵
2 judger_name varchar(100) 不許為空 判責人員姓名
3 judger _id varchar(100) 不許為空 判責人員 ID
4 goid int 不許為空 車單號
5 create_time timestamp 不許為空 創建時間
6 type int 不許為空 判責類型
7 result int 不許為空 判責結果
8 judg_desc varchar(100) 不許為空 判責備注
9 inspect_round int(11) 不許為空 判責輪次
10 update_user_i int(11) 不許為空 最后一次修改人
11 d update_time timestamp 不許為空 更新時間
12 feedback varchar(500) 無 反饋內容
判責信息表主要由判責人員ID、判責人員姓名、車單號、創建時間、判責類 型、判責結果、判責備注、判責輪次、最后一次修改人、更新時間和反饋內容組 成。其中判責人員和最后一次修改人記錄操作者的ID,判責結果由可枚舉的責任 等級和包含判責具體信息的判責備注組成。
(2)驗收信息表(l_accept)，如表4-11所示。
表 4-11 驗收信息表
Table 4-11 Acceptance information table
序號字段名稱 數據類型 約束條件 描述
1 id bigint(20) 不許為空， 主鍵
2 accept _name varchar(100) 自不增復許為空 驗收人員姓名
3 accept _id varchar(100) 不許為空 驗收人員 ID
4 goid int 不許為空 車單號
表 4-11(續表)
Table 4- 1 1 (Cont.)
序號 字段名稱 數據類型 約束條件 描述
號 5 create_time timestamp 不許為空 創建時間
6 accept_sugge varchar(500) 不許為空 驗收建議
7 st accept_result int 不許為空 驗收結果
8 accept_round int(11) 不許為空 驗收輪次
9 update_user_i int(11) 不許為空 最后一次修改
10 d update_time timestamp 不許為空 人更新時間
11 feedback varchar(500) 無 反饋內容
驗收信息表主要由驗收人員ID、驗收人員姓名、車單號、創建時間、驗收結 果、驗收建議、驗收輪次、最后一次修改人、更新時間和反饋內容組成。其中驗 收結果包含驗收通過、修改和驗收不通過三種，驗收后會給予相應的反饋信息。
4.5本章小結
本章通過系統整體功能結構、技術架構和數據庫表三個方面展示了網約車安 全信息管理平臺的概要設計。在力求滿足用戶需求和考慮產品特征的前提下，系 統設計目標簡明扼要，目的明確，力求高內聚低耦合，方便項目后期的迭代和測 試。繪制了系統的整體 E-R 圖，并根據系統整體的 E-R 圖對綜合管理模塊、數據 展示模塊、車單信息操作模塊、安全規則定制模塊和安全判責模塊五個模塊所涉 及的數據做了詳細的數據庫表設計，通過保障數據庫設計質量，為下面的詳細設 計與實現工作奠定了堅實的基礎。
5網約車安全信息管理平臺詳細設計與實現
在上一章，我們對網約車安全信息管理平臺進行了概要設計，本章將在上一 章概要設計的基礎上結合需求分析，對項目進行詳細設計和實現。詳細設計的根 本目標是確定應該怎樣具體地實現所要求的系統，得出對目標系統的精確描述， 進而在編碼階段把描述直接翻譯成用程序設計語言書寫的程序［29］。
本章將通過類圖、時序圖、流程圖和相應的文字說明來闡述網約車安全信息 管理平臺各個模塊的詳細設計內容和實現過程，接下來對各個模塊的內容進行詳 細說明。
5.1綜合管理模塊
綜合管理模塊主要包含項目的初始界面、登錄界面、用戶信息界面和文檔中 心界面，實現登錄校驗、權限提示和文檔的發布修改功能。初始界面包含首頁、 開放服務、文檔中心、合作咨詢、控制臺、核心能力介紹和登錄入口。其中首頁 為返回初始界面按鈕，開放服務為本平臺提供的各項服務文字簡介，合作咨詢提 供合作模式、合作要求、聯系方式等信息，控制臺為其他模塊的入口。因為開放 服務、咨詢合作和核心能力介紹三部分為固定的純文字內容，首頁和控制臺為跳 轉按鈕，所以本節重點闡述用戶登錄校驗和操作文檔中心部分。
5.1.1用戶登錄校驗
網約車安全信息管理平臺面向公司內部員工使用，用戶在使用前需要登錄認 證個人信息，并校驗用戶權限，登錄成功后可訪問自身權限允許的界面和進行自 身權限允許的操作。平臺管理人員可通過公司統一的權限系統為用戶申請或修改 相應的權限內容。用戶登錄校驗功能的流程圖如圖 5-1 所示，用戶登錄校驗功能的 時序圖如圖5-2所示。
開始
輸空碼
驗證權限
開始
正礎
正進
申請權限
轄界面
企業權限管理
登陸磁
圖5-1用戶登錄校驗功能流程圖
o
Figure 5-1 Flow chart of user login verification function
使用者
認證權限信息
昨密籲息、
礙珈信息
情
館密碼信息
情
ucenter （統
controller
前端界面
包器
圖5-2用戶登錄校驗功能時序圖
Figure 5-2 Sequence diagram of user login verification function
用戶登錄校驗功能的流程細節為：當用戶點擊登錄按鈕，頁面跳轉至登錄頁 面后，用戶可輸入賬號密碼信息，前端對用戶賬號密碼的長度和格式規范使用正 則表達式進行初步校驗，輸入內容格式只能由數字字母和常用符號組成，區分大 小寫，若前端校驗到賬號密碼錯誤或者為空后給予重新輸入提示。前端校驗過后， 用戶點擊登錄由前端發起 ajax 請求。后端接到認證請求后通過用戶名向公司統一 權限系統查詢中的用戶信息，比對賬號密碼校驗登錄是否成功，同時檢驗該用戶 的權限，看該用戶是否有使用網約車安全信息管理平臺面的權限，若無則給予無 權限的提示，提示用戶可向公司統一權限系統申請權限后再登錄。若有權限則登 錄成功，前端收到登錄成功的信息后，使用 vue-router 跳轉界面。用戶登錄校驗功 能的類圖如圖 5-3 所示。
圖5-3用戶登錄校驗功能類圖
Figure 5-3 User login verification function class diagram
如圖5-3，該功能點主要使用的類有UserController，UserService、UserExt等。 其中UserExt為用戶信息的包裝類,UserExt繼承自類User,針對前端的需求將User 類進行了修改和包裝，除了用戶ID、姓名、郵箱等基礎信息外，還包含用戶的權 限、所屬部門等信息，作為 UserController 類的返回值可直接供前端使用。 UserController 負責和前臺的 JavaScript 文件進行數據的交互，是前臺數據的接收 器 ， 后 臺 處 理 好 的 用 戶 數 據 也 是 通 過 UserController 傳遞到前臺顯示的。 UserServiceImpl 是 UserService 的接口實現類，包含有 findUserByUserName 和 findUserByUserId 兩個方法， 當前端登錄驗證請求帶來用戶名時只能使用 findUserByUserName 查詢到用戶的基礎信息，使用 findUserByUserId 可查到用戶 的權限、所屬部門等其他信息。網約車安全信息管理平臺基于Spring Boots框架，
使用 UserMapper 類 進行與數 據庫相關 的操作。整 體為 UserController 類調用 UserServiceImpl 類的方法并返回 UserExt 類型的數據，同時在用戶登錄過程中后臺 會將有效用戶的token寫入cookie,設置cookie有效期，前端收到cookie中的token 之后再發起請求時會攜帶此token。綜合管理模塊實現圖如圖5-4、圖5-5所示。
Figure 5-4 Implementation diagram of the integrated management module
圖 5-5 登錄頁面實現圖
Figure 5-5 Login page implementation diagram
5.1.2操作文檔中心
文檔中心頁面負責展示文檔內容，文檔包含標題、文字內容和圖片說明。用 戶可點擊查看、上傳和刪除文檔，其中上傳和刪除需要具備相應權限。上傳的文 檔需要符合默認格式，且前后端會對文檔基本信息做校驗以保障上傳的正確性和 安全性。操作文檔中心的流程圖如圖 5-6所示。
圖5-6操作文檔中心流程圖
Figure 5-6 Operation document center flow chart
文檔中心的文檔發布和刪除操作所涉及的權限校驗過程與上一節登錄認證過 程中的權限查詢過程類似，故而在下文中不再對權限校驗流程做贅述。操作文檔 中心的核心流程為在文檔中心界面可發起查看文檔和修改文檔的操作。其中修改 文檔操作包括發布和刪除，二者皆需權限校驗，校驗成功后可跳轉至發布界面或 刪除文檔。
當用戶在文檔中心發起文檔發布操作后，需要先從前端頁面選擇上傳文檔內 容，填寫文檔基本信息，包含標題、作者、文檔類型等。提交文檔內容后前端首 先對上傳的文檔進行一次校驗，主要校驗內容為文檔數據的格式是否符合規則。 前端校驗成功后后端會對文檔內容進行二次校驗，二次校驗包含對上傳文件的 MIME 類型檢測（檢測 Content-Type 內容）、目錄路徑檢測（檢測跟 path 參數相關的 內容）、文件擴展名檢測（檢測文件 extension 相關的內容）。發布文檔操作的時序圖 如圖 5-7所示，圖中不再重復繪制權限查閱操作的內容。
圖 5-7 發布文檔操作時序圖
Figure 5-7 Operation sequence of publishing documents
網約車安全數據管理平臺雖然現在針對公司內網使用，但考慮到項目的安全 性以及項目今后對外開放推廣商業化的發展可能，所以在詳細設計階段即對文件 上傳部分做了相關安全防護措施，除了上述的文件相關信息監測外，還在上傳過
程中進行httpDecode轉義操作，設置httpOnly，防止由漏洞引發的安全事故。當所 上傳的文檔數據校驗過無誤后會有后臺操作保存至數據庫，同時將反饋信息傳給
前端。操作文檔中心功能的類圖如圖5-8所示。
DocController
docVerify () getDocByldO publicDocO deleteDocO
findDocumentByldOp ublishDocumentO deleteDocumentO
DocServicelmpI
findDocumentByldOp ublishDocumentO deleteDocumentO
Upload VerifyUtil
type
rules
content
isDocumentLegitimate ()
DocMapper
title author category provider con tent docinsert () docDelete () docSearch ()
圖 5-8 操作文檔中心類圖
Figure 5-8 Class diagram of the operation document center
如圖 5-8 所示，該功能點所涉及的主要類有 DocController 、 DocService、
DocMapper、 document、 UploadVerifyUtil 等。其中 document 作為文檔 bean 類，內 包含標題、上傳者等屬性， UploadVerifyUtil 為上傳校驗的工具類，可以通過傳入 校驗類型、校驗規則和校驗內容對數據進行校驗操作，返回校驗結果。 DocController 中包含有 docVerify、 getDocById、 publicDoc 和 deleteDoc 方法，用于實現文檔的 驗證、查詢、發布和刪除。前端發布頁面收集到所要上傳文檔的信息后封裝成類 通過 ajax 發送至后端，服務端接到前端請求后 DocController 將前端傳遞過來的信 息整合到 document 類，并調用 UploadVerifyUtil 工具類對文檔數據進行校驗，校 驗成功后 DocController 再通過 DocService 的接口實現類 DocServiceImpl 調用 DocMapper， DocMapper 進行數據庫操作將文檔信息存儲，同時返回操作結果，前 端接到發布成功的信息后跳轉至文檔展示界面，同時刷新文檔展示內容。
5.2數據展示模塊
數據展示模塊主要負責網約車數據的可視化，前端基于 Echarts 可視化庫實現 各種圖表的，展示數據的變化、走勢、組成比列等。圖表內容支持時間、地點等 條件選擇，圖表內容在校驗權限后支持導出。數據展示模塊重點展示宏觀的數據 關系，車單的詳細信息放在車單信息操作模塊，不在數據展示模塊提供。數據展 示模塊操作的流程圖如圖 5-9 所示。
圖5-9數據展示模塊操作流程圖
Figure 5-9 Operation flowchart of data display module
數據展示模塊的詳細操作流程為：當用戶點擊數據展示模塊選項進入該模塊 界面后，展示內容分為三個部分，按日展示、按月展示和按安全事件展示，默認 展示當日網約車的數據，每日數據、每月數據和安全事件數據都支持按照時間和 地區進行篩選，用戶在界面中的篩選框可下拉選擇數據展示條件展示不同數據， 鼠標觸碰圖表上節點可顯示該節點詳細內容。進行數據導出時會先校驗用戶權限， 若用戶無此權限會彈窗提示，若用戶擁有此權限則可執行下載內容。數據展示模 塊的類圖如圖 5-10 所示。
圖 5-10 數據展示模塊類圖
Figure 5-10 Data display module class diagram
數據展示模塊主要涉及的 類為 OrderController 、 DownlController 、 AuthorityFilter 等。其中 OrderController 負責車單數據的查詢，因為普通訂單數據 信息和涉及安全事件的訂單信息存在不同表中，所以分別設計了 getOderInfo方法 和getAccidentlnfo方法在相對應的表中查詢。OrderServicelmpl實現對數據的查詢 操作，并調用 ChartInfoConv 類中的 convert 方法對查詢到的數據進行整理，轉換 成 Echarts 所需要的數據后再返給前端。因為數據展示模塊的數據側重展示大量數 據的整體關系，所以該部分數據可視化的數據存在數據倉庫中，其底層存儲為 HDFS。 DownlController 對接數據展示模塊的下載操作，當前端發起下載請求時， DownlController 會調用 AuthorityFilter 中的 getAuthorityDetail 方法來檢查當前操作 用戶的權限。權限核實正確之后，針對普通車單數據請求和涉及安全事件的車單 請求 DownlController 分 別 通過 DownloadServiceImp 類的 exportOrderInfo 和 exportAccidentInfo 方法調用 DownloadMapper 查詢數據倉庫中的數據，下載后的數 據存儲在瀏覽器的下載存儲位置。
5.3車單信息操作模塊
車單信息操作模塊主要負責車單信息詳細情況的展示和操作，進入該模塊前 會進行權限校驗，若無權限則不會顯示該模塊界面，僅給予無權限提示。進入車 單信息操作模塊的界面后，通過訂單號等篩選信息可快速定位到指定車單的具體 信息，包含車單基本信息、行程記錄、司機信息、乘客信息、聊天記錄、語音記 錄、判責信息等。車單信息操作模塊主要分為三個功能點：訂單號查詢、關鍵字 查詢和安全事件類型查詢，三者都支持信息導出。
5.3.1訂單號查詢訂單詳情信息
訂單號查詢訂單詳情信息界面是車單信息操作模塊的默認展示界面該功能點 提供一對一的查詢操作，信息數據包含文字、圖片、語音、圖表等。每筆打車訂 單的信息會自動保存兩周，期間訂單信息可查詢，兩周后該訂單信息默認清空。 訂單號查詢訂單詳情信息操作的流程圖如圖 5-11 所示。
圖 5-11 訂單號查詢訂單詳情信息操作流程圖
Figure 5-11 Operation flow chart of order number query order details
用戶檢驗權限后便會進入訂單號查詢訂單詳情信息界面，在該界面輸入清單
號，點擊查詢按鈕進行查詢，若輸入的訂單號號碼錯誤或者該訂單號已經失效則 會給與輸入的訂單到無效提示。輸入正確且有效的訂單號并查詢后會跳轉到訂單 行程心電圖（行程時間軸）界面，單行程時間軸包含訂單的搶單時間、結束時間 或取消時間、關鍵節點信息表格等。關鍵節點的信息表格默認為隱藏狀態，需要 用戶鼠標滑過時觸發展示，劃走消失。行程時間軸的關鍵時間點以及關鍵時間周 邊的展示效果使用 canvas 繪制，對該部分的視圖內容前端進行組件抽取，便于后 期的修改、測試和復用。訂單號查詢訂單詳情信息中訂單行程心電圖（行程時間 軸）的實現界面如圖 5-12 所示。
心電圖
[17656961077916(
da 帀 aoche SexualSpe 宙 bxualSpeech
RequestCoritecJjestDrunk SexualSpeech SexualSpeech
搶單時間 開鮒費時間 結束時間
. . • < —• .
2019.12.12019-12-19 2019-12-20 2019.-12-2(2019.-12-20 2019-12-20 2019-12-2Q019-12-20
23:57:30 23:59:14 00:06:48 00:13:37 00:15:43 00:20:19 00:28:06 00:31:13
詳筋息 #
gold 17656961077916
timestamp 1576772017
ability SexualSpeech
scone 0.0607 0.9393
attribute ,,other_infci:"：rse)("：rinfo,,:^ir',"num":"one,,},"RequestContacr,：Onf o":,r0l6",,,num-,:,,one"}}
sid 260
dtyjd 64
圖 5-12 訂單行程心電圖（行程時間軸）實現界面
Figure 5-12 Order trip ECG (travel timeline) implementation interface
用戶可選擇從訂單行程心電圖的界面切換到訂詳情信息展示的界面，訂單詳 情信息展示的界面中包含有該訂單的眾多基本信息、判責信息、聊天記錄和語音 記錄等。因訂單詳情展示界面所涉及的訂單、司機和乘客等信息具有私密性，出 于安全考慮，為訂單詳情頁面以及其所包含的判責信息、對話還原列表、語音信 息等添加水印，以防信息泄露和追源。添加水印處理后訂單詳情信息展示部分默 認界面的實現情況如圖5-13和圖 5-14 所示。
訂單回溯/訂單詳情
訂單信息
訂單信息
原始訂單號 17656961010940 加密訂單編號 TWpnNU1qZzRORFExT1 Rid05UQTFOekkw
創建訂單時間 2019-12-19 23:58:43 開始計貝時間 1971-01-01 00:00:00
接單時間 2019-12-19 23:58:48 訂單完成時間 1971-01-01 00:00:00
取消時間 1576771247 取消人 -1
是否代叫車 0 是否是目的地訂單 0
城市 無 步行導航距離 -1
目的地 福清市I溪頭村 導航距離 13
汽車品牌 取消訂單后距離下一單接單時長
汽車顏色 取消訂單一段時間內的岀車占比 -1
汽車牌照 取消訂單一小時后是否有接單記錄
搶單時間距出發地的預估時間 48 訂單類型 0
圖 5-13 訂單詳情信息展示部分界面實現圖
Figure 5-13 Order realization information display part of the interface implementation diagram
行程錄音
行程錄音1
開始時間：2019-12-19 23:58:53 | 結束時間：2019-12-19 23:59:32
文件名：20191219235945176569610109402fd103176e3a7045b02fad4e69e7a2908.amr
仟理宗咅9
圖 5-14 清單詳情信息展示部分界面實現圖
Figure 5-14 Partial interface implementation diagram of detailed list information display
用戶可在訂單詳情信息展示界面查看司機信息和乘客信息，其中乘客信息里 的關系包含有單人、拼車、和同行，用來鑒別同一單所涉及的乘客之間的關系。 點擊每條對話列表的標題可進入對話重現界面，對話重現界面以司機和乘客文字 對話的聊天框形式模擬重現該條通話信息中包含的內容。司機和乘客的聊天框進 行整體抽取作為單獨的功能部分，對司機和乘客聊天展示條目進行組件抽取，降 低組件嵌套程度，提高復用性。添加水印過后的對話重現界面的實現圖如圖 5-15 所示，訂單號查詢信息部分的類圖如圖 5-16 所示。
對話列表
▼對話歹!I表1 （電話）通話時間：|通話時長：s|通話錄音：播放錄音
&喂你好滴滴專車不好意思滴滴
2大概呀那個接單應該給給給點錯了你別取消一下行李的給你商星一下
啊
金不是你
注應該不會客氣了這有一個客人沒辦法呀
圖 5-15 對話重現界面實現圖
Figure 5-16 Order number query class details of order details
48
如圖 5-16 所示，訂單號查詢訂單詳情信息部分主要涉及的類有 Driver、 Passenger、OrderDetail、OrderDetailController 等。其中 Driver 類和 Passenger 類繼 承自Cuser類，從屬于OrderDetail類，作為OrderDetail的組成部分，OrderDetail 為前后端在訂單詳情部分傳輸訂單信息的主要載體，由 OrderDetailController 對 OrderDetailServiceImpl 調用 OrderDetailMapper 從數據庫中查詢到數據進行整理， showOrderDetail、showOrderTimeLine()、showCallrecords 和 exportOrderDetail 方法 分別對應訂單詳情展示、訂單行程時間軸、訂單通話記錄信息和單條訂單新消息 的導出，由 OrderDetailController 負責根據前端請求統一調度。
5.3.2關鍵字查詢和安全事件類型查詢
關鍵字查詢和安全事件類型查詢功能相似，實現思路也相似，所以放在一起 說明。關鍵字查詢可輸入任意有效關鍵字并選定時間后，后臺在所有有效訂單中 進行針對所輸入的關鍵字搜索，將命中的數據整合在一起并打包，然后將打包后 的包名、數據量、下載地址等數據信息返給前端展示。安全事件類型查詢功能與 此相似，下拉框中選擇相應安全事件類型并選擇時間后即可查詢并導出查詢結果 數據。關鍵字查詢的流程圖如圖 5-17 所示。
圖 5-17 關鍵字查詢流程圖
Figure 5-17 Keyword query flowchart
用戶訪問關鍵字查詢界面會先校驗權限，校驗失敗的用戶無法進行關鍵字查 詢操作，權限校驗的流程和前面部分相同不再贅述。用戶權限校驗通過后可在輸 入框輸入關鍵字和選擇篩選時間，篩選時間默認為前一天，不可選擇未來的時間。 關鍵字和時間選定后必須先進行搜索，待搜索結束輸入欄下方的表格展示搜索結 果后才可選擇導出，未搜索前導出按鈕置灰。安全數據類型查詢部分安全數據類 型為給定數據，可從下拉框中選擇，當前具體數據為：人車不符、代叫車、涉性、 索要聯系方式、切單和醉酒，其內容可隨現實需求狀況調整。安全事件類型導出 部分在選定事件類型和時間執行導出命令后，后臺會花費時間去查詢并打包處理 相對應的數據，在此期間前端采用輪詢策略詢問查詢數據的整合狀態，當數據整 合完畢后再執行導出操作，具體過程如圖 5-18 所示。
圖5-18安全事件類型查詢時序圖
Figure 5-18 Timing diagram of security event type query
鑒于數據的查詢和整合花費一定時間，若數據整合完畢前發起數據導出請求 必然會請求失敗導致無效的數據導出行為，所以前端通過 setTimeOut 設置輪詢， 每隔 1 秒向后端查看一次數據是否執行完成，當得到肯定答復后終止定時器，發 送數據導出請求。該部分功能的類圖如圖5-19所示。
圖5-19關鍵字查詢和安全事件類型查詢功能類圖
Figure 5-19 Keyword query and security event type query function class diagram
如上圖所示，關鍵字查詢和安全事件類型查詢功能主要涉及的類主要有 BatchExportController 、 BatchExportUtil 、 BatchExportOrdersService 等。其中 DisposeOrderListener 類為數據查詢整合操作的監聽器，當用戶通過前端頁面觸發 安全事件類型查詢操作時，BatchExportController 類通過 findOrdersBySafeCategory 方法向下調用Mapper去數據庫中查詢篩選符合條件的訂單數據信息，查詢到所需 要的數據后 BatchExportController 類會調用 BatchExportUtil 類的 exportOrders 方法 對數據進行整理和轉換， DisposeOrderListener 類會監聽這個過程。當前端一遍遍 的輪詢時， DisposeOrderListener 會返回數據整合過程的結果，整合完畢后再由前 端發起數據導出請求，瀏覽器執行下載任務將整合好的數據下載并存儲至瀏覽器 的默認下載路徑。請求到的文字數據包含訂單號、安全事件類型、備注和 evidence 等基本信息，批量導出的文本數據的具體實現圖 5-20 所示，該部分功能的實現圖 如圖 5-21 所示。
| speech-ability-sex-20191216
{\,,record-id\,,:\,,12019121523570100464617891\,,,\,,inuinduce\,,:\,,0\,,f\,,answer^ts\":
I 1576425428}}"f"sid": 260,"city_id":3,"evidence"點;,曲誡;:0," role":0* "start.t": 1576425443/'word"?男朋友的第一由口啊。"}]}
{"^oid":"35204924691794","timestamp":1576425627,"ability":"sex","attribute":"<\"common\": {\"record_id\":\"425df65820398014\",\"iT_induce\":\"0\",\"answer^s\":1576425509}}"r"sid": 260, "city_id": 360, "evidence" : [{"im^msg" : 0role" : 1, "start_t'' : 157^425510/'word":"喂女朋法:中學 啊，啥。"}]}
{"^oid":"17656013521452" /'timestamp":1576425628,"ability":"sex"/'attribute":”{'“common\“: {\,,record-id\,,:\,,320191215235756014090851480\,,f\,,im_induce\" :\"0\"f X'^nswer^tsV": 1576425486}}"f "sid": 260, "city.id": 48, "evidence": " role" : l/'starTt":
1576425519,,,word,': “我在這里頭要示干你你的頭呢？ "}]}
{“qoicT:“156723877862405“ /'timestamp":1576425630,"ability":"sex","attribute":”{\“common\”: {\"'record_id\" :\"67706958642058481991576425476208\"八“丄曲旦\” : \“0\“ A"answer^ts\": 1576425485}}" t "sid": 261, "city_id" : 91, "evidence": [{"inumsg." : 0," role" : 1, "start__t": 1576425491, “worf 我就愛姐姐了o "}]}
{"Soid":"17656013841815"."timestamp":1576425630,"ability":"sex"."attribute":"{X'^ommonX": {\"record_id\" :\"415df657e43f7414\"八”丄船I”：\"0\",\"answer^ts\": 1576425450}}"f"sid": 260, "city^id": 17,"evidence": [{,,i^sgb,,707'roie'；: 0,''starl.t1': 1576425450, "word":"妹妹。哼]} {"Soid":"17656013965107"「timest亦1576425631,“ability”:"sex"."attribute":"{X'^ommonX": {\“Fd&rd_id\“：\“：L20：L912：L52357：L5004646398：L0\“ 八“inuinduce\“：\“0\“，\“answejts\“： 1576425447}}"r "sid" : 260f "city^id" : 18, "evidence":'[FinTrnsgL" ： 0," role" :0, "starCt"： 1576425448,%。n?「謝矣師傅，你想陪我在火車了。"}]}
{"^oid":"35204923384197" /'timestamp":1576425631,"ability":"sex"/'attribute":”{'“common\“: {\"record=id\" :\,,415df657d523adl4\"八壯『十遼製匸豈、“:\"0\", \"answer_ts\" : 1576425440}}“r "sid":
| 307, "city一id": 36, "evidence" : [{"im^msg" : 0f" role" : 1, "start__t" : 1576425479, "word":"酒吧到莪殂還 j讓我得慢了嗎？ “}]}
I {'^oid；':“156723877440879“/'timestamp":1576425632,"ability":"sex","attribute":”{\“common\”: Pfi\”一、”中皿 Pnch】ca\” ： -'"nnawar
圖 5-20 安全事件類型查詢導出的文本實現圖
Figure 5-20 Text implementation diagram of security event type query export
圖 5-21 關鍵詞事查詢功能實現圖
Figure 5-21 Implementation diagram of keyword query function
5.4安全規則定制模塊
安全規則定制模塊主要提供規則制定和操作清洗任務兩部分功能。規則定制 部分包含規則的創建、修改、展示和歷史記錄查詢；操作清洗任務部分包含任務 的配置、啟動、暫停、展示等，清洗任務分為人工清洗和機器智能清洗，下面詳 細論述這幾部分的內容。
5.4.1清洗規則制定
規則制定部分提供詳細的規則創建、修改和展示的場景，并輔以修改記錄時 間軸，方便查詢和回退修改記錄。清洗規則展示界面提供規則篩選功能，可根據 規則類別、數據清洗類型和關鍵字進行篩選，規則展示列表條目中展示規則名稱、 規則描述、清洗數據類型、創建時間、創建人、最近修改人等基本信息，點擊規 則條目可查看規則詳情信息。規則制定部分的流程圖如圖5-22所示。
圖5-22規則定制流程圖
Figure 5-22 Rule customization flowchart
用戶進入規則定制部分后，默認為信息規則展示界面，可在該界面進行規則 篩選、創建規則和查看規則詳情內容。點擊任意一條規則條目后進入該條規則的 詳情頁面，規則詳情界面展示規則基本信息、機器清洗模型配置和歷史操作記錄
三部分，其中基本信息包括規則名稱、規則描述、單次任務閾值、清洗數據類型、 場景名稱和喚醒詞；機器清洗模型配置有模型類型、識別結果、 ASR 結果、人聲 情況等多個選項，對口數據清洗任務所需的實際需要，一條規則中可配置一條或 多條機器清洗模型數據；歷史操作記錄包含過往操作版本編碼、操作時間、和操 作人員信息，點擊該條規則的不同操作記錄按鈕可查看過往歷史版本中該條規則 的過往數據。從規則詳情頁面可進入編輯該條規則的頁面進行規則修改操作，對 已經存在的規則只可以修改除了清洗數據類型、場景名稱和喚醒詞三者以外的配 置，機器清洗模型可任意增刪修改，每次修改完成后系統會記錄修改操作和操作 人的基本信息。用戶在規則展示頁面可點擊查看規則按鈕進入規則創建界面，配 置清洗規則的各項數據，用戶需要先選擇數據清洗類型后才可選擇場景名稱和喚 醒詞內容。規則創建時不可創建同已存在規則相同類型的規則。清洗規則同類型 的判定方法為，若兩條清洗規則的清洗數據類型、場景名稱和喚醒詞具體內容三 者都相同，則認定該兩條清洗規則為同類型。在創建清洗規則時，若用戶配置了 同類型的清洗規則系統會給與該條規則已經存在的提示，若用戶繼續編輯創建， 則在用戶點擊保存按鈕時二次提示規則已存在，用戶二次確認后該條新規則會自 動覆蓋原有的同類型規則，即同類型清洗規則只可以保存一條。清洗規則展示界 面和清洗規則詳情界面的實現圖如圖 5-23和 5-24所示。
清洗規則
類SU： 畫全部 與我相黃
數據清核型：畫全部如司
I Q
第三條規則（修改二次）
雌：
更新時間：2019-12-02 10:19:211 創建人：wangyuling」| 最近修改：wangyulingj
第二條規則（修改三次次）
ffiS: test6®fl9S-^19l!J
嗎司
更新時間：2019-12-02 10:1&481 創建人：wangyuling」| 曼伽改：wangyulingj
第一條規則
JraS： test施
na® 旨
圖5-23清洗規則展示界面實現圖
Figure 5-23 Implementation diagram of the cleaning rule display interface
規則詳情
基本信息
機器清洗模型配置
轄嫩11:
剛結果 等于 已畫
圖 5-24 清洗規則詳情界面實現圖
Figure 5-24 Implementation diagram of the cleaning rule details interface
規則定制部分所涉及類圖如圖 5-25 所示。
如上圖 5-25,該部分主要涉及的類有 WashRuleController、WashRulelogService、 WashRuleService 等。 當用戶進入規則展示界面時， WashRuleController 類的
showWashRuleList 方法調用 WashRoleService 實現類和 WashRuleServiceMapper 類 中的方法去數據庫查詢清洗規則展示簡要數據，而getWashRule方法提供規則的詳 細信息。當用戶進行規則創建和修改操作時， WashRuleController 會調動 WashRoleLogService 和相對應的 Mapper 去進行歷史操作日志的記錄。
5.4.2操作清洗任務
清洗任務分為人工清洗和機器清洗，傳統的人工清洗為工作人員對相關車單 數據進行逐條查看其詳細內容，挑選出問題車單進行人工標注記錄，使用的工具 主要為網約車安全信息管理平臺的車單信息操作部分，這里我們重點介紹機器清 洗。
機器清洗結合相關算法，在語音識別、圖像識別和文字識別上進行數據的篩 選，標注出問題車單，需要配置相關數據創建并開始清洗任務，清洗結束后輸出 標注好的數據。機器清洗過后會進行隨機抽取清洗任務的結果進行質檢，對質檢 不通過的清洗任務進行反饋。操作清洗任務的具體流程如圖 5-26 所示。
圖5-26操作清洗數據流程圖
Figure 5-26 Operation cleaning data flow chart
當用戶進入喚醒數據回流界面時，默認展示清洗任務列表，用戶可在該界面 進行清洗任務的相關操作。可在該頁面發起創建清洗任務、查看清洗任務的各部 分和查看日志記錄。其中創建清洗任務需要配置清洗任務數據，配置數據主要包 含：場景名稱、喚醒詞、 SDK 版本號、待清洗數據分類、清洗數據開始時間和結 束時間等。場景名稱和喚醒詞可確定該條清洗任務所用的清洗規則，不可創建包 含未存在的清洗規則的清洗任務，若檢測到所用規則不存在會創建失敗。清洗數 據分類和清洗時間可對需要清洗的數據進行挑選，實現定向清洗。在清洗任務列 表可行看到已經創建成功的清洗任務們，點擊查看狀態按鈕可查看該條任務的當 前狀態，并選擇開始任務或者暫停任務，任務狀態可手動刷新。已經存在的任務 可進行修改和刪除操作，但不可修改和刪除正在進行中的清洗任務，需要手動暫 停后可刪除或者修改。清洗任務主要由上游AI算法賦能，網約車安全信息管理平 臺調用已經存在文字識別和語音檢測檢測敏感詞匯和語句，使用圖像識別進行傳 統的司機身份識別、攝像頭遮擋檢測、車內人員數檢測和車內人員性別檢測，除 此之外網約車安全信息管理平臺還新增加了基于 MobileNetV2 算法的司機抽煙行 為檢測。當清洗任務執行結束后，可查看清洗結果，同時進行質檢操作，比對機 器清洗任務的合格率，給出質檢結果意見，對有問題的清洗任務給與相應的反饋。 同一類清洗任務可多次質檢，根據實際情況給與不同結果。
不管是清洗任務的操作還是質檢的操作都會進行日志記錄，日志會記錄操作 的人員、操作時間、操作內容和操作結果描述，清洗任務操作的操作結果包含成 功的數據清洗結果和失敗時的操作結果以及錯誤提示信息。可從喚醒數據回流界 面進入日志界面查看這兩部分的操作日志，方便對數據清洗全流程的追蹤和問題 查詢。整個操作清洗任務的類圖如圖 5-27 所示。
圖5-27操作清洗任務類圖
Figure 5-27 Class diagram of operation cleaning tasks
如圖 5-27， 操作清洗任務部分主要涉及的類有 WashTaskController、 QualityTestController、LogService 等。當用戶觸發清洗任務的創建、查看、修改和 刪除操作時WashTaskController會調用相關的Service類和Mapper類進行清洗任務 庫表操作。用戶開始、暫停和刪除操作時WashTaskController會調用上游提供的算 法相關接口實現任務的上述操作。WashTaskController在響應用戶操作的同時會調 用 LogService 中的 相 關方法觸發記錄。 同樣， 當用 戶 進行 質檢時 QualityTestController也會調用其Service類和Mapper類進行增查改等數據庫操作， 質檢操作也會由 LogService 中的方法進行記錄操作信息。當用戶查看記錄時， LogService 會從庫中查詢到清洗任務或者質檢的操作日志經由 Controller 返回前 端，實現日志信息的展示。
5.5數據清洗實現部分
數據清洗分為人工清洗和智能機器清洗兩部分，二者目前為共存狀態，相互 補充，人工清洗技術成本低但效率十分低下，且因操作人員的不同正確率也無法 保證，智能機器清洗效率高、準確率有統一標準，但機器清洗使用范圍的普及有 賴于各類數據處理算法的實現，技術成本高，未來有智能機器清洗逐步全面代替 人工的發展趨勢。人工清洗的實現主要依靠人工查閱數據，鑒別數據類型，檢查 數據是否存在待處理問題，手工標注數據，依靠的是操作者的數據識別、知識儲 備、鑒別反應等能力，該功能的實現主要為操作者本體。所以本文主要論述智能 機器清洗部分，智能機器清洗為依托封裝好的人工智能算法，對數據按照需求進 行處理標注[30]。用戶僅需要按照標準在網約車安全信息管理平臺上制定清洗任務， 操作清洗進度，便可實現高效的數據清洗，得到有效的數據結果。網約車安全信 息管理平臺在傳統的人臉識別、人數檢測等圖像識別功能上還探索了抽煙行為的 智能檢測，下面闡述抽煙行為檢測的細節。
針對抽煙行為的圖片數據智能清洗有著數據量大、清洗次數多、未來有在移 動端普及等特點，最終選定抽煙行為的智能檢測基于MobileNet-V2來實現，作為 輕量化神經網絡， MobileNet-V2 有著低運算量和低參數量的特點，其網絡結構如 表 5-1 所示 [31] 。
表5-1 MobileNet-V2網絡結構
Table 5-1 MobileNet-V2 network structure
Input Operator 擴張倍數 輸岀通道 重復次數 步長
2242 x3 conv2d — 32 1 2
1122 x32 bottleneck 1 16 1 1
1122 x 16 bottleneck 6 24 2 2
562 x24 bottleneck 6 32 3 2
282 x32 bottleneck 6 64 4 2
142 x 64 bottleneck 6 96 3 1
142 x 96 bottleneck 6 160 31 2
72 x 160 bottleneck 6 320 1 1
72 x320 conv2d 1 x 1 — 1280 1 1
72 x 1280 avgpool 7 x 7 — — 1 —
1 x 1x1280 conv2d 1 x 1 — k —
如上表中所展示的，MobileV2網絡結構包含普通卷積，自定義的bottleneck模 塊以及平均池化層。首先原始輸入圖像經過步長為2的普通卷積擴張到32通道； 后經過17個不同參數設定的順序bottleneck模塊將通道維擴張到320；最后通過兩 個1x1的卷積升維/降維以及中間夾帶的平均池化層，輸出結果。其中自定義的 bottleneck模塊如圖5-28所示。
圖 5-28 自定義 bottleneck
Figure 5-28 Customizing bottleneck
MobileNet-V2中自定義的bottlenec模塊先采用1x1的PW擴張，再進行3x3 的DW卷積，最后采用1x1的PW壓縮oMobileNet系列均采用Depth-wise separable convolution (深度可分離卷)卷積的方式來提特征，深度可分離卷積將傳統的卷積 分解為一個深度卷積(depthwise convolution)和一個1x1的卷積(pointwise convolution)，成倍的減少卷積層的時間復雜度和空間復雜度，從而有效的減少了 運算量和參數量，提高運算效率，十分適合網約車管理平臺數據清洗的需求特點。 MobileNet-V2 在 DW 之前多了一個 1x1 的擴張層，專門用來升維，定義升維系數 t=6,從而提升了通道數，可以獲得更多特征，形成了從擴張到卷積提特征，再到 壓縮的過程，解決了該層提取得到的特征受限于輸入的通道數的問題。ReLU激活 函數在高維空間能夠有效的增加非線性，而在低維空間時則會破壞特征,故而去掉 了第二個 PW 的激活函數，減少特征值的破壞，從而在保證運行效率的前提下保 證準確率［32］。
當用戶制定并執行抽煙行為檢測的智能清洗任務后，會按照該任務設置中的 配置數據從數據庫中篩選數據，庫中數據來自移動端應用通過手機在車單執行途 中拍攝的記錄信息，為上游移動端負責提供。取得待處理數據集之后便使用之前 訓練好的抽煙行為檢測模型進行分類處理，再將車單的標注結果寫進庫中，識別 出的所有疑似包含抽煙行為的車單會作為本次清洗任務的結果，供判責操作使用。
5.6安全判責模塊
安全判責模塊主要包括判責車單的展示、車單判責驗收管理、判責驗收記錄 幾部分，進入安全判責模塊需要先校驗權限信息，權限符合才可進入，否則給與 無權提示，進入該部分后可進行判責和驗收相關操作，需要判責的車單信息來源 為人工或智能機器清洗標注的數據、網約車司機或乘客舉報或評價的數據、客服 人員標注的數據等。安全判責模塊具體的流程如圖 5-29 所示。
圖 5-29 安全判責模塊流程圖
Figure 5-29 Flowchart of Security Judgment Module
當用戶進入安全判責模塊界面后，默認展示所有安全判責相關的車單列表， 車單列表按時間倒序排列。用戶可在篩選框內選擇與我相關只展示自己待處理或 已經處理的車單，同時可以從安全事件類別、時間、判責狀態等方面進行篩選。 判責車單條目中顯示車單基本信息，包括車單號、車單類型、時間、車單處理狀 態、判責處理狀態、判責結果概述、安全事件類型、判責處理人員、驗收處理人 員等。
點擊判責車單條目可跳轉至該車單的判責詳情頁面，查看該車單的簡要信息、 判責輔助信息、該車單的判責和驗收記錄、判責信息和驗收信息。其中判責輔助 信息包含判責內容提示和判責規則提示，判責內容提示該車單疑似有何種違規， 建議判處何種安全事故類型的責任，判責規則提示為與該疑似問題相關的規則介 紹提示；判責信息包含有判責人員、判責結果、責任等級、判責時間、判責類型、 證據來源、違反條例、判責輪次、備注信息、建議處理方式和反饋信息等內容； 驗收信息包含有驗收人員、驗收結果、驗收時間、驗收輪次、驗收備注和反饋內 容等信息，驗收結果分為通過，修改和不通過三種；判責和驗收記錄中記錄了判 責或驗收的操作人員、時間點、結果等信息，可在判責和驗收記錄中檢索并查看 所有有效車單的判責和驗收記錄。在判責車單詳情界面可進入判責操作頁面或驗 收操作頁面，可跳轉至該車單的信息詳情頁面查看該車單具體的文字、圖片、語 音等信息。鑒于判責過程可能時間很長，分多個步驟進行，所以判責操作部分提 供保存功能，進入判責操作界面填寫判責相關信息并保存后該車單的判責狀態由 待處理狀態更變為判責中狀態，保存的數據可以不完整，僅作為臨時存儲，當判 責內容操作結束后點擊提交按鈕，將會提交本次判責所有相關數據，并視為一次 判責記錄，該車單的狀態由判責中變更為已判責，若此后再修改判責信息再次點 擊提交會視為第二輪判責記錄，后續以此類推。處于已判責狀態的數據可以進行 驗收操作，驗收人員在查看判責結果、判責證據來源、車單相關人員反饋信息后， 若比對車單實際數據無誤，且同意判責等級、建議處理方式等信息后可以予以驗 收通過，若存在上述問題可給與修改或不通過的結論。修改或者不通過的車單需 再次判責，判責后再次驗收，直至驗收通過為止。安全判責管理人員可從安全判 責模塊進入判責驗收管理界面，通過管理員權限校驗后可以為相關工作人員分配 待判責或待驗收的車單，分配后相關工作人員可查看自己被分配到的待處理車單 任務。
queryJudgementLogsO insertAcceptanceCheckLog () aueryAcceotanceCheckLcigs ('i
圖5-30安全判責模塊類圖
Figure 5-30 Class diagram of security judgment module
如圖 5-30 所示，安全判責模塊所涉及的類主要有 JudgementController 、 AcceptanceCheckController、 LogService 等。其中 JudgementController 負責實現判 責相關功能，為車單列表、判責詳情內容、判責結果等展示提供數據，對接判責 操作的處理邏輯，內部相關方法實現對判責信息庫表增查改等操作，并通知 LogService 對判責操作行為和判責結果進行記錄。 AcceptanceCheckController 類起 著相似的作用，對接驗收相關邏輯，調用 AcceptanceCheckService 及其實現類進行 驗收結果的保存和修改。LogService提供對判責操作和驗收操作記錄的方法，并通 過 LogMapper 操作數據庫根據訂單號提取表中保存的判責或者驗收日志信息，將 提取的信息通過Controller類交給前端部分進行展示。
5.7本章小結
本章以綜合管理模塊、數據展示模塊、車單信息操作模塊、安全規則定制模 塊和安全判責模塊五部分為骨架，各部分相關功能點、技術點為延伸，通過使用 流程圖、時序圖和類圖等圖片以及必要的文字說明對網約車安全信息管理平臺的 詳細設計內容進行了細致的闡述，再結合以相關界面的實現截圖，讓讀者通過閱 讀本章節可以清晰明了的掌握網約車安全信息管理平臺各個部分的設計情況和實 現效果。
6系統測試
測試是為了發現程序中的錯誤而執行程序的過程，它貫穿于整個軟件的研發 流程，就目前而且，軟件測試仍然是保證軟件可靠性的主要手段，其根本任務是 發現并改正軟件中的錯誤［33］。本章主要從系統的測試環境、功能性測試和非功能 性測試來介紹網約車安全信息管理平臺的測試工作。
6.1測試環境
測試前需要對測試環境進行部署，考慮到網約車安全信息管理平臺面向公司 內部不同崗位的員工使用，不同員工的軟硬件配置不同，對測試環境進行了以下 配置，系統具體的測試環境如表 6-1 所示。
表 6-1 測試環境
Table 6-1 Testing Environment
條目 內容
操作系統 Windows 10、Mac OS
CPU 4 核、 8 核
帶寬 5Mbps
數據庫環境 Mysql Server 5.6.32
瀏覽器 Chrome、IE、火狐
6.2功能性測試
功能測試是對產品的各功能進行檢查，根據產品需求設計出功能測試用例， 逐項檢驗，測試產品是否達到用戶所要求的功能標準。本節使用黑盒測試的方法 編寫測試用例，依據需求分析對網約車安全信息管理平臺的各項功能進行檢測， 下面展示各部分功能的具體測試用例。
綜合管理模塊是用戶使用本平臺的初始模塊，用戶在該部分實現登錄認證、 權限校驗、展示界面等功能，鑒于公司內部權限控制在專有應用上管理，本平臺 的準入校驗需要拉取公司專有權限應用上數據進行校驗，該部分準入校驗功能的 測試用例如表 6-2 所示。
表 6-2 準入校驗功能測試用例表
Table 6-2 Admission check function test case table
測試用例編號 TC001
測試用例名稱 準入校驗功能測試
目的 驗證能否準確獲取用戶個人信息并根據頁面展示和操作校驗相關 權限。
優先級 高
前置條件 數據庫服務正常，網絡連接正常。
測試流程 (1)使用瀏覽器進入該平臺，并輸入不同的賬號密碼進行登陸。
(2)從綜合管理模塊界面跳轉至文檔中心查看文檔、上傳文檔。
(3) 從綜合管理模塊界面依次跳轉至數據展、車單信息操作、安全 規則定制、和安全判責模塊。
預期結果 用戶登錄操作可以正常的拉取到用戶信息進行登錄校驗，失敗給 與提示，登錄成功后在進入每個功能界面前再次核對用戶權限，具 備該操作權限的用戶可進入該界面并進行操作，否則無法跳轉操作。
測試結果 登錄時賬號密碼校驗正常，成功拉取到用戶個人信息，無權限用 戶在跳轉界面時跳轉操作被拒絕且提示正常，文檔中心查看正常， 刪除操作二次校驗權限操作正常。
結論 測試結果符合預期，測試通過。
數據展示模塊主要針對不同數據需求提供各種數據的可視化表格，并根據不
同維度不同篩選條件進行數據區別展示，該模塊數據可視化展示功能的測試用例
如表 6-3 所示。
表 6-3 數據可視化展示功能測試用例表
Table 6-3 Data visualization display functional test case table
測試用例編號 TC002
測試用例名稱 數據可視化展示功能測試
目的 驗證數據可視化表格展示是否顯示正常，所展示數據能否根據不同篩選
條件正常變更。
優先級 高
前置條件 數據庫服務正常，網絡連接正常，用戶己登錄
表 6-3 (續表)
Table 6-3(Cont.)
測試用例編號 TC002
測試流程 (1)進入數據展示界面，選擇按日展示，查看不同日期、不同地區的 數據，查看表格中關鍵點詳細數據的觸碰展示效果。
(2)選擇按月展示，查看不同月份、不同地區的數據，查看表格中關 鍵點詳細數據的觸碰展示效果。
(3)選擇按安全事件展示，查看不同日期、不同地區的數據，查看表 格中關鍵點詳細數據的觸碰展示效果。
預期結果 根據所選不同時間、不同地理位置等條件正常展示對應的折線圖、
餅圖、柱狀圖等圖表，數據加載正常。
測試結果 各項圖表展示正常，圖中對應數據正確，關鍵點可現實詳情信息。
結論 測試結果符合預期，測試通過。
車單信息操作模塊是對單條車單信息操作的主要實現場所，提供與該車單相 關的最為詳細數據資料，以文字、圖片、語音等多種形式展出。車單信息操作展 示功能的測試用例如表 6-4 所示。
表 6-4 車單信息操作展示功能測試用例表
Table 6-4 Car order information operation and display test case table
測試用例編號 TC003
測試用例名稱 車單信息操作展示功能測試
目的 驗證能否根據訂單號、事件類型或關鍵字定位到具體的車單信息，
判斷具體車單的各項信息是否正確展示，導出功能是否正常。
優先級 高
前置條件 數據庫服務正常，網絡連接正常，用戶已登錄。
測試流程 (1)進入車單信息操作界面輸入車單號查詢該單號對應的車單信息。
(2)比對訂單信息時間軸數據展示狀況，時間軸上關鍵點注釋顯示隱 藏是否正常。
(3)從時間軸界面切換至詳情信息展示界面，比對詳情信息，點擊語 音回放，查看通話聊天再現內容。
(4)使用不同安全事件類型篩選車單，查看篩選結果，并批量導出。
(5)使用不同關鍵字篩選車單信息，查看篩選結果表格，并下載結果.
表 6-4(續表)
Table 6-4(Cont.)
測試用例編號 TC003
預期結果 輸入車單號查詢后顯示訂單信息時間軸，時間軸和詳情信息可自由
切換，詳情信息和聊天再現正常展示，錄音播放正常，批量導出正常。
測試結果 車單號可正確定位到制定車單信息，信息顯示無誤，錄音可正常播 放，詳情信息和聊天再現內容比對正確，安全事件類型和關鍵字篩選 功能正常，成功導出結果數據。
結論 測試結果符合預期，測試通過。
安全規則定制模塊的功能主要圍繞安全規則操作和清洗任務操作兩方面，其 中安全規則操作包括規則的內容查看、創建、修改等，清洗任務操作包含任務的 創建、修改、執行以及該任務對應的質檢功能。安全規則操作功能的測試用例如 表6-5所示，清洗任務操作功能的測試用例如表6-6所示。
表 6-5 安全規則操作功能測試用例表
Table 6-5 Safety rule operation function test case table
測試用例編號 TC004
測試用例名稱 安全規則操作功能測試
目的 驗證安全規則的創建、修改功能是否正常，歷史記錄是否正確顯示。
優先級 高
前置條件 數據庫服務正常，網絡連接正常，用戶已登錄且具備規則制定權限。
測試流程 (1)進入規則定制界面，查看已存在規則列表，比對展示的規則數據。
(2)點擊創建按鈕，分部填寫正確和錯誤的配置信息，分別按照正確 的創建流程和錯誤的流程進行創建規則，查看創建結果是否正確。
(3)創建已經存在過的規則，查看創建提示，選擇繼續創建并保存最 新內容，創建原規則是否被覆蓋。
(4)查看規則詳情，切換歷史記錄，修改已經存在規則信息并保存。
預期結果 規則列表可正常展示和篩選，規則詳情數據正確展示，創建、修改可
正常操作，且均有錯誤提示和歷史記錄。
測試結果 規則列表展示正常，規則數據詳情內容正確，僅執行正確創建流程 可創建成功，非正確流程案例創建失敗，創建和修改的歷史記錄展示 正確，修改記錄可正常切換查看。
結論 測試結果符合預期，測試通過。
表6-6清洗任務操作功能測試用例表
測試用例編號 TC005
測試用例名稱 清洗任務操作功能測試
目的 驗證清洗任務是否可以正常創建、修改和執行，清洗結果是否無誤， 質檢流程操作是否正常。
優先級 高
前置條件 數據庫服務正常，網絡連接正常，用戶已登錄且擁有操作權限。
測試流程 (1)進入清洗任務操作界面查看已存在的任務信息列表和任務各部 分詳情信息。
(2)選擇不同的場景名、喚醒詞、SDK版本號和時間等信息的組合 創建清洗任務。
(3)選擇已經存在的場景名和喚醒詞的組合創建清洗任務。
(4)選擇不同的已存在的任務進行開始、暫停等操作，并查看輸出 結果。
(5)對已清洗完畢的任務結果進行質檢并給出質檢結果。
(6)刪除已經存在的清洗任務
預期結果 清洗任務數據展示正常，可正常創建、修改，創建后的任務可執行，
任務輸出結果符合預期，可正常質檢。
測試結果 清洗任務列表展示正常，任務各部分詳情數據無誤，不同場景名、 喚醒詞、 SDK 版本號和時間等信息的組合可正常創建清洗任務，創 建同已存在清洗任務相同類型的任務失敗，清洗任務執行、暫停功能 正常，輸出結果標注符合要求，質檢操作流程正常。
結論 測試結果符合預期，測試通過。
安全判責模塊提供圍繞判責操作的判責任務的差異化展示、判責任務分配、 判責記錄查詢、判責定責、驗收判責結果等一系列服務，對已標注的數據有著任 務分配到判責定責，再到驗收判責結果一整套流程要求，該部分判責功能的測試 用例如表 6-7 所示。
表 6-7 判責功能測試用例表
測試用例編號 TC006
測試用例名稱 判責功能測試
目的 驗證判責任務個性化展示是否正常，任務分配功能是否正常，判斷
判責定責、驗收結果是否可以正常操作，且操作結果顯示正確。
優先級 高
前置條件 數據庫服務正常，網絡連接正常，用戶已登錄且具備判責操作權限。
測試流程 (1)進入判責操作界面查看判責任務列表，為其他用戶分配不同的判 責任務。
(2)勾選與自己相關的任務、選定涉性安全事件類型，查看篩選結果。
(3)點擊任務條目，查看判責相關的具體信息，跳轉至車單詳情頁面 并返回。
(4)填寫判責結果，標注證據來源，保存內容。再次進入該任務，修 改并補全判責相關信息并提交。
(5)對已判責的任務進行驗收操作，給與修改結果并反饋。二次判責 后再驗收，給與通過并反饋。
(6)查看上述操作的記錄。
預期結果 判責任務可正常分配，判責任務可差異化展示，頁面可來回跳轉，判 責和驗收流程可以正確執行。
測試結果 正確查看與到與自己相關的所有涉性類型的判責任務信息，任務詳 情信息展示無誤，頁面跳轉后對應數據正確，判責過程填寫數據保存、 提交正常，二次判責通過，二次驗收正常。
結論 測試結果符合預期，測試通過。
6.3非功性能測試
非功能性測試和功能性測試互為補充，主要針對更廣泛的質量問題進行測試， 旨在檢測軟件的性能、可用性、可靠性等。本平臺涉及了大量數據展示，前端部 分使用 Vue 和 Echarts 以及 JavaScript 的眾多新特性，因此需要對平臺的兼容性和 屏幕的適應性進行測試。現今市面上不同的瀏覽器大多擁有不同的內核，導致同 一份代碼在不同的瀏覽器上有著不同的效果，本節選取了當前幾款主流的瀏覽器 來進行測試，瀏覽器兼容測試的用例如表 6-8 所示。
表 6-8 瀏覽器兼容測試用例表
Table 6-8 Browser compatibility test case table
測試用例編號 TC007
測試用例名稱 瀏覽器兼容測試
目的 查看系統能否在主流瀏覽器上正常運行。
優先級 高
前置條件 數據庫服務正常，網絡連接正常。
測試流程 (1)在 Chrome 上打開本平臺，運行所有功能。
(2)在 Safari 上運行本平臺，測試平臺全部功能。
(3)在火狐上打開本平臺，運行所有功能。
(4)在 IE8 上運行該平臺，運行平臺所有功能。
(5)在IE9上運行該平臺，運行平臺所有功能
預期結果 平臺在絕大部分各種瀏覽器上都可正常運行，各項功能運作正常。
測試結果 平臺在Chrome、火狐、IE9和Safari上運行正常，在IE8上存在部
分展示和功能判斷問題。
結論 Vue支持IE9及以上版本的IE瀏覽器，對IE8存在部分兼容問題， 考慮到平臺的使用場景和 IE8 的使用人數，本平臺對市面上絕大部分 的瀏覽器的兼容符合預期，測試通過
經過前期調查本平臺的使用者主要使用的硬件為各類品牌的筆記本和臺式機 外接顯示屏，所以對以上顯示設備的主流分辨率進行了挑選，本平臺對不同分辨 率顯示的自適應測試用例如表 6-9 所示。
表 6-9 分辨率自適應測試用例表
Table 6-9 Resolution adaptive test case table
測試用例編號 TC008
測試用例名稱 分辨率自適應測試
目的 查看本平臺能否在不同分辨率的屏幕上正常顯示和運行。
優先級 高
前置條件 數據庫服務正常，網絡連接正常。
測試流程 分別在分辨率為2880*1800、 2560*1600 1920*1080、 1440*900的屏
幕上運行本平臺各項功能。
表 6-9 (續表)
Table 6-9(Cont.)
測試用例編號 TC008
預期結果 平臺在各分辨率屏幕上皆可正常運行，各部分界面可正常顯示。
測試結果 在不同分辨率的設備上可正常運行，表格等界面彈性自適應，展示 正常。
結論 測試結果符合預期，平臺頁面在不同分辨率屏幕上表現出良好的布 局自適應，測試通過。
6.4本章小結
本章對系統進行測試環境、功能性測試用例和非功能性測試用例進行了詳細 的描述，通過對上述測試用例的設計和測試，同時根據需求分析認真比對了預期 結果和實際結果，發現了系統存在的一些問題和不足，并及時進行了改正，完善 了平臺的功能，提高了產品的質量。
7 總結與展望
本章對項目整體的結構和內容進行總結，對項目的立意、設計、實現等進行 全文回顧和總結，并結合平臺當前運行狀況和網約車的發展行情對項目未來的發 展予以展望。
7.1全文總結
本文以軟件工程生命周期的各個階段為骨架，結合項目的背景和意義，從不 同維度和角度對系統進行了詳細的說明分析。當前網約車還處在高速發展的階段， 無論是從國內角度還是從全球角度來看，網約車市場的發展還有很大的上升空間， 網約車的使用人數和使用頻次都還在快速提升，進而在該領域產生的車單數據和 安全問題數據量也與日俱增，一款高效、易用的數據處理平臺在網約車公司內部 管理中心必不可少。本項目整合數據信息管理和安全兩要素，結合人工智能算法， 提供數據操作和和安全處理相結合的服務體驗，旨在提高安全數據的使用效率， 切實幫助相關工作者簡化安全事件處理工作流程。在與用戶的多次溝通與親身體 驗后，筆者在文中結合現實情況對網約車安全信息管理平臺的需求進行了仔細分 析，對產品特色和用戶特點進行了認真的思考，從功能性需求和非公性需求不同 方面進行了詳細的闡述。
在平臺的構思設計過程中，結合實際需求特征，選定了前后端分離的開發模 式，使用 Vue 加 Echarts 的模式實現項目中大量的數據展示，使用 Spring Boot 和 mysql 進行后端邏輯和數據處理的實現。本文在相關理論、技術概述和需求分析之 后對項目進行了概要設計和詳細設計的闡述，將平臺主體分為綜合管理模塊、數 據展示模塊、車單信息操作模塊、安全規則定制模塊和安全判責模塊五部分，結 合功能模塊劃分圖、用例圖、平臺架構圖等對各個模塊進行總體設計闡述，結合 系統總體 E-R 圖對系統各模塊進行了數據庫表的設計和展示。在詳細設計部分使 用文字說明結合流程圖、時序圖、類圖和部分功能的實現圖對系統各部分的設計 和實現做了詳細的說明。最后依據項目需求對實現的系統應用進行了功能性測試 和非功能性測試，并對測試出現的問題進行了改正和完善。
縱觀整個項目來看，網約車安全信息管理平臺符合軟件工程設計理念，在功 能實現和系統性能上符合用戶的期待和需求，在實際運行過程中能有效的整合數 據資源，將算法技術、數據承載和安全事務操作流程結合起來，助力提高了用戶 的工作質量和效率。
7.2展望
目前國內網約車市場呈現一超多強的情況，滴滴出行引領，多款同類網約車 品牌發展迅猛。但在網約車安全問題處理上各個公司大多處于起步階段，各種處 理策略和輔助處理應效果用參差不齊，作為新興發展事務，網約車在安全問題和 網約車數據處理的路上還有很長的一段路程要走，本平臺是結合各項需求和目前 網約車產業實際情況，考慮當前可使用的技術范圍后進行設計和實現的，在未來 還有很大的完善必要和發展空間。
首先是隨著技術的發展和科技運用的提高，人工智能越來越普及，各種算法 真正被運用在實際工作和生活中，現有數據清洗識別部分在未來肯定會增加新的 功能，逐步由機器清洗結合人工清洗向機器清洗為主人工核實為輔的方向發展， 在進行判責操作時機器智能能給予更多的輔助和提示。在硬件方面手機和車載智 能配置發展日新月異，硬件的提升使得信息數據的來源更加廣闊和準確，使得數 據處理的效率和實時性有著顯著的提升，這對平臺未來在數據處理方面必然會有 新的要求。
其次是網約車作為新興事物，其相關的各項指標和法律法規都處于完善階段， 而業內對應的配套規章制度和考核標準都可能有很大的改變和調整，作為以數據 管理和安全操作為主題的平臺，如何在規則靈活調整的背景下抓住安全信息的關 鍵點，為用戶提供更有價值的信息和更高效的安全事務處理是本平臺未來發展的 又一探索方向。
參考文獻
[1]李小春."互聯網+"時代的出租車資源配置問題研究J].現代商貿工業,2019, 40(11):85-86.
[2]許明月，劉恒科.網約車背景下地方出租車市場法律監管的改革與完善J].廣東社會科學， 2016(5):249-256.
[3]董成惠.Analysis The Value of Network-car Class Sharing Economic% 網約車類共享經濟的 價值分析J].蘭州學刊，2017, 00(04):148-155.
[4]侯登華. The Supervision under Quartet Agreement Operating Mode of Internet Private Hire Vehicles% “四方協議”下網約車的運營模式及其監管路徑J].法學雜志，2016, 037(012):68-77.
[5]Contreras S D,Paz A. The effects of ride-hailing companies on the taxicab industry in Las Vegas,Nevada[J].Transportation Research Part A Policy & Practice, 2017.
[6]Henao A,Marshall W E . The impact of ride-hailing on vehicle miles traveled[J]. Transportation, 2018(5).
[7]孫雨萌，張煜婷.滴滴出行安全系統隱患與變革對策研究[J].中國集體經濟, 592(08):104-106.
[8]吳霽，韓雪.網約車服務機制中解決糾紛的應用對策研究一一以滴滴出行為例J].知識經 濟, 2019(24).
[9]Feng G,Kong G,Wang Z. We are on the Way: Analysis of On-Demand Ride-Hailing Systems[J]. Ssrn Electronic Journal, 2017.
[10]Uhlemann E.ITS Frequency Bands Are Being Debated [Connected Vehicles][J]. IEEE Vehicular Technology Magazine, 2016, 11(4):12-14.
[11]Flanagan B D. JavaScript: The Definitive Guide[M]. 2011.
[12]王子毅, 張春海. Design and implementation of a data visualization analysis component based on ECharts%基于ECharts的數據可視化分析組件設計實現[J].微型機與應用，2016, 035(014):46-48,51.
[13]鄭幸源，洪親，蔡堅勇,et al.基于AJAX異步傳輸技術與Echarts3技術的動態數據繪圖實 現[J].軟件導刊，2017(3):143-145.
[14]Suryotrisongko H ， Jayanto D P ， Tjahyanto A . Design and Development of Backend Application for Public Complaint Systems Using Microservice Spring Boot[J]. Procedia Computer Science， 2017， 124:736-743.
[15]Rahman M A ， Kapoor P ， Laganiere R ， et al. Deep People Detection: A Comparative Study of SSD and LSTM-decoder[C] .IEEE Computer Society， 2018.
[16]Andrew G. Howard， Menglong Zhu， Bo Chen， Dmitry Kalenichenko， Weijun Wang， Tobias Weyand， Marco Andreetto， Hartwig Adam. MobileNets: Efficient Convolutional Neural Networks for Mobile Vision Applications[C] . CVPR: USA， IEEE:2017.
[17]Chen Y ， Meng G ， Zhang Q ， et al. Reinforced Evolutionary Neural Architecture Search[J]. 2018.
[18]Davis A M. Software Requirements - Analysis and Specification[M]. 1990.
[19]Minea M ， Timnea R S ， Stan C E . Integrated Platform for Road Traffic Safety Data Collection and Information Management[C]. IEEE Computer Society， 2010.
[20]Zhu W ， Jia Y . The Research on Safety Management Information System of Railway Passenger
Based on Risk Management Theory[J]. Iop Conference, 2018, 108.
[21]Gao Y F, Ya-Wen X U, Law S O, et al. The Distinguishing System of Local Regulation about Car-hailing via Internet: Based on Functionalism[J]. Journal of Zhejiang Gongshang University, 2017.
[22]Wang, Tingting, Zhao, Lei. The Analysis of Competitive Strategy and Suggestions for Didi under the Background of the New Car-hailing Regulation[J]. Journal of Physics Conference,2017,910:012056.
[23]甄藝凱.Research on New Policy of Ride-hailing Regulations%網約車管制新政研究[J].中國 工業經濟, 2017, 000(008):81-99.
[24]張海藩，牟永敏.軟件工程導論(第6版)[M]. 2013.
[25]Yang Z , Zhou Q , Ma A G , et al. The design and implementation of smart grid high volume data management platform architecture[C] IEEE, 2014.
[26]Selic B V . The theory and practice of modern modeling language design for model-based software engineering[C]// Companionof International Conference on Aspect-oriented Software Development. ACM, 2011.
[27]孫曉夢.九江市氣象服務工作平臺設計與實現[D].北京交通大學,2018.
[28]Bercic B , George C . Identifying Personal Data Using Relational Database Design Principles[J]. International Journal of Law & Information Technology, 2009, 17(3):233-251.
[29]Demirezen Z . An information theory based representation of software systems and design[J]. 2012.
[30]Broeck J V D , Fadnes L T . Data Cleaning[M]// Epidemiology: Principles and Practical Guidelines. 2013.
[31]Mark Sandler, Andrew Howard, Menglong Zhu, Andrey Zhmoginov, Liang-Chieh Chen. MobileNetV2: Inverted Residuals and Linear Bottlenecks [C]. IEEE, 2018: 4510-4520.
[32]Chollet F . Xception: Deep Learning with Depthwise Separable Convolutions[C] Conference on Computer Vision and Pattern Recognition (CVPR) , IEEE, 2017.
[33]Naik K , Tripathy P . Software Testing and Quality Assurance || System Test Design[J]. 2008, 10.1002/9780470382844:321-354.
上一篇：基于Android的高校移動教務管理系統的 設計與實現
下一篇：油井鉆探信息管理系統設計與實現
相關標簽:
