1. OMG Mailing List
  2. ADM KDM 1.5 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: kdm-rtf
  • Issues Count: 242

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
KDM13-20 References in KDM for UML, MOF, and XMI are not current KDM 1.2 KDM 1.3 Resolved closed
KDM11-13 Break cyclic dependency between Code and Action package KDM 1.0b1 KDM 1.1 Resolved closed
KDM11-19 9.4.2 - why 2 separate associations? KDM 1.0 KDM 1.1 Resolved closed
KDM11-18 9.4.1 - CMOF “redefines” mechanism KDM 1.0 KDM 1.1 Resolved closed
KDM11-17 9.3.3 getOwnerElement is misnamed KDM 1.0 KDM 1.1 Resolved closed
KDM11-16 9.3.3 Constraint 1 seems wrong KDM 1.0 KDM 1.1 Resolved closed
KDM11-15 9.3.3, association 'group' KDM 1.0 KDM 1.1 Resolved closed
KDM11-14 9.3.3 definition of owner KDM 1.0 KDM 1.1 Resolved closed
KDM11-25 Consider representation of a switch KDM 1.0 KDM 1.1 Resolved closed
KDM11-24 10.4.1: Audit.description KDM 1.0 KDM 1.1 Resolved closed
KDM11-23 10.4: use of 'author' is redundant KDM 1.0 KDM 1.1 Resolved closed
KDM11-22 p31 the XMI example has wrong namespaces for xmi and kdm and audit KDM 1.0 KDM 1.1 Resolved closed
KDM11-21 10.3.1: Description of 'segment' property KDM 1.0 KDM 1.1 Resolved closed
KDM11-20 9.5.1 Constraint 4 is inconsistent KDM 1.0 KDM 1.1 Resolved closed
KDM11-41 associations with duplicated names in the same package KDM 1.0 KDM 1.1 Resolved closed
KDM11-40 "Segments" assocation on the kdm::Segment class KDM 1.0 KDM 1.1 Resolved closed
KDM11-39 upper bound of the container end of a composition shown as unbounded KDM 1.0 KDM 1.1 Resolved closed
KDM11-38 case of a property name duplication KDM 1.0 KDM 1.1 Resolved closed
KDM11-37 There is a problem with Throws relation and Throw micro operation KDM 1.0 KDM 1.1 Resolved closed
KDM11-36 Description of the multidimentional arrays is confusing. KDM 1.0 KDM 1.1 Resolved closed
KDM11-35 representation of this-> and this KDM 1.0 KDM 1.1 Resolved closed
KDM11-34 change text for the arrayselect "single" reads KDM 1.0 KDM 1.1 Resolved closed
KDM11-33 text should mention optional writes in micro kdm and an example with a+1; KDM 1.0 KDM 1.1 Resolved closed
KDM11-32 Need to make Datatype generic, for the sake of using it in with stereotypes KDM 1.0 KDM 1.1 Resolved closed
KDM11-31 More than one label on a statement KDM 1.0 KDM 1.1 Resolved closed
KDM11-30 Discuss using the name of the action element as label KDM 1.0 KDM 1.1 Resolved closed
KDM11-29 Correct specification text: KDM 1.0 KDM 1.1 Resolved closed
KDM11-28 representation of the sizeof (type) operator as opposed to sizeof (expr) op KDM 1.0 KDM 1.1 Resolved closed
KDM11-27 Add uppercase requirement for the names of micro KDM operations KDM 1.0 KDM 1.1 Resolved closed
KDM11-26 Need a counterpart of the HasValue relation KDM 1.0 KDM 1.1 Resolved closed
KDM13-19 There should be no references from lower KDM layers to higher layers KDM 1.2 KDM 1.3 Resolved closed
KDM13-18 15.5.5 FileResource Class KDM 1.2 KDM 1.3 Resolved closed
KDM13-17 StorableUnit is not a subclass of StorableElement (anymore) KDM 1.2 KDM 1.3 Resolved closed
KDM13-16 'DataUnit' incorrectly used instead of 'DataElement' KDM 1.2 KDM 1.3 Resolved closed
KDM13-15 Cobol code erroneously says "PERFROM" instead of "PERFORM" KDM 1.2 KDM 1.3 Resolved closed
KDM13-14 Small typo at 19.3.8 KDM 1.2 KDM 1.3 Resolved closed
KDM13-13 Wrong class mentioned KDM 1.2 KDM 1.3 Resolved closed
KDM12-68 Annex must be either “normative” or “informative”. Specify it. (JP-12) KDM 1.1 KDM 1.2 Resolved closed
KDM12-67 The title of ISO/IEC 11401 is incorrect. (JP-11) KDM 1.1 KDM 1.2 Resolved closed
KDM12-66 Some class constraints are numbered, but others are not. Unify them. (JP-10) KDM 1.1 KDM 1.2 Resolved closed
KDM12-65 Acknowledgements are not specification. (JP-9) KDM 1.1 KDM 1.2 Resolved closed
KDM12-64 ISO standard documents are described with "shall", "should" and "may" (JP-8) KDM 1.1 KDM 1.2 Resolved closed
KDM12-26 p.32 (p.10) "Analyst is able to refactor the model..." bullet should be changed KDM 1.1 KDM 1.2 Resolved closed
KDM12-25 p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer" KDM 1.1 KDM 1.2 Resolved closed
KDM12-24 p. 25 editorial comment KDM 1.1 KDM 1.2 Resolved closed
KDM12-23 general information/comments KDM 1.1 KDM 1.2 Resolved closed
KDM12-22 Clarification on KDM package - kdm package/ Core - core etc needed KDM 1.1 KDM 1.2 Resolved closed
KDM12-21 SourceRef in Build package KDM 1.1 KDM 1.2 Resolved closed
KDM12-20 kinds for resource actions KDM 1.1 KDM 1.2 Resolved closed
KDM12-19 BindsTo relationship should have a more general “to” endpoint KDM 1.1 KDM 1.2 Resolved closed
KDM12-18 Several association ends are both 0..* and composite owners KDM 1.1 KDM 1.2 Resolved closed
KDM12-17 Many associations and association ends are given meaningless generated name KDM 1.1 KDM 1.2 Resolved closed
KDM12-16 Association A.62 KDM 1.1 KDM 1.2 Resolved closed
KDM12-15 Rename these associations to SignatureType and SourceFileRegion respectivel KDM 1.1 KDM 1.2 Resolved closed
KDM12-14 CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI KDM 1.1 KDM 1.2 Resolved closed
KDM12-13 invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI KDM 1.1 KDM 1.2 Resolved closed
KDM12-49 Clarify the usage of ‘view’ (rh-6) KDM 1.1 KDM 1.2 Resolved closed
KDM12-48 Need to clarify the use of term ‘view’ and align with ISO (rh-5) KDM 1.1 KDM 1.2 Resolved closed
KDM12-47 Missing definition of software asset (rh-4) KDM 1.1 KDM 1.2 Resolved closed
KDM12-46 Missing definitions of terms (rh-3) KDM 1.1 KDM 1.2 Resolved closed
KDM12-45 Alignment with the ISO concept of architecture view (rh-2) KDM 1.1 KDM 1.2 Resolved closed
KDM12-44 p. 113 (p.91) Change "return KDM 1.1 KDM 1.2 Resolved closed
KDM12-43 p.104 (p.82) "...defined datatype Octet String." -- "String" should be "string" KDM 1.1 KDM 1.2 Resolved closed
KDM12-42 p.88 (p.66) Suggest changing wording KDM 1.1 KDM 1.2 Resolved closed
KDM12-41 Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents KDM 1.1 KDM 1.2 Resolved closed
KDM12-40 p. 178 (p. 154) Semantics KDM 1.1 KDM 1.2 Resolved closed
KDM12-39 p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name KDM 1.1 KDM 1.2 Resolved closed
KDM12-59 Interchange format in compliance statement (JP-2) KDM 1.1 KDM 1.2 Resolved closed
KDM12-58 This document doesn't define the common interchange format (JP-1). KDM 1.1 KDM 1.2 Resolved closed
KDM12-57 Build Package in Abstract Layer (page 280-281). KDM 1.1 KDM 1.2 Resolved closed
KDM12-56 Align ‘ArchitectureView element with ISO (rh-13) KDM 1.1 KDM 1.2 Resolved closed
KDM12-55 Align structure package with ISO 42010 (rh-12) KDM 1.1 KDM 1.2 Resolved closed
KDM12-54 Missing definitions for ‘Engineering view’, ‘logical view’ and ‘developers view’ (rh-11) KDM 1.1 KDM 1.2 Resolved closed
KDM12-53 Align KDM Package with ISO Architecture Views (rh-10) KDM 1.1 KDM 1.2 Resolved closed
KDM12-52 Align structure package with ISO 42010 (rh-9) KDM 1.1 KDM 1.2 Resolved closed
KDM12-51 Reference ISO terminology (rh-8) KDM 1.1 KDM 1.2 Resolved closed
KDM12-50 Clarify the intent of KDM ontology (rh-7) KDM 1.1 KDM 1.2 Resolved closed
KDM12-63 Relationships between packages (JP-7) KDM 1.1 KDM 1.2 Resolved closed
KDM12-62 There is no terms ,definitions and symbols. (JP-6) KDM 1.1 KDM 1.2 Resolved closed
KDM12-61 Normative references (JP-4) KDM 1.1 KDM 1.2 Resolved closed
KDM12-60 Compliance levels (JP-3) KDM 1.1 KDM 1.2 Resolved closed
KDM12-38 p. 177 (p. 153) -- last line should be reordered KDM 1.1 KDM 1.2 Resolved closed
KDM12-37 p. 178 (p. 154) -- Inputs bullet -- should be "Ordered incoming..." not "Ordered outgoing..." KDM 1.1 KDM 1.2 Resolved closed
KDM12-36 p.69 (p.47) Section 11.3.6, 7, 8, 9, 10 KDM 1.1 KDM 1.2 Resolved closed
KDM12-35 p.69 (p.47) in the Semantics section KDM 1.1 KDM 1.2 Resolved closed
KDM12-34 p. 65/66 editorial issues KDM 1.1 KDM 1.2 Resolved closed
KDM12-33 p.53 (p.31) Section 10.4.2 KDM 1.1 KDM 1.2 Resolved closed
KDM12-32 p.52 (p.30) date:String and constraints KDM 1.1 KDM 1.2 Resolved closed
KDM12-31 Editorial issues p 47 through 51 KDM 1.1 KDM 1.2 Resolved closed
KDM12-30 p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work KDM 1.1 KDM 1.2 Resolved closed
KDM12-29 p. 43 (p.21) descriptions of items KDM 1.1 KDM 1.2 Resolved closed
KDM12-28 p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1) KDM 1.1 KDM 1.2 Resolved closed
KDM12-27 p.33 Figure 8.1 -- "Actions" should be "Action" KDM 1.1 KDM 1.2 Resolved 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

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

  • Key: KDM13-20
  • Legacy Issue Number: 15872
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:

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

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

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

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

    Proposed solution:

    In section 3

    Change:

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

    To:

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

  • Reported: KDM 1.2 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Replace Normative References section 3, page 6, with the following:
    The following normative documents contain provisions, which, through reference in this
    text, constitute provisions of this specification. For dated references, subsequent
    amendments to or revisions of any of these publications do not apply.
    • OMG UML Infrastructure Specification, ver. 2.3, formal/2010-05-03
    • OMG Meta Object Facility (MOF) Specification, ver. 2.0, formal/06-01-01
    • OMG MOF XML Metadata Interchange (XMI) Specification, ver. 2.1, formal/05-09-01
    • OMG Semantics of Business Vocabularies and Business Rules (SBVR) Specification,
    ver. 1.0, formal/08-01-02
    • ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)

  • Updated: Sun, 8 Mar 2015 13:51 GMT

