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

The current specification describing the BinaryFile Class file is either incorrect or misleading at best.

Since all files are ultimately binary, the BinaryFile Class, it seems, is more defined in terms of exclusion rather than inclusion. Normally we would consider human readable files as text files and non-readable files as binary. This is clearly not the definition used in the KDM context, as we would then have Image and ExecutableFile as extending BinaryFile.

So given the fact that BinaryFile first doesn’t follow general conventions, it should then be better defined. As it can probably be interpreted from reading the specification here, a BinaryFile is any file that doesn’t fit in any of the other type of files extending InventoryItem. But that would still leave us with issues of how to represent files that are clearly Text files, but not SourceFile, Configuration or ResourceDescription.

Rename BinaryFile to LinkableFile and clarify semantics

Rename BinaryFile into LinkableFile to avoid confusion with ImageFile on the semantics of "binary" meaning "linkable" rather than "non-text"
Clarify semantics. BinaryFile, ExecutableFile and SourceFile are related to computations, and contain representations of computational objects and statements in various formats, such as linkable object format for some platform, loadable machine instructions, interpretable bytecode, interpretable text statements, etc.

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.

In the Action Package, the codeElement at the to endpoint of the ActionElement, AbstractCodeElement relation should be marked as ordered.

This would be consistent with all other subsets of ownedElement with a mulitiplicity greater than 1 from the code model that also point to AbstractCodeElement which are all ordered. Given that these are owned code elements, and I quote, “nested action elements, or nested BlockUnits, or nested definitions of datatypes and computational objects”, losing the ordering of such elements goes counter to the design of the code model and has huge impact as we have to make ordering assumptions to make sense of the content.

Add "ordered" to owned CodeElement in Action

Add "ordered" to owned CodeElement in Action as per issue description. Remove "ordered" from AbstractActionRelationship association.

Currently the KDM defines 6 classes that are derived from InventoryItem and each of those is documented to represent files of some sort, but the naming is inconsistent. 3 of them have the File suffix and the other 3 don’t, leaving the user to question the categorization difference, which doesn’t seem to really exist when reading the documentation.

Rationalization of InventoryItem

Proposed subclasses of InventoryItem:
InventoryItem
.. SourceFile
.. Model (new)
.. LinkableFile (former BinaryFile)
......ObjectFile
......LibraryFile
..ExecutableFile
..ConfigFile (former Configuration)
..DataFile (new)
..ImageFile (former Image)
..Document (new)
..AudioFile (new)
..WebService (new)

