Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 483935 - [Core] UML-RT Profile & StateMachines addendum should be updated
Summary: [Core] UML-RT Profile & StateMachines addendum should be updated
Status: CLOSED FIXED
Alias: None
Product: Papyrus-rt
Classification: Modeling
Component: core (show other bugs)
Version: 0.8.0   Edit
Hardware: All All
: P3 enhancement
Target Milestone: 0.8.0   Edit
Assignee: Remi Schnekenburger CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-08 12:06 EST by Remi Schnekenburger CLA
Modified: 2016-09-29 14:55 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Remi Schnekenburger CLA 2015-12-08 12:06:03 EST 
Some evolutions are required on the profile:
- A constraint on CapsuleParts: Fixed capsule parts cannot have variable multiplicity
- A new stereotype RTGuard should be added as an extension of Constraint
- The constraint on RTStateMachines should be updated to add terminate pseudostate in the fordidden kind
Comment 1 Remi Schnekenburger CLA 2015-12-08 12:32:15 EST 
Plugin versions will be updated to 0.8.0 at the same time (profile has evolved, so all plugins should depend on the new version of this plugin)
Comment 2 Peter Cigehn CLA 2015-12-09 07:58:00 EST 
Preferably the new feature of the DSML Validation tooling shall be utilized for this update, see Bug 464249 Comment 14 and forward. This new feature partly has it origin from Bug 464387 Comment 14.
Comment 3 Eclipse Genie CLA 2015-12-09 12:58:05 EST 
New Gerrit change created: https://git.eclipse.org/r/62335
Comment 5 Peter Cigehn CLA 2015-12-14 03:33:37 EST 
I have tested the updated profile a bit. The new message without the "... not valid" at the end looks much better and is less confusing. The updated constraint for RTPseudostate works.

I also tested the constraint for multiplicity of capsule parts. For the basic cases where lowerValue is a LiteralInteger and upperValue is an LiteralUnlimitedNatural it works fine.

As discussed on the developer mailing list, I also checked the cases when lowerBound and upperBound are specified by LiteralString or OpaqueExpression (related to Bug 482923 and Bug 479350 Comment 2). The good thing is at least that you do not get any incorrect problems reported. Whenever you specify lowerBound/upperBound using a LiteralString/OpaqueExpressin the constraint passes, disregarding if the values of those LiteralStrings/OpaqueExpressions.

One could ask if the constraint should be able to detect that lowerValue and upperValue is specified by a LiteralString/OpaqueExpression with different values, e.g. the incorrect case of "MIN".."MAX". The rule should be that both lowerValue and upperValue should have the same (string) value in those cases also (whenever lower > 0). I guess it might be overkill (and maybe not even possible using OCL) to check that.

I suggest that we put this one into resolved/verified fixed if we do not see the need to detect the invalid LiteralString/OpaqueExpression cases.
Comment 6 Charles Rivet CLA 2016-09-29 14:55:38 EDT 
No comment since last December. Assuming that no one saw the need to detect the invalid LiteralString/OpaqueExpression cases.

Closing in preparation of v0.8 release