Eclipse Community Forums: UML2 » Re: UML -> Ecore (Derived + Composite)

Help

Home

Home » Modeling » UML2 » Re: UML -> Ecore (Derived + Composite)

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

Re: UML -> Ecore (Derived + Composite) [message #478412]

Tue, 19 May 2009 05:17

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

JT,

Yes, the UML converter is intentionally designed to do that. Best to
ask about it on the UML newsgroup which I've added to the "to" list of
the reply.

John T.E. Timm wrote:
> In attempting to recreate the Supplier / PurchaseOrder example from
> "EMF FeatureMaps", I ran into an issue where if I define a property in
> UML to be Composite and Derived, only derived is carried through to
> Ecore (during model import) which causes problems in serialization. If
> I change this attribute in the resulting Ecore after import,
> serialization works fine. From the article, preferredOrders and
> standardOrders should be composite, derived, transient, volatile,
> ordered, and unique.
>
> Thanks,
>
> JT
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: UML -> Ecore (Derived + Composite) [message #478413 is a reply to message #478412]

Tue, 19 May 2009 05:56

John T.E. Timm

Messages: 161
Registered: July 2009

Senior Member

Ed:

If this is the case, then it would appear that the round-trip between UML
and EMF is inconsistent. If I set derived and containment on the Ecore
model and export to UML, then I get derived and composite on the UML
model. However, if I set derived and composite on the UML model and import
back into EMF, then I do not get derived and containment set on the Ecore
model. I guess I will have to do some post-processing on the Ecore model
to accommodate our particular application.

Thanks,

JT

Ed Merks wrote:

> JT,

> Yes, the UML converter is intentionally designed to do that. Best to
> ask about it on the UML newsgroup which I've added to the "to" list of
> the reply.

> John T.E. Timm wrote:
>> In attempting to recreate the Supplier / PurchaseOrder example from
>> "EMF FeatureMaps", I ran into an issue where if I define a property in
>> UML to be Composite and Derived, only derived is carried through to
>> Ecore (during model import) which causes problems in serialization. If
>> I change this attribute in the resulting Ecore after import,
>> serialization works fine. From the article, preferredOrders and
>> standardOrders should be composite, derived, transient, volatile,
>> ordered, and unique.
>>
>> Thanks,
>>
>> JT
>>

Report message to a moderator

Re: UML -> Ecore (Derived + Composite) [message #478414 is a reply to message #478413]

Tue, 19 May 2009 14:41

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi John,

There appear to be some issues in the round trip story. Please log defects
and they will be looked into.

- James.

"John T.E. Timm" <johntimm@us.ibm.com> wrote in message
news:72fb2295232c02fd4dc9131d63e3d27b$1@www.eclipse.org...
> Ed:
>
> If this is the case, then it would appear that the round-trip between UML
> and EMF is inconsistent. If I set derived and containment on the Ecore
> model and export to UML, then I get derived and composite on the UML
> model. However, if I set derived and composite on the UML model and import
> back into EMF, then I do not get derived and containment set on the Ecore
> model. I guess I will have to do some post-processing on the Ecore model
> to accommodate our particular application.
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> JT,
>
>> Yes, the UML converter is intentionally designed to do that. Best to ask
>> about it on the UML newsgroup which I've added to the "to" list of the
>> reply.
>
>
>> John T.E. Timm wrote:
>>> In attempting to recreate the Supplier / PurchaseOrder example from "EMF
>>> FeatureMaps", I ran into an issue where if I define a property in UML to
>>> be Composite and Derived, only derived is carried through to Ecore
>>> (during model import) which causes problems in serialization. If I
>>> change this attribute in the resulting Ecore after import, serialization
>>> works fine. From the article, preferredOrders and standardOrders should
>>> be composite, derived, transient, volatile, ordered, and unique.
>>>
>>> Thanks,
>>>
>>> JT
>>>
>
>

Report message to a moderator