Got it, let's break down how to model this non-blocking interaction with PlantUML sequence diagrams. Here's a tailored solution for your scenario:

Core Concept for Non-Blocking Behavior #

In sequence diagrams, non-blocking interactions are represented with asynchronous messages (open-headed arrows) instead of synchronous ones (solid arrows). We'll also use activate/deactivate to visualize System B's active state, and loop to capture Terminal A's continuous request cycle.

PlantUML Code (Basic Non-Blocking Flow) #

This version shows System B sending a response to Terminal A immediately, then switching back to interacting with System C:

@startuml
actor TerminalA as A
participant SystemB as B
participant SystemC as C

note over A: Runs continuous loop to request variables
loop Continuous Update Cycle
    A ->> B: Request variable x (non-blocking)
    activate B
    B -->> A: Send computed x value (async response)
    B ->> C: Process ongoing interaction (e.g., sync data)
    deactivate B

    A ->> B: Request variable y (non-blocking)
    activate B
    B -->> A: Send computed y value (async response)
    B ->> C: Process another interaction (e.g., fetch updates)
    deactivate B
end loop
@enduml

PlantUML Code (Explicit Parallel Non-Blocking) #

If you want to emphasize that System B handles the response to A while interacting with C (not just after), use a parallel block to show concurrent actions:

@startuml
actor TerminalA as A
participant SystemB as B
participant SystemC as C

loop Continuous Update Cycle
    A ->> B: Request variable x
    activate B
    parallel "Respond to A" : "Interact with C"
        B -->> A: Send x value (async response)
        B ->> C: Process parallel interaction
    end
    deactivate B

    A ->> B: Request variable y
    activate B
    parallel "Respond to A" : "Interact with C"
        B -->> A: Send y value (async response)
        B ->> C: Process another parallel interaction
    end
    deactivate B
end loop
@enduml

Key Details Explained #

• actor TerminalA: Marked as an actor since it's an external initiator (the terminal user/process).
• ->> / -->>: These are asynchronous message arrows—they signal that the sender doesn't wait for a confirmation before moving to the next action.
• activate/deactivate: Highlights when System B is actively processing a request, making the flow easier to follow.
• loop block: Wraps the entire cycle to represent Terminal A's continuous request pattern.
• parallel block: Explicitly models concurrent work in System B, which is perfect for showcasing true non-blocking behavior.

Just paste either code into any PlantUML editor to generate the sequence diagram.

内容的提问来源于stack exchange，提问作者Patrick Bucher