第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
社区居家养老模式对于人口老龄化的问题来说，处于主要的地位。高鹏1认为社区居家医养结合服务运行机制受到诸多社会生态系统因素的影响，服务供给和需求之间存在着结构上的障碍。目前社区养老服务机构大多使用人工登记、电话沟通等方式来处理服务预约、派单调度等日常事务，信息传递链条长，服务响应慢的现象时有发生。刘凌菁2从社会技术系统角度出发，就BIM同智慧养老社区的协同问题展开了论述，认为技术工具对于提高养老服务质量起到决定性的作用。传统管理模式同现代养老服务需求之间存在较大差距，创建专门针对社区养老场景的信息化系统迫在眉睫。该系统把服务流程整合起来、统一数据管理、实时状态追踪，从技术上可以解决上面的现实问题。
1.1.2 研究意义
本文设计的社区养老系统具有操作高效、资源调度等明显优点。系统把服务预约、派单、评价等环节全部放在一个平台上进行管理，从而缩减了由于人工交接而造成的各种信息差错和时间浪费。老年人可以自主地选择服务并且可以预约服务，服务人员得到及时的派单任务，管理员可以查看到运营数据。该种运作模式可以加快整体服务流转的速度，降低管理成本。就行业而言，该系统给社区养老机构赋予了一种可参照的信息化创建方案，有益于促进养老服务行业朝着标准化和数字化的方向前进。系统自带的健康监测功能给老年人健康管理赋予了数据搜集和保存的途径，有益于提升老年群体的生活品质。
1.2 国内外研究现状
1.2.1 国内现状
国内社区养老服务信息化研究由原来的资讯展示发展为现在的业务协同。早期的平台主要进行养老服务政策的宣传以及机构信息的展示，内容的生产是由后台编辑手动发布的，用户之间的互动比较低。张红、吴诗祺认为数字技术正在改变传统养老服务的供给方式，信息系统介入之后服务流程更加透明3。查亚楠等4用系统评价法对老年人社区居家养老服务需求进行了总结，认为服务质量的好坏、信息是否容易获取是决定老人满意程度的重要因素。任宏达5设计出一套以云平台为依托的社区养老服务系统，证明了信息化手段可以提高社区养老服务系统的调度效率。朱文斌等人6用Docker容器技术创建了智慧养老社区集群服务系统，表现出轻量级虚拟化技术在养老环境里的应用前景。孙晓妍7用Hyperledger Fabric创建了一个区块链社区养老系统，探究了分布式账本技术怎样为服务的信任机制搭建提供途径。
1.2.2 国外现状
国外对于信息技术在老年照护中嵌入的方式有更早的开始。Sadashima等人8建立了一个可以预测社区老年人体重减轻危险的评分系统，并且对该系统进行了检验。Liu等9对社区和护理机构老年人群肌少症相关因素进行了系统比较，发现不同的居住环境里健康影响因素存在差异。Liu、Xu10用深度确定性策略梯度法对智慧养老社区建筑能源系统进行自适应优化设计，把强化学习技术应用到养老社区运营管理当中。Weiwei11设计出一种基于聚类算法的社区养老服务质量评价系统，用无监督学习的方法对服务质量进行自动分级。Lui等12就智能家居技术在社区、机构养老场景中预防和检测老年人跌倒的效果展开系统评价并进行荟萃分析，得出结论认为传感技术对于跌倒风险的管理是有成效的。
1.3 主要研究内容
主要工作就是设计并实现一个面向社区养老场景的JavaWeb系统。研究从需求分析开始，整理出老人用户、服务人员、管理员这三个角色的业务诉求，确定服务预约、健康监测、派单管理、评价反馈等主要功能的界限。接着进行系统的技术选型，选择SpringBoot做为后端框架，Vue构建前端界面，MySQL存储业务数据。系统设计阶段画出系统架构图、功能结构图、业务流程图和数据库E-R图，对模块进行分块，并对数据间的关系进行规范。编码实现阶段按照各个角色的功能模块来开展工作，编写出接口并搭建起相应的页面。测试验证阶段编写测试用例，对主要功能进行正确性检验。研究侧重点在于服务流转过程的完整性、健康数据管理的规范性，移动端适配、第三方支付接口对接等不在本次研究范围之内。最后得到可以运行的系统原型、数据库设计文档和测试报告。整体采用软件工程的瀑布模型，分阶段进行并逐项产生文档成果。
第二章 相关技术介绍
2.1 SpringBoot框架
SpringBoot框架是由Spring生态体系不断简化配置工作而产生的。该框架在开发时使用约定优于配置的思想，用自动配置的方式减少大量的XML配置文件的编写。运行阶段框架自带的嵌入式Servlet容器可以直接运行应用程序，不需要把WAR文件部署到独立的应用服务器上。框架内部给出一套完整的启动器依赖管理方案，开发人员加入相应的场景启动器模块之后，框架就会自动装载有关的组件。对于社区养老系统中的服务预约模块，使用SpringBoot框架的RESTful风格注解可以快速创建出数据交互接口。框架中还有健康检查和度量指标采集功能13，运维特性可以使得应用程序运行状态可以被观察到。SpringBoot的自动配置原理是依靠条件注解来运行的。框架启动的时候会扫描类路径下的依赖库，如果存在某个特定的类，则会创建该类对应的Bean对象。该框架的事件监听可以实现开发人员自定义初始化的功能。
2.2 Vue框架
Vue框架是基于JavaScript的一种渐进式用户界面开发框架。该框架的核心库只对视图层进行处理，使用响应式数据绑定的方式使模型和视图可以自动同步。当数据对象发生改变的时候，框架内部的依赖收集系统就会触发视图更新的操作。Vue的模板语法是基于纯HTML进行扩展的，开发人员可以在模板中使用声明式的绑定语法把DOM元素和底层数据关联起来。社区养老系统中老人用户端信息展示界面用Vue的列表渲染方式展示服务项目列表。组件化开发模式把界面拆分成可以被复用的独立模块，每个模块都有自身的模板、逻辑、样式等。Vue框架也提供路由管理库，可以用来创建单页面应用14。路由切换的时候不会重新加载整个页面，只是动态替换视图组件。虚拟DOM技术在数据发生变化的时候只计算出最小的DOM操作集合，从而减小了由于重绘而造成的性能开销。
2.3 MySQL数据库
MySQL是一个开源的关系型数据库管理系统。该数据库使用客户端/服务器结构。客户端和服务器之间用结构化查询语言来和数据库进程进行交互。服务器进程是解析SQL语句、优化查询计划、返回结果集的程序。MySQL的存储引擎架构采用插件式的管理模式15，用户可以根据业务需求来选择适合的存储引擎。InnoDB存储引擎支持事务处理和外键约束，适合需要数据一致性的业务场景。数据库在执行查询语句的时候，要经过语法分析、预处理、查询优化以及表扫描这些环节。查询优化器用代价估计模型来评价不同的索引路径执行开销，选取代价最小的方案作为最后执行计划。对于社区养老系统中健康监测数据存储业务来说，MySQL的时间戳和日期类型可以准确地记录每一次的测量时间。该数据库还具有视图机制以及存储过程的功能，可以对复杂的业务逻辑进行封装和复用。
2.4 MyBatis框架
MyBatis是持久层框架，可以将Java对象和数据库记录进行映射转换。该框架用XML配置文件或者注解的方式来定义SQL语句和映射规则。框架内部使用动态代理技术为映射器接口生成代理对象，调用接口方法时框架会执行对应的SQL并自动封装结果集。MyBatis的SQL语句和业务代码是分开存储的16，修改SQL不会影响到Java源代码的编译结果。该框架的一级缓存默认打开并且基于SqlSession的生命周期，同一个会话内多次查询相同的数据就会直接从缓存中取出结果。二级缓存跨会话共享要开发人员自己去设置开启。MyBatis也支持延迟加载，关联对象只有在主对象被使用的时候才会进行查询。社区养老系统服务派单业务中使用MyBatis的动态SQL标签可以根据输入参数是否为空灵活地拼接查询条件。框架的类型处理器用来将Java类型和JDBC类型进行转换，开发人员可以根据自身的需求来创建自定义的类型处理器。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
SpringBoot框架、Vue前端库和MySQL数据库这三个技术组合在一起就形成了一个成熟的体系。SpringBoot自带的自动配置可以简化项目的搭建过程，使用IntelliJ IDEA集成工具可以直接创建项目结构。Vue框架的组件化开发模式同后端RESTful API可以很好地将前后端职责分离开来，在众多的Web项目中已经被证明是有效的。MySQL数据库可以进行事务处理以及多表关联查询，可以满足社区养老系统中预约记录和派单状态数据一致性的需求。以上技术均为开源方案，社区文档及问题解决办法较多，开发过程中遇到的技术难题可以查阅相关资料加以解决。因此该系统的选型技术是合理的，开发环境是可行的。
3.1.2 操作可行性
系统开发所用到的软件工具都是免费或者社区版本的，IntelliJ IDEA提供免费的社区版，MySQL和Node.js运行环境是开源的可以获取。开发硬件使用普通的个人计算机就可以满足要求，不需要购买专用服务器设备。系统部署阶段采用低成本云服务器实例进行单机部署方案，可满足中小社区养老机构日常并发量的需求。运行维护人员只需要掌握基本的数据库操作和日志查看技能，不需要聘请高级运维人员。开发周期为三个月至四个月，人力成本属于学生毕业设计可以承受的范围。综合评价认为系统建设的经济投入小，预期效益可以覆盖开发成本。
3.1.3 经济可行性
老年人使用计算机的能力水平各不相同，对于界面简洁化、操作指导明确化的要求较高。系统界面采用大按钮、明显的标签、有条理的引导，老人用户完成服务预约只需选择项目、填写时间、确认提交这三步即可。服务人员日常使用手机端或者平板电脑接收派单通知，界面适配移动端触摸操作，服务状态更新通过点选来完成。管理员端用表格布局和筛选组件，运营人员通过菜单导航到不同的管理界面。三种角色的操作路径均在三个到五个点击步骤内完成，学习成本小。系统上线前给出简单的操作手册和演示视频，用户经过短暂的熟悉之后就可以独立使用。
3.2 功能需求分析
UML用例图是描述系统功能以及用户交互的一种建模工具，用角色和用例之间的关系来表现系统在各种情况下所发生的动作。用例图可以清楚地表现系统边界，确定外部的参与者同系统之间的交互方式。参与者代表不同的用户群体或者外部系统，用例体现系统所具有的功能或者服务。该图对于需求分析阶段有很重要的作用，可以发现主要的功能，防止漏掉重要的需求。图形化表示方式使用例图易于沟通、理解，为之后系统的设计、实现提供依据。本文将对系统按角色模块进行需求分析。
3.2.1 老人用户角色功能需求
老年人用户对系统上的服务进行预约。系统展示可以预约的服务项目列表，用户选择服务之后提交预约申请。老人用户可以查询自己所有的服务预约记录，查看预约审核状态和派单进度。服务状态查询功能可以追踪已经派单的服务执行阶段，知道服务人员是否已经接单或者正在前往。服务结束之后老人用户会收到评价提醒，可以填写满意度评分和文字反馈。健康监测模块可以给血压、血糖等指标添加录入入口，可以查看历史健康数据的变化趋势。新闻资讯版块展示养老政策、健康知识等文章给用户浏览。老人用户可以提交投诉建议，用留言板的形式向管理员反映服务上的问题。老人用户的用例图如下图3-1所示。
图3-1老人用户用例图
3.2.2 服务人员角色功能需求
服务人员接到系统发出的派单任务。派单管理界面显示待接单列表和已接单任务，服务人员选好接单之后任务状态就会变成处理中。服务状态查询功能可以更新当前服务的执行状态，分为路上、服务中、服务完成这三种状态。服务人员可以查看历史服务评价，了解服务结束之后用户对服务质量的评价情况。服务项目查询功能可以显示所有的可提供服务的项目名称、服务内容和价格信息，服务人员确认服务内容之后开始执行任务。服务状态更新操作会把通知推送到老人用户端和管理后台，保证信息流转闭环。服务人员用例图如图3-2所示。
图3-2服务人员用例图
3.2.3 管理员角色功能需求
管理员可以对服务预约量趋势、服务完成率、用户活跃度等进行统计。服务项目管理功能可以新增服务类型，修改服务价格和简介，设定服务预约次数上限。服务预约管理模块处理老人用户提出的预约申请，管理员审核通过之后产生派单任务。服务派单管理界面显示待分配的任务列表，管理员把任务分派给合适的工作人员。服务评价管理模块显示用户提交的评价内容，异常评价可以标记处理状态。健康监测管理可以查询所有的老人健康记录，并且可以导出数据报表进行健康分析。留言管理功能审核用户提交的投诉建议，对敏感内容进行隐藏或者删除。管理员用例图如下图3-3所示。
图3-3管理员用例图
3.3 非功能需求分析
(1)可用性需求
可用性上系统要保证稳定响应速度，在高并发访问情况下也可以保证界面加载的流畅性。系统应该可以被多平台访问，保证用户在不同的终端上都可以得到同样的使用体验。系统应具有明显的界面结构以及直观的操作方式，使用户操作更加容易。系统应能不断改善自身的性能，还可以进行新的功能扩展，在一个运行周期内保证较高的可用性。
(2)可靠性需求
可靠性上系统要具有自动容错的功能，在局部发生故障的时候仍然可以保证主要功能的正常运转。系统要支持数据备份和恢复机制，在出现异常的时候不会造成数据的丢失。系统应该有冗余设计来保证服务的连续性。系统应有运行监控和日志跟踪功能，可以对运行状态进行实时监测，并能找出问题。
(3)安全性需求
安全性上系统要设置访问控制，保证各个用户只对自身所拥有的权限进行操作。系统应该具有身份认证、数据加密的功能来保证传输和存储过程中信息的安全性。系统要设置入侵检测和防护措施来减少可能的攻击风险。系统应具有日志审计功能，可以对操作行为进行追踪，符合合规性要求。
第四章 系统设计
4.1 系统架构设计
系统用模块化的设计思想把前端展示、业务逻辑和数据存储分开。用户使用浏览器访问Vue.js搭建的界面，请求被axios库异步发往后台。Spring Boot框架接收到请求之后，就会调用对应的Service层组件来完成业务处理。Service层对数据进行校验和运算，最后使用数据访问对象与MySQL数据库交互。分层架构把各个模块的职责分清楚，减少功能之间耦合的程度。张明认为社区服务系统清晰的分层可以提高代码的可维护性以及系统的响应速度17。系统主要包含服务预约、新闻浏览、健康监测、留言互动这四个主要的功能。本地缓存机制可以用来保存会话数据，防止频繁地从数据库里查询，保证数据的一致性和操作的流畅性。整体架构抽象图如图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
系统为三个主要的用户角色，即老人用户、服务人员和管理员。老人用户的中心功能是服务获取和信息查询，服务预约、新闻资讯查询、投诉建议提交、服务派单查询、服务状态查询、服务评价填写、健康检测录入。服务人员主要是对派单任务进行处理，查询相关的服务状态和评价反馈，功能模块有服务派单管理、服务状态查询、服务评价查询、服务项目查询。管理员是系统全局的管理者，也是业务的监管者，其功能模块包含数据分析、服务项目管理、服务预约管理、服务派单管理、服务评价管理、健康监测管理、留言管理。该系统的功能结构如图4-2所示。
图4-2系统功能结构图
4.3 系统流程设计
4.3.1 系统总体业务流程设计
老人用户登录系统后浏览各类服务项目。用户提交预约申请生成待处理订单。管理人员审核预约信息并指派服务人员。服务人员接收派单任务后上门提供服务。服务完成后用户对本次服务进行评价。系统根据评价结果更新服务人员绩效。服务状态查询功能贯穿整个业务流程。系统总体业务流程如图4-3所示。
图4-3系统总体业务流程图
4.3.2 服务预约流程设计
用户进入服务项目列表查看项目详情。选定具体服务项目后填写预约信息。系统检查该时段预约名额是否充足。名额不足时提示用户调整预约时间。名额充足则保存预约记录并生成待支付订单。用户完成支付操作后预约状态变更为已确认。系统同时向服务人员推送新预约通知。服务预约流程如图4-4所示。
图4-4服务预约流程图
4.3.3 服务派单流程设计
管理人员进入待派单列表查看未处理预约。系统根据服务类型自动筛选合适服务人员。管理人员确认人员指派信息并提交派单指令。系统变更预约状态为已派单并记录派单时间。被指派的服务人员收到派单消息提醒。服务人员接单后开始准备上门服务。管理人员可通过派单查询跟踪任务执行进度。服务派单流程如图4-5所示。
图4-5服务派单流程图
4.3.4 服务评价流程设计
服务完成后用户进入评价填写页面。系统展示已完成服务的列表供用户选择。用户选择目标服务记录后填写评价内容。用户给出满意度等级并提交评价表单。系统保存评价信息并将服务状态更新为已评价。管理员后台审核评价内容是否合规。审核通过后评价信息在前台公开显示。服务评价流程如图4-6所示。
图4-6服务评价流程图
4.3.5 健康监测流程设计
老人用户或管理人员进入健康监测模块。系统展示老人基本信息列表供选择录入。用户选择特定老人后填写各项监测数据。系统校验血压心率等数据的数值范围。数据异常时提示录入人员重新测量确认。数据正常则保存监测记录至数据库。老人用户可随时查询历史监测数据变化。健康监测流程如图4-7所示。
图4-7健康监测流程图
4.4 数据库设计
数据库设计是在系统规划阶段，根据业务需求把现实世界中的实体、属性和关系抽象成数据模型的过程。设计者先找出实体及其属性，确定主键和外键之间的联系，然后根据性能目标选择字段类型、索引方式、分区方案、存储引擎等，并给出可以直接部署的物理结构，从而保证数据完整性和查询效率，同时具有未来可扩展性**18**。
4.4.1 E-R图设计
实体图是用图形化的方式表现业务要素以及它们之间的联系的一种数据建模工具，在数据库设计阶段把需求转化为结构化的可视化表示。它把节点对应业务实体，边对应实体间的关联关系，在节点内列出关键属性，直观地展示了数据模型的全貌，可以很快找到冗余、理清依赖，给逻辑设计和物理实现提供清晰的蓝图。下面将给出系统全局实体图以及各个主要实体的属性图。
老人用户实体主要包括老人用户id、用户id、老人姓名、老人性别、老人电话、审核状态等。实体属性图如图4-8所示。
图4-8老人用户实体属性图
服务预约实体主要包括服务预约id、老人用户、项目名称、项目类型、服务价格、预约日期、支付状态、派单限制次数等。实体属性图如图4-9所示。
图4-9服务预约实体属性图
服务人员实体主要包括服务人员id、用户id、人员姓名、人员性别、人员电话、审核状态等。实体属性图如图4-10所示。
图4-10服务人员实体属性图
服务派单实体主要包括服务派单id、老人用户、服务人员、项目名称、服务价格、预约日期、客户要求、状态限制次数等。实体属性图如图4-11所示。
图4-11服务派单实体属性图
服务项目实体主要包括服务项目id、项目名称、项目类型、服务价格、服务简介、预约限制次数、智能推荐等。实体属性图如图4-12所示。
图4-12服务项目实体属性图
健康监测实体主要包括健康监测id、老人用户、血压数值、血脂数值、心率数值、录入日期、录入备注等。实体属性图如图4-13所示。
图4-13健康监测实体属性图
服务评价实体主要包括服务评价id、老人用户、服务人员、满意程度、评价内容、服务状态等。实体属性图如图4-14所示。
图4-14服务评价实体属性图
服务状态实体主要包括服务状态id、老人用户、服务人员、服务状态、状态描述、评价限制次数等。实体属性图如图4-15所示。
图4-15服务状态实体属性图
用户账户实体主要包括用户id、用户名、密码、用户组、账户状态、上次登录时间等。实体属性图如图4-16所示。
图4-16用户账户实体属性图
项目类型实体主要包括项目类型id、项目类型、创建用户id等。实体属性图如图4-17所示。
图4-17项目类型实体属性图
留言板实体主要包括留言板id、用户id、昵称、内容、回复、回复状态等。实体属性图如图4-18所示。
图4-18留言板实体属性图
文章实体主要包括文章id、标题、正文、文章分类、点击数、点赞数等。实体属性图如图4-19所示。
图4-19文章实体属性图
系统E-R图如图4-20所示。
图4-20系统E-R图
4.4.2 数据库表设计
据库表设计就是根据业务需求确定数据库表结构、字段类型以及相互之间的关系。经过规范化的设计之后，可以保证数据的完整性、一致性以及高效性，还可以防止出现重复的数据，并且可以给后面的数据查询、存储以及维护工作提供一个清晰的架构**19**。以下是系统的数据库表设计展示。
老人用户表主要是用来存储老人身份信息与账户关联数据。主要包括老人用户id、用户id、老人姓名、老人电话等字段。如表4-1所示。
表4-1老人用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | elderly_users_id | int | 11 | 是 | 是 | 老人用户id |
| 2 | user_id | int | 11 | 是 | 否 | 用户id |
| 3 | old_mans_name | varchar | 64 | 否 | 否 | 老人姓名 |
| 4 | gender_of_the_elderly | varchar | 64 | 否 | 否 | 老人性别 |
| 5 | old_man_phone | varchar | 64 | 否 | 否 | 老人电话 |
| 6 | create_by | int | 11 | 是 | 否 | 创建用户id |
| 7 | create_time | timestamp | - | 是 | 否 | 创建时间 |
| 8 | update_time | timestamp | - | 是 | 否 | 更新时间 |
| 9 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
服务预约表主要是用来记录老人用户提交的项目预约申请。主要包括服务预约id、老人用户、项目名称、预约日期等字段。如表4-2所示。
表4-2服务预约表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_reservation_id | int | 11 | 是 | 是 | 服务预约id |
| 2 | elderly_users | int | 11 | 否 | 否 | 老人用户 |
| 3 | project_name | varchar | 64 | 否 | 否 | 项目名称 |
| 4 | project_type | varchar | 64 | 否 | 否 | 项目类型 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | appointment_date | date | - | 否 | 否 | 预约日期 |
| 7 | appointment_remarks | text | 65535 | 否 | 否 | 预约备注 |
| 8 | pay_state | varchar | 16 | 是 | 否 | 支付状态 |
服务人员表主要是用来存储服务人员身份信息与资格状态。主要包括服务人员id、用户id、人员姓名、人员电话等字段。如表4-3所示。
表4-3服务人员表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_personnel_id | int | 11 | 是 | 是 | 服务人员id |
| 2 | user_id | int | 11 | 是 | 否 | 用户id |
| 3 | name_of_personnel | varchar | 64 | 否 | 否 | 人员姓名 |
| 4 | gender_of_staff | varchar | 64 | 否 | 否 | 人员性别 |
| 5 | personnel_telephone | varchar | 64 | 否 | 否 | 人员电话 |
| 6 | create_by | int | 11 | 是 | 否 | 创建用户id |
| 7 | create_time | datetime | - | 是 | 否 | 创建时间 |
| 8 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
服务派单表主要是用来记录管理员分配给服务人员的任务信息。主要包括服务派单id、老人用户、服务人员、项目名称、预约日期等字段。如表4-4所示。
表4-4服务派单表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_dispatch_id | int | 11 | 是 | 是 | 服务派单id |
| 2 | elderly_users | int | 11 | 否 | 否 | 老人用户 |
| 3 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 4 | project_name | varchar | 64 | 否 | 否 | 项目名称 |
| 5 | service_price | double | - | 否 | 否 | 服务价格 |
| 6 | appointment_date | date | - | 否 | 否 | 预约日期 |
| 7 | customer_requirements | text | 65535 | 否 | 否 | 客户要求 |
| 8 | service_status_limit_times | int | 11 | 是 | 否 | 状态限制次数 |
服务项目表主要是用来存储可供预约的服务类型与定价信息。主要包括服务项目id、项目名称、项目类型、服务价格、服务简介等字段。如表4-5所示。
表4-5服务项目表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_item_id | int | 11 | 是 | 是 | 服务项目id |
| 2 | project_name | varchar | 64 | 否 | 否 | 项目名称 |
| 3 | project_type | varchar | 64 | 否 | 否 | 项目类型 |
| 4 | service_price | double | - | 否 | 否 | 服务价格 |
| 5 | service_introduction | longtext | 4294967295 | 否 | 否 | 服务简介 |
| 6 | cover_image | varchar | 255 | 否 | 否 | 封面图片 |
| 7 | hits | int | 11 | 是 | 否 | 点击数 |
| 8 | service_reservation_limit_times | int | 11 | 是 | 否 | 预约限制次数 |
健康监测表主要是用来存储老人的生理指标测量记录。主要包括健康监测id、老人用户、血压数值、心率数值、录入日期等字段。如表4-6所示。
表4-6健康监测表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | health_monitoring_id | int | 11 | 是 | 是 | 健康监测id |
| 2 | elderly_users | int | 11 | 否 | 否 | 老人用户 |
| 3 | blood_pressure_value | double | - | 否 | 否 | 血压数值 |
| 4 | heart_rate_value | double | - | 否 | 否 | 心率数值 |
| 5 | blood_lipuser_id_value | double | - | 否 | 否 | 血脂数值 |
| 6 | entry_date | date | - | 否 | 否 | 录入日期 |
| 7 | enter_comments | text | 65535 | 否 | 否 | 录入备注 |
服务评价表主要是用来存储用户对已完成服务的满意度反馈。主要包括服务评价id、老人用户、服务人员、满意程度、评价内容等字段。如表4-7所示。
表4-7服务评价表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | service_evaluation_id | int | 11 | 是 | 是 | 服务评价id |
| 2 | elderly_users | int | 11 | 否 | 否 | 老人用户 |
| 3 | service_personnel | int | 11 | 否 | 否 | 服务人员 |
| 4 | degree_of_satisfaction | varchar | 64 | 否 | 否 | 满意程度 |
| 5 | evaluation_content | text | 65535 | 否 | 否 | 评价内容 |
| 6 | service_status | varchar | 64 | 否 | 否 | 服务状态 |
用户账户表主要是用来存储系统登录账号与身份认证信息。主要包括用户id、用户名、密码、用户组、账户状态等字段。如表4-8所示。
表4-8用户账户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | user_id | int | 11 | 是 | 是 | 用户id |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | password | varchar | 64 | 是 | 否 | 密码 |
| 4 | nickname | varchar | 16 | 否 | 否 | 昵称 |
| 5 | user_group | varchar | 32 | 否 | 否 | 用户组 |
| 6 | state | smallint | 6 | 是 | 否 | 账户状态 |
| 7 | login_time | timestamp | - | 否 | 否 | 上次登录时间 |
项目类型表主要是用来对服务项目进行分类管理。主要包括项目类型id、项目类型等字段。如表4-9所示。
表4-9项目类型表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | project_type_id | int | 11 | 是 | 是 | 项目类型id |
| 2 | project_type | varchar | 64 | 否 | 否 | 项目类型 |
| 3 | create_by | int | 11 | 是 | 否 | 创建用户id |
| 4 | create_time | datetime | - | 是 | 否 | 创建时间 |
留言板表主要是用来存储用户的投诉建议与管理员回复内容。主要包括留言板id、用户id、昵称、内容、回复、回复状态等字段。如表4-10所示。
表4-10留言板表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | message_id | int | 11 | 是 | 是 | 留言板id |
| 2 | user_id | int | 11 | 是 | 否 | 用户id |
| 3 | nickname | varchar | 32 | 是 | 否 | 昵称 |
| 4 | content | longtext | 4294967295 | 是 | 否 | 内容 |
| 5 | reply | longtext | 4294967295 | 否 | 否 | 回复 |
| 6 | reply_state | tinyint | 4 | 否 | 否 | 回复状态 |
文章表主要是用来存储新闻资讯与健康科普内容。主要包括文章id、标题、正文、文章分类、点击数等字段。如表4-11所示。
表4-11文章表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | article_id | mediumint | 9 | 是 | 是 | 文章id |
| 2 | title | varchar | 125 | 是 | 是 | 标题 |
| 3 | content | longtext | 4294967295 | 否 | 否 | 正文 |
| 4 | description | text | 65535 | 否 | 否 | 文章描述 |
| 5 | type | varchar | 64 | 是 | 否 | 文章分类 |
| 6 | hits | int | 11 | 是 | 否 | 点击数 |
第五章 系统实现
5.1 老人用户功能实现
5.1.1 登录注册功能实现
用户在系统使用前完成身份认证。登录环节需要输入用户名和密码，系统核对数据库存储的凭证信息。新用户通过注册页面填写基本信息即可创建账户。注册过程采集必要资料，为后续服务预约做好准备。登录注册界面如图5-1所示。
图5-1登录注册界面
5.1.2 服务项目预约功能实现
老人用户通过该模块浏览机构提供的各类养老服务。用户查看项目详情页，了解服务内容、价格与时长。选定项目后填写预约时间与特殊需求，系统生成预约申请单。申请成功提交后进入等待审核环节。服务项目预约界面如图5-2所示。
图5-2服务项目预约界面
5.1.3 新闻资讯查询功能实现
养老动态与健康知识集中展现在该模块。老人用户点击资讯分类标签，筛选感兴趣的文章内容。文章列表按发布时间倒序排列，点击标题跳转详情页面查看完整信息。系统记录阅读次数用于热门推荐。新闻资讯查询界面如图5-3所示。
图5-3新闻资讯查询界面
5.1.4 投诉建议功能实现
老人用户遇到服务问题时可在此模块提交反馈信息。用户填写投诉标题与详细内容，描述具体不满事项。系统将留言存入数据库并标记为待处理状态。管理员回复后用户可以查看反馈结果。投诉建议界面如图5-4所示。
图5-4投诉建议界面
5.1.5 服务派单查询功能实现
老人用户追踪已提交服务的派单进度。系统展示用户历史预约记录列表，每条记录附带当前派单状态。用户点击某条记录查看派单详情，包括服务人员姓名与预计到达时间。状态变更时同步推送消息。服务派单查询界面如图5-5所示。
图5-5服务派单查询界面
5.1.6 服务状态查询功能实现
该模块让老人用户掌握服务执行的每个阶段。系统将派单状态分为待接单、服务中、已完成多个环节。用户查看当前进行中的任务，了解服务人员是否已出发或者正在提供帮助。服务状态查询界面如图5-6所示。
图5-6服务状态查询界面
5.1.7 服务评价功能实现
服务完成后老人用户在此模块表达满意度。用户选择星级评分选项，填写文字反馈描述服务体验。系统将评价内容关联到对应的服务人员与服务项目。评价提交后自动更新服务人员的综合评分。服务评价界面如图5-7所示。
图5-7服务评价界面
5.1.8 健康检测功能实现
老人用户录入日常生理指标数据构建个人健康档案。血压与心率数值通过表单提交，系统对输入范围进行合理性校验。用户查看历史测量记录生成的变化趋势图表。异常数据会触发提示信息。健康检测界面如图5-8所示。
图5-8健康检测界面
5.2 服务人员功能实现
5.2.1 服务派单管理功能实现
服务人员接收管理员分配的服务任务。系统展示待接单列表与已接单任务区。服务人员选择任务后点击接单按钮，任务状态转变为执行中。系统记录接单时间并推送通知至老人用户端。服务派单管理界面如图5-9所示。
图5-9服务派单管理界面
5.2.2 服务状态查询功能实现
服务人员更新当前任务的执行进度。系统提供路上、服务中、服务完成三个状态选项。服务人员根据实际工作阶段选择对应状态提交。每次状态变更生成时间戳记录，老人用户端同步收到通知。服务状态查询界面如图5-10所示。
图5-10服务状态查询界面
5.2.3 服务评价查询功能实现
服务人员查看用户对自己服务的反馈内容。系统展示个人综合评分与近期评价记录列表。每条评价显示评分等级与文字反馈，服务人员无法修改或删除评价内容。这些数据为服务改进提供参考。服务评价查询界面如图5-11所示。
图5-11服务评价查询界面
5.2.4 服务项目查询功能实现
服务人员浏览可以提供的服务项目列表。系统按项目类型分类展示，点击进入详情页查看服务简介与价格。服务人员了解服务内容后在执行任务时向老人用户解释。该模块帮助人员熟悉机构服务范围。服务项目查询界面如图5-12所示。
图5-12服务项目查询界面
5.3 管理员功能实现
5.3.1 数据分析功能实现
管理员查看系统运营核心指标的可视化看板。当日预约数量与待处理派单数量直观展示。系统绘制近一周服务预约趋势曲线与服务完成率变化图。管理员通过图表数据掌握业务动态，为决策提供依据。数据分析界面如图5-13所示。
图5-13数据分析界面
5.3.2 服务项目管理功能实现
管理员维护机构可提供的服务内容。添加新项目时填写服务名称与价格简介，编辑功能修改现有项目的各项属性。下架操作将项目从用户端隐藏，已存在预约不受影响。该模块保证服务资源配置灵活。服务项目管理界面如图5-14所示。
图5-14服务项目管理界面
5.3.3 服务预约管理功能实现
管理员处理老人用户提交的预约申请。待审核列表展示用户预约详情与期望服务时间。审核通过后预约状态变更为待派单，驳回时需要填写理由通知用户修改。该模块保证预约质量管控。服务预约管理界面如图5-15所示。
图5-15服务预约管理界面
5.3.4 服务派单管理功能实现
管理员将审核通过的预约任务指派给服务人员。系统根据服务类型与人员当前任务量推荐合适人选。管理员确认指派后生成派单记录，服务人员端收到任务推送。派单历史可追溯查询。服务派单管理界面如图5-16所示。
图5-16服务派单管理界面
5.3.5 服务评价管理功能实现
管理员审核用户提交的评价内容。待审核列表展示评分与文字反馈，通过后评价在前端正常显示。涉及不当言辞的评价进行隐藏或删除处理。该模块维护平台评价体系健康。服务评价管理界面如图5-17所示。
图5-17服务评价管理界面
5.3.6 健康监测管理功能实现
管理员查看所有老人的健康数据汇总记录。按老人姓名筛选历史测量数据，查看各项指标的变化趋势。系统支持导出月度健康报表用于统计分析。异常数据可标记提醒家属关注。健康监测管理界面如图5-18所示。
图5-18健康监测管理界面
5.3.7 留言管理功能实现
管理员回复用户提交的投诉建议内容。未回复留言显示待处理标签，点击回复按钮填写处理意见。回复后留言状态变更为已回复，用户端可查看回复内容。重复提交的留言可合并处理。留言管理界面如图5-19所示。
图5-19留言管理界面
第六章 系统测试
6.1 测试目的
系统测试工作对社区养老平台各个功能模块的实现情况，即其是否达到设计要求进行检验。服务预约从提交申请到派单完成的全部流程要查看是否存在数据断层或者状态丢失的情况。边界校验测试是对系统对异常输入的处理能力进行测试，用户填写不合理的预约日期或者健康数值超出正常范围时，系统应该给出明确提示而不会出现崩溃。跨表操作的事务一致性也要进行检验，派单生成过程中老人信息和服务人员数据都要写入相应的数据表。本次测试结果用来评判系统是否可以投入运行。
6.2 测试方法
系统测试使用黑盒测试方法，所有的测试用例都是按照需求文档的要求来设计的，并且不涉及内部代码的实现细节。功能测试包含老人用户端、服务人员端、管理员端三个角色的主要操作路径，每一个模块设置一组正常的流程用例来检验预期的行为。异常流程测试用例专门用来处理表单字段为空提交、超过预约次数限制、重复接单等边界情况。集成测试是对各个模块之间数据流转的正确性进行测试，服务预约完成后派单生成、评价推送等都属于验证范围。回归测试是在缺陷修复之后，对受该缺陷影响的所有用例进行重新执行20。
6.3 测试内容
6.3.1 服务项目预约功能测试
该模块测试主要验证老人用户提交服务预约申请时系统对预约信息的处理逻辑。测试关注预约申请的合法性校验功能，确保超出可预约次数或选择无效日期时系统能够正确拦截。预约申请成功后的数据持久化存储与状态初始化流程也在验证范围内。服务项目预约测试如表6-1所示。
表6-1服务项目预约测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 服务项目预约 | 正常预约流程 | 选择项目填写信息并提交 | 生成待审核预约记录 | 符合预期 | 测试成功 |
| 服务项目预约 | 超出预约次数限制 | 提交已满额项目 | 系统提示不可预约 | 符合预期 | 测试成功 |
| 服务项目预约 | 预约日期为空 | 不选择日期直接提交 | 提示补充预约日期 | 符合预期 | 测试成功 |
6.3.2 服务派单管理功能测试
该模块测试验证管理员将审核通过的预约任务指派给服务人员的操作流程。测试关注派单过程中系统对服务人员任务负载的判断逻辑，确保推荐算法能够筛选出合适的执行人员。派单生成后服务人员端是否收到推送通知也在验证范围内。服务派单管理测试如表6-2所示。
表6-2服务派单管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 服务派单管理 | 管理员指派人员 | 选择待派单任务分配人员 | 生成派单记录 | 符合预期 | 测试成功 |
| 服务派单管理 | 服务人员接单 | 服务人员点击接单按钮 | 任务状态变更为已接单 | 符合预期 | 测试成功 |
| 服务派单管理 | 服务人员拒单 | 服务人员点击拒单按钮 | 任务重新进入待派单队列 | 符合预期 | 测试成功 |
6.3.3 服务状态查询功能测试
该模块测试验证老人用户与服务人员对服务执行进度的追踪能力。测试关注状态变更后前端界面是否及时刷新展示最新阶段。老人用户端与服务人员端的状态展示一致性也在验证范围内，确保双方看到的进度信息同步。服务状态查询测试如表6-3所示。
表6-3服务状态查询测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 服务状态查询 | 老人查询进度 | 进入服务状态页面查看列表 | 展示预约记录与状态标签 | 符合预期 | 测试成功 |
| 服务状态查询 | 服务人员更新状态 | 选择任务更新执行阶段 | 状态变更并记录时间戳 | 符合预期 | 测试成功 |
| 服务状态查询 | 状态推送同步 | 服务人员更新状态后查看用户端 | 老人用户端同步显示新状态 | 符合预期 | 测试成功 |
6.3.4 服务评价功能测试
该模块测试验证服务完成后老人用户提交满意度反馈的完整流程。测试关注评价内容提交后系统是否正确更新服务项目与服务人员的评分统计数据。评价内容包含不当言论时管理员的审核功能与隐藏处理逻辑也在验证范围内。服务评价测试如表6-4所示。
表6-4服务评价测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 服务评价 | 正常提交评价 | 服务完成后填写评分与反馈 | 评价内容成功保存 | 符合预期 | 测试成功 |
| 服务评价 | 无评分提交 | 不选择星级直接提交 | 系统提示选择评分等级 | 符合预期 | 测试成功 |
| 服务评价 | 管理员审核评价 | 对不当言论评价进行隐藏 | 前端不再显示该评价 | 符合预期 | 测试成功 |
6.3.5 健康检测功能测试
该模块测试验证老人用户录入日常生理指标数据时的系统处理逻辑。测试关注数值超出正常范围时系统的提示功能与数据拦截效果。用户提交后的测量数据是否正确存储到个人健康档案并在历史记录中展示也在验证范围内。健康检测测试如表6-5所示。
表6-5健康检测测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 健康检测 | 正常录入数据 | 填写血压心率等指标后提交 | 数据保存成功并展示 | 符合预期 | 测试成功 |
| 健康检测 | 数值超出正常范围 | 输入异常数值提交 | 系统弹出警告提示 | 符合预期 | 测试成功 |
| 健康检测 | 查看历史趋势 | 点击趋势图展示按钮 | 生成近期变化折线图 | 符合预期 | 测试成功 |
6.3.6 服务项目管理功能测试
该模块测试验证管理员对服务项目信息进行增删改查操作的正确性。测试关注新增项目后用户端是否能够正常查看。编辑现有项目的价格与预约上限次数时系统的数据更新逻辑与生效时间也在验证范围内。服务项目管理测试如表6-6所示。
表6-6服务项目管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 服务项目管理 | 添加新项目 | 填写项目名称价格后提交 | 新增项目在列表中展示 | 符合预期 | 测试成功 |
| 服务项目管理 | 编辑项目信息 | 修改现有项目价格并保存 | 价格更新且前端显示新值 | 符合预期 | 测试成功 |
| 服务项目管理 | 下架项目 | 将项目状态设置为下架 | 用户端不再显示该项目 | 符合预期 | 测试成功 |
6.3.7 留言管理功能测试
该模块测试验证管理员回复用户提交的投诉建议留言的完整流程。测试关注用户提交留言后的存储状态与管理员回复后的状态变更同步。用户端是否能够正确查看已回复留言的管理员反馈内容也在验证范围内。留言管理测试如表6-7所示。
表6-7留言管理测试用例表
| 模块名称 | 测试内容 | 操作 | 预期结果 | 实际结果 | 结论 |
|---|---|---|---|---|---|
| 留言管理 | 用户提交留言 | 填写投诉标题与内容后提交 | 记录存入数据库标记待处理 | 符合预期 | 测试成功 |
| 留言管理 | 管理员回复留言 | 输入回复内容完成处理 | 留言状态变更为已回复 | 符合预期 | 测试成功 |
| 留言管理 | 用户查看已回复留言 | 进入历史留言列表 | 显示管理员回复内容 | 符合预期 | 测试成功 |
测试结论
对七项核心功能模块所有的测试用例进行测试。服务项目预约模块在正常流程以及边界条件之下，按照预期的逻辑运转，当预约超出了限制的时候，系统就会给出明确的拦截提示。服务派单验证了任务指派和接单拒单的全过程，派单生成之后服务人员端会同步收到任务信息。服务状态查询与评价模块状态变更通知功能测试通过，用户端显示的内容一样。健康检测模块对异常值进行校验和提示工作达到预期效果，超出正常范围的数据得到正确的拦截。服务项目管理以及留言管理的增删改查操作完成之后，数据被更新之后，前端界面就会随之刷新。所有的被测模块实际输出结果都和预期结果一致。