Issues for ADM KDM Revision Task Force

List of Open Issues. Other options: All Issues; Closed Issues.

(red=unresolved; yellow=pending Board vote)

Need traceability for indirect messaging relations in Platform package, as per example used in the tutorial. 

Deferred to RTF

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

Correct text:
Section 9.3.3, Page 17, description of the first association.
Change owner:KDMContainer[0..1] into owner:KDMEntity[0..1]
Change “KDM container that…” into “KDM entity that …”.
Change “Every specific KDM container defines…” into “Some KDM entities define …”
Disposition:

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.

Correct text
Correct text:
Section 9.3.3, Page 17, description of the second association.
Change group:KDMGroup[0..*] into group:KDMEntity[0..*]
Change “Set of KDM groups with which…” into “Set of KDM entities with which …”.
Change “Every specific KDM group defines…” into “Some KDM entities define …”
Add clarification to the second paragraph of 9.3.3 that introduces containers and groups:
A KDMEntity can be either an atomic element, a container for some KDMEntities, or a group of some
KDMEntities. Container and group introduce implicit relationships between entities and are used to
represent hierarchies of entities. A container is a KDMEntity that owns other entities. A group is a
KDMEntity with which other entities are associated. A KDMEntity can be owned by at most one container,
and can be associated with zero or many groups.

9.3.3 getOwnerElement is misnamed - should be getOwnedElement.

Correct text
Change getOwnerElement into getOwnedElement

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!

Deferred to next RTF to allow more discussion

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

Correct text; remove inconsistent constraint

10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.

Defer to the next RTF to assemble a more compelling package that justifies the change to the
KDM XMI schema

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

The original posting was incorrectly mentioning section 10.3.1 instead of 10.3.4
Correct text of the description of the segment property:
Instances of KDM entities owned by the model. Each KDM model defines specific subclasses of
KDMEntity class. Nested Segment elements owned by the current Segment.
KDMFramework class is extended by KDMSegment Segment and KDMModel classes. Each KDM
Framework is the container for KDM light-weight extensions (extension property).

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

Correct KDM XMI with correct namespaces for xmi and KDM packages
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:core="http://schema.omg.org/spec/KDM/1.1/core"
xmlns:kdm="http://schema.omg.org/spec/KDM/1.1/kdm"
xmlns:source="http://schema.omg.org/spec/KDM/1.1/source"
xmlns:code="http://schema.omg.org/spec/KDM/1.1/code"
xmlns:action="http://schema.omg.org/spec/KDM/1.1/action"
xmlns:data="http://schema.omg.org/spec/KDM/1.1/data"
xmlns:event="http://schema.omg.org/spec/KDM/1.1/event"
xmlns:ui="http://schema.omg.org/spec/KDM/1.1/ui"
xmlns:platform="http://schema.omg.org/spec/KDM/1.1/platform"
xmlns:conceptual="http://schema.omg.org/spec/KDM/1.1/conceptual"
xmlns:structure="http://schema.omg.org/spec/KDM/1.1/structure"
xmlns:build="http://schema.omg.org/spec/KDM/1.1/build"
pages: 29, 34, 50, 69, 85, 88, 98, 103, 106, 116, 118, 120, 121, 125 138, 144, 154,219 221, 230,
239, 244, 271, 287

10.4 would be better to have a proper 'date' type rather than using String. This could be properly mapped to the XML Schema type for validation.

Deferred to next RTF to allow more discussion

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.

Make clarification in the text.
Change text:
description:String Contains the description of the model element Framework element.
Audit element can be own Annotation elements and Attribute elements. The Audit.description is the
primary description and any associated annotations may be used as optional secondary descriptions.

Validate KDM examples in the KDM specification usign the KDM SDK validator tool and make corrections

Deferred to next RTF

throws example in the spec is incomplete

Deferred to the next RTF

Consider Uniform representation of exception object and classes as they are being thrown
    (check out Ada, it uses and extendable enumerated class)

Deferred to the next RTF to allow more discussion

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

Add Guard micro action kind to represent things like “case 1:”
Guard represents
start of the
branch of a
complex
condition
Single Reads
relation to a
DataElement
representing
the guard
value
none Single flow
unconditional
control flow
to the first
action of the
brach

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

