Community
Participate
Working Groups
Created attachment 251433 [details] Example UML-RT model If you validate a UML-RT model, then a number of runtime exceptions occurs which is logged in the error log. These exceptions causes the constraints to be disabled and thus never being evaluated. Steps to reproduce: 1) Import the attached model 2) Validate it by right clicking the model in the model explorer and select Validation > Validate model 3) Now 9 warnings gets logged in the error log indicating that 9 constraints have been disabled. The error log have been attached. 8 of the warnings are related to org.eclipse.ocl.SemanticException and one regarding org.eclipse.ocl.SyntaxException. Not sure if this is a tooling issue or something that is incorrect with the actual profile. If it something wrong with the profile itself then this should probably be aligned with the updates in bug 461830 which will cause an update of the UML-RT profile anyway.
Created attachment 251434 [details] Error log with the warnings about disabled constraints
Just to be more clear here is an extract from the attached error log regarding which the 9 failing constraints are: !MESSAGE The constraint "Private visibility is not supported on capsule features" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unknown type ([UML, VisibilityKind, private]) !MESSAGE The constraint "All operations of a capsule are sequential" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unknown type ([UML, CallConcurrencyKind, sequential]) !MESSAGE The constraint "A public port must be defined as a service port" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unknown type ([UML, VisibilityKind, public]) !MESSAGE The constraint "A SAP (unwired & unpublished) must have protected visibility" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unknown type ([UML, VisibilityKind, protected]) !MESSAGE The constraint "An SPP (unwired and published) must have public visibility" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unknown type ([UML, VisibilityKind, public]) !MESSAGE The constraint "RT state machines must have a context and it must be a Class" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unrecognized variable: (behavioredClassifier) !MESSAGE The constraint "Passive state machine are only allowed on passive data classes" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unrecognized variable: (behavioredClassifier) !MESSAGE The constraint "Regions in RT state machines cannot have a final state" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SemanticException: Unrecognized variable: (FinalState) !MESSAGE The constraint "RT state machines do not support concurrency or shallow history" is disabled. It will not be evaluated. java.lang.RuntimeException: org.eclipse.ocl.SyntaxException: 2:1:2:3 "let" unexpected token(s)
I could reproduce the problem. It is caused by the umlrt.validation plugin which does not reference the newer OCLpivot language and is not synchronized with the profile. The cause is that the regeneration of the validation plugin does not update the constraint definitions inside. Currently, the validation-plugin generator (silently) ignores constraints that do not apply the "ValidationRule". For some reason, the new version of the UML/RT profile does not longer apply the DSML validation profile - I guess it got unapplied by accident due to opening it without installing DSML validation first. I will make the generator more robust by indicating an empty set of constraints to the user and (eventually) by generating a plugin entry also for constraints that do not apply the "ValidationRule" stereotype.
So if I have understood it correctly, the issue identified in Bug 461856 is not due to that the re-generation of the validation plugin has not been performed, but that the re-generation indeed has been performed, but the mismatch that can be seen is due to the loss of the ValidationRule stereotypes and the DSML validation profile no longer being applied, which in its turn caused the validation plugin to not be re-generated correctly? Ansgar, can you please clarify this in Bug 461856 as well?
(In reply to Peter Cigéhn from comment #4) > So if I have understood it correctly, the issue identified in Bug 461856 is > not due to that the re-generation of the validation plugin has not been > performed, but that the re-generation indeed has been performed, but the > mismatch that can be seen is due to the loss of the ValidationRule > stereotypes and the DSML validation profile no longer being applied, which > in its turn caused the validation plugin to not be re-generated correctly? > > Ansgar, can you please clarify this in Bug 461856 as well? Effectively, I don't know if the regeneration has been done. If it is the case, it wouldn't have been effective. I raised bug 464249 to track this issue. I already have a version of the plugin-generator that uses default messages if the ValidationRule stereotypes are not applied and now I don't get exceptions during validation anymore. I will re-apply the stereotypes to get custom messages before pushing the change. It's likely that 461856 is also caused by this issue.
commit d7aff9b66bc83977c82471e4932170f88a9d05e8 for master fixes two issues (1) Add DSML validation stereotypes to current version of profile (2) Regeneration of validation plugin Now, there is still one exception (see below) during, but it is not specific to the UML/RT profile - and it will not cause the disabling of rules. (org.eclipse.ocl.pivot.uml.internal.es2as.UML2ASUseSwitch - Failed to create a pivot representation of a UML 'Trigger')
I've tried updating to the latest Mars build but there are some strange things going on. I still get the same issues, but I can also see that the list of constraints available when checking Preferences > Model Validation > Constraints still lists some old constraints, e.g. the one that has been renamed from "...sequential" to "...guarded". When checking a bit more I can see that the version number of the all the UML-RT plugins all have the form 1.1.0.qualifier. I guess that these kinds of things can cause issues with loading the latest version of the plugin, in case you have several versions of a plugin available. I guess this should be fixed in general for all the UML-RT plugins. I will try this again with a clean installation to ensure that I only have the latest set of plugins available.
Created attachment 252264 [details] Screenshot of validation selection dialog for UML/RT Here you see the validation selection dialog on my machine. The qualifier in 1.1.0.qualifier gets replaced with a timestamp during the build, all Papyrus plugins use this scheme.
The 1.1.0.qualifier version was shown when I checked the in the Plug-ins view in the Plug-in Development perspective. All other Papyrus (at least the ones I checked) had a version number with a time stamp, whereas all the UML-RT plugins still had the 1.1.0.qualifier version number in this list. I get a feeling that the time stamp had not been applied during build of the UML-RT plugins. And you're list of constraints looks like what I would have expected, especially the one that had been renamed to "...guarded". I still had "...sequential" in my list, which indicates that even if I had made an update an old version of the plugin had been loaded (which could have been caused by the version number still being 1.1.0.qualified). I am still in the process of performing a clean install.
Created attachment 252265 [details] Screen shot showing the version numbers being 1.1.0.qualifier Now I managed to get a clean install, and now the issue seem to have been resolved. None of the constraints are now disabled, at least the ones that now exist. One thing that now happened though was that all constraints related to the separate state-machine profile are gone. Earlier they could be found in its own top level category. So I am still not sure if any of the state-machine related constraints still fails or not. So I definitively had some issues with the wrong version of the plugin being loaded, i.e. still and old one. Please look into this issue with 1.1.0.qualifier still being the version of the UML-RT plugins after the build. I have attached a screen shot showing this.
I checked a bit and what I can see the state-machine profile still do not have the DSML validation profile applied, and none of the constraints in that profile have the ValidationRule stereotype applied. One other thing that I noticed when validating the model is that the error message for the renamed constraint related to "...guarded" still have "...sequential" in its message. When checking plugin.xml of the validation plugin I can see the following: <constraint id="allOperationsSequential" isEnabledByDefault="true" lang="OCLpivot" mode="Batch" name="All operations of a capsule are guarded" severity="ERROR" statusCode="1"> <message>All operations of a capsule are sequential</message><![CDATA[base_Class.ownedOperation->notEmpty() implies (base_Class.ownedOperation->forAll(op | op.concurrency = UML::CallConcurrencyKind::guarded))]]></constraint> There seem to some very confusing naming here, where the id, the name and the message have a mix of the old name with sequential and the new name with guarded. I am not sure what it is that controls the id, the name and the actual message. But they must be aligned. I have not checked the other constraints yet, but I suspect that there could be more of these kinds of issues.
You are right, I only corrected the umlrt/profile itself, not the separate state-machine profile.
Created attachment 252266 [details] Screenshot of validation selection dialog for UML/RT state machines The screenshot shows that UML/RT state-machines and UML/RT are in different categories after generation. Would that be ok?
(In reply to Ansgar Radermacher from comment #13) > Created attachment 252266 [details] > Screenshot of validation selection dialog for UML/RT state machines > > The screenshot shows that UML/RT state-machines and UML/RT are in different > categories after generation. Would that be ok? Commit f596d3e7f4d5b4ff4af2ce97e39e59d27f59c793 (for master) adds support for UML/RT statemachine constraints.
I installed the latest Mars build, and indeed now the state-machine related constraints are back again. All constraints, at least I think that my small example model should cover all relevant elements, now can be evaluated without run-time exceptions. Regarding the issue with the 1.1.0.qualifier that I could see was related to the fact that I had imported these projects into my workspace from the Git repo, hence showing the version from the source plugin, not the loaded one. So I guess you can disregard from my earlier comments about this. Regarding the categories I think it is good to keep them separate. But we could very well have one top level category for "UML-RT Constraints" and then two sub-categories "UML-RT Basic" and "UML-RT State Machines", to not clutter the top level with too many categories. The current names with some internal id does not look that nice. But in general the constraint categories should have a better structure and some more defined naming rules. Not sure though if we shall cover that with this Bugzilla. The misaligend ids and messages we should probably cover with another Bugzilla. I put this one into resolved fixed (including Bug 461856 now when you have re-generated the validation plugin). Then we just need to make sure that we have a good process in place to keep this up-to-date whenever we make updates to the UML-RT profile(s).
Verified to be fixed in the latest Mars build.
