UMLR — Message Signature in Interactions and Reception.ownedParameter

currently (till 2.5) a message's signature is of type NamedElement that
resolves either to an Operation or Signal. Apart from the fact that the
nearest common superclass is Namespace, the use of elements of different
inheritance hierarchies makes it cumbersome/impractical to work with the
signatures easily. You always have to check what concrete signature is
associated, cast it into the appropriate subclass (i.e. either Signal or
Operation) and use it further.

Regarding Message::Signature, I was wondering, whether it wouldn't be
simpler and far more consistent to refer to a BehavioralFeature
(Operation/Reception which has to have an Signal associated) directly
instead of NamedElement (which ought to be Namespace)?

This leads to a situation where I was wondering why a Reception, though
it is a BehavioralFeature, does not say any word about owned parameters
at all? However, if Receptions would be able to capture information
about parameter, too, the treatment of Reception and Operation would be
pretty much the same with regard to their parameter semantics. So, it
might be worth to reconsider the relationship between BehavioralFeature,
Reception and Parameter. We could supplement

BehavioralFeature::ownedParameter

containment

with

/Reception::ownedParameter [0..1]

containment

The derivation algorithm of Reception::ownedParameter could be similar
to the following: A Reception declares at most one Parameter. Its type
and name must exactly the name and type of the Signal, referenced by
Reception::signal, if present. The direction kind of a Reception's
Parameter must be set to IN exclusively.

context Reception
inv 'parameter':
if not self.signal.oclIsUndefined then
not self.ownedParameter.oclIsUndefined and
self.ownedParameter.type = self.signal and self.ownedParameter.name =
self.signal.name and self.ownedParameter.directionKind ==
ParameterDirectionKind::IN
else
endif

This would ease the usage of BehavioralFeatures a lot, I'd say. In case
of Messages, one would only have to walk over
Message::signature::parameter instead of casting it down to either an
Operation or Signal..