Issue 6492: ptc-03-09-15/Non-navigable ends with no role names nor multiplicities (uml2-rtf) Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com) Nature: Uncategorized Issue Severity: Summary: Issue: It appears that associations with neither end names nor multiplicities on non-navigable ends are used in parts of the UML Core that are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for example. I understand that for elements defined via EMOF, this signifies a simple property. But is it appropriate for elements defined with CMOF. Recommendation: Either correct this by adding multiplicities and end names or explain in the specification why it is alright to omit them in these cases Resolution: The meaning of this convention should be explained in the document. Revised Text: OMG Issue No: 6492 Title: ptc-03-09-15/Non-navigable Ends with No Role Names Nor David Frankel Consulting (Mr. David S. Frankel, df@davidfrankelconsulting.com) Summary: Issue: It appears that associations with neither end names nor multiplicities on non-navigable ends are used in parts of the UML Core that are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for example. I understand that for elements defined via EMOF, this signifies a simple property. But is it appropriate for elements defined with CMOF? Recommendation: Either correct this by adding multiplicities and end names or explain in the specification why it is alright to omit them in these cases Resolution: The meaning of this convention should be explained in the document. Revised Text: In the Superstructure document, add to section 6.5.2 on page 16, as the second last bullet of the list, the following item: • If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints – although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) • Associations that are not explicitly named, are given names that are constructed according to the following production rule: “A_” <association-end-name1> “_” <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. In the Infrastructure document, add to section 6.3.1 on page 6, as the second last bullet of the list, the following item: • If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints – although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) OMG Issue No: 6492 Associations that are not explicitly named, are given names that are constructed according to the following production rule: “A_” <association-end-name1> “_” <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. Disposition: Resolved Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: End of Annotations:===== m: "David S. Frankel" To: Subject: UML2Infra-MOF2Core/ ptc-03-09-15/Non-navigable ends with no role names nor multiplicities Date: Fri, 7 Nov 2003 22:03:50 -0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Issue: It appears that associations with neither end names nor multiplicities on non-navigable ends are used in parts of the UML Core that are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for example. I understand that for elements defined via EMOF, this signifies a simple property. But is it appropriate for elements defined with CMOF. Recommendation: Either correct this by adding multiplicities and end names or explain in the specification why it is alright to omit them in these cases. ================================================================= David S. Frankel David Frankel Consulting Email: df@DavidFrankelConsulting.com Web: www.DavidFrankelConsulting.com Tel: +1 530 893-1100 Fax: +1 530 893-1153 David Frankel's MDA book: www.DavidFrankelConsulting.com/book.htm Subject: RE: Resolution proposals for classes and Infrastructure Date: Thu, 11 Aug 2005 20:08:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution proposals for classes and Infrastructure Thread-Index: AcWewITOG6i8q30ITySBu+6d0nZeUwACOzWA From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com This is generally OK - some minor comments (and philosophy - sorry) below. In 6630 there is a slight lack of clarity in the resolution as to whether the property is only to be made non-navigable (for which we have no notation) or in addition whether its ownership should be changed from the Class to the Association: I think the latter is intended but it could be made clearer. Even if we do clarify I'd probably abstain on the issue: I can see the argument for the resolution in terms of consistency, but remain unhappy about how the new definition of navigability is applied in the UML metamodel itself (in fact it has not been explicitly applied - we kept the metamodel as it was despite changing what navigability meant). The original issue 6630 is IMHO somewhat muddled when it refers to an element 'knowing about its dependencies': model elements cannot 'know' anything and IMHO such anthropomorphic phrasing tends to really cloud discussion. In practice any model-processing application/tool (for which the UML metamodel is really the design/specification model) will need to have direct access to the elements at both ends of any such Dependency (if only to allow the user to draw the line). And the intention of UML is to allow such tools to perform impact analysis etc (i.e. bidirectional navigation): so the fact that we don't reflect that expected access in the metamodel is a shame: we're not talking about a 'real' business application here. -------- For 6692 I agree that it should be Close no change, but don't think the response really answers the question of when to use derived attributes vs operations. I don't agree that ". Derived attributes are typically used when the computation is judged to be inefficient in some sense. " One reason could be if there is the possibility of setting the value (which we have in the metamodel itself). Another if there may be the need to serialize it (e.g. via XMI). My own view is that if something represents 'data' then it should be a derived attribute since it gives a lot more capability and provides a more uniform interface to client tools. In fact I don't think we do have any (non-helper) operations as part of the metamodel itself. In the specific case of lowerBound() the reason for an operation is that this is not a true part of the metamodel but a helper operation used only in the constraint for specifying the derived attribute. --------- There is a typo in 8015: there is an extraneous 'in' before 'with': "Compositions may be linked in a directed acyclic graph in with transitive deletion characteristics" -------- One thing we need to add, I suggest to the resolution to 6492, is the convention for naming Associations: CMOF requires all Associations to have a name, and none at all are explicitly named in the Infra or Super specs. The convention I used in creating the XMI (which was also used in the UML 1.x XMI) is to name associations as "A_" followed by the name of the 1st end followed by "_" followed by the name of the 2nd end (where the name ends are as per the current proposed resolution if not explicit). PS we may want to add something to the following in the 6492 resolution text "in general, there is no need to refer to them explicitly either in the text or in formal constraints" while true, there is the need to refer to them in generated MOF language bindings for the UML metamodel (which is why CMOF requires the names). So I suggest adding "though they may be needed for other purposes such as MOF language bindings that use the metamodel." Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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 11, 2005 10:42 PM To: uml2-rtf@omg.org Subject: Resolution proposals for classes and Infrastructure Here are 10 resolution proposals that I hope to submit to ballot 8. Most of them are in the Classes and Infrastructure areas, so they should probably be carefully scrutinized. Cheers, Bran Reply-To: From: "Conrad Bock" To: Subject: RE: Draft ballot 8 Date: Fri, 19 Aug 2005 09:59:12 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Sorry for the slow reply, I've been having some problems with my mail client. > I guess there are multiple conflicting "conventional" > interpretations at work here. Visibility in UML has to do with > namespaces, which is a static compile-time concept and not a > dynamic run-time concept. Will reply on the "visibility" thread. > > - Issue 6492: ptc-03-09-15/Non-navigable ends with no role names nor > > multiplicities > > > > The resolution says: > > > > If an association end is unlabeled, the default name for that end > > is the name of the class to which the end is attached, modified > > such that the first letter is a lowercase letter. > > > > What if there are two unnamed ends "attached to" the same class? > > I was thinking of that one as well when I wrote this up: it > should probably use some kind of sequence numbering scheme. > Pete, what convention, if any do you folks use in those cases? Didn't see a reply from Pete, but it might be my mailer problems. > > - Issue 8015: Transitivity in composition > > > > Thanks for the correction, but would it be possible to remove the > > discussion, which is derogatory? > > I will reformulate the discussion. It was a reaction to what I > perceive as an arrogant assumption that there is just one > correct definition of the term "transitive" and that, naturally, > the submitter knew what it was. When used in conjunction with the word "anti-symmetric" there could really be only one interpretation, the one used typically in mathematics. I'm sure Jim R wrote this and had that in mind. > > The problem is clear to anyone > > understanding the semantics of transitivity, and leads to the > > general complaint that UML semantics is underspecified. Especially > > with OWL on the scene, it is important that UML be more careful in > > describing the meaning of its constructs. > > Yes, but such pedantry can be taken to the point of diminishing > returns. As I said in the discussion, I doubt strongly that this > is something that has really confused anyone. A colleague of mine noticed this in trying to use UML for analysis-level (so called CIM, ontology, don't want to start that discussion!) and saw the inconsistency. I'm surpised by your lack of concern for semantics in UML. From: "Thomas Weigert" To: "'Branislav Selic'" , Subject: RE: Ballot 8: start of voting Date: Fri, 19 Aug 2005 16:39:32 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 I am concerned about 6492. Why do we need to come up with names for unnamed, non-navigable ends? These are unnamed for a reason. If we do come up with names, there needs to be a rule that resolves name clashes if there is already an association with that invented name. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 19, 2005 4:26 PM To: uml2-rtf@omg.org Subject: Ballot 8: start of voting The official ballot 8 is attached below. The following are the differences from the draft ballot: 6201 - resolution added (accidentally omitted from ballot 7) 7950 - Oystein's latest edits included 8015 - offensive discussion text removed 8094 - further explanations added to the discussion 8144 - removed, since this issue was resolved in ballot 3 8164 - removed, since this issue was resolved in ballot 3 8330 - Oystein's latest edits included 8341 - Oystein's latest edits included 8345 - Oystein's latest edits included 8846 - removed at A. Moore's request Voting starts at 6 pm EDT today and ends on Friday, September 2, 2005 at 6 pm EDT Regards...Bran Subject: RE: Ballot 8: start of voting Date: Sun, 21 Aug 2005 11:13:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 8: start of voting Thread-Index: AcWlCYE2+baVlE8/Qf6u/rUX18m3BgBVNpfQ From: "Pete Rivett" To: "Thomas Weigert" , "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com Easy answer; UML2 is a CMOF metamodel and these are required (there is an explicit constraint) to have names for all association ends and associations. The proposed resolution for 6492 does not require anyone to 'come up' with a name - it proposes a rule whereby they are automatically generated. You may not realize it but exactly such a rule was used at UML 1.x (just have a look at the XMI). What this resolution (rightly) does is document the rule used - rather than having it buried away in some RoseScript/Java/XSLT. In practice the nameclash issue does not arise - since for ends owned by their Association (which, by convention, will be all ends depicted as 'non-navigable' in the UML2 spec diagrams - but remember now that ownership is distinct from navigability) then the end name need only be unique within the set of the (2 or fewer) ends owned by that Association (and any generalizations thereof). In practice in the UML2 metamodel all associations have at least one end owned by a Class - leaving a max of one end barring those from generalizations - for which a name 'clash' actually implies a {redefines} (again by convention in the UML2 spec). Pete Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Friday, August 19, 2005 10:40 PM To: 'Branislav Selic'; uml2-rtf@omg.org Subject: RE: Ballot 8: start of voting I am concerned about 6492. Why do we need to come up with names for unnamed, non-navigable ends? These are unnamed for a reason. If we do come up with names, there needs to be a rule that resolves name clashes if there is already an association with that invented name. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, August 19, 2005 4:26 PM To: uml2-rtf@omg.org Subject: Ballot 8: start of voting The official ballot 8 is attached below. The following are the differences from the draft ballot: 6201 - resolution added (accidentally omitted from ballot 7) 7950 - Oystein's latest edits included 8015 - offensive discussion text removed 8094 - further explanations added to the discussion 8144 - removed, since this issue was resolved in ballot 3 8164 - removed, since this issue was resolved in ballot 3 8330 - Oystein's latest edits included 8341 - Oystein's latest edits included 8345 - Oystein's latest edits included 8846 - removed at A. Moore's request Voting starts at 6 pm EDT today and ends on Friday, September 2, 2005 at 6 pm EDT Regards...Bran =================================================================