Community
Participate
Working Groups
Created attachment 176873 [details] Simple model with an InterfaceRealization Hello, using an InterfaceRealization, I get the following error after the validation: The opposite features 'namespace' of '<Interface Realization> yourrealization' and 'ownedMember' of '<Class> yourclass' do not refer to each other My.uml /testuml Unknown EMF Problem I'm using the last release of UML2 (feature UML2 Extender SDK 3.1.0.201006071150) and Eclipse Helios. Please find attached a simple model to reproduce the validation message. Regards, Gabriel
Hello, I have the same kind of error. When I define an interface with a property (or an operation), the validation fails with the following error: The opposite features 'feature' of '<Interface> MyInterface' and 'featuringClassifier' of '<Property> myProperty' do not refer to each other My.uml /model/src Unknown EMF Problem I use Helios with UML2: feature UML2 Unified Modeling Language 2.x Version: 3.1.1.v201008191505 Build id: 201006071241
The case with namespace / ownedMember is already addressed (see bug 320318). Any/all remaining cases will be addressed with this bug.
*** Bug 326746 has been marked as a duplicate of this bug. ***
Kenn, while this be addressed in an update for UML2 even before Helios SR2 in February?
(In reply to comment #4) > Kenn, while this be addressed in an update for UML2 even before Helios SR2 in > February? I'll try to post builds, for both the Indigo and Helios SR2 streams, soon. There won't be an official release before Helios SR2.
The fix has been committed to HEAD and 3_1_maintenance streams.
Builds containing the fix, for both UML2 3.2.0 and 3.1.2, are now available.
*** Bug 329739 has been marked as a duplicate of this bug. ***
I see that the fix merely disables validation of the offending references. Are there any plans for a "real" fix that corrects the underlying referential integrity issue? I couldn't find any tickets adressing that...
(In reply to comment #9) > I see that the fix merely disables validation of the offending references. Are > there any plans for a "real" fix that corrects the underlying referential > integrity issue? I couldn't find any tickets adressing that... As stated in bug 320318, we assume (and have for years) the implicit container of an element is its owner, the implicit container of a named element is also its namespace (if it's a kind of Namespace), and so on. In order to properly satisfy the constraint in question, we'd need to stop making this assumption and add a bunch of new 'subsets' constraints to the metamodel to make the relationship explicit. However, this kind of change would not be trivial and may have undesirable effects on existing clients. My preference is to bypass the constraint for specific features, since they are derived unions (read only and computed) anyway...
For me, this issue doesn't have much to do with assumptions one way or the other, or with the specifics of namespaces containing named elements. It is about a contract promised by the metamodel and broken by the implementation. I am (or rather my tools are) looking at instances of the UML metamodel just as instances of some EMF model and therefore know nothing about those implicit assumptions, just about bidirectional references - which then turn out to be not all that bidirectional... And since those derived unions, like Classifier.feature and Feature.featuringClassifier, don't (and obviously can't) expose any information about composition on the Ecore side of things, I couldn't even get the idea of using the implicit container. I'd therefore suggest that the references in question should either be fixed, or - if that's infeasible - be split into pairs of unidirectional references.
PS: I just had a look at the UML2 Superstructure and saw that it is missing the same bunch of subsets constraints. Maybe I should pester the OMG with this instead?
(In reply to comment #12) > PS: I just had a look at the UML2 Superstructure and saw that it is missing the > same bunch of subsets constraints. Maybe I should pester the OMG with this > instead? Yes, the implication was that all of these constraints would need to be added to the spec and that the implementation would need to migrate to the new version of the spec...
*** Bug 333456 has been marked as a duplicate of this bug. ***
Closing for Indigo release.
