ppppp
套话
2017年7月我参与了xxx保险公司财产险承保核心系统的设计和开发，担任系统分析师。该项目核心团队30多人，历经1年3个月于2018年10月成功上线。该项目结合了大数据和云计算并采用工作流引擎技术实现了保险承保全业务自动化流程和核保的智能风险控制管理，减轻了保险业务人员的工作，为公司减少了业务运行成本，同时也满足了用户对快速，高效，智能保险产品的需求，极大提升了用户满意度。本文结合作者的项目实际经验对软件开发法中结构化和面向对象还有原型法进行了论述，具体通过保单管理快中结合面向对象的开发方法进行详细的论述。
随着互联网技术的不断发展，保险公司市场的竞争越来越激烈，客户对于保险产品的多样性的需求与日俱增，公司原来的财产险承保系统已经满足不了市场快速迭代产品的需求。经过公司高层的一致分析和研究，需要开发一套满足公司今后运行要求的新一代承保核心系统。2017年7月我参与了xxx保险公司财产险承保核心系统的设计和开发并担任了系统分析师，该项目核心团队30多人，总共历时1年3个月于2018年10月成功上线。该项目结合了大数据和云计算并采用了工作流引擎技术实现了保险承保全业务自动化流程和核保的智能风险控制管理，减轻了保险公司业务人员的工作，建设了公司对财产险业务运营的成本，同时也满足了用户对快速，高效，智能的保险产品需求，极大的提高了用户的满意程度，为公司带了巨大的有形和无形价值。该系统主要分为4个核心模块，分别是险种的产品工厂模块，承保模块，保单的管理模块，智能核保模块。产品工厂模块主要功能是通过该模块系统的业务配置人员可以快速的配置新的保险产品，上线新的保险产品不用系统开发人员进行参与，极大的缩短了发布新产品的周期，为快速获得用户市场提供了技术支持。
承保模块，通过该模块可以进行新契约的创建，保单批改的创建，保单快速的保费计算，保单的智能核保，保单生成和打印还有保费的收取，该模块采用了activiti工作流引擎技术实现了保单全流程的自动化处理，减少了业务人员的工作量和提升了保险过程的精准度。
保单管理模块，通过该模块业务人员可以对保单对象进行修改申请和批准，比如对保单的基本信息投保人和被保人的信息进行修改，对保费和保单责任进行修改申请。
智能核保模块，该模块结合阿里云提供的大数据和云计算服务，通过规则系统，可以高效，准确，和智能的对保单的核保进行指派和通过和拒绝，极大的提高了保单的风险管理控制，为实现全流程的自动化提供了基础。
为了更高质量的设计和实现承保系统，在系统分析阶段我们采用了面向对象的方法对项目进行开发，下面我将具体论述在保单管理的实际工作过程中的运用。
软件开方法主要分为，结构化开发方法，原型化开发方法，和面向对象开发方法。结构化开发方法就是自定向下，逐层分解，对软件的设计和开发从上至下一层一层逐步的去实现软件的开发，每一个阶段的产物都作为下一个阶段的输入，每一层都有具体严格的要求和方法论。优点是对于需求确定的项目可以高质量的对项目进行开发和管控，缺点是对于需求不确定的项目后期需求的变更对前期有重大的影响，严重的影响项目的开发进度。
原型法的特点就是特别适用于需求不确定的项目，在需求模糊的情况下，首先通过原型法快速构造一个界面和功能的原型通过用户的不断反馈，持续的进行迭代，直至软件开发完成，最终满足用户的要求，缺点就是没有具体的方法论和严格的流程控制，项目开发过程中如果没有改方法的实践经验容易将项目推至一个混沌的不可控的状态，有着极大风险。
面向对象的开发方法就是通过客观世界去描述软件具体的模块功能和属性，通过该设计，开发人员可以快速的理解软件的功能，需求参与方也可以即使不了解技术也可以对设计进行讨论，方便了软件设计和开发过程中的沟通，减少了需求的误差，同时开发完成后也有较高的复用性。
在系统分析阶段保单管理模块我们就采用了面向对象开发方法。分为具体一下几个步骤，识别和定义对象，在保单管理模块定义出一些重要的对象如，投保人，被保人，保费，保险责任，保额等信息，
将对象定义为类，类是一组具有相同属性和方法的对象的集合，在保单管理系统中保单和投保险人具有不同的属性和方法就可以被定义为policy和policyholder。
定义类的属性和方法，在保单管理系统中policy中的属性有保额信息，保费信息，责任信息等等，policyholder中有姓名住址等等信息，
定义类之间的关系，类之前的关系十分重要包括，关联，继承，和组合和聚合，在保单管理系统中policy和policyholder的关系就是关联，policy和risk的关系就是组合。
定义类的行为方法和规则，为类定义方法和规则是为了定义和描述和规范类的行为，比如policy中定义了保费计算的方法，和详细保费计算的规则。
通过面向对象的方法分析更好的可以获取业务人员的需求，和方法开发人员的开发。对功能的模块的扩展性和可维护性有着巨大的提升。为高质量开发系统提供了基础
结尾：
经过核心团队30多人和关联多个部门和外部供应商的配合，该承保核心系统于2018年10月项目成功上线，该项目运行至今一直运行稳定。该项目减轻了承保业务人员的工作量，满足了用户对于个性化的保险产品的需求，减少了公司的运营成本，为业务扩大营收提供了技术支持。得到了公司领导和业务部门一直的好评，极大提高了用户的满意度。当然在项目建设过程中也遇到了不少困难，比如项目资源紧张，项目工期有逾期风险，项目对于新技术落地有技术风险等等问题，通过我们的一系列的努力和领导资源的调度都得到了及时的解决。我们在软件设计过程中比较重视软件开发方法的选择，通过理论结合项目的实际情况取得了显著的成果，为项目的能按时和高质量的开发做了巨大的帮助。在项目建设过程中当然也有遇到一下映像比较深的问题和思考，比如在需求分析阶段，由于刚开始业务人员对需求比较模糊，系统在开发过程中遇到了频繁的需求修改，拖延了项目的进度。在后面我们对需求不清楚的模块采用原型化的开发方法，在需求清楚的情况下，对需求进行严格的分析和确认，对后期需求的变更有着严格的变更控制，保证了项目按时完成。我将这些项目中所遇到的问题和思考分享给团队成员和记录为以后系统分析和设计工作提供指南。
软件开发模型
瀑布
原型
统一过程
敏捷
瀑布开发模型 是结构化的开发模型，一个一个阶段的进行项目开发，每个阶段的产物作为下一个阶段的输入，每一个步骤都有严格的流程和方法控制，需求分析，设计，编码，测试。
适合于需求明确的项目开发，需求设计完后如果后面出现需求变更对整个流程有着很大的影响。
原，使
统一过程开发模型。 改开发模型是结合瀑布模型和原型化模型的优点。主要分为初始，细化，构建，移交4个步骤。每个步骤都有特点的产物，改模型结合了风险控制和模块驱动开发和迭代的思想，适合于比较大型的项目
敏捷开发，强调相应需求的变化，和开发团队的合作。是以更高要求的满足客户需要为导向。强调可以运行的代码好过详细的文档，个体的交互好过流程和工具，客户合作好过与谈判。相应变化好于遵循计划，主要的开发方法有scrum ，水晶，极限编程等。
不同的项目结构和大小采用的敏捷的开发方法各不相同，由于该项目比较大，涉及模块众多，极限编程和水晶方式都不太适应，scrum方法 就比较适合，下面我结合该系统的保单管理模块就结合scrum做出具体论述。
项目中
新功能，技术。根据需求的反馈，不断的做出调整
scrum是一个基于迭代和增量的开发模型，它强调团队的合作和快速相应和次序的交付，有一些具体的组织流程，比如产品的
sprint计划议计，主要是确认里程碑。具体的工作比如是承包模块什么时候实现新契约的流程的开发完成，
sprint评审 反馈 下一个
sprint回归
日常的scrum会议，团队的各个成员快速的回报一下昨天的工作和今天的计划还有block手中的问题，会议组织者快速的对问题，
统一过程模型
敏捷
统一过程
统一过程模型结合了原型法和结构化模型的特点，主要分为4个阶段，初始，细化和构建还有移交，每一个阶段都有特定的产物，并且结合了原型的迭代和增量的特点，还结合和风险控制，模型驱动，适合于大型项目的开发，。
面主要结合保单管理模块在初始和细化阶段进行详细的阐述。初始阶段的主要工作就是确认项目目标，和项目范围，对项目资源进行规划，还有识别项目风险，保单管理模块的主要目标就是要实现，保单的管理，在线修改的申请，生效保单的查询，还有保单历史版本的查询。由于该模块涉及功能比较多，和涉及模块比较多，业务操作复杂，申请了和业务领导的配合，和几名有着丰富保单管理经验的业务人员的帮助，我们在确立项目范围的工作主要就是首先对历史系统进行分析，然后通过和业务人员进行访谈，和去现场观摩业务人员对流程具体的操作，结合文档。最后通过联合需求会议消除对一些出入的地方进行逐步的确认，最后完成了项目范围的确认。在识别风险这块，首先是业务风险，业务人员有时会提出一些特殊的需求，比如核保人员操作人员认为，核保权限分配采用只有超级理员的授权方式十分繁琐，希望我们可以实现逐级授权。经过我们和业务领导和产品经理的确认业务人员要求实现的功能具有一定的业务风险，经过分析对于这个业务行为我们并不会去放开实现。其次是技术风险，承保模块的业务流程在完成的各个阶段会分别去调用外部系统，由于考虑到性能的影响，有一部分接口延迟比较高的接口我们采用了消息中间件的方式去实现该功能。对比了市面上的一些主流中间间，比如ibm 的mq ，rabbit mq ，kafka，racket mq。在功能和性能方面技术同事一致认为rabbit mq 的吞吐量和触达率，失败重试，等方面具有很高的优势，经过项目组的分析和调研讨论，任务rabbit mq 首先该中间件采用的是elang语言开发的，由于我们是java 团队对中间间具体的内部实现并不是很了解，有着很大的技术风险，所以我们排除了该中间的采用，最后我们采用了在性能，安全性，可控程度都具有很高表现的kafka作为我们的消息中间件。在人员分配这块，我们结合我们项目的实际情况，由于项目资源比较紧张，我们首先识别了完成该项目的关键的几个模块，对这几个关键的模块做了人日估算，然后采用项目资源管理工具甘特图绘制了项目完成的任务节点，挑选出关键路径，然后进行项目人员的分配，和资源的申请，为项目的顺利的完成提供了资源保证还有对人员资源进行了控制。细化阶段的主要工作就是对承保系统进行详细的设计，确立项目的架构和模块和接口，由于考虑到我们业务的复杂性和对以后功能的复用性，我们采用的项目代码架构的风格是ddd领域模型开发，在项目框架上我们采用的是spring boot 框架，该架构能够通过脚手架快速的对项目进行搭建，通过spring boot的start技术快速的对中间件进行集成，极大地缩短了开发周期。在模块分配方面，我们采用了微服务架构，对系统进行模块分解，主要的模块有，保单管理模块，承保模块，产品工厂模块，智能核保模块，然后对其再依据功能再进行拆封，比如承包模块可以拆成保单保费计算模块，责任匹配模块，收付费模块，打印模块等等，通过模块的拆分可以使得每一个模块都可以独立的进行开发，降低了系统的耦合性，开发人员可以只关注自己的模块。最后就是接口的设计，由于业务流程复制，各个类之前的创建和组合关系复制，我们采用了创建行，结构性和行为性的设计模式对接口进行设计，实现了代码的高复用性。在细化阶段还有很重要的工作就是测试计划的安排，在做系统详细的阶段我们就和测试的同事安排进行沟通，完成他们测试计划和测试任务的安排，并且要求测试能够尽快的介入。
敏捷开发
敏捷开发的特点是快速响应变化，高度配合客户完成项目，持续不断的迭代和教父，敏捷开发的原则有，个体的交互胜过流程和工具，可以运行的软件胜过详细的文档，与客户合作胜过与客户进行谈判，响应变化优于遵循变化，市面上流行的敏捷开发方式有 scrum，极限编程，还有水晶法，极限编程等，由于承保系统模块多，流程复杂，系统比较庞大，我们经过分析和讨论最后选择了scrum在项目中进行了具体实践，下面我将具体阐述在scrum方法中结合我们具体的设计开发进行的实践。scrum 开发方法的特点特点就是，结合具体的方法论，通过一个一个里程碑进行项目的持续交付，最终获取客户的满意。scrum 主要的方法论有，backlog的管理，sprint 会议的准备，sprint会议的执行，sprint会议的回顾，日常scrum的站会。在承保系统中，我们具体的敏捷的实践就是，我们会将团队有模块划分才分为各个团队，比如承包模块，产品工厂模块，保单管理模块，智能核保模块。各个模块会按照计划参与sprint会议，项目组织者和模块组长会与backlog管理，项目各个模块团队会各自参与每日的scrum站会。backlog的管理主要是面向于整个系统方面，它记录了系统要完成任务的关键事件，和对任务的详细安排，还有新的功能增加，需求的调整等事件，有项目的管理者组织和，它会根据用户的需求不断调整，比如规定了几个关键事件 承保模块的关键事件 就是新契约流程的创建，保费的计算。产品工厂的关键事件就是通过json配置可以快速的发布保险产品，保单管理的关键事件就是可以对保单对生效保单和历史保单进行查询，在线对保单基本信息进行修改申请，智能核保系统的关键事件就是可以结合云计算和大数据供应商和自己系统的规则引擎实现保单核保任务的分发和决定。sprint会议就是全体项目成员进行会议，主要分为会议的计划，会议的评审，和会议的回顾，会议计划要求了计划了下一个里程碑要实现的主要功能，统计上个里程碑完成的情况，还有新的需求调整的情况，对各个团队下个阶段任务的调整等。会议中主要就是对本阶段里程碑完成情况进行展示和分析，对各个团队任务的调整进行安排，对需求调整进行说明。sprint会议的回顾就是对团队项目成功进行对客户进行展示，对项目中的一些问题的解决方案进行阐述。对各个团队反馈的问题进行解决。scrum会议是每个小组团队人员参与，需要是每个人对昨天的工作总结和今日工作计划和一些需要协调的问题进行反馈。我们的sprint会议室安排每2周进行一次，总结会是1个月进行一次。在不采用敏捷开发模式，依据我们的具体项目经验，原来需要6个月完成的模块，在具体结合scrum模式项目进度开发进度加快了20，客户的满意度也得到了极大的提高，团队之间的合作也变得更加自然高效。
测试
系统测试
系统测试主要包括功能测试，性能测试，稳定性测试，可靠性测试和安全测试，功能测试的内容是测试人员按照需求说明规格书编写测试用例，按照测试用例去测试，保证系统在功能上满足需求要求。性能测试是要求系统在功能正常的前提下，比如对请求响应时间，系统最大并发数量还有系统吞吐率是否满足设计需求，可靠性测试是要求系统平均无故障时间比上故障修复时间的比值尽可能的接近百分之百，还有在不可抗环境和外力的影响下系统也要能正常的提供服务，比如停电，系统遭受攻击等。安全性测试要求系统在外部攻击的防护或者是内部破坏对其进行监控和留痕的措施，比如外部sql注入攻击，dos攻击等，内部破坏比如进行数据删除是否留痕，数据是否能够还原。下面我主要就承保系统在功能性测试和性能测试和可靠性测试结合项目实际开发做具体阐述。
承保系统最核心的模块是承保模块，它包含了保单创建，保单的批改，保费的快速计算，流程的自动处理，保单生成和打印等功能，在保单创建功能上，测试人员首先通过创建看保单必填字段如投保人，被保险人，选择的保单责任一些必填校验是否校验，如果不校验是否可以创建保单，创建好的保单是否能流转到下一个任务人的环节。保费计算功能，测试人员需要验证保单在保单各个因数的作用下，是够能够计算出正确的保费，在有折扣的条件下保费计算是否正确，保单批改功能，测试人员会操作多个业务员权限的账号，检查不同权限的业务员账号是否能够操作保单，权限不匹配的业务员账号是否能够查询保单和对保单进行批改操作，保单生成功能，确认保单是否生成成功，是否有保费缴纳记录，调用外部系统是够成功，是否能正确的打印保单信息等功能。在性能测试阶段，测试人员会采用性能测试工具loadruner测试系统响应时间，并发量，和吞吐量。具体的操作是，首先配置被测试服务的数量和机器参数。在承保模块我们部署了4台4和16g的机器作为分布式集群提供服务，测试人员首先对系统各个接口模拟正常的请求情况，然后记录系统响应时间，看系统响应时间是否满足性能需求，然后通过设置系统并发请求数量模拟在50，100，300 和500并发量的情况下对系统进行测试，发现在并发量500的情况下系统的接口超时率达到了60，然后我们考虑机器性能和具体服务阻塞的节点进行分析，对服务进行了代码和结构上做了优化最终系统并发通过量在1000情况下超时率不超过5%，还有就是系统的安全性进行测试。测试人员在保单创建的时候模拟sql注入攻击在请求的url上进行sql拼接，看系统是否对非法url进行拦截处理。还有查看在业务人员进行一些危险操作，比如批量和赋权和删除操作，系统是够正确的进行系统留痕处理。
面向对象测试
面向对象测试是关注类和对象的接口，行为，和交互的。面向对象测试主要包括下面这些类型
单元测试
集成测试
系统测试
静态测试
，
单元测试是测试单个类的功能和职责，看该类的实现否满足系统的详细设计，测试方法是白盒测试，软件开发人员编写测试单元测试用断言方式判断功能是否正确。
集成测试是对多个类和对象之前的交互和接口方法组合进行测试，看功能是否满足需求规格说明说的要求，集成测试是黑盒测试，由测试人员编写测试用例去测试
系统测试是面向整个系统进行的测试，主要看系同在功能，性能，和可靠性方面是否满足用户需求，系统测试是黑盒测试，由测试人员按照之前编写的测试用例去测试。
静态测试是一种不执行代码的一种测试方法，通过一些代码扫描插件和项目开发团队成员对代码进行review，检查代码逻辑是否有bug，是否有潜在问题，和是否满足程序功能。
在承保系统的开发中我们团队结合面向对象测试方法对项目的功能行为，安全性，可靠性等方面进行测试。下面我将结合单元测试和集成测试还有静态测试结合实际工作中进行详细的阐述。在承保模块中保单类中的单元测试有，保单的必填信息是否都有校验，保单保费是否计算正确，保单的责任和保单的种类和保单的标的是否匹配。我们采用的单元测试框架室junit4，它可以对mock出类和对象对其他外部因素的依赖，可以让我们聚焦类和对象自身的行为和方法，与外部依赖进行解耦。通过类和对象的具体属性和行为，我们通过边界值分析法，代码圈度法，条件路径判断等白盒测试方法去编写单元测试类，通过assert断言判断所与设定的条件代码执行后的返回结果是否符合预期的要求，通过单元测试的编写和执行首先帮我们寻找出了我们在代码开发过程中出现的bug，其次在后续对原有功能进行调整后，我们可以通过单元测试快速的判断已修改的代码对原有功能的影响，判断修改是否对原功能产生影响，极大的保证了功能的稳定性。我们在项目中采用了阿里的测试代码扫描插件，要求代码的单元覆盖率要到90。在系统测试方面主要依赖测试人员依据需求规格说明书对项目功能，性能可靠性方面进行测试。功能方面比如保单创建后生成的保单号要求唯一，保单的必填校验符合需求说明，保单的保费挂钩保单的因素计算正确，保单创建后进入保单审批池要求批改业务人员要有权限才能查看和对保单进行批改操作。在性能测试方面我们安排了4台4和16g的主机部署承保模块通过集群的方式提供服务，测试人员用loadrunner压测工具对服务进行接口压测，首先测试接口在预估范围用户数量上进行接口的返回时间测试看承保模块创建保单和查询保单响应时间是否符合用户需求，然后模拟并发的情况通过设置并发参数在50，100，300，500，1000个用户的并发情况下对接口进行请求数量10000个进行调用观察接口服务是否能正常提供服务和是否超时，在测试人员进行500并发量的时候发现创建保单的接口延时率已经超过60，我们结合服务部署环境，Nginx请求分配策略，服务端日志情况对高延迟率进行了具体分析，最后优化了代码和nginx的配置，最后测试人员在用户并发1000情况下接口的正常返回数量达到95 超额的满足了系统性能的需要
设计模式
创建型 单工原构
结构型 适配器，桥接，享元模式，组装，外观，代理模式
行为性 观察者，状态，迭代器，命令，访问者，中介，备忘录，解释器模式
单例模式，在对象的创建过程中，要求容器中的对象只存在一个实例，服务中对对象的使用只有一个实例，避免了多个实例的创建，节省了系统内存的开销。
工厂模式，创建对象通过接口进行创建，不用关心对象创建的细节，降低了代码的耦合性和提高了代码稳定性和可读性。
模版方法模式，通过定义一个抽象类，将通用的流程方法都抽象提取到抽象类中，在抽象类中去对方法进行编排，具体的方法实现延迟到具体集成该抽象类的业务类中进行实现，模版方法定义好了实现功能的骨架，业务实现类只要实现具体的业务代码，具有控制功能流程的控制作用，而且降低了系统的耦合度，提高了代码质量和可维护性，提高了代码的课复用性。
责任链模式，是一种行为性设计模式，通过责任链模式实现了消息的发送方和消息的接收方解耦，发送不用制定具体消息的执行方，消息的处理方通过链式的方式进行传递和处理。
下面我就承保系统重，承保新契约模块中采用的单例模式，模版方法模式，和责任链模式结合实际的设计和开发做出具体的阐述。在新契约核保的流程中，创建者创建完单，该保单就进入了核保池子中，创建者并不知道是将由谁进行核保，我们在保单核保等级触发的时候通过责任链的模式进行设计，保单的核保等级分为1到5级，具体到每一个的各个规则都不同比如，保单标的价值超过5000会触发3级核保，我们将不同的规则组设计成一条链式的结构，定义了一个接口IpolicyCheck里面有是isCheck 和check的方法定义定义了一个next方法指向下一个任务处理者，定义了一个抽象类policyCheckAbstract实现了该接口，抽象类定义了一些抽象方法和对方法进行编排，业务类只需要继承该抽象类，然后在项目启动初始化的时候将具体的规则类放进容器中，具体的保单创建的时候会调用check方法，将规则的类逐级网上匹配，直到匹配到最大的为止。通过责任链模式在保单创建是进入到具体核保人员的手中，创建者并不要要关注核保人员是什么等级和是具体的那个人，对消息的发送者和消息处理者进行了解耦。新添加规则也只需要实现新建类和实现具体的规则对原有代码结构不会进行影响。在模版方法模式中，在保单创建的包含了一系列的保单操作如时候会调用周边系统，计算保费，发送短信，和触发核保等操作，我们通过定义了一个policyquoteabsect抽象类定义了这些方法对方法进行了编排。然后具体的PolicyInstans继承了该抽象类，实现具体的方法，从而完成保单新契约创建的一系列操作。单例模式中，在保单管理中对于周边系统的一些配置是需要公用的比如调用短信服务商参数的配置，调用中国保单登记中心的系统调用延迟测试，最大响应时间的一些配置，这些服务都是多个业务功能中都需要用的，我们不希望用的时候创建多个配置实例，通过单例模型在类第一次被创建的时候就只创建一次，保证这个配置在系统中是唯一的。通过设计模式我们使得我们的项目能够做出更好的设计，开发人员也可以按照设计进行代码的开发，对项目代码的质量属性有很大的提高，为项目高质量和按时交付提供了技术保障。
开发方法
面向对象设计原则
单一职责
开闭原则
里氏替换
依赖倒置
组合和聚合服用原则
迪米特法则
单一职责：要求每个类的职责单一化，只关注单一的功能原子化，开闭原则是要求类对功能的扩展是新建类而不是对原来的类进行修改，对扩展开发对修改关闭。里氏替换原则要求子类可以替代父类，用子类去实现功能而不是父类。依赖倒置要求对高层模块不依赖底层实现，类依赖于抽象而不是依赖具体实现，抽象不依赖具体实现，实现应该依赖抽象。聚合优先原则，对于继承和聚合应该优先选择聚合。迪米特法则，每个类对于其他类的具体内容的实现应该是透明的，每个类暴露给外部的方法应该越少越好。下面我将就在承保系统中的保单管理模块对单一职责，开闭原则，依赖倒置原则结合类的设计做出详细阐述。
在保单管理模块中每一个类都应该只有一个职责，我们将保单的创建，修改，更新，删除的类都分开，每个类都实现单一的功能，分别的去实现保单功能的新契约的创建，保单的申请修改，保单修改的批准，保单删除申请，保单删除确认等操作。这样使得模块中各个类的职责更加清晰，对每个类的扩展更加方便，代码结构可以更加清晰，可以更好的维护模块功能。
在开闭原则中，保单的反洗钱规则要求按照需求分类有4个大类，分别是姓名基本信息的校验，职业和年龄校验，家庭住址的校验，每个大类中会有具体的实现，我设计了一个定义了一个check的方法，在下层中定义了一个checkruleabstract的抽象类对校验流程进行编排，具体的校验逻辑需要各个校验类去具体实现，如果新加一个规则校验类，开发人员不需要对类进行修改而是通过添加业务校验类的方式进行校验功能的添加，使得添加功能对于扩展是开发的对于修改是关闭的，这样可以使得代码结构更加清晰，增强了代码的可维护性。
在依赖倒置原则中，我们定义了ipolicyablity接口，对于保单的对象操作的一些方法，repository如，保单保费的生产，保单的流转，保单的暂存，保单的提交的一些操作。业务层的一些具体操作如保单的快速报价阶段需要对保单保费的生产和保单的暂存不需要依赖于具体的类的实现只要依赖于ipolicyrepository就可以，实现了不依赖来于具体实现，依赖于抽象和接口，实现都依赖抽象，这样的好处是如果对于ipolicyrepostory 中具体的实现进行修改比如数据库的更换，供应商接口的更换不需要对业务逻辑进行调整，实现了隔离的作用，增强了代码的健壮性和可维护性。通过面向对象设计原则的运用为承包系统高质量的实现和按时完成项目有着巨大的实践价值，使我们可以设计出更加优秀，可靠，和健壮的模块和系统
需求获取
需求获取方法有用户访谈，问卷调查，现场观摩，情景串联法，原型法
用户访谈法，是通过组织业务人员和用户采用1对1或者1对多的方式对系统的要求面对面的沟通去获取需求，可以分为结构化和非结构化的访谈，通过访谈可以对系统需求的有一个清晰快速的获取，要求访谈人有较高的业务知识，有一定的成本。
问卷调查就是通过问卷回答的方式获取需求，问卷调查的方式可以触及的人数比较多，范围比较广，可以快速的低成本的去获取需求。
现场观摩的方式是通过需求获取人员下到生产操作中，具体观察业务人员的操作和用户的反馈获取需求，这个方式对于业务比较复杂的流程有着很好的效果。
情景串联法是通过绘制一系列的业务场景，对业务人员进行描述，业务人员可以迅速做出响应的反馈，比较生动形象，可以挖掘出很多隐藏的业务需求。
原型法就是通过先通过对业务的了解，绘制出一个简单的界面原型给用户或者业务人员观看，这个适用于开发一个新的系统或者对原来系统改变比较大的情况，可以快速的反馈出需求获取人员对于新系统的需求判断是否正确，是否满足用户的需求。
在承保系统的需求获取阶段我们采用了多种方式对需求进行获取，在系统设计初期阶段我们采用了用户访谈，和现场观摩的方式对需求的获取，设计中期采用了原型法和问卷调查的方式，在后期采用了情景串联法和联合需求计划的方式对需求进行获取。
下面我将通过实际的项目经验结合这些需求获取方式，在前中后期对进行详细的阐述。
由于保险系统功能众多，业务流程繁杂而且众多，要对保险承保系统获取一个详细，准确，和范围明确的需求十分困难，所以方法论结合实际十分重要，在需求前期阶段，我们首先通过公司领导的授权确定了几家营业部业务比较繁忙的业务人员，通过前期对系统进行一个分析，选取了一些比较突出的问题和业务人员采用结构化和非结构化相结合的方式的用户访谈，在结构化分析中我们询问了，一个保单新契约的完整生命周期是什么样的，完成一个新契约的创建的时间周期是多少，在哪些流程中的业务会比较复杂等等问题，通过结构化的用户访谈，业务老师详细的实际工作经验和专业知识很快的弥补了我们之前对系统分析的一些不足，对于一些之前一些比较模糊的需求有了一个清晰的认识，结构化访谈结束后我们就和业务老师进行了非结构化的访谈，非结构化的访谈主要聚焦于业务老师在系统操作，业务流程，和对系统预期方面的话题，通过非结构访谈我们获得了一些通过文档和分析很难获得的一些隐形知识，对于一些我们对业务的一些疑问有一个了更加清晰的认识。由于营业部全国各个地方都有，每个地方的营业部的业务人员专业知识和对系统的认真都不一样，我们通过问卷调查的方式可以快速的低成本的获得一个比较全面的需求。在需求中期
需求分析
需求获取的步骤，第一步是确定用户的需求，包括系统对于功能性和性能方面的要求，主要的需求分析方法是 用户访谈，。。。。
第二部就是需求分析，对于获取的需求进行分析整理，对于需求进行文档进行详细的描述，比如功能方面，性能方面，安全性方面，可靠性方面，都做出具体和详细的描述，然后对需求的优先级进行排序，为后面需求实现做计划。
第三部就是需求的建模。
为了更好的和业务人员和开发人员进行沟通和协调还需要对整理出来的需求进行需求建模。一般采用结构化和非结构化的方式进行需求建模，结构化的方式有创建数据字段，数据流图，状态装换图等方式，面向对象建模包括创建用例图，活动图，状态图，通信图，协作图 等一系列uml图。
最后就是需求的确认通过需求的建模可以快速的与用户进行需求的沟通，通过与用户反复的确认，保证系统的在功能性能等方面满足用户的需求。
承保系统中我们在需求分析阶段主要通过以上步骤去获取用户对系统的需求来为后面系统开发，下面我将结合在需求建模阶段采用的面向对象建模的具体方式在承保系统中的实际工作进行阐述。
基于构建开发
首先说下什么是构件开发，什么是构件，构件的特点，构件开发的好处
基于构件开发是软件开发中面向构件开发的技术，它是基于构件的理念和计算，将软件系统划分为多个独立的构件，然后通过构件的组装成一个独立的系统。这种开发强调构件的服用和组装，大大的提高了软件开发质量和效率。
什么是构件
独立，功能，
构件可以被定义为一个独立，可以重用的软件组件，它可以完成特定的功能，并提供标准的接口和封装实现，构件可以是可以执行的代码，库，服务和软件框架，可以在不同形式的软件架构中复用。采用基于构件的开发的优点有首先，构件在功能，行为，性能方面在进入构件库中每个方面都得到了严格的保证，是经过充分测试的。其次在软件开发周期方面，基于构件开发可以极大的缩短软件开发周期，为项目开发节省成本。在可维护方面，基于构件的开发，系统的维护和升级只需要考虑构件的兼容性对构件进行升级就行了，提高了软件的可维护性。在复用性方面，基于构件的开发提高了软件的服用性。基于构件的软件开发步骤有包括构件的获取，构件库的管理，构件的维护，在构件的获取方面有通过公司自行的设计和研发和对市面上开源的构件进行适用，构件的自行开发包括构件的构，构件的规划和设计，构件的开发和测试，构件的发布和管理，构件的组装和集成，构件的维护和更新在构件规划中，需要考虑构件的接口设计，功能，性能方面和兼容性方面，并设计测试方法，保证构件的质量和可用性。
构件的开发和测试，在这一步骤中要对构件按照设计进行开发，满足接口规约，和向下兼容性。在测试中要对构件的功能和性能，可靠性方面进行全面的测试，确保构件的质量达到要求。
构建的管理和发布，对构件库中的构件版本和种类进行分类管理，在构件为了适用于新的功能进行的新版本的发布和对于老版本的进行维护，通过构件库的管理实现了构件的稳定性和易用性。。
构件的组装和集成，这一步骤需要对系统需要的构件进行组装测试组成一个完整的系统，选择合适的进行组装，确保系统的性能和稳定性。
在承包系统中我将就新契约模块中对于
