熱門論文
最新論文
滇池藍藻防控處置信息管理系統設計 與開發
發布時間：2023-07-08 10:20
目錄
摘要 I
Abstract III
第一章 緒論 1
1.1研究背景和意義 1
1.2國內外研究現狀分析 4
1.2.1國內研究現狀 4
1.2.2國外研究現狀 5
1.3論文的研究內容 6
1.4論文組織結構 7
第二章 系統開發技術與開發方法研究 9
2.1B/S 架構模式 9
2.2WebService 9
2.3后端開發技術 11
2.3.1python 語言 11
2.3.2Django 框架 11
2.3.3MTV 模式 13
2.3.4MySQL 數據庫 14
2.3.5JSON 數據格式 14
2.4WEB前端開發技術 14
2.4.1Javascript 15
242 HTML 與 CSS 技術 15
2.4.3Bootstrap 框架 16
2.5APP端開發技術 16
2.5.1hybrid 開發技術 16
2.5.2hybrid 開發框架 17
2.6本章小結 18
第三章 系統需求分析 19
3.1滇池藍藻打撈處置業務流程分析 19
V
3.1.1藻情監控 20
3.1.2藍藻打撈 20
3.1.3藻水及藻泥處理 24
3.2滇池藍藻防控處置過程中存在的問題 25
3.3功能性需求分析 26
3.3.1總體功能需求 26
3.3.2WEB 端功能需求 29
3.3.3移動 APP 端 34
3.3.4服務器性能需求 42
3.4非功能性需求分析 42
3.5本章小結 43
第四章 滇池藍藻防控處置信息管理系統設計 45
4.1系統設計原則 45
4.2系統安全性設計 46
4.2.1驗證碼驗證 46
4.2.2Session 限時 47
4.3數據庫設計 47
4.3.1數據采集與處理 47
4.3.2數據庫設計 48
4.4系統功能設計 54
4.4.1WEB 端模塊設計 56
4.4.2APP 端模塊設計 58
4.5本章小結 61
第五章 系統實現 63
5.1系統概述 63
5.2WEB 端 63
5.3APP 端 69
5.4系統測試 75
5.4.1系統測試環境 75
VI
5.4.2系統測試結果 75
5.4.3非功能性測試 77
5.5本章小結 78
第六章 總結與展望 79
6.1總結 79
6.2展望 79
參考文獻 81
攻讀碩士學位期間完成的科研成果 85
致謝 87
VII
第一章 緒論
1.1研究背景和意義
湖泊是全球水資源一個不可或缺的部分。我國的湖泊眾多［1］，我國人民崇尚因 地制宜，環湖而居，所以有湖泊的地方都會形成城市群，湖泊的存在既提升了湖 泊周圍城市人民的生活質量，又促進了湖泊周圍城市的經濟發展水平［2］。
我國城市化速度在不斷加快的同時，城市的規模和人口也都在不斷激增。由 于我國人民長期以來環境保護觀念的淡漠，大量污水不加處理便直排入湖泊，這 些污水里含有大量的污染物，污染物的涌入加劇了湖泊富營養化的程度，而湖泊 的富營養化又導致了藍藻水華問題的發生。我國湖泊藍藻水華的問題近幾年日益 嚴重。藍藻水華的發生，會嚴重污染湖泊水體，進而毒害水生生物，最終破壞湖 泊生態系統，嚴重影響湖泊功能的發揮，制約湖泊流域社會經濟的可持續發展。
第十三屆世界湖泊大會統計報告中提到：中國湖泊富營養化程度位居世界前 列，污染程度非常嚴重。從1969年至2009 年，湖泊的總體富營養化程度激增六 十倍。根據地表水環境質量標準GB3838-2002以TN（總氮含量）和TP（總磷含量）的 含量作為主評價指標評價 2011年中國湖泊的水質［3］，我國大部分的湖泊、水庫都 存在著富營養化現象。
2007 年太湖發生了藍藻大規模爆發事件，湖區出現了大范圍藍藻聚集的現象 ［4］。繼太湖發生了大規模藍藻爆發之后，安徽巢湖的湖區內也出現了藍藻大規模爆 發的現象，接二連三的藍藻爆發事件讓政府和社會公眾的目光都聚焦在了藍藻的 身上，藍藻的防控處置刻不容緩。
滇池被譽為“高原上的明珠”［5］，從昆明建城伊始，滇池便已成為了昆明必不可 少的一部分。滇池促進著昆明的經濟發展，提高著人民的生活環境質量，改善著 昆明的氣候與濕度。滇池的流域的面積為兩千九百二十平方公里，湖面的面積為 三百零九點五平方公里，湖內容納有十五點六億立方米的水。根據昆明城的匯水 位置來看，滇池正處在昆明城匯水區域的最低處，是整片流域內最終的污水容納 水體。
從上個世紀八十年代開始，隨著滇池流域周邊城市人口的不斷增加和城市化進
程的逐漸加速，入湖污染負荷急速劇增［6］。九十年代末的滇池水質已經變為了劣 V
1
類，水體富營養化程度已經變為重度，藍藻水華在夏秋兩季頻發。當每年到夏秋 兩季，由于西南風向以及滇池環流的共同作用，藍藻水華會在四月至七月之間在 滇池北部一帶大量聚集。滇池水體透明度急劇下降，不僅大大削弱了水面光感， 有損于滇池湖光山色的整體協調，而且直接影響滇池旅游景觀，嚴重破壞了滇池 水體生態環境。2009年5月1 6日當天，滇池藍藻爆發程度達到歷史同期最高，整 片湖域的大部分位置都覆蓋有藍藻，藍藻聚集最多處藻漿厚達十多厘米，嚴重威 脅著人民的健康。滇池已經成為了我國污染最嚴重的一個高原湖泊。
滇池藍藻水華的頻發危害極大。嚴重污染了滇池的水體，毒害了水生生物，破 壞了滇池的生態系統，影響了水體的景觀。由于藍藻水華對滇池水質、其它水生 生物、以及周邊環境質量等產生一系列負面影響，多年來，滇池水質和水生生態 環境一直受藻類季節性消長的影響和制約。
圖 1.1 滇池藍藻水華
滇池的藍藻問題一直是黨和國家高度關注的生態環境問題。國務院已將“加強 滇池藍藻水華防控，提升藍藻應急處置能力”列為“十三五”規劃的重點工作任務。 滇池藍藻水華的防控不僅是滇池流域水污染防治的重點工程項目，同時也是評價 滇池治理成效的重要依據。
自 2001 年起，昆明市政府就專門劃撥資金，對滇池藍藻水華重點防控水域進 行湖面藍藻機械清除。對滇池北部藍藻富集區藍藻進行機械清除，在一定程度上 改善了該區域藍藻大規模聚集的現象，同時，藍藻清除也帶走了大量的富營養化 物質，對削減滇池內源污染，改善區域水體景觀具有極為顯著的效果。
歷經二十多年的持續性治理，截止至二零一八年年底，滇池水質達到了歷史同 期的最好水平，水體由“黑臭水體”、“藻濁水穩態”正在向“藻清水穩態”過度。每年 滇池藍藻水華發生的程度、范圍和頻次與往年相比均呈現明顯的下降趨勢。但目
2
前滇池水體受藍藻污染情況依然不容樂觀，滇池藍藻水華防控處置仍然是滇池水 污染防治的重點和難點。
按昆明市政府工作安排，自2018年，由滇池藍藻防控處置的專業部門統一負 責滇池 310 平方公里水域藍藻水華的防控處置工作。目前，滇池藍藻防控處置的 專業部門已初步構建了滇池藍藻水華防控處置設施體系，一方面通過藻水置換有 效改善了重點區域水動力條件，達到控藻抑藻的目的；另一方面持續加大水上浮 藻導流、聚集、圍捕、抽吸等打撈措施，以及藻站、藻車、藻船等藻水分離處理 措施，通過低耗高效的方法減緩藍藻過度增殖，降低水華爆發程度和規模，實現 改善水體景觀、削減水體內源污染負荷的目標。
據統計，二零一八年一月至十一月，滇池藍藻防控治理專業部門圍繞藍藻重點 防控水域（防控面積約為九點二八平方公里），累計收集富藻水二點五億立方米， 打撈藻漿（藍藻干物質含量大于百分之零點零五）七百九十萬立方米，處理藻漿 二百九十二萬立方米，生產藻泥（藍藻干物質含量大于百分之十）六千九百四十 二噸。累計削減滇池內源污染負荷總氮含量為一千一百零三噸、總磷含量為六十 五噸。二零一九年全年藻泥產量約為一萬五千噸，二零二零年全年藻泥產量達到 兩萬噸。
隨著滇池藍藻綜合治理的深入推進，藍藻水華防控數據運行管理的難度日益增 大，傳統的管理手段和模式已不能滿足滇池藍藻防控處置的需求，主要存在以下 問題：
（1） 滇池藍藻防控處置設施設備種類繁多，業務流程復雜，每個環節都有各 類運行數據需要采集、上報、匯總和分析。藍藻監測、打撈、藻水分離、藻泥處 置過程中產生的大量數據和信息是滇池藍藻科學防控與精準治污的決策基礎，也 是評價滇池治理成效的重要依據。但目前滇池藍藻水華防控處置的信息獲取與管 理手段落后單一，大部分基礎信息仍以傳統手工的方式進行采集、記錄和管理， 管理效率低，迫切需要開發和應用滇池藍藻防控處置信息管理系統，實現對滇池 藍藻水華防控處置的信息化管理與分析。
（2） 滇池藍藻防控處置運行管理部門缺乏統一的滇池藍藻水華防控處置綜合 數據庫，滇池藍藻水華防控處置數據分散、數據多源、多格式、準確度低、可靠 性差，缺乏統一的數據規范和標準，無法對滇池藍藻防控處置歷史數據進行高效
3
集成的統一管理和分析，為藍藻水華防控與預警提供數據支撐。
（3）滇池藍藻防控處置的點位多、面積廣，滇池 310 平方公里的水域，僅重 點防控區域就有 42個。重點防控區域最易發生藍藻大規模爆發現象，一旦發生藍 藻大規模爆，必須立即進行藍藻現場打撈處置工作。及時、準確的藍藻打撈處理 現場數據是滇池污染治理的重要基礎信息，滇池藍藻防控處置部門迫切需要開發 和應用基于便攜式移動設備的APP,實現對藍藻打撈處置信息的現場采集與遠程 傳輸。
本文針對上述滇池藍藻防控處置中存在的問題，緊密結合滇池藍藻防控打撈過 程中對數據收集和管理的需求，研究和開發“滇池藍藻防控處置信息管理系統”，實 現對滇池藍藻打撈處置全過程的跟蹤管理，以及對滇池藍藻防控處置過程中產生 海量數據的現場采集、傳輸、分類管理及統計分析，有效減少滇池藍藻防控處置 過程中的人力、物力和財力，提升滇池藍藻聯合防控及應急打撈處置工作的信息 化管理水平，為滇池污染治理提供決策支持。
1.2國內外研究現狀分析
1.2.1國內研究現狀
我國城市化速度在不斷加快的同時，城市的規模和人口也都在不斷激增。由 于我國人民長期以來環境保護觀念的淡漠，大量污水不加處理便直排入湖泊，這 些污水里含有大量的污染物，污染物的涌入加劇了湖泊富營養化的程度，而湖泊 的富營養化又導致了藍藻水華問題的發生。我國湖泊藍藻水華污染的問題越發嚴 重，滇池、千島湖、太湖、巢湖都相繼出現了藍藻大規模爆發的現象。
國家治理藍藻的決心巨大，各地方政府也在不遺余力的加大對治理藍藻的投 入，治理藍藻的難度和投入都在逐年上漲。
太湖是上海、無錫等城市重要的飲用水源地。由于太湖流域經濟發展迅速的同 時環保觀念淡薄，廢水大量直接排放進太湖，致使太湖流域內水體氮、磷等污染 物含量過高，水體富營養化程度不斷加劇，藍藻水華頻發，嚴重威脅到流域城市 人民的身體健康、生產生活與飲用水的安全。特別是在二零零七年五月底，太湖 出現藍藻水華大規模爆發事件，致使無錫市出現供水危機［7］。
為了能有效的防控藍藻水華大規模的爆發，太湖流域管理局將人工調查與多種 技術相互結合，從點到線再到面，構建了一套全方位、三維的太湖藍藻監測系統， 結合的技術包括：監測點技術—在線水質檢測技術；監測線技術—視頻流監控技
4
術；監測面技術一遙感衛星監測技術［8］,并采用MODIS衛星遙感數據實現對全湖 藍藻的遙感監測。這一系統將多源監測信息進行綜合應用，可以及時準確的掌握 藍藻水華爆發的面積、程度以及位置變化的情況。
研究表明,藍藻的歷史數據能為藍藻的預警提供有力的數據支撐,歷史數據越 詳細,數據量越大,越能精準的預測藍藻的爆發時間、爆發地點以及爆發程度。 為了能及早預警藍藻的爆發,提早采取措施,降低藍藻大規模爆發后治理藍藻的 成本,蘇州的市環境監測站設計開發了一套名為“藍藻預警監測數據管理”的系統 ［9］。這套系統將收集到的藍藻數據進行上報,通過上報數據,對藍藻的爆發程度以 及變化趨勢進行分析。無錫市采用 JSCORS 系統,進行高精度太湖湖區內藍藻爆 發范圍圖表繪制,在繪圖的同時,將獲取到的藍藻數據進行繪制點采樣,存儲在 系統中,進行管理分析。
從全國范圍來看,我國湖泊藍藻防控已獲得各級政府和社會各界的高度重視, 對湖泊藍藻的防控處置正在積極推進和展開,并取得了明顯成效。但與發達國家 相比,我國湖泊藍藻防控處置運行管理的信息化建設仍然處于相對落后的水平, 湖泊藍藻防控處置仍處于重建設、輕管理的狀態。目前,僅有江蘇、安徽等省建 立了湖泊藍藻防控處置信息管理平臺,絕大部分地區和部門均未建立以實現湖泊 藍藻防控處置運行管理信息的可視化、科學化管理平臺。
1.2.2國外研究現狀
全世界面臨最主要的水污染問題是水體富營養化,而藍藻爆發所引起的水華現 象則是水體富營養化最直觀的外在表現。
在上個世紀七十年代,日本琵笆湖就出現藍藻大范圍爆發的現象,歷經三十多 年的治理才控制住。上個世紀七十年代的荷蘭費呂沃湖,藍藻也曾大規模爆發, 歐洲的康斯坦茨湖也曾暴發過嚴重的藍藻水華。北美的休倫湖、蘇必利爾湖、伊 利湖、密歇根湖、安大略湖最近幾年也接連不斷的有藍藻大規模爆發的現象出現。
在五個淡水湖泊中,伊利湖的湖域面積排名第四,湖域面積兩萬五千平方千米。 伊利湖湖區周圍工業城市眾多,以重工業的高度發達換來的卻是伊利湖的水質被 嚴重污染。二零一九年七月至八月,伊利湖水域大面積藍藻爆發,在七月三十日 的衛星圖像中可看到藍藻覆蓋總面積超過七百七十平方千米,截止到八月十三日, 藍藻的覆蓋面積已經擴大到一千六百零五平方千米,這是伊利湖歷史上藍藻爆發 最為嚴重的一次［10］。
波羅的海也長期深受藍藻問題的困擾［11］,二零一八年的波羅的海遭遇了歷史上
5
最大規模的藍藻爆發危機。由于長時間的高溫，導致海水溫度遠高于同期水平， 適宜的溫度下藍藻在波羅的海瘋長，大片海面呈現為綠色，嚴重影響波羅的海沿 線國家的旅游業，周邊國家居民的生命健康也遭受到了威脅。
目前，世界各國都在研究和探索藍藻防控處置的有效方法和途徑，正在構建長 效完備的除藻設施體系，及時進行藍藻打撈處理工作和富藻水置換工作，是防控 藍藻水華的有效措施。
為了遏制藍藻的爆發，美國將航拍技術與 GIS 技術相結合，形成地空聯動，用 于監視藍藻的爆發情況，并將監測到的藍藻數據存儲到系統中，供后續分析利用 [12]。塞爾維亞尼斯大學電子工程學院采用 GIS 與傳感器相結合，來對河流水污染 進行監控，藍藻作為污染物同時被納入監控范疇，系統采集到的藍藻污染數據， 也被同時存儲到系統數據庫中。歐盟所開發的水資源管理信息系統（WRMIS）【I3】, 用于監控水污染情況以及對水污染情況做出相應的污染程度評估分析，藍藻作為 被監控的污染源之一,也有大量藍藻監控數據被記錄到數據庫中存儲,為后續藍 藻污染程度判定作依據。
綜上所述，從世界范圍來看，將現代信息技術、GIS技術、物聯網技術及互聯 網技術應用于湖泊水污染防治和藍藻水華防控是必然的趨勢。
1.3論文的研究內容
本文針滇池藍藻防控處置存在的問題，緊密結合滇池藍藻防控部門對信息化管 理的實際應用需求，研究、設計和開發“滇池藍藻防控處置信息管理系統”，通過對 滇池藍藻打撈處置全過程的跟蹤管理，實現了對滇池藍藻防控處置生產運行數據 的現場采集、傳輸、統計、匯總與綜合分析，提升了滇池藍藻聯合防控及應急打 撈處置的管理水平與管理效率，為滇池污染治理提供決策支持。
論文的主要工作包括以下內容：
（1） 深入分析了滇池藍藻打撈處置工作的管理現狀和業務流程。
（2） 對系統研發相關的開發技術和方法進行了深入的研究和分析，重點研究 了 Python 語言、 HTML 語言、 CSS 語言、 bootstrap 框架、 Mysql 數據庫、 MTV 設 計模式，以及移動 App 開發技術等。
（3） 參與滇池藍藻打撈處置各個流程的基礎信息采集與處理，設計構建了滇 池藍藻防控處置數據庫。
（4） 設計并開發“滇池藍藻防控處置信息管理系統”，該系統由Web端和移動 App 端兩大部份組成，具有藍藻防控打撈處置信息的錄入、上報、統計、匯總，
6
數據報表分析、數據圖表分析等功能。
（5）系統已實際應用于滇池污染防治專業管理部門,實現了滇池藍藻打撈處 置的信息化、科學化管理與分析。
1.4論文組織結構 本文包括六個章節： 第一章：緒論。
第二章：系統開發技術與開發方法研究，主要包括Python語言、HTML語言、 CSS語言、bootstrap框架、Mysql數據庫、MTV設計模式，以及移動App開發技 術等。
第三章：系統需求分析，從藍藻打撈處置工作的流程出發，深入對系統的功能 性需求與系統的非功能性需求做出了分析。
第四章：系統設計。詳細闡述滇池藍藻防控處置信息管理系統的各方面設計。 第五章：系統實現。闡述滇池藍藻防控處置信息管理系統的實現，重點介紹
WEB端和移動APP端的功能實現。
第六章：總結與展望。
第二章 系統開發技術與開發方法研究
2.1B/S 架構模式
B/S架構模式，B即Browser（瀏覽器），S即Server（服務器）。由于互聯網技術 的飛速崛起，B/S架構模式隨之興起。B/S架構模式是在C/S架構模式基礎上的進 一步改進網。在B/S架構模式下，用戶可以舍棄臃腫Client（客戶端）的束縛，通過 瀏覽器實現原本Client（客戶端）的功能。
B/S 架構模式使用了三層體系結構[15]：第一層——瀏覽器，通過瀏覽器用戶就 可以建立服務器與客戶端之間的聯系，實現數據解析的功能。第二層——Web服 務器，收到用戶發出的請求隨即將以 SQL 語言寫成的請求發送到數據庫服務器中。 第三層——數據庫服務器，收到并處理請求，將查詢后的結果回遞回 web 服務器。
圖 2.1 B/S 三層體系結構圖
2.2WebService
WebService 是一種遠程調用地技術，可以在操作系統不一致、編程語言不同的 情況下將兩者建立連接。是一種以 HTTP 協議為基礎，通過 XML（Extensible Markup Language）進行客戶端和服務器端通訊的框架或者組件昭，圖2.2為WebService的 工作流程。
用戶 互聯網 Web service
圖 2.2 WebService 的工作流程
WebService 由三大部分組成，分別是：SOAP、UDDI、WSDL[17]O
SOAP：是基于 XML 的簡單對象訪問協議（Simple Object Access Protocol）， 用來傳遞信息。 SOAP 有專屬的信息傳遞格式，格式的標準是將 XML 與 HTTP 進
行組合，來調用處在不同操作環境中的分布式對象。SOAP的具體執行過程如圖
2.3所示：
UDDI:是一種用 于描述(Universal Description)、發現(Discovery)和集成 (Integration)WebService 的技術。它既可以為信息注冊中心提供基于協議的標準， 又可以提供訪問協議，供注冊、發現和調用。為所有需求人員提供相同的接口， 便于使用者可以使用不同的編程平臺和方式，發現發布的。 UDDI 的規范由結構化 信息標準組織來制定。需求者通過機制查找分布在互聯網上的UDDI，獲取其所對 應的文件，然后便可以調用相應的服務，從而達到在自己的程序中調用其他請求
服務的目的［18］。 UDDI 的工作原理如圖 2.4 所示。
圖 2.4 UDDI 工作原理
WSDL： XML 格式的 WEB 服務描述語言(Web Services Description Language)。
WSDL 的具體執行流程如圖 2.5 所示：
抽象描述，對訪問這樣一種操作行為或者訪問的信息進行的描述性行為［18］； 綁定信息，主要針對對象是前一步驟之后的信息，最后將其綁定，主要綁定目 標是一些既有的或者開發的傳輸協議；
定義服務訪問點，即對服務進行訪問點的定義，此時便形成了一個 WebService， 但這時的 WebService 是抽象的；
描述服務訪問點，為讓客戶端更容易理解而用WSDL對服務訪問點進行描述 ［18］；
指示客戶端，客戶端通過WSDL的描述和指示與服務進行交互［18］； 最終用戶理解，用戶可以理解WebService的內容及調用格式等凹。
XML：可擴展標記語言（EXtensible Markup Language），用來保存數據，簡化數 據共享、傳輸的步驟，讓數據可以在不同系統之間輕松傳輸，是一種獨立于硬件、 軟件的存儲數據方法。
2.3后端開發技術
本文的系統后端采用Django框架進行搭建，一定程度上提升了系統的響應速 度和優化了系統的性能。系統采用MySQL數據庫進行數據的存儲，讓系統的前后 端數據交互更加迅速，數據的存儲于交換的安全性也得到了提高。
2.3.1python 語言
Python 是一種如今被廣泛用于互聯網行業的通用型高級程序設計語言［19］。 python因其簡單易學：可讀性非常強，在編碼過程中以解決問題為主要目的，其 最大的優勢是偽代碼性［20］；可解釋性強：python語言可以直接從源碼運行，不需 要編譯為二進制的代碼，提高執行效率的同時增強了可解釋性；開源性： python 語言開源；高級語言性：python是高級編程語言；可擴展性強：python可兼容其 他語言在其程序中運行；極為豐富的函數庫：python擁有極為強大的各類函數庫， 可以在使用時進行調用，極大的釋放了編程人員的生產力；代碼規范性強： python 代碼在編寫時極為注重縮進格式。以上優點讓python得到了廣泛的應用。
2.3.2Django 框架
Django框架是一個開發WEB后端的開源框架,Django框架所采用的架構模式 是與傳統MVC設計架構模式相類似的MTV架構模式，其中M、T、V分別代表 Django框架中三個重要的組成部分：model（模型）一主要實現的是與數據相關業務 的定義與處理功能;template（模板）一主要實現的是與顯示相關的處理功能;view （視 圖）—主要實現的是模型的構造與不同模板的鏈接功能［21］。
11
Django 框架的所有核心組件都是基于 MTV 設計架構模式設計實現的，下面將 分別介紹 Django 框架中的核心組件［19］：
（1） ORM模型組件（Object Relational Mapping，對象關系型映射）：作為面向 對象與關系數據庫之間的橋梁，讓兩者能夠相互匹配。使用ORM模型組件非常的 簡單，開發者只需要在Models模塊中進行模型的創建，模型的激活，模型的遷移 三個步驟，便能完成模型與數據庫的關聯，數據庫中字段類型可以自己定義。在 進行數據庫的調用時，開發者只需要編寫正常的python語句，ORM模型便可以自 動將語句轉換為可執行的 SQL 語句，開發者可以在沒學過數據庫的基礎上，實現 調用數據庫的部分功能，雖然ORM模型自動轉換的SQL語句執行效率可能不如 自己寫的執行效率高，但是可以極大程度上減少開發者另外學習數據庫相關知識 的學習成本。
（2） 路由分發組件：Django的urls.py中記錄有URL地址，當網頁訪問URL 地址時，Django將urls.py中保存的URL地址分別與網址欄傳遞過來的URL地址 相對比，待找到對比一致的地址后，會調用地址關聯的視圖函數，視圖函數最終 會返回一個結果，在網頁上顯示該請求的內容。
（3） 自定義后臺管理組件： Django 自帶一個支持二次開發的后臺管理系統， 十分的方便。
（4） 模板語言組件：把Django的變量、標簽放入到HTML文件里，讓HTML 文件中可以執行循環遍歷、邏輯判斷等功能。同時，因Django有著獨特的模板繼 承機制，可以在不同的頁面繼承同一份模板上的內容，讓頁面的編寫更加的方便， 頁面內容的安排也能更加清晰。
（5） 緩存組件：用戶與網站的各類交互請求，服務器都需要對數據庫進行相 應的操作，將數據從數據庫中取出，添加到模板中，執行邏輯操作，最后渲染生 成頁面。當網站被用戶大量訪問時，會快速消耗服務端的資源，為了減少服務器 的壓力，需要引入緩存機制。通過調用Django內置的緩存組件，可以減少服務端 的資源消耗，提升服務端的響應速度。
（6） 表單處理組件：表單可自動生成，并對表單內數據進行增、刪、改、查 操作。
Django 框架運行流程圖如 2.6 所示。
12
2.3.3MTV 模式
MTV 模式是 Django 框架的基礎［22］：
Model（模型）：將業務對象與數據庫之間建立關系映射。
Template（模板）：用戶可以直接看到的頁面。
View（視圖）：解決業務邏輯。
URL 分發器：將 URL 請求傳遞給對應的視圖處理。 圖 2.7 是 MTV 的框架示意圖。
13
2.3.4MySQL 數據庫
MySQL—關系數據庫管理系統I20】。當遇到數據需要被存儲時，MySQL會把所 有的數據按種類保存到不同的表中，這樣可以讓用戶在進行數據庫操作時擁有較 高的流暢度和靈活的操作感［44］。由于MySQL數據庫具有體積小巧、數據加載快等 優點，因此各類網站的開發者都會首選MySQL數據庫作為網站的后臺管理數據庫 ［45］。
2.3.5JSON 數據格式
JSON—數據交換格式。JSON的語法結構簡潔，使用文本來存儲數據，可以優 秀的實現前后端數據的交互功能。數據在JSON中以鍵值對的方式來存儲和表示。 JSON對象保存在JavaScript語言的花括號｛｝中，｛｝中的內容采用“key（關鍵 字）/value（值）”鍵值對的表示形式［23］，便于閱讀和理解，用“，”來分割key和value， key的類型為字符串，而value類型較多，包括true、false、null、數值等。
2.4WEB前端開發技術
本文采用當前最流行的 WEB 前端開發技術進行系統前端的設計與開發， 運 用時下最流行的 HTML5 技術與 CSS3 技術對系統的頁面展示進行設計，采用 Bootstrap框架進行系統展示頁面的快速搭建，運用Javascript腳本語言＞ jQuery框
14 架優化和增加頁面的用戶交互效果。
2.4.1Javascript
JavaScript 是一種基于原型的直譯式腳本語言，用于實現 HTML 網頁的動效功 能。JavaScript引擎是JavaScript語言的解釋器，已經被內嵌到各類瀏覽器當中［24］。 JavaScript 具有三個方面的優點：
（1） JavaScript 可以讓數據在本地進行校驗，有效的減少了網絡資源的占用， 提高資源的利用率；
（2） JavaScript 可以對頁面中顯示元素的外觀等進行控制，用戶可以自定義頁 面上的各種功能；
（3） JavaScript 可以讓任務在不需要網絡和服務器參與的情況下由客戶端獨立 完成；
jQuery 是一個 JavaScript 的開發框架，由于 jQuery 具有體積輕量、兼容多瀏覽 器、插件庫豐富、源碼開源等優點，使得 jQuery 被越來越多的開發者使用。
Ajax（Asynchronous JavaScript And XML），用 于進行交互式 Web 應用的開發。 與服務器的實時數據交換通過get和post函數來實現，Ajax即可適用于只需要更 新部分內容的靜態網頁使用，也可以用來創建動態網頁， Ajax 具有使網頁應用程 序代碼更小，更流暢的特點［23］。圖 2.18 為 Ajax 應用模式圖。
圖 2.8 Ajax 應用模式圖
2.4.2HTML 與 CSS 技術
HTML—用于萬維網編程和開發的超文本標記語言。HTML語言誕生于上個世 紀九十年代［25］，用于把網頁中存在的各部分內容直觀的呈現在頁面上。 HTML 語 言可以對文字、圖形等內容進行描述。 HTML 擁有著優秀的跨平臺、跨設備開發 的能力，可以實現自適應相應的布局，可以做到即時的更新。因其可以使網頁的
15
語義化結構更優化，可以讓網頁的啟動時間盡可能縮短［24］，優化網絡的速度，而 深受廣大開發者的喜愛。
css—層疊樣式表，以像素級別的精度來控制數據在頁面上進行展示［26］。CSS 可以將頁面上展示部分與數據內容相分離，也可以美化頁面上元素的顯示。現階 段用于開發的 cSS 引入了很多新的模塊，讓網頁具有了良好的可擴充性，也兼容 了不同分辨率的設備，這樣極大程度上加快了靜態頁面的開發速度［40、41］。
cSS 具有以下優點：
(1)可以將內容與展示分離。
(2)可以讓網頁的頁面展示更為統一，容易進行修改。
(3)豐富的頁面展示樣式，使得頁面的布局更為靈活。
2.4.3Bootstrap 框架
Bootstrap 是一套響應式 WEB 前端開發框架，可以讓同一個網頁在不同設備上 實現自適應的展示［27］。Twitter公司的一位設計師和一位工程師共同合作開發了 Bootstrap，于2011年8月19日首次發布。目前，Bootstrap經過多次重構，累計 更新迭代超過二十個版本，在已經發布的Bootstrap 3版本中，引入了“移動設備優 先”的理念并支持響應式布局的開發。
Bootstrap集合了 JavaScript、CSS和HTML，并提供了一系列簡潔的UI組件、 網格化系統以及JavaScript插件［24］,Bootstrap可以讓不精通前端UI設計的開發人 員，通過調用Bootstrap所提供的各類插件，快速搭建出即美觀又簡潔的前端界面。
Bootstrap 的優點：
(1)響應式設計：Bootstrap框架由于其所具有的響應式CSS，可以讓網頁在手機、 平板等各類終端實現自適應的展示。
(2)瀏覽器支持： Bootstrap 框架已廣泛的被各類瀏覽器所支持。
⑶內置組件豐富：Bootstrap框架里的內置組件多種多樣。
(4)開源/定制： Bootstrap 已經開源并支持定制。
2.5APP 端開發技術
2.5.1hybrid 開發技術
目前移動端APP有三種主流的開發模式：原生開發模式(native)—使用不同的 開發工具開發不同操作系統的APP，這樣開發出來的APP可以方便的調用設備 API，同時需要在終端安裝APP。網頁開發模式(web)—完全依靠網絡技術進行APP 開發，打開瀏覽器就能使用APP，不需要在終端安裝APP，這樣開發出來的APP
16
調用設備的API。混合模式(Hybrid)—將原生與網頁兩種開發模式的優點進行結合, 用網頁開發模式的開發方法開發出一個像原生開發模式一樣需要安裝的APP，利 用網頁開發技術進行開發，這樣可以讓設備的API被JavaScript所調用［28-30］, —套 代碼就能在不同的平臺進行使用。
Hybrid 開發模式具有以下的優點［28］：
(1)低廉的開發費用換來的卻是高效的開發效率。
(2)具有良好的跨平臺性。
(3)后期維護成本低廉，后續開發方便。
2.5.2hybrid 開發框架
2.5.2.1MUI 框架
MUI是一個最接近原生App效果的開發框架，具有性能高和體積輕量的優點 ［31］。 MUI 框架可以做到一次打包，多端同時使用，即程序一次編寫就能同時打包 為Android APP、iOS APP等應用，由于MUI框架編寫的各類應用程序通過調用 瀏覽器進行打開，因此只要HTML5+標準下的瀏覽器，即使軟件不兼容該SDK, 也能通過降低瀏覽器版本來打開應用程序［32］。在MUI框架中，有豐富的布局樣式 可供選擇，也提供了大量的CSS組件控件，如圖片輪播、滑動菜單、彈窗、折疊 面板等，有些控件就是原生的顯示效果。
MUI 具有以下優點［32-33］：
(1)輕量：MUI框架自帶的JSj CSS文件都很小，用戶可以根據自己的需要, 自定義下載對應的模塊。
(2)原生UI： MUI的前端框架的UI控件十分的貼合原生UI,足以滿足絕大 部分的開發需求。
(3)容易上手：可以直接進行開發，省去了學習其他框架的時間成本。 2.522 Vue.js 框架
Vue.js是一套漸進式用戶界面構造框架。在操作的過程中更加自由方便，Vue.js 框架的結構設計簡單，用戶在初次使用Vue.js框架時就能夠輕松上手，多次使用 便能輕松掌握Vue.js的全部用法。可以非常容易的掌握Vue.js的使用方法，也能 將Vue.js與其他庫或已經存在的項目進行融合，Vue.js是一套具有響應式編程、組 件化、模塊化特性的完整的用戶界面構造框架［24、33］。
Vue.js的操作多變，既可以把Vue.js與單文件的組件結合開發，讓Vue.js驅動
17
單頁應用程序。也可以調用 Vue.js 中的不同的組件，讓這些組件與不同的頁面相 對應[24],在開發多頁面時，已經調用過的Vue.js組件也可以進行復用，Vue.js的 引入讓開發更加方便和高效。
Vue.js 的 核 心 層 面 是 “ 數 據 驅 動 的 組 件 化 系 統 ” ， 即 使 用 MVVM(Model-View-ViewMode)模式來表示數據與用戶頁面之間的聯系，MVVM 模式是基于MV。42、43】模式的演變,View與Model之間通過ViewModel進行聯系， 一旦數據發生變化，便會動態的反應到與之聯系的模塊上，即所謂的數據雙向綁
本章詳細介紹了在開發滇池藍藻防控處置信息管理系統的過程中需要用到的
關鍵性技術，并對技術本身所具有的優勢進行了分析。
18
第三章 系統需求分析
3.1滇池藍藻打撈處置業務流程分析 目前，滇池藍藻打撈處置工作的業務流程主要分為以下三個步驟。 第一步：藻情監控；
第二步：藍藻打撈； 第三步：藻水及藻泥處置。
藍藻防控的各項工作均由滇池藍藻防控處置專業部門承擔，其中每個環節都會 有大量的藍藻打撈和處置數據需要采集、傳輸與上報，用于滇池藍藻防控運營管 理。
圖 3.1 為滇池藍藻防控處置的工作流程，以及各個環節需要采集和分析的運營 數據。
藻水打撈
處理手段 產生的運營數據 備注
藻水外排管道 開閘數、開度、小時數、 流量 均有圖片上報
打撈船（輔助管 道） 開關機時間、流量
藻船、藻車、藻 站 開關機時間、流量、加藥量、 耗電量
藻水處理
處理手段 產生的運營數據
管道抽吸后外排，藻車等加藥處理 處理量、加藥量
藻泥處理
處理手段 產生的運營數據
運輸車運至藻泥處理廠 藻泥含水率，藻泥量，運輸車牌 號，藻泥最終運輸地址及用途
圖 3.1 具體的工作流程及產生的對應運營報表數據
19
3.1.1藻情監控
每年滇池藍藻的爆發期從四月份開始，一直會持續到十一月，爆發周期長，爆 發時間、地點和區域不確定，給滇池藍藻監測帶來的較大的困難。
滇池藍藻防控處置專業部門通過對滇池歷年藍藻水華暴發的原因和發展變化 趨勢的研究，構建了“湖體-重點區域-關鍵位置”全覆蓋的滇池藍藻“天-空-地”一體 化監測體系，天代表的是衛星遙感的監測，空代表的是無人機的航拍，地代表的 是地面水域的巡查，做到實時發布滇池水質的變化情況和藍藻藻情預警信息，并 在藍藻爆發的第一時間內對滇池藍藻爆發區域的湖面進行藍藻打撈作業。
目前，根據滇池藍藻水華爆發的歷史數據及規律，滇池藍藻防控處置專業部門 已在 310平方公里湖區面積中，劃分出了42 個需要重點防控的湖面區域，并在與 湖面區域相對應的沿岸設立藍藻監控設施和監測點，布設有42個24小時視頻監 控的高清監控攝像頭。一旦監控區域發現藍藻爆發，藍藻打撈處置工作將會立刻 展開。
在除重點監控區域以外的區域，由于攝像頭的畫面無法覆蓋到，需要每天對滇 池湖面進行人工的巡查。巡查的地點近到滇池外海北岸，遠到晉寧一帶的濕地， 都需要巡查人員親自到現場，用肉眼觀察確定是否有藍藻小規模暴發的區域。每 位巡查人員都需要每天要走路 10公里、開車40—50公里巡護滇池岸堤。因為部 分巡查地段游客比較集中藍藻也容易富集，只有徒步巡查，才容易發現。
3.1.2藍藻打撈
及時打撈和處置藍藻是削減滇池湖體內源污染的有效措施和途徑，一旦發現藍 藻藻情，必須立即進行藍藻現場打撈處置。針對滇池藍藻防控處置以及滇池內源 污染削減的工作目標和任務，進一步加強昆明滇池湖泊藍藻爆發時期的打撈處置 工作力度，需要有大量的設備和人員投入到藍藻打撈處置的工作中。
打撈處置工作主要是針對藻水、藻槳和藻泥。
藍藻藻水：當每升湖水中含有的藻類數量大于 100萬個時便將此時的湖水稱為 藻水。在滇池湖泊水體中，藻數量以藍藻計，藍藻干物質含量小于 0.01%的稱為含 藻水；藍藻干物質含量為0.01%?0.05% （不含0.05%）的稱為富藻水；藍藻干物 質含量為0.05%?0.1% （不含0.1%）的稱為藻漿；藍藻干物質含量為0.1%?1% （不含1%）的稱為濃藻漿；藍藻干物質含量為1%?10%（不含 10%）的稱為藻 渣或藻泥。
目前，昆明滇池藍藻防控部門下轄有 56 類藍藻打撈處置設備，分別對藍藻藻
20
水、藻槳和藻泥進行打撈和處置。以下是部分藍藻打撈處置設備的藍藻打撈處置 流程及生產運營需采集和上報處理的數據。
3.1.2.1 固定式藻水分離站 滇池邊僅有一座固定式藻水分離站，它就是龍門藻水分離站。 固定式藻水分離站的藻水處理流程為：
(1)在藻漿調節池將富藻水濃度混合均勻。
(2)通過氣浮池底部不斷上浮的氣泡，將藍藻黏著到氣泡上并送浮到水面， 實現藻水分離。
(3)富藻水進入到二級分離池再次進行分離。
(4)將二級分離池分離出來的藻渣放入藻渣調節池，通過加壓離心高速旋轉， 使得藻渣內的水分得到進一步的分離，實現深度脫水。
(5)深度脫水狀態的藻渣成為了藻泥，將藻泥裝載到運輸車中送至藻泥處理 廠處理。
圖 3.2 龍門藻站及藻泥脫水過程
龍門藻站運行日報表如表 3-1 所示：
表 3-1 固定藻站運行數據表
龍門村藻站運彳 亍日報表
運行日期 年 月 日
班次 開機時間 停機時間 停機原因 班次運行時間 值班人員簽字
白班
中班
夜班
消耗藥劑(千克) 聚合氯化鋁 處理量 水處理量(立方米)
聚丙烯酰胺 藻泥處理量(噸)
流量計 開機流量 關機流量
1# 2# 3# 4# 1# 2# 3# 4#
藻
外
運 處 置 (噸) 車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號； 毛重： 皮重： 凈重： 車牌號； 毛重： 皮重： 凈重；
車牌號： 毛重： 皮重： 凈重： 車牌號； 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
設備情況
保養情況
備注
21
3.1.2.2 移動式藻水處理裝置（藻車）
移動式藻水處理裝置也被稱為藻車，藻車的靈活性高，機動性強，可停放在藍 藻匯集的區域岸邊，藍藻去除率達到 95%以上。
移動式藻水處理裝置的處理流程為：第一步聚集富藻水，通過人工和機械的方 法，將富藻水聚集；第二步抽吸藻漿，通過抽吸器吸取匯聚到一起的富藻水；第 三步氣浮分離，裝置底部產生氣泡將藍藻黏著到氣泡上送浮至水面，大量藍藻被 送浮到水面聚集形成藻渣，用刮渣器刮除；第四步脫水，將藻渣送至脫水器中脫 水形成藻泥；第五步藻泥外運，脫水后的藻泥會被運輸至處置點進行無害化處置 或資源化利用。
圖 3.3 移動式藻水處理裝置（藻車）
移動式藻水處理裝置運行日報表如表 3-2所示：
表 3-2 移動式藻水處理裝運行日報表
移動式藻水處理裝置運行日報表
車號 除藻地點 運行日期 年 月 日
班次 開機時間 停機時間 停機原因 班次運行時間 值班人員簽字
白班
中班
夜班
消耗藥劑（千克） 聚合氯化鋁 處理量 水處理量（立方米）
聚丙烯酰胺 藻泥處理量（噸）
流量計 開機流量 關機流量
領油量 耗油量 耗電量
藻 泥 外 運 處
（噸） 車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
車牌號： 毛重： 皮重： 凈重： 車牌號： 毛重： 皮重： 凈重：
設備情況
保養情況
備注
3.1.2.3 加壓控藻船（藻船）
加壓控藻船，可隨時抵達藍藻大面積匯集水域實施藍藻處置工作。加壓控藻船
22
的藻水處理流程為：對指定位置的水體進行加壓處理，高壓使藍藻囊團的囊膜破 裂，藍藻死亡。
圖 3.4 加壓控藻船（藻船） 加壓控藻船運行日報表如表 3-3所示：
表 3-3 加壓控藻船運行日報表
加壓控藻船運行日報表
船號 除藻地點 運行日期
開機與否 開機時間 關機時間 關機原因 單次運行時間 單次抽水量訐 記錄人 審核人
停機次數 運行時長 單日抽水量川 抽取藻漿量卅
領油量L 耗油量L 耗電量KW/h
設備情況
保養情況
備注
3.1.2.4 曝氣船
曝氣船，因其體積較小、操作靈活可在體積較大的除藻設備無法到達的近岸水 域進行工作，曝氣船的藻水處理流程為：通過向水體中不斷輸送氧氣，提高水體 中氧氣的溶解量以改善水質。
圖 3.5 曝氣船
曝氣船運行日報表如表 3-4所示：
23
表 3-4 曝氣船運行日報表
曝氣船運行日報表
船號 除藻地點 運行日期
開機與否 開機時間 關機時間 關機原因 單次運行時間 記錄人 審核人
合計 停機次數 單日運行時間
設備情況
維修保養情況
備注
3.1.2.5 水動力控藻器
水動力控藻器的藻水處理流程為：向下層水體中不斷輸送氧氣提升下層水體中
氧氣的濃度，輸送氧氣使得水層混合，進而破壞藻類的懸浮狀態，徹底將藍藻生
長所需要的環境條件改變，使得藍藻遷移到下層水體中，最終達到抑制藍藻生長 的目的。
圖 3.6 水動力控藻器
水動力控藻器運行日報表如表 3-5 所示：
表 3-5 水動力控藻器運行日報表
水動力控藻器運行日報
分布 日期 設備編號 開機時間 停機時間 停機原因 運行時間 備注 運行時間合計 停機次數合計
外海 □無藻停機' □設備檢修、□停機待命、□其他
□無藻停機、□設備檢修、□停機待命、□其他
□無藻停機、□設備檢修' □停機待命、□其他
□無藻停機、□設備檢修、□停機待命、□其他
草海 □無藁停機、□設備檢修、□停機待命' □其他
□無藻停機' □設備檢修' □停機待命、□其他
□無藻停機' □設備檢修' □停機待命' □其他
□無藻停機、□設備檢修、□停機待命、□其他
南岸 □無藻停機' □設備檢修' □停機待命' □其他
□無藻停機、□設備檢修、□停機待命、□其他
□無藻停機' □設備檢修' □停機待命、□其他
□無藻停機、□設備檢修、□停機待命、□其他
3.1.3藻水及藻泥處理
24
1、藻水處理 首先在藍藻富集區內采用船只或機械圍捕措施將水面浮藻向富藻水抽吸點聚 集，使水面浮藻由厚度約2cm堆積至約5cm左右，然后將藻漿輸送到藻漿調節池， 待藻漿調節均勻后再送入平流式氣浮池；在平流式氣浮池內，高藻水首先進入反 應室，水體停留時間lOmin,與投加的絮凝劑(絮凝劑濃度為PAC50ppm, PAM 2ppm)充分攪拌混合生成“磯花”，之后再經擋板底部進入氣浮接觸室，氣泡上升 將藍藻送浮至水面，機器順著水面將藻泥刮走；處理過后的清水進入清水槽，然 后直接排放回補滇池草海；
2、藻泥處理
將氣浮工藝獲得的含水量約 97%的藻渣，經機械措施進行藍藻胞間脫水后再用 高效沉降卸料離心裝置進行脫水分離處理。使藻渣的含水量由 97％降至 8O-85％。 脫水后的藻泥，外觀呈泥狀，無流動性；根據情況，可運至填埋廠或與污水處理 廠污泥合并處置。
3.2滇池藍藻防控處置過程中存在的問題
隨著滇池污染綜合治理的深入推進，滇池藍藻防控處置的規模劇增，藍藻水 華防控運行管理的難度日益增大。滇池藍藻防控處置設施設備種類繁多，業務流 程復雜，每個環節都有大量的運行數據需要采集、匯總和分析。但是僅僅依靠紙 質來記錄數據，僅僅憑借人工來報送資料的信息收集方式卻早已與藍藻防控處置 信息化的目標格格不入。
目前滇池湖泊藍藻打撈處置工作主要存在以下問題：
(1)對藍藻打撈治理的歷史數據資料缺乏科學化、信息化的統計分析。截止目 前為止，昆明滇池藍藻打撈處置過程中積累了大量歷史數據資料，包括歷年的滇 池藍藻動態數據匯總、歷年的滇池藍藻治理生產統計報表數據等相關歷史數據資 料。但是這些海量的歷史資料大數據，都因為歸檔混亂管理不清晰，缺乏科學化、 信息化的統計分析。致使許多數據資料不能為滇池的污染防治提供決策依據。
(2)每日滇池藍藻打撈處理的業務數據上報流程簡陋，管理存檔混亂。由于每 日的藍藻打撈治理工作的詳細運營數據，都是由現場設施設備操作人員，將所需 要上報的數據填寫為紙質報表或通過拍照的方式上報到微信群中，這樣便造成了 數據的歸檔統計不及時，無法進行及時的歸檔管理。
25
（3） 以紙質或者照片形式保存的歷史數據查詢十分不便，數據丟失嚴重。由于 各類運營管理數據均是通過紙質報表或拍照的形式進行上傳，導致后期數據的查 詢，數據的導出不便。以紙質形式所保存的數據資料丟失十分嚴重。
（4） 整理歸檔的數據不能以直觀的圖形圖表界面進行展示。當操作人員需要將 各類歷史數據以圖表、統計圖的形式導出時，沒有能一鍵導出的工具，只能用 Excel 圖表進行簡單的數據整理與圖形繪制，導致圖表、統計圖的繪制形式單一，可視 化效果很差，操作不便。
（5） 現場數據上傳填報不方便。由于通過拍照和紙質的形式進行上傳，現場操 作人員上傳填報數據并不方便，容易導致業務數據不能及時的上傳，存在數據偷 報、漏報、謊報的情況。
綜上所述，當前滇池藍藻打撈處置工作過程中，對現存的歷史大數據資料缺乏 科學的管理方式，湖泊管理單位的管理人員不能快速的進行數據的查詢、統計和 分析；而且，不能準確的將上報數據與責任人一一對應關聯，上報的數據資料容 易出現偷報、漏報、謊報的情況發生，數據資料的可信度也逐漸降低；歷史數據 的操作人員操作數據不方便，各類歷史數據不能一鍵生成所需要的圖表與統計數 據，可視化效果很差。
本文針對滇池藍藻防控處置信息管理存在的問題，緊密結合滇池污染治理部門 的實際應用需求，研究、設計和開發“滇池藍藻防控處置信息管理系統”，提升滇池 藍藻聯合防控及應急打撈處置工作的信息化管理水平，為滇池的藍藻打撈處置提 供基礎數據和決策支持。
3.3功能性需求分析
3.3.1 總體功能需求
根據對滇池藍藻防控處置業務流程的分析，滇池藍藻防控處置信息管理系統 應包括以下三種類型的用戶。
（1）現場設施設備操作人員：主要負責現場藍藻的打撈處理工作，需要利用 移動終端對現場的打撈作業情況進行匯總上報；
（2）監理工程師：主要負責對管轄范圍內現場設施設備操作人員提出的開關 機操作申請進行審核和批準；
（3）系統管理員：主要負責對上報的數據進行統計匯總分析，生成各類報表
26
數據，同時還需對現場設施設備操作人員上報的打撈作業數據進行審核。 根據上述分析，滇池藍藻防控處置信息管理系統需由兩部分組成，一部分是
WEB端系統，另一部分是移動終端APP。需要提供的服務功能如圖3.7所示。
圖3.7 系統總體功能結構圖
1、 WEB 端系統管理員的功能需求
(1)登錄/登出模塊
在登錄系統時負責核驗操作人員的身份信息，保證系統數據安全，并提供登出 功能，保證無賬號人員不得對系統數據進行操作。
(2)運維管理模塊 負責對各類除藻設備、打撈設備、運行維護設備等與滇池藍藻打撈處置有關設
備進行管理，包括增、刪、改、查等操作。
(3)運營統計模塊 對匯總的數據進行管理和統計，提供一鍵生成所需臺賬、匯總圖表，導出文件、
歷史記錄等功能。
(4)后臺管理模塊 在后臺管理模塊內，提供有菜單管理、后臺管理員管理、系統信息查看等功能。
2、 APP 端現場設施設備操作人員功能需求
(1)登錄/登出模塊 在登錄系統時負責核驗操作人員的身份信息，保證系統數據安全，并提供登出 功能，保證無賬號人員不得對系統數據進行操作。
27
(2)開/關機申請模塊
操作人員進行設備開/關機操作時需要進行申請，由監理工程師審核批準后方 能開始操作。開/關機申請模塊需要顯示申請列表和歷史開/關機申請記錄，點擊記 錄可以查看詳情。
(3)日志上報模塊 當操作人員完成當天現場作業后，需要填報操作數據，日志上報模塊需要具備 自動本地保存功能。
(4)個人中心模塊
提供修改頭像、修改密碼、提供檢查版本更新和上報軟件bug的功能。
3、 APP 監理工程師功能需求
(1)登錄/登出模塊
在登錄系統時負責核驗操作人員的身份信息，保證系統數據安全，并提供登出 功能，保證無賬號人員不得對系統數據進行操作。
(2)人員管理模塊 監理工程師可查看其管轄范圍內的所有現場設施設備操作人員以及每位操作 人員的詳細信息。
(3)申請展示模塊 監理工程師可查看其管轄范圍內的所有現場設施設備操作人員的每一次開關 機申請記錄，并對每一次開關機申請操作進行審核和批準。
(4)個人中心模塊
提供修改頭像、修改密碼、提供檢查版本更新和上報軟件bug的功能。
圖 3.8 所示是系統用例圖。
28
圖 3.8 系統用例圖
以下將對系統的 WEB 端和 APP 端各功能模塊的需求進行詳盡的介紹。
3.3.2 WEB 端功能需求
通過對滇池藍藻打撈處置流程的綜合性需求分析，系統的 WEB 端主要分為： 登錄/登出模塊，運維管理模塊，運營統計模塊，后臺管理模塊，和個人中心模塊 五個部分。
(1)登錄/退出模塊
滇池藍藻防控處置信息管理系統 WEB 端登錄/退出功能模塊功能需求如圖 3.9 所示。
1)賬號注冊：當出現新的操作人員操作 WEB 端系統時，系統將引導其完成賬 號注冊步驟。
2)賬號登錄：當操作人員操作 WEB 端系統時，都需要通過登錄已注冊的賬號 這一步驟進行身份驗證程序，保障系統的安全性。
29
3）賬號登出：當操作人員準備離開WEB端系統時，都需要進行已登錄賬號的 登出步驟，保障系統的安全性。
（2）運維管理模塊
運維管理模塊是滇池藍藻防控處置信息管理系統 WEB 端的重要功能模塊之 一，該模塊中詳細記錄了滇池藍藻防控處置專業部門所管轄的各類除藻設備、防 控設備、機械打撈設備等設備的詳細信息，以及設備管理人員申請開關機的詳細 記錄，監理工程師批準開關機申請的詳細記錄，設備管理人員每日上傳的運行日 報表詳細記錄。
運維管理模塊功能需求如圖3.10 所示。
運維管理模塊
圖 3.10 運維管理模塊功能結構圖
1） 設備管理：記錄所管轄的各類除藻設備、防控設備、機械打撈設備、輔助 設備的詳細信息。并可對設備進行增、刪、改、查操作。
2） 開/關機申請記錄：可以查看管轄范圍內所有設備管理人員每次開/關機的申 請記錄，湖泊管理方操作人員可對開/關機申請記錄進行查詢操作。
3） 開/關機審核記錄：可以查看管轄范圍內所有監理工程師每次審核開/關機的 申請的記錄，操作人員可對審核開/關機申請的記錄進行查詢操作。
4） 運行日報表上報記錄：可以查看管轄范圍內所有設備管理人員每次運行日 報表上傳的記錄，操作人員可對運行日報表上傳的記錄進行查詢、審核操作。
運維管理模塊用例分析如圖3.11 所示。
30
（3）運營統計模塊
運營統計模塊是滇池藍藻防控處置信息管理系統 WEB 端的重要功能模塊之 一，該模塊主要負責對后臺數據庫的各類數據進行統計分析，內嵌有繪圖框架， 方便系統操作人員將需要的各種報表數據一鍵導出，生成所需要的各類統計圖表 （柱狀圖、餅狀圖、折線圖）。
運營統計模塊功能需求如圖 3.12 所示。
運營統計模塊
圖 3.12 運營統計模塊功能結構圖
1） 開/關機申請統計：湖泊管理方操作人員可以按條件進行篩選，統計出符合 指定條件的開/關機記錄。
31
2)審批情況統計：湖泊管理方操作人員可以按條件進行篩選，統計出符合指 定條件的審批記錄。
3)設備運行情況統計：湖泊管理方操作人員可以按屬性條件進行篩選，分別 統計除藻設備、防控設備、機械打撈設備、輔助設備四類設備的詳細運行情況。
4)運營數據情況統計：湖泊管理方操作人員可以按屬性條件進行篩選，分別 統計出累計耗油量，累計耗電量，累計抽水量等詳細數據信息。
5)統計數據導出：湖泊管理方操作人員可以按條件選擇需要導出的數據，然 后一鍵導出為 Excel 表格等格式。
6)統計圖表繪制：湖泊管理方操作人員可以按條件選擇需要繪制的數據，并 選擇所需繪制的圖表形式，然后一鍵繪制。
7)歷史數據下載：湖泊管理方操作人員可以進行搜索，選擇需要的歷史數據 進行下載。
運營統計模塊用例分析如圖 3.13 所示。
圖 3.13 運營統計模塊用例圖
(4)后臺管理模塊 后臺管理模塊提供有菜單管理、后臺管理員管理、系統信息查看等功能。
32
后臺管理模塊功能需求如圖3.14所示。
后臺管理模塊
圖 3.14 后臺管理模塊功能結構圖
1)菜單管理：湖泊管理方的操作人員可以根據自己的工作需求，自由的增加 或減少菜單顯示內容。
2)角色管理：湖泊管理方的操作人員可以對角色進行管理。
3)后臺管理員管理：湖泊管理方的操作人員可以手動添加或者刪除后臺管理 人員，也可以對后臺管理人員的操作權限進行分配。
4)人員類型管理：湖泊管理方的操作人員可以進行人員類型的管理，可以手 動添加或者刪除設備管理人員、監理工程師，也可以手動變更人員的身份信息。
5)系統信息查看：湖泊管理方的操作人員可以查看系統的版本信息。
后臺管理模塊用例分析如圖 3.15 所示。
圖 3.15 后臺管理模塊用例圖
33 3.3.3 移動 APP 端 通過對滇池藍藻打撈處置流程的綜合性需求分析，系統配套的現場操作人員移 動 APP 端主要分為兩個版本：設備管理人員版本和監理工程師版本。下面將分別 闡述兩個版本的功能需求。
3.3.2.1移動端一APP設備管理人員功能需求
移動端 APP 設備管理人員功能需求主要分為：登錄/登出模塊，開/關機申請模 塊，日志上報模塊和個人中心模塊四個部分。
（1）登錄/登出模塊
滇池藍藻防控處置信息管理系統移動端APP設備管理人員版本登錄/登出功能 模塊功能需求如圖 3.16 所示。
登錄/登出模塊
圖 3.16 登錄/登出模塊功能結構圖
1） 賬號注冊：當現場出現新的設施設備管理人員操作移動端APP設備管理人員 版本時，將引導其完成賬號注冊步驟。
2） 賬號登錄：每次當設施設備管理人員操作移動端APP設備管理人員版本時, 都需要通過登錄已注冊的賬號這一步驟進行身份驗證程序，保障系統的安全性。
3） 賬號登出:每次當設施設備管理人員準備離開移動端APP設備管理人員版本 時，都需要進行已登錄賬號的登出步驟，保障系統的安全性。
（2）開/關機申請模塊
開/關機申請模塊是滇池藍藻防控處置信息管理系統移動端APP設備管理人員 版本的重要功能模塊之一，設備管理人員通過該模塊填報相應的現場信息，進行 開/關機操作的申請。監理工程師審批時限為15分鐘，15分鐘以內，監理工程師 通過觀察設備管理人員所上報的開/關機申請，審核是否達到需要進行藍藻打撈任 務/已近完成藍藻打撈任務，待監理工程師審核通過后，設備管理人員方能進行開/
34
關機操作；若審核不通過，則不能進行相應的操作。若 15 分鐘內監理工程師未進 行審核，則該開/關機申請將會發送到湖泊管理方，由湖泊管理方人員進行審核。 若超過 30 分鐘都未有審核通知，則設備管理人員無需等待審批結果，可以自行進 行開/關機操作。
開/關機申請模塊功能需求如圖3.17所示。
開/關機申請模塊
圖 3.17 運維管理模塊功能結構圖
1)申請填寫：設備管理人員到達現場后，通過進行現場定位、拍照，申請開/ 關機理由的填寫，進行開/關機的申請操作。
2)歷史申請：設備管理人員在歷史申請中，可以看到其每一次開/關機申請操 作的詳細記錄信息。
開/關機申請模塊用例如圖 3.18 所示。
圖 3.18 開/關機申請模塊用例圖
(3)日志上報模塊
35
日志上報模塊是滇池藍藻防控處置信息管理系統移動端 APP 設備管理人員版 本的重要功能模塊之一，現場設施設備管理人員完成一天的藍藻打撈處置任務之 后，需要在日志上報模塊，填寫當天作業的各種信息，上傳到湖泊管理方，進行 匯總統計歸檔。
日志上報模塊功能需求如圖 3.19 所示。
圖 3.19 日志上報模塊功能結構圖
1)日志填報：每次當設備管理人員完成一天的藍藻打撈處理工作之后，需要 進行日志填報。
2)歷史上報：設備管理人員在歷史上報中，可以看到其每一次運行日志填報 的詳細記錄。
日志上報模塊用例分析如圖 3.20 所示。
36
(4)個人中心模塊 個人中心模塊，為設備管理人員提供一系列的個性化設置，包括;設置頭像，
修改用戶名，修改登錄密碼，查看APP版本號，上報APP的BUG的功能。 個人中心模塊功能需求如圖 3.21 所示。
1)設置頭像：設備管理人員可以將頭像用喜歡的圖片替換。
2)修改用戶名：設備管理人員可以重新修改自己賬號的用戶名。
3)修改登錄密碼：設備管理人員可以重新修改自己賬號的登錄密碼。
4)查看APP版本號：設備管理人員可以在個人中心模塊查看APP對應的版本 號。
5)上報APP的BUG：設備管理人員在日常使用過程中遇到APP的BUG可以 在個人中心模塊進行使用 BUG 的上報。
個人中心模塊用例分析如圖3.22 所示。
37
圖 3.22 個人中心模塊用例圖
3.3.2.2移動端一APP監理工程師功能需求
移動端 APP 監理工程師功能需求主要分為：登錄/登出模塊，人員管理模塊， 申請展示模塊和個人中心模塊四個部分。
(1)登錄/登出模塊
滇池藍藻防控處置信息管理系統移動端APP監理工程師版本登錄/登出功能模
塊功能需求如圖3.23 所示。
登錄/登出模塊
圖 3.23 登錄/登出模塊功能結構圖
1)賬號注冊：當出現新的監理工程師操作移動端 APP 監理工程師版本時，將
引導其完成賬號注冊步驟。
38
2)賬號登錄：每次當監理工程師操作移動端 APP 監理工程師版本時，都需要 通過登錄已注冊的賬號這一步驟進行身份驗證程序，保障系統的安全性。
3)賬號登出：每次當監理工程師準備離開移動端 APP 監理工程師版本時，都 需要進行已登錄賬號的登出步驟，保障系統的安全性。
(2)人員管理模塊
人員管理模塊為滇池藍藻防控處置信息管理系統移動端 APP 監理工程師版本 的重要功能模塊之一。監理工程師可以通過人員管理模塊查看到其所負責管轄的 所有設備管理人員以及每位人員的詳細情況。
人員管理模塊功能需求如圖3.24所示。
人員管理模塊
圖 3.24 人員管理模塊功能結構圖
1)人員列表：監理工程師可以在人員列表列表界面看到其所管轄范圍內所有 的設備管理人員名單。
2)人員詳情：監理工程師可以點擊查看每一個設備管理人員的詳細情況。
3)人員設備：監理工程師可以查看到其所管轄的每一個設備管理人員所操作 設備的具體情況。
人員管理模塊用例分析如圖 3.25 所示。
39
(3)申請展示模塊
申請展示模塊為滇池藍藻防控處置信息管理系統移動端 APP 監理工程師版本 的重要功能模塊之一。監理工程師可以通過申請展示模塊查看到其所負責管轄的 所有設備管理人員的每一次開/關機申請，可以點擊查看每一個設備管理人員的開/ 關機申請理由，并進行開/關機申請的審核。
申請展示模塊功能結構如圖3.26所示。
申請展示模塊
圖 3.26 申請展示模塊功能結構圖
1)開/關機申請列表：監理工程師在開關機申請列表里可以看到所管轄范圍內 每一個設備管理人員的每一次的申請記錄。
2)開/關機詳情展示：監理工程師可以查看所管轄范圍內的每一個設備管理人 員的每一次在開關機申請記錄。
3)開/關機審核：監理工程師需要對查看的開/關機申請進行審核，點擊同意進 行該操作，或者拒絕該操作申請。
申請展示模塊用例如圖 3.27 所示。
40
(4)個人中心模塊 人中心模塊為監理工程師提供一系列的個性化設置，包括：設置頭像，修改用
戶名，修改登錄密碼，查看APP版本號，上報APP的BUG的功能。 個人中心模塊功能需求如圖 3.28 所示。
個人中心模塊
圖 3.28 個人中心模塊功能結構圖
1)設置頭像：監理工程師可以將頭像用喜歡的圖片替換。
2)修改用戶名：監理工程師可以重新修改自己賬號的用戶名。
3)修改登錄密碼：監理工程師可以重新修改自己賬號的登錄密碼。
4)查看APP版本號:監理工程師可以在個人中心模塊查看APP對應的版本號。
5)上報APP的BUG：監理工程師在日常使用過程中遇到APP的BUG可以在 個人中心模塊進行使用BUG的上報。
個人中心模塊用例如圖 3.29 所示。
41
3.3.4服務器性能需求 服務器是系統開發過程中一個十分重要的部分，由于有海量的數據需要進行存
儲，同時服務器又需要為各個模塊提供訪問服務，這樣無疑對滇池藍藻防控處置 信息管理系統的服務器提出了嚴苛的要求。
服務器性能需求為：
1)要能進行長期穩定的連續性不間斷服務。
2)要能穩定安全的存貯系統的海量數據。
3)要能提供安全、高效的數據訪問服務。
3.4非功能性需求分析
所謂非功能性需求，是指在滿足實現功能性需求的基礎上，再次將系統已有的
功能做進一步的優化和提升。由于滇池藍藻防控處置信息管理系統的包含有兩個 部分，一個部分是WEB端，一個部分是APP端，故系統的非功能性需求需結合 兩個部分進行完整的考慮，以下為系統的非功能性需求：
1.系統的可用性。滇池藍藻防控處置信息管理系統能夠長效、平穩、安全地運 行，確保用戶能夠正常地操作系統，獲取所需的數據信息。
2.系統的安全性。由于滇池藍藻防控處置信息管理系統屬于內部系統，系統數 據庫中包含有滇池湖泊管理公司歷年的歷史數據，這些數據都屬于企業內部資料 且都有一定的保密級別，不能隨意被外部人員獲取和使用。因此，需要對用戶的 合法性以及操作權限進行驗證，以保證系統數據資料的安全。
3.系統的兼容性。由于滇池藍藻防控處置信息管理系統的一個組成部分為 APP 端，對于APP端使用人員來說，大部分操作人員使用的手機系統均為Android系 統，而 Android 系統因版本更新迭代過快，操作人員使用的 Android 系統版本可能 從 Android7—Android11 都有，因此要求本系統的 APP 具有極強的兼容性，需要 讓不同系統版本的Android手機都能流暢運行該軟件。
4.系統的擴展性。由于本系統體量比較龐大，用戶對于本系統的需求和依賴程 度也較高，所以本系統的生命周期會比一般系統長很多。因此在系統較長的生命 周期內，用戶對于系統的需求可能會不斷的變化，所以為了滿足用戶對系統的需 求，系統的版本迭代和升級將會變得十分的常見，這就要求系統擁有極強的擴展 性，方便后期開發人員對系統進行升級和維護。
42
5.人性化的可視化界面展示，由于系統的服務對象是用戶，所以用戶的操作體 驗從一定程度上決定了系統的生命周期。所以功能的簡潔明快，顏色的舒心怡人， 操作模塊的清晰明了，將會從極大程度上大幅提高操作用戶的使用便捷性和舒適 性。所以要更多的從操作用戶的使用習慣、實際需進行考慮，這樣才能保證操作 用戶的實際操作體驗，也一定程度上降低了后期返工的概率。
3.5 本章小結
本章從滇池藍藻打撈處置過程的實際需求入手，深入分析了目前滇池藍藻打撈 處置流程中存在的各類問題，從滇池藍藻打撈處置工作的業務流程入手，根據實 際需求，收集整理各類數據資料，確定了整個系統的功能框架以及性能要求。
43
44
第四章 滇池藍藻防控處置信息管理系統設計
4.1系統設計原則
滇池藍藻防控處置信息管理系統的設計應遵循以下原則：
1.可靠性 建立以可靠性為核心的質量標準是確保系統能高質量完成的基礎，滇池藍藻防
控處置信息管理系統的可靠性標準包括四個方面：成熟性、易恢復性、容錯性和 依從性。
成熟性：指滇池藍藻防控處置信息管理系統避免因錯誤的發生而導致失效的能 力。
易恢復性：滇池藍藻防控處置信息管理系統失效并重新恢復數據的能力。 容錯性：在滇池藍藻防控處置信息管理系統發生故障時，系統保持特定性能的 能力。
依從性：滇池藍藻防控處置信息管理系統依附于可靠性相關的標準、約定和規 約的能力。
2.健壯性
性能因素、成本因素和質量因素三大因素統稱為軟件的健壯性。滇池藍藻防控 處置信息管理系統的健壯性設計將從以下兩個方面進行體現：
第一個方面—系統平臺的健壯性：滇池藍藻防控處置信息管理系統可以正確地 運行在不同平臺的環境下。
第二個方面—系統模塊級的健壯性：滇池藍藻防控處置信息管理系統內部有保 護機制，可實行自檢錯誤，保證執行結果的正確性。
3.可修改性 可修改性指能夠以最少的時間成本修改系統的功能。由于滇池藍藻防控處置信
息管理系統將會長期運行，在后續使用中可能會對系統的功能提出新的需求，于 是從以下方面對系統的可修改性進行了設計。
（1） 運用“模塊化”的設計思想，單個模塊只負責單個功能，避免出現變更時 因模塊職責過多而造成的繁瑣；
（2） 規定接口調用的規范，修改相關服務只進行局部化修改，不再對上層服
45
務進行修改。
（3）降低模塊與模塊之間的依賴性，類與類之間的連通通過第三方類來完成。
4.先進性
程序的先進性是指程序的界面友好、算法合理、技術先進、功能豐富。為保障 滇池藍藻防控處置信息管理系統的先進性，將會在開發過程中采用最前沿的開發 技術，在開發過程中將程序與硬件間之間的功能調用降低到最低，減少軟件運行 中的硬件資源浪費。
4.2系統安全性設計
系統的安全性是一個系統的立根之本，關乎到一個系統的存在價值，不具有安 全性的系統就像一間沒有門的屋子。最為容易被網絡黑客竊取到其中存放的資料。 滇池藍藻防控處置信息管理系統的安全性設計將從以下幾個方面進行實現。
4.2.1驗證碼驗證
由于當今世界有很多網絡黑客會利用機器人進行賬號的批量注冊，用注冊生成 的賬號同時大批量的向后端傳送無意義的數據，占用系統的帶寬，致使服務器崩 潰。所以為了避免上述情況的發生，本系統在登錄過程中加入了驗證碼驗證的步 驟。創建一個固定寬和高的正常的圖片，從 A-Z 的 26 個大寫字母和 0-9 的 10 個 數字中隨機地抽取 4 個字符填入到圖片中，同時對 4 個字符傾斜的角度進行調整， 然后再把調整的字符經過光學扭曲并加入許多干擾點，便生成圖像驗證碼，其中 抽取的 4個字符會保存在服務器的 session 中。系統將用戶輸入的與服務器中 session 保存的驗證碼比對，只有比對一致，才能完成登錄。同時，完成比對的驗證碼圖 片會立即銷毀，防止同一個驗證碼多次出現。人眼在辨別圖像驗證碼時已經十分 困難，故而加入驗證碼驗證的步驟可以防止網絡黑客利用賬號對系統服務器進行 破壞。在登錄過程中加入驗證碼驗證的過程也是目前主流網站采用最多的賬號驗 證方式。圖 4.1 是驗證碼驗證的過程圖。
46
圖 4.1 驗證碼驗證過程
4.2.2Session 限時
由于 HTTP 協議是一種無狀態的協議，所以在服務端，為了能準確記錄用戶的 狀態信息，需要用Session來識具體的用戶，將Session與用戶的ID進行綁定。服 務器中的Session會記錄用戶的具體操作內容，例如：具體的登錄時間，提交修改 的具體信息等等。由于Session會自動記錄用戶登錄的具體時間以及未進行操作的 時間周期。利用Session的這一特性，給Session設置一個較短的過期時間，當達 到所設置的過期時間之時，系統就會自動刪除對應時間段內符合條件的用戶 Session，這樣下一次用戶進行系統的操作，就需要再次輸入密碼進行身份驗證， 這樣就能一定程度上防止用戶在關閉系統時，因忘記登出賬號，而造成信息泄密 的隱患，從一定程度上進一步保護了系統中存放資料的信息安全。
4.3 數據庫設計
4.3.1 數據采集與處理
滇池藍藻防控處置信息管理系統所涉及的數據種類十分復雜且數據量較為龐 大，需要將滇池藍藻防控處置歷年來存儲的各類數據的原始數據表格等紙質文件 進行分類整理，再將部分以 Excel 表格等形式存儲的統計文件中的數據取出，將兩 個部分的文件進行匯總，再做最后的分類整理，這樣才能得到完整的歷史數據資 料。
藍藻防控運行管理數據主要包括以下幾個方面：
（1）除藻設備：運行日期、開機時間、關機時間、關機原因、耗油量、耗電
47
量、水處理量（立方米）、藻泥處理量（噸）、開機流量、關機流量、設施保養 情況和備注信息。
（2）防控設備：設備編號、設備名稱、設備維修時間、安全生產情況、設備 保養時間和其他內容。
（3）機械打撈設備：設備號、設備名稱、運行日期、開機時間、關機時間、 關機原因、設備維修保養情況、排水量（立方米）、領油量、耗油量（L）、運行人 員和其他信息。
（ 4）輔助設備：設備名稱、除藻地點、運行日期、開機時間、關機時間、關 機原因、單日運行時間、單日抽水量、累積抽水量、設備維修情況、耗油量（L）、 除藻泥量（噸）、運行人員和其他信息。
4.3.2 數據庫設計
滇池藍藻防控處置信息管理系統的核心功能就是對在藍藻打撈處置過程中產 生的各種數據進行有效的管理。滇池藍藻防控處置管理單位的操作人員需要用滇 池藍藻防控處置信息管理系統進行各類數據的導入導出，設備管理人員和監理工 程師則會通過移動終端 APP 填報運營數據（包括打撈量、耗油量、耗電量等）， 這些數據都會被保存到數據庫中。由此可見，數據庫的設計需要十分合理。數據 庫的設計包含概念設計和表結構設計兩個部分。
4.3.2.1 概念設計
數據庫的概念設計，即抽象提取實體與現象對應要素的過程。在要素的提取前， 需明確實體與實體對應屬性之間的關系。數據庫的概念設計既要做到合理又要做 到全面，因為只有這樣，才能正確表達數據的空間關系特征和數據的動態與多維 特征，也才能夠正確的分析和處理數據［24］。
在概念設計的過程中，本文采用E-R（實體-聯系）模型，來表示抽象出來的實體
與實體屬性以及與實體之間的關系。下圖 4.2、 4.3、 4.4、 4.5表示的是除藻設備、
防控設備、機械打撈設備和輔助設備的實體屬性圖及數據庫的E-R圖。
48
圖 4.3 防控設備實體-屬性圖
圖 4.4 機械打撈設備實體-屬性圖
49
圖 4.6 系統 E-R 圖
4.3.2.2 數據庫表結構設計
表結構設計是數據庫能否達到設計需要求的關鍵。根據滇池藍藻打撈處置工作 的實際應用需求，本論文將構建多個表結構。但限于篇幅有限，且表結構眾多， 在下文只羅列出部分表結構。
表 4-1 除藻地點數據結構表
序號 別名 字段名 字段類 型 長度 默認 值 是否主 鍵 是否必 填
1 唯一標識 id int 11 是 是
2 地點名稱 name varchar 50 否 是
50
3 經度 longitude decimal 20 否 否
4 緯度 latitude decimal 20 否 否
5 創建時間 create_time datetime 8 當前 時間 否 是
6 備注 remarks varchar 100 否 否
7 用戶類型 type tinyint 2 否 是
8 創建用戶 user id int 11 否 是
9 創建用戶 姓名 user_name varchar 10 否 是
［注:decimal型數據精確到小數點后7位，即可精確到1 cm。］
表 4-2 維修保養數據結構表
序號 別名 字段名 字段類
型 長度 默認值 是否主 鍵 是否必 填
1 唯一標 識 id int 11 是 是
2 維修保 養名稱 name varchar 30 否 是
3 創建用 戶 user_id int 11 否 是
4 創建用 戶姓名 user_name varchar 10 否 是
5 創建時 間 create_time datetime 8 當前時 間 否 是
6 備注 remarks varchar 100 否 否
7 用戶類
型 type tinyint 2 否 是
表 4-3 停機原因數據結構表
序號 別名 字段名 字段類
型 長度 默認值 是否主 鍵 是否必 填
1 唯一標 識 id int 11 是 是
2 停機原 因名稱 name varchar 30 否 是
3 用戶類 型 type tinyint 2 否 是
4 創建用 戶 user_id int 11 否 是
5 創建用 戶姓名 user_name varchar 10 否 是
6 創建時 間 create_time datetime 0 當前時 間 否 是
7 備注 remarks varchar 100 否 否
51
表 4-4 班次數據結構表
序號 別名 字段名 字段類 型 長度 默認值 是否主 鍵 是否必 填
1 唯一標 識 id int 11 是 是
2 班次名 稱 name varchar 11 否 是
5 備注 remarks varchar 100 否 否
表 4-5 藻泥外運處置數據結構表
序號 別名 字段名 字段類 型 長度 默認值 是否主 鍵 是否必 填
1 唯一標 識 id int 11 是 是
2 來源類 型 type tinyint 2 否 是
3 藻泥來 源 source_id int 11 否 是
4 藻泥去 向 direction id int 11 否 是
5 車牌號 car plate varchar 10 否 否
6 毛重 hair weight double 0 否 否
7 皮重 skin weight double 0 否 否
表 4-6 藻站數據結構表
序號 別名 字段名 字段類型 長度 默認 值 是否 主鍵 是否 必填
1 唯一標識 id int 11 是 是
2 所屬藻站 algalsites id int 11 否 是
3 運行時長 duration int 11 否 是
4 日期 time datetime 0 否 是
5 聚合氯化 鋁 pacl double 16 否 否
6 聚丙烯酰 胺 pam double 16 否 否
7 水處理量
（m3） dewatering double 16 否 否
8 藻泥處理
量（ t） algal_mud double 16 否 否
9 外運/車次 external number int 11 否 否
10 開機時間 open_time datetime 8 當前 時間 否 否
11 停機時間 end_time datetime 8 停機 時間 否 否
12 值班人 id duty user id int 11 否 是
52
13 值班人姓 名 duty_user_name varchar 10 否 是
14 開機流量 open flow double 16 否 否
15 關機流量 end flow double 16 否 否
16 維修保養 情況 maintain_content varchar 100 否 否
［注: double 型數據精確到小數點后 2 位］
表 4-7 藻車數據結構表
序號 別名 字段名 字段類型 長度 默認 值 是否 主鍵 是否 必填
1 唯一標識 id int 11 是 是
2 所屬藻車 algalcar id int 11 否 是
3 運行時長 duration int 11 否 是
4 日期 time datetime 0 否 是
5 聚合氯化 鋁 pacl double 16 否 否
6 聚丙烯酰 胺 pam double 16 否 否
7 領油量
（L） receive_oil double 16 否 否
8 耗油量
（L） consume_oil double 16 否 否
9 耗電量 （KW/h） consume_electricity double 16 否 否
10 水處理量
（m3） dewatering double 16 否 否
11 藻泥處理
量（ t） algal_mud double 16 否 否
12 外運/車次 external number int 11 否 否
13 開機時間 open_time datetime 8 當前 時間 否 否
14 停機時間 end_time datetime 8 停機 時間 否 否
15 值班人 id duty user id int 11 否 是
16 值班人姓 名 duty_user_name varchar 10 否 是
17 開機流量 open flow double 16 否 否
18 關機流量 end flow double 16 否 否
19 維修保養 情況 maintain_content varchar 100 否 否
［注: double 型數據精確到小數點后 2 位］
表 4-8 藻船數據結構表
序號 別名 字段名 字段類型 長度 默認 是否 是否
53
值 主鍵 必填
1 唯一標識 id int 11 是 是
2 所屬藻船 algalship id int 11 否 是
3 運行時長 duration int 11 否 是
4 日期 time datetime 8 否 是
5 聚合氯化 鋁 pacl double 16 否 否
6 聚丙烯酰 胺 pam double 16 否 否
7 加油量
（ L ） receive_oil double 16 否 否
8 耗油量
（ L ） consume_oil double 16 否 否
9 水處理量
（ m3） dewatering double 16 否 否
10 藻漿量
（ L ） algal_slurry double 16 否 否
11 耗電量 （ KW/h ） consume_electricity double 16 否 否
12 開機時間 open_time datetime 0 當前 時間 否 否
13 停機時間 end_time datetime 0 停機 時間 否 否
14 停機次數 shut-down times int 10 否 是
15 審核人 id review user id int 11 否 是
16 審核人姓 名 review_user_name varchar 10 否 是
17 記錄人 id record user id int 11 否 是
18 記錄人姓 名 record_user_name varchar 10 否 是
19 維修保養 情況 maintain_content varchar 100 否 否
4.4系統功能設計
系統的功能模塊嚴格按照第三章系統功能需求分析來進行設計，滇池藍藻防控 處置信息管理系統主要分為兩個部分：WEB端和移動終端APP。滇池藍藻防控處 置信息管理系統的主要功能結構如圖 4.7 所示。
54
串帶聊架 q
—
莊除聊架
卜 池百誡■&曲卅過 卜
| 池百就冊汀卅田P |劑百茁h■州苗r□了倩卜
斗弗珈冊曲卅逆 h
斗帶肖施法冊 U
斗第崗施了倩甌萍卜
圧如訥暮斗腎 P
世谿泮畫斗腎 p
婢TS&塔冷卻 卜
帽呻別幅niRUflB
圖 4.7 系統功能結構圖
55
4.4.1 WEB 端模塊設計
1、運維管理模塊
運維管理模塊是對與設備管理人員申請開/關機操作記錄，監理工程師審核開/ 關機操作記錄，設備管理人員上傳運行日報表數據的管理，模塊提供查看、按條 件查詢、排序等功能。
管理方的工作人員查看到信息處理的狀態，對開/關機記錄申請不規范，開/關 機審核審批延誤，運行日報表上報記錄有問題的人員，可以責令其整改，加強了 監督的力度和監督的實效性。
如圖 4.8 所示是運維管理模塊的流程圖。
圖 4.8 運維管理模塊流程圖
2、運營統計模塊
運維管理模塊是對與滇池管理方管轄范圍內所有設備、人員有關記錄的整體匯 總，模塊提供查看、按條件查詢、排序等功能。例如可用耗油量、耗電量等作為 篩選條件進行查詢，查詢到的結果以報表的形式呈現，可一鍵導出記錄報表，報
56
表格式為Word文本、Excel表格。也可一鍵生成各類圖表（折線圖、餅狀圖、柱 狀圖等）。
系統操作人員可根據統計的結果，評判打撈運行等情況，也方便工作人員做各 類信息、資料的匯總。
如圖 4.9 所示是運營統計模塊的流程圖。
圖 4.9 運營統計模塊流程圖
3、后臺管理模塊 后臺管理模塊為滇池湖泊管理方的工作人員提供了各類后臺權限管理，可以進 行菜單的個性化定制；角色、后臺管理員的修改編輯操作、人員類型的查詢修改、 系統信息查看等功能。
如圖 4.10 所示是后臺管理模塊的流程圖。
57
圖 4.10 后臺管理模塊流程圖
4.4.2 APP 端模塊設計
1、開/關機申請模塊： 開/關機申請模塊為設備管理人員提供開/關機申請，開/關機歷史申請記錄查看 的功能。
如圖 4.11 所示是開/關機申請模塊的流程圖。
58
圖 4.11 開/關機申請模塊流程圖
2、日志上報模塊 日志上報模塊為設備管理人員提供日志上報，日志上報歷史記錄查看的功能。 如圖 4.12所示是日志上報模塊的流程圖。
59
圖 4.12 日志上報模塊流程圖
3、人員管理模塊 人員管理模塊為監理工程師提供人員查看的功能。 如圖 4.13 所示是人員管理模塊的流程圖。
圖 4.13 人員管理模塊流程圖
4、申請展示模塊 申請展示模塊為監理工程師提供開/關機申請詳情展示，日開/關機申請審核的 功能。
如圖 4.14 所示是申請展示模塊的流程圖。
60
圖 4.14 申請展示模塊流程圖
4.5本章小結
本章對滇池藍藻防控處置信息管理系統的設計做了詳盡的介紹，并與需求進行 結合，完成了整個系統的功能設計。
61
62
第五章 系統實現
5.1系統概述
本文針對昆明滇池藍藻打撈處置工作的實際需求，設計開發了滇池藍藻防控處 置信息管理系統，系統包括兩個部分：WEB端和移動終端APPo其中移動終端 APP 分為兩個版本：設備管理人員版本，供設備管理人員使用；監理工程師版本， 供監理工程師使用。通過WEB端與APP端的聯動，做到了數據的及時傳遞，有 效的提升了打撈處理藍藻的效率。
5.2WEB 端
系統的WEB端使用pycharm作為開發工具，綜合使用HTML技術、CSS3技 術、JavaScript語言、python技術、Mysql數據庫、Bootstrap前端開發框架進行設 計與開發，從而實現系統桌面端的用戶交互體驗。
WEB 端包括登錄/登出模塊、運維管理模塊、運營統計模塊、后臺管理模塊四 個部分。運維管理模塊主要是實現對開/關機申請記錄、開/關機審核記錄、運行日 報表上報記錄的管理，湖泊管理單位的操作人員可以通過瀏覽器訪問滇池藍藻防 控處置信息管理系統，并對上述業務數據進行相應的操作。運營管理模塊主要實 現對各類運營數據、開關機申請數據、審批情況、設備運行情況的分析和統計， 同時能讓湖泊管理單位的操作人員一鍵將數據生成所需要的統計圖并導出。后臺 管理模塊主要是對角色進行管理、對人員類型管理以及系統信息查看等功能。WEB 端的部分功能如圖所示。
(1)設備管理
在設備管理頁面中，操作人員可以看到湖泊管理方所管轄范圍內的所有設備， 設備種類包括除藻設備、防控設備、機械打撈設備等，可以查看每個設備的詳情， 也可以新增設備，對已有設備進行查詢和刪除操作。
63
設備名稱|請輯入鬧名稱
設詢號 清輸入設備編號
設備規樓 入®模
型
是否有涓井 請昭是或否
所在薛 欣入所在©3
備注 備注
確認創建
圖 5.1 設備管理界面
(2)開/關機申請記錄 在開關機申請記錄頁面，操作人員可以看到每一位設備管理人員的每一次申請 開/關機的詳細申請情況。
64
丹關機申裔5錄 內容 | sa
序號 電請人 申WT可 稱 申艇由 審蝕果 操作
語 2020-11-07 6:30:52 就分離車 申新機
2號 2020-11-07 8:46:34 蘑4號 申斷機 JWT^felk,懇請SS... 扌瞇申請
3號 2020-11-07 8:52:1? 號 申師機 拡齢請
4號 2020-11-07 8:55:02 軸號 申耕機 ©tWffeT作了” 請審... ftU歸請
5號 呂敏偉 2020-11-07 8:59:14 期號 申新機 播隹申請
6號 麗才 2020-11-07 9:10:37 加囲蹄 申餅機 申S5E—
« Q 2 3 4 5 »
圖 5.2 開/ 關機申請記錄界面
(3)開/關機審核記錄 在開/關機審核記錄界面，操作人員能看到每一位設備管理人員的每一次申請 的詳細審核情況。
開/關機審核記錄 |蹄心3內容 翻
序號 申請人 申嗣間 申舷作 闋乍
1號 珮陽 2020-11-07 8:30:52 申ffff機 2020-11-07 &38:17 雌申請
2號 £3^ 2020-11-07 8:46:34 申Sff機 2020-11-07 8:48:52 捋鉀請
3號 2020-11-07 &52:17 申師機 2020-11-07 9:01:48
4號 2020-11-07 &55:02 申師機 田國明 2020-11-07 8:57:09 扌彷鉀請
5號 呂敏偉 2020-11-07 8:59:14 申WT機 2020-11-07 9:04:37 掘薛請
6號 歸才 2020-11-07 9:10:37 申WR機 2020-11-07 9:24:56 at®# 請
65
(4)運行日報表上報記錄
在運行日報表上報記錄頁面，可以看到每一位設備操作人員每次作業任務完成 后所填寫的運行日報表，對于日報表填寫不規范，有問題的日表表，操作人員可 以點擊返回重填按鈕，命令設備操作人員重新填寫當次的運行日報表。
(5)開/關機申請統計
66
在統計界面，可以對各類數據進行統計，可以統計開/關機申請情況，統計審 批情況，統計設備運行的情況，統計運營數據的情況等。下面以開/關機申請統計 為例，在開/關機申請統計頁面，可以通過選擇年份、月份、設備管理員和操作四
個分類，進行不同的組合，分別統計不同時期，不同人員，不同操作的詳細情況。
序號 設®運行日期 ©SS稱 眸時問 杲
1號 張朝陽 2020-11-07 & 30:52 批準申請
2號 張朝陽 2020-11-07 潮｝;分帖 申請關機 17:28:53 申請
3號 王*泉 2020-11-07 8»4號 8:46:34 ttt*田請
4號 王永泉 2020-11-87 SE4號 申請關機 17:32:39 批準申請
5號 2020-11-07 酒2號 8:52:17 批準申請
6號 $S9 2020-11-07 趣2號 申請關機 17:35:23 申請
7號 耒金蘭 2020-11-07 滇廈f號 申機 8： 55:02 M*申請
3號 耒金蘭 2020-11-07 演廈1號 審清關機 17:41:09 tffiftffiS
9號 呂敏偉 2020-11-07 鯽傳 田®5W & 59:14 fiBtt田請
1皓 呂敏偉 2020-11-97 葩1號 申請關機 17;45:5t tttfiffiS
總計 正褚開機次SS: 7983次 正芾關舷數：7甜5次 異議開機次數：517次 異常關痕數：605次
圖 5.5 開/ 關機申請統計界面
(6)統計圖表繪制
在統計圖表繪制界面，操作人員可以選擇數據的種類，一鍵將數據繪制成指定
種類的圖表，并可以將圖表一鍵導出。
圖 5.6 統計圖表繪制界面
并將歷史數據下載到本機當中，也可以一次性選擇多個歷史數據，一鍵下載。
67
圖 5.7 歷史數據下載界面
(8) 角色管理 在角色管理頁面，操作人員可以看到整個系統中所有注冊用戶，可以查看每位 注冊用戶的個人信息，也可以對注冊用戶的身份進行變更，以及創建新的用戶。
角色管理 盂莎議 Si]
5.3APP 端
移動終端APP是整個滇池藍藻打撈處置工作的核心，是整個滇池藍藻防控處 置信息管理系統數據來源的途徑。移動終端APP的開發，使用Hbulider作為開發 工具，將MUI和HTML5+結合進行移動終端APP的開發。用戶界面通過MUI框 架完成構建，APP的功能通過HTML5+技術實現。
設備管理人員和監理工程師通過登錄APP后，點擊相應的圖標實現不同的功 能，達到實時的數據傳輸效果。移動終端 APP 部分功能如圖所示。 設備管理人員版本部分界面展示：
(1)設備管理人員版本登錄界面和注冊界面
設備管理人員可通過注冊界面注冊賬號。再通過登錄界面登錄自己的賬號，進 行相關的操作。
69
圖 5.9 登錄界面和注冊界面
(2)設備管理人員版本主頁界面 設備管理人員版本主界面有四個功能模塊，它們分別是開/關機申請填寫、歷 史申請記錄、運行日志填報和歷史上報。
開/關機申請填寫
我的
圖 5.10 設備管理員版本主頁界面
(3)開/關機申請界面和歷史申請記錄界面
設備管理人員通過填寫開/關機申請界面的內容，進行開/關機操作的申請。歷 史申請界面供設備管理人員查看其每一次開/關機申請的詳細內容。在歷史申請記
70
錄界面，設備管理人員可以對歷史申請記錄進行搜索，也可以對歷史申請進行排
序。
圖 5.11 開/關機申請界面和歷史申請記錄界面
(4)運行日志填報界面和歷史上報界面
設備管理人員完成一天的現場作業后，需要到日志填報界面填寫相關的作業情 況。歷史上報界面供設備管理人員查看其每一次運行日志填報的詳細內容。在歷 史上報界面，設備管理人員可以對歷史上報進行搜索和排序。
71
圖 5.12 運行日志填報界面和歷史上報界面
（5） 個人中心界面 設備管理人員版本的個人中心可以設置頭像，修改用戶名，修改登錄密碼，查 看 APP 版本號和上報 APP 的 BUG 。
我的
監理工程師版本部分界面展示：
(1)監理工程師版本主界面
監理工程師版本主界面有兩個功能模塊，它們分別是人員管理和申請管理。
藍藻防控管理系統(監理工程師)
圖 5.14 監理工程師版本主頁界面
(2)人員管理界面 監理工程師可以在人員管理頁面，看到其管轄范圍內的所有設備管理人員，以 及可以查看到每一位設備管理人員的詳細信息。監理工程師可對人員進行搜索和 排序。
73
Q
圖 5.15 人員管理界面
(3)開關機申請界面
監理工程師在開/關機申請列表頁，可以看到待審批的開、關機申請個數和已 超時的審批請求個數，以及查看到每一條開/關機的申請詳情。
; 開/關機申請列表頁
開機申請列表頁
關機申請歹俵頁
已超時審批列表頁 ?
圖 5.16 開/ 關機申請管理界面
74
5.4 系統測試
5.4.1 系統測試環境
表 5-1 系統測試環境
項目 測試環境
計算機操作系統 Windows10
瀏覽器 Google Chrome
數據庫 Mysql
WEB 應用服務器 Apache
移動端系統版本 Android 10
5.4.2系統測試結果
“滇池藍藻防控處置信息管理系統”由WEB端和APP端兩個部分構成，系統的 測試將會使用昆明滇池湖泊管理單位提供的實際數據作為測試用例，測試結果如 下表所示。
WEB 端模塊測試：
表 5-2 登錄登出模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
a-1 登錄、登出模 塊 登錄 已注冊賬號登錄 是
a-2 登出 已注冊賬號登出 是
a-3 注冊賬號 未注冊賬號注冊 是
表 5-3 運維管理模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
b-1 運維管理模塊 設備管理 對存在設備進行增、刪、改、 查操作 是
b-2 開/關機申請 記錄 對開/關機申請記錄進行查詢、 搜索操作 是
b-3 開/關機審核 記錄 對開/關機審核記錄進行查詢、 搜索操作 是
b-4 運行日報表上 報記錄 對運行日報表進行查詢、審核
操作 是
表 5-4 運營統計模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
c-1 運營統計模塊 開/關機申請 指定條件，進行開/關機申請的 是
75
統計 統計
c-2 審批情況統計 指定條件，進行審批情況的統 計 是
c-3 設備運行情況
統計 指定條件，進行設備運行情況 的統計 是
c-4 運營數據情況 統計 指定條件，進行運營數據情況 的統計 是
c-5 統計數據導出 選擇導出數據類型對指定數據
進行導出 是
c-6 統計圖表繪制 任意選擇指定數據進行圖表繪 制，對繪制的圖表類型進行不 同的選擇 是
c-7 歷史數據下載 任意選擇歷史數據進行單文件 下載和多文件下載 是
表 5-5 后臺管理模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
d-1 后臺管理模塊 菜單管理 對菜單功能進行增、刪、改、 查操作 是
d-1 角色管理 對用戶進行增、刪、改、查操
作 是
d-1 后臺管理人員 管理 對后臺管理人員進行增、刪、 改、查操作 是
d-1 人員類型管理 對人員類型進行搜索、修改操
作 是
d-1 系統信息查看 對系統信息進行查看 是
APP 端模塊測試：
表 5-6 登錄、登出模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
e-1 登錄、登出模
塊 登錄 已注冊賬號登錄 是
e-2 登出 已注冊賬號登出 是
e-3 注冊賬號 未注冊賬號注冊 是
表 5-7 開關機申請模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
f-1 開關機申請模 塊 申請填寫 填寫開/關機申請進行上報 是
f-2 歷史申請 查看歷史申請記錄 是
表 5-8 日志上報模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
g-1 日志上報模塊 日志填報 填寫日志進行上報 是
76
g-2 歷史上報 查看歷史日志記錄 是
表 5-9 個人中心模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
h-1 個人中心模塊 設置頭像 點擊個人信息欄，點擊頭像修
改 是
h-2 修改用戶名 點擊個人信息欄，點擊用戶名
修改 是
h-3 修改登錄密碼 點擊賬號與安全，點擊修改密
碼 是
h-4 查看APP版本 號 點擊關于軟件，查看版本號 是
h-5 上報 APP 的
bug 點擊上報BUG，上報使用中存 在的 BUG 是
表 5-10 人員管理模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
i-1 人員管理模塊 人員查看 點擊人員信息進行查看 是
i-2 撥打電話 點擊任意員工電話撥打 是
i-3 搜索 點擊搜索按鈕進行搜索 是
表 5-11 申請展示模塊測試
序號 模塊名稱 功能名稱 測試內容 是否通過測試
j-1 申請展示模塊 申請查看 分別點擊開機申請列表頁、關 機申請列表頁、已超時審批列 表頁 是
j-2 批準申請 點擊批準申請 是
j-3 拒絕申請 點擊拒絕申請 是
5.4.3非功能性測試 從可用性測試、兼容性測試、安全性測試、可擴展性測試以及人性化測試五種 測試完成對系統的非功能性測試：
(1)可用性測試：系統在測試過程中運行平穩，功能正常，反應迅速，沒有出 現崩潰等錯誤的發生。
(2)兼容性測試：系統在測試階段可以在不同系統版本的機器上順利的運行。
(3)安全性測試：測試過程中，系統在10 分鐘內沒有進行任何操作，自動清 除 session ，再次操作時需要重新進行賬號登錄的步驟。
(4)可擴展性測試：采用MTV架構模式設計的系統，系統的代碼復用性很高,
77
新功能的增加非常方便。
(5)人性化測試：在整個測試過程中，沒有任何測試人員反饋系統界面操作反 人性化，操作不便的信息。
5.5本章小結
本章詳細的介紹了系統WEB端和APP端的具體實現，對系統的功能性方面和 非功能性方面進行了測試，整個測試中系統運行正常，所有功能均可正常使用， 達到了設計預期實現的效果。
78
第六章 總結與展望
6.1總結
滇池藍藻防控處置信息管理系統是一個輔助藍藻打撈處置工作的信息管理平 臺，系統開發的目的是為了協助滇池藍藻打撈處置專業部門，提高藍藻打撈處置 工作的效率和為藍藻的防控處置提供可靠、全面的基礎數據和科學的決策支持。 本論文主要的工作內容如下：
(1)全方位地分析了昆明滇池湖泊管理單位在整個滇池藍藻打撈處置工作流程 中存在的問題，并對系統進行了全面的需求分析。
(2)為開發滇池藍藻防控處置信息管理系統，深入學習了 B/S架構模式、MTV 模式、python 語言、HTML5、CSS3、MySQL 數據庫、JavaScript 等技術。
(3)參與了與滇池藍藻防控處置相關過程有關數據的收集工作。
(4)設計并構建了穩定、安全、高效的滇池藍藻防控處置信息管理系統數據庫。
(5)運用python技術、HTML技術、MUI移動端開發技術、bootstrap框架，基 于MySQL數據庫，設計并開發了滇池藍藻防控處置信息管理系統。系統分為WEB 端和APP端兩個部分，實現了設備管理、統計圖表繪制、歷史數據下載、日志填 報、開/關機申請等功能，做到了數據的實時采集、傳輸和上報，實現了精細化的 管理與可視化的顯示。
6.2展望
設計研發的滇池藍藻防控處置信息管理系統仍然存在著很多需要完善的地方。
(1)系統的統計分析功能只做到了對收集到的數據進行統計和展示，并沒有對 數據進行更深層次的挖掘和分析。
(2)移動端APP與WEB端功能的開發還不夠完善，還有很大的發展空間。
79
80
參考文獻
[1]金棟梁.我國的湖泊水資源[J].人民長江,1986(09):64.
[2]胡明明，朱喜.中國淡水湖泊藍藻爆發現狀及其治理思路[A].中國環境科學學會、四川大 學.2014中國環境科學學會學術年會論文集(第五章)[C].中國環境科學學會、四川大學: 中國環境科學學會,2014:9.
[3]地表水環境質量評價辦法(試行)(環辦[2011]22號)
[4]劉俊杰,陸雋,朱廣偉,高鳴遠,聞亮,姚敏,聶青. 2009-2017年太湖湖泛發生特征及其影響因素
[J]. 湖泊科學,2018,30(05):1196-1205.
[5]張石文.滇池藍藻暴發原因及治理措施探討[J].科技創新與應用,2020(33):116-117.
[6]楊金艷.淺議入滇河道截污建設的思路[J].吉林水利,2010(10):55-59+68.
[7]黃君,張虎軍，江嵐,宋挺，戴敏.太湖藍藻水華預警監測綜合系統的構建[J].中國環境監 測,2015,31(01):139-145.
[8]陳紓楊，曹舒婭,林惠娟，趙巧華.蘇州太湖藍藻水華預測預警系統[A].中國氣象學會.第34 屆中國氣象學會年會S7水文氣象、地質災害氣象預報理論與應用技術論文集[C].中國氣 象學會:中國氣象學會,2017:6.
[9]周雷俊.基于JSCORS系統監測太湖藍藻現狀變化格局研究[A].江蘇省測繪地理信息學 會GPS、大地專業委員會、江蘇省測繪工程院JSCORS中心.2014年GPS、大地專業委員 會學術年會交流論文[C].江蘇省測繪地理信息學會GPS、大地專業委員會、江蘇省測繪 工程院 JSCORS 中心:《現代測繪》編輯部,2014:3.
[10]伊菲恩•雷斯，程冠飛.為什么藻華頻發?[J].中國三峽,2014(11):89-91.
[11]Mati Kahru,Ulrich Horstmann,Ove Rud,張康生.衛星監測的波羅的海藍藻菌大量繁殖:是自 然變動還是生態系統變化?[J].AMBIO-人類環境雜志,1994,23(08):469-472.
[12]Carmichael W. (2008) A world overview — One-hundred-twenty-seven years of research on toxic cyanobacteria — Where do we go from here?. In: Hudnell H.K. (eds) Cyanobacterial Harmful Algal Blooms: State of the Science and Research Needs. Advances in Experimental Medicine and Biology, vol 619. Springer, New York, NY. https://doi.org/10.1007/978-0-387-75865-7_4
[13]Dale Dzemydien6,Saulius Maskeliunas,Kim Jacobsen. Sustainable management of water resources based on web services and distributed data warehouses[J]. Ukio Technologinis ir
81
Ekonominis Vystymas,2008,14(1).
[14]羅瀟瀟.基于B/S結構的密封企業項目管理系統設計與實現[D].電子科技大學,2020.
[15]熊錦輝.基于B/S結構的學生信息管理系統的設計與實現[D].北京郵電大學,2013.
[16]鐘輝.基于Webservice的遠程教育系統的設計與實現[D].電子科技大學,2016.
[17]萬彩花.基于SOA和WebService的P2P網絡借貸管理系統的研究與實現[D].吉林大 學,2014.
[18]王勝男.基于WebService的整車物流管理系統的研究與實現[D].武漢理工大學,2014.
[19]劉原銘.基于Python的中小學云課堂平臺設計與實現[D].北京交通大學,2018.
[20]白相辰 基于Django框架的Web在線教育平臺的設計與實現[D].北京交通大學,2019.
[21]鄭成剛.基于Django的日程協作系統的設計與實現[D].大連理工大學,2014.
[22]趙君.基于Django框架的腦磁共振圖像的可視化平臺的設計和開發[D].東南大學,2018.
[23]賈帥.石林國家農業科技園區氣象信息管理系統設計與實現[D].云南大學,2019.
[24]唐巧玲.基于移動終端的城市快速路巡檢養護信息系統的設計與開發[D].云南大學,2019.
[25]陳青云.HTML5與CSS3技術在網頁制作中的應用及發展前景[J].信息與電腦(理論 版),2018(16):1-2.
[26]蔣 昀 昕 . 基 于 CSS3 媒 體 查 詢 的 響 應 式 布 局 研 究 [J]. 現 代 計 算 機 ( 專 業 版),2018(33):82-84+100.
[27]舒后,熊一帆，葛雪嬌.基于Bootstrap框架的響應式網頁設計與實現[J].北京印刷學院學 報,2016,24(02):47-52.
[28]林增坦.校園掌上圖書館HybridAPP的設計與實現[J].信息記錄材料,2018(10):91-93.
[29]賈軍營，張大成,高春.HybridApp開發框架的實現及性能優化[J].計算機系統應用,2017, 26(7):130-136.
[30]馮明.基于混合模式(Hybrid App)移動終端設計的方法[J].數字技術與應用, 2015(4):148-149.
[31]胡世港，田櫻.基于HTML5+技術的教學質量管理系統移動端APP的開發研究[J].電腦知 識與技術, 2015(21):23-25.
[32]汪佳佳.MUI在webAPP開發中的應用與研究[J].數碼世界,2016(10):70-71.
[33]韋劼群.交通信號控制系統的移動終端APP開發[J].廣西廣播電視大學學報, 2016,27(1):28-34.
82
[34]易劍波.基于MVVM模式的WEB前端框架的研究[J].信息與電腦,2016(19):76-77.
[35]陳巖.輕量級響應式框架Vue.js應用分析[J].中國管理信息化,2018(3):181-183.
[36]朱二華.基于Vue.js的Web前端應用研究[J].科技與創新,2017(20):119-121.
[37]麥冬,陳濤,梁宗灣.輕量級響應式框架Vue.js應用分析[J].信息與電腦(理論 版),2017(7):58-59.
[38]徐頔，朱廣華,賈瑤.基于VueJs的WEB前端開發研究[J].科技風,2017(14):69-69.
[39]Pan H H , Jiang J J , Chen L , et al. A Scalable Graphics User Interface Architecture for CNC Application Based - on WPF and MVVM[J]. Advanced Materials Research,2011, 317-319:1931-1935.
[40]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.
[41]白蕾，郭清菊，BAILei,et al. HTML5與CSS3的設計模式[J].智能計算機與應 用,2016(2):104-105.
[42]Pop D P,Altar A. Designing an MVC Model for Rapid Web Application Development[J]. Annals ofDaaam & Proceedings, 2013, 69(1):1172-1179.
[43]Niu D,Gao L. Based on the MVC model of teachers' workload management system development[C]// International Conference on Computer Science & Information Processing. IEEE, 2012.
[44]林麗清.一種MySQL數據庫SQL遞歸查詢的研究與實現[J].黑龍江科技信 息,2015(24):185-186.
[45]魏松，賀丹娜.基于MYSQL的學生信息管理系統數據庫設計[J].計算機光盤軟件與應 用,2012(14):207-207.
下一篇：沒有了
相關標簽:
