Issues for Mailing list of the ADM Knowledge Discovery Metamodel Finalization Task Force

To comment on any of these issues, send email to kdm-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 9911: Section: 10.3, 10.4 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of KDM Framework as KDM Instance

Resolution:
Revised Text:
Actions taken:
July 10, 2006: received isuse
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 240 - 241

Issue 9912: Section: 10.5 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of usage of the Audit element

Resolution:
Revised Text:
Actions taken:
July 10, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM Framework example (issue 9911). Merged with 9911.
Disposition: Duplicate or merged

Issue 9965: Section: 11.3 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of SourceRef element as a KDM instance

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM HelloWorld example (issue 9977). Merged with 9977.
Disposition: Duplicate or merged

Issue 9966: Section: 11.4 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of SourceRegion element as a KDM instance. It would be good to illustrate alternative organization with and without the BuildModel for representing files, as well as various overrides for language attribute

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM Framework example (issue 9911). Merged with 9911.
Disposition: Duplicate or merged

Issue 9967: Section: 9.4 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM requires navigabable associations from KDMEntity to KDMRelationship (in the Core KDM these are named outbound and inbound, see Figure 9.2). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMRelationship element. The outbound and inbound associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 71 - 96 for details

Issue 9968: Section: 9.5 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM requires navigabable associations from KDMEntity to KDMAggregatedRelationship (in the Core KDM these are named inAggregated and outAggregated, see Figure 9.3). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMAggregatedRelationship element. The inAggregated and outAggregated associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 43/44 for deails

Issue 9969: Section: 9.7.1 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of KDM Stereotype as KDM instance (with tag definitions, as part of an Extension family).

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04, page 356 - 357

