Issue 8015: Transitivity in composition (uml2-rtf) Source: NIST (Mr. Evan K. Wallace, evan.wallace(at)nist.gov) Nature: Revision Severity: Minor Summary: Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends. Resolution: Revised Text: In the Superstructure document in section 7.3.3 on page 38 replace the sentence: Compositions define transitive asymmetric relationships—their links form a directed, acyclic graph. by the sentence: Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. In the Infrastructure document in section 11.3.1 on page 115 replace the sentence: Compositions define transitive asymmetric relationships—their links form a directed, acyclic graph. by the sentence: Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. Actions taken: December 30, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 14:43:57 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Evan Wallace Company: NIST mailFrom: evan.wallace@nist.gov Notification: No Specification: UML 2 Super Section: Classes FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 04-10-02 Page: 0 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends. 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.