5.4案例管理元素---计划模型元素----cmmnV1.1

此子条款指定了casePlanModel(参见图5.5)。对于一个特定的Case模型，casePlanModel包含了代表Case初始计划的所有元素，以及支持Case工作者通过运行时计划进一步发展的所有元素。如图5.5所示，casePlanModel是通过与Stage的关联来定义的。正如它将在这个子句中出现的，Stage代表了一个递归概念——Stage可以嵌套在其他Stage中——作为构建和进一步发展Case计划所需的任何元素的容器。“最外部的”阶段作为它的casePlanModel与案例相关联。

5.4.1 PlanItemDefinition

PlanItemDefinition元素定义了用来构造Case(实例)计划的构建块。PlanItemDefinition是一个继承自CMMNElement的抽象类

PlanItemDefinition专门分为以下几个概念，在本文件后续的子条款中有所说明:EventListener, Milestone, PlanFragment(和Stage)， Task。

PlanItemControl类为planitemdefinition的控制方面指定了默认值，比如这些实例是否必须在Case完成之前完成，或者包含实例的Case的一个Stage可以完成。PlanItemControl和这些方面将在5.4.1中指定。稍后会看到，与stage和PlanItemDefinition的其他子类型不同，PlanFragments(不是stage)不会在运行时实例化。

PlanItemDefinition具有以下属性：

该元素指定PlanItemDefinitions控制方面的默认值。DefaultControl绝对不能作为Case引用的阶段的casePlanModel而指定。

PlanItemDefinition必须在它被引用的阶段的范围内定义。阶段S的范围包括阶段S中包含的所有元素，以及包括阶段S到CasePlanModel的所有阶段。作为推论，如果阶段a和B包含在阶段S中，那么阶段a一定不能引用包含在阶段B中的元素，反之亦然。然而，阶段A和阶段B可能引用阶段S中包含的元素

5.4.2 EventListener

在CMMN中，事件是在案件过程中“发生”的事情。事件可以触发，例如，阶段和任务的启用、激活和终止，或者里程碑的实现。任何事件都有原因。CMMN预先定义了许多事件及其原因，如:

• 对CaseFile中的信息可能发生的任何事情。这是由表示cmmn定义的CaseFileItems生命周期中的转换的“标准事件”定义的。
• 任何可能发生在阶段、任务和里程碑上的事情中。这是由表示cmmn定义的生命周期中的转换的“标准事件”定义的。

然而，时间的流逝不能通过这些“标准事件”来捕获。当任何用户事件，例如批准或拒绝某事，都必须通过对CaseFile中的数据的影响或通过生命周期的转换(例如任务或里程碑)来捕获时，它通常会导致非常间接的建模。

出于这个原因，引入了一个额外的类，称为EventListener，专门用于TimerEventListener和UserEventListener。EventListener有自己的cmmn预定义的生命周期，因此任何时间的流逝以及任何用户事件都可以被捕获为“标准事件”，表示在cmmn定义的EventListener生命周期中的转换。

EventListener继承自PlanItemDefinition，因此EventListener的实例也可以是Case计划的元素。

这使得CMMN能够以统一的方式处理任何事件，即表示CMMN定义的生命周期中的转换的“标准事件”。这些标准事件是通过Sentries来处理的。哨兵和这些“标准事件”在5.4.6中有详细说明。

5.4.2.1 TimerEventListener

TimerEventListener是PlanItemDefinition，它的实例用于捕获预定义的时间流逝。它继承自EventListener。下表列出了TimerEventListener类的属性：

StartTrigger

TimerEventListener StartTrigger处理生命周期状态改变的事件，触发TimerEventListener的起始点。StartTrigger是一个抽象类，继承自CMMNElement，有两个子类，CaseFileItemStartTrigger和PlanItemStartTrigger。

CaseFileItemStartTrigger

CaseFileItemStartTrigger类继承自StartTrigger，并具有以下属性：

