什么是灾害应急救援平台？灾害应急救援平台区别于人们司空见惯的安卓系统和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所示。

→ 源码获取