Issue 15850: Restrictions on decision nodes (uml2-rtf) Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com) Nature: Uncategorized Issue Severity: Summary: In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I’m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and 1) If the Object flow is good, the object flow is then passed to a downstream activity Or 2) If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision. Resolution: Revised Text: Actions taken: November 5, 2010: received issue Discussion: End of Annotations:===== te: Fri, 05 Nov 2010 14:47:47 -0400 From: "Chonoles, Michael J" Subject: Restrictions on decision nodes To: "uml2-rtf@omg.org" Thread-Topic: Restrictions on decision nodes Thread-Index: Act9Ge4gtbq2G9+RToS0qq5Wa7eiEg== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-05_10:2010-11-05,2010-11-05,1970-01-01 signatures=0 In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I.m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and 1) If the Object flow is good, the object flow is then passed to a downstream activity Or 2) If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision. Michael Chonoles Lockheed Martin Subject: RE: Restrictions on decision nodes Date: Fri, 5 Nov 2010 17:17:12 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Restrictions on decision nodes Thread-Index: Act9Ge4gtbq2G9+RToS0qq5Wa7eiEgABfnJw From: "Ed Seidewitz" To: "Chonoles, Michael J" Cc: Michael . In actual practice, I often also would like to be able to have a control flow come out of a decision diamond that has an object flow going in. Indeed, we often see this come up when we use activity diagrams semi-formally for business process models. (And, to be honest, since MagicDraw lets us do it, we sometimes go ahead and diagram it the way that seems to make the most sense, even if it isn.t strictly well-formed UML.) I think the main issue, in terms of activity model token offer semantics, is that decision nodes technically operate on offered tokens, not actually flowing tokens. When token is offered to a decision node, the node evaluates its condition and then offers the incoming token on one of its outgoing flows. If the incoming token is an object token, but the outgoing flow is a control flow, the token offered by the decision node would have to be a different token (a control token) than the incoming object token. But there is no control token to offer . decision nodes, as control nodes, don.t actually hold any tokens, they just gate offers. Thus the original object node would somehow have to be offered on the control flow as if it was a control token, and when the offer was finally accepted downstream, the original object token would have to be consumed and effectively replaced with a control token. This is a pretty technical reason not to be able to do something that seems to make modeling sense. But I wanted to point out that simply removing the syntactic restriction on decision node flows is not enough . one needs to carefully deal with the semantic consequences. I do believe the could be done, but it is enough of a change that I don.t expect it to happen any time soon. (Almost certainly not until after the UML 2.5 Spec Simplification FTF.) Fortunately, I believe there is another way to get the effect you want. That is to still use an object flow where you would like to have a control flow, but feed the object flow into a control pin. A control pin can accept object tokens like a regular pin, but, relative to its action, it effectively treats the incoming object flow like a control flow. That is, the action is enabled if the control pin has an object token to accept and is not enabled otherwise. If the action is enabled and fired, then the object token on the control pin is consumed and its value is discarded. I still don.t like this as much as actually being able to use a control flow, because people don.t expect pins to be used for control (and the semantics are actually not really specified very clearly). But this is what we.ve got. -- Ed -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Friday, November 05, 2010 2:48 PM To: uml2-rtf@omg.org Subject: Restrictions on decision nodes In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I.m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and 1) If the Object flow is good, the object flow is then passed to a downstream activity Or 2) If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision. Michael Chonoles Lockheed Martin Date: Mon, 08 Nov 2010 10:44:24 -0500 From: "Chonoles, Michael J" Subject: RE: RE: Restrictions on decision nodes To: Ed Seidewitz Cc: "uml2-rtf@omg.org" Thread-Topic: RE: Restrictions on decision nodes Thread-Index: Act9Ge4gtbq2G9+RToS0qq5Wa7eiEgABfnJwAI5TkAA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-08_07:2010-11-08,2010-11-08,1970-01-01 signatures=0 Ed, thanks for the very useful. answer. Part of the problem arises from the control nature of an object flow. As an appearance of object token on a pin could enable the start of a behavior. The control pin approach seems to work, though it looks most unexpected. And there are still problems. For example, it is unclear what typing rules apply. Can any object token be placed on a control pin? There could be a merge of object tokens before it enters the control pin. When merged object tokens enter a regular pin, I believe the types have to conform (be equal, or be some subtype of the pin.s type). What happens when merged incompatible object tokens enter a control pin? Thanks Michael LMCO From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, November 05, 2010 5:17 PM To: Chonoles, Michael J Cc: uml2-rtf@omg.org Subject: Ex: RE: Restrictions on decision nodes Michael . In actual practice, I often also would like to be able to have a control flow come out of a decision diamond that has an object flow going in. Indeed, we often see this come up when we use activity diagrams semi-formally for business process models. (And, to be honest, since MagicDraw lets us do it, we sometimes go ahead and diagram it the way that seems to make the most sense, even if it isn.t strictly well-formed UML.) I think the main issue, in terms of activity model token offer semantics, is that decision nodes technically operate on offered tokens, not actually flowing tokens. When token is offered to a decision node, the node evaluates its condition and then offers the incoming token on one of its outgoing flows. If the incoming token is an object token, but the outgoing flow is a control flow, the token offered by the decision node would have to be a different token (a control token) than the incoming object token. But there is no control token to offer . decision nodes, as control nodes, don.t actually hold any tokens, they just gate offers. Thus the original object node would somehow have to be offered on the control flow as if it was a control token, and when the offer was finally accepted downstream, the original object token would have to be consumed and effectively replaced with a control token. This is a pretty technical reason not to be able to do something that seems to make modeling sense. But I wanted to point out that simply removing the syntactic restriction on decision node flows is not enough . one needs to carefully deal with the semantic consequences. I do believe the could be done, but it is enough of a change that I don.t expect it to happen any time soon. (Almost certainly not until after the UML 2.5 Spec Simplification FTF.) Fortunately, I believe there is another way to get the effect you want. That is to still use an object flow where you would like to have a control flow, but feed the object flow into a control pin. A control pin can accept object tokens like a regular pin, but, relative to its action, it effectively treats the incoming object flow like a control flow. That is, the action is enabled if the control pin has an object token to accept and is not enabled otherwise. If the action is enabled and fired, then the object token on the control pin is consumed and its value is discarded. I still don.t like this as much as actually being able to use a control flow, because people don.t expect pins to be used for control (and the semantics are actually not really specified very clearly). But this is what we.ve got. -- Ed -------------------------------------------------------------------------------- From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Friday, November 05, 2010 2:48 PM To: uml2-rtf@omg.org Subject: Restrictions on decision nodes In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I.m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and 1) If the Object flow is good, the object flow is then passed to a downstream activity Or 2) If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision. Michael Chonoles Lockheed Martin