Knowledge Discovery Metamodel Avatar
  1. OMG Specification

Knowledge Discovery Metamodel — Closed Issues

  • Acronym: KDM
  • Issues Count: 149
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
KDM14-306 Change UML model to match specification text regarding MOF enumerations KDM 1.3 KDM 1.4 Resolved closed
KDM14-304 Change MOF XMI version for the specification KDM 1.3 KDM 1.4 Resolved closed
KDM14-302 Revert from Primitivetype back to Datatype in section 9.7 KDM 1.3 KDM 1.4 Resolved closed
KDM14-309 Editorial changes regarding the KDM14-289 text KDM 1.3 KDM 1.4 Resolved closed
KDM14-59 Clarify the meaning of BinaryFile KDM 1.2 KDM 1.4 Duplicate or Merged closed
KDM14-289 Navigability used for code generation KDM 1.3 KDM 1.4 Resolved closed
KDM14-63 mark code element as ordered KDM 1.2 KDM 1.4 Resolved closed
KDM14-60 Standardize naming of InventoryItem children KDM 1.2 KDM 1.4 Resolved closed
KDM14-56 The format of normative references doesn't meet ISO format. (JP-5) KDM 1.1 KDM 1.4 Resolved closed
KDM14-53 AbstractEventElement should group KDM Elements (instead of AbstractCodeElement) KDM 1.0b1 KDM 1.4 Closed; No Change closed
KDM14-49 p.101 (p.79) I don't see the use for the DateType Class KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-48 p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6 KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-47 ISO/IEC 11404" should be "ISO/IEC 11404:1996 KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-46 from:KDMEntity[1] KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-45 to: KDMEntity[1] KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-70 KDM Build package issue KDM 1.3 KDM 1.4 Resolved closed
KDM14-69 Gap in KDM Platform Package KDM 1.3 KDM 1.4 Resolved closed
KDM14-68 BuildResource class diagram KDM 1.3 KDM 1.4 Duplicate or Merged closed
KDM14-67 micro-KDM documentation not updated KDM 1.3 KDM 1.4 Resolved closed
KDM14-66 In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-65 References in KDM for UML, MOF, and XMI are not current KDM 1.3 KDM 1.4 Duplicate or Merged closed
KDM14-64 current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit KDM 1.2 KDM 1.4 Resolved closed
KDM14-37 p.25 (p.3) Confusion KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-36 "Constraints" sub-section in the descriptions seems to be rarely needed KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-35 Page numbers KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-34 Inconsistency in the description of ConceptualRelations diagram KDM 1.1 KDM 1.4 Resolved closed
KDM14-33 RecordFile and Datatypes KDM 1.1 KDM 1.4 Resolved closed
KDM14-32 Clarify alignment of the KDM Core with RDF KDM 1.0 KDM 1.4 Resolved closed
KDM14-30 explicit relationship and the built-in relationships KDM 1.0 KDM 1.4 Resolved closed
KDM14-29 Representation of a stand-alone comment KDM 1.0 KDM 1.4 Resolved closed
KDM14-61 At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow' KDM 1.2 KDM 1.4 Resolved closed
KDM14-58 Change specification to allow stereotyping of Audit elements KDM 1.2 KDM 1.4 Resolved closed
KDM14-57 Change relation endpoint for Audit relation KDM 1.2 KDM 1.4 Resolved closed
KDM14-40 spell out SBVR KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-39 p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model" KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-38 p.31 (p.9) bottom of page KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-27 Assoc. between CompilationUnit and SourceFile other than through SourceRef KDM 1.0 KDM 1.4 Duplicate or Merged closed
KDM14-26 name of CompilationUnit should not contain extension KDM 1.0 KDM 1.4 Resolved closed
KDM14-25 Variable d2 in main compilation unit b.cpp doesn't have aHasValue relation KDM 1.0 KDM 1.4 Resolved closed
KDM14-24 In Initialization example do not need to use extern in the names KDM 1.0 KDM 1.4 Resolved closed
KDM14-23 Initialization block? KDM 1.0 KDM 1.4 Resolved closed
KDM14-44 p.42 (p.20) Constraints sub-section KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-43 p.35 (p.13) "Small KDM core..." -- need description or introduction as to what this is KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-42 p.34 (p.12) Bullet in section 8.2 KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-41 p.33 (p.11) editorial issues KDM 1.1 KDM 1.4 Closed; No Change closed
KDM14-235 Add missing descriptions of properties to KDMEntity KDM 1.3 KDM 1.4 Resolved closed
KDM14-233 Editorial changes to the descriptions of the new top elements KDM 1.3 KDM 1.4 Resolved closed
KDM14-231 Missing subsets inbound, outbound for KDM relationship endpoints KDM 1.3 KDM 1.4 Resolved closed
KDM14-247 Do not add source association to AbstractInventoryItem KDM 1.3 KDM 1.4 Resolved closed
KDM14-245 Add clarification regarding Track element to overview KDM 1.3 KDM 1.4 Resolved closed
KDM14-243 Add owner to Stereotype and TagDefinition KDM 1.3 KDM 1.4 Resolved closed
KDM14-241 Add clarification to Audit element KDM 1.3 KDM 1.4 Resolved closed
KDM14-239 Add clarification to BinaryRegion KDM 1.3 KDM 1.4 Resolved closed
KDM14-237 Clarification to MD5 KDM 1.3 KDM 1.4 Resolved closed
KDM14-31 Clarify the alignment with SBVR KDM 1.0 KDM 1.4 Resolved closed
KDM14-28 variables that are declared at header of loop needs special care in KDM KDM 1.0 KDM 1.4 Resolved closed
KDM14-208 Need a better way to introduce TraceableTo relation KDM 1.3 KDM 1.4 Resolved closed
KDM14-207 Lack of support for SourceRef to a non-plain text resource KDM 1.3 KDM 1.4 Resolved closed
KDM14-205 Missing generic micro action that can represent arbitrary assembly code KDM 1.3 KDM 1.4 Resolved closed
KDM14-192 Add derived operations getParameters and getReturnType to ControlElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-190 Clarify that ActionRelations in ActionElement are ordered KDM 1.3 KDM 1.4 Resolved closed
KDM14-189 Missing ProducesUIEvent relation KDM 1.3 KDM 1.4 Resolved closed
KDM14-188 Missing relation ProducesPlatformEvent KDM 1.3 KDM 1.4 Resolved closed
KDM14-187 Missing description of ProducesDataEvent section KDM 1.3 KDM 1.4 Resolved closed
KDM14-183 Typo: Extra period before example xmi KDM 1.3 KDM 1.4 Resolved closed
KDM14-182 Make IndexUnit for ArrayType optional KDM 1.3 KDM 1.4 Resolved closed
KDM14-178 Need to provide source code for the Visibility example on page 135 KDM 1.3 KDM 1.4 Resolved closed
KDM14-167 Move microKDM "This" from A.4 to A.5 KDM 1.3 KDM 1.4 Resolved closed
KDM14-225 KDM document is missing Datatype overview diagram KDM 1.3 KDM 1.4 Resolved closed
KDM14-223 Replace Templates with TemplateElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-221 Add ExportKind to ClassUnit KDM 1.3 KDM 1.4 Resolved closed
KDM14-214 Ownership of AggregatedRelations is inconsistent KDM 1.3 KDM 1.4 Resolved closed
KDM14-166 KDM does not distinguish between C++ pointer and reference KDM 1.3 KDM 1.4 Resolved closed
KDM14-147 Incorrect microKDM action "InterfaceCall" in example on page 114 KDM 1.3 KDM 1.4 Resolved closed
KDM14-145 Nonexistent class TypeElement mentioned as superclass of TemplateParameter KDM 1.3 KDM 1.4 Resolved closed
KDM14-143 Typo on page 285 "of" into "or" KDM 1.3 KDM 1.4 Resolved closed
KDM14-139 Confusion in the type of the method getCodeElement in ClassUnit KDM 1.3 KDM 1.4 Resolved closed
KDM14-138 KDMFramework ExtensionFamily association name mismatch KDM 1.3 KDM 1.4 Resolved closed
KDM14-137 AbstractInventoryElement association inventoryRelationship mismatch KDM 1.3 KDM 1.4 Resolved closed
KDM14-136 TaggedRef ModelElement association name mismatch KDM 1.3 KDM 1.4 Resolved closed
KDM14-135 Need to include operation getOwnedElement for KDMModel in ecore KDM SDK KDM 1.3 KDM 1.4 Resolved closed
KDM14-134 Make association endpoint from ExtensionFamily to KDMFramework navigable KDM 1.3 KDM 1.4 Resolved closed
KDM14-132 Make owner endpoint of Annotation and Attribute navigable KDM 1.3 KDM 1.4 Resolved closed
KDM14-131 Representation of InventoryItems KDM 1.3 KDM 1.4 Resolved closed
KDM14-128 Correct Bounds of RangeType KDM 1.3 KDM 1.4 Resolved closed
KDM14-118 Incorrect specification of PtrReplace micro-KDM KDM 1.3 KDM 1.4 Resolved closed
KDM14-229 Split InventoryModel Class Diagram KDM 1.3 KDM 1.4 Resolved closed
KDM14-227 Rename new class DeploymentResources into DeploymentElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-81 Missing section in KDM documentation KDM 1.1 KDM 1.4 Resolved closed
KDM14-80 Inconsistency between diagram and description KDM 1.3 KDM 1.4 Resolved closed
KDM14-79 VirtualCall is missing an Addresses KDM 1.3 KDM 1.4 Resolved closed
KDM14-78 Specification of Incr and Decr is ambiguous KDM 1.3 KDM 1.4 Resolved closed
KDM14-77 Missing superclass: StructureGroup KDM 1.3 KDM 1.4 Resolved closed
KDM14-76 Errors in example for micro actions KDM 1.3 KDM 1.4 Resolved closed
KDM14-75 Typo: Optinal should read Optional KDM 1.3 KDM 1.4 Closed; No Change closed
KDM14-74 Incorrect description in AbstractCodeElement codeRelation association KDM 1.3 KDM 1.4 Resolved closed
KDM14-269 Clarify description of BlockUnit KDM 1.3 KDM 1.4 Resolved closed
KDM14-267 Update references to examples in chapter 10 KDM 1.3 KDM 1.4 Resolved closed
KDM14-265 Editorial change in section 10.3.1 KDM 1.3 KDM 1.4 Resolved closed
KDM14-263 Replace ActionRelation with EntryFlow in example of page 165-167 KDM 1.3 KDM 1.4 Resolved closed
KDM14-261 Modify part 2 of the example for micro KDM section KDM 1.3 KDM 1.4 Resolved closed
KDM14-73 AbstractConceptualElement is required to have one and only one role KDM 1.3 KDM 1.4 Resolved closed
KDM14-72 Handling of Java enums KDM 1.3 KDM 1.4 Resolved closed
KDM14-71 If negate is unary it probably doesn't apply to two values KDM 1.3 KDM 1.4 Resolved closed
KDM14-285 Corrections to ClassD example (HasValue) KDM 1.3 KDM 1.4 Resolved closed
KDM14-283 Rename section ParameterKind KDM 1.3 KDM 1.4 Resolved closed
KDM14-281 Correction to Visibility and Comment example source KDM 1.3 KDM 1.4 Resolved closed
KDM14-279 Add reference to example in CommentUnit KDM 1.3 KDM 1.4 Resolved closed
KDM14-277 Corrections to reference example KDM 1.3 KDM 1.4 Resolved closed
KDM14-275 Eidtorial change to TaggedRef 10.6.3 KDM 1.3 KDM 1.4 Resolved closed
KDM14-273 Add explicit ordered to description of ActionElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-271 Clarify semantics of path attribute KDM 1.3 KDM 1.4 Resolved closed
KDM14-257 Remove some associations and constraints from SourceRegion KDM 1.3 KDM 1.4 Resolved closed
KDM14-255 Add description of the new Regions Class Diagram KDM 1.3 KDM 1.4 Resolved closed
KDM14-253 Change superclass of SourceRef and add region association KDM 1.3 KDM 1.4 Resolved closed
KDM14-251 Clarify semantics of ExecutableFile KDM 1.3 KDM 1.4 Resolved closed
KDM14-249 Editorial changes to clarify semantics of URI resolution KDM 1.3 KDM 1.4 Resolved closed
KDM14-287 Corrections to the RecordFile example KDM 1.3 KDM 1.4 Resolved closed
KDM14-22 There is an ambiguity between BlockItem and micro action compound KDM 1.0 KDM 1.4 Resolved closed
KDM14-21 specify which characterset is used for chartype or provide the capability t KDM 1.0 KDM 1.4 Resolved closed
KDM14-19 Call via pointer example: need pointer type in type unit fp KDM 1.0 KDM 1.4 Resolved closed
KDM14-18 PtrCall for callable units and method units a->foo() KDM 1.0 KDM 1.4 Resolved closed
KDM14-16 throws example in the spec is incomplete KDM 1.0 KDM 1.4 Resolved closed
KDM14-15 Validate KDM examples in the KDM specification KDM 1.0 KDM 1.4 Resolved closed
KDM14-14 10.4 would be better to have a proper 'date' type rather than using String KDM 1.0 KDM 1.4 Closed; No Change closed
KDM14-13 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement. KDM 1.0 KDM 1.4 Resolved closed
KDM14-12 9.6: These types should be declared as primitive KDM 1.0 KDM 1.4 Resolved closed
KDM14-10 9.5.1: Property 'density' should be a derived property KDM 1.0 KDM 1.4 Resolved closed
KDM14-9 most operations in the whole specification are redundant KDM 1.0 KDM 1.4 Closed; No Change closed
KDM14-6 Need additional type of UI control elements KDM 1.0b1 KDM 1.4 Closed; No Change closed
KDM14-4 Need Implements relation for BuildDescription KDM 1.0b1 KDM 1.4 Closed; No Change closed
KDM14-2 Need illustration for Platform package KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-1 Need traceability for indirect messages KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-259 Semantics section for initialization blocks goes to BlockUnit KDM 1.3 KDM 1.4 Resolved closed
KDM14-20 consider having a StorableUnit and CallableUnit, maybe with an explicit kind KDM 1.0 KDM 1.4 Deferred closed
KDM14-17 Consider Uniform representation of exception object and classes KDM 1.0 KDM 1.4 Deferred closed
KDM14-11 9.5.1 Semantics: should be expressed in OCL KDM 1.0 KDM 1.4 Deferred closed
KDM14-8 Need ResolvedMarshalledCall element KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-7 Need illustration of runtime context KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-5 Need illustration of logical events KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-3 Need example for reflection in Java KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-54 Component should allow one to express exposed and required services KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-52 KDM is missing constraints capabilities to stereotype KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-51 Section 12 add example KDM 1.1 KDM 1.4 Deferred closed
KDM14-50 p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404. KDM 1.1 KDM 1.4 Deferred closed
KDM14-133 Inconsistent naming of the property "taggedValue" in ModelElement KDM 1.3 KDM 1.4 Deferred closed
KDM14-127 Merge ClassUnit and InterfaceUnit KDM 1.3 KDM 1.4 Deferred closed
KDM14-62 Provide detailed information about dependencies between KDM packages KDM 1.2 KDM 1.4 Deferred closed
KDM14-55 Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews KDM 1.0b1 KDM 1.4 Deferred closed

