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

No Data Available

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

duplicate of issue 9983

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

Missing example of KDM Framework as KDM Instance

No Data Available

Missing example of usage of the Audit element

No Data Available

Section 13.7
Severity: minor
Nature: clarification

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

This should be StorableElement.

No Data Available

Section 13.6.2
Severity: minor
Nature: clarification

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

No Data Available

Section 13.5.7
Severity: minor
Nature: clarification

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

No Data Available

Section 13.5.6
Severity: minor
Nature: clarification

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

No Data Available

Section 13.6
Severity: minor
Nature: clarification

13.6 CallableRelations Class Diagram

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

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

CallableInterface should be CallableElement

No Data Available

Section 13.5.8
Severity: minor
Nature: clarification

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

No Data Available

Section 13.5.8
Severity: minor
Nature: clarification

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

No Data Available

Section 13.5.2
Severity: minor
Nature: clarification

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

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

No Data Available

Section 13.5.5
Severity: minor
Nature: clarification

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

No Data Available

Section 13.5.1
Severity: minor
Nature: clarification

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

No Data Available

Section 13.6.1
Severity: minor
Nature: clarification

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

No Data Available

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

No Data Available

Missing example of Interface and corresponding relations as KDM instance

No Data Available

Missing example of MacroUnit and its usages in section 12.9

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

Missing example of CommentUnit and its usages in section 12.23

No Data Available

Missing example of Visibility relationship in section 12.24

No Data Available

Need to relate platform activations and bindings to UI triggers

No Data Available

DataResource is the same as DataManager, Figure 19.4

No Data Available

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

No Data Available

Section 13.8
Severity: minor
Nature: clarification

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

CodeElement should be a PrototypeUnit

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

Add optional kind attribute to StorableUnit VariableKind with values

No Data Available

Allow multiple SourceRef elements for a given Code element

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

Missing

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

No Data Available

CodeContainer is redundant, since it can not be instanciated

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

TemplateParameterowned by TemplateUnit should be ordered

No Data Available

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

No Data Available

Missing examples of data types and their representations as KDM instances

No Data Available

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

No Data Available

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

No Data Available

CompositeTypeElement should own an ordered list of fields.

is now missing in Figure 12.14

No Data Available

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

No Data Available

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

No Data Available

Missing example of HasType relation as KDM instance

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available