eclipse-ocl-bot
commented
1 month ago By Ed Willink on Oct 31, 2009 04:19
This is rubbish.
Operation constraints have a pre/post/body stereotype that indicatesa the nature of the constrainedElement.
MDT/OCL correctly assigns the element accordingly.
| --- | --- | | Bugzilla Link | 257746 | | Status | CLOSED INVALID | | Importance | P3 normal | | Reported | Dec 05, 2008 12:35 EDT | | Modified | May 27, 2011 02:46 EDT | | Reporter | Ed Willink |
Description
I've just fallen over the same problem that you encountered when introducing\ ParsingOptions.DEFINITION_CONSTRAINS_FEATURE:
Paraphrasing: "A definition Constraint must constrain exactly one Classifier". This is very unfortunate because it means that the resulting AST has no association between the constraint and the actual constrained element. The constrained element can only sometimes be located by searching for a matching type signature.
This is so obviously an OCL howler that it seems worth fixing.
I would advocate that out-of-the-box MDT-OCL should exhibit as sensible a behaviour as possible, with only essential deviations from the standard that are justified by a submitted OMG issue that has a reasonable prospect of adoption.
Optional ParsingOptions.STRICT = "1.1" or "2.0" should amend behaviour to the exact letter of a specific specification.
For long term compatibility, perhaps
Optional ParsingOptions.LAX = "1.1" or "2.0" should amend behaviour to the spirit of a specific specification.
Since there is no OMG issue, should I raise one?
I feel that the option-driven introduction of a second constrainedElement is the wrong solution. For a STRICT realisation, the missing information should be conveyed by an EAnnotation/Comment. For a LAX realisation the constrainedElement should be the feature rather than the Classifier.