SMOF_ — SMOF Issue: Compatibility and Incompatibility constraint semantics

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.

This issue is resolved by the resolution to issue 17163.
Revised Text:
None.
Disposition: Closed – Duplicate / Merged – see issue 17163