9.2 Message Types & Interaction References (ref)

9.2 Message Types & Interaction References (ref)

Quick Reference: Messages define directed communications between lifelines. Synchronous calls (solid line, filled triangle) block the sender until a reply message (dashed line, open stick arrowhead) arrives. Asynchronous messages (solid line, open stick arrowhead) are non-blocking. Create messages point directly into the head rectangle of a newly instantiated lifeline. To maintain modularity, an Interaction Reference (ref) embeds a sub-interaction defined on another sequence diagram, interfacing via boundary Gates.

---

Message Fundamentals and Communication Semantics

In a SysML Sequence Diagram, communication between lifelines is realized through Messages. A message defines a specific communication link between two lifelines (or from a single lifeline to itself). The transmission and reception of a message correspond to two fundamental metamodel occurrences:

1. Message Send Occurrence (SendEvent): The point in time on the transmitting lifeline where the message originates and departs.
2. Message Receive Occurrence (ReceiveEvent): The point in time on the receiving lifeline where the message arrives and triggers an effect.

Under SysML temporal semantics, the send event must strictly precede the receive event (t(send) ≤ t(receive)). When drawn as a horizontal arrow, transmission and receipt are modeled as instantaneous relative to the diagram's time scale. When drawn as a downward-sloping arrow, communication latency across a transmission medium is explicitly represented.

Message Signature Syntax

A message label displayed above the arrow follows a standardized syntax:

[attribute = ] messageName [ ( [parameterList] ) ] [ : returnType ]

• attribute =: Assigns the return value to a local property of the calling lifeline upon completion.
• messageName: The name of the operation being called or the signal being dispatched (e.g., readTemperature or emergencyStopSignal).
• parameterList: Comma-separated list of argument values or variables passed to the receiver.
• : returnType: The data type or value type returned by an operation call.

---

Synchronous Messages (Call Operation)

A Synchronous Message represents an operation invocation where the sender halts its own execution and enters a suspended (blocked) state, waiting for the receiving participant to complete the invoked operation and return control.

Graphical Notation

• Line Style: Solid horizontal line.
• Arrowhead Style: Solid, filled triangular arrowhead (—▶).

Execution Semantics

1. The sending lifeline dispatches the call and immediately suspends execution.
2. The receiving lifeline receives the call, starting an Execution Specification (activation bar).
3. The receiver executes the requested operation.
4. When the operation completes, the receiver transmits a Reply Message back to the sender.
5. The sender receives the reply, terminates its blocked wait, and resumes execution.

Caller                                   Receiver
  |                                         |
  +---+                                     |
  |   |-------- readPressure(sensorID) ----▶|
  |   |         (Solid line, filled head)   +---+
  |   |                                     |   |  <-- Execution bar
  |   |                                     |   |
  |   |◀- - - - return pressureValue - - - -+---+
  +---+         (Dashed line, stick head)   |
  |                                         |

---

Reply Messages (Operation Returns)

A Reply Message represents the explicit return of control and output data from a completed operation back to the originating caller of a synchronous message.

Graphical Notation

• Line Style: Dashed horizontal line.
• Arrowhead Style: Open stick arrowhead (- - - >).

Semantic Rules

• Pairing Requirement: Every synchronous call is paired with a corresponding reply message unless the return of control is modeled implicitly by the termination of the receiver's execution specification.
• Data Return: The reply message label specifies return values or output parameter values (e.g., return statusOK or status = true).
• Activation Boundary: The dispatch of the reply message coincides with the bottom edge (termination) of the execution specification on the receiver.

---

Asynchronous Messages (Signal & Asynchronous Calls)

An Asynchronous Message represents a non-blocking communication where the sender dispatches a message—most commonly a Signal—and continues its own execution immediately without waiting for the receiver to receive, process, or acknowledge the message.

Graphical Notation

• Line Style: Solid horizontal line.
• Arrowhead Style: Open stick arrowhead (—>).

Execution Semantics

• Non-Blocking: The sender does not halt, does not enter a suspended state, and does not require a reply message.
• Decoupled Processing: The message is typically placed into the receiver's event pool or message buffer. The receiver processes the signal when its internal scheduling or state machine permits.
• Common Engineering Applications: Sensor telemetry broadcasting, fault alerts, trigger signals between distributed physical controllers, and event notifications in reactive architectures.

Sender                                  Receiver
  |                                         |
  +---+                                     |
  |   |-------- alertOverheat(temp) ------->|
  |   |         (Solid line, stick head)    +---+
  +---+                                     |   |  <-- Processes at convenience
  |                                         +---+
  |  <-- Sender continues immediately      |

Exam Trap: Pay meticulous attention to the arrowhead. A solid line with a filled triangular arrowhead is a synchronous blocking call. A solid line with an open stick arrowhead is an asynchronous non-blocking message. Confusing these two arrowheads is one of the most common pitfalls on the OCSMP Model User exam.

