Knowledge Discovery Metamodel Avatar
  1. OMG Specification

Knowledge Discovery Metamodel — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
KDM14-306 Change UML model to match specification text regarding MOF enumerations KDM 1.3 KDM 1.4 Resolved closed
KDM14-304 Change MOF XMI version for the specification KDM 1.3 KDM 1.4 Resolved closed
KDM14-302 Revert from Primitivetype back to Datatype in section 9.7 KDM 1.3 KDM 1.4 Resolved closed
KDM14-309 Editorial changes regarding the KDM14-289 text KDM 1.3 KDM 1.4 Resolved closed
KDM14-289 Navigability used for code generation 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-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-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-64 current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit KDM 1.2 KDM 1.4 Resolved closed
KDM14-63 mark code element as ordered KDM 1.2 KDM 1.4 Resolved 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-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-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-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-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-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-233 Editorial changes to the descriptions of the new top elements KDM 1.3 KDM 1.4 Resolved closed
KDM14-235 Add missing descriptions of properties to KDMEntity KDM 1.3 KDM 1.4 Resolved closed
KDM14-237 Clarification to MD5 KDM 1.3 KDM 1.4 Resolved closed
KDM14-239 Add clarification to BinaryRegion KDM 1.3 KDM 1.4 Resolved closed
KDM14-241 Add clarification to Audit element 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-247 Do not add source association to AbstractInventoryItem 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-231 Missing subsets inbound, outbound for KDM relationship endpoints KDM 1.3 KDM 1.4 Resolved closed
KDM14-27 Assoc. between CompilationUnit and SourceFile other than through SourceRef KDM 1.0 KDM 1.4 Duplicate or Merged 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-23 Initialization block? KDM 1.0 KDM 1.4 Resolved 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-223 Replace Templates with TemplateElement 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-221 Add ExportKind to ClassUnit 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-178 Need to provide source code for the Visibility example on page 135 KDM 1.3 KDM 1.4 Resolved closed
KDM14-182 Make IndexUnit for ArrayType optional 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-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-214 Ownership of AggregatedRelations is inconsistent 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-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-227 Rename new class DeploymentResources into DeploymentElement KDM 1.3 KDM 1.4 Resolved closed
KDM14-229 Split InventoryModel Class Diagram 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-118 Incorrect specification of PtrReplace micro-KDM 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-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-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-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-143 Typo on page 285 "of" into "or" 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-265 Editorial change in section 10.3.1 KDM 1.3 KDM 1.4 Resolved closed
KDM14-269 Clarify description of BlockUnit 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-267 Update references to examples in chapter 10 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-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-74 Incorrect description in AbstractCodeElement codeRelation association 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-287 Corrections to the RecordFile example KDM 1.3 KDM 1.4 Resolved closed
KDM14-285 Corrections to ClassD example (HasValue) 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-271 Clarify semantics of path attribute 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-277 Corrections to reference example 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-283 Rename section ParameterKind 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-249 Editorial changes to clarify semantics of URI resolution 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-255 Add description of the new Regions Class Diagram 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-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-73 AbstractConceptualElement is required to have one and only one role KDM 1.3 KDM 1.4 Resolved closed
KDM14-259 Semantics section for initialization blocks goes to BlockUnit 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-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-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-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-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-6 Need additional type of UI control elements KDM 1.0b1 KDM 1.4 Closed; No Change closed
KDM14-1 Need traceability for indirect messages KDM 1.0b1 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-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-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-3 Need example for reflection in Java 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-55 Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews KDM 1.0b1 KDM 1.4 Deferred closed
KDM14-62 Provide detailed information about dependencies between KDM packages KDM 1.2 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
KDM-160 Section: 15.10 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-159 Section: 12.11 (02) KDM 1.0b1 KDM 1.0 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-13 Break cyclic dependency between Code and Action package KDM 1.0b1 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-16 9.3.3 Constraint 1 seems wrong KDM 1.0 KDM 1.1 Resolved closed
KDM11-19 9.4.2 - why 2 separate associations? KDM 1.0 KDM 1.1 Resolved closed
KDM-158 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-157 Section: 10 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-153 Section: 13.6 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-152 Section: 11 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-156 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-155 Section: 12.8 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-154 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-148 Remove prototype unit KDM 1.0b1 KDM 1.0 Resolved closed
KDM-151 Section: 10 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-150 StorableElement should be able to own actions KDM 1.0b1 KDM 1.0 Resolved closed
KDM-149 Rename CodeAssembly to Package KDM 1.0b1 KDM 1.0 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-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-26 Need a counterpart of the HasValue relation KDM 1.0 KDM 1.1 Resolved closed
KDM11-25 Consider representation of a switch 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-28 representation of the sizeof (type) operator as opposed to sizeof (expr) op KDM 1.0 KDM 1.1 Resolved closed
KDM11-24 10.4.1: Audit.description 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-27 Add uppercase requirement for the names of micro KDM operations 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-41 associations with duplicated names in the same package 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-39 upper bound of the container end of a composition shown as unbounded 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-40 "Segments" assocation on the kdm::Segment class 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-34 change text for the arrayselect "single" reads KDM 1.0 KDM 1.1 Resolved closed
KDM12-64 ISO standard documents are described with "shall", "should" and "may" (JP-8) KDM 1.1 KDM 1.2 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
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
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-68 Annex must be either “normative” or “informative”. Specify it. (JP-12) KDM 1.1 KDM 1.2 Resolved closed
KDM-108 Section: 10.4 page 32 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-107 Section: 10.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-101 Section: 19 pages 149 - 169 (07) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-100 Section: 19 pages 149 - 169 (06) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-104 Section: 9.6.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-103 Section 93. KDM 1.0b1 KDM 1.0 Resolved closed
KDM-115 Section: 12.17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-114 Section: 12.13 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-110 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-109 Section: 9 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-106 Section: 10.3 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-105 Section: 9 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-112 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-111 Section: 12.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-102 Section: 19 pages 149 - 169 (09) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-113 Section: 12.9 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-54 Section: 12.14 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-53 Section: 12.14 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-48 Section: 12,13 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-51 Section: 12.24 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-50 Section: 12.23 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-46 Section: 9.7 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-52 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-47 Section: 12.17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-49 Section: 12.9 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-44 Section: 19 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-45 Section: 19.6 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-147 add type attribute to CallableUnit KDM 1.0b1 KDM 1.0 Resolved closed
KDM-139 Allow multiple SourceRef elements for a given Code element KDM 1.0b1 KDM 1.0 Resolved closed
KDM-138 Lack of fidelity for advance flow analysis KDM 1.0b1 KDM 1.0 Resolved closed
KDM-137 Remove several remaining backward navigable links to groups KDM 1.0b1 KDM 1.0 Resolved closed
KDM-136 Wrong text for PrototypeRelation class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-135 Wrong text for DataRelation class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-134 Wrong text for UsesCallable class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-142 Change name of attribute in Annotation from "note" to "text" to reflect sem KDM 1.0b1 KDM 1.0 Resolved closed
KDM-141 Make ValueElement a subclass of StorableElement KDM 1.0b1 KDM 1.0 Resolved closed
KDM-146 Add optional kind attribute to StorableUnit VariableKind KDM 1.0b1 KDM 1.0 Resolved closed
KDM-145 Make AggregatedRelationship a subclass of KDMRelationship KDM 1.0b1 KDM 1.0 Resolved closed
KDM-143 ActionElements can not be added directly to CodeModel KDM 1.0b1 KDM 1.0 Resolved closed
KDM-133 Wrong text for Calls class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-140 Missing attribute length for all StorableElements KDM 1.0b1 KDM 1.0 Resolved closed
KDM-144 Allow ActionElement to own storable elements KDM 1.0b1 KDM 1.0 Resolved closed
KDM-121 Insufficient specification of KDMAggregatedRelationship class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-120 Section: 9 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-123 Wrong text for 12.10.2 TemplateParameter Class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-122 Need additional attribute for SourceFile element to specify encoding KDM 1.0b1 KDM 1.0 Resolved closed
KDM-132 Wrong text for CallableRelations class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-131 Missing specification detail for ControlFlow class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-125 Wrong text for ControlFlow class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-124 Wrong text for DerivedTypeElement class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-127 Wrong text for ControlFlow class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-126 Wrong text for EntryFlow class KDM 1.0b1 KDM 1.0 Resolved closed
KDM-130 Wrong text for ControlFlow class (04) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-129 Wrong text for ControlFlow class (03) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-119 Section: 21.3 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-118 Section: 17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-117 Section: 13 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-116 Section: 13 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-128 Wrong text for ControlFlow class (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-69 Section: 19.11 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-68 Unnecessary abstract classes for relationships in Platform package KDM 1.0b1 KDM 1.0 Resolved closed
KDM-73 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-72 Section: 12.18 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-76 Section: 12, page 41-74 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-75 Section: 12, page 41-74 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-71 Section: 22.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-70 Section: 21.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-81 Section: 18 pages 137 - 148 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-80 Section: 18 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-79 Section: 17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-78 Section: 13.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-74 Section: 12 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-77 Section: 12, page 41-74 (04) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-24 Section: 12.7 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-23 Section: 12.6.6 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-20 Section: 9.7.1 (issue # 2) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-19 Section: 9.7.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-21 Section: 12.5 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-27 Section: 12.6 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-26 Section: 12.8 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-31 Section: 12.10 (issue # 3) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-30 Section: 12.10 (issue # 2) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-25 Section: 12.7 (iisue # 2) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-22 Section: 12.6.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-29 Section: 12.10 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-28 Section: 12.8 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-87 Section: 18 pages 137 - 148 (08) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-86 Section: 18 pages 137 - 148 (07) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-93 Section: 19 pages 149 - 169 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-92 Section: 19 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-91 Section: 20 pages 171 - 183 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-90 Section: 20 pages 171 - 183 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-95 Section: 19 pages 149 - 169 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-94 Section: 19 pages 149 - 169 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-85 Section: 18 pages 137 - 148 (06) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-84 Section: 18 pages 137 - 148 (05) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-83 Section: 18 pages 137 - 148 (04) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-82 Section: 18 pages 137 - 148 (03) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-99 Section: 19 pages 149 - 169 (05) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-98 Section: 19 pages 149 - 169 (04) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-89 Section: 18 pages 137 - 148 (10) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-88 Section: 18 pages 137 - 148 (09) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-97 Section: 19 pages 149 - 169 (03) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-96 Section: 19 pages 149 - 169 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-43 Section: 9.6.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-34 Section: 12.12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-33 Section: 12.11 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-40 Section: 12.18 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-39 Section: 9.6.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-37 Section: 12.16 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-36 Section: 12.12-12.17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-38 Section: 12.18 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-35 Section: 12.12 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-32 Section: 12.10 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-42 Section: 12.19-12.20 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-41 Section: 12.21 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-63 Section: 13.7 page 85 Creates relationship KDM 1.0b1 KDM 1.0 Resolved closed
KDM-62 Section: 13.7 page 85 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-57 Section: 9.7 page 23 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-56 Section: 12.19 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-64 Section: 13.3 page 76 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-67 Section: 14 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-66 Section: 15.3 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-60 Section: 12.13 page 59 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-59 Section: 10.5 page 34 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-58 Section: 9.7 page 23 (TaggedValue) KDM 1.0b1 KDM 1.0 Resolved closed
KDM-61 Section: 13 pages 75 - 95 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-55 Section: 11.4.1 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-65 Section: 12.17 page 65 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-17 Section: 9.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-16 Section: 11.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-18 Section: 9.5 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-14 Section: 10.5 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-13 Section: 10.3, 10.4 KDM 1.0b1 KDM 1.0 Resolved closed
KDM-15 Section: 11.3 KDM 1.0b1 KDM 1.0 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-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-23 general information/comments 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-24 p. 25 editorial comment 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-34 p. 65/66 editorial issues 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
KDM12-53 Align KDM Package with ISO Architecture Views (rh-10) KDM 1.1 KDM 1.2 Resolved closed
KDM12-63 Relationships between packages (JP-7) 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-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-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-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-59 Interchange format in compliance statement (JP-2) 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-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-13 invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI 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-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-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-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-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-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-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-35 p.69 (p.47) in the Semantics section 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-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
KDM14-298 Section: 22 KDM 1.0b1 KDM 1.0 Closed; No Change closed
KDM14-300 Section: 21 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-301 Section: 12 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-299 Section: 19 (03) KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-296 Section: 15 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-295 Section: 15 (Data package illustrating extraction of xml file elements ) KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-297 Section: 15 (extraction of record database elements ) KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-290 Section: 17 pages 131 - 136 (02) KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-293 Section: 18 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-294 Section: 16 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-292 Section: 17 KDM 1.0b1 KDM 1.0 Resolved closed
KDM14-291 Section: 19 pages 149 - 169 (10) KDM 1.0b1 KDM 1.0 Resolved closed

Issues Descriptions

Change UML model to match specification text regarding MOF enumerations

  • Key: KDM14-306
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Dr. 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

Navigability used for code generation

  • Key: KDM14-289
  • Legacy Issue Number: 19729
  • Status: closed  
  • Source: Adaptive ( Mr. 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

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

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

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 ( Dr. 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

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

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

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

Clarify alignment of the KDM Core with RDF

  • Key: KDM14-32
  • Legacy Issue Number: 11739
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

Inconsistency in the description of ConceptualRelations diagram

  • Key: KDM14-34
  • Legacy Issue Number: 12866
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

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

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

Editorial changes to the descriptions of the new top elements

  • Key: KDM14-233
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add missing descriptions of properties to KDMEntity

  • Key: KDM14-235
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Clarification to MD5

  • Key: KDM14-237
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add clarification to BinaryRegion

  • Key: KDM14-239
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add clarification to Audit element

  • Key: KDM14-241
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 regarding Track element to overview

  • Key: KDM14-245
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Do not add source association to AbstractInventoryItem

  • Key: KDM14-247
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 owner to Stereotype and TagDefinition

  • Key: KDM14-243
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Missing subsets inbound, outbound for KDM relationship endpoints

  • Key: KDM14-231
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Assoc. between CompilationUnit and SourceFile other than through SourceRef

  • Key: KDM14-27
  • Legacy Issue Number: 11728
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

Initialization block?

  • Key: KDM14-23
  • Legacy Issue Number: 11723
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

name of CompilationUnit should not contain extension

  • Key: KDM14-26
  • Legacy Issue Number: 11727
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

Replace Templates with TemplateElement

  • Key: KDM14-223
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

KDM document is missing Datatype overview diagram

  • Key: KDM14-225
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add ExportKind to ClassUnit

  • Key: KDM14-221
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add derived operations getParameters and getReturnType to ControlElement

  • Key: KDM14-192
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

  • Key: KDM14-178
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Make IndexUnit for ArrayType optional

  • Key: KDM14-182
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

  • Key: KDM14-167
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Need a better way to introduce TraceableTo relation

  • Key: KDM14-208
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

Ownership of AggregatedRelations is inconsistent

  • Key: KDM14-214
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Missing ProducesUIEvent relation

  • Key: KDM14-189
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

Clarify the alignment with SBVR

  • Key: KDM14-31
  • Legacy Issue Number: 11738
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Rename new class DeploymentResources into DeploymentElement

  • Key: KDM14-227
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Split InventoryModel Class Diagram

  • Key: KDM14-229
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

KDM does not distinguish between C++ pointer and reference

  • Key: KDM14-166
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

Incorrect specification of PtrReplace micro-KDM

  • Key: KDM14-118
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Make owner endpoint of Annotation and Attribute navigable

  • Key: KDM14-132
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Confusion in the type of the method getCodeElement in ClassUnit

  • Key: KDM14-139
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Need to include operation getOwnedElement for KDMModel in ecore KDM SDK

  • Key: KDM14-135
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

AbstractInventoryElement association inventoryRelationship mismatch

  • Key: KDM14-137
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Typo on page 285 "of" into "or"

  • Key: KDM14-143
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Modify part 2 of the example for micro KDM section

  • Key: KDM14-261
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Editorial change in section 10.3.1

  • Key: KDM14-265
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Clarify description of BlockUnit

  • Key: KDM14-269
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Replace ActionRelation with EntryFlow in example of page 165-167

  • Key: KDM14-263
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Update references to examples in chapter 10

  • Key: KDM14-267
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

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

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

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

Corrections to the RecordFile example

  • Key: KDM14-287
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Corrections to ClassD example (HasValue)

  • Key: KDM14-285
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Eidtorial change to TaggedRef 10.6.3

  • Key: KDM14-275
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Clarify semantics of path attribute

  • Key: KDM14-271
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add explicit ordered to description of ActionElement

  • Key: KDM14-273
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Corrections to reference example

  • Key: KDM14-277
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Correction to Visibility and Comment example source

  • Key: KDM14-281
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Rename section ParameterKind

  • Key: KDM14-283
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add reference to example in CommentUnit

  • Key: KDM14-279
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Editorial changes to clarify semantics of URI resolution

  • Key: KDM14-249
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Change superclass of SourceRef and add region association

  • Key: KDM14-253
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Add description of the new Regions Class Diagram

  • Key: KDM14-255
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Remove some associations and constraints from SourceRegion

  • Key: KDM14-257
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

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

Semantics section for initialization blocks goes to BlockUnit

  • Key: KDM14-259
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

There is an ambiguity between BlockItem and micro action compound

  • Key: KDM14-22
  • Legacy Issue Number: 11721
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

throws example in the spec is incomplete

  • Key: KDM14-16
  • Legacy Issue Number: 11710
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Mr. 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

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

  • Key: KDM14-19
  • Legacy Issue Number: 11716
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

  • Key: KDM14-13
  • Legacy Issue Number: 11178
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 Implements relation for BuildDescription

  • Key: KDM14-4
  • Legacy Issue Number: 10291
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 additional type of UI control elements

  • Key: KDM14-6
  • Legacy Issue Number: 10297
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 traceability for indirect messages

  • Key: KDM14-1
  • Legacy Issue Number: 9995
  • Status: closed  
  • Source: International Business Machines ( Mr. 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

Inconsistent naming of the property "taggedValue" in ModelElement

  • Key: KDM14-133
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

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

  • Key: KDM14-20
  • Legacy Issue Number: 11717
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Mr. 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 ( Dr. 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 example for reflection in Java

  • Key: KDM14-3
  • Legacy Issue Number: 10288
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Need illustration of runtime context

  • Key: KDM14-7
  • Legacy Issue Number: 10306
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

Provide detailed information about dependencies between KDM packages

  • Key: KDM14-62
  • Legacy Issue Number: 15129
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

Section: 15.10

  • Key: KDM-160
  • Legacy Issue Number: 10466
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Collision of the role name "attribute" in Data package This issue has been raised by Alain Picard from Benchmark Consulting. The role name "attribute" of the association between class XMLComplexType and SimpleTypeElement (from Code) (in the Data package) collides with the role name of the association between class Element and class Attribute. Recommendation is to rename the role in the Data package to "xmlAttribute"

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 21:54 GMT

Section: 12.11 (02)

  • Key: KDM-159
  • Legacy Issue Number: 9984
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel

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

    duplicate of issue 9983

  • Updated: Fri, 6 Mar 2015 22:55 GMT

9.4.1 - CMOF “redefines” mechanism

  • Key: KDM11-18
  • Legacy Issue Number: 11172
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Break cyclic dependency between Code and Action package

  • Key: KDM11-13
  • Legacy Issue Number: 10123
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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.3.3, association 'group'

  • Key: KDM11-15
  • Legacy Issue Number: 11169
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

9.3.3 Constraint 1 seems wrong

  • Key: KDM11-16
  • Legacy Issue Number: 11170
  • Status: closed  
  • Source: Adaptive ( Mr. 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.4.2 - why 2 separate associations?

  • Key: KDM11-19
  • Legacy Issue Number: 11173
  • Status: closed  
  • Source: Adaptive ( Mr. 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

Section: 12

  • Key: KDM-158
  • Legacy Issue Number: 10797
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Currently the “encapsulated relationship” pattern requires that relationship are owned by the element which is the origin of the relationship. There is a constraint for that. However, the multiplicity of the owned relationship in the xxxModel diagrams is 0..1 (at the owner side) It should be tightened to 1

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 10

  • Key: KDM-157
  • Legacy Issue Number: 10796
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Corrections to the text of the KDM package section, clarifying semantics

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 13.6

  • Key: KDM-153
  • Legacy Issue Number: 10792
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Some corrections are required to the CallableRelations to align with microKDM to differentiate between calls to static procedures and methods, regular methods, calls to procedures via pointers and calls to virtual methods. micro KDM provides operations to achieve this. More differentiation in the CallableRelations is required. “Invokes” relation conflicts with the ISO usage of the term. KDM uses “Calls” instead “Invokes’, leaving both will be confusing. “Invokes” can be changed into “Addresses” which can be generalized to work with a common parent of ControlElements and StorableElements

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 11

  • Key: KDM-152
  • Legacy Issue Number: 10791
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Inventory model as part of the Source package instead of Build There is one flaw in the current architecture of KDM: SourceRegion elements are part of the L0 compliance point, however the SourceFiles are defined in Build package, which is in L1. It would be much better to consolidate SourceFile elements and alike into a special “Inventory model” (the list of elements representing all artifacts as first class KDM citizens), right in the L0, for example as part of the Source package. In fact, all implementers so far are doing just that: they are aiming at supporting L0 with “limited support for Build”. Everybody seems to have an inventory model, and it makes perfect sense to have it right in the L0. The Build package makes sense on its own right as the place where we represent the “Engineering view” of the software system, i.e. the transformations between the artifacts (for example, files A.c, B.c, and C.c as well as the library GGG.lib are compiled into the executable XYZ.exe, where file A.c is provided by supplier S1, and the GGG.lib is provided by supplier S1, and the transformation requires tool T1 and is described in file “makefile”).

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: KDM-156
  • Legacy Issue Number: 10795
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Diagram ExceptionFlow should be moved to Code package in order to comply to the encapsulated relations meta-model pattern in KDM. This is a Code relations, since the from-endpoint is a code element

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.8

  • Key: KDM-155
  • Legacy Issue Number: 10794
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Current KDM has duplication between prototype relations (UsesPrototype and PrototypedBy) and interface relations (Implements, ImplementationOf, and CompliesTo). I suggest removing the prototype relations and use Interface relations.

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: KDM-154
  • Legacy Issue Number: 10793
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    The clear separation of KDM into Infrastructure, Program Elements, Resources and Abstractions layers shows that the current design is overly complex. Currently each package defines own “abstractions” capabilities (an arbitrary container and group). I suggest concentrating all containers and groups in the Abstractions layer. In the long run, this makes the whole KDM architecture more consistent.

  • Reported: KDM 1.0b1 — Wed, 28 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Remove prototype unit

  • Key: KDM-148
  • Legacy Issue Number: 10715
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Remove prototype unit, since it is not an independent model element, but either a signature or callable unit or a storable unit with external is true. If later it is substituted with a real definition, the calls or reads/writes relations will go to the internal definition, and UsesPrototype relationship will go to the external one. The internal definition is related to the external one by PrototypedBy relationship. Usually the external definition lives in a SahredUnit. This should be clarified in the spec. Note, there exists an issue about example ralated to this.

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 10

  • Key: KDM-151
  • Legacy Issue Number: 10767
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Make extensibility mechanism more general by changing the from-endpoint of the extended relation to the most generic element in the model (currently it is at the extended element).

  • Reported: KDM 1.0b1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

StorableElement should be able to own actions

  • Key: KDM-150
  • Legacy Issue Number: 10730
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    StorableElement should be able to own actions. This is required for initialization purposes, according to the Datatype reform. Currently the ownership is restricted to Datatype. Constraint should be added, restricting ownership to Datatype and Action.

  • Reported: KDM 1.0b1 — Tue, 13 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Rename CodeAssembly to Package

  • Key: KDM-149
  • Legacy Issue Number: 10716
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Rename CodeAssembly to Package and use it to represent logical containers for code elements

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

  • 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 ( Dr. 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 ( Dr. 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

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

  • Key: KDM11-22
  • Legacy Issue Number: 11180
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Need a counterpart of the HasValue relation

  • Key: KDM11-26
  • Legacy Issue Number: 11713
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Consider representation of a switch

  • Key: KDM11-25
  • Legacy Issue Number: 11712
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

More than one label on a statement

  • Key: KDM11-31
  • Legacy Issue Number: 11724
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

  • Key: KDM11-28
  • Legacy Issue Number: 11719
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

10.4.1: Audit.description

  • Key: KDM11-24
  • Legacy Issue Number: 11183
  • Status: closed  
  • Source: Adaptive ( Mr. 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

9.5.1 Constraint 4 is inconsistent

  • Key: KDM11-20
  • Legacy Issue Number: 11175
  • Status: closed  
  • Source: Adaptive ( Mr. 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

Add uppercase requirement for the names of micro KDM operations

  • Key: KDM11-27
  • Legacy Issue Number: 11715
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

10.4: use of 'author' is redundant

  • Key: KDM11-23
  • Legacy Issue Number: 11182
  • Status: closed  
  • Source: Adaptive ( Mr. 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

associations with duplicated names in the same package

  • Key: KDM11-41
  • Legacy Issue Number: 13399
  • Status: closed  
  • Source: Adaptive ( Mr. 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

case of a property name duplication

  • Key: KDM11-38
  • Legacy Issue Number: 13396
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Dr. 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

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

  • Key: KDM11-39
  • Legacy Issue Number: 13397
  • Status: closed  
  • Source: Adaptive ( Mr. 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

Description of the multidimentional arrays is confusing.

  • Key: KDM11-36
  • Legacy Issue Number: 11734
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

"Segments" assocation on the kdm::Segment class

  • Key: KDM11-40
  • Legacy Issue Number: 13398
  • Status: closed  
  • Source: Adaptive ( Mr. 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

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 ( Dr. 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 ( Dr. 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

change text for the arrayselect "single" reads

  • Key: KDM11-34
  • Legacy Issue Number: 11731
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

  • Key: KDM12-64
  • Legacy Issue Number: 13829
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

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

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

  • Key: KDM12-67
  • Legacy Issue Number: 13832
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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

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

  • Key: KDM12-68
  • Legacy Issue Number: 13833
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Section: 10.4 page 32

  • Key: KDM-108
  • Legacy Issue Number: 10327
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add capability to add Stereotypes to Models (currently, Stereotypes can only be added to ModelElements, not to Elements, since ModelElements represent artifacts of existing systems, and Elements are part of the metamodel infrastructure).

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 10.4

  • Key: KDM-107
  • Legacy Issue Number: 10326
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Try to decouple kdm package from other packages, for example by introducing "extensible" kdm model and removing explicit associations with models. Complexity of queries needs to be taken into consideration

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 19 pages 149 - 169 (07)

  • Key: KDM-101
  • Legacy Issue Number: 10318
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200521 from submitters database Originally raised by Nick Mansourov Introduce strongly typed MarshalledCall relation between MarshalledService and instance of MarshalledResource

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

    No Data Available

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

Section: 19 pages 149 - 169 (06)

  • Key: KDM-100
  • Legacy Issue Number: 10317
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issues 1211200518,1211200519,1211200520 from submitters database Originally raised by Nick Mansourov Rename Activation to ActivationService Rename Registration to NamingService Rename MarshalledCall to MarshalledService

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

    No Data Available

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

Section: 9.6.1

  • Key: KDM-104
  • Legacy Issue Number: 10323
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    add more elements to the InstanceKind: -member -signature -unknown

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section 93.

  • Key: KDM-103
  • Legacy Issue Number: 10322
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Suggestion to make diagram at figure 9.1 more "balanced" (mutually exclusive subtypes) by introducing an extra subclass "KDMElement" as a subtype of KDMEntity and changing other diagrams accordingly

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.17

  • Key: KDM-115
  • Legacy Issue Number: 10334
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add attribute

    {public, private, etc.}

    to members of the class

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.13

  • Key: KDM-114
  • Legacy Issue Number: 10333
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider adding a special extensibility attrbiute to Predefined classes (since they have to be extended in most cases by adding more precise language specific constraints). This will be a shortcut to adding a Stereotype

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: KDM-110
  • Legacy Issue Number: 10329
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add model elements to represent exceptions (try blocks, exception types, catch with formal parameters, throw), for example in Java and in C++.

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 9

  • Key: KDM-109
  • Legacy Issue Number: 10328
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need generic extensible entity and relationship. Currently, this is somewhat limited because of abstract classes tat can not be instanciated.

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 10.3

  • Key: KDM-106
  • Legacy Issue Number: 10325
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Move association "Segements" from Root to ModelRoot, so that Segements can contain Segments, and kdm framework is more flexible.

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 9

  • Key: KDM-105
  • Legacy Issue Number: 10324
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add an entity id into the Core model, to be used in reasoning about KDM entities, for example, to make a statement that two variables are the same

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: KDM-112
  • Legacy Issue Number: 10331
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing

    {ordered}

    specifications for some elements, such as CodelElement in CallableElement, in MacroUnit; TemplateParameters, EnumeratedLiterals in EnumeratedUnit, ActionRelations, fields in CompositeUnit, all members in ClassUnit

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.4

  • Key: KDM-111
  • Legacy Issue Number: 10330
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    CodeContainer is redundant, since it can not be instanciated

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 19 pages 149 - 169 (09)

  • Key: KDM-102
  • Legacy Issue Number: 10320
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1910200501 from submitters database Originally raised by Nick Mansourov Need to perform unification of triggers and platform bindings

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

    No Data Available

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

Section: 12.9

  • Key: KDM-113
  • Legacy Issue Number: 10332
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing parameters to the MacroUnit

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.14

  • Key: KDM-54
  • Legacy Issue Number: 10109
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need special attribute to RefinementUnit to represent the actual refinement. Currently there is no special special modeling element for representing the actual refinement of a data type (for example, the actual range in Ada) as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the refinement in RefinementUnit. This information is required in several queries against KDM models and is required for transformations of existing systems.

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

    No Data Available

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

Section: 12.14

  • Key: KDM-53
  • Legacy Issue Number: 10108
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need special attribute to ArrayUnit to represent the size of the array. Currently there is no special special modeling element for representing size of the array as it may be declared in the existing source code artifact. This gap has to be mitigated, for example, by introducing a special attribute for representing the size of the array. This information is required in several queries against KDM models and is required for transformations of existing systems.

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

    No Data Available

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

Section: 12,13

  • Key: KDM-48
  • Legacy Issue Number: 10103
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Improve encapsulation of KDM models by associating KDM relationships with the from-endpoint. Encapsulation of KDM models can be improved by placing most KDM relationships into the elements that are the from-endpoints of these relationships, instead of associating these relationships with the whole model. Particularly, ActionRelationships should be owned by ActionElements; CodeRelationships should be owned by CallableElements. Currently, only FlowRelationships follow this principle (they are already owned by CallableElements). This will significantly reduce the number of KDM relationships that are contained directly by the each KDM model. The proposed revision will dramatically improve the readability of KDM instances in XMI (otherwise, each model is "flooded" by a flat set of KDM relationships).

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

    No Data Available

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

Section: 12.24

  • Key: KDM-51
  • Legacy Issue Number: 10106
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of Visibility relationship in section 12.24

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

    No Data Available

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

Section: 12.23

  • Key: KDM-50
  • Legacy Issue Number: 10105
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of CommentUnit and its usages in section 12.23

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

    No Data Available

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

Section: 9.7

  • Key: KDM-46
  • Legacy Issue Number: 10100
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Move Extension and Annaotation diagrams from Core to Kdm package. Management of KDM packages can be optimized, if the Extension and Annotations diagrams are moved from the Core package into the Kdm package. This way, the Core package will contain abstract classes that define the meta-level facilties of KDM, and determine the meta-level API to KDM instances. The Kdm package, on the other hand, will contain concrete classes that are part of each KDM instance.

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

    No Data Available

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

Section: 12

  • Key: KDM-52
  • Legacy Issue Number: 10107
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need special modeling element to represent initialization of data items. Currently there is no special special modeling element for initialization. This can be represented by ActionElements and Initializaes relationship. However, this solution proves to be not particularly readable and rather verbose. Introducing a special element for initialization will improve readability of KDM XMI instances.

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

    No Data Available

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

Section: 12.17

  • Key: KDM-47
  • Legacy Issue Number: 10102
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Definition of ClassUnit should be flattened. Definition of ClassUnit (Figure 12.15) should be flattened, so that ClassUnit contains a single association to CodeResource. This will make Classunit more generic, for example, allow to use PrototypeUnit as a contained element, and will allow to make contents of ClassUnit ordered

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

    No Data Available

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

Section: 12.9

  • Key: KDM-49
  • Legacy Issue Number: 10104
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of MacroUnit and its usages in section 12.9

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

    No Data Available

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

Section: 19 (02)

  • Key: KDM-44
  • Legacy Issue Number: 9996
  • Status: closed  
  • Source: International Business Machines ( Mr. Howard Hess)
  • Summary:

    Need to relate platform activations and bindings to UI triggers

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

    No Data Available

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

Section: 19.6

  • Key: KDM-45
  • Legacy Issue Number: 9998
  • Status: closed  
  • Source: International Business Machines ( Mrs. Neta Aizenbud-Reshef)
  • Summary:

    DataResource is the same as DataManager, Figure 19.4

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

    No Data Available

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

add type attribute to CallableUnit

  • Key: KDM-147
  • Legacy Issue Number: 10714
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    add type attribute to CallableUnit, to specify Signature to be consistent with ISO Lnaguage Independent datatypes and with StorableElement

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Allow multiple SourceRef elements for a given Code element

  • Key: KDM-139
  • Legacy Issue Number: 10653
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Allow multiple SourceRef elements for a given Code element

  • Reported: KDM 1.0b1 — Wed, 7 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Lack of fidelity for advance flow analysis

  • Key: KDM-138
  • Legacy Issue Number: 10652
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    The current KDM allows for the representation of flow information through various action elements, but the current representation is too vague and lacks the full fidelity needed to provide detailed static analysis “grade” representations, especially when we are being asked to produce this in a standard compliant fashion. Currently, an action element is underspecified: it can be one statement, or more than one statement, or less than one statement. If it is too coarse grained, we are loosing precision regarding the semantics of the Reads and Writes and operations performed and access to complex data structures. What we need is either a finer-grained model or at least a specification that would standardize the way the current elements should be used in order to create a compliant KDM model with “instruction-level” fidelity. Maybe this new “micro-KDM” compliance point becomes part of the optional L1 categories, so that we at least can all agree and understand how to process this kind of information.

  • Reported: KDM 1.0b1 — Wed, 7 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Remove several remaining backward navigable links to groups

  • Key: KDM-137
  • Legacy Issue Number: 10468
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Remove several remaining backward navigable links to groups Several backward navigation links have been left unnoticed in the resolution to issue 10412; and need to be removed. StructureGroup -> CodeResource ResourceDefinition -> CodeResource DeployedSoftwareSystem -> SoftwareSystem DeployedComponent -> CodeAssembly DeployedResource -> ResourceElement DeployedResource -> ResourceInstance DeployedResource -> ResourceProvider "Backward navigability" should be removed

  • Reported: KDM 1.0b1 — Mon, 20 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for PrototypeRelation class

  • Key: KDM-136
  • Legacy Issue Number: 10465
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.8
    Severity: minor
    Nature: clarification

    13.8 PrototypeRelations Class Diagram The PrototypeRelations class diagram defines basic meta-model constructs to model prototype relationships between ActionElement and CodeElement.
    Diagram shows extension of PrototypeRelationship, KDM shows extension of CodeRelationship

    CodeElement should be a PrototypeUnit

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for DataRelation class

  • Key: KDM-135
  • Legacy Issue Number: 10464
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.7
    Severity: minor
    Nature: clarification

    13.7 DataRelations Class Diagram The DataRelations class diagram collects together classes and associations of the Action package. They provide basic meta-model constructs to define data specific CRUD like relationships between ActionElement and DataInterface.
    What is a DataInterface and where is it defined?

    This should be StorableElement.

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for UsesCallable class

  • Key: KDM-134
  • Legacy Issue Number: 10463
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.6.2
    Severity: minor
    Nature: clarification

    13.6.2 UsesCallable Class
    The UsesCallable is an association class to provide linkages between ActionElement and CodeElement for any references
    to a CallableElement, other than performing a call.
    Should talk about UsesCode instead

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Change name of attribute in Annotation from "note" to "text" to reflect sem

  • Key: KDM-142
  • Legacy Issue Number: 10709
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Change name of attribute in Annotation from "note" to "text" to reflect semantics

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Make ValueElement a subclass of StorableElement

  • Key: KDM-141
  • Legacy Issue Number: 10708
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    ValueElement has to be compatible with StorableElement in order for Reads relationship to work Suggestion: Make ValueElement a subclass of StorableElement. This is a bit of an overspecialization, so we need to add some constraints. Add constraint to ValueElement that it can not have owned elements; it can only be the target of Reads relationship (and not of Addresses, Writes or Initializes). add constraint to Writes, Addresses, Initializes relationships that it can not use ValueElement as target.

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Add optional kind attribute to StorableUnit VariableKind

  • Key: KDM-146
  • Legacy Issue Number: 10713
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add optional kind attribute to StorableUnit VariableKind with values

    {global, local, static, unknown}
  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Make AggregatedRelationship a subclass of KDMRelationship

  • Key: KDM-145
  • Legacy Issue Number: 10712
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Make AggregatedRelationship a subclass of KDMRelationship so that they can occur in KDM XMI, add a concept of an AggregatedRelationship Filter (as a set of relationship type names or "all" ) and add a filter attribute to Aggregated relationship

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

ActionElements can not be added directly to CodeModel

  • Key: KDM-143
  • Legacy Issue Number: 10710
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    ActionElements can not be added directly to CodeModel. Currently CodeModel allows ActionElements (for example, to represent scripts), but does not allow Flow relations. Suggestion to disallow free standing ActionElements, and to use BlockUnit instead, because BlockUnit is a CallableElement, and therefore allows FlowRelations. In order to implement, modify owned elements of CodeModel to become Module

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for Calls class

  • Key: KDM-133
  • Legacy Issue Number: 10462
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.6.1
    Severity: minor
    Nature: clarification

    13.6.1 Calls Class The Calls class is a subtype of CodeRelationship and provides linkages between ActionElement and CallableInterface for the situations when an ActionElement performs a call to the CallableElement.

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Missing attribute length for all StorableElements

  • Key: KDM-140
  • Legacy Issue Number: 10654
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing attribute length for all StorableElements (as used in the Data item representation examples)

  • Reported: KDM 1.0b1 — Wed, 7 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Allow ActionElement to own storable elements

  • Key: KDM-144
  • Legacy Issue Number: 10711
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Allow ActionElement to own storable elements (for example, for temporary variables and values).

  • Reported: KDM 1.0b1 — Mon, 12 Feb 2007 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Insufficient specification of KDMAggregatedRelationship class

  • Key: KDM-121
  • Legacy Issue Number: 10450
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Section 9.5.1
    Severity: minor
    Nature: clarification

    9.5.1 KDMAggregatedRelationship Class The KDMAggregatedRelationship represents the set of aggregated relationships of the given entity. The set of derived relationships consists of the primitive relationships of the current entity and of all primitive relationships of the entities that are recursively contained in the current entity.
    What is the difference between aggregated and derived relationships?
    Can you shed light with an example on the recursive nature of relationship, is this related to group and container type entities?

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 9

  • Key: KDM-120
  • Legacy Issue Number: 10412
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    This is another occurence of "backward navigation" references in the KDM Core. KDM requires navigable associations from KDMEntity to KDMGroup (in the Core KDM this association is named group, see Figure 9.1). While useful for certain type of cross-referencing queries (e.g. to which groups does the given entity belong), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). Also, as this element is subsetted by various groups, children of KDMEntity get funny collections of such associations (e.g. UIGroup, CodeGroup associations, etc). It is better to eliminate all these associations, and leave only the association from the KDMGroup to the KDMEntity element. The group association can be changed into an operation, and implemented internally by particular KDM tools.

  • Reported: KDM 1.0b1 — Wed, 18 Oct 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for 12.10.2 TemplateParameter Class

  • Key: KDM-123
  • Legacy Issue Number: 10452
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Section 12.10.2
    Severity: minor
    Nature: clarification

    12.10.2 TemplateParameter Class The TemplateParameter is a CodeElement and is a parameter for TemplateUnit.
    In the KDM, TemplateParameter is a specialization of TypeElement more specifically.
    The text mentions CodeElement, while the diagram mentions CodeResource.

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Need additional attribute for SourceFile element to specify encoding

  • Key: KDM-122
  • Legacy Issue Number: 10451
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Section 11.4
    Severity: minor
    Nature: clarification

    KDM assumes that a source file is a sequence of lines, identified by a linenumber. Each line is a sequence of characters, identified by a position within the line. Whitespace characters like tabulation are considered to be a single character.

    What is the definition of character in regards to the KDM? Is it a byte, 2 bytes, UTF-8 or ????, What about special characters such as in Java \u0234. How should that work?
    Are both line numbers and position, 1 based?

    An additional attribute to specify encoding is needed for the element SourceRegion and SourceFile.

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for CallableRelations class

  • Key: KDM-132
  • Legacy Issue Number: 10461
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.6
    Severity: minor
    Nature: clarification

    13.6 CallableRelations Class Diagram

    The CallableRelations diagram describes the following types: o CodeRelationship - an association class subtyping KDMRelationship.

    o Calls - an association class representing a call type relationship between an ActionElement and a CallableInterface .

    CallableInterface should be CallableElement

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Missing specification detail for ControlFlow class

  • Key: KDM-131
  • Legacy Issue Number: 10460
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.8
    Severity: minor
    Nature: clarification

    Missing specification on how to represent default flow when representing a switch construct using GuardedFlow. The semantics of FalseFlow should be made more generic as a default case, then it can be used to represent both the conditional flows as wells as GuardedFlows

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for ControlFlow class

  • Key: KDM-125
  • Legacy Issue Number: 10454
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.1
    Severity: minor
    Nature: clarification

    13.5.1 ControlFlow Class The ControlFlow is an association class representing the control flow between ActionElements.
    Superclass ActionRelationship
    Doesn't look like the right superclass, believe it should be FlowRelationship

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for DerivedTypeElement class

  • Key: KDM-124
  • Legacy Issue Number: 10453
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 12.14.1
    Severity: minor
    Nature: clarification

    12.14.1 DerivedTypeElement Class The DerivedTypeElement is a meta-model element that represents user-defined types that are derived from a certain base type. In the meta-model the RefinementType is a subclass of TypeContainer. It is associated with the corresponding base type. This class is subclassed by several more specific KDM classes.

    The text mentions RefinementType, but the diagram mention DerivedType.

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for ControlFlow class

  • Key: KDM-127
  • Legacy Issue Number: 10456
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.5
    Severity: minor
    Nature: clarification

    13.5.5 Flow Class (abstract) The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
    Superclass ActionRelationship
    wrong description, not abstract and their superclass is ControlFlow

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for EntryFlow class

  • Key: KDM-126
  • Legacy Issue Number: 10455
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.2
    Severity: minor
    Nature: clarification

    13.5.2 EntryFlow Class
    The ControlFlow is an association class representing the control flow between ActionElements.
    Superclass ActionRelationship

    Doesn't look like the right description and superclass (believe it should be FlowRelationship)?

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for ControlFlow class (04)

  • Key: KDM-130
  • Legacy Issue Number: 10459
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.8
    Severity: minor
    Nature: clarification

    13.5.8 GuardedFlow Class (abstract)
    The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
    Superclass
    ActionRelationship
    wrong description, not abstract and their superclass is ControlFlow

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for ControlFlow class (03)

  • Key: KDM-129
  • Legacy Issue Number: 10458
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.7
    Severity: minor
    Nature: clarification

    13.5.7 FalseFlow Class (abstract)
    The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
    Superclass
    ActionRelationship
    wrong description, not abstract and their superclass is ControlFlow

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 21.3

  • Key: KDM-119
  • Legacy Issue Number: 10408
  • Status: closed  
  • Source: Princeton Blue, Inc. ( Vitaly Khusidman)
  • Summary:

    The diagram in the Figure 21.2 incorrectly shows that ConceptualElement is a specialization of KDMGroup (from Core). It is also inconsistent with the diagram in the Figure 22.2 (Behavior Package). The correct way to show Conceptual Inheritances is: ConceptualGroup is a specialization of KDMGroup (from Core) and ConceptualElement is a specialization of KDMGEntity (from Core)

  • Reported: KDM 1.0b1 — Thu, 12 Oct 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 17

  • Key: KDM-118
  • Legacy Issue Number: 10338
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Add state as an explicit entity (suggested by Larry Hines in Boston)

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 13

  • Key: KDM-117
  • Legacy Issue Number: 10337
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider optimizing the usage of Flow relations by making them

    {ordered}

    . This would lead to more efficient handling of the basic blocks, and Flow relation will be only needed for goto constructs. The xmi file will remain very readable.

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 13

  • Key: KDM-116
  • Legacy Issue Number: 10335
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider adding (an optional) ActionRelation for detailed tracking of the usages of operations in the language (like "+", "*", etc.). Size of the model needs to be taked into consideration.

  • Reported: KDM 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Wrong text for ControlFlow class (02)

  • Key: KDM-128
  • Legacy Issue Number: 10457
  • Status: closed  
  • Source: Benchmark Consulting ( Alain Picard)
  • Summary:

    Section 13.5.6
    Severity: minor
    Nature: clarification

    13.5.6 TrueFlow Class (abstract)
    The ImportRelationship class represents the family of relations corresponding to import of declarations between modules.
    Superclass
    ActionRelationship
    wrong description, not abstract and their superclass is ControlFlow

  • Reported: KDM 1.0b1 — Sat, 18 Nov 2006 05:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 19.11

  • Key: KDM-69
  • Legacy Issue Number: 10137
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing description of the class UsesResource in section 19.11 (correspondign to Figure 19.9

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

    No Data Available

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

Unnecessary abstract classes for relationships in Platform package

  • Key: KDM-68
  • Legacy Issue Number: 10136
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Unnecessary abstract classes for relationships in Platform package. Platform package defines 3 unnecessary abstract classes for KDM relationships: TechnologyRelationship, ExternalRelationship and ResourceRelationship. Originally, these classes were introduced as potential extension hotspots. However they are required to be abstract, so they became unnecessary. Recommendation: to remove these unnecessary classes to simplity the KDM metamodel. This does not affect KDM XMI. Usages of these relationships should be promoted to PlatformRelationship class.

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

    No Data Available

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

Section: 12

  • Key: KDM-73
  • Legacy Issue Number: 10284
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 0308200503 from submitters database Originally raised by Mike Smith (EDS) Add a general "depends" relationship between two CodeEntities

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

    No Data Available

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

Section: 12.18

  • Key: KDM-72
  • Legacy Issue Number: 10283
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 0510200504 for submitters database Originally raised by Larry Hines (EDS) Distinguish parameter passing variants Add attributes to Signature parameters, like ParameterKind with values ByName, ByValue. This will provide a capability to distinguish various forms of parameter passing.

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

    No Data Available

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

Section: 12, page 41-74 (02)

  • Key: KDM-76
  • Legacy Issue Number: 10287
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 0602200602 from submitters database Originally raised by Adam Neal (Klocwork) Role names "class", 'interface' and 'package' are reserved Java keywords. They introduce conflicts during JMI generation

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

    No Data Available

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

Section: 12, page 41-74

  • Key: KDM-75
  • Legacy Issue Number: 10286
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2009200501 from submitters database Originally raised by Nick Mansourov representation of variants (conditional compilation

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

    No Data Available

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

Section: 22.4

  • Key: KDM-71
  • Legacy Issue Number: 10149
  • Status: closed  
  • Source: Princeton Blue, Inc. ( Vitaly Khusidman)
  • Summary:

    Inability to create relationships between BehaviorElements and ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping from BehaviorElement (e.g. RuleUnit) to ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific RuleUnit has business significance and to define the correspondent Rule in the Business Rules Model. However, KDM does not provide simple means to define a relationship between BehaviorElements and ConceptualElements.

  • Reported: KDM 1.0b1 — Thu, 31 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 21.4

  • Key: KDM-70
  • Legacy Issue Number: 10148
  • Status: closed  
  • Source: Princeton Blue, Inc. ( Vitaly Khusidman)
  • Summary:

    Inability to create relationships between ConceptualElements. This issue manifests itself in a context of transferring information from a code mining tool to a rules management (analysis) tool. Mining tool has information on mapping (e.g. based on computational dependency) between ConceptualElements (i.e. TermUnits and FactUnits). This is vital information for an analyst working with rules management tool that helps to determine whether a specific TermUnit or FactUnit has business significance and to define the correspondent Term or Fact in the Business Rules Model. However, KDM does not provide means to define a relationship between ConceptualElements.

  • Reported: KDM 1.0b1 — Thu, 31 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 18 pages 137 - 148

  • Key: KDM-81
  • Legacy Issue Number: 10296
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200601 from submitters database Originally raised by Nick Mansourov DisplayUnits should be groups for Triggers

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

    No Data Available

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

Section: 18

  • Key: KDM-80
  • Legacy Issue Number: 10295
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1410200504 from submitters database Originally raised by Nick Mansourov introduce precise actions for UI

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

    No Data Available

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

Section: 17

  • Key: KDM-79
  • Legacy Issue Number: 10292
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1410200505 from submitters database Originally raised by Nick Mansourov introduce precise actions for triggering

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

    No Data Available

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

Section: 13.4

  • Key: KDM-78
  • Legacy Issue Number: 10290
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 0302200602 from submitters database Originally raised by Nick Mansourov Action Containers are missing

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

    No Data Available

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

Section: 12 (02)

  • Key: KDM-74
  • Legacy Issue Number: 10285
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1309200505 from submitters database Originally raised by Nick Mansourov consistency of models wrt source ref in case of macros (links to fully expanded macro and source of macros).

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

    No Data Available

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

Section: 12, page 41-74 (04)

  • Key: KDM-77
  • Legacy Issue Number: 10289
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200603 from submitters database Originally raised by Nick Mansourov Review the semantics and usages of CodeGroup. Missing examples of the usage of CodeGroup.

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

    No Data Available

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

Section: 12.7

  • Key: KDM-24
  • Legacy Issue Number: 9974
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines Module (and its subclasses) as a subclass of CodeContainer, which means they inherit SourceRef association. However, this element is not defined at this level. It is only applicable to individual elemetns inside the Module.

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

    No Data Available

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

Section: 12.6.6

  • Key: KDM-23
  • Legacy Issue Number: 9973
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines OperatorUnit as a special subclass of CallableElement, together with CallableUnit, BlockUnit, MethodUnit and ConstructorUnit. There is little value in this element compared to a regular CallableUnit or a MethodUnit. The difference seems more syntactic. Suggestion - to eliminate this element in order to simplify the metamodel.

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

    No Data Available

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

Section: 9.7.1 (issue # 2)

  • Key: KDM-20
  • Legacy Issue Number: 9970
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM requires a named association from Stereotype to the ModelElement (called extendedElement in Figure 9.5). While useful for certain cross-referencing queries (usage of a given stereotype), this feature makes KDM instance XMI very inflexible and complicated (as information is essentially duplicated). Suggestion to define this as an operation, or remove to be implemented internally to KDM tools, if needed

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

    No Data Available

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

Section: 9.7.1

  • Key: KDM-19
  • Legacy Issue Number: 9969
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of KDM Stereotype as KDM instance (with tag definitions, as part of an Extension family).

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

    No Data Available

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

Section: 12.5

  • Key: KDM-21
  • Legacy Issue Number: 9971
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines unnecessary abstract classes for relations, for example, CodeRelationship, PrototypeRelationship, Interfacerelationship, TypeRelationship, TemplateRelationship (figure 12.3). This is a consistent pattern, repreated at other packages. The intention was to provide additional extension points, however, these relationships are defined as abstract classes, so they cannot be instanciated. They cannot be made concrete either for the reasons of compatibility with EMF. They make the metamodel unnecessary complex without adding any value. They do not affect the KDM instance XMI. The suggestion is to simplify the metamodel by removing these unnecessary relations. This suggestion was also given by ASG representative.

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

    No Data Available

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

Section: 12.6

  • Key: KDM-27
  • Legacy Issue Number: 9977
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing examples of various CallableElements as KDM instances

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

    No Data Available

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

Section: 12.8

  • Key: KDM-26
  • Legacy Issue Number: 9976
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines PrototypeUnit as CodeResource. However it should be moved into the TypeElement hierarch, so that it can be owned by ClassUnits. Figure 12.6

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

    No Data Available

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

Section: 12.10 (issue # 3)

  • Key: KDM-31
  • Legacy Issue Number: 9981
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    TemplateParameterowned by TemplateUnit should be ordered

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

    No Data Available

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

Section: 12.10 (issue # 2)

  • Key: KDM-30
  • Legacy Issue Number: 9980
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Association templateElement between TemplateUnit and CodeResource at Figure 12.8. is too general. It says 0..*, but TemplateUnit can contain a single class or method.

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

    No Data Available

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

Section: 12.7 (iisue # 2)

  • Key: KDM-25
  • Legacy Issue Number: 9975
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines Module (and its subclasses) as a subclass of CodeContainer, which does not enforce that semantically all individual code elements are supposed to be owned by some module. Suggestion - change the inheritance hierarchy Figure 12.5 and 12.2

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

    No Data Available

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

Section: 12.6.1

  • Key: KDM-22
  • Legacy Issue Number: 9972
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM text mentions incorrect superclass for CallableUnit, BlockUnit, MethodUnit, (KDM text describes this a CodeElement, while it is in fact CallableElement, as defined in Figure 12.4).

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

    No Data Available

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

Section: 12.10

  • Key: KDM-29
  • Legacy Issue Number: 9979
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM defines TemplateParameter as a subclass of CodeResource, but it should be a subclass of TypeElement in order to get correct usage relations. Figure 12.8.

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

    No Data Available

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

Section: 12.8

  • Key: KDM-28
  • Legacy Issue Number: 9978
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing examples of PrototypeUnit and its usages as KDM instance

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

    No Data Available

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

Section: 18 pages 137 - 148 (08)

  • Key: KDM-87
  • Legacy Issue Number: 10303
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1903200605 from submitters database Originally raised by Nick Mansourov UI package should define its own Event UIEvent

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

    No Data Available

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

Section: 18 pages 137 - 148 (07)

  • Key: KDM-86
  • Legacy Issue Number: 10302
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200610 from submitters database Originally raised by Nick Mansourov Consider DisplayUnit as a group for its data, rather than a relationship to data: in BMS the data definition is autogenerated as a copybook, with two parts, one suffixed with "I" for input and another - with "O" for output; In Visual Basic Control elements are objects with data fields In Web there is a JavaBean

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

    No Data Available

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

Section: 19 pages 149 - 169

  • Key: KDM-93
  • Legacy Issue Number: 10310
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2610200507 from submitters database Originally raised by Howard Hess (IBM) relate platform activations and bindings to UI triggers This is similar to issue 1901200601 review platform element as a special form of binding; maybe need a more generic mechanism to support integration of models.

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

    No Data Available

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

Section: 19

  • Key: KDM-92
  • Legacy Issue Number: 10309
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 0410200501 from submitters database Originally raised by Mike Smith (EDS) Environment relations should be related to triggers, dataports, etc.

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

    No Data Available

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

Section: 20 pages 171 - 183 (02)

  • Key: KDM-91
  • Legacy Issue Number: 10308
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200517 from submitters database Originally raised by Nick Mansourov Rename RunTimeRelations to RunTimeRelationship so that its name is uniform with other generic relation elements

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

    No Data Available

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

Section: 20 pages 171 - 183

  • Key: KDM-90
  • Legacy Issue Number: 10307
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200508 from submitters database Originally raised by Nick Mansourov Review role names for Machine and DeployedComponent and DeployedResource, and the need for backward navigability

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

    No Data Available

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

Section: 19 pages 149 - 169

  • Key: KDM-95
  • Legacy Issue Number: 10312
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200501 from submitters database Originally raised by Nick Mansourov Review backward navigation from ResourceInstance to ResourceElement

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

    No Data Available

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

Section: 19 pages 149 - 169 (02)

  • Key: KDM-94
  • Legacy Issue Number: 10311
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 3110200504 from submitters database Originally raised by Nick Mansourov DataManager is a deployment resource. Should it be moved to RunTime view? Missing association to Data model elements

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

    No Data Available

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

Section: 18 pages 137 - 148 (06)

  • Key: KDM-85
  • Legacy Issue Number: 10301
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200607 from submitters database Originally raised by Nick Mansourov Endpoint of Displays relation is like a resource instance in Platform; needs review

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

    No Data Available

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

Section: 18 pages 137 - 148 (05)

  • Key: KDM-84
  • Legacy Issue Number: 10300
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200606 from submitters database Originally raised by Nick Mansourov Add capability to represent receiving data from DisplayUnits

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

    No Data Available

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

Section: 18 pages 137 - 148 (04)

  • Key: KDM-83
  • Legacy Issue Number: 10299
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200605 from submitters database Originally raised by Nick Mansourov Change CallableElement to ActionElement in Displays relation in UI package

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

    No Data Available

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

Section: 18 pages 137 - 148 (03)

  • Key: KDM-82
  • Legacy Issue Number: 10298
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1703200604 from submitters database Originally raised by Pete Rivett (Adaptive) UIContainer should be a Group for triggers

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

    No Data Available

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

Section: 19 pages 149 - 169 (05)

  • Key: KDM-99
  • Legacy Issue Number: 10316
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1903200602 from submitters database Originally raised by Nick Mansourov relation or group association from external actor to triggers

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

    No Data Available

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

Section: 19 pages 149 - 169 (04)

  • Key: KDM-98
  • Legacy Issue Number: 10315
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200523 from submitters database Originally raised by Nick Mansourov Consider renaming PlatfromRelations to ResourceRelation

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

    No Data Available

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

Section: 18 pages 137 - 148 (10)

  • Key: KDM-89
  • Legacy Issue Number: 10305
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2103200602 from submitters database Originally raised by Nick Mansourov UI package should define code elements corresponding to UI things

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

    No Data Available

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

Section: 18 pages 137 - 148 (09)

  • Key: KDM-88
  • Legacy Issue Number: 10304
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2103200601 from submitters database Originally raised by Nick Mansourov UI package should define actions corresponding to UI things

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

    No Data Available

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

Section: 19 pages 149 - 169 (03)

  • Key: KDM-97
  • Legacy Issue Number: 10314
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200506 from submitters database Originally raised by Nick Mansourov inverse platform activations relations

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

    No Data Available

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

Section: 19 pages 149 - 169 (02)

  • Key: KDM-96
  • Legacy Issue Number: 10313
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 1211200502 from submitters database Originally raised by Nick Mansourov Optional ownership of ResourceElement & ResourceInstance by ResourceType

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

    No Data Available

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

Section: 9.6.1

  • Key: KDM-43
  • Legacy Issue Number: 9994
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Representation of data types and storable elements in KDM (aka "compressed data type representation") has a disadvantage: it is difficult to implement a query that lists all variables in a Code Model. KDM does not explicitly represent varibles. Instead, it represented various typeUnits with a additional kind attribute (of InstanceKind data type) that distinguishes for example, global variable, local variables, fields of a record, members of a class, formal parameters of a procedure, etc. In order to get the list of variables, one needs to iterate over all subtypes of a TypeElement (quite a few), and check the kind attribute. Suggestion: to "uncompress" the representation a little, by introducing an explicit StorableUnit element with attribute type that provides a reference to the corresponding type. This will still satisfy most of the goals of the "compressed representation", for example, low cost of representing complex derived types, and not tracking usages to predefined types through KDM relations (only relations to NamedTypes). This suggestion originates from an external reviewer, who is implementing KDM.

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

    No Data Available

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

Section: 12.12

  • Key: KDM-34
  • Legacy Issue Number: 9985
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing general description of type representation in KDM, embracing sections 12.12-12.22

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

    No Data Available

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

Section: 12.11

  • Key: KDM-33
  • Legacy Issue Number: 9983
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Element TemplateInstance is redundant, as TemplateUnit can contain only a single class or method. The instance of the template therefore consists of that class or method (properly instanciated), and no additinal housekeeping is required. The instance can be the endpoint for the "Instantiates" relation. Suggestion - remove this element to simplify the metamodel, and correct model for instantiates relation to go from CodeResource to TemplateUnit at Figure 12.9. This also elimintaes the need to distinguish between InstanceOf and Instanciates relationships. Relationship InstanceOf can be elimitated to further simplify the metamodel.

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

    No Data Available

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

Section: 12.18

  • Key: KDM-40
  • Legacy Issue Number: 9991
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of CallableElements and their Signatures as KDM instance, illustrating corresponding KDM relations.

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

    No Data Available

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

Section: 9.6.1

  • Key: KDM-39
  • Legacy Issue Number: 9990
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Move InstanceKind enumeration data type from Core package to Code package, since it is only used in Code package. This will simplify development of class factories per each package.

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

    No Data Available

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

Section: 12.16

  • Key: KDM-37
  • Legacy Issue Number: 9988
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    CompositeTypeElement should own an ordered list of fields.

    {ordered}

    is now missing in Figure 12.14

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

    No Data Available

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

Section: 12.12-12.17

  • Key: KDM-36
  • Legacy Issue Number: 9987
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing examples of data types and their representations as KDM instances

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

    No Data Available

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

Section: 12.18

  • Key: KDM-38
  • Legacy Issue Number: 9989
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Signature should have an (optional) association to the returned type, instead of ownership, since returned types are defiend elsewhere, and signature does not define a special name for it.

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

    No Data Available

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

Section: 12.12 (02)

  • Key: KDM-35
  • Legacy Issue Number: 9986
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need new subclass of DerivedTypeElement to represent "synonym types", for example, in C: typedef int x;

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

    No Data Available

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

Section: 12.10

  • Key: KDM-32
  • Legacy Issue Number: 9982
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of a TemplateUnit for class and method as KDM instance. Related to Figure 12.8

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

    No Data Available

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

Section: 12.19-12.20

  • Key: KDM-42
  • Legacy Issue Number: 9993
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of Interface and corresponding relations as KDM instance

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

    No Data Available

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

Section: 12.21

  • Key: KDM-41
  • Legacy Issue Number: 9992
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of HasType relation as KDM instance

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

    No Data Available

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

Section: 13.7 page 85 Creates relationship

  • Key: KDM-63
  • Legacy Issue Number: 10121
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Creates relationship is is a relationship to a TypeElement (ClassUnit), rather than to a variable of that class. This is also different from the call to a particular constructor of that class. Example (C++): A x=new A(1); Pseudo KDM (ClassUnit name="A" id=id0 MethodUnit name="A" id=id3)) (IntegerUnit name="1" kind=constant id=id1) (NamedClassUnit name="x" kind=variable id=id4) (HasType from=id4 to=id0) (ActionElement id=id2) (Creates from=id2 to=id0) (Reads from=id2 to=id1) (Calls from=id2 t=id3) (Writes from=id2 to=id4)

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

    No Data Available

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

Section: 13.7 page 85

  • Key: KDM-62
  • Legacy Issue Number: 10120
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Destroys relationship is not needed since it is simply a call to a destructor method. It should be removed from Figure 13.5

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

    No Data Available

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

Section: 9.7 page 23

  • Key: KDM-57
  • Legacy Issue Number: 10115
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Allow multiple stereotypes for ModelElement Currently Figure 9.5 allow not more than one stereotype to be associated with each ModelElement. It is more convenient to have multiple stereotypes, so that extension can be split. This will avoid duplication in defining extensions. To resolve, corresponding multiplicty has to be changed from 0..1 to 0..*

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

    No Data Available

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

Section: 12.19

  • Key: KDM-56
  • Legacy Issue Number: 10111
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Rename Interface class to InterfaceUnit. Section 12.19, page 67 defines class Interface. However the rest of the specification uses suffix xxxUnit for concrete model elements. Suggestion to rename Interface to InterfaceUnit

  • Reported: KDM 1.0b1 — Thu, 17 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 13.3 page 76

  • Key: KDM-64
  • Legacy Issue Number: 10122
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Unnecessary abstract classes for relationships in Action package. Action package defines 4 unnecessary asbstract relationships: CallableRelationship, MacroRelationship, ImportRelationship and DataRelationship. Originally they were introduced as potential extension hotspots, but later they were made abstract because of the overall KDM pattern and CMOF, so they are now completely redundant. Removing them will simplify KDM. This does not affect existing KDM XMI. Recommendation to promote CallableRelationship and DataRelationship to ActionRelationship and other two - to CodeRelationship (with the possibility for their from-endpoint to own them in order to achieve better encapsulation of the model).

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

    No Data Available

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

Section: 14

  • Key: KDM-67
  • Legacy Issue Number: 10132
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Build 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: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 15.3

  • Key: KDM-66
  • Legacy Issue Number: 10125
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    abstract element ProgramElement should be subclassed by DataElement and CodeElement (rather than only CodeResource), since it is necessary to allow ActionElement to be included into definition of ConceptualGroup

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

    No Data Available

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

Section: 12.13 page 59

  • Key: KDM-60
  • Legacy Issue Number: 10118
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need to add void type to PredefinedTypeElement. This is needed to represent C/C++ casting to void*, and also will make signature more uniform

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

    No Data Available

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

Section: 10.5 page 34

  • Key: KDM-59
  • Legacy Issue Number: 10117
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Typo in the attribute author of Audit class Spelled "duthor" instead of "author"

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

    No Data Available

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

Section: 9.7 page 23 (TaggedValue)

  • Key: KDM-58
  • Legacy Issue Number: 10116
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Allow TaggedValue that can refer to other KDM ModelElements Currently Figure 9.5 allow only TaggedValues with a String value. For some extensions it is convenient to add TaggedValues that contain a reference to other ModelElements. Resolution suggestion: introduce a supertype with two sublclasses, one - current TaggedValue with String value, another one, for example TaggedRef, with an association to ModelElement

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

    No Data Available

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

Section: 13 pages 75 - 95

  • Key: KDM-61
  • Legacy Issue Number: 10119
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Merge UsesType, UsesCallable and UsesData into a single more generic relationship Uses. This relationship is sufficient for tracking dependencies between components, without making fine distinction between the exact semantics of the usage, which can be further derived from the kind of the entity at the to-endpoint. There is not need to duplicate this information in the kind of the relationship

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

    No Data Available

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

Section: 11.4.1

  • Key: KDM-55
  • Legacy Issue Number: 10110
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing description of additional properties for SourceRef in SourceRegion diagram Section 11.4.1. SourceRegion class Diagram misses description of additional properties that are defined for class SourceRef (association from SourceRef to SourceRegions).

  • Reported: KDM 1.0b1 — Thu, 17 Aug 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 12.17 page 65

  • Key: KDM-65
  • Legacy Issue Number: 10124
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Need better support for virtual methods. Recommendation: special call action and a special MethodKind

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

    No Data Available

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

Section: 9.4

  • Key: KDM-17
  • Legacy Issue Number: 9967
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM requires navigabable associations from KDMEntity to KDMRelationship (in the Core KDM these are named outbound and inbound, see Figure 9.2). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMRelationship element. The outbound and inbound associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

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

    No Data Available

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

Section: 11.4

  • Key: KDM-16
  • Legacy Issue Number: 9966
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of SourceRegion element as a KDM instance. It would be good to illustrate alternative organization with and without the BuildModel for representing files, as well as various overrides for language attribute

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

    No Data Available

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

Section: 9.5

  • Key: KDM-18
  • Legacy Issue Number: 9968
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    KDM requires navigabable associations from KDMEntity to KDMAggregatedRelationship (in the Core KDM these are named inAggregated and outAggregated, see Figure 9.3). While useful for certain type of cross-referencing queries (e.g. who is using the given entity), these associations make KDM instance XMI extremely inflexible and hard to modify (as information abut relations is essentially duplicated). It is better to eliminate these associations, and leave only the from and to associations in the KDMAggregatedRelationship element. The inAggregated and outAggregated associations can be changed into operations, or implemented internally by particular KDM tools, if needed.

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

    No Data Available

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

Section: 10.5

  • Key: KDM-14
  • Legacy Issue Number: 9912
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of usage of the Audit element

  • Reported: KDM 1.0b1 — Mon, 10 Jul 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 10.3, 10.4

  • Key: KDM-13
  • Legacy Issue Number: 9911
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of KDM Framework as KDM Instance

  • Reported: KDM 1.0b1 — Mon, 10 Jul 2006 04:00 GMT
  • Disposition: Resolved — KDM 1.0
  • Disposition Summary:

    No Data Available

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

Section: 11.3

  • Key: KDM-15
  • Legacy Issue Number: 9965
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example of SourceRef element as a KDM instance

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

    No Data Available

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

p.45 (p. 23) The explanation of Figure 9.4 (paragraph) right after Figure 9.4 needs work

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

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

    Also, "interpretation that UML multiplicity" needs fixing – not sure what the sentence should read.

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

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

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

p. 43 (p.21) descriptions of items

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

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

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

    9.5.1. Associations, Page 21, “to:KDMEntity[1]” replace “relations” with “relationships”

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

p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1)

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

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

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

    Replace entire semantics paragraph with the following:
    “KDMRelationship meta-model element is an abstract element. The concrete KDM relationships
    between KDM entities in KDM views are instances of concrete subclasses of KDMRelationship.
    Each instance of KDMRelationship has exactly one target and exactly one origin. Each concrete
    subclass of KDMRelationship defines the acceptable types of the endpoints.”

  • 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

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

p.53 (p.31) Section 10.4.2

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

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

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

    Add sentence to 10.4.2 before Associations:
    “Audit elements can be owned by any subclass of the KDMFramework element, including
    segment or model.”

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

p.52 (p.30) date:String and constraints

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

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

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

    resolved

  • 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

Editorial issues p 47 through 51

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

    p.47 (p.25) Throughout the document, "kdm package" is also spelled as "Kdm package" – not sure which is correct
    (I assumed it was kdm package until this section). Just need to go a global search and make it consistent, whichever
    it should be.

    p.48 (p.26) need a space between the dash and defines in the first line ("–defines" should be "– defines")

    p.51 (p.29) Example section: there are extra blank lines in the Example that need to be removed.

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

    resolved

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

p. 65/66 editorial issues

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

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

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

    Section 11.1, page 43 replace "KDM offers further two options:" with "KDM
    offers an additional two options:"

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

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

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

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

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

    see page 24 of ptc/2010-12-10

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

Align KDM Package with ISO Architecture Views (rh-10)

  • Key: KDM12-53
  • Legacy Issue Number: 13301
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to 8.2, Part I

    "Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems."

    The architectural viewpoints being employed should be made explicit, and defined as per ISO 42010

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

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

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

Relationships between packages (JP-7)

  • Key: KDM12-63
  • Legacy Issue Number: 13828
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)

    Suggested resolution: Describe it using Package diagram.

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

    No Data Available

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

Align structure package with ISO 42010 (rh-9)

  • Key: KDM12-52
  • Legacy Issue Number: 13300
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to 8.2, paragraph 1, bullet 10

    "Structure package defines the architectural components of existing application, subsystems, layers, packages, etc."

    DIS should articulate how the Structure package supports common architectural concepts of architecture, architecture description, architecture viewpoint, architecture view, and architecture model per ISO 42010

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

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

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

Reference ISO terminology (rh-8)

  • Key: KDM12-51
  • Legacy Issue Number: 13299
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to section 7, paragraph 13, bullet 5

    "KDM defines multiple hierarchies of entities via containers and groups." It is very difficult to read this sentence and accept the claim in 4 that there are no special terms in this document. Terms like GROUP, CONTAINER, HIERARCHY have ordinary language meanings, numerous technical meanings.

    The DIS should define those terms it depends upon, either within the current document, or by reference to other standards (or if they ordinary language sense of these terms is intended) to a suitable dictionary

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

    No Data Available

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

Clarify the intent of KDM ontology (rh-7)

  • Key: KDM12-50
  • Legacy Issue Number: 13298
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to section 7, paragraph 13, bullet 3

    "KDM defines an ontology for describing existing software systems"

    Clarify whether the intent is an ontology for systems or software assets of system. These are very different subject matters

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

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

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

Align structure package with ISO 42010 (rh-12)

  • Key: KDM12-55
  • Legacy Issue Number: 13303
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to 19.1

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

    Align with ISO 42010, or explain why it is excluded from software assets of interest.

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

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

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

Missing definitions for ‘Engineering view’, ‘logical view’ and ‘developers view’ (rh-11)

  • Key: KDM12-54
  • Legacy Issue Number: 13302
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to 11.1

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

    Views should have definitions USUALLY as viewpoints

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

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

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

This document doesn't define the common interchange format (JP-1).

  • Key: KDM12-58
  • Legacy Issue Number: 13822
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to clause 1.

    Suggested resolution:

    Remove the following statement from scope.

    "The primary purpose of this meta-model is to provide a common interchange format that will allow interoperability between existing modernization and software assurance tools, services, and their respective intermediate representations."

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

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

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

Build Package in Abstract Layer (page 280-281).

  • Key: KDM12-57
  • Legacy Issue Number: 13323
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Change text of section 21.3.4 page 281 from
    “ 21.3.4 Origin Class
    The Origin class models producers of the 3rd party software components as they contribute to the
    build process.”
    Into
    “ 21.3.4 Supplier Class
    The Supplier class models producers of the 3rd party software components as they contribute to
    the build process.”

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

Align ‘ArchitectureView element with ISO (rh-13)

  • Key: KDM12-56
  • Legacy Issue Number: 13304
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to 19.3.8

    "The ArchitectureView class represents a logical packaging of the architectural artifacts related to a particular view of a software system."

    The terminology herein should be aligned to use terms from ISO/IEC 42010:2007, as we can see substantial alignment.

    In addition to alignment on terms, it would be A Good Thing for the developers of this document to look at the draft 42010:20xx, to understand the emerging requirements on Architecture Frameworks. DIS 19506 could well be positioned as an Architecture Framework that conforms to the requirements in the revision of ISO/IEC 42010.

    ArchitectureView class should have attributes with those in the 42010 conceptual model: a corresponding Architectural Viewpoint (which also must be an ArchitectureElement in the present DIS, see Clause 5.3); Identifier, Purpose; and its contained Architecturl Models (see Clause 5.4).

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

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

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

There is no terms ,definitions and symbols. (JP-6)

  • Key: KDM12-62
  • Legacy Issue Number: 13827
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to clause: 4.5

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

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

    No Data Available

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

Normative references (JP-4)

  • Key: KDM12-61
  • Legacy Issue Number: 13825
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to clause: 3

    The following standard must be refered.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502
    • ISO/IEC11404
    • SBVR

    Suggested resolution:

    ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)

    ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

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

    Semantics of Business Vocabulary and Business Rules (SBVR) available at http://www.omg.org/spec/SBVR/1.0/PDF

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

    Change list of references in section 3 “Normative references” into:
    • OMG UML 2.2 Infrastructure Specification formal/2009-02-04
    • OMG Meta-Object Facility (MOF) ver. 2.0 formal/2006-01-01
    • OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-
    02
    • ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
    • ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
    • ISO/IEC 11404:2007 Information technology – General-Purpose Datatypes (GPD)
    Disposition: Resolved

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

Compliance levels (JP-3)

  • Key: KDM12-60
  • Legacy Issue Number: 13824
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to clause 2.2

    "There are two KDM compliance levels:" But there are three level:L0, L1, L2.

    Suggested resolution: "There are Three KDM compliance levels:"

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

    Section 2.2 Compliance levels: change
    "There are two KDM compliance levels:"
    into
    "There are three KDM compliance levels:"

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

Interchange format in compliance statement (JP-2)

  • Key: KDM12-59
  • Legacy Issue Number: 13823
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Related to clause: 2

    The compliance of this standard assume common interchange format between tools. But this standard doesn't define it. Thus remove it.

    Suggested resolution: Remove the clause "2 compliance".

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

    No Data Available

  • 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 ( Dr. 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

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

  • Key: KDM12-18
  • Legacy Issue Number: 12425
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 ( Mr. 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

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

  • Key: KDM12-13
  • Legacy Issue Number: 12420
  • Status: closed  
  • Source: Adaptive ( Mr. 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

kinds for resource actions

  • Key: KDM12-20
  • Legacy Issue Number: 12482
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

Rename these associations to SignatureType and SourceFileRegion respectivel

  • Key: KDM12-15
  • Legacy Issue Number: 12422
  • Status: closed  
  • Source: Adaptive ( Mr. 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 ( Mr. 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

Missing definition of software asset (rh-4)

  • Key: KDM12-47
  • Legacy Issue Number: 13295
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

  • Key: KDM12-49
  • Legacy Issue Number: 13297
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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

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

  • Key: KDM12-45
  • Legacy Issue Number: 13293
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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.
    Page 2: change sentence
    Level 1 (L1) - This level addresses KDM domains and extends the capabilities provided by Level 0.
    Specifically, it adds the following packages: Build, Structure, Data, Conceptual, UI, Event, Platform, as
    well as the set of constraints for the micro KDM domain defined in sub clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.” These packages are grouped to form abovementioned
    domains.
    Into
    Level 1 (L1) - This level addresses the remaining KDM domains and extends the capabilities provided by
    Level 0. Specifically, this level is determined by the following packages: Build, Structure, Data,
    Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in sub
    clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.”.
    Page 3 change sentence:
    To be L1 compliant for a given KDM domain, a tool must completely support all model elements defined
    by the package for that domain and satisfy all semantic constraints specified for that domain.
    Into
    To be L1 compliant for a given KDM domain, a tool shall completely support all meta-model elements
    defined by the corresponding packages and satisfy all semantic constraints specified for that domain.
    EDITORIAL NOTE: This is the end of Block 2.
    EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
    changebars the following edit instructions are collectively referred to as Issue 13293
    Block 3 (see specification with changebars and editorial notes)
    Change sentence page 12 KDM representation is a single, integrated repository of different facets of
    knowledge about the software system.
    Into
    KDM instance is a single, integrated representation of different facets of knowledge about the software
    system.
    EDITORIAL NOTE: This is the end of Block 3.
    EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
    changebars the following edit instructions are collectively referred to as Issue 13293
    Block 4 (see specification with changebars and editorial notes)
    Page 9 Change from: KDM separates knowledge about existing systems into several orthogonal facets
    that are well-known in software engineering and are often referred to as Architecture Views.
    into:
    KDM groups facts about existing systems into several domains each of which corresponds to an ISO 42010
    architectural viewpoint. Each KDM domain is represented by one or more KDM packages, which
    formalizes the viewpoint language for that domain. KDM focuses at the entities and their relationships that
    are essential for the given domain. A KDM representation of a given existing system – KDM instance - is a
    collection of facts about that system. These facts are organized into KDM models per each domain. KDM
    model corresponds to an ISO 42010 architectural view. KDM facts are further organized into meaningful
    groups called segments. A KDM segment may include one or more architectural views of the given
    system. KDM instances may be part of the complete architectural description of the system, as defined by
    ISO 42010, in which case additional requirements of ISO 42010 shall be satisfied by the overall document.
    KDM instances are represented as XML documents conforming to the KDM XMI schema.
    Add clarification page 9 after sentence: Logically, KDM consists of 9 models.
    Each KDM model is described by one or more KDM packages and corresponds to one KDM domain.
    Most KDM domains are defined by a single package, with the exception of the Code domain, which is split
    between the Code and the Action packages.
    EDITORIAL NOTE: This is the end of Block 4. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
    changebars the following edit instructions are collectively referred to as Issue 13293
    Block 5 (see specification with changebars and editorial notes)
    Page 27: Change from: A KDM model corresponds to one of the well-known architecture views of
    software systems. KDM defines several concrete subclasses of the KDMModel class.
    To:
    A KDMModel element is an abstract class that defines the common properties of KDM model instances
    which are collection of facts about a given existing system from the same architectural viewpoint of one of
    the KDM domains. KDM defines several concrete subclasses of the KDMModel class, each of which
    defines a particular kind of a KDM model. The architectural viewpoint is defined by the corresponding
    KDM package. A KDM model instance is an architectural view of the given system.

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

p. 113 (p.91) Change "return

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

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

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

    Page 91 Replace “”this is a return parameter” with “parameter being returned”
    Replace “the parameter passing convention is unknown” with “parameter passing convention is
    unknown”

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

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

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

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

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

    Page 154, inputs bullet replace “Ordered outgoing Reads” into “Ordered incoming Reads”

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

p.69 (p.47) Section 11.3.6, 7, 8, 9, 10

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

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

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

    Page 48, section 11.3.6 replace “The Image” into “Image element”
    Page 48, section 11.3.7 replace “The Configuration” into “Configuration element”
    Page 48, section 11.3.8 replace “The ResourceDescription” into “ResourceDescription element”
    Page 48, section 11.3.9 replace “The BinaryFile” into “BinaryFile element”
    Page 49, section 11.3.10 replace “The ExecutableFile” into “ExecutableFile element”

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

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

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

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

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

    Page 82 12.9.16 section semantics, replace “The KMD Octetstring class … Octet String” with
    “The KDM OctetString class … Octet string”

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

p.88 (p.66) Suggest changing wording

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

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

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

    Section 12.5.5. replace "Same source files may produce a different
    logical model (for example, when compiled and linked for a different
    hardware platform, or for a different operating system)."
    With "A source file may produce a different logical models when, for
    example, compiled and linked for a different hardware platform, or for
    a different operating system.”

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

Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents

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

    Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents to logically break up the TOC such as these
    heading do within the document. These headings do segment the document logically and as such I don't see why

    they are not in the TOC. Also would make it easier to find them in the document.

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

    Change the TOC to include parts

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

p. 178 (p. 154) Semantics

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

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

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

    Replace "Semantics of the micro KDM action elements"
    With "Semantics of the Micro KDM Action Elements"

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

p.69 (p.47) in the Semantics section

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

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

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

    Delete "The requirement for KDM tools is to read information in UTF-8."
    Add to the last paragraph of Semantics: “KDM tools shall at a minimum
    support UTF-8”.

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

p. 177 (p. 153) -- last line should be reordered

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

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

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

    Page 153, last line, replace “5 parts (Action Kind, Inputs, Outputs, Control, and Extras)” into
    “5 parts (Action Kind, Outputs, Inputs, Control, Extras)”

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

p. 178 (p. 154) Control and Extras bullets should not have "part" as part of name

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

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

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

    Page 154 replace “Control part” into “Control”
    Replace “Extras part” into “Extras”

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

Section: 22

  • Key: KDM14-298
  • Legacy Issue Number: 10127
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for Behavior pacakge illustrating the extraction and usage of ScenarioUnit, BehaviorUnit, RuleUnit and other elements as KDM instance XMI

  • Reported: KDM 1.0b1 — Wed, 23 Aug 2006 04:00 GMT
  • Disposition: Closed; No Change — KDM 1.0
  • Disposition Summary:

    Behavior package has been merged with Conceptual package.

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

Section: 21

  • Key: KDM14-300
  • Legacy Issue Number: 10126
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example for Conceptual package illustrating the extraction and usage of TermUnit, FactUnit and other elements as KDM instances in XMI

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

    Resolved. One diagram was updated to reflect the uniform Resource and Abstractions Layer
    pattern. See kdm_1.0.2_changes.pdf file attached.

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

Section: 12

  • Key: KDM14-301
  • Legacy Issue Number: 10101
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing descriptions of associations in Code package. Specification is missing descriptions of some associations: section 12.4.4. Codegroup class section 12.8.2 Prototype class 12.8.3. Code Element (additional properties) 12.9.1. MacroUnit 12.10.1 templateUnit 12.11.1 Instantiates class 12.11.2 InstanceOf 12.11.3 CodeResource (additional properties) 12.20.3 CodeResource (additional properties) 12.20.4 Interface(additional properties) 12.20.5 Signature(additional properties) 12.21.2. CodeResource (additional properties)

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

    Multiple descriptions of associations and missing semantic notes added. See
    kdm_1.0.2_changes.pdf file attached.

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

Section: 19 (03)

  • Key: KDM14-299
  • Legacy Issue Number: 9997
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing comprehensive example for Platform package as KDM instance, like the one used in KDM tutorial

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

    Example of combined usage of CodeModel, DataModel, PlatformModel and EventModel is
    provided (illustrating RecordFile manipulation in Cobol), DataModel chapter.
    When validating the example, 3 diagrams of the Platform package were slightly modified for that
    they follow the uniform Resource Layer pattern. See kdm_1.0.2_changes.pfd file attached.

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

Section: 15

  • Key: KDM14-296
  • Legacy Issue Number: 10128
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Data package illustrating extraction of relational database elements

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

    Data package contains example of relational database schema representation in KDM. 2
    diagrams were slightly modified to makes them follow uniform Resource Layer pattern.
    See kdm_1.0.3_changes.pdf file attached.

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

Section: 15 (Data package illustrating extraction of xml file elements )

  • Key: KDM14-295
  • Legacy Issue Number: 10130
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Data package illustrating extraction of xml file elements

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

    Data package contains 2 example of structured content representation in KDM. ContentElements
    diagram slightly modified to align with datatype representation in CodeModel (explicit type
    association for content elements). See file kdm_1.0.2_changes.pdf

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

Section: 15 (extraction of record database elements )

  • Key: KDM14-297
  • Legacy Issue Number: 10129
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Data package illustrating extraction of record database elements

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

    Example of RecordFile manipulation in Cobol is provided. Also, example of IMS representation is
    provided. 2 diagrams of the Data package were made more extensible, following the uniform
    Resource layer pattern. See file kdm_1.0.2_changes.pdf.

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

Section: 17 pages 131 - 136 (02)

  • Key: KDM14-290
  • Legacy Issue Number: 10294
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2610200506 from submitters database Originally raised by Howard Hess (IBM) Missing example on how to represent a trigger without an explicit activation

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

    Data package contains a combined example related to this. See file kdm_1.0.2_changes.pdf.

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

Section: 18

  • Key: KDM14-293
  • Legacy Issue Number: 10134
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the UI 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: Resolved — KDM 1.0
  • Disposition Summary:

    Example of UI representation is provided in combination with Conceptual model example. See file
    kdm_1.0.2_changes.pdf attached.

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

Section: 16

  • Key: KDM14-294
  • Legacy Issue Number: 10131
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Structure package illustrating extraction of susbystems, layers and components and their representation as KDM XMI instances

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

    Example added. Had to do some followup on issue 10712 to allow concrete from and to
    properties to AggregatedRelationship instead of derived properties. See file
    kdm_1.0.2_changes.pdf

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

Section: 17

  • Key: KDM14-292
  • Legacy Issue Number: 10133
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Missing example(s) for the Event 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: Resolved — KDM 1.0
  • Disposition Summary:

    Example of combined usage of Code, Data, Platform and Event packages was provided in Data
    chapter (illustrating RecordFile manipulation in Cobol). See file kdm_1.0.2_changes.pdf attached.

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

Section: 19 pages 149 - 169 (10)

  • Key: KDM14-291
  • Legacy Issue Number: 10321
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Issue 2610200504, 2610200505 from submitters database Originally raised by Howard Hess (IBM) Missing example, illustrating a DataResource. Illustrate representation of a JDBC

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

    Example to Data package contains illustration of JDBC. See file kdm_1.0.2_changes.pdf.

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