Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 484591

Summary: [Tooling] Remove the superfluous multiplicity check of capsule parts in the tooling
Product: [Modeling] Papyrus-rt Reporter: Peter Cigehn <peter.cigehn>
Component: toolAssignee: Project Inbox <papyrusrt-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: papyrus-bugs, rschnekenburger
Version: 0.7.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=489009
https://git.eclipse.org/r/67885
https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=bb22c53bbc48ef6b3cf71af88b94f4bdee1aa716
Whiteboard:
Attachments:
Description Flags
Screen shot showing the superfluous warning dialog none

Description Peter Cigehn CLA 2015-12-17 10:44:06 EST
Created attachment 258767 [details]
Screen shot showing the superfluous warning dialog

Earlier it was introduced an explicit check of the multiplicity for capsule part, see discussion in Bug 473064 for example and an explicit dialog pops up in case a user enters an invalid multiplicity. The existence of this dialog was discussed already then, as indicated by Bug 473064 Comment 29.

Since a new constraint was added to the UML-RT profile, as part of Bug 483935, which checks that the multiplicity, the explicity checking for this in the UI/tooling is superfluous.

Apart from that, the tooling should really be updated to ensure that the user only can enter the upper bound part, which is related to introducing the field "Replication", see Bug 479350, which basically should prohibit the user from altering the lower bound of multiplicity.

Steps to reproduce:

1) Create a new UML-RT model
2) Create Capsule1 and Capsule2
3) Drag-and-drop Capsule2 onto Capsule1 to create capsule2 part
4) Select capsule2 part
5) In the properties on the Real Time tab view write "2..5" in the current multiplicity field (as long as Bug 479350 have not been fixed yet).
6) A dialog pops up stating "This multiplicity is not allowed for Capsule Part!" and the multiplicity is left unchanged in the model. Confusingly enough, the properties view is not refreshed so the text 2..5 is still shown in the properties view, so you have to switch to another element and back again to refresh the properties view and see that multiplicity has remained as before. But that is separate refresh issue.
7) Now switch editors using the switch button to the left of the multiplicity field so that you get separate editors for lower and upper bound (this shall also be removed within the scope of Bug 479350).
8) Now use the pen (edit) button to edit the value of lower bound to 2 and use the pen (edit) button to edit the value of upper bound to 5.  As can be seen, the superfluous check does not check all cases anyway, which makes is rather redundant.
9) Now validate the model
10) A problem appears in the Model Validation view, indicating "Fixed capsule parts cannot have variable multiplicity" which is the new constraint added by Bug 483935, which detects the invalid multiplicity.

Since we now have the constraint there should not be any need to have this superfluous check in the UI/tooling, especially considering that it does not detect the invalid multiplicity when editing the way shown in the steps to reproduce.
Comment 1 Peter Cigehn CLA 2016-03-04 07:40:54 EST
As can be seen in Bug 489009, there is an additional, explicit check made in the tooling regarding the change of aggregation. Instead of having that explicit check in the tooling it is suggested to add a constraint to the UML-RT profile for checking any invalid settings of aggregation. 

Then both the check for multiplicity and any invalid settings of aggregation will be covered by constraints in the UML-RT profile, and there is no need for these additional checks in the tooling itself.
Comment 2 Eclipse Genie CLA 2016-03-07 05:04:38 EST
New Gerrit change created: https://git.eclipse.org/r/67885
Comment 4 Remi Schnekenburger CLA 2016-03-17 04:12:48 EDT
Contribution merged, closing bug.
Comment 5 Peter Cigehn CLA 2016-03-17 07:40:32 EDT
Verified that the superfluous checks are not made in the tooling. If the model is not consistent, e.g. by updating it using the UML or the Advanced tab in the Properties view, then the constraints updated/added according to Bug 489009, detects those inconsistencies.

Most inconsistent states also makes radio buttons for selecting kind to be completely unselected, which makes it easy to fix the inconsistent state by selecting the appropriate radio button (before one of the radio buttons could still be selected, making it harder to fix the issue).
Comment 6 Peter Cigehn CLA 2017-02-01 04:46:31 EST
Mass closing already verified fixed/worksforme/wontfix bugs.