Home » Modeling » UML2 » Re: UML -> Ecore (Derived + Composite)
Re: UML -> Ecore (Derived + Composite) [message #478412] |
Tue, 19 May 2009 05:17 |
Ed Merks Messages: 33218 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/
|
|
|
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
>>
|
|
|
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
>>>
>
>
|
|
|
Re: UML -> Ecore (Derived + Composite) [message #627598 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
>>
|
|
|
Re: UML -> Ecore (Derived + Composite) [message #627599 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
>>>
>
>
|
|
|
Goto Forum:
Current Time: Wed Sep 25 17:21:05 GMT 2024
Powered by FUDForum. Page generated in 0.04528 seconds
|