Issue 7223: Questions about DataTypes and generalization (uml2-rtf) Source: Red Hat (Mr. Randall M. Hauch, rhauch(at)redhat.com) Nature: Uncategorized Issue Severity: Summary: I have a few questions regarding section 7.12 entitled "Kernel - the DataTypes Diagram" in the final adopted Superstructure spec (03-08-02). DataType specializes Classifier, and as such it also inherits the ability to have generalization relationships with other Classifiers. Classifier has an additional operation 'maySpecializeType(Classifier):boolean' that is described/defined as follows: "The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints." (p. 63) with the OCL: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) DataType, nor its subtypes PrimitiveType and Enumeration, defines no additional constraints or additional operations. These additional constraints are executed/applied in the UML2 metamodel (rather than in a UML2 model), correct? If so, then this implies that a DataType may specialize another DataType, Classifier, Namespace, Type, etc., but that DataType may not specialize PrimitiveType or Enumeration. Please correct me if I'm interpreting this incorrectly. Consider an example with: * a PrimitiveType named "string" * a PrimitiveType named "float" * a DataType named "InternationalPrice" that specializes "float" and adds a new attribute/property called "currency" of type "string" The "InternationalPrice" DataType is conceptually a qualified type, meaning it is a float plus a qualifier of the value. Examples of instances would be {426.36, "US Dollars"}, {401.23, "Euros"}, {749.42, "Yen"}. If my interpretations of the Superstructure spec are correct, then this example cannot be modeled using UML2. And, in fact, the specification would actually allow me to create a new PrimitiveType named "double" that actually specializes my "InternationalPrice" DataType (since DataType is a supertype of PrimitiveType). My thought is that this is either a issue with the 'maySpecializeType' operation or it is an issue with DataType, PrimitiveType and Enumeration not being properly constrained. Resolution: Revised Text: Actions taken: April 6, 2004: received issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== From: Randall Hauch To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Questions about DataTypes and generalization Date: Tue, 6 Apr 2004 07:48:18 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) I have a few questions regarding section 7.12 entitled "Kernel - the DataTypes Diagram" in the final adopted Superstructure spec (03-08-02). DataType specializes Classifier, and as such it also inherits the ability to have generalization relationships with other Classifiers. Classifier has an additional operation 'maySpecializeType(Classifier):boolean' that is described/defined as follows: "The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints." (p. 63) with the OCL: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) DataType, nor its subtypes PrimitiveType and Enumeration, defines no additional constraints or additional operations. These additional constraints are executed/applied in the UML2 metamodel (rather than in a UML2 model), correct? If so, then this implies that a DataType may specialize another DataType, Classifier, Namespace, Type, etc., but that DataType may not specialize PrimitiveType or Enumeration. Please correct me if I'm interpreting this incorrectly. Consider an example with: * a PrimitiveType named "string" * a PrimitiveType named "float" * a DataType named "InternationalPrice" that specializes "float" and adds a new attribute/property called "currency" of type "string" The "InternationalPrice" DataType is conceptually a qualified type, meaning it is a float plus a qualifier of the value. Examples of instances would be {426.36, "US Dollars"}, {401.23, "Euros"}, {749.42, "Yen"}. If my interpretations of the Superstructure spec are correct, then this example cannot be modeled using UML2. And, in fact, the specification would actually allow me to create a new PrimitiveType named "double" that actually specializes my "InternationalPrice" DataType (since DataType is a supertype of PrimitiveType). My thought is that this is either a issue with the 'maySpecializeType' operation or it is an issue with DataType, PrimitiveType and Enumeration not being properly constrained. Thanks in advance, Randall M. Hauch VP Development, Chief Architect MetaMatrix, Inc. Subject: RE: Questions about DataTypes and generalization Date: Tue, 6 Apr 2004 11:21:32 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about DataTypes and generalization Thread-Index: AcQb5oka+c+JybsmTLSReVrCP3VD7wABA3vn From: "Karl Frank" To: "Randall Hauch" , , X-OriginalArrivalTime: 06 Apr 2004 15:21:34.0156 (UTC) FILETIME=[D87CA0C0:01C41BEA] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i36FNkAQ000868 Randall: Thanks for this. It really should be logged as an issue wrt the Classes chapter, which I handle, and so I have added issues@omg.org to the address line. Regards, Karl Frank Borland Software -----Original Message----- From: Randall Hauch [mailto:rhauch@metamatrix.com] Sent: Tue 4/6/2004 8:48 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Questions about DataTypes and generalization I have a few questions regarding section 7.12 entitled "Kernel - the DataTypes Diagram" in the final adopted Superstructure spec (03-08-02). DataType specializes Classifier, and as such it also inherits the ability to have generalization relationships with other Classifiers. Classifier has an additional operation 'maySpecializeType(Classifier):boolean' that is described/defined as follows: "The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints." (p. 63) with the OCL: Classifier::maySpecializeType(c : Classifier) : Boolean; maySpecializeType = self.oclIsKindOf(c.oclType) DataType, nor its subtypes PrimitiveType and Enumeration, defines no additional constraints or additional operations. These additional constraints are executed/applied in the UML2 metamodel (rather than in a UML2 model), correct? If so, then this implies that a DataType may specialize another DataType, Classifier, Namespace, Type, etc., but that DataType may not specialize PrimitiveType or Enumeration. Please correct me if I'm interpreting this incorrectly. Consider an example with: * a PrimitiveType named "string" * a PrimitiveType named "float" * a DataType named "InternationalPrice" that specializes "float" and adds a new attribute/property called "currency" of type "string" The "InternationalPrice" DataType is conceptually a qualified type, meaning it is a float plus a qualifier of the value. Examples of instances would be {426.36, "US Dollars"}, {401.23, "Euros"}, {749.42, "Yen"}. If my interpretations of the Superstructure spec are correct, then this example cannot be modeled using UML2. And, in fact, the specification would actually allow me to create a new PrimitiveType named "double" that actually specializes my "InternationalPrice" DataType (since DataType is a supertype of PrimitiveType). My thought is that this is either a issue with the 'maySpecializeType' operation or it is an issue with DataType, PrimitiveType and Enumeration not being properly constrained. Thanks in advance, Randall M. Hauch VP Development, Chief Architect MetaMatrix, Inc.