[news.eclipse.tools.emf] Re: OCL checker for EMF models in transformatio

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

Hi, Damien,

Find some comments in-line below.

HTH,

Christian


Damien Thivolle wrote:

> Ed Merks a Ãcrit :
>> Damien,
>> 
>> Comments below.
>> 
>> Damien Thivolle wrote:

-----8<-----

>>>>> I've been hinted to write a checker in OCL that would just tell me
>>>>> whether a model Ma (conforming to MMa) is included in the subset I'm
>>>>> interested in.
>> There's also an OCL-specific newsgroup... The EMF extended validation
>> framework includes support for writing constraints with OCL
>> (org.eclipse.emf.validation.ocl).

The EMF Validation Framework SDK has an example that might give you a
head-start on what you're looking for.  The "New -> Example..." menu has
an "EMF Validation Framework Examples / OCL" example that installs an
org.eclipse.emf.validation.ocl project in your workspace (note that, in
order to get it working, you need to install all three examples; we have a
bugzilla about that).

Included in this project is an example of how to define a Dynamic Constraint
Provider, which in this case parses the constraints in a *.ocl document and
applies them to EXTLibrary model instances.  This sounds like what you are
aiming to do.


-----8<-----

>>> Yeah, sorry about my whining :) It's just that usually with Eclipse,
>>> the documentation gives you a lot of examples as starting points. But
>>> too often, there aren't enough explanations to make you really
>>> understand what you're doing (see the doc for the OCL environment
>>> class which takes  12 template parameters...).

Heh heh ... there are some brief works in the Javadoc and the Developer
Guide to explain that these parameters correspond to a metamodels'
representation of modeling constructs such
as "package", "classifier", "operation", "property", etc.  Don't let the
number of type parameters get in your way.  In concept, they all serve the
same purpose.


>> Let me whine a bit myself.  Have you had a look at some of the
>> specifications written out there?  How are users supposed to understand
>> things like that?

Much less implement them! :-)


> You're very right about that...
> 
>>>
>>>>> For example, I've seen a lot of EMF models with annotations named
>>>>> "OCL" and having several entries, but I can't really find anything
>>>>> that would explain me what to do with those.
>>>> Did you look at the Eclipse help?

The only OCL-specific annotations that I know of are those demonstrated in
my article:

http://www.eclipse.org/articles/article.php?file=Article-EMF-Codegen-with-OCL/index.html

These are in no way implemented by the Eclipse distributions of EMF or OCL. 
They are just an example.


-----8<-----

>> Hmmm.  I know the validation framework supports writing contains for the
>> SAM.ecore model that would apply to instances stored in *.sam files.  I
>> know Christian has written some nice help information for how to get
>> started with live validation...
> 
> Yes, I've read all this, and it's really awesome. But I'm not really
> sure if I need live validation, maybe later, I need to think some more ;)

Live validation really fits best with the EMF Transaction API, with which
you might build editors that use a TransactionalEditingDomain.  Otherwise,
some other kind of incremental batch-mode validation strategy is possibly
more advantageous, perhaps as an incremental workspace builder or localized
re-validation of objects affected by the execution of a Command.


-----8<-----

>>> Then I would ask the user to choose an ocl file and would use the OCL
>>> Eclipse project to open that OCL file, parse it and verify the
>>> constraints on my SAM model. Does that sound alright or is there a
>>> better way to do it?

This is the purpose for which the MDT OCL implementation provides parsing of
OCL files.  However, there may be more convenient ways to implement this
for your users than asking them to choose OCL files.  Perhaps some kind of
automatic discovery of OCL files, or a one-time registration ...


>> I think Christian has nice frameworks in place for all of this and that
>> he's documented them well.  I guess it's a little hard to find though,
>> but it is in the help system under fairly easy-to-find headings.
> 
> I've found all the documentation, read it and what I explained above is
> how I think I should proceed after having processed all I read. I just
> wanted to know if this seems a correct way to check a set of OCL
> constraints on SAM models given the fact that I can't modify the SAM
> meta-model.

OCL is always my first choice, but then I'm biased  :-)  Seriously, though. 
The nice thing about OCL is that it is model-based and portable between
modeling systems, not tied to any API.  I'd start with OCL and look for
alternatives only when your constraints reach beyond the expressive power
of OCL.


> Best regards,
>