UML25 — Operation::isConsistentWith()

I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

The current definition is this:

isConsistentWith(redefinee : RedefinableElement) : Boolean

A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

let op : Operation = redefinee.oclAsType(Operation) in

self.ownedParameter->size() = op.ownedParameter->size() and

Sequence

->

forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

There seem to me to be three approaches here.

1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

Any comments?

issue withdrawn