什么是災害應急救援平臺？災害應急救援平臺區別于人們司空見慣的安卓系統和iOS系統，災害應急救援平臺希望只用一整套系統就解決使用的硬件設備需要有不同的系統的繁瑣問題。它的出現不僅讓使用者在使用時更加方便，還可以讓使用者在使用選項上有了更多選擇的余地。災害應急救援平臺十分流暢，可以讓使用者在使用時幾乎沒有任何的延遲和卡頓，可以給使用者帶來十分輕松的體驗。并且可以在幾乎我們能看到的所有電子設備上使用，大幅度的增加了災害應急救援平臺的使用范圍。同時，災害應急救援平臺可以同步全部的連接對象，對于使用者來說這樣的系統更加方便。它可以很精準的將使用者所需的各方面的災害應急救援需求通過該系統提供給使用者，并且它的使用普遍性可以讓各個年齡段的使用者都能有一個良好的使用體驗。

為了適應電子信息時代和科技化時代的到來，并且應對今后可能越來越廣泛的信息化的發展，需要做出了更加超前時代的功能應對。在這個高速發展的時代里，使用者對信息管理系統的要求也是越來越高，使用者都希望自己可以有擁有一款符合當今科技發展時代，且具有科技感，功能齊全的系統。希望可以只通過一個系統就可以輕松完成自己的需求，而不再因為信息的復雜而不知如何做出最佳選擇。科技時代帶給了人們輕松，立體的體驗，而災害應急救援平臺就符合大家對科技時代的系統所擁有的期待，它可以提升用戶的使用體驗。

想要做一個完整的系統，就必須要為其制定一套詳細并且規范的原則。這些原則定可以幫助我們在設計過程中能有一個更好的設計理念和設計方向，可以讓系統變的更加立體，更加完美。變成更加符合使用者所希望的模樣。所以為了能夠更好的完成系統，對系統制定了一些原則：

（1）以人為本原則

這個災害應急救援平臺，它的本質是為人們服務。是希望其可以實現并滿足廣大使用者對科技時代下的災害應急救援平臺的憧憬與向往。如何解放需要人工才能完成的部分和提升使用者的使用觀感是最為基礎的也是最重要的。它的設計宗旨就是為使用者服務。明確使用者的想法和需求，設法讓使用者可以真實的感受到科技時代的魅力是設計的初衷。災害應急救援平臺可以滿足新時代使用者的需求，讓使用者能夠真實的感受到它的便捷。

（2）可修改原則

設計系統時并不能確保讓所有的功能都達到使用者最理想的要求，在設計的過程中可能會有紕漏。所以在設計時要確保可以及時對不完整，不完美的部分進行修改和補充。同時，也要確保在系統發行后，在出現bug時可以在不影響使用者使用的情況下對系統進行線上維護。同時要確保在修復，更新，維護的同時可以保證使用者的體驗。

需求分析的首要是要分析用戶的需求，知道用戶存在的一些情況，并且要明確用戶的使用狀況，然后設計規劃解決的問題。其中在使用定性的分析以及定量的分析，從這兩個方面獲取用戶的需求。一方面定性的分析獲得的應該是用戶的基本需求，能夠發現現在人們的習慣要求。所以定性的需要主要是為了多與用戶交流，從而更為深刻的了解一些存在的需求問題；定量的分析則是發現一些潛在的用戶，并且獲得不一樣的反饋內容。所以定量的需求要讓用戶來闡述一些情況，一定讓使用者清晰的進行客觀的描述，這樣才能夠比較全面的獲得用戶的需求所在。

（1）鑒于該系統是一款面向全體使用者的系統，管理者需要錄入使用者的個人信息、給予使用者應有的權限，讓使用者可以更加自由的使用系統。

（2）要給予用戶更高的查詢權限，讓用戶可以全方位的了解本課題，讓用戶可以查詢到指揮調度、救援信息、救援反饋等。

