后勤管理移动应用系统设计研究

时间:2022-07-06 09:32:07

后勤管理移动应用系统设计研究

摘要:为高校师生提供更为优质的服务是高校后勤管理的根本目标之一。结合高校后勤服务要求与应用场景,从体系架构、功能架构、系统用例和数据库设计等方面介绍了一种高校后勤管理移动应用系统的设计。系统能够突破基于PC端后勤管理信息系统所具有的时空局限性,能为高校后勤管理水平和整体服务质量提升提供强有力的支持。

关键词:高校;后勤管理;移动应用

1引言

在高校后勤管理方式中,传统的基于PC端的后勤管理系统将后勤服务搬到了网络上,通过工作流等技术手段,可以实现办事流程的规范化;以数据集中存储管理方式,能够有效降低数据冗余;借助计算机的演算能力,能够快速获取如设备损坏率等统计分析结果,从而有效提高后勤管理人员的工作效率,拉近了师生与后勤管理人员的距离。然而仍存在时效性低、信息交互不及时、访问方式受限等问题。高校作为高素质人才的聚集地,接受新生事物的能力较强,移动智能终端因其实用性、多样性和低成本等特点,已基本实现了全范围覆盖[1]。因此,借助移动互联网强大、便捷的信息交互特点,建立一个应用于高校后勤管理的移动应用系统显得非常重要且切实可行。本文结合校园后勤经营服务的要求和实际情况,设计高校后勤管理移动应用系统,将传统的桌面终端后勤服务提升为“掌上后勤”服务,通过移动终端实现校园设施故障报修、通知公告信息推送,能够有效解决传统PC端后勤管理系统的时空受限问题,进一步拉近师生与后勤部门间的距离,从而使得后勤服务水平更上一个台阶。

2系统架构

本文设计的高校后勤管理移动应用系统采用B/S架构,系统的服务器端采用Java语言来实现,数据库选用MySQL,用户可通过手机、平板电脑和PC访问系统,通过采用前后端分离的方式提升系统的可扩展性,系统总体架构图如图1所示。系统的低耦合性能使系统具有更好的可扩展性和可维护性[2],本文将系统划分为接口层、数据转换层、数据存储层、应用层和表现层五个层次。接口层实现与高校其他应用系统的数据共享,如从学籍管理系统或职工管理系统中获取师生用户数据,提供后勤服务人员的评价数据接口供职工管理系统调用等;数据转换层负责对接口数据进行清理、更新与转换,实现数据共享;数据存储层负责保存系统的基础数据和业务数据,包含结构化数据与非结构化数据两类;应用层提供如故障报修、通知公告等系统所包含的功能;展示层为用户提供数据查询和操作的界面,用户可以通过手机、平板电脑和PC电脑等设备访问系统。

3系统设计

3.1系统功能设计。基于高校后勤服务原则与要求,结合后勤服务的应用场景,本文所设计的高校后勤管理移动应用系统包含一套基于B/S架构的服务器端管理系统与能够通过智能移动终端访问的移动应用端APP系统,系统功能分为系统管理、业务管理和统计分析三个类别,细分为系统管理、故障报修、通知公告、失物寻物、办事指南和统计分析六个模块。系统功能结构如图2所示。系统管理包含用户管理、角色管理和权限管理三个子模块,系统用户包括高校学生、教师和后勤服务群体,用户管理模块与学籍管理系统和职工管理系统实现对接,学生的信息直接从学籍管理系统中获取,教师与后勤人员的信息直接从职工管理系统中获取,从而有效促进信息共享,避免数据孤岛的形成,系统管理模块为系统中的其他功能提供支撑。故障报修功能包括故障报修单管理、维修工单管理、服务评价管理三个子模块,实现故障报修全流程管理,师生可通过智能移动终端快速便捷地上报校园设施故障。通知公告管理实现后勤相关通知信息的,通过消息推送,使高校师生及时掌握校园后勤服务动态。失物寻物包括失物招领和寻物启事两个子模块,构建失物寻物信息平台,提高用户寻回失物的可能性。办事指南管理对后勤办事步骤和详情进行说明,使师生了解后勤服务流程和后勤服务事项,提升后勤服务效率与水平。统计分析包括服务人员评价统计和设施故障率统计两个子模块,为决策人员提供更为科学的理论依据。3.2系统用例。依据对系统功能架构的分析,高校后勤管理移动应用系统中的用户有教师、学生、后勤人员三类,根据不同的系统功能,参与人员的角色各不相同,可依据不同的角色来划分系统模型。高校后勤管理移动应用系统的角色分为报修员、维修员、审核员、公告录入员、失主、拾主、决策人员和系统管理员,值得注意的是,同一用户可以具有多个角色,如学生可以是报修人员,也可以是失主或者拾主,审核员可以审核通知公告,也可以审核失主的信息等。系统用例图如图3所示。以故障报修功能为例,参与的角色为报修员、审核员和维修员,报修员可以为高校师生群体,审核员为后勤管理人员,维修员为后勤服务人员。当师生在校园内发现某设施出现故障,需要进行维修时,借助手机等智能移动终端,登录后勤管理系统移动APP,进入故障报修模块,填写如设施类型、问题描述等故障基本信息,支持拍照上传图片,提交故障信息后,由后勤审核人员对所提交的信息进行审核确认,根据故障描述内容以确定是否受理,对于不受理的维修申请,必须填写不予受理的理由,对于受理的维修申请,应根据描述指派适合的维修人员,维修人员接收到维修单信息后,即可前往故障所在地进行处置,待维修完成后,反馈维修结果,最后由报修人员对该次故障维修工单处置结果进行评价,评价结果纳入后勤人员考核标准中。3.3数据库设计。本文所设计的后勤管理移动应用系统在运行过程中需要如用户信息、功能菜单等基础数据提供支撑,同时,会产生如故障报修单、失物招领信息等大量业务数据,因此,需要使用数据库进行集中管理。数据库设计应结合应用场景,从现实场景抽象实体与实体之间的关系,秉承原子性、原始性和稳定性等要求,确保数据库设计的高度结构化[3]。图4为故障报修实体关系图。在本文设计的高校后勤管理移动应用系统中,由于一个故障问题可能需要多个后勤维修人员多次参与,因此,一个故障报修单可以创建多个维修工单,而一个维修工单只能对应一个故障报修单,故障报修单与维修工单之间的关系为一对多。一条服务评价对应一个维修工单,一个维修工单对应一个服务评价,服务评价与维修工单之间的关系为一对一。

4结语

本文简要介绍了一种高校后勤管理移动应用系统的设计。通过系统架构层次划分,降低系统耦合度,接口层的设计能够推动高校内信息共享,提升资源利用率;结合高校后勤服务场景,设计了系统应具有的功能模块;通过角色与功能模块之间的关系,描述了系统用例设计,并借助实体关系模型描述了部分数据库的设计。本文借助移动互联网技术,提供了一个具有移动性和高效性的高校后勤移动应用解决方案,在传统的基于PC端的后勤管理系统的基础上,丰富了服务手段,进一步降低了后勤沟通成本,提高了高校后勤服务水平。

参考文献

[1]王礼云.高校校园“微信平台”的舆情监控与引导[J].赢未来,2017(12):0011.

[2]聂常红,张屹,李宝智.基于Struts2的MVC模式在高校科研管理系统中的应用[J].电子技术与软件工程,2015(1):95-97.

[3]陈宝贤.数据库应用与程序设计教程[M].北京:人民邮电出版社,2004.

作者:黄振兴 单位:湖北工业大学