ModelElement taggedValue association has the ExtendedValue type instead of the taggedValue as specified in the KDM spec.

This issue is related to KDM14-20

Problem: During the code model generation for Java we want to identify which class are in fact interfaces. Problem is that we basically need to identify which classes are interfaces upfront or have the ability to convert KDM "class unit" to "interface unit". However, both the objects presenting these both inherit from datatype but at the java code level one can't convert (i.e.) cast from ClassUnit to InterfaceUnit.

Question: from an implementation point of view would it better to have a class object with an Interface attribute? For example the ClassUnit object has isAbstract. Can we implement isInterface to ClassUnit?

This change will make it easier to change the type of a given KDM object.

Note: Java 1.8 will start to allow code in interface specifications which will blur the lines between interface/class specifications.

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.

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)

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.

p.102 (p.80) Suggest calling FloatType RealType to be consistent with ISO 11404.

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.

Consider Uniform representation of exception object and classes as they are being thrown
(check out Ada, it uses an extendable enumerated class)

9.5.1 Semantics: should be expressed in OCL

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.