处理所有项目时，如何终止模式流的扩展区域？
考虑模式的最简单扩展区 流。根据 uml文档（16.12扩展区域）
如果[ mode ]的值是 stream ，则完全有一个扩展执行，并且在每个集合的流中提供了该执行的元素值。也就是说，输入元素节点上集合的每个元素分别以一个令牌为单位，一个一个一个一个，一个从扩展名中的所有传出活动上。
但是，这种扩展区将永远不会结束！一旦处理了input扩展名称的所有令牌，做某事将无限期地等待来自input> Input的令牌，这将永远不会出现！如何终止此扩展区域？
更新：似乎我能找到的唯一解决方案是以下内容（但我不确定，请参见下文）：
当没有更多的标记可从执行某件事不接受的控制令牌通过c.3-c.4-c.2路径，因为根据16.2 .3.4活动中的动作和大头针
在活动中执行操作需要提供其所有必要令牌的所有输入 最小多重性
，根据15.2.3.2活动节点
当活动节点开始执行时，令牌为 从某些或全部传入的活动中接受并将令牌放置在节点上。
因此，从上面的结论中得出结论（即做某事）似乎是合理的，如果无法执行该令牌，则不会接受控制令牌，因此决策节点将通过令牌传递以控制Flow C.5，因为它具有“否则”守护，根据15.3.3.6决策节点：
仅与决策节点一起使用，一个预定义的后卫“ else”以“否定”为表达式作为其操作员而无操作数），最多可用于最外向的边缘。只有在决策节目中没有任何其他外向的边缘接受令牌时，此守卫才能评估为true。
更新2 ：循环（C.1-C.2-C.3）是否需要？在我看来，答案是“是”，因为没有它做某事只会处理一个对象令牌！ IE 做某事将根据15.2.3.6的活动执行在扩展区的调用中接收单个控件令牌
首次调用活动时，除输入活动Parameternodes以外，其节点最初都不会容纳任何令牌。但是，没有传入边缘并且不需要执行输入数据的节点将立即启用。单个控件令牌放置在每个启用节点上，并开始同时执行。这样的节点包括没有传入控制流的执行顺序（请参见子句15.5），也没有强制性输入数据和初始点数（请参见子句15.3）。
并根据15.5.3.1可执行节点
当执行程序完成执行时，代表执行的控件令牌从 executableNode和控件令牌均在ExecutablaDode的所有传出控制流上提供。
UML文档中是否有任何澄清说，控制令牌可以“停留” 做某事（无循环）并重新启用其执行以处理下一个对象令牌？
Consider the simplest ExpansionRegion of mode stream. According to UML Documentation (16.12 Expansion Regions)
If the value [of mode] is stream, there is exactly one expansion execution, and element values are offered to this execution in a stream from each collection. That is, each element of a collection on an input ElementNode is offered separately as a token, one by one, on all outgoing ActivityEdges from the ExpansionNode
But this ExpansionRegion will never end! As soon as all tokens from input ExpansionNode are processed, Do something will be waiting indefinitely for a token from input, which will never come! How do I terminate this ExpansionRegion?
Update: it seems the only solution I could find is the following (but I'm not sure, see below) :
When there are no more tokens available from input then the control token from Do something is not accepted by Do something through C.3-C.4-C.2 path since according to 16.2.3.4 Actions and Pins in Activities
Executing an Action in an Activity requires all of its InputPins to be offered all necessary tokens, as specified by their
minimum multiplicity
and according to 15.2.3.2 Activity Nodes
When an ActivityNode begins execution, tokens are
accepted from some or all of its incoming ActivityEdges and a token is placed on the node.
so it seems reasonable to conclude from the above that Action (i.e. Do something) will not accept a control token if it is not able to execute so Decision node will pass the token to control flow C.5 since it has "else" guard and according to 15.3.3.6 Decision Nodes:
For use only with DecisionNodes, a predefined guard “else” represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode.
Update 2: Is the loop (C.1-C.2-C.3) required? It seems to me the answer is "yes" because without it Do something would process just one object token! I.e. Do something would receive a single control token at the ExpansionRegion's invocation according to 15.2.3.6 Activity Execution
When an Activity is first invoked, none of its nodes other than input ActivityParameterNodes will initially hold any tokens. However, nodes that do not have incoming edges and require no input data to execute are immediately enabled. A single control token is placed on each enabled node and they begin executing concurrently. Such nodes include ExecutableNodes (see sub clause 15.5) with no incoming ControlFlows and no mandatory input data and InitialNodes (see sub clause 15.3).
and according to 15.5.3.1 Executable Nodes
When an ExecutableNode completes an execution, the control token representing that execution is removed from the
ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode.
Are there any clarification in UML Documentation saying that control token could "stay" on Do something (without the loop) and re-enable its execution to process next object token?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您似乎认为自己建模了僵局。实际上，UML活动无法定义具有僵局。当启用所有包含的动作时，执行所有操作容器（活动和结构性努力及其子类型）结束。
处理输入集合中的最后一个元素后，不再启用操作，因此，扩展区域结束并为输出对象流提供了输出集合。因此，不需要初始节点和所有控制流。
话虽如此，您可能需要控制流量，因为您还有其他动作。假设您需要
初始化在第一次执行之前系统，并且每次执行。您的第一个示例可以很好地效果。只需在执行执行某件事c.1和上放置在c.3上做其他事情。如果您必须在离开扩展区域之前进行一些
清理，则可以使用第二个解决方案。只需将其放在C.5上即可。我不知道这会起作用，但是在重读了您引用的规范文本之后，我同意它在起作用。You seem to think that you modeled a deadlock. Actually, UML Activities cannot have deadlocks by definition. The execution of all action containers (Activitys and StructuredActivityNodes with their subtypes) ends when none of the contained actions is enabled.
After processing the last element in the input collection, no action is enabled anymore and therefore, the expansion region ends and offers the output collection to the outgoing object flow. Therefore, the initial node and all the control flows are not needed.
Having said that, it is possible, that you need control flows, because you have additional actions. Let's say you need to
initializethe system before the first execution andDo something elseafter each execution ofDo something. Your first example works well for this. Just placeinitializeonC.1andDo something elseonC.3.Your second solution could be used, if you have to do some
cleanupbefore leaving the expansion region. Just place it onC.5. I was not aware, that this would work, but after rereading the specification text cited by you, I agree that it is working.似乎您错过了对象令牌足以触发动作的观点 - 无需控制令牌。
UML 2.5 p。 374：
因此，一旦摆脱了启动节点和多余的控制结构，就会得到所需的行为：动作始于接收对象并在发射结果对象时结束。
我找不到一个完整的例子，但是那张图片足以说明它：
p.478 of UML 2.5 ：（请探讨规格有关更多详细信息）
如您所见，扩展区域是一个“简单”动作，它采用对象并返回另一个动作。因此，就像任何简单的动作具有输入引脚的任何简单动作，如我的答案中所示。这意味着它将开始收到对象并在完成后发射（最终是空的）对象。
It seems like you missed the point that object tokens are sufficient to trigger an action - without any need for a control token.
UML 2.5 p. 374:
So once you get rid of the start node and the superfluous control structures you will get the desired behavior: the action starts with receiving an object and ends when emitting the resulting object.
I could not find a full fledged example on the fly, but that picture illustrates it well enough:
Longer explanation
P. 478 of UML 2.5: (please look into the specs for more details)
As you can see, the expansion region is a "simple" action that takes an object and returns another. As such it's like any simple action with an input pin like shown above in my answer. That means it will start upon receipt of an object and emit an (eventually empty) object when it's done.