| Previous | UML Classes | Table of Contents | UML Packages | Next |
•
NamedElement (from Kernel , Dependencies ) on page 99
A Message defines a particular communication between Lifeline s of an Interaction.
A Message is a NamedElement that defines one specific kind of communication in an Interaction. A communication can be, for
example, raising a signal, invoking an Operation, creating or destroying an Instance. The Message specifies not only the kind
of communication given by the dispatching ExecutionSpecification, but also the sender and the receiver.
A Message associates normally two OccurrenceSpecifications - one sending OccurrenceSpecification and one receiving OccurrenceSpecification.
Attributes
Issue 9191 - add default values
• messageKind:MessageKind The derived kind of the Message (complete, lost, found, or unknown). Default value is unknown.
• messageSort:MessageSort The sort of communication reflected by the Message. Default value is synchCall.
Associations
• interaction:Interaction[1] The enclosing Interaction owning the Message.
• sendEvent : MessageEnd [0..1] References the Sending of the Message.
• receiveEvent: MessageEnd [0..1] References the Receiving of the Message.
• connector: Connector[0..1] The Connector on which this Message is sent.
• argument:ValueSpecification [*] The arguments of the Message.
• /signature:NamedElement [0..1] The definition of the type or signature of the Message (depending on its kind). The associated named element is derived from the message end that constitutes the sending or receiving message event. If both a sending event and a receiving message event are present, the signature is obtained from the sending event.
Constraints
[1] If the sending MessageEvent and the receiving MessageEvent of the same Message are on the same Lifeline , the sending MessageEvent
must be ordered before the receiving MessageEvent .
[2] The signature must either refer to an Operation (in which case messageSort is either synchCall or asynchCall) or a Signal
(in which case messageSort is asynchSignal). The name of the NamedElement referenced by signature must be the same as that
of the Message.
[3] In the case when the Message signature is an Operation, the arguments of the Message must correspond to the parameters
of the Operation. A Parameter corresponds to an Argument if the Argument is of the same Class or a specialization of that
of the Parameter.
[4] In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of
the Signal. A Message Argument corresponds to a Signal Attribute if the Argument is of the same Class or a specialization
of that of the Attribute.
[5] Arguments of a Message must only be: i) attributes of the sending lifeline. ii) constants. iii) symbolic values (which
are wildcard values representing any legal value). iv) explicit parameters of the enclosing Interaction. v) attributes of
the class owning the Interaction.
[6] Messages cannot cross boundaries of CombinedFragment s or their operands.
[7] If the MessageEnd s are both OccurrenceSpecifications, then the connector must go between the Parts represented by the
Lifeline s of the two MessageEnd s.
Semantics
The semantics of a complete Message is simply the trace <sendEvent, receiveEvent>.
A lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret
this to be because the message never reached its destination. The semantics is simply the trace <sendEvent>.
A found message is a message where the receiving event occurrence is known, but there is no (known) sending event occurrence.
We interpret this to be because the origin of the message is outside the scope of the description. This may for example be
noise or other activity that we do not want to describe in detail. The semantics is simply the trace <receiveEvent>.
Issue 8345 -remove extraneous dash
A Message reflects either an Operation call and start of execution or a sending and reception of a Signal.
When a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallOperationAction
on the sending Lifeline as well as the arguments of the CallEvent occurrence on the receiving Lifeline .
When a Message represents a Signal, the arguments of the Message are the arguments of the SendAction on the sending Lifeline
and on the receiving Lifeline the arguments are available in the SignalEvent .
If the Message represents a CallAction, there will normally be a reply message from the called Lifeline back to the calling
lifeline before the calling Lifeline will proceed.
Notation
Issue 8745 -clarify valid angles of message lines
A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line
fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may
both be on the same lifeline. The form of the line or arrowhead reflects properties of the message:
•
Asynchronous Messages have an open arrow head.
Issue 8345 -replace ‘method’ with ‘operation’ and make reply case a separate bullet item
•
Synchronous Messages typically represent operation calls and are shown with a filled arrow head.
•
The reply message from a method has a dashed line.
•
Object creation Message has a dashed line with an open arrow.
•
Lost Messages are described as a small black circle at the arrow end of the Message.
•
Found Messages are described as a small black circle at the starting end of the Message.
Issue 7950 -Clarifying decoration of Messages in Communication Diagrams
•
On Communication Diagrams, the Messages are decorated by a small arrow in the direction of the Message close to the
Message name and sequence number along the line between the lifelines (See Table 14.4
and Figure 14.27).
Syntax for the Message name is the following: <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument>
[‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’
Issue 7970 - Correcting minor error in BNF for message argument.
<argument> ::= ([<parameter-name> '='] <argument-value>) | (<attribute> '=' <out-parameter-name> [':' <argument-value>] )
| ' -'
Messageident equaling ‘*’ is a shorthand for more complex alternative CombinedFragment to represent a message of any type.
This is to match asterisk triggers in State Machines.
Return-value and attribute assignment are used only for reply messages. Attribute assignment is a shorthand for including
the Action that assigns the return-value to that attribute. This holds both for the possible return value of the message (the
return value of the associated operation), and the out values of (in)out parameters.
When the argument list contains only argument-values, all the parameters must be matched either by a value or by a dash (-).
If parameter-names are used to identify the argument-value, then arguments may freely be omitted. Omitted parameters get an
unknown argument-value.
In
Figure 14.16 we see only asynchronous Messages. Such Messages may
overtake each other.
In Figure 14.11 we see method calls that are synchronous accompanied by replies. W
e also see a Message that represents the creation of an object.In
Figure 14.27 we see how Messages are denoted in Communication Diagrams.
Examples of syntax:
mymessage(14, - , 3.14, hello) // second argument is undefined v=mymsg(16, variab):96 // this is a reply message carrying
the return value 96 assigning it to v mymsg(myint=16) // the input parameter ‘myint’ is given the argument value 16
See
Figure 14.11 for a number of different applications of the textual syntax of message identification.
Changes from previous UML
Messages may have Gate s on either end.