remove ResourceDescription (can't distinguish from ConfigFile)

Assume InventoryItem has attribute path:URL (see KDM14-131)
Rename generic Platform::ResourceType into Platform::PlatformResource because the old name conflicts with the use of resource in the InventoryModel.

Add attribute format:String to InventoryItem
format:String Optional description of the format of the InventoryItem
add semantics: format attribute describes the organization of the InventoryItem. Examples of format for various subclasses of InventoryItem are: "xml", "html", "json", "csv", "text", "ms word", "coff", "java class", "jpeg","mp3","css"

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

The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit.

The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value.

Some concrete example:

1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is “final public” or “static”

2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like “final protected” (also needs multi-value)

3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as “final” (or is that an “ImportKind”)

4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing “static”, “transient”, “volatile” and a way to express “default”, unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: “private static final String CONST1 = “xx”; “

I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple “modifiers” for the same “unit”. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType

current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit

Added attributes since using an enum does not seem appropriate. These should match some UML concepts.

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

Related to clause: 3

See above. And if you want to refer OMG documents, write reference like:

IEC Std Template, IEC, available at http://www.iec.ch/tiss/templates.htm

Change format of the normative references and update versions

Change format of the normative references and update versions

p.101 (p.79) I don't see the use for the DateType Class. As ISO 11404 does, I suggest having only the TimeType Class
and removing 12.9.5 DateType Class. BTW, I like the addition of the Decimal class – I'm a little puzzled why ISO 11404
doesn't have it. For the most part, I would suggest being in total sync with 11404 should be the default and only in
selected (very rare) instances should there be deviations. Also, being in sync with the order and structure of chapters 8
and 10 of ISO 11404:2007 would be better, particularily when fast tracking this through ISO.

This issue has been closed in KDM RTF 1.3

This issue has been already closed by KDM RTF 1.3

p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6, the numbers are 2 and 3 instead of 1 (looks like Words
autonumbering feature is helping you)

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate by KDM RTF 1.3, ballot 1.

p.32 (p.10), p.79 (p.57), and other places: "ISO/IEC 11404" should be "ISO/IEC 11404:1996" – you may even want to update
this to be "ISO/IEC 11404:2007" which is the latest version and for the purposes of this document would not likely be different.

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1.

AbstractEventElement should group KDM Elements (instead of AbstractCodeElement). This allows us to attach an Event model also to other part of the model

Proposal does not align with existing mechanisms

EventModel is available to represent some abstractions and link the to lower-level KDM elements. For example, EventModel can be used to represent abstractions of some existing system.
Semantics of EventModel is not strong enough so that these elements can be used to model other KDM elements.

from:KDMEntity[1] The source container of the relationships in the aggregated set. All relationships in
the aggregated set should originate from the source container or from some entity
that is contained directly or indirectly in the source container

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

to: KDMEntity[1] The target container of the relationships in the aggregated set. All relations in the
aggregated set should terminate at the target container or at some entity that is
contained directly or indirectly in the target container.

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

Currently the KDM doesn’t allow for the stereotyping of Audit elements since those inherit from Element and not ModelElement.

We believe that this is an oversight, as a reading of the specification uses the Audit element by name as one of the possible owner of a stereotype (10.5.1 constraint #5: KDM

meta-elements (for example, “KDMEntity,” or “Audit”)) or the endpoint to a TaggedRef (10.5.2 constraint #4: KDM meta-element (for example, “KDMEntity,” or

“Audit”))

We are proposing the following changes to restore this capability that was clearly intended to exist in the first place:

· Move the stereotype relation from ModelElement to Element

· Change the endpoint of the reference relation in TaggedRef to now point to Element instead of ModelElement

· Change all text that refers to ModelElement as being subject to extension in favor of Element

Another possible approach that might be simpler is to derived the Audit from ModelElement instead of Element. Probably the only issue at hand is if it fits the definition given in 9.3.2 as being an element of the existing software system or not. That is a bit of a stretch here, but we could see this as being argued either way in the case of Audit.

Introduce Core class ExtendableElement and change subclass of Audit

in core package: Add class diagram Element to Core. Introduce abstract Core classes AnnotatableElement, AnnotationElement, ExtendableElement and ExtensionElement. Make ModelElement a subclass of ExtendableElement.
in kdm package: Make Audit a subclass of ExtendableElement.
Make Attribute, Annotation subclasses of AnnotationElement
Make ExtendedValue, Stereotype, TagDefinition, ExtensionFamily subclasses of ExtensionElement.
Then on Figure 10.3 we could have ExtendableElement instead of ModelElement.
Clarify descriptions.

We are proposing changing the Audits relation that is now from KDMFramework to Audit and instead having it from ModelElement to Audit.

That change would allow audits to be attached not only to segments and models, but sometimes to other element as well. For examples, Modules or CompilationUnit are prime candidate for us as they are initially produces independently and then brought into a bigger KDM.

Change audit endpoint to ModelElement

Changing the endpoint to allow audits to be stored for any ModelElement to associate additional metadata with any model element. This information can be related to provenance, argument, composition requirements, etc.

At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow'), since 'WITH TEST AFTER' is not used in the 'PERFORM' statement. This would be consistent with the 'FalseFlow' defined in 'id.64'. Suggestion: Move 'id.64' up to before the loop starts (after id.44) and remove the unconditional 'Flow' from 'id.44'. This improves action element arrangement with respect to their associated Cobol code snippets. Also, action elements corresponding to Cobol statements subordinated to the inline PERFORM appear at the same indentation level as action element 'id.64'. If this action element is indeed moved up, those dependent action elements should probably become part of its 'codeElement' children.

