Issue 14560: Value of a Property (uml2-rtf) Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Enhancement Severity: Significant Summary: In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed. "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent. Suggested resolution : * Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification * Change defaultValue to be derived according to the following constraint: {OCL} defaultValue = if self.isDerived then self.valueSpecification else NULL endif Resolution: Revised Text: Actions taken: October 14, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 14 Oct 2009 09:24:36 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Yves BERNARD Company: EADS-Airbus mailFrom: yves.bernard@airbus.com Notification: Yes Specification: OMG Unified Modeling LanguageTM (OMG UML), Section: 7.3.44 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: May 2008 Page: 125-129 Title: Value of a Property Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed. "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent. Suggested resolution : * Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification * Change defaultValue to be derived according to the following constraint: Subject: RE: Derivation Expressions Date: Wed, 14 Oct 2009 17:38:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Derivation Expressions thread-index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9A From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Derivation Expressions To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 14 Oct 2009 22:06:51 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/14/2009 22:06:42 Ed, thanks! That solution sounds ok to me too. One question though, are constraints redefinable? i.e. can a subclass provide an redefining constraint with a different derivation? How is that done? "Ed Seidewitz" "Ed Seidewitz" 10/14/2009 05:38 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 pic27878.gif From: "Rouquette, Nicolas F (316A)" To: Maged Elaasar , Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Wed, 14 Oct 2009 19:51:36 -0700 Subject: Re: Derivation Expressions Thread-Topic: Derivation Expressions Thread-Index: AcpNPEZHCCamzcn+TNiAWHVjKLlxqQABiLSf Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Maged, Short answer: Constraints aren.t redefinable and making them redefinable would be ill-advised. This question pertains to a longstanding issue of documenting the language architecture principles for MOF metamodels. The strategic issue is that these principles have been scattered all over the place and need to be compiled and cross-referenced from one normative location in the spec. Doing so would open the possibility that the redefining constraints in the context of a specialized classifier may not be consistent with the redefined constraints in the context of the general classifier. In principle we would have no way then of verifying that the specialized classifier is a consistent specialization of the general classifier. In navigating down any hierarchy of classifiers or features, specialization, resp. redefinition can add but never remove or modify constraints inherited from general classifiers, resp. redefined features. To achieve the effect of specializing constraints in the context of a classifier hierarchy or redefinition hierarchy, the UML metamodel uses a pattern of delegation from a constraint to a redefinable operation. For example, Namespace::membersAreDistinguishable() delegates to the NamedElement::isDistinguishableFrom() operation which is redefined in BehavioralFeature::isDistinguishableFrom(). - Nicolas. On 10/14/09 7:06 PM, "Maged Elaasar" wrote: Ed, thanks! That solution sounds ok to me too. One question though, are constraints redefinable? i.e. can a subclass provide an redefining constraint with a different derivation? How is that done? "Ed Seidewitz" "Ed Seidewitz" 10/14/2009 05:38 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 Subject: RE: Derivation Expressions Date: Thu, 15 Oct 2009 14:32:44 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Derivation Expressions Thread-Index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9AAB+OewA= From: "BERNARD, Yves" To: "Ed Seidewitz" , "Maged Elaasar" Cc: X-OriginalArrivalTime: 15 Oct 2009 12:32:45.0766 (UTC) FILETIME=[991A7660:01CA4D93] Magged, Ed, I've just posted an issue on a related subject yesterday, cf. attachement. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 14 octobre 2009 23:38 À: Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 Received: from fr0-mailrt04.res.airbus.corp ([152.9.126.23]) by FR0-MAILMB12.res.airbus.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Oct 2009 17:15:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CA4CE1.2A07FE80" Received: from fr0-mailrt13.res.airbus.corp ([152.9.126.21]) by fr0-mailrt04.res.airbus.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Oct 2009 17:15:29 +0200 Received: from airbus-sf4.airbus.gmessaging.net ([81.252.56.12]) by fr0-mailrt13.res.airbus.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Oct 2009 17:15:29 +0200 Received: from airbus-pf3.airbus.gmessaging.net (localhost [127.0.0.1]) by localhost.airbus.gmessaging.net (Postfix) with SMTP id 6447CAC8100; Wed, 14 Oct 2009 17:15:27 +0200 (CEST) Received: from amethyst.omg.org (amethyst.omg.org [192.67.184.64]) by airbus-pf3.airbus.gmessaging.net (Postfix) with ESMTP id 949F7340069; Wed, 14 Oct 2009 17:15:26 +0200 (CEST) Received: from serpentine.omg.org (serpentine.omg.org [192.67.184.8]) by amethyst.omg.org (8.13.8/8.12.11) with ESMTP id n9EFCw1t006835; Wed, 14 Oct 2009 11:12:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by serpentine.omg.org (Postfix) with ESMTP id AE6223E60D3; Wed, 14 Oct 2009 11:14:55 -0400 (EDT) Received: from BOLDT.omg.org (unknown [192.67.184.116]) (Authenticated sender: omg1234) by serpentine.omg.org (Postfix) with ESMTP id 5086A3E60CC; Wed, 14 Oct 2009 11:14:52 -0400 (EDT) content-class: urn:content-classes:message Subject: issue 14560 -- UML 2 RTF issue Date: Wed, 14 Oct 2009 17:14:45 +0200 Message-ID: <10205_1255533327_4AD5EB0F_10205_186_2_20091014151452.5086A3E60CC@serpentine.omg.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14560 -- UML 2 RTF issue Thread-Index: AcpM4SrjTXFq5akDTDK1zLZxFmGffw== From: "Juergen Boldt" To: , From: webmaster@omg.org Date: 14 Oct 2009 09:24:36 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Yves BERNARD Company: EADS-Airbus mailFrom: yves.bernard@airbus.com Notification: Yes Specification: OMG Unified Modeling LanguageTM (OMG UML), Section: 7.3.44 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: May 2008 Page: 125-129 Title: Value of a Property Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed. "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent. Suggested resolution : * Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification * Change defaultValue to be derived according to the following constraint: {OCL} defaultValue = if self.isDerived then self.valueSpecification else NULL endif This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: Re: Derivation Expressions To: "Rouquette, Nicolas F (316A)" Cc: Ed Seidewitz , "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 15 Oct 2009 14:47:29 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2009 14:47:31 Nic, > The problem of verifying that an instance conforms to all of the constraints > specified by its classifier is considerably easier if we have a strong > guarantee that constraints defined in a general classifier are unchanged in > the context of any specialization of that general classifier. Why, because > it means that a specialized classifier effectively inherits all of the > constraints specified in its ancestor classifiers without any modification. I cannot see how a constraint can be inherited *without any modification* if it calls into a redefinable operation, that could be redefined in the subclass and changed. Therefore, I am still not very convinced that redefining the constraint directly is different from redefining an operation called from the constraint. Subject: RE:#14560 Value of a Property (from Derivation Expressions) Date: Fri, 16 Oct 2009 08:38:44 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Derivation Expressions Thread-Index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9AAB+OewAAB/Wj0AAdVP5w From: "BERNARD, Yves" To: "Ed Seidewitz" , "Maged Elaasar" Cc: X-OriginalArrivalTime: 16 Oct 2009 06:38:45.0392 (UTC) FILETIME=[4F445900:01CA4E2B] Ed, I understand that "value of a property" is related to the M0 level and i don't ask to add a "value" attribute to the Property meta-class. I do agree on your point about derivation. Nevertheless, you cannot say on one hand that the value of a property depends on other model elements (ie. is derived) and on the other hand define its default value arbitrarily (what is possible today through its defaultValue attribute). This point has already been underlined in a previous discussion. My proposal is not to use the default value to specifiy to the constraint but conversely to constraint the default value to stick to the derivation constraint when the property is derived or more precisely to prevent the (arbitrary) specification of default values for derived properties. And yes, i think that it could be a more general answer to the issue raised by Magged. ;o) Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 15 octobre 2009 18:23 À: BERNARD, Yves; Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Yves . Yes, I did see that, though I wasn.t sure why you had a problem with the phrase .the value of a property.. This pretty standard terminology to mean the value that the property has at runtime (i.e., in an MO instance of the classifier with the property). In any case, your suggestion for adding a value specification to property for the purposes of derivation seems to be a generalization of what Maged proposed (ValueSpecification is a generalization of OpaqueExpression), and my comments to him apply. Moreover, the point of a derivation is not to just set the default value of the property, which is really only the initial value by UML semantics, but to determine the value of that property completely at any point in time. Nevertheless, your filed issue can provide the vehicle for resolving the underlying concern on better defining the formal derivation of a derived property, which I think the input from both you and Maged show is a general one. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 15, 2009 8:33 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Derivation Expressions Magged, Ed, I've just posted an issue on a related subject yesterday, cf. attachement. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 14 octobre 2009 23:38 À: Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14560 Value of a Property (from Derivation Expressions) Date: Fri, 16 Oct 2009 10:14:40 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14560 Value of a Property (from Derivation Expressions) thread-index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9AAB+OewAAB/Wj0AAdVP5wABCUo9A= From: "Ed Seidewitz" To: "BERNARD, Yves" Cc: Bernard . OK, I think I see that your point is that, if a property is derived, then its value is already entirely determined by its derivation and, therefore, it doesn.t make sense to give it a default initial value. This would seem to actually be independent of how the derivation is formally specified, if at all. So perhaps the resolution should simply be a constraint on Property such that, if the property is derived, it does not have a default value (e.g., self.isDerived implies self.defaultValue->isEmpty()). -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, October 16, 2009 2:39 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE:#14560 Value of a Property (from Derivation Expressions) Ed, I understand that "value of a property" is related to the M0 level and i don't ask to add a "value" attribute to the Property meta-class. I do agree on your point about derivation. Nevertheless, you cannot say on one hand that the value of a property depends on other model elements (ie. is derived) and on the other hand define its default value arbitrarily (what is possible today through its defaultValue attribute). This point has already been underlined in a previous discussion. My proposal is not to use the default value to specifiy to the constraint but conversely to constraint the default value to stick to the derivation constraint when the property is derived or more precisely to prevent the (arbitrary) specification of default values for derived properties. And yes, i think that it could be a more general answer to the issue raised by Magged. ;o) Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 15 octobre 2009 18:23 À: BERNARD, Yves; Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Yves . Yes, I did see that, though I wasn.t sure why you had a problem with the phrase .the value of a property.. This pretty standard terminology to mean the value that the property has at runtime (i.e., in an MO instance of the classifier with the property). In any case, your suggestion for adding a value specification to property for the purposes of derivation seems to be a generalization of what Maged proposed (ValueSpecification is a generalization of OpaqueExpression), and my comments to him apply. Moreover, the point of a derivation is not to just set the default value of the property, which is really only the initial value by UML semantics, but to determine the value of that property completely at any point in time. Nevertheless, your filed issue can provide the vehicle for resolving the underlying concern on better defining the formal derivation of a derived property, which I think the input from both you and Maged show is a general one. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 15, 2009 8:33 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Derivation Expressions Magged, Ed, I've just posted an issue on a related subject yesterday, cf. attachement. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 14 octobre 2009 23:38 À: Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14560 Value of a Property (from Derivation Expressions) Date: Fri, 16 Oct 2009 16:42:52 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14560 Value of a Property (from Derivation Expressions) Thread-Index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9AAB+OewAAB/Wj0AAdVP5wABCUo9AAARMSgA== From: "BERNARD, Yves" To: "Ed Seidewitz" Cc: X-OriginalArrivalTime: 16 Oct 2009 14:42:53.0190 (UTC) FILETIME=[F11A9260:01CA4E6E] Ed, This is one part of my point, indeed. The solution you propose is convenient to avoid inconsistencies between the default value and the derivation constraint but: a) it doesn't help ensuring that the derivation constraint is defined for a derived property b) Despite, it's possible for a stereotype of Property to inforce isDerived, it still doesn't have the means to constrain the way the value of that extended property is computed. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé vendredi 16 octobre 2009 16:15 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : RE: #14560 Value of a Property (from Derivation Expressions) Bernard . OK, I think I see that your point is that, if a property is derived, then its value is already entirely determined by its derivation and, therefore, it doesn.t make sense to give it a default initial value. This would seem to actually be independent of how the derivation is formally specified, if at all. So perhaps the resolution should simply be a constraint on Property such that, if the property is derived, it does not have a default value (e.g., self.isDerived implies self.defaultValue->isEmpty()). -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, October 16, 2009 2:39 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE:#14560 Value of a Property (from Derivation Expressions) Ed, I understand that "value of a property" is related to the M0 level and i don't ask to add a "value" attribute to the Property meta-class. I do agree on your point about derivation. Nevertheless, you cannot say on one hand that the value of a property depends on other model elements (ie. is derived) and on the other hand define its default value arbitrarily (what is possible today through its defaultValue attribute). This point has already been underlined in a previous discussion. My proposal is not to use the default value to specifiy to the constraint but conversely to constraint the default value to stick to the derivation constraint when the property is derived or more precisely to prevent the (arbitrary) specification of default values for derived properties. And yes, i think that it could be a more general answer to the issue raised by Magged. ;o) Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 15 octobre 2009 18:23 À: BERNARD, Yves; Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Yves . Yes, I did see that, though I wasn.t sure why you had a problem with the phrase .the value of a property.. This pretty standard terminology to mean the value that the property has at runtime (i.e., in an MO instance of the classifier with the property). In any case, your suggestion for adding a value specification to property for the purposes of derivation seems to be a generalization of what Maged proposed (ValueSpecification is a generalization of OpaqueExpression), and my comments to him apply. Moreover, the point of a derivation is not to just set the default value of the property, which is really only the initial value by UML semantics, but to determine the value of that property completely at any point in time. Nevertheless, your filed issue can provide the vehicle for resolving the underlying concern on better defining the formal derivation of a derived property, which I think the input from both you and Maged show is a general one. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 15, 2009 8:33 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Derivation Expressions Magged, Ed, I've just posted an issue on a related subject yesterday, cf. attachement. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 14 octobre 2009 23:38 À: Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE: #14560 Value of a Property (from Derivation Expressions) Date: Fri, 16 Oct 2009 11:43:36 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #14560 Value of a Property (from Derivation Expressions) thread-index: AcpNEILFdcGtpdWPRveUWjGomqGvOwABFW9AAB+OewAAB/Wj0AAdVP5wABCUo9AAARMSgAACCiGA From: "Ed Seidewitz" To: "BERNARD, Yves" Cc: Yves (sorry for calling you .Bernard. earlier, I get confused on this sometimes!) . Right, I understand your other point . that is the part that is essentially the same issue that Maged raised. However, there actually is a way to constrain the value of a derived property . you just use a constraint, as described in the spec. All that is missing at the moment is way to formally identify which constraint(s) determine the value of a derived property, which I agree might be useful. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, October 16, 2009 10:43 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: #14560 Value of a Property (from Derivation Expressions) Ed, This is one part of my point, indeed. The solution you propose is convenient to avoid inconsistencies between the default value and the derivation constraint but: a) it doesn't help ensuring that the derivation constraint is defined for a derived property b) Despite, it's possible for a stereotype of Property to inforce isDerived, it still doesn't have the means to constrain the way the value of that extended property is computed. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé vendredi 16 octobre 2009 16:15 À: BERNARD, Yves Cc : uml2-rtf@omg.org Objet : RE: #14560 Value of a Property (from Derivation Expressions) Bernard . OK, I think I see that your point is that, if a property is derived, then its value is already entirely determined by its derivation and, therefore, it doesn.t make sense to give it a default initial value. This would seem to actually be independent of how the derivation is formally specified, if at all. So perhaps the resolution should simply be a constraint on Property such that, if the property is derived, it does not have a default value (e.g., self.isDerived implies self.defaultValue->isEmpty()). -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, October 16, 2009 2:39 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE:#14560 Value of a Property (from Derivation Expressions) Ed, I understand that "value of a property" is related to the M0 level and i don't ask to add a "value" attribute to the Property meta-class. I do agree on your point about derivation. Nevertheless, you cannot say on one hand that the value of a property depends on other model elements (ie. is derived) and on the other hand define its default value arbitrarily (what is possible today through its defaultValue attribute). This point has already been underlined in a previous discussion. My proposal is not to use the default value to specifiy to the constraint but conversely to constraint the default value to stick to the derivation constraint when the property is derived or more precisely to prevent the (arbitrary) specification of default values for derived properties. And yes, i think that it could be a more general answer to the issue raised by Magged. ;o) Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 15 octobre 2009 18:23 À: BERNARD, Yves; Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Yves . Yes, I did see that, though I wasn.t sure why you had a problem with the phrase .the value of a property.. This pretty standard terminology to mean the value that the property has at runtime (i.e., in an MO instance of the classifier with the property). In any case, your suggestion for adding a value specification to property for the purposes of derivation seems to be a generalization of what Maged proposed (ValueSpecification is a generalization of OpaqueExpression), and my comments to him apply. Moreover, the point of a derivation is not to just set the default value of the property, which is really only the initial value by UML semantics, but to determine the value of that property completely at any point in time. Nevertheless, your filed issue can provide the vehicle for resolving the underlying concern on better defining the formal derivation of a derived property, which I think the input from both you and Maged show is a general one. -- Ed -------------------------------------------------------------------------------- From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, October 15, 2009 8:33 AM To: Ed Seidewitz; Maged Elaasar Cc: uml2-rtf@omg.org Subject: RE: Derivation Expressions Magged, Ed, I've just posted an issue on a related subject yesterday, cf. attachement. Yves -----Message d'origine----- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé mercredi 14 octobre 2009 23:38 À: Maged Elaasar Cc : uml2-rtf@omg.org Objet : RE: Derivation Expressions Maged . While a derived property is often given the computed value of some expression, a derivation will not always be a direct computation. In general, any constraint strong enough to give a unique value for the property is sufficient. This could be, e.g., a requirement that a numerical property is the root of some complicated function, that a referential property has a certain relationship to other properties, etc. The specification text is actually correct in giving derivations as constraints . in the semantics for Property, it says that .The derivation for a derived property may be specified by a constraint.. I don.t know of any normative convention for giving a derivation via an operation with the same name as the property, unless there is also a constraint specifying that the value of the property is the result of calling the operation. In order to make the connection between a derived property and its derivation more explicit, rather than introducing a derivationExpression attribute, one could instead add a derivationConstraint association, which would point to the constraint (or constraints?) by which the property is derived (which could still be owned, for example, by the classifier that owns the property). -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 14, 2009 4:17 PM To: uml2-rtf@omg.org Subject: Derivation Expressions The current convensions for representing derivation expressions for derived properties in UML spec are: In the spec text: It is specified as a constraint with syntax: "property_name = " In the metamode: It is specified as an operation whose name is "property_name" and whose body constraint is "result = " I think the link between a derived property and its derivation expression should be modeled by making the derivationExpression: OpaqueExpression an attribute of metaclass Property, instead of using this convension which is not formal and hard to trace. What do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. {OCL} defaultValue = if self.isDerived then self.valueSpecification else NULL endif