TTC2015 Model Execution: Question about token rules

[GoogleCodeExporter]

According to the case description, join and merge nodes simply offer the 
incoming tokens on all outgoing control flow edges.  Fork and decision nodes 
have their own token passing rules which makes sense, of course.

However, why do opaque actions also have special token passing rules?  The case 
description says that an OpaqueAction creates one new control token and offers 
that to successor nodes.  Why doesn't it simply pass on the tokens it receives 
like join and merge nodes?

I have one special situation in mind: there is a fork node, and on the parallel 
branches of the fork there is a complex control flow containing 
decisions/merges, opaque actions, and possibly more fork/joins.  In such a 
parallel branch, decision/merge nodes just pass the ForkedToken they receive.  
Fork nodes would offer new ForkedNodes that have the incoming ForkedToken as 
baseToken.  In contrast, a OpaqueAction replaces the FokedToken with a new 
ControlToken.  Why this difference?

And another question: Fork nodes create ForkedTokens that wrap a baseToken.  
But that base token is never used.  So what is it good for?

Original issue reported on code.google.com by tsd...@gmail.com on 20 Apr 2015 at 11:10

[GoogleCodeExporter]

The semantics of actions and control nodes differ in handling tokens as defined 
by the fUML standard. The semantics of actions is to consume and produce 
tokens. On the other hand, the semantics of control nodes is to only route 
tokens to actions. Thus, control nodes do not produce tokens on their own. The 
exception is a fork node as it shall “fork” a token to multiple parallel 
paths. It thus cannot simple provide an incoming token to all outgoing edges, 
but instead provides a forked token pointing to the original incoming token as 
“base token”. I have to admit that the “base token” reference is not 
absolutely necessary if we only consider control flows. However, in the case of 
object flows, it is essential because an object token carries data that may be 
provided to multiple actions using fork nodes. In this case, the produced 
forked token referrers to the data carrying object token and via this 
reference, actions may access the data to be processed. While we do not 
consider object flows in this TTC case, we nevertheless decided to leave the 
semantics of fork nodes and fork tokens as defined by fUML.

Original comment by tanjaema...@gmail.com on 21 Apr 2015 at 9:17

• Changed state: Fixed

[GoogleCodeExporter]

Ok, thanks for the clarifications.

Original comment by tsd...@gmail.com on 21 Apr 2015 at 9:33