Issue 15668: isDerived with DefaultValue (uml2-rtf) Source: (Dr. Maged Elaasar, melaasar(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = <Property> UML::State::/ isSubmachineState : Boolean defaultValue = <Literal Boolean> false property = <Property> UML::State::/ isSimple : Boolean defaultValue = <Literal Boolean> true property = <Property> UML::State::/ isOrthogonal : Boolean defaultValue = <Literal Boolean> false property = <Property> UML::State::/ isComposite : Boolean defaultValue = <Literal Boolean> false property = <Property> UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = <Literal UnlimitedNatural> 1 property = <Property> UML::Operation::/ lower : Integer [0..1] defaultValue = <Literal Integer> 1 property = <Property> UML::Operation::/ isUnique : Boolean defaultValue = <Literal Boolean> true property = <Property> UML::Operation::/ isOrdered : Boolean defaultValue = <Literal Boolean> false property = <Property> UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = <Literal UnlimitedNatural > 1 property = <Property> UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = <Literal Integer> 1 property = <Property> UML::Message::/ messageKind : MessageKind defaultValue = <Instance Value> unknown property = <Property> UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = <Literal Integer > 0 property = <Property> UML::Extension::/ isRequired : Boolean defaultValue = <Literal Boolean> false do we need to fix them? Resolution: Revised Text: Actions taken: September 30, 2010: received issue Discussion: End of Annotations:===== ubject: isDerived with DefaultValue To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 30 Sep 2010 13:20:22 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/30/2010 13:20:24 Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean defaultValue = false do we need to fix them? Maged Subject: RE: isDerived with DefaultValue Date: Thu, 30 Sep 2010 13:41:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: isDerived with DefaultValue thread-index: ActgxDcQDyFpBAxTRkaakb55vOPf6gAAXPew From: "Ed Seidewitz" To: "Maged Elaasar" , Maged . Arguably, having a default value for a derived attribute just means that, by default, the other attributes from which the derived attribute value is derived must have initial values consistent with the default derived value. You or I may or may not agree with this, but the fact that it is arguable means that it will be so argued, meaning that this is not just a metamodel .fix.. Indeed, even if it was a .fix., I wouldn.t want to take the existing defaults out without careful consideration to make sure the other non-derived attributes are defaulted to give the originally desired effect. Really, we need to stop bringing up these issues requiring ongoing judgment and discussion and get on with Ballot 11. The only additional things we should be worrying about now is alignment with MOF 2.4. Every time we get near the finish line, we keep moving it farther out. Let.s get UML 2.4 done! -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, September 30, 2010 1:20 PM To: uml2-rtf@omg.org Subject: isDerived with DefaultValue Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean defaultValue = false do we need to fix them? Maged Subject: RE: isDerived with DefaultValue To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 30 Sep 2010 13:44:22 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/30/2010 13:44:23 Ed, I was not necessarily suggesting fixing them in 2.4. If we think it is an issue, we just need to log it at least. "Ed Seidewitz" "Ed Seidewitz" 09/30/2010 01:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: isDerived with DefaultValue Maged . Arguably, having a default value for a derived attribute just means that, by default, the other attributes from which the derived attribute value is derived must have initial values consistent with the default derived value. You or I may or may not agree with this, but the fact that it is arguable means that it will be so argued, meaning that this is not just a metamodel .fix.. Indeed, even if it was a .fix., I wouldn.t want to take the existing defaults out without careful consideration to make sure the other non-derived attributes are defaulted to give the originally desired effect. Really, we need to stop bringing up these issues requiring ongoing judgment and discussion and get on with Ballot 11. The only additional things we should be worrying about now is alignment with MOF 2.4. Every time we get near the finish line, we keep moving it farther out. Let.s get UML 2.4 done! -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, September 30, 2010 1:20 PM To: uml2-rtf@omg.org Subject: isDerived with DefaultValue Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean defaultValue = false do we need to fix them? Maged pic25739.gif Subject: RE: isDerived with DefaultValue Date: Thu, 30 Sep 2010 10:47:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: isDerived with DefaultValue Thread-Index: ActgxAkokLl88UtHQeK+zinvifneUwAAstSg From: "Pete Rivett" To: "Maged Elaasar" , That.s a good point . since the meaning of .defaultValue. is the value to be assigned (on element creation) and invariably such derived properties have isReadOnly=.true. so are unable to be assigned any value! So hence this is a fundamental inconsistency that should be fixed. Pete From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, September 30, 2010 10:20 AM To: uml2-rtf@omg.org Subject: isDerived with DefaultValue Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean do are unable to be assigned any value! So hence this is a > fundamental inconsistency that should be fixed. If we went that far with read-only then you couldn't even have read-only derived values, since they set the value. The action model assumes read-only attributes can be set before the object is "initialized", including to have default set (search on "initial" in the Actions chapter). Conrad faultValue = false do we need to fix them? nce the meaning of lue Maged From: "Bock, Conrad" To: Pete Rivett , Maged Elaasar , "uml2-rtf@omg.org" Date: Thu, 30 Sep 2010 14:02:13 -0400 Subject: RE: isDerived with DefaultValue Thread-Topic: isDerived with DefaultValue Thread-Index: ActgxAkokLl88UtHQeK+zinvifneUwAAstSgAACMfxA= 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 o are unable to be assigned any value! So hence this is a > fundamental inconsistency that should be fixed. If we went that far with read-only then you couldn't even have read-only derived values, since they set the value. The action model assumes read-only attributes can be set before the object is "initialized", including to have default set (search on "initial" in the Actions chapter). Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Thu, 30 Sep 2010 14:03:40 -0400 Subject: RE: isDerived with DefaultValue Thread-Topic: isDerived with DefaultValue Thread-Index: ActgxDcQDyFpBAxTRkaakb55vOPf6gAAXPewAAEDzwA= 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 Ed, > Really, we need to stop bringing up these issues requiring > ongoing judgment and discussion and get on with Ballot 11. > The only additional things we should be worrying about now > is alignment with MOF 2.4. I think it's fine to bring them up, just not fix them. :) Conrad Subject: Fw: isDerived with DefaultValue To: Juergen Boldt X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 30 Sep 2010 14:18:07 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/30/2010 14:18:08 Please log this issue for UML2. Thanks. ----- Forwarded by Maged Elaasar/Ottawa/IBM on 09/30/2010 02:17 PM ----- Maged Elaasar/Ottawa/IBM@IBMCA 09/30/2010 01:20 PM To uml2-rtf@omg.org cc Subject isDerived with DefaultValue Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean defaultValue = false do we need to fix them? Maged pic11445.gif good point ete,lue nce the meaning of > Tha From: "Bock, Conrad" To: Pete Rivett , Maged Elaasar , "uml2-rtf@omg.org" Date: Thu, 30 Sep 2010 14:02:13 -0400 Subject: RE: isDerived with DefaultValue Thread-Topic: isDerived with DefaultValue Thread-Index: ActgxAkokLl88UtHQeK+zinvifneUwAAstSgAACMfxA= 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 P good point ete, From: Steve Cook To: Maged Elaasar , Ed Seidewitz CC: "uml2-rtf@omg.org" Subject: RE: isDerived with DefaultValue Thread-Topic: isDerived with DefaultValue Thread-Index: AQHLYMQ9FtUSF42hPEK2bu/5bnRO1pMquwGAgAAA7gCAAQtn4A== Date: Fri, 1 Oct 2010 08:52:06 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] I don.t think we should fix it in 2.4. Maged, could you log an issue? With regard to finishing 2.4, I propose to put one more resolution into Ballot 11, which is to make isID non-optional (I.m waiting for an issue number). Then we need to provisionally apply all of the fixes and errata we have discovered, and regenerate the UML2.4/MOF2.4/XMI2.4 artifacts (Nicolas will be doing the metamodel and generation, Maged the spec docs). If we find *serious* errata and tooling bugs while doing this we.ll fix them. Otherwise we should reject all new issues. If these all pass, we will vote on Ballot 11; presuming it passes then I will complete the report and ship it with the normative artifacts. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 30 September 2010 18:44 To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: isDerived with DefaultValue Ed, I was not necessarily suggesting fixing them in 2.4. If we think it is an issue, we just need to log it at least. "Ed Seidewitz" "Ed Seidewitz" 09/30/2010 01:41 PM To Maged Elaasar/Ottawa/IBM@IBMCA, cc Subject RE: isDerived with DefaultValue Maged . Arguably, having a default value for a derived attribute just means that, by default, the other attributes from which the derived attribute value is derived must have initial values consistent with the default derived value. You or I may or may not agree with this, but the fact that it is arguable means that it will be so argued, meaning that this is not just a metamodel .fix.. Indeed, even if it was a .fix., I wouldn.t want to take the existing defaults out without careful consideration to make sure the other non-derived attributes are defaulted to give the originally desired effect. Really, we need to stop bringing up these issues requiring ongoing judgment and discussion and get on with Ballot 11. The only additional things we should be worrying about now is alignment with MOF 2.4. Every time we get near the finish line, we keep moving it farther out. Let.s get UML 2.4 done! -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, September 30, 2010 1:20 PM To: uml2-rtf@omg.org Subject: isDerived with DefaultValue Hello, I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values. Here is a list of such derived properties in the metamodel: PropertyIsDerivedWithDefaultValue : 13 property = UML::State::/ isSubmachineState : Boolean defaultValue = false property = UML::State::/ isSimple : Boolean defaultValue = true property = UML::State::/ isOrthogonal : Boolean defaultValue = false property = UML::State::/ isComposite : Boolean defaultValue = false property = UML::Operation::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::Operation::/ lower : Integer [0..1] defaultValue = 1 property = UML::Operation::/ isUnique : Boolean defaultValue = true property = UML::Operation::/ isOrdered : Boolean defaultValue = false property = UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1] defaultValue = 1 property = UML::MultiplicityElement::/ lower : Integer [0..1] defaultValue = 1 property = UML::Message::/ messageKind : MessageKind defaultValue = unknown property = UML::ExtensionEnd::/ lower : Integer [0..1] defaultValue = 0 property = UML::Extension::/ isRequired : Boolean defaultValue = false do we need to fix them? Maged X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=pUW89uuwYBcA:10 a=FynzZczSZDYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=D1-Pp1MCpyoA:10 a=yMhMjlubAAAA:8 a=oCcaPWc0AAAA:8 a=poTxJt9gAx9R_jw3JL8A:9 a=vB1ak8Fck76qXLOU:21 a=ntaFKfJYe9qNcRDT:21 a=-_AEsMP7bkao32nQ:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 Date: Mon, 24 Jun 2013 06:46:34 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "uml25-ftf@omg.org" Subject: Re: 15668 Derived default values X-Virus-Scanned: amavisd-new at omg.org Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink CC: "uml25-ftf@omg.org" Subject: RE: 15668 Derived default values Thread-Topic: 15668 Derived default values Thread-Index: AQHOcJ5ZBMGMNdKoCUy/Ho02fJxrgplEXhqQ Date: Mon, 24 Jun 2013 06:33:53 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.108.109.65] X-Virus-Scanned: amavisd-new at omg.org Ed . The problem is how to attached a constraint to a derived property such that it defines the value of that property in a way that it is distinguished and computable by tooling. There is, unfortunately, no standard way to do this in UML. Note that .isDerived. is simply a flag . it provides no indication how the property is derived, just that there it can be .computed from other information.. This information can potentially be given anywhere in the model, if it is given explicitly at all . there is no requirement that it be specified by a constraint or, if it is, that this constraint is even attached to the property itself. (And the derived property itself cannot own the constraint, because Property is not a Namespace and it provides no specific way to own a constraint.) For the UML abstract syntax, however, it is necessary for tools to know how to explicitly compute all derived values. While this has not been presented clearly or consistently in previous spec documents, the convention in the metamodel itself has always been to use an operation with only a return parameter of the same name as the derived property that, when evaluated, gives the value of the property. But, through UML 2.3, the actual link of the operation to the property was solely through their names, which was not very satisfactory. There was an extensive discussion of this in the UML 2.4 RTF, if I remember correctly. The vendor representatives strongly argued to continue the use of operations for specifying how derived values were computed, because this had become the understood approach by the UML implementation community. However, in order to provide some formal link back to the derived property in the metamodel, we made the derived property a constrained element of the constraint condition for the operation, even though that constraint is owned by the operation. So, for example, the Operation::isOrdered operation owns the constraint that is its body condition. But this constraint has both the Operation::isOrdered operation and the Operation::isOperation property as its constrained elements. It is not ideal that the interpretation of the body of the constraint as computing the value of the derived property can only be understood by convention, but this was the compromise and, in any case, some convention is necessary, since, as noted above, there is not standard way to specify a derivation in UML. As usual, you need to know the history in order to understand why things are the way they are in the UML specification. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 7:47 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=pUW89uuwYBcA:10 a=FynzZczSZDYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=D1-Pp1MCpyoA:10 a=vrshd3w6AAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=hEHSN7QJQm6eJIXWkQQA:9 a=dyMaSh-Ee5N_PpI8:21 a=8HUCOksYTc_f3XD-:21 a=8QHs0hSbcAx7xTaW:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=WP4_USCxRkkA:10 Date: Mon, 24 Jun 2013 07:47:57 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "uml25-ftf@omg.org" Subject: Re: 15668 Derived default values X-Virus-Scanned: amavisd-new at omg.org Hi Ed If it is almost mandatory to retain the synonym operations then what is wrong with changing the clearly wrong Operation.isOrdered = false to Operation.isOrdered = isOrdered() ? No change to the operation. No need to change the 'constrainedElements'; they are functionally irrelevant and so may have a redundant legacy compatibility. (Functionally irrelevant: An OCL constraint is unable to access the constrainedElements except by reflection which is not currently supported in OCL.) Previously, tooling was obviously ignoring the wrong default so cannot be too confused by a coherent function call. Regards Ed Willink On 24/06/2013 07:33, Ed Seidewitz wrote: Ed . The problem is how to attached a constraint to a derived property such that it defines the value of that property in a way that it is distinguished and computable by tooling. There is, unfortunately, no standard way to do this in UML. Note that .isDerived. is simply a flag . it provides no indication how the property is derived, just that there it can be .computed from other information.. This information can potentially be given anywhere in the model, if it is given explicitly at all . there is no requirement that it be specified by a constraint or, if it is, that this constraint is even attached to the property itself. (And the derived property itself cannot own the constraint, because Property is not a Namespace and it provides no specific way to own a constraint.) For the UML abstract syntax, however, it is necessary for tools to know how to explicitly compute all derived values. While this has not been presented clearly or consistently in previous spec documents, the convention in the metamodel itself has always been to use an operation with only a return parameter of the same name as the derived property that, when evaluated, gives the value of the property. But, through UML 2.3, the actual link of the operation to the property was solely through their names, which was not very satisfactory. There was an extensive discussion of this in the UML 2.4 RTF, if I remember correctly. The vendor representatives strongly argued to continue the use of operations for specifying how derived values were computed, because this had become the understood approach by the UML implementation community. However, in order to provide some formal link back to the derived property in the metamodel, we made the derived property a constrained element of the constraint condition for the operation, even though that constraint is owned by the operation. So, for example, the Operation::isOrdered operation owns the constraint that is its body condition. But this constraint has both the Operation::isOrdered operation and the Operation::isOperation property as its constrained elements. It is not ideal that the interpretation of the body of the constraint as computing the value of the derived property can only be understood by convention, but this was the compromise and, in any case, some convention is necessary, since, as noted above, there is not standard way to specify a derivation in UML. As usual, you need to know the history in order to understand why things are the way they are in the UML specification. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 7:47 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink CC: "uml25-ftf@omg.org" Subject: RE: 15668 Derived default values Thread-Topic: 15668 Derived default values Thread-Index: AQHOcJ5ZBMGMNdKoCUy/Ho02fJxrgplEXhqQgABh/4D//64tsA== Date: Mon, 24 Jun 2013 07:03:07 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.108.109.65] X-Virus-Scanned: amavisd-new at omg.org Because a default value does not give derivation, it just gives an initial value. A derived property needs to have its value recomputed based on any changes in the values of other properties involved in its derivation. Besides, the UML abstract syntax is a MOF model, and MOF has the additional constraint .For a TypedElement that is a kind of Parameter or Property typed by an PrimitiveType, the defaultValue, if any, must be a kind of LiteralSpecification.. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 8:48 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed If it is almost mandatory to retain the synonym operations then what is wrong with changing the clearly wrong Operation.isOrdered = false to Operation.isOrdered = isOrdered() ? No change to the operation. No need to change the 'constrainedElements'; they are functionally irrelevant and so may have a redundant legacy compatibility. (Functionally irrelevant: An OCL constraint is unable to access the constrainedElements except by reflection which is not currently supported in OCL.) Previously, tooling was obviously ignoring the wrong default so cannot be too confused by a coherent function call. Regards Ed Willink On 24/06/2013 07:33, Ed Seidewitz wrote: Ed . The problem is how to attached a constraint to a derived property such that it defines the value of that property in a way that it is distinguished and computable by tooling. There is, unfortunately, no standard way to do this in UML. Note that .isDerived. is simply a flag . it provides no indication how the property is derived, just that there it can be .computed from other information.. This information can potentially be given anywhere in the model, if it is given explicitly at all . there is no requirement that it be specified by a constraint or, if it is, that this constraint is even attached to the property itself. (And the derived property itself cannot own the constraint, because Property is not a Namespace and it provides no specific way to own a constraint.) For the UML abstract syntax, however, it is necessary for tools to know how to explicitly compute all derived values. While this has not been presented clearly or consistently in previous spec documents, the convention in the metamodel itself has always been to use an operation with only a return parameter of the same name as the derived property that, when evaluated, gives the value of the property. But, through UML 2.3, the actual link of the operation to the property was solely through their names, which was not very satisfactory. There was an extensive discussion of this in the UML 2.4 RTF, if I remember correctly. The vendor representatives strongly argued to continue the use of operations for specifying how derived values were computed, because this had become the understood approach by the UML implementation community. However, in order to provide some formal link back to the derived property in the metamodel, we made the derived property a constrained element of the constraint condition for the operation, even though that constraint is owned by the operation. So, for example, the Operation::isOrdered operation owns the constraint that is its body condition. But this constraint has both the Operation::isOrdered operation and the Operation::isOperation property as its constrained elements. It is not ideal that the interpretation of the body of the constraint as computing the value of the derived property can only be understood by convention, but this was the compromise and, in any case, some convention is necessary, since, as noted above, there is not standard way to specify a derivation in UML. As usual, you need to know the history in order to understand why things are the way they are in the UML specification. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 7:47 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=pUW89uuwYBcA:10 a=FynzZczSZDYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=D1-Pp1MCpyoA:10 a=vrshd3w6AAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=fZYHQXzDO9XSYd4NGdQA:9 a=P2fIEwOxrlYV2DyC:21 a=kaw2oIP1js1SN0dN:21 a=bqVRthNxfmOU5J7S:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=WP4_USCxRkkA:10 Date: Mon, 24 Jun 2013 10:48:06 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "uml25-ftf@omg.org" Subject: Re: 15668 Derived default values X-Virus-Scanned: amavisd-new at omg.org Hi Ed I thought that UML 2.4 threw off the shackles of MOF, and I thought that UML 2.5 was resolving gratuitous complexity. Does the specification provide any more detail than "The derivation for a derived Property may be specified by a constraint." for the specified-by-operation-synonym-elsewhere idiom or is this just a totally unwritten custom and practice. I would expect to see some well-formedness rules and some guidance as to whether a value computed elsewhere can be cached. e.g. (unchecked) context Property def synonymOperation() : Operation[?] : let candidates : Collection(Operation) = ownedType.ownedOperations() ->select(name = self.name) ->select(ownedParameter->size() = 1) ->select(ownedParameter->forAll(direction = ParameterDirectionKind::return)) in if candidates ->size() = 1 then candidates->any(true) else null endif inv DerivationIsSpecifiedElseWhere: isDerived implies synonymOperation() <> null inv DerivationIsConsistent: isDerived implies let synonymOperation : Operation = synonymOperation() in synonymOperation <> null implies synonymOperation.isQuery and synonymOperation.type = self.type and synonymOperation.bodyCondition.constrainedElement->includes(synonymOperation) and synonymOperation.bodyCondition.constrainedElement->includes(self) "But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property." refers to a derivation constraint which is not specified in UML (or OCL). Requiring reversable constraint evaluation seems pretty impractical in practice. For derived properties one might almost expect the opposite; readonly asserts that the derived value can be safely cached, not-readonly indicates that the value may change. "a default value does not give derivation, it just gives an initial value" can be interpreted in various ways. The default value solves the problem of an absence of a needed value, so in the case of a derived property for which caching is not authorised, on each occasion an absence arises a default is determined by the default ValueSpecification, so a default value does give a derivation. Regards Ed Willink On 24/06/2013 08:03, Ed Seidewitz wrote: Because a default value does not give derivation, it just gives an initial value. A derived property needs to have its value recomputed based on any changes in the values of other properties involved in its derivation. Besides, the UML abstract syntax is a MOF model, and MOF has the additional constraint .For a TypedElement that is a kind of Parameter or Property typed by an PrimitiveType, the defaultValue, if any, must be a kind of LiteralSpecification.. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 8:48 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed If it is almost mandatory to retain the synonym operations then what is wrong with changing the clearly wrong Operation.isOrdered = false to Operation.isOrdered = isOrdered() ? No change to the operation. No need to change the 'constrainedElements'; they are functionally irrelevant and so may have a redundant legacy compatibility. (Functionally irrelevant: An OCL constraint is unable to access the constrainedElements except by reflection which is not currently supported in OCL.) Previously, tooling was obviously ignoring the wrong default so cannot be too confused by a coherent function call. Regards Ed Willink On 24/06/2013 07:33, Ed Seidewitz wrote: Ed . The problem is how to attached a constraint to a derived property such that it defines the value of that property in a way that it is distinguished and computable by tooling. There is, unfortunately, no standard way to do this in UML. Note that .isDerived. is simply a flag . it provides no indication how the property is derived, just that there it can be .computed from other information.. This information can potentially be given anywhere in the model, if it is given explicitly at all . there is no requirement that it be specified by a constraint or, if it is, that this constraint is even attached to the property itself. (And the derived property itself cannot own the constraint, because Property is not a Namespace and it provides no specific way to own a constraint.) For the UML abstract syntax, however, it is necessary for tools to know how to explicitly compute all derived values. While this has not been presented clearly or consistently in previous spec documents, the convention in the metamodel itself has always been to use an operation with only a return parameter of the same name as the derived property that, when evaluated, gives the value of the property. But, through UML 2.3, the actual link of the operation to the property was solely through their names, which was not very satisfactory. There was an extensive discussion of this in the UML 2.4 RTF, if I remember correctly. The vendor representatives strongly argued to continue the use of operations for specifying how derived values were computed, because this had become the understood approach by the UML implementation community. However, in order to provide some formal link back to the derived property in the metamodel, we made the derived property a constrained element of the constraint condition for the operation, even though that constraint is owned by the operation. So, for example, the Operation::isOrdered operation owns the constraint that is its body condition. But this constraint has both the Operation::isOrdered operation and the Operation::isOperation property as its constrained elements. It is not ideal that the interpretation of the body of the constraint as computing the value of the derived property can only be understood by convention, but this was the compromise and, in any case, some convention is necessary, since, as noted above, there is not standard way to specify a derivation in UML. As usual, you need to know the history in order to understand why things are the way they are in the UML specification. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 7:47 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink , "uml25-ftf@omg.org" Subject: RE: 15668 Derived default values Thread-Topic: 15668 Derived default values Thread-Index: AQHOcJ5ZBMGMNdKoCUy/Ho02fJxrgplEXhqQgABh/4D//64tsIAAhCkAgAANHBA= Date: Mon, 24 Jun 2013 15:38:41 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.131.194.109] X-Virus-Scanned: amavisd-new at omg.org Ed . Unfortunately, you thought wrong. The UML 2.4.1 abstract syntax is a MOF 2.4.1 model (more correctly conforming to MOF, in fact, than any UML metamodel before it). UML 2.5 is a simplification of the UML specification, but the UML 2.5 metamodel is intended to be essentially the same as the fully merged UML 2.4.1 metamodel. There is allowance for correcting and completing OCL, but there is no call for changing the way that the OCL is attached for derivations. The tooling that uses such constraints should simply be able to take advantage of their completion in UML 2.5. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 11:48 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed I thought that UML 2.4 threw off the shackles of MOF, and I thought that UML 2.5 was resolving gratuitous complexity. Does the specification provide any more detail than "The derivation for a derived Property may be specified by a constraint." for the specified-by-operation-synonym-elsewhere idiom or is this just a totally unwritten custom and practice. I would expect to see some well-formedness rules and some guidance as to whether a value computed elsewhere can be cached. e.g. (unchecked) context Property def synonymOperation() : Operation[?] : let candidates : Collection(Operation) = ownedType.ownedOperations() ->select(name = self.name) ->select(ownedParameter->size() = 1) ->select(ownedParameter->forAll(direction = ParameterDirectionKind::return)) in if candidates ->size() = 1 then candidates->any(true) else null endif inv DerivationIsSpecifiedElseWhere: isDerived implies synonymOperation() <> null inv DerivationIsConsistent: isDerived implies let synonymOperation : Operation = synonymOperation() in synonymOperation <> null implies synonymOperation.isQuery and synonymOperation.type = self.type and synonymOperation.bodyCondition.constrainedElement->includes(synonymOperation) and synonymOperation.bodyCondition.constrainedElement->includes(self) "But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property." refers to a derivation constraint which is not specified in UML (or OCL). Requiring reversable constraint evaluation seems pretty impractical in practice. For derived properties one might almost expect the opposite; readonly asserts that the derived value can be safely cached, not-readonly indicates that the value may change. "a default value does not give derivation, it just gives an initial value" can be interpreted in various ways. The default value solves the problem of an absence of a needed value, so in the case of a derived property for which caching is not authorised, on each occasion an absence arises a default is determined by the default ValueSpecification, so a default value does give a derivation. Regards Ed Willink On 24/06/2013 08:03, Ed Seidewitz wrote: Because a default value does not give derivation, it just gives an initial value. A derived property needs to have its value recomputed based on any changes in the values of other properties involved in its derivation. Besides, the UML abstract syntax is a MOF model, and MOF has the additional constraint .For a TypedElement that is a kind of Parameter or Property typed by an PrimitiveType, the defaultValue, if any, must be a kind of LiteralSpecification.. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 8:48 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed If it is almost mandatory to retain the synonym operations then what is wrong with changing the clearly wrong Operation.isOrdered = false to Operation.isOrdered = isOrdered() ? No change to the operation. No need to change the 'constrainedElements'; they are functionally irrelevant and so may have a redundant legacy compatibility. (Functionally irrelevant: An OCL constraint is unable to access the constrainedElements except by reflection which is not currently supported in OCL.) Previously, tooling was obviously ignoring the wrong default so cannot be too confused by a coherent function call. Regards Ed Willink On 24/06/2013 07:33, Ed Seidewitz wrote: Ed . The problem is how to attached a constraint to a derived property such that it defines the value of that property in a way that it is distinguished and computable by tooling. There is, unfortunately, no standard way to do this in UML. Note that .isDerived. is simply a flag . it provides no indication how the property is derived, just that there it can be .computed from other information.. This information can potentially be given anywhere in the model, if it is given explicitly at all . there is no requirement that it be specified by a constraint or, if it is, that this constraint is even attached to the property itself. (And the derived property itself cannot own the constraint, because Property is not a Namespace and it provides no specific way to own a constraint.) For the UML abstract syntax, however, it is necessary for tools to know how to explicitly compute all derived values. While this has not been presented clearly or consistently in previous spec documents, the convention in the metamodel itself has always been to use an operation with only a return parameter of the same name as the derived property that, when evaluated, gives the value of the property. But, through UML 2.3, the actual link of the operation to the property was solely through their names, which was not very satisfactory. There was an extensive discussion of this in the UML 2.4 RTF, if I remember correctly. The vendor representatives strongly argued to continue the use of operations for specifying how derived values were computed, because this had become the understood approach by the UML implementation community. However, in order to provide some formal link back to the derived property in the metamodel, we made the derived property a constrained element of the constraint condition for the operation, even though that constraint is owned by the operation. So, for example, the Operation::isOrdered operation owns the constraint that is its body condition. But this constraint has both the Operation::isOrdered operation and the Operation::isOperation property as its constrained elements. It is not ideal that the interpretation of the body of the constraint as computing the value of the derived property can only be understood by convention, but this was the compromise and, in any case, some convention is necessary, since, as noted above, there is not standard way to specify a derivation in UML. As usual, you need to know the history in order to understand why things are the way they are in the UML specification. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 7:47 AM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Steve [Sorry for deviating off-list.] The default values certainly need cleaning up. For instance: Operation.isOrdered = false is clearly wrong. However the 'specified elsewhere' is unhelpful. It dates back to a time when either OCL was not understood, had not tackled the problem of propertiy initialisers or when practical tooling was indaequate or misleading. Consequently many properties have an idiomatic same-named operation sibling. The current definition of isOrdered() : Boolean body: if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif satisfies the requirement of providing the information in words but makes for an incoherent model. Practical tooling needs to understand the specified-by-operation-synonym-elsewhere idiom in order to compute the derived value. Coherence can be achieved by: Operation.isOrdered = isOrdered() However IMHO it should be rectified so that the property definition is self-contained Operation.isOrdered = if returnResult()->notEmpty() then returnResult()-> exists(isOrdered) else false endif The redundant operation sibling can be retained for compatibility but should be clearly secondary. isOrdered() : Boolean body: isOrdered (The only occasion on which the sibling operations are necessary is if overloading in derived classes is required. Where this occurs the primary definition should certainly be the operation, with the default property value being the operation invocation.) (Once the property is self-contained, a related issue arises as to whether the 'derived' attribute is redundant with respect to 'readonly'. Can any derived attribute be mutable? Can any non-derived attribute be readonly?) Regards Ed Willink IMHO. This s On 22/06/2013 12:46, Steve Cook wrote: >It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. That is not how we do it in the metamodel. We do it using a separate operation with the same name. >IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Nobody is proposing getting rid of defaultValue. We will get rid of the particular defaultValues for derived properties whose value is calculated elsewhere. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 21 June 2013 11:41 To: Steve Cook Subject: 15668 Derived default values Hi On 18/06/2013 14:50, Steve Cook wrote: 15668. This issue suggests that default values for derived properties are meaningless. We agree, and will resolve the issue by deleting them. Surely the defaultValue (a poor name) is where the derived value is defined, just the same as the body of an operation? It is a ValueSpecification and so may have the constructive OCL that allows tools to compute the derived property. In contrast constraints that happen to mention the property/operation are poorly correlated with the required functionality. IMHO if you get rid of defaultValue you should also get rid of Operation.bodyCondition since postConditions will do 'just as well'. Regards Ed Willink No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6430 - Release Date: 06/21/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6434 - Release Date: 06/23/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=pUW89uuwYBcA:10 a=FynzZczSZDYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=D1-Pp1MCpyoA:10 a=vrshd3w6AAAA:8 a=ANOmflX2txeJB-mWXIgA:9 a=DFSfNU_vDif9nuwQ:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 Date: Mon, 24 Jun 2013 16:48:48 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "uml25-ftf@omg.org" Subject: Re: 15668 Derived default values X-Virus-Scanned: amavisd-new at omg.org Hi Ed On 24/06/2013 16:38, Ed Seidewitz wrote: but there is no call for changing the way that the OCL is attached for derivations. But where is the way in which OCL is attached specified? Regards Ed Willink X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink CC: "uml25-ftf@omg.org" Subject: RE: 15668 Derived default values Thread-Topic: 15668 Derived default values Thread-Index: AQHOcJ5ZBMGMNdKoCUy/Ho02fJxrgplEXhqQgABh/4D//64tsIAAhCkAgAANHBCAAFerAIAAB9dg Date: Mon, 24 Jun 2013 21:24:08 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.108.109.65] X-Virus-Scanned: amavisd-new at omg.org Ed . Good point. All I could find was the following sentence in Subclause 6.4 How to Read this Specification, under the discussion of how attributes are presented in Classifier Descriptions: .Where an attribute is derived, the logic of the derivation is in most cases shown using OCL.. This is, at best, in complete and actually rather misleading, since it says nothing about the fact that you actually have to look for an operation with the same name as the attribute to find the OCL. Unless I am missing something, it looks like there should be an issue about this. (I didn.t see any submitted already, and this is certainly different than 15668.) -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 5:49 PM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed On 24/06/2013 16:38, Ed Seidewitz wrote: but there is no call for changing the way that the OCL is attached for derivations. But where is the way in which OCL is attached specified? Regards Ed Willink From: Steve Cook To: Juergen Boldt CC: "uml25-ftf@omg.org" , "issues@omg.org" Subject: RE: 15668 Derived default values Thread-Topic: 15668 Derived default values Thread-Index: AQHObmvw7pi6WrClcUC29yw6P6kV1ZlBnkhAgALBPgCAAA04gIAAA++AgAAEPICAAC4ZAIAAYfSAgAAC0wCAAF2xAIAA0OYg Date: Tue, 25 Jun 2013 09:57:56 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(189002)(199002)(479174003)(377454003)(24454002)(512954002)(16236675002)(74366001)(71186001)(56776001)(16406001)(15202345003)(47976001)(56816003)(81542001)(33656001)(20776003)(63696002)(81342001)(54356001)(80022001)(49866001)(69226001)(6806003)(47736001)(46102001)(77096001)(31966008)(74662001)(51856001)(55846006)(53806001)(19300405004)(79102001)(74502001)(65816001)(74876001)(76786001)(54316002)(77982001)(76482001)(59766001)(76796001)(74706001)(50986001)(47446002)(4396001);DIR:OUT;SFP:;SCL:1;SRVR:BN1AFFO11HUB006;H:TK5EX14MLTC103.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0888B1D284 X-Virus-Scanned: amavisd-new at omg.org Juergen Could we raise an issue against UML 2.5 please: Title: Improve documentation of how derived properties are calculated. Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type. Thanks -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 24 June 2013 22:24 To: Ed Willink Cc: uml25-ftf@omg.org Subject: RE: 15668 Derived default values Ed . Good point. All I could find was the following sentence in Subclause 6.4 How to Read this Specification, under the discussion of how attributes are presented in Classifier Descriptions: .Where an attribute is derived, the logic of the derivation is in most cases shown using OCL.. This is, at best, in complete and actually rather misleading, since it says nothing about the fact that you actually have to look for an operation with the same name as the attribute to find the OCL. Unless I am missing something, it looks like there should be an issue about this. (I didn.t see any submitted already, and this is certainly different than 15668.) -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Monday, June 24, 2013 5:49 PM To: uml25-ftf@omg.org Subject: Re: 15668 Derived default values Hi Ed On 24/06/2013 16:38, Ed Seidewitz wrote: but there is no call for changing the way that the OCL is attached for derivations. But where is the way in which OCL is attached specified? Regards Ed Willink > Thatt