介绍

在DMN决策模型的决策依赖层面，由一个或多个决策依赖图（DRD）描绘出一个完整的决策依赖图形（DRG）。

一个决策域的DRG模型，显示了关键元素在其中的作用和他们之间的依赖关系，这些元素模型是：决策、领域业务知识、业务知识源和输入的数据。

决策元素是指：从多个输入中确定输出的行为，使用决策逻辑可以引用其中一个或者多个业务知识模型。

业务知识模型元素是指：以功能形式封装的业务知识，如，业务规则，决策表，或者某种分析模型。

数据输入元素是指：为一个或者多个决策使用的输入信息。

知识源元素是指：业务知识模型或一个决策的权威根据。

这些元素之间的依赖关系概括为以下3种依赖：信息，知识和权威根据：

信息依赖是指：数据输入或者决策输出被用于另一个决策的输入。

知识依赖是指：一个决策的逻辑调用的业务知识模型。

权威根据依赖是指：一个知识源依赖某个DRG元素，或者一个DRG元素依赖某个知识源。

这些组件被总结在表1，并在下一节会更详细的描述。

符号

DRD所有组件的符号汇总在表1中，并在下面更详细地描述。

表1

DRD元素

决策符号

在DRD中，决策表现为一个矩形，通常用实线绘制，如表1中的显示。图形上必须能够显示决策的名字，并且可以显示其他属性，如，问题或描述。如果显示，内容必须清晰的显示在DRD元素的图形中。

如果所列的数据输入选项是需要使用的（请见数据输入符号章节），所有数据输入的决策依赖必须列在决策标签下方，并且用横线分隔，如下图所示。列出的数据输入名称必须是清晰的显示在DRD元素的图形中。

决策的属性将在Decisions元模型章节列出。

业务知识模型符号

一个业务知识模型在DRD中用一个实线绘制的切角矩形表示，如表1中的显示。图形上必须能够显示业务知识模型的名字，并且可以显示其他属性，如，描述。如果显示，内容必须清晰的显示在DRD元素的图形中。

业务知识模型的属性将在Business Knowledge Model元模型章节列出。

数据输入符号

一个数据输入元素在DRD中用一个实线绘制的两个半圆边的矩形表示，如表1中的显示。图形上必须能够显示数据输入的名字，并且可以显示其他属性，如，描述。如果显示，内容必须清晰的显示在DRD元素的图形中。

当DRDs是大型或复杂的时候，用另一种方式来显示数据输入的依赖尤其有用：数据输入不用在DRD中画独立的标记元素，而是在需要他们的决策要素中列出。为方便起见在本说明书中，这称为"列表式的数据输入"选项。实现可以提供此选项。图11显示了两个等价的DRD，一个图形数据输入元素，另一个使用列表式的数据输入选项。请注意，如果一个数据输入元素没显示，则必须保证它列在所需的决策上（除非它被故意隐藏，在后面讨论）。

业务知识模型的属性将在Input Data元模型章节列出。

知识源符号

一个知识源在DRD中用一个实线绘制的由三条直线和一条波浪线表示的形状，如表1中的显示。图形上必须能够显示知识源元素的名字，并且可以显示其他属性，如，描述。如果显示，内容必须清晰的显示在DRD元素的图形中。

业务知识模型的属性将在Knowledge Source元模型章节列出。

DRD依赖

信息依赖符号

信息依赖以从 数据输入 连接到 决策，也可以由一个决策画到另一个决策。它们也可以被解释为数据流：一个DRD只显示决策、数据输入和信息依赖，它相当于展现出一个在执行时多个元素之间的信息通讯的数据流图。一个有效的DRG中的信息依赖，形成一个有向无环图。

一个信息依赖在DRD中用实线和实心箭头表示，如表1中的显示。箭头表示信息流的方向，即，从依赖的信息指向决策。

知识依赖符号

知识依赖可以从 业务知识模型 连接到 决策，也可以由一个知识模型连接到另一个知识模型。他们表示进行决策时调用的业务知识。它也可以理解是类似一个功能函数的调用：一个DRD只显示决策、业务知识模型和知识依赖，它相当于展示了在执行决策时的功能函数调用的层次结构图。一个有效的DRG中的知识依赖，形成一个有向无环图。

一个知识依赖在DRD中用虚线和开放箭头表示，如表1中的显示。箭头表示执行函数结果的信息流的方向，即，从依赖的业务知识指向元素。

权威根据依赖符号

权威根据依赖有两种方式使用：

它可以从 知识源元素 连接到 决策、业务知识模型或其他知识源上，他代表DRD元素与知识源的依赖关系。它通常会被用于记录一个事实，即一组业务规则必须来自 或者 与公开文件保持一致，例如一项法例或业务政策声明。使用知识来源的例子如图12。

