Schematex
usecase·OMG UML 2.5.1 §18·software, e-commerce, retail, education·complexity 2/3

Online bookstore use case diagram (include + extend)

An e-commerce checkout use case diagram showing «include» chains, an «extend» relationship with a condition and extension point, and the extension-point compartment inside the base ellipse. A primary customer, an external payment gateway, and a supporting warehouse actor.

For the business analyst

Open in Playground →
usecase·§
↘ preview
100%
Use Case Diagram — Online Bookstore — Checkout Subject: Bookstore System. 3 actors, 7 use cases, 3 include, 1 extend. Online Bookstore — Checkout Bookstore System Customer «actor» Payment Gateway Warehouse Staff Browse Catalog Add to Cart Checkout extension points payment failed stock depleted Pay Cancel Order Ship Order Validate Card «include» «include» «extend» [payment failed] (extension point: payment failed) «include»
UTF-8 · LF · 28 lines · 783 chars✓ parsed·3.3 ms·7.6 KB SVG

This is the diagram a business analyst hands to engineering when an online store is being scoped. It uses every relationship in the use case vocabulary, and each one means something precise.

Three actors on two sides. Customer is the primary actor (left). Payment Gateway is (external) — a third-party system, drawn as an «actor» rectangle on the right. Warehouse Staff is a supporting human actor, also on the right. Schematex flanks the subject automatically.

«include» — mandatory composition. Checkout ..> Pay reads "Checkout includes Pay": every checkout always runs the payment sub-flow, so the arrow points from the base toward the included use case. The chain continues — Pay ..> ValidateCard — so payment always validates the card. Include is the right tool when a step always happens and you want to factor it out for reuse. The dashed line, open arrowhead, and «include» pill are all UML-standard.

«extend» — optional, conditional behavior. Cancel <.. Checkout reads "Cancel Order extends Checkout": cancellation is optional behavior that only kicks in under a condition. The [payment failed] clause is that condition, and (extension point: payment failed) ties it to the named extension point declared inside the Checkout ellipse. Note the arrow still points at the base (Checkout) even though Cancel is written first — that's the UML rule, and Schematex normalises it for you. Extend lines are drawn in the accent color because they're the rarer, more surprising relationship.

Extension points live in the ellipse. Because Checkout declares extension point: payment failed and stock depleted, those appear in a compartment below the name, separated by a divider. They're the hooks an «extend» relationship can attach to.

The result reads top-to-bottom as a flow: browse → add to cart → checkout, with checkout fanning out into pay (→ validate card, → payment gateway), ship (→ warehouse), and an optional cancel path. That's exactly the scope picture a stakeholder review needs.

Use case syntax