Knowledge Discovery Metamodel Avatar
  1. OMG Specification

Knowledge Discovery Metamodel — Closed Issues

  • Acronym: KDM
  • Issues Count: 29
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
KDM11-35 representation of this-> and this KDM 1.0 KDM 1.1 Resolved closed
KDM11-37 There is a problem with Throws relation and Throw micro operation KDM 1.0 KDM 1.1 Resolved closed
KDM11-38 case of a property name duplication KDM 1.0 KDM 1.1 Resolved closed
KDM11-40 "Segments" assocation on the kdm::Segment class KDM 1.0 KDM 1.1 Resolved closed
KDM11-39 upper bound of the container end of a composition shown as unbounded KDM 1.0 KDM 1.1 Resolved closed
KDM11-36 Description of the multidimentional arrays is confusing. KDM 1.0 KDM 1.1 Resolved closed
KDM11-34 change text for the arrayselect "single" reads KDM 1.0 KDM 1.1 Resolved closed
KDM11-41 associations with duplicated names in the same package KDM 1.0 KDM 1.1 Resolved closed
KDM11-33 text should mention optional writes in micro kdm and an example with a+1; KDM 1.0 KDM 1.1 Resolved closed
KDM11-32 Need to make Datatype generic, for the sake of using it in with stereotypes KDM 1.0 KDM 1.1 Resolved closed
KDM11-27 Add uppercase requirement for the names of micro KDM operations KDM 1.0 KDM 1.1 Resolved closed
KDM11-26 Need a counterpart of the HasValue relation KDM 1.0 KDM 1.1 Resolved closed
KDM11-28 representation of the sizeof (type) operator as opposed to sizeof (expr) op KDM 1.0 KDM 1.1 Resolved closed
KDM11-31 More than one label on a statement KDM 1.0 KDM 1.1 Resolved closed
KDM11-30 Discuss using the name of the action element as label KDM 1.0 KDM 1.1 Resolved closed
KDM11-23 10.4: use of 'author' is redundant KDM 1.0 KDM 1.1 Resolved closed
KDM11-29 Correct specification text: KDM 1.0 KDM 1.1 Resolved closed
KDM11-25 Consider representation of a switch KDM 1.0 KDM 1.1 Resolved closed
KDM11-24 10.4.1: Audit.description KDM 1.0 KDM 1.1 Resolved closed
KDM11-22 p31 the XMI example has wrong namespaces for xmi and kdm and audit KDM 1.0 KDM 1.1 Resolved closed
KDM11-17 9.3.3 getOwnerElement is misnamed KDM 1.0 KDM 1.1 Resolved closed
KDM11-21 10.3.1: Description of 'segment' property KDM 1.0 KDM 1.1 Resolved closed
KDM11-18 9.4.1 - CMOF “redefines” mechanism KDM 1.0 KDM 1.1 Resolved closed
KDM11-19 9.4.2 - why 2 separate associations? KDM 1.0 KDM 1.1 Resolved closed
KDM11-20 9.5.1 Constraint 4 is inconsistent KDM 1.0 KDM 1.1 Resolved closed
KDM11-16 9.3.3 Constraint 1 seems wrong KDM 1.0 KDM 1.1 Resolved closed
KDM11-15 9.3.3, association 'group' KDM 1.0 KDM 1.1 Resolved closed
KDM11-13 Break cyclic dependency between Code and Action package KDM 1.0b1 KDM 1.1 Resolved closed
KDM11-14 9.3.3 definition of owner KDM 1.0 KDM 1.1 Resolved closed

Issues Descriptions

