Issue 8268: MOF 2.0 Core: Exceptions missing for CMOF Reflective operations
Issue 8997: CMOF should not itnore visibilities
Issue 14553: MOF semantics chapter says nothing about ordering of links when association ends are marked ordered.
Issue 15272: MOF 2.0 9.1 Confusing instance superclass statement
Issue 15442: Primitive type values cannot be tested for equality using Reflection
Issue 15608: MOF 2 should merge UML 2 (merged) as opposed to Kernel
Issue 15646: Bad description of set()
Issue 15661: linksOfType needs includeSubtypes parameter
Issue 15825: Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1
Issue 15828: There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15
Issue 15829: Revise conventions to avoid unnecessary duplication of descriptions for operations
Issue 15833: Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties
Issue 16270: MOF does not have the correct semantics for links in the presence of association specialization
Issue 16393: MOF 2.4 issue: duplicated paragraph in section 3
Issue 16394: MOF 2.4 issue: Part III contains the word Gagagaga
Issue 16489: Because MOF merges UML, UML as an instance of MOF is ill-formed
Issue 17049: Invalid restrictions on concrete metaclasses allowed in EMOF and CMOF
Issue 8268: MOF 2.0 Core: Exceptions missing for CMOF Reflective operations (mof2core-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
In ptc/04-10-15, Chapter 9 (EMOF Reflection) has some limited exceptions defined but Chapter 13 (CMOF Reflection) has none
Significant work is needed to develop a complete set of exceptions. Disposition: Deferred
Constraint [7] in section 14.3 of the MOF2 specification says that visibilities will be ignored, everything is assumed to be public, and name classes are possible and should be avoided. This constraint also appears in section 12.4 EMOF Constraints, constraint [4]. This is necessary for EMOF because it does not support package import or visibility. However, CMOF, which is based on InfrastructureLibrary Constructs does support both package import, namespace visibility, and visibility kind. It is not clear why CMOF would define visibility and then introduce a rule to ignore it. Perhaps this rule should be relaxed.
MOF semantics chapter says nothing about ordering of links when association ends are marked ordered. In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether.
The statement in clause 9.1 semantics "Class Element is the superclass of all model elements in MOF, and is the superclass of all instances of MOF model elements." is confusing since instances do not normally have superclasses. The statement could be interpreted to mean that every class always has Element as a superclass including user-defined classes. But this would then make it impossible to model lightweight application classes supporting solely the required functionality. Surely it is every M2 (and M3 and ...) class that has Element as a superclass? At M1 the superclasses are as modelled by the user. This is significant for OCL since OCL inserts at least OclAny as the top type at M1 in order to support some reflective behaviour. If Element really is an M1 superclass, then OCL should align. If Element is not an M1 superclass, OCL should provide its reflection in OclAny.
Reflection package of the MOF defines operation MOF::Element.equals(element:Object):Boolean for testing equality of model elements. Description of this function (on page 16) tells, that "For instances of DataType, returns true if the object has the same value as this Element instance." But instances of particular DataTypes (e.g. Integer, Bolean etc.) are just values (actually, I did not found, where exactly in MOF or UML Infrastructure specification, but somewhere I saw a definition of PrimitiveTypes like "instances of primitive types are identified only by their values"). So they are not Element-s (as I understand, they are Object-s, so each of primitive type, i.e. Integer, Boolean, String, UnlimitedNatural, can be considered as derived from Object, although they are not defined in such a way in MOF specification). As so, instances of primitive type has no operation "equals" (which is quite OK, as they should have no operations - for this reasons they are PrimitiveTypes). So we cannot call "equals" operation as member of e.g. Integer Object. So, we cannot compare two integer objects. Being more specific, let's cosider example (it is invalid call...): some_property.get(lower).equals(MOF::Factory.CreateFromString(integer, "1")) this test for equality (if lower bound of "some_property" equals to 1) is invalid, as "get" operation returns just number (value, instance of Integer), and it has not operation "equals". Note: in example above "some_property" is instance of MOF::Property, which represents some property of some class, and "lower" is either instance of MOF::Property, which represents lower bound of "some_proerty". "integer" is an instance of MOF::PrimitiveType meta-metaclass, which represents MOF::Integer meta-primitive-type. Actually, currently I have no Proposal for solution of this inconsistency, so this message is just report about it.
MOF 2 should merge UML 2 (merged) as opposed to Kernel and use the automated constraints from UML 2.4 production. Since UML2 now has a normative merged metamodel it makes sense to reference this especially since Kernel will be disappearing at UML 2.5. The UML 2.4 team has produced a more complete set of executable constraints for valid MOF 2.4 metamodels which should be incorporated.
In section 9.1 the description of the exceptions refer to element instead of object as the parameter. And the whole section needs clarification of null e.g. does C.isInstance(null) = true for any class or datatype?
In 13.6, elementsOfType has a parameter includeSubtypes, but linksOfType does not. There is no reason for this disparity Associations can be generalized.
Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1
There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15
Revise the conventions used in the MOF specification document to avoid unnecessary duplication of descriptions for inherited operations. in particular, the add/addAll/remove operations in 10.7 ReflectiveSequence are unnecessary duplicate descriptions of the add/addAll/remove operations inherited from 10.6 ReflectiveCollection
Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties, i.e., set, ordered set, bag and sequence
In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF 2.4 seems to be silent on the semantics of association generalization. According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: Each instance of the specific classifier is also an indirect instance of the general classifier. However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics. Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply. But there is a problem. Lets look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval. That gives anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug. In summary, the CMOF API that allows links to be explicitly manipulated and navigated should be defined so that a link of a sub-association is also a link of its super-associations.
In MOF 2.4, section 3, Normative References, there is a single paragraph which is repeated. Both paragraphs refer to the UML Superstructure 2.4, but they refer to it with different document numbers the first is 2010-08-02 and the second is 2010-11-14. The second would be correct for 2.4, although needs to be revised again for 2.4.1.
The page of the MOF 2.4 spec headed Part III The MOF Model has the meaningless word Gagagaga at the end of it.
In MOF 2.4, Reflection::Element merges UML::Element. Then it is stated that Reflection::Element is an implicit superclass of all metaclasses defined using MOF. Hence UML::Element is a subclass of Reflection::Element which merges UML::Element. Reflection::Element has all of the properties of UML::Element (e.g. ownedComment) and so UML::Element may not validly have these properties. The solution is for MOF not to merge any part of UML, because there is no need to do so. MOF should simply refer to UML for its definitions.
Per UML2.4.1, a In 12.4, constraint [8] currently reads: An EMOF metamodel is restricted to use the following concrete metaclasses from UMLs Kernel: Class Comment DataType Enumeration EnumerationLiteral Generalization InstanceValue LiteralBoolean LiteralInteger LiteralNull LiteralReal LiteralString LiteralUnlimitedNatural Operation Package Parameter PrimitiveType Property The list includes InstanceValue but incorrectly omits InstanceSpecification. InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification; see UML2.4.1, 7.3.23: instance: InstanceSpecification [1] The instance that is the specified value. Since the list includes Class and a Class can have Property features, an InstanceSpecification that is the value of an InstanceValue in EMOF may have to specify values for the instantiated Class' Property features. Therefore, the list should also include UML2.4.1's Slot as well. The list should be corrected as follows: Class Comment DataType Enumeration EnumerationLiteral Generalization InstanceSpecification InstanceValue LiteralBoolean LiteralInteger LiteralNull LiteralReal LiteralString LiteralUnlimitedNatural Operation Package Parameter PrimitiveType Property In 14.4, constraint [10] currently reads: A CMOF metamodel is restricted to use the following concrete metaclasses from UMLs Kernel: Association Class Comment Constraint DataType ElementImport Enumeration EnumerationLiteral Generalization InstanceValue LiteralBoolean LiteralInteger LiteralNull LiteralReal LiteralString LiteralUnlimitedNatural OpaqueExpression Operation Package PackageImport PackageMerge Parameter PrimitiveType Property The list includes InstanceValue but incorrectly omits InstanceSpecification. InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification; see UML2.4.1, 7.3.23: instance: InstanceSpecification [1] The instance that is the specified value. Since the list includes Class and DataType, both of which can have Property features, an InstanceSpecification that is the value of an InstanceValue in CMOF may have to specify values for the instantiated Class' or DataType's Property features. Therefore, the list should also include UML2.4.1's Slot as well. The list should be corrected as follows: Association Class Comment Constraint DataType ElementImport Enumeration EnumerationLiteral Generalization InstanceSpecification InstanceValue LiteralBoolean LiteralInteger LiteralNull LiteralReal LiteralString LiteralUnlimitedNatural OpaqueExpression Operation Package PackageImport PackageMerge Parameter PrimitiveType Property Slot