Project: Model a Process Three Ways

Project: Model a Process Three Ways

Throughout this tutorial you have built each behavioral diagram type in isolation: sequence, activity, and state. Now you apply all three to a single real-world scenario and experience firsthand what each diagram reveals — and what it hides. This is the core skill of a practicing analyst: selecting the right lens for the right question, and triangulating between diagrams to produce a complete behavioral specification.

The Scenario: Online Pharmacy Order

A customer visits an online pharmacy, searches for a prescription medication, uploads a prescription image, places an order, and waits for a pharmacist to verify the prescription before the order is dispatched. If the pharmacist rejects the prescription the customer is notified and the order is cancelled. If approved, the warehouse picks and ships the order, and the customer receives a delivery confirmation.

This scenario is deliberately layered: it involves multiple participants (customer, pharmacist, warehouse), a conditional path (approve vs reject), and an object that changes state (the order). That makes it a perfect candidate for all three diagram types.

Diagram 1 — Sequence Diagram: The Verification Interaction

A sequence diagram is best when you need to show the precise exchange of messages between specific participants in time order. Here it answers: Who sends what to whom, and in what sequence, during prescription verification?

Key modeling decisions in this diagram:

• The alt fragment captures the approve / reject branch — both outcomes are visible in one diagram.
• The pharmacist activation bar shows exactly how long the verifyPrescription() call holds the thread.
• Return messages (dashed arrows) make the response data explicit: approvalResult flows back to the system, which then notifies the customer.

Diagram 2 — Activity Diagram: The End-to-End Order Flow

An activity diagram is best when you need to show the complete process flow — all steps, all decision points, and who is responsible for what. Here it answers: What is the full sequence of actions from order placement to delivery, and which role performs each?

Key modeling decisions:

• Three swimlanes partition responsibility: Customer, OrderSystem, and Pharmacist+Warehouse (combined for brevity).
• A decision diamond at "Verify Prescription" splits the flow clearly into approved and rejected paths.
• The process ends at two different final nodes: a successful delivery and a cancelled order. Both are valid terminal states.

Diagram 3 — State Machine Diagram: The Order Lifecycle

A state machine diagram is best when you need to track how one object (the Order) changes its condition over time in response to events. Here it answers: What are the valid states of an order, and exactly which events cause it to move between them?

Key modeling decisions:

• States such as Pending Verification and Shipped are stable resting places — the order sits in them until an event arrives.
• Transitions are labeled event [guard] / action: for example verificationResult [rejected] / notifyCustomer.
• Two terminal states (Delivered and Cancelled) make both outcomes explicit.

Comparing the Three Perspectives

Each diagram answers a different question about the same scenario:

• Sequence diagram — Who talks to whom, and when? Excellent for specifying API contracts, designing interface requirements, and reviewing handoff points between systems and people.
• Activity diagram — What is the full flow of work, and who owns each step? Best for process documentation, discovering missing steps, and communicating with business stakeholders.
• State machine diagram — What can an object be, and what makes it change? Essential for designing business rules, validation logic, and database status fields.

When to Draw All Three

In practice, you do not always need all three for every process. A useful heuristic:

• Draw a sequence diagram whenever you are specifying an integration or API between two systems or teams.
• Draw an activity diagram whenever a business stakeholder asks "how does the process work?" — it is the most readable for non-technical audiences.
• Draw a state machine whenever an object in your system has a status column (order_status, ticket_state, account_status). The diagram becomes the direct specification for that column's allowed values and transitions.