Break cyclic dependency between Code and Action package

  • Key: KDM11-13
  • Legacy Issue Number: 10123
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

  • Reported: KDM 1.0b1 — Tue, 22 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    The current framework is working fine.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.4.2 - why 2 separate associations?

  • Key: KDM11-19
  • Legacy Issue Number: 11173
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.4.1 - CMOF “redefines” mechanism

  • Key: KDM11-18
  • Legacy Issue Number: 11172
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    9.4.1: "In KDM this is represented by the CMOF “redefines” mechanism. Concrete properties redefine the “union” properties of the parent classes, defined in the Core package." However by using

    {redefines}

    and not

    {subsets}

    it is largely defeating the point of using a derived union - since redefines makes the derived end unavailable!

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

    Page 19, 9.4.1 in “to” association replace “redefines” mechanism “ with “subsets” mechanism
    Page 19, 9.4.1 in “from” association replace “redefines” mechanism “ with “subsets” mechanism

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.3 getOwnerElement is misnamed

  • Key: KDM11-17
  • Legacy Issue Number: 11171
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    9.3.3 getOwnerElement is misnamed - should be getOwnedElement.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.3 Constraint 1 seems wrong

  • Key: KDM11-16
  • Legacy Issue Number: 11170
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    Page 17, 9.3.3 delete constraint 1

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.3, association 'group'

  • Key: KDM11-15
  • Legacy Issue Number: 11169
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.3 definition of owner

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consider representation of a switch

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

