Issue 6381: Figure 395 requires a lot more explanation (uml2-superstructure-ftf) Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk) Nature: Uncategorized Issue Severity: Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. Resolution: see above Revised Text: Actions taken: October 23, 2003: received issue March 8, 2005: closed issue Discussion: The intent for this presentation option is to provide a graphical representation for triggers and actions attached on a transition. This notational enhancement is not about mixing activity graph notation into a statemachine. Therefore, the answer to Alan’s question is that all the graphical segments connecting action and trigger symbols map to a single transition. Semantically the transition is the one that owns the activity that contains the actions represented by the symbols. It is a tool implementation issue whether a transition with graphical actions is composed by creating a transition and then attaching the action/trigger symbols to it, or nodes are created and connected by several graphical segments which all map to a single transition. The proposed resolution: Metamodel: Add an import dependency between BehaviorStateMachines and StructuredActivities. BehaviorStateMachines ProtocolStateMachines MaximumOneRegion <<merge>> Kernel BasicBehaviors Interfaces Ports <<merge>> <<merge>> <<merge>> StructuredActivities Notation section shall be updated as the table below: Issue6381Table.pdf The text starts with “The following icons provide” through figure 395 shall be replaced with the following: Presentation options Triggers and actions may be notated either textually or using graphical symbols on a transition. This section describes the graphical presentation option. The graphical action presentation of a transition consists of one or more graphical symbols attached on a transition each representing a trigger or an action. The sequence of symbols may consist of a single trigger symbol (or none), a sequence of zero or more signal send or action sequence symbols. All the action symbols are mapped to an activity containing a sequence node that sequences the actions according to their graphical order on the transition path. Each action symbol is mapped to an instance of an action in that sequence. In case of an actionsequence symbol, it may be mapped to an opaque action or to a sequence of action or activity node instances in case where the actions in the sequence symbols are mapped to the action semantics. In principle, tools supporting the actions presentation options shall support also the BasicActivities package and the StructuredActivities package, which are the semantic concepts supporting that notation. Otherwise, the entire set of actions in a transition shall be mapped to an opaque behavior, where there is no semantic mapping to the action symbols. The graphical nodes split one logical transition to several graphical arrow segments, all mapped to a single transition instance (see Figure 395). It is not prescribed here whether this graphical action presentation is composed from a single graphical line segment with attached icons, or several line segments connecting the icons. This is a tool issue and up to the decision of tool builders. Signal receipt The “signal receipt” symbol may be shown as a five-pointed polygon that looks like a rectangle with a triangular notch in one of its sides (either one). It represents the trigger of the transition. The textual trigger specification is denoted inside the symbol, similar to the textual notation. Specifically, if the transition owns a guard, the guard is also described within the signal receipt icon, using the textual notation: <trigger> ‘[‘ <guard> ‘]’ The signal receipt is always first in the path of symbols and a transition path can only have at most one such symbol. Signal sending Signal sending is a common action that has a special notation. It may be shown as a five-pointed polygon that looks like a rectangle with a protruding triangle on one of its sides (either one). The actua l parameters of the signal are shown inside the symbol. On a given path, the signal sending graphic must follow the signal receipt icon if the latter exists. The signal sending symbol maps to a SendSignalAction within the activity owned by the transition on which the graphic is attached. If a tool uses only basic actions, the sent signal may be captured within the body of an instance of an opaque action. It is possible to have multiple signal sending nodes on a transition path. Action sequence An action sequence node is a rectangle that contains a textual representation of actions owned by the transition. The action sequence symbol must follow the signal receipt symbol if one exists for that transition. The action sequence symbol is mapped to an opaque action, or to a sequence symbol containing instances of actions recursively. Note that the graphical action presentation option combines only the above symbols into a single transition. Choice and junction symbols (see Figure 395) for example, are not mapped to actions on transition but to choice and junction pseudo-states (note that similar symbols are also used in activity graphs in which they map to actions, but in state machines they map to pseudo states). Therefore figure 395 consists of 4 transitions: from idle to the choice symbol, each of the branches of the choice through the junction symbol, and a transition from the junction to the busy state. End of Annotations:===== m: "Moore, Alan" To: issues@omg.org Subject: UML2 Super/Transitions Date: Thu, 23 Oct 2003 18:02:38 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) 03-08-02.pdf Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in OMG Issue 6381 Title: Figure 395 requires a lot more explanation Source: ARTISAN Software Tools (Mr. Alan Moore, mailto:%20alan.moore@artisansw.com) Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. Discussion: The iconic representation of transitions will be further clarified. In Page 502 the paragraph describing The iconic notation will be added the following clarifications - The signalReceipt, SignalSend and Action sequence are NOT nodes of the Statemachine but icons attached to a transition. The fragments .between. the icons are essentially graphical fragments of a single transition. Therefore the fragments do not map to any semantic concept. The mechanics of how an iconic transition is composed is a tool issue and not discussed here. - The iconic notation is NOT based on activity graphs notation and/or concepts. The ActionSequence icon represents a .black box. activity which is either described as a graph somewhere else or using textual notation. - A transition may have up to 3 icons in the following order: signalReceipt, SignalSend, ActionSequence Disposition: Resolved From: Eran Gery To: Branislav Selic Cc: Guus Ramackers , UML Superstructure FTF Subject: RE: SM resolutions for ballot 5 Date: Mon, 19 Jan 2004 11:28:02 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Bran See inline. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sun, January 18, 2004 9:11 PM To: Eran Gery Cc: Guus Ramackers; UML Superstructure FTF Subject: Re: SM resolutions for ballot 5 Thanks, Eran. (BTW, please use my new e-mail address and get rid of the old Rational one: it is no longer valid. The new one is in this e-mail.) I have some feedback now, but may have some more later as I review the proposed resolutions in more detail later: Issue 6229: Can you please provide the proposed diagram in your resolution text. I am really sorry to be so fussy, but, according to the formal OMG rules, we vote on the EXACT text (and graphics) and not a description of it -- the same goes for graphics. I may make an exception of metamodel changes in some cases, but even those should, in principle, be explicit. [EG] I will fix that for the ballot. The question I have is whether in order to get feedback we can send out drafts that outline the resolutions, and the have the final thing in the ballot. Also in terms of process it is more efficient, as if the FTF pushes back on a resolution outline there's no point to spend the time and do all this fine tuning. Issue 6256: I guess this has to be completed with the activities changes. So, until Conrad provides the appropriate changes, I do not think this is closed. Also, are there not text changes accompanying this: in the description of the associations of the corresponding metaclasses. Those too should be included in the resolution text. Until those changes are in there, I cannot consider this solution adequate. [EG] OK - So I will remoe it from the ballot. Issue 6381: It would be nice if we had agreement from Alan Moore (who raised the issue) before we submitted this one for a vote. [EG] I believe I have well addressed Alan's request for clarification. Also, I do not see anything controvercial here. Nevertheless I will solicit his feedback on the proposal. Issue 6395: The problem with this resolution is that (a) it creates backward compatibility problems (at least for Rose RT users) and (b) I do not agree that changing the trigger is tantamount to changing a feature definition. In most cases, it changes the way that an event is handled in a given state -- it does not remove the operation. I would like more discussion on this resolution. [EG] I will remove it from ballot5 then. By definition it can't be a backward compatibility issue as inheritance was not specified in UML 1. So compatibility should not be part of the debate. To repeat, I apologize for being such a stickler to precise formats, but I think that this is the only way that we can ensure that there are no misunderstandings about what goes into the final text of the revised submission. I plan to enforce this discipline consistently throughout the process. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com Eran Gery 01/18/2004 01:25 PM To: UML Superstructure FTF cc: Guus Ramackers , "Bran Selic (E-mail)" Subject: SM resolutions for ballot 5 Attached 11 proposed resolution for Statemachines. Most are trivial, few less... Thanks, Eran #### SM-proposals-ballot5.doc has been removed from this note on January 18, 2004 by Branislav Selic the diagrams section. OMG Issue 6381 Title: Figure 395 requires a lot more explanation Source: ARTISAN Software Tools (Mr. Alan Moore, mailto:%20alan.moore@artisansw.com) Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. - Discussion: There issue here indeed requires slight modification of the statemachine metamodel to accommodate this notation. The intent for this .transition oriented. notation is to instantiate statemachine classes and not mix in activity graph fragments, as might implied by the notation. Therefore, the answer to Alan.s question is That ALL arrows are transitions. The only exception is the activity and send signal symbols that should map to activities. The proposed resolution: Metamodel: Multiplicity between transition and activity will change to * with an {ordered} constraint, such that a transition may contain several activities including a send actions. Notation section: The signal receipt, signal send and action symbols shall be added to the diagram section, each references the transition section. The text before figure 395 will be updated as follows. The section will be titled .Transition iconic notation.. The following paragraph also accounts for issue 6608 which also related to the iconic notation. Transition iconic notation An alternative notation, which is also referred as .transition oriented., uses explicit icons to represent the trigger and actions(s) owned by a transition. Note although the iconic representation of a transition results in several icons connected on a path (see Figure 395), they all map to a single transition instance, a trigger instance, and list of action instances. Whether the transition path containing the icons consists of a single graphical segment with icons attached to, or several graphical segments connecting the icons, is a tool issue and not prescribed here. As discussed above, the entire path is mapped to a single transition regardless of its graphical management by a tool. Signal receipt The trigger of a transition, known as a .signal receipt. symbol, may be shown as a concave pentagon that looks like a rectangle with a triangular notch in its side (either side). The signature of the signal is shown inside the symbol. In case the transition owns a guard, the guard is also described within the signal receipt icon, using the textual signal[guard] notation. The signal receipt is always first in the path of icons and a transition path can only have only such icon. Signal sending Signal sending is a common action that has a special notation, among many other possible actions. It is may be shown as a convex pentagon that looks like a rectangle with a triangular point on one side (either side). The actual parameters of the signal is shown inside the symbol. The signal sending icon must follow the signal receipt icon if such exists. The signal sending icon is mapped to an instance of an activity owned by the transition on which the icon is attached, which owns an instance of sendSignalAction. If the actions package is not used by a tool, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance. It is possible to have several signal sending nodes on a transition path. Action sequence An action sequence icon is a rectangle that contains a textual representation of actions owned by the transition. Like the signal sending icon the action sequence icon must follow the signal receipt icon if exists. The action sequence node is also mapped to an activity, where the actions within are either mapped to a body of the activity instance or to an actions owned by the activity (in case the actions are mapped to the UML actions package). Disposition: Resolved To: "Eran Gery" Cc: "Guus Ramackers \(E-mail\)" , uml2-superstructure-ftf@omg.org Subject: Re: 4 statemachine resolutions for ballot 12 (11?) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 31 Mar 2004 04:38:53 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 03/31/2004 04:39:11 Eran, I agree with your proposed changes but I made a few modifications to them, mostly to clarify the changes and to correct a few minor English grammar issues and style points. I have also included the updated Table 20 for issue 6381. (NB: the specifications on what needs to be changed has to be more specific than had been done in past RTFs. In fact, the precise text of the change and/or precise specifications on where the change is to be made must be provided.) Specifically: - I have simplified the OCL constraint for resolution 6237 -- note that OCL assumes a left-to-right evaluation so that there is no need to use typecasting. - I do not believe that you are using the term "icon" properly -- which, I believe, represents a stand-alone symbolic renderings of some concept (e.g., such as the icons on your Windows desktop). Therefore, the notation for elements such as class boxex, send actions, and receive actions are not icons: they are full-fledged graphical constructs that can be joined to other similar constructs according to some syntactic rules. Therefore, I have renamed the style of notation for transitions to "action-oriented" notation rather than "transition iconic". If you agree with these changes and the ballot is postponed and no one else objects, we can include these in ballot 11. Attached is my modified version of your resolutions: Cheers, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 03/30/2004 09:06 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers \(E-mail\)" cc Subject 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran[attachment "SM-proposals-ballot12.doc" deleted by Branislav Selic/Ottawa/IBM] Smachine-ballot11-12.doc OMG Issue 6381 Title: Figure 395 requires a lot more explanation Source: ARTISAN Software Tools (Mr. Alan Moore, mailto:%20alan.moore@artisansw.com) Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. - Discussion: There issue here indeed requires slight modification of the statemachine metamodel to accommodate this notation. The intent for this .transition oriented. notation is to instantiate statemachine classes and not mix in activity graph fragments, as might implied by the notation. Therefore, the answer to Alan.s question is That ALL arrows are transitions. The only exception is the activity and send signal symbols that should map to activities. The proposed resolution: Metamodel: Change Change the multiplicity between Transition and Activity to * with an {ordered} constraint, which means which means that a transition may contain several activities including send actions. Notation section: The Add, to Table 20, the signal receipt, signal send and action symbols shall be added to the diagram section, each with references the transition section in Table 20 as per attached document as per attached document. The text before figure 395 will be updated as follows. The section will be titled .Transition-oriented notationAction-oriented notation.. The following paragraph also accounts for issue 6608 which is also related to the iconicthis notation. Transition-oriented notation An alternative notation, which is also referred as .transition-orientedaction-oriented., uses explicit icons to represent the trigger and actions(s) owned by a transition. Note that Note that although the iconic representation of a transition may contain multiple graphical elements connected by a control-flow path although this representation of a transition may contain multiple graphical elements connected by a control-flow path (see Figure 395), they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions. Whether the control-flow path consists of a single graphical segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. Whether the control-flow path consists of a single graphical segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. As discussed above, the entire path is mapped to a single transition regardless of its graphical management by a tool. Signal receipt The trigger of a transition, known as a .signal receipt. symbol, may be shown as a concave pentagonfive-pointed polygon that looks like a rectangle with a triangular notch in its side (either side). The signature of the signal is shown inside the symbol. If the transition owns a guard, the guard is also described within the signal receipt icon, using the textual signal[guard] notation. The signal receipt is always first in the path of icons and a transition path can only have at most one such icon at most one such icon. Signal sending Signal sending is a common action that has a special notation, among many other possible actions. It is may be shown as a convex pentagonfive-pointed polygon that looks like a rectangle with a protruding triangular pointtriangle on one either side (either side). The actual parameters of the signal is are shown inside the symbol. The On a given path, the signal sending icon graphic must follow the signal receipt icon if such the latter exists. The signal sending icon graphic maps is mapped to an instance of an activity owned by the transition on which the icon graphic is attached (, which owns an instance of sendSignalAction). If the actions package is not used by a tool, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance. It is possible to have several signal sending nodes on a transition path. Action sequence An action sequence icon grphic element is a rectangle that contains a textual representation of actions owned by the transition. Like the signal sending icon graphic, the action sequence icon graphic must follow the signal receipt icon graphic if one exists for that transition. The action sequence node graphic is also mapped to an activity, where the actions within are either mapped to a body of the activity instance or to an actions owned by the activity (in case the actions are mapped to the UML actions package). Disposition: Resolved From: "Eran Gery" To: "'Branislav Selic'" Cc: "Guus Ramackers \(E-mail\)" , Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Wed, 31 Mar 2004 16:33:32 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal Bran - Only one comment on your changes - the title of the modified section in issue 6381 is "transition oriented notation" and should be replaced replaced with "action oriented" following your amendment. The term icon was there before, I did not make it up... however I was also trying to distinguish these graphical nodes from the other nodes which are part of the statemachine graph. Those "icon" nodes are not part of the transition graph and therefore a term that reinforces this serves a purpose. Nevertheless, the term icon may not be the best one to make that distinction. So I am fine moving forward with this to ballot 11. Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wed, March 31, 2004 12:39 PM To: Eran Gery Cc: Guus Ramackers (E-mail); uml2-superstructure-ftf@omg.org Subject: Re: 4 statemachine resolutions for ballot 12 (11?) Eran, I agree with your proposed changes but I made a few modifications to them, mostly to clarify the changes and to correct a few minor English grammar issues and style points. I have also included the updated Table 20 for issue 6381. (NB: the specifications on what needs to be changed has to be more specific than had been done in past RTFs. In fact, the precise text of the change and/or precise specifications on where the change is to be made must be provided.) Specifically: - I have simplified the OCL constraint for resolution 6237 -- note that OCL assumes a left-to-right evaluation so that there is no need to use typecasting. - I do not believe that you are using the term "icon" properly -- which, I believe, represents a stand-alone symbolic renderings of some concept (e.g., such as the icons on your Windows desktop). Therefore, the notation for elements such as class boxex, send actions, and receive actions are not icons: they are full-fledged graphical constructs that can be joined to other similar constructs according to some syntactic rules. Therefore, I have renamed the style of notation for transitions to "action-oriented" notation rather than "transition iconic". If you agree with these changes and the ballot is postponed and no one else objects, we can include these in ballot 11. Attached is my modified version of your resolutions: Cheers, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Eran Gery" 03/30/2004 09:06 AM To Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers \(E-mail\)" cc Subject 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran[attachment "SM-proposals-ballot12.doc" deleted by Branislav Selic/Ottawa/IBM] OMG Issue 6381 Title: Figure 395 requires a lot more explanation Source: ARTISAN Software Tools (Mr. Alan Moore, mailto:%20alan.moore@artisansw.com) Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. - Discussion: There issue here indeed requires slight modification of the statemachine metamodel to accommodate this notation. The intent for this .transition oriented. notation is to instantiate statemachine classes and not mix in activity graph fragments, as might implied by the notation. Therefore, the answer to Alan.s question is That ALL arrows are transitions. The only exception is the activity and send signal symbols that should map to activities. The proposed resolution: Metamodel: Change Change the multiplicity between Transition and Activity to * with an {ordered} constraint, which means which means that a transition may contain several activities including send actions. Notation section: The Add, to Table 20, the signal receipt, signal send and action symbols shall be added to the diagram section, each with references the transition section in Table 20 as per attached document as per attached document. The text before figure 395 will be updated as follows. The section will be titled .Transition-oriented notationAction-oriented notation.. The following paragraph also accounts for issue 6608 which is also related to the iconicthis notation. Transition-oriented notation An alternative notation, which is also referred as .transition-orientedaction-oriented., uses explicit icons to represent the trigger and actions(s) owned by a transition. Note that Note that although the iconic representation of a transition may contain multiple graphical elements connected by a control-flow path although this representation of a transition may contain multiple graphical elements connected by a control-flow path (see Figure 395), they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions. Whether the control-flow path consists of a single graphical segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. Whether the control-flow path consists of a single graphical segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. As discussed above, the entire path is mapped to a single transition regardless of its graphical management by a tool. Signal receipt The trigger of a transition, known as a .signal receipt. symbol, may be shown as a concave pentagonfive-pointed polygon that looks like a rectangle with a triangular notch in its side (either side). The signature of the signal is shown inside the symbol. If the transition owns a guard, the guard is also described within the signal receipt icon, using the textual signal[guard] notation. The signal receipt is always first in the path of icons and a transition path can only have at most one such icon at most one such icon. Signal sending Signal sending is a common action that has a special notation, among many other possible actions. It is may be shown as a convex pentagonfive-pointed polygon that looks like a rectangle with a protruding triangular pointtriangle on one either side (either side). The actual parameters of the signal is are shown inside the symbol. The On a given path, the signal sending icon graphic must follow the signal receipt icon if such the latter exists. The signal sending icon graphic maps is mapped to an instance of an activity owned by the transition on which the icon graphic is attached (, which owns an instance of sendSignalAction). If the actions package is not used by a tool, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance. It is possible to have several signal sending nodes on a transition path. Action sequence An action sequence icon grphic element is a rectangle that contains a textual representation of actions owned by the transition. Like the signal sending icon graphic, the action sequence icon graphic must follow the signal receipt icon graphic if one exists for that transition. The action sequence node graphic is also mapped to an activity, where the actions within are either mapped to a body of the activity instance or to an actions owned by the activity (in case the actions are mapped to the UML actions package). Disposition: Resolved To: "Moore, Alan" Cc: "'Eran Gery'" , "Guus Ramackers (E-mail)" , uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sun, 4 Apr 2004 08:50:02 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/04/2004 08:50:04, Serialize complete at 04/04/2004 08:50:04 Thanks for the feedback, Alan. You raise valid points. Fortunately, the resolution proposed to issue 6381 has not been put on Ballot 11. Eran is the owner of this one so he has the last word. I can see how the "all arrows are transition" statement can be confusing. This is why I introduced the terms "line segment" and "control flow". But, as you point out, this seems to have caused a potential inconsistency in the resolution. In essence, there are two ways in which a transition can be shown: as a single directed line segment between two nodes (states or pseudostates) or as a flow chart (for want of a better word). The line segments in the flow-chart representation are not transitions in my opinion, but control-flow specifications that all map to the same transition in the repository model. Cheers....Bran "Moore, Alan" 04/04/2004 06:32 AM To "'Eran Gery'" , Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers (E-mail)" cc uml2-superstructure-ftf@omg.org Subject RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran[attachment "Smachine-ballot11-12(am).doc" deleted by Branislav Selic/Ottawa/IBM] From: Eran Gery To: "Moore, Alan" , "'Branislav Selic'" Cc: uml2-superstructure-ftf@omg.org, "Guus Ramackers (E-mail)" Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Date: Sun, 4 Apr 2004 15:35:34 +0200 X-Mailer: Internet Mail Service (5.5.2656.59) Alan - I have further refined the text to address your comments. There were indeed several places where we used terms that could have been misleading. As to the multiple triggers issue - I have basically modifid the text such that the trigger/guard expression is denoted within the "signal receipt" symbol similar to the way it is denoted in regular (non "action-oriented" transitions). Therefore, it does not impose any additional constraint comparing to the "regular" notation. So I have essentially delagated the multiple trigger issue to the textual notation which is not part of this section. However, looking at that, this whole issue of denoting multiple triggers seems lacking/inconsistent and "deserves" another issue, which also involves common behaviors. Eran p.s. Bran - this is the current candidate to include in ballot 12 -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Sun, April 04, 2004 1:33 PM To: 'Eran Gery'; 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: RE: 4 statemachine resolutions for ballot 12 (11?) Hi Eran, I have modified the document with some comments on my issue. Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 30 March 2004 15:06 To: 'Branislav Selic'; Guus Ramackers (E-mail) Cc: uml2-superstructure-ftf@omg.org Subject: 4 statemachine resolutions for ballot 12 (11?) Bran/Guus Attached is a resolution prposal for 4 statemachine issues I originally intended for ballot 11, but since none of them is trivial, I thought at this point they better be submitted for discussion for ballot 12. However I'm fine submitting them to 11 if you find appropriate and/or nobody objects. Thanks, Eran Smachine-ballot11-12(am-eg).doc OMG Issue 6381 Title: Figure 395 requires a lot more explanation Source: ARTISAN Software Tools (Mr. Alan Moore, mailto:%20alan.moore@artisansw.com) Summary: Figure 395 requires a lot more explanation. The abstract syntax claims that the effect of a transition be expressed as an Activity and so I suppose this is what this diagram represents, but I don't recognise the rectangle notation from activities. It's also not clear whether the arrows represent flows or transitions - if fact they can't be either, because some of the arrows start on states and end on actions. It also isn't clear whether there are any rules about the construction of these transitions; for example, I assume that there can only be one signal receipt and that it has to be the first symbol encountered, but that isn't stated. There may be an explanation that I missed, in which case it should be placed nearer the figure, or an appropriate reference inserted. The various symbols should also appear in the diagrams section. - Discussion: There issue here indeed requires slight modification of the statemachine metamodel to accommodate this notation. The intent for this .actiontransition oriented. notation is to instantiate statemachine classes and not mix in activity graph fragments, as might implied by the notation. Therefore, the answer to Alan.s question is tThat allALL the graphical segments connecting action and trigger nodesarrows map toare a single transition. Semantically the transitions is the one which owns the activities which represent the action symbols. . The only exception is the activity and send signal symbols that should map to activities. As discussed below, it is a tool implementation issue whether action oriented transitions are composed by creating a transition and then attaching the action/trigger nodes to it, or nodes are created and connected by several graphical segments which all map to a single transition. The proposed resolution: Metamodel: Change Change the multiplicity between Transition and Activity to * with an {ordered} constraint, which means which means that a transition may contain several activities. includ These activities represent action-sequence and send-actions icons, as described below. ing send actions . Notation section: The Add, to Table 20, the signal receipt, signal send and action symbols shall be added to the diagram section, each with references the transition section in Table 20 as per attached document as per attached document. The text before figure 395 will be updated as follows. The section will be titled .Transition-oriented notationAction-oriented notation.. The following paragraph also accounts for issue 6608 which is also related to the iconicthis notation. ActionTransition-oriented notation An alternative notation, which is also referred as .transition-orientedaction-oriented., uses explicit icons to represent the trigger and actions(s) owned by a transition. Note that Note that although the iconic representation of a transition may contain multiple graphical elements connected by a control-flow path although this graphical representation of a transition may contain multiple graphical line segments connecting trigger/action iconsgraphical elements connected by a control-flow path (see Figure 395), they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions they all map to a single transition (possibly including a trigger) and an ordered collection of linked actions. Whether the control-flow path consists of a single graphical segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. Whether such an action oriented transition is composed fromthe control-flow path consists of a single graphical line segment with attached icons, or several line segments connecting the icons, is a tool issue and is not prescribed here. As discussed above, the entire path is mapped to a single transition regardless of its graphical management by a tool. Signal receipt The trigger of a transition, known as a .signal receipt. symbol, may be shown as a concave pentagonfive-pointed polygon that looks like a rectangle with a triangular notch in its side (either side). It represents the trigger of the transition. The textual trigger specification is denoted inside the symbol, similar to the .regular. (non action oriented) notation. Specifically, The signature of the signal is shown inside the symbol. Iif the transition owns a guard, the guard is also described within the signal receipt icon, using the textual triggersignal[guard] notation. The signal receipt is always first in the path of icons and a transition path can only have at most one such icon at most one such icon. Signal sending Signal sending is a common action that has a special notation, among many other possible actions. It is may be shown as a convex pentagonfive-pointed polygon that looks like a rectangle with a protruding triangular pointtriangle on one either side (either side). The actual parameters of the signal is are shown inside the symbol. The On a given path, the signal sending icon graphic must follow the signal receipt icon if such the latter exists. The signal sending icon graphic maps is mapped to an instance of an activity owned by the transition on which the icon graphic is attached (, which owns an instance of sendSignalAction). If the actions package is not used by a tool, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance. It is possible to have several signal sending nodes on a transition path. Action sequence An action sequence icon grphic element is a rectangle that contains a textual representation of actions owned by the transition. Like the signal sending icon graphic, the action sequence icon graphic must follow the signal receipt icon graphic if one exists for that transition. The action sequence node graphic is also mapped to an activity, where the actions within are either mapped to a body of the activity instance or to an actions owned by the activity (in case the actions are mapped to the UML actions package). Disposition: Resolved From: "Eran Gery" To: "'Branislav Selic'" Cc: Subject: More Statemachine resolutions Date: Thu, 22 Jul 2004 01:35:44 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 00000000EC840A89B0118247A991840092C4F311A4867901 Attached two resolutions 6381, 6608 that relate to the action notation, which I believe triggerred all this activities/behaviors reorg Conrad and Thomas did. The notorious 6381 (Alan's clarification request for the action notation) is submitted relying on Conrad's 7319, specifically utilizing the sequence node. If 7319 is submitted to 20 then 6381 can also be submitted. This will probably be my last installment before going on my vacation... Eran From: "Moore, Alan" To: "'Eran Gery'" , "'Branislav Selic'" Cc: uml2-superstructure-ftf@omg.org Subject: RE: More Statemachine resolutions Date: Thu, 22 Jul 2004 14:22:42 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Eran, A couple of comments: On the graphics you state: It is not prescribed here whether this graphical action presentation is composed from a single graphical line segment with attached icons, or several line segments connecting the icons. Does this mean that the display will be different depending on the toolbuilders choice, for example with a single line segment there will only be one arrow, whereas with several line segments there will be one arrow per segment - in which case, is 395 an example of the latter? Also The signal sending graphic maps to an activity owned by the transition on which the graphic is attached (which owns an instance of sendSignalAction). from my reading of the revised description above, this is no longer true - it maps to an action not an activity. If I'm correct then its hard to see how the following is possible if there are several sendSignalActions in the effect of a Transition: If a tool does not use the actions package, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance How do we distinguish the different actions? Regards, Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 21 July 2004 23:36 To: 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: More Statemachine resolutions Attached two resolutions 6381, 6608 that relate to the action notation, which I believe triggerred all this activities/behaviors reorg Conrad and Thomas did. The notorious 6381 (Alan's clarification request for the action notation) is submitted relying on Conrad's 7319, specifically utilizing the sequence node. If 7319 is submitted to 20 then 6381 can also be submitted. This will probably be my last installment before going on my vacation... Eran From: "Eran Gery" To: "'Moore, Alan'" , "'Branislav Selic'" Cc: Subject: RE: More Statemachine resolutions Date: Thu, 22 Jul 2004 19:08:38 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Alan - see inline -----Original Message----- From: Moore, Alan [mailto:AlanM@artisansw.com] Sent: Thursday, July 22, 2004 4:23 PM To: 'Eran Gery'; 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: RE: More Statemachine resolutions Hi Eran, A couple of comments: On the graphics you state: It is not prescribed here whether this graphical action presentation is composed from a single graphical line segment with attached icons, or several line segments connecting the icons. EG> it does say that the line makes one transition. It does not prescribe how to construct it. Does this mean that the display will be different depending on the toolbuilders choice, for example with a single line segment there will only be one arrow, whereas with several line segments there will be one arrow per segment - in which case, is 395 an example of the latter? EG> Yes Also The signal sending graphic maps to an activity owned by the transition on which the graphic is attached (which owns an instance of sendSignalAction). from my reading of the revised description above, this is no longer true - it maps to an action not an activity. EG> Right. This shall be corrected. It shall say that a send symbol maps to an action which is part of the activity owned by the transition. BRAN - not sure I'll havr time to ammend it... if not could you please ammend this for the ballot ? If I'm correct then its hard to see how the following is possible if there are several sendSignalActions in the effect of a Transition: If a tool does not use the actions package, the details of the sent signal may be captured within the body of the activity instead of the sendSignalAction instance How do we distinguish the different actions? EG> In order to support this notation you have to support basic actions a structured activities. In that case you would have to map the send to an opaque action from basic actions. This is new stuff coming from Conrad and Thomas. Regards, Alan. -----Original Message----- From: Eran Gery [mailto:erang@ilogix.co.il] Sent: 21 July 2004 23:36 To: 'Branislav Selic' Cc: uml2-superstructure-ftf@omg.org Subject: More Statemachine resolutions Attached two resolutions 6381, 6608 that relate to the action notation, which I believe triggerred all this activities/behaviors reorg Conrad and Thomas did. The notorious 6381 (Alan's clarification request for the action notation) is submitted relying on Conrad's 7319, specifically utilizing the sequence node. If 7319 is submitted to 20 then 6381 can also be submitted. This will probably be my last installment before going on my vacation...