| Re: [papyrus-rt-dev] [PROVENANCE INTERNET] Re: Update of the profile and updateversionnumbers |
Hi Remi, all
please note that patch https://git.eclipse.org/r/#/c/61719/
(which is not yet integrated) removes any specific min/max handling from Papyrus, as it is not correctly handled in the UML2 plugin already.
Best regards
Ansgar
On 10/12/2015 09:31, SCHNEKENBURGER Remi 211865 wrote:
Hi,
FYI, there are 5 different tests currently, all green:
- Min[LiteralInteger] = Max[UnlimitedNatural] – constraint valid
- Min[LiteralInteger] != Max[UnlimitedNatural] – constraint violated – detected in the tests
- Min[LiteralString] = Max[LiteralString] – constraint valid
- Min[LiteralString] != Max[LiteralString] – constraint violated – detected in the tests
- 0[LiteralInteger] != 3 [UnlimitedNatural] – constraint now checked (as it is an optional capsulePart)
There could be 2 or 3 more on the OpaqueExpressions.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : jeudi 10 décembre 2015 09:24
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Update of the profile and update version numbers
Hi,
That was good news that we were able to use this new feature also on the Mars track! Looks good, as you say the confusing "...not valid" at the ends of the messages are now gone! Great.
Regarding the test of the multiplicity, I would like to add a few more just for the sake of it. Considering the discussion around symbolic constants in the code-generator Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=482923 but also in the related tooling Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=479350 I would like to have tested the cases when you have both a LiteralString in form of a symbolic constants, e.g. the string "MAX".
The normal expected case should be that both lowerValue and upperValue both have a LiteralString with the same value, i.e. basically "MAX"..."MAX" for fixed capsule parts, or 0.."MAX" for optional/plugin capsule parts, i.e. lowerValue is LiteralInteger and upperValue is a LiteralString.
The same cases should also be tested with an OpaqueExpression (since we have not yet really decided whether the tooling should use LiteralString or OpaqueExpressions as the legacy tooling is), specify lowerValuy and upperValue with an OpaqueExpression with some suitable language and a body with "MAX".
I guess for completeness we should test also the invalid cases where the symbolic string differs between lowerValue and upperValue, e.g. "MIN"..."MAX". But I guess that since the OCL constraint is based on the derived features lower and upper, the derived integer respectively natural unlimited values will be 1 in both cases.
I don't think it is needed and we probably should not bother about checking the string values (for the case of symbolic constants) of the LiteralString/OpaqueExpression always are the same.
/Peter Cigéhn
On 9 December 2015 at 19:10, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
Hi,
I pushed a new gerrit to add the support of the new DSML plugin version[1]. The stereotype <<MessageHandling>> is also in the Mars maintenance branch, so I could apply it to the UML-RT and UML-RT StateMachines profile.
The new messages do not have the ‘not valid’ at the end. I added new tests on the validation for the capsulepart multiplicities to be sure the rule was well written, because I had doubt on non-integer based multiplicity compare. I could also add a check on the message being presented to the user, to be sure we have no regression in this area. Here is a snapshot from the test model for validation rule, with a compare between 2 upper/lower values being LiteralStrings “3” and “15”.
Regards
Rémi
[1] https://git.eclipse.org/r/62335
-------------------------------------------------------
Rémi SCHNEKENBURGER
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : mercredi 9 décembre 2015 13:09
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Update of the profile and update version numbers
Hi,
I have tried to look at changes in Gerrit, but I am not sure I can see the change related to the discussion in the following Bugzilla:
Ansgar have made some improvements to the DMSL Validation tooling regarding how the messages gets formatted. I would have expected the new <<MessageHandling>> stereotype to have been applied, with the property "messageMode" set to "NameIsMessage" (if I understood Ansgar correctly regarding how this new feature should be used for the UML-RT profile). But maybe that new feature is only available in the DSML Validation tooling on the Neon track?
The current naming of the actual error message with the "... not valid" is rather confusing (as discussed also in https://bugs.eclipse.org/bugs/show_bug.cgi?id=464387#c14).
So I was just expecting the improvement Ansgar made to be included in this update of the profile. But maybe we have to wait until we are on the Neon track to get these improvements included in Papyrus-RT?
One very minor comment: I am not used to write OCL so I am not sure what conventions normally are used. But I can see that you have written the multiplicity constraint for capsule parts without spaces around ">", whereas Bran in his proposal had spaces. I guess these are things that an OCL expert will find "annoying" if the convention normally is to use spaces around ">" (you have used spaces around "=").
/Peter Cigéhn
On 9 December 2015 at 12:24, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
Hi,
I pushed on gerrit an updated version of the profile [1]. That will be the first step of the general update to version 0.8.0 of Papyrus-RT.
Before continuing the update of the version numbers to 0.8.0, could you have a look to the new profile version and check if everything is OK for you?
Tomorrow, I will update the version numbers. I initially planned to update all the version numbers of the plugins / features doing a basic search and replace. Do you all agree to that update, also for codegen and xtumlrt plugins ? There will probably be some issues on the build system, as there could be in the Hudson job configurations some references to 0.7.1 versions I do not see. Is the timing OK for you to have the update tomorrow or would you like to wait another time frame?
Regards,
Rémi
[1] https://git.eclipse.org/r/#/c/62285/
-------------------------------------------------------
Rémi SCHNEKENBURGER
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
-- Ansgar Radermacher CEA/DRT/DILS/LISE http://www-list.cea.fr/index.htm phone: +33 16908 3812 mailto: ansgar.radermacher@xxxxxx
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
