熱門論文
最新論文
設備巡檢信息管理系統 設計與實現
發布時間：2023-07-07 16:38
目錄
摘要 I
ABSTRACT III
目 錄 V
第 1 章 緒論 1
1.1研究背景與意義 1
1.2國內外研究現狀 1
1.2.1國外研究現狀 1
1.2.2國內發展趨勢 2
1.2.3國內研究現狀 2
1.3論文研究內容及結構 4
第 2 章 相關技術 5
2.1Python 5
2.2HTML5 技術 5
2.3JavaScript 技術 6
2.4Bootstrap 前端框架 6
2.5Django 框架 7
2.6MySQL 數據庫技術 7
2.7.Nginx 技術 8
2.8 本章小結 8
第 3 章 系統可行性與需求分析 9
3.1系統需求主要問題分析 9
3.2系統可行性分析 10
3.3系統總體需求 11
3.4系統功能需求分析 13
3.4.1人員管理系統需求分析 14
3.4.2設備巡檢系統需求分析 15
3.4.3備件管理系統需求分析 16
3.4.4設備維護系統需求分析 17
3.4.5設備檔案/履歷系統需求分析 18
3.5系統流程分析 19
3.6系統非功能需求分析 20
3.7本章小結 22
第 4 章 巡檢信息管理系統設計與實現 23
4.1系統設計目標 23
4.2系統總體架構設計 24
4.3系統性能設計目標 25
4.4系統主要功能設計 27
4.4.1設備檔案模塊設計 27
4.4.2設備巡檢模塊設計 29
4.4.3設備報修保養模塊設計 30
4.4.4備品備件管理模塊設計 32
4.4.5系統管理模塊設計 34
4.5系統類圖設計 36
4.6系統數據庫設計 36
4.6.1邏輯結構設計 37
4.6.2物理結構設計 37
4.7系統安全性設計 47
4.8巡檢信息管理系統實現 49
4.8.1系統的開發環境 49
4.8.2系統框架的實現 50
4.8.3巡檢管理模塊實現 58
4.8.4設備報修管理模塊實現 62
4.8.5自動報修模塊實現 67
4.9本章小結 70
第 5 章 巡檢信息管理系統測試與運行分析 71
5.1測試環境與工具 71
5.1.1功能測試 71
5.1.2壓力測試 74
5.1.3兼容性和可用性測試 76
5.2系統運行測試結果分析 76
5.3本章小結 77
第 6 章 總結與展望 78
6.1總結 78
6.2展望 79
參考文獻 80
致 謝 84
攻讀碩士學位期間公開發表的論文 85
第 1 章 緒論
1.1研究背景與意義
廣西送變電超高壓輸電線路運行維護中心是南方電網的超高壓設施設備維護單 位，負責兩條超高壓輸電線路的運行維護和檢修。當前上級單位要求使用的生產信息 系統，在業務流程和下級單位信息對接上存在大量不合理的規劃，導致基層單位無法 實際使用上級所提供的表單規范，無法有計劃的執行巡視方案，沒有齊全的巡檢信息 電子歸檔體系。當前在巡檢過程中產生的巡檢記錄，只能通過紙質表單來填報和存放 歸檔，急需通過無線傳輸技術實現現場信息管理支持。巡檢員現場檢查設備出現故障 后，需要使用紙張表格填寫工作記錄和設備故障表，回到工作站后手動錄入電子表格， 不但造成了人工成本的二次浪費，臺賬資料的原始文件更不好存放，數據分散，歷史 資料沒有形成統一化管理，若遇突發重大事故需要緊急開展特殊巡視，資料在緊急情 況下的查詢非常不便，容易造成巡視計劃制定疏漏。［1-2］在當前經濟建設大力發展背景 下，新的變電站設備和線路在不斷增加，工作量猛增但人員數量卻維持不變，依靠通 過信息化管理，提高巡檢的效率變得尤為重要。在保證業務遵循標準流程規范的情況 下，不增加人手且有限時間內去檢修更多的設備并使其可靠的運行，是急需解決的一 大難題。因此需要根據南方電網有關管理標準規范要求，結合實際生產所需研發一套 信息管理系統，解決上述傳統巡檢中存在的問題。
本文所設計系統的開發和投入運行可以極大地提升工作效率，通過將業務流程進 行標準化應用，使巡檢管理從，計劃、執行、維修到完成確認形成一條完整的封閉回 路，實現巡檢工作流程智能化管理。在系統的使用中可以有效減少巡檢的疏漏，使用 手持終端及信息系統替代傳統的巡檢填報方式，在檢測維修和倉儲保養各部門之間實 現了信息實時流通，保障設備的長期安全、穩定、高效運行。
1.2國內外研究現狀
1.2.1國外研究現狀
國外在移動巡檢信息系統方面發展得比較早，各種方案已經成熟應用于人工巡查 檢修，直升機巡查檢修，無人機巡查等各個方面，形成了不少企業級解決方案的信息 管理系統。以下介紹幾個代表性外國公司的技術產品以及其解決方案。
Autodesk 公司提供了 ONsite 巡檢移動解決方案。該方案是一套基于 GIS 技術的 企業級應用方案，是一整套擁有完整應用軟件生態鏈的巡檢信息系統。［3］當巡檢人員 抵達設備所在的環境時，立即獲取巡檢位置信息，通過終端上傳信息后，信息數據流 可以在不同平臺和應用場景之間，實現業務流程無縫對接，采用聯網數據庫實現數據 信息的交換。
ESRI提供的ARCPad移動巡檢解決方案°ARCPad是ESRI公司開發的小型掌上巡檢 信息收集平臺軟件，可通過手持獨立 GPS 定位模塊和移動基站，移動終端等，為戶外 用戶提供信息服務，例如上報巡檢信息，巡檢坐標，設備數據等功能。［4］可以兼容不 同類型的移動終端包括CE平臺終端，Pocket PC平臺終端，安卓終端，I0S終端，在 不同終端下功能完整界面風格一致。支持 ESRI 影像顯示，可以與其他 ESRI 桌面級應 用產品實現衛星數據傳輸。戶外巡檢人員可以通過終端軟件接口，實時與工作站內私 有中心數據庫實現實時訪問，獲取業務信息。
MapInfo 公司提供的 MapMobile 巡檢解決方案。該方案在 Pocket PC 平臺上使用 了 MapX平臺互通技術。Windows下開發MapX平臺的軟件，可以在桌面，網頁，掌上 終端實現軟件一致部署無縫對接。［5］該移動解決方案比較特殊，采用無網方案，桌面 端為主數據庫，巡檢開始后下載進終端，巡檢過程中將信息和 GIS 信息記錄在終端內。 回到工作站的時候，把設備中的信息上傳至桌面端同步。
1.2.2國內發展趨勢
國內的電力行業近年來由于業務量增加，整體信息系統建設的步伐加快，國內的 電網系統企事業單位對于各個信息系統的投入和建設力度也在不斷增大，ERP、0A、電 力信息管理系統開始大量出現在各個系統單位中。［6］由于沒有明確的信息化規范建設 體系，在這些新建的信息系統運行的過程中由于硬件的升級和軟件的漏洞維護等諸多 問題，導致二次開發的軟件系統和硬件設備的數量日益增多；由于各個電網系統單位 的需求和業務不同，投運的信息管理系統也不同，形成了各種獨立的信息流，無法互 相溝通，仿佛一座座獨立的島嶼。［7］此外，由于缺乏對信息的準確記錄和規范運營， 導致計劃和預算等管理方式過于粗放，運營成本極高，同時又存在著大量的人手不足， 影響了正常的生產工作。
1.2.3國內研究現狀
國網公司依據“十二五”信息技術系統發展規程，決定建設龐大的智能電網工程， 也叫“186 工程”。［8］其中的“1”指的是將系統中的硬件網絡、數據流通、數據倉庫、 應用框架、門戶服務組成一個一體化的企業級生態平臺。其中的“8”指的是在功能上， 構建金融服務，銷售服務，生產系統，協同0A、勞資管理、物資調運、項目跟蹤八大 應用功能。其中的“6”指的是建設信息安全、標準模式、績效評定、行政管理、科研 進步、人才管理六個體系。
在 SG186 的要求下，國內較先進的電力巡檢系統是山東國網和中國移動聯合開發 的電力智慧巡檢系統。［9］該系統可以實現現場照片數據，現場 GIS 采集，電子簽名技 術，等相關移動掌上設備采集，通過運營商無線網絡能夠與云服務器內的業務應用層 交互和實現業務處理。實現延緩管理、巡檢定位、電子標簽等功能。系統的新穎之處 是二維碼掃描模塊，每個設備都貼有不同的二維碼，通過掃描二維碼，實現快速查詢 設備記錄，簽到監督等不同功能，作為巡檢人員監督的補充手段。
南寧供電局當前投運和使用的巡檢信息管理系統由單位完全自主開發。廣西電網 總集團公司在 2000年后，相繼開發并投運了全廣西電網總信息管理集成系統。［10］南寧 供電局在此舊系統的基礎上，通過廣西電網開放的接口系統，過渡到新的自主研發系 統上，新的系統主要負責管理南寧市管轄范圍內的輸電、變電、配電、調度生產業務。
硬件平臺中，主數據庫采用 IBM RS 6000小型機 2臺，工作流服務器采用戴爾服 務器 6臺，硬件設備由廣西電網公司博聯信通公司統一管理。員工移動終端為 10寸 的華為定制款防水安卓平板電腦。
軟件方面，采用 J2EE(Java 2 Enterprise Edition)平臺，EJB (Enterprise Java Beam)實現業務邏輯層。移動終端采用安卓系統和安卓應用。
在設備巡檢方面，移動終端可以實現 GPS 實時定位巡更考勤，現場拍照上傳，設 備表單現場填寫上傳，實時查詢設備缺陷等功能。其中最有亮點的功能是設備健康， 通過設備缺陷的數量和位置來評定設備的健康分數，一目了然設備的健康運行狀態。
廣供目前使用的配套巡檢系統是由廣州供電局與地方供電局協同開發的。［11］廣州 供電局負責華南最龐大的電力網絡系統，包含 200條以上電力線路， 8000多座電力鐵 塔。單位使用了無人機、機器人等多種不同的高科技業務方式來進行業務巡檢。
為了解決增長速度過快的業務需求。該單位將新開發的電力巡檢系統投入內部使 用。由于各單位內部信息化程度相當高。該系統與其他的信息管理系統可以進行無縫 接口對接。
巡檢信息管理系統在廣州供電局實施的過程中，一共經歷了三個主要的階段。第 一個階段主要實現了巡檢的記錄填寫以及巡檢報告生產業務系統的對接。第二個階段 擴展了 GIS信息處理功能。第三個階段實現了機器人和無人機巡檢數據采集。
軟件方面，服務器采用Microsoft Windows Server，數據庫采用Microsoft SQL Server。軟件框架系統采用MVC框架，Web服務端技術，能夠與地方單位的信息管理 系統進行信息對接。
巡檢終端是一個運行 WinCE 的掌上電腦終端，該移動終端搭載有衛星定位和基站 無線聯網模塊，可以通過聯網與云服務器進行實時的數據訪問。系統軟件層提供了詳 盡的設備信息隱患分析功能，并能接收來自手持終端的實時任務分發和信息提交。
1.3論文研究內容及結構
本文將結合高壓電線路巡視中的缺陷閉環管理問題，制定解決方案，研究與實現 一個管理追蹤缺陷生命周期的系統。該系統采用 Web 端架構，設計目標是提高跟蹤處 理缺陷的工作效率。
本文從巡檢信息管理系統的開發目的、國內外開發行業解決方案分析、系統開發 需求進行了總結。介紹了巡檢信息管理系統的設計思路并對系統開發完畢，之后進行 了系統測試，并根據測試結果進行解決和優化。本文主要章節內容如下：
第 1 章是緒論，論述巡檢信息系統的行業發展背景及開發創新點，分析現有行業 應用方案情況和開發設計的痛點，闡述了本文的研究內容和組織形式。
第 2 章介紹系統技術架構和開發工作所涉及的主要技術，包括 Html5 技術、 Javascrip技術、Bootstrap前端框架、Django框架、Nginx技術等。
第 3 章從系統建設目標與原則、應用功能、技術性能與安全等角度，對系統需求 進行分析。
第 4 章是系統設計與實現，首先介紹了系統的框架設計，對系統的主要業務功能 進行了分析與設計，根據業務功能和業務流程設計了數據庫的表結構，對各個需求功 能的頁面和業務邏輯進行了開發和實現。
第 5 章是系統測試，介紹了測試的環境，對通過壓力測試、硬件性能測試、兼容 性測試得出的結果進行了分析。
第 6 章是總結與展望，總結了撰寫該論文所做的全部工作，指出系統存在可以改 進的創新性方向，對以后學習思路提出展望。
第 2 章 相關技術
本章主要介紹系統建模和開發工作所涉及的主要技術，包括Html5技術、 Javascrip技術、Bootstrap前端框架、Django框架、Nginx技術等。以下是這些技 術的分析和介紹。
2.1Python
Python是一種解釋型語言，不需要進行編譯即可在服務器上進行直接運行，擁有 良好的跨平臺能力，該語言的編程方式可使用JAVA的面對對象，也可使用C的面向過 程，也可兩種混用，適用用于軟件原型快速迭代開發。[12]Python擁有非常全面及強大 的函數庫支持， 例如 Numpy 提供基礎計算， SciPy 提供了 高級計算、信號處理， Matplotlib提供了 Matlab類似的強大交互式繪圖，Pandas提供了各種數據分析和數 據庫操作函數，Statsmodels提供了專業的統計分析，Scikit-learn和TensorFlow 則提供了機器學習和深度學習的算法和模型，此外還有上千個三方類庫可使用，因此 Python在神經計算、金融計算、框架開發、系統模擬等實際場景下有著廣泛的應用。 [13]Python可以通過接口，操作由面向對象或面向過程等不同類型編程語言編寫的功能 庫。在實際的使用過程中，Python可以針對跨平臺穩定性高需求的情景，使用穩定性 極高的JAVA語言開發，通過Python接口直接訪問JAVA語言編寫好的功能庫，以便達 到跨平臺系統穩定性的要求。[14]
2.2HTML5 技術
Html5作為一個Html標記語言制定了 Web開發的一系列新標準。可以將普通的 Html文本語言作為APP開發語言使用。[15]由于它的很多新特性和特點，以及強大的開 發便利性，注定會成為下一代互聯網的核心技術。Html5重寫了大量的新功能，比如 標簽，提交，音樂視頻，可以敏捷開發出一套完整的輕量化APP軟件。泗Html5提供 了一系列網頁編程語言接口，比如定位，陀螺儀，快速訪問，實現在移動端平臺的IE 內核上運行APP，提升開發功能的可用性和開發的新思路。Html5技術可以把應用端實 現在瀏覽器上，同時瀏覽器作為應用廣泛的跨平臺通用軟件，可以實現各個平臺間的 互通。[17]
2.3JavaScript 技術
JavaScript 主要用于處理系統驗證頁面中的前端代碼。前端驗證指的是，用戶在 網頁中填寫信息的時候，頁面的代碼會自動探測到輸入的信息是否符合邏輯要求。[18]
JavaScript 的特點有：是一種解釋語言，運行到該句的時候，機器就專門翻譯這 句代碼，所以不需要像 C 語言那樣一次性把所有高級語言翻譯成機器碼才能執行，語 法結構和 JAVA 類似，可以使用面對對象編寫。[19]
JavaScript的適用場景有：瀏覽器網頁端開發，服務器后端語言Nodejs，移動端
APP開發React Native，跨平臺桌面應用程序如Electronjs°[20]
2.4Bootstrap 前端框架
Bootstrap 屬于一整套定義好的 UI 組件，主要解決的還是布局方面的問題，因此 更合適稱為前端UI框架。加Bootstrap的意義在于把寫好的Html和Css樣式進行了 封裝以供直接使用。例如后端程序員獨自完成一個包含前后端的 Web 系統項目，項目 必定包含大量的前端頁面，對于大部分專業從事后端程序員來說，對前端頁面的設計 并不能像專業前端程序員那樣將頁面做得美觀大方。Bootstrap可以解決此類難題， 無需專業的前端設計制作頁面，可以使用框架內的自帶套件來實現美觀大方的 UI。 Bootstrap 包含有很多樣式，例如排版，表單，縮略圖，面板。并且有豐富的插件， 導航、分頁、下拉菜單，模態框。[22]
Bootstrap 最大的優勢是可以建立動態自適應頁面，當設備的屏幕大小發生差異 時，會根據屏幕分辨率縮放元素排列順序，卻不影響內容的顯示和元素操作。讓頁面 不受設備分辨率的限制，能使得 APP 具有多平臺便利性優勢，可以在手機，平板，臺 式電腦上無縫使用，不需要根據不同設備的尺寸制作多個頁面去適配應用。[23]
2.5Django 框架
Django 是主流的 Web 系統框架之一，主要由 Python 代碼編寫，這個框架的起源 是一個2005年的新聞Web站點的開源項目。Django擁有MTV架構，也就是模型M、模 板T、視圖V。該框架因為其簡易和便利性，在近年來發展迅速，應用也越來越廣泛。
使用 Django 框架可以省去處理 Socket 的通信細節，把精力放在網站的業務邏輯 設計上，本身該框架提供構建一個網站所需要的基礎程序代碼，只需按照既定的流程 去編寫程序就可以輕松完成許多原本非常復雜的事情。[24]
Django在設計的時候遵守了模塊化概念，將數據庫操作做了抽象化，在網站的設 計過程中不需要使用SQL查詢語言，只需使用ORM,也就是使用Python的對象操作方 法的方式去處理數據庫中的數據，日后如果需要更換數據庫的類型，例如MySQL換成 Orcale，并不需要修改多少代碼就可以輕松實現數據庫更換升級。泅
2.6MySQL 數據庫技術
Mysql 是關系型數據庫，支持高并發處理，優秀的跨平臺性使其可以與各種編程 語言結合使用。軟件體積小，開箱即用。由于集眾多優點于一身，該數據庫被大量使 用于各種私有云及各大網站上。
Mysql 的優點有： 功能豐富。數據庫中有不同功能的數據引擎可供選擇，每個引擎都有各自的特點， 適用不同業務需求。用戶可以通過當前的業務需求及技術架構選擇適合自己系統的數 據引擎。
強大的跨平臺性。該數據庫支持多種開發平臺。在這樣的情況下，任何一個平臺 內編寫好的代碼都可以進行跨平臺部署，直接在不同操作系統的云端服務器運行。[26]
強大的運行速度。該數據庫最顯著的特征是超高的運行速度。采用了索引壓縮技 術，可以實現極速響應。SQL等數據庫查詢語言可以實現自定義編程，構建符合需求 的語言類庫，使系統運行更加高效。[27]
支持面對對象。編程方式可以使用類似C語言的過程性語言或者Java的面向對象 語言的方式進行編寫。也可混合兩種語言的風格進行支持。[28]
支持超大容量存儲及分布式存儲。作為企業級應用場景，通常一個數據庫可以支
持 60TB 以上的容量，可以輕松完成上千萬條記錄的大數據查詢和檢索。[29]
2.7.Nginx 技術
Nginx 是一個頁面級的網頁服務器，同時支持動態語言。專為高并發負載做了強 大的優化，能夠經受住上萬個并發壓力°[30]Nginx作為高性能頁面服務器和反向代理 服務器，最大優勢是不占用硬件資源，達到同樣負載性能的前提下，使用的硬件資源 只有其他同類產品的一半。[31]服務支持熱部署，啟動快，可以在不需要關閉服務器和 重啟應用模塊的情況下，對上線運行中的應用功能版本進行快速更新和部署。
2.8 本章小結
一個完整的網頁應用包含有服務器通信，業務數據處理，頁面生成展示交互三個 模塊，那么服務器通信用Nginx，業務數據處理用Python Django，頁面生成展示交互 用 H5+Bootstrap 技術，這就是巡檢信息管理系統設計的技術完整架構。
本章對巡檢信息管理系統所選型的主要開發技術、選型原因進行了介紹。論述了 每個技術在系統中的優勢和特性并進行了技術選型總結。
第 3 章 系統可行性與需求分析
本章對巡檢信息管理系統的可行性、總體需求、業務功能進行了探討和介紹。對 巡檢信息管理的主要問題提出需求和解決思路，然后對系統的可行性和總體需求進行 分析，之后對各個功能模塊的需求進行了分析，總結了系統業務需要的整體流程，最 后分析了非功能需求。
3.1系統需求主要問題分析
1、 巡檢單位無法直接使用外單位系統進行信息管理，需要解決與這些單位的獨立 系統進行設備缺陷數據接口對接的問題。
巡檢單位在電網改革之前屬于電力線路搶修單位，2014 年后由于并入中國南方電 網成為下屬子公司，開始接管關鍵高壓輸電線路運行維護，線路的原管轄段有多個地 方性質供電局，這些供電局使用的系統都是來自早期廣西電網統籌開發、后期自研、 南網新試點等信息項目的獨立系統，互不相通。不同單位的缺陷信息提交需要不同格 式的電子表格導入該單位的生產系統，而這些系統分別處于獨立的 VPN(Virtual Private Network)內網中，登錄內網需要不同的加密狗，導致信息接口無法直接對接。
解決方法：開發的信息系統采用 MySQL 數據庫，對于要交付該單位的電子表格提 前編輯好提交表格的格式，然后使用 MySQL for Excel 插件，［32］從數據庫中提取出需 要的信息，用于直接交付表格，也可通過編寫好的前端頁面功能模塊，使用 JavaScript 技術實現前端頁面中直接讀取和導出 Excel 文件［33］。
2、 本文所設計的巡檢信息系統需要側重實際業務需求，無法模仿外單位系統以及 現有的商業巡檢系統業務邏輯進行開發，需要解決業務邏輯側重點的問題。
各供電局單位的生產系統業務側重點更多的是政績宣傳和領導績效考核，其中有 部分業務邏輯不符合實際情況，導致這些系統不能務實生產，例如每年要求缺陷消除 完成率必須達到 100%，24 小時內消除缺陷的及時率必須達到 100%。這些規定直接導 致了生產系統失去了缺陷跟蹤的功能，最終導致所有的缺陷依舊只能記錄在工作人員 的電子表格中，當月要去消除缺陷的時候，才在消除前 24 小時內提交為發現缺陷。［34］
而現在的商業級別巡檢系統雖有缺陷記錄的功能，但是無法實現跟蹤變化的缺陷， 商業系統的業務邏輯強調在人員到位的監督考勤和人事管理上，實際交付的對象是人 力資源管理層。
解決方法：數據庫的設計上要以缺陷跟蹤為主，能夠體現出缺陷的變化，每次檢 查設備都會有檢查記錄和缺陷變化的記錄體現，從發現到協調、處理、消缺檢查形成 一個完整的閉環過程，做到每個環節都有負責人可查。
3、需要解決商業巡檢系統中某些華而不實的系統功能，并不適合實際業務中使用 的問題。
GPS實時定位和考勤管理功能并不是剛需,GPS信息是可以通過破解的終端或者后 臺數據庫偽造，然而該考勤系統卻存在于大多數MIS電力管理系統中成了標配，上線 后被多家單位棄之不用。在電力巡檢的規程中有詳細描述，對于巡視的標準考勤方法 是由上級單位給出當月的巡視標記，例如某個中文漢字，然后到達設備點后直接將標 記寫于指定設備位置拍照記錄。這樣的考勤方式一直沿用至今，也有利于上級巡視組 檢查，無法用 GPS 考勤取代。[35]
移動終端拍照和視頻上傳功能雖說是現在巡檢信息系統的亮點，但不契合實際， 正常巡視需要配有20-200mm焦距的高倍率鏡頭單反相機來拍攝遠在高處的細小的設 備零件故障，或者懸掛在鐵塔上的鳥巢、風箏等異物，手機、平板等移動終端的像素 和遠距離拍攝能力遠遠達不到電力巡檢指導文件的規范要求。
顯示設備零件資料功能，這也是各供電局MIS系統維護最頭疼的東西，起初想法 是可以快速查詢到設備的資料，選擇合適的零件去更換，實際上這些資料只有在維修 設備前才會用到，并且錄入復雜，很多東西要大量時間計算，花費工時還見不到效果， 等到了維修設備前，還是要去找設備圖紙確認設備零件的型號，MIS系統中的設備資 料功能形同虛設。[36]
以上這些功能，不僅對核心業務沒有起到實際的作用，還容易造成各種連帶性的 系統漏洞，導致系統崩潰。
解決方法：降低軟件的復雜度，去除多余的功能和模塊，專注解決生產中的實際 問題。
3.2系統可行性分析
通過可行性分析，我們可以知道這套系統是否能夠在合理的技術條件下進行開發， 開發經費是否能夠完成系統的全部功能實現。以及系統投入生產運行后的資金投入和 人力成本節約情況、運行維護情況等是否符合系統能夠持續運行下去的各種必要條件。
1、經濟可行性分析
系統投入運行后，并不需要購買昂貴的移動設備，辦公電腦也不需要進行硬件升 級，使用的云服務器價格低廉但性能穩定，且安全保障符合要求。在巡檢過程中通過 使用該系統的巡檢功能，可以省去查閱缺陷表格，填報紙質文檔等繁雜操作，只需在 手持設備上勾選和填寫即可完成所有巡檢任務。極大縮短了巡檢時檢查設備和填寫的 時間，節約了人力成本，讓巡檢工作的開展更高效。在維修和庫存管理方面應用該系 統后可以同樣極大縮短人工成本，提高管理效率。
2、 技術可行性研究
采用成熟的互聯網行業 Web 開發技術，使用免費成熟的輕量化敏捷開源軟件 Django框架和MTV架構方案，使用Html5技術、Javascrip技術、Bootstrap前端框 架完成前端和移動采集端的信息解決方案。后端使用 Django 框架開發業務邏輯，服務 器采用可彈性配置性能的阿里云服務器 ，服務端軟件部署采用 Nginx 。從技術的成 熟性，互聯網行業對于技術架構的使用案例上分析，這套技術架構對于巡檢信息系統 完全符合短周期內完成快速開發出原型系統的要求。
3、 后期運行維護費用可行性分析
外單位的系統開發周期長，開發平臺技術復雜度高，采用昂貴的甲骨文商業數據 庫，移動設備采購昂貴的定制防水掌上電腦，后期運維使用的服務器硬件費用昂貴。 仔細分析后得出高費用需求的原因，主要是行政上的需要，一部分的需求是示范性信 息工程，另一部分的需求是績效考核，所以單位可以使用較高的規格和經費去開發系 統。當前巡檢單位從事該業務剛起步，若直接申請到高額的開發經費，軟件開發過程 中必然會有更多的高層提出管理上的功能需求，會將務實的生產需求轉變為半行政目 的的人事績效考核系統，偏離系統設計的初衷——服務于生產。
該系統低成本快速開發、輕量化開發的問題。巡檢單位對這套信息系統研發保持 支持的態度，通過該系統可以規范管理制度和管理方法，規范原始數據的收集，本文 所設計的系統操作簡單，易于上手，工作人員可以在非常短的時間內就可以學會熟悉 操作該系統。只要單位能夠積極支持和配合開發，并針對新開發的系統完善規章制度， 使系統能發揮作用，對系統的運營將是極大的支持。
通過以上的內容得出結論，本文所設計的系統開發的思路清晰，各種可行性上均 符合開發要求。
3.3系統總體需求
本文所設計的系統在功能上連通整個缺陷的生命周期，圍繞一個缺陷的發現，跟 蹤，處理，審核，歸檔，完成一個完整的缺陷從發現到消除閉環，保證準確的追蹤和 確定缺陷的存在，制定合理的消缺方案，最終以最完整的資料記錄歸檔該缺陷的發現 到消除整個過程的細節資料。
目前缺陷信息管理在各個單位并不普及，很多單位還在使用紙質表格統計，整個
信息的記錄過程復雜，紙質負責記錄的臺賬幾經易手，同一個缺陷多個人到過現場導 致描述不一致，最后無法確定這個缺陷是誰跟蹤的以及是不是同一個缺陷。使用該系 統可以根據登錄人員的記錄信息，明確每次跟蹤負責人，以及詳細的每次跟蹤的照片， 避免了人為錯誤和跟蹤失誤導致的責任錯誤。減少管理上的壓力和失誤。［37］系統功能 結構圖如圖 3-1 所示。
該模塊包含的內容有：
人員管理系統：人員ID密碼管理，人員訪問審核權限管理， 設備巡檢系統：確認巡視方案，確認巡視時間，設備巡檢單。 設備維護系統：設備報修，設備保養。 備件管理系統：備件領用，備件入庫，備件庫存，備件臺賬。 設備檔案系統：設備履歷管理，設備信息管理。
圖 3-1 系統功能結構圖
Figure 3-1 System function structure diagram
3.4系統功能需求分析
系統頂級用例： 該系統主要包含的系統模塊有人員管理系統、設備巡檢系統、設備維護系統、備 件管理系統、設備檔案系統、基礎信息管理系統。頂級系統用例圖如圖 3-2 所示。
3.4.1人員管理系統需求分析
由系統管理員確定登錄系統人員ID密碼，姓名，職責，信息系統訪問權限，以便 后續對于缺陷流程中的審核處理有明確的人員登錄記錄和規范填報信息，人員管理系 統用例圖如圖 3-3 所示 。主要功能有：
1：人員ID密碼管理：設置人員的登錄ID和登錄密碼
2：人員訪問審核權限管理：設置或撤銷該ID的角色權限
圖 3-3 人員管理系統用例圖
Figure 3-3 Personnel management system use case diagram
系統管理員可通過該模塊提供的功能直接修改用戶的ID,密碼，訪問權限，角色 等信息。
缺陷管理系統涉及到多個業務流程，每個角色只允許訪問特定的模塊，表3-1為 角色和權限表，如果業務流程中符合該角色的業務范圍，系統管理員可以直接通過該 模塊設置賬戶對應的角色權限。
表 3-1 職能表
Table 3-1 Department function table
角色 職能
巡檢員 填寫提交、更新缺陷數據、安排巡檢計劃
保養員 填寫提交、更新保養數據
庫存管理員 填寫提交入庫備件信息，出入庫信息更新，備件狀態更新
維修人員 填寫提交、更新設備及備件維修信息。
3.4.2設備巡檢系統需求分析
每次出任務前，需要給當前巡視組員制定好巡視的路線，提供需要檢查的設備信 息，指定巡檢人姓名以及巡視路線位置。并給巡視人員生成一份巡視線路表，表內有 巡視路線計劃，以及路線內所有設備的缺陷情況，設備巡檢系統用例圖如圖 3-4 所示 。 主要功能有：
確認巡視時間計劃：設置該任務需要參與的人員姓名 設備巡檢方案：設置巡視需要經過的設備編號 設備巡檢單：查詢并得出信息表，顯示該巡視任務內所有設備的缺陷情況。 巡視人員到達指定設備位置后，對設備檢查，對缺陷存在的狀況進行更新。是否 隱患程度變高影響設備風險，是否有新增隱患，然后填寫進系統后，繼續去下一個設 備檢查。設備巡檢單主要功能有：
新增缺陷填報：若該缺陷是未曾見過的新缺陷。則直接填報成新增缺陷。 舊缺陷填報更新：若該缺陷是舊的缺陷，不管缺陷是否變嚴重，把目前的缺陷情況更 新到舊的缺陷信息上，形成新的記錄，同時舊的記錄也能作為歷史看到。
3.4.3備件管理系統需求分析
庫管人員負責備件的出入庫和統計備件數量，備件管理系統用例圖如圖3-5所示。
主要功能有：
備件領用：設備維修人員在系統中登記后，從備件庫中領取備件去維修更換設備 部件，庫管員經手交接；系統記錄的設備到達保養期后，系統推送提醒并由設備保養 人員領取設備進行保養，庫管員經手交接。
備件入庫：庫管人員登記設備進入指定倉庫，并登記設備信息，數量，單位。
備件庫存：定期清點設備，若有數量不符或丟失，則更新庫存信息。
備件臺賬：登記備件的名稱、規格和廠家，以及備注詳細內容。
圖 3-5 備件管理系統用例圖
Figure 3-5 Spare parts management system system use case diagram
3.4.4設備維護系統需求分析
該系統主要負責設備相關的報修申請和設備保養，設備維護系統用例圖如圖 3-6 所示。主要功能有：
1.設備報修：巡檢員發現設備有緊急缺陷需要報修的時候，通過該系統填寫報修 申請，并拍攝照片，或者上傳文件大小在 20M 以內的故障視頻并簡述故障原因，便于 維修人員快速定位問題，維修員從倉庫領取備件后到現場進行維修，維修后現場由巡 檢員驗收。
2.設備保養：保養人員根據設備規范，制定所有設備的保養計劃，若計劃到期， 則系統推送提醒去倉庫領取設備進行保養，保養結束后更新保養信息并上傳照片，若 保養出現設備異常，則填寫設備報修，呼叫維修員進行維修，維修好后交付保養員，
保養員驗收備件，完成保養維修閉環。
3.4.5設備檔案/履歷系統需求分析
巡檢員在巡檢設備時，可以通過該檔案核對和檢查設備的健康狀況、缺陷的數量， 通過核對和跟蹤缺陷的情況，確定是否發展為重大缺陷，若是重大缺陷則提交維修申 請，并顯示上次的巡檢的時間記錄和人員記錄，以及該設備的維修保養記錄，設備檔 案/履歷系統用例圖如圖 3-7所示 。主要功能有：
1.設備信息檔案：登記和展示設備的名稱，廠家，所在地，巡檢間隔時間。
2.設備履歷記錄：展示設備的巡檢記錄，保養記錄，維修記錄。
3.5 系統流程分析
設備缺陷閉環
巡檢人員根據設備檔案制定巡檢設備和巡檢時間，巡檢過程中使用設備檔案模塊 查詢設備的狀態，核對設備的缺陷情況。若檢查發現設備缺陷情況發展至重大缺陷， 則通過維護系統申請設備維修。維修員的終端收到推送提醒后，前往倉庫領取所需的 換件，然后抵達現場維修。維修好后，巡檢人員驗收，完成消缺閉環。
庫存維護管理和保養閉環
庫存管理員對入庫的設備進行入庫登記和統計，定時清點庫存。保養人員根據設 備的保養時間自動提醒推送，從庫存領取需要保養的備件進行保養。如果保養中途發 現設備損壞或者異常，則通過設備維護提交維修申請。維修人員接收設備后進行維修， 修好后返還保養人員，完成保養閉環。
設備缺陷閉環和庫存維護管理保養閉環構成了整個完整的業務體系，完整的業務 流程圖如圖 3-8 所示。
圖 3-8 業務流程圖
Figure 3-8 Business flowchart
3.6系統非功能需求分析
在當前的巡檢業務中，由于對設備的維護信息涉及供電末端生產設備安全，巡檢 信息的準確及時，巡檢系統安全性，系統硬件可維護性等十分重要，任何一方面出現 問題，都會造成重大的經濟損失，巡檢信息管理系統的非功能需求如下：
1.實用性。對缺陷進行完善的跟蹤，以及便捷的歷史情況查詢，以便隨時知道設 備的健康狀況。
2.可擴展性。系統通過Djang。框架應用層內多個APP來實現不同的功能，使得 組件可以靈活地在框架中應用，若之后需要開發新的功能，可以在不影響現有應用的 情況下，通過開發新的應用，直接在生產系統中添加為新的功能，便于新應用的快速 部署。
3.易用性。在系統的各項功能界面能夠簡化和突出元素核心，減少無關的信息， 方便用戶辦理流程；系統 Web 端界面干凈整潔，在不同尺寸的移動端上提供能夠自動 適配設備分辨率的 UI 界面，能夠讓用戶一目了然各種業務的辦理流程，系統功能設計 扁平化，確保用戶使用的功能可以精準定位到對應需要解決的問題上。
4.可靠性。因為系統直接涉及生產，要求系統能充分考慮各種異常情況，進行有 效的突發處理，避免系統在故障時導致生產癱瘓。要求系統必須能 24 小時不間斷穩定 運行，以及快速排障，系統癱瘓時，能自動切換備用服務器。
5.穩健性。系統本身能在本地和云端系統快速部署穩定運行，其次在不同桌面瀏 覽器上有良好的兼容性，能夠適配不同品牌終端的系統內核瀏覽器。
6.安全性需求。系統需要有對外部破解和非法的防御能力。
Django 框架中有豐富的安全性工具技術，其中包括
XSS （跨站點腳本）保護-默認情況下，Djang。模板系統會對變量進行轉義，除 非它們明確標記為安全變量。[38]
CSRF（跨站點請求偽造）保護-用于驗證POST請求是否由你自己的站點內發送。 [39]
SQL注入保護- Django使用內置的ORM,因此不存在SQL注入的風險。
Clickjacking Pro tec tion- Djang。可以檢測到未經授權的內容請求。
Safe Password Hash - Django 默認使用 PBKDF2,另一個選項是 Bcrypt。兩者都 可以靈活使用Rainbow Tables,兩者都有相當長的計算時間來防止輕松的暴力。
以上是 Django 提供的開箱即用的安全保護措施。此外為了防止暴力破解對系統認 證的破壞，還需要限制防火墻對數據庫的訪問，在服務器系統上及時更新最新的安全 補丁。
7.可快速部署需求。 系統開發在本地完成，開發完成之后需要部署到云服務器上，便于更多用戶訪問， 其中在本地開發過程中使用的是微軟操作系統，而云服務采用的是 linux 系統。為了 確保程序在不同平臺的性能和穩定性，需要該系統的代碼具有良好的跨平臺移植性。 通過使用跨平臺敏捷開發語言 Python 完成開發，以及遠程數據庫連接可以實現系統平 臺快速部署。
3.7本章小結
本章論述了巡檢信息系統中各個業務流程和功能需求分析，并對非功能性需求進 行了整理，對于各種可行性分析也進行了深入的探討，為下一步系統的架構設計和系 統實現奠定基礎。
第 4 章 巡檢信息管理系統設計與實現
4.1系統設計目標
輸電線路設備巡檢管理系統 Web 端主要采用 H5、Bootstrap 技術，結合 Django 框架，可以實現桌面和手機端瀏覽器無縫切換頁面布局。本文所設計的系統遵循上級 電網管理制度和流程，借鑒優秀的同類產品，開發出一個適合基層使用的巡檢信息管 理系統。本文系統的設計目標有：
1.多平臺性
（1） 桌面端：系統采用流行的Python語言進行開發，其特點是不需要編譯，源 代碼可以在服務器端直接解釋運行。巡檢信息管理系統使用目前互聯網行業應用廣泛 的輕量化敏捷WEB應用開發框架。得益于成熟的WEB框架技術，用戶不需要額外的硬 件或者軟件，就可以通過普通的辦公電腦自帶的WEB瀏覽工具直接訪問系統平臺。
（2） 移動端：通過前端框架技術的自適應功能，讓系統可以在不同的移動設備平 臺上穩定運行，采用了 H5技術、Bootstrap技術與Django跨平臺Web應用的框架， 可以自適應各種移動終端的瀏覽器。
2.可擴展性
隨著業務的增加，系統需要在原有的基礎上新增應用，系統內部框架的低耦合性 優勢，可以很便捷地在原有技術框架上開發全新功能的應用，而且可以在不影響原有 的系統功能的情況下，直接將新應用部署到投入運行中的系統。
3.穩定性
在系統的平臺穩定性上，使用 Nginx 服務進行靜態頁面和視頻圖片的緩存代理服 務，服務器啟動uWSGI容器，通過負載均衡模式，使得系統在極限訪問量下，可以穩 定的對外提供訪問和業務處理服務，使得各項應用模塊的功能不因高并發的服務器壓 力受到影響。同時Django框架內靜態層也可進行一部分靜態資源的緩存，提高系統的 運行速度和執行效率。[40]
4.可維護性
Django框架內擁有完整的日志模塊系統，通過合理地設置可以實現完整的監控服 務。此外，可以使用其他的監控平臺與該框架的日志系統進行接口對接，提高系統的 維護便捷性。當系統出現緊急故障情況時，可以及時通過手機和短信通知管理運維人 員，進行故障分析和技術維護。[41]
4.2系統總體架構設計
隨著互聯網和智能移動設備普及，無紙化作業辦公成為信息化管理的趨勢。通過 科學設計巡檢管理系統，加快各部門之間的業務辦理流程，減少了巡檢的工作量，提 高了巡檢效率，使得巡檢質量更高。并且巡檢人員可以根據信息管理系統中的統計信 息進行分析，安排更有效率的巡檢路線和巡檢流程。有了巡檢缺陷管理系統以后所有 的設備維修，設備檢查，出入庫都可以通過終端或者桌面端進行快速辦理流程。巡檢 信息管理系統架構圖如圖 4-1 所示：
圖 4-1 巡檢信息管理系統架構圖
Figure 4-1 Architecture diagram of inspection information management system
通過分析以上的系統內部結構圖，得知該系統的設計模式為標準的MVC模式。MVC 指的是模型層，視圖層和邏輯控制層，Django仿照了標準的MVC模式，便是MTV設 計模式。
Model：數據的正常存儲。負責存放和處理相關的業務數據。提供增刪改查等基本 操作。
Template：模板層。用于存放靜態的html頁面。也負責用于處理頁面的顯示效果。
View： 業務邏輯層， 處理具體的業務邏輯， 它的作用是連通 Model 層和
Template 。
以上三層的關系如圖4-2所示。
圖 4-2 Django 框架下的 MTV 設計模式
Figure 4-2 MTV design pattern under Django framework
用戶通過瀏覽器向服務器發送Request,通過Nginx和uWSGI轉發到Django框架 的具體應用中。其中Nginx服務器擁有靜態資源的處理能力，例如圖片、視頻、css 頁面和網頁緩存；而對于動態響應的請求，例如表單提交，頁面渲染則轉發給 uWSGI 服務器，uWSGI通過網關協議將請求發送給Django框架中的不同應用，應用針對請求 作出相應連接數據庫增刪改查操作，原路返回數據至前端頁面，最終實現用戶請求。 [42]
4.3系統性能設計目標
該系統在投運后需要 24 小時運行，并且保證系統的運行穩定性。因此，從系統的 性能優化、穩定性和安全性，這三個方面考慮，需要達到的各項指標有：
在系統性能優化方面，需合理地使用緩存技術達到應有的性能指標。通過Nginx 服務器和Djang。框架中的Static層，對一些常用但是不會經常變動的頁面數據、網 頁渲染數據和圖片視頻資源進行靜態緩存存儲，減少了對數據庫和服務器內應用的訪 問壓力，從而提升網站性能。通過以上優化，在用戶通過瀏覽器提交請求后，系統內 的應用能快速做出響應，響應時間應該限制在 3 秒內完成。
在穩定性方面，客戶端與系統應用的交互中需要擁有穩定且高并發的能力。Nginx 采用多進程、異步非阻塞方式，通過反向代理后，經過技術性優化，系統的峰值需要 能保持在 500 左右的并發，滿足大量員工同時使用的過程中提交大量的數據不會崩 潰。
在系統運維方面，Nginx服務器提供負載均衡能力，系統在運行中，通過負載均 衡使用多個服務器組成群組，進行7X24小時服務。一旦系統故障，自動切換到可以 使用的服務器繼續運行應用，故障的服務器會自動下線并發送故障通知郵件，保障系 統的暢通運行。
對于安全性方面，分為系統運行安全、系統權限安全和系統技術安全。
系統運行安全：服務器需要有能夠防御 40Gbps 以上流量 DDos 攻擊的能力，以及 防御服務器操作系統漏洞攻擊的能力。為此服務器需要使用租賃云服務器主機的方式， 云端自帶有強大的硬件防火墻和流量防火墻，可以有效阻擋來自網絡的黑客攻擊。在 系統的服務器上，采用版本最新補丁完善的 Linux 系統，可以實現不停機的情況下， 進行系統更新和漏洞修補，保障系統運行安全。
系統權限安全：需要對不同的角色設置不同的數據庫及功能模塊信息訪問權限。 必要時可以使用物理加密手段進行證書驗證訪問。
系統技術安全：在系統設計的過程中，需要使用系統框架中自帶的安全保護工具， 從技術上實現數據庫、瀏覽器頁面、用戶權限和會話安全的漏洞攻擊防范。
4.4系統主要功能設計
4.4.1 設備檔案模塊設計
I
廠
設備信息添加 設備信息確認
圖 4-3 設備檔案功能圖
Figure 4-3 Functional diagram of equipment file
這是本文所設計系統的設備檔案功能圖，如圖 4-3 所示。功能模塊分別為：設備 檔案添加，設備檔案確認。各個模塊的介紹如下：
設備信息添加模塊：巡檢員可以使用該功能為系統添加設備信息。通過開發相關 的插件可以實現批量導入設備信息。
設備信息確認模塊：巡檢員可以通過該功能查詢設備的信息與實際設備是否一致， 并進行信息確認。
例如需要對大量的設備信息進行導入操作。當設備信息檔案從上級單位發到巡檢 員手上之后，巡檢員通過 Web 管理端導入設備信息數據，最后系統返回數據，導入成 功的信息將會顯示在功能中的管理頁面上。該操作的時序圖如圖 4-4所示。
圖 4-4 批量導入設備信息時序圖
Figure 4-4 Sequence diagram of batch importing device information
4.4.2 設備巡檢模塊設計
巡檢管理槿塊
圖 4-5 巡檢管理功能圖
Figure 4-5 Functional diagram of inspection management
這是本文所設計系統的巡檢管理功能圖，如圖 4-5 所示。該巡檢管理模塊的功能 有：巡檢信息添加，設備信息查詢，巡檢方案添加，巡檢方案查詢。巡檢員可以通過 這些模塊制定巡檢方案，以及在巡檢過程中查詢對照設備的缺陷，并添加新的設備缺 陷信息至數據庫中。以下為巡檢管理功能的詳細介紹：
巡檢信息添加模塊：巡檢員可使用此功能添加巡檢記錄。對巡檢設備的情況進行 核對后提交設備的信息更新，如果該設備有缺陷或者故障，則填寫提交。
設備信息查詢模塊：巡檢員對需要核對的設備進行查詢該設備存在的缺陷，檢查 核對缺陷是否是真實存在的，或是否升級為故障。
巡檢方案添加模塊：巡檢員可以在巡檢開始前的準備階段，通過設備信息查詢得 出的結果去參考制定添加的巡檢方案。
巡檢方案查詢模塊：巡檢開始后，可以根據該模塊查詢得出需要巡檢的目標設備 和路線。
巡檢員攜帶智能終端抵達設備所在地以后，通過檢查設備，若設備正常，通過智 能終端的網頁瀏覽器提交無異常信息；若設備有缺陷，則提交缺陷信息至系統，巡檢 管理信息添加時序圖，如圖 4-6 所示。
圖 4-7 設備報修保養功能圖
Figure 4-7 Equipment repair and maintenance function diagram
設備報修保養功能圖，如圖 4-7所示。該模塊的功能有：報修信息添加，報修信 息查詢，保養信息添加，保養信息查詢
如下為功能介紹： 報修信息添加：巡檢員或保養員通過該功能提交報修信息，申請報修。 報修信息查詢：維修員通過查詢報修信息，從庫存領取更換備件后，抵達巡檢員 申請報修的設備地點，進行維修。
保養信息添加：保養員核對設備臺賬和設備信息后添加每個備件的保養周期，保 養狀態。從庫存領取備件后進行保養，保養結束后提交完成保養的信息。
保養信息查詢：查詢設備保養周期是否達到，查詢設備保養后是否入庫成功。
以保養員申請保養流程為例，保養員登錄系統模塊的Web端頁面后，在功能模塊
內提交保養申請，系統確認后提交成功。保養信息添加時序圖，如圖 4-8所示。
圖 4-8 保養信息添加時序圖
Figure 4-8 Timing chart for adding maintenance information
4.4.4 備品備件管理模塊設計
備品備件管理
槿塊
圖 4-9 備品備件管理模塊功能圖
Figure 4-9 Function diagram of spare parts management module
備品備件管理模塊功能，如圖 4-9 所示。該模塊的功能有：備件信息添加，備件 領用信息添加，備件入庫信息添加，備件庫存查詢。
以下是該模塊中每個功能的介紹： 備件信息添加：庫管員通過備件臺賬，在系統中添加備件的詳細信息。 備件領用信息添加：保養員領用備件進行保養時，或維修員來領用備件用于維修 時，通過該模塊添加領用信息。
備件入庫信息添加：有新的備件入庫，可以通過該模塊添加信息。 備件庫存查詢：用于查詢備件的庫存，以及用于設備盤點實際庫存是否與系統中 的數量一致時使用。
以備件入庫信息添加流程為例，庫管員先通過 Web 端查詢該型號備件的數量，系 統數據庫返回結果呈現在 Web 端頁面上，若已有該型號的備件，則更新備件的庫存數 量，若庫存中沒有該備件，則將該備件的信息和數量錄入系統，系統確認后返回結果 錄入成功。備件入庫信息添加時序圖，如圖 4-10 所示。
圖 4-10 備件入庫信息添加時序圖
Figure 4-10 Timing diagram for adding spare parts storage information
4.4.5 系統管理模塊設計
圖 4-11 人員管理模塊功能圖
Figure 4-11 Function diagram of personnel management module
人員管理模塊主要負責管理系統內登錄人員的ID、密碼，以及模塊訪問權限。人 員管理模塊功能圖，如圖 4-11 所示。該模塊有兩個功能：人員信息編輯和人員權限編 輯。
人員信息編輯：可以批量導入人員的ID、密碼和角色權限，可以對單個人員進行 ID、密碼和角色權限的修改。
人員權限編輯：設置不同權限能訪問的模塊。
例如需要創建新的用戶，并給用戶賦予權限，管理員通過前端頁面導入用戶信息， 系統接收信息后確認信息有效并返回結果，管理員在前端頁面給該用戶授權，系統確 認后返回結果最終呈現于前端頁面。用戶新建時序圖如圖，4-12 所示。
I系統宦理員I
□
□
□
D
0
□
0
8.更新站庫
9.返回授權信息 U
6.授權操作
7.更改權限
1 •導入用戶信息
5.返回結果
2.保存用戶
3•更新站庫
U 4.返酹果
親統管理
前臺篩頁 面
漏管理
圖 4-12 用戶新建時序圖
Figure 4-12 Sequence diagram of user creation
4.5系統類圖設計
對巡檢缺陷信息管理系統中的人員身份進行分類可知，分為系統管理員、庫管員、 巡檢員、維修員和保養員五種身份。管理員負責管理其他賬戶信息，以及賬戶的業務 流程權限授權。庫管員負責管理設備的領用入庫信息，巡檢員管理設備檔案和巡檢信 息，維修員和保養員則在設備報修保養模塊中提交自己的申請。系統類圖如圖 4-13 所示。
圖 4-13 系統類圖
Figure 4-13 The system class diagram
4.6系統數據庫設計
系統使用的是基于 ORM 數據模型方案，使用含有類和對象的代碼將系統中需要使 用的字段和數據建立模型。[43] 通過在框架中設置好需要連接的數據庫和驅動管理程 序，使用相應的命令將對象模型映射成數據庫內的數據表。[44] Django 框架內擁有完
善的數據庫操作接口 API,對數據庫的操作十分方便，并且數據存儲上與邏輯完全分 離，在設計業務邏輯代碼的時候，不需要考慮數據庫 JDBC 操作，只需交給模型類和數 據接口完成即可。[45]
4.6.1 邏輯結構設計
巡檢缺陷管理系統主要包括設備，備件，巡檢單，報修單，入庫單，領用單，保 養單等幾個實體。其中各個巡檢單與設備，入庫單、領用單、保養單與備件，都是多 對多的關系，報修單與設備是一對一的關系。根據巡檢信息管理系統的實際功能需求， 以及基礎數據庫關系設計原則，畫出系統實體 E-R 圖，如圖 4-14 所示。
圖 4-14 系統主要部分實體 E-R 圖
Figure 4-14 the main part of the entity E-R diagram
4.6.2 物理結構設計
系統數據庫 db_xxgl 中含有 17 張數據表它們分別是： 設備檔案表 EquipmentFile 設備巡檢單表 InspectionList 設備巡檢單-巡檢記錄表 InspectionList_Record 設備巡檢方案表 InspectionPlan
設備巡檢方案-預檢明細表 InspectionPlan_PreCheckDetails 巡檢時間計劃表 InspectionTimePlan
設備報修單表 RepairApplicationForm
設備保養單表 MaintenanceOrder
備件領用單表 SparePartsRequisition 備件領用單-設備維修表 SparePartsRequisition_Repair 備件領用單-設備維修-領用明細表 SparePartsRequisition_Repair_Details 備件領用單-設備保養表 SparePartsRequisition_Maintenance 備件領用單-設備保養-領用明細表
SparePartsRequisition_Maintenance_Details
備件入庫單表 SparePartsStorage 備件入庫單-入庫明細表 SparePartsStorage_Details 備件庫存表 SparePartsInventory
備件臺賬表 SparePartsInformation
(1)設備檔案表(EquipmentFile):用于保存設備的信息，以及最近巡檢的時 間，結構如表 4-1 所示。
表 4-1 EquipmentFile 的結構 Table 4-1 EquipmentFile structure
字段名稱 類型 長度 主鍵 外鍵 字段說明 備注
ID INT 10 否 否 自動編號
EquipmentID INT 10 是 否 設備編號 自動生成設備編號
PhotoUpload VARCHAR 300 否 否 設備圖片 圖片文件的上傳地址
EquipmentName VARCHAR 50 否 否 設備名稱
EquipmentStatus VARCHAR 50 否 是 設備狀態
EquipmentModel VARCHAR 50 否 否 規格型號
EquipmentType VARCHAR 50 否 是 設備類型
EquipmentLocation VARCHAR 300 否 是 安裝地點
PersonInCharge VARCHAR 50 否 是 負責人
ContactDetails VARCHAR 300 否 否 聯系方式
Manufacturer VARCHAR 300 否 是 生產廠家
Supplier VARCHAR 50 否 是 供應商
PurchaseTime DATE 3 否 否 購買時間
ActivationTime DATE 3 否 否 啟用時間
InspectionPlan VARCHAR 50 否 是 巡檢方案
InspectionsPerDay INT 10 否 否 一天規定巡檢次數
LastInspectionTime DATETIME 8 否 否 最近巡檢時間
(2)設備巡檢單表(InspectionList)：用于保存巡檢員本次巡檢中對設備的巡 檢數據，包括設備編號，設備狀態，巡檢結果，巡檢時間等，該表結構如表 4-2 所示。
表 4-2 InspectionList 的結構
Table 4-2 InspectionList structure
字段名稱 類型 長度 主鍵 外鍵 字段說明 備注
ID INT 10 是 否 自動編號
EquipmentID INT 10 否 是 設備編號 可掃碼
EquipmentName VARCHAR 50 否 否 設備名稱
EquipmentModel VARCHAR 50 否 否 規格型號
EquipmentType VARCHAR 50 否 否 設備類型
InspectionTime DATETIME 8 否 否 巡檢時間
InspectorPerson VARCHAR 50 否 是 巡檢人員
PatrolLocation VARCHAR 300 否 否 巡檢定位 移動端獲取位置
PhotoUpload VARCHAR 300 否 否 拍照上傳 圖片文件的上傳地址
InspectionPlanName VARCHAR 50 否 是 巡檢方案名稱
InspectionsPerDay INT 10 否 否 一天規定巡檢次數
InspectionResults VARCHAR 300 否 否 巡檢結果
EquipmentStatus VARCHAR 50 否 是 設備狀態
Summary VARCHAR 300 否 否 本次巡檢總結
(3)設備巡檢單-巡檢記錄表(InspectionList_Record)：用于記錄巡檢設備單 中設備的具體檢查項目，每個項目的巡檢方法和巡檢結果，該表結構如表 4-3 所示。
表 4-3 InspectionList_Record 的結構
Table 4-3 InspectionList_Record structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 否 否 自動編號
EquipmentID INT 10 是 否 設備編號
InspectionItems VARCHAR 50 否 否 巡檢項目
InspectionMethod VARCHAR 50 否 否 巡檢方法
InspectionResult VARCHAR 300 否 否 檢查結果
(4)設備巡檢方案表(InspectionPlan)：用于保存巡檢方案的具體內容，包括 巡檢的設備，巡檢內容和巡檢時間，該表結構如表 4-4 所示。
表 4-4 InspectionPlan 的結構
Table 4-4 InspectionPlan structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
PlanName VARCHAR 50 否 否 巡檢方案名稱
EquipmentType VARCHAR 50 否 是 設備類型
InspectionTimePlan VARCHAR 50 否 是 巡檢時間計劃
InspectionsPerDay INT 10 否 否 一天規定巡檢次數
InspectionContentPlan VARCHAR 300 否 否 巡檢內容計劃
(5)設備巡檢方案-預檢明細表(InspectionPlan_PreCheckDetails): 用于保存巡檢方案中詳細的巡檢項目和巡檢方法，該表結構如表4-5所示。
表 4-5 InspectionPlan_PreCheckDetails 的結構
Table 4-5 InspectionPlan_PreCheckDetails structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
InspectionItems VARCHAR 50 否 否 巡檢項目
InspectionMethod VARCHAR 50 否 否 檢查方法
(6)巡檢時間計劃表(InspectionTimePlan)：用于保存巡檢的計劃名和巡檢計 劃次數，該表結構如表 4-6 所示。
表 4-6 InspectionTimePlan 的結構
Table 4-6 InspectionTimePlan structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 否 否 自動編號
PlanName VARCHAR 50 是 否 巡檢時間計劃名稱
InspectionsPerDay INT 10 否 否 一天規定巡檢次數
(7)設備報修單表(RepairApplicationForm)：用于保存設備報修的設備信息 以及報修時間和故障信息，該表結構如表4-7所示。
表 4-7 RepairApplicationForm 的結構
Table 4-7 RepairApplicationForm structure
字段名稱 類型 長度 主鍵 外鍵 字段說明 備注
ID INT 10 是 否 自動編號
EquipmentID INT 10 否 否 設備編號 可掃碼
EquipmentName VARCHAR 50 否 否 設備名稱
EquipmentModel VARCHAR 50 否 否 規格型號
SubTime DATETIME 8 否 否 報修時間
DefectPhoto VARCHAR 300 否 否 故障拍照
DefectDescription VARCHAR 300 否 否 故障描述
(8)設備保養單表(MaintenanceOrder):用于保存備件的設備類型，備件的保 養信息，以及備件的保養記錄，該表結構如表 4-8 所示。
表 4-8 MaintenanceOrder 的結構
Table 4-8 MaintenanceOrder structure
字段名稱 類型 長度 主鍵 外鍵 字段說明 備注
ID INT 10 是 否 自動編號
EquipmentID INT 10 否 否 設備編號 可掃碼
PhotoUpload VARCHAR 300 否 否 設備圖片 圖片文件的上傳地址
EquipmentName VARCHAR 50 否 否 設備名稱
EquipmentModel VARCHAR 50 否 否 規格型號
EquipmentType VARCHAR 50 否 否 設備類型
PersonInCharge VARCHAR 50 否 否 保養負責人
MaintenanceLevel VARCHAR 50 否 是 保養等級
MaintenanceFrequency VARCHAR 50 否 是 保養頻次
DaysBetween INT 10 否 否 間隔天數
ThisMaintenanceTime DATETIME 8 否 否 本次保養時間
NextMaintenanceTime DATETIME 8 否 否 下次保養時間
ContentAndRequirements VARCHAR 300 否 否 保養內容及要求
MaintenanceResult VARCHAR 50 否 否 保養結果
EquipmentStatus VARCHAR 50 否 是 設備狀態
InformationRecord VARCHAR 300 否 否 保養信息記錄
ReplaceSpareParts VARCHAR 50 否 否 是否需要更換備品
備件？
AbnormalMaintenance VARCHAR 50 否 否 保養異常？
(9)備件領用單表(SparePartsRequisition):用于保存設備領用記錄和領用 人，該表結構如表 4-9 所示。
表 4-9 SparePartsRequisition 的結構
Table 4-9 SparePartsRequisition structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
Requisition date DATETIME 8 否 否 領用日期
ReceiverName VARCHAR 50 否 是 領用人
(10)備件領用單-設備維修表(SparePartsRequisition_Repair)：用于保存領 用目的是維修的工單信息，該表結構如表4-10所示。
表 4-10 SparePartsRequisition_Repair 的結構
Table 4-10 SparePartsRequisition_Repair structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
RepairOrder INT 10 否 是 維修工單
EquipmentID INT 10 否 否 設備編號
Description VARCHAR 300 否 否 故障描述
Depot VARCHAR 50 否 是 領用倉庫
(11)備件領用單-設備維修-領用明細表
(SparePartsRequisition_Repair_Details)：用于保存維修工單信息中詳細的領用 備件型號和規格數量，該表結構如表 4-11 所示。
表 4-11 SparePartsRequisition_Repair_Details 的結構
Table 4-11 SparePartsRequisition_Repair_Details structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
SparePartsName VARCHAR 50 否 是 備件名
EquipmentModel VARCHAR 50 否 是 規格型號
SparePartsID INT 10 否 否 備件編號
RequisitionQuantity INT 10 否 否 領用數量
Unit VARCHAR 50 否 否 單位
Reason VARCHAR 300 否 否 領用原因
(12)備件領用單-設備保養表(SparePartsRequisition_Maintenance)：用于 保存領用目的是保養為主的設備工單編號和倉庫位置，該表結構如表 4-12 所示。
表 4-12 SparePartsRequisition_Maintenance 的結構
Table 4-12 SparePartsRequisition_Maintenance structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
MaintenanceOrder INT 10 否 是 保養工單
EquipmentID INT 10 否 否 設備編號
Maintenance
level VARCHAR 50 否 否 保養等級
Depot VARCHAR 50 否 是 領用倉庫
13)備件領用單-設備保養-領用明細表
(SparePartsRequisition_Maintenance_Details)：用于保存保養領用工單中詳細的 設備明細規格數量等多條記錄，該表結構如表 4-13 所示。
表 4-13 parePartsRequisition_Maintenance_Details 的結構
Table 4-13 parePartsRequisition_Maintenance_Details structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
SparePartsName VARCHAR 50 否 是 備件名
EquipmentModel VARCHAR 50 否 是 規格型號
SparePartsID INT 10 否 否 備件編號
RequisitionQuantity INT 10 否 否 領用數量
Unit VARCHAR 50 否 否 單位
Reason VARCHAR 300 否 否 領用原因
(14)備件入庫單表(SparePartsStorage)：用于保存入庫表的編號和入庫位置, 該表結構如表 4-14 所示。
表 4-14 SparePartsStorage 的結構
Table 4-14 SparePartsStorage structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
Storage time DATETIME 8 否 否 入庫時間
Depot VARCHAR 50 否 是 入庫倉庫
ReceiverName VARCHAR 50 否 是 入庫人員
(15)備件入庫單-入庫明細表 (SparePartsStorage_Details )：用于保存入 庫表的詳細入庫備件規格條目和備件數量，該表結構如表 4-15 所示。
表 4-15 SparePartsStorage_Details 的結構
Table 4-15 SparePartsStorage_Details structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
SparePartsName VARCHAR 50 否 是 備件名
EquipmentModel VARCHAR 50 否 是 規格型號
SparePartsID INT 10 否 否 備件編號
RequisitionQuantity INT 10 否 否 入庫數量
Unit VARCHAR 50 否 否 單位
(16)備件庫存表(SparePartsInventory):用于保存備件的規格型號，所在 庫存的入庫和出庫量，該表結構如表 4-16 所示。
表 4-16 SparePartsInventory 的結構
Table 4-16 SparePartsInventory structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
Depot VARCHAR 50 否 是 倉庫名
SparePartsName VARCHAR 50 否 否 備件名
EquipmentModel VARCHAR 50 否 否 規格型號
SparePartsID INT 10 否 否 備件編號
Unit VARCHAR 50 否 否 單位
RequisitionQuantity INT 10 否 否 入庫量
OutQuantity INT 10 否 否 出庫量
(17)備件臺賬表(SparePartslnformation):用于保存備件的名稱和規格信 息，該表結構如表 4-17 所示。
表 4-17 SparePartsInformation 的結構
Table 4-17 SparePartsInformation structure
字段名稱 類型 長度 主鍵 外鍵 字段說明
ID INT 10 是 否 自動編號
SparePartsName VARCHAR 50 否 否 備件名
EquipmentModel VARCHAR 50 否 否 規格型號
Unit VARCHAR 50 否 否 單位
Manufacturer VARCHAR 300 否 否 生產廠家
Remarks VARCHAR 300 否 否 備注
4.7系統安全性設計
對于巡檢管理系統的安全性設計上，系統需要通過服務器驗證、身份驗證、用戶 文件、加密技術和數據庫安全等技術方面去實現系統的安全。
在服務器驗證上，為了防止假冒網站偽造頁面竊取用戶賬戶密碼，網站采用 HTTPS 傳輸協議。從頂級CA機構購買SSL證書，在Django安全模塊中設置所有圖片、視頻 資源文件采用HTTPS協議傳輸，若用戶未使用HTTPS協議訪問資源，則該資源會被安 全模塊進行重新定向至預先寫好的警告圖片和警告視頻，以警示用戶未使用安全協議。 [46]
在用戶身份驗證上，首先在CSRF （跨站點請求偽造保護）模塊中設置所有用戶在 非HTTPS傳輸模式下，所有COOKIES緩存失效，這樣通過非HTTPS訪問的用戶無法進 行正常登錄。其次，所有用戶必須進行登錄提交才能進入系統，通過Django框架中的 login裝飾器自定義一個類，所有需要用登錄后才能訪問的頁面對應的后臺View層都 繼承該類，以此確保訪問時必須是登錄狀態，否則跳出至登錄頁面。最后，采用雙因 子認證，用戶輸入賬戶密碼確認后，需要用戶綁定的手機接收短信驗證碼輔助驗證， 才可以登錄系統。
在用戶文件上，系統只允許上傳視頻、音頻和圖片三個類型的文件，前端頁面通 過JavaScript代碼限制上傳的文件類型大小和后綴，后端使用Django中的PIL庫進 行核對是否是符合規范的后綴名，若不符合規范則在后端自動刪除文件，以防止惡意 上傳腳本攻擊。所有上傳文件全部保存在一個權限設置為文件無法執行的目錄下。
在數據加密技術上，Django框架自帶的CSRF防御，前端HTML頁面的表單中添加 {%csrf_token%}。在項目運行后瀏覽器中查看源碼可以看到一串隱藏的驗證碼，里面 的 value 值用于驗證，這樣表單才能順利提交。如果表單中沒有該驗證碼，瀏覽器會 返回403報錯，提示CSRF驗證失敗，有效防止CSRF攻擊。確保表單（POST請求）從 你自己的站點發送。此外框架自帶優秀的加密算法模塊 pbkdf2_sha256 方式來存儲和 管理用的密碼。[47]
在數據庫安全上，在使用 Django 的 ORM 操作數據庫后，所有提交的信息通過底層 驅動轉義處理后去操作數據庫指針，可有效避免 SQL 注入攻擊的問題。
4.8巡檢信息管理系統實現
本部分內容主要介紹系統的開發環境，系統框架的實現以及各個模塊的實現。
4.8.1 系統的開發環境
本文所設計的系統的服務器端實現主要使用的技術有：
開發工具：業務代碼開發工具Pycharm；前端及前臺代碼開發工具WebStrom 開發語言：后端業務代碼：Python，前端業務代碼：html5,css,javascript 后臺框架：Django
前臺框架：BootStrap+CSS+HTML+JavaScript 其他詳細的開發環境如表5-1所示：
表 5-1 服務器端開發環境
Table 5-1 Server-side development environment
語言 Python、Javascript、HTML5
軟件環境 Python 3.8.7
數據庫 MySQL 5.1.60
PC 操作系統 Windows10
PC 硬件配置 處理器：AMD Ryzen Threadripper 2990WX 安裝內存（RAM） : 16.0GB 系統類型： 64 位操作系統
硬盤：希捷 500GB
Web 服務器 Nginx 1.12.2
在開發過程中使用微軟操作系統作為本地開發環境，通過Pycharm開發工具套件 將Django框架和MySQL數據庫整合，并通過豐富的三方庫增加各項應用功能，在完成 各項應用功能的開發后，部署到云服務器上。服務器的系統更換為更穩定的 Linux 系 統，在本地開發的時候使用的是簡單Web容器。部署到云服務器后使用uWSGI作為容
器，使用 Nginx 進行端口轉發，實現與 Django 內應用層的通信。云服務器端環境，如 表 5-2 所示：
表 5-2 云服務器端環境
Table 5-2 Cloud server environment
語言 Python、Javascript、HTML5
軟件環境 Python 3.8.7
數據庫 MySQL 5.1.60
云服務器操作系統 CentOS 8.2.2004
硬件 CPU/內存2核2GB
數據庫 1GB 網頁空間 50GB 峰值帶寬 15Mbps 每月高速流量 1000GB
Web 服務器 Nginx 1.12.2,uWSGI
4.8.2 系統框架的實現
本文所設計的系統使用Django的MTV模式框架開發。Django的MTV分別是：
M代表模型Model：負責處理對象和數據庫之間的關系。
T代表模板Template：負責頁面展示給用戶。
V代表視圖View：負責處理業務，用于調用模型層和模板層的文件。
除了以上三個應用層外，還有一個 URL 路由器。路由器可以把網頁端發過來的請 求分發給不同的應用。這樣拆分的好處是將三個應用層的工作量明確分工，一旦修改 一個應用層的內容，并不會影響到其他應用層的代碼。比如前端美工可以通過修改頁 面的 CSS 文件改變網頁的樣式，后端程序員可以隨意修改業務邏輯模型，并不會影響 到前端美工的界面修改工作，框架的系統文件如圖 5-1 所示。[48]
圖 5-1 框架目錄文件結構
Figure 5-1 Framework directory file structure
1、數據存取層（M）
M表示Model，也就是模型層，用于在系統中建立數據模型使用接口，可以與不同 類型的數據庫進行溝通及完成數據庫操作。例如創建一個模型時，ORM框架會使用現 有的數據模型結構操作數據庫創建一張對應的數據表。表中的每個字段屬性對應的是 模型中的對象屬性。
以下我們以巡檢信息管理模塊為例，各個模型部分代碼設計如下所示：
設備檔案模型
Class EquipmentFile（models.Model）:
EquipmentlD二models. CharField（u' 設備 ID' , max_length=50, unique二True） EquiName二models. CharField（u' 設備名稱',max_length=50）
Equipme nt Type二models. CharField（u' 設備類型',max_leng th=50） PersonlnCharge二models. CharField（u' 負責人',max_length=50） LastInspectionTime二models. DateField（u'最近巡檢時間'） InspectionPlan二models. ForeignKey （u' 巡檢方
案',on_delete二models. CASCADE）
設備巡檢模型
Class InspectionList（models.Model）:
EquipmentlD二models. CharField（u' 設備 ID' , max_length=50,unique二True）
InspectionResults二models. CharField（u' 巡檢結果',max_length=300）
EquipmentStatusChoice=（
（normal, u' 正常'）
（Fault,u'故障'）
（service, u'待檢修'）
（danger, u'隱患風險'）
）
EquipmentStatus二models. CharField（u' 設備狀
態',Choice二EquipmentStatusChoice）
InspectionTime二models. DateField（u'最近巡檢時間'）
InspectorPerson二models. CharField（u' 巡檢人',max_length=50）
巡檢方案模型
Class InspectionPlan（models.Model）:
PlanName二models. CharField（u' 巡檢方案名稱',max_length=50, unique二True）
EquipmentType=models. CharField（u' 設備類型',max_length=50）
InspectionTimePlan二models. CharField（u' 巡檢時間計劃',max_length=50）
InspectionsPerDay二models. SmallIntegerField（u' 一天規定巡檢次
數',max_length=50）
InspectionContentPlan=models. CharField（u' 巡檢內容計
劃',max_l ength=300）
2、模板層（T）
Template 模板，一個單獨的模板就是一個 Html 文件，開發過程中將寫好的 HTML 文件中嵌入 Django 特定的模板語言，在視圖函數里將變量帶入到模板對象中，使用返 回函數將結果返回給對象以此實現響應的請求。
Bootstrap 前端框架自適應頁面的實現
Bootstrap 前端框架擁有完善的響應式布局解決方案，它可以探測設備的窗體大 小來自動改變頁面布局，是一個很靈活的自動排版網格系統，可以通過探測設備屬性 得出的設備窗體大小來進行自動排版布局。它包含的功能有各種不同的布局選項和預 52
設的類。它針對的優先設計準則是移動端的小窗設備。屈B。。tstrap前端框架能對設 備進行媒體查詢，得知提交申請的設備是移動設備還是臺式電腦。頁面自適應的特點 是能隨著屏幕大小的增加減少元素或者改變頁面的布局。系統主頁面的主要任務是將 系統內的全部流程待辦和模塊功能展示處理，該頁面可以自適應不同設備的大小，適 當增加或者刪除元素。
Boostrap 需要一個 container 元素來包裹頁面上的內容來容納網格系統。在本文 所設計的系統前端頁面自適應頁面網格功能中，通過container容器實現的部分頁面 效果代碼如下所示:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title></title>
</head>
<body>
<div class="container">
<div class="row">
<div class="col-lg-3 col-lg-push-9 col-md-4 col-md-push-8 col-sm-6 col-sm-push-6">...</div>
<div class="thumbnail">
<img src="img/設備巡檢單 UI 圖片.jpg" alt="...">
<div class="caption">
〈p〉設備巡檢單〈/p〉
</div>
〈/div〉
〈div class="col-lg-3 col-lg-push-3 col-md-4 col-ms-6 col-sm-pull-6"〉...〈/div〉
<img src="img/設備報修單 UI 圖片.jpg" alt="...">
〈div class="caption"〉
〈p〉設備報修單〈/p〉
〈/div〉
〈/div〉
〈div class="col-lg-3 col-lg-push-3 col-md-4 col-md-pull-8
col-sm-6">...</div>
<div class="thumbnail">
<img src="img/設備報保養單 UI 圖片.jpg" alt="...">
<div class="caption">
〈p〉設備報保養單〈/p〉
</div>
〈/div〉
〈div class="col-lg-3 col-lg-push-3 col-sm-6"〉...〈/div〉
〈div class="thumbnail"〉
<img src="img/備件領用單 UI 圖片.jpg" alt="...">
〈div class="caption"〉
〈p〉備件領用單〈/p〉
〈/div〉
〈/div〉
〈/div〉
〈/body〉
〈/html〉
具體實現結果，在桌面瀏覽器上的效果如圖 5-2 所示，手機端的效果如圖 5-3 所 示，所有工作人員在主界面都可以查看該業務的流程進度。比如申請維修流程，申請 保養流程。
#首頁
•創建 Q捜護
1設備雋/雇歷表
□ 檢啟
* ©&J6修&確 .備品篩飆
•» MESffiB
尊全部
"待辦事項
及時清理侍辦，可以有菽提升流程施
0
即將超時
常用
鬧報修單
0
催辦
設亀呆惡
0我注的強s 0
E抄送ws林 o
目草稿箱 0
9
封牛® ffl單
圖 5-2 巡檢管理系統主界面桌面端頁面
Figure 5-2 Desktop page of the main interface of the inspection management system
圖 5-3 巡檢管理系統主界面手機端頁面
Figure 5-3 Mobile phone page of main interface of patrol management system
3、業務邏輯層（V）
Views 是 Django 框架的邏輯層，當該層收到來自 uWSGI 的客戶端申請數據時，通 過 URL 路由內的設計轉發申請，將數據發送至業務邏輯層對應的應用函數上。若沒有 對應的應用函數，則跳轉到預先寫好的故障代碼頁面。
系統主要的 view 函數定義如下：
人員信息編輯
#Def editPersonnelInformation（Request）:
人員權限編輯
#Def editPersonnelPermission（Request）:
備件信息添加
#Def addSparePartsInformation（Request）:
備件領用添加
#Def addSparePartsCollection（Request）:
備件入庫添加
#Def addSparePartsDepot（Request）:
備件庫存查詢
#Def querySparePartsInventory （Request）:
設備信息添加
#Def addDeviceInformation（Request）:
設備信息確認
#Def confirmEquipmentInformation（Request）:
巡檢信息添加
#Def addPatrolInformation（Request）:
設備信息查詢
#Def queryEquipmentInformation （Request）:
巡檢方案添加
#Def addPatrolScheme（Request）:
巡檢方案查詢
#Def queryInspectionScheme （Request）:
報修信息添加
#Def addRepairInformation（Request）:
報修信息查詢
#Def queryRepairInformation（Request）:
保養信息添加
#Def addMaintenanceInformation（Request）: 保養信息查詢
#Def queryMaintenanceInformation（Request）
4.8.3 巡檢管理模塊實現
巡檢人員檢查設備后若巡檢結果異常，則記錄于巡檢表內，同時系統增加報修單，
如果巡檢結果正常則更新設備狀態，并更新巡檢時間。巡檢管理系統流程如圖5-4。
圖 5-4 巡檢管理系統流程
Figure 5-4 Inspection management system process
巡檢人員在桌面端或者移動端登錄系統后，可以查詢巡檢記錄，也可以對設備的 記錄進行更新。模塊實現界面如 5-5 所示。
圖 5-5 巡檢管理提交及查詢頁面
Figure 5-5 Inspection management submission and query page
模塊代碼實現部分：
(1)查看管理范圍內的設備信息詳情 class EquipmentView(LoginRequired, View):
//設備管理
def get(self, request):
ret = Menu.getMenuByRequestUrl(url=request.path_info) ret.update(SystemSetup.getSystemSetupLastData()) equipment_types = EquipmentType.objects.all() filters = dict()
if request.user.department_id == 9: //只能看自己管理內的設備信息 filters['belongs_to_id'] = request.user.id
PersonInCharge = PersonInCharge.objects.filter(**filters).order_by('unit')
ret['equipment_types'] = equipment_types ret['PersonInCharge'] = PersonInCharge
return render(request, 'adm/equipment/equipment.html', ret)
(2) 更新設備的詳細信息 class ServiceInfoUpdateView(LoginRequired, View):
//設備維保更新記錄
def get(self, request):
ret = dict()
if 'id' in request.GET and request.GET['id']: equipment_id = request.GET['id'] ret['equipment_id'] = equipment_id
return render(request, 'adm/equipment/service_info_update.html',
ret)
def post(self, request):
res = dict(result=False)
if 'id' in request.POST and request.POST['id']: equipment = get_object_or_404(Equipment, pk=request.POST.get('id'))
if 'content' in request.POST and request.POST['content']: content = request.POST['content'] writer_id = request.user.id
service_info = ServiceInfo(content=content, writer_id=writer_id)
service_info.save() equipment.service_info.add(service_info) res['result'] = True
return HttpResponse(json.dumps(res), content_type='application/json')
4.8.4 設備報修管理模塊實現
巡檢員檢查設備發現設備有故障后，通過系統提交派工單，維修人員接到派工單 后抵達現場維修，維修完成后，由巡檢員驗收，驗收成功后提交設備狀態更新。 設備
報修管理流程如圖 5-6所示。
圖 5-6 設備報修管理流程圖
Figure 5-6 Equipment repair management flowchart
巡檢人員在桌面端或者移動端登錄系統后，可以查詢和填寫提交設備報修單，也
可以對設備的記錄進行更新。模塊實現界面如 5-7 所示。
圖 5-7 設備報修管理提交及查詢頁面
Figure 5-7 Equipment repair management submission and query page
模塊代碼實現部分：
(1)視圖層 views.py 實現代碼： class PersonalView(LoginRequired, View):
//我的工作臺頁面視圖
def get(self, request):
ret = Menu.getMenuByRequestUrl(url=request.path_info)
ret.update(SystemSetup.getSystemSetupLastData())
start_date = date.today().replace(day=1)
_, days_in_month = calendar.monthrange(start_date.year,
start_date.month)
end_date = start_date + timedelta(days=days_in_month)
# (('0', '工單已退回'), ('1', '新建-保存'), ('2', '提交-等待審批'),
('3', '已審批-等待執行'), ('4', '已執行-等待確認'), ('5', '工單已完成'))
role = Role. objects.get(title二'檢修部')
if 'value' in request.GET and int(request.GET['value']) == 1:
role = Role. objec ts.ge t(titl e二'維護')
if role:
users = role.userprofile_set.filter(is_active=1).values('id',
'name')
month_work_order_count = get_month_work_order_count(users,
value=int(request.GET.get('value', 0)))
year_work_order_count = get_year_work_order_count(users,
value=int(request.GET.get('value', 0)))
ret['month_work_order_count'] = month_work_order_count ret['year_work_order_count'] = year_work_order_count
return render(request, 'personal/personal_index.html', ret)
(2)邏輯層 forms.py 實現代碼： class WorkOrderCreateForm(forms.ModelForm):
//創建工單表單
# approver = forms.(required=True, error_messages={"required": "請選擇
審批人"})
class Meta:
model = WorkOrder
fields = '__all__'
error_messages = {
"title": {"required": "請輸入工單標題"},
"type": {"required": "請選擇工單類型"},
"status": {"required": "請選擇工單狀態"},
"do_time": {"required": "請輸入工單安排時間"},
"content": {"required": "請輸入工單內容"}, "PersonInCharge": {"required": "請選客戶信息"},
}
def clean(self):
cleaned_data = super(WorkOrderCreateForm, self).clean()
approver = cleaned_data.get("approver", "")
number = cleaned_data.get("number")
if not approver:
raise forms. ValidationError("請選擇工單審批人")
if WorkOrder.objects.filter(number=number).count():
raise forms. ValidationError ("工單編號已存在")
def clean(self):
cleaned_data = super(WorkOrderUpdateForm, self).clean()
approver = cleaned_data.get("approver", "")
if not approver:
raise forms. ValidationError("請選擇工單審批人")
4.8.5 自動報修模塊實現
備件在系統中登記有保養周期，系統會定期自動檢查一遍保養周期，當系統檢查 到備件的保養周期到期，系統會自動更新備件狀態，提示狀態異常，并自動填寫申請 保養單，推送給保養員，達到自動報修的目的。自動報修模塊流程如圖 5-8 所示。
圖 5-8 自動報修流程圖
Figure 5-8 Automatic repair flowchart
保養員保養結束后，在自動報修模塊填寫保養完成工單。并提交系統。自動報修
保養信息管理模塊實現界面如 5-9 所示。
礙呆養單 ■ X
(§> https//qingftaw.com/i777ffa792
保極次 間隔天數
d B3 入內容
本次保養時間 下次保養時問
2021-03-05 b| 2021-03-05 a
保養內容及要求
入內容
保養結果 設備狀態
已 未 I 請
保養信息記錄
尢RJ4-填
I請輪入內容
是否需要更換備品備件？-
圖 5-9 自動報修保養信息管理界面
Figure 5-9 Automatic repair and maintenance information management interface 模塊代碼實現部分： 系統會根據設備保養周期情況每月自動生成一份設備保養需求工單表
def get_month_work_order_count(users, value=0):
months = range(1, 12)
filters = dict()
month_work_order_count = []
for equipment in equipments:
count = []
for month in months:
start_date = date.today().replace(month=month, day=1)
_, days_in_month = calendar.monthrange(start_date.year,
start_date.month)
end_date = start_date + timedelta(days_in_month)
if value == 0:
filters['proposer_id'] = equipment['id']
else:
filters['receiver_id'] = equipment['id'] filters['add_time__range'] = (start_date, end_date) month_work_order = WorkOrder.objects.filter(**filters).count() count.append(month_work_order)
data = {
'name': equipment['name'],
'count': count
}
month_work_order_count.append(data)
return month_work_order_count
4.9本章小結
本章節分析了系統的設計目標和設計架構，對主要業務邏輯和功能需求進行了分 析。之后對自適應頁面的技術問題進行了分析，解決了系統的多平臺數據交互問題。 此外還對本文所設計系統的功能模塊的進行了設計和實現，最終完成系統的開發。
第 5 章 巡檢信息管理系統測試與運行分析
系統測試是為了發現軟件中存在的問題，通過設計不同的用例去進行實際測試， 能夠反饋出軟件的實際漏洞，確保系統能穩健地在生產環境中運行。系統測試包括黑 盒測試、壓力測試和兼容性測試。可通過得出的結論進行方案優化和代碼優化。
5.1測試環境與工具
WEB 服務端：
數據庫：MySQL 5. 1.60
操作系統：CentOS & 2. 2004
服務器軟件：Nginx 1. 12. 2； uWSGI
運行框架：前端Bootstrap框架，后端Django框架 桌面 WEB 客戶端：
桌面系統：微軟視窗 10
桌面系統內存：32G 顯示器分辨率：2560*1440 桌面瀏覽器：Google Chrome 手機端：
Android平臺原生瀏覽器：華為Mate8手機
IOS平臺原生瀏覽器：Iphonell手機
5.1.1功能測試
黑盒測試，可以測試出系統運行中存在的問題，是否完成了需求中提到各個功能， 在測試的過程中軟件能反饋出正確的信息，保障系統的穩定運行。
部分黑盒測試用例結果如下：
1、系統用戶功能測試，如下表 6-1。
表 6-1 系統用戶功能測試
Tab 6-1 System user function test
測試編號：001；測試功能：用戶登錄功能；使用賬戶： 管理員 admin01
序號 操作步驟 使用參數 操作結果 備注
1 不輸入賬戶、key,點擊“登
錄” 顯示請輸入用戶、密碼
的提示
2 輸入不正確的賬戶和 key,
點擊“登錄” ID：amin02
Key：123456 提示權限登陸錯誤,不
存在該賬戶
3 輸入正確的賬戶和key,點
擊“登錄” ID：admin01
KEY：user01 成功登錄系統
4 點擊“注銷用戶” 登出系統
2、密碼更換功能測試，如下表 6-2。
表 6-2 密碼更換功能測試
Table 6-2 Password replacement function test
測試編號：002；測試功能：密碼更改；使用賬戶： 管理員 admin01
序號 操作步驟 使用參數 操作結果 備注
1 使用正確的賬戶和密碼登
錄后,進入后臺權限管理 顯示所用角色信息,賬
戶名,賬戶權限信息
2 輸入新的key,和確認key,
并且兩個 key 內容不同,
點確認提交。 新密碼：admin233
確認密碼： admin1 顯示兩次密碼驗證不一
致,請重新輸入
3 輸入新的key,和確認key, 并且兩個 key 內容一致, 點確認提交。 新密碼： admin233
確認密碼： admin233 顯示提交成功,密碼修
改完成
4 不做任何輸入操作,直接 彈出提示該操作無效請
點擊確認提交 輸入密碼
5 點擊“退回主頁” 回到登錄界面
3、設備檔案管理模塊測試，如表 6-3。
表 6-3 設備檔案管理模塊測試
Table 6-3 Equipment file management module test
測試編號：003；測試功能：檢查是否可成功提交設備信息；使用賬戶： 管理員 admin01
序號 操作步驟 使用參數 操作結果 備注
1 進入備檔案管理頁面 系統前端頁面顯示設
備臺賬詳情表
2 申請修改該頁面權限 身份確認可以進行操
作
3 點擊頁面中的新增 新增設備信息 顯示已成功更新設備
信息
4 進行相關的查詢和操作之后，
按返回按鈕 回到主界面。
4、巡檢管理模塊測試，如下表 6-4。
表 6-4 巡檢管理模塊測試
Table 6-4 Inspection management module test
測試編號：004；測試功能：檢查提交設備缺陷信息的功能；使用賬戶： 管理員 admin01
序號 操作步驟 使用參數 操作結果 備注
1 點擊提交巡檢申請并填寫設備
缺陷信息 設備缺陷信息
2 申請提交該頁面權限 身份確認可以進行操
作
3 前端頁面上點擊保存 顯示申請提交成功
4 點擊“退回主頁” 回到登錄界面
5、設備報修管理模塊測試，如下表 6-5。
表 6-5 設備報修管理模塊測試
Table 6-5 Equipment repair management module test
測試編號：test_007；測試功能：設備報修功能測試；使用賬戶：管理員adminOl
序號 操作步驟 使用參數 操作結果 備注
l 點擊提交報修申請并填寫設備
報修信息 設備報修信息
2 申請修改該頁面權限 身份確認可以進行操作
3 前端頁面上點擊保存 顯示申請提交成功
4 已通知維修人員界面的出現 回到登錄界面
從以上對巡檢信息管理系統的測試中得出的結果是：當使用者輸入正確的操作信 息步驟時，系統在正常反應時間內返回數據結果，并通過前端頁面正確渲染顯示在瀏 覽器中。當使用者輸入錯誤的操作信息步驟時，系統根據錯誤的內容，提示出錯的原 因，并能指導用戶完成正確的操作。所有的測試結果符合預期功能，并且界面渲染正 確，符合要求。
5.1.2壓力測試
本文所設計的系統的測試服務器硬件表，如表 6-6 所示，采用本地的服務器進行 測試，為了方便今后轉移到云端部署，本地服務器的配置與云服務器的硬件配置性能 極其類似。
表 6-6 測試服務器硬件表
Table 6-6 Test server hardware table
硬件資源 名稱/類型 備注
網頁端服務器 處理器 銳龍處理器 8 核
內存 32G
硬盤 1000GB 固態硬盤
操作系統 Linux
數據庫中心服務器 CPU 銳龍處理器 8 核
內存 16GB
硬盤 500GB 固態硬盤
操作系統 Linux
性能測試的方式是使用自動化測試工具來模擬大量的客戶訪問,通過日志寫入運 行過程中返回的硬件數據和指標,來進行測試。性能測試主要用于測試系統在高負荷 訪問量下的極限能力,用于檢驗系統的實際性能,作為之后優化調整的參考依據。本 文所設計的系統測試使用的軟件為ApacheBench。該軟件的原理是通過創建多個客戶 端的訪問,模擬高并發的情況下對系統的某個應用在短時間內進行大流量訪問。以此 原理來對服務器的性能進行針對性的瓶頸測試。[50]
在改變不同的并發數后,記錄相關的服務器性能數據,如表 6-7 所示。
表 6-7 并發測試數據記錄表
Table 6-7 Concurrent test data record table
并發數 平均吞吐量(TPS) 吞吐量峰值(TPS) 90%響應時間(ms)
2 64 67 53
8 83 102 173
16 89 110 199
32 87 103 203
64 83 107 204
128 85 112 220
256 90 170 250
512 97 230 370
測試過程中的訪問量和系統硬件效能的關系如表 6-8所示。
表 6-8 壓力測試數據記錄表
Table 6-8 Pressure test data record table
開始時
間 結束時間 并發數 請求總數 失敗
總數 平均吞吐
量 90%響應
時間 CPU占
用率
lO:3O lO:3l 2 7O527 O lO9l l.09 34
lO:33 lO:34 8 7O545 O lllO 3.3 66
lO:35 lO:36 l6 7lO7O O ll69 7.8 73
lO:43 lO:44 32 7lOl9 O ll3O 23.2 77
lO:45 lO:46 64 7l283 O ll8O 45.5 82
lO:5O lO:5l l28 7O789 O ll9O 8l.3 84
ll:OO ll:O5 256 7lOl5 O l2lO 92.5 93
ll:lO ll:l5 5l2 72Ol3 O l26O 98 98
由以上測試結果可知，通過對系統最大能承受的客戶訪問量、高并發下數據庫的 壓力極限速度和頁面服務器瓶頸性能測試得出結果如下：在 500并發的極限負荷下， 網頁訪問的均響應時間控制在 2秒內，頁面查詢和服務器應用響應時間不超過 3秒， 符合對于系統性能設計的預期。以此得出結論，本文所設計的系統性能符合設計要求， 能夠很好支持大量的并發請求。
5.1.3兼容性和可用性測試
分別在華為Mate8手機和Iphonel2手機進行測試，巡檢信息管理系統的前端頁面 在這兩臺手機上均能完美流暢運行，證明本文所設計的系統在不同的終端和瀏覽器內 核環境下運行過程中都有良好的兼容性和穩定性。系統使用的前端渲染框架在不同的 設備中功能正常，頁面和 UI 交互操作上顯示正常，沒有出現排版錯亂，美觀大方優雅。
5.2 系統運行測試結果分析
經過以上測試后，系統各個功能均可正常使用，測試后針對發現的 BUG 進行了解 決,并且之后的運行過程中沒有再次出現。本文的 UI 界面部分對于實際業務的需要做 了圖形優化,使得在業務辦理的過程中流程顯示更加清晰易懂,提高了用戶體驗。
在經過以上全部測試后,系統測試結果符合預先期望的水平,系統能穩定運行。
5.3本章小結
本章的目的是針對系統軟件運行過程進行缺陷測試和分析。首先對系統的功能進 行了黑盒測試,之后完成了硬件測試和跨平臺測試。最后完成了測試結果總結,所有 測試結果均達到預期標準。
第 6 章 總結與展望
6.1總結
本文研究的主要目的是開發一個巡檢信息管理系統， 結合了巡檢的實際需要，通 過分析業務功能和業務流程，完成了技術架構選型，系統的功能設計和實現。
本文中系統的前端 WEB 頁面可以自適應于桌面端和移動終端，采用 HTML5 技術， 結合Django框架，Bootstrap框架為基礎進行開發，實現了跨平臺的無縫切換。最后 對該系統進行了軟件測試和硬件壓力測試。
巡檢信息管理系統在實際業務中，有效提高了巡檢業務的工作效率，減少了庫存 管理成本，有效節約了人工成本，省去了大量需要手工填寫的表格和臺賬，為巡檢業 務提供了信息化、高效化的管理方案。本文所設計系統能很好的處理與上級單位信息 管理系統數據對接問題，與上級單位的信息管理系統相比優勢和創新如下：
（1） 設備信息管理按照電網相關技術管理文件規范標準進行設計，包括人員信息、 設備信息、巡檢歷史記錄和設備手冊等，通過在數據庫中的合理數據結構設計，可以 在最短時間內完成實時報表統計和數據查詢。
（2） 對于電網線路設備運行規范和業務流程進行梳理，明確巡視要求，綜合考慮 設備巡視、檢查和維修等專業工作內容，建立一套巡檢計劃管理功能模塊，使得設備 的維護有目的性。
（3） 系統建立在規范化的業務流程上，實現計劃巡檢、報修和庫存管理，各個業 務間的流程辦理便捷和智能化，整體業務透明化和信息化。
（4） 采用目前最成熟的“互聯網+”開源技術解決方案，不需要額外的軟件采購 成本即可構建系統的輕量化及敏捷開發，實現快速完成系統原型，邊使用邊迭代開發。
（5） 與上級系統相比，不需要高昂的開發預算，復雜的開發團隊，采購昂貴的硬 件平臺和終端設備，可以直接使用最便宜的終端設備實現基層業務流程信息化。只需 要個人即可完成全部開發。軟件不需要繁瑣的培訓，操作簡便人性化。后期維護成本 極低。可以快捷的根據基層業務變動開發新的功能。
論文完成的主要內容有：
通過技術文檔和文件資料的查閱工作后，分析了國內外研究背景和行業應用情況， 進行合理的架構技術選型；對巡檢信息管理系統的功能需求和業務流程進行了分析和 總結，探討了系統的可行性需求；對系統的架構、業務功能進行設計，梳理業務流程 邏輯，并實現了原型的開發；在參與的開發過程中，遇到的問題例如自適應頁面的排 版系統失效，進行研究和解決。
6.2展望
本文所設計的系統已經實現了巡檢的所有業務所需的功能模塊，由于上級部門的 新規定和要求，后續的功能增加需要在原有系統開發中，增加足夠多的功能接口，以 便后續的新功能開發。此外在界面設計上，需要根據實際的用戶需求進行修改，使得 應用層的界面操作更加簡便易用。
目前互聯網行業發展迅猛，各種成熟的技術方案已經在各行各業廣泛應用，使用 這些免費開源且成熟的敏捷方案去開發信息系統成為當下最好的選擇。負責巡檢業務 的各部門人員可以通過移動終端和桌面端進行業務的快速受理、快速流轉、快速辦理， 極大地提高了業務的辦理效率。
由于自身的開發水平有限，在實現系統的過程中有許多困難和不足，這些問題將 成為本人后續探究的思路。
參考文獻
[1]康毅•輸電線路的精益化運檢管理研究[J].冶金管理，2020(19):107-108.
[2]肖榮軍•傳輸線路巡檢管理系統的應用探討[J].江蘇通信，2007(05):54-56.
[3]周麗芬•基于PDA的嵌入式GIS系統的研究與實現[D].武漢理工大學，2007.
[4]Thrall,Susan,Elshaw.ESRI'sArcPad6.0.3.[J].GeospatialSolutions,2006, 16(1):30-33.
[5]石旺來，王立勝，王成道.基于MapXMobile的嵌入式開發J].電子工程師， 2005(06):65-67.
[6]徐高瞻.ERP環境下地市級電網企業內部控制制度設計[D].華北電力大學(北 京),2016.
[7]亓東霞，馬琳，朱大銘，李振宇，申奇.企業信息孤島現狀及對策研究J].信息 技術與信息化，2019(08):166-168.
[8]唐躍中，魏曉菁.國家電網公司信息化“SG186”工程實施戰略研究J].電力信 息化，2007(10):18-22.
[9]馬洪舉.電力系統在“互聯網+”行動下輸電運檢管理策略——以山東濟寧供電 公司“互聯網+電力智慧巡檢”項目為例J].科技與創新，2016(21):58.
[10]黃蔚亮，覃平，黃榮海等.輸電精益化管理研究與實踐[C].中國電力企業管理創 新 5 年經典案例集，2015:997-1000.
[11]邰彬.智能巡檢系統在變電設備巡視中的應用[J].廣東輸電與變電技術， 2008(01):21-22.
[12]Sanner M F.Python: a programming language for software integration and development.[J].Journal of Molecular Graphics& Modelling,1999,17(1):57-61.
[13]MillmanKJ,AivazisM.PythonforScientistsandEngineers[J].Computing in Science & Engineering,2011,13(2):9-12.
[14]Nitnaware R R.Basic Fundamental of Python Programming Language and The Bright Future[J].A Peer-Reviewed Journal About,2019,8(2):71-76.
[15]R Tabares. HTML5 and the evolution of HTML; tracing the origins of digital platforms[J].Technology in Society,2021,65:29.
[16]Lin H C ,Lee G .Building a Secure Cross Platform Enterprise Service Mobile Apps Using HTML5[C].International Conference on Network-based Information Systems.IEEE Computer Society,2015:162-166.
[17]Bouras C ,Papazois A ,Stasinos N .A Framework for Cross-Platform Mobile Web Applications Using HTML5[C].International Conference on Future Internet of Things&Cloud.IEEE Computer Society,2014:420-424.
[18]Eich,Brendan.JavaScript at ten years[J].Acm Sigplan Notices,2005,40(9):129.
[19]Kienle H M .It's About Time to Take JavaScript (More) Seriously[J].IEEE Software,2010,27(3):60-62.
[20]Shah K,H Sinha,Mishra P.Analysis of Cross-Platform Mobile App Development Tools[C].2019 IEEE 5th International Conference for Convergence in Technology (I2CT).IEEE,2019:1-7.
[21]徐曉.基于Bootstrap技術的移動端Web開發研究[J].微型電腦應用，2018, 34(09):8-10.
[22]李淼，杜明晶，苗放•網頁設計中Bootstrap CSS框架的應用與拓展J].電子技 術與軟件工程，2013(017):222-223.
[23]周萍，趙娜，李慕.Bootstrap框架在響應式Web設計中的應用[J].軟件導刊， 2017,16(6):135-137.
[24]劉志凱，張太紅.Django框架在web開發中的應用[J].農業網絡信息， 2015(2):51-52.
[25]Tian H,Zhao J,Shen J.Research on Optimized Storage and Analysis System of Web Log Based on Django's MVC Framework[J].Journal of Physics: Conference Series,2021,1769(1):65-74.
[26]傅明，王瑋，程曉恒.跨平臺下網站開發運行環境PHP+MYSQL的實現J].計算 機應用研究，2001,18(4):116-118.
[27]Liu B J,Wu L J,He W,et al.Research on Performance Optimization Technology of Complex Equipment Software Database[J].IOP Conference Series Materials Science and Engineering,2021,1043(2):22.
[28]MD Giacomo.MySQL:lessons learned on a digital library[J].IEEE Software, 2005,22(3):10-13.
[29]Miyamoto N,Higuchi K,Tsuji T.Incremental Data Migration for Multi-database Systems Based on MySQL with Spider Storage Engine[J].International Journal of Networked and Distributed Computing,2015,3(2):119.
[30]杜星.輕量級Web服務器Nginx的理論與技術研究[D].江蘇：南京郵電大學， 2016.
[31]戴偉•基于Nginx高性能Web服務器的理論研究與性能改進[D].江蘇：南京郵電 大學，2019.
[32]何世明，凌正飛，戴明新.Excel數據向MySQL導入技術[J].電腦編程技巧與維 護，2007(12):46-48,65.
[33]徐輝.基于XML的Excel和MySQL數據交換的研究及實現[J].電腦開發與應用， 2009,22(03):51-53.
[34]阮征•淺談電力設備缺陷閉環管理系統[J].科技資訊，2006(01):11-13.
[35]徐力•供電企業變電檢修巡檢管理改進及優化研究[D].華北電力大學(北 京),2017.
[36]張明媚.電網企業生產管理信息系統建設管理探討[J].廣西電業， 2008(11):46-48.
[37]袁宇斌•淺談變電站缺陷的跟蹤與處理[J].中國高新技術企業， 2014(34):105-106.
[38]蘇鵬.跨站點腳本攻擊XSS的攻擊原理與防護[J].電子科學技術， 2014(1):83-87.
[39]王保錦，林卉，王健如，等.跨站請求偽造攻擊技術淺析[J].網絡安全技術與應 用，2020(5):28-29.
[40]田純青.利用Nginx實現基于URI的Web負載分配[J].現代計算機(專業 版),2009(07):187-191.
[41]陳淑蘭.基于Web日志的入侵檢測系統實現[J].電子世界，2014(10):128-128.
[42]白昌盛.基于Django的Python Web開發[J].信息與電腦(理論 版),2019,31(24):37-40.
[43]張磊•基于0RM技術的面向對象數據與關系型數據交互問題的研究[J].電腦知識 與技術，2017,13(6):144-145.
[44]Sakowicz,Napieralski.0bject 0riented Application Cooperation Methods with Relational Database(0RM) based on J2EE Technology[C].Cad Systems in Microelectronics, Cadsm 07 International Conference-the Experience of Designing&Applications of.IEEE,2007:327-330.
[45]蹇常林.0RM在 Django操作數據庫中的應用[J].技術與市場,2020, 27(1) : 56-57.
[46]魏雅琦.HTTPS加密協議在電力業務系統中的應用及安全防護研究[J].電力信息 與通信技術，2018,16(01):39-43.
[47]韓可彧.基于Django的XSS和CSRF防御系統的研究與實現[D].武漢郵電科學研 究院，2018.
[48]張翠麗，孟小艷，楊抒•基于Django框架的管理系統的設計與開發[J].計算機 技術與發展，2019,29(10):63-68.
[49]張晶晶，曹雙雙，楊怡潔，等.基于Bootstrap框架的響應式網站設計[J].電腦 知識與技術，2020,16(34):247-248.
[50]Y A Auliya,Y Nurdinsyah,D A R Wulandari.Performance Comparison of Docker and LXD with ApacheBench[J].Journal of Physics: Conference Series,2019,1211(1):42-47.
下一篇：沒有了
相關標簽:
