Issues for ADM KDM 1.5 Revision Task Force

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

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

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

Jira Issues

Issue 9995: Section: 19 (kdm-rtf)

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

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

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
July 26, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

Deferred to RTF

Issue 10123: Break cyclic dependency between Code and Action package (kdm-rtf)

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

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

Resolution: The current framework is working fine. Disposition: Closed, no change
Revised Text:
Actions taken:
August 22, 2006: received issue
July 18, 2008: closed issue

Discussion:

Issue 10135: Section: 20 (kdm-rtf)

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

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

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
August 23, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

Runtime model has been merged with Platform model. Specific examples to the former elements  of the runtime model are deferred to RTF

Issue 10288: Section: 12, page 41-74 (03) (kdm-rtf)

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

Issue 1302200602 from submitters database Originally raised by Alain Picard (CastorTech) Missing example of how to represent reflection mechanisms in Java

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 10291: Section: 13.4 page 80 (kdm-rtf)

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

Issue 2507200504 from submitters database Originally raised by Mike Smith (EDS) BuildDescription should have relation "implements" to BuildModel

Resolution: Does not fit the current design In current KDM a model is simply a container of facts. There are currently no relations involving models. A BuildDescription represents transformation, and there is a relation DescribedBy to BuildStep.
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Discussion:

Deferred to RTF

Issue 10293: Section: 17 pages 131 - 136 (kdm-rtf)

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

Issue 1703200611 from submitters database Originally raised by Nick Mansourov Missign example on how to represent a logical event that is implemented as a field in a message (a non-event dirven system, implicit events); also how to handle default handling of implicit events

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 10297: Section: 18 pages 137 - 148 (02) (kdm-rtf)

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

Issue 1703200602 from submitters database Originally raised by Nick Mansourov Add other types of UI control elements to UI

Resolution: No need for additional UI elements There is no need for additional UI elements
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Discussion:

This issue is deferred to the RTF. Other UI elements (for example, pull down menus, buttons) can  be added as extensions. More feedback is needed from implementers of KDM if more  standardization is needed.  Disposition: Deferred

Issue 10306: Section: 20 (kdm-rtf)

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

Issue 2610200502 from submitters database Originally raised by Nick Mansourov Missing illustration how to represent runtime context for the following situation: (ps | wc -l; ps | grep "root") where the same deployment component is used in two contexts

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 10319: Section: 19 pages 149 - 169 (08) (kdm-rtf)

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

Issue 1211200522 from submitters database Originally raised by Nick Mansourov Introduce ResolvedMarshalledCall from MarshalledService directly to CodeElement

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
September 3, 2006: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

Deferred to RTF

