Community
Participate
Working Groups
Ports with multiplicity > 1 should be shown as a stack of ports. The topic has been discussed for capsule parts in bug 482694. As discussed with Peter C., this Bugzilla was written to separate the two issues. Another related Bugzilla is bug 496304.
Some clarifications: First the minor aspect regarding terminology. We shall probably refer to this as replication > 1. See Bug 479352 for the simplification and introduction of the replication field for ports, as a replacement for the more complex multiplicity (and its lower and upper bounds). Also don't consider "> 1" as strictly the only case when stacking shall be shown. If the replication factor is specified using a symbolic constant, i.e. an OpaqueExpression, then it should be assumed that the port is replicated (disregarding what the current, possibly unknown, value of that symbolic constant has). Please see Bug 482694 Comment 18.
One more thing to make clear: This is actually a regression, since the stacking of ports actually once worked, see Bug 482694 Comment 12.
This seem to work again, at least partly. It is a bit tricky to test though since the replication field for ports not yet are in (according to Bug 479352). Anyway, when changing multiplicity on the standard UML tab, the stacking pattern is not immediately updated. Seem to be some refresh issue going on. But when selecting the diagram and the diagram is refreshed the stacking pattern appears (which is quite confusing). This needs to be tested further when Bug 479352 has been completed. What is not working is the stacking pattern for ports on capsule parts. Here the stacking pattern is not shown at all. And the size aspect, including the stacking pattern, should be considered according to the discussion in Bug 496304 related to the alignment of port sizes with legacy models (to avoid that different ports sizes causes additional bend points and routing of connectors).
(In reply to Peter Cigehn from comment #3) > This seem to work again, at least partly. It is a bit tricky to test though > since the replication field for ports not yet are in (according to Bug > 479352). As such, is a dependency on Bug 479352 required? > > Anyway, when changing multiplicity on the standard UML tab, the stacking > pattern is not immediately updated. Seem to be some refresh issue going on. > But when selecting the diagram and the diagram is refreshed the stacking > pattern appears (which is quite confusing). This needs to be tested further > when Bug 479352 has been completed. > > What is not working is the stacking pattern for ports on capsule parts. Here > the stacking pattern is not shown at all. And the size aspect, including the > stacking pattern, should be considered according to the discussion in Bug > 496304 related to the alignment of port sizes with legacy models (to avoid > that different ports sizes causes additional bend points and routing of > connectors). This seems to me that this bug is confirmed, so I moved it to "New". This is also an important aspect of the UML-RT visual "language" that is part of the 0.8 (MVP1, structure) release, so I marked it as such.
(In reply to Charles Rivet from comment #4) > (In reply to Peter Cigehn from comment #3) > > This seem to work again, at least partly. It is a bit tricky to test though > > since the replication field for ports not yet are in (according to Bug > > 479352). > > As such, is a dependency on Bug 479352 required? If I had access rights do so, I would already have added such a depends on to indicate this. But I cannot do this myself.
(In reply to Peter Cigehn from comment #5) > (In reply to Charles Rivet from comment #4) > > (In reply to Peter Cigehn from comment #3) > > > This seem to work again, at least partly. It is a bit tricky to test though > > > since the replication field for ports not yet are in (according to Bug > > > 479352). > > > > As such, is a dependency on Bug 479352 required? > > If I had access rights do so, I would already have added such a depends on > to indicate this. But I cannot do this myself. Added dependency for Peter
(In reply to Peter Cigehn from comment #3) > Anyway, when changing multiplicity on the standard UML tab, the stacking > pattern is not immediately updated. Seem to be some refresh issue going on. > But when selecting the diagram and the diagram is refreshed the stacking > pattern appears (which is quite confusing). This needs to be tested further > when Bug 479352 has been completed. Now when Bug 479352 have been fixed, I checked this again. And indeed, the refresh is made immediately when changing replication using the new replication field on the UML-RT tab. So the stacking pattern becomes visible immediately after changing the replication field to something larger than 1. But now one can see the same kind of refresh issue as in Bug 500751, e.g. if an external behavior port is placed on the left border, then changing to a replicated port only show the stacking pattern "on the inside" of the capsule frame. As indicated in Bug 496304, the stacking pattern in the legacy tooling, both for ports as well as for capsule parts, are always shown on the inside of the original frame of the port or capsule part, i.e. changing to a replicated port or capsule part does not make the frame "bigger" and the size is kept. I guess that doing the same in Papyrus-RT could help these kind refresh issues, including the problem also seen for capsule parts as Bug 482694. So what remains for this Bugzilla is to ensure that also ports on capsule parts gets the stacking pattern. But then I think it is even more important to not add any additional size to the port, but instead align the size with the legacy tooling to ensure that imported models does not get its layout changed too much (as indicated in Bug 496304). Probably we should write a new Bugzilla for improving the stacking pattern in general, both for ports and capsule parts, to not increase the size of the shape but instead keep the stacking pattern "on the inside" of the shape. This could then hopefully solve issues with graphical refresh issues both for replicated ports and capsule parts.
(In reply to Peter Cigehn from comment #7) > Probably we should write a new Bugzilla for improving the stacking pattern > in general, both for ports and capsule parts, to not increase the size of > the shape but instead keep the stacking pattern "on the inside" of the > shape. This could then hopefully solve issues with graphical refresh issues > both for replicated ports and capsule parts. I've written a more general Bug 500982 for the improvement of how the stacking pattern is rendered, and made that one block this one.
New Gerrit change created: https://git.eclipse.org/r/82616
The gerrit patch addresses the problem that the stack pattern for port is not shown for ports on paths (apply the patch for 500982 first to get a nicer result)
I've tested the proposed Gerrit change, and indeed it brings back the stacking pattern also for ports on capsule parts. I suggest that we merge the fix and put this one into resolved fixed and then I can verify it in a build of Papyrus-RT.
Gerrit change https://git.eclipse.org/r/82616 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=6d64e1d94645ce0378c5718950462164352ad612
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/82616 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=6d64e1d94645ce0378c5718950462164352ad612 I've tested this in the latest Papyrus-RT build, and the stacking pattern is now also shown for ports on capsule parts. I suggest that we put the Bugzilla into resolved/verified fixed, unless there are some unit tests that we feel should be added before we can consider this one to be resolved. Since I have not been appointed QA, I do not have the access rights to update the Bugzilla myself.
I assume that there are not obvious unit-tests to be added for this fix. Setting it to resolved fixed since it now works in the latest Papyrus-RT build.
Verified to be fixed in the latest Papyrus-RT build. The ports on capsule parts shows the stacking pattern for replicated ports. The aspect of defining the replication factor using a symbolic constant, as mentioned in Comment 1, is tracked separately in Bug 504760. Moving to verified fixed.
Closing as verified fixed.
