KDM has several instances of MOF enumerations. The model shall represent them as MOF enumerations, rather than as MOF classes with a hardcoded stereotype "<<enumeration>>"

Refactor MOF enumerations and update diagrams in the specification

Currently MOF enumerations are represented as UML classes with a hardcoded stereotype "<<enumeration>>". Instead, they should be represented directly as instances of MOF Enumeration. The figures need to be replaced because of a slightly different look an feel of proper MOF Enumerations. Otherwise the specification text is correct.

Currently the KDM spec references an old XMI version 2.1
The current is 2.4.2
This affects examples in the specification text as well as KDM XMI XSD

Update example to new version of XMI and KDM

The new format of standard references for XMI 2.4.2 schema files is :
XMI namespace URI http://www.omg.org/spec/XMI/20110701
XMI xref URI http://www.omg.org/spec/XMI/20110701/XMI-model.xmi

According to standard format of OMG references, each KDM 1.4 package
has own namespace URI, with the common base
http://www.omg.org/spec/KDM/20160501
followed by the package name.

For example, for KDM Core package
XMI namespace URI http://www.omg.org/spec/KDM/20160501/core
XMI xref core.xsd

Use of references in XSD schema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:core="http://www.omg.org/spec/KDM/20160501/core"
xmlns:kdm="http://www.omg.org/spec/KDM/20160501/kdm"
xmlns:source="http://www.omg.org/spec/KDM/20160501/source" targetNamespace="http://www.omg.org/spec/KDM/20160501/source" >

<xsd:import namespace="http://www.omg.org/spec/KDM/20160501/core" schemaLocation="core.xsd" />
<xsd:import namespace="http://www.omg.org/spec/KDM/20160501/kdm" schemaLocation="kdm.xsd" />

Use of references in KDM XMI document
<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment
xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
xmlns:core="http://www.omg.org/spec/KDM/20160501/core"
xmlns:code="http://www.omg.org/spec/KDM/20160501/code"
xmlns:kdm="http://www.omg.org/spec/KDM/20160501/kdm"
name="Stereotype Example">

In KDM 1.3 the predefined datatypes used to be instances of MOF datatype. According to KDM14-12 this has been changed to PrimitiveType. However, following up the discussion at the AM meeting on March 26, 2015, using MOF datatype is a more appropriate decision.

Revert predefined types to MOF datatype

the 3 datatype from Core shall be referred to as "predefined" datatypes to distinguish from primitive datatypes in Code model

Several corrections to the resolution text of KDM14-289 based on the feedback from the production of the MOF model

Make editorial changes to the specification text

Make editorial changes to the specification text, with reference to the text introduced by KDM14-289 and the sections of the KDM-1.4 draft. In the changebar document the corrections are marked as KDM14-289

Strictly speaking end ownership should be used for generating operators not navigability. e.g. if the property is an ownedAttribute of the class, not whether it's navigable.

Clarify specification text regarding association end ownership

From Pete Rivett:
Navigability is an implementation hint that the navigation should be efficient.
It is quite conceivable to have an ownedAttribute which is not seen an important for it to be efficient (e.g. the implementation might iterate through all instances of the target to look for a link to the source).
Likewise there might be an end owned by association where efficiency is important but there is no ownedAttribute – especially for cross-metamodel associations (or those involving MOF Element) where it is not allowed to add an ownedAttribute to an external metamodel or MOF itself.

Though KDM may have a pattern that always combines ownership and navigability, the specification should reference ownership.
What I’m looking for to resolve my issue is:

• Use ownership not navigability in the text
• Use the dot notation in the diagrams to show end ownership

Overview of the proposed resolution:
Modify the specification text of section 6.2.1 Diagram format according to the suggestion by Pete. Do not use the dot notation in the diagrams, as the convention of the diagrams is fully described in section 6.2.1, the pattern is consistent, and last but not least, introducing the dot notation involves a massive change to the specification text. Instead, add text to the key semantic sections in the kdm core, emphasizing association end ownership.

There is an inconsistency between the documentation in the KDM build package and the example in the section.

The example shows a BuildStep consuming it's input source elements which are classified as BuildComponent.

In the description for BuildComponent we have: "The BuildComponent class represents binary files that correspond to deployable components, for example executable files."

Obviously the input source elements being consumed in the example are .c and .h files, which are not binary.

So is BuildComponent the right class to use for input source elements or is the description of the class incorrect?

Add definitions of BuildComponent, BuildProduct, Library

Rename Library to BuildLibrary for consistency.
The description of BuildProduct and BuildLibrary are missing. Definition of a BuildComponent is actually related to (missing) BuildProduct. A BuildProduct defines the product of a build process.
A Library is a collection of InventoryItems (usually BinaryFiles, or SourceFiles) which is used as an intermediate product of a build process.
BuildComponent can be described as any collection of InventoryItems. A BinaryComponent defines SourceFlles as inputs to BuildSteps or any other anonymous collections of resources as they are used as inputs of outputs of a build process.
The intention is to identify sources and targets of BuildStep as sets of InventoryItem (in fact, the definition is more general and will accept any KDMEntity).