Generalize the “to” endpoint of HasValue relationship from CodeItem to AbstractCodeElement to
allow both ValueElement and ActionElement as endpoints.
This is a conservative extension that does not affect existing KDM XMI. Change text section 12.19.2 page 106:
The HasValue is a specific meta-model element that represents semantic relation between a data element
and its initialization data element element, which can be a data element or an action element for complex
initializations that involve expressions. HasValue is an optional element that compliments the real
initialization semantics by a sequence of action elements in the initialization code.
The target datatype AbstractCodeElement.
Constraints:
1. If the target of the HasValue is an ActionElement then this ActionElement should have an
outgoing Writes relationship to the CodeItem that is the the source of the Hasvalue relationship
Semantics: The target of the HasValue relationship can be a Value for simple initializations that involve
constants, or Data Element for simple initializations that involve another data element, or an
ActionElement that writes to the source element for complex initializations involving expressions.

PtrCall for callable units and method units a->foo() 
   or should it be only used for callable units; while for method units is a VirtualCall ?
   relationship is Dispatches, not Calls
   The text of the specification needs to be made more clear

Defer to the next RTF due to the lack of time

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

Add clarification to the text
Page 154
Action Kind - is nature of the operation performed by the micro action. This is represented as a “kind”
attribute to the micro action. The action kind may designate certain outgoing relationships as part of the
Control. For example, the “call” “Call” micro action designated designates the Calls outgoing relationship
as part of Control. Action kinds are defined as case sensitive strings in Annex A.

Call via pointer example: need pointer type in type unit fp

Defer to the next RTF.

For discussion. When transforming procedures to methods KDM objects needs to be changed, it is not as easy as moving 
something to class. We should consider having a StorableUnit and CallableUnit, maybe with an explicit kind. 
This will leave the only distincltion between them in micro actions.

Defer to the next RTF.

specify which characterset is used for chartype or provide the capability to extend
Issues in KDM representation of funny Unicode symbols back and forth. Need some sort of translation. And need to
specify what it the canonical representation in KDM ?
Text needs to be made more specific.

Defer to the next RTF.

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.

There are two alternatives: just have UsesType to the Datatype, or allow also Reads to
DataElement (in the later case the processor should be able to calculate the type from the
expression first):
Sizeof Determines
the length
of a
DataElement
(based on
the
datatype) or
the length of
a Datatype
Reads
represents the
DataElement; or
UsesType
writes to
a
DataElement
Single
flow to
the next
micro
action
Disposition:

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

There is a typo in Table A.6. It mentions UsesCode relationship instead of UsesType.
Correct text in Table A.6 page 299:
Instanceof Performs
dynamic
type check if
the data
element is of
a certain
datatype
Reads
represents the
DataElement;
UsesType
relation
represents the
datatype
Writes to a
DataElement
of a
Boolean type;
Single
flow to
the next
micro
action
DynCast Performs a
dynamic
cast of a
DataElement
to a certain
Datatype
Reads
represents the
DataElement;
UsesType
relation
represents the
datatype
Writes to a
DataElement
Single
flow to
the next
micro
action
TypeCast Performs a
static type
conversion
of a
DataElement
to a
certain
Datatype
Reads
represents the
DataElement;
UsesType
relation
represents the
datatype
writes to
a
DataElement
Single
flow to
the next
micro
action

There is an ambiguity between BlockItem and micro action compound. The specification text has to be made 
more clear

Defer to the next RTF.

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.

Initialization block? Maybe need a special ControlElement for it. Maybe represent it with a BlockUnit 
not a CallableUnit. What is the semantics of passing control to other init blocks? The text needs to be made more 
clear

In Initialization example do not need to use extern in the names

Defer to the next RTF.

Variable d2 in main in compilation unit b.cpp does not have a HasValue relation; need to see how to represent
constructor calls.

Defer to the next RTF.

name of CompilationUnit should not contain extension. The text should make that more explicit and the 
exampel needs to be changed.

Defer to the next RTF to allow more discussion

Association between CompilationUnit and SourceFile other than through SourceRef.

Defer to the next RTF to allow more discussion

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

