Hi Peter,
The UML Specification leaves this open. It only says that lower/upper bounds should evaluate to an integer. When and how
this happens is unspecified.
Eclipse/UML2 is slightly more constrained: everything that is not immediately evaluated to an integer is -1. That’s a
bug, which we workaround in the Papyrus validation
Regards,
Camille
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:43
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Update of the profile and update version numbers
Yes, but I guess there is a difference if the LiteralString can be evaluated into an integer/unlimited natural value, vs. whent the string cannot? I don't know the inner details of the UML spec
and the UML2 components implementation when you try to retreive the integerValue() respectively unlimitedValue() from a LiteralString.
If I check the UML spec upper and lower is derived according to:
body: if (lowerValue=null or lowerValue.integerValue()=null) then 1 else
lowerValue.integerValue() endif
body: if (upperValue=null or upperValue.unlimitedValue()=null) then 1 else
upperValue.unlimitedValue() endif
To conclude if there is a difference I guess we need to have one case "5".."5" and another case "MAX".."MAX" vs. "1".."5" and "MIN".."MAX".
But maybe the current tests already covers this? But then I do not understand how the violation actually can be detected for the case when upperValue and lowerValue has different LiteralStrings,
because I would expect both of them to be derived to 1.
On 10 December 2015 at 09:31, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> 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
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut
CARNOT CEA LIST
 www.eclipse.org/papyrus
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
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.
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.
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
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
 www.eclipse.org/papyrus
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
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?
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 "=").
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
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
www.eclipse.org/papyrus
_______________________________________________
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
|