PlanItemStartTrigger

PlanItemStartTrigger类继承自StartTrigger，并具有以下属性。

5.4.2.2 UserEventListener

UserEventListener是PlanItemDefinition，其中哪些实例用于捕获由用户引发的事件，哪些事件用于直接影响Case的执行，而不是通过影响CaseFile中的信息间接影响Case的执行。UserEventListener允许用户与Case直接交互。它继承自EventListener。下表列出了UserEventListener类的属性。

5.4.3 Milestone

里程碑是一个PlanItemDefinition，它代表了一个可实现的目标，定义它是为了对案例的进展进行评估。没有工作与一个里程碑直接相关，但是任务集的完成或关键可交付成果的可用性(CaseFile中的信息)通常会导致实现一个里程碑。

5.4.4 PlanFragment

PlanFragment是一组PlanItems(见5.4.5)，它们可能彼此依赖，并且经常出现在Case计划的组合中，代表一个模式。

 PlanFragments中PlanItems之间的依赖关系被定义为Sentries(见5.4.6)。PlanFragment是PlanItems和Sentries的容器，它们定义了启用(或进入)和终止(或退出)PlanItems的标准。PlanFragments的简单例子如下:

• 两个任务的组合，其中一个任务的完成满足哨兵，使另一个任务开始。
• EventListener和Task的组合，事件的发生满足Sentry，从而启动Task。

PlanFragments可以代表任何复杂的PlanItem-and-Sentry模式。简单的PlanFragment 不能包含哨兵。PlanFragment继承了PlanItemDefinition，因为它包含的PlanItems(和Sentries)组合可以作为一个单元添加到Case(实例)的平面图中。与其他PlanItemDefinitions不同，PlanFragment(不是Stage)在运行时没有表示，也就是说，在Case实例的上下文中没有PlanFragment(不是Stage)的生命周期跟踪的概念。只有包含在其中的PlanItems被实例化，并且它们的生命周期被跟踪。

为了计划被跟踪的PlanItems的组合，在Case实例的计划中，作为组合，应该使用PlanFragment的专门化，称为Stage。阶段在5.4.8中指定。阶段有生命周期，而PlanFragments(不是阶段)则没有。

类PlanFragment具有以下属性：

5.4.5 PlanItem

PlanItem对象在PlanFragment(或Stage)的PlanItemDefinition元素中使用。

一旦在应用Case模型中获得了经验，最佳实践可能会发展，例如，认识到应用PlanItemDefinitions的可重用组合的有用性，甚至必要性。同样的PlanItemDefinition可能被(重新)多次使用，作为不同组合的一部分，即，作为不同的PlanFragments(或stage)的一部分。因此，一个PlanItemDefinition(例如，一个Task或EventListener)只定义一次，并且可以(重新)在多个PlanFragments(和stage)中使用。

这需要一个单独的类PlanItem，它引用PlanItemDefinition。多个PlanItems可能引用同一个PlanItemDefinition。当这些PlanFragments(或stage)包含引用或(“使用”)相同PlanItemDefinition的PlanItems时，PlanItemDefinition(重新)在多个PlanFragments(或stage)中使用。

Criterion

criteria是一个抽象元素，用来表示PlanItem变得可用或完成的条件，具体取决于所使用的具体实现。它继承了CMMNElement并添加了以下属性。

Entry Criterion

EntryCriterion表示PlanItem变为可用的条件。它继承了Criterion，没有添加任何属性。

Exit Criterion

ExitCriterion表示PlanItem终止的条件。它继承了Criterion，没有添加任何属性。

PlanItemDefinition Reference Constraint Example

5.4.6 Sentry

“哨兵”“警惕”发生的重要情况(或“事件”)，这些情况会影响案件的进一步审理(以及案件的名称)。