With this interpretation the example on page 306 is correct.

In the platform package we don't seem to have any direct way to express relations between AbstractPlatformElement and InventoryElement. A good example is how to describe the file in the inventory model that represents a certain deployed component.

AbstractPlatformElement has a source relation to a SourceRef but here we're not dealing with a Source inventory element (not sure how often PlatformElement would really need this relation). The Build package uses the implementation relation which points to KDM entity to describe relations to inventory elements. Again here in the platform package this points to AbstractCodeElement only.

I hate to have to use stereotypes to build such a basic relation.

Add TraceableTo relation to Inventory model

In order to support arbitrary traceability links to InventoryItems, we use Figure 11.3, page 59 and add relation "TraceableTo" from KDMEntity to InventoryItem.

In section 21.5, BuildResource class diagram, the class Library and BuildProduct are described in the diagram 21.3 but have no description in the text of the specification. However references can be found in examples and they are part of the XMI model.

I believe that standard documentation sections should be added for these classes.

Merge with KDM14-70

This issue is merged with KDM14-70

After changes from Ballot 11 in 2007, the micro-KDM the documentation was not updated to reflect the fact that the invokes relationship didn’t exist anymore.

We currently still have 4 micro-KDM actions that describe Invokes relationships:

MethodCall, VirtualCall, MemberSelect, MemberReplace.

These need to be changed to the Adresses relationship at the very minimum.

Change Invokes to Addresses

Change specification text to replace 4 occurrences of "Invokes relationship" into "Addresses relationship". One occurrence has been changed as part of resolution to issue 14-79

In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement

Change superclass of MethodUnit to ControlElement

The correct superclass of MethodUnit is ControlElement as in the model. The specification text should be corrected.

The references to UML, MOF and XMI in the KDM 2.2 are not appropriate.

The references to 19502:2005 and 10503:2005 are not used anywhere in the spec and should be removed.

The ref to MOF should be to the actual version used.

The proposed resolution below assumes the Latest Versions used are MOF 2.0 and XMI 2.1.1.

Proposed solution:

In section 3

Change:
“
3 Normative References
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply.
• OMG UML 2.2 Infrastructure Specification formal/2009-02-04
• OMG Meta-Object Facility (MOF) ver. 2.0 formal/2006-01-01
• OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-02
• ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
• ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
• ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
“
To:
“
3 Normative References
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply.
• OMG UML 2.4 Infrastructure Specification <omg spec ref URL>
• OMG Meta-Object Facility (MOF) ver. 2.0 <OMG spec ref URL>
• OMG MOF XML Metadata Interchange (XMI) ver. 2.1.1 <OMG spec ref URL>
• OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-02
• ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
"

Merge with KDM14-56

Merge with KDM14-56

This is a follow-up correction to KDM14-58. Some descriptions were missing in the original resolution.

*Add descriptions of the new top-level elements *

Add descriptions of the new top-level abstract elements AnnotatableElement, AnnotationElement, ExtendableElement, ExtensionElement. Editorial changes to description of the Element and ModelElement.

In KDM 1.3 the text description of the KDMEntity is missing properties ownedElement and groupedElement.

Add missing descriptions of properties to KDMEntity

Add text descriptions of derived properties "ownedElement" and "groupedElement" to section 9.4.1
Add text descriptions of derived properties "inbound" and "outbound" to section 9.5.2
Add text descriptions of derived properties "inAggregated", "outAggregated" to section 9.6.2

This is a clarification to text that is introduced as resolution to KDM14-131:
1. replace
md5:String Optional MD5 has signature of the resource
with
md5:String Optional MD5 hash signature of the resource using the MD5 message-digest algorith

2. add sentence to semantics:
The 128-bit (16-byte) hash value produced by the MD5 message-digest algorithm is represented in text format as a string of exactly 32 characters [0-9a-fA-F] that correspond to the digits of the hexadecimal number.

Add clarifications to the use of MD5 property

Add clarifications to the use of MD5 property of IntentoryItem:

Add clarification to BinaryRegion element introduced by KDM14-207:
"Specification of a BinaryRegion assumes that the corresponding resource is a sequence of bytes, where each byte has 8-bit size, representable as an octet. Addresses in a BinaryRegion are represented as non-negative integers. The address of the first byte in a binary resource is 0. For example, an address that may be displayed as a C-like string "0x00A0" is represented as an integer 160."

Add clarification to BinaryRegion

Add clarification to BinaryRegion.
Make sure the diagram shows attributes of BinaryRegion as startAddr, endAddr, as in the text.

Audit element can be extended with ExtensionElement using the light-weight extensibility mechanism.

Add clarification to Audit element

Add clarification to Audit element