Issues Descriptions

Change UML model to match specification text regarding MOF enumerations

  • Key: KDM14-306
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 10 Feb 2016 15:26 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Refactor MOF enumerations and update diagrams in the specification

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change MOF XMI version for the specification

  • Key: KDM14-304
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 10 Feb 2016 06:01 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Update example to new version of XMI and KDM

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

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Revert from Primitivetype back to Datatype in section 9.7

  • Key: KDM14-302
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 9 Feb 2016 22:06 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Revert predefined types to MOF datatype

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial changes regarding the KDM14-289 text

  • Key: KDM14-309
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 13 Mar 2016 17:33 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make editorial changes to the specification text

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify the meaning of BinaryFile

  • Key: KDM14-59
  • Legacy Issue Number: 14170
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

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

  • Reported: KDM 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Duplicate or Merged — KDM 1.4
  • Disposition Summary:

    Rename BinaryFile to LinkableFile and clarify semantics

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Navigability used for code generation

  • Key: KDM14-289
  • Legacy Issue Number: 19729
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.3 — Sat, 21 Feb 2015 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify specification text regarding association end ownership

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

mark code element as ordered

  • Key: KDM14-63
  • Legacy Issue Number: 15276
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

  • Reported: KDM 1.2 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add "ordered" to owned CodeElement in Action

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Standardize naming of InventoryItem children

  • Key: KDM14-60
  • Legacy Issue Number: 14171
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

  • Reported: KDM 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Rationalization of InventoryItem

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

    remove ResourceDescription (can't distinguish from ConfigFile)

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

The format of normative references doesn't meet ISO format. (JP-5)

  • Key: KDM14-56
  • Legacy Issue Number: 13826
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to clause: 3

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

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

  • Reported: KDM 1.1 — Tue, 24 Mar 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change format of the normative references and update versions

    Change format of the normative references and update versions

  • Updated: Tue, 12 Jul 2016 14:44 GMT

AbstractEventElement should group KDM Elements (instead of AbstractCodeElement)

  • Key: KDM14-53
  • Legacy Issue Number: 13160
  • Status: closed  
  • Source: Politecnico di Milano ( Matteo Miraz)
  • Summary:

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

  • Reported: KDM 1.0b1 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Proposal does not align with existing mechanisms

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.101 (p.79) I don't see the use for the DateType Class

  • Key: KDM14-49
  • Legacy Issue Number: 12906
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

    This issue has been already closed by KDM RTF 1.3

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6

  • Key: KDM14-48
  • Legacy Issue Number: 12904
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

ISO/IEC 11404" should be "ISO/IEC 11404:1996

  • Key: KDM14-47
  • Legacy Issue Number: 12903
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

from:KDMEntity[1]

  • Key: KDM14-46
  • Legacy Issue Number: 12890
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

to: KDMEntity[1]

  • Key: KDM14-45
  • Legacy Issue Number: 12889
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

KDM Build package issue

  • Key: KDM14-70
  • Legacy Issue Number: 15925
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

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

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

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

  • Reported: KDM 1.3 — Mon, 10 Jan 2011 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add definitions of BuildComponent, BuildProduct, Library

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

    With this interpretation the example on page 306 is correct.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Gap in KDM Platform Package

  • Key: KDM14-69
  • Legacy Issue Number: 15924
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

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

  • Reported: KDM 1.3 — Mon, 10 Jan 2011 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add TraceableTo relation to Inventory model

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

BuildResource class diagram

  • Key: KDM14-68
  • Legacy Issue Number: 15923
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

  • Reported: KDM 1.3 — Mon, 10 Jan 2011 05:00 GMT
  • Disposition: Duplicate or Merged — KDM 1.4
  • Disposition Summary:

    Merge with KDM14-70

    This issue is merged with KDM14-70

  • Updated: Tue, 12 Jul 2016 14:44 GMT

micro-KDM documentation not updated

  • Key: KDM14-67
  • Legacy Issue Number: 15906
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

    MethodCall, VirtualCall, MemberSelect, MemberReplace.

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

  • Reported: KDM 1.3 — Mon, 3 Jan 2011 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change Invokes to Addresses

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-66
  • Legacy Issue Number: 15897
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 13 Dec 2010 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change superclass of MethodUnit to ControlElement

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

References in KDM for UML, MOF, and XMI are not current

  • Key: KDM14-65
  • Legacy Issue Number: 15878
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

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

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

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

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

    Proposed solution:

    In section 3

    Change:

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

    To:

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

  • Reported: KDM 1.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Duplicate or Merged — KDM 1.4
  • Disposition Summary:

    Merge with KDM14-56

    Merge with KDM14-56

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-64
  • Legacy Issue Number: 15277
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

    Some concrete example:

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

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

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

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

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

  • Reported: KDM 1.2 — Mon, 7 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.25 (p.3) Confusion

  • Key: KDM14-37
  • Legacy Issue Number: 12876
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

"Constraints" sub-section in the descriptions seems to be rarely needed

  • Key: KDM14-36
  • Legacy Issue Number: 12874
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Page numbers

  • Key: KDM14-35
  • Legacy Issue Number: 12871
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Already closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Inconsistency in the description of ConceptualRelations diagram

  • Key: KDM14-34
  • Legacy Issue Number: 12866
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.1 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change model to generalize endpoints of ConceptualFlow to AbstractConceptualElement

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

RecordFile and Datatypes

  • Key: KDM14-33
  • Legacy Issue Number: 12481
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

    Suggested resolution: generalize owned elements from ItemUnit to CodeItem.

  • Reported: KDM 1.1 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Illustrate usage of owned ItemUnit as record fields

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify alignment of the KDM Core with RDF

  • Key: KDM14-32
  • Legacy Issue Number: 11739
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Clarify alignment of the KDM Core with RDF

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify text regarding alignment with RDF

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

explicit relationship and the built-in relationships

  • Key: KDM14-30
  • Legacy Issue Number: 11737
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add text to page 27, semantics of KDMRelationship

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Representation of a stand-alone comment

  • Key: KDM14-29
  • Legacy Issue Number: 11736
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify the description of CommentUnit

    The description of the CommentUnit should be clarified.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-61
  • Legacy Issue Number: 14173
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: KDM 1.2 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Multiple corrections in RecordFile example

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change specification to allow stereotyping of Audit elements

  • Key: KDM14-58
  • Legacy Issue Number: 14107
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

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

    “Audit”))

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

    · Move the stereotype relation from ModelElement to Element

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

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

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

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Introduce Core class ExtendableElement and change subclass of Audit

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change relation endpoint for Audit relation

  • Key: KDM14-57
  • Legacy Issue Number: 14106
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

  • Reported: KDM 1.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change audit endpoint to ModelElement

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