10.4.1: Audit.description

  • Key: KDM11-24
  • Legacy Issue Number: 11183
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

10.4: use of 'author' is redundant

  • Key: KDM11-23
  • Legacy Issue Number: 11182
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: KDM11-22
  • Legacy Issue Number: 11180
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

10.3.1: Description of 'segment' property

  • Key: KDM11-21
  • Legacy Issue Number: 11179
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.5.1 Constraint 4 is inconsistent

  • Key: KDM11-20
  • Legacy Issue Number: 11175
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

associations with duplicated names in the same package

  • Key: KDM11-41
  • Legacy Issue Number: 13399
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

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

  • Reported: KDM 1.0 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    The full list of 16 associations with duplicate names from Gene Mutschler on 26-02-
    2009:
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_itemUnit.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::code: A_owner_codeElement.
    Duplicate association in package: Logical View::KDM::data: A_owner_contentElement.
    Duplicate association in package: Logical View::KDM::data: A_owner_contentElement.
    Duplicate association in package: Logical View::KDM::data: A_group_implementation.
    Duplicate association in package: Logical View::KDM::data: A_owner_dataElement.
    Duplicate association in package: Logical View::KDM::event: A_owner_eventElement.
    Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement.
    Duplicate association in package: Logical View::KDM::platform: A_owner_platformElement.
    Duplicate association in package: Logical View::KDM::ui: A_owner_uiElement.
    To disambiguate the association names, the rule for producing CMOF association should
    be changed into
    "A_" <class-name1> "_" <association-end-name2>
    When these rules are applied, unambiguous association names are
    produced. For example, for the association owner-code element owned by
    Module, the following CMOF is produced:
    <ownedMember xmi:id='A_58' xmi:type='cmof:Association'
    memberEnd='P_O_29311055 P_D_29311055' name='A_Module_codeElement'
    general='A_1'>
    <ownedEnd xmi:id='P_D_29311055' xmi:type='cmof:Property'
    subsettedProperty='P_D_9252407' type='C_18297765' name='owner'
    lower='0' upper='1' isComposite='false' association='A_58' />
    </ownedMember>
    <ownedMember xmi:id='C_18297765' xmi:type='cmof:Class'
    name='Module' superClass='C_8898472' isAbstract='false' > <ownedAttribute xmi:id='P_O_29311055' xmi:type='cmof:Property'
    isOrdered='true' subsettedProperty='P_O_9252407' type='C_13966896'
    name='codeElement' lower='0' upper='*' isComposite='true'
    association='A_58' />
    </ownedMember>
    This change is performed automatically in the process of converting the
    UML Rose diagrams into CMOF. The unique ids of the cmof elements may
    change during the conversion.
    Add new section before section 6.3 Acknowledgements, page 7 that explicitly defines the naming
    conventions for mechanical production of CMOF definition of KDM from UML diagrams:

    6.2.1. Diagram format
    Metamodel diagrams in this specification are used to mechanically produce the MOF definition of
    KDM, and the corresponding KDM XMI schema. The following conventions are adopted for all
    metamodel diagrams throughout this specification:
    • An association with one end marked by a navigability arrow means that:
    o the association is navigable in the direction of that end,
    o the marked association end is owned by the classifier, and
    o the opposite (unmarked) association end is owned by the association.
    • An association with neither end marked by navigability arrows means that:
    o the association is navigable in both directions,
    o each association end is owned by the classifier at the opposite end (i.e.,
    neither end is owned by the association).
    .. Additionally, properties “owner”, “group” and “model” are automatically
    renamed to ownerProperty, groupProperty and modelProperty
    respectively.
    • Association specialization and redefinition are indicated by appropriate constraints
    situated in the proximity of the association ends to which they apply. Thus:
    o The constraint

    {subsets endA}

    means that the association end to which this
    constraint is applied is a specialization of association end endA that is part of the
    association being specialized.
    o A constraint

    {redefines endA}

    means that the association end to which this
    constraint is applied redefines the association end endA that is part of the
    association being specialized.
    • Derived union is indicated by placing constraint

    {union}

    in the proximity of the association
    end to which it applies. The corresponding association endpoint is marked as derived and
    read only.
    • If an association end is unlabeled, the default name for that end is the name of the
    class to which the end is attached, modified such that the first letter is a lowercase
    letter. In addition, if the name of the class to which the end is attached starts has a
    meaningful prefix of uppercase letters, for example XMLxxxx, KDMxxx,
    UIxxxx, the entire uppercase prefix is modified to become lowercase. For
    example, the above words become xmlxxxx, kdmxxx, uixxxx. (Note that, by
    convention, non-navigable association ends are often left unlabeled since, in general,
    there is no need to refer to them explicitly either in the text or in formal constraints –
    although there may be needed for other purposes, such as MOF language bindings that
    use the metamodel.)
    o Unlabeled association ends attached to the class KDM Entity which
    correspond to KDM Relationships are additionally prefixed with “in” or
    “out” according to the direction of the relationship. The corresponding properties at the KDM Relationship class side are "to" and "from". For
    example, association ends for the ActionElement class corresponding to
    the associations to ControlFlow class are named “inControlFlow” (the
    counterpart of the “to” endpoint from the ControlFlow side) and
    “outControlFlow” (the counterpart of the “from” endpoint from the
    ControlFlow side)
    • Associations that are not explicitly named, are given names that are constructed
    according to the following production rule:
    "A_" <class-name1> "_" <association-end-name2>
    where <class-name1> is the name of the class that owns the first association end
    and <association-end-name2> is the name of the second association end

  • Updated: Fri, 6 Mar 2015 20:57 GMT

