Issues for ADM KDM 1.4 Revision Task Force

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

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

Issue 9995: Section: 19
Issue 10123: Break cyclic dependency between Code and Action package
Issue 10135: Section: 20
Issue 10288: Section: 12, page 41-74 (03)
Issue 10291: Section: 13.4 page 80
Issue 10293: Section: 17 pages 131 - 136
Issue 10297: Section: 18 pages 137 - 148 (02)
Issue 10306: Section: 20
Issue 10319: Section: 19 pages 149 - 169 (08)
Issue 11167: most operations in the whole specification are redundant
Issue 11168: 9.3.3 definition of owner
Issue 11169: 9.3.3, association 'group'
Issue 11170: 9.3.3 Constraint 1 seems wrong
Issue 11171: 9.3.3 getOwnerElement is misnamed
Issue 11172: 9.4.1 - CMOF “redefines” mechanism
Issue 11173: 9.4.2 - why 2 separate associations?
Issue 11174: 9.5.1: Property 'density' should be a derived property
Issue 11175: 9.5.1 Constraint 4 is inconsistent
Issue 11176: 9.5.1 Semantics: should be expressed in OCL
Issue 11177: 9.6: These types should be declared as primitive
Issue 11178: 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.
Issue 11179: 10.3.1: Description of 'segment' property
Issue 11180: p31 the XMI example has wrong namespaces for xmi and kdm and audit
Issue 11181: 10.4 would be better to have a proper 'date' type rather than using String
Issue 11182: 10.4: use of 'author' is redundant
Issue 11183: 10.4.1: Audit.description
Issue 11709: Validate KDM examples in the KDM specification
Issue 11710: throws example in the spec is incomplete
Issue 11711: Consider Uniform representation of exception object and classes
Issue 11712: Consider representation of a switch
Issue 11713: Need a counterpart of the HasValue relation
Issue 11714: PtrCall for callable units and method units a->foo()
Issue 11715: Add uppercase requirement for the names of micro KDM operations
Issue 11716: Call via pointer example: need pointer type in type unit fp
Issue 11717: consider having a StorableUnit and CallableUnit, maybe with an explicit kin
Issue 11718: specify which characterset is used for chartype or provide the capability t
Issue 11719: representation of the sizeof (type) operator as opposed to sizeof (expr) op
Issue 11720: Correct specification text:
Issue 11721: There is an ambiguity between BlockItem and micro action compound
Issue 11722: Discuss using the name of the action element as label
Issue 11723: Initialization block?
Issue 11724: More than one label on a statement
Issue 11725: In Initialization example do not need to use extern in the names
Issue 11726: Variable d2 in main compilation unit b.cpp doesn't have aHasValue relation
Issue 11727: name of CompilationUnit should not contain extension
Issue 11728: Assoc. between CompilationUnit and SourceFile other than through SourceRef
Issue 11729: Need to make Datatype generic, for the sake of using it in with stereotypes
Issue 11730: text should mention optional writes in micro kdm and an example with a+1;
Issue 11731: change text for the arrayselect "single" reads
Issue 11732: representation of this-> and this
Issue 11733: variables that are declared at header of loop needs special care in KDM
Issue 11734: Description of the multidimentional arrays is confusing.
Issue 11735: There is a problem with Throws relation and Throw micro operation
Issue 11736: Representation of a stand-alone comment
Issue 11737: explicit relationship and the built-in relationships
Issue 11738: Clarify the algnment with SBVR
Issue 11739: Clarify alignment of the KDM Core with RDF
Issue 12420: invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI
Issue 12421: CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI
Issue 12422: Rename these associations to SignatureType and SourceFileRegion respectivel
Issue 12423: Association A.62
Issue 12424: Many associations and association ends are given meaningless generated name
Issue 12425: Several association ends are both 0..* and composite owners
Issue 12480: BindsTo relationship should have a more general “to” endpoint
Issue 12481: RecordFile and Datatypes
Issue 12482: kinds for resource actions
Issue 12483: SourceRef in Build package
Issue 12866: Inconsistency in the description of ConceptualRelations diagram
Issue 12870: Missing section in KDM documentation
Issue 12871: Page numbers
Issue 12872: Clarification on KDM package - kdm package/ Core - core etc needed
Issue 12873: general information/comments
Issue 12874: "Constraints" sub-section in the descriptions seems to be rarely needed
Issue 12875: p. 25 editorial comment
Issue 12876: p.25 (p.3) Confusion
Issue 12877: p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer"
Issue 12878: p.31 (p.9) bottom of page
Issue 12879: p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model"
Issue 12880: p.32 (p.10) "Analyst is able to refactor the model..." bullet should be changed
Issue 12881: spell out SBVR
Issue 12882: p.33 Figure 8.1 -- "Actions" should be "Action"
Issue 12883: p.33 (p.11) editorial issues
Issue 12884: p.34 (p.12) Bullet in section 8.2
Issue 12885: p.35 (p.13) "Small KDM core..." -- need description or introduction as to what this is
Issue 12886: p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1)
Issue 12887: p.42 (p.20) Constraints sub-section
Issue 12888: p. 43 (p.21) descriptions of items
Issue 12889: to: KDMEntity[1]
Issue 12890: from:KDMEntity[1]
Issue 12891: p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work
Issue 12892: Editorial issues p 47 through 51
Issue 12893: p.52 (p.30) date:String and constraints
Issue 12894: p.53 (p.31) Section 10.4.2
Issue 12895: p. 65/66 editorial issues
Issue 12896: p.69 (p.47) in the Semantics section
Issue 12897: p.69 (p.47) Section 11.3.6, 7, 8, 9, 10
Issue 12898: p. 178 (p. 154) -- Inputs bullet -- should be "Ordered incoming..." not "Ordered outgoing..."
Issue 12899: p. 177 (p. 153) -- last line should be reordered
Issue 12900: p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name
Issue 12901: p. 178 (p. 154) Semantics
Issue 12902: Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents
Issue 12903: ISO/IEC 11404" should be "ISO/IEC 11404:1996
Issue 12904: p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6
Issue 12905: p.88 (p.66) Suggest changing wording
Issue 12906: p.101 (p.79) I don't see the use for the DateType Class
Issue 12907: p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.
Issue 12908: p.104 (p.82) "...defined datatype Octet String." -- "String" should be "string"
Issue 12909: Section 12 add example
Issue 12910: p. 113 (p.91) Change "return
Issue 13159: KDM is missing constraints capabilities to stereotype
Issue 13160: AbstractEventElement should group KDM Elements (instead of AbstractCodeElement)
Issue 13161: Component should allow one to express exposed and required services
Issue 13162: Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews
Issue 13293: Alignment with the ISO concept of architecture view (rh-2)
Issue 13294: Missing definitions of terms (rh-3)
Issue 13295: Missing definition of software asset (rh-4)
Issue 13296: Need to clarify the use of term ‘view’ and align with ISO (rh-5)
Issue 13297: Clarify the usage of ‘view’ (rh-6)
Issue 13298: Clarify the intent of KDM ontology (rh-7)
Issue 13299: Reference ISO terminology (rh-8)
Issue 13300: Align structure package with ISO 42010 (rh-9)
Issue 13301: Align KDM Package with ISO Architecture Views (rh-10)
Issue 13302: Missing definitions for ‘Engineering view’, ‘logical view’ and ‘developers view’ (rh-11)
Issue 13303: Align structure package with ISO 42010 (rh-12)
Issue 13304: Align ‘ArchitectureView element with ISO (rh-13)
Issue 13323: Build Package in Abstract Layer (page 280-281).
Issue 13396: case of a property name duplication
Issue 13397: upper bound of the container end of a composition shown as unbounded
Issue 13398: "Segments" assocation on the kdm::Segment class
Issue 13399: associations with duplicated names in the same package
Issue 13822: This document doesn't define the common interchange format (JP-1).
Issue 13823: Interchange format in compliance statement (JP-2)
Issue 13824: Compliance levels (JP-3)
Issue 13825: Normative references (JP-4)
Issue 13826: The format of normative references doesn't meet ISO format. (JP-5)
Issue 13827: There is no terms ,definitions and symbols. (JP-6)
Issue 13828: Relationships between packages (JP-7)
Issue 13829: ISO standard documents are described with "shall", "should" and "may" (JP-8)
Issue 13830: Acknowledgements are not specification. (JP-9)
Issue 13831: Some class constraints are numbered, but others are not. Unify them. (JP-10)
Issue 13832: The title of ISO/IEC 11401 is incorrect. (JP-11)
Issue 13833: Annex must be either “normative” or “informative”. Specify it. (JP-12)
Issue 14106: Change relation endpoint for Audit relation
Issue 14107: Change specification to allow stereotyping of Audit elements
Issue 14108: Wrong class mentioned
Issue 14109: Small typo at 19.3.8
Issue 14170: Clarify the meaning of BinaryFile
Issue 14171: Standardize naming of InventoryItem children
Issue 14172: Cobol code erroneously says "PERFROM" instead of "PERFORM"
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'
Issue 14572: 'DataUnit' incorrectly used instead of 'DataElement'
Issue 15129: Provide detailed information about dependencies between KDM packages
Issue 15273: StorableUnit is not a subclass of StorableElement (anymore)
Issue 15276: mark code element as ordered
Issue 15277: current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit
Issue 15304: 15.5.5 FileResource Class
Issue 15305: There should be no references from lower KDM layers to higher layers
Issue 15872: References in KDM for UML, MOF, and XMI are not current
Issue 15878: References in KDM for UML, MOF, and XMI are not current
Issue 15897: In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement
Issue 15906: micro-KDM documentation not updated
Issue 15923: BuildResource class diagram
Issue 15924: Gap in KDM Platform Package
Issue 15925: KDM Build package issue
Issue 15979: If negate is unary it probably doesn't apply to two values
Issue 16167: Handling of Java enums
Issue 16633: AbstractConceptualElement is required to have one and only one role
Issue 17092: Inconsistency between diagram and description
Issue 17093: Incorrect description in AbstractCodeElement codeRelation association
Issue 17272: Typo: Optinal should read Optional
Issue 17301: Errors in example for micro actions
Issue 17374: Missing superclass: StructureGroup

