AbstractEventElement should group KDM Elements (instead of AbstractCodeElement). This allows us to attach an Event model also to other part of the model

Proposal does not align with existing mechanisms

EventModel is available to represent some abstractions and link the to lower-level KDM elements. For example, EventModel can be used to represent abstractions of some existing system.
Semantics of EventModel is not strong enough so that these elements can be used to model other KDM elements.

Issue 2507200504 from submitters database Originally raised by Mike Smith (EDS) BuildDescription should have relation "implements" to BuildModel

Does not fit the current design

In current KDM a model is simply a container of facts. There are currently no relations involving models. A BuildDescription represents transformation, and there is a relation DescribedBy to BuildStep.

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

Defer to KDM 1.5

Defer to KDM 1.5

Issue 1703200602 from submitters database Originally raised by Nick Mansourov Add other types of UI control elements to UI

No need for additional UI elements

There is no need for additional UI elements

Need traceability for indirect messaging relations in Platform package, as per example used in the tutorial.

Defer to KDM 1.5

Defer to KDM 1.5

Component should allow one to express exposed and required services. An entity connection should be also created to manage the connections between them.

Defer to KDM 1.5

Defer to KDM 1.5

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)

Defered to KDM 1.5

More information is needed for the use case.
It is possible to add two attributes to Stereotype:
constraint:String - optional expression of the constraint for the stereotype and the stereotyped elements
language:String - the language in which the constraint is expressed, e.g. OCL
Consumers of KDM can take advantage of this information.
However this can be achieved with current KDM through Attributes.

Issue 1211200522 from submitters database Originally raised by Nick Mansourov Introduce ResolvedMarshalledCall from MarshalledService directly to CodeElement

Defer to KDM 1.5

Defer to KDM 1.5

Issue 1302200602 from submitters database Originally raised by Alain Picard (CastorTech) Missing example of how to represent reflection mechanisms in Java

Defer to KDM 1.5

Defer to KDM 1.5

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

Defer to KDM 1.5

Defer to KDM 1.5

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

Defer to KDM 1.5

Defer to KDM 1.5

Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews

Missing constraints on Structure package elements

Assigning constraints for elements of the structure package is probably beyond the scope of a revision. I do not see the KDM as being a replacement for architecture meta-models, but rather as a connection to a separate architecture representation much like the conceptual package's connection to SBVR (to link to code artifacts for aggregate analysis).

Are missing constraints to specify clearly Subsystems, Layers, Components, SoftwareSystems, and ArchitectureViews

Component should allow one to express exposed and required services. An entity connection should be also created to manage the connections between them.

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)

Issue 1211200522 from submitters database Originally raised by Nick Mansourov Introduce ResolvedMarshalledCall from MarshalledService directly to CodeElement

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 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 1302200602 from submitters database Originally raised by Alain Picard (CastorTech) Missing example of how to represent reflection mechanisms in Java

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

Need traceability for indirect messaging relations in Platform package, as per example used in the tutorial.

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

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

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

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

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

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

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

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

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 1211200521 from submitters database Originally raised by Nick Mansourov Introduce strongly typed MarshalledCall relation between MarshalledService and instance of MarshalledResource

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

to members of the class

No Data Available

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

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

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

No Data Available

Missing parameters to the MacroUnit

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

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

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

Missing example of Visibility relationship in section 12.24

No Data Available

Missing example of CommentUnit and its usages in section 12.23

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

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

Missing example of MacroUnit and its usages in section 12.9

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

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

No Data Available

Allow multiple SourceRef elements for a given Code element

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

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

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

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

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

Add optional kind attribute to StorableUnit VariableKind with values

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

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

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

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

No Data Available

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

No Data Available

Section 9.5.1
Severity: minor
Nature: clarification

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

No Data Available

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

No Data Available

Section 12.10.2
Severity: minor
Nature: clarification

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

No Data Available

Section 11.4
Severity: minor
Nature: clarification

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

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

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

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.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 12.14.1
Severity: minor
Nature: clarification

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

The text mentions RefinementType, but the diagram mention DerivedType.

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

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

No Data Available

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

No Data Available

Consider optimizing the usage of Flow relations by making them

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

No Data Available

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

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

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

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

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 2009200501 from submitters database Originally raised by Nick Mansourov representation of variants (conditional compilation

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 1703200601 from submitters database Originally raised by Nick Mansourov DisplayUnits should be groups for Triggers

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 0302200602 from submitters database Originally raised by Nick Mansourov Action Containers are missing

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

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

Missing examples of various CallableElements as KDM instances

No Data Available

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

No Data Available

TemplateParameterowned by TemplateUnit should be ordered

No Data Available