Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » EMF bidirectional validation failing
EMF bidirectional validation failing [message #546499] Tue, 13 July 2010 06:51 Go to next message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
Dear all, in Helios, literally all my UML models no longer validate,
including trivial new ones. For example, in the Helios Modeling Tools
release, I create a new UML model with the following structure:

+ Model
+ Statemachine
+ Region
+ Transition
+Trigger

Selecting "Validate" in the UML editor will then yield:

"The opposite features 'owner' of '<Trigger> s' and 'ownedElement' of
'<Transition> k' do not refer to each other"

Likewise, in the OCL console, on the transition, querying for 'trigger'
will return the trigger, but both 'ownedMember' and 'ownedElement'
return an empty result set (which is why the validation seems to be
failing).

I'm observing this on two different Helios installations (MacOS MDT
20100617-1415, Solaris x86 3.6RC4).

Thanks in advance for any clues as to what I'm doing wrong!

Volker, F'Up set

--
United Nations University -
Re: EMF bidirectional validation failing [message #547710 is a reply to message #546499] Mon, 19 July 2010 11:33 Go to previous messageGo to next message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
In article <i1kd1d$69d$1@build.eclipse.org>,
Ed Merks <Ed.Merks@gmail.com> wrote:

> Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
> the complaints about source and target not being set might be the cause
> of these other problems.

(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace <-> ownedMember
owner <-> ownedElement

One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.

I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this. I double-checked with the OCL interpreter in Galileo, it
has the same result (ownedMember doesn't contain the interface
realization), so the only difference seems to be the bidirectional
validation that you added a while ago (I'm not aware of the UML
metamodel changing in the meantime as well).

For clarification, let me give this problem another spin: from looking
e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
only be included in ownedElements, but not in ownedMembers. However, the
Javadoc (presumably generated from the metamodel) says that the opposite
of namespace is ownedMember, which clearly isn't the case for
InterfaceRealization. I am wondering if your validation rule is finally
exposing a bug in the UML metamodel, where either this opposite
feature-relationship was incorrectly specified, or that the generated
code does not correctly reflect that e.g. interface realizations should
be included in ownedMembers.

I guess I'll raise a bug in MDT if nobody else has any idea (and once
I'm past my surprise that nobody else is observing this---it means that
most people are happy with UML class diagrams and don't actually venture
to component diagrams or state machines ;)

Volker

> Volker Stolz wrote:
> > In article <i1hofp$rkn$1@build.eclipse.org>,
> > Ed Merks <Ed.Merks@gmail.com> wrote:
>
> > Ed, thanks for your input. I'm using the Example EMF Model Creation
> > Wizard to create the UML model (here; as reported I get the same problem
> > with programmatically generated UML files).
> > In this case, I only stay within the editor, and there is no (separate,
> > on-disk) Ecore model (except the UML models in-memory representation).
> > There's also nothing in the Error Log, and I just checked with a fresh
> > Classic Helios and only installed the UML2Extender.
> >
> > This is the trivial model.uml (never mind the line breaks). :
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <uml:Model xmi:version="2.1"
> > xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> > xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"
> > xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint="">
> > <packagedElement xmi:type="uml:StateMachine"
> > xmi:id="_-hY4EI6MEd-MxvZKuoG_jg">
> > <region xmi:id="__yf6oI6MEd-MxvZKuoG_jg">
> > <transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg">
> > <trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/>
> > </transition>
> > </region>
> > </packagedElement>
> > </uml:Model>
> >
> > Should this better go to one of the UML groups?
> >
> > Volker

--
United Nations University -
Re: EMF bidirectional validation failing [message #547721 is a reply to message #547710] Mon, 19 July 2010 13:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090308060206020802090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Volker,

Comments below.

Volker Stolz wrote:
> In article <i1kd1d$69d$1@build.eclipse.org>,
> Ed Merks <Ed.Merks@gmail.com> wrote:
>
>
>> Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
>> the complaints about source and target not being set might be the cause
>> of these other problems.
>>
>
> (x-posting/f-up to .uml2)
>
> Hi Ed, I think this might be unlikely. So far I have two instances of
> this validation problem:
>
> namespace <-> ownedMember
> owner <-> ownedElement
>
Those are definitely properly paired bidirectional opposites in
UML21.ecore. They are also derived. I believe they are derived from
containment references so they're sort of like a derived containment.
> One of those other examples is that if I have
>
> + Component c
> + Property p
> + InterfaceRealization r
>
> the property is in c.ownedMembers, and the interface realization isn't.
>
Now you're talking an instances though. I don't see how Ecore
constraints on UML itself end up apply for an instance. UML's own
constraints should apply instead.
> I am wondering if this means that the UML metamodel is not consistent
> with your validation rule (from [280397]): it says that ownedMember is
> the opposite of namespace, but even from looking at the source (Galileo
> and Helios) it is clear that the implementation of e.g. Component never
> ensured this.
What makes that clear?
> I double-checked with the OCL interpreter in Galileo, it
> has the same result (ownedMember doesn't contain the interface
> realization), so the only difference seems to be the bidirectional
> validation that you added a while ago (I'm not aware of the UML
> metamodel changing in the meantime as well).
>
> For clarification, let me give this problem another spin: from looking
> e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
> only be included in ownedElements, but not in ownedMembers. However, the
> Javadoc (presumably generated from the metamodel) says that the opposite
> of namespace is ownedMember, which clearly isn't the case for
> InterfaceRealization. I am wondering if your validation rule is finally
> exposing a bug in the UML metamodel, where either this opposite
> feature-relationship was incorrectly specified, or that the generated
> code does not correctly reflect that e.g. interface realizations should
> be included in ownedMembers.
>
Someone in UML land will need to comment. I just don't see how Ecore's
constraints end up apply to UML2 instances. Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?
> I guess I'll raise a bug in MDT if nobody else has any idea (and once
> I'm past my surprise that nobody else is observing this---it means that
> most people are happy with UML class diagrams and don't actually venture
> to component diagrams or state machines ;)
>
> Volker
>
>
>> Volker Stolz wrote:
>>
>>> In article <i1hofp$rkn$1@build.eclipse.org>,
>>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>>
>>> Ed, thanks for your input. I'm using the Example EMF Model Creation
>>> Wizard to create the UML model (here; as reported I get the same problem
>>> with programmatically generated UML files).
>>> In this case, I only stay within the editor, and there is no (separate,
>>> on-disk) Ecore model (except the UML models in-memory representation).
>>> There's also nothing in the Error Log, and I just checked with a fresh
>>> Classic Helios and only installed the UML2Extender.
>>>
>>> This is the trivial model.uml (never mind the line breaks). :
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <uml:Model xmi:version="2.1"
>>> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>>> xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"
>>> xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint="">
>>> <packagedElement xmi:type="uml:StateMachine"
>>> xmi:id="_-hY4EI6MEd-MxvZKuoG_jg">
>>> <region xmi:id="__yf6oI6MEd-MxvZKuoG_jg">
>>> <transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg">
>>> <trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/>
>>> </transition>
>>> </region>
>>> </packagedElement>
>>> </uml:Model>
>>>
>>> Should this better go to one of the UML groups?
>>>
>>> Volker
>>>
>
>

--------------090308060206020802090103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
Comments below.<br>
<br>
Volker Stolz wrote:
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i1kd1d$69d$1@build.eclipse.org">&lt;i1kd1d$69d$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
the complaints about source and target not being set might be the cause
of these other problems.
</pre>
</blockquote>
<pre wrap=""><!---->
(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace &lt;-&gt; ownedMember
owner &lt;-&gt; ownedElement
</pre>
</blockquote>
Those are definitely properly paired bidirectional opposites in
UML21.ecore.&nbsp; They are also derived.&nbsp; I believe they are derived from
containment references so they're sort of like a derived containment.<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.
</pre>
</blockquote>
Now you're talking an instances though.&nbsp; I don't see how Ecore
constraints on UML itself end up apply for an instance.&nbsp; UML's own
constraints should apply instead.<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this. </pre>
</blockquote>
What makes that clear?<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">I double-checked with the OCL interpreter in Galileo, it
has the same result (ownedMember doesn't contain the interface
realization), so the only difference seems to be the bidirectional
validation that you added a while ago (I'm not aware of the UML
metamodel changing in the meantime as well).

For clarification, let me give this problem another spin: from looking
e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
only be included in ownedElements, but not in ownedMembers. However, the
Javadoc (presumably generated from the metamodel) says that the opposite
of namespace is ownedMember, which clearly isn't the case for
InterfaceRealization. I am wondering if your validation rule is finally
exposing a bug in the UML metamodel, where either this opposite
feature-relationship was incorrectly specified, or that the generated
code does not correctly reflect that e.g. interface realizations should
be included in ownedMembers.
</pre>
</blockquote>
Someone in UML land will need to comment.&nbsp; I just don't see how Ecore's
constraints end up apply to UML2 instances.&nbsp; Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
I guess I'll raise a bug in MDT if nobody else has any idea (and once
I'm past my surprise that nobody else is observing this---it means that
most people are happy with UML class diagrams and don't actually venture
to component diagrams or state machines ;)

Volker

</pre>
<blockquote type="cite">
<pre wrap="">Volker Stolz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i1hofp$rkn$1@build.eclipse.org">&lt;i1hofp$rkn$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Ed, thanks for your input. I'm using the Example EMF Model Creation
Wizard to create the UML model (here; as reported I get the same problem
with programmatically generated UML files).
In this case, I only stay within the editor, and there is no (separate,
on-disk) Ecore model (except the UML models in-memory representation).
There's also nothing in the Error Log, and I just checked with a fresh
Classic Helios and only installed the UML2Extender.

This is the trivial model.uml (never mind the line breaks). :

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;uml:Model xmi:version="2.1"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://schema.omg.org/spec/XMI/2.1">"http://schema.omg.org/spec/XMI/2.1"</a>
xmlns:uml=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/uml2/3.0.0/UML">"http://www.eclipse.org/uml2/3.0.0/UML"</a>
xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint=""&gt;
&lt;packagedElement xmi:type="uml:StateMachine"
xmi:id="_-hY4EI6MEd-MxvZKuoG_jg"&gt;
&lt;region xmi:id="__yf6oI6MEd-MxvZKuoG_jg"&gt;
&lt;transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg"&gt;
&lt;trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/&gt;
&lt;/transition&gt;
&lt;/region&gt;
&lt;/packagedElement&gt;
&lt;/uml:Model&gt;

Should this better go to one of the UML groups?

Volker
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------090308060206020802090103--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF bidirectional validation failing [message #547760 is a reply to message #547721] Mon, 19 July 2010 14:50 Go to previous messageGo to next message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
In article <i21ja2$jbo$1@build.eclipse.org>,
Ed Merks <Ed.Merks@gmail.com> wrote:

> > (x-posting/f-up to .uml2)
> >
> > Hi Ed, I think this might be unlikely. So far I have two instances of
> > this validation problem:
> >
> > namespace <-> ownedMember
> > owner <-> ownedElement
> >
> Those are definitely properly paired bidirectional opposites in
> UML21.ecore. They are also derived. I believe they are derived from
> containment references so they're sort of like a derived containment.
> > One of those other examples is that if I have
> >
> > + Component c
> > + Property p
> > + InterfaceRealization r
> >
> > the property is in c.ownedMembers, and the interface realization isn't.
> >
> Now you're talking an instances though. I don't see how Ecore
> constraints on UML itself end up apply for an instance. UML's own
> constraints should apply instead.
> > I am wondering if this means that the UML metamodel is not consistent
> > with your validation rule (from [280397]): it says that ownedMember is
> > the opposite of namespace, but even from looking at the source (Galileo
> > and Helios) it is clear that the implementation of e.g. Component never
> > ensured this.
> What makes that clear?

Ed, I'm a bit confused by your remark about instances and constraints
above.

For the example above, you can find, what I understood to be the
calculation of those derived sets, in
org.eclipse.uml2.uml.internal.impl.ComponentImpl:

protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_RULE,
UMLPackage.COMPONENT__OWNED_USE_CASE,
UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
UMLPackage.COMPONENT__OWNED_CONNECTOR,
UMLPackage.COMPONENT__OWNED_BEHAVIOR,
UMLPackage.COMPONENT__OWNED_TRIGGER,
UMLPackage.COMPONENT__NESTED_CLASSIFIER,
UMLPackage.COMPONENT__OWNED_OPERATION,
UMLPackage.COMPONENT__OWNED_RECEPTION,
UMLPackage.COMPONENT__PACKAGED_ELEMENT};

protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_COMMENT,
UMLPackage.COMPONENT__NAME_EXPRESSION,
UMLPackage.COMPONENT__ELEMENT_IMPORT,
UMLPackage.COMPONENT__PACKAGE_IMPORT,
UMLPackage.COMPONENT__OWNED_MEMBER,
UMLPackage.COMPONENT__TEMPLATE_BINDING,
UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
UMLPackage.COMPONENT__GENERALIZATION,
UMLPackage.COMPONENT__SUBSTITUTION,
UMLPackage.COMPONENT__COLLABORATION_USE,
*** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
UMLPackage.COMPONENT__REALIZATION};

