Issue 6233: UML 2 Super/Compliance points/confusing and redundant (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain: There is no facility provided to indicate which particular compliance points are assumed in a given model -- hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard. The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java. Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant. This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?). Resolution: This is a duplicate of issue 6248. Revised Text: Actions taken: September 7, 2003: received issue December 2, 2004: closed issue Discussion: End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/Compliance points/confusing and redundant X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 15:00:52 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 15:00:55, Serialize complete at 09/07/2003 15:00:55 The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain: There is no facility provided to indicate which particular compliance points are assumed in a given model -- hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard. The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java. Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant. This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?). Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 Oct 2003 12:41:07 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: ,gi, 6233: Proposal for compliance Karl Frank wrote: Joaquin, can you please comment on the highlighted bit below and my questions on them? -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: Wednesday, October 22, 2003 11:39 AM To: UML Superstructure FTF ... 2. interchange a tool is model interchange compliant if it interchanges all the model elements for which it claims compliance So a precondition for using this test is that each tool that claims compliance will be delivered with a list of all the concrete classes that descend from Kernel::Element in the Superstructure spec for which it claims support. Yes. I'd say: will be delivered with a compliance statement that states the compliance points to which it claims compliance (and from which a list of concrete classes which it necessarily must then support can be inferred). The point: I hope the compliance statements will list compliance points, not meta-model classses. But: yes. I am not implying that this is impossible or problematic, I am pointing out that a precondition for compliance testing is that each vendor shall be required to provide such a list, and you had not made that explicit. I see. It should be explicit. Thanks. I believe (correct me if i'm wrong) that the list can be arrived at by looking at the packages that correspond to a particular compliance point. Compliance point>list of packages>list of classes>list of concrete classes>list of everything connected with those concrete classes, that must also be interchanged. I hope the progression there will be entirely determined by the compliance point specification. Reply-To: Joaquin Miller X-Sender: joaquin%joaquin.net@secure.cnchost.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 Oct 2003 08:39:12 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: Proposal for compliance A rough first approximation to (actually, an overestimate of) the number of distinct compliance points is: x to the power y x the number of columns in the compliance matrix y the number of rows Proposals for reducing the number of compliance points: 1. partial compliance eliminate x is reduced by one at a stroke of the pen, reduces the number of different UMLs by one quarter. 2. interchange a tool is model interchange compliant if it interchanges all the model elements for which it claims compliance else that tool is not interchange compliant. x is reduced by one y is increased by one reduces the number of remaining different UMLs by almost a third 3. diagram interchange a tool is diagram compliant if if it interchanges all the model elements for which it claims compliance and also interchanges diagrams of all model elements for which it claims compliance else it is not diagram interchange compliant. y is increased by one doubles the number of remaining different UMLs (but this would have happened anyway. yes, this may be an item for the diagram interchange FTF, but it is, i believe, for joint consideration.) I'll follow this in a day or two with some more proposals, for further reducing the number of compliance possibilities. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Subject: RE: Proposal for compliance Date: Wed, 22 Oct 2003 15:23:28 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Proposal for compliance Thread-index: AcOYssqdYZzhhCl8TdiiZKR3GB9+aQAHSg1A From: "Karl Frank" To: "Joaquin Miller" , "UML Superstructure FTF" X-OriginalArrivalTime: 22 Oct 2003 19:23:29.0518 (UTC) FILETIME=[F954D8E0:01C398D1] Joaquin, can you please comment on the highlighted bit below and my questions on them? - Karl -----Original Message----- From: Joaquin Miller [mailto:joaquin@joaquin.net] Sent: Wednesday, October 22, 2003 11:39 AM To: UML Superstructure FTF Subject: Proposal for compliance A rough first approximation to (actually, an overestimate of) the number of distinct compliance points is: x to the power y x the number of columns in the compliance matrix y the number of rows Proposals for reducing the number of compliance points: 1. partial compliance eliminate x is reduced by one at a stroke of the pen, reduces the number of different UMLs by one quarter. 2. interchange a tool is model interchange compliant if it interchanges all the model elements for which it claims compliance So a precondition for using this test is that each tool that claims compliance will be delivered with a list of all the concrete classes that descend from Kernel::Element in the Superstructure spec for which it claims support. I am not implying that this is impossible or problematic, I am pointing out that a precondition for compliance testing is that each vendor shall be required to provide such a list, and you had not made that explicit. - Karl else that tool is not interchange compliant. x is reduced by one y is increased by one reduces the number of remaining different UMLs by almost a third 3. diagram interchange a tool is diagram compliant if if it interchanges all the model elements for which it claims compliance and also interchanges diagrams of all model elements for which it claims compliance else it is not diagram interchange compliant. y is increased by one doubles the number of remaining different UMLs (but this would have happened anyway. yes, this may be an item for the diagram interchange FTF, but it is, i believe, for joint consideration.) I'll follow this in a day or two with some more proposals, for further reducing the number of compliance possibilities. Cordially, Joaquin PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 OMG Issue No: 6233 Title: UML 2 Super/Compliance points/confusing and redundant Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain: There is no facility provided to indicate which particular compliance points are assumed in a given model -- hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard. The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java. Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant. This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?). Discussion: This is a duplicate of issue 6248. Disposition: Duplicate e-mail: bselic@ca.ibm.com