Knowledge Discovery Metamodel Avatar
  1. OMG Specification

Knowledge Discovery Metamodel — Closed Issues

  • Acronym: KDM
  • Issues Count: 56
  • 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
KDM12-68 Annex must be either “normative” or “informative”. Specify it. (JP-12) KDM 1.1 KDM 1.2 Resolved closed
KDM12-67 The title of ISO/IEC 11401 is incorrect. (JP-11) KDM 1.1 KDM 1.2 Resolved closed
KDM12-66 Some class constraints are numbered, but others are not. Unify them. (JP-10) KDM 1.1 KDM 1.2 Resolved closed
KDM12-65 Acknowledgements are not specification. (JP-9) KDM 1.1 KDM 1.2 Resolved closed
KDM12-64 ISO standard documents are described with "shall", "should" and "may" (JP-8) KDM 1.1 KDM 1.2 Resolved closed
KDM12-63 Relationships between packages (JP-7) 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-57 Build Package in Abstract Layer (page 280-281). 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-58 This document doesn't define the common interchange format (JP-1). 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-55 Align structure package with ISO 42010 (rh-12) KDM 1.1 KDM 1.2 Resolved closed
KDM12-53 Align KDM Package with ISO Architecture Views (rh-10) KDM 1.1 KDM 1.2 Resolved closed
KDM12-52 Align structure package with ISO 42010 (rh-9) KDM 1.1 KDM 1.2 Resolved closed
KDM12-49 Clarify the usage of ‘view’ (rh-6) 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-50 Clarify the intent of KDM ontology (rh-7) KDM 1.1 KDM 1.2 Resolved closed
KDM12-48 Need to clarify the use of term ‘view’ and align with ISO (rh-5) KDM 1.1 KDM 1.2 Resolved closed
KDM12-47 Missing definition of software asset (rh-4) KDM 1.1 KDM 1.2 Resolved closed
KDM12-51 Reference ISO terminology (rh-8) KDM 1.1 KDM 1.2 Resolved closed
KDM12-46 Missing definitions of terms (rh-3) KDM 1.1 KDM 1.2 Resolved closed
KDM12-45 Alignment with the ISO concept of architecture view (rh-2) KDM 1.1 KDM 1.2 Resolved closed
KDM12-44 p. 113 (p.91) Change "return KDM 1.1 KDM 1.2 Resolved closed
KDM12-43 p.104 (p.82) "...defined datatype Octet String." -- "String" should be "string" KDM 1.1 KDM 1.2 Resolved closed
KDM12-42 p.88 (p.66) Suggest changing wording KDM 1.1 KDM 1.2 Resolved closed
KDM12-41 Suggest putting Part 1, Part 2, Section 1, etc. in the table of contents KDM 1.1 KDM 1.2 Resolved closed
KDM12-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
KDM12-37 p. 178 (p. 154) -- Inputs bullet -- should be "Ordered incoming..." not "Ordered outgoing..." KDM 1.1 KDM 1.2 Resolved closed
KDM12-40 p. 178 (p. 154) Semantics 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-34 p. 65/66 editorial issues 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-36 p.69 (p.47) Section 11.3.6, 7, 8, 9, 10 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-32 p.52 (p.30) date:String and constraints 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-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-28 p.41 (p. 19) The Semantics paragraph is simply a repeat of the one in the opening section (Part 1) KDM 1.1 KDM 1.2 Resolved closed
KDM12-27 p.33 Figure 8.1 -- "Actions" should be "Action" KDM 1.1 KDM 1.2 Resolved closed
KDM12-25 p.31 (p.9) In bullets, "KDM Infrastructure Layer" should be "Infrastructure Layer" 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-24 p. 25 editorial comment KDM 1.1 KDM 1.2 Resolved closed
KDM12-23 general information/comments KDM 1.1 KDM 1.2 Resolved closed
KDM12-22 Clarification on KDM package - kdm package/ Core - core etc needed KDM 1.1 KDM 1.2 Resolved closed
KDM12-17 Many associations and association ends are given meaningless generated name KDM 1.1 KDM 1.2 Resolved closed
KDM12-21 SourceRef in Build package KDM 1.1 KDM 1.2 Resolved closed
KDM12-20 kinds for resource actions KDM 1.1 KDM 1.2 Resolved closed
KDM12-18 Several association ends are both 0..* and composite owners 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-16 Association A.62 KDM 1.1 KDM 1.2 Resolved closed
KDM12-15 Rename these associations to SignatureType and SourceFileRegion respectivel KDM 1.1 KDM 1.2 Resolved closed
KDM12-14 CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI KDM 1.1 KDM 1.2 Resolved closed
KDM12-13 invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI KDM 1.1 KDM 1.2 Resolved closed

