Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Re: UML -> Ecore (Derived + Composite)
Re: UML -> Ecore (Derived + Composite) [message #478412] Tue, 19 May 2009 05:17 Go to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
>
Re: UML -> Ecore (Derived + Composite) [message #478413 is a reply to message #478412] Tue, 19 May 2009 05:56 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
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
>>
Re: UML -> Ecore (Derived + Composite) [message #478414 is a reply to message #478413] Tue, 19 May 2009 14:41 Go to previous message
james bruck is currently offline 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
>>>
>
>
Re: UML -> Ecore (Derived + Composite) [message #627598 is a reply to message #478412] Tue, 19 May 2009 05:56 Go to previous message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
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
>>
Re: UML -> Ecore (Derived + Composite) [message #627599 is a reply to message #478413] Tue, 19 May 2009 14:41 Go to previous message
james bruck is currently offline 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
>>>
>
>
Previous Topic:Re: UML -> Ecore (Derived + Composite)
Next Topic:Static profile stereotype application problem
Goto Forum:
  


Current Time: Sat Sep 20 22:14:04 GMT 2014

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

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