图15.35中，在活动开始执行时，初始节点把控制移交给Receive Order可执行节点。

图15.35 InitialNode example

图15.36中，当Fill Order结束后，ForkNode把控制移交给Ship Order和Send Invoice。

图15.36 ForkNode example

图15.37中，JoinNode用于对Ship Order和Send Invoice的处理进行同步，当它们都执行完后，控制才移交给Close Order。

图15.37 JoinNode example

图15.38展示了如何使用一个joinSpec来确保在饮料分发之前已经选择了饮料并投入了足够数量的钱。流入边的名称在join规约中被引用来指示tokens是否可用。

图15.38 joinSpec example

图15.39中，节点Buy Item和Make Item可能都执行或其一执行。只要有一个执行，控制就传递给Ship Item。也就是说，如果二者其一完成，Ship Item只执行一次；如果两者都完成，Ship Item执行两处。

图15.39 MergeNode example

图15.40包含一个决策节点。分支基于订单是接受还是拒绝。如果接受了，控制传递到Fill Order；如果拒绝，控制传递给Close Order。

图15.40 DecisionNode example

图15.41展示了一个订单处理过程的例子。一个订单项从库房获取准备交付。由于该条目已经从库存中删除，应该检查再排序水平；如果实际的水平低于一个预设的再排序点，更多相同类型的条目应该再排序。

图15.41 DecisionNode example with decisionInput

图15.42描绘了当Close Order结束后，整个活动终止，因此此时控制传递到了活动结束节点。

图15.42 ActivityFinalNode example

图15.43是一个基于员工支出报销过程的例子，说明了两个并发的流竞争结束。第一个到达活动结束节点的将终止另一个。这两个流位于相同的活动因此共享数据，例如在没有动作时向谁通知。使用一个Fork节点来将初始流划分为两个并发的流。

图15.43 ActivityFinalNode example

图15.44中，存在到达活动结束节点的两条路；但它是排他性“or”分支的结果，而不是图15.43中的“竞争”场景。这个例子使用了两个活动结束节点，这与使用一个带两条流入边的活动结束节点具有相同的语义。

注意. Notify of Modification的执行时间应短于Publish Proposal和Notify of Rejection，否则后者的完成导致它被杀死。

图15.44 ActivityFinalNode example

图15.45中，假定可以构建和安装许多构件。这里，Build Component节点对于每个构件迭代执行。当最后一个构件被构建出来后，构建迭代以一个流结束节点结束。然而，尽管所有的构件构造都结束了，但其它节点仍然在运行（例如Install Component）。

图15.45 FlowFinalNode example

图15.46展示了两种结束节点：流结束节点和活动结束节点。该例扩展了图15.45中的模型。在这个扩展模型中，当最后一个构件被安装后，该应用被交付。当Deliver Application结束后，控制传递给活动结束节点——指示整个处理过程终止。

图15.46 FlowFinalNode example

图15.47包含各种控制节点的例子。左上的初始节点触发Receive Order节点。之后的决策节点基于拒绝还是接受进行分支处理。Fill Order把控制传递给Send Invoice和Ship Order。

JoinNode指示当Ship Order和Accept Payment都结束后控制传递给合并节点（当订单被拒绝时控制也会传递给Close Order）。当Close Order结束后，控制传递给活动结束节点。

图15.47 ControlNode examples (with accompanying actions and control flows)

15.3.5 示例

results matching ""