Home » Modeling » Papyrus » DSML validation functionality
DSML validation functionality [message #1044284] |
Thu, 18 April 2013 18:07 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
Hi,
I was playing around a bit with the DSML validation feature. Since this feature is not yet present on the Kepler nightly build (is it??), I tried with juno SR2. And although I couldn't find any documentation about the feature (is there some documentation somewhere??), I managed to get reasonably far. What I did so far:
I created a profile as shown
I added to OCL constraints on the stereotypes (one of them is not visible due to a problem with the image generation, but the OCL constraint states "self.base_class.isActive = false". I applied the DSML validation profile on the model, and set the validation rule stereotype on both constraints, and filled in the necessary stereotype properties.
After that, I generated a validation plugin from the profile, and a "profile plugin" such that the profile becomes a registered one for eclipse. When I now create a run-time instance using the two generated plugins, I can
* apply my profile to a UML model
* check in the preferences of the runtime instance that the validation plugin seems to work fine and the new constraints are present, see
So far, so good. However, when I try to validate the model using the new constraints, I get the following error for _both_ constraints:
The constraint "IntegerConstraintOCL" is disabled. It will not be evaluated.
java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unrecognized variable: (Property1)
at org.eclipse.emf.validation.ocl.AbstractOCLModelConstraint.getConstraintCondition(AbstractOCLModelConstraint.java:140)
at org.eclipse.emf.validation.ocl.AbstractOCLModelConstraint$QueryManager.check(AbstractOCLModelConstraint.java:203)
at org.eclipse.emf.validation.ocl.AbstractOCLModelConstraint.validate(AbstractOCLModelConstraint.java:155)
at org.eclipse.emf.validation.service.AbstractConstraintProvider$ConstraintProxy.validate(AbstractConstraintProvider.java:119)
at org.eclipse.emf.validation.internal.service.AbstractValidator.evaluateConstraints(AbstractValidator.java:241)
at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:264)
at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:211)
at org.eclipse.emf.validation.internal.service.BatchValidator.doValidate(BatchValidator.java:149)
at org.eclipse.emf.validation.internal.service.AbstractValidator.validate(AbstractValidator.java:147)
at org.eclipse.emf.validation.internal.service.AbstractValidator.validate(AbstractValidator.java:126)
at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:117)
at org.eclipse.emf.facet.infra.facet.validation.EValidatorAdapter.validate(EValidatorAdapter.java:62)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:159)
at org.eclipse.papyrus.infra.services.validation.commands.AbstractValidateCommand$2.validate(AbstractValidateCommand.java:190)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
at org.eclipse.papyrus.infra.services.validation.commands.AbstractValidateCommand.validate(AbstractValidateCommand.java:166)
at org.eclipse.papyrus.infra.services.validation.commands.AbstractValidateCommand$1.run(AbstractValidateCommand.java:113)
at org.eclipse.ui.actions.WorkspaceModifyDelegatingOperation.execute(WorkspaceModifyDelegatingOperation.java:69)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.ocl.SemanticException: Unrecognized variable: (Property1)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:358)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:328)
at org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:518)
at org.eclipse.ocl.internal.helper.HelperUtil.parseInvariant(HelperUtil.java:207)
at org.eclipse.ocl.internal.helper.OCLHelperImpl.createInvariant(OCLHelperImpl.java:216)
at org.eclipse.emf.validation.ocl.AbstractOCLModelConstraint.getConstraintCondition(AbstractOCLModelConstraint.java:137)
... 21 more
Can somebody tell me where I went wrong?
|
|
| | | | | | | |
Re: DSML validation functionality [message #1060236 is a reply to message #1059455] |
Thu, 23 May 2013 16:08 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
Klaas Gadeyne wrote on Sat, 18 May 2013 15:48Camille Letavernier wrote on Fri, 19 April 2013 11:12Klaas,
The support in Juno was incomplete and not usable. In Kepler, it is still work in progress (Basically, it works for most cases, but it is not fully integrated). You should wait for M7 before actually being able to use it, and it should be stable for the Kepler release.
Regards,
Camille
Hi Camille, I can't find this feature in papyrus M7 (not in main nor extra). Am I missing something (not looking in the right place?)?
Replying to myself (how pathetic .
Meanwhile, I managed to build the dsml-validation feature from papyrus-trunk. Given this feature, I can successfully validate the above model! Great!
Caveats/Questions/Remarks:
* For building the thing, there is still a dependency on "qompass designer validation". This seems weird to me (and brings in a whole bunch of other dependencies). Could somebody explain what is this qompass designer about, and why there is a dependency between the DSML validation stuff and the qompass designer stuff? [*]
* Contrary to what is described above this only works if the OCL evaluator delegate is set to LPG, otherwise one gets errors a la
Constraint "be.fmtc.Validation.MyFirstProfile.Stereotype1.IntegerConstraintOCL" could not find target EMF type "Class."
* There seems to be a problem with refreshing the error view. When changing the model, and revalidating, the old errors are not cleaned up.
* The error message could be a little more 'beautified' I guess, now it says
The 'ShouldBePassiveConstraint' invariant is violated on 'Stereotype1 7 -> <<Stereotype1>> <Class> Class1'
(in this case, 7 is the value of Property1 in the figure above)
But hey, it works
[*] The only thing that google came up with was [http://www.maenad.eu/public_pw/MAENAD_Deliverable_D6.1.3_V2.0.pdf], which links qompass to analysis on MARTE models. However, I can't see how profile validation would have a dependency on MARTE stuff, right??
Regards,
Klaas
|
|
|
Re: DSML validation functionality [message #1060270 is a reply to message #1060236] |
Thu, 23 May 2013 18:42 |
Camille Letavernier Messages: 952 Registered: February 2011 |
Senior Member |
|
|
Hi Klaas,
There are now two ways to define OCL constraints. The first one is through "DSML Validation", which AFAIK is not properly built on Hudson yet (I plan to fix that somewhere around RC2; or maybe between RC4 and the Kepler release, as it is not part of the release train). The second one is the default UML2 one, and is automatically used when you define a profile from Papyrus (In the UML2 editor, this is an option which is disabled by default).
So currently:
- When you define a profile, the OCL constraints are automatically embedded. Just apply this profile, and validate. That's it.
- If you choose to create a validation plug-in from your profile, and if you're lucky enough to make it work, the constraints will actually be validated twice (Because the auto-generated constraints are still here)
The dynamic/automatic approach works correctly in M7, but has several drawbacks:
- It is not possible to choose the severity of the error (Always "Error", there is no "Warning" status)
- It is not possible to associate a message to the error (Always "invariant is violated")
So you should use the dynamic approach for now. Much simpler, less bugs, and lightweight. There's nothing to install or configure. Just create OCL constraints, and define your profile.
Hopefully, the static approach will be fully operational for Kepler, and will allow to define more precisely the nature of your constraints. But currently, it is still experimental and I don't recommend using it.
Regards,
Camille
Camille Letavernier
|
|
|
Re: DSML validation functionality [message #1060280 is a reply to message #1060270] |
Thu, 23 May 2013 19:57 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi Camille
If you use OCLinEcore or Complete OCL you can define messages and
severity for invariants, and if you use an appropriate EObjectValidator
you can see them too. Unfortunately
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337792 remains unresolved.
Within Ecore the message is signalled by an additional EAnnotation.
Promoting this to UML makes it look nasty.
I think the solution must lie within OCL. I have been toying with
allowing an invariant to return a Tuple in place of the normal Boolean.
e.g.
invariant MyInv: Tuple{severity='error', code=911, message='bad ' +
self.name, constraint=self.name=self.name.toUpper(),
quickFixHandler='java:org.eclipse.mine.SimpleQuickFix'}
which would be legal OCL in UML.
Regards
Ed Willink
On 23/05/2013 19:42, Camille Letavernier wrote:
> Hi Klaas,
>
>
> There are now two ways to define OCL constraints. The first one is
> through "DSML Validation", which AFAIK is not properly built on Hudson
> yet (I plan to fix that somewhere around RC2; or maybe between RC4 and
> the Kepler release, as it is not part of the release train). The
> second one is the default UML2 one, and is automatically used when you
> define a profile from Papyrus (In the UML2 editor, this is an option
> which is disabled by default).
>
> So currently:
>
> - When you define a profile, the OCL constraints are automatically
> embedded. Just apply this profile, and validate. That's it.
> - If you choose to create a validation plug-in from your profile, and
> if you're lucky enough to make it work, the constraints will actually
> be validated twice (Because the auto-generated constraints are still
> here)
>
> The dynamic/automatic approach works correctly in M7, but has several
> drawbacks:
>
> - It is not possible to choose the severity of the error (Always
> "Error", there is no "Warning" status)
> - It is not possible to associate a message to the error (Always
> "invariant is violated")
>
> So you should use the dynamic approach for now. Much simpler, less
> bugs, and lightweight. There's nothing to install or configure. Just
> create OCL constraints, and define your profile.
>
> Hopefully, the static approach will be fully operational for Kepler,
> and will allow to define more precisely the nature of your
> constraints. But currently, it is still experimental and I don't
> recommend using it.
>
>
> Regards,
> Camille
|
|
|
Re: DSML validation functionality [message #1060394 is a reply to message #1060270] |
Fri, 24 May 2013 13:02 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
Hi Camille,
Camille Letavernier wrote on Thu, 23 May 2013 14:42Hi Klaas,
There are now two ways to define OCL constraints. The first one is through "DSML Validation", which AFAIK is not properly built on Hudson yet (I plan to fix that somewhere around RC2; or maybe between RC4 and the Kepler release, as it is not part of the release train).
Is there a bugzilla entry for that? (I couldn't find one at first sight?)
Quote:
The second one is the default UML2 one, and is automatically used when you define a profile from Papyrus (In the UML2 editor, this is an option which is disabled by default).
Are you referring here to Ed's bug report here [https://bugs.eclipse.org/bugs/show_bug.cgi?id=403787]? My guess would be that Papyrus still doesn't have an option for this right now, but the papyrus default is now "Process"?
Quote:
So currently:
- When you define a profile, the OCL constraints are automatically embedded. Just apply this profile, and validate. That's it.
- If you choose to create a validation plug-in from your profile, and if you're lucky enough to make it work, the constraints will actually be validated twice (Because the auto-generated constraints are still here)
The dynamic/automatic approach works correctly in M7, but has several drawbacks:
- It is not possible to choose the severity of the error (Always "Error", there is no "Warning" status)
- It is not possible to associate a message to the error (Always "invariant is violated")
So you should use the dynamic approach for now. Much simpler, less bugs, and lightweight. There's nothing to install or configure. Just create OCL constraints, and define your profile.
If only I would have known this earlier
It works indeed! However, next to the problems you describe above, the following things which I experienced with the static approach also apply:
* The OCL evaluator needs to be set to LPG. In case of setting it to pivot, the error log show
Severity Description Element Parent Type
Error An exception occurred while delegating evaluation of the 'ShouldBePassiveConstraint' invariant on 'Stereotype1 5 -> <<Stereotype1>> <Class> Class1': null Stereotype1 5 -> <<Stereotype1>> <Class> Class1 null EMF Problem
(without any further content in the log file)
* There seems to be a problem with refreshing the error view. When changing the model, saving it, and revalidating, the old errors are not cleaned up! This is very confusing!
* The error message could be a little more 'beautified' I guess, now it says
The 'ShouldBePassiveConstraint' invariant is violated on 'Stereotype1 7 -> <<Stereotype1>> <Class> Class1'
(in this case, 7 is the value of Property1 in the figure above)
Quote:
Hopefully, the static approach will be fully operational for Kepler, and will allow to define more precisely the nature of your constraints. But currently, it is still experimental and I don't recommend using it.
As a last request. I was following [https://bugs.eclipse.org/bugs/show_bug.cgi?id=382975] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=382733], but they both seem related to the static approach. Could you point me to the right (meta-)bug for the dynamic approach?
Thx,
Klaas
|
|
| | | |
Goto Forum:
Current Time: Wed Sep 25 08:29:19 GMT 2024
Powered by FUDForum. Page generated in 0.08778 seconds
|