representation of this-> and this

  • Key: KDM11-35
  • Legacy Issue Number: 11732
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    representation of this-> and this. there should be some sort of addresses to the class or something like that. There
    is an example (initialization) but it may need some corrections. The example simply writes to the class member. The
    problem is that this is not distinguishable from simply num=x; (the example has this->num=x
    Maybe there should be a microoperation "this"?

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

There is a problem with Throws relation and Throw micro operation

  • Key: KDM11-37
  • Legacy Issue Number: 11735
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    There is a problem with Throws relation and Throw micro operation: Throws relation is to an object! but Throw says
    that there are Reads. Reads should be part of the constructor, there should be new, bla-bla, constructor call.
    Big question mark.

    Throws should be a shortcut - relationship to the exception class. with a single Reads to the exception object.
    Because we do not want to duplicate the constructor call logic.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

case of a property name duplication

  • Key: KDM11-38
  • Legacy Issue Number: 13396
  • Status: closed  
  • Source: Adaptive ( 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>
    <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>
    <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
    class.
    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

"Segments" assocation on the kdm::Segment class

  • Key: KDM11-40
  • Legacy Issue Number: 13398
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

    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 an error where there was an association from a class to itself that had the same role name on both ends. This was the "Segments" assocation on the kdm::Segment class. When I communicated this problem 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.

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

    No Data Available

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

upper bound of the container end of a composition shown as unbounded

  • Key: KDM11-39
  • Legacy Issue Number: 13397
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

    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 an error where the upper bound of the container end of a composition was shown as unbounded (the A_group_groupedElement association on the KDMEntity class). When I communicated this to Nikolai, he indicated that the problem was that this relation should not be composite. He sent a provisional CMOF file that changed the nature of the association that I was able to import successfully. This issue is filed to track this problem and insure that the change that was made appears in the final CMOF 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 KDM group associations.
    This correctly produces isDerived=true for ownedElement, and isDerived=false for
    groupedElement.
    <ownedAttribute xmi:id='P_O_9252407' xmi:type='cmof:Property'
    isOrdered='false' isDerivedUnion='true' isDerived='true'
    isReadOnly='true' type='C_12313807' name='ownedElement' lower='0'
    upper='*' isComposite='true' association='A_1' />
    <ownedAttribute xmi:id='P_D_9252407' xmi:type='cmof:Property'
    isDerivedUnion='true' isDerived='true' isReadOnly='true'
    type='C_12313807' name='ownerProperty' lower='0' upper='1'
    isComposite='false' association='A_1' />
    <ownedAttribute xmi:id='P_O_11837032' xmi:type='cmof:Property'
    isOrdered='false' isDerivedUnion='true' isDerived='true'
    isReadOnly='true' type='C_12313807' name='groupedElement' lower='0'
    upper='*' isComposite='false' association='A_36' />
    <ownedAttribute xmi:id='P_D_11837032' xmi:type='cmof:Property'
    isDerivedUnion='true' isDerived='true' isReadOnly='true'
    type='C_12313807' name='groupProperty' lower='0' upper='*'
    isComposite='false' association='A_36' />
    Also in order to avoid duplication derived union properties “owner”, “group” and “model” are
    automatically renamed to ownerProperty, groupProperty and modelProperty respectively.
    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.

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

Description of the multidimentional arrays is confusing.

  • Key: KDM11-36
  • Legacy Issue Number: 11734
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Description of the multidimentional arrays is confusing. Need to clarify the text.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

change text for the arrayselect "single" reads

  • Key: KDM11-34
  • Legacy Issue Number: 11731
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    change text for the arrayselect "single" reads

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

associations with duplicated names in the same package

  • Key: KDM11-41
  • Legacy Issue Number: 13399
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

    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.

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

    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

    {subsets endA}

    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

    {redefines endA}

    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

    {union}

    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

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

text should mention optional writes in micro kdm and an example with a+1;

  • Key: KDM11-33
  • Legacy Issue Number: 11730
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    text should mention optional writes in micro kdm and an example with a+1;

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

Need to make Datatype generic, for the sake of using it in with stereotypes

  • Key: KDM11-32
  • Legacy Issue Number: 11729
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Need to make Datatype generic, for the sake of using it in with stereotypes

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    resolved

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

Add uppercase requirement for the names of micro KDM operations

  • Key: KDM11-27
  • Legacy Issue Number: 11715
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Add uppercase requirement for the names of micro KDM operations. Make the text more clear.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

Need a counterpart of the HasValue relation

  • Key: KDM11-26
  • Legacy Issue Number: 11713
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Need a counterpart of the HasValue relation to directly represent complex initializations.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

representation of the sizeof (type) operator as opposed to sizeof (expr) op

  • Key: KDM11-28
  • Legacy Issue Number: 11719
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    representation of the sizeof (type) operator as opposed to sizeof (expr) operator
    Sizeof should not have Reads ? Maybe addresses ? Maybe we need another micro action for sizeof type,
    with a UsesType relation.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

More than one label on a statement

  • Key: KDM11-31
  • Legacy Issue Number: 11724
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    More than one label on a statement (weird as it may be).
    a: b: c: x=1; switch case 1: goto a; case 2: goto b; case 3: goto c; }
    -> this can be represented as a sequence of Nops.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    This is addressed by the resolution to another issue 11722.
    Disposition: Closed, no change

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

Discuss using the name of the action element as label

  • Key: KDM11-30
  • Legacy Issue Number: 11722
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Discuss using the name of the action element as label; if this is ok; add to specification
    alternatively we can use a Nop with a name as a label.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

10.4: use of 'author' is redundant

  • Key: KDM11-23
  • Legacy Issue Number: 11182
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    10.4: XMI already has the ability to capture the tool creating an instance: use of 'author' for this is redundant

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

Correct specification text:

  • Key: KDM11-29
  • Legacy Issue Number: 11720
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Correct specification text:
    in the definition of InstanceOf - relations in UsesType, not usesCode. Dyncast, typecast

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

Consider representation of a switch

  • Key: KDM11-25
  • Legacy Issue Number: 11712
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Consider representation of a switch. What action kind is the second action with a reads ?
    maybe add a new kind "guard"

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

10.4.1: Audit.description

  • Key: KDM11-24
  • Legacy Issue Number: 11183
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    10.4.1: States that an Audit element can onw Annotation elements: it's unclear whether Audit.description should be used or owned Annotation elements.

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

p31 the XMI example has wrong namespaces for xmi and kdm and audit

  • Key: KDM11-22
  • Legacy Issue Number: 11180
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    p31 the XMI example has wrong namespaces for xmi and kdm and audit

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

9.3.3 getOwnerElement is misnamed

  • Key: KDM11-17
  • Legacy Issue Number: 11171
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.3.3 getOwnerElement is misnamed - should be getOwnedElement.

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

10.3.1: Description of 'segment' property

  • Key: KDM11-21
  • Legacy Issue Number: 11179
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    10.3.1: Description of 'segment' property does not mention segment and seems to be a paste from another place

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

9.4.1 - CMOF “redefines” mechanism

  • Key: KDM11-18
  • Legacy Issue Number: 11172
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.4.1: "In KDM this is represented by the CMOF “redefines” mechanism. Concrete properties redefine the “union” properties of the parent classes, defined in the Core package." However by using

    {redefines}

    and not

    {subsets}

    it is largely defeating the point of using a derived union - since redefines makes the derived end unavailable!

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    Page 19, 9.4.1 in “to” association replace “redefines” mechanism “ with “subsets” mechanism
    Page 19, 9.4.1 in “from” association replace “redefines” mechanism “ with “subsets” mechanism

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

9.4.2 - why 2 separate associations?

  • Key: KDM11-19
  • Legacy Issue Number: 11173
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.4.2 It seems that getOwnedRelation = getOutbound: why 2 separate associations?

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    Disposition: Closed, no change

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

9.5.1 Constraint 4 is inconsistent

  • Key: KDM11-20
  • Legacy Issue Number: 11175
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.5.1 Constraint 4 is inconsistent with the descriptions of 'to' and 'from' which allow entities which are indirectly contained.

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

9.3.3 Constraint 1 seems wrong

  • Key: KDM11-16
  • Legacy Issue Number: 11170
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.3.3 Constraint 1 seems wrong - why not group X that is owned by something else? At minimum this should be explained in the semantics.
    If it is valid then it would be better shown as an XOR constraint.

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    Page 17, 9.3.3 delete constraint 1

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

9.3.3, association 'group'

  • Key: KDM11-15
  • Legacy Issue Number: 11169
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.3.3, association 'group' has "The group of a KDM entity is defined as the group..." which is inconsistent with the next sentence and the metamodel which says an entity may be in many groups.

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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

Break cyclic dependency between Code and Action package

  • Key: KDM11-13
  • Legacy Issue Number: 10123
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Break cyclic dependency between Code and Action package. Code and Action package both define elements for the CodeModel. Each package defines some concrete KDM relationships (7 relationships is Code package, and 17 in Action package). On the other hand, Action package defines a signle entity - ActionElement. This creates a cyclic dependency between the two packages. Also, there is a some confusion as to which EMF factory to use for creating a particular relationship. KDM can be improved, if ActionElement definition is moved to Code package and all relationship definitions from the Code package are moved to action package. This will remove dependency deom Code package to Action package and simplify the usage of factories.

  • Reported: KDM 1.0b1 — Tue, 22 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    The current framework is working fine.
    Disposition: Closed, no change

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

9.3.3 definition of owner

  • Key: KDM11-14
  • Legacy Issue Number: 11168
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    9.3.3 definition of owner has its type as KDMContainer which is inconsistent with the preceding figure which has it as recursive

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

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