A communication diagram shows which objects talk to each other and in what order, by drawing them as boxes connected by links and numbering the messages along those links. It carries the same information as a sequence diagram but emphasises who is connected to whom rather than the timeline. Designers use it to spot chatty or tangled collaborations.
In UML 1 this diagram was called a collaboration diagram. It answers the question: for this one scenario, which participants exchange messages, and over which connections? Order is given by sequence numbers rather than vertical position, so you can lay participants out freely, often to mirror the architecture.
The same scenario can always be redrawn as a sequence diagram and vice versa; tools such as Enterprise Architect convert between them. The choice is about emphasis: sequence diagrams make timing easy to read, communication diagrams make structure and coupling easy to read.
Each box is a lifeline (participant) named name : Type. A plain line is a link: the participants can reach each other. Messages are small arrows along the link labelled with a sequence number and the operation. Decimal numbers express nesting: 1.1 and 1.2 happen while handling message 1. Prefix * means iteration and a [guard] makes a message conditional.
Walkthrough: the checkout UI sends 1: placeOrder to the order service, which then calls 2: reserve on inventory, 3: charge on payment and 4: sendReceipt on email, before 5: confirmation goes back to the UI. Laid out this way, it is obvious that OrderService is the hub: it has four links, everything else has one. That is either a deliberate orchestrator or a warning sign, and the diagram makes you decide.
Walkthrough: the chat API asks the retriever for context (1). While handling that, the retriever searches the vector DB for 50 candidates (1.1) and reranks them down to 5 (1.2). Only then does the API call the LLM with the question and context (2). Nested numbering shows that 1.1 and 1.2 are internal steps of retrieval, which is exactly the boundary you would mock in a unit test.
Read the numbers, not the layout: find 1, then follow the numbering, descending into 1.1, 1.2 before moving to 2. Then forget the numbers and look at the shape: how many links does each box have, and do any links cross layers that should not talk?
Common mistakes: flat numbering (1, 2, 3, ...) when calls are actually nested, which hides who called whom; drawing messages without a link to carry them; and trying to show loops and alternatives in detail, which sequence diagram fragments handle far better.
PlantUML has no dedicated communication syntax; a common trick is an object diagram with labelled links. Mermaid has none either, so many teams render the equivalent sequence diagram instead:
@startuml
object ":CheckoutUI" as ui
object ":OrderService" as os
object ":Inventory" as inv
object ":Payment" as pay
object ":Email" as mail
ui -- os : "1: placeOrder(cart) →\n5: confirmation ←"
os -- inv : "2: reserve(items) →"
os -- pay : "3: charge(total) →"
os -- mail : "4: sendReceipt() →"
@endumlModelling tools such as Enterprise Architect, Visual Paradigm and StarUML draw the real notation and can convert it to and from a sequence diagram.