此系统设计主要采用的是nodejs语言来进行开发，采用express框架技术，框架分为三层，分别是控制层Controller，业务处理层Service，持久层dao，能够采用多层次管理开发，对于各个模块设计制作有一定的安全性；数据库方面主要采用的是MySQL来进行开发，其特点是稳定性好，数据库存储容量大，处理能力快等优势；服务器采用的是Tomcat服务，能够提供稳固的运行平台，确保系统稳定运行。通过灾害应急救援平台来提升本课题的各项功能的工作效率，提供了一个多样功能，具有良好实用性的灾害应急救援平台。
前端技术：nodejs+vue+elementui,
Express 框架于Node运行环境的Web框架,
语言 node.js
框架：Express
前端:Vue.js
数据库：mysql
数据库工具：Navicat
开发软件：VScode
视图层其实质就是vue页面，通过编写vue页面从而展示在浏览器中，编写完成的vue页面要能够和控制器类进行交互，从而使得用户在点击网页进行操作时能够正常。
代码结构讲解
1、 node_modules文件夹(有npn install产生)
这文件夹就是在创建完项目后，cd到项目目录执行npm install后生成的文件夹，下载了项目需要的依赖项。
2、package.json文件
此文件是项目的配置文件（可定义应用程序名，版本，依赖项等等）。node_modules文件夹下的依赖项是从哪里知道的呢？原因就是项目根目录下的这个package.json文件，执行npm install时会去找此文件中的dependencies，并安装指定的依赖项。
3、public文件夹(包含images、javascripts、stylesheets)
这个文件夹做过Web开发的应该一看就知道，为了存放图片、脚本、样式等文件的。
4、routes文件夹
用于存放路由文件。
5、views文件夹
存放视图。
2.3可行性分析
2.3.1经济可行性
任何系统在开发之前，经济方面的问题都是最应该被考虑的，经济问题主要体现在两个方面。一方面是在开发时，现有可使用的设计资源能否满足系统的预计开发消耗；另一方面是在开发以后，系统的盈利能否保证系统的正常运行和日复一日的更新消耗。
开发方面，因为在开发系统时使用的开发工具基本都是免费的，只有一些少量的人工费。所以，开发工具上的经济消耗都是很少的，都是在可控范围内的。另外，可以在确保质量的前提下，尽可能的减少设计成本，可以为开发之后的工作留下更多的经济资源。
在最大限度降低开发成本的同时，也可以让使用者最大限度的从系统中获利，对双方来说都是一个可行的灾害应急救援平台。总结下来就是，该系统的各项开发费用都处于可控范围内。经过了种种分析和考虑后证明，该系统软件可以行得通的，经济方面的压力是在预料之内的。
2.3.2技术可行性
在研究技术可行性的时候，系统的开发环境是可以确定的，所以技术可行性最好与系统功能和性能以及一些实际的情况同时考虑。在可行性研究阶段，结合实际调整开发的内容和选择能够完成的技术体系是一个可用的手段，如果系统进入开发阶段，任何的调整都意味着会耗费更多的经历。需要再次明确的问题是，技术可行性不只是考虑在技术上是否可实现，实际上还包含了在当前的实际的情况下的技术可行性。有很多的因素例如时间不足、预期的开发目标技术难度比较难、不能有充足的技术积累、而且对于技术的掌握不够等这些实际存在的情况，都是要提前部署和认真规划的。
开发灾害应急救援平台的技术内容分析，目前的状况是从网络硬件和相关技术上看是可行的。该系统采用了nodejs和 MySQL技术。到现在可以知道，很多的基础知识都是经过学习使用的，在后续的设计中还需要不断的练习，学习更多相关的技术经验来充实自己对于系统的开发。
2.3.3社会可行性
在社会可行性分析中，首先能结合国家经济和社会发展的实际情况，还需要能够让用户更加的便利，给使用者带来多方面的高效益，使得可以比较快速的发展以及应用，随着很多领域的发展，尤其是智能化的社会下，据统计许多的人都拥有属于自己的系统，这种情况下就带来很多的问题，比较突出的就是管理上的不足，从而出现低效率的原因。
在可行性分析中的收益分析，是比较清晰地发掘开发的系统带来的各种直接的有效的利益以及一些隐藏起来的好处，以便在后续的设计中更加的坚定和确信系统开发的意义。解决一些社会方面存在的问题，设计并开发系统肯定是要发现某类社会存在的问题，并且能够带来一定的社会价值。还有一些社会的影响力，是通过系统想优势和切实的好处来产生的，能够在一定的情况下提高效率，肯定会增加一些社会的进步和发展。社会上的可行性，包括法律上的可行性，也包括法律上的可能性，法律上的可行性，需要社会上的许多因素，可以来实现系统建设的现实性。如果所开发的系统与国家法律或政策等相关的因素不相符合，在某些信息化的邻域中使用的是一些加密的信息或者技术问题，还有不经过正常的操作使用其他的一些公开的信息等这些情况，这样的系统的开发在法律的范围中就是不能被允许的。
其中还有一个比较重要的用户使用可行性也是通过执行系统时的可行性，是从所有情况下用户的角度来考虑系统的可行性，由于设计开发相关的系统就是站在社会中广大的用户体验考虑的，所以在这个层面考虑也是符合的。
灾害应急救援平台的目的是让使用者可以更方便的将人、设备和场景更立体的连接在一起。能让用户以更科幻的方式使用产品，体验高科技时代带给人们的方便，同时也能让用户体会到与以往常规产品不同的体验风格。
与安卓，iOS相比较起来，灾害应急救援平台在流畅性，续航能力，等方方面面都有着很大的优势。这就意味着灾害应急救援平台的设计可以比其他系统更为出色的能力，可以更高效的完成最新的用户、应急人员、应急设备、应急决策、应急信息、应急物资、紧急呼救、应急评估、指挥调度、救援信息、救援反馈、现场反馈等功能。
目 录
摘 要 I
Abstract II
1 绪 论 1
1.1研究意义 1
1.2系统设计目的 2
1.3系统设计思想 2
2系统需求分析 3
2.1系统性能需求 3
2.2系统用例图 3
2.3可行性分析 4
2.3.1经济可行性 4
2.3.2技术可行性 5
2.3.3社会可行性 6
2.4系统开发技术 6
2.4.1 express框架 7
2.4.2 B/S架构 8
2.4.3 MySQL介绍 8
2.4.4 nodejs介绍 9
2.5系统流程分析 10
3系统设计 11
3.1系统功能结构 12
3.1.1系统结构图 13
3.2数据库设计 15
3.2.1 数据库概念设计 16
3.2.2数据逻辑结构 18
4系统详细设计 21
4.1登录模块设计 22
4.2管理员功能模块 23
4.3用户功能模块 24
4.4应急人员功能模块 25
5 软件测试 28
5.1软件测试原则 29
5.2测试用例 30
结 论 30
参考文献 31
致 谢 32
1 绪 论
近些年来，随着电子科学技术的高速发展，计算机相关行业的发展创新。衍生出了各种各样方便快捷的电子设备。如手机，电脑等。这些电子设备功能强大，方便所有类型的人们使用。但这些年来，人们对手机，电脑等电子高科技产物的依赖和需求也越来越大。现在的人们已经不再满足于它们各式各样的基础功能，例如与他人通讯，上网了解信息等。人们现在更希望的是随着科技的发展，手机、电脑等高科技产品可以给自己带来更多方便快捷、简单实用的功能。同时也希望自己在使用的时候可以更轻松的掌握使用这些设备的技巧。同时，伴随着这些电子设备的出现，操作系统就显的尤为重要，电子设备各式各样功能的顺利运行都要依靠它的稳定运行。操作系统可以管理、控制计算机的硬件资源和软件资源，也是计算机最为基本的系统软件。人们所有能涉及到和使用到的软件运行几乎都离不开它。它就像人类的大脑一样，控制着计算机的各种设备。但同样，操作系统在发展时自身也会出现很多问题，同样的系统不能应用在所有的硬件设备上。这个问题对于大部分的电子科技受益者来说很陌生，处理起来很有困难。会让使用者不能在第一时间使用，因此会造成很多负面的影响。
什么是灾害应急救援平台？灾害应急救援平台区别于人们司空见惯的安卓系统和iOS系统，灾害应急救援平台希望只用一整套系统就解决使用的硬件设备需要有不同的系统的繁琐问题。它的出现不仅让使用者在使用时更加方便，还可以让使用者在使用选项上有了更多选择的余地。灾害应急救援平台十分流畅，可以让使用者在使用时几乎没有任何的延迟和卡顿，可以给使用者带来十分轻松的体验。并且可以在几乎我们能看到的所有电子设备上使用，大幅度的增加了灾害应急救援平台的使用范围。同时，灾害应急救援平台可以同步全部的连接对象，对于使用者来说这样的系统更加方便。它可以很精准的将使用者所需的各方面的灾害应急救援需求通过该系统提供给使用者，并且它的使用普遍性可以让各个年龄段的使用者都能有一个良好的使用体验。
1.1研究意义
伴随着科技的进步，时代的发展，越来越多的电子设备也随之出现在人们的眼前，在电子设备，软件技术成熟之前，人们可以选择使用电子设备，通过灾害应急救援软件的帮助，找到最适合自己，最符合自己的管理方式。而灾害应急救援的普及也伴随着很多问题，有的灾害应急救援软件不能适应用户使用的电子设备的系统，这会让部分使用者对这款软件彻底否认，会导致该系统失去预想的市场竞争力，面临淘汰。使用者更希望自己使用的灾害应急救援平台可以在完成最基本的功能需求的基础上变的更加稳定，流畅，并且没有任何因兼容性而引发的复杂问题。
而灾害应急救援平台的出现也渐渐让这种类似的问题有了一个相对明确的解决方案，灾害应急救援平台可以使软件的运行速度变的更快，并且可以同步全部的连接对象，可以确保项目的正确运行，同时，在如此信息化的时代里，使用者对软件的各项要求也越来越多，在如此广阔的信息量之下，使用者更希望自己使用的系统可以畅通无阻的浏览每个网页上的信息，可以全方位的了解应急设备、应急决策、应急信息、应急物资、紧急呼救、应急评估、指挥调度等的特点，根据自己的需求，选择最适合自己的方案。并且让整个电子信息时代都注入了新鲜的血液，且能更好的流向各个领域，各个行业，为电子信息时代继续发光发热。
1.2系统设计目的
为了适应电子信息时代和科技化时代的到来，并且应对今后可能越来越广泛的信息化的发展，需要做出了更加超前时代的功能应对。在这个高速发展的时代里，使用者对信息管理系统的要求也是越来越高，使用者都希望自己可以有拥有一款符合当今科技发展时代，且具有科技感，功能齐全的系统。希望可以只通过一个系统就可以轻松完成自己的需求，而不再因为信息的复杂而不知如何做出最佳选择。科技时代带给了人们轻松，立体的体验，而灾害应急救援平台就符合大家对科技时代的系统所拥有的期待，它可以提升用户的使用体验。
1.3系统设计思想
想要做一个完整的系统，就必须要为其制定一套详细并且规范的原则。这些原则定可以帮助我们在设计过程中能有一个更好的设计理念和设计方向，可以让系统变的更加立体，更加完美。变成更加符合使用者所希望的模样。所以为了能够更好的完成系统，对系统制定了一些原则：
（1）以人为本原则
这个灾害应急救援平台，它的本质是为人们服务。是希望其可以实现并满足广大使用者对科技时代下的灾害应急救援平台的憧憬与向往。如何解放需要人工才能完成的部分和提升使用者的使用观感是最为基础的也是最重要的。它的设计宗旨就是为使用者服务。明确使用者的想法和需求，设法让使用者可以真实的感受到科技时代的魅力是设计的初衷。灾害应急救援平台可以满足新时代使用者的需求，让使用者能够真实的感受到它的便捷。
（2）可修改原则
设计系统时并不能确保让所有的功能都达到使用者最理想的要求，在设计的过程中可能会有纰漏。所以在设计时要确保可以及时对不完整，不完美的部分进行修改和补充。同时，也要确保在系统发行后，在出现bug时可以在不影响使用者使用的情况下对系统进行线上维护。同时要确保在修复，更新，维护的同时可以保证使用者的体验。
2系统需求分析
需求分析的首要是要分析用户的需求，知道用户存在的一些情况，并且要明确用户的使用状况，然后设计规划解决的问题。其中在使用定性的分析以及定量的分析，从这两个方面获取用户的需求。一方面定性的分析获得的应该是用户的基本需求，能够发现现在人们的习惯要求。所以定性的需要主要是为了多与用户交流，从而更为深刻的了解一些存在的需求问题；定量的分析则是发现一些潜在的用户，并且获得不一样的反馈内容。所以定量的需求要让用户来阐述一些情况，一定让使用者清晰的进行客观的描述，这样才能够比较全面的获得用户的需求所在。
2.1系统性能需求
（1）鉴于该系统是一款面向全体使用者的系统，管理者需要录入使用者的个人信息、给予使用者应有的权限，让使用者可以更加自由的使用系统。
（2）要给予用户更高的查询权限，让用户可以全方位的了解本课题，让用户可以查询到指挥调度、救援信息、救援反馈等。
（3）要提升用户的使用效率，让用户可以更加快捷的查询自己想要查询的东西。同时，还要做到同步性，在用户查询信息或者修改信息的同时，系统可以及时反馈到数据库上，进行及时更新和修复。
2.2系统用例图
本系统采用自上往下的方法开发，基本定位如下功能：
本课题要求实现一套灾害应急救援平台，系统主要包括管理员模块和用户、应急人员模块的功能模块；
4系统详细设计
4.1登录模块设计
这个功能模块用来让工作人员进行后端登录。管理人员通过网站。在输入自己的用户名和密码、角色进行登录，登录后管理人员就可以对后台的信息相关的操作。
首先，设计后端管理的登陆页面。对页面的各个板块进行详细的设计，规划它们的字体大小，背景颜色，字体颜色和板块大小等。还要加上图片，让页面被设计的更加美观。以便让以后需要登陆的管理员可以直观的使用。
4.2管理员功能模块
管理员通过登录页面填写用户名和密码、角色，完成后进行登录，如图4-1所示。
图4-1管理员登录页面
管理员登录进入灾害应急救援平台的实现可以查看系统首页、个人中心、用户管理、应急人员管理、应急设备管理、应急决策管理、应急信息管理、应急物资管理、紧急呼救管理、应急评估管理、指挥调度管理、救援信息管理、救援反馈管理、现场反馈管理等信息，如图4-2所示。
图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所示。
图4-15应急人员注册登录界面
应急人员登录到系统界面，可以对系统首页、个人中心、应急设备管理、应急决策管理、应急信息管理、应急物资管理、指挥调度管理、救援信息管理、救援反馈管理、现场反馈管理等功能进行相应操作，如图4-6所示。
图4-16应急人员功能界图面
应急人员点击应急设备管理；在应急设备管理页面对设备编号、设备名称、设备类型、设备位置、状态、登记日期等信息，进行查询应急设备等操作；如图4-17所示。
图4-17应急设备管理界面图
应急人员点击指挥调度管理；在指挥调度管理页面对账号、姓名、时间、调度时间、人员账号、人员姓名、调度设备、调度物资等信息，进行查询指挥调度等操作；如图4-18所示。
图4-18指挥调度管理界面图
应急人员点击救援信息管理；在救援信息管理页面对账号、姓名、手机、救援状态、登记时间、人员账号、人员姓名等信息，进行查询救援信息等操作；如图4-19所示。
图4-19救援信息管理界面图
5 软件测试
软件测试（Software Testing）是指在设计基本完成后对软件的各项功能进行测试，检测其能否达到在系统设计之初对其的预期情况。预估系统上线后的情况，对出现问题的地方进行及时修改。软件测试作为系统设计的最终阶段，它的准确性往往影响了系统的最终使用感。因为软件是由数据、文档以及程序代码组成的，所以软件测试的对象就不仅仅是程序的本身，还有包括软件设计过程中形成的数据、文档等。但软件测试也存在着问题，软件测试注重的是软件设计的最终结果，其并没有关心整个系统在开发过程中发生的问题。软件测试必须假设和考虑在设计过程中发生的问题。并对软件测试中发现的问题进行回归测试。要更好的通过软件测试检测系统以更好的找出问题来提高系统的质量。软件测试要以最少的人力和经济消耗来完成系统的设计结尾工作。而且所有的测试都要以人为本，任何的测试都要考虑到用户使用的实际体验感，要确保用户有一个好的使用体验。要确保整个软件测试过程都按照原定的规则进行，以确保最终设计的系统的完整性和实用性。
5.1软件测试原则
编筐编篓，重在收口。软件测试的完成效果直接影响到整个系统的使用效果。对于软件测试来说，如果能早点发现系统的漏洞，就能及时修改，可以让设计的成本减少。进行软件测试的时候，测试员们需要制定自己的测试脚本，让这个脚本尽可能多的覆盖系统需要测试的各个路径，避免系统疏漏。同时，在软件测试的过程中，要检测程序有没有进行与系统预期功能要求无关的代码运行。避免多余的程序运行对系统产生破坏，降低效率，增加成本。同时在测试后，还要尽量保留所有测试用例，这样可以帮助日后想要修改时可以及时找到原先的用例，可以再直接进行测试。以下是总结下来比较重要的一些软件测试原则：
（1）要尽可能早的进行软件测试。
随着系统的设计进行，设计过程中每一个阶段发生的错误都有可能导致在后续的开发设计的时候连续出错，如果等到软件设计工作基本全都完成再进行测试，可能会导致大量的错误同时出现，而且很难找到它们出错的源头。因为开发设计的每一步都与后续程序紧密相连，如果不及时找出错误，可能会因一处错误导致后续整个程序瘫痪。所以要坚持尽早进行软件测试的原则，一来可以减少牵一发而动全身的错误，二来可以降低成本。
（2）软件测试证明软件存在缺陷。
通过软件测试可以检测系统设计时是否存在错误和缺陷，但并不能说明系统是不存在任何缺陷的。软件测试的目的是辅助软件开发，让程序员可以尽可能早的发现错误，提高质量。软件开发的过程或多或少都会产生一些错误，软件测试就是尽可能地发现错误和缺陷，尽可能优化程序。
（3）缺陷集群效应原则。
一个软件核心的地方可能就只有那么小的一部分，但就是那一小部分，却能引发软件大规模的损坏。当我们进行软件测试的时候要特别注意那一小部分，也就是核心的部分，因为它们几乎控制了整个软件的稳定性，它们是最容易出现错误的，控制好它们几乎就控制了软件的八成稳定性。但我们也不能只仅限于这小部分模块的检查，也要对剩余的地方进行适当的测试。
（4）以人为本原则。
灾害应急救援平台设计的目的就是为人服务，任何的缺陷和错误的修改方向都要在使用者的角度去进行。要做到尽可能贴近使用者的日常模式，从使用者的角度去出发，去修改。
（5）经常更新测试方式。
测试人员应该尽量避免对系统所有的部分都使用同一种测试方式。一些测试方式只能检测特定的模块，并不能对整个系统都进行有效的测试，甚至无法发现一处错误。所以，为了能更好的发挥软件测试的作用，软件测试的时候应该经常更新测试方法，让测试的质量最大化。
5.2测试用例
部分系统测试用例如表5-1所示。
表 5-1 测试用例表
测试功能、流程 预期结果 实际结果 结论
进行登录实验。需要管理员输入相应的信息验证，看能否进入 录入信息验证通过，
转入管理员界面 登陆成功，
成功跳转页面 测试成功
对用户的登录进行测试。管理员就录入特定的信息，看能否成功登录 录入特定信息，
可以登录，可以在数据后台找到信息 可以登录，在后台找到了对应信息 测试成功
测试登录功能是否符合规定。测试员要输入错误的登录信息，检查能否登录 在输入错误的信息后，系统会发现错误，禁止测试人员登录
输入错误信息后，系统禁止登录 测试成功
对兼容性进行测试，让软件在不同的电子类产品上进行登录测试 都可以成功打开软件，正常运行 可以在不同的设备上和其他软件共存 测试成功
续表5-1
1
测试功能、流程 预期结果 实际结果 结论
安装测试，在试验机上登录软件，检测能否按预期正常运行 登录后可以进行正常操作，可以发行 在试验机上可以正常运行，没有卡顿 测试成功
结 论
灾害应急救援平台通过 express框架、nodejs语言等技术完成的。系统可以完成用户的基本需求，并且在测试中系统运行情况良好，没有出现异常。但是，还是有许多我需要学习和完善的地方。
灾害应急救援平台实现了模块化连接，对应不同的平台可以进行针对性部署，可以进行全方位的覆盖。它实现了跨终端无缝协同体验。但碍于灾害应急救援平台刚进入市场发行不久，它的各项数据，功能还没有达到完美的地步。需要进一步的实际运行来完善有缺陷的地方。在这个信息化的时代大家都希望手里的任何一个电子设备都可以完成平时的常见功能，通过灾害应急救援平台的开发可以实现这一目标。灾害应急救援平台作为国产系统，它的发展前途十分明亮，未来也会拥有很广泛的市场，通过未来的长时间发展，灾害应急救援平台的软件开发一定会成为一种趋势，让中国的操作系统发展得到进一步的提升。