Editorial change:
SourceRef and Region elements that represent traceability links between other instances of KDM meta-model elements and source code of an existing software system.
Track element that together with the TraceableTo relation represents traceability links between instances of KDM entities, including links from KDMEntities to InventoryItem elements.

Add clarification regarding Track element to overview

Editorial change

Resolution to KDM14-60 adds source association to AbstractInventoryElement. This has been superseded by the resolution to KDM14-208. The association shall be removed (or not added to begin with).

Remove attribute source

Remove attribute source added in resolution KDM14-60 and not removed by resolution to KDM14-208

KDM14-134 added owner to ExtensionFamily. However the underlying use case also requires owner properties be added to Stereotype (to the corresponding ExtensionFamily, reachable from the stereotyped element), and to TagDefinition (to the corresponding Stereotype, reachable from ExtendedValue).

Add owner to Stereotype and TagDefinition

Add owner to Stereotype and TagDefinition

Explicit KDM relationships are subclasses of KDMRelationship class. There are two associations: one with endpoint "to", redefines "to" from KDMRelationship; other - with endpoint "from", redefines "from" from KDMRelationship. The opposite endpoints of "to" and "from" correspond to "inbound" and "outbound" in KDMRelationship-KDMEntity association. In cmof, these endpoints correctly subset the "inbound" and "outbound" properties. However, in the KDM UML diagrams the is not stated explicitly.
Recommendation to add subsetted properites to all relation endpoints as part of upgrading to NoMagic format.

Add subsets inbound, outbound properties to KDM relation endpoints

Add subsetted property inbound at the endpoint opposite to "to" and subsetted property at the end opposite to "from" in all diagrams that represent KDM relationships.
This is already in the cmof model, so the impact it merely to upgrade the KDM diagrams to reflect this and tie getInbound(), getOutbound() to low-level kdm relationships, using the formal CMOF mechanism.

This issue corrects resolutions to KDM14-81.
The new element Templates does not conforms to KDM naming conventions.
It should be renamed into TemplateElement.
Also to facilitate extensions, it should be made "generic" instead of "abstract".

Rename new element Templates into TemplateElement

Rename new element Templates into TemplateElement and make is generic

Datatype organization is quite complex, yet there is no overview of the key subclasses of Datatype. This information is split into several diagrams.
Suggest adding a Datatypes class diagram, showing key subclasses.

Add Datatype class diagram

Add Datatype class diagram to provide overview of the key subclasses.

This issue is related to KDM14-64. Currently the attribute ExportKind is available for MethodUnit and MemberUnit. However in some languages like C#, entire classes can be made public, private, or protected. SO, in order to finish the restructuring of the attributes started in KDM14-64, ExportKind needs to be added to ClassUnit.

Add ExportKind to ClassUnit

Add ExportKind to ClassUnit

ControlElement is expected to have Signature and a type property referring to the Signature. It is a frequent operation to access the list of ParameterUnits and Return type, if any, from the ControlUnit.

Add derived operations getParameters and getReturnType to ControlElement

Add derived operations getParameters and getReturnType to ControlElement

Reverse the part of resolution to KDM14-63, which has removed the "ordered" from the actionRelation property, and add text saying that this property is ordered, which is required for example for matching actual and formal parameters, and access to composite and derived datatypes.

Restore "ordered" attribute for owned AbstractActionRelationship

Restore "ordered" for owned AbstractActionRelationship, accidentally removed in resolution to KDM14-63

Example on page 135 has code snippets but does not have the actual source code.

Add source for the example

Add source code to example on page 135

Current KDM mandates IndexUnit. Instead make it optional, with cardinality 0..1, and update text.
Also create a Constraints section, and move text : "Any anonymous datatype used by IndexUnit of the ArrayType should be owned by that IndexUnit." from the end of Semantics section to the Constraints section.

Make IndexUnit optional as per specification text

Make IndexUnit optional as per specification text

Current KDM spec defines micro action "This" is table A.4 (Control), however it is better placed into table A.5 (Access to Datatypes)

Move microKDM "This" from A.4 to A.5

Move microKDM "This" from A.4 to A.5

This issue is related to KDM14-69
The initial proposal violates the KDM constraint that the owner element and the from-endpoint must be the same.

Change the endpoint of TraceableTo relation to make it work

Here is the solution that will work:

• use the same approach as SourceRef. Introduce a new element called Track. Let every KDMEntity own it. Add the definition to SourceRef class diagram. The definition has to be in the kdm package, not in Core.
• the TraceableTo relation will now be from Track to any KDMEntity. The original proposal was only to an InventoryItem, but there is actually need for a more flexible traceability mechanism.
• the element Track shall be extendable.

In addition, re-define SourceRef ownership in the same way, in the SourceRef class diagram, from KDMEntity, instead of defining this ownership in every XXXInheritance class diagram from AbstractXXXElement. This actually amount to the same thing, as the union of all AbstractXXXElement is equal KDMEntity.