spell out SBVR

  • Key: KDM14-40
  • Legacy Issue Number: 12881
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-39
  • Legacy Issue Number: 12879
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.31 (p.9) bottom of page

  • Key: KDM14-38
  • Legacy Issue Number: 12878
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Assoc. between CompilationUnit and SourceFile other than through SourceRef

  • Key: KDM14-27
  • Legacy Issue Number: 11728
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Association between CompilationUnit and SourceFile other than through SourceRef.

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Duplicate or Merged — KDM 1.4
  • Disposition Summary:

    Merged with KDM14-69

    Merged with KDM14-69

  • Updated: Tue, 12 Jul 2016 14:44 GMT

name of CompilationUnit should not contain extension

  • Key: KDM14-26
  • Legacy Issue Number: 11727
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add semantic guideline that the name shall include all extensions

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Variable d2 in main compilation unit b.cpp doesn't have aHasValue relation

  • Key: KDM14-25
  • Legacy Issue Number: 11726
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Correct Init example

    Make corrections to the Init example

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-24
  • Legacy Issue Number: 11725
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Initialization block?

  • Key: KDM14-23
  • Legacy Issue Number: 11723
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Generalize Calls and clarify constraints for init blocks

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

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.42 (p.20) Constraints sub-section

  • Key: KDM14-44
  • Legacy Issue Number: 12887
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-43
  • Legacy Issue Number: 12885
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been closed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.34 (p.12) Bullet in section 8.2

  • Key: KDM14-42
  • Legacy Issue Number: 12884
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

