报修系统范文

报修系统范文（精选11篇）

报修系统 第1篇

目前,随着日常办公设备的广泛使用,办公设备的维修成为管理人员普遍关心的问题,办公设备维修管理流程的信息化、规范化成为发展趋势。传统办公设备维修管理主要依靠在纸质媒介上人工记录信息,电话分配任务甚至面对面分配任务的方式,从而造成效率低下、易出现疏漏等情况;因此开发一套在线报修管理系统,以达到办公设备或设施出现故障或隐患时,职工发现问题时能快速、直观、准确的报送给相关负责部门,维修部门能够及时知悉详细情况并进行快速维护,并在维修结束完成后能迅速反馈结果,从报修到维修完毕形成规范的流程,以提高工作效率。

2 系统整体设计

在线报修管理系统对办公设备故障后报修的事务流程进行管理,以形成有序的、高效的运作方式。

2.1 系统总体结构

在线报修管理系统总体结构图如图1所示,该系统主要分为报修管理功能模块、系统管理功能模块、查询统计功能模块。

2.2 系统各模块功能

报修管理功能模块:用户提出报修申请时,系统生成报修单,要求用户填写相关信息;生成报修流程中各节点任务;维修完成后生成反馈单。

系统管理功能模块:主要分为用户管理、基础信息配置和通知公告管理三大块。用户管理,包括添加、删除用户,更改用户信息等;基础信息管理,包括添加、删除现有办公设备,配置系统运行环境等;通知公告管理,包括通知发布、更新、删除等。

查询统计功能模块:不同权限用户根据不同查询条件,查询报修记录、设备故障等信息;管理人员根据报修情况统计设备信息,统计单位时间内同一设备的故障率,从而判定设备性能,为办公设备预防性维护提供数据参考。

2.3 报修流程

报修管理功能完成报修流程的控制,流程各个节点的任务分配;生成报修单和报修反馈单。报修任务的流程图如图22所示

报修人员通过浏览器登录自己的账户,登录系统,启动报修任务,填写报修信息,描述故障情况,提交任务;维修任务完成,收到反馈提醒后填写反馈单,评价维修质量,提交后完成整个报修任务流程。在整个任务流程中,普通用户需要完成“启动任务”和“评价反馈”两个节点任务。

维修管理人员登录系统后,如收到报修任务,评估任务紧迫性,对多个任务进行排序,向维修人员下发任务;维修任务完成,收到用户的反馈单后,审核完毕存入系统数据库。维修管理人员可以查询数据,进行统计分析,以便排查办公设备可能发生的故障或存在隐患;与厂商沟通要求协助处理或要求厂商派遣维护人员;对于重大故障或隐患提交至相关上一级领导。

维修人员登录系统后,可收到报修提醒,根据报修单上的相关信息,开始维修,维修完成后申请反馈单,发送至报修用户处;如有不能解决的问题,提交给维修管理人员,以便联系厂商或上报上一级领导。

2.4 系统架构设计

系统软件架构设计中,采用和遵循三层架构设计模式,以降低各功能模块间的耦合程度,依次为:界面层(User Interface layer)UIL、业务逻辑层(Business Logic Layer)BLL和数据访问层(Data access layer)DAL。业务逻辑层定义了实现业务逻辑功能的类:人员管理、部门管理、报修单管理、公告管理、设备管理、维护信息管理、数据列表操作等。数据访问层定义类DataBase.cs,实现连接数据库、对数据库的读、写等功能。

2.5 界面设计

在用户界面部分,根据需求分析的结果,用户界面友好、易操作。在界面设计上,做到简单明了,易于操作,并且要注意到界面的布局,突出显示重要以及出错信息,同时保证各个页面美观大方,风格统一。本系统在用户界面设计中,使用母版页,公共信息显示在母版页上,以做到系统各页面风格统一。

3 数据库设计

根据在线报修管理系统的功能数据逻辑结构设计,分为报修表单、维修信息表单、公告信息表单、用户信息表单。

1)报修表单(ORMS_Repair):报修编号、用户名、用户所在部门、用户电话、设备名称、设备地点、报修时间、故障描述、等级、维修状态、维修人员。

2)维修信息表单(ORMS_Maintain):维修编号、报修编号、维修人员、处理情况、处理时间、维修状态、维修费用、用户评价、用户意见、评价时间。

3)公告信息表单(ORMS_News):公告编号、公告名、用户ID、公告内容、更新时间。

4)用户信息表单(ORMS_User):用户名、用户密码、用户角色、用户姓名、用户部门、用户电话。

4 系统实现

在线报修管理系统采用B/S模式设计,由用户端、Web服务器、数据库服务器构成。

4.1 系统开发环境

数据库系统:Windows2003 Server、安装SQLserver2008

开发环境:Microsoft Visual Studio 2010,ASP.NET 4.0,C#

Web服务器系统:Windows7, 安装IE6、安装IIS7、安装Frame Work4

4.2 实际运行效果

报修管理:管理人员对报修任务进行审核,划分故障等级,向维修人员下发维修任务,并决定是否向上一级领导汇报。效果如图33所示,类型统计效果如图44所示。

5 结束语

本系统从日常办公的实际需求出发,架构设计遵循三层架构模式,提高系统架构的明确性、层次性和标准性;权限设计时充分考虑实际办公模式,提高系统管理功能的有效性和科学性;界面设计时充分考虑用户的操作习惯,以提高易用程度。在今后管理系统的运行过程中,将根据工作需求逐步完善,以达到提高工作效率的目的。

摘要：基于ASP.NET的在线报修管理系统致力于解决当前办公设备报修、维修流程信息化、规范化的问题,该系统采用了B/S模式实现,使用ASP.NET 4.0和SQL Server2008开发。该文从系统的整体设计、功能模块设计、流程设计、架构设计、界面设计、数据库设计、系统实现等方面详细介绍了在线报修管理系统设计和实现过程。该系统的运用在一定程度上提高了办公设备维修的效率。

关键词：管理系统,维修,办公设备,ASP.NET,设计

参考文献

[1]张正礼,王坚宁.ASP.NET从入门到精通[M].北京:清华大学出版社,2011.

[2]Paul Nielsen.SQL Server2008宝典[M].北京:清华大学出版社,2011.

[3]陆凌牛.HTML5与CSS3权威指南[M].北京:机械工业出版社,2011.

在线报修管理系统设计与实现论文 第2篇