Correct text:
Writes and single Flow are optional in most cases. Add word optional to the description of the
micro elements where appropriate.
Page 291 in front of table A.1
Optional Writes .. (no Writes corresponds to an expression statement, where the result of the
operation is ignored; otherwise the result should be stored into a DataElement, which can be
permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an
ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind)
Optional single flow … (no Flow corresponds to the terminal action)
Page 292 in front of table A.2
Optional single Writes … (no Writes corresponds to an expression statement, where the result of
the operation is ignored)
Optional single flow …
Page 292 in front of table A.3:
Optional single Writes …
Optional single Flow …
Assign: optional single flow
Call: subsequently – an optional single flow …
MethodCall: subsequently an optional single flow …
PtrCall –subsequently an optional single flow to the next micro action is performed
VirtualCall – subsequently an optional single flow …
Condition (in the writes column) none
Return (in the writes column) none
Nop – optional single flow
Incr – optional single flow
Decr – optional single flow
Switch – an optional single flow
Page 297 Table A.5
Remove last column
Add description of the Control in front of the table:
Inputs – see table
Outputs – see table
Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)
Move the semantics comment from the control column in the second column for the “New” micro
element:
This micro operation does not invoke the constructor of the new object;
FieldSelect, ChoiceSelect, Ptr, PtrSelect, ArraySelect, MemberSelect – optional Writes …Page 299 Table A.6
Remove last columns
Add description of the control in front of the table:
Inputs – see table
Outputs – see table
Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)
InstanceOf, DynCase – optional Writes …
Page 300, table A.7
Remove last 2 columns
Add description of the writes and control in front of the table
Inputs – see table
Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement,
where the result of the operation is ignored; otherwise the result should be stored into a
DataElement, which can be permanent, for example a StorableUnit with a kind other than
“register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a
“register” kind)
Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)
Page 301, table A.8
Remove last 2 columns
Add description of the writes and control in front of the table
Inputs – see table
Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement,
where the result of the operation is ignored; otherwise the result should be stored into a
DataElement, which can be permanent, for example a StorableUnit with a kind other than
“register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a
“register” kind)
Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)
Page 302, table A.9
Remove last 2 columns
Add description of the writes and control in front of the table
Inputs – see table
Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement,
where the result of the operation is ignored; otherwise the result should be stored into a
DataElement, which can be permanent, for example a StorableUnit with a kind other than
“register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a
“register” kind)
Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)
Page 303, table A.10
Remove last 2 columns
Add description of the writes and control in front of the table
Inputs – see table
Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement,
where the result of the operation is ignored; otherwise the result should be stored into a
DataElement, which can be permanent, for example a StorableUnit with a kind other than
“register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a
“register” kind) Controls – optional single Flow to the next micro action (no Flow means a terminal action
element)

change text for the arrayselect "single" reads

There is a typo in Table A.5 page 297 in specification of ArraySelect.
Correct text in Table A.5 page 297
ArraySelect Access to a
particular
ItemUnit of
an
ArrayType
Single
Addresses
relationship to a
DataElement (of
an ArrayType);
Single Reads
relationship to
an
ItemUnit
representing the
ItemUnit
being accessed;
Last Reads
represents
the Index
Writes
relationship
represents the
DataElement
(except for
a
ValueElement)
to which
the value of the
ItemUnit
is assigned
Single flow
to the next
micro
action

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"?

This operator is used to resolve the scope of names in situations when the name of the formal
parameter is the same as the name of the class member. For example:
set(a) {this.a =a; }
// Take a const-reference to the right-hand side of the assignment.
// Return a non-const reference to the left-hand side.
MyClass& MyClass::operator=(const MyClass &rhs) {
... // Do the assignment operation!
return *this; // Return a reference to myself.
}
MyClass& MyClass::operator=(const MyClass &rhs) {
// Only do assignment if RHS is a different object from this.
if (this != &rhs) {
... // Deallocate, allocate new space, copy values...
}
return *this;
}
Add micro operation
this no reads or addresses; writes to a data element of the class datatype;
This pointer to
the current
instance of
the object
none Writes to a
DataElement
Single flow
to the next
micro
action

variables that are declared at the header of the loop needs special care in KDM. Suggestion: to use VisibleIn 
relationship in addition to a compound statement for loop. Need an additional example