Issue 9970: Section: 9.7.1 (issue # 2) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM requires a named association from Stereotype to the ModelElement (called extendedElement in Figure 9.5). While useful for certain cross-referencing queries (usage of a given stereotype), this feature makes KDM instance XMI very inflexible and complicated (as information is essentially duplicated). Suggestion to define this as an operation, or remove to be implemented internally to KDM tools, if needed

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 45/46 for deails

Issue 9971: Section: 12.5 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM defines unnecessary abstract classes for relations, for example, CodeRelationship, PrototypeRelationship, Interfacerelationship, TypeRelationship, TemplateRelationship (figure 12.3). This is a consistent pattern, repreated at other packages. The intention was to provide additional extension points, however, these relationships are defined as abstract classes, so they cannot be instanciated. They cannot be made concrete either for the reasons of compatibility with EMF. They make the metamodel unnecessary complex without adding any value. They do not affect the KDM instance XMI. The suggestion is to simplify the metamodel by removing these unnecessary relations. This suggestion was also given by ASG representative.

Resolution:
Revised Text: resolved
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

KDM can be improved by eliminating several unnecessary abstract classes, that are
defined as subclasses of CodeRelationship at diagram CodeRelations. Several other
diagrams need to be corrected. As the result, the diagram CodeRelations becomes
redundant, so the CodeRelations element can be moved into the CodeInheritances
diagram. The only needed abstract subclasses of KDMRelationship are those that are
used to represent ownership of relations, such as CodeRelationship.
This change does not affect the KDM XMI.
Delete CodeRelations class diagram (Figure 12.3).
Delete section 12.5, page 46-47.
Modify CodeInheritances class diagram (Figure 12.1) by moving CodeRelationship class
into it (changes are indicated by red color):    (Added text is indicated by underlining)
Add �CodeRelationship� into the list of classes defined at the CodeModel diagram
(section 12.4 page 42, after CodeElement item):
.. CodeRelationship � a class representing an abstract parent for all KDM
relationships that can be used to model code.
Add new section after section 12.4.2 CodeElement, describing CodeRelationship class
(as it was moved from CodeRelations diagram to CodeInheritances diagram):
12.4.3. CodeRelationship Class (abstract)
The CodeRelationship is an abstract class representing any relationship determined by a
programming language.
Superclass
KDMRelationship
Constraints
Semantics CodeRelationship is an abstract class that is used to constrain the subclasses of
KDMRelationship in the Code model.Modify Prototype class diagram (Figure 12.6 page 51) to change PrototypeRelations into
CodeRelationship (changes are indicated by red color):
Modify superclass of PrototypedBy class in the text (section 12.8.2, page 52):
Superclass
CodeRelationship
Modify TemplateRelations class diagram (Figure 12.9, page 56) to change
TemplateRelationship into CodeRelationship: Modify superclass of Instantiates class in the text (section 12.11.1, page 56):
Superclass
CodeRelationship
Modify superclass of InstanceOf class in the text (section 12.11.2, page 56):
Superclass
CodeRelationship
Modify InterfaceRelations class diagram (Figure 12.18, page 68) to change
InterfaceRelationship into CodeRelationship: Modify superclass of Implements class in the text (section 12.20.1, page 68):
Superclass
CodeRelationship
Modify superclass of ImplementationOf class in the text (section 12.20.2, page 69):
Superclass
CodeRelationship
Modify TypeRelations class diagram (Figure 12.19, page 70) to change TypeRelationship
into CodeRelationship: Modify superclass of HasType class in the text (section 12.21.1, page 70):
Superclass
CodeRelationship
Modify ClassRelations class diagram (Figure 12.20, page 71) to change
TypeRelationship into CodeRelationship: Modify superclass of Extends class in the text (section 12.22.1, page 72):
Superclass
CodeRelationship
Modify Visiblity class diagram (Figure 12.22, page 73) to change PrototypeRelationship
into CodeRelationship: Modify superclass of VisibleIn class in the text (section 12.24.1, page 74):
Superclass
CodeRelationship
Modify PrototypeRelations class diagram in the Action package (Figure 13.6, page 90) to
change PrototypeRelationship into CodeRelationship: Modify superclass of UsesPrototype class in the text (section 13.18.1, page 90):
Superclass
CodeRelationship
Modify TypeRelations class diagram in the Action package (Figure 13.8, page 93) to
change TypeRelationship into CodeRelationship: Modify superclass of UsesType class in the text (section 13.10.1, page 93):
Superclass
CodeRelationship
Modify TypeRelations class diagram in the Action package (Figure 13.8, page 93) to
change TypeRelationship into CodeRelationship: Modify superclass of Imports class in the text (section 13.9.2, page 92):
Superclass
CodeRelationship
Modify MacroRelations class diagram in the Action package (Figure 13.9, page 94) to
change MacroRelationship into CodeRelationship:  Modify superclass of Expands class in the text (section 13.11.1, page 94):
Superclass
CodeRelationship
Modify PlatformInterfaces class diagram in the Platform package (Figure 19.6, page 158)
to change InterfaceRelationship into PlatformRelationship (since InterfaceRelationship
has been removed): Modify superclass of CompliesTo class in the text (section 19.8.1, page 158):
Superclass
PlatformRelationship
Modify EventRelations class diagram in the Events package (Figure 17.4, page 133) to
change MacroRelationship into CodeRelationship: Modify superclass of HasSignature class in the text (section 13.11.1, page 94):
Superclass
EventRelationship

Issue 9972: Section: 12.6.1 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM text mentions incorrect superclass for CallableUnit, BlockUnit, MethodUnit, (KDM text describes this a CodeElement, while it is in fact CallableElement, as defined in Figure 12.4).

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

(Changed text indicated by underlining)
Pg. 48, section 12.6.2 CallableUnit class
Superclass
CallableElement
Pg.49, section 12.6.3 BlockUnit class
Superclass
CallableElement
Pg/ 49, section 12.6.4 MethodUnit Class
Superclass
CallableElement

Issue 9973: Section: 12.6.6 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM defines OperatorUnit as a special subclass of CallableElement, together with CallableUnit, BlockUnit, MethodUnit and ConstructorUnit. There is little value in this element compared to a regular CallableUnit or a MethodUnit. The difference seems more syntactic. Suggestion - to eliminate this element in order to simplify the metamodel.

Resolution:
Revised Text: resolved see ptc/2007-03-04 for deails
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

The intention of KDM is to represent behavior and dependencies, especially across
compilation units. KDM is more about functionality than about syntax.
The rationale of CallableElement family and the corresponding action relations (like
Calls, Invokes, Uses, etc.) is to:
- represent dependency between containers
- provide the capability to track scenarios through calls
- identify packaging at the to-endpoint (what is being invoked)
- identify the ways how things are being invoked (at the from-endpoint)
Based on this, the current design is not balanced, as it provides too much differentiation
for the to-endpoint (in particular, there are special entities for Methods, Constructors and
Operators), but is generic enough at the from-endpoint (in particular, there are no entities
for various invocation kinds, like procedure calls, function call inside and expression,
constructor call, destructor call, and operator call).
According to the general guidelines, we decided to resolve the issue by reducing the
variation at the to-endpoint from OperatorUnit, ConstructorUnit and MethodUnit to
simply MethodUnit with an additional attribute to distinguish between regular methods,
constructors, destructors, and operators.
Related issues are 9976 (PrototypeUnit should be able to be owned by ClassUnit) and
10102 (ClassUnit should be flattened).
Changes:
Modify CallableUnits class diagram (Figure 12.4, page 48) by removing classes
OperatorUnit and ConstructorUnit, and adding an attribute �kind:MethodKind� to
MethodUnit and new enumeration MethodKind:    Delete sections 12.6.5 and 12.6.6. (page 49).
Add text describing the attribute �kind:MethodKind� to section 12.6.4, page 49:
The MethodUnit represents member functions owned by a ClassUnit, including userdefined
operators, constructors and destructors.
Attributes
kind:MethodKind Indicator of the kind of the method represented by this element
Add section describing enumeration MethodKind after section 12.6.4:
12.6.5. MethodKind (enumeration)
MethodKind enumeration defines additional specification of the kind of method, defined
by a MethodUnit model element.
Literal Values
method the MethodUnit represents a regular member function
constructor the MethodUnit represents a constructor destructor the MethodUnit represents a destructor
operator the MethodUnit represents an operator
unknown the kind of the MethodUnit is none of the above
Modify ClassTypes class diagram (Figure 12.15, page 65) by removing references to
classes OperatorUnit and ConstructorUnit

Issue 9974: Section: 12.7 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM defines Module (and its subclasses) as a subclass of CodeContainer, which means they inherit SourceRef association. However, this element is not defined at this level. It is only applicable to individual elemetns inside the Module.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Add semantic constraint to the Module element that it cannot have a SourceRef element.
Add constraint to section 12.7.1:
Constraints
.. Module class and its subclasses should not own SourceRef elements
Disposition: Resolved

Issue 9975: Section: 12.7 (iisue # 2) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

KDM defines Module (and its subclasses) as a subclass of CodeContainer, which does not enforce that semantically all individual code elements are supposed to be owned by some module. Suggestion - change the inheritance hierarchy Figure 12.5 and 12.2

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 158 - 160 for details

Issue 9976: Section: 12.8 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

KDM defines PrototypeUnit as CodeResource. However it should be moved into the TypeElement hierarch, so that it can be owned by ClassUnits. Figure 12.6

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 34 for deails

Issue 9977: Section: 12.6 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing examples of various CallableElements as KDM instances

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 242 - 243

Issue 9978: Section: 12.8 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing examples of PrototypeUnit and its usages as KDM instance

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

Issue 9979: Section: 12.10 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

KDM defines TemplateParameter as a subclass of CodeResource, but it should be a subclass of TypeElement in order to get correct usage relations. Figure 12.8.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 35 for deails

Issue 9980: Section: 12.10 (issue # 2) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Association templateElement between TemplateUnit and CodeResource at Figure 12.8. is too general. It says 0..*, but TemplateUnit can contain a single class or method.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 36 for deails

Issue 9981: Section: 12.10 (issue # 3) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

TemplateParameterowned by TemplateUnit should be ordered

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closeed issue

Discussion:

resolved see ptc/2007-03-04 page 37 for deails

Issue 9982: Section: 12.10 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of a TemplateUnit for class and method as KDM instance. Related to Figure 12.8

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04, page 349 - 353

Issue 9983: Section: 12.11 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 38/39 for deails

Issue 9984: Section: 12.11 (02) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel

Resolution: duplicate of issue 9983
Revised Text:
Actions taken:
July 26, 2006: received issue
August 2, 2006: closed issue

Issue 9985: Section: 12.12 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing general description of type representation in KDM, embracing sections 12.12-12.22

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Add the following text:
Data item representation of KDM is aligned with ISO/IEC 11404 (Language-Independent
datatypes) standard. KDM provides distinct meta-model elements for �data items� (for example,
global and local variables, constants, record fields, parameters, class members, array items and
pointer base elements) and �datatypes�. Each data item has an association �type� to its datatype.
KDM distinguishes primitive datatypes (for example integer, Boolean), complex user-defined
datatypes (for example, array, pointer, sequence) and named datatypes (for example, a class, a
synonym type). KDM meta-model elements corresponding to datatypes are subclasses of a
generic class Datatype. KDM meta-model elements corresponding to data items are subclasses
of a generic class StorableElement.
KDM model elements represent existing artifacts determined by a programming language. KDM
meta-model elements provide sufficient coverage for most common datatypes and data items,
common to programming languages. KDM also provides several powerful generic extensible
elements that can be further used with stereotypes to represent uncommon situations.
In addition to the type association, KDM relationship �HasType� is used to track named data
types. Anonymous data types are owned by the data item that uses it.
Concrete examples of datatypes, data items and the use of the type association and the HasType
relationship are provided further in the text of the specification.
Disposition: Resolved

Issue 9986: Section: 12.12 (02) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

Need new subclass of DerivedTypeElement to represent "synonym types", for example, in C: typedef int x;

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

This issue is resolved as part of the resolution to issue 9994 by introducing the so-called
DefinedTypes.
Disposition: Duplicate or merged

Issue 9987: Section: 12.12-12.17 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing examples of data types and their representations as KDM instances

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 244 - 254

Issue 9988: Section: 12.16 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

CompositeTypeElement should own an ordered list of fields. {ordered} is now missing in Figure 12.14

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

This is an oversight. The text of the specification mentions that both
CompositeUnit and UnionUnit define an �ordered collection� of types (fields and
variants, respectively).
Pg. 64, Figure 12.14 (changes indicated using a red pen)
Pg. 64, section 12.16.1 (added text is underlined)
Associations
Field:TypeElement[0..*] {ordered}
Disposition: Resolved

Issue 9989: Section: 12.18 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

Signature should have an (optional) association to the returned type, instead of ownership, since returned types are defiend elsewhere, and signature does not define a special name for it.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the resolution to a more general issue 9994 related to
representation of data items and distinction between data items (like variables) and data
types. In the resolution to 9994, formal parameter of a signature have uniform references
to their corresponding datatypes, instead of ownership.
Disposition: Duplicate or merged

Issue 9990: Section: 9.6.1 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Move InstanceKind enumeration data type from Core package to Code package, since it is only used in Code package. This will simplify development of class factories per each package.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 40 - 42 for deails

Issue 9991: Section: 12.18 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of CallableElements and their Signatures as KDM instance, illustrating corresponding KDM relations.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

Issue 9992: Section: 12.21 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of HasType relation as KDM instance

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Illustrated in the KDM data type examples (issue 9987). Merged with 9987.
Disposition: Duplicate or merged

Issue 9993: Section: 12.19-12.20 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of Interface and corresponding relations as KDM instance

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04, page 354 - 355

Issue 9994: Section: 9.6.1 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

Representation of data types and storable elements in KDM (aka "compressed data type representation") has a disadvantage: it is difficult to implement a query that lists all variables in a Code Model. KDM does not explicitly represent varibles. Instead, it represented various typeUnits with a additional kind attribute (of InstanceKind data type) that distinguishes for example, global variable, local variables, fields of a record, members of a class, formal parameters of a procedure, etc. In order to get the list of variables, one needs to iterate over all subtypes of a TypeElement (quite a few), and check the kind attribute. Suggestion: to "uncompress" the representation a little, by introducing an explicit StorableUnit element with attribute type that provides a reference to the corresponding type. This will still satisfy most of the goals of the "compressed representation", for example, low cost of representing complex derived types, and not tracking usages to predefined types through KDM relations (only relations to NamedTypes). This suggestion originates from an external reviewer, who is implementing KDM.

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 169 - 194 for details

Issue 9996: Section: 19 (02) (kdm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Howard Hess, h2@us.ibm.com hmhess1@yahoo.com)
Nature: Revision
Severity: Minor
Summary:

Need to relate platform activations and bindings to UI triggers

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is a duplicate of 10310. It refers to the same submitters issue id 2610200507.
Disposition: Duplicate or merged

Issue 9998: Section: 19.6 (kdm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mrs. Neta Aizenbud-Reshef, neta@il.ibm.com)
Nature: Revision
Severity: Minor
Summary:

DataResource is the same as DataManager, Figure 19.4

Resolution:
Revised Text:
Actions taken:
July 26, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 321 - 328

Issue 10100: Section: 9.7 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Move Extension and Annaotation diagrams from Core to Kdm package. Management of KDM packages can be optimized, if the Extension and Annotations diagrams are moved from the Core package into the Kdm package. This way, the Core package will contain abstract classes that define the meta-level facilties of KDM, and determine the meta-level API to KDM instances. The Kdm package, on the other hand, will contain concrete classes that are part of each KDM instance.

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

This change rationalizes the use of KDM packages, and does not affect the KDM XMI.
Move diagram, represented at Figure 9.5 at page 23 (classes KDMExtensionFamily,
Stereotype, TaggedValue, TagDefinition) and diagram, corresponding to Figure 9.6, page
26 (classes Attribute and Annotation) from Core package to kdm package.
Move section 9.7 after section 10.5. Move section 9.8 at the end of chapter 10.

Issue 10102: Section: 12.17 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Definition of ClassUnit should be flattened. Definition of ClassUnit (Figure 12.15) should be flattened, so that ClassUnit contains a single association to CodeResource. This will make Classunit more generic, for example, allow to use PrototypeUnit as a contained element, and will allow to make contents of ClassUnit ordered

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 47/48 for deails

Issue 10103: Section: 12,13 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Improve encapsulation of KDM models by associating KDM relationships with the from-endpoint. Encapsulation of KDM models can be improved by placing most KDM relationships into the elements that are the from-endpoints of these relationships, instead of associating these relationships with the whole model. Particularly, ActionRelationships should be owned by ActionElements; CodeRelationships should be owned by CallableElements. Currently, only FlowRelationships follow this principle (they are already owned by CallableElements). This will significantly reduce the number of KDM relationships that are contained directly by the each KDM model. The proposed revision will dramatically improve the readability of KDM instances in XMI (otherwise, each model is "flooded" by a flat set of KDM relationships).

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 100 - 110 for details

Issue 10104: Section: 12.9 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of MacroUnit and its usages in section 12.9

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04, page 341 - 346

Issue 10105: Section: 12.23 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of CommentUnit and its usages in section 12.23

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04, page 347 - 348

Issue 10106: Section: 12.24 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example of Visibility relationship in section 12.24

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Example is merged with Comments (see issue 10105).
Disposition: Duplicate or merged

Issue 10107: Section: 12 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Need special modeling element to represent initialization of data items. Currently there is no special special modeling element for initialization. This can be represented by ActionElements and Initializaes relationship. However, this solution proves to be not particularly readable and rather verbose. Introducing a special element for initialization will improve readability of KDM XMI instances.

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

This is resolved as part of the resolution to issue 9994
Disposition: Duplicate or merged

Issue 10108: Section: 12.14 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

Need special attribute to ArrayUnit to represent the size of the array. Currently there is no special special modeling element for representing size of the array as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the size of the array. This information is required in several queries against KDM models and is required for transformations of existing systems.

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the resolution to issue 9994.
Disposition: Duplicate or merged

Issue 10109: Section: 12.14 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Significant
Summary:

Need special attribute to RefinementUnit to represent the actual refinement. Currently there is no special special modeling element for representing the actual refinement of a data type (for example, the actual range in Ada) as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the refinement in RefinementUnit. This information is required in several queries against KDM models and is required for transformations of existing systems.

Resolution:
Revised Text:
Actions taken:
August 15, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the resolution to issue 9994.
Disposition: Duplicate or merged

Issue 10110: Section: 11.4.1 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Missing description of additional properties for SourceRef in SourceRegion diagram Section 11.4.1. SourceRegion class Diagram misses description of additional properties that are defined for class SourceRef (association from SourceRef to SourceRegions).

Resolution:
Revised Text:
Actions taken:
August 17, 2006: received isuse
July 30, 2007: closed issue

Discussion:

Add section 11.4.2 SourceRef (additional properties)
11.4.2 SourceRef (additional properties)
This association links a particular SourceRef element to the list of SourceRegion elements,
Associations
region:SourceRegion[0..*] {ordered} The list of SourceRegion elements that provide the physical
links to portions of the source code, corresponding to the SourceRef.
Semantics

Issue 10111: Section: 12.19 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Rename Interface class to InterfaceUnit. Section 12.19, page 67 defines class Interface. However the rest of the specification uses suffix xxxUnit for concrete model elements. Suggestion to rename Interface to InterfaceUnit

Resolution:
Revised Text:
Actions taken:
August 17, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 50/51 for deails

Issue 10115: Section: 9.7 page 23 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Allow multiple stereotypes for ModelElement Currently Figure 9.5 allow not more than one stereotype to be associated with each ModelElement. It is more convenient to have multiple stereotypes, so that extension can be split. This will avoid duplication in defining extensions. To resolve, corresponding multiplicty has to be changed from 0..1 to 0..*

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 52 for details

Issue 10116: Section: 9.7 page 23 (TaggedValue) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Allow TaggedValue that can refer to other KDM ModelElements Currently Figure 9.5 allow only TaggedValues with a String value. For some extensions it is convenient to add TaggedValues that contain a reference to other ModelElements. Resolution suggestion: introduce a supertype with two sublclasses, one - current TaggedValue with String value, another one, for example TaggedRef, with an association to ModelElement

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 161 - 163 for details

Issue 10117: Section: 10.5 page 34 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Typo in the attribute author of Audit class Spelled "duthor" instead of "author"

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 53 for details

Issue 10118: Section: 12.13 page 59 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Need to add void type to PredefinedTypeElement. This is needed to represent C/C++ casting to void*, and also will make signature more uniform

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 53 for details

Issue 10119: Section: 13 pages 75 - 95 (kdm-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Merge UsesType, UsesCallable and UsesData into a single more generic relationship Uses. This relationship is sufficient for tracking dependencies between components, without making fine distinction between the exact semantics of the usage, which can be further derived from the kind of the entity at the to-endpoint. There is not need to duplicate this information in the kind of the relationship

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 118 - 120 for details

Issue 10120: Section: 13.7 page 85 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Destroys relationship is not needed since it is simply a call to a destructor method. It should be removed from Figure 13.5

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

This is the consequence of consolidating constructors and regular methods. Now there is no need
for a special relation to a destructor. A regular Calls relation should be used instead.
Remove class �Destroys� from Figure 13.5, page 88. (See diagram in proposed resolution for
issue 10121).
Remove section 13.7.5 Destroys class, page 90.
Disposition: Resolved

Issue 10121: Section: 13.7 page 85 Creates relationship (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Creates relationship is is a relationship to a TypeElement (ClassUnit), rather than to a variable of that class. This is also different from the call to a particular constructor of that class. Example (C++): A x=new A(1); Pseudo KDM (ClassUnit name="A" id=id0 MethodUnit name="A" id=id3)) (IntegerUnit name="1" kind=constant id=id1) (NamedClassUnit name="x" kind=variable id=id4) (HasType from=id4 to=id0) (ActionElement id=id2) (Creates from=id2 to=id0) (Reads from=id2 to=id1) (Calls from=id2 t=id3) (Writes from=id2 to=id4)

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 57-58 for details

Issue 10122: Section: 13.3 page 76 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Unnecessary abstract classes for relationships in Action package. Action package defines 4 unnecessary asbstract relationships: CallableRelationship, MacroRelationship, ImportRelationship and DataRelationship. Originally they were introduced as potential extension hotspots, but later they were made abstract because of the overall KDM pattern and CMOF, so they are now completely redundant. Removing them will simplify KDM. This does not affect existing KDM XMI. Recommendation to promote CallableRelationship and DataRelationship to ActionRelationship and other two - to CodeRelationship (with the possibility for their from-endpoint to own them in order to achieve better encapsulation of the model).

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 59 -  61 for details

Issue 10124: Section: 12.17 page 65 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Need better support for virtual methods. Recommendation: special call action and a special MethodKind

Resolution:
Revised Text:
Actions taken:
August 22, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 164 for details

Issue 10125: Section: 15.3 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

abstract element ProgramElement should be subclassed by DataElement and CodeElement (rather than only CodeResource), since it is necessary to allow ActionElement to be included into definition of ConceptualGroup

Resolution:
Revised Text:
Actions taken:
August 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 62 - 63 for details

Issue 10132: Section: 14 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing example(s) for the Build package illustrating extraction of various elements and their representation as KDM XMI instances

Resolution:
Revised Text:
Actions taken:
August 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Example is provided as part of the resolution to issue 10179
Disposition: Duplicate or merged

Issue 10136: Unnecessary abstract classes for relationships in Platform package (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Unnecessary abstract classes for relationships in Platform package. Platform package defines 3 unnecessary abstract classes for KDM relationships: TechnologyRelationship, ExternalRelationship and ResourceRelationship. Originally, these classes were introduced as potential extension hotspots. However they are required to be abstract, so they became unnecessary. Recommendation: to remove these unnecessary classes to simplity the KDM metamodel. This does not affect KDM XMI. Usages of these relationships should be promoted to PlatformRelationship class.

Resolution:
Revised Text:
Actions taken:
August 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 64 - 69 for details

Issue 10137: Section: 19.11 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Missing description of the class UsesResource in section 19.11 (correspondign to Figure 19.9

Resolution:
Revised Text:
Actions taken:
August 23, 2006: received issue
July 30, 2007: closed issue

Discussion:

Add section between 19.11.6 and 19.11.7:
19.11.7. UsesResource Class
UsesResource relationship is a met-model element that represents various platform-specific
relations between platform services and individual resource instances.
Superclass
PlatformRelationship
Associations
from:PlatfromService[1]
to:ResourceInstance[1]
Constraints
Semantics
Disposition: Resolved

Issue 10148: Section: 21.4 (kdm-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Vitaly B. Khusidman, vitaly.khusidman@unisys.com)
Nature: Enhancement
Severity: Significant
Summary:

Inability to create relationships between ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping (e.g. based on computational dependency) between ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific TermUnit or FactUnit has business significance and to define the correspondent Term or Fact in the Business Rules Model. However, KDM does not provide means to define a relationship between ConceptualElements.

Resolution:
Revised Text:
Actions taken:
August 31, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
Merged with issue 10149.
Disposition: Duplicate or merged

Issue 10149: Section: 22.4 (kdm-ftf)

Click here for this issue's archive.
Source: Unisys (Dr. Vitaly B. Khusidman, vitaly.khusidman@unisys.com)
Nature: Enhancement
Severity: Significant
Summary:

Inability to create relationships between BehaviorElements and ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping from BehaviorElement (e.g. RuleUnit) to ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific RuleUnit has business significance and to define the correspondent Rule in the Business Rules Model. However, KDM does not provide simple means to define a relationship between BehaviorElements and ConceptualElements.

Resolution:
Revised Text:
Actions taken:
August 31, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 267 - 279

Issue 10283: Section: 12.18 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 0510200504 for submitters database Originally raised by Larry Hines (EDS) Distinguish parameter passing variants Add attributes to Signature parameters, like ParameterKind with values ByName, ByValue. This will provide a capability to distinguish various forms of parameter passing.

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue has been resolved as part of the resolution for the issue 9994. Special
StorableElement called ParameterUnit was introduced to represent formal parameters of
signatures. It has a kind attribute with type enumeration ParameterKind (byname,
byValue, byReference, return).
Disposition: Duplicate or merged

Issue 10284: Section: 12 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 0308200503 from submitters database Originally raised by Mike Smith (EDS) Add a general "depends" relationship between two CodeEntities

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

This issue is merged with 10330 and 10322 and the resolution will be provided in 10322.

Issue 10285: Section: 12 (02) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1309200505 from submitters database Originally raised by Nick Mansourov consistency of models wrt source ref in case of macros (links to fully expanded macro and source of macros).

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 257 - 266

Issue 10286: Section: 12, page 41-74 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 2009200501 from submitters database Originally raised by Nick Mansourov representation of variants (conditional compilation

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
The resolution to this issue is consolidated with the resolution to issue 10285.
Disposition: Duplicate or merged

Issue 10287: Section: 12, page 41-74 (02) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 0602200602 from submitters database Originally raised by Adam Neal (Klocwork) Role names "class", 'interface' and 'package' are reserved Java keywords. They introduce conflicts during JMI generation

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue has been already resolved in KDM 1.0.
Disposition: Closed, no change

Issue 10289: Section: 12, page 41-74 (04) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Clarification
Severity: Minor
Summary:

Issue 1703200603 from submitters database Originally raised by Nick Mansourov Review the semantics and usages of CodeGroup. Missing examples of the usage of CodeGroup.

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 132 - 133 for details

Issue 10290: Section: 13.4 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 0302200602 from submitters database Originally raised by Nick Mansourov Action Containers are missing

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved see ptc/2007-03-04 page 134 - 135 for details

Issue 10292: Section: 17 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1410200505 from submitters database Originally raised by Nick Mansourov introduce precise actions for triggering

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

resolved, see ptc/2007-03-04 page 314 - 320

Issue 10295: Section: 18 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1410200504 from submitters database Originally raised by Nick Mansourov introduce precise actions for UI

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the UI package will have
more clear Resources and ResourceActions, with a clear separation from the Program Elements
layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 10296: Section: 18 pages 137 - 148 (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1703200601 from submitters database Originally raised by Nick Mansourov DisplayUnits should be groups for Triggers

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 10298: Section: 18 pages 137 - 148 (03) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1703200604 from submitters database Originally raised by Pete Rivett (Adaptive) UIContainer should be a Group for triggers

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301
Disposition: Duplicate or merged

Issue 10299: Section: 18 pages 137 - 148 (04) (kdm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick@kdmanalytics.com)
Nature: Revision
Severity: Minor
Summary:

Issue 1703200605 from submitters database Originally raised by Nick Mansourov Change CallableElement to ActionElement in Displays relation in UI package

Resolution:
Revised Text:
Actions taken:
September 3, 2006: received issue
July 30, 2007: closed issue

Discussion:

Discussion:
This issue is resolved as part of the L1 resource layer reform, where the platform package will
have more clear Resources and ResourceActions, with a clear separation from the Program
Elements layer. Resolution to this issue is provided in the consolidated issue 10301.
Disposition: Duplicate or merged

Issues for Mailing list of the ADM Knowledge Discovery Metamodel Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 9911: Section: 10.3, 10.4 (kdm-ftf)

Issue 9912: Section: 10.5 (kdm-ftf)

Issue 9965: Section: 11.3 (kdm-ftf)

Issue 9966: Section: 11.4 (kdm-ftf)

Issue 9967: Section: 9.4 (kdm-ftf)

Issue 9968: Section: 9.5 (kdm-ftf)

Issue 9969: Section: 9.7.1 (kdm-ftf)

Issue 9970: Section: 9.7.1 (issue # 2) (kdm-ftf)

Issue 9971: Section: 12.5 (kdm-ftf)

Issue 9972: Section: 12.6.1 (kdm-ftf)

Issue 9973: Section: 12.6.6 (kdm-ftf)

Issue 9974: Section: 12.7 (kdm-ftf)

Issue 9975: Section: 12.7 (iisue # 2) (kdm-ftf)

Issue 9976: Section: 12.8 (kdm-ftf)

Issue 9977: Section: 12.6 (kdm-ftf)

Issue 9978: Section: 12.8 (kdm-ftf)

Issue 9979: Section: 12.10 (kdm-ftf)

Issue 9980: Section: 12.10 (issue # 2) (kdm-ftf)

Issue 9981: Section: 12.10 (issue # 3) (kdm-ftf)

Issue 9982: Section: 12.10 (kdm-ftf)

Issue 9983: Section: 12.11 (kdm-ftf)

Issue 9984: Section: 12.11 (02) (kdm-ftf)

Issue 9985: Section: 12.12 (kdm-ftf)

Issue 9986: Section: 12.12 (02) (kdm-ftf)

Issue 9987: Section: 12.12-12.17 (kdm-ftf)

Issue 9988: Section: 12.16 (kdm-ftf)

Issue 9989: Section: 12.18 (kdm-ftf)

Issue 9990: Section: 9.6.1 (kdm-ftf)

Issue 9991: Section: 12.18 (kdm-ftf)

Issue 9992: Section: 12.21 (kdm-ftf)

Issue 9993: Section: 12.19-12.20 (kdm-ftf)

Issue 9994: Section: 9.6.1 (kdm-ftf)

Issue 9996: Section: 19 (02) (kdm-ftf)

Issue 9998: Section: 19.6 (kdm-ftf)

Issue 10100: Section: 9.7 (kdm-ftf)

Issue 10102: Section: 12.17 (kdm-ftf)

Issue 10103: Section: 12,13 (kdm-ftf)

Issue 10104: Section: 12.9 (kdm-ftf)

Issue 10105: Section: 12.23 (kdm-ftf)

Issue 10106: Section: 12.24 (kdm-ftf)

Issue 10107: Section: 12 (kdm-ftf)

Issue 10108: Section: 12.14 (kdm-ftf)

Issue 10109: Section: 12.14 (kdm-ftf)

Issue 10110: Section: 11.4.1 (kdm-ftf)

Issue 10111: Section: 12.19 (kdm-ftf)

Issue 10115: Section: 9.7 page 23 (kdm-ftf)

Issue 10116: Section: 9.7 page 23 (TaggedValue) (kdm-ftf)

Issue 10117: Section: 10.5 page 34 (kdm-ftf)

Issue 10118: Section: 12.13 page 59 (kdm-ftf)

Issue 10119: Section: 13 pages 75 - 95 (kdm-ftf)

Issue 10120: Section: 13.7 page 85 (kdm-ftf)

Issue 10121: Section: 13.7 page 85 Creates relationship (kdm-ftf)

Issue 10122: Section: 13.3 page 76 (kdm-ftf)

Issue 10124: Section: 12.17 page 65 (kdm-ftf)

Issue 10125: Section: 15.3 (kdm-ftf)

Issue 10132: Section: 14 (kdm-ftf)

Issue 10136: Unnecessary abstract classes for relationships in Platform package (kdm-ftf)

Issue 10137: Section: 19.11 (kdm-ftf)

Issue 10148: Section: 21.4 (kdm-ftf)

Issue 10149: Section: 22.4 (kdm-ftf)

Issue 10283: Section: 12.18 (kdm-ftf)

Issue 10284: Section: 12 (kdm-ftf)

Issue 10285: Section: 12 (02) (kdm-ftf)

Issue 10286: Section: 12, page 41-74 (kdm-ftf)

Issue 10287: Section: 12, page 41-74 (02) (kdm-ftf)

Issue 10289: Section: 12, page 41-74 (04) (kdm-ftf)

Issue 10290: Section: 13.4 (kdm-ftf)

Issue 10292: Section: 17 (kdm-ftf)

Issue 10295: Section: 18 (kdm-ftf)

Issue 10296: Section: 18 pages 137 - 148 (kdm-ftf)

Issue 10298: Section: 18 pages 137 - 148 (03) (kdm-ftf)

Issue 10299: Section: 18 pages 137 - 148 (04) (kdm-ftf)

Issue 10300: Section: 18 pages 137 - 148 (05)