“哨兵”是“事件和/或条件”的组合。当接收到事件时，可以应用一个条件来评估事件是否有效。哨兵可以采取以下形式:

 如5.4.2所述，CMMN定义了一组基于CMMN定义的生命周期中的转换的“标准事件”，这些事件能够捕获在Case上下文中相关的任何事件。这包括计时器事件、案例信息事件和用户事件。

 《哨兵》可由两部分组成:

• 0个或多个OnParts。OnPart指定作为触发器的事件。当事件被捕获时，OnPart被称为“发生”。
• 0或1个IfPart。IfPart指定一个条件，作为在CaseFile上计算的Expression。如果Sentry的所有OnParts都发生了，并且它的IfPart(如果存在)计算为TRUE，那么Sentry就被称为“满足”。

一个满足的哨兵会触发指向它的PlanItem(见图5.8)

• 当Sentry被PlanItem的entryCriteriaRefs引用时，PlanItem(它的实例)将会传输，基于它生命周期中与进入标准相关的转换:一个任务或阶段将被启用，一个里程碑将被实现。
• 当Sentry被PlanItem的exitCriteriaRefs引用时，PlanItem将在生命周期中基于与退出标准相关的转换进行传输:一个任务或阶段将被终止(退出)。

第8条将详细分析哨兵和生命周期之间的关系。

Sentry继承自CMMNElement，具有以下属性。

OnPart

Sentry OnPart解决了Sentry的“事件”方面。OnPart类是继承自CMMNElement的抽象类。它有两个子类:CaseFileItemOnPart和PlanItemOnPart

CaseFileItemOnPart

CaseFileItemOnPart类继承自OnPart并具有以下属性。

CaseFileItemTransition

CaseFileItemTransition是一个枚举，它指定cmmn定义的CaseFileItems生命周期中的转换(参见8.3)。其值在下表中列出。

PlanItemOnPart

PlanItemOnPart类继承自OnPart并具有以下属性:

- PlanItemTransition

PlanItemTransition是一个枚举，它指定cmmn定义的阶段、任务、eventlistener和里程碑生命周期中的转换(参见8.4)。它的值是:

IfPart

Sentry的IfPart用于指定一个(可选)条件。

IfPart类继承自CMMNElement，具有以下属性。

5.4.7 Expressions

表达式是字符串对象。表达式对CaseFile中的属性和CaseFileItems进行操作。除了Casefile内容外，还允许常量和时间基表达式。

表达式继承自CMMNElement，并具有以下属性:

5.4.8 Stage

Stage继承自PlanFragment。作为PlanFragment，它也是一个PlanItemDefinition，并作为Case(实例)计划的构建块。

作为PlanFragment，一个阶段可以包含PlanItems和Sentries。

与PlanFragments(不是stage)不同，stage在Case(实例)计划中有运行时表示。阶段的实例在cmmn定义的阶段生命周期中被跟踪(见8.4.2)。阶段可以被认为是案例的“片断”，尽管案例模型允许定义也可以并行规划的阶段。

Stage支持以下内容，PlanFragment不支持(不是Stage):

• 一个阶段可以作为PlanFragments或其他阶段中的PlanItem使用。
• 一个阶段(实例)可以作为计划的上下文(例如，一个阶段可以有一个计划表)来支持用户在运行时计划额外的(“自由决定的”)项到阶段的实例中。规划表和酌情项在5.4.9中指定。
• 案例指的是一个阶段作为它的案例计划模型。这定义了案例的“最外层”阶段。
• 案件的这一“最外层”阶段也可能包含哨兵，作为该阶段的退出标准，因此也包括案件的退出标准.

 类Stage具有以下属性:

5.4.9 PlanningTable

计划是一项运行时工作。规划表定义了规划的范围，通过确定可以在特定上下文中考虑的PlanItemDefinitions的子集。规划的背景可能是:

• 一个阶段。当一个阶段有一个规划表时，对于该阶段的一个实例，可以使用规划表将任务和阶段的实例规划到该阶段实例中。
• HumanTask。当一个HumanTask有一个规划表(参见5.4.10.4)时，对于该HumanTask的实例，可以使用规划表将task和Stage的实例规划到包含该HumanTask实例的Stage的实例中。

 由同一个PlanItemDefinition定义的任务和阶段的实例可能会基于多个规划表进行规划。这需要一个单独的类，distionaryitem(见5.4.9.2)，它引用PlanItemDefinition。多个酌情项目可能引用同一个PlanItemDefinition。当多个规划表包含引用或(“使用”)相同PlanItemDefinition的离散项时，PlanItemDefinition(重新)在多个规划表中使用。

为了方便起见，一个引用PlanItemDefinition(任务)的DiscretionaryItem可以被称为“discretionary Task”。类似地，我们可以考虑“自由决定的计划片段”和“自由决定的阶段”。注意，不是阶段的PlanFragments只能是“自由决定的”，因为PlanItems不能引用它们(见5.4.5)。再次注意，当PlanFragment(不是Stage)被用于规划时，只有包含在其中的PlanItems被实例化，并且它们的生命周期被跟踪。PlanFragment(不是Stage)没有实例化自己。

为了在运行时规划时的方便，在一个规划表可能包含许多离散项的情况下，可以递归地定义一个规划表:一个规划表包含其他规划表。

当用户(案例工作者)从规划表中选择DiscretionaryItems，并将其相关PlanItemDefinitions的实例移动到案例(实例)的计划中时，他们被称为“计划”(在运行时)。

可以授权角色来规划某些酌情项目和子规划表。基于CaseFile上评估的条件，也可以使离散化项目(和子规划表)动态适用于规划。角色授权和应用规则(见5.4.9.3)都可以动态控制哪些酌情项(可能通过子规划表组织)暴露给参与规划的个案工作者。

第7条详细地指定了运行时计划的语义，其中还指定了Stage实例何时有资格进行计划(进入它们)以及何时可以执行计划。HumanTasks规划表，以及通过HumanTasks进行规划的目的在5.4.10.4中指定。

planingtable继承自CMMNElement，并具有以下属性。

TableItem

一个TableItem可能是一个DiscretionaryItem或一个planingtable。

TableItem继承自CMMNElement，具有以下属性。

DiscretionaryItem

PlanItemDefinition DiscretionaryItem标识,可以规划的实例,对“自由裁量权”的情况下工人参与计划,这计划为实例的上下文(参见5.4.9和8.7)包含DiscretionaryItem PlanningTable所暗示的,直接或通过嵌套PlanningTable。

distionaryitem继承自TableItem，并具有以下属性。

PlanItemDefinition被认为是HumanTask或Stage的“酌情决定的”:

• 当HumanTask或Stage有一个规划表，该规划表直接或通过规划表嵌套包含一个引用该PlanItemDefinition的离散项时，或
• 最终到达具有规划表的HumanTask或Stage，该规划表直接或通过规划表嵌套包含引用该PlanItemDefinition的离散项

阶段不能由它自己或它的嵌套阶段自行决定。

对于PlanItemDefinition中包含的PlanItem或其嵌套的Stage, Stage不能被HumanTask任意定义。

HumanTask不能由它自己决定,必须包含一个离散项的entryCriteriaRefs和exitCriteriaRefs:

• 在也包含包含离散项的规划表的阶段中，直接或递归地通过规划表的层次结构，或
• 阶段中，该阶段还包含具有包含离散项的规划表的HumanTask，直接或递归地通过规划表的层次结构。

Applicability Rules

ApplicabilityRules用于指定TableItem是否“适用”(“合格”，“可用”)用于规划，基于CaseFile中的信息评估的条件。

相关的ApplicabilityRule评估为FALSE的表项不会暴露给个案工作者进行规划。

类ApplicabilityRule具有以下属性:

5.4.10 Task

Task是工作的原子单位。Task是CMMN中所有Task的基类，继承自PlanItemDefinition.

Task类具有以下属性:

5.4.10.1 Parameter

类Parameter是CaseParameter和procesparameter的抽象基类。它继承自CMMNElement，并具有以下属性

5.4.10.2 ParameterMapping

类ParameterMapping用于CaseTasks和ProcessTasks的输入/输出映射。它继承自CMMNElement并具有以下属性。

5.4.10.3 CaseParameter

类CaseParameter用于对case和Tasks的输入和输出建模。它继承了Parameter并具有以下属性。

5.4.10.4 HumanTask

HumanTask是由案例工作者执行的任务.

当一个HumanTask没有“阻塞”(isBlocking是FALSE)时，它可以被认为是一个“手动”任务，也就是说，案例管理系统没有跟踪HumanTask(实例)的生命周期。

HumanTask可以有一个规划表，这样HumanTask也可以用于规划。尽管也可以基于包含HumanTask的Stage的规划表来执行规划，但有时也可以直接从HumanTask执行规划，例如:

• 它带来了一个特殊的规划视角:HumanTask的规划表中的TableItems，作为阶段中的PlanItem使用，是阶段和任务规划的基础，这些阶段和任务可以被认为是特定HumanTask的后续阶段和任务。基于包含Stage的规划表进行规划，添加Stage(的一个实例)所包含的Stage和Tasks的实例，但不特别像表5.42的后续- CaseParameter属性属性描述bindingRef: CaseFileItem[0..1]对CaseFileItem的引用。当一个Task有一个带有引用CaseFileItem的bindingRef的CaseParameter输出时，该Task实例的执行对该CaseFileItem实例的影响可以通过CaseFileItem的cmmn生命周期的转换来观察(见8.3)。类似地，当一个Case有一个带有引用CaseFileItem的bindingRef的CaseParameter输入时，通过CaseParameter将信息传递给Case的一个实例，会对Case实例的CaseFileItem的实例产生影响，可以通过CaseFileItem的cmmn生命周期中的转换来观察(见8.3)。Case的输出和task的输入只涉及从Case实例的CaseFile中检索CaseFileItem(实例)。bindingRefinement:表达式[0 . .1]一个可选的表达式，进一步细化CaseParameter到CaseFileItem的绑定，它被CaseParameter的bindingRef引用。例如，如果bindingRef将引用一个表示购买订单的CaseFileItem，那么binding细化可以用来有效地将引用的购买订单集合减少到一个特定的购买订单(注意，CaseFileItem的多样性可能大于零)，或有效地引用(一个)关联的CaseFileItem(s)，例如(a)采购订单行。表达式在5.4.7中指定。案例管理模型和表示法，v1.1 47认为HumanTask。HumanTask的规划表通常包含与特定HumanTask的规划上下文特别相关的TableItems，而包含Stage的规划表可能提供更广泛的TableItems。
• 它有助于避免定义只包含一个PlanItem的“任意”阶段的开销:为了与更狭义PlanningTable上下文,它通常不是首选进一步定义阶段嵌套(包含有他们PlanningTables阶段,包含一个HumanTask),而是使用PlanningTable HumanTask, HumanTask直接包含在Statge上。
• 它允许使用由HumanTask的performerRef引用的角色，以有效地作为被授权基于HumanTask的规划表中的任何TableItem进行规划的角色，或者强制案例工作者根据规划表中的PlanItems进行计划，必须同时分配与humantask相关的角色和与tableitem相关的角色。

HumanTask继承自Task，并具有以下属性。

5.4.10.5 ProcessTask

在案例中可以使用ProcessTask来调用业务流程(参见5.4.10.5.1)。