This issue is related to KDM14-69.
Current KDM allows SourceRef to reference SourceRegion element, which assumes a plain text target. While this does cover the main use case, there are multiple other use cases. This situation is significantly mitigated by the addition of the new TraceableTo relation. However, we still need a capability to refer to non-plain text regions.
Propose introducing an abstract superclass "Region" with a subclass SourceRegion (current class) and another one "BinaryRegion" for references to binary files with attributes startOffset, endOffset, format,language , and another one "ReferenceableRegion" with attributes ref, format and language

Allow non-text regions in arbitrary InventoryItem

Add abstract class Region as superclass of SourceRegion with attributes path:String, format:String, association file to InventoryItem[0..1] and add two additional subclasses:
BinaryRegion with attributes startAddr:Integer, endAddr:Integer, and ReferenceableRegion with attribute ref:String

The impact for this change is that 1) property file in SourceRegion will have type InventoryItem instead of SourceFile. 2) SourceRef will own tag "<region xmi:type="SourceRegion" ... />" instead of <SourceRegion ... />" because of multiple subtypes of Region.

Table A.11 contains generic actions for each model. However it is missing a generic "Code" action for CodeModel that is required to represent arbitrary platform-specific assembly segments or individual instructions.

Add generic "Code" micro action to Table A.11

Add generic "Code" micro action to Table A.11

The current definition of who owns AggreagtedRelation is inconsistent.
1) KDM 1.3. says that "Overall management and lifecycle of the Aggregated Relationships is determined by the operations of the KDMEntity class."
2) the operation createAggregation( otherEntity ) is defined for the KDMEntity
The descriptive text says: "The new aggregated relationship is owned by the model to which owns the current entity (either directly or indirectly through container ownership)."

3) Figure 10.1 says that KDMModel owns AggreatedRelation. This is consistent by the descriptive text.
4) on the other hand, this is not symmetric to the explicit relations, which are owned by the KDMEntity (Figure 9.3 for AggregatedRelations is not consistent with Figure 9.2 for explicit relations)
5) Figure 19.1 says that AbstractStructureElement owns AggregatedRelations. This is consistent with Figure 9.2, but not consistent with Figure 10.1

The API on page 31, section 9.5.2 is consistent in itself and can be implemented with either ownership (model or entity). However, it does not make a lot of sense to let the KDMEntity create its AggregatedRelation with another entity, and then pass the ownership to some model. The implementation with the model ownership is more complex.

Also, in case of density==1 when the explicit relation is the only aggregated instance, two relations are owned in a different way.

Also, implementing the deleteAggregation api becomes less straightforward, requires access to a Model.

Recommendation is to make Figure 9.3 consistent with Figure 9.2 and
remove ownership of AggregatedRelation in Figures 10.1 and 19.1

Make ownership of AggregatedRelations symmetric with explicit relations

Make ownership of AggregatedRelations symmetric with explicit relations

in UIActions diagram

Add section ProducesUIEvent

Add section ProducesUIEvent

in PlatformEvents section

Add section ProducesPlatformEvent

Add section ProducesPlatformEvent

Missing a subsection in section 18.9 DataAction

Add section ProducesDataEvent

Add section ProducesDataEvent

Example
.<?xml version="1.0" encoding="UTF-8"?>

Should not have the '.' before the xml text.

Remove dot for example in Section 13.8.4

Remove the dot

This is related to the new class DeploymentResources introduced by resolution to KDM14-81. This name does not conform to KDM naming conventions.
Recommendation is to rename this class to DeploymentElement and to make this class generic instead of abstract.

*Rename DeploymentResources into DeploymentElement *

Rename DeploymentResources into DeploymnetElement and make this class generic

This is related to KDM14-60
Split InventoryModel class diagram into two by separating out InventoyItem subclasses.

Split InventoryModel Class Diagram

Split InventoryModel class diagram by creating a new section InventoryItems Class Diagram.

Specification text must be clarified regarding semantics of "pointers".

Current KDM has PointerType which is aligned with ISO 11404 pointer datatype. This datatype is actually a reference. According to the description of "pointer" datatype in ISO 11404:
"pointer generates a datatype, called a pointer datatype, each of whose values constitutes a means of reference to values of another datatype, designated the element datatype. The values of a pointer datatype are atomic."

So, the following C++ int i; int *pi=&i; int & ri=i;
shall be represented by the same KDM, so "ext" attribute could be used to distinguish between them. The two DataElement can be also distinguished by their initialization.

IntegerType id="int" name="int"
PointerType id="tpi" name="pint"
– ItemUnit id="itpi" type="int" ext="int* tpi"
PointerType id="tri" name="rint"
– ItemUnit id="itri" type="int" ext="int& tri"

StorableUnit id="i" name="i" type="int" ext="int i"
StorableUnit id="pi" name="pi" type="pint"
– HasType p
– HasValue a1

StorableUnit id="ri" name="ri" type="rint"
– HasType r
– HasValue i