（3）要提升用戶的使用效率，讓用戶可以更加快捷的查詢自己想要查詢的東西。同時，還要做到同步性，在用戶查詢信息或者修改信息的同時，系統可以及時反饋到數據庫上，進行及時更新和修復。

2.2系統用例圖

本系統采用自上往下的方法開發，基本定位如下功能：

本課題要求實現一套災害應急救援平臺，系統主要包括管理員模塊和用戶、應急人員模塊的功能模塊；

?（1）管理員用例圖如下所示：

圖2-1管理員用例圖

（2）用戶用例圖如下所示：

圖2-2用戶用例圖

（3）應急人員用例圖如下所示：

圖2-3應急人員用例圖

任何系統在開發之前，經濟方面的問題都是最應該被考慮的，經濟問題主要體現在兩個方面。一方面是在開發時，現有可使用的設計資源能否滿足系統的預計開發消耗；另一方面是在開發以后，系統的盈利能否保證系統的正常運行和日復一日的更新消耗。

開發方面，因為在開發系統時使用的開發工具基本都是免費的，只有一些少量的人工費。所以，開發工具上的經濟消耗都是很少的，都是在可控范圍內的。另外，可以在確保質量的前提下，盡可能的減少設計成本，可以為開發之后的工作留下更多的經濟資源。

在最大限度降低開發成本的同時，也可以讓使用者最大限度的從系統中獲利，對雙方來說都是一個可行的災害應急救援平臺。總結下來就是，該系統的各項開發費用都處于可控范圍內。經過了種種分析和考慮后證明，該系統軟件可以行得通的，經濟方面的壓力是在預料之內的。

在研究技術可行性的時候，系統的開發環境是可以確定的，所以技術可行性最好與系統功能和性能以及一些實際的情況同時考慮。在可行性研究階段，結合實際調整開發的內容和選擇能夠完成的技術體系是一個可用的手段，如果系統進入開發階段，任何的調整都意味著會耗費更多的經歷。需要再次明確的問題是，技術可行性不只是考慮在技術上是否可實現，實際上還包含了在當前的實際的情況下的技術可行性。有很多的因素例如時間不足、預期的開發目標技術難度比較難、不能有充足的技術積累、而且對于技術的掌握不夠等這些實際存在的情況，都是要提前部署和認真規劃的。

開發災害應急救援平臺的技術內容分析，目前的狀況是從網絡硬件和相關技術上看是可行的。該系統采用了JAVA和?MySQL技術。到現在可以知道，很多的基礎知識都是經過學習使用的，在后續的設計中還需要不斷的練習，學習更多相關的技術經驗來充實自己對于系統的開發。?

在社會可行性分析中，首先能結合國家經濟和社會發展的實際情況，還需要能夠讓用戶更加的便利，給使用者帶來多方面的高效益，使得可以比較快速的發展以及應用，隨著很多領域的發展，尤其是智能化的社會下，據統計許多的人都擁有屬于自己的系統，這種情況下就帶來很多的問題，比較突出的就是管理上的不足，從而出現低效率的原因。?

在可行性分析中的收益分析，是比較清晰地發掘開發的系統帶來的各種直接的有效的利益以及一些隱藏起來的好處，以便在后續的設計中更加的堅定和確信系統開發的意義。解決一些社會方面存在的問題，設計并開發系統肯定是要發現某類社會存在的問題，并且能夠帶來一定的社會價值。還有一些社會的影響力，是通過系統想優勢和切實的好處來產生的，能夠在一定的情況下提高效率，肯定會增加一些社會的進步和發展。社會上的可行性，包括法律上的可行性，也包括法律上的可能性，法律上的可行性，需要社會上的許多因素，可以來實現系統建設的現實性。如果所開發的系統與國家法律或政策等相關的因素不相符合，在某些信息化的鄰域中使用的是一些加密的信息或者技術問題，還有不經過正常的操作使用其他的一些公開的信息等這些情況，這樣的系統的開發在法律的范圍中就是不能被允許的。

