Previous UML Classes Table of Contents UML Packages Next


14.3.20 Message

BasicInteractions


*Generalizations

   

    NamedElement (from Kernel , Dependencies ) on page 99

*Description

   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

   Associations

   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.

*Examples

   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.