保险系统的部分模式

Wolfgang Keller 关于保险系统采用的一些pattern的介绍，这是网上流行的一篇译文，但是初看之下有些行业词汇的误译，特意做了修正，顺便排版成word文档，虽然不清楚是不是已经有人做过这件事了。
原文虽然已经发表很久了，但我认为国内的保险软件开发商如果实现了这些pattern的已经是难能可贵了。

保险系统的部分模式

作者：Wolfgang Keller 著，liwenhua 译    本文选自：UMLChina  2003年01月10日

 

 

对于许多保险公司来说，要建立一个能够缩短产品周期，柔性灵活的保险系统可谓是一个挑战。虽然这个系统有着巨大的市场，围绕这些相同的问题开展了许多项目，但是这些项目似乎仍然有些扑朔迷离。实际上，这个问题没有答案。

保险系统参考模型概述

随着金融市场诡秘多变、竞争加剧，较短的产品革新周期将有助你在这个充满竞争的金融服务市场领先。服务提供商总想扩张到新的产品领域，所以允许交叉销售。他们尽力提供个性化产品，以便争取个人市场，为现有客户提供更好服务。同时，为了减少投资代价必须要有灵活柔性的系统。而有了灵活柔性的系统，在能够承受的维护开支下就能达到上述目标。

为了达到这些目标，金融业采用了许多系统。这些系统具有很大的相似性。这种相似性就是在银行业和保险业都存在的所谓产品驱动方法。这种方法是从传统制造业借鉴得来的，但是它与传统制造业又存在显著差别。这个差别就是你在生产订单（保险单）的同时就进入了系统的投保服务。毕竟金融产品是无形的。

其它工业的类似情况

 

本文收集了产品驱动的保险系统中的一些模式，他们解释了那些驱动保险系统运转的各个部分在设计上的基本规律和方案。这些模式设计得十分灵活，可以在保险和金融业的许多系统中看到。也许可以在其它工业中找到这些模式的身影，但是，在此将不解释如何不需要其它领域的实际项目背景知识，它们就可以应用在那些领域。如果有人从其它工业也得出了相似的模式，我们可以比较它们，匹配它们。

 

“产品树”是一种核心模式——这种模式试图以树的结构来呈现产品——其原型来源于制造业，只是到了最近才被应用到保险业（大约10年了）。服务提供者希望按顾客需要的方式，使用一系列预定义好的单元来配置产品，这种想法在制造业和其它行业中也可以看到。还有好几种称之为批量定制的方法，它们严重依赖信息技术来传递批量定制的产品[And+97]。在计算机行业有一个很典型的例子——DELL或者VOBIS可以定制个人计算机。在布匹行业也有同样的例子（Levy Strauss和其它）。

个人非实物产品同样可以在电信业找到。账单计划也可以使用与产品树和产品服务器类似的技术从预定义的构造块中选取来进行配置。

本文并没有全部使用模式语言去表达模式。实际上，有很多方法可以对产品建模，我们这里只使用了其中一种。

现有的保险业参考模型

许多对模式感兴趣的读者可能听说过IAA（IBM's Insurance Application Architecture），并奇怪这里怎么会与之相关呢？其实IAA价格不菲，除了尚可利用的二手资源外，我根本没有直接接触过它，也就无从详细讨论这种相关性。对此我表示抱歉，不过，这也不是我的错。我所能借鉴就只有VAA（VAA95）了。VAA是德国保险业参考的一个公开模型，我总是尽可能参考它。

驱动保险应用设计的一般动力

驱动这些模式产生的因素是明确的，它们包括：

1. 市场中的时间因素和系统的灵活性：在欧洲，近几十年来，政府一直严格对保险市场进行规范。但是随着全球市场和欧洲市场不规则因素的出现，保险公司发现他们又处在一种新的竞争空间中。银行，其它金融服务提供者，来自邻国的保险同行，以及其它机构等等，这些新的竞争对手不断涌现。时间在市场中已经扮演了一个决定性的角色。那些有能力更快设计出新产品并把产品推向市场，同时又能够提供个性化服务产品的公司将比那些好些年才向市场推出一个新产品的公司更具竞争优势。

2. 新产品和个性化产品：Michael Porter分析了几种竞争战略（Por85），一种是价格竞争，一种是质量竞争，还有一种是综合服务竞争。如果你想开辟新的市场，或者想成为为客户眼中质量信誉的佼佼者，在更多的客户中拥有更多的产品无疑会帮助你实现梦想。在工业化早期，各方面的开销相互冲突，要想做到这点很困难。但是，随着现代计算机技术的日新月异，以较低开销提供客户个性化产品已经成为可能，所要做的就是把原来产品的标准元素模块同客户个性化产品要求结合起来。谁能为客户提供个性化产品谁就具有众多的竞争优势。