"Segments" assocation on the kdm::Segment class

  • Key: KDM11-40
  • Legacy Issue Number: 13398
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

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

  • Reported: KDM 1.0 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: KDM11-39
  • Legacy Issue Number: 13397
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

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

  • Reported: KDM 1.0 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

case of a property name duplication

  • Key: KDM11-38
  • Legacy Issue Number: 13396
  • Status: closed  
  • Source: Adaptive ( Gene Mutschler)
  • Summary:

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

  • Reported: KDM 1.0 — Fri, 30 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is a problem with Throws relation and Throw micro operation

  • Key: KDM11-37
  • Legacy Issue Number: 11735
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Description of the multidimentional arrays is confusing.

  • Key: KDM11-36
  • Legacy Issue Number: 11734
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

representation of this-> and this

  • Key: KDM11-35
  • Legacy Issue Number: 11732
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

change text for the arrayselect "single" reads

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

    change text for the arrayselect "single" reads

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

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

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

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

    resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

More than one label on a statement

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

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

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

    This is addressed by the resolution to another issue 11722.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Discuss using the name of the action element as label

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correct specification text:

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

representation of the sizeof (type) operator as opposed to sizeof (expr) op

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add uppercase requirement for the names of micro KDM operations

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need a counterpart of the HasValue relation

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

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

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