p.33 (p.11) editorial issues

  • Key: KDM14-41
  • Legacy Issue Number: 12883
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    This issue has been disposed in KDM RTF 1.3

    This issue has been disposed as duplicate in KDM RTF 1.3

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add missing descriptions of properties to KDMEntity

  • Key: KDM14-235
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 19:04 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add missing descriptions of properties to KDMEntity

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial changes to the descriptions of the new top elements

  • Key: KDM14-233
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 18:53 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    *Add descriptions of the new top-level elements *

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing subsets inbound, outbound for KDM relationship endpoints

  • Key: KDM14-231
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 17 Feb 2015 17:32 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add subsets inbound, outbound properties to KDM relation endpoints

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Do not add source association to AbstractInventoryItem

  • Key: KDM14-247
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 02:25 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Remove attribute source

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add clarification regarding Track element to overview

  • Key: KDM14-245
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 21:02 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add clarification regarding Track element to overview

    Editorial change

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add owner to Stereotype and TagDefinition

  • Key: KDM14-243
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 20:43 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add owner to Stereotype and TagDefinition

    Add owner to Stereotype and TagDefinition

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add clarification to Audit element

  • Key: KDM14-241
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 20:10 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add clarification to Audit element

    Add clarification to Audit element

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add clarification to BinaryRegion

  • Key: KDM14-239
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 19:53 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add clarification to BinaryRegion

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarification to MD5

  • Key: KDM14-237
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

  • Reported: KDM 1.3 — Thu, 19 Feb 2015 19:47 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add clarifications to the use of MD5 property

    Add clarifications to the use of MD5 property of IntentoryItem:

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify the alignment with SBVR

  • Key: KDM14-31
  • Legacy Issue Number: 11738
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Remove Figure 20.1 and clarify text

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