3. 服务点和节省开支：有许多策略可以增强竞争力。其中一个策略就是为客户提供贴身服务。许多保险系统还纯粹实行着老的办公制度，大量的公文在多个办公室和销售代表之间流转。节省开支策略就是瞄准公文流转所带来的诸多烦琐，努力精简公文处理的中间步骤。保险系统被部署在更靠近客户的地方，通过运用互联网络和个人电脑，销售代表的膝上电脑可以与事务处理中心紧密集成。

4. 开发成本：保险业提供纯粹的无形服务，既没有硬件也没有可以触及的实物。一个保险公司可以显著地减少数据处理过程的开支，这一点跟制造业企业减少劳动力成本和生产原料成本没有什么两样。做到这一点意味着竞争优势。因此，在开发保险系统的时候，在提供更多功能和灵活性的同时，也要追求开发成本得到降低。

5. 一个保险公司的传统结构对应于产品包和开发开支：就拿我们涉及到的这个新保险业来说，保险公司有那么些时间是繁忙不堪的，是他们的需要扶植了数据处理技术的发展。保险行业的遗留系统和组织一般都是围绕产品分类而建。举个例子，譬如你会看到人寿保险，健康保险和财产保险分而治之，这些反映了公司的组织机构和处理过程的分布。如果按照这样来设计系统，就会存在大量功能上的冗余，例如，财产保险中的客户申请处理系统和汽车保险中的客户申请保险系统绝大多数是相同的，而健康保险和人寿保险都是以人的身体为保险对象。所以围绕产品分类来开发系统会导致不必要的开发开支。从另一方面来说，如果所有的领域专家还是旧的观念，尽管对部分产品很精通却很少知道其它产品，那么，要开发同时能够满足所有产品的系统也是万分困难的。现实中还经常存在分歧，不同部门并不都愿意同心协力为所有产品类别建立系统。

模式

这里呈现的所有模式具有相当强的内在联系，对于你将要应用的领域，这些模式可以组织成一些章节来讲述。

 

图1 模式集合的指示图

这里给出的模式只是保险领域所涉及的众多模式中的一部分，如果把它们按照某种逻辑组织起来，将有助于更好地理解。因此我们把这些模式安排到如下章节：

保险系统的顶层结构： 大多数保险系统都涉及如何处理顶层子系统的结构问题。在这一部分，将要描述的模式有： 保险价值链，产品服务器和作为产品服务器典型子系统的规则系统。

保险产品模型：这里包含对产品服务器的产品进行建模有意义的一些模式。这一部分描述的模式有：产品树和对象事件保证。

保单： 这一部分涉及如何实现保险保单，这里只提供了唯一的一种模式：作为产品实例的保单。

分布式的保险系统：在一个典型的保险系统中，假如我们拥有一台虚拟的超级计算机，这台超级计算机把保险组织中的每一名员工紧密联系起来，数据存取无需时间，网络带宽无限制而且免费，那么你会发现其中一些子系统是不必要的。不幸的是，在现实中，依然要开发这些子系统。那么，这里将提供一些用于分布式处理的模式，比如：保险销售系统，或者一个表格系统。

 

 

保险系统的顶层结构

在这一篇文章中，我们将介绍在多数现代保险系统中可以看到的、依据保险价值链而存在的顶层子系统。保险系统中一个非常重要的产品部件就是所谓的产品服务器。典型情况下，作为一个产品服务器，它存在一个用于处理产品规则的规则系统。

保险价值链

例子

你被分配去为新的保险办公系统设计结构。在现在的系统中，你找到一个一个根据产品分类的系统分支，如人寿保险，财产保险，汽车保险。你发现，这些现存系统中存在大量交叉重复功能，尤其在申报处理系统和政策处理系统。你也发现要增加一个新的产品需要做的工作十分繁琐冗长，它以每年增加两个新产品的速率进行着。这样低效的原因源自于系统管理政策部分和管理申报处理部分的产品知识混乱，更多其他的产品知识还存在于系统其它部分。

问题

对一个保险办公系统中的大部分商务功能和商务对象来说，什么是一个好的领域构架呢？

约束

系统应该这样来构造，它必须能支持你的竞争战略。我们已经讨论了工作中的市场约束。

方案

根据保险中的价值链构架领域结构。产品－政策－申报处理－销售和市场－客户服务，再加上帮助系统，比如伙伴子系统，保险对象子系统，进出支付系统。

结构

 

图2 依据保险价值链的保险系统结构图。类似于Porter的价值链模型，这种结构被保险业所采用。

通过子系统来进行价值链建模：

· 产品开发和定义子系统：产品为其他子系统所使用前必须给予定义。产品开发和定义子系统负责为其它系统提供产品定义。产品定义由系统其它部分解释。

· 保单子系统：负责存储保单，支持所有开展商务活动的用例。

. 理赔子系统：所有保险的理赔集中处理，主要业务对象包括事件、理赔、涉及的人员机构和其他。