Defer to the next RTF

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

Add clarification to the text
Multidimensional arrays can be represented where an ItemUnit is referencing an anonymous ArrayType
that represents internal dimensions(s). The IndexItem of the ArrayType that owns an internal anonymous
ArrayType precedes the IndexItem of the owned ArrayType.
Multidimensional array are represented by nested ArrayType elements, in which the top ArrayType
represents the first (outer) dimension, and its ItemUnit has type ArrayType that represents the next
(internal) dimension and so on.

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.

Table A.4 page 295.
Throw raise
exception
zero or more
Reads
relationships to
DataElements
representing
actual
parameters to
the
the
the exception
object being
thrown
none Throws relationship to the
datatype DataElement that
represents the "exception
object".
Optional ExceptionFlow
relationship to a CatchUnit
that processes the
exception
Disposition: Resolved

Representation of a stand-alone comment (not associated with a particular CodeElement)

Defer to the next RTF

Clarify the text regarding the distinction between the explicit relationship and the built-in relationships

Defer to the next RTF

Clarify the algnment with SBVR, update references to the current SSBVR specification

Defer to the next RTF due to the lack of time

Clarify alignment of the KDM Core with RDF

Defer to the next RTF due to the lack of time

The file is invalid XML, since for the 'type' attribute of Operations it omits spaces after the closing quote of the previous value.
For example line 784 is:
        <ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*'type='C.6698801' />


Proposed resolution
Insert space before 'type=' in all Operation definitions. The above line becomes:
        <ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*' type='C.6698801' />

The CMOF and XMI namespaces are incorrect (they include an extra 'www') 
Line 1 of the file is:
<XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1"> 


Proposed resolution
Include correct namespace definitions, so that the above line becomes:
<XMI xmlns:xmi="http:// schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">

Signature and SourceFile are used as both Class and Association names in the same package: this is not permitted by CMOF constraints


Proposed resolution
Rename these associations to SignatureType and SourceFileRegion respectively 


Line 256 is currently:
      <ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='Signature'>
And should become
      <ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='SignatureType'>


Line 1083 is currently:
      <ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFile'>
And should become:
      <ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFileRegion'>

Association A.62 has an owned end is called 'model ' (trailing space), which is inconsistent and invalid for generating language bindings


Proposed resolution
Remove the trailing space


Line 347 is currently:
        <ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model ' lower='0' upper='1' isComposite='false' association='A.62' />
And should become
        <ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model' lower='0' upper='1' isComposite='false' association='A.62' /> 

Many associations and association ends are given meaningless generated names, like A.0, P.G.307. Since these will be used for the generated language bindings, and are required for traversing and accessing models, these names are not usable. In addition, the inclusion of '.'s in the names makes unnecessary for language bindings since they are not valid Java names.


For example lines 4 and 5 illustrate the names:
      <ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707'  name='A.2' general='A.3'>
        <ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='P.D.14122707' lower='1' upper='1' isComposite='false' association='A.2' />


Proposed resolution:
Generate meaningful names for these elements, using the same algorithm as UML2, which is as follows (from section 6.4 of formal/07-11-02)


* 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. (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 they may be needed for other purposes, such as MOF language bindings that use the metamodel.)


* Associations that are not explicitly named, are given names that are constructed according to the following production
rule: "A_" <association-end-name1> "_" <association-end-name2>
where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of
the second association end.


As an example, lines 4 and 5 would become:
      <ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707'  name='A_actionElement_actionRelation' general='A.3'>
        <ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='actionElement' lower='1' upper='1' isComposite='false' association='A.2' />

Several association ends are both 0..* and composite owners. This is not only an invalid combination but is inconsistent with the specification document and Rose model used for that. This seems to affect the ends that {subset group} (that in the XMI contain "subsettedProperty='P.O.6222315' ")


For example, line 172 of the file is:
        <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.35' />
The fact that this has isComposite='true' is inconsistent with Figure 21.3 of ptc/08-02-08 (the KDM 1.1 spec document) which has no black diamond on the line between BuildResource and Group. 


Proposed resolution
Make all Properties that {subset group} have isComposite='false'
For example, the above line 172 would become:
        <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='false' association='A.35' />