variables that are declared at header of loop needs special care in KDM

  • Key: KDM14-28
  • Legacy Issue Number: 11733
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Illustrate local variables defined in compound action element

    Add example to Micro KDM section, page 167.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need a better way to introduce TraceableTo relation

  • Key: KDM14-208
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 4 Feb 2015 21:54 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change the endpoint of TraceableTo relation to make it work

    Here is the solution that will work:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Lack of support for SourceRef to a non-plain text resource

  • Key: KDM14-207
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 4 Feb 2015 17:31 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Allow non-text regions in arbitrary InventoryItem

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing generic micro action that can represent arbitrary assembly code

  • Key: KDM14-205
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 2 Feb 2015 23:18 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add derived operations getParameters and getReturnType to ControlElement

  • Key: KDM14-192
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 28 Jan 2015 15:52 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add derived operations getParameters and getReturnType to ControlElement

    Add derived operations getParameters and getReturnType to ControlElement

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify that ActionRelations in ActionElement are ordered

  • Key: KDM14-190
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Wed, 28 Jan 2015 13:39 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Restore "ordered" attribute for owned AbstractActionRelationship

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing ProducesUIEvent relation

  • Key: KDM14-189
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    in UIActions diagram

  • Reported: KDM 1.3 — Tue, 27 Jan 2015 23:24 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add section ProducesUIEvent

    Add section ProducesUIEvent

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing relation ProducesPlatformEvent

  • Key: KDM14-188
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    in PlatformEvents section

  • Reported: KDM 1.3 — Tue, 27 Jan 2015 23:23 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add section ProducesPlatformEvent

    Add section ProducesPlatformEvent

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing description of ProducesDataEvent section

  • Key: KDM14-187
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Missing a subsection in section 18.9 DataAction

  • Reported: KDM 1.3 — Tue, 27 Jan 2015 23:21 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add section ProducesDataEvent

    Add section ProducesDataEvent

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Typo: Extra period before example xmi

  • Key: KDM14-183
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher)
  • Summary:

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

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

  • Reported: KDM 1.3 — Mon, 26 Jan 2015 19:15 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Remove dot for example in Section 13.8.4

    Remove the dot

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Make IndexUnit for ArrayType optional

  • Key: KDM14-182
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 26 Jan 2015 18:09 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make IndexUnit optional as per specification text

    Make IndexUnit optional as per specification text

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need to provide source code for the Visibility example on page 135

  • Key: KDM14-178
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sat, 24 Jan 2015 14:25 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add source for the example

    Add source code to example on page 135

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-167
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 23 Jan 2015 21:57 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

KDM document is missing Datatype overview diagram

  • Key: KDM14-225
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 16 Feb 2015 19:37 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add Datatype class diagram

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Replace Templates with TemplateElement

  • Key: KDM14-223
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 16 Feb 2015 18:32 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Rename new element Templates into TemplateElement

    Rename new element Templates into TemplateElement and make is generic

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add ExportKind to ClassUnit

  • Key: KDM14-221
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 16 Feb 2015 15:09 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add ExportKind to ClassUnit

    Add ExportKind to ClassUnit

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Ownership of AggregatedRelations is inconsistent

  • Key: KDM14-214
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

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

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

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

  • Reported: KDM 1.3 — Fri, 13 Feb 2015 20:54 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make ownership of AggregatedRelations symmetric with explicit relations

    Make ownership of AggregatedRelations symmetric with explicit relations

  • Updated: Tue, 12 Jul 2016 14:44 GMT

KDM does not distinguish between C++ pointer and reference

  • Key: KDM14-166
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

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

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

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

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

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

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

    (*pi)=1;

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

    ri=2;

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

  • Reported: KDM 1.3 — Fri, 23 Jan 2015 21:40 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add example to microKDM chapter

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Incorrect microKDM action "InterfaceCall" in example on page 114

  • Key: KDM14-147
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

  • Reported: KDM 1.3 — Mon, 19 Jan 2015 16:59 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify specification text

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Nonexistent class TypeElement mentioned as superclass of TemplateParameter

  • Key: KDM14-145
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 19 Jan 2015 16:51 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace "TypeElement" with "Datatype" on page 105

    Replace "TypeElement" with "Datatype" on page 105

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Typo on page 285 "of" into "or"

  • Key: KDM14-143
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 19 Jan 2015 16:29 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace "of" into "or"

    • page 285 section 20.5.5 "Additional annotations of stereotypes" -> additional annotations OR stereotypes".
  • Updated: Tue, 12 Jul 2016 14:44 GMT

Confusion in the type of the method getCodeElement in ClassUnit

  • Key: KDM14-139
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 17:02 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

KDMFramework ExtensionFamily association name mismatch

  • Key: KDM14-138
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:59 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Repalce replace "extension" into "extensionFamily"

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

AbstractInventoryElement association inventoryRelationship mismatch

  • Key: KDM14-137
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:58 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace "inventoryRelationship" into "inventoryRelation" on page 54

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

TaggedRef ModelElement association name mismatch

  • Key: KDM14-136
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:54 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace "ref" with "reference" on page 46

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need to include operation getOwnedElement for KDMModel in ecore KDM SDK

  • Key: KDM14-135
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:51 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add getOwnedElement operation to KDMModel

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Make association endpoint from ExtensionFamily to KDMFramework navigable

  • Key: KDM14-134
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:40 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make owner of ExtensionFamily navigable

    Make owner of ExtensionFamily navigable

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Make owner endpoint of Annotation and Attribute navigable

  • Key: KDM14-132
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:35 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make owner endpoint for Annotation and Attribute navigable

    Make owner endpoint for Annotation and Attribute navigable

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Representation of InventoryItems

  • Key: KDM14-131
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

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

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:28 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Define path as URL and add MD5

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Correct Bounds of RangeType

  • Key: KDM14-128
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher)
  • Summary:

    A RangeType is described as:

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

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

  • Reported: KDM 1.3 — Sat, 17 Jan 2015 04:45 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Use Value to determine bounds for a RangeType

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Incorrect specification of PtrReplace micro-KDM

  • Key: KDM14-118
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

  • Reported: KDM 1.3 — Thu, 15 Jan 2015 21:07 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change text in table A.5 for PtrReplace

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Split InventoryModel Class Diagram

  • Key: KDM14-229
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 16 Feb 2015 20:23 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Split InventoryModel Class Diagram

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Rename new class DeploymentResources into DeploymentElement

  • Key: KDM14-227
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 16 Feb 2015 20:02 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    *Rename DeploymentResources into DeploymentElement *

    Rename DeploymentResources into DeploymnetElement and make this class generic

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing section in KDM documentation

  • Key: KDM14-81
  • Legacy Issue Number: 12870
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

    12.3.7 Module Class (generic)

  • Reported: KDM 1.1 — Tue, 30 Sep 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Describe top subclasses for each KDM model

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Inconsistency between diagram and description

  • Key: KDM14-80
  • Legacy Issue Number: 17092
  • Status: closed  
  • Source: Benchmark Canada ( Aboubacar Kaba)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 31 Jan 2012 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

VirtualCall is missing an Addresses

  • Key: KDM14-79
  • Legacy Issue Number: 18779
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

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

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

  • Reported: KDM 1.3 — Fri, 14 Jun 2013 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change constraint for VirtualCall

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Specification of Incr and Decr is ambiguous

  • Key: KDM14-78
  • Legacy Issue Number: 18778
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

    The micro definition for kinds Incr and Decr is ambiguous.

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

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

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

  • Reported: KDM 1.3 — Thu, 13 Jun 2013 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Missing superclass: StructureGroup

  • Key: KDM14-77
  • Legacy Issue Number: 17374
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

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

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

  • Reported: KDM 1.3 — Fri, 18 May 2012 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace StructureGroup into AbstractStructureElement in specification text

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Errors in example for micro actions

  • Key: KDM14-76
  • Legacy Issue Number: 17301
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

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

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

  • Reported: KDM 1.3 — Wed, 11 Apr 2012 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Correct microKDM example

    Multiple corrections of XML on pages 165-167

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Typo: Optinal should read Optional

  • Key: KDM14-75
  • Legacy Issue Number: 17272
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 26 Mar 2012 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Already fixed in KDM 1.3

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Incorrect description in AbstractCodeElement codeRelation association

  • Key: KDM14-74
  • Legacy Issue Number: 17093
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

    The association AbstractCodeElement has the following description:

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

    It should read:

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

  • Reported: KDM 1.3 — Tue, 31 Jan 2012 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change description of AbstractCodeElement

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify description of BlockUnit

  • Key: KDM14-269
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 00:24 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify description of BlockUnit

    Clarify description of BlockUnit

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Update references to examples in chapter 10

  • Key: KDM14-267
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    3 references were incorrect

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 00:14 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Update references to examples in chapter 10

    Update references to examples in chapter 10

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial change in section 10.3.1

  • Key: KDM14-265
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Mon, 23 Feb 2015 23:54 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Editorial change in section 10.3.1

    clarify sentence

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Replace ActionRelation with EntryFlow in example of page 165-167

  • Key: KDM14-263
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Resolution to KDM14-76 has missed this.

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 21:26 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Replace ActionRelation with Entry flow in the microKDM example

    Replace ActionRelation with Entry flow in the origianl microKDM example

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Modify part 2 of the example for micro KDM section

  • Key: KDM14-261
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 21:19 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Modify part 2 of the example

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

