计算机科学与技术-车险理赔信息自动收发系统

目录TOC\o"1-3"\h\u31328第1章绪论 1218241.1系统开发的背景及意义 1309801.2国内外研究现状 2161891.2.1国外研究现状 2112531.2.2国内研究现状 2276031.3系统主要研究内容 234801.4系统开发环境与开发工具 327103第2章系统需求分析 479882.1系统的核心业务流程分析 4132862.2系统的整体功能需求分析 5241152.2.1后台管理员主要功能介绍 6212012.3可行性分析 8215902.3.1经济可行性 8173702.3.2操作可行性 88836第3章系统设计与实现 988533.1系统总体架构设计 989933.2功能模块设计 12246923.2.1短信收发端 12266373.2.2后台管理端 13238633.3数据库设计 15147883.3.1表设计 1541443.4系统实现 20102793.4.1短信收发端 20123473.4.2后台管理端 22770第4章系统测试 26309364.1系统测试 26325834.1.1测试的意义 26237644.1.2测试的目的 26142264.1.3软件测试方法 26151904.1.4本系统测试介绍 26270074.1.5测试用例及测试结果 264695第5章结束语 2678785.1全文总结 2616839参考文献： 27第1章绪论1.1系统开发的背景及意义保险，是每个人每个家庭最好的风险对冲工具，经过几十年的发展，人们的保险意识越发提高，参保人数稳定增长，保险，是一个巨大的市场。而其中一种最常见的保险业务，则是车辆保险业务，简称车险。现在全国的汽车保有量已经连续几年保持飞速增长，往后，增长就算放缓，全国的汽车保有量也只增不减，毕竟衣食住行，行，是一个实实在在的刚性需求，在此背景下，汽车的关联业务车险业务，也拥有着巨大的市场与可持续的前景。车险，分为交强险和商业险。其中交强险，由交通部门规定每辆车上路前强制购买，其中包含了车辆的交强险保费，还有车辆的车船税。而商业险，则由商业保险公司自行制定，由车主自主选择是否购买。相比国家规定的交强险，商业险保障的范围更多更细，各大保险公司的针对推出的险种有时会有些区别，但基本大同小异。一般主要险种为：第三者责任险，车损险，盗抢险，玻璃险，自燃险，三方代偿六种。各个险种针对的事故种类不一样，保费价格也有差异，比如第三者就是专门针对交通事故后，对除了车主本人外，对其他人造成的损失进行赔付的险种。而车损险，则是对自己的车造成的损失进行赔付的险种。盗抢险，主要是车被盗后，到公安部门报案，三个月没找到，可以要求进行理赔。玻璃险，即指代车辆在行驶过程中玻璃破碎的一种商业险。自燃险指代汽车在行驶过程中自燃的车险。机动车在路上行驶时，由于各种情况，发生事故的几率是比较高的。因为这一特性，车险业务的理赔率也比其他保险高一些，在这背景下，理赔业务的很多流程急需一些数字化的软件工具来简化流程，从而达到提高效率和节省人力。在车险公司还没使用车险系统的时候，一辆机动车发生事故时，首先要通知保险公司进行报险，然后保险公司要通知查勘员（对车辆碰撞修复进行科学系统的估损定价的专业技术人员），查勘员到达现场后，查勘现场，对被保险车辆的损失情况进行定损，跟事故车车主确定维修地点，最后把信息发给理赔专员，最后由理赔专员向车辆被保人或者汽车维修厂进行保额赔付。在这整个流程中，有一个这样的业务流程：保险公司在接到报险电话后，确定到事故地点，首先要通过一条短信通知事故所在地的分公司，然后分公司通知当地的查勘员到达现场。分公司在通知查勘员后，一般还会通知附近的合作汽车维修点。但这里涉及到一个问题,保险公司给分公司发出报险信息之后，一个分公司覆盖的地方很大，而每个查勘员负责的地方是有划分的，分公司在接到报险中心发来的短信后，首先得进行人工的范围筛选，筛选出对应的查勘员后，再通知相应的查勘员还有附近的汽修厂。这里，要求保险公司分公司24小时有人值班在线，充当一个联络员的角色。本系统就是根据这一业务流程，接受保险公司的委托，定制的一套信息推送系统。在系统上线后，分公司在接收到保险公司的报险中心的信息后，将会由系统进行自动筛选信息，然后再通过短信通知对应的查勘员和附近的汽车维修厂，省去了联络员的人手，还有系统快速的筛选增强了保险公司出险的速度。大大的改进了关于理赔出险这一业务的效率与减低了成本。1.2国内外研究现状1.2.1国外研究现状在国外，无论是保险行业还是软件行业，都有着比国内更加先进的业务流程与技术水平。基于保险业而言，国外的保险业相比国内，参保人数更多，覆盖人群更广，后续的理赔流程更简便，效率更高。这与国外的市场起步时间较早有关。而软件行业就更加不用说了，多年来，国外的数字化程度一直都比国内更高，虽然随着近来来国内互联网市场的大热，国内的软件水平也是突飞猛进，不可同日而语。但在传统行业的数字化方面，无论是普及程度还是项目质量，国内与国外还是有一定的差距。1.2.2国内研究现状国内的软件行业，从上个世纪九十年代开始发展，到现在已有三十年的历史，在早期的二十年，中国的软件水平相比欧美或者日韩一些发达国家，一直处于落后的地位，但随着近十年来互联网市场大热的原因，很多互联网项目表现出了超一流的技术水平与用户体验，在与国外产品对比时也不落下风甚至已经实现了弯道超车。虽然国内在互联网项目取得了如此大的成就，但相比而言，传统行业的数字化建设却显得不是那么成熟。大量的传统行业只是实现了简单的数据管理，很多业务流程并没有真正的接入线上。以保险行业为例，在了解本次项目的业务需求时，我就得知，虽然保险公司总公司的系统非常完善，但是其下辖的分公司，比如本项目的客户东莞某保险公司分公司，在信息分发的时候还是采用最传统的人工分发，24小时值班的分公司查勘中心，在接到总部报案中心发来的出险信息后，通过人工筛选以后通知对应的查勘员到达现场处理。整个过程，不仅人力要求多，而且耗时也比较慢，实在是一种比较落后的做法。通过此例子可得知，在一些传统行业，数字化水平还急需完善和改进。1.3系统主要研究内容车险理赔信息自动收发系统主要研究的内容分为业务上的还有技术上的。在业务上，需要理解整个车险行业的出险查勘流程，理赔信息的发送流程，匹配规则。在技术上，本项目中，分为一个短信收发端，还有一个后台管理端，短信收发端借助一个叫短信猫（GSM-SMMODEM）的第三方硬件设备读取特定几张手机卡收到的短信，通过c3p0连接池连接数据库，把数据存进短信记录表里以等待后台管理端的定时任务调用。后台管理端则采用SpringBoot框架作为项目框架，持久层框架采用MyBatis，前端页面模板使用Thymeleaf,数据库则采用MySQL数据库，通过Redis缓存部分数据。1.4系统开发环境与开发工具本系统开发环境：WINDOWS10操作系统，JDK1.8，IDEA2018.3.5，MYSQL5.6，CENTOS6.5，Redis64.3。采用了以下技术:SpringBoot:Spring是Pivotal团队提供的一个开发框架，里面集成了SpringMVC和Spring框架的所有功能，还内置了web容器，配置简单，上手容易，比起传统的JavaWeb项目省去了大量繁琐的配置，是当前java开发最受欢迎的框架。MyBatis:MyBatis框架是一个基于SQLMAP思想的持久层框架，如官网所说，MyBatis避免了所有在Java代码中编写SQL的情况，而且封装了JDBC代码，通过配置映射SQL与接口还有实体类，大大简化了持久层的编写。而且MyBatis还有一个很大的特点，就是上手容易，学习成本低，而且相比一些ORM框架，运行速度较快，无论从哪点来看都是很优秀的持久层框架。Thymeleaf:Thymeleaf是SpringBoot默认的页面模板引擎，相比JSP，Thymeleaf模板能够直接被浏览器所渲染，不需要经过模板引擎解析器，在开发调式的时候非常方便，在语法方面，Thymeleaf与JSP的差别不大，上手也比较容易。MySQL:MySQL是一个开源的免费的关系型数据库，是目前世界上最流行的关系型数据库之一，相比其他商业型数据库，MySQL虽然可能在某些方面有着自己的一些短板，但是作为一款免费的数据库，从稳定性，运行速度来说，MySQL各项指标都达到了一款商用数据库的标准，所以，对于一些中低成本的软件项目来说,MySQL是最好的选择之一。Redis:Redis是一个高性能的，基于Key-Value的内存缓存数据库，相比与传统的把数据写入硬盘的数据库，内存缓存数据库具有高性能的特点，对于一些读取频繁的数据而已，存在内存缓存数据库能避免频繁的调用IO访问硬盘。提高性能。第2章系统需求分析2.1可行性分析2.1.1经济可行性本系统经过初期的项目评估，定下了一个月的工期，时间方面比较充裕，由两名开发人员参与，加上一个第三方硬件的采购，算上以后的折旧替换，项目成本基本确定，比较符合客户的预期。而系统本身带来的经济效益，首先第一可以替换掉一个24小时值班的信息分发部门，能节省下相当多的人力物力，而且是永久性的。第二，此系统可以带来效率的巨大提升，所以此系统是完全具有经济可行性的。2.1.2操作可行性从操作可行性的角度来说，这系统的开发涉及到的技术都是目前市面上比较成熟的技术，比如SpringBoot作为一个JavaWeb框架，拥有巨量的用户，非常专业的支援团队，成熟的交流社区。其他的如数据库MySQL，持久层框架MyBatis,缓存数据库Redis，都拥有上面的特性，说白了，就是本系统采用的技术栈都非常成熟，在开发中就算遇到问题也能比较容易的解决。而本系统短信收发端中涉及到的另一个硬件短信猫，相比而言则比较小众一点，项目组在初期的方案调用时，第一时间就是研究短信猫硬件的使用，包括这硬件的使用方法，稳定性，接口文档，发现完全能符合此项目的需求。而在业务上，此系统的需求，一个全自动的信息筛选与信息分发系统，也是完全能通过而且客户也迫切希望系统取代传统人手负责的流程，所以无论是技术上，还是业务上，本项目都是具备操作可行性的。2.2系统的核心业务流程分析软件项目开发中，需求分析是非常重要的一个环节。需求分析是一个了解业务流程和客户想法的过程。有充分的需求分析，再经过转化，才能设计出合理的项目结构还有代码流程。在需求分析的时候，首先得把大致的业务流程了解清楚，然后到具体功能的设计，聆听客户的特定想法，最终落实转化为系统模块。本系统的核心业务流程其实就是信息的分发，通过短信收发端收集到的短信，在经过指定的匹配规则后，先把一些不需要的跟本系统无关的短信去掉，剩下的则称为业务短信。然后把业务短信进行进一步的筛选，根据指定的筛选规则筛选出对应的理赔员，然后往理赔员的手机上发送一条短信。图2-1系统核心业务流程图短信记录分两种匹配状态，一种记录是否业务短信，一种记录是否匹配对应理赔员。如果短信两次匹配都为成功，则触发发送短信功能，把发送状态改为发送中，等待发送短信状态回调。发送成功则改为发送成功，发送失败和发送异常的区别在于，发送失败为短信接口返回失败，会在往后重新尝试发送，发送异常则在系统发送短信过程中抛出了异常，则记录为发送异常，不会尝试重新发送的操作。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系统打开用户信息添加页面1.22填写用户基本信息1.23选择保存或重置1.24保存，返回1.26操作1.25重置，返回1.22操作1.26后台数据库添加成功后返回添加用户信息1.27显示添加成功的用户信息给管理员1.3修改用户信息1.31系统打开用户信息修改界面1.32管理员选中具体的员工信息，并双击1.33系统显示当前用户的详细信息1.34系统管理员选择保存或者重置1.35保存，返回1.37操作1.36重置，返回1.33操作1.37后台数据库修改成功后返回修改用户信息1.38显示修改成功的用户信息给管理员1.4删除用户信息1.41系统打开员工信息列表界面1.42管理员选中要删除的员工信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回1.41操作1.45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的员工信息给予管理员1.5查询用户信息1.5.1系统打开员工信息查询界面1.5.2系统显示所有员工信息，管理员选择“查询”1.6角色设置1.6.1系统打开员工信息查询界面1.6.2管理员选中具体的员工信息，并双击1.6.3点击角色设置按钮，弹出角色下拉框，选则角色，点击确定1.6.4后台数据库修改成功后返回用户信息可选操作流程角色设置用例名称角色管理用例描述角色信息管理，实现角色基本信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行角色信息的管理操作1.1进入角色信息列表1.2添加角色信息1.21系统打开角色信息添加页面1.22填写角色基本信息1.23选择保存或重置1.24保存，返回1.26操作1.25重置，返回1.22操作1.26后台数据库添加成功后返回添加角色信息1.27显示添加成功的角色信息给管理员1.3修改角色信息1.31系统打开角色信息修改界面1.32管理员选中具体的角色信息，并双击1.33系统显示当前角色的详细信息1.34系统管理员选择保存或者重置1.35保存，返回1.37操作1.36重置，返回1.33操作1.37后台数据库修改成功后返回修改角色信息1.38显示修改成功的角色信息给管理员1.4删除角色信息1.41系统打开角色信息列表界面1.42管理员选中要删除的角色信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回1.41操作1.45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的角色信息给予管理员1.5查询角色信息1.5.1系统打开角色信息查询界面1.5.2系统显示所有角色信息，管理员选择“查询”1.6权限设置1.6.1系统打开角色信息查询界面1.6.2管理员选中具体的角色信息，点击权限修改按钮1.6.3点击角色设置按钮，所有权限，勾选需要的权限，点击确定1.6.4后台数据库修改成功后返回角色信息可选操作流程权限设置用例名称权限管理用例描述权限信息管理，实现权限基本信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行权限信息的管理操作1.1进入权限信息列表1.2添加权限信息1.21系统打开权限信息添加页面1.22填写权限基本信息1.23选择保存或重置1.24保存，返回1.26操作1.25重置，返回1.22操作1.26后台数据库添加成功后返回添加权限信息1.27显示添加成功的权限信息给管理员1.3修改权限信息1.31系统打开权限信息修改界面1.32管理员选中具体的权限信息，并双击1.33系统显示当前权限的详细信息1.34系统管理员选择保存或者重置1.35保存，返回1.37操作1.36重置，返回1.33操作1.37后台数据库修改成功后返回修改权限信息1.38显示修改成功的权限信息给管理员1.4删除权限信息1.41系统打开权限信息列表界面1.42管理员选中要删除的权限信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回1.41操作1.45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的权限信息给予管理员1.5查询权限信息1.5.1系统打开权限信息查询界面1.5.2系统显示所有权限信息，管理员选择“查询”可选操作流程用例名称查看用户用例描述用户信息查看参与者理赔员/查勘员优先级2前置条件理赔员/查勘员已登录系统后置条件用户只能查看自己的数据基本路径1、理赔员/查勘员进行用户信息的查看操作1.1系统打开用户信息列表可选操作流程业务管理用例描述图2-4车险理赔信息自动收发系统用户业务管理用例图用例名称查勘/理赔员管理用例描述查勘/理赔员管理，实现查勘/理赔员信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行查勘/理赔员信息的管理操作1.1进入查勘/理赔员信息列表1.2添加查勘/理赔员信息1.21系统打开查勘/理赔员信息添加页面1.22填写查勘/理赔员基本信息1.23选择保存或重置1.24保存，返回1.26操作1.25重置，返回1.22操作1.26后台数据库添加成功后返回添加查勘/理赔员信息1.27显示添加成功的查勘/理赔员信息给管理员1.3修改查勘/理赔员信息1.31系统打开查勘/理赔员信息修改界面1.32管理员选中具体的查勘/理赔员信息，并双击1.33系统显示当前查勘/理赔员的详细信息1.34系统管理员选择保存或者重置1.35保存，返回1.37操作1.36重置，返回1.33操作1.37后台数据库修改成功后返回修改查勘/理赔员信息1.38显示修改成功的查勘/理赔员信息给管理员1.4删除查勘/理赔员信息1.41系统打开查勘/理赔员信息列表界面1.42管理员选中要删除的查勘/理赔员信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回1.41操作1.45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的查勘/理赔员信息给予管理员1.5查询查勘/理赔员信息1.5.1系统打开查勘/理赔员信息查询界面1.5.2系统显示所有查勘/理赔员信息，管理员选择“查询”可选操作流程用例名称接收短信管理用例描述接收短信管理，实现接收短信信息的删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行接收短信信息的管理操作1.1进入接收短信信息列表1.2修改接收短信信息1.21系统打开接收短信信息修改界面1.22管理员选中具体的接收短信信息，并双击1.23系统显示当前接收短信的详细信息1.24系统管理员选择保存或者重置1.25保存，返回1.27操作1.26重置，返回1.23操作1.27后台数据库修改成功后返回修改接收短信信息1.28显示修改成功的接收短信信息给管理员1.3删除接收短信信息1.31系统打开接收短信信息列表界面1.32管理员选中要删除的接收短信信息，点击“删除”按钮1.33弹出删除二次确认框，系统管理员选择确定或者取消1.34确定，返回1.36操作1.35取消，返回1.31操作1.36后台数据库删除成功后显示更新后的接收短信信息给予管理员1.4查询接收短信信息1.4.1系统打开接收短信信息查询界面1.4.2系统显示所有接收短信信息，管理员选择“查询”1.5导出短信记录1.51管理员勾选需要导出的短信记录1.52点击导出信息按钮1.53弹出文件选择系统，选择文件保存路径，然后点解确定或者取消1.54确定，返回1.56操作1.55取消，返回1.51操作1.56文件以浏览器下载方式下载可选操作流程用例名称查看已收短信用例描述查看已经接收到的信息参与者查勘员/理赔员优先级2前置条件查勘员/理赔员已登录系统后置条件用户只能看见属于自己的短信基本路径1、理赔员/查勘员进行短信信息的查看操作1.1系统打开短信信息列表可选操作流程用例名称导出信息用例描述导出短信信息参与者查勘员/理赔员优先级2前置条件查勘员/理赔员已登录系统后置条件用户只能导出属于自己的短信基本路径1、理赔员/查勘员进行短信信息的查看操作1.1系统打开短信信息列表1.2导出短信记录1.21管理员勾选需要导出的短信记录1.22点击导出信息按钮1.23弹出文件选择系统，选择文件保存路径，然后点解确定或者取消1.24确定，返回1.56操作1.25取消，返回1.51操作1.26文件以浏览器下载方式下载可选操作流程用例名称发送短信管理用例描述发送短信管理，实现发送短信信息的删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行发送短信信息的管理操作1.1进入发送短信信息列表1.2删除发送短信信息1.21系统打开发送短信信息列表界面1.22管理员选中要删除的发送短信信息，点击“删除”按钮1.23弹出删除二次确认框，系统管理员选择确定或者取消1.24确定，返回1.36操作1.25取消，返回1.31操作1.26后台数据库删除成功后显示更新后的发送短信信息给予管理员1.3查询发送短信信息1.31系统打开发送短信信息查询界面1.32系统显示所有发送短信信息，管理员选择“查询”可选操作流程用例名称匹配规则管理用例描述匹配规则管理，实现匹配规则信息的增删改查参与者管理员优先级2前置条件管理员已登录系统后置条件若有改动必须保存基本路径1、管理员进行匹配规则信息的管理操作1.1进入匹配规则信息列表1.2添加匹配规则信息1.21系统打开匹配规则信息添加页面1.22填写匹配规则基本信息1.23选择保存或重置1.24保存，返回1.26操作1.25重置，返回1.22操作1.26后台数据库添加成功后返回添加查勘/理赔员信息1.27显示添加成功的查勘/理赔员信息给管理员1.3修改匹配规则信息1.31系统打开匹配规则信息修改界面1.32管理员选中具体的匹配规则信息，并双击1.33系统显示当前匹配规则的详细信息1.34系统管理员选择保存或者重置1.35保存，返回1.37操作1.36重置，返回1.33操作1.37后台数据库修改成功后返回修改匹配规则信息1.38显示修改成功的匹配规则信息给管理员1.4删除匹配规则信息1.41系统打开匹配规则信息列表界面1.42管理员选中要删除的匹配规则信息，点击“删除”按钮1.43弹出删除二次确认框，系统管理员选择确定或者取消1.44确定，返回1.41操作1.45取消，返回1.41操作1.46后台数据库删除成功后显示更新后的匹配规则信息给予管理员1.5查询匹配规则信息1.5.1系统打开匹配规则信息查询界面1.5.2系统显示所有匹配规则信息，管理员选择“查询”可选操作流程第3章系统设计与实现3.1系统总体架构设计短信收发端24小时不端的扫描指定手机卡收到的短信，并且把短信通过JDBC连接数据库存进数据库。后台管理员使用浏览器进入后台管理端，后台管理端使用SpringBoot作为开发框架，通过MyBatis框架连接数据库。进入后台管理端首先进入到登录页面，如图3-1，进行登陆后，则进入到主页，可以进行实际的业务操作，主页如图3-2所示。系统的总架构则如图3-3所示:图3-1登录界面图3-2用户管理页面图3-3角色管理页面图3-4接收信息管理页面图3-5权限管理页面图3-6查勘员/理赔员管理页面图3-7系统总体架构图从3-7系统总体架构图可知，本系统采用的也是最经典的三层架构，即Controller-Service-Dao，其中Controller层中文也叫控制层，一般负责页面的转发与业务业务方法的调用与，用接口的形式成为客户端与服务端连接的桥梁。而Service层中文也叫业务层，业务层用来编写所有业务逻辑代码，理论上来讲，真正的三层架构，所有业务代码都应该编写在业务层里，合理的封装成一个个的方法供控制层或其他业务类调用。而最后的Dao层中文则是数据访问层，这是用于与数据库通讯的一层，所有与数据库连接的代码，实际的SQL语句编写，都应该放在这层，这层不关注业务逻辑，只应该单纯的进行一些对数据库的连接与增删改查操作。本系统的Controller层框架使用的是SpringMVC，在SpringBoot项目中，默认的MVC框架就是SringMVC，不需要引入与配置。数据访问层框架则是MyBatis，MyBatis只需要在Maven引入依赖MyBatis的依赖还有JDBC连接驱动则可，如图3-8所示：图3-8MyBatis与JDBC驱动包依赖在导入依赖包后还需要配置MyBatis的SqlSessionFactory，SqlSessionFactory是MyBatis的中央工厂，负责管理所有的连接对象，在MyBatis里叫SqlSession对象。还有一些SQL语句的预创建和预存，还负责记录各种JDBC连接参数，比如最大连接数，初始连接数等参数。SqlSessionFactory里面维护着一个连接池对象，连接池初始化需要连接数据库的四大参数，分别为数据库用户名username,数据库密码password,数据库连接地址url,还有驱动类全名diver-class-name,在SpringBoot的配置当中，直接配置一个连接池，SpringBoot就会自动把则连接池配置给MyBatis,以初始化MyBatis的SqlSessionFactory，MyBatis的基本配置则完全了，如图3-9所示：图3-9MyBatis参数配置MyBatis的核心思想是SQL映射，把SQL以XML格式编写在Mapper文件中，通过文件名自动映射（Dao接口名与Mapper文件名相同），具体的SQL语句则通过Dao层接口中定义的方法名与Mapper中SQL语句的id自动映射。MyBatis也会做自动的ORM映射，把SQL的查询元数据自动封装成对象或对象集合进行返回。3.2功能模块设计本项目分为短信收发端与后台管理端，短信收发端负责数据收集，还有一个发送短信的功能接口。后台管理端则分为系统模块与业务模块，系统模块负责用户，角色，权限管理。业务模块则有短信管理，理赔员管理，匹配规则管理等模块，如图3-10所示：图3-10系统功能模块图3.2.1短信收发端短信收发端只负责两件事，第一是不间断的收集数据。第二是暴露出一个短信发送的接口，在一开始系统架构设计的时候，因为考虑到短信猫对接的特殊要求，还有短信猫的高频率运作，特意独立出一个项目来负责涉及与短信猫对接的所有功能。短信收发端不负责中的功能不直接与用户交互，所以并没有开发UI界面。采用系统控制台来打印监控运行状态，如图3-11所示：图3-11短信收发端运行图1.短信收集：短信收发端24小时检测手机卡中接收到的信息，存进数据库的短信记录表。2.短信发送：调用短信猫中的短信发送功能，传入接收短信的手机号码，短信内容等参数，向指定手机发送短信，做成一个接口让后台管理端调用。3.2.2后台管理端后台管理端负责实际的业务流程操作，分为短信管理，理赔员管理，匹配规则管理，用户管理，权限管理。其中短信管理，理赔员管理和匹配规则管理为实际的业务模块，其他三个用户管理，角色管理，权限管理则为系统模块。还有后台管理端还运行这一个定时器，不断的去扫描数据库中的短信记录表，把初始化的短信扫出来根据一定规则进行匹配操作，如果匹配成功，则调用短信收发端的短信发送功能对指定理赔员进行短信发送，除了定时器的循环匹配自动发送外，后台管理员也能在短信记录模块手动的调用这些匹配功能和短信发送功能。具体的功能如下：1：登录(1)功能描述a.系统用户输入手机号码密码进行登录b.登录后跳转到后台管理端首页，根据角色查找拥有权限，根据拥有权限显 示左侧导航菜单，在每个页面中根据拥有的功能权限显示对应的功能按钮C.用户登录在主页能查看自己的手机号码，还有在本系统拥有的余额，余额 在进行短信发送时，发送成功时结算扣减2:短信记录(1)功能描述a.短信查看:查看所有短信记录，短信记录包括短信内容，接收时间，匹配时 间，发送备注。短信记录在最初收集进数据库时为初始状态，还分别有三个 字段记录数据状态，一个为是否业务短信状态，一个为是否匹配理赔员状态， 一个为短信发送状态，根据各种匹配状态，有各种不同的统计规则b.短信匹配规则设置：在短信匹配规则设置中，能设置匹配规则，用于定时 器判断此短信是否为业务短信，如果是的话，则把是否业务短信状态改为0， 然后进入下一步的理赔员匹配，如若不是，则修改短信的是否业务短信状态 为1，结束流程c.短信发送：手动操作将此短信发送到指定手机号码上，不需要经过任何匹配规则d.重新匹配：手动调用匹配功能，重新的将所有是否业务短信状态为1和所 有是否匹配理赔员状态为1的短信进行一次重新匹配，此功能在新增理赔员 和新增是否业务短信匹配规则时，也会自动触发一次。e.理赔员重新匹配：手动调用匹配功能，重新的将所有业务短信状态为0， 但是否匹配理赔员状态为1的短信进行重新匹配，此功能在新增理赔员的时 候，也会自动触发一次f.发送失败短信重新发送：之前通过两次匹配的短信，在发送短信时如果运 营商回调信息为发送失败，则此短信的发送状态会记录为发送失败，此功能 会自动的将所有发送失败的短信进行一次重新发送。g.发送异常短信重新发送：之前通过两次匹配的短信，在发送短信时如果发 生代码异常，则此短信的发送状态会记录为发送失败，此功能会自动的将所 有发送失败的短信进行一次重新发送3.理赔员管理(1)功能描述a.查看理赔员：查询所有理赔员信息，包括理赔员的手机号码，理赔员姓名， 登记时间，还有关联的理赔员匹配规则，根据理赔员匹配的短信记录还有发 送状态做一个统计b.匹配规则设定：给当前理赔员匹配相应的关键字条件，如果短信记录在第 一次匹配为业务短信时，则会进一步的对理赔员进行匹配，此时调用的就是 理赔员的匹配规则，如果与当前的理赔员匹配成功的话，则会往当前理赔员 的手机号码上发送一条短信，匹配代码如图3-12图3-12匹配功能代码3.3数据库设计本系统采用MySQL作为数据库，MySQL是一个免费的开源的关系型数据库，是市面上最受欢迎的数据库之一，因为其免费而且不俗的性能，一直是所有中小项目数据库的首选。数据引擎则采用INNODB数据引擎，INNODB是事务性数据库的首选引擎，支持行级锁，支持完整的事务特性3.3.1表设计在基本模块设计完毕后，开始着手设计数据表保存一些相关的信息，如短信信息、职位信息、员工信息、面试评价、人才信息等一些数据库，以下是对上述一些主要数据库表的设计：(1)短信记录表（t_business_message）列名数据类型可为空注释idLONGNOTNULL唯一主键IdcontentVARCHAR(1000)NOTNULL内容recive_timeTIMESTAMPNOTNULL接收时间sender_telVARCHAR(50)NOTNULL发送人手机号码is_b_messageINTNOTNULL是否业务短信is_c_messageINTNOTNULL是否匹配理赔员send_statusINTNOTNULL短信发送状态memoVARCHAR(200)NULL备注fail_memoVARCHAR(200)NULL失败备注error_memoVARCHAR(200)NULL异常备注create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态短信记录表记录了短信内容，接收时间，短信发送人手机号码，还有本系统中定自动匹配定时器要使用到的两个状态，一个用于判断是否业务短信，一个用于判断是否已经匹配到理赔员，还有匹配成功后用来记录发送状态的短信发送状态，发送失败和发送异常时用来记录失败原因和异常信息的失败备注，异常备注，还有后台管理员用来备注的备注，和几乎每张数据表都会有的字段：创建时间，修改时间，创建人，修改人，数据状态。(2)理赔员信息表（t_business_claims）列名数据类型可为空注释idLONGNOTNULL唯一主键IDnameVARCHAR(100)NOTNULL理赔员姓名telVARCHAR(50)NOTNULL手机号码memoVARCHAR(200)NULL备注matching_ruleTEXTNULL匹配规则，特殊格式存储create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态理赔员信息记录表记录了理赔员姓名，手机号码，备注，还有匹配规则等字段，其中手机号码是直接用于发送短信的参数，而匹配规则则以特殊的格式存进数据库的一个文本字段中，在需要匹配时，取出匹配规则字段，通过指定方式去把里面的相应条件解析出来，让匹配器进行匹配。（3）匹配规则信息表(t_business_matching_rule)列名数据类型可为空注释idLONGNOTNULL唯一主键IDmatching_ruleTEXTNULL匹配规则create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态匹配规则设定表，用于记录是否业务短信的匹配规则，跟理赔员信息表中的匹配规则一样，此表的匹配规则也是通过特殊的格式存进字段里，在短信进行是否业务短信匹配时，把此表记录的所有匹配规则拿出来，通过特定的方式去解析，然后进行循环匹配，如果有一条匹配规则触发，则该业务短信是业务短信，终止循环。（4）用户信息表（t_system_user）列名数据类型可为空注释idLONGNOTNULL唯一主键IDusernameVARCHAR(50)NOTNULL用户名称passwordVARCHAR(50)NOTNULL用户密码telVARCHAR(50)NOTNULL手机号码emailVARCHAR(100)NULL电子邮箱history_logintimeTIMESTAMPNOTNULL上次登录时间create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态用户信息表，用于记录登录系统的用户。用户名密码作为登录时的凭证，上次登录时间记录用户最后一次登录的时间，默认值为1970-1-100:00:00，在本系统中，时间格式的字段，用1970-1-100:00:00替代空值，避免空值导致查询时索引失效。用户表默认有一个超级用户，拥有所有角色权限。（5）角色信息表(t_system_role)列名数据类型可为空注释idLONGNOTNULL唯一主键IDroleVARCHAR(50)NOTNULL角色名称create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态角色信息表，角色，其实就是权限组，一个角色中会拥有多个权限，通过中间表与权限表进行关联。同时用户表与角色表也通过一张中间表关联，最终通过用户关联的角色获取用户实际拥有的权限（6）权限信息表(t_system_privilege)列名数据类型可为空注释idLONGNOTNULL唯一主键IDfunction_nameVARCHAR(50)NOTNULL功能名menu_nameVARCHAR(50)NOTNULL菜单名create_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态权限信息表，一个用户在操作一个系统时，会有其相应的权限，根据他的权限，在访问某些特定页面或者后台接口时，系统会进行一些拦截，而要实现权限的拦截，需要先把具体的权限记录在权限表，然后通过给与角色关联，最终实现与用户相关联。（7）角色信息与权限信息中间表（t_system_mid_role_privilege）列名数据类型可为空注释idLONGNOTNULL唯一主键IDrole_idLONGNOTNULL角色信息表IDprivilege_idLONGNOTNULL权限信息表IDcreate_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态角色信息与权限信息中间表，用于关联角色和权限信息,角色信息ID与权限信息表ID组成一个UNIQUEKEY（唯一值，表中不允许有超过一条这两个值一样的数据存在）（8）用户信息与角色信息中间表(t_system_mid_user_role)列名数据类型可为空注释idLONGNOTNULL唯一主键IDrole_idLONGNOTNULL角色信息表IDuser_idLONGNOTNULL用户信息表IDcreate_timeTIMESTAMPNOTNULL创建时间update_timeTIMESTAMPNOTNULL修改时间create_userVARCHAR(50)NOTNULL创建人update_userVARCHAR(50)NOTNULL修改人statusINTNOTNULL数据状态用户信息与角色信息中间表，用于关联用户和角色信息，用户信息ID与角色信息ID组成一个UNIQUEKEY。3.4系统实现本系统的架构主要分为两个子系统，一个是短信收发端，一个是后台管理端，负责与第三方硬件短信猫对接，读取短信猫中手机卡收到的信息，通过c3p0连接池连接数据库，把短信信息存入数据库，还有发送信息，开放一个Http协议的接口，让访问者通过调用接口传入相应参数，再调用短信猫的相关API，使用短信猫中的手机卡给指定手机号码发送一条短信。因为短信收发端着重点在于与短信猫的对接，涉及的web开发只有一个功能接口，所以采用普通的javaweb项目。后台管理端则采用SpringBoot作为项目框架，在连接数据库方面则引入持久层框架MyBatis。后台管理端涉及用户模块，角色模块，权限模块等系统模块。同时短信记录信息，理赔员信息，匹配规则信息等业务操作也在后台管理端。用户在后台管理端进行业务和系统操作，所以后台管理端需要一个前台页面让用户操作。本系统采用的页面引擎模板是Thymeleaf，Thymeleaf作为一个H5引擎模板，同时支持静态动态的形式，可无需解析，直接用浏览器预览，相比JSP等一些引擎模板，在提倡前后端分离的今天，更加适合项目的需求。系统的数据库则采用的是MySQL5.6，MySQL是一个免费开源的关系型数据库，因为其免费的特性，一直是众多中小项目的首选数据库。而性能方面，MySQL多年来部署在无数个项目里，经受住了来自不同需求的各种考验，足以是一个稳定的可靠的数据库。3.4.1短信收发端1.环境的搭载连接短信猫等GSM-Modem设备，需要用到一个叫SMSLib的开源库，这个库由Apache基金会负责维护，有.NET和JAVA两个版本，现在最新稳定版为为3.5.4。SMSLib封装了GSM-Modem的操作指令，把一些复杂的指令封装成通俗易懂的SendMessage,ReadMessage方法。除了SMSLib库外，java程序连接短信猫还需要导入一个串口编程库:RXTXcomm，要注意的是，在使用RXTXcomm这个库的时候，需要用RXTXcomm包自带的两个DLL库：rxtxSerial.dll、rxtxParallel.dll替换掉编译JDK目录下JRE目录下bin文件夹里的两个同名文件。2．SMSLib主要API(1)IInboundMessageNotification：短信入站监听接口，需要实现process方法，当GSM-MODEM接到短信时，触发一次这个方法。(2)GatewayStatusNotification：网关状态监听接口，需要实现process方法,当网关状态变更时，触发一次这个方法。比如多手机卡同时运作时，当手机卡切换，会触发此方法一次。(3)SerialModemGateway：主程序，GSM-MODEM的核心工作类，直接GSM-MODEM硬件交互3.开发思路首先编写一个实现IInboundMessageNotification接口的短信接收监听器，绑定短信接收监听器，网关状态监听器则使用默认的，设置参数允许接收信息，设置参数允许发送信息，然后启动主程序。代码如图3-13：图3-13SMSLib驱动GSM-MODEM代码4.C3P0连接池C3P0连接池是一个开源的数据库连接池。程序在需要对接数据库的时候，需要通过建立先建立与数据库的连接对象，再通过连接对象对数据库发出指令（执行SQL语句，调用存储过程等）来操作数据库，等操作完毕后销毁连接对象，在这过程中，建立连接是一个比较耗费性能的过程，如果每次需要访问数据库都重复一上操作，频繁的创建销毁连接，会对系统带来很大的开销。所以，人们一般用连接池来缓存连接对象。在项目启动时就根据配置预初始化一些连接对象，把这些对象存放在一个容器里，等程序需要连接数据时，从容器中取出连接对象，操作完成后把连接对象重新放入到容器中，这样就避免了频繁的创建销毁对象的动作，大大的优化了程序在访问数据库时的性能。本项目中的短信收发端，因为并没有使用到持久层框架，所以自己配置了一个C3P0连接池，用于把接收到的短信信息，存放到短信记录信息表内，配置代码如图3-14：图3-14C3P0连接池配置初始化代码3.4.2后台管理端1.环境搭载后台管理端采用的是SpringBoot框架进行开发，SpringBoot是当今JavaWeb开发最流行的框架之一，里面不仅封装了SpringMVC和Spring框架，还内置了Web容器，配置简单，搭建容易，是所有JavaWeb项目开发的首选框架之一。一个最基本的SpringBoot项目如图3-15：图3-15SpringBoot基础项目结构如图所示，main目录下包含了java和resources两个文件夹，java文件夹用于存放所有的java代码文件，比如SpringBoot的启动类就存放在java文件夹下。而resources文件夹则存放了所有非代码文件资源，比如mapper里存放的是MyBatis框架所要用到的mapper映射文件。static下存放的则是项目的静态资源，如CSS样式和JS脚本，还有字体文件和图片，一般也存放在这个文件夹之下。Templates文件夹则专门用于存放结合模板引擎编写的HTML页面。还有resources目录下的application.yml则是SpringBoot的主配置文件，SpringBoot把所有需要配置的参数都整合到一个文件中，比如以往需要在web容器中配置的端口号，还有Spring配置文件中的连接池，MyBatis配置文件中的mapper路径，都整合到了一个统一的配置文件中，在配置这一点上，相比以前的杂乱臃肿，SpringBoot也有着很大的改进。2．权限拦截在后台管理端中，实现了对访问者的权限拦截，在本系统中，采用SpringBoot的原生拦截器实现这一需求。首先，采用注解配置的形式来注册拦截器，SringBoot中，配置文件统一用@Configuration来注册成一个Bean,通过实现WebMvcConfigurer来配置SpringMVC的参数。配置拦截器代码如图图3-16配置拦截器通过以上配置拦截器，SpringBoot在接收到除了访问登录页面和静态资源的请求时，会在对控制层访问前或后，根据实现的方法，执行注册的拦截器里的代码。实现系统的权限拦截需求。3.异常处理后台管理端在异常处理方面，取用了切面编程手法（AOP），当一个异常最终被抛出到控制层时，我们不应该把异常继续往JVM抛出，而应该在控制层把异常统一处理好，比如把异常信息捕获掉，给调用者返回正确明了的提示，这样也方便后续维护时发生问题时的调试与追查。本系统采用注解的形式配置切面变成，来做一个统一的异常处理。注册一个切面bean用到的注解是@RestControllerAdvice(basePackages="com.lanchongs.motorcycle.controller")，其中basePackages参数配置的是你需要切面类介入的包路径，当当前包下的类，触发到了切面类中配置的切面方法介入时机时，就会执行方法里的代码。现在系统的需求时当发生异常时统一处理掉异常，所以我们编写一个error方法，用@ExceptionHandler注解把此方法标识为当异常被抛出时，则执行该方法，代码如下3-17：图3-17切面方法统一处理异常代码4.日志记录在一个系统中，记录日志是一件非常基本同时又非常重要的事情，生产环境中会发生的意外与状况，是开发时期很难全面预测到的，当问题发生时，我们需要快速的准确的排查出原因，并且迅速解决问题。这时候日志，是我们最重要的参考信息。本系统采用的是LogBack日志组件来记录系统的日志，在SpringBoot中，默认已经整合了LogBack，所以接下来只要配置好配置文件，就可以使用日志组件了。SpringBoot默认会在resources的根目录下，查找一个叫做logback-spring的xml配置文件，一般我们无需对这个配置文件的路径进行更改。配置文件中可以配置日志输出的格式，输出日志文件的路径，还有输出日志文件的级别和日志文件的滚动策略。滚动策略可以根据设置，自动删除一些比较旧的日志，比如设定保留一个月的日志，超过一个月的日志将会被自动删除，这样有助于剩下硬盘的空间，是一个比较实用的功能。本系统滚动策略设置如图3-18：图3-18滚动策略配置第4章系统测试4.1系统测试4.1.1测试的意义系统测试，是一个贯穿整个软件开发周期的重要环节。代码的复杂性决定了测试的重要性，一个没有经过严密科学测试的项目，是几乎不可能做到稳定的。测试一来可以解决一些以往开发中遗留的代码错误，二来项目组可以在