· 销售和市场子系统：处理面向客户的产品销售

· 客户服务子系统：有助于向你的客户提供你期望的额外服务，这些服务是在投诉系统所规定的服务之外的。

要建模好所有的商务功能，你需要像下面一样的帮助子系统：

· 伙伴子系统：存储你公司所有合作伙伴的信息。

· 被保对象子系统：存储有关被保和投保对象的信息。

· 支付子系统：处理收入和支出的现金流。

通常你会发现还有好多系统，比如通用名册保持（general bookkeeping），管理信息系统和数据仓库，人力资源系统等等，这些系统不单是针对保险系统，而是普遍存在的，所以我们这里不再进一步讲述。

结论

并非只要采用保险价值链模型就能得到一个灵活柔性的系统和缩短的市场开发时间，你还需要使用更多类似产品服务器、产品实例参数这样的模式来帮助你实现目标。

采用模式你可以建立一个满足所有产品类的系统，但是不能一步到位，多数情况下你需要先从一部分产品类开始，然后逐渐扩充系统以便从遗留系统迁移过来。如果这样，你就避免了重复投资，从而减缩开发费用。

上述结构是为内勤系统设计的。它并不会单独影响你在服务上的态度。

采用上述结构并不意味着能减少通讯的层次，节省开支。要想达到这个目的，你需要启动业务过程重组并采用工作流系统。

实现

保险价值链是一个领域构架模式，要实现一个现实系统你需要一个应用构架。目前，多数领域系统都通过一个树状层次构架来建造。工作流系统也经常用到。通常，你无法在一个地方一下子实现整个系统，或者一下子实现虚拟的单个系统。目前的网络带宽和性能还不如人意，基于这些考虑，你不得不把系统分成内勤和保险销售两个系统。

变种

你常常会发现产品系统和保单系统联合工作方式的差异。将要谈到的产品服务器模式与上述两者都不同，而其它像UDP之类的框架，没有提供两子系统之间的子系统边界，但是却把保单当着产品实例，并且贴切地耦合了两个系统

相关模式

一般，产品子系统被当作产品服务器来实现。

一个保单子系统通常采用用户定义的产品框架来实现，这样可以充分利用组件模式和Type Object模式的优势。通常，你可以把保单当成产品实例。

已知应用

上述构架在保险业几个领域构架，比如Phoenix构架，IAA--IBM的保险应用构架或者VAA(VAA95)有更详细的描述。

进一步阅读

尽管保险市场巨大，但是有关保险系统的资料还很少，在这一点与其它市场领域相反。有关基于价值链构架的基本概念和原料产品的相关概念可以参阅《Innovative Gestaltung von Versicherungsprodukten》。以上的已知应用有大量的文档，描述了相近的领域构架。来自IBM的IAA也是一个巨大的领域构架，但是它已经注册，不向公众公开。

 

模式：产品服务器

 

例子

假设你想建立一个产品驱动的保险系统，这个系统一般具有一个后勤系统，用以处理计划书，管理保单，处理理赔。另一方面，你还需要为用于销售的个人电脑，诸如内部供给或者保险经纪人支持等其它系统提供产品定义。

 

图2 多个系统需要明确的产品定义

问题

何处定义你的产品知识以及怎样发布？

约束

除了上面提到的，还有几个因素也需要考虑：

平台独立性：后勤系统一般运行在OS/390机器上，销售PC一般运行Win95或者其它个人操作系统，互联网上的客户端可能运行Java应用，或者通过嵌入式HTML与某种语言写的服务器端程序组成应用。你的产品定义必须在不同平台都可以访问。

接口设计：宽接口容易导致维护困难和软件结构过于内聚。狭接口则适合大量客户在不同平台的情况。

产品知识封装对最佳用户界面设计：一方面你希望封装所有产品知识。这样的好处是，例如所有的对话框只解释一个产品定义，而且能够自动改变适应新的产品定义。缺点是自动化的界面缺少美观。这种方法适合内勤系统对话框，但是不适合销售对话框和销售员笔记本电脑上的多媒体产品展示。

需求差异：尽管内勤系统和销售系统都需要使用相同的产品定义，但是它们对产品定义的视角却有差异。对于存储所有保单的内勤系统，你既需要老的产品定义也需要实际的产品定义。对于销售系统你只需要你实际销售的产品程序。一个产品定义知道更多的产品，包括那些正在开发中的和销售程序中尚未出现的，都需要为这些系统提供不同的视图。

 

方案

在产品服务器中封装产品知识。运行期间，在可移植的产品运行系统中封装它并且使用外观提供视图

结构

你在一个典型的产品服务器中会发现如下组件：

产品编辑器：为定义产品的用户提供易于使用的界面。产品定义可能稳定于产品模型中。

固定的产品定义：代表你的产品的固定商务对象。如何最好地组织这些对象将会在产品树和对象事件赔偿两处予以讨论。