ActionElement id="a1" kind="Ptr"
– Addresses i

The corresponding C++ uses are represented by the following KDM:
i=1;

ActionElement id="a1" kind="Assign"
– Reads 1
– Writes i

(*pi)=1;

ActionElement id="a1" kind="PtrReplace"
– Addresses pi
– Reads 1
– Writes itpi

ri=2;

ActionElement id="a1" kind="PtrReplace"
– Addresses ri
– Reads 2
– Writes itri

Add example to microKDM chapter

Add examples to microKDM chapter and revise the text regarding the use of the word "pointer". Correct "pointer" to "pointer or reference" and rephrase any figurative use.

page 114, ActionElement with id=id.49 uses an incorrect kind InterfaceCall.

<codeElement xmi:id="id.49" xmi:type="action:ActionElement"
name="a4" kind="InterfaceCall"> <actionRelation xmi:id="id.50" xmi:type="action:CompliesTo"
to="id.23" from="id.49"/> <actionRelation xmi:id="id.51" xmi:type="action:Addresses"
to="id.34" from="id.49"/> <actionRelation xmi:id="id.52" xmi:type="action:Calls" to="id.22" from="id.49"/>
</codeElement>

Clarify specification text

Clarify text for Dispatches relation, that the corresponding micro action is PtrCall for stand-alone procedures and functions that are not called in the context of an object.

page 105, section 12.16.2 sentence "In the meta-model, TemplateParameter is a subclass of TypeElement." replace "TypeElement" with "Datatype".

Replace "TypeElement" with "Datatype" on page 105

Replace "TypeElement" with "Datatype" on page 105

This issue represents a problem statement accidentally merged into KDM14-76, and thus mis-labeled under "errors in example for micro-KDM actions":

In normative ANNEX:
A.5 PtrReplace inputs should be corrected to 'single reads relationship' rather than last read.

Change text in table A.5 for PtrReplace

Change text in table A.5 for PtrReplace to Single Reads

The current KDM spec provides a name for the endpoint as "owner", but the endpoint is not navigable, therefore an access operation is not created in KDM SDK. However such operation is useful for applications.

Make owner endpoint for Annotation and Attribute navigable

Make owner endpoint for Annotation and Attribute navigable

Currently the KDM specification for inventory model will represent each file source and/or binary file within the context of a directory structure as shown in the following fragment:
<directory xmi:type="source:Directory" name="test" path="/home/sample/test" xmi:id="4">
<attribute tag="link:id" value="test"/>
<directory xmi:type="source:Directory" name="Pirates-2.1" path="/home/sample/test/Pirates-2.1" xmi:id="5">
<attribute tag="link:id" value="Pirates-2.1">
<directory xmi:type="source:Directory" name="src" path="/home/sample/test/Pirates-2.1/src" xmi:id="6">
<attribute tag="link:id" value="src"/>
<binaryFile xmi:type="source:BinaryFile" name="Tasks.o" path="/home/sample/test/Pirates-2.1/src/Tasks.o" xmi:id="7">
<attribute tag="link:id" value="Tasks.o"/>
</binaryFile>

Spec does not state that "name" should be an absolute path but internally code will need to walk the object tree to compare if two files are the same at the expense of memory & resources.

Could we just refer to "file" just as a discrete absolute path instead? This may reduce the code level complexity and reduce resource consumption during the processing of large projects. Currently we need to break down each file into its component parts which has resulted in coding errors (PRs) and forces the developer to manage a number of objects instead of dealing with a single discrete entity.

Could we use URL instead of path? Apart from the ability to point to network level entities may further improve the implementation the KDM SDK and application level software. I also like this idea since it highlights that "file" may (which in the case of a service is always) is not referring to a file on the native file system. Application should not make is assumption as this may lead to incorrect KDM data representation.

I would also like to use MD5 as a file ID. Currently the extractor is able to tell if a file has been modified over time or is a duplicate of another file. Thinking that a URL + MD5 attribute would be a solid foundation for inventory entries.

Define path as URL and add MD5

1. Define semantics of path attribute in InventoryItem and Directory as URL
2. Add URL standard to normative references
3. Clarify the semantics of path attribute in Directory, allow path attribute in InventoryItem to be relative
4. add attribute MD5:String an MD5 hash signature of the InventoryItem

A RangeType is described as:

"RangeType is a meta-model element that represents user-defined subtypes of any ordered datatype by placing new upper and/or lower bounds on the value space."

In the current version of the spec, the upper and lower bounds cannot match any value that is not an int.

Use Value to determine bounds for a RangeType

lower: Integer the optional lower boundary of the range
upper: Integer the optional upper boundary of the range

These should become Value objects to support any type of ranges (e.g, floats or strings). The Values should be contained in the RangeType.

The type is CodeItems. So we have a method getCodeElements that in fact returns a list of CodeItems.

