Issue 8751: Relations (mof2core-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations. Resolution: It is not clear that all connections between elements in the UML2 model are a kind of Relationship or DirectedRelationship. A better way to achieve generic traversal is to use MOF reflection to navigate metaclass containment associations. Tools would be free to merge MOF2 Reflection into UML2 compliance levels to provide this capability. If this change were to be made it could have a significant impact on existing implementations and, therefore, is outside the scope of an RTF Disposition: Closed, no change Revised Text: Actions taken: May 1, 2005: received issue June 13, 2006: transferred to mof2core-rtf January 20, 2011: closed issue; Closed; No Change April 25, 2011: closed issue Discussion: It is not clear that all connections between elements in the UML2 model are a kind of Relationship or DirectedRelationship. A better way to achieve generic traversal is to use MOF reflection to navigate metaclass containment associations. Tools would be free to merge MOF2 Reflection into UML2 compliance levels to provide this capability. If this change were to be made it could have a significant impact on existing implementations and, therefore, is outside the scope of an RTF End of Annotations:===== m: webmaster@omg.org Date: 01 May 2005 08:07:05 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Markus Brigl Company: mailFrom: mbrigl@gmx.net Notification: Yes Specification: UML 2 Superstructure Section: General FormalNumber: ptc/04-10-02 Version: RevisionDate: Page: Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations. Reply-To: From: "Conrad Bock" To: Subject: RE: Draft ballot 7 -- please review Date: Tue, 2 Aug 2005 15:36:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 7. Conrad - Issue 8021: Section: Classes The discussion says "There are no constraints or any other connection between properties B::aend and SubB::subA", but there must be. For example, if there is an instance of SubB, and you navigate from it along the inherited B::aend, the result should be the instances of A related by that association, including the ones created on instances of SubA with SubB::subA. How can it have this semantics if B::aend and SubB::subA aren't related? Needs more discussion, especially in relation to the text references in Association Semantics, see 8023 below. - Issue 8023: Association specialization semantics This didn't address the issues that some of the text applies to Generalization. The cited text, including the proposed revision, is especially confusing because the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, as the cited text explains, but that is a minor point. Subsetting/specialization in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. In particular, for association classes, the user should be able to specialize an association class with another association class with the same semantics as to subsetting ends. Should discuss more. - Issue 8028: create dependency Figures 103 and 121 This way of modeling a constructor should be in Classes, which Thomas agrees with. His question on the wiki was about whether compliance levels permitted it, but I can't see why they wouldn't. Seems like it can be moved to Classes with no adverse effect. - Issue 8038: IsReadOnly constriant This is overconstrained, because the default value could be set dynamically before initialization, rather than a default value. As long as this happens before initialization is over, there is no violation of multiplicity. In any case, UML doesn't enforce when constraints are evaluated or inconsistencies repaired. Tim's response on the wiki only came on the 29th, so I hadn't replied, but it was only about the wording I used on the wiki, which I corrected to the above. Never mind that I filed the issue! - Issue 8078: Actor is a specialized Classifier and not BehavioredClassifier There isn't anything I can find on BehavioredClassifier that says it supports interfaces. - Issue 8677: token movement In the revised text, update the new sentence to "For brevity, the specification uses the terms "flow", "pass", "traverse" interchangeably in relation to tokens to mean offering tokens, and movement of tokens when offers are accepted. - Issue 8751: Relations I agree with the filer here. We should discuss more. - Issue 8758: Association in UseCase diagram Can't say there hasn't been enough discussion, but use cases have had associations between them for so long, that it doesn't seem