Issues for Mailing list of the MOF Support for Semantic Structures Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 15975: UML Profile XMI does not load, and it has MagicDraw specifics
Issue 16107: SMOF should be updated to 2.4 before finalization to be consistent with UML, MOF and XMI.
Issue 16395: SMOF issue: incorrect namespaces in XMI examples
Issue 17034: What is the definition of "fundamental type"?
Issue 17035: Two spelling mistakes
Issue 17036: CompatibleWith/IncompatibleWith and the Law of the Excluded Middle
Issue 17132: Issue with SMOF semantics
Issue 17148: Property visibility in profile
Issue 17149: AspectOf encourages misuse in common use case
Issue 17150: Extended element semantics complicates common use case
Issue 17151: Compatibility semantics clarification for generalization
Issue 17152: Default compatibility for generalization
Issue 17153: Required semantics when source instances unclassified
Issue 17154: Compatiblity constraints and instances
Issue 17155: When compatibility is the same as generalization
Issue 17156: Profile using Constraint, why not?
Issue 17157: Subject classifier
Issue 17158: Profile compatibility semantics different from metamodel extension
Issue 17159: Profile and metamodel extension text alignment
Issue 17162: Incompatibility::constrainedType does not need to be ordered
Issue 17163: SMOF not a subset of UML
Issue 17164: Compatiblity::isRequired = true redundant with Generalization
Issue 17165: Compatibility complicates common programming use case
Issue 17166: SMOF cumbersome for semantic applications
Issue 17167: EquivalentClass and IncompatibleWith stereotypes redundant with ODM
Issue 17170: oclIsKindOf / ocIsTypeOf
Issue 17171: AspectOf equivalence
Issue 17279: AspectOf extending Generalization with Constraint unclear
Issue 17280: Metamodel Effect subsections should use instances
Issue 17281: SMOF Issue: Compatibility and Incompatibility constraint semantics
Issue 17505: Clause 8 should alter MOF’s containment constraints
Issue 17506: reclassify should check its arguments

Issue 15975: UML Profile XMI does not load, and it has MagicDraw specifics (smof-ftf)

I could not get the UML Profile XMI to load, and it has MagicDraw specifics.

The profile XMI also has a stereotype called Constraint which had no base class and was not in the spec – so it should be deleted.

 

SMOF should be updated to 2.4 before finalization to be consistent with UML, MOF and XMI.

