subroute.
Beginner13 min readUML & Diagramminglive prototype

Component & Deployment Diagrams

These are the two 'zoom out' diagrams. A component diagram shows the big software building-blocks and the interfaces they offer and need; a deployment diagram shows the physical machines those blocks actually run on.

The idea

What it is

After class and object diagrams, which zoom in on individual classes, these two diagrams zoom out. A component diagram shows the big software building-blocks of a system — modules or services like Web UI, Order API, Database — and the interfaces each one offers and needs. A deployment diagram shows the physical side: which machines (called nodes) your software actually runs on, and which network links connect them.

Think of LEGO. A component diagram is the picture of the bricks and how they clip together — which brick offers a stud and which brick needs a stud. A deployment diagram is the picture of which shelves and boxes the bricks physically sit in. Same toy, two different questions: how do the pieces connect, versus where do the pieces live.

The one sentence to remember

Component diagram = the logical pieces and how they plug together (a brick offers a stud, another brick needs it). Deployment diagram = the physical machines those pieces run on and the wires between them. Component answers what connects to what; deployment answers where does it run.

Mechanics

How it works

Component diagram: the building-blocks

A component is a chunk of software you can build and replace on its own — a module, a library, or a whole service. You draw it as a rectangle with a little component icon in the corner, or with the keyword «component» above its name. The interesting part is the interfaces: the small symbols on the edges that say what each component offers and what it needs.

«component» Web UI ⊃ requires ● provides OrderService «component» Order API needs Database socket (⊃) = I NEED a service lollipop (●) = I OFFER a service
A lollipop ●— means "I provide this interface"; a socket ⊃— means "I require one." Order API provides OrderService (its lollipop) and needs the Database (its socket); Web UI's socket plugs onto Order API's lollipop — offer meets need.

Two symbols carry the whole meaning, and they fit together like a plug and a socket:

  • Provided interface — the lollipop (a line ending in a filled circle, ●—). It means “I offer this service.” Order API draws a lollipop labelled OrderService to say I provide order operations to whoever needs them.
  • Required interface — the socket (a line ending in a half-circle cup, ⊃—). It means “I need this service.” Web UI draws a socket to say I need an `OrderService` from somewhere.
  • Assembly — plugging in. When one component's lollipop sits inside another's socket, that's an assembly connector: the provider's ● clicks into the consumer's ⊃. Order API's lollipop plugs into Web UI's socket — the UI's need is satisfied by the API's offer.

Lollipop vs socket — never mix them up

*Lollipop `●—` = provided = I OFFER this.* Socket ⊃— = required = I NEED this.* Remember it as: the lollipop is a candy you give out; the socket is an empty cup waiting to be filled*. A working connection is always one component's lollipop sitting inside another's socket.

Deployment diagram: where it runs

A deployment diagram answers a different question: on which machines does this software actually run? It has three things — nodes, artifacts, and communication paths.

HTTPS JDBC/TCP Browser (device) «artifact» webapp.js App Server (node) «artifact» order-api.jar DB Server (node) «artifact» postgres node = a machine artifact = the deployed file path = a network link + its protocol
A node is a machine (the 3D box: Browser, App Server, DB Server), an artifact is the file deployed inside it (webapp.js, order-api.jar, postgres), and a labelled path is the network link — HTTPS from browser to app server, JDBC/TCP from app server to database.
  • Node — a 3D box that stands for a machine or device: a server, a phone, a browser, a container. Here Browser, App Server, and DB Server are three nodes.
  • Artifact — the actual deployable file that sits inside a node, drawn as a small rectangle (often marked «artifact»). Examples: webapp.js, order-api.jar, a Docker image, or postgres. The artifact is the real thing you copy onto the machine.
  • Communication path — a line between two nodes, labelled with the protocol they talk over: HTTPS between browser and app server, JDBC/TCP between app server and database. The label tells ops people exactly which wire and port to open.

Same system, two pictures

The Order API component (a logical building-block) is deployed as the order-api.jar artifact, which runs inside the App Server node (a physical machine). One side is what it is and what it connects to; the other side is where it physically lives and over what wire it talks. Drawing both shows you understand structure and operations.

Don't confuse the two

A common mix-up: putting machines in a component diagram, or interfaces in a deployment diagram. Keep them apart — component = logical structure (modules + provided/required interfaces), deployment = physical reality (nodes + artifacts + network links). If you're talking about clipping pieces together, that's component; if you're talking about which server it's on, that's deployment.

Interactive prototype

See it. Build it. Break it.

A sandboxed, hands-on simulation — no setup, no install. Play with it as you read.

About this simulation

