Issue 6153: Interactions view of state machines/activities (uml2-superstructure-ftf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Revision Severity: Critical Summary: Interactions should be able to show a message passing view on a state machine or activity, by referring directly to the invocation actions in those models. UML 1.4 worked this way. Resolution: see above Revised Text: Actions taken: August 30, 2003: received issue March 8, 2005: closed issue Discussion: See resolution of 7319. It introduces a link between interactions and actions that can be used for interactions to refer to actions contained in activities or state machines. End of Annotations:===== Name: Alan Moore Company: Artisan mailFrom: AlanM@artisansw.com Nature: Revision Severity: Critical Subject: Interactions view of state machines/activities Interactions should be able to show a message passing view on a state machine or activity, by referring directly to the invocation actions in Reply-To: From: "Conrad Bock" To: Subject: RE: ,ia, Issue 6153: Date: Tue, 14 Oct 2003 13:00:51 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9EGugQR012875 I think this is the top priority interaction issue. It used to be that interactions could refer directly to actions, for example in a state machine to identify which action sent a message. Now it refers to Behavior, which is too coarse-grained to identify the action. Interactions can no longer be used as "views" on other other behavior models. Conrad Issue 6153: Interactions view of state machines/activities Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Nature: Revision Severity: Critical Summary: Interactions should be able to show a message passing view on a state machine or activity, by referring directly to the invocation actions in those models. UML 1.4 worked this way Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Last draft of ballot 16 Date: Tue, 15 Jun 2004 18:53:56 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > I agree with your basic premise that data and control flow as defined > in the current activity model should be how actions get data and > control. Thanks for reiterating this, it is just the downstream effects I'm concerned about. > i. In interactions we need to be able to speak of actions > happening. This does not mean they get data or control, all we do is > state the mere fact that in the event trace we see the occurrence of > an action. Yes, I filed Issue 6153 (Interactions view of state machines/activities) about this, and mentioned to Nikloai that it was the most important issue in interactions, IMO. My concern is that we don't encourage profilers to solve this problem for us, because there needs to be a single standard for it. > ii. In state machines, we might want to describe actions standing in > a control and data flow relationship, and an activity is fine to > encapsulate those actions. OK, that helps. > However, there are certain things (ObjectFlow, ActivityParameterNode, > Partitions, and other semantic features of activities) that do not > make sense in this context. ActivityParameterNode is the only way to get data in and out of an activity, presumably you'd need that. Partitions aren't in BasicActivties. ObjectFlow is needed even to use the variable actions, unless we resolve issue 7394 (Variable pins). > iii. For simple methods defined in an action language again we want > the basic data and control flow mechanism of activities, but not the > machinery that Activities add for conventional activity modeling. > Unfortunately, some of that is already in BasicActivities. See above. OMG Issue No: 6153 Title: Interactions view of state machines/activities Source: ARTISAN Software Tools (Mr. Alan Moore, alan.moore@artisansw.com) Summary: Interactions should be able to show a message passing view on a state machine or activity, by referring directly to the invocation actions in those models. UML 1.4 worked this way. Discussion: Allow both general Behaviors and Actions to be the source of the ExecutionOccurrence . but not both. This requires the following changes: 1. Change the diagram in Figure 328 to the following diagram (includes previous fixes to the same diagram) that adds a new association between Executionoccurrence and Action 2. Add the following entry to the list of association ends of the metaclass ExecutionOccurrence (on page 417): · action : Action [0..1] The Action that resulted in this ExecutionOccurrence. 3. Add the following constraint to the ExecutionOccurrence class (on page 417): [2] An ExecutionOccurrence is represented as caused either by a Behavior or by an Action. (action->notEmpty() implies behavior->isEmpty()) and (behavior->notEmpty()) implies action->isEmpty()) 4. Replace the package diagram on page 404 with the following diagram that adds an import dependency between BasicInteractions and BasicActivities: Disposition: Resolved Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 20 Date: Fri, 23 Jul 2004 15:57:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 20. Conrad 6153 (Interactions view of state machines/activities) This is being addressed in 7319, where we are avoiding introducing an xor. 6157 (Property string undefined) I gather this is consistent with 7135? 7135 (adopt a single notation to specify text strings used in the notation) Will this be updated to allow constraints on attributes, parameters, etc, like the old property list? 7253 (UML Sequence diagram) This is actually an activity issue. My proposed resolution text would be: "The arrows in activity diagrams are flows, not messages, so cannot be asynchronous. For more explanation, see http://www.jot.fm/issues/issue_2004_07/column4." 7328 (enumerated type MessageSort) Seems like "asynchSignal" should be "signal". There aren't any To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 20 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 23 Jul 2004 16:33:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/23/2004 16:33:08, Serialize complete at 07/23/2004 16:33:08 Thanks, Conrad. My feedback below: > 6153 (Interactions view of state machines/activities) > > This is being addressed in 7319, where we are avoiding introducing > an xor. Fair enough. However, I will keep this in the ballot, just in case 7319 gets hung up (as it might). If and when that resolution is adopted, it is no problem to overwrite this resolution. > 6157 (Property string undefined) > > I gather this is consistent with 7135? Yes. Karl and I worked together on this. > 7135 (adopt a single notation to specify text strings used in the > notation) > > Will this be updated to allow constraints on attributes, parameters, > etc, like the old property list? Yes. > 7253 (UML Sequence diagram) > > This is actually an activity issue. My proposed resolution text > would be: > > "The arrows in activity diagrams are flows, not messages, so > cannot be asynchronous. For more explanation, see > http://www.jot.fm/issues/issue_2004_07/column4." OK. Replaced my resolution with yours but retained "closed, no change" disposition. > 7328 (enumerated type MessageSort) > > Seems like "asynchSignal" should be "signal". There aren't any > synchronous signals are there? True, but it is useful to include the "asynch" reminder. It is also consistent with the format of the other enumerations. Cheers...Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 20 Date: Sat, 24 Jul 2004 15:23:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > 6153 (Interactions view of state machines/activities) > > > > This is being addressed in 7319, where we are avoiding > introducing > > an xor. > > Fair enough. However, I will keep this in the ballot, just in > case 7319 gets hung up (as it might). If and when that > resolution is adopted, it is no problem to overwrite this resolution. Then it would good to update it with the solution I copied to on, that doesn't use xor. We aren't using that anywhere else that I know of in UML 2. Thomas and I agreed to do it as subclassing. Wouldn't hurt to pull this for one more cycle. Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 20 Date: Sat, 24 Jul 2004 15:23:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > 6153 (Interactions view of state machines/activities) > > > > This is being addressed in 7319, where we are avoiding > introducing > > an xor. > > Fair enough. However, I will keep this in the ballot, just in > case 7319 gets hung up (as it might). If and when that > resolution is adopted, it is no problem to overwrite this resolution. Then it would good to update it with the solution I copied to on, that doesn't use xor. We aren't using that anywhere else that I know of in UML 2. Thomas and I agreed to do it as subclassing. Wouldn't hurt to pull this for one more cycle. Conrad From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: Draft of ballot 20 Date: Sun, 25 Jul 2004 02:04:22 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments, late due to travel... Issue 6153: This issue resolution overlaps with the issue resolution worked out by Conrad with respect to the action/activity simplification. The resolution by Conrad is somewhat more encompassing and does not leverage the xor relationship which we have decided to not deploy (I believe) in UML2. I suggest that the two issue resolutions get harmonized and only one be submitted. Issue 6381: I believe this issue resolution should await the final resolution of the activity/action issue, as the mapping between notation and abstract syntax cannot be finalized until that issue is dispatched with. I recommend to wait with this resolution. Issue 6608: I believe that it would be more consistent to follow suggestion (2) rather than (3). I suggest we discuss this further. Cheers, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 22, 2004 2:44 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Draft of ballot 20 Here is the current draft of ballot 20. Eran, I changed your resolution to reflect the new BNF format that we are hoping to adopt as part of issue 7135. There are 25 resoutions in this ballot at present. I expect that karl will likely have at least one more resolution. Please review and tell me if you have any objections to any of the resolutions -- before noon tomorrow, if possible. Cheers, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 20 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sun, 25 Jul 2004 13:31:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/25/2004 13:31:57, Serialize complete at 07/25/2004 13:31:57 Thanks, Thomas. Here is the situation regarding the issues you mention: 6153: I will pull that when I see the action/activity harmonization posted. Until then, I will leave it in. 6381 and 6608: the problem here is that these two resolutions were submitted by Eran before he left on 3 weeks of vacation. he won't be back until after the Montreal meeting and will not be checking his e-mail. Note that, in both cases, approving these resolutions in advance of the action/activity harmonization is not a big problem. The later resolution will simply supersede the former one. We've already had a number of these cases (including, notably, one resolution that made Action concrete and another later one that made it abstract again). The advantage of doing it this way is that we at least have a resolution to these issues in case the action/activities unification gets bogged down. So, it may be best to just leave the ballot as is. Regards, Bran "Thomas Weigert" 07/25/2004 03:04 AM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Draft of ballot 20 Bran, comments, late due to travel... Issue 6153: This issue resolution overlaps with the issue resolution worked out by Conrad with respect to the action/activity simplification. The resolution by Conrad is somewhat more encompassing and does not leverage the xor relationship which we have decided to not deploy (I believe) in UML2. I suggest that the two issue resolutions get harmonized and only one be submitted. Issue 6381: I believe this issue resolution should await the final resolution of the activity/action issue, as the mapping between notation and abstract syntax cannot be finalized until that issue is dispatched with. I recommend to wait with this resolution. Issue 6608: I believe that it would be more consistent to follow suggestion (2) rather than (3). I suggest we discuss this further. Cheers, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 22, 2004 2:44 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Draft of ballot 20 Here is the current draft of ballot 20. Eran, I changed your resolution to reflect the new BNF format that we are hoping to adopt as part of issue 7135. There are 25 resoutions in this ballot at present. I expect that karl will likely have at least one more resolution. Please review and tell me if you have any objections to any of the resolutions -- before noon tomorrow, if possible. Cheers, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 20 Date: Mon, 26 Jul 2004 09:29:01 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > 6153: I will pull that when I see the action/activity > harmonization posted. Until then, I will leave it in. The resolution wasn't coordinated with the interested parties. We can post an agreed-upon one separately from the action/activity issue if you like. Leaving an unagreed resolution on the ballot isn't the process we have adopted so far, and can't be corrected, since the issue will be off the table. Please pull 6153. Conrad