which indicates to me that interface realizations are not ownedMembers
(since they are explicitly listed in ownedElements, but not
ownedMembers, see ***) . But then I wonder how this matches with
ownedMember being supposedly the opposite of namespace!

> Someone in UML land will need to comment. I just don't see how Ecore's
> constraints end up apply to UML2 instances. Where in a UML is there an
> instance of EReference? Or to ask it another way, what in UML derives
> from EReference or reuses EReference?

I am by no means certain where this behaviour might come from (except
that the UML behaviour is unchanged from Galileo to Helios). Of course
there's a chance that the generator that produced the above code should
have, well, generated something else.

I hope you can observe the same behaviour as I do by clicking together a
trivial model using New->UML Model and running Validate from within the
UML Editor.

EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
explicitly e.g. in UMLValidator.validateComponent.

Volker

--
United Nations University -
Re: EMF bidirectional validation failing [message #547779 is a reply to message #547760] Mon, 19 July 2010 15:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020807010204060803010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Volker,

I see. I'm confusing the constraints! Doh!! :-P

_UI_UnpairedBidirectionalReference_diagnostic is the one you're
referring too. In that case, I expect you're right. There's likely
something about UML's derivation of these features that is indeed not
implemented correctly and it's only by checking this constraint that we
find the instances aren't properly conforming to the definition of the
UML model. Hopefully some UML expert will comment on this.


Volker Stolz wrote:
> In article <i21ja2$jbo$1@build.eclipse.org>,
> Ed Merks <Ed.Merks@gmail.com> wrote:
>
>
>>> (x-posting/f-up to .uml2)
>>>
>>> Hi Ed, I think this might be unlikely. So far I have two instances of
>>> this validation problem:
>>>
>>> namespace <-> ownedMember
>>> owner <-> ownedElement
>>>
>>>
>> Those are definitely properly paired bidirectional opposites in
>> UML21.ecore. They are also derived. I believe they are derived from
>> containment references so they're sort of like a derived containment.
>>
>>> One of those other examples is that if I have
>>>
>>> + Component c
>>> + Property p
>>> + InterfaceRealization r
>>>
>>> the property is in c.ownedMembers, and the interface realization isn't.
>>>
>>>
>> Now you're talking an instances though. I don't see how Ecore
>> constraints on UML itself end up apply for an instance. UML's own
>> constraints should apply instead.
>>
>>> I am wondering if this means that the UML metamodel is not consistent
>>> with your validation rule (from [280397]): it says that ownedMember is
>>> the opposite of namespace, but even from looking at the source (Galileo
>>> and Helios) it is clear that the implementation of e.g. Component never
>>> ensured this.
>>>
>> What makes that clear?
>>
>
> Ed, I'm a bit confused by your remark about instances and constraints
> above.
>
> For the example above, you can find, what I understood to be the
> calculation of those derived sets, in
> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>
> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
> UMLPackage.COMPONENT__OWNED_RULE,
> UMLPackage.COMPONENT__OWNED_USE_CASE,
> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
> UMLPackage.COMPONENT__OWNED_CONNECTOR,
> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
> UMLPackage.COMPONENT__OWNED_TRIGGER,
> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
> UMLPackage.COMPONENT__OWNED_OPERATION,
> UMLPackage.COMPONENT__OWNED_RECEPTION,
> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>
> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
> UMLPackage.COMPONENT__OWNED_COMMENT,
> UMLPackage.COMPONENT__NAME_EXPRESSION,
> UMLPackage.COMPONENT__ELEMENT_IMPORT,
> UMLPackage.COMPONENT__PACKAGE_IMPORT,
> UMLPackage.COMPONENT__OWNED_MEMBER,
> UMLPackage.COMPONENT__TEMPLATE_BINDING,
> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
> UMLPackage.COMPONENT__GENERALIZATION,
> UMLPackage.COMPONENT__SUBSTITUTION,
> UMLPackage.COMPONENT__COLLABORATION_USE,
> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
> UMLPackage.COMPONENT__REALIZATION};
>
> which indicates to me that interface realizations are not ownedMembers
> (since they are explicitly listed in ownedElements, but not
> ownedMembers, see ***) . But then I wonder how this matches with
> ownedMember being supposedly the opposite of namespace!
>
>
>> Someone in UML land will need to comment. I just don't see how Ecore's
>> constraints end up apply to UML2 instances. Where in a UML is there an
>> instance of EReference? Or to ask it another way, what in UML derives
>> from EReference or reuses EReference?
>>
>
> I am by no means certain where this behaviour might come from (except
> that the UML behaviour is unchanged from Galileo to Helios). Of course
> there's a chance that the generator that produced the above code should
> have, well, generated something else.
>
> I hope you can observe the same behaviour as I do by clicking together a
> trivial model using New->UML Model and running Validate from within the
> UML Editor.
>
> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
> explicitly e.g. in UMLValidator.validateComponent.
>
> Volker
>
>