In clause 12 of SMOF, the namespaces (such as xmlns:xmi=http://www.omg.org/spec/XMI/20100101) do not refer to any actual published specification. Furthermore, the xmlns:uml namespace inconsistently refers to the XMI spec.

Section 7.1 includes this sentence:


"In reality, objects are subject to constant variations without changing their identity or their fundamental type, they undergo changes in classifications and assumed roles."

The term "fundamental type" doesn't seem to have a formal definition in either MOF or SMOF, so it's not clear what the term means in this context. Please further clarify the implicit distinction being made here between "type" and "fundamental type" (or remove the term).

Some spelling mistakes in the beta specification:


"clientt" (p 32, section 11.2.2, "Where CompatibleWith exists between two classes it is then permissible to add or remove the clientt ... ")

"sever" (p 9, section 7.4, "Note that there are sever subclasses of ...")

It is unclear what what relationship to deduce between a pair classifiers where neither  "CompatibleWith" nor "IncompatibleWith" has been asserted between them. Is the default assumption that they are compatible, not compatible, or that there is no information?


The description of "CompatibleWith" (11.2.2) says:


" ... if AspectOf or CompatibleWith does not exist between two classes (or their supertypes) an instance may not be explicitly classified by both classes ..."


What is the meaning of "may" in that sentence? If the intended meaning is "shall", then it's clear that in the absence of CompatibleWith between two classes, those two classes are not compatible. However, if the intended meaning is indeed "may/might", then the the sentence does nothing to remove the ambiguity.

It is also unclear what behaviour is intended if both CompatibleWith and IncompatibleWith exist between the same pair of classifiers. Presumably this is an error, but how exactly shall a compliant implementation behave under these circumstances?

SMOF needs to clarify the algebraic properties of Compatibility and Incompatibility, as follows:

 

1.       Is Compatibility transitive?  I.e. if X C Y and Y C Z, is it valid to multiply classify an object by X and Z without Y being present?

2.       How does Compatibility interact with subtyping?  If X C Y, does that mean that subtypes of X are also compatible with Y? How about X being compatible with subtypes of Y?

3.       How does Incompatibility interact with subtyping?  Same questions as (2).

Figure 6 (SMOF Profile) has private visibility on the properties.  Is that intended?

Section (11.2.1) AspectOf, Description, is too strong an interpretation of reclassification to subtypes, and encourages modelers to use aspects when that is not what they mean.  For example, if Mammal generalizes Dog, some instances of Mammal might be dogs, but the modeler doesn't know it yet.  When it becomes known that a particular instance of Mammal is a dog, it can be reclassified under Dog.  This doesn't make Dog an aspect of Mammals.  To support this example, modelers would likely think they need to apply the AspectOf stereotype to the generalization between Mammal and Dog, which won't make sense.  This construct needs to be rethought in context of other use cases and perhaps additional stereotypes for more cases.

Section 9.1.2.3 (Element, as extended), Semantics, first sentence, says reclassification is constrained by Compatibility elements, but this would mean an instances of a type cannot be reclassified as one of its subtypes without using compatibility, see AspectOf example in the previous issue.  This is such a typical use case that it would be significant burden to require modelers to explicitly define compatibility for it. 

Section 9.1.2.2 (Compatibility), Semantics, first paragraph, last sentence, should clarify that disallowing multiple classification does not prevent multiple classification due to generalization.  Otherwise instances can't be created for types that have generalizations

The last three issues indicate modelers shouldn't be forced to define compatibility for types related by generalization.  Such reclassifications are so common as knowledge about instances changes that the modeler would need to apply compatibility to all generalizations in their models.  Perhaps this could be addressed by assuming unrequired compatibility between types and their generalizations.  Another option might be to batch declare compatibility for generalization at the level of packages.

Section 9.1.2.2 (Compatibility), Attributes, says if isRequired=true, and the constraint spec evaluated to true, instances of the source will be classified as instances of the target.  Will the instances be unclassified from the target when they are unclassified from the source? If not, this construct won't emulate generalization, and can't capture type equivalance (see last sentence of Semantics), wasn't that the intention?

Section 9.1.2.2 (Compatibility), Semantics, should clarify whether
instances can be taken into account when evaluating the constraint
specification (compare to the AspectOf, Attributes, isRequired, next to
last paragraph in the description).  If they can, the last sentence
presumably should replace evaluates to true" with "evaluates to true for
all possible instances of either type".  My understanding is the
Compatible constraint specification must evaluate to true for an
instance to be classified under both types, so if the constraint spec
can account for instances, then all instances (past, present, and
future) of both types must satisfy the constraint spec for the types to
be equivalent.

Section 9.1.2.2 (Compatibility), Semantics, explains how to capture equivalance, and it would be good also to explain that isRequired=true with a constraint spec that always evaluates to true is the same as generalization between the source and the target.

Figure 6 (SMOF Profile) uses Dependency as base, but the metamodel extensions in Chapter 9 use Constraint.  Why not use Constraint in the profile?

Section 11.2.2 (CompatibleWith) Description, third paragraph, first sentence refers to a "subject classifier", what is a subject classifier?

Section 11.2.2 (CompatibleWith) Description, third paragraph, first sentence mentions adding or removing the client classifier, but not the supplier classifier, which isn't the same as Section 9.1.2.2 (Compatibility), Semantics, first, which doesn't distinguish between the constrained types.

The profile uses very different language from the metamodel extensions to describe what presumably is the same semantics.  For example, the semantics of Compatibility constraint specifications is much more spelled out in the metamodel extensions than that the profile, (and also see the previous issue).  It would help prevent misinterpretation and improve consistency if the same text is used in both sections as much as possible.

In Figure 3 (SMOF Classification Constraints), Incompatibility::constrainedType does not need to be ordered, incompatibility is symmetric.

MOF is a subset /constrained version of UML now, as I understand it, but SMOF is not.  MOF subsetting UML had many benefits, why not SMOF?

Compatiblity::isRequired = true is redundant with Generalization (both declare all instances of one type are instances of another), why is isRequired needed?  It would be simpler to enable Generalization to be used without modifying it's end types (Pete claims it doesn't even currently require such modification, even though most implementation modify the specialized type).

