Issue 12795: Special Types violate UML Generalization Semantics (ocl2-rtf) Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody) Nature: Clarification Severity: Minor Summary: Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier. Resolution: Revised Text: Actions taken: August 24, 2008: received issue Discussion: The issue requires some further analysis. Deferred for timing reasons. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 24 Aug 2008 11:27:06 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Christian W. Damus Company: Zeligsoft, Inc. mailFrom: cdamus@zeligsoft.com Notification: No Specification: OCL Section: 11.2.1, 11.2.3, 11.2.4 FormalNumber: formal/06-05-01 Version: 2.0 RevisionDate: 06-05-01 Page: 137, 138 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1 Description Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier. X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPvDj0rUnw4R/2dsb2JhbADSdIQaBQ Date: Sat, 22 Aug 2009 18:11:54 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: ocl2-rtf@omg.org Subject: Re: Issue No: 12795 Special Types violate UML Generalization X-Plusnet-Relay: e958e49c1554a18f65ebe3844c09f6e9 Hi The elimination of OclType in the resolution of Issue 6532 in favour of a 'powertype' provides a simplifying solution for this. It is currently confusing for Classifier to appear at M2 as the abstract supertype of OCL language types and again at M1 as abstract supertype of user types. These two usages are unnecessarily distinct; only one of them conforms to OclAny, but since UML does not provide OclAny, it is not possible to provide a UML model that relates the user types to the OCL standard library type system. There is no longer any need for OclAny. Let OclAny be a deprecated synonym for Classifier, so that OclAny/Classifier is indeed the UML root of all user and predefined types. It is then only necessary to define OclVoid with the constraint that it generalises all types. Then OclInvalid generalises OclVoid and all types have a valid UML generalisation hierarchy. Methods such as OclAny::oclIsNew do not need to be defined in UML. The Issue 6532 resolution migrating OclAny::allInstances() to Classifier::allInstances() can be followed for the remaining OclAny operations. ?? There may be yet further simplifications to be made by this increased alighnment with the UML type system. Potentially all the irregularity in A.2.7 vanishes. ?? ------------------ If this seems reasonable, I'll write it up as a resolution. Regards Ed Willink From: "Brucker, Achim" To: "'Ed Willink'" , "'ocl2-rtf@omg.org'" Date: Sun, 23 Aug 2009 22:15:04 +0200 Subject: RE: Issue No: 12795 Special Types violate UML Generalization Thread-Topic: Issue No: 12795 Special Types violate UML Generalization Thread-Index: AcojS81X2Z2OhndoSJqWsV7plddJNQA4SzSw Accept-Language: en-US, de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE X-Scanner: Virus Scanner virwal02 X-SAP: out X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n7NK9LMX022851 Hi, sorry, I did not follow all of your recent mails (in fact, du to a lot of other work, they are still on my "need to be read" list). With respect to OclInvalid/OclAny/OclVoid there is already severe problems. This situation, not only with respect to the UML alignment but also with respect to the (formal) semantics of OCL should be improved in the next version. IMHO, this requires a careful planning. As it is quite hard to judge the effects of these changes to the semantics of OCL just by looking at the different "bug fixes", I would highly appreciate a brief summary of the changes your are proposing in this area. Thanks a lot for your work! Achim > -----Original Message----- > From: Ed Willink [mailto:ed@willink.me.uk] > Sent: Saturday, August 22, 2009 7:12 PM > To: ocl2-rtf@omg.org > Subject: Re: Issue No: 12795 Special Types violate UML Generalization > > Hi > > The elimination of OclType in the resolution of Issue 6532 in > favour of > a 'powertype' provides a simplifying solution for this. > > It is currently confusing for Classifier to appear at M2 as > the abstract > supertype of OCL language types and again at M1 as abstract > supertype of > user types. These two usages are unnecessarily distinct; only one of > them conforms to OclAny, but since UML does not provide OclAny, it is > not possible to provide a UML model that relates the user > types to the > OCL standard library type system. > > There is no longer any need for OclAny. > > Let OclAny be a deprecated synonym for Classifier, so that > OclAny/Classifier is indeed the UML root of all user and predefined > types. It is then only necessary to define OclVoid with the > constraint > that it generalises all types. Then OclInvalid generalises > OclVoid and > all types have a valid UML generalisation hierarchy. > > Methods such as OclAny::oclIsNew do not need to be defined in > UML. The > Issue 6532 resolution migrating OclAny::allInstances() to > Classifier::allInstances() can be followed for the remaining OclAny > operations. > > ?? There may be yet further simplifications to be made by > this increased > alighnment with the UML type system. Potentially all the > irregularity in > A.2.7 vanishes. ?? > > ------------------ > > If this seems reasonable, I'll write it up as a resolution. > > Regards > > Ed Willink > > > > > X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACfSkUrUnw6S/2dsb2JhbADSQIQaBYFR Date: Mon, 24 Aug 2009 07:39:10 +0100 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Brucker, Achim" CC: "'ocl2-rtf@omg.org'" Subject: Re: Issue No: 12795 Special Types violate UML Generalization X-Plusnet-Relay: bd2956f9da817ca770175a1effbda414 Hi Achim I submitted five Issues over the weekend, which should make it through to this list shortly. The outer email in each case contains a very short teaser, then the discussion of the attachment contains more detail. One on "OCL 2.0, 2.1 inconsistent definition of null and invalid" might address all the null/invalid problems. The "OCL 2.1 Issue 12948 'Making OclAny denote any object' disposition has very unfortunate corrolaries" suggests that the proposed change for OclAny is untenable and offers some alternatives. Since submitting that, I've started to be concerned that automatic object to collection conversions may also be a source of ambiguity once collections are also objects. The issues should make it clear that I'm not proposing any changes to existing OCL, just endeavouring to get the specification to say what it means without contradiction; this inevitably means a change to one of the contradictory statements. This flurry of problems arose from the one enhancement I am trying to write up in resolution form on introduction of a transitiveClosure() iterator, this caused me to really read all the relevant parts, find problems, try to resolve them and find more problems ... I thoroughly agree that there needs to be careful planning. I'm not sure that the OCL 2.1 changes have really been considered. Many of the minor changes have been implemented by vendors as unavoidable ambiguity resolutions. The major change for OclAny needs prototyping and fully specifying in one go rather than as a halfway house that will require a further clarification in the next version. Regards Ed Willink Brucker, Achim wrote: Hi, sorry, I did not follow all of your recent mails (in fact, du to a lot of other work, they are still on my "need to be read" list). With respect to OclInvalid/OclAny/OclVoid there is already severe problems. This situation, not only with respect to the UML alignment but also with respect to the (formal) semantics of OCL should be improved in the next version. IMHO, this requires a careful planning. As it is quite hard to judge the effects of these changes to the semantics of OCL just by looking at the different "bug fixes", I would highly appreciate a brief summary of the changes your are proposing in this area. Thanks a lot for your work! Achim -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: Saturday, August 22, 2009 7:12 PM To: ocl2-rtf@omg.org Subject: Re: Issue No: 12795 Special Types violate UML Generalization Hi The elimination of OclType in the resolution of Issue 6532 in favour of a 'powertype' provides a simplifying solution for this. It is currently confusing for Classifier to appear at M2 as the abstract supertype of OCL language types and again at M1 as abstract supertype of user types. These two usages are unnecessarily distinct; only one of them conforms to OclAny, but since UML does not provide OclAny, it is not possible to provide a UML model that relates the user types to the OCL standard library type system. There is no longer any need for OclAny. Let OclAny be a deprecated synonym for Classifier, so that OclAny/Classifier is indeed the UML root of all user and predefined types. It is then only necessary to define OclVoid with the constraint that it generalises all types. Then OclInvalid generalises OclVoid and all types have a valid UML generalisation hierarchy. Methods such as OclAny::oclIsNew do not need to be defined in UML. The Issue 6532 resolution migrating OclAny::allInstances() to Classifier::allInstances() can be followed for the remaining OclAny operations. ?? There may be yet further simplifications to be made by this increased alighnment with the UML type system. Potentially all the irregularity in A.2.7 vanishes. ?? ------------------ If this seems reasonable, I'll write it up as a resolution. Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAFDlGUvUnw4S/2dsb2JhbACZD7t/hDME Date: Sat, 05 Dec 2009 12:49:00 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: ocl2-rtf@omg.org Subject: Re: Issue No: 12795 Special Types violate UML Generalization X-Plusnet-Relay: 64af82978783f1ce646e74e1302d9ba8 Hi Please ignore my previous contribution to this thread suggesting that OclAny be a synonym for Classifier. This was a very foolish idea confusing M1 and M2. Classifier exists at M2; only Classifier instances at M1. The original submission highlighted the problem that OclAny as an instance of AnyType (which is a specialized Classifier) cannot be the general of instances of Class (which is a specialized Classifier but not a specialized AnyType). A UML revision of Classifier::maySpecializeType is needed to legalize this. It is not obvious how the revision would work. The problem can be shifted sideways by eliminating AnyType and defining OclAny as a/the special instance of Classifier. A UML revision to make Classifier non-abstract is needed to legalize this. This change is much easier to understand. Do we want to request this change to UML? Do we want to eliminate AnyType anyway? It seem unlikely that anyone will notice a difference. Regards X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEEAFDlGUvUnw4S/2dsb2JhbACZD7t/hDME Date: Sat, 05 Dec 2009 12:49:00 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: ocl2-rtf@omg.org Subject: Re: Issue No: 12795 Special Types violate UML Generalization X-Plusnet-Relay: 64af82978783f1ce646e74e1302d9ba8 Hi Please ignore my previous contribution to this thread suggesting that OclAny be a synonym for Classifier. This was a very foolish idea confusing M1 and M2. Classifier exists at M2; only Classifier instances at M1. The original submission highlighted the problem that OclAny as an instance of AnyType (which is a specialized Classifier) cannot be the general of instances of Class (which is a specialized Classifier but not a specialized AnyType). A UML revision of Classifier::maySpecializeType is needed to legalize this. It is not obvious how the revision would work. The problem can be shifted sideways by eliminating AnyType and defining OclAny as a/the special instance of Classifier. A UML revision to make Classifier non-abstract is needed to legalize this. This change is much easier to understand. Do we want to request this change to UML? Do we want to eliminate AnyType anyway? It seem unlikely that anyone will notice a difference. Regards Ed Willink