--------------020807010204060803010306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
I see.&nbsp; I'm confusing the constraints!&nbsp; Doh!! :-P<br>
<br>
_UI_UnpairedBidirectionalReference_diagnostic is the one you're
referring too.&nbsp; In that case, I expect you're right.&nbsp; There's likely
something about UML's derivation of these features that is indeed not
implemented correctly and it's only by checking this constraint that we
find the instances aren't properly conforming to the definition of the
UML model.&nbsp;&nbsp; Hopefully some UML expert will comment on this.<br>
<br>
<br>
Volker Stolz wrote:
<blockquote cite="mid:vs-950039.16503319072010@news.eclipse.org"
type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i21ja2$jbo$1@build.eclipse.org">&lt;i21ja2$jbo$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace &lt;-&gt; ownedMember
owner &lt;-&gt; ownedElement

</pre>
</blockquote>
<pre wrap="">Those are definitely properly paired bidirectional opposites in
UML21.ecore. They are also derived. I believe they are derived from
containment references so they're sort of like a derived containment.
</pre>
<blockquote type="cite">
<pre wrap="">One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.

</pre>
</blockquote>
<pre wrap="">Now you're talking an instances though. I don't see how Ecore
constraints on UML itself end up apply for an instance. UML's own
constraints should apply instead.
</pre>
<blockquote type="cite">
<pre wrap="">I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this.
</pre>
</blockquote>
<pre wrap="">What makes that clear?
</pre>
</blockquote>
<pre wrap=""><!---->
Ed, I'm a bit confused by your remark about instances and constraints
above.

For the example above, you can find, what I understood to be the
calculation of those derived sets, in
org.eclipse.uml2.uml.internal.impl.ComponentImpl:

protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_RULE,
UMLPackage.COMPONENT__OWNED_USE_CASE,
UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
UMLPackage.COMPONENT__OWNED_CONNECTOR,
UMLPackage.COMPONENT__OWNED_BEHAVIOR,
UMLPackage.COMPONENT__OWNED_TRIGGER,
UMLPackage.COMPONENT__NESTED_CLASSIFIER,
UMLPackage.COMPONENT__OWNED_OPERATION,
UMLPackage.COMPONENT__OWNED_RECEPTION,
UMLPackage.COMPONENT__PACKAGED_ELEMENT};

protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_COMMENT,
UMLPackage.COMPONENT__NAME_EXPRESSION,
UMLPackage.COMPONENT__ELEMENT_IMPORT,
UMLPackage.COMPONENT__PACKAGE_IMPORT,
UMLPackage.COMPONENT__OWNED_MEMBER,
UMLPackage.COMPONENT__TEMPLATE_BINDING,
UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
UMLPackage.COMPONENT__GENERALIZATION,
UMLPackage.COMPONENT__SUBSTITUTION,
UMLPackage.COMPONENT__COLLABORATION_USE,
*** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
UMLPackage.COMPONENT__REALIZATION};

which indicates to me that interface realizations are not ownedMembers
(since they are explicitly listed in ownedElements, but not
ownedMembers, see ***) . But then I wonder how this matches with
ownedMember being supposedly the opposite of namespace!

</pre>
<blockquote type="cite">
<pre wrap="">Someone in UML land will need to comment. I just don't see how Ecore's
constraints end up apply to UML2 instances. Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?
</pre>
</blockquote>
<pre wrap=""><!---->
I am by no means certain where this behaviour might come from (except
that the UML behaviour is unchanged from Galileo to Helios). Of course
there's a chance that the generator that produced the above code should
have, well, generated something else.

I hope you can observe the same behaviour as I do by clicking together a
trivial model using New-&gt;UML Model and running Validate from within the
UML Editor.

EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
explicitly e.g. in UMLValidator.validateComponent.

Volker

</pre>
</blockquote>
</body>
</html>

