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

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

Hi,

This was a good question! I had to play around a bit a see how the legacy tooling behaves, including going back one older generation to RoseRT. Before going into the details how it looks like, I need to point out an important difference between RSARTE and RoseRT and its meta-models. Especially this question about where the primary context for editing a port and its properties are made, i.e. on the "outside" or on the "inside". RoseRT is based on UML 1.x and ports on capsule parts is handled differently, and so is the terminology. In RoseRT you have capsule roles on which you have port roles. The capsule role is typed by the capsule and the port roles are "typed" by, i.e. references, the ports on the corresponding capsule. So what you see on the outside are not the ports themselves, but port roles, and the properties presented in the properties dialog are basically a read-only subset of the properties of the port. This is rather different in RSARTE (and Papyrus-RT) based on UML 2.x where you see the actual ports directly on the outside on the capsule part. So yes, in RoseRT you *have* to go inside to to see, and edit, all properties of a port. But in RSARTE/Papyrus-RT you directly see all the properties, and can edit them, on the outside as well. So you don't have to go inside in the corresponding way as you had to in RoseRT. Just clarifying a (rather fundamental) conceptual difference between those two different generations of legacy tooling.

So, I made a similar model as what Christian made, but also extended it a bit to show a redefinition case as well. We have three inheritance chains Capsule1 <- Capsule2 <- Capsule3 and CapsuleA <- CapuleB <- CapsuleC. In CapsuleA have port "protocol1", CapsuleB adds port "protocol1_2" and CapsuleC adds port "protocol1_3" and redefines port protocol1.

As can be seen, the legacy tooling in RSARTE consistently visualizes the ports on the outside the same as on the inside. I assume that this makes most sense considering the fact that you can see and edit all the properties of a port, both on the outside as well as on the inside. Some things to be noted on the redefinition cases in Capsule3. Both the capsule part and the port have their labels in bold to indicate that they redefines their types. But only the capsule part have the redefinition annotation (filled arrow) in the top right corner. The port does not have it (it would probably make the port to be too cluttered). The redefinition annotation is shown on the port on the inside though as expected.

But what if we compare with an earlier generation of legacy tooling and check how this looks like in RoseRT?

As you can see, this is now more in line with what Christian proposes. But since we have this (rather fundamental) conceptual difference as explained above, I really think that the way RSARTE is doing it, i.e. the port is visualized the same on the inside as on the outside, makes more sense, since they *are* the same, and not as it actually was in RoseRT where it was a port role that you saw on the outside.

Regarding the connector, it should as Ernesto pointed out, and as can be seen above, be shown as "washed out" as well. We have concluded that there is an oversight in the UML-RT profile and profile document regarding the exclusion/redefinition of connectors. This is tracked by bug 507968. Bran have confirmed that this a fault in the profile document.

Basically I would only expect to connectors to be excluded, which is just the special case of redefining it with nothing. To "redefine" and inherited connector by re-orient/re-route it feels strange and overly complex. I actually tried it in the legacy tooling and it behaved really strange and the semantic model and the diagrams got out of synch. When re-routing the inherited connector in the specialized context, the connector in the general context was updated, but not its diagram. The connector end lost it reference to port on part, just ending up in a big inconsistency. So not even the legacy tooling handles this in a good way (I guess the re-routing of the connector should have been blocked in the specializing context).

I think that the absolutely most easy is to simply state that connectors can basically only be excluded. So if you want to "re-route" an inherited connector you basically first exclude it, i.e. basically remove it in the inheriting context, and then draw a new connector. From user perspective this is probably the most simple and straight-forward way of doing it.

Regarding adding additional connectors for inherited ports, I would say that it feels like something that you would like to do. Of course the replication factor of the inherited port and existing connectors in the general context must allow for additional connectors to be added in the specializing context. But I guess this must checked so that the code-generator and run-time can handle it properly. Ernesto, any comments regarding this?

/Peter Cigéhn

On 28 November 2016 at 23:22, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Ernesto,

Thanks for your response.  Indeed, I quite neglected to state that port C is inherited by Capsule 3 (the type of the capsule3 part) from another capsule.  And that Capsule2 has a generalization relationship to Capsule1.

You raise a good point about inherited connectors.  The UML-RT Profile Specification does not discuss the inheritance and redefinition of connectors in capsules, and in fact the «RTRedefinedElement» stereotype is not permitted on connectors, which suggests that UML-RT does not recognize/allow redefinition of connectors.  So, I have questions:

• if we were to show inherited connectors (yes, they would be washed-out), should users be able to redefine them by connecting either end to some other port?
• does it make sense in a capsule to connect an inherited port to some port in the inheriting capsule context if the inherited port already has a connector in the capsule from which it is inherited?  To put it another way, can a capsule add another connector to an inherited port that already has a connector in a parent capsule?

This is complicated, of course, by the fact that connecting an inherited port in the inheriting capsule doesn’t have to redefine the port because the port doesn’t actually reference its connector ends (ConnectableElement::end is not navigable).  This is rather like the incoming and outgoing transitions of vertices in state machine inheritance.

cW

On 28 November, 2016 at 16:54:06, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

Is C supposed to be a port that Capsule3 inherits from some other capsule not shown here?

At first, I do agree that it would probably be easier if ports-on-a-part are "washed-out" according to the part's inheritance, i.e., D should be washed-out. If you need to redefine a port like D, you would do it in the capsule structure diagram for Capsule3, not the one shown here.

BTW, if Capsule2 is a subclass of Capsule1, I would expect a washed-out connector between A and D as well.

--

Ernesto Posse

Zeligsoft

On Mon, Nov 28, 2016 at 4:16 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Team,

I think I have a handle on how inherited ports and parts should look in capsule structure diagrams, but ports on parts present a bit of a quandary.  We want inherited elements to present in washed-out colours, which is easy enough.  viz. objects A and B in the attached screen grab.  This image shows the results of a naïve scheme in which all inherited ports are shown washed out, regardless of whether they are presented on a part shape or not.

For these ports on parts, I would like to survey the team and our users to see how they should be presented because I can see reasons for and against my own preference.  Consider object C in the diagram:  it doesn’t seem useful to me to distinguish inherited ports on a part shape because the part shape is not the primary context for editing these ports; that is what the capsule structure diagram of the capsule typing the part is for.  Conversely, looking at object D, I would be inclined to show this one in the washed-out colour because the part is inherited by the enclosing capsule, so indirectly the port on that part is inherited in this enclosing context.

So, my proposal is that all ports on a part should present the inheritance (or not) of the part, not their actual inheritance (or not) in the context of the capsule that is the part’s type.  So, in this example, C should be black and D should be grey.

Any contrary opinions?  Is there some nuance that I have overlooked?

Thanks,

Christian

_______________________________________________
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