Issue 6409: UML 2 Super/Interactions/missing OCL constraints (uml2-rtf) Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com) Nature: Uncategorized Issue Severity: Summary: Not all the constraints in the Interactions section (14.3). They should be added Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change Revised Text: Actions taken: November 3, 2003: received issue February 20, 2015: closed issue Discussion: These constraints should definitely be added. This should be done in an RTF. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification. End of Annotations:===== ubject: UML 2 Super/Interactions/missing OCL constraints Date: Mon, 3 Nov 2003 14:20:42 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2 Super/Interactions/missing OCL constraints Thread-Index: AcOiP5KGfYbXFBuaSOy1/0sMnACRTQ== From: "Nikolai Mansurov" To: Cc: "Branislav Selic (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hA3JEmAq018928 Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran Not all the constraints in the Interactions section (14.3). They should be added.