Issue 15787: Parameter semantics related to Behavior and BehavioralFeature (uml2-rtf) Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com) Nature: Uncategorized Issue Severity: Summary: On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors. ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says “See semantics of ParameterSet”. But all 12.3.43 says is “A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.” 12.3.13 also says “See notation for ParameterSet” – that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that’s the topic of a separate discussion). ParameterEffectKind, as well, talks exclusively about Behaviors. So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors. Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel. There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others. The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature. One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18. Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter? Resolution: Revised Text: Actions taken: October 27, 2010: received issue Discussion: End of Annotations:===== m: Steve Cook To: "uml2-rtf@omg.org" Subject: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLw== Date: Wed, 27 Oct 2010 13:30:39 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors. ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says .See semantics of ParameterSet.. But all 12.3.43 says is .A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.. 12.3.13 also says .See notation for ParameterSet. . that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that.s the topic of a separate discussion). ParameterEffectKind, as well, talks exclusively about Behaviors. So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors. Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel. There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others. The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature. One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18. Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter? From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Thu, 28 Oct 2010 14:23:48 -0400 Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0A Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Steve, > Now, in the UML specification, there actually appear to be two > separate metaclasses called Parameter. There is the one defined in > Kernel, together with the one defined in Collaborations as a merge > increment: the merge happens via > Collaborations->InternalStructures->Interfaces->Dependencies->Kernel. > There is a second one defined in CompleteActivities. According to > the specification text, this is a specialization (it does not say > merge) of the one in Kernel. However these are the merges: > CompleteActivities->IntermediateActivities->BasicActivities- > FundemantalActivities->BasicBehaviors->Kernel. So > CompleteActivities::Parameter is also merged with the others. > One explanation of this might that the merge is accidental, and > there are supposed to be two definitions of Parameter. This is > belied, however, by 12.3.13 and figure 12.18. Anything about specialization of Parameter from Parameter in different packages is accidentlly left over from the conversation to merging. Before package merge, all the merges were specializations. They were all supposed to be converted to merges, but some may have been missed, especially in the specification text as opposed to the model. > ParameterSet semantics talks almost exclusively about Behaviors. > There is a forward reference in 12.3.13 that says "See semantics of > ParameterSet". But all 12.3.43 says is "A behavior with output > parameter sets can only post outputs to the parameters in one of the > sets per execution. The same is true for operations with parameter > sets." Operation calls post outputs, just as behavior calls do, and the text says the output parameters can be groups in into sets, possibly overlapping, where each execution can only post output values for parameters in one set. Not sure anything what else needs to be said here, except perhaps for examples. > 12.3.13 also says "See notation for ParameterSet" that is simply > false, because 12.3.43 only has notation for Behaviors (well, > actually Activities, because Behavior has no notation (13.3.2) but > that's the topic of a separate discussion). Yes, the forward ref doesn't give a parameter set notion for classifiers, so this is more a "see also", than "see" in the sense of referring to additional specification of Classifier. > ParameterEffectKind, as well, talks exclusively about Behaviors. This is inadvertently due to the focus of activities on calls of behavior rather than operations, but the end result is the same in both cases, namely a behavior execution, so parameter effect applies to operations as well. > The end result is Parameter which defines both direction: > ParameterDirectionKind and effect: ParameterEffectKind, that can be > organized into subsets, regardless of where it is used. But there > are almost no semantics and no notation specified for the > Behavior-oriented features as they relate to BehavioralFeature. > On my first UML 2.5 efforts at consolidating the semantics of > Classifiers in the merged model it becomes very obvious that > Parameter has two sets of semantics: one related to the parameters > of BehavioralFeatures and one related to the parameters of > Behaviors. > Can anybody explain what this is supposed to be about? Are these > meanings of Parameter really supposed to be integrated like this? The semantics of these constructs for operations isn't different from that of behaviors, because the constructs are from the view of the caller. The caller of an operation doesn't know if there's a single possible method behavior behind the operation or many, so for these constructs it amounts to the same thing as a direct call to a behavior. The lack of clarity on this is just do to focus of the text than any semantic difference. > What are the meanings of effect and parameterSet for Operations and > Receptions? See above about operations. Receptions are equivalent to asychronous operation calls with one parameter, so parameter sets might be defined for them, but not much use, since there aren't any outputs and only a single input. This is just as well, because determining the resulting behavior invoked from a reception ranges from easy (a state machine classifier behavior) to possible difficult (an activity classifier behavior). Conrad From: Steve Cook To: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnA= Date: Mon, 1 Nov 2010 12:15:55 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.70] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oA1BwG03017660 Conrad, thanks. I'd appreciate some additional clarification: >parameter effect applies to operations as well. What is the relationship between parameter effect and parameter direction? They must surely be mutually constrained. Does it make sense, for example, to have effect == read and direction == out or direction == inout? -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 28 October 2010 19:24 To: uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve, > Now, in the UML specification, there actually appear to be two > separate metaclasses called Parameter. There is the one defined in > Kernel, together with the one defined in Collaborations as a merge > increment: the merge happens via > Collaborations->InternalStructures->Interfaces->Dependencies->Kernel. > There is a second one defined in CompleteActivities. According to > the specification text, this is a specialization (it does not say > merge) of the one in Kernel. However these are the merges: > CompleteActivities->IntermediateActivities->BasicActivities- > FundemantalActivities->BasicBehaviors->Kernel. So > CompleteActivities::Parameter is also merged with the others. > One explanation of this might that the merge is accidental, and > there are supposed to be two definitions of Parameter. This is > belied, however, by 12.3.13 and figure 12.18. Anything about specialization of Parameter from Parameter in different packages is accidentlly left over from the conversation to merging. Before package merge, all the merges were specializations. They were all supposed to be converted to merges, but some may have been missed, especially in the specification text as opposed to the model. > ParameterSet semantics talks almost exclusively about Behaviors. > There is a forward reference in 12.3.13 that says "See semantics of > ParameterSet". But all 12.3.43 says is "A behavior with output > parameter sets can only post outputs to the parameters in one of the > sets per execution. The same is true for operations with parameter > sets." Operation calls post outputs, just as behavior calls do, and the text says the output parameters can be groups in into sets, possibly overlapping, where each execution can only post output values for parameters in one set. Not sure anything what else needs to be said here, except perhaps for examples. > 12.3.13 also says "See notation for ParameterSet" that is simply > false, because 12.3.43 only has notation for Behaviors (well, > actually Activities, because Behavior has no notation (13.3.2) but > that's the topic of a separate discussion). Yes, the forward ref doesn't give a parameter set notion for classifiers, so this is more a "see also", than "see" in the sense of referring to additional specification of Classifier. > ParameterEffectKind, as well, talks exclusively about Behaviors. This is inadvertently due to the focus of activities on calls of behavior rather than operations, but the end result is the same in both cases, namely a behavior execution, so parameter effect applies to operations as well. > The end result is Parameter which defines both direction: > ParameterDirectionKind and effect: ParameterEffectKind, that can be > organized into subsets, regardless of where it is used. But there > are almost no semantics and no notation specified for the > Behavior-oriented features as they relate to BehavioralFeature. > On my first UML 2.5 efforts at consolidating the semantics of > Classifiers in the merged model it becomes very obvious that > Parameter has two sets of semantics: one related to the parameters > of BehavioralFeatures and one related to the parameters of > Behaviors. > Can anybody explain what this is supposed to be about? Are these > meanings of Parameter really supposed to be integrated like this? The semantics of these constructs for operations isn't different from that of behaviors, because the constructs are from the view of the caller. The caller of an operation doesn't know if there's a single possible method behavior behind the operation or many, so for these constructs it amounts to the same thing as a direct call to a behavior. The lack of clarity on this is just do to focus of the text than any semantic difference. > What are the meanings of effect and parameterSet for Operations and > Receptions? See above about operations. Receptions are equivalent to asychronous operation calls with one parameter, so parameter sets might be defined for them, but not much use, since there aren't any outputs and only a single input. This is just as well, because determining the resulting behavior invoked from a reception ranges from easy (a state machine classifier behavior) to possible difficult (an activity classifier behavior). Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Mon, 1 Nov 2010 08:56:15 -0400 Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Steve, > > parameter effect applies to operations as well. > What is the relationship between parameter effect and parameter > direction? They must surely be mutually constrained. Yes, the current constraints in 12.3.41 Parameter are: [4] Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect. > Does it make sense, for example, to have effect == read and > direction == out or direction == inout? A behavior/alfeature might read an object it provides as output. I can see how this combination might used less often than the others. Conrad From: Steve Cook To: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xw Date: Tue, 2 Nov 2010 10:11:40 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.70] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oA29r6YL010011 Conrad I am still puzzled. What about an operation/behavior that takes a single in-out parameter, as follows? On the first execution it creates it. On the second execution it writes it. On the third execution it reads it. On the fourth execution it deletes it. How can such a parameter be meaningfully marked with ParameterEffectKind? Thanks -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 01 November 2010 12:56 To: uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve, > > parameter effect applies to operations as well. > What is the relationship between parameter effect and parameter > direction? They must surely be mutually constrained. Yes, the current constraints in 12.3.41 Parameter are: [4] Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect. > Does it make sense, for example, to have effect == read and > direction == out or direction == inout? A behavior/alfeature might read an object it provides as output. I can see how this combination might used less often than the others. Conrad Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Date: Tue, 2 Nov 2010 12:46:01 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7A= From: "Ed Seidewitz" To: "Steve Cook" Cc: "Bock, Conrad" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oA2GSBIR029749 Steve -- Parameter effect is optional. In the case you describe, I don't see that it makes sense to include any particular parameter effect at all. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, November 02, 2010 6:12 AM To: Bock, Conrad; uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Conrad I am still puzzled. What about an operation/behavior that takes a single in-out parameter, as follows? On the first execution it creates it. On the second execution it writes it. On the third execution it reads it. On the fourth execution it deletes it. How can such a parameter be meaningfully marked with ParameterEffectKind? Thanks -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 01 November 2010 12:56 To: uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve, > > parameter effect applies to operations as well. > What is the relationship between parameter effect and parameter > direction? They must surely be mutually constrained. Yes, the current constraints in 12.3.41 Parameter are: [4] Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect. > Does it make sense, for example, to have effect == read and > direction == out or direction == inout? A behavior/alfeature might read an object it provides as output. I can see how this combination might used less often than the others. Conrad From: Steve Cook To: Ed Seidewitz CC: "Bock, Conrad" , "uml2-rtf@omg.org" Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoA== Date: Tue, 2 Nov 2010 17:28:15 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.70] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oA2HB7B3011803 Ed I thought that might be the case. The spec says: "The effect of a parameter is a declaration of the modeler's intent, and does not have execution semantics. The modeler must ensure that the owner of the parameter has the stated effect." Does that mean at least the stated effect, or the stated effect and only the stated effect? -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 02 November 2010 16:46 To: Steve Cook Cc: Bock, Conrad; uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve -- Parameter effect is optional. In the case you describe, I don't see that it makes sense to include any particular parameter effect at all. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, November 02, 2010 6:12 AM To: Bock, Conrad; uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Conrad I am still puzzled. What about an operation/behavior that takes a single in-out parameter, as follows? On the first execution it creates it. On the second execution it writes it. On the third execution it reads it. On the fourth execution it deletes it. How can such a parameter be meaningfully marked with ParameterEffectKind? Thanks -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 01 November 2010 12:56 To: uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve, > > parameter effect applies to operations as well. > What is the relationship between parameter effect and parameter > direction? They must surely be mutually constrained. Yes, the current constraints in 12.3.41 Parameter are: [4] Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect. > Does it make sense, for example, to have effect == read and > direction == out or direction == inout? A behavior/alfeature might read an object it provides as output. I can see how this combination might used less often than the others. Conrad Date: Tue, 02 Nov 2010 13:41:38 -0400 From: "Chonoles, Michael J" Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. To: Steve Cook , Ed Seidewitz Cc: "Bock, Conrad" , "uml2-rtf@omg.org" Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoAABIEtw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-02_07:2010-11-02,2010-11-02,1970-01-01 signatures=0 When we discuss items that have no execution semantics, I believe we typically leave the details of the interpretation up to the agreement with the modeler and model reader (or automated tools). (e.g., the interpretation of aggregation). Michael -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, November 02, 2010 1:28 PM To: Ed Seidewitz Cc: Bock, Conrad; uml2-rtf@omg.org Subject: EXTERNAL: RE: Parameter semantics related to Behavior and BehavioralFeature. Ed I thought that might be the case. The spec says: "The effect of a parameter is a declaration of the modeler's intent, and does not have execution semantics. The modeler must ensure that the owner of the parameter has the stated effect." Does that mean at least the stated effect, or the stated effect and only the stated effect? -- Steve -----Original Message----- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 02 November 2010 16:46 To: Steve Cook Cc: Bock, Conrad; uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve -- Parameter effect is optional. In the case you describe, I don't see that it makes sense to include any particular parameter effect at all. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, November 02, 2010 6:12 AM To: Bock, Conrad; uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Conrad I am still puzzled. What about an operation/behavior that takes a single in-out parameter, as follows? On the first execution it creates it. On the second execution it writes it. On the third execution it reads it. On the fourth execution it deletes it. How can such a parameter be meaningfully marked with ParameterEffectKind? Thanks -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 01 November 2010 12:56 To: uml2-rtf@omg.org Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Steve, > > parameter effect applies to operations as well. > What is the relationship between parameter effect and parameter > direction? They must surely be mutually constrained. Yes, the current constraints in 12.3.41 Parameter are: [4] Only in and inout parameters may have a delete effect. Only out, inout, and return parameters may have a create effect. > Does it make sense, for example, to have effect == read and > direction == out or direction == inout? A behavior/alfeature might read an object it provides as output. I can see how this combination might used less often than the others. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Tue, 2 Nov 2010 13:57:31 -0400 Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA/FFHA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Steve, > I am still puzzled. What about an operation/behavior that > takes a single in-out parameter, as follows? On the first > execution it creates it. On the second execution it writes > it. On the third execution it reads it. On the fourth > execution it deletes it. > > How can such a parameter be meaningfully marked with > ParameterEffectKind? > Does that mean at least the stated effect, or the stated > effect and only the stated effect? Ideally we would have local effect kinds on the invocation actions, as we have currently for pre/postconditions. Then the effects on behaviors/operations could be narrowed for the particular conditions expected at a each invocation separately. But even this wouldn't address your example, since the invocation could be the same for the four executions you mentioned. The traditional interpretation of "CRUD" as I understood it is a particular execution might or might not have the stated effect(s), but that some possible execution would (where the conditions for these possible executions might never actually happen). This enables the caller to know the full range of things that might happen, and accomodate them. In this interpretation, your example behavior would have all four effects, raising the question of why the property is single-valued. Even in simpler cases, behaviors updating an object usually also read it. And created objects are usually updated. I think these last two pairings are typically assumed from update and create, respectively. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Tue, 2 Nov 2010 14:01:03 -0400 Subject: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Topic: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoAABIEtwAACmoJA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Michael, > When we discuss items that have no execution semantics, I believe we > typically leave the details of the interpretation up to the > agreement with the modeler and model reader (or automated > tools). (e.g., the interpretation of aggregation). Declarative semantics (as in this case) is still semantics. It places restrictions on execution, but not enough for typical platforms to carry out the behavior. Once enough restrictions are placed for typical platforms to carry out the behavior, it is called "executable" or "operational" semantics. Conrad Date: Tue, 02 Nov 2010 14:13:00 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Parameter semantics related to Behavior and BehavioralFeature. To: "Bock, Conrad" , "uml2-rtf@omg.org" Thread-Topic: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoAABIEtwAACmoJAAAIPREA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: Date: Tue, 02 Nov 2010 14:13:00 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Parameter semantics related to Behavior and BehavioralFeature. To: "Bock, Conrad" , "uml2-rtf@omg.org" Thread-Topic: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoAABIEtwAACmoJAAAIPREA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-02_07:2010-11-02,2010-11-02,1970-01-01 signatures=0 I suppose I was noting that we have precedent for not being precise in all these cases. Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, November 02, 2010 2:01 PM To: uml2-rtf@omg.org Subject: Ex: RE: Parameter semantics related to Behavior and BehavioralFeature. Michael, > When we discuss items that have no execution semantics, I believe we > typically leave the details of the interpretation up to the te: Tue, 02 Nov 2010 14:13:00 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Parameter semantics related to Behavior and BehavioralFeature. To: "Bock, Conrad" , "uml2-rtf@omg.org" Thread-Topic: RE: Parameter semantics related to Behavior and BehavioralFeature. Thread-Index: Act12Qc9oNlnqPjpS4W05gjfgLiRLwA5kb0AAL+FGnAAAVl18AAsp/xwAA35U7AAAMFdoAABIEtwAACmoJAAAIPREA== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-02_07:2010-11-02,2010-11-02,1970-01-01 signatures=0 I suppose I was noting that we have precedent for not being precise in all these cases. Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Tuesday, November 02, 2010 2:01 PM To: uml2-rtf@omg.org Subject: Ex: RE: Parameter semantics related to Behavior and BehavioralFeature. Michael, > When we discuss items that have no execution semantics, I believe we > typically leave the details of the interpretation up to the > agreement with the modeler and model reader (or automated > tools). (e.g., the interpretation of aggregation). Declarative semantics (as in this case) is still semantics. It places restrictions on execution, but not enough for typical platforms to carry out the behavior. Once enough restrictions are placed for typical platforms to carry out the behavior, it is called "executable" or "operational" semantics. Conrad