There should be no references from lower KDM layers to higher layers

  • Key: KDM13-19
  • Legacy Issue Number: 15305
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In the preface to part III we have the following:

    KDM is designed in such a way that the Resource level analysis can use KDM models from the Platform Elements Layer as input and produce Resource Layer models as output. There should be no references from lower KDM layers to higher layers; therefore, new Resource Layer models can be built on top of existing Program Element layer models.

    Couple of points:

    1. There is no “Platform Elements Layer”. As shown in the next sentence it should probably read “Program Elements Layer” which is part II.

    2. The 2 places where it refers to “Resource Layer” might be renamed to “Runtime Resources Layer” to better match the part title.

  • Reported: KDM 1.2 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 159, replace “commpon properties of the Resource Layer” with “common properties of the
    Runtime Resources Layer”
    (After bullets) Replace “Since Resource Layer” with “Since “Runtime Resources Layer”
    Replace “a way that the Resource Layer” with “a way that the Runtime Resources Layer”
    Replace “produce Resource Layer models” with “produce Runtime Resources Layer
    models”
    Replace “new Resource Layer models” with “new Runtime Resources Layer models”
    Replace “Platform Elements Layer as input” with “Program Elements Layer as input”
    Replace “Resource Layer package systematically: with “Packages of the Runtime
    Resources Layer”
    Bullet 1 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Bullet 2 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Bullet 2 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines”
    Replace “modularity between Resource Layer packages” with “modularity between
    KDM packages”
    Page 160
    Bullet 5 replace “elements of Resource Layer package” with “elements of Runtime
    Resources Layer package”
    Bullet 6 replace “Each Resource Layer package defines” with “Each Runtime Resources
    Layer package defines” After bullets: replace “Resource Layer packages are independent” with “Runtime
    Resources Layer packages are independent”
    Replace “action containers in Resource Layer models” with “action containers in
    Runtime Resources Layer models”
    In the next bulleted list replace “Resource Layer patterns” with “Runtime Resources
    Layer patterns”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

15.5.5 FileResource Class

  • Key: KDM13-18
  • Legacy Issue Number: 15304
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In the following paragraph, the DataInterface has been gone since 2006, so maybe we just want to remove the last sentence or reword it to refer to the PlatformActions.

    15.5.5 FileResource Class

    FileResource represents platform resources that provide any non-database related storage. In the meta-model the

    FileResource class is a subclass of ResourceType. It also implements the DataInterface so that this class can be the

    endpoint of Data relations.

  • Reported: KDM 1.2 — Fri, 25 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 170, delete sentence “It also implements the DataInterface so that this class can be the
    endpoint of Data relations.”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

StorableUnit is not a subclass of StorableElement (anymore)

  • Key: KDM13-17
  • Legacy Issue Number: 15273
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    12.7.2 StorableUnit Class

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

    system.

  • Reported: KDM 1.2 — Fri, 4 Jun 2010 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