前两个组件也可能被组织在一个普通的面向对象三层结构中。

 

图3 产品服务器的结构

商业对象代表了稳定的产品定义，很少被移植。因此我们需要更多的组件。

发生器：负责从稳定产品定义中产生可移植的代码。

产品运行时系统：可以运行在OS/390上以及Window平台上，负责解释上面产生的代码。有些系统采用ANSI C为产品运行时系统编码以保证系统的可移植性。

如果你想在产品运行时系统中提供一个非常窄的接口，但是又不想处理过多的原始界面操作，或许你可以实现：

前端部件：为你的产品定义系统提供不同的视图

 

图4 销售员膝上电脑

所谓的产品服务器包含所有组件的事实并不说明所有这些组件必须运行在单个机器上，也不意味从客户/服务器系统模式来说产品服务器就是服务器。

要了解这一点请看图4：销售系统的配置。销售对话框通过前端部件使用产品运行时系统。而所谓的产品服务器的剩余部分，产品编辑器，产品商务对象，生成器可能运行在不同的机器不同操作系统和技术架构。

结论

保险系统使用产品服务器来提供优良的灵活性和平台独立性。相对于只使用活动对象模型，使用产品服务器可以在你的销售系统、网站等等为同样的产品定义赋予不同的视图。

缺点在于创建过程。与使用活动对象模型和反射相比，使用产生器具有某些缺点。但是这个缺点可以在一个方面为某种事实所弥补。通常正在编辑的时候，你并不希望你对产品的修改同时为其它地方所见。保险产品就如同代码一样也需要经过测试，发布，版本化。一个系统使用一个简单的活动对象模型，产品开发，测试则笼统模糊，生产没有效率，容易陷入困境。

其它结论是：

平台独立性：通过使用一个可移植的产品运行时系统来达到平台独立性

良好的接口设计：为产品运行系统设计一个非常窄的接口或许能取得良好的接口设计

最优用户界面设计：包含某些产品的专门知识，并涵盖其趋势。这是不凡的设计

需求差异：可以通过在产品运行时系统使用不同前端部件来兼容需求差异

实现

通过在树状层次构架中使用活动对象模型，可以把产品编辑器当作普通面向对象应用来实现。

相关模式

要实现产品编辑器，你应该使用产品树，而产品树用对象事件补偿模式组织。你还需要把表格系统和规则系统集成到其中。运行时系统可以采用实现虚拟机所采用的模式。前端部件用来为产品定义提供不同的产品视图。

要为产品编辑器实现产品商务模型，可以采用活动对象模型和发射。

已知应用

采用产品服务器的这种思想可以在许多保险系统中找到。VP/MS中可以看到部分，如采用CAF的产品定义。EA Generali实现的两个项目也包含了产品服务器的思想：KPS/S，一个正在开发财产保险项目；Phoenix，一个快要完成的人寿保险系统。

模式：规则系统

举例

假如你实现了一个产品编辑器，这个产品编辑器允许你定义产品结构，那么你需要一种机制来为树的节点元素从一种属性导出另一种属性，比如评估保单。

问题

你如何来实现真实性检查或者对产品树进行政策评估这样的功能？

动机

系统管理员的使用：如果你打算让你的系统管理员不编码就定义新产品，你必要提供一种解释语言，这种语言能够把产品属性，性能估计连接起来并且可以实现表格查找。如果你按照这个想法去开始你的工作，你很早就会发现这需要一种全新的编程语言才行。有关这些的进一步讨论可以参看WWW上的《通过编程实现可定制》" (http://c2.com)。那里的讨论与《硬编码对脚本编程语言》相似：一般硬编码（尤其在Smalltalk）比试图在Smalltalk上再建立一种Smalltalk容易。

代价：草率地开发一个规则系统是昂贵的冒险。给一些系统管理员培训Smalltalk一般比为他们开发一种可定制的编程语言代价少。另外我们知道，像Excel那样，按可以接受的代价来实现像公式解释器那样的功能也常常为系统管理员乐意接受。

追溯机制的完成：如果要建立一个规则系统，最好使之能够完成产品定义需要的所有属性导出，否则，你就得编程实现。

灵活性：对于像C++那样的编译语言，要编辑/编译/链接才能完成，对系统管理员来说一个Excel表单似乎灵活的多。

测试和调试产品：如果你要在你的产品定义中实现脚本语言一样的编码属性追溯机制，你需要一些其它编程语言环境，以及额外的工具，比如可定制调试器。

方案

建立一个类似于解析树中的语义功能的属性追溯机制，或者Excell表单中的单元计算，在运行时解释。

结构

参看图6：保险产品树。如同编译建造，你可以使用某种编程语言（如Lex/Yacc）为语义功能编制程序，或者你也可以用各种不同脚本语言定义一套完整的工具。

