[news.eclipse.modeling.mdt.uml2.ocl] Re: OCL Debugging ?

["Christian W. Damus" <cdamus@xxxxxxxxxx>]

Hi, Andy,

Find some comments, in-line.

Cheers,

Christian


Andreas Maier wrote:

> Christian,
> thanks for the answers. I meant "debugging" at the level of evaluating
> the expressions. In the mean time I got used to validate smaller
> portions of a complex OCL statement if it does not work immediately.

Yes, there should definitely be more "tracing" style code in the evaluation,
as there is in the parsing.  Also, there is no public API for turning on
the tracing currently available in the parser.  Would you mind raising bugs
for these items?


> Contributing a debugger: I'm afraid that would be far more than I can
> do, both time-wise and also programming-wise. But I'd be definitely
> interested to test it out if someone wants to engage in that endeavor :-)

And more than I handle, too, though I would sure be eager to use it!


> Another area that I think could benefit is the area of writing test
> cases against OCL statements. I tend to have only a small number of test
> models which I modify to only once or so cause my (profile based) OCL
> statements to fire, and once that is validated, I leave the models in a
> state where the OCL statements do not fire, because otherwise there are
> too many problem messages around. That approach obviously does not allow
> for regression testing.

Sorry, I'm not sure that I followed this.  Do you mean, that it is difficult
to perform regular regression testing of the constraints that you have
formulated in your UML profile?  You would need to develop a framework
(using JUnit) that lets you easily generate the minimal model required to
violate and pass each constraint individually ... I don't think that this
would be in the scope of the OCL project, or even EMFT Validation.


> Also, in case someone feels inclined to start an "OCL documentation
> project", I'd be willing to spend time and contribute.

Great!  Whatever you can contribute, I would be more than happy to review. 
Do you mean to contribute a bare-bones OCL language guide, or something
else?  There is already
https://bugs.eclipse.org/bugs/show_bug.cgi?id=156360 which addresses the
developer's guide from an API perspective.


> 
> Andy
> 
> Christian W. Damus wrote:
>> Hi, Andy,
>> 
>> That depends on what you mean by debugging.  :-)
>> 
>> If the error messages provided by the parser aren't sufficiently clear to
>> indicate what the cause of a parsing problem is, then please raise bugs.
>> 
>> If you have complex OCL expressions that parse but compute the wrong
>> results, and you need to find out why, then I'm afraid that there isn't
>> any
>> debug support at the OCL level of abstraction.  You will have to debug
>> the Java code evaluating your expression (the evaluation visitor) to see:
>> 
>>   - what the AST looks like; this often can indicate what the problem is
>>     by seeing how the results of sub-expressions are incorporated into
>>     the larger expressions
>> 
>>   - what values are actually computed for each sub-expression
>> 
>> One tip that may help is to visualize your OCL expression in the
>> tree-based
>> editor.  Generate an OCL editor from the OCL.ecore model, save your
>> parsed
>> OCLExpression in an XMI document, then load it up in the editor.  You can
>> then browse the AST to see exactly what the parser thinks your expression
>> meant.
>> 
>> An OCL debug UI would, of course, be very cool.  Would you be interested
>> in contributing one?
>> 
>> HTH,
>> 
>> Christian
>> 
>> 
>> Andreas Maier wrote:
>> 
>>> Is there some way to debug OCL ?
>>>
>>> Andy
>>