Two views of the same small web app, with a toggle on top. The Component view draws three building-blocks — Web UI, Order API, Database — joined by a lollipop (●—, 'I offer this service') plugging into a socket (⊃—, 'I need this service'). The Deployment view redraws the same app as three machines — Browser, App Server, DB Server — with the real files sitting inside them and labelled network links between them. Click any piece in either view and one fixed note explains it in plain English. Only one note shows at a time, so nothing scrolls away or grows the page.

Hands-on

Try these yourself

Open the prototype above, predict what happens, then verify.

try 01

Read the lollipop and the socket

Open the prototype on the Component view. Find the round lollipop (●—) on Order API and click it — confirm the note says I offer this service. Now click the socket (⊃—) on Web UI — confirm it says I need this service. Say it out loud: Order API offers, Web UI needs. That offer-meets-need is the whole point of a component diagram.

try 02

Follow one feature across both views

Still on the Component view, click the Order API box and read what it is. Now toggle to the Deployment view and find order-api.jar inside the App Server node and click it. You've just followed one piece from logical building-block (the component) to physical file on a machine (the artifact). That's the bridge between the two diagrams.

try 03

Trace the wires

On the Deployment view, click the line labelled HTTPS between Browser and App Server, then the line labelled JDBC/TCP between App Server and DB Server. Read what each protocol means. Notice the diagram now tells an ops person exactly which machines talk to which, and over what — information a component diagram never shows.

In practice

When to use it — and what trips people up

When to reach for each one

Reach for a component diagram when you're organising the software: splitting a system into services or modules, planning how a monolith breaks into microservices, or showing a teammate which block offers which interface. Reach for a deployment diagram when you're planning where it runs: an infrastructure or DevOps conversation, deciding which server hosts what, or showing how machines connect and over which protocols.

Deployment is the bridge from LLD to HLD

A deployment diagram is where low-level design meets high-level design: it stops talking about classes and interfaces and starts talking about servers, containers, and networks. When an interviewer asks “and how would you deploy this?”, a quick node-and-path sketch — with HTTPS and JDBC/TCP on the links — shows you can think past the code to where it actually lives.

What it gives you

  • Zoom-out clarity — they show the whole system at a glance, which class diagrams (too detailed) can't.
  • Component diagrams make a clean service/module split obvious before you commit to it in code.
  • Provided/required interfaces force you to think about contracts between pieces, not just their insides.
  • Deployment diagrams give ops and DevOps a shared map of machines, artifacts, and the wires (and ports) between them.

Common mistakes

  • Easy to confuse the two — beginners put machines in a component diagram or interfaces in a deployment one.
  • Go stale quickly: infrastructure changes often, so a detailed deployment diagram needs constant upkeep.
  • Can oversimplify — a single node box can hide a whole cluster, load balancer, or auto-scaling group.
  • The notation (lollipop, socket, 3D node, «artifact») is unfamiliar at first and trips people up until practised.

Reference

Code & further reading

A minimal reference implementation and pointers worth bookmarking.

// A component diagram isn't code — but provided/required interfaces map
// straight onto an interface + dependency injection.

// The PROVIDED interface (the lollipop ●—): "I offer this service."
interface OrderService {
  placeOrder(itemId: string): string;
}

// OrderApi PROVIDES OrderService — it draws the lollipop ●—.
class OrderApi implements OrderService {
  placeOrder(itemId: string): string {
    return "order-for-" + itemId;
  }
}

// WebUi REQUIRES an OrderService (the socket ⊃—): it asks for one
// in its constructor instead of building its own. That's the socket.
class WebUi {
  // ⊃— required interface, satisfied by injection (the lollipop plugs in)
  constructor(private readonly orders: OrderService) {}

  checkout(itemId: string): string {
    return this.orders.placeOrder(itemId); // uses the offered service
  }
}

// "Assembly": OrderApi's lollipop plugs into WebUi's socket.
const ui = new WebUi(new OrderApi());

References & further reading

5 sources

Knowledge check

Did it land?

Quick questions, answers revealed on submit. Sign in to save your best score.

question 01 / 05

In a component diagram, what does a lollipop (a line ending in a filled circle, ●—) on a component mean?

question 02 / 05

Web UI draws a socket (⊃—) and Order API draws a lollipop (●—) labelled OrderService, and they plug together. What is happening?

question 03 / 05

You want to show which server runs your app and which database it talks to over JDBC/TCP. Which diagram do you draw?

question 04 / 05

In a deployment diagram, what is an artifact (e.g. order-api.jar sitting inside a node)?

question 05 / 05

What is the core difference between a component diagram and a deployment diagram?

0/5 answered