注意，这跟基于规则的系统，比如人寿保险中的风险评估系统，没有太大的关系。在基于规则的系统中，你经常可以看到专家系统（如以Prolog实现的）。我们这里谈到的规则系统在一个相当确定并且可预期的基础上实现商务规则。

结论

结论如同实现途径一样多种多样，究竟如何使用取决于你的动机。这些方面跟编程语言设计非常相似。这里给出一些示例，在我所知道的系统中，这些示例将要发生或者已经发生：

不完全规则定义语言：这种情况下，你将需要部分编码来完成属性追溯和定义，这样的结果是，相对它所提供的灵活性和可定制性，你付出了太高的代价。

超完全规则定义语言：这样一个非常复杂的语言容易出错并且相当昂贵。与其这样还不如使用解释性编程语言。

相关模式

需要相关模式来实现产品树。解释器和虚拟机经常用来实现规则系统。

已知应用

UDP一文勾画了如何用Smalltalk实现一个规则系统。VP/MS使用了一个版本，这个版本非常像电子数据表。Phoenix混合使用了硬编码和规则。

 

保险系统的产品模型

本文包括了一些模式，这些模式在产品服务器建模保险产品非常有用。这些模式是：产品树和对象事件赔偿。建模产品有很广泛的方式，对象事件赔偿仅仅只是其中一种。参看[Sch+96]可以获得更多信息，或许将来我们还要从中挖掘更多的信息应用到工作中。

模式：产品树

示例

你决心顺着保险价值链去建立一个产品服务器，在设计之前，你需要知道如何建模保险产品。

问题

什么是好的保险产品展示呢？

动机

除了驱动保险应用的常规因素，下列因素也需要考虑：

涉及用户同灵活性和通用性的对比：你需要采用用户能够理解的模型，而工程上使用的是非常难以理解的抽象数据模型。

重用和灵活性：好的方法能够在程序模块级别上实现重用。理想的方式是在产品开发过程中形成模块库，这些库可以直接重用或者经过组合以形成新的产品，就像制造工业一样。

方案

把你的保险产品建模成一颗树，就像平时组装自行车一样。

结构

 

图1 保险产品树(P15)

* 树的节点是产品或者产品组件;
* 每个节点用属性描述;
* 加入保险费计算功能作为导出规则，模拟编译器解析树的语义功能，或者写你自己的规则系统（参看Ralph Johnson的关于UDP的论文）。

结果

产品灵活性：一旦你明确了保险产品的构成元素块，设计和建模新的产品将变得容易和直接得多。

用户包含：开发产品服务器的实际工作显示了，具备一些额外知识的领域专家就能够建模产品树。

重用：一旦你定义了产品构成块，你就能在无论是新的还是现有产品中重用。

实现

严格实现这个设计还需要作出一些额外的设计考虑。产品树建模并不意味你能最好地组织这些产品树，也不意味你有最好的产品模型设计。请参看对象事件赔偿获取一些技巧。

通常你会用组合模式和Type Object模型将保单建模为产品实例。把导出的属性和这些模型结合起来就可以得出在Ralph Johnson和Jeff Oakes正在进行的工作中描述的完整的框架。

有两个非常基本的替代方式用于设计产品树的运行时系统

1.第一种方式假设产品编辑者工作在同一个数据库上，并且在生产性系统中当作活动实现来建模。这将得到Ralph Johnson和Jeff Oakes所描述的活动对象模型。

2.第二种方式假设开发空间和产品空间严格分离，这就是产品服务器方式。

变种

经常构建模块，那么就会有确定的属性用来共享。考虑下面两个产品元素：养老金组件和风险人寿保险，你会发现两者之间投保人都是相关对象的属性。在一个产品集合中要结合这两者就需要确定两个投保人的属性。这就产生了DAG表示（直接非循环图表）而不是树型表示。

相关模式

模式是根据保险价值链实现系统的关键。前面已经讨论过用来实现这种系统规划的模式。

已知应用

这种方法在保险业中非常常见。比如CAF的VP/MS产品定义系统。EA Generali开发的两个系统，如正在进行的财产保险系统KPS/S和快要完成的人寿保险系统Phoenix也都包含产品服务器的思想。其它保险公司也正在或者已经采用了这种方式。

进一步阅读

模仿制造业部件分散制造的原理来建造保险系统的思想已经由Paul Schonsleben和Ruth Leuzinger在一定层面讨论过了。

Ralph Johnson和Jeff Oakes讨论了如何用面向对象方式实现同样的系统。

 

模式：对象事件补偿系统模型

示例

你已经决定把你的保险产品建模成一个产品树，于是你开始工作了，你的同伴与你合作。当你把由不同人建立的两个系统结合到一起，你发现单产品树范例就不允许你随意重组从前的构造块。

问题

使用树状结构来建模保险产品，有什么好的方法呢？怎么样在建模保险产品时进行好的抽象呢？

动机

质量和可理解性：多种编程语言的存在，仅仅一种方法实现保险产品树会带来模型结构不良，不易理解，从而导致维护困难。相似的情况在许多领域也存在，都有一个相当高层的抽象的建模范例，比如对象建模，实体关系建模等等：你需要一些规则或者领域分析模式用以缩小解决方案的范围，另外还需要一些规范用以减轻建模难度。

重用：也要求建模规范。你的保险产品组件建模得越规范，以后在其它产品中重用就越容易。

方案

使用对象事件补偿模式建模保险产品。每个保险产品确保一个或者多个保险对象。如果那个对象相关的特定事件发生了，客户有权申请一定的补偿。

结构

你的产品树应该是如下模样：

 

图2 按照对象事件补偿模型组织的产品树

每个对象具有递归性：一个对象可能包含其它对象，一个产品可能包含其它产品，等等。但是这个树型结构的基础是十分稳定的。

结果

生产力和重用：如果每个开发者都坚持相同或者相似的建模模式，那么大家对产品结构可以取得共同的理解，这样将可以获得更高的生产力和更好的可重用性。

相关模式

对象事件补偿模式只描述了高层产品结构，这里需要更细化的模式用作诸如属性的定义，语义规则，如何查表等等。要挖掘这些模式，你需要参考一些由不同人或者不同公司建立的产品模型。由于产品模型是竞争的机密信息，我们需要较长的时间才能等到它公开。

进一步阅读

这个主题上没有书籍也没有文章予以介绍，但是像CAF这样的产品提供商提供培训和相关课程资料。

 

保单

本文主要来介绍如何实现保险保单，这一章只有一个模式，产品实例化保单。

模式：实例化保单

别名

镜像部件列表

示例

很高兴你刚完成了你的产品编辑器。你用了组合模式来实现它，并在界面上使用了分层的列表框。你已经在叶结点键入产品数据，对象事件补偿也加入了一些。

问题

如何表示保险产品保单

动机

一般动机：最大的动机是驱动保险应用设计的动机。关键是灵活性。如果你不能在后勤系统处理新产品，最好的产品服务器也是无用。因此，处理保单的系统应该像产品定义工具一样灵活。

方案

创建产品保单实例，并用Type Object模式来完成，那么保单就能够反映树型产品定义。

结构

 

图1 作为产品实例的保单

一些产品实例被当作原型保存在保单工厂中。用真实的数据实例化这些原型就形成了保单。

结果

· 灵活性：如同最具反射能力的系统一样，你将获得一个非常灵活柔性的系统，这个系统能够使你同产品定义保持同步。

· 可移植性：你必须提前考虑到系统的可移植性。假如你用这个模型在一台主机上实现了活动对象模型，如果系统不具有好的移植性的话，你可能需要花相当多时间在销售员的膝上电脑实现同样的系统。

· 性能：如果你不经常注意性能的话，就如同多数发射系统一样性能可能变得很差。如果你有一个6层深度的产品树，并用一个本地数据库存储，要想正常工作，你需要提取比如说100条数据库记录才能做到。要避免这种情况，你需要建立一个具更智能的数据库映射。

变种

实际上，你可以找到两种主要的模式变种。

单一数据库系统：这种情况下，产品数据定义系统和保单组件在单一的一个数据库实现。你可以使用产品编辑器在保单工厂中创建新的产品原型。这种情况下，保单工厂也是产品定义系统的数据池。

这种方式的不足：

过分紧密地耦合了产品开发和实际产品的生产。优点是，一旦你定义了产品，这个产品就马上可以在产品系统中使用（对于测试和发布来说，这实际是它的缺点）。

多数情况下，没有办法在一个销售员的膝上电脑上使用单一产品定义数据源。

如果天真地坚持这种商务对象，你会陷入巨大的性能麻烦。

去耦方法：中央保单管理系统和保险销售系统共用一个产品服务器：使用产品服务器，把保单工厂（参看图2）作为产品运行时系统的客户端，并且把产品定义对话框从图2移去。

这种方法的缺点：实现起来更复杂，不直观，并且有些冗余。

优点：产品定义系统与保单系统分离，有更多调整性能的余地。你可以建立其它客户端，例如保险销售系统。

 

图2 单一数据库产品定义和保单管理系统

相关模式

这种模式是组合和Type Object模式在特定环境中的递归使用。另一种叫法是活动对象模型，它是发射模式的变种。

你在产品定义系统中为产品树组件指定类型是第一次使用Type Object。第二次使用是将一个复杂的树型实例（产品树实例）当作保险保单原型（参看图1）。

使用复合类型建造产品树和保单树。一个具体的保单树是一种产品树。

已知应用

Generali Munich的PVS就是在一个主机上使用单一数据库。UDP系统虽然没有明确说使用了哪种变种，但是看起来更像使用单一数据库。在Generali 的Phoenix项目也使用了单一数据库的变种。