它可以从 数据输入 和 决策 连接到 知识源，这之中可以结合使用。它代表通过从数据输入的内容和决策的结果分析推导出业务知识模型。知识来源通常是指分析模型（或建模过程）；业务知识模型表示可执行逻辑来自或者依赖这个模型。使用知识来源的例子如图13。

一个权威根据依赖在DRD中用虚线和一个实心圆头的箭头表示，如表1中的显示。箭头从权威根据源指向它规定的元素。

连接规则

在下表中汇总了DRD依赖元素的连接规则。

请注意，没有要求的话可以在数据输入元素得出终点。

部分视图（Partial views）和信息隐藏

元模型提供给每个DRG元素的属性一般不是用于显示在DRD上的，而是提供有关他们的类型或者功能的附加信息。例如，对于一个决策它们包括一些属性来指定BPMN流程和任务使用的决策。一个实现必须提供工具用于指定和显示这些属性。

为重要领域建立决策DRD模型，其完整的DRG可能是一个巨大而且复杂的图。一个实现可以提供显示部分的或者过滤的DRG视图的能力，例如，通过隐藏元素的种类，或隐藏或折叠部分区域。DMN没有指定这样的视图该如何标记，但是在信息隐藏的情况下实现应提供清晰的视觉提示。

DRD提供DRG部分视图的两个例子如图14所示：DRD1仅显示了一个单独决策的执行需求；DRD2仅显示了信息依赖和元素直接的关联。这个例子仅用于说明可以采用虚线轮廓来隐藏元素的做法。

在DRD v1.0中，DRD不会在元模型中体现，因此可能不能互换；DRG包含一组定义，可以被互换，并且可以接收生成任何支持接收执行的DRD。

元模型（Metamodel）

DMN元素的元模型

DMNElement是决策依赖模型元素的抽象基类。它提供必要属性id和可选属性name和description，他们都是String类型，其他元素将会继承自它。DMNElement的id属性必须唯一。

DMNElement有三个抽象实现：Expression, BusinessContextElement, DRGElement和四个具体实现：Definitions, ItemDefinition, InformationItem, ElementCollection。

下表显示了DMNElement元素的属性和模型的关联

Definitions元模型

Definitions是DMN决策模型中的所有元素的最外层包含对象。它定义了可见范围和所有元素的命名空间。元素是包含在一个Definitions实例中的，他们有自己的定义生命周期，并且不会因为删除其他元素时被删掉。DMN文件的交换始终是通过一个或多个Definitions。

Definitions是DMNElement的一个实现，它继承了id和可选属性name、description，他们都是String。

一个Definitions实例有命名空间，它标识Definitions中元素的默认目标命名空间，并且遵守XML Schema的转换约定。

一个Definitions实例可以指定expressionLanguage，它标识在Definitions范围内的元素所使用的默认的表达式语言。这个值可以在每个单独的LiteralExpression上覆盖。该语言必须用URI格式指定。默认是FEEL（第10条）。

一个Definitions实例可以指定一个typeLanguage，它标识在这个定义范围内的元素所使用的默认语言类型。例如，typeLanguage 值："http://www.w3.org/2001/XMLSchema"，表示这个数据结构定义在Definitions里，默认情况下是XML Schema形式。如果未指定，则默认为FEEL。这个值可以在每个单独的ItemDefinition上覆盖。该typeLanguage必须用URI格式指定。

一个Definitions实例是由0至*个drgElements组成，这就是DRGElement实例；0至*个collections组成了ElementCollection；0至*个itemDefinition组成了ItemDefinition实例；0至*个businessContextElement组成了BusinessContextElement实例。

Import实例可以包含多个相关import。Import用于从Definitions之外导入元素定义，例如，在另一个Definitions中的元素使他们也可以在本Definitions中可用。

Definitions继承所有来自DMNElement的属性和模型关联。

Import元模型

Import类用于导入外部定义的元素，或者包含在其他Definitions元素中的其他DMN DRGElement，也可以是非DMN元素，如XML Schema和PMML文件。Import必须明确定义。

Import实例有一个字符串型的importType属性，指定与元素相关联Import的类型。例如，值是"http://www.w3.org/2001/XMLSchema"的时候表示导入的元素是XML schema。值是"<DMN namespace>"的时候表示导入的元素是DMN定义元素。

导入的元素位置可以指定通过Import实例中的一个可选属性locationURI进行关联。该locationURI的是一个String类型，必须指定为URI格式。

Import实例有namespace属性，用于表示导入元素的命名空间。

Element Collection元模型

该ElementCollection类是用来定义DRGElement实例的命名组。

元素集合可以用于与任何相关的用途，例如

标识一个或者多个决策的需求子图（即按照需求封装一组元素在一张需求图中）。

标识一个绘制在DRD上的元素。

