Policy :“谓词演算”

在讨论“Specification”的帖子里，讨论了简单“谓词”类，现在我们要更进一步的讨论
基于谓词演算的“Policy”,也就是通常所说的“业务规则”。

“预存三百元话费，送两百元话费”；
“买组合的两本书，可以打8折”；
“现在买智能手机，赠送一张1GSD卡”；
“对于个人和组织客户，提供不同的商品目录”
“对于使用超过一年的上网用户，可免费获取一个月的使用时间”

凡此种种，都可以归结为“谓词演算”，实际上，通常所说的“业务规则”都是基于
谓词演算的IF-THEN连接：即:
IF p THEN q
或者
p --> q
其中p和q必须是布尔表达式。
所以，“预存三百元话费，送两百元话费”就是“如果客户预存三百元话费，那么就送他两百元话费”。

上面的谓词演算IF-THEN连接其逻辑表达式完全等价于：

OR((NOT p),q)

所以：
“如果太阳比地球大，那么2 + 2 = 4”为true，因为q为true,所以不管p为true还是false,OR(false,true)为true
“如果太阳比地球大，那么2 + 2 = 2”为false, 因为p为true, (NOT p)就为false, q为false,所以OR(false,false)为false
“如果太阳比地球小，那么2 + 2 = 4”为true, 因为p为false，(NOT p)就为true，所以不管q为true还是false,OR(true,true)为true
“如果太阳比地球小，那么2 + 2 = 2”为true, 因为p为false，(NOT p)就为true，所以不管q为true还是false,OR(true,false)为true

待续

离散数学的实际应用，期待下文

实际上，在上面的讨论中，我们又混用了“类”和“实例”的概念。
“如果客户预存三百元话费，那么就送他两百元话费”同“如果太阳比地球大，那么2 + 2 = 4”稍稍有些不同。
因为前者是包含了“参数”的“命题函数”。前一句话更准确的表达为:

S=客户集合，x∈S,IF x 预存 三百元话费，THEN x帐户的话费预存金额 += 两百元

如果，我们让“命题函数”P(x) = “IF x 预存 三百元话费，THEN x帐户的话费预存金额 += 两百元”
我们就可以将“业务规则”表示为S=客户集合，x∈S,P(x)。

将上面的规则抽象一下得到：
“对于给定的集合S,x∈S,IF<条件> == true，THEN <应用效果>”

如果，使用OO来表示这种关系，我们得到下图：

待续

上图表明，一个Rule由两部分组成，一个是Condition，另一个是Action，他们通过共享式的聚合关联，因为
Condition和Action是可以复用的部分，可以提供给多个Rule使用。多对多的关系，还表明一个Rule可以包含
多个Condition和多个Action,这个不难理解，我就不举例了。

进一步，我们分析Condition和Action的构成，还是用上面的例子：

“IF x 预存 三百元话费，THEN x帐户的话费预存金额 += 两百元”

可以抽象为：

“IF <变量1> <操作符1> <值1>，THEN <变量2> <操作符2> <值2>”

我们可以把“<变量> <操作符> <值>”看作一个“陈述”，这就得到了下面的结构：

待续

似乎对于Rule元模型的描述已近完美。但考虑到应用Rule的场景。
因为我们既不希望Rule永久休眠，也不希望Rule被任何事件唤醒。
所以还需要将Rule同Event关联起来。这就得到了Rule的三角结构。

待续

构造一个高阶逻辑， 觉得仍然逃不出T1那个讲解函数编程的思想范畴， 期待亮点

目前有哪些企业应用，需要高阶逻辑呢？不说高阶，就二阶会有多少呢？
我认为，通常来说一阶逻辑已经够用了。

俺想要表明的方法，是完全OO的，函数编程，俺讲不来，至少目前讲不来。

有关函数编程，尽管看起来很美，但（全是瞎猜）根据现象反推回去，我认为必然存在某种未决的因素，横在它普及的路上......

其实你这个又何尝不是高阶逻辑? 用粗粒度得执行体对象代替程序设计语言中细粒度得语句?程序设计语言得构造也是这些逻辑, 只不过你得粒度更大, 然后组合,这个跟FP中组合得思想一致.
在业务逻辑狂复杂得系统高阶逻辑是非常有用得, 毕竟提供了分解->组合得好路子, 可以认为是粗粒度得程序设计语言, 我觉得跟你这个基本一致
JAVA这些类型得语言只不过FP太丑陋了, 很难普及, 只能模仿, 不过模仿带来得好处也是很明显得, 可以使程序得逻辑更清晰
函数编程是个好东西, 我觉得你要表达得思想在函数编程中已经完全体现了, 而且更优雅. 要不是python之类这些语言执行效率太低, 处理这些业务逻辑高度复杂得东西, 俺肯定首选.

T1牛帖:
http://forum.javaeye.com/viewtopic.php?t=7569&postdays=0&postorder=asc&start=0#39063

我觉得你这个倒可以做成一个高阶逻辑框架, 把程序语言构造得一些东西都加上, 什么list(actions)啊, for_each( start, end, functor)啊之类得操作统统加上, 没准为处理业务逻辑复杂系统得java人提供很大帮助

老大， 我看的有些糊涂了，感觉像在说一个rule engine，如果在event前加上factor。（可能是我思维定势了）