Issue 10825: ownership of association ends does not matter for traversal in OCL (ocl2-rtf) Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com) Nature: Clarification Severity: Minor Summary: during work on the definition of the UML Profile for CIM (an activity performed jointly between OMG and DMTF), we recently found the following issue with OCL 2. Please record this issue officially and let me know the issue number for it. Issue: No explicit statement that ownership of association ends does not matter for traversal in OCL Nature: Clarification Severity: Minor Summary: The UML Superstructure spec 2.1.1 defines in section 6.5.2 "Diagram Format" that any meta-association has two ends, regardless of whether the ends are owned by the association or the associated classifiers. However, the Superstructure spec only describes those association ends that are owned by the associated classifiers. Furthermore, a major OCL engine (from Eclipse) does not currently support meta-association traversal in OCL towards ends owned by the meta-association. This may leave the impression to some readers that OCL would only support meta-association traversal in the direction of ends owned by the associated classifiers. I understand that the intention is in OCL to support traversal of meta-associations in any direction, regardless of whether the target end is owned by the association or the associated classifier. It would be helpful to state that explicitly in the OCL specification. Resolution: Revised Text: In Section 7.5.3 AssociationEnds and Navigation, add a subsection following the “Missing AssocationEnd Names” as follows: Ends Owned by Associations In a UML association, an end may be owned by the Classifier at that end, or by the association, itself. The ownership of the end is not significant to OCL. In either case, the association end is considered as a property of the Classifier and can be navigated from that end to the other. Note that navigation of association-owned ends is an optional compliance point for OCL implementations, as per Table 2.1. Actions taken: March 17, 2007: received issue October 16, 2009: closed issue Discussion: The intent for OCL to support navigation of association-owned ends is retained, with clarification of the implication on implementations. End of Annotations:===== Subject: Feedback on issues from 8663 to 12485 Date: Thu, 9 Oct 2008 16:04:37 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on issues from 8663 to 12485 thread-index: AckqF/bHnUBqNPt8Ry6DkAvW50hUEQ== From: To: X-OriginalArrivalTime: 09 Oct 2008 14:04:41.0376 (UTC) FILETIME=[F9688200:01C92A17] Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? >>> Issue 10921: TypeType This depends on resolution of issue 6532. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com ubject: OCL 2: No explicit statement that ownership of association ends does not matter for traversal in OCL To: issues@omg.org Cc: Pete Rivett , Branislav Selic , Dusko Misic X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Andreas Maier Date: Sat, 17 Mar 2007 21:22:36 . X-MIMETrack: Serialize by Router on D12ML066/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 17/03/2007 21:23:06 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hi, during work on the definition of the UML Profile for CIM (an activity performed jointly between OMG and DMTF), we recently found the following issue with OCL 2. Please record this issue officially and let me know the issue number for it. Issue: No explicit statement that ownership of association ends does not matter for traversal in OCL Nature: Clarification Severity: Minor Summary: The UML Superstructure spec 2.1.1 defines in section 6.5.2 "Diagram Format" that any meta-association has two ends, regardless of whether the ends are owned by the association or the associated classifiers. However, the Superstructure spec only describes those association ends that are owned by the associated classifiers. Furthermore, a major OCL engine (from Eclipse) does not currently support meta-association traversal in OCL towards ends owned by the meta-association. This may leave the impression to some readers that OCL would only support meta-association traversal in the direction of ends owned by the associated classifiers. I understand that the intention is in OCL to support traversal of meta-associations in any direction, regardless of whether the target end is owned by the association or the associated classifier. It would be helpful to state that explicitly in the OCL specification. Andy Andreas Maier IBM Senior Technical Staff Member, Systems Management Architecture & Design IBM Development Laboratory Boeblingen, Germany maiera@de.ibm.com, 7031-16-3654 ________________________________________________________________________________________________ IBM Deutschland Entwicklung GmbH; Vorsitzender des Aufsichtsrats: Johann Weihen, Geschaeftsfuehrung: Herbert Kircher; Sitz der Gesellschaft: Boeblingen, Registergericht: Amtsgericht Stuttgart, HRB 243294