我们还没有看到去耦的实现，不过很可能我们后面的某个项目中就会实现它。

进一步阅读

关于在建造产品树方面的面向对象设计考虑的具体讨论，可以参考Ralph Johnson和Jeff Oakes的文章，他们给出了这个主题深层次的模式。本文就如何用解释器计算导出属性给出一个深层的讨论。

分布式保险系统

在一个典型的保险系统中，在某一假设下，你或许会发现有些子系统并非必要。这个假设就是，假想我们拥有一台虚拟超级计算机，它没有网络带宽的限值，它能够使保险组织中的每个人无延迟地访问而且无需任何费用。不幸的是，这样的系统不存在。现在，我们将搜寻能够处理分布式应用，比如保险销售系统和表格系统的模式。

模式：保险销售系统

示例

你有一个灵活的后勤办公系统，你想要一个膝上前端办公系统使得你的销售代表能够帮助你更好地销售通过产品服务器定义的产品。

问题

如何在销售代表的膝上电脑上构造销售系统的结构？

动机

除了上述一般动机，你还要注意下面一些特殊动机：

系统发布：理想的保险系统应该具有一个分布式虚拟框架，这个框架提供给销售员一个图形用户界面，销售员只要轻轻按动手指就可以获取公司必要的信息。这个系统不能太贵，因为在内存存取，文件和数据库I/O，网络I/O上我们有不同的性能。毕竟没有免费的无限带宽。

低投资对比个人市场表现：今天你也许能够以较低的价格买到销售标准金融产品的系统。但是这并非你所要。你需要的是个人市场的表现而不是标准产品，你需要的是更快得到它们。

上面提到的一般动机详细讨论了这一点。

灵活性：缩短产品创新周期需要一个非常灵活性的系统。

重用和单一源：为了保证费用限值，避免多源带来的冗余问题，你需要一个单一的代码库，并在前端办公系统和后勤办公系统做到最大程度的重用。

创新方面：说“我也能够”，你无法吸引你的客户。你需要一个地方来在你的应用中插入革新的部件。

 

方案

首先，把所有为销售产品和提供服务而需要的东西都放在销售员的膝上电脑上。准备得越多越好。然后把这些功能划分为任何保险公司通用的shell，一个合作伙伴子系统，一个销售记录，一个联系子系统，以及把投保转换为保单的核心销售部件。喜欢的话可以增加一个多媒体销售部件。把系统脱机连接到中央处理系统单元以便处理投保和交换客户数据。

结构

 

图3 一个保险销售系统应用的结构

系统中各个组件具有如下责任：

通用Shell（外壳）提供基于PC的面向对象方案，如MVC框架、保持框架所需要的所有基础部件。还提供你数据复制，通用应用驱动。通用应用驱动让你方便地插入新的应用。

合作伙伴子系统：允许销售代表收集关于你的客户，客户的金融状况，客户的兴趣爱好信息。所有的措施是使销售平滑，能够从目前群体中有选择地行动。一个合作伙伴子系统一般比后勤办公系统为销售员提供多得多的功能。

销售记录：允许你跟踪你的伙伴从你这里或者其它公司那里已经购买的产品。个性化程度取决于你想提供的分歧分析组件的质量。

联系子系统：这个组件用来跟踪你的约会，计划定制等等。

销售：提供对话框使得你能够依据一定格式同你的客户一起计算保险单。这些对话框是面向产品的，典型的是使用产品服务器。

分歧分析：一个典型的个性化部件。它能够收集客户的信息，并且把客户已有的产品同总需求作一个比较，最好列出客户可能从你这里购买的产品。

革新部件：任何能够帮助你销售产品部件的，比如多媒体产品信息，都将使你的分析受益。

示例

已经知道了使用外壳的实现方法，现在你正联系一个卖主，启动一个项目，那么你可以把你产品和创新的想法放入外壳。

结论

跨越网络的性能：离线系统优点是在性能上，缺点是无法存取企业所有的数据。你需要销售你的产品而非想像在POS上的最大功能。

· 功能：模式描述了你今天在POS看到的系统，而没有描述你将来会看到的系统——我们将看到更多的功能移到POS。这是一个实在的模式而不只是对未来的展望。

低投资对比个人市场表现：这种模式考虑到在相对低的投资下争取好的个人市场表现（产品和革新部件）。这个模式也为作为插件的革新预留了空间。

· 灵活性：在销售每个产品部件中，产品服务器提供了简短的产品革新周期。

· 重用和单一源：可以通过一系列方法达到重用：首先当你不打算重写一个单独的伙伴或者联系应用系统时，可以使用这种模式。其次，可以使用产品服务器。另外一个提高重用的好主意是在部件层次和商务对象层次使用组件的概念。

相关模式

一个销售系统经常使用产品服务器运行时组件，以及表系统和规则系统。

已知应用

