Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » UML constraints context(UML constraints context)
UML constraints context [message #1761414] Wed, 10 May 2017 17:30 Go to next message
Jeremie Tatibouet is currently offline Jeremie TatibouetFriend
Messages: 6
Registered: April 2014
Junior Member
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:

index.php/fa/29302/0/

  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 always evaluates on the specified context.

index.php/fa/29303/0/

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.

  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 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.

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?

Regards

Jérémie
Re: UML constraints context [message #1761422 is a reply to message #1761414] Wed, 10 May 2017 21:50 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

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.

Past

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.

Present

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.

Future

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.

Regards

Ed Willink








Re: UML constraints context [message #1761914 is a reply to message #1761422] Thu, 11 May 2017 19:12 Go to previous messageGo to next message
Ed Seidewitz is currently offline Ed SeidewitzFriend
Messages: 9
Registered: July 2011
Junior Member
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 #1762878 is a reply to message #1761914] Fri, 12 May 2017 05:56 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi Ed

Thanks. While a Constraints package may seem mad at the UI level, it clearly makes a lot of sense at the model/XMI level.

I see a ?99.99% compatible solution.

The 'old' way. Constraint placed 'below' its context => OCL context comes from the nearest ancestral classifier. constrainedElements provide additional constraint-role-specific 'arguments'. i.e. the containment hierarchy involves a Classifier.

The 'new' way. Constraint placed arbitrarily. context comes from the first constrainedElement. other constrainedElements provide additional constraint-role-specific 'arguments'.

If the 'new' way is limited to placement within a package hierarchy, We can use a "there is/isn't a Classifier in the containment hierarchy" test to distinguish the two cases.

Since the 'new' way prohibits 'old' way Constraints on Packages, perhaps the 'new' way defines a new Unclassified Constraint semantic contrasted with the 'old' way definition of a Classified Constraint.

The 'new' way therefore elaborates some missing helpers as follows (not yet tool checked)

context Constraint

def: isUnclassifiedConstraint : Boolean =
self->closure(oclContainer())->selectByKind(Classifier)->isEmpty()

def: contextualClassifier : Classifier =
if isUnclassifiedConstraint
then constrainedElements->at(1).oclAsType(Classifier)
else self->closure(oclContainer())->selectByKind(Classifier)->at(1)
endif

def: contextualConstrainedElements : Sequence(Element) =
if isUnclassifiedConstraint
then constrainedElements->subSequence(2, constrainedElements->size())
else constrainedElements
endif

This has two tolerable limitations.
- the 'old' way cannot be extended to Constraints on Packages. If Constraints on Packages are introduced they will have to use the 'new' way. Or perhaps be static Constraints on Classifiers.
- the 'new' way is limited to 'arbitrary' placement of Constraints in the Package hierarchy.

?0.01% incompatibility. It is just conceivable that there are models in which Packages do already have Constraints. These are presumably using a non-standard semantics that can remain non-standard or be revised to accommodate the additional semantic in the standard.

Regards

Ed Willink

Re: UML constraints context [message #1763215 is a reply to message #1762878] Fri, 12 May 2017 08:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

An Unclassifued Constraint introduces two problems with distinguishability.

a) straightforward

The isDistiguishable logic for a Package/Constraint must ensure that constraint names are distinguishable in the contextualClassifier Namespace rather than the context Namespace.

b) troublesome

In UML 1.5 the keyword-stereotype (inv/pre/post/...) allowed for an arbitrary number of contextualRoles some of which were enumerated in OCL/UML specifications.

UML 2.0 eliminated the keyword-stereotype and so also eliminated arbitrary contextualRoles. I'm not aware of anyone objecting. This was ok since the contextualRole can be deduced for Classified Constraints:

context Constraint

def: is_inv : Boolean context.oclIsKindOf(Classifier) and constrainedElements->isEmpty()

def: is_der: Boolean context.oclIsKindOf(Classifier) and constrainedElements->size()=1 and constrainedElements->at(1)->oclIsKindOf(Property)

def: is_pre: Boolean preContext <> null
def: is_body: Boolean bodyContext <> null
def: is_post: Boolean postContext <> null

is_inv and is_der migrate to Unclassified Constraints by replacing "context"/"constrainedElements" by the "contextualClassifier"/contextualConstrainedElements" helpers.

However is/pre/is/body/is_post do not. There is no keyword-stereotype or containment path that distinguishes the three Unclassified Operation Constraint roles.

Options

- (Re)introduce a keyword-stereotype/contextualRole Property. Clearly unacceptable for UML 2.5.2. Not very nice for UML 2.6.

- Introduce a contextualRole StringLiteral as a further constrainedElement. The StringLiteral is inv/der/pre/post/body/... Irregular, or a tedious imposition on all Unclassified Constraints just to fix Unclassified Operation Constraints.

- Introduce a contextualRole Property as a further constrainedElement. The second constrainedElement is the context/preContext/postContext/bodyContext containing Property (or its opposite since it not necessarily navigable). A tedious imposition on all Unclassified Constraints just to fix Unclassified Operation Constraints. A slightly surprising use of UML elements in the user model.

- Introduce a naming hack. The UML/OCL bodyCondition/bodyExpression incompatibility is already hacked by a mandatory "result =" in the XMI. A naming idiom such as a ":pre:"/":post:"/... prefix could be imposed on Unclassified Constraints that need to identify their role. ":xxx:" is ok in XMI and very unlikely to clash with user names, so that a ":xxx:" could apply regularly to all Constraint names; it may be omitted for the single alternative defined by the UML specification. UML UI tools should split the hacked name to show two distinct concepts, i.e. two form entries, and e.g. <<post>> name in the diagram.

- Inference. The OCL expression can be analyzed and precondition distinguished. However bodyconditions and postconditions cannot always be distinguished. Not applicable to constraints in arbitrary languages.

I'm not a fan of name hacks, but without a UML metamodel addition, I see little realistic alternative. It has the advantage of zero change for anyone already using Unclassified Constraints for Class Invariants or Derived Properties.

Revised WFRs will of course need helpers to extract contextualName and contextualRole from the hacked name.

Regards

Ed Willink
Re: UML constraints context [message #1763306 is a reply to message #1763215] Fri, 12 May 2017 13:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi Ed

Just checked Eclipse UML2. Multiple same-named differently constrainedElement Constraints in a Package give not-distinguishable WFR failures.

The Unclassified Constraint is really just a very limited (i.e half-baked) form of Open Classes. Open only to arbitrarily placed Constraints. So of course it is not open to helper Operations or helper derived Properties, unless a new random placement capability is provided for Operations and Properties too, by which time you really do have open classes. It seems to me that the lessons to be learned from recent UML-based specification is that open classes are required. Arguably package merge of the pre UML 2.5 packages provided open classes. It seems that the more disciplined URI/name hierarchy collision overlay for OCL open classes is needed by UML. As noted earlier, the UI ergonomics of editing a Constraints package seems to be quite unreasonable for text-only information content.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=516562 identifies that Unclassified Constraints are easily handled as just another weirdness to be accommodated by the transformation from UML to the normalized OCL Pivot model. Nothing in the Pivot OCL core functionality needs to change.

Regards

Ed Willink
Re: UML constraints context [message #1763339 is a reply to message #1763306] Fri, 12 May 2017 20:39 Go to previous messageGo to next message
Ed Seidewitz is currently offline Ed SeidewitzFriend
Messages: 9
Registered: July 2011
Junior Member
Ed,

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.

Ed
Re: UML constraints context [message #1763354 is a reply to message #1763339] Sat, 13 May 2017 08:51 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi Ed

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.

context NamedElement::name
derive IsLowerCase: name.toLowercase() = name -- allowing IsLowerCase is an Eclipse OCL extension

This is semantically identical to the Class Invariant

context NamedElement
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.

Regards

Ed Willink



Previous Topic:Evaluation of transformations with OCL
Next Topic:IllegalStateException on plain vanilla install of OCL
Goto Forum:
  


Current Time: Sat Dec 16 13:16:47 GMT 2017

Powered by FUDForum. Page generated in 0.01985 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software