In UML/SysMLv1.x Lifelines do not have specific information about the times or time ordering of events (such as Message arrival/sending) of other Lifelines
A SignalEvent represents the receipt of an asynchronous Signal instance. Source Unified Modeling Language 2.5.1
A CallEvent models the receipt by an object of a message invoking a call of an Operation. Source Unified Modeling Language 2.5.1
A trigger for an AnyReceiveEvent is triggered by the receipt of any message that is not explicitly handled by any related trigger. Source Unified Modeling Language 2.5.1
The “hybridSUV” lifeline represents another interaction which further elaborates what happens inside the “hybridSUV” when the vehicle is started. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.9 shows an interaction that includes events and messages communicated between the driver and vehicle during the starting of the vehicle. Source OMG Systems Modeling Language (SysML) 1.6
SysML-1.6: In Figure D.9 is a synchronous Message from Lifeline for :Driver for an Operation StartVehicle() intended? Does it make sense for the human Driver to have to wait for such a synchronous call?
Figure D.10 - White Box Interaction for “StartVehicle” Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6: HSUV sample Slide kind SysML Sequence Diagram UML Sequence Diagram
If the reply Message has a signature, then wildcard arguments are provided for all return, out and inout ownedParameters of the signature Operation. Source Unified Modeling Language 2.5.1
If the identity of a reply Message is obvious (e.g., when its sendEvent is the only reply within the extent of an ExecutionOccurence where there is only one receipt of an Operation call message), the label may be omitted to simplify the diagram. Source Unified Modeling Language 2.5.1
If an output-argument does not have an explicit assignment-target specified, it is considered to have an unknown assignment target. In this case, it is required to include a value-specification, which denotes the returned value for the argument. Source Unified Modeling Language 2.5.1
An output-argument with an explicit assignment-target given may also optionally include a value-specification. If a value-specification is given, then this denotes the returned value for the argument. Otherwise the argument has no modeled returned value Source Unified Modeling Language 2.5.1
Note that the parentheses are not considered part of the output-argument list, so a reply-message-label without an output-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. Source Unified Modeling Language 2.5.1
If a reply-message-label does not include an output-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all out and inout ownedParameters of the signature Operation (if any). Source Unified Modeling Language 2.5.1
An output-argument always explicitly names the parameter to which it is to be matched. Any parameters that are not named are considered to have implicit wildcard arguments. (There is thus no need for an explicit wildcard notation for output-arguments.) Source Unified Modeling Language 2.5.1
If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. However, if the Message has a signature that is an Operation with out or inout ownedParameters, then ... Source Unified Modeling Language 2.5.1
If a reply Message does not have a signature, then the only argument that may be specified for it is a return argument as specified above. Source Unified Modeling Language 2.5.1
If the Message has a signature without a return parameter, then no assignment-target or value-specification may be given for the reply-message-label as a whole. Source Unified Modeling Language 2.5.1
If the Message has a signature that is an Operation with a return parameter, then this assignment-target and/or value-specification corresponds to the argument for that parameter (if no assignment-target is given, it is considered to be unknown). Source Unified Modeling Language 2.5.1
A reply-message-label may optionally have an assignment-target given to the left of the message-name, with a corresponding returned value denoted by the optional value-specification given after a colon at the end of the reply-message-label. Source Unified Modeling Language 2.5.1
If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply). Otherwise the name is unconstrained. Source Unified Modeling Language 2.5.1
The message-name appearing in a reply-message-label is the name property of the Message. Source Unified Modeling Language 2.5.1
A reply-message-label is used for reply Messages. It has the following form ... Source Unified Modeling Language 2.5.1
Note that the parentheses are not considered part of the input-argument list, so a request-message-label without an input-argument-list may still optionally include an empty set of parentheses (“()”) after the message-name. Source Unified Modeling Language 2.5.1
If a request-message-label does not include an input-argument-list and the Message has a signature, then this denotes that the Message has wildcard arguments corresponding to all in and inout ownedParameters of an Operation or attributes of a Signal ... Source Unified Modeling Language 2.5.1
Message::signature : NamedElement [0..1] ... The signature of the Message is the specification of its content. It refers either an Operation or a Signal. Source Unified Modeling Language 2.5.1
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 ... Source OMG Systems Modeling Language (SysML) 1.6
A found Message is denoted with a small black circle at the starting end of the Message. Source OMG Systems Modeling Language (SysML) 1.6
A lost Message is denoted with a small black circle at the arrow end of the Message. Source OMG Systems Modeling Language (SysML) 1.6
An object deletion Message (messageSort equals deleteMessage) must end in a DestructionOccurrenceSpecification. Source OMG Systems Modeling Language (SysML) 1.6
An object creation Message (messageSort equals createMessage) has a dashed line with an open arrow head. Source OMG Systems Modeling Language (SysML) 1.6
A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head. Source OMG Systems Modeling Language (SysML) 1.6
A synchronous Message (messageSort equals synchCall) has a filled arrow head. Source OMG Systems Modeling Language (SysML) 1.6
An asynchronous Message (messageSort equals asynchCall or asynchSignal) has an open arrow head. Source OMG Systems Modeling Language (SysML) 1.6
The form of the line or arrowhead reflects properties of the message Source OMG Systems Modeling Language (SysML) 1.6
The send and receive events may both be on the same lifeline. Source OMG Systems Modeling Language (SysML) 1.6
17.4.4.1 Message - A message is shown as a line from the sender MessageEnd to the receiver MessageEnd. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.9 - Black Box Interaction for "StartVehicle", referencing White Box Interaction Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6: HSUV sample Slide kind SysML Sequence Diagram UML Sequence Diagram