有好几个定制产品的示例支持这种模式。例如NSE开发的FINAS系统(www.nse.de)，CAF开发的SILVA系统(www.caf.de)。一些个性化产品如EA-Generali的KUBIS或者Interunfall的AdiPlus，都是相似的。

 

模式：表系统

示例

保险系统，尤其是那些处理产品的保险系统，需要许多表格。这些表格用来提供关键字的合法集合，提供诸如从区域到相关利率映射实现自动保险保单。

问题

你如何提供灵活而且满足需要性能的系统，使得能够顺利存取那些大多数是只读的数据，能够把数据组织在表格中，提供给领域专家随时更新。

动机

性能对比冗余的功能：假如你要实现另一个比关系数据库性能更好，只是功能少一些的数据库系统，你就在制造系统的冗余。相反，提供一个本地只读数据库，它有非常好的存取速度，考虑到后期维护代价，这样的组件重复是完全值得的。

数据分发的投资和代价：在一个中央数据库中，你完全没有数据重复问题。而如果你有另外一个使用文件的数据库，系统在线时使用主存，离线时使用本地存储，这样就存在数据重复的问题。因此你需要在数据分发方便性和数据存取效率上权衡。

测试和新产品的分发：定义产品就象编写代码一样。在一个保险应用中，表中数据是定义的数据，因此必须像对待代码一样对待它：它们需要版本化，需要测试和发布过程代码。如果你想在一个中央数据库系统提供这种功能，无论如何你都得创造些额外的过程。

历史数据需要：保险系统非常依赖于历史数据。由于存在内部审核过程，你需要能够再现任何历史状态。更糟的是一旦保单发生变化，你必须能够在任何时间再现任何与保险合同相关的现在的和历史的数据。这就是所谓的二维历史。实际上没有哪个数据库能够天生就支持这种功能。

方案

使用一个表格系统，表格是这个系统的唯一数据提取层。这些表格驻留在运行时的主存中。

结构

对于客户，一个表格系统提供了一系列表格来存储中间抽取数据。

 

图4 保险应用中的包含了头衔合法集的表

对于一个表格系统，你需要一些基本部件。

· 一个表格编辑器，用于管理员输入合法数据。

· 需要分发到所有客户的表格。它们通常保存在文本文件或者其它文件系统格式中。

· 当客户系统启动时，需要把所有的表格装载到内存。如果客户系统没有足够的内存转载所有的表格，它可以使用缓存机制和交换机制只读取所需的表格。

结论

性能：表格系统的访问速度远远优于数据库系统（前者是纳秒级，后者是微妙级）

冗余和代价：在你的主存安装一个经过修正的数据库，不得不开发为数据分发，测试，编辑开发程序。一个表格系统不便宜。

变种

市场上可以找到表格系统，这种表格系统要么能够处理历史数据要么不能处理。

相关模式

有关历史数据的模式参看Fowler的分析模式集合：历史映射模式和二维历史模式。要想真正实现一个系统，目前给出的细节还不够。我们自己的Phoenix框架包含了一个实现，但是一个设计并非一个模式，而且我们的确知道仅有的另一个实现，但非常困难。

已知应用

Table/23是欧洲保险市场主机和客户系统使用广泛的产品。VP/MS包含了一个表格系统，这个系统作为产品服务器的一个组件（但是没有包含历史数据）。两个产品都使用在多个保险系统中。VAA包含了一个自己的表格系统规范，该规范使用在保险商务中。

 

 

经常使用的模式和策略

下面列举了本文中经常使用的模式:

活动对象模型

无需编程你就可以采用活动对象模型。与此相似的概念是元系统或者反射

业务过程重组

你会经常把实现一个新的保险系统和业务过程重组努力结合起来。有关BPR的模式表述参看Bee97

组合模式

组合模式是建模产品树时要使用的模式。

解释器

为了实现一个规则系统，你需要创建自己的解释语言，这个时候最常用的就是解释器模式

反射

反射模式以模式的形式描述了元系统。要实现产品的柔性，你有必要使用活动对象模型。

Type Object

Type Object模式可以被用来连接保单和产品，方法是通过建造产品保单实例。产品树的递归结构多数情况是复合得到的。

虚拟机

如果你建立一个产品服务器，你或许需要解释你的产品定义。这时你就可以用一个虚拟机从运行产品（产品实例是政策）来去耦产品定义（编程）

整体部分

组合模式是整体部分模式的一个变体。因此，从这个意义来说，无论何时使用组合模式，就是在使用整体部分模式。

 

感谢

 

我要感谢我的PLoP导师 Richard Helm，感谢他给了我许多有用的提示和建议。

 

 

 

附：整理说明:

1．   作了部分格式的整理

2．   原译文漏译了几句，作了补充。

3．   调整了部分原译文，如:

policy: 保单（原译文是策略或政策参数）

claim: 理赔（原译文是投诉）

interface: 接口（原译文是界面）