Eclipse Community Forums: UML2 » UML2 vs EMF generated code difference

Help

Home

Home » Modeling » UML2 » UML2 vs EMF generated code difference

Show: Today's Messages :: Show Polls :: Message Navigator

UML2 vs EMF generated code difference [message #477266]

Thu, 17 April 2008 19:19

Vladimir Hirsl

Messages: 10
Registered: July 2009

Junior Member

Hi,
I recently converted a meta model specified in EMF into a UML meta
model. When regenerating the code from the UML-ized model I noticed
changes in generated code for 'eInverseRemove' methods, and in some
cases they were completely absent.

After some investigation it turned out that UML code generator did not
generate case statements for derived features. Eventually I traced it
down to differences in GenFeatureFilter-s applied to
GenClassImpl.getEInverseRemoveGenFeatures method.

In EMF the filter's accept method looks like this:
public boolean accept(GenFeature genFeature)
{
return genFeature.isEffectiveContains() ||
(genFeature.isBidirectional() &&
(!genFeature.getReverse().isVolatile() ||
genFeature.getReverse().hasDelegateFeature())) ||
genFeature.isFeatureMapType();
}

while in UML2 it looks like this:
public boolean accept(GenFeature genFeature) {
return !genFeature.isDerived();
}

Why the different treatment of derived features in EMF and UML? Why is
it unacceptable to 'inverse remove' a derived feature in UML?

Thanks,
Vmir

Report message to a moderator

Re: UML2 vs EMF generated code difference [message #477275 is a reply to message #477266]

Mon, 21 April 2008 17:07

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

Vmir,

The values of derived properties are typically obtained (computed) from the
values of other (non-derived) properties. Since such features are also
typically volatile and because the UML2 code generator can't assume how this
computation takes place, it does not generate handshaking code for them by
default (it's easier to add such behavior than to take it out). Do you have
a use case where hand-shaking code is needed for a derived feature (in the
UML metamodel, it is not)?

Kenn

"Vladimir Hirsl" <vladimirh@edgewater.ca> wrote in message
news:fu87ss$nav$1@build.eclipse.org...
> Hi,
> I recently converted a meta model specified in EMF into a UML meta model.
> When regenerating the code from the UML-ized model I noticed changes in
> generated code for 'eInverseRemove' methods, and in some cases they were
> completely absent.
>
> After some investigation it turned out that UML code generator did not
> generate case statements for derived features. Eventually I traced it down
> to differences in GenFeatureFilter-s applied to
> GenClassImpl.getEInverseRemoveGenFeatures method.
>
> In EMF the filter's accept method looks like this:
> public boolean accept(GenFeature genFeature)
> {
> return genFeature.isEffectiveContains() ||
> (genFeature.isBidirectional() &&
> (!genFeature.getReverse().isVolatile() ||
> genFeature.getReverse().hasDelegateFeature())) ||
> genFeature.isFeatureMapType();
> }
>
> while in UML2 it looks like this:
> public boolean accept(GenFeature genFeature) {
> return !genFeature.isDerived();
> }
>
> Why the different treatment of derived features in EMF and UML? Why is it
> unacceptable to 'inverse remove' a derived feature in UML?
>
> Thanks,
> Vmir

Report message to a moderator

Re: UML2 vs EMF generated code difference [message #477286 is a reply to message #477275]

Mon, 28 April 2008 14:56

Vladimir Hirsl

Messages: 10
Registered: July 2009

Junior Member

Hi Kenn,
thanks for your reply.

My derived features are contained, volatile, transient and changeable
and they delegate to features of contained objects. They are really just
a different name for existing features. I expect that they should behave
the same way original features do. The reason I need them is partly for
GMF diagram tools to generate diagram code that requires less customization.

I did not understand if the difference in generated code is due to the
changed semantics of derived features in UML or due to code generation
optimization. If it is the latter I guess there should be an option in a
UML genmodel to turn the optimization on/off.

Thanks,
Vmir

Kenn Hussey wrote:
> Vmir,
>
> The values of derived properties are typically obtained (computed) from the
> values of other (non-derived) properties. Since such features are also
> typically volatile and because the UML2 code generator can't assume how this
> computation takes place, it does not generate handshaking code for them by
> default (it's easier to add such behavior than to take it out). Do you have
> a use case where hand-shaking code is needed for a derived feature (in the
> UML metamodel, it is not)?
>
> Kenn
>
> "Vladimir Hirsl" <vladimirh@edgewater.ca> wrote in message
> news:fu87ss$nav$1@build.eclipse.org...
>
>> Hi,
>> I recently converted a meta model specified in EMF into a UML meta model.
>> When regenerating the code from the UML-ized model I noticed changes in
>> generated code for 'eInverseRemove' methods, and in some cases they were
>> completely absent.
>>
>> After some investigation it turned out that UML code generator did not
>> generate case statements for derived features. Eventually I traced it down
>> to differences in GenFeatureFilter-s applied to
>> GenClassImpl.getEInverseRemoveGenFeatures method.
>>
>> In EMF the filter's accept method looks like this:
>> public boolean accept(GenFeature genFeature)
>> {
>> return genFeature.isEffectiveContains() ||
>> (genFeature.isBidirectional() &&
>> (!genFeature.getReverse().isVolatile() ||
>> genFeature.getReverse().hasDelegateFeature())) ||
>> genFeature.isFeatureMapType();
>> }
>>
>> while in UML2 it looks like this:
>> public boolean accept(GenFeature genFeature) {
>> return !genFeature.isDerived();
>> }
>>
>> Why the different treatment of derived features in EMF and UML? Why is it
>> unacceptable to 'inverse remove' a derived feature in UML?
>>
>> Thanks,
>> Vmir
>>
>
>
>

Report message to a moderator

Re: UML2 vs EMF generated code difference [message #477291 is a reply to message #477286]

Tue, 29 April 2008 14:11

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

Vladimir,

The opposites of derived features should generally be derived; if you change
the value of the derived feature on one side, it will update the feature on
which it depends, and that feature, assuming it has an opposite, will update
its opposite per the usual handshaking mechanism and in turn the opposite
derived feature should be updated with the new value. The difference is that
no events will be fired for the change of the opposite derived feature's
value, and I suspect that this is really the issue - if you're using these
derived features as the basis for GMF diagrams, you'll need all events. So,
you'll need to ensure that the list implementation you're using for these
derived, volatile features are firing all the expected events...

Kenn

"Vladimir Hirsl" <vladimirh@edgewater.ca> wrote in message
news:fv4oib$s2s$1@build.eclipse.org...
> Hi Kenn,
> thanks for your reply.
>
> My derived features are contained, volatile, transient and changeable and
> they delegate to features of contained objects. They are really just a
> different name for existing features. I expect that they should behave the
> same way original features do. The reason I need them is partly for GMF
> diagram tools to generate diagram code that requires less customization.
>
> I did not understand if the difference in generated code is due to the
> changed semantics of derived features in UML or due to code generation
> optimization. If it is the latter I guess there should be an option in a
> UML genmodel to turn the optimization on/off.
>
> Thanks,
> Vmir
>
> Kenn Hussey wrote:
>> Vmir,
>>
>> The values of derived properties are typically obtained (computed) from
>> the values of other (non-derived) properties. Since such features are
>> also typically volatile and because the UML2 code generator can't assume
>> how this computation takes place, it does not generate handshaking code
>> for them by default (it's easier to add such behavior than to take it
>> out). Do you have a use case where hand-shaking code is needed for a
>> derived feature (in the UML metamodel, it is not)?
>>
>> Kenn
>>
>> "Vladimir Hirsl" <vladimirh@edgewater.ca> wrote in message
>> news:fu87ss$nav$1@build.eclipse.org...
>>
>>> Hi,
>>> I recently converted a meta model specified in EMF into a UML meta
>>> model. When regenerating the code from the UML-ized model I noticed
>>> changes in generated code for 'eInverseRemove' methods, and in some
>>> cases they were completely absent.
>>>
>>> After some investigation it turned out that UML code generator did not
>>> generate case statements for derived features. Eventually I traced it
>>> down to differences in GenFeatureFilter-s applied to
>>> GenClassImpl.getEInverseRemoveGenFeatures method.
>>>
>>> In EMF the filter's accept method looks like this:
>>> public boolean accept(GenFeature genFeature)
>>> {
>>> return genFeature.isEffectiveContains() ||
>>> (genFeature.isBidirectional() &&
>>> (!genFeature.getReverse().isVolatile() ||
>>> genFeature.getReverse().hasDelegateFeature())) ||
>>> genFeature.isFeatureMapType();
>>> }
>>>
>>> while in UML2 it looks like this:
>>> public boolean accept(GenFeature genFeature) {
>>> return !genFeature.isDerived();
>>> }
>>>
>>> Why the different treatment of derived features in EMF and UML? Why is
>>> it unacceptable to 'inverse remove' a derived feature in UML?
>>>
>>> Thanks,
>>> Vmir
>>
>>
>>

Report message to a moderator