[news.eclipse.modeling.mdt.uml2.ocl] Re: Using OCL to specify derived Re

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

Hi, JÃrgen,

The EMFT Validation project can, indeed, help you to achieve the deferred
validation that you are seeking.  Before I get into that, though, I should
just mention that the OCL support in EMFT Validation is simply to allow OCL
to be used to defined constraints in a "constraint provider" within the
EMFT Validation framework.  Other supported languages are "Java" (in which
a constraint is implemented by a named Java class) and "EMF" (in which a
constraint is delegated to an EOperation in the Ecore model; more on that
later).

EMFT Validation provides two "modes" in which it evaluates constraints: 
Live and Batch.  The Batch mode is intended for user-driven validation
(e.g., selecting a "validate" menu action), and Live mode is intended for
on-the-fly validation of edits.  This latter mode can be used to validate
every discrete change that is made in a model, as it occurs.  However, it
is often expedient to allow temporary inconsistencies on the assumption
that they will be resolved when an edit transaction completes.  This is
where the EMFT Transaction API extends the validation framework's
definition of "Live" validation to evaluate constraints when a transaction
commits.

To hook the constraints that you generate from Ecore annotations into the
EMFT Validation framework, you need to declare them in a constraint
provider using the "EMF" constraint language.  The
org.eclipse.emf.validation.examples.adapter example plug-in demonstrates
how to define constraints that delegate to the Ecore model in this way.  To
install this example, select "File -> New Example" from the main menu and
pick the appropriate EMFT Validation example.  The Examples Guide in the
help provides more information, too.  You may want to have a look at the
other examples, too, to see how "Live" validation works and how it differs
in the EMFT Transaction world.

HTH,

Christian


JG wrote:

> Christian,
> 
> 
> Christian W. Damus wrote:
> 
>> OCL, as UML, does not distinguish between "attributes" and "references"
>> as
>> Ecore does; these are all just Properties.  Thus, "der:" constraints
>> specified in OCL can derive read-only values for either of these kinds of
>> properties.
>> 
>> You can use OCL in the EMF code generation process to specify derived
>> properties as described in this article:
>> 
>> http://www.eclipse.org/articles/Article-EMF-Codegen-with-OCL/article.html
> 
> I have already stumbled across this article and I am working through it
> at the moment (in parallel to a few other things, so progress is slow).
> I used an EAnnotation in the Ecore model to specify a method body (but
> since I am new to the OCL syntax I yet have to define something useful).
> I got the code created as shown in the above tutorial. I also tried to
> define a constraint like "myAttribute>0", by using the "inv:" constraint
> on the attribute, but apparently, the OCL SDK did not generate code that
> checks this invariant upon setting the attribute.
> How can this be done?
> Is there a way to make constraint checks "deferred" (i.e. allow
> inconsistent attributes during a series object modifications and check
> for validity after the modifications).
> 
> Can you tell me the relationship between the two EMFT projects "OCL" and
> "Validation"? Apparently, OCL aims at creating code from OCL constraints
> attached as annotations... but what is the scope of Validation? To me it
> seems that their goals are at least partially overlapping (Validation
> mentions supporting OCL). Validation describes something like the
> "deferred constraints".
> 
>> 
>> There are also plans for the UML2 UML and OCL components to implement
>> support for specifying OCL constraints such as property derivations in
>> UML models:
>> 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=163808
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=105199
> 
> Thanks for this hint, but I hope I can stick with basic Ecore models for
> now.
> 
> Regards
> 
> JÃrgen