Issue 9995: Section: 19 (kdm-rtf)

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

Deferred to RTF

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. 

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

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

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

Deferred to RTF

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 

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

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

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

Deferred to RTF

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

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

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

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

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

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

9.3.3 getOwnerElement is misnamed - should be getOwnedElement.

Correct text
Change getOwnerElement into getOwnedElement

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

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

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

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

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

Correct text; remove inconsistent constraint

9.5.1 Semantics: should be expressed in OCL

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

Deferred to next RTF to allow more discussion

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

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

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

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

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

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

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

Deferred to next RTF to allow more discussion

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

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

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

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

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

Deferred to next RTF

throws example in the spec is incomplete

Deferred to the next RTF

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

Deferred to the next RTF to allow more discussion

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

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

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

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

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

Defer to the next RTF due to the lack of time

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

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

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

Defer to the next RTF.

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

Defer to the next RTF.

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

Defer to the next RTF.

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

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

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

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

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

Defer to the next RTF.

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

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

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

deferred to next RTF

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.

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

Defer to the next RTF.

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

Defer to the next RTF.

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

Defer to the next RTF to allow more discussion

Association between CompilationUnit and SourceFile other than through SourceRef.

Defer to the next RTF to allow more discussion

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

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

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

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

change text for the arrayselect "single" reads

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

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

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

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