'DataUnit' incorrectly used instead of 'DataElement'

  • Key: KDM13-16
  • Legacy Issue Number: 14572
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

  • Reported: KDM 1.2 — Mon, 19 Oct 2009 04:00 GMT
  • Disposition: Resolved — KDM 1.3
  • Disposition Summary:

    Page 296, A.4 replace “DataUnit” with “DataElement” (2 times)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: KDM13-15
  • Legacy Issue Number: 14172
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

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

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

    Page 222, replace “perfrom” with “perform”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Small typo at 19.3.8

  • Key: KDM13-14
  • Legacy Issue Number: 14109
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Small typo at 19.3.8

    “attrbiutes” instead of attributes

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

    Page 258, 19.3.8 replace “attrbuites” with “attributes”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong class mentioned

  • Key: KDM13-13
  • Legacy Issue Number: 14108
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    In 10.5.1, Stereotype class, it says that: “In the meta-model the Stereotype is a subclass of ModelElement.”

    This should read as: “In the meta-model the Stereotype is a subclass of Element.”

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

    10.5.1. replace “In the meta-model the Stereotype is a subclass of ModelElement” with
    “In the meta-model the Stereotype is a subclass of Element”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Annex must be either “normative” or “informative”. Specify it. (JP-12)

  • Key: KDM12-68
  • Legacy Issue Number: 13833
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to clause: Annex A

    Suggested resolution: Annex A may be informative.

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

    Annex A is normative.
    Add the word (normative) to section title Annex A – Semantics of the Micro KDM Action Elements
    (normative).
    Add word normative to the first sentence of the section:
    This normative annex defines..

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The title of ISO/IEC 11401 is incorrect. (JP-11)

  • Key: KDM12-67
  • Legacy Issue Number: 13832
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to clause: 7 last paragraph

    Suggested resolution:

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

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

    Make the following changes to the text:
    Page 10
    Change “KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR” into
    KDM is aligned with ISO/IEC 11404 General-Purpose Datatypes and OMG Semantics of Business
    Vocabularies and Business Rules (SBVR)
    Page 57
    Change “Data representation of KDM is aligned with ISO/IEC 11404 (Language-
    Independent datatypes) standard.” Into
    Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard.
    Pages 76, 77, 79, 80, 81, 82, 83, 84, 85, 87, 88, 89, 90, 91, 93, 95
    Change ISO/IEC 11404:1996 into ISO/IEC 11404
    Page 77
    Change “Data representation of KDM is aligned with ISO/IEC 11404 (Language-Independent datatypes)
    standard.” Into
    Data representation of KDM is aligned with ISO/IEC 11404 (General-Purpose Datatypes) standard.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some class constraints are numbered, but others are not. Unify them. (JP-10)

  • Key: KDM12-66
  • Legacy Issue Number: 13831
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Suggested resolution: All class constraints must be numbered.

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

    Remove all empty Constraints sections
    Add numbers to constraints in section 9.4.2, page 20
    Add numbers to constraints in section 10.6.2, page 39
    Add numbers to constraints in section 11.6.1, page 52
    Add numbers to constraints in section 11.6.2, page 54
    Add numbers to constraints in section 13.5.2, page 134
    Add numbers to constraints in section 13.5.4, page 135
    Add numbers to constraints in section 13.5.5, page 136
    Add numbers to constraints in section 13.5.6, page 137
    Add numbers to constraints in section 16.5.1, page 187
    Add numbers to constraints in section 16.5.2, page 187

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Acknowledgements are not specification. (JP-9)

  • Key: KDM12-65
  • Legacy Issue Number: 13830
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to clause: 6.3

    Suggested resolution: Remove subclause 6.3.

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

    According to the guidance from the OMG-ISO Liaison:
    The acknowledgments should not be in a normative part of an ISO standard.
    You could remove them or put them in an informative annex

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ISO standard documents are described with "shall", "should" and "may" (JP-8)

  • Key: KDM12-64
  • Legacy Issue Number: 13829
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

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

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

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

p.32 (p.10) "Analyst is able to refactor the model..." bullet should be changed

  • Key: KDM12-26
  • Legacy Issue Number: 12880
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

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

    Page 13 replace “Analyst is able to refactor the model (for example, by moving entities between
    containers) and map changes in the model to changes in the software through traceability links””
    into
    “KDM provides model refactoring capabilities, for example, a KDM tool can support moving
    entities between containers and map changes in the model to changes in the code through the
    traceability links”.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer"

  • Key: KDM12-25
  • Legacy Issue Number: 12877
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

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

    Page 6 replace “The KDM Infrastructure Layer” with “Infrastructure Layer”
    Page 11. replace “KDM Infrastructure Layer” with “Infrastructure Layer”
    Page 12 3rd paragraph, replace “KDM Infrastructure Layer” into “Infrastructure Layer”
    Page 25 replace “KDM Infrastructure” with “Infrastructure Layer”
    Page 13 (Part I) change title into “Infrastructure Layer”
    1st paragraph replace “KDM Infrastructure Layer” with “Infrastructure Layer”
    Change index “KDM Infrastructure Layer 10” into “Infrastructure Layer 10”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

