Issue 7337: inconsistency in the action model (uml2-rtf) Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu) Nature: Clarification Severity: Critical Summary: There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.) Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Actions taken: May 15, 2004: received issue Discussion: Two comments on the issue text: "there are other links in the model, such as those due to Connectors". The links established due to connectors are just links any other (link = an instance of an association). "or one should generalize the link actions to apply to liks identified by any StructuralFeature". Links cannot be identified by structural features that are not association ends, because there are no links in that case. In separate discussion with the filer, there was concern that structural feature were not well enough defined to have actions defined on them. Structural feature inherits from TypedElement, which provides a way to map to instances of a type, as explained in the entry for Kernel::TypedElement. The structural feature actions provide the results of this mapping, as explained in the semantics of StructuralFeature. The filer would like this issue held for further discussion. End of Annotations:===== m: webmaster@omg.org Date: 15 May 2004 16:16:35 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Thomas Weigert Company: Motorola mailFrom: thomas.weigert@motorola.com Notification: No Specification: UML Section: 11.3.21 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: 02/08/2003 Page: p.239 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.) OMG Issue No: 7337 Title: inconsistency in the action model Source: Motorola (Dr. Thomas Weigert, thomas.weigert@motorola.com) Summary: There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.) Discussion: Two comments on the issue text: "there are other links in the model, such as those due to Connectors". The links established due to connectors are just links any other. "or one should generalize the link actions to apply to liks identified by any StructuralFeature". Links cannot be identified by structural features that are not association ends, because there are no links in that case. In discussion with the filer, there was concern that structural feature were not well enough defined to have actions defined on them. Structural feature inherits from TypedElement, which provides a way to map to instances of a type, as explained in the entry for Kernel::TypedElement. The structural feature actions the results of this mapping, as explained in the semantics of StructuralFeature. Disposition: Closed no change From: "Thomas Weigert" To: "Conrad Bock" , Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Sun, 30 May 2004 17:54:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, you really worked hard... A few comments: 1. Issue 6491: I have objected to this resolution earlier on the basis that what is requested by the issue can already be done in the current specification without introducing additional features. In addition, the feature duplicates functionality already present. I had assumed that we would be working out a solution that removes this duplication, if a resolution is indeed required. You just resubmitted the old issue. 2. Issue 7319: Looking at the assignment spreadsheet, this issue is assigned to me. I have circulated a proposal for a resolution which you might want to comment on. 3. Issue 7337: I believe you did not fully appreciate the problem described in the issue. Also, the two comments on the issue you make are, I believe, incorrect. For example, I can speak of the link induced by a connector but I do not have association ends in the model to address them. However, in an action, I might want to explicitly create such links. I believe that there is a real issue that was pointed to here and would prefer if we could spend some more time working on understanding the issue. 4. Issue 7378: I would prefer I would were to not just brush off the issue by saying "Common behavior is overly general." I believe that activities have gratuitously introduced a way of communicating that is needlessly different to how things are done in the other behaviors and also to how it is done in real life systems. I have implemented a stream-based language in a compiler once, and I can tell you this is not easy. It is not the job of the UML to introduce research features. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 30, 2004 4:21 PM > To: uml2-superstructure-ftf@omg.org > Subject: ,av,,ac, Activity/action resolutions for ballot 16 > > > > > Hi all, > > Here are some proposed resolutions (23) in activities/actions for ballot > 16. > Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Wed, 2 Jun 2004 09:47:24 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Thanks for your comments, see replies below. Conrad > 1. Issue 6491: I have objected to this resolution earlier on the > basis that what is requested by the issue can already be done in the > current specification without introducing additional features. How would you do the example given in the resolution? > 2. Issue 7319: Looking at the assignment spreadsheet, this issue is > assigned to me. That's an error, since it is about activities/actions. Bran, please reassign 7319 to me, thanks. > 3. Issue 7337: I believe you did not fully appreciate the problem > described in the issue. Also, the two comments on the issue you make > are, I believe, incorrect. For example, I can speak of the link > induced by a connector but I do not have association ends in the > model to address them. However, in an action, I might want to > explicitly create such links. I believe that there is a real issue > that was pointed to here and would prefer if we could spend some more > time working on understanding the issue. Sure, can you elaborate? > 4. Issue 7378: I would prefer I would were to not just brush off the > issue by saying "Common behavior is overly general." I believe that > activities have gratuitously introduced a way of communicating that > is needlessly different to how things are done in the other behaviors > and also to how it is done in real life systems. I have implemented a > stream-based language in a compiler once, and I can tell you this is > not easy. It is not the job of the UML to introduce research > features. The term "stream" might be midleading, since it refers to when inputs and outputs are provided/taken, rather than, for example, the unix notion of stream. It is used heavily at the analysis level of process modeling. Please correct me, but the issue text implied that common Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Wed, 2 Jun 2004 09:47:24 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Thanks for your comments, see replies below. Conrad > 1. Issue 6491: I have objected to this resolution earlier on the > basis that what is requested by the issue can already be done in the > current specification without introducing additional features. How would you do the example given in the resolution? > 2. Issue 7319: Looking at the assignment spreadsheet, this issue is > assigned to me. That's an error, since it is about activities/actions. Bran, please reassign 7319 to me, thanks. > 3. Issue 7337: I believe you did not fully appreciate the problem > described in the issue. Also, the two comments on the issue you make > are, I believe, incorrect. For example, I can speak of the link > induced by a connector but I do not have association ends in the > model to address them. However, in an action, I might want to > explicitly create such links. I believe that there is a real issue > that was pointed to here and would prefer if we could spend some more > time working on understanding the issue. Sure, can you elaborate? > 4. Issue 7378: I would prefer I would were to not just brush off the > issue by saying "Common behavior is overly general." I believe that > activities have gratuitously introduced a way of communicating that > is needlessly different to how things are done in the other behaviors > and also to how it is done in real life systems. I have implemented a > stream-based language in a compiler once, and I can tell you this is > not easy. It is not the job of the UML to introduce research > features. The term "stream" might be midleading, since it refers to when inputs and outputs are provided/taken, rather than, for example, the unix notion of stream. It is used heavily at the analysis level of process modeling. Please correct me, but the issue text implied that common Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16 Date: Sun, 6 Jun 2004 20:44:44 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi all, Here is an update to the activities/actions proposals for ballot 16, for Thomas' comments issues 6491, 7319, and 7378. These reflect the current state of discussion. In particular, the need for refactoring activities/actions has not been concluded yet. Please provide followup comments and let me know if I missed anything. Below are some additional replies to Thomas on 7337. Conrad > 3. Issue 7337: I believe you did not fully appreciate the problem > described in the issue. Also I believe that there is a real issue > that was pointed to here and would prefer if we could spend some more > time working on understanding the issue. Sure, can you elaborate? > ... the two comments on the issue you make are, I believe, > incorrect. For example, I can speak of the link induced by a > connector but I do not have association ends in the model to address > them. However, in an action, I might want to explicitly create such > links. Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,av,,ac, Activity/action resolutions for ballot 16, 7337 Date: Wed, 9 Jun 2004 15:31:21 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > If you read the semantics of connectors, you will find that they > imply a link at run time. But there is not necessarily a link stored > in the model. You need to give a way of identifying such links > (e.g., by going through the connectors). Right, a link at runtime doesn't usually affect the model. > If you read through common behavior, you will find that there are a > number of communications possible without explicit associations. All > these imply the existence of links. Remember, that links are just > communication paths. An association in the model is but one way of > specifying such paths. Sounds like you use the term "link" more generally than a runtime instance of an association. The specification uses it to mean an instance of an association, at least the classes chapter does, and that is how it is used in the resolution remarks. Can clarify. > It must be possible to dynamically establish the links that > correspond to these paths, no matter how these links were > specified. OK, so how does this relate to 7337? How can a link exist without association ends? behavior can restrict the specialized behavior models. I can restate behavior can restrict the specialized behavior models. I can restate > Conrad OMG Issue No: 7337 Title: inconsistency in the action model Source: Motorola (Dr. Thomas Weigert, thomas.weigert@motorola.com) Summary: There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.) Discussion: Two comments on the issue text: "there are other links in the model, such as those due to Connectors". The links established due to connectors are just links any other (link = an instance of an association). "or one should generalize the link actions to apply to liks identified by any StructuralFeature". Links cannot be identified by structural features that are not association ends, because there are no links in that case. In discussion with the filer, there was concern that structural feature were not well enough defined to have actions defined on them. Structural feature inherits from TypedElement, which provides a way to map to instances of a type, as explained in the entry for Kernel::TypedElement. The structural feature actions provide the results of this mapping, as explained in the semantics of StructuralFeature. Disposition: Closed no change 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: "uml2ftf" Subject: RE: ,av,,ac, Activity/action proposals for ballot 17 Date: Tue, 15 Jun 2004 18:50:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas > 6236: In the text there is a typo "unmarhsall" should be "unmarshall". Thanks. > 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. OK. > 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. OK, can move it there. > 7337: As I have pointed out several times, This is a real issue and has not been resolved. Apologies, I'm not doubting it is a real issue, just having a hard time understanding it. In particular: > 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. The term links means an instance of an association, at least the way the spec uses the term. So if the entity you are referring to has no association, then it can't be something addressed by the link actions or structural feature actions. > We need to have a mechanism of denoting those links so that we can > construct them, add them, or delete them. If they have no association, how can we refer to the type required for creating them? > LinkAction requires LinkEndData which identifies the link by pointing > to a property (that is constrained to be an association end). It already does. If the Property is owned by an end classifier, then it is a property. > 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 don't recall that. What was the reasoning? This only extends activities with variables when variables are implemented, not in general. > 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. That's a much bigger change and requires harmonizing classes and structured nodes. The issue was deferred in an earlier ballot.