对于非开发人员来说，不同的是计算机表达的逻辑与人类表达的逻辑有何不同。这是开发人员在设计软件时难以将用户需求转换为条件语句（规则）的原因之一。

了解一种语言意味着能够产生无数个以前从未说过的句子，并且能够理解以前从未听过的句子。对于我们人类来说，像汤姆这样的东西喜欢足球和煎饼是很自然的。对于非开发人员来说，将这些语句翻译成计算机语言所需的心理努力可能并不那么明显。如果我们真的将相同的陈述写入计算机程序，那么（对于机器而言）汤姆只有在吃煎饼时才能看足球时才会感到高兴。

因此，在编写软件时，您基本上所做的是将用户需求（使用人类语言描述的人类故事）转换为规则（使用计算机语言编写的条件结构）。在这样做时，你需要意识到人类口头逻辑和计算机语言逻辑之间的差异，这样你就不会意外地谴责汤姆在吃煎饼时只是在看足球时找到快乐。

由于计算机语言既包含命题逻辑（假设世界包含事实）又包含一阶逻辑（假设世界包含对象，关系和函数），人们可能会认为开发人员装备精良，只需要计算机语言。使他们能够编写将人类需求转化为代码所需的任何算法和条件语句（规则）。

我们认为它不是，主要是因为三个主要困难阻碍了开发人员 - 第一个困难是由逻辑的复杂性带来的，正如我们将在下面看到的那样。后续职位将涵盖第二和第三个困难（由时间和不确定性引起）。

现在，让我们更仔细地研究使用由条件结构组成的计算机逻辑构建软件应用程序的过程。

布尔代数 是数学和机器的语言（相当于命题逻辑），并且具有精确且定义明确的结构或构成其词汇的“机器单词”。

那么，让我们看看我们如何阅读这个表：

例如，德摩根定律说明如下：“a和b”的否定等同于“不是a或b”， 而“a或b”的否定等同于“不是a而不是b”。

现在，想象一个软件程序，其中使用布尔代数的多个语句连接在一起。条件语句越长，通过单独阅读代码来测试其有效性就越困难。例如，这些陈述是等价的：（a <b ||（a> = b && c == d）），（a <b || c == d）。将这些语句连接在一起使得很难验证预期的逻辑。

验证预期逻辑的难度也可以通过称为圈复杂度的度量来衡量，Thomas McCabe于1976年提出。圈复杂度是通过程序源代码的线性独立路径数量的定量度量。尽管其作为软件质量测量的有用性受到质疑，但一般来说，为了完全测试模块，必须执行通过模块的所有执行路径。这也意味着更复杂的模块更难理解，因为程序员必须了解不同的途径和这些途径的结果。

正如电路设计者可能指出的那样，有一些方法可以简化数字逻辑，例如布尔简化和卡诺映射。K-maps可以提供帮助，但阅读代码的人也必须了解其意图，这对K-Maps来说并不容易。

所以我们已经看到，在设计软件时，逻辑的复杂性已经为开发人员试图将用户需求转换为正确的条件语句（规则）带来了两个主要障碍：

1. 首先，人们在使用口语表达规则时经常使用“错误”的逻辑陈述
2. 其次，即使这些结构被正确编码，如果条件语句太长，人类仍然很难检查它们的预期逻辑。

我们在本白皮书中论证，这是使用规则引擎可以解决的挑战之一。还有另外两个大的-一个是所带来的时间维度，另一个由不确定的概念。

使用规则引擎为物联网应用构建复杂逻辑

实际应用程序逻辑很复杂。它将不可避免地涉及比任何教科书示例更多的变量。复杂逻辑由高阶逻辑（HOL）构造组成，这就是规则引擎支持它们的重要原因。要管理它，规则引擎应支持以下内容：

1.结合规则中的多个非二元函数（观察）结果，超越布尔真/假状态

我们所做的就是结合多个非二进制状态。例如，在我们决定是否在周末进行城市旅行之前，我们考虑了很多因素。我们看一下天气（及其非二元状态的范围：小雨，暴风雨，雪，多云的天空，晴朗的天空）以及星期几（七个州），航班和住宿费用等。

2.处理规则中的多数表决条件

多数表决是指根据满足该行动的大多数条件采取行动，但不一定全部。例如，在医疗保健诊断系统中，这种能力很重要，其中一些但不是所有适应症都可能指向医学问题。其中使用的另一个例子是“线控飞行”控制系统，例如波音777电传操纵三重冗余计算机，它在三个处理器中复制计算，然后执行多数表决以确定最终结果。

3.基于先前观察结果处理函数的条件执行

基于先前观察的执行是：“如果机器发生故障，则仅检查资产数据库；否则，不执行任何操作。”

我们在本白皮书中论证，复杂逻辑和时间维度是规则引擎可以解决的物联网应用程序开发中的两大挑战。第三个是由不确定性的概念引起的，我们将在后面的文章中讨论。敬请关注！