UML22 — Section 14 Interaction

As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

Changing this cardinality in the metamodel is a breaking change, and is unnessary.
It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
.something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
to be added later.
There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
type of the ConnectableElement associated with a Lifeline.
Disposition: Closed - No Change