Home » Modeling » UML2 » Transforming UML associations to Ecore
| |
| Re: Transforming UML associations to Ecore [message #476821 is a reply to message #476820] |
Thu, 03 January 2008 17:08   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dave, James,
If and when this enhancement is committed to UML2, would either of you be
interested in contributing support for these association EClasses in the
OCL component? Also, does this enhancement cover
- AssociationClasses generally (including other features that
they may declare), even where at least one of the ends is not
owned and/or is navigable?
- N-ary associations?
- Association-end qualifiers?
All of this would affect the run-time evaluation support of OCL component's
UML binding, which currently implements navigation of non-navigable
association ends but not association classes (because these currently don't
map to Ecore).
Cheers,
Christian
James Bruck wrote:
> Hi Dave,
>
> Thanks for the defect and patch. It is being looked into now.
>
> Cheers,
> - James.
>
>
> "Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
> news:fku4is$ehp$1@build.eclipse.org...
>> It seems that the UML to Ecore transformation needs to be enhanced to
>> consider Associations where both ends are owned by the Association. In
>> the OMG's SBVR cmof metamodel, there is NO use of composition, and all
>> associations own both property ends. Neither property is composition,
>> nor navigable.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213894
>>
>> I would expect that these associations must be transformed into Ecore
>> classes. I don't know what tools were used by the SBVR spec authors to
>> create their XSD for serialized XMI models (apparently not EMF...), but
>> the cmof associations appear in XSD as shown below, which implies that
>> EMF would need an EClass for each Association that owns both of its ends.
>>
>> <xs:element name="placeholderUsesDesignation"
>> type="sbvr:placeholderUsesDesignation"/>
>> <xs:complexType name="placeholderUsesDesignation">
>> <xs:all>
>> <xs:element name="placeholder" form="unqualified" minOccurs="0">
>> <xs:complexType>
>> <xs:attributeGroup ref="xmi:LinkAttribs"/>
>> </xs:complexType>
>> </xs:element>
>> <xs:element name="designation" form="unqualified" minOccurs="0">
>> <xs:complexType>
>> <xs:attributeGroup ref="xmi:LinkAttribs"/>
>> </xs:complexType>
>> </xs:element>
>> <xs:element ref="xmi:Extension" minOccurs="0"/>
>> </xs:all>
>> <xs:attribute name="placeholder" type="xs:IDREF" use="optional"/>
>> <xs:attribute name="designation" type="xs:IDREF" use="optional"/>
>> </xs:complexType>
>>
|
|
|
| Re: Transforming UML associations to Ecore [message #476822 is a reply to message #476821] |
Thu, 03 January 2008 17:25 |
 Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
If the scope is increased to include the items listed below, then I would
want to split this bug into two:
1) bug in CMOF support, where an Association that owns both ends is mapped
to an EClass. Currently these associations are completely ignored by Ecore
export from CMOF or UML. This is a compliance bug for XMI serialization of
CMOF, and prevents EMF from being used with the OMG's SBVR metamodel.
2) an enhancement request for UML AssociationClass, N-ary associations, and
Association-end qualifiers. None of these are present in CMOF and are not
required to fill the compliance gap for XMI serialization.
Dave
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:flj4qo$evb$1@build.eclipse.org...
> Hi, Dave, James,
>
> If and when this enhancement is committed to UML2, would either of you be
> interested in contributing support for these association EClasses in the
> OCL component? Also, does this enhancement cover
>
> - AssociationClasses generally (including other features that
> they may declare), even where at least one of the ends is not
> owned and/or is navigable?
> - N-ary associations?
> - Association-end qualifiers?
>
> All of this would affect the run-time evaluation support of OCL
> component's
> UML binding, which currently implements navigation of non-navigable
> association ends but not association classes (because these currently
> don't
> map to Ecore).
>
|
|
|
| Re: Transforming UML associations to Ecore [message #476823 is a reply to message #476822] |
Thu, 03 January 2008 17:51 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dave,
Yes, that makes perfect sense. Note, of course, that I'm not actually
asking for an increased scope, but possibly from a UML perspective the
scope naturally would tend to creep.
I think UML doesn't actually implement CMOF-to-Ecore conversion, but rather
imports the CMOF into UML and generates Ecore from that? This would mean
that UML associations, as well as CMOF, will be converted to Ecore, and OCL
(which attempts to target UML but not CMOF, as such) should be able to
handle that (playing catch-up, you know :-)
Cheers,
Christian
Dave Carlson wrote:
> Hi Christian,
> If the scope is increased to include the items listed below, then I would
> want to split this bug into two:
>
> 1) bug in CMOF support, where an Association that owns both ends is mapped
> to an EClass. Currently these associations are completely ignored by
> Ecore
> export from CMOF or UML. This is a compliance bug for XMI serialization
> of CMOF, and prevents EMF from being used with the OMG's SBVR metamodel.
>
> 2) an enhancement request for UML AssociationClass, N-ary associations,
> and
> Association-end qualifiers. None of these are present in CMOF and are not
> required to fill the compliance gap for XMI serialization.
>
> Dave
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:flj4qo$evb$1@build.eclipse.org...
>> Hi, Dave, James,
>>
>> If and when this enhancement is committed to UML2, would either of you be
>> interested in contributing support for these association EClasses in the
>> OCL component? Also, does this enhancement cover
>>
>> - AssociationClasses generally (including other features that
>> they may declare), even where at least one of the ends is not
>> owned and/or is navigable?
>> - N-ary associations?
>> - Association-end qualifiers?
>>
>> All of this would affect the run-time evaluation support of OCL
>> component's
>> UML binding, which currently implements navigation of non-navigable
>> association ends but not association classes (because these currently
>> don't
>> map to Ecore).
>>
|
|
| |
| Re: Transforming UML associations to Ecore [message #625797 is a reply to message #476820] |
Thu, 03 January 2008 17:08 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dave, James,
If and when this enhancement is committed to UML2, would either of you be
interested in contributing support for these association EClasses in the
OCL component? Also, does this enhancement cover
- AssociationClasses generally (including other features that
they may declare), even where at least one of the ends is not
owned and/or is navigable?
- N-ary associations?
- Association-end qualifiers?
All of this would affect the run-time evaluation support of OCL component's
UML binding, which currently implements navigation of non-navigable
association ends but not association classes (because these currently don't
map to Ecore).
Cheers,
Christian
James Bruck wrote:
> Hi Dave,
>
> Thanks for the defect and patch. It is being looked into now.
>
> Cheers,
> - James.
>
>
> "Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
> news:fku4is$ehp$1@build.eclipse.org...
>> It seems that the UML to Ecore transformation needs to be enhanced to
>> consider Associations where both ends are owned by the Association. In
>> the OMG's SBVR cmof metamodel, there is NO use of composition, and all
>> associations own both property ends. Neither property is composition,
>> nor navigable.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213894
>>
>> I would expect that these associations must be transformed into Ecore
>> classes. I don't know what tools were used by the SBVR spec authors to
>> create their XSD for serialized XMI models (apparently not EMF...), but
>> the cmof associations appear in XSD as shown below, which implies that
>> EMF would need an EClass for each Association that owns both of its ends.
>>
>> <xs:element name="placeholderUsesDesignation"
>> type="sbvr:placeholderUsesDesignation"/>
>> <xs:complexType name="placeholderUsesDesignation">
>> <xs:all>
>> <xs:element name="placeholder" form="unqualified" minOccurs="0">
>> <xs:complexType>
>> <xs:attributeGroup ref="xmi:LinkAttribs"/>
>> </xs:complexType>
>> </xs:element>
>> <xs:element name="designation" form="unqualified" minOccurs="0">
>> <xs:complexType>
>> <xs:attributeGroup ref="xmi:LinkAttribs"/>
>> </xs:complexType>
>> </xs:element>
>> <xs:element ref="xmi:Extension" minOccurs="0"/>
>> </xs:all>
>> <xs:attribute name="placeholder" type="xs:IDREF" use="optional"/>
>> <xs:attribute name="designation" type="xs:IDREF" use="optional"/>
>> </xs:complexType>
>>
|
|
|
| Re: Transforming UML associations to Ecore [message #625798 is a reply to message #476821] |
Thu, 03 January 2008 17:25 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
If the scope is increased to include the items listed below, then I would
want to split this bug into two:
1) bug in CMOF support, where an Association that owns both ends is mapped
to an EClass. Currently these associations are completely ignored by Ecore
export from CMOF or UML. This is a compliance bug for XMI serialization of
CMOF, and prevents EMF from being used with the OMG's SBVR metamodel.
2) an enhancement request for UML AssociationClass, N-ary associations, and
Association-end qualifiers. None of these are present in CMOF and are not
required to fill the compliance gap for XMI serialization.
Dave
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:flj4qo$evb$1@build.eclipse.org...
> Hi, Dave, James,
>
> If and when this enhancement is committed to UML2, would either of you be
> interested in contributing support for these association EClasses in the
> OCL component? Also, does this enhancement cover
>
> - AssociationClasses generally (including other features that
> they may declare), even where at least one of the ends is not
> owned and/or is navigable?
> - N-ary associations?
> - Association-end qualifiers?
>
> All of this would affect the run-time evaluation support of OCL
> component's
> UML binding, which currently implements navigation of non-navigable
> association ends but not association classes (because these currently
> don't
> map to Ecore).
>
|
|
|
| Re: Transforming UML associations to Ecore [message #625847 is a reply to message #476822] |
Thu, 03 January 2008 17:51 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dave,
Yes, that makes perfect sense. Note, of course, that I'm not actually
asking for an increased scope, but possibly from a UML perspective the
scope naturally would tend to creep.
I think UML doesn't actually implement CMOF-to-Ecore conversion, but rather
imports the CMOF into UML and generates Ecore from that? This would mean
that UML associations, as well as CMOF, will be converted to Ecore, and OCL
(which attempts to target UML but not CMOF, as such) should be able to
handle that (playing catch-up, you know :-)
Cheers,
Christian
Dave Carlson wrote:
> Hi Christian,
> If the scope is increased to include the items listed below, then I would
> want to split this bug into two:
>
> 1) bug in CMOF support, where an Association that owns both ends is mapped
> to an EClass. Currently these associations are completely ignored by
> Ecore
> export from CMOF or UML. This is a compliance bug for XMI serialization
> of CMOF, and prevents EMF from being used with the OMG's SBVR metamodel.
>
> 2) an enhancement request for UML AssociationClass, N-ary associations,
> and
> Association-end qualifiers. None of these are present in CMOF and are not
> required to fill the compliance gap for XMI serialization.
>
> Dave
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:flj4qo$evb$1@build.eclipse.org...
>> Hi, Dave, James,
>>
>> If and when this enhancement is committed to UML2, would either of you be
>> interested in contributing support for these association EClasses in the
>> OCL component? Also, does this enhancement cover
>>
>> - AssociationClasses generally (including other features that
>> they may declare), even where at least one of the ends is not
>> owned and/or is navigable?
>> - N-ary associations?
>> - Association-end qualifiers?
>>
>> All of this would affect the run-time evaluation support of OCL
>> component's
>> UML binding, which currently implements navigation of non-navigable
>> association ends but not association classes (because these currently
>> don't
>> map to Ecore).
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:06:29 GMT 2024
Powered by FUDForum. Page generated in 0.03433 seconds |
] 
Search
Help
Register
Login
Home
