农村社会养老保险管理信息系统的设计与实现.doc

硕士学位论文目 录摘要IABSTRACTII第1章绪论11.1项目背景11.2研究现状11.3系统解决的主要问题21.4本文主要工作21.5本文结构3第2章需求分析42.1系统概述42.2术语表42.3功能性需求52.3.1系统用例52.3.2数据流程62.3.3业务详述72.4非功能性需求92.4.1系统的性能92.4.2系统的可靠性92.4.3易用性9第3章总体设计113.1技术架构113.2网络结构133.3系统功能143.4开发环境15第4章详细设计164.1系统功能设计164.1.1参保164.1.2缴费174.1.3给付开户204.1.4发放234.1.5终保254.1.6退保274.1.7转出294.2数据库设计314.3界面设计33第5章系统实现355.1参保355.2缴费365.3给付开户395.4发放415.5终保435.6退保455.7转出47第6章系统测试506.1黑盒测试506.1.1等价类划分法506.1.2边界值分析法516.1.3错误推测法516.1.4因果图法516.2发现的问题526.2.1程序中的bug526.2.2业务处理方案536.3解决方案536.3.1修改程序536.3.2优化业务处理方案546.3.3更改数据库表设计54第7章结论56参考文献57致谢58学位论文评阅及答辩情况表59ContentsCHINESE ABSTRACTIENGLISH ABSTRACTIIChapter 1 Introduction11.1Background11.2Current Status of the Industry11.3Main Problems of the System Solves21.4Main Content of the Article21.5Structure of the Article3Chapter 2 Demand Analysis42.1Outline42.2Glossary42.3Functional Requirements52.3.1System use case52.3.2Data flow62.3.3Business details72.4Non-functional requirements92.4.1Performance of the system92.4.2Reliability92.4.3Usability9Chapter 3 Overall Design113.1Technical Architecture113.2Network structure133.3System function143.4Development Environment15Chapter 4 Detailed Design164.1Systems Functional Design164.1.1Insured164.1.2Payment174.1.3Account Payments204.1.4Peisions234.1.5Final Paul254.1.6Interrupt Paul274.1.7Roll out294.2Database Design314.3Interface Design33Chapter 5 system implementation355.1Insured355.2Payment365.3Account Payments395.4Peisions415.5Final Paul435.6Interrupt Paul455.7Roll out47Chapter 6 System Testing506.1Black Box Testing506.1.1Equivalence Class Partioning506.1.2Boundary Value Analysis516.1.3Error Reckoning516.1.4Causal Mapping516.2Founded Problems526.2.1Bug In the Problems526.2.2Business Sloved Program536.3Sloved Program536.3.1Modification of Program536.3.2Business Process Optimization Program546.3.3Changing of Database Design54Chapter 7 Conclusion56References57Thanks58Table of Comment on Masters Thesis and Reply Status59iv摘要农村社会养老保险管理信息系统（以下称“农保系统”），是以农村社会养老保险处提出的需求为基础，为建立农村社会养老保险统一的数据库信息平台，实现各级单位之间协同办公和资源共享，优化服务质量，而建设的管理信息系统。农保系统的设计与实现，在深入调研农村社会养老保险业务的基础上，进行需求分析；然后确定技术架构、网络结构，进而抽象出系统功能模块，确定开发环境；又通过详细设计具体论述了涉及的对象，以及数据库内容，并明确了界面布局；接着对于系统实现的几个重点问题进行详细的分析与论述，最后对整个系统进行测试、改进。“农保系统”以电子化、分布式信息资源为基础，以全面实现信息交换的系统化、规范化、自动化，及管理决策的科学化为主要目标，形成了覆盖地市级区域的农村社会养老保险信息网络系统：第一， 实现了农村社会养老保险中的参保、缴费、给付开户、发放、终保、退保、转出等业务功能的信息化管理。第二， 系统的输出，根据农保政策公式化，保证处理的结果正确，以及业务规范统一。第三， 实现了除参保外的每个业务的审核功能，业务经办的内容由业务审核最终确定。第四， 为缴费、给付开户、发放等业务，实现了批量处理的功能。目前，“农保系统”已经在烟台、威海等地市使用，反映效果良好，推进了农村社会养老保险的网络化进程，提高了农村社会养老保险的信息化水平，为农村社会养老保险的业务更优越的服务于大众提供了有力保障。关键词：农村社会养老保险管理信息系统；社会养老保险；管理信息系统ABSTRACTRural social endowment insurance management information system (hereinafter referred to as agricultural insurance system), is based on rural social endowment insurance Department on the basis of the demand for the establishment of a unified rural social endowment insurance database information platform to achieve synergies between all levels of office units and resource sharing, optimize service quality, and construction management information system. Farmers insurance system design and implementation, in-depth study of rural social old-age pension insurance, based on a needs analysis; then determine the technical architecture, network structure, and then abstract out of the system function modules to determine the development environment; also discussed through the detailed design of the specific related to objects, and database content, and a clear layout of the interface; and then for the system implementation of several key issues for detailed analysis and discussion, the final test of the whole system to improve. Agricultural insurance system to electronically distributed information resources as the basis, the full realization of the systematic exchange of information, standardization, automation, and management decision-making more scientific as the main objective of forming a prefecture-level regions of rural social endowment Insurance Information Network System: First, the realization of the rural social endowment insurance of the insured, payment, payment accounts, issuance, the final insurance, surrender, transfer out of business functions such as information management. Second, the systems output, according to farmers insurance policy formulated to ensure the processing result is correct, and business standards harmonization. Third, the addition of the insured outside of the audit function of each business, the business handling the contents of the operational audit finalized. Fourth, for the payment, payment accounts, dissemination of business, achieved a batch processing function. At present, the agricultural insurance system has been in Yantai, Weihai and other cities to use, reflecting the good effect, promoting the rural social endowment insurance network, improve the rural social endowment insurance, the level of information for rural social endowment insurance business superior service to the public provided a strong guarantee.Keyword：Rural social endowment insurance management information system；Social endowment insurance;Management Information System;MIS61第1章 绪论1.1 项目背景农村社会养老保险，是人力资源和社会保障部，根据国务院有关面向农村的政策法规，立足于当今农村实际，为保障农村人口年老后的基本生活，而建立的一项社会化养老保险制度。建立农村社会养老保险制度，是加快建立覆盖城乡居民的社会保障体系的重要组成部分，对妥善解决农民的养老问题，统筹城乡经济社会一体化发展，实现和谐社会，具有重要意义。此外，它从根本上解决了中国历史上“养儿防老”的长久传统，彻底解决了广大农民养老的后顾之忧，对于计划生育的开展，也起到积极作用。在我国，有63.78%的人口分布在农村，人口众多，而且文化程度良莠不齐，农村社会养老保险工作管理相当复杂，当前广泛使用的单机部署的管理信息系统即无法保证业务的大批量开展，也无法保证业务规范统一执行，更不能保证业务数据的共享。“农村社会养老保险管理信息系统的设计与实现”，以解决上述问题为根本出发点，严格按照人力资源和社会保障部有关信息标准规范，科学合理地设计业务流程和数据指标体系，利用当前先进的信息化技术，实现业务系统规范化、自动化、网络化，以及“数据向上集中、服务向下延伸”的信息理念，最大程度的满足了农村社会养老保险业务：数据广泛采集、业务集中办理、信息多渠道查询。1.2 研究现状根据当前对农保相关系统的使用情况的了解，现状如下：1、 武汉天喻公司已经开始对类似系统的研究，在系统构建上采用了J2EE架构平台，利用网络保证整个系统的顺畅性和联通性。2、 芯软科技研制开发了类似系统，系统采用B/S、C/S 相结合的架构，实现参保人员开户、缴费、发放、销户整个业务流程的信息化管理。3、 山东省的大多地市，农保部门使用的管理信息系统大多采用单机部署模式，各业务端数据无法共享，相互之间数据交流，只是以报盘的方式。由于独立办公、各自为政，无法保证采用统一的业务规范。4、 目前，国家部委正在组织人力，研究开发统一的农保系统实现方案，并将最新的技术应用到系统实现中去。1.3 系统解决的主要问题针对目前农保业务相关系统存在的诸多问题，以及随着农保业务的逐步开展带来的对系统的诸多要求，农保系统着眼于解决以下问题：1、 数据权限的划分。当前系统大多是针对区县级业务员的单机运行模式，没有过多考虑数据权限的划分，每个业务员无论实际级别高低，处理的数据范围都是相同的。2、 业务审核功能。由于系统中没有划分用户的级别，每个系统用户都能有业务审核的权限，不利于保证业务正常有序开展。3、 系统功能可扩展。由于目前系统建设时间久远，系统可扩展性与现实农保业务的距离相差较大，不能跟上农保业务发展的需要。4、 业务批量办理。由于系统建设时期，农保业务量少，从需求上说，不需要批量办理的功能，但随着农保业务的不断推广，业务批量办理功能势在必行。1.4 本文主要工作“农保系统”以电子化、分布式信息资源为基础，以全面实现信息交换的系统化、规范化、自动化，及管理决策的科学化为主要目标，形成了覆盖地市级区域的农村社会养老保险信息网络系统：第一， 实现了农村社会养老保险中的参保、缴费、给付开户、发放、终保、退保、转出等业务功能的信息化管理。第二， 系统的输出，根据农保政策公式化，保证处理的结果正确，以及业务规范统一。第三， 实现了除参保外的每个业务的审核功能，业务经办的内容由业务审核最终确定。第四， 为缴费、给付开户、发放等业务，实现了批量处理的功能。 “农保系统”的设计与实现，立足于当前农保日常业务，着眼于农保日常业务未来的发展，严格按照人力资源和社会保障部有关信息标准规范，利用当前先进的信息化技术，实现业务系统的规范化、自动化、网络化，以及“数据向上集中、服务向下延伸”的信息理念，为优化农村社会养老保险服务质量提供了有力保障。1.5 本文结构全文分为七章。第1章是绪论，主要介绍了项目背景，以及当前相关信息系统的现状，说明了系统需要解决的问题和本文的主要工作。第2章是需求分析，从用户日常业务出发，抽取出系统的用例，然后以用例为对象，对系统的功能性需求进行详述。第3章是总体设计，阐述了系统的总体架构、网络结构、逻辑结构，以及对系统的模块化设计。第4章是详细设计，在总体设计的基础上，确定各个具体任务，选择适当的处理方法，为系统的实现奠定良好的基础。第5章是系统实现，根据详细设计的结果，阐述了实现系统主要功能的关键代码。第6章是系统测试，阐述了测试的方法，并列出系统主要功能的测试用例，同时还描述了在测试过程中发现的问题和及其解决方案。第7章是结论，总结了本文的成果，使用效果，以及主要工作等。第2章 需求分析需求分析是软件生命周期的一个重要阶段，它最根本的任务是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。具体的说，应该确定系统必须具有的功能和性能，并且预测系统发展的前景；必须仔细分析系统中的数据，既要分析系统中的数据流，以要分析长期使用的数据存储。需求分析的结果是系统开发的基础，关系到工程的成败和软件产品的质量。2.1 系统概述农村社会养老保险，实行“个人缴费、集体补助、政府补贴相结合”的筹资结构，社会统筹与个人账户相结合的制度，基础养老金和个人账户养老金相结合的待遇方式。系统在总体设计上，充分满足上述要求，并提供良好的稳定性、扩展性和可维护性。在业务处理上，合理规划参保、缴费、发放、终保、退保、转出等一系列业务的办理流程，做到操作简便、通俗易懂；同时提供批量处理的功能，以及在此基础上提供完善的数据接口和丰富的查询统计功能。2.2 术语表表2-1 术语表类别术语含义备注业务功能参保农民到当地农保部门申请参加农村社会养老保险，并登记本人的基本档案信息。缴费按当地农保部门规定，参保人员定期向农保部门缴纳费用。给付开户参保人员符合当地农村社会养老保险的养老金发放条件后，向所属农保部门提出申请，由农保部门核定参保人员相关的养老金发放信息。养老金发放按照领取开户确定的养老金发放信息，定期（每月或每季度）向参保人员拨付养老金。转出参保人员因户籍变动，改变所属农保单位。退保参保人员在未被所属部门核定养老金发放信息前，主动退出农村社会养老保险。终保参保人员在被所属部门核定养老金发放信息后，退出农村社会养老保险。业务名词集体与行政村同级的行政单位。机构与区县同级的行政单位。保证期保证参保人员至少能够的月数。保险状态分为：缴费、发放、终保、退保，用于标识参保人员当前的业务状态，能够决定参保人员对应的业务范围。批次同一个业务员对同一个集体录入的缴费明细，在未提交审核前，都属于同一个批次。发放标准参保人员每个月应该领取的养老金核算计算指定时间段内，每个人能够领取的养老保险金。2.3 功能性需求2.3.1 系统用例图2-1 农村社会养老保险管理信息系统用例图农村社会养老保险管理信息系统，涉及的主要功能主要有：参保、缴费、给付开户、发放、终保、退保、转出，按功能角色划分，用户可以分为：乡镇级业务员、区县级业务员、审核业务员。2.3.2 数据流程图2-2 农村社会养老保险业务数据流程图农村社会养老保险业务数据流程：1、 参保，根据申报的原始个人信息，生成档案信息。2、 缴费，在档案信息的基础上，根据申报的缴费明细，生成缴费信息。3、 给付开户，根据申报的开户人员名单，在已存在缴费信息的基础上，生成发放标准。4、 发放，根据指定的发放时间段，在已存在发放标准的基础上，生成发放信息。5、 终保，根据申报的终保人员名单，参照发放信息和缴费信息，生成终保信息。6、 转出，根据转出申请，在已存在档案信息的基础上，生成转出信息，并修改档案信息。7、 退保，根据退保申请，参照缴费信息，生成退保信息。2.3.3 业务详述业务详述是对各用例做具体描述，更加详细的展现用例的真实面貌。通过用例规格说明，具体描述出各用例：参保，是指农民到当地农保部门申请参加农村社会养老保险，并登记本人的基本档案信息。表2-2 参保用例规格说明用例参保执行者区县级业务员、乡镇级业务员先决条件符合参保条件（年龄、户口所在地）的人员参保。事件流录入参保人员的档案信息。后置条件参保人员的基本情况保存到档案信息中，保险状态为“缴费”。缴费，是指按当地农保部门规定，参保人员定期向农保部门缴纳费用。表2-3 缴费用例规格说明用例缴费执行者审核业务员、区县级业务员、乡镇级业务员先决条件1、 参保人员申报缴费；2、 参保人员的保险状态为“缴费”。事件流1、 乡镇级业务员或区县级业务员，将对应参保人员的缴费明细保存成临时缴费明细；2、 乡镇级业务员或区县级业务员，将自己录入的缴费明细，做提交审核；3、 审核业务员，对已提交审核的缴费明细，做缴费审核。后置条件缴费明细存在对应参保人员的缴费账户中。给付开户，是指参保人员符合当地农村社会养老保险的养老金发放条件后，向所属农保部门提出申请，由农保部门核定参保人员相关的养老金发放信息。表2-4 给付开户用例规格说明用例给付开户执行者区县级业务员、审核业务员先决条件1、 参保人员的保险状态为“缴费”；2、 参保人员存在缴费信息。事件流1、 区县级业务员，确定给付开户的人员范围；2、 系统查询出相关人员给付开户必要条件：出生日期、缴费积累总额等；3、 系统计算出起领年月、发放标准；4、 区县级业务员，认定上述内容无误后，保存；5、 审核业务员，对操作的给付开户的人员做审核确认。后置条件参保人员的起领年月保存到档案信息中，发放标准保存到发放标准信息中，保险状态为“发放”。养老金发放，是指按照领取开户确定的养老金发放信息，定期（每月或每季度）向参保人员拨付养老金。表2-5 发放用例规格说明用例发放执行者区县级业务员、审核业务员先决条件1、 已存在参保人员的发放标准；2、 已明确发放的截至年月。事件流1、 区县级业务员，确定发放的人员范围；2、 系统根据相关人员起领年月、已发放至年月，确定本次发放起始年月；3、 系统根据本次发放的起始年月、即定发放标准，计算出本次发放明细；4、 区县级业务员，认定上述内容无误后，保存；5、 审核业务员，对操作的发放内容做审核确认。后置条件参保人员的发放明细保存到发放信息中。终保，是指参保人员在被所属部门核定养老金发放信息后，退出农村社会养老保险。表2-6 终保用例规格说明用例终保执行者区县级业务员、审核业务员先决条件1、 参保人员的保险状态是“发放”。事件流1、 区县级业务员，确定终保人员，及其终保日期；2、 系统根据终保人员的终保日期，参照缴费信息和发放信息，计算出返还金额；3、 区县级业务员，认定上述内容无误后，保存；4、 审核业务员，对操作的终保的信息做审核确认。后置条件参保人员的终保信息保存到终保信息中，保险状态为“终保”。退保，是指参保人员在未被所属部门核定养老金发放信息前，主动退出农村社会养老保险。表2-7 退保用例规格说明用例退保执行者区县级业务员、审核业务员先决条件1、 参保人员的保险状态是“缴费”。事件流1、 区县级业务员，确定退保人员，及其退保日期；2、 系统根据退保人员的退保日期，参照缴费信息，计算出返还金额；3、 区县级业务员，认定上述内容无误后，保存；4、 审核业务员，对操作的退保的信息做审核确认。后置条件参保人员的退保信息保存到退保信息中，保险状态为“退保”。转出，是指参保人员因户籍变动，改变所属农保单位。表2-8 转出用例规格说明用例转出执行者区县级业务员、审核业务员先决条件1、 参保人员保险状态为“缴费”。事件流1、 区县级业务员，确定转出人员，及其新隶属单位；2、 审核业务员，对转出信息做审核确认。后置条件参保人员的新的隶属单位更新到档案信息中。2.4 非功能性需求非功能性需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性,一般包括系统的性能、可靠性、可维护性、可扩充性和对技术及业务的适应性等方面的需求。软件产品非功能性定义不仅决定产品的质量,还在很大程度上影响产品的功能需求定义。在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于对非功能性需求的分析。2.4.1 系统的性能表2-9 系统性能指标要求指标要求事务响应时间在业务高峰期，页面请求的每个事务，根据数据量大小，处理时间不能多于0.53秒。吞吐量每秒能够处理的事务数不能少于50个。容量能够容纳200个用户同时办理业务，并保证数据权限和功能权限的正确。客户端对系统用户来说，在网络范围内，不能因客户端的变化，而产生数据权限、功能权限的变化。系统故障率造成业务停滞性故障的发生频率平均不能高于1次/季度，不能出现不可修复性故障。2.4.2 系统的可靠性1、 当系统出现故障时，要给以明确提示，禁止继续操作，并支持恢复。2、 当用户在使用过程中遇到错误的时候，要通过明确的提示或日志形式，立即定位问题。3、 当网络不稳定或使用中异常中断的情况下，系统要有相应的容错措施。2.4.3 易用性1、 易见，各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作。2、 易学，用户能够通过在线帮助，导航，向导等各种方式，自已学习掌握系统的逻辑处理方式。3、 易用，使用户在熟练使用软件后，可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，去细分场景和用户。第3章 总体设计总体设计阶段的基本目的，是用比较抽象概括的方式确定系统如何完成预定的任务，也就是说，应该确定系统的物理配置方案，并且进而确定组成系统的每个程序的结构。首先，从系统基本需求和系统发展的前景出发，结合当前先进的技术，确定合理的技术架构；其次，根据用户实际的硬件条件，以及业务的办理模式，确定网络结构；然后，进行系统功能设计，确定系统由哪些模块组成以及这些模块之间的动态调用关系；最后，确定开发语言，以及开发工具。3.1 技术架构实现农村社会养老保险管理信息系统，技术架构采用基于MVC设计模式的Struts框架，自下而上被分为数据层、持久化层、业务处理层、请求处理层、表现层。图3-1 技术架构图表现层实现客户需求的交互方式；请求处理层在表现层和业务处理层之间起适配作用；业务处理层实现具体的业务操作；持久化层为系统中的实体提供持久化服务。系统各层调用关系如下：1、 在表现层，JSP文件被执行形成HTML页面，显示在客户端浏览器，与用户进行交互，将请求提交到请求处理层对应的用例Action2、 在请求处理层，用例Action继承org.apache.struts.action，通过Delegator调用业务服务工厂BusinessServiceFactory，在业务服务工厂里，通过ServiceCache调用org.apache.log4j.Logger记录业务日志，调用ServiceContent取得农保用例接口提供的业务服务实例。请求处理层得到业务处理层返回的数据后，通过调用org.apache.struts.action.ActionMapping取得对应的JSP文件后，显示在客户端浏览器。3、 在业务处理层，农保用例POJO，实现农保用例接口，通过元类BpoProxy调用农保用例BPO，引发对业务的处理。采用元类BpoProxy调用，是为对调用的具体对象和方法加一层处理。农保用例BPO负责在持久化层的基础上，组织主要的业务逻辑处理，通过持久化层的OPManager和Sql实现与数据层的交互。4、 在持久化层，定义了接口BusinessService，以及核心公共类。TransManager调用HibernateSession，用来控制事务的处理；OPManager调用HibernateSession，实现调用业务实体；sql调用java.sql.PreparedStatement，做为另外一条与数据库交互的途径；Exception继承java.lang.Throwable，处理系统应用中产生的异常。5、 在数据层，采用关系数据库。3.2 网络结构图3-2 网络结构分布图农保系统在地市级信息中心部署，建立中心数据库服务器和应用服务器。地市级客户端和区县级客户端，利用Internet构建的业务专网与中心应用服务器连接，实现系统网络化。各客户端在办理业务时，与中心数据库实时连通，业务数据在中心数据库实时更新。客户端在权限范围内，可以访问任一客户端产生的业务数据，保证了农保业务数据的实时共享，从而实现了“数据向上集中、服务向下延伸”的信息理念。数据库服务器和应用服务器统一部署，由系统管理员统一协调、控制业务参数、业务流程，实现了农保系统规范化。3.3 系统功能图3-3 功能架构图系统在遵守相关标准与规范的基础上，引用Struts框架的功能实现核心引擎部分，保证持久化层的正常运行。在核心引擎的基础上，首先实现系统公共组件，保证统计报表、功能权限等功能的正常运行。在系统公共组件的基础上，根据功能性需求，实现参保、缴费、给付开户、发放等业务功能。功能权限的分配，采用系统页面是否显示的方式确定，把它做为一种特殊的业务请求来实现。在用户登录系统后首先根据用户ID查询可视的页面范围，然后重新布置系统的页面，从而实现功能权限的划分。统计报表，通过基于调用Microsoft Office Excel 2003的相关组件，对传入的数据集重新组装来实现。3.4 开发环境1、 开发语言：前台：JSP后台：JAVA数据库：oracle10g2、 开发工具：程序开发：eclipse数据库操作：PLSQL Developer应用服务器：Tomcat第4章 详细设计详细设计阶段，就是为每个模块完成的功能进行具体的描述，把功能描述转变为精确的、结构化的过程描述。除了应该保证程序的可靠性之外，使将来编写出的程序可读性好，容易理解，容易测试和容易修改、维护，是详细设计阶段的最重要目标。4.1 系统功能设计4.1.1 参保参保用例，界面设计如下：表4-1 参保用例界面设计界面名称新增人员界面元素乡镇、集体、个人编号、参保人姓名、身份证号码、出生日期、参保日期、个人身份、民族、性别、联系方式、户口所在地、住址、备注。界面输入输入上述内容；审核。界面响应将录入的信息保存到人员信息，并给操作成功的提示。参保用例涉及的对象，及相互关系如下图所示：图4-1 参保用例核心对象及关系PersonAction调用接口类PersonBS，实现对业务逻辑的调用；PersonBSImp实现接口类PersonBS，并调用AddPersonBPO，进行业务处理；AddPersonBPO包含对参保用例业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类AddPersonBPO，用于实现录入参保人员档案信息的相关功能，提供的方法：取个人编号（getGrbh()）、保存参保人员信息（savePayTmp()）。图4-2 取得个人编号PAD图4.1.2 缴费将缴费用例的实现分为三个部分：缴费录入、提交审核、缴费审核，在系统中表现为三个页面，界面设计如下：表4-2 缴费用例界面设计界面名称缴费录入提交审核缴费审核界面元素查询条件乡镇、集体、个人编号乡镇、集体、缴费日期缴费批次编号查询结果个人编号、姓名缴费日期、缴费总人数、总钱数缴费批次信息操作查询、保存选中行查询、提交审核查询、审核界面输入参照查询结果，录入缴费明细信息；保存录入信息的选中行。选中需要提交审核的数据；提交审核。选中需要审核的缴费批次；审核。界面响应把录入的缴费明细，保存到临时缴费明细表，并显示出成功保存的缴费明细。把选中的缴费明细，做提交审核，并显示出缴费批次编号。对选中的缴费明细，做审核，并给出操作成功的提示。缴费用例涉及的对象，及相互关系如下图所示：图4-3 缴费用例核心对象及关系ReceiveAction调用接口类ReceiveBS，实现对业务逻辑的调用；ReceiveBSImp实现接口类ReceiveBS，并调用ReceiveBPO、SubmmitBPO、AuditReceiveBPO，进行业务处理；ReceiveBPO、SubmmitBPO、AuditReceiveBPO包含对缴费用例的业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类ReceiveBPO，用于实现缴费录入的相关功能，提供的方法：保存缴费明细（savePayTmp()）。图4-4 保存缴费明细PAD图业务类SubmmitBPO，用于实现提交审核相关的系统功能，提供的方法：根据条件取得具有相同缴费批次特征的缴费明细（getPayTmpForBatch()）、生成缴费批次（savePayBatch()）。图4-5 生成缴费批次PAD图业务类AuditReceiveBPO，用于实现缴费审核相关的系统功能，提供的方法：取得缴费批次信息（getPayBatch()）、审核缴费批次（payAudit()）。图4-6 审核缴费批次PAD图4.1.3 给付开户将给付开户用例的实现分为两个部分：批量给付开户、给付开户审核，在系统中表现为两个页面，界面设计如下：表4-3 给付开户用例界面设计界面名称批量给付开户给付开户审核界面元素查询条件乡镇、集体、起始出生年月、截止出生年月乡镇、集体、个人编号查询结果个人编号、姓名、出生日期单据流水号、个人编号、姓名、单据状态、发放金额、开户日期操作查询、批量开户查询、审核确认界面输入参照查询结果，批量选中给付开户的人员；批量开户选中行。参照查询结果，批量选中审核的给付开户人员；审核确认。界面响应对选中人员做给付开户，并给出操作成功的提示。对选中给付开户内容，做审核确认，并给出操作成功的提示。给付开户用例涉及的对象，及相互关系如下图所示：图4-7 给付开户用例核心对象及关系GiveNoticeAction调用接口类GiveNoticeBS，实现对业务逻辑的调用；GiveNoticeBSImp实现接口类GiveNoticeBS，并调用GiveNoticeBPO、GiveNoticeAuditBPO，进行业务处理；GiveNoticeBPO、GiveNoticeAuditBPO包含对给付开户用例的业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类GiveNoticeBPO，用于实现办理给付开户的相关功能，提供的方法：查询符合给付开户条件的参保人员（getInfoForGiveNotice()）、保存给付开户信息（saveGiveNotice ()）。图4-8 保存给付开户信息PAD图业务类GiveNoticeAuditBPO，用于实现审核办理的给付开户信息的相关功能，提供的方法：查询需要审核的给付开户的信息（queryGiveNotice()）、审核给付开户信息（auditGiveNotice()）。图4-9 审核给付开户信息PAD图4.1.4 发放将发放用例的实现分为两个部分：发放、发放审核，在系统中表现为两个页面，界面设计如下：表4-4 发放用例界面设计界面名称发放发放审核界面元素查询条件乡镇乡镇、集体、起始核算年月、截止核算年月查询结果乡镇、发放至年月、上次发放经办日期乡镇、集体、发放年月、发放经办日期、发放总数操作查询、发放查询、审核确认界面输入参照查询结果，输入发放至年月，批量选中发放的乡镇；发放选中行。参照查询结果，批量选中审核的发放内容；审核确认。界面响应对选中乡镇，按照发放至年月做发放，并给出操作成功的提示。对选中发放内容，做审核确认，并给出操作成功的提示。发放用例涉及的对象，及相互关系如下图所示：图4-10 发放用例核心对象及关系GiveAction调用接口类GiveBS，实现对业务逻辑的调用；GiveBSImp实现接口类GiveBS，并调用GiveBPO、GiveAuditBPO，进行业务处理；GiveBPO、GiveAuditBPO包含对发放用例的业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类GiveBPO，用于实现办理发放的相关功能，提供的方法：查询符合发放条件的乡镇（queryXzxxForGive ()）、保存发放信息（saveGive ()）。图4-11 保存发放信息PAD图业务类GiveAuditBPO，用于实现审核办理的发放信息的相关功能，提供的方法：查询需要审核的发放的信息（queryGiveForAudit()）、审核发放信息（giveAudit ()）。图4-12 发放审核PAD图4.1.5 终保将终保用例的实现分为两个部分：终保、终保审核，在系统中表现为两个页面，界面设计如下：表4-5 终保用例界面设计界面名称终保终保审核界面元素查询条件基金领取方式、一次性返还金额、终保日期乡镇、集体、起始办理日期、截止办理日期、个人编号、终保单号查询结果单据流水号、基金领取方式、返还金额、终保日期、单据状态操作查询、保存终保单据查询、审核确认界面输入录入终保相关信息；保存终保单据。参照查询结果，批量选中审核的终保内容；审核确认。界面响应保存录入的终保内容，并给出操作成功的提示。对选中终保内容，做审核确认，并给出操作成功的提示。终保用例涉及的对象，及相互关系如下图所示：图4-13 终保用例核心对象及关系PersonStopAction调用接口类PersonStopBS，实现对业务逻辑的调用；PersonStopBSImp实现接口类PersonStopBS，并调用PersonStopBPO、PersonStopAuditBPO，进行业务处理；PersonStopBPO、PersonStopAuditBPO包含对终保用例的业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类PersonStopBPO，用于实现办理终保的相关功能，提供的方法：查询需要终保的人员（queryForPersonStop()）、保存终保信息（saveStopBill()）。图4-14 保存终保信息PAD图业务类PersonStopAuditBPO，用于实现审核办理的终保信息的相关功能，提供的方法：查询需要审核的终保信息（queryForAuditStop()）、审核终保信息（auditStopBill ()）。图4-15 终保审核PAD图4.1.6 退保将退保用例的实现分为两个部分：退保、退保审核，在系统中表现为两个页面，界面设计如下：表4-6 退保用例界面设计界面名称退保退保审核界面元素查询条件缴费积累本、息；退保金额、退保日期、退保原因乡镇、集体、个人编号查询结果乡镇名称、集体名称、退还金额操作保存退保单据查询、审核确认界面输入录入退保相关信息；保存退保单据。参照查询结果，批量选中审核的退保内容；审核确认。界面响应保存录入的退保内容，并给出操作成功的提示。对选中退保内容，做审核确认，并给出操作成功的提示。退保用例涉及的对象，及相互关系如下图所示：图4-16 退保用例核心对象及关系ReturnBillAction调用接口类ReturnBillBS，实现对业务逻辑的调用；ReturnBillBSImp实现接口类ReturnBillBS，并调用ReturnBillBPO、ReturnBillAuditBPO，进行业务处理；ReturnBillBPO、ReturnBillAuditBPO包含对退保用例的业务处理逻辑，通过调用OPManager、Sql类，操作实体类，完成与数据库的交互。业务类ReturnBillBPO，用于实现办理退保的相关功能，提供的方法：查询需要退保的人员（queryForReturnBi