UML diagrams for an inventory management system

The key facts

• Class diagram: Product, Location, Movement, Order, Supplier — the data model and its relationships.
• Sequence diagram: how an order flows — check stock, reserve, pick, invoice, push to accounting.
• State diagram: one order's life — received → checked → picked → packed → invoiced → paid.
• Use-case diagram: the four actors and what each triggers.
• The honest note: diagrams specify; they do not build. A working system still needs transactions, audit trails and integrations behind the boxes.

The class diagram — the data model

The class diagram is the one that matters most and gets drawn worst. The honest core: Product (with SKU, unit, cost), Location (warehouse, aisle, van), Movement (receipt, issue, transfer, adjustment — with user and timestamp), Order (customer, lines, status), Supplier and PurchaseOrder, Batch (lot, expiry) where goods age. The relationships carry the truth: a Movement always references a Product and a Location; an Order references its customer and its lines; a Batch references what went into it.

Get this diagram right and everything downstream follows; get it wrong — say, quantities living on the Order instead of emerging from Movements — and no amount of code fixes the record. The architecture diagram shows how these classes become layers.

Sequence and state — the behaviour

The sequence diagram traces one flow across actors: customer places order → system checks live stock (including promises to others) → reserves → warehouse picks and packs → approval → invoice pushed to Xero or MYOB → payment status mirrors back. Drawing it exposes every place the flow touches the record — and every place a home-built version needs a transaction where it planned a variable.

The state diagram tracks one order through its life: received, checked, picked, packed, invoiced, paid — with the transitions named by the events that cause them. If a state can be reached without work happening (someone just editing the status), the design is lying. The use-case diagram — drawn in full here — is the simplest: four actors, their triggers, and the system enforcing the rules.

Using the diagrams honestly

Diagrams specify; they do not build. Their best use is evaluation: take any four diagrams to a vendor demo and check which behaviours exist — live availability checks, self-updating states, mirrored payments, audited adjustments. They are also the fastest requirements tool for a custom build, and the honest companion to the build-it-yourself guide, which is clear about where self-built stops.

We build BSimple, so weigh that: the diagrams above describe its actual shape — movements as transactions, states driven by work, batch traceability, the accounting handoff — from $180/month (AUD). The trial runs the sequence diagram on your own products; the inventory management guide is the class diagram with prose.