Multiple corrections in RecordFile example

The RecordFile example introduces ExceptionFlow in the corresponding DataModel. The base code model does not represent these flows because the semantics of exceptions is determined by the data model, not the code model (this is the KDM split, eventhough in Cobol they are both defined as part of the programming language)
So, we will move the UNTIL condition to the top of the loop, as proposed, since the default for PERFORM UNIL is indeed WITH TEST BEFORE. We will also fix few related issues.

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

Add text to page 27, semantics of KDMRelationship

This issue is to some extent related to KDM14-32 regarding the alignment between KDM and RDF. Semantics of the KDMRelationship should be clarified.

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

Clarify the description of CommentUnit

The description of the CommentUnit should be clarified.

Currently RecordFile in DataModel owns ItemUnits. There is a need for a RecordType, so that we can define a StorableUnit, corresponding to a record, and use that RecordType for the Type attribute of that StorableUnit. We need the StorableUnit for Addresses, etc. It is important that the RecordFile owns the RecordType, because we want to have associations going to the RecordFile whenever its fields are used in the code.

Suggested resolution: generalize owned elements from ItemUnit to CodeItem.

Illustrate usage of owned ItemUnit as record fields

add microKDM kind "Assign"; add Reads and Writes to ItemUnits owned by files in twp action elements. Clarify the description of the example for RecordFile on page 236.

Clarify alignment of the KDM Core with RDF

Clarify text regarding alignment with RDF

The text should clarify how KDM explicit and built-in relations can be represented as RDF triples.

p.31 (p.9) bottom of page – "Logically, KDM consists of 9 models." – is it 9 because the infrastructure layer elements
are not counted as models?

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1

p.25 (p.3) Confusion: If L1 compliance implies full realization of L0, then what purpose does L2 serve? You
can have L0 compliance or L1 compliance, but wouldn't L2 compliance be the same as L1 compliance since
both imply L0 and L1 compliance? In short, I don't see what purpose L2 serves – maybe additional text is
needed on L2 in this section.

This issue has been disposed in KDM RTF 1.3

This issue has been already resolved in KDM RTF 1.3, ballot 1

"Constraints" sub-section in the descriptions seems to be rarely needed. That is not a problem, but I read through many
sections wondering what it was used for and why it appeared. Might be useful to enter a "None" beneath each one with
no constraints so it is clear that it is a placeholder and that there are no constraints for that section.

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1

Page number refers to the pdf page number as in "178/334." Page numbers in parenthsis refers to
the page number at the bottom of each page.

Already closed in KDM RTF 1.3

This issue has been already closed in KDM RTF 1.3, ballot 1

In the ConceptualRelations Class Diagram in the KDM specification (see page 269) indicates that ConceptualFlow class has two associations socalled ‘to’ and ‘from’ on ConceptualContainer class. However in the section that explains the associations (in same page) indicates that they are ‘to’ and ‘from’ associations that have AbstractConceptualElement type (superclass of ConceptualContainer class).
”

Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement

Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement to match the specification text.

p.32 (p.10) "KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR" – spell out SBVR

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1

p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model"

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

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.

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

Generalize Calls and clarify constraints for init blocks

1. extend target of the current Calls from ControlElement to CodeItem so that It could refer to either a ControlElement or an entire CompilationUnit.
Add description of initialization blocks to 13.3.3 pages 141-142, refer to Init example in section 12.19.2.

2. Add description text to 12.19.2. Semantics of init blocks: 1) Code Assembly shall have an EntryFlow relation to the Init block, called the "master" init block; 2) each CompilationUnit shall have an EntryFlow relation to the first init block for the CompilationUnit, if required; 3) each init block has Flow relation to next init block within the same CompilationUnit, if required; 4) KDM implementation shall provide correct initialization order between multiple init blocks within each CompilationUnit. 5) KDM implementation shall provide correct initialization order between init blocks of separate modules. This order is typically undefined in the programming language and depends on the linker and the order in which modules are built. 6) KDM implementation shall determining appropriate owner for the init blocks. 6) KDM implementation shall provide appropriate chaining of init blocks across separate CompilationUnits within a CodeAssembly through the "master" init block in the CodeAssembly.
The "master" init block owned by CodeAssembly owns an ActionElement with a sequence of Calls relations to each CompilationUnit that has an init block, in appropriate order. The last Calls relation is to the entry point of the CodeAssembly, for example, "main".

