UML stream模式ExpansionRegion处理完所有项后如何终止

基础场景与原生缺陷 #

我们讨论mode=stream配置下的最简ExpansionRegion场景。根据UML 2.5.1规范16.12节（Expansion Regions章节）的定义：当mode设为stream时，ExpansionRegion仅生成1个扩展执行实例，所有输入集合的元素以流形式逐一向该实例交付——输入ElementNode对应集合的每个元素会单独生成1个token，经ExpansionNode的所有传出ActivityEdge逐个传递给区域内的执行逻辑。

该最简原生结构存在明确的无法终止缺陷：当input ExpansionNode的所有token全部处理完成后，区域内的Do something动作会持续等待永远不会抵达的input token，陷入永久阻塞。

合规的终止实现方案 #

目前验证到一种完全符合UML规范的可行实现：引入DecisionNode搭配回流控制逻辑，核心逻辑为：当input节点无可用token时，Do something输出的控制token无法通过C.3-C.4-C.2的回流路径被Do something接收。
该方案的合规性来自三条UML规范的明确规则推导：

• 16.2.3.4节（Activities章节下的Actions and Pins部分）：活动中的Action必须等所有InputPin都收到最小多重性规定的全部必要token后，才能启动执行。
• 15.2.3.2节（Activity Nodes章节）：只有ActivityNode满足启动执行的条件时，才会从部分或全部传入ActivityEdge接收token，放置到自身节点上。
• 15.3.3.6节（Decision Nodes章节）：DecisionNode专属的预定义守卫else最多只能绑定1条传出边，仅当token无法被DecisionNode其余所有传出边接收时，else守卫才会求值为true。

按照上述规则，当Do something（Action类型）因缺少input token不满足执行条件时，不会接收回流路径上的控制token；此时DecisionNode会自动将token路由到绑定else守卫的控制流C.5，直接触发ExpansionRegion的终止流程，从机制上避免无限等待。

回流循环结构的必要性 #

针对C.1-C.2-C.3构成的控制流循环是否为必需结构的问题，目前推导结论为该循环是强制必需的：如果移除该循环，Do something仅能处理1个对象token，无法适配stream模式的逐元素处理要求。
该结论同样基于UML规范的两条明确规则：

• 15.2.3.6节（Activity Execution章节）：Activity首次被调用时，除输入ActivityParameterNode外，其余所有节点初始状态下不持有任何token；无传入边、无强制输入数据要求的节点会被立即启用，每个被启用的节点会获得1个控制token并并发启动执行，这类节点包括无传入ControlFlow的节点、无强制输入要求的ExecutableNode、InitialNode。
• 15.5.3.1节（Executable Nodes章节）：ExecutableNode完成一次执行后，对应该次执行的控制token会从节点上移除，同时向节点的所有传出ControlFlow输出控制token。

也就是说，如果没有循环回流路径，Do something仅会在ExpansionRegion刚被调用时获得1次初始控制token，执行1次后控制token就会被清除，没有新的控制token触发下一轮执行，最终只能处理1个输入元素，完全不符合stream模式的设计预期。

待确认的规范问题 #

目前未在UML 2.5.1规范中找到对应明确条款，需要确认：是否存在正式规则说明，在无需上述循环结构的前提下，控制token可以“驻留”在Do something节点上，在新的对象token流入时自动重新触发节点执行，完成下一个元素的处理？

内容的提问来源于stack exchange，提问作者zer0hedge