Community
Participate
Working Groups
Build Identifier: HEAD on May 13, 2010 It attempts to validate the connector ends' types with the association ends' types but does so in order, which may or may not give an accurate result for associations where all ends are navigable. The attached patch fixes validation for binary associations and ignores it on other associations where all ends are navigable. Reproducible: Always
Created attachment 168465 [details] Fixes ConnectorOperations.validateTypes()
Any word if this can get into the Helios release?
The attached patch seems incorrect in several ways. Firstly, navigability and end ownership are two distinct concepts in UML; secondly, the patch explicitly handles only binary association case. The patch does not seem to address the corresponding constraint in the spec. Do you have a concrete example that illustrates the issue?
Here is a concrete example of the problem: 1) Add two classes to a model and call them C1 & C2. 2) Add an association (not a directed association) from C1 to C2. 3) Add an association (not a directed association) from C2 to C1. 4) Now assume C1 and C2 are types for two attribute parts. 5) Create a connector between the two parts and set the type of the connector to one of the associations. If you set the type of the connector to one of the associations, validation will succeed but if you set the type of the connector the other association, validation will fail.
This bug is invalid. The implementation of the constraint appears to match the UML specification: - semantics of connector have nothing to do with navigability of the ends of the association that is its type. An implicit (inferred) association type for a connector has all ends navigable only because some choice has to be made. They could as well all have been non-navigable, although that's not interesting since UML added the ability for owned ends to be navigable - connector ends are ordered; likewise association member ends - the correspondence of connector ends to member ends of its type association is one-to-one, as implied by the rules for inference of the association in the case where the connector type is unspecified So, in the scenario described in comment #4, a connector between a role of type C1 and a role of type C2 may only be typed by an association between C2 and C1 in which the member ends have type C1 and C2, in that order (accounting for generalization, of course). It is correct that only one of the association types is valid for the connector. What the proposed patch does in reversing member ends violates the ordering semantics of association members and connector ends. The correct resolution of the model validation problem is to ensure that, if the model is so complete as to specify the type of a connector, that such connector's ends are in the same order as the association member ends.
Given Christian's comment (thanks for looking into this!), it's not likely we'll be making a change in UML2.