其中還有一個比較重要的用戶使用可行性也是通過執行系統時的可行性，是從所有情況下用戶的角度來考慮系統的可行性，由于設計開發相關的系統就是站在社會中廣大的用戶體驗考慮的，所以在這個層面考慮也是符合的。

該框架擁有自己獨特的配置方式，網站開發人員不需要再進行大量重復的樣板 式的配置工作，開箱即用，不會生成額外代碼量，不需要進行XML文件的配置。

B/S結構就是指系統客戶端與服務器分離，客戶端通過瀏覽器訪問服務端進行操作。

B/S結構目前廣泛應用于絕大部分系統搭建中，這種結構摒棄C/S結構客戶端服務端不分離的缺點，具有更多的優勢：

（1）跨平臺性：B/S的標準由標準化組織確立，適用于絕大多數的系統搭建，通用于應用之間。

（2）低維護成本：客戶端和服務器端分離，減輕了兩端的壓力，尤其是客戶端，對客戶端設備，硬件、軟件要求都比較低，并且系統需要升級或維護時，只需要在服務器端升級或維護就可以，使相應的費用減少。

Java 最大的兩個特點就是功能強大和簡單易用。Java可以讓程序員進行復雜的編程而不必為儲存管理對象等問題所煩惱，把精力和時間更多的放在研發與設計上，極大地提高了開發者的工作效率和工作熱情。

3系統設計

????系統設計要提出具體的軟件功能及要求，是系統分析后進行的流程。它的主要目的是提供軟件開發的思路和具體流程，是系統運行的根本保障。它要確定軟件各個模塊的功能，并形成相應的流程圖，方便設計者思考。同時要將每個模塊需要完成的任務詳細的表達出來，并對每個模塊進行具體化的設計分析，提供相當數量的設計方案，再通過設計者的詳細分析和比對，選擇出最佳的方案進行設計開發。并對相應的方案進行驗證和拓展。

系統結構圖可以把雜亂無章的模塊按照設計者的思維方式進行調整排序，可以讓設計者在之后的添加，修改程序內容的過程中有一個很明顯的思維方向。同時結構圖還可以讓設計者以外的其他人更直觀的看出整個系統的設計理論和設計過程。讓系統的設計變的更直觀。該系統的功能架構圖如圖3-1所示：

?????????????

???

???????圖3-1 災害應急救援平臺功能結構圖

從系統運行完整的角度出發，設置相應的實體，明確各實體之間的聯系。下面列舉整個系統中涉及核心功能的實體：

1. 用戶信息實體

圖3-2用戶信息實體圖

1. 應急人員信息實體

圖3-3應急人員信息實體圖

1. 應急設備實體

圖3-4應急設備實體圖

4、緊急呼救實體

在綜合了以上對系統的設計，和對數據庫的分析，同時結合了以往對數據庫的使用經驗后，構建了以下幾張表，以下為每張表的內容：

表3-1：token表

表3-2：用戶表

表3-3：救援信息

表3-4：用戶

表3-5：救援反饋

表3-6：應急信息

表3-7：指揮調度

表3-8：緊急呼救

表3-9：應急物資

表3-10：配置文件

表3-11：應急設備

表3-12：應急人員

表3-13：應急評估

表3-14：應急決策

表3-15：現場反饋

這個功能模塊用來讓工作人員進行后端登錄。管理人員通過網站。在輸入自己的用戶名和密碼、角色進行登錄，登錄后管理人員就可以對后臺的信息相關的操作。

首先，設計后端管理的登陸頁面。對頁面的各個板塊進行詳細的設計，規劃它們的字體大小，背景顏色，字體顏色和板塊大小等。還要加上圖片，讓頁面被設計的更加美觀。以便讓以后需要登陸的管理員可以直觀的使用。

4.2管理員功能模塊

管理員通過登錄頁面填寫用戶名和密碼、角色，完成后進行登錄，如圖4-1所示。

