KDM11 — associations with duplicated names in the same package

In the base zip file for KDM 1.2, I imported the KDM_1.1.cmof file into the Rose CMOF addin to verify it, since Adaptive supports the current version of KDM and will probably support 1.2. I found several cases where there are associations with duplicated names in the same package; for example, the association "A_owner_codeElement" appears 7 times in the KDM::code package. When I communicated the complete list of duplicated associations to Nikolai, he sent a provisional CMOF file that corrected the problem. This issue is filed to track this problem and insure that the change that was made appears in the final CMOF file.

The full list of 16 associations with duplicate names from Gene Mutschler on 26-02-
2009:
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_itemUnit.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
Duplicate association in package: Logical View::KDM::data: A_owner_contentElement.
Duplicate association in package: Logical View::KDM::data: A_owner_contentElement.
Duplicate association in package: Logical View::KDM::data: A_group_implementation.
Duplicate association in package: Logical View::KDM::data: A_owner_dataElement.
Duplicate association in package: Logical View::KDM::event: A_owner_eventElement.
Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement.
Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement.
Duplicate association in package: Logical View::KDM::ui: A_owner_uiElement.
To disambiguate the association names, the rule for producing CMOF association should
be changed into
"A_" <class-name1> "_" <association-end-name2>
When these rules are applied, unambiguous association names are
produced. For example, for the association owner-code element owned by
Module, the following CMOF is produced:
<ownedMember xmi:id='A_58' xmi:type='cmof:Association'
memberEnd='P_O_29311055 P_D_29311055' name='A_Module_codeElement'
general='A_1'>
<ownedEnd xmi:id='P_D_29311055' xmi:type='cmof:Property'
subsettedProperty='P_D_9252407' type='C_18297765' name='owner'
lower='0' upper='1' isComposite='false' association='A_58' />
</ownedMember>
<ownedMember xmi:id='C_18297765' xmi:type='cmof:Class'
name='Module' superClass='C_8898472' isAbstract='false' > <ownedAttribute xmi:id='P_O_29311055' xmi:type='cmof:Property'
isOrdered='true' subsettedProperty='P_O_9252407' type='C_13966896'
name='codeElement' lower='0' upper='*' isComposite='true'
association='A_58' />
</ownedMember>
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.
Add new section before section 6.3 Acknowledgements, page 7 that explicitly defines the naming
conventions for mechanical production of CMOF definition of KDM from UML diagrams:
“
6.2.1. Diagram format
Metamodel diagrams in this specification are used to mechanically produce the MOF definition of
KDM, and the corresponding KDM XMI schema. The following conventions are adopted for all
metamodel diagrams throughout this specification:
• An association with one end marked by a navigability arrow means that:
o the association is navigable in the direction of that end,
o the marked association end is owned by the classifier, and
o the opposite (unmarked) association end is owned by the association.
• An association with neither end marked by navigability arrows means that:
o the association is navigable in both directions,
o each association end is owned by the classifier at the opposite end (i.e.,
neither end is owned by the association).
.. Additionally, properties “owner”, “group” and “model” are automatically
renamed to ownerProperty, groupProperty and modelProperty
respectively.
• Association specialization and redefinition are indicated by appropriate constraints
situated in the proximity of the association ends to which they apply. Thus:
o The constraint

means that the association end to which this
constraint is applied is a specialization of association end endA that is part of the
association being specialized.
o A constraint

means that the association end to which this
constraint is applied redefines the association end endA that is part of the
association being specialized.
• Derived union is indicated by placing constraint

in the proximity of the association
end to which it applies. The corresponding association endpoint is marked as derived and
read only.
• If an association end is unlabeled, the default name for that end is the name of the
class to which the end is attached, modified such that the first letter is a lowercase
letter. In addition, if the name of the class to which the end is attached starts has a
meaningful prefix of uppercase letters, for example XMLxxxx, KDMxxx,
UIxxxx, the entire uppercase prefix is modified to become lowercase. For
example, the above words become xmlxxxx, kdmxxx, uixxxx. (Note that, by
convention, non-navigable association ends are often left unlabeled since, in general,
there is no need to refer to them explicitly either in the text or in formal constraints –
although there may be needed for other purposes, such as MOF language bindings that
use the metamodel.)
o Unlabeled association ends attached to the class KDM Entity which
correspond to KDM Relationships are additionally prefixed with “in” or
“out” according to the direction of the relationship. The corresponding properties at the KDM Relationship class side are "to" and "from". For
example, association ends for the ActionElement class corresponding to
the associations to ControlFlow class are named “inControlFlow” (the
counterpart of the “to” endpoint from the ControlFlow side) and
“outControlFlow” (the counterpart of the “from” endpoint from the
ControlFlow side)
• Associations that are not explicitly named, are given names that are constructed
according to the following production rule:
"A_" <class-name1> "_" <association-end-name2>
where <class-name1> is the name of the class that owns the first association end
and <association-end-name2> is the name of the second association end
“