This leads to code written like this :
List<CodeElement> myList= cu.getCodeElements();
Which causes class cast exceptions since a CodeItem isn't a CodeElement

The method should be renamed getCodeItems, or type made more generic to AbstractCodeElement

Change the type of property codeElements in ClassUnit and TemplateUnit to AbstractCodeElement

Currently the type is CodeItems; it should be made more generic to AbstractCodeElement in order to avoid confusion with the type of hte generated method getCodeElement and to allow extensions.

The KDMFramework ExtensionFamily association is named 'extensionFamily' in the diagram and extension in the text below. Reference section 10.3.0 and 10.3.1

Repalce replace "extension" into "extensionFamily"

page 35, section 10.3.1 replace "extension" into "extensionFamily"

Ecore file does not contain the association getOwnedElement for KDMModel. This property is currently defined as "derived" union of "ownedElement" properties of subclasses.

Add getOwnedElement operation to KDMModel

Add getOwnedElement():KDMENtity[0..*] operation to KDMModel

Figure 10.1 Framework Class states, that rhe extension family does not have an bi-directional relationship with KDMFramework. For ease of navigation it should have the navigable owner association.

Make owner of ExtensionFamily navigable

Make owner of ExtensionFamily navigable

Section 11.3.2. AbstractInventoryElement
The association named 'inventoryRelationship' does not match the diagram above.

Replace "inventoryRelationship" into "inventoryRelation" on page 54

page 54, section 11.3.2 repalce "inventoryRElationship" with "inventoryRelation"

Section 10.6.3, page 46. The association to a ModelElement named 'reference' in the UML diagram and 'ref' in the text below

Replace "ref" with "reference" on page 46

page 46, section 10.6.3 replace "ref" with "reference" to match the model (Figure 10.4)

page 285 section 20.5.5 "Additional annotations of stereotypes" into additional annotations OR stereotypes".

Replace "of" into "or"

• page 285 section 20.5.5 "Additional annotations of stereotypes" -> additional annotations OR stereotypes".

Resolution to KMD14-18 contains a multi-part example to be placed to micro KDM section (chapter 14).
Part 2 of the example (interface call) needs to be modified to be readable.

Modify part 2 of the example

Modify part 2 of the example to add constructor and proper definitions

Follow-up on KDM14-13.
Replace
These elements are contains for KDM light-weight extensions (extension property).
with
These elements may own KDM light-weight extensions (extensionFamily property).

Editorial change in section 10.3.1

clarify sentence

Add sentence to description:
BlockUnit can also represent initialization blocks of individual ControlElement, ClassUnit, CompilationUnit and
CodeAssembly. These BlockUnit own ActionElement related to initialization of global, static and local variables and
creation of static objects.

Clarify description of BlockUnit

Clarify description of BlockUnit

Resolution to KDM14-76 has missed this.

Replace ActionRelation with Entry flow in the microKDM example

Replace ActionRelation with Entry flow in the origianl microKDM example

3 references were incorrect

Update references to examples in chapter 10

Update references to examples in chapter 10

The following classes refer to StructureGroup as their superclass instead of AbstractStructureElement.

19.3.4 Subsystem Class
19.3.5 Layer Class
19.3.6 Component Class
19.3.7 SoftwareSystem Class
19.3.8 ArchitectureView Class

Replace StructureGroup into AbstractStructureElement in specification text

Sections 19.3.4-19.3.8 incorrectly describe the superclass of the corresponding elements. The model is correct.

The example used to describe the difference between micro and non-micro kdm support contains several errors. From example in Chapter 14:

id.11 id.80 id:85 -> Flows do not have 'to'
id.45 -> should be of type Pointer (id.103)
id.55 [ArraySelect] -> Select is on an array of pointers, the register (id.45) should be a pointer.
id.61 [PointerReplace] -> PtrReplace is missing the addresses (first reads should become an addresses)
id.92 -> Missing Addresses
id.103 -> Array contains pointers (not integers), Array operations should reflect this

Correct microKDM example

Multiple corrections of XML on pages 165-167

Table A.5 describes Access options, two of which have optional outputs. The description of outputs of Ptr and ArraySelect read 'optinal' rather than 'optional'

Already fixed in KDM 1.3

The typo has been fixed throughout the editing process. Not present in the formal KDM 1.3 document

Virtual calls should have an Addresses to indicate what is the object that is being passed a message. Currently, the only action relations that are required describe the parameters and the next control flow.

IMO, a VirtualCall should match a PtrCall that requires a "Addresses relationship to the
DataElement that represents
the pointer". In the case of the Virtual call, it should probably read "Addresses relationship to the
DataElement that represents
the object", and perhaps specify that the DataElement should be of ClassUnit type.

Change constraint for VirtualCall

VirtualCall should use Addresses to the instance. However, the DataElement is of type DataElement, not ClassUnit, which is a subclass of Datatype

The micro definition for kinds Incr and Decr is ambiguous.

