UML25 — Interactions needs to fix Gate name Distinguishability rules

The isDistingishableFrom() operation of NamedElement needs to be
overridden for Gate class to cover the case of when the gate is used as
a formalGate of an Interaction. The association end formalGate subsets
ownedElement, and since the Gate name attribute is optional, it is
allowed to have two formal gates without an explicit name, but having
derived names which are distinct.

Even though the gate matching rules do not use this operation, we need
to override it to avoid problems.

In addition to this fix, there is a also need to add constraints to the
gate names used for Gates for the gate matching rules to work properly.
In particular, there are cases in use of gates which require distinction
for the gate matching rules to work.

Thus there is still a need to add new constraints on gate Names (explicit
or derived).

Because Gates which do not have an explicity name attribute have derived
names, any constraint must include the possibility of these derived
names.

There is an explicit operation getGateName() on Gate class which returns
the name of the gate which is to be used in the gate matching rules. If
a gate does not have an explicit name attribute, a gate name is derived
from the name of the message the gate is attached to , and the direction
of the message with respect to the gate (e.g, foo_in, foo_out). The
direction "in" or "out" is considered with respect to the outer perimeter
of the interaction fragment that the gate is attached to.

UML 2.5 added Gate matching rules in OCL, using this getGateName()
operation, however there are currently no gate name distinguishably
constraints in the spec. Two gates in the same container may have
duplicate derived names, just because they are attached to two different
messages, with the same direction, which happen to have the same name.
There are cases when the gate matching rules will not work unless at
least one of these gates needs includes an explicit name attribute value
contrived to avoid the collision of the getGateNames() operation.

The association end formalGates of Interaction subset ownedMember, and,
as already stated above, we have to override the isDistinguisableFrom()
operator for gate class. However, If there were two formal Gates with
the same gate name in an interaction, the gate matching rules would
become invalid.

The association ends actualGates of InteractionUse, and cFragmentGates
of CombinedFragment, both subset ownedElement, not ownedMember. So they
no not need to obey the isDistinguisableFrom test. However, even though
not required for the UML namespace Rules, actual Gates for an
InteractionUse should have distinguishable gate names, in order for the
gate matching rules to work.

For the same reason, If a cFragmentGate is outside the CombinedFragment,
then it must be distinguishable from other outer cFragmentGates of that
same CombinedFragment.

For the same reason, any two inner cFragmentGates associated with the
same InteractionOperator of a CombinedFragment must have distinguished
gate names.

Thus we need to add a set of four constraints (one for each kind of gate)
to the Gate class. Adding these four constraints will ensure that the
gate matching rules work correctly.

Proposed Change:

Override the isDistinguishableFrom() operation of Gate to always return
true.

Add the following four new constraints to the Gate class. These rely on
the four existing boolean operators of the Gate class which are used to
determine in which of the four contexts of association that the gate is
an instance of.

formal_gate_distinguishable
isFormal() implies <test that no other formal
gate of the parent Interaction returns the same getGateName() as returned
for self>

actual_gate_distinguishable
isActual() implies <test that no other actual
gate of the parent InteractionUse returns the same getGateName() as
returned for self>

outside_cf_gate_distinguishable
isOutsideCF() implies <test that no other
outside cf gate of the parent CombinedFragment returns the same
getGateName() as returned for self>

inside_cf_gate_distinguishable
isInsideCF() implies <test that no other
inside cf gate attached to a message with its other end in the same
InteractionOperator as self returns the same getGateName() as returned
for self>

I leave the detailed OCL for the actual OCL to include within the < >
for the actual resolution of this issue.

Override the isDistinguishableFrom() operation of Gate to always return true.
Fix a problem in the isInnerCF operation, to fix the other End Gate situation.
Add the following four new constraints to the Gate class. These rely on the four existing boolean operators
of the Gate class which are used to determine in which of the four contexts of association that the gate is an
instance of.
formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction
returns the same getGateName() as returned for self>
actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse
returns the same getGateName() as returned for self>
outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment
returns the same getGateName() as returned for self>
inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message
with its other end in the same InteractionOperator as self returns the same getGateName() as returned for
self>