--------------020807010204060803010306--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF bidirectional validation failing [message #547812 is a reply to message #547779] Mon, 19 July 2010 16:21 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Hmm, this is a bit of a problem. In UML2, we assume (and have for years)
the implicit container of an element is its owner, and the implicit
container of a named element is also its namespace (if it's a kind of
Namespace). In order to satisfy this new constraint, we'd either need to
stop making this assumption and add a bunch of new subsets constraints
to the metamodel to make it explicit, or else (perhaps more
realistically) bypass the constraint for UML models. In any case, please
open a bug and hopefully someone will look into it.

Kenn

Ed Merks wrote:
> Volker,
>
> I see. I'm confusing the constraints! Doh!! :-P
>
> _UI_UnpairedBidirectionalReference_diagnostic is the one you're
> referring too. In that case, I expect you're right. There's likely
> something about UML's derivation of these features that is indeed not
> implemented correctly and it's only by checking this constraint that we
> find the instances aren't properly conforming to the definition of the
> UML model. Hopefully some UML expert will comment on this.
>
>
> Volker Stolz wrote:
>> In article <i21ja2$jbo$1@build.eclipse.org>,
>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>
>>
>>>> (x-posting/f-up to .uml2)
>>>>
>>>> Hi Ed, I think this might be unlikely. So far I have two instances of
>>>> this validation problem:
>>>>
>>>> namespace <-> ownedMember
>>>> owner <-> ownedElement
>>>>
>>>>
>>> Those are definitely properly paired bidirectional opposites in
>>> UML21.ecore. They are also derived. I believe they are derived from
>>> containment references so they're sort of like a derived containment.
>>>
>>>> One of those other examples is that if I have
>>>>
>>>> + Component c
>>>> + Property p
>>>> + InterfaceRealization r
>>>>
>>>> the property is in c.ownedMembers, and the interface realization isn't.
>>>>
>>>>
>>> Now you're talking an instances though. I don't see how Ecore
>>> constraints on UML itself end up apply for an instance. UML's own
>>> constraints should apply instead.
>>>
>>>> I am wondering if this means that the UML metamodel is not consistent
>>>> with your validation rule (from [280397]): it says that ownedMember is
>>>> the opposite of namespace, but even from looking at the source (Galileo
>>>> and Helios) it is clear that the implementation of e.g. Component never
>>>> ensured this.
>>>>
>>> What makes that clear?
>>>
>>
>> Ed, I'm a bit confused by your remark about instances and constraints
>> above.
>>
>> For the example above, you can find, what I understood to be the
>> calculation of those derived sets, in
>> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>>
>> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
>> UMLPackage.COMPONENT__OWNED_RULE,
>> UMLPackage.COMPONENT__OWNED_USE_CASE,
>> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
>> UMLPackage.COMPONENT__OWNED_CONNECTOR,
>> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
>> UMLPackage.COMPONENT__OWNED_TRIGGER,
>> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
>> UMLPackage.COMPONENT__OWNED_OPERATION,
>> UMLPackage.COMPONENT__OWNED_RECEPTION,
>> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>>
>> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
>> UMLPackage.COMPONENT__OWNED_COMMENT,
>> UMLPackage.COMPONENT__NAME_EXPRESSION,
>> UMLPackage.COMPONENT__ELEMENT_IMPORT,
>> UMLPackage.COMPONENT__PACKAGE_IMPORT,
>> UMLPackage.COMPONENT__OWNED_MEMBER,
>> UMLPackage.COMPONENT__TEMPLATE_BINDING,
>> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
>> UMLPackage.COMPONENT__GENERALIZATION,
>> UMLPackage.COMPONENT__SUBSTITUTION,
>> UMLPackage.COMPONENT__COLLABORATION_USE,
>> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
>> UMLPackage.COMPONENT__REALIZATION};
>>
>> which indicates to me that interface realizations are not ownedMembers
>> (since they are explicitly listed in ownedElements, but not
>> ownedMembers, see ***) . But then I wonder how this matches with
>> ownedMember being supposedly the opposite of namespace!
>>
>>
>>> Someone in UML land will need to comment. I just don't see how Ecore's
>>> constraints end up apply to UML2 instances. Where in a UML is there an
>>> instance of EReference? Or to ask it another way, what in UML derives
>>> from EReference or reuses EReference?
>>>
>>
>> I am by no means certain where this behaviour might come from (except
>> that the UML behaviour is unchanged from Galileo to Helios). Of course
>> there's a chance that the generator that produced the above code should
>> have, well, generated something else.
>>
>> I hope you can observe the same behaviour as I do by clicking together a
>> trivial model using New->UML Model and running Validate from within the
>> UML Editor.
>>
>> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
>> explicitly e.g. in UMLValidator.validateComponent.
>>
>> Volker
>>
>>
Re: EMF bidirectional validation failing [message #548102 is a reply to message #547812] Tue, 20 July 2010 16:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: ralf.ellner.cs.fau.de

Hi,

I tried to reproduce the problem and ran into the same validation error
using a UML model like this:

+ Component c
+ Property p
+ InterfaceRealization r

According to the UML specification the association property
'InterfaceRealization::implementingClassifier' is a subset of
'Element::owner' and 'BehavioredClassifier::interfaceRealization' is a
subset of 'Element::ownedElement'. This is ok because 'Element::owner'
and 'Element::ownedElement' are opposites of each other.

Thus, it is correct that r is not contained in 'Namespace::ownedMember'
of c. However, using the OCL console one gets c as a result when
querying r for 'NamedElement::namespace'. This is obviously wrong and
leads to the validation error. The problem can be found at
NamedElementImpl#basicGetNamespace() which returns the
eInternalContainer (c) of the InterfaceRealization instead of null.

I think the same problem exists at least for 'Component::realization'
and 'ComponentRealization::abstraction'. I will open a bug for this.

Best regards, Ralf



> Hmm, this is a bit of a problem. In UML2, we assume (and have for years)
> the implicit container of an element is its owner, and the implicit
> container of a named element is also its namespace (if it's a kind of
> Namespace). In order to satisfy this new constraint, we'd either need to
> stop making this assumption and add a bunch of new subsets constraints
> to the metamodel to make it explicit, or else (perhaps more
> realistically) bypass the constraint for UML models. In any case, please
> open a bug and hopefully someone will look into it.
>
> Kenn
>
> Ed Merks wrote:
>> Volker,
>>
>> I see. I'm confusing the constraints! Doh!! :-P
>>
>> _UI_UnpairedBidirectionalReference_diagnostic is the one you're
>> referring too. In that case, I expect you're right. There's likely
>> something about UML's derivation of these features that is indeed not
>> implemented correctly and it's only by checking this constraint that
>> we find the instances aren't properly conforming to the definition of
>> the UML model. Hopefully some UML expert will comment on this.
>>
>>
>> Volker Stolz wrote:
>>> In article <i21ja2$jbo$1@build.eclipse.org>,
>>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>>
>>>
>>>>> (x-posting/f-up to .uml2)
>>>>>
>>>>> Hi Ed, I think this might be unlikely. So far I have two instances
>>>>> of this validation problem:
>>>>>
>>>>> namespace <-> ownedMember
>>>>> owner <-> ownedElement
>>>>>
>>>> Those are definitely properly paired bidirectional opposites in
>>>> UML21.ecore. They are also derived. I believe they are derived
>>>> from containment references so they're sort of like a derived
>>>> containment.
>>>>
>>>>> One of those other examples is that if I have
>>>>>
>>>>> + Component c
>>>>> + Property p
>>>>> + InterfaceRealization r
>>>>>
>>>>> the property is in c.ownedMembers, and the interface realization
>>>>> isn't.
>>>>>
>>>> Now you're talking an instances though. I don't see how Ecore
>>>> constraints on UML itself end up apply for an instance. UML's own
>>>> constraints should apply instead.
>>>>
>>>>> I am wondering if this means that the UML metamodel is not
>>>>> consistent with your validation rule (from [280397]): it says that
>>>>> ownedMember is the opposite of namespace, but even from looking at
>>>>> the source (Galileo and Helios) it is clear that the implementation
>>>>> of e.g. Component never ensured this.
>>>> What makes that clear?
>>>>
>>>
>>> Ed, I'm a bit confused by your remark about instances and constraints
>>> above.
>>>
>>> For the example above, you can find, what I understood to be the
>>> calculation of those derived sets, in
>>> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>>>
>>> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
>>> UMLPackage.COMPONENT__OWNED_RULE,
>>> UMLPackage.COMPONENT__OWNED_USE_CASE,
>>> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
>>> UMLPackage.COMPONENT__OWNED_CONNECTOR,
>>> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
>>> UMLPackage.COMPONENT__OWNED_TRIGGER,
>>> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
>>> UMLPackage.COMPONENT__OWNED_OPERATION,
>>> UMLPackage.COMPONENT__OWNED_RECEPTION,
>>> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>>>
>>> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
>>> UMLPackage.COMPONENT__OWNED_COMMENT,
>>> UMLPackage.COMPONENT__NAME_EXPRESSION,
>>> UMLPackage.COMPONENT__ELEMENT_IMPORT,
>>> UMLPackage.COMPONENT__PACKAGE_IMPORT,
>>> UMLPackage.COMPONENT__OWNED_MEMBER,
>>> UMLPackage.COMPONENT__TEMPLATE_BINDING,
>>> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
>>> UMLPackage.COMPONENT__GENERALIZATION,
>>> UMLPackage.COMPONENT__SUBSTITUTION,
>>> UMLPackage.COMPONENT__COLLABORATION_USE,
>>> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
>>> UMLPackage.COMPONENT__REALIZATION};
>>>
>>> which indicates to me that interface realizations are not
>>> ownedMembers (since they are explicitly listed in ownedElements, but
>>> not ownedMembers, see ***) . But then I wonder how this matches with
>>> ownedMember being supposedly the opposite of namespace!
>>>
>>>
>>>> Someone in UML land will need to comment. I just don't see how
>>>> Ecore's constraints end up apply to UML2 instances. Where in a UML
>>>> is there an instance of EReference? Or to ask it another way, what
>>>> in UML derives from EReference or reuses EReference?
>>>>
>>>
>>> I am by no means certain where this behaviour might come from (except
>>> that the UML behaviour is unchanged from Galileo to Helios). Of
>>> course there's a chance that the generator that produced the above
>>> code should have, well, generated something else.
>>>
>>> I hope you can observe the same behaviour as I do by clicking
>>> together a trivial model using New->UML Model and running Validate
>>> from within the UML Editor.
>>>
>>> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is
>>> called explicitly e.g. in UMLValidator.validateComponent.
>>>
>>> Volker
>>>
>>>
Re: EMF bidirectional validation failing [message #548221 is a reply to message #548102] Wed, 21 July 2010 07:27 Go to previous message
Eclipse UserFriend
Originally posted by: ralf.ellner.cs.fau.de

Hi,

Kenn already opened a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=320318

Best regards, Ralf
Re: EMF bidirectional validation failing [message #628540 is a reply to message #546499] Mon, 19 July 2010 11:33 Go to previous message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
In article <i1kd1d$69d$1@build.eclipse.org>,
Ed Merks <Ed.Merks@gmail.com> wrote:

> Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
> the complaints about source and target not being set might be the cause
> of these other problems.

(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace <-> ownedMember
owner <-> ownedElement

One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.

I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this. I double-checked with the OCL interpreter in Galileo, it
has the same result (ownedMember doesn't contain the interface
realization), so the only difference seems to be the bidirectional
validation that you added a while ago (I'm not aware of the UML
metamodel changing in the meantime as well).

For clarification, let me give this problem another spin: from looking
e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
only be included in ownedElements, but not in ownedMembers. However, the
Javadoc (presumably generated from the metamodel) says that the opposite
of namespace is ownedMember, which clearly isn't the case for
InterfaceRealization. I am wondering if your validation rule is finally
exposing a bug in the UML metamodel, where either this opposite
feature-relationship was incorrectly specified, or that the generated
code does not correctly reflect that e.g. interface realizations should
be included in ownedMembers.

I guess I'll raise a bug in MDT if nobody else has any idea (and once
I'm past my surprise that nobody else is observing this---it means that
most people are happy with UML class diagrams and don't actually venture
to component diagrams or state machines ;)

Volker

> Volker Stolz wrote:
> > In article <i1hofp$rkn$1@build.eclipse.org>,
> > Ed Merks <Ed.Merks@gmail.com> wrote:
>
> > Ed, thanks for your input. I'm using the Example EMF Model Creation
> > Wizard to create the UML model (here; as reported I get the same problem
> > with programmatically generated UML files).
> > In this case, I only stay within the editor, and there is no (separate,
> > on-disk) Ecore model (except the UML models in-memory representation).
> > There's also nothing in the Error Log, and I just checked with a fresh
> > Classic Helios and only installed the UML2Extender.
> >
> > This is the trivial model.uml (never mind the line breaks). :
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <uml:Model xmi:version="2.1"
> > xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> > xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"
> > xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint="">
> > <packagedElement xmi:type="uml:StateMachine"
> > xmi:id="_-hY4EI6MEd-MxvZKuoG_jg">
> > <region xmi:id="__yf6oI6MEd-MxvZKuoG_jg">
> > <transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg">
> > <trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/>
> > </transition>
> > </region>
> > </packagedElement>
> > </uml:Model>
> >
> > Should this better go to one of the UML groups?
> >
> > Volker

--
United Nations University -
Re: EMF bidirectional validation failing [message #628542 is a reply to message #547710] Mon, 19 July 2010 13:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090308060206020802090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Volker,

Comments below.

Volker Stolz wrote:
> In article <i1kd1d$69d$1@build.eclipse.org>,
> Ed Merks <Ed.Merks@gmail.com> wrote:
>
>
>> Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
>> the complaints about source and target not being set might be the cause
>> of these other problems.
>>
>
> (x-posting/f-up to .uml2)
>
> Hi Ed, I think this might be unlikely. So far I have two instances of
> this validation problem:
>
> namespace <-> ownedMember
> owner <-> ownedElement
>
Those are definitely properly paired bidirectional opposites in
UML21.ecore. They are also derived. I believe they are derived from
containment references so they're sort of like a derived containment.
> One of those other examples is that if I have
>
> + Component c
> + Property p
> + InterfaceRealization r
>
> the property is in c.ownedMembers, and the interface realization isn't.
>
Now you're talking an instances though. I don't see how Ecore
constraints on UML itself end up apply for an instance. UML's own
constraints should apply instead.
> I am wondering if this means that the UML metamodel is not consistent
> with your validation rule (from [280397]): it says that ownedMember is
> the opposite of namespace, but even from looking at the source (Galileo
> and Helios) it is clear that the implementation of e.g. Component never
> ensured this.
What makes that clear?
> I double-checked with the OCL interpreter in Galileo, it
> has the same result (ownedMember doesn't contain the interface
> realization), so the only difference seems to be the bidirectional
> validation that you added a while ago (I'm not aware of the UML
> metamodel changing in the meantime as well).
>
> For clarification, let me give this problem another spin: from looking
> e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
> only be included in ownedElements, but not in ownedMembers. However, the
> Javadoc (presumably generated from the metamodel) says that the opposite
> of namespace is ownedMember, which clearly isn't the case for
> InterfaceRealization. I am wondering if your validation rule is finally
> exposing a bug in the UML metamodel, where either this opposite
> feature-relationship was incorrectly specified, or that the generated
> code does not correctly reflect that e.g. interface realizations should
> be included in ownedMembers.
>
Someone in UML land will need to comment. I just don't see how Ecore's
constraints end up apply to UML2 instances. Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?
> I guess I'll raise a bug in MDT if nobody else has any idea (and once
> I'm past my surprise that nobody else is observing this---it means that
> most people are happy with UML class diagrams and don't actually venture
> to component diagrams or state machines ;)
>
> Volker
>
>
>> Volker Stolz wrote:
>>
>>> In article <i1hofp$rkn$1@build.eclipse.org>,
>>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>>
>>> Ed, thanks for your input. I'm using the Example EMF Model Creation
>>> Wizard to create the UML model (here; as reported I get the same problem
>>> with programmatically generated UML files).
>>> In this case, I only stay within the editor, and there is no (separate,
>>> on-disk) Ecore model (except the UML models in-memory representation).
>>> There's also nothing in the Error Log, and I just checked with a fresh
>>> Classic Helios and only installed the UML2Extender.
>>>
>>> This is the trivial model.uml (never mind the line breaks). :
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <uml:Model xmi:version="2.1"
>>> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>>> xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"
>>> xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint="">
>>> <packagedElement xmi:type="uml:StateMachine"
>>> xmi:id="_-hY4EI6MEd-MxvZKuoG_jg">
>>> <region xmi:id="__yf6oI6MEd-MxvZKuoG_jg">
>>> <transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg">
>>> <trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/>
>>> </transition>
>>> </region>
>>> </packagedElement>
>>> </uml:Model>
>>>
>>> Should this better go to one of the UML groups?
>>>
>>> Volker
>>>
>
>

--------------090308060206020802090103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
Comments below.<br>
<br>
Volker Stolz wrote:
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i1kd1d$69d$1@build.eclipse.org">&lt;i1kd1d$69d$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Yes, best to ask on the UML newsgroup. I haven't a clue. I wonder if
the complaints about source and target not being set might be the cause
of these other problems.
</pre>
</blockquote>
<pre wrap=""><!---->
(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace &lt;-&gt; ownedMember
owner &lt;-&gt; ownedElement
</pre>
</blockquote>
Those are definitely properly paired bidirectional opposites in
UML21.ecore.&nbsp; They are also derived.&nbsp; I believe they are derived from
containment references so they're sort of like a derived containment.<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.
</pre>
</blockquote>
Now you're talking an instances though.&nbsp; I don't see how Ecore
constraints on UML itself end up apply for an instance.&nbsp; UML's own
constraints should apply instead.<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this. </pre>
</blockquote>
What makes that clear?<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">I double-checked with the OCL interpreter in Galileo, it
has the same result (ownedMember doesn't contain the interface
realization), so the only difference seems to be the bidirectional
validation that you added a while ago (I'm not aware of the UML
metamodel changing in the meantime as well).

For clarification, let me give this problem another spin: from looking
e.g. at ComponentImpl, it is obvious that the InterfaceRealization will
only be included in ownedElements, but not in ownedMembers. However, the
Javadoc (presumably generated from the metamodel) says that the opposite
of namespace is ownedMember, which clearly isn't the case for
InterfaceRealization. I am wondering if your validation rule is finally
exposing a bug in the UML metamodel, where either this opposite
feature-relationship was incorrectly specified, or that the generated
code does not correctly reflect that e.g. interface realizations should
be included in ownedMembers.
</pre>
</blockquote>
Someone in UML land will need to comment.&nbsp; I just don't see how Ecore's
constraints end up apply to UML2 instances.&nbsp; Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?<br>
<blockquote cite="mid:vs-3DDC6F.13330319072010@news.eclipse.org"
type="cite">
<pre wrap="">
I guess I'll raise a bug in MDT if nobody else has any idea (and once
I'm past my surprise that nobody else is observing this---it means that
most people are happy with UML class diagrams and don't actually venture
to component diagrams or state machines ;)

Volker

</pre>
<blockquote type="cite">
<pre wrap="">Volker Stolz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i1hofp$rkn$1@build.eclipse.org">&lt;i1hofp$rkn$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Ed, thanks for your input. I'm using the Example EMF Model Creation
Wizard to create the UML model (here; as reported I get the same problem
with programmatically generated UML files).
In this case, I only stay within the editor, and there is no (separate,
on-disk) Ecore model (except the UML models in-memory representation).
There's also nothing in the Error Log, and I just checked with a fresh
Classic Helios and only installed the UML2Extender.

This is the trivial model.uml (never mind the line breaks). :

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;uml:Model xmi:version="2.1"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://schema.omg.org/spec/XMI/2.1">"http://schema.omg.org/spec/XMI/2.1"</a>
xmlns:uml=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/uml2/3.0.0/UML">"http://www.eclipse.org/uml2/3.0.0/UML"</a>
xmi:id="_89dnMI6MEd-MxvZKuoG_jg" viewpoint=""&gt;
&lt;packagedElement xmi:type="uml:StateMachine"
xmi:id="_-hY4EI6MEd-MxvZKuoG_jg"&gt;
&lt;region xmi:id="__yf6oI6MEd-MxvZKuoG_jg"&gt;
&lt;transition xmi:id="_ArWOMI6NEd-MxvZKuoG_jg"&gt;
&lt;trigger xmi:id="_Ba40wI6NEd-MxvZKuoG_jg"/&gt;
&lt;/transition&gt;
&lt;/region&gt;
&lt;/packagedElement&gt;
&lt;/uml:Model&gt;

Should this better go to one of the UML groups?

Volker
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------090308060206020802090103--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF bidirectional validation failing [message #628543 is a reply to message #547721] Mon, 19 July 2010 14:50 Go to previous message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
In article <i21ja2$jbo$1@build.eclipse.org>,
Ed Merks <Ed.Merks@gmail.com> wrote:

> > (x-posting/f-up to .uml2)
> >
> > Hi Ed, I think this might be unlikely. So far I have two instances of
> > this validation problem:
> >
> > namespace <-> ownedMember
> > owner <-> ownedElement
> >
> Those are definitely properly paired bidirectional opposites in
> UML21.ecore. They are also derived. I believe they are derived from
> containment references so they're sort of like a derived containment.
> > One of those other examples is that if I have
> >
> > + Component c
> > + Property p
> > + InterfaceRealization r
> >
> > the property is in c.ownedMembers, and the interface realization isn't.
> >
> Now you're talking an instances though. I don't see how Ecore
> constraints on UML itself end up apply for an instance. UML's own
> constraints should apply instead.
> > I am wondering if this means that the UML metamodel is not consistent
> > with your validation rule (from [280397]): it says that ownedMember is
> > the opposite of namespace, but even from looking at the source (Galileo
> > and Helios) it is clear that the implementation of e.g. Component never
> > ensured this.
> What makes that clear?

Ed, I'm a bit confused by your remark about instances and constraints
above.

For the example above, you can find, what I understood to be the
calculation of those derived sets, in
org.eclipse.uml2.uml.internal.impl.ComponentImpl:

protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_RULE,
UMLPackage.COMPONENT__OWNED_USE_CASE,
UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
UMLPackage.COMPONENT__OWNED_CONNECTOR,
UMLPackage.COMPONENT__OWNED_BEHAVIOR,
UMLPackage.COMPONENT__OWNED_TRIGGER,
UMLPackage.COMPONENT__NESTED_CLASSIFIER,
UMLPackage.COMPONENT__OWNED_OPERATION,
UMLPackage.COMPONENT__OWNED_RECEPTION,
UMLPackage.COMPONENT__PACKAGED_ELEMENT};

protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_COMMENT,
UMLPackage.COMPONENT__NAME_EXPRESSION,
UMLPackage.COMPONENT__ELEMENT_IMPORT,
UMLPackage.COMPONENT__PACKAGE_IMPORT,
UMLPackage.COMPONENT__OWNED_MEMBER,
UMLPackage.COMPONENT__TEMPLATE_BINDING,
UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
UMLPackage.COMPONENT__GENERALIZATION,
UMLPackage.COMPONENT__SUBSTITUTION,
UMLPackage.COMPONENT__COLLABORATION_USE,
*** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
UMLPackage.COMPONENT__REALIZATION};

which indicates to me that interface realizations are not ownedMembers
(since they are explicitly listed in ownedElements, but not
ownedMembers, see ***) . But then I wonder how this matches with
ownedMember being supposedly the opposite of namespace!

> Someone in UML land will need to comment. I just don't see how Ecore's
> constraints end up apply to UML2 instances. Where in a UML is there an
> instance of EReference? Or to ask it another way, what in UML derives
> from EReference or reuses EReference?

I am by no means certain where this behaviour might come from (except
that the UML behaviour is unchanged from Galileo to Helios). Of course
there's a chance that the generator that produced the above code should
have, well, generated something else.

I hope you can observe the same behaviour as I do by clicking together a
trivial model using New->UML Model and running Validate from within the
UML Editor.

EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
explicitly e.g. in UMLValidator.validateComponent.

Volker

--
United Nations University -
Re: EMF bidirectional validation failing [message #628544 is a reply to message #547760] Mon, 19 July 2010 15:12 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020807010204060803010306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Volker,

I see. I'm confusing the constraints! Doh!! :-P

_UI_UnpairedBidirectionalReference_diagnostic is the one you're
referring too. In that case, I expect you're right. There's likely
something about UML's derivation of these features that is indeed not
implemented correctly and it's only by checking this constraint that we
find the instances aren't properly conforming to the definition of the
UML model. Hopefully some UML expert will comment on this.


Volker Stolz wrote:
> In article <i21ja2$jbo$1@build.eclipse.org>,
> Ed Merks <Ed.Merks@gmail.com> wrote:
>
>
>>> (x-posting/f-up to .uml2)
>>>
>>> Hi Ed, I think this might be unlikely. So far I have two instances of
>>> this validation problem:
>>>
>>> namespace <-> ownedMember
>>> owner <-> ownedElement
>>>
>>>
>> Those are definitely properly paired bidirectional opposites in
>> UML21.ecore. They are also derived. I believe they are derived from
>> containment references so they're sort of like a derived containment.
>>
>>> One of those other examples is that if I have
>>>
>>> + Component c
>>> + Property p
>>> + InterfaceRealization r
>>>
>>> the property is in c.ownedMembers, and the interface realization isn't.
>>>
>>>
>> Now you're talking an instances though. I don't see how Ecore
>> constraints on UML itself end up apply for an instance. UML's own
>> constraints should apply instead.
>>
>>> I am wondering if this means that the UML metamodel is not consistent
>>> with your validation rule (from [280397]): it says that ownedMember is
>>> the opposite of namespace, but even from looking at the source (Galileo
>>> and Helios) it is clear that the implementation of e.g. Component never
>>> ensured this.
>>>
>> What makes that clear?
>>
>
> Ed, I'm a bit confused by your remark about instances and constraints
> above.
>
> For the example above, you can find, what I understood to be the
> calculation of those derived sets, in
> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>
> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
> UMLPackage.COMPONENT__OWNED_RULE,
> UMLPackage.COMPONENT__OWNED_USE_CASE,
> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
> UMLPackage.COMPONENT__OWNED_CONNECTOR,
> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
> UMLPackage.COMPONENT__OWNED_TRIGGER,
> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
> UMLPackage.COMPONENT__OWNED_OPERATION,
> UMLPackage.COMPONENT__OWNED_RECEPTION,
> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>
> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
> UMLPackage.COMPONENT__OWNED_COMMENT,
> UMLPackage.COMPONENT__NAME_EXPRESSION,
> UMLPackage.COMPONENT__ELEMENT_IMPORT,
> UMLPackage.COMPONENT__PACKAGE_IMPORT,
> UMLPackage.COMPONENT__OWNED_MEMBER,
> UMLPackage.COMPONENT__TEMPLATE_BINDING,
> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
> UMLPackage.COMPONENT__GENERALIZATION,
> UMLPackage.COMPONENT__SUBSTITUTION,
> UMLPackage.COMPONENT__COLLABORATION_USE,
> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
> UMLPackage.COMPONENT__REALIZATION};
>
> which indicates to me that interface realizations are not ownedMembers
> (since they are explicitly listed in ownedElements, but not
> ownedMembers, see ***) . But then I wonder how this matches with
> ownedMember being supposedly the opposite of namespace!
>
>
>> Someone in UML land will need to comment. I just don't see how Ecore's
>> constraints end up apply to UML2 instances. Where in a UML is there an
>> instance of EReference? Or to ask it another way, what in UML derives
>> from EReference or reuses EReference?
>>
>
> I am by no means certain where this behaviour might come from (except
> that the UML behaviour is unchanged from Galileo to Helios). Of course
> there's a chance that the generator that produced the above code should
> have, well, generated something else.
>
> I hope you can observe the same behaviour as I do by clicking together a
> trivial model using New->UML Model and running Validate from within the
> UML Editor.
>
> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
> explicitly e.g. in UMLValidator.validateComponent.
>
> Volker
>
>

--------------020807010204060803010306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
I see.&nbsp; I'm confusing the constraints!&nbsp; Doh!! :-P<br>
<br>
_UI_UnpairedBidirectionalReference_diagnostic is the one you're
referring too.&nbsp; In that case, I expect you're right.&nbsp; There's likely
something about UML's derivation of these features that is indeed not
implemented correctly and it's only by checking this constraint that we
find the instances aren't properly conforming to the definition of the
UML model.&nbsp;&nbsp; Hopefully some UML expert will comment on this.<br>
<br>
<br>
Volker Stolz wrote:
<blockquote cite="mid:vs-950039.16503319072010@news.eclipse.org"
type="cite">
<pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:i21ja2$jbo$1@build.eclipse.org">&lt;i21ja2$jbo$1@build.eclipse.org&gt;</a>,
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(x-posting/f-up to .uml2)

Hi Ed, I think this might be unlikely. So far I have two instances of
this validation problem:

namespace &lt;-&gt; ownedMember
owner &lt;-&gt; ownedElement

</pre>
</blockquote>
<pre wrap="">Those are definitely properly paired bidirectional opposites in
UML21.ecore. They are also derived. I believe they are derived from
containment references so they're sort of like a derived containment.
</pre>
<blockquote type="cite">
<pre wrap="">One of those other examples is that if I have

+ Component c
+ Property p
+ InterfaceRealization r

the property is in c.ownedMembers, and the interface realization isn't.

</pre>
</blockquote>
<pre wrap="">Now you're talking an instances though. I don't see how Ecore
constraints on UML itself end up apply for an instance. UML's own
constraints should apply instead.
</pre>
<blockquote type="cite">
<pre wrap="">I am wondering if this means that the UML metamodel is not consistent
with your validation rule (from [280397]): it says that ownedMember is
the opposite of namespace, but even from looking at the source (Galileo
and Helios) it is clear that the implementation of e.g. Component never
ensured this.
</pre>
</blockquote>
<pre wrap="">What makes that clear?
</pre>
</blockquote>
<pre wrap=""><!---->
Ed, I'm a bit confused by your remark about instances and constraints
above.

For the example above, you can find, what I understood to be the
calculation of those derived sets, in
org.eclipse.uml2.uml.internal.impl.ComponentImpl:

protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_RULE,
UMLPackage.COMPONENT__OWNED_USE_CASE,
UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
UMLPackage.COMPONENT__OWNED_CONNECTOR,
UMLPackage.COMPONENT__OWNED_BEHAVIOR,
UMLPackage.COMPONENT__OWNED_TRIGGER,
UMLPackage.COMPONENT__NESTED_CLASSIFIER,
UMLPackage.COMPONENT__OWNED_OPERATION,
UMLPackage.COMPONENT__OWNED_RECEPTION,
UMLPackage.COMPONENT__PACKAGED_ELEMENT};

protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
UMLPackage.COMPONENT__OWNED_COMMENT,
UMLPackage.COMPONENT__NAME_EXPRESSION,
UMLPackage.COMPONENT__ELEMENT_IMPORT,
UMLPackage.COMPONENT__PACKAGE_IMPORT,
UMLPackage.COMPONENT__OWNED_MEMBER,
UMLPackage.COMPONENT__TEMPLATE_BINDING,
UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
UMLPackage.COMPONENT__GENERALIZATION,
UMLPackage.COMPONENT__SUBSTITUTION,
UMLPackage.COMPONENT__COLLABORATION_USE,
*** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
UMLPackage.COMPONENT__REALIZATION};

which indicates to me that interface realizations are not ownedMembers
(since they are explicitly listed in ownedElements, but not
ownedMembers, see ***) . But then I wonder how this matches with
ownedMember being supposedly the opposite of namespace!

</pre>
<blockquote type="cite">
<pre wrap="">Someone in UML land will need to comment. I just don't see how Ecore's
constraints end up apply to UML2 instances. Where in a UML is there an
instance of EReference? Or to ask it another way, what in UML derives
from EReference or reuses EReference?
</pre>
</blockquote>
<pre wrap=""><!---->
I am by no means certain where this behaviour might come from (except
that the UML behaviour is unchanged from Galileo to Helios). Of course
there's a chance that the generator that produced the above code should
have, well, generated something else.