p. 25 editorial comment

  • Key: KDM12-24
  • Legacy Issue Number: 12875
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

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

    Remove sentence page 3:
    “This would be an additional reason why L0 interoperability (which at this level would be viewed as
    information sharing between tools) is mandated. In this case interoperability at this level would be viewed
    as correlation between tools to complete knowledge puzzle that end user might need to perform a particular
    task. “

  • Updated: Fri, 6 Mar 2015 20:57 GMT

general information/comments

  • Key: KDM12-23
  • Legacy Issue Number: 12873
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

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

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

    Page 25, Add sentence after “the implementer shall provide … “ “On the other hand, the
    implemented of KDM import tools should not make any assumptions about the
    organization of KDM model elements in models or organization of models in segments.”
    Page 28, delete “The implementers of KDM import tools should not make any assumptions regarding
    the organization of the content into KDM models. “
    Page 29, delete “The implementers of KDM import tools should not make any assumptions regarding
    the organization of the KDM models into KDM segments.”

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on KDM package - kdm package/ Core - core etc needed

  • Key: KDM12-22
  • Legacy Issue Number: 12872
  • Status: closed  
  • Source: Office of the Secretary of Defense ( Larry Wagoner)
  • Summary:

    Overall comments – I found it somewhat confusing to have differences between items just dependent
    on case (e.g. KDM package and kdm package, Core and core, etc.) when the items refer to very
    different things. This occurs with several things. Not sure whether this can be fixed or made more

    clear as to the distinction, but it was a source of confusion for me in reading it.

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

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

SourceRef in Build package

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

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

    Suggested resolution: change multiplicity to 0..1

    Change the origin of the relationship to SourceRef from BuildDescription to BuildResource.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

kinds for resource actions

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

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

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

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