Issue 11167: most operations in the whole specification are redundant (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In general most operations in the whole specification are redundant since they are merely the accessors of the properties. Such operations are never explicitly documented

Resolution: Keep the operations that correspond to derived properties Keep the operations that correspond to derived properties. These operations are defined in packages Core and Kdm. They represent the high-level api to the kdm models. Since each model redefines and/or subsets some of these derived properties to provide a large, strongly typed api, that determines the structure of the XMI, the high-level properties are only represented by the operations.
Revised Text:
Actions taken:
July 23, 2007: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 11168: 9.3.3 definition of owner (kdm-rtf)

Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11169: 9.3.3, association 'group' (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11170: 9.3.3 Constraint 1 seems wrong (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Page 17, 9.3.3 delete constraint 1
Revised Text:
Actions taken:
July 23, 2007: received issue
April 27, 2011: closed issue

Issue 11171: 9.3.3 getOwnerElement is misnamed (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

9.3.3 getOwnerElement is misnamed - should be getOwnedElement.

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

Correct text  Change getOwnerElement into getOwnedElement

Issue 11172: 9.4.1 - CMOF �redefines� mechanism (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

9.4.1: "In KDM this is represented by the CMOF �redefines� mechanism. Concrete properties redefine the �union� properties of the parent classes, defined in the Core package." However by using {redefines} and not {subsets} it is largely defeating the point of using a derived union - since redefines makes the derived end unavailable!

Resolution: Page 19, 9.4.1 in �to� association replace �redefines� mechanism � with �subsets� mechanism Page 19, 9.4.1 in �from� association replace �redefines� mechanism � with �subsets� mechanism
Revised Text:
Actions taken:
July 23, 2007: received issue
April 27, 2011: closed issue

Discussion:

Issue 11173: 9.4.2 - why 2 separate associations? (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Disposition: Closed, no change
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

The rationale for explicitly defining Core operations is to have a uniform interface to various  model elements at the level of the Entity-Relationship model. getOutbound operation is the key.  However, the getOwnedRelationship is part of the more physical view of the KD model that has  nesting. These are two different perspectives on the model, so they require two operations, which  happen to produce the same result, as described in the constraint

Issue 11174: 9.5.1: Property 'density' should be a derived property (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

9.5.1: Property 'density' should be a derived property: it is merely the count(self.relation) and is read only.

Resolution: Make property density derived Make property density derived
Revised Text: Change Figure 9.3, page 28 to indicate that property density is derived page 29 attributes, replace "density" with "/density" to indicate that it is derived
Actions taken:
July 23, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 11175: 9.5.1 Constraint 4 is inconsistent (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

Correct text; remove inconsistent constraint

Issue 11176: 9.5.1 Semantics: should be expressed in OCL (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

9.5.1 Semantics: should be expressed in OCL

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
July 23, 2007: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 11177: 9.6: These types should be declared as primitive (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

9.6: These types should be declared as <<primitive>>

Resolution: *Change stereotype from datatype into primitive * Change stereotype from datatype into primitive. This makes KDM core consistent with the UML Infrastructure specification. However, the exact origin of these stereotypes and their semantics is rather unclear. In fact, the UML Infrastructure document never explains where the stereotypes are imported from. This is likely because they were using a Visio stencil to produce some of the diagrams. However, the intended representation in CMOF is that of an instance of PrimitiveType, as in the current KDM. Go figure.
Revised Text: page 10 add bullet: classes marked with a stereotype "<<enumeration>> represent MOF enumerations page 10 bullet: classes marked with a stereotype "<<primitive>>" represent MOF primitive types In diagram 9.5 on page 31 change stereotype datatype in to primitive for Boolean, Integer, String classes. Keep producing same CMOF, e.g. <ownedMember xmi:id='D_345' xmi:type='cmof:PrimitiveType' name='Integer' /> page 31 replace " utility data types" with "several primitive data types" page 31 replace "Each class at the Datatypes class diagram is a subclass of MOF DataType class." with "Each class at the Datatypes class diagram is an instance of MOF PrimitiveType class." page 31 replace "Boolean Type (datatype)" with "Boolean Type (primitive)" page 31 replace "The meta-model uses the Boolean type to represent some KDM attributes, KDM operations, and their parameters." with "The meta-model uses primitive Boolean type to represent some KDM attributes, KDM operations, and their parameters." page 31 replace "String Type (datatype)" with "String Type (primitive)" page 31 replace "The meta-model uses the String type to represent some KDM attributes, KDM operations, and their parameters." with "The meta-model uses primitive String type to represent some KDM attributes, KDM operations, and their parameters." page 31 replace "Integer Type (datatype)" with "Integer Type (primitive)" page 31 replace "The meta-model uses the Integer type to represent some KDM attributes, KDM operations, and their parameters." with "The meta-model uses primitive Integer type to represent some KDM attributes, KDM operations, and their parameters."
Actions taken:
July 23, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Deferred to next RTF to allow more discussion

Issue 11178: 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement. (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Rename abstract class KDMFramework into FrameworkElement Rename abstract class KDMFramework into FrameworkElement
Revised Text: in model rename abstract class KDMFramework into FrameworkElement *modify Figure 10.1, page 34 to rename class KDMFramework into FrameworkElement *section 10.3.1,page 35, replace word "KDMFramework" into "FrameworkElement" (3 occurrences) *page 36, section superclass, replace word "KDMFramework" into "FrameworkElement" *page 37, section superclass, replace word "KDMFramework" into "FrameworkElement" *page 38, modify Figure 10.2 to to rename class KDMFramework into FrameworkElement *page 39, replace word "KDMFramework" into "FrameworkElement" (4 occurrences) *page 48, replace word "KDMFramework" into "FrameworkElement" *page 49, replace word "KDMFramework" into "FrameworkElement"
Actions taken:
July 23, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

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

Issue 11179: 10.3.1: Description of 'segment' property (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11180: p31 the XMI example has wrong namespaces for xmi and kdm and audit (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11181: 10.4 would be better to have a proper 'date' type rather than using String (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Keep date represented as String CMOF does not have a primitive type for a "date". The current representation as String allows some flexibility to the implementations. Yet, the specification of the format is unambiguous (if restrictive). Date is only used in Audit element.
Revised Text:
Actions taken:
July 23, 2007: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Discussion:

Deferred to next RTF to allow more discussion

Issue 11182: 10.4: use of 'author' is redundant (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
April 26, 2010: closed issue

Discussion:

There was some email discussion, but inclusion of decisions would be too big a change for an RTF, which ought to be concerned only with implementing and using the specification as published.  Suggestion: restart discussion on if and how the BMM should accommodate decisions. If there were consensus that it should, this might affect the timing of an RFP for BMM 2.                                                Actions Taken:  Issue received 11 December 2008  Noted for input to RFP for BMM 2.0 (as and when it is developed)  Disposition:	Closed, no change

Issue 11183: 10.4.1: Audit.description (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 23, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11709: Validate KDM examples in the KDM specification (kdm-rtf)

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

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

Resolution: Update examples Fix few minor issues and update the KDM URL to 1.4
Revised Text: Replace "Equal" with "Equals" in example on page 246, in actions elements with id.23 and id.29 in examples on pages 37, 41, 58, 79, 80, 95, 98, 108, 113, 117, 127, 128, 130, 131, 135, 148, 154, 164, 230, 234, 236, 245, 254, 259, 288, 306 replace /spec/KDM/1.2 into /spec/KDM/1.4 page 165 add <actionRelation xmi:id="id.401" xmi:type="action:Flow" to="id.42" from="id.37"/> page 165 replace <actionRelation xmi:id="id.41" xmi:type="action:Flow" to="id.31" from="id.28"/> with <entryFlow xmi:id="id.41" to="id.31" from="id.28"/> page 167 replace <actionRelation xmi:id="id.96" xmi:type="action:Flow" to="id.50" from="id.42"/> with <entryFlow xmi:id="id.96" to="id.50" from="id.42"/>
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Deferred to next RTF

Issue 11710: throws example in the spec is incomplete (kdm-rtf)

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

throws example in the spec is incomplete

Resolution: Add throws example class A { void foo() { try{ bar(); catch(Exception e){ println("Something went wrong"); } finally{ println("Good bye"); } } void bar() throws MoreDescriptiveException{ try{ this.arr[20] = 20; println(arr); } catch (IndexOutOfBoundsException e){ println("Oops"); throw new "went too far" } finally{ println(arr); } } int[] arr = new int[10] } Some comments: Some of the AbstractCodeElements are BlockUnits. I would have used EntryFlows instead of regular Flows, but that might be a matter of choice. 1. TryUnit entryFlow> ActionElement[kind='Call'] not required? 2. I see that we need to create new Exception to send. That's the revision I attached. I did a pass to do the changes, but I hope I got the numbering right (done manually).  <codeElement xmi:id="id.47" xmi:type="action:ActionElement" name="a8" kind="New"> <codeElement xmi:id="id.48" xmi:type="code:StorableUnit" type="id.67" kind="local"/> <actionRelation xmi:id="id.49" xmi:type="action:Creates" to="id.48" from="id.47"/> <actionRelation xmi:id="id:50" xmi:type="action:Flow" to="id.50" from="id.47"/> </codeElement>  <codeElement xmi:id="id.51" xmi:type="action:ActionElement" name="a9" kind="Throw"> <actionRelation xmi:id="id.52" xmi:type="action:Throws" from="id.51" to="id.48"/> </codeElement>
Revised Text: 1. page 154, section Example, add source code: class A { void foo() { try{ bar(); catch(Exception e){ println("Something went wrong"); } finally{ println("Good bye"); } } void bar() throws MoreDescriptiveException{ try{ this.arr[20] = 20; println(arr); } catch (IndexOutOfBoundsException e){ println("Oops"); throw new MoreDescriptiveException("went too far") } finally{ println(arr); } } int[] arr = new int[10] } class MoreDescriptiveException extends Exception { public MoreDescriptiveException(String msg){ super(msg); } } 2. page 154, add methodKind="method" type="id.71" to id.2 3. add signature owned by id.2 <codeElement xmi:id="id.71" xmi:type="code:Signature"> </codeElement> 4. page 154, add methodKind="method" type="id.57" to id.23 5. modify to property in id.46 replace to="id.47" with to="id.72" 6. Add "new" action element after id.46 <codeElement xmi:id="id.72" xmi:type="action:ActionElement" name="a8" kind="New"> <codeElement xmi:id="id.73" xmi:type="code:StorableUnit" type="id.69" kind="local"/> <actionRelation xmi:id="id.74" xmi:type="action:Creates" to="id.48" from="id.72"/> <actionRelation xmi:id="id:75" xmi:type="action:Flow" to="id.76" from="id.72"/> </codeElement> 7. Add "MethodCall" action element, move definition of value id.48 from id.47 to the new action element <codeElement xmi:id="id.76" xmi:type="action:ActionElement" name="a8" kind="MethodCall"> <codeElement xmi:id="id.48" xmi:type="code:Value" name=""Went too far"" type="id.69"/> <actionRelation xmi:id="id.77" xmi:type="action:Addresses" to="id.73" from="id.76"/> <actionRelation xmi:id="id.78" xmi:type="action:Reads" to="id.48" from="id.76"/> <actionRelation xmi:id="id.79" xmi:type="action:Calls" to="id.73" from="id.76"/> <actionRelation xmi:id="id:80" xmi:type="action:Flow" to="id.47" from="id.72"/> </codeElement> 8. add property to in id.50 (Throws relation) to="id.73" <actionRelation xmi:id="id.50" xmi:type="action:Throws" from="id.50" to="id.73"/> 9. add constructors to id.63 <codeElement xmi:id="id.63" xmi:type="code:ClassUnit" name="MoreDescriptiveException" isAbstract="true"> <codeRelation xmi:id="id.64" xmi:type="code:Extends" to="id.67" from="id.63"/> <codeElement xmi:id="id.81" xmi:type="code:MethodUnit" name="MoreDescriptiveException" methodKind="constructor" type="86" > <entryFlow xmi:id="id.82" to="id.83" from="id.81"/> <codeElement xmi:id="id.83" xmi:type="action:ActionElement" name="a9" kind="MethodCall"> <actionRelation xmi:id="id.84" xmi:type="action:Reads" to="id.87" from="id.83"/> <actionRelation xmi:id="id.85" xmi:type="action:Calls" to="id.88" from="id.83"/> </codeElement> <codeElement xmi:id="id.86" xmi:type="code:Signature"> <parameterUnit xmi:id="id.87" type="id.69" name="msg" kind="byValue"/> </codeElement> </codeElement> 10. add constructor to id.67 <codeElement xmi:id="id.67" xmi:type="code:ClassUnit" name="Exception"> <codeElement xmi:id="id.88" xmi:type="code:MethodUnit" name="Exception" methodKind="constructor" type="id.89" > <codeElement xmi:id="id.89" xmi:type="code:Signature"> <parameterUnit xmi:id="id.90" type="id.69" name="msg" kind="byValue"/> </codeElement> </codeElement> 11. add entryFlow to id.4 <entryFlow xmi:id="id.91" to="id.5" from="id.4"/> 12. add entryFlow to id.10 <entryFlow xmi:id="id.92" to="id.12" from="id.10"/> 13. add entryFlow to id.17 <entryFlow xmi:id="id.93" to="id.18" from="id.17"/> 14. add entryFlow to id.25 <entryFlow xmi:id="id.94" to="id.26" from="id.25"/> 15. add entryFlow to id.25 <entryFlow xmi:id="id.94" to="id.26" from="id.25"/> 16. add to and from properties to id.39 <actionRelation xmi:id="id.39" xmi:type="action:ExitFlow" to="id.52" from="id.25"/> 17. add entryFlow to id.40 <entryFlow xmi:id="id.95" to="id.42" from="id.40"/> 18. add entryFlow to id.52 <entryFlow xmi:id="id.96" to="id.53" from="id.52"/>
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Deferred to the next RTF

Issue 11711: Consider Uniform representation of exception object and classes (kdm-rtf)

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

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

Resolution: Defer to KDM 1.5 Defer to KDM 1.5 to allow more substantial discussion.
Revised Text:
Actions taken:
December 1, 2007: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

Deferred to the next RTF to allow more discussion

Issue 11712: Consider representation of a switch (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11713: Need a counterpart of the HasValue relation (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11714: PtrCall for callable units and method units a->foo() (kdm-rtf)

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

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

Resolution: Add example to microKDM chapter Add example to micro KDM chapter, clarifying the use of the corresponding microKDM operations
Revised Text: page 313 Add description to table A.4, PtrCall: "Dispatches relation to the DataElement represents the pointer" page 313 Add description to table A.4, VirtualCall: "method call by pointer or reference or call to an interface element" add example page 167 Consider the following C++ fragment: struct foo{ int x; float y; int bar( return x+2; } }; struct foo var; struct foo* pvar; Now few statements and the outline of the corresponding KDM: var.x = 5; ActionElement id="a1" kind="MemberReplace" ? Addresses var ? Reads 5 ? Writes x (&var)->y = 14.3; ActionElement id="a1" kind="Ptr" ? Addresses var ? Writes r1 ? Flows a2 ActionElement id="a2" kind="PtrSelect" ? Addresses r1 ? Writes r2 ? Flows a3 ActionElement id="a3" kind="MemberReplace" ? Addresses r2 ? Reads 14.3 ? Writes y pvar->y = 22.4; ActionElement id="a1" kind="PtrSelect" ? Addresses pvar ? Writes r1 ? Flows a2 ActionElement id="a2" kind="MemberReplace" ? Addresses r1 ? Reads 22.4 ? Writes y (*pvar).x = 6; ActionElement id="a1" kind="PtrSelect" ? Addresses pvar ? Writes r1 ? Flows a2 ActionElement id="a2" kind="MemberReplace" ? Addresses r1 ? Reads 6 ? Writes x Note, that semantically there is no difference between last two statements, so the KDM pattern is the same. Now with calls var.bar(1); ActionElement id="a1" kind="MethodCall" ? Addresses var ? Reads 1 ? Calls bar pvar->bar(1) ActionElement id="a1" kind="PtrSelect" ? Addresses pvar ? Writes r1 ? Flows a2 ActionElement id="a2" kind="VirtualCall" ? Addresses r1 ? Reads 1 ? Calls bar (&var)->bar(1); ActionElement id="a1" kind="Ptr" ? Addresses var ? Writes r1 ? Flows a2 ActionElement id="a2" kind="VirtualCall" ? Addresses r1 ? Reads 1 ? Calls bar interface foo{ int x; float y; int bar(int); } ; class foobar implements foo { int x; float y; int bar(1){ return x+2;} }; foo x=new foobar(); ActionElement id="a1" kind="VirtualCall" ? Addresses x ? Reads 1 ? Calls bar class foo{ int x; float y; static int getName( return "foo"; } }; foo::getname(); ActionElement id="a1" kind="Call" ? Calls getName Consider the following C fragment: int bar(int x){return x+ 2; } typedef int (*pbar) (int); pbar foo=bar; (*pbar)(1); KDM: ActionElement id="a1" kind="PtrCall" ? Addresses pbar ? Reads 1 ? Dispatches pbar
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF due to the lack of time

Issue 11715: Add uppercase requirement for the names of micro KDM operations (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11716: Call via pointer example: need pointer type in type unit fp (kdm-rtf)

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

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

Resolution: Fix issues in Dispatch example Fix Dispatches example on page 149.
Revised Text: page 149: 1. <codeElement xmi:id="id.2" xmi:type="code:CallableUnit" name="foo" type="id.15" kind="regular"> must have a type="id.4" (to signature) <codeElement xmi:id="id.2" xmi:type="code:CallableUnit" name="foo" type="id.4" kind="regular"> <codeRelation xmi:id="id.3" xmi:type="code:HasType" to="id.14" from="id.2"/> <codeElement xmi:id="id.4" xmi:type="code:Signature" name="foo"> <parameterUnit xmi:id="id.5" name="a" type="id.13"/> <parameterUnit xmi:id="id.6" type="id.13" kind="return"/> </codeElement> </codeElement> 2. <codeElement xmi:id="id.7" xmi:type="code:CallableUnit" name="bar" type="id.15" kind="regular"> must have type="id.9" (to signature) <codeElement xmi:id="id.7" xmi:type="code:CallableUnit" name="bar" type="id.9" kind="regular"> <codeRelation xmi:id="id.8" xmi:type="code:HasType" to="id.14" from="id.7"/> <codeElement xmi:id="id.9" xmi:type="code:Signature" name="bar"> <parameterUnit xmi:id="id.10" name="a" type="id.13"/> <parameterUnit xmi:id="id.11" type="id.13" kind="return"/> </codeElement> </codeElement> 3. <codeElement xmi:id="id.12" xmi:type="code:StorableUnit" name="pf" type="id.14"/> must be owned by foobar 4. TypeUnit fp should be declared as a pointer to signature <codeElement xmi:id="id.14" xmi:type="code:TypeUnit" name="fp" type="id.34"> <codeElement xmi:id="id.34" xmi:type="code:PointerType" name="pf" > <codeElement xmi:id="id.35" xmi:type="code:ItemUnit" name="ipf" type="id.15"> <codeElement xmi:id="id.15" xmi:type="code:Signature" name="f"> <parameterUnit xmi:id="id.16" name="a" type="id.13"/> <parameterUnit xmi:id="id.17" type="id.13" kind="return"/> </codeElement> </codeElement> </codeElement> </codeElement> 5. <codeElement xmi:id="id.20" xmi:type="action:ActionElement" name="a1" kind="Assign"> must be of kind "Ptr" 6. <codeElement xmi:id="id.24" xmi:type="action:ActionElement" name="a2" kind="Assign"> must be of kind Ptr 7. <codeElement xmi:id="id.28" xmi:type="action:ActionElement" name="a3" kind="PtrCall"> should have addresses instead of Reads: <codeElement xmi:id="id.29" xmi:type="code:Value" name="1" type="id.13"/> <actionRelation xmi:id="id.30" xmi:type="action:Addresses" to="id.12" from="id.28"/> <actionRelation xmi:id="id.31" xmi:type="action:Reads" to="id.29" from="id.28"/> <actionRelation xmi:id="id.32" xmi:type="action:Dispatches" to="id.12" from="id.28"/> </codeElement>
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11717: consider having a StorableUnit and CallableUnit, maybe with an explicit kin (kdm-rtf)

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

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

Resolution: Defer to KDM 1.5 This issue will have a fairly significant impact on implementations, so it requires an additional cycle for discussion.
Revised Text:
Actions taken:
December 1, 2007: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11718: specify which characterset is used for chartype or provide the capability t (kdm-rtf)

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

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

Resolution: Add charset:String attribute to CharType and String classes Add attribute charset:String to CharType and StringType classes. Semantics of charset is aligned with "repertoir-identifier" in ISO 11404 and identifies a character set. If this attribute is omitted, the default characterset is ISO-8859-1.
Revised Text: page 88, Figure 12.7, add attribute charset:String to CharType and StringType classes. page 89, section 12.9.3 CharType add: Attributes: charset:String ISO identifier of a character set page 89 add to semantics Attribute charset identifies a character set for the CharType. Semantics of charset is aligned with "repertoir-identifier" in ISO 11404. If this attribute is omitted, the default character set is ISO-8859-1. For the list of valid character set identifiers, refer to ISO 11404, Appendix A, or IANA character sets, RFC 2978. page 91, section 12.9.12 StringType add: Attributes: charset:String ISO identifier of a character set page 91, section 12.9.12 StringType replace: The interpretation of the details of the character encoding of the StringType is outside of the scope of KDM. Multibyte character strings can be represented as StringType with a stereotype. with Attribute charset identifies a character set for the StringType. Semantics of charset is aligned with "repertoir-identifier" in ISO 11404. If this attribute is omitted, the default character set is ISO-8859-1. For the list of valid character set identifiers, refer to ISO 11404, Appendix A, or IANA character sets, RFC 2978.
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11719: representation of the sizeof (type) operator as opposed to sizeof (expr) op (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11720: Correct specification text: (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11721: There is an ambiguity between BlockItem and micro action compound (kdm-rtf)

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

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

Resolution: Add guidelines for BlockUnit BlockUnit element is introduced to represent nested statements in systems, while composite ActionElement is a generic mechanism in KDM to manage complex collections of ActionElement, in particular, related to micro-KDM.
Revised Text: page 141, section semantics. Change text "BlockUnit represents the entire set of leaf Actions, owned by the BlockUnit directly or indirectly" into "BlockUnit represents nested ActionElement which are found in the given software system, while a generic composite ActionElement is an internal mechanism to manage complex ActionElement collections, in particular, those related to micro-KDM."
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11722: Discuss using the name of the action element as label (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

Discussion:  Label represents  a label; the  name of the  action is  the label  none none Single flow  to the next  micro  action  Disposition: Resolved

Issue 11723: Initialization block? (kdm-rtf)

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

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

Resolution: 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
Revised Text: page 147, Figure 13.4 extend target of the current Calls from ControlElement to CodeItem so that It could refer to either a ControlElement or an entire CompilationUnit. page 147 replace "ControlElement or one of its subclass elements" with "CodeItem, which can be a ControlElement or one of its subclasses, or an entire CompilationUnit" page 147: replace ControlElement with CodeItem page 148 : add after first sentence in semantics: "Calls relationship also represents the control flow between initialization blocks. " page 148 add: "Example: see example in sections 12.6.5, 12.19.2" page 116: add: Semantics of initialization blocks is described in section 13.3.3. BlockUnit page 141: add to description of BlockUnit: BlockUnit can also represent initialization blocks of individual ControlElement and CompilationUnit. These BlockUnit own ActionElement related to initialization of global, static and local variables and creation of static objects. page 142: add to BlockUnit: Constraints: 1. BlockUnit shall have an EntryFlow relation to the logically first ActionElement Add description of initialization blocks to 13.3.3 pages 141-142, refer to Init example in section 12.19.2. Add description text to 12.19.2. BlockUnit is used as a container for various ActionElement that are involved in the initialization of global, static and local variables in various CompilationUnit of a CodeAssembly. Such BlockUnit are called "init blocks". In micro KDM, an init block shall have a kind="Init". Semantics of the init blocks describes representation of control and data flow between init blocks using EntryFlow, Flow and Calls relations. Semantics of init blocks: 1) each CompilationUnit shall have an EntryFlow relation to the first init block for the CompilationUnit, if required; 2) each init block has Flow relation to next init block within the same CompilationUnit, if required; 3) KDM implementation shall provide correct initialization order between multiple init blocks within each CompilationUnit. 4) Code Assembly shall have an EntryFlow relation to the Init block, called the "master" init block; 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. 7) 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". Further, the initialization ActionElement owned by init blocks can be targets of HasValue relations from the corresponding DataElements. Example See example in section 12.9.2 HasValue Correct "master" init block in the Init example (id.94) <codeElement xmi:id="id.94" xmi:type="action:BlockUnit" name="master" kind="Init"> <entryFlow xmi:id="id.95" to="id.96" from="id.94"/> <codeElement xmi:id="id.96" xmi:type="action:ActionElement" name="i7" kind="Init"> <entryFlow xmi:id="id.97" to="id.10" from="id.96"/> <actionRelation xmi:id="id.98" xmi:type="action:Calls" to="id.2" from="id.96"/> <actionRelation xmi:id="id.99" xmi:type="action:Calls" to="id.44" from="id.96"/> <actionRelation xmi:id="id.100" xmi:type="action:Calls" to="id.48" from="id.96"/> </codeElement> </codeElement> Correct Init example section 12.9.2 HasValue <actionRelation xmi:id="id.74" xmi:type="action:Flow" to="id.79" from="id.71"/> should flow to id.75 page 75, section 12.5.1 add: If Module owns ActionElement, then the Module shall own EntryFlow relation to the logically first ActionElement page 75 add to end of semantics of CompilationUnit: ompilationUnit may own initialization blocks. The EntryFlow relation shall refer to the logically first init block. Semantics of init blocks is described in section 13.3.3 BlockUnit Example: See example in section 12.19.2 HasValue page 76 add to semantics of CodeAssembly: The EntryFlow relation shall refer to the logically first init block, which is usually the "master" init block that refers to initialization of owned CompilationUnit in correct order and then refer to the entry point of the CodeAssembly, for example, "main" Semantics of init blocks is described in section 13.3.3 BlockUnit Example: See example in section 12.19.2 HasValue page 145: replace text in bullet #4 with: The CodeAssembly shall include the "master" initialization block that owns an ActionElement with action kind="Init" and a sequence of Calls relaitons to the inidividual CompilationUnits in appropriate order, followed by another Calls relation to to the logical entry point of the CodeAssembly, for example "main". The initialization blocks of individual CompilationUnit referred to by the "master" block do not need to have the Flow relationship at their last action element. The control flow is returned to "master" initialization block. Additional semantics of initialization blocks is described in section 13.3.3. BlockUnit and in section 12.19.2 HasValue relation. Example See example in section 12.19.2 HasValue
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

deferred to next RTF

Issue 11724: More than one label on a statement (kdm-rtf)

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

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

Resolution: This is addressed by the resolution to another issue 11722. Disposition: Closed, no change
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Issue 11725: In Initialization example do not need to use extern in the names (kdm-rtf)

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

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

Resolution: 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
Revised Text: Initialization example on page 118 change the following line: <codeElement xmi:id="id.47" xmi:type="code:StorableUnit" name="extern d1" kind="external"/> into <codeElement xmi:id="id.47" xmi:type="code:StorableUnit" name="d1" kind="external"/>
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11726: Variable d2 in main compilation unit b.cpp doesn't have aHasValue relation (kdm-rtf)

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

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

Resolution: Correct Init example Make corrections to the Init example
Revised Text: Example on page 116-119 1. <codeElement xmi:id="id.25" xmi:type="code:MethodUnit" name="D"> needs a methodKind="constructor" 2. same line needs a type="id.36" 3. action element with id.28 needs to use "this" and MemberReplace rather than a direct assignment to "x" <codeElement xmi:id="id.28" xmi:type="action:ActionElement" name="a4_1" kind="This"> <actionRelation xmi:id="id.30" xmi:type="action:Writes" to="id.24" from="id.28"/> <actionRelation xmi:id="id.31" xmi:type="action:Flow" to="id.32" from="id.114"/> <codeElement xmi:id="id.113" xmi:type="code:StorableUnit" name="r1" type="id.55"> </codeElement> </codeElement> <codeElement xmi:id="id.114" xmi:type="action:ActionElement" name="a4_2" kind="MemberReplace"> <actionRelation xmi:id="id.115" xmi:type="action:Addresses" to="id.113" from="id.114"/> <actionRelation xmi:id="id.116" xmi:type="action:Reads" to="id.37" from="id.114"/> <actionRelation xmi:id="id.117" xmi:type="action:Writes" to="id.24" from="id.114"/> <actionRelation xmi:id="id.118" xmi:type="action:Flow" to="id.32" from="id.114"/> </codeElement> 4. action element with id.40 requires a "this" and a MemberSelect, instead of direct reads from "num" <codeElement xmi:id="id.40" xmi:type="action:ActionElement" name="a6_1" kind="This"> <actionRelation xmi:id="id.41" xmi:type="action:Writes" to="id.119" from="id.40"/> <actionRelation xmi:id="id.42" xmi:type="action:Flows" to="id.120" from="id.40"/> <codeElement xmi:id="id.119" xmi:type="code:StorableUnit" name="r2" type="id.55"> </codeElement> </codeElement> <codeElement xmi:id="id.120" xmi:type="action:ActionElement" name="a6_2" kind="Call"> <actionRelation xmi:id="id.41" xmi:type="action:Addresses" to="id.119" from="id.120"/> <actionRelation xmi:id="id.41" xmi:type="action:Reads" to="id.39" from="id.120"/> <actionRelation xmi:id="id.42" xmi:type="action:Reads" to="id.24" from="id.120"/> <actionRelation xmi:id="id.43" xmi:type="action:Calls" to="id.106" from="id.120"/> </codeElement> 5. main must have a signature <codeElement xmi:id="id.48" xmi:type="code:CallableUnit" name="main" type="id.121"> <codeElement xmi:id="id.121" xmi:type="code:Signature" name="main"> </codeElement> 6. method <codeElement xmi:id="id.38" xmi:type="code:MethodUnit" name="work"> must have a methodKind="method" and a signature <codeElement xmi:id="id.38" xmi:type="code:MethodUnit" name="work" methodKind="method" type="id.122"> <codeElement xmi:id="id.122" xmi:type="code:Signature" name="work"> </codeElement>
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF.

Issue 11727: name of CompilationUnit should not contain extension (kdm-rtf)

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

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

Resolution: 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.
Revised Text: page 75, section 12.5.2 add "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 one is available. 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. "
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF to allow more discussion

Issue 11728: Assoc. between CompilationUnit and SourceFile other than through SourceRef (kdm-rtf)

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

Association between CompilationUnit and SourceFile other than through SourceRef.

Resolution: Merged with [1]KDM14-69 Merged with [2]KDM14-69 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/KDM14-69 [2] http://issues.omg.org/browse/KDM14-69
Revised Text:
Actions taken:
December 1, 2007: received issue
March 29, 2016: Duplicate or Merged
July 12, 2016: closed issue

Discussion:

Defer to the next RTF to allow more discussion

Issue 11729: Need to make Datatype generic, for the sake of using it in with stereotypes (kdm-rtf)

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

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

Resolution: resolved
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

Currently the Datatype element is abstract. All of its counterparts: ControlElement, DataElement  and Module are generic, i.e. concrete from the MOF perspective so that they can be instantiated  in KDM XMI, but underspecified from KDM semantics perspective, so that they can be used as  extension points with stereotypes. In the context of using KDM together with SBVR in a rule  based environment there is a need to specify general endpoints of relationships (and later to  provide more concrete elements). In order to achieve this, Datatype has to be made generic.  This change does not affect existing KDM XMI documents, or any existing KDM implementations.  Make Datatype concrete class; change txt to indicate that it is generic, add constraint  Also make generic ComputationalObject, and ValueElement

Issue 11730: text should mention optional writes in micro kdm and an example with a+1; (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11731: change text for the arrayselect "single" reads (kdm-rtf)

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

change text for the arrayselect "single" reads

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11732: representation of this-> and this (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11733: variables that are declared at header of loop needs special care in KDM (kdm-rtf)

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

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

Resolution: Illustrate local variables defined in compound action element Add example to Micro KDM section, page 167.
Revised Text: Add example to Micro KDM section, page 167. Example: C: int i; int sum=0; for(i=0;i<10;i++){sum+=i;} KDM fragment illustrating only the essential elements related to micro KDM: IntegerType name="int" id="int" Value name="0" id="0" type="int" Value name="10" id="10" type="int" StorableUnit name="i" type="int" kind="global" StorableUnit name="sum" type="int" kind="global" ? HasValue 0 ActionElement id="a1" kind="compound" ? ActionElement id="a2" kind="Assign" ? ? Reads 0 ? ? Writes i ? ? Flows a3 ? ActionElement id="a3" kind="LessThan" ? ? Reads i ? ? Reads 10 ? ? TrueFlow a4 ? ? FalseFlow a4 ? ActionElement id="a4" kind="Add" ? ? Reads sum ? ? Reads i ? ? Writes sum ? ? Flows a5 ? ActionElement id="a5" kind="Incr" ? ? Addresses i ? ? Flows a3 ? ActionElement id="a6" kind="Nop" C++: int sum=0; for(int i=0;i<10;i++) {sum+=i;} KDM fragment illustrating only the essential elements related to micro KDM: IntegerType name="int" id="int" Value name="0" id="0" type="int" Value name="10" id="10" type="int" StorableUnit name="sum" type="int" kind="global" ? HasValue 0 ActionElement id="a1" kind="compound" ? StorableUnit name="i" type="int" kind="local" ? ? VisibleIn a1 ? ActionElement id="a2" kind="Assign" ? ? Reads 0 ? ? Writes i ? ? Flows a3 ? ActionElement id="a3" kind="LessThan" ? ? Reads i ? ? Reads 10 ? ? TrueFlow a4 ? ? FalseFlow a4 ? ActionElement id="a4" kind="Add" ? ? Reads sum ? ? Reads i ? ? Writes sum ? ? Flows a5 ? ActionElement id="a5" kind="Incr" ? ? Addresses i ? ? Flows a3 ? ActionElement id="a6" kind="Nop"
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF

Issue 11734: Description of the multidimentional arrays is confusing. (kdm-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11735: There is a problem with Throws relation and Throw micro operation (kdm-rtf)

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

There is a problem with Throws relation and Throw micro operation: Throws relation is to an object! but Throw says  that there are Reads. Reads should be part of the constructor, there should be new, bla-bla, constructor call.  Big question mark.    Throws should be a shortcut - relationship to the exception class. with a single Reads to the exception object.   Because we do not want to duplicate the constructor call logic.

Resolution:
Revised Text:
Actions taken:
December 1, 2007: received issue
July 18, 2008: closed issue

Discussion:

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

Issue 11736: Representation of a stand-alone comment (kdm-rtf)

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

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

Resolution: Clarify the description of CommentUnit The description of the CommentUnit should be clarified.
Revised Text: page 132, section 12.23.1 semantics. add to the end of the paragraph. CommentUnit is a special element as it is a subclass of ModelElement, and not of KDMEntity. In addition to owned CodeElement, each AbstractCodeElement can own zero or more ordered CommentUnit. The order of CommentUnit is independent on the order of owned CodeElement. CommentUnit does not have SourceRef. The only connection of CommentUnit to the SourceFile is through the owner code element. KDM implementation shall decide how to associate CommentUnit with the corresponding code element. At a minimum, CommentUnit shall be owned by the corresponding Module, but typically they are owned by some CodeItem that are owned by the Module. Thus, each code element can have one or more SourceRef as well as associated comments. CommentUnit may be derived from sources other than the original SourceFile. CommentUnit is similar to Annotation element, however since CommentUnit is a subclass of ModelElement, it shall represent the text related to the system under investigation, and opposed to an Annotation, which shall represent text added during analysis.
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF

Issue 11737: explicit relationship and the built-in relationships (kdm-rtf)

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

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

Resolution: Add text to page 27, semantics of KDMRelationship This issue is to some extent related to [1]KDM14-32 regarding the alignment between KDM and RDF. Semantics of the KDMRelationship should be clarified. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/KDM14-32
Revised Text: page 27, add to semantics section at the end as a new paragraph: "KDM packages defines a viewpoint language, consisting of noun terms represented as subclasses KDMEntity, and verb terms represented as subclasses of KDMRelationship. Relations defined as subclasses of KDMRelationship are "explicit" and represent the majority of the vocabulary defined by KDM. Explicit relations can be mapped to RDF triples. KDM also defined several "built-in" relations, such as "ownedElement" and "groupedElement" defined at the CoreEntities class diagram and several others. KDM "built-in" relations as well as attributes of KDMEntities can be also mapped to RDF triples. The key difference between explicit and built-in relations is how they are used in the Aggregated Relations mechanism. Only explicit relations can be aggregated. On the other hand, the Aggregated Relations mechanism uses owns and groups built-in relations to define aggregations. Other built-in relations cannot be aggregated and always remain as links between the original endpoints. " page 21: first line, replace "provides" with "provides a vocabulary and" page 21: replace "From the meta-model perspective KDM is an entity-relationship representation. So, the" with "The" page 21, before "All KDM relationships are binary". Add "Such relationships are called "explicit" relations". page 21: replace "KDM defines two special relationships" with :KDM also defines several "built-in" relations, most notably:" page 21: replace "Some KDM entities are" into "These built-in relations allow defining some KDM entities as" page 21: replace " regular relationships of the entity-relationship model." with "explicit relations". page 27, in the description of ownedRelation: replace "Primitive" with "Explicit" page 28, section 9.5.1. replace "primitive" with "explicit" page 29: replace "primitive" with "explicit" (3 occurrences) page 29: replace "regular" with "explicit" (8 occurences) page 29: replace "atomic elements" into "entities" page 29, semantics, item 4, replace "containers" with "containers (and/or groups)" page 30: last paragraph: replace "more primitive" with "explicit" page 30: last paragraph: replace "at the end are" with "represent" page 30: last paragraph: replace "code facts" with "facts" page 30: last paragraph: replace "A primitive" with "Explicit" page 30: last paragraph: replace "primitive" with "explicit" page 46: section 10.6.2. semantics replace "primitive type" with "primitive datatype" page 140 section 13.1.3 replace "for primitive relations" with "for a large number of explicit KDM relations that describe control and data flow between various code elements"
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF

Issue 11738: Clarify the algnment with SBVR (kdm-rtf)

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

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

Resolution: 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.
Revised Text: page 278: line 5 from top: replace "and FactUnit" with ", FactUnit, RuleUnit and ConceptualRole" page 278 line 5: replace "mapping to SBVR" with "representation of the elements from external SBVR vocabularies and ontologies as parts of uniform KDM fact models" page 278: remove paragraph: KDM Conceptual model is aligned with SBVR specification in the following way. The KDM Conceptual Model allows representing three ?concepts? that are key to SBVR: Term, Fact, and Rule. The following is a mapping of these KDM ?concepts? to the SBVR terminology: ? Term corresponds to SBVR Noun (collectively referring to SBVR Terms and SBVR Names) ? Fact corresponds to SBVR Fact ? Rule represents a condition, group of conditions, or constraint The SBVR ?concepts? (i.e., Term, Fact, and Rule) are not defined in KDM. Instead, the KDM Conceptual Model defines the implementations of these ?concepts? - TermUnit, FactUnit, and RuleUnit. The mapping between KDM and SBVR is facilitated with the help of (0..) to (0..) relationships between pairs (i.e., <Term, TermUnit> and <Fact, FactUnit> and <Rule, RuleUnit>) as shown in Figure 20.1. page 279, remove Figure 20.1
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF due to the lack of time

Issue 11739: Clarify alignment of the KDM Core with RDF (kdm-rtf)

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

Clarify alignment of the KDM Core with RDF

Resolution: Clarify text regarding alignment with RDF The text should clarify how KDM explicit and built-in relations can be represented as RDF triples.
Revised Text: page 14 remove bullet "KDM is an Entiry-Relationship model" page 14-15 move last bullet "KDM defines an ontology for describing existing software systems...." as second bullet page 14: add as 3rd bullet: "KDM defines a set of concepts that can be used, for example, as the foundation of a pattern language; and KDM defines a schema for representing facts about specific existing software systems." page 14, add as 4th bullet: "KDM is designed in such a way that KDM facts can be represented as W3C Resource Description Framework (RDF) triples" page 14: replace "KDM models are composable (it is possible" with "extensively uses containment relationship: it is possible"
Actions taken:
December 1, 2007: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Defer to the next RTF due to the lack of time

Issue 12420: invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: In the kdm_1.1.cmof.xml correct the following 11 occurences of �ownedOperation� by inserting a space between �upper� clause and �type� clause. This is implemented as part of the automatic conversion from UML Rose diagrams into CMOF, so the unique ids of cmof elements may change. <ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*'type='C.6698801' /> <ownedOperation xmi:id='OP.28796973' xmi:type='cmof:Operation' name='getOutbound' lower='0' upper='*'type='C.6698801' /> <ownedOperation xmi:id='OP.1602470' xmi:type='cmof:Operation' name='getOwnedRelation' lower='0' upper='*'type='C.6698801' /> <ownedOperation xmi:id='OP.22060939' xmi:type='cmof:Operation' name='getInAggregated' lower='0' upper='*'type='C.1688690' /> <ownedOperation xmi:id='OP.1735173' xmi:type='cmof:Operation' name='getOutAggregated' lower='0' upper='*'type='C.1688690' /> <ownedOperation xmi:id='OP.4259620' xmi:type='cmof:Operation' name='getOwner' lower='0' upper='1'type='C.19792917' /> <ownedOperation xmi:id='OP.19831230' xmi:type='cmof:Operation' name='getOwnedElement' lower='0' upper='*'type='C.19792917' /> <ownedOperation xmi:id='OP.7316011' xmi:type='cmof:Operation' name='getGroup' lower='0' upper='*'type='C.19792917' /> <ownedOperation xmi:id='OP.16772004' xmi:type='cmof:Operation' name='getGoupedElement' lower='0' upper='*'type='C.19792917' /> <ownedOperation xmi:id='OP.29851750' xmi:type='cmof:Operation' name='getModel' lower='0' upper='1'type='C.31431715' /> <ownedOperation xmi:id='OP.12504936' xmi:type='cmof:Operation' name='getTo' lower='1' upper='1'type='C.19792917' /> <ownedOperation xmi:id='OP.19054722' xmi:type='cmof:Operation' name='getFrom' lower='1' upper='1'type='C.19792917' />
Revised Text:
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Issue 12421: CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CMOF and XMI namespaces are incorrect (they include an extra 'www')   Line 1 of the file is:  <XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">       Proposed resolution  Include correct namespace definitions, so that the above line becomes:  <XMI xmlns:xmi="http:// schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">

Resolution: In file kdm_1.1.cmof.xml change line <XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1"> Into <XMI xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1"> This is implemented as part of the automatic conversion from UML Rose diagrams into CMOF.
Revised Text:
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Issue 12422: Rename these associations to SignatureType and SourceFileRegion respectivel (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Signature and SourceFile are used as both Class and Association names in the same package: this is not permitted by CMOF constraints      Proposed resolution  Rename these associations to SignatureType and SourceFileRegion respectively       Line 256 is currently:        <ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='Signature'>  And should become        <ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='SignatureType'>      Line 1083 is currently:        <ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFile'>  And should become:        <ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFileRegion'>

Resolution:
Revised Text: see pages 11 - 14 of ptc/2009-06-02
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Issue 12423: Association A.62 (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Association A.62 has an owned end is called 'model ' (trailing space), which is inconsistent and invalid for generating language bindings      Proposed resolution  Remove the trailing space      Line 347 is currently:          <ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model ' lower='0' upper='1' isComposite='false' association='A.62' />  And should become          <ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model' lower='0' upper='1' isComposite='false' association='A.62' />

Resolution:
Revised Text: see pages 15 - 16 of ptc/2009-06-02
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Issue 12424: Many associations and association ends are given meaningless generated name (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Many associations and association ends are given meaningless generated names, like A.0, P.G.307. Since these will be used for the generated language bindings, and are required for traversing and accessing models, these names are not usable. In addition, the inclusion of '.'s in the names makes unnecessary for language bindings since they are not valid Java names.      For example lines 4 and 5 illustrate the names:        <ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707'  name='A.2' general='A.3'>          <ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='P.D.14122707' lower='1' upper='1' isComposite='false' association='A.2' />      Proposed resolution:  Generate meaningful names for these elements, using the same algorithm as UML2, which is as follows (from section 6.4 of formal/07-11-02)      * If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached,  modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are  often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal  constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.)      * Associations that are not explicitly named, are given names that are constructed according to the following production  rule: "A_" <association-end-name1> "_" <association-end-name2>  where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of  the second association end.      As an example, lines 4 and 5 would become:        <ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707'  name='A_actionElement_actionRelation' general='A.3'>          <ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='actionElement' lower='1' upper='1' isComposite='false' association='A.2' />

Resolution: Resolution: Proposed resolution: Change the rules for converting the UML Rose diagram into CMOF xml file to generate meaningful names for unnamed association endpoints and associations. 1. If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. In addition, if the name of the class to which the end is attached starts has a meaningful prefix of uppercase letters, for example XMLxxxx, KDMxxx, UIxxxx, the entire uppercase prefix is modified to become lowercase. For example, the above words become xmlxxxx, kdmxxx, uixxxx. 2. Unlabeled association end points at the KDM Entity side which correspond to KDM Relationships are additionally prefixed with �in� or �out� according to the direction of the relationship. The corresponding properties at the KDM Relationship class side as "to" and "from". For example, association ends for the ActionElement class corresponding to the associations to ControlFlow class are named �inControlFlow� (the counterpart of the �to� endpoint from the ControlFlow side) and �outControlFlow� (the counterpart of the �from� endpoint from the ControlFlow side). 3. Associations that are not explicitly named, are given names that are constructed according to the following production rule: "A_" <association-end-name1> "_" <association-end-name2> where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of the second association end. The unique ids of the cmof elements may change during the conversion.
Revised Text:
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Discussion:

Here is the brief outline of the discussion related to the proposed resolution: -----Original Message----- From: Nikolai Mansourov Sent: 29 May 2008 17:07 Subject: RE: Urgent issues on ptc-08-02-10.xml KDM 1.1 CMOF XMI Based on the previous interactions with Pete's team, there is a little unresolved point related to issue #12424 meaningful names of associations and association endpoints. I am waiting for Pete to respond, to better understand the implications for his project. In summary, Pete's team has proposed and implemented a certain naming convention for association ends that in my opinion is counterintuitive within the KDM context. At the same time, I have proposed and implemented a different naming convention which follows the framework already described in the KDM specification. Below in the copy from the original posting, describing this problem. -----------------original posting------------------------------- The naming convention that you have implemented to disambiguate the essociation names on top of the suggested UML2 convention is not intuitive in the KDM context. For example, in case of a KDMRelationship ControlFlow with "to" to an ActionElement and a "from" to an ActionElement, the ActionElement class has following endpoints: "controlFlow" and "controlFlow_inv_from" In the KDM specification these endpoints are referred to as "inbound" and "outbound", and the naming convention is to use "in" and "out" prefixes followed by the name of the relationship. So the endpoints should be: "inControlFlow" and "outControlFlow" "to" and "from" are quite symmetric in the KDM context for all KDM relationships. This is described in the introduction to the Core KDM layer. ------------------- -----Original Message----- From: Pete Rivett Sent: Monday, June 02, 2008 8:29 PM Subject: RE: Urgent issues on ptc-08-02-10.xml KDM 1.1 CMOF XMI Just to re-iterate a point made previously in Nick Dowler's email of 12th May (attached)... We would have been more than happy with the names of the style proposed by Nick M - however the hand-edited changes he sent did not cover all the problem cases: specifically there were still metaclasses having owned properties with duplicated names. Because we had a pressing deadline to ship something to a customer, we applied an automated algorithm to generate unique names for ALL the cases. So I believe that, as things stand, the Adaptive-proposed XMI file is the only one on the table that addresses all the problems. From: Nikolai Mansourov Sent: Mon 6/2/2008 8:51 PM Subject: RE: Urgent issues on ptc-08-02-10.xml KDM 1.1 CMOF XMI I have sent you an automatically generated CMOF file with unique properties that follow the KDM pattern with "in" and "out" prefixes. This email was sent on 12-05-2008. This solution addresses all urgent issues opened by you recently. I understand the implementation pressures. I am open to a compromise, if this naming convention has significant impact for your company. As I understand, Adaptive is the only company that is taking the route of using CMOF for code generation from KDM. Several other companies are using the EMF route. It is my recommendation is to use the "in" and "out" prefixes for the association endpoints that correspond to the inbound and outbound KDM relationships as summarized below (and shipped to you on 12-05-2008). As you remember, these endpoints were producing non-unique endpoint names according to the algorithms, suggested by you initially, and required further disambiguation. In my opinion, the naming convention with "in" and "out" prefixes is consistent with KDM design patterns and emphasized the symmetry of KDM relationships that are modeled by explicit MOF classes. The naming convention implemented by you which uses the suffix "inv_from" in one case and no prefix in the other case is asymmetric, and it does not leverage specific KDM knowledge. From: Alain Picard Sent: Monday, June 02, 2008 9:03 PM Subject: RE: Urgent issues on ptc-08-02-10.xml KDM 1.1 CMOF XMI We really wish to second Nick's approach here. The ability to use clear design and naming patterns is critical to a facilitating the usage of the KDM and its comprehension by humans, like us.

Issue 12425: Several association ends are both 0..* and composite owners (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Several association ends are both 0..* and composite owners. This is not only an invalid combination but is inconsistent with the specification document and Rose model used for that. This seems to affect the ends that {subset group} (that in the XMI contain "subsettedProperty='P.O.6222315' ")      For example, line 172 of the file is:          <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.35' />  The fact that this has isComposite='true' is inconsistent with Figure 21.3 of ptc/08-02-08 (the KDM 1.1 spec document) which has no black diamond on the line between BuildResource and Group.       Proposed resolution  Make all Properties that {subset group} have isComposite='false'  For example, the above line 172 would become:          <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='false' association='A.35' />

Resolution: Change the clause isComposite=�true� into isComposite=�false� in the following lines (provided below in the context of their Class owner) in the file kdm_1.1.cmof.xml: <ownedMember xmi:id='C.22840242' xmi:type='cmof:Class' name='BuildResource' superClass='C.14056260' isAbstract='false' > <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.35' /> <ownedAttribute xmi:id='P.O.13254846' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.14056260' name='groupedBuild' lower='0' upper='*' isComposite='true' association='A.37' /> </ownedMember> <ownedMember xmi:id='C.21360255' xmi:type='cmof:Class' name='NamespaceUnit' superClass='C.7475352' isAbstract='false' > <ownedAttribute xmi:id='P.O.6893036' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.7475352' name='groupedCode' lower='0' upper='*' isComposite='true' association='A.80' /> </ownedMember> <ownedMember xmi:id='C.2688299' xmi:type='cmof:Class' name='AbstractConceptualElement' superClass='C.19792917' isAbstract='true' > <ownedAttribute xmi:id='P.O.20416442' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.104' /> </ownedMember> <ownedMember xmi:id='C.12349885' xmi:type='cmof:Class' name='IndexElement' superClass='C.16116684' isAbstract='false' > <ownedAttribute xmi:id='P.O.9068636' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.30064779' name='implementation' lower='0' upper='*' isComposite='true' association='A.115' /> </ownedMember> <ownedMember xmi:id='C.25797638' xmi:type='cmof:Class' name='DataAction' superClass='C.27225657' isAbstract='false' > <ownedAttribute xmi:id='P.O.18189246' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.8621536' name='implementation' lower='0' upper='*' isComposite='true' association='A.126' /> </ownedMember> <ownedMember xmi:id='C.12180601' xmi:type='cmof:Class' name='AbstractEventElement' superClass='C.19792917' isAbstract='true' > <ownedAttribute xmi:id='P.O.15209872' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114' name='implementation' lower='0' upper='*' isComposite='true' association='A.151' /> </ownedMember> <ownedMember xmi:id='C.3554254' xmi:type='cmof:Class' name='AbstractPlatformElement' superClass='C.19792917' isAbstract='true' > <ownedAttribute xmi:id='P.O.23393515' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114' name='implementation' lower='0' upper='*' isComposite='true' association='A.175' /> </ownedMember> <ownedMember xmi:id='C.13266771' xmi:type='cmof:Class' name='DeployedSoftwareSystem' superClass='C.3554254' isAbstract='false' > <ownedAttribute xmi:id='P.O.31436981' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.31179076' name='groupedComponent' lower='0' upper='*' isComposite='true' association='A.185' /> </ownedMember> <ownedMember xmi:id='C.31179076' xmi:type='cmof:Class' name='DeployedComponent' superClass='C.3554254' isAbstract='false' > <ownedAttribute xmi:id='P.O.29921964' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.28336930' name='groupedCode' lower='0' upper='*' isComposite='true' association='A.188' /> </ownedMember> <ownedMember xmi:id='C.32002033' xmi:type='cmof:Class' name='AbstractStructureElement' superClass='C.19792917' isAbstract='true' > <ownedAttribute xmi:id='P.O.14191483' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.202' /> </ownedMember> <ownedMember xmi:id='C.26598825' xmi:type='cmof:Class' name='AbstractUIElement' superClass='C.19792917' isAbstract='true' > <ownedAttribute xmi:id='P.O.14454637' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.32333114' name='implementation' lower='0' upper='*' isComposite='true' association='A.209' /> </ownedMember> These are all associations that follow the �group association� pattern of KDM. This change is performed automatically in the process of converting the UML Rose diagrams into CMOF. The unique ids of the cmof elements may change during the conversion.
Revised Text:
Actions taken:
April 25, 2008: received issue
October 19, 2009: closed issue

Issue 12480: BindsTo relationship should have a more general �to� endpoint (kdm-rtf)

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

Currently the BindsTo relationship has the ResourceType as its �from� endpoint and another ResourceType as its �to� endpoint. As the result there is a lack of capability to capture binding of logical resources to their physical counterparts (such as files in the inventory model).    Suggested resolution: generalize the �to� endpoint of the BindsTo relationship  to KDMEntity class.

Resolution:
Revised Text: see page 24 of ptc/2009-06-02
Actions taken:
May 15, 2008: received issue
October 19, 2009: closed issue

Issue 12481: RecordFile and Datatypes (kdm-rtf)

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

Currently RecordFile in DataModel owns ItemUnits. We are missing 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.

Resolution: 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.
Revised Text: In description of Example for RecordFile on page 236, replace "The CodeModel of this" with "This" Add sentence at the end of the paragraph: "Example uses ItemUnits owned by RecordFile as variables. Note, that ExceptionalFlows are added through the DataModel." 1. add microKDM kind "Assign"; add Reads and Writes to ItemUnits owned by files to id.53: <codeElement xmi:id="id.53" xmi:type="action:ActionElement" name="a3" kind="Assign"> <source xmi:id="id.54" language="Cobol" snippet="MOVE SEQ-SOC-SEC-NUM TO IND-SOC-SEQ-NUM"/> <actionRelation xmi:id="id.55r" xmi:type="action:Reads" to="id.2" from="id.53"/> <actionRelation xmi:id="id.55w" xmi:type="action:Writes" to="id.7" from="id.53"/> <actionRelation xmi:id="id.55" xmi:type="action:Flow" to="id.56" from="id.53"/> </codeElement> 2. add microKDM kind "Assign"; add Reads and Writes to ItemUnits owned by files to id.56: <codeElement xmi:id="id.56" xmi:type="action:ActionElement" name="a4" kind="Assign"> <source xmi:id="id.57" language="Cobol" snippet="MOVE SEQ-REST-OF-RECORD TO IND-REST-OF-RECORD"/> <actionRelation xmi:id="id.58r" xmi:type="action:Reads" to="id.3" from="id.56"/> <actionRelation xmi:id="id.58w" xmi:type="action:Writes" to="id.8" from="id.56"/> <actionRelation xmi:id="id.58" xmi:type="action:Flow" to="id.59" from="id.56"/> </codeElement>
Actions taken:
May 15, 2008: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 12482: kinds for resource actions (kdm-rtf)

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

In the mapping for COBOL the code model uses action elements that correspond to various resource packages (in particular, Data, UI, Platform). These action elements are not exactly system calls, so from the micro KDM perspective they should have distinct kinds, at least saying that they represent resource actions. Otherwise the model can not be compliant to micro KDM.

Resolution: Add section A.11 Actions related to Resources Resource micro-actions represent specific statements that are determined by some programming languages and which manipulate resources provided by the operating environment. Such statements are alternative to using system calls. Kinds in Table A.11 represent such statements as micro KDM ActionElements. Precise semantics of representing the operating environment is described in Part 3 Runtime Resource Layer. In particular, a combination of resource actions, resource relationships and resource events can be used, where the resource micro-action is part of a Code Model, while other elements can be added in various models of the Resource Layer (Platform, Data, Event or UI). Inputs: Zero or more Reads relationships to DataElements; represent input data which is sent to the resource; ordered Outputs: Zero or more Writes relationships to DataElements; represents output data which is received from the resource; Control: optional single Flow to the next micro action (no Flow means a terminal action element). Extras: optional resource-specific relationships Table A.11 Resource Actions Micro Action Description Platform ActionElement represents a statement that manipulates a Platform Resource Data ActionElement represents a statement that manipulates a Data Resource Event ActionElement represents a statement that manipulates an Event Resource UI ActionElement represents a statement that manipulates a UI Resource Disposition: Resolved
Revised Text:
Actions taken:
May 15, 2008: received issue
October 19, 2009: closed issue

Issue 12483: SourceRef in Build package (kdm-rtf)

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

As currently specified in the build package, in figure 21.3 the BuildDescription has a relation to SourceRef with the containment side with a 1 specified. This is forcing any SourceRef to actually have a BuildDescription attached or else it won�t validate. This be 0..1. At the same time, the relationship to SourceRef should originate from BuildResource rather than only from BuildDescription in order for identifying BuildStep for example.    Suggested resolution: change multiplicity to 0..1    Change the origin of the relationship to SourceRef from BuildDescription to BuildResource.

Resolution:
Revised Text: see pages 27 - 28 of ptc/2009-06-02
Actions taken:
May 15, 2008: received issue
October 19, 2009: closed issue

Issue 12866: Inconsistency in the description of ConceptualRelations diagram (kdm-rtf)

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

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).  �

Resolution: Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement to match the specification text.
Revised Text: page 285, edit Figure 20.5 to change endpoint of ConceptualFlow relation to AbstractConceptualElement instead of ConceptualContainer to match specification text.
Actions taken:
September 26, 2008: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 12870: Missing section in KDM documentation (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

The KDM documentation is missing a small documentation piece that should be:         12.3.7 Module Class (generic)

Resolution: 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.
Revised Text: page 70: add to the list at the end of page: "- PreprocessorDirective" page 70: last paragraph add sentence: "Classes Module and PreprocessorDirective are defined in a separate sections." page 105 *add abstract class Templates to diagram 12.14, page 105. tas the superclass for TemplateUnit, TemplateType and TemplateParameter page 105: Add section before 12.16.1 12.16.1 Templates (abstract) The Templates class is an abstract meta-model element that represents various code elements related to templates, their parameters and instantiations. Superclass Datatype page 105: modify superclass of TemplateUnit class from Datatype to Templates page 105: modify superclass of TemplateParameter class from Datatype to Templates page 106: modify superclass of TemplateType class from Datatype to Templates *add sentence to section 12.3.6, page 73: "The key subclasses of Datatype are: PrimitiveTypes, EnumeratedTypes, CompositeTypes, DerivedTypes, Signature, DefinedTypes, ClassTypes, Templates *add to 12.3.2 AbstractCodeElement, page 71 "The key subclasses of AbstractCodeElement are CodeItem and ActionElement." page 176, section 15.3.2 AbstractPlatformElement add sentence: " The key subclasses of AbstractPlatformElement are PlatformResources, PlatformActions, DeploymentResources, RuntimeResources page 187, Figure 15.6 introduce abstract class DeploymentResources for page 187 add section before 15.9.1 15.9.1 DeployedResources (abstract) DeployedResources abstract class is a common meta-model element for various classes related to deployment of computational objects and related platform resources across multiple nodes. Superclass AbstractPlatformElement page 188 section 15.9.2. superclass replace "AbstractPlatformResource" with "DeploymentResources" page 188 section 15.9.3 superclass replace "AbstractPlatformResource" with "DeploymentResources" page 189 section 15.9.4 superclass replace "AbstractPlatformResource" with "DeploymentResources" page 197, section 16.3.2 AbstractUIElement add sentence: "The key subclasses of AbstractUIElement are UIResources and UIActions." page 211, section 17.3.2 AbstractEventElement add sentence: "The key subclasses of AbstractEventElement are EventResource and EventAction." page 223, section 18.3.2 AbstractDataElement add sentence: "The key subclasses of AbstractDataElement are DataResource, DataAction, XMLSchema and AbstractContentElement" page 298 In Build Figure 21.1 move BuildResource class inheritance to this diagram from Figure 21.3; page 298, section 21.3 add sentence: "BuildResource class is defined in a separate section."
Actions taken:
September 30, 2008: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 12871: Page numbers (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Already closed in KDM RTF 1.3 This issue has been already closed in KDM RTF 1.3, ballot 1
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12872: Clarification on KDM package - kdm package/ Core - core etc needed (kdm-rtf)

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

Overall comments -- I found it somewhat confusing to have differences between items just dependent  on case (e.g. KDM package and kdm package, Core and core, etc.) when the items refer to very  different things.  This occurs with several things.  Not sure whether this can be fixed or made more    clear as to the distinction, but it was a source of confusion for me in reading it.

Resolution: Page 4 �L0 compliance point� replace �as defined in the Kdm package� into �as defined in the package named �kdm� (in 2 columns) Page 7 top replace �Chapter 10. KDM package� into �Chapter 10. The Package named �kdm�� Page 15: replace �In particular, each KDM package depends on the Core package� into �In particular, each package depends on the Core package�. Replace �Also, each package depends on the kdm package� into �Also, each package depends on the package with name �kdm�. Replace �Each KDM package above the kdm package defines a KDM Model,�� Into �Each package above the package with name �kdm� in Figure 8.1 defines a viewpoint,��. Replace �The Kdm package provides the infrastructure for all KDM models.� Into �The package with name �kdm� provides the infrastructure for all viewpoints.� Replace �The nature of the dependency on the kdm package is twofold. First each package defines a subclass of the KDMModel class defined in the kdm package. Second, each kdm package provides several concrete classes that are instantiated in each KDM representation as part of the infrastructure. Kdm package defines several important mechanisms that are used by all KDM models: the annotation mechanism, the mechanism of user-defined attributes, and the light-weight extension mechanism. The meta-model elements that support these mechanisms can be instantiated by any KDM model.� Into �The nature of the dependency on the package with name �kdm� is as folllowes. First each package defines a subclass of the KDMModel class defined in that package. Second, each package provides several concrete classes that are instantiated in each KDM instance as part of the infrastructure. Third, the package with name �kdm� defines several important mechanisms that are used by all KDM models: the annotation mechanism, the mechanism of user-defined attributes, and the light-weight extension mechanism. The corresponding meta-model elements can be instantiated by any KDM model.� Page 16: replace �The Kdm package provides static context shared by all KDM models.� Into �The package with name �kdm� provides shared context for all KDM models�. Page 13 (page 43 of the ptc2009-06-05 � looks like there is a glitch in page numbers) Replace �The kdm package defines several elements that together constitute the framework of each KDM representation� into �The package with name �kdm� defines several elements that together constitute the framework of each KDM instance� Page 14 Replace �for which the KDM representation is created� into �For which the KDM views are created� Page 15 (section 9.2) replace �The KDM uses packages� into �The KDM specification uses packages� Replace �The KDM Core package consists� into �The Core package consists� Page 17 (page 47 of the ptc2009-06-15, 2nd line) replace �defined in the kdm package� into �defined in the package named �kdm� Page 25, change title of section 10 from �KDM Package� into �The Package named �kdm� � Page 25 (section 10.1) 1st paragraph replace �The Kdm package defines� into �The package with name �kdm� defines� Same paragraph: Replace �KDM representations� into �KDM views� (2 times) Replace �are instances of the KDM (which is a meta-model)� into �are collections of the elements that are instances of the meta-model elements defined by the KDM specification�. Section 10.1 paragraph 2: Replace �Kdm package describes� into �The package named �kdm� describes� Change title of 10.2 into �Organization of the KDM framework� Replace �The Kdm package is a collection � into �The package with name �kdm� is a collection� In the last paragraph on page 25 replace �The Kdm package consists� into �The package with name �kdm� consists� Replace �of the kdm framework� into �of the KDM framework� Page 12 replace �Core, kdm and Source. Core and kdm packages� into �Core, �kdm� and Source. The Core package and the package named �kdm� � Page 26 replace �The Kdm package depends� into �The package with name �kdm� depends� Page 27 replace �Each KDM Framework is the container� into �These elements are containers� Change index: replace 2 items �KDM package 9� and �Kdm package 25� with �Package named �kdm� 9,25 Page 13 (page 43 of PDF) Change �of one of the core classes� into �of one of the classes defined in the Core package� Replace �Small KDM Core� into �The Core package� Page 15 replace �Core KDM package� into �The Core package� Page 129 delete duplicate �Core� bullet Page 145 replace �with the core� into �with the code� Page 186 (page 223 of the PDF) replace �subclass core meta-model elements from the KDM Core package� into �are related to the meta-model elements defined in the Core package� Page 198 17.4 replace �inherit core meta-model classes from KDM Code package� into �inherit meta-model elements from the Core package�. Page 210 replace �various data classes derive from the Core KDM classes� into �the meta-model elements defined in the Data package are related to the meta-model elements defined in the Core package� Replace �KDM Core package� into �Core package� Page 259 replace �various data classes are types of Core KDM classes� into �the meta-model elements of the Structure package are related to the meta-model elements of the Core package.� Replace �KDM classes defined within the KDM Core package� into �meta-model elements defined in the Core package� Page 282 replace �in the KDM Core package� into �in the Core package� Disposition:
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12873: general information/comments (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There were many instances of general information/comments that apply widely made in the detailed  (specific) descriptions.  For instance, in the semantics section of 10.3.4, it is stated:  "The implementers of KDM import tools should not make any assumptions regarding the organization of the KDM models  into KDM segments."  This is a very general statement that applies widely.  As such, it would be better to be put into a general introduction  section instead of in a specific section.  Such general statements can be adapted to where they apply so they don't  read so general as in section 10.4.1:  "The implementers of KDM import tools should not make any assumptions regarding the content of the Audit element,  other than the �human-readable text.� It is expected that at least one Audit element is related to the origin of the model or  segment."  If possible, either adapt the statements so they are specific when in specific sections, or remove them to general (abstract)  sections.

Resolution: Page 25, Add sentence after �the implementer shall provide � � �On the other hand, the implemented of KDM import tools should not make any assumptions about the organization of KDM model elements in models or organization of models in segments.� Page 28, delete �The implementers of KDM import tools should not make any assumptions regarding the organization of the content into KDM models. � Page 29, delete �The implementers of KDM import tools should not make any assumptions regarding the organization of the KDM models into KDM segments.�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12874: "Constraints" sub-section in the descriptions seems to be rarely needed (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This issue has been disposed in KDM RTF 1.3 This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12875: p. 25 editorial comment (kdm-rtf)

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

p.25 (p.3) "In this case interoperability at this level would be viewed as correlation between tools to  complete knowledge puzzle that end user might need to perform a particular task." should be  "In this case interoperability at this level would be viewed as a correlation between tools to  the complete knowledge puzzle that the end user might need to perform a particular task."

Resolution: Remove sentence page 3: �This would be an additional reason why L0 interoperability (which at this level would be viewed as information sharing between tools) is mandated. In this case interoperability at this level would be viewed as correlation between tools to complete knowledge puzzle that end user might need to perform a particular task. �
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12876: p.25 (p.3) Confusion (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This issue has been disposed in KDM RTF 1.3 This issue has been already resolved in KDM RTF 1.3, ballot 1
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12877: p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer" (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer" since the other 3 bulletted items   do not have "KDM" in them.

Resolution: Page 6 replace �The KDM Infrastructure Layer� with �Infrastructure Layer� Page 11. replace �KDM Infrastructure Layer� with �Infrastructure Layer� Page 12 3rd paragraph, replace �KDM Infrastructure Layer� into �Infrastructure Layer� Page 25 replace �KDM Infrastructure� with �Infrastructure Layer� Page 13 (Part I) change title into �Infrastructure Layer� 1st paragraph replace �KDM Infrastructure Layer� with �Infrastructure Layer� Change index �KDM Infrastructure Layer 10� into �Infrastructure Layer 10�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12878: p.31 (p.9) bottom of page (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: This issue has been closed in KDM RTF 1.3 This issue has already been closed in KDM RTF 1.3, ballot 1
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12879: p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model" (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This issue has been closed in KDM RTF 1.3 This issue has already been closed in KDM RTF 1.3, ballot 1.
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12880: p.32 (p.10) "Analyst is able to refactor the model..." bullet should be changed (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.32 (p.10) "Analyst is able to refactor the model..." bullet should be something like "KDM provides model refactoring capability  for analysts..." to be consistent with the other bullets (all of the other ones start with "KDM..."

Resolution: Page 13 replace �Analyst is able to refactor the model (for example, by moving entities between containers) and map changes in the model to changes in the software through traceability links�� into �KDM provides model refactoring capabilities, for example, a KDM tool can support moving entities between containers and map changes in the model to changes in the code through the traceability links�.
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12881: spell out SBVR (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 12882: p.33 Figure 8.1 -- "Actions" should be "Action" (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.33 Figure 8.1 -- "Actions" should be "Action"

Resolution: see page 24 of ptc/2010-12-10
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12883: p.33 (p.11) editorial issues (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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"

Resolution: This issue has been disposed in KDM RTF 1.3 This issue has been disposed as duplicate in KDM RTF 1.3
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12884: p.34 (p.12) Bullet in section 8.2 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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"

Resolution: 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
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12885: p.35 (p.13) "Small KDM core..." -- need description or introduction as to what this is (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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"

Issue 12886: p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1) (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1).  Might be better to keep the  paragraph in Part 1 general and instead of repeating it, tailor it to the specific item being discussed, in this case the  KDMRelationship Class, and what being binary, for example, means to this class.  The paragraph is too general to be in this  section.  The semantics section in 9.4.3 is much more specifically tailored to the item being discussed and is much better.

Resolution: Replace entire semantics paragraph with the following: �KDMRelationship meta-model element is an abstract element. The concrete KDM relationships between KDM entities in KDM views are instances of concrete subclasses of KDMRelationship. Each instance of KDMRelationship has exactly one target and exactly one origin. Each concrete subclass of KDMRelationship defines the acceptable types of the endpoints.�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12887: p.42 (p.20) Constraints sub-section (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12888: p. 43 (p.21) descriptions of items (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.43 (p.21) Might as well make the description for the following items identical except for source/target, terminate/originate, from/at  instead of rewording the second sentence to state the same meaning (e.g. "All relations" instead of "All relationships")

Resolution: 9.5.1. Associations, Page 21, �to:KDMEntity[1]� replace �relations� with �relationships�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Discussion:

12889,12890.  Here is the continuation of the issue text:  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.  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

Issue 12889: to: KDMEntity[1] (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Issue 12890: from:KDMEntity[1] (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 12891: p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work.  There are no arrows in the figure,  contrary to the explanation in the paragraph.  Would be helpful to tie the paragraph more to the figure, e.g. instead of  "UML package symbols represent KDM Containers..." state "UML package symbols C1 and C2 represent KDM Containers..."  and instead of "Numbers at the ends of associations..." state "the numbers at the ends of associations, such as +2,..."         Also, "interpretation that UML multiplicity" needs fixing -- not sure what the sentence should read.

Resolution: Page 21 replace �AggregatedRelations are� into �AggregatedRelationship is� Page 22 top, bullet 4, replace �AggregatedRelation� into �AggregatedRelatiopnship� Page 22 Replace �The relation �x in* C� with �The relationship �x in* C� Replace �For relation R � corresponding aggregated relation� with �For relationship R� corresponding aggregated relationship� Next line replace �relation R, let� into �relationship R, let� Replace �C1 and C2 are related by the aggregated relation� with �C1 and C2 are related by the aggregated relationship� Change caption of Figure 9.4 into �AggregatedRelationships illustrated Replace �Containers and aggregated relations� into �Containers and aggregated relationships� Page 22, text after figure 9.4. replace �UML package symbols represent KDM containers� into �UML package symbols C1 and C2 represent KDM containers� Replace �Numbers at the ends of associations� into �The numbers at the ends of associations, such as �+2� � Replace �relation (there should be at least one arrow; arrows at both ends indicate two relations, one in each direction)� into �relationship, when there are no arrows at either end of the association (as in the Figure 9.4), this indicates two relationships, one in each direction.� Replace �The KDM density has a different interpretation that UML multiplicity� into �The KDM density has a different interpretation than UML multiplicity� Replace �the exact relations� into �the exact relationships� Replace �Aggregated relations are collections of more primitive relations� into �Aggregated relationships are collections of primitive relationships� Line 2 from bottom replace �code relation� into �code relationship� Page 23 line 1 replace �aggregated relation� into �aggregated relationship� Line 2 replace �aggregated relation� into �aggregated relationship� Line 3 �primitive relations� into �primitive relationships� In createAggregation operation replace �aggregated relation� into �aggregated relationship�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12892: Editorial issues p 47 through 51 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.47 (p.25) Throughout the document, "kdm package" is also spelled as "Kdm package" -- not sure which is correct  (I assumed it was kdm package until this section).  Just need to go a global search and make it consistent, whichever  it should be.         p.48 (p.26) need a space between the dash and defines in the first line ("�defines" should be "� defines")         p.51 (p.29) Example section: there are extra blank lines in the Example that need to be removed.

Resolution: resolved
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12893: p.52 (p.30) date:String and constraints (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.52 (p.30) date:String and constraints both state the constraint on the date format.  Since this is specific to the  date field, suggest removing it from the constraint sub-section.

Resolution: resolved
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12894: p.53 (p.31) Section 10.4.2 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.53 (p.31) Section 10.4.2 -- should there be more of a description here?  Maybe a reference to the KDMFramework (abstract)  section?

Resolution: Add sentence to 10.4.2 before Associations: �Audit elements can be owned by any subclass of the KDMFramework element, including segment or model.�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12895: p. 65/66 editorial issues (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.65 (p.43) "KDM offers further two options:" should be "KDM offers an additional two options:"  p.66 (p.44) "such a SourceFile, an" should be "such as a SourceFile, an"

Resolution: Section 11.1, page 43 replace "KDM offers further two options:" with "KDM offers an additional two options:"
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Discussion:

The second problem was edited out in the KDM 1.2

Issue 12896: p.69 (p.47) in the Semantics section (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.69 (p.47) in the Semantics section -- the sentence "The requirement for KDM tools is to read information in UTF-8." should be  incorporated in the next paragraph where the discussion is and "UTF-8" is introduced.

Resolution: Delete "The requirement for KDM tools is to read information in UTF-8." Add to the last paragraph of Semantics: �KDM tools shall at a minimum support UTF-8�.
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12897: p.69 (p.47) Section 11.3.6, 7, 8, 9, 10 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

.69 (p.47) Section 11.3.6, 7, 8, 9, 10... -- "The Image is used to represent image files." should be "Image is used to represent image files."  and the initial "The" should be removed in the same way from sections the other sections.  These classes are obviously very vague --  will they be expanded in a future iteration of the document?

Resolution: Page 48, section 11.3.6 replace �The Image� into �Image element� Page 48, section 11.3.7 replace �The Configuration� into �Configuration element� Page 48, section 11.3.8 replace �The ResourceDescription� into �ResourceDescription element� Page 48, section 11.3.9 replace �The BinaryFile� into �BinaryFile element� Page 49, section 11.3.10 replace �The ExecutableFile� into �ExecutableFile element�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12898: p. 178 (p. 154) -- Inputs bullet -- should be "Ordered incoming..." not "Ordered outgoing..." (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p. 178 (p. 154) -- Inputs bullet -- should be "Ordered incoming..." not "Ordered outgoing..."

Resolution: Page 154, inputs bullet replace �Ordered outgoing Reads� into �Ordered incoming Reads�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12899: p. 177 (p. 153) -- last line should be reordered (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p. 177 (p. 153) -- last line should be reordered to be the same as the items presented -- i.e. should  be Action Kind, Outputs, Inputs, Control, Extras)

Resolution: Page 153, last line, replace �5 parts (Action Kind, Inputs, Outputs, Control, and Extras)� into �5 parts (Action Kind, Outputs, Inputs, Control, Extras)�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12900: p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name.  That is, remove  "part" from "Control part" and "Extras part"

Resolution: Page 154 replace �Control part� into �Control� Replace �Extras part� into �Extras�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12901: p. 178 (p. 154) Semantics (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p. 178 (p. 154) Semantics -- need to capitalize Annex A title to match Annex A as it appears.  That  is, change the title to "Semantics of the Micro KDM Action Elements"

Resolution: Replace "Semantics of the micro KDM action elements" With "Semantics of the Micro KDM Action Elements"
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12902: Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents to logically break up the TOC such as these  heading do within the document.  These headings do segment the document logically and as such I don't see why    they are not in the TOC.  Also would make it easier to find them in the document.

Resolution: Change the TOC to include parts
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12903: ISO/IEC 11404" should be "ISO/IEC 11404:1996 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This issue has been disposed in KDM RTF 1.3 This issue has been disposed as duplicate in KDM RTF 1.3, ballot 1.
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12904: p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6 (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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)

Resolution: This issue has been disposed in KDM RTF 1.3 This issue has been disposed as duplicate by KDM RTF 1.3, ballot 1.
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12905: p.88 (p.66) Suggest changing wording (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.88 (p.66) Suggest changing "Same source files may produce a different logical model (for example, when compiled and linked  for a different hardware platform, or for a different operating system)." to "A source file may produce a different logical models when,  for example, compiled and linked for a different hardware platform, or for a different operating system.

Resolution: Section 12.5.5. replace "Same source files may produce a different logical model (for example, when compiled and linked for a different hardware platform, or for a different operating system)." With "A source file may produce a different logical models when, for example, compiled and linked for a different hardware platform, or for a different operating system.�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12906: p.101 (p.79) I don't see the use for the DateType Class (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This issue has been closed in KDM RTF 1.3 This issue has been already closed by KDM RTF 1.3
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 12907: p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404. (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.

Resolution: *Rename FloatType class into RealType * Rename FloatType into RealType to align with ISO 11404.
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

deferred to next RTF

Issue 12908: p.104 (p.82) "...defined datatype Octet String." -- "String" should be "string" (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p.104 (p.82) "...defined datatype Octet String." -- "String" should be "string"

Resolution: Page 82 12.9.16 section semantics, replace �The KMD Octetstring class � Octet String� with �The KDM OctetString class � Octet string�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 12909: Section 12 add example (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Section 12 -- I like the examples (e.g. "An example of a choice datatype is a Pascal and Ada variant record, and a union in the  C programming language.") -- maybe a new Example field could be added to the Superclass, Constraints, Semantics, etc. fields  for all parts of Section 12 -- 12.11.3 already has this and I think it is the only entry that does.

Resolution: Defered to KDM 1.5 Additional cycle will be required to evaluate the need for more examples
Revised Text:
Actions taken:
September 24, 2008: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

deferred to next RTF

Issue 12910: p. 113 (p.91) Change "return (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

p. 113 (p.91) Change "return   this is a return parameter" to "return   parameter being returned"  and "unknown   the parameter passing convention is unknown" to  "unknown   parameter passing  convention is unknown" to be consistent with the other entries.

Resolution: Page 91 Replace ��this is a return parameter� with �parameter being returned� Replace �the parameter passing convention is unknown� with �parameter passing convention is unknown�
Revised Text:
Actions taken:
September 24, 2008: received issue
April 27, 2011: closed issue

Issue 13159: KDM is missing constraints capabilities to stereotype (kdm-rtf)

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

KDM is missing constraints capabilities to stereotype. It is nice to have a metamodel element to express: * a description (in plain english) of the constraint. * the constraint language used (e.g. OCL) * the constraint expression * the severity of the constraing (WEAK / SEVERE)

Resolution: Defered to KDM 1.5 More information is needed for the use case. It is possible to add two attributes to Stereotype: constraint:String - optional expression of the constraint for the stereotype and the stereotyped elements language:String - the language in which the constraint is expressed, e.g. OCL Consumers of KDM can take advantage of this information. However this can be achieved with current KDM through Attributes.
Revised Text:
Actions taken:
December 15, 2008: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 13160: AbstractEventElement should group KDM Elements (instead of AbstractCodeElement) (kdm-rtf)

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

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

Resolution: 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.
Revised Text:
Actions taken:
December 15, 2008: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 13161: Component should allow one to express exposed and required services (kdm-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Component should allow one to express exposed and required services. An entity connection should be also created to manage the connections between them.

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
December 15, 2008: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 13162: Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews (kdm-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews

Resolution: Missing constraints on Structure package elements Assigning constraints for elements of the structure package is probably beyond the scope of a revision. I do not see the KDM as being a replacement for architecture meta-models, but rather as a connection to a separate architecture representation much like the conceptual package's connection to SBVR (to link to code artifacts for aggregate analysis).
Revised Text:
Actions taken:
December 15, 2008: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Issue 13293: Alignment with the ISO concept of architecture view (rh-2) (kdm-rtf)

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

Related to section 2.1    "KDM domains correspond to the well-known concept of architecture views." If this is true, the requirements for documenting views should be met; and the rules for interpreting such views should be provided. Usually this is done in terms of an Architectural Viewpoint definition for each view.         Satisfy requirements on each architectural view in accordance with ISO/IEC 42010.    Add Architectural Viewpoint definitions for each view in accordance with the rules of ISO/IEC 42010.

Resolution: EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with changebars the following edit instructions are collectively referred to as Issue 13293 Block 1 (see specification with changebars and editorial notes) page 1 Change sentence: Each KDM domain consists of a single KDM package that defines meta-model elements to represent particular aspects of the system under study. KDM domains correspond to the well-known concept of architecture views. Each KDM domain defines an architectural viewpoint. The viewpoint language for the domain is defined by the corresponding KDM package that defines meta-model elements to represent particular facts of the system under study that are essential to the given knowledge discovery domain. The meta-model elements defined by all KDM packages constitute the ontology for describing existing systems. Page 1 change sentence: For example, the Structure domain enables users to discover architectural elements of source code from the system under study, while the Business Rules domain provides users with behavioral elements of the same system such as features or process rules. Into For example, the Code package defines the language to represent individual code elements, such as variables, statements and procedures, the Structure package provides the language to represent architectural elements of the system such as subsystems and components, while the Conceptual package, corresponding to the Business Rules domain defines the language to represent behavioral elements of the same system such as features or business rules. KDM formally defines traceability, aggregation and derivation of facts across domains. Page 1 remove sentence: Separation of concerns in the design of KDM is embodied in the concept of KDM domains. Page 1 change sentence: The following domains of knowledge have been identified as the foundation for defining compliance in KDM: Build, Structure, Data, Business Rules, UI, Event, Platform, and micro KDM. Into: The following domains of knowledge have been identified as the foundation for defining compliance in KDM: Inventory, Code, Build, Structure, Data, Business Rules, UI, Event, Platform, and micro KDM. EDITORIAL NOTE: This is the end of Block 1. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with changebars the following edit instructions are collectively referred to as Issue 13293 Block 2 (see specification with changebars and editorial notes) Page 2: change sentence: This compliance level contains the following KDM packages: Core, kdm, Source, Code, and Action packages. Into: This compliance level addresses the Inventory and Code domains and is determined by the following KDM packages: Core, kdm, Source, Code, and Action packages. Page 2 change sentence: To be L0 compliant, a tool must completely support all model elements within all packages for L0 level. Into To be L0 compliant, a tool shall completely support all meta-model elements within all packages of L0 level. Page 2: change sentence Level 1 (L1) - This level addresses KDM domains and extends the capabilities provided by Level 0. Specifically, it adds the following packages: Build, Structure, Data, Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in sub clause 14 �Micro KDM,� and Annex A �Semantics of the Micro KDM Action Elements.� These packages are grouped to form abovementioned domains. Into Level 1 (L1) - This level addresses the remaining KDM domains and extends the capabilities provided by Level 0. Specifically, this level is determined by the following packages: Build, Structure, Data, Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in sub clause 14 �Micro KDM,� and Annex A �Semantics of the Micro KDM Action Elements.�. Page 3 change sentence: To be L1 compliant for a given KDM domain, a tool must completely support all model elements defined by the package for that domain and satisfy all semantic constraints specified for that domain. Into To be L1 compliant for a given KDM domain, a tool shall completely support all meta-model elements defined by the corresponding packages and satisfy all semantic constraints specified for that domain. EDITORIAL NOTE: This is the end of Block 2. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with changebars the following edit instructions are collectively referred to as Issue 13293 Block 3 (see specification with changebars and editorial notes) Change sentence page 12 KDM representation is a single, integrated repository of different facets of knowledge about the software system. Into KDM instance is a single, integrated representation of different facets of knowledge about the software system. EDITORIAL NOTE: This is the end of Block 3. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with changebars the following edit instructions are collectively referred to as Issue 13293 Block 4 (see specification with changebars and editorial notes) Page 9 Change from: KDM separates knowledge about existing systems into several orthogonal facets that are well-known in software engineering and are often referred to as Architecture Views. into: KDM groups facts about existing systems into several domains each of which corresponds to an ISO 42010 architectural viewpoint. Each KDM domain is represented by one or more KDM packages, which formalizes the viewpoint language for that domain. KDM focuses at the entities and their relationships that are essential for the given domain. A KDM representation of a given existing system � KDM instance - is a collection of facts about that system. These facts are organized into KDM models per each domain. KDM model corresponds to an ISO 42010 architectural view. KDM facts are further organized into meaningful groups called segments. A KDM segment may include one or more architectural views of the given system. KDM instances may be part of the complete architectural description of the system, as defined by ISO 42010, in which case additional requirements of ISO 42010 shall be satisfied by the overall document. KDM instances are represented as XML documents conforming to the KDM XMI schema. Add clarification page 9 after sentence: Logically, KDM consists of 9 models. Each KDM model is described by one or more KDM packages and corresponds to one KDM domain. Most KDM domains are defined by a single package, with the exception of the Code domain, which is split between the Code and the Action packages. EDITORIAL NOTE: This is the end of Block 4. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with changebars the following edit instructions are collectively referred to as Issue 13293 Block 5 (see specification with changebars and editorial notes) Page 27: Change from: A KDM model corresponds to one of the well-known architecture views of software systems. KDM defines several concrete subclasses of the KDMModel class. To: A KDMModel element is an abstract class that defines the common properties of KDM model instances which are collection of facts about a given existing system from the same architectural viewpoint of one of the KDM domains. KDM defines several concrete subclasses of the KDMModel class, each of which defines a particular kind of a KDM model. The architectural viewpoint is defined by the corresponding KDM package. A KDM model instance is an architectural view of the given system.
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

In terms of ISO/IEC 42010 KDM domains correspond to architectural viewpoints. A  KDM package defines a viewpoint language for the corresponding domain. A particular  instance of a single KDM Model is an architectural view of a given system. It represents  a collection of facts about the given system, for a particular facet of knowledge. KDM  instances can be part of an architectural description of the system, whereby such  architectural description should satisfy additional requirements defined by ISO 42010.  With this understanding, the resolution involves the following editorial changes to the  text of the specification (changed text is underlined, whenever appropriate):

Issue 13294: Missing definitions of terms (rh-3) (kdm-rtf)

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

Related to section 4    It is hard to believe that there are "no special terms or definitions in this specification", since usage of a number of terms in this DIS seem to have no relationship to other, more common usages of those same terms.    Define the terms that have specialzed meanings or usage in this DIS. ISO/IEC 42010:2007 provides a well established ontology for describing architectures of various types, presumably including "Architecture Driven Modernization" senses of "Architecture". For the architecture-related terms, architecture, architecture description, architecture view, architecture viewpoint and architecture model, adopt the defintions from ISO/IEC 42010:2007

Resolution: Section 4, Page 6 �Terms and Definitions� Replace sentence �There are no special terms or definitions in this specification.� with the following text: This subclause contains only those terms which are used in a specialised way throughout the KDM specification. The majority of terms in KDM are used either according to their accepted dictionary definitions or according to commonly accepted definitions that may be found in ISO glossaries or other well-known collections of software engineering terms. Some combinations of common terms used in KDM, while not meriting glossary definition, are explained for clarity in the context where they are used. Abstraction: A view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information. Aggregation: a derived relationship between two elements that are groups of other elements that represents all individual relationships between the grouped elements of the two groups. Architecture-Driven Modernization (ADM): ADM is the process of understanding and evolving existing software assets of a system of interest. ADM focuses at collecting, sharing, utilizing, transforming, presenting, maintaining and storing models of the architectural aspects of existing systems. ADM does not preclude source-to-source migrations (where appropriate), but encourages user organizations to consider modernization from an analysis and design perspective. In doing so, project teams ensure that obsolete concepts or designs are not propagated into modern languages and platforms. Build: An operational version of a system or component that incorporates a specified subset of the capabilities that the final product provides. Build process: a process of transforming of project code base into usable applications. The end result of a software build is a collection of files that consitute a product in a distributable package. In this case, package can mean a standalone application, Web service, compact disc, hotfix, or bug fix. Each step of a build process is a transformation performed by software running on a general purpose computer. A simple software build may involve compiling a single source code file into an executable code. A complex software build may involve orchestrating hundreds of versions of thousands of files with millions of lines of source code such that a correct executable code results from the compilation. The implementation of a system also involves deploying the build onto the system nodes, and applying appropriate configuration settings. Component: a functionally or logically distinct part of a system. A component may be hardware or software and may be subdivided into other components. Often a component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. Such component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files. Container: a model element that owns one or more distinct elements through the special �owns� (�contains�) relationships between the container element and owned elements. �Containment� relationships form a special group of the corresponding owned elements. No element has more than one container. Domain : An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. Element: one of the parts of a compound or complex whole. For example, a model element, a meta-model element. Group: a number of model elements regarded as a unit formed by traceability relationships to a single distinct element. An element may be part of multiple groups, including a single group formed by the �containment� relationships between a container and its owned elements. An element is said to group together one or more elements, if these elements have traceability relationships to the element. Hierarchy: an arrangement of model elements according to traceability relationships, where an element that �owns� or �group� other elements is considered at a higher level than the owned (grouped) elements. Interface: (1) a shared boundary or connection between two dissimilar objects, devices or systems through which information is passed. The connection can be either physical or logical. (2) a named set of operations that characterize the behavior of an entity Item: that which can be individually described or considered. See also Component, Element, Unit, Module. KDM Entity: a meta-model element (as well as the corresponding model elements) that represents a thing of significance of the system of interest, about which information needs to be known or held. A KDM entity is an abstraction of some element of the system of interest that has a distinct, separate existence objective or conceptual reality, a selfcontained piece of data that can be referenced as a unit. As a model element each KDM entity is an instance of some specific meta-model element and it usually the endpoint of distinct KDM relationships. KDM instance: a collection of KDM model elements that represent one or more views of the system of interest. KDM model: a meta-model element (as well as the corresponding model elements) that is a container for a KDM view KDM Relationship: a meta-model element (as well as the corresponding model elements) that represents some semantic association between elements of the system of interest. All KDM relationships are binary. As a model element each KDM relationship is an instance of some specific meta-model element. Meta-model: A special kind of model that specifies the abstract syntax of a modeling language. The typical role of a metamodel is to define the semantics for how model elements in a model get instantiated. A model typically contains model elements. These are created by instantiating model elements from a metamodel, i.e., metamodel elements. Meta-model element: an element of a meta-model from which model elements are instantiated. Model: A model represents a system of interest, from the perspective of a related set of concerns. The model is related to the system by an explicit or implicit isomorphism. Models are instances of MOF meta-models and therefore consist of model elements and links between them. Model element: instance of a meta-model element Module. (1) A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading; for example, the input to, or output from, an assembler, compiler, linkage editor, or executive routine. (2) A logically separable part of a program. Resource: any physical or virtual component of limited availability within a computer system available for a given purpose and managed by the runtime platform. Runtime platform: the set of hardware and software components that implement the services utilized by the application software. A runtime system generally controls how several tasks are scheduled to run, and manages resources. Its provisions for the programmer typically form an Application Programming Interface� a set the welldocumented ways of using the system. Segment: A collection of data that corresponds to one or more coherent views of a system of interest that is stored or transferred as a unit. Software artifact: A software artifact is a tangible machine-readable document created during software development. Examples are requirement specification documents, design documents, source code and executables. Software asset: A software asset is a description of a partial solution (such as a component or design document) or knowledge (such as requirements database or test procedures) that engineers use to build or modify software products. A software asset is a set of one or more related artifacts that have been created or harvested for the purpose of applying that asset repeatedly in subsequent contexts. The asset consumer is an architect or a designer of any type of IT or business process solutions from solution business modeling, analysis (assets used are models) and design to application development (assets used are pieces of code). Traceability: The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match. Unit : (1) a piece or complex of apparatus serving to perform one particular function (2) A software element that is not subdivided into other elements. User interface: An interface that enables information to be passed between a human user and hardware or software components of a computer system. View: A representation of a whole system from the perspective of a related set of concerns. Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
Revised Text:
Actions taken:
January 16, 2009: received issue
April 27, 2011: closed issue

Issue 13295: Missing definition of software asset (rh-4) (kdm-rtf)

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

Related to section 4    Unable to determine intended scope of this standard without a definition of "software asset". Does it intend to cover information items as defined in ISO 15289?    Define "software asset". Clarify which information items and work products specified in ISO 15289 are included within the scope of this DIS.

Resolution: In the following editing instructions, the occurrences of terms in the original sentences are highlighted, and the changes are underlined. Change sentence Page 1. This specification defines a meta-model for representing existing software assets, their associations, and operational environments, referred to as the Knowledge Discovery Meta-model (KDM). Into: This specification defines a meta-model for representing existing software, its elements, associations, and operational environments, referred to as the Knowledge Discovery Meta-model (KDM). Change sentence Page 1. One common characteristic of various tools that address SwA and ADM challenge is that they analyze existing software assets (for example, source code modules, database descriptions, build scripts, etc.) to obtain explicit knowledge. Into One common characteristic of various tools that address SwA and ADM challenge is that they analyze existing software artifacts (for example, source code modules, database descriptions, build scripts, etc.) to obtain explicit knowledge.. Change sentence page 1: Each tool produces a portion of the knowledge about existing software assets. Such tool-specific knowledge may be implicit (�hard-coded� in the tool), restricted to a particular source language, and/or particular transformation, and/or operational environment. Into: Any tool that operates on existing software produces some portion of the knowledge about the given software system. However, such tool-specific knowledge may not be exported in any explicit format. For example, such knowledge may be used internally by the tool: a compiler generates precise knowledge about a compilation unit only to discard it as soon as the object file is generated. Tool-specific knowledge may be limited in scope, restricted to a particular source language and/or particular transformation, and/or particular operational environment. Change sentence Page 1. The meta-model for Knowledge Discovery provides a common repository structure that facilitates the exchange of data contained within individual tool models that represent existing software assets. The meta-model represents the physical and logical assets at various levels of abstraction. Into The meta-model for Knowledge Discovery provides a common ontology and an interchange format that facilitates the exchange of data contained within individual tool models that represent existing software. The meta-model represents the physical and logical elements of software as well as their relations at various levels of abstraction. Change Page 9. section 7. This specification defines a meta-model for representing information related to existing software assets, their associations, and operational environments (referred to as the Knowledge Discovery Meta-model (KDM)). Into This specification defines a meta-model for representing information related to existing software, its elements, associations, and operational environments (referred to as the Knowledge Discovery Meta-model (KDM)). Change sentence Page 9. section 7. More specifically, (KDM) provides a common repository structure that facilitates the exchange of data currently contained within individual tool models that represent existing software assets. The meta-model represents the physical and logical software assets at various levels of abstraction as entities and relations. Into More specifically, (KDM) defines a common ontology and an interchange format that facilitates the exchange of data currently contained within individual tool models that represent existing software. The meta-model represents the physical and logical elements of software as well as their relations at various levels of abstraction. EDITORIAL NOTE: For traceability purposes the following minor edits are marked as Block 2 in the specification text with changebars Section 10.1 change �application� into �system� KDM instance is not a model that represents constraints, like the ones used during the design phase, rather, this is an intermediate representation that captures precise knowledge about the system. Section 10.1 change �artifacts� to �elements� The remaining KDM packages provide meta-model elements that represent various elements of existing systems. Section 11.1 The Source package also represents traceability links between instances of KDM meta-elements and the regions of source code, which is represented by these meta-model elements.
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

The term �software asset� is already used in several ISO documents. It often has a connotation of a  �reusable solution�. The suggested resolution to this issue is change the occurrences of the term �existing  software assets� into �existing software�, emphasizing its elements, associations and operational  environment.

Issue 13296: Need to clarify the use of term �view� and align with ISO (rh-5) (kdm-rtf)

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

Related to section 4                "View" is used in a number of context. Sometimes as "architectural view" other times, unclear             Clarify when "architecture view" in intended, and use ISO 42010 definition. If "database view" is meant (which is a very different notion); make that clear. If both notions are needed; qualify each usage.

Resolution: The resolution to this issue involves the following editorial changes: EDITORIAL NOTE: for the purposes of traceability the following changes will be referred to as block 1 in the editorial note in the specification text with changebars Change sentence Page 6: Chapter 11. Source package - This package describes meta-model elements for specifying the linkage between the KDM model artifacts and their physical implementations in the artifacts of existing software. Elements of the Source package allow viewing the source code, corresponding to KDM model elements. Into: Chapter 11. Source package � Describes meta-model elements that provide traceability from KDM facts to the original representation of the software item (for example, the source code). Change sentence Page 7 Chapter 20. Conceptual package - Describes the meta-model elements for representing business domain knowledge about existing applications in the context of other KDM views. Into Chapter 20. Conceptual package � Describes meta-model elements that represent facts related to the business domain of the existing system and provide traceability to other KDM facts. Change sentence Page 7: Chapter 21. Build package - Describes the meta-model elements for representing the artifacts involved in building the software system (the engineering view of the software system). Into: Chapter 21. Build package - Describes the meta-model elements that represent the facts related to the build process of the software system (including but not limited to the engineering transformations of the �source code� to �executables�). Build package defines the architectural viewpoint for the Build domain. EDITORIAL NOTE: This is the end of Block 1 EDITORIAL NOTE: for the purposes of traceability the following changes will be referred to as block 2 in the editorial note in the specification text with changebars Change sentence Page 13: Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems. Into Each KDM package defines several meta-model elements that represent specific entities for a particular KDM domain. Change sentence Page 13: Each KDM package defines several relationship types representing specific abstractions related to a certain viewpoint on existing software systems. Into Each KDM package defines several meta-model elements that represent specific relationships for a particular KDM domain. EDITORIAL NOTE: This is the end of Block 2 EDITORIAL NOTE: for the purposes of traceability the following changes will be referred to as block 3 in the editorial note in the specification text with changebars Change sentence Page 18: Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems. Into Each KDM package defines several meta-model elements that represent specific entities for a particular KDM domain. EDITORIAL NOTE: This is the end of Block 3 EDITORIAL NOTE: for the purposes of traceability the following changes will be referred to as block 4 in the editorial note in the specification text with changebars Change sentence Page 19: Each KDM package defines several relationship types representing specific abstractions related to a certain viewpoint on existing software systems. Into Each KDM package defines several meta-model elements that represent specific relationships for a particular KDM domain. EDITORIAL NOTE: This is the end of Block 4 EDITORIAL NOTE: for the purposes of traceability the following changes will be referred to as block 5 in the editorial note in the specification text with changebars Change sentence section 10.2 page 25: There are 9 kinds of models, corresponding to some well-known concerns of software engineering. Into There are 9 kinds of models. Each KDM model is described by one or more KDM packages and corresponds to one KDM domain. Change sentence section 10.2, page 25, From the architectural perspective, each KDM model represents a particular view of the existing system. From the infrastructure perspective, a KDM model is a typed container for model element instances. From the meta-model perspective, KDM model is represented by a separate package that defines a collection of the meta-model elements, which can be used to build representations of the particular view of existing systems. Into From the architectural perspective, each KDM package defines an architectural viewpoint. KDM model is the key mechanism to organize individual facts into architecture views. From the infrastructure perspective, a KDM model is a typed container for meta-model element instances (collection of facts organzied into an architectural view). From the meta-model perspective, each KDM model is represented by a separate KDM package that defines a collection of the meta-model elements, which can be used to represent the facts about the given existing systems from a particular viewpoint. Change sentence Page 27 A KDM model corresponds to one of the well-known architecture views of software systems. Into Each KDM model defines an architectural viewpoint. An instance of a KDM model is an architectural view of the given existing system. Physically every instance of KDMModel element and its subclasses is a container for the facts from the corresponding KDM domain. Change sentence Page 29: The Segment element represents a coherent set of logically related KDM models that together provide a useful view of an existing software system. Into The Segment element is a container for a meaningful set of facts about an existing software system. Each Segment may involve one or more KDM model instances and thus represents a collection of one or more architectural views for a given existing system. Change sentence Page 29: Each KDM model defines KDM entities representing a certain view of the existing software system. Each KDM model defines specific meta-model elements. Into Each KDM model defines an architectural viewpoint. KDM model defines specific metamodel elements (entities and relationships specific to the viewpoint) that collectively define the viewpoint language. Change sentence Page 43: The Source package defines the KDM Inventory model that corresponds in part to the engineering view of the existing software system. Into The Source package defines an architectural viewpoint for the Inventory domain. Change section 11.1 sentence: The Source package also represents traceability links between instances of KDM meta-elements and the regions of source code, which is represented by these meta-model elements. It represents the convergence between the KDM intermediate representation and the application source it represents Into: The Source package also represents traceability links between instances of KDM meta-elements and the regions of source code, which is represented by these meta-model elements. It represents the link between the KDM instance and the corresponding artifacts of the existing system. Change sentence Page 44: InventoryModel class diagram defines meta-model elements that represent the artifacts of the existing software system as �first class citizens� on the KDM instance. into : InventoryModel class diagram defines meta-model elements that represent the physical artifacts of the existing software system. Change sentence Page 44: The InventoryModel class diagram follows the uniform pattern for KDM model to extend the KDM Framework with specific meta-model elements related to the engineering view of existing software systems. into The InventoryModel class diagram follows the uniform pattern for KDM model to extend the KDM Framework with specific meta-model elements. Change sentence Page 45: The InventoryModel is a specific KDM model which corresponds to the physical (engineering) view of the existing software system. into The InventoryModel is a specific KDM model which represents facts related to the physical artifacts of the existing software system. Change sentence Page 51: KDM Build package that constitutes a separate L1.Build compliance point, defines more precise meta-model elements to represent the engineering view of the software system. into KDM Build package that constitutes a separate L1.Build compliance point, defines additional meta-model elements that represent the facts involved in building the software system (including but not limited to the engineering transformations of the �source code� to �executables�). Remove sentence Page 59: This facet of knowledge about existing software systems corresponds to the logical view. Change sentence Page 61 The CodeModel is the specific KDM model that corresponds to the logical view of the implementation of the existing software system. Into The CodeModel is the specific KDM model that represents collections of facts about the existing software system such that these facts correspond to the Code domain. Change sentence Page 164: Platform model defines one of the architectural views in support of the principle of separation of concerns in KDM models. Into PlatformModel is the specific KDM model that represents collections of facts about the existing software system such that these facts correspond to the Platform domain. Remove sentence Page 177 The logical view of KDM model describes one or more SoftwareSystems. Change sentence Page 207 This fact of knowledge corresponds to the logical view. It is determined by a data description language. Into Fact in the Data domain are usually determined by a certain Data Description Language (for example, SQL) but may in some cases be determined by the code elements. Change sentence Page 253: Abstraction Layer defines a set of meta-model elements whose purpose is to represent domain-specific and application-specific abstractions, as well as the engineering view of the exsting software system. Into Abstraction Layer defines a set of meta-model elements that represent domain-specific and applicationspecific abstractions, as well as the artifacts related to the build process of the existing software system. Change sentence Page 262: The Conceptual package defines meta-model elements for representing highlevel, high-value application-specific �conceptual� views of existing software systems. Into The Conceptual package defines meta-model elements for representing high-level, high-value applicationspecific �conceptual� elements of existing software systems and their traceability to other KDM facts. Change the sentence Page 263: The ConceptualModel class is a KDM model that extends the KDM Infrastructure framework to provide the infrastructure for representing conceptual views of existing software systems. Into The ConceptualModel is the specific KDM model that represents collections of facts about conceptual elements implemented by a given existing software system. Change sentence Page 279: The Build package represents the artifacts that represent the engineering view of a particular existing system. The Build package also includes the entities to represent the artifacts that are generated by the build process. into The Build package defines meta-model elements that represent the facts involved in building the software system (including but not limited to the engineering transformations of the �source code� to �executables�). The Build package also includes the meta-model elements to represent the artifacts that are generated by the build process. Change sentence Page 279 The Build package defines a collection of meta-model elements that represent entities and relationships related to the engineering view of existing software systems. Into The Build package defines a collection of meta-model elements that represent entities and relationships related to the build process of an existing software system. Change sentence Page 279 The BuildModel class diagram provides basic meta-model constructs to model the engineering view of a particular existing software system within the KDM framework. into The BuildModel class diagram provides basic meta-model elements that represent entities and relationships related to the build process of an existing software system.
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13297: Clarify the usage of �view� (rh-6) (kdm-rtf)

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

Related to section 7, paragraph 3    "ADM KDM separates knowledge about existing systems into several orthogonal facets that are well-known in software engineering and are often referred to as Architecture Views."       Clarify usage of view. if Architectural View is intended, following rules of ISO 42010 to enable readers understand intent.

Resolution: Editorial changes to the text of the specification related to the resolution of this issue are part of the resolution to another issue 13296 Disposition: Duplicate
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Issue 13298: Clarify the intent of KDM ontology (rh-7) (kdm-rtf)

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

Related to section 7, paragraph 13, bullet 3         "KDM defines an ontology for describing existing software systems"        Clarify whether the intent is an ontology for systems or software assets of system. These are very different subject matters

Resolution: Add to page 10 (ontology bullet), and move that bullet to the end of the list: The ontology defined by KDM is related to the elements of existing software systems, and the relationships between these elements, as well as the elements of the operational environment of the software system. KDM ontology addresses both physical elements (for example, a procedure, a variable, a table), which are originally represented by language-specific artifacts of the software (for example source code), as well as logical elements (for example, user interface elements, concepts that are implemented by the software, architectural components of the software, such as layers, etc.)
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Issue 13299: Reference ISO terminology (rh-8) (kdm-rtf)

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

Related to section 7, paragraph 13, bullet 5         "KDM defines multiple hierarchies of entities via containers and groups." It is very difficult to read this sentence and accept the claim in 4 that there are no special terms in this document. Terms like GROUP, CONTAINER, HIERARCHY have ordinary language meanings, numerous technical meanings.         The DIS should define those terms it depends upon, either within the current document, or by reference to other standards (or if they ordinary language sense of these terms is intended) to a suitable dictionary

Resolution:
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

Resolution to this issue is provided as part of the resolution to another issue 13294, where a  glossary of terms in introduced.  Disposition: Duplicate

Issue 13300: Align structure package with ISO 42010 (rh-9) (kdm-rtf)

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

Related to 8.2, paragraph 1, bullet 10         "Structure package defines the architectural components of existing application, subsystems, layers, packages, etc."    DIS should articulate how the Structure package supports common architectural concepts of architecture, architecture description, architecture viewpoint, architecture view,  and architecture model per ISO 42010

Resolution: Change sentence Page 12, Structure package defines the architectural components of existing application, subsystems, layers, packages, etc. into Structure package defines meta-model elements that represent architectural components of existing software systems, such as subsystems, layers, packages, etc. and define traceability of these elements to other KDM facts. Editorial changes to the other bullets of the list: Change bullet: The Source package defines the inventory of the physical artifacts of the existing software system and references to the source code. Into The Source package defines meta-model elements that represent the inventory of the physical artifacts of the existing software system and define the key traceability mechanism of KDM � how KDM facts reference back to their original representation in the artefacts of the software system (for example, source code). Change bullet: The Code package defines the low-level building blocks of application source files, such as procedures, datatypes, classes, etc. (as determined by a programming language). Into The Code package defines meta-model elements that represent the low-level building blocks of software such as procedures, datatypes, classes, variables, etc. (as determined by a programming language). Change bullet: Action package defines end points of relations, and the majority of KDM relations. Into Action package defines meta-model elements that represent s statements of software as the end points of relations, as well as the majority of low-level KDM relations. Change bullet: Platform package defines artifacts, related to the run time platform of the enterprise application. Into Platform package defines meta-model element that represent the run time resources used by the software systems, as well as relationships determined by the run-time platform. Change bullet: UI package defines the user-interface aspects of the application. Into UI package defines meta-model element that represent the user-interface aspects of the application. Change bullet: Event package defines a common concept related to event-driven programming. Into Event package defines meta-model element that represent event-driven aspects of the software systems, such as events, states, state transitions, as well as relations determined by the event-driven semantics of the application�s run-time framework. Change bullet: Data package defines the persistent data aspects of an application. Into Data package defines meta-model elements that represent persistent data aspects of the software system. Change bullet: Conceptual package defines the domain-specific elements of an application. Into Conceptual package defines meta-model elements that represent the domain-specific elements of existing software system. Change bullet: Build package defines the artifacts related to engineering of an application. Into Build package defines meta-model elements that represent the artefacts related to the build process of the software system (including but not limited to the engineering transformations of the �source code� to �executables�).
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13301: Align KDM Package with ISO Architecture Views (rh-10) (kdm-rtf)

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

Related to 8.2, Part I         "Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems."         The architectural viewpoints being employed should be made explicit, and defined as per ISO 42010

Resolution: Add definitions of architecture viewpoints for each package that defines an architectural viewpoint: Section 11.1 Page 43 Inventory architecture viewpoint Concerns: � What are the artifacts (software items) of the system? � What is the general role of each artifact (for example, is it a source file, a binary file, an executable or a configuration description)? � What is the organization of the aritifacts (into directories and projects)? � What are the dependencies between the artifacts? Viewpoint language: Inventory views conform to KDM XMI schema. The viewpoint language for the Inventory architectural viewpoint is defined by the Source package. It includes an abstract entity AbstractInventoryElement, several generic entities, such as InventoryItem and InventoryContainer, as well as several concrete entities, such as SourceFile, BinaryFile, Image, Directory, etc. The viewpoint language for the Inventory architectural viewpoint also includes DependsOn relationship, which are subclasses of AbstractInventoryRelationship. Analytic methods: The Inventory architectural viewpoint supports the following main kinds of checking: � What artifacts depend on the given artifact? The Inventory viewpoint also supports check in combinations with other KDM architectural viewpoint to determine the original artifacts that correspond to a given KDM element. Construction methods: � Inventory views that correspond to the KDM Inventory architectural viewpoint are usually constructed by directory scanning tools, which identify files and their types. � Construction of an Inventory view is determined by the particular development and deployment environments of the existing software system � Construction of an Inventory view is determined by the semantics of the environment as well as the semantics of the corresponding artifacts, and it based on the mapping from the given environment to KDM The mapping from a particular environment to KDM may produce additional information (system-specific, or environment-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Change sentence: It represents the convergence between the KDM intermediate representation and the application source it represents. Into It represents the association between the KDM model and the artifacts it represents. Part II Program Elements Page 57 Code architecture viewpoint Concerns: � What are the computational elements of the system? � What are the modules of the system? � What is the low-level organization of the computational elements? � What are the datatypes used by the computational elements? � What are the units of behaviour of the system? � What are the low-level relationships between the code elements, in particular what are the control-flow and data-flow relationships ? � What are the important non-computational elements? � How computational elements and modules are related to the physical artifacts of the system? Viewpoint language: Code views conform to KDM XMI schema The viewpoint language for the Code architectural viewpoint is defined by the Code and Action packages. It includes several abstract entities, such as AbstractCodeElement and CodeItem, several generic entities, such as Datatype, ComputationalObject and Module, as well as several concrete entities, such as StorableUnit, CallableUnit, CompilationUnit and ActionElement. The viewpoint language for the Code architectural viewpoint also includes several relationships, which are subclasses of AbstractCodeRelationship and AbstractActionRelationship. Analytic methods: The Code architectural viewpoint supports the following main kinds of checking: � Composition (for example, what code elements are owned by a CompilationUnit, SharedUnit or a CodeAssembly; what action elements are owned by a CallableUnit) � Data flow (for example, what action elements read from a given StorableUnit; what action elements write to a given StorableUnit; what action elements create dynamic instances of a given Datatype; what action elements address a particular StorableUnit; what data element are being read as actual parameters in a call) � Control flow (for example, what CallableUnit is used in a call; what action element is executed after the given action element; what action elements are executed before the given action element; what data element is used to dispatch control flow from a given action element; what action element is executed after the given element under what conditions; what is the exceptional flow of control; what action elements are executed as entry points to a given module or a CallableUnit) � Datatypes (for example, what is the datatype of the given storable unit; what is the base datatype of the given pointer type; what is the base datatype of the given element of the record type; what is the signature of the given CallableUnit) Other kind of checking are related to the interfaces, templates and pre-processor. All relationships defined in the Code model are non-transitive. Additional computations are required to derive, for example, all action elements that can be executed after the given action element, or all CallableUnits that a given action element can dispatch control to. The KDM mechanism of aggregated relationship is used to derive relationships between KDM elements that own or reference various Code elements (usually, Module and CodeAssembly) based on the low-level relationship between individual Code elements Construction methods: � Code views that correspond to the KDM Code architectural viewpoint are usually constructed by parser-like tools which take artifacts of the system as the input and produce one or mode Code views as output � Construction of the Code view is determined by the syntax and semantics of the programming language of the corresponding artifact, and it based on the mapping from the given programming language to KDM; such mapping is specific only to the programming language and not to a specific software system � The mapping from a particular programming language to KDM may produce additional information (system-specific, or programming language-specific, or extractor toolspecific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 15.1, page 163 KDM Platform architecture viewpoint Concerns: � What are the resources used by the software system? � What elements of the run-time platform are used by the software system? � What behaviour is associated with the resources of the run-time platform? � What control flows are initiated by the events in the resources? � What control flows are initiated by the run-time environment? � What are the bindings to the run-time environment? � What are the deployment configurations of the software system? � What are the dynamic/concurrent threads of activity within the software system? Viewpoint language: Platform views conform to KDM XMI schema The viewpoint language for the Platform architectural viewpoint is defined by the Platform package. It includes an abstract entity AbstractPlatformElement, several generic entities, such as ResourceType, RuntimeResource, as well as several concrete entities, such as PlatformAction, PlatformEvent, ExternalActor, MarshalledResource, NamingResource, etc. The viewpoint language for the Platform architectural viewpoint also includes several relationships, which are subclasses of AbstractPlatformRelationship. Analytic methods: The Platform architectural viewpoint supports the following main kinds of checking: � Data flow (for example, what action elements read from a given resource; what action elements write to a given resource; what action elements manage a given resource; including indirect data flow using a MarshalledResource or a MessagingResource where a particular resource is used to perform a data flow between the �send� action element and the �receive� action element) � Control flow (for example, what action elements are triggered by events in a given resource; what action elements operate on a given resource) � Identify of resource instances based on resource handles in various modules Platform Views are used in combination with Code views and Inventory views. Construction methods: � Platform views that correspond to the KDM Platform architectural viewpoint are usually constructed by analyzing Code views for the given system as well as the platformspecific configuration artifacts. The platform extractor tool uses the knowledge of the API and semantics for the given run-time platform to produce one or mode Platform views as output As an alternative, for some languages like Cobol, in which the elements of the run-time platform are explicitly defined by the language, the platform views are produced by the parser-like tools which take artifacts of the system as the input and produce one or mode Platform views as output (together with the corresponding Code views) � Construction of the Platform view is determined by the semantics of the run-time platform, and it based on the mapping from the given run-time platform to KDM; such mapping is specific only to the run-time platform and not to a specific software system � The mapping from a particular run-time platform to KDM may produce additional information (system-specific, or platform-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 16.1, page 183 UI architecture viewpoint Concerns: � What are the distinct elements of the user interface of the systems? � What is the organization of the user interface? � How user interface uses artifacts of the system (for example, images) ? � What data flows originate from the user interface ? � What data flows output to the user interface? � What control flows are initiated by the user interface? Viewpoint language: UI views conform to KDM XMI schema The viewpoint language for the UI architectural viewpoint is defined by the UI package. It includes an abstract entity AbstractUIElement, several generic entities, such as UIResource, UIDisplay, as well as several concrete entities, such as Screen, Report, UIField, UIAction, UIEvent, etc. The viewpoint language for the UI architectural viewpoint also includes several relationships, which are subclasses of AbstractUIRelationship. Analytic methods: The UI architectural viewpoint supports the following main kinds of checking: � Data flow (for example, what action elements read from a given UI element; what action elements write to a given UI element; what action elements manage a given UI element) � Control flow (for example, what action elements are triggered by events in a given UI element; what action elements operate on a given UI element) � Workflow (what UI elements will be displayed after the given one; what UI elements are displayed before the given one) UI Views are used in combination with Code views and Inventory views. Construction methods: � UI views that correspond to the KDM UI architectural viewpoint are usually constructed by analyzing Code views for the given system as well as the UI-specific configuration artifacts. The UI extractor tool uses the knowledge of the API and semantics for the given run-time platform to produce one or mode UI views as output � As an alternative, for some languages like Cobol, in which the elements of the UI are explicitly defined by the language, the UI views are produced by the parser-like tools which take artifacts of the system as the input and produce one or mode UI views as output (together with the corresponding Code views) � Construction of the UI view is determined by the semantics of the UI platform, and it based on the mapping from the given UI platform to KDM; such mapping is specific only to the UI platform and not to a specific software system � The mapping from a particular UI platform to KDM may produce additional information (system-specific, or platform-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 17.1, page 195 Event architecture viewpoint Concerns � What are the distinct states involved in the behaviour of the software system? � What are the events that cause transitions between states? � What action elements are executed in a given state? Viewpoint language: Event views conform to KDM XMI schema The viewpoint language for the Event architectural viewpoint is defined by the Event package. It includes an abstract entity AbstractEventElement, generic entity EventResource, UIDisplay, as well as several concrete entities, such as State, Transition, Event, EventAction, etc. The viewpoint language for the UI architectural viewpoint also includes several relationships, which are subclasses of AbstractEventRelationship. Analytic methods: The Event architectural viewpoint supports the following main kinds of checking: � Reachability (for example, what states are reachable from the given state) � Control flow (for example, what action elements are triggered by a given state transition; what action elements will be executed for a given traversal of the state transition graph) � Data flow (what data sequences correspond to a given traversal of the state transition graph) Event Views are used in combination with Code views, Data views, Platform views and Inventory views. Construction methods: � Event views that correspond to the KDM Event architectural viewpoint are usually constructed by analyzing Code views for the given system as well as the configuration artefacts specific to the event-driven framework. The Event extractor tool uses the knowledge of the API and semantics of the event-driven framework to produce one or mode Event views as output � Construction of the Event view is determined by the semantics of the event-driven framework, and it based on the mapping from the given event-driven framework to KDM; such mapping is specific only to the event-driven framework and not to a specific software system � The mapping from a particular event-driven framework to KDM may produce additional information (system-specific, or platform-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 18.1, page 207 Data architecture viewpoint Concerns � What is the organization of persistent data in the software systems? � What are the information model supported by the software system? � What action elements read persistent data? � What action elements write persistent data? � What control flows are determined by the events corresponding to persistent data? Viewpoint language Data views conform to KDM XMI schema The viewpoint language for the Data architectural viewpoint is defined by the Data package. It includes abstract entities AbstractDataElement, AbstractContentElement, generic entities DataResource, DataContainer, ContentItem, as well as several concrete entities, such as Catalog, RelationalSchema, DataEvent, DataAction, ColumnSet, RecordFile,XMLSchema, etc. The viewpoint language for the Data architectural viewpoint also includes several relationships, which are subclasses of AbstractDataRelationship. Analytic methods: The Data architectural viewpoint supports the following main kinds of checking: � Data aggregation (the set of data items accessible from the given ColumnSet by adding data items through foreign key relationships to other tables) Data Views are used in combination with Code views and Inventory views. Construction methods: � Data views that correspond to the KDM Data architectural viewpoint are usually constructed by analyzing Data Definition Language artifacts for the given data management platform. The Data extractor tool uses the knowledge of the data management platform to produce one or mode Data views as output � As an alternative, for some languages like Cobol, in which some elements of the Data are explicitly defined by the language, the Data views are produced by the parser-like tools which take artifacts of the system as the input and produce one or mode Data views as output (together with the corresponding Code views) � Construction of the Data view is determined by the semantics of the data management platform, and it based on the mapping from the given data management platform to KDM; such mapping is specific only to the data management platform and not to a specific software system � The mapping from a particular data management platform to KDM may produce additional information (system-specific, or platform-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 19.1, page 255 Structure architecture viewpoint Concerns: � What are the structural elements of the system, and what is the organization of these elements? � What software elements compose the system? � How the structural elements of the system are related to the computational elements? � What are the connections of these elements based on the relationships between the corresponding computational elements? � What are the interfaces of the structural elements of the system? Viewpoint language: Structure views conform to KDM XMI schema The viewpoint language for the Structure architectural viewpoint is defined by the Structure package. It includes abstract entitity AbstractStructureElement, and several concrete entities, such as Subsystem, Layer, Component, SoftwareSystem, ArchitectureView. The viewpoint language for the Structure architectural viewpoint also includes an abstract relationship AbstractStructureRelationship. Analytic methods: The Structure architectural viewpoint supports the following main kinds of checking: � Attachment (are components properly connected?) � Coupling and cohesion (the number of internal relationship within a component compared to the number of relationships to other components) � Efferent and afferent relationship (uses of a component by other components and usages of other component by the given component) � Interfaces (what is the required and provided interface of the given component) Structure Views are used in combination with Code views, Data views, Platform views, UI views and Inventory views. Construction methods: Structure views that correspond to the KDM Structure architectural viewpoint are usually constructed by analyzing architecture models of the given system. The Structure extractor tool uses the knowledge of the architecture models to produce one or mode Structure views as output � As an alternative, structure views can be produced manually using the input from the architect of the system and architecture documentation � Construction of the Structure view is determined by the architectural description of the system � Construction of the Structure views corresponding to a particular architectural description may involve additional information (system-specific or architecture-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 20.1, page 261 Conceptual architecture viewpoint Concerns: � What are the domain terms implemented by the system? � What are the behaviour elements of the system? � What are the business rules implemented by the system? � What are the scenarios supported by the system? Viewpoint language: Conceptual views conform to KDM XMI schema The viewpoint language for the Conceptual architectural viewpoint is defined by the Conceptual package. It includes abstract entitity AbstractConceptualElement, and several concrete entities, such as TermUnit, FactUnit, RuleUnit, Scenario, BehaviorUnit. The viewpoint language for the Conceptual architectural viewpoint also includes ConceptualFlow relationship, which is a subclass of an abstract relationship AbstractConceptualRelationship. Analytic methods The Conceptual architectural viewpoint supports the following main kinds of checking: � Conceptual relationships (what are the relationships between conceptual entities, based on their implementation by the Code and Data entities?) � Scenario flow (what are the control flow relationship between the two scenarios based on the flow between action elements referenced by each scenario) � BehaviorUnit coupling (what are the control flow and data flow relationships between two behaviour units based on the action elements referenced by each behaviour unit) � Business Rule analysis (what is the logic of the business rule based on the action elements referenced by the business rule) Conceptual Views are used in combination with Code views, Data views, Platform views, UI views and Inventory views. Construction methods: � Conceptual views can be produced manually using the input from the information analysis and the architect of the system and architecture documentation � Construction of the Conceptual view is determined by the domain model and the architectural description of the system � Construction of the Conceptual views corresponding to a particular architectural description may involve additional information (system-specific or architecturespecific). This information can be attached to KDM elements using stereotypes, attributes or annotations Section 21.1, page 279 Build architecture viewpoint Concerns: � What are the inputs to the build process? What artifacts are generated during the build process? � What tools are used to perform build steps? � What is the workflow of the build process? � Who are the suppliers of the source artifacts? Viewpoint language Build views conform to KDM XMI schema The viewpoint language for the Build architectural viewpoint is defined by the Build package. It includes abstract entity AbstractBuildElement, a generic entity BuildResource as well as several concrete entities, such as BuildComponent, BuildStep, BuildProduct, BuildDescription, Library. The viewpoint language for the Build architectural viewpoint also includes several build relationships, which is a subclass of an abstract relationship AbstractBuildRelationship. Analytic methods � Supply chain analysis (what are the artifacts that depend on a given supplier) Build Views are used in combination with Inventory views. Construction methods: � Build views that correspond to the KDM Build architectural viewpoint are usually constructed by analyzing build scripts and build configuration files for the given system. This inputs are specific to the build automation framework. The Build extractor tool uses the knowledge of the semantics of the build automation framework to produce one or mode Build views as output � Construction of the Build view is determined by the semantics of the build automation framework, and it based on the mapping from the given build automation framework to KDM; such mapping is specific only to the build automation framework and not to a specific software system � The mapping from a particular build automation framework to KDM may produce additional information (system-specific, or platform-specific, or extractor tool-specific). This information can be attached to KDM elements using stereotypes, attributes or annotations
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13302: Missing definitions for �Engineering view�, �logical view� and �developers view� (rh-11) (kdm-rtf)

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

Related to 11.1         "Engineering view", logical view" and "developers view" should be defined         Views should have definitions USUALLY as viewpoints

Resolution: Remove references to these �views� (they are actually viewpoints, according to ISO 42010), since each KDM model explicitly defines an architecture viewpoint. Engineering view: Editorial changes are provided as part of the resolution to issue 13296 Logical view: Editorial changes are provided as part of the resolution to issue 13296 Developers view: Change sentence Page 113, Ignore the generated primary code, provide a high-fidelity representation to the embedded construct; the embedded construct is the origin and the target of KDM relationships; some details of how the embedded construct is expanded into the primary code may not be recovered from the KDM representation (but in general, the embedded construct provides a better representation, since it is the view that developers have). Into Ignore the generated primary code, provide a high-fidelity representation to the embedded construct; the embedded construct is the origin and the target of KDM relationships; some details of how the embedded construct is expanded into the primary code may not be recovered from the KDM instance (but in general, the embedded construct provides a better choice, since it is the constructs introduced by the developer).
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13303: Align structure package with ISO 42010 (rh-12) (kdm-rtf)

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

Related to 19.1         "The Structure package defines constructs for defining the high level abstraction of the organization of a software system." Some might call this "architecture". If that is intent, the capabilities of this clause should be aligned with those of existing architecture standards such as ISO 42010, which has a rich ontology (and metamodel) of architectural "assets". Users of that standard should be able to model assets using this DIS, but there is no clear connection, and the current Structure package looks inadequate to conduct this modeling.         Align with ISO 42010, or explain why it is excluded from software assets of interest.

Resolution: Change paragraph page 255, section 19.1: Structure package defines constructs for defining the high level abstraction of the organization of a software system. The Structure model constructs specify how the software�s divisions and subdivisions down to the modules defined in the Code Package. The form of the system may be presented as a single form or a set of layers components, subsystems, or packages. The reach of this representation extends from a uniform architecture to entire family of modulesharing subsystems. The Structure model is a collection of StructuralElement instances. Packages are the leaf elements of the Structure model, representing a division of a system�s Code Modules into discrete, non-overlapping parts. An undifferentiated architecture is represented by a single Package. StructuralGroup recursively gathers StructuralElements to portray various architectural divisions. The Software System subclass provides a gathering point for all the system�s packages directly or indirectly through other Structure elements. The packages may be further separated into Subsystems, Layers, and Components, or Architecture Views. Into Structure package defines meta-model elements that represent architectural components of existing software systems, such as subsystems, layers, packages, etc. and define traceability of these elements to other KDM facts for the same system. Change sentence page 255, section 19.1: Structure package defines constructs for defining the high level abstraction of the organization of a software system. The Structure model constructs specify how the software�s divisions and subdivisions down to the modules defined in the Code Package. Into Structure package defines meta-model elements that represent architectural components of existing software systems, such as subsystems, layers, packages, etc. and define traceability of these elements to other KDM facts for the same system. Structure model defines an architectural viewpoint. The architectural views based on the viewpoint defined by the Structure model represent how the structural elements of the software system are related to the modules defined in the Code views that correspond to the Code architectural viewpoint defined by the Code model. The architectural viewpoint is defined as follows. This text will be followed by the definition of the Structural architecture viewpoint from the resolution to issue 13301. Add the following paragraphs to the end of section 19.1 The organization of the system may be presented as a single Structure view or a set of multiple Structure view showing layers, components, subsystems, or packages. The reach of this representation extends from a uniform architecture to entire family of module-sharing subsystems. The Structure model owns a collection of StructuralElement instances. Packages are the leaf elements of the Structure model, representing a division of a system�s Code Modules into discrete, non-overlapping parts. An undifferentiated architecture is represented by a single Package. StructuralGroup recursively gathers StructuralElements to represent various architectural divisions. The Software System subclass provides a gathering point for all the system�s packages directly or indirectly through other Structure elements. The packages may be further grouped into Subsystems, Layers, and Components, or Architecture Views.
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Issue 13304: Align �ArchitectureView element with ISO (rh-13) (kdm-rtf)

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

Related to 19.3.8         "The ArchitectureView class represents a logical packaging of the architectural artifacts related to a particular view of a software system."    The terminology herein should be aligned to use terms from ISO/IEC 42010:2007, as we can see substantial alignment.     In addition to alignment on terms, it would be A Good Thing for the developers of this document to look at the draft 42010:20xx, to understand the emerging requirements on Architecture Frameworks. DIS 19506 could well be positioned as an Architecture Framework that conforms to the requirements in the revision of ISO/IEC 42010.         ArchitectureView class should have attributes with those in the 42010 conceptual model: a corresponding Architectural Viewpoint (which also must be an ArchitectureElement in the present DIS, see Clause 5.3); Identifier, Purpose; and its contained Architecturl Models (see Clause 5.4).

Resolution: Page 258: Change 19.3.8 ArchitectureView Class The ArchitectureView class represents a logical packaging of the architectural artifacts related to a particular view of a software system. Superclass StructureGroup Semantics To: 19.3.8 ArchitectureView Class The ArchitectureView class represents an arbitrary architecture view, as defined by ISO 42010 Architectural View. The KDM ArchitectureView class is a collection of KDM entities that correspond to a particular architectural view of a software system. To conform to the ISO 42010 requirements for architectural description, the creator of the KDM model shall further document the viewpoint used (as a a stereotype to the ArchitectureView class, attributes or annotations). Superclass StructureGroup Semantics
Revised Text:
Actions taken:
January 16, 2009: received issue
October 19, 2009: closed issue

Issue 13323: Build Package in Abstract Layer (page 280-281). (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 would like to report another inconsistency detected in the KDM specification v1.0 owned ADM effort.  In this case is the Build Package in Abstract Layer (page 280-281). In BuildModel Class Diagram (in page 280) there is an element so-called �Supplier�. However, in page 281 this element is not depict, but a new element so-called �Origin� is depict. I think that both elements are the same element.

Resolution: Change text of section 21.3.4 page 281 from � 21.3.4 Origin Class The Origin class models producers of the 3rd party software components as they contribute to the build process.� Into � 21.3.4 Supplier Class The Supplier class models producers of the 3rd party software components as they contribute to the build process.�
Revised Text:
Actions taken:
January 22, 2009: received issue
October 19, 2009: closed issue

Issue 13396: case of a property name duplication (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Revision
Severity: Significant
Summary:

Nikolai Mansourov sent a zip file containing the baseline files for KDM 1.2. I extracted the KDM_1.1.cmof file for processing with the CMOF Addin for Rose, since Adaptive incorporates the KDM 1.1.1 model and will presumably wish to support KDM 1.2. I found a case of a property name duplication, which renders it impossible to use the model without renaming one of the offending properties. The properties in question were both named "aggregatedRelationship" in the KDMEntity class. Nikolai has since supplied a provisional CMOF file with this problem corrected. This issue is filed for tracking purposes so that the provisional change is in the final KDM 1.2 file.

Resolution: Change the algorithm of mechanical production of the CMOF definition of KDM, by providing special treatment for named associations. For example, the associations between the AggregatedRelationship class and KDMEntity class should use the named association ends to produce the following (without duplication): <ownedMember xmi:id='C_9427293' xmi:type='cmof:Class' name='AggregatedRelationship' superClass='C_12698353' isAbstract='false' > <ownedAttribute xmi:id='P_G_174' xmi:type='cmof:Property' type='C_12313807' name='from' lower='1' upper='1' isComposite='false' association='A_28697616' /> <ownedAttribute xmi:id='P_G_176' xmi:type='cmof:Property' type='C_12313807' name='to' lower='1' upper='1' isComposite='false' association='A_499276' /> <ownedAttribute xmi:id='P_G_178' xmi:type='cmof:Property' type='C_27407718' name='relation' lower='0' upper='*' isComposite='false' association='A_2731614' /> <ownedAttribute xmi:id='P_G_181' xmi:type='cmof:Property' type='C_8395033' name='model' lower='0' upper='1' isComposite='false' association='A_7776694' /> <ownedAttribute xmi:id='P_27247421' xmi:type='cmof:Property' name='density' type='D_25324380' /> </ownedMember> <ownedMember xmi:id='A_499276' xmi:type='cmof:Association' name='Destination' memberEnd='P_G_176 P_G_177' /> Similarly for the segments association (see duplicate issue 13398): <ownedMember xmi:id='C_6068917' xmi:type='cmof:Class' name='Segment' superClass='C_29405700' isAbstract='false' > <ownedAttribute xmi:id='P_G_322' xmi:type='cmof:Property' type='C_6068917' name='segment' lower='0' upper='*' isComposite='true' association='A_22905698' /> <ownedAttribute xmi:id='P_G_323' xmi:type='cmof:Property' type='C_6068917' name='owner' lower='0' upper='1' isComposite='false' association='A_22905698' /> <ownedAttribute xmi:id='P_G_324' xmi:type='cmof:Property' type='C_8395033' name='model' lower='0' upper='*' isComposite='true' association='A_28370794' /> </ownedMember> <ownedMember xmi:id='A_22905698' xmi:type='cmof:Association' name='Segments' memberEnd='P_G_322 P_G_323' /> This change is performed automatically in the process of converting the UML Rose diagrams into CMOF. The unique ids of the cmof elements may change during the conversion. Additional change in support of this resolution, �to� and �from� roles of the KDMRelationship should not be declared as derived union, or derived (Core package). They are always redefined in subclasses. This is similar to the aggregated relations pattern in the AggregatedRelationship class. Change diagram 9.2, page 18 into the following: <<<DIAGRAM on PAGE 68 of ptc/2009-06-02
Revised Text:
Actions taken:
January 30, 2009: received issue
October 19, 2009: closed issue

Issue 13397: upper bound of the container end of a composition shown as unbounded (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:

In the base zip file for KDM 1.2, I imported the KDM_1.1.cmof file into the Rose CMOF addin to verify it, since Adaptive supports the current version of KDM and will probably support 1.2. I found an error where the upper bound of the container end of a composition was shown as unbounded (the A_group_groupedElement association on the KDMEntity class). When I communicated this to Nikolai, he indicated that the problem was that this relation should not be composite. He sent a provisional CMOF file that changed the nature of the association that I was able to import successfully. This issue is filed to track this problem and insure that the change that was made appears in the final CMOF file.

Resolution: Change the algorithm of mechanical production of the CMOF definition of KDM, by providing special treatment for KDM group associations. This correctly produces isDerived=true for ownedElement, and isDerived=false for groupedElement. <ownedAttribute xmi:id='P_O_9252407' xmi:type='cmof:Property' isOrdered='false' isDerivedUnion='true' isDerived='true' isReadOnly='true' type='C_12313807' name='ownedElement' lower='0' upper='*' isComposite='true' association='A_1' /> <ownedAttribute xmi:id='P_D_9252407' xmi:type='cmof:Property' isDerivedUnion='true' isDerived='true' isReadOnly='true' type='C_12313807' name='ownerProperty' lower='0' upper='1' isComposite='false' association='A_1' /> <ownedAttribute xmi:id='P_O_11837032' xmi:type='cmof:Property' isOrdered='false' isDerivedUnion='true' isDerived='true' isReadOnly='true' type='C_12313807' name='groupedElement' lower='0' upper='*' isComposite='false' association='A_36' /> <ownedAttribute xmi:id='P_D_11837032' xmi:type='cmof:Property' isDerivedUnion='true' isDerived='true' isReadOnly='true' type='C_12313807' name='groupProperty' lower='0' upper='*' isComposite='false' association='A_36' /> Also in order to avoid duplication derived union properties �owner�, �group� and �model� are automatically renamed to ownerProperty, groupProperty and modelProperty respectively. This change is performed automatically in the process of converting the UML Rose diagrams into CMOF. The unique ids of the cmof elements may change during the conversion.
Revised Text:
Actions taken:
January 30, 2009: received issue
October 19, 2009: closed issue

Discussion:

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

Issue 13398: "Segments" assocation on the kdm::Segment class (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:

In the base zip file for KDM 1.2, I imported the KDM_1.1.cmof file into the Rose CMOF addin to verify it, since Adaptive supports the current version of KDM and will probably support 1.2. I found an error where there was an association from a class to itself that had the same role name on both ends. This was the "Segments" assocation on the kdm::Segment class. When I communicated this problem to Nikolai, he sent a provisional CMOF file that corrected the problem. This issue is filed to track this problem and insure that the change that was made appears in the final CMOF file.

Resolution:
Revised Text:
Actions taken:
January 30, 2009: received issue
October 19, 2009: closed issue

Discussion:

This is caused by the same issue as 13323, see resolution there.  Disposition: Duplicate

Issue 13399: associations with duplicated names in the same package (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:

In the base zip file for KDM 1.2, I imported the KDM_1.1.cmof file into the Rose CMOF addin to verify it, since Adaptive supports the current version of KDM and will probably support 1.2. I found several cases where there are associations with duplicated names in the same package; for example, the association "A_owner_codeElement" appears 7 times in the KDM::code package. When I communicated the complete list of duplicated associations to Nikolai, he sent a provisional CMOF file that corrected the problem. This issue is filed to track this problem and insure that the change that was made appears in the final CMOF file.

Resolution: The full list of 16 associations with duplicate names from Gene Mutschler on 26-02- 2009: Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_itemUnit. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::code: A_owner_codeElement. Duplicate association in package: Logical View::KDM::data: A_owner_contentElement. Duplicate association in package: Logical View::KDM::data: A_owner_contentElement. Duplicate association in package: Logical View::KDM::data: A_group_implementation. Duplicate association in package: Logical View::KDM::data: A_owner_dataElement. Duplicate association in package: Logical View::KDM::event: A_owner_eventElement. Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement. Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement. Duplicate association in package: Logical View::KDM::ui: A_owner_uiElement. To disambiguate the association names, the rule for producing CMOF association should be changed into "A_" <class-name1> "_" <association-end-name2> When these rules are applied, unambiguous association names are produced. For example, for the association owner-code element owned by Module, the following CMOF is produced: <ownedMember xmi:id='A_58' xmi:type='cmof:Association' memberEnd='P_O_29311055 P_D_29311055' name='A_Module_codeElement' general='A_1'> <ownedEnd xmi:id='P_D_29311055' xmi:type='cmof:Property' subsettedProperty='P_D_9252407' type='C_18297765' name='owner' lower='0' upper='1' isComposite='false' association='A_58' /> </ownedMember> <ownedMember xmi:id='C_18297765' xmi:type='cmof:Class' name='Module' superClass='C_8898472' isAbstract='false' > <ownedAttribute xmi:id='P_O_29311055' xmi:type='cmof:Property' isOrdered='true' subsettedProperty='P_O_9252407' type='C_13966896' name='codeElement' lower='0' upper='*' isComposite='true' association='A_58' /> </ownedMember> This change is performed automatically in the process of converting the UML Rose diagrams into CMOF. The unique ids of the cmof elements may change during the conversion. Add new section before section 6.3 Acknowledgements, page 7 that explicitly defines the naming conventions for mechanical production of CMOF definition of KDM from UML diagrams: � 6.2.1. Diagram format Metamodel diagrams in this specification are used to mechanically produce the MOF definition of KDM, and the corresponding KDM XMI schema. The following conventions are adopted for all metamodel diagrams throughout this specification: � An association with one end marked by a navigability arrow means that: o the association is navigable in the direction of that end, o the marked association end is owned by the classifier, and o the opposite (unmarked) association end is owned by the association. � An association with neither end marked by navigability arrows means that: o the association is navigable in both directions, o each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association). .. Additionally, properties �owner�, �group� and �model� are automatically renamed to ownerProperty, groupProperty and modelProperty respectively. � Association specialization and redefinition are indicated by appropriate constraints situated in the proximity of the association ends to which they apply. Thus: o The constraint {subsets endA} means that the association end to which this constraint is applied is a specialization of association end endA that is part of the association being specialized. o A constraint {redefines endA} means that the association end to which this constraint is applied redefines the association end endA that is part of the association being specialized. � Derived union is indicated by placing constraint {union} in the proximity of the association end to which it applies. The corresponding association endpoint is marked as derived and read only. � If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. In addition, if the name of the class to which the end is attached starts has a meaningful prefix of uppercase letters, for example XMLxxxx, KDMxxx, UIxxxx, the entire uppercase prefix is modified to become lowercase. For example, the above words become xmlxxxx, kdmxxx, uixxxx. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints � although there may be needed for other purposes, such as MOF language bindings that use the metamodel.) o Unlabeled association ends attached to the class KDM Entity which correspond to KDM Relationships are additionally prefixed with �in� or �out� according to the direction of the relationship. The corresponding properties at the KDM Relationship class side are "to" and "from". For example, association ends for the ActionElement class corresponding to the associations to ControlFlow class are named �inControlFlow� (the counterpart of the �to� endpoint from the ControlFlow side) and �outControlFlow� (the counterpart of the �from� endpoint from the ControlFlow side) � Associations that are not explicitly named, are given names that are constructed according to the following production rule: "A_" <class-name1> "_" <association-end-name2> where <class-name1> is the name of the class that owns the first association end and <association-end-name2> is the name of the second association end �
Revised Text:
Actions taken:
January 30, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13822: This document doesn't define the common interchange format (JP-1). (kdm-rtf)

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

Related to clause 1.                       Suggested resolution:    Remove the following statement from scope.    "The primary purpose of this meta-model is to provide a common interchange format that will allow interoperability between existing modernization and software assurance tools, services, and their respective intermediate representations."

Resolution: Section 1 Scope: change �to provide� into �to enable�: "The primary purpose of this meta-model is to enable a common interchange format that will allow interoperability between existing modernization and software assurance tools, services, and their respective intermediate representations. In Section 2. Conformance add the following: KDM is defined via Meta-Object Facility (MOF). KDM defines the interchange format via the XML Metadata Interchange (XMI) by applying the standard MOF to XMI mapping to the KDM MOF model. The interchange format, defined by KDM is called the KDM XMI schema. The KDM XMI schema is provided as the normative part of this specification." Also make the following editorial clarifications. EDITORIAL COMMENT: these edits are made to the conformance paragraph change: The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate cooperation between tool suppliers by allowing integration information about a complex enterprise application from multiple sources, as the complexity of modern enterprise applications involves multiple platform technologies and programming languages. Into The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate cooperation between tool suppliers to integrate multiple facts about a complex enterprise application from, as the complexity of modern enterprise applications involves multiple platform technologies and programming languages. Remove sentence: Consequently, the definition of compliance for KDM requires a balance to be drawn between modularity and ease of interchange
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Issue 13823: Interchange format in compliance statement (JP-2) (kdm-rtf)

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

Related to clause: 2    The compliance of this standard assume common interchange format between tools. But this standard doesn't define it.  Thus remove it.          Suggested resolution: Remove the clause "2 compliance".

Resolution:
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

KDM defines an interchange format, as clarified in the resolution to 13822. This interchange  format is specified as KDM XMI schema, which is available as a normative part of the  specification. Compliance to KDM is defined in terms of supporting sub-packages of KDM XMI  schema, corresponding to the KDM domains. Clause 2 defines various compliance statements for  KDM as is essential to the specification.  Disposition: Closed

Issue 13824: Compliance levels (JP-3) (kdm-rtf)

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

Related to clause 2.2    "There are two KDM compliance levels:" But there are three level:L0, L1, L2.     Suggested resolution:  "There are Three KDM compliance levels:"

Resolution: Section 2.2 Compliance levels: change "There are two KDM compliance levels:" into "There are three KDM compliance levels:"
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Issue 13825: Normative references (JP-4) (kdm-rtf)

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

Related to clause:  3     The following standard must be refered.    - XMI ISO/IEC19503    - MOF ISO/IEC19502    - ISO/IEC11404    - SBVR         Suggested resolution:    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)      Semantics of Business Vocabulary and Business Rules (SBVR)  available at https://www.omg.org/spec/SBVR/1.0/PDF

Resolution: Change list of references in section 3 �Normative references� into: � 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) Disposition: Resolved
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 13826: The format of normative references doesn't meet ISO format. (JP-5) (kdm-rtf)

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

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

Resolution: Change format of the normative references and update versions Change format of the normative references and update versions
Revised Text: Section 3 Normative references, page 5. replace list of references with: *ISO/IEC 19505-1:2012 ?Information technology - Object Management Group Unified Modeling Language (OMG UML), Infrastructure? (OMG Unified Modeling Language (OMG UML), Infrastructure http:// www.omg.org/spec/UML/2.4.1/Infrastructure) [1]https://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/ *ISO/IEC 19508:2014, ?Information technology - Object Management Group Meta Object Facility (MOF) Core? (OMG Meta Object Facility (MOF) Specification (Version 2.4.2) - [2]https://www.omg.org/spec/MOF/2.4.2) *ISO/IEC 19509:2014, ?Information technology - Object Management Group XML Metadata Interchange (XMI)? (XML Metadata Interchange - [3]https://www.omg.org/spec/XMI/2.4.2) *ISO/IEC 11404:2007, "Information technology ? General-Purpose Datatypes (GPD)" *Semantics of Business Vocabularies and Business Rules (SBVR) version 1.2 - [4]https://www.omg.org/spec/SBVR/1.2 ---------------------------------------------------------------------------------------- [1] https://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/ [2] https://www.omg.org/spec/MOF/2.4.2 [3] https://www.omg.org/spec/XMI/2.4.2 [4] https://www.omg.org/spec/SBVR/1.2
Actions taken:
March 24, 2009: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

ISO/IEC formatting template to be applied during the production of the ISO/IEC version  Disposition: Deferred

Issue 13827: There is no terms ,definitions and symbols. (JP-6) (kdm-rtf)

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

Related to clause:  4.5    Suggested resolution: Remove the clause "4 Terms and definitions" and "5 Symbols".

Resolution:
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

This has been already requested by IEEE issue 13294. Definitions of the key terms will be added.  Section 5 Symbols is required by the OMG template. It can be removed during the production of  the ISO/IEC document, based on the ISO/IEC template.  Disposition: Duplicate

Issue 13828: Relationships between packages (JP-7) (kdm-rtf)

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

Existing software based systems have the relationship among packages.  But this standard doesn't mention it precisely.  (Conceptually, this shows package structure.)    Suggested resolution: Describe it using Package diagram.

Resolution:
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

The current picture shows layers of KDM packages, this illustration is part of the non-normative  introductory material and does not require precision. Dependencies between different layers are  implicit.  Disposition: Closed

Issue 13829: ISO standard documents are described with "shall", "should" and "may" (JP-8) (kdm-rtf)

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

Suggested resolution: Define this standard with "shall", "should" and "may".

Resolution: Modify table 2.1 Compliance statement by adding phrase �Compliant tool shall: in each cell and adding bullets to each requirement. Make the following editorial changes: L0 Import-Analysis: Change: support specified mapping between KDM and existing model in the tool; into implement mapping between KDM and existing internal representation of the tool; Add word �support�: extend operations of existing tool to support traceability to the physical artifacts of the application from Source package. Add word �demonstrate� in front to �L0 compliance� In semantic sections � change �it is implementer�s responsibility� to �the implementer shall� (below we only show the new version of the sentence with the changed phrase underlined): Source package: Page 45 The implementer shall arrange inventory elements into one or more inventory models. KDM import tools shall not make any assumptions about the organization of inventory items into inventory models. Page 47: The implementer shall provide a mapping from concrete types of the physical artifacts involved in the engineering of the existing software system into concrete subclasses of the InventoryItem. The implementer shall map each artifact of the existing software system to some instance of KDM InventoryItem. Page 51: The implementer shall capture certain aspects knowledge of the engineering process in the form of �DependsOn� relations between inventory items. Page 53: The implementer shall provide adequate traceability links. Code package The implementer shall arrange code elements into one or more code models. Page 65 The implementer shall select an appropriate subclass of the Module element. Page 66 The implementer shall add such files to the InventoryModel. Page 110 Change �The implementer will have the choice to either� into The implementer shall either: Page 112 Change �This is up to the implementer� into The implementer may provide additional information using stereotypes. Page 113 Change �KDM does not restrict implementers whether to clone the included code elements or to reuse them and keep a single copy in the SharedUnit. However, many KDM implementations will usually clone the elements of the SharedUnit. � into The implementer may either clone the included code elements or to reuse them and keep a single copy in the SharedUnit. The recommended approach is to clone the elements of the SharedUnit. Page 114 The implementer shall select a particular strategy to represent macro units Page 116 The implementer shall identify and represent associations between MacroUnits, as well as a MacroDirective and the corresponding MacroUnit according to the semantics of the preprocessor. Page 119 The implementer shall identify and represent include relationships according to the semantics of the particular preprocessor. Page 120 The implementer shall identify and represent the variants and associations between the �generated� code and the corresponding conditional directive according to the semantics of the preprocessor. Page 121 The implementer shall identify and represent redefinitions of macro units according to the semantics of the particular preprocessor. Page 123 The implementer shall make an adequate decision on how to associate line comments with the surrounding elements in the source code. Page 127 The implementer shall identify and represent import directives and their targets according to the semantics of the programming language of the existing software system. Action package Page 131 The implementer shall select the granularity of the action elements. Page 131 The implementer shall map programming language statements and other descriptions of behavior into KDM ActionElements. Page 134 The implementer shall map control flow mechanisms of the given programming language into ControlFlow meta-elements. The implementer shall adequately represent the control flows of the existing system by a set of action elements and ControlFlow relationships between them. Page 150 The implementer shall identify and represent these associations according to the semantics of the programming language of the existing software system. Micro actions Page 154; constraint 1 �should� change into �shall� Platform package Page 165 The implementer shall arrange platform elements into one or more platform models. Page 168 The implementer shall identify runtime resources used by the existing software system according to the semantics of the platform used by the existing system, resource configuration files, and other appropriate sources of information. Page 175 The implementer shall correctly associate the platform resource with the corresponding logical definition of this resource (usually a Signature, an Interface, or a Package). UI package Page 184 The implementer shall arrange user-interface elements into one or more UIModel containers. Page 185 The implementer shall map specific user interface element types determined by the particular user-interface system of the existing software system, into concrete subclasses of the AbstractUIElement. The implementer shall map each user interface element into some instance of the AbstractUIElement. Implementation elements are one or more ComputationalObjects or ActionElements from some CodeModel that are represented by the current UI element. �Abstraction� actions may be used to represent precise semantics of the UI Element. Page 185 The implementer shall map specific user interface association types determined by the particular userinterface system of the existing software system, into concrete subclasses of the AbstractUIRelationship. The implementer shall map each user interface association into some instance of the AbstactUIRelationship. Event package Page 196 The implementer shall arrange event elements into one or more event models. Data package Page 208 The implementer shall arrange the instances of the data elements into one or more DataModels. Build package Page 285 The implementer shall capture the input build elements for a certain build step in the form of �Consumes� relation. Page 286 The implementer shall capture the output build elements for a certain build step in the form of �Produces� relation. Page 286 The implementer shall capture the required Tool elements for a certain build step in the form of �SupportedBy� relation. Page 287 The implementer shall capture the origin of build elements in the form of �SuppliedBy� relation. Page 287 The implementer shall capture the description of a certain build step in the form of �DescribedBy� relation to some BuildDescription element.
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Issue 13830: Acknowledgements are not specification. (JP-9) (kdm-rtf)

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

Related to clause: 6.3    Suggested resolution: Remove subclause 6.3.

Resolution: According to the guidance from the OMG-ISO Liaison: The acknowledgments should not be in a normative part of an ISO standard. You could remove them or put them in an informative annex
Revised Text: Remove acknowledgement section 6.3, page 11
Actions taken:
March 24, 2009: received issue
April 27, 2011: closed issue

Discussion:

It is custom for OMG specifications to contain acknowledgements. ISO/IEC formatting  template to be applied during the production of the ISO/IEC version.  Disposition: Deferred

Issue 13831: Some class constraints are numbered, but others are not. Unify them. (JP-10) (kdm-rtf)

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

Suggested resolution: All class constraints must be numbered.

Resolution: Remove all empty Constraints sections Add numbers to constraints in section 9.4.2, page 20 Add numbers to constraints in section 10.6.2, page 39 Add numbers to constraints in section 11.6.1, page 52 Add numbers to constraints in section 11.6.2, page 54 Add numbers to constraints in section 13.5.2, page 134 Add numbers to constraints in section 13.5.4, page 135 Add numbers to constraints in section 13.5.5, page 136 Add numbers to constraints in section 13.5.6, page 137 Add numbers to constraints in section 16.5.1, page 187 Add numbers to constraints in section 16.5.2, page 187
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Issue 13832: The title of ISO/IEC 11401 is incorrect. (JP-11) (kdm-rtf)

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

Related to clause: 7 last paragraph    Suggested resolution:    ISO/IEC 11404:2007  Information technology -- General-Purpose Datatypes (GPD)

Resolution: Make the following changes to the text: Page 10 Change �KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR� into KDM is aligned with ISO/IEC 11404 General-Purpose Datatypes and OMG Semantics of Business Vocabularies and Business Rules (SBVR) Page 57 Change �Data representation of KDM is aligned with ISO/IEC 11404 (Language- Independent datatypes) standard.� Into Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard. Pages 76, 77, 79, 80, 81, 82, 83, 84, 85, 87, 88, 89, 90, 91, 93, 95 Change ISO/IEC 11404:1996 into ISO/IEC 11404 Page 77 Change �Data representation of KDM is aligned with ISO/IEC 11404 (Language-Independent datatypes) standard.� Into Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard.
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

Follow, and consolidate in the normative references

Issue 13833: Annex must be either �normative� or �informative�. Specify it. (JP-12) (kdm-rtf)

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

Related to clause: Annex A    Suggested resolution: Annex A may be informative.

Resolution: Annex A is normative. Add the word (normative) to section title Annex A � Semantics of the Micro KDM Action Elements (normative). Add word normative to the first sentence of the section: This normative annex defines..
Revised Text:
Actions taken:
March 24, 2009: received issue
October 19, 2009: closed issue

Discussion:

Issue 14106: Change relation endpoint for Audit relation (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text: page 28 Modify Figure 10.2 to indicate that the owner of the Audit is ModelElement. page 38 10.4.1 Audit Class replace KDM models with "KDM model elements. The Audit element allows associating provenance, argument as well as other metadata with arbitrary KDM model elements." replace "Each ModelElement element can have zero or more Audit instances associated with it. " with Each ModelElement element can have zero or more Audit instances associated with it. replace "Contains the description of the Framework elements" with "Contains the description related to the Audit of the element (the Audit message)" page 39 rename into 10.4.2 ModelElement (additional properties) replace "Audit elements can be owned by any subclass of the KDMFramework element." with Audit elements can be owned by any subclass of the ModelElement element. Associations audit:Audit[0..*] The list of Audit element instances for the given instance of ModelElement, including segment or model.
Actions taken:
July 27, 2009: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

deferred to next RTF

Issue 14107: Change specification to allow stereotyping of Audit elements (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text: page 23 replace four class diagrams with "five class diagrams" add bullet "Elements" page 23 add section before 9.3 titles Elements Class Diagram The Elements class diagram describes the top level abstract classes that identify the main categories of elements in KDM. The classes and associations of the Elements class diagram are shown in Figure 9.1 add Figure 9.1 move section 9.3.1 Element Class (abstract) from page 24 to new section 9.3.1 add section 9.3.3 AnnotatableElement (abstract) add section 9.3.4. AnnotationElement (abstract) add section 9.3.5 ExtendableElement (abstract) add section 9.3.6 ExtensionElement (abstract) move section 9.3.2 ModelElement from page 24 to new section 9.3 as 9.3.7 page 24, Figure 9.1 (old - will be renumbered because of the edits above) remove Element class and inheritance to ModelElement. (This is introduced at new Elements class diagram) page 38, Figure 10.2 change superclass of Audit from Element into ExtendableElement page 38 10.4.1 replace Element with ExtendableElement page 39 replace "virtual" with "extended" (3 counts) page 40 replace "wildcard" with "viewpoint-specific" page 40, Figure 10.3 change superclass of ExtensionFamily, Stereotype, TagDefinition from Element into ExtensionElement page 40, Figure 10.3 change owner of ExtendedValue from ModelElement into ExtenadableElement. page 40 replace "(classifying) model elements" with "(classifying) certain elements" page 40 replace "virtual meta-model constructs" with "extended meta-model constructs" page 40 replace "These model elements" with "These elements" page 40 replace "non-stereotyped model elements" with "non-stereotyped elements" page 40 replace "apply to model elements" with "apply to these elements" page 40 replace "between two model elements" with "between two elements" page 40 remove "In the meta-model the Stereotype is a subclass of Element." page 40 replace "named model element" with "named element" page 40 replace "apply to all ModelElements" with "apply to each ExtendableElement" page 41 replace "base class" with "base element" page 41 replace Element with ExtensionElement page 41 replace "model element" with "base element" page 41 constraints, replace "model element" with "an ExtendableElement" page 41 constraints, replace ModelElement" with "an ExtendableElement" page 41 constraints, replace baseClass with "value of the type attribute of the Stereotype" page 41 constraints replace "Type" with "type" page 41 constraints replace "KDM meta-elements. Names of the core datatypes (?Boolean,? ?String,? ?Integer?)" with "subclasses of ExtendableElement and the names of the core datatypes" page 41 constraints replace "other KDM meta-elements" with "the subclasses of ExtendableElement" page 43 10.5.2 replace Element with ExtensionElement page 43 replace "meta-element" with "element" page 43 10.5.3 replace Element with ExtensionElement page 44 replace 10.5.4 ModelElement (additional properties) with 10.5.4. ExtendableElement (additional properties) page 44 replace TaggedValue with ExtendedValue page 44 repalce "The set of tagged values" with "The set of extended values" page 44, 10.5.4 constraints, replace ModelElement with ExtendableElement (5 counts) replace "Conformance" with "Full validation" replace "validated dynamically" with "performed dynamically" replace "since lightweighted extensions are" with "since the purpose and the semantics of an extension is" page 45 Figure 10.4 change superclass of ExtendedValue into ExtensionElement page 45, Figure 10.4 change endpoint of reference association into ExtendableElement page 45, 10.6.1 replace Element with ExtensionElement page 45, 10.6.1 replace "virtual" with "additional" page 45 replace "defines the virtual" with "defines the extended" page 45 replace "Virtual attributes are" with "ExtendedValue elements that correspond to a Stereotype shall be" page 45 replace "every time a new virtual" with "every time a new extended" page 46 remove "In the meta-model, TaggedValue is a subclass of Element" page 46 semantics, replace "virtual" with extended page 46 semantics replace "type" with "datatype" page 46 remove "In the meta-model, TaggedRef is a subclass of ExtendedValue." page 47 replace virtual with extended (3 counts) page 47, Figure 10.5 change superclass of Attribute and Annotation from Element into annotationElement page 47, Figure 10.5 change owner of Annotation and Attribute from Element into AnnotatableElement page 48 remove "In the meta-model, TaggedValue is a subclass of Element." page 48 replace Element with AnnotationElement page 48 remove "by analysis, etc." page 48 replace "virtual" with "extended" page 48 remove "The meta-model Annotation class is a subclass of Element. " page 48, 10.7.2 replace Element with AnnotationElement page 49 rename 10.7.3 Element (additional properties) into 10.7.3 AnnotatableElement (additional properties) page 54 replace virtual with extended (2 counts) page 60, Figure 11.4 change superclass of SourceRef and SourceRegion from Element into AnnotatableElement page 60, 11.6.1 change Element into AnnotatableElement page 61, 11.6.2 change Element into AnnotatableElement page 62 replace wildcard into "viewpoint-specific" page 63 replace virtual into "extended" (3 counts) page 64 replace virtual into "extended" page 73 replace virtual into "extended" (2 counts) page 78 replace virtual into "extended" (1 counts) page 88 replace virtual into "extended" (1 counts) page 136 replace wildcard into "viewpoint-specific" page 136 replace virtual into "extended" (2 counts) page 137 replace virtual into "extended" (2 counts) page 143 replace virtual into "extended" (1 counts) page 160 replace wildcard into "viewpoint-specific" page 161 replace virtual into "extended" (2 counts) page 191 replace wildcard into "viewpoint-specific" page 192 replace virtual into "extended" (3 counts) page 193 replace virtual into "extended" (1 counts) page 205 replace wildcard into "viewpoint-specific" page 206 replace virtual into "extended" (3 counts) page 207 replace virtual into "extended" (1 counts) page 218 replace wildcard into "viewpoint-specific" page 218 replace virtual into "extended" (1 counts) page 219 replace virtual into "extended" (3 counts) page 226 replace virtual into "extended" (1 counts) page 227 replace "a new virtual" into "a new extended" (1 counts) page 227 replace "represent a virtual" into "represent an additional" (1 counts) page 228 remove "a virtual action element that represents the" page 265 replace wildcard into "viewpoint-specific" page 265 replace virtual into "extended" (3 counts) page 267 replace virtual into "extended" (1 counts) page 273 replace wildcard into "viewpoint-specific" page 274 replace virtual into "extended" (3 counts) page 275 replace virtual into "extended" (1 counts) page 294 replace wildcard into "viewpoint-specific" page 294 replace virtual into "extended" (1 counts) page 295 replace virtual into "extended" (3 counts) page 307 replace wildcard into "viewpoint-specific" page 307 replace virtual into "extended" (1 counts) page 308 replace virtual into "extended" (3 counts)
Actions taken:
July 27, 2009: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 14108: Wrong class mentioned (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

In 10.5.1, Stereotype class, it says that: �In the meta-model the Stereotype is a subclass of ModelElement.�    This should read as: �In the meta-model the Stereotype is a subclass of Element.�

Resolution: 10.5.1. replace �In the meta-model the Stereotype is a subclass of ModelElement� with �In the meta-model the Stereotype is a subclass of Element�
Revised Text:
Actions taken:
July 27, 2009: received issue
April 27, 2011: closed issue

Issue 14109: Small typo at 19.3.8 (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

Small typo at 19.3.8         �attrbiutes� instead of attributes

Resolution: Page 258, 19.3.8 replace �attrbuites� with �attributes�
Revised Text:
Actions taken:
July 27, 2009: received issue
April 27, 2011: closed issue

Discussion:

Issue 14170: Clarify the meaning of BinaryFile (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text:
Actions taken:
July 31, 2009: received issue
March 29, 2016: Duplicate or Merged
July 12, 2016: closed issue

Issue 14171: Standardize naming of InventoryItem children (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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 [1]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" ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/KDM14-131
Revised Text: page 51 viewpoint language: replace BinaryFile, Image with ObjectFile, ImageFile page 51 viewpoint language: replace DependsOn with TraceableTo and DependsOn page 53 replace "In addition, the InventoryModel" with "The InventoryModel" page 53 replace "concrete KDM entity for each artifact, such a SourceFile, an Image, a ResourceDescription, a Configuration description, a BinaryFile, and an ExecutableFile" with "meta-model elements for several important categories of artifacts according to their functional role in software systems. Software artifacts are local or network resources that are identifiable by URI references." page 53, figure 11.1 rename BinaryFile to LinkableFile add subclasses ObjectFile, LibraryFile to BinaryFile rename Configuration into ConfigFile rename Image into ImageFile add Document add Model add AudioFile add DataFile add WebService remove ResourceDescription (can't distinguish from ConfigFile) Add attribute format:String to InventoryItem page 54 11.3.2 add attribute source:SourceRef[0..*] Link to the physical artifact of the inventory element page 55, 11.3.4 add attribute format:String Optional description of the format of the InventoryItem add semantics: format attribute describes the organization of the InventoryItem. For SourceFile the value of format attribute is assumed "text", and the structure is defined by the language attribute. Examples of format for various subclasses of InventoryItem are: "xml", "html", "json", "csv", "text", "ms word", "coff", "java class", "jpeg","mp3","css" page 55 11.3.5 add to semantics of SourceFile: The SourceFile element represents source files that determine the structure and the behavior of software systems. A source file usually has plain text format. The logical organization of a source file is usually determined by a certain language, such a a programming language, a data definition language, etc. KDM models outside of the Infrastructure layer provide viewpoint languages to describe the common elements of software systems and provide references to the corresponding source files. page 56 add section titled Model Class Model element represents various model artifacts that are related to the software system. Superclass InventoryItem Semantics Model element represents various model artifacts that are related to the software system. The format of a document can be plain text, structured text, such as xml, or one of the many binary formats. A Model element complements SourceFile, because it determine the structure and behavior of the software system in an indirect way, by determining the structure and behavior of the source files through the techniques known as model-based engineering. page 56 add section titled Document Class Document element represents various textual documents that are related to the software system. Superclass InventoryItem Semantics Document element represents various textual documents that are related to the software system. The format of a document can be plain text, formatted text, where style information is included, or one of the many binary formats, in which some portions must be interpreted as binary objects (encoded integers, real numbers, images, etc.). A Document is different from a SourceFile, because it does not determine the structure and behavior of the software system (but may describe it). Document element can be used to represent an arbitrary information item related to the system. Other model element can be linked to particular Document element using traceability links. page 56 11.3.6 replace Image Class with ImageFile Class replace "Image element is used to represent image files." with "ImageFile element represents visual images, such as still graphical images, animated images or video." Add semantics: ImageFile element represents visual images that combine shapes and color to inform, illustrate, entertain, or to guide viewers to particular information. ImageFile can be used to create a graphical interface for the user of a software system. ImageFile can be content of the software system, or part of the related documentation. Graphical images, animated images and video are elements of multimedia technology. A rich multimedia resource that combines video and audio shall be represented as an Instance of ImageFile. An ImageFile requires certain capability to render. page 56 add section titled AudioFile Class AudioFile AudioFile element represents resources related to audio content form. Superclass InventoryItem Semantics: AudioFile element represents resources related to audio content form, for example, digital recording or generation of sound waves such as voice, singing, instrumental music or sound effects. AudioFile can be used to create the user interface of a software system, or as part of its content. Audio is an element of multimedia technology. AudioFile requires certain capability to produce sound. page 56, section 11.3.7 rename Configuration into ConfigFile Add semantics: "ConfigFile element represents configuration files, such as property lists, initial settings for user applications, server processes, operating system settings, or even simple databases. Configuration files often use plain text format, "us-ascii" character set, and are line-oriented. Configuration files are usually used during compilation, linking or initialization phases of the lifecycle of a software system. ConfigFile that is used during the runtime phase is similar to DataFile. For example, a simple database can be also represented as a DataFile. KDM implementation shall select appropriate element based on its role in the system. page 56 remove section 11.3.8 ResourceDescription class page 56 add section LinkableFile (generic) A LinkableFile element represents various forms of relocatable machine code that is usually not directly executable. Superclass InventoryItem Constraints 1. LinkableFile should have at least one Stereotype. Semantics A LinkableFile element represents various forms of relocatable machine code that is usually not directly executable. LinkableFile is a generic element, which introduces an extension point for the light-weight extension mechanism. Concrete subclasses of LinkableElement are ObjectFile and LibraryFile. page 56 add section ObjectFile ObjectFile element represents relocatable bytecode or machine code with additional metadata. Superclass LinkableFile Semantics An object file is a file containing relocatable machine code that is usually not directly executable. Usually object files are used as input to the linker, which in turn typically generates an executable or library by combining parts of object files. In addition object files may contain metadata used for linking or debugging, such as information to resolve symbolic cross-references between different modules, relocation information, stack unwinding information, comments, program symbols, debugging or profiling information. page 56 add section LibraryFile LibraryFile element represents libraries of machine code or bytecode. Superclass LinkableFile Semantics A library is a collection of reusable bytecode or machine code with a well-defined interface. A static library allows access to the code implemented by a library during the build of the invoking program. A shared or dynamic library can be accessed after the executable has been invoked to be executed, either as part of the process of starting the execution, or in the middle of execution. Most compiled languages have a standard library and also allow create custom libraries. Most modern software systems provide libraries that implement the majority of system services. page 57 add section DataFile DataFile element represents variety of plain text or binary files that are used as input to some elements of a software system. Superclass InventoryItem Semantics DataFile element represents variety of plain text or binary files that are used as input to some elements of a software system during the runtime phase. Data files may include csv files, Excel spreadsheets, database files, xml files, json files, etc. DataFile is often similar to a ConfigFile. KDM implementation shall select appropriate element based on its role in the system. page 57 add section Service Service element represents a network resource that exposes some operations. Superclass InventoryItem Semantics Service element represents a network resource that exposes some operations, such as a Web service. For example, REST web services provide a uniform set of stateless operations to manipulate a certain resource. A service may be described in machine-processable format, such as WSDL, and may be registered to facilitate service discovery. Usually a service uses a certain protocol to exchange data. In KDM models a Service resource can be a binding target for various platform resource elements. Rename generic Platform::ResourceType into Platform::PlatformResource page 173 replace parts with resources (2 counts) page 173 replace ResourceType with PlatformResource page 178, Figure 15.2 rename generic clas ResourceType into PlatformResource page 178 replace ResourceType into PlatformResource (2 counts) page 179 replace ResourceType into PlatformResource (10 counts) page 180 replace ResourceType with PaltformResource (6 counts) page 181 replace ResourceType with PlatformResource page 182 Figure 15.3 replace ResourceType with PlatformResource page 182 replace ResourceType into PlatformResource (3 counts) page 184 Figure 15.5 replace ResourceType with PlatformResource page 184 replace ResourceType with PlatformResource page 185 replace ResourceType into PlatformResource (2 counts) page 187 Figure 15.6 replace ResourceType with PlatformResource page 187 replace parts with resources page 188 replace ResourceType with PlatformResource page 189 Figure 15.7 replace ResourceType with PlatformResource page 189 replace ResourceType into PlatformResource (3 counts)
Actions taken:
July 31, 2009: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

deferred to next RTF

Issue 14172: Cobol code erroneously says "PERFROM" instead of "PERFORM" (kdm-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

Cobol code erroneously says "PERFROM" instead of "PERFORM".

Resolution: Page 222, replace �perfrom� with �perform�
Revised Text:
Actions taken:
August 3, 2009: received issue
April 27, 2011: closed issue

Issue 14173: At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow' (kdm-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: 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.
Revised Text: 1. correct typo on page 235: RECORD COTNAINS 39 CHARACTERS into RECORD CONTAINS 39 CHARACTERS 2. Add StorableUnit 'END-OF-FILE-SWITCH' to id.43 <codeElement xmi:id="id.116" xmi:type="code:StorableUnit" name="END-OF-FILE-SWITCH" kind="global" type="id.115"/> 3. Add value 'Yes' to id.43 <codeElement xmi:id="id.117" xmi:type="code:Value" name="'YES'" type="id.115"/> 4. in action element with id.44: microKDM kind should be "PlatformAction" <codeElement xmi:id="id.44" xmi:type="action:ActionElement" name="a0" kind="PlatformAction"> <source xmi:id="id.45" language="Cobol" snippet="OPEN INPUT SEQUENTIAL-FILE OUTPUT INDEXED-FILE."/> <actionRelation xmi:id="id.46" xmi:type="action:Flow" to="id.47" from="id.44"/> </codeElement> 5. Move action element with id.64 between id.43 and id.47 6. microKDM kind should be Equals, add 2 Reads relations, and FalseFlow to id.44 instead of id.47 <codeElement xmi:id="id.64" xmi:type="action:ActionElement" name="a7" kind="Equals"> <source xmi:id="id.65" language="Cobol" snippet="UNTIL END-OF-FILE-SWITCH = 'YES'"/> <actionRelation xmi:id="id.66" xmi:type="action:Reads" to="id.116" from="id.64"/><actionRelation xmi:id="id.66" xmi:type="action:Reads" to="id.117" from="id.64"/> <actionRelation xmi:id="id.66" xmi:type="action:FalseFlow" to="id.44" from="id.64"/> <actionRelation xmi:id="id.67" xmi:type="action:TrueFlow" to="id.68" from="id.64"/> </codeElement> 7. Remove constraint in section 13.9.2 page 157 that the target of an ExceptionFlow is always a CatchBlock; use ExceptionFlow instead of TrueFlow, FalseFlow Change text, page 157: The ExceptionFlow relationship represents an exception flow relationship between a TryUnit and the corresponding CatchUnit, or between a particular action element that can raise an exception to the corresponding CatchUnit. into The ExceptionFlow relationship represents an exception flow of control between an ActionElement that produces an exception, such as a TryUnit, and the ActionElement that handles the exception, such as the corresponding CatchUnit. Change text, page 155: The ExceptionFlow relationship goes from an ActionElement representing the source of the throw, to a CallableElement that represents the catcher of the exception. The ExceptionFlow target is either the local CatchUnit that will handle the exception or point back to the TryUnit. into The ExceptionFlow relationship goes from an ActionElement representing the source of the throw, to another ActionElement that represents the catcher of the exception. The ExceptionFlow target could be a local CatchUnit that will handle the exception or a point back to the TryUnit or simply another ActionElement. 8. in id.47 microKDM kind should be PlatformAction. Note, there is only unconditional normal Flow. The ExceptionFlow is added by the corresponding DataModel <codeElement xmi:id="id.47" xmi:type="action:ActionElement" name="a1" kind="PlatformAction"> <source xmi:id="id.48" language="Cobol" snippet="READ SEQUENTIAL-FILE"/> <actionRelation xmi:id="id.49" xmi:type="action:Flow" to="id.53" from="id.47"/> </codeElement> 9. in id.68 microKDM kind should be PlatformAction; <codeElement xmi:id="id.68" xmi:type="action:ActionElement" name="a8" kind="PlatformAction"> <source xmi:id="id.69" language="Cobol" snippet="Close SEQUENTIAL-FILE INDEXED-FILE."/> </codeElement> 10. in id.59 microAction kind should be PlatformAction. Note, that this has only an unconditional Flow, as the ExceptionFlow is added by the corresponding DataModel <codeElement xmi:id="id.59" xmi:type="action:ActionElement" name="a5" kind="PlatformAction"> <source xmi:id="id.60" language="Cobol" snippet="WRITE INDEXED-RECORD"/> <actionRelation xmi:id="id.61" xmi:type="action:Flow" to="id.64" from="id.59"/> </codeElement> 11. in id.62 microActionKind should be either Calls or PlatformAction, should then flow to close, add Flow to id.68 <codeElement xmi:id="id.62" xmi:type="action:ActionElement" name="a6" kind="PlatformAction"> <source xmi:id="id.63" language="Cobol" snippet="PERFORM 0020-EXPLAIN-WRITE-ERROR"/> <actionRelation xmi:id="id.631" xmi:type="action:Flow" to="id.68" from="id.62"/> </codeElement> 12. In data model; name="EOF", kind="exception" <dataElement xmi:id="id.23" name="EOF" kind="exception"> <abstraction xmi:id="id.24" name="ae1"> <actionRelation xmi:id="id.25" xmi:type="action:ExceptionFlow" to="id.50" from="id.24"/> </abstraction> </dataElement> 13. In data model; name="NOT EOF" kind="exception" <dataElement xmi:id="id.26" name="NOT EOF" kind="exception"> <abstraction xmi:id="id.27" name="nae1"> <actionRelation xmi:id="id.28" xmi:type="action:Flow" to="id.53" from="id.27"/> </abstraction> </dataElement> 14. In data model; name="INVALID KEY" kind="exception" <dataElement xmi:id="id.35" name="INVALID KEY" kind="exception"> <abstraction xmi:id="id.36" name="ik1"> <actionRelation xmi:id="id.37" xmi:type="action:ExceptionFlow" to="id.62" from="id.36"/> </abstraction> </dataElement> 15. in data model; missing implementation="id.68" <dataElement xmi:id="id.38" xmi:type="data:DataAction" name="da5" kind="close" implementaion="id.68"> <abstraction xmi:id="id.39" name="da5" kind="close"/> </dataElement> 16. in data model; missing implementation="id.68" <dataElement xmi:id="id.40" xmi:type="data:DataAction" name="da6" kind="close" implementation="id.68"> <abstraction xmi:id="id.41" name="da5" kind="close"/> </dataElement> 17. add ProducesDataEvent to abstracted DataAction for reads <dataElement xmi:id="id.17" xmi:type="data:DataAction" name="da3" kind="read" implementation="id.47"> <abstraction xmi:id="id.18" name="da3" kind="read"> <actionRelation xmi:id="id.19" xmi:type="data:ReadsColumnSet" to="id.1" from="id.18"/> <actionRelation xmi:id="id.20" xmi:type="action:Writes" to="id.2" from="id.18"/> <actionRelation xmi:id="id.21" xmi:type="action:Writes" to="id.3" from="id.18"/> <actionRelation xmi:id="id.22" xmi:type="platform:ReadsResource" to="id.75" from="id.18"/> <actionRelation xmi:id="id.22a" xmi:type="platform:ProducesDataEvent" to="id.23" from="id.18"/> <actionRelation xmi:id="id.22b" xmi:type="platform:ProducesDataEvent" to="id.26" from="id.18"/> </abstraction> 18. add ProducesDataEvent to abstracted DataAction for writes <dataElement xmi:id="id.29" xmi:type="data:DataAction" name="da4" kind="write" implementation="id.59"> <abstraction xmi:id="id.30" name="da4" kind="write"> <actionRelation xmi:id="id.31" xmi:type="action:Reads" to="id.7" from="id.30"/> <actionRelation xmi:id="id.32" xmi:type="action:Reads" to="id.8" from="id.30"/> <actionRelation xmi:id="id.33" xmi:type="data:WritesColumnSet" to="id.4" from="id.30"/> <actionRelation xmi:id="id.34" xmi:type="platform:WritesResource" to="id.79" from="id.30"/> <actionRelation xmi:id="id.34a" xmi:type="platform:ProducesDataEvent" to="id.35" from="id.30"/> </abstraction>
Actions taken:
August 3, 2009: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

According to this spec(P64),  "Package" is subclass of Modules.  In that case, what is the base class of Module?  (CodeItem is superclass of Module. However, CodeItem is not original  UML base element.)  Considering above, it seems this "Package" is different from original  UML Package.  From my understanding,  (I think,)  if this spec use the Module,  Module is a subclass of Package (which is from original UML),  and change the name of "Package", which are shown in Page 64 and Page  66, to "Container" (something like that).  Disposition: Deferred

Issue 14572: 'DataUnit' incorrectly used instead of 'DataElement' (kdm-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

'Table A.4 - Control actions' contains two rows related with Incr and Decr ActionElement Micro actions. In the column named 'Outputs' the word 'DataUnit' is incorrectly used twice, one per row. It should read 'DataElement'.

Resolution: Page 296, A.4 replace �DataUnit� with �DataElement� (2 times)
Revised Text:
Actions taken:
October 19, 2009: received issue
April 27, 2011: closed issue

Issue 15129: Provide detailed information about dependencies between KDM packages (kdm-rtf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:

Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that �Existing software based systems have the relationship among packages.  But this standard doesn't mention it precisely.  (Conceptually, this shows package structure.)�. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification.

Resolution: Defer to KDM 1.5 Defer to KDM 1.5
Revised Text:
Actions taken:
March 24, 2010: received issue
March 29, 2016: Deferred
July 12, 2016: closed issue

Discussion:

It is not clear whether the issue is with the general approach within KDM to  representing packages in existing systems, or about Figure 8.1 in the KDM  specification, showing packages on KDM itself.  Additional discussion on November 30:  Clarification request: The issue is about the modelling elements of the  KDM that allow representation of the packages within some existing  system, as well as relationships between these packages, so that the  corresponding KDM view can be described using a UML package diagram.  Please let me know if this interpretation of the issue is correct.  Assuming that this interpretation is correct, existing KDM  specification already has several relevant mechanisms.  KDM has Package meta-model element (section 12.5.6, part of the Code  package and the corresponding Code viewpoint). This element represents  packages in existing software systems, as well as similar module  constructs. The Package element is the endpoint of several KDM  relationships. First, a Package may "contain" other KDM elements.  Second, some element may "import" a Package using the Imports  relationship, or be "Visible in" a Package using the "VisibleIn"  relationship.  However, most importantly, KDM defines the mechanism of "aggregated  relationships" by which relationships between Packages can be derived from the individual relationships between the contained elements of  these Packages.  KDM specification does not define any diagrams, however the KDM Code  views involving Packages can be mapped to a UML Package diagram.  So, provided my interpretation of the issue is correct, KDM already has  the necessary modelling elements to describe relationships between  packages of existing software systems. In fact, several KDM compliant  tools already produce package diagrams of existing software based  systems.  Response from the originator of the comment:  I checked KDM spec. again.  �Existing software based systems have the relationship among packages.  But this standard doesn't mention it precisely. (Conceptually, this  shows package structure.)�. The suggested resolution was to >Describe  it using Package diagram.  The issue is about the modelling elements of the KDM that allow  representation of the packages within some existing system, as well as  relationships between these packages, so that the corresponding >KDM  view can be described using a UML package diagram.�  Your interpretation is correct.  My comment means that it is necessary to define package structure using  Package diagram.  �KDM has Package meta-model element (section 12.5.6, part of the Code  package and the corresponding Code viewpoint). This element represents  packages in existing software systems,�  <..>  my original question is based on the Figure 8.1 Page 11.  This figure shows package structure of KDM.  In general, multiple Package structure specification like UML need to  be defined using Package diagram,  to clarify their structure/relationship.  This Figure 8.1 is not precise definition of Package structure  (different from regular definition).  To clarify this structure, it is necessary to specify the Package  structure usign UML,  because there is no precise way to define package structure except UML  package diagram. According to this spec(P64),  "Package" is subclass of Modules.  In that case, what is the base class of Module?  (CodeItem is superclass of Module. However, CodeItem is not original  UML base element.)  Considering above, it seems this "Package" is different from original  UML Package.  From my understanding,  (I think,)  if this spec use the Module,  Module is a subclass of Package (which is from original UML),  and change the name of "Package", which are shown in Page 64 and Page  66, to "Container" (something like that).  Disposition: Deferred

Issue 15273: StorableUnit is not a subclass of StorableElement (anymore) (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

12.7.2  StorableUnit Class    StorableUnit class is a concrete subclass of the StorableElement class that represents variables of the existing software     system.

Resolution:
Revised Text:
Actions taken:
June 4, 2010: received issue
April 25, 2011: closed issue

Issue 15276: mark code element as ordered (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Add "ordered" to owned CodeElement in Action Add "ordered" to owned CodeElement in Action as per issue description. Remove "ordered" from AbstractActionRelationship association.
Revised Text: in the model, remove "ordered" attribute from association from ActionElement to AbstractActionRelationship. add "ordered" attribute to association from ActionElement to AbstractCodeElement. Update Figure 13.1
Actions taken:
June 5, 2010: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 15277: current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text: page 77, Figure 12.4 Add isFinal:Boolean to MemberUnit and MethodUnit. Add isStatic:Boolean to MemberUnit, MethodUnit and CallableUnit. Add isVirtual:Boolean, isAbstract:Boolean to MethodUnit move ExportKind from DataElements class diagram to ControlElements class diagram page 78, 12.6.2 CallableUnit add attribute isStatic:Boolean indicates that the element is declared as "static" (is visible only in the owner CompilationUnit) page 79, MethodUnit add attributes isFinal:Boolean indicates that the method may not be redefined in a subtype isStatic:Boolean indicates that the method characterizes the ClassUnit (true) or individual class instances (false) isVirtual:Boolean indicates the the method is declared as virtual isAbstract:Boolean indicates that the method is declared as abstract or is the part of an interface add Constraints: 1. No instance of MethodUnit shall have isAbstract==true AND isFinal==true page 79 12.6.5 MethodKind remove virtual, abstract page 79 move section ExportKind here page 81, Figure 12.5 move ExportKind to ControlElements class diagram add attribute isFinal:Boolean to MemberUnit isStatic:Boolean to MemberUnit isStatic:Boolean to StorableUnit isFinal:Boolean to ParameterUnit remove final from ExportKind remove static from StorableKind page 82, 12.7.2 StorableUnit add attribute isStatic:Boolean indicates that the element is declared as "static" (visible only in the owner CompilationUnit) page 82, 12.7.3 remove static page 83 12.7.4 ExportKind remove final move section to ControlElements page 84, 12.7.7 MemberUnit add attributes isFinal:Boolean indicates that the member may not be redefined in a subtype isStatic:Boolean indicates that the member characterizes the ClassUnit(true) or individual class instances (false) page 84, 12.7.8 ParameterUnit add attribute isFinal:Boolean indicates that the parameter may not be written to (may not be the endpoint of a Writes relationship) page 103, Figure 12.13 add attribute isFinal:Boolean to ClassUnit page 104, 12.15.1 ClassUnit add attribute isFinal:Boolean indicates that the ClassUnit may not have subtypes (may not be the to-endpoint of Extends relationship)
Actions taken:
June 7, 2010: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 15304: 15.5.5 FileResource Class (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the following paragraph, the DataInterface has been gone since 2006, so maybe we just want to remove the last sentence or reword it to refer to the PlatformActions.         15.5.5  FileResource Class    FileResource represents platform resources that provide any non-database related storage. In the meta-model the     FileResource class is a subclass of ResourceType. It also implements the DataInterface so that this class can be the     endpoint of Data relations.

Resolution: Page 170, delete sentence �It also implements the DataInterface so that this class can be the endpoint of Data relations.�
Revised Text:
Actions taken:
June 25, 2010: received issue
April 27, 2011: closed issue

Issue 15305: There should be no references from lower KDM layers to higher layers (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the preface to part III we have the following:         KDM is designed in such a way that the Resource level analysis can use KDM models from the Platform Elements Layer as input and produce Resource Layer models as output. There should be no references from lower KDM layers to higher layers; therefore, new Resource Layer models can be built on top of existing Program Element layer models.         Couple of points:    1.       There is no �Platform Elements Layer�. As shown in the next sentence it should probably read �Program Elements Layer� which is part II.    2.       The 2 places where it refers to �Resource Layer� might be renamed to �Runtime Resources Layer� to better match the part title.

Resolution: Page 159, replace �commpon properties of the Resource Layer� with �common properties of the Runtime Resources Layer� (After bullets) Replace �Since Resource Layer� with �Since �Runtime Resources Layer� Replace �a way that the Resource Layer� with �a way that the Runtime Resources Layer� Replace �produce Resource Layer models� with �produce Runtime Resources Layer models� Replace �new Resource Layer models� with �new Runtime Resources Layer models� Replace �Platform Elements Layer as input� with �Program Elements Layer as input� Replace �Resource Layer package systematically: with �Packages of the Runtime Resources Layer� Bullet 1 replace �Each Resource Layer package defines� with �Each Runtime Resources Layer package defines� Bullet 2 replace �Each Resource Layer package defines� with �Each Runtime Resources Layer package defines� Bullet 2 replace �Each Resource Layer package defines� with �Each Runtime Resources Layer package defines� Replace �modularity between Resource Layer packages� with �modularity between KDM packages� Page 160 Bullet 5 replace �elements of Resource Layer package� with �elements of Runtime Resources Layer package� Bullet 6 replace �Each Resource Layer package defines� with �Each Runtime Resources Layer package defines� After bullets: replace �Resource Layer packages are independent� with �Runtime Resources Layer packages are independent� Replace �action containers in Resource Layer models� with �action containers in Runtime Resources Layer models� In the next bulleted list replace �Resource Layer patterns� with �Runtime Resources Layer patterns�
Revised Text:
Actions taken:
June 25, 2010: received issue
April 27, 2011: closed issue

Issue 15872: References in KDM for UML, MOF, and XMI are not current (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Nature of Problem: 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) "

Resolution: Replace Normative References section 3, page 6, with the following: 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 Infrastructure Specification, ver. 2.3, formal/2010-05-03 � OMG Meta Object Facility (MOF) Specification, ver. 2.0, formal/06-01-01 � OMG MOF XML Metadata Interchange (XMI) Specification, ver. 2.1, formal/05-09-01 � OMG Semantics of Business Vocabularies and Business Rules (SBVR) Specification, ver. 1.0, formal/08-01-02 � ISO/IEC 11404:2007 Information technology -- General-Purpose Datatypes (GPD)
Revised Text:
Actions taken:
December 7, 2010: received issue
April 27, 2011: closed issue

Discussion:

Additional comment from Tom Rutt:  �A correction needs to be made to the proposed resolution.  I think the resolution needs to be that the References in the output of this RTF be to  the versions of the reference specs which were available at the time the RTF was doing its  work. The proposed resolution needs to be amended so that the UML reference be changed to  UML 2.3,  and the MOF ref should be to MOF 2.0, and the XMI ref to XMI 2.1.1.�  RTF comment: This issue provides details related to the previous issue 13826.  KDM XMI uses XMI 2.1, not XMI 2.1.1. As Tom suggested, we will use the actual  version used, which is XMI 2.1.

Issue 15878: References in KDM for UML, MOF, and XMI are not current (kdm-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Merge with [1]KDM14-56 Merge with [2]KDM14-56 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/KDM14-56 [2] http://issues.omg.org/browse/KDM14-56
Revised Text:
Actions taken:
December 7, 2010: received issue
March 29, 2016: Duplicate or Merged
July 12, 2016: closed issue

Issue 15897: In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Change superclass of MethodUnit to ControlElement The correct superclass of MethodUnit is ControlElement as in the model. The specification text should be corrected.
Revised Text: page 79, section 12.6.4 change "CallableUnit" to "ControlElement"
Actions taken:
December 13, 2010: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 15906: micro-KDM documentation not updated (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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
Revised Text: page 312, in table A.4 for MethodCall, column Inputs, change "Invokes" into "Addresses" page 316, in table A.5 for MemberSelect, column Inputs, change "Invokes" into "Addresses" page 316, in table A.5 for MemberReplace, column Inputs, change "Invokes" into "Addresses"
Actions taken:
January 3, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 15923: BuildResource class diagram (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Merge with [1]KDM14-70 This issue is merged with [2]KDM14-70 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/KDM14-70 [2] http://issues.omg.org/browse/KDM14-70
Revised Text:
Actions taken:
January 10, 2011: received issue
March 29, 2016: Duplicate or Merged
July 12, 2016: closed issue

Issue 15924: Gap in KDM Platform Package (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text: page 59, add Superclass AbstractInventoryRelationship to section 11.5.1 Figure 11.3, page 59 and add class "TraceableTo" from KDMEntity to InventoryItem. Page 59 add new section 11.5.2 TraceableTo class Traceable class is a meta-model element that represents an optional relationship between any KDMEntity and an InventoryItem. This relationship represents situations where the KDMEntity is traceable to the inventory element during one or more steps of the engineering process. For example, a Module element in the CodeModel can be traceable to a certain SourceFile. Superclass AbstractInventoryRelationship Associations from:KDMEntity[1] to:InventoryItem[1] Constraints 1. An InventoryItem cannot be traceable to itself Semantics The TraceableTo relationship is optional. The implementer may capture certain aspects of the knowledge extraction process or engineering process in the form of ?TraceableTo? relations to inventory items. ?TraceableTo? relationship is part of the Infrastructure Layer, which is available to all KDM implementations at various compliance levels. "TraceableTo" relation is related to the SourceRef mechanism that is also provided by the InventoryModel. However, in contrast to the SourceRef mechanism, the "TraceableTo" relation is an explicit relation between any KDMEntity and some InventoryItem. KDM Build package that constitutes a separate L1.Build compliance point, defines additional meta-model elements that represent the facts involved in the build process of the software system (including but not limited to the engineering transformations of the ?source code? to ?executables?).
Actions taken:
January 10, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Issue 15925: KDM Build package issue (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: 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.
Revised Text: In model rename class LIbrary into BuildLibrary. Modify Figure 21.3 on page 301 page 297, replace Library with BuildLibrary page 301, replace Library with BuildLibrary page 302, section 21.5.2, replace text "binary files that correspond to deployable components, for example executable files" with "an arbitrary collection of InventoryItems (or other KDM entities). Usually 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." page 302, insert section 21.5.5 BuildLibrary BuildLIbrary represents a named collection of InventoryItems (usually BinaryFiles, or SourceFiles) which is used as an intermediate product of a build process. Superclass BuildResource Semantics page 302, insert section 21.5.6 BuildProduct BuildProduct represents a named collection of InventoryItems that is the output of a build process (usually BinaryFile or ExecutableFile). For example, binary files that correspond to deployable components, executable files. Superclass BuildResource Semantics
Actions taken:
January 10, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Discussion:

Issue 15979: If negate is unary it probably doesn't apply to two values (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Change text in table A.2 Correct description of Negate operation.
Revised Text: in table A.2 page 310, for Negate, change text "two value of the same" into "a single value of" change text "datatype." (at the end) into: "datatype. Requires a single Reads relationship."
Actions taken:
January 21, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 16167: Handling of Java enums (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Mr. Alain Picard, apicard(at)benchmarkconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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
Revised Text: Add to section 12.10.1, page 93 Constraints 1. Every Value element owned by an EnumeratedType must have its type property set to this EnumeratedType. at the end of Semantics paragraph on page 93, add: "Some programming languages, for example Java, allow enumerated type with methods and other elements. Such datatypes are represented as ClassUnit, containing the corresponding Value element." In 12.15 ClassUnit, page 104, after words "internal datatype definitions, etc." add the following sentence: "A class that has a finite set of named literals like a Java enum can be represented as a ClassUnit containing Value elements. These Value elements shall have the name corresponding to name of the literal and they shall all have the type property set to the containing ClassUnit. Simple Java enum with just a set of literals can still be represented as an EnumeratedType instance."
Actions taken:
May 5, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 16633: AbstractConceptualElement is required to have one and only one role (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Clarification
Severity: Minor
Summary:

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.

Resolution: Change caridinality of Role association at the side of ConceptualRole to 0..* Allow multiple ConceptualRoles to be associated with the same AbstractConceptualElement
Revised Text: Change cardinality of ConceptualRole in Role association from 1 to 0..* Add text in Semantics section on page 285: "Multiple ConceptualRole elements can be associated with the same AbstractConceptualElement"
Actions taken:
October 25, 2011: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 17092: Inconsistency between diagram and description (kdm-rtf)

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

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

Resolution: 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.
Revised Text: Figure 12.12, page 102 change cardinality of property codeElement from 0..1 into 0..*
Actions taken:
January 31, 2012: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 17093: Incorrect description in AbstractCodeElement codeRelation association (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Change description of AbstractCodeElement Change word "model" into word "element" as suggested.
Revised Text: Page 72, description of the association CodeRelationship, change "model" into "element"
Actions taken:
January 31, 2012: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 17272: Typo: Optinal should read Optional (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Clarification
Severity: Minor
Summary:

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'

Resolution: Already fixed in KDM 1.3 The typo has been fixed throughout the editing process. Not present in the formal KDM 1.3 document
Revised Text:
Actions taken:
March 26, 2012: received issue
March 29, 2016: Closed; No Change
July 12, 2016: closed issue

Issue 17301: Errors in example for micro actions (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Revision
Severity: Minor
Summary:

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      In normative ANNEX:  A.5 PtrReplace inputs should be corrected to 'single reads relationship' rather than last read.

Resolution: Correct microKDM example Multiple corrections of XML on pages 165-167
Revised Text: page 165, with Flow from="id.4": add to="id.12" page 165, with Flow from="id.31": add to="id.37" page 165, in StorableUnit with "id.45": change type="id.112" into type="id.103" page 166, with Flow from="id.55": add to="id.61" page 166 action element with id.62 change type to Addresses page 166, with Flow from="id.75": add to="id.81" page 166, with Flow from="id.81": add to="id.86" page 167 action element with id.93 change type to Addresses
Actions taken:
April 11, 2012: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 17374: Missing superclass: StructureGroup (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: 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.
Revised Text: page 272, section 19.3.4 change "StructureGroup" into "AbstractStructureElement" page 272, section 19.3.5 change "StructureGroup" into "AbstractStructureElement" page 272, section 19.3.6 change "StructureGroup" into "AbstractStructureElement" page 273, section 19.3.7 change "StructureGroup" into "AbstractStructureElement" page 273, section 19.3.8 change "StructureGroup" into "AbstractStructureElement"
Actions taken:
May 18, 2012: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 18778: Specification of Incr and Decr is ambiguous (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: 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.
Revised Text: Change text on page 310, "except for neg, succ, incr, dece unary operations, which has a single Reads relationship into except for Negate and Successor operations, which require a single Reads relationship; Incr and Decr operations, which require a single Addresses Relationship Remove rows Incr, Decr from table A.4 at page 314. Add 2 rows to table A.2 as follows: Incr | Variable post increment operation. Single Addresses relationship represents the DataElement whose value is incremented. Decr | Variable post decrement operation. Single Addresses relationship represents the DataElement whose value is decremented. Page 311, change text "except for neg, succ, incr, dece unary operations, which has a single Reads relationship" into "except for BitNot, which requires a single Reads relationship" change text in column Inputs, for BitNot into: "Single Reads relationship to a DataElement"
Actions taken:
June 13, 2013: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 18779: VirtualCall is missing an Addresses (kdm-rtf)

Click here for this issue's archive.
Source: Benchmark Consulting (Dr. Stephane Vaucher, svaucher(at)benchmarkcanada.com)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: 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
Revised Text: page 313, in VirtualCall decription, column "Inputs", change "Invokes" to "Addresses".
Actions taken:
June 14, 2013: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue

Issue 19729: Navigability used for code generation (kdm-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text: change text on page 10, section 6.2.1 from Meta-model diagrams in this specification into Class diagrams in this specification Change text The following conventions are adopted for all metamodel diagrams into The following conventions are adopted for all class diagrams change text, page 10: from unlabeled, the into unlabeled that association end is owned by the association. The change text non-navigable association ends into association ends that are owned by by the association are also considered non-navigable and add subbullet by this convention, KDM specification explicitly defines several operations that emphasize navigation to the classes where the association end is owned by the association. These operations constitute the high-level interface to KDM. Such operations are redundant from the MOF perspective as they are already implied by the derived properties. Keep "navigation" operations in the UML model. Make them not visible on the diagrams. page 27 KDM entity semantics add text: Association ends owner, ownedElement, group, groupedElement are owned by the associations. At the class diagram they are marked as derived. Explicit operations are defined for navigation. These operations constitute as generic interface of KDM Core. Individual KDM Models define specialized versions of the generic KDM Core interface with more specific details regarding allowed associations between entities in each model. add text 9.5.1 Association ends to, from and ownedRelation are owned by the associations and are marked as derived. Explicit operations are defined for navigation. Individual KDM Models define specialized versions of the generic KDM Core interface with more specific details regarding allowed associations between entities in each model. add text section 9.5.2 Association ends inbound, outbound and ownedRelation are owned by the associations and are marked as derived. Explicit operations are defined for navigation. Individual KDM Models define specialized versions of the generic KDM Core interface with more specific details regarding allowed associations between entities in each model. Replace Figure 9.4, page 30, to mark property "aggregate" as derived section 9.6.1 page 31 Replace "This" with "One AggregatedRelationship represents collection of individual explicit relationships (and can be referred to as an aggregate). The aggregation rules are defined in the semantics section. AggregatedRelationship" Replace "The lifecycle of the Aggregated Relationships can be explicitly managed by the operations of the KDMEntity class" with KDMEntity class defines operations for managing the lifecycle of its owned AggregatedRelationships add to page 33 before 9.7 9.6.3 KDMRelationship (additional properties) Associations / aggregate:AggregatedRelationship[0..*] the set of aggregated relationships that include this KDMRelationship. This is a derived non-navigable property and no explicit operations for navigation are defined Page 38 add "/" in front of ownedElement add 10.3.3 Associations / model: KDMModel[0..1] KDM model that owns this KDM Entity add text 10.3.2 Association ends model and ownedElement are owned by the associations and are marked as derived. Explicit operations are defined for navigation. add text 10.3.3. Semantics Association ends model and ownedElement are owned by the associations and are marked as derived. Explicit operations are defined for navigation. Page 39 correction: model:KDMModel[0..*] add text page 43, 10.5.1. Association ends tag and owner are owned by the class. add text page 46 10.5.2 Association end owner is owned by the class. add text page 46 10.5.3 Association ends stereotype and owner are owned by the class. add text page 47, 10.5.4. Semantics Association ends taggedValue and stereotype are owned by the class. Page 48 correction: tag:TagDefinition[1] add text to 10.6.1. Semantics Association end tag is owned by the class. add text to 10.7.1. Association end owner is owned by the class. add text to 10.7.2. Association end owner is owned by the class. add text to 10.7.3. Association ends attribute and annotation are owned by the class.
Actions taken:
February 21, 2015: received issue
March 29, 2016: Resolved
July 12, 2016: closed issue