Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312838

Summary:

ConnectorOperations.validateTypes() doesn't take into account associations navigable on all ends

Product:

[Modeling] MDT.UML2

Reporter:

Wayne <wdiu>

Component:

Core

Assignee:

UML2 Inbox <mdt-uml2-inbox>

Status:

RESOLVED INVALID

QA Contact:

Severity:

normal

Priority:

CC:

ahunter.eclipse, bruck.james, Kenn.Hussey

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Fixes ConnectorOperations.validateTypes()	none

Description Wayne

2010-05-13 16:01:43 EDT

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

Comment 1 Wayne

2010-05-13 16:02:55 EDT

Created attachment 168465 [details]
Fixes ConnectorOperations.validateTypes()

Comment 2 Anthony Hunter

2010-05-21 17:37:30 EDT

Any word if this can get into the Helios release?

Comment 3 James Bruck

2010-05-22 00:11:17 EDT

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?

Comment 4 Wayne

2010-05-25 11:00:11 EDT

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.

Comment 5 Christian Damus

2012-08-29 09:55:21 EDT

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.

Comment 6 Kenn Hussey

2012-08-29 11:34:12 EDT

Given Christian's comment (thanks for looking into this!), it's not likely we'll be making a change in UML2.