活动边
活动边是两个活动节点之间的一个有向连接，tokens经它由源活动节点流向目标活动节点。
Tokens由边的源活动节点提交给自己。交付按照活动和每种控制节点所关联的规则通过活动边和控制节点进行扩散，直到它们到达一个对象节点（用于对象tokens）或一个可执行节点（用于控制节点和一些由建模者规定的对象tokens，参见15.4中的对象节点）。每种对象节点（参见15.4）和可执行节点（参见15.5和第16章）都有何时接受tokens的规则。如果一个对象节点或可执行节点接受了一个交付的token，那么该token从它的原始交付活动节点流向接受的活动节点。前面说过，可能会有多个节点竞争该token——交付的概念定义了管理此类竞争的语义。
活动边可以有一个guard，它是一个值规约，在每个token提交给该边时被计算。只有guard计算为真，交付才能通过该边。没有guard的活动边相当于它有一个对每个token都计算为真的guard。（Guards通常用于决策节点，但它们允许用于任意活动边。）
一些tokens可以每一次按组，或不同时刻单独地通过一条活动边。weight属性指示必须同时通过该边的最小tokens数目。它必须是一个可以计算为正LiteralUnlimitedNatural的数或是一个常数。一旦被提交的tokens达到了最小允许值，由源提交的所有tokens立即被交付给目标。它们必须被接受才能通过该边。如果活动边有一个guard，那么对于计数以达到最小允许值的token，guard必须计算为真。如果对某些tokens guard失败了，这会减少要提交给目标的tokens的数量使其达不到weight，那么所有的tokens都不能被提交。一个无限的weight意味着由源提交的所有tokens必须先被接受才能通过边。（这可以与一个JoinNode合用使其满足一定的条件才接受所有的tokens；参见图15.21和15.59中的示例）。如果没有规定weight，那么这等价于weight为1.
注意. 一个弱但简单的weight替换方案是把信息组织到一个更大的对象中使得一个token就携带了所有需要的数据。
有两种类型的活动边：
- 控制流只能传输控制tokens（和一些由建模者规定的对象tokens，参见15.4中的对象节点的isControlType）。控制流用于显式地对活动节点的执行进行排序，因为在源活动节点执行结束并产生token之前目标活动节点不能接收控制token来启动执行。
- 对象流可以传输对象tokens。对象流建模对象节点之间值的流动。Tokens按照它们来自源的顺序被交付给目标活动节点。如果同时交付多个tokens，那么它们也是有序的，就如同它们是一次一个被交付一样。如果源是一个规定了次序的对象节点，那么从这个源提交的tokens要按照这个顺序交付给目标。（参见15.4中对来自一个对象节点的tokens的交付。）
不同于控制流，对象流还提供了对多播/接收、从对象节点对token进行选择和转换的额外支持，如下所述。