基于Jsp和MySql的汽车维修管理系统
摘 要
随着人们生活水平的不断提高,私家车的数量正在逐年攀升。这带动了汽车维修行业的发展。越来越多的汽车维修厂如雨后春笋般涌现。同时,维修厂的业务操作产生了庞大的数据,这给汽车维修厂工作人员的数据管理提出了新的要求,他们需要去考虑如何高效无差错的处理数据,保证维修厂的高效运营,来提升他们的经济效益。所以,汽车维修厂需要一个能够帮助他们处理维修厂的业务数据、客户数据和员工数据信息管理系统。
本课题主要解决的问题有:
-
车辆接待 :系统需要实现添加来访者以及其车辆的信息,进行开单操作,并为维修单分配维修人员和质检人员
-
维修项目登记 :维修人员维修检查,登记维修用料和维修工时的情况
-
维修领料 :维修人员人员领取维修材料
-
质检完工 :质检员进行质检,录入质检结果到系统中
-
消费结算 :查询维修单,进行付款操作
-
配件管理 :工作人员管理配件的信息
本文首先介绍了汽车维修管理的课题研究的背景,当前发展的现状和面临的问题。接着介绍了本次课题所用到的技术。然后是需求分析,使用面向对象的思想方法结合UML分析建模工具来完成。然后介绍了系统的设计部分,详细说明了系统的业务逻辑和具体的实现方法。描述了系统的数据库设计。还介绍了系统的具体实现部分。本系统使用SMM框架来实现,页面使用EasyUI来完成。最后介绍了系统的测试部分,选取了一部分功能进行测试。
关键词 :汽车维修管理;Java;SSM;EasyUI
Abstract
With the continuous improvement of people's living standards, the number of private cars is increasing year by year. This leads to the development of the automotive maintenance industry. More and more car repair factories have sprung up. At the same time, the maintenance operations of the plant have generated a large amount of data, which put new requirements for the data management of the staff of the vehicle repair factory. They need to think about how to handle data efficiently and without error to ensure efficient operation of the maintenance and plant their economic benefits. Therefore, the car repair factories need a business data management system that can help them deal with the maintenance plant's business data, customer data and employee data.
The main problems solved in this paper are:
-
vehicle reception : the system needs to add visitors and their vehicle information, billing operations, and assign maintenance staff and quality inspection staff to the maintenance order
-
maintenance project registration : maintenance staff can carry out maintenance inspection, register maintenance materials and maintenance hours
-
maintenance picking : maintenance staff receive maintenance materials
-
quality inspection completed : quality inspectors quality inspection and input quality inspection results to system
-
consumer billing : check the maintenance order and make payment operation
-
accessories management : staff management accessories information
This paper firstly introduces the background, current situation and problems of vehicle maintenance management. Then the paper introduces the technology used in this project. Then the requirement analysis is carried out by using the object-oriented method and UML analysis modeling tools. Then the design of the system is introduced, and the business logic of the system is described in detail. It describes the database design of the system. It also describes the specific implementation of the system. The system uses the SMM framework to achieve and the pages use EasyUI to complete. At last, it introduces the test part of the system and selects some functions to test it.
Keywords : Vehicle Maintenance Management; Java; SSM; EasyUI
1 绪论
1.1 课题研究的背景
随着我国汽车制造业的不断发展,汽车数量在不断的增加。在这种背景下,出现了越来越多的汽车修理厂,汽车维修行业展现了蓬勃发展的趋势。有相关的调查资料显示,在2013年,我国的汽车售后的资金规模量已经高达4500亿元,未来还在呈不断上升的趋势。我们可以发现,汽车的售后服务在整个产业链中占据着越来越重要的地位。很多的汽车厂家开始把自己品牌售后服务维修作为重要的战略要点之一。
由于这些新增长点的出现,汽车修理厂的业务数据量也变得多了起来,这对汽车维修行业的管理者们对业务数据的管理发起了新的挑战。维修厂的工作人员除了要面对自己眼前的维修任务,还要处理来自修理厂其他的基础业务信息。这些数据即使被记录下来也无法被加以有效的管理和利用。在传统的汽车修理厂的管理模式中,维修厂的工作人员只能通过手工表格的方式来记录这些信息。但是这些数据量过于庞大和复杂,查找起来不太容易更不方便去统计,这给工作人员的数据处理带来了一定的麻烦,在一定程度上降低了修理厂的运营效率。这些问题也逐渐成为了汽车维修管理中的痛点。所以在这种背景下,需要有一个管理系统,来将维修厂日常运营产生的数据进行管理、分析和统计,让维修厂的管理人员从繁琐的数据处理中解脱出来。从现有普遍的汽车修理厂的工作模式出发,经过调查和分析,整个业务流程大体上分为五个主要的步骤,分别为维修接待、维修登记、维修领料、维修质检和支付结算。汽车维修厂信息管理系统需要能够实现客户资料的管理、维修订单的维修领料情况管理和维修项目登记管理等功能。让这些数据便于汽修厂内部的对账、修理厂员工的考绩效核以及消费者最终的消费结算。基于以上的讨论,一个能够支撑汽车修理厂日常运营的信息管理系统需要被开发出来,来帮助修理厂提高工作的效率,解决数据存储和统计的相关问题,为汽车修理厂带去更多的经济效益提升在同行业中的竞争力。
1.2 课题研究的现状
在现实场景中,按照传统的做法,汽车修理厂的工作人员每天需要记录大量的来访的用户的信息,对于用户的每一个订单需要进行维修进度的追踪,以及支付的追踪。还要处理一大堆员工的业绩和汽车维修零件相关采购等基础信息,在这些大量复杂而且没有经过处理的数据面前,工作人员也会束手无策。现在市面上的一些类似的管理系统有很少的一部分能够真正从汽车维修厂的实际业务出发,解决汽车修理厂的维修订单追踪和庞大的数据统计等问题。
1.3 课题研究的意义
汽车行业作为当前热门的的行业之一,在我们的生活中扮演着重要的角色,对于维修厂而言,如何高效的提高汽修厂的工作效率是我们需要考虑的问题。按照传统的方式,汽车维修厂的数据维护成本太大,效率低下,而且容易出现错误,这严重阻碍了汽车修理厂的正常的运营。所以一个能够帮助汽车修理厂从接单到维修到维修领料再到完工以及最后的支付结算需要被设计开发出来,而本课题就是着重解决这几个业务流程,帮助用户去除维修管理中的痛点,真正做到高效的自动化管理,提高维修厂工作人员的效率。为汽车修理厂解决数据量大,数据复杂不知如何管理的问题。
1.4 文档的内容
全文共有六大模块。
-
第1章绪论 :该部分主要介绍了本课题研究的背景、现状和意义。是全文的开篇,着重阐述了本文需要解决哪些现实生活问题
-
第2章开发工具和相关技术 :该模块主要说明了完成本系统主要采用了哪些技术,对于这些技术做一个简要的描述
-
第3章需求分析 :该部分作为系统的前期分析设计模块,主要内容为需求的陈述以及业务建模
-
第4章系统设计 :该部分主要分为四个小部分,分别为:体系结构设计、系统功能设计、数据库设计和安全性设计部分
-
第5章系统实现 :该部分主要展现了系统实现的具体情况和相关的功能说明
-
第6章系统测试 :该部分为系统测试模块为针对系统的主要功能做出的一些测试的结果
2 开发工具及相关技术
2.1 Eclipse工具
Eclipse是备受广大程序员爱好的一款软件开发工具。它具备源代码开放、免费的的优势,拥有优秀厂商的技术支持,同时eclipse具备丰富的可拓展的插件,Eclipse不仅仅是java的集成开发环境,还支持其他的编程语言,比如C/C++、Python和PHP等等。
2.2 WebStorm工具
WebStorm是备受很多国内JS开发者热宠的一款前端开发利器。很多人对WebStorm在前端开发的表现有很高的评价,它被称为“最优秀的javascriptIDE”、“前端开发的神器”和“最高效的HTML5集成开发环境”。
2.3 Navicat for MySQL工具
Navicat是香港卓软数码科技有限公司旗下生产的一种图形化的数据库管理软件,它支持当前多种主流的数据库,比如Oracle、MySQL、Microsoft SQL Server及MariaDB等。该软件适用于DBA和程序员,它能够支持多重连接本地和或者远程的数据库,操作十分方便。
2.4 Java技术
Java是一门面向对象的跨平台的高级程序设计语言,开始由sun公司推出。经过数十年的不断发展,java的发展已经日臻成熟,越来越多的编程人员开始学习并使用java来编写很多有趣的程序。Java语言还具备自己其他的一些新的特性,比如自动垃圾回收机制、泛型等等。
2.5 Spring技术
Java技术的发展日新月异,各种框架层出不穷。技术的发展来源于人们对于简单高效的追求,而Spring正是为了用这样的方式解决现实生活问题而产生的。Spring由于其具备简单、轻量级、依赖注入和面向切面编程的特性而备受java开发人员的追捧。本系统决定使用spring来简化系统的开发。
3 需求分析
3.1 需求陈述
汽车维修管理系统是针对维修厂日常运营管理而设计的一款软件。该软件需要能够帮助修理厂从维修接待、维修检测施工、维修领料、质检核算等环节实现自动化,帮助维修厂的工作人员提高工作效率,减少出错的概率,使汽车维修厂能够平稳高效运营,提升修理厂的经济效益。同时该系统需要能够帮助维修厂统计的营业效益,用图表统计的方式让数据更加生动的展现出来。该系统核心模块有客户的接待模块、维修登记模块、维修领料模块、维修质检模块和支付结算模块。这些模块共通组成了汽车维修厂所真正需要的一个B/S架构的在线管理系统。
3.2 业务建模
3.2.1 业务流程
-
车辆接待 :汽车修理厂的工作人员接待新的客户,当有车辆到汽修厂时,需要进行用户信息的登记。首先工作人员先查看本维修厂是否有当前的客户,如果有当前的客户就继续登记车辆的其他信息,如果没有登录则需要重新记录用户的信息形成用户的档案。在确定了用户信息之后,需要登记车主描述的车辆状况的信息,登记汽车上的贵重物品,与用户核实是否需要清洁车辆、查看旧件、检查备胎等业务,确定用户最终提车的时间。然后工作人员会安排当前汽车修理厂的相关的维修人员和质检人员。用户拿到发票等待汽车的维修完成。没有其他的异常情况进入下一个业务环节
-
维修项目登记 :维修人员了解当前自己维修的任务有哪些,查看维修订单,了解客户描述的车辆的状况,然后进行汽车的检测,记录当前的车辆需要维修的项目以备最终的支付结算。同时维修人员需要对自己维修工作中对于当前车辆所要用到的零件进行登记,并由维修人员拿到的零件领取单去零件仓库领取相关的材料,来完成最终的维修任务。维修人员在维修完毕并确定无误后可交接给质检人员进行相关维修项目的质检,观察维修项目是否合格。维修人员如果还未曾领取材料则到第三个步骤进行维修材料的领取。维修完毕后则进入第五个步骤质检完工的环节
-
维修领料 :在第二步骤的操作中,维修人员在登记了自己所要领取的材料之后,需要进行材料的领取。领取材料后需要对领取人、领取材料的时间、领取材料的名称以及领取材料的数量进行登记,进行后续的操作。如果发现零件库存不够则通知相关的采购人员进行原材料的采购工作,如果材料数量足够则用户领取材料继续第二个步骤维修项目登记的环节
-
采购配件 :当维修人员进行领取材料的时候,发现材料库存量不足则需要进行材料的采购工作,采购员拿到相关的待采购的订单后,进行采购订单的业务环节,期间采购需要记录下采购的商家、零件的名称、采购的价格、采购的日期以及采购的单价等信息,方便财务管理和后续的业务操作。采购完成后,待维修人员进行维修材料的领取。没有异常情况,进行后续的业务操作
-
质检完工 :维修人员在交接给维修质检人员时,质检人员需要查看质检人员登记的维修项目有哪些,根据维修项目进行质检,对于质检不通过的需要告知维修人员哪里还存在问题,退回给维修人员继续维修直至维修质检完全通过。当该订单所有的内容经过维修并且已经维修通过的时候,该笔订单就进入到的维修支付的阶段,如果没有质检通过,则退回到第二个步骤维修登记部分
-
消费结算 :作为最后一个部分支付部分,该部分为用户到维修厂进行提车,用户对自己的汽车进行订单的支付功能,工作人员会列出用户当前所有的登记过的维修项目的费用和已经使用过相关零件材料的费用进行合计。顾客针对自己的订单完成支付。整个维修过程,从接单、维修、支付提车就结束了
3.2.2 业务用例建模
根据需求的分析,利用建模工具分析得出了以下的业务用例,用例图的具体设计内容如图3-1。
3.2.3 业务活动图
根据业务分析的结果,得到汽车维修管理系统的业务活动图如图3-2。
3.2.4 业务静态建模
根据业务逻辑分析,设计出业务静态建模图,如图3-3所示。
4 系统设计
4.1 体系结构设计
汽车维修管理系统使用MVC设计的思想,将模型层、视图层和控制层。结合工厂模式整体设计思路如下,分别将数据访问层,服务层每一层的最上方封装一个工厂类,控制层通过服务层的工厂类调用相关服务,服务类再调用数据访问层的工厂类来实现相关的数据访问层操作,体系结构设计的详情如图4-1。
4.2 系统总体设计
汽车维修管理系统主要分为五大模块,分别为汽车维修管理、配件管理、财务管理、基础数据管理和系统维护,系统功能总体的设计图如图4-2所示。
4.3 系统功能设计
4.3.1 车辆接待功能
车辆接待的功能主要是为了实现前台的工作人员对于来访的车辆进行一个车主和车辆信息的登记,同时安排相关的维修人员和质检人员进行后续的维修工作。该部分的主要业务逻辑为用户来访先查询是否有当前用户如果没有就需要重新录入用户的相关的信息。录入或者选择完用户的信息后,用户对用户的当前的车辆进行信息的登记,记录用户对应车辆的状况的描述,同时选择相关的维修人员和质检人员进行后续的修理操作。
车辆接待功能的设计类图如图4-3所示。
如上图4-3 车辆接待功能设计类图所示:
-
VehicleReception.jsp :该类表示汽车维修管理系统的接待页面
-
VehicleReception :该类表示汽车维修接待的控制层
-
ServiceFactory :该类为了描述所有的服务的类
-
IVehicleMaintence :该类主要为了描述汽车维修接待的服务接口
-
VehicleMaintence :该类主要描述了汽车维修管理部分的业务接口实现的部分
-
ICustomerMapper :改类为操作用户信息的数据访问接口
-
Ipersonalallocate :该类为维修订单人员分配的数据访问接口
车辆接待功能的顺序图如图4-4所示。
如上图4-4 车辆接待功能设计顺序图所示:
-
getAllUserDept :获取所有的用户信息和用户所在部门的信息
-
getVehicleMaintence :获取汽车维修管理的服务对象
-
queryUserSectorInEUI :查询出用户和部门的信息将结果以easyui数据结构的形式返回
-
getUserinfoMapper :获取用户信息数据库操作的接口
-
addUser :添加用户和车辆信息的方法
-
addUserVehicleInfo :服务层添加用户和车辆信息的方法,返回操作的结果
-
receptOrders :控制层用来添加维修订单的方法
-
newOrderList :服务层用来添加维修订单的方法
4.3.2 维修项目登记
维修项目登记为维修人员进入系统后查询到分配给自己的任务,可以根据条件查询,如按照时间范围、关键字和维修单的状态等进行查询。维修人员点击一条维修单可以看清楚接单员填写的有关车辆相关的信息,然后系统会查询维修用料情况和维修项目工时等相关情况。维修人员可以对维修项目工时的情况和使用零件材料情况进行管理。
维修项目登记功能的设计类图如图4-5所示。
如上图4-5 维修项目登记设计类图所示:
-
MaintanceProjReg.jsp :该类主要描述了维修项目登记的页面
-
IOrdersMapper :该类主要描述了维修订单管理的数据访问的接口
-
IMainprojregMapper :该类主要描述了维修项目登记的数据访问的接口
-
IPartMapper :该类主要描述了维修项目使用材料的数据访问接口
维修项目登记功能主要包括加载维修人员的维修任务信息、查看客户登记的信息、维修项目登记管理和维修使用材料登记管理等功能,其顺序图如图4-6所示。
如上图4-6 维修项目登记功能的顺序图所示:
-
queryAllTasks :该方法为查询所有当前的维修的任务
-
addMaintRegRecord :为当前的订单添加维修项目的登记
-
partsManage :为当前的维修的订单添加零件使用的纪录
-
endFixed :标记当前的维修项目已经登记完成进入下一步
-
queryMaintanceOrders :查询当前的所有维修的任务
-
addMainItemRecord :登记维修项目的信息
-
addPartRegtion :登记零件使用情况
-
finisedFixed :结束当前维修单的维修
4.3.3 维修领料
维修领料的环节为维修人员在登记了材料后,进行领取材料的操作。用户可以根据自己的工号、姓名和时间范围查询到自己的维修领料情况。用户点击维修后写入领取记录表,改变库存的数量,如果库存不足则写入采购表中,等待采购人员采购。维修领料的类图设计如图4-7所示。
如上图4-7 维修领料设计类图所示:
-
MaintenancePicking.jsp :该类主要作用为描述维修领料的页面
-
BeanUtils :该类主要作用为封装了将List类型的集合转化为分页的形式的数据结构
-
IPartusedMapper :该类主要作用为封装了零件使用历史记录的数据访问接口
-
IPartstorageMapper :该类为零件存储的数据访问接口
-
IPartprocMapper :零件采购的数据访问接口
维修领料的顺序图如图4-8所示。
如上图4-8 维修领料顺序图所示:
-
queryAllPickingRows :查询所有的领取材料的信息
-
pickPart :该方法主要功能为领取材料的信息
-
queryPickingView :该方法主要实现分页查询领取材料的信息
-
topagedResult :该方法主要实现的功能为将list类型的数据转化为分页形式的数据
-
selectPartUsed :查询已经登记过的材料的信息
-
IPartusedMaper.selectByPrimaryKey :通过主键查询已经登记过的材料的信息
-
updateByPrimaryKeySelective :更新已经登记过材料的信息
-
IPartstorageMapper.selectByPrimaryKey :通过主键查询零件存储的信息
-
insertSelective :向零件采购表中添加数据
4.3.4 质检完工
质检完工主要的功能为维修人员在进行维修结束后对自己的维修订单进行确认,确认无误后点击完成维修,则该笔维修订单到了质检完工的环节,质检人员首先查看自己的当前的所有的质检任务,然后点击质检查看维修人员登记维修项目的详细内容。质检人员对维修人员登记的每一个项目进行质检操作,如果合格点击审核通过,如果不合格点击审核不通过,同时可以输入不通过的理由。质检人员可以点击回退按钮,将该笔维修单让相关的维修人员重新进行维修操作。当所有的维修项目没有问题之后,质检人员可以点击审核通过,该笔订单进入支付结算的环节。
质检完工的设计类图如图4-9所示。
如上图4-9 质检设计类图所示:
-
IQualityinspecMapper :该类为质检的数据操作的接口
-
IMainprojregMapper :该类为维修项目数据操作的接口
-
IOrdersMapper :该类为订单信息数据操作的接口
质检完工的顺序图如图4-10所示。
如上图4-10 质检完工顺序图所示:
-
queryQualiting :按照条件查询当前所要质检的项目
-
getVehicleMaintence :控制层查询所要质检项目的方法
-
queryFixing :根据订单的编号查询当前维修订单下所有维修项目列表
-
queryAllFlexing :服务层查询所有维修项目等级情况的信息
-
endQualitied :结束质检项目的方法,改方法包含结束通过质检和将维修订单退回到维修环节中
4.3.5 消费结算
消费结算主要的功能是经过下单、维修质检后的最后一个步骤,用户进行付费提车。系统在付费时候,会自动查询出当前的订单所使用的的材料以及维修项目的列表的详细信息。用户支付完成以后表示整个业务环节结束。
消费结算的设计类图如图4-11所示。
如上图4-11消费结算设计类图所示:
-
ConsumptionSettle.jsp :该类表示维修订单结算的页面
-
IOrdersMapper :该类表示订单的数据访问接口
-
IBalancesheetMapper :该类表示维修订单支付情况的数据访问接口
消费结算的顺序图如图4-12所示。
如上图4-12 消费结算顺序图所示:
-
queryPayingView :查询待支付的维修订单的信息
-
queryAllPayOrder :业务层查询待支付订单的信息
-
queryAllPartUsedView :查询所有的当前订单下使用的材料的详细信息
-
queryMainitemUsed :查询所有的已经登记过的维修项目的信息
-
paymyOrders :对我的订单进行支付结算
4.4 数据库设计
4.4.1 数据库逻辑结构设计
汽车维修管理系统的ER图如图4-13所示。
4.4.2 数据表设计
账户(Account)数据表 ,作用是用来描述系统用户的信息。如表4-1所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 账户表编号 |
2 | accountnumber | char(20) | No | 账户号 |
3 | passwords | char(20) | No | 密码 |
5 | accountflag | char(10) | No | 账户的标记 |
6 | userinfoid | int | No | 用户信息表编号 |
结算(Balancesheet)数据表 ,作用描述用户支付的信息。如表4-2所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 结算表的编号 |
2 | settlementdate | datetime | No | 结算日期 |
3 | totalamount | double | No | 总金额 |
4 | settler | char(20) | No | 操作员 |
5 | ordersid | int | No | 订单表的编号 |
业务状态(Bustatus)数据表 ,作用是描述业务名称的信息。如表4-3所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | servicecode | char(20) | No | 服务的编号 |
3 | statename | varchar(40) | No | 业务名称 |
4 | remarks | char(40) | No | 备注 |
客户信息(Customer)数据表 ,作用是描述客户的信息。如表4-4所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | numbering | char(20) | No | 用户名称 |
3 | mailbox | char(80) | No | 邮箱 |
4 | contactinfo | varchar(100) | No | 联系方式 |
5 | idcard | char(18) | No | 身份证号码 |
6 | customerflag | char(50) | No | 客户的标记 |
客户信息来访(Customervisthis)数据表 ,作用是记录用户来访的信息。如表4-5所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | customername | char(20) | No | 客户姓名 |
3 | contactinfo | char(20) | No | 联系方式 |
4 | visitime | datetime | No | 来访时间 |
5 | servicecontent | varchar(200) | No | 登记内容 |
6 | isnew | smallint | No | 是否是新用户 |
7 | customer | int | No | 客户信息表的编号 |
维修项目(Mainitem)数据表 ,作用是描述维修项目的信息。如表4-6所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | mainnumbering | char(20) | No | 维修项目编号 |
3 | projName | varchar(100) | No | 项目名称 |
4 | projcategoryid | int | No | 项目类别编号 |
5 | itemprice | double | No | 项目的价格 |
6 | mainflag | char(10) | No | 维修项目的标记 |
维修项目登记(Mainprojreg)数据表 ,作用是描述的登记订单的维修项目的信息。如表4-7所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | ordersid | int | No | 订单的编号 |
3 | mainitemid | int | No | 维修项目的编号 |
4 | regperson | char(20) | No | 登记人 |
5 | spenttime | double | No | 耗费的工时 |
6 | mainstatus | char(10) | No | 维修项目登记的状态 |
7 | haspassed | smallint | No | 审核是否通过 |
订单(Orders)数据表 ,作用是描述订单的信息。如表4-8所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | numbering | int | No | 订单的流水号 |
3 | customerid | int | No | 客户的编号 |
4 | miles | double | No | 行驶里程数 |
5 | ifused | smallint | No | 是否查看旧件 |
6 | ifcheckspare | smallint | No | 是否检查备胎 |
7 | ifclean | smallint | No | 是否清洗车辆 |
8 | esdeliverytime | datetime | No | 预计提车时间 |
9 | warrcontent | varchar(200) | No | 登记的内容 |
10 | caritems | varchar(200) | No | 随车物品 |
11 | valuableobj | varchar(200) | No | 贵重物品 |
12 | ownerdescribtion | text | No | 车主描述故障信息 |
13 | hassettled | smallint | No | 是否修理完成 |
14 | completedate | datetime | No | 完成日期 |
15 | settlecompdate | datetime | No | 支付完成日期 |
16 | bustatusid | int | No | 业务状态的编号 |
17 | paystatusid | int | No | 支付状态的编号 |
零件(Parts)数据表 ,作用是零件的信息。如表4-9所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | partnumbering | int | No | 零件的流水号 |
3 | partcategoryid | int | No | 零件类别的编号 |
4 | partname | varchar(200) | No | 零件的名称 |
5 | purchaseprice | double | No | 采购价格 |
6 | salesprice | double | No | 销售价格 |
7 | specifications | char(100) | No | 规格 |
8 | remarks | varchar(400) | No | 备注 |
9 | partflag | char(10) | No | 零件的标记 |
10 | supplierid | int | No | 供应商的编号 |
零件类别(PartCategory)数据表 ,作用是描述零件类别的信息。如表4-10所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | numbering | int | No | 零件系统编号 |
3 | partcategory | varchar(100) | No | 零件类别名称 |
4 | partcatFlag | char(10) | No | 零件标记 |
零件采购(PartProc)数据表 ,作用是描述零件采购的信息。如表4-11所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | partcategoryname | varchar(100) | No | 零件类别的名称 |
3 | partcategorycode | char(20) | No | 零件类别的编号 |
4 | partname | varchar(100) | No | 零件名称 |
5 | partcode | char(20) | No | 零件的编号 |
6 | suppliercode | char(20) | No | 供应商编号 |
7 | suppliername | varchar(100) | No | 零件的名称 |
8 | pruchdemand | double | No | 零件的需求量 |
9 | pruchprice | double | No | 零件的采购价格 |
10 | pruchenum | double | No | 零件采购数量 |
11 | prucher | char(20) | No | 采购人 |
12 | totalpurchase | double | No | 采购合计 |
13 | purchstatus | char(10) | No | 采购的状态 |
零件存储(Partstorage)数据表 ,作用是描述零件采购的信息。如表4-12所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | partid | int | No | 零件编号 |
3 | warehouseid | int | No | 零件仓库编号 |
4 | detaillocation | varchar(200) | No | 零件的详细位置 |
5 | inventory | double | No | 库存量 |
6 | storagetime | datetime | No | 入库时间 |
7 | purchaser | char(20) | No | 采购人 |
8 | contactinfo | char(20) | No | 联系电话 |
9 | jobnumber | char(20) | No | 工号 |
10 | remarks | varchar(200) | No | 备注 |
零件使用记录(Partused)数据表 ,作用是描述零件使用的信息。如表4-13所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | ordersid | int | No | 订单编号 |
3 | partid | int | No | 零件编号 |
4 | useamount | double | No | 使用的数量 |
5 | applicant | char(20) | No | 申请人 |
6 | jobnumber | char(20) | No | 工号 |
7 | concatinfo | char(20) | No | 联系方式 |
8 | applicattime | datetime | No | 申请时间 |
9 | registedspecnum | double | No | 登记使用的数量 |
10 | noreceivingnum | double | No | 剩余领取量 |
11 | receivednum | double | No | 领取数量 |
12 | receivestatus | char(10) | No | 领取状态 |
支付状态(Paystatus)数据表 ,作用是描述支付状态的信息。如表4-14所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | paystatuscode | char(20) | No | 支付状态代码 |
3 | statusname | char(40) | No | 状态名称 |
4 | remarks | char(40) | No | 备注 |
人员分配(Personallocate)数据表 ,作用是描述人员分配的信息。如表4-15所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | userinfoid | int | No | 用户信息的编号 |
3 | ordersid | int | No | 订单编号 |
4 | taskcategory | char(10) | No | 任务类别 |
5 | allocatetime | datetime | No | 分配的时间 |
项目类别(Projcategory)数据表 ,作用是描述人员分配的信息。如表4-16所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | numbering | int | No | 类别编号 |
3 | projcateNum | int | No | 项目类别代码 |
4 | projname | varchar(100) | No | 项目名称 |
5 | catflag | char(10) | No | 类别标志 |
项目质检(Qualityinspec)数据表 ,作用是描述项目质检的信息。如表4-17所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | mainprojregid | int | No | 登记项目编号 |
3 | inspectperson | char(20) | No | 质检员 |
4 | jobnum | char(20) | No | 工号 |
5 | inspecttime | datetime | No | 质检时间 |
6 | remarks | varchar(200) | No | 备注 |
部门(Sector)数据表 ,作用是描述部门的信息。如表4-18所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | deptname | varchar(100) | No | 部门名称 |
3 | secflag | char(10) | No | 部门的标记 |
供应商(Supplier)数据表 ,作用是描述零件的供应商的信息。如表4-19所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | supplierName | varchar(200) | No | 供应商名称 |
3 | contacts | char(20) | No | 部门的标记 |
4 | phone | char(20) | No | 电话 |
5 | contactInfo | varchar(50) | No | 联系方式 |
6 | fax | char(20) | No | 传真 |
7 | mailbox | char(50) | No | 邮箱 |
8 | address | varchar(200) | No | 地址 |
9 | postcode | char(20) | No | 邮政编码 |
10 | bankaccount | char(20) | No | 银行账户 |
11 | suppflag | char(10) | No | 标记 |
用户信息(Userinfo)数据表 ,作用是描述用户的信息。如表4-20所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | username | char(20) | No | 用户信息 |
3 | jobnumber | char(30) | No | 工号 |
4 | concatinfo | char(20) | No | 联系方式 |
5 | address | varchar(200) | No | 地址 |
6 | entrytime | datetime | No | 登记时间 |
7 | userflag | char(10) | No | 用户标记 |
8 | sectorid | int | No | 部门编号 |
用户权限(Userrights)数据表 ,作用是描述用户权限的信息。如表4-21所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | permissionid | int | No | 权限编号 |
3 | accountid | int | No | 账户表编号 |
汽车(Vehicle)数据表 ,作用是描述汽车的信息。如表4-22所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | vehname | varchar(50) | No | 汽车名称 |
3 | carmodel | varchar(50) | No | 汽车型号 |
4 | inspectiondate | datetime | No | 年检日期 |
5 | milage | char(20) | No | 里程 |
6 | platenum | char(20) | No | 汽车牌号 |
7 | vehflag | char(10) | No | 汽车标记 |
8 | customerid | int | No | 客户表编号 |
仓库(Warehouse)数据表 ,作用是描述仓库的信息。如表4-23所示:
序号 | 字段名 | 数据类型 | 是否主键 | 意义 |
---|---|---|---|---|
1 | id | int | Yes | 编号 |
2 | warehouseName | varchar(100) | No | 仓库名称 |
3 | warehouseAdd | varchar(200) | No | 仓库地址 |
4 | remarks | varchar(200) | No | 备注 |
5 | wareflag | char(20) | No | 标记 |
4.5 安全性设计
汽车维修管理系统在安全性设计方面采用了登录、权限管理和拦截器的方式来保证系统的安全性和可靠性。
登录
用户在使用系统时,需要正确的输入自己的账号和密码否则系统校验不通过拒绝请求,登录设计的流程图如图4-14所示:
权限管理
用户准备登录时,在左侧的导航栏需要展示用户的所具备的功能,用户所具备的权限是系统管理员分配的。在一定程度上保证了系统的安全性。权限管理安全设计的流程图如图4-15所示:
拦截器
在前台调用后台的API时候,需要对发起请求的人进行身份的认证,认证方法为检查当前的session是否为空,如果为空表示为非法的请求,系统自动跳转到登录的页面。拦截器的安全设计流程图如图4-16所示:
5 系统实现
5.1 登录页面的实现
该页面作为系统的入口,用户通过输入自己的账号和密码,进入系统进行后续的操作。在登录框的右下角有记住账号和密码的勾选框,除非用户特别要求,系统默认勾选,表示让浏览器记住当前用户输入的账号和密码,避免以后用户重复输入。记住账号和密码保存在cookie中,系统设置浏览器保存cookie时长为2天,过期则会失效。系统具体页面设计和功能详情见图5-1。
5.2 后台首页的实现
该页面作为系统登录之后的第一个页面,首先显示的是四块统计图表的内容。分别为:接单量统计、营销额统计、采购金额统计和收入与采购占比。其中接单量统计、营销额统计和采购金额统计主要统计的默认当前年份下,按照月份为参数进行的一个数量的统计,收入和采购总额用饼图的方式展现了出来,这些图标形象生动的展现了当前汽车维修厂的业务情况。在接单统计表中,按照不同的月份进行统计,虚线部分代表平均值。在营销额统计表中,分别统计了每个月中结算的金额,展现了修理厂的运营情况。采购金额统计图表中,统计了每个月的采购材料的情况。在最后一张图表中,用饼图的方式展现了采购额和营销额的对比的情况。在导航栏部分,功能项是根据用户的权限自动生成的权限树,并显示出来,用户可以点击功能按钮切换到不同的功能页面。具体页面设计和功能详情见图5-2。
5.3 车辆接待的实现
5.3.1 车辆接待信息填写页面的实现
这部分主要是接单,用于填写客户的车辆状况信息,并安排维修人员和质检人员。其中选择员工为该系统下的所有的员工按照不同的部门树状图来显示,当需要添加维修人员时,点击任意部门下的员工进行拖拽,放置到已选维修人员的表格中,即可完成任务的分配。在提交信息之前系统会对所填写的信息进行一个合理的验证,保证数据的合理性。用户点击充值,可以清楚已经填写的相关的信息。页面具体设计和功能见图5-3。
5.3.2 添加用户的实现
该部分功能主要是应对客户第一次到当前汽车维修厂的场景。如果系统之前没有记录,需要将用户和车辆的相关信息录入到系统中,然后进行后续的业务操作。页面的设计和具体的功能见图5-4。
5.3.2 选择用户的实现
该功能主要应对的是老客户进入修理厂的业务场景,直接进行检索选择。在输入关键字中可以输入用户名、手机号、车牌号进行模糊查询,双击表示选中,然后进行后续的操作。页面的设计和具体的功能见图5-5。
5.4 维修项目登记的实现
5.4.1 维修项目登记主页面实现
该页面主要实现的工为进行维修的记录,包括维修项目的登记和维修使用材料的登记。在维修任务一栏,可以按照关键字、任务的状态、开始和结束时间进行条件查询,筛选出符合条件的记录。点击查看维修一栏,系统会加载客户的详情信息,以及维修项目和使用材料的信息。页面的设计和具体的功能见图5-6。
5.4.2 维修项目登记的实现
该页面主要是进行维修项目的添加,维修项目的修改以及维修项目删除的操作功能实现。根据业务逻辑当订单已经通过质检后无法进行删除修改的操作,在维修项目登记一栏显示了维修项目的状态。页面设计和具体功能见图5-7。
5.4.3 维修材料登记页面的实现
该页面主要完成的是对于某一个维修单进行维修材料的登记,在选择材料时,可以按照关键字进行模糊查询到相关的零件,然后双击,填写用料数量,确定并完成使用材料的登记,用户还可以在未曾质检之前对材料进行修改或者删除操作。页面设计和具体功能见图5-8。
5.5 维修领料的实现
该页面实现的功能为当维修人员进行材料登记后,进行领料的环节。可以根据维修人员的姓名或者工号、领取的状态、开始时间和结束时间进行模糊查询。当材料不够时,系统提示采购中,采购完成后方可领取材料。页面的具体设计和功能见图5-9。
5.6 质检完工的实现
该页面主要实现质检完工,当维修人员点击确定完工后,质检人员会查询到关于自己的维修单,单击维修检测,可以查看到订单维修的情况,然后可以点击审核,进行质检,通过或者不通过。当所有确认无误后,点击通过质检,并且该操作不能撤销,进入下一个业务环节。页面设计和具体功能见图5-10。
5.7 消费结算的实现
该页面主要完成当汽车完成了维修任务后进入到结算环节,系统会自动查询当前订单所有的使用材料和维修项目的详细情况,计算出总额进行支付。点击支付后表示用户完成了支付,该笔订单成为历史订单,整个主要业务环节结束。页面设计和具体功能见图5-11。
5.8 采购配件的实现
该页面主要是针对当库存不足时进行采购的操作,用户可以按照关键字、采购状态、开始时间和结束时间进行条件查询。用户还可以导出当前条件的excel文档。点击采购输入采购的金额,完成采购。页面设计和具体功能见图5-12。
5.9 库存管理的实现
该页面主要实现查看当前的所有的库存情况,用户可以点击修改销售价格进行零件信息价格的修改。在关键词一栏输入零件的名称或者零件的类别名称可以实现模糊查询零件的信息。页面设计和具体功能见图5-13。
5.10 供应商信息管理的实现
该功能主要是针对供应商的管理,用户可以按照关键字,供应商的状态进行条件查询。用户可以将所有的供应商的信息导出为excel文档。同时用户可以进行供应商的修改和删除操作。页面设计和具体功能见图5-14。
5.11 客户资料管理的实现
该功能主要是对系统中所有的客户信息的管理。可以按照客户名、客户的联系方式和汽车牌号进行模糊查询,修改和导出excel等操作。页面设计和具体功能见图5-15。
5.12 系统基础数据配置的实现
该功能为系统所有权限的管理,用户可以点击开启或者关闭功能,进行权限的放开和回收功能,页面设计和具体功能见图5-16。
5.13 系统用户管理的实现
该功能主要实现的是对系统用户的管理,用户可以按照用户名、手机号、工号和状态进行条件查询,还可以对用户进行删除和修改信息操作。页面设计和具体功能见图5-17。
5.14 修改密码的实现
该页面主要实现用户对密码的修改操作,两次输入的密码必须一致才能修改成功,修改成功后需要重新登录。页面设计和具体功能见图5-18。
5.15 数据备份还原的实现
该页面主要实现的功能为将数据库的数据和接口导出为sql文件,或者将sql文件导入进行数据库的还原操作。页面设计和具体功能见图5-19。
6 系统测试
软件开发和部署完毕后需要对已经开发好的系统进行一个测试,下面对车辆接待的功能模块进行系统的测试,具体的测试内容如下所示。
6.1 车辆接待模块选择用户功能测试
车辆接待模块选择用户功能的测试结果如图6-1所示:
序号 | 测试用例 | 预期结果 | 实测结果 | 测试状态 |
---|---|---|---|---|
1 | 点击选择用户 | 弹出模态框,里面分页显示了客户的相关信息 | 与预期的结果相符 | 1 |
2 | 输入关键字查询用户的信息 | 系统会显示出所有的符合条件的数据 | 与预期的结果相符 | 1 |
3 | 点击下一页,进行数据的切换 | 系统会显示对应页号的数据 | 与预期的结果相符 | 1 |
4 | 双击选中用户 | 系统会选中当前数据,把用户名和汽车牌号显示在当前用户的输入框中 | 与预期的结果相符 | 1 |
5 | 点击清除用户 | 系统会将当前的用户的信息栏清空 | 与预期的结果相符 | 1 |
6 | 未完全填写必要的字段,点击提交数据 | 系统提示请填写相应的数据 | 与预期的结果相符 | 1 |
6.2 车辆接待模块选择添加用户功能能测试
车辆接待模块添加用户功能测试的结果如图6-2所示:
序号 | 测试用例 | 预期结果 | 实测结果 | 测试状态 |
---|---|---|---|---|
1 | 点击添加按钮 | 弹出模态框,显示输入用户信息模块框 | 与预期的结果相符 | 1 |
2 | 不输入信息直接提交 | 系统验证表单不通过,提示输入信息 | 与预期结果相符 | 1 |
3 | 输入合法信息提交 | 系统添加当前用户的信息,并把当前的用户的姓名和汽车牌号显示在当前用户的输入框中,提示成功 | 与预期的结果相符 | 1 |
6.3 车辆接待模块分配维修人员和质检人员功能测试
车辆接待功能分配维修人员和质检人员功能测试结果如图6-3所示:
序号 | 测试用例 | 预期结果 | 实测结果 | 测试状态 |
---|---|---|---|---|
1 | 选中该用户拖拽到表格中 | 表格中会显示当前选中的用户的信息 | 与预期的结果相符 | 1 |
2 | 点击删除 | 表格中的用户会被删除,提示删除该用户成功 | 与预期的结果相符 | 1 |
3 | 如果重复添加用户 | 系统会提示已经添加过该用户,请重新添加 | 与预期的结果相符 | 1 |
6.4 车辆接待模块添加维修单功能测试
车辆接待功能模块添加维修单功能测试结果如图6-4所示:
序号 | 测试用例 | 预期结果 | 实测结果 | 测试状态 |
---|---|---|---|---|
1 | 不输入信息 | 系统提示请输入信息后提交 | 与预期的结果相符 | 1 |
2 | 输入合法信息 | 系统提示是否确认提交,确定后提示添加成功 | 与预期的结果相符 | 1 |
3 | 清除用户信息 | 系统提示是否确定删除,如果确认就删除所选择的用户的信息 | 与预期的结果相符 | 1 |
4 | 点击刷新 | 系统会提示刷新后将不再保存当前的数据,是否刷新?确定后将重新刷新该页面 | 与预期的结果相符 | 1 |
结论
该系统主要是解决汽车修理厂的日常管理任务而设计和开发的一款比较实用的软件。能够帮助维修厂的工作人员减轻一定的工作压力,综合分析来看整个软件在以下几个方面具有一定的参考价值和实际价值。
-
需求分析阶段使用了强大的UML分析建模工具结合面向对象思想和软件工程的方式来分析设计这款软件
-
从软件架构上,采用了目前企业比较流行的java开发框架SSM,分别为Spring、SpringMVC和MyBatis,大大减少了开发人员的工作量,提高了开发效率,使开发人员真正专注于业务逻辑代码的实现,而不用去多的底层的重复的冗余部分
-
在软件的用户体验上来看,软件使用了当前比较流行的后端管理系统的前端开发框架EasyUI,页面整齐大方重点功能突出,用户体验相对较好
-
在软件安全的方面,汽车维修管理系统专门开发了用户权限管理部分和接口访问的拦截器部分,这大大提高了软件的安全性,从多方面去保护用户的数据不被窃取
-
从软件的现实价值上来看,软件能够真正帮助汽车维修厂解决他们日常运营的痛点,提升他们的工作效率,在一定程度上为汽车修理厂带来了经济效益,提升他们在同行业中的竞争力
汽车维修管理系统能够保证维修厂日常的运营工作,同时也有很多其他方面问题需要去解决。
-
比如在系统的财务管理部分没有去深挖需求,让维修厂的维修工作和财务工作无缝的对接
-
软件在维修材料这方面的信息管理没有做到强控制,比如原材料采购方面还是需要工作人员从系统中导出excel文档,查看相应的维修任务,去进行原材料的采购,系统可以在这方便再做一些优化
-
系统在分析统计报表上用户能够查看每一个月的具体营销情况,但是可以考虑做到细粒度的统计,统计每一天的接单量和维修报表情况
总体上,系统完成了需求分析中的维修厂管理的的需求要点,流程安排相对合理、规范,达到了本课题设计的要求。
参考文献
[1] 布奇.UML用户指南[M].北京:人民邮电出版社,2013
参考文献
- 基于.NET汽修汽配管理系统设计与实现(电子科技大学·王乐琳)
- 上汽集团汽车4S店管理系统设计与实现(大连理工大学·邵晓华)
- 基于某军用信息系统数据库系统的设计与实现(华北工学院·马巧梅)
- 基于SSH框架的汽车销售服务系统的设计与实现(西安电子科技大学·屈鑫)
- 汽车配件管理信息系统的设计与实现(山东科技大学·倪见素)
- 基于某军用信息系统数据库系统的设计与实现(华北工学院·马巧梅)
- 汽车配件管理信息系统的设计与实现(山东科技大学·倪见素)
- 北汽福田汽车股份公司汽车零部件销售管理信息系统设计与实现(山东大学·赵增成)
- 基于某军用信息系统数据库系统的设计与实现(华北工学院·马巧梅)
- 承压设备泄漏事故应急决策与救援指挥系统的建设(北京邮电大学·宋丹杰)
- 上汽集团汽车4S店管理系统设计与实现(大连理工大学·邵晓华)
- 基于J2EE的汽车维修信息系统设计与实现(天津大学·孙震)
- 韩泰轮胎公司汽车配件管理系统的设计与实现(大连理工大学·单君轶)
- 基于SSH框架的汽车销售服务系统的设计与实现(西安电子科技大学·屈鑫)
- 北汽福田汽车股份公司汽车零部件销售管理信息系统设计与实现(山东大学·赵增成)
本文内容包括但不限于文字、数据、图表及超链接等)均来源于该信息及资料的相关主题。发布者:代码海岸 ,原文地址:https://bishedaima.com/yuanma/35361.html