Issue 14759: Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (bpmn2-rtf) Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com) Nature: Enhancement Severity: Significant Summary: Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349 ##Original Info: (Severity: Significant - Nature: Enhancement) Suggested by Michael Rowley: Add Exclusive conditional behavior from activities. "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task." This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>) Proposal TBD Resolution: The FTF agrees that this issue deserves further discussion, and could not agree on a resolution and deferred its resolution to a future RTF Disposition: Deferred Revised Text: Actions taken: November 20, 2009: received issue Discussion: Comments: From: wstephe created: Fri, 21 Nov 2008 17:43:58 -0600 (CST) Assigned to Hagen for now since there are execution semantics consequences of this feature. From: hvo created: Thu, 22 Jan 2009 09:11:32 -0600 (CST) Seems to be related to 145, at least for subprocesses, more precisely related to the discussion there whether we want to encapsulate alternative behavior in a subprocess and how we want to show that at the interface. From: bruce created: Sat, 24 Jan 2009 18:00:25 -0600 (CST) I don't think this is same as 145. This one uses normal semantics of subprocess completion. It is purely notational, and works the same regardless of the visual representation of the activity (unlike 145). Conditional sequence flow with the open diamond "implies" independent conditions (like OR gateway) but it "could" be used with exclusive conditions (like XOR gateway). This makes a clear distinction between the two forms of conditional sequence flow out of an activity. The downside is yet another graphic element. From: david_marston created: Sun, 25 Jan 2009 11:53:25 -0600 (CST) Maybe you just need to say that at a certain level of formality, explicit gateways are necessary. I think we don't want a mix of exclusive and inclusive minidiamonds, which would be the next requested feature once two kinds are allowed. If you are drawing the process for human consumption, be informal and show all exit conditions as inclusive (and use an annotation to state that formal rules exist, if that would ease your guilt). If you want a model that will compile into checkboxes and/or radio buttons, draw the necessary gateways. From: mariano.benitez created: Tue, 27 Jan 2009 12:37:28 -0600 (CST) I would really like to be able to define exclusive implicit gateways in the activity, this has been the behaviour of our product for the past 8 years and we never had a complain abou it. (This is just to express how much I like the idea, it is not an argument.) :) Now, I agree NOT to mix exclusive and inclusive minidiamonds. What I think is that the inclusive/exclusive behaviour is an attribute of the activity. The default SF out of the activity is actually an attribute of the activity itself, so we might well add another attribute "gateway behaviour" that would be inclusive or inclusive. Actually diamonds has nothing to do with the type of gateway they are flowing out from. I prefer an activity attribute that would rule for all conditional SF out of the activity. From: hvo created: Wed, 28 Jan 2009 02:30:27 -0600 (CST) Is there any reason why we would like to have this feature only on the output side but not on the input side? From: wstephe created: Wed, 28 Jan 2009 17:17:34 -0600 (CST) I understand Mariano's point of view on this issue. A few tool vendors involved in V1.0 had similar features and so the mini diamond was added. I would have preferred that ALL Sequence Flow control be handled by Gateways. Having both Gateways and mini diamonds is too much notation, in my opinion. BPMN is already dinged by people who say that it is too complex. I would not suggest that we remove the mini-diamonds, since they are legacy, but I would prefer that we don't add any more notation to V2.0 than we have to. I would recommend that we defer this issue. From: mariano.benitez created: Fri, 30 Jan 2009 08:21:32 -0600 (CST) I think multiple sequence flows in/out of activities is a reasonable shortcut that most of our customers use, it makes the visual diagram cleaner. Actually, in the case of multiple incoming sequence flows, it behaves like an exclusive gateway, different from the outgoing side. (see section 13.2.1) There is no reason why people would not want inclusive gateway semantics on the incoming side too. I don't think it is too much of a change to add 2 attributes that describe the incoming and outgoing behaviour, and it would make the semantics more consistent and flexible for users. So, I would recommend we open this issue with the proposal I just made. From: wstephe created: Fri, 25 Sep 2009 15:10:08 -0500 (CDT) Summary updated to match Beta 1 spec sections End of Annotations:===== s is issue # 14759 [OMG 14759] Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349 ##Original Info: (Severity: Significant - Nature: Enhancement) Suggested by Michael Rowley: Add Exclusive conditional behavior from activities. "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task." This was discussed on a BLOG (http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886) Proposal TBD Comments: From: wstephe created: Fri, 21 Nov 2008 17:43:58 -0600 (CST) Assigned to Hagen for now since there are execution semantics consequences of this feature. From: hvo created: Thu, 22 Jan 2009 09:11:32 -0600 (CST) Seems to be related to 145, at least for subprocesses, more precisely related to the discussion there whether we want to encapsulate alternative behavior in a subprocess and how we want to show that at the interface. From: bruce created: Sat, 24 Jan 2009 18:00:25 -0600 (CST) I don't think this is same as 145. This one uses normal semantics of subprocess completion. It is purely notational, and works the same regardless of the visual representation of the activity (unlike 145). Conditional sequence flow with the open diamond "implies" independent conditions (like OR gateway) but it "could" be used with exclusive conditions (like XOR gateway). This makes a clear distinction between the two forms of conditional sequence flow out of an activity. The downside is yet another graphic element. From: david_marston created: Sun, 25 Jan 2009 11:53:25 -0600 (CST) Maybe you just need to say that at a certain level of formality, explicit gateways are necessary. I think we don't want a mix of exclusive and inclusive minidiamonds, which would be the next requested feature once two kinds are allowed. If you are drawing the process for human consumption, be informal and show all exit conditions as inclusive (and use an annotation to state that formal rules exist, if that would ease your guilt). If you want a model that will compile into checkboxes and/or radio buttons, draw the necessary gateways. From: mariano.benitez created: Tue, 27 Jan 2009 12:37:28 -0600 (CST) I would really like to be able to define exclusive implicit gateways in the activity, this has been the behaviour of our product for the past 8 years and we never had a complain abou it. (This is just to express how much I like the idea, it is not an argument.) :) Now, I agree NOT to mix exclusive and inclusive minidiamonds. What I think is that the inclusive/exclusive behaviour is an attribute of the activity. The default SF out of the activity is actually an attribute of the activity itself, so we might well add another attribute "gateway behaviour" that would be inclusive or inclusive. Actually diamonds has nothing to do with the type of gateway they are flowing out from. I prefer an activity attribute that would rule for all conditional SF out of the activity. From: hvo created: Wed, 28 Jan 2009 02:30:27 -0600 (CST) Is there any reason why we would like to have this feature only on the output side but not on the input side? From: wstephe created: Wed, 28 Jan 2009 17:17:34 -0600 (CST) I understand Mariano's point of view on this issue. A few tool vendors involved in V1.0 had similar features and so the mini diamond was added. I would have preferred that ALL Sequence Flow control be handled by Gateways. Having both Gateways and mini diamonds is too much notation, in my opinion. BPMN is already dinged by people who say that it is too complex. I would not suggest that we remove the mini-diamonds, since they are legacy, but I would prefer that we don't add any more notation to V2.0 than we have to. I would recommend that we defer this issue. From: mariano.benitez created: Fri, 30 Jan 2009 08:21:32 -0600 (CST) I think multiple sequence flows in/out of activities is a reasonable shortcut that most of our customers use, it makes the visual diagram cleaner. Actually, in the case of multiple incoming sequence flows, it behaves like an exclusive gateway, different from the outgoing side. (see section 13.2.1) There is no reason why people would not want inclusive gateway semantics on the incoming side too. I don't think it is too much of a change to add 2 attributes that describe the incoming and outgoing behaviour, and it would make the semantics more consistent and flexible for users. So, I would recommend we open this issue with the proposal I just made. From: wstephe created: Fri, 25 Sep 2009 15:10:08 -0500 (CDT) Summary updated to match Beta 1 spec sections