车险理赔信息自动收发系统.docx

车险理赔信息自动收发系统摘要：车险理赔信息自动首发系统，是某保险公司下辖市级分公司订制开发的一款业务流程辅助系统，主要用于对保险公司总公司分发的信息进行收集，然后通过此系统对分公司下辖的业务人员进行再次分发的一个系统。该系统由两部分组成，第一部分是短信收集端，通过一个叫短信猫的第三方硬件收集指定手机卡中的短信，进行一个数据的初步收集，然后存进数据库以供后台管理端进行进一步的业务流程操作。第二部分是自动首发系统的后台管理端。后台管理端负责让系统操作员对短信收集端收集到的数据进行进一步操作。其中后台管理端涉及到系统模块，业务模块两大模块。系统模块包含用户管理，角色管理，权限管理等三个子模块。业务模块则包含短信记录，理赔人员，短信匹配规则设置三个子模块。后台管理端采用SPringBoOl框架开发，持久层框架则采用当前最流行的MyBatis框架，数据库采用的是MYSQL。本论文首章主要概述车险理赔信息自动收发系统的背景及开发意义。然后通过针对性的研究车险理赔信的收发业务流程制定出系统的基本架构与需求。再对所使用技术栈进行一个深入的了解与阐述。最终开发出一套高效的自动化的系统来简化理赔信息收发的业务流程。在开发完毕后，还会进行单独与整体的完整测试。项目最终完成了开发，并且成功部署上线，正式投入到实际生产当中，理赔信息收发从以前的24小时人工值班，人工分发信息变成全自动的筛选与分发，给客户带来了效率增长与人力节省的双重提升。关键词：短信猫，Springboot,车险，MyBatis,MySQLVehicleInsuranceClaimInformationAutoReceivingAndSendingSystemAbstract:Autoreceivingandsendingsystemofvehicleinsuranceclaiminformation,ltisabusinessprocessauxiliarysystemcustomizedanddevelopedbyamunicipalbranchunderthejurisdictionofaninsurancecompany,Thissystemismainlyusedtocollecttheinformationdistributedbytheheadofficeoftheinsurancecompany,andthissystemistoredistributethebusinesspersonnelunderthejurisdictionofthebranchcompany.Thesystemiscomposedoftwoparts.ThefirstpartisthecollectionofSMS,whichcollectstheSMSinthedesignatedmobilevehicledthroughathird-partyhardwarecalledSMScat,Itconductsapreliminarycollectionofdata,andthenstoresitinthedatabaseforfurtherbusinessprocessoperationbythebackgroundmanagement.Thesecondpartisthebackgroundmanagementoftheautomaticlaunchsystem.BackgroundmanagementisresponsibleforthesystemoperatortofurtheroperatethedatacollectedbytheSMScollectionend.Thebackgroundmanagementinvolvestwomodules:systemmoduleandbusinessmodule.Thesystemmoduleincludesthreesubmodules:usermanagement,rolemanagementandauthoritymanagement.Thebusinessmoduleconsistsofthreemodules:SMSrecord,claimadjusterandSMSmatchingruleselting.Thebackgroundmanagementusesthespringbootframework,thepersistencelayerframeworkusesthemostpopularmybatisframework,andthedatabaseusesmysql.Thefirstchapterofthispapermainlysummarizesthebackgroundanddevelopmentsignificanceofautoreceivingandsendingsystemofautomobileinsuranceclaiminformation.Throughthetargetedresearchonthebusinessprocessofreceivingandsendingautomobileinsuranceclaiminformation,thebasicstructureandrequirementsofthesystemarefbrmulated.Then,itmakesanin-depthunderstandingandelaborationofthetechnologystackuscd.FinaIly,anefficientandautomaticsystemisdevelopedtosimplifythebusinessprocessofclaiminformationsendingandreceiving.Afterthecompletionofdevelopment,therewillbeacompletetest,bothindividuallyandasawhole.Theprojectfinallycompletedthedevelopment,andsuccessfullydeployedonline.ltwasofficiallyputintoactualproduction.Theclaiminformationwassentandreceivedfromtheprevious24-hourmanualduty,andthemanualdistributionofinformationbecamefullyautomaticscreeninganddistribution,whichbroughtthedoubleimprovementofefficiencygrowthandlaborsavingtocustomers.Keywords:GSMModem,SpringBoot,vehicleinsurance,MyBatis,MySQL目录第1章绪论11.1 系统开发的背景及意义11.2 国内外研究现状21.2.1 国外研究现状21.2.2 国内研究现状错误！未定义书签。1.3 系统主要研究内容21.4 系统开发环境与开发工具3第2章系统需求分析52.1 系统的核心业务流程分析52.2 系统的整体功能需求分析62.2.1 后台管理员主要功能介绍82.3 可行性分析52.3.1 经济可行性52.3.2 操作可行性5第3章系统设计与实现183.1 系统总体架构设计183.2 功能模块设计233.2.1 短信收发端233.2.2 后台管理端243.3 数据库设计283.3.1 表设计283.4 系统实现333.4.1 短信收发端333.4.2 后台管理端36第4章系统测试414.1 系统测试414.1.1 测试的意义414.1.2 测试的目的错误！未定义书签。4.1.3 软件测试方法错误！未定义书签。4.1.4 本系统测试介绍错误！未定义书签。4.1.5 测试用例及测试结果错误！未定义书签。第5章结束语错误!未定义书签。5.1全文总结错误!未定义书签。参考文献：错误!未定义书签。第1章绪论1.1 系统开发的背景及意义保险，是每个人每个家庭最好的风险对冲工具，经过几十年的发展，人们的保险意识越发提高，参保人数稳定增长，保险，是一个巨大的市场。而其中一种最常见的保险业务，则是车辆保险业务，简称车险。现在全国的汽车保有量已经连续几年保持飞速增长，往后，增长就算放缓，全国的汽车保有量也只增不减，毕竟衣食住行，行，是一个实实在在的刚性需求，在此背景下，汽车的关联业务车险业务，也拥有着巨大的市场与可持续的前景。车险，分为交强险和商业险。其中交强险，由交通部门规定每辆车上路前强制购买，其中包含了车辆的交强险保费，还有车辆的车船税。而商业险，则由商业保险公司自行制定，由车主自主选择是否购买。相比国家规定的交强险，商业险保障的范围更多更细，各大保险公司的针对推出的险种有时会有些区别，但基本大同小异。一般主要险种为：第三者责任险，车损险，盗抢险，玻璃险，自燃险，三方代偿六种。各个险种针对的事故种类不一样，保费价格也有差异，比如第三者就是专门针对交通事故后，对除了车主本人外，对其他人造成的损失进行赔付的险种。而车损险，则是对自己的车造成的损失进行赔付的险种。盗抢险，主要是车被盗后，到公安部门报案，三个月没找到，可以要求进行理赔。玻璃险，即指代车辆在行驶过程中玻璃破碎的一种商业险。自燃险指代汽车在行驶过程中自燃的车险。机动车在路上行驶时，由于各种情况，发生事故的几率是比较高的。因为这一特性，车险业务的理赔率也比其他保险高一些，在这背景下，理赔业务的很多流程急需一些数字化的软件工具来简化流程，从而达到提高效率和节省人力。在车险公司还没使用车险系统的时候，一辆机动车发生事故时，首先要通知保险公司进行报险，然后保险公司要通知查勘员（对车辆碰撞修复进行科学系统的估损定价的专业技术人员），查勘员到达现场后，查勘现场，对被保险车辆的损失情况进行定损，跟事故车车主确定维修地点，最后把信息发给理赔专员，最后由理赔专员向车辆被保人或者汽车维修厂进行保额赔付。在这整个流程中，有一个这样的业务流程：保险公司在接到报险电话后，确定到事故地点，首先要通过一条短信通知事故所在地的分公司，然后分公司通知当地的查勘员到达现场。分公司在通知查勘员后，一般还会通知附近的合作汽车维修点。但这里涉及到一个问题，保险公司给分公司发出报险信息之后，一个分公司覆盖的地方很大，而每个查勘员负责的地方是有划分的，分公司在接到报险中心发来的短信后，首先得进行人工的范围筛选，筛选出对应的查勘员后，再通知相应的查勘员还有附近的汽修o这里，要求保险公司分公司24小时有人值班在线，充当一个联络员的角色。本系统就是根据这一业务流程，接受保险公司的委托，定制的一套信息推送系统。在系统上线后，分公司在接收到保险公司的报险中心的信息后，将会由系统进行自动筛选信息，然后再通过短信通知对应的查勘员和附近的汽车维修厂，省去了联络员的人手，还有系统快速的筛选增强了保险公司出险的速度。大大的改进了关于理赔出险这一业务的效率与减低了成本。1.2 国内外研究现状1.2.1 国外研究现状在国外，无论是保险行业还是软件行业，都有着比国内更加先进的业务流程与技术水平。基于保险业而言，国外的保险业相比国内，参保人数更多，覆盖人群更广，后续的理赔流程更简便，效率更高。这与国外的市场起步时间较早有关。而软件行业就更加不用说了，多年来，国外的数字化程度一直都比国内更高，虽然随着近来来国内互联网市场的大热，国内的软件水平也是突飞猛进，不可同日而语。但在传统行业的数字化方面，无论是普及程度还是项目质量，国内与国外还是有一定的差距。1.2.2 国内研究现状国内的软件行业，从上个世纪九十年代开始发展，到现在已有三十年的历史，在早期的二十年，中国的软件水平相比欧美或者日韩一些发达国家，一直处于落后的地位，但随着近十年来互联网市场大热的原因，很多互联网项目表现出了超一流的技术水平与用户体验，在与国外产品对比时也不落下风甚至已经实现了弯道超车。虽然国内在互联网项目取得了如此大的成就，但相比而言，传统行业的数字化建设却显得不是那么成熟。大量的传统行业只是实现了简单的数据管理，很多业务流程并没有真正的接入线上。以保险行业为例，在了解本次项目的业务需求时，我就得知，虽然保险公司总公司的系统非常完善，但是其下辖的分公司，比如本项目的客户东莞某保险公司分公司，在信息分发的时候还是采用最传统的人工分发，24小时值班的分公司查勘中心，在接到总部报案中心发来的出险信息后，通过人工筛选以后通知对应的查勘员到达现场处理。整个过程，不仅人力要求多，而且耗时也比较慢，实在是一种比较落后的做法。通过此例子可得知，在一些传统行业，数字化水平还急需完善和改进。1.3 系统主要研究内容车险理赔信息自动收发系统主要研究的内容分为业务上的还有技术上的。在业务上，需要理解整个车险行业的出险查勘流程，理赔信息的发送流程，匹配规则。在技术上，本项目中，分为一个短信收发端，还有一个后台管理端，短信收发端借助一个叫短信猫(GSM-SMMODEM)的第三方硬件设备读取特定几张手机卡收到的短信，通过c3p连接池连接数据库，把数据存进短信记录表里以等待后台管理端的定时任务调用。后台管理端则采用SpringBoot框架作为项目框架，持久层框架采用MyBatis,前端页面模板使用ThymeIeaf,数据库则采用MySQL数据库，通过Redis缓存部分数据。1.4 系统开发环境与开发工具本系统开发环境：Windowsio操作系统，jdki.8,idea2018,35,mysql5.6,CENTOS6.5,Redis64.3o采用了以下技术：SpringBoocSpring是Pivotal团队提供的一个开发框架，里面集成了SpringMVC和SPring框架的所有功能，还内置了Web容器，配置简单，上手容易，比起传统的JaVaWeb项目省去了大量繁琐的配置，是当前java开发最受欢迎的框架。MyBatisMyBatis框架是一个基于SQLMAP思想的持久层框架，如官网所说，MyBatiS避免了所有在JaVa代码中编写SQL的情况，而且封装了JDBC代码，通过配置映射SQL与接口还有实体类，大大简化了持久层的编写。而且MyBatiS还有一个很大的特点，就是上手容易，学习成本低，而且相比一些ORM框架，运行速度较快，无论从哪点来看都是很优秀的持久层框架。ThymeleafiThymeleaf是SpringBoot默认的页面模板引擎，相比JSP5Thymeleaf模板能够直接被浏览器所渲染，不需要经过模板引擎解析器，在开发调式的时候非常方便，在语法方面，ThymeIeaf与JSP的差别不大，上手也比较容易。MySQLMySQL是一个开源的免费的关系型数据库，是目前世界上最流行的关系型数据库之一，相比其他商业型数据库，MySQL虽然可能在某些方面有着自己的一些短板，但是作为一款免费的数据库，从稳定性，运行速度来说，MySQL各项指标都达到了一款商用数据库的标准，所以，对于一些中低成本的软件项目来说，MySQL是最好的选择之一。Redis:Redis是一个高性能的，基于Key-ValUe的内存缓存数据库，相比与传统的把数据写入硬盘的数据库，内存缓存数据库具有高性能的特点，对于一些读取频繁的数据而已，存在内存缓存数据库能避免频繁的调用K）访问硬盘。提高性能。第2章系统需求分析2.1 可行性分析2.1.1 经济可行性本系统经过初期的项目评估，定下了一个月的工期，时间方面比较充裕，由两名开发人员参与，加上一个第三方硬件的采购，算上以后的折旧替换，项目成本基本确定，比较符合客户的预期。而系统本身带来的经济效益，首先第一可以替换掉一个24小时值班的信息分发部门，能节省下相当多的人力物力，而且是永久性的。第二，此系统可以带来效率的巨大提升，所以此系统是完全具有经济可行性的。2.1.2 操作可行性从操作可行性的角度来说，这系统的开发涉及到的技术都是目前市面上比较成熟的技术，比如SPringBOot作为一个JaVaWeb框架，拥有巨量的用户，非常专业的支援团队，成熟的交流社区。其他的如数据库MySQL,持久层框架MyBatis,缓存数据库Redis,都拥有上面的特性，说白了，就是本系统采用的技术栈都非常成熟，在开发中就算遇到问题也能比较容易的解决。而本系统短信收发端中涉及到的另一个硬件短信猫，相比而言则比较小众一点，项目组在初期的方案调用时，第一时间就是研究短信猫硬件的使用，包括这硬件的使用方法，稳定性，接口文档，发现完全能符合此项目的需求。而在业务上，此系统的需求，一个全自动的信息筛选与信息分发系统，也是完全能通过而且客户也迫切希望系统取代传统人手负责的流程，所以无论是技术上，还是业务上，本项目都是具备操作可行性的。2.1.3 2系统的核心业务流程分析软件项目开发中，需求分析是非常重要的一个环节。需求分析是一个了解业务流程和客户想法的过程。有充分的需求分析，再经过转化，才能设计出合理的项目结构还有代码流程。在需求分析的时候，首先得把大致的业务流程了解清楚，然后到具体功能的设计，聆听客户的特定想法，最终落实转化为系统模块。本系统的核心业务流程其实就是信息的分发，通过短信收发端收集到的短信，在经过指定的匹配规则后，先把一些不需要的跟本系统无关的短信去掉，剩下的则称为业务短信。然后把业务短信进行进一步的筛选，根据指定的筛选规则筛选出对应的理赔员，然后往理赔员的手机上发送一条短信。图2T系统核心业务流程图短信记录分两种匹配状态，一种记录是否业务短信，一种记录是否匹配对应理赔员。如果短信两次匹配都为成功，则触发发送短信功能，把发送状态改为发送中，等待发送短信状态Pl调。发送成功则改为发送成功，发送失败和发送异常的区别在于，发送失败为短信接口返回失败，会在往后重新尝试发送，发送异常则在系统发送短信过程中抛出了异常，则记录为发送异常，不会尝试重新发送的操作。2.3系统的整体功能需求分析在后台管理端里，后台管理员负责后台的系统管理，如权限管理，角色管理，用户管理等三个模块的管理。还有业务管理中的短信记录管理，理赔人员管理，匹配规则管理等三个模块。如图2-2所示:用户管理后台管理员角色管理权限管理后台管理端功能模块短信记录管理业务管理理赔员管理匹配规则管理图2-2后台管理端各模块图主要的业务功能都是针对短信的，如短信发送，短信查看，短信匹配规则设置,和理赔员的匹配规则设置，如图2-3所示开用立管课后台置理员收理置理短信前新恐配知假皮送实聚帮值重新发送后台管理端功能模块报组记水，岁选异常想信堂新友是理职分重新进配业务营理读艇央管理否看齿好染四配现州置理图2-3后台管理端各功能图2.3.1后台管理员主要功能介绍(1)登录：系统用户输入手机号码密码进行登录，输入正确的验证码才能登录，反之则提示密码错误，需要重新登录。(2)权限管理：管理员在登录之后，可以对权限管理进行查看权限，增加权限，删除权限和修改权限。(3)角色管理：该管理主要是设置角色的权限。管理员在登录之后，可以对角色管理进行查看角色，增加角色接着进行角色的权限选择，删除角色，修改角色的权限和角色名字。(4)用户管理：该管理主要是设置该用户拥有的角色。管理员在登录之后，可以对用户管理进行查看用户的信息，增加用户接着进行用户的角色选择，删除用户，修改用户角色，用户名字，手机号码和密码。(5)余额查看：管理员登录在主页能查看自己的手机号码，还有在本系统拥有的余额，余额在进行短信发送时，发送成功时结算扣减。(6)接收短信记录管理：管理员在登录之后，可以查看接收短信的记录，短信记录包括信内容，接收时间，匹配时间，发送备注。短信记录在最初收集进数据库时为初始状态，还分别有三个字段记录数据状态，一个为是否业务短信状态，也可对接收短信的记录进行删除，也可导出其记录。(7)发送短信记录管理：管理员在登录之后，可以对发送短信的信息进行查看，也可对其进行删除，也可导出其信息。(8)理赔员/查勘员管理：管理员在登录之后，可以查看理赔员/查勘员的信息，增加理赔员/查勘员信息，删除理赔员/查勘员信息，修改理赔员/查勘员信息。(9)匹配规则管理：添加匹配规则，删除匹配规则，修改匹配规则，查看匹配规则。2.3.2查勘员/理赔员主要功能介绍(1)登录：系统用户输入手机号码密码进行登录，输入正确的验证码才能登录，反之则提示密码错误，需要重新登录。(2)用户管理：可查看当前用户信息。(3)发送短信记录管理：用户在登录之后，可以对发送短信的信息进行查看，也可导出其信息。(4)接收短信记录管理：用户在登录之后，可以对接收短信的信息进行查看，也可导出其信息。2.4UML系统建模2.4.1 用例描述(1)系统管理用例描述图2-4车险理赔信息自动收发系统用户系统管理用例图用例名称用户管理用例描述用户信息管理，实现用户基本信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行用户信息的管理操作1. 1进入用户信息列表1.2添加用户信息1.21系统打开用户信息添加页面L22填写用户基本信息1. 23选择保存或重置1.24 保存，返回L26操作1.25 重置，返回1.22操作1. 26后台数据库添加成功后返回添加用户信息1. 27显示添加成功的用户信息给管理员1.3修改用户信息1. 31系统打开用户信息修改界面1.32管理员选中具体的员工信息，并双击1. 33系统显示当前用户的详细信息1.34 系统管理员选择保存或者重置1.35 保存，返回L37操作1.36 重置，返回L33操作1.37 后台数据库修改成功后返回修改用户信息1. 38显示修改成功的用户信息给管理员1.4删除用户信息1. 41系统打开员工信息列表界面1.42管理员选中要删除的员工信息，点击“删除”按钮1. 43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回L41操作L45取消，返回1.41操作L46后台数据库删除成功后显示更新后的员工信息给予管理员1.5查询用户信息1.5.1系统打开员工信息查询界面1.5.2系统显示所有员工信息，管理员选择“查询”L6角色设置1.6. 1系统打开员工信息查询界面L6.2管理员选中具体的员工信息，并双击1.6.3点击角色设置按钮，弹出角色下拉框，选则角色，点击确定1.6.4后台数据库修改成功后返回用户信息可选操作流程角色设置用例名称角色管理用例描述角色信息管理，实现角色基本信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行角色信息的管理操作L1进入角色信息列表1. 2添加角色信息1.21系统打开角色信息添加页面1.22填写角色基本信息L23选择保存或重置L24保存,返回1.26操作L25重置,返回1.22操作1.26后台数据库添加成功后返回添加角色信息1. 27显示添加成功的角色信息给管理员1.3修改角色信息1. 31系统打开角色信息修改界面1.32管理员选中具体的角色信息，并双击1. 33系统显示当前角色的详细信息1. 34系统管理员选择保存或者重置1.35 保存，返回L37操作1.36 重置，返回1.33操作1. 37后台数据库修改成功后返回修改角色信息1. 38显示修改成功的角色信息给管理员1.4删除角色信息L41系统打开角色信息列表界面1.42管理员选中要删除的角色信息，点击“删除”按钮1. 43弹出删除二次确认框，系统管理员选择确定或者取消1.44 确定，返回L41操作1.45 取消，返回L41操作L46后台数据库删除成功后显示更新后的角色信息给予管理员1.5 查询角色信息1 .5.1系统打开角色信息查询界面2 .5.2系统显示所有角色信息，管理员选择“查询”1.6 权限设置1.6. 1系统打开角色信息查询界面1.6.2管理员选中具体的角色信息，点击权限修改按钮1.6.3点击角色设置按钮，所有权限，勾选需要的权限，点击确定1.6.4后台数据库修改成功后返回角色信息可选操作流程权限设置用例名称权限管理用例描述权限信息管理，实现权限基本信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行权限信息的管理操作Ll进入权限信息列表1. 2添加权限信息1.1 21系统打开权限信息添加页面1.22 填写权限基本信息1.23 选择保存或重置1.24保存,返回1.26操作L25重置,返回L22操作1.26后台数据库添加成功后返回添加权限信息1.27显示添加成功的权限信息给管理员1. 3修改权限信息1. 31系统打开权限信息修改界面L32管理员选中具体的权限信息，并双击1.33系统显示当前权限的详细信息1.34系统管理员选择保存或者重置L35保存,返回L37操作L36重置,返回L33操作1.37后台数据库修改成功后返回修改权限信息1.38显示修改成功的权限信息给管理员1. 4删除权限信息L41系统打开权限信息列表界面1.42管理员选中要删除的权限信息，点击“删除”按钮1. 43弹出删除二次确认框，系统管理员选择确定或者取消L44确定，返回1.41操作L45取消,返回1.41操作1.46后台数据库删除成功后显示更新后的权限信息给予管理员1. 5查询权限信息1. 5.1系统打开权限信息查询界面1.5. 2系统显示所有权限信息，管理员选择“查询”可选操作流程用例名称查看用户用例描述用户信息查看参与者理赔员/查勘员优先级2前置条件理赔员/查勘员已登录系统后置条件用户只能查看自己的数据基本路径1、理赔员/查勘员进行用户信息的查看操作LI系统打开用户信息列表可选操作流程(1)业务管理用例描述管理员、查勘员/理赔员o 一发送姣信管理导出信息 .ro <<indude>>查看发送短信匹配规则管理图2-4车险理赔信息自动收发系统用户业务管理用例图用例名称查勘/理赔员管理用例描述查勘/理赔员管理，实现查勘/理赔员信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行查勘/理赔员信息的管理操作Ll进入查勘/理赔员信息列表L2添加查勘/理赔员信息1. 21系统打开查勘/理赔员信息添加页面1.22 填写查勘/理赔员基本信息1.23 选择保存或重置1.24 保存,返回L26操作1.25 重置，返回L22操作L26后台数据库添加成功后返回添加查勘/理赔员信息1.27显示添加成功的查勘/理赔员信息给管理员1.3修改查勘/理赔员信息1. 31系统打开查勘/理赔员信息修改界面L32管理员选中具体的查勘/理赔员信息，并双击1. 33系统显示当前查勘/理赔员的详细信息2. 34系统管理员选择保存或者重置L35保存，返回1.37操作L36重置，返回L33操作1. 37后台数据库修改成功后返回修改查勘/理赔员信息1. 38显示修改成功的查勘/理赔员信息给管理员L4删除查勘/理赔员信息1. 41系统打开查勘/理赔员信息列表界面1.42管理员选中要删除的查勘/理赔员信息，点击“删除”按钮1. 43弹出删除二次确认框，系统管理员选择确定或者取消1.1 44确定,返回1.41操作1.45 取消，返回1.41操作1.46 后台数据库删除成功后显示更新后的查勘/理赔员信息给予管理员L5查询查勘/理赔员信息1.5. 1系统打开查勘/理赔员信息查询界面1.6. 2系统显示所有查勘/理赔员信息，管理员选择“查询”可选操作流程用例名称接收短信管理用例描述接收短信管理，实现接收短信信息的删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行接收短信信息的管理操作LI进入接收短信信息列表L2修改接收短信信息1. 21系统打开接收短信信息修改界面1.22管理员选中具体的接收短信信息，并双击1.23系统显示当前接收短信的详细信息1.24系统管理员选择保存或者重置L25保存,返回1.27操作1.26重置,返回L23操作1.27后台数据库修改成功后返回修改接收短信信息1. 28显示修改成功的接收短信信息给管理员1.3删除接收短信信息1. 31系统打开接收短信信息列表界面L32管理员选中要删除的接收短信信息，点击“删除”按钮L33弹出删除二次确认框，系统管理员选择确定或者取消L34确定,返回L36操作1.35取消,返回L31操作L36后台数据库删除成功后显示更新后的接收短信信息给予管理员L4查询接收短信信息14.1系统打开接收短信信息查询界面1.4. 2系统显示所有接收短信信息，管理员选择“查询”1.5导出短信记录1.51 管理员勾选需要导出的短信记录1.52 点击导出信息按钮L53弹出文件选择系统，选择文件保存路径，然后点解确定或者取消L54确定，返回L56操作L55取消，返回L51操作1.56文件以浏览器下载方式下载可选操作流程用例名称查看已收短信用例描述查看已经接收到的信息参与者查勘员/理赔员优先级2前置条件查勘员/理赔员已登录系统后置条件用户只能看见属于自己的短信基本路径1、理赔员/查勘员进行短信信息的查看操作1.1系统打开短信信息列表可选操作流程用例名称导出信息用例描述导出短信信息参与者查勘员/理赔员优先级2前置条件查勘员/理赔员已登录系统后置条件用户只能导出属于自己的短信基本路径1、理赔员/查勘员进行短信信息的查看操作1. 1系统打开短信信息列表1.2导出短信记录1. 21管理员勾选需要导出的短信记录1.22 点击导出信息按钮L23弹出文件选择系统，选择文件保存路径，然后点解确定或者取消1.24 确定，返回L56操作L25取消,返回L51操作1.26文件以浏览器下载方式下载可选操作流程用例名称发送短信管理用例描述发送短信管理，实现发送短信信息的删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行发送短信信息的管理操作1. 1进入发送短信信息列表1.2删除发送短信信息1. 21系统打开发送短信信息列表界面L22管理员选中要删除的发送短信信息，点击“删除”按钮L23弹出删除二次确认框，系统管理员选择确定或者取消L24确定，返回1.36操作L25取消，返回L31操作1.26后台数据库删除成功后显示更新后的发送短信信息给予管理员1. 3查询发送短信信息1. 31系统打开发送短信信息查询界面1.32系统显示所有发送短信信息，管理员选择“查询”可选操作流程用例名称匹配规则管理用例描述匹配规则管理，实现匹配规则信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行匹配规则信息的管理操作1.1进入匹配规则信息列表1.2添加匹配规则信息1. 21系统打开匹配规则信息添加页面1.1 22填写匹配规则基本信息1.23 选择保存或重置1.24 保存，返回1.26操作1.25 重置,返回L22操作1. 26后台数据库添加成功后返回添加查勘/理赔员信息1. 27显示添加成功的查勘/理赔员信息给管理员L3修改匹配规则信息1. 31系统打开匹配规则信息修改界面L32管理员选中具体的匹配规则信息，并双击1.33系统显示当前匹配规则的详细信息1.34系统管理员选择保存或者重置L35保存,返回1.37操作L36重置,返回1.33操作1.37后台数据库修改成功后返回修改匹配规则信息1.38显示修改成功的匹配规则信息给管理员1.4删除匹配规则信息1.41系统打开匹配规则信息列表界面L42管理员选中要删除的匹配规则信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消L44确定,返回1.41操作L45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的匹配规则信息给予管理员1. 5查询匹配规则信息1.5. 1系统打开匹配规则信息查询界面1.6. 2系统显示所有匹配规则信息，管理员选择“查询”可选操作流程第3章系统设计与实现3.1 系统总体架构设计短信收发端24小时不端的扫描指定手机卡收到的短信，并且把短信通过JDBC连接数据库存进数据库。后台管理员使用浏览器进入后台管理端，后台管理端使用SpringBoot作为开发框架，通过MyBatiS框架连接数据库。进入后台管理端首先进入到登录页面，如图3-1,进行登陆后，则进入到主页，可以进行实际的业务操作，主页如图3-2所示。系统的总架构则如图3-3所示：图3-1登录界面东平大平年电制议族图3-2用户管理页面东常太平洋理名推送系统8金Itf按收号码：13794870801。电¥分=种献庭*循完费.亲IH刑产特色力第当前余额，1眼66元如再骅4.1州附内程要u«»尚存均享.>afA=忸户科8三炯广南色A出型X路F过高州山再要州明证何利平代H场井“成化古笈理生教地行已章复业分过快神议是产种责记那次费图3-3角色管理页面ftD306M.24238U0*%41.丫平PU44 J也A-I山广乙 191Y耳比丫山公电 0,#号442*254* Ml 与5«:*IMian工法林 114 4FuFt ml2#FXn-4*4m法58HF=4:r9xWr F20Paf=C544-