AbstractConceptualElement is required to have one and only one role

  • Key: KDM14-73
  • Legacy Issue Number: 16633
  • Status: closed  
  • Source: Benchmark Consulting ( Stephane Vaucher [X] (Inactive))
  • Summary:

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

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

  • Reported: KDM 1.3 — Tue, 25 Oct 2011 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

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

    Allow multiple ConceptualRoles to be associated with the same AbstractConceptualElement

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Handling of Java enums

  • Key: KDM14-72
  • Legacy Issue Number: 16167
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

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

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

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

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

    Thanks for your insight in clarifying this situation.

  • Reported: KDM 1.3 — Thu, 5 May 2011 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clearing up Java Enums

    2 changes: Clarify EnumeratedTypes and use of ClassUnits

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-71
  • Legacy Issue Number: 15979
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

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

    Negate

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

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

  • Reported: KDM 1.3 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change text in table A.2

    Correct description of Negate operation.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Corrections to ClassD example (HasValue)

  • Key: KDM14-285
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:37 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Corrections to ClassD example (HasValue)

    Corrections to ClassD example (HasValue)

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Rename section ParameterKind

  • Key: KDM14-283
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Rename section 12.13.2 ParameterKind Enumeration Datatype
    into ParameterKind (enumeration)

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:30 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Rename section ParameterKind

    Rename section ParameterKind Enumeration Datatype into ParameterKind (enumeration)

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Correction to Visibility and Comment example source

  • Key: KDM14-281
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

    { int foobar ; // Comment to item unit foobar }

    with

    { int // Comment to integer type foobar ; // Comment to item unit foobar }

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:26 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Correction to Visibility and Comment example source

    Correction to Visibility and Comment example source

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add reference to example in CommentUnit

  • Key: KDM14-279
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:21 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add reference to example in CommentUnit

    Add reference to example in CommentUnit

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Corrections to reference example

  • Key: KDM14-277
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:16 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Corrections to reference example

    Corrections to reference example

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Eidtorial change to TaggedRef 10.6.3

  • Key: KDM14-275
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

    Add to editorial note KDM14-58

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:10 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Eidtorial change to TaggedRef 10.6.3

    Eidtorial change to TaggedRef 10.6.3

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add explicit ordered to description of ActionElement

  • Key: KDM14-273
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 00:46 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add explicit ordered to ownedElement in ActionElement

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify semantics of path attribute

  • Key: KDM14-271
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 00:38 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify semantics of path attribute

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Remove some associations and constraints from SourceRegion

  • Key: KDM14-257
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 03:03 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Remove some associations and constraints from SourceRegion

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Add description of the new Regions Class Diagram

  • Key: KDM14-255
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 02:58 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add description of the new Regions Class Diagram

    Add description of the new Regions Class Diagram

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Change superclass of SourceRef and add region association

  • Key: KDM14-253
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 02:50 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Change superclass of SourceRef and add region association

    Change superclass of SourceRef and add region association

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Clarify semantics of ExecutableFile

  • Key: KDM14-251
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 02:44 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify semantics of ExecutableFile

    Clarify semantics of ExecutableFile

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Editorial changes to clarify semantics of URI resolution

  • Key: KDM14-249
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 02:34 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Clarify semantics of URI resolution

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Corrections to the RecordFile example

  • Key: KDM14-287
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Tue, 24 Feb 2015 03:49 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Corrections to the RecordFile example

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

There is an ambiguity between BlockItem and micro action compound

  • Key: KDM14-22
  • Legacy Issue Number: 11721
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add guidelines for BlockUnit

    BlockUnit element is introduced to represent nested statements in systems, while composite ActionElement is a generic mechanism in KDM to manage complex collections of ActionElement, in particular, related to micro-KDM.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

specify which characterset is used for chartype or provide the capability t

  • Key: KDM14-21
  • Legacy Issue Number: 11718
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add charset:String attribute to CharType and String classes

    Add attribute charset:String to CharType and StringType classes. Semantics of charset is aligned with "repertoir-identifier" in ISO 11404 and identifies a character set. If this attribute is omitted, the default characterset is ISO-8859-1.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-19
  • Legacy Issue Number: 11716
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Fix issues in Dispatch example

    Fix Dispatches example on page 149.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

PtrCall for callable units and method units a->foo()

  • Key: KDM14-18
  • Legacy Issue Number: 11714
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add example to microKDM chapter

    Add example to micro KDM chapter, clarifying the use of the corresponding microKDM operations

  • Updated: Tue, 12 Jul 2016 14:44 GMT

throws example in the spec is incomplete

  • Key: KDM14-16
  • Legacy Issue Number: 11710
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    throws example in the spec is incomplete

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Add throws example

    class A {
    void foo() {
    try{
    bar();
    catch(Exception e)

    { println("Something went wrong"); }

    finally

    { println("Good bye"); }

    }
    void bar() throws MoreDescriptiveException{
    try

    { this.arr[20] = 20; println(arr); }

    catch (IndexOutOfBoundsException e)

    { println("Oops"); throw new "went too far" }

    finally

    { println(arr); }

    }

    int[] arr = new int[10]
    }

    Some comments:
    Some of the AbstractCodeElements are BlockUnits. I would have used EntryFlows instead of regular Flows, but that might be a matter of choice.
    1. TryUnit entryFlow> ActionElement[kind='Call'] not required?
    2. I see that we need to create new Exception to send. That's the revision I attached. I did a pass to do the changes, but I hope I got the numbering right (done manually).

    <!-- Create the Exception, no constructor called -->
    <codeElement xmi:id="id.47" xmi:type="action:ActionElement" name="a8" kind="New">
    <codeElement xmi:id="id.48" xmi:type="code:StorableUnit" type="id.67" kind="local"/>
    <actionRelation xmi:id="id.49" xmi:type="action:Creates" to="id.48" from="id.47"/>
    <actionRelation xmi:id="id:50" xmi:type="action:Flow" to="id.50" from="id.47"/>
    </codeElement>

    <!-- Throw statement -->
    <codeElement xmi:id="id.51" xmi:type="action:ActionElement" name="a9" kind="Throw">
    <actionRelation xmi:id="id.52" xmi:type="action:Throws" from="id.51" to="id.48"/>
    </codeElement>

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Validate KDM examples in the KDM specification

  • Key: KDM14-15
  • Legacy Issue Number: 11709
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Update examples

    Fix few minor issues and update the KDM URL to 1.4

  • Updated: Tue, 12 Jul 2016 14:44 GMT

10.4 would be better to have a proper 'date' type rather than using String

  • Key: KDM14-14
  • Legacy Issue Number: 11181
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Keep date represented as String

    CMOF does not have a primitive type for a "date". The current representation as String allows some flexibility to the implementations. Yet, the specification of the format is unambiguous (if restrictive). Date is only used in Audit element.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-13
  • Legacy Issue Number: 11178
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Rename abstract class KDMFramework into FrameworkElement

    Rename abstract class KDMFramework into FrameworkElement

  • Updated: Tue, 12 Jul 2016 14:44 GMT

9.6: These types should be declared as primitive

  • Key: KDM14-12
  • Legacy Issue Number: 11177
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    *Change stereotype from datatype into primitive *

    Change stereotype from datatype into primitive. This makes KDM core consistent with the UML Infrastructure specification. However, the exact origin of these stereotypes and their semantics is rather unclear. In fact, the UML Infrastructure document never explains where the stereotypes are imported from. This is likely because they were using a Visio stencil to produce some of the diagrams. However, the intended representation in CMOF is that of an instance of PrimitiveType, as in the current KDM. Go figure.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

9.5.1: Property 'density' should be a derived property

  • Key: KDM14-10
  • Legacy Issue Number: 11174
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Make property density derived

    Make property density derived

  • Updated: Tue, 12 Jul 2016 14:44 GMT

most operations in the whole specification are redundant

  • Key: KDM14-9
  • Legacy Issue Number: 11167
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Keep the operations that correspond to derived properties

    Keep the operations that correspond to derived properties. These operations are defined in packages Core and Kdm. They represent the high-level api to the kdm models. Since each model redefines and/or subsets some of these derived properties to provide a large, strongly typed api, that determines the structure of the XMI, the high-level properties are only represented by the operations.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need additional type of UI control elements

  • Key: KDM14-6
  • Legacy Issue Number: 10297
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    No need for additional UI elements

    There is no need for additional UI elements

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need Implements relation for BuildDescription

  • Key: KDM14-4
  • Legacy Issue Number: 10291
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.4
  • Disposition Summary:

    Does not fit the current design

    In current KDM a model is simply a container of facts. There are currently no relations involving models. A BuildDescription represents transformation, and there is a relation DescribedBy to BuildStep.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need illustration for Platform package

  • Key: KDM14-2
  • Legacy Issue Number: 10135
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Wed, 23 Aug 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need traceability for indirect messages

  • Key: KDM14-1
  • Legacy Issue Number: 9995
  • Status: closed  
  • Source: International Business Machines ( Howard Hess)
  • Summary:

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

  • Reported: KDM 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Semantics section for initialization blocks goes to BlockUnit

  • Key: KDM14-259
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Fri, 20 Feb 2015 21:08 GMT
  • Disposition: Resolved — KDM 1.4
  • Disposition Summary:

    Place paragraph describing semantics of initialization blocks to BlockUnit section

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

consider having a StorableUnit and CallableUnit, maybe with an explicit kind

  • Key: KDM14-20
  • Legacy Issue Number: 11717
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Consider Uniform representation of exception object and classes

  • Key: KDM14-17
  • Legacy Issue Number: 11711
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0 — Sat, 1 Dec 2007 05:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5 to allow more substantial discussion.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

9.5.1 Semantics: should be expressed in OCL

  • Key: KDM14-11
  • Legacy Issue Number: 11176
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    9.5.1 Semantics: should be expressed in OCL

  • Reported: KDM 1.0 — Mon, 23 Jul 2007 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need ResolvedMarshalledCall element

  • Key: KDM14-8
  • Legacy Issue Number: 10319
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need illustration of runtime context

  • Key: KDM14-7
  • Legacy Issue Number: 10306
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need illustration of logical events

  • Key: KDM14-5
  • Legacy Issue Number: 10293
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Need example for reflection in Java

  • Key: KDM14-3
  • Legacy Issue Number: 10288
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Sun, 3 Sep 2006 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Component should allow one to express exposed and required services

  • Key: KDM14-54
  • Legacy Issue Number: 13161
  • Status: closed  
  • Source: Politecnico di Milano ( Matteo Miraz)
  • Summary:

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

  • Reported: KDM 1.0b1 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

KDM is missing constraints capabilities to stereotype

  • Key: KDM14-52
  • Legacy Issue Number: 13159
  • Status: closed  
  • Source: Politecnico di Milano ( Matteo Miraz)
  • Summary:

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

  • Reported: KDM 1.0b1 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defered to KDM 1.5

    More information is needed for the use case.
    It is possible to add two attributes to Stereotype:
    constraint:String - optional expression of the constraint for the stereotype and the stereotyped elements
    language:String - the language in which the constraint is expressed, e.g. OCL
    Consumers of KDM can take advantage of this information.
    However this can be achieved with current KDM through Attributes.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Section 12 add example

  • Key: KDM14-51
  • Legacy Issue Number: 12909
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defered to KDM 1.5

    Additional cycle will be required to evaluate the need for more examples

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-50
  • Legacy Issue Number: 12907
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

  • Reported: KDM 1.1 — Wed, 24 Sep 2008 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    *Rename FloatType class into RealType *

    Rename FloatType into RealType to align with ISO 11404.

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Inconsistent naming of the property "taggedValue" in ModelElement

  • Key: KDM14-133
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.3 — Sun, 18 Jan 2015 16:37 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Rename taggedValue propoerty into extendedValue

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Merge ClassUnit and InterfaceUnit

  • Key: KDM14-127
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    This issue is related to KDM14-20

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

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

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

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

  • Reported: KDM 1.3 — Fri, 16 Jan 2015 23:44 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

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

  • Updated: Tue, 12 Jul 2016 14:44 GMT

Provide detailed information about dependencies between KDM packages

  • Key: KDM14-62
  • Legacy Issue Number: 15129
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.2 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Defer to KDM 1.5

    Defer to KDM 1.5

  • Updated: Tue, 12 Jul 2016 14:44 GMT

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

  • Key: KDM14-55
  • Legacy Issue Number: 13162
  • Status: closed  
  • Source: Politecnico di Milano ( Matteo Miraz)
  • Summary:

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

  • Reported: KDM 1.0b1 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Deferred — KDM 1.4
  • Disposition Summary:

    Missing constraints on Structure package elements

    Assigning constraints for elements of the structure package is probably beyond the scope of a revision. I do not see the KDM as being a replacement for architecture meta-models, but rather as a connection to a separate architecture representation much like the conceptual package's connection to SBVR (to link to code artifacts for aggregate analysis).

  • Updated: Tue, 12 Jul 2016 14:44 GMT