First, they are described in the preamble of A.2 and A.3. The description indicates that they should have a Reads and a Writes, which makes sense since they might represent the code for something like 'i++'.

Second, they are described in the table under A.4. Control Actions. This would imply that they are used for control, but I don't understand why that would be the case. Furthermore, these ActionElements would have only an Addresses relationship, but that does not match the definition of an Addresses class (access to complex data structure/pointer).

It would be helpful to know what is the correct description.

Move specifications of Incr and Decr from table A.4 to table A.2

Move specifications of Incr and Decr operations from table A.4 (Control) to table A.2 (Actions related to Primitive Numerical Datatypes).
Modify description in table A.3 to remove references to Incr and Decr.

The association AbstractCodeElement has the following description:

codeRelation:CodeRelation[0..*] The set of code relations owned by this code model.

It should read:

codeRelation:CodeRelation[0..*] The set of code relations owned by this code element.

Change description of AbstractCodeElement

Change word "model" into word "element" as suggested.

In Section 12.14.1, there is an inconsistency concerning the DefinedType class. The cardinality of the "codeElement" containment
reference in Figure 12.12 is 0..1 (zero or one) while it is described as 0..* (zero to many) in the description of the class that follows
the diagram (Anonymous datatypes used in the definition of the datatype). To be consistent with the class description, the relationship in the diagram should be corrected to read 0..*.

Change cardinality of owned CodeElement in DefinedType to 0..*

DefinedType can be a container for other CodeElement, for example, owned Datatype. The cardinality of the owned CodeElement should be 0..*. The change is to the model and the diagram. Additional comment can be added to the specification text.

Resolution to KDM14-61 is missing several changes to the PlatformModel

Corrections to the RecordFile example

Corrections to the RecordFile example: proper ManagesResources relations and added ProducedEvent actions with links to the Event model.

Some minor corrections to the modifications introduced in KDM14-75
as #3,4

Corrections to ClassD example (HasValue)

Corrections to ClassD example (HasValue)

In the description of the element, remove sentence "In the meta-model, TaggedRef is a subclass of ExtendedValue. " (kind of obvious).

replace constraint (ref->reference, missed by KDM14-136)
The model element that is the target of the ref association must be of the type, specified by the type attribute of the
tag definition that is the target of the tag association of the tagged ref element.
with
The model element that is the target of the reference association must be of the type, specified by the type attribute
of the tag definition that is the target of the tag association of the tagged ref element.

Add to editorial note KDM14-58

Eidtorial change to TaggedRef 10.6.3

Eidtorial change to TaggedRef 10.6.3

Resolution to KDM14-26 add the following sentence to section 12.5.2:
On the other hand, the name of SourceFile element of the InventoryModel shall include all "extensions", etc.
The combination of path and name attributes shall uniquely identify the SourceFile in the filesystem, described by the InventoryModel.
On the other hand, the updated semantics of the URI reference and the resolution of the URI in the context of Directory ownership in KDM14-
requires a correction to this. Replace "name" into "path" in the first sentence, and replace "Combination of name and path attributes" with "Path attribute" in the second sentence.

Clarify semantics of path attribute

Clarify semantics of path attribute in text added by KDM14-26 to CompilationUnit, section 12.5.2

section 13.3.1, after resolution to KDM14-63, the text emphasizes that ownedRelation is ordered, but does not emphasize that ownedElement is also ordered. This should be made symmetic.

Add explicit ordered to ownedElement in ActionElement

section 13.3.1 ActionElement
Add explicit ordered to description of ownedElement in ActionElement
It is already ordered in the model.

Corrections to reference example in microKDM section, introduced by KDM14-166.
replace HasType p with HasType tpi
replace HasType r with HasType tri

Corrections to reference example

Corrections to reference example

KDM14-178 has added the source for the existing example for visibility and comment.
replace

with

The existing KDM example has an additional comment to the int type. This was missed in KDM14-178

Correction to Visibility and Comment example source

Correction to Visibility and Comment example source

Rename section 12.13.2 ParameterKind Enumeration Datatype
into ParameterKind (enumeration)

Rename section ParameterKind

Rename section ParameterKind Enumeration Datatype into ParameterKind (enumeration)

Add Example
See example in section “VisibleIn Class”.
(should be in KDM14-29)

Add reference to example in CommentUnit

Add reference to example in CommentUnit

Clarify semantics of URI resolution introduced in KDM14-131 and modify example

Clarify semantics of URI resolution

KDM14-131 added URI reference semantics to "path" attributes of InventoryItem and Directory. Resolution of relative URI due to hierarchical ownership structure of Directory elements needs to be clarified and precise.

KDM 1.3 text missed to describe region association for SourceRef (it is part of the model). It should be added. Also change the superclass of SourceRef to AnnotatableElement (missed in resolution to KDM14-208).

Change superclass of SourceRef and add region association

Change superclass of SourceRef and add region association

