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
+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
--
Ansgar Radermacher CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx
|
