Issue 6974: Ambiguous semantics of isStatic (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: The semantics of isStatic = true is ambiguous for structural features declared on classifiers that have children. It is not defined whether this gives a single value for the classifier and all its descendents, or values for the classifier and each descendant separately. Resolution: see above Revised Text: Actions taken: February 9, 2004: received issue March 8, 2005: closed issue Discussion: An example: Suppose some classifier A is specified in UML as having a static feature, in particular someProperty: integer. Suppose A is specified as a parent, generalizing two children, B1subA and B2subA. Suppose further that for some system, which is supposed to conform with this specification, the value 5 is specified for A.someProperty Analysis of the issue: 1. UML 2 semantics in the FAS do not determine whether specializations inherit the value along with the static features of their parents. Given that the child B1subA will inherit the static .someProperty, must B1subA.someProperty = 5? 2. Readers of the spec are likely to read into UML such inheritance of values, because OO programming languages provide for inheritance of static values. The issue asks for a ruling on this point: either explicitly specify inheritance of static values, or explicitly state that it is a semantic variation point. To take the third path, of saying the values are CANNOT be inherited, is out of the question because it would bar us from modeling C++, Java, or C#. This resolution proposes inheritance of static values should be a semantic variation point. Extended discussion: The term 'static' as a keyword or modifier in OO programming languages has a long history, notably in C++, Java, and C#. To understand the intended semantics of isStatic = true or false in UML 2, it is first necessary to understand that this isStatic attribute exists in UML 2 to facilitate modeling C++, Java, and C# and that our answer should be consistent with what these OO languages do with static members, but should not favor one language over another. So here is a summary of how static members are used in leading OO programming languages: static members are best understood as members that characterize classes, not the objects that are instances of classes. In some cases (Java) , it is permitted (but discouraged) as a way of characterizing n different instances efficiently by using the classifier as a distribution mechanism of one value to all, but that is a perversion of their purpose and is a violation of the coding conventions for Java.. All OO programming languages discourage accessing the value of static members through instances by calling it a bad practice , and C# goes so far as to make any attempt to do so a compile-time error. This proves that the intent of the programming language designers is to have static members characterize the Class itself, not the several instances of the class individually. A feature for which isStatic = false is an instance feature. An instance feature differentiates insta nces of the same classifier, wrt the values that feature takes. In contrast, a feature for which isStatic = true is termed a static feature, and the classifier itself, not its instances, holds a value for this feature. Hence, all instances of this classifier, since they are all classified by this one classifier, may sometimes (erroneously) be thought to share the exact same value for their classifier's static features. This thought is an error because: statics are by definition NOT instance features, the semantics of features for which isStatic = true is that such features do not characterize instances AT ALL, but characterize instead the classifier. This is the erroneous idea behind the text in the UML 2 Superstructure text that describes statics as assigning a value "at the classifier level". That implies that the values apply at the instance level, but are for convenience, assigned at a "level" that covers many instances. Here is an example: Suppose the static feature of some classifier A is someProperty: integer. Making our example more detailed, suppose the static feature of classifier A is numberOfInstancesClassified: integer, and the intended meaning of this is loosely expressed as: the count of how many instances are classified by this classifier A. Suppose this classifier is the parent generalizing two others, as in an example provided by Conrad Bock. There are two ways to answer this. 1. If we interpret the feature more precisely as the count of how many instances are classified by classifier A, we get one answer 1. If we interpret the feature more precisely as the count of how many instances are classified by classifier self, we get another answer because the context has changed. One might want classifiers to inherit the ability to count their own instances. This could be a very useful behavioral feature. Our semantic variation point recommendation would permit that, and that is only possible if the values are not inherited. It is useful to think of instance features as features that describe instances as distinct individuals. Normally, different instances of the same classifier may differ wrt the value of that feature. We might all have a name, but fortunately, we mostly have different values for the name feature. Following this line of thought, static features must be features that characterize classifiers, in that the value of a static feature is never determined by instance data, but by the classifier itself. A more specialized classifier is indeed a DIFFERENT classifier from its general parent. It should have the ability to have a different value for a static feature. Old text: section 7.9.2: Feature (p. 73 of FAS) New text: For the description of the attribute isStatic: Boolean, use: Specifies whether this feature characterizes individual instances classified by the classifier (false) or the classifier itself (true). Default value is false. For the semantics subsection quoted above, substitute the following, including the new semantic variation points subsection. A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier's instances considered individually (not static), or of the classifier itself (static). A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another. Semantic Variation Points With regard to static features, two alternative semantics are recognized: a static feature may have different values for different featuring classifiers, or the same value for all featuring classifiers. In accord with this semantic variation point, inheritance of values for static features is permitted but not required by UML 2. Such inheritance is encouraged when modeling systems to be coded in languages, such as C++, Java, and C#, which stipulate inheritance of values for static features. End of Annotations:===== eply-To: From: "Conrad Bock" To: Cc: Subject: Resubmission of 4446 Date: Mon, 9 Feb 2004 15:06:53 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Juergen, Here is a restatement of issue 4446 with UML 2 terminology, that should be logged as a new issue. It is shared between infra and super. Conrad Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Minor Subject: Ambiguous semantics of isStatic The semantics of isStatic = true is ambiguous for structural features declared on classifiers that have children. It is not defined whether this gives a single value for the classifier and all its descendents, Subject: 6974 easy issue for next ballot. Date: Sat, 31 Jul 2004 08:17:21 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR2gUXw5i/248+FTryvckYjVsfXiAAj80sA From: "Karl Frank" To: "Branislav Selic" , Cc: X-OriginalArrivalTime: 31 Jul 2004 15:17:25.0182 (UTC) FILETIME=[7C0135E0:01C47711] Please see attached. - Karl Frank Issue6974.doc OMG Issue No: 6974 Title: Ambiguous semantics of isStatic Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The semantics of isStatic = true is ambiguous for structural features declared on classifiers that have children. It is not defined whether this gives a single value for the classifier and all its descendents, or values for the classifier and each descendant separately. Discussion: We shall add to the semantic subsection on Feature to improve the clarity of the spec wrt the semantics of isStatic = true. Not everyone agrees that the spec is ambiguous on this point, and those of this opinion may object to the added text as redundant. Of course, redefinition enables the introduction of a new feature with the old name, and a new feature may have a different value for isStatic, but that is irrelevant to the issue at hand. Old text: subsection Semantics, section: Feature chapter:Classes doc: Super (p. 73) New text: For the concluding sentence quoted above will read: A Feature can be a feature of multiple classifiers, in which case the feature's value for isStatic shall remain one and the same value in the context of each featuring Classifier. Disposition: Resolved From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , Cc: Subject: RE: 6974 easy issue for next ballot. Date: Sat, 31 Jul 2004 12:55:20 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank To: "Thomas Weigert" Cc: "Karl Frank" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sat, 31 Jul 2004 15:45:43 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/31/2004 15:45:45, Serialize complete at 07/31/2004 15:45:45 I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank Subject: RE: 6974 easy issue for next ballot. Date: Mon, 2 Aug 2004 05:42:17 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR3NvnQX7ADIOlARJ66sL+Wb0CahQBUvkwQ From: "Karl Frank" To: "Branislav Selic" , "Thomas Weigert" Cc: , X-OriginalArrivalTime: 02 Aug 2004 12:42:22.0375 (UTC) FILETIME=[27ED0370:01C4788E] Thomas, the clarification of what my new proposed sentence means is given below in black. The bigger issue is whether my proposed resolution is correct or adequate. I classified this (in my triage of issues) as a top priority issue for classes because I see it as part of the problem UML has with using instantiation as its paradigm for model/metamodel conformance, and also having instanceSpecification as a model element alongside the Classifier in the same metalevel. Maybe, by introducing the notion of isStatic and saying it means the attribute is applied "at the classifier level", the spec itself is furthering a confusion about whether we are talking about the modeling element Feature and its metaattribute isStatic, or about some user instance of a static Feature, which happens to be of type integer and which is assigned value 5. It seems to me that if the Feature is really "at the classifier level" then the fact that it has a static assigned value of becomes part of the metamodel, not the user model. What Conrad is asking is really, does every instance of the same static feature have, not only the same value for isStatic, but must if also have the same value for the static feature. My proposal says "The UML 2 metamodel doesn't know about the integer values that may be provided in a user model for a static feature. It just knows about the metaattribute isStatic, and its boolean values. I was trying to express this view by my proposed new sentence, which is further explained as follows in the attached v1 of the proposal. For example, suppose a classifier A has feature f, and A is also declared as parent of B1 and B2 in two generalization relaionships. This is an example in which a feature f is a feature of multiple classifiers, viz. A, B1, and B2. If f has attribute isStatic = True in the context of A, it likewise must have as isStatic True in the context of both B1 and B2. Here is the email Conrad sent to explain the issue (it is originally his). - Karl The spec only says: isStatic: Boolean Specifies whether the feature is applied at the classifier-level (true) or the instance-level (false). Default value is false. Apply this to the following example: ClassA AttrB [*] {isStatic = true} ^ ^ | | | | ClassSubA1 ClassSubA2 Unless you infer the meaning from programming languages, you might wonder if there could be separate static values for ClassA, ClassSubA1, and ClassSubA2, that apply only the instances of those classes. For example, the static values for ClassSubA1 might not apply to ClassSubA2. I assume the meaning is that there is only the values for ClassA, and that all the instances of ClassA and its descendants see the same values. C -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Aug 2004 07:35:06 -0700 To: , From: Joaquin Miller Subject: RE: 6974 easy issue for next ballot. I trust we all agree that UML 2 should attempt to be programing language neutral. (If not, i will stand corrected, and suggest we list the languages UML is intended to be suitable for.) Of course, it's inevitable that there are languages out there that just don't fit with the presumptions of UML 2. Still, we ought to use a number of the commercial languages to test our work. A small such set might include Java, C#, C++, and Smalltalk. We might also use the .NET CIL. The tests would be whether UML 2 is well suited to specify the structure of a program in the test language. Should it be the case that we choose to exclude some widely used languages, such as C and COBOL, then as a service to our users we should say that in the specification document. Not list all such languages, of course, but say that we have consciously excluded some, and list a few so folks can have some indication of the criteria we have used to admit certain languages to the fold, and exclude others. In Smalltalk, of course, we find both kinds of class attributes, i.e. both kinds of attributes that are isStatic: Smalltalk has both class variables and class instance variables. In Conrad's example, the value of a class variable declared in A will be the same in all objects of A, SubA1 and Sub A2. The value of a class instance variable might have one value in all objects of A, a different value in objects of SubA1, and yet another in objects of SubA2 In Karl's text, the value of a class variable declared in A will be the same in all objects of A, B1 and B2. The value of a class instance variable might have one value in all objects of A, a different value in objects of B1, and yet another in objects of B2 At 05:42 AM 8/2/2004, Karl Frank wrote: Thomas, the clarification of what my new proposed sentence means is given below in black. The bigger issue is whether my proposed resolution is correct or adequate. I classified this (in my triage of issues) as a top priority issue for classes because I see it as part of the problem UML has with using instantiation as its paradigm for model/metamodel conformance, and also having instanceSpecification as a model element alongside the Classifier in the same metalevel. Maybe, by introducing the notion of isStatic and saying it means the attribute is applied "at the classifier level", the spec itself is furthering a confusion about whether we are talking about the modeling element Feature and its metaattribute isStatic, or about some user instance of a static Feature, which happens to be of type integer and which is assigned value 5. It seems to me that if the Feature is really "at the classifier level" then the fact that it has a static assigned value of becomes part of the metamodel, not the user model. What Conrad is asking is really, does every instance of the same static feature have, not only the same value for isStatic, but must if also have the same value for the static feature. My proposal says "The UML 2 metamodel doesn't know about the integer values that may be provided in a user model for a static feature. It just knows about the metaattribute isStatic, and its boolean values. I was trying to express this view by my proposed new sentence, which is further explained as follows in the attached v1 of the proposal. For example, suppose a classifier A has feature f, and A is also declared as parent of B1 and B2 in two generalization relaionships. This is an example in which a feature f is a feature of multiple classifiers, viz. A, B1, and B2. If f has attribute isStatic = True in the context of A, it likewise must have as isStatic True in the context of both B1 and B2. Here is the email Conrad sent to explain the issue (it is originally his). - Karl The spec only says: isStatic: Boolean Specifies whether the feature is applied at the classifier-level (true) or the instance-level (false). Default value is false. Apply this to the following example: ClassA AttrB [*] {isStatic = true} ^ ^ | | | | ClassSubA1 ClassSubA2 Unless you infer the meaning from programming languages, you might wonder if there could be separate static values for ClassA, ClassSubA1, and ClassSubA2, that apply only the instances of those classes. For example, the static values for ClassSubA1 might not apply to ClassSubA2. I assume the meaning is that there is only the values for ClassA, and that all the instances of ClassA and its descendants see the same values. C -------------------------------------------------------------------------------- I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S Subject: RE: 6974 easy issue for next ballot. Date: Tue, 3 Aug 2004 12:09:36 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR3NvnQX7ADIOlARJ66sL+Wb0CahQCThMbA From: "Karl Frank" To: "Branislav Selic" , "Thomas Weigert" Cc: , X-OriginalArrivalTime: 03 Aug 2004 19:09:44.0936 (UTC) FILETIME=[6FFC1E80:01C4798D] I have addressed the points made in discussion of my first attempt, in the attached upgraded resolution. Summary: Conrad's point is, 1. UML 2 semantics do not determine whether, in systems conforming to UML 2, specializations must inherit the static value along with the inherited static features of their parents. 2. Readers of the spec are likely to assume such inheritance of values was intended but left unstated. We must either explicitly say static feature brings its value along in inheritance (among other contexts where the "same" feature may be features of many classifiers), or explicitly recognize this as a semantic variation point to avoid the charge of ambiguity. We argue and conclude that UML 2 should allow inheritance of static values as a semantic variation point, further, that for compatibility with C#, we propose to change the language of the spec that currently describes the isStatic attribute as being used to say that an attribute is being assigned a value at the "level" of the classifier. This language should be changed because it is contrary to the facts that 1. instances are not at a "lower level" in some hierarchy inhabited by them along with classifiers. 2. instances are not getting the attribute value at all, static values do not "filter down to the objects from the classifier". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank Issue6974upgrade.doc Subject: Recall: 6974 easy issue for next ballot. Date: Tue, 3 Aug 2004 12:26:49 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR5j9Y9PB+5W7GhQaSL1b/JCcC2/A== Priority: Urgent Expiry-Date: Thu, 5 Aug 2004 12:26:48 -0700 From: "Karl Frank" To: "Branislav Selic" , "Thomas Weigert" Cc: , X-OriginalArrivalTime: 03 Aug 2004 19:26:56.0157 (UTC) FILETIME=[D6A3F4D0:01C4798F] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i73Jd6lj021261 Karl Frank would like to recall the message, "6974 easy issue for next ballot.". Subject: RE: 6974 easy issue for next ballot. Date: Tue, 3 Aug 2004 12:27:42 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR3NvnQX7ADIOlARJ66sL+Wb0CahQCThMbA From: "Karl Frank" To: "Branislav Selic" , "Thomas Weigert" Cc: , X-OriginalArrivalTime: 03 Aug 2004 19:27:50.0559 (UTC) FILETIME=[F7110AF0:01C4798F] A spellcheck fixed some errors in the attachment. Please discard any earlier version. ----------------------------------------------------- I have addressed the points made in discussion of my first attempt, in the attached upgraded resolution. Summary: Conrad's point is, 1. UML 2 semantics do not determine whether, in systems conforming to UML 2, specializations must inherit the static value along with the inherited static features of their parents. 2. Readers of the spec are likely to assume such inheritance of values was intended but left unstated. We must either explicitly say static feature brings its value along in inheritance (among other contexts where the "same" feature may be features of many classifiers), or explicitly recognize this as a semantic variation point to avoid the charge of ambiguity. We argue and conclude that UML 2 should allow inheritance of static values as a semantic variation point, further, that for compatibility with C#, we propose to change the language of the spec that currently describes the isStatic attribute as being used to say that an attribute is being assigned a value at the "level" of the classifier. This language should be changed because it is contrary to the facts that 1. instances are not at a "lower level" in some hierarchy inhabited by them along with classifiers. 2. instances are not getting the attribute value at all, static values do not "filter down to the objects from the classifier". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank Issue6974upgrade_spellchecked.doc OMG Issue No: 6974 Title: Ambiguous semantics of isStatic Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The semantics of isStatic = true is ambiguous for structural features declared on classifiers that have children. It is not defined whether this gives a single value for the classifier and all its descendents, or values for the classifier and each descendant separately. Discussion: An example: Suppose some classifier A is specified in UML as having a static feature, in particular someProperty: integer. Suppose A is specified as a parent, generalizing two children, B1subA and B2subA. Suppose further that for some system, which is supposed to conform with this specification, the value 5 is specified for A.someProperty Analysis of the issue: 1. UML 2 semantics in the FAS do not determine whether specializations inherit the value along with the static features of their parents. Given that the child B1subA will inherit the static .someProperty, must B1subA.someProperty = 5? 2. Readers of the spec are likely to read into UML such inheritance of values, because OO programming languages provide for inheritance of static values. The issue asks for a ruling on this point: either explicitly specify inheritance of static values, or explicitly state that it is a semantic variation point. To take the third path, of saying the values are NOT inherited, is out of the question because it is contrary to what OO programming languages do, and so would bar us from modeling C++, Java, or C#. This resolution proposes inheritance of static values should be a semantic variation point, and further, that for compatibility with C#, we change the language of the spec that currently describes the isStatic attribute as being used to say that static features are applied to instances at the "level" of the classifier. The notion of level is inappropriate, as the instances of a classifier are NOT a lower level of a hierarchy that includes the classifier as a "higher" level of the same kind of entity. Indeed, C# makes it a compile time error to attempt to get the value of a static member thru an instance. Statics don't describe instances. Extended discussion: The term 'static' as a keyword or modifier in OO programming languages has a long history, notably in C++, Java, and C#. To understand the intended semantics of isStatic = true or false in UML 2, it is first necessary to understand that this isStatic attribute exists in UML 2 to facilitate modeling C++, Java, and C# and that our answer should be consistent with what these OO languages do with static members, but should not favor one language over another. So here is a summary of how static members are used in leading OO programming languages: static members are best understood as members that characterize classes, not the objects that are instances of classes. In some cases (Java) , it is permitted (but discouraged) as a way of characterizing n different instances efficiently by using the classifier as a distribution mechanism of one value to all, but that is a perversion of their purpose. All OO programming languages discourage accessing the value of static members through instances by calling it a bad practice , and C# goes so far as to make any attempt to do so a compile-time error. This proves that the intent of the programming language designers is to have static members characterize the Class itself, not the several instances of the class. A feature for which isStatic = false is an instance feature. An instance feature differentiates instances of the same classifier, wrt the values that feature takes. In contrast, a feature for which isStatic = true is termed a static feature, and the classifier itself, not its instances, holds a value for this feature. Hence, all instances of this classifier, since they are all classified by this one classifier, may sometimes (erroneously) be thought to share the exact same value for their classifier's static features. This thought is an error because: statics are by definition NOT instance features, the semantics of features for which isStatic = true is that such features do not characterize instances AT ALL, but characterize instead the classifier. This is the erroneous idea behind the text in the UML 2 Superstructure text that describes statics as assigning a value "at the classifier level". That implies that the values apply at the instance level, but are for convenience, assigned at a "level" that covers many instances. Here is an example: Suppose the static feature of some classifier A is someProperty: integer. Making our example more detailed, suppose the static feature of classifier A is numberOfInstancesClassified: integer, and the intended meaning of this is loosely expressed as: the count of how many instances are classified by this classifier A. Suppose this classifier is the parent generalizing two others, as in Conrad's example. There are two ways to answer this. 1. If we interpret the feature more precisely as the count of how many instances are classified by classifier A, we get one answer 1. If we interpret the feature more precisely as the count of how many instances are classified by classifier self, we get another answer because the context has changed. One might want classifiers to inherit the ability to count their own instances. This could be a very useful behavioral feature. Our semantic variation point recommendation would permit that, and that is only possible if the values are not inherited. It is useful to think of instance features as features that describe instances as distinct individuals. Normally, different instances of the same classifier may differ wrt the value of that feature. We might all have a name, but fortunately, we mostly have different values for the name feature. Following this line of thought, static features must be features that characterize classifiers, in that the value of a static feature is never determined by instance data, but by the classifier itself. A more specialized classifier is indeed a DIFFERENT classifier from its general parent. It should have the ability to have a different value for a static feature. Old text: subsection Semantics, section: Feature chapter:Classes doc: Super (p. 72) Attributes New text: For the description of the attribute isStatic: Boolean, use: Specifies whether this feature characterizes instances classified by the classifier (false) or the classifier itself (true). Default value is false. (p. 73) For the semantics subsection quoted above, use: A feature represents some characteristic, which may be of its featuring classifiers (static) or of their instances (not static). A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another. For example, suppose a classifier A has feature f, and A is also declared as parent of B1 and B2 in two generalization relationships. This is an example in which f is a feature of multiple classifiers, viz. A, B1, and B2. If f has attribute isStatic = True in the context of A, it likewise must have as isStatic = True in the context of both B1 and B2. The above is not to be understood as requiring that the value of static feature f is the same for A, B1, and B2. Inheritance of values for static features is permitted but not required by UML 2; this is a semantic variation point. Such inheritance is encouraged when modeling systems to be coded in languages, such as C++, Java, and C#, which stipulate inheritance of values for static features. Disposition: Resolved From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: 6974 easy issue for next ballot. Date: Tue, 3 Aug 2004 21:35:44 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, good. You have finally gotten to the point of clearly defining this as class variable vs. instance variable. In light of this, it would be good to change the name to something more meaningful. "static" is a bad name in C++ (derived from "static" in C, having to do with persistence), but it is an impossible name in UML. There is nothing "static" about such features. Secondly, you should indicate semantic variation points as customary in the specification. Introduce a new heading in italics "Semantic variation points" and then put a condensed version of your last paragraph after that. Cheers, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 03, 2004 2:28 PM To: Branislav Selic; Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. A spellcheck fixed some errors in the attachment. Please discard any earlier version. ----------------------------------------------------- I have addressed the points made in discussion of my first attempt, in the attached upgraded resolution. Summary: Conrad's point is, 1. UML 2 semantics do not determine whether, in systems conforming to UML 2, specializations must inherit the static value along with the inherited static features of their parents. 2. Readers of the spec are likely to assume such inheritance of values was intended but left unstated. We must either explicitly say static feature brings its value along in inheritance (among other contexts where the "same" feature may be features of many classifiers), or explicitly recognize this as a semantic variation point to avoid the charge of ambiguity. We argue and conclude that UML 2 should allow inheritance of static values as a semantic variation point, further, that for compatibility with C#, we propose to change the language of the spec that currently describes the isStatic attribute as being used to say that an attribute is being assigned a value at the "level" of the classifier. This language should be changed because it is contrary to the facts that 1. instances are not at a "lower level" in some hierarchy inhabited by them along with classifiers. 2. instances are not getting the attribute value at all, static values do not "filter down to the objects from the classifier". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank To: "Thomas Weigert" Cc: "Karl Frank" , mu2i-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 4 Aug 2004 07:57:31 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/04/2004 07:57:33, Serialize complete at 08/04/2004 07:57:33 While I too hate the term "static", changing it at this point is gratuitous, out of scope of the FTF, and likely to cause confusion. Leave it. Bran "Thomas Weigert" 08/03/2004 10:35 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, "Thomas Weigert" cc , Subject RE: 6974 easy issue for next ballot. Karl, good. You have finally gotten to the point of clearly defining this as class variable vs. instance variable. In light of this, it would be good to change the name to something more meaningful. "static" is a bad name in C++ (derived from "static" in C, having to do with persistence), but it is an impossible name in UML. There is nothing "static" about such features. Secondly, you should indicate semantic variation points as customary in the specification. Introduce a new heading in italics "Semantic variation points" and then put a condensed version of your last paragraph after that. Cheers, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 03, 2004 2:28 PM To: Branislav Selic; Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. A spellcheck fixed some errors in the attachment. Please discard any earlier version. ----------------------------------------------------- I have addressed the points made in discussion of my first attempt, in the attached upgraded resolution. Summary: Conrad's point is, 1. UML 2 semantics do not determine whether, in systems conforming to UML 2, specializations must inherit the static value along with the inherited static features of their parents. 2. Readers of the spec are likely to assume such inheritance of values was intended but left unstated. We must either explicitly say static feature brings its value along in inheritance (among other contexts where the "same" feature may be features of many classifiers), or explicitly recognize this as a semantic variation point to avoid the charge of ambiguity. We argue and conclude that UML 2 should allow inheritance of static values as a semantic variation point, further, that for compatibility with C#, we propose to change the language of the spec that currently describes the isStatic attribute as being used to say that an attribute is being assigned a value at the "level" of the classifier. This language should be changed because it is contrary to the facts that 1. instances are not at a "lower level" in some hierarchy inhabited by them along with classifiers. 2. instances are not getting the attribute value at all, static values do not "filter down to the objects from the classifier". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank Subject: RE: 6974 easy issue for next ballot. Date: Wed, 4 Aug 2004 06:02:58 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6974 easy issue for next ballot. Thread-Index: AcR5zB9HAWb+fdWaSvOs3oaANpDCvQAVW0qw From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" Cc: , X-OriginalArrivalTime: 04 Aug 2004 13:03:07.0355 (UTC) FILETIME=[62D162B0:01C47A23] Thomas: I wasn't aware of the standard form for presenting semantic variation points, I will revise the proposal to follow that format. Also, I will condense the last paragraph as you suggest. I am aware that I go on much too long in these writeups. wrt the "impossible" name, I agree that the name is unfortunate, no dictionary of English would define 'static' in a way that fits this UML usage, but I disagree that we must change it. Changing it is a nice-to-have that at this stage is not worth the effort. 1. 'static' appears in many parts of the spec. 2. No existing issue complains about it. 3. Everyone in OO is familiar with this peculiar meaning for 'static' it has become a technical term of art. So, my opposition to changing the name is pragmatic. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, 03 August, 2004 10:36 PM To: Karl Frank; Branislav Selic; Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. Karl, good. You have finally gotten to the point of clearly defining this as class variable vs. instance variable. In light of this, it would be good to change the name to something more meaningful. "static" is a bad name in C++ (derived from "static" in C, having to do with persistence), but it is an impossible name in UML. There is nothing "static" about such features. Secondly, you should indicate semantic variation points as customary in the specification. Introduce a new heading in italics "Semantic variation points" and then put a condensed version of your last paragraph after that. Cheers, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Tuesday, August 03, 2004 2:28 PM To: Branislav Selic; Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. A spellcheck fixed some errors in the attachment. Please discard any earlier version. ----------------------------------------------------- I have addressed the points made in discussion of my first attempt, in the attached upgraded resolution. Summary: Conrad's point is, 1. UML 2 semantics do not determine whether, in systems conforming to UML 2, specializations must inherit the static value along with the inherited static features of their parents. 2. Readers of the spec are likely to assume such inheritance of values was intended but left unstated. We must either explicitly say static feature brings its value along in inheritance (among other contexts where the "same" feature may be features of many classifiers), or explicitly recognize this as a semantic variation point to avoid the charge of ambiguity. We argue and conclude that UML 2 should allow inheritance of static values as a semantic variation point, further, that for compatibility with C#, we propose to change the language of the spec that currently describes the isStatic attribute as being used to say that an attribute is being assigned a value at the "level" of the classifier. This language should be changed because it is contrary to the facts that 1. instances are not at a "lower level" in some hierarchy inhabited by them along with classifiers. 2. instances are not getting the attribute value at all, static values do not "filter down to the objects from the classifier". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, 31 July, 2004 3:46 PM To: Thomas Weigert Cc: Karl Frank; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: 6974 easy issue for next ballot. I see how Karl is interpreting this, but it seems to me that the text could be a bit clearer. I have to admit that the case of subclasses sharing a single instance of a static feature did not occur to me until I saw it in Karl's resolution, I wonder if that is the reason why there is a 0..* mutliplicity from Feature to Classifier instead of 1 or 0..1 (or, at least, one of the reasons). There was some discussion on this point on the reflector not so long ago. Karl, rather than referring to it so indirectly, why not simply say that in cases of static features, the same instance is shared by all class and subclass instances -- or something along those lines. Cheers, Bran S "Thomas Weigert" 07/31/2004 01:55 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: 6974 easy issue for next ballot. Karl, I cannot understand what the new sentence is trying to say. Please make it clearer. Thanks, Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, July 31, 2004 10:17 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: 6974 easy issue for next ballot. Please see attached. - Karl Frank From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Draft of ballot 22 -- Please review Date: Thu, 5 Aug 2004 18:57:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Comments: 6974: Insert "Semantic Variation Point" in italics before the last paragraph. Delete the "; this is a semantic variation point" from the first sentence of the last paragraph. 7355: First, let me say that I think that whoever wrote the discussion did not appreciate the problem described (or the problem description was too unclear). So the resolution does not address the concern. Moreover, the resolution confuses more than it helps. Just below the text that is supposed to be inserted there is the explanation of the ParameterDirectionKind enumerated type, where each of the direction kinds are explained, but slightly different than in the proposed text. The explanation of the attribute Parameter.direction should reference the explanation of ParameterDirectionKind, not rephrase it and thus invite confusion. But primarily, the issue is not addressed: The specification uses the term "return result" at times to refer to the parameters with direction kind "return" and sometimes to any value returned (no matter on which parameter). This is a global spec issue, not something that a reformulation of Parameter.direction can help. Please pull that issue and rework. 7394: The discussion of this issue has not been completed, due to work on the action/activity issue. The resolution helps the "pull model" of data handling. However, there were two models discussed to ease access to data: the currently proposed one, and the one were we used an input action to be able to access connectable elements (variables, structural features, and parameters) without special actions. I am afraid that the people most concerned about this topic, Anders and Eran, have not been able to give it sufficient attention as it was unclear which model was being proposed (I also am surprised of finding this on this ballot). I would prefer if Eran and Anders explicitly looked at this issue and the alternative, before putting this on the ballot. Can we do this after Eran comes back from vacation? Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 05, 2004 2:56 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 22 -- Please review The attached document is for the Guinness Book of Records -- it is our largest ballot to date (in size, not in terms of number of issues). It is all of 124 pages long (and 600+ KB). All of these resolutions have been posted on the reflector, discussed, revised (many of them numerous times), and then reposted, so none of them should be surprising. All the big issues on this ballot (6279, 7135, 7319) have been soaking for at least 10 days (and some have been soaking for months). BTW, I have not included the convenience documents for issue 7319, since that would make the ballot even bigger. However, I sent those out earlier (08/02/2004 subject: Re: ,av,,ac, Activity/action resolutions for ballot 22) If you have any comments or suggestions, please send them in before noon tomorrow. Regards, Bran Subject: RE: Draft of ballot 22 -- Please review Date: Fri, 6 Aug 2004 06:09:38 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft of ballot 22 -- Please review Thread-Index: AcR7rvmfI9MptnepSFqzoNaRmhEagAABewlA From: "Karl Frank" To: "Branislav Selic" , "Thomas Weigert" Cc: , X-OriginalArrivalTime: 06 Aug 2004 13:09:49.0577 (UTC) FILETIME=[A7631790:01C47BB6] I already made the fix Thomas asked for in 6974, and that fix is in the updated version I sent to you for inclusion in the next ballot. on 7355, Thomas says that my proposed resolution does not understand the problem, which may well be, so I am agreeable to withdrawing that from ballot 22 to reexamine the issue. Also attached is 6630 an issue that has been widely discussed, and has been revised by me in a manner that seems to me to answer all the objections raised to earlier resolutions. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, 06 August, 2004 8:13 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review Karl and Conrad: These are your issues. Do you have a response to Thomas' concerns? Bran "Thomas Weigert" 08/05/2004 07:57 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Draft of ballot 22 -- Please review Comments: 6974: Insert "Semantic Variation Point" in italics before the last paragraph. Delete the "; this is a semantic variation point" from the first sentence of the last paragraph. 7355: First, let me say that I think that whoever wrote the discussion did not appreciate the problem described (or the problem description was too unclear). So the resolution does not address the concern. Moreover, the resolution confuses more than it helps. Just below the text that is supposed to be inserted there is the explanation of the ParameterDirectionKind enumerated type, where each of the direction kinds are explained, but slightly different than in the proposed text. The explanation of the attribute Parameter.direction should reference the explanation of ParameterDirectionKind, not rephrase it and thus invite confusion. But primarily, the issue is not addressed: The specification uses the term "return result" at times to refer to the parameters with direction kind "return" and sometimes to any value returned (no matter on which parameter). This is a global spec issue, not something that a reformulation of Parameter.direction can help. Please pull that issue and rework. 7394: The discussion of this issue has not been completed, due to work on the action/activity issue. The resolution helps the "pull model" of data handling. However, there were two models discussed to ease access to data: the currently proposed one, and the one were we used an input action to be able to access connectable elements (variables, structural features, and parameters) without special actions. I am afraid that the people most concerned about this topic, Anders and Eran, have not been able to give it sufficient attention as it was unclear which model was being proposed (I also am surprised of finding this on this ballot). I would prefer if Eran and Anders explicitly looked at this issue and the alternative, before putting this on the ballot. Can we do this after Eran comes back from vacation? Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 05, 2004 2:56 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Draft of ballot 22 -- Please review The attached document is for the Guinness Book of Records -- it is our largest ballot to date (in size, not in terms of number of issues). It is all of 124 pages long (and 600+ KB). All of these resolutions have been posted on the reflector, discussed, revised (many of them numerous times), and then reposted, so none of them should be surprising. All the big issues on this ballot (6279, 7135, 7319) have been soaking for at least 10 days (and some have been soaking for months). BTW, I have not included the convenience documents for issue 7319, since that would make the ballot even bigger. However, I sent those out earlier (08/02/2004 subject: Re: ,av,,ac, Activity/action resolutions for ballot 22) If you have any comments or suggestions, please send them in before noon tomorrow. Regards, Bran Subject: RE: Ballot 22 (Voting closes on Fri. Aug. 13) Date: Fri, 13 Aug 2004 14:13:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 22 (Voting closes on Fri. Aug. 13) Thread-Index: AcR8ATWVH50XWOulQAy/JV/BWom5XwFTqN9w From: "Pete Rivett" To: "Branislav Selic" , Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i7DIFglj020412 Adaptive votes YES on all resolution proposals contained in ballot 22, except for resolution 7394 which has been revoked, 6232 to which it votes NO, and 7319 to which it ABSTAINs. The problem with 6232 is, frankly, that IMHO the new language does not really clarify the spec which was the intention: and in fact causes additional problems of comprehensibility (at least to me). For example I really find the following hard going and having read it 4 times I still cannot determine what it is saying about association specialization: "Specialization is in contrast to Subsetting a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naïve but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." Also, though not mentioned specifically in the issue, I would expect such a discussion to include derived unions which are very closely related to subsetting and association generalization (in fact unions only work in conjunction with subsetting). And I would expect the resolution to replace the unsatisfactory statement on the same page (in Infra) "The interaction of association specialization with association end redefinition and subsetting is not defined." since that's really what the original issue was complaining about (and to say something is not defined is not really a variation point per se). Aside: this is probably another issue that needs raising, but reading 6974 it occurred to me that it still leaves open the scope for the static feature i.e. the runtime scope of the class owning the static property. This might typically be memory space of a runtime process, or a single database, or (in a MOF context) a MOF Extent. I see this as another semantic variation point. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 06, 2004 10:48 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Ballot 22 (Voting closes on Fri. Aug. 13) Don't forget to vote...Bran or values for the classifier and each descendant separately.