KDM 1.1 RTF Avatar
  1. OMG Issue

KDM11 — case of a property name duplication

  • Key: KDM11-38
  • Legacy Issue Number: 13396
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Nikolai Mansourov sent a zip file containing the baseline files for KDM 1.2. I extracted the KDM_1.1.cmof file for processing with the CMOF Addin for Rose, since Adaptive incorporates the KDM 1.1.1 model and will presumably wish to support KDM 1.2. I found a case of a property name duplication, which renders it impossible to use the model without renaming one of the offending properties. The properties in question were both named "aggregatedRelationship" in the KDMEntity class. Nikolai has since supplied a provisional CMOF file with this problem corrected. This issue is filed for tracking purposes so that the provisional change is in the final KDM 1.2 file.

  • Reported: KDM 1.0 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    Change the algorithm of mechanical production of the CMOF definition of KDM, by providing
    special treatment for named associations.
    For example, the associations between the AggregatedRelationship class and KDMEntity class
    should use the named association ends to produce the following (without duplication):
    <ownedMember xmi:id='C_9427293' xmi:type='cmof:Class'
    name='AggregatedRelationship' superClass='C_12698353'
    isAbstract='false' >
    <ownedAttribute xmi:id='P_G_174' xmi:type='cmof:Property'
    type='C_12313807' name='from' lower='1' upper='1' isComposite='false'
    association='A_28697616' />
    <ownedAttribute xmi:id='P_G_176' xmi:type='cmof:Property'
    type='C_12313807' name='to' lower='1' upper='1' isComposite='false'
    association='A_499276' />
    <ownedAttribute xmi:id='P_G_178' xmi:type='cmof:Property'
    type='C_27407718' name='relation' lower='0' upper='*'
    isComposite='false' association='A_2731614' />
    <ownedAttribute xmi:id='P_G_181' xmi:type='cmof:Property'
    type='C_8395033' name='model' lower='0' upper='1' isComposite='false'
    association='A_7776694' />
    <ownedAttribute xmi:id='P_27247421' xmi:type='cmof:Property'
    name='density' type='D_25324380' />
    <ownedMember xmi:id='A_499276' xmi:type='cmof:Association'
    name='Destination' memberEnd='P_G_176 P_G_177' />
    Similarly for the segments association (see duplicate issue 13398):
    <ownedMember xmi:id='C_6068917' xmi:type='cmof:Class' name='Segment'
    superClass='C_29405700' isAbstract='false' >
    <ownedAttribute xmi:id='P_G_322' xmi:type='cmof:Property'
    type='C_6068917' name='segment' lower='0' upper='*' isComposite='true'
    association='A_22905698' /> <ownedAttribute xmi:id='P_G_323' xmi:type='cmof:Property'
    type='C_6068917' name='owner' lower='0' upper='1' isComposite='false'
    association='A_22905698' />
    <ownedAttribute xmi:id='P_G_324' xmi:type='cmof:Property'
    type='C_8395033' name='model' lower='0' upper='*' isComposite='true'
    association='A_28370794' />
    <ownedMember xmi:id='A_22905698' xmi:type='cmof:Association'
    name='Segments' memberEnd='P_G_322 P_G_323' />
    This change is performed automatically in the process of converting the
    UML Rose diagrams into CMOF. The unique ids of the cmof elements may
    change during the conversion.
    Additional change in support of this resolution, “to” and “from” roles of the KDMRelationship
    should not be declared as derived union, or derived (Core package). They are always redefined
    in subclasses. This is similar to the aggregated relations pattern in the AggregatedRelationship
    Change diagram 9.2, page 18 into the following: <<<DIAGRAM on PAGE 68 of ptc/2009-06-02

  • Updated: Fri, 6 Mar 2015 20:57 GMT