I hope you can observe the same behaviour as I do by clicking together a
trivial model using New-&gt;UML Model and running Validate from within the
UML Editor.

EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
explicitly e.g. in UMLValidator.validateComponent.

Volker

</pre>
</blockquote>
</body>
</html>

--------------020807010204060803010306--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF bidirectional validation failing [message #628547 is a reply to message #547779] Mon, 19 July 2010 16:21 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Hmm, this is a bit of a problem. In UML2, we assume (and have for years)
the implicit container of an element is its owner, and the implicit
container of a named element is also its namespace (if it's a kind of
Namespace). In order to satisfy this new constraint, we'd either need to
stop making this assumption and add a bunch of new subsets constraints
to the metamodel to make it explicit, or else (perhaps more
realistically) bypass the constraint for UML models. In any case, please
open a bug and hopefully someone will look into it.

Kenn

Ed Merks wrote:
> Volker,
>
> I see. I'm confusing the constraints! Doh!! :-P
>
> _UI_UnpairedBidirectionalReference_diagnostic is the one you're
> referring too. In that case, I expect you're right. There's likely
> something about UML's derivation of these features that is indeed not
> implemented correctly and it's only by checking this constraint that we
> find the instances aren't properly conforming to the definition of the
> UML model. Hopefully some UML expert will comment on this.
>
>
> Volker Stolz wrote:
>> In article <i21ja2$jbo$1@build.eclipse.org>,
>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>
>>
>>>> (x-posting/f-up to .uml2)
>>>>
>>>> Hi Ed, I think this might be unlikely. So far I have two instances of
>>>> this validation problem:
>>>>
>>>> namespace <-> ownedMember
>>>> owner <-> ownedElement
>>>>
>>>>
>>> Those are definitely properly paired bidirectional opposites in
>>> UML21.ecore. They are also derived. I believe they are derived from
>>> containment references so they're sort of like a derived containment.
>>>
>>>> One of those other examples is that if I have
>>>>
>>>> + Component c
>>>> + Property p
>>>> + InterfaceRealization r
>>>>
>>>> the property is in c.ownedMembers, and the interface realization isn't.
>>>>
>>>>
>>> Now you're talking an instances though. I don't see how Ecore
>>> constraints on UML itself end up apply for an instance. UML's own
>>> constraints should apply instead.
>>>
>>>> I am wondering if this means that the UML metamodel is not consistent
>>>> with your validation rule (from [280397]): it says that ownedMember is
>>>> the opposite of namespace, but even from looking at the source (Galileo
>>>> and Helios) it is clear that the implementation of e.g. Component never
>>>> ensured this.
>>>>
>>> What makes that clear?
>>>
>>
>> Ed, I'm a bit confused by your remark about instances and constraints
>> above.
>>
>> For the example above, you can find, what I understood to be the
>> calculation of those derived sets, in
>> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>>
>> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
>> UMLPackage.COMPONENT__OWNED_RULE,
>> UMLPackage.COMPONENT__OWNED_USE_CASE,
>> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
>> UMLPackage.COMPONENT__OWNED_CONNECTOR,
>> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
>> UMLPackage.COMPONENT__OWNED_TRIGGER,
>> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
>> UMLPackage.COMPONENT__OWNED_OPERATION,
>> UMLPackage.COMPONENT__OWNED_RECEPTION,
>> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>>
>> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
>> UMLPackage.COMPONENT__OWNED_COMMENT,
>> UMLPackage.COMPONENT__NAME_EXPRESSION,
>> UMLPackage.COMPONENT__ELEMENT_IMPORT,
>> UMLPackage.COMPONENT__PACKAGE_IMPORT,
>> UMLPackage.COMPONENT__OWNED_MEMBER,
>> UMLPackage.COMPONENT__TEMPLATE_BINDING,
>> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
>> UMLPackage.COMPONENT__GENERALIZATION,
>> UMLPackage.COMPONENT__SUBSTITUTION,
>> UMLPackage.COMPONENT__COLLABORATION_USE,
>> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
>> UMLPackage.COMPONENT__REALIZATION};
>>
>> which indicates to me that interface realizations are not ownedMembers
>> (since they are explicitly listed in ownedElements, but not
>> ownedMembers, see ***) . But then I wonder how this matches with
>> ownedMember being supposedly the opposite of namespace!
>>
>>
>>> Someone in UML land will need to comment. I just don't see how Ecore's
>>> constraints end up apply to UML2 instances. Where in a UML is there an
>>> instance of EReference? Or to ask it another way, what in UML derives
>>> from EReference or reuses EReference?
>>>
>>
>> I am by no means certain where this behaviour might come from (except
>> that the UML behaviour is unchanged from Galileo to Helios). Of course
>> there's a chance that the generator that produced the above code should
>> have, well, generated something else.
>>
>> I hope you can observe the same behaviour as I do by clicking together a
>> trivial model using New->UML Model and running Validate from within the
>> UML Editor.
>>
>> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is called
>> explicitly e.g. in UMLValidator.validateComponent.
>>
>> Volker
>>
>>
Re: EMF bidirectional validation failing [message #628551 is a reply to message #547812] Tue, 20 July 2010 16:17 Go to previous message
Eclipse UserFriend
Originally posted by: ralf.ellner.cs.fau.de

Hi,

I tried to reproduce the problem and ran into the same validation error
using a UML model like this:

+ Component c
+ Property p
+ InterfaceRealization r

According to the UML specification the association property
'InterfaceRealization::implementingClassifier' is a subset of
'Element::owner' and 'BehavioredClassifier::interfaceRealization' is a
subset of 'Element::ownedElement'. This is ok because 'Element::owner'
and 'Element::ownedElement' are opposites of each other.

Thus, it is correct that r is not contained in 'Namespace::ownedMember'
of c. However, using the OCL console one gets c as a result when
querying r for 'NamedElement::namespace'. This is obviously wrong and
leads to the validation error. The problem can be found at
NamedElementImpl#basicGetNamespace() which returns the
eInternalContainer (c) of the InterfaceRealization instead of null.

I think the same problem exists at least for 'Component::realization'
and 'ComponentRealization::abstraction'. I will open a bug for this.

Best regards, Ralf



> Hmm, this is a bit of a problem. In UML2, we assume (and have for years)
> the implicit container of an element is its owner, and the implicit
> container of a named element is also its namespace (if it's a kind of
> Namespace). In order to satisfy this new constraint, we'd either need to
> stop making this assumption and add a bunch of new subsets constraints
> to the metamodel to make it explicit, or else (perhaps more
> realistically) bypass the constraint for UML models. In any case, please
> open a bug and hopefully someone will look into it.
>
> Kenn
>
> Ed Merks wrote:
>> Volker,
>>
>> I see. I'm confusing the constraints! Doh!! :-P
>>
>> _UI_UnpairedBidirectionalReference_diagnostic is the one you're
>> referring too. In that case, I expect you're right. There's likely
>> something about UML's derivation of these features that is indeed not
>> implemented correctly and it's only by checking this constraint that
>> we find the instances aren't properly conforming to the definition of
>> the UML model. Hopefully some UML expert will comment on this.
>>
>>
>> Volker Stolz wrote:
>>> In article <i21ja2$jbo$1@build.eclipse.org>,
>>> Ed Merks <Ed.Merks@gmail.com> wrote:
>>>
>>>
>>>>> (x-posting/f-up to .uml2)
>>>>>
>>>>> Hi Ed, I think this might be unlikely. So far I have two instances
>>>>> of this validation problem:
>>>>>
>>>>> namespace <-> ownedMember
>>>>> owner <-> ownedElement
>>>>>
>>>> Those are definitely properly paired bidirectional opposites in
>>>> UML21.ecore. They are also derived. I believe they are derived
>>>> from containment references so they're sort of like a derived
>>>> containment.
>>>>
>>>>> One of those other examples is that if I have
>>>>>
>>>>> + Component c
>>>>> + Property p
>>>>> + InterfaceRealization r
>>>>>
>>>>> the property is in c.ownedMembers, and the interface realization
>>>>> isn't.
>>>>>
>>>> Now you're talking an instances though. I don't see how Ecore
>>>> constraints on UML itself end up apply for an instance. UML's own
>>>> constraints should apply instead.
>>>>
>>>>> I am wondering if this means that the UML metamodel is not
>>>>> consistent with your validation rule (from [280397]): it says that
>>>>> ownedMember is the opposite of namespace, but even from looking at
>>>>> the source (Galileo and Helios) it is clear that the implementation
>>>>> of e.g. Component never ensured this.
>>>> What makes that clear?
>>>>
>>>
>>> Ed, I'm a bit confused by your remark about instances and constraints
>>> above.
>>>
>>> For the example above, you can find, what I understood to be the
>>> calculation of those derived sets, in
>>> org.eclipse.uml2.uml.internal.impl.ComponentImpl:
>>>
>>> protected static final int[] OWNED_MEMBER_ESUBSETS = new int[]{
>>> UMLPackage.COMPONENT__OWNED_RULE,
>>> UMLPackage.COMPONENT__OWNED_USE_CASE,
>>> UMLPackage.COMPONENT__OWNED_ATTRIBUTE,
>>> UMLPackage.COMPONENT__OWNED_CONNECTOR,
>>> UMLPackage.COMPONENT__OWNED_BEHAVIOR,
>>> UMLPackage.COMPONENT__OWNED_TRIGGER,
>>> UMLPackage.COMPONENT__NESTED_CLASSIFIER,
>>> UMLPackage.COMPONENT__OWNED_OPERATION,
>>> UMLPackage.COMPONENT__OWNED_RECEPTION,
>>> UMLPackage.COMPONENT__PACKAGED_ELEMENT};
>>>
>>> protected static final int[] OWNED_ELEMENT_ESUBSETS = new int[]{
>>> UMLPackage.COMPONENT__OWNED_COMMENT,
>>> UMLPackage.COMPONENT__NAME_EXPRESSION,
>>> UMLPackage.COMPONENT__ELEMENT_IMPORT,
>>> UMLPackage.COMPONENT__PACKAGE_IMPORT,
>>> UMLPackage.COMPONENT__OWNED_MEMBER,
>>> UMLPackage.COMPONENT__TEMPLATE_BINDING,
>>> UMLPackage.COMPONENT__OWNED_TEMPLATE_SIGNATURE,
>>> UMLPackage.COMPONENT__GENERALIZATION,
>>> UMLPackage.COMPONENT__SUBSTITUTION,
>>> UMLPackage.COMPONENT__COLLABORATION_USE,
>>> *** UMLPackage.COMPONENT__INTERFACE_REALIZATION,
>>> UMLPackage.COMPONENT__REALIZATION};
>>>
>>> which indicates to me that interface realizations are not
>>> ownedMembers (since they are explicitly listed in ownedElements, but
>>> not ownedMembers, see ***) . But then I wonder how this matches with
>>> ownedMember being supposedly the opposite of namespace!
>>>
>>>
>>>> Someone in UML land will need to comment. I just don't see how
>>>> Ecore's constraints end up apply to UML2 instances. Where in a UML
>>>> is there an instance of EReference? Or to ask it another way, what
>>>> in UML derives from EReference or reuses EReference?
>>>>
>>>
>>> I am by no means certain where this behaviour might come from (except
>>> that the UML behaviour is unchanged from Galileo to Helios). Of
>>> course there's a chance that the generator that produced the above
>>> code should have, well, generated something else.
>>>
>>> I hope you can observe the same behaviour as I do by clicking
>>> together a trivial model using New->UML Model and running Validate
>>> from within the UML Editor.
>>>
>>> EObjectValidator.validate_EveryBidirectionalReferenceIsPaire d is
>>> called explicitly e.g. in UMLValidator.validateComponent.
>>>
>>> Volker
>>>
>>>
Re: EMF bidirectional validation failing [message #628553 is a reply to message #548102] Wed, 21 July 2010 07:27 Go to previous message
Eclipse UserFriend
Originally posted by: ralf.ellner.cs.fau.de

Hi,

Kenn already opened a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=320318

Best regards, Ralf
Previous Topic:Dynamic UML
Next Topic:UML 2.0.0 metamodel to UML 2.1.0 metamodel
Goto Forum:
  


Current Time: Thu Mar 28 09:30:19 GMT 2024

Powered by FUDForum. Page generated in 0.04664 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top