Issue 14449: PrimitiveType has missing constraints (uml2-rtf) Source: (Dr. Guus Ramackers, Guus.Ramackers(at)gmail.com) Nature: Revision Severity: Significant Summary: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. Resolution: Revised Text: Actions taken: October 5, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. Subject: RE: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 14:06:31 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue Thread-Index: AcpF1UIvP6FDeqOoRQmbUu0zAwv4NQBcJ/sA From: "Tim Weilkiens" To: "Juergen Boldt" , , The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 09:58:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue thread-index: AcpF1UIvP6FDeqOoRQmbUu0zAwv4NQBcJ/sAAAO4LvA= From: "Ed Seidewitz" To: "Tim Weilkiens" Cc: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 16:44:12 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue Thread-Index: AcpF1UIvP6FDeqOoRQmbUu0zAwv4NQBcJ/sAAAO4LvAAAVNXMA== From: "Tim Weilkiens" To: "Ed Seidewitz" Cc: Ed, I agree that your abstract syntax proposal is much clearer, in particular for Enumerations. I think it makes no sense for Enumerations to have attributes. With "well chosen" I meant that the author had something in mind, i.e. that he differentiates between relevant and no relevant substructures. Otherwise he had chosen the statement "without any attributes". For me a complex number is still a primitive type. However I don't see any way to give a formal and clear constraint which defines the difference between relevant and non-relevant substructures. To increase the precision of UML I would support your proposal. Tim -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, October 07, 2009 3:59 PM To: Tim Weilkiens Cc: uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 Date: Wed, 07 Oct 2009 16:20:14 +0100 From: Guus Ramackers Reply-To: Guus.Ramackers@oracle.com User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Ed Seidewitz CC: Tim Weilkiens , uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4ACCB1E6.01F6:SCFMA4539814,ss=1,fgs=0 Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: Re: issue 14449 -- UML 2 RTF issue To: Guus.Ramackers@oracle.com Cc: Ed Seidewitz , Tim Weilkiens , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 12:14:13 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 12:14:15 Please rember that some Enumerations have operations, like Package UML::Classes::Kernel Enumeration VisibilityKind Operations + bestVisibility (vis : VisibilityKind [0..*]) : VisibilityKind [1..1] {query} The query bestVisibility() examines a set of VisibilityKinds, and returns public as the preferred visibility. precondition (): pre: not vis->includes(#protected) and not vis->includes(#package) 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 Guus Ramackers Guus Ramackers 10/07/2009 11:20 AM Please respond to Guus.Ramackers@oracle.com To Ed Seidewitz cc Tim Weilkiens , uml2-rtf@omg.org Subject Re: issue 14449 -- UML 2 RTF issue Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 pic14629.gif To: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue X-KeepSent: AFAA37E5:E49820A8-85257648:005D5220; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V851_08092009[dod_197302] August 12, 2009 From: Jim Amsden Date: Wed, 7 Oct 2009 13:03:32 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V851_08302009|August 30, 2009) at 10/07/2009 11:03:33, Serialize complete at 10/07/2009 11:03:33 DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I canâ..t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what â..relevant substructureâ. means. And I would tend to agree with Guus.to me, attribuutes would seem to be â..substructureâ.. The point really is the need to be more precise about what we mean by â..primitive typeâ.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (â..algebra and operations defined outside of UMLâ.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type mmodel of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldnâ..t have any attributes. Instead, it might, for example, have â..Imâ. and â..Reâ. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, StraÃ.enbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Date: Wed, 07 Oct 2009 18:07:49 +0100 From: Guus Ramackers Reply-To: Guus.Ramackers@oracle.com User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Maged Elaasar CC: Ed Seidewitz , Tim Weilkiens , uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4ACCCAF1.0135:SCFMA4539814,ss=1,fgs=0 Maged, These are operations to define OCL constraints. The operations referred to in the issue are Operations defined by the UML end-user (viz. that would show up in the operations compartment). Thanks, guus Maged Elaasar wrote: Please rember that some Enumerations have operations, like Package UML::Classes::Kernel Enumeration VisibilityKind Operations + bestVisibility (vis : VisibilityKind [0..*]) : VisibilityKind [1..1] {query} The query bestVisibility() examines a set of VisibilityKinds, and returns public as the preferred visibility. precondition (): pre: not vis->includes(#protected) and not vis->includes(#package) 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 Guus Ramackers Guus Ramackers 10/07/2009 11:20 AM Please respond to Guus.Ramackers@oracle.com To Ed Seidewitz cc Tim Weilkiens , uml2-rtf@omg.org Subject Re: issue 14449 -- UML 2 RTF issue Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Date: Wed, 07 Oct 2009 18:11:57 +0100 From: Guus Ramackers Reply-To: Guus.Ramackers@oracle.com User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Jim Amsden CC: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4ACCCC4D.000A:SCFMA4539814,ss=1,fgs=0 Jim, I think this is consistent (identical except for the names of the metaclasses) with Ed's suggestion. Thanks, Guus Jim Amsden wrote: DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: Re: issue 14449 -- UML 2 RTF issue To: Guus.Ramackers@oracle.com Cc: Ed Seidewitz , Tim Weilkiens , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Wed, 7 Oct 2009 13:29:03 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/07/2009 13:29:05 Right, so in this case, the user who wrote a constraint felt the need to define an operation to call from the constraint, which was only possible since Enumerations had an operation collection. Maged Guus Ramackers Guus Ramackers 10/07/2009 01:07 PM Please respond to Guus.Ramackers@oracle.com To Maged Elaasar/Ottawa/IBM@IBMCA cc Ed Seidewitz , Tim Weilkiens , uml2-rtf@omg.org Subject Re: issue 14449 -- UML 2 RTF issue Maged, These are operations to define OCL constraints. The operations referred to in the issue are Operations defined by the UML end-user (viz. that would show up in the operations compartment). Thanks, guus Maged Elaasar wrote: Please rember that some Enumerations have operations, like Package UML::Classes::Kernel Enumeration VisibilityKind Operations + bestVisibility (vis : VisibilityKind [0..*]) : VisibilityKind [1..1] {query} The query bestVisibility() examines a set of VisibilityKinds, and returns public as the preferred visibility. precondition (): pre: not vis->includes(#protected) and not vis->includes(#package) 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 Guus Ramackers Guus Ramackers 10/07/2009 11:20 AM Please respond to Guus.Ramackers@oracle.com To Ed Seidewitz cc Tim Weilkiens , uml2-rtf@omg.org Subject Re: issue 14449 -- UML 2 RTF issue Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 pic15318.gif Subject: RE: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 14:06:07 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue thread-index: AcpHabOknRPoMSBxQhC+4TRScggFpgADO7dA From: "Ed Seidewitz" To: "Maged Elaasar" , Cc: "Tim Weilkiens" , Maged . This is a pretty silly operation that is seemingly only attached to VisibilityKind as an operation because the only way behaviors are defined in the spec is by attaching them to something as operations. In any case, the spec doesn.t even seem to use this operation anyplace (at least not that I could find with a search)! So it could be removed. I really don.t think that having operations on enumerations is that useful in the end. However, my point really is that owned attributes and/or operations should be included on various kinds of data types because we think they should be, not because they happen to be accidentally inherited from some superclass. DataType is an abstract superclass without owned attributes and operations, then we can easily have PrimitiveType with neither attributes or operations, Enumeration with operations (if we want) but no attributes and StructuredDataType with both. (Note also that there is a general issue with operations on data types at all, in that data types are not behaviored classifiers, so such operations can never be given methods. However, they can be given declarative specifications, such as through preconditions and postconditions, which I guess can be useful.) -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Wednesday, October 07, 2009 12:14 PM To: Guus.Ramackers@oracle.com Cc: Ed Seidewitz; Tim Weilkiens; uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue Please rember that some Enumerations have operations, like Package UML::Classes::Kernel Enumeration VisibilityKind Operations + bestVisibility (vis : VisibilityKind [0..*]) : VisibilityKind [1..1] {query} The query bestVisibility() examines a set of VisibilityKinds, and returns public as the preferred visibility. precondition (): pre: not vis->includes(#protected) and not vis->includes(#package) 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 Guus Ramackers Guus Ramackers 10/07/2009 11:20 AM Please respond to Guus.Ramackers@oracle.com To Ed Seidewitz cc Tim Weilkiens , uml2-rtf@omg.org Subject Re: issue 14449 -- UML 2 RTF issue Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 From: Salman Qadri To: Jim Amsden , "uml2-rtf@omg.org" Date: Wed, 7 Oct 2009 14:30:34 -0400 Subject: RE: issue 14449 -- UML 2 RTF issue Thread-Topic: issue 14449 -- UML 2 RTF issue Thread-Index: AcpHcG9WDOR2gUQ8Ro2iYj7n2lfK6wAC7Elg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US The solution is to say that PrimitiveType and Enumeration redefine ownedAttribute to 0..0, and PrimitiveType also redefined ownedOperation to 0..0. Problem solved! From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, October 07, 2009 1:04 PM To: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substruccture.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type..it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: RE: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 14:45:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue thread-index: AcpHcG9WDOR2gUQ8Ro2iYj7n2lfK6wAC7ElgAABk31A= From: "Ed Seidewitz" To: "Salman Qadri" Cc: Redefining inherited properties to make them go away is a classic example of a poor object-oriented generalization hierarchy! Why have them inherited in the first place if you don.t want them? Note that there are already general (union) properties for getting any features of a classifier, the only issue here is whether primitive types and enumerations should own attributes and operations. If not, then it is much better practice . and much clearer . for them to not have ownedAttribute and ownedOperation properties at all, rather than for them to inherit such properties and then require them to be empty. And that was my original point: the very reason that Guus needed to submit an issue asking for constraints (or redefinitions) like you suggest was that the data type abstract syntax model was poor in the first place. -- Ed -------------------------------------------------------------------------------- From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: Wednesday, October 07, 2009 2:31 PM To: Jim Amsden; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The solution is to say that PrimitiveType and Enumeration redefine ownedAttribute to 0..0, and PrimitiveType also redefined ownedOperation to 0..0. Problem solved! From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, October 07, 2009 1:04 PM To: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Wed, 7 Oct 2009 14:53:56 -0400 Subject: RE: issue 14449 -- UML 2 RTF issue Thread-Topic: issue 14449 -- UML 2 RTF issue Thread-Index: AcpHcG9WDOR2gUQ8Ro2iYj7n2lfK6wAC7ElgAABk31AAAG1NEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n97IqTQG007577 Ed, > Redefining inherited properties to make them go away is a > classic example of a poor object-oriented generalization > hierarchy! But it can make a good taxonomy (eg, bacholars have no wives, etc). Conrad From: Salman Qadri To: Ed Seidewitz CC: "uml2-rtf@omg.org" Date: Wed, 7 Oct 2009 16:16:11 -0400 Subject: RE: issue 14449 -- UML 2 RTF issue Thread-Topic: issue 14449 -- UML 2 RTF issue Thread-Index: AcpHcG9WDOR2gUQ8Ro2iYj7n2lfK6wAC7ElgAABk31AAAtRMwA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US If that were true, then it is also bad design if you ever have to redefinition from 0..* to 0..1 or 1..1. What difference is there in going from 0..* to 0..0 vs going to 0..1? More importantly, redefinition to 0..0 still satisfies the constraints of redefinition and specialization, in the same way a redefinition to 0..1 or 1..1 would from a 0..*. This does not mean that we .inherit such properties and then require them to be empty.. That is the wrong view. The more correct view is that, when the object is viewed as the more general type, the contract of the property in the general type that was redefined away MUST still hold. Whether this is the correct answer for this case or not is a different issue, but I strongly feel that redefining to 0..0 should be a valid thing to do. Salman From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, October 07, 2009 2:45 PM To: Salman Qadri Cc: uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue Redefining inherited properties to make them go away is a classic example of a poor object-oriented generalization hierarchy! Why have them inherited in the first place if you don.t want them? Note that there are already general (union) properties for getting any features of a classifier, the only issue here is whether primitive types and enumerations should own attributes and operations. If not, then it is much better practice . and much clearer . for them to not have ownedAttribute and ownedOperation properties at all, rather than for them to inherit such properties and then require them to be empty. And that was my original point: the very reason that Guus needed to submit an issue asking for constraints (or redefinitions) like you suggest was that the data type abstract syntax model was poor in the first place. -- Ed -------------------------------------------------------------------------------- From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: Wednesday, October 07, 2009 2:31 PM To: Jim Amsden; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The solution is to say that PrimitiveType and Enumeration redefine ownedAttribute to 0..0, and PrimitiveType also redefined ownedOperation to 0..0. Problem solved! From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, October 07, 2009 1:04 PM To: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Subject: RE: issue 14449 -- UML 2 RTF issue Date: Wed, 7 Oct 2009 16:42:19 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 14449 -- UML 2 RTF issue thread-index: AcpHcG9WDOR2gUQ8Ro2iYj7n2lfK6wAC7ElgAABk31AAAtRMwAABIQPQ From: "Ed Seidewitz" To: "Salman Qadri" Cc: Salman . It isn.t that redefinition to 0..0 is invalid, it is just that, in this case, I feel that it is a workaround for a poor model. The problem is that, in this specific case, the contract of the property in the general type just doesn.t make sense at all for certain subtypes. For example, the ownedAttribute property is supposed to hold the owned attributes of the data type. But if a primitive type by definition does not have attributes, then a redefinition to 0..0 is exactly saying that a data type owns attributes, but that a primitive type is required not to own any. In my opinion, this is just poor modeling. Note that I don.t have anything against the Classifier::attribute derived union property that all kinds of data type would still inherit. It is fine (and very convenient) to be able to ask, for any classifier, what attributes it has . and, in the case of a primitive type, this will just always be empty. What I object to is modeling the generalization that all data types own attributes when, in fact, neither primitive types nor enumerations ever should. It is much more consistent with the way that this is usually done in the rest of the abstract syntax model (and, in my opinion, better modeling practice) for them just not to have an ownedAttribute property at all. -- Ed -------------------------------------------------------------------------------- From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: Wednesday, October 07, 2009 4:16 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue If that were true, then it is also bad design if you ever have to redefinition from 0..* to 0..1 or 1..1. What difference is there in going from 0..* to 0..0 vs going to 0..1? More importantly, redefinition to 0..0 still satisfies the constraints of redefinition and specialization, in the same way a redefinition to 0..1 or 1..1 would from a 0..*. This does not mean that we .inherit such properties and then require them to be empty.. That is the wrong view. The more correct view is that, when the object is viewed as the more general type, the contract of the property in the general type that was redefined away MUST still hold. Whether this is the correct answer for this case or not is a different issue, but I strongly feel that redefining to 0..0 should be a valid thing to do. Salman From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Wednesday, October 07, 2009 2:45 PM To: Salman Qadri Cc: uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue Redefining inherited properties to make them go away is a classic example of a poor object-oriented generalization hierarchy! Why have them inherited in the first place if you don.t want them? Note that there are already general (union) properties for getting any features of a classifier, the only issue here is whether primitive types and enumerations should own attributes and operations. If not, then it is much better practice . and much clearer . for them to not have ownedAttribute and ownedOperation properties at all, rather than for them to inherit such properties and then require them to be empty. And that was my original point: the very reason that Guus needed to submit an issue asking for constraints (or redefinitions) like you suggest was that the data type abstract syntax model was poor in the first place. -- Ed -------------------------------------------------------------------------------- From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: Wednesday, October 07, 2009 2:31 PM To: Jim Amsden; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The solution is to say that PrimitiveType and Enumeration redefine ownedAttribute to 0..0, and PrimitiveType also redefined ownedOperation to 0..0. Problem solved! From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Wednesday, October 07, 2009 1:04 PM To: uml2-rtf@omg.org Subject: Re: issue 14449 -- UML 2 RTF issue DataType is used to model value or data transfer objects that don't have identity. The problem is unintended inheritance. PrimitiveType is also a kind of value object, but one that has no specified structure. So we're either missing an common abstract metaclass (say ValueObject) or a means of defining facets or multi-classification.l Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Guus Ramackers To: Ed Seidewitz Cc: Tim Weilkiens , uml2-rtf@omg.org Date: 10/07/2009 11:28 AM Subject: Re: issue 14449 -- UML 2 RTF issue -------------------------------------------------------------------------------- Ed, > have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. That makes sense to me. Thanks, Guus Ed Seidewitz wrote: Tim . Well, I can.t agree that the wording is well chosen. Indeed, I think it is another case of the spec being (unintentionally) ambiguous and unclear. This is evidenced by the very case that you and Guus interpret differently what .relevant substructure. means. And I would tend to agree with Guus.to me, attributes would seem to be .substructure.. The point really is the need to be more precise about what we mean by .primitive type.. The spec seems to be trying to say that a primitive type is one that is declared to exist in UML but whose properties are otherwise not modeled using UML (.algebra and operations defined outside of UML.). In this case, a UML model of ComplexNumber with attributes for real and imaginary parts would not be a primitive type.it would be a structured UML data type model of complex numbers, and it could have operations and functions defined on it as behaviors also modeled using UML. On the other hand, one could define ComplexNumber as a true primitive type, in which case it wouldn.t have any attributes. Instead, it might, for example, have .Im. and .Re. operations defined on it as part of its algebra outside of UML, which could be referenced via, e.g., opaque functions in UML (just like primitive operations for integer, etc.). The root problem, in my mind, is that, in the abstract syntax, PrimitiveType is a specialization of the concrete superclass DataType, the later of which has owned attributes and operations that are inherited by PrimitiveType. Note that this also happens for Enumeration, and I am even less sure what it means for an Enumeration type to have attributes! A much better abstract syntax model would have DataType be abstract with three specializations, PrimitiveType, Enumeration and StructuredDataType, and only StructuredDataType would have owned attributes and operations. (Of course, you still could disagree with the exclusion of structure from PrimitiveType, but at least the model would be clear!) -- Ed -------------------------------------------------------------------------------- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, October 07, 2009 8:07 AM To: Juergen Boldt; issues@omg.org; uml2-rtf@omg.org Subject: RE: issue 14449 -- UML 2 RTF issue The specification states: "without any relevant substructure". I think the wording is well choosen and attributes are allowed, e.g. ComplexNumber would be a Primitive type with two attributes for the real and imaginary number. What about a constraint that only allows PrimitiveTypes as types of attributes of PrimitiveTypes? Tim ----------------------------------------------------------------- Tim Weilkiens Head of Systems Engineering OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Monday, October 05, 2009 6:00 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 14449 -- UML 2 RTF issue From: webmaster@omg.org Date: 05 Oct 2009 09:12:39 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Guus Ramackers Company: Oracle mailFrom: guus.ramackers@oracle.com Notification: Yes Specification: UML Section: 7.3.43 FormalNumber: ptc/2008-05-05 Version: 2.2 RevisionDate: may 2008 Page: 124 Title: PrimitiveType has missing constraints Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: The UML specification text for PrimitiveType states that it has no operationsnor attributes: "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically." However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations. Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType. The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification. 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 -- _______________________________________________________________ Guus Ramackers Product Manager Web Services & UML Modeling, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification.