| 编辑推荐: |
本文总结了DMN基本概念,
DMN的范围和用途, 三种DMN的用法：
人工决策建模，
自动化决策需求建模，
实现自动化决策
等等，希望对您有所帮助。
本文来源于cnblogs，由火龙果软件Delores编辑，推荐 |
|
背景
DMN的目的是提供一个模型决策结构，从而使组织的策略可以用图形清晰的地描绘出来，通过业务分析准确的定义，使其自动化（可选地）。
这里讨论的决策应用主要针对以下两种不同视角的建模标准：
业务流程模型（如BPMN）业务处理过程中，在决策发生的地方通过定义特别的任务或活动描述决策是如何协作的。
决策逻辑（例如，PRR，PMML）可以用来做单个决策的具体逻辑定义，例如业务规则，决策表，或可执行的分析模型。
然而，一些开发者（包括提交小组成员）发现用以上两种角度的建模标准做决策应用，其特有的内部结构都不太方便。DMN将提供第三个视角："决策需求图"形成业务流程模型和决策逻辑模型之间的桥梁：
业务流程模型将在业务流程中定义决策发生所需的任务
决策需求图将定义决策逻辑中的任务、相互关系、以及前提条件。
决策逻辑将定义足够详细和必要的策略，以允许验证（和自动化）。
结合在一起，决策需求图和决策逻辑可以提供一个完整的决策模型，通过详细指定处理任务的决策过程，为业务流程模型做了很好的补充。这三个方面的模型间关系如图1所示。
这个结果将业务流程中业务规则的角色和分析模型、模型的交叉验证、"TOP-DOWN"流程设计和自动化和决策自动执行等一系列详细建模联系起来。（通过BPMS调用一个部署在BRMS中的决策服务）
虽然图1显示了一个业务流程模型和决策模型之间的联系，其目的是说明DMN和其它标准之间的关系，但是必须强调的是DMN不依赖于BPMN，他们是两个层面的－决策需求和决策逻辑－它可以单独使用或者配合使用，决策领域模型没有任何一点引用或参考业务流程。
DMN提供了决策需求和决策逻辑的建模结构：
对于决策需求建模，它定义了一个决策需求图形（DRG），包括一组元素和它们的连接规则，以及相应的符号概念：决策需求图（DRD）。
对于决策逻辑建模提供了一个名为FEEL的语言用来定义和组装决策表、做计算、if/then/else逻辑、简单的数据结构，并使用标准语义的可执行表达式来调用Java和PMML定义的外部逻辑。另外它还提供了逻辑决策标志（"box表达式"）允许将决策逻辑层通过图形绘制，并关联决策需求图的元素。这些结构之间的关系示于图2。
再次申明，虽然图2描绘了这些决策建模结构是相互关联的，但它仍然可以单独或者任意组合使用。例如，可以仅使用DMN画DRDs，或仅定义决策表，或仅写FEEL表达式。
基本概念
决策需求层
"决策"这个词通常有两种定义：1. 根据给定的条件从候选项中选择某项的过程；2. 某个条件被选择。在该规范中，我们采用前者的用法，一个决策是：从多个输入值中判定一个输出值（已被选择的条件）的行为，通过逻辑定义输出是如何从输入中判定的。决策逻辑可能包含一个或多个业务知识模型，它们通过业务规则，分析模型，或其它形式封装业务的专业知识。这是所有的决策模型构建的基本结构，示于图3。
官方可以定义决策或业务知识模型，这可能是（例如）领域专家负责定义和维护的，或从业务知识模型派生的源文档，或是成套的测试案例，他们必须与决策一致。这些被称为知识源（参见图4）。
一项决策也被叫做"依赖"，它的输入项用以决定它的输出项。输入项可以是输入的数据，或者是其他决策的输出。（在这两种情况下它们可以是数据结构，而不是仅仅简单的数据项。）如果"决策1"的输入项包含"决策2"的输出项，决策1"依赖"决策2。决策因此可能被连接成一个网状，这称为决策需求图形（DRG），通过它可画成一个决策需求图（DRD）。
一个DRD显示了一组决策如何彼此依赖，对输入的数据，和对业务知识模型等。如图5所示一个只有2个决策的简单DRD例子：
一项决策可能需要多个业务知识模型，一个业务知识模型又可能需要其他多个业务知识模型，如图6显示。这将允许通过组合不同领域的业务知识的复杂决策逻辑可以被模型化，并在不同情况下使用提供了替代版本的决策逻辑。
DRGs和他们作为DRDs的符号，将在下一章详细说明。
决策逻辑层
决策模型的决策需求层作为一个组件是可以被描述的，他们是宏观的，只用于业务概念。描述这个层次通常是完全面向决策领域的业务分析，以识别所涉及的业务决策、他们的相互关系、领域的业务知识和所需数据，以及业务知识源。使用决策逻辑，相同的组件可以进行更详细的说明，用以获得一套完整的业务规则和计算，以及（如果需要的话）允许决策完全自动化。
决策逻辑也提供一些附加信息，比如有关如何在决策模型上显示元素。例如，一个决策表的决策逻辑元素可以指定是否显示规则的行或列。用于计算的决策逻辑元素可以指定按照垂直或水平排列。
决策需求层和决策逻辑层之间的概念的对应关系会在以后描述。请注意，在下面的图，如在图1和图2中，灰色的椭圆形和虚线画出仅出于介绍目的表现出在不同层次的概念之间的对应关系。他们不是DMN符号的一部分，他们将在DRG and DRD符号、决策表符号和FEEL表达式符号中定义。据设想，这个实现将提供模型层次之间移动的能力，如"打开"，"向下钻取"或"放大"，但DMN不指定这个应该怎么做。
在决策逻辑层，DRG中的每一个决策的定义是使用的值表达式，它指定决策的输出是如何通过输入确定的。在该层次，决策被认为是表达式的执行。值表达式可以使用boxed表达式来标志，如图7。
以同样的方式，在决策逻辑层，一个业务知识模型的定义是使用一个值表达式，它指定一个输出是如何通过一组输入计算出来的。值表达式可以被封装成函数，可从在决策值表达式中调用；业务知识模型就是这种函数功能的例子（但决策逻辑可能还包含业务知识模型不具备的功能）。解释业务知识模型像是DMN中的函数功能，如图6中组合的业务知识模型，具有清晰的功能性组合的语义。业务知识模型的值表达式可以使用box函数来标志，如图8。
一个业务知识模型可以包含的多个决策逻辑，能够被表示为一个函数。这将使许多现有的决策逻辑建模标准（例如，业务规则和分析模型）可以导入到DMN。决策表是业务知识的重要形式，在DMN中明确支持。这种业务的知识模型可以利用决策表进行标志，如图所示
在大多数情况下，决策的逻辑被封装成业务知识模型，那么业务知识模型是如何调用决策相关的值表达式，其结果是如何调用组合计算输出的。该决策的值表达式也可以完全通过自己指定如何从它的输入决定输出，而不调用业务知识模型：在这种情况下，没有业务知识模型与决策相关（不论是在决策需求层或在决策逻辑层）。
在DMN中，决策逻辑是使用表达式语言来定义的，将在FEEL表达式语言章节中描述详细描述。
FEEL：the Friendly Enough Expression Language
DMN的范围和用途
为一个业务或者组织在理解和定义决策时是通过业务分析来设计决策模型的。这样的决策是一般操作决策用于每天的日常业务流程，而不是较少的规则或表示事实的战略决策。
以下三种DMN的用法：
人工决策建模
自动化决策需求建模
实现自动化决策
人工决策建模
组织中的人员可以使用DMN来对决策进行建模。人工决策可以分解成一个由相互依赖的决策组成的网络，模型使用DRD。这些在DRD中的决策可能会使用自然语言来描述，而不是决策逻辑。
知识来源可以定义对：人（如经理）、监管机构（如监察员）、文件（例如，一项策略文件）或立法（例如，政府法规）等决策模型的治理。这些知识的来源可以联系起来，例如，一个决策是由：一组监管机构定义的规定和公司经理维护的策略文件 组成的。
业务知识模型可以用来表示在决策时提取业务知识的区域。这将允许DMN被用作对知识管理需要正式定义需求的工具。业务知识模型可以被联系起来，以显示知识之间的相互依赖性（方式类似于使用Knowledge Structure Mapping）。知识的来源可以关联到业务知识模型用来表达业务知识是如何管理和维护的，例如，公司策略文件（知识源）中定义了一组业务策略（业务知识模型）。
在某些情况下，为建立一项决策需要尽可能去定义特定的规则或者算法。它们可以使用在DRD中相关的业务知识模型进行决策逻辑建模（例如，业务规则或决策表），无论是描述形式的（记录下决策在当前是怎么做的，或者是到了特定时机他们是如何做的）或是规范形式的（定义出决策应该如何执行，或者将在未来执行）。
DMN中的决策模型可以被映射到使用BPMN建模的业务流程中的任务或活动。宏观的来看，协作决策任务可以映射到一个DRD中一组决策子集，它代表一组或一个部门的整个决策行为。从细节来看，他可以建立依赖模型在使用BPMN协作的单个或者一组中决策：在决策中的每个参与者是通过协作图中独立的池（pool）来表示的，在决策模型中是独立的DRD。那些DRDs决策映射到池中的任务，DRD中的输入数据是映射到消息中的内容，在多个池之间传递。
BPMN和DMN的结合使用提供了一个图形化的语言，用于描述一个组织内部多层次的人工决策，从业务流程中的活动到决策逻辑的详细定义。在此背景下DMN模型将描述协作组织决策、治理、以及他们的业务知识依赖。
自动化决策需求建模
使用DMN为自动化决策需求建模是类似于人工决策的，但它完全是指令形式的，而不是描述形式的，并且有更偏重于具体的决策逻辑。
决策全自动化，决策逻辑必须是完整的，即能够对任何可能的输入数据的值提供决策结果。
然而，部分自动化是比较常见的，一些决策依然是人工进行的。人工和自动化决策之间的相互作用可以用上面提到的协作方式建模，为人工和自动决策机分别设置独立的池，或更简单的分配决策到业务流程模型里的独立任务上：人工决策使用人工任务，自动决策使用业务规则任务。因此，举例来说，一个自动化的业务规则任务可能会决定将某些事情交给人工审核；自动化任务的决策逻辑需要指定完整，但审核者的决策可以不指定。
一旦一个DRD决策映射到BPMN流程图的任务上，他将可以通过两个层次的模型来验证。例如，它可以验证在DRDs中所有的输入数据是由前一个流程任务提供的，并且该业务流程在后续的任务和网关中使用了该决策结果。DMN模型化了决策和业务流程之间的关系，使得必须对业务流程完成做出的决策可以被识别，所以可以指定具体的决策任务执行决策。在DMN1.0中没有提出正式的映射从DMN ItemDefinitions或DMN InputData到BPMN的数据对象上，但实现可能包括在某种情况下检查映射。
总之，BPMN和DMN可使自动化决策需求规范化，以及在业务流程中它与人工决策的交互。这些要求可在任何详细级别来指定，或者在所有级别。业务流程模型，DRDs和决策逻辑之间的三层映射将允许通过基于模型的计算机辅助设计工具来支持这些需求的定义。
实现自动化决策
如果所有决策和业务知识模型充分利用决策逻辑规定，那么它就可以执行决策模型。
一种可能的情况是在BPMS（Business Process Management System）中调用一个部署在BRMS（Business Rules Management System）中的"决策服务"。一个决策服务封装支持DRD的决策逻辑，提供对应于DRD内输入数据和决策的接口。当调用并输入一组数据，决策服务将执行指定的决策并返回他们的结果。DMN中要求所有的决策逻辑是无副作用的，这意味着决策服务将符合SOA原则，简化了系统设计。
一个决策模型的结构在DRD是可视化的，可被用作规划项目实现的基础。具体项目任务包括：决策逻辑的定义（例如，专家归纳规则或者创建分析模型）和决策模型组件的实现。
决策逻辑表现为：封装在决策服务中的业务知识需要由专人长期维护，并使用特殊的"知识维护接口"进行决策。DMN支持有效地设计和实现知识维护接口：任何需要维护的业务知识应当在DRD中建立业务知识模型和相关的知识来源。DRD为所需的知识维护接口和使用者提供了一个规范，决策逻辑还指定了业务知识的初始化配置，便于维护。
其他决策逻辑更新需要通过常规分析建模。在DMN中的业务知识模型就像是一个功能函数一样，很简单的在决策服务中使用其分析模型：任何一个分析模型都能够表现成为一个功能函数，导入决策服务中后直接调用。
组合应用建模
上述三种情况并不是相互排斥的；一个大型处理自动化项目可能同时使用到DMN的三种方式。
首先，在现有处理中的决策是可以被模型化的，以确定当前的决策和涉及业务知识领域的全部范围。这种"AS-IS"分析提供了过程改进的基线。
接下来，该过程可能会重新设计，以有效地利用自动与人工决策，通常采用两者之间的协作（例如，使用自动计算人工决策者，或者使用决策支持系统推荐或限定使用者）。这样的重新设计包括：发生在每个处理任务、组织中的单个或者一组角色和职责的决策需求的建模。该模型提供了所需过程和决策坐标的"TO-BE"规范。
比较"AS-IS"和"TO-BE"模型会发现需求不仅仅是自动化技术，而是对管理的改变：其改变涉及到角色和人员职责以及为新的或者调整的业务知识做培训支持。
最后，"TO-BE"模型将被实现为可执行的系统软件。提供的决策逻辑是完全使用FEEL或者是其他扩展逻辑（外部定义的Java方法或PMML模型），决策模型组件可以直接用软件来实现。
DMN没有规定任何特定的方法用于执行上述活动，它仅支持使用他们的模型。
|
