Use a sequence diagram when you need to show who sends each message and in what order. The diagram records a supplied interaction contract; its arrows do not establish that an actual service implemented the contract.
Start from a bounded message contract
This original fictional reservation exchange has two participants: a Desk UI and a Reservation service. The UI sends one reserve request. If stock is available, the service returns a reservation reference. If stock is unavailable, it returns an unavailable response. The exercise defines no retries, payment operation or notification message.
The corresponding PlantUML source is:
@startuml
participant "Desk UI" as UI
participant "Reservation service" as Service
UI -> Service: reserve(item)
alt stock available
Service --> UI: reservation reference
else stock unavailable
Service --> UI: unavailable
end
@enduml
UI and Service are aliases used in message statements. The quoted names are displayed labels. Keep these roles separate so the source does not accidentally introduce another participant when referring to an existing one.
PlantUML's sequence-diagram reference, checked October 24, 2026, documents participant declarations, aliases and alternative message groups. Solid and dotted arrows provide visual notation here; the supplied contract must define the actual request and response meanings.
Reject a confirmation after both alternatives
Suppose a draft adds this line after end:
Service --> UI: reservation confirmed
That unconditional message follows the alternative block. It makes the unavailable path appear to receive a confirmation too. Move a required success message into the stock-available branch, or remove it if the reservation-reference reply already expresses the complete supplied success response. Do not invent another business event to justify the extra arrow.
| Path | Messages expected for this fixture |
|---|---|
| Available | reserve(item), then reservation reference |
| Unavailable | reserve(item), then unavailable |
These are the textual acceptance paths for the authored example. They remain useful even before a renderer is selected.
Request source and a message audit together
Draft one PlantUML sequence diagram from this interaction contract.
Participants, exact display names and roles: [PASTE]
Ordered messages and conditions for each outcome: [PASTE]
Facts not established by the source: [ENTER]
Return complete @startuml/@enduml source and a plain-text message list
for each alternative path. Declare participants explicitly with short
aliases. Use alt/else/end for mutually exclusive outcomes. Keep replies
inside the branch that produces them. Do not invent retries, services,
timeouts or success events. Flag missing behavior separately. Do not
claim to render the source or observe a service execution.
This task supplies the context and output requested in OpenAI's prompting guidance. A path list helps you catch a semantic error that attractive arrow spacing would not reveal.
Render the maintained source and inspect each path
Save the accepted source as a .puml file and render it with your chosen PlantUML installation or approved tool. Inspect participant names, message order and the boundaries of the alternative group. Record the renderer and actual result if you need reproducible output; this article supplies source and expected paths, not a native render receipt.
If your immediate task is deciding which kind of diagram fits a set of rules, the diagram guide starts there. For this sequence, keep the accepted message contract beside the .puml file and review both branches whenever an outcome changes.