Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Invariants on EStructuralFeatures(Is it possible to define invariants applied to EStructuralFeatures?)
Invariants on EStructuralFeatures [message #1343821] Fri, 09 May 2014 13:22 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi everyone,

after implementing a set of restrictions over our models, I realised org.eclipse.emf.common.util.Diagnostic generated by the validation delegated to org.eclipse.ocl.ecore.delegate.OCLValidationDelegate did not contain certain information some frameworks expect (for instance, error decoration in a form editor for a given EStructuralFeature).

Indeed, the invariant I created was over an EClass, and therefore, the diagnostic returned applies only to our EClass instance. I understand this is the expected behavior. However, it would be desirable being able to define invariants over EStructuralFeature, so at certain point, a diagnostic would tell us something such as "the value of your feature does not complain to invariant XYZ", instead of "your EClass instance does not complain to invariant XYZ".

By looking at the documentation, I can't find a way to achieve this.
Apparently, and focusing only on contraints over EStructuralFeatures, one can use OCLInEcore either to derive them, or calculate its initial value (very cool!).

Is there a way to achieve the described scenario? Is this a missing feature or something that cannot be implemented for some reason?

Best Regards,
Víctor Roldán Betancort.
Re: Invariants on EStructuralFeatures [message #1344010 is a reply to message #1343821] Fri, 09 May 2014 15:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The tutorials explain how to do custom messages, using an OCL expression
to compute the message.

Regards

Ed Willink


On 09/05/2014 14:22, Victor Roldan Betancort wrote:
> Hi everyone,
>
> after implementing a set of restrictions over our models, I realised
> org.eclipse.emf.common.util.Diagnostic generated by the validation
> delegated to org.eclipse.ocl.ecore.delegate.OCLValidationDelegate did
> not contain certain information some frameworks expect (for instance,
> error decoration in a form editor for a given EStructuralFeature).
>
> Indeed, the invariant I created was over an EClass, and therefore, the
> diagnostic returned applies only to our EClass instance. I understand
> this is the expected behavior. However, it would be desirable being
> able to define invariants over EStructuralFeature, so at certain
> point, a diagnostic would tell us something such as "the value of your
> feature does not complain to invariant XYZ", instead of "your EClass
> instance does not complain to invariant XYZ".
>
> By looking at the documentation, I can't find a way to achieve this.
> Apparently, and focusing only on contraints over EStructuralFeatures,
> one can use OCLInEcore either to derive them, or calculate its initial
> value (very cool!).
>
> Is there a way to achieve the described scenario? Is this a missing
> feature or something that cannot be implemented for some reason?
>
> Best Regards,
> Víctor Roldán Betancort.
Re: Invariants on EStructuralFeatures [message #1344331 is a reply to message #1344010] Fri, 09 May 2014 18:25 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

I've not being clear enough. I wasn't refering to the customization of the validation messages. A code snippet may clarify this:

diagnostics.add
(createDiagnostic
(Diagnostic.ERROR,
 DIAGNOSTIC_SOURCE,
 PARAMETER_NAME_MUST_NOT_BE_EMPTY,
 "_UI_GenericConstraint_diagnostic",
 new Object[] { "name of a parameter must be defined", getObjectLabel(parameter, context) },
 new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME },
 context));

The Diagnostic instance has an atribute named "data", in the above example corresponds to:
new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME }

Which means that I'm passing to the diagnostic the EClass instance that violates the constraint, and more specifically, the EAttribute that violates it.
org.eclipse.emf.common.util.Diagnostic.getData()

The Diagnostic.data atribute seems to be used by implementations to add information about the diagnostic itself, for instance, some frameworks expect to find here EStructuralFeature instances, which means not only that a certain EClass instance violates a constriant, but also that an specific feature within that EClass is the culprit. This helps to decorate with error markers in UI editors, such as forms.

As reference, you may find several examples in org.eclipse.emf.ecore.util.EcoreValidator

Now, back to OCL. I'm assuming the OCL Validation Delegation does take care of the evaluation of invariants at some point, and creates the Diagnostic instances afterwards (I cant seem to find any evidence of this, though). I'd like to see these Diagnostic instances wrapping the culprit EStructuralFeature so my form editors have a formal reference to the culprit. I'm not looking to show a generic message "your name is invalid", I want my forms to know which EStructuralFeature is invalid, so it can trigger more clever logic, for instance, decorating the input box corresponding to the "name" EAttribute with an error marker.

I hope you have now a clearer picture. The EcoreValidator class should depict better what I want to explain.

Cheers,
Víctor Roldán Betancort.
Re: Invariants on EStructuralFeatures [message #1345997 is a reply to message #1344331] Sat, 10 May 2014 11:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
HI Victor

Sorry you're limited by the capabilities of EMF delegates and the
UML/OCL inspiration.

EMF's ValidationDelegates supports only EClass constraints and
invariants (implemanted as callable EOperations).

EMF's InvocationDelegates support EOperation bodies

EMF's SettingDelegates support EProperty initilaization

UML/OCL have derived/initial property constraints, but a derived
property constraint is really just a Class invariant that happens to
mention the property as a constrained element. An initial property
constraint is not a constraint at all; it influences the default/initial
value; the specification is not yet precise.

Just look at EcoreValidator; no individual EStructuralFeature constraints.

Of course EStructuralFeature has constraints.

If you look at markers in the Sample Ecore Editor, you get to see then
in pretty much the detail that you require.

o if you have a [10..5] multiplicity, the marker appears on the property.

I just tried it. If you open the Property View, the markers now (Luna
M7) appear in relevant form lines.

So just see how the Sample Ecore Editor works.

Regards

Ed

On 09/05/2014 19:25, Victor Roldan Betancort wrote:
> Ed,
>
> I've not being clear enough. I wasn't refering to the customization of
> the validation messages. A code snippet may clarify this:
>
>
> diagnostics.add
> (createDiagnostic
> (Diagnostic.ERROR,
> DIAGNOSTIC_SOURCE,
> PARAMETER_NAME_MUST_NOT_BE_EMPTY,
> "_UI_GenericConstraint_diagnostic",
> new Object[] { "name of a parameter must be defined",
> getObjectLabel(parameter, context) },
> new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME },
> context));
>
> The Diagnostic instance has an atribute named "data", in the above
> example corresponds to:
> new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME }
> Which means that I'm passing to the diagnostic the EClass instance
> that violates the constraint, and more specifically, the EAttribute
> that violates it.
> org.eclipse.emf.common.util.Diagnostic.getData()
> The Diagnostic.data atribute seems to be used by implementations to
> add information about the diagnostic itself, for instance, some
> frameworks expect to find here EStructuralFeature instances, which
> means not only that a certain EClass instance violates a constriant,
> but also that an specific feature within that EClass is the culprit.
> This helps to decorate with error markers in UI editors, such as forms.
>
> As reference, you may find several examples in
> org.eclipse.emf.ecore.util.EcoreValidator
> Now, back to OCL. I'm assuming the OCL Validation Delegation does take
> care of the evaluation of invariants at some point, and creates the
> Diagnostic instances afterwards (I cant seem to find any evidence of
> this, though). I'd like to see these Diagnostic instances wrapping the
> culprit EStructuralFeature so my form editors have a formal reference
> to the culprit. I'm not looking to show a generic message "your name
> is invalid", I want my forms to know which EStructuralFeature is
> invalid, so it can trigger more clever logic, for instance, decorating
> the input box corresponding to the "name" EAttribute with an error
> marker.
>
> I hope you have now a clearer picture. The EcoreValidator class should
> depict better what I want to explain.
>
> Cheers,
> Víctor Roldán Betancort.
Re: Invariants on EStructuralFeatures [message #1349779 is a reply to message #1345997] Mon, 12 May 2014 10:47 Go to previous message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Ed,

thanks for your insight. I see your point with the EMF delegation mechanisms.

Right know I think my best bet is to use the EMF generator to create my own EValidator and implement my constraints through java code (pretty much as EcoreValidator does). Adding a constraint annotation like this:

<eAnnotations source="http://www.eclipse.org/emf/2002/Ecore">
  <details key="constraints" value="myContraintName"/>
</eAnnotations>

as described in:

http://www.eclipse.org/forums/index.php?t=msg&th=129754

triggers the generation of an EValidator implementation with stubs for the constraints described in the annotation.

Thanks Ed!
Víctor Roldán Betancort
Previous Topic:Is it pivot validation bug?
Next Topic:OCL Pivot - Visitor implementation
Goto Forum:
  


Current Time: Tue Mar 19 07:34:56 GMT 2024

Powered by FUDForum. Page generated in 0.02867 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top