参数用于在ProcessTask(在Case中)和它所指向的Process之间传递信息:ProcessTask的输入映射到Process的输入，ProcessTask的输出映射到Process的输出。这样，Case的CaseFile中的CaseFileItems的(元素)实例可以被传递给Process，而Process的输出可以被传回并映射到CaseFileItems的(元素)实例。

当一个processstask正在“阻塞”(isBlocking为TRUE)时，processstask正在等待，直到与processstask相关联的进程完成。如果isBlocking设置为FALSE, ProcessTask不会等待Process完成，而是在它实例化并调用其关联的Process后立即完成

可以通过在设计时选择现有流程的有效QName或指定将计算为有效流程QName的表达式来为ProcessTask选择流程。后者允许在运行时动态选择Process。如果指定了processRefExpression，则当processstask变为Active时，必须作为processstask启动操作(自动或手动)的一部分计算该表达式。如果processRefExpression的计算结果不是现有流程的QName，或者QName引用的流程与ProcessTask的ParameterMapping不兼容，则必须将ProcessTask故障并移动到状态Failed,

 Process

5.4.10.6 CaseTask

CaseTask可以用来调用另一个Case。CaseTask触发另一个Case实例的创建，该实例的创建表示cmmn定义的Case实例生命周期中的初始转换(参见8.2)。

使用CaseTask和Stage之间的区别是,CaseTask调用一个新的案件,都有其特定的环境,也就是说,它是基于自己的CaseFile(实现重用),而一个阶段是在目前的情况下,也就是说,它是基于同一CaseFile是“嵌入”在当前的情况下(实现组成)。

参数用于在CaseTask(在Case中)和它所指向的Case之间传递信息:CaseTask的输入映射到Case的输入，CaseTask的输出映射到Case的输出。通过这种方式，CaseFileItems的(元素)实例可以在Cases的(casefile)之间交换。

当CaseTask处于“阻塞”状态(isBlocking为TRUE)时，CaseTask一直在等待，直到与CaseTask关联的Case完成。如果isBlocking设置为FALSE, CaseTask不会等待Case完成，而是在实例化和调用关联Case时立即完成

可以通过在设计时选择现有Case的有效QName或指定将计算为有效Case QName的表达式来执行CaseTask的Case选择。后者允许在运行时动态选择Case。如果指定了caseRefExpression，那么当CaseTask变为Active时，这个表达式必须作为CaseTask启动操作(自动或手动)的一部分进行计算。如果caseRefExpression的计算结果不是现有Case的QName，或者QName引用的Case与CaseTask的ParameterMapping不兼容，那么CaseTask必须故障并移动到状态Failed。

5.4.10.7 Decision Task

案例中可以使用DecisionTask来调用决策(参见5.4.10.7.1)

参数用于在DecisionTask(在案例中)和它所指向的Decision之间传递信息:DecisionTask的输入映射到Decision的输入，Decision的输出映射到DecisionTask的输出。通过这种方式，可以将Case的CaseFile中的CaseFileItems的实例传递给Decision，而Decision的输出可以传回并映射到CaseFileItems的实例。

当DecisionTask是“blocking”(isBlocking设置为TRUE)时，DecisionTask正在等待与DecisionTask关联的Decision完成。如果isBlocking设置为FALSE，则DecisionTask不会等待Decision完成，而是在实例化并调用关联的Decision后立即完成。

当DecisionTask是“blocking”(isBlocking设置为TRUE)时，DecisionTask正在等待与DecisionTask关联的Decision完成。如果isBlocking设置为FALSE，则DecisionTask不会等待Decision完成，而是在实例化并调用关联的Decision后立即完成。

Decision 

CMMN中的决策是决策的抽象，因为它们在各种决策建模规范中被指定。

可以通过在设计时选择现有Decision的有效QName或指定将计算为有效Decision QName的表达式来执行为DecisionTask选择Decision。后者允许在运行时动态选择Decision。如果指定了decisionRefExpression，则当DecisionTask变为Active时，必须作为DecisionTask启动操作(手动或自动)的一部分计算该表达式。如果decisionRefExpression计算出的结果不是现有Decision的QName，或者QName引用的Decision与DecisionTask的ParameterMapping不兼容，则必须将DecisionTask故障并移动到状态Failed。

