[发明专利]一种在计算规则中灵活增加条件项和计算项的方法和系统

说明书

技术领域

本发明涉及软件系统的计算规则的灵活修改。

背景技术

可灵活修改计算规则的方法和系统(参考图1和图2)已成功用于多种系统中，使当计算规则发生变化时，不用修改原应用系统201，只需修改计算规则脚本211就能改变原应用系统201执行的计算逻辑。但是当计算规则脚本211中的条件项和计算项修改范围超出了原来应用系统201提供的条件项和计算项数据接口组207和208时，就必须在原来的应用系统201中增加并实现新的条件项和计算项数据接口，就必须走开发、测试、发布的完整流程，还是耗时费力。当然计算规则修改到需要增加新的条件项和计算项的时候不多，主要集中在系统上线初期需求不特别稳定阶段，但还是希望找到一种方法能够在修改计算规则时彻底避免修改原应用系统，即使是需要增加新条件项和计算项也不要修改原应用系统。

可灵活修改计算规则的系统的工作原理就是，具体应用系统201中的计算模块204通过计算规则系统202提供的计算规则统一调用接口206统一调用计算规则模块210，这样具体应用系统201就只负责启动计算动作，具体的计算逻辑发生在计算规则系统202中。这样一来，实现计算规则调用接口206的、作为计算逻辑承载体的计算模块210可以很容易修改却不影响具体应用系统201，达到了灵活修改计算规则的目的。

计算规则由条件项和计算项组成，计算规则模块210中出现的条件项和计算项符号由具体应用系统201提供的条件项和计算项数据接口组207和208负责解释，并在运行时由这两类接口负责向计算规则模块210提供条件项和计算项数据。由此可见，具体应用系统201与计算规则系统202之间只通过计算规则接口调用206、条件项数据接口组调用207和计算项数据接口组调用208，这3类接口调用发生耦合关系，属于松耦合。

例如，原计算规则脚本A是：

其中，

有2个条件项：

会员积分MemberCumulativePoint

优惠活动CouponActivity

有3个计算项：

优惠金额CouponMoney

商品标价StandardPrice

折扣价BargainPrice

因此具体应用系统201应相应提供2个条件项数据接口和3个计算项数据接口供计算规则系统202调用。

在系统发布后，计算规则需求发生变化，新计算规则脚本B是：

这里，计算规则B与计算规则A比较，增加了一行“else if”条件，但其中的条件项没有增加，只是条件由“＞100”变为了“＞60”。还增加了新的积分数学规则2，但其中的计算项也没有增加，只是系数由原来的0.7变为0.6。在这种情况下，只需按新计算规则脚本B改变计算规则系统202中的计算规则模块110，原应用系统201不用任何改动就能按新规则B执行计算。可见图2所示的系统结构能够相当灵活地修改计算规则而不触动原应用系统。

但是，当计算规则修改程度大到需要用到新的条件项和计算项时呢?例如上例中，在修改完成后，计算规则需求又发生巨大变化，最新计算规则脚本C是：

这里，计算规则C与计算规则B比较，增加1个新条件项：

买家好评数PraiseNumberFromBuyer

还增加了2个新计算项：

优惠券数量CouponNumber

优惠券面值CouponParValue

在这种情况下，按传统方法，如果不修改原应用系统201，则新增加的这1个条件项符号和2个计算项符号将无法解释或编译。只有修改原应用系统201，相应增加这1个条件项数据接口和2个计算项数据接口才能使新计算规则C正常执行。可见图2所示的系统结构在计算规则修改程度大到需要用到新的条件项和计算项时也不得不修改原应用系统201。虽然大到这种程度的修改非常少见，并且在具体应用系统201中增加条件项和计算项数据接口也容易做到，但是毕竟还是修改了原应用系统201，还是要重新走测试发布流程。因此想到，对大到这种程度的计算规则修改，有没有办法避免修改原应用系统201呢？

发明内容

提供本发明内容是为了以简化的形式介绍将在以下具体实施例中进一步描述的一些概念。本发明内容并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所要求保护的主题的范围。