Defer to the next RTF

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

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

There is a problem with Throws relation and Throw micro operation: Throws relation is to an object! but Throw says
that there are Reads. Reads should be part of the constructor, there should be new, bla-bla, constructor call.
Big question mark.

Throws should be a shortcut - relationship to the exception class. with a single Reads to the exception object. 
Because we do not want to duplicate the constructor call logic.

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

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

Defer to the next RTF

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

Defer to the next RTF

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

Defer to the next RTF due to the lack of time

Clarify alignment of the KDM Core with RDF

Defer to the next RTF due to the lack of time

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


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

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


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

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


Proposed resolution
Rename these associations to SignatureType and SourceFileRegion respectively 


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


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

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


Proposed resolution
Remove the trailing space


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

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


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


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


* If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached,
modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are
often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal
constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.)


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


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

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.

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

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.

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.

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.

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.

 

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

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

 

12.3.7 Module Class (generic)

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.

 

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.

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.

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

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

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.

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.

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?

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

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

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

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

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"

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"

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"

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.

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.

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

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

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

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.

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.

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.

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

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"

The second problem was edited out in the KDM 1.2

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.

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

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

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)

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"

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"

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.

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.

 

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)

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.

 

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.

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

deferred to next RTF

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

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.

deferred to next RTF

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.

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)

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

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

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

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.

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

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

 

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.

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.

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.

 

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.

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

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 to this issue is provided as part of the resolution to another issue 13294, where a
glossary of terms in introduced.
Disposition: Duplicate

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

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

Related to 11.1

 

"Engineering view", logical view" and "developers view" should be defined

 

Views should have definitions USUALLY as viewpoints

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.

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

 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.

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.

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.

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

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.

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

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.

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

 

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

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

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

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 http://www.omg.org/spec/SBVR/1.0/PDF

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

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

Related to clause:  4.5

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

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

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.

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

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

Related to clause: 6.3

Suggested resolution: Remove subclause 6.3.

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

Suggested resolution: All class constraints must be numbered.

Related to clause: 7 last paragraph

Suggested resolution:

ISO/IEC 11404:2007  Information technology -- General-Purpose Datatypes (GPD)

 

Follow, and consolidate in the normative references

Related to clause: Annex A

Suggested resolution: Annex A may be informative.

 

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. 

deferred to next RTF

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.

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

 

Small typo at 19.3.8

 

“attrbiutes” instead of attributes 

 

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.

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.

 

deferred to next RTF

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

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.

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

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

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.

 

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

12.7.2  StorableUnit Class

StorableUnit class is a concrete subclass of the StorableElement class that represents variables of the existing software 

system.

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.

 

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

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.

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.

 

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

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.

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

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

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.

 

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.

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.

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?

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.

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.

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.

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

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

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'

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.

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