ElementCollection是一种DMNElement，它继承了id和可选属性name和description。Id属性必须全局唯一。

一个ElementCollection元素有多个关联的drgElements，每个drgElements都是一个DRGElement实例。ElementCollection定义他们成为一个组。请注意，ElementCollection元素仅引用DRGElement 实例，收集但不包含它们：DRGElement的实例只能被包含在Definitions元素中。

ElementCollection继承了DMNElement的所有属性和模型关系。

DRG元素的元模型

DRGElement是所有DMN元素的抽象基类，它被包含在Definitions中，它具有DRD的图形展现。所有的DMN决策模型元素是不直接包含在Definitions中的（特别是：所有的3种依赖、绑定语句和决策规则、导入以及目标），必须包含在DRGElement实例中，或在一个嵌套的DRGElement实例的模型元素中。

具体的DRGElement实现是Decision, InputData, BusinessKnowledgeModel和KnowledgeSource。

DRGElement是DMNElement的一个实现，它继承了id和可选属性name和description。Id属性必须全局唯一。

Decision Requirements Diagram (DRD)决策依赖图是图解的方式展现一个或多个DRGElement实例以及他们的信息、知识和权威根据关系。一个DRGElement实例表现为图中的一个节点。线代表：信息依赖、知识依赖和权威根据依赖的实例。

DRGElement继承了DMNElement的所有属性和模型关系。

Decision元模型

在DMN 1.0中，Decision类用来对一个决策进行建模。

Decision是一个DRGElement的具体实现，并且它继承了必要属性id和可选属性name和description。

此外，它还有question和allowedAnswers属性，他们都是字符串。可选属性description是决策的简要说明。可选属性question属性是体现决策特征的原始问题（自然语言），这样决策的输出就是该问题的答案。可选属性allowedAnswers是该问题期待的答案（自然语言），就像是：是/否、一组允许的值、一个数字区间等。

在一个DRD中，一个决策实例表现为一个决策图标元素。

一个Decision元素是由一个可选的决策逻辑（它是一个Expression实例）和0至多个信息依赖、知识依赖、权威根据依赖元素组成的他们分别是信息、知识和权威根据的实例。

Decision元素的需求子图（requirement subgraph）是由决策元素自身、其中的信息依赖、知识依赖和权威根据依赖，加上每个依赖的需求和依赖的知识元素组成的有向子图：即，Decision是封装了所有依赖的信息、输入、相关决策、业务知识模型和知识源的集合，入口是Decision元素的需求子图。

一个决策实例，即一个决策的模型，需要所有的信息依赖和知识依赖都定义合格才可以被认为是合格的，这种情况尤其需要这个Decision元素的需求子图必须是无环的，也就是说一个Decision元素必须不能够依赖自己，不论直接的或者间接的。

除了这些逻辑组件（信息依赖、决策逻辑等）之外，决策模型还可以为决策记录其业务环境。

在DMN 1.0中，一个决策实例的业务环境是通过它与多个supportedObjectives关联来定义的，Objective的实例定义在OMG BMM中，多个impactedPerformanceIndicators，它是执行指标的实例；decisionMaker和decisionOwner是OrganisationalUnit的实例。

Decision继承了DRGElement的所有属性和模型关系。

Business Context元素的元模型

BusinessContextElement是抽象类，它是PerformanceIndicator和OrganizationUnit具体实现的容器，这里预计还会引入从其他的OMG元模型，如OMG OSM，这将被进一步开发。

在DMN 1.0中，BusinessContextElement是一个DMNElement的实现，它继承了必要属性id和可选属性name和description。

另外，BusinessContextElements实例可以设置URI，他必须指定为URI格式，并且

一个PerformanceIndicator的实例引用多个impactingDecision，它会影响决策元素。

一个OrganisationalUnit的实例引用多个decisionOwned和decisionMade，它是Decision元素的模型，组织单位执行或拥有的决策。

BusinessContextElement继承了DRGElement的所有属性和模型关系。

PerformanceIndicator继承了BusinessContextElement的所有属性和模型关系。

OrganisationalUnit继承了BusinessContextElement的所有属性和模型关系。

Business Knowledge Model元模型

所有与决策相关的业务知识模型的决策逻辑都是或者有部分是可重用的模块化表达式。

在DMN 1.0中，BusinessKnowledgeModel类是用来对业务知识进行建模。

BusinessKnowledgeModel是一个DRGElement的具体实现，它从DMNElement继承了必要属性id和可选属性name和description。

在一个DRD中，一个BusinessKnowledgeModel实例表现为一个业务知识模型图标元素。

一个业务知识模型元素可以有0至多个知识依赖（KnowledgeRequirement实例），以及0至多个权威根据依赖（AuthorityRequirement的实例）。

