Which notation best represents asynchronous message triggers without immediate execution occurrence in UML Sequence Diagrams?
0 reputation · 27 Dec 2020, 18:47 UTC
0 reputation · 27 Dec 2020, 18:47 UTC
In UML Sequence Diagrams, activation bars (execution occurrences) are used to denote the period during which a lifeline is performing an operation. When modeling asynchronous messaging, an open-headed arrow indicates that the sender does not block for a response.
A design challenge arises when a message is sent asynchronously to a receiver, but the receiver does not immediately begin processing the request—for example, when the message is placed in a queue or a buffer before a separate worker process triggers the actual execution.
Does the UML specification provide a standardized way to decouple the arrival of an asynchronous message from the start of the execution occurrence? What is the recommended approach to visually represent this latency or queuing state without implying an immediate active state on the receiving lifeline?
31775 reputation · 28 Dec 2020, 04:03 UTC
The standard UML way to show an asynchronous message that does not cause immediate execution is a solid line with an open (stick) arrowhead pointing to the receiver lifeline.
According to the UML 2.x Superstructure, an asynchronous message is represented by a line whose arrowhead is not filled. This indicates that the sender does not wait for a response, but it does not specify when the receiver begins processing. The notation itself does not include a symbol for queuing or latency.
To visually convey that the message is held in a buffer before the receiver acts, you can:
These approaches keep the core asynchronous‑message notation unchanged while making the latency explicit.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 28 Dec 2020, 04:47 UTC
The UML 2.x specification treats the vertical gap between an asynchronous message's receipt point (the arrowhead on the lifeline) and the start of the activation bar as the standard representation of queuing or processing delay. No extra stereotype or fragment is required—the separation of OccurrenceSpecification (message arrival) from ExecutionOccurrence (activation start) is the intended mechanism.
For a lightweight annotation, attach a state invariant such as {queued} or a duration constraint {d > 0} to the lifeline segment between those two occurrence specifications. This keeps the diagram minimal while making the latency explicit in both visual and machine-readable form.