Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Question about the EMF implementation of the UML metamodel


I see that Christian Damus replied to your question in the forum.

To supplement what he said, the reason for the difference here is an implementation detail that is based on constraints imposed by EMF. In an EMF-based model, a given element can only have one container. Here, Element::ownedElement is a composite derived union that is subsetted by a composite property, Package::packagedElement. Since a given packaged element can be contained via only one reference in EMF, the more specific reference is left as the containment relationship and the superset is made a non-containment reference. You'll see the same pattern applied for other composite subsets of Element::ownedElement and, indeed, for other superset/subset combinations that involve multiple composite properties.


On Fri, Jun 19, 2015 at 6:51 AM, Patrick TOURNET <ptournet@xxxxxxxxxxxxxx> wrote:

As I'm not sure if any MDT-UML developper is reading the forum, I'm reposting here a question about the choices made by the team in order to implement some containment associations described in the UML 2.4.1 metamodel (original question is here : :

While looking at the UML implementation using EMF I noticed something that I couldn't figure out by myself, so I'm hoping that someone will be able to explain the following :

In the 2.4.1 UML spec, there's a containment association between Element and itself (owner/ownedElement) and there's also one between Package and PackageableElement (owningPackage/packagedElement).
But in the EMF implementation, the first one is modeled as a derived bi-directionnal reference
    <eStructuralFeatures xsi:type="ecore:EReference" name="ownedElement" ordered="false"
        upperBound="-1" eType="#//Element" changeable="false" volatile="true" transient="true"
        derived="true" eOpposite="#//Element/owner">
      <eAnnotations source="">
        <details key="documentation" value="The Elements owned by this Element.&#xA;&lt;p>From package UML::CommonStructure.&lt;/p>"/>
      <eAnnotations source="union"/>
    <eStructuralFeatures xsi:type="ecore:EReference" name="owner" ordered="false"
        eType="#//Element" changeable="false" volatile="true" transient="true" derived="true"
      <eAnnotations source="">
        <details key="documentation" value="The Element that owns this Element.&#xA;&lt;p>From package UML::CommonStructure.&lt;/p>"/>
      <eAnnotations source="union"/>
while the second one is modeled as a composition
    <eStructuralFeatures xsi:type="ecore:EReference" name="packagedElement" ordered="false"
        upperBound="-1" eType="#//PackageableElement" containment="true">
      <eAnnotations source="">
        <details key="documentation" value="Specifies the packageable elements that are owned by this Package.&#xA;&lt;p>From package UML::Packages.&lt;/p>"/>
      <eAnnotations source="subsets" references="#//Namespace/ownedMember"/>
So, I was wondering why the difference between those two... It seems to me that both are doing the same thing, but is there any particular reason to chose one approach over the other ? Or did I miss something ?
Thanks for your time,
Patrick Tournet

Avast logo

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top