Issue 9995: Section: 19
Issue 10123: Break cyclic dependency between Code and Action package
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 11168: 9.3.3 definition of owner
Issue 11169: 9.3.3, association 'group'
Issue 11170: 9.3.3 Constraint 1 seems wrong
Issue 11171: 9.3.3 getOwnerElement is misnamed
Issue 11172: 9.4.1 - CMOF “redefines” mechanism
Issue 11173: 9.4.2 - why 2 separate associations?
Issue 11174: 9.5.1: Property 'density' should be a derived property
Issue 11175: 9.5.1 Constraint 4 is inconsistent
Issue 11176: 9.5.1 Semantics: should be expressed in OCL
Issue 11178: 10.1: 'KDMFramework' is a misnomer - it should be KDMFrameworkElement.
Issue 11179: 10.3.1: Description of 'segment' property
Issue 11180: p31 the XMI example has wrong namespaces for xmi and kdm and audit
Issue 11181: 10.4 would be better to have a proper 'date' type rather than using String
Issue 11182: 10.4: use of 'author' is redundant
Issue 11183: 10.4.1: Audit.description
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 11712: Consider representation of a switch
Issue 11713: Need a counterpart of the HasValue relation
Issue 11714: PtrCall for callable units and method units a->foo() Add uppercase requirement for the names of micro KDM operations
Issue 11715: Add uppercase requirement for the names of micro KDM operations
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 11719: representation of the sizeof (type) operator as opposed to sizeof (expr) op
Issue 11720: Correct specification text:
Issue 11721: There is an ambiguity between BlockItem and micro action compound
Issue 11722: Discuss using the name of the action element as label
Issue 11723: Initialization block?
Issue 11724: More than one label on a statement
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 11729: Need to make Datatype generic, for the sake of using it in with stereotypes
Issue 11730: text should mention optional writes in micro kdm and an example with a+1;
Issue 11731: change text for the arrayselect "single" reads
Issue 11732: representation of this-> and this variables that are declared at header of loop needs special care in KDM
Issue 11733: variables that are declared at header of loop needs special care in KDM
Issue 11734: Description of the multidimentional arrays is confusing.
Issue 11735: There is a problem with Throws relation and Throw micro operation
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 12420: invalid XML - ptc-08-02-10.xml KDM 1.1 CMOF XMI
Issue 12421: CMOF and XMI namespaces incorrect - ptc-08-02-10.xml KDM 1.1 CMOF XMI
Issue 12422: Rename these associations to SignatureType and SourceFileRegion respectivel
Issue 12423: Association A.62
Issue 12424: Many associations and association ends are given meaningless generated name
Issue 12425: Several association ends are both 0..* and composite owners
Issue 12480: BindsTo relationship should have a more general “to” endpoint
Issue 12481: RecordFile and Datatypes
Issue 12482: kinds for resource actions
Issue 12483: SourceRef in Build package
Issue 9995: Section: 19 (kdm-rtf)
Click here for this issue's archive.
Source: International Business Machines (Mr. Howard Hess, h2@us.ibm.com hmhess1@yahoo.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
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.
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.3.3 definition of owner has its type as KDMContainer which is inconsistent with the preceding figure which has it as recursive
Correct text: Section 9.3.3, Page 17, description of the first association. Change owner:KDMContainer[0..1] into owner:KDMEntity[0..1] Change “KDM container that…” into “KDM entity that …”. Change “Every specific KDM container defines…” into “Some KDM entities define …” Disposition:
9.3.3, association 'group' has "The group of a KDM entity is defined as the group..." which is inconsistent with the next sentence and the metamodel which says an entity may be in many groups.
Correct text Correct text: Section 9.3.3, Page 17, description of the second association. Change group:KDMGroup[0..*] into group:KDMEntity[0..*] Change “Set of KDM groups with which…” into “Set of KDM entities with which …”. Change “Every specific KDM group defines…” into “Some KDM entities define …” Add clarification to the second paragraph of 9.3.3 that introduces containers and groups: A KDMEntity can be either an atomic element, a container for some KDMEntities, or a group of some KDMEntities. Container and group introduce implicit relationships between entities and are used to represent hierarchies of entities. A container is a KDMEntity that owns other entities. A group is a KDMEntity with which other entities are associated. A KDMEntity can be owned by at most one container, and can be associated with zero or many groups.
9.3.3 Constraint 1 seems wrong - why not group X that is owned by something else? At minimum this should be explained in the semantics. If it is valid then it would be better shown as an XOR constraint.
9.3.3 getOwnerElement is misnamed - should be getOwnedElement.
Correct text Change getOwnerElement into getOwnedElement
9.4.1: "In KDM this is represented by the CMOF “redefines” mechanism. Concrete properties redefine the “union” properties of the parent classes, defined in the Core package." However by using {redefines} and not {subsets} it is largely defeating the point of using a derived union - since redefines makes the derived end unavailable!Deferred to next RTF to allow more discussion
9.4.2 It seems that getOwnedRelation = getOutbound: why 2 separate associations?
9.5.1: Property 'density' should be a derived property: it is merely the count(self.relation) and is read only.
9.5.1 Constraint 4 is inconsistent with the descriptions of 'to' and 'from' which allow entities which are indirectly contained.
Correct text; remove inconsistent constraint
9.5.1 Semantics: should be expressed in OCL
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.3.1: Description of 'segment' property does not mention segment and seems to be a paste from another place
The original posting was incorrectly mentioning section 10.3.1 instead of 10.3.4 Correct text of the description of the segment property: Instances of KDM entities owned by the model. Each KDM model defines specific subclasses of KDMEntity class. Nested Segment elements owned by the current Segment. KDMFramework class is extended by KDMSegment Segment and KDMModel classes. Each KDM Framework is the container for KDM light-weight extensions (extension property).
p31 the XMI example has wrong namespaces for xmi and kdm and audit
Correct KDM XMI with correct namespaces for xmi and KDM packages xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:core="http://schema.omg.org/spec/KDM/1.1/core" xmlns:kdm="http://schema.omg.org/spec/KDM/1.1/kdm" xmlns:source="http://schema.omg.org/spec/KDM/1.1/source" xmlns:code="http://schema.omg.org/spec/KDM/1.1/code" xmlns:action="http://schema.omg.org/spec/KDM/1.1/action" xmlns:data="http://schema.omg.org/spec/KDM/1.1/data" xmlns:event="http://schema.omg.org/spec/KDM/1.1/event" xmlns:ui="http://schema.omg.org/spec/KDM/1.1/ui" xmlns:platform="http://schema.omg.org/spec/KDM/1.1/platform" xmlns:conceptual="http://schema.omg.org/spec/KDM/1.1/conceptual" xmlns:structure="http://schema.omg.org/spec/KDM/1.1/structure" xmlns:build="http://schema.omg.org/spec/KDM/1.1/build" pages: 29, 34, 50, 69, 85, 88, 98, 103, 106, 116, 118, 120, 121, 125 138, 144, 154,219 221, 230, 239, 244, 271, 287
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
10.4: XMI already has the ability to capture the tool creating an instance: use of 'author' for this is redundant
10.4.1: States that an Audit element can onw Annotation elements: it's unclear whether Audit.description should be used or owned Annotation elements.
Make clarification in the text. Change text: description:String Contains the description of the model element Framework element. Audit element can be own Annotation elements and Attribute elements. The Audit.description is the primary description and any associated annotations may be used as optional secondary descriptions.
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
Consider representation of a switch. What action kind is the second action with a reads ? maybe add a new kind "guard"
Add Guard micro action kind to represent things like “case 1:” Guard represents start of the branch of a complex condition Single Reads relation to a DataElement representing the guard value none Single flow unconditional control flow to the first action of the brach
Need a counterpart of the HasValue relation to directly represent complex initializations.
Generalize the “to” endpoint of HasValue relationship from CodeItem to AbstractCodeElement to allow both ValueElement and ActionElement as endpoints. This is a conservative extension that does not affect existing KDM XMI. Change text section 12.19.2 page 106: The HasValue is a specific meta-model element that represents semantic relation between a data element and its initialization data element element, which can be a data element or an action element for complex initializations that involve expressions. HasValue is an optional element that compliments the real initialization semantics by a sequence of action elements in the initialization code. The target datatype AbstractCodeElement. Constraints: 1. If the target of the HasValue is an ActionElement then this ActionElement should have an outgoing Writes relationship to the CodeItem that is the the source of the Hasvalue relationship Semantics: The target of the HasValue relationship can be a Value for simple initializations that involve constants, or Data Element for simple initializations that involve another data element, or an ActionElement that writes to the source element for complex initializations involving expressions.
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
Add uppercase requirement for the names of micro KDM operations. Make the text more clear.
Add clarification to the text Page 154 Action Kind - is nature of the operation performed by the micro action. This is represented as a “kind” attribute to the micro action. The action kind may designate certain outgoing relationships as part of the Control. For example, the “call” “Call” micro action designated designates the Calls outgoing relationship as part of Control. Action kinds are defined as case sensitive strings in Annex A.
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.
representation of the sizeof (type) operator as opposed to sizeof (expr) operator
Sizeof should not have Reads ? Maybe addresses ? Maybe we need another micro action for sizeof type,
with a UsesType relation.There are two alternatives: just have UsesType to the Datatype, or allow also Reads to DataElement (in the later case the processor should be able to calculate the type from the expression first): Sizeof Determines the length of a DataElement (based on the datatype) or the length of a Datatype Reads represents the DataElement; or UsesType writes to a DataElement Single flow to the next micro action Disposition:
Correct specification text: in the definition of InstanceOf - relations in UsesType, not usesCode. Dyncast, typecast
There is a typo in Table A.6. It mentions UsesCode relationship instead of UsesType. Correct text in Table A.6 page 299: Instanceof Performs dynamic type check if the data element is of a certain datatype Reads represents the DataElement; UsesType relation represents the datatype Writes to a DataElement of a Boolean type; Single flow to the next micro action DynCast Performs a dynamic cast of a DataElement to a certain Datatype Reads represents the DataElement; UsesType relation represents the datatype Writes to a DataElement Single flow to the next micro action TypeCast Performs a static type conversion of a DataElement to a certain Datatype Reads represents the DataElement; UsesType relation represents the datatype writes to a DataElement Single flow to the next micro action
There is an ambiguity between BlockItem and micro action compound. The specification text has to be made more clear
Defer to the next RTF.
Discuss using the name of the action element as label; if this is ok; add to specification
alternatively we can use a Nop with a name as a label.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
More than one label on a statement (weird as it may be).
a: b: c: x=1; switch(x) case 1: goto a; case 2: goto b; case 3: goto c; }
-> this can be represented as a sequence of Nops.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
Need to make Datatype generic, for the sake of using it in with stereotypes
Currently the Datatype element is abstract. All of its counterparts: ControlElement, DataElement and Module are generic, i.e. concrete from the MOF perspective so that they can be instantiated in KDM XMI, but underspecified from KDM semantics perspective, so that they can be used as extension points with stereotypes. In the context of using KDM together with SBVR in a rule based environment there is a need to specify general endpoints of relationships (and later to provide more concrete elements). In order to achieve this, Datatype has to be made generic. This change does not affect existing KDM XMI documents, or any existing KDM implementations. Make Datatype concrete class; change txt to indicate that it is generic, add constraint Also make generic ComputationalObject, and ValueElement
text should mention optional writes in micro kdm and an example with a+1;
Correct text: Writes and single Flow are optional in most cases. Add word optional to the description of the micro elements where appropriate. Page 291 in front of table A.1 Optional Writes .. (no Writes corresponds to an expression statement, where the result of the operation is ignored; otherwise the result should be stored into a DataElement, which can be permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind) Optional single flow … (no Flow corresponds to the terminal action) Page 292 in front of table A.2 Optional single Writes … (no Writes corresponds to an expression statement, where the result of the operation is ignored) Optional single flow … Page 292 in front of table A.3: Optional single Writes … Optional single Flow … Assign: optional single flow Call: subsequently – an optional single flow … MethodCall: subsequently an optional single flow … PtrCall –subsequently an optional single flow to the next micro action is performed VirtualCall – subsequently an optional single flow … Condition (in the writes column) none Return (in the writes column) none Nop – optional single flow Incr – optional single flow Decr – optional single flow Switch – an optional single flow Page 297 Table A.5 Remove last column Add description of the Control in front of the table: Inputs – see table Outputs – see table Controls – optional single Flow to the next micro action (no Flow means a terminal action element) Move the semantics comment from the control column in the second column for the “New” micro element: This micro operation does not invoke the constructor of the new object; FieldSelect, ChoiceSelect, Ptr, PtrSelect, ArraySelect, MemberSelect – optional Writes …Page 299 Table A.6 Remove last columns Add description of the control in front of the table: Inputs – see table Outputs – see table Controls – optional single Flow to the next micro action (no Flow means a terminal action element) InstanceOf, DynCase – optional Writes … Page 300, table A.7 Remove last 2 columns Add description of the writes and control in front of the table Inputs – see table Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement, where the result of the operation is ignored; otherwise the result should be stored into a DataElement, which can be permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind) Controls – optional single Flow to the next micro action (no Flow means a terminal action element) Page 301, table A.8 Remove last 2 columns Add description of the writes and control in front of the table Inputs – see table Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement, where the result of the operation is ignored; otherwise the result should be stored into a DataElement, which can be permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind) Controls – optional single Flow to the next micro action (no Flow means a terminal action element) Page 302, table A.9 Remove last 2 columns Add description of the writes and control in front of the table Inputs – see table Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement, where the result of the operation is ignored; otherwise the result should be stored into a DataElement, which can be permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind) Controls – optional single Flow to the next micro action (no Flow means a terminal action element) Page 303, table A.10 Remove last 2 columns Add description of the writes and control in front of the table Inputs – see table Outputs – optional Writes to a DataElement (no Writes corresponds to an expression statement, where the result of the operation is ignored; otherwise the result should be stored into a DataElement, which can be permanent, for example a StorableUnit with a kind other than “register”, a MemberUnit, an ItemUnit or a ParameterUnit; or temporary, a StorableUnit with a “register” kind) Controls – optional single Flow to the next micro action (no Flow means a terminal action element)
change text for the arrayselect "single" reads
There is a typo in Table A.5 page 297 in specification of ArraySelect. Correct text in Table A.5 page 297 ArraySelect Access to a particular ItemUnit of an ArrayType Single Addresses relationship to a DataElement (of an ArrayType); Single Reads relationship to an ItemUnit representing the ItemUnit being accessed; Last Reads represents the Index Writes relationship represents the DataElement (except for a ValueElement) to which the value of the ItemUnit is assigned Single flow to the next micro action
representation of this-> and this. there should be some sort of addresses to the class or something like that. There is an example (initialization) but it may need some corrections. The example simply writes to the class member. The problem is that this is not distinguishable from simply num=x; (the example has this->num=x;) Maybe there should be a microoperation "this"?
This operator is used to resolve the scope of names in situations when the name of the formal
parameter is the same as the name of the class member. For example:
set(a) {this.a =a; }
// Take a const-reference to the right-hand side of the assignment.
// Return a non-const reference to the left-hand side.
MyClass& MyClass::operator=(const MyClass &rhs) {
... // Do the assignment operation!
return *this; // Return a reference to myself.
}
MyClass& MyClass::operator=(const MyClass &rhs) {
// Only do assignment if RHS is a different object from this.
if (this != &rhs) {
... // Deallocate, allocate new space, copy values...
}
return *this;
}
Add micro operation
this no reads or addresses; writes to a data element of the class datatype;
This pointer to
the current
instance of
the object
none Writes to a
DataElement
Single flow
to the next
micro
actionvariables 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
Description of the multidimentional arrays is confusing. Need to clarify the text.
Add clarification to the text Multidimensional arrays can be represented where an ItemUnit is referencing an anonymous ArrayType that represents internal dimensions(s). The IndexItem of the ArrayType that owns an internal anonymous ArrayType precedes the IndexItem of the owned ArrayType. Multidimensional array are represented by nested ArrayType elements, in which the top ArrayType represents the first (outer) dimension, and its ItemUnit has type ArrayType that represents the next (internal) dimension and so on.
There is a problem with Throws relation and Throw micro operation: Throws relation is to an object! but Throw says that there are Reads. Reads should be part of the constructor, there should be new, bla-bla, constructor call. Big question mark. Throws should be a shortcut - relationship to the exception class. with a single Reads to the exception object. Because we do not want to duplicate the constructor call logic.
Table A.4 page 295. Throw raise exception zero or more Reads relationships to DataElements representing actual parameters to the the the exception object being thrown none Throws relationship to the datatype DataElement that represents the "exception object". Optional ExceptionFlow relationship to a CatchUnit that processes the exception Disposition: Resolved
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
The file is invalid XML, since for the 'type' attribute of Operations it omits spaces after the closing quote of the previous value.
For example line 784 is:
<ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*'type='C.6698801' />
Proposed resolution
Insert space before 'type=' in all Operation definitions. The above line becomes:
<ownedOperation xmi:id='OP.28195661' xmi:type='cmof:Operation' name='getInbound' lower='0' upper='*' type='C.6698801' />
The CMOF and XMI namespaces are incorrect (they include an extra 'www') Line 1 of the file is: <XMI xmlns:xmi="http://www.schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://www.schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1"> Proposed resolution Include correct namespace definitions, so that the above line becomes: <XMI xmlns:xmi="http:// schema.omg.org/spec/XMI/2.1" xmlns:cmof="http://schema.omg.org/spec/MOF/2.0/cmof.xml" xmi:version="2.1">
Signature and SourceFile are used as both Class and Association names in the same package: this is not permitted by CMOF constraints
Proposed resolution
Rename these associations to SignatureType and SourceFileRegion respectively
Line 256 is currently:
<ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='Signature'>
And should become
<ownedMember xmi:id='A.25972044' xmi:type='cmof:Association' memberEnd='P.G.94 P.G.95' name='SignatureType'>
Line 1083 is currently:
<ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFile'>
And should become:
<ownedMember xmi:id='A.30564957' xmi:type='cmof:Association' memberEnd='P.G.264 P.G.265' name='SourceFileRegion'>
Association A.62 has an owned end is called 'model ' (trailing space), which is inconsistent and invalid for generating language bindings
Proposed resolution
Remove the trailing space
Line 347 is currently:
<ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model ' lower='0' upper='1' isComposite='false' association='A.62' />
And should become
<ownedEnd xmi:id='P.D.11368610' xmi:type='cmof:Property' subsettedProperty='P.D.7559765' type='C.13301479' name='model' lower='0' upper='1' isComposite='false' association='A.62' />
Many associations and association ends are given meaningless generated names, like A.0, P.G.307. Since these will be used for the generated language bindings, and are required for traversing and accessing models, these names are not usable. In addition, the inclusion of '.'s in the names makes unnecessary for language bindings since they are not valid Java names.
For example lines 4 and 5 illustrate the names:
<ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707' name='A.2' general='A.3'>
<ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='P.D.14122707' lower='1' upper='1' isComposite='false' association='A.2' />
Proposed resolution:
Generate meaningful names for these elements, using the same algorithm as UML2, which is as follows (from section 6.4 of formal/07-11-02)
* If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached,
modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are
often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal
constraints - although they may be needed for other purposes, such as MOF language bindings that use the metamodel.)
* Associations that are not explicitly named, are given names that are constructed according to the following production
rule: "A_" <association-end-name1> "_" <association-end-name2>
where <association-end-name1> is the name of the first association end and <association-end-name2> is the name of
the second association end.
As an example, lines 4 and 5 would become:
<ownedMember xmi:id='A.2' xmi:type='cmof:Association' memberEnd='P.O.14122707 P.D.14122707' name='A_actionElement_actionRelation' general='A.3'>
<ownedEnd xmi:id='P.D.14122707' xmi:type='cmof:Property' subsettedProperty='P.D.29853041' type='C.8621536' name='actionElement' lower='1' upper='1' isComposite='false' association='A.2' />
Several association ends are both 0..* and composite owners. This is not only an invalid combination but is inconsistent with the specification document and Rose model used for that. This seems to affect the ends that {subset group} (that in the XMI contain "subsettedProperty='P.O.6222315' ")
For example, line 172 of the file is:
<ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='true' association='A.35' />
The fact that this has isComposite='true' is inconsistent with Figure 21.3 of ptc/08-02-08 (the KDM 1.1 spec document) which has no black diamond on the line between BuildResource and Group.
Proposed resolution
Make all Properties that {subset group} have isComposite='false'
For example, the above line 172 would become:
<ownedAttribute xmi:id='P.O.20372204' xmi:type='cmof:Property' isOrdered='false' subsettedProperty='P.O.6222315' type='C.19792917' name='implementation' lower='0' upper='*' isComposite='false' association='A.35' />
Currently the BindsTo relationship has the ResourceType as its “from” endpoint and another ResourceType as its “to” endpoint. As the result there is a lack of capability to capture binding of logical resources to their physical counterparts (such as files in the inventory model). Suggested resolution: generalize the “to” endpoint of the BindsTo relationship to KDMEntity class.
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 mapping for COBOL the code model uses action elements that correspond to various resource packages (in particular, Data, UI, Platform). These action elements are not exactly system calls, so from the micro KDM perspective they should have distinct kinds, at least saying that they represent resource actions. Otherwise the model can not be compliant to micro KDM.
As currently specified in the build package, in figure 21.3 the BuildDescription has a relation to SourceRef with the containment side with a 1 specified. This is forcing any SourceRef to actually have a BuildDescription attached or else it won’t validate. This be 0..1. At the same time, the relationship to SourceRef should originate from BuildResource rather than only from BuildDescription in order for identifying BuildStep for example. Suggested resolution: change multiplicity to 0..1 Change the origin of the relationship to SourceRef from BuildDescription to BuildResource.