| http://tech.ccidnet.com/pub/article/c291_a36325_p1.html 保险政策参数介绍 （1） |
||||
| 作者：Wolfgang Keller 著，liwenhua 译 发文时间：2003.01.10 15:47:42 | ||||
 |
||||
| 本文主要来介绍如何实现保险政策参数，并详细分析了险销售系统和表格系统的模式。
别名 镜像部件列表 示例 很高兴你刚完成了你的产品编辑器。你用了组合模式来实现它，并在界面上使用了分层的列表框。你已经在叶结点键入产品数据，对象事件补偿也加入了一些。 问题 如何表示保险产品政策参数 动机 一般动机：最大的动机是驱动保险应用设计的动机。关键是灵活性。如果你不能在后勤系统处理新产品，最好的产品服务器也是无用。因此，处理政策参数的系统应该像产品定义工具一样灵活。 方案 创建产品政策参数实例，并用Type Object模式来完成，那么政策参数就能够反映树型产品定义。 结构  一些产品实例被当作原型保存在政策参数工厂中。用真实的数据实例化这些原型就形成了政策参数。 结果 · 灵活性：如同最具反射能力的系统一样，你将获得一个非常灵活柔性的系统，这个系统能够使你同产品定义保持同步。 · 可移植性：你必须提前考虑到系统的可移植性。假如你用这个模型在一台主机上实现了活动对象模型，如果系统不具有好的移植性的话，你可能需要花相当多时间在销售员的膝上电脑实现同样的系统。 · 性能：如果你不经常注意性能的话，就如同多数发射系统一样性能可能变得很差。如果你有一个6层深度的产品树，并用一个本地数据库存储，要想正常工作，你需要提取比如说100条数据库记录才能做到。要避免这种情况，你需要建立一个具更智能的数据库映射。 变种 实际上，你可以找到两种主要的模式变种。 单一数据库系统：这种情况下，产品数据定义系统和政策参数组件在单一的一个数据库实现。你可以使用产品编辑器在政策参数工厂中创建新的产品原型。这种情况下，政策参数工厂也是产品定义系统的数据池。 这种方式的不足： 过分紧密地耦合了产品开发和实际产品的生产。优点是，一旦你定义了产品，这个产品就马上可以在产品系统中使用（对于测试和发布来说，这实际是它的缺点）。 多数情况下，没有办法在一个销售员的膝上电脑上使用单一产品定义数据源。 如果天真地坚持这种商务对象，你会陷入巨大的性能麻烦。 去耦方法：中央政策参数管理系统和保险销售系统共用一个产品服务器：使用产品服务器，把政策参数工厂（参看图2）作为产品运行时系统的客户端，并且把产品定义对话框从图2移去。 这种方法的缺点：实现起来更复杂，不直观，并且有些冗余。 优点：产品定义系统与政策参数系统分离，有更多调整性能的余地。你可以建立其它客户端，例如保险销售系统。  相关模式 这种模式是组合和Type Object模式在特定环境中的递归使用。另一种叫法是活动对象模型，它是发射模式的变种。 你在产品定义系统中为产品树组件指定类型是第一次使用Type Object。第二次使用是将一个复杂的树型实例（产品树实例）当作保险政策参数原型（参看图1）。 使用复合类型建造产品树和政策参数树。一个具体的政策参数树是一种产品树。 已知应用 Generali Munich的PVS就是在一个主机上使用单一数据库。UDP系统虽然没有明确说使用了哪种变种，但是看起来更像使用单一数据库。在Generali 的Phoenix项目也使用了单一数据库的变种。 我们还没有看到去耦的实现，不过很可能我们后面的某个项目中就会实现它。 进一步阅读 关于在建造产品树方面的面向对象设计考虑的具体讨论，可以参考Ralph Johnson和Jeff Oakes的文章，他们给出了这个主题深层次的模式。本文就如何用解释器计算导出属性给出一个深层的讨论。 分布式保险系统 在一个典型的保险系统中，在某一假设下，你或许会发现有些子系统并非必要。这个假设就是，假想我们拥有一台虚拟超级计算机，它没有网络带宽的限值，它能够使保险组织中的每个人无延迟地访问而且无需任何费用。不幸的是，这样的系统不存在。现在，我们将搜寻能够处理分布式应用，比如保险销售系统和表格系统的模式。 示例 你有一个灵活的后勤办公系统，你想要一个膝上前端办公系统使得你的销售代表能够帮助你更好地销售通过产品服务器定义的产品。 问题 如何在销售代表的膝上电脑上构造销售系统的结构？ 动机 除了上述一般动机，你还要注意下面一些特殊动机： 系统发布：理想的保险系统应该具有一个分布式虚拟框架，这个框架提供给销售员一个图形用户界面，销售员只要轻轻按动手指就可以获取公司必要的信息。这个系统不能太贵，因为在内存存取，文件和数据库I/O，网络I/O上我们有不同的性能。毕竟没有免费的无限带宽。 低投资对比个人市场表现：今天你也许能够以较低的价格买到销售标准金融产品的系统。但是这并非你所要。你需要的是个人市场的表现而不是标准产品，你需要的是更快得到它们。 上面提到的一般动机详细讨论了这一点。 灵活性：缩短产品创新周期需要一个非常灵活性的系统。 重用和单一源：为了保证费用限值，避免多源带来的冗余问题，你需要一个单一的代码库，并在前端办公系统和后勤办公系统做到最大程度的重用。 创新方面：说“我也能够”，你无法吸引你的客户。你需要一个地方来在你的应用中插入革新的部件。
|
