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.
cWOn 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
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
|
