Home » Modeling » OCL » UML constraints context(UML constraints context)
|UML constraints context [message #1761414]
||Wed, 10 May 2017 17:30
| Jeremie Tatibouet
Registered: April 2014
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:
- constrainedElement: the ordered set of elements referenced by this constraint.
- specification: a condition that must be true when evaluated.
- 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 always evaluates on the specified context.
For instance, in the above figure, 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.
- Contextual classifier: defines the namespace in which the expression is evaluated.
- 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 is 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.
- Does self must be resolved (as indicated in OCL specification) based on the constrained element?
- 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?
|Re: UML constraints context [message #1761422 is a reply to message #1761414]
||Wed, 10 May 2017 21:50
| Ed Willink
Registered: July 2009
Very short answer: What you ask is not defined by the UML or OCL specifications.
There was a long discussion in http://issues.omg.org/browse/UMLR-707
Rather than just regurgitate my ingrained/prejuduced point of view I reread Clause 12 of the OCL specification. My full review notes are attached. To keep this email more manageable I will try to consider only relevant issues.
OCL 2.0 was forked off from UML 1.5 seemingly by agreement between the U2P and 2U submissions who contributed to the 03-01-07 draft. (03-01-08 was the 3rd 2U submission.) At that point U2P and 2U were competing and so the 03-01-07 joint work references UML 1.5 with many TBDs for alignment with the future UML 2.0. The winning UML 2 submission did not conttribute to any progress and so the 03-01-07 draft sat on the shelf until it was approved as 06-05-01 with minimal changes; mostly just deletion of the really hard TBDs. This faciltated QVT, but it is a mystery how the AB ever approved an OCL 2.0 specifiication so full of TBDs. Subsequent OCL revisions have addressed some simple issues. Major challenges of UML alignment and mechanics require considerable work, much of which has been prototyped by Eclipse OCL.
UML 2.0 is a bit vague/confusing in regard to the Constraint class that I regard as a dustbin for under-designed concepts. Ed S is doing his best to address the vagueness/confusion from a UML perspective but with inadequate understanding of the OCL perspective/mess.
OCL 2.x UML alignment is a disgrace. Any OCL implementor must adjust the UML 1.5 terminology for use with UML 2.x.
There are (at last) two significant differences between UML 2.0 and UML 1.5 in regards to Constraints.
a) The keyword-stereotypes such as <<invariant>> used by the OCL specification have been removed forcing an OCL redesign.
b) The Constraint::context property has been added.
UML 2.5 7.6.3 "In addition, the context of the Constraint may be used as the Namespace for interpreting names used in the specification
(for example, in OCL "self" is used to refer to the context element)."
Obvious conclusion. Great. UML 2.x has improved to provide support for Complete OCL's "context" keyword / contextual classifier. Clearly the OCL context in a UML 2.x world should be based on Constraint::context rather than the mish-mash of inconsistent suggestions in the UML 1.5-based OCL 2.x text.
The real killer for an OCL toolsmith is at the end of OCL 2.4 12.12
Note - The rules for the synthesized and inherited attributes associated with the grammar all depend upon the UML 2.0
metamodel. They cannot be written until this metamodel has been stabilized. Therefore only the grammar rules are given.
The synthesized attributes would tell us precisely how the OCL CS is mapped to the UML AS. Since it remains to be written, the answer to
"I would like to clarify the definition of what is the context of an OCL constraint when used with UML."
is that it has not yet been unspecified. Each toolsmith uses their best endeavours to make sense of the vague UML specification and undesigned OCL specification.
For Eclipse OCL the self context is determined by the (nearest) classifier on the containment hierarchy of the Constraint. Typically Constraint::context, but perhaps Constraint::bodyContext.class or ...
Once I have fully modelled Eclipse-ism free models I anticipate that these will form the baasic of a largely autogenerated submission for a next OCL.
I'm mystified by the idea that Constraints should be moved to a distinct package. It seems to combine the worst of ergonomics and architecture.
Ergonomically specifying many text-based concepts in a graphical tool is really painful. Who writes expressions in a graphical language? Who really defines all their function signatures in UML? Defining hundreds of OCL constrints in UML graphics is clearly mad. So UML 1.x developed the Complete OCL textual language allowing all constraints to be defined in a purely text fashion. The syntax is poor but useable. UML 1.x already developed the solution why not use it. Eclipse OCL provides an Xtext-based editor for Complete OCL documents. Papyrus users can possibly use it as is, but no doubt some UI rough edges can be resolved.
I don't see that a Constraints package actually solves any problems. You still have to struggle with poor graphical ergonomics for text-based concepts. The same thing could be achieved by a normal Class Diagram that just focussed on defining constraints - diagrams are views. Anything more and you open up the challenge of open classes that OCL supports in principle, but without adequate specifcation detail. If you want open classes, use OCL or extend UML to support what OCL also needs.
Of course a Constraints package requires a new interpretation of Constraint::context/constrainedElement and so requires new tools. In the OMG world anything that is not supported by (the increasingly vintage) IBM RSA is not acceptable, so a new form of Constraints package may be challenging.
If UML really wants to have orphaned constraints, I suggest that as a minimum UML introduces a new "contextElements" property to the Constraint dustbin that enumerates each element that may take the 'self' role for the Constraint. Better still introduce derived Constraint classes for each different semantics. If "contextElements" is empty, it defaults to the nearest ancestral Classifier. http://issues.omg.org/browse/UMLR-92 for UML 2.6 introduces a monstrous fudge whereby the first/all "constrainedElements" that conform to Classifier may be treated as "contextElements", but this would be a semantic breakage even if it happened to avoid a change to the dustbin's metamodel. Much better to introduce a clearly defined "contextElements" so that "constrainedElements" can remain constraint-type-specific. The new UML 2.6 wording is a "may" so it just serves to loosen current practice to encompass divergent solutions, it does not require any tool to change to support any other tool's interpretation.
|Re: UML constraints context [message #1761914 is a reply to message #1761422]
||Thu, 11 May 2017 19:12
| Ed Seidewitz
Registered: July 2011
First, it needs to be noted that the resolution to issue UMLR-92 was adopted as part of a package of three urgent issues, leading to an update of the UML standard to version 2.5.1. While, unfortunately, the formal specification for UML 2.5.1 has not yet been published, version 2.5.1 is technically now the current one, not 2.5.|
The resolution to UMLR-92 makes the following changes to subclause 7.6.3 of the UML 2.5 spec (which addresses Constraint semantics):
"In subclause 7.6.3, in the first paragraph, delete the last sentence. In the second paragraph, in the first sentence, replace 'owners' with 'context' and, in the third sentence, replace 'owner' with 'context'. Delete the second sentence."
Applying these changes, the first two paragraphs of 7.6.3 for UML 2.5.1 are:
"The specification of a Constraint is given by a ValueSpecification (see Clause 8) of type Boolean. The computation of the specification may reference the constrainedElements of the Constraint and also the context of the Constraint.
In general there are many possible kinds of context for a Constraint. The context of the Constraint determines when the Constraint specification is evaluated. For example, a Constraint that is a precondition of an Operation is evaluated at the start of the invocation of the Operation, while a Constraint that is a postcondition is evaluated at the conclusion of the invocation (see sub clause 9.6 on Operations)."
Note, in particular, that the reference to OCL "self" is now gone. It is clear in UML 2.5.1 that a Constraint specification can reference all constrainedElements as well as the context, and the only special function of the Constraint context is that it determines "when the Constraint specification is evaluated."
Second, the need to be able to have UML Constraints constrain elements other than their owners is very important, and the UML metamodel is specifically set up to allow this.
For example, it is common in the business rules community to define an entity model, and then to add business rules to that model. However, you don't want these business rules to be "owned" by the entities in the entity model, because different sets of rules may apply in different situations, and you often want to change the rules independently of the entity model. Now, Complete OCL allows you to essentially "open up" classifiers and add constraints to them, but this capability has not been integrated with UML, in which adding owned members is considered a "modification" of the namespace to which the member is being added. The way you do it in UML is to have Constraints owned by a Package of rules, with the Constraints pointing to the elements they constrain as constrainedElements (hence the name "constrainedElements").
Standards-wise, the problem with the "context as self" interpretation really came to a head with the difficulties in defining the expanding subsets of UML used in successive executable UML specifications. In fUML and the Precise Semantics of Composite Structure (PSCS), the applicable UML subsets were defined by essentially copying a subset of the UML metamodel, but declaring that interchange was to use the original metamodel, not the copy. This was already unwieldy with PSCS, and it became clearly unworkable for the Precise Semantics of State Machines (PSSM), which is also based on fUML, but has conformance points both with and without PSCS.
For PSSM, we adopted a new approach (which we plan to also use in fUML and PSCS when these are moved to UML 2.5.1), in which we simply identify those metaclasses in the UML metamodel that are in the PSSM subset and require PSSM models to only be constructed from that subset. However, we also need to add further Constraints to the metaclasses in that subset. But, since we are simply importing the UML metaclasses, we can't change then to add "owned" Constraints to them. Instead, we place the PSSM Constraints all in their own Package and have each one point to the metaclass to which it applies as a constrainedElement.
What we would like now is for tools to allow such Constraints to be specified using OCL and to have "self" within the Constraint be the constrainedElement (valid as their is a single constrainedElement that is a Classifier). This is consistent with UML 2.5.1 and, seemingly, consistent with the original intent of the use of OCL for UML invariants (despite the fact that the wording in the OCL spec was never updated for the adopted UML 2.0). Indeed, the whole reason that UMLR-92 was resolved as an urgent issue was to remove the ambiguity about this in UML, so that we could get the new interpretation supported for PSSM (and going forward).
[Updated on: Thu, 11 May 2017 19:14]
Report message to a moderator
|Re: UML constraints context [message #1763339 is a reply to message #1763306]
||Fri, 12 May 2017 20:39
| Ed Seidewitz
Registered: July 2011
Look, I think we can boil things down more simply.
1. From a UML perspective, I don't understand why it is necessary that "constraint names are distinguishable in the contextualClassifier Namespace rather than the context Namespace". If a Constraint is owned by a Package, then I would expect its name to be distinguishable within, and qualified by, the namespace of the Package. The context Classifier namespace has nothing to do with it.
2. For interpreting OCL inv/pre/post/body/der, I think the conditions you identified have that covered.
3. For other cases, the OCL expression that is the UML Constraint specification is simply a Boolean expression with no OCL context clause. The only issue is how to interpret "self". The simplest backward compatible rule is: If a Constraint has no constrainedElements and its context is a Classifier, then the context Classifier is the type of "self". If the Constraint has a single constrainedElement which is a Classifier, then that constrainedElement Classifier is the type of "self". Otherwise the Constraint is semantically invalid. (I suppose one could allow multiple constrainedElements in which the first one is a Classifier, but I don't see how this would be useful in practice, since I don't think there is any way to access the other constrainedElements from the OCL expression.)
For PSSM, we simply would like, e.g., Papyrus, to be able to handle case 3 above for Constraints owned by a Package with a constrainedElement that is a Classifier.
|Re: UML constraints context [message #1763354 is a reply to message #1763339]
||Sat, 13 May 2017 08:51
| Ed Willink
Registered: July 2009
1) Distinguishability of constraint names is largely an ergonomic courtesy rather than a semantic necessity. There are two cases to consider:
a) False positives
It is common practice to re-use a constraint name when the same constraining principle applies to many members of a class family. For Classified Constraints - no problem. For Unclassified Constraints, oops must either adjust the WFR or user must choose different names.
b) False negatives
Currently only one (local or inherited) constraint of each name is permitted per class. What happens if an Unclassified Constraint name clashes with a Classified Constraint name. I expect a WFR violation, but other design options are that both constraints apply, or one of the Constraints dominates.
2) I identified five options for Unclassified Operation Constraints; none good. I reluctantly advocated a name hack. After thinking about it, this as a minimum requires clear specification of where tools should perform hacking/unhacking. Not happy. I now prefer that when necessary, a first constrainedElement may be a disambiguating composite Property of the second constrainedElement which is the unclassified contextualClassifier. (The StringLiteral option was particularly bad since the StringLiteral would have to be composed somewhere else in order to be referenced as a constrainedElement.) Which option(s) are you in favour of?
3) What you write informally is similar to what I wrote more formally using OCL. But you do not seem to understand what the OCL specification calls a Derived Value Expression and I prefer to call a Property Invariant.
derive IsLowerCase: name.toLowercase() = name -- allowing IsLowerCase is an Eclipse OCL extension
This is semantically identical to the Class Invariant
inv LowerCaseName: name.toLowercase() = name
but gives better UI ergonomics since the reference to the Property as the first constrainedElement enables tools such as Papyrus to report violations with a marker on the Property rather than leaving users with a sometimes confusing Classifier marker. Users like them.
In order to make further progress, I think we need to agree on what we are actually trying to achieve since I see an intuitive hack that makes the Constraint specification vaguer. There are many corner cases where our intuitions may differ.
Assume. Add support for Unclassified Class Invariants.
Do you want support for Unclassified Property Invariants?
Do you want support for Unclassified Operation Bodyconditions?
Do you want support for Unclassified Operation Preconditions? -- for many tools this support will be compile-time only - no synthesized run-time code
Do you want support for Unclassified Operation Postconditions? -- for many tools this support will be compile-time only - no synthesized run-time code
... every other kind of Statemachine / Activity / ... Constraint
Do you want support for arbitrary user-defined Unclassified Constraints? supported by UML 1.x, not supported by OCL 2.x, partially supported by UML 2.x
Do you want support for Unclassified helper Properties? e.g. Property Definitions in Complete OCL.
Do you want support for Unclassified helper Operations? e.g. Operation Definitions in Complete OCL.
How are conflicts between Classified and Unclassified Constraints handled? WFR violation, both apply, Classified dominates, Unclassified dominates
Are you happy to make the UML spec vaguer so that each tool may come up with its own solution or do you want the XMI-level solution to be unambiguous and amenable to MIWG testing?
Are you happy to leave the prevailing Constraint vagueness, or do you want to take the opportunity of defining Unclassified Constraints accurately to also define Classified Constraints? - it's probably rather hard to make Unclassified Constraints precise while Classified Constraints remain vague.
Current Time: Fri Feb 21 22:44:21 GMT 2020
Powered by FUDForum
. Page generated in 0.02287 seconds