BindsTo relationship should have a more general “to” endpoint

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

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

    Suggested resolution: generalize the “to” endpoint of the BindsTo relationship to KDMEntity class.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Several association ends are both 0..* and composite owners

  • Key: KDM12-18
  • Legacy Issue Number: 12425
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Several association ends are both 0..* and composite owners. This is not only an invalid combination but is inconsistent with the specification document and Rose model used for that. This seems to affect the ends that

    {subset group} (that in the XMI contain "subsettedProperty='P.O.6222315' ")


    For example, line 172 of the file is:
    <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.35' />
    The fact that this has isComposite='true' is inconsistent with Figure 21.3 of ptc/08-02-08 (the KDM 1.1 spec document) which has no black diamond on the line between BuildResource and Group.


    Proposed resolution
    Make all Properties that {subset group}

    have isComposite='false'
    For example, the above line 172 would become:
    <ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='false' association='A.35' />

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Many associations and association ends are given meaningless generated name

  • Key: KDM12-17
  • Legacy Issue Number: 12424
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

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

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

    • If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached,
      modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are
      often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal
      constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.)
    • Associations that are not explicitly named, are given names that are constructed according to the following production
      rule: "A_" <association-end-name1> "_" <association-end-name2>
      where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of
      the second association end.

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

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association A.62

  • Key: KDM12-16
  • Legacy Issue Number: 12423
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

    Proposed resolution
    Remove the trailing space

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

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rename these associations to SignatureType and SourceFileRegion respectivel

  • Key: KDM12-15
  • Legacy Issue Number: 12422
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

    Proposed resolution
    Rename these associations to SignatureType and SourceFileRegion respectively

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

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

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI

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

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

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

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

    In file kdm_1.1.cmof.xml change line
    <XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1"
    xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml"
    xmi:version="2.1">
    Into
    <XMI xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
    xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">
    This is implemented as part of the automatic conversion from UML Rose diagrams into CMOF.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI

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

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

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

  • Reported: KDM 1.1 — Fri, 25 Apr 2008 04:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify the usage of ‘view’ (rh-6)

  • Key: KDM12-49
  • Legacy Issue Number: 13297
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to section 7, paragraph 3

    "ADM KDM separates knowledge about existing systems into several orthogonal facets that are well-known in software engineering and are often referred to as Architecture Views."

    Clarify usage of view. if Architectural View is intended, following rules of ISO 42010 to enable readers understand intent.

  • Reported: KDM 1.1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

    Editorial changes to the text of the specification related to the resolution of this issue are part of
    the resolution to another issue 13296
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need to clarify the use of term ‘view’ and align with ISO (rh-5)

  • Key: KDM12-48
  • Legacy Issue Number: 13296
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to section 4

    "View" is used in a number of context. Sometimes as "architectural view" other times, unclear

    Clarify when "architecture view" in intended, and use ISO 42010 definition. If "database view" is meant (which is a very different notion); make that clear. If both notions are needed; qualify each usage.

  • Reported: KDM 1.1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing definition of software asset (rh-4)

  • Key: KDM12-47
  • Legacy Issue Number: 13295
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to section 4

    Unable to determine intended scope of this standard without a definition of "software asset". Does it intend to cover information items as defined in ISO 15289?

    Define "software asset". Clarify which information items and work products specified in ISO 15289 are included within the scope of this DIS.

  • Reported: KDM 1.1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing definitions of terms (rh-3)

  • Key: KDM12-46
  • Legacy Issue Number: 13294
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to section 4

    It is hard to believe that there are "no special terms or definitions in this specification", since usage of a number of terms in this DIS seem to have no relationship to other, more common usages of those same terms.

    Define the terms that have specialzed meanings or usage in this DIS. ISO/IEC 42010:2007 provides a well established ontology for describing architectures of various types, presumably including "Architecture Driven Modernization" senses of "Architecture". For the architecture-related terms, architecture, architecture description, architecture view, architecture viewpoint and architecture model, adopt the defintions from ISO/IEC 42010:2007

  • Reported: KDM 1.1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Alignment with the ISO concept of architecture view (rh-2)

  • Key: KDM12-45
  • Legacy Issue Number: 13293
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Related to section 2.1

    "KDM domains correspond to the well-known concept of architecture views." If this is true, the requirements for documenting views should be met; and the rules for interpreting such views should be provided. Usually this is done in terms of an Architectural Viewpoint definition for each view.

    Satisfy requirements on each architectural view in accordance with ISO/IEC 42010.

    Add Architectural Viewpoint definitions for each view in accordance with the rules of ISO/IEC 42010.

  • Reported: KDM 1.1 — Fri, 16 Jan 2009 05:00 GMT
  • Disposition: Resolved — KDM 1.2
  • Disposition Summary:

    EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
    changebars the following edit instructions are collectively referred to as Issue 13293
    Block 1 (see specification with changebars and editorial notes)
    page 1 Change sentence: Each KDM domain consists of a single KDM package that
    defines meta-model elements to represent particular aspects of the system under study.
    KDM domains correspond to the well-known concept of architecture views. Each KDM domain defines an architectural viewpoint. The viewpoint language for the
    domain is defined by the corresponding KDM package that defines meta-model elements
    to represent particular facts of the system under study that are essential to the given
    knowledge discovery domain. The meta-model elements defined by all KDM packages
    constitute the ontology for describing existing systems.
    Page 1 change sentence:
    For example, the Structure domain enables users to discover architectural elements of source code from the
    system under study, while the Business Rules domain provides users with behavioral elements of the same
    system such as features or process rules.
    Into
    For example, the Code package defines the language to represent individual code elements, such as
    variables, statements and procedures, the Structure package provides the language to represent
    architectural elements of the system such as subsystems and components, while the Conceptual package,
    corresponding to the Business Rules domain defines the language to represent behavioral elements of the
    same system such as features or business rules. KDM formally defines traceability, aggregation and
    derivation of facts across domains.
    Page 1 remove sentence: Separation of concerns in the design of KDM is embodied in the concept of
    KDM domains.
    Page 1 change sentence: The following domains of knowledge have been identified as the foundation for
    defining compliance in KDM: Build, Structure, Data, Business Rules, UI, Event, Platform, and micro
    KDM.
    Into:
    The following domains of knowledge have been identified as the foundation for defining compliance in
    KDM: Inventory, Code, Build, Structure, Data, Business Rules, UI, Event, Platform, and micro KDM.
    EDITORIAL NOTE: This is the end of Block 1.
    EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
    changebars the following edit instructions are collectively referred to as Issue 13293
    Block 2 (see specification with changebars and editorial notes)
    Page 2: change sentence: This compliance level contains the following KDM packages: Core, kdm, Source,
    Code, and Action packages.
    Into:
    This compliance level addresses the Inventory and Code domains and is determined by the following KDM
    packages: Core, kdm, Source, Code, and Action packages.
    Page 2 change sentence: To be L0 compliant, a tool must completely support all model elements within all
    packages for L0 level.
    Into
    To be L0 compliant, a tool shall completely support all meta-model elements within all packages of L0
    level.
    P