Issue 9995: Section: 19
Issue 10135: Section: 20
Issue 10288: Section: 12, page 41-74 (03)
Issue 10291: Section: 13.4 page 80
Issue 10293: Section: 17 pages 131 - 136
Issue 10297: Section: 18 pages 137 - 148 (02)
Issue 10306: Section: 20
Issue 10319: Section: 19 pages 149 - 169 (08)
Issue 11167: most operations in the whole specification are redundant
Issue 11174: 9.5.1: Property 'density' should be a derived property
Issue 11176: 9.5.1 Semantics: should be expressed in OCL
Issue 11177: 9.6: These types should be declared as primitive
Issue 11178: 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.
Issue 11181: 10.4 would be better to have a proper 'date' type rather than using String
Issue 11709: Validate KDM examples in the KDM specification
Issue 11710: throws example in the spec is incomplete
Issue 11711: Consider Uniform representation of exception object and classes
Issue 11714: PtrCall for callable units and method units a->foo()
Issue 11716: Call via pointer example: need pointer type in type unit fp
Issue 11717: consider having a StorableUnit and CallableUnit, maybe with an explicit kin
Issue 11718: specify which characterset is used for chartype or provide the capability t
Issue 11721: There is an ambiguity between BlockItem and micro action compound
Issue 11723: Initialization block?
Issue 11725: In Initialization example do not need to use extern in the names
Issue 11726: Variable d2 in main compilation unit b.cpp doesn't have aHasValue relation
Issue 11727: name of CompilationUnit should not contain extension
Issue 11728: Assoc. between CompilationUnit and SourceFile other than through SourceRef
Issue 11733: variables that are declared at header of loop needs special care in KDM
Issue 11736: Representation of a stand-alone comment
Issue 11737: explicit relationship and the built-in relationships
Issue 11738: Clarify the algnment with SBVR
Issue 11739: Clarify alignment of the KDM Core with RDF
Issue 12481: RecordFile and Datatypes
Issue 12866: Inconsistency in the description of ConceptualRelations diagram
Issue 12870: Missing section in KDM documentation
Issue 12871: Page numbers
Issue 12874: "Constraints" sub-section in the descriptions seems to be rarely needed
Issue 12876: p.25 (p.3) Confusion
Issue 12878: p.31 (p.9) bottom of page
Issue 12879: p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model"
Issue 12881: spell out SBVR
Issue 12883: p.33 (p.11) editorial issues
Issue 12884: p.34 (p.12) Bullet in section 8.2
Issue 12885: p.35 (p.13) "Small KDM core..." -- need description or introduction as to what this is
Issue 12887: p.42 (p.20) Constraints sub-section
Issue 12889: to: KDMEntity[1]
Issue 12890: from:KDMEntity[1]
Issue 12903: ISO/IEC 11404" should be "ISO/IEC 11404:1996
Issue 12904: p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6
Issue 12906: p.101 (p.79) I don't see the use for the DateType Class
Issue 12907: p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.
Issue 12909: Section 12 add example
Issue 13159: KDM is missing constraints capabilities to stereotype
Issue 13160: AbstractEventElement should group KDM Elements (instead of AbstractCodeElement)
Issue 13161: Component should allow one to express exposed and required services
Issue 13162: Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews
Issue 13826: The format of normative references doesn't meet ISO format. (JP-5)
Issue 14106: Change relation endpoint for Audit relation
Issue 14107: Change specification to allow stereotyping of Audit elements
Issue 14170: Clarify the meaning of BinaryFile
Issue 14171: Standardize naming of InventoryItem children
Issue 14173: At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow'
Issue 15129: Provide detailed information about dependencies between KDM packages
Issue 15276: mark code element as ordered
Issue 15277: current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit
Issue 15878: References in KDM for UML, MOF, and XMI are not current
Issue 15897: In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement
Issue 15906: micro-KDM documentation not updated
Issue 15923: BuildResource class diagram
Issue 15924: Gap in KDM Platform Package
Issue 15925: KDM Build package issue
Issue 15979: If negate is unary it probably doesn't apply to two values
Issue 16167: Handling of Java enums
Issue 16633: AbstractConceptualElement is required to have one and only one role
Issue 17092: Inconsistency between diagram and description
Issue 17093: Incorrect description in AbstractCodeElement codeRelation association
Issue 17272: Typo: Optinal should read Optional
Issue 17301: Errors in example for micro actions
Issue 17374: Missing superclass: StructureGroup
Issue 18778: Specification of Incr and Decr is ambiguous
Issue 18779: VirtualCall is missing an Addresses
Issue 9995: Section: 19 (kdm-rtf)
Click here for this issue's archive.
Source: International Business Machines (Mr. Howard Hess, h2(at)us.ibm.com)
Nature: Revision
Severity: Minor
Summary:
Need traceability for indirect messaging relations in Platform package, as per example used in the tutorial.
Deferred to RTF
Missing example(s) for the Runtime package illustrating extraction of various elements and their representation as KDM XMI instances
Issue 1302200602 from submitters database Originally raised by Alain Picard (CastorTech) Missing example of how to represent reflection mechanisms in Java
Issue 2507200504 from submitters database Originally raised by Mike Smith (EDS) BuildDescription should have relation "implements" to BuildModel
Deferred to RTF
Issue 1703200611 from submitters database Originally raised by Nick Mansourov Missign example on how to represent a logical event that is implemented as a field in a message (a non-event dirven system, implicit events); also how to handle default handling of implicit events
Issue 1703200602 from submitters database Originally raised by Nick Mansourov Add other types of UI control elements to UI
This issue is deferred to the RTF. Other UI elements (for example, pull down menus, buttons) can be added as extensions. More feedback is needed from implementers of KDM if more standardization is needed. Disposition: Deferred
Issue 2610200502 from submitters database Originally raised by Nick Mansourov Missing illustration how to represent runtime context for the following situation: (ps | wc -l; ps | grep "root") where the same deployment component is used in two contexts
Issue 1211200522 from submitters database Originally raised by Nick Mansourov Introduce ResolvedMarshalledCall from MarshalledService directly to CodeElement
Deferred to RTF
In general most operations in the whole specification are redundant since they are merely the accessors of the properties. Such operations are never explicitly documented
9.5.1: Property 'density' should be a derived property: it is merely the count(self.relation) and is read only.
9.5.1 Semantics: should be expressed in OCL
9.6: These types should be declared as <<primitive>>
Deferred to next RTF to allow more discussion
10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.
Defer to the next RTF to assemble a more compelling package that justifies the change to the KDM XMI schema
10.4 would be better to have a proper 'date' type rather than using String. This could be properly mapped to the XML Schema type for validation.
Deferred to next RTF to allow more discussion
Validate KDM examples in the KDM specification usign the KDM SDK validator tool and make corrections
Deferred to next RTF
throws example in the spec is incomplete
Deferred to the next RTF
Consider Uniform representation of exception object and classes as they are being thrown
(check out Ada, it uses and extendable enumerated class)Deferred to the next RTF to allow more discussion
PtrCall for callable units and method units a->foo() or should it be only used for callable units; while for method units is a VirtualCall ? relationship is Dispatches, not Calls The text of the specification needs to be made more clear
Defer to the next RTF due to the lack of time
Call via pointer example: need pointer type in type unit fp
Defer to the next RTF.
For discussion. When transforming procedures to methods KDM objects needs to be changed, it is not as easy as moving something to class. We should consider having a StorableUnit and CallableUnit, maybe with an explicit kind. This will leave the only distincltion between them in micro actions.
Defer to the next RTF.
specify which characterset is used for chartype or provide the capability to extend Issues in KDM representation of funny Unicode symbols back and forth. Need some sort of translation. And need to specify what it the canonical representation in KDM ? Text needs to be made more specific.
Defer to the next RTF.
There is an ambiguity between BlockItem and micro action compound. The specification text has to be made more clear
Defer to the next RTF.
Initialization block? Maybe need a special ControlElement for it. Maybe represent it with a BlockUnit not a CallableUnit. What is the semantics of passing control to other init blocks? The text needs to be made more clear
deferred to next RTF
In Initialization example do not need to use extern in the names
Defer to the next RTF.
Variable d2 in main in compilation unit b.cpp does not have a HasValue relation; need to see how to represent constructor calls.
Defer to the next RTF.
name of CompilationUnit should not contain extension. The text should make that more explicit and the exampel needs to be changed.
Defer to the next RTF to allow more discussion
Association between CompilationUnit and SourceFile other than through SourceRef.
Defer to the next RTF to allow more discussion
variables that are declared at the header of the loop needs special care in KDM. Suggestion: to use VisibleIn relationship in addition to a compound statement for loop. Need an additional example
Defer to the next RTF
Representation of a stand-alone comment (not associated with a particular CodeElement)
Defer to the next RTF
Clarify the text regarding the distinction between the explicit relationship and the built-in relationships
Defer to the next RTF
Clarify the algnment with SBVR, update references to the current SSBVR specification
Defer to the next RTF due to the lack of time
Clarify alignment of the KDM Core with RDF
Defer to the next RTF due to the lack of time
Currently RecordFile in DataModel owns ItemUnits. We are missing a RecordType, so that we can define a StorableUnit, corresponding to a record, and use that RecordType for the Type attribute of that StorableUnit. We need the StorableUnit for Addresses, etc. It is important that the RecordFile owns the RecordType, because we want to have associations going to the RecordFile whenever its fields are used in the code. Suggested resolution: generalize owned elements from ItemUnit to CodeItem.
In the ConceptualRelations Class Diagram in the KDM specification (see page 269) indicates that ConceptualFlow class has two associations socalled ‘to’ and ‘from’ on ConceptualContainer class. However in the section that explains the associations (in same page) indicates that they are ‘to’ and ‘from’ associations that have AbstractConceptualElement type (superclass of ConceptualContainer class). ”
The KDM documentation is missing a small documentation piece that should be: 12.3.7 Module Class (generic)
Page number refers to the pdf page number as in "178/334." Page numbers in parenthsis refers to the page number at the bottom of each page.
"Constraints" sub-section in the descriptions seems to be rarely needed. That is not a problem, but I read through many sections wondering what it was used for and why it appeared. Might be useful to enter a "None" beneath each one with no constraints so it is clear that it is a placeholder and that there are no constraints for that section.
p.25 (p.3) Confusion: If L1 compliance implies full realization of L0, then what purpose does L2 serve? You can have L0 compliance or L1 compliance, but wouldn't L2 compliance be the same as L1 compliance since both imply L0 and L1 compliance? In short, I don't see what purpose L2 serves -- maybe additional text is needed on L2 in this section.
p.31 (p.9) bottom of page -- "Logically, KDM consists of 9 models." -- is it 9 because the infrastructure layer elements are not counted as models?
p.32 (p.10) "KDM is a MOF model" should be "KDM is a Meta-Object Facility (MOF) model"
p.32 (p.10) "KDM is aligned with ISO/IEC 11404 Language-Independent Datatypes and SBVR" -- spell out SBVR
p.33 (p.11) "The Kdm package provides the..." should be "The kdm package provides the..." p.33 (p.11) "the infrastructure. kdm package" should be "the infrastructure. The kdm package"
p.34 (p.12) Bullet in section 8.2: "The Kdm package provides static context shared by all KDM models" should be "The kdm package provides static context shared by all KDM models"
p.35 (p.13) "Small KDM core..." -- need description or introduction as to what this is. Suggest going over and rewriting the section on the core package in "Part 1"
p.42 (p.20) Constraints sub-section -- item in that section should be numbered (e.g. "1. The set...") to be consistent with other Constraint sub-sections. Same is true of other Constraint sub-sections, so the rest need to be checked.
to: KDMEntity[1] The target container of the relationships in the aggregated set. All relations in the aggregated set should terminate at the target container or at some entity that is contained directly or indirectly in the target container.
from:KDMEntity[1] The source container of the relationships in the aggregated set. All relationships in the aggregated set should originate from the source container or from some entity that is contained directly or indirectly in the source container
p.32 (p.10), p.79 (p.57), and other places: "ISO/IEC 11404" should be "ISO/IEC 11404:1996" -- you may even want to update this to be "ISO/IEC 11404:2007" which is the latest version and for the purposes of this document would not likely be different.
p.85 (p.63) In the Constraints section of 12.3.5 and 12.3.6, the numbers are 2 and 3 instead of 1 (looks like Words autonumbering feature is helping you)
p.101 (p.79) I don't see the use for the DateType Class. As ISO 11404 does, I suggest having only the TimeType Class and removing 12.9.5 DateType Class. BTW, I like the addition of the Decimal class -- I'm a little puzzled why ISO 11404 doesn't have it. For the most part, I would suggest being in total sync with 11404 should be the default and only in selected (very rare) instances should there be deviations. Also, being in sync with the order and structure of chapters 8 and 10 of ISO 11404:2007 would be better, particularily when fast tracking this through ISO.
p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.
deferred to next RTF
Section 12 -- I like the examples (e.g. "An example of a choice datatype is a Pascal and Ada variant record, and a union in the C programming language.") -- maybe a new Example field could be added to the Superclass, Constraints, Semantics, etc. fields for all parts of Section 12 -- 12.11.3 already has this and I think it is the only entry that does.
deferred to next RTF
KDM is missing constraints capabilities to stereotype. It is nice to have a metamodel element to express: * a description (in plain english) of the constraint. * the constraint language used (e.g. OCL) * the constraint expression * the severity of the constraing (WEAK / SEVERE)
AbstractEventElement should group KDM Elements (instead of AbstractCodeElement). This allows us to attach an Event model also to other part of the model
Component should allow one to express exposed and required services. An entity connection should be also created to manage the connections between them.
Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews
Related to clause: 3 See above. And if you want to refer OMG documents, write reference like: IEC Std Template, IEC, available at http://www.iec.ch/tiss/templates.htm
ISO/IEC formatting template to be applied during the production of the ISO/IEC version Disposition: Deferred
We are proposing changing the Audits relation that is now from KDMFramework to Audit and instead having it from ModelElement to Audit. That change would allow audits to be attached not only to segments and models, but sometimes to other element as well. For examples, Modules or CompilationUnit are prime candidate for us as they are initially produces independently and then brought into a bigger KDM.
deferred to next RTF
Currently the KDM doesn’t allow for the stereotyping of Audit elements since those inherit from Element and not ModelElement. We believe that this is an oversight, as a reading of the specification uses the Audit element by name as one of the possible owner of a stereotype (10.5.1 constraint #5: KDM meta-elements (for example, “KDMEntity,” or “Audit”)) or the endpoint to a TaggedRef (10.5.2 constraint #4: KDM meta-element (for example, “KDMEntity,” or “Audit”)) We are proposing the following changes to restore this capability that was clearly intended to exist in the first place: · Move the stereotype relation from ModelElement to Element · Change the endpoint of the reference relation in TaggedRef to now point to Element instead of ModelElement · Change all text that refers to ModelElement as being subject to extension in favor of Element Another possible approach that might be simpler is to derived the Audit from ModelElement instead of Element. Probably the only issue at hand is if it fits the definition given in 9.3.2 as being an element of the existing software system or not. That is a bit of a stretch here, but we could see this as being argued either way in the case of Audit.
The current specification describing the BinaryFile Class file is either incorrect or misleading at best. Since all files are ultimately binary, the BinaryFile Class, it seems, is more defined in terms of exclusion rather than inclusion. Normally we would consider human readable files as text files and non-readable files as binary. This is clearly not the definition used in the KDM context, as we would then have Image and ExecutableFile as extending BinaryFile. So given the fact that BinaryFile first doesn’t follow general conventions, it should then be better defined. As it can probably be interpreted from reading the specification here, a BinaryFile is any file that doesn’t fit in any of the other type of files extending InventoryItem. But that would still leave us with issues of how to represent files that are clearly Text files, but not SourceFile, Configuration or ResourceDescription.
Currently the KDM defines 6 classes that are derived from InventoryItem and each of those is documented to represent files of some sort, but the naming is inconsistent. 3 of them have the File suffix and the other 3 don’t, leaving the user to question the categorization difference, which doesn’t seem to really exist when reading the documentation.
deferred to next RTF
At the start of page 224, a 'Flow' is defined that goes to="id.47" from="id.44". This should be conditional ('FalseFlow'), since 'WITH TEST AFTER' is not used in the 'PERFORM' statement. This would be consistent with the 'FalseFlow' defined in 'id.64'. Suggestion: Move 'id.64' up to before the loop starts (after id.44) and remove the unconditional 'Flow' from 'id.44'. This improves action element arrangement with respect to their associated Cobol code snippets. Also, action elements corresponding to Cobol statements subordinated to the inline PERFORM appear at the same indentation level as action element 'id.64'. If this action element is indeed moved up, those dependent action elements should probably become part of its 'codeElement' children.
According to this spec(P64), "Package" is subclass of Modules. In that case, what is the base class of Module? (CodeItem is superclass of Module. However, CodeItem is not original UML base element.) Considering above, it seems this "Package" is different from original UML Package. From my understanding, (I think,) if this spec use the Module, Module is a subclass of Package (which is from original UML), and change the name of "Package", which are shown in Page 64 and Page 66, to "Container" (something like that). Disposition: Deferred
Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification.
It is not clear whether the issue is with the general approach within KDM to representing packages in existing systems, or about Figure 8.1 in the KDM specification, showing packages on KDM itself. Additional discussion on November 30: Clarification request: The issue is about the modelling elements of the KDM that allow representation of the packages within some existing system, as well as relationships between these packages, so that the corresponding KDM view can be described using a UML package diagram. Please let me know if this interpretation of the issue is correct. Assuming that this interpretation is correct, existing KDM specification already has several relevant mechanisms. KDM has Package meta-model element (section 12.5.6, part of the Code package and the corresponding Code viewpoint). This element represents packages in existing software systems, as well as similar module constructs. The Package element is the endpoint of several KDM relationships. First, a Package may "contain" other KDM elements. Second, some element may "import" a Package using the Imports relationship, or be "Visible in" a Package using the "VisibleIn" relationship. However, most importantly, KDM defines the mechanism of "aggregated relationships" by which relationships between Packages can be derived from the individual relationships between the contained elements of these Packages. KDM specification does not define any diagrams, however the KDM Code views involving Packages can be mapped to a UML Package diagram. So, provided my interpretation of the issue is correct, KDM already has the necessary modelling elements to describe relationships between packages of existing software systems. In fact, several KDM compliant tools already produce package diagrams of existing software based systems. Response from the originator of the comment: I checked KDM spec. again. “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to >Describe it using Package diagram. The issue is about the modelling elements of the KDM that allow representation of the packages within some existing system, as well as relationships between these packages, so that the corresponding >KDM view can be described using a UML package diagram.” Your interpretation is correct. My comment means that it is necessary to define package structure using Package diagram. “KDM has Package meta-model element (section 12.5.6, part of the Code package and the corresponding Code viewpoint). This element represents packages in existing software systems,” <..> my original question is based on the Figure 8.1 Page 11. This figure shows package structure of KDM. In general, multiple Package structure specification like UML need to be defined using Package diagram, to clarify their structure/relationship. This Figure 8.1 is not precise definition of Package structure (different from regular definition). To clarify this structure, it is necessary to specify the Package structure usign UML, because there is no precise way to define package structure except UML package diagram. According to this spec(P64), "Package" is subclass of Modules. In that case, what is the base class of Module? (CodeItem is superclass of Module. However, CodeItem is not original UML base element.) Considering above, it seems this "Package" is different from original UML Package. From my understanding, (I think,) if this spec use the Module, Module is a subclass of Package (which is from original UML), and change the name of "Package", which are shown in Page 64 and Page 66, to "Container" (something like that). Disposition: Deferred
In the Action Package, the codeElement at the to endpoint of the ActionElement, AbstractCodeElement relation should be marked as ordered. This would be consistent with all other subsets of ownedElement with a mulitiplicity greater than 1 from the code model that also point to AbstractCodeElement which are all ordered. Given that these are owned code elements, and I quote, “nested action elements, or nested BlockUnits, or nested definitions of datatypes and computational objects”, losing the ordering of such elements goes counter to the design of the code model and has huge impact as we have to make ordering assumptions to make sense of the content.
The current KDM has known issues regarding the expression of modifiers for ClassUnit, MethodUnit, MemberUnit and to a certain extent ParameterUnit and StorableUnit. The issue is that some of the kind enumeration are tied to a class but in reality can apply in other places and that those enumeration are single valued where in real life usage we would need to often specify more than one value. Some concrete example: 1- ClassUnit (and InterfaceUnit) supports no modifiers (or kind enumeration in KDM speak). This issue was raised in 2006 and never addressed. How can we, without resorting to stereotypes, which are not very interoperable, describe a Java class that is “final public” or “static” 2- MethodUnit has a MethodKind but it has no ExportKind which would be a start to try to capture a Java method like “final protected” (also needs multi-value) 3- ParameterUnit has a ParameterKind but it again has no ExportKind. So another example, your Java method parameter that is declared as “final” (or is that an “ImportKind”) 4- MemberUnit represent for example Java field class member (JLS names). There we have ExportKind but like other places for Java modifiers it would be missing “static”, “transient”, “volatile” and a way to express “default”, unless we agree that it is in force if none of public, private or protected is specified. But we should be able to easily support a field declaration such as: “private static final String CONST1 = “xx”; “ I am not sure what the best approach is here in all regards. First I think we must change the cardinality to support multiple “modifiers” for the same “unit”. We also need to look if we want to simply expand the ExportKind and move it to the ComputationObject class instead of being at the MemberUnit level. That obviously expands the classes that can make use of it, but it addresses most of the issues, except for the ClassUnit and InterfaceUnit which are children of DataType
The references to UML, MOF and XMI in the KDM 2.2 are not appropriate. The references to 19502:2005 and 10503:2005 are not used anywhere in the spec and should be removed. The ref to MOF should be to the actual version used. The proposed resolution below assumes the Latest Versions used are MOF 2.0 and XMI 2.1.1. Proposed solution: In section 3 Change: “ 3 Normative References The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply. • OMG UML 2.2 Infrastructure Specification formal/2009-02-04 • OMG Meta-Object Facility (MOF) ver. 2.0 formal/2006-01-01 • OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-02 • ISO/IEC 19502:2005 Information technology -- Meta Object Facility (MOF) • ISO/IEC 19503:2005 Information technology -- XML Metadata Interchange (XMI) • ISO/IEC 11404:2007 Information technology -- General-Purpose Datatypes (GPD) “ To: “ 3 Normative References The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to or revisions of any of these publications do not apply. • OMG UML 2.4 Infrastructure Specification <omg spec ref URL> • OMG Meta-Object Facility (MOF) ver. 2.0 <OMG spec ref URL> • OMG MOF XML Metadata Interchange (XMI) ver. 2.1.1 <OMG spec ref URL> • OMG Semantics of Business Vocabularies and Business Rules (SBVR) Ver 1.0 formal/08-01-02 • ISO/IEC 11404:2007 Information technology -- General-Purpose Datatypes (GPD) "
In section 12.6.4, the Superclass of MethodUnit is shown as CallableElement instead of the current ControlElement
After changes from Ballot 11 in 2007, the micro-KDM the documentation was not updated to reflect the fact that the invokes relationship didn’t exist anymore. We currently still have 4 micro-KDM actions that describe Invokes relationships: MethodCall, VirtualCall, MemberSelect, MemberReplace. These need to be changed to the Adresses relationship at the very minimum.
In section 21.5, BuildResource class diagram, the class Library and BuildProduct are described in the diagram 21.3 but have no description in the text of the specification. However references can be found in examples and they are part of the XMI model. I believe that standard documentation sections should be added for these classes.
In the platform package we don't seem to have any direct way to express relations between AbstractPlatformElement and InventoryElement. A good example is how to describe the file in the inventory model that represents a certain deployed component. AbstractPlatformElement has a source relation to a SourceRef but here we're not dealing with a Source inventory element (not sure how often PlatformElement would really need this relation). The Build package uses the implementation relation which points to KDM entity to describe relations to inventory elements. Again here in the platform package this points to AbstractCodeElement only. I hate to have to use stereotypes to build such a basic relation.
There is an inconsistency between the documentation in the KDM build package and the example in the section. The example shows a BuildStep consuming it's input source elements which are classified as BuildComponent. In the description for BuildComponent we have: "The BuildComponent class represents binary files that correspond to deployable components, for example executable files." Obviously the input source elements being consumed in the example are .c and .h files, which are not binary. So is BuildComponent the right class to use for input source elements or is the description of the class incorrect?
In section A.2 of the Micro-KDM annex we have: Negate Polymorphic unary negate operation for two values of the same numeric datatype; see ISO Negate operation for the corresponding datatype. If negate is unary it probably doesn't apply to two values.
We found a bug in our Java KDM implementation, but after review it sneak in because of the fact that Java enum are special classes and thus can have their own methods. In 12.10 the KDM defines EnumeratedType which subsets the ownerElement relation to the value relation against Value. In 12.15, ClassUnit subsets that relation to codeElement against CodeItem, allowing MethodUnit children among other things. So, how would you represent a Java enum, as an EnumeratedType but then what do you do with the Methods defined in the enum, or as a ClassUnit and then what do you do with the Values. Or can we define the Java enum as a ClassUnit that will contain the class behavior of the enum, with an HasType relation to an EnumaratedType instance that will hold the value and the representation of the enum portion? Thanks for your insight in clarifying this situation.
In the Conceptual package (Section 20) of the KDM specification, there is a constraint described in Fig. 20.4, that forces an AbstractConceptualElement to be associated to one and only one ConceptualRole. This does not seem to be justified by the description of a ConceptualRole. Furthermore, the example provided in Section 20.6.1 does not respect this constraint. In this example, there are two rule units that define 2 different roles that are associated to the same fact. The impact of this requirement is that a Term Unit cannot be play a role in multiple FactUnits, and a FactUnit cannot play a role in multiple RuleUnits. If this is correct, a clarification would be advisable.
In Section 12.14.1, there is an inconsistency concerning the DefinedType class. The cardinality of the "codeElement" containment reference in Figure 12.12 is 0..1 (zero or one) while it is described as 0..* (zero to many) in the description of the class that follows the diagram (Anonymous datatypes used in the definition of the datatype). To be consistent with the class description, the relationship in the diagram should be corrected to read 0..*.
The association AbstractCodeElement has the following description: codeRelation:CodeRelation[0..*] The set of code relations owned by this code *model*. It should read: codeRelation:CodeRelation[0..*] The set of code relations owned by this code *element*.
Table A.5 describes Access options, two of which have optional outputs. The description of outputs of Ptr and ArraySelect read 'optinal' rather than 'optional'
The example used to describe the difference between micro and non-micro kdm support contains several errors. From example in Chapter 14: id.11 id.80 id:85 -> Flows do not have 'to' id.45 -> should be of type Pointer (id.103) id.55 [ArraySelect] -> Select is on an array of pointers, the register (id.45) should be a pointer. id.61 [PointerReplace] -> PtrReplace is missing the addresses (first reads should become an addresses) id.92 -> Missing Addresses id.103 -> Array contains pointers (not integers), Array operations should reflect this In normative ANNEX: A.5 PtrReplace inputs should be corrected to 'single reads relationship' rather than last read.
The following classes refer to StructureGroup as their superclass instead of AbstractStructureElement. 19.3.4 Subsystem Class 19.3.5 Layer Class 19.3.6 Component Class 19.3.7 SoftwareSystem Class 19.3.8 ArchitectureView Class
The micro definition for kinds Incr and Decr is ambiguous. First, they are described in the preamble of A.2 and A.3. The description indicates that they should have a Reads and a Writes, which makes sense since they might represent the code for something like 'i++'. Second, they are described in the table under A.4. Control Actions. This would imply that they are used for control, but I don't understand why that would be the case. Furthermore, these ActionElements would have only an Addresses relationship, but that does not match the definition of an Addresses class (access to complex data structure/pointer). It would be helpful to know what is the correct description.
Virtual calls should have an Addresses to indicate what is the object that is being passed a message. Currently, the only action relations that are required describe the parameters and the next control flow. IMO, a VirtualCall should match a PtrCall that requires a "Addresses relationship to the DataElement that represents the pointer". In the case of the Virtual call, it should probably read "Addresses relationship to the DataElement that represents the object", and perhaps specify that the DataElement should be of ClassUnit type.