Eclipse Community Forums: EMF » invariant vs. constraint

Help

Home

Home » Modeling » EMF » invariant vs. constraint

Show: Today's Messages :: Show Polls :: Message Navigator

invariant vs. constraint [message #430331]

Fri, 15 May 2009 13:41

Dirk Hoffmann

Messages: 163
Registered: July 2009

Senior Member

Hi,

when reading the book or internet resources on EMF validation I found
the two concepts of "invariants" and "constraints".

For invariants I found

Considered a "stronger" statement about validity than a constraint

Looking at the generated code the only difference about them seems to be
the place where you need to put the actual validation code. For
constraints put it into the central validator class and for invariants
into the model class.

So where does "stronger" manifest in the generated code? I would have
expected that invariants get checked on every attempt to change an
object's state and rejecting the change if the invariant is violated
whereas with constraints validation takes place only upon the user's
request.

Regards,
Dirk

Report message to a moderator

Re: invariant vs. constraint [message #430341 is a reply to message #430331]

Fri, 15 May 2009 19:45

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Dirk,

Comments below.

Dirk Hoffmann wrote:
> Hi,
>
> when reading the book or internet resources on EMF validation I found
> the two concepts of "invariants" and "constraints".
>
> For invariants I found
>
> Considered a "stronger" statement about validity than a constraint
>
> Looking at the generated code the only difference about them seems to
> be the place where you need to put the actual validation code. For
> constraints put it into the central validator class and for invariants
> into the model class.
>
> So where does "stronger" manifest in the generated code? I would have
> expected that invariants get checked on every attempt to change an
> object's state and rejecting the change if the invariant is violated
> whereas with constraints validation takes place only upon the user's
> request.
All validation is done on demand. Invariants are easy to check
individually directly on the model, but there's not much that makes them
stronger other than that they are in the API of the model itself.
>
> Regards,
> Dirk

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: invariant vs. constraint [message #430355 is a reply to message #430341]

Sat, 16 May 2009 16:04

Philipp Kutter

Messages: 306
Registered: July 2009

Senior Member

> All validation is done on demand. Invariants are easy to check
> individually directly on the model, but there's not much that makes them
> stronger other than that they are in the API of the model itself.

Thus adding an EAnnotation and make dynamic templates triggering
automatic check after set for invariants is trivial, while doing it for
constraints would be harder.

Is it a wrong picture in my mind, if the invariants are thus intended to
be true from a class perspective, but the constraints are rather
intended to be true for a full model, and do typically relate to a
larger context?

May I ask how such an EAnnotation for automatic chack after set for
invariants could be interpreted in reflective models, without generated
code?

Would we need a variant of the eInvoke() solution you designed for
operation bodies?

Regards, Philipp

Report message to a moderator

Re: invariant vs. constraint [message #430357 is a reply to message #430355]

Sat, 16 May 2009 16:14

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

Philipp,

Comments below.

Philipp Kutter wrote:
>
>> All validation is done on demand. Invariants are easy to check
>> individually directly on the model, but there's not much that makes
>> them stronger other than that they are in the API of the model itself.
>
> Thus adding an EAnnotation and make dynamic templates triggering
> automatic check after set for invariants is trivial, while doing it
> for constraints would be harder.
Only a little. The model specific validator has methods you can invoke...
>
> Is it a wrong picture in my mind, if the invariants are thus intended
> to be true from a class perspective, but the constraints are rather
> intended to be true for a full model, and do typically relate to a
> larger context?
It's reasonable, but nothing enforces that...
>
> May I ask how such an EAnnotation for automatic chack after set for
> invariants could be interpreted in reflective models, without
> generated code?
Right now it can't.
>
> Would we need a variant of the eInvoke() solution you designed for
> operation bodies?
Yes.
>
> Regards, Philipp

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO] AuditSupport of MappingStrategy and Store does not match
Next Topic:	derived, volatile, not changeable, BUT NOT transient: error on resource creation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 04:21:14 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter