A UML use case diagram shows what a system does from the user's point of view: the actors who use it, the things they can do, and how those use cases relate. This template is a worked restaurant example, with actors like Customer, Waiter, and Chef connected to use cases like Order Food and Pay for Food. Analysts and developers use it to capture requirements and agree on a system's scope before building.
A use case diagram shows what actors can do with a system at a high, requirements level: the functional goals, without specifying order or timing. A sequence diagram shows how one scenario plays out message by message over time, between specific objects. In a restaurant, 'a customer orders food' is a use case; the back-and-forth between the waiter and the kitchen to fulfil it is a sequence. Use one to define what, the other to detail how.
A use case diagram is a UML diagram that shows how users interact with a system. It has actors (the people or systems outside), use cases (the things the system does, drawn as ovals), and a boundary that marks what's in scope. Lines connect actors to the use cases they take part in. It's used to capture requirements and agree on scope.
A use case diagram has four main parts: actors (roles outside the system, drawn as stick figures or icons), use cases (functions the system performs, shown as ovals), the system boundary (a box around the use cases), and relationships, the associations between actors and use cases plus «include» and «extend» links between use cases.
Both connect one use case to another, but they mean different things. «include» is for mandatory shared behavior that always runs, like 'Authenticate' included by several use cases. «extend» is for optional or conditional behavior that only runs sometimes, like 'Serve Wine' extending 'Serve Food' if wine was ordered. Include is always; extend is sometimes.
A use case diagram shows what actors can do with a system at a high, requirements level: the goals, not the order. A sequence diagram shows how one scenario plays out step by step, the messages passed between objects over time. Use a use case diagram to define what the system does; use a sequence diagram to detail how a specific interaction works.
Three common examples: a restaurant system, where a Customer places an order, a Waiter serves it, and a Chef cooks it, with 'Serve Wine' extending 'Serve Food'. An ATM, where a Customer withdraws cash and checks a balance, both including 'Authenticate'. And online shopping, where a Customer browses and checks out (including 'Log in') and an Admin manages inventory. This template uses the restaurant example.