Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Transforming UML associations to Ecore
Transforming UML associations to Ecore [message #476805] Wed, 26 December 2007 17:55 Go to next message
Dave Carlson is currently offline Dave CarlsonFriend
Messages: 402
Registered: July 2009
Senior Member
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 #476820 is a reply to message #476805] Thu, 03 January 2008 15:30 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
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 #476821 is a reply to message #476820] Thu, 03 January 2008 17:08 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Dave Carlson is currently offline Dave CarlsonFriend
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 Go to previous message
Eclipse UserFriend
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 #625796 is a reply to message #476805] Thu, 03 January 2008 15:30 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
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 #625797 is a reply to message #476820] Thu, 03 January 2008 17:08 Go to previous message
Eclipse UserFriend
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 Go to previous message
Dave Carlson is currently offline Dave CarlsonFriend
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 Go to previous message
Eclipse UserFriend
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).
>>
Previous Topic:SequenceNode serialization problem?
Next Topic:uml metamodel diagrams
Goto Forum:
  


Current Time: Tue Aug 16 05:04:42 GMT 2022

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

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

Back to the top