This element has survived the edits in KDM14-60. Its semantics needs to be clarified to match the updates in the rest of the section.

Clarify semantics of ExecutableFile

Clarify semantics of ExecutableFile

The general description was missed in the resolution to KDM14-207, where the diagram was introduced.

Add description of the new Regions Class Diagram

Add description of the new Regions Class Diagram

They have moved to superclass Region as part of resolution to KDM14-207

Remove some associations and constraints from SourceRegion

Remove some associations and constrains from SourceRegion, as they moved to the superclass Region as part of resolution to KDM14-207.

We found a bug in our Java KDM implementation, but after review it sneak in because of the fact that Java enum are special classes and thus can have their own methods.

In 12.10 the KDM defines EnumeratedType which subsets the ownerElement relation to the value relation against Value.

In 12.15, ClassUnit subsets that relation to codeElement against CodeItem, allowing MethodUnit children among other things.

So, how would you represent a Java enum, as an EnumeratedType but then what do you do with the Methods defined in the enum, or as a ClassUnit and then what do you do with the Values.

Or can we define the Java enum as a ClassUnit that will contain the class behavior of the enum, with an HasType relation to an EnumaratedType instance that will hold the value and the representation of the enum portion?

Thanks for your insight in clarifying this situation.

Clearing up Java Enums

2 changes: Clarify EnumeratedTypes and use of ClassUnits

1. There is currently no constraint forcing all Value objects under an EnumeratedType to share the same type.
2. Indicate how a Java enum should be implemented

In section A.2 of the Micro-KDM annex we have:

Negate

Polymorphic unary negate operation for two values of the same numeric datatype; see ISO Negate operation for the corresponding datatype.

If negate is unary it probably doesn't apply to two values.

Change text in table A.2

Correct description of Negate operation.

In the Conceptual package (Section 20) of the KDM specification, there is a constraint described in Fig. 20.4, that forces an AbstractConceptualElement to be associated to one and only one ConceptualRole. This does not seem to be justified by the description of a ConceptualRole. Furthermore, the example provided in Section 20.6.1 does not respect this constraint. In this example, there are two rule units that define 2 different roles that are associated to the same fact.

The impact of this requirement is that a Term Unit cannot be play a role in multiple FactUnits, and a FactUnit cannot play a role in multiple RuleUnits. If this is correct, a clarification would be advisable.

Change caridinality of Role association at the side of ConceptualRole to 0..*

Allow multiple ConceptualRoles to be associated with the same AbstractConceptualElement

The original resolution to KDM14-23 placed the paragraph describing semantics of initialization blocks to section "HasValue Class". Instead the paragraph starting with the sentence "Semantics of init blocks: 1) Code Assembly ..." should go to section "BlockUnit Class".
Also "init block" should be systematically renamed to "initialization block".

Place paragraph describing semantics of initialization blocks to BlockUnit section

Place paragraph describing semantics of initialization blocks to BlockUnit section (original editing instruction #2)
Systematically rename "init block" into "initialization block"

ModelElement taggedValue association has the ExtendedValue type instead of the taggedValue as specified in the KDM spec.

Rename taggedValue propoerty into extendedValue

Property "taggedValue" has actual type "ExtendedValue".
To make it consistent, it should be renamed to "extendedValue".
However, this will drastically break compatibility with KDM 1.3: any KDM XML that uses stereotypes will need to be changed. This change will be implemented at a later point, for the next major KDM release.

This issue is related to KDM14-20

Problem: During the code model generation for Java we want to identify which class are in fact interfaces. Problem is that we basically need to identify which classes are interfaces upfront or have the ability to convert KDM "class unit" to "interface unit". However, both the objects presenting these both inherit from datatype but at the java code level one can't convert (i.e.) cast from ClassUnit to InterfaceUnit.

Question: from an implementation point of view would it better to have a class object with an Interface attribute? For example the ClassUnit object has isAbstract. Can we implement isInterface to ClassUnit?

This change will make it easier to change the type of a given KDM object.

Note: Java 1.8 will start to allow code in interface specifications which will blur the lines between interface/class specifications.

Defer to KDM 1.5

This issue will have a fairly significant impact on implementation, so it requires additional cycle for discussion.

ModelElement taggedValue association has the ExtendedValue type instead of the taggedValue as specified in the KDM spec.

This issue is related to KDM14-20

Problem: During the code model generation for Java we want to identify which class are in fact interfaces. Problem is that we basically need to identify which classes are interfaces upfront or have the ability to convert KDM "class unit" to "interface unit". However, both the objects presenting these both inherit from datatype but at the java code level one can't convert (i.e.) cast from ClassUnit to InterfaceUnit.

Question: from an implementation point of view would it better to have a class object with an Interface attribute? For example the ClassUnit object has isAbstract. Can we implement isInterface to ClassUnit?

This change will make it easier to change the type of a given KDM object.

Note: Java 1.8 will start to allow code in interface specifications which will blur the lines between interface/class specifications.