Issue 17311: Having a fork node as initial enabled node does not work (fuml-rtf) Source: LieberLieber Software (Mrs. Tanja Mayerhofer, mayerhofer(at)big.tuwien.ac.at.) Nature: Clarification Severity: Minor Summary: If a fork node is identified as initial enabled node in the method ActivityNodeActivationGroup.run(ActivityNodeActivationList), and the method ActivityNodeActivation.receiveOffer() is called for the ForkNodeActivation, the method ForkNodeActivation.fire(TokenList) does not produce any forked tokens (because there is no real incoming token for the fork node) and because of this, the method call this.sendOffers(forkedTokens) (last statement of the method ForkNodeActivationActivation.fire(TokenList)) does not result in offers sent to successor nodes but this should be possible. Resolution: A fork node is required to have a single incoming edge (this is Constraint [1] under Subclause 12.3.30 ForkNode in the UML Superstructure spec, constraints from which also apply to fUML). The intent is that a fork node only generates forked tokens based on tokens offered to it on that one incoming edge. More specifically, consider that the only way a fork node can be initially enabled (in fUML) is if the source for its one incoming edge is either outside the activity node activation group containing the fork node activation or it is in the same activation group but not yet activated. The first case occurs when the fork node is contained a structured node but is the target of an edge crossing into the structured node from a source outside it. In this case, receiveOffer is called on the (enabled) fork node activation when the structured node fires, and this operation in turn calls takeOfferedTokens, which accepts any tokens offered on the incoming edge into the fork node. If tokens have been offered on that edge previously to the structured node firing, then the fork node activation will create forked tokens for them and offer them on the outgoing edges from the fork node. On the other hand, if no tokens have been offered, then the fork node activation does nothing further, which is correct. The second case occurs when the fork node is part of a conditional node or a loop node and the source of the incoming edge is an action or pin within the same node. The executable nodes for a conditional or loop node are divided up into test and body parts, which are activated incrementally per the semantics of the containing nodes. Contained control nodes, however, are always activated unconditionally (or, in the case of a loop, on each iteration). If a fork node is thus activated before the source of its incoming edge is, then it is not possible for anything to have been offered on that edge yet and, therefore, it is correct that the fork node should not offer anything on its outgoing edges. If that source node is later activated and does eventually offer something on the edge to the fork node, then that will trigger another call to receiveOffer on the fork node activation, which will result in forked nodes being offered on outgoing edges as appropriate. So, the current semantics for fork nodes are actually correct. Revised Text: None. Disposition: Closed, No Change Revised Text: Actions taken: April 16, 2012: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 16 Apr 2012 08:52:56 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Tanja Mayerhofer Employer: Vienna University of Technology mailFrom: mayerhofer@big.tuwien.acat Terms_Agreement: I agree Specification: Semantics of a Foundational Subset for Executable UML Models Section: 8.5.2.2.9 FormalNumber: formal/2011-02-01 Version: 1.0 Doc_Year: 2011 Doc_Month: February Doc_Day: 01 Page: 205, 206 Title: DecisionNodeActivation can send offers to multiple outgoing edges Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: In the method DecisionNodeActivation.fire(TokenList), a token offer is sent to each outgoing edge for which the guard evaluates to true resulting in the execution of multiple successor nodes. Only one successor node should receive an offer also if the guards of several outgoing edges evaluate to true. From: Ed Seidewitz To: "mayerhofer@big.tuwien.acat" CC: "issues@omg.org" , "fuml-rtf@omg.org" Date: Mon, 16 Apr 2012 13:33:11 -0400 Subject: RE: issue 17311 -- fUML RTF issue Thread-Topic: issue 17311 -- fUML RTF issue Thread-Index: Ac0b5GF0qOmjqliORkeIc6kSDXkjrAADli3w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-20218-c X-Mailprotector-ID: ea0d4601-a19f-4a73-b1c0-9c7b4cf30496 Tanya . This is an interesting point, and somewhat related, I think, to Issue 17300 that I recently filed on activity final nodes. However, the situation is a bit different for fork nodes. Unlike a final node, a fork node is required to have a single incoming edge (this is Constraint [1] under Subclause 12.3.30 ForkNode in the UML Superstructure spec, constraints from which also apply to fUML). The intent is that a fork node only generates forked tokens based on tokens offered to it on that one incoming edge. More specically, consider that the only way a fork node can be initially enabled is if the source for its one incoming edge is either outside the activity node activation group containing the fork node activation or it is in the same activation group but not yet activated. The first case occurs when the fork node is contained a structured node but is the target of an edge crossing into the structured node from a source outside it. In this case, receiveOffer is called on the (enabled) fork node activation when the structured node fires, and this operation in turn calls takeOfferedTokens, which accepts any tokens offered on the incoming edge into the fork node. If tokens have been offered on that edge previously to the structured node firing, then the fork node activation will create forked tokens for them and offer them on the outgoing edges from the fork node. On the other hand, if no tokens have been offered, then the fork node activation does nothing further, which is correct. The second case occurs when the fork node is part of a conditional node or a loop node and the source of the incoming edge is an action or pin within the same node. The executable nodes for a conditional or loop node are divided up into test and body parts, which are activated incrementally per the semantics of the containing nodes. Contained control nodes, however, are always activated unconditionally (or, in the case of a loop, on each iteration). If a fork node is thus activated before the source of its incoming edge is, then it is not possible for anything to have been offered on that edge yet and, therefore, it is correct that the fork node should not offer anything on its outgoing edges. If that source node is later activated and does eventually offer something on the edge to the fork node, then that will trigger another call to receiveOffer on the fork node activation, which will result in forked nodes being offered on outgoing edges as appropriate. So, I think the current semantics for fork nodes are actually correct. Let me know if you agree. -- Ed From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, April 16, 2012 11:19 AM To: issues@omg.org; fuml-rtf@omg.org Subject: issue 17311 -- fUML RTF issue From: webmaster@omg.org Date: 16 Apr 2012 08:59:00 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Tanja Mayerhofer Employer: Vienna University of Technology mailFrom: mayerhofer@big.tuwien.acat Terms_Agreement: I agree Specification: Semantics of a Foundational Subset for Executable UML Models Section: 8.5.2.2.11 FormalNumber: formal/2011-02-01 Version: 1.0 Doc_Year: 2011 Doc_Month: February Doc_Day: 01 Page: 212 Title: Having a fork node as initial enabled node does not work Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: If a fork node is identified as initial enabled node in the method ActivityNodeActivationGroup.run(ActivityNodeActivationList), and the method ActivityNodeActivation.receiveOffer() is called for the ForkNodeActivation, the method ForkNodeActivation.fire(TokenList) does not produce any forked tokens (because there is no real incoming token for the fork node) and because of this, the method call this.sendOffers(forkedTokens) (last statement of the method ForkNodeActivationActivation.fire(TokenList)) does not result in offers sent to successor nodes but this should be possible. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org