---

Lifecycle Messages: Create and Delete

SysML Sequence Diagrams model dynamic lifecycle variations where instances are created and destroyed during interaction execution.

Create Message (Instantiation)

• Notation: A dashed horizontal line with an open stick arrowhead (- - - >).
• Destination: The arrow points directly into the head rectangle of the newly created lifeline.
• Elevation Rule: The head rectangle of the created lifeline is vertically offset—positioned at the exact vertical level of the create message arrow, rather than positioned at the top border of the diagram. This visually reinforces that the participant did not exist prior to this event.

Delete Message (Destruction Request)

• Notation: An arrow (synchronous or asynchronous) directed to the terminal destruction marker (X) of the target lifeline.
• Semantic Effect: Instigates the termination of the target instance. The target deallocates memory and resources, ceasing all further participation.

Creator                                NewInstance
   |                                        
   |                                        
   |- - - - - createSubsystem() - - - - - > +---------------------+
   |        (Points to head box)            | :GuidanceProcessor  |
   |                                        +---------------------+
   |                                                   |
   |                                                   +---+
   |----------------- executeSelfTest() --------------▶|   |
   |                                                   +---+
   |                                                   |
   |----------------- terminate() -------------------->X  <-- Destruction Marker

---

Lost and Found Messages

In complex system modeling, interactions must occasionally account for boundary conditions where one end of the communication is undefined, unknown, or outside the modeled scope.

Lost Messages

• Notation: A message arrow originating from a known lifeline and terminating at a small filled black circle (●).
• Semantics: The message was dispatched by the sender, but its destination is unknown, outside the system model boundary, or lost in transit (e.g., dropped packets over a noisy RF communications channel).

Found Messages

• Notation: A message arrow originating from a small filled black circle (●) and terminating at a known lifeline.
• Semantics: The message arrives at a known participant, but its originating sender is unknown or outside the modeled scope (e.g., a cold-start hardware interrupt, an unmodeled physical disturbance, or an external environmental stimulus).

---

Interaction References (ref)

In industrial systems engineering, end-to-end interactions often span dozens of complex sub-sequences. Drawing all operational details on a single diagram canvas leads to visual clutter, poor readability, and duplicate modeling effort. SysML resolves this through Interaction References.

The ref Frame (Interaction Use)

An Interaction Reference (UML's interaction use) is an interaction fragment that refers to an entire interaction defined elsewhere, usually on another sequence diagram. It is drawn like a combined fragment but is a separate UML construct.

• Graphical Syntax: A large rectangle enclosing the lifelines participating in the referenced behavior. In the upper-left corner of the rectangle, an operator pentagon displays the keyword ref.
• Content: The body of the ref box shows the name of the referenced interaction, e.g., CalibrateInertialSensors. The ref keyword sits only in the pentagon tag; no [Interaction] type label is written in the body.
• Parameter Passing: An interaction reference may pass input arguments and receive returned values (e.g., CalibrateInertialSensors(portID) : calMatrix).
• Semantic Equivalence: Graphically embedding a ref fragment is semantically equivalent to inlining the full referenced sequence diagram directly into that slice of execution.

+---------------------------------------------------------------------+
| sd [Interaction] NominalFlightProfile                               |
|                                                                     |
|   pilot : Pilot               fc : FlightCtrl         eng : Engine  |
|         |                            |                      |       |
|         |--- armFlightControls() ---▶|                      |       |
|         |                            |                      |       |
|     +===========================================================+   |
|     | ref                                                       |   |
|     |            CalibrateInertialSensors(biasTolerance)        |   |
|     +===========================================================+   |
|         |                            |                      |       |
|         |--- engageThrottle() ------▶|                      |       |
|         |                            |--- setThrust() -----▶|       |
+---------------------------------------------------------------------+

---

Diagram Gates: Frame Boundary Message Routing

When interactions are decomposed into modular sequence diagrams via interaction references, messages must enter and exit the referenced interaction boundaries cleanly. SysML accomplishes this using Gates.

Gate Definition & Syntax

A Gate is a formal connection point positioned directly on the boundary of an interaction frame or an interaction reference fragment:

1. Formal Gates (on the interaction's own frame): Connection points on the interior border of a sequence diagram frame. An arrow from the outside touches the frame at a gate point, allowing an external message to enter the interaction and connect to a local lifeline.
2. Actual Gates (on a ref box): Connection points drawn on the border of a ref fragment box. A message arrow from an enclosing diagram attaches to the gate on the ref boundary, matching the corresponding formal gate inside the referenced interaction.

Gate Notation

A gate is the point where a message line meets the frame or the ref box border. An optional gate name can be written next to that point, and messages on each side are matched through their gates. Gates ensure strict interface contracts between parent interactions and modular child interaction diagrams.

---

Summary Comparison of SysML Message Types

---

Exam Pitfalls & Misconceptions