| [mdt-papyrus.dev] [OCL] - About the context of constraints |
|
Dear Ed – I would like to clarify the definition of what is the context of an OCL constraint when used with UML. Figure 7.6.2 in [UML 2.5] defines the syntactic element Constraint as follows:
1.
constrainedElement: the ordered set of elements referenced by this constraint. 2.
specification: a condition that must be true when evaluated. 3.
context: specifies the namespace that owns the constraint. The association A_ownedRule_context (see section 7.9.22 in [UML 2.5]) ends both subset ends of the association
A_ownedMember_namespace (see section 7.9.19 in [UML 2.5]). The interest of the association A_ownedRule_context seems to enable the designer to explicitly define “the Namespace for interpreting names used in the specification (for example, in OCL self is used to refer
the context element)” – see section 7.6.3 in [UML 2.5]. Based on this, in Papyrus
self seems to always evaluate on the specified context.
For instance, in the figure below, C has
Thread for context (which means that Thread owns the constraint
C) and Thread is referenced in the list of constrained element. In such configuration, the constraint
C specified with OCL evaluates to true. Now if we change the context (e.g., to store our constraints in a
Constraints package) then C is owned by that package while still constraining Thread. At this point the validation of the constraint fails due to the update of the context. While the evaluation of
self to the context (i.e., the Constraints package) conforms to what UML specifies, it does not look to be the correct behavior to the final user since the constrained element did not change. The OCL specification (see section 12.1 in [OCL 2.4]) defines the notion of
contextual classifier and self instance. 1.
Contextual classifier: defines the namespace in which the _expression_ is evaluated. 2.
Self instance: is the reference to the object that evaluates the _expression_. It is always an instance of the contextual classifier. It also provides a clear definition about the way an invariant must be specified for a Classifier (see section 12.6.1 in [OCL 2.4]). The first rule specifies that
“The constraint has the stereotype «invariant» (A) and the constraint is attached to only one model element (B) the constraint is attached to a Classifier (C).
The contextual classifier is the constrained element and the type of the OCL _expression_ must be Boolean
“. Considering these points, it seems clear that the self shall be resolved based on the constrained element. However this somehow contradicts what in in UML specification (see section 7.6.3 in [UML 2.5]). In addition, this
leads to an interrogation: why do we need in UML to define the association A_ownedRule_context (see section 7.9.22 in [UML 2.5])? It looks that only with A_ownedMember_namespace (see section 7.9.19 in [UML 2.5]) we have the capability to provide
a namespace for a Constraint that is basically given by its owning element. Questions are: 1.
Does self must be resolved (as indicated in OCL specification) based on the constrained element? 2.
What is the interest of having the possibility to define a “context” for a constraint? Is the one defined by owning-owner relationship not sufficient? Note: I know you had a discussion on this with Ed Seidewitz. However I am not sure what your conclusions were? Regards Jérémie TATIBOUET (CEA LIST) |