3. Correct "master" init block in the Init example.

4. Correct Init example.
<actionRelation xmi:id="id.74" xmi:type="action:Flow" to="id.79" from="id.71"/>
should flow to id.75

5. Add description to CodeAssembly regarding EntryFlow relation to chained init blocks.

6. Add description to Init microKDM action in Annex A, table A.4
Clarify description of EntryFlow

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

Correct Init example

Make corrections to the Init example

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

Remove the word "extern" from the name of the external variable

Initialization example on page 118 contains the following line:
<codeElement xmi:id="id.47" xmi:type="code:StorableUnit"
name="extern d1" kind="external"/>
word "extern" needs to be removed

Association between CompilationUnit and SourceFile other than through SourceRef.

Merged with KDM14-69

Merged with KDM14-69

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

Add semantic guideline that the name shall include all extensions

The specification text should be clarified to include a semantic guideline that the name of SourceFile element of the InventoryModel shall include all "extensions", etc. The path+name shall uniquely identify the SourceFile in the filesystem, described by the InventoryModel. The semantics of CompilationUnit should be clarified, to say that the KDM implementation shall determine appropriate name of the CompilationUnit. This name may or may not be the same as the name of the corresponding SourceFile, if it is available.

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

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

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

Add clarification to Audit element

Add clarification to Audit element

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

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.

p.42 (p.20) Constraints sub-section – item in that section should be numbered (e.g. "1. The set...") to be consistent with
other Constraint sub-sections. Same is true of other Constraint sub-sections, so the rest need to be checked.

This issue has been disposed in KDM RTF 1.3

This issue has already been disposed as duplicate in KDM RTF 1.3, ballot 1.

p.35 (p.13) "Small KDM core..." – need description or introduction as to what this is. Suggest going over and rewriting the section
on the core package in "Part 1"

This issue has been closed in KDM RTF 1.3

This issue has already been closed in KDM RTF 1.3, ballot 1.

p.34 (p.12) Bullet in section 8.2: "The Kdm package provides static context shared by all KDM models" should be "The kdm
package provides static context shared by all KDM models"

This issue has been disposed in KDM RTF 1.3

This issue has been already disposed as duplicate in KDM RTF 1.3, ballot 1

p.33 (p.11) "The Kdm package provides the..." should be "The kdm package provides the..."

p.33 (p.11) "the infrastructure. kdm package" should be "the infrastructure. The kdm package"

This issue has been disposed in KDM RTF 1.3

This issue has been disposed as duplicate in KDM RTF 1.3

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

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

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

Remove Figure 20.1 and clarify text

Current KDM mentions two kind of alignment with SBVR: one in the overview and in the Core package mentions that KDM defines a vocabulary of terms and fact types for descriptions of systems, and second in the conceptual package. The text of the conceptual package should be simplified, and the only alignment should be the one in Core and overview. The conceptual package should explain how existing ontologies and vocabularies can be represented on top of other KDM facts in a combined model.

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

Illustrate local variables defined in compound action element

Add example to Micro KDM section, page 167.

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

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

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

in UIActions diagram

Add section ProducesUIEvent

Add section ProducesUIEvent

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

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

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

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

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.

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"

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

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

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.

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)

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.

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

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.

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

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

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

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.

The KDM documentation is missing a small documentation piece that should be:

12.3.7 Module Class (generic)

Describe top subclasses for each KDM model

Each KDM model should clearly define the main subclasses of the corresponding AbstractXXXElement. This should be clear both from diagrams as well as support text.

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.

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

3 references were incorrect

Update references to examples in chapter 10

Update references to examples in chapter 10

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

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.

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

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

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

Corrections to ClassD example (HasValue)

Corrections to ClassD example (HasValue)

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.

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

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

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.