Issue 6236: UML 2.0 serious layout problems with activity diagrams (uml2-superstructure-ftf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Uncategorized Issue Severity: Summary: In UML 1.x you can draw several outgoing transitions from an action state with guard conditions. That's semantically equivalent to a decision. The semantic changes in UML 2.0. Several outgoing edges from an action node are semantically equivalent to a fork. The new semantic is absolutely ok, but I have problems with the notation. Especially in business process modelling it is common that a decision follows each action. Now I have to draw a decision node after each action node. That blows up the diagrams and makes them hard to read. With UML 2 I need two pages for a diagram that fits on half a page with UML 1.x. Is it possible to use a notational shortcut to keep the diagrams small and readable? I heard from several people that they think about workarounds for that problem. But I think that's the wrong way. Any solutions? Resolution: Revised Text: Actions taken: September 8, 2003: received issue March 9, 2005: closed issue Discussion: Guards can be used with control edges coming out from an action and the user can ensure they are mutually exclusive. Object flows edges coming out of pins are inherently mutually exclusive by competing for tokens, and can also have guards. However, AcceptEventAction should support multiple triggers to avoid using decisions with multiple accept event actions, see 7339. Disposition: Closed, no change End of Annotations:===== OMG Issue No: 6236 Title: UML 2.0 serious layout problems with activity diagrams Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: In UML 1.x you can draw several outgoing transitions from an action state with guard conditions. That's semantically equivalent to a decision. The semantic changes in UML 2.0. Several outgoing edges from an action node are semantically equivalent to a fork. The new semantic is absolutely ok, but I have problems with the notation. Especially in business process modelling it is common that a decision follows each action. Now I have to draw a decision node after each action node. That blows up the diagrams and makes them hard to read. With UML 2 I need two pages for a diagram that fits on half a page with UML 1.x. Is it possible to use a notational shortcut to keep the diagrams small and readable? I heard from several people that they think about workarounds for that problem. But I think that's the wrong way. Any solutions? Discussion: This is too large a change for the FTF. Will need to review other visual languages before proposing a shorthand. Disposition: Defer OMG Issue No: 6236 Title: UML 2.0 serious layout problems with activity diagrams Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: In UML 1.x you can draw several outgoing transitions from an action state with guard conditions. That's semantically equivalent to a decision. The semantic changes in UML 2.0. Several outgoing edges from an action node are semantically equivalent to a fork. The new semantic is absolutely ok, but I have problems with the notation. Especially in business process modelling it is common that a decision follows each action. Now I have to draw a decision node after each action node. That blows up the diagrams and makes them hard to read. With UML 2 I need two pages for a diagram that fits on half a page with UML 1.x. Is it possible to use a notational shortcut to keep the diagrams small and readable? I heard from several people that they think about workarounds for that problem. But I think that's the wrong way. Any solutions? Discussion: This is too large a change for the FTF. Will need to review other visual languages before proposing a shorthand. Disposition: Defer OMG Issue No: 6236 Title: UML 2.0 serious layout problems with activity diagrams Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: In UML 1.x you can draw several outgoing transitions from an action state with guard conditions. That's semantically equivalent to a decision. The semantic changes in UML 2.0. Several outgoing edges from an action node are semantically equivalent to a fork. The new semantic is absolutely ok, but I have problems with the notation. Especially in business process modelling it is common that a decision follows each action. Now I have to draw a decision node after each action node. That blows up the diagrams and makes them hard to read. With UML 2 I need two pages for a diagram that fits on half a page with UML 1.x. Is it possible to use a notational shortcut to keep the diagrams small and readable? I heard from several people that they think about workarounds for that problem. But I think that's the wrong way. Any solutions? Discussion: This is too large a change for the FTF. Will need to review other visual languages before proposing a shorthand. Disposition: Defer OMG Issue No: 6236 Title: UML 2.0 serious layout problems with activity diagrams Source: oose.de Dienstleistungen fur innovative Informatik (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Summary: In UML 1.x you can draw several outgoing transitions from an action state with guard conditions. That's semantically equivalent to a decision. The semantic changes in UML 2.0. Several outgoing edges from an action node are semantically equivalent to a fork. The new semantic is absolutely ok, but I have problems with the notation. Especially in business process modelling it is common that a decision follows each action. Now I have to draw a decision node after each action node. That blows up the diagrams and makes them hard to read. With UML 2 I need two pages for a diagram that fits on half a page with UML 1.x. Is it possible to use a notational shortcut to keep the diagrams small and readable? I heard from several people that they think about workarounds for that problem. But I think that's the wrong way. Any solutions? Discussion: Guards can be used with control edges coming out from an action and the user can ensure they are mutually exclusive. Object flows edges coming out of pins are inherently mutually exclusive by competing for tokens, and can also have guards. However, AcceptEventAction should support multiple triggers to avoid using decisions with multiple accept event actions, typos need to be corrected for 7292, and an unmarshalling made more consistent for 7399, as follows. In Figure 150 Change multiplicities from AcceptEventAction to Trigger to "1..*:. On AcceptEventAction add attribute "isUnmarhsall : Boolean = false" as shown below: In AcceptEventAction: Attributes, add isUnmarhsall : Boolean = false Indicates whether there is a single output pin for the event, or multiple output pins for attributes of the event. Associations, trigger, change entry to: trigger : Trigger [1..*] The type of events accepted by the action, as specified by triggers. For signal triggers, a signal of any subtype of the specified signal type is accepted. result, change entry to: result: OutputPin [0..*] Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity might not be preserved. Constraints Change Constraint 2 to "There are no output pins if the triggers are ChangeTrigger, or if they are CallTrigger when this class is AcceptEventAction and not one of its children." Change Constraint 3 to "If the triggers are TimeTrigger, there is exactly one output pin." Add new constraints, as second and third cosntraints: "All triggers must be instances of the same metaclass." "if isUnmarshall is true, there must be only one trigger of type SignalTrigger, and the result pins must match the attributes of the signal in number, type, and order." Semantics First paragraph First sentence, after "If the event is a SignalEvent" add "and isUnmarshall is false" Add new second sentence "If the event is a SignalTrigger, and isUnmarshall is true, the attribute values of the signal are placed on the result output pins of the action." Third sentence (in FAS) - replace "the specification" with "one of the triggers" - replace "accept signal action" with "accept event action". Second paragraph: Replace "An action whose event" with "An action whose trigger". Replace next to last sentence with "If the trigger is a ChangeTrigger or a CallTrigger, the result is a control token, there are no output pins (however, see AcceptCallAction). Throughout, replace: "SignalEvent" with "SignalTrigger" "ChangeEvent" with "ChangeTrigger" "TimeEvent" with "TimeTrigger". In AcceptCallAction, Constraints, add new constraint: "isUnmarshall = true". From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: ,av,,ac, Activity/action proposals for ballot 17 Date: Sun, 13 Jun 2004 21:52:57 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Comments: 6236: In the text there is a typo "unmarhsall" should be "unmarshall". I am also a little worried about the use of this terminology. By marshalling data we usually refer to a conversion of data structures when passing data. A typical example would be the conversion of a message as a stream of bits into a well-defined data structure as is typical in telecom systems. Another example would be to extract the payload from an Ethernet packet. There are tools called "marshalling compilers" which generate code that does this conversion, from high-level description of the data structures. I can see why you would call pulling the data from an event as marshalling, as in a sense it also converts data from one representation to another. I would advise to look for a better word. I also wonder whether the solution is not quite a stretch for what the issue asked. The issue requested a notation that simplifies the situation where we have decisions follow an action. The resolution points out that guards can be used to avoid these decision nodes in most cases. I wonder whether adding multiple triggers to AcceptEventAction falls within this problem? I think that this resolution should be moved to issue 7399 to avoid the appearance of going out of scope of the issue. 7337: As I have pointed out several times, there are links at runtime where we do not have an explicit association in the model. For example, a connector implies a link at run time. We need to have a mechanism of denoting those links so that we can construct them, add them, or delete them. This is a real issue and has not been resolved. LinkAction requires LinkEndData which identifies the link by pointing to a property (that is constrained to be an association end). Please fix this problem before closing the issue. 7393: The original motivation in the action semantics was to have StructuredActivityNode (actually was then StructuredAction) to be the scope for variables. It was specifically rejected then that variables would be in what then was called Procedures (now Activity). This resolution deviates from that. I have no problems with this change in principle, but if we change the scope of variables, we should go further as another issue suggested and make Variables StructuralFeatures. That way the issue would be resolved also, and in addition, we would not have to duplicate the StructuralFeatureActions to get VariableActions. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, June 13, 2004 7:37 PM > To: uml2ftf > Subject: ,av,,ac, Activity/action proposals for ballot 17 > > > > Hi all, > > Here are some (29) activity/action proposals for > balot 17. > Reply-To: From: "Conrad Bock" To: , Subject: RE: FW: Actions and Activities, again Date: Sun, 20 Jun 2004 20:57:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > If you cannot look at the notation without knowing what its abstract > syntax is then the notation is ambiguous, by definition. My point was to distinguish ambiguity to the user vs ambiguity to a vendor parsing the notation into a metamodel. The notation is not ambiguous to users, it means the same thing to them regardless of metamodeling. As for the vendor, it is a rare situation that the metamodel is parsed from the diagram. Conrad > > -----Original Message----- > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > Sent: Tuesday, June 15, 2004 5:54 PM > > To: anders.ek@telelogic.se; uml2-superstructure-ftf@omg.org > > Subject: RE: FW: Actions and Activities, again > > > > > > > > Thomas, > > > > > Note that the solution proposed by Eran solves the problem if > > > you want to store a sequence of uninterpreted behaviors. These > > > would be completely unrelated.The downside of this approach is > > > that the notation would look identical whether you used an > > > action model or uninterpreted behaviors, but the metamodel would > > > be very different. Thus you would have the only case where the > > > same notation would result in different metamodels (i.e., the > > > notation would be ambiguous depending on what your tool > > > capabilities are). > > > > It wouldn't be ambiguous to the user, only to someone translating > > notation to a model without the benefit of the original model, a rare > > use case. > > > > Conrad Reply-To: From: "Conrad Bock" To: , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Sun, 20 Jun 2004 20:57:27 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > I tend to agree with Conrad on this one. It would be better if > everybody reused the same model of data passing. That is the reason > why the model needs to be reusable, But your proposals leave flows separate from actions, inviting profilers to define flows in a different way. This was my very first point, still awaiting a reply: if actions are separate from flows, how do actions get their data? > as I have been arguing to the point that most are probably annoyed > already. If we do not package to allow reuse of the actions and > essential flow model in other behaviors, vendors will be forced to > invent their own, incompatible semantics. I would say the UML should address this issue, not let profilers define incompatible ways of providing data to actions in the various behaviors. > As I pointed out before, those efforts are already ongoing and will > impede interchange. Is there someone I could talk to that is working on this (besides yourself)? Conrad From: "Thomas Weigert" To: , , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Sun, 20 Jun 2004 20:04:53 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, as I described in my presentation, there are times you want to speak about actions without any concern of whether and where they get their data. Please look at the examples of interactions. This is an important use of actions. All the best, Th. P.S. I think I have replied to this question at least three times already. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, June 20, 2004 7:57 PM > To: anders.ek@telelogic.se; 'uml2ftf' > Subject: RE: FW: Actions and Activities, again > > > Thomas, > > > I tend to agree with Conrad on this one. It would be better if > > everybody reused the same model of data passing. That is the reason > > why the model needs to be reusable, > > But your proposals leave flows separate from actions, inviting profilers > to define flows in a different way. This was my very first point, still > awaiting a reply: if actions are separate from flows, how do actions get > their data? From: "Thomas Weigert" To: , , Subject: RE: FW: Actions and Activities, again Date: Sun, 20 Jun 2004 20:06:05 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) If the user draws a model and in one case she gets a set of activities and in the other case she gets a single activities as the result, I'd call that ambiguous to the user... th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, June 20, 2004 7:57 PM > To: anders.ek@telelogic.se; uml2-superstructure-ftf@omg.org > Subject: RE: FW: Actions and Activities, again > > > Thomas, > > > If you cannot look at the notation without knowing what its abstract > > syntax is then the notation is ambiguous, by definition. > > My point was to distinguish ambiguity to the user vs ambiguity to a > vendor parsing the notation into a metamodel. The notation is not > ambiguous to users, it means the same thing to them regardless of > metamodeling. As for the vendor, it is a rare situation that the > metamodel is parsed from the diagram. > > Conrad > > > > > -----Original Message----- > > > From: Conrad Bock [mailto:conrad.bock@nist.gov] > > > Sent: Tuesday, June 15, 2004 5:54 PM > > > To: anders.ek@telelogic.se; uml2-superstructure-ftf@omg.org > > > Subject: RE: FW: Actions and Activities, again > > > > > > > > > > > > Thomas, > > > > > > > Note that the solution proposed by Eran solves the problem if > > > > you want to store a sequence of uninterpreted behaviors. These > > > > would be completely unrelated.The downside of this approach is > > > > that the notation would look identical whether you used an > > > > action model or uninterpreted behaviors, but the metamodel would > > > > be very different. Thus you would have the only case where the > > > > same notation would result in different metamodels (i.e., the > > > > notation would be ambiguous depending on what your tool > > > > capabilities are). > > > > > > It wouldn't be ambiguous to the user, only to someone translating > > > notation to a model without the benefit of the original model, a rare > > > use case. > > > > > > Conrad Reply-To: From: "Conrad Bock" To: , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Mon, 21 Jun 2004 21:35:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > as I described in my presentation, there are times you want to speak > about actions without any concern of whether and where they get their > data. Please look at the examples of interactions. This is an > important use of actions. Yes, it is important (see my issue 6153, Interactions view of state machines/activities), and actions can be used separately from activities right now, see the multiplicities from Action to Activity. In the end, these actions will be in some activity, possibly on a state machine. Interaction using actions by themselves is only an early stage of the modeling process. There's no need to change the package dependencies. > P.S. I think I have replied to this question at least three > times already. I hadn't realized you were trying to connect the interactions use case to the package dependencies, see above. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: FW: Actions and Activities, again Date: Mon, 21 Jun 2004 21:36:02 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > If the user draws a model and in one case she gets a set of > activities and in the other case she gets a single activities as the > result, I'd call that ambiguous to the user... th. Agreed, but it depends on whether the user sees those activities or not, which depends on the what the vendor supports. I was assuming the use case was a tool only supporting the textual format in a state machine diagram, as Anders and Eran are referring to, but if the vendor supports activities, then users would see activities. It wouldn't be ambiguous to a particular user of a particular tool. Conrad To: Cc: "uml2ftf" Subject: RE: ,av,,ac, Activity/action proposals for ballot 17, update X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 21 Jun 2004 21:45:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/21/2004 21:45:54, Serialize complete at 06/21/2004 21:45:54 Conrad, Regarding issue 6236: It sounds to me like it would be useful to add a statement saying explicitly that the notational shortcut that the filer is seeking already exists. The way it is phrased at the moment, the reader has to infer that by reading the text carefully. Bran "Conrad Bock" 06/21/2004 09:32 PM Please respond to conrad.bock To "uml2ftf" cc Subject RE: ,av,,ac, Activity/action proposals for ballot 17, update Hi all, Here's an update to the activity/action resolutions for ballot 17 (6236 and 7399 in particular). Suggestions welcome for an alternative to the term "unmarshall". Conrad [attachment "issueresolution-cb-8.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: , , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Mon, 21 Jun 2004 21:37:32 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, I don't understand why you insist on saying things you know are incorrect. You cannot use actions without having also the activity package available. This is dictated by the package dependencies. You know that. A tool must provide the activity package if it wants to provide the action package and be UML compliant. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, June 21, 2004 8:36 PM > To: anders.ek@telelogic.se; 'uml2ftf' > Subject: RE: FW: Actions and Activities, again > > > > Thomas, > > > as I described in my presentation, there are times you want to speak > > about actions without any concern of whether and where they get their > > data. Please look at the examples of interactions. This is an > > important use of actions. > > Yes, it is important (see my issue 6153, Interactions view of state > machines/activities), and actions can be used separately from activities > right now, see the multiplicities from Action to Activity. In the end, > these actions will be in some activity, possibly on a state machine. > Interaction using actions by themselves is only an early stage of the > modeling process. There's no need to change the package dependencies. > > > P.S. I think I have replied to this question at least three > > times already. > > I hadn't realized you were trying to connect the interactions use case > to the package dependencies, see above. > > Conrad From: "Thomas Weigert" To: , , Subject: RE: FW: Actions and Activities, again Date: Mon, 21 Jun 2004 21:38:55 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Ambiguity and standard cut across tools. If I have tool X and you have tool Y and both tools support the same UML (or the same profile), my model should mean the same as your model. The abstract syntax is part of the meaning, isn't it? Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, June 21, 2004 8:36 PM > To: anders.ek@telelogic.se; uml2-superstructure-ftf@omg.org > Subject: RE: FW: Actions and Activities, again > > > > Thomas, > > > If the user draws a model and in one case she gets a set of > > activities and in the other case she gets a single activities as the > > result, I'd call that ambiguous to the user... th. > > Agreed, but it depends on whether the user sees those activities or not, > which depends on the what the vendor supports. I was assuming the use > case was a tool only supporting the textual format in a state machine > diagram, as Anders and Eran are referring to, but if the vendor supports > activities, then users would see activities. It wouldn't be ambiguous > to a particular user of a particular tool. > > Conrad Reply-To: From: "Conrad Bock" To: , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Tue, 22 Jun 2004 17:16:46 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > I don't understand why you insist on saying things you know are > incorrect. You cannot use actions without having also the activity > package available. This is dictated by the package dependencies. You > know that. A tool must provide the activity package if it wants to > provide the action package and be UML compliant. I must not have been clear. My point is that even if interactions has a direct connection to actions (which it doesn't currently), the actions will eventually be part of an activity, either stand alone, or as method, or in a state machine. It doesn't make sense for a vendor to do only the early stage of discovery and not follow through with a complete model. So it's fine that actions entail activities. Conrad > > Thomas, > > > > > as I described in my presentation, there are times you want to > > > speak about actions without any concern of whether and where > > > they get their data. Please look at the examples of > > > interactions. This is an important use of actions. > > Yes, it is important (see my issue 6153, Interactions view of state > > machines/activities), and actions can be used separately from > > activities right now, see the multiplicities from Action to > > Activity. In the end, these actions will be in some activity, > > possibly on a state machine. Interaction using actions by > > themselves is only an early stage of the modeling process. There's > > no need to change the package dependencies. > > > > > P.S. I think I have replied to this question at least three > > > times already. > > > > I hadn't realized you were trying to connect the interactions use case > > to the package dependencies, see above. > > > > Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: FW: Actions and Activities, again Date: Tue, 22 Jun 2004 17:16:48 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > Ambiguity and standard cut across tools. If I have tool X and you > have tool Y and both tools support the same UML (or the same > profile), my model should mean the same as your model. The abstract > syntax is part of the meaning, isn't it? Right, and presumably they would in the scenario you give above. A tool supporting activities would translate the state machine to activities, otherwise not. So if the above tools support the same parts of UML, then they will interchange fine. (We know all the problems that happen with interchange between tools that don't support the same parts of UML). Conrad From: "Thomas Weigert" To: , , "'uml2ftf'" Subject: RE: FW: Actions and Activities, again Date: Tue, 22 Jun 2004 16:28:38 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) A vendor supporting requirements tool or test case tools has no need or use for these. You cannot just support a market where everybody supports all of the UML. That was the whole mission of UML: To specialize to markets and technology needs. Just because you cannot imagine a tool, it does not mean that it is not being built... witness the current situation. The vast majority of our UML users use UML in this way... and you are talking lots of users... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, June 22, 2004 4:17 PM > To: anders.ek@telelogic.se; 'uml2ftf' > Subject: RE: FW: Actions and Activities, again > > > Thomas, > > > I don't understand why you insist on saying things you know are > > incorrect. You cannot use actions without having also the activity > > package available. This is dictated by the package dependencies. You > > know that. A tool must provide the activity package if it wants to > > provide the action package and be UML compliant. > > I must not have been clear. My point is that even if interactions has a > direct connection to actions (which it doesn't currently), the actions > will eventually be part of an activity, either stand alone, or as > method, or in a state machine. It doesn't make sense for a vendor to do > only the early stage of discovery and not follow through with a complete > model. So it's fine that actions entail activities. > > Conrad > > > > > Thomas, > > > > > > > as I described in my presentation, there are times you want to > > > > speak about actions without any concern of whether and where > > > > they get their data. Please look at the examples of > > > > interactions. This is an important use of actions. > > > > Yes, it is important (see my issue 6153, Interactions view of state > > > machines/activities), and actions can be used separately from > > > activities right now, see the multiplicities from Action to > > > Activity. In the end, these actions will be in some activity, > > > possibly on a state machine. Interaction using actions by > > > themselves is only an early stage of the modeling process. There's > > > no need to change the package dependencies. > > > > > > > P.S. I think I have replied to this question at least three > > > > times already. > > > > > > I hadn't realized you were trying to connect the > interactions use case > > > to the package dependencies, see above. > > > > > > Conrad > > > > From: "Eran Gery" To: , , , Cc: Subject: RE: Activites / action comment Date: Wed, 23 Jun 2004 20:04:43 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) I have a slightly different view from Anders, since I am not trying to pull into statemachines a complete coding model. Statemachines (as well as interaction) have their own way to specify control flows. The only missing bit to create a useful machine is providing it with the primitive actions that actually "do" things: read/write, send, assign etc. To me it is important to distinguish between the primitive actions and those control actions. Reason is that I do not want to force this semantic overlap. So to me the ideal solution would provide a package used by statemachine that allows - Opaque behaviors - Primitive (atomic) actions - Possibly a sequence construct I believe trying to cover a coding model goes beyond what statemachines need, so this should be the next level of packaging. I agree though that having a package that maps to an imperative coding model (leaving out all the dataflow stuff) would be useful. -----Original Message----- From: anders.ek@telelogic.se [mailto:anders.ek@telelogic.se] Sent: Wednesday, June 23, 2004 7:29 PM To: thomas.weigert@motorola.com; conrad.bock@nist.gov; bselic@ca.ibm.com; erang@ilogix.co.il Cc: uml2-superstructure-ftf@omg.org Subject: Activites / action comment My input to your discussion tomorrow! What I see as my main requirements are simply the following: - (1) To be able to represent the actions in a statemachine transition - (2) To be able to define a profile that defines a syntax for actions used in statemachine transitions. This should cover simple procedural programming style constructs like assignments, loops etc. In (1) I want to be able to use the UML actions. At least SendSignalAction for which there is a syntax in statemachines. However, ideally I also would like to be able to use other actions. Essentially I want to be able to represent a sequence of actions. If this is done as a sequence of behaviours instead of actions it could be ok. But it seems like a very strange model. What would e.g. a sequence containing some StateMachines and some Interactions mean? So I would prefer if we can have actions and not behaviours to be referenced from statemachines. For the purpose of (2) I guess the only requirement is that this must be possible using a suitable subset of the Activity model packages. I can see that adding something like the SequenceAction and some simpler scheme for assignment would help but I'm not sure it is needed. However, I can also see that what definitely will be needed is to include a kind of 'catch all' construct that can be used when the built-in actions are not enough. Traditionally in UML this has been the UninterpretedAction. Since we don't seem to have this anymore I'm not sure how to model this. So I guess my preference would be something like having a sequence of actions to be referenced from statemachines and have at least SendSignalAction and something similar to the old UninterpretedAction to be among the supported actions. Regards Anders Reply-To: From: "Conrad Bock" To: , Subject: RE: Activites / action comment Date: Wed, 23 Jun 2004 13:28:30 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Eran, > I have a slightly different view from Anders, since I am not > trying to pull into statemachines a complete coding model. Just to clarify: structured activities have fine-grained packaging also. You wouldn't need all of structured activities to do sequences, for example. > Statemachines (as well as interaction) have their own way to > specify control flows. The only missing bit > to create a useful machine is providing it with the primitive > actions that actually "do" things: read/write, send, assign etc. > To me it is important to distinguish between the primitive actions > and those control actions. Reason is that I do not want to force this > semantic overlap. >From the examples, these actions are often groups of actions, that is, small activities (see my slide 2, example on the upper right). State machines don't cover that. > So to me the ideal solution would provide a package used by > statemachine that allows > > - Opaque behaviors > - Primitive (atomic) actions > - Possibly a sequence construct > > I believe trying to cover a coding model goes beyond what > statemachines need, so this should be the next level of packaging. I > agree though that having a package that maps to an imperative coding > model (leaving out all the dataflow stuff) would be useful. See above on a simple structured activity package. Conrad To: anders.ek@telelogic.se Cc: conrad.bock@nist.gov, erang@ilogix.co.il, thomas.weigert@motorola.com, uml2-superstructure-ftf@omg.org Subject: Re: Activites / action comment X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 23 Jun 2004 16:33:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/23/2004 16:33:37, Serialize complete at 06/23/2004 16:33:37 Hi Anders, Thanks for this input, this is very useful. I have a clarification question followed by some comments: > - (2) To be able to define a profile that defines a syntax > for actions used in statemachine transitions. This should cover > simple procedural programming style constructs like assignments, loops etc. In principle, the concepts of flows and nodes defined in activities provide the mechanisms for modeling the simple procedural programming style that you are seeking. The problem, as I understand it, is that the parts that are needed for supporting this are tightly coupled to other concepts that you do not need but which you would still have to support in your tool (at least in the XMI that you generate). Is this a proper statement of your position? If it is, then it seems that the ideal solution would be to refactor and decouple the concepts. I am not sure whether this is the kind of thing we can do safely at this juncture. OTOH, if we just leave the actions as Thomas suggests without the flows, there is indeed a serious danger of repeating gratuitously what is already in the current flows package. As I see it, the more commonality we have in the CommonBehaviors package (where these things belong) the better. It would mean that a lot more tooling and knowledge can be reused to the benefit of UML users. Just my ruminations on these topics. Cheers...Bran Subject: RE: Activites / action comment Date: Tue, 29 Jun 2004 09:01:28 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Activites / action comment Thread-Index: AcRZYXq0M8geZQGvTKW9XLqmyQgi/wERKS6A From: "Anders Ek" To: "Branislav Selic" Cc: Hi Bran, From a profile point of view we need a decent packaging of activities, but I guess that a perfect one is not needed. The reason is that in a profile we can add constraints on what concepts are allowed when this profile is added. So, from a profile point of view any decent packaging should be ok. From a tool vendors compliance point of view it is of course slightly different. There we need a packaging that allows us to in a clear and simple way state what we support. So the packaging is more critical in this respect. /Anders -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: den 23 juni 2004 22:34 To: Anders Ek Cc: conrad.bock@nist.gov; erang@ilogix.co.il; thomas.weigert@motorola.com; uml2-superstructure-ftf@omg.org Subject: Re: Activites / action comment Hi Anders, Thanks for this input, this is very useful. I have a clarification question followed by some comments: > - (2) To be able to define a profile that defines a syntax > for actions used in statemachine transitions. This should cover > simple procedural programming style constructs like assignments, loops etc. In principle, the concepts of flows and nodes defined in activities provide the mechanisms for modeling the simple procedural programming style that you are seeking. The problem, as I understand it, is that the parts that are needed for supporting this are tightly coupled to other concepts that you do not need but which you would still have to support in your tool (at least in the XMI that you generate). Is this a proper statement of your position? If it is, then it seems that the ideal solution would be to refactor and decouple the concepts. I am not sure whether this is the kind of thing we can do safely at this juncture. OTOH, if we just leave the actions as Thomas suggests without the flows, there is indeed a serious danger of repeating gratuitously what is already in the current flows package. As I see it, the more commonality we have in the CommonBehaviors package (where these things belong) the better. It would mean that a lot more tooling and knowledge can be reused to the benefit of UML users. Just my ruminations on these topics. Cheers...Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: ,av,,ac, Activity/action resolutions for ballot 18 Date: Tue, 29 Jun 2004 15:03:13 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi all, Here are proposed activity/action resolutions for ballot 18. Conrad issueresolution-cb-9.doc Disposition: Resolved