BusinessKnowledgeModel元素的需求子图（requirement subgraph）是由BusinessKnowledgeModel元素自身、其中的知识依赖，加上知识依赖引用的所有requiredKnowledge元素的依赖子图组成的有向图。

一个业务知识模型实例，要么没有任何知识依赖，要么所有的知识依赖都是合格的才可以被认为是合格的，这种情况尤其需要这个BusinessKnowledgeModel元素的需求子图必须是无环的，也就是说一个BusinessKnowledgeModel元素必须不能够依赖自己，不论直接的或者间接的。

在决策逻辑层，一个BusinessKnowledgeModel元素定义一个功能。它是由一个相关联的主体（是Expression实例）、0至多个参数（是InformationItem实例）。这个主体是关联到一个BusinessKnowledgeModel元素，是可重用模块的决策逻辑，这就表示为BusinessKnowledgeModel元素。BusinessKnowledgeModel元素的参数是由它的主体所引用的输入变量。

BusinessKnowledgeModel继承了DRGElement的所有属性和模型关系。

Input Data元模型

DMN1.0使用InputData类是用来对一个决策的输入进行建模的，其值是定义在决策模型之外的。

InputData是一个DRGElement的具体实现，它从DMNElement继承了必要属性id和可选属性name和description。

InputData的实例可引用一个itemDefinition，它是一个ItemDefinition元素，用于指定InputData展现的数据类型。

在DRD中，一个InputData实例表现为一个数据输入图标元素。InputData元素没有需求子图，他必须总是定义完整。

InputData继承了DRGElement的所有属性和模型关系。

Knowledge Source元模型

在DMN 1.0中， KnowledgeSource类是用来对决策模型中的权威知识来源进行建模的。

在DRD中，一个KnowledgeSource实例表现为一个知识源图标元素。

KnowledgeSource是一个DRGElement、DMNElement的具体实现，它从DMNElement继承了必要属性id和可选属性name和description并从DRGElement继承了必要属性Id from。此外，一个知识源有一个locationURI，它是字符串并且必须使用URI格式。还有type属性也是字符串类型，还有owner是一个OrganisationalUnit实例。

一个KnowledgeSource元素也是由0个或多个权威根据依赖元素组成的，这是AuthorityRequirement的实例。

KnowledgeSource继承了DRGElement的所有属性和模型关系。

Information Requirement元模型

InformationRequirement类是用来对信息依赖进行建模的，在DRD中表示为一个普通的箭头。

InformationRequirement元素是决策元素的一个组成部分，它关联决策元素到一个被依赖的决策元素（Decision实例），或者被依赖输入元素（InputData实例）。

一个信息依赖元素是由变量（InformationItem实例）组成的，它表示在决策逻辑层的信息依赖。

请注意，一个信息依赖元素必须引用Decision实例或者InputData，由它关联至需要的Decision元素上，而不是包含它：Decision实例或者InputData只能被包含在Definitions元素中。

一个InformationRequirement实例需要满足以下所有要求才可以被认为是合格的：

它引用一个依赖决策或者依赖输入元素，但不能同时引用。

引用的依赖决策或者依赖输入元素必须是合格的。

如果包含InformationRequirement实例的Decision元素是不能出现在被引用的依赖Decision元素需求子图中。

Knowledge Requirement元模型

KnowledgeRequirement类是用来对知识依赖进行建模的，在DRD中用虚线箭头表示。

知识依赖元素是决策元素或业务知识模型元素的组成部分，它关联决策元素或业务知识模型元素到一个被依赖的知识元素上（BusinessKnowledgeModel实例）

请注意，KnowledgeRequirement元素必须引用BusinessKnowledgeModel的实例，由它关联至需要的Decision或业务知识模型元素上，而不是包含它：BusinessKnowledgeModel实例只能被包含在Definitions元素中。

一个BusinessKnowledgeModel实例需要满足以下所有要求才可以被认为是合格的：

它引用一个requiredKnowledge元素

引用的依赖requiredKnowledge元素必须是合格的。

如果包含InformationRequirement实例的BusinessKnowledgeModel元素是不能出现在被引用的依赖BusinessKnowledgeModel元素需求子图中。

Authority Requirement元模型

AuthorityRequirement类是用来对权威根据依赖进行建模的，在DRD中用虚线和一个填充的圆形箭头表示。

权威根据依赖元素是决策、 业务知识模型或知识源元素的组成部分，它关联决策、业务知识模型或知识源元素到一个被依赖的权威根据元素（KnowledgeSource实例）或依赖决策元素（Decision实例）或依赖输入元素（InputData实例）上。

请注意，一个AuthorityRequirement元素必须引用KnowledgeSource或Decision或InputData的实例，由它关联至需要的元素上，而不是包含它：KnowledgeSource、Decision或InputData只能被包含在Definitions元素中。