Re: [papyrus-rt-dev] Visuals of Inherited Ports on Parts

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi,

I am not sure how to proceed here. Yes, due to the fact that in the semantic model there *is* only *one* element for the Port (which is exactly what I am trying to explain), both seen from the "inside" as well as seen from the "outside", the ConnectorEnd are forced to distinguish which part the port is related to, using the 'partWithPort' attribute, in the case the connector is connecting the port on the "outside". That is nothing new for me. I have just not brought that additional aspect up in this discussion because I thought that it was well-known and irrelevant to this discussion, and for me it does not really change my view on how the ports shall be colored. 

Since this aspect of the ConnectorEnd is exactly the same in RSARTE, I don't see why this should strengthen the case for the RoseRT-ish colouring which is based on rather different meta-model, where the connector either references a port (for the case when connecting on the "inside") or a port role (for the case when connecting on the "outside"), and the port role on the "outside" is a completely different element in the semantic model compared to the port (which the port role references, or is "projection of" as it is explained in RRTEI, the API for the RoseRT meta-model) and from the end-user perspective also is something different.

I think that we are spending far too much energy and time on this discussion. Since I am the only one arguing (at least in this mail-thread) for keeping the coloring according to how it is done in RSARTE, based on the fact that the port as seen from the "outside" *is* exactly the same element in the semantic model as seen from in the "inside", I simply rest my case. No need to spend any more time on this. We probably have much more important aspects to spend time on.

If we want to have someone else's opinion on this, I suggest that we ask Bran. He is the one that should have the best insight with respect to this difference regarding the "port role" as it existed in RoseRT and the reasons why it did not make its way into UML 2, and in what way this make us think differently about the port on the parts or not (as it apparently have been made between RoseRT and RSARTE), and whether we shall carry over the way of thinking (and coloring) from RSARTE or from RoseRT.

/Peter Cigéhn

On 30 November 2016 at 17:53, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi,

Indeed, the significance of the ConnectorEnd is that it has not only a reference to the Port that it connects (via the ‘role’ attribute) but optionally also a part that presents this port “on the outside” in the case of connection to a port on a part (the ‘partWithPort’) attribute.  So, a port P “on the inside” of a capsule C is the same element (strictly speaking in the UML structure) as the port P “on the outside” of a part of type C, but the port isn’t enough to understand the meaning in the second case without also the part-with-port.

So, the different visualization that I proposed initially for the two presentations of the same port element distinguishes this nuance of the part-with-port.  Does that strengthen the case for RoseRT-ish colouring over RSARTE-ish colouring?

cW

On 30 November, 2016 at 11:42:04, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

Hi,

On Wed, Nov 30, 2016 at 3:37 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

On 29 November 2016 at 19:07, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

[epp] I'm not entirely sure what you mean by visualizing a port "on the inside" and "on the outside". Is this in reference to port protocol1_2 of part capsuleB in Capsule2? To me it is very counterintuitive to show it "as is" (i.e. as it is defined in CapsuleB) rather than washed-out.

Yes, with "on the inside" I mean the in the context of the capsule itself, and "on the outside" I mean in the context of a capsule part typed by that capsule. This terminology is so natural for me, so I have always assumed that this was clear. There is a rather fundamental navigation in legacy tooling referred to as "Go Outside...", see Bug 494554 regarding this feature, where you navigate from a capsule to any capsule part being typed by that capsule.

Regarding this being counter-intuitive or not, is what I (hope) that I tried to explain regarding the big conceptual difference between RoseRT and RSARTE. Yes, if you have the "mental model" that the ports on the capsule parts ("on the outside") is another "thing" than the port on the capsule itself ("in the inside"), i.e. exactly as it worked in RoseRT and its meta-model with "port roles" on the "capsule role" on the "outside" vs. the "ports" on the "capsule" on the "inside" then you probably feel that this is counter-intuitive. 

[epp] It sounds that your definition of "port on the outside", i.e. "port role" in RoseRT corresponds to a UML ConnectorEnd. Although, a "port on the inside", that is, the port as defined in the capsule, also has a ConnectorEnd, when the port is a relay port.

 

But in RSARTE (and Papyrus-RT) the port visualized on the capsule part ("on the outside") is exactly the same "thing" as the port visualized on the capsule ("on the inside"). In both contexts you get

[epp] I think this is a bit confusing. Unless I completely misunderstood your definitions of "on the inside" and "on the outside". The port-on-a-part ("on the outside") cannot be the exact same object as the port in its definition context (the capsule that owns the port, "on the inside"), because the capsule that owns the port can be used in several different contexts: If we have capsule A with port p, we can have capsule B with part a:A and capsule C with part a:A as well, but then the occurrence of A.p in B is B.a.p, is definitely not the same as the occurrence of A.p in C, that is, C.a.p. As I understand it, the A.p is the port "on the inside" while B.a.p and C.a.p are the ports "on the outside". Of course, you can click on any these and they show the same contents and you can edit their properties, but they are not the exact same object. Strictly speaking, when the port occurs in a context (on the outside), what you get in the UML model is a ConnectorEnd with a reference (called "role" in UML) to the actual UML Port that it represents, i.e. the port in its definition context (inside). 

exactly the same contents in the properties view and if you navigate from the port on the capsule part, the port on the typing capsule is selected in the model explorer. Considering also that you do can edit all the properties of the port also from the "outside", including adding new ports (either using the new child menu or drag-and-drop). So this about that you edit a port, and redefine, in the context of the capsule ("on the inside") is not really true. It was true in RoseRT; but is not true in RSARTE (and not in Papyrus-RT either). 

I remember myself, that I had to "rethink" a lot regarding this conceptual difference when I made the transition from using RoseRT to using RSARTE.

Considering all this, I personally think it is pretty clear that we shall align with RSARTE and ensure that the port is visualized (washed out or not) in the same way both on the "outside" as on the "inside".

But if people still feel that this is counter-intuitive, then I have a feeling that the core problem is that you want the UML 2 meta-model to be more like the RoseRT meta-model, and that we need a concept of a "port role" on the capsule part. Bran should probably comment on why the "port role" never made its way into UML 2 (I do think that Bran have explained that there were a lot of discussions during the UML 2 standardization regarding these details, and the "port role" concept was "removed" as a simplification).

[epp] I am not proposing to change the UML 2 meta-model, and I cannot do it, anyway. I'm just stating that the meta-model already is like what you are describing with RoseRT. I may be misunderstanding things here as well, but to me, it looks like a ConnectorEnd is the same as a "port role". If not, what is the difference? 

/Peter Cigéhn

_______________________________________________
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