管理員登錄進入災害應急救援平臺的實現可以查看系統首頁、個人中心、用戶管理、應急人員管理、應急設備管理、應急決策管理、應急信息管理、應急物資管理、緊急呼救管理、應急評估管理、指揮調度管理、救援信息管理、救援反饋管理、現場反饋管理等信息，如圖4-2所示。

管理員點擊應急人員管理；在應急人員管理頁面對人員賬號、人員姓名、年齡、性別、聯系電話、頭像等信息，進行查詢，新增或刪除應急人員信息等操作；如圖4-3所示。

圖4-3應急人員管理界面圖

管理員點擊用戶管理；在用戶管理頁面對賬號、姓名、年齡、性別、手機、頭像等信息，進行查詢，新增或刪除用戶信息等操作；如圖4-4所示。

圖4-4用戶管理界面圖

管理員點擊應急設備管理；在應急設備管理頁面對設備編號、設備名稱、設備類型、設備位置、狀態、登記日期等信息，進行查詢，新增或刪除應急設備等操作；如圖4-5所示。

圖4-5應急設備管理界面圖

管理員點擊應急物資管理；在應急物資管理頁面對物資名稱、物資分類、規格、數量、登記日期等信息，進行查詢或刪除應急物資等操作；如圖4-6所示。

圖4-6應急物資管理界面圖

管理員點擊緊急呼救管理；在緊急呼救管理頁面對標題、賬號、姓名、手機、號碼、呼救時間、審核回復、審核狀態、審核等信息，進行查詢或刪除緊急呼救等操作；如圖4-7所示。

圖4-7緊急呼救管理界面圖

管理員點擊應急評估管理；在應急評估管理頁面對賬號、姓名、評估等級、評估時間等信息，進行查詢或刪除應急評估等操作；如圖4-8所示。

圖4-8應急評估管理界面圖

管理員點擊指揮調度管理；在指揮調度管理頁面對賬號、姓名、時間、調度時間、人員賬號、人員姓名、調度設備、調度物資等信息，進行查詢或刪除指揮調度等操作；如圖4-9所示。

圖4-9指揮調度管理界面圖

管理員點擊救援信息管理；在救援信息管理頁面對賬號、姓名、手機、救援狀態、登記時間、人員賬號、人員姓名等信息，進行查詢或刪除救援信息等操作；如圖4-10所示。

圖4-10救援信息管理界面圖

4.3?用戶功能模塊

用戶注冊登錄界面，首先雙擊打開系統，連上網絡之后會顯示出本系統的注冊登錄界面，這是進入系統的第初始頁面“注冊登錄”，能成功進入到該登錄界面則代表系統的開啟是成功的，接下來就可以操作本系統所帶有的其他所有的功能，如圖4-11所示。

?

圖4-11用戶注冊登錄界面

用戶登錄系統后，可以對系統首頁、個人中心、緊急呼救管理、指揮調度管理、救援信息管理、救援反饋管理等功能進行相應操作，如圖4-12所示。

圖4-12用戶功能界圖面

用戶點擊緊急呼救管理；在緊急呼救管理頁面對標題、賬號、姓名、手機、號碼、呼救時間、審核回復、審核狀態等信息，進行查詢、新增或者刪除緊急呼救等操作；如圖4-13所示。

圖4-13緊急呼救管理界面圖

用戶點擊救援信息管理；在救援信息管理頁面對賬號、姓名、手機、救援狀態、登記時間、人員賬號、人員姓名等信息，進行查詢救援信息等操作；如圖4-14所示。

圖4-14救援信息管理界面圖

4.4?應急人員功能模塊

應急人員注冊登錄界面，首先雙擊打開系統，連上網絡之后會顯示出本系統的注冊登錄界面，這是進入系統的第初始頁面“注冊登錄”，能成功進入到該注冊登錄界面則代表系統的開啟是成功的，接下來就可以操作本系統所帶有的其他所有的功能，如圖4-15所示。

→ 源碼獲取