The default restriction against reclassification between generalizations (see Section 9.1.2.3, Semantics, first sentence, and the four earlier issues starting with AspectOf) is not aligned with typical OO programming languages, which allow runtime instances to be bound to variables typed by a superclass of the class from which instances are created.  These programming capabilities enable an class instance to be viewed as an instance of one of the superclasses, but this common programming use case requires a special declaration in SMOF.

SMOF says it gives support to "semantic structures", in particular citing "structural rigidity of object-oriented programming systems" (Section 1, 7.1), including "type / classification systems" as a problem area, but in contrast to typical "semantic" languages, SMOF assumes types are disjoint unless otherwise stated (see Section 9.1.2.1, Incompatibility, Semantics, first paragraph, last sentence), and even prevents reclassification between general and special types by default (see use case in four earlier issues starting with AspectOf, and the immediately previous issue).  Typical "semantic" applications will be forced to define compatibility over most types in their models.  Perhaps this burden could be reduced by compatiblity between types as the default, or maybe a batch compatibility declaration at the level of packages.

The EquivalentClass and IncompatibleWith stereotypes are redundant with the EquivalentClass and ComplementOf stereotypes in the UML Profile for OWL, see the Ontology Definition Metamodel.

Section 11.2.1 (AspectOf), Description, third to last paragraph (the one starting "When the subtype/aspect is added"), oclIsKindOf() is always true for the superclass and subclass, should be oclIsTypeOf().

Section 11.2.1 (AspectOf), Description, fourth paragraph (the starting "Applying AspectOf to a Generalization") is "exactly equivalent", but should say "semantically equivalent".  Aspect is not exactly equivalent to the CompatibleWith pattern given, or you could just use the CompatibleWith pattern as stated and it would be understood the same way by the modeler.  Other uses of the same CompatibleWith pattern are not aspects, see Issue 17149 (AspectOf encourages misuse in common use case).

Semantically, AspectOf (Section 11.2.1) corresponds to an SMOF::Compatibility, which is a kind of SMOF::Constraint.  However, the profile also allows using a UML::Constraint to specify the compatibility constraint.  It is unclear whether the intent of the profile is that it's the combination of the AspectOf-stereotyped Generalization + the Constraint applied to that AspectOf-stereotyped Generalization that corresponds to a single SMOF::Constraint

The Metamodel Effect subsections (11.2.1, 11.2.2, 11.2.3, 11.2.4) currently show relevant portions of the SMOF metamodel diagrams. Instead of showing the SMOF metamodel diagrams, these subsections should show the meaning of each SMOF Profile stereotype in terms of the set of corresponding instances of the SMOF Metamodel classes / associations.

SMOF Compatibility and Incompatibility are kinds of Constraint.  As such they must have a specification, which is a kind of ValueSpecification.

 

I believe that Incompatibility leaves no more to be said: two types are Incompatible if they are related by an Incompatibility, regardless of what the specification evaluates to.  So what should the specification be?

 

Compatibility says (9.1.2.2) that two compatible classes may co-exist “as long as the constraint’s specification evaluates to true”.  If the constraint is to be OCL, this implies some binding to define the evaluation context for the constraint.  What, for example, is self bound to?  According to 10.1.9, the constraint is evaluated “in the context of the first constrained element”.    

 

I think this is inconsistent with 9.1.2.2.  This gives a direction to Compatibility: the instance is first classified by the “target class”, and second classified by the “source class”.   9.1.2.2 says the source type is constrainedType->at(1) and the target type is constrainedType->at(2).  Since the compatibility constraint must be evaluated against the instance as classified by the target class, then the type of self must be the target class, which makes 10.1.9 wrong.  Looking at an example: Person is compatible with LicensedDriver if age >= 17.  The instance must first be classified as Person, and secondly by LicensedDriver.  So Person is the target type (according to 9.1.2.2) and LicensedDriver is the source type.  Then the constraint self.age >= 17 will make sense if an appropriate OCL binding is defined (which implies a modification to the OCL spec, which we need anyway).

 

I actually think that the target type ought to be constrainedType->at(1) and the source type constrainedType->at(2), to emphasize that the instance has the target type before the source type.

 

Anyway, the wording of Compatibility semantics should say type, not class.

Clause 8 should alter MOF 2.4.1’s containment constraints that an object may only have one container, so that they do not apply in an SMOF context.  In particular, in MOF 12.5, several constraints under Property::isComposite== true need to be reworded

Reclassify should throw an exception if oldMetaClass contains any metaclass that does not currently directly classify the object.