Issues Descriptions

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

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

    Related to clause: Annex A

    Suggested resolution: Annex A may be informative.

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

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

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

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

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

    Related to clause: 7 last paragraph

    Suggested resolution:

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

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

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

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

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

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

    Suggested resolution: All class constraints must be numbered.

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

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

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

Acknowledgements are not specification. (JP-9)

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

    Related to clause: 6.3

    Suggested resolution: Remove subclause 6.3.

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

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

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

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

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

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

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

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

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

Relationships between packages (JP-7)

  • Key: KDM12-63
  • Legacy Issue Number: 13828
  • Status: closed  
  • Source: KDM Analytics ( 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

Interchange format in compliance statement (JP-2)

  • Key: KDM12-59
  • Legacy Issue Number: 13823
  • Status: closed  
  • Source: KDM Analytics ( 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

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

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

  • Key: KDM12-62
  • Legacy Issue Number: 13827
  • Status: closed  
  • Source: KDM Analytics ( 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 ( 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 ( 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

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

  • Key: KDM12-58
  • Legacy Issue Number: 13822
  • Status: closed  
  • Source: KDM Analytics ( 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

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

  • Key: KDM12-54
  • Legacy Issue Number: 13302
  • Status: closed  
  • Source: KDM Analytics ( 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

Align structure package with ISO 42010 (rh-12)

  • Key: KDM12-55
  • Legacy Issue Number: 13303
  • Status: closed  
  • Source: KDM Analytics ( 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

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

  • Key: KDM12-53
  • Legacy Issue Number: 13301
  • Status: closed  
  • Source: KDM Analytics ( 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

Align structure package with ISO 42010 (rh-9)

  • Key: KDM12-52
  • Legacy Issue Number: 13300
  • Status: closed  
  • Source: KDM Analytics ( 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

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

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

    Related to section 7, paragraph 3

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

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

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

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

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

Align ‘ArchitectureView element with ISO (rh-13)

  • Key: KDM12-56
  • Legacy Issue Number: 13304
  • Status: closed  
  • Source: KDM Analytics ( 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

Clarify the intent of KDM ontology (rh-7)

  • Key: KDM12-50
  • Legacy Issue Number: 13298
  • Status: closed  
  • Source: KDM Analytics ( 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

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

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

    Related to section 4

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

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

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

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

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

Missing definition of software asset (rh-4)

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

    Related to section 4

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

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

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

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

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

Reference ISO terminology (rh-8)

  • Key: KDM12-51
  • Legacy Issue Number: 13299
  • Status: closed  
  • Source: KDM Analytics ( 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

Missing definitions of terms (rh-3)

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

    Related to section 4

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

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

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

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

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

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

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

    Related to section 2.1

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

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

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

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

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

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

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

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

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

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

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

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

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

p.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. 25 editorial comment

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

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

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

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

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

general information/comments

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

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

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

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

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

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

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

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

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

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

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

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

Many associations and association ends are given meaningless generated name

  • Key: KDM12-17
  • Legacy Issue Number: 12424
  • Status: closed  
  • Source: 88solutions ( 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

SourceRef in Build package

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

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

    Suggested resolution: change multiplicity to 0..1

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

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

    No Data Available

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

kinds for resource actions

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

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

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

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

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

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

  • Key: KDM12-18
  • Legacy Issue Number: 12425
  • Status: closed  
  • Source: 88solutions ( 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

BindsTo relationship should have a more general “to” endpoint

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

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

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

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

    No Data Available

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

Association A.62

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

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

    Proposed resolution
    Remove the trailing space

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

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

    No Data Available

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

Rename these associations to SignatureType and SourceFileRegion respectivel

  • Key: KDM12-15
  • Legacy Issue Number: 12422
  • Status: closed  
  • Source: 88solutions ( 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: 88solutions ( Pete Rivett)
  • Summary:

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

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

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

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

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

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

  • Key: KDM12-13
  • Legacy Issue Number: 12420
  • Status: closed  
  • Source: 88solutions ( 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