摘要：基于ASP.NET的在线报修管理系统致力于解决当前办公设备报修、维修流程信息化、规范化的问题，该系统采用了B/S模式实现，使用ASP.NET4.0和SQLServer开发。该文从系统的整体设计、功能模块设计、流程设计、架构设计、界面设计、数据库设计、系统实现等方面详细介绍了在线报修管理系统设计和实现过程。该系统的运用在一定程度上提高了办公设备维修的效率。

关键词：管理系统;维修;办公设备;ASP.NET;设计

中图分类号：TP315文献标识码：A文章编号：1009-304403-0073-02

1背景

目前，随着日常办公设备的广泛使用，办公设备的维修成为管理人员普遍关心的问题，办公设备维修管理流程的信息化、规范化成为发展趋势。传统办公设备维修管理主要依靠在纸质媒介上人工记录信息，电话分配任务甚至面对面分配任务的方式，从而造成效率低下、易出现疏漏等情况;因此开发一套在线报修管理系统，以达到办公设备或设施出现故障或隐患时，职工发现问题时能快速、直观、准确的`报送给相关负责部门，维修部门能够及时知悉并进行快速维护，并在维修结束完成后能迅速反馈结果，从报修到维修完毕形成规范的流程，以提高工作效率。

2系统整体设计

在线报修管理系统对办公设备故障后报修的事务流程进行管理，以形成有序的、高效的运作方式。

2.1系统总体结构

在线报修管理系统总体结构图，该系统主要分为报修管理功能模块、系统管理功能模块、查询统计功能模块。

2.2系统各模块功能

报修管理功能模块：用户提出报修申请时，系统生成报修单，要求用户填写相关信息;生成报修流程中各节点任务;维修完成后生成反馈单。系统管理功能模块：主要分为用户管理、基础信息配置和通知公告管理三大块。用户管理，包括添加、删除用户，更改用户信息等;基础信息管理，包括添加、删除现有办公设备，配置系统运行环境等;通知公告管理，包括通知发布、更新、删除等。查询统计功能模块：不同权限用户根据不同查询条件，查询报修记录、设备故障等信息;管理人员根据报修情况统计设备信息，统计单位时间内同一设备的故障率，从而判定设备性能，为办公设备预防性维护提供数据参考。

2.3报修流程

报修管理功能完成报修流程的控制，流程各个节点的任务分配;生成报修单和报修反馈单。报修人员通过浏览器登录自己的账户，登录系统，启动报修任务，填写报修信息，描述故障情况，提交任务;维修任务完成，收到反馈提醒后填写反馈单，评价维修质量，提交后完成整个报修任务流程。在整个任务流程中，普通用户需要完成“启动任务”和“评价反馈”两个节点任务。维修管理人员登录系统后，如收到报修任务，评估任务紧迫性，对多个任务进行排序，向维修人员下发任务;维修任务完成，收到用户的反馈单后，审核完毕存入系统数据库。维修管理人员可以查询数据，进行统计分析，以便排查办公设备可能发生的故障或存在隐患;与厂商沟通要求协助处理或要求厂商派遣维护人员;对于重大故障或隐患提交至相关上一级领导。维修人员登录系统后，可收到报修提醒，根据报修单上的相关信息，开始维修，维修完成后申请反馈单，发送至报修用户处;如有不能解决的问题，提交给维修管理人员，以便联系厂商或上报上一级领导。

2.4系统架构设计

系统软件架构设计中，采用和遵循三层架构设计模式，以降低各功能模块间的耦合程度，依次为：界面层(UserInterfacelayer)UIL、业务逻辑层(BusinessLogicLayer)BLL和数据访问层(Dataaccesslayer)DAL。业务逻辑层定义了实现业务逻辑功能的类：人员管理、部门管理、报修单管理、公告管理、设备管理、维护信息管理、数据列表操作等。数据访问层定义类DataBase.cs，实现连接数据库、对数据库的读、写等功能。2.5界面设计在用户界面部分，根据需求分析的结果，用户界面友好、易操作。在界面设计上，做到简单明了，易于操作，并且要注意到界面的布局，突出显示重要以及出错信息，同时保证各个页面美观大方，风格统一。本系统在用户界面设计中，使用母版页，公共信息显示在母版页上，以做到系统各页面风格统一。

3数据库设计

根据在线报修管理系统的功能数据逻辑结构设计，分为报修表单、维修信息表单、公告信息表单、用户信息表单。

1)报修表单(ORMS_Repair)：报修编号、用户名、用户所在部门、用户电话、设备名称、设备地点、报修时间、故障描述、等级、维修状态、维修人员。

2)维修信息表单(ORMS_Maintain)：维修编号、报修编号、维修人员、处理情况、处理时间、维修状态、维修费用、用户评价、用户意见、评价时间。

3)公告信息表单(ORMS_News)：公告编号、公告名、用户ID、公告内容、更新时间。

4)用户信息表单(ORMS_User)：用户名、用户密码、用户角色、用户姓名、用户部门、用户电话。

4系统实现

在线报修管理系统采用B/S模式设计，由用户端、Web服务器、数据库服务器构成。4.1系统开发环境数据库系统：WindowsServer、安装SQLserver2008开发环境：MicrosoftVisualStudio2010,ASP.NET4.0,C#Web服务器系统：Windows7,安装IE6、安装IIS7、安装FrameWork44.2实际运行效果报修管理：管理人员对报修任务进行审核，划分故障等级，向维修人员下发维修任务，并决定是否向上一级领导汇报。

5结束语

本系统从日常办公的实际需求出发，架构设计遵循三层架构模式，提高系统架构的明确性、层次性和标准性;权限设计时充分考虑实际办公模式，提高系统管理功能的有效性和科学性;界面设计时充分考虑用户的操作习惯，以提高易用程度。在今后管理系统的运行过程中，将根据工作需求逐步完善，以达到提高工作效率的目的。

参考文献:

[1]张正礼,王坚宁.ASP.NET从入门到精通[M].北京:清华大学出版社,.

[2]PaulNielsen.SQLServer2008宝典[M].北京:清华大学出版社,2011.

[3]陆凌牛.HTML5与CSS3权威指南[M].北京:机械工业出版社,2011.

报修系统 第3篇

【关键词】定位;Android客户端;资源管理

1 引言（introduction）

目前高校，学习区，办公区，宿舍区，具有地理区域非常庞大，设备种类非常多，设备数量非常多的特点，也必然带来了，管理难度大，容易出现管理缺失的各种问题。需要用计算机技术和现代的管理思想来进行管理;如果管理不到位，可能出现，设备损坏，无人维护，设备缺失，设备无法统计，使用情况无法掌握，后期是否增加某一设备，无法提供进行有效的数据进行统计，也就无法进行科学的预计。

2 系统功能设计（The system function design）

公共物品损坏报修系统包括：物品报修，修复报单，物品数据分析，供应商数据查询等功能。

（1）物品报修

这项功能设计，主要作用是在发现公共用品出现破损的时候，使用手机客户端，进行拍照，并收集定位信息，进行必要的说明。然后上传报修的数据。这样系统接收到这些关键数据就可以派给维修人员，通过相应数据找到损坏的设备然后进行维修。

（2）修复报单

当维修人员修复了设施后，通过系统提交已经修复的数据，包括拍照等数据。

（3）物品数据分析

目前，有不少物资管理系统，或者资产管理系统，也有一些其他的MIS系统能够对高校各种设备进行数据记录，查询等功能。但是存在一些问题，开始开发的时候，基本都是以物资，资产，这种价值作为核心概念很多是从财务角度去设计系统，仅仅提供，财务清查的时候能够看到，资产的相应的数据。实际上，这样的设计理念和设计思路是滞后了，根据管理学，以及从实际出发。应该为如何使用，如何更好的使用，这些物品出发。以物品为中心，而非以物品价值为中心，并加入了，目前“服务”这样的管理概念。高校后勤的目的是为了保障高校师生的学习和工作，生活各种需求。那么，如何更好的，更加高效，围绕“物品”的功能进行服务好师生，是本系统的着重点。

（4）供应商数据查询

在进行维修前，首先要查询下，这个设施物品是否在质保时间内，如果在保应该要求供应商来进行维护，所以要能够查询供应商信息。如果已经过保就应该可以让维修人员去进行修葺。

3 系统环境搭建（System environment）

根据开发环境选择需要的JDK[1]，并安装JDK，根据系统类型下载adt-bundle，解压即可使用。下载Android SDK，选择2.33以及4.0以上，分别对应最低开发版本，对应目标版本。下载并安装MySQL，下载并配置tomcat。新建一个Android新的工程项目，启动项目在手机上进行测试。

4 开发流程及关键技术（The Process and key technology development）

本系统的特点在于，以“物品”使用为中心，不以“资产”为中心。通过该系统，能够提供一种维护“物品”方式，能够快速响应保修，能够及时掌握“物品”的状态，能够让“物品”得到最好的使用。并可以为后期的选择给出实际的“物品”质量数据，使用数据，需求数据。使用了主流智能手机的APP。

数据存储设计：包括设备表，施工表，设备供应商表;设备维护表，设备维护人员表;设备废弃表;权限表，人员表;

5 结论（Conclusion）

通过本系统提供公共设施损坏报修功能，可以通过GPS定位，现场图片有效的提高维修的人员的工作效率，减少因为对设施损坏原因不了解，导致浪费时间，通过系统提供的时间节点，又可以清晰的发现设施是否在质保时间内。后期对设施损坏原因，进行分析可以对以后的设施管理，采购，维护提供很多帮助。当然本系统在设备的数据管理，设计上，还存在一些问題。后期要加强物品核心信息的手机，进一步迭代开发，做到数据预测的功能。

本文受安徽省青年人才基金重点项目（2013SQRL106ZD）支持。

参考文献：

【1】郭霖.第一行代码Android[M]. 北京：人民邮电出版社，2014.

【2】张明星 孙娇.Android智能穿戴设备开发从入门到精通[M]. 北京：人民邮电中国铁道出版社，2014.

增强型报修系统的分析和设计 第4篇

关键词：数据库,报修系统

“报修系统”作为一个很好的工具,被广泛应用于企事业单位的后勤服务工作中。但是,目前主流的报修系统普遍暴露出通用性有余、与实际业务流差距较大、缺少统计分析功能等不足。在此,我们对报修业务进行了细致的分析,以人性化为出发点,提出了一套增强型报修系统的设计方案。

1 报修业务的分析

现行的多数系统之所以存在诸多不足,“对实际报修业务的分析不够到位”应该是很重要的原因之一。下面我们就来进行一次细致的分析。

1.1 前台业务分析

目前主流的公共报修系统,前台通常只涉及两个角色,即“报修方”和“维修方”,缺乏“管理方”,而且“报修方”没有“登录”的环节,因此功能和业务流都很单一。在我们的设计中,引入了“管理方”,报修方也增加了“登录”环节,使得系统更贴合了实际的业务需求,从而业务流也发生了明显的变化,如图1所示。

在图1中,所有带实线下划线的操作都是由“维修方”发起的,包括:受理、完工、申请延期、申请撤销、评价回复、投诉回复;所有带虚线下划线的操作都是由“管理方”发起的,包括:同意延期、拒绝延期、敦促、投诉回复;所有带实线框的操作都是由系统自动发起的,包括:过期、延期结束;其他操作都是由“报修方”发起的,包括:报修、主动撤销、同意撤销、拒绝撤销、评价、修改评价、投诉、撤销投诉。

按照我们的设计,“报修方”、“维修方”和“管理方”发起的所有操作中,除“敦促”外,都允许修改,但是,为了体现严肃性,修改之前的历史痕迹都应该得到保留。

在图1中可以看到,一次报修业务的最终状态有四种:已完结、已撤销、已过期、被投诉。

通常,报修业务都应该终止在“以完结”状态。最顺利的一次报修业务一般是这样的:首先,报修人员登录后进行“报修”操作此次业务进入初始状态,即“已报修,等待受理”。然后,相关的维修人员登录后会收到这个报修,并予以受理,业务状态转入“处理中”。接下来,在维修完成后,维修人员进行“完工”操作,业务状态转入“已处理,等待评价”(因为日后要通过对维修人员获得的所有“评价”进行统计分析,以评判该维修人的工作实绩,因此“评价”环节是必须的)。最后,报修人员进行评价此次报修业务就进入结束状态,即“已完结”。此后,维修方可以就报修方的评价进行评价回复,但不会改变业务的状态。

报修业务也可以终止在“已撤销”的状态。譬如:报修人员发现自己误报了,则可以“主动撤销”。又譬如:维修人员受理报修后,发现此次报修,因特殊原因不能处理(譬如:因外网光缆受损,导致不能访问外网),则可以申请原报修人员撤销报修,原报修人员批准后,业务终止于“已撤销”状态。

报修业务若在规定时间内(后台可以指定一个天数)未能被受理或是没有处理完毕的,则由系统自动终止,并标示为“已过期”状态。对过期的报修,报修方有权发起投诉,从而使业务终止于“被投诉”状态。若是未及时受理引起的过期,由于尚未确定维修人员,因此该投诉的回复由相关部门的管理人员负责若;是受理后的过期,即维修人员未能在规定时间内处理完毕,则该投诉的回复由受理的维修人员负责。投诉回复不影响业务状态,报修方也可以撤销已经发起的投诉,从而使业务状态从“被投诉”回复到“已过期”状态。

管理人员除了在报修业务的过程中能够进行一些干预操作外,在实际工作中,还有一些特权,主要是对信息的查看、统计和分析。譬如:查看某个员工上半年的报修次数;统计某几个维修人员上一年度的用户评分情况;比较同一时间段内不同楼宇中相同报修小类的发生次数等等。

1.2 后台业务分析

后台的主要业务通常涉及人员管理、公共信息管理、系统维护等等。

人员管理主要包括账号管理、角色(权限)管理

公共信息管理主要包括:报修位置(故障发生的具体位置)管理、报修类别管理、时间段管理(主要针对数据转储和统计)

系统维护主要包括:数据库的备份、还原、系统初始化、历史数据的转存和调用等等。其中转储历史数据的直接目的就是将过期数据从主数据中剔除,以提高系统的运行效力,但考虑到日后可能会需要调阅这些历史数据,因此采取转储的形式。转储后的历史数据需要被“调阅”后才能看到,但“调阅历史数据”的功能不会向普通用户开放,发生的频率很低,所以由此带来的不便也很有限。

1.3 特色业务分析

第一个特色业务是“用户地址簿”。因为大多数用户在报修时的地址信息是相对固定的,所以“用户地址簿”的使用可以帮助用户方便准确地填写地址信息。“用户地址簿”的产生途径有两种,一种是用户自定义,另一种是系统自动生成。系统自动生成又可以按两种方式,一种是取最近使用过的若干个地址,按时间的由近到远排序;另种是取最近一阶段使用频率最高的若干个地址,按使用频率由高到低排序。

第二个特色业务是“时间段定义”。转储历史数据的首要目的是给现行系统减负,其次是为了日后的调阅。“调阅”通常会指明一个“时间段”,如果没有对时间段进行具体的说明和定义,那么,在需要调阅某个历史时间段的数据时,用户在起止日期的确定上往往会很迷茫。譬如:2011年的某天,校领导要求调阅2005-2006学年第一学期的有关数据。这个时间段到底应该从哪天算起又是到哪天结束,恐怕没人能立即提供正确的答案。然而,如果事先现进行了“时间段定义”,就可以方便地从“时间段列表”中选择,而不必担心出错。

2 数据库设计

在前面业务分析的基础上,我们把数据库中的数据表被分为两大类:一类是与报修业务直接相关的表,这里称为“前台类表”;另一类是与报修业务不直接相关的表,这些表主要面向后台系统管理员,这里称为“后台类表”。

2.1 前台类表的设计

前台类表的设计,以前台业务的分析为基础,因此涉及以下一些表:

1)前台用户要求登录后方可进行操作,因此需要有一个用户表(users)。另外需要一个用户所在部门的信息表(departments),已方便用户管理。

2)前台的用户有不同角色,不同角色的用户会被分配不同的操作权限,因此需要有一个用户角色表(user_character)和一个操作类型表(operations)。

3)用户报修需要提供位置信息。这里将位置信息分成由大到小的三级区域、楼宇、房间(房间也兼有“场所的含义”,譬如:3楼走廊)。因此需要有区域信息表(areas)、楼宇信息表(buildings)和房间信息表(rooms)这三个表之间是逐级关联的。

4)用户的报修项目还需要指定类别。这里将类别信息分成由大到小的三级维修部(如:总务处)、工种(如:强电)、小类(如:照明),其中,“工种”也可理解为是“大类”。因此需要有维修部信息表(这个表可以借用前面的部门信息表)、大类信息表(big_class)和小类信息表(small_class),显然,这三个表之间也是逐级关联的。

5)前台用户的各种操作都需要被记录下来,形成一个流水账,因此需要有记录表(records)。这个记录表是信息量最大的表,日积月累后会影响系统运行效率,所以需要被定期转储和清理。为了方便日后的调阅,转储的方式可以是建立一个结构相同的转储表,然后将需要转储的历史数据导入其中。

6)为了实现“用户地址簿”,需要一个用户地址簿表(user_addressbook)

2.2 后台类表的设计

后台类表的设计,以后台业务的分析为基础,因此涉及以下一些表:

1)前台用户的个人信息可以由前台用户自行维护,但是用户的角色、权限则是由后台管理员维护的。不同角色的有着不同的权限,既可以进行不同的操作,需要有一个用户权限表(rights)来罗列每个角色都可以进行哪些操作。

2)用户报修时会涉及调用与“位置信息”相关的三个表,以及与“报修类别”相关的三个表中的内容项,但是,很显然,这六个表的维护是后台管理员的职责和权限。

3)为了增强系统的安全性,需要建立系统运行日志,即记录所有的操作,包括操作发生的时间、发起该操作的用户、操作的类型、操作的概要性说明、IP地址等等。这些都需要一个表来记录,即日志表(logs)。显然,这个“日志表(logs)”和“记录表(records)”一样也需要被定期转储和清理。

4)历史数据的转储和调阅都会涉及“时间段定义”业务,因而需要一个时间段表(interval)来维护时间段列表。

5)整个系统的全局信息,需要一个表来维护,即系统表(system)。其中包含“系统标题”、“版权”、“后台管理员账号”等常规信息,还要包含支持前面提到的“用户地址簿”业务的相关信息,譬如:每个用户的地址条目数上限;默认系统要求报修被受理的时限;默认系统要求报修被的处理完毕的时限等等。

6)根据图1,一条报修记录生成后,会经历不同的状态。这些状态包括:已报修、已撤销、处理中、已完结、已过期、被投诉、申请延期中、暂缓处理、等待评价、敦促中、申请撤销中等等。这些状态的表述可能会需要修改,而且,2~5个字的短语,可能不足以将其含义表达清楚,因此需要配以解释说明,所以就需要一个状态表(state)来维护这些信息。

7)同大多数用户管理机制一样,我们需要向前台用户提供“找回密码”的途径,常见的就是“密码问题”。为了方便管理,我们不推荐由用户自定义密码问题,而是由系统设定,因此需要一个密码问题表(question)。

8)每个维修员都应该有明确的职责分工,包括负责维修的区域、建筑;负责维修的大类、小类,因此需要一个职责分工表(re-sponsibility)。

9)报修方在业务进入“完工”状态后,可以对此次报修处理进行评级,但是评级的习惯有多种,有的用“满意、基本满意、不满意”;有的用“优、良、中、差”。为了满足通用性,需要一个评级表(grade)。可以在这个表中引入“评级”和“评级值”的概念“评级”是直接显示给前台用户的,每一个“评级”对应一个“评级值”,这个值主要是面向日后的统计分析的。

3 界面设计

3.1 前台界面设计

报修人员首先需要拥有账号才可以进行报修的相关操作,这个账号可以通过用户自行注册经审核后获得,也可以直接有后台管理员开设。前台登录后,进入报修用户界面,其中分为两大功能区:“用户信息”和“报修相关”。“用户信息”包括用户的常规信息,譬如:姓名、所属部门、所在办公室、联系电话等等。“报修相关”包括:报修界面、报修历史记录查询界面、用户地址簿维护界面等等。其中“报修界面”是使用最频繁的,因此设计上要让用户的报修过程便捷而准确凡是能够通过选择确定的项目,都应向用户提供选择项来填写,譬如:类别和位置信息就可以目录树的形式提供给前台用户选择。

维修人员和管理人员同样也需要账号。通常有两种设计方案:

1)维修人员和管理人员的账号是专门的用维修人员的账号登录后,仅能看到维修相关的界面,不能进行报修等其他操作;同样,用管理人员的账号登录后,仅能看到管理相关的界面,也不能进行报修等其他操作。

2)维修人员和管理人员的账号也是普通的前台账号,但是由后台管理员分配维修或管理的权限。即维修人员用自己的账号登录后,其中也有普通报修人员的相关界面,即也可以进行报修操作,只是多了若干和维修相关的界面,管理人员亦然。

我们倾向于第二种方案,这种设计更贴近现实现实中报修人员、维修人员和管理人员这三个身份是可以在同一个用户身上重叠的。

3.2 后台界面设计

后台界面主要涉及后类表中全局信息的维护。除了“位置信息”和“报修类别”需要同时涉及多个表,其他信息基本都是相互独立的,因此设计上都比较简单。

4 总结

限于篇幅的原因,我们不能将整个设计的完整方案汇报给读者,但是以上的内容已经涵盖了我们最主要的设计思想,欢迎感兴趣的朋友一同来探讨。

参考文献

[1]鲍威尔.数据库设计入门经典[M].北京:清华大学出版社,2007.

餐厅维修报修流程 第5篇

一、目标：

为了保证食堂正常营运是所有工作的中心，设备、设施完好需要我们共同努力，保养重于维修！维修重于购置！

二、总则：

1、组织机构：中心设置维修审核小组，由中心领导及各餐厅经理组成。由**任组长，**任副组长，各餐厅经理任成员。

2、维修分类：日常维修和紧急维修。

3、维修报修方式：餐厅必须按维修流程的规定填写相关维修表格。

4、注意事项：维修人员进入生产区必须戴帽和佩带名牌并征得管理组同意，维修过程中服从管理组的安排。

5、维修验收：已完成的维修工作必须由餐厅经理或值班经理在《维修申请单》上签字确认

三、维修报修方式：

1、报修时：餐厅设备、设施发生故障，首先应按照设备说明书进行检查，并做简要的处理，若确认故障无法解决时再报修。

2、报修人员：餐厅经理、值班经理；

3、向谁报修：中心办公室；

4、报修途径：以填制维修申请表方式报维修负责人。紧急维修电话报修并及时补办报修手续。

5、报修时间：日常维修每周一次；紧急维修随时电话报修，并及时补报维修申请表；

四、设备、设施分类：

1.设备：厨房设备，不锈钢制品及小配件，冷冻、和冰箱等； 2.设施：装修及上下给排水、电器、空调、消防、环保系统，桌椅和招牌等；

五、维修类型：

1、日常维修：除紧急维修以外的一切维修内容；

2、紧急维修：设备、设施故障引起断产品、影响产品品质、出现安全隐患及重大成本损失等需要立即解决的问题。

六：维修流程：

（见下页）

1、日常维修流程：

2、紧急维修流程：

七、验收与费用审核

1、维修结束，餐厅经理须在维修单上签名，确认工作完成，若有意见也同时写在备注栏内。

2、中心维修师傅在日常工作中，抽检厂商维修单及维修质量；

3、各餐厅经理每月统计维修单、确认费用、分析状况，并反馈给维修师傅或维修厂家。

4、维修师傅或维修厂家分类请款，走学校相关付款流程。

八、餐厅确认以下内容：

1、维修工单上所填写的维修时间、更换的零配件是否与实际的维修时间、零配件相符，如更换零件，须要求维修人员把更换下的零配件（保固期外的）留在餐厅；

2、检查维修后的设备是否能正常运行；

3、依照设备病历卡，确认此维修设备是否在整机保固期之内，如在整机保固期内应属免费维修（人为损坏除外）；

4、依据设备病历卡，确认此设备所更换的零件是否在相应的保固期内，如在保固期内更换过，此零件应属免费更换（人为损坏除外）；

生活家地板用户报修被骗原因可疑 第6篇

生活家地板维修人员上门

只推销地板精油未服务

现在，生活家地板已成为人们所熟知的品牌，出于对这个品牌的信赖，北京杨女士家装修新房就选用了居然之家丽泽桥店的生活家地板。

地板于2012年4月安装完成，但使用不到一年的时间，地板就出现了缝隙，于是杨女士拨打了生活家地板订货合同上的售后电话，找到生活家地板售后维修部门，售后人员接线后说“稍后安排人员上门服务。”

时间不长，便有人联系杨女士进行上门服务，自称是生活家地板的售后维修人员。

来人对杨女士的姓名、住址及生活家地板米数面积等信息了解的非常清楚，流程也很正常。在维修过程中，上门服务人员边查看地板情况边向杨女士介绍，“生活家地板正为用户提供一项维修保养的服务，954元保养一年半的时间”。

杨女士根本没多想，就相信了他所说的此项服务，杨女士说“我是拨打的生活家地板订货合同上的售后电话，所以对上门服务人员根本没有多想或是起什么怀疑。”结果，该人员向杨女士推销起了地板精油，劝说杨女士一次性购买，并告知以后每月上门对地板进行一次保养，在杨女士家现场收取了954元后便离开了。

但是两个月过去了，并没有见到生活家地板的售后人员上门对地板进行保养，于是杨女士再次拨打居然之家丽泽桥店的生活家地板订货合同上的售后电话，接电话的售后人员称“生活家地板并没有记录杨女士的报修信息。”这下让杨女士感觉有点不对劲，她分析整个事情的来龙去脉，怀疑生活家地板售后客服人员与人勾结，泄露用户信息，骗取用户钱财。

生活家地板公司上门退费

无调查结果

接到消费者反映后，中国质量万里行工作人员致电生活家地板公司，生活家地板公司人员称“先去内部核实情况。”

报修系统 第7篇

1 系统功能

1.1 临床科室设备报修、送修。

系统接收后按分工提醒本科工程师接收维修, 维修完成后反馈临床科室维修结果。避免原模式下临床科打电话或送修找不到人, 医工科修好设备后多次电话通知无人领的问题的发生。

1.2 送修设备故障原因记录, 送修设备附件明细记录。

详细记录故障原因帮助工程师快速解决问题或查找设备厂家、联系人及时获得技术支持, 详细记录送修设备附件避免附件丢失后的责任确定问题。

1.3 本科维修室及工程师工作量统计。

分别对各维修室及个人进行月季年的工作量统计, 根据统计结果合理分配科室人员及时调整工程师的责任范围。

1.4 设备维修情况查询。

对某一类设备或某一厂家设备修理情况进行查询, 帮助工程师找出维修规律快速解决问题及对相关厂家提出反馈意见。

2 结构流程

2.1 该系统数据结构包括如下字典库

(1) 用户字典, 该字典记录系统使用者信息; (2) 科室字典, 该字典记录系统涉及科室信息; (3) 设备信息字典, 该字典记录设备名称、型号、厂家、联系人、保期等信息; (4) 维修信息字典, 该字典记录设备故障描述、原因及解决方法等信息。

2.2 系统流程图如图1所示, 该系统尽量与当前工作流程靠拢减少因流程改变造成的不便。

(1) 一线科室通过网络上报设备名称、型号、故障原因等信息, 系统根据分工实时及分时多次提醒相关维修人员; (2) 工程师收到报修后可查寻该设备的基本信息 (厂家、电话、是否在保等信息) 及以往维修记录, 分析判断后反馈科室是否需要送修; (3) 接触设备后标注设备维修状态 (完成、送修、等待配件) 填写维修记录; (4) 修理完成后实时及分时多次提醒一线科室领取送修设备, 取走后注明本次维修工作结束; (5) 对设备维修情况及工程师工作量进行统计。

3 系统模式及开发环境

该系统依托院内现有局域网及设备, 使用Asp+sqlserver开发, 采用B/S模式, 无需客户端安装, 减少了系统安装更新时的大量客户端工作, 各终瑞只需通过院内网页就可轻松完成报修。

4 系统应用

报修系统 第8篇

随着高校规模的不断扩大,后勤报修维修的工作量也相应的不断增加,基于高校局域网的建设成果,可以使用B/S模式的网上报修系统来提高工作效率及加强报修维修工作管理。

1 技术简介

1.1 MVC模式及Struts框架

MVC为一种软件架构模式,它把软件系统分为三个基本部分:模型、视图和控制器。模型就是业务流程/状态的处理以及业务规则的制定。视图代表用户交互界面,对于Web应用来说,视图就是指Web页面。控制器可以理解为从用户接收请求,将模型与视图匹配在一起,共同完成用户的请求。

Struts是一组相互协作的类、servlet和JSP标记,它们组成一个可重用的MVC设计。Struts是一个框架,而不是一个库,但Struts也包含了丰富的标记库和独立于该框架工作的实用程序类[1]。

1.2 Spring和Hibernate

Spring是一个开源框架,是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许您选择使用哪一个组件,同时为J2EE应用程序开发提供集成的框架。在本系统中将使用IOC实现对象的注入,使用AOP实现数据库的事务管理[3]。

Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了轻量级的对象封装,使得Java程序员可以使用面向对象编程思维来操纵数据库。本系统中将采用Hibernate实现数据的访问操作[2]。

2 系统分析与设计

2.1 系统总体功能

报修系统采用模块化结构,共包含以下几大功能:用户管理、维修项目管理、报修管理、报表处理及评价系统。

其中用户管理包括一般报修用户(单位)管理以及各类管理人员用户管理;维修项目管理包括水、电和木三大类及各小类项目的添加、删除及修改;报修管理是指报修用户通过Web提交报修单、管理人员派工、维修人员提交维修结论及报修人意见等报修及维修过程;报表处理指根据不同的要求及应用的不同地点输出相应的报表;评价系统指根据给定的一段时间对每一维修项目、每一维修人员或整个维修进行评价,给出相应的评价指标。

2.2 数据库设计

根据系统功能需求,系统需要的数据信息有:用户信息、管理员信息、维修人员信息、维修项目信息及维修清单信息。为了高效的管理与使用这些数据信息,系统采用关系数据库进行数据管理。系统数据库模型图如图一所示。

2.3 系统业务总体流程分析与设计

报修系统实现报修人网上报修、工作人员网上任务分配、工单输出、维修人员维修结果网上提交以及报修人维修后意见反馈等业务操作。系统业务总体流程见图二所示。

3 系统实现

系统采用My Eclipse可视化设计工具来实现,My E-clipse是对Eclipse IDE的扩展,利用它可以在数据库和J2EE的开发、发布以及应用程序服务器的整合方面极大的提高工作效率。它完整支持HTML、Struts、JSF、CSS、Javascript、SQL、Hibernate。

3.1 数据库存取

报修系统所使用的数据信息采用SQL Server2000数据库进行管理,系统中的所有功能模块的实现都需要对数据库进行存取。系统采用Hibernate作为数据库存取工具,结合Spring框架数据源连接及数据表映射代码如下所示[2,3]:

数据库数据的存取均采用Hibernate的HQL及Hibernate Template对象的save、update及get等方法来实现。如下代码为存储一条用户数据记录的方法:this.get Hibernate Template().save(user)。

3.2 用户管理及维修项目管理实现

用户管理主要涉及的操作是向数据库添加新的用户、更新用户数据及删除用户。维修项目管理主要涉及的操作为向数据库添加新的维修项目、更新数据库中已有项目的内容及删除数据库中的维修项目。

从以上描述可知,用户管理和维修项目管理主要是对数据的存取操作,业务逻辑相对简单,具体实现采用数据库存取中讨论的方法进行。

3.3 报修管理

报修业务作为本系统的重要业务模块包括用户网上报修、工作人员任务分派及结果提交等。业务流程见本文2.3小节。

3.4 报表处理

报表作为系统输出的一个重要形式,将输出报修及维修情况的工作清单。系统采用Jasper Reports加i Report报表的设计与输出。Jasper Reports是一个基于Java的开源报表工具,它支持PDF、HTML和XLS等文件输出格式。JasperReports使用一个预定义好的XML模板(jrxml文件)来组织数据,jrxml文件需编译成Jasper Reports本地二进制模板(Jasper文件),Jasper Reports通过为Jasper文件提供所需的数据,产生最终的报表。i Report主要作用是以可视化的方式设计生成Jasper Report所使用的报表格式文件,以弥补Jasper Report本身并未提供很好的可视化报表设计工具。

报表处理时先使用i Report来生成所需的报表格式文件,再使用Jasper Report方法根据相应的报表格式文件输出报表。主要代码如下:

3.5 评价系统

评价系统实现对整个维修工作和维修人员一段时间工作的总结,评价系统评价指标主要是根据报修人修后的反馈信息。报修人修后反馈选项有:非常满意、满意、基本满意及不满意。评价系统算出每一选项占反馈总数的百分比并以报表形式输出。

4 结束语

后勤报修系统作为高校后勤管理信息化的一部分,它能够在一定程度上提高后勤报修维修业务的工作及管理效率。本文所设计与实现的高校后勤报修系统也可使用在其它有报修及维修的企事业单位中。

参考文献

[1]李刚.Struts权威指南[M].北京:电子工业出版社,2007.

[2]夏,李志蜀.基于Hibernate框架的数据持久化层的研究及其应用[J].计算机应用,2008,(9):2446-2448.

[3]哈罗普(美),马可赛克(美).Spring专业开发指南[M].北京:电子工业出版社,2006.

苏州大学报修管理系统的设计与实现 第9篇

由于苏州大学各校区分布地域较大, 维修点分散, 日常维修种类繁多复杂, 报修接线员很难在接听电话时详细的记录故障情况, 也无法向报修人提供维修进展, 报修人也经常遇到电话占线等待时间较长等问题。因此后勤服务部门急需建立一套报修管理系统, 来针对设施故障、设备损坏和家属区公共部位维修项目的报修进行动态管理。

二、相关研究基础

本文系统基于微软Framework 2.0的B/S架构。.NET是一个在J2EE之后出现的平台, 其应用不再以本地机器代码运行, 而是编译成中间代码, 由称为CLR的虚拟机来运行。.NET框架简化了在高度分布式Internet环境中应用程序开发, 而且还支持第三方运行库宿主的开发, 它有两个主要组件:公共语言运行库和.NET框架类库。

三、系统的设计与实现

1、系统体系架构设计

系统整体采用基于Web的N层分布式B/S架构, 其中包括BLL业务逻辑层, DAL数据操作层、以及Model业务实体。系统模块结构如图1所示。

2、系统数据库设计

数据库采用SQL Server 2005, 访问采用ADO.NET方式, 涉及的主要数据表如下:

系统表与表之间的联系严格通过主外键关联, 关系如图2所示

3、系统的实现

(1) 报修管理

报修人可进行电话报修或网上在线报修 (如图3所示) , 由后勤工作人员按校区、类别进行筛选确认, 在线生成派工单, 连同手机短信发送至物业维修人员。

维修人员根据短信提醒进入系统打印派工单, 赴现场维修, 维修完成后, 根据用户签字确认的派工单填写完成时间、耗材费用等, 确认维修情况。报修人和后勤管理人员均可通过系统对维修人员的服务进行评价。关键代码举例如下:

(2) 资金结算与统计报表

系统可以根据资金结算周期, 按维修单位汇总结算单, 管理部门和物业维修单位通过系统结算单结算。管理层也可以根据统计图表, 对维修情况、满意度、返修率等数据一目了然 (如图5所示) 。关键代码举例如下:

(3) 应用实例

四、结论

本系统通过信息化手段实现了苏州大学维修管理工作的全过程管理, 包括记录报修信息, 监控维修过程, 反馈维修结果, 结算维修费用。目前系统已成为苏州大学数字校园的重要组成部分, 真正提高了零维修的响应速度和工作效率, 规范了维修管理过程, 健全了学校后勤的管理体系。

参考文献

[1]周翔:《基于Web的高校后勤报修系统设计与实现》, 《科技广场》, 2009 (11) :131-133。

报修系统 第10篇

关键词：ASP.NET,工厂模式,报修系统

近些年来,高校校园网在普及的基础上,取得长足的发展,在校园内覆盖的深度和广度上都有极大提高,但是,很多高校的后勤维修服务却还停留在手工报修的管理模式上。这给广大师生带来了极大的不便,设施故障报修的便捷程度和后勤服务部门的响应效率都较低。为实现高效、方便、快捷的高校服务理念和目标,提高广大师生对后勤服务工作的满意度,开发适合高校校情的“网上报修系统”已是大势所趋。

1 技术概要

1.1 ASP.NET技术

ASP.Net是建立在微软新一代.Net平台架构上,利用普通语言运行时(Common Language Runtime)在服务器后端为用户提供建立强大的企业级Web应用服务的编程框架。它是统一的Web开发平台,用来提供开发人员生成企业级Web应用程序所需的服务。它提供一种新的编程模型和结构,用于生成更安全、可伸缩和稳定的应用程序。

1.2 Factory Method工厂模式

工厂方法(Factory Method)模式是类的创建模式,其用意是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。在工厂方法模式中,核心的工厂类不再负责所有产品的创建,而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口,而不接触哪一个产品类被实例化这种细节,这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

1.3 SQL Server数据库

SQL Server 2005作为关系型数据库,可以和组织管理任何数据;可以将结构化、半结构化和非结构化文档的数据直接存储到数据库中;可以对数据进行查询、搜索、同步、报告和分析等操作。系统将平台基本信息,报修过程生成模拟数据更新到数据库中,系统可以直观、简洁地完成整个报修及回访等操作。

2 系统分析及设计

2.1 功能模块

报修系统采用模块化结构设计,通过详细的需求分析,在原有手工报修的基础上,对报修的各个环节进行规范化分析及处理。报修系统主要包括用户报修、报修管理、报表统计、用户管理、系统设置等功能模块。

用户报修主要实现学生或教师在网上申报维修以及查看、评价等操作。报修管理主要是管理人员进行报修的审核、派遣维修等操作。报表统计实现管理员按楼宇、按服务以及派单统计等功能。用户管理主要实现系统用户、学生用户、教师用户的管理以及角色管理等功能。系统设置主要实现系统代码设置、系统参数设置、系统日志管理等功能。

2.2 运行流程

报修系统实现游客的维修信息查看、学生或教师用户的网上报修、评价,以及后台管理员的报修信息的处理、维修人员的派遣、报修的回访、用户管理和系统设置等业务操作。系统运行流程如图1所示。

2.3 数据库

合理的数据库设计将为系统的设计和实现提供稳定性和可扩展性的保障。根据系统功能的需求,系统需要的数据信息主要有:报修信息、申报主题、校区信息、楼宇信息、服务项目信息和用户信息等。系统采用关系数据库进行管理,其数据库模型如图2所示。

3 系统实现

报修系统采用Visual Studio 2015作为开发工具,使用C#作为开发语言,以SQL Server 2008作为开发数据库,基于.NET Framework 4.0的B/S构架。以下就系统的用户报修模块和报修管理模块功能的实现进行概要介绍。

3.1 用户报修模块

该模块主要实现用户在系统上申请报修信息的提交到数据库的功能。报修内容中的申请单号、申请人均由系统自动产生,申报主题、校区、楼号、服务项目等由用户自己选择,可在系统代码设置中维护。其他内容由用户根据情况填写。实现提交报修申请表单的主要C#代码如下:

3.2 报修管理模块

该模块主要实现管理员的报修审核、申请驳回、报修受理、报修派单、报修处理、报修回访和评价管理等功能。如图3所示。

4 结语

针对高校后勤服务部门对日常报修处理的实际需求,设计开发了一个基于Web的报修管理系统。系统采用ASP.NET来开发实现用户报修、报修管理、报表统计、用户管理、系统设置等功能模块。

参考文献

[1]李波,刘维忠.基于ASP.NET架构新疆农村社区公共服务管理信息系统设计——以新疆昌吉市榆树沟镇为例[J].农村经济与科技,2012(3):104-106.

[2]刘健,姜华,张安妮.Asp.net和B/S架构的档案信息管理系统应用[J].计算机与网络,2009(24):42-44.

[3]赵雪莉.基于.net的计算机设备网上报修系统的设计与实现[D].成都:电子科技大学,2013.

报修系统 第11篇

为此,该文采用流行的SSH框架(Struts、Spring、Hibernate)实现一个基于网络的在线报修管理系统,实现信息高效管理。

1 Struts、Hibernate、Spring简介

Struts是Apache软件基金会赞助的一个开源项目。它通过采用Java Servlet、JSP技术,实现了基于Java EE Web应用的MVC设计模式的应用框架。而Struts新推出的2.0版本是基于另外一个著名的框架Web Work,它吸收了Struts1和Web Work两者的优势。

Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。

Hibernate的核心接口一共有5个,分别为:Session、Session Factory、Transaction、Query和Configuration。这5个核心接口在任何开发中都会用到。通过这些接口,不仅可以对持久化对象进行存取,还能够进行事务控制。

Spring是一个开源框架,是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许您选择使用哪一个组件,同时为J2EE应用程序开发提供集成的框架。组成Spring框架的每个模块(或组件)都可以单独存在,或者与其他一个或多个模块联合实现。

2 系统基本需求

实验实训中心负责人通过管理员帐号登录,为本中心维修人员提供报修处理登录帐号,为每个院系报修人员分配报修帐号。报修人员使用帐号登录系统,将所在部门需要维修的信息录入上报到实验实训中心,实验实训中心负责人根据报修情况指定维修人员按照报修情况进行维修处理,维修结束,维修人员填写维修记录,以备查询。

3 数据库设计

使用开源数据库My SQL数据库存储数据,主要数据表定义如下:

用户类型表:类型编号,类型名称;

报修部门:部门编号,部门名称,备注;

用户表:用户编号,登录帐号,密码,所属类型编号,所属部门编号;

设别所在场地:场地编号,场地名称,场地描述,所属部门编号;

报修处理记录:报修编号,报修部门,报修用户,报修场地,报修内容,报修时间,维修状态,维修人员,处理结果,维修时间。

4 系统模块设计

教学设备报修系统主要分为管理员模块、报修员模块、维修员模块,模块图如图1所示。

系统主要模块功能如下:

1)管理员模块:实现系统基本信息设置、部门信息维护、设备场地信息维护、报修员信息维护、维修员信息维护及报修单信息管理及报修任务分配。

2)报修员模块:实现报修信息发布处理及报修结果查询等。

3)维修员模块:实现维修任务查询、处理及维修结果记录处理。

5 系统实现的关键技术

1)Struts2基本配置:

Struts2框架开发和运行过程中需要使用一些配置文件,例如经常用到的struts.xml配置文件,这个配置文件的主要功能是建立页面与实现类之间的关系,实现业务控制流程。例如:

2)拦截器:

在Web程序中,要求访问许多资源或页面时在实际业务处理前后做一些公共的处理,如检验访问用户权限、记录用户操作日志等。为了将这些公共处理从实际业务处理代码中剥离出来,减少开发工作量和便于程序维护,Struts 2框架提供一种拦截器机制可以很方便地实现这一功能。例如下面这个权限拦截器,就是校验用户是否登录,没有登录则不能继续访问当前页而是跳到登录页面去。实现一个拦截器只需要继承Struts2提供的Abstract Interceptor并实现intercept方法即可。验证用户登录状态的代码如下:

3)Struts、String、Hibernate整合处理

利用Spring的IOC功能,实现Struts的Action对象的管理,在Struts的action配置中不需要直接产生Action对象,而放在Spring配置文件中配置,由Spring统一管理;将Hibernate的数据库访问对象的也交给Spring管理,并在Hibernate的数据访问对象中继承Spring所提供的基本类Hibernate Dao Support,利用Spring所提供的基本方法,实现数据库的访问,简化访问过程。在Action中所需要的Hibernate数据库访问对象也直接由Spring的IOC方式提供,由Spring维护。

6 结束语

教学设备报修系统的建立使得实验实训中的的管理人员、维修人员和部门报修人员能够在网络上完成设备报修,任务分配,维修结果登录等各项维修工作,使得这些工作变得快速和简化,提高了工作效率也方便了部门工作。Struts框架作为一种MVC框架,与Hibernate、Spring整合,完成系统开发。使用Struts的MVC框架,利用Hibernate实现ORM映射,采用Spring的IOC实现模块化管理维护。十分适合大型Web应用的开发和维护,并且易于扩展。大大降低了系统开发和维护的成本,提高了系统模块的可复用性,在教学设备报修系统软件的开发中起到了重要的作用。

参考文献

[1]寇毅,吴力文.基于MVC设计模式的Struts框架的应用方法[J].计算机应用,2003(12):13-15.

[2]谷毅,王爽心,刘鑫,利用Struts开发Web应用程序在工业自动化中的实现[J].微计算机信息,2004(10):24-26.

[3]Roughley I.精通Struts 2:Web 2.0开发实战[M].李进华,译.北京:人民邮电出版社,2009.

[4]Brown D.Struts 2实战[M].马召,译.北京:人民邮电出版社,2010.

[5]尹汪宏.基于Struts 2的文件上传功能实现[J].安徽电子信息职业技术学院学报,2009(6):18-24.