Issue 6512: Guard conditions at fork nodes - UML2 Superstructure issue (uml2-superstructure-ftf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: I have a question about the token flow traffic rules within activity models: It is allowed to have guards at outgoing edges from fork nodes. The specification says about fork nodes: "When an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edges." This means that the fork node offers tokens to its outgoing edges, if all guard conditions evaluates to true. So there is a dependency between the parallel flows after a fork node. Is that true? I think the fork node should offer tokens on all outgoing edges that accept the token. If there is a guard condition at an outgoing edge, it is possible that the flow continues only on two of three outgoing edges. Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 8, 2005: closed issue Discussion: See issue 7221 for discussion. In ForkNode class, semantics section, first paragraph, replace the second sentence with: "If at least one outgoing edge accepts the token, duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not accept the token due to failure of their targets to accept it keep their copy in an implicit FIFO queue until it can be accepted by the target. The rest of the outgoing edges do not receive a token (these are the ones with failing guards). This is an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see Activity)." Disposition: Resolved End of Annotations:===== -Return: cris.kobryn@telelogic.com Date: Sat, 08 Nov 2003 07:20:23 -0000 From: "Cris Kobryn" To: juergen@omg.org, issues@omg.org, cris.kobryn@telelogic.com Subject: Fwd: Guard conditions at fork nodes - UML2 Superstructure issue User-Agent: eGroups-EW/0.82 X-Mailer: Yahoo Groups Message Poster X-Originating-IP: 68.71.8.84 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hA88KDNA023363 --- In u2p-issues@yahoogroups.com, "Tim Weilkiens" wrote: I have a question about the token flow traffic rules within activity models: It is allowed to have guards at outgoing edges from fork nodes. The specification says about fork nodes: "When an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edges." This means that the fork node offers tokens to its outgoing edges, if all guard conditions evaluates to true. So there is a dependency between the parallel flows after a fork node. Is that true? I think the fork node should offer tokens on all outgoing edges that accept the token. If there is a guard condition at an outgoing edge, it is possible that the flow continues only on two of three outgoing edges. Thanks for hints! Tim --- E-Mail tim.weilkiens@o... Fon ++49 +40 41 42 50 - 25 Fax ++49 +40 41 42 50 - 50 oose.de Dienstleistungen für innovative Informatik GmbH Oberstraße 14b, D-20144 Hamburg Amtsgericht Hamburg HRB 66648 Geschäftsführer Bernd Oestereich Internet www.oose.de --- End forwarded message --- Reply-To: From: "Conrad Bock" To: "Jan Hendrik Hausmann" , Cc: "Tim Weilkiens" Subject: RE: UML 2 Superstructure/Activity Diagrams: Relax Traverse-to-Completion semantics Date: Wed, 14 Apr 2004 10:51:14 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Jan, Thank you for your detailed comments. They are generalizations of an issue already filed (6512, guard conditions at fork nodes, http://www.omg.org/issues/issue6512.txt), and raise the the priority of resolving it. Regarding your proposals: Removing the action rule increases the chance of deadlock without a way of preventing it. For example, if the action input rule were removed, how would deadlock be prevented in the original carpenter example? Buffering at joins only addresses your point about Figure 212. What about the others? It wouldn't resolve Issue 6512. I think adding more queues will make the model more difficult to interpret. Other comments below and attached in Acrobat notes, Conrad The purpose of TTC is just to simplify the queuing model by restricting it to only one kind of node (object node). It's separate from the requirement that inputs are taken all at once, which is to address deadlock. The resolution to your modification of the carpenter example is to clean the drills and test the cords before putting them in the central buffer. You can always construct an uncommon example that will cause deadlock in any behavior model. Agreed the action input rule is nonlocal, but the object nodes it synchronizes are (ie, they the input pins to one action). Offers made to the input pins come and go, and when they are all there, the pins can accept the tokens. This is the same principle as join nodes and Petri Net transitions. OMG Issue No: 6512 Title: Guard conditions at fork nodes - UML2 Superstructure issue Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: I have a question about the token flow traffic rules within activity models: It is allowed to have guards at outgoing edges from fork nodes. The specification says about fork nodes: "When an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edges." This means that the fork node offers tokens to its outgoing edges, if all guard conditions evaluates to true. So there is a dependency between the parallel flows after a fork node. Is that true? I think the fork node should offer tokens on all outgoing edges that accept the token. If there is a guard condition at an outgoing edge, it is possible that the flow continues only on two of three outgoing edges. Discussion: See issue 7221 for discussion. In ForkNode class, semantics section, first paragraph, replace the second sentence with: "If at least one outgoing edge accepts the token, duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not accept the token due to failure of their targets to accept it keep their copy in an implicit FIFO queue until it can be accepted by the target. The rest of the outgoing edges do not receive a token (these are the ones with failing guards). This is an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see Activity)." Disposition: Resolved hausmann-ttc-cb.pdf