5.4.11 PlanItemControl

PlanItemControls定义了任务、阶段、eventlistener和里程碑等实例的控制方面。它们与模型中的“起源”——PlanItems和DiscretionaryItems——相关定义，PlanItemControls可以默认PlanItemControls与PlanItems和DiscretionaryItems通过它们的definitionRef引用的PlanItemDefinitions相关定义。

PlanItemControls可以指定以下内容:

• 在哪些条件下，任务和阶段，一旦启用，将手动或自动启动。这是由ManualActivationRules指定的，作为PlanItemControls的一部分(参见5.4.11.1)。
• 在哪些条件下，任务、阶段和里程碑“需要”在包含它们的阶段完成之前完成。这是由RequiredRules规定的，作为PlanItemControls(参见5.4.11.2)的一部分。
• 在哪些条件下需要重复任务、阶段和里程碑。这是由PlanItemControls(参见5.4.11.3)中的RepetitionRules规定的。

与这些规则相关的运行时语义在第7条中指定。

 

PlanItemControl类继承自CMMNElement，并具有以下属性。 

PlanItemControl必须是PlanItem或DiscretionaryItem的itemControl或PlanItemDefinition的defaultControl。

一个PlanItemControl必须包含至少一个repetitionRule或一个requirerule或一个manualActivationRule。

ManualActivationRule

ManualActivationRule指定在哪些条件下任务和阶段，一旦启用，手动或自动启动。

 

RequiredRule

RequiredRule指定了在哪些条件下任务、阶段和里程碑将被“要求”在包含它们的阶段完成之前完成或终止.

定义为Expression的条件。表达式在5.4.7中指定。必须计算为布尔值的表达式。如果Expression的值为TRUE，那么Task、Stage或Milestone的实例是必需的，并且必须在包含Stage(实例)的实例完成之前处于禁用、完成、终止或失败的状态(参见8.3和8.5)，否则它被认为是可选的。

 

RepetitionRule

repeattionrule指定了任务、阶段和里程碑在哪些条件下会有重复。每一次重复都是它的一个新实例。第一次实例化不被认为是重复。重复的触发器是一个Sentry，它被引用为条目标准，被满足，由此该Sentry的OnPart发生。例如:每次创建某个文档时，都会重复一个Task。Task(作为PlanItem)可能有一个入口标准，引用一个哨兵，有OnPart，其中OnPart指的是代表文档类型的CaseFileItem，并且OnPart的标准devent被指定为“create”。当任务的PlanItemControl(如PlanItem)中包含的RepetitionRule也计算为TRUE时，该任务在创建文档时被重复。或者，重复规则可以用于没有任何输入条件的任务或阶段。在这种情况下，当Task或Stage的一个实例完成或终止时，就会计算RepetitionRule。如果计算结果为TRUE，则创建一个新实例。

当带有RepetitionRole的任务、阶段和里程碑被实例化时，RepetitionRule的条件将被计算(在从Create到Available的转换期间)。Task、Stage或Milestone的第一次实例化不被认为是重复，因此repeattionrule的条件值被丢弃。之后，每次OnPart的输入条件满足了RepetitionRule的条件就会被重新计算，如果它的计算结果为TRUE，就会创建一个Task、Stage或Milestone的新实例并转换到Available。这允许用户控制重复次数，以及在什么条件下应该发生重复。

EventListeners不能有RepetitionRule。重复的概念对UserEventListeners没有用处。然而，对于TimerEventListener，重复可以通过基于ISO-8601的timerExpression定义，通过在其中定义重复间隔(使用“R<n>/”标记)。

 

备注：翻译过程借助有道同步完成